JP2007336573A - 画像符号化装置、画像復号化装置 - Google Patents

Abstract

【課題】動画と静止画とが混在する場合に、静止画を動画よりも高画質に符号化および復号化する画像符号化装置および画像復号化装置を提供する。
【解決手段】本発明の画像符号化装置は、静止画の１ピクチャ当たりの符号量の上限を示す第１の上限と、動画像の１ピクチャ当たりの符号量の上限を示す第２の上限とを決定し、連続して再生する複数の静止画のみからなる所定単位毎に第１の上限を満たすように複数の静止画を符号化し、連続して再生する複数の動画像のみからなる所定単位毎に第２の上限を満たすように複数の動画像を符号化し、所定単位毎に符号量の上限を特定する管理情報を生成し、管理情報と、所定単位毎に符号化された静止画と、動画像とを出力する。
【選択図】図５

Description

本発明は、画像符号化装置、画像復号化装置等に関し、特に、動画像と静止画とを含むストリームの符号化、復号化に関する。再生時にランダムアクセス性を確保したパッケージメディアに関する。

従来の技術である、ＤＶＤ−Ｖｉｄｅｏディスク（以下単にＤＶＤと呼ぶ）について説明する。

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

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

ＤＶＤの場合、ＵＤＦおよびＩＳＯ９６６０両方を使用しており（両方を合わせて「ＵＤＦブリッジ」と呼ぶ事がある）、ＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。勿論、書き換え型のＤＶＤディスクであるＤＶＤ−ＲＡＭ／Ｒ／ＲＷでは、これらファイルシステムを介し、物理的にデータの読み、書き、削除が可能である。

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

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

拡張子として２つの種類が規定されており、「ＩＦＯ」は再生制御情報が記録されたファイルであって、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルである。再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。

再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット（ＤＶＤでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を１枚のディスクに記録することが可能である。）毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。

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

ＶＴＳＩの中にはＰＧＣ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ）と呼ばれる再生シーケンスの情報であるＰＧＣＩ（Ｐｒｏｇｒａｍ Ｃｈａｉｎ Ｉｎｆｏｒｍａｔｉｏｎ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間の集合であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。

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

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

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

ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には、幾つかのボタンが現れ、夫々のボタンには当該ボタンが選択実行された時の処理が定義されている。また、メニュー上では一つのボタンが選択されており（ハイライトによって選択ボタン上に半透明色がオーバーレイされており該ボタンが選択状態であることをユーザに示す）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプタの再生がコマンドによって実行されている。

図２の左上部はＮＶ＿ＰＣＫ内に格納される制御情報の概要を示している。
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作夫々に対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）が記述されている。

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

上述のようにして、ＤＶＤではメニューを実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのは、ストリームと同期して動的にメニュー情報を更新したり（例えば、映画再生の途中５分〜１０分の間にだけメニューが表示されるなど）、同期タイミングが問題となりやすいアプリケーションの場合でも、問題なく実現できるようにしたためである。また、もう一つの大きな理由は、ＮＶ＿ＰＣＫには特殊再生を支援するための情報を格納し、ＤＶＤ再生時の早送り、巻き戻しなどの非通常再生時にも円滑にＡＶデータをデコードし再生させる等、ユーザの操作性を向上させるためである。

図３は、ＤＶＤのストリームであるＶＯＢのイメージである。図に示すように、映像、音声、字幕などのデータ（Ａ段）は、ＭＰＥＧシステム規格（ＩＳＯ／ＩＥＣ１３８１８−１）に基づいて、パケットおよびパック化し（Ｂ段）、夫々を多重化して１本のＭＰＥＧプログラムストリームにしている（Ｃ段）。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。

ＭＰＥＧシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順に基づいてビット列が形成されている訳ではない。これは多重化したＭＰＥＧシステムストリームのデコーダモデル（一般にＳｙｓｔｅｍ Ｔａｒｇｅｔ Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる（図３のＤ段））が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。例えばＤＶＤ−Ｖｉｄｅｏで規定されるデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、２３２ＫＢ、音声に対しては４ＫＢ、字幕に対しては５２ＫＢを夫々有している。

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

一方、次世代ＤＶＤ規格としてＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）がある。
ＤＶＤでは、標準画質（Ｓｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎ画質）の映像に対する、パッケージ配信（ＤＶＤ−Ｖｉｄｅｏ規格）やアナログ放送の記録（ＤＶＤ Ｖｉｄｅｏ Ｒｅｃｏｒｄｉｎｇ規格）を目的としてきたが、ＢＤでは、高精度画質（Ｈｉｇｈ
Ｄｅｆｉｎｉｔｉｏｎ画質）のデジタル放送をそのまま記録する（Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅｗｒｉｔａｂｌｅ規格、以下ＢＤ−ＲＥ）ことができる。

しかしながら、ＢＤ−ＲＥ規格は広くデジタル放送の記録を目的としているため、特殊再生の支援情報などが最適化されていない。将来的に、高精度映像をデジタル放送よりも高レートでパッケージ配信させることを考えると（ＢＤ−ＲＯＭ規格）、非通常再生時でもユーザにストレスを与えない仕組みが必要となってくる。

ＢＤ−ＲＥの特殊再生支援情報（タイムマップ）に関しては、特許文献１に公開されている。
特開２０００−２２８６５６号公報

従来の情報記録媒体では、動画と静止画において、１ピクチャ当りの符号量の上限値が同一であったため、静止画を高画質に符号化できないという課題がある。

たとえば、ＭＰＥＧ−４ ＡＶＣではピクチャの符号量の最大値が規定されている。ＢＤなどのアプリケーション規格では、ＭＰＥＧ−４ ＡＶＣにおける規定値、あるいはアプリケーションにおいて独自に設定した値をピクチャの符号量の上限値としている。上限値は、ＭＰＥＧ−４ ＡＶＣ規格において規定された、ＭｉｎＣＲ（Ｍｉｎｉｍｕｍ Ｃｏｍｐｒｅｓｓｉｏｎ Ｒａｔｉｏ）と呼ばれるパラメータにより制限できる。ＭｉｎＣＲとは、原画に対する符号化ピクチャの圧縮率の下限を示すパラメータである。例えば、ＭｉｎＣＲが２であれば、符号化ピクチャの符号量は、原画のデータサイズの２分の１以下であることを示す。

従来の情報記録媒体では、動画アプリケーションと静止画アプリケーションにおいて、ＭｉｎＣＲとして同一の値を使用していた。動画においては、符号化データを復号する際の処理量が大きくなることから、特に、１ピクチャを復号する際の演算量が規格で定められた上限値となるようなワーストケースにおいても動作を保証できるように、ＭｉｎＣＲが決定される。一方、静止画では、動画に比べて表示間隔が長いことから、復号時の処理量よりも、むしろ画質が重要となる。しかしながら、静止画を高画質に符号化すると符号量が増加するため、静止画と動画でＭｉｎＣＲが同一である従来の情報記録媒体では、特にイントラ符号化時に、ピクチャに対して十分なビットを割り当てられないという課題があった。

本発明は、動画と静止画とが混在する場合に、静止画を動画よりも高画質に符号化および復号化する画像符号化装置および画像復号化装置を提供することを目的とする。

上記目的を達成するため、本発明の画像符号化装置は、静止画および動画像を符号化する画像符号化装置であって、静止画の１ピクチャ当たりの符号量の上限を示す第１の上限と、動画像の１ピクチャ当たりの符号量の上限を示す第２の上限とを決定する決定手段と、前記第１および第２の上限を満たすように静止画および動画像を符号化する符号化手段と、符号化された静止画と符号化された動画像とを多重化することによりストリームを生成する多重化手段と、前記第１および第２の上限を特定する管理情報を生成する生成手段と、前記ストリームと管理情報とを出力する出力手段とを備える。ここで、前記第１の上限は、第２の上限よりも大きくしてもよい。

この構成によれば、静止画の符号量の上限（第１の上限）を動画像の符号量の上限（第２の上限）よりも大きくすることができる。これにより、動画と静止画とが混在する場合に、再生装置において動画像のデコード処理量を抑えつつ、静止画を動画像よりも高画質に符号化することができる。

ここで、前記管理情報は、前記ストリームの所定単位毎に対応するフラグを含み、前記フラグは、対応する所定単位が動画像であるか静止画であるかを示すようにしてもよい。

