(57)【特許請求の範囲】
【請求項１】
ビデオストリームと、グラフィクスストリームとが多重化されたデジタルストリームを記録する記録方法であって、
前記ビデオストリームは、動画像を構成するものであり、
前記グラフィクスストリームは、動画像上に合成されるべきグラフィクスを表示するグラフィックスオブジェクトを構成するものであり、
前記記録方法は、
前記ビデオストリームを生成するビデオストリーム生成ステップと、
前記グラフィクスストリームを生成するグラフィクスストリーム生成ステップと、
前記ビデオストリームと前記グラフィクスストリームとを多重化して前記デジタルストリームを生成するデジタルストリーム生成ステップと、
前記デジタルストリームを記録媒体に記録する記録ステップと、を含み、
前記グラフィクスストリーム生成ステップは、
２つのデジタルストリームの再生を連続して行う場合、後のデジタルストリームに対して、再生装置のメモリに格納されている前のデジタルストリームに含まれるグラフィックスオブジェクトを再生装置のメモリに維持させる旨を示す状態情報を生成する状態情報生成ステップを含み、
前記グラフィクスストリーム生成ステップでは、前記状態情報を含む前記グラフィクスストリームが生成されることを特徴とする記録方法。
【請求項２】
前記記録ステップは、更に、前記複数デジタルストリームの再生経路を示す再生経路情報を記録する再生経路情報記録ステップを含み、
前記再生経路情報は、
２つのデジタルストリームの再生を連続して行う場合、動画再生がシームレスに行われるか否かを示すシームレスフラグを含み、
前記状態情報は、前記シームレスフラグが動画再生がシームレスに行われる旨を示す場合にのみ有効である、請求項１記載の記録方法。
【請求項３】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームを再生する再生装置であって、
前記ビデオストリームをデコードして動画像を得るビデオデコーダと、
前記グラフィクスストリームをデコードすることにより、前記動画像に合成されるべきグラフィクスを表示するグラフィックスオブジェクトを得るグラフィクスデコーダとを備え、
前記グラフィクスストリームは、状態情報を有し、
前記グラフィクスデコーダは、
複数のメモリと、コントローラとを備え、
前記グラフィクスデコーダは、デジタルストリームの再生を開始する際、前記メモリに対するメモリ管理を開始し、デジタルストリームに含まれるグラフィクスストリームがデコードされれば、デコードにより得られたグラフィックスオブジェクトは、前記メモリに格納され、
前記コントローラは前記メモリに格納されたグラフィックスオブジェクトを前記メモリから読み出して表示に供する制御を行い、
２つのデジタルストリームの再生を連続して行う場合の後のデジタルストリームのデコードにおいて、
前記メモリには、前のデジタルストリームに含まれるグラフィックスオブジェクトが存在しており、
前記コントローラは、後のデジタルストリームに含まれるグラフィクスストリームの状態情報が、所定のタイプを示している場合、前記メモリのグラフィックスオブジェクトを前記メモリに維持する制御を行う、ことを特徴とする再生装置。
【請求項４】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生方法をコンピュータに行わせるプログラムであって、
前記再生方法は、
前記ビデオストリームをデコードして動画像を得るステップ、
前記グラフィクスストリームをデコードすることにより、前記動画像に合成されるべきグラフィクスを表示するグラフィックスオブジェクトを得るステップを備え、
前記グラフィクスストリームは、状態情報を有し、
前記コンピュータは、複数のメモリを備え、
前記グラフィクス表示を得るステップは、デジタルストリームの再生を開始する際、前記メモリに対するメモリ管理を開始し、デジタルストリームに含まれるグラフィクスストリームがデコードされれば、デコードにより得られたグラフィックスオブジェクトは、前記メモリに格納され、
前記グラフィクスオブジェクトを得るステップは、前記メモリに格納されたグラフィックスオブジェクトを前記メモリから読み出して表示に供する制御を行い、
２つのデジタルストリームの再生を連続して行う場合の後のデジタルストリームのデコードにおいて、
前記メモリには、前のデジタルストリームに含まれるグラフィックスオブジェクトが存在しており、
前記グラフィクスオブジェクトを得るステップは、
後のデジタルストリームに含まれるグラフィクスストリームの状態情報が、所定のタイプを示している場合、前記メモリのグラフィックスオブジェクトを前記メモリに維持する、ことを特徴とするプログラム。
【請求項５】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生を行う再生方法であって、
前記ビデオストリームをデコードして動画像を得るステップ、
前記グラフィクスストリームをデコードすることにより、前記動画像に合成されるべきグラフィクスを表示するグラフィックスオブジェクトを得るステップを備え、
前記グラフィクスストリームは、状態情報を有し、
前記コンピュータは、複数のメモリを備え、
前記グラフィクス表示を得るステップは、デジタルストリームの再生を開始する際、前記メモリに対するメモリ管理を開始し、デジタルストリームに含まれるグラフィクスストリームがデコードされれば、デコードにより得られたグラフィックスオブジェクトは、前記メモリに格納され、
前記グラフィクスオブジェクトを得るステップは、前記メモリに格納されたグラフィックスオブジェクトを前記メモリから読み出して表示に供する制御を行い、
２つのデジタルストリームの再生を連続して行う場合の後のデジタルストリームのデコードにおいて、
前記メモリには、前のデジタルストリームに含まれるグラフィックスオブジェクトが存在しており、
前記グラフィクスオブジェクトを得るステップは、
後のデジタルストリームに含まれるグラフィクスストリームの状態情報が、所定のタイプを示している場合、前記メモリのグラフィックスオブジェクトを前記メモリに維持する、ことを特徴とする再生方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シームレス再生の技術分野に属する発明であり、BD-ROM(Blu-ray Disc Read Only Memory)やDVD-Video等の記録媒体、民生用の再生装置に、かかるGUI技術を応用する場合の改良に関する。
【背景技術】
【０００２】
シームレス再生とは、複数のデジタルストリームを順次再生してゆく場合、これらのデジタルストリームの切り換わり時の途切れをなくす技術である。ユーザ操作や装置の状態(例えば装置に対するレーティングレベルの設定)に応じてストーリ展開が変わるマルチストーリ型の映画作品は、このシームレス再生の技術を基盤にして実現される。シームレス再生技術の応用により映画作品の付加価値を高め、流通市場におけるメガヒットを生みだしたいとの思惑は、多くの映画関係者が抱いているところである。
【０００３】
上述したデジタルストリームは、動画像を構成するビデオストリーム、音声を構成するオーディオストリーム、字幕やメニューを構成するグラフィクスストリームといった複数種類のエレメンタリストリームを多重化したものである。複数のデジタルストリームに多重されているビデオストリームをシームレスに再生させる技術は、例えば以下の特許文献１、２に記載されている。
【特許文献１】国際公開公報WO97/13367
【特許文献２】国際公開公報WO97/13363
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで映画作品が複数のデジタルストリームから構成されている場合、それぞれのデジタルストリームは、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとがある。従来のDVD再生装置に内蔵されているビデオデコーダ(ビデオストリームデコードのためのデコーダ)は、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとを明確に区別して、メモリ管理を継続することにより、シームレス再生を実現することができる。しかし、従来のDVD再生装置に内蔵されているグラフィクスデコーダ(グラフィクスストリームデコードのためのデコーダ)は、あるデジタルストリームから別のデジタルストリームへの切り換え時において、内蔵されているメモリを一律リセットするとの措置をとっている。これは、たとえビデオストリームがシームレスに再生されるとしても、グラフィクスストリームは先行するデジタルストリーム内のグラフィクスストリームと独立していない場合があり、グラフィクスストリームが独立しているのか、独立していないのかを再生装置内のグラフィクスデコーダが区別するのが難しいという事情による。このリセットにあたって、字幕・メニュー等のグラフィクスは、消去されるので、再生切り換えの前後では字幕・メニューの途切れが生じる。
【０００５】
デジタルストリームの境目では字幕・メニューの途切れが生じるため、オーサリング担当者は台詞がないシーン等、字幕等が出現し得ないシーンを選び、そこをデジタルストリームの分割境界に選ぶという手間を払っている。台詞がない位置をデジタルストリームの分割境界として選ぶ必要があるので、従来技術では、1つの映画作品を複数のデジタルストリームに分割するにあたっての、分割の自由度が足りないという問題点がある。
【０００６】
その結果、マルチストーリ型の映画作品を制作したとしても、思うようなストーリ展開で、再生を進行させてゆくことができないことがある。
本発明の目的は、デジタルストリームを分割するにあたっての自由度を高めることにより、再生経路をもった映画作品の制作を容易にすることができる記録方法を提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明にかかる記録方法は、ビデオストリームと、グラフィクスストリームとが多重化されたデジタルストリームを記録する記録方法であって、前記ビデオストリームは、動画像を構成するものであり、前記グラフィクスストリームは、動画像上に合成されるべきグラフィクスを表示するグラフィックスオブジェクトを構成するものであり、
前記記録方法は、
前記ビデオストリームを生成するビデオストリーム生成ステップと、
前記グラフィクスストリームを生成するグラフィクス生成ステップと、
前記ビデオストリームと前記グラフィクスストリームとを多重化して前記デジタルストリームを生成するデジタルストリーム生成ステップと、
前記デジタルストリームを記録媒体に記録する記録ステップと、を含み、
前記グラフィクスストリーム生成ステップは、
２つのデジタルストリームの再生を連続して行う場合、後のデジタルストリームに対して、再生装置のメモリに格納されている前のデジタルストリームに含まれるグラフィックスオブジェクトを再生装置のメモリに維持させる旨を示す状態情報を生成する状態情報生成ステップを含み、
前記グラフィクスストリーム生成ステップでは、前記状態情報を含む前記グラフィクスストリームが生成されることを特徴としている。
【発明の効果】
【０００８】
上記構成によれば、状態情報は、先に再生されるべきデジタルストリームと、後に再生されるべきデジタルストリームとの間で、メモリ管理を継続させる旨を再生装置に指示するので、たとえデジタルストリーム間の再生切り換えが発生したとしても、グラフィクスデコーダを再生装置がリセットすることはない。メモリ管理を継続させることにより、メニューや字幕があるような位置を、デジタルストリームの分割境界に選ぶことができるので、デジタルストリームの分割境界の選択の自由度を高めることができる。これにより、マルチストーリ型映画作品の制作にあたって、思うようなストーリ展開で、再生を進行させてゆくことができる。
【発明を実施するための最良の形態】
【０００９】
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、BD-ROM１００である。このBD-ROM１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００１０】
以上が本発明に係る記録媒体の使用形態についての説明である。続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、BD-ROMの応用層に対する改良により実施することができる。
図２は、ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現した図である。本図においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
【００１１】
BDMVディレクトリの配下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJAディレクトリと呼ばれる4つのサブディレクトリが存在する。
STREAMディレクトリは、いわばデジタルストリーム本体となるファイル群を格納しているディレクトリであり、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts)が存在する。
【００１２】
PLAYLISTディレクトリは、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls,00003mpls)が存在する。
CLIPINFディレクトリは、PLAYLISTディレクトリ同様、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)が存在する。
【００１３】
本図において拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts・・・・・)は、AVClipを格納している。AVClipには、MainCLip、SubClipといった種別がある。MainCLipは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム(PGストリーム)、メニューを構成するインタラクティブグラフィクスストリーム(IGストリーム)というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００１４】
図３は、AVClipがどのように構成されているかを模式的に示す図である。
AVClipは(中段)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(上１段目)、PESパケット列に変換し(上２段目)、更にTSパケットに変換し(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PGストリーム)及び対話系のインタラクティブグラフィクスストリーム(IGストリーム)を(下１段目)を、PESパケット列に変換し(下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００１５】
BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておく。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arrival_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケットは、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のTP_extra_header付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致するからである。3個のセクタに収められた32個のTP_extra_header付きTSパケットを”AlignedUnit”という。  
【００１６】
以上がAVClipについての説明である。続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。
【００１７】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、PCS(Presentation Composition Segment)、WDS(WindowDefine Segment)、PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(ENDof 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として扱う。
【００１９】
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にDisplaySetを、第１段目にEpochをそれぞれ示す。
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線kz1は、第３段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。
【００２０】
第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう(※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。)。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像−グラフィクスの同期は保証されない。
【００２１】
Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図６は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当に」「ごめん」「あれから」「3年がたった」のうち、2つの字幕「本当に」「ごめん」は画面の下側に、「あれから」「3年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplaySetについて説明する。
【００２２】
図５における破線hk1,2は、第２段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。Epoch Start,AcquisitionPoint,Normal Caseという一連のDSは、第１段目のEpochを構成していることがわかる。『Epoch Start』、『AcquisitionPoint』、『Normal Case』は、DSの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。
【００２３】
『Epoch Start』は、新たなEpochの開始を示す。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。EpochStartは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるDisplay Setである。AcquisitionPointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。AcquisitionPointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisitionPointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【００２４】
『Normal Case』は、前のDisplay Setからの差分のみを含む。例えば、あるDSvの字幕は、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、PCSと、ENDのみのDSvを設けてこのDSvをNormalCaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。一方、Normal CaseのDSは、差分にすぎないので、NormalCase単独では画面構成は行えない。
【００２５】
続いてDefinition Segment(ODS,WDS,PDS)について説明する。
『Object_Definition_Segment』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。BD-ROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BD-ROMでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すPixelCodeと、画素値の連続長とにより、画素列を表現したデータである。Pixel Codeは、8ビットの値であり、1〜255の値をとる。ランレングスデータでは、このPixelCodeによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
【００２６】
ODSによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ODSは、図７（ａ）に示すように自身がODSであることを示す『segment_type』と、ODSのデータ長を示す『segment_length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object_id』と、EpochにおけるODSのバージョンを示す『object_version_number』と、『last_in_sequence_flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object_data_fragment』とからなる。
【００２７】
『Palette Difinition Segment(PDS)』は、パレットデータを格納する機能セグメントである。パレットデータとは、1〜255のPixelCodeと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するPixelCodeを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。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は、グラフィックスプレーンにおける左上画素の水平アドレスであるので、1〜video_widthの値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので1〜video_heightの値をとる。
【００３０】
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、1〜video_width-window_horizontal_positionの値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので1〜video_height-window_vertical_positionの値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【００３１】
続いて『END of Display Set Segment』について説明する。END of Display Set Segmentは、DisplaySetの伝送の終わりを示す指標であり、Display Setにおける機能セグメントのうち、最後のODSの直後に配置される。この END of DisplaySetSegmentの内部構成は、自身が END of Display SetSegmentであることを示す『segment_type』と、当該機能セグメントのデータ長を示す『segment_length』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
【００３２】
以上がODS、PDS、WDS、ENDについての説明である。続いてPCSについて説明する。
PCSは、対話的な画面を構成する機能セグメントである。PCSは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id』と、『composition_object(1)〜(m)』とから構成される。
【００３３】
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、EpochStartであるかを示す。
【００３４】
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnlyDispley Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnlyDispley Updateとは、直前のDisplay Setから、パレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされる場合、本フィールドは”1”に設定される。
【００３５】
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図８（ｂ）の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id_ref』、『window_id_ref』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【００３６】
『object_id_ref』は、グラフィクスオブジェクト識別子(object_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window_id_ref』は、ウィンドゥ識別子(window_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【００３７】
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。
【００３８】
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_position』、『object_cropping_width』、『object_cropping_height』からなる。
【００３９】
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSIEN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４０】
『object_cropping_width』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。続いてPCSの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとに』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるEpochは、DS1(EpochStart)、DS2(Normal Case)を有する。DS1は、字幕の表示枠となるwindowを定義するWDS、台詞『ほんとに  ごめん』を表すODS、1つ目のPCSを備える。DS2(NormalCase)は、2つ目の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は、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。
【００４４】
以上が機能セグメントについての説明である。続いてこれらPCS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplaySetから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。DisplaySet内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplaySetの割り当てである。
【００４５】
Epochに属するDisplay Setのうち、任意のDisplay SetをDSnとすると、DSnは、図１２に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。図１２は、DSnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてDSnの始期は、DSnに属するPCSのDTS値(DTS(DSn[PCS]))により示されており、終期は、DSnに属するPCSのPTS値(PTS(DSn[PCS]))により示されている。そしてDSnにおいて最初の表示が行われるタイミングも、PCSのPTS値(PTS(DSn[PCS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(DSn[PCS])とを一致させれば、DSnの最初の表示は、そのビデオストリームと同期することになる。
【００４６】
PTS(DSn[PCS])は、DTS(DSn[PCS])に、ODSのデコードに要する期間(DECODEDURATION)を足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。図６の期間mc1は、DSnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。
【００４７】
以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
Epochは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら1つのAVClip内でEpochは完結していなければならない。しかし2つのAVClipが順次再生される場合であって、所定の3つの条件が満たされるような場合、2つのAVClip間で連続性をもつようなEpochを定義することができる。
【００４８】
図１３（ａ）は、2つのAVClip間で連続性をもつようなEpochを示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、2つのAVClip間で連続性をもつEpochを示す。第3段目は、第2段目のEpochに属するDisplaySetを示す。第2段目におけるEpochは、AVClipにより分断されない。しかし第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplaySetに分断されている。本図において注目すべきは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型が、”Epoch Continueタイプ”になっていることである。
【００４９】
”Epoch Continue”とは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型であり、所定の3つの条件が満たされる場合、AcquisitionPointとして取り扱われる。この3つの条件のうち、1つでも欠落があれば、Epoch Startとして取り扱われる。
図１３（ｂ）は、Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。本図に示すように、EpochContinueタイプのDisplay Setは、後続AVClipからの飛び込み再生が行われる場合、”Epoch Start”として取り扱われ、先行AVClipから連続再生が行われる場合、”AcquisitionPoint”として取り扱われることがわかる。
【００５０】
図１４は、2つのAVClip間で連続性をもつための3つの条件を示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、3つのEpochを示す。この3つのEpochのうち、真ん中のEpochが、2つのAVClip間でメモリ管理の連続性をもつEpochである。第3段目は、3つのEpochのそれぞれに属するDisplaySetを示す。第2段目におけるEpochは、AVClipにより分断されることはなかったが、第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplaySetに分断されている。第4段目は、各Display Setに属する機能セグメントを示す。この第4段目における機能セグメント群は、図５の第4段目に示したものと同じである。図中の◎1,◎2,◎3が、2つのAVClip間で連続性をもつようなEpochの成立条件を示す。1つ目の条件は、AVClip境界の直後に位置するDisplaySet(DSm+1)の類型が、第3段目に示すようにEpoch Continueになっていることである。
【００５１】
2つ目の条件は、DSm+1に属するPCSのComposition Numberが、1つ前のDSmに属するPCSのComposition Number(=A)と同じであること、つまりグラフィクス表示の内容が、AVClip境界の前後で同じであることを意味する。CompositionNumberは、Display Setによる画面構成を意味するものである。このComposition Numberが同じであるということは、画面構成で得られるグラフィクスの内容が、DSmと、DSm+1とで同じであることを意味する。図１５は、DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。本図に示すように、DSmによるグラフィクスの内容は『3年たった』であり、DSm+1によるグラフィクスの内容は『3年たった』であるので、2つのDisplaySet間でグラフィクスの内容は同じであり、Composition Numberが同一値になっていることがわかる。また、ビデオストリームの再生もシームレス接続になされているので、DSm+1はAcquisitionPointとして取り扱われることがわかる。
【００５２】
3つ目の条件は、先行AVClIPの再生と、後続AVClIPの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
(i)ビデオ属性情報に示されているビデオストリームの表示方式（NTSC、PAL等）が、2つのAVClip間で同一である。
【００５３】
(ii)オーディオ属性情報に示されているオーディオストリームのエンコード方式（AC-3、MPEG、LPCM等）が、2つのAVClip間で同一である。
以上の(i)〜(ii)においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。
【００５４】
例えば、連続して再生すべき2つのオーディオストリームにおいて、一方の符号化方式がAC-3方式であり、他方がMPEG規格である場合、ストリームがAC-3からMPEGへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
これら(i)〜(ii)の関係が全て満たされた場合のみ、シームレス接続がなされる。(i)〜(ii)の関係のうち、１つでも満たされない場合、シームレス接続はなされない。
【００５５】
かかる3つの条件が満たされれば、Epoch ContinueタイプのDSm+1はAcquisition Pointとして取り扱われることになる。つまりDisplaySet1〜m、Display Setm+1〜n間は1つのEpochを形成することになり、2つのAVClipの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
仮にDSm+1の類型がEpoch Continueであったとしても、残り2つの条件のうち、1つの欠落があれば、Epochは、図１６に示すように、AVClipの境界前後で2つに分断されることになる。以上のことからEpochContinueタイプのDisplay Setは、上述したように3つの条件が全て満たされた場合にAcquisition Pointとして扱われる。1つの条件が欠けた場合は、EpochStartとして取り扱われることになる。  図１７は、1つのAVClIP(AVClIP#1)に対して後続AVClip(AVClIP#2、AVClIP#3)が2つ有り、先行AVClIPが分岐点になっている場合のEpochContinueの扱いを示す。2つの先行AVClIPのうち、AVClIP#1は図１４と同じであり、後続AVClipの1つであるAVClIP#2も、図１４と同じである。そのためAVClIP#1、AVClIP#2は3つの条件を全て満たす。そのためAVClIP#1から再生がなされた場合、AVClIP#2の最初のDS(DSm+1)はEpochContinueとして取り扱われることになる。もう一方の後続AVClipであるAVClIP#3はグラフィクス表示の内容が全く同じであり、AVClip#1の最後のDS(DSn)におけるCompositionNumberが、AVClIP#3の最初のDS(DS1)におけるComposition Numberと一致している。そのため、AVClIP#1→AVClIP#3の再生時には、3つの条件が全て満たされることになり、EpochContinueタイプのDisplay SetはAcquisition Pointとして取り扱われることになる。
【００５６】
図１８は、1つのAVClIP(AVClIP#2)が2つの先行AVClIP(AVClIP#1、AVClIP#4)の合流点になっている場合のEpochContinueの扱いを示す。2つの先行AVClIPのうち、AVClIP#1は図１４と同じであり、AVClIP#2も図１４と同一であり、3つの条件を全て満たす。そのためAVClIP#1から再生がなされた場合、AVClIP#2の最初のDS(DS1)はEpochContinueとして取り扱われることになる。一方、AVClIP#4もグラフィクス表示の内容が全く同じであり、AVClIP#4の最後のDS(DSm)におけるCompositionNumberが、AVClIP#2の最初のDS(DS1)におけるComposition Numberと一致している。そのため、AVClIP#4→AVClIP#2の再生時には、3つの条件が全て満たされることになり、EpochContinueタイプのDisplay SetはAcquisition Pointとして取り扱われることになる。
【００５７】
以上がAVClipについての説明である。続いて拡張子”clpi”が付与されたファイル、及び、拡張子”mpls”が付与されたファイルについて説明する。図１９は、clpi”が付与されたファイル、及び、拡張子”mpls”が付与されたファイルを示す図である。
拡張子”clpi”が付与されたファイル(00001.clpi,00002.clpi,00003.clpi・・・・・)は、AVClipのそれぞれに1対1に対応する管理情報である。管理情報故に、Clip情報は、AVClipにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すEP_map、ATC_deltaをもっている。ATC_deltaのATC(ArrivalTime Clock)とは、ATSの基準となるClockであり、ATC_deltaは、先に再生されるAVClipのATCと、後に再生されるAVClipのATCとの間の差分を意味する。
【００５８】
拡張子”mpls”が付与されたファイル(00001.mpls,00002.mpls,00003.mpls・・・・・)は、PL情報を格納したファイルである。PL情報は、AVClipを参照してプレイリストを定義する情報である。図２０は、PL情報の構成を示す図であり、本図の左側に示すように、PL情報は、破線の矢印mp1に示すように複数のPlayItem情報(PlayItem())からなる。PlayItemとは、1つ以上のAVClip時間軸上において、In_Time,Out_Timeを指定することで定義される再生区間である。PlayItem情報を複数配置させることで、複数再生区間からなるプレイリスト(PL)が定義される。図中の破線mp2は、PlayItem情報の内部構成をクローズアップしている。本図に示すようにPlayItem情報は、対応するAVClipを示す『Clip_information_file_name』と、『In_time』と、『Out_time』と、『connection_condition』とからなる。
【００５９】
2つのAVClipを1つのPlayListとして取り扱う場合のPL情報の設定について図２１を参照しながら説明する。図２１の第1段目は、図１５に示した2つのAVClipを示し、図２１の第2段目は、PL情報により定義されるPlayList時間軸を示す。PL情報が2つのPlayItem情報を含んでおり(PlayItem#1、PlayItem#2)、PlayItem#1のIn_time、Out_timeがAVClipの始点、終点を指し示していて、PlayItem#2のIn_time、Out_timeがAVClipの始点、終点を指し示している場合、これら先行AVClIP及び後続AVClIPは、1つのPlayListとして取り扱われることになる。図２１の第2段目は、PL情報により定義されるPlayListの再生時間軸(PL再生時間軸)を示す。このようにPlayListを定義すると、AVClipはいわばPlayListの部分区間として取り扱われることになる。PlayListの部分区間はPlayItemと呼ばれる。つまりPlayItem＝AVClipの関係が成り立つ。
【００６０】
PlayItemを定義するPlayItem情報には、connection_conditionというフィールドがあり、先行するPlayItem(AVClip)との再生がシームレスになされるか否かを示す。
図２２は、各PlayItem(AVClip)に属するDisplay Setと、各PlayItemにおけるconnection_conditionとを示す図である。ここでPlayItem#2に属するDisplaySetのうち、先頭のもの(DSm+1)のSegment TypeがEpoch Continueであり、PlayItem#2のconnection_conditionがシームレス接続を示しているなら、PlayItem#2(後続AVClIP)の先頭にあたるDSm+1と、PlayItem#1(先行AVClip)の最後にあたるDSmとは同一のEpochに属することになる。図２３は、PlayItem#2(後続AVClIP)の先頭にあたるDSm+1と、PlayItem#1(先行AVClip)の最後にあたるDSmとが属する同一のEpochを示す図である。先行AVClipにおける最後のDisplaySetと、後続AVClipにおける最初のDisplay Setとが同一のEpochに帰属するので、これら2つのDisplay Setによるグラフィクス表示は連続してなされることになる。
【００６１】
これまでに説明したDisplay Set(PCS,WDS,PDS,ODS)のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Blu-rayDisc Read Only Formatに規定された構文に従い、クラス構造体を記述することで、BD-ROM上のこれらのデータ構造を得ることができる。
以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２４は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置、マイコンシステムという3つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BDドライブ１、Arrivaltime Clock Counter２a、Source de-packetetizer２b、PIDフィルタ３、Transport Buffer４a,b,c、周辺回路４d、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、CLUT部９、加算器１０、グラフィクスデコーダ１２、CodedData Buffer１３、周辺回路１３a、Stream Graphics Processor１４、Object Buffer１５、CompositionBuffer１６、Graphicalコントローラ１７から構成される。
【００６２】
BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行して、32個のセクタからなるAlignedUnitをBD-ROMから読み出す。
Arrival time Clock Counter２aは、27MHzの水晶発振器(27MHz X-tal)に基づき、Arrival Time Clockを生成する。ArrivalTime Clockとは、TSパケットに付与されたATSの基準となる時間軸を規定するクロック信号である。
【００６３】
Source de-packetetizer２bは、BD-ROMから32個のセクタからなるAligned Unitが読み出されれば、Aligned Unitを構成するそれぞれのTSパケットから、TP_extra_headerを取り外して、TSパケットのみをPIDフィルタ３に出力する。Sourcede-Packetizer２bによるPIDフィルタ３への出力は、Arrival time Clock Counter２aが経時している時刻が、TP_extra_headerに示されるATSになったタイミングになされる。PIDフィルタ３への出力は、ATSに従いなされるので、たとえBD-ROMからの読み出しに1倍速、2倍速といった速度差があっても、PIDフィルタ３へのTSパケット出力は、ArrivalTime Clockが経時する現在時間に従いなされることになる。2つのAVClipを連続再生しようとする場合、Source de-packetetizer２bは、Clip情報中に存在するATC_Deltaを用いて、2つのAVClipにおけるATCのズレを調整する。
【００６４】
PID Filter３は、TSパケットに付加されているPIDを参照することにより、TSパケットが、ビデオストリーム、PGストリーム、IGストリームの何れに帰属するのかを判定して、TransportBuffer４a,b,cのどれかに出力する。  
Transport Buffer４a,b,cは、PIDフィルタ３から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。
【００６５】
周辺回路４dは、Transport Buffer４a,b,cから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCodedData Buffer１３に格納される。
ビデオデコーダ５は、PIDフィルタ３から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
【００６６】
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、PIDフィルタ３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
【００６７】
CLUT部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるY,Cr,Cb値に基づき変換する。
加算器１０は、CLUT部９により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
【００６８】
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
このグラフィクスデコーダ１２は、Coded Data Buffer１３、周辺回路１３a、Stream Graphics Processor１４、ObjectBuffer１５、Composition Buffer１６、Graphicalコントローラ１７から構成される。
【００６９】
Coded Data Buffer１３は、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、TransportBuffer４a,b,cに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS／DTSは、PESパケットと対応付けて格納される。
【００７０】
周辺回路１３aは、Coded Data Buffer１３−Stream Graphics Processor１４間の転送、Coded Data Buffer１３−CompositionBuffer１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がODSのDTSに示される時刻になれば、ODSを、Coded DataBuffer１３からStream Graphics Processor１４に転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをCompositionBuffer１６に転送するという処理を行う。
【００７１】
Stream Graphics Processor１４は、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObjectBuffer１５に書き込む。Stream Graphicsプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをStreamGraphicsプロセッサ１４は一時的に保持する。Stream Graphicsプロセッサ１４によるデコードは瞬時になされるが、Stream Graphicsプロセッサ１４からObjectBuffer１５への書き込みは、瞬時には終わらない。BD-ROM規格のプレーヤモデルでは、Object Buffer１５への書き込みは、128Mbpsという転送レートでなされるからである。ObjectBuffer１５への書き込み完了時点は、ENDセグメントのPTSに示されているので、このENDセグメントのPTSに示される時点が経過するまで、次のDSに対する処理を待つことになる。各ODSをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。
【００７２】
Object Buffer１５は、Stream Graphics Processor１４のデコードにより得られたグラフィクスオブジェクトが配置されるバッファである。ObjectBuffer１５は、グラフィクスプレーン８の2倍／4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン８の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【００７３】
Composition Buffer１６は、PCS、PDSが配置されるメモリである。−−処理すべきDisplay Setが2つあり、これらのPCSのアクティブ期間が重複している場合、Compositionバッファ１６には処理すべきPCSが複数格納される。
Graphicalコントローラ１７は、Graphicalコントローラ１７はPCSの解読を行い、PCSの解読結果に従って、グラフィクスオブジェクトのObjectBuffer１５への書き込み、及び、Object Buffer１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Graphicalコントローラ１７による表示は、PCSを格納したPESパケットのPTSに示される時点において実行される。Graphicalコントローラ１７によるDSnに属するグラフィクスオブジェクトの表示から、DSn+1に属するグラフィクスオブジェクトの表示までの間隔は上述した通りである。
【００７４】
図２５は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegment(ICS,PDS,ODS)のそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で(ステップＳ１)、ステップＳ２〜Ｓ１３の処理を全てのSegmentについて繰り返すループ構造を有している(ステップＳ１４、ステップＳ１５)。
【００７５】
ループ構造をもつステップＳ２〜ステップＳ１５の処理は、無視フラグが1かどうかを判定して(ステップＳ３)、無視フラグが0であるなら、対象となる機能セグメントをCodedDataバッファ１３からCompositionバッファ１６、Stream Graphicsプロセッサ１４のどれかに転送し(ステップＳ４)、無視フラグが1であるならかかる転送を行わずCodedDataバッファ１３上で、対象となる機能セグメントを削除する(ステップＳ５)という処理を、機能セグメントの読み出しが継続している限り繰り返すものである。
【００７６】
SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ９、Ｓ１０は、この無視フラグを設定する処理である。
ステップＳ６は、PCSにおけるComposition_StateがEpoch Continueであるか否かの判定である。SegmentKがEpochContinueであるなら、ステップＳ７〜ステップＳ９が実行され、SegmentKがもしEpoch StartかNormal Caseであるなら、ステップＳ１０〜ステップＳ１２が実行される。
【００７７】
ステップＳ７〜ステップＳ９は、ステップＳ７、ステップＳ８という2回の判定を行い、これらの判定が両方ともYesであった場合のみ、無視フラグを1に設定する(ステップＳ９)。
ステップＳ７は、PCSが属するPlayItemのconnection_conditionが”＝5(シームレス接続)”であるか否かの判定である。ステップＳ８は、新たに読み出されたPCSにおけるCompositionNumberが、Compositionバッファ１６上にあるPCSにおけるComposition Numberと同一であるか否かの判定である。
【００７８】
これらのステップＳ７、ステップＳ８のどちらかがNoであれば、ステップＳ１０に移行して、無視フラグを0に設定する。ステップＳ７、ステップＳ８の双方がYesであれば、無視フラグは1に設定されることになる(ステップＳ９)。
ステップＳ１１は、新たに読み出されたPCSのComposition_StateがNormal Caseであるか否かの判定であるか、Epoch Startであるかの判定である。もしEpochStartであるなら、無視フラグを0に設定する(ステップＳ１０)。
【００７９】
ステップＳ１１は、PCSにおけるComposition_StateがNormal Caseであるか否かの判定である。もしNormal Caseであるなら、追加のチェックとしてステップＳ１２を実行する。ステップＳ１２は、グラフィクスオブジェクトがObjectBufferに存在しており、PCS,PDS,WDSがComposition Buffer１６に存在するかの判定である。もし、存在すれば無視フラグを0に設定する(ステップＳ１０)。存在しなければ、ステップＳ９に移行する。
【００８０】
Object Bufferにグラフィクスオブジェクトが存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないという理由による。
図２６は、図１４に示した2つのAVClipを再生するにあたってのDisplay Set読み出しがどのように行われるかを示す図である。第3段目は、AVClipに多重化されているDisplaySetを示し、第2段目は、ビデオストリームを構成する複数のピクチャを、第1段目はグラフィクスデコーダにおける状態を示す。
【００８１】
Epochの先頭に位置するDS1の読み出し時には、グラフィクスデコーダに対するリセットがなされ、DS1を構成するPCS、WDS、PDS、ODSがCodedDataバッファ１３に順次読み出されることになる。そしてPCS、WDS、PDSはCompositionバッファ１６に転送され、ODSはStreamGraphicsプロセッサに出力されることになる。
矢印mr1は、DSmの読み出し時を示す。DSmを構成するPCS、WDS、PDS、ODSがCoded Dataバッファ１３に順次読み出されることになる。このDSmのconnection_conditionは、AcquisitionPointなので、PCS、WDS、PDSはCompositionバッファ１６に転送されることなく廃棄される。一方、ODSもStream Graphicsプロセッサに出力されることなく廃棄される。
【００８２】
矢印mr2は、DSm+1の読み出し時を示す。この場合グラフィクスデコーダは、3つの条件が満たされるか否かを判定する。DSm+1のChange streamがEpochContinueを示しており、ビデオストリームの再生がシームレスになされ、そしてDSm+1のComposition Numberが、Compositionバッファ１６上のPCSのCompositionNumberと一致していれば、これら3つの条件が満たされることになり、DSm+1をAcquisition Pointとして扱う。これにより再生装置は、グラフィクスデコーダをリセットせず、CodedDataバッファ１３に読み出されたPCS、WDS、PDSをCompositionバッファ１６に転送することなく廃棄する。一方、ODSもStreamGraphicsプロセッサに出力することなく廃棄する。こうすることで、グラフィクスデコーダの状態は継続することになる。
【００８３】
以上が通常再生時における処理であるが、チャプタージャンプやチャプターサーチによりAVClIPへの飛び込み再生がなされた場合、この飛び込みの指示と同時に、グラフィクスデコーダのリセットがなされることになる。これによりグラフィクスデコーダ上で管理されているカレントCompositionNumberは、新たに再生されようとする先行AVClIPにおけるDSm+1のComposition Numberと一致することはない。このためDSm+1は、飛び込み再生時において、EpochStartとして取り扱われることになる。
【００８４】
図２７は、図１４に示したAVClIP#2への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す。第1段目〜第3段目の意味内容は、図２６と同じであり、矢印の意味合いも図と同じである。ただ、グラフィクスの表示内容が図２６と違っているため、CompositionNumberは違う値になっている。後続AVClipの再生が開始され、DSm+1がCoded Dataバッファ１３に読み出されると、グラフィクスデコーダはCodedDataバッファ１３に読み出されたPCSを解読してDSm+1におけるChange streamが何であるかを判定する。Epoch Continueであれば残る2つの条件を判定する。ここでビデオストリームの再生がシームレスに行われたとしても、CompositionNumberが先行AVClIPから変化しているためグラフィクスデコーダはDSm+1をEpoch Startとして扱う。これによりグラフィクスデコーダはリセットされ、CodedDataバッファ１３に読み出されたPCS、WDS、PDSはCompositionバッファ１６に転送され、ODSはStream Graphicsプロセッサに出力されることになる。
【００８５】
(第２実施形態)
第２実施形態は、Epoch Continueを実現するためのPTS設定に関する実施形態である。2つのAVClipを順次再生しようとする場合、これらが基準としているクロックが異なることを考慮せねばならない。オーサリング時においてAVClipは、それぞれ別々の機会にエンコードされるから、2つのAVClipは、別々のクロック信号を基準にして生成される。AVClip生成時にあたって、エンコードの基準に用いられるクロックをSTC(SystemTime Clock)という。かかるSTCは、再生装置の再生時においてもデコード処理の基準になる。
【００８６】
STCが異なる2つのAVClipを連続して再生させるため、再生装置は、STCのズレ量(STC_delta)を算出して、自身が内蔵しているクロックの計数値に、このSTC_deltaを加算することにより、かかるSTCの違いを吸収する。図２８は、先行AVClIPに属するビデオストリームのPTS値と、後続AVClIPに属するビデオストリームのPTS値とを対比して示す図である。先行AVClIPにおいて最後に再生される再生装置の表示開始時刻をPTS(1stEND)、ピクチャの表示期間をTppとし、後続AVClIPにおいて最初に表示されるピクチャの開始時刻をPTS(2ndSTART)とした場合、STC_deltaは
STC_delta＝PTS(1stEND)＋Tpp−PTS(2ndSTART)
として表現される。これは、2つのAVClipを順次再生する際、PTS(1stEND)＋Tppと、PTS(2ndSTART)とは本来一致するべきであり、PTS(1stEND)＋Tppと、PTS(2ndSTART)との違いがSTCの違いであると考えることができるという理由による。
【００８７】
2つのAVClipを連続して再生しようとする場合、PTS(1stEND)、PTS(2ndSTART)をそれぞれ検出して、これらからSTC_deltaを算出する。そして再生装置に内蔵されているクロックの計数値にSTC_deltaを足し合わせて、STC_deltaが足し合わされたクロックの計数値をビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２のそれぞれに出力する。このようにSTC_deltaが足し合わされたクロック計数値を基準することで、ビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２は、2つのAVClipに属するビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリームを途切れなく再生してゆくことができる。
【００８８】
かかる処理を円滑に行うため、後続AVClIPに属するプレゼンテーショングラフィクスストリームにおいて、先頭に位置するDSm+1のPTS(DSm+1[PCS])の値を調整しておく。どのように調整するかというと、PTS(1stEND)＋Tpp及びPTS(2ndSTART)と同じ時刻を指すように、調整しておくのである。これは以下の理由による。再生装置は、先行AVClIPにおける最後のグラフィクス表示が行われてから。後続AVClIPにおける最初の表示が行われるまでの間隔が長いと、一旦グラフィクスデコーダをリセットしてしまうことがある。BD-ROMにおける複数AVClipは、それぞれ別々のファイルに格納されているため、2つのファイルを連続して読み出すにはタイムラグがあり、2つのAVClipの読み出しが遅れた場合は、リセットがなされる確率がますます高くなる。そこで後続AVClIPの先頭に位置するEpochContinueタイプのDisplay Setは、ビデオストリームの最初のピクチャが表示されるのと同じタイミングで、グラフィクス表示が行われるよう、PTS(1stEND)+Tppの値と、同じ時刻を示すように、PTS(DSm+1[PCS])の値を設定しておく。
【００８９】
こうすることで、先行AVClIPの読み出しの完了後から後続AVClIPの読み出し開始までのタイムラグが長くなったとしても、先行AVClIPにおける最後のグラフィクス表示が行われてから、後続AVClIPにおける最初の表示が行われるまでの間隔は最短にしておくことができる。こうすることにより再生装置はグラフィクスデコーダをリセットすることはないので、そのままメモリ状態を継続させることができる。
【００９０】
(第３実施形態)
第１実施形態では、PGストリームについて説明を行ったが、第３実施形態はIGストリームについての実施形態である。続いてインタラクティブグラフィクスストリームについて説明する。図２９（ａ）は、インタラクティブグラフィクスストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。尚、プレゼンテーショングラフィクスストリームについては、本願の主眼ではないので説明は行わない。
【００９１】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ICS(Interactive Composition Segment)、PDS(PaletteDifinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ICSは、画面構成セグメントと呼ばれ、PDS、ODS、ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。図２９（ｂ）は、機能セグメントを変換することにより得られるPESパケットを示す図である。
【００９２】
以降、各機能セグメントについて説明する。
『Interactive Composition Segment(ICS)』は、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。対話的な画面構成の1つとして、本実施形態のICSは、マルチページメニューを実現するものとする。
これら様々な種別の機能セグメントは、図３０のような論理構造を構築する。図３０は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にEpochを、第２段目にDisplaySetを、第３段目にDisplay Setの類型をそれぞれ示す。図２９（ａ）の第3段目に示した機能セグメントは第４段目に描かれている。IGストリームにも、EpochStart、Acquisition Point、Epoch Continueという類型があるが、PCSと異なるのは、Acquisition Pointという類型においてページ毎のバージョンアップが可能になることである。
【００９３】
IGストリームは、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための新規な構成は、ICS内のInteractive_compositionに存在する。以降ICS、Interactive_compositionの内部構成について以下説明する。
図３１（ａ）（ｂ）は、ICSとInteractive_compositionとの対応関係を示す図である。ICSとInteractive_compositionとの対応関係には、図７（ａ）に示すような1対1のものと、図３１（ｂ）に示すような1対多のものとがある。
【００９４】
対応関係が1対1になるのは、Interactive_compositionのサイズが小さく、1つのICS内にInteractive_compositionが収まる場合である。
1対多の対応関係になるのは、Interactive_compositionのサイズが大きく、Interactive_compositionがフラグメント化され、複数ICSに格納される場合である。複数ICSへの格納が可能なので、Interactive_compositionサイズには制限がなく、512Kバイトであろうと、1Mバイトであろうと、Interactive_compositionのサイズを大きくすることができる。ICS、Interactive_compositionには1対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ICS、Interactive_compositionの対応関係は、1対1であるとする。
【００９５】
図３２は、ICSの内部構成を示す図である。ICSには、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部が格納されている。図８の左側に示すように、ICSは、自身がICSであることを示す『segment_descriptor』と、本ICSが想定している縦横の画素数、フレームレートを示す『video_descriptor』と、『composition_descriptor』と、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部である『Interactive_composition_data_fragment』とからなる。
【００９６】
図３２中の矢印cu1は、『composition_descriptor』の内部構成をクローズアップして示す。この矢印cu1に示すように『composition_descriptor』は、本ICSが属するDisplaySetが、Normal Case、Acquisition Point、Epoch Start、Effect_Sequenceの何れであるかを示す『composition_state』と、画面合成の回数を示す『Composition_Number』とを含む。
【００９７】
図３２の矢印cu2は、Interactive_compositionの内部構成をクローズアップしている。この矢印に示すようにInteractive_compositionは、『Interactive_composition_length』,『Stream_model』,『user_interface_model』,『composition_time_out_pts』,『selection_time_out_pts』,『user_time_out_duration』、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報(1)(2)・・・(i)・・・(number_of_page-1)』を含む。
【００９８】
『Interactive_composition_length』は、Interactive_compositionのデータ長を示す。
『Stream_model』は、Interactive_compositionが想定しているストリームモデルのタイプを示す。ストリームモデルとは、Interactive_compositionがどのような形態でBD-ROMに記録されて、再生装置におけるコンポジションバッファ上でどのように扱われるかを示すものであり、Stream_modelは、グラフィクスストリームがAVClipから多重分離されてコンポジションバッファ上にロードされたものであるか(i)、SubClipとして、コンポジションバッファにプリロードされたものであるか(ii)を示す。
【００９９】
『user_interface_model』は、Interactive_compositionが想定しているユーザインターフェイスモデルが、Always-onU/IであるかPop-upU/Iであるかを示す。Always-onU/Iとは、AVClipの再生進行に伴ってメニューの表示・消去がなされるユーザインターフェイスであり、ポップアップU/Iとは、ユーザによる操作をトリガにしてメニューの表示・消去がなされるユーザインターフェイスである。
【０１００】
『Composition_time_out_pts』は、ICSが帰属するEpochの終期(Epoch END)を示す。ICSによる対話制御は、このEpoch終期(EpochEND)においてもはや不可能となるので、このcomposition_time_out_ptsに示される時点が、対話制御の終期を意味する。
『selection_time_out_pts』は、セレクテッド状態にあるボタンを自動的にアクティベートするためのタイムアウト時刻を示す。ボタンとは、マルチページメニューにおける個々の選択項目であり、かかるボタンの状態をアクティブ状態に変化させる時間を規定しているのがこのselection_time_out_ptsである。
【０１０１】
図中のIF文(if(Stream_model=='0b'))は、上述したcomposition_time_out_pts及びselection_time_out_ptsが、Stream_model=Multiplexedの際、出現する任意の情報要素であることを示してる。ICSが想定しているストリームモデルがプリロードである場合、これらcomposition_time_out_pts、selection_time_out_ptsは存在しない。
『user_time_out_dutration』は、ユーザ操作により表示され得るページを消去するためのタイムアウト時刻を示す。Always-onU/Iでは、2ndPage以降のPage(SubPageという)がユーザ操作により表示されるので、このuser_time_out_dutrationのタイムアウトにより、SubPageのみが消去され、1stPageのみとなる。Pop-upU/Iでは、SubPageだけではなく、マルチページメニュー全体がユーザ操作により表示されるので、user_time_out_dutrationのタイムアウトにより、全てのページが消去され何も表示されない状態(NoMenu Display)になる。
【０１０２】
図３３は、1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。この図３３の右側に示すようにPage情報(y)は、
i)Page(y)を一意に識別する『page_id』、
ii)Page情報(y)により運搬されるデータ構造の中身にあたる,『UO_Mask_Table』、『in_effect』,『out_effect』,『animation_frame_rate_code』,『default_selected_button_id_ref』、『default_activated_button_id_ref』,『pallet_id_ref』,『ボタン情報(1)(2)・・・・・(number_of_buttons-1)』、
iii)Page情報(y)の中身のバージョンを示す『Page_Version_Number』
から構成される。
先ず初めに、Page情報(y)により運搬されるデータ構造を構成する各フィールドについて説明する。
【０１０３】
『UO_Mask_Table』は、Page(y)におけるユーザ操作の許可／不許可が設定されるテーブルである。
『in_effect』は、Page(y)の表示開始時あたって再生すべき表示効果を示す。  『out_effect』は、Page(y)の表示終了時あたって再生すべき表示効果を示す。
『animation_frame_rate_code』は、Page(y)にアニメーション表示を適用する際、適用すべきフレームレートを記述する。
【０１０４】
『default_selected_button_id_ref』は、Page(y)の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”OxFF”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ(PlayerStatus Register(PSR))の設定値が優先的に解釈され、PSRに示されるボタンがセレクテッド状態になる。本フィールドが0xFFでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『default_selected_button_id_ref』に規定されたボタン番号でPSRを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。
【０１０５】
『default_activated_button_id_ref』は、selection_time_out_ptsに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。default_activated_button_id_refが”FF”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このdefault_activated_button_id_refが00であれば、自動選択はなされない。00,FF以外の値であれば本フィールドは、有効なボタン番号として解釈される。
【０１０６】
『pallet_id_ref』は、Page(y)において、CLUT部に設定すべきパレットのidを示す。
『ボタン情報(Button_info)』は、Page(y)上に表示される各ボタンを定義する情報である。以上のフィールドにより、マルチページメニューにおける個々のページの中身は特定される。
『Page_Version_Number』は、EpochにおいてPage情報(y)のデータ構造により運搬される中身のバージョンを示すフィールドである。このPage_Version_Numberは本願の主眼となるものであるので、このPage_Version_Numberについて詳しく説明する。ページ情報(y)のバージョンとは、ページ情報で運搬されるデータ構造の中身が、何回目のアップデートを経たものであるかを示す。Page情報(y)のデータ構造において、Page_Version_Number直後のフィールドのうち、どれかの値が変化した場合、又は、Page_Version_Number直後の各フィールドに何等かの変化があった場合、Page情報(y)は、アップデートされたとみなされる。
【０１０７】
Page_Version_Numberによるバージョンは、1つのEpochにおける通し番号で表現される。そのため、このPage_Version_Numberの値は、ページ情報が1つのEpochにおいてどのDisplaySetに属するかによって変わる。1つのEpochにおいてEpoch Startに属するページ情報では、このPage_Version_Numberは初期値(=0)に設定される。一方、2つ目以降のDisplaySetのうち、アップデートをもたらすもの(Acquisition Point、Normal Case)に属するPage_Version_Numberには、アップデート回数を示す1〜255の値が設定される。
【０１０８】
以降図３４の具体例を交えてこのPage_Version_Numberについて詳しく説明する。
図３４は、連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。DSx+1はAcquisitionPointであり、このDisplay Setの任意のページ情報(y)を着眼する。このDSx+1のPage情報(y)の中身が、DSxと全く同一であれば、DSx+1.Page情報(y)のPage_Version_Numberは、DSx.Page情報(y)のPage_Version_Numberと同じ値に設定される。このPage_Version_Numberを参照することにより再生装置は、DSx、DSx+1の間において、Page情報(y)の中身から変わっていないと判断することができる。これに対し図３５では、DSx+1におけるPage情報(y)の中身は、DSxにおけるPage情報(y)のそれから変わっている。この場合、DSx+1.Page情報(y)のPage_Version_Numberは、DSx.Page情報(y)の値に1を加えた値(=A+1)になっている。かかるPage_Version_Numberの値を参照することで再生装置は、DSx+1におけるPage情報(y)が、DSxのPage情報(y)から変化していることを知ることができる。
【０１０９】
図３６は、DSx.Page情報(y)により構成されるページと、DSx+1.Page情報(y)により構成されるページとを対比して示す図である。
DSx+1におけるPage情報(y)により構成されるページは、3つのボタン(A,B,C)をボタンB→ボタンC→ボタンAの順に配置するものである。
一方、DSxにおけるPage情報(y)により構成されるページは、3つのボタン(ボタンA、ボタンB、ボタンC)を、ボタンA→ボタンB→ボタンCの順に配置するものである。２枚のページの違いは、ボタンの順序がボタンA→ボタンB→ボタンCからボタンB→ボタンC→ボタンAに変化している点に過ぎない。たとえ変化が僅かなものであったとしても、DSx+1のPage情報(y)におけるPage_Version_Numberの値は、DSxより増えた値になる。Page_Version_Numberをこのように設定しておくことでPage情報(y)における些細な変化を、再生装置にシグナリングすることができる。
【０１１０】
これまでの説明は、Acquisition PointDisplay SetにおけるInteractive_compositionをアップデートする一例であったが、NormalCaseに属するInteractive_compositionにおいても、ページ情報毎にPage_Version_Numberが存在する。そしてページ情報毎の内容変化を、このPage_Version_Numberに示させておくことができる。
第１実施形態同様、先行AVClIPと、後続AVClIPとの間で3つの条件が満たされている場合は、後続AVClIPにおけるEpoch ContinueタイプのDisplaySetをAcquisition Pointとして扱うことができる。更にAcquisition PointタイプのDisplay Setでは、page情報毎にPage_Version_Numberをインクリメントすることができるので、EpochContinueタイプのDisplay Setに属するICSにおいて、Page_Version_Numberが増えたページ情報があれば、Compositionバッファ１６に格納されているICS内のページ情報のうち、Page_Version_Numberが増えたページ情報のみを更新することができる。
【０１１１】
以上が本実施形態に係る記録媒体についての改良である。続いて本実施形態に係る再生装置について説明する。上述したようにIGストリームは、PGストリーム同様の構成を有しているため、図２４の内部構成をもつ再生装置により、再生を行うことができる。
IGストリーム内に、Epoch ContinueタイプのDisplay Setが存在するため、本実施形態に係るGraphicsコントローラ１７は、図３７のフローチャートに従って処理を行う。本フローチャートは、図２５のフローチャートにおけるPCSという表記を、ICSという表記に置き換えたものである。この置き換えに加え、ステップＳ２１、ステップＳ２２が追加されている点が新規である。ステップＳ２１は、ステップＳ７−ステップＳ８がどちらもYesと判定され、AcquisitionPointとして処理する場合に、実行されるステップである。ステップＳ２１では、Page_Version_Numberが変化したページ情報が存在するかどうかの判定を行い、もし存在すれば、Compositionバッファ１６に存在するInteractive_compositionにおけるページ情報のうち、Page_Version_Numberが変化したもののみを、新たなページ情報に置き換える。こうすることで、EpochContinueタイプのDisplay Setを、ページ情報毎にアップデートしてゆくことができる。
【０１１２】
以上のように本実施形態によれば、メニュー表示実現のためのDisplay Setにおいても、Epoch Continueという類型があるので、2つのAVClipを順次再生しようとする場合でもメニュー表示を途切れないようにすることができる。
(第４実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図３８は、第１実施形態〜第３実施形態に示したBD-ROMを作成するための製造工程を示す図である。
【０１１３】
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１３を含む。
【０１１４】
以降ステップＳ２０４〜ステップＳ２１３について説明する。ステップＳ２０４において制御情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５において、制御情報、パレット定義情報、グラフィクスを機能セグメントに変換する。ステップＳ２０６では、同期したいピクチャが出現するタイミングに基づき、ICSのPTSを設定する。そしてステップＳ２０７では、PTS[ICS]の値に基づき、DTS[ODS],PTS[ODS]を設定し、ステップＳ２０８においてDTS[ODS]の値に基づき、DTS[ICS],PTS[PDS]を設定する。
【０１１５】
ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのDTS、PTSを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してAVClipを得る。以降、AVClipをBD-ROMのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
【０１１６】
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
【０１１７】
(A)全ての実施形態では、本発明に係る記録媒体をBD-ROMとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレキシブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバブルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。
【０１１８】
(B)全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムLSI(集積回路)のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１１９】
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムが使用される行為の形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１２０】
(E)IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてAligned Unitの送信を行ってもよい。つまり送り手側の機器は、AlignedUnitに含まれる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(VideoObject)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。
【０１２１】
(G)各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１２２】
(H)各実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いている。デコードを実現する装置構成を、字幕−グラフィックスオブジェクト間で共通化する目的で、字幕と同じ圧縮・伸長方式をグラフィックスオブジェクトに採用している。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはPNGデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１２３】
(I)グラフィックスプレーンクリア及び再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は1/29.93秒の25%と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc=256Mbpsの転送レートであっても、スムーズな表示の実現が可能になる。
【０１２４】
(J)各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行(ライン)毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
(K)各実施形態におけるグラフィックスプレーンは、ダブルバッファとして構成することが望ましい。グラフィックスプレーンをダブルバッファで構成すれば数フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯にメニューを表示する場合に有意義である。
【０１２５】
(L)Epoch ContinueのDisplay Setを、Acquisition Pointとして扱うには、AVClip境界の直後に位置するDisplaySet(DSm+1)の類型が、Epoch Continueになっていること(第１の条件)、DSm+1に属するPCSのComposition Numberが、1つ前のDSmに属するPCSのCompositionNumberと同じであること(第２の条件)、先行AVClIPの再生と、後続AVClIPの再生とがシームレス接続されること(第３の条件)という3つの条件があった。このうち、第２の条件又は第３の条件は、必須の条件ではなく、第１の条件が満たされていれば、つまり、AVClip境界の直後に位置するDisplaySet(DSm+1)の類型が、Epoch Continueになっていれば、Epoch ContinueのDisplay Setを、AcquisitionPointとして扱ってもよい。
【産業上の利用可能性】
【０１２６】
本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【図面の簡単な説明】
【０１２７】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現した図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。  （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトのデータ構造を示す図である。  （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。  （ｂ）PCSのデータ構造を示す図である。
【図９】字幕表示を実現するための記述例を示す図である。
【図１０】DS1におけるPCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図１３】（ａ）2つのAVClip間で連続性をもつようなEpochを示す図である。  （ｂ）Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。
【図１４】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【図１５】DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。
【図１６】AVClipの境界前後で2つに分断されたEpochを示す図である。
【図１７】1つのAVClIP(AVClIP#1)に対して後続AVClip(AVClIP#2、AVClIP#3)が2つ有り、分岐点になっている場合のEpochContinueの扱いを示す図である。
【図１８】1つのAVClIP(AVClIP#2)が2つの先行AVClIP(AVClIP#1、AVClIP#4)の合流点になっている場合のEpochContinueの扱いを示す図である。
【図１９】clpi”が付与されたファイル、及び、拡張子”mpls”が付与されたファイルを示す図である。
【図２０】PL情報の構成を示す図である。
【図２１】2つのAVClipを1つのPlayListとして取り扱う場合のPL情報の一例を示す図である。
【図２２】各PlayItem(AVClip)に属するDisplay Setと、各PlayItemにおけるconnection_conditionとを示す図である。
【図２３】PlayItem#2(後続AVClIP)の先頭にあたるDSm+1と、PlayItem#1(先行AVClip)の最後にあたるDSmとが属する同一のEpochを示す図である。
【図２４】本発明に係る再生装置の内部構成を示す図である。
【図２５】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図２６】図１４に示した2つのAVClipを再生するにあたってのDisplay Set読み出しがどのように行われるかを示す図である。
【図２７】図１４に示したAVClIP#2への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す図である。
【図２８】先行AVClIPに属するビデオストリームのPTS値と、後続AVClIPに属するビデオストリームのPTS値とを対比して示す図である。
【図２９】（ａ）インタラクティブグラフィクスストリームの構成を示す図である。  （ｂ）機能セグメントを変換することにより得られるPESパケットを示す図である。
【図３０】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図３１】（ａ）（ｂ）ICSとInteractive_compositionとの対応関係を示す図である。
【図３２】ICSの内部構成を示す図である。
【図３３】1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。
【図３４】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３５】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３６】DSx.Page情報(y)により構成されるページと、DSx+1.Page情報(y)により構成されるページとを対比して示す図である。
【図３７】IGストリーム内に、Epoch ContinueタイプのDisplay Setが存在する場合の、Graphicsコントローラ１７による処理手順を示す図である。
【図３８】第１実施形態〜第３実施形態に示したBD-ROMを作成するための製造工程を示す図である。
【図１】
0004496170.tif 000002
【図２】
0004496170.tif 000003
【図３】
0004496170.tif 000004
【図４】
0004496170.tif 000005
【図５】
0004496170.tif 000006
【図６】
0004496170.tif 000007
【図７】
0004496170.tif 000008
【図８】
0004496170.tif 000009
【図９】
0004496170.tif 000010
【図１０】
0004496170.tif 000011
【図１１】
0004496170.tif 000012
【図１２】
0004496170.tif 000013
【図１３】
0004496170.tif 000014
【図１４】
0004496170.tif 000015
【図１５】
0004496170.tif 000016
【図１６】
0004496170.tif 000017
【図１７】
0004496170.tif 000018
【図１８】
0004496170.tif 000019
【図１９】
0004496170.tif 000020
【図２０】
0004496170.tif 000021
【図２１】
0004496170.tif 000022
【図２２】
0004496170.tif 000023
【図２３】
0004496170.tif 000024
【図２４】
0004496170.tif 000025
【図２５】
0004496170.tif 000026
【図２６】
0004496170.tif 000027
【図２７】
0004496170.tif 000028
【図２８】
0004496170.tif 000029
【図２９】
0004496170.tif 000030
【図３０】
0004496170.tif 000031
【図３１】
0004496170.tif 000032
【図３２】
0004496170.tif 000033
【図３３】
0004496170.tif 000034
【図３４】
0004496170.tif 000035
【図３５】
0004496170.tif 000036
【図３６】
0004496170.tif 000037
【図３７】
0004496170.tif 000038
【図３８】
0004496170.tif 000039