情報記録媒体、及びデータ再生装置
【課題】基本データのみを復号するデコーダが、基本データと次世代に対応する拡張データとを含むアクセスユニットを処理することを可能にする情報記録媒体を提供する。
【解決手段】複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、１個の前記アクセスユニットは、基本データを含む第１のパケット（ＰＥＳ ｐａｃｋｅｔ（Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ））と、基本データと関連する拡張データを含む第２のパケット（ＰＥＳ ｐａｃｋｅｔ（Ｌｅｖｅｌ２−ＥＸＴ））とを有し、基本データは、拡張データを必要とすることなく完全な状態に復号することができるデータであり、拡張データは、基本データから生成されるデータの質を向上させるためのデータであり、ストリームは、第１のパケット及び第２のパケットの属性を示す情報（ｄｅｓｃｒｉｐｔｏｒ）を有する。
【解決手段】複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、１個の前記アクセスユニットは、基本データを含む第１のパケット（ＰＥＳ ｐａｃｋｅｔ（Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ））と、基本データと関連する拡張データを含む第２のパケット（ＰＥＳ ｐａｃｋｅｔ（Ｌｅｖｅｌ２−ＥＸＴ））とを有し、基本データは、拡張データを必要とすることなく完全な状態に復号することができるデータであり、拡張データは、基本データから生成されるデータの質を向上させるためのデータであり、ストリームは、第１のパケット及び第２のパケットの属性を示す情報（ｄｅｓｃｒｉｐｔｏｒ）を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像や音声のデータが記録される情報記録媒体、及びデータを再生するデータ再生装置等に関する。
【背景技術】
【０００２】
従来のＤＶＤ−Ｖｉｄｅｏディスク（以下、「ＤＶＤ」という）について説明する。
【０００３】
図１は、ＤＶＤの構造を示す図である。図１の下段に示すように、ＤＶＤには、リード・イン部からリード・アウト部までの間に論理アドレス空間が設けられている。論理アドレス空間には、先頭にファイルシステムのボリューム情報が記録され、続いて映像や音声などのアプリケーションデータが記録される。
【０００４】
ＤＶＤのファイルシステムは、ＩＳＯ９６６０やUniversal Disc Format（ＵＤＦ）の
ファイルシステムである。ファイルシステムは、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現するための仕組みである。パーソナルコンピュータ（ＰＣ）では、ＦＡＴまたはＮＴＦＳと呼ばれるファイルシステムが用いられている。そのファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータは、コンピュータにより処理される。これにより、ユーザビリティが高くなっている。
【０００５】
ＤＶＤでは、ＵＤＦおよびＩＳＯ９６６０の両方のファイルシステムが使用されている。ＵＤＦおよびＩＳＯ９６６０の両方を合わせて「ＵＤＦブリッジ」と呼ぶことがある。ＤＶＤに記録されているデータは、ＵＤＦおよびＩＳＯ９６６０のどちらのファイルシステムドライバによっても読み出すことができる。勿論、書き換え可能型のＤＶＤであるＤＶＤ−ＲＡＭ／Ｒ／ＲＷでは、これらのファイルシステムを介して、物理的にデータの読み、書き、および削除が可能である。
【０００６】
ＤＶＤに記録されたデータは、ファイルシステムを介して、図１左上に示すようなディレクトリまたはファイルとして存在する。ルートディレクトリ（図１における「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルに分割されて記録されている。主なファイルとして以下のものがある。
【０００７】
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
．．．．．
【０００８】
２つの拡張子が規定されている。「ＩＦＯ」は、それが付与されているファイルが再生制御情報が記録されたファイルであることを示す拡張子である。「ＶＯＢ」は、それが付与されているファイルがＡＶデータであるＭＰＥＧストリームが記録されたファイルであることを示す拡張子である。再生制御情報は、ＤＶＤについて採用されたインタラクティビティ（ユーザの操作に応じて再生状態を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などを含む情報である。ＤＶＤでは一般的に、再生制御情報はナビゲーション情報と呼ばれる。
【０００９】
再生制御情報ファイルとして、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセットの再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」とが存在する。ファイル名のボディにある「０１」はビデオタイトルセットの番号を示している。例えば、ビデオタイトルセットの番号が＃２であれば、そのビデオタイトルセットのファイル名は「ＶＴＳ＿０２＿０．ＩＦＯ」である。なおＤＶＤでは、複数のタイトル、言い換えれば内容が異なる複数の映画や、内容が同一でバージョンが異なる複数の映画を１枚のディスクに記録することが可能である。
【００１０】
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間、即ち前述した再生制御情報が展開された論理構造空間を示している。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、Video Manager Information（ＶＭＧＩ）として、ＤＶＤナビゲーショ
ン空間に展開される。「ＶＴＳ＿０１＿０．ＩＦＯ」等のビデオタイトルセット毎に存在する再生制御情報は、Video Title Set Information（ＶＴＳＩ）としてＤＶＤナビゲー
ション空間に展開される。
【００１１】
ＶＴＳＩには、Program Chain（ＰＧＣ）と呼ばれる再生シーケンスの情報であるProgram Chain Information（ＰＧＣＩ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合と、コマンドと呼ばれる一種のプログラミング情報とによって構成されている。Ｃｅｌｌは、Video Object（ＶＯＢ，ＭＰＥＧストリーム）の一部区間の集合、または全部区間である。Ｃｅｌｌの再生は、ＶＯＢの、Ｃｅｌｌによって指定された区間を再生することを意味している。
【００１２】
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、ブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。Ｊａｖａ（登録商標）スクリプトは、論理演算の他に、ウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドを開く）を行う。それに対して、ＤＶＤのコマンドは、論理演算の他には、ＡＶタイトルの再生制御（例えば、再生するチャプタの指定など）のみを行う。このように、ＤＶＤのコマンドは、Ｊａｖａ（登録商標）スクリプトと異なっている。
【００１３】
Ｃｅｌｌは、ディスク上に記録されているＶＯＢの開始アドレスおよび終了アドレス（ディスク上での論理記録アドレス）の情報を有している。プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始アドレスおよび終了アドレスの情報を使って、データを読み出して再生する。
【００１４】
図２は、ＡＶストリーム中に埋め込まれているナビゲーション情報を説明するための図である。ＤＶＤにおいて特徴的なインタラクティビティは、前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されるのではない。インタラクティビティを実現するための幾つかの重要な情報は、ナビゲーション パック（「ナビパック」または「ＮＶ＿ＰＣＫ」という）と呼ばれる専用キャリアが用いられて、ＶＯＢ内に映像データおよび音声データと一緒に多重化されている。
【００１５】
ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には幾つかのボタンが現れる。夫々のボタンには、そのボタンが選択され押下されたときの処理の内容が定義されている。メニュー上では一つのボタンが選択される。ハイライトは、選択されているボタン上にオーバーレイされる半透明色の画像であって、それがオーバーレイされているボタンが選択されていることをユーザに示す。ユーザは、リモコンの上下左右キーを使って、選択されているボタンをそのボタンの上下左右の何れかのボタンに移動させることができる。ユーザは、リモコンの上下左右キーを使って、実行させたい処理に対応するボタンまでハイライトを移動させて、決定キーを押す。これによって、選択されたボタンに対応するコマンドのプログラムが実行される。例えば、タイトルやチャプタの再生がコマンドによって実行される（例えば、特許文献１参照）。
【００１６】
図２の左上部は、ＮＶ＿ＰＣＫ内に格納される制御情報の概要を示している。
【００１７】
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報や個々のボタン情報などが含まれている。ハイライトカラー情報内には、カラーパレット情報が記述される。カラーパレット情報はオーバーレイするハイライトの半透明色を指定する。ボタン情報内には、個々のボタンの位置情報である矩形領域情報と、あるボタンから他のボタンへの移動情報（ユーザによるリモコンの上下左右キーの選択に対応する移動先ボタンの指定）と、ボタンコマンド情報（そのボタンが選択されたときに実行されるコマンド）とが記述されている。
【００１８】
メニュー上のハイライトは、図２の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報内の矩形領域情報によって特定されるボタンの上にカラーパレット情報によって特定される色をつけた画像である。オーバーレイ画像は、図２の右部に示す背景画像と合成されて画面上に表示される。
【００１９】
上述したようにして、ＤＶＤではメニューが表示される。ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいる理由は、ストリームと同期して動的にメニュー情報を更新することを可能とするためである。例えば、映画が再生されている途中の５分〜１０分の間だけメニューが表示されることを可能とするためである。二つ目の理由は、ストリームとメニュー情報とを同期させることが困難なアプリケーションデータであっても、ストリームとメニュー情報とを同期させて表示することを可能とするためである。もう一つの大きな理由は、ユーザの操作性を向上させるためである。例えば、ＮＶ＿ＰＣＫに特殊再生を支援するための情報を格納することにより、ＤＶＤに記録されているＡＶデータを早送りや巻き戻しなどの非通常再生する際にも、円滑にそのＡＶデータをデコードし再生することが可能となる。
【００２０】
図３は、ＤＶＤのストリームであるＶＯＢのイメージを示す図である。図３（Ａ）に示す映像、音声、および字幕などのデータは、図３（Ｂ）に示すように、ＭＰＥＧシステム規格（ＩＳＯ／ＩＥＣ１３８１８−１）に基づいてパケット化およびパック化され、図３（Ｃ）に示すように、夫々は多重化されて、１本のＭＰＥＧプログラムストリームが生成される。インタラクティビティを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも、パケットおよびパックと一緒に多重化される。
【００２１】
ＭＰＥＧシステムにおけるデータの多重化の特徴は、多重化される個々のデータはデコード順に基づくビット列になっているが、多重化されるデータ相互については、即ち、映像データ、音声データ、および字幕データ相互については、必ずしも再生順、言い換えればデコード順に配列されているわけではない。これは、ＭＰＥＧシステムストリームのデコーダモデル（一般に、「System Target Decoder」または「ＳＴＤ」と呼ばれる（図３
（Ｄ）参照））が、多重化されているデータを解いた後の個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまで一時的にデータを蓄積していることに由来している。ＤＶＤ−Ｖｉｄｅｏで規定されるデコーダバッファのサイズは、エレメンタリーストリーム毎に異なる。映像に対するバッファのサイズは２３２ＫＢであり、音声に対するバッファのサイズは４ＫＢであり、字幕に対するバッファのサイズは５２ＫＢである。
【００２２】
即ち、映像データと並んで多重化されている字幕データは、必ずしも映像データと同一タイミングでデコードまたは再生されるわけではない。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開平９−２８２８４８号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
従来からＤＶＤで採用されている音声コーデック規格として、「ドルビーディジタル（ＡＣ−３）」と、「ＭＰＥＧオーディオ」と、「ＬＰＣＭ」と、「ｄｔｓ」との４つの規格がある。「ｄｔｓ」はプレーヤオプション機能であり、ＤＶＤプレーヤには、ｄｔｓデコーダを内蔵するものと、内蔵しないものとがある。また、ＤＶＤプレーヤには、ＡＶアンプへのディジタルデータの出力機能として、ｄｔｓ対応機能を有しているものと、有していないものとがある。
【００２５】
ｄｔｓディジタルデータ出力機能を有しているＤＶＤプレーヤは、Sony/Philips Digital Interconnect Format（ＳＰＤＩＦ、民生向けはＩＥＣ６０９５８−３規格で規定）と呼ばれるディジタルＩ／Ｆ規格に準拠したデータを、その規格に準拠したＡＶアンプに出力する。
【００２６】
しかしながら、ＳＰＤＩＦは、規格上１．５Ｍｂｐｓの帯域までしか対応することができず、「ｄｔｓ」の拡張コーデック規格である、２０Ｍｂｐｓ近い帯域を必要とする「ｄｔｓ＋＋（ロスレス圧縮）」に対応していない。したがって、次世代ＨＤ ＤＶＤ規格（ＢＤ規格）が「ｄｔｓ＋＋」に対応しても、ＳＰＤＩＦ規格に準拠したＡＶアンプに、ｄｔｓ＋＋ストリームを出力することはできない。
【００２７】
本発明は、上述した課題を考慮し、基本データのみを復号するデコーダが、基本データと次世代に対応する拡張データとを含むアクセスユニットを処理することができるように、基本データと拡張データとを含むアクセスユニットが記録される情報記録媒体を提供することを目的とする。また、本発明は、本発明の情報記録媒体のアクセスユニットを処理するデータ再生装置を提供することを目的とする。
【課題を解決するための手段】
【００２８】
上記課題を解決し上記目的を達成するために、本発明の情報記録媒体は、複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、１個の前記アクセスユニットは、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、前記基本データは、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データは、前記基本データから生成されるデータの質を向上させるためのデータであり、前記ストリームは、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する。
【００２９】
例えば、前記情報は、前記ストリームのｄｅｓｃｒｉｐｔｏｒに記述されている。
【００３０】
例えば、前記アクセスユニットは、音に関するデータであって、前記属性は、チャンネル、周波数、ビットレート、及び、２チャンネルのダウンミックスデータの存在の有無、の少なくとも一つを特定する。
【００３１】
例えば、各前記アクセスユニットは一定時間のデータである。
【００３２】
本発明のデータ再生装置は、本発明の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得する取得手段と、前記情報を用いて、前記アクセスユニットを再生する再生手段とを備える。
【００３３】
本発明は、本発明のデータ再生装置の特徴的な構成手段をステップとするデータ再生方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現することもできる。そのプログラムは、ＣＤ−ＲＯＭ等の記録媒体や通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００３４】
本発明は、基本データのみを復号するデコーダが、基本データと次世代に対応する拡張データとを含むアクセスユニットを処理することができるように、基本データと拡張データとを含むアクセスユニットが記録される情報記録媒体を提供することができる。また、本発明は、本発明の情報記録媒体のアクセスユニットを処理するデータ再生装置を提供することができる。
【００３５】
すなわち、本発明により、既存のディジタルＩ／Ｆが持つ帯域を越える新しい音声コーデックを使った音声データが記録媒体に記録されている場合であっても、既存のディジタルＩ／Ｆに対して従来通りの音声データの抽出および出力が可能になる効果が得られる。
【図面の簡単な説明】
【００３６】
【図１】図１は、ＤＶＤの構造を示す図である。
【図２】図２は、ナビゲーション情報を説明するための図である。
【図３】図３（Ａ）は、映像、音声、および字幕などのデータを示す図である。図３（Ｂ）は、各データをパケット化およびパック化することを示す図である。図３（Ｃ）は、パケット化およびパック化されたデータを示す図である。図３（Ｄ）は、ＭＰＥＧシステムストリームのデコーダモデルを示す図である。
【図４】図４は、次世代ＤＶＤの構成を示す図である。
【図５】図５は、ＢＤディスクに記録されている論理データのディレクトリおよびファイルの構成を示す図である。
【図６】図６は、プレーヤの機能を示すブロック図である。
【図７】図７は、プレーヤの構成を詳細化したブロック図である。
【図８】図８は、ＢＤのアプリケーション空間を示す図である。
【図９】図９は、ＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【図１０】図１０は、パックの構成を示す図である。
【図１１】図１１は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を説明するための図である。
【図１２】図１２は、ＶＯＢデータ連続供給モデルを説明するための図である。
【図１３】図１３は、ＶＯＢ管理情報ファイルの内部構造を示す図である。
【図１４】図１４は、ＶＯＢＵ情報の詳細を説明するための図である。
【図１５】図１５は、タイムマップの詳細に説明するための図である。
【図１６】図１６は、プレイリスト情報の内部構造を示す図である。
【図１７】図１７は、イベントハンドラテーブルを示す図である。
【図１８】図１８は、ＢＤディスク全体に関する情報の内部構造を示す図である。
【図１９】図１９は、グローバルイベントハンドラのプログラムのテーブルを示す図である。
【図２０】図２０は、タイムイベントの例を示す図である。
【図２１】図２１は、ユーザイベントの例を示す図である。
【図２２】図２２は、グローバルイベントの例を示す図である。
【図２３】図２３は、プログラムプロセッサの機能を説明するための図である。
【図２４】図２４は、システムパラメータの一覧を示す図である。
【図２５】図２５は、２つの選択ボタンを持つメニューのプログラムの例を示す図である。
【図２６】図２６は、ユーザイベントのイベントハンドラの例を示す図である。
【図２７】図２７は、ＡＶの再生までの基本処理フローを示す図である。
【図２８】図２８は、ＰＬの再生開始からＶＯＢの再生開始までの処理フローを示す図である。
【図２９】図２９は、ＡＶの再生開始後からのイベント処理フローを示す図である。
【図３０】図３０は、字幕処理のフローを示す図である。
【図３１】図３１は、階層構造を持たないアクセスユニットの構造を示す図である。
【図３２】図３２は、２つの階層構造を持つアクセスユニットの構造を示す図である。
【図３３】図３３は、３つの階層構造を持つアクセスユニットの構造を示す図である。
【図３４】図３４は、階層構造を持つデータを、様々な階層に対応したデコーダに出力するストリーム読込／供給部の、データの出力先毎に異なる動作を説明するための図である。
【図３５】図３５は、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及した場合に、Ｌｅｖｅｌ２−ＥＸＴを導入するための理想的なアクセスユニットの構造を示す図である。
【図３６】図３６は、Ｌｅｖｅｌ２を含むデータストリームのデータ構造を示す図である。
【図３７】図３７は、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されているアクセスユニットの処理を説明するための図である。
【図３８】図３８は、ＭＰＥＧ２−ＴＳへの階層構造を持つアクセスユニットの格納方法を示す図である。
【図３９】図３９は、ｄｅｓｃｒｉｐｔｏｒに記述される事項の一例を示す図である。
【図４０】図４０（Ａ）は、５．１チャンネルのスピーカレイアウトを示す図であり、図４０（Ｂ）は、７．１チャンネルのスピーカレイアウトを示す図である。
【図４１】図４１は、チャンネル構造を示す図である。
【図４２】図４２は、光ディスクに記録する際のＭＰＥＧ２−ＴＳのファイルフォーマットを示す図である。
【図４３】図４３は、ＤＶＤ−Ｖｉｄｅｏで規定されるＤＴＳの詳細を説明するための図である。
【図４４】図４４は、デマルチプレクサ、および、ストリーム読込／供給部の処理を示すフローチャートである。
【図４５】図４５は、入力時刻管理装置２０００およびデコーダモデル３０００の構成図である。
【図４６】図４６は、Ｂａｓｅを復号するデコーダモデルを破綻させないようにするとともに、かつ、ＢａｓｅおよびＬｅｖｅｌ２を復号するデコーダモデルを破綻させないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する方法を説明するための図である。
【発明を実施するための形態】
【００３７】
以下に、本発明を実施するための最良の形態を図面を参照して説明する。
【００３８】
（関連する実施の形態）
（ディスク上の論理データ構造）
図４は、次世代ＤＶＤ（以下、「ＢＤ」という）の構成、特にディスク媒体であるＢＤディスク１０４並びに、ディスク１０４に記録されているデータ１０１，１０２，および１０３の構成を示す図である。ＢＤディスク１０４には、ＡＶデータ１０３と、ＡＶデータの管理情報およびＡＶ再生シーケンスなどを含むＢＤ管理情報１０２と、インタラクティビティを実現するためのＢＤ再生プログラム１０１とが記録される。本実施の形態では、説明の都合上、映画のＡＶコンテンツを再生するためのＡＶアプリケーションデータがＢＤディスク１０４に記録されていると仮定する。しかしながら、ＢＤディスク１０４は、他の用途として用いられてもよい。
【００３９】
図５は、ＢＤディスクに記録されている論理データのディレクトリおよびファイルの構成を示す図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様に、内周から外周に向けてらせん状に記録領域を持ち、内周のリード・イン部と外周のリード・アウト部との間に論理データを記録するための論理アドレス空間を有している。ＢＤディスクには、リード・イン部の内側に、Burst Cutting Area（ＢＣＡ）と呼ばれるドライブでしかデータを読み出すことができない特別な領域が存在する。この領域のデータは、アプリケーションデータを利用しても読み出すことができない。そのため、上記領域は、例えば著作権保護技術のためなどに利用されることがある。
【００４０】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に、映像データなどのアプリケーションデータが記録されている。ファイルシステムは、「背景技術」で説明した通り、ＵＤＦやＩＳＯ９６６０などのファイルシステムであり、通常のＰＣと同じように、記録されている論理データをディレクトリおよびファイルの構造を使って読み出すためのシステムである。
【００４１】
本実施の形態におけるＢＤディスク上のディレクトリおよびファイルの構造では、ルートディレクトリ（ＲＯＯＴ）の直下に、ＢＤＶＩＤＥＯディレクトリが置かれている。ＢＤＶＩＤＥＯディレクトリは、ＢＤに記録されるＡＶコンテンツや管理情報などのデータ（図４のデータ１０１，１０２，および１０３）が格納されているディレクトリである。
【００４２】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００４３】
ＢＤ．ＩＮＦＯファイル（ファイル名固定）
「ＢＤ．ＩＮＦＯ」ファイルは、「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報が記録されたファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００４４】
ＢＤ．ＰＲＯＧファイル（ファイル名固定）
「ＢＤ．ＰＲＯＧ」ファイルは、「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関する再生制御情報が記録されたファイルである。
【００４５】
ＸＸＸ．ＰＬファイル（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＸＸＸ．ＰＬ」ファイルは、「ＢＤ管理情報」の一つであり、シナリオ（再生シーケンス）であるプレイリスト情報が記録されたファイルである。プレイリスト毎に一つのファイルが存在する。
【００４６】
ＸＸＸ．ＰＲＯＧファイル（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＸＸＸ．ＰＲＯＧ」ファイルは、「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報が記録されたファイルである。「ＸＸＸ．ＰＲＯＧ」ファイルに対応するプレイリストは、ファイルボディ名（「ＸＸＸ」）が一致するプレイリストである。
【００４７】
ＹＹＹ．ＶＯＢファイル（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＹＹＹ．ＶＯＢ」ファイルは、「ＡＶデータ」の一つであり、ＶＯＢ（「背景技術」で説明したＶＯＢと同じ）が記録されたファイルである。ＶＯＢ毎に一つのファイルが存在する。
【００４８】
ＹＹＹ．ＶＯＢＩファイル（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＹＹＹ．ＶＯＢＩ」ファイルは、「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関するストリーム管理情報が記録されたファイルである。「ＹＹＹ．ＶＯＢＩ」ファイルに対応するＶＯＢは、ファイルボディ名（「ＹＹＹ」）が一致するＶＯＢである。
【００４９】
ＺＺＺ．ＰＮＧファイル（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＺＺＺ．ＰＮＧ」ファイルは、「ＡＶデータ」の一つであり、字幕およびメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）が記録されたファイルである。ＰＮＧイメージ毎に一つのファイルが存在する。
【００５０】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤについて、図６および図７を用いて説明する。
【００５１】
図６は、プレーヤの大まかな機能を示すブロック図である。
【００５２】
ＢＤディスク２０１上のデータは、光ピックアップ２０２を通して読み出される。読み出されたデータは、そのデータの種類に応じて専用のメモリに転送される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」ファイルまたは「ＸＸＸ．ＰＲＯＧ」ファイル）はプログラム記録メモリ２０３に転送される。ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」ファイル、「ＸＸＸ．ＰＬ」ファイル、または「ＹＹＹ．ＶＯＢＩ」ファイル）は管理情報記録メモリ２０４に転送される。ＡＶデータ（「ＹＹＹ．ＶＯＢ」ファイルまたは「ＺＺＺ．ＰＮＧ」ファイル）はＡＶ記録メモリ２０５に転送される。
【００５３】
プログラム記録メモリ２０３に記録されたＢＤ再生プログラムはプログラム処理部２０６によって処理される。管理情報記録メモリ２０４に記録されたＢＤ管理情報は管理情報処理部２０７によって処理される。ＡＶ記録メモリ２０５に記録されたＡＶデータはプレゼンテーション処理部２０８によって処理される。
【００５４】
プログラム処理部２０６は、管理情報処理部２０７より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取り、プログラムを実行する。プログラムは再生するプレイリストを動的に変えることが可能である。プログラム処理部２０６が管理情報処理部２０７に対してプレイリストの再生命令を送ることで、再生するプレイリストが動的に変わることが実現する。プログラム処理部２０６は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、そのイベント（リクエスト）に対応するプログラムがある場合、それを実行する。
【００５５】
管理情報処理部２０７は、プログラム処理部２０６からの指示を受け、対応するプレイリストおよびプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部２０８に、対象となるＡＶデータの再生を指示する。また、管理情報処理部２０７は、プレゼンテーション処理部２０８より基準時刻情報を受け取り、基準時刻情報に基づいてプレゼンテーション処理部２０８にＡＶデータの再生の停止を指示し、また、プログラム処理部２０６に対して指示するための、プログラムの実行タイミングを示すイベントを生成する。
【００５６】
プレゼンテーション処理部２０８は、映像、音声、および字幕／イメージ（静止画）の夫々に対応するデコーダを持ち、管理情報処理部２０７からの指示に従い、ＡＶデータのデコードおよび出力を行う。映像データ、および字幕／イメージは、デコードされた後に夫々の専用プレーン、ビデオプレーン２１０またはイメージプレーン２０９に描画される。ビデオプレーン２１０およびイメージプレーン２０９に描画された各映像は、合成処理部２１１によって合成され、ＴＶなどの表示デバイスへ出力される。
【００５７】
図６を用いて説明したように、ＢＤプレーヤは図４で示したＢＤディスクに記録されているデータの構成に対応する構成部を有している。
【００５８】
図７は前述したプレーヤの構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ２０５は、イメージメモリ３０８およびトラックバッファ３０９として表現されている。プログラム処理部２０６は、プログラムプロセッサ３０２およびＵＯＰマネージャ３０３として表現されている。管理情報処理部２０７は、シナリオプロセッサ３０５およびプレゼンテーションコントローラ３０６として表現されている。プレゼンテーション処理部２０８は、クロック３０７、デマルチプレクサ３１０、イメージプロセッサ３１１、ビデオプロセッサ３１２、およびサウンドプロセッサ３１３として表現されている。
【００５９】
ＢＤディスク２０１から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ３０９に記録され、イメージデータ（ＰＮＧ）はイメージメモリ３０８に記録される。デマルチプレクサ３１０は、クロック３０７の時刻に基づき、トラックバッファ３０９に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ３１２に送り、音声データをサウンドプロセッサ３１３に送る。ビデオプロセッサ３１２およびサウンドプロセッサ３１３はそれぞれ、ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダとで構成されている。即ち、デマルチプレクサ３１０から送りこまれる映像および音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック３０７の時刻に従い対応するデコーダでデコードされる。
【００６０】
イメージメモリ３０８に記録されたＰＮＧは、次の２つの処理方法によって処理される。
【００６１】
イメージデータが字幕用のデータである場合、プレゼンテーションコントローラ３０６によってデコードタイミングが指示される。シナリオプロセッサ３０５は、クロック３０７からの時刻情報を受け、適切に字幕を表示することができるように、字幕の表示開始時刻になると、プレゼンテーションコントローラ３０６に対して字幕の表示を指示する。同様に、シナリオプロセッサ３０５は、クロック３０７からの時刻情報に基づいて、字幕の表示終了時刻になると、プレゼンテーションコントローラ３０６に対して字幕の表示の停止を指示する。プレゼンテーションコントローラ３０６からデコード／表示の指示を受けたイメージプロセッサ３１１は、対応するＰＮＧデータをイメージメモリ３０８から抜き出してデコードし、イメージプレーン３１４に描画する。
【００６２】
次に、イメージデータがメニュー用のデータである場合を説明する。その場合、プログラムプロセッサ３０２によってデコードタイミングが指示される。プログラムプロセッサ３０２がイメージのデコードを指示するタイミングは、プログラムプロセッサ３０２が処理しているＢＤプログラムに依存し、一概には決まらない。
【００６３】
イメージデータおよび映像データは、図６を用いて説明したように、夫々デコードされた後に、イメージプレーン３１４またはビデオプレーン３１５に描画され、合成処理部３１６によって合成された後、出力される。
【００６４】
ＢＤディスク２０１から読み出された管理情報（シナリオ情報およびＡＶ管理情報）は、管理情報記録メモリ３０４に格納される。その後、シナリオ情報（「ＢＤ．ＩＮＦＯ」ファイルおよび「ＸＸＸ．ＰＬ」ファイル）はシナリオプロセッサ３０５によって読み出される。ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」ファイル）はプレゼンテーションコントローラ３０６によって読み出される。
【００６５】
シナリオプロセッサ３０５は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置とをプレゼンテーションコントローラ３０６に知らせる。プレゼンテーションコントローラ３０６は、対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」ファイル）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ３１７に指示を出す。
【００６６】
ドライブコントローラ３１７は、プレゼンテーションコントローラ３０６からの指示に従い、光ピックアップを移動させ、対象となるＡＶデータを読み出す。読み出されたＡＶデータは、前述したようにイメージメモリ３０８またはトラックバッファ３０９に格納される。
【００６７】
シナリオプロセッサ３０５は、クロック３０７の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ３０２に出力する。
【００６８】
プログラム記録メモリ３０１に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」ファイルまたは「ＸＸＸ．ＰＲＯＧ」ファイル）は、プログラムプロセッサ３０２によって処理される。プログラムプロセッサ３０２は、シナリオプロセッサ３０５からイベントが送られてきた場合か、ＵＯＰマネージャ３０３からイベントが送られてきた場合、ＢＤプログラムを処理する。ＵＯＰマネージャ３０３は、ユーザからリモコンキーによってリクエストが送られてきた場合、プログラムプロセッサ３０２に対するイベントを生成する。
【００６９】
（アプリケーション空間）
図８は、ＢＤのアプリケーション空間を示す図である。
【００７０】
ＢＤのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位である。プレイリストは、セル（Ｃｅｌｌ）の連結であって、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。プログラムによる動的なシナリオの変化が無い限り、プレイリストは個々のセルを順に再生させる。全てのセルの再生を終了した時点で、プレイリストの再生は終了する。プログラムには、セルの再生順序を変化させる内容を記述することが可能である。また、プログラムは、ユーザの選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例として、メニューが挙げられる。ＢＤでは、メニューはユーザの選択によって再生するシナリオであると定義することができ、プログラムによってプレイリストを動的に変化させることができる。
【００７１】
ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラである。
【００７２】
時間イベントは、プレイリストに埋め込まれた時刻情報に基づいて生成されるイベントである。図７を用いて説明したシナリオプロセッサ３０５からプログラムプロセッサ３０２に送られるイベントが、時間イベントの一例である。時間イベントが発行されると、プログラムプロセッサ３０２は識別子（ＩＤ）によって対応付けられるイベントハンドラを実行する。前述した通り、実行されるプログラムは他のプレイリストの再生を指示することが可能である。例えば、プログラムは、現在再生されているプレイリストの再生を中止し、指定されたプレイリストを再生させる。
【００７３】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。
【００７４】
一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）。リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された場合、有効なイベントハンドラが検索され、有効なイベントハンドラがある場合、そのイベントハンドラが実行される。有効なイベントハンドラがない場合、メニュー選択のイベントは無視される。
【００７５】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声または字幕を呼び出し、音声または字幕を変更後に中断した地点からタイトルを再生する機能等）を実装することができる。
【００７６】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）は、ＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を示す。セルは、ＶＯＢ内の再生区間を、開始時刻および終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、データの再生時刻に対応した記録アドレスのテーブル情報であるタイムマップ（Time MapまたはＴＭ）を有している。タイムマップを用いることによって、前述したＶＯＢの再生時刻および終了時刻から、ＶＯＢ内（即ち対象となる「ＹＹＹ．ＶＯＢ」ファイル内）での読み出しの開始アドレスおよび終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００７７】
（ＶＯＢの詳細）
図９は、本実施の形態におけるＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【００７８】
図９に示すように、ＶＯＢは複数のVideo Object Unit（ＶＯＢＵ）によって構成され
ている。ＶＯＢＵは、ＭＰＥＧビデオストリームにおけるGroup Of Pictures（ＧＯＰ）
を基準として、音声データも含んだ多重化ストリームにおける一再生単位である。ＶＯＢＵのビデオ再生時間は０．４秒から１．０秒であって、通常は０．５秒程度である。つまり、多くのケースで１ＧＯＰには１５フレーム程度のフレームが格納されている（ＮＴＳＣの場合）。
【００７９】
ＶＯＢＵは、ビデオパック（Ｖ＿ＰＣＫ）とオーディオパック（Ａ＿ＰＣＫ）とを有している。各パックのサイズは、１セクタと同じであり、本実施の形態では、２ＫＢである。
【００８０】
図１０は、パックの構成を示す図である。
【００８１】
図１０に示すように、ビデオデータおよびオーディオデータといったエレメンタリデータは、PES Packet Payload（ペイロード）と呼ばれるPES Packet（パケット）のデータ格納領域に先頭から順次格納される。ペイロードは、PES Packet Header（パケットヘッダ
）が付けられて１つのPES Packet（パケット）を構成する。パケットヘッダには、ペイロードに格納されているデータがどのストリームのデータであるのかを識別するためのstream id（ＩＤ）と、そのペイロードのデコードおよび表示夫々の時刻情報であるタイムス
タンプ、即ちDecoding Time Stamp（ＤＴＳ）およびPresentation Time Stamp（ＰＴＳ）とが記録される。ＰＴＳおよびＤＴＳは、必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによってルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）の規格書に記述されているので、その説明を省略する。
【００８２】
パケットは、更にPack Header（ヘッダ）が付けられて、パックを構成する。そのヘッ
ダには、そのパックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるのかを示すタイムスタンプ、即ちSystem Clock Reference（ＳＣＲ）が記録されている。
【００８３】
（ＶＯＢのインターリーブ記録）
次に、図１１および図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００８４】
図１１上段は、前述したプレーヤの構成図の一部である。図１１に示すように、ＢＤディスク上のＶＯＢ即ちＭＰＥＧストリームは、光ピックアップを通してトラックバッファへ入力される。ＢＤディスク上のＰＮＧ即ちイメージデータは、光ピックアップを通してイメージメモリへ入力される。
【００８５】
トラックバッファはＦＩＦＯ形式のバッファであり、トラックバッファに入力されたＶＯＢのデータは入力された順にデマルチプレクサへ送られる。この時、個々のパックは、前述したＳＣＲに従ってトラックバッファから引き抜かれ、デマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへ送られる。他方、イメージメモリに入力されたイメージデータについては、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使われたイメージデータは、それが字幕用のイメージデータである場合、使われると同時にイメージメモリから削除される。それに対して、描画に使われたイメージデータがメニュー用のイメージデータである場合、そのメニューが描画されている間はイメージメモリ内にそのまま残される。これは、メニューの描画はユーザの操作に依存しており、ユーザの操作に追従してメニューの一部分を再表示または異なるイメージに置き換える際に、再表示される部分のイメージデータをデコードし易くするためである。
【００８６】
図１１下段は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭでは、一連の連続再生単位となるＡＶデータは連続して記録されている。データが連続して記録されている限り、ドライブは順次データを読み出し、デコーダに送り届ける。しかしながら、連続するデータが分断されてディスク上に離散して配置されている場合、ドライブは個々の連続区間をシークするので、シーク期間においてはデータの読み出しが止まることになり、データの供給が止まる可能性がある。それを防止するために、ＲＯＭでは、一連の連続再生単位となるＡＶデータは連続して記録されている。ＢＤでも、ＶＯＢファイルは連続領域に記録されることが望ましい。字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータは、ＶＯＢファイルと同様に何らかの方法によってＢＤディスクから読み出すことが必要になる。
【００８７】
字幕データの読み出し方法の一つとして、ＶＯＢの再生開始前に一まとめに字幕用のイメージデータ（ＰＮＧファイル）を読み出す方法がある。しかしながら、この方法では、大容量のメモリが必要となり、非現実的である。
【００８８】
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方法を採用している。図１１下段はそのインターリーブ記録を説明するための図である。
【００８９】
ＶＯＢファイルとイメージデータとを適切にインターリーブ配置することで、前述したような大容量の一時記録メモリを用いることなく、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。なお、イメージデータを読み出している際には、ＶＯＢデータの読み出しは当然のことながら停止する。
【００９０】
図１２は、トラックバッファを使ったＶＯＢデータ連続供給モデルを説明するための図である。
【００９１】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート（Ｖａ）と、トラックバッファからのデータ出力レート（Ｖｂ）との間に差（Ｖａ＞Ｖｂ）を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加していく。
【００９２】
図１２の上段に示すように、ＶＯＢの一連続記録領域が論理アドレスの“ａ１”から“ａ２”まで続くとする。論理アドレスの“ａ２”から“ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータは記録されていない区間であるとする。
【００９３】
図１２の下段は、トラックバッファ内のデータ量の推移を示す。横軸は時間を示し、縦軸はトラックバッファ内に蓄積されているデータの量を示す。時刻“ｔ１”は、ＶＯＢの一連続記録領域の開始点である論理アドレス“ａ１”のデータの読み出しを開始した時刻を示している。時刻“ｔ１”以降、トラックバッファにはレート（Ｖａ−Ｖｂ）でデータが蓄積される。そのレートは、トラックバッファへ入力するデータのレートと、トラックバッファから出力するデータのレートとの差である。時刻“ｔ２”は一連続記録領域の終了点である論理アドレス“ａ２”のデータを読み出す時刻である。即ち時刻“ｔ１”から“ｔ２”の間、レート（Ｖａ−Ｖｂ）でトラックバッファ内はデータ量が増加する。時刻“ｔ２”でのデータ蓄積量Ｂ（ｔ２）は下記の式１によって求めることができる。
【００９４】
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
【００９５】
この後、論理アドレスの“ａ２”から“ａ３”まではイメージデータが続くため、トラックバッファへのデータの入力は０であり、出力レート“−Ｖｂ”でトラックバッファ内のデータ量は減少する。これは論理アドレス“ａ３”まで、即ち時刻“ｔ３”まで継続する。
【００９６】
ここで大事なことは、時刻“ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。時刻“ｔ３”でトラックバッファにデータが残っている場合、ＶＯＢの再生はストップすることなく連続する。
【００９７】
時刻“ｔ３”より前にトラックバッファに蓄積されているデータ量が０になることを防止するための条件は、下記の式２によって示される。
【００９８】
Ｂ（ｔ２） ≧ Ｖｂ×（ｔ３−ｔ２） （式２）
【００９９】
即ち、式２を満たすように、イメージデータ（非ＶＯＢデータ）の配置を決めればよい。
【０１００】
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤのナビゲーションデータ（ＢＤ管理情報）の構造について説明する。
【０１０１】
図１３は、ＶＯＢ管理情報ファイル（“ＹＹＹ．ＶＯＢＩ”）の内部構造を示す図である。
【０１０２】
ＶＯＢ管理情報は、ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）と、タイムマップ（ＴＭＡＰ）とを有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）と、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）とを含む。特にオーディオストリームに関しては、ＶＯＢが複数のオーディオストリームを同時に持つことができることから、オーディオストリームの数（Ｎｕｍｂｅｒ）によって、データフィールドが示される。
【０１０３】
下記は、ビデオ属性（Ｖｉｄｅｏ）が持つ複数のフィールドと、夫々のフィールドが持ち得る値を示す。
【０１０４】
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
ＭＰＥＧ４−ＡＶＣ（Advanced Video Coding）
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０×１０８０
１２８０×７２０
７２０×４８０
７２０×５６５
アスペクト比（Ａｓｐｅｃｔ）：
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）：
６０
５９．９４
５０
３０
２９．９７
２５
２４
２３．９７６
【０１０５】
下記は、オーディオ属性（Ａｕｄｉｏ）が持つ複数のフィールドと、夫々のフィールドが持ち得る値を示す。
【０１０６】
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
ＤＴＳＨＤ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
【０１０７】
タイムマップ（ＴＭＡＰ）は、ＶＯＢＵ毎の情報を持つテーブルであって、ＶＯＢが有するＶＯＢＵの数（Ｎｕｍｂｅｒ）と、各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）とを持つ。個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）と、ＶＯＢＵのデータサイズ（Ｓｉｚｅ）とを有している。
【０１０８】
図１４はＶＯＢＵ情報の詳細を説明するための図である。
【０１０９】
広く知られているように、ＭＰＥＧビデオストリームは可変ビットレート圧縮されることがあり、各フレームの再生時間とデータサイズとには、単純な相関はない。これに対して、音声の圧縮規格であるＡＣ３は、音声データを固定ビットレートで圧縮することを定めているため、音声データについては、時間とアドレスとの関係は１次式によって表現される。ＭＰＥＧビデオデータでは、個々のフレームは固定の表示時間を持つが、例えばＮＴＳＣに対応するＭＰＥＧビデオデータでは１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性やピクチャタイプ、即ちＩ／Ｐ／Ｂピクチャのタイプによって大きく異なる。従って、ＭＰＥＧビデオデータについては、時間とアドレスとの関係を一次式で表現することは不可能である。
【０１１０】
当然のこととして、ＭＰＥＧビデオデータが多重化されているＭＰＥＧシステムストリーム、即ちＶＯＢについても、時間とデータサイズとの関係を一次式で表現することは不可能である。ＶＯＢでは、タイムマップ（ＴＭＡＰ）が時間とアドレスとを結びつける。図１４に示すように、ＶＯＢＵ毎に、ＶＯＢＵ内のフレームの数と、ＶＯＢＵ内のパックの数（つまりデータサイズ）とをエントリとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
【０１１１】
図１５を用いて、タイムマップ（ＴＭＡＰ）を詳細に説明する。
【０１１２】
図１５に示すように時刻情報が与えられた場合、先ずはその時刻がどのＶＯＢＵに属するのかを検索する。即ち、タイムマップのＶＯＢＵ毎のフレームの数を加算し、フレームの数の和が、与えられた時刻をフレーム数に換算した場合のそのフレーム数を超えるＶＯＢＵ、またはそのフレーム数に一致するＶＯＢＵを検索する。次に、タイムマップのＶＯＢＵ毎のデータサイズをそのＶＯＢＵの直前のＶＯＢＵまで加算する。加算によって得られた値が、与えられた時刻を含むフレームを再生するために読み出すべきパックのアドレスを求めるために用いられる。
【０１１３】
次に、図１６を用いて、プレイリスト情報（“ＸＸＸ．ＰＬ”）の内部構造を説明する。
【０１１４】
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）と、イベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１１５】
セルリスト（ＣｅｌｌＬｉｓｔ）はプレイリスト内の再生セルシーケンスであり、セルリストの記述順でセルが再生される。セルリスト（ＣｅｌｌＬｉｓｔ）は、セルの数（Ｎｕｍｂｅｒ）と、各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）とから構成されている。
【０１１６】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）と、ＶＯＢ内での開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）とを持っている。開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）は、夫々ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得ることができる。
【０１１７】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、ＶＯＢと同期再生される字幕の情報を持つテーブルである。ＶＯＢは音声と同様に複数の言語の字幕を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、言語の数（Ｎｕｍｂｅｒ）と、それに続く言語毎のテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）とから構成されている。
【０１１８】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇ）と、個々に表示される字幕の情報の数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の情報（字幕情報，Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）とから構成されている。字幕情報（Ｓｐｅｅｃｈ＃）は、対応するイメージデータのファイル名（Ｎａｍｅ）と、字幕の表示開始時刻（Ｉｎ）および字幕の表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）とから構成されている。
【０１１９】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベントの数（Ｎｕｍｂｅｒ）と、それに続く個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成されている。個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）と、イベントの識別子（ＩＤ）と、イベントの発生時刻（Ｔｉｍｅ）と、イベントの有効期間（Ｄｕｒａｔｉｏｎ）とから構成されている。
【０１２０】
図１７は、個々のプレイリストのイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（“ＸＸＸ．ＰＲＯＧ”）を示す図である。
【０１２１】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラムの数（Ｎｕｍｂｅｒ）と、個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）とを有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）は、イベントハンドラの開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と、前述したイベントの識別子と対になるイベントハンドラの識別子（ＩＤ）とを持つ。その後に、プログラムが、Ｆｕｎｃｔｉｏｎに続く括弧“｛”と“｝”との間に記述される。前述の“ＸＸＸ．ＰＬ”のイベントリスト（ＥｖｅｎｔＬｉｓｔ）に格納されたイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は、“ＸＸＸ．ＰＲＯＧ”のイベントハンドラの識別子（ＩＤ）を用いて特定される。
【０１２２】
次に、図１８を用いてＢＤディスク全体に関する情報（“ＢＤ．ＩＮＦＯ”）の内部構造を説明する。
【０１２３】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）と、グローバルイベント用のイベントテーブル（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１２４】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトルの数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）とから構成されている。個々のタイトル情報（Ｔｉｔｌｅ＃）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｂｌｅ）と、タイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）とを含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）は、タイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名とを有している。
【０１２５】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、タイトルに含まれるチャプタの数（Ｎｕｍｂｅｒ）と、個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）とから構成されている。個々のチャプタ情報（Ｃｈａｐｔｅｒ＃）は、そのチャプタを含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持つ。セルのテーブル（ＣｅｌｌＴａｂｌｅ）は、セルの数（Ｎｕｍｂｅｒ）と、個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）とから構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は、そのセルを含むプレイリスト名と、プレイリスト内でのセル番号とから構成されている。
【０１２６】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と、個々のグローバルイベントの情報とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入されたとき、最初に呼ばれる。グローバルイベント用のイベント情報は、イベントタイプ（Ｔｙｐｅ）と、イベントの識別子（ＩＤ）とだけを持っている。
【０１２７】
図１９は、グローバルイベントハンドラのプログラムのテーブル（“ＢＤ．ＰＲＯＧ”）を示す図である。
【０１２８】
本テーブルの内容は、図１７を用いて説明したイベントハンドラテーブルの内容と同じである。
【０１２９】
（イベント発生のメカニズム）
図２０から図２２を用いてイベント発生のメカニズムについて説明する。
【０１３０】
図２０はタイムイベントの例を示す図である。
【０１３１】
前述したとおり、タイムイベントは、プレイリスト情報（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＴｉｍｅＥｖｅｎｔ”である場合、イベント生成時刻（“ｔ１”）に、識別子“Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに出力される。プログラムプロセッサは、イベント識別子“Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、２つのボタンイメージの描画等のイベントが行われる。
【０１３２】
図２１はメニュー操作を行うユーザイベントの例を示す図である。
【０１３３】
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＵｓｅｒＥｖｅｎｔ”である場合、イベント生成時刻（“ｔ１”）に、ユーザイベントはレディとなる。この時、イベント自身は未だ生成されていない。イベントは、有効期間情報（Ｄｕｒａｔｉｏｎ）で示される期間レディ状態にある。
【０１３４】
図２１に示すように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されてプログラムプロセッサに出力される。プログラムプロセッサは、シナリオプロセッサにＵＯＰイベントを出力する。シナリオプロセッサは、ＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するか否かを調べ、有効なユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサに出力する。プログラムプロセッサは、イベント識別子“Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、プレイリスト＃２の再生が開始される。
【０１３５】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたのかを特定する情報は含まれない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録され保持される。このレジスタの値を調べることにより、イベントハンドラのプログラムを分岐処理することが可能である。
【０１３６】
図２２はグローバルイベントの例を示す図である。
【０１３７】
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（“ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベントのタイプ（Ｔｙｐｅ）が“ＧｌｏｂａｌＥｖｅｎｔ”である場合、ユーザがリモコンキーを操作したときにのみイベントが生成される。
【０１３８】
ユーザが“メニュー”キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されてプログラムプロセッサに出力される。プログラムプロセッサはシナリオプロセッサにＵＯＰイベントを出力し、シナリオプロセッサはそのＵＯＰイベントに対応するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサは、イベント識別子“ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、プレイリスト＃３の再生が開始される。
【０１３９】
本実施の形態では、“メニュー”キーは１個である場合を想定しているが、ＤＶＤレコーダのリモコンのように、メニューキーは複数存在していてもよい。その場合、メニューキー毎に対応する識別子が定義される。
【０１４０】
（仮想プレーヤマシン）
図２３を用いてプログラムプロセッサの機能を説明する。
【０１４１】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンは、ＢＤに対応する機能を有し、ＢＤプレーヤの実装には依存しない。即ち、仮想プレーヤマシンは、どのＢＤプレーヤにおいても同様の機能を実現できることが保証されている。
【０１４２】
仮想プレーヤマシンは、プログラミング関数とプレーヤ変数（レジスタ）とを持っている。プログラミング関数では、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能がＢＤ固有関数として定義されている。
【０１４３】
リンク関数：現在の再生を停止し、指定されたプレイリスト、セル、または時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅
【０１４４】
プレーヤ変数として、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と、一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１４５】
図２４はシステムパラメータ（ＳＰＲＭ）の一覧を示す図である。
【０１４６】
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
【０１４７】
なお、本実施の形態では、仮想プレーヤのプログラミング関数はＪａｖａ（登録商標）Ｓｃｒｉｐｔベースとして定義されているが、プログラミング関数は、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなどによって定義されてもよい。言い換えれば、プログラミング関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔによって定義されると限定されない。
【０１４８】
（プログラムの例）
図２５および図２６は、イベントハンドラでのプログラムの例を示す図である。
【０１４９】
図２５は、２つの選択ボタンを持つメニューのプログラムの例を示す図である。
【０１５０】
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）の先頭のタイムイベントに基づいて、図２５左側のプログラムが実行される。ゼネラルパラメータの一つＧＰＲＭ（０）に“１”がセットされている。ＧＰＲＭ（０）は、プログラムの中で、選択されているボタンを識別するために用いられている。最初の状態（初期値）では、左側に配置されているボタン１が選択されている。
【０１５１】
次に、ＰＮＧの描画が、描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行われる。ボタン１は、座標（１０、２００）を起点（左端）とする領域に、ＰＮＧイメージ“１ｂｌａｃｋ．ｐｎｇ”が描画されることにより形成される。ボタン２は、座標（３３０，２００）を起点（左端）とする領域に、ＰＮＧイメージ“２ｗｈｉｔｅ．ｐｎｇ”が描画されることにより形成される。
【０１５２】
また、本セルの最後のタイムイベントが用いられて、図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って、セルの先頭から再度再生するように指定されている。
【０１５３】
図２６は、メニュー選択のユーザイベントのイベントハンドラの例を示す図である。
【０１５４】
「左」キー、「右」キー、「決定」キーが押された場合の夫々のキーに対応するプログラムが、イベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２１を用いて説明したとおり、ユーザイベントが生成され、図２６のイベントハンドラが起動する。本イベントハンドラでは、選択ボタンを識別するＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）とを使って、分岐処理が行われる。
【０１５５】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーである場合
ＧＰＲＭ（０）を“２”に再設定して、選択状態にあるボタンを右ボタン２に変更する。
【０１５６】
ボタン１、ボタン２のイメージを夫々書き換える。
【０１５７】
条件２）選択キーが「決定（ＯＫ）」であって、ボタン１が選択されている場合
プレイリスト＃２の再生を開始する。
【０１５８】
条件３）選択キーが「決定（ＯＫ）」であって、ボタン２が選択されている場合
プレイリスト＃３の再生を開始する。
【０１５９】
上記のような分岐処理が行われる。
【０１６０】
（プレーヤ処理フロー）
次に、図２７から図３０を用いてプレーヤの処理フローを説明する。
【０１６１】
図２７は、ＡＶの再生までの基本処理フローを示す図である。
【０１６２】
ＢＤディスクが挿入されると（Ｓ１０１）、ＢＤプレーヤは、“ＢＤ．ＩＮＦＯ”ファイルの読み込みと解析とを行い（Ｓ１０２）、“ＢＤ．ＰＲＯＧ”ファイルを読み込む（Ｓ１０３）。“ＢＤ．ＩＮＦＯ”ファイルおよび“ＢＤ．ＰＲＯＧ”ファイルは、共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１６３】
続いて、シナリオプロセッサは、“ＢＤ．ＩＮＦＯ”ファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントはプログラムプロセッサによって受け取られ、プログラムプロセッサは、そのイベントに対応するイベントハンドラを実行する（Ｓ１０５）。
【０１６４】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されている、ことが期待される。仮に、プレイリストの再生が指示されていない場合、プレーヤは何も再生することなく、ユーザイベントを待ち続ける（Ｓ２０１）。ＢＤプレーヤがユーザからのリモコン操作による指示を受け付けると、ＵＯＰマネージャは、プログラムマネージャに対してＵＯＰイベントの実行を開始させる（Ｓ２０２）。
【０１６５】
プログラムマネージャは、ＵＯＰイベントがメニューキーであるか否かを判別し（Ｓ２０３）、ＵＯＰイベントがメニューキーである場合、シナリオプロセッサにＵＯＰイベントを出力し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは、生成されたユーザイベントに対応するイベントハンドラを実行する（Ｓ２０５）。
【０１６６】
図２８は、ＰＬの再生開始からＶＯＢの再生開始までの処理フローを示す図である。
【０１６７】
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリストの再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリストの再生に必要な情報として、プレイリスト情報“ＸＸＸ．ＰＬ”の読み込みと解析とを行い（Ｓ３０２）、プレイリストに対応するプログラム情報“ＸＸＸ．ＰＲＯＧ”を読み込む（Ｓ３０３）。続いて、シナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する（Ｓ３０４）。セルの再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出されたことを意味し、プレゼンテーションコントローラはＡＶの再生を開始する（Ｓ３０５）。
【０１６８】
ＡＶの再生が開始されると（Ｓ４０１）、プレゼンテーションコントローラは、再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）の読み込みと解析とを行う（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生を開始するＶＯＢＵとそのアドレスとを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出す（Ｓ４０３）。これにより、ＶＯＢデータがデコーダに送られ、その再生が開始される（Ｓ４０４）。
【０１６９】
ＶＯＢの再生は、そのＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセルの再生（Ｓ３０４）へ移行する。次のセルが無い場合、再生は停止する（Ｓ４０６）。
【０１７０】
図２９は、ＡＶの再生開始後からのイベント処理フローを示す図である。
【０１７１】
ＢＤプレーヤはイベントドリブン型のプレーヤである。プレイリストの再生が開始すると、タイムイベント系、ユーザイベント系、および字幕表示系のイベント処理が夫々起動し、平行してイベント処理が実行される。
【０１７２】
Ｓ５００系の処理は、タイムイベント系の処理である。
【０１７３】
プレイリストの再生開始後（Ｓ５０１）、プレイリストの再生が終了しているか否かを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったか否かを確認する（Ｓ５０３）。タイムイベント発生時刻になった場合、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサはタイムイベントを受け取って、イベントハンドラを実行する（Ｓ５０５）。
【０１７４】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、および、ステップＳ５０４でイベントハンドラを実行した後、ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリストの再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１７５】
Ｓ６００系の処理は、ユーザイベント系の処理である。
【０１７６】
プレイリストの再生開始後（Ｓ６０１）、プレイリストの再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰの受付確認ステップに移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサは、ＵＯＰイベントがメニューコールであるか否かを確認する（Ｓ６０５）。ＵＯＰイベントがメニューコールである場合、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行する（Ｓ６０８）。
【０１７７】
ステップＳ６０５でＵＯＰイベントがメニューコールでないと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントであることを示している。この場合、現在時刻がユーザイベント有効期間内であるか否かをシナリオプロセッサが判断する（Ｓ６０６）。現在時刻がユーザイベント有効期間内である場合、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行する（Ｓ６０８）。
【０１７８】
ステップＳ６０３でＵＯＰが受付けられていない場合、ステップＳ６０６で現在時刻がユーザイベント有効期間にない場合、および、ステップＳ６０８でイベントハンドラを実行した後、ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリストの再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１７９】
図３０は字幕処理のフローを示す図である。
【０１８０】
プレイリストの再生開始後（Ｓ７０１）、プレイリストの再生終了確認ステップ（Ｓ７０２）を経て、字幕の描画開始時刻確認ステップ（Ｓ７０３）に移る。現在時刻が字幕の描画開始時刻である場合、シナリオプロセッサはプレゼンテーションコントローラに字幕の描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕の描画を指示する（Ｓ７０４）。ステップＳ７０３で現在時刻が字幕の描画開始時刻でないと判断された場合、現在時刻が字幕の表示終了時刻であるか否かを確認する（Ｓ７０５）。現在時刻が字幕の表示終了時刻であると判断された場合、プレゼンテーションコントローラはイメージプロセッサに字幕の消去を指示し、イメージプロセッサは描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１８１】
字幕の描画ステップＳ７０４の終了後、字幕の消去ステップＳ７０６の終了後、および、字幕の表示終了時刻確認ステップＳ７０５で現在時刻が字幕の表示終了時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリストの再生が終了したことが確認されると、字幕の表示に関する処理は強制的に終了する。
【０１８２】
（実施の形態１）
次に、実施の形態１について説明する。
【０１８３】
実施の形態１はＢＤの音声データにおけるストリーム構造に関し、その内容は基本的には上記の関連する実施の形態に基づく。したがって、実施の形態１では、関連する実施の形態から拡張した部分、および関連する実施の形態と異なる部分を中心に説明する。
【０１８４】
図３１は階層構造を持たない１つのアクセスユニット（映像／音声の情報に対する復号および再生の符号化単位）の構造を示す図である。映像符号化方式の一つであるＭＰＥＧ−２ビデオや、音声符号化方式の一つであるＭＰＥＧ−１オーディオなどでは、一つのアクセスユニットは、図３１に示すように、ヘッダ部（Ｂａｓｅ Ｈｅａｄｅｒ）と、ペイロード部（Ｂａｓｅ Ｐａｙｌｏａｄ）とから構成される。
【０１８５】
Ｂａｓｅ Ｈｅａｄｅｒには、Ｂａｓｅ ｆｒａｍｅの同期信号であるＢａｓｅ ＳＹＮＣ、このアクセスユニットのデータサイズを示すＡＵ＿ＳＩＺＥ、このアクセスユニットがＢａｓｅ ｆｒａｍｅからのみ構成されているか否かを示すＥＸＴ、もしこのアクセスユニットがＢａｓｅ ｆｒａｍｅからのみで構成されていない場合に、どのような種類の拡張情報が付与されているのかを示すＥＸＴ＿ＩＤ、および、将来使用される場合のためのリザーブ領域などが設けられている。
【０１８６】
図３１のアクセスユニットでは階層構造は導入されておらず、１つの符号化方式のみで１つのアクセスユニット全体が符号化されている。それは、１種類の復号方式のみで１アクセスユニット全てを復号することができることを意味する。
【０１８７】
図３２は、Ｂａｓｅ ｆｒａｍｅに、Ｂａｓｅ ｆｒａｍｅとは異なる符号化方式により、例えば、より高画質な映像情報やより高音質な音声情報を符号化したＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅが追加された、１アクセスユニットの構造を示す図である。
【０１８８】
Ｂａｓｅ ＨｅａｄｅｒのＥＸＴは、このアクセスユニットがＢａｓｅ ｆｒａｍｅからのみで構成されていないことを示し、ＥＸＴ＿ＩＤは、他の拡張階層データの内、Ｌｅｖｅｌ１がＢａｓｅ ｆｒａｍｅに続いて符号化されていることを示している。
【０１８９】
ＡＵ＿ＳＩＺＥは、アクセスユニットのサイズを表す。ＡＵ＿ＳＩＺＥを使うことにより、Ｂａｓｅ ｆｒａｍｅしか復号できないデコーダ（Ｌｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを復号できないデコーダ）がこのアクセスユニットをＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを無視しながら適切に復号できるように、１アクセスユニットを設計することができる。
【０１９０】
このように、元々ある符号化単位（Ｂａｓｅ）に新たな拡張部分（Ｌｅｖｅｌ１−ＥＸＴ）を追加しても、Ｌｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを無視することにより、図３２に示すアクセスユニットにより構成されるストリームを復号することができる。それとともに、次々と新しい圧縮符号化アルゴリズムを導入することができる。
【０１９１】
同様にＬｅｖｅｌ２−ＥＸＴまで拡張されたアクセスユニットを、図３３に示す。Ｌｅｖｅｌ２−ＥＸＴのデータは、例えば、Ｌｅｖｅｌ１−ＥＸＴまでのデータのサンプリングレートより高いサンプリングレートの音声を得るためのＬｅｖｅｌ１−ＥＸＴまでのデータに含まれないデータである。
【０１９２】
ＥＸＴ＿ＩＤは、Ｌｅｖｅｌ１とＬｅｖｅｌ２とが存在することを示すように設定される。
【０１９３】
図３４は、このように階層構造を持って符号化されたデータ（例えば、Ｌｅｖｅｌ２ストリーム）を、様々な階層に対応したデコーダに出力するストリーム読込／供給部の、データの出力先毎に異なる動作を説明するための図である。
【０１９４】
Ｂａｓｅデコーダにデータを出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＬｅｖｅｌ１−ＥＸＴとＬｅｖｅｌ２−ＥＸＴフレームとを取り除いて、Ｂａｓｅ ｆｒａｍｅだけを出力する。その際、ストリーム読込／供給部は、Ｂａｓｅ Ｈｅａｄｅｒのアクセスユニットのサイズ情報であるＡＵ＿ＳＩＺＥ、Ｂａｓｅ ｆｒａｍｅからのみで構成されているか否かを示すＥＸＴ、および拡張階層データの種別を示すＥＸＴ＿ＩＤの各値を書換えて、データを出力する。
【０１９５】
同様に、Ｌｅｖｅｌ１デコーダにデータを出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＬｅｖｅｌ２−ＥＸＴ ｆｒａｍｅを取り除き、ＡＵ＿ＳＩＺＥ、およびＥＸＴ＿ＩＤの各値を書換えてデータを出力する。
【０１９６】
勿論、Ｌｅｖｅｌ２ストリームをＬｅｖｅｌ２デコーダに出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームをそのまま出力する。
【０１９７】
ここで、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及しており、新たにＬｅｖｅｌ２−ＥＸＴを導入する場合を想定する。この場合、Ｌｅｖｅｌ２ストリームからＢａｓｅ ｆｒａｍｅとＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅとを抽出することのみを行い、抽出したデータをその機器に対して出力することが望ましい。つまり、データを一切修正しないことが望ましい。
【０１９８】
図３５は、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及した場合に、Ｌｅｖｅｌ２−ＥＸＴを導入するための理想的なアクセスユニットの構造を示す図である。
【０１９９】
図３５に示すアクセスユニットでは、アクセスユニットがＢａｓｅとＬｅｖｅｌ１−ＥＸＴとから構成される場合と同様に、Ｌｅｖｅｌ１−ＥＸＴまでのデータに関する情報は、Ｂａｓｅ Ｈｅａｄｅｒ（およびＬｅｖｅｌ１ Ｈｅａｄｅｒ）に記述されている。それに対して、Ｌｅｖｅｌ２−ＥＸＴ以降の拡張階層データに関する情報は、リザーブ領域のようなＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダが感知しない領域に記述されている。図３５では、ＥＸＴ＿ＩＤにはＬｅｖｅｌ２は存在しないことを示す値が設定されているが、Ｌｅｖｅｌ１のフレームまでは使われていなかったリザーブ領域にＥＸＴ＿ＩＤ２が用意され、そこにＬｅｖｅｌ２の拡張階層データが存在することが記述されている。
【０２００】
図３５に示すＬｅｖｅｌ２のアクセスユニット（例えばＢａｓｅ、Ｌｅｖｅｌ１−ＥＸＴ、およびＬｅｖｅｌ２−ＥＸＴを含むアクセスユニット）を、Ｌｅｖｅｌ１のアクセスユニット（Ｂａｓｅのみ、または、ＢａｓｅおよびＬｅｖｅｌ１−ＥＸＴ）へ変換して出力する際、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＢａｓｅの部分とＬｅｖｅｌ１−ＥＸＴの部分との抽出のみを行う。つまり、ストリーム読込／供給部は、データの書換えを一切行わずにＬｅｖｅｌ１のデコーダに、Ｌｅｖｅｌ１のアクセスユニットにより構成されるストリームを出力することが可能となる。
【０２０１】
上述の方法は、ＡＵ＿ＳＩＺＥなどのサイズ情報のビットの割り当て数が少なく、Ｌｅｖｅｌ２を加えた際に１アクセスユニットのデータサイズが大きすぎて、サイズ情報をＡＵ＿ＳＩＺＥでは表現することができない場合などにも有効である。
【０２０２】
「ＤＴＳ」では、ＤＴＳ＋＋によりロスレス圧縮の符号化データが生成されても、サンプリングＰＣＭデータ如何によっては、ほとんど圧縮の効果が得られない場合がある、その場合、ＤＴＳの数１００ＫｂｐｓからからＤＴＳ＋＋（ロスレス）の数１０Ｍｂｐｓ辺りまで、ビットレートが急激に増えることが考えられる。その結果、現在のＤＴＳのＣｏｒｅヘッダに記述されるアクセスユニットのデータサイズを示すＦＳＩＺＥ（１４ビットでバイト単位のデータサイズを示す）では、サイズを示すためのビットフィールドが不足する問題が起こる。このため、ＤＴＳ＋＋のロスレス圧縮のように、サイズをＡＵ＿ＳＩＺＥ（ＦＳＩＺＥ）で記述することができない場合、ＡＵ＿ＳＩＺＥの範囲を２つのデータブロックに分けることが考えられる。
【０２０３】
図３６は、Ｌｅｖｅｌ１までサポートする機器が存在し、新たにＬｅｖｅｌ２を採用する場合のデータストリームのデータ構造を示す図である。
【０２０４】
図３６は、１つのアクセスユニットが、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されていることを、明確に示している。
【０２０５】
映像や音声のエレメンタリーストリームをＭＰＥＧ２−ＴＳ（transport stream）やＭＰＥＧ２−ＰＳ（program stream）で多重化する場合、データはＰＥＳパケットと呼ばれる論理単位に格納されることがＭＰＥＧ規格で規定されている。
【０２０６】
ＰＥＳパケットは、ＰＥＳヘッダと実データを格納するＰＥＳペイロードとから構成され、ＰＥＳヘッダは図３６に示すように様々なフィールドを有する。
【０２０７】
ｓｔｒｅａｍ＿ｉｄは、そのＰＥＳパケットのペイロード部に格納されているエレメンタリーストリームの種別を示す。一般にｓｔｒｅａｍ＿ｉｄが異なることは、エレメンタリーストリームが異なることを示す。ＰＥＳ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈは、ＰＥＳパケットのデータサイズを示す。ＰＥＳ＿ｐｒｉｏｒｉｔｙは、そのＰＥＳパケットの優先レベルを識別するための情報である。ＰＴＳ＿ＤＴＳ＿ｆｌａｇｓは、そのＰＥＳペイロードの再生開始時刻情報であるＰＴＳと復号開始時刻情報であるＤＴＳとがあるか否かを示す情報である。ＰＴＳとＤＴＳの値が同じ場合にはＤＴＳは省略される。ＰＥＳ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ、およびＰＥＳ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ＿２は、夫々ＰＥＳパケットのペイロード部に拡張データ領域があるか否かを示す情報である。ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎは、ｓｔｒｅａｍ＿ｉｄ＝０ｘＦＤ（ｅｘｔｅｎｄｅｄ＿ｓｔｒｅａｍ＿ｉｄ）の場合にのみ存在可能なｓｔｒｅａｍ＿ｉｄを補うための、エレメンタリーストリームの識別補助情報である。
【０２０８】
アクセスユニットのＢａｓｅフレーム部分（図３６では、Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ部分）と、Ｂａｓｅフレームを含まない部分（図３６では、Ｌｅｖｅｌ２−ＥＸＴ部分）とは、後述するＴＳパケットの識別情報であるPacket Identifier（ＰＩＤ）を同一
にし、ｓｔｒｅａｍ＿ｉｄを異ならせて分けられてもよいし、ＰＴＳ＿ＤＴＳ＿ｆｌａｇｓを異ならせて分けられてもよいし、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを用いて分けられてもよい。Ｂａｓｅフレーム部分を、２０３２バイト、またはＤＶＤ−Ｖｉｄｅｏにも対応する２０１３バイトで完結する部分とし、１アクセスユニットのそれ以外の部分を、Ｂａｓｅフレームを含まない部分とすることにより、Ｂａｓｅフレーム部分とＢａｓｅフレームを含まない部分とが分けられてもよい。
【０２０９】
例えば、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを用いる場合、Ｂａｓｅフレームを含むＰＥＳパケットもＢａｓｅフレームを含まないＰＥＳパケットもｓｔｒｅａｍ＿ｉｄ＝０ｘＦＤ（プライベートストリーム）となる。そこで、Ｂａｓｅフレームを含むＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値（例えば０ｘ７０）と、Ｂａｓｅフレームを含まないＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値（例えば０ｘ７１）とを異なる値に設定する。これにより、プレーヤや外部出力部はＢａｓｅフレームを含むデータのみを抽出することができる。この場合、設定されるｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値は、論理アドレス０ｘ４０から０ｘ７Ｆのプライベートストリーム領域に記録される。
【０２１０】
１つ目のＰＥＳパケットには、現存する機器に対応する（ディジタルインターフェース上のプロトコルなどが規定されており、尚且つそれに対応した入力端子を持つ、現存するＡＶレシーバに対応する）Ｌｅｖｅｌ１までの符号化単位を格納することができる。２つ目のＰＥＳパケットには、現存しない機器に対応する（ディジタルインターフェース上のプロトコルなどが規定されていない、またはそれに対応した入力端子を持たない、現存しないＡＶレシーバに対応する）Ｌｅｖｅｌ２以降の符号化単位を格納することができる。
【０２１１】
１つ目のＰＥＳパケットと、２つ目以降のＰＥＳパケットとは、ｓｔｒｅａｍ＿ｉｄ、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ、またはＰＴＳ＿ＤＴＳ＿ｆｌａｇｓ、の値を判断することにより区別することが可能である。
【０２１２】
上述したように、ＰＥＳヘッダには、ＰＥＳ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈなどのサイズ情報があるため、ＰＥＳペイロードはそのサイズ情報から極めて容易に抽出することができる。従って、Ｌｅｖｅｌ１−ＥＸＴまでの符号化単位が既存のＡＶレシーバやディジタルインターフェースに互換性が高く１つ目のＰＥＳパケットにまとめて格納されている場合、１つ目のＰＥＳパケットのＰＥＳペイロードは、ＰＥＳヘッダを解析することで容易に抽出することができる。
【０２１３】
図３７を用いて、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されているアクセスユニットの処理を再度説明する。
【０２１４】
ＢＤプレーヤ１０００において、複数のアクセスユニットにより構成されているストリームが記録されているＢＤディスク１００１から、そのストリームがパーサ１００２に入力される。パーサ１００２は、各アクセスユニットについて、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを区別する。
【０２１５】
そして、パーサ１００２は、Ｂａｓｅフレーム部のみを処理することができる、ＢＤプレーヤ１０００内部のデコーダ１００３へ、Ｂａｓｅフレーム部である１つ目のＰＥＳパケットを出力する。デコーダ１００３は、１つ目のＰＥＳパケットをデコードし、デコードデータを、ステレオ／アナログインターフェース１００４を介して、テレビ１００５に出力する。テレビ１００５は、ＢＤプレーヤ１０００からのデータを再生し、そのデータに基づく画像および音声を出力する。
【０２１６】
また、パーサ１００２は、ＳＰＤＩＦ１００６を介して、ＢＤプレーヤ１０００外部のＡ／Ｖレシーバ１００７内の、Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９に、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットを出力する。Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９は、Ｂａｓｅフレーム部や、それに加えてＬｅｖｅｌ１−ＥＸＴフレーム部を処理することができるデコーダであり、ＢＤプレーヤ１０００からの１つ目のＰＥＳパケットを処理する。
【０２１７】
さらに、パーサ１００２は、Ａｄｖａｎｃｅｄ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ１０１１を介して、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを、Ａ／Ｖレシーバ１００７内の、Ｌｅｖｅｌ２−ＥＸＴデコーダ１０１２に出力する。Ｌｅｖｅｌ２−ＥＸＴデコーダ１０１２は、ＢａｓｅからＬｅｖｅｌ２−ＥＸＴフレームまでの全てのフレームを処理することができるデコーダであり、ＢＤプレーヤ１０００からの両方のＰＥＳパケットを処理する。
【０２１８】
このように、パーサ１００２がアクセスユニットを解析することにより、アクセスユニットは、既存のデコーダであるデコーダ１００３、Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９に送信され、処理される。それとともに、アクセスユニットは、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを処理することができるＬｅｖｅｌ２−ＥＸＴデコーダ１０１２に出力され、処理される。
【０２１９】
なお、図３７のＢＤプレーヤ１０００は、本発明のデータ再生装置の一例である。パーサ１００２はデータ分別装置の一例である。
【０２２０】
全デコーダで復号が保証されているＢａｓｅフレームが格納されたＰＥＳパケットの次には、それに付加機能を与えることができるものの復号互換性の低い拡張フレーム（Ｌｅｖｅｌ１−ＥＸＴやＬｅｖｅｌ２−ＥＸＴなど）が格納されたＰＥＳパケットが続くことが重要である。また、１アクセスユニットの中のデータの並び順は、Ｂａｓｅ、Ｌｅｖｅｌ１−ＥＸＴ、Ｌｅｖｅｌ２−ＥＸＴ、Ｌｅｖｅｌ３−ＥＸＴ、Ｌｅｖｅｌ４−ＥＸＴ、・・・と昇順であり、１アクセスユニットの全ての符号化単位を抽出する際に並べ替えが発生しないことが重要である。
【０２２１】
ＤＴＳ（Ｄｉｇｉｔａｌ Ｔｈｅａｔｅｒ Ｓｙｓｔｅｍｓ社が開発した音声符号化方式）では、１つ目のＢａｓｅ（ＤＴＳではｃｏｒｅと呼ぶ）を含むＰＥＳパケットのペイロードのデータサイズは、ディジタルインターフェースであるＳＰＤＩＦ（Sony/Philips
Digital Interconnect Format、民生向けはＩＥＣ６０９５８−３規格で規定）の規定に従い、２０３２バイト以下とすればよい。これは、４８ＫＨｚでサンプリングされた音声データの内５１２サンプルを１フレームに格納するＤＴＳ−ｔｙｐｅＩ方式の場合、ビットレートに換算して１５２４Ｋｂｐｓ以下までを１つめのＰＥＳパケットにて格納するということになる。
【０２２２】
ここで、１５２４[Ｋｂｐｓ]＝２０３２[ｂｙｔｅｓ]×８[ｂｉｔｓ／ｂｙｔｅ]×４８０００[ｓａｍｐｌｅ／ｓｅｃ]／５１２[ｓａｍｐｌｅ]
【０２２３】
ＤＶＤ−Ｖｉｄｅｏプレーヤから出力されるデータに準拠したＤＴＳ対応のＡＶレシーバ（ホームシアターなど）との互換性を保つには、１つ目のＢａｓｅを含むＰＥＳパケットのペイロードのデータサイズを、２０１３バイト以下とすればよい。
【０２２４】
このようにして、ＰＥＳパケット単位で、既存のプレーヤ／デコーダと新規のプレーヤ／デコーダとの互換性を保って、１つのアクセスユニットのデータを分割して管理する。つまり、ディジタルインターフェースの規定に応じて、１つのアクセスユニットのデータを分割して管理する。これにより、所定の拡張階層データまでを含むアクセスユニットデータを、一切加工することなく、かつ不整合を起こすことなく送出することができる。
【０２２５】
図３８は、ＭＰＥＧ２−ＴＳで多重化される、階層構造を持つアクセスユニットの構造を示す図である。
【０２２６】
ＭＰＥＧ２−ＴＳは、１つ１８８バイトのＴＳパケットから構成されるディジタルストリームであり、ＭＰＥＧ２−ＴＳのプログラムの構成情報を格納しているProgram Map Table（ＰＭＴ）の一部は、図３８に示すような構造である。
【０２２７】
ＭＰＥＧ２−ＴＳの規定では、１つのＴＳパケットが複数のＰＥＳパケットを格納することは禁止されている。そのため、図３８に示すように、Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴの符号化単位を格納したＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴの符号化単位を格納したＰＥＳパケットとは、別々のＴＳパケットに格納される。
【０２２８】
ＭＰＥＧ２−ＴＳには、そのＭＰＥＧ２−ＴＳ内に格納されているプログラムを示すＰＭＴパケットが格納されている。ＰＭＴは、所定のプログラムに属する映像情報や音声情報などの各種情報がどのＰＩＤのＴＳパケットで運ばれているのかを示すｅｌｅｍｅｎｔａｒｙ＿ｓｔｒｅａｍ＿ＰＩＤと、そのエレメンタリーストリームの符号化種別を示すｓｔｒｅａｍ＿ｔｙｐｅと、そのエレメンタリーストリームについて付加情報を記述した１つまたは複数のｄｅｓｃｒｉｐｔｏｒとを格納している。
【０２２９】
階層構造を持つ符号化方式に対するｄｅｓｃｒｉｐｔｏｒには、拡張階層のレベル情報（ｃｏｄｉｎｇ＿ｌｅｖｅｌ）や、現時点でサポートされていない、または極めて少ない拡張階層を用いているか否かを示す情報（例えば、Ｌｅｖｅｌ２を使っているか否かを示す識別情報、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅ）や、符号化データが音声情報であれば、チャンネル配置情報（ｃｈａｎｎｅｌ＿ａｓｓｉｇｎｍｅｎｔ）や、サンプリング周波数（ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙ）などの情報が記述されることが考えられる。
【０２３０】
符号化データが映像情報であれば、ｄｅｓｃｒｉｐｔｏｒに、ｃｏｄｉｎｇ＿ｌｅｖｅｌや、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅの他に、解像度情報やフレーム周波数などが記述されることが考えられる。
【０２３１】
ここで、符号化データが音声情報である場合のｄｅｓｃｒｉｐｔｏｒに記述される内容を、図３９から図４１を用いて説明する。
【０２３２】
図３９に示すように、ｄｅｓｃｒｉｐｔｏｒには、レベルと、オーディオ属性（Ｑ値、周波数、チャンネル、およびスピーカレイアウト）との関係を記述することができる。スピーカレイアウトの情報を利用することにより、デコーダは、処理するストリームのレイアウトと、実際のレイアウトとが異なっていても、適宜チャンネル毎に修正することができる。図４０（Ａ）に、５．１チャンネルのスピーカレイアウトを示し、図４０（Ｂ）に、７．１チャンネルのスピーカレイアウトを示す。
【０２３３】
上述したように、ｄｅｓｃｒｉｐｔｏｒには、Ｌｅｖｅｌとチャンネルとの関係を記述することができる。
【０２３４】
それだけではなく、図４１の“チャンネル構造”に示すように２チャンネルや５．１チャンネルのダウンミックス音が含まれているか否かをチャンネル数情報として記述してもよい。これにより、各チャンネルに対応するデコーダは、適切に音を出力可能か否か識別することができる。例えば、チャンネル構造が７．１ｃｈ（２＋３．１＋２の階層構造）である場合、２ｃｈ ｄｅｃｏｄｅｒは、２チャンネルの音を出力することができ、５．１ｃｈ ｄｅｃｏｄｅｒは、５．１チャンネル（２＋３．１チャンネル）の音を出力することができる。しかしながら、チャンネル構造がこのような階層構造を伴わない７．１ｃｈである場合、処理量の都合から２ｃｈ ｄｅｃｏｄｅｒおよび５．１ｃｈ ｄｅｃｏｄｅｒは、音を出力することができない可能性がある。
【０２３５】
ＤＴＳのデータは、ＤＴＳ（Ｂａｓｅに相当）およびＤＴＳ＋（Ｌｅｖｅｌ１−ＥＸＴに相当）のデータと、ＤＴＳ＋＋（Ｌｅｖｅｌ２−ＥＸＴに相当）のデータとに分けられる。
【０２３６】
ＤＴＳ＋もＤＴＳ＋＋も、どちらも拡張階層データを含むが、その扱いは異なる。そのため、ｄｅｓｃｒｉｐｔｏｒに、対象ストリームがＤＴＳ／ＤＴＳ＋であるのか、ＤＴＳ＋＋であるのかを識別するための情報（図３８のＬｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅに相当）が含められてもよい。
【０２３７】
なお、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅは、対象ストリームがＤＶＤ−Ｖｉｄｅｏと同様の形式（ＤＴＳ−ｔｙｐｅＩ形式）でＳＰＤＩＦへ出力可能な部分だけを含んでいるのか否かを示す情報として用いられてもよい。
【０２３８】
これら、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅや、ｃｏｄｉｎｇ＿ｌｅｖｅｌの情報は、データベースファイル（図１３のＶＯＢＩファイルのＡｔｔｒｉｂｕｔｅ内など）に記述されてもよい。これらの情報は、ディジタルデータを出力する際の抽出処理が異なることを示すのは勿論であるが、ＢＤのメニュー画面などで映像や音声の属性表示／選択に利用することも可能である。例えば、Ｌｅｖｅｌ２に対応していないプレーヤは、復号対象のストリームがＬｅｖｅｌ２のストリームであることをデータベースから判定し、Ｌｅｖｅｌ２の音声を予め選択不可能としてユーザに供することもできる。
【０２３９】
図４２は、ＢＤ−ＲＯＭなどの光ディスクに記録する際のＭＰＥＧ２−ＴＳのファイルフォーマットを示す図である。
【０２４０】
ＴＳパケット毎に、４バイトのArrival Time Stamp（ＡＴＳ、ＴＳパケットのデコーダへの入力開始時刻情報）が付与されて１つのＴｉｍｅｄ ＴＳパケットが構成され、３２個のＴｉｍｅｄ ＴＳパケットがまとめて３セクタ（６ＫＢ）に記録される。
【０２４１】
図４３は、ＤＶＤ−Ｖｉｄｅｏで規定されるＤＴＳの詳細を説明するための図である。
【０２４２】
ＤＶＤ−Ｖｉｄｅｏでは、１アクセスユニットの最大サイズは２０１３バイトと定めてられているが、これがＤＴＳ／ＤＴＳ＋／ＤＴＳ＋＋の何れに属するかは規定されていない。つまり、４８ＫＨｚで５１２サンプル分の音声情報を表す１アクセスユニットは、ｃｏｒｅのみで構成されていてもよいし、ｃｏｒｅとｅｘｔｅｎｓｉｏｎとから構成されていてもよい。
【０２４３】
最大２０１３バイトの１アクセスユニットはＰＥＳペイロードに格納され、ＰＥＳヘッダ（ＰＥＳｈｄｒ）とパックヘッダ（Ｐａｃｋｈｄｒ）とが付与され、全体のサイズは２ＫＢとなる。
【０２４４】
ＰＥＳペイロードの音声データだけを格納したＤＴＳバーストペイロードが形成され、それに、２バイトずつで計８バイトのプリアンブル群（Ｐａ，Ｐｂ，Ｐｃ，Ｐｄ）と、ｓｔｕｆｆｉｎｇデータとが付与されて、２ＫＢのＩＥＣ６１９３７−５フレームが形成される。
【０２４５】
ＳＰＤＩＦ（ＩＥＣ６０９５８−３）は１９２フレームを１ブロックとした周期で転送される。１フレームは２つのサブフレームから成り、サブフレームはＩＥＣ６１９３７−５フレームの内の２バイトのデータを運ぶ４バイトのデータである。
【０２４６】
従って、ＤＶＤ−Ｖｉｄｅｏと互換性を保つようにＤＴＳのデータを送るには、ＩＥＣ６１９３７−５フレームの内２０１３バイトまでに収まるように、ｃｏｒｅとｅｘｔｅｎｓｉｏｎのビット量を制御すればよい。これにより、データの種類がＤＴＳ／ＤＴＳ＋／ＤＴＳ＋＋の何れであるのかを問う必要はなくなる。
【０２４７】
これが、ＢＤ−ＲＯＭでＤＴＳ＋＋を格納する場合、ｃｏｒｅを含むＰＥＳパケットのペイロード部を２０１３バイト以下の符号化単位とする理由である。
【０２４８】
当然ながらＤＶＤ−Ｖｉｄｅｏと同様に、２０１３バイト以下で１アクセスユニットを構成するフレームが完結している必要がある。例えば、ＢａｓｅフレームとＬｅｖｅｌ１−ＥＸＴフレームのサイズが２０１４バイトであるならば、全体が２０１３バイトに収まるように再エンコードするか、ＢａｓｅフレームだけのＰＥＳパケットを構成し、Ｌｅｖｅｌ１−ＥＸＴは多重化順序が次のＰＥＳパケットに格納するなどとする必要がある。
【０２４９】
図４４は、デマルチプレクサ３１０（図７）、および、ストリーム読込／供給部（図３４）の処理を示すフローチャートである。
【０２５０】
Ｓ８０１は、ＳＰＤＩＦに対応するために、図３６に示すアクセスユニットの一部を抽出して外部に出力するディジタル出力開始ステップである。
【０２５１】
Ｓ８０２は再生終了判定ステップであり、ＹＥＳの場合、データの出力を終了し、ＮＯの場合、ＰＥＳパケットの処理Ｓ８０３へ進む。
【０２５２】
Ｓ８０３では、ＰＩＤによるＴＳパケットの弁別と、ＰＥＳパケットのヘッダの解析と、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎの読み出しとを行う。
【０２５３】
Ｓ８０４では、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを判定する。そのフィールドの値が、“０ｘ７１（非Ｂａｓｅフレーム部）”である場合はＳ８０５へ進み、“０ｘ７０（Ｂａｓｅフレーム部）”である場合はＳ８０６へ進む。
【０２５４】
Ｓ８０５は、Ｓ８０４で、ＰＥＳパケットが非Ｂａｓｅフレーム部であると判定された場合に行われるステップであり、Ｓ８０５ではＰＥＳパケットを破棄する。
【０２５５】
Ｓ８０６は、Ｓ８０４で、ＰＥＳパケットがＢａｓｅフレーム部であると判定された場合に行われるステップである。Ｓ８０６では、ＰＥＳパケットのペイロード（Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ）を取り出し、図７および図３４を用いて説明したとおり、フレームデータをデコーダまたは既存ディジタルＩ／Ｆへ出力する。
【０２５６】
Ｓ８０５およびＳ８０６の後に、再生終了判定ステップＳ８０２へと戻る。
【０２５７】
次に、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴ（以下、単に“Ｂａｓｅ”という）と、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴ（以下、単に“Ｌｅｖｅｌ２”という）とを１個のアクセスユニットに多重化する方法を説明する。
【０２５８】
先ず、図４５を用いて、入力時刻管理装置２０００と、ＴＳ ｓｙｓｔｅｍ ｔａｒｇｅｔ ｄｅｃｏｄｅｒ ｍｏｄｅｌ（以下、“デコーダモデル”または“Ｔ−ＳＴＤ”という）３０００とを説明する。
【０２５９】
図４５に示すように、入力時刻管理装置２０００は、リードバッファ（ＲＢ）と、ｄｅ−ｐａｃｋｅｔｉｚｅｒと、ＡＴＳ Ｃｏｕｎｔｅｒと、２７ＭＨｚ Ｃｌｏｃｋとを有する。ＲＢは、“ｘｘｘｘ．ｖｏｂ”ファイルを一時的に蓄積する。ｄｅ−ｐａｃｋｅｔｉｚｅｒは、“ｘｘｘｘ．ｖｏｂ”のＴＳパケットからＡＴＳを除去し、最初のＴＳパケットからＡＴＳを除去するとき、最初のＴＳパケットのＡＴＳの値を、ＡＴＳ Ｃｏｕｎｔｅｒにセットする。また、ｄｅ−ｐａｃｋｅｔｉｚｅｒは、ＡＴＳの時刻通りに各ＴＳパケットのみをＴ−ＳＴＤ３０００に出力する。２７ＭＨｚ Ｃｌｏｃｋは、２７ＭＨｚでクロックを出力する。
【０２６０】
図４５に示すように、デコーダモデル３０００は、デマルチプレクサと、画像に関するバッファであるＴＢ、ＭＢ、およびＥＢと、デコーダＤｖと、音データのＢａｓｅに関するバッファであるＴＢａ１およびＢａ１と、デコーダＤａ１と、音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」に関するバッファであるＴＢａ２およびＢａ２と、デコーダＤａ２と、システムデータに関するバッファであるＴＢｓｙｓおよびＢｓｙｓと、デコーダＤｓｙｓとを有する。
【０２６１】
画像データは、ＴＢ、ＭＢ、ＥＢ、およびデコーダＤｖの順に処理される。音データのＢａｓｅは、ＴＢａ１、Ｂａ１、およびデコーダＤａ１の順に処理される。音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」は、ＴＢａ２、Ｂａ２、およびデコーダＤａ２の順に処理される。システムデータは、ＴＢｓｙｓ、Ｂｓｙｓ、およびデコーダＤｓｙｓの順に処理される。
【０２６２】
音データのＢａｓｅがデコードされるラインと、音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」がデコードされるラインとでは、夫々のストリームの属性に応じてバッファ間のデータの転送レートや、バッファのサイズなどデコーダの仕様が異なる。従って、両方の仕様に対応するように、ＢａｓｅとＬｅｖｅｌ２とを多重化しなければならない。Ｂａｓｅのみをデコードする場合、そのデコーダライン（ＴＢａ１、Ｂａ１、およびデコーダＤａ１）で、バッファを破綻させずにＢａｓｅのみをデコードすることができなければならない。「Ｂａｓｅ＋Ｌｅｖｅｌ２」をデコードする場合、そのデコーダライン（ＴＢａ２、Ｂａ２、およびデコーダＤａ２）で、バッファを破綻させずに「Ｂａｓｅ＋Ｌｅｖｅｌ２」をデコードすることができなければならない。つまり、Ｂａｓｅのデコーダライン（ＴＢａ１、Ｂａ１、およびデコーダＤａ１）でも、「Ｂａｓｅ＋Ｌｅｖｅｌ２」のデコーダライン（ＴＢａ２、Ｂａ２、およびデコーダＤａ２）でも、バッファを破綻させないように、ＢａｓｅとＬｅｖｅｌ２とを１本のストリームとして同一ＰＩＤにて多重化しなければならない。
【０２６３】
図４６を用いて、Ｂａｓｅと、「Ｂａｓｅ＋Ｌｅｖｅｌ２」とをそれぞれのデコーダラインでデコードする際の、ＴＢａ１およびＴＢａ２のデータ蓄積量の推移を説明する。
【０２６４】
ＴＢａ１については、ｎ番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ）のＢａｓｅ（Ｂａｓｅ＃ｎ）が、時刻ＡＴＳ＿ｂ＃ｎからビットレート（ＲTS）で入力して蓄積されると同時にＲｂａ１のレートでＢａ１へと引き抜かれる。Ｂａｓｅ＃ｎの入力が終了すると、蓄積データ量は一定のビットレート（−Ｒｂａ１）で減少する。（ｎ＋１）番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ＋１）のＢａｓｅ（Ｂａｓｅ＃ｎ＋１）が、時刻ＡＴＳ＿ｂ＃ｎ＋１からビットレート（ＲTS）で入力して蓄積する。図４６では、Ｂａｓｅ＃ｎ＋１の入力が終了するまでに、ＴＢａ１はオーバーフローする。つまり、バッファは破綻する。以降同様の処理が続く。
【０２６５】
ＴＢａ２については、ｎ番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ）のＢａｓｅ（Ｂａｓｅ＃ｎ）が、時刻ＡＴＳ＿ｂ＃ｎからビットレート（ＲTS）で入力して蓄積されると同時にＲｂａ１のレートでＢａ２へと引き抜かれる。Ｂａｓｅ＃ｎの入力が終了すると、蓄積データ量は一定のビットレート（−Ｒｂａ２）で減少する。そして、ｎ番目のアクセスユニットの２個のＬｅｖｅｌ２（Ｌｅｖｅｌ２＃ｎ）が、入力され蓄積する。入力が無い期間のＴＢａ２の蓄積データ量はビットレート（−Ｒｂａ２）で減少する。以降同様の処理が続く。図４６では、ＴＢａ２はオーバーフローしない。つまり、バッファは破綻しない。
【０２６６】
図４６の場合、Ｂａｓｅ＃ｎのみに対応するデコーダラインは、１個のアクセスユニットが１つのＰＥＳパケットに格納されるＢａｓｅと、Ｌｅｖｅｌ１とから構成されているストリームしかデコードすることができず、Ｌｅｖｅｌ２を含むような高ビットレートのストリームは処理できない。このように低ビットレートしか対応できないＴＢａ１を破綻させないためには、ＴＢａ１へのＢａｓｅ＃ｎ＋１の入力時刻を遅らせる必要がある。つまり、下記の式３が満たされなければならない。
【０２６７】
ＴＢａ１（ＡＴＳ＿ｂ＃ｎ＋１）＋１８８×（１−Ｒｂａ１／ＲTS）
≦ＴＢａ１のサイズ＝５１２ （式３）
【０２６８】
式３は、時刻ＡＴＳ＿ｂ＃ｎ＋１におけるＴＢａ１のデータ蓄積量に、１つのＴＳパケットを入力する際に増加するバイト量（１８８×（１−Ｒｂａ１／ＲTS））が加算されても、ＴＢａ１のサイズを超えないことを意味する。式３を満たす時刻ＡＴＳ＿ｂ＃ｎ＋１以降に、Ｂａｓｅ＃ｎ＋１を多重化するように、ＡＴＳを設定し、ストリームにＢａｓｅ＃ｎ＋１を多重化しなければならない。
【０２６９】
さらに、Ｂａｓｅ（１つ目のＰＥＳパケット）が格納されるＴＳパケットの数をＮｂａｓとし、Ｌｅｖｅｌ２（２つ目のＰＥＳパケット）が格納されるＴＳパケットの数をＮｅｘｔとすると、ＢａｓｅとＬｅｖｅｌ２とをデコード順に転送するためには、下記の式４が満たされなければならない。
【０２７０】
[（Ｎｂａｓ＋Ｎｅｘｔ）×１８８×８／ＲTS]×２７００００００
≦ ＡＴＳ＿ｂ＃（ｎ＋１）− ＡＴＳ＿ｂ＃ｎ （式４）
【０２７１】
ここで、ビットレートＲｂａ１，ＲTSの単位は、ｂｉｔｓ／ｓｅｃｏｎｄであり、２７００００００はＡＴＳの時刻精度のクロック周波数を意味する。Ｎｂａｓ，Ｎｅｘｔの値は、夫々のＣｏｄｅｃの最大ビットレートなどの情報から算出することができる。
【０２７２】
例えば、ＤＴＳ＋＋の場合、サンプリング周波数が４８ＫＨｚで、５１２サンプル／Ａｃｃｅｓｓ Ｕｎｉｔ（ＤＴＳ＿ｔｙｐｅ１）でＣｏｒｅ（Ｂａｓｅ）が１Ｍｂｐｓの固定レート、ＸＬＬ（Ｌｅｖｅｌ２）が単独で２４Ｍｂｐｓであるとすると、ＸＬＬのデータ長＝２４Ｍｂｐｓ×５１２／４８Ｋ＝３２０００ｂｙｔｅｓとなる。これを格納するには、ＴＳ／ＰＥＳヘッダのオーバーヘッドも含めて、１７４個のＴＳパケットが必要となる。
【０２７３】
上記の式３および４が満たされるように、多重化処理は行われなければならず、ＢａｓｅおよびＬｅｖｅｌ２を含むＴＳパケットに適切なＡＴＳを付加し、多重化する。これにより、バッファは破綻しない。
【０２７４】
なお、バッファは、データがオーバーフローする場合だけでなく、アンダーフローする場合にも破綻する。データがアンダーフローしないように、ＢａｓｅとＬｅｖｅｌ２とを多重化しなければならない。そのため、データがオーバーフローすることを防止する場合と同様に、バッファのサイズ、バッファへ入力するデータのサイズ、バッファへ入力するデータの速度、および、バッファから出力するデータの速度に基づいて、データがアンダーフローしないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する。
【０２７５】
要するに、各デコーダモデルにおいて、バッファのサイズ、バッファへ入力するデータのサイズ、バッファへ入力するデータの速度、および、バッファから出力するデータの速度を考慮して、各デコーダモデルが破綻しないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する。
【産業上の利用可能性】
【０２７６】
本発明の情報記録媒体は、映像や音声のデータが記録される光ディスク等として有用である。本発明のデータ分別装置は、光ディスク等の本発明の情報記録媒体に記録されているデータから、既存のデコーダまたは、既存のディジタルＩ／Ｆに対応する基礎圧縮データを抜き出す装置等として有用である。本発明のデータ再生装置は、光ディスク等の本発明の情報記録媒体から上記基礎圧縮データを抜き出して再生する装置等として有用である。本発明のデータ再生装置は、光ディスク等の本発明の情報記録媒体からのデータに限らず、放送やネットワークを通して供給されるオーディオデータや、ハードディスクや半導体メモリなどの記録メディア上のオーディオデータを再生する再生装置などにも有用である。
【符号の説明】
【０２７７】
２０１ ＢＤディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０１ プログラム記録メモリ
３０２ プログラムプロセッサ
３０３ ＵＯＰマネージャ
３０４ 管理情報記録メモリ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１４ イメージプレーン
３１５ ビデオプレーン
３１６ 合成処理部
３１７ ドライブコントローラ
【技術分野】
【０００１】
本発明は、映像や音声のデータが記録される情報記録媒体、及びデータを再生するデータ再生装置等に関する。
【背景技術】
【０００２】
従来のＤＶＤ−Ｖｉｄｅｏディスク（以下、「ＤＶＤ」という）について説明する。
【０００３】
図１は、ＤＶＤの構造を示す図である。図１の下段に示すように、ＤＶＤには、リード・イン部からリード・アウト部までの間に論理アドレス空間が設けられている。論理アドレス空間には、先頭にファイルシステムのボリューム情報が記録され、続いて映像や音声などのアプリケーションデータが記録される。
【０００４】
ＤＶＤのファイルシステムは、ＩＳＯ９６６０やUniversal Disc Format（ＵＤＦ）の
ファイルシステムである。ファイルシステムは、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現するための仕組みである。パーソナルコンピュータ（ＰＣ）では、ＦＡＴまたはＮＴＦＳと呼ばれるファイルシステムが用いられている。そのファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータは、コンピュータにより処理される。これにより、ユーザビリティが高くなっている。
【０００５】
ＤＶＤでは、ＵＤＦおよびＩＳＯ９６６０の両方のファイルシステムが使用されている。ＵＤＦおよびＩＳＯ９６６０の両方を合わせて「ＵＤＦブリッジ」と呼ぶことがある。ＤＶＤに記録されているデータは、ＵＤＦおよびＩＳＯ９６６０のどちらのファイルシステムドライバによっても読み出すことができる。勿論、書き換え可能型のＤＶＤであるＤＶＤ−ＲＡＭ／Ｒ／ＲＷでは、これらのファイルシステムを介して、物理的にデータの読み、書き、および削除が可能である。
【０００６】
ＤＶＤに記録されたデータは、ファイルシステムを介して、図１左上に示すようなディレクトリまたはファイルとして存在する。ルートディレクトリ（図１における「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルに分割されて記録されている。主なファイルとして以下のものがある。
【０００７】
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ ビデオタイトルセット＃１ストリームファイル
．．．．．
【０００８】
２つの拡張子が規定されている。「ＩＦＯ」は、それが付与されているファイルが再生制御情報が記録されたファイルであることを示す拡張子である。「ＶＯＢ」は、それが付与されているファイルがＡＶデータであるＭＰＥＧストリームが記録されたファイルであることを示す拡張子である。再生制御情報は、ＤＶＤについて採用されたインタラクティビティ（ユーザの操作に応じて再生状態を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などを含む情報である。ＤＶＤでは一般的に、再生制御情報はナビゲーション情報と呼ばれる。
【０００９】
再生制御情報ファイルとして、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセットの再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」とが存在する。ファイル名のボディにある「０１」はビデオタイトルセットの番号を示している。例えば、ビデオタイトルセットの番号が＃２であれば、そのビデオタイトルセットのファイル名は「ＶＴＳ＿０２＿０．ＩＦＯ」である。なおＤＶＤでは、複数のタイトル、言い換えれば内容が異なる複数の映画や、内容が同一でバージョンが異なる複数の映画を１枚のディスクに記録することが可能である。
【００１０】
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間、即ち前述した再生制御情報が展開された論理構造空間を示している。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、Video Manager Information（ＶＭＧＩ）として、ＤＶＤナビゲーショ
ン空間に展開される。「ＶＴＳ＿０１＿０．ＩＦＯ」等のビデオタイトルセット毎に存在する再生制御情報は、Video Title Set Information（ＶＴＳＩ）としてＤＶＤナビゲー
ション空間に展開される。
【００１１】
ＶＴＳＩには、Program Chain（ＰＧＣ）と呼ばれる再生シーケンスの情報であるProgram Chain Information（ＰＧＣＩ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合と、コマンドと呼ばれる一種のプログラミング情報とによって構成されている。Ｃｅｌｌは、Video Object（ＶＯＢ，ＭＰＥＧストリーム）の一部区間の集合、または全部区間である。Ｃｅｌｌの再生は、ＶＯＢの、Ｃｅｌｌによって指定された区間を再生することを意味している。
【００１２】
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、ブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。Ｊａｖａ（登録商標）スクリプトは、論理演算の他に、ウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドを開く）を行う。それに対して、ＤＶＤのコマンドは、論理演算の他には、ＡＶタイトルの再生制御（例えば、再生するチャプタの指定など）のみを行う。このように、ＤＶＤのコマンドは、Ｊａｖａ（登録商標）スクリプトと異なっている。
【００１３】
Ｃｅｌｌは、ディスク上に記録されているＶＯＢの開始アドレスおよび終了アドレス（ディスク上での論理記録アドレス）の情報を有している。プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始アドレスおよび終了アドレスの情報を使って、データを読み出して再生する。
【００１４】
図２は、ＡＶストリーム中に埋め込まれているナビゲーション情報を説明するための図である。ＤＶＤにおいて特徴的なインタラクティビティは、前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されるのではない。インタラクティビティを実現するための幾つかの重要な情報は、ナビゲーション パック（「ナビパック」または「ＮＶ＿ＰＣＫ」という）と呼ばれる専用キャリアが用いられて、ＶＯＢ内に映像データおよび音声データと一緒に多重化されている。
【００１５】
ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には幾つかのボタンが現れる。夫々のボタンには、そのボタンが選択され押下されたときの処理の内容が定義されている。メニュー上では一つのボタンが選択される。ハイライトは、選択されているボタン上にオーバーレイされる半透明色の画像であって、それがオーバーレイされているボタンが選択されていることをユーザに示す。ユーザは、リモコンの上下左右キーを使って、選択されているボタンをそのボタンの上下左右の何れかのボタンに移動させることができる。ユーザは、リモコンの上下左右キーを使って、実行させたい処理に対応するボタンまでハイライトを移動させて、決定キーを押す。これによって、選択されたボタンに対応するコマンドのプログラムが実行される。例えば、タイトルやチャプタの再生がコマンドによって実行される（例えば、特許文献１参照）。
【００１６】
図２の左上部は、ＮＶ＿ＰＣＫ内に格納される制御情報の概要を示している。
【００１７】
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報や個々のボタン情報などが含まれている。ハイライトカラー情報内には、カラーパレット情報が記述される。カラーパレット情報はオーバーレイするハイライトの半透明色を指定する。ボタン情報内には、個々のボタンの位置情報である矩形領域情報と、あるボタンから他のボタンへの移動情報（ユーザによるリモコンの上下左右キーの選択に対応する移動先ボタンの指定）と、ボタンコマンド情報（そのボタンが選択されたときに実行されるコマンド）とが記述されている。
【００１８】
メニュー上のハイライトは、図２の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報内の矩形領域情報によって特定されるボタンの上にカラーパレット情報によって特定される色をつけた画像である。オーバーレイ画像は、図２の右部に示す背景画像と合成されて画面上に表示される。
【００１９】
上述したようにして、ＤＶＤではメニューが表示される。ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいる理由は、ストリームと同期して動的にメニュー情報を更新することを可能とするためである。例えば、映画が再生されている途中の５分〜１０分の間だけメニューが表示されることを可能とするためである。二つ目の理由は、ストリームとメニュー情報とを同期させることが困難なアプリケーションデータであっても、ストリームとメニュー情報とを同期させて表示することを可能とするためである。もう一つの大きな理由は、ユーザの操作性を向上させるためである。例えば、ＮＶ＿ＰＣＫに特殊再生を支援するための情報を格納することにより、ＤＶＤに記録されているＡＶデータを早送りや巻き戻しなどの非通常再生する際にも、円滑にそのＡＶデータをデコードし再生することが可能となる。
【００２０】
図３は、ＤＶＤのストリームであるＶＯＢのイメージを示す図である。図３（Ａ）に示す映像、音声、および字幕などのデータは、図３（Ｂ）に示すように、ＭＰＥＧシステム規格（ＩＳＯ／ＩＥＣ１３８１８−１）に基づいてパケット化およびパック化され、図３（Ｃ）に示すように、夫々は多重化されて、１本のＭＰＥＧプログラムストリームが生成される。インタラクティビティを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも、パケットおよびパックと一緒に多重化される。
【００２１】
ＭＰＥＧシステムにおけるデータの多重化の特徴は、多重化される個々のデータはデコード順に基づくビット列になっているが、多重化されるデータ相互については、即ち、映像データ、音声データ、および字幕データ相互については、必ずしも再生順、言い換えればデコード順に配列されているわけではない。これは、ＭＰＥＧシステムストリームのデコーダモデル（一般に、「System Target Decoder」または「ＳＴＤ」と呼ばれる（図３
（Ｄ）参照））が、多重化されているデータを解いた後の個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまで一時的にデータを蓄積していることに由来している。ＤＶＤ−Ｖｉｄｅｏで規定されるデコーダバッファのサイズは、エレメンタリーストリーム毎に異なる。映像に対するバッファのサイズは２３２ＫＢであり、音声に対するバッファのサイズは４ＫＢであり、字幕に対するバッファのサイズは５２ＫＢである。
【００２２】
即ち、映像データと並んで多重化されている字幕データは、必ずしも映像データと同一タイミングでデコードまたは再生されるわけではない。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開平９−２８２８４８号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
従来からＤＶＤで採用されている音声コーデック規格として、「ドルビーディジタル（ＡＣ−３）」と、「ＭＰＥＧオーディオ」と、「ＬＰＣＭ」と、「ｄｔｓ」との４つの規格がある。「ｄｔｓ」はプレーヤオプション機能であり、ＤＶＤプレーヤには、ｄｔｓデコーダを内蔵するものと、内蔵しないものとがある。また、ＤＶＤプレーヤには、ＡＶアンプへのディジタルデータの出力機能として、ｄｔｓ対応機能を有しているものと、有していないものとがある。
【００２５】
ｄｔｓディジタルデータ出力機能を有しているＤＶＤプレーヤは、Sony/Philips Digital Interconnect Format（ＳＰＤＩＦ、民生向けはＩＥＣ６０９５８−３規格で規定）と呼ばれるディジタルＩ／Ｆ規格に準拠したデータを、その規格に準拠したＡＶアンプに出力する。
【００２６】
しかしながら、ＳＰＤＩＦは、規格上１．５Ｍｂｐｓの帯域までしか対応することができず、「ｄｔｓ」の拡張コーデック規格である、２０Ｍｂｐｓ近い帯域を必要とする「ｄｔｓ＋＋（ロスレス圧縮）」に対応していない。したがって、次世代ＨＤ ＤＶＤ規格（ＢＤ規格）が「ｄｔｓ＋＋」に対応しても、ＳＰＤＩＦ規格に準拠したＡＶアンプに、ｄｔｓ＋＋ストリームを出力することはできない。
【００２７】
本発明は、上述した課題を考慮し、基本データのみを復号するデコーダが、基本データと次世代に対応する拡張データとを含むアクセスユニットを処理することができるように、基本データと拡張データとを含むアクセスユニットが記録される情報記録媒体を提供することを目的とする。また、本発明は、本発明の情報記録媒体のアクセスユニットを処理するデータ再生装置を提供することを目的とする。
【課題を解決するための手段】
【００２８】
上記課題を解決し上記目的を達成するために、本発明の情報記録媒体は、複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、１個の前記アクセスユニットは、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、前記基本データは、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データは、前記基本データから生成されるデータの質を向上させるためのデータであり、前記ストリームは、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する。
【００２９】
例えば、前記情報は、前記ストリームのｄｅｓｃｒｉｐｔｏｒに記述されている。
【００３０】
例えば、前記アクセスユニットは、音に関するデータであって、前記属性は、チャンネル、周波数、ビットレート、及び、２チャンネルのダウンミックスデータの存在の有無、の少なくとも一つを特定する。
【００３１】
例えば、各前記アクセスユニットは一定時間のデータである。
【００３２】
本発明のデータ再生装置は、本発明の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得する取得手段と、前記情報を用いて、前記アクセスユニットを再生する再生手段とを備える。
【００３３】
本発明は、本発明のデータ再生装置の特徴的な構成手段をステップとするデータ再生方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現することもできる。そのプログラムは、ＣＤ−ＲＯＭ等の記録媒体や通信ネットワーク等の伝送媒体を介して流通させることもできる。
【発明の効果】
【００３４】
本発明は、基本データのみを復号するデコーダが、基本データと次世代に対応する拡張データとを含むアクセスユニットを処理することができるように、基本データと拡張データとを含むアクセスユニットが記録される情報記録媒体を提供することができる。また、本発明は、本発明の情報記録媒体のアクセスユニットを処理するデータ再生装置を提供することができる。
【００３５】
すなわち、本発明により、既存のディジタルＩ／Ｆが持つ帯域を越える新しい音声コーデックを使った音声データが記録媒体に記録されている場合であっても、既存のディジタルＩ／Ｆに対して従来通りの音声データの抽出および出力が可能になる効果が得られる。
【図面の簡単な説明】
【００３６】
【図１】図１は、ＤＶＤの構造を示す図である。
【図２】図２は、ナビゲーション情報を説明するための図である。
【図３】図３（Ａ）は、映像、音声、および字幕などのデータを示す図である。図３（Ｂ）は、各データをパケット化およびパック化することを示す図である。図３（Ｃ）は、パケット化およびパック化されたデータを示す図である。図３（Ｄ）は、ＭＰＥＧシステムストリームのデコーダモデルを示す図である。
【図４】図４は、次世代ＤＶＤの構成を示す図である。
【図５】図５は、ＢＤディスクに記録されている論理データのディレクトリおよびファイルの構成を示す図である。
【図６】図６は、プレーヤの機能を示すブロック図である。
【図７】図７は、プレーヤの構成を詳細化したブロック図である。
【図８】図８は、ＢＤのアプリケーション空間を示す図である。
【図９】図９は、ＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【図１０】図１０は、パックの構成を示す図である。
【図１１】図１１は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を説明するための図である。
【図１２】図１２は、ＶＯＢデータ連続供給モデルを説明するための図である。
【図１３】図１３は、ＶＯＢ管理情報ファイルの内部構造を示す図である。
【図１４】図１４は、ＶＯＢＵ情報の詳細を説明するための図である。
【図１５】図１５は、タイムマップの詳細に説明するための図である。
【図１６】図１６は、プレイリスト情報の内部構造を示す図である。
【図１７】図１７は、イベントハンドラテーブルを示す図である。
【図１８】図１８は、ＢＤディスク全体に関する情報の内部構造を示す図である。
【図１９】図１９は、グローバルイベントハンドラのプログラムのテーブルを示す図である。
【図２０】図２０は、タイムイベントの例を示す図である。
【図２１】図２１は、ユーザイベントの例を示す図である。
【図２２】図２２は、グローバルイベントの例を示す図である。
【図２３】図２３は、プログラムプロセッサの機能を説明するための図である。
【図２４】図２４は、システムパラメータの一覧を示す図である。
【図２５】図２５は、２つの選択ボタンを持つメニューのプログラムの例を示す図である。
【図２６】図２６は、ユーザイベントのイベントハンドラの例を示す図である。
【図２７】図２７は、ＡＶの再生までの基本処理フローを示す図である。
【図２８】図２８は、ＰＬの再生開始からＶＯＢの再生開始までの処理フローを示す図である。
【図２９】図２９は、ＡＶの再生開始後からのイベント処理フローを示す図である。
【図３０】図３０は、字幕処理のフローを示す図である。
【図３１】図３１は、階層構造を持たないアクセスユニットの構造を示す図である。
【図３２】図３２は、２つの階層構造を持つアクセスユニットの構造を示す図である。
【図３３】図３３は、３つの階層構造を持つアクセスユニットの構造を示す図である。
【図３４】図３４は、階層構造を持つデータを、様々な階層に対応したデコーダに出力するストリーム読込／供給部の、データの出力先毎に異なる動作を説明するための図である。
【図３５】図３５は、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及した場合に、Ｌｅｖｅｌ２−ＥＸＴを導入するための理想的なアクセスユニットの構造を示す図である。
【図３６】図３６は、Ｌｅｖｅｌ２を含むデータストリームのデータ構造を示す図である。
【図３７】図３７は、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されているアクセスユニットの処理を説明するための図である。
【図３８】図３８は、ＭＰＥＧ２−ＴＳへの階層構造を持つアクセスユニットの格納方法を示す図である。
【図３９】図３９は、ｄｅｓｃｒｉｐｔｏｒに記述される事項の一例を示す図である。
【図４０】図４０（Ａ）は、５．１チャンネルのスピーカレイアウトを示す図であり、図４０（Ｂ）は、７．１チャンネルのスピーカレイアウトを示す図である。
【図４１】図４１は、チャンネル構造を示す図である。
【図４２】図４２は、光ディスクに記録する際のＭＰＥＧ２−ＴＳのファイルフォーマットを示す図である。
【図４３】図４３は、ＤＶＤ−Ｖｉｄｅｏで規定されるＤＴＳの詳細を説明するための図である。
【図４４】図４４は、デマルチプレクサ、および、ストリーム読込／供給部の処理を示すフローチャートである。
【図４５】図４５は、入力時刻管理装置２０００およびデコーダモデル３０００の構成図である。
【図４６】図４６は、Ｂａｓｅを復号するデコーダモデルを破綻させないようにするとともに、かつ、ＢａｓｅおよびＬｅｖｅｌ２を復号するデコーダモデルを破綻させないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する方法を説明するための図である。
【発明を実施するための形態】
【００３７】
以下に、本発明を実施するための最良の形態を図面を参照して説明する。
【００３８】
（関連する実施の形態）
（ディスク上の論理データ構造）
図４は、次世代ＤＶＤ（以下、「ＢＤ」という）の構成、特にディスク媒体であるＢＤディスク１０４並びに、ディスク１０４に記録されているデータ１０１，１０２，および１０３の構成を示す図である。ＢＤディスク１０４には、ＡＶデータ１０３と、ＡＶデータの管理情報およびＡＶ再生シーケンスなどを含むＢＤ管理情報１０２と、インタラクティビティを実現するためのＢＤ再生プログラム１０１とが記録される。本実施の形態では、説明の都合上、映画のＡＶコンテンツを再生するためのＡＶアプリケーションデータがＢＤディスク１０４に記録されていると仮定する。しかしながら、ＢＤディスク１０４は、他の用途として用いられてもよい。
【００３９】
図５は、ＢＤディスクに記録されている論理データのディレクトリおよびファイルの構成を示す図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様に、内周から外周に向けてらせん状に記録領域を持ち、内周のリード・イン部と外周のリード・アウト部との間に論理データを記録するための論理アドレス空間を有している。ＢＤディスクには、リード・イン部の内側に、Burst Cutting Area（ＢＣＡ）と呼ばれるドライブでしかデータを読み出すことができない特別な領域が存在する。この領域のデータは、アプリケーションデータを利用しても読み出すことができない。そのため、上記領域は、例えば著作権保護技術のためなどに利用されることがある。
【００４０】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に、映像データなどのアプリケーションデータが記録されている。ファイルシステムは、「背景技術」で説明した通り、ＵＤＦやＩＳＯ９６６０などのファイルシステムであり、通常のＰＣと同じように、記録されている論理データをディレクトリおよびファイルの構造を使って読み出すためのシステムである。
【００４１】
本実施の形態におけるＢＤディスク上のディレクトリおよびファイルの構造では、ルートディレクトリ（ＲＯＯＴ）の直下に、ＢＤＶＩＤＥＯディレクトリが置かれている。ＢＤＶＩＤＥＯディレクトリは、ＢＤに記録されるＡＶコンテンツや管理情報などのデータ（図４のデータ１０１，１０２，および１０３）が格納されているディレクトリである。
【００４２】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００４３】
ＢＤ．ＩＮＦＯファイル（ファイル名固定）
「ＢＤ．ＩＮＦＯ」ファイルは、「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報が記録されたファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００４４】
ＢＤ．ＰＲＯＧファイル（ファイル名固定）
「ＢＤ．ＰＲＯＧ」ファイルは、「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関する再生制御情報が記録されたファイルである。
【００４５】
ＸＸＸ．ＰＬファイル（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＸＸＸ．ＰＬ」ファイルは、「ＢＤ管理情報」の一つであり、シナリオ（再生シーケンス）であるプレイリスト情報が記録されたファイルである。プレイリスト毎に一つのファイルが存在する。
【００４６】
ＸＸＸ．ＰＲＯＧファイル（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＸＸＸ．ＰＲＯＧ」ファイルは、「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報が記録されたファイルである。「ＸＸＸ．ＰＲＯＧ」ファイルに対応するプレイリストは、ファイルボディ名（「ＸＸＸ」）が一致するプレイリストである。
【００４７】
ＹＹＹ．ＶＯＢファイル（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＹＹＹ．ＶＯＢ」ファイルは、「ＡＶデータ」の一つであり、ＶＯＢ（「背景技術」で説明したＶＯＢと同じ）が記録されたファイルである。ＶＯＢ毎に一つのファイルが存在する。
【００４８】
ＹＹＹ．ＶＯＢＩファイル（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＹＹＹ．ＶＯＢＩ」ファイルは、「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関するストリーム管理情報が記録されたファイルである。「ＹＹＹ．ＶＯＢＩ」ファイルに対応するＶＯＢは、ファイルボディ名（「ＹＹＹ」）が一致するＶＯＢである。
【００４９】
ＺＺＺ．ＰＮＧファイル（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＺＺＺ．ＰＮＧ」ファイルは、「ＡＶデータ」の一つであり、字幕およびメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）が記録されたファイルである。ＰＮＧイメージ毎に一つのファイルが存在する。
【００５０】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤについて、図６および図７を用いて説明する。
【００５１】
図６は、プレーヤの大まかな機能を示すブロック図である。
【００５２】
ＢＤディスク２０１上のデータは、光ピックアップ２０２を通して読み出される。読み出されたデータは、そのデータの種類に応じて専用のメモリに転送される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」ファイルまたは「ＸＸＸ．ＰＲＯＧ」ファイル）はプログラム記録メモリ２０３に転送される。ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」ファイル、「ＸＸＸ．ＰＬ」ファイル、または「ＹＹＹ．ＶＯＢＩ」ファイル）は管理情報記録メモリ２０４に転送される。ＡＶデータ（「ＹＹＹ．ＶＯＢ」ファイルまたは「ＺＺＺ．ＰＮＧ」ファイル）はＡＶ記録メモリ２０５に転送される。
【００５３】
プログラム記録メモリ２０３に記録されたＢＤ再生プログラムはプログラム処理部２０６によって処理される。管理情報記録メモリ２０４に記録されたＢＤ管理情報は管理情報処理部２０７によって処理される。ＡＶ記録メモリ２０５に記録されたＡＶデータはプレゼンテーション処理部２０８によって処理される。
【００５４】
プログラム処理部２０６は、管理情報処理部２０７より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取り、プログラムを実行する。プログラムは再生するプレイリストを動的に変えることが可能である。プログラム処理部２０６が管理情報処理部２０７に対してプレイリストの再生命令を送ることで、再生するプレイリストが動的に変わることが実現する。プログラム処理部２０６は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、そのイベント（リクエスト）に対応するプログラムがある場合、それを実行する。
【００５５】
管理情報処理部２０７は、プログラム処理部２０６からの指示を受け、対応するプレイリストおよびプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部２０８に、対象となるＡＶデータの再生を指示する。また、管理情報処理部２０７は、プレゼンテーション処理部２０８より基準時刻情報を受け取り、基準時刻情報に基づいてプレゼンテーション処理部２０８にＡＶデータの再生の停止を指示し、また、プログラム処理部２０６に対して指示するための、プログラムの実行タイミングを示すイベントを生成する。
【００５６】
プレゼンテーション処理部２０８は、映像、音声、および字幕／イメージ（静止画）の夫々に対応するデコーダを持ち、管理情報処理部２０７からの指示に従い、ＡＶデータのデコードおよび出力を行う。映像データ、および字幕／イメージは、デコードされた後に夫々の専用プレーン、ビデオプレーン２１０またはイメージプレーン２０９に描画される。ビデオプレーン２１０およびイメージプレーン２０９に描画された各映像は、合成処理部２１１によって合成され、ＴＶなどの表示デバイスへ出力される。
【００５７】
図６を用いて説明したように、ＢＤプレーヤは図４で示したＢＤディスクに記録されているデータの構成に対応する構成部を有している。
【００５８】
図７は前述したプレーヤの構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ２０５は、イメージメモリ３０８およびトラックバッファ３０９として表現されている。プログラム処理部２０６は、プログラムプロセッサ３０２およびＵＯＰマネージャ３０３として表現されている。管理情報処理部２０７は、シナリオプロセッサ３０５およびプレゼンテーションコントローラ３０６として表現されている。プレゼンテーション処理部２０８は、クロック３０７、デマルチプレクサ３１０、イメージプロセッサ３１１、ビデオプロセッサ３１２、およびサウンドプロセッサ３１３として表現されている。
【００５９】
ＢＤディスク２０１から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ３０９に記録され、イメージデータ（ＰＮＧ）はイメージメモリ３０８に記録される。デマルチプレクサ３１０は、クロック３０７の時刻に基づき、トラックバッファ３０９に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ３１２に送り、音声データをサウンドプロセッサ３１３に送る。ビデオプロセッサ３１２およびサウンドプロセッサ３１３はそれぞれ、ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダとで構成されている。即ち、デマルチプレクサ３１０から送りこまれる映像および音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック３０７の時刻に従い対応するデコーダでデコードされる。
【００６０】
イメージメモリ３０８に記録されたＰＮＧは、次の２つの処理方法によって処理される。
【００６１】
イメージデータが字幕用のデータである場合、プレゼンテーションコントローラ３０６によってデコードタイミングが指示される。シナリオプロセッサ３０５は、クロック３０７からの時刻情報を受け、適切に字幕を表示することができるように、字幕の表示開始時刻になると、プレゼンテーションコントローラ３０６に対して字幕の表示を指示する。同様に、シナリオプロセッサ３０５は、クロック３０７からの時刻情報に基づいて、字幕の表示終了時刻になると、プレゼンテーションコントローラ３０６に対して字幕の表示の停止を指示する。プレゼンテーションコントローラ３０６からデコード／表示の指示を受けたイメージプロセッサ３１１は、対応するＰＮＧデータをイメージメモリ３０８から抜き出してデコードし、イメージプレーン３１４に描画する。
【００６２】
次に、イメージデータがメニュー用のデータである場合を説明する。その場合、プログラムプロセッサ３０２によってデコードタイミングが指示される。プログラムプロセッサ３０２がイメージのデコードを指示するタイミングは、プログラムプロセッサ３０２が処理しているＢＤプログラムに依存し、一概には決まらない。
【００６３】
イメージデータおよび映像データは、図６を用いて説明したように、夫々デコードされた後に、イメージプレーン３１４またはビデオプレーン３１５に描画され、合成処理部３１６によって合成された後、出力される。
【００６４】
ＢＤディスク２０１から読み出された管理情報（シナリオ情報およびＡＶ管理情報）は、管理情報記録メモリ３０４に格納される。その後、シナリオ情報（「ＢＤ．ＩＮＦＯ」ファイルおよび「ＸＸＸ．ＰＬ」ファイル）はシナリオプロセッサ３０５によって読み出される。ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」ファイル）はプレゼンテーションコントローラ３０６によって読み出される。
【００６５】
シナリオプロセッサ３０５は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置とをプレゼンテーションコントローラ３０６に知らせる。プレゼンテーションコントローラ３０６は、対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」ファイル）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ３１７に指示を出す。
【００６６】
ドライブコントローラ３１７は、プレゼンテーションコントローラ３０６からの指示に従い、光ピックアップを移動させ、対象となるＡＶデータを読み出す。読み出されたＡＶデータは、前述したようにイメージメモリ３０８またはトラックバッファ３０９に格納される。
【００６７】
シナリオプロセッサ３０５は、クロック３０７の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ３０２に出力する。
【００６８】
プログラム記録メモリ３０１に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」ファイルまたは「ＸＸＸ．ＰＲＯＧ」ファイル）は、プログラムプロセッサ３０２によって処理される。プログラムプロセッサ３０２は、シナリオプロセッサ３０５からイベントが送られてきた場合か、ＵＯＰマネージャ３０３からイベントが送られてきた場合、ＢＤプログラムを処理する。ＵＯＰマネージャ３０３は、ユーザからリモコンキーによってリクエストが送られてきた場合、プログラムプロセッサ３０２に対するイベントを生成する。
【００６９】
（アプリケーション空間）
図８は、ＢＤのアプリケーション空間を示す図である。
【００７０】
ＢＤのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位である。プレイリストは、セル（Ｃｅｌｌ）の連結であって、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。プログラムによる動的なシナリオの変化が無い限り、プレイリストは個々のセルを順に再生させる。全てのセルの再生を終了した時点で、プレイリストの再生は終了する。プログラムには、セルの再生順序を変化させる内容を記述することが可能である。また、プログラムは、ユーザの選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例として、メニューが挙げられる。ＢＤでは、メニューはユーザの選択によって再生するシナリオであると定義することができ、プログラムによってプレイリストを動的に変化させることができる。
【００７１】
ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラである。
【００７２】
時間イベントは、プレイリストに埋め込まれた時刻情報に基づいて生成されるイベントである。図７を用いて説明したシナリオプロセッサ３０５からプログラムプロセッサ３０２に送られるイベントが、時間イベントの一例である。時間イベントが発行されると、プログラムプロセッサ３０２は識別子（ＩＤ）によって対応付けられるイベントハンドラを実行する。前述した通り、実行されるプログラムは他のプレイリストの再生を指示することが可能である。例えば、プログラムは、現在再生されているプレイリストの再生を中止し、指定されたプレイリストを再生させる。
【００７３】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。
【００７４】
一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）。リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された場合、有効なイベントハンドラが検索され、有効なイベントハンドラがある場合、そのイベントハンドラが実行される。有効なイベントハンドラがない場合、メニュー選択のイベントは無視される。
【００７５】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声または字幕を呼び出し、音声または字幕を変更後に中断した地点からタイトルを再生する機能等）を実装することができる。
【００７６】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）は、ＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を示す。セルは、ＶＯＢ内の再生区間を、開始時刻および終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、データの再生時刻に対応した記録アドレスのテーブル情報であるタイムマップ（Time MapまたはＴＭ）を有している。タイムマップを用いることによって、前述したＶＯＢの再生時刻および終了時刻から、ＶＯＢ内（即ち対象となる「ＹＹＹ．ＶＯＢ」ファイル内）での読み出しの開始アドレスおよび終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００７７】
（ＶＯＢの詳細）
図９は、本実施の形態におけるＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【００７８】
図９に示すように、ＶＯＢは複数のVideo Object Unit（ＶＯＢＵ）によって構成され
ている。ＶＯＢＵは、ＭＰＥＧビデオストリームにおけるGroup Of Pictures（ＧＯＰ）
を基準として、音声データも含んだ多重化ストリームにおける一再生単位である。ＶＯＢＵのビデオ再生時間は０．４秒から１．０秒であって、通常は０．５秒程度である。つまり、多くのケースで１ＧＯＰには１５フレーム程度のフレームが格納されている（ＮＴＳＣの場合）。
【００７９】
ＶＯＢＵは、ビデオパック（Ｖ＿ＰＣＫ）とオーディオパック（Ａ＿ＰＣＫ）とを有している。各パックのサイズは、１セクタと同じであり、本実施の形態では、２ＫＢである。
【００８０】
図１０は、パックの構成を示す図である。
【００８１】
図１０に示すように、ビデオデータおよびオーディオデータといったエレメンタリデータは、PES Packet Payload（ペイロード）と呼ばれるPES Packet（パケット）のデータ格納領域に先頭から順次格納される。ペイロードは、PES Packet Header（パケットヘッダ
）が付けられて１つのPES Packet（パケット）を構成する。パケットヘッダには、ペイロードに格納されているデータがどのストリームのデータであるのかを識別するためのstream id（ＩＤ）と、そのペイロードのデコードおよび表示夫々の時刻情報であるタイムス
タンプ、即ちDecoding Time Stamp（ＤＴＳ）およびPresentation Time Stamp（ＰＴＳ）とが記録される。ＰＴＳおよびＤＴＳは、必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによってルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）の規格書に記述されているので、その説明を省略する。
【００８２】
パケットは、更にPack Header（ヘッダ）が付けられて、パックを構成する。そのヘッ
ダには、そのパックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるのかを示すタイムスタンプ、即ちSystem Clock Reference（ＳＣＲ）が記録されている。
【００８３】
（ＶＯＢのインターリーブ記録）
次に、図１１および図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００８４】
図１１上段は、前述したプレーヤの構成図の一部である。図１１に示すように、ＢＤディスク上のＶＯＢ即ちＭＰＥＧストリームは、光ピックアップを通してトラックバッファへ入力される。ＢＤディスク上のＰＮＧ即ちイメージデータは、光ピックアップを通してイメージメモリへ入力される。
【００８５】
トラックバッファはＦＩＦＯ形式のバッファであり、トラックバッファに入力されたＶＯＢのデータは入力された順にデマルチプレクサへ送られる。この時、個々のパックは、前述したＳＣＲに従ってトラックバッファから引き抜かれ、デマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへ送られる。他方、イメージメモリに入力されたイメージデータについては、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使われたイメージデータは、それが字幕用のイメージデータである場合、使われると同時にイメージメモリから削除される。それに対して、描画に使われたイメージデータがメニュー用のイメージデータである場合、そのメニューが描画されている間はイメージメモリ内にそのまま残される。これは、メニューの描画はユーザの操作に依存しており、ユーザの操作に追従してメニューの一部分を再表示または異なるイメージに置き換える際に、再表示される部分のイメージデータをデコードし易くするためである。
【００８６】
図１１下段は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭでは、一連の連続再生単位となるＡＶデータは連続して記録されている。データが連続して記録されている限り、ドライブは順次データを読み出し、デコーダに送り届ける。しかしながら、連続するデータが分断されてディスク上に離散して配置されている場合、ドライブは個々の連続区間をシークするので、シーク期間においてはデータの読み出しが止まることになり、データの供給が止まる可能性がある。それを防止するために、ＲＯＭでは、一連の連続再生単位となるＡＶデータは連続して記録されている。ＢＤでも、ＶＯＢファイルは連続領域に記録されることが望ましい。字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータは、ＶＯＢファイルと同様に何らかの方法によってＢＤディスクから読み出すことが必要になる。
【００８７】
字幕データの読み出し方法の一つとして、ＶＯＢの再生開始前に一まとめに字幕用のイメージデータ（ＰＮＧファイル）を読み出す方法がある。しかしながら、この方法では、大容量のメモリが必要となり、非現実的である。
【００８８】
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方法を採用している。図１１下段はそのインターリーブ記録を説明するための図である。
【００８９】
ＶＯＢファイルとイメージデータとを適切にインターリーブ配置することで、前述したような大容量の一時記録メモリを用いることなく、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。なお、イメージデータを読み出している際には、ＶＯＢデータの読み出しは当然のことながら停止する。
【００９０】
図１２は、トラックバッファを使ったＶＯＢデータ連続供給モデルを説明するための図である。
【００９１】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート（Ｖａ）と、トラックバッファからのデータ出力レート（Ｖｂ）との間に差（Ｖａ＞Ｖｂ）を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加していく。
【００９２】
図１２の上段に示すように、ＶＯＢの一連続記録領域が論理アドレスの“ａ１”から“ａ２”まで続くとする。論理アドレスの“ａ２”から“ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータは記録されていない区間であるとする。
【００９３】
図１２の下段は、トラックバッファ内のデータ量の推移を示す。横軸は時間を示し、縦軸はトラックバッファ内に蓄積されているデータの量を示す。時刻“ｔ１”は、ＶＯＢの一連続記録領域の開始点である論理アドレス“ａ１”のデータの読み出しを開始した時刻を示している。時刻“ｔ１”以降、トラックバッファにはレート（Ｖａ−Ｖｂ）でデータが蓄積される。そのレートは、トラックバッファへ入力するデータのレートと、トラックバッファから出力するデータのレートとの差である。時刻“ｔ２”は一連続記録領域の終了点である論理アドレス“ａ２”のデータを読み出す時刻である。即ち時刻“ｔ１”から“ｔ２”の間、レート（Ｖａ−Ｖｂ）でトラックバッファ内はデータ量が増加する。時刻“ｔ２”でのデータ蓄積量Ｂ（ｔ２）は下記の式１によって求めることができる。
【００９４】
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
【００９５】
この後、論理アドレスの“ａ２”から“ａ３”まではイメージデータが続くため、トラックバッファへのデータの入力は０であり、出力レート“−Ｖｂ”でトラックバッファ内のデータ量は減少する。これは論理アドレス“ａ３”まで、即ち時刻“ｔ３”まで継続する。
【００９６】
ここで大事なことは、時刻“ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。時刻“ｔ３”でトラックバッファにデータが残っている場合、ＶＯＢの再生はストップすることなく連続する。
【００９７】
時刻“ｔ３”より前にトラックバッファに蓄積されているデータ量が０になることを防止するための条件は、下記の式２によって示される。
【００９８】
Ｂ（ｔ２） ≧ Ｖｂ×（ｔ３−ｔ２） （式２）
【００９９】
即ち、式２を満たすように、イメージデータ（非ＶＯＢデータ）の配置を決めればよい。
【０１００】
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤのナビゲーションデータ（ＢＤ管理情報）の構造について説明する。
【０１０１】
図１３は、ＶＯＢ管理情報ファイル（“ＹＹＹ．ＶＯＢＩ”）の内部構造を示す図である。
【０１０２】
ＶＯＢ管理情報は、ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）と、タイムマップ（ＴＭＡＰ）とを有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）と、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）とを含む。特にオーディオストリームに関しては、ＶＯＢが複数のオーディオストリームを同時に持つことができることから、オーディオストリームの数（Ｎｕｍｂｅｒ）によって、データフィールドが示される。
【０１０３】
下記は、ビデオ属性（Ｖｉｄｅｏ）が持つ複数のフィールドと、夫々のフィールドが持ち得る値を示す。
【０１０４】
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
ＭＰＥＧ４−ＡＶＣ（Advanced Video Coding）
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０×１０８０
１２８０×７２０
７２０×４８０
７２０×５６５
アスペクト比（Ａｓｐｅｃｔ）：
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）：
６０
５９．９４
５０
３０
２９．９７
２５
２４
２３．９７６
【０１０５】
下記は、オーディオ属性（Ａｕｄｉｏ）が持つ複数のフィールドと、夫々のフィールドが持ち得る値を示す。
【０１０６】
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
ＤＴＳＨＤ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
【０１０７】
タイムマップ（ＴＭＡＰ）は、ＶＯＢＵ毎の情報を持つテーブルであって、ＶＯＢが有するＶＯＢＵの数（Ｎｕｍｂｅｒ）と、各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）とを持つ。個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）と、ＶＯＢＵのデータサイズ（Ｓｉｚｅ）とを有している。
【０１０８】
図１４はＶＯＢＵ情報の詳細を説明するための図である。
【０１０９】
広く知られているように、ＭＰＥＧビデオストリームは可変ビットレート圧縮されることがあり、各フレームの再生時間とデータサイズとには、単純な相関はない。これに対して、音声の圧縮規格であるＡＣ３は、音声データを固定ビットレートで圧縮することを定めているため、音声データについては、時間とアドレスとの関係は１次式によって表現される。ＭＰＥＧビデオデータでは、個々のフレームは固定の表示時間を持つが、例えばＮＴＳＣに対応するＭＰＥＧビデオデータでは１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性やピクチャタイプ、即ちＩ／Ｐ／Ｂピクチャのタイプによって大きく異なる。従って、ＭＰＥＧビデオデータについては、時間とアドレスとの関係を一次式で表現することは不可能である。
【０１１０】
当然のこととして、ＭＰＥＧビデオデータが多重化されているＭＰＥＧシステムストリーム、即ちＶＯＢについても、時間とデータサイズとの関係を一次式で表現することは不可能である。ＶＯＢでは、タイムマップ（ＴＭＡＰ）が時間とアドレスとを結びつける。図１４に示すように、ＶＯＢＵ毎に、ＶＯＢＵ内のフレームの数と、ＶＯＢＵ内のパックの数（つまりデータサイズ）とをエントリとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
【０１１１】
図１５を用いて、タイムマップ（ＴＭＡＰ）を詳細に説明する。
【０１１２】
図１５に示すように時刻情報が与えられた場合、先ずはその時刻がどのＶＯＢＵに属するのかを検索する。即ち、タイムマップのＶＯＢＵ毎のフレームの数を加算し、フレームの数の和が、与えられた時刻をフレーム数に換算した場合のそのフレーム数を超えるＶＯＢＵ、またはそのフレーム数に一致するＶＯＢＵを検索する。次に、タイムマップのＶＯＢＵ毎のデータサイズをそのＶＯＢＵの直前のＶＯＢＵまで加算する。加算によって得られた値が、与えられた時刻を含むフレームを再生するために読み出すべきパックのアドレスを求めるために用いられる。
【０１１３】
次に、図１６を用いて、プレイリスト情報（“ＸＸＸ．ＰＬ”）の内部構造を説明する。
【０１１４】
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）と、イベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１１５】
セルリスト（ＣｅｌｌＬｉｓｔ）はプレイリスト内の再生セルシーケンスであり、セルリストの記述順でセルが再生される。セルリスト（ＣｅｌｌＬｉｓｔ）は、セルの数（Ｎｕｍｂｅｒ）と、各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）とから構成されている。
【０１１６】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）と、ＶＯＢ内での開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）とを持っている。開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）は、夫々ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得ることができる。
【０１１７】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、ＶＯＢと同期再生される字幕の情報を持つテーブルである。ＶＯＢは音声と同様に複数の言語の字幕を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、言語の数（Ｎｕｍｂｅｒ）と、それに続く言語毎のテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）とから構成されている。
【０１１８】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇ）と、個々に表示される字幕の情報の数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の情報（字幕情報，Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）とから構成されている。字幕情報（Ｓｐｅｅｃｈ＃）は、対応するイメージデータのファイル名（Ｎａｍｅ）と、字幕の表示開始時刻（Ｉｎ）および字幕の表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）とから構成されている。
【０１１９】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベントの数（Ｎｕｍｂｅｒ）と、それに続く個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成されている。個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）と、イベントの識別子（ＩＤ）と、イベントの発生時刻（Ｔｉｍｅ）と、イベントの有効期間（Ｄｕｒａｔｉｏｎ）とから構成されている。
【０１２０】
図１７は、個々のプレイリストのイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（“ＸＸＸ．ＰＲＯＧ”）を示す図である。
【０１２１】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラムの数（Ｎｕｍｂｅｒ）と、個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）とを有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）は、イベントハンドラの開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と、前述したイベントの識別子と対になるイベントハンドラの識別子（ＩＤ）とを持つ。その後に、プログラムが、Ｆｕｎｃｔｉｏｎに続く括弧“｛”と“｝”との間に記述される。前述の“ＸＸＸ．ＰＬ”のイベントリスト（ＥｖｅｎｔＬｉｓｔ）に格納されたイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は、“ＸＸＸ．ＰＲＯＧ”のイベントハンドラの識別子（ＩＤ）を用いて特定される。
【０１２２】
次に、図１８を用いてＢＤディスク全体に関する情報（“ＢＤ．ＩＮＦＯ”）の内部構造を説明する。
【０１２３】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）と、グローバルイベント用のイベントテーブル（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１２４】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトルの数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）とから構成されている。個々のタイトル情報（Ｔｉｔｌｅ＃）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｂｌｅ）と、タイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）とを含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）は、タイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名とを有している。
【０１２５】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、タイトルに含まれるチャプタの数（Ｎｕｍｂｅｒ）と、個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）とから構成されている。個々のチャプタ情報（Ｃｈａｐｔｅｒ＃）は、そのチャプタを含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持つ。セルのテーブル（ＣｅｌｌＴａｂｌｅ）は、セルの数（Ｎｕｍｂｅｒ）と、個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）とから構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は、そのセルを含むプレイリスト名と、プレイリスト内でのセル番号とから構成されている。
【０１２６】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と、個々のグローバルイベントの情報とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入されたとき、最初に呼ばれる。グローバルイベント用のイベント情報は、イベントタイプ（Ｔｙｐｅ）と、イベントの識別子（ＩＤ）とだけを持っている。
【０１２７】
図１９は、グローバルイベントハンドラのプログラムのテーブル（“ＢＤ．ＰＲＯＧ”）を示す図である。
【０１２８】
本テーブルの内容は、図１７を用いて説明したイベントハンドラテーブルの内容と同じである。
【０１２９】
（イベント発生のメカニズム）
図２０から図２２を用いてイベント発生のメカニズムについて説明する。
【０１３０】
図２０はタイムイベントの例を示す図である。
【０１３１】
前述したとおり、タイムイベントは、プレイリスト情報（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＴｉｍｅＥｖｅｎｔ”である場合、イベント生成時刻（“ｔ１”）に、識別子“Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに出力される。プログラムプロセッサは、イベント識別子“Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、２つのボタンイメージの描画等のイベントが行われる。
【０１３２】
図２１はメニュー操作を行うユーザイベントの例を示す図である。
【０１３３】
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＵｓｅｒＥｖｅｎｔ”である場合、イベント生成時刻（“ｔ１”）に、ユーザイベントはレディとなる。この時、イベント自身は未だ生成されていない。イベントは、有効期間情報（Ｄｕｒａｔｉｏｎ）で示される期間レディ状態にある。
【０１３４】
図２１に示すように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されてプログラムプロセッサに出力される。プログラムプロセッサは、シナリオプロセッサにＵＯＰイベントを出力する。シナリオプロセッサは、ＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するか否かを調べ、有効なユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサに出力する。プログラムプロセッサは、イベント識別子“Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、プレイリスト＃２の再生が開始される。
【０１３５】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたのかを特定する情報は含まれない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録され保持される。このレジスタの値を調べることにより、イベントハンドラのプログラムを分岐処理することが可能である。
【０１３６】
図２２はグローバルイベントの例を示す図である。
【０１３７】
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（“ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベントのタイプ（Ｔｙｐｅ）が“ＧｌｏｂａｌＥｖｅｎｔ”である場合、ユーザがリモコンキーを操作したときにのみイベントが生成される。
【０１３８】
ユーザが“メニュー”キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されてプログラムプロセッサに出力される。プログラムプロセッサはシナリオプロセッサにＵＯＰイベントを出力し、シナリオプロセッサはそのＵＯＰイベントに対応するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサは、イベント識別子“ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、本実施の形態では、プレイリスト＃３の再生が開始される。
【０１３９】
本実施の形態では、“メニュー”キーは１個である場合を想定しているが、ＤＶＤレコーダのリモコンのように、メニューキーは複数存在していてもよい。その場合、メニューキー毎に対応する識別子が定義される。
【０１４０】
（仮想プレーヤマシン）
図２３を用いてプログラムプロセッサの機能を説明する。
【０１４１】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンは、ＢＤに対応する機能を有し、ＢＤプレーヤの実装には依存しない。即ち、仮想プレーヤマシンは、どのＢＤプレーヤにおいても同様の機能を実現できることが保証されている。
【０１４２】
仮想プレーヤマシンは、プログラミング関数とプレーヤ変数（レジスタ）とを持っている。プログラミング関数では、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能がＢＤ固有関数として定義されている。
【０１４３】
リンク関数：現在の再生を停止し、指定されたプレイリスト、セル、または時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅
【０１４４】
プレーヤ変数として、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と、一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１４５】
図２４はシステムパラメータ（ＳＰＲＭ）の一覧を示す図である。
【０１４６】
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
【０１４７】
なお、本実施の形態では、仮想プレーヤのプログラミング関数はＪａｖａ（登録商標）Ｓｃｒｉｐｔベースとして定義されているが、プログラミング関数は、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなどによって定義されてもよい。言い換えれば、プログラミング関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔによって定義されると限定されない。
【０１４８】
（プログラムの例）
図２５および図２６は、イベントハンドラでのプログラムの例を示す図である。
【０１４９】
図２５は、２つの選択ボタンを持つメニューのプログラムの例を示す図である。
【０１５０】
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）の先頭のタイムイベントに基づいて、図２５左側のプログラムが実行される。ゼネラルパラメータの一つＧＰＲＭ（０）に“１”がセットされている。ＧＰＲＭ（０）は、プログラムの中で、選択されているボタンを識別するために用いられている。最初の状態（初期値）では、左側に配置されているボタン１が選択されている。
【０１５１】
次に、ＰＮＧの描画が、描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行われる。ボタン１は、座標（１０、２００）を起点（左端）とする領域に、ＰＮＧイメージ“１ｂｌａｃｋ．ｐｎｇ”が描画されることにより形成される。ボタン２は、座標（３３０，２００）を起点（左端）とする領域に、ＰＮＧイメージ“２ｗｈｉｔｅ．ｐｎｇ”が描画されることにより形成される。
【０１５２】
また、本セルの最後のタイムイベントが用いられて、図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って、セルの先頭から再度再生するように指定されている。
【０１５３】
図２６は、メニュー選択のユーザイベントのイベントハンドラの例を示す図である。
【０１５４】
「左」キー、「右」キー、「決定」キーが押された場合の夫々のキーに対応するプログラムが、イベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２１を用いて説明したとおり、ユーザイベントが生成され、図２６のイベントハンドラが起動する。本イベントハンドラでは、選択ボタンを識別するＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）とを使って、分岐処理が行われる。
【０１５５】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーである場合
ＧＰＲＭ（０）を“２”に再設定して、選択状態にあるボタンを右ボタン２に変更する。
【０１５６】
ボタン１、ボタン２のイメージを夫々書き換える。
【０１５７】
条件２）選択キーが「決定（ＯＫ）」であって、ボタン１が選択されている場合
プレイリスト＃２の再生を開始する。
【０１５８】
条件３）選択キーが「決定（ＯＫ）」であって、ボタン２が選択されている場合
プレイリスト＃３の再生を開始する。
【０１５９】
上記のような分岐処理が行われる。
【０１６０】
（プレーヤ処理フロー）
次に、図２７から図３０を用いてプレーヤの処理フローを説明する。
【０１６１】
図２７は、ＡＶの再生までの基本処理フローを示す図である。
【０１６２】
ＢＤディスクが挿入されると（Ｓ１０１）、ＢＤプレーヤは、“ＢＤ．ＩＮＦＯ”ファイルの読み込みと解析とを行い（Ｓ１０２）、“ＢＤ．ＰＲＯＧ”ファイルを読み込む（Ｓ１０３）。“ＢＤ．ＩＮＦＯ”ファイルおよび“ＢＤ．ＰＲＯＧ”ファイルは、共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１６３】
続いて、シナリオプロセッサは、“ＢＤ．ＩＮＦＯ”ファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントはプログラムプロセッサによって受け取られ、プログラムプロセッサは、そのイベントに対応するイベントハンドラを実行する（Ｓ１０５）。
【０１６４】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されている、ことが期待される。仮に、プレイリストの再生が指示されていない場合、プレーヤは何も再生することなく、ユーザイベントを待ち続ける（Ｓ２０１）。ＢＤプレーヤがユーザからのリモコン操作による指示を受け付けると、ＵＯＰマネージャは、プログラムマネージャに対してＵＯＰイベントの実行を開始させる（Ｓ２０２）。
【０１６５】
プログラムマネージャは、ＵＯＰイベントがメニューキーであるか否かを判別し（Ｓ２０３）、ＵＯＰイベントがメニューキーである場合、シナリオプロセッサにＵＯＰイベントを出力し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは、生成されたユーザイベントに対応するイベントハンドラを実行する（Ｓ２０５）。
【０１６６】
図２８は、ＰＬの再生開始からＶＯＢの再生開始までの処理フローを示す図である。
【０１６７】
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリストの再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリストの再生に必要な情報として、プレイリスト情報“ＸＸＸ．ＰＬ”の読み込みと解析とを行い（Ｓ３０２）、プレイリストに対応するプログラム情報“ＸＸＸ．ＰＲＯＧ”を読み込む（Ｓ３０３）。続いて、シナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する（Ｓ３０４）。セルの再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出されたことを意味し、プレゼンテーションコントローラはＡＶの再生を開始する（Ｓ３０５）。
【０１６８】
ＡＶの再生が開始されると（Ｓ４０１）、プレゼンテーションコントローラは、再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）の読み込みと解析とを行う（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生を開始するＶＯＢＵとそのアドレスとを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出す（Ｓ４０３）。これにより、ＶＯＢデータがデコーダに送られ、その再生が開始される（Ｓ４０４）。
【０１６９】
ＶＯＢの再生は、そのＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセルの再生（Ｓ３０４）へ移行する。次のセルが無い場合、再生は停止する（Ｓ４０６）。
【０１７０】
図２９は、ＡＶの再生開始後からのイベント処理フローを示す図である。
【０１７１】
ＢＤプレーヤはイベントドリブン型のプレーヤである。プレイリストの再生が開始すると、タイムイベント系、ユーザイベント系、および字幕表示系のイベント処理が夫々起動し、平行してイベント処理が実行される。
【０１７２】
Ｓ５００系の処理は、タイムイベント系の処理である。
【０１７３】
プレイリストの再生開始後（Ｓ５０１）、プレイリストの再生が終了しているか否かを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったか否かを確認する（Ｓ５０３）。タイムイベント発生時刻になった場合、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサはタイムイベントを受け取って、イベントハンドラを実行する（Ｓ５０５）。
【０１７４】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、および、ステップＳ５０４でイベントハンドラを実行した後、ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリストの再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１７５】
Ｓ６００系の処理は、ユーザイベント系の処理である。
【０１７６】
プレイリストの再生開始後（Ｓ６０１）、プレイリストの再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰの受付確認ステップに移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサは、ＵＯＰイベントがメニューコールであるか否かを確認する（Ｓ６０５）。ＵＯＰイベントがメニューコールである場合、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行する（Ｓ６０８）。
【０１７７】
ステップＳ６０５でＵＯＰイベントがメニューコールでないと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントであることを示している。この場合、現在時刻がユーザイベント有効期間内であるか否かをシナリオプロセッサが判断する（Ｓ６０６）。現在時刻がユーザイベント有効期間内である場合、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行する（Ｓ６０８）。
【０１７８】
ステップＳ６０３でＵＯＰが受付けられていない場合、ステップＳ６０６で現在時刻がユーザイベント有効期間にない場合、および、ステップＳ６０８でイベントハンドラを実行した後、ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリストの再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１７９】
図３０は字幕処理のフローを示す図である。
【０１８０】
プレイリストの再生開始後（Ｓ７０１）、プレイリストの再生終了確認ステップ（Ｓ７０２）を経て、字幕の描画開始時刻確認ステップ（Ｓ７０３）に移る。現在時刻が字幕の描画開始時刻である場合、シナリオプロセッサはプレゼンテーションコントローラに字幕の描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕の描画を指示する（Ｓ７０４）。ステップＳ７０３で現在時刻が字幕の描画開始時刻でないと判断された場合、現在時刻が字幕の表示終了時刻であるか否かを確認する（Ｓ７０５）。現在時刻が字幕の表示終了時刻であると判断された場合、プレゼンテーションコントローラはイメージプロセッサに字幕の消去を指示し、イメージプロセッサは描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１８１】
字幕の描画ステップＳ７０４の終了後、字幕の消去ステップＳ７０６の終了後、および、字幕の表示終了時刻確認ステップＳ７０５で現在時刻が字幕の表示終了時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリストの再生が終了したことが確認されると、字幕の表示に関する処理は強制的に終了する。
【０１８２】
（実施の形態１）
次に、実施の形態１について説明する。
【０１８３】
実施の形態１はＢＤの音声データにおけるストリーム構造に関し、その内容は基本的には上記の関連する実施の形態に基づく。したがって、実施の形態１では、関連する実施の形態から拡張した部分、および関連する実施の形態と異なる部分を中心に説明する。
【０１８４】
図３１は階層構造を持たない１つのアクセスユニット（映像／音声の情報に対する復号および再生の符号化単位）の構造を示す図である。映像符号化方式の一つであるＭＰＥＧ−２ビデオや、音声符号化方式の一つであるＭＰＥＧ−１オーディオなどでは、一つのアクセスユニットは、図３１に示すように、ヘッダ部（Ｂａｓｅ Ｈｅａｄｅｒ）と、ペイロード部（Ｂａｓｅ Ｐａｙｌｏａｄ）とから構成される。
【０１８５】
Ｂａｓｅ Ｈｅａｄｅｒには、Ｂａｓｅ ｆｒａｍｅの同期信号であるＢａｓｅ ＳＹＮＣ、このアクセスユニットのデータサイズを示すＡＵ＿ＳＩＺＥ、このアクセスユニットがＢａｓｅ ｆｒａｍｅからのみ構成されているか否かを示すＥＸＴ、もしこのアクセスユニットがＢａｓｅ ｆｒａｍｅからのみで構成されていない場合に、どのような種類の拡張情報が付与されているのかを示すＥＸＴ＿ＩＤ、および、将来使用される場合のためのリザーブ領域などが設けられている。
【０１８６】
図３１のアクセスユニットでは階層構造は導入されておらず、１つの符号化方式のみで１つのアクセスユニット全体が符号化されている。それは、１種類の復号方式のみで１アクセスユニット全てを復号することができることを意味する。
【０１８７】
図３２は、Ｂａｓｅ ｆｒａｍｅに、Ｂａｓｅ ｆｒａｍｅとは異なる符号化方式により、例えば、より高画質な映像情報やより高音質な音声情報を符号化したＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅが追加された、１アクセスユニットの構造を示す図である。
【０１８８】
Ｂａｓｅ ＨｅａｄｅｒのＥＸＴは、このアクセスユニットがＢａｓｅ ｆｒａｍｅからのみで構成されていないことを示し、ＥＸＴ＿ＩＤは、他の拡張階層データの内、Ｌｅｖｅｌ１がＢａｓｅ ｆｒａｍｅに続いて符号化されていることを示している。
【０１８９】
ＡＵ＿ＳＩＺＥは、アクセスユニットのサイズを表す。ＡＵ＿ＳＩＺＥを使うことにより、Ｂａｓｅ ｆｒａｍｅしか復号できないデコーダ（Ｌｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを復号できないデコーダ）がこのアクセスユニットをＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを無視しながら適切に復号できるように、１アクセスユニットを設計することができる。
【０１９０】
このように、元々ある符号化単位（Ｂａｓｅ）に新たな拡張部分（Ｌｅｖｅｌ１−ＥＸＴ）を追加しても、Ｌｅｖｅｌ１−ＥＸＴ ｆｒａｍｅを無視することにより、図３２に示すアクセスユニットにより構成されるストリームを復号することができる。それとともに、次々と新しい圧縮符号化アルゴリズムを導入することができる。
【０１９１】
同様にＬｅｖｅｌ２−ＥＸＴまで拡張されたアクセスユニットを、図３３に示す。Ｌｅｖｅｌ２−ＥＸＴのデータは、例えば、Ｌｅｖｅｌ１−ＥＸＴまでのデータのサンプリングレートより高いサンプリングレートの音声を得るためのＬｅｖｅｌ１−ＥＸＴまでのデータに含まれないデータである。
【０１９２】
ＥＸＴ＿ＩＤは、Ｌｅｖｅｌ１とＬｅｖｅｌ２とが存在することを示すように設定される。
【０１９３】
図３４は、このように階層構造を持って符号化されたデータ（例えば、Ｌｅｖｅｌ２ストリーム）を、様々な階層に対応したデコーダに出力するストリーム読込／供給部の、データの出力先毎に異なる動作を説明するための図である。
【０１９４】
Ｂａｓｅデコーダにデータを出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＬｅｖｅｌ１−ＥＸＴとＬｅｖｅｌ２−ＥＸＴフレームとを取り除いて、Ｂａｓｅ ｆｒａｍｅだけを出力する。その際、ストリーム読込／供給部は、Ｂａｓｅ Ｈｅａｄｅｒのアクセスユニットのサイズ情報であるＡＵ＿ＳＩＺＥ、Ｂａｓｅ ｆｒａｍｅからのみで構成されているか否かを示すＥＸＴ、および拡張階層データの種別を示すＥＸＴ＿ＩＤの各値を書換えて、データを出力する。
【０１９５】
同様に、Ｌｅｖｅｌ１デコーダにデータを出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＬｅｖｅｌ２−ＥＸＴ ｆｒａｍｅを取り除き、ＡＵ＿ＳＩＺＥ、およびＥＸＴ＿ＩＤの各値を書換えてデータを出力する。
【０１９６】
勿論、Ｌｅｖｅｌ２ストリームをＬｅｖｅｌ２デコーダに出力する場合、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームをそのまま出力する。
【０１９７】
ここで、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及しており、新たにＬｅｖｅｌ２−ＥＸＴを導入する場合を想定する。この場合、Ｌｅｖｅｌ２ストリームからＢａｓｅ ｆｒａｍｅとＬｅｖｅｌ１−ＥＸＴ ｆｒａｍｅとを抽出することのみを行い、抽出したデータをその機器に対して出力することが望ましい。つまり、データを一切修正しないことが望ましい。
【０１９８】
図３５は、ＢａｓｅとＬｅｖｅｌ１−ＥＸＴとに対応した機器が広く普及した場合に、Ｌｅｖｅｌ２−ＥＸＴを導入するための理想的なアクセスユニットの構造を示す図である。
【０１９９】
図３５に示すアクセスユニットでは、アクセスユニットがＢａｓｅとＬｅｖｅｌ１−ＥＸＴとから構成される場合と同様に、Ｌｅｖｅｌ１−ＥＸＴまでのデータに関する情報は、Ｂａｓｅ Ｈｅａｄｅｒ（およびＬｅｖｅｌ１ Ｈｅａｄｅｒ）に記述されている。それに対して、Ｌｅｖｅｌ２−ＥＸＴ以降の拡張階層データに関する情報は、リザーブ領域のようなＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダが感知しない領域に記述されている。図３５では、ＥＸＴ＿ＩＤにはＬｅｖｅｌ２は存在しないことを示す値が設定されているが、Ｌｅｖｅｌ１のフレームまでは使われていなかったリザーブ領域にＥＸＴ＿ＩＤ２が用意され、そこにＬｅｖｅｌ２の拡張階層データが存在することが記述されている。
【０２００】
図３５に示すＬｅｖｅｌ２のアクセスユニット（例えばＢａｓｅ、Ｌｅｖｅｌ１−ＥＸＴ、およびＬｅｖｅｌ２−ＥＸＴを含むアクセスユニット）を、Ｌｅｖｅｌ１のアクセスユニット（Ｂａｓｅのみ、または、ＢａｓｅおよびＬｅｖｅｌ１−ＥＸＴ）へ変換して出力する際、ストリーム読込／供給部は、Ｌｅｖｅｌ２ストリームからＢａｓｅの部分とＬｅｖｅｌ１−ＥＸＴの部分との抽出のみを行う。つまり、ストリーム読込／供給部は、データの書換えを一切行わずにＬｅｖｅｌ１のデコーダに、Ｌｅｖｅｌ１のアクセスユニットにより構成されるストリームを出力することが可能となる。
【０２０１】
上述の方法は、ＡＵ＿ＳＩＺＥなどのサイズ情報のビットの割り当て数が少なく、Ｌｅｖｅｌ２を加えた際に１アクセスユニットのデータサイズが大きすぎて、サイズ情報をＡＵ＿ＳＩＺＥでは表現することができない場合などにも有効である。
【０２０２】
「ＤＴＳ」では、ＤＴＳ＋＋によりロスレス圧縮の符号化データが生成されても、サンプリングＰＣＭデータ如何によっては、ほとんど圧縮の効果が得られない場合がある、その場合、ＤＴＳの数１００ＫｂｐｓからからＤＴＳ＋＋（ロスレス）の数１０Ｍｂｐｓ辺りまで、ビットレートが急激に増えることが考えられる。その結果、現在のＤＴＳのＣｏｒｅヘッダに記述されるアクセスユニットのデータサイズを示すＦＳＩＺＥ（１４ビットでバイト単位のデータサイズを示す）では、サイズを示すためのビットフィールドが不足する問題が起こる。このため、ＤＴＳ＋＋のロスレス圧縮のように、サイズをＡＵ＿ＳＩＺＥ（ＦＳＩＺＥ）で記述することができない場合、ＡＵ＿ＳＩＺＥの範囲を２つのデータブロックに分けることが考えられる。
【０２０３】
図３６は、Ｌｅｖｅｌ１までサポートする機器が存在し、新たにＬｅｖｅｌ２を採用する場合のデータストリームのデータ構造を示す図である。
【０２０４】
図３６は、１つのアクセスユニットが、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されていることを、明確に示している。
【０２０５】
映像や音声のエレメンタリーストリームをＭＰＥＧ２−ＴＳ（transport stream）やＭＰＥＧ２−ＰＳ（program stream）で多重化する場合、データはＰＥＳパケットと呼ばれる論理単位に格納されることがＭＰＥＧ規格で規定されている。
【０２０６】
ＰＥＳパケットは、ＰＥＳヘッダと実データを格納するＰＥＳペイロードとから構成され、ＰＥＳヘッダは図３６に示すように様々なフィールドを有する。
【０２０７】
ｓｔｒｅａｍ＿ｉｄは、そのＰＥＳパケットのペイロード部に格納されているエレメンタリーストリームの種別を示す。一般にｓｔｒｅａｍ＿ｉｄが異なることは、エレメンタリーストリームが異なることを示す。ＰＥＳ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈは、ＰＥＳパケットのデータサイズを示す。ＰＥＳ＿ｐｒｉｏｒｉｔｙは、そのＰＥＳパケットの優先レベルを識別するための情報である。ＰＴＳ＿ＤＴＳ＿ｆｌａｇｓは、そのＰＥＳペイロードの再生開始時刻情報であるＰＴＳと復号開始時刻情報であるＤＴＳとがあるか否かを示す情報である。ＰＴＳとＤＴＳの値が同じ場合にはＤＴＳは省略される。ＰＥＳ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ、およびＰＥＳ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ＿２は、夫々ＰＥＳパケットのペイロード部に拡張データ領域があるか否かを示す情報である。ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎは、ｓｔｒｅａｍ＿ｉｄ＝０ｘＦＤ（ｅｘｔｅｎｄｅｄ＿ｓｔｒｅａｍ＿ｉｄ）の場合にのみ存在可能なｓｔｒｅａｍ＿ｉｄを補うための、エレメンタリーストリームの識別補助情報である。
【０２０８】
アクセスユニットのＢａｓｅフレーム部分（図３６では、Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ部分）と、Ｂａｓｅフレームを含まない部分（図３６では、Ｌｅｖｅｌ２−ＥＸＴ部分）とは、後述するＴＳパケットの識別情報であるPacket Identifier（ＰＩＤ）を同一
にし、ｓｔｒｅａｍ＿ｉｄを異ならせて分けられてもよいし、ＰＴＳ＿ＤＴＳ＿ｆｌａｇｓを異ならせて分けられてもよいし、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを用いて分けられてもよい。Ｂａｓｅフレーム部分を、２０３２バイト、またはＤＶＤ−Ｖｉｄｅｏにも対応する２０１３バイトで完結する部分とし、１アクセスユニットのそれ以外の部分を、Ｂａｓｅフレームを含まない部分とすることにより、Ｂａｓｅフレーム部分とＢａｓｅフレームを含まない部分とが分けられてもよい。
【０２０９】
例えば、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを用いる場合、Ｂａｓｅフレームを含むＰＥＳパケットもＢａｓｅフレームを含まないＰＥＳパケットもｓｔｒｅａｍ＿ｉｄ＝０ｘＦＤ（プライベートストリーム）となる。そこで、Ｂａｓｅフレームを含むＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値（例えば０ｘ７０）と、Ｂａｓｅフレームを含まないＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値（例えば０ｘ７１）とを異なる値に設定する。これにより、プレーヤや外部出力部はＢａｓｅフレームを含むデータのみを抽出することができる。この場合、設定されるｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ値は、論理アドレス０ｘ４０から０ｘ７Ｆのプライベートストリーム領域に記録される。
【０２１０】
１つ目のＰＥＳパケットには、現存する機器に対応する（ディジタルインターフェース上のプロトコルなどが規定されており、尚且つそれに対応した入力端子を持つ、現存するＡＶレシーバに対応する）Ｌｅｖｅｌ１までの符号化単位を格納することができる。２つ目のＰＥＳパケットには、現存しない機器に対応する（ディジタルインターフェース上のプロトコルなどが規定されていない、またはそれに対応した入力端子を持たない、現存しないＡＶレシーバに対応する）Ｌｅｖｅｌ２以降の符号化単位を格納することができる。
【０２１１】
１つ目のＰＥＳパケットと、２つ目以降のＰＥＳパケットとは、ｓｔｒｅａｍ＿ｉｄ、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎ、またはＰＴＳ＿ＤＴＳ＿ｆｌａｇｓ、の値を判断することにより区別することが可能である。
【０２１２】
上述したように、ＰＥＳヘッダには、ＰＥＳ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈなどのサイズ情報があるため、ＰＥＳペイロードはそのサイズ情報から極めて容易に抽出することができる。従って、Ｌｅｖｅｌ１−ＥＸＴまでの符号化単位が既存のＡＶレシーバやディジタルインターフェースに互換性が高く１つ目のＰＥＳパケットにまとめて格納されている場合、１つ目のＰＥＳパケットのＰＥＳペイロードは、ＰＥＳヘッダを解析することで容易に抽出することができる。
【０２１３】
図３７を用いて、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴと、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴとの２つの部分から構成されているアクセスユニットの処理を再度説明する。
【０２１４】
ＢＤプレーヤ１０００において、複数のアクセスユニットにより構成されているストリームが記録されているＢＤディスク１００１から、そのストリームがパーサ１００２に入力される。パーサ１００２は、各アクセスユニットについて、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを区別する。
【０２１５】
そして、パーサ１００２は、Ｂａｓｅフレーム部のみを処理することができる、ＢＤプレーヤ１０００内部のデコーダ１００３へ、Ｂａｓｅフレーム部である１つ目のＰＥＳパケットを出力する。デコーダ１００３は、１つ目のＰＥＳパケットをデコードし、デコードデータを、ステレオ／アナログインターフェース１００４を介して、テレビ１００５に出力する。テレビ１００５は、ＢＤプレーヤ１０００からのデータを再生し、そのデータに基づく画像および音声を出力する。
【０２１６】
また、パーサ１００２は、ＳＰＤＩＦ１００６を介して、ＢＤプレーヤ１０００外部のＡ／Ｖレシーバ１００７内の、Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９に、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットを出力する。Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９は、Ｂａｓｅフレーム部や、それに加えてＬｅｖｅｌ１−ＥＸＴフレーム部を処理することができるデコーダであり、ＢＤプレーヤ１０００からの１つ目のＰＥＳパケットを処理する。
【０２１７】
さらに、パーサ１００２は、Ａｄｖａｎｃｅｄ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ１０１１を介して、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを、Ａ／Ｖレシーバ１００７内の、Ｌｅｖｅｌ２−ＥＸＴデコーダ１０１２に出力する。Ｌｅｖｅｌ２−ＥＸＴデコーダ１０１２は、ＢａｓｅからＬｅｖｅｌ２−ＥＸＴフレームまでの全てのフレームを処理することができるデコーダであり、ＢＤプレーヤ１０００からの両方のＰＥＳパケットを処理する。
【０２１８】
このように、パーサ１００２がアクセスユニットを解析することにより、アクセスユニットは、既存のデコーダであるデコーダ１００３、Ｂａｓｅデコーダ１００８、および、Ｂａｓｅ／Ｌｅｖｅｌ１−ＥＸＴデコーダ１００９に送信され、処理される。それとともに、アクセスユニットは、Ｂａｓｅフレーム部を含む１つ目のＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴ部だけを含む２つ目以降のＰＥＳパケットとを処理することができるＬｅｖｅｌ２−ＥＸＴデコーダ１０１２に出力され、処理される。
【０２１９】
なお、図３７のＢＤプレーヤ１０００は、本発明のデータ再生装置の一例である。パーサ１００２はデータ分別装置の一例である。
【０２２０】
全デコーダで復号が保証されているＢａｓｅフレームが格納されたＰＥＳパケットの次には、それに付加機能を与えることができるものの復号互換性の低い拡張フレーム（Ｌｅｖｅｌ１−ＥＸＴやＬｅｖｅｌ２−ＥＸＴなど）が格納されたＰＥＳパケットが続くことが重要である。また、１アクセスユニットの中のデータの並び順は、Ｂａｓｅ、Ｌｅｖｅｌ１−ＥＸＴ、Ｌｅｖｅｌ２−ＥＸＴ、Ｌｅｖｅｌ３−ＥＸＴ、Ｌｅｖｅｌ４−ＥＸＴ、・・・と昇順であり、１アクセスユニットの全ての符号化単位を抽出する際に並べ替えが発生しないことが重要である。
【０２２１】
ＤＴＳ（Ｄｉｇｉｔａｌ Ｔｈｅａｔｅｒ Ｓｙｓｔｅｍｓ社が開発した音声符号化方式）では、１つ目のＢａｓｅ（ＤＴＳではｃｏｒｅと呼ぶ）を含むＰＥＳパケットのペイロードのデータサイズは、ディジタルインターフェースであるＳＰＤＩＦ（Sony/Philips
Digital Interconnect Format、民生向けはＩＥＣ６０９５８−３規格で規定）の規定に従い、２０３２バイト以下とすればよい。これは、４８ＫＨｚでサンプリングされた音声データの内５１２サンプルを１フレームに格納するＤＴＳ−ｔｙｐｅＩ方式の場合、ビットレートに換算して１５２４Ｋｂｐｓ以下までを１つめのＰＥＳパケットにて格納するということになる。
【０２２２】
ここで、１５２４[Ｋｂｐｓ]＝２０３２[ｂｙｔｅｓ]×８[ｂｉｔｓ／ｂｙｔｅ]×４８０００[ｓａｍｐｌｅ／ｓｅｃ]／５１２[ｓａｍｐｌｅ]
【０２２３】
ＤＶＤ−Ｖｉｄｅｏプレーヤから出力されるデータに準拠したＤＴＳ対応のＡＶレシーバ（ホームシアターなど）との互換性を保つには、１つ目のＢａｓｅを含むＰＥＳパケットのペイロードのデータサイズを、２０１３バイト以下とすればよい。
【０２２４】
このようにして、ＰＥＳパケット単位で、既存のプレーヤ／デコーダと新規のプレーヤ／デコーダとの互換性を保って、１つのアクセスユニットのデータを分割して管理する。つまり、ディジタルインターフェースの規定に応じて、１つのアクセスユニットのデータを分割して管理する。これにより、所定の拡張階層データまでを含むアクセスユニットデータを、一切加工することなく、かつ不整合を起こすことなく送出することができる。
【０２２５】
図３８は、ＭＰＥＧ２−ＴＳで多重化される、階層構造を持つアクセスユニットの構造を示す図である。
【０２２６】
ＭＰＥＧ２−ＴＳは、１つ１８８バイトのＴＳパケットから構成されるディジタルストリームであり、ＭＰＥＧ２−ＴＳのプログラムの構成情報を格納しているProgram Map Table（ＰＭＴ）の一部は、図３８に示すような構造である。
【０２２７】
ＭＰＥＧ２−ＴＳの規定では、１つのＴＳパケットが複数のＰＥＳパケットを格納することは禁止されている。そのため、図３８に示すように、Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴの符号化単位を格納したＰＥＳパケットと、Ｌｅｖｅｌ２−ＥＸＴの符号化単位を格納したＰＥＳパケットとは、別々のＴＳパケットに格納される。
【０２２８】
ＭＰＥＧ２−ＴＳには、そのＭＰＥＧ２−ＴＳ内に格納されているプログラムを示すＰＭＴパケットが格納されている。ＰＭＴは、所定のプログラムに属する映像情報や音声情報などの各種情報がどのＰＩＤのＴＳパケットで運ばれているのかを示すｅｌｅｍｅｎｔａｒｙ＿ｓｔｒｅａｍ＿ＰＩＤと、そのエレメンタリーストリームの符号化種別を示すｓｔｒｅａｍ＿ｔｙｐｅと、そのエレメンタリーストリームについて付加情報を記述した１つまたは複数のｄｅｓｃｒｉｐｔｏｒとを格納している。
【０２２９】
階層構造を持つ符号化方式に対するｄｅｓｃｒｉｐｔｏｒには、拡張階層のレベル情報（ｃｏｄｉｎｇ＿ｌｅｖｅｌ）や、現時点でサポートされていない、または極めて少ない拡張階層を用いているか否かを示す情報（例えば、Ｌｅｖｅｌ２を使っているか否かを示す識別情報、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅ）や、符号化データが音声情報であれば、チャンネル配置情報（ｃｈａｎｎｅｌ＿ａｓｓｉｇｎｍｅｎｔ）や、サンプリング周波数（ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙ）などの情報が記述されることが考えられる。
【０２３０】
符号化データが映像情報であれば、ｄｅｓｃｒｉｐｔｏｒに、ｃｏｄｉｎｇ＿ｌｅｖｅｌや、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅの他に、解像度情報やフレーム周波数などが記述されることが考えられる。
【０２３１】
ここで、符号化データが音声情報である場合のｄｅｓｃｒｉｐｔｏｒに記述される内容を、図３９から図４１を用いて説明する。
【０２３２】
図３９に示すように、ｄｅｓｃｒｉｐｔｏｒには、レベルと、オーディオ属性（Ｑ値、周波数、チャンネル、およびスピーカレイアウト）との関係を記述することができる。スピーカレイアウトの情報を利用することにより、デコーダは、処理するストリームのレイアウトと、実際のレイアウトとが異なっていても、適宜チャンネル毎に修正することができる。図４０（Ａ）に、５．１チャンネルのスピーカレイアウトを示し、図４０（Ｂ）に、７．１チャンネルのスピーカレイアウトを示す。
【０２３３】
上述したように、ｄｅｓｃｒｉｐｔｏｒには、Ｌｅｖｅｌとチャンネルとの関係を記述することができる。
【０２３４】
それだけではなく、図４１の“チャンネル構造”に示すように２チャンネルや５．１チャンネルのダウンミックス音が含まれているか否かをチャンネル数情報として記述してもよい。これにより、各チャンネルに対応するデコーダは、適切に音を出力可能か否か識別することができる。例えば、チャンネル構造が７．１ｃｈ（２＋３．１＋２の階層構造）である場合、２ｃｈ ｄｅｃｏｄｅｒは、２チャンネルの音を出力することができ、５．１ｃｈ ｄｅｃｏｄｅｒは、５．１チャンネル（２＋３．１チャンネル）の音を出力することができる。しかしながら、チャンネル構造がこのような階層構造を伴わない７．１ｃｈである場合、処理量の都合から２ｃｈ ｄｅｃｏｄｅｒおよび５．１ｃｈ ｄｅｃｏｄｅｒは、音を出力することができない可能性がある。
【０２３５】
ＤＴＳのデータは、ＤＴＳ（Ｂａｓｅに相当）およびＤＴＳ＋（Ｌｅｖｅｌ１−ＥＸＴに相当）のデータと、ＤＴＳ＋＋（Ｌｅｖｅｌ２−ＥＸＴに相当）のデータとに分けられる。
【０２３６】
ＤＴＳ＋もＤＴＳ＋＋も、どちらも拡張階層データを含むが、その扱いは異なる。そのため、ｄｅｓｃｒｉｐｔｏｒに、対象ストリームがＤＴＳ／ＤＴＳ＋であるのか、ＤＴＳ＋＋であるのかを識別するための情報（図３８のＬｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅに相当）が含められてもよい。
【０２３７】
なお、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅは、対象ストリームがＤＶＤ−Ｖｉｄｅｏと同様の形式（ＤＴＳ−ｔｙｐｅＩ形式）でＳＰＤＩＦへ出力可能な部分だけを含んでいるのか否かを示す情報として用いられてもよい。
【０２３８】
これら、Ｌｅｖｅｌ２＿ｅｘｉｓｔｅｎｃｅや、ｃｏｄｉｎｇ＿ｌｅｖｅｌの情報は、データベースファイル（図１３のＶＯＢＩファイルのＡｔｔｒｉｂｕｔｅ内など）に記述されてもよい。これらの情報は、ディジタルデータを出力する際の抽出処理が異なることを示すのは勿論であるが、ＢＤのメニュー画面などで映像や音声の属性表示／選択に利用することも可能である。例えば、Ｌｅｖｅｌ２に対応していないプレーヤは、復号対象のストリームがＬｅｖｅｌ２のストリームであることをデータベースから判定し、Ｌｅｖｅｌ２の音声を予め選択不可能としてユーザに供することもできる。
【０２３９】
図４２は、ＢＤ−ＲＯＭなどの光ディスクに記録する際のＭＰＥＧ２−ＴＳのファイルフォーマットを示す図である。
【０２４０】
ＴＳパケット毎に、４バイトのArrival Time Stamp（ＡＴＳ、ＴＳパケットのデコーダへの入力開始時刻情報）が付与されて１つのＴｉｍｅｄ ＴＳパケットが構成され、３２個のＴｉｍｅｄ ＴＳパケットがまとめて３セクタ（６ＫＢ）に記録される。
【０２４１】
図４３は、ＤＶＤ−Ｖｉｄｅｏで規定されるＤＴＳの詳細を説明するための図である。
【０２４２】
ＤＶＤ−Ｖｉｄｅｏでは、１アクセスユニットの最大サイズは２０１３バイトと定めてられているが、これがＤＴＳ／ＤＴＳ＋／ＤＴＳ＋＋の何れに属するかは規定されていない。つまり、４８ＫＨｚで５１２サンプル分の音声情報を表す１アクセスユニットは、ｃｏｒｅのみで構成されていてもよいし、ｃｏｒｅとｅｘｔｅｎｓｉｏｎとから構成されていてもよい。
【０２４３】
最大２０１３バイトの１アクセスユニットはＰＥＳペイロードに格納され、ＰＥＳヘッダ（ＰＥＳｈｄｒ）とパックヘッダ（Ｐａｃｋｈｄｒ）とが付与され、全体のサイズは２ＫＢとなる。
【０２４４】
ＰＥＳペイロードの音声データだけを格納したＤＴＳバーストペイロードが形成され、それに、２バイトずつで計８バイトのプリアンブル群（Ｐａ，Ｐｂ，Ｐｃ，Ｐｄ）と、ｓｔｕｆｆｉｎｇデータとが付与されて、２ＫＢのＩＥＣ６１９３７−５フレームが形成される。
【０２４５】
ＳＰＤＩＦ（ＩＥＣ６０９５８−３）は１９２フレームを１ブロックとした周期で転送される。１フレームは２つのサブフレームから成り、サブフレームはＩＥＣ６１９３７−５フレームの内の２バイトのデータを運ぶ４バイトのデータである。
【０２４６】
従って、ＤＶＤ−Ｖｉｄｅｏと互換性を保つようにＤＴＳのデータを送るには、ＩＥＣ６１９３７−５フレームの内２０１３バイトまでに収まるように、ｃｏｒｅとｅｘｔｅｎｓｉｏｎのビット量を制御すればよい。これにより、データの種類がＤＴＳ／ＤＴＳ＋／ＤＴＳ＋＋の何れであるのかを問う必要はなくなる。
【０２４７】
これが、ＢＤ−ＲＯＭでＤＴＳ＋＋を格納する場合、ｃｏｒｅを含むＰＥＳパケットのペイロード部を２０１３バイト以下の符号化単位とする理由である。
【０２４８】
当然ながらＤＶＤ−Ｖｉｄｅｏと同様に、２０１３バイト以下で１アクセスユニットを構成するフレームが完結している必要がある。例えば、ＢａｓｅフレームとＬｅｖｅｌ１−ＥＸＴフレームのサイズが２０１４バイトであるならば、全体が２０１３バイトに収まるように再エンコードするか、ＢａｓｅフレームだけのＰＥＳパケットを構成し、Ｌｅｖｅｌ１−ＥＸＴは多重化順序が次のＰＥＳパケットに格納するなどとする必要がある。
【０２４９】
図４４は、デマルチプレクサ３１０（図７）、および、ストリーム読込／供給部（図３４）の処理を示すフローチャートである。
【０２５０】
Ｓ８０１は、ＳＰＤＩＦに対応するために、図３６に示すアクセスユニットの一部を抽出して外部に出力するディジタル出力開始ステップである。
【０２５１】
Ｓ８０２は再生終了判定ステップであり、ＹＥＳの場合、データの出力を終了し、ＮＯの場合、ＰＥＳパケットの処理Ｓ８０３へ進む。
【０２５２】
Ｓ８０３では、ＰＩＤによるＴＳパケットの弁別と、ＰＥＳパケットのヘッダの解析と、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎの読み出しとを行う。
【０２５３】
Ｓ８０４では、ｓｔｒｅａｍ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎを判定する。そのフィールドの値が、“０ｘ７１（非Ｂａｓｅフレーム部）”である場合はＳ８０５へ進み、“０ｘ７０（Ｂａｓｅフレーム部）”である場合はＳ８０６へ進む。
【０２５４】
Ｓ８０５は、Ｓ８０４で、ＰＥＳパケットが非Ｂａｓｅフレーム部であると判定された場合に行われるステップであり、Ｓ８０５ではＰＥＳパケットを破棄する。
【０２５５】
Ｓ８０６は、Ｓ８０４で、ＰＥＳパケットがＢａｓｅフレーム部であると判定された場合に行われるステップである。Ｓ８０６では、ＰＥＳパケットのペイロード（Ｂａｓｅ＋Ｌｅｖｅｌ１−ＥＸＴ）を取り出し、図７および図３４を用いて説明したとおり、フレームデータをデコーダまたは既存ディジタルＩ／Ｆへ出力する。
【０２５６】
Ｓ８０５およびＳ８０６の後に、再生終了判定ステップＳ８０２へと戻る。
【０２５７】
次に、既存のプレーヤやデコーダで復号可能なＢａｓｅ／Ｌｅｖｅｌ１−ＥＸＴ（以下、単に“Ｂａｓｅ”という）と、既存のプレーヤやデコーダでは復号不可能なＬｅｖｅｌ２−ＥＸＴ（以下、単に“Ｌｅｖｅｌ２”という）とを１個のアクセスユニットに多重化する方法を説明する。
【０２５８】
先ず、図４５を用いて、入力時刻管理装置２０００と、ＴＳ ｓｙｓｔｅｍ ｔａｒｇｅｔ ｄｅｃｏｄｅｒ ｍｏｄｅｌ（以下、“デコーダモデル”または“Ｔ−ＳＴＤ”という）３０００とを説明する。
【０２５９】
図４５に示すように、入力時刻管理装置２０００は、リードバッファ（ＲＢ）と、ｄｅ−ｐａｃｋｅｔｉｚｅｒと、ＡＴＳ Ｃｏｕｎｔｅｒと、２７ＭＨｚ Ｃｌｏｃｋとを有する。ＲＢは、“ｘｘｘｘ．ｖｏｂ”ファイルを一時的に蓄積する。ｄｅ−ｐａｃｋｅｔｉｚｅｒは、“ｘｘｘｘ．ｖｏｂ”のＴＳパケットからＡＴＳを除去し、最初のＴＳパケットからＡＴＳを除去するとき、最初のＴＳパケットのＡＴＳの値を、ＡＴＳ Ｃｏｕｎｔｅｒにセットする。また、ｄｅ−ｐａｃｋｅｔｉｚｅｒは、ＡＴＳの時刻通りに各ＴＳパケットのみをＴ−ＳＴＤ３０００に出力する。２７ＭＨｚ Ｃｌｏｃｋは、２７ＭＨｚでクロックを出力する。
【０２６０】
図４５に示すように、デコーダモデル３０００は、デマルチプレクサと、画像に関するバッファであるＴＢ、ＭＢ、およびＥＢと、デコーダＤｖと、音データのＢａｓｅに関するバッファであるＴＢａ１およびＢａ１と、デコーダＤａ１と、音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」に関するバッファであるＴＢａ２およびＢａ２と、デコーダＤａ２と、システムデータに関するバッファであるＴＢｓｙｓおよびＢｓｙｓと、デコーダＤｓｙｓとを有する。
【０２６１】
画像データは、ＴＢ、ＭＢ、ＥＢ、およびデコーダＤｖの順に処理される。音データのＢａｓｅは、ＴＢａ１、Ｂａ１、およびデコーダＤａ１の順に処理される。音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」は、ＴＢａ２、Ｂａ２、およびデコーダＤａ２の順に処理される。システムデータは、ＴＢｓｙｓ、Ｂｓｙｓ、およびデコーダＤｓｙｓの順に処理される。
【０２６２】
音データのＢａｓｅがデコードされるラインと、音データの「Ｂａｓｅ＋Ｌｅｖｅｌ２」がデコードされるラインとでは、夫々のストリームの属性に応じてバッファ間のデータの転送レートや、バッファのサイズなどデコーダの仕様が異なる。従って、両方の仕様に対応するように、ＢａｓｅとＬｅｖｅｌ２とを多重化しなければならない。Ｂａｓｅのみをデコードする場合、そのデコーダライン（ＴＢａ１、Ｂａ１、およびデコーダＤａ１）で、バッファを破綻させずにＢａｓｅのみをデコードすることができなければならない。「Ｂａｓｅ＋Ｌｅｖｅｌ２」をデコードする場合、そのデコーダライン（ＴＢａ２、Ｂａ２、およびデコーダＤａ２）で、バッファを破綻させずに「Ｂａｓｅ＋Ｌｅｖｅｌ２」をデコードすることができなければならない。つまり、Ｂａｓｅのデコーダライン（ＴＢａ１、Ｂａ１、およびデコーダＤａ１）でも、「Ｂａｓｅ＋Ｌｅｖｅｌ２」のデコーダライン（ＴＢａ２、Ｂａ２、およびデコーダＤａ２）でも、バッファを破綻させないように、ＢａｓｅとＬｅｖｅｌ２とを１本のストリームとして同一ＰＩＤにて多重化しなければならない。
【０２６３】
図４６を用いて、Ｂａｓｅと、「Ｂａｓｅ＋Ｌｅｖｅｌ２」とをそれぞれのデコーダラインでデコードする際の、ＴＢａ１およびＴＢａ２のデータ蓄積量の推移を説明する。
【０２６４】
ＴＢａ１については、ｎ番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ）のＢａｓｅ（Ｂａｓｅ＃ｎ）が、時刻ＡＴＳ＿ｂ＃ｎからビットレート（ＲTS）で入力して蓄積されると同時にＲｂａ１のレートでＢａ１へと引き抜かれる。Ｂａｓｅ＃ｎの入力が終了すると、蓄積データ量は一定のビットレート（−Ｒｂａ１）で減少する。（ｎ＋１）番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ＋１）のＢａｓｅ（Ｂａｓｅ＃ｎ＋１）が、時刻ＡＴＳ＿ｂ＃ｎ＋１からビットレート（ＲTS）で入力して蓄積する。図４６では、Ｂａｓｅ＃ｎ＋１の入力が終了するまでに、ＴＢａ１はオーバーフローする。つまり、バッファは破綻する。以降同様の処理が続く。
【０２６５】
ＴＢａ２については、ｎ番目のアクセスユニット（Ａｃｃｅｓｓ Ｕｎｉｔ＃ｎ）のＢａｓｅ（Ｂａｓｅ＃ｎ）が、時刻ＡＴＳ＿ｂ＃ｎからビットレート（ＲTS）で入力して蓄積されると同時にＲｂａ１のレートでＢａ２へと引き抜かれる。Ｂａｓｅ＃ｎの入力が終了すると、蓄積データ量は一定のビットレート（−Ｒｂａ２）で減少する。そして、ｎ番目のアクセスユニットの２個のＬｅｖｅｌ２（Ｌｅｖｅｌ２＃ｎ）が、入力され蓄積する。入力が無い期間のＴＢａ２の蓄積データ量はビットレート（−Ｒｂａ２）で減少する。以降同様の処理が続く。図４６では、ＴＢａ２はオーバーフローしない。つまり、バッファは破綻しない。
【０２６６】
図４６の場合、Ｂａｓｅ＃ｎのみに対応するデコーダラインは、１個のアクセスユニットが１つのＰＥＳパケットに格納されるＢａｓｅと、Ｌｅｖｅｌ１とから構成されているストリームしかデコードすることができず、Ｌｅｖｅｌ２を含むような高ビットレートのストリームは処理できない。このように低ビットレートしか対応できないＴＢａ１を破綻させないためには、ＴＢａ１へのＢａｓｅ＃ｎ＋１の入力時刻を遅らせる必要がある。つまり、下記の式３が満たされなければならない。
【０２６７】
ＴＢａ１（ＡＴＳ＿ｂ＃ｎ＋１）＋１８８×（１−Ｒｂａ１／ＲTS）
≦ＴＢａ１のサイズ＝５１２ （式３）
【０２６８】
式３は、時刻ＡＴＳ＿ｂ＃ｎ＋１におけるＴＢａ１のデータ蓄積量に、１つのＴＳパケットを入力する際に増加するバイト量（１８８×（１−Ｒｂａ１／ＲTS））が加算されても、ＴＢａ１のサイズを超えないことを意味する。式３を満たす時刻ＡＴＳ＿ｂ＃ｎ＋１以降に、Ｂａｓｅ＃ｎ＋１を多重化するように、ＡＴＳを設定し、ストリームにＢａｓｅ＃ｎ＋１を多重化しなければならない。
【０２６９】
さらに、Ｂａｓｅ（１つ目のＰＥＳパケット）が格納されるＴＳパケットの数をＮｂａｓとし、Ｌｅｖｅｌ２（２つ目のＰＥＳパケット）が格納されるＴＳパケットの数をＮｅｘｔとすると、ＢａｓｅとＬｅｖｅｌ２とをデコード順に転送するためには、下記の式４が満たされなければならない。
【０２７０】
[（Ｎｂａｓ＋Ｎｅｘｔ）×１８８×８／ＲTS]×２７００００００
≦ ＡＴＳ＿ｂ＃（ｎ＋１）− ＡＴＳ＿ｂ＃ｎ （式４）
【０２７１】
ここで、ビットレートＲｂａ１，ＲTSの単位は、ｂｉｔｓ／ｓｅｃｏｎｄであり、２７００００００はＡＴＳの時刻精度のクロック周波数を意味する。Ｎｂａｓ，Ｎｅｘｔの値は、夫々のＣｏｄｅｃの最大ビットレートなどの情報から算出することができる。
【０２７２】
例えば、ＤＴＳ＋＋の場合、サンプリング周波数が４８ＫＨｚで、５１２サンプル／Ａｃｃｅｓｓ Ｕｎｉｔ（ＤＴＳ＿ｔｙｐｅ１）でＣｏｒｅ（Ｂａｓｅ）が１Ｍｂｐｓの固定レート、ＸＬＬ（Ｌｅｖｅｌ２）が単独で２４Ｍｂｐｓであるとすると、ＸＬＬのデータ長＝２４Ｍｂｐｓ×５１２／４８Ｋ＝３２０００ｂｙｔｅｓとなる。これを格納するには、ＴＳ／ＰＥＳヘッダのオーバーヘッドも含めて、１７４個のＴＳパケットが必要となる。
【０２７３】
上記の式３および４が満たされるように、多重化処理は行われなければならず、ＢａｓｅおよびＬｅｖｅｌ２を含むＴＳパケットに適切なＡＴＳを付加し、多重化する。これにより、バッファは破綻しない。
【０２７４】
なお、バッファは、データがオーバーフローする場合だけでなく、アンダーフローする場合にも破綻する。データがアンダーフローしないように、ＢａｓｅとＬｅｖｅｌ２とを多重化しなければならない。そのため、データがオーバーフローすることを防止する場合と同様に、バッファのサイズ、バッファへ入力するデータのサイズ、バッファへ入力するデータの速度、および、バッファから出力するデータの速度に基づいて、データがアンダーフローしないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する。
【０２７５】
要するに、各デコーダモデルにおいて、バッファのサイズ、バッファへ入力するデータのサイズ、バッファへ入力するデータの速度、および、バッファから出力するデータの速度を考慮して、各デコーダモデルが破綻しないように、ＢａｓｅとＬｅｖｅｌ２とを多重化する。
【産業上の利用可能性】
【０２７６】
本発明の情報記録媒体は、映像や音声のデータが記録される光ディスク等として有用である。本発明のデータ分別装置は、光ディスク等の本発明の情報記録媒体に記録されているデータから、既存のデコーダまたは、既存のディジタルＩ／Ｆに対応する基礎圧縮データを抜き出す装置等として有用である。本発明のデータ再生装置は、光ディスク等の本発明の情報記録媒体から上記基礎圧縮データを抜き出して再生する装置等として有用である。本発明のデータ再生装置は、光ディスク等の本発明の情報記録媒体からのデータに限らず、放送やネットワークを通して供給されるオーディオデータや、ハードディスクや半導体メモリなどの記録メディア上のオーディオデータを再生する再生装置などにも有用である。
【符号の説明】
【０２７７】
２０１ ＢＤディスク
２０２ 光ピックアップ
２０３ プログラム記録メモリ
２０４ 管理情報記録メモリ
２０５ ＡＶ記録メモリ
２０６ プログラム処理部
２０７ 管理情報処理部
２０８ プレゼンテーション処理部
２０９ イメージプレーン
２１０ ビデオプレーン
２１１ 合成処理部
３０１ プログラム記録メモリ
３０２ プログラムプロセッサ
３０３ ＵＯＰマネージャ
３０４ 管理情報記録メモリ
３０５ シナリオプロセッサ
３０６ プレゼンテーションコントローラ
３０７ クロック
３０８ イメージメモリ
３０９ トラックバッファ
３１０ デマルチプレクサ
３１１ イメージプロセッサ
３１２ ビデオプロセッサ
３１３ サウンドプロセッサ
３１４ イメージプレーン
３１５ ビデオプレーン
３１６ 合成処理部
３１７ ドライブコントローラ
【特許請求の範囲】
【請求項１】
複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、
前記アクセスユニットは、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、
前記基本データは、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データは、前記基本データから生成されるデータの質を向上させるためのデータであり、
前記ストリームは、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する
情報記録媒体。
【請求項２】
前記情報は、前記ストリームのｄｅｓｃｒｉｐｔｏｒに記述されている
請求項１記載の情報記録媒体。
【請求項３】
前記アクセスユニットは、音に関するデータであって、
前記属性は、チャンネル、周波数、ビットレート、及び、２チャンネルのダウンミックスデータの存在の有無、の少なくとも一つを特定する
請求項１記載の情報記録媒体。
【請求項４】
各前記アクセスユニットは一定時間のデータである
請求項１記載の情報記録媒体。
【請求項５】
前記情報は、前記ストリームのＰｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ（ＰＭＴ）に記述されている
請求項１記載の情報記録媒体。
【請求項６】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得する取得手段と、
前記情報を用いて、前記アクセスユニットを再生する再生手段と
を備えるデータ再生装置。
【請求項７】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得し、
前記情報を用いて、前記アクセスユニットを再生する
データ再生方法。
【請求項８】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得し、
前記情報を用いて、前記アクセスユニットを再生する
ことをコンピュータに実行させるためのプログラム。
【請求項９】
情報記録媒体への記録方法であって、
複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームを情報記録媒体に記録するステップを含み、
前記記録するステップでは、
前記アクセスユニットが、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、
前記基本データが、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データが、前記基本データから生成されるデータの質を向上させるためのデータであり、
前記ストリームが、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する
ように、前記ストリームを前記情報記録媒体に記録する記録方法。
【請求項１】
複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームが記録される情報記録媒体であって、
前記アクセスユニットは、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、
前記基本データは、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データは、前記基本データから生成されるデータの質を向上させるためのデータであり、
前記ストリームは、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する
情報記録媒体。
【請求項２】
前記情報は、前記ストリームのｄｅｓｃｒｉｐｔｏｒに記述されている
請求項１記載の情報記録媒体。
【請求項３】
前記アクセスユニットは、音に関するデータであって、
前記属性は、チャンネル、周波数、ビットレート、及び、２チャンネルのダウンミックスデータの存在の有無、の少なくとも一つを特定する
請求項１記載の情報記録媒体。
【請求項４】
各前記アクセスユニットは一定時間のデータである
請求項１記載の情報記録媒体。
【請求項５】
前記情報は、前記ストリームのＰｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ（ＰＭＴ）に記述されている
請求項１記載の情報記録媒体。
【請求項６】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得する取得手段と、
前記情報を用いて、前記アクセスユニットを再生する再生手段と
を備えるデータ再生装置。
【請求項７】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得し、
前記情報を用いて、前記アクセスユニットを再生する
データ再生方法。
【請求項８】
請求項１記載の情報記録媒体に記録されている前記アクセスユニット、及び前記情報を取得し、
前記情報を用いて、前記アクセスユニットを再生する
ことをコンピュータに実行させるためのプログラム。
【請求項９】
情報記録媒体への記録方法であって、
複数のアクセスユニットを有する、画像及び音の少なくとも一方を含むストリームを情報記録媒体に記録するステップを含み、
前記記録するステップでは、
前記アクセスユニットが、基本データを含む第１のパケットと、前記基本データと関連する拡張データを含む第２のパケットとを有し、
前記基本データが、前記拡張データを必要とすることなく完全な状態に復号することができるデータであり、前記拡張データが、前記基本データから生成されるデータの質を向上させるためのデータであり、
前記ストリームが、前記第１のパケット及び前記第２のパケットの属性を示す情報を有する
ように、前記ストリームを前記情報記録媒体に記録する記録方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【公開番号】特開２０１０−２２５２６４（Ｐ２０１０−２２５２６４Ａ）
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願番号】特願２０１０−９４４１８（Ｐ２０１０−９４４１８）
【出願日】平成２２年４月１５日（２０１０．４．１５）
【分割の表示】特願２００６−５３１８１６（Ｐ２００６−５３１８１６）の分割
【原出願日】平成１７年８月１７日（２００５．８．１７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願日】平成２２年４月１５日（２０１０．４．１５）
【分割の表示】特願２００６−５３１８１６（Ｐ２００６−５３１８１６）の分割
【原出願日】平成１７年８月１７日（２００５．８．１７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]