この構成によれば、ピクチャ当たりの符号量が第１の上限であるか第２の上限であるかをストリーム中の所定単位毎に決定することができる。さらに、画像符号化装置と画像復号化装置との間で第１および第２の上限をそれぞれ固定的に定めておけば、前記管理情報は、第１および第２の上限を必ずしも明示的に表す必要がなく、単に、所定単位のそれぞれが動画像であるか静止画あるかを示すだけで足りる。これにより、管理情報のデータ量をより低減することができる。

ここで、前記第１および第２の上限は、１ピクチャ当たりの符号量が原画のデータ量に対してどれだけ圧縮されているか示すようにしてもよい。

ここで、前記符号化された静止画は、静止画の復号時に参照される初期化情報を格納する第１の単位と、前記静止画の画素データを格納する第２の単位とを含み、前記第１の単位は、前記静止画を繰り返し表示する際のフレームレートを示す情報と、前記フレームレートを示す情報が前記第１の単位に存在するかどうかを示す識別フラグとを含むことができ、前記第１の単位が前記静止画のデータ内に存在する場合には、前記識別フラグがセットされているようにしてもよい。

この構成によれば、静止画の表示時刻および表示時間をフレームレートを基準に設定することができる。

ここで、前記管理情報は、前記ストリーム内の全ての静止画のアドレスに関する情報を有するようにしてもよい。

本発明の画像復号化装置は、符号化された動画像および符号化された静止画を含むストリームを取得する取得手段と、前記ストリームから符号化された静止画と符号化された動画像と分離する分離手段と、分離後の符号化された動画像および符号化された静止画を復号する復号化手段とを備え、前記復号化手段は、符号化された静止画のデコードタイムスタンプからプレゼンテーションタイムスタンプまでのデコード期間にマージンを付与し、付与後のデコード期間に従って符号化された静止画のデコードまたは出力を開始する。

この構成によれば、静止画１ピクチャ当たりの符号量が動画１ピクチャ当たりの符号量よりも多い場合に、動画よりも高画質の静止画を容易にかつ確実に復号化することができる。例えば、画像サイズが大きい静止画の復号時や、携帯電話など処理能力の小さい復号化装置であっても高画質の静止画を復号化することができる。

ここで、画像復号化手段は、符号化された静止画に含まれるデコードタイムスタンプの時刻にデコードを開始し、前記プレゼンテーションタイムスタンプの時刻までに静止画のデコードが完了しなかった場合に、前記プレゼンテーションタイムスタンプにマージンを付与し、付与後のプレゼンテーションタイムスタンプに復号化された静止画を出力するようにしてもよい。

この構成によれば、静止画のデコードが遅延した場合にのみ実際の出力時刻を遅くするので、静止画の符号量や復号時の処理量に応じて出力時刻を動的に柔軟に変更することができる。

ここで、画像復号化手段は、前記デコードタイムスタンプにマージンを付与し、付与後のデコードタイムスタンプの時刻に静止画のデコードを開始するようにしてもよい。

この構成によれば、デコード開始時刻をデコードタイムスタンプの時刻よりも早くするので、静止画の出力遅延を発生させないで、プレゼンテーションタイムスタンプの時刻に適合した再生をすることができる。

ここで、前記符号化された静止画は、静止画の復号時に参照される初期化情報を格納する第１の単位と、前記静止画の画素データを格納する第２の単位とを含み、前記第１の単位は、前記静止画を繰り返し表示する際のフレームレートを示す情報と、前記フレームレートを示す情報が前記第１の単位に存在するかどうかを示す識別フラグとを含むことができ、前記第１の単位が前記静止画のデータ内に存在する際には、前記識別フラグは必ずセットされ、前記復号化手段は、復号化が完了した静止画のプレゼンテーションタイムスタンプから、復号順が次の静止画のプレゼンテーションタイムスタンプまでの間、前記フレームレートに従って前記復号化が完了した静止画を出力するようにしてもよい。

また、本発明の画像符号化方法、画像復号化方法、半導体装置、符号列についても上記と同様の構成であるので、省略する。

以上のように、本発明の画像符号化装置、画像復号化装置等によれば、動画に比べて、静止画における１ピクチャ当りの符号量の上限値を大きく設定することにより、再生装置において動画再生時の処理量を抑えつつ、静止画再生時には高画質な静止画を再生できるという効果が得られ、その実用的価値が高い。

以下、本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
本実施の形態では、ＢＤ‐ＲＯＭなどのパッケージメディアなどにおいて、動画再生時の処理量を抑えつつ、静止画を高画質に符号化できる情報記録媒体、およびその再生装置について説明する。

本実施の形態における情報記録媒体では、動画と静止画のそれぞれに異なるＭｉｎＣＲを適用することにより、動画については復号時の処理量を鑑みてＭｉｎＣＲ値を大きくし、静止画については、高画質に符号化するために十分なピクチャサイズを保証できるように、動画よりもＭｉｎＣＲ値を小さくする。

図４は、本実施の形態の情報記録媒体のデータ構造例を示す。ＢＤ管理情報におけるストリーム管理情報には、ＣｌｉｐＩｎｆｏと呼ばれるデータ・オブジェクトにおいてクリップの属性情報が示される。なお、クリップとは、ＡＶデータのファイルを指し、例えば、ＭＰＥＧ−４ ＡＶＣの静止画ストリームを格納した１つのファイルが、１クリップとなる。動画と静止画とで異なるＭｉｎＣＲが適用されていることを示すには、クリップ毎のＭｉｎＣＲ値を示す情報が必要となる。従って、ＣｌｉｐＩｎｆｏには、参照するクリップにおいて適用されるＭｉｎＣＲ値を示す情報が付加される。ここでは、静止画のクリップと動画のクリップに対して適用されるＭｉｎＣＲ値が予め定められているものとして、参照するクリップが動画であるか静止画であるかを示すフラグ情報を格納することにより、クリップに適用されるＭｉｎＣＲ値を示すことにする。図４の例では、ディスク内に少なくとも静止画と動画のクリップが格納されており、それぞれＣｌｉｐＩｎｆｏ ＃１とＣｌｉｐＩｎｆｏ ＃２から参照される。ここで、ＣｌｉｐＩｎｆｏ ＃１にはクリップが静止画であることを示すフラグ情報、ＣｌｉｐＩｎｆｏ ＃２にはクリップが動画であることを示すフラグ情報が格納される。このフラグ情報を参照することにより、クリップを構成するピクチャにおけるＭｉｎＣＲ値を取得することができる。図４の例では、静止画のクリップにおけるＭｉｎＣＲを２、動画のクリップにおけるＭｉｎＣＲを４とすることにより、静止画の高画質化と動画復号時の処理量の抑制を両立している。なお、ここでのＭｉｎＣＲ値は一例であり、この他の組み合わせを使用してもよく、再生装置の処理量に余裕があるアプリケーションにおいては、静止画と動画のＭｉｎＣＲ値を同一にしてもよい。また、予め、静止画用と動画用のＭｉｎＣＲ値の組み合わせを複数定めておき、特定の組み合わせを示すパラメータを導入することによりＭｉｎＣＲ値を示してもよい。また、クリップは、ＭＰＥＧ−２システムのトランスポートストリームやプログラムストリームＡＶデータをパケット化したストリームであってもよい。

なお、ＣｌｉｐＩｎｆｏには、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅと呼ばれる、クリップを再生するアプリケーションのタイプを示すフィールドが存在する。本フィールドでは、アプリケーションが動画、静止画のどちらであるか、また、静止画である場合にはタイム・ベース、ブラウザブルのどちらであるかを示すことができる。ここで、タイム・ベースとは、予め定められた間隔で静止画を表示するものであり、ブラウザブルとは、ユーザが静止画の表示タイミングを決定できるアプリケーションである。従って、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅのフィールド値が、タイム・ベース、あるいはブラウザブルの静止画アプリケーションを指す際には、静止画用のＭｉｎＣＲ値が適用され、動画アプリケーションを指す際には、動画用のＭｉｎＣＲ値が適用されるとしてもよい。

