記録媒体、再生システム
【課題】グラフィクスを、動画のような滑らかさで動かすことができる記録媒体を提供する。
【解決手段】グラフィクスストリームは、PESパケットの配列であり、PESパケットには、グラフィクスデータを格納したODS(Object Define Segment)と、制御情報を格納したPCS(Presentation Control Segment)とがある。PCSは、PESパケット列において自身より前方に存在するODS内のグラフィクスデータの表示色を、所定のタイミングで、PDS(Pallet Data Segment)を用いて、色変換する旨を示す情報であり、前記色変換に用いるべきPDSを示す参照値を含む。PCS、ODSは、それぞれ別々のDisplay Setに属しており、このODSは同じDisplay Set内のPCSからは参照されていない、非参照グラフィクスデータであってもよい。
【解決手段】グラフィクスストリームは、PESパケットの配列であり、PESパケットには、グラフィクスデータを格納したODS(Object Define Segment)と、制御情報を格納したPCS(Presentation Control Segment)とがある。PCSは、PESパケット列において自身より前方に存在するODS内のグラフィクスデータの表示色を、所定のタイミングで、PDS(Pallet Data Segment)を用いて、色変換する旨を示す情報であり、前記色変換に用いるべきPDSを示す参照値を含む。PCS、ODSは、それぞれ別々のDisplay Setに属しており、このODSは同じDisplay Set内のPCSからは参照されていない、非参照グラフィクスデータであってもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画ストリーム及びグラフィクスストリームが多重化されたデジタルストリームが記録されている記録媒体と、そのデジタルストリームを再生する再生装置とに関し、特に動画ストリーム及びグラフィクスストリームを再生装置が別個にデコードし、そのデコードにより得られた映像−グラフィクスを合成することで、再生映像を得る技術に関する。
【背景技術】
【０００２】
上述した合成技術は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択して表示することもできる。また必要に応じてグラフィクスを表示したり、消したりという選択も可能である。これらの選択が可能なので、かかる技術は、DVD-Video規格やETSI EN 300 743標準規格のプレーヤモデルに採用されている。上記規格技術においてグラフィクスストリームは、PESパケットの配列であり、PESパケットには、制御情報を格納したもの、グラフィクス本体たるグラフィクスデータを格納したものの2種類がある。制御情報は、グラフィクスデータより前に配置されており、制御情報及びグラフィクスデータの一対で一個のグラフィクス表示を実現する。具体的にいうと、再生装置は制御情報及びグラフィクスデータが順次読み込み、制御情報を解読すると共に、グラフィクスデータをデコードし、デコードにより得られた非圧縮グラフィクスを、制御情報の解読結果に従い、所望の表示タイミングで表示する。
【０００３】
かかるグラフィクス表示の先行技術には、以下の特許文献に記載されたものがある。
【特許文献１】特許第328220号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
以上のようなグラフィクス表示にあたっては、グラフィクス表示の度に、グラフィクスデータのデコードを行う必要があるので、1つのグラフィクス表示から、次のグラフィクス表示までの間隔は、グラフィクスデータのデコード期間に依存したものとなる。ここでグラフィクスの解像度が高く、デコード期間が長ければ長いほど、グラフィクスの更新間隔も長くなってしまう。
【０００５】
映画における字幕のように、グラフィクスが2〜3秒という時間間隔で更新されるのであれば、多少、グラフィクスの解像度が高く、デコード期間が長くなったとしても問題はない。しかし、アミューズメントの用途にグラフィクスを使用しようとする場合、グラフィクスの表示間隔をもっと短くしたいという要望がでてくる。
ここでアミューズメントの用途とは、登場人物の台詞を示すグラフィクスに、独特の動きを与えて、視聴者の注意をひいたり、色彩を派手に変化させることで、視聴者の意表を突くというものである。かかるグラフィクス表示の実現は、バラエティ色が濃い映像コンテンツの制作現場からの要望が特に強い。
【０００６】
しかしグラフィクスの滑らかな動きを実現するには、グラフィクスをデコードし、表示するという処理を、ディスプレィの一表示期間(NTSC方式の場合は1/29.97sec)という僅かな期間が経過する毎に、行う必要がある。ディスプレィの一表示期間が経過する度に、グラフィクスのデコード−表示を繰り返すというのは、多大な負荷であり、低コストでの普及を想定しているような再生装置のハードウェアスペックでは実現が困難である。
【０００７】
無論、上述したようなグラフィクス動きや色彩変化は、動画像の一コマ一コマにグラフィクスを予め合成しておき、各コマの絵柄の一部としてグラフィクスを取り扱うことで実現可能である。しかし一コマ一コマに、グラフィクスを予め合成しておくといく方法は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択的に表示するという、融通性を欠く。そのため、かかる方法を採用している限り、将来への展望は見えてこない。
【０００８】
本発明の目的は、グラフィクスを、動画のような滑らかさで動かすことができる記録媒体を提供することである。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明にかかる記録媒体は、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、前記パレットデータは、各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、前記制御データは、前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させることを特徴としている。
【発明の効果】
【００１０】
上述した構成において、制御データは、パケット列において自身より前方に存在するグラフィクスデータの表示色を、所定のタイミングで変換する旨を示している。そのため、パレットデータを指定する制御データのみを再生装置に送り込むだけでグラフィクスの色彩を変化させるという制御を再生装置に行わせることができる。制御データを送り込むだけで、グラフィクス表示を更新することができるので、グラフィクスの表示と、動画の再生との同期が容易になる。
【００１１】
このため、アミューズメントの用途、つまり、登場人物の台詞の色彩を派手に変化させることで、視聴者の意表を突くという用途にグラフィクスを利用することができ、バラエティ色が濃い映像コンテンツの制作現場からの要望を満たすことができる。
【発明を実施するための最良の形態】
【００１２】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、BD-ROM１００である。このBD-ROM１００は、再生装置２００、テレビ３００、リモコン４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００１３】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、BD-ROMの応用層に対する改良により実施することができる。図２は、BD-ROMの構成を示す図である。
本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。本図に示すようにBD-ROMには、ROOTディレクトリの下にBDMVディレクトリがあり、BDMVディレクトリの配下には、AVClipを格納したファイル(XXX.M2TS)、AVClipの管理情報を格納したファイル(XXX.CLPI),AVClipにおける論理的な再生経路(PL)を定義したファイル(YYY.MPLS)が存在する。本図に示すようなアプリケーションフォーマットを作成することにより、本発明に係る記録媒体は生産される。尚、XXX.M2TS、XXX.CLPI,YYY.MPLSといったファイルが、それぞれ複数存在する場合は、BDMVディレクトリの配下に、STREAMディレクトリ、CLIPINFディレクトリ、PLAYLISTディレクトリという3つのディレクトリを設け、STREAMディレクトリにXXX.M2TSと同じ種別のファイルを、CLIPINFディレクトリにXXX.CLPIと同じ種別のファイルを、PLAYLISTディレクトリにYYY.MPLSと同じ種別のファイルを格納することが望ましい。
【００１４】
このアプリケーションフォーマットにおけるAVClip(XXX.M2TS)について説明する。
AVClip(XXX.M2TS)は、MPEG-TS(Transport Stream)形式のデジタルストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、プレゼンテーショングラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、プレゼンテーショングラフィクスストリームは、映画の字幕をそれぞれ示している。図３は、AVClipがどのように構成されているかを模式的に示す図である。
【００１５】
AVClipは(中段)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(上１段目)、PESパケット列に変換し(上２段目)、更にTSパケットに変換し(上３段目)、同じくプレゼンテーショングラフィクスストリーム(下１段目)を、PESパケット列に変換し(下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００１６】
本図において多重されるプレゼンテーショングラフィクスストリームは1つであるが、BD-ROMが多言語対応型である場合、その言語毎のプレゼンテーショングラフィクスストリームがAVClipに多重される。かかる過程を経て生成されたAVClipは、通常のコンピュータファイル同様、複数のエクステントに分割され、BD-ROM上の領域に記録される。
続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。
【００１７】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、PCS(Presentation Composition Segment)、WDS(Window Define Segment)、PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、PCSは、画面構成セグメントと呼ばれ、WDS,PDS,ODS,ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。
【００１８】
図４（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図４（ｂ）に示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。
【００１９】
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にDisplay Setを、第１段目にEpochをそれぞれ示す。
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線は、第３段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。
【００２０】
第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう(※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。)。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像−グラフィクスの同期は保証されない。
【００２１】
Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図６は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当は」「ウソだった」「ごめん」「あれから」「3年がたった」のうち、3つの字幕「本当は」「ウソだった」「ごめん」は画面の下側に、「あれから」「3年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplay Setについて説明する。
【００２２】
図５における破線hk1,2は、第２段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。Epoch Start,Acquisition Point,Normal Caseという一連のDSは、第１段目のEpochを構成していることがわかる。『Epoch Start』、『Acquisition Point』、『Normal Case』は、DSの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。
【００２３】
『Epoch Start』は、”新表示”という表示効果をもたらすDSであり、新たなEpochの開始を示す。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。Epoch Startは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、”表示リフレッシュ”という表示効果をもたらすDisplay Setであり、先行するEpoch Startと全く同じDisplay Setをいう。Acquisition PointたるDSは、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、Acquisition PointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。
【００２４】
Acquisition PointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisition Pointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【００２５】
『Normal Case』は、”表示アップデート”という表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvの字幕は、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、PCSと、ENDのみのDSvを設けてこのDSvをNormal CaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。一方、Normal CaseのDSは、差分にすぎないので、Normal Case単独では画面構成は行えない。
【００２６】
続いてDefinition Segment(ODS,WDS,PDS)について説明する。
『Object_Definition_Segment』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。BD-ROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BD-ROMでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すPixel Codeと、画素値の連続長とにより、画素列を表現したデータである。Pixel Codeは、8ビットの値であり、1〜255の値をとる。ランレングスデータでは、このPixel Codeによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
【００２７】
ODSによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ODSは、図７（ａ）に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_in_sequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
【００２８】
『object_id』は、ODSはデコードされて対応するグラフィクスオブジェクトがオブジェクトバッファ上に読み出された場合、このグラフィクスオブジェクトと、オブジェクトバッファにおいてこのグラフィクスオブジェクトが占有している領域とを一意に識別する識別子である。1つ以上のグラフィクスオブジェクトが格納された状態において、オブジェクトバッファのメモリ空間における個々の領域は、このobject_idにより識別されることになる。仮にあるobject_idが2つ以上のDisplay Setに付加されている場合、先行するODSに対応するグラフィクスオブジェクトは、オブジェクトバッファに格納された後、同じobject_idを有する後続のグラフィクスオブジェクトにより上書きされることになる。かようなアップデートは、空き領域の虫食い状の発生や、グラフィクスオブジェクトの離散配置を避けるとの配慮である。その理由は以下の通りである。グラフィクス表示を行うため、オブジェクトバッファ上のグラフィクスオブジェクトは絶えずグラフィックスプレーンに転送されることになる。オブジェクトバッファ内に空き領域が虫食い状に発生したり、また同じobject_idをもったグラフィクスオブジェクトがバラバラにされて離散的に配置されると、グラフィクスオブジェクトを読み出すためのオーバヘッドが発生し、オブジェクトバッファ→グラフィックスプレーンの転送時にあたっての転送効率が落ちる。この効率低下は、グラフィクス−動画の同期表示に悪影響を及ぼしかねない。かかる事情から、オブジェクトバッファ上においてあるobject_idで識別されるグラフィクスオブジェクトが共有している領域は、同じ大きさと同じobject_idとをもったグラフィクスオブジェクトでのみ上書きできるとしている。
【００２９】
グラフィクスオブジェクト上書きにあたって、後続するグラフィクスオブジェクトのサイズは、先行するものと同じサイズでなければならない。先行するグラフィクスオブジェクトにより小さすぎてもいけないし、大き過ぎてもいけない。アップデートにあたってグラフィクスオブジェクトのサイズが同じになるようにグラフィクスオブジェクトを作成しておくというのは、オーサリング担当者にとっての責務になる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
【００３０】
『last_in_sequence_flag』、『object_data_fragment』について説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject_data_fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last_in_sequence_flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。
【００３１】
『Palette Difinition Segment(PDS)』は、色変換用のパレットを定義する情報である。パレットとは、1〜255のPixel Codeと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するPixel Codeを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。PDSのデータ構造を図７（ｂ）に示す。図７（ｂ）に示すようにPDSは、自身がPDSであることを示す『segment_type』、PDSのデータ長を示す『segment_length』、このPDSに含まれるパレットを一意に識別する『pallet_id』、EpochにおけるEpochのPDSのバージョンを示す『pallet_version_number』、各エントリーについての情報『pallet_entry』からなる。『pallet_entry』は、各エントリーにおける赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値)を示す。
【００３２】
続いてWDSについて説明する。
『window_definition_segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”window”と呼ばれ、このWDSで定義される。図８（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window_horizontal_position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window_vertical_position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window_width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。
【００３３】
window_horizontal_position、window_vertical_position、window_width、window_heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦:video_height、横:video_widthという二次元状の大きさをもつ。
window_horizontal_positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0〜video_width-1の値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0〜video_height-1の値をとる。
【００３４】
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、1〜video_width-window_horizontal_positionの値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので1〜video_height-window_vertical_positionの値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【００３５】
続いて『END of Display Set Segment』について説明する。END of Display Set Segmentは、Display Setの伝送の終わりを示す指標であり、Display Setにおける機能セグメントのうち、最後のODSの直後に配置される。この END of Display SetSegmentの内部構成は、自身が END of Display SetSegmentであることを示す『segment_type』と、当該機能セグメントのデータ長を示す『segment_length』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
【００３６】
以上がODS、PDS、WDS、ENDについての説明である。続いてPCSについて説明する。
PCSは、対話的な画面を構成する機能セグメントである。PCSは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id_ref』と、『composition_object(1)〜(m)』とから構成される。
【００３７】
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、Epoch Startであるかを示す。
【００３８】
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、PalletOnly Displey Updateに用いられるべきパレットを示す。
【００３９】
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図８（ｂ）の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id_ref』、『window_id_ref』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００４０】
『object_id_ref』は、グラフィクスオブジェクト識別子(object_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window_id_ref』は、ウィンドゥ識別子(window_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【００４１】
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。
【００４２】
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_position』、『object_cropping_width』、『object_cropping_height』からなる。
【００４３】
『object_cropping_horizontal_position』は、オブジェクトバッファにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_position』は、オブジェクトバッファにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４４】
『object_cropping_width』は、オブジェクトバッファにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、オブジェクトバッファにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。続いてPCSの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとは』『ウソだった』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるEpochは、DS1(Epoch Start)、DS2(Normal Case)、DS3(Normal Case)を有する。DS1は、字幕の表示枠となるwindowを定義するWDS、台詞『ほんとは ウソだった ごめん』を表すODS、1つ目のPCSを備える。DS2(Normal Case)は、2つ目のPCSを有する。DS3(Normal Case)は3つ目のPCSを有する。
【００４５】
次に個々のPCSをどのように記述するかについて説明する。Display Setに属するWDS、PCSの記述例を図１０〜図１２に示す。図１０は、DS1におけるPCSの記述例を示す図である。
図１０において、WDSのwindow_horizontal_position、window_vertical_positionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、window_width,window_heightは、ウィンドゥの表示枠の横幅、縦幅を示す。
【００４６】
図１０におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_positionは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして基準点からobject_cropping_width、object_cropping_heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてobject_horizontal_position,object_vertical_positionを基準点(左上)とした破線の範囲cp1に配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
【００４７】
図１１は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ウソだった』の左上座標を示し、object_cropping_height,object_cropping_widthは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
【００４８】
図１２は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１２におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ごめん』の左上座標を示し、object_cropping_height,object_cropping_widthは、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。
【００４９】
図１３は、図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。本図に示すようにオブジェクトバッファは、縦幅、横幅、位置が固定された格納領域A,B,C,Dが4つあり、このうち格納領域Aに、図１１に示した字幕が格納される。これら4つの格納領域A,B,C,Dのそれぞれには、格納されているグラフィクスオブジェクトに対応するobject_idにより識別される。つまりobject_id=1により格納領域Aが、object_id=2により格納領域Bが、object_id=3により格納領域Cが、object_id=4により格納領域Dがそれぞれ識別されるのである。グラフィックスプレーンへの転送効率を維持するため、これら格納領域の縦幅、横幅は終始固定されている。同じobject_idをもったグラフィクスオブジェクトがデコードにより新たに得られれば、それらの格納領域はその新たに得られたグラフィクスオブジェクトにより上書きされる。例えば、図１０に示した字幕と同じ位置に、同じ大きさで字幕を表示させたい場合、後続するDisplay Setにおいて、同じobject_idを付加したODSを設ければよい。このように同じobject_idを付加するだけで、オブジェクトバッファ上に存在するグラフィクスオブジェクトは、新たなグラフィクスオブジェクトで上書きされ、その新たなグラフィクスオブジェクトは、先のグラフィクスオブジェクトと同じ大きさ・同じ位置で表示されることになる。
【００５０】
表示効果実現にあたっての制約について説明する。なめらかな表示効果の実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。ウィンドゥクリアと、ウィンドゥ再描画とをビデオフレームの時間間隔で実現する場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートをRcとすると、ワーストケースでは、この転送レートRcでウィンドゥクリアと、ウィンドゥ再描画とを行わねばならない。そうするとウィンドゥクリア、ウィンドゥ再描画のそれぞれをRcの半分の転送レート(Rc/2)で実現せねばならない。
【００５１】
これらウィンドゥクリア−ウィンドゥ再描画をビデオフレームと同期させるには、
ウィンドゥサイズ×フレームレート≒Rc/2
を満たす必要がある。このフレームレートが29.97であるなら、
Rcは、ウィンドゥサイズ×2×29.97になる。
【００５２】
字幕の表示にあたっては、グラフィックスプレーン全体に対し、最低でも25%〜33%程度の大きさが必要となる。ここでグラフィックスプレーンの総画素数は1920×1080であり、一画素当たりのインデックスのビット長を8ビットとすると、グラフィックスプレーンの総容量は2Mバイト(≒1920×1080×8)になる。
【００５３】
この総容量の1/4をウィンドゥサイズとすると、500kバイト(＝2Mバイト/4)になる。これを上述した式に代入してRcを導けば、Rcは256Mbps(500Kバイト×2×29.97)と算出することができる。
この25%〜33%という大きさであれば、256Mbpsという転送レートで字幕の表示を行っている限り、如何なる表示効果を実現する場合であっても、動画との同期を維持することができる。
【００５４】
仮に、ウィンドゥクリア及び再描画のレートがビデオフレームのフレームレートの1/2,1/4でよいなら、Rcがたとえ同じであってもウィンドゥサイズを2倍,4倍にすることができる。以上がwindowの大きさについての説明である。続いて、windowの位置、範囲について説明する。上述したように、Epochにおいてウィンドゥの位置、範囲は一貫している。
Epochにおいてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
【００５５】
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
【００５６】
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が2つまでであると、最悪4つのオーバーヘッドが発生すると見込んで転送レートを設定すればよいので、ミニマムスタンダードたる転送レートを数値化し易くなる。
【００５７】
以上がウィンドゥについての説明である。続いてこれらPCS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplay Setから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するために想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。Display Set内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplay Setの割り当てである。
【００５８】
先ず、ODSに付加されたDTS、PTSにより、どのような同期制御がなされるかについて説明する。
DTSは、ODSのデコードを開始すべき時間を90KHzの時間精度で示しており、PTSはデコード終了時刻を示す。
ODSのデコードは、瞬時には完了せず、時間的な長さをもっている。このデコード期間の開始点・終了点を明らかにしたいとの要望から、ODSについてのDTS、PTSはデコード開始時刻、デコード終了時刻を示している。
【００５９】
PTSの値はデッドラインであるので、PTSに示される時刻までにODSのデコードがなされて、非圧縮状態のグラフィックオブジェクトが、再生装置上のオブジェクトバッファに得られなければならない。
DSnに属する任意のODSjのデコード開始時刻は、90KHzの時間精度でDTS(DSn[ODSj])に示されるので、これにデコードを要する最長時間を加えた時刻が、Display SetのODSjのデコード終了時刻になる。
【００６０】
ODSjのサイズを”SIZE(DSn[ODSj])”、ODSのデコードレートを”Rd”とすると、デコードに要する最長時間(秒)は、”SIZE(DSn[ODSj])//Rd”になる。ここで”//”は、小数点以下切り上げの割り算を示す演算子である。
この最長時間を90KHzの時間精度に変換し、ODSjのDTSに加算することにより、PTSで示されるべきデコード終了時刻(90KHz)は算出される。
【００６１】
DSnに属するODSjのPTSを、数式で表すと、以下の式のようになる。
PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)
そして互いに隣接する2つのODS(ODSj,ODSj+1)との間では、以下の関係を満たす必要がある。
【００６２】
PTS(DSn[ODSj])≦DTS(DSn[ODSj+1])
またDSnに属するENDは、DSnの終わりを示すものだから、DSnに属する最後のODS(ODSlast)のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2(ODSlast)のPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定される。
【００６３】
PTS(DSn[END]) = PTS(DSn[ODSlast])
続いてPCSのDTS、PTSの設定について説明する。
PCSのDTS値は、DSnにおける最初のODS(ODS1)のデコード開始時点か、それ以前の時点を示す。何故ならPCSは、DSnにおける最初のODS(ODS1)のデコード開始時点(DTS(DSn[ODS1]))、及び、DSnにおける最初のPDS(PDS1)が有効になる時点(PTS(DSn[PDS1]))と同時か、又はそれ以前に、再生装置上のバッファにロードされねばならないからである。よって以下の式の関係を満たす値に、設定されねばならない。
【００６４】
]DTS(DSn[PCS])≦DTS(DSn[ODS1])
DTS(DSn[PCS])≦PTS(DSn[PDS1])
そしてDSnにおけるPCSのPTSは、以下の数式から算出される。
PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)
ここでdecodeduration(DSn)は、PCSのアップデートに用いられる全グラフィクスオブジェクトのデコード及び表示に要する時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本DSn.PCSnの画面合成に用いられるオブジェクトをDSn.PCSn.OBJ[j]とした場合、decodeduration(DSn)は、ウィンドゥクリアに要する時間(i)、DSn.PCSn.OBJ[j]のデコード期間(ii)、DSn.PCSn.OBJ[j]の書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
【００６５】
decode_durationの計算は、図１４のプログラムに基づき行われる。また図１５、図１６（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図１５のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図１５のステップＳ１)。PLANEINITIALIZATINTIME関数(図１６（ａ）)は、Display Setを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図１５のステップＳ１では、DSn,DSn.PCS.OBJ[0],decode_durtationを引数に設定して、この関数を呼び出す。
【００６６】
続いて図１６（ａ）を参照しながらPLANEINITIALIZATINTIME関数について説明する。図１６（ａ）においてinitialize_durationとは、PLANEINITIALIZATINTIME関数の戻り値を示す変数である。
図１６のステップＳ２は、DSnのPCSにおけるcomposition_stateがEpoch Startかどうかにより、処理を切り換えるif文である。もしcomposition_stateがEpoch Startであるなら(図１４のDSn.PCS.composition_state==EPOCH_START、ステップＳ２＝Yes)、グラフィックスプレーンのクリアに要する時間をinitialize_durationに設定する(ステップＳ３)。
【００６７】
オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、グラフィックスプレーンの総サイズをvideo_width*video_heightとすると、クリアに要する時間(秒)は、「video_width*video_height//256,000,000」になる。これに、90,000Hzを乗じPTSの時間精度で表現すれば、グラフィックスプレーンのクリアに要する時間は「90000×video_width*video_height//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。
【００６８】
もしcomposition_stateがEpoch Startでないなら(ステップＳ２＝No)、WDSにて定義されるwindow[i]のクリアに要する時間をinitialize_durationに加えるという処理を全てのwindowについて繰り返す(ステップＳ４)。オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、WDSに属するウィンドゥ[i]の総サイズをΣSIZE(WDS.WIN[i])とすると、クリアに要する時間(秒)は、「ΣSIZE(WDS.WIN[i])//256,000,000」になる。これに、90,000Hzを乗じPTSの時間精度で表現すれば、WDSに属する全ウィンドゥのクリアに要する時間は「90000×ΣSIZE(WDS.WIN[i]))//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。以上がPLANEINITIALIZATINTIME関数である。
【００６９】
図１５のステップＳ５は、DSnに属するグラフィクスオブジェクトの数が2であるか、1であるかで処理を切り換えるものであり(図１４のif(DSn.PCS.num_of_object==2),if(DSn.PCS.num_of_object==1))、もし”1”であるなら(ステップＳ５＝1)、グラフィクスオブジェクトのデコードを行うための待ち時間をdecode_durationに加える(ステップＳ６)。この待ち時間の算出は、WAIT関数の呼出(図１４のdecode_duration +=WAIT(DSn,DSn.PCS.OBJ[0],decode_duration))で実現される。この関数呼出にあたっての引数はDSn,DSn.PCS.OBJ[0],decode_durationであり、待ち時間を示すwait_durationが戻り値として返される。
【００７０】
図１６（ｂ）は、WAIT関数の処理手順を示すフローチャートである。
このWAIT関数においてcurrent_durationとは、呼出元のdecode_durationが設定される。object_define_ready_timeは、Display Setのグラフィクスオブジェクト[i]のPTSが設定される変数である。
current_timeとは、DSnのPCSのDTSに、current_durationを足した値が設定される変数である。このcurrent_timeよりobject_define_ready_timeが大きい場合(ステップＳ７がYes、if(current_time < object_define_ready_time))、戻り値たるwait_durationは、object_define_ready_timeとcurrent_timeとの差分が設定されることになる(ステップＳ８、wait_duration += object_define_ready_time - current_time)。以上がWait関数である。ステップＳ６においてdecode_durationには、このwait関数の戻り値と、OBJ[0]をwindowに描画するのに必要な時間を足し合わせた時間(90,000*(SIZE(DSn.WDS.WIN[0]))//256,000,000)が設定されることになる(ステップＳ９)。
【００７１】
以上はDSnのグラフィクスオブジェクトが1つである場合の処理である。図１５のステップＳ５は、グラフィクスオブジェクトの数が2であるかどうかを判定している。DSnのグラフィクスオブジェクトが2以上であれば(図１４のif(DSn.PCS.num_of_object==2))、DSn,DSn.PCS.OBJ[0],decode_durationを引数として、wait関数を呼び出し、その戻り値をdecode_durationに加算する(ステップＳ１０)。
【００７２】
続くステップＳ１１は、DSnのOBJ[0]が属するwindowが、グラフィクスオブジェクト[1]が属するwindowと同一かどうかの判定であり(if(DSn.PCS.OBJ[0].window_id == DSn.PCS.OBJ[1].window_id)、もし同一であるなら、DSn,DSn.PCS.OBJ[1],decode_durationを引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップＳ１２)。OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１３)。
【００７３】
もし属するwindowが異なるなら(ステップＳ１１で”異なる”)、OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１５)。DSn,DSn.PCS.OBJ[1],decode_durationを引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップＳ１６)。その後、OBJ[1]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[1].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１７)。
【００７４】
以上のアルゴリズムにより、Decode_Durationは算出される。このPCSのPTSが、具体的にどのように設定されるかについて説明する。
図１７（ａ）は、1つのwindowに1つのODSが存在するケースを想定した図である。図１７（ｂ）（ｃ）は、図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。本チャートには3つの段があり、これらの段のうち、”グラフィックスプレーンアクセス”の段、”ODSデコード”の段は、再生時にパラレルになされる2つの処理を示す。上述したアルゴリズムは、これらの2つの処理のパラレル実行を想定している。
【００７５】
グラフィックスプレーンアクセスは、クリア期間(1)、書き込み期間(3)からなる。このクリア期間(1)は、グラフィックスプレーン全体のクリアに要する期間(90,000×(グラフィックスプレーンのサイズ//256,000,000))、グラフィックスプレーンにおける全windowのクリアに要する時間(Σ(90,000×(window[i]のサイズ//256,000,000)))のどちらかを意味する。
【００７６】
書き込み期間(3)は、window全体描画に要する期間(90,000×(windowサイズ//256,000,000))を意味する。
一方、デコード期間(2)は、ODSのDTSからPTSまでに示される期間を意味する。 これらクリア期間(1)〜書き込み期間(3)は、クリアすべき範囲、デコードすべきODSのサイズ、グラフィックスプレーンに書き込むべきグラフィクスオブジェクトのサイズにより変化し得る。本図では、説明の簡略化のため、ODSのデコード期間(2)の始点は、クリア期間(1)の始点と同一であると仮定している。
【００７７】
図１７（ｂ）はデコード期間(2)が長くなるケースであり、Decode_Durationはデコード期間(2)＋書き込み期間(3)になる。
図１７（ｃ）は、クリア期間(1)が長くなるケースであり、Decode_Durationはクリア期間(1)＋書き込み期間(3)の期間がDecode_Durationになる。
図１８（ａ）〜（ｃ）は、1つのwindowに2つのODSが存在するケースを想定した図である。本図（ｂ）（ｃ）におけるデコード期間(2)は、2つのグラフィクスのデコードに要する期間の総和を意味する。グラフィクス書込期間(3)も、2つのグラフィクスをグラフィックスプレーンに書き込む期間の総和を意味する。ODSが2つになっているものの、図１７と同様に考えればDecode_Durationを算出することができる。2つのODSをデコードするためのデコード期間(2)が長い場合は、図１８（ｂ）に示すようにDecode_Durationはデコード期間(2)＋書き込み期間(3)に算出されることになる。
【００７８】
クリア期間(1)が長い場合は、図１８（ｃ）に示すように、Decode_Durationはクリア期間(1)＋書き込み期間(3)となる。
図１９（ａ）は、2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定している。この場合でもクリア期間(1)が、2つのODSをデコードするための総デコード期間(2)より長い場合、Decode_Durationはクリア期間(1)＋書き込み期間(3)になる。問題は、クリア期間(1)がデコード期間(2)より短くなるケースである。この場合デコード期間(2)の経過を待たずに、1つ目のwindowへの書き込みは可能になる。そのためクリア期間(1)＋書き込み期間(3)、デコード期間(2)＋書き込み期間(3)の長さにはならない。ここで1つ目のODSのデコードに要する期間を書込期間(31)、2つ目のODSのデコードに要する期間を書込期間(32)とする。図１９（ｂ）は、デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示す。この場合Decode_Durationは、デコード期間(2)＋書込期間(32)になる。
【００７９】
図１９（ｃ）は、クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示す。この場合Decode_Durationはクリア期間(1)＋書込期間(31)＋書込期間(32)になる。
グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またwindowのサイズ、ODSのサイズ、個数もオーサリングの段階で判明しているので、これらからDecode_Durationがクリア期間(1)＋書き込み期間(3)、デコード期間(2)＋書き込み期間(3)、デコード期間(2)＋書込期間(32)、クリア期間(1)＋書込期間(31)＋書込期間(32)のどれかになる。こうしたDecode_Duration算出を基にPCSのPTSを設定すれば、ピクチャデータとの同期表示を高い時間精度で実現することができる。このような高精度な同期制御は、windowを定義し、クリア・再描画する範囲を、このwindowに限定することで成り立っているので、オーサリングの環境に、このwindowの概念を導入したことの意義は大きい。
【００８０】
続いてDSnにおけるWDSのDTS、PTSの設定について説明する。WDSのDTSは、以下の数式を満たすように設定すればよい。
DTS(DSn[WDS])≧DTS(DSn[PCS])
一方、DSnにおけるWDSのPTSは、グラフィックスプレーンに対する書き込みを開始すべきデッドラインを示す。グラフィックスプレーンへの書き込みは、ウィンドゥだけで足りるので、PCSのPTSに示される時刻から、全てのウィンドウの書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。WDSの総サイズをΣSIZE(WDS.WIN[i])とすれば、これのクリア及び再描画に要する時間は、『ΣSIZE(WDS.WIN[i])//256,000,000』になる。そして、これを90.000KHzの時間精度で表現すると『90000×ΣSIZE(WDS.WIN[i])//256,000,000』になる。
【００８１】
故に以下の数式から、WDSのPTSを算出すればよい。
PTS(DSn[WDS])=PTS(DSn[PCS])-90000×ΣSIZE(WDS.WIN[i])//256,000,000
このWDSに示されるPTSはデッドラインなので、これより早い時点からグラフィックスプレーンの書き込みを開始してもよい。つまり図１９に示すように、2つのウィンドゥのうち、1つのウィンドゥに表示させるべきODSのデコードが完了したなら、その時点からデコードにより得られたグラフィクスオブジェクトの書き込みを開始してもよい。
【００８２】
このようにWDSに付加されたDTS、PTSを用いてAVClipの再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上がPCS、WDSのDTS、PTSの説明である。
続いてPCSによる前方参照について説明する。前方参照とは、前もって再生装置のメモリに読み込まれたグラフィクスオブジェクトを参照した再生制御をいう。図２０は、前方参照を行うPCSを描いた図である。本図では、DSn、DSn+1、DSn+2という3つのDisplay Setが描かれている。この中でDSn+1、DSn+2に属するPCSが「前方参照を行うPCS」である。本図の矢印yy1,yy2は、PCSにおける前方参照を象徴的に示す。かかる前方参照において参照先になっているグラフィクスオブジェクトは、DSn内のODS#u+1〜#vにより定義されるグラフィクスオブジェクトである。ここでDSnは、ODS#1〜#u、ODS#u+1〜#vという複数のグラフィクスオブジェクトを含む。このうちDSn内のPCSにより参照されているのは、ODS#1〜#uであり、ODS#u+1〜#vは参照されていない。つまりDSn内の非参照グラフィクスオブジェクトが前方参照されているのである。
【００８３】
以上のような前方参照では、PCSにより参照されているグラフィクスオブジェクトが前もって再生装置に読み込まれているので、同じDisplay Setに属するODSのデコードを待つ必要が無い。PCSを新たに送り込むだけで、そのPCSに基づく表示制御を再生装置に実行させることができる。PCSの読み込みに即応した表示制御が可能であるため、既に表示されているグラフィクスを、新たなグラフィクスを用いて更新するというグラフィクス更新を短い時間間隔で実行することができる。そして短い時間間隔でのグラフィクス更新を繰り返せば、動画像の再生進行と共にグラフィクスを滑らかに動かすという表示制御が可能になる。前方参照型のPCSにおける2つの記述例について説明する。
【００８４】
先ず初めに、画面上でグラフィクスが動きまわるような表示効果を実現するにあたってのPCSの記述について説明する。図２１（ａ）は、かかる表示効果を実現するEpochを示す図である。本Epochは、9つのDisplay Set(DS0〜DS8)からなり、先頭のDS0は、PCS、PDS、ODSを含む。DS0内のODSは、図２２（ａ）に示すような字幕「心が揺れる」を定義するものであり、object_id=1が付されている。後続するDS1〜DS8は、PCSのみを含む。
【００８５】
図２１（ｂ）は、DS1〜DS8に含まれるPCSの内容と、PTS値とを示す図である。本図に示すようにDS1〜DS8に属するPCS内の内容は、object_id_ref=1のグラフィクスオブジェクトを座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)に表示するよう、object_horizontal_position,object_vertivcal_positionの位置決めがなされている。これら座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)が、ウィンドゥの座標系のどこに存在するかを、具体的に示したのが図２２（ｂ）である。図２２（ｂ）において座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)は、波形を表す曲線上に存在していることがわかる。これら(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)という座標値は、WDSにて定義されるウィンドゥ内に、グラフィクスが収まるように規定されている。ウィンドゥ内に、グラフィクスが収まらないと、ビデオストリームにおける動画表示との同期を確立することができないからである。
【００８６】
図２１（ｂ）におけるPCSのPTS値は、座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)に対する表示を、再生時間軸上の時点t1,t2,t3・・・・t8のタイミングで命じるものである。
以上のように、PCSの内容が規定されたDS0〜DS8を順次再生装置に読み込んでゆくことにより、グラフィクスは、図２３のような表示効果をなす。動画ストリームの再生時間軸における時点t1において、再生装置にはDS1が読み込まれるので、ウィンドゥ内の座標(x1,y1)にグラフィクスが表示される。時点t4において再生装置にはDS4が読み込まれるので座標(x4,y4)にグラフィクスが表示されることになる。一方時点t6では、DS6が読み込まれるので座標(x6,y6)に、時点t8ではDS8が読み込まれるので座標(x8,y8)にグラフィクスが表示されることになる。これらの座標(x1,y1),(x4,y4),(x6,y6),(x8,y8)は、波形の曲線上に存在するので、かかる座標に表示位置の位置決めがなされたPCSにより、グラフィクスは、図２４に示すように波形の軌道を描くことになる。
【００８７】
以上のようにobject_horizontal_position,object_vertivcal_positionが規定されたPCSを含むDisplay Setを順次再生装置に読み込ませれば、再生装置はBD-ROMから読み出されてくるDS1、DS2、DS3内のPCSに従い、既にオブジェクトバッファに格納されているグラフィクスオブジェクトを、表示させることができる。制御情報の送り込みのみで、グラフィクスの位置を変化させることができるので、グラフィクスを目まぐるしく動かすという制御に適している。
【００８８】
個々のDisplay Setの読み出し時において、それまで参照していたPCSを、新たなPCSで上書きするとの動作を行えば、たとえ読み出すべきPCSが何十個、何百個あったとしても、そのうち最も新しいもののみ、再生装置に格納しておけばよい。滑らかな動きを実現するため、表示座標を示すPCSが、何十個、何百個必要であっても、そのうち最新のもののみ、再生装置に常駐させておけばよいので、再生装置におけるメモリ占有量を必要最低限にすることができる。
【００８９】
続いてPCSの第２の記述例としてPallet Only Updateについて説明する。図２５は、Pallet Only Updateを実現する一連のDisplay Setを示す図である。本図の第１段目は、Pallet Only Updateを実現する一連のDisplay Set(DS0、DS1、DS2、DS3)を示す。このうちDS0は、PCSと、3つのPDS0,1,2,3と、ODSとを含む。以降のDS2、DS3、DS4は、PCSのみからなる。
【００９０】
DS0内のODSは、引き出し線hv1に示すように、文字列「忘れない」を定義するものである。これら文字「忘」「れ」「な」「い」は、それぞれ複数のRun Length(図中の白抜きの四角形)から構成される。このうち文字「忘」を構成するRun Lengthは、PixelCode0をもっているものとする。文字「れ」,「な」,「い」を構成するRun Lengthは、PixelCode1,PixelCode2,PixelCode3をもっているものとする。
【００９１】
図２６（ａ）は、DS0内のPDSがどのような内容であるかを示す図である。
4つのPDSのうち、1つ目のPDS0は(第1段目)、pallet_id=0が付加されており、PixelCode0に赤色を、PixelCode1〜3に白色を割り当てるものである。
2つ目のPDS1は(第2段目)、pallet_id=1が付加されており、0,1,2のPixelCodeに赤色を、3以降のPixelCodeに白色を割り当てるものである。
【００９２】
3つ目のPDS2は(第3段目)、pallet_id=2が付加されており、0,1,2,3のPixelCodeに赤色を、4のPixelCodeに白色を割り当てるものである。
4つ目のPDS3は(第4段目)、pallet_id=3が付加されており、0,1〜4のPixelCodeに赤色を割り当てるものである。
図２６（ｂ）は、DS0〜DS3内のPCSを示す図である。
【００９３】
本図においてDS0内のPCSは(第1段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが0に設定され、Pallet_id_refが0に設定されている。これによりDS0内のODSは、Pallet_id=0で指示されるPDSを用いて、表示されることになる。
DS1内のPCSは(第2段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが1に設定されている。これは、DS1の読み込み時において、Pallet_id=1で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。
【００９４】
DS2内のPCSは(第3段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが2に設定されている。これは、DS2の読み込み時において、Pallet_id=2で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。]
DS3内のPCSは(第4段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが3に設定されている。これは、DS3の読み込み時において、Pallet_id=3で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。DS0〜DS3に属するPCSは、以上のように設定されているので、DS0に属するグラフィクスオブジェクトは、それぞれ別々のパレットデータを用いて、更新されてゆくことになる。
【００９５】
図２７は、これら4つのDisplay Setが読み込ませることで実現される、表示効果を現した図である。DS0に属するグラフィクスオブジェクトが再生装置に投入された段階で、字幕「忘れない」が表示され、それを構成する文字のうち、文字「忘」が赤色になる。次にDS1を投入した段階において、字幕「忘れない」を構成する文字のうち、文字「忘」,「れ」が赤色に、DS2を投入した段階で、文字「忘」,「れ」,「な」が赤色になる。そしてDS3を投入した段階で、全ての文字が赤色になる。Display Setが投入される毎に、字幕を構成する文字は、左に位置するものから順に、白色から赤色に変わってゆくので、音声の進行と共に、文字の色彩を代えてゆく表示効果を実現することができる。
【００９６】
これまでに説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-ray Disc Read Only Formatに規定された構文に従い、クラス構造体を記述することで、BD-ROM上のこれらのデータ構造を得ることができる。 以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２８は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置、マイコンシステムという3つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BDドライブ１、Read Buffer２、PIDフィルタ３、Transport Buffer４a,b,c、周辺回路４d、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、CLUT部９、加算器１０、グラフィクスデコーダ１２、Coded Data Buffer１３、周辺回路１３a、Stream Graphics Processor１４、Object Buffer１５、Composition Buffer１６、Graphical Controller１７から構成される。
【００９７】
BD-ROMドライブ１は、BD-ROMのローディング／リード／イジェクトを行い、BD-ROMに対するアクセスを実行する。
Read Buffer２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
PIDフィルタ３は、Read Buffer２から出力される複数TSパケットに対してフィルタリングを施す。PIDフィルタ３によるフィルタリングは、TSパケットのうち、所望のPIDをもつもののみをTransport Buffer４a,b,cに書き込むことでなされる。PIDフィルタ３によるフィルタリングでは、バッファリングは必要ではない。従って、PIDフィルタ３に入力されたTSパケットは、時間遅延なく、Transport Buffer４a,b,cに書き込まれる。
【００９８】
Transport Buffer４a,b,cは、PIDフィルタ３から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。このTransport Buffer４aからTSパケットが取り出される速度を速度Rxとする
周辺回路４dは、Transport Buffer４a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCoded Data Buffer１３に格納される。
【００９９】
ビデオデコーダ５は、PIDフィルタ３から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、PIDフィルタ３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
【０１００】
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
CLUT部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
【０１０１】
加算器１０は、CLUT部９により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
【０１０２】
グラフィクスデコーダ１２によるパイプラインは、DSnに属するグラフィクスオブジェクトをObject Buffer１５に書き込む処理、DSn+1に属するグラフィクスオブジェクトをObject Buffer１５から読み出す処理を同時に実行することでパイプラインは実行される。
このグラフィクスデコーダ１２は、Coded Data Buffer１３、周辺回路１３a、Stream Graphics Processor１４、Object Buffer１５、Composition Buffer１６、Graphical Controller１７から構成される。
【０１０３】
Coded Data Buffer１３は、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、Transport Buffer４a,b,cに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS／DTSは、PESパケットと対応付けて格納される。
【０１０４】
周辺回路１３aは、Coded Data Buffer１３−Stream Graphics Processor１４間の転送、Coded Data Buffer１３−Composition Buffer１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がODSのDTSに示される時刻になれば、ODSを、Coded Data Buffer１３からStream Graphics Processor１４に転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをComposition Buffer１６に転送するという処理を行う。
【０１０５】
Stream Graphics Processor１４は、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObject Buffer１５に書き込む。Stream Graphicsプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをStream Graphicsプロセッサ１４は一時的に保持する。Stream Graphicsプロセッサ１４によるデコードは瞬時になされるが、Stream Graphicsプロセッサ１４からObject Buffer１５への書き込みは、瞬時には終わらない。BD-ROM規格のプレーヤモデルでは、Object Buffer１５への書き込みは、128Mbpsという転送レートでなされるからである。Object Buffer１５への書き込み完了時点は、ENDセグメントのPTSに示されているので、このENDセグメントのPTSに示される時点が経過するまで、次のDSに対する処理を待つことになる。各ODSをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。
【０１０６】
書き込み時にあたってDSn側のグラフィックスデータと、DSn+1側のグラフィックスデータとに割り当てられているobject_idが別々の場合、Stream Graphicsプロセッサ１４はDSn側のグラフィックスデータと、DSn+1側のグラフィックスデータとを、Object Buffer１５における別々の領域に書き込む。これによりDSnのPCSにより参照されるグラフィクスオブジェクトは、DSn+1に属するグラフィクスオブジェクトにより上書きされることなく、パイプラインで表示に供される。両グラフィクスオブジェクトに割り当てられているobject_idが同じである場合、前記Stream Graphicsプロセッサ１４は、Object Buffer１５において先行DS側のグラフィックスデータが格納されている領域と同じ領域に、後続DS側のグラフィックスデータを上書きする。かかる場合、パイプラインは行わない。またDSに属するグラフィクスオブジェクトには、同一DSのPCSにより参照されているものと、参照されていないものとがある。Stream Graphicsプロセッサ１４は、PCSにより参照されているグラフィクスオブジェクトだけでなく、参照されてないグラフィクスオブジェクトを逐次デコードして、デコードにより得られたグラフィクスをObject Buffer１５に格納する。
【０１０７】
Object Buffer１５は、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor１４のデコードにより得られたグラフィクスオブジェクトが配置される。Object Buffer１５は、グラフィクスプレーン８の2倍／4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン８の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【０１０８】
Composition Buffer１６は、PCS、PDSが配置されるメモリである。−−処理すべきDisplay Setが2つあり、これらの有効区間が重複している場合、Compositionバッファ１６には処理すべきPCSが複数格納される。
Graphical Controller１７は、Graphicalコントローラ１７はPCSの解読を行い、PCSの解読結果に従って、グラフィクスオブジェクトのObject Buffer１５への書き込み、及び、Object Buffer１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Graphicalコントローラ１７による表示は、PCSを格納したPESパケットのPTSに示される時点において実行される。
【０１０９】
PCSを用いた画面構成を実行するにあたって、Graphicsコントローラ１７は以下の処理を行う。Graphicsコントローラ１７は、オブジェクトCに記述されたグラフィクスオブジェクト識別子の参照値(object_id_ref)を読み取り、そのobject_id_refにより指示されるグラフィクスオブジェクトのうち、object_cropping_horizontal_position,object_cropping_vertical_positionから、object_cropping_width、object_cropping_heightに示されるクロップ範囲を切り出して、グラフィックスプレーンのobject_horizontal_position,object_vertical_positionにより示される位置に書き込む。この参照値が、PCSと同じDisplay Setに属するグラフィクスオブジェクトを表している場合、同じDisplay Setに属するODSがデコードされた後でないと、上述したグラフィックスプレーンへの書き込みは行えない。
【０１１０】
一方、オブジェクトCが属するDisplay SetのComposition_stateがNormal Caseである場合、デコードにより得られたグラフィクスオブジェクトが、前もってオブジェクトバッファ内に格納されているので、ODSのデコードを待つことなく、上述したグラフィックスプレーンへの書き込みを行うことができる。
PalletOnly Displey Update時におけるGraphicsコントローラ１７の読み出し処理は以下の通りである。Display Setが、BD-ROMから読み出された場合、Graphicsコントローラ１７は、PCSのPallette_update_flagが、”1”であるか否かを判定する。もし1であるなら、PCSのpallet_idに記述されているパレットデータを用いた画素値変換を、CLUT部９に命じた上で、Object Buffer１５からグラフィクスオブジェクトを読み出し、グラフィクスプレーン８に格納させてゆく。CLUT部９に対するパレットデータの設定のみを行うことで、グラフィクスの更新を行うのである。
【０１１１】
続いて、PIDフィルタ３、Transport Buffer４a,b,c、グラフィクスプレーン８、CLUT部９、Coded Data Buffer１３〜Graphical Controller１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２９は、書込レートRx,Rc,Rd、グラフィクスプレーン８、Transport Buffer４a、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【０１１２】
Object Buffer１５−グラフィクスプレーン８間の転送レートRcは、本装置において最も高い転送レートであり、ウィンドゥサイズ、フレームレートから256Mbps(=500Kバイト×29.97×2)と算出される。
Stream Graphics Processor１４−Object Buffer１５間の転送レートRd(Pixel Decoding Rate)は、Rcとは異なり、ビデオフレームの周期によるアップデートは要求されずRcの1/2,1/4でよい。故に128Mbps,64Mbpsになる。
【０１１３】
Transport Buffer４a,b,c−Coded Data Buffer１３間のTransport Buffer LeakレートRxは、圧縮状態たるODSの転送レートである。従ってTransport Buffer Leakレートは、Rdに圧縮率を乗じた転送レートでよい。ODSの圧縮率を25%と仮定すれば、16Mbps(=64Mbps×25%)で足りる。
この図に示す転送レート、バッファ規模はあくまでもミニマムスタンダードであり、これより大きい値での実装を否定している訳ではない。
【０１１４】
以上のように構成された再生装置において、各構成要素はパイプライン式にデコード処理を行うことができる。
図３０は、再生装置によるパイプライン処理を示すタイミングチャートである。第５段目は、BD-ROMにおけるDisplay Setを示し、第４段目は、Coded Data Buffer１３へのPCS、WDS、PDS、ODSの読出期間を示す。第３段目は、Stream Graphics Processor１４による各ODSのデコード期間を、第２段目はComposition Buffer１６の格納内容を、第１段目はGraphical Controller１７の処理内容を示す。
【０１１５】
ODS1,2に付与されたDTS(デコード開始時刻)は、図中のt31,t32の時点を示している。デコード開始時刻がDTSに規定されているので、各ODSは、自身のDTSに示される時刻までにCoded Data Buffer１３に読み出されなければならない。そのためODS1の読み出しは、Coded Data Buffer１３へのODS1のデコード期間dp1の直前までに完了している。Coded Data Buffer１３へのODS2の読み出しは、ODS2のデコード期間dp2の直前までに完了している。
【０１１６】
一方、ODS1,2に付与されたPTS(デコード終了時刻)は、図中のt32,t33の時点を示している。Stream Graphics Processor１４によるODS1のデコードはt32までに完了し、ODS2のデコードは、t33に示される時刻までに完了する。以上のように、Stream Graphics Processor１４は、各ODSのDTSに示される時刻までに、ODSをCoded Data Buffer１３に読み出し、Coded Data Buffer１３に読み出されたODSを、各ODSのPTSに示される時刻までに、デコードしてObject Buffer１５に書き込む。
【０１１７】
本図の第１段目における期間cd1は、Graphics Controller１７がグラフィクスプレーン８をクリアするのに要する期間である。また期間td1は、Object Buffer１５上にえられたグラフィクスオブジェクトを、グラフィクスプレーン８に書き込むのに要する期間である。WDSのPTSは、この書き込みの開始にあたってのデッドラインを示し、PCSのPTSはこの書き込みの終了時点及び表示タイミングを示す。このPCSのPTSに示される時点になれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン８上に得られることになる。この非圧縮グラフィクスの色変換をCLUT部９に行わせ、ビデオプレーン６に格納されている非圧縮ピクチャとの合成を加算器１０に行わせれば、合成画像が得られることになる。
【０１１８】
グラフィクスデコーダ１２において、Graphics Controller１７がグラフィクスプレーン８のクリアを実行している間においても、Stream Graphics Processor１４のデコードは継続して行われる。以上のようなパイプライン処理により、グラフィクスの表示を迅速に実施することができる。
図３０では、グラフィックスプレーンのクリアが、ODSのデコードより早く終わる場合を想定したが、図３１は、ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。この場合、ODSのデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
【０１１９】
再生装置におけるバッファ占有量の時間的遷移について図３２を参照しながら説明する。図３２は、図２８におけるCompositionバッファ１６、Object Buffer１５、Coded Dataバッファ１３、グラフィクスプレーン８の時間的遷移を示すタイミングチャートである。本図は、第１段目から第４段目までに、グラフィクスプレーン８、Object Buffer１５、Coded Dataバッファ１３、Compositionバッファ１６における占有量の時間的遷移を示している。この占有量の時間的遷移は、横軸を時間軸とし、縦軸を占有量とした折れ線グラフの表記で表現している。
【０１２０】
図３２の第４段目は、Compositionバッファ１６における占有量の時間的遷移を示す。本図に示すようにCompositionバッファ１６の時間的遷移は、Coded Dataバッファ１３から出力されPCSが格納されることによる単調増加vf0を含む。
第３段目は、Coded Dataバッファ１３における占有量の時間的遷移を示す。本図に示すようにCoded Dataバッファ１３の時間的遷移は、ODSが格納されることによる単調増加Vf1,Vf2と、格納されたODSが順次Stream Graphicsプロセッサ１４により取り出されることによる単調減少Vg1,Vg2とを含む。単調増加Vf1,Vf2の傾きは、Transportバッファ４a,b,cからCoded Dataバッファ１３への出力レートRxに基づき、単調減少Vg1,Vg2の傾きは、Stream Graphicsプロセッサ１４によるデコードであり、瞬時に実行される。つまりODSに対するデコードは瞬時に行われ、Stream Graphicsプロセッサ１４は、デコードにより得られた非圧縮グラフィクスを保持する。Stream Graphicsプロセッサ１４からObject Buffer１５への伝送路の書込レートは128Mbpsであるため、この書込レートにより、Object Buffer１５の占有量は増加する。
【０１２１】
第２段目は、Object Buffer１５における占有量の時間的遷移を示す。本図に示すようにObject Buffer１５の時間的遷移は、Stream Graphicsプロセッサ１４から出力されたODSが格納されることによる単調増加Vh1,Vh2を含む。単調増加Vh1,Vh2の傾きは、Stream Graphicsプロセッサ１４からObject Buffer１５への転送レートRdに基づく。第３段目の単調減少が生じる期間及びの第２段目の単調増加が生ずる期間が、デコード期間である。このデコード期間の始期は、ODSのDTSに示されており、デコード期間の終期は、ODSのPTSに示されている。このODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer１５に格納されれば、ODSに対するデコードは完了したことになる。ODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer１５に格納されることが、必須の要件であり、このデコード期間における単調増加、単調減少はどのようなものであってもよい。
【０１２２】
第１段目は、グラフィクスプレーン８における占有量の時間的遷移を示す。本図に示すようにグラフィクスプレーン８の時間的遷移は、Object Buffer１５から出力されたデコード済みODSが格納されることによる単調増加Vf3を含む。単調増加Vf3の傾きは、Object Buffer１５からグラフィクスプレーン８への転送レートRcに基づく。この単調増加の終期は、PCSのPTSに示されている。
【０１２３】
ODSに付与されたDTS、PTS、ICSに付与されたDTS、PTS、そして図２９に示した各バッファのサイズ、転送レートを用いれば、本図のようなグラフを作図することにより、BD-ROMにて供給すべきAVClipの再生時において、各バッファの状態がどのように変化するかが、オーサリングの段階で明らかになる。
このバッファ状態の遷移は、DTS、PTSに示される値を書き換えることで、調整することが可能なので、再生装置側のデコーダのスペックを越えるような復号負荷の発生を回避したり、再生にあたってのバッファオーバーフローの回避することができる。そのため再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
【０１２４】
以上が再生装置の内部構成である。続いてグラフィクスコントローラ１７を、どのようにして実装するかについて説明する。グラフィクスコントローラ１７は、図３３の処理手順を行うプログラムを作成し、CPUに実行させることにより実装可能である。以降、図３３を参照しながら、グラフィクスコントローラ１７の処理手順について説明する。
図３３は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(PCS,WDS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップＳ２１〜Ｓ２４、ステップＳ２７〜Ｓ３１の処理を全てのSegmentKについて繰り返すループ構造を有している(ステップＳ２５、ステップＳ２６)。
【０１２５】
ステップＳ２１は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップＳ２７、ステップＳ２８の判定を行う。
ステップＳ２２は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップＳ２３に移行し、1であるならステップＳ２４に移行する。無視フラグが1であれば(ステップＳ２２でNo)、ステップＳ２３においてSegmentKをCoded Data Buffer１３にロードする。
【０１２６】
無視フラグが0に設定されていれば(ステップＳ２２がNo)、ステップＳ２４においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップＳ２２がNoになって、無視されることになる(ステップＳ２４)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
【０１２７】
ステップＳ２７は、PCSにおけるcomposition_stateがAcquisition Pointであるか否かの判定である。SegmentKがAcquisition Pointであるなら、ステップＳ２８に移行し、SegmentKがもしEpoch StartかNormal Caseであるなら、ステップＳ３１に移行する。
ステップＳ２８は、先行するDSがグラフィクスデコーダ１２内のどれかのバッファ(Coded Data Buffer１３、Stream Graphicsプロセッサ１４、Object Buffer１５、Composition Buffer１６)に存在するかどうかの判定であり、ステップＳ２７がYesである場合に実行される。グラフィクスデコーダ１２内にDSが存在しないケースとは、頭出しがなされたケースをいう。この場合、Acquisition PointたるDSから、表示を開始せねばならないので、ステップＳ３０に移行する(ステップＳ２８でNo)。
【０１２８】
ステップＳ３０は、無視フラグを0に設定し、ステップＳ２２に移行する。
グラフィクスデコーダ１２内にDSが存在するケースとは、通常再生がなされたケースをいう。この場合、ステップＳ２９に移行する(ステップＳ２８でYes)。ステップＳ２９は、無視フラグを1に設定し、ステップＳ２２に移行する。
ステップＳ３１は、PCSにおけるcomposition_stateがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップＳ３４に移行する。SegmentKがEpoch Startであるなら、ステップＳ３０において無視フラグを0に設定する。 ステップＳ３４は、ステップＳ２８と同じであり、先行するDSがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップＳ３０)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップＳ３５)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ１２に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
【０１２９】
DSが、図３４のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図３４の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、composition_stateがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図３３のフローチャートの対象となる。ステップＳ２７においてcomposition_stateはAcquisition Pointと判定されるが、先行するDSはCoded Data Buffer１３上に存在しないため、無視フラグは0に設定され、このDS10が図３５の矢印md1に示すように再生装置のCoded Data Buffer１３にロードされる。一方、頭出し位置がDS10の存在位置より後である場合(図３４の矢印am2)、DS20は、Normal CaseのDisplay Setであり、先行するDS20はCoded Data Buffer１３に存在しないので、このDisplay Setは、無視されることになる(図３５の矢印md2)。
【０１３０】
図３６のように通常再生が行われた場合のDS1,10,20のロードは、図３６に示すものとなる。3つのDSのうち、PCSのcomposition_stateがEpoch StartであるDS1は、そのままCoded Data Buffer１３にロードされるが(ステップＳ２３)、PCSのcomposition_stateがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップＳ２９)、これを構成する機能セグメントはCoded Data Buffer１３にロードされず無視される(図３７の矢印rd2,ステップＳ２４)。またDS20については、PCSのcomposition_stateはNormal Caseなので、Coded Data Buffer１３にロードされる(図３７の矢印rd3)。
【０１３１】
続いてGraphical Controller１７の処理手順について説明する。図３８〜図４０は、Graphical Controller１７の処理手順を示すフローチャートである。
ステップＳ４１〜ステップＳ４４は、本フローチャートのメインルーチンであり、ステップＳ４１〜ステップＳ４４に規定した何れかの事象の成立を待つ。
ステップＳ４１は、現在の再生時点がPCSのDTS時刻になっているか否かの判定であり、もしなっていれば、ステップＳ４５〜ステップＳ５３の処理を行う。
【０１３２】
ステップＳ４５は、PCSのcomposition_stateが、Epoch_Startであるか否かの判定であり、もしEpoch Startであるなら、ステップＳ４６においてグラフィクスプレーン８を全クリアする。それ以外であるなら、ステップＳ４７においてWDSのwindow_horizontal_position、window_vertival_position、window_width、window_heightに示されるwindowをクリアする。
【０１３３】
ステップＳ４８は、ステップＳ４６又はステップＳ４７でのクリア後の実行されるステップであり、任意のODSxのPTS時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン８全体のクリアにあたっては、そのクリア時間に長時間を費するので、あるODS(ODSx)のデコードが既に完了していることもある。ステップＳ４８はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかのODSのデコード時刻を経過しているなら、ステップＳ４９〜ステップＳ５１を実行する。ステップＳ４９は、object_cropped_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５０)。
【０１３４】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ５１)。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３５】
ステップＳ５２は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン８に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして(ステップＳ５３)、ステップＳ４９に移行する。これにより、別のODSに対しても、ステップＳ４９〜Ｓ５１の処理が繰り返し行われる。
次に図３９を参照して、ステップＳ４２、ステップＳ５４〜ステップＳ５９について説明する。
【０１３６】
ステップＳ４２は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップＳ５４においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップＳ５５〜ステップＳ５９のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップＳ５７〜ステップＳ５９を実行するというものである。ステップＳ５７は、object_cropped_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５８)。
【０１３７】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ５９)。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３８】
ステップＳ４４は、現在の再生時点がPCSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップＳ６０においてPallet_update_flagが1を示しているか否かを判定する。もし1を示しているなら、pallet_idに示されるPDSをCLUT部に設定する(ステップＳ６１)。0を示しているなら、ステップＳ６１をスキップする。
その後、グラフィクスプレーン８におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する(ステップＳ６２)。
【０１３９】
次に図４０を参照して、ステップＳ４３、ステップＳ６４〜ステップＳ６６について説明する。
ステップＳ４３は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップＳ６３においてウィンドゥが2つであるか否かを判定する。もし1つであれば、メインルーチンにリターンする。
【０１４０】
ステップＳ４３及びステップＳ６３の判定は以下の意味をもつ。つまりウィンドゥが2つある場合、それぞれのウィンドゥには、1つずつグラフィクスオブジェクトが表示される。そうすると、それぞれのODSのデコードが完了する度に、デコードにより得られたグラフィクスオブジェクトを、グラフィックスプレーンに書き込んでゆく処理が必要になる(例:図１９（ｂ）のケース)。そこで現在時点がODSのPTSに示される時点であり、ウィンドゥが2つであるなら、個々のグラフィクスオブジェクトをグラフィックスプレーンに書き込むべく、ステップＳ６４〜ステップＳ６６を実行する。ステップＳ６４は、object_cropped_flagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ６５)。
【０１４１】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ６６)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
【０１４２】
(第２実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図４１は、第１実施形態に示したPCSを作成するための製造工程を示す図である。
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程Ｓ２０３を含む。
【０１４３】
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１０を含む。
ステップＳ２０４において制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５では、制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを機能セグメントに変換する。そしてステップＳ２０６において同期したいピクチャが出現するタイミングに基づき、PCSのPTSを設定し、ステップＳ２０７では、PTS[PCS]の値に基づき、DTS[ODS],PTS[ODS]を設定する。ステップＳ２０８において、DTS[ODS]の値に基づき、DTS[PCS],PTS[PDS],DTS[WDS],PTS[WDS]を設定し、ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのDTS、PTSを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してAVClipを得る。以降、AVClipをBD-ROMのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
【０１４４】
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の［技術分野］の、出願当時の技術水準の特性に基づく。
【０１４５】
(A)全ての実施形態では、本発明に係る記録媒体をBD-ROMとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレシキブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。
【０１４６】
(B)全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムLSI(集積回路)のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、第１実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１４７】
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１４８】
(E)BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arribval_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”Aligned Unit”という。
【０１４９】
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、Aligned Unitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArribval_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
【０１５０】
(F)各実施形態におけるデジタルストリームは、BD-ROM規格のAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(Video Object)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。
【０１５１】
(G)各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１５２】
(H)第１実施形態〜第２実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いているからである。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはPNGデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１５３】
(I)PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
またPCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBD-ROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
【０１５４】
(J)第１実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25%に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
【０１５５】
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。
(K)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
【０１５６】
(L)グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、動画と緻密に同期して表示されるものであればなんであってもよい。例えばイラストや絵柄、キャラクタ、シンボルマークを描いたものであってもよい。商標を構成するような図形,文字,色彩の組合せや、国の紋章,旗章,記章,国家が採用する監督/証明用の公の記号・印章、政府間国際機関の紋章,旗章,記章,特定商品の原産地表示を含んでいてもよい。
【０１５７】
(M)第１実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
(O)グラフィクスデコーダ１２が、DSn及びDSn+1に対する処理をパイプライン式に行うのは、DSn及びDSn+1が、グラフィクスストリームにおける同じEpochに帰属している場合であり、前記DSn及びDSn+1が、互いに異なるEpochに属している場合、DSnにおけるグラフィクス表示を開始した後に、DSn+1に対する処理を開始する。
【０１５８】
またグラフィクスストリームには、動画との同期を主たる目的としたプレゼンテーション系のものと、対話的な表示を主目的としたインタラクティブ系のものとがあり、前記グラフィクスデコーダは、グラフィクスストリームがプレゼンテーション系である場合に、2つのDSに対するパイプライン式を行い、グラフィクスストリームがインタラクティブ系である場合、2つのDSに対するパイプライン式を行わない。
【０１５９】
(P)Display Set内にグラフィクスデータを配列させるにあたって、図２０では、同じDisplay Set内のPCSにより参照されるグラフィクスデータを、参照されないグラフィクスデータの前に配列したが、複数の参照グラフィクスデータ、及び、複数の非参照グラフィクスデータを、それぞれ、object_idにより指示される識別番号順に配列してもよい。また複数の参照グラフィクスデータは、スキャンライン順に配列してもよい。スキャンラインとは、ディスプレイでの表示時において、走査される順番を表す。通常ディスプレイにおける走査は、左上→右下方向に向けてなされるから、表示座標が左上にあるグラフィクスデータを前に、表示座標が右下にあるグラフィクスデータを後に配置するのである。こうすることで、グラフィクスデータ表示の迅速化を図ることができる。
【０１６０】
上述した変更実施は可能であるものの、請求項に係る各発明は、従来技術の技術的課題を解決するための手段を反映したものであるから、請求項に係る各発明の技術範囲は、従来技術の技術的課題解決が当業者により認識される技術範囲を超えることはない。故に、本願の請求項に係る各発明は、詳細説明の記載と、実質的な対応関係を有する。
【産業上の利用可能性】
【０１６１】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき工業的に量産することが可能なので、資質において工業上用することができる。このことから本発明に係る再生装置は、産業上利用可能性を有する。
【図面の簡単な説明】
【０１６２】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの構成を示す図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】字幕の表示位置と、Epochとの関係を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトの定義を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造を示す図である。
【図９】字幕表示を実現するためのDisplay Setの記述例である。
【図１０】DS1におけるWDS、PCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DS3におけるPCSの記述例を示す図である。
【図１３】図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。
【図１４】decode_durationの計算アルゴリズムの一例を示す図である。
【図１５】図１４のプログラムのアルゴリズムを図式化したフローチャートである。
【図１６】（ａ）（ｂ）図１４のプログラムのアルゴリズムを図式化したフローチャートである。
【図１７】（ａ）1つのwindowに1つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図１８】（ａ）1つのwindowに2つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図１９】（ａ）2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定したタイミングチャートである。 （ｂ）デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示すタイミングチャートである。 （ｃ）クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示すタイミングチャートである。
【図２０】前方参照を行うPCSを描いた図である。
【図２１】（ａ）DS1〜DS8に含まれるPCSの内容と、PTS値とを示す図である。 （ｂ）グラフィクスが画面内を動き回るという表示効果を実現するEpochを示す図である。
【図２２】（ａ）DS0内のODSを示す図である。 （ｂ）座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)が、ウィンドゥの座標系のどこに存在するかを示す図である。
【図２３】各Display Setに属する各機能セグメントのタイムスタンプに対する設定を示す図である。
【図２４】アップデートの、時間的変遷の具体例を示す図である。
【図２５】Pallet Only Updateを実現する一連のDisplay Setを示す図である。
【図２６】（ａ）DS0内のPDS及び各Display SetのPCSがどのような内容であるかを示す図である。 （ｂ）DS0〜DS3内のPCSを示す図である。
【図２７】4つのDisplay Setが読み込ませることで実現される、表示効果を現した図である。
【図２８】本発明に係る再生装置の内部構成を示す図である。
【図２９】書込レートRx,Rc,Rd、グラフィクスプレーン８、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【図３０】再生装置によるパイプライン処理を示すタイミングチャートである。
【図３１】ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。
【図３２】Compositionバッファ１６、Object Buffer１５、Coded Dataバッファ１３、グラフィクスプレーン８における蓄積量の時間的遷移を示すタイミングチャートである。
【図３３】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図３４】スキップ操作がなされる一例を示す図である。
【図３５】図３４においてスキップ操作がなされた際、DS10が再生装置のCoded Data Buffer１３にロードされる様子を示す図である。
【図３６】通常再生が行われる場合を示す図である。
【図３７】図３６のように通常再生が行われた場合のDS1,10,20のロードを示す図である。
【図３８】Graphical Controller１７の処理手順を示すフローチャートである。
【図３９】Graphical Controller１７の処理手順を示すフローチャートである。
【図４０】Graphical Controller１７の処理手順を示すフローチャートである。
【図４１】第１実施形態に示したPCSが記録されたBD-ROMを製造するための製造工程を示す図である。
【符号の説明】
【０１６３】
１ BDドライブ１、
２ Read Buffer
３ PIDフィルタ
４a,b,c Transport Buffer
４d 周辺回路
５ ビデオデコーダ
６ ビデオプレーン
７ オーディオデコーダ
８ グラフィクスプレーン
９ CLUT部
１０ 加算器
１２ グラフィクスデコーダ
１３ Coded Data Buffer
１３a 周辺回路
１４ Stream Graphics Processor
１５ Object Buffer
１６ Composition Buffer
１７ Graphical Controller
１００ BD-ROM
２００ 再生装置
３００ テレビ
４００ リモコン
【技術分野】
【０００１】
本発明は、動画ストリーム及びグラフィクスストリームが多重化されたデジタルストリームが記録されている記録媒体と、そのデジタルストリームを再生する再生装置とに関し、特に動画ストリーム及びグラフィクスストリームを再生装置が別個にデコードし、そのデコードにより得られた映像−グラフィクスを合成することで、再生映像を得る技術に関する。
【背景技術】
【０００２】
上述した合成技術は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択して表示することもできる。また必要に応じてグラフィクスを表示したり、消したりという選択も可能である。これらの選択が可能なので、かかる技術は、DVD-Video規格やETSI EN 300 743標準規格のプレーヤモデルに採用されている。上記規格技術においてグラフィクスストリームは、PESパケットの配列であり、PESパケットには、制御情報を格納したもの、グラフィクス本体たるグラフィクスデータを格納したものの2種類がある。制御情報は、グラフィクスデータより前に配置されており、制御情報及びグラフィクスデータの一対で一個のグラフィクス表示を実現する。具体的にいうと、再生装置は制御情報及びグラフィクスデータが順次読み込み、制御情報を解読すると共に、グラフィクスデータをデコードし、デコードにより得られた非圧縮グラフィクスを、制御情報の解読結果に従い、所望の表示タイミングで表示する。
【０００３】
かかるグラフィクス表示の先行技術には、以下の特許文献に記載されたものがある。
【特許文献１】特許第328220号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
以上のようなグラフィクス表示にあたっては、グラフィクス表示の度に、グラフィクスデータのデコードを行う必要があるので、1つのグラフィクス表示から、次のグラフィクス表示までの間隔は、グラフィクスデータのデコード期間に依存したものとなる。ここでグラフィクスの解像度が高く、デコード期間が長ければ長いほど、グラフィクスの更新間隔も長くなってしまう。
【０００５】
映画における字幕のように、グラフィクスが2〜3秒という時間間隔で更新されるのであれば、多少、グラフィクスの解像度が高く、デコード期間が長くなったとしても問題はない。しかし、アミューズメントの用途にグラフィクスを使用しようとする場合、グラフィクスの表示間隔をもっと短くしたいという要望がでてくる。
ここでアミューズメントの用途とは、登場人物の台詞を示すグラフィクスに、独特の動きを与えて、視聴者の注意をひいたり、色彩を派手に変化させることで、視聴者の意表を突くというものである。かかるグラフィクス表示の実現は、バラエティ色が濃い映像コンテンツの制作現場からの要望が特に強い。
【０００６】
しかしグラフィクスの滑らかな動きを実現するには、グラフィクスをデコードし、表示するという処理を、ディスプレィの一表示期間(NTSC方式の場合は1/29.97sec)という僅かな期間が経過する毎に、行う必要がある。ディスプレィの一表示期間が経過する度に、グラフィクスのデコード−表示を繰り返すというのは、多大な負荷であり、低コストでの普及を想定しているような再生装置のハードウェアスペックでは実現が困難である。
【０００７】
無論、上述したようなグラフィクス動きや色彩変化は、動画像の一コマ一コマにグラフィクスを予め合成しておき、各コマの絵柄の一部としてグラフィクスを取り扱うことで実現可能である。しかし一コマ一コマに、グラフィクスを予め合成しておくといく方法は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択的に表示するという、融通性を欠く。そのため、かかる方法を採用している限り、将来への展望は見えてこない。
【０００８】
本発明の目的は、グラフィクスを、動画のような滑らかさで動かすことができる記録媒体を提供することである。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明にかかる記録媒体は、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、前記パレットデータは、各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、前記制御データは、前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させることを特徴としている。
【発明の効果】
【００１０】
上述した構成において、制御データは、パケット列において自身より前方に存在するグラフィクスデータの表示色を、所定のタイミングで変換する旨を示している。そのため、パレットデータを指定する制御データのみを再生装置に送り込むだけでグラフィクスの色彩を変化させるという制御を再生装置に行わせることができる。制御データを送り込むだけで、グラフィクス表示を更新することができるので、グラフィクスの表示と、動画の再生との同期が容易になる。
【００１１】
このため、アミューズメントの用途、つまり、登場人物の台詞の色彩を派手に変化させることで、視聴者の意表を突くという用途にグラフィクスを利用することができ、バラエティ色が濃い映像コンテンツの制作現場からの要望を満たすことができる。
【発明を実施するための最良の形態】
【００１２】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、BD-ROM１００である。このBD-ROM１００は、再生装置２００、テレビ３００、リモコン４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００１３】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、BD-ROMの応用層に対する改良により実施することができる。図２は、BD-ROMの構成を示す図である。
本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。本図に示すようにBD-ROMには、ROOTディレクトリの下にBDMVディレクトリがあり、BDMVディレクトリの配下には、AVClipを格納したファイル(XXX.M2TS)、AVClipの管理情報を格納したファイル(XXX.CLPI),AVClipにおける論理的な再生経路(PL)を定義したファイル(YYY.MPLS)が存在する。本図に示すようなアプリケーションフォーマットを作成することにより、本発明に係る記録媒体は生産される。尚、XXX.M2TS、XXX.CLPI,YYY.MPLSといったファイルが、それぞれ複数存在する場合は、BDMVディレクトリの配下に、STREAMディレクトリ、CLIPINFディレクトリ、PLAYLISTディレクトリという3つのディレクトリを設け、STREAMディレクトリにXXX.M2TSと同じ種別のファイルを、CLIPINFディレクトリにXXX.CLPIと同じ種別のファイルを、PLAYLISTディレクトリにYYY.MPLSと同じ種別のファイルを格納することが望ましい。
【００１４】
このアプリケーションフォーマットにおけるAVClip(XXX.M2TS)について説明する。
AVClip(XXX.M2TS)は、MPEG-TS(Transport Stream)形式のデジタルストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、プレゼンテーショングラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、プレゼンテーショングラフィクスストリームは、映画の字幕をそれぞれ示している。図３は、AVClipがどのように構成されているかを模式的に示す図である。
【００１５】
AVClipは(中段)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(上１段目)、PESパケット列に変換し(上２段目)、更にTSパケットに変換し(上３段目)、同じくプレゼンテーショングラフィクスストリーム(下１段目)を、PESパケット列に変換し(下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００１６】
本図において多重されるプレゼンテーショングラフィクスストリームは1つであるが、BD-ROMが多言語対応型である場合、その言語毎のプレゼンテーショングラフィクスストリームがAVClipに多重される。かかる過程を経て生成されたAVClipは、通常のコンピュータファイル同様、複数のエクステントに分割され、BD-ROM上の領域に記録される。
続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。
【００１７】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、PCS(Presentation Composition Segment)、WDS(Window Define Segment)、PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、PCSは、画面構成セグメントと呼ばれ、WDS,PDS,ODS,ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。
【００１８】
図４（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図４（ｂ）に示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。
【００１９】
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にDisplay Setを、第１段目にEpochをそれぞれ示す。
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線は、第３段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。
【００２０】
第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう(※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。)。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像−グラフィクスの同期は保証されない。
【００２１】
Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図６は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当は」「ウソだった」「ごめん」「あれから」「3年がたった」のうち、3つの字幕「本当は」「ウソだった」「ごめん」は画面の下側に、「あれから」「3年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplay Setについて説明する。
【００２２】
図５における破線hk1,2は、第２段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。Epoch Start,Acquisition Point,Normal Caseという一連のDSは、第１段目のEpochを構成していることがわかる。『Epoch Start』、『Acquisition Point』、『Normal Case』は、DSの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。
【００２３】
『Epoch Start』は、”新表示”という表示効果をもたらすDSであり、新たなEpochの開始を示す。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。Epoch Startは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、”表示リフレッシュ”という表示効果をもたらすDisplay Setであり、先行するEpoch Startと全く同じDisplay Setをいう。Acquisition PointたるDSは、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、Acquisition PointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。
【００２４】
Acquisition PointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisition Pointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【００２５】
『Normal Case』は、”表示アップデート”という表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvの字幕は、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、PCSと、ENDのみのDSvを設けてこのDSvをNormal CaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。一方、Normal CaseのDSは、差分にすぎないので、Normal Case単独では画面構成は行えない。
【００２６】
続いてDefinition Segment(ODS,WDS,PDS)について説明する。
『Object_Definition_Segment』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。BD-ROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BD-ROMでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すPixel Codeと、画素値の連続長とにより、画素列を表現したデータである。Pixel Codeは、8ビットの値であり、1〜255の値をとる。ランレングスデータでは、このPixel Codeによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
【００２７】
ODSによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ODSは、図７（ａ）に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_in_sequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
【００２８】
『object_id』は、ODSはデコードされて対応するグラフィクスオブジェクトがオブジェクトバッファ上に読み出された場合、このグラフィクスオブジェクトと、オブジェクトバッファにおいてこのグラフィクスオブジェクトが占有している領域とを一意に識別する識別子である。1つ以上のグラフィクスオブジェクトが格納された状態において、オブジェクトバッファのメモリ空間における個々の領域は、このobject_idにより識別されることになる。仮にあるobject_idが2つ以上のDisplay Setに付加されている場合、先行するODSに対応するグラフィクスオブジェクトは、オブジェクトバッファに格納された後、同じobject_idを有する後続のグラフィクスオブジェクトにより上書きされることになる。かようなアップデートは、空き領域の虫食い状の発生や、グラフィクスオブジェクトの離散配置を避けるとの配慮である。その理由は以下の通りである。グラフィクス表示を行うため、オブジェクトバッファ上のグラフィクスオブジェクトは絶えずグラフィックスプレーンに転送されることになる。オブジェクトバッファ内に空き領域が虫食い状に発生したり、また同じobject_idをもったグラフィクスオブジェクトがバラバラにされて離散的に配置されると、グラフィクスオブジェクトを読み出すためのオーバヘッドが発生し、オブジェクトバッファ→グラフィックスプレーンの転送時にあたっての転送効率が落ちる。この効率低下は、グラフィクス−動画の同期表示に悪影響を及ぼしかねない。かかる事情から、オブジェクトバッファ上においてあるobject_idで識別されるグラフィクスオブジェクトが共有している領域は、同じ大きさと同じobject_idとをもったグラフィクスオブジェクトでのみ上書きできるとしている。
【００２９】
グラフィクスオブジェクト上書きにあたって、後続するグラフィクスオブジェクトのサイズは、先行するものと同じサイズでなければならない。先行するグラフィクスオブジェクトにより小さすぎてもいけないし、大き過ぎてもいけない。アップデートにあたってグラフィクスオブジェクトのサイズが同じになるようにグラフィクスオブジェクトを作成しておくというのは、オーサリング担当者にとっての責務になる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
【００３０】
『last_in_sequence_flag』、『object_data_fragment』について説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject_data_fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last_in_sequence_flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。
【００３１】
『Palette Difinition Segment(PDS)』は、色変換用のパレットを定義する情報である。パレットとは、1〜255のPixel Codeと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するPixel Codeを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。PDSのデータ構造を図７（ｂ）に示す。図７（ｂ）に示すようにPDSは、自身がPDSであることを示す『segment_type』、PDSのデータ長を示す『segment_length』、このPDSに含まれるパレットを一意に識別する『pallet_id』、EpochにおけるEpochのPDSのバージョンを示す『pallet_version_number』、各エントリーについての情報『pallet_entry』からなる。『pallet_entry』は、各エントリーにおける赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値)を示す。
【００３２】
続いてWDSについて説明する。
『window_definition_segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”window”と呼ばれ、このWDSで定義される。図８（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window_horizontal_position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window_vertical_position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window_width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。
【００３３】
window_horizontal_position、window_vertical_position、window_width、window_heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦:video_height、横:video_widthという二次元状の大きさをもつ。
window_horizontal_positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0〜video_width-1の値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0〜video_height-1の値をとる。
【００３４】
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、1〜video_width-window_horizontal_positionの値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので1〜video_height-window_vertical_positionの値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【００３５】
続いて『END of Display Set Segment』について説明する。END of Display Set Segmentは、Display Setの伝送の終わりを示す指標であり、Display Setにおける機能セグメントのうち、最後のODSの直後に配置される。この END of Display SetSegmentの内部構成は、自身が END of Display SetSegmentであることを示す『segment_type』と、当該機能セグメントのデータ長を示す『segment_length』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
【００３６】
以上がODS、PDS、WDS、ENDについての説明である。続いてPCSについて説明する。
PCSは、対話的な画面を構成する機能セグメントである。PCSは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id_ref』と、『composition_object(1)〜(m)』とから構成される。
【００３７】
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、Epoch Startであるかを示す。
【００３８】
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、PalletOnly Displey Updateに用いられるべきパレットを示す。
【００３９】
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図８（ｂ）の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id_ref』、『window_id_ref』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００４０】
『object_id_ref』は、グラフィクスオブジェクト識別子(object_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window_id_ref』は、ウィンドゥ識別子(window_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【００４１】
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。
【００４２】
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_position』、『object_cropping_width』、『object_cropping_height』からなる。
【００４３】
『object_cropping_horizontal_position』は、オブジェクトバッファにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_position』は、オブジェクトバッファにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４４】
『object_cropping_width』は、オブジェクトバッファにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、オブジェクトバッファにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。続いてPCSの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとは』『ウソだった』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるEpochは、DS1(Epoch Start)、DS2(Normal Case)、DS3(Normal Case)を有する。DS1は、字幕の表示枠となるwindowを定義するWDS、台詞『ほんとは ウソだった ごめん』を表すODS、1つ目のPCSを備える。DS2(Normal Case)は、2つ目のPCSを有する。DS3(Normal Case)は3つ目のPCSを有する。
【００４５】
次に個々のPCSをどのように記述するかについて説明する。Display Setに属するWDS、PCSの記述例を図１０〜図１２に示す。図１０は、DS1におけるPCSの記述例を示す図である。
図１０において、WDSのwindow_horizontal_position、window_vertical_positionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、window_width,window_heightは、ウィンドゥの表示枠の横幅、縦幅を示す。
【００４６】
図１０におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_positionは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして基準点からobject_cropping_width、object_cropping_heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてobject_horizontal_position,object_vertical_positionを基準点(左上)とした破線の範囲cp1に配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
【００４７】
図１１は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ウソだった』の左上座標を示し、object_cropping_height,object_cropping_widthは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
【００４８】
図１２は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１２におけるクロップ情報のobject_cropping_horizontal_position,object_cropping_vertical_position,は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ごめん』の左上座標を示し、object_cropping_height,object_cropping_widthは、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。
【００４９】
図１３は、図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。本図に示すようにオブジェクトバッファは、縦幅、横幅、位置が固定された格納領域A,B,C,Dが4つあり、このうち格納領域Aに、図１１に示した字幕が格納される。これら4つの格納領域A,B,C,Dのそれぞれには、格納されているグラフィクスオブジェクトに対応するobject_idにより識別される。つまりobject_id=1により格納領域Aが、object_id=2により格納領域Bが、object_id=3により格納領域Cが、object_id=4により格納領域Dがそれぞれ識別されるのである。グラフィックスプレーンへの転送効率を維持するため、これら格納領域の縦幅、横幅は終始固定されている。同じobject_idをもったグラフィクスオブジェクトがデコードにより新たに得られれば、それらの格納領域はその新たに得られたグラフィクスオブジェクトにより上書きされる。例えば、図１０に示した字幕と同じ位置に、同じ大きさで字幕を表示させたい場合、後続するDisplay Setにおいて、同じobject_idを付加したODSを設ければよい。このように同じobject_idを付加するだけで、オブジェクトバッファ上に存在するグラフィクスオブジェクトは、新たなグラフィクスオブジェクトで上書きされ、その新たなグラフィクスオブジェクトは、先のグラフィクスオブジェクトと同じ大きさ・同じ位置で表示されることになる。
【００５０】
表示効果実現にあたっての制約について説明する。なめらかな表示効果の実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。ウィンドゥクリアと、ウィンドゥ再描画とをビデオフレームの時間間隔で実現する場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートをRcとすると、ワーストケースでは、この転送レートRcでウィンドゥクリアと、ウィンドゥ再描画とを行わねばならない。そうするとウィンドゥクリア、ウィンドゥ再描画のそれぞれをRcの半分の転送レート(Rc/2)で実現せねばならない。
【００５１】
これらウィンドゥクリア−ウィンドゥ再描画をビデオフレームと同期させるには、
ウィンドゥサイズ×フレームレート≒Rc/2
を満たす必要がある。このフレームレートが29.97であるなら、
Rcは、ウィンドゥサイズ×2×29.97になる。
【００５２】
字幕の表示にあたっては、グラフィックスプレーン全体に対し、最低でも25%〜33%程度の大きさが必要となる。ここでグラフィックスプレーンの総画素数は1920×1080であり、一画素当たりのインデックスのビット長を8ビットとすると、グラフィックスプレーンの総容量は2Mバイト(≒1920×1080×8)になる。
【００５３】
この総容量の1/4をウィンドゥサイズとすると、500kバイト(＝2Mバイト/4)になる。これを上述した式に代入してRcを導けば、Rcは256Mbps(500Kバイト×2×29.97)と算出することができる。
この25%〜33%という大きさであれば、256Mbpsという転送レートで字幕の表示を行っている限り、如何なる表示効果を実現する場合であっても、動画との同期を維持することができる。
【００５４】
仮に、ウィンドゥクリア及び再描画のレートがビデオフレームのフレームレートの1/2,1/4でよいなら、Rcがたとえ同じであってもウィンドゥサイズを2倍,4倍にすることができる。以上がwindowの大きさについての説明である。続いて、windowの位置、範囲について説明する。上述したように、Epochにおいてウィンドゥの位置、範囲は一貫している。
Epochにおいてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
【００５５】
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
【００５６】
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が2つまでであると、最悪4つのオーバーヘッドが発生すると見込んで転送レートを設定すればよいので、ミニマムスタンダードたる転送レートを数値化し易くなる。
【００５７】
以上がウィンドゥについての説明である。続いてこれらPCS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplay Setから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するために想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。Display Set内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplay Setの割り当てである。
【００５８】
先ず、ODSに付加されたDTS、PTSにより、どのような同期制御がなされるかについて説明する。
DTSは、ODSのデコードを開始すべき時間を90KHzの時間精度で示しており、PTSはデコード終了時刻を示す。
ODSのデコードは、瞬時には完了せず、時間的な長さをもっている。このデコード期間の開始点・終了点を明らかにしたいとの要望から、ODSについてのDTS、PTSはデコード開始時刻、デコード終了時刻を示している。
【００５９】
PTSの値はデッドラインであるので、PTSに示される時刻までにODSのデコードがなされて、非圧縮状態のグラフィックオブジェクトが、再生装置上のオブジェクトバッファに得られなければならない。
DSnに属する任意のODSjのデコード開始時刻は、90KHzの時間精度でDTS(DSn[ODSj])に示されるので、これにデコードを要する最長時間を加えた時刻が、Display SetのODSjのデコード終了時刻になる。
【００６０】
ODSjのサイズを”SIZE(DSn[ODSj])”、ODSのデコードレートを”Rd”とすると、デコードに要する最長時間(秒)は、”SIZE(DSn[ODSj])//Rd”になる。ここで”//”は、小数点以下切り上げの割り算を示す演算子である。
この最長時間を90KHzの時間精度に変換し、ODSjのDTSに加算することにより、PTSで示されるべきデコード終了時刻(90KHz)は算出される。
【００６１】
DSnに属するODSjのPTSを、数式で表すと、以下の式のようになる。
PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)
そして互いに隣接する2つのODS(ODSj,ODSj+1)との間では、以下の関係を満たす必要がある。
【００６２】
PTS(DSn[ODSj])≦DTS(DSn[ODSj+1])
またDSnに属するENDは、DSnの終わりを示すものだから、DSnに属する最後のODS(ODSlast)のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2(ODSlast)のPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定される。
【００６３】
PTS(DSn[END]) = PTS(DSn[ODSlast])
続いてPCSのDTS、PTSの設定について説明する。
PCSのDTS値は、DSnにおける最初のODS(ODS1)のデコード開始時点か、それ以前の時点を示す。何故ならPCSは、DSnにおける最初のODS(ODS1)のデコード開始時点(DTS(DSn[ODS1]))、及び、DSnにおける最初のPDS(PDS1)が有効になる時点(PTS(DSn[PDS1]))と同時か、又はそれ以前に、再生装置上のバッファにロードされねばならないからである。よって以下の式の関係を満たす値に、設定されねばならない。
【００６４】
]DTS(DSn[PCS])≦DTS(DSn[ODS1])
DTS(DSn[PCS])≦PTS(DSn[PDS1])
そしてDSnにおけるPCSのPTSは、以下の数式から算出される。
PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)
ここでdecodeduration(DSn)は、PCSのアップデートに用いられる全グラフィクスオブジェクトのデコード及び表示に要する時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本DSn.PCSnの画面合成に用いられるオブジェクトをDSn.PCSn.OBJ[j]とした場合、decodeduration(DSn)は、ウィンドゥクリアに要する時間(i)、DSn.PCSn.OBJ[j]のデコード期間(ii)、DSn.PCSn.OBJ[j]の書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
【００６５】
decode_durationの計算は、図１４のプログラムに基づき行われる。また図１５、図１６（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図１５のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図１５のステップＳ１)。PLANEINITIALIZATINTIME関数(図１６（ａ）)は、Display Setを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図１５のステップＳ１では、DSn,DSn.PCS.OBJ[0],decode_durtationを引数に設定して、この関数を呼び出す。
【００６６】
続いて図１６（ａ）を参照しながらPLANEINITIALIZATINTIME関数について説明する。図１６（ａ）においてinitialize_durationとは、PLANEINITIALIZATINTIME関数の戻り値を示す変数である。
図１６のステップＳ２は、DSnのPCSにおけるcomposition_stateがEpoch Startかどうかにより、処理を切り換えるif文である。もしcomposition_stateがEpoch Startであるなら(図１４のDSn.PCS.composition_state==EPOCH_START、ステップＳ２＝Yes)、グラフィックスプレーンのクリアに要する時間をinitialize_durationに設定する(ステップＳ３)。
【００６７】
オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、グラフィックスプレーンの総サイズをvideo_width*video_heightとすると、クリアに要する時間(秒)は、「video_width*video_height//256,000,000」になる。これに、90,000Hzを乗じPTSの時間精度で表現すれば、グラフィックスプレーンのクリアに要する時間は「90000×video_width*video_height//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。
【００６８】
もしcomposition_stateがEpoch Startでないなら(ステップＳ２＝No)、WDSにて定義されるwindow[i]のクリアに要する時間をinitialize_durationに加えるという処理を全てのwindowについて繰り返す(ステップＳ４)。オブジェクトバッファ−グラフィックスプレーン間の転送レートRcを上述したように256,000,000とし、WDSに属するウィンドゥ[i]の総サイズをΣSIZE(WDS.WIN[i])とすると、クリアに要する時間(秒)は、「ΣSIZE(WDS.WIN[i])//256,000,000」になる。これに、90,000Hzを乗じPTSの時間精度で表現すれば、WDSに属する全ウィンドゥのクリアに要する時間は「90000×ΣSIZE(WDS.WIN[i]))//256,000,000」になる。この時間を、initialize_durationに加えて、initialize_durationを戻り値としてリターンする。以上がPLANEINITIALIZATINTIME関数である。
【００６９】
図１５のステップＳ５は、DSnに属するグラフィクスオブジェクトの数が2であるか、1であるかで処理を切り換えるものであり(図１４のif(DSn.PCS.num_of_object==2),if(DSn.PCS.num_of_object==1))、もし”1”であるなら(ステップＳ５＝1)、グラフィクスオブジェクトのデコードを行うための待ち時間をdecode_durationに加える(ステップＳ６)。この待ち時間の算出は、WAIT関数の呼出(図１４のdecode_duration +=WAIT(DSn,DSn.PCS.OBJ[0],decode_duration))で実現される。この関数呼出にあたっての引数はDSn,DSn.PCS.OBJ[0],decode_durationであり、待ち時間を示すwait_durationが戻り値として返される。
【００７０】
図１６（ｂ）は、WAIT関数の処理手順を示すフローチャートである。
このWAIT関数においてcurrent_durationとは、呼出元のdecode_durationが設定される。object_define_ready_timeは、Display Setのグラフィクスオブジェクト[i]のPTSが設定される変数である。
current_timeとは、DSnのPCSのDTSに、current_durationを足した値が設定される変数である。このcurrent_timeよりobject_define_ready_timeが大きい場合(ステップＳ７がYes、if(current_time < object_define_ready_time))、戻り値たるwait_durationは、object_define_ready_timeとcurrent_timeとの差分が設定されることになる(ステップＳ８、wait_duration += object_define_ready_time - current_time)。以上がWait関数である。ステップＳ６においてdecode_durationには、このwait関数の戻り値と、OBJ[0]をwindowに描画するのに必要な時間を足し合わせた時間(90,000*(SIZE(DSn.WDS.WIN[0]))//256,000,000)が設定されることになる(ステップＳ９)。
【００７１】
以上はDSnのグラフィクスオブジェクトが1つである場合の処理である。図１５のステップＳ５は、グラフィクスオブジェクトの数が2であるかどうかを判定している。DSnのグラフィクスオブジェクトが2以上であれば(図１４のif(DSn.PCS.num_of_object==2))、DSn,DSn.PCS.OBJ[0],decode_durationを引数として、wait関数を呼び出し、その戻り値をdecode_durationに加算する(ステップＳ１０)。
【００７２】
続くステップＳ１１は、DSnのOBJ[0]が属するwindowが、グラフィクスオブジェクト[1]が属するwindowと同一かどうかの判定であり(if(DSn.PCS.OBJ[0].window_id == DSn.PCS.OBJ[1].window_id)、もし同一であるなら、DSn,DSn.PCS.OBJ[1],decode_durationを引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップＳ１２)。OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１３)。
【００７３】
もし属するwindowが異なるなら(ステップＳ１１で”異なる”)、OBJ[0]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[0].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１５)。DSn,DSn.PCS.OBJ[1],decode_durationを引数にしてwait関数を呼び出し、その戻り値wait_durationを、decode_durationに加算する(ステップＳ１６)。その後、OBJ[1]が属するwindowの再描画に必要な時間(90,000*(SIZE(DSn.WDS.OBJ[1].window_id)//256,000,000)をdecode_durationに加える(ステップＳ１７)。
【００７４】
以上のアルゴリズムにより、Decode_Durationは算出される。このPCSのPTSが、具体的にどのように設定されるかについて説明する。
図１７（ａ）は、1つのwindowに1つのODSが存在するケースを想定した図である。図１７（ｂ）（ｃ）は、図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。本チャートには3つの段があり、これらの段のうち、”グラフィックスプレーンアクセス”の段、”ODSデコード”の段は、再生時にパラレルになされる2つの処理を示す。上述したアルゴリズムは、これらの2つの処理のパラレル実行を想定している。
【００７５】
グラフィックスプレーンアクセスは、クリア期間(1)、書き込み期間(3)からなる。このクリア期間(1)は、グラフィックスプレーン全体のクリアに要する期間(90,000×(グラフィックスプレーンのサイズ//256,000,000))、グラフィックスプレーンにおける全windowのクリアに要する時間(Σ(90,000×(window[i]のサイズ//256,000,000)))のどちらかを意味する。
【００７６】
書き込み期間(3)は、window全体描画に要する期間(90,000×(windowサイズ//256,000,000))を意味する。
一方、デコード期間(2)は、ODSのDTSからPTSまでに示される期間を意味する。 これらクリア期間(1)〜書き込み期間(3)は、クリアすべき範囲、デコードすべきODSのサイズ、グラフィックスプレーンに書き込むべきグラフィクスオブジェクトのサイズにより変化し得る。本図では、説明の簡略化のため、ODSのデコード期間(2)の始点は、クリア期間(1)の始点と同一であると仮定している。
【００７７】
図１７（ｂ）はデコード期間(2)が長くなるケースであり、Decode_Durationはデコード期間(2)＋書き込み期間(3)になる。
図１７（ｃ）は、クリア期間(1)が長くなるケースであり、Decode_Durationはクリア期間(1)＋書き込み期間(3)の期間がDecode_Durationになる。
図１８（ａ）〜（ｃ）は、1つのwindowに2つのODSが存在するケースを想定した図である。本図（ｂ）（ｃ）におけるデコード期間(2)は、2つのグラフィクスのデコードに要する期間の総和を意味する。グラフィクス書込期間(3)も、2つのグラフィクスをグラフィックスプレーンに書き込む期間の総和を意味する。ODSが2つになっているものの、図１７と同様に考えればDecode_Durationを算出することができる。2つのODSをデコードするためのデコード期間(2)が長い場合は、図１８（ｂ）に示すようにDecode_Durationはデコード期間(2)＋書き込み期間(3)に算出されることになる。
【００７８】
クリア期間(1)が長い場合は、図１８（ｃ）に示すように、Decode_Durationはクリア期間(1)＋書き込み期間(3)となる。
図１９（ａ）は、2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定している。この場合でもクリア期間(1)が、2つのODSをデコードするための総デコード期間(2)より長い場合、Decode_Durationはクリア期間(1)＋書き込み期間(3)になる。問題は、クリア期間(1)がデコード期間(2)より短くなるケースである。この場合デコード期間(2)の経過を待たずに、1つ目のwindowへの書き込みは可能になる。そのためクリア期間(1)＋書き込み期間(3)、デコード期間(2)＋書き込み期間(3)の長さにはならない。ここで1つ目のODSのデコードに要する期間を書込期間(31)、2つ目のODSのデコードに要する期間を書込期間(32)とする。図１９（ｂ）は、デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示す。この場合Decode_Durationは、デコード期間(2)＋書込期間(32)になる。
【００７９】
図１９（ｃ）は、クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示す。この場合Decode_Durationはクリア期間(1)＋書込期間(31)＋書込期間(32)になる。
グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またwindowのサイズ、ODSのサイズ、個数もオーサリングの段階で判明しているので、これらからDecode_Durationがクリア期間(1)＋書き込み期間(3)、デコード期間(2)＋書き込み期間(3)、デコード期間(2)＋書込期間(32)、クリア期間(1)＋書込期間(31)＋書込期間(32)のどれかになる。こうしたDecode_Duration算出を基にPCSのPTSを設定すれば、ピクチャデータとの同期表示を高い時間精度で実現することができる。このような高精度な同期制御は、windowを定義し、クリア・再描画する範囲を、このwindowに限定することで成り立っているので、オーサリングの環境に、このwindowの概念を導入したことの意義は大きい。
【００８０】
続いてDSnにおけるWDSのDTS、PTSの設定について説明する。WDSのDTSは、以下の数式を満たすように設定すればよい。
DTS(DSn[WDS])≧DTS(DSn[PCS])
一方、DSnにおけるWDSのPTSは、グラフィックスプレーンに対する書き込みを開始すべきデッドラインを示す。グラフィックスプレーンへの書き込みは、ウィンドゥだけで足りるので、PCSのPTSに示される時刻から、全てのウィンドウの書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。WDSの総サイズをΣSIZE(WDS.WIN[i])とすれば、これのクリア及び再描画に要する時間は、『ΣSIZE(WDS.WIN[i])//256,000,000』になる。そして、これを90.000KHzの時間精度で表現すると『90000×ΣSIZE(WDS.WIN[i])//256,000,000』になる。
【００８１】
故に以下の数式から、WDSのPTSを算出すればよい。
PTS(DSn[WDS])=PTS(DSn[PCS])-90000×ΣSIZE(WDS.WIN[i])//256,000,000
このWDSに示されるPTSはデッドラインなので、これより早い時点からグラフィックスプレーンの書き込みを開始してもよい。つまり図１９に示すように、2つのウィンドゥのうち、1つのウィンドゥに表示させるべきODSのデコードが完了したなら、その時点からデコードにより得られたグラフィクスオブジェクトの書き込みを開始してもよい。
【００８２】
このようにWDSに付加されたDTS、PTSを用いてAVClipの再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上がPCS、WDSのDTS、PTSの説明である。
続いてPCSによる前方参照について説明する。前方参照とは、前もって再生装置のメモリに読み込まれたグラフィクスオブジェクトを参照した再生制御をいう。図２０は、前方参照を行うPCSを描いた図である。本図では、DSn、DSn+1、DSn+2という3つのDisplay Setが描かれている。この中でDSn+1、DSn+2に属するPCSが「前方参照を行うPCS」である。本図の矢印yy1,yy2は、PCSにおける前方参照を象徴的に示す。かかる前方参照において参照先になっているグラフィクスオブジェクトは、DSn内のODS#u+1〜#vにより定義されるグラフィクスオブジェクトである。ここでDSnは、ODS#1〜#u、ODS#u+1〜#vという複数のグラフィクスオブジェクトを含む。このうちDSn内のPCSにより参照されているのは、ODS#1〜#uであり、ODS#u+1〜#vは参照されていない。つまりDSn内の非参照グラフィクスオブジェクトが前方参照されているのである。
【００８３】
以上のような前方参照では、PCSにより参照されているグラフィクスオブジェクトが前もって再生装置に読み込まれているので、同じDisplay Setに属するODSのデコードを待つ必要が無い。PCSを新たに送り込むだけで、そのPCSに基づく表示制御を再生装置に実行させることができる。PCSの読み込みに即応した表示制御が可能であるため、既に表示されているグラフィクスを、新たなグラフィクスを用いて更新するというグラフィクス更新を短い時間間隔で実行することができる。そして短い時間間隔でのグラフィクス更新を繰り返せば、動画像の再生進行と共にグラフィクスを滑らかに動かすという表示制御が可能になる。前方参照型のPCSにおける2つの記述例について説明する。
【００８４】
先ず初めに、画面上でグラフィクスが動きまわるような表示効果を実現するにあたってのPCSの記述について説明する。図２１（ａ）は、かかる表示効果を実現するEpochを示す図である。本Epochは、9つのDisplay Set(DS0〜DS8)からなり、先頭のDS0は、PCS、PDS、ODSを含む。DS0内のODSは、図２２（ａ）に示すような字幕「心が揺れる」を定義するものであり、object_id=1が付されている。後続するDS1〜DS8は、PCSのみを含む。
【００８５】
図２１（ｂ）は、DS1〜DS8に含まれるPCSの内容と、PTS値とを示す図である。本図に示すようにDS1〜DS8に属するPCS内の内容は、object_id_ref=1のグラフィクスオブジェクトを座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)に表示するよう、object_horizontal_position,object_vertivcal_positionの位置決めがなされている。これら座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)が、ウィンドゥの座標系のどこに存在するかを、具体的に示したのが図２２（ｂ）である。図２２（ｂ）において座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)は、波形を表す曲線上に存在していることがわかる。これら(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)という座標値は、WDSにて定義されるウィンドゥ内に、グラフィクスが収まるように規定されている。ウィンドゥ内に、グラフィクスが収まらないと、ビデオストリームにおける動画表示との同期を確立することができないからである。
【００８６】
図２１（ｂ）におけるPCSのPTS値は、座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)に対する表示を、再生時間軸上の時点t1,t2,t3・・・・t8のタイミングで命じるものである。
以上のように、PCSの内容が規定されたDS0〜DS8を順次再生装置に読み込んでゆくことにより、グラフィクスは、図２３のような表示効果をなす。動画ストリームの再生時間軸における時点t1において、再生装置にはDS1が読み込まれるので、ウィンドゥ内の座標(x1,y1)にグラフィクスが表示される。時点t4において再生装置にはDS4が読み込まれるので座標(x4,y4)にグラフィクスが表示されることになる。一方時点t6では、DS6が読み込まれるので座標(x6,y6)に、時点t8ではDS8が読み込まれるので座標(x8,y8)にグラフィクスが表示されることになる。これらの座標(x1,y1),(x4,y4),(x6,y6),(x8,y8)は、波形の曲線上に存在するので、かかる座標に表示位置の位置決めがなされたPCSにより、グラフィクスは、図２４に示すように波形の軌道を描くことになる。
【００８７】
以上のようにobject_horizontal_position,object_vertivcal_positionが規定されたPCSを含むDisplay Setを順次再生装置に読み込ませれば、再生装置はBD-ROMから読み出されてくるDS1、DS2、DS3内のPCSに従い、既にオブジェクトバッファに格納されているグラフィクスオブジェクトを、表示させることができる。制御情報の送り込みのみで、グラフィクスの位置を変化させることができるので、グラフィクスを目まぐるしく動かすという制御に適している。
【００８８】
個々のDisplay Setの読み出し時において、それまで参照していたPCSを、新たなPCSで上書きするとの動作を行えば、たとえ読み出すべきPCSが何十個、何百個あったとしても、そのうち最も新しいもののみ、再生装置に格納しておけばよい。滑らかな動きを実現するため、表示座標を示すPCSが、何十個、何百個必要であっても、そのうち最新のもののみ、再生装置に常駐させておけばよいので、再生装置におけるメモリ占有量を必要最低限にすることができる。
【００８９】
続いてPCSの第２の記述例としてPallet Only Updateについて説明する。図２５は、Pallet Only Updateを実現する一連のDisplay Setを示す図である。本図の第１段目は、Pallet Only Updateを実現する一連のDisplay Set(DS0、DS1、DS2、DS3)を示す。このうちDS0は、PCSと、3つのPDS0,1,2,3と、ODSとを含む。以降のDS2、DS3、DS4は、PCSのみからなる。
【００９０】
DS0内のODSは、引き出し線hv1に示すように、文字列「忘れない」を定義するものである。これら文字「忘」「れ」「な」「い」は、それぞれ複数のRun Length(図中の白抜きの四角形)から構成される。このうち文字「忘」を構成するRun Lengthは、PixelCode0をもっているものとする。文字「れ」,「な」,「い」を構成するRun Lengthは、PixelCode1,PixelCode2,PixelCode3をもっているものとする。
【００９１】
図２６（ａ）は、DS0内のPDSがどのような内容であるかを示す図である。
4つのPDSのうち、1つ目のPDS0は(第1段目)、pallet_id=0が付加されており、PixelCode0に赤色を、PixelCode1〜3に白色を割り当てるものである。
2つ目のPDS1は(第2段目)、pallet_id=1が付加されており、0,1,2のPixelCodeに赤色を、3以降のPixelCodeに白色を割り当てるものである。
【００９２】
3つ目のPDS2は(第3段目)、pallet_id=2が付加されており、0,1,2,3のPixelCodeに赤色を、4のPixelCodeに白色を割り当てるものである。
4つ目のPDS3は(第4段目)、pallet_id=3が付加されており、0,1〜4のPixelCodeに赤色を割り当てるものである。
図２６（ｂ）は、DS0〜DS3内のPCSを示す図である。
【００９３】
本図においてDS0内のPCSは(第1段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが0に設定され、Pallet_id_refが0に設定されている。これによりDS0内のODSは、Pallet_id=0で指示されるPDSを用いて、表示されることになる。
DS1内のPCSは(第2段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが1に設定されている。これは、DS1の読み込み時において、Pallet_id=1で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。
【００９４】
DS2内のPCSは(第3段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが2に設定されている。これは、DS2の読み込み時において、Pallet_id=2で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。]
DS3内のPCSは(第4段目)、object_id_ref=1のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてPallet_update_flagが1に設定され、Pallet_id_refが3に設定されている。これは、DS3の読み込み時において、Pallet_id=3で指示されるPDSを用いて、グラフィクス表示の更新を行う旨を示す。DS0〜DS3に属するPCSは、以上のように設定されているので、DS0に属するグラフィクスオブジェクトは、それぞれ別々のパレットデータを用いて、更新されてゆくことになる。
【００９５】
図２７は、これら4つのDisplay Setが読み込ませることで実現される、表示効果を現した図である。DS0に属するグラフィクスオブジェクトが再生装置に投入された段階で、字幕「忘れない」が表示され、それを構成する文字のうち、文字「忘」が赤色になる。次にDS1を投入した段階において、字幕「忘れない」を構成する文字のうち、文字「忘」,「れ」が赤色に、DS2を投入した段階で、文字「忘」,「れ」,「な」が赤色になる。そしてDS3を投入した段階で、全ての文字が赤色になる。Display Setが投入される毎に、字幕を構成する文字は、左に位置するものから順に、白色から赤色に変わってゆくので、音声の進行と共に、文字の色彩を代えてゆく表示効果を実現することができる。
【００９６】
これまでに説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-ray Disc Read Only Formatに規定された構文に従い、クラス構造体を記述することで、BD-ROM上のこれらのデータ構造を得ることができる。 以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２８は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置、マイコンシステムという3つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BDドライブ１、Read Buffer２、PIDフィルタ３、Transport Buffer４a,b,c、周辺回路４d、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、CLUT部９、加算器１０、グラフィクスデコーダ１２、Coded Data Buffer１３、周辺回路１３a、Stream Graphics Processor１４、Object Buffer１５、Composition Buffer１６、Graphical Controller１７から構成される。
【００９７】
BD-ROMドライブ１は、BD-ROMのローディング／リード／イジェクトを行い、BD-ROMに対するアクセスを実行する。
Read Buffer２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
PIDフィルタ３は、Read Buffer２から出力される複数TSパケットに対してフィルタリングを施す。PIDフィルタ３によるフィルタリングは、TSパケットのうち、所望のPIDをもつもののみをTransport Buffer４a,b,cに書き込むことでなされる。PIDフィルタ３によるフィルタリングでは、バッファリングは必要ではない。従って、PIDフィルタ３に入力されたTSパケットは、時間遅延なく、Transport Buffer４a,b,cに書き込まれる。
【００９８】
Transport Buffer４a,b,cは、PIDフィルタ３から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。このTransport Buffer４aからTSパケットが取り出される速度を速度Rxとする
周辺回路４dは、Transport Buffer４a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCoded Data Buffer１３に格納される。
【００９９】
ビデオデコーダ５は、PIDフィルタ３から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、PIDフィルタ３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
【０１００】
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
CLUT部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
【０１０１】
加算器１０は、CLUT部９により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
【０１０２】
グラフィクスデコーダ１２によるパイプラインは、DSnに属するグラフィクスオブジェクトをObject Buffer１５に書き込む処理、DSn+1に属するグラフィクスオブジェクトをObject Buffer１５から読み出す処理を同時に実行することでパイプラインは実行される。
このグラフィクスデコーダ１２は、Coded Data Buffer１３、周辺回路１３a、Stream Graphics Processor１４、Object Buffer１５、Composition Buffer１６、Graphical Controller１７から構成される。
【０１０３】
Coded Data Buffer１３は、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、Transport Buffer４a,b,cに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS／DTSは、PESパケットと対応付けて格納される。
【０１０４】
周辺回路１３aは、Coded Data Buffer１３−Stream Graphics Processor１４間の転送、Coded Data Buffer１３−Composition Buffer１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がODSのDTSに示される時刻になれば、ODSを、Coded Data Buffer１３からStream Graphics Processor１４に転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをComposition Buffer１６に転送するという処理を行う。
【０１０５】
Stream Graphics Processor１４は、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObject Buffer１５に書き込む。Stream Graphicsプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをStream Graphicsプロセッサ１４は一時的に保持する。Stream Graphicsプロセッサ１４によるデコードは瞬時になされるが、Stream Graphicsプロセッサ１４からObject Buffer１５への書き込みは、瞬時には終わらない。BD-ROM規格のプレーヤモデルでは、Object Buffer１５への書き込みは、128Mbpsという転送レートでなされるからである。Object Buffer１５への書き込み完了時点は、ENDセグメントのPTSに示されているので、このENDセグメントのPTSに示される時点が経過するまで、次のDSに対する処理を待つことになる。各ODSをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。
【０１０６】
書き込み時にあたってDSn側のグラフィックスデータと、DSn+1側のグラフィックスデータとに割り当てられているobject_idが別々の場合、Stream Graphicsプロセッサ１４はDSn側のグラフィックスデータと、DSn+1側のグラフィックスデータとを、Object Buffer１５における別々の領域に書き込む。これによりDSnのPCSにより参照されるグラフィクスオブジェクトは、DSn+1に属するグラフィクスオブジェクトにより上書きされることなく、パイプラインで表示に供される。両グラフィクスオブジェクトに割り当てられているobject_idが同じである場合、前記Stream Graphicsプロセッサ１４は、Object Buffer１５において先行DS側のグラフィックスデータが格納されている領域と同じ領域に、後続DS側のグラフィックスデータを上書きする。かかる場合、パイプラインは行わない。またDSに属するグラフィクスオブジェクトには、同一DSのPCSにより参照されているものと、参照されていないものとがある。Stream Graphicsプロセッサ１４は、PCSにより参照されているグラフィクスオブジェクトだけでなく、参照されてないグラフィクスオブジェクトを逐次デコードして、デコードにより得られたグラフィクスをObject Buffer１５に格納する。
【０１０７】
Object Buffer１５は、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor１４のデコードにより得られたグラフィクスオブジェクトが配置される。Object Buffer１５は、グラフィクスプレーン８の2倍／4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン８の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【０１０８】
Composition Buffer１６は、PCS、PDSが配置されるメモリである。−−処理すべきDisplay Setが2つあり、これらの有効区間が重複している場合、Compositionバッファ１６には処理すべきPCSが複数格納される。
Graphical Controller１７は、Graphicalコントローラ１７はPCSの解読を行い、PCSの解読結果に従って、グラフィクスオブジェクトのObject Buffer１５への書き込み、及び、Object Buffer１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Graphicalコントローラ１７による表示は、PCSを格納したPESパケットのPTSに示される時点において実行される。
【０１０９】
PCSを用いた画面構成を実行するにあたって、Graphicsコントローラ１７は以下の処理を行う。Graphicsコントローラ１７は、オブジェクトCに記述されたグラフィクスオブジェクト識別子の参照値(object_id_ref)を読み取り、そのobject_id_refにより指示されるグラフィクスオブジェクトのうち、object_cropping_horizontal_position,object_cropping_vertical_positionから、object_cropping_width、object_cropping_heightに示されるクロップ範囲を切り出して、グラフィックスプレーンのobject_horizontal_position,object_vertical_positionにより示される位置に書き込む。この参照値が、PCSと同じDisplay Setに属するグラフィクスオブジェクトを表している場合、同じDisplay Setに属するODSがデコードされた後でないと、上述したグラフィックスプレーンへの書き込みは行えない。
【０１１０】
一方、オブジェクトCが属するDisplay SetのComposition_stateがNormal Caseである場合、デコードにより得られたグラフィクスオブジェクトが、前もってオブジェクトバッファ内に格納されているので、ODSのデコードを待つことなく、上述したグラフィックスプレーンへの書き込みを行うことができる。
PalletOnly Displey Update時におけるGraphicsコントローラ１７の読み出し処理は以下の通りである。Display Setが、BD-ROMから読み出された場合、Graphicsコントローラ１７は、PCSのPallette_update_flagが、”1”であるか否かを判定する。もし1であるなら、PCSのpallet_idに記述されているパレットデータを用いた画素値変換を、CLUT部９に命じた上で、Object Buffer１５からグラフィクスオブジェクトを読み出し、グラフィクスプレーン８に格納させてゆく。CLUT部９に対するパレットデータの設定のみを行うことで、グラフィクスの更新を行うのである。
【０１１１】
続いて、PIDフィルタ３、Transport Buffer４a,b,c、グラフィクスプレーン８、CLUT部９、Coded Data Buffer１３〜Graphical Controller１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２９は、書込レートRx,Rc,Rd、グラフィクスプレーン８、Transport Buffer４a、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【０１１２】
Object Buffer１５−グラフィクスプレーン８間の転送レートRcは、本装置において最も高い転送レートであり、ウィンドゥサイズ、フレームレートから256Mbps(=500Kバイト×29.97×2)と算出される。
Stream Graphics Processor１４−Object Buffer１５間の転送レートRd(Pixel Decoding Rate)は、Rcとは異なり、ビデオフレームの周期によるアップデートは要求されずRcの1/2,1/4でよい。故に128Mbps,64Mbpsになる。
【０１１３】
Transport Buffer４a,b,c−Coded Data Buffer１３間のTransport Buffer LeakレートRxは、圧縮状態たるODSの転送レートである。従ってTransport Buffer Leakレートは、Rdに圧縮率を乗じた転送レートでよい。ODSの圧縮率を25%と仮定すれば、16Mbps(=64Mbps×25%)で足りる。
この図に示す転送レート、バッファ規模はあくまでもミニマムスタンダードであり、これより大きい値での実装を否定している訳ではない。
【０１１４】
以上のように構成された再生装置において、各構成要素はパイプライン式にデコード処理を行うことができる。
図３０は、再生装置によるパイプライン処理を示すタイミングチャートである。第５段目は、BD-ROMにおけるDisplay Setを示し、第４段目は、Coded Data Buffer１３へのPCS、WDS、PDS、ODSの読出期間を示す。第３段目は、Stream Graphics Processor１４による各ODSのデコード期間を、第２段目はComposition Buffer１６の格納内容を、第１段目はGraphical Controller１７の処理内容を示す。
【０１１５】
ODS1,2に付与されたDTS(デコード開始時刻)は、図中のt31,t32の時点を示している。デコード開始時刻がDTSに規定されているので、各ODSは、自身のDTSに示される時刻までにCoded Data Buffer１３に読み出されなければならない。そのためODS1の読み出しは、Coded Data Buffer１３へのODS1のデコード期間dp1の直前までに完了している。Coded Data Buffer１３へのODS2の読み出しは、ODS2のデコード期間dp2の直前までに完了している。
【０１１６】
一方、ODS1,2に付与されたPTS(デコード終了時刻)は、図中のt32,t33の時点を示している。Stream Graphics Processor１４によるODS1のデコードはt32までに完了し、ODS2のデコードは、t33に示される時刻までに完了する。以上のように、Stream Graphics Processor１４は、各ODSのDTSに示される時刻までに、ODSをCoded Data Buffer１３に読み出し、Coded Data Buffer１３に読み出されたODSを、各ODSのPTSに示される時刻までに、デコードしてObject Buffer１５に書き込む。
【０１１７】
本図の第１段目における期間cd1は、Graphics Controller１７がグラフィクスプレーン８をクリアするのに要する期間である。また期間td1は、Object Buffer１５上にえられたグラフィクスオブジェクトを、グラフィクスプレーン８に書き込むのに要する期間である。WDSのPTSは、この書き込みの開始にあたってのデッドラインを示し、PCSのPTSはこの書き込みの終了時点及び表示タイミングを示す。このPCSのPTSに示される時点になれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン８上に得られることになる。この非圧縮グラフィクスの色変換をCLUT部９に行わせ、ビデオプレーン６に格納されている非圧縮ピクチャとの合成を加算器１０に行わせれば、合成画像が得られることになる。
【０１１８】
グラフィクスデコーダ１２において、Graphics Controller１７がグラフィクスプレーン８のクリアを実行している間においても、Stream Graphics Processor１４のデコードは継続して行われる。以上のようなパイプライン処理により、グラフィクスの表示を迅速に実施することができる。
図３０では、グラフィックスプレーンのクリアが、ODSのデコードより早く終わる場合を想定したが、図３１は、ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。この場合、ODSのデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
【０１１９】
再生装置におけるバッファ占有量の時間的遷移について図３２を参照しながら説明する。図３２は、図２８におけるCompositionバッファ１６、Object Buffer１５、Coded Dataバッファ１３、グラフィクスプレーン８の時間的遷移を示すタイミングチャートである。本図は、第１段目から第４段目までに、グラフィクスプレーン８、Object Buffer１５、Coded Dataバッファ１３、Compositionバッファ１６における占有量の時間的遷移を示している。この占有量の時間的遷移は、横軸を時間軸とし、縦軸を占有量とした折れ線グラフの表記で表現している。
【０１２０】
図３２の第４段目は、Compositionバッファ１６における占有量の時間的遷移を示す。本図に示すようにCompositionバッファ１６の時間的遷移は、Coded Dataバッファ１３から出力されPCSが格納されることによる単調増加vf0を含む。
第３段目は、Coded Dataバッファ１３における占有量の時間的遷移を示す。本図に示すようにCoded Dataバッファ１３の時間的遷移は、ODSが格納されることによる単調増加Vf1,Vf2と、格納されたODSが順次Stream Graphicsプロセッサ１４により取り出されることによる単調減少Vg1,Vg2とを含む。単調増加Vf1,Vf2の傾きは、Transportバッファ４a,b,cからCoded Dataバッファ１３への出力レートRxに基づき、単調減少Vg1,Vg2の傾きは、Stream Graphicsプロセッサ１４によるデコードであり、瞬時に実行される。つまりODSに対するデコードは瞬時に行われ、Stream Graphicsプロセッサ１４は、デコードにより得られた非圧縮グラフィクスを保持する。Stream Graphicsプロセッサ１４からObject Buffer１５への伝送路の書込レートは128Mbpsであるため、この書込レートにより、Object Buffer１５の占有量は増加する。
【０１２１】
第２段目は、Object Buffer１５における占有量の時間的遷移を示す。本図に示すようにObject Buffer１５の時間的遷移は、Stream Graphicsプロセッサ１４から出力されたODSが格納されることによる単調増加Vh1,Vh2を含む。単調増加Vh1,Vh2の傾きは、Stream Graphicsプロセッサ１４からObject Buffer１５への転送レートRdに基づく。第３段目の単調減少が生じる期間及びの第２段目の単調増加が生ずる期間が、デコード期間である。このデコード期間の始期は、ODSのDTSに示されており、デコード期間の終期は、ODSのPTSに示されている。このODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer１５に格納されれば、ODSに対するデコードは完了したことになる。ODSのPTSに示される期間までに、非圧縮のグラフィクスがobject buffer１５に格納されることが、必須の要件であり、このデコード期間における単調増加、単調減少はどのようなものであってもよい。
【０１２２】
第１段目は、グラフィクスプレーン８における占有量の時間的遷移を示す。本図に示すようにグラフィクスプレーン８の時間的遷移は、Object Buffer１５から出力されたデコード済みODSが格納されることによる単調増加Vf3を含む。単調増加Vf3の傾きは、Object Buffer１５からグラフィクスプレーン８への転送レートRcに基づく。この単調増加の終期は、PCSのPTSに示されている。
【０１２３】
ODSに付与されたDTS、PTS、ICSに付与されたDTS、PTS、そして図２９に示した各バッファのサイズ、転送レートを用いれば、本図のようなグラフを作図することにより、BD-ROMにて供給すべきAVClipの再生時において、各バッファの状態がどのように変化するかが、オーサリングの段階で明らかになる。
このバッファ状態の遷移は、DTS、PTSに示される値を書き換えることで、調整することが可能なので、再生装置側のデコーダのスペックを越えるような復号負荷の発生を回避したり、再生にあたってのバッファオーバーフローの回避することができる。そのため再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
【０１２４】
以上が再生装置の内部構成である。続いてグラフィクスコントローラ１７を、どのようにして実装するかについて説明する。グラフィクスコントローラ１７は、図３３の処理手順を行うプログラムを作成し、CPUに実行させることにより実装可能である。以降、図３３を参照しながら、グラフィクスコントローラ１７の処理手順について説明する。
図３３は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(PCS,WDS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップＳ２１〜Ｓ２４、ステップＳ２７〜Ｓ３１の処理を全てのSegmentKについて繰り返すループ構造を有している(ステップＳ２５、ステップＳ２６)。
【０１２５】
ステップＳ２１は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップＳ２７、ステップＳ２８の判定を行う。
ステップＳ２２は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップＳ２３に移行し、1であるならステップＳ２４に移行する。無視フラグが1であれば(ステップＳ２２でNo)、ステップＳ２３においてSegmentKをCoded Data Buffer１３にロードする。
【０１２６】
無視フラグが0に設定されていれば(ステップＳ２２がNo)、ステップＳ２４においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップＳ２２がNoになって、無視されることになる(ステップＳ２４)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
【０１２７】
ステップＳ２７は、PCSにおけるcomposition_stateがAcquisition Pointであるか否かの判定である。SegmentKがAcquisition Pointであるなら、ステップＳ２８に移行し、SegmentKがもしEpoch StartかNormal Caseであるなら、ステップＳ３１に移行する。
ステップＳ２８は、先行するDSがグラフィクスデコーダ１２内のどれかのバッファ(Coded Data Buffer１３、Stream Graphicsプロセッサ１４、Object Buffer１５、Composition Buffer１６)に存在するかどうかの判定であり、ステップＳ２７がYesである場合に実行される。グラフィクスデコーダ１２内にDSが存在しないケースとは、頭出しがなされたケースをいう。この場合、Acquisition PointたるDSから、表示を開始せねばならないので、ステップＳ３０に移行する(ステップＳ２８でNo)。
【０１２８】
ステップＳ３０は、無視フラグを0に設定し、ステップＳ２２に移行する。
グラフィクスデコーダ１２内にDSが存在するケースとは、通常再生がなされたケースをいう。この場合、ステップＳ２９に移行する(ステップＳ２８でYes)。ステップＳ２９は、無視フラグを1に設定し、ステップＳ２２に移行する。
ステップＳ３１は、PCSにおけるcomposition_stateがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップＳ３４に移行する。SegmentKがEpoch Startであるなら、ステップＳ３０において無視フラグを0に設定する。 ステップＳ３４は、ステップＳ２８と同じであり、先行するDSがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップＳ３０)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップＳ３５)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ１２に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
【０１２９】
DSが、図３４のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図３４の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、composition_stateがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図３３のフローチャートの対象となる。ステップＳ２７においてcomposition_stateはAcquisition Pointと判定されるが、先行するDSはCoded Data Buffer１３上に存在しないため、無視フラグは0に設定され、このDS10が図３５の矢印md1に示すように再生装置のCoded Data Buffer１３にロードされる。一方、頭出し位置がDS10の存在位置より後である場合(図３４の矢印am2)、DS20は、Normal CaseのDisplay Setであり、先行するDS20はCoded Data Buffer１３に存在しないので、このDisplay Setは、無視されることになる(図３５の矢印md2)。
【０１３０】
図３６のように通常再生が行われた場合のDS1,10,20のロードは、図３６に示すものとなる。3つのDSのうち、PCSのcomposition_stateがEpoch StartであるDS1は、そのままCoded Data Buffer１３にロードされるが(ステップＳ２３)、PCSのcomposition_stateがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップＳ２９)、これを構成する機能セグメントはCoded Data Buffer１３にロードされず無視される(図３７の矢印rd2,ステップＳ２４)。またDS20については、PCSのcomposition_stateはNormal Caseなので、Coded Data Buffer１３にロードされる(図３７の矢印rd3)。
【０１３１】
続いてGraphical Controller１７の処理手順について説明する。図３８〜図４０は、Graphical Controller１７の処理手順を示すフローチャートである。
ステップＳ４１〜ステップＳ４４は、本フローチャートのメインルーチンであり、ステップＳ４１〜ステップＳ４４に規定した何れかの事象の成立を待つ。
ステップＳ４１は、現在の再生時点がPCSのDTS時刻になっているか否かの判定であり、もしなっていれば、ステップＳ４５〜ステップＳ５３の処理を行う。
【０１３２】
ステップＳ４５は、PCSのcomposition_stateが、Epoch_Startであるか否かの判定であり、もしEpoch Startであるなら、ステップＳ４６においてグラフィクスプレーン８を全クリアする。それ以外であるなら、ステップＳ４７においてWDSのwindow_horizontal_position、window_vertival_position、window_width、window_heightに示されるwindowをクリアする。
【０１３３】
ステップＳ４８は、ステップＳ４６又はステップＳ４７でのクリア後の実行されるステップであり、任意のODSxのPTS時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン８全体のクリアにあたっては、そのクリア時間に長時間を費するので、あるODS(ODSx)のデコードが既に完了していることもある。ステップＳ４８はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかのODSのデコード時刻を経過しているなら、ステップＳ４９〜ステップＳ５１を実行する。ステップＳ４９は、object_cropped_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５０)。
【０１３４】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ５１)。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３５】
ステップＳ５２は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン８に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして(ステップＳ５３)、ステップＳ４９に移行する。これにより、別のODSに対しても、ステップＳ４９〜Ｓ５１の処理が繰り返し行われる。
次に図３９を参照して、ステップＳ４２、ステップＳ５４〜ステップＳ５９について説明する。
【０１３６】
ステップＳ４２は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップＳ５４においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップＳ５５〜ステップＳ５９のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップＳ５７〜ステップＳ５９を実行するというものである。ステップＳ５７は、object_cropped_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５８)。
【０１３７】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ５９)。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３８】
ステップＳ４４は、現在の再生時点がPCSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップＳ６０においてPallet_update_flagが1を示しているか否かを判定する。もし1を示しているなら、pallet_idに示されるPDSをCLUT部に設定する(ステップＳ６１)。0を示しているなら、ステップＳ６１をスキップする。
その後、グラフィクスプレーン８におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する(ステップＳ６２)。
【０１３９】
次に図４０を参照して、ステップＳ４３、ステップＳ６４〜ステップＳ６６について説明する。
ステップＳ４３は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップＳ６３においてウィンドゥが2つであるか否かを判定する。もし1つであれば、メインルーチンにリターンする。
【０１４０】
ステップＳ４３及びステップＳ６３の判定は以下の意味をもつ。つまりウィンドゥが2つある場合、それぞれのウィンドゥには、1つずつグラフィクスオブジェクトが表示される。そうすると、それぞれのODSのデコードが完了する度に、デコードにより得られたグラフィクスオブジェクトを、グラフィックスプレーンに書き込んでゆく処理が必要になる(例:図１９（ｂ）のケース)。そこで現在時点がODSのPTSに示される時点であり、ウィンドゥが2つであるなら、個々のグラフィクスオブジェクトをグラフィックスプレーンに書き込むべく、ステップＳ６４〜ステップＳ６６を実行する。ステップＳ６４は、object_cropped_flagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ６５)。
【０１４１】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいて object_horizontal_position,object_vertival_positionに示される位置に書き込む(ステップＳ６６)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
【０１４２】
(第２実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図４１は、第１実施形態に示したPCSを作成するための製造工程を示す図である。
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程Ｓ２０３を含む。
【０１４３】
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１０を含む。
ステップＳ２０４において制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５では、制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを機能セグメントに変換する。そしてステップＳ２０６において同期したいピクチャが出現するタイミングに基づき、PCSのPTSを設定し、ステップＳ２０７では、PTS[PCS]の値に基づき、DTS[ODS],PTS[ODS]を設定する。ステップＳ２０８において、DTS[ODS]の値に基づき、DTS[PCS],PTS[PDS],DTS[WDS],PTS[WDS]を設定し、ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのDTS、PTSを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してAVClipを得る。以降、AVClipをBD-ROMのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
【０１４４】
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の［技術分野］の、出願当時の技術水準の特性に基づく。
【０１４５】
(A)全ての実施形態では、本発明に係る記録媒体をBD-ROMとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレシキブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。
【０１４６】
(B)全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムLSI(集積回路)のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、第１実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１４７】
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１４８】
(E)BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arribval_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”Aligned Unit”という。
【０１４９】
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、Aligned Unitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArribval_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
【０１５０】
(F)各実施形態におけるデジタルストリームは、BD-ROM規格のAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(Video Object)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。
【０１５１】
(G)各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１５２】
(H)第１実施形態〜第２実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いているからである。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはPNGデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１５３】
(I)PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
またPCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBD-ROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
【０１５４】
(J)第１実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25%に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
【０１５５】
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。
(K)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
【０１５６】
(L)グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、動画と緻密に同期して表示されるものであればなんであってもよい。例えばイラストや絵柄、キャラクタ、シンボルマークを描いたものであってもよい。商標を構成するような図形,文字,色彩の組合せや、国の紋章,旗章,記章,国家が採用する監督/証明用の公の記号・印章、政府間国際機関の紋章,旗章,記章,特定商品の原産地表示を含んでいてもよい。
【０１５７】
(M)第１実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
(O)グラフィクスデコーダ１２が、DSn及びDSn+1に対する処理をパイプライン式に行うのは、DSn及びDSn+1が、グラフィクスストリームにおける同じEpochに帰属している場合であり、前記DSn及びDSn+1が、互いに異なるEpochに属している場合、DSnにおけるグラフィクス表示を開始した後に、DSn+1に対する処理を開始する。
【０１５８】
またグラフィクスストリームには、動画との同期を主たる目的としたプレゼンテーション系のものと、対話的な表示を主目的としたインタラクティブ系のものとがあり、前記グラフィクスデコーダは、グラフィクスストリームがプレゼンテーション系である場合に、2つのDSに対するパイプライン式を行い、グラフィクスストリームがインタラクティブ系である場合、2つのDSに対するパイプライン式を行わない。
【０１５９】
(P)Display Set内にグラフィクスデータを配列させるにあたって、図２０では、同じDisplay Set内のPCSにより参照されるグラフィクスデータを、参照されないグラフィクスデータの前に配列したが、複数の参照グラフィクスデータ、及び、複数の非参照グラフィクスデータを、それぞれ、object_idにより指示される識別番号順に配列してもよい。また複数の参照グラフィクスデータは、スキャンライン順に配列してもよい。スキャンラインとは、ディスプレイでの表示時において、走査される順番を表す。通常ディスプレイにおける走査は、左上→右下方向に向けてなされるから、表示座標が左上にあるグラフィクスデータを前に、表示座標が右下にあるグラフィクスデータを後に配置するのである。こうすることで、グラフィクスデータ表示の迅速化を図ることができる。
【０１６０】
上述した変更実施は可能であるものの、請求項に係る各発明は、従来技術の技術的課題を解決するための手段を反映したものであるから、請求項に係る各発明の技術範囲は、従来技術の技術的課題解決が当業者により認識される技術範囲を超えることはない。故に、本願の請求項に係る各発明は、詳細説明の記載と、実質的な対応関係を有する。
【産業上の利用可能性】
【０１６１】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき工業的に量産することが可能なので、資質において工業上用することができる。このことから本発明に係る再生装置は、産業上利用可能性を有する。
【図面の簡単な説明】
【０１６２】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの構成を示す図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】字幕の表示位置と、Epochとの関係を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトの定義を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造を示す図である。
【図９】字幕表示を実現するためのDisplay Setの記述例である。
【図１０】DS1におけるWDS、PCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DS3におけるPCSの記述例を示す図である。
【図１３】図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。
【図１４】decode_durationの計算アルゴリズムの一例を示す図である。
【図１５】図１４のプログラムのアルゴリズムを図式化したフローチャートである。
【図１６】（ａ）（ｂ）図１４のプログラムのアルゴリズムを図式化したフローチャートである。
【図１７】（ａ）1つのwindowに1つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図１８】（ａ）1つのwindowに2つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図１９】（ａ）2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定したタイミングチャートである。 （ｂ）デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示すタイミングチャートである。 （ｃ）クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示すタイミングチャートである。
【図２０】前方参照を行うPCSを描いた図である。
【図２１】（ａ）DS1〜DS8に含まれるPCSの内容と、PTS値とを示す図である。 （ｂ）グラフィクスが画面内を動き回るという表示効果を実現するEpochを示す図である。
【図２２】（ａ）DS0内のODSを示す図である。 （ｂ）座標(x1,y1)(x2,y2)(x3,y3)・・・(x8,y8)が、ウィンドゥの座標系のどこに存在するかを示す図である。
【図２３】各Display Setに属する各機能セグメントのタイムスタンプに対する設定を示す図である。
【図２４】アップデートの、時間的変遷の具体例を示す図である。
【図２５】Pallet Only Updateを実現する一連のDisplay Setを示す図である。
【図２６】（ａ）DS0内のPDS及び各Display SetのPCSがどのような内容であるかを示す図である。 （ｂ）DS0〜DS3内のPCSを示す図である。
【図２７】4つのDisplay Setが読み込ませることで実現される、表示効果を現した図である。
【図２８】本発明に係る再生装置の内部構成を示す図である。
【図２９】書込レートRx,Rc,Rd、グラフィクスプレーン８、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【図３０】再生装置によるパイプライン処理を示すタイミングチャートである。
【図３１】ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。
【図３２】Compositionバッファ１６、Object Buffer１５、Coded Dataバッファ１３、グラフィクスプレーン８における蓄積量の時間的遷移を示すタイミングチャートである。
【図３３】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図３４】スキップ操作がなされる一例を示す図である。
【図３５】図３４においてスキップ操作がなされた際、DS10が再生装置のCoded Data Buffer１３にロードされる様子を示す図である。
【図３６】通常再生が行われる場合を示す図である。
【図３７】図３６のように通常再生が行われた場合のDS1,10,20のロードを示す図である。
【図３８】Graphical Controller１７の処理手順を示すフローチャートである。
【図３９】Graphical Controller１７の処理手順を示すフローチャートである。
【図４０】Graphical Controller１７の処理手順を示すフローチャートである。
【図４１】第１実施形態に示したPCSが記録されたBD-ROMを製造するための製造工程を示す図である。
【符号の説明】
【０１６３】
１ BDドライブ１、
２ Read Buffer
３ PIDフィルタ
４a,b,c Transport Buffer
４d 周辺回路
５ ビデオデコーダ
６ ビデオプレーン
７ オーディオデコーダ
８ グラフィクスプレーン
９ CLUT部
１０ 加算器
１２ グラフィクスデコーダ
１３ Coded Data Buffer
１３a 周辺回路
１４ Stream Graphics Processor
１５ Object Buffer
１６ Composition Buffer
１７ Graphical Controller
１００ BD-ROM
２００ 再生装置
３００ テレビ
４００ リモコン
【特許請求の範囲】
【請求項１】
動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、
グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、
前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、
前記パレットデータは、
各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、
前記制御データは、
前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させる
ことを特徴とする記録媒体。
【請求項２】
グラフィクスストリームにおけるパケットは、複数のディスプレィセットの何れかに分類されており、個々のディスプレィセットは、グラフィクス表示を実現する一個のデータの集合であり、
前記グラフィクスデータと、制御データとは、別々のディスプレィセットに属している
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
記録媒体と、再生装置とを含む再生システムであって、
記録媒体には、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されており、
グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、
前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、
前記パレットデータは、各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、
前記制御データは、前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させるものであり、
前記再生装置は、ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生を行い、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードして非圧縮グラフィクスを得るグラフィクスデコーダと、
デコードにより得られた非圧縮グラフィクスを描画するためのプレーンメモリと、
ルックアップテーブル部とを備え、
前記グラフィクスデコーダは、
デコードにより得られた非圧縮グラフィクスを格納するオブジェクトバッファを備え、
記録媒体から新たな制御データが読み込まれれば、その制御データに基づき、前もって送り込まれたグラフィクスを表示する制御を実行し、
前記表示制御は、オブジェクトバッファに格納された非圧縮グラフィクスをプレーンメモリに転送すると共に、記録媒体から読み込まれたパレットデータをルックアップテーブル部に設定して、前記制御データに記述されたパレットデータを示す参照値に基づく色変換をルックアップテーブル部に命じることでなされる
ことを特徴とする再生システム。
【請求項４】
グラフィクスストリームはグラフィクス表示を実現するデータの集合であるディスプレィセットを複数含み、
グラフィクスデコーダは、
ディスプレィセットが記録媒体から読み出されれば、そのディスプレィセットに属するグラフィクスデータをオブジェクトバッファに格納しておき、
前記前もって送り込まれたグラフィクスは、オブジェクトバッファに格納されているグラフィクスデータである
ことを特徴とする請求項３記載の再生システム。
【請求項１】
動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、
グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、
前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、
前記パレットデータは、
各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、
前記制御データは、
前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させる
ことを特徴とする記録媒体。
【請求項２】
グラフィクスストリームにおけるパケットは、複数のディスプレィセットの何れかに分類されており、個々のディスプレィセットは、グラフィクス表示を実現する一個のデータの集合であり、
前記グラフィクスデータと、制御データとは、別々のディスプレィセットに属している
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
記録媒体と、再生装置とを含む再生システムであって、
記録媒体には、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されており、
グラフィクスストリームは、パケットの配列からなり、パケットには、グラフィクスデータを格納したものと、パレットデータを格納したものと、制御データを格納したものとがあり、
前記グラフィクスデータは、複数のコード値を用いて、表示内容を表現したデータであり、
前記パレットデータは、各コード値と、揮度及び色差との対応関係を示すテーブル構造のデータであり、前記再生装置がグラフィクス表示を行う際、再生装置におけるルックアップテーブル部に設定され、
前記制御データは、前記グラフィクス表示で色変換を実行するにあたって、当該色変換に用いるべき前記パレットデータに対する参照値を含み、当該参照値に基づく色変換を再生装置におけるルックアップテーブル部に命じることで、パケット列において自身より前方に存在するグラフィクスデータであって、既にオブジェクトバッファに格納され、尚且つ、プレーンメモリ上で描画されているものの表示色を、所定のタイミングで変化させるものであり、
前記再生装置は、ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生を行い、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードして非圧縮グラフィクスを得るグラフィクスデコーダと、
デコードにより得られた非圧縮グラフィクスを描画するためのプレーンメモリと、
ルックアップテーブル部とを備え、
前記グラフィクスデコーダは、
デコードにより得られた非圧縮グラフィクスを格納するオブジェクトバッファを備え、
記録媒体から新たな制御データが読み込まれれば、その制御データに基づき、前もって送り込まれたグラフィクスを表示する制御を実行し、
前記表示制御は、オブジェクトバッファに格納された非圧縮グラフィクスをプレーンメモリに転送すると共に、記録媒体から読み込まれたパレットデータをルックアップテーブル部に設定して、前記制御データに記述されたパレットデータを示す参照値に基づく色変換をルックアップテーブル部に命じることでなされる
ことを特徴とする再生システム。
【請求項４】
グラフィクスストリームはグラフィクス表示を実現するデータの集合であるディスプレィセットを複数含み、
グラフィクスデコーダは、
ディスプレィセットが記録媒体から読み出されれば、そのディスプレィセットに属するグラフィクスデータをオブジェクトバッファに格納しておき、
前記前もって送り込まれたグラフィクスは、オブジェクトバッファに格納されているグラフィクスデータである
ことを特徴とする請求項３記載の再生システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【公開番号】特開２００７−２５９５０４（Ｐ２００７−２５９５０４Ａ）
【公開日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願番号】特願２００７−１７０２７０（Ｐ２００７−１７０２７０）
【出願日】平成１９年６月２８日（２００７．６．２８）
【分割の表示】特願２００６−２４２５７２（Ｐ２００６−２４２５７２）の分割
【原出願日】平成１６年６月２９日（２００４．６．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１９年１０月４日（２００７．１０．４）
【国際特許分類】
【出願日】平成１９年６月２８日（２００７．６．２８）
【分割の表示】特願２００６−２４２５７２（Ｐ２００６−２４２５７２）の分割
【原出願日】平成１６年６月２９日（２００４．６．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]