JP2006073127A - ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 - Google Patents
ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 Download PDFInfo
- Publication number
- JP2006073127A JP2006073127A JP2004257237A JP2004257237A JP2006073127A JP 2006073127 A JP2006073127 A JP 2006073127A JP 2004257237 A JP2004257237 A JP 2004257237A JP 2004257237 A JP2004257237 A JP 2004257237A JP 2006073127 A JP2006073127 A JP 2006073127A
- Authority
- JP
- Japan
- Prior art keywords
- information
- event
- data
- stream
- playback
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
Abstract
【課題】符号化自由度が高い映像符号化方式を用いる場合には、特殊再生や、マルチアングルなどの再生時に、適切に復号可能か否かストリームを解析するしかなかった。
【解決手段】それ以降の符号化順を持つピクチャが復号できることを保証できるピクチャを規定し、このピクチャの位置を管理することで、適切に再生制御を行うことが可能となる。
【選択図】図33
【解決手段】それ以降の符号化順を持つピクチャが復号できることを保証できるピクチャを規定し、このピクチャの位置を管理することで、適切に再生制御を行うことが可能となる。
【選択図】図33
Description
本発明は適切なランダムアクセス性を確保したパッケージメディアに関するものである。
従来の技術である、DVD−Videoディスク(以下単にDVDと呼ぶ)について説明する。
図1は、DVDの構造を示した図である。図1の下段に示すように、DVDディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられ、論理アドレス空間の先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
ファイルシステムとは、ISO9660やUDF(Universal Disc Format)のことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。日常使っているPC(パーソナルコンピュータ)の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。
DVDの場合、UDFおよびISO9660両方を使用しており(両方を合わせて「UDFブリッジ」と呼ぶ事がある)、UDFまたはISO9660どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。勿論、書き換え型のDVDディスクであるDVD−RAM/R/RWでは、これらファイルシステムを介し、物理的にデータの読み、書き、削除が可能である。
DVD上に記録されたデータは、UDFブリッジを通して、図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では一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
VTS_01_0.IFO ビデオタイトルセット#1再生制御情報ファイル
VTS_01_0.VOB ビデオタイトルセット#1ストリームファイル
.....
拡張子として2つの種類が規定されており、「IFO」は再生制御情報が記録されたファイルであって、「VOB」はAVデータであるMPEGストリームが記録されたファイルである。再生制御情報とは、DVDで採用されたインタラクティビティ(ユーザの操作に応じて再生を動的に変化させる技術)を実現するための情報や、メタデータのようなタイトルやAVストリームに付属する情報などのことである。また、DVDでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
再生制御情報ファイルは、ディスク全体を管理する「VIDEO_TS.IFO」と、個々のビデオタイトルセット(DVDでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を1枚のディスクに記録することが可能である。)毎の再生制御情報である「VTS_01_0.IFO」がある。ここで、ファイル名ボディにある「01」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット#2の場合は、「VTS_02_0.IFO」となる。
図1の右上部は、DVDのアプリケーション層でのDVDナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「VIDEO_TS.IFO」内の情報は、VMGI(Video Manager Information)として、「VTS_01_0.IFO」または、他のビデオタイトルセット毎に存在する再生制御情報はVTSI(Video Title Set Information)としてDVDナビゲーション空間に展開される。
VTSIの中にはPGC(Program Chain)と呼ばれる再生シーケンスの情報であるPGCI(Program Chain Information)が記述されている。PGCIは、Cellの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Cell自身はVOB(Video Objectの略であり、MPEGストリームを指す)の一部区間または全部区間の集合であり、Cellの再生は、当該VOBのCellによって指定された区間を再生することを意味している。
コマンドは、DVDの仮想マシンによって処理されるものであり、ブラウザ上で実行されるJava(登録商標)スクリプトなどに近いものである。しかしながらJava(登録商標)スクリプトが論理演算の他にウィンドウやブラウザの制御(例えば、新しいブラウザのウィンドを開くなど)を行うのに対して、DVDのコマンドは、論理演算の他にAVタイトルの再生制御、例えば、再生するチャプタの指定などを実行するだけのものである点で異なっている。
Cellはディスク上に記録されているVOBの開始および終了アドレス(ディスク上での論理記録アドレス)をその内部情報として有しており、プレーヤは、Cellに記述されたVOBの開始および終了アドレス情報を使ってデータの読み出し、再生を実行する。
図2はAVストリーム中に埋め込まれているナビゲーション情報を説明する概略図である。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のイメージである。図に示すように、映像、音声、字幕などのデータ(A段)は、MPEGシステム規格(ISO/IEC13818-1)に基づいて、パケットおよびパック化し(B段)、夫々を多重化して1本のMPEGプログラムストリームにしている(C段)。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだNV_PCKも一緒に多重化をされている。
MPEGシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順に基づいてビット列が形成されている訳ではない。これは多重化したMPEGシステムストリームのデコーダモデル(一般にSystem Target Decoder、またはSTDと呼ばれる(図3のD段))が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。例えばDVD−Videoで規定されるデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、232KB、音声に対しては4KB、字幕に対しては52KBを夫々有している。
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードもしくは再生されているわけでは無い。
一方、次世代DVD規格としてBD(Blu-ray Disc)がある。
DVDでは、標準画質(Standard Definition画質)の映像に対する、パッケージ配信(DVD-Video規格)やアナログ放送の記録(DVD Video Recording規格)を目的としMPEG−2を基本技術としてきたが、BDでは、高精度画質(High Definition画質)の映画素材をそのまま記録する(Blu-ray Disc Read-Only-Memory規格、以下BD-ROMもしくはBD)ことができ、新しい符合化方式(MPEG−4 AVCやVC−9など)を用いて低ビットレートながら高画質な映像を提供することも可能である。
しかしながら、新しい符合化方式は、MPEG−2と比べて演算量と要求メモリ量が大きく、また自由度が高い符号化方式であるため、エンコーダ/デコーダの実装が困難であるネガティブファクターも兼ね備えている。
したがって、ストリームの途中に飛び込み再生開始する場合や、特殊再生、DVDで実現されているマルチアングルなどの機能を実現するには、新しい符合化方式の符号化を一部制限することで実装のインパクトを減らし、かつ、管理情報に符号化情報を抽出するなどし、デコードを支援する必要がある。
特殊再生支援情報(タイムマップ)に関しては、特許文献1に公開されている。
特開平11−96730号公報
現在のDVDやBDでは、MPEG−2の符号化方式を基本技術としているため、映像圧縮方式としてMPEG−4 AVCやVC−9を用いる場合に復号を支援する適切な情報を備えていない課題がある。
本発明は、上記課題を解決することを目的としている。
上記課題を解決するため、請求項1にかかる発明は、ストリーム途中からの復号処理が可能か否かを示す復号開始点情報を持たない画像符合化方式によって符合化された映像情報を含むストリームを記録した情報記録媒体であって、前記ストリーム内に前記復号開始点情報を格納させ、前記ストリームが前記復号開始点情報を含むことを示す情報を記録した管理情報を持つことを特徴とする情報記録媒体としている。
請求項2にかかる発明は、ストリーム途中からの復号処理が可能か否かを示す復号開始点情報を持たない画像符合化方式によって符合化された映像情報を含むストリームを記録した情報記録媒体であって、前記ストリームが前記復号開始点情報を前記ストリーム内の1つもしくは複数のピクチャを束ねた論理単位の符合化属性を示すヘッダ情報直後のユーザーデータ領域に記述されることを特徴とする情報記録媒体としている。
請求項3にかかる発明は、請求項2に記載の情報記録媒体であって、前記ストリームの管理情報に、前記復号開始点情報が多重化されている位置を示す情報が記録されていることを特徴とする情報記録媒体としている。
請求項4にかかる発明は、請求項3に記載の情報記録媒体であって、前記復号開始点情報からの復号処理が可能か否かを示す情報が前記管理情報に格納されていることを特徴とする情報記録媒体としている。
上記解決手段を講じることによって、ストレスのない再生機能を提供することが可能となり、ユーザ操作のレスポンス向上が期待できる。
また、符号化条件を制限することで、機器実装が簡易になる効果もある。
(実施例1)
まず最初に本発明の第1の実施の形態について説明する。
(ディスク上の論理データ構造)
図4は、BD−ROMの構成、特にディスク媒体であるBDディスク(104)と、ディスクに記録されているデータ(101、102、103)の構成を示す図である。BDディスク(104)に記録されるデータは、AVデータ(103)と、AVデータに関する管理情報およびAV再生シーケンスなどのBD管理情報(102)と、インタラクティブを実現するBD再生プログラム(101)である。本実施の形態では、説明の都合上、映画のAVコンテンツを再生するためのAVアプリケーションを主眼においてのBDディスクの説明を行うが、他の用途として用いても勿論同様である。
まず最初に本発明の第1の実施の形態について説明する。
(ディスク上の論理データ構造)
図4は、BD−ROMの構成、特にディスク媒体であるBDディスク(104)と、ディスクに記録されているデータ(101、102、103)の構成を示す図である。BDディスク(104)に記録されるデータは、AVデータ(103)と、AVデータに関する管理情報およびAV再生シーケンスなどのBD管理情報(102)と、インタラクティブを実現するBD再生プログラム(101)である。本実施の形態では、説明の都合上、映画のAVコンテンツを再生するためのAVアプリケーションを主眼においてのBDディスクの説明を行うが、他の用途として用いても勿論同様である。
図5は、上述したBDディスクに記録されている論理データのディレクトリ・ファイル構成を示した図である。BDディスクは、他の光ディスク、例えばDVDやCDなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはBCA(Burst Cutting Area)と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがある。
論理アドレス空間には、ファイルシステム情報(ボリューム)を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、UDFやISO9660などのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
本実施例の場合、BDディスク上のディレクトリ、ファイル構造は、ルートディレクトリ(ROOT)直下にBDVIDEOディレクトリが置かれている。このディレクトリはBDで扱うAVコンテンツや管理情報などのデータ(図4で説明した101、102、103)が格納されているディレクトリである。
BDVIDEOディレクトリの下には、次の7種類のファイルが記録されている。
BD.INFO(ファイル名固定)
「BD管理情報」の一つであり、BDディスク全体に関する情報を記録したファイルである。BDプレーヤは最初にこのファイルを読み出す。
「BD管理情報」の一つであり、BDディスク全体に関する情報を記録したファイルである。BDプレーヤは最初にこのファイルを読み出す。
BD.PROG(ファイル名固定)
「BD再生プログラム」の一つであり、BDディスク全体に関わる再生制御情報を記録したファイルである。
「BD再生プログラム」の一つであり、BDディスク全体に関わる再生制御情報を記録したファイルである。
XXX.PL(「XXX」は可変、拡張子「PL」は固定)
「BD管理情報」の一つであり、シナリオ(再生シーケンス)であるプレイリスト情報を記録したファイルである。プレイリスト毎に1つのファイルを持っている。
「BD管理情報」の一つであり、シナリオ(再生シーケンス)であるプレイリスト情報を記録したファイルである。プレイリスト毎に1つのファイルを持っている。
XXX.PROG(「XXX」は可変、拡張子「PL」は固定)
「BD再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報を記録したファイルである。プレイリストとの対応はファイルボディ名(「XXX」が一致する)によって識別される。
「BD再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報を記録したファイルである。プレイリストとの対応はファイルボディ名(「XXX」が一致する)によって識別される。
YYY.VOB(「YYY」は可変、拡張子「VOB」は固定)
「AVデータ」の一つであり、VOB(従来例で説明したVOBと同じ)を記録したファイルである。VOB毎に1つのファイルを持っている。
「AVデータ」の一つであり、VOB(従来例で説明したVOBと同じ)を記録したファイルである。VOB毎に1つのファイルを持っている。
YYY.VOBI(「YYY」は可変、拡張子「VOBI」は固定)
「BD管理情報」の一つであり、AVデータであるVOBに関わるストリーム管理情報を記録したファイルである。VOBとの対応はファイルボディ名(「YYY」が一致する)によって識別される。
「BD管理情報」の一つであり、AVデータであるVOBに関わるストリーム管理情報を記録したファイルである。VOBとの対応はファイルボディ名(「YYY」が一致する)によって識別される。
ZZZ.PNG(「ZZZ」は可変、拡張子「PNG」は固定)
「AVデータ」の一つであり、字幕およびメニューを構成するためのイメージデータPNG(W3Cによって標準化された画像フォーマットであり「ピング」と読む)を記録したファイルである。1つのPNGイメージ毎に1つのファイルを持つ。
(プレーヤの構成)
次に、前述したBDディスクを再生するプレーヤの構成について図6および図7を用いて説明する。
「AVデータ」の一つであり、字幕およびメニューを構成するためのイメージデータPNG(W3Cによって標準化された画像フォーマットであり「ピング」と読む)を記録したファイルである。1つのPNGイメージ毎に1つのファイルを持つ。
(プレーヤの構成)
次に、前述したBDディスクを再生するプレーヤの構成について図6および図7を用いて説明する。
図6は、プレーヤの大まかな機能構成を示すブロック図である。
BDディスク(201)上のデータは、光ピックアップ(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)に描画され、合成処理部(211)によって映像の合成処理が行われTVなどの表示デバイスへ出力される。
このように図6に示すように、BDプレーヤは図4で示したBDディスクに記録されているデータ構成に基づいた機器構成をとっている。
図7は前述したプレーヤ構成を詳細化したブロック図である。図7では、AV記録メモリ(205)はイメージメモリ(308)とトラックバッファ(309)に、プログラム処理部(206)はプログラムプロセッサ(302)とUOPマネージャ(303)に、管理情報処理部(207)はシナリオプロセッサ(305)とプレゼンテーションコントローラ(306)に、プレゼンテーション処理部(208)はクロック(307)、デマルチプレクサ(310)、イメージプロセッサ(311)、ビデオプロセッサ(312)とサウンドプロセッサ(313)に夫々対応/展開している。
BDディスク(201)から読み出されたVOBデータ(MPEGストリーム)はトラックバッファ(309)に、イメージデータ(PNG)はイメージメモリ(308)に夫々記録される。デマルチプレクサ(310)がクロック(307)の時刻に基づき、トラックバッファ(309)に記録されたVOBデータを抜き出し、映像データをビデオプロセッサ(312)に音声データをサウンドプロセッサ(313)に夫々送り込む。ビデオプロセッサ(312)およびサウンドプロセッサ(313)は夫々MPEGシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ(310)から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック(307)に従い個々のデコーダでデコード処理される。
イメージメモリ(308)に記録されたPNGは、次の2つの処理方法がある。
イメージデータが字幕用の場合は、プレゼンテーションコントローラ(306)によってデコードタイミングが指示される。クロック(307)からの時刻情報をシナリオプロセッサ(305)が一旦受け、適切な字幕表示が行えるように、字幕表示時刻(開始および終了)になればプレゼンテーションコントローラ(306)に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ(306)からデコード/表示の指示を受けたイメージプロセッサ(311)は対応するPNGデータをイメージメモリ(308)から抜き出し、デコードし、イメージプレーン(314)に描画する。
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ(302)によってデコードタイミングが指示される。プログラムプロセッサ(302)が何時イメージのデコードを指示するかは、プログラムプロセッサ(302)が処理しているBDプログラムに因るものであって一概には決まらない。
イメージデータおよび映像データは、図6で説明したように夫々デコード後にイメージプレーン(314)、ビデオプレーン(315)に出力され、合成処理部(316)によって合成後出力される。
BDディスク(201)から読み出された管理情報(シナリオ、AV管理情報)は、管理情報記録メモリ(304)に格納されるが、シナリオ情報(「BD.INFO」および「XXX.PL」)はシナリオプロセッサ(305)へ読み込み処理される。また、AV管理情報(「YYY.VOBI」)はプレゼンテーションコントローラ(306)によって読み出され処理される。
シナリオプロセッサ(305)は、プレイリストの情報を解析し、プレイリストによって参照されているVOBとその再生位置をプレゼンテーションコントローラ(306)に指示し、プレゼンテーションコントローラ(306)は対象となるVOBの管理情報(「YYY.VOBI」)を解析して、対象となるVOBを読み出すようにドライブコントローラ(317)に指示を出す。
ドライブコントローラ(317)はプレゼンテーションコントローラ(306)の指示に従い、光ピックアップを移動させ、対象となるAVデータの読み出しを行う。読み出されたAVデータは、前述したようにイメージメモリ(308)またはトラックバッファ(309)に読み出される。
また、シナリオプロセッサ(305)は、クロック(307)の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ(302)に投げる。
プログラム記録メモリ(301)に記録されたBDプログラム(「BD.PROG」または「XXX.PROG」)は、プログラムプロセッサ302によって実行処理される。プログラムプロセッサ(302)がBDプログラムを処理するのは、シナリオプロセッサ(305)からイベントが送られてきた場合か、UOPマネージャ(303)からイベントが送られてきた場合である。UOPマネージャ(303)は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ(302)に対するイベントを生成する。
(アプリケーション空間)
図8は、BDのアプリケーション空間を示す図である。
(アプリケーション空間)
図8は、BDのアプリケーション空間を示す図である。
BDのアプリケーション空間では、プレイリスト(PlayList)が一つの再生単位になっている。プレイリストはセル(Cell)の連結で、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。BDの場合、メニューとはユーザの選択によって再生するシナリオと定義でき、プログラムによってプレイリストを動的に選択することである。
ここで言うプログラムとは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図7で説明したシナリオプロセッサ(305)からプログラムプロセッサ(302)に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ(302)はIDによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく2つのタイプに分けられる。一つ目は、カーソルキー(「上」「下」「左」「右」キー)または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり(プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている)、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、DVDのメニューコール(タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する機能等)を実装することができる。
プレイリストで静的シナリオを構成する単位であるセル(Cell)はVOB(MPEGストリーム)の全部または一部の再生区間を参照したものである。セルはVOB内の再生区間を開始、終了時刻の情報として持っている。個々のVOBと一対になっているVOB管理情報(VOBI)は、その内部にデータの再生時刻に対応した記録アドレスのテーブル情報であるタイムマップ(Time MapまたはTM)を有しており、このタイムマップによって前述したVOBの再生、終了時刻をVOB内(即ち対象となるファイル「YYY.VOB」内)での読み出し開始アドレスおよび終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
(VOBの詳細)
図9は、本実施例で使用するMPEGストリーム(VOB)の構成図である。
(VOBの詳細)
図9は、本実施例で使用するMPEGストリーム(VOB)の構成図である。
図9に示すように、VOBは複数のVOBU(Video Object Unit)によって構成されている。VOBUは、MPEGビデオストリームで言うGOP(Group Of Pictures)を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。VOBUは1.0秒以下のビデオ再生時間を持ち、通常は0.5秒程度の再生時間を持っている。
VOBU先頭のTSパケット(MPEG-2 Transport Stream Packet)は、シーケンスヘッダとそれに続くGOPヘッダとIピクチャ(Intra-coded)を格納しており、このIピクチャからの復号が開始可能なようになっている。また、このVOBU先頭のIピクチャの先頭を含むTSパケットのアドレス(開始アドレス)と、この開始アドレスからIピクチャの最後を含むTSパケットまでのアドレス(終了アドレス)と、このIピクチャの再生開始時刻(PTS)をタイムマップで管理している。したがって、タイムマップのエントリーはVOBU先頭のTSパケットごとに与えられている。
VOBUは、その内部にビデオパケット(V_PKT)とオーディオパケット(A_PKT)を有している。各パケットは188バイトであり、図9に図示してはいないが、各TSパケットの直前には、そのTSパケットの相対的なデコーダ供給開始時刻であるATS(Arrival Time Stamp)が付与されている。
ATSを各TSパケットごとに付与するのは、このTSストリームのシステムレートが固定レートでなく、可変レートであるためである。一般的にシステムレートを固定にする場合にはNULLパケットと呼ばれるダミーのTSパケットを挿入することになるが、限られた記録容量の中に高画質で記録するためには、可変レートが適しており、BDではATS付きのTSストリームとして記録している。
図10は、TSパケットの構成を示した図である。
図10に示すように、TSパケットは、TSパケットヘッダと、適用フィールドと、ペイロード部から構成される。TSパケットヘッダにはPID(Packet Identifier)が格納され、これにより、TSパケットがどのような情報を格納しているのか識別される。適用フィールドにはPCR(Program Clock Reference)が格納される。PCRはストリームをデコードする機器の基準クロック(System Time Clock、STCと呼ぶ)の参照値である。機器は典型的にはPCRのタイミングでシステムストリームをデマルチプレクスし、ビデオストリーム等の各種ストリームを再構築する。ペイロードにはPESパケットが格納される。
PESパケットヘッダには、DTS(Decoding Time Stamp)とPTS(Presentation Time Stamp)が格納される。DTSは当該PESパケットに格納されるピクチャ/オーディオフレームのデコードタイミングを示し、PTSは映像音声出力等のプレゼンテーションタイミングを示す。ビデオデータおよびオーディオデータといったエレメンタリデータは、PESパケットペイロード(PES Packet Payload)と呼ばれるパケット(PES Packet)のデータ格納領域に先頭から順次入れられていく。PESパケットヘッダには、ペイロードに格納してあるデータがどのストリームなのかを識別するためのID(stream_id)も記録されている。
TSストリームの詳細についてはISO/IEC13818-1で規定されており、BDで特徴的なのはATSを各TSパケットごとに付与したことである。
(VOBのインターリーブ記録)
次に図11および図12を用いてVOBファイルのインターリーブ記録について説明する。
(VOBのインターリーブ記録)
次に図11および図12を用いてVOBファイルのインターリーブ記録について説明する。
図11上段は、前述したプレーヤ構成図の一部である。図の通り、BDディスク上のデータは、光ピックアップを通してVOB即ちMPEGストリームであればトラックバッファへ入力され、PNG即ちイメージデータであればイメージメモリへと入力される。
トラックバッファはFIFOであり、入力されたVOBのデータは入力された順にデマルチプレクサへと送られる。この時、前述したATSに従って個々のTSパケットはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、そのメニュー描画中はイメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存しており、ユーザーの操作に追従してメニューの一部分を再表示もしくは異なるイメージに置き換えることがあり、その際に再表示される部分のイメージデータをデコードし易くするためである。
図11下段は、BDディスク上でのVOBファイルおよびPNGファイルのインターリーブ記録を示す図である。一般的にROM、例えばCD−ROMやDVD−ROMの場合、一連の連続再生単位となるAVデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出し、デコーダに送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。BDの場合も同様に、VOBファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにVOBに記録されている映像データと同期して再生されるデータがあり、VOBファイルと同様に字幕データも何らかの方法によってBDディスクから読み出す事が必要になる。
字幕データの読み出し方法の一手段として、VOBの再生開始前に一まとめで字幕用のイメージデータ(PNGファイル)を読み出してしまう方法がある。しかしながら、この場合には大量のメモリが必要となり、非現実的である。
そこで、VOBファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図11下段はそのインターリーブ記録を説明した図である。
VOBファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、VOBデータの読み込みは当然のことながら停止することになる。
図12は、この問題を解決するトラックバッファを使ったVOBデータ連続供給モデルを説明する図である。
既に説明したように、VOBのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート(Va)とトラックバッファからのデータ出力レート(Vb)の間に差(Va>Vb)を設けると、BDディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。
図12の上段に記すようにVOBの一連続記録領域が論理アドレスの”a1”から”a2”まで続くとする。”a2”から”a3”の間は、イメージデータが記録されていて、VOBデータの読み出しが行えない区間であるとする。
図12の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”t1”がVOBの一連続記録領域の開始点である”a1”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートVa−Vbでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”t2”は一連続記録領域の終了点である”a2”のデータを読み込む時刻である。即ち時刻”t1”から”t2”の間レートVa−Vbでトラックバッファ内はデータ量が増加していき、時刻”t2”でのデータ蓄積量はB(t2)は下式によって求めることができる。
B(t2) = (Va−Vb)×(t2−t1) (式1)
この後、BDディスク上のアドレス”a3”まではイメージデータが続くため、トラックバッファへの入力は0となり、出力レートである”−Vb”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”a3”まで、時刻でいう”t3”までになる。
この後、BDディスク上のアドレス”a3”まではイメージデータが続くため、トラックバッファへの入力は0となり、出力レートである”−Vb”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”a3”まで、時刻でいう”t3”までになる。
ここで大事なことは、時刻”t3”より前にトラックバッファに蓄積されているデータ量が0になると、デコーダへ供給するVOBのデータが無くなってしまい、VOBの再生がストップしてしまう可能性がある。しかしながら、時刻”t3”でトラックバッファにデータが残っている場合には、VOBの再生がストップすることなく連続できることを意味している。
この条件は下式によって示すことができる。
B(t2) ≧ −Vb×(t3−t2) (式2)
即ち、式2を満たすようにイメージデータ(非VOBデータ)の配置を決めればよい事になる。
(ナビゲーションデータ構造)
図13から図19を用いて、BDのナビゲーションデータ(BD管理情報)構造について説明をする。
即ち、式2を満たすようにイメージデータ(非VOBデータ)の配置を決めればよい事になる。
(ナビゲーションデータ構造)
図13から図19を用いて、BDのナビゲーションデータ(BD管理情報)構造について説明をする。
図13は、VOB管理情報ファイル(”YYY.VOBI”)の内部構造を示した図である。
VOB管理情報は、当該VOBのストリーム属性情報(Attribute)とタイムマップ(TMAP)を有している。ストリーム属性は、ビデオ属性(Video)、オーディオ属性(Audio#0〜Audio#m)個々に持つ構成となっている。特にオーディオストリームの場合は、VOBが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数(Number)によって、データフィールドの有無を示している。
下記はビデオ属性(Video)の持つフィールドと夫々が持ち得る値である。
圧縮方式(Coding):
MPEG1
MPEG2
MPEG4
MPEG4−AVC(Advanced Video Coding)
解像度(Resolution):
1920x1080
1440x1080
1280x720
720x480
720x565
アスペクト比(Aspect)
4:3
16:9
フレームレート(Framerate)
60
59.94(60/1.001)
50
30
29.97(30/1.001)
25
24
23.976(24/1.001)
下記はオーディオ属性(Audio)の持つフィールドと夫々が持ち得る値である。
MPEG1
MPEG2
MPEG4
MPEG4−AVC(Advanced Video Coding)
解像度(Resolution):
1920x1080
1440x1080
1280x720
720x480
720x565
アスペクト比(Aspect)
4:3
16:9
フレームレート(Framerate)
60
59.94(60/1.001)
50
30
29.97(30/1.001)
25
24
23.976(24/1.001)
下記はオーディオ属性(Audio)の持つフィールドと夫々が持ち得る値である。
圧縮方式(Coding):
AC3
MPEG1
MPEG2
LPCM
チャンネル数(Ch):
1〜8
言語属性(Language):
タイムマップ(TMAP)はVOBU毎の情報を持つテーブルであって、当該VOBが有するVOBU数(Number)と各VOBU情報(VOBU#1〜VOBU#n)を持つ。個々のVOBU情報は、VOBU先頭TSパケット(Iピクチャ開始)のアドレスI_startと、そのIピクチャの終了アドレスまでのオフセットアドレス(I_end)、およびそのIピクチャの再生開始時刻(PTS)から構成される。
AC3
MPEG1
MPEG2
LPCM
チャンネル数(Ch):
1〜8
言語属性(Language):
タイムマップ(TMAP)はVOBU毎の情報を持つテーブルであって、当該VOBが有するVOBU数(Number)と各VOBU情報(VOBU#1〜VOBU#n)を持つ。個々のVOBU情報は、VOBU先頭TSパケット(Iピクチャ開始)のアドレスI_startと、そのIピクチャの終了アドレスまでのオフセットアドレス(I_end)、およびそのIピクチャの再生開始時刻(PTS)から構成される。
図14はVOBU情報の詳細を説明する図である。
広く知られているように、MPEGビデオストリームは高画質記録するために可変ビットレート圧縮されることがあり、その再生時間とデータサイズ間に単純な相関はない。逆に、音声の圧縮規格であるAC3は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は1次式によって求めることができる。しかしながらMPEGビデオデータの場合は、個々のフレームは固定の表示時間、例えばNTSCの場合は1フレームは1/29.97秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるI/P/Bピクチャによってデータサイズは大きく変わってくる。従って、MPEGビデオの場合は、時間とアドレスの関係は一次式の形で表現することは不可能である。
当然の事として、MPEGビデオデータを多重化しているMPEGシステムストリーム、即ちVOBも時間とデータサイズとを一次式の形で表現することは不可能である。このため、VOB内での時間とアドレスとの関係を結びつけるのがタイムマップ(TMAP)である。
このようにして、ある時刻情報が与えられた場合、先ずは当該時刻がどのVOBUに属するのかを検索(VOBU毎のPTSを追っていく)して、当該時刻の直前のPTSをTMAPに持つVOBUに飛びこみ(I_startで指定されたアドレス)、VOBU先頭のIピクチャから復号を開始し、当該時刻のピクチャから表示を開始する。
次に図15を使って、プレイリスト情報(”XXX.PL”)の内部構造を説明する。
プレイリスト情報は、セルリスト(CellList)とイベントリスト(EventList)から構成されている。
セルリスト(CellList)は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト(CellList)の中身は、セルの数(Number)と各セル情報(Cell#1〜Cell#n)である。
セル情報(Cell#)は、VOBファイル名(VOBName)、当該VOB内での開始時刻(In)および終了時刻(Out)と、字幕テーブル(SubtitleTable)を持っている。開始時刻(In)および終了時刻(Out)は、夫々当該VOB内でのフレーム番号で表現され、前述したタイムマップ(TMAP)を使うことによって再生に必要なVOBデータのアドレスを得る事ができる。
字幕テーブル(SubtitleTable)は、当該VOBと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル(SubtitleTable)最初の情報も言語数(Number)とそれに続く個々の言語ごとのテーブル(Language#1〜Language#k)から構成されている。
各言語のテーブル(Language#)は、言語情報(Lang)と、個々に表示される字幕の字幕情報数(Number)と、個々に表示される字幕の字幕情報(Speech#1〜Speech#j)から構成され、字幕情報(Speech#)は対応するイメージデータファイル名(Name)、字幕表示開始時刻(In)および字幕表示終了時刻(Out)と、字幕の表示位置(Position)から構成されている。
イベントリスト(EventList)は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数(Number)に続いて個々のイベント(Event#1〜Event#m)から構成され、個々のイベント(Event#)は、イベントの種類(Type)、イベントのID(ID)、イベント発生時刻(Time)と有効期間(Duration)から構成されている。
図16は、個々のプレイリスト毎のイベントハンドラ(時間イベントと、メニュー選択用のユーザイベント)を持つイベントハンドラテーブル(”XXX.PROG”)である。
イベントハンドラテーブルは、定義されているイベントハンドラ/プログラム数(Number)と個々のイベントハンドラ/プログラム(Program#1〜Program#n)を有している。各イベントハンドラ/プログラム(Program#)内の記述は、イベントハンドラ開始の定義(<event_handler>タグ)と前述したイベントのIDと対になるイベントハンドラのID(ID)を持ち、その後に当該プログラムもFunctionに続く括弧”{”と”}”の間に記述する。前述の”XXX.PL”のイベントリスト(EventList)に格納されたイベント(Event#1〜Event#m)は”XXX.PROG”のイベントハンドラのID(ID)を用いて特定される。
次に図17を用いてBDディスク全体に関する情報(”BD.INFO”)の内部構造を説明する。
BDディスク全体情報は、タイトルリスト(TitleList)とグローバルイベント用のイベントテーブル(EventList)から構成されている。
タイトルリスト(TitleList)は、ディスク内のタイトル数(Number)と、これに続く各タイトル情報(Title#1〜Title#n)から構成されている。個々のタイトル情報(Title#)は、タイトルに含まれるプレイリストのテーブル(PLTable)とタイトル内のチャプタリスト(ChapterList)を含んでいる。プレイリストのテーブル(PLTable)はタイトル内のプレイリストの数(Number)と、プレイリスト名(Name)即ちプレイリストのファイル名を有している。
チャプタリスト(ChapterList)は、当該タイトルに含まれるチャプタ数(Number)と個々のチャプタ情報(Chapter#1〜Chapter#n)から構成され、個々のチャプタ情報(Chapter#)は当該チャプタが含むセルのテーブル(CellTable)を持ち、セルのテーブル(CellTable)はセル数(Number)と個々のセルのエントリ情報(CellEntry#1〜CellEntry#k)から構成されている。セルのエントリ情報(CellEntry#)は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
イベントリスト(EventList)は、グローバルイベントの数(Number)と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント(FirstEvent)と呼ばれ、BDディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ(Type)とイベントのID(ID)だけを持っている。
図18は、グローバルイベントハンドラのプログラムのテーブル(”BD.PROG”)である。
本テーブルは、図16で説明したイベントハンドラテーブルと同一内容である。
(イベント発生のメカニズム)
図19から図21を使ってイベント発生のメカニズムについて説明する。
(イベント発生のメカニズム)
図19から図21を使ってイベント発生のメカニズムについて説明する。
図19はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報(”XXX.PL”)のイベントリスト(EventList)で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ(Type)が”TimeEvent”の場合、イベント生成時刻(”t1”)になった時点で、ID”Ex1”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントID”Ex1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、2つのボタンイメージの描画を行うなどを行うことができる。
図20はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報(”XXX.PL”)のイベントリスト(EventList)で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ(Type)が”UserEvent”の場合、イベント生成時刻(”t1”)になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効期間情報(Duration)で記される期間レディ状態にある。
図20に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずUOPイベントがUOPマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してUOPイベントを流し、シナリオプロセッサはUOPイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントID”Ev1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、プレイリスト#2の再生を開始する。
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、UOPイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタSPRM(8)に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
図21はグローバルイベントの例である。
前述したとおり、グローバルイベントはBDディスク全体に関する情報(”BD.INFO”)のイベントリスト(EventList)で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ(Type)が”GlobalEvent”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
ユーザが”メニュー”を押した場合、先ずUOPイベントがUOPマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してUOPイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントID”menu”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合ではプレイリスト#3の再生を開始している。
本実施例では、単に”メニュー”キーと呼んでいるが、DVDのように複数のメニューキーがあってもよい。各メニューキーに対応するIDを夫々定義することで対応することが可能である。
(仮想プレーヤマシン)
図22を用いてプログラムプロセッサの機能構成を説明する。
(仮想プレーヤマシン)
図22を用いてプログラムプロセッサの機能構成を説明する。
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはBDとして定義された機能モデルであって、各BDプレーヤの実装には依存しないものである。即ち、どのBDプレーヤにおいても同様の機能を実行するできることを保証している。
仮想プレーヤマシンは大きく2つの機能を持っている。プログラミング関数とプレーヤ変数(レジスタ)である。プログラミング関数は、Java(登録商標)Scriptをベースとして、以下に記す2つの機能をBD固有関数として定義している。
リンク関数:現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Link(PL#,Cell#,time)
PL# : プレイリスト名
Cell# : セル番号
time : セル内での再生開始時刻
PNG描画関数:指定PNGデータをイメージプレーンに描画する
Draw(File,X,Y)
File : PNGファイル名
X : X座標位置
Y : Y座標位置
イメージプレーンクリア関数:イメージプレーンの指定領域をクリアする
Clear(X,Y,W,H)
X : X座標位置
Y : Y座標位置
W : X方向幅
H : Y方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ(SPRM)と一般用途として使用可能なゼネラルパラメータ(GPRM)とがある。
Link(PL#,Cell#,time)
PL# : プレイリスト名
Cell# : セル番号
time : セル内での再生開始時刻
PNG描画関数:指定PNGデータをイメージプレーンに描画する
Draw(File,X,Y)
File : PNGファイル名
X : X座標位置
Y : Y座標位置
イメージプレーンクリア関数:イメージプレーンの指定領域をクリアする
Clear(X,Y,W,H)
X : X座標位置
Y : Y座標位置
W : X方向幅
H : Y方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ(SPRM)と一般用途として使用可能なゼネラルパラメータ(GPRM)とがある。
図23はシステムパラメータ(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に限定されるものでは無い。
(プログラムの例)
図24および図25は、イベントハンドラでのプログラムの例である。
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に限定されるものでは無い。
(プログラムの例)
図24および図25は、イベントハンドラでのプログラムの例である。
図24は、2つの選択ボタンを持ったメニューの例である。
セル(PlayList#1.Cell#1)先頭でタイムイベントを使って図24左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つGPRM(0)に”1”がセットされている。GPRM(0)は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン1が選択されている事を初期値として持たされている。
次に、PNGの描画を描画関数であるDrawを使ってボタン1、ボタン2夫々について行っている。ボタン1は、座標(10、200)を起点(左端)としてPNGイメージ”1black.png”を描画している。ボタン2は、座標(330,200)を起点(左端)としてPNGイメージ”2white.png”を描画している。
また、本セル最後ではタイムイベントを使って図24右側のプログラムが実行される。ここでは、Link関数を使って当該セルの先頭から再度再生するように指定している。
図25は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図20で説明したとおり、ユーザイベントが生成され、図25のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているGPRM(0)の値と、選択されたリモコンキーを識別するSPRM(8)を使って分岐処理を行っている。
条件1)ボタン1が選択されている、かつ、選択キーが「右」キーの場合
GPRM(0)を2に再設定して、選択状態にあるボタンを右ボタン2に変更する。
GPRM(0)を2に再設定して、選択状態にあるボタンを右ボタン2に変更する。
ボタン1、ボタン2のイメージを夫々書き換える。
条件2)選択キーが「決定(OK)」の場合で、ボタン1が選択されている場合
プレイリスト#2の再生を開始する
条件3)選択キーが「決定(OK)」の場合で、ボタン2が選択されている場合
プレイリスト#3の再生を開始する
上記のようにして実行処理が行われる。
(プレーヤ処理フロー)
次に図26から図29を用いてプレーヤでの処理フローを説明する。
プレイリスト#2の再生を開始する
条件3)選択キーが「決定(OK)」の場合で、ボタン2が選択されている場合
プレイリスト#3の再生を開始する
上記のようにして実行処理が行われる。
(プレーヤ処理フロー)
次に図26から図29を用いてプレーヤでの処理フローを説明する。
図26は、AV再生までの基本処理フローである。
BDディスクを挿入すると(S101)、BDプレーヤはBD.INFOファイルの読み込みと解析(S102)、BD.PROGの読み込み(S103)を実行する。BD.INFOおよびBD.PROGは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
続いて、シナリオプロセッサは、BD.INFOファイル内のファーストイベント(FirstEvent)情報に従い、最初のイベントを生成する(S104)。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する(S105)。
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。(S201)。BDプレーヤはユーザからのリモコン操作を受け付けると、UOPマネージャはプログラムマネージャに対してUOPイベントを立ち上げる(S202)。
プログラムマネージャは、UOPイベントがメニューキーかを判別し(S203)、メニューキーの場合は、シナリオプロセッサにUOPイベントを流し、シナリオプロセッサがユーザイベントを生成する(S204)。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する(S205)。
図27は、PL再生開始からVOB再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される(S301)。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”XXX.PL”の読み込みと解析(S302)、プレイリストに対応するプログラム情報”XXX.PROG”の読み込みを行う(S303)。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する(S304)。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはAV再生を開始する(S305)。
AV再生の開始(S401)を開始すると、プレゼンテーションコントローラは再生するセルに対応するVOBの情報ファイル(XXX.VOBI)を読み込みおよび解析をする(S402)。プレゼンテーションコントローラは、タイムマップを使って再生開始するVOBUとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるVOBデータを読み出し(S403)、VOBデータがデコーダに送られ再生が開始される(S404)。
VOB再生は、当該VOBの再生区間が終了するまで続けられ(S405)、終了すると次のセル再生S304へ移行する。次にセルが無い場合は、再生が停止する(S406)。
図28は、AV再生開始後からのイベント処理フローである。
BDプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
S500系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後(S501)、プレイリスト再生が終了しているかを確認するステップ(S502)を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する(S503)。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し(S504)、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する(S505)。
ステップS503でタイムイベント発生時刻になっていない場合、または、ステップS504でイベントハンドラ実行処理後は再度ステップS502へ戻り、上述した処理を繰り返す。また、ステップS502でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
S600系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後(S601)、プレイリスト再生終了確認ステップ(S602)を経て、UOP受付確認ステップの処理に移る(S603)。UOPの受付があった場合、UOPマネージャはUOPイベントを生成し(S604)、UOPイベントを受け取ったプログラムプロセッサはUOPイベントがメニューコールであるかを確認し(S605)、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ(S607)、プログラムプロセッサはイベントハンドラを実行処理する(S608)。
ステップS605でUOPイベントがメニューコールで無いと判断された場合、UOPイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し(S606)、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し(S607)、プログラムプロセッサが対象のイベントハンドラを実行処理する(S608)。
ステップS603でUOP受付が無い場合、ステップS606で現在時刻がユーザイベント有効期間に無い場合、または、ステップS608でイベントハンドラ実行処理後は再度ステップS602へ戻り、上述した処理を繰り返す。また、ステップS602でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
図29は字幕処理のフローである。
プレイリスト再生開始後(S701)、プレイリスト再生終了確認ステップ(S702)を経て、字幕描画開始時刻確認ステップに移る(S703)。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する(S704)。ステップS703で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する(S705)。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する(S706)。
字幕描画ステップS704終了後、字幕消去ステップS706終了後、または、字幕表示終了時刻確認ステップS705で当該時刻でないことが判断された場合、ステップS702に戻り、上述した処理を繰り返す。また、ステップS702でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
(VC−9への適用)
上記においては、MPEG−2を用いる場合を基本に説明をしてきたが、VC−9を映像符号化方式として適用する場合には、符号化方式の制限の違いから、MPEG−2では不要だった配慮が必要となってくる。VC−9は、SMPTE(The Society of Motion Picture and Television Engineers)で策定中であり、MPEG−2ビデオ方式、MPEG−4ビジュアル方式をベースとし、符号化ツール等の拡張を行っている。
(VC−9への適用)
上記においては、MPEG−2を用いる場合を基本に説明をしてきたが、VC−9を映像符号化方式として適用する場合には、符号化方式の制限の違いから、MPEG−2では不要だった配慮が必要となってくる。VC−9は、SMPTE(The Society of Motion Picture and Television Engineers)で策定中であり、MPEG−2ビデオ方式、MPEG−4ビジュアル方式をベースとし、符号化ツール等の拡張を行っている。
上記文献では、3つのプロファイル(シンプル、メイン、アドバンスド)が規定されている。アドバンスドプロファイルでは、MPEG−2ビデオでも規定されているGOP(Group Of Pictures)構造を有し、GOPヘッダ部にBROKEN_LINKフラグとCLOSED_GOPフラグを有している。ここで、BROKEN_LINKフラグとは、そのGOPに含まれるBピクチャが直前のGOPに含まれるピクチャを参照して符号化していながら、編集等の処理によってその直前のGOPが存在しないときに「1」となるフラグである。またCLOSED_GOPフラグは、そのGOP内のピクチャが他のGOPのピクチャを参照していないときに「1」となるフラグである。すなわち、CLOSED_GOPフラグが「1」であれば、そのGOPから再生を開始しても、全てのピクチャを完全に再生することができる。
一方、シンプルプロファイル、メインプロファイルではGOP構造が規定されておらず、またBROKEN_LINKフラグとCLOSED_GOPフラグも規定されていない。
図30を用いて、ピクチャ間の参照関係を説明する。図30(a)は、Closed GOPでない場合のピクチャ参照関係であり、図30(b)は、Closed GOPである場合のピクチャ参照関係を示している。
MPEG−2との対比で分かりやすいように自己復号可能なIピクチャ、他ピクチャ1枚を参照して復号可能なPピクチャ、他ピクチャ2枚を参照して復号可能なBピクチャとして表している。(a)ではGOPのピクチャが直前のGOPのピクチャを参照している。
したがって、ストリーム中の符号化順でI2ピクチャ(Closed GOPでないGOPの先頭)に飛び込んで再生を開始した場合、符号化順序がI2ピクチャ以降のピクチャであっても、その復号ができずに映像が表示されない問題が起こる。図の例ではB0、B1ピクチャは参照ピクチャを失っているため、正しく復号処理ができない。
図30(b)に示すように、それ以降の符号化順のピクチャが必ず復号できる保証をするように、Closed GOP構造にて符号化することで、GOPに飛び込んで再生を開始した場合でも、それ以降に符号化されているピクチャは全て復号でき、表示が可能である。
言い換えれば、Closed GOPは、他のGOPのピクチャを参照しないため、ストリームの途中に飛び込み再生を開始するときなどの復号開始ポイントとなりうる。
図31にDVD−Videoで使われているマルチアングル時にClosed GOPを使うこと、およびそれを管理しておくことの有用性を説明する。マルチアングルとは、映画などのある再生地点からある再生地点まで(同一の時間帯)で表示する映像を変える技術である。例えば、違うカメラから撮影した映像をこのようにマルチアングルにしておくことで、ユーザは好きな視点(カメラ)を選択することが可能となる。
図に示すように、ストリーム#Aとストリーム#Bがマルチアングルを構成している2本のストリームで、それぞれのタイムマップが管理情報に格納されている。
タイムマップには、タイムマップのPTSを持つピクチャがClosed GOP先頭であることを示す情報(図中ではIDRフィールドの値が1に相当する)が管理されており、ユーザがマルチアングルのストリームを切り替える際に、アングル切り替えを行っても映像が破綻しないかが再生機器は判断できる。
時刻t1よりも前の時間にストリーム#Bを再生していた場合、アングル切り替えを行うユーザ操作を行ったとしても、ストリーム#Aの時刻t1のピクチャ(図中Iピクチャ)はIDRフィールドの値が0で、Closed GOPの先頭ではないことを示している。したがって、ユーザ操作通りにアングル切り替えを行った場合、Iピクチャ以降を正しく復号できる保証がないため、再生機器はそのままストリーム#Bを復号しても良い。
また同様に、時刻t2の時点で、ストリーム#Aからストリーム#Bへアングル切り替えすることは、ストリーム#Bの時刻t2でのピクチャがClosed GOP先頭であることから、この切り替え操作は適切に映像の途切れなく対応できることが予めストリーム#Bを解析する前からタイムマップによって判断できる。
このように、再生機器は、タイムマップにClosed GOPであることを示す情報を持つことで、マルチアングル間のアングル切り替え時に、映像復号において破綻しないかを前もって判断できる。勿論、Closed GOPの多重化位置を示す情報は、タイムマップに限らず、上述のBDの管理情報内に記述されていれば同様の効果が得られるのは明らかである。
図32には、BDのプレイリストの再生開始点について、Closed GOPを使うことの効果を説明する図である。
Closed GOPの場合、それ以降の符号化順を持つピクチャは全て順次復号可能であるため、プレイリストの再生開始点や、セルの再生開始点などは、Closed GOPを指していることが望ましい。
仮に、Iピクチャを指し示すPTS時刻情報がt1のエントリーが、セルの再生開始点に設定されていた場合、Iピクチャ(アドレス=x1)から順次再生を行ったとしても、Iピクチャ以降のピクチャを復号できる保証がないため、プレイリストの再生中に映像が乱れることになる。従って、プレイリストやセルも再生開始点はClosed GOPを指し示すことが望ましいことが分かる。
尚、上記タイムマップから指されるアドバンスドプロファイルのIピクチャは、複合が常に可能なように1つのPESパケットペイロードの中で、シーケンスヘッダ(プロファイル情報やフレームレート情報を含む)とEntry−Pointヘッダ(BROKEN_LINEやCLOSED_GOP情報を含む)に続いて符合化されているピクチャである。
このように、Closed GOPをストリーム途中からの再生開始点に設定する、もしくは、Closed GOPである場合に飛び込み再生を許可するなど、Closed GOPで符合化し、それを管理することの有用性はBD−ROMのような映画コンテンツを対象とするような精度の高い再生が求められる場合には極めて大きい。
以下、VC−9のシンプル/メインプロファイルでのClosed GOP構造の導入について説明する。
VC−9のシンプル/メインプロファイルを用いて符合化する場合には、BROKEN_LINK、CLOSED_GOPといったEntry−Pointヘッダとしてアドバンスドプロファイルのみで定義されている情報を、そのまま若しくはその一部をストリーム中に適用することが考えられる。
例えば、シンプル/メインプロファイルのVC−9をMPEG−2 TSで多重化する場合には、上記情報は、PESパケットペイロードの先頭に配置されるシーケンスヘッダの直後に続けて記述しても良いし、そのシーケンスヘッダの直後にユーザーデータ領域を確保し、そのユーザーデータの中に記述しても良いし、PESパケットヘッダのプライベートデータ領域やリザーブ領域の中に記述しても良いし、直前のPMTのdescriptorの中に記述しても良いし、TSパケットヘッダのアダプテーションフィールドにあるrandom_access_indicator=1bの場合にClosed GOPであると定義しても良い。
図33にシーケンスヘッダの直後にユーザーデータ領域を確保し、そのユーザーデータの中にEntry−Pointヘッダ情報を記述する例を示す。
このように、ユーザーデータにEntry−Pointヘッダもしくはその情報の一部を挿入することで、シンプル/メインプロファイルの規定を変更することなく、BROKEN_LINKやCLOSED_GOPといった情報をシーケンスヘッダ後でかつ、ピクチャデータの前に挿入することが可能となる。これはMPEG−2ビデオと同じ符合化順序である。
上記、VC−9のユーザーデータには、その挿入位置によっていくつかのレイヤーに分かれるが、その何れのレイヤーを使っても良い。シーケンスレベルユーザーデータでも良いし、Entry−Pointレベルユーザーデータでも良いし、フレームレベルユーザーデータでも良い。
また、プロファイルに依らず、上記に示すような所定のタイミングでEntry−Pointヘッダの情報がストリーム中に格納されていることを示す情報を管理情報に格納させても良い。尚、この際、図31のようにタイムマップに格納するようにしても良い。
また、シンプル/メインプロファイルのように、本来、ストリーム内にアドバンスドプロファイルのEntry−Pointヘッダに格納するような情報を格納できない場合であっても、ストリームとは別に管理情報(例えばタイムマップ)にてストリーム途中からの再生が可能であることを示すことで、再生装置の再生制御を支援することが可能である。
また、シンプル/メインプロファイルであっても、図33のように、シーケンスヘッダ直後にBROKEN_LINKやCLOSED_GOPといった情報をユーザーデータに格納して始まるIピクチャをストリームとは別の管理情報(例えばタイムマップ)にて管理するようにし、再生装置の再生制御を支援することが可能である。
尚、上記説明では、VC−9を用いて説明したが、本発明はこれに限らず、他の映像符号化方式にとっても全く同様に適用可能である。
本発明は、特定の実施形態について説明されてきたが、当業者にとっては他の多くの変形例、修正、他の利用が明らかである。それゆえ、本発明は、ここでの特定の開示に限定されず、添付の請求の範囲によってのみ限定され得る。
本発明にかかる情報記録媒体は、記録したコンテンツに対し、確実に復号開始可能なポイントを管理することで、マルチアングルやプレイリストの再生において、途切れない映像再生を行う再生装置を提供することが可能となる。
201 BDディスク
202 光ピックアップ
203 プログラム記録メモリ
204 管理情報記録メモリ
205 AV記録メモリ
206 プログラム処理部
207 管理情報処理部
208 プレゼンテーション処理部
209 イメージプレーン
210 ビデオプレーン
211 合成処理部
301 プログラム記録メモリ
302 プログラムプロセッサ
303 UOPマネージャ
304 管理情報記録メモリ
305 シナリオプロセッサ
306 プレゼンテーションコントローラ
307 クロック
308 イメージメモリ
309 トラックバッファ
310 デマルチプレクサ
311 イメージプロセッサ
312 ビデオプロセッサ
313 サウンドプロセッサ
314 イメージプレーン
315 ビデオプレーン
316 合成処理部
317 ドライブコントローラ
3207 動画ダウンコンバータ
3215 字幕ダウンコンバータ
3223 静止画ダウンコンバータ
3228 音声ダウンコンバータ
S101 ディスク挿入ステップ
S102 BD.INFO読み込みステップ
S103 BD.PROG読み込みステップ
S104 ファーストイベント生成ステップ
S105 イベントハンドラ実行ステップ
S201 UOP受付ステップ
S202 UOPイベント生成ステップ
S203 メニューコール判定ステップ
S204 イベント生成ステップ
S205 イベントハンドラ実行ステップ
S301 プレイリスト再生開始ステップ
S302 プレイリスト情報(XXX.PL)読み込みステップ
S303 プレイリストプログラム(XXX.PROG)読み込みステップ
S304 セル再生開始ステップ
S305 AV再生開始ステップ
S401 AV再生開始ステップ
S402 VOB情報(YYY.VOBI)読み込みステップ
S403 VOB(YYY.VOB)読み込みステップ
S404 VOB再生開始ステップ
S405 VOB再生終了ステップ
S406 次セル存在判定ステップ
S501 プレイリスト再生開始ステップ
S502 プレイリスト再生終了判定ステップ
S503 タイムイベント時刻判定ステップ
S504 イベント生成ステップ
S505 イベントハンドラ実行ステップ
S601 プレイリスト再生開始ステップ
S602 プレイリスト再生終了判定ステップ
S603 UOP受付判定ステップ
S604 UOPイベント生成ステップ
S605 メニューコール判定ステップ
S606 ユーザーイベント有効期間判定ステップ
S607 イベント生成ステップ
S608 イベントハンドラ実行ステップ
S701 プレイリスト再生開始ステップ
S702 プレイリスト再生終了判定ステップ
S703 字幕描画開始判定ステップ
S704 字幕描画ステップ
S705 字幕表示終了判定ステップ
S706 字幕消去ステップ
202 光ピックアップ
203 プログラム記録メモリ
204 管理情報記録メモリ
205 AV記録メモリ
206 プログラム処理部
207 管理情報処理部
208 プレゼンテーション処理部
209 イメージプレーン
210 ビデオプレーン
211 合成処理部
301 プログラム記録メモリ
302 プログラムプロセッサ
303 UOPマネージャ
304 管理情報記録メモリ
305 シナリオプロセッサ
306 プレゼンテーションコントローラ
307 クロック
308 イメージメモリ
309 トラックバッファ
310 デマルチプレクサ
311 イメージプロセッサ
312 ビデオプロセッサ
313 サウンドプロセッサ
314 イメージプレーン
315 ビデオプレーン
316 合成処理部
317 ドライブコントローラ
3207 動画ダウンコンバータ
3215 字幕ダウンコンバータ
3223 静止画ダウンコンバータ
3228 音声ダウンコンバータ
S101 ディスク挿入ステップ
S102 BD.INFO読み込みステップ
S103 BD.PROG読み込みステップ
S104 ファーストイベント生成ステップ
S105 イベントハンドラ実行ステップ
S201 UOP受付ステップ
S202 UOPイベント生成ステップ
S203 メニューコール判定ステップ
S204 イベント生成ステップ
S205 イベントハンドラ実行ステップ
S301 プレイリスト再生開始ステップ
S302 プレイリスト情報(XXX.PL)読み込みステップ
S303 プレイリストプログラム(XXX.PROG)読み込みステップ
S304 セル再生開始ステップ
S305 AV再生開始ステップ
S401 AV再生開始ステップ
S402 VOB情報(YYY.VOBI)読み込みステップ
S403 VOB(YYY.VOB)読み込みステップ
S404 VOB再生開始ステップ
S405 VOB再生終了ステップ
S406 次セル存在判定ステップ
S501 プレイリスト再生開始ステップ
S502 プレイリスト再生終了判定ステップ
S503 タイムイベント時刻判定ステップ
S504 イベント生成ステップ
S505 イベントハンドラ実行ステップ
S601 プレイリスト再生開始ステップ
S602 プレイリスト再生終了判定ステップ
S603 UOP受付判定ステップ
S604 UOPイベント生成ステップ
S605 メニューコール判定ステップ
S606 ユーザーイベント有効期間判定ステップ
S607 イベント生成ステップ
S608 イベントハンドラ実行ステップ
S701 プレイリスト再生開始ステップ
S702 プレイリスト再生終了判定ステップ
S703 字幕描画開始判定ステップ
S704 字幕描画ステップ
S705 字幕表示終了判定ステップ
S706 字幕消去ステップ
Claims (4)
- ストリーム途中からの復号処理が可能か否かを示す復号開始点情報を持たない画像符合化方式によって符合化された映像情報を含むストリームを記録した情報記録媒体であって、前記ストリーム内に前記復号開始点情報を格納させ、前記ストリームが前記復号開始点情報を含むことを示す情報を記録した管理情報を持つことを特徴とする情報記録媒体。
- ストリーム途中からの復号処理が可能か否かを示す復号開始点情報を持たない画像符合化方式によって符合化された映像情報を含むストリームを記録した情報記録媒体であって、前記ストリームが前記復号開始点情報を前記ストリーム内の1つもしくは複数のピクチャを束ねた論理単位の符合化属性を示すヘッダ情報直後のユーザーデータ領域に記述されることを特徴とする情報記録媒体。
- 前記ストリームの管理情報に、前記復号開始点情報が多重化されている位置を示す情報が記録されていることを特徴とする請求項2に記載の情報記録媒体。
- 前記復号開始点情報からの復号処理が可能か否かを示す情報が前記管理情報に格納されていることを特徴とする請求項3に記載の情報記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004257237A JP2006073127A (ja) | 2004-09-03 | 2004-09-03 | ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004257237A JP2006073127A (ja) | 2004-09-03 | 2004-09-03 | ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006073127A true JP2006073127A (ja) | 2006-03-16 |
Family
ID=36153573
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004257237A Pending JP2006073127A (ja) | 2004-09-03 | 2004-09-03 | ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2006073127A (ja) |
-
2004
- 2004-09-03 JP JP2004257237A patent/JP2006073127A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4714191B2 (ja) | 画像符号化装置、画像復号化装置および方法 | |
JP6227828B2 (ja) | 再生装置および再生方法 | |
JP6487514B2 (ja) | 再生装置、および再生方法 | |
JP6466258B2 (ja) | 再生装置、再生方法および記録媒体 | |
JP6272534B2 (ja) | 再生方法、および再生装置 | |
WO2016038811A1 (ja) | 記録媒体、再生装置、および再生方法 | |
JP2007036663A (ja) | 互換性を考慮した情報記録媒体およびその記録装置、記録方法、記録プログラム | |
JP5295572B2 (ja) | 情報記録媒体および情報記録媒体再生システム | |
JP2007235185A (ja) | ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 | |
WO2016021120A1 (ja) | 再生装置、再生方法および記録媒体 | |
JP2007133938A (ja) | オーディオミキシング出力の可否を示すフラグを持った情報記録媒体、および、その再生装置、再生方法 | |
JP6591202B2 (ja) | 記録媒体、再生装置およびその方法 | |
JP2006073127A (ja) | ランダムアクセスに適した情報記録媒体、およびその記録/再生装置、記録/再生方法 | |
JP2006087081A (ja) | 画像符号化装置、画像復号化装置 | |
JP2007048383A (ja) | 情報記録媒体およびその記録装置、記録方法、記録プログラム | |
JP2006013726A (ja) | 情報記録媒体、およびその記録/再生装置、記録/再生方法 | |
JP2019067481A (ja) | 記録媒体 | |
WO2016009606A1 (ja) | 記録媒体、再生装置およびその方法 | |
JP2006244655A (ja) | 再生装置および再生方法 | |
JP2007049461A (ja) | 情報記録媒体、情報記録装置およびその方法 | |
JP2006236453A (ja) | 情報記録媒体およびその再生装置、再生方法。 | |
JP2006228339A (ja) | 宣言型言語で記述された再生制御環境のリソース管理を考慮した情報記録媒体およびその再生装置、再生方法 |