JP2020098661A - 再生装置、及び、再生方法 - Google Patents

Abstract

【課題】ＨＤＲとＳＤＲとが両方記録される記録媒体の再生制御を簡素化する。【解決手段】記録媒体には、Ｃｏｍｂｉ（）と、ＣｏｍｂｉＥｘｔ（）とを含むプレイリストファイルが記録され、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、ＣｏｍｂｉＥｘｔ（）には、ＳＤＲビデオストリーム及びＳＤＲ字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される。【選択図】図４６

Description

本発明は、符号化されたビデオストリームが記録された記録媒体、そのビデオストリームを再生する再生方法、および再生装置に関するものである。

従来、ＤＶＤに関する技術が開示されている（例えば、特許文献１参照）。

特開平９−２８２８４８号公報

しかしながら、上記特許文献では、更なる改善が必要とされていた。

本発明の一態様に係る記録媒体は、再生環境に応じて選択的に用いられる、標準輝度範囲のビデオストリーム及び前記標準輝度範囲よりも輝度範囲の広い高輝度範囲のビデオストリームと、前記再生環境に応じて選択的に用いられる、前記標準輝度範囲の字幕ストリーム及び前記高輝度範囲の字幕ストリームと、コンテンツの再生制御情報が格納されるプレイリストファイルであって、メインストリームに関する前記再生制御情報が格納される管理領域、及び、拡張領域を含むプレイリストファイルとが記録され、前記管理領域には、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、前記拡張領域には、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される。

上記態様によれば、更なる改善を実現することができる。

ＳＤ−ＤＶＤの構造を示す図である。 ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。 ＤＶＤにおけるＶＯＢの構成を示す概要図である。 ＢＤ−ＲＯＭのデータ階層を示す図である。 ＢＤ−ＲＯＭに記録されている論理データの構造を示す図である。 ＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。 図６に示すプレーヤの構成を詳細化したブロック図である。 ＢＤ−ＲＯＭのアプリケーション空間を示す図である。 ＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。 ＭＰＥＧストリームにおけるパックの構成を示す図である。 ＡＶデータとプレーヤ構成との関係を説明するための図である。 トラックバッファを使ったＶＯＢデータ連続供給モデルを説明するための図である。 ＶＯＢ管理情報ファイルの内部構造を示す図である。 ＶＯＢＵ情報の詳細を説明するための図である。 タイムマップを使ったアドレス情報取得方法を説明するための図である。 プレイリストの構成を示す図である。 イベントハンドラテーブルの構成を示す図である。 ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。 グローバルイベントハンドラテーブルの構成を示す図である。 タイムイベントの例を示す図である。 ユーザのメニュー操作によるユーザイベントの例を示す図である。 グローバルイベントの例を示す図である。 プログラムプロセッサの機能的な構成を説明するための図である。 システムパラメータ（ＳＰＲＭ）の一覧を示す図である。 ２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。 メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。 ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフローチャートである。 ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフローチャートである。 図２９の（Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフローチャートであり、図２９の（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフローチャートである。 ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフローチャートである。 ＮＡＬユニットの並びを説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 ＨＤＲビデオストリームのＭＰＥＧ−２ ＴＳ多重化例を説明する図である。 字幕ストリームの構造を示す図である。 字幕の表示制御に使われるパラメーターの関係を示す図である。 管理情報と、その内容を説明する図である。 データベースファイルのデータ構造を示す図である。 ＨＤＲビデオストリームとその拡張ビデオストリームとの同期再生を説明する図である。 ＨＤＲビデオストリームとその拡張ビデオストリームとの同期再生を説明する図である。 ＨＤＲビデオストリームのデコーダモデルを説明する図である。 データベースファイルへの各ストリームの登録方法を示す図である。 プレーヤの再生処理のフロー図である。

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した技術に関して課題が生じることを見出した。その課題について、以下、詳細に説明する。

映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、「Ｓｔａｎｄａｒｄ Ｄｉｆｉｎｉｔｉｏｎ（ＳＤ）−ＤＶＤ」ともいう。）である。以下に従来のＤＶＤについて説明する。

図１は、ＳＤ−ＤＶＤの構造を示す図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられている。その論理アドレス空間には先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。

ファイルシステムとは、ＩＳＯ９６６０やＵｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ（ＵＤＦ）等の規格により定められたデータを管理する仕組みのことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。

日常使っているパーソナルコンピュータ（ＰＣ）の場合でも、Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅｓ（ＦＡＴ）またはＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＮＴＦＳ）と呼ばれるファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。

ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０の両方のファイルシステムが使用されている。両方を合わせて「ＵＤＦブリッジ」とも呼ばれる。記録されているデータはＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。なお、ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である。

ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図１における「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下の種類のファイルがある。

ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
.....

上記例に示すように２つの拡張子が規定されている。「ＩＦＯ」は再生制御情報が記録されたファイルであることを示す拡張子であり、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルであることを示す拡張子である。

再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのような、ＡＶデータに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。

再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。なお、ＤＶＤでは複数のタイトル、言い換えれば複数の異なる映画や楽曲を１枚のディスクに記録することが可能である。

ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。

図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＩＤＥＯ Ｍａｎａｇｅｒ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＭＧＩ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶｉｄｅｏ Ｔｉｔｌｅ Ｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＴＳＩ）としてＤＶＤナビゲーション空間に展開される。

ＶＴＳＩの中にはＰｒｏｇｒａｍ Ｃｈａｉｎ（ＰＧＣ）と呼ばれる再生シーケンスの情報であるＰｒｏｇｒａｍ Ｃｈａｉｎ Ｉｎｆｏｒｍａｔｉｏｎ（ＰＧＣＩ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。

Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間を指定する情報であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。

コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、例えば、ウェブページを表示するブラウザ上で実行されるＪａｖａ（登録商標）Ｓｃｒｉｐｔなどに近いものである。しかしながらＪａｖａ（登録商標）Ｓｃｒｉｐｔが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドウを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプターの指定などを実行するだけのものである点で異なっている。

Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。

図２は、ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。

ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫという。）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。

ここでは簡単なインタラクティビティの例としてメニュー画面について説明する。メニュー画面上には、幾つかのボタンが現れ、それぞれのボタンには当該ボタンが選択実行された時の処理が定義されている。

また、メニュー画面上では一つのボタンが選択されており（選択ボタン上に半透明色がオーバーレイされることで該ボタンがハイライトされ、該ボタンが選択状態であることをユーザに示す）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。

リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプターの再生がコマンドによって実行されている。

図２の左上部はＮＶ＿ＰＣＫに格納される情報の概要を示している。ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。

ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作それぞれに対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）とが記述されている。

メニュー画面上のハイライトは、図２の右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色を付した物である。このオーバーレイ画像は図２の右部に示す背景画像と合成されて画面上に表示される。

前述のようにして、ＤＶＤではメニュー画面を実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのかについては、以下の理由からである。

すなわち、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニュー画面を表示するといった、同期タイミングが問題となりやすい処理を問題なく実現できるようにするためである。

また、もう一つの大きな理由は、ＮＶ＿ＰＣＫには特殊再生を支援するための情報を格納し、ＤＶＤ再生時の早送り、巻き戻しなどの非通常再生時にも円滑にＡＶデータをデコードし再生させる等、ユーザの操作性を向上させるためである。

図３は、ＤＶＤにおけるＶＯＢの構成を示す概要図である。図に示すように、映像、音声、字幕などのデータ（図３の（１））は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（図３の（２））、それぞれを多重化して１本のＭＰＥＧプログラムストリームにしている（図３の（３））。

また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。

ＭＰＥＧシステムの多重化の特徴として、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではないことが挙げられる。

これはＭＰＥＧシステムストリームのデコーダモデル（図３の（４）、一般にＳｙｓｔｅｍ Ｔａｒｇｅｔ Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる）が多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。

このデコーダバッファは、個々のエレメンタリストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢをそれぞれ有している。

このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。

即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。

ここで、ブルーレイディスク（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）のような大容量記録メディアにおいては、非常に高品位な映像情報を格納できる可能性がある。なお、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃは、ＢＤまたはＢＤ−ＲＯＭとも称される。

例えば、４Ｋ（３８４０ｘ２１６０ピクセルの解像度を持つ映像情報）またはＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅと一般に呼ばれる高輝度映像情報）などの映像情報をＢＤに格納することができると考えられる。なお、従来の標準輝度映像情報は、ＳＤＲ（Ｓｔａｎｄａｒｄ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）と一般に呼ばれる。

ここで、ＨＤＲ対応のテレビと、ＨＤＲに非対応（ＳＤＲのみに対応）のテレビとの両方でコンテンツを再生するために、ＨＤＲとＳＤＲとが両方記録されるＢＤがある。このようなＢＤにおいては、ビデオストリームの選択などの再生制御を簡素化することが課題である。

本発明者は、上記課題を解決するために、下記の改善策を検討した。

本発明の一態様に係る記録媒体は、再生環境に応じて選択的に用いられる、標準輝度範囲のビデオストリーム及び前記標準輝度範囲よりも輝度範囲の広い高輝度範囲のビデオストリームと、前記再生環境に応じて選択的に用いられる、前記標準輝度範囲の字幕ストリーム及び前記高輝度範囲の字幕ストリームと、コンテンツの再生制御情報が格納されるプレイリストファイルであって、メインストリームに関する前記再生制御情報が格納される管理領域、及び、拡張領域を含むプレイリストファイルとが記録され、前記管理領域には、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、前記拡張領域には、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される。

このような構成の記録媒体を再生する再生装置は、高輝度範囲のビデオストリームを選択して再生する場合には、管理領域に格納された第一再生制御情報を読み出せばよい。一方、再生装置は、標準輝度範囲のビデオストリームを選択して再生する場合には、拡張領域に格納された第二再生制御情報を読み出せばよい。これにより、再生装置は、高輝度範囲のビデオストリームとほぼ同様の処理で標準輝度範囲のビデオストリームの再生を行うことができる。

また、高輝度範囲のビデオストリームには、高輝度範囲の字幕ストリームが組み合わされているため、ＨＤＲビデオストリームにＳＤＲ字幕ストリームが組み合わされるといったことが生じない。

このように、上記記録媒体によれば、ビデオストリームの選択などの再生制御が簡素化される。上記記録媒体によれば、当該記録媒体を再生する再生装置の、ビデオストリーム選択処理及び再生処理を容易にすることができる。

また、前記第二再生制御情報の一部は、前記第一再生制御情報と共通のデータ構造を有してもよい。

これにより、再生装置は、高輝度範囲のビデオストリームとほぼ同様の処理で標準輝度範囲のビデオストリームの再生を行うことができる。また、システムのオーサリングが容易であるという利点、及び、プレーヤの実装／動作検証が容易である（コストを削減できる）という利点がある。

また、前記記録媒体には、さらに、ビデオストリームに含まれる独立して復号可能なピクチャの位置を示すマップ情報が格納されるマップ領域及び拡張マップ領域を含む、管理情報ファイルが記録され、前記マップ領域には、前記高輝度範囲のビデオストリームに含まれる独立して復号可能なピクチャの前記高輝度範囲のビデオストリーム内の位置を示す第一マップ情報が格納され、前記拡張マップ領域には、前記標準輝度範囲のビデオストリームに含まれる独立して復号可能なピクチャの前記標準輝度範囲のビデオストリーム内の位置を示す第二マップ情報が格納されてもよい。

このような構成の記録媒体を再生する再生装置は、高輝度範囲のビデオストリームを選択してランダムアクセス再生等を行うときには、マップ領域内の第一マップ情報を読み出せばよく、ＳＤＲビデオストリームを選択してランダムアクセス再生等を行うときには、拡張マップ領域内の第二マップ情報を読み出せばよい。つまり、このようなＢＤによれば、当該ＢＤを再生する再生装置の、ビデオストリーム選択処理及び再生処理を、ランダムアクセス再生（特殊再生）等を行う場合においても容易にすることができる。

また、前記記録媒体には、さらに、前記メインストリームのファイルと同時に再生されるサブストリームに関する前記再生制御情報が格納されるサブプレイリストファイルが記録され、前記サブプレイリストファイルには、前記高輝度範囲のビデオストリームの輝度範囲を拡張するための拡張ビデオストリームに関する第三再生制御情報が格納されてもよい。

このような構成の記録媒体を再生する再生装置は、管理領域内の第一制御情報とサブプレイリスト内の第三制御情報とを読み出すことにより、高輝度範囲のビデオストリームと拡張ストリームとを同時に再生することができる。つまり、このようなＢＤによれば、当該ＢＤを再生するプレーヤの、高輝度範囲のビデオストリームの拡張処理を容易にすることができる。

また、前記記録媒体には、さらに、前記メインストリームのファイルと同時に再生されるサブストリームに関する前記再生制御情報が格納されるサブプレイリストファイルが記録され、前記サブプレイリストファイルには、前記高輝度範囲のビデオストリームの輝度範囲を拡張するための拡張ビデオストリームに関する第三再生制御情報が格納され、前記マップ領域には、前記第一マップ情報と、前記拡張ビデオストリームに含まれる独立して復号可能なピクチャの前記拡張ビデオストリーム内の位置を示す第三マップ情報が格納されてもよい。

このような構成の記録媒体を再生する再生装置は、管理領域内の第一制御情報とサブプレイリスト内の第三制御情報とを読み出すことにより、高輝度範囲のビデオストリームと拡張ストリームとを同時に再生することができる。つまり、このようなＢＤによれば、当該ＢＤを再生する再生装置の、高輝度範囲のビデオストリームの拡張処理を容易にすることができる。

また、再生装置は、ランダムアクセス再生等を行うときには、マップ領域内の情報のみをさらに読み出せばよい。つまり、このようなＢＤによれば、高輝度範囲のビデオストリームを拡張し、かつ、ランダムアクセス再生等を行う場合において、当該ＢＤを再生する再生装置の再生処理を容易にすることができる。