なお、ＭｉｎＣＲ値は、動画と静止画で切り替える以外にも、異なる動画のクリップ間でも切り替えることができる。例えば、主映像と副映像が含まれる際には、主映像についてはＭｉｎＣＲ値を小さく設定して高画質に符号化し、副映像については処理量を考慮してＭｉｎＣＲ値を大きく設定することができる。このときは、ＭｉｎＣＲ値を示す情報としては、静止画であるか動画であるかを示すフラグ情報ではなく、クリップ毎のＭｉｎＣＲ値を示す情報を使用する。

なお、動画あるいは静止画の符号量の上限を示すパラメータはＭｉｎＣＲに制限されるものではなく、符号量の上限値をデータサイズとして直接示すなど、他のパラメータであってもよい。

なお、クリップにおけるピクチャの符号量の上限値を示す情報は、ＣｌｉｐＩｎｆｏ以外のＢＤ管理情報に格納してもよいし、符号化データ内に格納してもよい。符号化データに格納する際には、ＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）などのランダムアクセス単位毎に格納でき、例えば、ＭＰＥＧ−４ ＡＶＣでは、ユーザデータを格納するためのデータ単位を使用することができる。なお、ユーザデータ格納用のデータ単位としては、特定のタイプをもつＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニット、あるいは、ユーザデータ格納用のＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージなどがある。また、ピクチャの符号量の上限値は、ランダムアクセス単位など、クリップとは異なる単位で切り替え可能としてもよい。

また、データ再生装置によっては、動画を復号する際に、１ピクチャの符号化データを復号にかかる時間が予め定められた時間、あるいは、ピクチャの表示時刻に間に合わないと判定されると、当該ピクチャの復号をスキップして次ピクチャの復号を開始することがある。あるいは、動画の復号時にはワーストケースにも対応できる場合でも、本実施の形態の情報記録媒体における静止画を再生する際には、静止画の符号量の上限が動画よりも大きくなり、符号量が大きくなると復号に要する時間も増加するため、結果として静止画の復号がスキップされることがある。ここで、一般的に、静止画の表示間隔は動画に比べて長いために、予め設定された表示開始時刻までに復号が完了していなくても、復号完了後に表示すれば再生品質の低下は軽微である。従って、静止画の復号時は、予め設定された表示開始時刻までに復号が完了しない場合にも、復号をスキップせずに、復号完了後に表示すればよい。

なお、上記においてはＢＤについて説明したが、静止画と動画を格納することのできる情報記録媒体であれば、同様の方法を用いることができる。また、符号化方式もＭＰＥＧ−４ ＡＶＣに限定されるものではなく、ＭＰＥＧ−２ ＶｉｄｅｏやＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）において標準化中であるＶＣ１など他の符号化方式にも適用できる。

図５は、本実施の形態における情報記録媒体に格納されたデータを作成するための多重化方法を示すフローチャートである。本実施の形態の多重化方法は、クリップの種類に応じてＭｉｎＣＲ値を切り替えるステップ（ステップＳ２００１、ステップＳ２００２、およびステップＳ２００３）、および、ＭｉｎＣＲ値を特定するためのフラグ情報を生成して管理情報に含めるステップ（ステップＳ２００４とステップＳ２００５）とを備える点において、従来の多重化方法と異なる。

まず、ステップＳ２００１において、生成するクリップが動画であるか静止画であるか判定する。クリップが静止画である際には、ステップＳ２００２に進み、予め定められた静止画クリップ用のＭｉｎＣＲ値を設定し、クリップが動画である際には、ステップＳ２００３進み、予め定められた動画クリップ用のＭｉｎＣＲ値を設定する。次に、ステップＳ１００１において、ステップＳ２００２、あるいはステップＳ２００３において設定されたＭｉｎＣＲ値を満たすように、クリップを構成するピクチャを符号化し、ステップＳ１００２に進む。ステップＳ１００２では、ステップＳ１００１において符号化されたデータをシステム多重化する。ＢＤでは、システム多重化の方式としてＭＰＥＧ−２のトランスポートストリームを用いる。次に、ステップＳ２００４では、クリップを構成するピクチャに適用されるＭｉｎＣＲ値を特定するためのフラグ情報を生成し、ステップＳ２００５において、ステップＳ２００４において生成したフラグ情報を含んだ管理情報を生成する。最後に、ステップＳ１００３において、管理情報と、システム多重化された符号化データとを結合して出力する。ここで、結合時には、管理情報とシステム多重化された符号化データとを別ファイルとして格納してもよいし、一つのファイルにまとめてもよい。また、別ファイルとして格納する際には、同一ディレクトリに格納することにしてもよい。なお、ステップＳ２００１における静止画用のＭｉｎＣＲ値の設定は、ストリームのビットレート、レベル、プロファイルなどに基づいて定めればよい。ここで、レベルとはビットレートやフレームレート、あるいは画像サイズなどの符号化パラメータの上限値を示すパラメータであり、プロファイルとは符号化時に使用できるツールの組み合わせを規定するパラメータである。例えば、ストリームのビットレートが比較的低い場合は、ｍｉｎＣＲを小さく（符号量の上限を大きく）しても動画のフレームレート内で復号化を完了できるため、静止画と動画で同一のｍｉｎＣＲを用いればよい。逆に、ビットレートが比較的高い場合は、静止画のｍｉｎＣＲを動画よりも小さく（符号量の上限を大きく）することにより、静止画を高画質化するができる。また、ＭｉｎＣＲ値を特定するための情報としては、ピクチャの符号量の最大値を直接格納するなど、フラグ情報以外であってもよい。さらに、複数のクリップを扱う場合には、ステップＳ２００１からステップＳ２００５までの処理を繰り返し、全クリップのシステム多重化と管理情報の生成が終了してからステップＳ１００３において統合して出力してもよい。

さらに、静止画は動画とは異なり、各画像をある程度時間をかけて鑑賞できることが望ましいため、表示間隔が所定の値以上となるようにしてもよい。このとき、ステップＳ１００１では、復号順で連続する静止画の表示時刻が所定の値以上となるように符号化してもよい。なお、復号時刻および表示時刻の設定はステップＳ１００２で行うことから、ステップＳ１００２において復号順で連続する静止画の表示時刻が所定の値以上となるように設定するのみとしてもよい。このとき、ステップＳ１００１においては、入力画像を符号化する際に表示時刻の間隔を考慮しなくてもよい。

なお、音声、グラフィックスなどのデータについても、動画あるいは静止画とともに多重化することができるが、ここでは説明を省略する。

図６は、本実施の形態の多重化方法を実現する多重化装置２０００の構成を示すブロック図である。多重化装置２０００は、ＭｉｎＣＲ決定部２００１、ＭｉｎＣＲ情報生成部２００２、符号化部１００１、システム多重化部１００２、管理情報作成部２００３、結合部１００３を備え、ＭｉｎＣＲ決定部２００１、ＭｉｎＣＲ情報生成部２００２を備える点、および、管理情報作成部２００３においてＭｉｎＣＲ値を特定するためのフラグ情報を含む管理情報を生成する点において、従来の多重化装置と異なる。

以下に、各部の動作について説明する。ＭｉｎＣＲ決定部は、クリップが動画であるか静止画であるかを示すクリップ属性ＣｌｉｐＣｈａｒに基づいて、クリップを構成するピクチャに適用するＭｉｎＣＲ値を決定し、決定したＭｉｎＣＲ値ｃｒを符号化部１００１とＭｉｎＣＲ情報生成部２００２に入力する。符号化部１００１は、ＭｉｎＣＲ決定部により決定されたＭｉｎＣＲ値ｃｒに基づいて、入力の動画像あるいは画像データＶｉｎを符号化し、符号化データＣｄａｔａをシステム多重化部１００２に入力する。システム多重化部１００２は、符号化データＣｄａｔａをシステム多重化して多重化データＭｄａｔａを結合部１００３に入力する。一方、ＭｉｎＣＲ情報作成部は、ＭｉｎＣＲ値ｃｒに基づいて、クリップを構成するピクチャに適用されたＭｉｎＣＲ値を特定するためのフラグ情報であるＭｉｎＣＲ情報ｃｒＩｎｆを生成し、管理情報作成部２００３に入力する。管理情報生成部は、タイムマップなど、多重化データＭｄａｔａについての管理情報を生成するためのストリーム情報ＳｔｒＩｎｆをシステム多重化部１００２から取得して、ＭｉｎＣＲ情報ｃｒＩｎｆを含む管理情報ＣｔｒＩｎｆを生成し、結合部１００３に出力する。結合部１００３は、管理情報ＣｔｒＩｎｆと多重化データＭｄａｔａとを結合して記録データＤｏｕｔとして出力する。なお、ストリーム情報ＳｔｒＩｎｆは、符号化部１００１から管理情報作成部２００３に入力してもよい。

