トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 記録媒体、再生システム
【発明者】 【氏名】マクロッサン ジョセフ

【氏名】岡田 智之
【要約】 【課題】複数ディスプレイセットに対する処理を並列化する能力が再生装置にあったとしても、本来の順序でグラフィクスを表示させることができる記録媒体を提供する。

【構成】BD-ROMには、動画ストリームとグラフィクスストリームとを多重化することにより得られたAVClipが記録されている。グラフィクスストリームは、グラフィクス画面を実現するデータ群であるディスプレイセット(DS)を複数含み、各DSはグラフィクスデータを含む。先行するDSの制御セグメントのアクティブ期間と、後続するDSの制御セグメントのアクティブ期間とが動画ストリームにおける再生時間軸上でオーバーラップする場合、後続DSに属するグラフィックスデータによる上書きを禁止するよう、グラフィクスデータには、先行DS内のPCSにより参照されるグラフィックスデータと異なるobject_idが割り当てられる。
【特許請求の範囲】
【請求項１】
動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、
グラフィクスストリームは、グラフィクス画面を実現するディスプレイセットを複数含み、
各ディスプレイセットは、プレゼンテーション制御セグメントと、オブジェクトバッファに新たなグラフィクスオブジェクトを供給するオブジェクト定義セグメントとを含み、
先行するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間と、後続するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間とが動画ストリームにおける再生時間軸上でオーバーラップしている場合、
後続ディスプレイセットのオブジェクト定義セグメントは、既にオブジェクトバッファに存在しているグラフィクスオブジェクトがアップデートされない場合に限り、後続ディスプレイセットにおけるプレゼンテーション制御セグメントにより参照されるグラフィクスオブジェクトをオブジェクトバッファに供給する
ことを特徴とする記録媒体。
【請求項２】
前記オブジェクトバッファは、デコード済みのグラフィクスオブジェクトを格納しておくバッファであり、
グラフィクスオブジェクトには、識別子が割り当てられており、当該識別子は、オブジェクトバッファにおけるグラフィクスオブジェクトの占有領域を、一意に識別するものであり、
前記アップデートは、
先行するディスプレイセットのプレゼンテーショ制御セグメントにより参照されているグラフィクスオブジェクトと同一の識別子が付されたグラフィクスオブジェクトであって、先行するディスプレイセットのプレゼンテーション制御セグメントにより参照されているグラフィクスオブジェクトと異なるものを、後続するディスプレイセットがオブジェクトバッファに供給することでなされる
請求項１記載の記録媒体。
【請求項３】
前記ディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間は、
ディスプレイセットに属するプレゼンテーション制御セグメントのデコード開始時刻から、プレゼンテーション制御セグメントに基づき構成されたグラフィクス画面の表示開始時刻までであり
前記プレゼンテーション制御セグメントは、ディスプレイセットの先頭に位置しており、
プレゼンテーション制御セグメントは、デコード開始時刻、及び、画面構成の開始時刻を示す時間情報を含む
ことを特徴とする請求項１記載の記録媒体。
【請求項４】
プレゼンテーション制御セグメントは完結した状態で、１つのパケットに格納されており、
デコード開始時刻を示す時間情報とは、プレゼンテーション制御セグメントを格納したパケットのデコードタイムスタンプであり、
画面構成の開始時刻を示す時間情報とは、プレゼンテーション制御セグメントを格納したパケットのプレゼンテーションタイムスタンプである
ことを特徴とする請求項３記載の記録媒体。
【請求項５】
記録媒体と、再生装置とを含む再生システムであって、
記録媒体には、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されており、
グラフィクスストリームは、グラフィクス画面を実現するディスプレイセットを複数含み、
各ディスプレイセットは、プレゼンテーション制御セグメントと、オブジェクトバッファに新たなグラフィクスオブジェクトを供給するオブジェクト定義セグメントとを含み、
先行するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間と、後続するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間とが動画ストリームにおける再生時間軸上でオーバーラップしている場合、
後続ディスプレイセットのオブジェクト定義セグメントは、既にオブジェクトバッファに存在しているグラフィクスオブジェクトがアップデートされない場合に限り、後続ディスプレイセットにおけるプレゼンテーション制御セグメントにより参照されるグラフィクスオブジェクトをオブジェクトバッファに供給するものであり、
前記再生装置は、記録媒体からデジタルストリームを読み出し、これに多重化されたビデオストリーム、及び、グラフィクスストリームを再生するものであり、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードしてグラフィクスオブジェクトを得て、動画像に合成させるグラフィクスデコーダとを備え、
グラフィクスデコーダは、デコード済みのグラフィクスオブジェクトを格納しておくオブジェクトバッファを備え、
グラフィクスストリームは、グラフィクス画面を実現するディスプレイセットを複数含み、
各ディスプレイセットは、プレゼンテーション制御セグメントと、オブジェクトバッファに新たなグラフィクスオブジェクトを供給するオブジェクト定義セグメントとを含み、
先行するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間と、後続するディスプレイセットに属するプレゼンテーション制御セグメントのアクティブ期間とが動画ストリームにおける再生時間軸上でオーバーラップしている場合、
前記グラフィクスデコーダは、既にオブジェクトバッファに存在しているグラフィクスオブジェクトがアップデートされない場合に限り、後続ディスプレイセットにおけるプレゼンテーション制御セグメントにより参照されるグラフィクスオブジェクトをオブジェクトバッファに供給する
ことを特徴とする再生システム。
【請求項６】
前記グラフィクスデコーダは各ディスプレイセットに属するオブジェクト定義セグメントをデコードしてグラフィクスオブジェクトを得るプロセッサと、
デコードにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、
オブジェクトバッファに格納されたグラフィクスオブジェクトを読み出して、動画像と合成させるコントローラとを備え、
前記グラフィクスデコーダは
先行ディスプレイセットに属するグラフィクスオブジェクトをオブジェクトバッファに書き込む処理、後続ディスプレイセットに属するグラフィクスオブジェクトをオブジェクトバッファから読み出す処理を同時に実行する
ことを特徴とする請求項５記載の再生システム。
【発明の詳細な説明】【技術分野】
【０００１】
BD-ROM等の記録媒体に関し、特に、ビデオストリームと、グラフィクスストリームとを多重してなるデジタルストリームを再生して字幕表示を行う技術に関する。
【背景技術】
【０００２】
グラフィクスストリームの描画により実現される字幕表示は、ある言語圏で制作された映画作品を、他の言語圏の人々に鑑賞してもらうための、必要不可欠な手段である。動画を表すビデオストリームは、グラフィクスストリームと多重されて記録媒体に記録される。このグラフィクスストリームは、ディスプレイセットと呼ばれる表示制御セグメント、グラフィクスデータの集合を複数含む。これらディスプレイセットのそれぞれは、映画作品の再生にあたって、個々の字幕表示を実現するものである。動画の再生進行に伴ってこれらディスプレイセットを1つずつ記録媒体から読み出し、処理することで字幕は動画と共に表示されてゆく。
【０００３】
このように複数ディスプレイセットを処理するにあたって前のディスプレイセットの処理完了を待っていたのでは、処理に遅れが出る。そこでグラフィクスストリームに複数のディスプレイセットが存在する場合、これらディスプレイセットに対する処理を、並列化したいとの要望が出ている。
【特許文献１】特許第３１２８２２０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら字幕には、動画の再生進行と共に移り変わってゆくという性質がある。仮に2つのディスプレイセットに対する処理を並列化してしまえば、後に表示されるべき字幕と、先に表示されるべき字幕とが同時にデコードされ、後に表示される字幕が、先に表示される字幕の代わりに表示されてしまうことも有り得る。このような字幕の入れ代わりが起こり得ると、複数ディスプレイセットに対する処理を並列化する能力は、実質的に役にたたず、無用の長物と化す恐れがある。
【０００５】
本発明の目的は、複数ディスプレイセットに対する処理を並列化する能力が再生装置にあったとしても、本来の順序でグラフィクスを表示させることができる記録媒体を提供することである。
【課題を解決するための手段】
【０００６】
上述した目的を達成するため、本発明にかかる記録媒体は、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、グラフィクスストリームは、グラフィクス画面を実現するディスプレイセットを複数含み、各ディスプレイセットは、制御セグメントと、識別子が割り当てられたグラフィクスデータとを含み、先行するディスプレイセットに属する制御セグメントのアクティブ期間と、後続するディスプレイセットに属する制御セグメントのアクティブ期間とが動画ストリームにおける再生時間軸上でオーバーラップする場合、当該グラフィクスデータには、先行ディスプレイセット内の制御セグメントにより参照されるグラフィックスデータと異なる識別子が割り当てられることを特徴としている。
【発明の効果】
【０００７】
本発明は上述したように構成されているので、制御セグメントのアクティブ期間の重複が生じるのであれば、後続ディスプレイセットに属するグラフィクスデータが、先行ディスプレイセットに属するグラフィクスデータを上書きしないよう、これらのグラフィクスデータには別々の識別子が割り当てられるので、後のグラフィクスが先のグラフィクスの代わりに表示されてしまうことはない。表示の入れ代わりが生じないような保証を、識別子割り当てで実現することができるので、複数ディスプレイセットに対する処理を並列化する能力が再生装置にあった場合に、その能力を存分に発揮させることができる。
【発明を実施するための最良の形態】
【０００８】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、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における論理的な再生経路(Playlist)を定義したファイル(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をもった1つのグラフィクスオブジェクトがバラバラにされ、離散的に配置されると、グラフィクスオブジェクトを読み出すためのオーバヘッドが発生し、オブジェクトバッファ→グラフィックスプレーンの転送時にあたっての転送効率が落ちる。この効率低下は、グラフィクス−動画の同期表示に悪影響を及ぼしかねない。かかる事情から、オブジェクトバッファ上においてあるobject_idで識別されるグラフィクスオブジェクトが共有している領域は、同じ大きさと同じobject_idとをもったグラフィクスオブジェクトでのみ上書きできるとしている。
【００２５】
グラフィクスオブジェクト上書きにあたって、後続するグラフィクスオブジェクトのサイズは、先行するものと同じサイズでなければならない。先行するグラフィクスオブジェクトにより小さすぎてもいけないし、大き過ぎてもいけない。アップデートにあたってグラフィクスオブジェクトのサイズが同じになるようにグラフィクスオブジェクトを作成しておくというのは、オーサリング担当者にとっての責務になる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとが、同じobject_idをもっている場合、これらのグラフィクスオブジェクトでは縦横のサイズが変わっても良い。
【００２６】
『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』と、『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』、『window_id』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００３６】
『object_id』は、composition_object(i)に対応するウィンドゥ内に存在するODSの識別子を示す。
『window_id』は、本PCSにおいて、グラフィクスオブジェクトに割り当てられるべきウィンドゥを示す。1つのウィンドゥには最大2つのグラフィクスオブジェクトが割り当てられる。
【００３７】
『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)は、DSnにおけるPCSのアップデートに用いられる全グラフィクスオブジェクトのデコード及び表示に要する時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本DSn.PCSnの画面合成に用いられるオブジェクトをDSn.PCSn.OBJ[j]とした場合、decodeduration(DSn)は、ウィンドゥクリアに要する時間(i)、DSn.PCSn.OBJのデコード期間(ii)、DSn.PCSn.OBJの書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
【００５８】
decode_durationの計算は、図１４のプログラムに基づき行われる。また図１５、図１６（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図１５のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図１５のステップＳ１)。PLANEINITIALIZATINTIME関数(図１６（ａ）)は、DSnの表示を実現するため、グラフィックスプレーンの初期化に要する時間を求める関数である。図１５のステップＳ１では、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関数の戻り値と、window再描画に必要な時間を足し合わせた時間(90,000*(SIZE(DSn.WDS.WIN[0]))//256,000,000)が設定されることになる(ステップＳ９)。
【００６４】
以上はDSnのグラフィクスオブジェクトが1つである場合の処理である。図１５のステップＳ５は、グラフィクスオブジェクトの数が2であるかどうかを判定している。DSnのグラフィクスオブジェクトが2以上であれば(図１４のif(DSn.PCS.num_of_object==2))、PCSにおける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のデコードに要する期間を書込期間(、2つ目のODSのデコードに要する期間を書込期間(とする。図１９（ｂ）は、デコード期間(2)がクリア期間(1)＋書込期間(より長くなるケースを示す。この場合Decode_Durationは、デコード期間(2)＋書込期間(になる。
【００７２】
図１９（ｃ）は、クリア期間(1)＋書込期間(がデコード期間(2)より長くなるケースを示す。この場合Decode_Durationはクリア期間(1)＋書込期間(＋書込期間(になる。
グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またwindowのサイズ、ODSのサイズ、個数もオーサリングの段階で判明しているので、これらからDecode_Durationがクリア期間(1)＋書き込み期間(3)、デコード期間(2)＋書き込み期間(3)、デコード期間(2)＋書込期間(、クリア期間(1)＋書込期間(＋書込期間(のどれかになる。こうした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の説明である。ここでDTSに示される時刻から、PTSに示される時刻まで、PCSはactiveになる。PCSがactiveになっている期間を、Display SetのPCSのアクティブ期間という。
【００７６】
続いてDisplay SetのPCSのアクティブ期間重複について説明する。複数Display Setの処理が必要である場合、これらに対する処理を並列化したいとの要望がある。かかる並列化を再生装置に行わせるには、PCSのactive期間を重複させねばならない。しかしBluy-ray Disc Read-Only規格では、必要最低限の構成をもった再生装置で、デコードできることを保証しなければならない。
【００７７】
Bluy-ray Disc Read-Only規格のデコーダモデルは、パイプライン処理を前提にしたデコーダモデル(パイプラインデコーダモデル)である。パイプラインデコーダモデルとは、あるDisplay Setに属するグラフィクスオブジェクトをオブジェクトバッファから読み出すのと同時に、次のDisplay Setに属するグラフィクスオブジェクトをオブジェクトバッファに書き込む処理を行い得るデコーダモデルをいう。
【００７８】
再生装置がパイプラインデコーダモデルである場合、投入間隔が問題となる。ここで投入間隔とは、前のDisplay Setに対する処理開始から、次のDisplay Setに対する処理開始までの間隔をいう。ここで1つのDisplay Setに対する処理のうち、オブジェクトバッファに係るものは、ODSをデコードして、非圧縮グラフィクスをオブジェクトバッファに書き込む処理、非圧縮グラフィクスをオブジェクトバッファから読み出してグラフィックスプレーンに書き込む処理の2つである。そうすると、1つのDisplay SetのPCSのアクティブ期間における内訳は、図２０の通りとなる。図２０に示すように、1つのDisplay Setの処理の内訳は、『ODSをデコードしてオブジェクトバッファに書き込むのに要する期間』、『グラフィクスをオブジェクトバッファから読み出し、グラフィックスプレーンに書き込むのに要する期間』からなる。
【００７９】
パイプラインデコーダモデルでは、オブジェクトバッファへのグラフィクス書き込みと、オブジェクトバッファからのデータ読み出しとは同時に行なえるのだから、2つのDisplay Setに対する処理は、図２１に示すように、並列化することができる。図２１は、パイプラインデコーダモデルにおいて、2つのDisplay Set(DSn,DSn+1)に対する処理がどのように並列化されるかを示す図である。
【００８０】
本図に示すように、DSnに対する処理における『オブジェクトバッファからの読み出し期間』と、DSn+1に対する処理における『オブジェクトバッファへの書き込み期間』とが重複するように、これらDSn,DSn+1に対する処理の並列化はなされる。
図２１のような並列化は、DSnに属するグラフィクスオブジェクトが、オブジェクトバッファに書き込まれ、その書き込みが完了する時点以降に、DSn+1に属するグラフィクスオブジェクトが、オブジェクトバッファに書き込まれることを意味する。
【００８１】
DSnに属するODSのデコード終了時刻は、ENDセグメントのPTSに示されており、DSn+1に属するODSが最も早く開始されるのは、DTS(DSn+1[PCS])に示される時点であるので、
PTS(DSn[END])≦DTS(DSn+1[PCS])
との関係を満すよう、DSnのENDセグメントに対するタイムスタンプ、DSn+1のPCSに対するタイムスタンプを設定しておく。こうして投入間隔を設ければ、パイプラインモデルでの実行は可能になる。
【００８２】
3つのDisplay Setに対するPCSのアクティブ期間を、図２２に示すように、重複させる場合において、各Display Setに属する各機能セグメントのタイムスタンプを、再生時間軸上にどのように設定するかについて説明する。図２３は、各Display Setに属する各機能セグメントのタイムスタンプに対する設定を示す図である。本図においてDS0に属するWDS、PDS、ODSのDTS値は、PCSのDTS値と同じになるように設定されている。これは、Display SetPCSのアクティブ期間の開始直後に、ODSのデコードを開始させることを意図している。故にDS0に属する最初のODS1のデコードは、DTS(PCS)に示される時点に開始することになる。そしてDS0に属する最後のODSnのデコードは、ENDセグメントに示される時点PTS(END)で終了する。尚、DS0に属するWDS、PDS、ODSのDTS値は、PCSのDTS値より後の時点を示していてもよい。
【００８３】
一方、DS1に属するPCS1のDTS値は、PTS(END)の以降の時点を示すから、DS1に属するODSのデコードが、たとえDTS(PCS1)と同時期に開始されたとしても、これら2つのDisplay Setに対する処理をパイプラインで並列化することができる。
続いてグラフィックスプレーンへの書込処理の並列化について考察する。DSnに対する処理と、DSn+1に対する処理とが並列化されると、DSn+1に対する処理で得られたグラフィクスオブジェクトと、DSnに対する処理で得られたグラフィクスオブジェクトとが同時にグラフィックスプレーンに書き込まれ、DSnに属するグラフィクスオブジェクトがディスプレイに現れないという現象が起こりうる。
【００８４】
そこでDSnと、DSn+1との間には、以下の関係が成立するよう、DSn、DSn+1に属するPCSにPTSを付加する。PTS(DSn[PCS])+(90000×ΣSIZE(DSn[WDS].window[i]))//256,000,000
≦PTS(DSn+1[PCS])
ここでΣSIZE(WDS.WIN[i])はWDS[i]の総サイズであり、
(90000×ΣSIZE(DSn[WDS].window[i]))//256,000,000は、これの再描画に要する時間である。DSn+1の表示時刻を遅らせることで、DSn+1に属するグラフィクスオブジェクトが、DSnに属するグラフィクスオブジェクトを上書きしてしまうような事態を避けることができる。図２４は、このPTSの間隔を示す数式で現した図である。
【００８５】
ウィンドゥの大きさがグラフィックスプレーンの1/4である場合、上述した式では、PTS(DSn[PCS])と、PTS(DSn+1[PCS])との間隔は、動画の表示期間になる。
続いて重複の禁止事項について説明する。PCSのアクティブ期間の重複が許されないのは、あるDisplay Setに属するグラフィクスオブジェクトが、先行するDisplay Setに属するグラフィクスオブジェクトと同じobject_idが付されており、グラフィクスオブジェクトのアップデートが予定されている場合である。ここでDS0に、ID=1が付加されたODSAが存在しており、DS1にもobject_id=1が付加されたODSが存在しているものとする。
【００８６】
PCSのアクティブ期間の重複があれば、DS0の終了点までにDS1のODSが再生装置にロードされ、デコードされる。そうすると、DS0のグラフィクスオブジェクトは、DS1のグラフィクスオブジェクトにより上書きされてしまうので、DS0の表示時にあたって、DS0内のグラフィクスオブジェクトの代わりに、DS1に属するグラフィクスオブジェクトが表示されることになる。かかる事態を防止するため、グラフィクスオブジェクトのアップデートが予定されている場合は、Display SetのPCSのアクティブ期間の重複を禁じる。
【００８７】
図２５（ａ）（ｂ）は、2つのDSのパイプラインが認められるケースと、そうでないケースとを示す図である。本図におけるDS0は、ODSを有しており、DS1は、ODSを有している。。そしてDS1に属するODSC,Dに対し、DS0に属するODSA,Bと同じobject_idが付与されている場合、図２５（ａ）に示すように2つのDisplay Setの重複が認められる。一方、DS1に属するODSC,Dに対し、DS0に属するODSA,Bとは別のobject_idが付与されている場合、図２５（ｂ）に示すように2つのDisplay Setの重複は禁止される。
【００８８】
この禁止事項は、”ODS伝送の前倒し”で回避することができる。”ODS伝送の前倒し”とは、アップデートすべきグラフィクスオブジェクトと異なるobject_idをODSに割り当てておいて、オブジェクトバッファにODSに対応するグラフィクスオブジェクトを格納した後、事後的にこのグラフィクスオブジェクトに付加されたobject_idを変更し、先にオブジェクトバッファに格納されたグラフィクスオブジェクトを上書きしてしまうというものである。このような手法をとれば、上述した禁止事項の適用はない。先にオブジェクトバッファにロードされたグラフィクスオブジェクトの表示をまつことなく、そのグラフィクスオブジェクトを上書きするようなグラフィクスオブジェクトをオブジェクトバッファにロードすることができる。
【００８９】
アップデートにあたっては、かかる伝送の前倒しが有効なので、1つのDisplay Setには、自身のPCSにより参照されるODSだけではなく、後のDisplay SetのPCSにより参照されるODSも一緒に伝送されることが多くなる。しかしPCSにより参照されないODSを伝送するとなると、複数ODSを再生装置にロードするにあたって、どこまでが先のDisplay Setに属し、どこまでが後のDisplay Setに属するかという境界が曖昧になる。そこでDisplay Setにあたっては、自身に属するODSの後ろにENDセグメントを置くとの手法をとる。こうすることで再生装置はENDセグメントの参照により、1つのDisplay Setに属するODSの伝送終了を知得することができる。
【００９０】
図２６は、ENDセグメントによる伝送終了を説明するための図である。本図の第１段目は1つのDisplay Setに属する機能セグメントを示し、第２段目は、機能セグメントがBD-ROM上でどのように配置されているかを示す。PCS、WDS、PDS、ODSといった機能セグメントは、TSパケット化されて、TSパケット化されたビデオストリームと共にBD-ROMに記録される。
【００９１】
この際、機能セグメントに対応するTSパケット、ビデオストリームに対応するTSパケットはそれぞれATS,PCSと呼ばれるタイムスタンプが付加される。機能セグメントに対応するTSパケット、ビデオストリームに対応するTSパケットは、同じタイムスタンプ後を持つものが順に並ぶようにBD-ROM上で配列される。
そうするとDisplay Setに属するPCS、WDS、PDSは、BD-ROM上で連続して存在せず、これらの間にはビデオストリームに対応するTSパケット(図中の”V”)が挿入されることになる。これにより機能セグメントは、BD-ROM上で飛び飛びに出現する。機能セグメントに対応するTSパケットがBD-ROM上で飛び飛びに現れれば、どこまでのTSパケットが1つのDisplay Setに属するのかがにわかに区別できない。またDisplay Setには、自身のPCSで参照されないものも含まれているので、なおさら区別がつきにくい。しかし本実施形態では、ODSの後ろにENDセグメントを挿入することにしているので、Display Setを構成する機能セグメントが飛び飛びに出現するにしても、どこまでが自身に属するODSであるのかの区別が容易につく。
【００９２】
PCSのアクティブ期間の重複と、object_id割り当ての関係について、図２７にまとめてみた。以下、図２７（ａ）について説明する。本図で想定するのは、4つのDisplay Set(DS0、DS1、DS2、DS3)である。DS0は、何も表示しないよう記述されている。DS1のPCSはオブジェクトX、オブジェクトYを画面上に表示し、DS2のPCSはオブジェクトA、オブジェクトY、オブジェクトCを、DS3のPCSはオブジェクトDをそれぞれ画面に表示させるものである。
【００９３】
図２７（ｂ）は、各Display Setに属するODSと、各Display SetのPCSのアクティブ期間とを示す図である。DS0は、オブジェクトXを構成するODSを、DS1は、オブジェクトYを構成するODSを含み、DS2はオブジェクトA、オブジェクトB、オブジェクトCを構成するODSを、DS3はオブジェクトDを構成するODSを含む。表示されるグラフィクスオブジェクトと、伝送されるグラフィクスオブジェクトとが一致していないのは、伝送の前倒しを意図しているからである。
【００９４】
また4つのDisplay SetのPCSのアクティブ期間は、一部分ずつ重なり合うとの形態をなしている。一方、オブジェクトバッファにおける各グラフィクスオブジェクトの配置は、図２７（ｃ）に示すものとなる。
これらオブジェクトX,Y、オブジェクトA〜オブジェクトCにはそれぞれ0,1,2,3,4の識別子が付されているものとする。
【００９５】
以上のような4つのDisplay Setにおいて、最後のDisplay Set(DS3)に属するオブジェクトDに、どのようなobject_idが可能になるかについて考察する。
このときDS3に属するDS1に対し、割当可能となるobject_idは5,3,0になる。
5が割当可能なのは、DS0〜DS2においてobject_id＝5は未割当だからである。
3が割当可能なのは、3が付与されたオブジェクトBは、DS2に含まれているものの何れのDisplay SetのPCSからも参照されていないからである。
【００９６】
0が割当可能なのは、object_id=0が付与されたオブジェクトXは、DS1で表示されるものであり、DS1のPCSのアクティブ期間を経過すれば、たとえ同じobject_idを割り当てたしても、オブジェクトXの代わりにオブジェクトDが表示されてしまうとの不都合は起こり得ないからである。
逆にこれら以外のobject_id(1,2,4)をオブジェクトDに割り当てることはできない。もし割り当ててしまえば、DS2において表示されるべき3つのグラフィクスオブジェクト(オブジェクトA、オブジェクトY、オブジェクトC)のうち、どれかの代わりにオブジェクトDが表示されてしまうからである。
【００９７】
このようにPCSのアクティブ期間が重複しているDisplay SetのPCSのアクティブ期間にて参照されていないグラフィクスオブジェクトや、PCSのアクティブ期間が既に終了したDisplay SetのPCSで参照されているグラフィクスオブジェクトについては、同じobject_idを付加することが可能になる。
Display Setが有するPCSのアクティブ期間のオーバラップは、DSn及びDSn+1が、グラフィクスストリームにおける同じEpochに帰属していることを前提条件にしている。2つのDisplay Setが互いに異なるEpochに帰属している場合、これら2つのDisplay SetのPCSのアクティブ期間をオーバーラップさせることはできない。何故なら、DSnのPCSのアクティブ期間が終了までにDSn+1のPCSやODSが読み出されれば、DSnの終期において、オブジェクトバッファ及びグラフィックスプレーンをフラッシュすることができなくなるからである。
【００９８】
DSnがEPOCHmに属する最後のDSであり(これをEPOCHm DSlast[PCS]という)、DSn+1がEPOCHm+1に属する最初のDSである場合(これをEPOCHm+1 DSfirst[PCS]という)、これらPCSに対するPTS値は、以下の式を満たすように設定されねばならない。
PTS(EPOCHm DSlast[PCS]) ≦ DTS(EPOCHm+1 DSfirst[PCS])
Display Setが有するPCSのアクティブ期間のオーバラップは、グラフィクスストリームが、プレゼンテーショングラフィクスストリームであることを前提にしている。グラフィクスストリームには、このプレゼンテーショングラフィクスストリームの他に、対話的な表示を主目的としたインタラクティブグラフィクスストリームがある。
【００９９】
連続する2つのDisplay Set(DSn,DSn+1)がインタラクティブグラフィクスストリームに属している場合、オーバーラップの発生は認められず、DSnのPCSのアクティブ期間以降から、DSn+1のPCSのアクティブ期間が始まるように、時間情報は設定されねばならない。インタラクティブグラフィクスストリームにおいて、制御情報を格納したセグメントはInterractive Composition Segmentと呼ばれる。DSnのPCSのアクティブ期間の終点は、DSnに属するICSのPTS値により示され、DSn+1のPCSのアクティブ期間の始点は、DSn+1に属するICSのDTS値により示される。ここでPTS(DSn[ICS])及びDTS(DSn+1[ICS])は、以下の式を満たすように設定されねばならない。
【０１００】
PTS(DSn[ICS]) ≦ DTS(DSn+1[ICS])
以上がPCSのアクティブ期間のオーバーラップについての説明である。
これまでに説明した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つあり、これらのPCSのアクティブ期間が重複している場合、Compositionバッファ１６には処理すべきPCSが複数格納される。
Graphical Controller１７は、Graphicalコントローラ１７はPCSの解読を行い、PCSの解読結果に従って、グラフィクスオブジェクトのObject Buffer１５への書き込み、及び、Object Buffer１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Graphicalコントローラ１７による表示は、PCSを格納したPESパケットのPTSに示される時点において実行される。Graphicalコントローラ１７によるDSnに属するグラフィクスオブジェクトの表示から、DSn+1に属するグラフィクスオブジェクトの表示までの間隔は上述した通りである。
【０１１２】
続いて、PIDフィルタ３、Transport Buffer４a,b,c、グラフィクスプレーン８、CLUT部９、Coded Data Buffer１３〜Graphical Controller１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２９は、書込レートRx,Rc,Rd、グラフィクスプレーン８、transport Buffer４a、Coded Data Buffer１３、Object 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であれば(ステップＳ２２でYes)、ステップＳ２３においてSegmentKをCoded Data Buffer１３にロードする。
【０１２７】
無視フラグが1に設定されていれば(ステップＳ２２がNo)、ステップＳ２４においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップＳ２２がNoになって、無視されることになる(ステップＳ２４)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
【０１２８】
ステップＳ２７は、PCSにおけるcomposition_typeが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_typeがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップＳ３４に移行する。SegmentKがEpoch Startであるなら、ステップＳ３０において無視フラグを0に設定する。 ステップＳ３４は、ステップＳ２８と同じであり、先行するDSがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップＳ３０)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップＳ３５)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ１２に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
【０１３０】
DSが、図３４のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図３４の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、composition_typeがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図３３のフローチャートの対象となる。ステップＳ２７においてcomposition_typeは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_typeがEpoch StartであるDS1は、そのままCoded Data Buffer１３にロードされるが(ステップＳ２３)、PCSのcomposition_typeがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップＳ２９)、これを構成する機能セグメントはCoded Data Buffer１３にロードされず無視される(図３７の矢印rd2,ステップＳ２４)。またDS20については、PCSのcomposition_typeは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に示される位置に書き込む(ステップＳ５９)。以上の処理を繰り返せば、ウィンドゥに最大2つのグラフィクスオブジェクトが描かれることになる。
【０１３９】
ステップＳ４４は、現在の再生時点が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に示される位置に書き込む(ステップＳ６６)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
【０１４３】
以上のように本実施形態によれば、制御セグメントのアクティブ期間の重複が生じる場合、先行Display Setに属するグラフィクスオブジェクトが既にオブジェクトバッファ上に存在している場合、後続Display Setに属するグラフィクスオブジェクトが、このオブジェクトバッファ上の先行グラフィクスオブジェクトを上書きしないよう、これらのグラフィクスオブジェクトには別々のobject_idが割り当てられるので、後のグラフィクスが先のグラフィクスの代わりに表示されてしまうことはない。表示の入れ代わりが生じないような保証を、object_idの割り当てで実現することができるので、複数Display Setに対する処理を並列化する能力が再生装置にあった場合に、その能力を存分に発揮させることができる。
【０１４４】
(第２実施形態)
本実施形態は、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に対するパイプライン式を行わない。
【０１６０】
上述した変更実施は可能であるものの、請求項に係る各発明は、従来技術の技術的課題を解決するための手段を反映したものであるから、請求項に係る各発明の技術範囲は、従来技術の技術的課題解決が当業者により認識される技術範囲を超えることはない。故に、本願の請求項に係る各発明は、詳細説明の記載と、実質的な対応関係を有する。
【産業上の利用可能性】
【０１６１】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが可能なので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上利用可能性を有する。
【図面の簡単な説明】
【０１６２】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】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)より長くなるケースを示すタイミングチャートである。
【図２０】1つのDisplay Setに対する処理の内訳を示す図である。
【図２１】パイプラインデコーダモデルにおいて、2つのDisplay Set(DSn,DSn+1)に対する処理がどのように並列化されるかを示す図である。
【図２２】3つのDisplay Setに対するPCSのアクティブ期間を重複させる場合の一例を示す図である。
【図２３】各Display Setに属する各機能セグメントのタイムスタンプに対する設定を示す図である。
【図２４】各Display Setに属するPCSのタイムスタンプを示す図である。
【図２５】（ａ）2つのDisplay Setに対するPCSのアクティブ期間を重複させる場合の一例を示す図である。 （ｂ）2つのDisplay Setに対するPCSのアクティブ期間を重複させない場合の一例を示す図である。
【図２６】ENDセグメントによる伝送終了を説明するための図である。
【図２７】（ａ）〜（ｃ）は、PCSのアクティブ期間の重複と、object_id割り当ての関係を示す図である。
【図２８】本発明に係る再生装置の内部構成を示す図である。
【図２９】書込レート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
１４ Stream Graphics Processor
１５ Object Buffer
１６ Composition Buffer
１７ Graphical Controller
２０ 加算器
１００ BD-ROM
２００ 再生装置
３００ テレビ
４００ リモコン
【出願人】 【識別番号】０００００５８２１
【氏名又は名称】松下電器産業株式会社
【出願日】 平成１９年９月１８日（２００７．９．１８）
【代理人】 【識別番号】１０００９０４４６
【弁理士】
【氏名又は名称】中島 司朗

【識別番号】１０００７２４４２
【弁理士】
【氏名又は名称】松村 修治

【識別番号】１００１２５５９７
【弁理士】
【氏名又は名称】小林 国人
【公開番号】 特開２００８−７２７２６（Ｐ２００８−７２７２６Ａ）
【公開日】 平成２０年３月２７日（２００８．３．２７）
【出願番号】 特願２００７−２４１０５３（Ｐ２００７−２４１０５３）