本発明の一態様に係る再生方法は、記録媒体からコンテンツを読み出して再生する再生方法であって、前記記録媒体には、再生環境に応じて選択的に用いられる、標準輝度範囲のビデオストリーム及び前記標準輝度範囲よりも輝度範囲の広い高輝度範囲のビデオストリームと、前記再生環境に応じて選択的に用いられる、前記標準輝度範囲の字幕ストリーム及び前記高輝度範囲の字幕ストリームと、前記コンテンツの再生制御情報が格納されるプレイリストファイルであって、メインストリームに関する前記再生制御情報が格納される管理領域、及び、拡張領域を含むプレイリストファイルとが記録され、前記管理領域には、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、前記拡張領域には、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納され、前記再生方法は、前記コンテンツを前記高輝度範囲のコンテンツとして再生する場合には、前記第一再生制御情報に基づいて、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを読み出して再生し、前記コンテンツを前記標準輝度範囲のコンテンツとして再生する場合には、前記第二再生制御情報に基づいて、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを読み出して再生する。

また、前記第二再生制御情報の一部は、前記第一再生制御情報と共通のデータ構造を有してもよい。

また、前記記録媒体には、さらに、ビデオストリームに含まれる独立して復号可能なピクチャの位置を示すマップ情報が格納されるマップ領域及び拡張マップ領域を含む、管理情報ファイルが記録され、前記マップ領域には、前記高輝度範囲のビデオストリームに含まれる独立して復号可能なピクチャの前記高輝度範囲のビデオストリーム内の位置を示す第一マップ情報が格納され、前記拡張マップ領域には、前記標準輝度範囲のビデオストリームに含まれる独立して復号可能なピクチャの前記標準輝度範囲のビデオストリーム内の位置を示す第二マップ情報が格納され、前記再生方法は、前記コンテンツを前記高輝度範囲のコンテンツとして再生する場合には、前記第一再生制御情報及び前記第一マップ情報に基づいて、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを読み出して再生し、前記コンテンツを前記標準輝度範囲のコンテンツとして再生する場合には、前記第二再生制御情報及び前記第二マップ情報に基づいて、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを読み出して再生してもよい。

また、前記記録媒体には、さらに、前記メインストリームのファイルと同時に再生されるサブストリームに関する前記再生制御情報が格納されるサブプレイリストファイルが記録され、前記サブプレイリストファイルには、前記高輝度範囲のビデオストリームの輝度範囲を拡張するための拡張ビデオストリームに関する第三再生制御情報が格納され、前記再生方法は、前記コンテンツを前記高輝度範囲よりも拡張された輝度範囲のコンテンツとして再生する場合、前記第一再生制御情報に基づいて、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを読み出して再生し、かつ、前記第三再生制御情報に基づいて、前記拡張ビデオストリームを読み出して再生してもよい。

また、前記記録媒体には、さらに、前記メインストリームのファイルと同時に再生されるサブストリームに関する前記再生制御情報が格納されるサブプレイリストファイルが記録され、前記サブプレイリストファイルには、前記高輝度範囲のビデオストリームの輝度範囲を拡張するための拡張ビデオストリームに関する第三再生制御情報が格納され、前記マップ領域には、前記第一マップ情報と、前記拡張ビデオストリームに含まれる独立して復号可能なピクチャの前記拡張ビデオストリーム内の位置を示す第三マップ情報が格納され、前記再生方法は、前記コンテンツを前記高輝度範囲よりも拡張された輝度範囲のコンテンツとして再生する場合、前記第一再生制御情報及び前記第一マップ情報に基づいて、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを読み出して再生し、かつ、前記第三再生制御情報及び前記第三マップ情報に基づいて、前記拡張ビデオストリームを読み出して再生してもよい。

本発明の一態様に係る再生装置は、記録媒体からコンテンツを読み出して再生する再生装置であって、前記記録媒体には、再生環境に応じて選択的に用いられる、標準輝度範囲のビデオストリーム及び前記標準輝度範囲よりも輝度範囲の広い高輝度範囲のビデオストリームと、前記再生環境に応じて選択的に用いられる、前記標準輝度範囲の字幕ストリーム及び前記高輝度範囲の字幕ストリームと、前記コンテンツの再生制御情報が格納されるプレイリストファイルであって、メインストリームに関する前記再生制御情報が格納される管理領域、及び、拡張領域を含むプレイリストファイルとが記録され、前記管理領域には、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、前記拡張領域には、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納され、（１）前記コンテンツを前記高輝度範囲のコンテンツとして再生する場合には、前記第一再生制御情報に基づいて、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを読み出して再生し、（２）前記コンテンツを前記標準輝度範囲のコンテンツとして再生する場合には、前記第二再生制御情報に基づいて、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを読み出して再生する、映像再生部を備える。

なお、これらの全般包括的または具体的な態様は、装置、方法、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。

なお、本願請求項１に係る発明に最も近い実施の形態は実施の形態２であるが、理解を容易にするために、実施の形態２における情報記録媒体等の基本的な構成を説明する実施の形態１を先に説明する。

（実施の形態１）
まず、ＢＤ−ＲＯＭおよびＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成および動作について、図１〜図３０を用いて説明する。

（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭのデータ階層を示す図である。

図４に示すように、ディスク媒体であるＢＤ−ＲＯＭ１０４上には、ＡＶデータ１０３と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報１０２と、インタラクティブを実現するＢＤ再生プログラム１０１とが記録されている。

なお、本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてＢＤ−ＲＯＭの説明を行うが、ＢＤ−ＲＯＭをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体として使用することも当然のことながら可能である。

図５は、前述のＢＤ−ＲＯＭ１０４に記録されている論理データの構造を示す図である。ＢＤ−ＲＯＭ１０４は、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有している。

また、リードインの内側にはＢｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ（ＢＣＡ）と呼ばれる、ドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。

論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０等の規格により定められたデータを管理する仕組みのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。

本実施の形態の場合、ＢＤ−ＲＯＭ１０４上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶデータや管理情報などのデータ（図４に示すＢＤ再生プログラム１０１、ＢＤ管理情報１０２、ＡＶデータ１０３）が記録されているディレクトリである。

ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。

ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤ−ＲＯＭ全体に関する情報を記録したファイルである。ＢＤ−ＲＯＭプレーヤは最初にこのファイルを読み出す。

ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤ−ＲＯＭ全体に関わるプログラムを記録したファイルである。

ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。

ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＲＯＧ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。

ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。１つのＶＯＢは１つのファイルに対応する。

ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。

ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニュー画面を構成するためのイメージデータであるＰＮＧ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって標準化された画像フォーマットであり「ピング」と読む。）形式のイメージファイルである。１つのＰＮＧイメージは１つのファイルに対応する。

（プレーヤの構成）
次に、前述のＢＤ−ＲＯＭ１０４を再生するプレーヤの構成について図６及び図７を用いて説明する。

図６は、ＢＤ−ＲＯＭ１０４を再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。

図６に示すＢＤ−ＲＯＭプレーヤにおいて、ＢＤ−ＲＯＭ１０４上のデータは、光ピックアップ２０２を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。

ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイル）はプログラム記録メモリ２０３に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」ファイル）は管理情報記録メモリ２０４に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」ファイル）はＡＶ記録メモリ２０５にそれぞれ記録される。

プログラム記録メモリ２０３に記録されたＢＤ再生プログラムはプログラム処理部２０６によって処理される。管理情報記録メモリ２０４に記録されたＢＤ管理情報は管理情報処理部２０７によって処理される。

また、ＡＶ記録メモリ２０５に記録されたＡＶデータはプレゼンテーション処理部２０８によって処理される。

プログラム処理部２０６は、管理情報処理部２０７から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで、再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部２０７に対して変更後のプレイリストの再生命令を送ることで実現する。

プログラム処理部２０６は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコンからのリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。

管理情報処理部２０７は、プログラム処理部２０６の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応したＶＯＢの管理情報を解析する。更に、プレゼンテーション処理部２０８に再生の対象となるＡＶデータの再生を指示する。

また、管理情報処理部２０７は、プレゼンテーション処理部２０８から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部２０８にＡＶデータ再生の停止指示を行う。更に、プログラム処理部２０６に対してプログラム実行タイミングを示すイベントを生成する。

プレゼンテーション処理部２０８は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部２０７からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。

具体的には、映像データはビデオプレーン２１０に描画され、字幕データ等のイメージデータはイメージプレーン２０９に描画される。更に、２つのプレーンに描画された映像の合成処理が合成処理部２１１によって行われＴＶなどの表示デバイスへ出力される。

図６で示すように、ＢＤ−ＲＯＭプレーヤは図４で示したＢＤ−ＲＯＭ１０４に記録されているデータ構造に基づいた構成をとっている。

図７は、図６に示すプレーヤの構成を詳細化したブロック図である。図６に示す各構成部と、図７に示す各構成部との対応は以下の通りである。

ＡＶ記録メモリ２０５はイメージメモリ３０８とトラックバッファ３０９に対応する。プログラム処理部２０６はプログラムプロセッサ３０２とＵＯ（Ｕｓｅｒ Ｏｐｅｒａｔｉｏｎ）マネージャ３０３に対応する。管理情報処理部２０７はシナリオプロセッサ３０５とプレゼンテーションコントローラ３０６とに対応する。プレゼンテーション処理部２０８はクロック３０７、デマルチプレクサ３１０、イメージプロセッサ３１１、ビデオプロセッサ３１２とサウンドプロセッサ３１３とに対応する。

ＢＤ−ＲＯＭ１０４から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ３０９に、イメージデータ（ＰＮＧ）はイメージメモリ３０８にそれぞれ記録される。

デマルチプレクサ３１０は、クロック３０７から得られる時刻に基づき、トラックバッファ３０９に記録されたＶＯＢデータを抜き出す。更に、ＶＯＢデータに含まれる映像データをビデオプロセッサ３１２に音声データをサウンドプロセッサ３１３にそれぞれ送り込む。

ビデオプロセッサ３１２及びサウンドプロセッサ３１３はそれぞれＭＰＥＧシステム規格で定められる通りに、デコーダバッファとデコーダからそれぞれ構成されている。即ち、デマルチプレクサ３１０から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック３０７に従い個々のデコーダでデコード処理される。

イメージメモリ３０８に記録されたＰＮＧデータは、次の２つの処理方法がある。ＰＮＧデータが字幕用の場合は、プレゼンテーションコントローラ３０６によってデコードタイミングが指示される。クロック３０７からの時刻情報をシナリオプロセッサ３０５が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ３０６に対して字幕の表示、非表示の指示を出す。

プレゼンテーションコントローラ３０６からデコード／表示の指示を受けたイメージプロセッサ３１１は対応するＰＮＧデータをイメージメモリ３０８から抜き出し、デコードし、イメージプレーン２０９に描画する。

また、ＰＮＧデータがメニュー画面用の場合は、プログラムプロセッサ３０２によってデコードタイミングが指示される。プログラムプロセッサ３０２がいつイメージのデコードを指示するかは、プログラムプロセッサ３０２が処理しているＢＤプログラムに因るものであって一概には決まらない。

イメージデータ及び映像データは、図６で説明したようにそれぞれデコード後にイメージプレーン２０９およびビデオプレーン２１０に描画され、合成処理部２１１によって合成出力される。

ＢＤ−ＲＯＭ１０４から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ２０４に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ３０５によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ３０６によって読み出され処理される。

シナリオプロセッサ３０５は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ３０６に指示し、プレゼンテーションコントローラ３０６は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ３１７に指示を出す。

ドライブコントローラ３１７はプレゼンテーションコントローラ３０６の指示に従い、光ピックアップ２０２を移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ３０８またはトラックバッファ３０９に記録される。

また、シナリオプロセッサ３０５は、クロック３０７の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ３０２に投げる。

プログラム記録メモリ２０３に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ３０２がＢＤプログラムを処理するのは、シナリオプロセッサ３０５からイベントが送られてきた場合か、ＵＯマネージャ３０３からイベントが送られてきた場合である。

ＵＯマネージャ３０３は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ３０２に送る。

このような各構成部の動作により、ＢＤ−ＲＯＭの再生がおこなわれる。

（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。

ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。

プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。

一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーヤの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の１つである。

また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。

時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ３０５からプログラムプロセッサ３０２に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ３０２はＩＤによって対応付けられるイベントハンドラを実行処理する。

前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。

ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。

メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ３０２は、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。

二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。

グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行することができる。

プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図１４を用いて後述する。

（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。図９に示すように、ＶＯＢは複数のＶｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ（ＶＯＢＵ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームにおけるＧｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）を基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。

ＶＯＢＵは０．４秒から１．０秒の再生時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）であることによって導かれるものである。

ＶＯＢＵは、その内部に映像データであるビデオパック（Ｖ＿ＰＣＫ）と、音声データであるオーディオパック（Ａ＿ＰＣＫ）とを有している。各パックは１セクタで構成され、本実施の形態の場合は２ｋＢ単位で構成されている。

図１０は、ＭＰＥＧストリームにおけるパックの構成を示す図である。

図１０に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。

パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのか、映像データであるのか音声データであるのか、および、映像データまたは音声データがそれぞれ複数ストリーム分ある場合に、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）、並びに、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプであるＤｅｃｏｄｅ Ｔｉｍｅ Ｓｔａｍｐ（ＤＴＳ）及びＰｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ（ＰＴＳ）が記録されている。

ＤＴＳおよびＰＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。

パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサ３１０を通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプであるＳｙｓｔｅｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ（ＳＣＲ）が記録されている。

（ＶＯＢのインターリーブ記録）
図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。

図１１は、ＡＶデータとＢＤ−ＲＯＭプレーヤの構成との関係を説明するための図である。

図１１上段の図は、図７を用いて前述したプレーヤ構成図の一部である。図の通り、ＢＤ−ＲＯＭ上のデータは、光ピックアップ２０２を通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファ３０９へ入力され、ＰＮＧ即ちイメージデータであればイメージメモリ３０８へと入力される。

トラックバッファ３０９はＦｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ（ＦＩＦＯ）であり、入力されたＶＯＢのデータは入力された順にデマルチプレクサ３１０へと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファ３０９から引き抜かれデマルチプレクサ３１０を介してビデオプロセッサ３１２またはサウンドプロセッサ３１３へとデータが送り届けられる。