なお、オーサリングツールなどでデータを作成する際には、符号化データの生成と、システム多重化あるいは管理情報の作成を別々の装置で行うことがあるが、そのような場合でも、各装置の動作は多重化装置２０００における各部と同一にすればよい。

次に再生方法について説明する。動画ピクチャに比べて静止画の符号量が多い場合には、再生装置の処理能力にも依存するが、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ：復号時刻）からＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ：表示時刻）までのデコード期間内に静止画のデコードが間に合わないケースが起こり得る。このようなケースでも正常に静止画を再生出力するために、本実施の形態では、以下に示す第１または第２の再生方法により静止画を再生する。

図７Ａは、静止画ストリームの第１の再生方法を示す説明図である。同図において、ＤＴＳ１は、静止画ｐｉｃ１の符号を載せたパケット（ＰＥＳパケットと呼ばれる）ヘッダに含まれるデコードタイムスタンプの時刻を指し、静止画ｐｉｃ１のデコードを開始すべき時刻を示す。ＰＴＳ１は、静止画ｐｉｃ１の符号を載せたパケットヘッダに含まれるプレゼンテーションタイムスタンプの時刻を指し、静止画ｐｉｃ１のプレゼンテーション（出力または表示）を開始すべき時刻を示す。ＤＴＳ２、ＤＴＳ３、ＰＴＳ２、ＰＴＳ３についても同様である。

同図の静止画ｐｉｃ２は、ＤＴＳ２の時刻にデコードを開始し、デコード完了時刻がＰＴＳ２の時刻の後であった場合を示している。第１の再生方法では、静止画のデコード完了時刻がＰＴＳの時刻に間に合わなかった場合に、デコード完了時刻の直後のフレームグリッドの時刻においてプレゼンテーションを開始するようにしている。

このように第１の再生方法では、符号化された静止画に含まれるデコードタイムスタンプの時刻にデコードを開始し、前記プレゼンテーションタイムスタンプの時刻までに静止画のデコードが完了しない場合に、前記プレゼンテーションタイムスタンプにマージンを付与し、付与後のプレゼンテーションタイムスタンプに復号化された静止画を出力するよ
うにしている。

図７Ｂは、静止画ストリームの第２の再生方法を示す説明図である。第２の再生方法は、ＤＴＳにマージンを付与し、マージンを付与した時刻に静止画のデコードを開始し、ＰＴＳの時刻に出力するようにしている。

図８は、静止画ストリームの第１の再生方法を示すフローチャートである。同図のように、第１の再生方法では、静止画ピクチャ（ｐｉｃ＿Ｎ）のＤＴＳ時刻においてｐｉｃ＿Ｎのデコードを開始し（Ｓ３００１）、静止画ピクチャ（ｐｉｃ＿Ｎ）のＰＴＳ（ＰＴＳ＿Ｎ）時刻においてその復号を完了したかを判定し（Ｓ３００２）、完了した場合にはＰＴＳ（ＰＴＳ＿Ｎ）時刻に復号された静止画ピクチャ（ｐｉｃ＿Ｎ）を出力し（Ｓ３００３）、完了しなかった場合には復号完了の直後のフレームグリッドの時刻に復号された静止画ピクチャ（ｐｉｃ＿Ｎ）を出力する（Ｓ３００４）。

このように第１の再生方法によれば、静止画のデコードが遅延した場合にのみ実際の出力時刻を遅くするので、静止画の符号量に応じて出力時刻を動的に柔軟に変更することができる。

図９は、静止画ストリームの第２の再生方法をフローチャートである。同図のように、第２の再生方法では、静止画ストリームであるか否かを判定し（Ｓ４００１）、静止画ストリームである場合にはピクチャ（ｐｉｃ＿Ｎ）のＤＴＳ時刻よりも、所定時間Ｔだけ早い時刻にｐｉｃ＿Ｎのデコードを開始し（Ｓ４００２）、静止画ストリームでない場合（動画ストリームである場合）にはＤＴＳ時刻において復号を開始する（４３００３）。ここで所定時間Ｔは、ＤＴＳに付与されるマージンであり、マージンが付与されたＤＴＳからＰＴＳまでの時間が最大符号量の静止画のデコードに要する時間よりも小さくならないように定められる。

この第２の再生方法によれば、デコード開始時刻をＤＴＳ時刻よりも早くするので、静止画の出力遅延を発生させないで、ＰＴＳ時刻に適合した再生をすることができる。

なお、図９では全ての静止画に対してデコード開始時刻を早くするが、静止画の符号量がしきい値を超える場合にのみデコード開始時刻を早くするようにしてもよい。例えば、図７Ｂのｐｉｃ１、ｐｉｃ３の符号量がしきい値以下であり、ｐｉｃ２の符号量がしきい値を超えている場合には、ｐｉｃ１、ｐｉｃ３のデコード開始時刻はＤＴＳ１、ＤＴＳ３時刻となる。ｐｉｃ２のデコード開始時刻は（ＤＴＳ２−Ｔ）となる。また、画像サイズやビットレート、あるいはレベルなどのパラメータが所定の値を超える場合にのみステップＳ４００２の処理を行ってもよい。

また、図８、図９に示した第１、第２の再生方法は、後述する図１２のプレゼンテーション管理部２０８、図１３および図１７のビデオプロセッサ、あるいは図１３の合成処理部により実行され、図３３のＳ４０４に含まれる。

（ディスク上の論理データ構造）
図１０は、ＢＤ−ＲＯＭの構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報およびＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、説明の都合上、映画のＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、他の用途として用いても勿論同様である。

図１１は、上述したＢＤディスクに記録されている論理データのディレクトリ・ファイル構成を示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがある。

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

本実施例の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤで扱うＡＶコンテンツや管理情報などのデータ（図１０で説明した１０１、１０２、１０３）が格納されているディレクトリである。

ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。

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

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

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

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

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

ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕およびメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。

（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図１２および図１３を用いて説明する。

図１２は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに転送される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々転送される。

プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。

プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、それを実行する。

管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリストおよびプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。

プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ（静止画）の夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコードおよび出力を行う。映像データ、字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）およびイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。

このように図１２に示すように、ＢＤプレーヤは図１０で示したＢＤディスクに記録されているデータ構成に基づいた機器構成をとっている。

図１３は前述したプレーヤ構成を詳細化したブロック図である。図１３では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。

ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）およびサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。

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

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

イメージデータおよび映像データは、図１２で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に出力され、合成処理部（３１６）によって合成後出力される。

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

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

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

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

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

（アプリケーション空間）
図１４は、ＢＤのアプリケーション空間を示す図である。

ＢＤのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の連結で、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤの場合、メニューとはユーザの選択によって再生するシナリオと定義でき、プログラムによってプレイリストを動的に選択することである。

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

時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図１３で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。

ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。

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

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

（ＶＯＢの詳細）
図１５は、本実施例で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。

図１５に示すように、ＶＯＢは複数のＶＯＢＵ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは１．０秒以下のビデオ再生時間を持ち、通常は０．５秒程度の再生時間を持っている。

ＶＯＢＵ先頭のＴＳパケット（ＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ Ｐａｃｋｅｔ）は、シーケンスヘッダとそれに続くＧＯＰヘッダとＩピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ）を格納しており、このＩピクチャからの復号が開始可能なようになっている。また、このＶＯＢＵ先頭のＩピクチャの先頭を含むＴＳパケットのアドレス（開始アドレス）と、この開始アドレスからＩピクチャの最後を含むＴＳパケットまでのアドレス（終了アドレス）と、このＩピクチャの再生開始時刻（ＰＴＳ）をタイムマップで管理している。したがって、タイムマップのエントリーはＶＯＢＵ先頭のＴＳパケットごとに与えられている。

