(本発明の基礎となった知見)
本発明者は、「背景技術」の欄において記載した技術に関して課題が生じることを見出した。その課題について、以下、詳細に説明する。
映像データを記録した情報記録媒体の代表格は、DVD(以下、「Standard Difinition(SD)−DVD」ともいう。)である。以下に従来のDVDについて説明する。
図1は、SD−DVDの構造を示す図である。図1の下段に示すように、DVDディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられている。その論理アドレス空間には先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
ファイルシステムとは、ISO9660やUniversal Disc Format(UDF)等の規格により定められたデータを管理する仕組みのことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。
日常使っているパーソナルコンピュータ(PC)の場合でも、File Allocation Tables(FAT)またはNT File System(NTFS)と呼ばれるファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。
SD−DVDの場合、UDF及びISO9660の両方のファイルシステムが使用されている。両方を合わせて「UDFブリッジ」とも呼ばれる。記録されているデータはUDFまたはISO9660どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。なお、ここで取り扱うDVDはパッケージメディア用のROMディスクであり、物理的に書き込みが不可能である。
DVD上に記録されたデータは、UDFブリッジを通して、図1左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ(図1における「ROOT」)の直下に「VIDEO_TS」と呼ばれるディレクトリが置かれ、ここにDVDのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下の種類のファイルがある。
VIDEO_TS.IFO ディスク再生制御情報ファイル
VTS_01_0.IFO ビデオタイトルセット#1再生制御情報ファイル
VTS_01_0.VOB ビデオタイトルセット#1ストリームファイル
.....
上記例に示すように2つの拡張子が規定されている。「IFO」は再生制御情報が記録されたファイルであることを示す拡張子であり、「VOB」はAVデータであるMPEGストリームが記録されたファイルであることを示す拡張子である。
再生制御情報とは、DVDで採用されたインタラクティビティ(ユーザの操作に応じて再生を動的に変化させる技術)を実現するための情報や、メタデータのような、AVデータに付属する情報などのことである。また、DVDでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
再生制御情報ファイルは、ディスク全体を管理する「VIDEO_TS.IFO」と、個々のビデオタイトルセット毎の再生制御情報である「VTS_01_0.IFO」がある。なお、DVDでは複数のタイトル、言い換えれば複数の異なる映画や楽曲を1枚のディスクに記録することが可能である。
ここで、ファイル名ボディにある「01」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット#2の場合は、「VTS_02_0.IFO」となる。
図1の右上部は、DVDのアプリケーション層でのDVDナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「VIDEO_TS.IFO」内の情報は、VIDEO Manager Information(VMGI)として、「VTS_01_0.IFO」または、他のビデオタイトルセット毎に存在する再生制御情報はVideo Title Set Information(VTSI)としてDVDナビゲーション空間に展開される。
VTSIの中にはProgram Chain(PGC)と呼ばれる再生シーケンスの情報であるProgram Chain Information(PGCI)が記述されている。PGCIは、Cellの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。
Cell自身はVOB(Video Objectの略であり、MPEGストリームを指す)の一部区間または全部区間を指定する情報であり、Cellの再生は、当該VOBのCellによって指定された区間を再生することを意味している。
コマンドは、DVDの仮想マシンによって処理されるものであり、例えば、ウェブページを表示するブラウザ上で実行されるJava(登録商標)Scriptなどに近いものである。しかしながらJava(登録商標)Scriptが論理演算の他にウィンドウやブラウザの制御(例えば、新しいブラウザのウィンドウを開くなど)を行うのに対して、DVDのコマンドは、論理演算の他にAVタイトルの再生制御、例えば、再生するチャプターの指定などを実行するだけのものである点で異なっている。
Cellはディスク上に記録されているVOBの開始及び終了アドレス(論理アドレス)をその内部情報として有しており、プレーヤは、Cellに記述されたVOBの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
図2は、AVデータであるMPEGストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。
SD−DVDの特長であるインタラクティビティは前述した「VIDEO_TS.IFO」や「VTS_01_0.IFO」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック(ナビパックまたは、NV_PCKという。)と呼ばれる専用キャリアを使いVOB内に映像、音声データと一緒に多重化されている。
ここでは簡単なインタラクティビティの例としてメニュー画面について説明する。メニュー画面上には、幾つかのボタンが現れ、それぞれのボタンには当該ボタンが選択実行された時の処理が定義されている。
また、メニュー画面上では一つのボタンが選択されており(選択ボタン上に半透明色がオーバーレイされることで該ボタンがハイライトされ、該ボタンが選択状態であることをユーザに示す)、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。
リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する(決定キーを押す)ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプターの再生がコマンドによって実行されている。
図2の左上部はNV_PCKに格納される情報の概要を示している。NV_PCK内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。
ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報(ユーザの上下左右キー操作それぞれに対応する移動先ボタンの指定)と、ボタンコマンド情報(当該ボタンが決定された時に実行されるコマンド)とが記述されている。
メニュー画面上のハイライトは、図2の右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色を付した物である。このオーバーレイ画像は図2の右部に示す背景画像と合成されて画面上に表示される。
前述のようにして、DVDではメニュー画面を実現している。また、何故、ナビゲーションデータの一部をNV_PCKを使ってストリーム中に埋め込んでいるのかについては、以下の理由からである。
すなわち、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中5分〜10分の間にだけメニュー画面を表示するといった、同期タイミングが問題となりやすい処理を問題なく実現できるようにするためである。
また、もう一つの大きな理由は、NV_PCKには特殊再生を支援するための情報を格納し、DVD再生時の早送り、巻き戻しなどの非通常再生時にも円滑にAVデータをデコードし再生させる等、ユーザの操作性を向上させるためである。
図3は、DVDにおけるVOBの構成を示す概要図である。図に示すように、映像、音声、字幕などのデータ(図3の(1))は、MPEGシステム(ISO/IEC13818−1)規格に基づいて、パケット及びパック化し(図3の(2))、それぞれを多重化して1本のMPEGプログラムストリームにしている(図3の(3))。
また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだNV_PCKも一緒に多重化をされている。
MPEGシステムの多重化の特徴として、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではないことが挙げられる。
これはMPEGシステムストリームのデコーダモデル(図3の(4)、一般にSystem Target Decoder、またはSTDと呼ばれる)が多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。
このデコーダバッファは、個々のエレメンタリストリーム毎にサイズが異なり、映像に対しては、232kB、音声に対しては4kB、字幕に対しては52kBをそれぞれ有している。
このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、MPEGシステムストリームとしてビット列を形成する順番と表示(デコード)されるタイミングにずれが生じている。
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
ここで、ブルーレイディスク(Blu−ray(登録商標) Disc)のような大容量記録メディアにおいては、非常に高品位な映像情報を格納できる可能性がある。なお、Blu−ray(登録商標) Discは、BDまたはBD−ROMとも称される。
例えば、4K(3840x2160ピクセルの解像度を持つ映像情報)またはHDR(High Dynamic Rangeと一般に呼ばれる高輝度映像情報)などの映像情報をBDに格納することができると考えられる。しかしながら、HDRを含めて輝度には様々な実現方法があり、これらの実現方法の映像情報を効率的にビデオストリームとして記録および管理できるフォーマットはなかった。したがって、再生装置は、BDなどの記録媒体に記録されているビデオストリームの種別(上述の実現方法)に応じた輝度を適切に表現することができないという課題がある。
本発明者は、上記課題を解決するために、下記の改善策を検討した。
本発明の一態様に係る再生装置は、符号化された映像情報であるビデオストリームを記録媒体から読み出して再生する再生装置であって、前記ビデオストリームの輝度のダイナミックレンジが、第1のダイナミックレンジか、前記第1のダイナミックレンジよりも広い第2のダイナミックレンジかを示す第1の属性情報を、前記ビデオストリームに対応付けて前記記録媒体に記録されている管理情報ファイルから読み出す属性読み出し部と、前記ビデオストリームを前記記録媒体から読み出して復号することにより復号映像情報を生成する復号部と、読み出された前記第1の属性情報が第2のダイナミックレンジを示す場合、前記第2のダイナミックレンジに応じた前記ビデオストリームの最高輝度を示す最高輝度情報とともに、前記復号映像情報を出力する出力部とを備える。
これにより、記録媒体に記録されているビデオストリームの種別(特に、ダイナミックレンジ)に応じた輝度を適切に表現することができる。
また、前記第1の属性情報は、前記第2のダイナミックレンジを示す場合、さらに、前記第2のダイナミックレンジのタイプを示し、前記出力部は、前記第2のダイナミックレンジのタイプに応じた前記最高輝度情報と前記復号映像情報とを出力してもよい。例えば、前記第1の属性情報によって示されるタイプが、前記ビデオストリームの輝度範囲が静的に表現されるタイプである場合、前記出力部は、静的に最高輝度を示す前記最高輝度情報と前記復号映像情報とを出力する。または、前記第1の属性情報によって示されるタイプが、前記ビデオストリームの輝度範囲が静的および動的に表現されるタイプである場合、前記出力部は、静的および動的に最高輝度を示す前記最高輝度情報と前記復号映像情報とを出力する。なお、前記最高輝度情報は、前記ビデオストリームの全てのピクチャのうちの最高輝度によって定義される輝度範囲を示すことによって、静的に輝度範囲を示し、前記ビデオストリームに含まれる1つまたは複数のピクチャからなるグループごとに、当該グループのうちの最高輝度によって定義される輝度範囲を示すことによって、動的に輝度範囲を示す。または、前記第1の属性情報によって示されるタイプが、基本ビデオストリームと、前記基本ビデオストリームの輝度を拡張するための拡張ビデオストリームとによって、輝度が表現されるタイプである場合、前記復号部は、前記ビデオストリームを前記拡張ビデオストリームとして復号することによって前記復号映像情報を生成し、さらに、前記基本ビデオストリームを前記記録媒体から読み出して復号することによって基本映像情報を生成し、前記出力部は、前記最高輝度情報と、前記基本映像情報を用いて画像処理された前記復号映像情報とを出力する。
これにより、記録媒体にどのようなタイプのビデオストリームが記録されていても、そのビデオストリームのタイプに応じた輝度を適切に表現することができる。言い換えれば、どのような実現方法のHDRビデオストリームが記録媒体に記録されていても、その実現方法に応じた輝度を適切に表現することができる。
また、前記属性読み出し部は、さらに、前記ビデオストリームの最高輝度を示す第2の属性情報を、前記管理情報ファイルから読み出し、前記出力部は、さらに、前記第2の属性情報を含む前記最高輝度情報を出力してもよい。
これにより、ビデオストリームの輝度をより適切に表現することができる。
また、本発明の一態様に係る記録媒体は、符号化された映像情報であるビデオストリームと、前記ビデオストリームに対応付けられた管理情報ファイルとが記録され、前記管理情報ファイルは、前記ビデオストリームの輝度のダイナミックレンジが、第1のダイナミックレンジか、前記第1のダイナミックレンジよりも広い第2のダイナミックレンジかを示す第1の属性情報を含む。
これにより、再生装置に対して、ビデオストリームの種別に応じた輝度を適切に表現させることができる。また、異なる実現方法のHDRビデオストリームを同一の記録媒体に効率的に記録および管理することができる。
また、前記第1の属性情報は、前記第2のダイナミックレンジを示す場合、さらに、前記第2のダイナミックレンジのタイプを示してもよい。例えば、前記第1の属性情報は、前記第2のダイナミックレンジのタイプとして、前記ビデオストリームの輝度範囲が静的に表現される第1のタイプを示す。または、前記第1の属性情報は、前記第2のダイナミックレンジのタイプとして、前記ビデオストリームの輝度範囲が静的および動的に表現される第2のタイプを示す。なお、前記第2のタイプでは、前記ビデオストリームの全てのピクチャのうちの最高輝度を示す第1の補助拡張情報が前記ビデオストリームに含まれていることによって、前記ビデオストリームの輝度範囲が静的に表現され、前記ビデオストリームに含まれる1つまたは複数のピクチャからなるグループごとに、当該グループのうちの最高輝度を示す第2の補助拡張情報が前記ビデオストリームに含まれているによって、前記ビデオストリームの輝度範囲が動的に表現される。または、前記第1の属性情報は、基本ビデオストリームと、前記基本ビデオストリームの輝度を拡張するための拡張ビデオストリームである前記ビデオストリームとによって、輝度が表現される第3のタイプを、前記第2のダイナミックレンジのタイプとして示し、前記記録媒体には、さらに、前記基本ビデオストリームが記録されている。
これにより、記録媒体にどのようなタイプのビデオストリームが記録されていても、再生装置に対して、そのビデオストリームのタイプに応じた輝度を適切に表現させることができる。言い換えれば、どのような実現方法のHDRビデオストリームが記録媒体に記録されていても、再生装置に対して、その実現方法に応じた輝度を適切に表現させることができる。
また。前記管理情報ファイルは、さらに、前記ビデオストリームの最高輝度を示す第2の属性情報を含んでもよい。
これにより、再生装置に対して、ビデオストリームの輝度をより適切に表現させることができる。
なお、これらの全般包括的または具体的な態様は、装置、方法、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。
なお、本願請求項1に係る発明に最も近い実施の形態は実施の形態2であるが、理解を容易にするために、実施の形態2における情報記録媒体等の基本的な構成を説明する実施の形態1を先に説明する。
(実施の形態1)
まず、BD−ROMおよびBD−ROMを再生するBD−ROMプレーヤの基本的な構成および動作について、図1〜図30を用いて説明する。
(ディスク上の論理データ構造)
図4は、BD−ROMのデータ階層を示す図である。
図4に示すように、ディスク媒体であるBD−ROM104上には、AVデータ103と、AVデータに関する管理情報及びAV再生シーケンスなどのBD管理情報102と、インタラクティブを実現するBD再生プログラム101とが記録されている。
なお、本実施の形態では、映画などのAVコンテンツを再生するためのAVアプリケーションを主眼においてBD−ROMの説明を行うが、BD−ROMをCD−ROMやDVD−ROMの様にコンピュータ用途の記録媒体として使用することも当然のことながら可能である。
図5は、前述のBD−ROM104に記録されている論理データの構造を示す図である。BD−ROM104は、他の光ディスク、例えばDVDやCDなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有している。
また、リードインの内側にはBurst Cutting Area(BCA)と呼ばれる、ドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
論理アドレス空間には、ファイルシステム情報(ボリューム)を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、UDFやISO9660等の規格により定められたデータを管理する仕組みのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
本実施の形態の場合、BD−ROM104上のディレクトリ、ファイル構造は、ルートディレクトリ(ROOT)直下にBDVIDEOディレクトリが置かれている。このディレクトリはBD−ROMで扱うAVデータや管理情報などのデータ(図4に示すBD再生プログラム101、BD管理情報102、AVデータ103)が記録されているディレクトリである。
BDVIDEOディレクトリの下には、次の7種類のファイルが記録されている。
BD.INFO(ファイル名固定)
「BD管理情報」の一つであり、BD−ROM全体に関する情報を記録したファイルである。BD−ROMプレーヤは最初にこのファイルを読み出す。
BD.PROG(ファイル名固定)
「BD再生プログラム」の一つであり、BD−ROM全体に関わるプログラムを記録したファイルである。
XXX.PL(「XXX」は可変、拡張子「PL」は固定)
「BD管理情報」の一つであり、シナリオを記録するプレイリスト(Play List)情報を記録したファイルである。プレイリスト毎に1つのファイルを持っている。
XXX.PROG(「XXX」は可変、拡張子「PROG」は固定)
「BD再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名(「XXX」が一致する)によって識別される。
YYY.VOB(「YYY」は可変、拡張子「VOB」は固定)
「AVデータ」の一つであり、VOB(従来例で説明したVOBと同じ)を記録したファイルである。1つのVOBは1つのファイルに対応する。
YYY.VOBI(「YYY」は可変、拡張子「VOBI」は固定)
「BD管理情報」の一つであり、AVデータであるVOBに関わる管理情報を記録したファイルである。VOBとの対応はファイルボディ名(「YYY」が一致する)によって識別される。
ZZZ.PNG(「ZZZ」は可変、拡張子「PNG」は固定)
「AVデータ」の一つであり、字幕及びメニュー画面を構成するためのイメージデータであるPNG(World Wide Web Consortium(W3C)によって標準化された画像フォーマットであり「ピング」と読む。)形式のイメージファイルである。1つのPNGイメージは1つのファイルに対応する。
(プレーヤの構成)
次に、前述のBD−ROM104を再生するプレーヤの構成について図6及び図7を用いて説明する。
図6は、BD−ROM104を再生するBD−ROMプレーヤの基本的な構成の概要を示す図である。
図6に示すBD−ROMプレーヤにおいて、BD−ROM104上のデータは、光ピックアップ202を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。
BD再生プログラム(「BD.PROG」または「XXX.PROG」ファイル)はプログラム記録メモリ203に、BD管理情報(「BD.INFO」、「XXX.PL」または「YYY.VOBI」ファイル)は管理情報記録メモリ204に、AVデータ(「YYY.VOB」または「ZZZ.PNG」ファイル)はAV記録メモリ205にそれぞれ記録される。
プログラム記録メモリ203に記録されたBD再生プログラムはプログラム処理部206によって処理される。管理情報記録メモリ204に記録されたBD管理情報は管理情報処理部207によって処理される。
また、AV記録メモリ205に記録されたAVデータはプレゼンテーション処理部208によって処理される。
プログラム処理部206は、管理情報処理部207から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで、再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部207に対して変更後のプレイリストの再生命令を送ることで実現する。
プログラム処理部206は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコンからのリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
管理情報処理部207は、プログラム処理部206の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応したVOBの管理情報を解析する。更に、プレゼンテーション処理部208に再生の対象となるAVデータの再生を指示する。
また、管理情報処理部207は、プレゼンテーション処理部208から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部208にAVデータ再生の停止指示を行う。更に、プログラム処理部206に対してプログラム実行タイミングを示すイベントを生成する。
プレゼンテーション処理部208は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部207からの指示に従い、AVデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。
具体的には、映像データはビデオプレーン210に描画され、字幕データ等のイメージデータはイメージプレーン209に描画される。更に、2つのプレーンに描画された映像の合成処理が合成処理部211によって行われTVなどの表示デバイスへ出力される。
図6で示すように、BD−ROMプレーヤは図4で示したBD−ROM104に記録されているデータ構造に基づいた構成をとっている。
図7は、図6に示すプレーヤの構成を詳細化したブロック図である。図6に示す各構成部と、図7に示す各構成部との対応は以下の通りである。
AV記録メモリ205はイメージメモリ308とトラックバッファ309に対応する。プログラム処理部206はプログラムプロセッサ302とUO(User Operation)マネージャ303に対応する。管理情報処理部207はシナリオプロセッサ305とプレゼンテーションコントローラ306とに対応する。プレゼンテーション処理部208はクロック307、デマルチプレクサ310、イメージプロセッサ311、ビデオプロセッサ312とサウンドプロセッサ313とに対応する。
BD−ROM104から読み出されたVOBデータ(MPEGストリーム)はトラックバッファ309に、イメージデータ(PNG)はイメージメモリ308にそれぞれ記録される。
デマルチプレクサ310は、クロック307から得られる時刻に基づき、トラックバッファ309に記録されたVOBデータを抜き出す。更に、VOBデータに含まれる映像データをビデオプロセッサ312に音声データをサウンドプロセッサ313にそれぞれ送り込む。
ビデオプロセッサ312及びサウンドプロセッサ313はそれぞれMPEGシステム規格で定められる通りに、デコーダバッファとデコーダからそれぞれ構成されている。即ち、デマルチプレクサ310から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック307に従い個々のデコーダでデコード処理される。
イメージメモリ308に記録されたPNGデータは、次の2つの処理方法がある。PNGデータが字幕用の場合は、プレゼンテーションコントローラ306によってデコードタイミングが指示される。クロック307からの時刻情報をシナリオプロセッサ305が一旦受け、適切な字幕表示が行えるように、字幕表示時刻(開始及び終了)になればプレゼンテーションコントローラ306に対して字幕の表示、非表示の指示を出す。
プレゼンテーションコントローラ306からデコード/表示の指示を受けたイメージプロセッサ311は対応するPNGデータをイメージメモリ308から抜き出し、デコードし、イメージプレーン209に描画する。
また、PNGデータがメニュー画面用の場合は、プログラムプロセッサ302によってデコードタイミングが指示される。プログラムプロセッサ302がいつイメージのデコードを指示するかは、プログラムプロセッサ302が処理しているBDプログラムに因るものであって一概には決まらない。
イメージデータ及び映像データは、図6で説明したようにそれぞれデコード後にイメージプレーン209およびビデオプレーン210に描画され、合成処理部211によって合成出力される。
BD−ROM104から読み出された管理情報(シナリオ、AV管理情報)は、管理情報記録メモリ204に記録されるが、シナリオ情報(「BD.INFO」及び「XXX.PL」)はシナリオプロセッサ305によって読み出され処理される。また、AV管理情報(「YYY.VOBI」)はプレゼンテーションコントローラ306によって読み出され処理される。
シナリオプロセッサ305は、プレイリストの情報を解析し、プレイリストによって参照されているVOBとその再生位置をプレゼンテーションコントローラ306に指示し、プレゼンテーションコントローラ306は対象となるVOBの管理情報(「YYY.VOBI」)を解析して、対象となるVOBを読み出すようにドライブコントローラ317に指示を出す。
ドライブコントローラ317はプレゼンテーションコントローラ306の指示に従い、光ピックアップ202を移動させ、対象となるAVデータの読み出しを行う。読み出されたAVデータは、前述したようにイメージメモリ308またはトラックバッファ309に記録される。
また、シナリオプロセッサ305は、クロック307の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ302に投げる。
プログラム記録メモリ203に記録されたBDプログラム(「BD.PROG」または「XXX.PROG」)は、プログラムプロセッサ302によって実行処理される。プログラムプロセッサ302がBDプログラムを処理するのは、シナリオプロセッサ305からイベントが送られてきた場合か、UOマネージャ303からイベントが送られてきた場合である。
UOマネージャ303は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ302に送る。
このような各構成部の動作により、BD−ROMの再生がおこなわれる。
(アプリケーション空間)
図8は、BD−ROMのアプリケーション空間を示す図である。
BD−ROMのアプリケーション空間では、プレイリスト(PlayList)が一つの再生単位になっている。プレイリストはセル(Cell)の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。
プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。
一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーヤの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。BD−ROMの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の1つである。
また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図7で説明したシナリオプロセッサ305からプログラムプロセッサ302に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ302はIDによって対応付けられるイベントハンドラを実行処理する。
前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく2つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー(「上」「下」「左」「右」キー)または「決定」キーの操作によって生成されるメニュー選択のイベントである。
メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ302は、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。
グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、DVDのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行することができる。
プレイリストで静的シナリオを構成する単位であるセル(Cell)はVOB(MPEGストリーム)の全部または一部の再生区間を参照したものである。セルはVOB内の再生区間を開始、終了時刻の情報として持っている。個々のVOBと一対になっているVOB管理情報(VOBI)は、その内部にタイムマップ(Time MapまたはTM)を有しており、このタイムマップによって前述したVOBの再生、終了時刻をVOB内(即ち対象となるファイル「YYY.VOB」内)での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図14を用いて後述する。
(VOBの詳細)
図9は、本実施の形態で使用するMPEGストリーム(VOB)の構成を示す図である。図9に示すように、VOBは複数のVideo Object Unit(VOBU)によって構成されている。VOBUは、MPEGビデオストリームにおけるGroup Of Pictures(GOP)を基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。
VOBUは0.4秒から1.0秒の再生時間を持ち、通常は0.5秒の再生時間を持っている。これはMPEGのGOPの構造が通常は15フレーム/秒(NTSCの場合)であることによって導かれるものである。
VOBUは、その内部に映像データであるビデオパック(V_PCK)と、音声データであるオーディオパック(A_PCK)とを有している。各パックは1セクタで構成され、本実施の形態の場合は2kB単位で構成されている。
図10は、MPEGストリームにおけるパックの構成を示す図である。
図10に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ1つのパケットを構成する。
パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのか、映像データであるのか音声データであるのか、および、映像データまたは音声データがそれぞれ複数ストリーム分ある場合に、どのストリームのデータなのかを識別するためのID(stream_id)、並びに、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプであるDecode Time Stamp(DTS)及びPresentation Time Stamp(PTS)が記録されている。
DTSおよびPTSは必ずしも全てのパケットヘッダに記録されている訳ではなく、MPEGによって記録するルールが規定されている。ルールの詳細についてはMPEGシステム(ISO/IEC13818−1)規格書に記述されているので省略する。
パケットには更にヘッダ(パックヘッダ)が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサ310を通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプであるSystem Clock Reference(SCR)が記録されている。
(VOBのインターリーブ記録)
図11及び図12を用いてVOBファイルのインターリーブ記録について説明する。
図11は、AVデータとBD−ROMプレーヤの構成との関係を説明するための図である。
図11上段の図は、図7を用いて前述したプレーヤ構成図の一部である。図の通り、BD−ROM上のデータは、光ピックアップ202を通してVOB即ちMPEGストリームであればトラックバッファ309へ入力され、PNG即ちイメージデータであればイメージメモリ308へと入力される。
トラックバッファ309はFirst−In First−Out(FIFO)であり、入力されたVOBのデータは入力された順にデマルチプレクサ310へと送られる。この時、前述したSCRに従って個々のパックはトラックバッファ309から引き抜かれデマルチプレクサ310を介してビデオプロセッサ312またはサウンドプロセッサ313へとデータが送り届けられる。
一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ306(図7参照)によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ308から削除されるが、メニュー用のイメージデータの場合は、イメージメモリ308内にそのまま残される。
これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
図11下段の図は、BD−ROM上でのVOBファイル及びPNGファイルのインターリーブ記録を示す図である。
一般的にROM、例えばCD−ROMやDVD−ROMの場合、一連の連続再生単位となるAVデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。
しかしながら、連続再生すべきAVデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。
BD−ROMの場合も同様に、VOBファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにVOBに記録されている映像データと同期して再生されるデータがあり、VOBファイルと同様に字幕データも何らかの方法によってBD−ROMから読み出す事が必要になる。
字幕データの読み出し方法の一手段として、VOBの再生開始前に一まとめで字幕用のイメージデータ(PNGファイル)を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。
そこで、本実施の形態では、VOBファイルを幾つかのブロックに分けて、VOBファイルとイメージデータとをインターリーブ記録する方式を使用する。
図11下段はそのインターリーブ記録を説明するための図である。VOBファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリ308に格納することが可能になる。
しかしながらイメージデータを読み出している際には、VOBデータの読み込みは当然のことながら停止することになる。
図12は、上記のインターリーブ記録における問題を解決するトラックバッファ309を使ったVOBデータ連続供給モデルを説明するための図である。
既に説明したように、VOBのデータは、一旦トラックバッファ309に蓄積される。トラックバッファ309へのデータ入力レートをトラックバッファ309からのデータ出力レートより高く設定すると、BD−ROMからデータを読み出し続けている限り、トラックバッファ309のデータ蓄積量は増加をしていくことになる。
ここでトラックバッファ309への入力レートをVa、トラックバッファ309からの出力レートをVbとする。図12の上段の図に示すようにVOBの一連続記録領域が論理アドレスの“a1”から“a2”まで続くとする。また、“a2”から“a3”の間は、イメージデータが記録されていて、VOBデータの読み出しが行えない区間であるとする。
図12の下段の図は、トラックバッファ309の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ309内部に蓄積されているデータ量を示している。時刻“t1”がVOBの一連続記録領域の開始点である“a1”の読み出しを開始した時刻を示している。
この時刻以降、トラックバッファ309にはレートVa−Vbでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファ309の入出力レートの差である。時刻“t2”は一連続記録領域の終了点である“a2”のデータを読み込む時刻である。
即ち時刻“t1”から“t2”の間レートVa−Vbでトラックバッファ309内はデータ量が増加していき、時刻“t2”でのデータ蓄積量B(t2)は下記の(式1)によって求めることができる。
B(t2) = (Va−Vb)×(t2−t1) (式1)
この後、BD−ROM上のアドレス“a3”まではイメージデータが続くため、トラックバッファ309への入力は0となり、出力レートである“−Vb”でトラックバッファ309内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置“a3”まで、つまり、時刻でいう“t3”まで続く。
ここで大事なことは、時刻“t3”より前にトラックバッファ309に蓄積されているデータ量が0になると、デコーダへ供給するVOBのデータが無くなってしまい、VOBの再生がストップしてしまうことである。
しかしながら、時刻“t3”でトラックバッファ309にデータが残っている場合には、VOBの再生がストップすることなく連続して行われることを意味している。
このVOBの再生がストップすることなく連続して行われるための条件は下記の(式2)によって示すことができる。
B(t2) ≧ −Vb×(t3−t2) (式2)
即ち、(式2)を満たすようにイメージデータの配置を決めればよい事になる。
(ナビゲーションデータ構造)
図13から図19を用いて、BD−ROMに記録されたナビゲーションデータ(BD管理情報)の構造について説明をする。
図13は、VOB管理情報ファイル(“YYY.VOBI”)の内部構造を示す図である。
VOB管理情報は、当該VOBのストリーム属性情報(Attribute)とタイムマップ(TMAP)とを有している。ストリーム属性情報は、ビデオ属性(Video)、オーディオ属性(Audio#0〜Audio#m)個々に持つ構成となっている。特にオーディオストリームの場合は、VOBが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数(Number)によって、オーディオ属性のデータフィールドの数が特定される。
下記はビデオ属性(Video)の持つフィールドとそれぞれが持ち得る値の例である。
圧縮方式(Coding):
MPEG1
MPEG2
MPEG4
解像度(Resolution):
1920x1080
1280x720
720x480
720x565
アスペクト比(Aspect):
4:3
16:9
フレームレート(Framerate):
60
59.94
50
30
29.97
25
24
下記はオーディオ属性(Audio)の持つフィールドとそれぞれが持ち得る値の例である。
圧縮方式(Coding):
AC3
MPEG1
MPEG2
LPCM
チャンネル数(Ch):
1〜8
言語属性(Language):
JPN、ENG、・・・
タイムマップ(TMAP)はVOBU毎の情報を持つテーブルであって、当該VOBが有するVOBU数(Number)と各VOBU情報(VOBU#1〜VOBU#n)を持つ。
個々のVOBU情報は、VOBUの再生時間長(Duration)とVOBUのデータサイズ(Size)とを有している。
図14は、VOBU情報の詳細を説明するための図である。
広く知られているように、MPEGストリームは時間的側面とデータサイズとしての側面との2つの物理量についての側面を有している。例えば、音声の圧縮規格であるAudio Code number 3(AC3)は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は1次式によって求めることができる。
しかしながらMPEGビデオデータの場合、個々のフレームは固定の表示時間、例えばNTSCの場合、1フレームは1/29.97秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるI/P/Bピクチャによってデータサイズは大きく変わってくる。
従って、MPEGビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。
当然の事として、MPEGビデオデータを多重化しているMPEGストリーム、即ちVOBについても、時間とデータとを一般式の形で表現することは不可能である。
これに代わって、VOB内での時間とアドレスとの関係を結びつけるのがタイムマップ(TMAP)である。図14に示すように、VOBU毎にVOBU内のフレーム数と、VOBU内のパック数とをそれぞれエントリとして持つテーブルがタイムマップ(TMAP)である。
図15を使って、タイムマップ(TMAP)の使い方を説明する。
図15は、タイムマップを使ったアドレス情報取得方法を説明するための図である。
図15に示すように時刻情報(Time)が与えられた場合、まずは当該時刻がどのVOBUに属するのかを検索する。具体的には、タイムマップのVOBU毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致するVOBUが当該時刻に対応するVOBUになる。
次に、タイムマップのVOBU毎のサイズを当該VOBUの直前のVOBUまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレス(Address)になっている。
このようにして、MPEGストリームにおいて、与えられた時刻情報に対応するアドレスを得ることができる。
次に図16を使って、プレイリスト(“XXX.PL”)の内部構造を説明する。
図16は、プレイリストの構成を示す図である。
プレイリストは、セルリスト(CellList)とイベントリスト(EventList)とから構成されている。
セルリスト(CellList)は、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。
セルリスト(CellList)の中身は、セルの数(Number)と各セル情報(Cell#1〜Cell#n)である。
各セル情報(Cell#〜Cell#n)は、VOBファイル名(VOBName)、当該VOB内での有効区間開始時刻(In)及び有効区間終了時刻(Out)と、字幕テーブル(SubtitleTable)を持っている。
有効区間開始時刻(In)及び有効区間終了時刻(Out)は、それぞれ当該VOB内でのフレーム番号で表現され、前述したタイムマップ(TMAP)を使うことによって再生に必要なVOBデータのアドレスを得る事ができる。
字幕テーブル(SubtitleTable)は、当該VOBと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル(SubtitleTable)は言語数(Number)とそれに続く個々の言語ごとのテーブル(Language#1〜Language#k)とから構成されている。
各言語のテーブル(Language#1〜Language#k)は、言語情報(Language)と、表示される字幕の字幕情報数(Number)と、表示される字幕の字幕情報(Speech#1〜Speech#j)とから構成され、各字幕情報(Speech#1〜Speech#j)は対応するイメージデータファイル名(Name)、字幕表示開始時刻(In)及び字幕表示終了時刻(Out)と、字幕の表示位置(Position)とから構成されている。
イベントリスト(EventList)は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数(Number)に続いて個々のイベント(Event#1〜Event#m)とから構成され、各イベント(Event#1〜Event#m)は、イベントの種類(Type)、イベントのID(ID)、イベント生成時刻(Time)と有効期間(Duration)とから構成されている。
図17は、個々のプレイリスト毎のイベントハンドラ(時間イベントと、メニュー選択用のユーザイベント)を持つイベントハンドラテーブル(“XXX.PROG”)の構成を示す図である。
イベントハンドラテーブルは、定義されているイベントハンドラ/プログラム数(Number)と個々のイベントハンドラ/プログラム(Program#1〜Program#n)を有している。
各イベントハンドラ/プログラム(Program#1〜Program#n)内の記述は、イベントハンドラ開始の定義(<event_handler>タグ)と前述したイベントのIDと対になるイベントハンドラのID(event_handler id)を持ち、その後に当該プログラムが“function”に続く括弧“{”と“}”との間に記述される。
次に図18を用いてBD−ROM全体に関する情報(“BD.INFO”)の内部構造について説明をする。
図18は、BD−ROM全体情報であるBD.INFOの構成を示す図である。
BD−ROM全体情報は、タイトルリスト(TitleList)とグローバルイベント用のイベントリスト(EventList)とから構成されている。
タイトルリスト(TitleList)は、ディスク内のタイトル数(Number)と、これに続く各タイトル情報(Title#1〜Title#n)とから構成されている。
各タイトル情報(Title#1〜Title#n)は、タイトルに含まれるプレイリストのテーブル(PLTalble)とタイトル内のチャプターリスト(ChapterList)とを含んでいる。プレイリストのテーブル(PLTable)はタイトル内のプレイリストの数(Number)と、プレイリスト名(Name)即ちプレイリストのファイル名を有している。
チャプターリスト(ChapterList)は、当該タイトルに含まれるチャプター数(Number)と各チャプター情報(Chapter#1〜Chapter#n)とから構成され、各チャプター情報(Chapter#1〜Chapter#n)は当該チャプターが含むセルのテーブル(CellTable)を持ち、セルのテーブル(CellTable)はセル数(Number)と各セルのエントリ情報(CellEntry#1〜CellEntry#k)とから構成されている。
セルのエントリ情報(CellEntry#1〜CellEntry#k)は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
イベントリスト(EventList)は、グローバルイベントの数(Number)と各グローバルイベントの情報(Event#1〜Event#m)とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント(FirstEvent)と呼ばれ、BD−ROMがプレーヤに挿入された時、最初に実行されるイベントである。
各グローバルイベントの情報(Event#1〜Event#m)はイベントタイプ(Type)とイベントのID(ID)だけを持っている。
図19は、グローバルイベントハンドラテーブル(“BD.PROG”)の構成を示す図である。本テーブルは、図17で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。
(イベント発生のメカニズム)
図20から図22を使ってイベント発生のメカニズムについて説明する。
図20は、タイムイベントの例を示す図である。
前述したとおり、タイムイベントはプレイリスト(“XXX.PL”)のイベントリスト(EventList)で定義される。
タイムイベントとして定義されているイベント、即ちイベントタイプ(Type)が“TimeEvent”の場合、イベント生成時刻(“t1”)になった時点で、ID“Ex1”を持つタイムイベントがシナリオプロセッサ305からプログラムプロセッサ302に対して出力される。
プログラムプロセッサ302は、イベントID“Ex1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、2つのボタンイメージの描画を行うことなどが可能である。
図21は、ユーザのメニュー操作によるユーザイベントの例を示す図である。
前述したとおり、メニュー操作によるユーザイベントもプレイリスト(“XXX.PL”)のイベントリスト(EventList)で定義される。
ユーザイベントとして定義されるイベント、即ちイベントタイプ(Type)が“UserEvent”の場合、イベント生成時刻(“t1”)になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。
当該イベントは、有効規格情報(Duration)で記される期間(“T1”)レディ状態にある。
図21に示すように、ユーザによりリモコンキーの「上」「下」「左」「右」キーのいずれかのキー、または「決定」キーが押された場合、まずUOイベントがUOマネージャ303によって生成されプログラムプロセッサ302に出力される。
プログラムプロセッサ302は、シナリオプロセッサ305に対してUOイベントを流し、シナリオプロセッサ305はUOイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。
シナリオプロセッサ305は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ302に出力する。
プログラムプロセッサ302では、イベントID、例えば、図21に示す例の場合では“Ev1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト#2の再生を開始する。
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、UOイベントによってプログラムプロセッサ302に伝えられ、仮想プレーヤが持つレジスタに記録保持される。
イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。
図22は、グローバルイベントの例を示す図である。
前述のように、グローバルイベントはBD−ROM全体情報(“BD.INFO”)のイベントリスト(EventList)で定義される。
グローバルイベントとして定義されるイベント、即ちイベントタイプ(Type)が“GlobalEvent”であるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される。
ユーザによりメニューキーが押された場合、先ずUOイベントがUOマネージャ303によって生成されプログラムプロセッサ302に出力される。プログラムプロセッサ302は、シナリオプロセッサ305に対してUOイベントを流す。
シナリオプロセッサ305は、該当するグローバルイベントを生成し、プログラムプロセッサ302に送る。プログラムプロセッサ302は、イベントID“menu”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、図22に示す例の場合、プレイリスト#3の再生を開始している。
本実施の形態では、単にメニューキーと呼んでいるが、DVDを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応するIDをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。
(仮想プレーヤマシン)
図23は、プログラムプロセッサ302の機能的な構成を説明するための図である。
図23を用いてプログラムプロセッサ302の機能的な構成を説明する。
プログラムプロセッサ302は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはBD−ROMとして定義された機能モデルであって、各BD−ROMプレーヤの実装には依存しないものである。即ち、どのBD−ROMプレーヤにおいても同様の機能を実行できることを保証している。
仮想プレーヤマシンは大きく2つの機能を持っている。プログラミング関数とプレーヤ変数である。プレーヤ変数はレジスタに記憶され保持されている。
プログラミング関数は、Java(登録商標) Scriptをベースとして、以下に記す3つの機能をBD−ROM固有関数として定義している。
リンク関数:現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する。
Link(PL#,Cell#,time)
PL# : プレイリスト名
Cell# : セル番号
time : セル内での再生開始時刻
PNG描画関数:指定PNGデータをイメージプレーン209に描画する
Draw(File,X,Y)
File : PNGファイル名
X : X座標位置
Y : Y座標位置
イメージプレーンクリア関数:イメージプレーン209の指定領域をクリアする
Clear(X,Y,W,H)
X : X座標位置
Y : Y座標位置
W : X方向幅
H : Y方向幅
また、プレーヤ変数は、プレーヤの設定値等を示すシステムパラメータ(SPRM)と、一般用途として使用可能なゼネラルパラメータ(GPRM)とがある。
図24は、システムパラメータ(SPRM)の一覧を示す図である。
SPRM(0) : 言語コード
SPRM(1) : 音声ストリーム番号
SPRM(2) : 字幕ストリーム番号
SPRM(3) : アングル番号
SPRM(4) : タイトル番号
SPRM(5) : チャプター番号
SPRM(6) : プログラム番号
SPRM(7) : セル番号
SPRM(8) : 選択キー情報
SPRM(9) : ナビゲーションタイマー
SPRM(10) : 再生時刻情報
SPRM(11) : カラオケ用ミキシングモード
SPRM(12) : パレンタル用国情報
SPRM(13) : パレンタルレベル
SPRM(14) : プレーヤ設定値(ビデオ)
SPRM(15) : プレーヤ設定値(オーディオ)
SPRM(16) : 音声ストリーム用言語コード
SPRM(17) : 音声ストリーム用言語コード(拡張)
SPRM(18) : 字幕ストリーム用言語コード
SPRM(19) : 字幕ストリーム用言語コード(拡張)
SPRM(20) : プレーヤリージョンコード
SPRM(21) : 予備
SPRM(22) : 予備
SPRM(23) : 再生状態
SPRM(24) : 予備
SPRM(25) : 予備
SPRM(26) : 予備
SPRM(27) : 予備
SPRM(28) : 予備
SPRM(29) : 予備
SPRM(30) : 予備
SPRM(31) : 予備
なお、本実施の形態では、仮想プレーヤのプログラミング関数をJava(登録商標) Scriptベースとしたが、Java(登録商標) Scriptではなく、UNIX(登録商標) OSなどで使われているB−Shellや、Perl Scriptなど他のプログラミング関数であってもよい。言い換えれば、本発明におけるプログラム言語はJava(登録商標) Scriptに限定されるものでは無い。
(プログラムの例)
図25及び図26は、イベントハンドラにおけるプログラムの例を示す図である。
図25は、2つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。
セル(PlayList#1.Cell#1)先頭でタイムイベントを使って図25左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つGPRM(0)に“1”がセットされている。GPRM(0)は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン[1]が選択されている状態を初期値として持たされている。
次に、PNGの描画を描画関数である“Draw”を使ってボタン[1]、ボタン[2]それぞれについて行っている。ボタン[1]は、座標(10、200)を起点(左上端)としてPNGイメージ“1black.png”を描画している。ボタン[2]は、座標(330,200)を起点(左上端)としてPNGイメージ“2white.png”を描画している。
また、本セル最後ではタイムイベントを使って図25右側のプログラムが実行される。ここでは、Link関数を使って当該セルの先頭から再度再生するように指定している。
図26は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれている。ユーザによりリモコンキーが押された場合、図21を用いて説明したように、ユーザイベントが生成され、図26のイベントハンドラが起動されることになる。
本イベントハンドラでは、選択ボタンを識別しているGPRM(0)の値と、選択されたリモコンキーを識別するSPRM(8)を使って以下のように分岐処理を行っている。
条件1)ボタン[1]が選択されている、かつ、選択キーが「右」キーの場合
GPRM(0)を2に再設定して、選択状態にあるボタンを右のボタン[2]に変更する。
ボタン[1]、ボタン[2]のイメージをそれぞれ書き換える。
条件2)選択キーが「決定(OK)」の場合で、ボタン[1]が選択されている場合
プレイリスト#2の再生を開始する。
条件3)選択キーが「決定(OK)」の場合で、ボタン[2]が選択されている場合
プレイリスト#3の再生を開始する。
図26に示すプログラムは、上記のように解釈され実行される。
(プレーヤ処理フロー)
図27から図30を用いてプレーヤでの処理の流れを説明する。
図27は、BD−ROMプレーヤにおけるAVデータ再生の基本処理の流れを示すフロー図である。
BD−ROMが挿入されると(S101)、BD−ROMプレーヤは“BD.INFO”の読み込みと解析(S102)、および、“BD.PROG”の読み込み(S103)を実行する。“BD.INFO”及び“BD.PROG”は共に管理情報記録メモリ204に一旦格納され、シナリオプロセッサ305によって解析される。
続いて、シナリオプロセッサ305は、“BD.INFO”ファイル内のファーストイベント(FirstEvent)情報に従い、最初のイベントを生成する(S104)。生成されたファーストイベントは、プログラムプロセッサ302で受け取られ、当該イベントに対応するイベントハンドラを実行処理する(S105)。
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる(S201でNo)。
UOマネージャ303は、ユーザからのリモコン操作を受け付けると(S201でYes)、プログラムプロセッサ302に対するUOイベントを生成する(S202)。
プログラムプロセッサ302は、UOイベントがメニューキーによるものであるかを判別し(S203)、メニューキーの場合(S203でYes)は、シナリオプロセッサ305にUOイベントを流し、シナリオプロセッサ305がユーザイベントを生成する(S204)。プログラムプロセッサ302は生成されたユーザイベントに対応するイベントハンドラを実行処理する(S205)。
図28は、BD−ROMプレーヤにおけるプレイリスト再生開始からVOB再生終了までの処理の流れを示すフロー図である。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される(S301)。シナリオプロセッサ305は、再生対象のプレイリスト再生に必要な情報として、プレイリスト“XXX.PL”の読み込みと解析(S302)、および、プレイリストに対応するプログラム情報“XXX.PROG”の読み込みを行う(S303)。
続いてシナリオプロセッサ305は、プレイリストに登録されているセル情報に基づいてセルの再生を開始する(S304)。セル再生は、シナリオプロセッサからプレゼンテーションコントローラ306に対して要求が出される事を意味し、プレゼンテーションコントローラ306はAVデータ再生を開始する(S305)。
AVデータの再生が開始されると、プレゼンテーションコントローラ306は、再生するセルに対応するVOBの情報ファイル“XXX.VOBI”を読み込み(S402)、解析する。プレゼンテーションコントローラ306は、タイムマップを使って再生開始するVOBUとそのアドレスを特定し、ドライブコントローラ317に読み出しアドレスを指示する。ドライブコントローラ317は対象となるVOBデータ“YYY.VOB”を読み出す(S403)。
読み出されたVOBデータはデコーダに送られ再生が開始される(S404)。VOB再生は、当該VOBの再生区間が終了するまで続けられ(S405)、終了すると次のセルが存在する場合(S406でYes)、Cellの再生(S304)へ移行する。また、次のセルが無い場合(S406でNo)は、再生に係る処理が終了する。
図29は、AVデータ再生開始後からのイベント処理の流れを示すフロー図である。
図29の(A)は、BD−ROMプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。
なお、BD−ROMプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。
BD−ROMプレーヤにおいてプレイリスト再生の再生が開始されると(S501)、プレイリスト再生が終了していないことが確認され(S502でNo)、シナリオプロセッサ305は、タイムイベント発生時刻になったかを確認する(S503)。
タイムイベント発生時刻になっている場合(S503でYes)には、シナリオプロセッサ305はタイムイベントを生成する(S504)。プログラムプロセッサ302はタイムイベントを受け取り、イベントハンドラを実行処理する(S505)。
また、タイムイベント発生時刻になっていない場合(S503でNo)、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認(S502)以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると(S502でYes)、タイムイベント系の処理は強制的に終了する。
図29の(B)は、BD−ROMプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。
BD−ROMプレーヤにおいてプレイリストの再生が開始されると(S601)、プレイリスト再生が終了していないことが確認され(S602でNo)、UOマネージャ303は、UOの受け付けがあったかを確認する。
UOの受け付けがあった場合(S603でYes)、UOマネージャ303はUOイベントを生成する(S604)。プログラムプロセッサ302はUOイベントを受け取り、そのUOイベントがメニューコールであるかを確認する。
メニューコールであった場合(S605でYes)、プログラムプロセッサ302はシナリオプロセッサ305にイベントを生成させ(S607)、プログラムプロセッサ302はイベントハンドラを実行処理する(S608)。
また、UOイベントがメニューコールで無いと判断された場合(S605でNo)、UOイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ305が判断し、有効期間内である場合(S606でYes)には、シナリオプロセッサ305がユーザイベントを生成し(S607)、プログラムプロセッサ302が対象のイベントハンドラを実行処理する(S608)。
また、UO受付が無い場合(S603でNo)、現在時刻がユーザイベント有効期間内にない場合(S606でNo)、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認(S602)以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると(S602でYes)、ユーザイベント系の処理は強制的に終了する。
図30は、BD−ROMプレーヤにおける字幕データの処理の流れを示すフロー図である。
BD−ROMプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認され(S702でNo)、シナリオプロセッサ305は、字幕表示開始時刻になったかを確認する。字幕表示開始時刻になっている場合(S703でYes)、シナリオプロセッサ305はプレゼンテーションコントローラ306に字幕描画を指示し、プレゼンテーションコントローラ306はイメージプロセッサ311に字幕描画を指示する。イメージプロセッサ311は、その指示に従い字幕をイメージプレーン209に字幕を描画する(S704)。
また、字幕表示開始時刻になっていない場合(S703でNo)、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合(S705でYes)、プレゼンテーションコントローラ306がイメージプロセッサ311に字幕消去指示を行う。
イメージプロセッサ311は、その指示に従い描画されている字幕をイメージプレーン209から消去する(S706)。
また、イメージプロセッサ311による字幕描画(S704)が終了した場合、イメージプロセッサ311による字幕消去(S706)のが終了した場合、および、字幕表示終了時刻でないと判断(S705でNo)された場合、プレイリスト再生の終了確認(S702)以降の処理を繰り返す。
また、プレイリスト再生が終了したことが確認されると(S702でYes)、字幕表示系の処理は強制的に終了する。
以上の動作により、BD−ROMプレーヤは、ユーザの指示またはBD−ROMに記録されているBD管理情報等に基づき、BD−ROMの再生に係る基本的な処理を行う。
(実施の形態2)
次に本発明の実施の形態2について説明する。
実施の形態2は、BDでの高輝度(HDR:High Dynamic Range)映像情報の記録または再生に関する内容である。実施の形態2は、基本的には実施の形態1に基づくため、実施の形態2において拡張されている部分または異なる部分を中心に、以下、説明する。
図31は、MPEG−4 AVC(別名H.264)、もしくはHEVC(別名H.265)のような映像符号化方式を用いて高輝度化メタデータを送る方法を説明する図である。ここでは、MPEG−2 Videoでのランダムアクセス性を高めるために用いられたGOP(Group Of Pictures)と同等のピクチャ参照構成から成る単位を、MPEG−4 AVC、もしくはHEVCでのGOPとして、複数のピクチャをグループ化して符号化している。
図31の(a)は、GOP先頭のピクチャ(first access unit)における複数のNALユニットの符号化順番を示している。GOP先頭のピクチャでは、1つのAU delimiter、1つのSPS、1つ以上のPPS、0個または複数のSEI message、ピクチャを構成する1つ以上のSliceのそれぞれのNALユニットが続いた後、必要に応じてFiller data、End of sequence、End of streamのそれぞれのNALユニットが続く。
SEI message(SEI(s))では、必要に応じて、Buffering period SEI messageに続けて、他の幾つかのSEI messageが続く。例えば、(1)このGOP内のピクチャの参照関係を示したUser data unregistered SEI message(GOP)、(2)このピクチャのClosed Captioning情報を持つUser data unregistered SEI message(CC)、(3)このビデオシーケンス(VOB)内の全てのピクチャの中での最大輝度または最小輝度などの輝度範囲を示す基本的かつ静的な高輝度化メタデータを含むUser data unregistered SEI message(HDRb)、(4)このピクチャもしくはGOP内の全てのピクチャの中での最大輝度または最小輝度などの輝度範囲を示すように、SEI message(HDRb)よりも詳細で動的な高輝度化メタデータを含むUser data unregistered SEI message(HDRe)、などの幾つかのSEI messageが、この順番で符号化されている。
上述のSEI message(HDRb)またはSEI message(HDRe)は、映像情報と一緒に伝送される。これは、マスタリングの際に利用された輝度に関する情報を伝送し、映像情報をデコードした後に得られる各ピクセルごとの輝度値(Y)が、実際にはどの程度の明るさ(cd/m^2)に相当するのかなどの情報を与えるためである。
例えば、ビデオをデコードした結果、輝度値(Y)が1000の値を持つピクセルのマスタリング時の輝度は5000cd/m^2だった、といったピクセルの持つ輝度とマスタリング時の輝度との相関情報などが、上述のSEI message(HDRb)またはSEI message(HDRe)に含まれる。また、プレーヤに接続したTVが表現できる最高輝度(cd/m^2)が取得された場合、ピクチャ全体の輝度方向のダイナミックレンジを変更するための情報を、上述のSEI message(HDRb)またはSEI message(HDRe)に持たせてもよい。
SEI message(HDRb)は、HDRビデオシーケンスであることを示すためにピクチャ単位もしくはGOP単位で伝送されるSEI messageであり、ビデオシーケンス(VOB)全体の静的な輝度に関する情報を伝送している。ここで言うHDRビデオシーケンスとは、SEI message(HDRb)が記録されているビデオシーケンスのこととする。
より詳細でかつ動的な輝度に関する情報を伝送するSEI message(HDRe)は、HDRビデオシーケンスに記録されている必要はなく、HDRビデオシーケンス中に1つも存在しなくてもよい。また、SEI message(HDRe)は、存在する場合には、必ずSEI message(HDRb)の直後に符号化されるSEI messageであり、ピクチャ単位もしくはGOP単位で輝度に関する情報を伝送している。
図31の(b)は、GOP先頭のピクチャではないピクチャ(non−first access unit)における複数のNALユニットの符号化順番を示している。GOP先頭でないピクチャでは、1つのAU delimiter、0個または1個のPPS、0個または複数のSEI message、ピクチャを構成する1つ以上のSliceのそれぞれのNALユニットが続く。さらにその後に、必要に応じて、Filler data、End of sequence、End of streamのそれぞれのNALユニットが続く。
SEI message(HDRb)またはSEI message(HDRe)は、それぞれ上記の情報を格納しており、この図31に示す方法では、ピクチャごとに付与されている。GOP単位で輝度に関する情報を伝送する場合には、SEI message(HDRb)およびSEI message(HDRe)はともにGOP先頭のピクチャのみに付与され、GOP先頭でないピクチャには一切付与されない。
図32は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する方法を説明する図である。なお、本実施の形態において、シーケンスは、ストリームと同義であってもよく、ストリームの一部であってもよい。1ピクチャ(1フレームまたは1 video access unit)を1PESパケットに格納して、HDRビデオストリームをPES化した後、PID=Xの各TSパケットのペイロードに、PESパケットにおけるデータが分割されて順番に格納される。
図32に示す方法の場合、同じPID(PID=X)の各TSパケットに、stream_id=0xE1のPESパケットとされる、SEI message(HDRe)まで含むHDRビデオシーケンスが、分割されて順番に格納される。なお、HDMI(登録商標)でHDRビデオシーケンスを出力する際に、図32に示す方法のように、SEI message(HDRe)の情報が伝送されると、ビデオシーケンス全体からSEI message(HDRe)を検索するための処理が重くなる場合がある。
図33は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する別の方法を説明する図である。1ピクチャ(1フレームまたは1 video access unit)を1PESパケットに格納して、HDRビデオストリームをPES化した後、PID=XとZのそれぞれのTSパケットのペイロードに、PESパケットにおけるデータが分割されて順番に格納される。
図33に示す方法の場合、PID=XのTSパケットに、stream_id=0xE1のPESパケットとしてHDRビデオシーケンスが格納され、SEI message(HDRe)のみがPID=ZのTSパケットに単独で格納されている。HDMI(登録商標)でHDRビデオを出力する際に、図33に示す方法のように、SEI message(HDRe)の情報が伝送されると、PID=ZのTSパケットにSEI message(HDRe)のみが格納されている。したがって、SEI message(HDRe)を検索するための処理は軽い。
PID=XのTSパケットで伝送されるHDRビデオシーケンスのみをデコードするのは簡単である。しかし、SEI message(HDRe)までを含んだ更に高輝度な映像再生を行うためには、PID=XとZのそれぞれのTSパケットを同一のTBバッファ(MPEG−2 SystemのT−STDモデルにて使われる前段バッファ)に伝送する追加処理が必要となる。
図34は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する別の方法を説明する図である。1ピクチャ(1フレームまたは1 video access unit)を分割して3つのPESパケットのそれぞれに格納して、ビデオストリームをPES化する。その後、3つのPESパケットのそれぞれは、必要に応じて分割され、PID=Xの各TSパケットのペイロードに順番に格納される。
図34に示す方法の場合、PID=XのTSパケットに、stream_id=0xE1の2つのPESパケットとしてHDRビデオシーケンスが格納される。そして、SEI message(HDRe)のみが、同じstream_id=0xE1ながらPES_priority=0のPESパケットとして、同じPID=XのTSパケットに単独で格納されている。
HDMI(登録商標)でHDRビデオを出力する際に、図34に示す方法のように、SEI message(HDRe)の情報が伝送されると、PID=Xの各TSパケットから、stream_id=0xE1でPES_priority=0のPESパケットが検索される。したがって、SEI message(HDRe)を検索するための処理は、図33に示す方法のようには軽くはない。
しかし、PID=XのTSパケットで伝送されるHDRビデオシーケンスのみをデコードするのも、HDRビデオシーケンスだけでなくSEI message(HDRe)も含めてデコードするのも大きな差異はなく、図34に示す方法は実現可能である。
尚、PES_priorityの値は必ずしもこの組み合わせでなくても良く、SEI message(HDRe)を格納するPESパケットだけがPES_priority=1を取るようにしていても同様の効果を発揮することができる。
図35は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する別の方法を説明する図である。図34に示す方法との違いは、図35に示す方法では、SEI message(HDRe)を含むPESパケットを格納するTSパケットのtransport_priorityが0である点である。
HDMI(登録商標)でHDRビデオを出力する際に、図35に示す方法のように、SEI message(HDRe)の情報が伝送されると、PID=Xでtransport_priority=0のTSパケットからSEI message(HDRe)が解析される。したがって、SEI message(HDRe)を検索するため処理量は、図33に示す方法とほぼ同じように軽く、図35に示す方法を実現することは可能である。
また、この場合には、HDRビデオシーケンスのみをデコードするのも、HDRビデオシーケンスだけでなくSEI message(HDRe)も含めてデコードするのも、T−STDモデル上では差異はなく、図35に示す方法を実現することができる。例えば、TSデコーダのPIDデマルチプレクサは、transport_priorityの値にも基づいてストリームを分離する。これにより、SEI message(HDRe)には対応せず、SEI message(HDRb)までの情報を用いて高輝度化するデコーダは、上述のPIDデマルチプレクサによって、SEI message(HDRe)を含むTSパケットを容易に破棄することが可能である。
尚、transport_priorityの値は必ずしもこの組み合わせでなくても良く、SEI message(HDRe)を格納するTSパケットだけがtransport_priority=1を取るようにしていても同様の効果を発揮することができる。
図36は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する別の方法を説明する図である。この図36に示す方法では、図33に示す方法のように、PIDを2種類使い、図34または図35に示す方法のように、PESパケットを構成している。この図36に示す方法は、図33に示す方法と同じような利点と欠点を併せ持つ。
図37は、SEI message(HDRe)まで含むHDRビデオストリームをMPEG−2 TSで多重化する別の方法を説明する図である。この図37に示す方法では、SEI message(HDRe)を、SEI message(HDRb)などが格納されているPESパケットとは別のPESパケットである、PES_priority=0のPESパケットに格納する。そして、スライスNALユニットを格納し終わった後に、PES_priority=0のPESパケットを、PID=XのTSパケットとは別のPID=ZのTSパケットにて多重化している。SEI message(HDRe)の多重化位置はピクチャデータ直後となっている。したがって、図37に示す方法では、SEI message(HDRb)までのHDRビデオシーケンスが1つのPESパケットに格納されている。この点を除き、図37に示す方法は、図33に示す方法と同じような利点と欠点を併せ持つ。
図38は、SEI message(HDRe)の代わりに、HDRビデオシーケンスとは別のビデオシーケンスである拡張ビデオシーケンスをMPEG−2 TSで多重化する方法を説明する図である。この図38に示す方法では、SEI message(HDRe)で高輝度拡張メタデータを伝送するのではなく、拡張ビデオシーケンス(Enhancement layer video sequence)を、HDRビデオシーケンス(Base layer video sequence with user data unregistered SEI message(HDRb))に対する拡張映像情報として伝送する。
例えば、上記HDRビデオシーケンスに含まれるBase frame PES#nの基本ピクチャに対して、拡張ビデオシーケンスに含まれるEnhancement frame PES#nの拡張ピクチャを加える。これにより、HDRビデオシーケンスの高輝度拡張を、SEI messageよりも更に多くのデータを用いながら、より正確に行うことが可能になる。ここで、対応するピクチャ同士は同じPTSを持つようにして、ピクチャ間の相関が示されていても良い。例えば、「基本ピクチャのPTS#b1」=「拡張ピクチャのPTS#e1」を示す相関が示される。
上述の基本ビデオシーケンスと拡張ビデオシーケンスとは、夫々全く異なる2本のビデオシーケンスとして異なるPIDで異なるPESパケットでMPEG−2 TSへ多重化される。
PMTパケットには、基本ビデオシーケンスと拡張ビデオシーケンスとのペアを正しく指定するために、descriptor()を用いてそのペアを表現しても良い。例えば、この図38に示す方法では、PMTパケットの中に、HDR_pairing_descriptor()が記述される。HDR_pairing_descriptor()には、このMPEG−2 TS内のペア数(number_of_HDR_pairs)と、ペアごとの基本ビデオシーケンスと拡張ビデオシーケンスとが用いるPID値とが含まれる。基本ビデオシーケンスが用いるPID値は、base_layer_video_sequence_PIDによって示され、拡張ビデオシーケンスが用いるPID値は、enhancement_layer_video_sequence_PIDによって示される。このようなHDR_pairing_descriptor()が記述されることで、正しいペアの組み合わせを示すことができる。
図39は、ビデオストリーム(YYY.VOB)の管理情報であるYYY.VOBIにてHDRビデオストリームを管理する場合の属性情報を説明する図である。
YYY.VOBに含まれるビデオストリームの本数(V_Number)だけ、Videoの属性が、YYY.VOBIの「Attribute」に、ビデオ属性情報として記録される。1本のビデオストリームのビデオ属性情報には、符号化方式(Coding)、空間解像度(Resolution)、アスペクト比(Aspect)、およびフレームレート(Framerate)だけでなく、以下の属性情報が含まれている。
属性情報であるis_HDRは、この属性情報に対応するビデオストリームが、HDRビデオストリームなのか、SDR(Standard Dynamic Range)ビデオストリームなのかを識別する情報である。ここで、is_HDRに、HDRビデオストリームであると記載された場合(つまり、is_HDR=1bの場合)には、以下のHDRに関連する属性情報が続いて記述される。
属性情報であるHDR_typeは、この属性情報に対応するビデオストリームの種別、つまりHDRの種別を示す。HDR_typeに含まれる7ビットのうち、最下位の1ビット(b6)が1bの場合は、HDR_typeは、そのビデオストリームが、SEI message(HDRb)を含むHDRビデオストリームであることを示す。また、1つ上位の1ビット(b5)が1bの場合は、HDR_typeは、そのビデオストリームが、SEI message(HDRe)を含む輝度拡張されたHDRビデオストリームであることを示す。また、さらに1つ上位の1ビット(b4)が1bの場合は、HDR_typeは、そのビデオストリームが、SEI message(HDRb)を含む基本ビデオストリームに対する拡張ビデオシーケンスであることを示す。
属性情報であるHDR_base_streamは、この属性情報に対応するビデオストリームが、SEI message(HDRe)の輝度拡張されたHDRビデオストリームか、拡張ビデオシーケンスである場合に、基本となるSEI message(HDRb)を含むHDRビデオストリーム(基本ビデオストリーム)を特定する情報である。例えば、その情報は、基本となるSEI message(HDRb)を含むHDRビデオストリーム(基本ビデオストリーム)のTSパケットのPID値を示す。これにより、属性情報に対応するビデオストリームとペアとなる基本ビデオストリームがどのビデオストリームなのかを、ストリームを解析することなく知り、TSデコーダのPIDデマルチプレクサなどの設定を適切に行うことができる。
属性情報であるMax_luminanceは、その属性情報に対応する、ビデオストリーム(YYY.VOB)内のHDRビデオストリームの、最高輝度(Max_luminance)のピクセル輝度値(Y)を表現し、さらに、その実際の輝度をcd/m^2の単位で表現する。
属性情報であるMin_luminanceは、その属性情報に対応する、ビデオストリーム(YYY.VOB)内のHDRビデオストリームの、最低輝度(Min_luminance)のピクセル輝度値(Y)を表現し、さらに、その実際の輝度をcd/m^2の単位で表現する。
再生装置であるプレーヤは、このビデオ属性情報を解釈することで、再生しようとしているビデオストリームがHDRなのか否かを判定することができる。さらに、プレーヤは、ビデオストリームがHDRであれば、そのHDRはどのようなタイプか、つまり、HDRビデオストリームはどのような符号化方式のHDRビデオストリームなのかを、判定することができる。また、プレーヤは、再生しようとしているビデオストリームに対応する基本HDRビデオストリームの識別情報(PID)と、最高輝度および最低輝度などの輝度範囲を示す情報とを得ることができる。これにより、適切な輝度制御処理を行いながらHDRビデオを再生することができる。
図40は、本実施の形態にけるHDRビデオストリームのデコーダモデルを説明する図である。
SEI message(HDRb)を含むHDRビデオストリームは、基本デコーダ(Base Dec)401にてデコードされる。そして、そのHDRビデオストリームのデコードによって生成された高輝度映像情報は、基本プレーン(Base plane(HDRb))403に展開される。ここで、SEI message(HDRb)に含まれる基本的な輝度情報(コンテンツ全体での最高/最低輝度値によって定義される輝度範囲)などは、その高輝度映像情報と一緒に伝送されて、HDMI(登録商標)などの外部映像出力I/Fへと出力される。
SEI message(HDRe)に対応したデコーダシステム400は、基本プレーン(Base plane(HDRb))403の高輝度映像情報に対して、SEI message(HDRe)の輝度拡張情報を加えて、HDReプレーン405に拡張高輝度映像情報を展開する。このSEI message(HDRe)までを加えた拡張高輝度映像情報は、SEI message(HDRe)に含まれる追加の輝度情報(シーン単位での最高の輝度値と最低の輝度値によって定義される輝度範囲)などと一緒に、HDMI(登録商標)などの外部映像出力I/Fへと出力される。
上述の拡張ビデオシーケンスに対応したデコーダシステム400は、拡張ビデオシーケンスを拡張デコーダ(Enh. Decd)402にてデコードする。そして、そのデコードによって生成された拡張映像情報は、拡張プレーン(Enh. plane)404に展開される。デコーダシステム400は、この拡張映像情報を、基本プレーン(Base plane(HDRb))403の高輝度映像情報と、同じPTSを持つ映像同士で合成する。この合成によって得られた拡張高輝度映像情報は、Base+Enh.プレーン406に展開される。デコーダシステム400は、この拡張高輝度映像情報を、SEI message(HDRb)にて伝送される基本的な輝度情報、または拡張ビデオシーケンス内に格納された輝度拡張情報などと一緒に、HDMI(登録商標)などの外部映像出力I/Fへと出力する。
尚、上記の説明は一例に過ぎず、当該技術者にとっては、様々な応用が適用できる。
図41Aは、本実施の形態における再生装置の構成の一例を示すブロック図である。
本実施の形態における再生装置100は、符号化された映像情報であるビデオストリームを例えば上述のBDなどの記録媒体200から読み出して再生する装置であって、属性読み出し部110と、復号部120と、出力部130とを備える。
属性読み出し部110は、そのビデオストリームの輝度のダイナミックレンジが、第1のダイナミックレンジか第2のダイナミックレンジかを示す第1の属性情報を、そのビデオストリームに対応付けて記録媒体200に記録されている管理情報ファイルから読み出す。例えば、第1のダイナミックレンジはSDRであり、第2のダイナミックレンジは、そのSDRよりも広いダイナミックレンジであるHDRである。また、管理情報ファイルは、例えば上述のVOBIのファイルであって、その管理情報ファイルに含まれる第1の属性情報は、is_HDRおよびHDR_typeからなる情報である。第1の属性情報に含まれるis_HDRは、そのビデオストリームがSDRかHDRかを示す。
復号部120は、そのビデオストリームを記録媒体200から読み出して復号することにより復号映像情報を生成する。この復号部120は、例えば、図40の基本デコーダ401および拡張デコーダ402などを含む。
出力部130は、読み出された第1の属性情報が第2のダイナミックレンジを示す場合、第2のダイナミックレンジに応じたビデオストリームの最高輝度を示す最高輝度情報とともに、生成された復号映像情報を出力する。この出力部130は、例えば、図40に示す構成要素のうち、基本デコーダ401および拡張デコーダ402以外の構成要素を含む。また、ビデオストリームの最高輝度を示す最高輝度情報は、上述のSEI message(HDRb)に含まれる情報、あるいはSEI message(HDRb)およびSEI message(HDRe)に含まれる情報である。
これにより、本実施の形態における再生装置100は、記録媒体200に記録されているビデオストリームの種別(特に、ダイナミックレンジ)に応じた輝度を適切に表現することができる。
また、第1の属性情報は、第2のダイナミックレンジを示す場合、さらに、第2のダイナミックレンジのタイプを示す。つまり、第1の属性情報のうちのHDR_typeは、HDRのタイプを示す。このような場合、出力部130は、第2のダイナミックレンジのタイプに応じた最高輝度情報と復号映像情報とを出力する。
具体的には、第1の属性情報によって示されるタイプが、ビデオストリームの輝度範囲が静的に表現されるタイプ(HDRd)である場合、出力部130は、静的に最高輝度を示す最高輝度情報と復号映像情報とを出力する。ここで、その最高輝度情報は、ビデオストリームの全てのピクチャのうちの最高輝度によって定義される輝度範囲を示すことによって、静的に輝度範囲を示す。つまり、出力部130は、上述のSEI message(HDRb)に含まれる情報を最高輝度情報として出力する。
または、第1の属性情報によって示されるタイプが、ビデオストリームの輝度範囲が静的および動的に表現されるタイプ(HDReを含むタイプ)である場合、出力部130は、静的および動的に最高輝度を示す最高輝度情報と復号映像情報とを出力する。ここで、最高輝度情報は、ビデオストリームに含まれる1つまたは複数のピクチャからなるグループごとに、当該グループのうちの最高輝度によって定義される輝度範囲を示すことによって、動的に輝度範囲を示す。複数のピクチャからなるグループは例えばGOPである。つまり、出力部130は、上述のSEI message(HDRb)およびSEI message(HDRe)に含まれる情報を最高輝度情報として出力する。
また、第1の属性情報によって示されるタイプには、基本ビデオストリームと、その基本ビデオストリームの輝度を拡張するための拡張ビデオストリームとによって、輝度が表現されるタイプがある。このタイプは、上述の拡張ビデオシーケンスを用いるタイプである。第1の属性情報がこのタイプを示す場合、復号部120は、上述のビデオストリームを拡張ビデオストリームとして復号することによって復号映像情報を生成する。さらに、復号部120は、基本ビデオストリームを記録媒体200から読み出して復号することによって基本映像情報を生成する。この場合、出力部130は、最高輝度情報と、生成された基本映像情報を用いて画像処理(例えば合成)された復号映像情報とを出力する。また、このときに出力される最高輝度情報は、上述のSEI message(HDRb)に含まれる情報である。
これにより、記録媒体200にどのようなタイプのHDRビデオストリームが記録されていても、そのHDRビデオストリームのタイプに応じた輝度を適切に表現することができる。
また、属性読み出し部110は、さらに、ビデオストリームの最高輝度を示す第2の属性情報を、管理情報ファイルから読み出す。第2の属性情報は、例えば上述のMax_luminanceである。このとき、出力部130は、さらに、その第2の属性情報を含む最高輝度情報を出力する。
これにより、ビデオストリームの輝度をより適切に表現することができる。
また、本実施の形態における記録媒体200には、上述のビデオストリームと、上述の各属性情報を含む管理情報ファイルとが記録されている。また、ビデオストリームのタイプに応じて基本ビデオストリームが記録されている。
これにより、本実施の形態における記録媒体200は、再生装置に対して、ビデオストリームの種別に応じた輝度を適切に表現させることができる。
また、HDRビデオストリームには様々な実現方法がありながら、従来では、これら複数の実現方法のHDRビデオストリームを効率的に1つの記録媒体に記録および管理することができなかった。しかし、本実施の形態では、複数のHDRビデオストリームごとに、上述の実現方法を示す属性情報が記録されているため、単一の記録媒体に複数の実現方法のHDRビデオストリームを好適に記録することができる。すなわち、異なる実現方法のHDRビデオストリームを同一のメディア上に効率的に記録および管理することが可能である。さらに、1枚の記録媒体から、TVの高輝度映像表示能力に応じてビデオストリームを選択することもできる。
図41Bは、本実施の形態における再生方法の一例を示すフローチャートである。
本実施の形態における再生方法は、符号化された映像情報であるビデオストリームを記録媒体200から読み出して再生する方法であって、ステップS110、ステップS120およびステップS130を含む。
ステップS110では、ビデオストリームの輝度のダイナミックレンジが、第1のダイナミックレンジか、第1のダイナミックレンジよりも広い第2のダイナミックレンジかを示す属性情報を、そのビデオストリームに対応付けて記録媒体200に記録されている管理情報ファイルから読み出す。
ステップS120では、そのビデオストリームを記録媒体200から読み出して復号することにより復号映像情報を生成する。
ステップS130では、読み出された属性情報が第2のダイナミックレンジ(つまりHDR)を示す場合、第2のダイナミックレンジに応じたビデオストリームの最高輝度を示す最高輝度情報とともに、復号映像情報を出力する。
これにより、本実施の形態における再生方法では、記録媒体200に記録されているビデオストリームの種別(特に、ダイナミックレンジ)に応じた輝度を適切に表現することができる。
なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の再生装置100などを実現するソフトウェアは、例えば図41Bに示すフローチャートに含まれる各ステップをコンピュータに実行させるプログラムである。
以上、一つまたは複数の態様に係る再生装置および再生方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の範囲に含まれてもよい。