一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ３０６（図７参照）によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ３０８から削除されるが、メニュー用のイメージデータの場合は、イメージメモリ３０８内にそのまま残される。

これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。

図１１下段の図は、ＢＤ−ＲＯＭ上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。

一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。

しかしながら、連続再生すべきＡＶデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。

ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤ−ＲＯＭから読み出す事が必要になる。

字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。

そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、ＶＯＢファイルとイメージデータとをインターリーブ記録する方式を使用する。

図１１下段はそのインターリーブ記録を説明するための図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリ３０８に格納することが可能になる。

しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。

図１２は、上記のインターリーブ記録における問題を解決するトラックバッファ３０９を使ったＶＯＢデータ連続供給モデルを説明するための図である。

既に説明したように、ＶＯＢのデータは、一旦トラックバッファ３０９に蓄積される。トラックバッファ３０９へのデータ入力レートをトラックバッファ３０９からのデータ出力レートより高く設定すると、ＢＤ−ＲＯＭからデータを読み出し続けている限り、トラックバッファ３０９のデータ蓄積量は増加をしていくことになる。

ここでトラックバッファ３０９への入力レートをＶａ、トラックバッファ３０９からの出力レートをＶｂとする。図１２の上段の図に示すようにＶＯＢの一連続記録領域が論理アドレスの“ａ１”から“ａ２”まで続くとする。また、“ａ２”から“ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。

図１２の下段の図は、トラックバッファ３０９の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ３０９内部に蓄積されているデータ量を示している。時刻“ｔ１”がＶＯＢの一連続記録領域の開始点である“ａ１”の読み出しを開始した時刻を示している。

この時刻以降、トラックバッファ３０９にはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファ３０９の入出力レートの差である。時刻“ｔ２”は一連続記録領域の終了点である“ａ２”のデータを読み込む時刻である。

即ち時刻“ｔ１”から“ｔ２”の間レートＶａ−Ｖｂでトラックバッファ３０９内はデータ量が増加していき、時刻“ｔ２”でのデータ蓄積量Ｂ（ｔ２）は下記の（式１）によって求めることができる。

Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）

この後、ＢＤ−ＲＯＭ上のアドレス“ａ３”まではイメージデータが続くため、トラックバッファ３０９への入力は０となり、出力レートである“−Ｖｂ”でトラックバッファ３０９内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置“ａ３”まで、つまり、時刻でいう“ｔ３”まで続く。

ここで大事なことは、時刻“ｔ３”より前にトラックバッファ３０９に蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまうことである。

しかしながら、時刻“ｔ３”でトラックバッファ３０９にデータが残っている場合には、ＶＯＢの再生がストップすることなく連続して行われることを意味している。

このＶＯＢの再生がストップすることなく連続して行われるための条件は下記の（式２）によって示すことができる。

Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）

即ち、（式２）を満たすようにイメージデータの配置を決めればよい事になる。

（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭに記録されたナビゲーションデータ（ＢＤ管理情報）の構造について説明をする。

図１３は、ＶＯＢ管理情報ファイル（“ＹＹＹ．ＶＯＢＩ”）の内部構造を示す図である。

ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）とを有している。ストリーム属性情報は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、オーディオ属性のデータフィールドの数が特定される。

下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドとそれぞれが持ち得る値の例である。

圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）：
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）：
６０
５９．９４
５０
３０
２９．９７
２５
２４

下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドとそれぞれが持ち得る値の例である。

圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
ＪＰＮ、ＥＮＧ、・・・

タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。

個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）とを有している。

図１４は、ＶＯＢＵ情報の詳細を説明するための図である。

広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つの物理量についての側面を有している。例えば、音声の圧縮規格であるＡｕｄｉｏ Ｃｏｄｅ ｎｕｍｂｅｒ ３（ＡＣ３）は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。

しかしながらＭＰＥＧビデオデータの場合、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合、１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。

従って、ＭＰＥＧビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。

当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧストリーム、即ちＶＯＢについても、時間とデータとを一般式の形で表現することは不可能である。

これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数とをそれぞれエントリとして持つテーブルがタイムマップ（ＴＭＡＰ）である。

図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。

図１５は、タイムマップを使ったアドレス情報取得方法を説明するための図である。

図１５に示すように時刻情報（Ｔｉｍｅ）が与えられた場合、まずは当該時刻がどのＶＯＢＵに属するのかを検索する。具体的には、タイムマップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致するＶＯＢＵが当該時刻に対応するＶＯＢＵになる。

次に、タイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレス（Ａｄｄｒｅｓｓ）になっている。

このようにして、ＭＰＥＧストリームにおいて、与えられた時刻情報に対応するアドレスを得ることができる。

次に図１６を使って、プレイリスト（“ＸＸＸ．ＰＬ”）の内部構造を説明する。

図１６は、プレイリストの構成を示す図である。

プレイリストは、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。

セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。

セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。

各セル情報（Ｃｅｌｌ＃〜Ｃｅｌｌ＃ｎ）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。

有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、それぞれ当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。

字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）とから構成されている。

各言語のテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）は、言語情報（Ｌａｎｇｕａｇｅ）と、表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）とから構成され、各字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）とから構成されている。

イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成され、各イベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）とから構成されている。

図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（“ＸＸＸ．ＰＲＯＧ”）の構成を示す図である。

イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。

各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ｅｖｅｎｔ＿ｈａｎｄｌｅｒ ｉｄ）を持ち、その後に当該プログラムが“ｆｕｎｃｔｉｏｎ”に続く括弧“｛”と“｝”との間に記述される。

次に図１８を用いてＢＤ−ＲＯＭ全体に関する情報（“ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。

図１８は、ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。

ＢＤ−ＲＯＭ全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。

タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）とから構成されている。

各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）とを含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。

チャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプター数（Ｎｕｍｂｅｒ）と各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）とから構成され、各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）は当該チャプターが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と各セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）とから構成されている。

セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。

イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤ−ＲＯＭがプレーヤに挿入された時、最初に実行されるイベントである。

各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。

図１９は、グローバルイベントハンドラテーブル（“ＢＤ．ＰＲＯＧ”）の構成を示す図である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。

（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。

図２０は、タイムイベントの例を示す図である。

前述したとおり、タイムイベントはプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。

タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、ＩＤ“Ｅｘ１”を持つタイムイベントがシナリオプロセッサ３０５からプログラムプロセッサ３０２に対して出力される。

プログラムプロセッサ３０２は、イベントＩＤ“Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うことなどが可能である。

図２１は、ユーザのメニュー操作によるユーザイベントの例を示す図である。

前述したとおり、メニュー操作によるユーザイベントもプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。

ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。

当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間（“Ｔ１”）レディ状態にある。

図２１に示すように、ユーザによりリモコンキーの「上」「下」「左」「右」キーのいずれかのキー、または「決定」キーが押された場合、まずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。

プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流し、シナリオプロセッサ３０５はＵＯイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。

シナリオプロセッサ３０５は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ３０２に出力する。

プログラムプロセッサ３０２では、イベントＩＤ、例えば、図２１に示す例の場合では“Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト＃２の再生を開始する。

生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯイベントによってプログラムプロセッサ３０２に伝えられ、仮想プレーヤが持つレジスタに記録保持される。

イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。

図２２は、グローバルイベントの例を示す図である。

前述のように、グローバルイベントはＢＤ−ＲＯＭ全体情報（“ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。

グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＧｌｏｂａｌＥｖｅｎｔ”であるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される。

ユーザによりメニューキーが押された場合、先ずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流す。

シナリオプロセッサ３０５は、該当するグローバルイベントを生成し、プログラムプロセッサ３０２に送る。プログラムプロセッサ３０２は、イベントＩＤ“ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、図２２に示す例の場合、プレイリスト＃３の再生を開始している。

本実施の形態では、単にメニューキーと呼んでいるが、ＤＶＤを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。

（仮想プレーヤマシン）
図２３は、プログラムプロセッサ３０２の機能的な構成を説明するための図である。

図２３を用いてプログラムプロセッサ３０２の機能的な構成を説明する。

プログラムプロセッサ３０２は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行できることを保証している。

仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数である。プレーヤ変数はレジスタに記憶され保持されている。

プログラミング関数は、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔをベースとして、以下に記す３つの機能をＢＤ−ＲＯＭ固有関数として定義している。

リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する。

Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーン２０９に描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーン２０９の指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅

また、プレーヤ変数は、プレーヤの設定値等を示すシステムパラメータ（ＳＰＲＭ）と、一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。

図２４は、システムパラメータ（ＳＰＲＭ）の一覧を示す図である。

ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプター番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備

なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標）
Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であってもよい。言い換えれば、本発明におけるプログラム言語はＪａｖａ（登録商標） Ｓｃｒｉｐｔに限定されるものでは無い。

（プログラムの例）
図２５及び図２６は、イベントハンドラにおけるプログラムの例を示す図である。

図２５は、２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。

セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に“１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン［１］が選択されている状態を初期値として持たされている。

次に、ＰＮＧの描画を描画関数である“Ｄｒａｗ”を使ってボタン［１］、ボタン［２］それぞれについて行っている。ボタン［１］は、座標（１０、２００）を起点（左上端）としてＰＮＧイメージ“１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン［２］は、座標（３３０，２００）を起点（左上端）としてＰＮＧイメージ“２ｗｈｉｔｅ．ｐｎｇ”を描画している。

また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。

図２６は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。

「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれている。ユーザによりリモコンキーが押された場合、図２１を用いて説明したように、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。

本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って以下のように分岐処理を行っている。

条件１）ボタン［１］が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右のボタン［２］に変更する。

ボタン［１］、ボタン［２］のイメージをそれぞれ書き換える。

条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン［１］が選択されている場合
プレイリスト＃２の再生を開始する。

条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン［２］が選択されている場合
プレイリスト＃３の再生を開始する。

図２６に示すプログラムは、上記のように解釈され実行される。

（プレーヤ処理フロー）
図２７から図３０を用いてプレーヤでの処理の流れを説明する。

図２７は、ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフロー図である。

ＢＤ−ＲＯＭが挿入されると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤは“ＢＤ．ＩＮＦＯ”の読み込みと解析（Ｓ１０２）、および、“ＢＤ．ＰＲＯＧ”の読み込み（Ｓ１０３）を実行する。“ＢＤ．ＩＮＦＯ”及び“ＢＤ．ＰＲＯＧ”は共に管理情報記録メモリ２０４に一旦格納され、シナリオプロセッサ３０５によって解析される。

続いて、シナリオプロセッサ３０５は、“ＢＤ．ＩＮＦＯ”ファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサ３０２で受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。

ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる（Ｓ２０１でＮｏ）。

ＵＯマネージャ３０３は、ユーザからのリモコン操作を受け付けると（Ｓ２０１でＹｅｓ）、プログラムプロセッサ３０２に対するＵＯイベントを生成する（Ｓ２０２）。

プログラムプロセッサ３０２は、ＵＯイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合（Ｓ２０３でＹｅｓ）は、シナリオプロセッサ３０５にＵＯイベントを流し、シナリオプロセッサ３０５がユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサ３０２は生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。

図２８は、ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフロー図である。

前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサ３０５は、再生対象のプレイリスト再生に必要な情報として、プレイリスト“ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、および、プレイリストに対応するプログラム情報“ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。

続いてシナリオプロセッサ３０５は、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラ３０６に対して要求が出される事を意味し、プレゼンテーションコントローラ３０６はＡＶデータ再生を開始する（Ｓ３０５）。

ＡＶデータの再生が開始されると、プレゼンテーションコントローラ３０６は、再生するセルに対応するＶＯＢの情報ファイル“ＸＸＸ．ＶＯＢＩ”を読み込み（Ｓ４０２）、解析する。プレゼンテーションコントローラ３０６は、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラ３１７に読み出しアドレスを指示する。ドライブコントローラ３１７は対象となるＶＯＢデータ“ＹＹＹ．ＶＯＢ”を読み出す（Ｓ４０３）。

読み出されたＶＯＢデータはデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセルが存在する場合（Ｓ４０６でＹｅｓ）、Ｃｅｌｌの再生（Ｓ３０４）へ移行する。また、次のセルが無い場合（Ｓ４０６でＮｏ）は、再生に係る処理が終了する。

図２９は、ＡＶデータ再生開始後からのイベント処理の流れを示すフロー図である。

図２９の（Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。

なお、ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。

ＢＤ−ＲＯＭプレーヤにおいてプレイリスト再生の再生が開始されると（Ｓ５０１）、プレイリスト再生が終了していないことが確認され（Ｓ５０２でＮｏ）、シナリオプロセッサ３０５は、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。

タイムイベント発生時刻になっている場合（Ｓ５０３でＹｅｓ）には、シナリオプロセッサ３０５はタイムイベントを生成する（Ｓ５０４）。プログラムプロセッサ３０２はタイムイベントを受け取り、イベントハンドラを実行処理する（Ｓ５０５）。

また、タイムイベント発生時刻になっていない場合（Ｓ５０３でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ５０２）以降の処理を繰り返す。

また、プレイリスト再生が終了したことが確認されると（Ｓ５０２でＹｅｓ）、タイムイベント系の処理は強制的に終了する。

図２９の（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。

ＢＤ−ＲＯＭプレーヤにおいてプレイリストの再生が開始されると（Ｓ６０１）、プレイリスト再生が終了していないことが確認され（Ｓ６０２でＮｏ）、ＵＯマネージャ３０３は、ＵＯの受け付けがあったかを確認する。

ＵＯの受け付けがあった場合（Ｓ６０３でＹｅｓ）、ＵＯマネージャ３０３はＵＯイベントを生成する（Ｓ６０４）。プログラムプロセッサ３０２はＵＯイベントを受け取り、そのＵＯイベントがメニューコールであるかを確認する。

メニューコールであった場合（Ｓ６０５でＹｅｓ）、プログラムプロセッサ３０２はシナリオプロセッサ３０５にイベントを生成させ（Ｓ６０７）、プログラムプロセッサ３０２はイベントハンドラを実行処理する（Ｓ６０８）。