ＶＯＢＵは、その内部にビデオパケット（Ｖ＿ＰＫＴ）とオーディオパケット（Ａ＿ＰＫＴ）を有している。各パケットは１８８バイトであり、図１５に図示してはいないが、各ＴＳパケットの直前には、そのＴＳパケットの相対的なデコーダ供給開始時刻であるＡＴＳ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ）が付与されている。

ＡＴＳを各ＴＳパケットごとに付与するのは、このＴＳストリームのシステムレートが固定レートでなく、可変レートであるためである。一般的にシステムレートを固定にする場合にはＮＵＬＬパケットと呼ばれるダミーのＴＳパケットを挿入することになるが、限られた記録容量の中に高画質で記録するためには、可変レートが適しており、ＢＤではＡＴＳ付きのＴＳストリームとして記録している。

図１６は、ＴＳパケットの構成を示した図である。
図１６に示すように、ＴＳパケットは、ＴＳパケットヘッダと、適用フィールドと、ペイロード部から構成される。ＴＳパケットヘッダにはＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）が格納され、これにより、ＴＳパケットがどのような情報を格納しているのか識別される。適用フィールドにはＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が格納される。ＰＣＲはストリームをデコードする機器の基準クロック（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ、ＳＴＣと呼ぶ）の参照値である。機器は典型的にはＰＣＲのタイミングでシステムストリームをデマルチプレクスし、ビデオストリーム等の各種ストリームを再構築する。ペイロードにはＰＥＳパケットが格納される。

ＰＥＳパケットヘッダには、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）とＰ
ＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が格納される。ＤＴＳは当該ＰＥＳパケットに格納されるピクチャ／オーディオフレームのデコードタイミングを示し、ＰＴＳは映像音声出力等のプレゼンテーションタイミングを示す。ビデオデータおよびオーディオデータといったエレメンタリーデータは、ＰＥＳパケットペイロード（ＰＥＳ Ｐａｃｋｅｔ Ｐａｙｌｏａｄ）と呼ばれるパケット（ＰＥＳ Ｐａｃｋｅｔ）のデータ格納領域に先頭から順次入れられていく。ＰＥＳパケットヘッダには、ペイロードに格納してあるデータがどのストリームなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）も記録されている。

ＴＳストリームの詳細についてはＩＳＯ／ＩＥＣ１３８１８−１で規定されており、ＢＤで特徴的なのはＡＴＳを各ＴＳパケットごとに付与したことである。

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

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

トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＡＴＳに従って個々のＴＳパケットはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、そのメニュー描画中はイメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存しており、ユーザの操作に追従してメニューの一部分を再表示もしくは異なるイメージに置き換えることがあり、その際に再表示される部分のイメージデータをデコードし易くするためである。

図１７下段は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出し、デコーダに送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。

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

そこで、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図１７下段はそのインターリーブ記録を説明した図である。

ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。

図１８は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。

既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート（Ｖａ）とトラックバッファからのデータ出力レート（Ｖｂ）の間に差（Ｖａ＞Ｖｂ）を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。

図１８の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。

図１８の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。

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

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

ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。

この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）

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

（ナビゲーションデータ構造）
図１９から図２５を用いて、ＢＤのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。

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

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

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

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

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

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

タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵ先頭ＴＳパケット（Ｉピクチャ開始）のアドレスＩ＿ｓｔａｒｔと、そのＩピクチャの終了アドレスまでのオフセットアドレス（Ｉ＿ｅｎｄ）、およびそのＩピクチャの再生開始時刻（ＰＴＳ）から構成される。

なお、Ｉ＿ｅｎｄの値はオフセット値、すなわちＩピクチャのサイズを持たせるのではなく、実際のＩピクチャの終了アドレスを持たせてもよい。

図２０はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧビデオストリームは高画質記録するために可変ビットレート圧縮されることがあり、その再生時間とデータサイズ間に単純な相関はない。逆に、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一次式の形で表現することは不可能である。

当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータサイズとを一次式の形で表現することは不可能である。このため、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。

このようにして、ある時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索（ＶＯＢＵ毎のＰＴＳを追っていく）して、当該時刻の直前のＰＴＳをＴＭＡＰに持つＶＯＢＵに飛びこみ（Ｉ＿ｓｔａｒｔで指定されたアドレス）、ＶＯＢＵ先頭のＩピクチャから復号を開始し、当該時刻のピクチャから表示を開始する。

次に図２１を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。

セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。

セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップを使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。

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

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

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

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

イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。前述の”ＸＸＸ．ＰＬ”のイベントリスト（ＥｖｅｎｔＬｉｓｔ）に格納されたイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は”ＸＸＸ．ＰＲＯＧ”のイベントハンドラのＩＤ（ＩＤ）を用いて特定される。

次に図２３を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造を説明する。

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

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

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

イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。

図２４は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。

本テーブルは、図２２で説明したイベントハンドラテーブルと同一内容である。

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

図２５はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、２つのボタンイメージの描画を行うなどを行うことができる。

図２６はメニュー操作を行うユーザイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効期間情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。

図２６に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、プレイリスト＃２の再生を開始する。

生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。

図２７はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。

ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合ではプレイリスト＃３の再生を開始している。

本実施例では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。

（仮想プレーヤマシン）
図２８を用いてプログラムプロセッサの機能構成を説明する。

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

仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、ＪａｖａＳｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ固有関数として定義している。

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

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

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

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

（プログラムの例）
図３０および図３１は、イベントハンドラでのプログラムの例である。

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

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

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

図３１は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２６で説明したとおり、ユーザイベントが生成され、図３１のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。

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

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

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

上記のようにして実行処理が行われる。

（プレーヤ処理フロー）
次に図３２から図３５を用いてプレーヤでの処理フローを説明する。

図３２は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。

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

ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。（Ｓ２０１）。ＢＤプレーヤはユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。

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

図３３は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。

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

ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。

図３４は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。

Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。

ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。

Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。

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

ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。

図３５は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。

字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。

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

実施の形態２は、上記のアプリケーションを応用して、静止画によるスライドショーを実現するための説明である。基本的には実施例１に基づく内容であり、拡張または異なる部分を中心に説明する。

（Ｉピクチャの参照）
図３６はスライドショー（静止画アプリケーション）とタイムマップの関係を示している。通常スライドショーは静止画（Ｉピクチャ）のみから構成されている。タイムマップは静止画データの位置とサイズ情報を持っており、ある静止画が選ばれた場合、必要なデータを取り出してデコーダに送ることにより、１枚の静止画を表示する。通常スライドショーは動画のように順番に表示されるとは限らず、ユーザのインタラクションのより、表示順序が決まっていないため、どこからでも表示できることを保証するために、単独でデコード可能なイントラ符号化されたＩピクチャを利用している。

しかし、データ量を抑えるために、Ｉピクチャを参照して圧縮するＰピクチャや２枚以上の前後のピクチャを参照して圧縮するＢピクチャであってもスライドショーを実現することは可能である。

ところが、ＰピクチャやＢピクチャは参照しているピクチャがないとデコードすることができない。そのため、ユーザのインタラクションにより、途中にあるＰピクチャやＢピクチャから再生を開始しようとしてもデコードできない。そこで、図３７に示すように、タイムマップが指しているピクチャがＩピクチャであること、他のどの画像も参照していないことを示すフラグを用意する。このフラグを参照することにより、参照画像が必要ない場合、すなわち独立してデコード可能な場合には、前後の表示に関係なくその画像からデコードおよび表示することは可能だが、参照画像が必要な場合には、関連する画像がそれまでにデコードされていなければ表示できないため、表示順序によっては画像が表示できないことを示している。

なお、タイムマップ全体として、タイムマップから参照されるピクチャが必ずＩピクチャであること、つまりどのピクチャも独立してデコードすることが可能であることを示すフラグを、図３８のようにタイムマップあるいは関連するナビゲーション情報内の一箇所に記録されていてもよい。このフラグが立っていない場合には、タイムマップのエントリが必ずＩピクチャを指しているとは限らないため、参照されているピクチャをデコードできるかどうかは保証されないことになる。

