再生装置、記録方法、再生方法、集積回路
【課題】グラフィックスプレーンに書き込むべきデータ量が多大であっても、ピクチャの表示と同期したグラフィクスのアップデートを実現することができる再生装置を提供する。
【解決手段】再生装置の対象となるAVClipには、グラフィクスストリームが多重されており、グラフィクスストリームは、複数のディスプレイセットを含み、そのうち先頭のものは、エポックスタートディスプレイセットであり、ノーマルケースディスプレイセットが後ろに存在する。これはクロップ情報及び位置情報が記載された制御データを含み、クロップ情報は、オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、プレーンメモリに転送するかを示し、位置情報は切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す。
【解決手段】再生装置の対象となるAVClipには、グラフィクスストリームが多重されており、グラフィクスストリームは、複数のディスプレイセットを含み、そのうち先頭のものは、エポックスタートディスプレイセットであり、ノーマルケースディスプレイセットが後ろに存在する。これはクロップ情報及び位置情報が記載された制御データを含み、クロップ情報は、オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、プレーンメモリに転送するかを示し、位置情報は切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す。
【発明の詳細な説明】
【技術分野】
【０００１】
BD-ROM等の再生装置に関し、特に、ビデオストリームと、グラフィクスストリームとを多重してなるデジタルストリームを再生して字幕表示を行う技術に関する。
【背景技術】
【０００２】
グラフィクスストリームの描画により実現される字幕表示は、ある言語圏で制作された映画作品を、他の言語圏の人々に鑑賞してもらうための、必要不可欠な手段である。字幕表示を実現する先行技術には、ETSI EN 300 743標準規格(ETSI:European Telecommunication Standards Institute)におけるピクセルバッファのメモリ割り当て方式がある。ここでピクセルバッファとは、伸長されたグラフィクスを一旦格納しておくメモリであり、再生時において再生装置は、このメモリ内のグラフィクスを、”グラフィックスプレーン”と呼ばれる表示用メモリに、書き込む。これによりグラフィクスは描画される。上述したメモリ割り当て方式は、ピクセルバッファに”Region”を定義し、伸長されたグラフィクスのうち、この”Region”に包含される部分をグラフィックスプレーンに書き込むというものである。例えば、「Good bye・・・」という字幕がピクセルバッファに存在しており、このうち「Go」の部分を包含するよう”Region”の位置・大きさを定義すれば、この「Go」の部分がグラフィックスプレーンに書き込まれて画面に表示される。また「Good」を包含するよう”Region”を定義すれば、この「Good」の部分が画面に表示される。
【０００３】
”Region”の定義と、グラフィックスプレーンへの書き込みとを繰り返し行えば、字幕「Good bye・・・」は、「Go」→「Good」→「Good bye」→「Good bye・・・」というように、余韻をもって徐々に画面に現れる。このような描画により、ワイプインという表示効果を実現することができる。これらの技術を記載した文献には、以下の非特許文献に掲げたものがある。
【非特許文献１】“Digital Video Broadcasting(DVB) Subtitling systems;Final draft ETSI EN 300 743”ETSI STANDARDS,EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE,SOPHIA-ANTIPO,FR
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで従来のETSI EN 300 743標準規格には、グラフィックスプレーンに対する書き込み負荷が大きい場合に、グラフィクスの表示と、ピクチャの表示との同期をどのように保証するかという考えが全くなかった。グラフィックスプレーンには、非圧縮状態のグラフィクスが書き込まれるので、グラフィクスの解像度が高ければ高い程、書き込み負荷が大きくなる。例えば、BD-ROMが予定しているグラフィクス(1920×1080という高解像度をもつグラフィクス)を描画しようとすると、グラフィックスプレーンに書き込むべきグラフィクスのサイズは最大2Mバイトになる。このような、多大なサイズをもつグラフィクスを、ピクチャの表示と同期させるには、グラフィックスプレーンへの書き込みに多大なバンド幅が必要となる。しかしグラフィックスプレーンへの書き込みに、高いバンド幅を要求することは、再生装置の低コスト化の妨げになる。仮に再生装置が常に合理的な書き込みを行うなら、グラフィックスプレーン書き込み時のバンド幅を低下させることができる。ここで合理的な書き込みとは、前回の表示内容との差分のみ、グラフィックスプレーンに書き込んでゆくという書き込みをいう。しかし、再生装置に常に合理的書き込み手法を要求するのも、ソフトウェアの実装の自由度を奪う結果になる。
【０００５】
このように、グラフィックスプレーンへの書き込み負荷が多大であると、高いバンド幅での動作や、合理的な手法での書き込みを再生装置に強いることになり、再生装置の製品開発を著しく阻害することになる。
本発明の目的は、グラフィックスプレーンに書き込むべきデータ量が多大であっても、ピクチャの表示と同期したグラフィクスのアップデートを実現することができる再生装置を提供することである。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明に係る再生装置は、ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームを再生する再生装置であって、ビデオストリームをデコードして動画像を得るビデオデコーダと、グラフィクスストリームをデコードするグラフィクスデコーダと、プレーンメモリと、を備え、前記グラフィクスデコーダは、エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、コントローラと、を備え、前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、前記グラフィクスストリームは、複数のディスプレイセットからなり、個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す、ことを特徴としている。
【発明の効果】
【０００７】
ピクチャに対応する平面(Plane)の一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
【０００８】
グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、オーサリングを行う制作者は、あらゆる再生装置での同期保証を実現することができる。
またウィンドゥ情報によりウィンドゥの位置や大きさを規定できるので、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。ピクチャ内の絵柄の邪魔にならないように、グラフィクスを表示させることができるので、ピクチャの絵柄に時間的な変動があっても、グラフィクスの見易すさを維持することができる。これにより映画作品の品質を高めることができる。
【０００９】
ここでワーストケースでのアップデートとは、全クリア＋再描画という最も効率が悪い処理でグラフィックスがアップデートされることをいう。ワーストケースを想定して、ウィンドゥの大きさを決める場合、前記ウィンドゥの縦幅、横幅は、ピクチャに対応する平面の1/xの大きさになるように定め、xは、ウィンドゥのアップデートレートと、ピクチャの表示レートとの比率に基づく実数とすることが望ましい。
【００１０】
このようにウィンドゥの大きさを定めれば、再生装置において、グラフィックスプレーンへの書き込みに必要なバンド幅は、ある決まった値になる。ミニマムスタンダードとして、このバンド幅を満たすよう、再生装置を構成すれば、ソフトウェアの実装がどのようなものであっても、ピクチャとの同期を実現することができる。
このように再生装置構成のためのミニマムスタンダードを提供することができるので、かかる転送レートというミニマムスタンダードさえ満たせば、その他の実装は、開発者が自由に定めることができるので、再生装置の開発にあたっての自由度が高まる。
【発明を実施するための最良の形態】
【００１１】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、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)、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つの字幕「本当は」「ウソだった」「あなたが」は画面の下側に、「ずっと」「すきだった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、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のみのDSv、又は、PCSのみの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では、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。画素の色にあたっては、一画素当たりのインデックス値(赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値))のビット長が8ビットになっており、これによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。グラフィクスオブジェクトによる字幕は、透明色の背景に、文字列を配置することで描画される。
【００２６】
ODSによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ODSは、図７（ａ）に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_insequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
【００２７】
『object_id』は、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する。グラフィクスストリームのEpochには、同じIDをもつODSが複数含まれる。同じIDをもつ複数のODSは縦横のサイズが同じであり、オブジェクトバッファの共通の領域が割り当てられる。同じIDをもつ複数ODSのうち1つが、この領域に読み出されれば、オブジェクトバッファにおけるODSは、同じIDをもつ後続のODSにより上書きされる。このように、ビデオストリームの再生進行に伴い、オブジェクトバッファ上のODSが、同じ識別子をもつ後続のODSにて上書きされることにより、ODSにおける絵柄は、時間的な変遷を遂げる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
【００２８】
『last_insequence_flag』、『object_data_fragment』について説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject_data_fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last_sequence_flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。
【００２９】
『Palette Difinition Segment(PDS)』は、色変換用のパレットを定義する情報である。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は、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0〜video_width-window_horizontal_position-1の値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので0〜video_height-window_vertical_position-1の値をとる。
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』と、『window情報(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に用いられるべきパレットを示す。
【００３７】
『window情報(1)・・・(n)』は、このPCSが属するDisplay Set内の、個々のウィンドゥをどのように制御するかを示す情報である。図８（ｂ）の破線wd1は、任意のwindow情報(i)の内部構成をクローズアップしている。この破線wd1に示すように、window情報(i)は、『object_id』、『window_id』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００３８】
『object_id』は、window情報(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_address』、『object_cropping_width』、『object_cropping_height』からなる。
【００４１】
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_address』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４２】
『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は、『あなたが』の横幅、縦幅を示す。こうすることにより、『あなたが』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。
【００４７】
DS1,2,3のPCSを以上のように記述することで、字幕の表示効果を実現することができる。その他の表示効果を実現するにあたっての、PCSの記述作法について説明する。
先ず初めにCut-In/Outの記述作法について説明する。図１３は、時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。
本図におけるwindow(x,y,u.v)におけるx,yは、window_vertical_position、window_horizontal_positionの値であり、u,vは、window_width、window_heightの値を示す。また本図のCropping Rectangle(a,b,c,d)におけるa,bは、object_cropping_vertical_position、object_cropping_horizontal_positionの値であり、c,dはobject_cropping_width、object_cropping_heightの値である。本図の再生時間軸の時点t11,t12,t13には、DS11,DS12,DS13が存在している。
【００４８】
時点t11に存在するDS11は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Credit:」を表すODS＃0、ENDを有する。
時点t12に存在しているDS12は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS＃1を含む。
【００４９】
時点t13に存在しているDS13は、Composition_StateがNormal Caseであり、クロップされたグラフィクスオブジェクトを消すよう、object_cropped_flagが0に設定されたPCS＃2を含む(No Cropping Rectangle Visible)。
以上のDisplay Setにより、t11では字幕「Credit:」は非表示になっているが、t12で表示され、t13で再び非表示になる。これによりCut-In/Cut-Outという表示効果が実現される。
【００５０】
続いてFade-In/Outという表示効果を実現する際の、Display Setの記述作法について説明する。図１４は、時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。本図の時点t21,t22,t23,t24には、DS21,DS22,DS23,DS24が存在している。
時点t21に存在するDS21は、Composition_StateがEpoch Startに設定され、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Fin」を表すODS＃0、ENDを有する。
【００５１】
時点t22に存在しているDS22は、Composition_StateがNormal CaseであるPCS＃1と、PDS＃1とを含む。このPDS＃1は、PDS＃0と同じ色彩の赤色差、青色差を示しておりながら、高い輝度値をもっているものとする。
時点t23に存在しているDS23は、Composition_StateがNormal CaseであるPCS＃3と,PDS＃2と,ENDとを含む。このPDS＃2は、PDS＃0と同じ色彩の赤色差、青色差を示しておりながら、低い輝度値をもっているものとする。
【００５２】
時点t24に存在するDS24は、Composition_StateがNormal Caseに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS、ENDを有する。
これら一連のDisplay Setは、1つ前のDisplay Setと異なるPDSを指定しているため、Epoch内の複数PCSにおいて表示されるグラフィクスオブジェクトは、徐々に輝度値が高められたり、弱められることになる。これによりFade-In/Outという表示効果の実現が可能になる。
【００５３】
続いてScrollingの記述作法について説明する。図１５は、時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。本図における表記は、図１３の一例に準ずる。
AVClip再生時間軸の時点t31に存在するDS31は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Credit: Company」を表すODS＃0、ENDを有する。
【００５４】
時点t32に存在するDS32は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃1を含む。オブジェクトバッファにおいて(0,0)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち「Credit:」が存在するので、この「Credit:」がグラフィックスプレーンに出現することになる。
【００５５】
時点t33に存在するDS33は、Composition_StateがNormal Caseであり、オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲を切り出し(Cropping Rectangle＃0(0,100,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃2を含む。オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち、「Credit:」の下半分と、「Company」の上半分とが存在するので、これらの部分がグラフィックスプレーンに出現することになる。
【００５６】
時点t34に存在するDS34は、Composition_StateがNormal Caseであり、オブジェクトバッファの座標(0,200)から横600×縦400の範囲を切り出し(Cropping Rectangle＃0(0,200,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃3を含む。オブジェクトバッファ上の座標(0,200)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち、「Company」が存在するので、２段表記の字幕のうち「Company」の部分が画面上に現れることになる。以上のPCSの記述により、「Credit:」「Company」という２段表記の字幕の下スクロールがなされることになる。
【００５７】
続いてWipe-In/Outの記述作法について説明する。図１６は、時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。本図における表記は、図１３の一例に準ずる。
本図の時点t51に存在するDS51は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Fin」を表すODS＃0、ENDを有する。
【００５８】
時点t52に存在するDS52は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃1を含む。(0,0)から横600,縦400の範囲には、「Fin」という字幕が存在するので、この「Fin」がグラフィックスプレーンに出現することになる。
【００５９】
時点t53に存在するDS53は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(200,0)から縦400×横400の範囲でクロップを行い(Cropping Rectangle＃0(200,0,400,400))、座標(200,0)を基準にして、表示を行わせるPCS＃2を含む(on window＃0(200,0))。そうすると、(200,0)〜(400,400)が表示範囲内になり、(0,0)〜(199,400)は、非表示範囲になる。
【００６０】
時点t54に存在するDS54は、Composition_StateがNormal Caseであり、オブジェクトバッファにおけるグラフィクスオブジェクトの(400,0)から横200×縦400の範囲でクロップを行い(Cropping Rectangle＃0(400,0,200,400))、座標(400,0)を基準にして、ウィンドゥの表示を行わせる(on window＃0(400,0))PCS＃3を含む。そうすると、(0,0)〜(399,400)は、非表示範囲になる。
【００６１】
グラフィックスプレーンの非表示範囲が広がるに伴い、表示範囲が狭まるのでWipe-In/Outが実現されることになる。
このようにPCSの記述次第でCut-In/Out,Fade-In/Out,Wipe-In/Out,Scrollというような多様な表示効果を実現することができるので、字幕描画に様々な工夫を凝らすことができる。
【００６２】
かかる表示効果実現にあたっての制約について説明する。図１３〜図１６の表示効果のうち、Scrollingの実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。図１５のt32−t33間で考えれば、Scrollingの実現のためには、t32における「Credit:」なるグラフィクスオブジェクトをグラフィックスプレーンから消し去るというウィンドゥクリアと、「Credit:」の下半分、「Company」の上半分をグラフィックスプレーンに書き込むというウィンドゥ再描画とをt32−t33の時間間隔で実現せねばならない。この時間間隔がビデオフレームの時間間隔である場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
【００６３】
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートを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においてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
【００６８】
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
【００６９】
図１７は、ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。グラフィクスオブジェクトが4つ存在する場合、エッジの数は8つになるのでグラフィクスオブジェクトが2つ存在する場合と比べると、エッジの数は2倍になっている。
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が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[ODS])に示されるので、これにデコードを要する最長時間を加えた時刻が、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])
続いてPCSのDTS、PTSの設定について説明する。
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のデコード期間(ii)、DSn.PCSn.OBJの書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
【００７７】
decode_durationの計算は、図１８のプログラムに基づき行われる。また図１９、図２０（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図１９のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図１９のステップＳ１)。PLANEINITIALIZATINTIME関数(図２０（ａ）)は、Display Setを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図１９のステップＳ１では、DSn,DSnPCS.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におけるOBJ[0]を引数として、wait関数を呼び出し、その戻り値をdecode_durationに加算する(ステップＳ１０)。
【００８４】
続くステップＳ１１は、DSnのOBJ[0]が属するwindowが、グラフィクスオブジェクト[1]が属するwindowと同一かどうかの判定であり(if(DSn.PCS.OBJ[0].window_id == DSn.PCS.OBJ[1].window_id)、もし同一であるなら、OBJ[1]を引数にして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に加える(ステップＳ１５)。OBJ[1]を引数にして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)＋デコード期間(2)になる。問題は、クリア期間(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の書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。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の再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上が再生時間軸に対するDisplay Setの割り当てについての説明である。
Display Setに対するDTS、PTSの設定について、図２４〜図２５の具体例を交えながら説明する。図２４は、4回のグラフィックスプレーンへの書き込みにより字幕を表示することを想定した具体例である。この具体例は、2つの字幕『what is blu-ray』、『blu-ray is everywhere』を1つずつ表示させるというアップデートを想定している。図２４は、本具体例が想定しているアップデートの、時間的変遷がどのようなものであるかを示す図である。時点t1では『what』までを表示し、続く時点t2では『what is』まで、時点t3では『what is blu-ray』全体を表示させる。字幕の全貌を明らかにした上で時点t4において別の字幕『blu-ray is everywhere』を表示させるのである。
【００９６】
図２５（ａ）は、かかるアップデートを実現するため、記述された4つのDisplay Setを示す図である。DS1は、時点t1におけるアップデートを制御するPCS1.2と、彩色のためのPDS1と、字幕『what is blu-ray』に相当するODS1と、DS1の終了コードであるENDとからなる。
DS2は、時点t2におけるアップデートを制御するPCS1.2と、ENDとからなる。DS3は、時点t3におけるアップデートを制御するPCS1.3と、ENDとからなる。DS4は、時点t2のアップデートを制御するためのPCS2と、色変換のためのPDS2と、字幕『blu-ray is everywhere』に相当するODS2と、ENDとからなる。
【００９７】
これら4つのDisplay Setに属する各機能セグメントのDTS、PTSをどのように設定するかを、図２５（ｂ）のタイミングチャートを参照して説明する。
このタイミングチャートの再生時間軸は、図２４の再生時間軸と同じものである。このタイミングチャートにおいて、PTS(PCS1.1)、PTS(PCS1.2)、PTS(PCS1.3)、PTS(PCS2)は、それぞれ『what』の表示時点t1,『what is』の表示時点t2,『what is blu-ray』の表示時点t3,『blu-ray is everywhere』の表示時点t4を示すよう設定される。これは、それぞれの字幕の表示時点において各PCSに記述された制御(Cropなど)を実行する必要があるからである。
【００９８】
PTS(ODS1),PTS(ODS2)は、PTS(PCS1.1)及びPTS(PCS2)の時点からDecode_Durationを差し引いた時点を示すよう設定されている。PTS(PCS)は、数式PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)を満たすよう設定する必要があるからである。
図２５（ｂ）では、時点t4より手前の時点t5を示すよう、PTS(ODS2)は設定されており、時点t1より手前の時点t0を示すよう、PTS(ODS1)は設定されている。DTS(ODS1),DTS(ODS2)は、PTS(ODS1)及びPTS(ODS2)の時点からデコード期間を差し引いた時点を示すよう設定されている。DTS(ODS)は、数式PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)を満たすよう設定する必要があるからである。図２５（ｂ）では、時点t5より手前の時点t0を示すよう、PTS(ODS2)は設定されており、時点t0より手前の時点を示すよう、PTS(ODS1)は設定されている。
【００９９】
ここでDTS(ODS2)=PTS(ODS1)の関係が満たされことがわかる。これにより再生装置の実装によっては、ODS1がオブジェクトバッファに読み出された後、このオブジェクトバッファ上のODS1を上書きする形で、ODS2を読み出すことができる。あるODSのPTSを、先に表示すべきODSのPTSに設定しておけば、古いODSを上書きする形で、新しいODSをメモリに読み出すという動作を再生装置が行うことにより、小メモリ規模での再生処理を実現することができる。かかる再生処理の実現により、再生装置におけるメモリ規模の選択の幅は広がる。
【０１００】
PCS1.1のDTSは、DTS(PCS1.1)＝DTS(ODS1)になるように設定されている。これは、PCS1.1のDTS値は、DTS(ODS1)により示される時点以前であるなら、どの時点でもよいからである。
ODS1のPTS値、ODS2のDTS値、PCS1.2、PCS1.3、PCS2のPTS値は、PTS(ODS1)＝DTS(ODS2)＝PTS(PCS1.2)＝PTS(PCS1.3)＝DTS(PCS2)の関係を満たすよう、何れも時点t0に設定されている。
【０１０１】
これは、PCS1.2、PCS1.3のDTS値は、PTS(PCS1.2)、PTS(PCS1.3)以前であれば、どの時点でもよく、またPCS2のDTS値も、DTS(PCS2)以前であれば、どの時点でもよいという自由度があるからである。これにより、複数のPCSをまとめて読み出しておき、前のPCSによるアップデートの実行が終われば続くPCSによるアップデートを即座に実行することができる。
【０１０２】
PCSのDTS・PTS、ODSのDTS・PCSは、上述の数式で示したような不等号の関係さえ最低限満たせばよいので、DTS(ODS2)=PTS(ODS1)になるように設定したり、PTS(ODS1)＝DTS(ODS2)＝PTS(PCS1.2)＝PTS(PCS1.3)＝DTS(PCS2)になるように設定することも可能になる。こうしたタイムスタンプの設定により、デコード負荷が発生する期間やバッファの占有量が増える期間を、調整することができる。かかる調整が可能になるので、再生時になしえる再生制御の幅が広がり、オーサリングを行う技術者及び再生装置を製造する技術者にとってのメリットは大きい。これで、DTS,PTS設定の具体例の説明を終える。
【０１０３】
以上説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-ray Disc Prerecording 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,b,cからTSパケットが取り出される速度を速度Rxとする
周辺回路４dは、Transport Buffer４a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCoded Data Buffer１３に格納される。
【０１０６】
ビデオデコーダ５は、PIDフィルタ３から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、PIDフィルタ３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
【０１０７】
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
CLUT部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
加算器１０は、CLUT部９により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
【０１０８】
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。このグラフィクスデコーダ１２は、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 Processor１４によるデコードは、ODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。上述したグラフィックオブジェクトのデコードレートRdは、このStream Graphics Processor１４の出力レートである。
【０１１２】
Object Buffer１５は、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor１４のデコードにより得られたグラフィクスオブジェクトが配置される。Object Buffer１５は、グラフィクスプレーン８の2倍／4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン８の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【０１１３】
Composition Buffer１６は、PCS、PDSが配置されるメモリである。
Graphical Controller１７は、Composition Buffer１６に配置されたPCSを解読して、PCSに基づく制御をする。この制御の実行タイミングは、PCSに付加されたPTSの値に基づく。以上が再生装置の構成要素である。
続いて、PIDフィルタ３、Transport Buffer４a,b,c、グラフィクスプレーン８、CLUT部９、Coded Data Buffer１３〜Graphical Controller１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２７は、書込レートRx,Rc,Rd、グラフィクスプレーン８、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のデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
【０１２１】
以上が再生装置の内部構成である。続いて制御部２０及びグラフィクスデコーダ１２を、どのようにして実装するかについて説明する。制御部２０は、図３０の処理手順を行うプログラムを作成し、汎用ＣＰＵに実行させることにより実装可能である。以降、図３０を参照しながら、制御部２０の処理手順について説明する。
図３０は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(PCS,WDS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップＳ２１〜Ｓ２４、ステップＳ２７〜Ｓ３１の処理を全てのSegmentKについて繰り返すループ構造を有している(ステップＳ２５、ステップＳ２６)。
【０１２２】
ステップＳ２１は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップＳ２７、ステップＳ２８の判定を行う。
ステップＳ２２は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップＳ２３に移行し、1であるならステップＳ２４に移行する。無視フラグが1であれば(ステップＳ２２でYes)、ステップＳ２３においてSegmentKをCoded Data Buffer１３にロードする。
【０１２３】
無視フラグが0に設定されていれば(ステップＳ２２がNo)、ステップＳ２４においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップＳ２２がNoになって、無視されることになる(ステップＳ２４)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
【０１２４】
ステップＳ２７は、PCSにおけるsegment_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におけるsegment_typeがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップＳ３４に移行する。SegmentKがEpoch Startであるなら、ステップＳ３０において無視フラグを0に設定する。 ステップＳ３４は、ステップＳ２８と同じであり、先行するDSがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップＳ３０)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップＳ３５)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ１２に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
【０１２６】
DSが、図３１のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図３１の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、segment_typeがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図３０のフローチャートの対象となる。ステップＳ２７においてsegment_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のsegment_typeがEpoch StartであるDS1は、そのままCoded Data Buffer１３にロードされるが(ステップＳ２３)、PCSのsegment_typeがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップＳ２９)、これを構成する機能セグメントはCoded Data Buffer１３にロードされず無視される(図３４の矢印rd2,ステップＳ２４)。またDS20については、PCSのsegment_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_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５０)。
【０１３１】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ５１)。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３２】
ステップＳ５２は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン８に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして(ステップＳ５３)、ステップＳ４９に移行する。これにより、別のODSに対しても、ステップＳ４９〜Ｓ５１の処理が繰り返し行われる。
次に図３６を参照して、ステップＳ４２、ステップＳ５４〜ステップＳ５９について説明する。
【０１３３】
ステップＳ４２は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップＳ５４においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップＳ５５〜ステップＳ５９のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップＳ５７〜ステップＳ５９を実行するというものである。ステップＳ５７は、object_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５８)。
【０１３４】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ５９)。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３５】
ステップＳ４４は、現在の再生時点がPDSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップＳ６０においてPallet_update_flagが1を示しているか否かを判定する。もし1を示しているなら、pallet_idに示されるPDSをCLUT部に設定する(ステップＳ６１)。0を示しているなら、ステップＳ６１をスキップする。
その後、グラフィクスプレーン８におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する(ステップＳ６２)。
【０１３６】
次に図３７を参照して、ステップＳ４３、ステップＳ６４〜ステップＳ６６について説明する。
ステップＳ４３は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップＳ６３においてウィンドゥが2つであるか否かを判定し、もし1つであれば、メインルーチンにリターンする。ウィンドゥが2つであるなら、ステップＳ６４〜ステップＳ６６を行う。ステップＳ６４は、object_crop_flagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ６５)。
【０１３７】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ６６)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
【０１３８】
以上、DSnに属するPCSのDTS,PTS,ODSのDTS、PTSの設定について説明したが、PDSのDTS、PTS、ENDのDTS、PTSについては説明していない。先ず、DSnに属する各PDSのDTS,PTSの設定について説明する。
DSnに属する各PDSは、PCSがComposition Buffer１６にロードされる時点(DTS(DSn[PCS]))から、最初のODSのデコード開始時点(DTS(DSn[ODS1]))までに、CLUT部９において、有効になればよい。このことからDSnに属する各PDS(PDS1〜PDSlast)のPTS値は、以下の関係を満たす値に、設定されねばならない。
【０１３９】
DTS(DSn[PCS])≦PTS(DSn[PDS1])
PTS(DSn[PDSj])≦PTS(DSn[PDSj+1])≦PTS(DSn[PDSlast])
PTS(DSn[PDSlast])≦DTS(DSn[ODS1])
尚、PDSにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
【０１４０】
以上の関係を満たすようDTS、PDSが設定された場合、再生装置のパイプラインにおいてこれらDTS、PTSがどのような役割をもつかについて説明する。図３８はPDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。この図３８は、図２８をベースにして作図されている。図３８において第１段目は、CLUT部９へのPDS設定を示している。以降の段は、図２８の第１〜第５段目と同じである。PDS1〜lastのCLUT部９への設定は、PCS,WDSの転送後、ODS1のデコードより前になされるので、矢印up2,up3に示すようにODS1のDTSに示される時点より前に設定されている。
【０１４１】
以上のようにPDSの設定は、ODSのデコードの先立ちなされることがわかる。
続いてDSnに属するEND of Display SetSegmentのPTSの設定について説明する。DSnに属するENDは、DSnの終わりを示すものだから、ODS2のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2(ODSlast)のPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定されねばならない。
【０１４２】
PTS(DSn[END]) = PTS(DSn[ODSlast])
DSn,DSn+1に属するPCSとの関係で考えれば、DSnにおけるPCSは、最初のODS(ODS1)のロード時刻以前に、Composition Buffer１６にロードされるから、ENDのPTSは、DSnに属するPCSのロード時刻(DTS(DSn[PCS]))以降、DSn+1に属するPCSのロード時刻(DTS(DSn+1[PCS]))以前でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
【０１４３】
DTS(DSn[PCS])≦PTS(DSn[END])≦DTS(DSn+1[PCS])
一方、最初のODS(ODS1)のロード時刻は、最後のPDS(PDSlast)のロード時刻以前であるから、ENDのPTS(PTS(DSn[END]))は、DSnに属するPDSのロード時刻以降(PTS(DSn[PDSlast]))でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
【０１４４】
PTS(DSn[PDSlast])≦PTS(DSn[END])
続いて再生装置のパイプラインにおいて、ENDのPTSが、どのような意味合いをなすのかについて説明する。図３９は、再生装置のパイプライン動作時における、ENDの意味合いを示す図である。本図は、図２８の第２段目以降をベースに作図しており、第２段以降の意味合いは図２８と同一である。また本図では、DSn,DSn+1という2つのDisplay Setを描いている。DSnにおいてODSlastになるのは、A-ODSsの最後のODSnであるので、ENDのPTSは、このODSnのPTSを示すよう設定されている。そして、このENDのPTSに示される時点は、DSn+1のPCSのDTSにより示される時点より早いものになっている。
【０１４５】
このENDのPTSにより、再生時にあたっては、DSnについてのODSのロードが、どの時点で完了するのかを知得することができる。
尚、ENDにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
以上のように本実施形態によれば、グラフィックプレーンの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。グラフィックプレーンの25%〜33%など、ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。グラフィックプレーンのうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
【０１４６】
グラフィックプレーンの1/4等、グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、再生装置は、256Mbps等、ある決まった転送レートでグラフィックプレーンの書き込みを行いさえすれば、ピクチャとの同期を実現することができる。
同期保証が容易になるので、高い解像度での字幕表示を多くの再生装置において実現することができる。
【０１４７】
(第２実施形態)
第１実施形態では、ビデオフレーム毎にグラフィクスをアップデートできるように、ウィンドゥの大きさをグラフィックスプレーン全体の1/4とし、グラフィックスプレーンへの書込レートRcを256Mbpsとした。またアップデートレートを、ビデオフレームレートの1/2,1/4とすることにより、大きなサイズのグラフィクスのアップデートの実現も可能とした。しかしアップデートレートをビデオフレームレートの1/2,1/4とした場合、グラフィックスプレーンへの書き込みは、2,4ビデオフレームを要する。そしてグラフィックスプレーンが1つであれば、この書き込みに費やされる2,4フレームの間、グラフィクスが書き込まれる過程がユーザに見えてしまう。そうすると、あるグラフィクスから大きなグラフィクスへと瞬時に切り換わるような表示効果は実現できない。そこで第２実施形態ではグラフィックスプレーンを2つ設ける。図４０は、第２実施形態に係る再生装置の内部構成を示す図である。本図が図２６、図２７と比較して新規なのは、グラフィックスプレーンが2つ有り(図中のグラフィクスプレーン８１、グラフィクスプレーン８２)、この2つのグラフィックスプレーンがダブルバッファを構成している点である。そのため、2つのグラフィックスプレーンのうち一方からの読み出しが行われている間、他方のグラフィックスプレーンへの書き込みは可能になる。そして第２実施形態に係るGraphical Controller１７は、この読出対象の切り換えをPCSに付与されているPTSの時点に実行する。
【０１４８】
図４１は、ダブルバッファによるグラフィックスプレーン読み出し／書き込みを模式的に示す図である。本図の縦軸方向は、グラフィクスプレーン８１、グラフィクスプレーン８２の格納内容を、横軸方向は、1フレーム目、2フレーム目、3,4,5フレーム目のグラフィックスプレーンの格納内容を示している。そしてグラフィクスプレーン８１、グラフィクスプレーン８２の格納内容のうち、太い枠で囲まれているものが、読み出しの対象になっている。本図では、グラフィクスプレーン８１に顔マークが格納されており、これを太陽マークに置き換えることを意図している。太陽マークはObject Buffer１５に存在しており、4MByteのサイズをもつ。この4MByteのサイズは、Object Buffer１５の目一杯のサイズである。
【０１４９】
太陽マークを、グラフィクスプレーンへの書込レート(Rc=256Mbps)で書き込むなら、グラフィクスプレーン８２への書き込み完遂に4フレームがかかる。そしてこの書き込みに費やされる4フレームという期間において、1フレーム目では太陽マークのグラフィクスは1/4だけ、2フレーム目では2/4、3フレーム目では3/4だけ書き込みがなされる。しかし1フレームから4フレーム目までは、グラフィクスプレーン８１、グラフィクスプレーン８２のうち、読出対象がグラフィクスプレーン８１なので、これら太陽マークがグラフィックスプレーンに書き込まれている過程は、ユーザには見えない。5フレーム目においてグラフィックスプレーンの読出対象がグラフィクスプレーン８２に移った段階で、グラフィクスプレーン８２の格納内容はユーザに見える。これにより顔マークから太陽マークへの切り換わり時になされる。
【０１５０】
以上のように本実施形態によれば、4フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯に映画制作者、制作スタッフ、出演者の氏名のクレジットを表示する場合や、映画のあらすじ、警告文を、瞬時に表示する場合に有意義である。
(第３実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図４２は、第３施形態に係るBD-ROMの製造工程を示すフローチャートである。
【０１５１】
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２０９を含む。
【０１５２】
ステップＳ２０４において、字幕の表示範囲となる windowを定義するようWDSを記述し、ステップＳ２０５では、windowが同じになる再生区間を Epochとし、個々のEpochにおけるPCSを記述する。
こうしてPCSが得られれば、ステップＳ２０６において字幕素材たるグラフィクスをODSに変換し, これをPCS、WDS、PDSを組み合わせることでDisplay Setを得る。その後、ステップＳ２０７では、Display Setにおける各機能セグメントを PESパケット化し、タイムスタンプを付与することによりグラフィクスストリームを得る。
【０１５３】
最後に、ステップＳ２０８では、グラフィクスストリームを別途生成されたビデオストリーム、 オーディオストリームと多重することでAVClipを生成する。
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データであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１６３】
(H)PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
(I)PCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBD-ROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
【０１６４】
(J)第１実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25%に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
【０１６５】
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。
(K)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
【０１６６】
(L)グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、商標を構成するような図形,文字,色彩の組合せや、国の紋章,旗章,記章,国家が採用する監督/証明用の公の記号・印章、政府間国際機関の紋章,旗章,記章,特定商品の原産地表示を含んでいてもよい。
(M)第１実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
【０１６７】
(N)各実施形態におけるAVClipは、映画作品を構成するものであったが、AVClipはカラオケを実現するものであってもよい、そしてこの場合、PCSは歌の進行に応じて、字幕の色を変えるという表示効果を実現してもよい。
【産業上の利用可能性】
【０１６８】
本発明に係る記録媒体、再生装置は、表示効果を伴う字幕表示を実現することができるので、より付加価値が高い映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図面の簡単な説明】
【０１６９】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの構成を示す図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】字幕の表示位置と、Epochとの関係を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトの定義を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造で構成される。
【図９】字幕表示を実現するためのDisplay Setの記述例である。
【図１０】DS1におけるWDS、PCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DS3におけるPCSの記述例を示す図である。
【図１３】時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。
【図１４】時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。
【図１５】時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。
【図１６】時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。
【図１７】ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。
【図１８】decode_durationの計算アルゴリズムの一例を示す図である。
【図１９】図１８のプログラムのアルゴリズムを図式化したフローチャートである。
【図２０】（ａ）（ｂ）図１８のプログラムのアルゴリズムを図式化したフローチャートである。
【図２１】（ａ）1つのwindowに1つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１８で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図２２】（ａ）1つのwindowに2つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１８で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図２３】（ａ）2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定したタイミングチャートである。 （ｂ）デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示すタイミングチャートである。 （ｃ）クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示すタイミングチャートである。
【図２４】アップデートの、時間的変遷の具体例を示す図である。
【図２５】（ａ）図２４に示したアップデートを実現するため、記述された4つのDisplay Setを示す図である。 （ｂ）図２５（ａ）におけるDisplay Setに属する各機能セグメントのDTS、PTSがどのように設定されているかを示すタイミングチャートである。
【図２６】本発明に係る再生装置の内部構成を示す図である。
【図２７】書込レートRx,Rc,Rd、グラフィクスプレーン８、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【図２８】再生装置によるパイプライン処理を示すタイミングチャートである。
【図２９】ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。
【図３０】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図３１】多重化の一例を示す図である。
【図３２】DS10が再生装置のCoded Data Buffer１３にロードされる様子を示す図である。
【図３３】通常再生が行われる場合を示す図である。
【図３４】図３３のように通常再生が行われた場合のDS1,10,20のロードを示す図である。
【図３５】Graphical Controller１７の処理手順を示すフローチャートである。
【図３６】Graphical Controller１７の処理手順を示すフローチャートである。
【図３７】Graphical Controller１７の処理手順を示すフローチャートである。
【図３８】PDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。
【図３９】再生装置のパイプライン動作時における、ENDの意味合いを示す図である。
【図４０】第２実施形態に係る再生装置の内部構成を示す図である。
【図４１】ダブルバッファによるグラフィックスプレーン読み出し／書き込みを模式的に示す図である。
【図４２】第３施形態に係るBD-ROMの製造工程を示すフローチャートである。
【符号の説明】
【０１７０】
１ BDドライブ
２ Read Buffer
３ PIDフィルタ
４ TBバッファ
５ ビデオデコーダ
６ ビデオプレーン
７ オーディオデコーダ
８ グラフィクスプレーン
９ CLUT部
１０ 加算器
１２ グラフィクスデコーダ
１３ Coded Data Buffer
１４ Stream Graphics プロセッサ
１６ Composition バッファ
１７ Graphicsコントローラ
１８ UOコントローラ
１９ プレーヤレジスタ群
２０ 制御部
２００ 再生装置
３００ テレビ
４００ リモコン
【技術分野】
【０００１】
BD-ROM等の再生装置に関し、特に、ビデオストリームと、グラフィクスストリームとを多重してなるデジタルストリームを再生して字幕表示を行う技術に関する。
【背景技術】
【０００２】
グラフィクスストリームの描画により実現される字幕表示は、ある言語圏で制作された映画作品を、他の言語圏の人々に鑑賞してもらうための、必要不可欠な手段である。字幕表示を実現する先行技術には、ETSI EN 300 743標準規格(ETSI:European Telecommunication Standards Institute)におけるピクセルバッファのメモリ割り当て方式がある。ここでピクセルバッファとは、伸長されたグラフィクスを一旦格納しておくメモリであり、再生時において再生装置は、このメモリ内のグラフィクスを、”グラフィックスプレーン”と呼ばれる表示用メモリに、書き込む。これによりグラフィクスは描画される。上述したメモリ割り当て方式は、ピクセルバッファに”Region”を定義し、伸長されたグラフィクスのうち、この”Region”に包含される部分をグラフィックスプレーンに書き込むというものである。例えば、「Good bye・・・」という字幕がピクセルバッファに存在しており、このうち「Go」の部分を包含するよう”Region”の位置・大きさを定義すれば、この「Go」の部分がグラフィックスプレーンに書き込まれて画面に表示される。また「Good」を包含するよう”Region”を定義すれば、この「Good」の部分が画面に表示される。
【０００３】
”Region”の定義と、グラフィックスプレーンへの書き込みとを繰り返し行えば、字幕「Good bye・・・」は、「Go」→「Good」→「Good bye」→「Good bye・・・」というように、余韻をもって徐々に画面に現れる。このような描画により、ワイプインという表示効果を実現することができる。これらの技術を記載した文献には、以下の非特許文献に掲げたものがある。
【非特許文献１】“Digital Video Broadcasting(DVB) Subtitling systems;Final draft ETSI EN 300 743”ETSI STANDARDS,EUROPEAN TELECOMMUNICATION STANDARDS INSTITUTE,SOPHIA-ANTIPO,FR
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで従来のETSI EN 300 743標準規格には、グラフィックスプレーンに対する書き込み負荷が大きい場合に、グラフィクスの表示と、ピクチャの表示との同期をどのように保証するかという考えが全くなかった。グラフィックスプレーンには、非圧縮状態のグラフィクスが書き込まれるので、グラフィクスの解像度が高ければ高い程、書き込み負荷が大きくなる。例えば、BD-ROMが予定しているグラフィクス(1920×1080という高解像度をもつグラフィクス)を描画しようとすると、グラフィックスプレーンに書き込むべきグラフィクスのサイズは最大2Mバイトになる。このような、多大なサイズをもつグラフィクスを、ピクチャの表示と同期させるには、グラフィックスプレーンへの書き込みに多大なバンド幅が必要となる。しかしグラフィックスプレーンへの書き込みに、高いバンド幅を要求することは、再生装置の低コスト化の妨げになる。仮に再生装置が常に合理的な書き込みを行うなら、グラフィックスプレーン書き込み時のバンド幅を低下させることができる。ここで合理的な書き込みとは、前回の表示内容との差分のみ、グラフィックスプレーンに書き込んでゆくという書き込みをいう。しかし、再生装置に常に合理的書き込み手法を要求するのも、ソフトウェアの実装の自由度を奪う結果になる。
【０００５】
このように、グラフィックスプレーンへの書き込み負荷が多大であると、高いバンド幅での動作や、合理的な手法での書き込みを再生装置に強いることになり、再生装置の製品開発を著しく阻害することになる。
本発明の目的は、グラフィックスプレーンに書き込むべきデータ量が多大であっても、ピクチャの表示と同期したグラフィクスのアップデートを実現することができる再生装置を提供することである。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明に係る再生装置は、ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームを再生する再生装置であって、ビデオストリームをデコードして動画像を得るビデオデコーダと、グラフィクスストリームをデコードするグラフィクスデコーダと、プレーンメモリと、を備え、前記グラフィクスデコーダは、エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、コントローラと、を備え、前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、前記グラフィクスストリームは、複数のディスプレイセットからなり、個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す、ことを特徴としている。
【発明の効果】
【０００７】
ピクチャに対応する平面(Plane)の一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
【０００８】
グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、オーサリングを行う制作者は、あらゆる再生装置での同期保証を実現することができる。
またウィンドゥ情報によりウィンドゥの位置や大きさを規定できるので、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。ピクチャ内の絵柄の邪魔にならないように、グラフィクスを表示させることができるので、ピクチャの絵柄に時間的な変動があっても、グラフィクスの見易すさを維持することができる。これにより映画作品の品質を高めることができる。
【０００９】
ここでワーストケースでのアップデートとは、全クリア＋再描画という最も効率が悪い処理でグラフィックスがアップデートされることをいう。ワーストケースを想定して、ウィンドゥの大きさを決める場合、前記ウィンドゥの縦幅、横幅は、ピクチャに対応する平面の1/xの大きさになるように定め、xは、ウィンドゥのアップデートレートと、ピクチャの表示レートとの比率に基づく実数とすることが望ましい。
【００１０】
このようにウィンドゥの大きさを定めれば、再生装置において、グラフィックスプレーンへの書き込みに必要なバンド幅は、ある決まった値になる。ミニマムスタンダードとして、このバンド幅を満たすよう、再生装置を構成すれば、ソフトウェアの実装がどのようなものであっても、ピクチャとの同期を実現することができる。
このように再生装置構成のためのミニマムスタンダードを提供することができるので、かかる転送レートというミニマムスタンダードさえ満たせば、その他の実装は、開発者が自由に定めることができるので、再生装置の開発にあたっての自由度が高まる。
【発明を実施するための最良の形態】
【００１１】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、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)、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つの字幕「本当は」「ウソだった」「あなたが」は画面の下側に、「ずっと」「すきだった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、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のみのDSv、又は、PCSのみの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では、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。画素の色にあたっては、一画素当たりのインデックス値(赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値))のビット長が8ビットになっており、これによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。グラフィクスオブジェクトによる字幕は、透明色の背景に、文字列を配置することで描画される。
【００２６】
ODSによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ODSは、図７（ａ）に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_insequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
【００２７】
『object_id』は、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する。グラフィクスストリームのEpochには、同じIDをもつODSが複数含まれる。同じIDをもつ複数のODSは縦横のサイズが同じであり、オブジェクトバッファの共通の領域が割り当てられる。同じIDをもつ複数ODSのうち1つが、この領域に読み出されれば、オブジェクトバッファにおけるODSは、同じIDをもつ後続のODSにより上書きされる。このように、ビデオストリームの再生進行に伴い、オブジェクトバッファ上のODSが、同じ識別子をもつ後続のODSにて上書きされることにより、ODSにおける絵柄は、時間的な変遷を遂げる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
【００２８】
『last_insequence_flag』、『object_data_fragment』について説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject_data_fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last_sequence_flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。
【００２９】
『Palette Difinition Segment(PDS)』は、色変換用のパレットを定義する情報である。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は、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0〜video_width-window_horizontal_position-1の値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので0〜video_height-window_vertical_position-1の値をとる。
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』と、『window情報(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に用いられるべきパレットを示す。
【００３７】
『window情報(1)・・・(n)』は、このPCSが属するDisplay Set内の、個々のウィンドゥをどのように制御するかを示す情報である。図８（ｂ）の破線wd1は、任意のwindow情報(i)の内部構成をクローズアップしている。この破線wd1に示すように、window情報(i)は、『object_id』、『window_id』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００３８】
『object_id』は、window情報(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_address』、『object_cropping_width』、『object_cropping_height』からなる。
【００４１】
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_address』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４２】
『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は、『あなたが』の横幅、縦幅を示す。こうすることにより、『あなたが』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。
【００４７】
DS1,2,3のPCSを以上のように記述することで、字幕の表示効果を実現することができる。その他の表示効果を実現するにあたっての、PCSの記述作法について説明する。
先ず初めにCut-In/Outの記述作法について説明する。図１３は、時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。
本図におけるwindow(x,y,u.v)におけるx,yは、window_vertical_position、window_horizontal_positionの値であり、u,vは、window_width、window_heightの値を示す。また本図のCropping Rectangle(a,b,c,d)におけるa,bは、object_cropping_vertical_position、object_cropping_horizontal_positionの値であり、c,dはobject_cropping_width、object_cropping_heightの値である。本図の再生時間軸の時点t11,t12,t13には、DS11,DS12,DS13が存在している。
【００４８】
時点t11に存在するDS11は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Credit:」を表すODS＃0、ENDを有する。
時点t12に存在しているDS12は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS＃1を含む。
【００４９】
時点t13に存在しているDS13は、Composition_StateがNormal Caseであり、クロップされたグラフィクスオブジェクトを消すよう、object_cropped_flagが0に設定されたPCS＃2を含む(No Cropping Rectangle Visible)。
以上のDisplay Setにより、t11では字幕「Credit:」は非表示になっているが、t12で表示され、t13で再び非表示になる。これによりCut-In/Cut-Outという表示効果が実現される。
【００５０】
続いてFade-In/Outという表示効果を実現する際の、Display Setの記述作法について説明する。図１４は、時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。本図の時点t21,t22,t23,t24には、DS21,DS22,DS23,DS24が存在している。
時点t21に存在するDS21は、Composition_StateがEpoch Startに設定され、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window(0,0))という手順を示すPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Fin」を表すODS＃0、ENDを有する。
【００５１】
時点t22に存在しているDS22は、Composition_StateがNormal CaseであるPCS＃1と、PDS＃1とを含む。このPDS＃1は、PDS＃0と同じ色彩の赤色差、青色差を示しておりながら、高い輝度値をもっているものとする。
時点t23に存在しているDS23は、Composition_StateがNormal CaseであるPCS＃3と,PDS＃2と,ENDとを含む。このPDS＃2は、PDS＃0と同じ色彩の赤色差、青色差を示しておりながら、低い輝度値をもっているものとする。
【００５２】
時点t24に存在するDS24は、Composition_StateがNormal Caseに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS、ENDを有する。
これら一連のDisplay Setは、1つ前のDisplay Setと異なるPDSを指定しているため、Epoch内の複数PCSにおいて表示されるグラフィクスオブジェクトは、徐々に輝度値が高められたり、弱められることになる。これによりFade-In/Outという表示効果の実現が可能になる。
【００５３】
続いてScrollingの記述作法について説明する。図１５は、時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。本図における表記は、図１３の一例に準ずる。
AVClip再生時間軸の時点t31に存在するDS31は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Credit: Company」を表すODS＃0、ENDを有する。
【００５４】
時点t32に存在するDS32は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃1を含む。オブジェクトバッファにおいて(0,0)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち「Credit:」が存在するので、この「Credit:」がグラフィックスプレーンに出現することになる。
【００５５】
時点t33に存在するDS33は、Composition_StateがNormal Caseであり、オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲を切り出し(Cropping Rectangle＃0(0,100,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃2を含む。オブジェクトバッファ上の座標(0,100)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち、「Credit:」の下半分と、「Company」の上半分とが存在するので、これらの部分がグラフィックスプレーンに出現することになる。
【００５６】
時点t34に存在するDS34は、Composition_StateがNormal Caseであり、オブジェクトバッファの座標(0,200)から横600×縦400の範囲を切り出し(Cropping Rectangle＃0(0,200,600,400))、ウィンドゥにおける座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃3を含む。オブジェクトバッファ上の座標(0,200)から横600×縦400の範囲には、「Credit:」「Company」という２段表記の字幕のうち、「Company」が存在するので、２段表記の字幕のうち「Company」の部分が画面上に現れることになる。以上のPCSの記述により、「Credit:」「Company」という２段表記の字幕の下スクロールがなされることになる。
【００５７】
続いてWipe-In/Outの記述作法について説明する。図１６は、時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。本図における表記は、図１３の一例に準ずる。
本図の時点t51に存在するDS51は、Composition_StateがEpoch Startに設定され、Object_Cropped_Flagが0(No Cropping Rectangle Visible)に設定されたPCS＃0、グラフィックスプレーンの(100,100)の位置に、横700×縦500のwindowを宣言するWDS＃0、PDS＃0、字幕「Fin」を表すODS＃0、ENDを有する。
【００５８】
時点t52に存在するDS52は、Composition_StateがNormal Caseであり、オブジェクトバッファの(0,0)から横600×縦400の範囲でクロップを行い(Cropping Rectangle＃0(0,0,600,400))、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標(0,0)に配置する(on window＃0(0,0))という手順を示すPCS＃1を含む。(0,0)から横600,縦400の範囲には、「Fin」という字幕が存在するので、この「Fin」がグラフィックスプレーンに出現することになる。
【００５９】
時点t53に存在するDS53は、Composition_StateがNormal Caseであり、オブジェクトバッファにおける(200,0)から縦400×横400の範囲でクロップを行い(Cropping Rectangle＃0(200,0,400,400))、座標(200,0)を基準にして、表示を行わせるPCS＃2を含む(on window＃0(200,0))。そうすると、(200,0)〜(400,400)が表示範囲内になり、(0,0)〜(199,400)は、非表示範囲になる。
【００６０】
時点t54に存在するDS54は、Composition_StateがNormal Caseであり、オブジェクトバッファにおけるグラフィクスオブジェクトの(400,0)から横200×縦400の範囲でクロップを行い(Cropping Rectangle＃0(400,0,200,400))、座標(400,0)を基準にして、ウィンドゥの表示を行わせる(on window＃0(400,0))PCS＃3を含む。そうすると、(0,0)〜(399,400)は、非表示範囲になる。
【００６１】
グラフィックスプレーンの非表示範囲が広がるに伴い、表示範囲が狭まるのでWipe-In/Outが実現されることになる。
このようにPCSの記述次第でCut-In/Out,Fade-In/Out,Wipe-In/Out,Scrollというような多様な表示効果を実現することができるので、字幕描画に様々な工夫を凝らすことができる。
【００６２】
かかる表示効果実現にあたっての制約について説明する。図１３〜図１６の表示効果のうち、Scrollingの実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。図１５のt32−t33間で考えれば、Scrollingの実現のためには、t32における「Credit:」なるグラフィクスオブジェクトをグラフィックスプレーンから消し去るというウィンドゥクリアと、「Credit:」の下半分、「Company」の上半分をグラフィックスプレーンに書き込むというウィンドゥ再描画とをt32−t33の時間間隔で実現せねばならない。この時間間隔がビデオフレームの時間間隔である場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
【００６３】
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートを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においてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
【００６８】
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
【００６９】
図１７は、ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。グラフィクスオブジェクトが4つ存在する場合、エッジの数は8つになるのでグラフィクスオブジェクトが2つ存在する場合と比べると、エッジの数は2倍になっている。
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が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[ODS])に示されるので、これにデコードを要する最長時間を加えた時刻が、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])
続いてPCSのDTS、PTSの設定について説明する。
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のデコード期間(ii)、DSn.PCSn.OBJの書き込みに要する時間(iii)により変動を受ける値になる。Rd,Rcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。
【００７７】
decode_durationの計算は、図１８のプログラムに基づき行われる。また図１９、図２０（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecode_durationの算出について説明する。図１９のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecode_durationに加算する(図１９のステップＳ１)。PLANEINITIALIZATINTIME関数(図２０（ａ）)は、Display Setを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図１９のステップＳ１では、DSn,DSnPCS.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におけるOBJ[0]を引数として、wait関数を呼び出し、その戻り値をdecode_durationに加算する(ステップＳ１０)。
【００８４】
続くステップＳ１１は、DSnのOBJ[0]が属するwindowが、グラフィクスオブジェクト[1]が属するwindowと同一かどうかの判定であり(if(DSn.PCS.OBJ[0].window_id == DSn.PCS.OBJ[1].window_id)、もし同一であるなら、OBJ[1]を引数にして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に加える(ステップＳ１５)。OBJ[1]を引数にして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)＋デコード期間(2)になる。問題は、クリア期間(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の書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。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の再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上が再生時間軸に対するDisplay Setの割り当てについての説明である。
Display Setに対するDTS、PTSの設定について、図２４〜図２５の具体例を交えながら説明する。図２４は、4回のグラフィックスプレーンへの書き込みにより字幕を表示することを想定した具体例である。この具体例は、2つの字幕『what is blu-ray』、『blu-ray is everywhere』を1つずつ表示させるというアップデートを想定している。図２４は、本具体例が想定しているアップデートの、時間的変遷がどのようなものであるかを示す図である。時点t1では『what』までを表示し、続く時点t2では『what is』まで、時点t3では『what is blu-ray』全体を表示させる。字幕の全貌を明らかにした上で時点t4において別の字幕『blu-ray is everywhere』を表示させるのである。
【００９６】
図２５（ａ）は、かかるアップデートを実現するため、記述された4つのDisplay Setを示す図である。DS1は、時点t1におけるアップデートを制御するPCS1.2と、彩色のためのPDS1と、字幕『what is blu-ray』に相当するODS1と、DS1の終了コードであるENDとからなる。
DS2は、時点t2におけるアップデートを制御するPCS1.2と、ENDとからなる。DS3は、時点t3におけるアップデートを制御するPCS1.3と、ENDとからなる。DS4は、時点t2のアップデートを制御するためのPCS2と、色変換のためのPDS2と、字幕『blu-ray is everywhere』に相当するODS2と、ENDとからなる。
【００９７】
これら4つのDisplay Setに属する各機能セグメントのDTS、PTSをどのように設定するかを、図２５（ｂ）のタイミングチャートを参照して説明する。
このタイミングチャートの再生時間軸は、図２４の再生時間軸と同じものである。このタイミングチャートにおいて、PTS(PCS1.1)、PTS(PCS1.2)、PTS(PCS1.3)、PTS(PCS2)は、それぞれ『what』の表示時点t1,『what is』の表示時点t2,『what is blu-ray』の表示時点t3,『blu-ray is everywhere』の表示時点t4を示すよう設定される。これは、それぞれの字幕の表示時点において各PCSに記述された制御(Cropなど)を実行する必要があるからである。
【００９８】
PTS(ODS1),PTS(ODS2)は、PTS(PCS1.1)及びPTS(PCS2)の時点からDecode_Durationを差し引いた時点を示すよう設定されている。PTS(PCS)は、数式PTS(DSn[PCS])≧DTS(DSn[PCS])+decodeduration(DSn)を満たすよう設定する必要があるからである。
図２５（ｂ）では、時点t4より手前の時点t5を示すよう、PTS(ODS2)は設定されており、時点t1より手前の時点t0を示すよう、PTS(ODS1)は設定されている。DTS(ODS1),DTS(ODS2)は、PTS(ODS1)及びPTS(ODS2)の時点からデコード期間を差し引いた時点を示すよう設定されている。DTS(ODS)は、数式PTS(DS[ODSj])=DTS(DSn[ODSj])+90,000×(SIZE(DSn[ODSj])//Rd)を満たすよう設定する必要があるからである。図２５（ｂ）では、時点t5より手前の時点t0を示すよう、PTS(ODS2)は設定されており、時点t0より手前の時点を示すよう、PTS(ODS1)は設定されている。
【００９９】
ここでDTS(ODS2)=PTS(ODS1)の関係が満たされことがわかる。これにより再生装置の実装によっては、ODS1がオブジェクトバッファに読み出された後、このオブジェクトバッファ上のODS1を上書きする形で、ODS2を読み出すことができる。あるODSのPTSを、先に表示すべきODSのPTSに設定しておけば、古いODSを上書きする形で、新しいODSをメモリに読み出すという動作を再生装置が行うことにより、小メモリ規模での再生処理を実現することができる。かかる再生処理の実現により、再生装置におけるメモリ規模の選択の幅は広がる。
【０１００】
PCS1.1のDTSは、DTS(PCS1.1)＝DTS(ODS1)になるように設定されている。これは、PCS1.1のDTS値は、DTS(ODS1)により示される時点以前であるなら、どの時点でもよいからである。
ODS1のPTS値、ODS2のDTS値、PCS1.2、PCS1.3、PCS2のPTS値は、PTS(ODS1)＝DTS(ODS2)＝PTS(PCS1.2)＝PTS(PCS1.3)＝DTS(PCS2)の関係を満たすよう、何れも時点t0に設定されている。
【０１０１】
これは、PCS1.2、PCS1.3のDTS値は、PTS(PCS1.2)、PTS(PCS1.3)以前であれば、どの時点でもよく、またPCS2のDTS値も、DTS(PCS2)以前であれば、どの時点でもよいという自由度があるからである。これにより、複数のPCSをまとめて読み出しておき、前のPCSによるアップデートの実行が終われば続くPCSによるアップデートを即座に実行することができる。
【０１０２】
PCSのDTS・PTS、ODSのDTS・PCSは、上述の数式で示したような不等号の関係さえ最低限満たせばよいので、DTS(ODS2)=PTS(ODS1)になるように設定したり、PTS(ODS1)＝DTS(ODS2)＝PTS(PCS1.2)＝PTS(PCS1.3)＝DTS(PCS2)になるように設定することも可能になる。こうしたタイムスタンプの設定により、デコード負荷が発生する期間やバッファの占有量が増える期間を、調整することができる。かかる調整が可能になるので、再生時になしえる再生制御の幅が広がり、オーサリングを行う技術者及び再生装置を製造する技術者にとってのメリットは大きい。これで、DTS,PTS設定の具体例の説明を終える。
【０１０３】
以上説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-ray Disc Prerecording 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,b,cからTSパケットが取り出される速度を速度Rxとする
周辺回路４dは、Transport Buffer４a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCoded Data Buffer１３に格納される。
【０１０６】
ビデオデコーダ５は、PIDフィルタ３から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、PIDフィルタ３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
【０１０７】
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
CLUT部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
加算器１０は、CLUT部９により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
【０１０８】
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。このグラフィクスデコーダ１２は、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 Processor１４によるデコードは、ODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。上述したグラフィックオブジェクトのデコードレートRdは、このStream Graphics Processor１４の出力レートである。
【０１１２】
Object Buffer１５は、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor１４のデコードにより得られたグラフィクスオブジェクトが配置される。Object Buffer１５は、グラフィクスプレーン８の2倍／4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン８の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【０１１３】
Composition Buffer１６は、PCS、PDSが配置されるメモリである。
Graphical Controller１７は、Composition Buffer１６に配置されたPCSを解読して、PCSに基づく制御をする。この制御の実行タイミングは、PCSに付加されたPTSの値に基づく。以上が再生装置の構成要素である。
続いて、PIDフィルタ３、Transport Buffer４a,b,c、グラフィクスプレーン８、CLUT部９、Coded Data Buffer１３〜Graphical Controller１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２７は、書込レートRx,Rc,Rd、グラフィクスプレーン８、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のデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
【０１２１】
以上が再生装置の内部構成である。続いて制御部２０及びグラフィクスデコーダ１２を、どのようにして実装するかについて説明する。制御部２０は、図３０の処理手順を行うプログラムを作成し、汎用ＣＰＵに実行させることにより実装可能である。以降、図３０を参照しながら、制御部２０の処理手順について説明する。
図３０は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(PCS,WDS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップＳ２１〜Ｓ２４、ステップＳ２７〜Ｓ３１の処理を全てのSegmentKについて繰り返すループ構造を有している(ステップＳ２５、ステップＳ２６)。
【０１２２】
ステップＳ２１は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップＳ２７、ステップＳ２８の判定を行う。
ステップＳ２２は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップＳ２３に移行し、1であるならステップＳ２４に移行する。無視フラグが1であれば(ステップＳ２２でYes)、ステップＳ２３においてSegmentKをCoded Data Buffer１３にロードする。
【０１２３】
無視フラグが0に設定されていれば(ステップＳ２２がNo)、ステップＳ２４においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップＳ２２がNoになって、無視されることになる(ステップＳ２４)。
このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
【０１２４】
ステップＳ２７は、PCSにおけるsegment_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におけるsegment_typeがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、ステップＳ３４に移行する。SegmentKがEpoch Startであるなら、ステップＳ３０において無視フラグを0に設定する。 ステップＳ３４は、ステップＳ２８と同じであり、先行するDSがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する(ステップＳ３０)。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する(ステップＳ３５)。かかるフラグ設定により、先行するDSがグラフィクスデコーダ１２に存在しない場合、Normal Caseを構成する機能セグメントは無視されることになる。
【０１２６】
DSが、図３１のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図３１の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、segment_typeがEpoch_Start、DS10はAcquisition Point、DS20は、Normal Caseである。
かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図３０のフローチャートの対象となる。ステップＳ２７においてsegment_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のsegment_typeがEpoch StartであるDS1は、そのままCoded Data Buffer１３にロードされるが(ステップＳ２３)、PCSのsegment_typeがAcquisition PointであるDS10については、無視フラグが1に設定されるため(ステップＳ２９)、これを構成する機能セグメントはCoded Data Buffer１３にロードされず無視される(図３４の矢印rd2,ステップＳ２４)。またDS20については、PCSのsegment_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_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５０)。
【０１３１】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ５１)。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３２】
ステップＳ５２は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン８に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして(ステップＳ５３)、ステップＳ４９に移行する。これにより、別のODSに対しても、ステップＳ４９〜Ｓ５１の処理が繰り返し行われる。
次に図３６を参照して、ステップＳ４２、ステップＳ５４〜ステップＳ５９について説明する。
【０１３３】
ステップＳ４２は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップＳ５４においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップＳ５５〜ステップＳ５９のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップＳ５７〜ステップＳ５９を実行するというものである。ステップＳ５７は、object_crop_flagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ５８)。
【０１３４】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ５９)。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。
【０１３５】
ステップＳ４４は、現在の再生時点がPDSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップＳ６０においてPallet_update_flagが1を示しているか否かを判定する。もし1を示しているなら、pallet_idに示されるPDSをCLUT部に設定する(ステップＳ６１)。0を示しているなら、ステップＳ６１をスキップする。
その後、グラフィクスプレーン８におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する(ステップＳ６２)。
【０１３６】
次に図３７を参照して、ステップＳ４３、ステップＳ６４〜ステップＳ６６について説明する。
ステップＳ４３は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップＳ６３においてウィンドゥが2つであるか否かを判定し、もし1つであれば、メインルーチンにリターンする。ウィンドゥが2つであるなら、ステップＳ６４〜ステップＳ６６を行う。ステップＳ６４は、object_crop_flagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする(ステップＳ６５)。
【０１３７】
もし0を示していないなら、object_cropping_horizontal_position、object_cropping_vertival_position、cropping_width、cropping_heightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のwindowにおいてobject_cropping_horizontal_position,object_cropping_vertival_positionに示される位置に書き込む(ステップＳ６６)。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
【０１３８】
以上、DSnに属するPCSのDTS,PTS,ODSのDTS、PTSの設定について説明したが、PDSのDTS、PTS、ENDのDTS、PTSについては説明していない。先ず、DSnに属する各PDSのDTS,PTSの設定について説明する。
DSnに属する各PDSは、PCSがComposition Buffer１６にロードされる時点(DTS(DSn[PCS]))から、最初のODSのデコード開始時点(DTS(DSn[ODS1]))までに、CLUT部９において、有効になればよい。このことからDSnに属する各PDS(PDS1〜PDSlast)のPTS値は、以下の関係を満たす値に、設定されねばならない。
【０１３９】
DTS(DSn[PCS])≦PTS(DSn[PDS1])
PTS(DSn[PDSj])≦PTS(DSn[PDSj+1])≦PTS(DSn[PDSlast])
PTS(DSn[PDSlast])≦DTS(DSn[ODS1])
尚、PDSにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
【０１４０】
以上の関係を満たすようDTS、PDSが設定された場合、再生装置のパイプラインにおいてこれらDTS、PTSがどのような役割をもつかについて説明する。図３８はPDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。この図３８は、図２８をベースにして作図されている。図３８において第１段目は、CLUT部９へのPDS設定を示している。以降の段は、図２８の第１〜第５段目と同じである。PDS1〜lastのCLUT部９への設定は、PCS,WDSの転送後、ODS1のデコードより前になされるので、矢印up2,up3に示すようにODS1のDTSに示される時点より前に設定されている。
【０１４１】
以上のようにPDSの設定は、ODSのデコードの先立ちなされることがわかる。
続いてDSnに属するEND of Display SetSegmentのPTSの設定について説明する。DSnに属するENDは、DSnの終わりを示すものだから、ODS2のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2(ODSlast)のPTS(PTS(DSn[ODSlast]))に示されているので、ENDのPTSは、以下の式に示される値に設定されねばならない。
【０１４２】
PTS(DSn[END]) = PTS(DSn[ODSlast])
DSn,DSn+1に属するPCSとの関係で考えれば、DSnにおけるPCSは、最初のODS(ODS1)のロード時刻以前に、Composition Buffer１６にロードされるから、ENDのPTSは、DSnに属するPCSのロード時刻(DTS(DSn[PCS]))以降、DSn+1に属するPCSのロード時刻(DTS(DSn+1[PCS]))以前でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
【０１４３】
DTS(DSn[PCS])≦PTS(DSn[END])≦DTS(DSn+1[PCS])
一方、最初のODS(ODS1)のロード時刻は、最後のPDS(PDSlast)のロード時刻以前であるから、ENDのPTS(PTS(DSn[END]))は、DSnに属するPDSのロード時刻以降(PTS(DSn[PDSlast]))でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。
【０１４４】
PTS(DSn[PDSlast])≦PTS(DSn[END])
続いて再生装置のパイプラインにおいて、ENDのPTSが、どのような意味合いをなすのかについて説明する。図３９は、再生装置のパイプライン動作時における、ENDの意味合いを示す図である。本図は、図２８の第２段目以降をベースに作図しており、第２段以降の意味合いは図２８と同一である。また本図では、DSn,DSn+1という2つのDisplay Setを描いている。DSnにおいてODSlastになるのは、A-ODSsの最後のODSnであるので、ENDのPTSは、このODSnのPTSを示すよう設定されている。そして、このENDのPTSに示される時点は、DSn+1のPCSのDTSにより示される時点より早いものになっている。
【０１４５】
このENDのPTSにより、再生時にあたっては、DSnについてのODSのロードが、どの時点で完了するのかを知得することができる。
尚、ENDにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。
以上のように本実施形態によれば、グラフィックプレーンの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。グラフィックプレーンの25%〜33%など、ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。グラフィックプレーンのうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
【０１４６】
グラフィックプレーンの1/4等、グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、再生装置は、256Mbps等、ある決まった転送レートでグラフィックプレーンの書き込みを行いさえすれば、ピクチャとの同期を実現することができる。
同期保証が容易になるので、高い解像度での字幕表示を多くの再生装置において実現することができる。
【０１４７】
(第２実施形態)
第１実施形態では、ビデオフレーム毎にグラフィクスをアップデートできるように、ウィンドゥの大きさをグラフィックスプレーン全体の1/4とし、グラフィックスプレーンへの書込レートRcを256Mbpsとした。またアップデートレートを、ビデオフレームレートの1/2,1/4とすることにより、大きなサイズのグラフィクスのアップデートの実現も可能とした。しかしアップデートレートをビデオフレームレートの1/2,1/4とした場合、グラフィックスプレーンへの書き込みは、2,4ビデオフレームを要する。そしてグラフィックスプレーンが1つであれば、この書き込みに費やされる2,4フレームの間、グラフィクスが書き込まれる過程がユーザに見えてしまう。そうすると、あるグラフィクスから大きなグラフィクスへと瞬時に切り換わるような表示効果は実現できない。そこで第２実施形態ではグラフィックスプレーンを2つ設ける。図４０は、第２実施形態に係る再生装置の内部構成を示す図である。本図が図２６、図２７と比較して新規なのは、グラフィックスプレーンが2つ有り(図中のグラフィクスプレーン８１、グラフィクスプレーン８２)、この2つのグラフィックスプレーンがダブルバッファを構成している点である。そのため、2つのグラフィックスプレーンのうち一方からの読み出しが行われている間、他方のグラフィックスプレーンへの書き込みは可能になる。そして第２実施形態に係るGraphical Controller１７は、この読出対象の切り換えをPCSに付与されているPTSの時点に実行する。
【０１４８】
図４１は、ダブルバッファによるグラフィックスプレーン読み出し／書き込みを模式的に示す図である。本図の縦軸方向は、グラフィクスプレーン８１、グラフィクスプレーン８２の格納内容を、横軸方向は、1フレーム目、2フレーム目、3,4,5フレーム目のグラフィックスプレーンの格納内容を示している。そしてグラフィクスプレーン８１、グラフィクスプレーン８２の格納内容のうち、太い枠で囲まれているものが、読み出しの対象になっている。本図では、グラフィクスプレーン８１に顔マークが格納されており、これを太陽マークに置き換えることを意図している。太陽マークはObject Buffer１５に存在しており、4MByteのサイズをもつ。この4MByteのサイズは、Object Buffer１５の目一杯のサイズである。
【０１４９】
太陽マークを、グラフィクスプレーンへの書込レート(Rc=256Mbps)で書き込むなら、グラフィクスプレーン８２への書き込み完遂に4フレームがかかる。そしてこの書き込みに費やされる4フレームという期間において、1フレーム目では太陽マークのグラフィクスは1/4だけ、2フレーム目では2/4、3フレーム目では3/4だけ書き込みがなされる。しかし1フレームから4フレーム目までは、グラフィクスプレーン８１、グラフィクスプレーン８２のうち、読出対象がグラフィクスプレーン８１なので、これら太陽マークがグラフィックスプレーンに書き込まれている過程は、ユーザには見えない。5フレーム目においてグラフィックスプレーンの読出対象がグラフィクスプレーン８２に移った段階で、グラフィクスプレーン８２の格納内容はユーザに見える。これにより顔マークから太陽マークへの切り換わり時になされる。
【０１５０】
以上のように本実施形態によれば、4フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯に映画制作者、制作スタッフ、出演者の氏名のクレジットを表示する場合や、映画のあらすじ、警告文を、瞬時に表示する場合に有意義である。
(第３実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図４２は、第３施形態に係るBD-ROMの製造工程を示すフローチャートである。
【０１５１】
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２０９を含む。
【０１５２】
ステップＳ２０４において、字幕の表示範囲となる windowを定義するようWDSを記述し、ステップＳ２０５では、windowが同じになる再生区間を Epochとし、個々のEpochにおけるPCSを記述する。
こうしてPCSが得られれば、ステップＳ２０６において字幕素材たるグラフィクスをODSに変換し, これをPCS、WDS、PDSを組み合わせることでDisplay Setを得る。その後、ステップＳ２０７では、Display Setにおける各機能セグメントを PESパケット化し、タイムスタンプを付与することによりグラフィクスストリームを得る。
【０１５３】
最後に、ステップＳ２０８では、グラフィクスストリームを別途生成されたビデオストリーム、 オーディオストリームと多重することでAVClipを生成する。
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データであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１６３】
(H)PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
(I)PCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBD-ROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
【０１６４】
(J)第１実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25%に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
【０１６５】
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。
(K)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
【０１６６】
(L)グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、商標を構成するような図形,文字,色彩の組合せや、国の紋章,旗章,記章,国家が採用する監督/証明用の公の記号・印章、政府間国際機関の紋章,旗章,記章,特定商品の原産地表示を含んでいてもよい。
(M)第１実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
【０１６７】
(N)各実施形態におけるAVClipは、映画作品を構成するものであったが、AVClipはカラオケを実現するものであってもよい、そしてこの場合、PCSは歌の進行に応じて、字幕の色を変えるという表示効果を実現してもよい。
【産業上の利用可能性】
【０１６８】
本発明に係る記録媒体、再生装置は、表示効果を伴う字幕表示を実現することができるので、より付加価値が高い映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図面の簡単な説明】
【０１６９】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの構成を示す図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】字幕の表示位置と、Epochとの関係を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトの定義を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造で構成される。
【図９】字幕表示を実現するためのDisplay Setの記述例である。
【図１０】DS1におけるWDS、PCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DS3におけるPCSの記述例を示す図である。
【図１３】時間軸に沿った連続写真的な表記で、Cut-In/Outを実行する際のDisplay Setの記述例を示す図である。
【図１４】時間軸に沿った連続写真的な表記で、Fade-In/Outを実行する際のDisplay Setの記述例を示す図である。
【図１５】時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。
【図１６】時間軸に沿った連続写真的な表記で、Wipe-In/Outがどのように行われるかを記述した図である。
【図１７】ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。
【図１８】decode_durationの計算アルゴリズムの一例を示す図である。
【図１９】図１８のプログラムのアルゴリズムを図式化したフローチャートである。
【図２０】（ａ）（ｂ）図１８のプログラムのアルゴリズムを図式化したフローチャートである。
【図２１】（ａ）1つのwindowに1つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１８で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図２２】（ａ）1つのwindowに2つのODSが存在するケースを想定した図である。 （ｂ）（ｃ）図１８で引用した各数値の時間的な前後関係を示すタイミングチャートである。
【図２３】（ａ）2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定したタイミングチャートである。 （ｂ）デコード期間(2)がクリア期間(1)＋書込期間(31)より長くなるケースを示すタイミングチャートである。 （ｃ）クリア期間(1)＋書込期間(31)がデコード期間(2)より長くなるケースを示すタイミングチャートである。
【図２４】アップデートの、時間的変遷の具体例を示す図である。
【図２５】（ａ）図２４に示したアップデートを実現するため、記述された4つのDisplay Setを示す図である。 （ｂ）図２５（ａ）におけるDisplay Setに属する各機能セグメントのDTS、PTSがどのように設定されているかを示すタイミングチャートである。
【図２６】本発明に係る再生装置の内部構成を示す図である。
【図２７】書込レートRx,Rc,Rd、グラフィクスプレーン８、Coded Data Buffer１３、Object Buffer１５、Composition Buffer１６のサイズを示す図である。
【図２８】再生装置によるパイプライン処理を示すタイミングチャートである。
【図２９】ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。
【図３０】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図３１】多重化の一例を示す図である。
【図３２】DS10が再生装置のCoded Data Buffer１３にロードされる様子を示す図である。
【図３３】通常再生が行われる場合を示す図である。
【図３４】図３３のように通常再生が行われた場合のDS1,10,20のロードを示す図である。
【図３５】Graphical Controller１７の処理手順を示すフローチャートである。
【図３６】Graphical Controller１７の処理手順を示すフローチャートである。
【図３７】Graphical Controller１７の処理手順を示すフローチャートである。
【図３８】PDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。
【図３９】再生装置のパイプライン動作時における、ENDの意味合いを示す図である。
【図４０】第２実施形態に係る再生装置の内部構成を示す図である。
【図４１】ダブルバッファによるグラフィックスプレーン読み出し／書き込みを模式的に示す図である。
【図４２】第３施形態に係るBD-ROMの製造工程を示すフローチャートである。
【符号の説明】
【０１７０】
１ BDドライブ
２ Read Buffer
３ PIDフィルタ
４ TBバッファ
５ ビデオデコーダ
６ ビデオプレーン
７ オーディオデコーダ
８ グラフィクスプレーン
９ CLUT部
１０ 加算器
１２ グラフィクスデコーダ
１３ Coded Data Buffer
１４ Stream Graphics プロセッサ
１６ Composition バッファ
１７ Graphicsコントローラ
１８ UOコントローラ
１９ プレーヤレジスタ群
２０ 制御部
２００ 再生装置
３００ テレビ
４００ リモコン
【特許請求の範囲】
【請求項１】
ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームを再生する再生装置であって、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードするグラフィクスデコーダと、
プレーンメモリと、を備え、
前記グラフィクスデコーダは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、
コントローラと、を備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする再生装置。
【請求項２】
アクィジッションポイントのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記アクィジッションポイントのディスプレイセットは、表示リフレッシュという効果をもたらすために、前記エポックスタートのディスプレイセットと同じディスプレイセットを持っている、ことを特徴とする請求項１記載の再生装置。
【請求項３】
ボリュームデータを生成して、ボリュームデータが記録された記録媒体を得る記録方法であって、
前記ボリュームデータは、ビデオストリームとグラフィクスストリームとを多重化したデジタルストリームを含み、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された 制御データを含むディスプレイセットであり、
前記クロップ情報は、前記グラフィクスオブジェクト用バッファに蓄積されているグラフィクスオブジェクト全体のうち、どの部分を表示効果のために切り出して、前記プレーンメモリに転送するかという切り出し枠の指定を示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに配置して、表示するかを示す
ことを特徴とする記録方法。
【請求項４】
再生装置に組込まれ、ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームの再生を再生装置に行わせる集積回路であって、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードするグラフィクスデコーダと、を備え、
前記グラフィクスデコーダは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、
コントローラと、を備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記再生装置内のプレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする集積回路。
【請求項５】
ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームの再生を、コンピュータ上で実行する再生方法であって、
ビデオストリームをデコードして動画像を得るデコードと、
グラフィクスストリームをデコードするデコードと、を有し、
前記コンピュータは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファを備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする再生方法。
【請求項１】
ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームを再生する再生装置であって、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードするグラフィクスデコーダと、
プレーンメモリと、を備え、
前記グラフィクスデコーダは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、
コントローラと、を備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分をウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする再生装置。
【請求項２】
アクィジッションポイントのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記アクィジッションポイントのディスプレイセットは、表示リフレッシュという効果をもたらすために、前記エポックスタートのディスプレイセットと同じディスプレイセットを持っている、ことを特徴とする請求項１記載の再生装置。
【請求項３】
ボリュームデータを生成して、ボリュームデータが記録された記録媒体を得る記録方法であって、
前記ボリュームデータは、ビデオストリームとグラフィクスストリームとを多重化したデジタルストリームを含み、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された 制御データを含むディスプレイセットであり、
前記クロップ情報は、前記グラフィクスオブジェクト用バッファに蓄積されているグラフィクスオブジェクト全体のうち、どの部分を表示効果のために切り出して、前記プレーンメモリに転送するかという切り出し枠の指定を示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに配置して、表示するかを示す
ことを特徴とする記録方法。
【請求項４】
再生装置に組込まれ、ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームの再生を再生装置に行わせる集積回路であって、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードするグラフィクスデコーダと、を備え、
前記グラフィクスデコーダは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファと、
コントローラと、を備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記再生装置内のプレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする集積回路。
【請求項５】
ビデオストリームとグラフィクスストリームとが多重化されたデジタルストリームの再生を、コンピュータ上で実行する再生方法であって、
ビデオストリームをデコードして動画像を得るデコードと、
グラフィクスストリームをデコードするデコードと、を有し、
前記コンピュータは、
エポックスタートのディスプレイセット内のグラフィクスデータを復号することにより得られたグラフィクスオブジェクトを格納しておくオブジェクトバッファを備え、
前記ビデオストリームは、動画像を表すデータであり、動画像を構成する複数ピクチャからなり、
前記グラフィクスストリームは、複数のディスプレイセットからなり、
個々のディスプレイセットは、１画面分のグラフィクスを構成するデータの集合であり、
前記複数のディスプレイセットのうち先頭のタイプは、エポックスタートのディスプレイセットであり、
前記エポックスタートのディスプレイセットは、グラフィクスデータと、前記グラフィクスデータの描画領域を定義するウィンドゥ定義データと、を含み、
前記グラフィクスデータは、前記ピクチャに合成されるグラフィクスを表し、
前記ウィンドゥ定義データは、前記ピクチャとの合成のためのプレーンメモリにおけるウィンドゥの位置、縦幅、横幅を示し、
前記ノーマルケースのディスプレイセットは、前記エポックスタートのディスプレイセットより後ろに存在し、
前記ノーマルケースのディスプレイセットは、クロップ情報及び位置情報が記載された制御データを含むディスプレイセットであり、
前記クロップ情報は、前記オブジェクトバッファに存在するグラフィクスオブジェクト全体のうち、どの部分を切り出して、前記プレーンメモリに転送するかを示し、
前記位置情報は、前記クロップ情報により前記グラフィクスオブジェクトから切り出されたグラフィクスの一部分を前記ウィンドゥ内のどこに表示させるかを示す、
ことを特徴とする再生方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【公開番号】特開２００８−２９５０６５（Ｐ２００８−２９５０６５Ａ）
【公開日】平成２０年１２月４日（２００８．１２．４）
【国際特許分類】
【出願番号】特願２００８−１６６８３４（Ｐ２００８−１６６８３４）
【出願日】平成２０年６月２６日（２００８．６．２６）
【分割の表示】特願２００６−７９９７３（Ｐ２００６−７９９７３）の分割
【原出願日】平成１６年４月２７日（２００４．４．２７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２０年１２月４日（２００８．１２．４）
【国際特許分類】
【出願日】平成２０年６月２６日（２００８．６．２６）
【分割の表示】特願２００６−７９９７３（Ｐ２００６−７９９７３）の分割
【原出願日】平成１６年４月２７日（２００４．４．２７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]