また、ＵＯイベントがメニューコールで無いと判断された場合（Ｓ６０５でＮｏ）、ＵＯイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ３０５が判断し、有効期間内である場合（Ｓ６０６でＹｅｓ）には、シナリオプロセッサ３０５がユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサ３０２が対象のイベントハンドラを実行処理する（Ｓ６０８）。

また、ＵＯ受付が無い場合（Ｓ６０３でＮｏ）、現在時刻がユーザイベント有効期間内にない場合（Ｓ６０６でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ６０２）以降の処理を繰り返す。

また、プレイリスト再生が終了したことが確認されると（Ｓ６０２でＹｅｓ）、ユーザイベント系の処理は強制的に終了する。

図３０は、ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフロー図である。

ＢＤ−ＲＯＭプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認され（Ｓ７０２でＮｏ）、シナリオプロセッサ３０５は、字幕表示開始時刻になったかを確認する。字幕表示開始時刻になっている場合（Ｓ７０３でＹｅｓ）、シナリオプロセッサ３０５はプレゼンテーションコントローラ３０６に字幕描画を指示し、プレゼンテーションコントローラ３０６はイメージプロセッサ３１１に字幕描画を指示する。イメージプロセッサ３１１は、その指示に従い字幕をイメージプレーン２０９に字幕を描画する（Ｓ７０４）。

また、字幕表示開始時刻になっていない場合（Ｓ７０３でＮｏ）、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合（Ｓ７０５でＹｅｓ）、プレゼンテーションコントローラ３０６がイメージプロセッサ３１１に字幕消去指示を行う。

イメージプロセッサ３１１は、その指示に従い描画されている字幕をイメージプレーン２０９から消去する（Ｓ７０６）。

また、イメージプロセッサ３１１による字幕描画（Ｓ７０４）が終了した場合、イメージプロセッサ３１１による字幕消去（Ｓ７０６）のが終了した場合、および、字幕表示終了時刻でないと判断（Ｓ７０５でＮｏ）された場合、プレイリスト再生の終了確認（Ｓ７０２）以降の処理を繰り返す。

また、プレイリスト再生が終了したことが確認されると（Ｓ７０２でＹｅｓ）、字幕表示系の処理は強制的に終了する。

以上の動作により、ＢＤ−ＲＯＭプレーヤは、ユーザの指示またはＢＤ−ＲＯＭに記録されているＢＤ管理情報等に基づき、ＢＤ−ＲＯＭの再生に係る基本的な処理を行う。

（実施の形態２）
次に本発明の実施の形態２について説明する。

実施の形態２は、ＢＤでの高輝度（ＨＤＲ：Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）映像情報の記録または再生に関する内容である。実施の形態２は、基本的には実施の形態１に基づくため、実施の形態２において拡張されている部分または異なる部分を中心に、以下、説明する。

図３１は、ＭＰＥＧ−４ ＡＶＣ（別名Ｈ．２６４）、もしくはＨＥＶＣ（別名Ｈ．２６５）のような映像符号化方式を用いて高輝度化メタデータを送る方法を説明する図である。ここでは、ＭＰＥＧ−２ Ｖｉｄｅｏでのランダムアクセス性を高めるために用いられたＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）と同等のピクチャ参照構成から成る単位を、ＭＰＥＧ−４ ＡＶＣ、もしくはＨＥＶＣでのＧＯＰとして、複数のピクチャをグループ化して符号化している。

図３１の（ａ）は、ＧＯＰ先頭のピクチャ（ｆｉｒｓｔ ａｃｃｅｓｓ ｕｎｉｔ）における複数のＮＡＬユニットの符号化順番を示している。ＧＯＰ先頭のピクチャでは、１つのＡＵ ｄｅｌｉｍｉｔｅｒ、１つのＳＰＳ、１つ以上のＰＰＳ、０個または複数のＳＥＩ ｍｅｓｓａｇｅ、ピクチャを構成する１つ以上のＳｌｉｃｅのそれぞれのＮＡＬユニットが続いた後、必要に応じてＦｉｌｌｅｒ ｄａｔａ、Ｅｎｄ ｏｆ ｓｅｑｕｅｎｃｅ、Ｅｎｄ ｏｆ ｓｔｒｅａｍのそれぞれのＮＡＬユニットが続く。

ＳＥＩ ｍｅｓｓａｇｅ（ＳＥＩ（ｓ））では、必要に応じて、Ｂｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄ ＳＥＩ ｍｅｓｓａｇｅに続けて、他の幾つかのＳＥＩ ｍｅｓｓａｇｅが続く。例えば、（１）このＧＯＰ内のピクチャの参照関係を示したＵｓｅｒ ｄａｔａ
ｕｎｒｅｇｉｓｔｅｒｅｄ ＳＥＩ ｍｅｓｓａｇｅ（ＧＯＰ）、（２）このピクチャのＣｌｏｓｅｄ Ｃａｐｔｉｏｎｉｎｇ情報を持つＵｓｅｒ ｄａｔａ ｕｎｒｅｇｉｓｔｅｒｅｄ ＳＥＩ ｍｅｓｓａｇｅ（ＣＣ）、（３）このビデオシーケンス（ＶＯＢ）内の全てのピクチャの中での最大輝度または最小輝度などの輝度範囲を示す基本的かつ静的な高輝度化メタデータを含むＵｓｅｒ ｄａｔａ ｕｎｒｅｇｉｓｔｅｒｅｄ ＳＥＩ
ｍｅｓｓａｇｅ（ＨＤＲｂ）、（４）このピクチャもしくはＧＯＰ内の全てのピクチャの中での最大輝度または最小輝度などの輝度範囲を示すように、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）よりも詳細で動的な高輝度化メタデータを含むＵｓｅｒ ｄａｔａ ｕｎｒｅｇｉｓｔｅｒｅｄ ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）、などの幾つかのＳＥＩ ｍｅｓｓａｇｅが、この順番で符号化されている。

上述のＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）またはＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）は、映像情報と一緒に伝送される。これは、マスタリングの際に利用された輝度に関する情報を伝送し、映像情報をデコードした後に得られる各ピクセルごとの輝度値（Ｙ）が、実際にはどの程度の明るさ（ｃｄ／ｍ＾２）に相当するのかなどの情報を与えるためである。

例えば、ビデオをデコードした結果、輝度値（Ｙ）が１０００の値を持つピクセルのマスタリング時の輝度は５０００ｃｄ／ｍ＾２だった、といったピクセルの持つ輝度とマスタリング時の輝度との相関情報などが、上述のＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）またはＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）に含まれる。また、プレーヤに接続したＴＶが表現できる最高輝度（ｃｄ／ｍ＾２）が取得された場合、ピクチャ全体の輝度方向のダイナミックレンジを変更するための情報を、上述のＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）またはＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）に持たせてもよい。

ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）は、ＨＤＲビデオシーケンスであることを示すためにピクチャ単位もしくはＧＯＰ単位で伝送されるＳＥＩ ｍｅｓｓａｇｅであり、ビデオシーケンス（ＶＯＢ）全体の静的な輝度に関する情報を伝送している。ここで言うＨＤＲビデオシーケンスとは、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）が記録されているビデオシーケンスのこととする。

より詳細でかつ動的な輝度に関する情報を伝送するＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）は、ＨＤＲビデオシーケンスに記録されている必要はなく、ＨＤＲビデオシーケンス中に１つも存在しなくてもよい。また、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）は、存在する場合には、必ずＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）の直後に符号化されるＳＥＩ ｍｅｓｓａｇｅであり、ピクチャ単位もしくはＧＯＰ単位で輝度に関する情報を伝送している。

図３１の（ｂ）は、ＧＯＰ先頭のピクチャではないピクチャ（ｎｏｎ−ｆｉｒｓｔ ａｃｃｅｓｓ ｕｎｉｔ）における複数のＮＡＬユニットの符号化順番を示している。ＧＯＰ先頭でないピクチャでは、１つのＡＵ ｄｅｌｉｍｉｔｅｒ、０個または１個のＰＰＳ、０個または複数のＳＥＩ ｍｅｓｓａｇｅ、ピクチャを構成する１つ以上のＳｌｉｃｅのそれぞれのＮＡＬユニットが続く。さらにその後に、必要に応じて、Ｆｉｌｌｅｒ ｄａｔａ、Ｅｎｄ ｏｆ ｓｅｑｕｅｎｃｅ、Ｅｎｄ ｏｆ ｓｔｒｅａｍのそれぞれのＮＡＬユニットが続く。

ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）またはＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）は、それぞれ上記の情報を格納しており、この図３１に示す方法では、ピクチャごとに付与されている。ＧＯＰ単位で輝度に関する情報を伝送する場合には、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）およびＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）はともにＧＯＰ先頭のピクチャのみに付与され、ＧＯＰ先頭でないピクチャには一切付与されない。

図３２は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する方法を説明する図である。なお、本実施の形態において、シーケンスは、ストリームと同義であってもよく、ストリームの一部であってもよい。１ピクチャ（１フレームまたは１ ｖｉｄｅｏ ａｃｃｅｓｓ ｕｎｉｔ）を１ＰＥＳパケットに格納して、ＨＤＲビデオストリームをＰＥＳ化した後、ＰＩＤ＝Ｘの各ＴＳパケットのペイロードに、ＰＥＳパケットにおけるデータが分割されて順番に格納される。

図３２に示す方法の場合、同じＰＩＤ（ＰＩＤ＝Ｘ）の各ＴＳパケットに、ｓｔｒｅａｍ＿ｉｄ＝０ｘＥ１のＰＥＳパケットとされる、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオシーケンスが、分割されて順番に格納される。なお、ＨＤＭＩ（登録商標）でＨＤＲビデオシーケンスを出力する際に、図３２に示す方法のように、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の情報が伝送されると、ビデオシーケンス全体からＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を検索するための処理が重くなる場合がある。

図３３は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する別の方法を説明する図である。１ピクチャ（１フレームまたは１ ｖｉｄｅｏ ａｃｃｅｓｓ ｕｎｉｔ）を１ＰＥＳパケットに格納して、ＨＤＲビデオストリームをＰＥＳ化した後、ＰＩＤ＝ＸとＺのそれぞれのＴＳパケットのペイロードに、ＰＥＳパケットにおけるデータが分割されて順番に格納される。

図３３に示す方法の場合、ＰＩＤ＝ＸのＴＳパケットに、ｓｔｒｅａｍ＿ｉｄ＝０ｘＥ１のＰＥＳパケットとしてＨＤＲビデオシーケンスが格納され、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）のみがＰＩＤ＝ＺのＴＳパケットに単独で格納されている。ＨＤＭＩ（登録商標）でＨＤＲビデオを出力する際に、図３３に示す方法のように、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の情報が伝送されると、ＰＩＤ＝ＺのＴＳパケットにＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）のみが格納されている。したがって、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を検索するための処理は軽い。

ＰＩＤ＝ＸのＴＳパケットで伝送されるＨＤＲビデオシーケンスのみをデコードするのは簡単である。しかし、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）までを含んだ更に高輝度な映像再生を行うためには、ＰＩＤ＝ＸとＺのそれぞれのＴＳパケットを同一のＴＢバッファ（ＭＰＥＧ−２ ＳｙｓｔｅｍのＴ−ＳＴＤモデルにて使われる前段バッファ）に伝送する追加処理が必要となる。

図３４は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する別の方法を説明する図である。１ピクチャ（１フレームまたは１ ｖｉｄｅｏ ａｃｃｅｓｓ ｕｎｉｔ）を分割して３つのＰＥＳパケットのそれぞれに格納して、ビデオストリームをＰＥＳ化する。その後、３つのＰＥＳパケットのそれぞれは、必要に応じて分割され、ＰＩＤ＝Ｘの各ＴＳパケットのペイロードに順番に格納される。

図３４に示す方法の場合、ＰＩＤ＝ＸのＴＳパケットに、ｓｔｒｅａｍ＿ｉｄ＝０ｘＥ１の２つのＰＥＳパケットとしてＨＤＲビデオシーケンスが格納される。そして、ＳＥＩ
ｍｅｓｓａｇｅ（ＨＤＲｅ）のみが、同じｓｔｒｅａｍ＿ｉｄ＝０ｘＥ１ながらＰＥＳ＿ｐｒｉｏｒｉｔｙ＝０のＰＥＳパケットとして、同じＰＩＤ＝ＸのＴＳパケットに単独で格納されている。

ＨＤＭＩ（登録商標）でＨＤＲビデオを出力する際に、図３４に示す方法のように、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の情報が伝送されると、ＰＩＤ＝Ｘの各ＴＳパケットから、ｓｔｒｅａｍ＿ｉｄ＝０ｘＥ１でＰＥＳ＿ｐｒｉｏｒｉｔｙ＝０のＰＥＳパケットが検索される。したがって、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を検索するための処理は、図３３に示す方法のようには軽くはない。

しかし、ＰＩＤ＝ＸのＴＳパケットで伝送されるＨＤＲビデオシーケンスのみをデコードするのも、ＨＤＲビデオシーケンスだけでなくＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）も含めてデコードするのも大きな差異はなく、図３４に示す方法は実現可能である。

尚、ＰＥＳ＿ｐｒｉｏｒｉｔｙの値は必ずしもこの組み合わせでなくても良く、ＳＥＩ
ｍｅｓｓａｇｅ（ＨＤＲｅ）を格納するＰＥＳパケットだけがＰＥＳ＿ｐｒｉｏｒｉｔｙ＝１を取るようにしていても同様の効果を発揮することができる。

図３５は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する別の方法を説明する図である。図３４に示す方法との違いは、図３５に示す方法では、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を含むＰＥＳパケットを格納するＴＳパケットのｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙが０である点である。

ＨＤＭＩ（登録商標）でＨＤＲビデオを出力する際に、図３５に示す方法のように、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の情報が伝送されると、ＰＩＤ＝Ｘでｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙ＝０のＴＳパケットからＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）が解析される。したがって、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を検索するため処理量は、図３３に示す方法とほぼ同じように軽く、図３５に示す方法を実現することは可能である。