なお、これまでの説明ではＭＰＥＧ２ビデオストリームをもとにＩピクチャとして説明していたが、ＭＰＥＧ４−ＡＶＣ（Ｈ．２６４やＪＶＴとも呼ばれる）の場合では、ＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ ｒｅｆｒｅｓｈ）ピクチャ、あるいはＩＤＲピクチャ以外のＩピクチャであってもよく、また、その他の形式の画像の場合でも単独でデコード可能な画像であれば、容易に応用可能である。
（すべてのＩピクチャの参照の保証）
図３９は動画アプリケーションと静止画アプリケーション（スライドショー）の違いを示している。図３９（ａ）が示すように、動画アプリケーションの場合は一度再生を開始すれば、以降のピクチャを連続的にデコードするため、すべてのＩピクチャにタイムマップから参照を設定しておく必要はなく、最低限再生開始したい点にのみタイムマップのエントリーが設定されていればよい。

図３９（ｂ）はスライドショーの例である。スライドショーの場合は、ユーザの操作により前後の映像を表示せず、スキップ操作などのより順序に関係なく静止画を表示する必要がある。そのため、すべてのＩピクチャに対してタイムマップのエントリーを登録しておかなければ、実際にストリームをすべて解析しなければ表示すべきＩピクチャのデータをデコーダに流すことができないため、効率が悪い。各Ｉピクチャにタイムマップのエントリーがあれば、必要なＩピクチャのデータのみを直接アクセスしてデータを読み込み、デコーダに流すことができるため、アクセス効率がよく、表示までの時間も短くてすむため効率がよい。

すべてのＩピクチャに対してエントリーが存在することが識別できれば、どのＩピクチャにアクセスする際にでもタイムマップのエントリーを参照することにより、読み出すデータの範囲が分かるため、前後のストリームを余分に解析する必要がなくなる。

すべてのＩピクチャに対してエントリーが存在することが保証されていない場合、タイムマップに登録されていないＩピクチャの表示を指定された場合、その前後のストリームを解析しながら必要なデータを抜き出さなければならず、アクセス効率が悪く、表示するまでに時間がかかるため効率が悪い。

そこで、図４０に示すようにタイムマップ内に、すべてのＩピクチャがタイムマップから参照されていることが保証されているか否かを示すフラグを用意することにより、前後のストリームを解析しなければいけないか、あるいは必要ないか、静的データを解析するだけで識別できるようになるため、このようなフラグは有効である。

なお、このフラグはスライドショーのような静止画アプリケーションだけではなく、動画アプリケーションにおいても有効であり、どのＩピクチャからでも再生を開始できることが保証されるフラグとなる。

（実施の形態３）
実施の形態２において、静止画アプリケーションを実現するための符号化方式としてＭＰＥＧ‐４ ＡＶＣを使用できることを述べた。ＭＰＥＧ−４ ＡＶＣの静止画は、ＭＰＥＧ−４ＡＶＣ規格自体ではなく、ＭＰＥＧ−２システムのＭＰＥＧ−４ ＡＶＣ向け拡張規格（ＩＳＯ／ＩＥＣ １３８１８−１ Ａｍｅｎｄｍｅｎｔ ３）においてＡＶＣ Ｓｔｉｌｌ Ｐｉｃｔｕｒｅとして規定されている。しかしながら、ＭＰＥＧ−２システム規格では静止画の再生方法について規定しておらず、ＭＰＥＧ−４ ＡＶＣの静止画を再生する際の表示タイミングなどを決定できず、再生機器が任意のタイミングで表示を行っていたため機器間での再生動作の互換性が取れないという課題があった。本実施の形態では、ＭＰＥＧ−４ ＡＶＣを静止画アプリケーションに適用するための静止画のデータ構造、および表示方法について説明する。

ＭＰＥＧ−２システム規格におけるＡＶＣ Ｓｔｉｌｌ Ｐｉｃｔｕｒｅは、ＩＤＲピクチャ、および当該ＩＤＲピクチャから参照されるＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、および（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）を含むと規定されている。図４１は、本実施の形態におけるＭＰＥＧ−４ ＡＶＣの静止画（以降、ＡＶＣ静止画と呼ぶ）のデータ構造を示す。図中のボックスは、それぞれＮＡＬユニット（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｕｎｉｔ）を示す。ＡＶＣ静止画では、Ｅｎｄ ｏｆ ＳｅｑｕｅｎｃｅのＮＡＬユニットを必ず含めることにする。Ｅｎｄ ｏｆ Ｓｅｑｕｅｎｃｅは、ＭＰＥＧ−４ ＡＶＣにおけるシーケンスの終端を示す識別情報であるため、Ｅｎｄ ｏｆ ＳｅｑｕｅｎｃｅのＮＡＬユニットを配置してシーケンスを終了させることにより、ＡＶＣ静止画の表示方法についてはＭＰＥＧ−４ ＡＶＣ規格外で独自に定義することができる。ここで、各ＮＡＬユニットの出現順序についてはＭＰＥＧ−４ ＡＶＣ規格において定められた規定に従うものとする。なお、Ｅｎｄ ｏｆ Ｓｅｑｕｅｎｃｅの代わりに、Ｅｎｄ ｏｆ ＳｔｒｅａｍのＮＡＬユニットをＡＶＣ静止画の終端に配置してもよい。

次に、図４２を参照してＡＶＣ静止画の表示方法について説明する。静止画アプリケーションにおいては、静止画の表示時刻、および静止画の表示時間長を規定する必要がある。ＡＶＣ静止画の表示時刻（ＰＴＳ：Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）は、タイムマップ、あるいはＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍａｎｔａｒｙ Ｓｔｒｅａｍ）パケットのヘッダから取得する。ここで、タイムマップにより全ての静止画の表示時刻が示される際には、タイムマップのみを参照して表示時刻を取得することができる。Ｎ番目のＡＶＣ静止画の表示時刻から、Ｎ＋１番目のＡＶＣ静止画の表示時刻までの間は、Ｎ番目のＡＶＣ静止画の表示をフリーズする、すなわち、Ｎ番目のＡＶＣ静止画を繰り返し表示することにする。

ＡＶＣ静止画を再生する際には、ＡＶＣ静止画のデータからフレームレートを取得できることが望ましい。ＭＰＥＧ−４ ＡＶＣにおいては、動画ストリームの表示レートを、ＳＰＳ内のＶＵＩ（Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）により示すことができる。具体的には、ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋ、ｔｉｍｅ＿ｓｃａｌｅ、ｆｉｘｅｄ＿ｆｒａｍｅ＿ｒａｔｅ＿ｆｌａｇの３つのフィールドを参照する。ここで、ｔｉｍｅ＿ｓｃａｌｅはタイムスケールを示し、例えば、３００００Ｈｚで動作するクロックのｔｉｍｅ＿ｓｃａｌｅは３００００とできる。ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋは、クロックが動作する時間を示す基本単位であり、例えば、ｔｉｍｅ＿ｓｃａｌｅが３００００であるクロックのｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋが１００１であれば、クロックが動作する際の基本周期が２９．９７Ｈｚであることを示せる。また、ｆｉｘｅｄ＿ｆｒａｍｅ＿ｒａｔｅ＿ｆｌａｇをセットすることにより、フレームレートが固定であると示すことができる。ＭＰＥＧ−４ ＡＶＣにおいては、これらのフィールドを用いて、連続する２枚のピクチャの表示時刻の差分値を示すことができるが、本実施の形態では、これらのフィールドを用いて、ＡＶＣ静止画を繰り返し表示する際のフレームレートを示すことにする。まず、ｆｉｘｅｄ＿ｆｒａｍｅ＿ｒａｔｅ＿ｆｌａｇを１にセットすることにより、フレームレートが固定であることを示す。次に、フレームレートを２３．９７６Ｈｚに設定する際には、例えばｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋを１００１に、ｔｉｍｅ＿ｓｃａｌｅを２４０００に、それぞれセットする。つまり、フレームレート ＝ｔｉｍｅ＿ｓｃａｌｅ／ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋ となるように両フィールドを設定する。さらに、ＶＵＩ、およびＶＵＩにおける上記３つのフィールドが存在することを保証するために、ＳＰＳ内のｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、およびＶＵＩ内のｔｉｍｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを共に１にセットする。Ｎ番目のＡＶＣ静止画が、最終のＡＶＣ静止画である際には、ユーザ動作があるまで、あるいは、プログラムにより予め定められた次の動作等が開始するまで表示をフリーズさせることとする。なお、フレームレートの設定方法は、ｔｉｍｅ＿ｓｃａｌｅ／ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋに制限されるものではない。例えば、ＭＰＥＧ−４ ＡＶＣの動画ストリームにおいては、ｔｉｍｅ＿ｓｃａｌｅ／ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋはフィールドのレート（フィールドの表示間隔を示すパラメータ）を示すため、フレームレートはｔｉｍｅ＿ｓｃａｌｅ／ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋ／２となる。従って、静止画においてもフレームレートをｔｉｍｅ＿ｓｃａｌｅ／ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃ／２としてもよい。

上記の方法により示されるフレームレートは、ＢＤ管理情報内で示されるフレームレート値と一致するものとする。具体的には、ストリームの符号化パラメータを示す情報であるＳｔｒｅａｍＣｏｄｉｎｇＩｎｆｏにおけるｆｒａｍｅ＿ｒａｔｅフィールドにより示される値と一致する。

なお、ＡＶＣ静止画を繰り返し表示する際の表示周期は、上記の方法により示されるフレームレートから取得できる。この表示周期を、フレームグリッド、あるいはフィールドグリッドの整数倍としてもよい。ここで、グリッドとは、フレームあるいはフィールドを表示できるタイミングを示す。こうすることで、ビデオ、グラフィックスなど他の映像ソースとの同期再生を保証することができる。ここで、フレームグリッド、あるいはフィールドグリッドはビデオなど特定のストリームのフレームレートを基準として生成される。さらに、Ｎ番目とＮ＋１番目のＡＶＣ静止画の表示時刻の差分値は、フレームグリッド、あるいはフィールドグリッドの整数倍とすることにしてもよい。

ＡＶＣ静止画を再生する際に参照するタイムマップとしては、実施の形態２におけるタイムマップを使用する。

なお、ＢＤ ＲＯＭ規格などにおいて、ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋ、ｔｉｍｅ＿ｓｃａｌｅ、ｆｉｘｅｄ＿ｆｒａｍｅ＿ｒａｔｅ＿ｆｌａｇのデフォルト値を規定することにより、これらのフィールドを省略することにしてもよい。

なお、ビデオストリームの場合にはストリーム内で解像度を変更することは禁止されているが、静止画のストリームでは解像度を変換しても復号動作におけるバッファ管理などを破綻なく実現できるため、ストリーム内で解像度を変更できることにしてもよい。ここで、解像度はＳＰＳ内のフィールドにより示される。

なお、ＭＰＧＥ−４ ＡＶＣ以外の符号化方式であっても、同様のデータ構造をもつ場合には、本実施の形態のデータ構造、および再生方法を適用できる。

（実施の形態４）
さらに、上記各実施の形態で示した情報記録媒体、その符号化方法、復号化方法および多重化方法を実現するためのプログラムを、フレキシブルディスク等の記録媒体に記録するようにすることにより、上記各実施の形態で示した処理を、独立したコンピュータシステムにおいて簡単に実施することが可能となる。

図４３Ａ〜図４３Ｃは、上記各実施の形態の符号化方法および復後か方法を、フレキシブルディスク等の記録媒体に記録されたプログラムを用いて、コンピュータシステムにより実施する場合の説明図である。

図４３Ｂは、フレキシブルディスクの正面からみた外観、断面構造、及びフレキシブルディスクを示し、図４３Ａは、記録媒体本体であるフレキシブルディスクの物理フォーマットの例を示している。フレキシブルディスクＦＤはケースＦ内に内蔵され、該ディスクの表面には、同心円状に外周からは内周に向かって複数のトラックＴｒが形成され、各トラックは角度方向に１６のセクタＳｅに分割されている。従って、上記プログラムを格納したフレキシブルディスクでは、上記フレキシブルディスクＦＤ上に割り当てられた領域に、上記プログラムが記録されている。

また、図４３Ｃは、フレキシブルディスクＦＤに上記プログラムの記録再生を行うための構成を示す。符号化方法および復号化方法を実現する上記プログラムをフレキシブルディスクＦＤに記録する場合は、コンピュータシステムＣｓから上記プログラムをフレキシブルディスクドライブを介して書き込む。また、フレキシブルディスク内のプログラムにより符号化方法および復号化方法を実現する再生方法および記録方法をコンピュータシステム中に構築する場合は、フレキシブルディスクドライブによりプログラムをフレキシブルディスクから読み出し、コンピュータシステムに転送する。

なお、上記説明では、記録媒体としてフレキシブルディスクを用いて説明を行ったが、光ディスクを用いても同様に行うことができる。また、記録媒体はこれに限らず、ＩＣカード、ＲＯＭカセット等、プログラムを記録できるものであれば同様に実施することができる。

なお、図６、図１２、図１３等に示したブロック図の各機能ブロックは典型的には集積回路装置であるＬＳＩとして実現される。このＬＳＩは１チップ化されても良いし、複数チップ化されても良い。（例えばメモリ以外の機能ブロックが１チップ化されていても良い。）ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ
ル・プロセッサを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。

また、各機能ブロックのうち、データを格納するユニットだけ１チップ化せずに、本実施形態の記録媒体１１５のように別構成としても良い。

なお、図６、図１２、図１３等に示したブロック図の各機能ブロックおよび図５、図７〜図９、図３２、図３３に示したフローチャートにおいて、中心的な部分はプロセッサおよびプログラムによっても実現される。

このように、上記実施の形態で示した画像符号化方法あるいは画像復号化方法を上述したいずれの機器・システムに用いることは可能であり、そうすることで、上記実施の形態で説明した効果を得ることができる。

本発明は、画像を符号化又は復号化するする符号化装置、復号化装置に適しており、動画配信するウェブサーバー、それを受信するネットワーク端末、動画の記録再生可能なデジタルカメラ、カメラ付き携帯電話機、ＢＤなどの光ディスク録画／再生機、ＰＤＡ、パーソナルコンピュータ等に適している。

図１は、ＤＶＤの構成図である。 図２は、ハイライトの構成図である。 図３は、ＤＶＤでの多重化の例を示す図である。 図４は、実施の形態１におけるクリップに対して特定のＭｉｎＣＲ値が適用されることを示すフラグ、およびデータ構造を説明する図である。 図５は、多重化方法の動作を示すフローチャートである。 図６は、多重化装置の構成を示すブロック図である。 図７Ａは、静止画ストリームの第１の再生方法を示す説明図である。 図７Ｂは、静止画ストリームの第２の再生方法を示す説明図である。 図８は、静止画ストリームの第１の再生方法を示すフローチャートである。 図９は、静止画ストリームの第２の再生方法をフローチャートである。 図１０は、ＨＤ−ＤＶＤのデータ階層図である。 図１１は、ＨＤ−ＤＶＤ上の論理空間の構成図である。 図１２は、ＨＤ−ＤＶＤプレーヤの概要ブロック図である。 図１３は、ＨＤ−ＤＶＤプレーヤの構成ブロック図である。 図１４は、ＨＤ−ＤＶＤのアプリケーション空間の説明図である。 図１５は、ＭＰＥＧストリーム（ＶＯＢ）の構成図である。 図１６は、パックの構成図である。 図１７は、ＡＶストリームとプレーヤ構成の関係を説明する図である。 図１８は、トラックバッファへのＡＶデータ連続供給モデル図である。 図１９は、ＶＯＢ情報ファイル構成図である。 図２０は、タイムマップの説明図である。 図２１は、プレイリストファイルの構成図である。 図２２は、プレイリストに対応するプログラムファイルの構成図である。 図２３は、ＢＤディスク全体管理情報ファイルの構成図である。 図２４は、グローバルイベントハンドラを記録するファイルの構成図である。 図２５は、タイムイベントの例を説明する図である。 図２６は、ユーザイベントの例を説明する図である。 図２７は、グローバルイベントハンドラの例を説明する図である。 図２８は、仮想マシンの構成図である。 図２９は、プレーヤ変数テーブルの図である。 図３０は、イベントハンドラ（タイムイベント）の例を示す図である。 図３１は、イベントハンドラ（ユーザイベント）の例を示す図である。 図３２は、プレーヤの基本処理のフローチャートである。 図３３は、プレイリスト再生処理のフローチャートである。 図３４は、イベント処理のフローチャートである。 図３５は、字幕処理のフローチャートである。 図３６は、タイムマップと静止画の関係を説明する図である。 図３７は、参照するピクチャがデコード可能か否かを示すフラグを説明する図である。 図３８は、すべてのエントリがＩピクチャを参照することを示すフラグを説明する図である。 図３９は、動画アプリケーションとスライドショーの違いを説明する図である。 図４０は、すべてのＩピクチャが参照されていることを保証するフラグを説明する図である。 図４１は、ＭＰＥＧ−４ ＡＶＣにおける静止画のデータ構造を示す図である。 図４２は、ＭＰＥＧ−４ ＡＶＣにおける静止画の再生方法を説明する図である。 図４３Ａは、記録媒体本体であるフレキシブルディスクの物理フォーマットの例を示している。 図４３Ｂは、フレキシブルディスクの正面からみた外観、断面構造、及びフレキシブルディスクを示す。 図４３Ｃは、フレキシブルディスクＦＤに上記プログラムの記録再生を行うための構成を示す。