また、この場合には、ＨＤＲビデオシーケンスのみをデコードするのも、ＨＤＲビデオシーケンスだけでなくＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）も含めてデコードするのも、Ｔ−ＳＴＤモデル上では差異はなく、図３５に示す方法を実現することができる。例えば、ＴＳデコーダのＰＩＤデマルチプレクサは、ｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙの値にも基づいてストリームを分離する。これにより、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）には対応せず、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）までの情報を用いて高輝度化するデコーダは、上述のＰＩＤデマルチプレクサによって、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を含むＴＳパケットを容易に破棄することが可能である。

尚、ｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙの値は必ずしもこの組み合わせでなくても良く、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を格納するＴＳパケットだけがｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙ＝１を取るようにしていても同様の効果を発揮することができる。

図３６は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する別の方法を説明する図である。この図３６に示す方法では、図３３に示す方法のように、ＰＩＤを２種類使い、図３４または図３５に示す方法のように、ＰＥＳパケットを構成している。この図３６に示す方法は、図３３に示す方法と同じような利点と欠点を併せ持つ。

図３７は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）まで含むＨＤＲビデオストリームをＭＰＥＧ−２ ＴＳで多重化する別の方法を説明する図である。この図３７に示す方法では、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）を、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）などが格納されているＰＥＳパケットとは別のＰＥＳパケットである、ＰＥＳ＿ｐｒｉｏｒｉｔｙ＝０のＰＥＳパケットに格納する。そして、スライスＮＡＬユニットを格納し終わった後に、ＰＥＳ＿ｐｒｉｏｒｉｔｙ＝０のＰＥＳパケットを、ＰＩＤ＝ＸのＴＳパケットとは別のＰＩＤ＝ＺのＴＳパケットにて多重化している。ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の多重化位置はピクチャデータ直後となっている。したがって、図３７に示す方法では、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）までのＨＤＲビデオシーケンスが１つのＰＥＳパケットに格納されている。この点を除き、図３７に示す方法は、図３３に示す方法と同じような利点と欠点を併せ持つ。

図３８は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の代わりに、ＨＤＲビデオシーケンスとは別のビデオシーケンスである拡張ビデオシーケンスをＭＰＥＧ−２ ＴＳで多重化する方法を説明する図である。この図３８に示す方法では、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）で高輝度拡張メタデータを伝送するのではなく、拡張ビデオシーケンス（Ｅｎｈａｎｃｅｍｅｎｔ ｌａｙｅｒ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅ）を、ＨＤＲビデオシーケンス（Ｂａｓｅ ｌａｙｅｒ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅ ｗｉｔｈ ｕｓｅｒ ｄａｔａ ｕｎｒｅｇｉｓｔｅｒｅｄ ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ））に対する拡張映像情報として伝送する。

例えば、上記ＨＤＲビデオシーケンスに含まれるＢａｓｅ ｆｒａｍｅ ＰＥＳ＃ｎの基本ピクチャに対して、拡張ビデオシーケンスに含まれるＥｎｈａｎｃｅｍｅｎｔ ｆｒａｍｅ ＰＥＳ＃ｎの拡張ピクチャを加える。これにより、ＨＤＲビデオシーケンスの高輝度拡張を、ＳＥＩ ｍｅｓｓａｇｅよりも更に多くのデータを用いながら、より正確に行うことが可能になる。ここで、対応するピクチャ同士は同じＰＴＳを持つようにして、ピクチャ間の相関が示されていても良い。例えば、「基本ピクチャのＰＴＳ＃ｂ１」＝「拡張ピクチャのＰＴＳ＃ｅ１」を示す相関が示される。

上述の基本ビデオシーケンスと拡張ビデオシーケンスとは、夫々全く異なる２本のビデオシーケンスとして異なるＰＩＤで異なるＰＥＳパケットでＭＰＥＧ−２ ＴＳへ多重化される。

ＰＭＴパケットには、基本ビデオシーケンスと拡張ビデオシーケンスとのペアを正しく指定するために、ｄｅｓｃｒｉｐｔｏｒ（）を用いてそのペアを表現しても良い。例えば、この図３８に示す方法では、ＰＭＴパケットの中に、ＨＤＲ＿ｐａｉｒｉｎｇ＿ｄｅｓｃｒｉｐｔｏｒ（）が記述される。ＨＤＲ＿ｐａｉｒｉｎｇ＿ｄｅｓｃｒｉｐｔｏｒ（）には、このＭＰＥＧ−２ ＴＳ内のペア数（ｎｕｍｂｅｒ＿ｏｆ＿ＨＤＲ＿ｐａｉｒｓ）と、ペアごとの基本ビデオシーケンスと拡張ビデオシーケンスとが用いるＰＩＤ値とが含まれる。基本ビデオシーケンスが用いるＰＩＤ値は、ｂａｓｅ＿ｌａｙｅｒ＿ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ＿ＰＩＤによって示され、拡張ビデオシーケンスが用いるＰＩＤ値は、ｅｎｈａｎｃｅｍｅｎｔ＿ｌａｙｅｒ＿ｖｉｄｅｏ＿ｓｅｑｕｅｎｃｅ＿ＰＩＤによって示される。このようなＨＤＲ＿ｐａｉｒｉｎｇ＿ｄｅｓｃｒｉｐｔｏｒ（）が記述されることで、正しいペアの組み合わせを示すことができる。

図３９は、１つの表示単位を構成する字幕映像ストリームの構造を示している。１つの表示単位の字幕映像ストリームは、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔと呼ばれ、ＰＭデータで始まりＥＮＤで終わる構造である。以下個々のデータセグメントについて説明する。

ＰＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｍａｎａｇｅｒ）は必ず字幕映像ストリームの各Ｐｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔの先頭に配置されるデータセグメントであり、以下のデータフィールドを含む。

ｓｅｇ＿ｔｙｐｅはセグメントの種別を表しており、図３９に示すようにｓｅｇ＿ｔｙｐｅ＝０ｘ０１の場合であれば、それを含むデータセグメントがＰＭであることを示している。

ｐｒｅｓｅｎ＿ｓｅｔ＿ｓｔａｔｅはこのＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが字幕の１つの表示単位として字幕表示に必要なデータを全て含むタイプか、表示色のみを変更するような部分的な更新データだけを格納するタイプなのかを示している。

ｂｉｔｍａｐ＿ｉｄ＿ｒｅｆはこのＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが表示する字幕映像のビットマップの識別情報（ｂｉｔｍａｐ＿ｉｄ）を示している。

ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆはこのＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが利用する表示領域の識別情報（ｗｉｎｄｏｗ＿ｉｄ）を示している。

ｂｉｔｍａｐ＿ｐｏｓ＿ｘ及びｂｉｔｍａｐ＿ｐｏｓ＿ｙはｂｉｔｍａｐ＿ｉｄ＿ｒｅｆで指定されたビットマップの左上座標の位置を示している。

ｐａｌｅｔｔｅ＿ｉｄ＿ｒｅｆはこのＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが利用する表示色インデックスカラーテーブルの識別情報（ｐａｌｅｔｔｅ＿ｉｄ）を示している。

ｐａｌｅｔｔｅ＿ｕｐｄａｔｅ＿ｊｕｄｇｅはこのＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが表示色インデックスカラーテーブルのみを更新するタイプのＰｒｅｓｅｎｔａｔｉｏｎ
Ｓｅｔか否かを示している。ｐａｌｅｔｔｅ＿ｕｐｄａｔｅ＿ｊｕｄｇｅ＝１の場合は表示領域及びビットマップ自体は直前のＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔと同じであるが、表示色インデックスカラーテーブルのみが変わる。これにより、例えば、カラオケのような徐々に色が変わるような図柄の表示制御をデータサイズが大きいビットマップを再送せずに実現することができる。

ＷＩＮ（ＷＩＮｄｏｗ）はＰＭ直後に配置されるデータセグメントであり複数並べてもよい。ＷＩＮはＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが用いる表示領域を指定するデータセグメントであり、以下のデータフィールドを含む。

ｓｅｇ＿ｔｙｐｅ＝０ｘ０２で、このデータセグメントがＷＩＮであることが示される。

ｗｉｎｄｏｗ＿ｉｄは、このＷＩＮで指定される表示領域を識別するための情報である。

ｗｉｎｄｏｗ＿ｐｏｓ＿ｘ及びｗｉｎｄｏｗ＿ｐｏｓは、この表示領域の左上座標値を示している。＿ｗｉｎｄｏｗ＿ｓｉｚｅ＿ｘ及びｗｉｎｄｏｗ＿ｓｉｚｅ＿ｙは、この表示領域の横方向（ｘ）及び縦方向（ｙ）のサイズをピクセル精度で示している。

なお、表示領域をこのように区切るのは、限られたデコーダ伝送帯域の条件下であっても、表示領域を絞ることで、表示更新間隔を早くすることができるからである。

ＰＡＬ（ＰＡＬｅｔｔｅ）はＷＩＮ直後に配置されるデータセグメントであり複数並べてもよい。ＰＡＬはＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが用いる表示色（インデックスカラー）を格納したデータセグメントであり、以下のデータフィールドを含む。

ｓｅｇ＿ｔｙｐｅ＝０ｘ０３で、このデータセグメントがＰＡＬであることが示される。

ｐａｌｅｔｔｅ＿ｉｄは、この表示色インデックスカラーテーブルを識別するための情報である。

ｐａｌｅｔｔｅ＿ｖｅｒｓｉｏｎは、同じｐａｌｅｔｔｅ＿ｉｄを持つＰＡＬの中でのバージョン（更新の有無）を示している。このｐａｌｅｔｔｅ＿ｖｅｒｓｉｏｎは、表示色インデックスカラーテーブルのみを更新するようなＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔ（ｐａｌｅｔｔｅ＿ｕｐｄａｔａ＿ｊｕｄｇｅ＝１）において、ｐａｌｅｔｔｅ＿ｉｄは固定ながらｐａｌｅｔｔｅ＿ｖｅｒｓｉｏｎのみを更新する目的で利用することができる。

ｃｏｌｏｒ＿ｉｎｄｅｘはカラーインデックスの番号（例えば０から２５５）を示している。

Ｙ、Ｃｒ、Ｃｂ及びａｌｐｈａは該当するカラーインデックス番号（ｃｏｌｏｒ＿ｉｎｄｅｘ）が実際に意味する色情報を示す。当該色情報は、Ｙ（輝度情報）、Ｃｒ／Ｃｂ（色差情報）、ａｌｐｈａ（透過度情報）として夫々格納される。これによりＢＭＰ（）にて指定されるインデックスカラー番号（ｃｏｌｏｒ＿ｉｎｄｅｘ）に対応する色が特定される。このカラーインデックスはループ処理により最大２５５色が登録される。

ＢＭＰ（ＢｉｔＭａＰ）はＰＡＬ直後に配置されるデータセグメントで複数並べてもよい。例えば、複数の字幕映像が同時に表示される場合に、複数のＷＩＮ、ＰＡＬ及びＢＭＰが配置される。ＢＭＰはＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔが格納する字幕映像のビットマップ情報を格納している。

ｓｅｇ＿ｔｙｐｅ＝０ｘ０４で、このデータセグメントがＢＭＰであることが示される。

ｂｉｔｍａｐ＿ｉｄは、このビットマップ映像情報の識別情報である。

ｂｉｔｍａｐ＿ｖｅｒｓｉｏｎは、このビットマップのバージョン（更新の有無）を示している。

ｂｉｔｍａｐ＿ｓｉｚｅ＿ｘ及びｂｉｔｍａｐ＿ｓｉｚｅ＿ｙは、このビットマップを展開した際のｘ及びｙ方向のサイズをピクセル精度で記述している。

ｂｉｔｍａｐ＿ｉｍａｇｅ＿ｄａｔａ（）は、このビットマップ映像を圧縮符号化したデータを格納している。

このように、１つの字幕表示単位であるＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔは、１回の字幕表示もしくは字幕更新に必要な情報をデータセグメント化して転送するためのエレメンタリストリームである。字幕ストリームは、このＰｒｅｓｅｎｔａｔｉｏｎ Ｓｅｔを複数ならべて字幕を更新させるものである。

図４０は、図３９で説明した字幕表示時の位置関係を示す図である。

字幕を表示するプレーンは左上を原点としてｘ及びｙ座標軸が夫々右及び下方向へ向かう。このプレーン内に表示領域（ＷＩＮ）が配置され、その表示領域の内部に、ビットマップイメージ（ＢＭＰ）が配置される。

図４１は、図５などで説明した管理情報（管理情報ファイル）と、その内容を説明する図である。

図４１の（ａ）に示されるように、ＢＤ．ＩＮＦＯファイルには、ディスク全体の代表属性情報を記述したＤｉｓｃＩｎｆｏ（）と、ＢＤ．ＩＮＦＯの拡張データ領域であるＥｘｔｅｎｓｉｏｎ（）とが含まれる。Ｅｘｔｅｎｓｉｏｎ（）には、Ｄｉｓｃ＿Ｔｙｐｅ（）とＨＤＲ＿ｍｅｔａ（）とが含まれる。

Ｄｉｓｃ＿Ｔｙｐｅ（）は、これが記録されたディスクの物理的特性を示す拡張情報である。Ｄｉｓｃ＿Ｔｙｐｅ（）内のｄｉｓｃ＿ｔｙｐｅフィールドに示される３ｂｉｔの情報に基づいて、下記のようにディスク種別の識別が可能である。

ｄｉｓｃ＿ｔｙｐｅ： ３ｂｉｔｓ （ｂｓｌｂｆ）
０１０ｂ： ２５ＧＢ／ｌａｙｅｒの記録密度を持ち、７２Ｍｂｐｓで読み込みが必要なディスク
０１１ｂ： ２５ＧＢ／ｌａｙｅｒの記録密度を持ち、９２Ｍｂｐｓで読み込みが必要なディスク
１００ｂ： ３３ＧＢ／ｌａｙｅｒの記録密度を持ち、９２Ｍｂｐｓで読み込みが必要なディスク
１０１ｂ： ３３ＧＢ／ｌａｙｅｒの記録密度を持ち、１２２Ｍｂｐｓで読み込みが必要なディスク
１１０ｂ： ３３ＧＢ／ｌａｙｅｒの記録密度を持ち、１４４Ｍｂｐｓで読み込みが必要なディスク