符号の説明

２０１ ＢＤディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０１ プログラム記録メモリ
３０２ プログラムプロセッサ
３０３ ＵＯＰマネージャ
３０４ 管理情報記録メモリ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１４ イメージプレーン
３１５ ビデオプレーン
３１６ 合成処理部
３１７ ドライブコントローラ
１００１ 符号化部
１００２ システム多重化部
１００３ 結合部
２０００ 多重化装置
２００１ ＭｉｎＣＲ決定部
２００２ ＭｉｎＣＲ情報生成部
２００３ 管理情報作成部
３２０７ 動画ダウンコンバータ
３２１５ 字幕ダウンコンバータ
３２２３ 静止画ダウンコンバータ
３２２８ 音声ダウンコンバータ
Ｓ１０１ ディスク挿入ステップ
Ｓ１０２ ＢＤ．ＩＮＦＯ読み込みステップ
Ｓ１０３ ＢＤ．ＰＲＯＧ読み込みステップ
Ｓ１０４ ファーストイベント生成ステップ
Ｓ１０５ イベントハンドラ実行ステップ
Ｓ２０１ ＵＯＰ受付ステップ
Ｓ２０２ ＵＯＰイベント生成ステップ
Ｓ２０３ メニューコール判定ステップ
Ｓ２０４ イベント生成ステップ
Ｓ２０５ イベントハンドラ実行ステップ
Ｓ３０１ プレイリスト再生開始ステップ
Ｓ３０２ プレイリスト情報（ＸＸＸ．ＰＬ）読み込みステップ
Ｓ３０３ プレイリストプログラム（ＸＸＸ．ＰＲＯＧ）読み込みステップ
Ｓ３０４ セル再生開始ステップ
Ｓ３０５ ＡＶ再生開始ステップ
Ｓ４０１ ＡＶ再生開始ステップ
Ｓ４０２ ＶＯＢ情報（ＹＹＹ．ＶＯＢＩ）読み込みステップ
Ｓ４０３ ＶＯＢ（ＹＹＹ．ＶＯＢ）読み込みステップ
Ｓ４０４ ＶＯＢ再生開始ステップ
Ｓ４０５ ＶＯＢ再生終了ステップ
Ｓ４０６ 次セル存在判定ステップ
Ｓ５０１ プレイリスト再生開始ステップ
Ｓ５０２ プレイリスト再生終了判定ステップ
Ｓ５０３ タイムイベント時刻判定ステップ
Ｓ５０４ イベント生成ステップ
Ｓ５０５ イベントハンドラ実行ステップ
Ｓ６０１ プレイリスト再生開始ステップ
Ｓ６０２ プレイリスト再生終了判定ステップ
Ｓ６０３ ＵＯＰ受付判定ステップ
Ｓ６０４ ＵＯＰイベント生成ステップ
Ｓ６０５ メニューコール判定ステップ
Ｓ６０６ ユーザイベント有効期間判定ステップ
Ｓ６０７ イベント生成ステップ
Ｓ６０８ イベントハンドラ実行ステップ
Ｓ７０１ プレイリスト再生開始ステップ
Ｓ７０２ プレイリスト再生終了判定ステップ
Ｓ７０３ 字幕描画開始判定ステップ
Ｓ７０４ 字幕描画ステップ
Ｓ７０５ 字幕表示終了判定ステップ
Ｓ７０６ 字幕消去ステップ

Claims (7)

1. 静止画および動画像を符号化する画像符号化装置であって、
   静止画の１ピクチャ当たりの符号量の上限を示す第１の上限と、動画像の１ピクチャ当たりの符号量の上限を示す第２の上限とを決定する決定手段と、
   連続して再生する複数の静止画のみからなる所定単位毎に、前記第１の上限を満たすように前記複数の静止画を符号化する第１の符号化手段と、
   連続して再生する複数の動画像のみからなる所定単位毎に、前記第２の上限を満たすように前記複数の動画像を符号化する第２の符号化手段と、
   前記所定単位毎に前記符号量の上限を特定する管理情報を生成する生成手段と、
   前記管理情報と、前記所定単位毎に符号化された静止画と、動画像とを出力する出力手段と、
   を備え、
   前記符号化された静止画は、静止画の復号時に参照される初期化情報を格納する第１の単位と、前記静止画の画素データを格納する第２の単位とを含み、
   前記第１の単位は、前記静止画を繰り返し表示する際のフレームレートを示す情報と、
   前記フレームレートを示す情報が前記第１の単位に存在するかどうかを示す識別フラグとを含むことができ、
   前記第１の単位が前記静止画のデータ内に存在する場合には、前記識別フラグがセットされていること
   を特徴とする画像符号化装置。
2. 前記管理情報は、前記所定単位毎に符号化された全ての静止画のアドレスに関する情報を有することを特徴とする請求項１記載の画像符号化装置。
3. 画像復号化装置であって、
   符号化された動画像および符号化された静止画を含むストリームを取得する取得手段と、
   前記ストリームから符号化された静止画と符号化された動画像とに分離する分離手段と、
   分離後の符号化された動画像および符号化された静止画を復号する復号化手段とを備え、
   前記復号化手段は、符号化された静止画のデコードタイムスタンプからプレゼンテーションタイムスタンプまでのデコード期間にマージンを付与し、付与後のデコード期間に従って符号化された静止画のデコードまたは出力を開始する
   ことを特徴とする画像復号化装置。
4. 画像復号化手段は、
   符号化された静止画のデコードタイムスタンプの時刻にデコードを開始し、
   前記プレゼンテーションタイムスタンプの時刻までに静止画のデコードが完了しなかった場合に、前記プレゼンテーションタイムスタンプにマージンを付与し、付与後のプレゼンテーションタイムスタンプに復号化された静止画を出力する
   ことを特徴とする請求項３記載の画像復号化装置。
5. 画像復号化手段は、
   前記デコードタイムスタンプにマージンを付与し、付与後のデコードタイムスタンプの時刻に静止画のデコードを開始する
   ことを特徴とする請求項３記載の画像復号化装置。
6. 前記符号化された静止画は、静止画の復号時に参照される初期化情報を格納する第１の単位と、前記静止画の画素データを格納する第２の単位とを含み、
   前記第１の単位は、前記静止画を繰り返し表示する際のフレームレートを示す情報と、
   前記フレームレートを示す情報が前記第１の単位に存在するかどうかを示す識別フラグとを含むことができ、
   前記第１の単位が前記静止画のデータ内に存在する場合は、前記識別フラグがセットされ、
   前記復号化手段は、復号化が完了した静止画のプレゼンテーションタイムスタンプから、復号順が次の静止画のプレゼンテーションタイムスタンプまでの間、前記フレームレートに従って前記復号化が完了した静止画を出力する
   ことを特徴とする請求項３記載の画像復号化装置。
7. 画像復号化方法であって、
   符号化された動画像および符号化された静止画を含むストリームを取得し、
   前記ストリームから符号化された静止画と符号化された動画像と分離し、
   分離後の符号化された動画像および符号化された静止画を復号し、
   前記静止画の復号において、符号化された静止画のデコードタイムスタンプからプレゼンテーションタイムスタンプまでのデコード期間にマージンを付与し、付与後のデコード期間に従って符号化された静止画のデコードまたは出力を開始する
   ことを特徴とする画像復号化方法。

Images