ＢＤ．ＩＮＦＯファイル内のＨＤＲ＿ｍｅｔａ（）には、このディスクに対するＨＤＲ関連のメタデータが記述されている。

また、図４１の（ｂ）に示されるように、ＸＸＸ．ＰＬファイルには、前述の情報に加えて、ＣｅｌｌＬｉｓｔ内に拡張ビデオストリーム（Ｅｎｈａｎｃｅｍｅｎｔ ｌａｙｅｒ ｖｉｄｅｏ ｓｔｒｅａｍ）の再生制御情報が記述されたＳｕｂＰＬＬｉｓｔ（）が含まれる。また、ＸＸＸ．ＰＬファイルの拡張データ領域であるＥｘｔｅｎｓｉｏｎ（）内には、ＨＤＲ＿ｍｅｔａ（）とＣｏｍｂｉＥｘｔ（）とを記録できる。

ＸＸＸ．ＰＬファイル内のＨＤＲ＿ｍｅｔａ（）は、このプレイリストに対するＨＤＲ関連のメタデータが記述されている。

また、プレイリストファイルのＥｘｔｅｎｓｉｏｎ（）内には、ＣｏｍｂｉＥｘｔ（）が格納される。ＣｏｍｂｉＥｘｔ（）は、後述する図４２に記載されたＣｏｍｂｉ（）と同じデータ構造とセマンティックスを持ち、同時に再生可能なエレメンタリストリームの組み合わせを示す情報である。ＣｏｍｂｉＥｘｔ（）には、標準輝度範囲のビデオストリーム（以下、ＳＤＲビデオストリームとも記載する）と、当該ＳＤＲビデオストリームと一緒に再生可能な標準輝度範囲の字幕ストリーム（以下、ＳＤＲ字幕ストリームとも記載する）やオーディオストリームなどが登録されている。

また、図４１の（ｃ）に示されるように、ＹＹＹ．ＶＯＢＩファイルには、当該ＶＯＢの使用用途を表す情報（ＶＯＢ＿ｔｙｐｅ）、システムストリームの最大ビットレートを示す情報（ＳｙｓＲａｔｅ）、ビデオストリームの属性情報（Ｖｉｄｅｏ＃０（）など）、オーディオストリームの属性情報（Ａｕｄｉｏ＃０（）など）、字幕ストリームの属性情報（Ｓｕｂｔｉｔｌｅ＃０（）など）を記録できる。また、ＹＹＹ．ＶＯＢＩファイルには、ランダムアクセスポイントが列挙されたＴＭＡＰ（）を記録できる。また、ＹＹＹ．ＶＯＢＩの拡張データ領域であるＥｘｔｅｎｓｉｏｎ（）内には、ＨＤＲ＿ｍｅｔａ（）とＴＭＡＰＥｘｔ（）とを記録できる。

ＹＹＹ．ＶＯＢＩファイル内のＨＤＲ＿ｍｅｔａ（）は、このＶＯＢストリームに対するＨＤＲ関連のメタデータが記述されている。

ＴＭＡＰＥｘｔ（）は、図１３、図１４、及び図１５で示すようなランダムアクセスのテーブル情報であるＴＭＡＰ（）と、同じデータ構造及び同じセマンティックスを有する。ＴＭＡＰＥｘｔ（）には、標準輝度（ＳＤＲ）のビデオストリームに対するランダムアクセスポイント情報が格納される。

ＶＯＢ＿ｔｙｐｅに格納される値は、下記のような意味である。

ＶＯＢ＿ｔｙｐｅ＝０ｘ０１（Ｍａｉｎ ＴＳ ｆｏｒ ｍｏｖｉｅ ａｐｐｌｉｃａｔｉｏｎ）である場合は、これが記述されたＶＯＢが、通常の映画などの映像再生で使われるＶＯＢ（ＭＰＥＧ−２ ＴＳストリーム）であることを意味する。

ＶＯＢ＿ｔｙｐｅ＝０ｘ１０（Ｓｕｂ ＴＳ ｆｏｒ Ｅｎｈａｎｃｅｍｅｎｔ ｌａｙｅｒ ｖｉｄｅｏ ｓｔｒｅａｍ）である場合は、これが記述されたＶＯＢが拡張ビデオストリームを多重化した、ＳｕｂＰＬでのみ利用可能なＶＯＢ（ＭＰＥＧ−２ ＴＳストリーム）であることを意味する。

図４２は、図４１で説明したデータベースファイルのデータ構造を示す図である。

図４２の（ａ）に示されるように、Ｃｅｌｌ＃ｎ（）は、ｎ番目のＣｅｌｌの情報である。Ｃｅｌｌ＃ｎ（）は、当該Ｃｅｌｌ＃ｎ（）において参照されるＶＯＢストリームファイルの識別情報（ＶＯＢＮａｍｅ）、Ｃｌｏｓｅｄ Ｃａｐｔｉｏｎｉｎｇの情報（ＣＣ）、当該Ｃｅｌｌ＃ｎ（）の再生開始時刻情報（Ｉｎ）、当該Ｃｅｌｌ＃ｎ（）の再生終了時刻情報（Ｏｕｔ）、当該Ｃｅｌｌ＃ｎ（）内で同時に再生可能なエレメンタリストリームの組み合わせを示すＣｏｍｂｉ（）情報などから構成される。

Ｃｏｍｂｉ（）には、当該Ｃｏｍｂｉを含むＣｅｌｌ＃ｎ（）において同時に再生できる組み合わせとして許可されているエレメンタリストリームごとに様々な符号化属性情報が記述される。

図４２の（ｂ）に示されるように、許可されているエレメンタリストリームがビデオストリームであれば、Ｃｏｍｂｉ（）には、そのビデオストリームのＰＩＤのような特定情報（ＶｉｄｅｏＰＩＤ）、解像度及びアスペクトなどの符号化属性情報（ＶｉｄｅｏＦｏｒｍａｔ）などが記述される。

許可されているエレメンタリストリームが図３８で示したような拡張ビデオストリームであれば、Ｃｏｍｂｉ（）には、その拡張ビデオシーケンスのＰＩＤのような特定情報（ＥｎｈＶｉｄｅｏＰＩＤ）、ビットデプス情報（ＥｎｈＶｉｄｅｏＢｉｔＤｅｐｔｈ）、及び最高輝度情報（ＥｎｈＶｉｄｅｏＭａｘＬｕｍ）などが記述される。

許可されているエレメンタリストリームがオーディオストリームであれば、Ｃｏｍｂｉ（）には、そのオーディオストリームのＰＩＤのような特定情報（ＡｕｄｉｏＰＩＤ）、符号化方式（Ｃｏｄｉｎｇ）、及びチャンネル数（Ｃｈ．）などが記述される。

許可されているエレメンタリストリームが字幕ストリームであれば、その字幕ストリームのＰＩＤのような特定情報（ＳｕｂｔｉｔｌｅＰＩＤ）、及び字幕の言語情報（Ｌａｎｇｕａｇｅ）などが記述される。

図４２の（ｃ）に示されるように、ＳｕｂＰＬ＃ｎ（）は、ｎ番目の追加の副再生経路を指定する情報である。ＳｕｂＰＬ＃ｎ（）は、例えば、ＨＤＲビデオストリームと組み合わせて一緒に再生されるべき拡張ビデオストリームを指定する情報である。

ＳｕｂＰＬ＃ｎ（）に含まれるＳｕｂＰＬ＿ｔｙｐｅ情報は、ＨＤＲビデオストリームと拡張ビデオストリームとの再生方法の種別を示す情報である。同期／非同期、または、再生に利用されるシステムストリーム本数（１ｏｒ２本）などを特定するために用いられる。

ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｅｎｈａｎｃｅｍｅｎｔ
Ｌａｙｅｒ Ｖｉｄｅｏ ＳｕｂＰＬ ｉｎ Ｓｕｂ ＴＳ）は、２本のシステムストリーム（ＭＰＥＧ−２ ＴＳ）の一方からＨＤＲビデオストリームを読み出し、他方から拡張ビデオストリームを読み出し、読み出したストリーム同士を同期して再生する再生方法の種別である。なお、ここでの「同期」は、ＨＤＲビデオストリームのあるピクチャは、必ず拡張ビデオストリームのあるピクチャとしか同時に再生されないという固定的な関係にあることを意味する。

ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ｂ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｅｎｈａｎｃｅｍｅｎｔ
Ｌａｙｅｒ Ｖｉｄｅｏ ＳｕｂＰＬ ｉｎ Ｍａｉｎ ＴＳ）は、１本のＭＰＥＧ−２ ＴＳの中にあるＨＤＲビデオストリームと、拡張ビデオストリームとを同期して再生する再生方法の種別である。

ＳｕｂＣｅｌｌＬｉｓｔ情報は、ＳｕｂＣｅｌｌ情報が束ねられた情報である。

ＳｕｂＣｅｌｌ情報は、拡張ビデオストリームを含む１連続区間（ＳｕｂＣｅｌｌ）が参照するＶＯＢファイルのファイル名（ＶＯＢＮａｍｅ）、ＳｕｂＣｅｌｌ開始時刻情報（Ｉｎ）、ＳｕｂＣｅｌｌ終了時刻情報（Ｏｕｔ）、及び、同時に再生されるＣｅｌｌの識別情報（ＣｅｌｌＮｕｍ）とを含む。

このようなＳｕｂＰＬ＃ｎ（）は、どのような再生モデルで、どのファイルを用いて、ＨＤＲビデオストリームと拡張ビデオストリームとが再生されるのかをプレーヤに指示することができる。

図４３は、ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａの場合における管理情報の各フィールドの意味を説明する図である。

ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａの再生モデルでは、２本のシステムストリームファイル（ＭＰＥＧ−２ ＴＳ）を用いて、ＨＤＲビデオストリーム（ＨＤＲｂ）をＭａｉｎ ＴＳから、その拡張ビデオストリーム（Ｅｎｈ． Ｌａｙｅｒ Ｖｉｄｅｏ）をＳｕｂ ＴＳから、同時に読み出しながら再生する。

Ｃｅｌｌ＃０にて指定される再生区間として、ＨＤＲビデオストリーム（ＨＤＲｂ）におけるＣｅｌｌ＃０．ＩｎからＣｅｌｌ＃０．Ｏｕｔまでの再生区間が再生される。この再生に同期して、ＳｕｂＣｅｌｌ＃０にて指定される連続区間として、拡張ビデオストリームにおけるＳｕｂＣｅｌｌ＃０．ＩｎからＳｕｂＣｅｌｌ＃０．Ｏｕｔまでの連続区間が再生される。これにより、後述の図４５に示す基本デコーダ４０１にて復号されるＨＤＲビデオストリーム（ＨＤＲｂ）よりもより高輝度でより量子化精度が高い高輝度映像情報が出力される。

ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａの再生モデルでは、２本のビデオストリームは同期して再生されるため、Ｃｅｌｌ＃０．ＩｎとＳｕｂＣｅｌｌ＃０．Ｉｎとは同一であり、かつ、Ｃｅｌｌ＃０．ＯｕｔとＳｕｂＣｅｌｌ＃０．Ｏｕｔとは同一である。なお、Ｃｅｌｌ＃０．Ｉｎ、Ｃｅｌｌ＃０．Ｏｕｔ、ＳｕｂＣｅｌｌ＃０．ＩｎおよびＳｕｂＣｅｌｌ＃０．ＯｕｔはそれぞれＰＴＳ時間軸で表現される時刻である。

ここで、ＶＯＢ＿ｔｙｐｅ＝０ｘ１０ （Ｓｕｂ ＴＳ ｆｏｒ Ｅｎｈ． Ｌａｙｅｒ Ｖｉｄｅｏ）は、このＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａ （Ｓｙｎｃｈｒｏｎｏｕｓ
Ｅｎｈａｎｃｅｍｅｎｔ Ｌａｙｅｒ Ｖｉｄｅｏ ＳｕｂＰＬ ｉｎ Ｓｕｂ ＴＳ）の再生モデルのみに利用される。

図４４は、ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ｂの場合における管理情報の各フィールドの意味を説明する図である。

ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ｂの再生モデルでは、１本のシステムストリームファイル（ＭＰＥＧ−２ ＴＳ）の中に、ＨＤＲビデオストリーム（ＨＤＲｂ）と、その拡張ビデオストリームとが多重化されており、それらのストリームを同時に再生する。このように、ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ｂの再生モデルでは、基本ビデオストリームと拡張ビデオストリームとが同一のトランスポートストリームに多重化されている。これにより、基本ビデオストリームと拡張ビデオストリームとを明確に対応付けることができ、広いダイナミックレンジの映像情報を適切に再生することができる。

Ｃｅｌｌ＃０にて指定される再生区間として、ＨＤＲビデオストリーム（ＨＤＲｂ）におけるＣｅｌｌ＃０．ＩｎからＣｅｌｌ＃０．Ｏｕｔまでの再生区間が再生される。この再生に同期して、ＳｕｂＣｅｌｌ＃０にて指定される連続区間として、拡張ビデオストリームにおけるＳｕｂＣｅｌｌ＃０．ＩｎからＳｕｂＣｅｌｌ＃０．Ｏｕｔまでの連続区間が再生される。これにより、後述の図４５に示す基本デコーダ４０１にて復号されるＨＤＲビデオストリーム（ＨＤＲｂ）よりもより高輝度でより量子化精度が高い高輝度映像情報が出力される。

このように、ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ｂの再生モデルでは、２本のビデオストリームは、同一のシステムストリームファイル（ＭＰＥＧ−２ ＴＳであるＭａｉｎ ＴＳ）に多重化されており、同期して再生される。したがって、Ｃｅｌｌ＃０．ＩｎとＳｕｂＣｅｌｌ＃０．Ｉｎとは同一であり、かつ、Ｃｅｌｌ＃０．ＯｕｔとＳｕｂＣｅｌｌ＃０．Ｏｕｔとは同一である。

つまり、管理情報ファイルであるＰｌａｙＬｉｓｔには、基本ビデオストリームの再生経路に含まれる第１の区間と、拡張ビデオストリームの再生経路に含まれる第２の区間とが互いに対応付けて記述されている。そして、その第１の区間と第２の区間の再生時間は同じである。具体的には、ＰｌａｙＬｉｓｔには、互いに同一の時刻である、第１の区間の再生開始時刻と、第２の区間の再生開始時刻とが記述され、さらに、互いに同一の時刻である、第１の区間の再生終了時刻と、第２の区間の再生終了時刻とが記述されている。これにより、基本ビデオストリームと拡張ビデオストリームとを適切に同期させて再生することができる。

図４５は、本実施の形態におけるＨＤＲビデオストリームのデコーダモデルを説明する図である。

本実施の形態における再生装置は、デコーダシステム４００を備えている。デコーダシステム４００は、上述の各管理情報ファイルに基づいて、基本ビデオストリームまたは拡張ビデオストリームなどのビデオストリームと、字幕などを示すグラフィックスデータとを、ＢＤから読み出して再生する映像再生部である。

デコーダシステム４００は、基本デコーダ（Ｂａｓｅ Ｄｅｃ）４０１、拡張デコーダ（Ｅｎｈ． Ｄｅｃ）４０２、基本プレーン（Ｂａｓｅ ｐｌａｎｅ（ＨＤＲｂ））４０３、拡張プレーン（Ｅｎｈ． ｐｌａｎｅ）４０４、拡張プレーン（ＨＤＲｅ ｐｌａｎｅ）４０５、Ｂａｓｅ＋Ｅｎｈ．プレーン４０６、字幕デコーダ（Ｓｕｂ． Ｄｅｃ）４０７、字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（８ｂｉｔ））４０８、グラフィックスプロセッサ（ＧＰ）４０９、高輝度字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（ＨＤＲｂ／ｅ））４１０、および高輝度字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（Ｂａｓｅ＋Ｅｎｈ．））４１１を備える。

ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）を含むＨＤＲビデオストリームは、基本デコーダ（Ｂａｓｅ Ｄｅｃ）４０１にてデコードされる。そして、そのＨＤＲビデオストリームのデコードによって生成された高輝度映像情報は、基本プレーン（Ｂａｓｅ ｐｌａｎｅ（ＨＤＲｂ））４０３に展開される。ここで、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）に含まれる基本的な輝度情報（コンテンツ全体での最高／最低輝度値）などは、その高輝度映像情報と一緒に伝送されて、ＨＤＭＩ（登録商標）などの外部映像出力Ｉ／Ｆへと出力される。

ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）に対応した再生装置であるデコーダシステム４００は、基本プレーン（Ｂａｓｅ ｐｌａｎｅ（ＨＤＲｂ））４０３の高輝度映像情報に対して、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）の輝度拡張情報を加えて、拡張プレーン４０５に拡張高輝度映像情報を展開する。このＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）までを加えた拡張高輝度映像情報は、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｅ）に含まれる追加の輝度情報（シーン単位での最高／最低輝度値）などと一緒に、ＨＤＭＩ（登録商標）などの外部映像出力Ｉ／Ｆへと出力される。

上述の拡張ビデオストリームに対応した再生装置であるデコーダシステム４００では、拡張ビデオストリームを拡張デコーダ（Ｅｎｈ． Ｄｅｃ）４０２にてデコードする。そして、そのデコードによって生成された拡張映像情報は、拡張プレーン（Ｅｎｈ． ｐｌａｎｅ）４０４に展開される。デコーダシステム４００は、この拡張映像情報を、基本プレーン（Ｂａｓｅ ｐｌａｎｅ（ＨＤＲｂ））４０３の高輝度映像情報と、同じＰＴＳを持つ映像同士で合成する。この合成によって得られた拡張高輝度映像情報は、Ｂａｓｅ＋Ｅｎｈ．プレーン４０６に展開される。デコーダシステム４００は、この拡張高輝度映像情報を、ＳＥＩ ｍｅｓｓａｇｅ（ＨＤＲｂ）にて伝送される基本的な輝度情報、または拡張ビデオストリーム内に格納された輝度拡張情報などと一緒に、ＨＤＭＩ（登録商標）などの外部映像出力Ｉ／Ｆへと出力する。

ここで、ビデオに重畳するグラフィックスデータ、例えば字幕ストリームは、字幕デコーダ（Ｓｕｂ． Ｄｅｃ）４０７にてデコードされることによって、８ビットのインデックスカラー（２５５色）にて表現される。デコードされた字幕ストリームである字幕は、字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（８ｂｉｔ））４０８へ展開される。グラフィックスプロセッサ（ＧＰ）４０９は、その字幕を表現する８ビット諧調のＹＣｒＣｂを１０ビット諧調のＹＣｒＣｂへ、さらに、字幕の輝度を標準輝度から、（高輝度映像情報または拡張高輝度映像情報に合わせた）高い輝度へ変換する。高輝度に変換された字幕である高輝度字幕は、高輝度字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（ＨＤＲｂ／ｅ））４１０に展開される。そして、高輝度字幕プレーン４１０に展開された高輝度字幕は、同一表示時刻を持つ、基本プレーン（Ｂａｓｅ ｐｌａｎｅ（ＨＤＲｂ））４０３のピクチャか、拡張プレーン（ＨＤＲｅ ｐｌａｎｅ）４０５のピクチャと合成されて出力される。

また、Ｂａｓｅ＋Ｅｎｈ．プレーン４０６に拡張高輝度映像情報がある場合または、ＳｕｂＰＬ＿ｔｙｐｅ＝０ｘ０Ａ ｏｒ ０ｘ０ＢのＰｌａｙＬｉｓｔが再生されている場合には、グラフィックスプロセッサ（ＧＰ）４０９は、字幕を表現する８ビット諧調のＹＣｒＣｂを１２ビット諧調のＹＣｒＣｂへ変換する。さらに、グラフィックスプロセッサ（ＧＰ）４０９は、字幕を拡張ビデオストリームにあわせて重畳するため、字幕の輝度を標準輝度から、（拡張ビデオストリームを用いて生成された拡張高輝度映像情報に合わせた）より高い輝度に変換する。より高い輝度に変換された字幕である高輝度字幕は、高輝度字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（Ｂａｓｅ＋Ｅｎｈ．））４１１に展開される。そして、高輝度字幕プレーン４１１に展開された高輝度字幕は、同一表示時刻を持つ、Ｂａｓｅ＋Ｅｎｈ．プレーン４０６のピクチャと合成されて出力される。

ここで、グラフィックスプロセッサ（ＧＰ）４０９は、字幕プレーン（Ｓｕｂｔｉｔｌｅ Ｐｌａｎｅ（８ｂｉｔ））４０８に展開された字幕に対するインデックスカラーテーブル（ＣＬＵＴ）を、字幕デコーダ（Ｓｕｂ． Ｄｅｃ）４０７から取得する。このインデックスカラーテーブル（ＣＬＵＴ）においては、字幕に合成される映像情報がＳＤＲビデオストリームであるかＨＤＲビデオストリームであるかに応じて、ＳＤＲ用のＣＬＵＴ及びＨＤＲ用のＣＬＵＴのいずれか一方のＣＬＵＴのみが多重化されている。また、映像情報のＨＤＲ種別は複数あるが、字幕ストリームのＣＬＵＴは、１種類のみがＨＤＲ用として提供される。

図４６は、データベースファイルへの各ストリームの登録方法を示す図である。図４６は、プレイリストファイルに格納されるＣｏｍｂｉ（）、ＣｏｍｂｉＥｘｔ（）、及び、ＳｕｂＰＬ（）と、ＶＯＢＩファイルに格納されるＴＭＡＰ（）及びＴＭＡＰＥｘｔ（）との５つのデータブロックに対して、ビデオストリームの組み合わせに応じてどこにどのような情報が登録及び管理されるのかを示す表である。尚、図４６におけるＥＬは、拡張ビデオストリームを指している。図４６におけるＨＤＲは、ＨＤＲｂまたはＨＤＲｅを指している。

ＳＤＲビデオストリームだけがプレイリストファイルに登録される場合には、Ｃｏｍｂｉ（）に、当該ＳＤＲビデオストリームと、それに重畳されるＳＤＲ字幕ストリーム（ＳＤＲ用のＰＡＬのみを持つ字幕ストリーム）と、音声ストリームとが登録される。ＴＭＡＰ（）には、ＳＤＲビデオストリームのランダムアクセス情報が登録される。

同様に、ＨＤＲビデオストリームだけがプレイリストに登録される場合には、Ｃｏｍｂｉ（）に、当該ＨＤＲビデオストリームと、それに重畳されるＨＤＲ字幕ストリーム（ＨＤＲ用のＰＡＬのみを持つ字幕ストリーム）と、音声ストリームとが登録される。ＴＭＡＰ（）にはＨＤＲビデオストリームのランダムアクセス情報が登録される。

次に、ＨＤＲビデオストリームとＳＤＲビデオストリームとの２本が１つのプレイリストに登録される場合について説明する。この場合、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリームと、それに重畳されるＨＤＲ字幕ストリームと、音声ストリームとが登録される。つまり、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納される。

一方、ＴＭＡＰ（）には、ＨＤＲビデオストリームのランダムアクセス情報が登録される。つまり、ＴＭＡＰ（）には、ＨＤＲビデオストリームに含まれる独立して復号可能なピクチャの位置を示すランダムアクセス情報（以下、第一ランダムアクセス情報とも記載する）が格納される。

これに加えて、ＣｏｍｂｉＥｘｔ（）には、ＳＤＲビデオストリームとそれに重畳されるＳＤＲ字幕ストリームと、音声ストリームとが登録される。つまり、ＣｏｍｂｉＥｘｔには、ＳＤＲビデオストリーム及びＳＤＲ字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される。

そして、ＴＭＡＰＥｘｔ（）には、ＳＤＲビデオストリームのランダムアクセス情報が登録される。つまり、ＴＭＡＰＥｘｔ（）には、ＳＤＲビデオストリームに含まれる独立して復号可能なピクチャの位置を示すランダムアクセス情報（以下第二ランダムアクセス情報とも記載する）が格納される。

次に、ＨＤＲビデオストリームと拡張ビデオストリーム（図４６ではＥＬと表記）との２本が１つのプレイリストに登録される場合について説明する。この場合、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリームと、それに重畳されるＨＤＲ字幕ストリームと、音声ストリームとが登録される。ＴＭＡＰ（）には、ＨＤＲビデオストリームのランダムアクセス情報と拡張ビデオストリームのランダムアクセス情報とが登録される。つまり、この場合、ＴＭＡＰ（）には、上記第一ランダムアクセス情報と、拡張ビデオストリームに含まれるピクチャの再生時刻を示すランダムアクセス情報（以下、第三ランダムアクセス情報とも記載する）が格納される。

さらに、ＳｕｂＰＬ（）には、拡張ビデオストリームの再生制御情報が登録される。つまり、ＳｕｂＰＬ（）には、ＨＤＲビデオストリームの輝度範囲を拡張するための拡張ビデオストリームが指定された第三再生制御情報が格納される。これは、図４３及び図４４を用いて説明されたパターンである。

次に、ＨＤＲビデオストリームと輝度拡張用ビデオストリームとＳＤＲビデオストリームとの３本が１つのプレイリストに登録される場合について説明する。この場合、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリームと、それに重畳されるＨＤＲ字幕ストリームと、音声ストリームとが登録される。ＴＭＡＰ（）には、ＨＤＲビデオストリームのランダムアクセス情報と、拡張ビデオストリームのランダムアクセス情報とが登録される。

さらに、ＳｕｂＰＬ（）には、拡張ビデオストリームの再生制御情報が登録される。加えて、ＣｏｍｂｉＥｘｔ（）には、ＳＤＲビデオストリームと、それに重畳されるＳＤＲ字幕ストリームと、音声ストリームとが登録される。ＴＭＡＰＥｘｔ（）には、ＳＤＲビデオストリームのランダムアクセス情報が登録される。

次に、ＳＤＲビデオストリームと拡張ビデオストリームとの２本が１つのプレイリストに登録される場合について説明する。この場合、Ｃｏｍｂｉ（）には、ＳＤＲビデオストリームと、それに重畳されるＳＤＲ字幕ストリームと、音声ストリームとが登録される。ＴＭＡＰ（）には、ＳＤＲビデオストリームのランダムアクセス情報と、拡張ビデオストリームのランダムアクセス情報が登録される。さらに、ＳｕｂＰＬ（）には、拡張ビデオストリームの再生制御情報が登録される。

ただし、このケースは、拡張ビデオストリームを用いてＳＤＲビデオストリームを高輝度／高ビット精度のＨＤＲ映像へ変換することができる場合にのみ適用される。

このように、ＨＤＲビデオストリームとＳＤＲビデオストリームとを１つのプレイリストに登録する際には、ＨＤＲビデオストリームとセットになるストリームは、Ｃｏｍｂｉ（）に登録され、ＳＤＲビデオストリームとセットになるストリームは、ＣｏｍｂｉＥｘｔ（）に登録される。つまり、ＨＤＲビデオストリームに関連するストリームのセットと、ＳＤＲビデオストリームに関連するストリームのセットとが全く別のセットとして別個に管理されている。

このような構成によれば、ＨＤＲビデオストリーム及びＳＤＲビデオストリームのどちらを再生するかが決定されれば、プレーヤ（再生装置）は、Ｃｏｍｂｉ（）及びＣｏｍｂｉＥｘｔ（）のどちらか１方だけを処理すればよい。Ｃｏｍｂｉ（）及びＣｏｍｂｉＥｘｔ（）は、同じデータ構造であり、かつ、同じセマンティックスであるため、Ｃｏｍｂｉ（）への処理とＣｏｍｂｉＥｘｔ（）への処理の一部を共通化し、処理を簡単にすることができる。また、システムのオーサリングが容易であるという利点、及び、プレーヤの実装／動作検証が容易である（開発コストを削減できる）という利点がある。

ここで、「Ｃｏｍｂｉ（）及びＣｏｍｂｉＥｘｔ（）は、同じデータ構造、同じセマンティックスである」の意味について補足する。図４１及び図４２に示されるように、プレイリストファイルの中には、具体的には、Ｃｅｌｌ＃ｎというデータブロックが設けられ、一つのＣｅｌｌ＃ｎ（）に、一つのＣｏｍｂｉ（）が設けられる。

これに対し、ＣｏｍｂｉＥｘｔ（）は、Ｃｅｌｌ＃ｎ（）に対する拡張データであるため、Ｃｏｍｂｉ（）は、ＣｏｍｂｉＥｘｔ（）の一部に対応する。上記の「Ｃｏｍｂｉ（）及びＣｏｍｂｉＥｘｔ（）は、同じデータ構造、同じセマンティックスである」は、より詳細には、ＣｏｍｂｉＥｘｔ（）に格納された第二再生制御情報の一部が、Ｃｏｍｂｉ（）に格納された第一再生制御情報の一部と実質的に同一のデータ構造及びセマンティックスを有することを意味する。言い換えれば、ＣｏｍｂｉＥｘｔ（）に格納された第二再生制御情報の一部は、Ｃｏｍｂｉ（）に格納された第一再生制御情報の一部と共通のデータ構造及びセマンテティックスを有する。

また、Ｃｏｍｂｉ（）と、ＣｏｍｂｉＥｘｔ（）とは、いずれもビデオストリームのＰＩＤのような特定情報（ＶｉｄｅｏＰＩＤ）を有していることも共通している。

以上のように、図４６に示されるようにデータベースファイルに各ストリームが登録されたＢＤには、再生環境に応じて選択的に用いられる、ＳＤＲビデオストリーム及びＳＤＲビデオストリームよりも輝度範囲の広いＨＤＲビデオストリームが記録される。ＳＤＲビデオストリームは、言い換えれば、標準輝度範囲のビデオストリームであり、ＨＤＲビデオストリームは、言い換えれば、高輝度範囲のビデオストリームである。ＢＤは、記録媒体の一例である。

また、このＢＤには、再生環境に応じて選択的に用いられる、ＳＤＲ字幕ストリーム及びＨＤＲ字幕ストリームと、コンテンツの再生制御情報が格納されるプレイリストファイル（図４６のＸＸＸ．ＰＬ）とが記録される。プレイリストファイルは、Ｃｏｍｂｉ（）、及び、ＣｏｍｂｉＥｘｔ（）を含む。Ｃｏｍｂｉ（）は、メインストリームに関する再生制御情報が格納される管理領域の一例であり、ＣｏｍｂｉＥｘｔ（）は、拡張領域の一例である。

そして、ＨＤＲビデオストリームとＳＤＲビデオストリームが１つのプレイリストに登録される場合、Ｃｏｍｂｉ（）には、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納される。ＣｏｍｂｉＥｘｔ（）には、ＳＤＲビデオストリーム及びＳＤＲ字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される。

このような構成のＢＤを再生するプレーヤは、ＨＤＲビデオストリームを選択して再生する場合には、従来どおりＣｏｍｂｉ（）内の第一再生制御情報を読み出せばよい。一方、プレーヤは、ＳＤＲビデオストリームを選択して再生する場合には、ＣｏｍｂｉＥｘｔ（）内の第二再生制御情報を読み出せばよい。

また、ＨＤＲとＳＤＲとが両方記録されるＢＤでは、ＨＤＲビデオストリームに、ＳＤＲ字幕ストリームまたはＳＤＲグラフィックスが重畳されてしまうことが想定される。つまり、高輝度の映像に輝度が不足した字幕及びグラフィックスが重畳されてしまうことが想定される。しかしながら、ＨＤＲビデオストリームとＳＤＲビデオストリームが１つのプレイリストに登録される場合、Ｃｏｍｂｉ（）に登録されるＨＤＲビデオストリームには、当該Ｃｏｍｂｉ（）の中でＨＤＲ字幕ストリームが組み合わされているため、ＨＤＲビデオストリームにＳＤＲ字幕ストリームが組み合わされるといったことが生じない。逆に、ＣｏｍｂｉＥｘｔ（）に登録されるＳＤＲビデオストリームには、当該ＣｏｍｂｉＥｘｔ（）の中でＳＤＲ字幕ストリームが組み合わされているため、ＳＤＲビデオストリームにＨＤＲ字幕ストリームが組み合わされるといったことが生じない。

このように、上記ＢＤによれば、ビデオストリームの選択などの再生制御が簡素化される。上記ＢＤによれば、当該ＢＤを再生するプレーヤの、ビデオストリーム選択処理及び再生処理を容易にすることができる。

また、第二再生制御情報の一部は、第一再生制御情報と共通のデータ構造を有する。これにより、プレーヤは、ＨＤＲビデオストリームとほぼ同様の処理でＳＤＲビデオストリームの再生を行うことができる。

また、図４６に示されるように、上記ＢＤには、さらに、上記ＢＤの全体に関する属性を示すＶＯＢＩファイルが記録される。ＶＯＢＩファイルは、ＴＭＡＰ（）及びＴＭＡＰＥｘｔ（）を含む。ＴＭＡＰ（）及びＴＭＡＰＥｘｔ（）のそれぞれには、ビデオストリームに含まれる独立して復号可能なピクチャの当該ビデオストリーム内の位置を示すランダムアクセス情報が格納される。ＶＯＢＩファイルは、管理情報ファイルの一例であり、ＴＭＡＰ（）は、マップ領域の一例であり、ＴＭＡＰＥｘｔ（）は、拡張マップ領域の一例である。

ＴＭＡＰ（）には、ＨＤＲビデオストリームに含まれる独立して復号可能なピクチャの当該ＨＤＲビデオストリーム内の位置を示す第一ランダムアクセス情報が格納される。ＴＭＡＰＥｘｔ（）には、ＳＤＲビデオストリームに含まれる独立して復号可能なピクチャの当該ＳＤＲビデオストリーム内の位置を示す第二ランダムアクセス情報が格納される。第一ランダムアクセス情報は、第一マップ情報の一例であり、第二ランダムアクセス情報は、第二マップ情報の一例である。

このような構成のＢＤを再生するプレーヤは、ＨＤＲビデオストリームを選択してランダムアクセス再生等を行うときには、ＴＭＡＰ（）内の第一ランダムアクセス情報を読み出せばよく、ＳＤＲビデオストリームを選択してランダムアクセス再生等を行うときには、ＴＭＡＰＥｘｔ（）内の第二ランダムアクセス情報を読み出せばよい。つまり、このようなＢＤによれば、当該ＢＤを再生するプレーヤの、ビデオストリーム選択処理及び再生処理を、ランダムアクセス再生等を行う場合においても容易にすることができる。

また、図４６に示されるように、上記ＢＤには、さらに、メインストリームのファイルと同時に再生されるサブストリームに関する再生制御情報が記録されるサブプレイリストファイル（図４６のＳｕｂＰＬ（））が記録される。サブプレイリストファイルには、ＨＤＲビデオストリームの輝度範囲を拡張するための拡張ビデオストリームに関する第三再生制御情報が格納される。そして、ＴＭＡＰ（）には、第一ランダムアクセス情報と、拡張ビデオストリームに含まれる独立して復号可能なピクチャの当該拡張ストリーム内の位置を示す第三ランダムアクセス情報が格納される。第三ランダムアクセス情報は、第三マップ情報の一例である。

このような構成のＢＤを再生するプレーヤは、Ｃｏｍｂｉ（）内の第一再生制御情報とＳｕｂＰＬ（）内の第三再生制御情報とを読み出すことにより、ＨＤＲビデオストリームと拡張ストリームとを同時に再生することができる。つまり、このようなＢＤによれば、当該ＢＤを再生するプレーヤの、ＨＤＲビデオストリームの拡張処理を容易にすることができる。

また、プレーヤは、ランダムアクセス再生等を行うときには、ＴＭＡＰ（）内の情報のみをさらに読み出せばよい。つまり、このようなＢＤによれば、ＨＤＲビデオストリームを拡張し、かつ、ランダムアクセス再生等を行う場合において、当該ＢＤを再生するプレーヤの再生処理を容易にすることができる。

次に、プレーヤの再生処理について説明する。図４７は、１つのプレイリストにＨＤＲビデオストリームを含む第一再生制御情報と、ＳＤＲビデオストリームを含む第二再生制御情報と、拡張ビデオストリームを含む第三再生制御情報、の３つの再生制御情報を含む場合の、プレーヤの再生処理のフロー図である。図４７に示されるように、プレーヤは、プレイリストファイルの実行開始後に、ＢＤに記録されたコンテンツ、プレーヤのＨＤＲビデオストリームのデコード対応可否、及び、プレーヤに接続されるテレビのＨＤＲビデオストリームへの対応有無などに基づいてコンテンツの再生形態の判定を行う（Ｓ８０１）。

プレーヤは、判定の結果、コンテンツのＨＤＲ再生を行う場合には、Ｃｏｍｂｉ（）に登録されたストリームセットを読み出して再生する（Ｓ８０２）。

言い換えれば、プレーヤ（再生装置）が備える映像再生部は、コンテンツをＨＤＲのコンテンツとして再生する場合には、Ｃｏｍｂｉ（）に格納された第一再生制御情報に基づいて、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを読み出して再生する。

なお、映像再生部は、コンテンツをＨＤＲのコンテンツとしてランダムアクセス再生等を行う場合には、第一再生制御情報及び第一ランダムアクセス情報に基づいて、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを読み出して再生する。

また、プレーヤは、判定の結果、コンテンツの拡張ＨＤＲ再生を行う場合には、Ｃｏｍｂｉ（）とＳｕｂＰＬ（）とに登録されたストリームセットを読み出して再生する（Ｓ８０３）。

言い換えれば、プレーヤが備える映像再生部は、コンテンツをより拡張された輝度範囲のＨＤＲコンテンツとして再生する場合、第一再生制御情報に基づいて、ＨＤＲビデオストリーム及びＨＤＲの字幕ストリームを読み出して再生し、かつ、第三再生制御情報に基づいて、拡張ビデオストリームを読み出して再生する。

なお、映像再生部は、コンテンツをより拡張された輝度範囲のＨＤＲコンテンツとしてランダムアクセス再生等を行う場合、第一再生制御情報及び第一ランダムアクセス情報に基づいて、ＨＤＲビデオストリーム及びＨＤＲ字幕ストリームを読み出して再生し、かつ、第三再生制御情報及び第三ランダムアクセス情報に基づいて、拡張ビデオストリームを読み出して再生する。

また、プレーヤは、判定の結果、コンテンツのＳＤＲ再生を行う場合には、ＣｏｍｂｉＥｘｔ（）に登録されたストリームセットを読み出して再生する（Ｓ８０４）。

言い換えれば、プレーヤが備える映像再生部は、コンテンツをＳＤＲのコンテンツとして再生する場合には、第二再生制御情報に基づいて、ＳＤＲビデオストリーム及びＳＤＲ字幕ストリームを読み出して再生する。

なお、映像再生部は、コンテンツをＳＤＲのコンテンツとしてランダムアクセス再生等を行う場合には、第二再生制御情報及び第二ランダムアクセス情報に基づいて、ＳＤＲビデオストリーム及びＳＤＲ字幕ストリームを読み出して再生する。

このように、上記ＢＤによれば、当該ＢＤを再生するプレーヤの、ビデオストリーム選択処理及び再生処理を容易にすることができる。

尚、上記の説明は一例に過ぎず、当該技術者にとっては、様々な応用が適用できる。

なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

以上、一つまたは複数の態様に係る記録媒体、再生方法および再生装置について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の範囲に含まれてもよい。

例えば、本発明は、上記のような記録媒体の製造方法（データの記録方法）または記録媒体の製造装置（データの記録装置）として実現されてもよい。

本発明は、標準輝度範囲のビデオストリーム及び高輝度範囲のビデオストリームの両方が記録された光ディスクであって、ビデオストリームの再生制御が容易な光ディスクに利用可能である。また、本発明は、このような光ディスクからビデオストリームを読み出して再生する再生装置としても利用可能である。

１０１ ＢＤ再生プログラム
１０２ ＢＤ管理情報
１０３ ＡＶデータ
１０４ ＢＤ−ＲＯＭ
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０２ プログラムプロセッサ
３０３ ＵＯマネージャ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１７ ドライブコントローラ
４００ デコーダシステム
４０１ 基本デコーダ
４０２ 拡張デコーダ
４０４ 拡張プレーン（Ｅｎｈ．ｐｌａｎｅ）
４０５ 拡張プレーン（ＨＤＲｅ ｐｌａｎｅ）
４０６ Ｂａｓｅ＋Ｅｎｈ．プレーン
４０７ 字幕デコーダ
４０８ 字幕プレーン
４０９ グラフィックスプロセッサ
４１０ 高輝度字幕プレーン
４１１ 高輝度字幕プレーン

Claims (1)

1. 再生環境に応じて選択的に用いられる、標準輝度範囲のビデオストリーム及び前記標準輝度範囲よりも輝度範囲の広い高輝度範囲のビデオストリームと、
   前記再生環境に応じて選択的に用いられる、前記標準輝度範囲の字幕ストリーム及び前記高輝度範囲の字幕ストリームと、
   コンテンツの再生制御情報が格納されるプレイリストファイルであって、メインストリームに関する前記再生制御情報が格納される管理領域、及び、拡張領域を含むプレイリストファイルとが記録され、
   前記管理領域には、前記高輝度範囲のビデオストリーム及び前記高輝度範囲の字幕ストリームを組み合わせて再生することが指定された第一再生制御情報が格納され、
   前記拡張領域には、前記標準輝度範囲のビデオストリーム及び前記標準輝度範囲の字幕ストリームを組み合わせて再生することが指定された第二再生制御情報が格納される
   記録媒体。

Images