(57)【要約】【課題】さらなる改善を実現することができる再生方法を提供する。【解決手段】システムストリームファイルを再生する再生装置による再生方法であって、システムストリームファイルを読み出し、再生するシステムストリームファイルが第１のファイル形式を有する第１のシステムストリームファイルであるか、第２のファイル形式を有する第２のシステムストリームファイルであるかを判定し、再生するシステムストリームファイルが第１のシステムストリームファイルである場合に、読み出されたシステムストリームファイルのファイル形式を第１のファイル形式から第２のファイル形式に変換し、第２のファイル形式を有するシステムストリームファイルを復号する。【選択図】図３３
2020119623.tif 000002
【特許請求の範囲】
【請求項１】
システムストリームファイルを再生する再生装置による再生方法であって、
前記システムストリームファイルを読み出し、
再生する前記システムストリームファイルが第１のファイル形式を有する第１のシステムストリームファイルであるか、第２のファイル形式を有する第２のシステムストリームファイルであるかを判定し、
再生する前記システムストリームファイルが前記第１のシステムストリームファイルである場合に、読み出された前記システムストリームファイルのファイル形式を前記第１のファイル形式から前記第２のファイル形式に変換し、
前記第２のファイル形式を有する前記システムストリームファイルを復号する、
再生方法。
【請求項２】
システムストリームファイルを再生する再生装置であって、
前記システムストリームファイルを読み出す読み出し部と、
再生する前記システムストリームファイルが第１のファイル形式を有する第１のシステムストリームファイルであるか、第２のファイル形式を有する第２のシステムストリームファイルであるかを判定する判定部と、
再生する前記システムストリームファイルが前記第１のシステムストリームファイルである場合に、読み出された前記システムストリームファイルのファイル形式を前記第１のファイル形式から前記第２のファイル形式に変換する変換部と、
前記第２のファイル形式を有する前記システムストリームファイルを復号する復号部と、を備える、
再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、暗号化された映像情報を含むシステムストリームファイルを再生する再生方法及びその再生装置、当該システムストリームファイルを記録した記録媒体に関する。
【背景技術】
【０００２】
従来、ＤＶＤに関する技術が開示されている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−２８２８４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献では、更なる改善が必要とされていた。
【課題を解決するための手段】
【０００５】
本開示の一態様に係る再生方法は、システムストリームファイルを再生する再生装置による再生方法であって、前記システムストリームファイルを読み出し、再生する前記システムストリームファイルが第１のファイル形式を有する第１のシステムストリームファイルであるか、第２のファイル形式を有する第２のシステムストリームファイルであるかを判定し、再生する前記システムストリームファイルが前記第１のシステムストリームファイルである場合に、読み出された前記システムストリームファイルのファイル形式を前記第１のファイル形式から前記第２のファイル形式に変換し、前記第２のファイル形式を有する前記システムストリームファイルを復号する。
【０００６】
本開示の一態様に係る再生方法は、暗号化された映像情報を含むシステムストリームファイルを再生する再生装置による再生方法であって、前記システムストリームファイルは、前記再生装置が個別に有する第一の復号鍵を用いて復号できる第一のデータ単位と、前記第一のデータ単位と同じデータサイズの第二のデータ単位であって、当該第一の復号鍵で復号できない第二のデータ単位とを繰り返す第一の区間と、前記再生装置が他の再生装置と共通して有する第二の復号鍵を用いて復号可能な第二の区間と、を有し、前記再生方法は、前記システムストリームファイルを読み出し、読み出した前記システムストリームファイルのうちの、前記第一の区間の前記第二のデータ単位を連続した複数の無効なパケットに置き換えたシステムストリームへ変換する変換処理を行い、変換後のシステムストリームを出力する。
【発明の効果】
【０００７】
上記態様によれば、更なる改善を実現することができる。
【図面の簡単な説明】
【０００８】
【図１】ＳＤ−ＤＶＤの構造を示す図である。
【図２】ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。
【図３】ＤＶＤにおけるＶＯＢの構成を示す概要図である。
【図４】ＢＤ−ＲＯＭのデータ階層を示す図である。
【図５】ＢＤ−ＲＯＭに記録されている論理データの構造を示す図である。
【図６】ＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。
【図７】図６に示すプレーヤの構成を詳細化したブロック図である。
【図８】ＢＤ−ＲＯＭのアプリケーション空間を示す図である。
【図９】ＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。
【図１０】ＭＰＥＧストリームにおけるパックの構成を示す図である。
【図１１】ＡＶデータとプレーヤ構成との関係を説明するための図である。
【図１２】トラックバッファを使ったＶＯＢデータ連続供給モデルを説明するための図である。
【図１３】ＶＯＢ管理情報ファイルの内部構造を示す図である。
【図１４】ＶＯＢＵ情報の詳細を説明するための図である。
【図１５】タイムマップを使ったアドレス情報取得方法を説明するための図である。
【図１６】プレイリストの構成を示す図である。
【図１７】イベントハンドラテーブルの構成を示す図である。
【図１８】ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。
【図１９】グローバルイベントハンドラテーブルの構成を示す図である。
【図２０】タイムイベントの例を示す図である。
【図２１】ユーザのメニュー操作によるユーザイベントの例を示す図である。
【図２２】グローバルイベントの例を示す図である。
【図２３】プログラムプロセッサの機能的な構成を説明するための図である。
【図２４】システムパラメータ（ＳＰＲＭ）の一覧を示す図である。
【図２５】２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。
【図２６】メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。
【図２７】ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフローチャートである。
【図２８】ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフローチャートである。
【図２９】図２９の（Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフローチャートであり、図２９の（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフローチャートである。
【図３０】ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフローチャートである。
【図３１】Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃにて使われているシステムストリームの記録フォーマットを説明するための図である。
【図３２】新しい暗号化処理を施したシステムストリームの記録フォーマットを説明するための図である。
【図３３】新たなプレーヤのシステム構成を説明するための図である。
【図３４】コンバータによりｓｃｔｓファイルをｍ２ｔｓファイルに変換する例を示す図である。
【図３５】復号できない方のＡｌｉｇｎｅｄ  ｕｎｉｔのデータを３２個の連続なＮＵＬＬパケットに置き換える際に各ＮＵＬＬパケットに付与するＩｎｐｕｔ  Ｔｉｍｅの値について説明するための図である。
【図３６】特殊再生におけるパフォーマンスを担保するための多重化制約について説明するための図である。
【図３７】情報記録媒体が光ディスクの場合の追加実施例を説明するための図である。
【発明を実施するための形態】
【０００９】
（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、ＤＶＤなどの記録媒体に関し、以下の問題が生じることを見出した。
【００１０】
映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、「Ｓｔａｎｄａｒｄ  Ｄｉｆｉｎｉｔｉｏｎ（ＳＤ）−ＤＶＤ」ともいう。）である。以下に従来のＤＶＤについて説明する。
【００１１】
図１は、ＳＤ−ＤＶＤの構造を示す図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられている。その論理アドレス空間には先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
【００１２】
ファイルシステムとは、ＩＳＯ９６６０やＵｎｉｖｅｒｓａｌ  Ｄｉｓｋ  Ｆｏｒｍａｔ（ＵＤＦ）等の規格により定められたデータを管理する仕組みのことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。
【００１３】
日常使っているパーソナルコンピュータ（ＰＣ）の場合でも、Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ（ＦＡＴ）またはＮＴ  Ｆｉｌｅ  Ｓｙｓｔｅｍ（ＮＴＦＳ）と呼ばれるファイルシステムにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。
【００１４】
ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０の両方のファイルシステムが使用されている。両方を合わせて「ＵＤＦブリッジ」とも呼ばれる。記録されているデータはＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。なお、ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である。
【００１５】
ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図１における「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下の種類のファイルがある。
【００１６】
ＶＩＤＥＯ＿ＴＳ．ＩＦＯ    ディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯ    ビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢ    ビデオタイトルセット＃１ストリームファイル
．．．．．
【００１７】
上記例に示すように２つの拡張子が規定されている。「ＩＦＯ」は再生制御情報が記録されたファイルであることを示す拡張子であり、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルであることを示す拡張子である。
【００１８】
再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのような、ＡＶデータに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
【００１９】
再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。なお、ＤＶＤでは複数のタイトル、言い換えれば複数の異なる映画や楽曲を１枚のディスクに記録することが可能である。
【００２０】
ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。
【００２１】
図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＩＤＥＯ  Ｍａｎａｇｅｒ  Ｉｎｆｏｒｍａｔｉｏｎ（ＶＭＧＩ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶｉｄｅｏ  Ｔｉｔｌｅ  Ｓｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ（ＶＴＳＩ）としてＤＶＤナビゲーション空間に展開される。
【００２２】
ＶＴＳＩの中にはＰｒｏｇｒａｍ  Ｃｈａｉｎ（ＰＧＣ）と呼ばれる再生シーケンスの情報であるＰｒｏｇｒａｍ  Ｃｈａｉｎ  Ｉｎｆｏｒｍａｔｉｏｎ（ＰＧＣＩ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。
【００２３】
Ｃｅｌｌ自身はＶＯＢ（Ｖｉｄｅｏ  Ｏｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間を指定する情報であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。
【００２４】
コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、例えば、ウェブページを表示するブラウザ上で実行されるＪａｖａ（登録商標）Ｓｃｒｉｐｔなどに近いものである。しかしながらＪａｖａ（登録商標）Ｓｃｒｉｐｔが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドウを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプターの指定などを実行するだけのものである点で異なっている。
【００２５】
Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
【００２６】
図２は、ＡＶデータであるＭＰＥＧストリーム中に埋め込まれているナビゲーション情報を説明する概要図である。
【００２７】
ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫという。）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。
【００２８】
ここでは簡単なインタラクティビティの例としてメニュー画面について説明する。メニュー画面上には、幾つかのボタンが現れ、それぞれのボタンには当該ボタンが選択実行された時の処理が定義されている。
【００２９】
また、メニュー画面上では一つのボタンが選択されており（選択ボタン上に半透明色がオーバーレイされることで該ボタンがハイライトされ、該ボタンが選択状態であることをユーザに示す）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。
【００３０】
リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプターの再生がコマンドによって実行されている。
【００３１】
図２の左上部はＮＶ＿ＰＣＫに格納される情報の概要を示している。ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。
【００３２】
ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作それぞれに対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）とが記述されている。
【００３３】
メニュー画面上のハイライトは、図２の右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色を付した物である。このオーバーレイ画像は図２の右部に示す背景画像と合成されて画面上に表示される。
【００３４】
前述のようにして、ＤＶＤではメニュー画面を実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのかについては、以下の理由からである。
【００３５】
すなわち、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニュー画面を表示するといった、同期タイミングが問題となりやすい処理を問題なく実現できるようにするためである。
【００３６】
また、もう一つの大きな理由は、ＮＶ＿ＰＣＫには特殊再生を支援するための情報を格納し、ＤＶＤ再生時の早送り、巻き戻しなどの非通常再生時にも円滑にＡＶデータをデコードし再生させる等、ユーザの操作性を向上させるためである。
【００３７】
図３は、ＤＶＤにおけるＶＯＢの構成を示す概要図である。図に示すように、映像、音声、字幕などのデータ（図３の（１））は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（図３の（２））、それぞれを多重化して１本のＭＰＥＧプログラムストリームにしている（図３の（３））。
【００３８】
また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。
【００３９】
ＭＰＥＧシステムの多重化の特徴として、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではないことが挙げられる。
【００４０】
これはＭＰＥＧシステムストリームのデコーダモデル（図３の（４）、一般にＳｙｓｔｅｍ  Ｔａｒｇｅｔ  Ｄｅｃｏｄｅｒ、またはＳＴＤと呼ばれる）が多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。
【００４１】
このデコーダバッファは、個々のエレメンタリストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢをそれぞれ有している。
【００４２】
このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。
【００４３】
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
【００４４】
以上述べたようなＤＶＤに関する技術は、特許文献１に記載されている。
【００４５】
ところで、ブルーレイディスク（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ（ＢＤ））のような大容量記録メディアにおいては、非常に高品位な映像情報を格納できる可能性がある。例えば、４Ｋ（３８４０ｘ２１６０ピクセルの解像度を持つ映像情報）やＨＤＲ（Ｈｉｇｈ  Ｄｙｎａｍｉｃ  Ｒａｎｇｅと一般に呼ばれる高輝度映像情報）などが考えられる。
【００４６】
これらの高品位なコンテンツが不正利用されないために、不正流出元となった再生装置を特定するための暗号技術が考えられている。しかし、複雑な暗号技術のために不必要に復号処理が難しく、時間がかかるものとなり、結果的に再生装置の挙動が遅くなったり、著しい価格上昇に繋がるようなことがあっては、多くの善良な消費者のためにならない。
【００４７】
つまり、不正利用を防止する暗号技術は十分な暗号強度と、再生装置への実装負担及びレスポンス低下とを上手くバランスとった形で導入しなければ多くの消費者にとって不利益にしかならないという課題がある。
【００４８】
以上の検討を踏まえ、本発明者は、上記課題を解決するために、下記の改善策を検討した。
【００４９】
本開示の一態様に係る再生方法は、暗号化された映像情報を含むシステムストリームファイルを再生する再生装置による再生方法であって、前記システムストリームファイルは、前記再生装置が個別に有する第一の復号鍵を用いて復号できる第一のデータ単位と、前記第一のデータ単位と同じデータサイズの第二のデータ単位であって、当該第一の復号鍵で復号できない第二のデータ単位とを繰り返す第一の区間と、前記再生装置が他の再生装置と共通して有する第二の復号鍵を用いて復号可能な第二の区間と、を有し、前記再生方法は、前記システムストリームファイルを読み出し、読み出した前記システムストリームファイルのうちの、前記第一の区間の前記第二のデータ単位を連続した複数の無効なパケットに置き換えたシステムストリームへ変換する変換処理を行い、変換後のシステムストリームを出力する。
【００５０】
これによれば、新たな暗号技術が導入された、記録フォーマットが異なるシステムストリームファイルを再生する場合であっても、従来のデコーダの構成を設計変更せずにそのまま利用できるため、プレーヤの実装負担やコスト上昇を抑えることができる。
【００５１】
また、例えば、前記第二のデータ単位は、３２個のソースパケットから構成され、前記変換処理では、前記第二のデータ単位を構成している前記３２個のソースパケットを、前記複数の無効なパケットとしての３２個のＮＵＬＬパケットに置き換えてもよい。
【００５２】
これによれば、３２個のソースパケットを同じ３２個のＮＵＬＬパケットで置き換えるため、復号できる第一のデータ単位を構成する複数のソースパケットの位置を変換処理の前後において同一の位置に配置できる。このため、アドレス計算の再計算を行わなくても第一のデータ単位の再生を行うことができ、処理負荷を低減できる。
【００５３】
また、例えば、前記変換処理では、前記第一の区間を前記第一の復号鍵を用いて復号し、かつ、前記第二の区間を前記第二の復号鍵を用いて復号することにより、前記システムストリームファイルをｍ２ｔｓ形式のシステムストリームに変換してもよい。
【００５４】
また、例えば、前記システムストリームファイルは、前記第一の区間及び前記第二の区間を有する第一のシステムストリームファイルと、ｍ２ｔｓ形式の第二のシステムストリームファイルとの少なくとも一方を有し、前記出力では、読み出した前記システムストリームファイルの拡張子がｍ２ｔｓ形式を示すか否かに応じて、当該システムストリームファイルが前記第一のシステムストリームファイルであるか、前記第二のシステムストリームファイルであるかを判定し、前記判定の結果、読み出した前記システムストリームファイルが前記第一のシステムストリームファイルである場合、前記変換処理を行うことにより得られたｍ２ｔｓ形式のシステムストリームを出力し、前記判定の結果、読み出した前記システムストリームファイルが前記第二のシステムストリームファイルである場合、前記変換処理を行わずにシステムストリームを出力してもよい。
【００５５】
これによれば、システムファイルストリームの拡張子に応じて、変換処理の切り替えを行っているため、容易に切り替えを行うことができる。
【００５６】
また、例えば、前記システムストリームファイルは、複数のソースパケットから構成され、前記複数のソースパケットのそれぞれは、前記再生装置が備えるシステムターゲットデコーダへの入力時刻を示すタイムスタンプを有し、前記変換処理では、前記複数の無効なパケットのそれぞれに、前記システムターゲットデコーダへの入力時刻を示すタイムスタンプを付与してもよい。
【００５７】
これによれば、変換処理において置き換えた複数の無効なパケットのそれぞれにタイムスタンプを付与するため、変換処理後のシステムストリームファイルを適切に処理できる。
【００５８】
また、例えば、前記変換処理では、前記複数の無効なパケットのそれぞれに、当該無効なパケットを転送する転送レートが前記システムストリームファイルの最大転送レート以下であることを満たす前記タイムスタンプを付与してもよい。
【００５９】
また、例えば、前記変換処理では、一の前記第二のデータ単位において置き換えた前記複数の無効なパケットのうちの最後の前記無効なパケットに、当該一の第二のデータ単位の直後のＴＳパケットの前記タイムスタンプよりも、１つのＴＳパケットを前記システムストリームファイルの最大転送レートで転送するのに要する時間以上前の時刻であることを満たす前記タイムスタンプを付与してもよい。
【００６０】
また、例えば、前記システムストリームファイルは、当該システムストリームファイルに対応する管理情報を記録した管理情報ファイルとでＡＶ（Ａｕｄｉｏ  Ｖｉｓｕａｌ）データを構成し、前記管理情報ファイルは、ランダムアクセスポイントとなるＩピクチャの提示時刻を示すタイムマップを有し、前記タイムマップにおいて前記提示時刻が示される全てのＩピクチャは、前記第二の区間において多重化されており、前記出力では、前記全てのＩピクチャを、前記第二の復号鍵を用いて復号することにより、前記システムストリームファイルをｍ２ｔｓ形式のシステムストリームに変換してもよい。
【００６１】
これによれば、ランダムアクセスポイントとなる全てのＩピクチャは、第二の区間において多重化されているため、第二の復号鍵のみを用いて復号できる。これにより、当該Ｉピクチャの復号に復号鍵を切り替える処理を行わなくても済むため、特殊再生時のレスポンスが遅くなることを低減できる。
【００６２】
本開示の一態様に係る記録媒体は、ＡＶデータを記録した記録媒体であって、前記ＡＶデータは、暗号化された映像情報を含むシステムストリームファイルと、当該システムストリームファイルに対応する管理情報を記録した管理情報ファイルとを有し、前記システムストリームファイルは、前記記録媒体に記録された前記ＡＶデータを再生する再生装置が個別に有する第一の復号鍵を用いて復号できる第一のデータ単位と、前記第一のデータ単位と同じデータサイズの第二のデータ単位であって、当該第一の復号鍵で復号できない第二のデータ単位とを繰り返す第一の区間と、前記再生装置が他の再生装置と共通して有する第二の復号鍵を用いて復号可能な第二の区間と、を有し、前記管理情報ファイルは、ランダムアクセスポイントとなるＩピクチャと、当該Ｉピクチャの提示時刻とが対応づけられたタイムマップを有し、前記タイムマップにおいて前記提示時刻が示されるＩピクチャは、前記第二の区間において多重化されている。
【００６３】
これによれば、ランダムアクセスポイントとなる全てのＩピクチャは、第二の区間において多重化されているため、再生装置は、第二の復号鍵のみを用いて復号できる。これにより、当該Ｉピクチャの復号に復号鍵を切り替える処理を行わなくても済むため、特殊再生時のレスポンスが遅くなることを低減できる。
【００６４】
また、例えば、前記タイムマップでは、さらに、前記Ｉピクチャが格納されている複数のソースパケットのうちの先頭のソースパケットを特定する先頭ソースパケット番号が対応づけられており、前記先頭ソースパケット番号で特定される前記先頭のソースパケットは、前記第二の区間に配置されていてもよい。
【００６５】
また、例えば、前記タイムマップでは、さらに、前記先頭のソースパケットからのパケット数であって、前記Ｉピクチャが格納されている複数のソースパケットが含まれることが保証されるパケット数を段階的に示す最終位置情報が対応づけられており、前記先頭のソースパケットから、前記先頭ソースパケット番号及び前記最終位置情報で特定されるソースパケットまでの区間は、前記第二の区間に配置されていてもよい。
【００６６】
また、例えば、前記システムストリームファイルは、前記記録媒体に記録された前記ＡＶデータを再生する再生装置に読み出される所定のデータ単位で、前記記録媒体に記録されており、前記先頭ソースパケット番号で特定される前記先頭のソースパケットを含む前記所定のデータ単位と、前記先頭ソースパケット番号及び前記最終位置情報で特定されるソースパケットを含む前記所定のデータ単位とは、前記第一の区間の一部または全部を含まなくてもよい。
【００６７】
なお、これらの全般包括的または具体的な態様は、装置、方法、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、装置、方法、システム、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【００６８】
以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。
【００６９】
なお、本願請求項１に係る発明に最も近い実施の形態は実施の形態２であるが、理解を容易にするために、実施の形態２における情報記録媒体等の基本的な構成を説明する実施の形態１を先に説明する。
【００７０】
（実施の形態１）
まず、ＢＤ−ＲＯＭおよびＢＤ−ＲＯＭを再生するＢＤ−ＲＯＭプレーヤの基本的な構成および動作について、図１〜図３０を用いて説明する。
【００７１】
（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭのデータ階層を示す図である。
【００７２】
図４に示すように、ディスク媒体であるＢＤ−ＲＯＭ１０４上には、ＡＶデータ１０３と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報１０２と、インタラクティブを実現するＢＤ再生プログラム１０１とが記録されている。
【００７３】
なお、本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてＢＤ−ＲＯＭの説明を行うが、ＢＤ−ＲＯＭをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体として使用することも当然のことながら可能である。
【００７４】
図５は、前述のＢＤ−ＲＯＭ１０４に記録されている論理データの構造を示す図である。ＢＤ−ＲＯＭ１０４は、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有している。
【００７５】
また、リードインの内側にはＢｕｒｓｔ  Ｃｕｔｔｉｎｇ  Ａｒｅａ（ＢＣＡ）と呼ばれる、ドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
【００７６】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０等の規格により定められたデータを管理する仕組みのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００７７】
本実施の形態の場合、ＢＤ−ＲＯＭ１０４上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶデータや管理情報などのデータ（図４に示すＢＤ再生プログラム１０１、ＢＤ管理情報１０２、ＡＶデータ１０３）が記録されているディレクトリである。
【００７８】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００７９】
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤ−ＲＯＭ全体に関する情報を記録したファイルである。ＢＤ−ＲＯＭプレーヤは最初にこのファイルを読み出す。
【００８０】
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤ−ＲＯＭ全体に関わるプログラムを記録したファイルである。
【００８１】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ  Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
【００８２】
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＲＯＧ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００８３】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。１つのＶＯＢは１つのファイルに対応する。
【００８４】
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００８５】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニュー画面を構成するためのイメージデータであるＰＮＧ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって標準化された画像フォーマットであり「ピング」と読む。）形式のイメージファイルである。１つのＰＮＧイメージは１つのファイルに対応する。
【００８６】
（プレーヤの構成）
次に、前述のＢＤ−ＲＯＭ１０４を再生するプレーヤの構成について図６及び図７を用いて説明する。
【００８７】
図６は、ＢＤ−ＲＯＭ１０４を再生するＢＤ−ＲＯＭプレーヤの基本的な構成の概要を示す図である。
【００８８】
図６に示すＢＤ−ＲＯＭプレーヤにおいて、ＢＤ−ＲＯＭ１０４上のデータは、光ピックアップ２０２を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。
【００８９】
ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイル）はプログラム記録メモリ２０３に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」ファイル）は管理情報記録メモリ２０４に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」ファイル）はＡＶ記録メモリ２０５にそれぞれ記録される。
【００９０】
プログラム記録メモリ２０３に記録されたＢＤ再生プログラムはプログラム処理部２０６によって処理される。管理情報記録メモリ２０４に記録されたＢＤ管理情報は管理情報処理部２０７によって処理される。
【００９１】
また、ＡＶ記録メモリ２０５に記録されたＡＶデータはプレゼンテーション処理部２０８によって処理される。
【００９２】
プログラム処理部２０６は、管理情報処理部２０７から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで、再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部２０７に対して変更後のプレイリストの再生命令を送ることで実現する。
【００９３】
プログラム処理部２０６は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコンからのリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
【００９４】
管理情報処理部２０７は、プログラム処理部２０６の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応したＶＯＢの管理情報を解析する。更に、プレゼンテーション処理部２０８に再生の対象となるＡＶデータの再生を指示する。
【００９５】
また、管理情報処理部２０７は、プレゼンテーション処理部２０８から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部２０８にＡＶデータ再生の停止指示を行う。更に、プログラム処理部２０６に対してプログラム実行タイミングを示すイベントを生成する。
【００９６】
プレゼンテーション処理部２０８は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部２０７からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。
【００９７】
具体的には、映像データはビデオプレーン２１０に描画され、字幕データ等のイメージデータはイメージプレーン２０９に描画される。更に、２つのプレーンに描画された映像の合成処理が合成処理部２１１によって行われＴＶなどの表示デバイスへ出力される。
【００９８】
図６で示すように、ＢＤ−ＲＯＭプレーヤは図４で示したＢＤ−ＲＯＭ１０４に記録されているデータ構造に基づいた構成をとっている。
【００９９】
図７は、図６に示すプレーヤの構成を詳細化したブロック図である。図６に示す各構成部と、図７に示す各構成部との対応は以下の通りである。
【０１００】
ＡＶ記録メモリ２０５はイメージメモリ３０８とトラックバッファ３０９に対応する。プログラム処理部２０６はプログラムプロセッサ３０２とＵＯ（Ｕｓｅｒ  Ｏｐｅｒａｔｉｏｎ）マネージャ３０３に対応する。管理情報処理部２０７はシナリオプロセッサ３０５とプレゼンテーションコントローラ３０６とに対応する。プレゼンテーション処理部２０８はクロック３０７、デマルチプレクサ３１０、イメージプロセッサ３１１、ビデオプロセッサ３１２とサウンドプロセッサ３１３とに対応する。
【０１０１】
ＢＤ−ＲＯＭ１０４から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ３０９に、イメージデータ（ＰＮＧ）はイメージメモリ３０８にそれぞれ記録される。
【０１０２】
デマルチプレクサ３１０は、クロック３０７から得られる時刻に基づき、トラックバッファ３０９に記録されたＶＯＢデータを抜き出す。更に、ＶＯＢデータに含まれる映像データをビデオプロセッサ３１２に音声データをサウンドプロセッサ３１３にそれぞれ送り込む。
【０１０３】
ビデオプロセッサ３１２及びサウンドプロセッサ３１３はそれぞれＭＰＥＧシステム規格で定められる通りに、デコーダバッファとデコーダからそれぞれ構成されている。即ち、デマルチプレクサ３１０から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック３０７に従い個々のデコーダでデコード処理される。
【０１０４】
イメージメモリ３０８に記録されたＰＮＧデータは、次の２つの処理方法がある。ＰＮＧデータが字幕用の場合は、プレゼンテーションコントローラ３０６によってデコードタイミングが指示される。クロック３０７からの時刻情報をシナリオプロセッサ３０５が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ３０６に対して字幕の表示、非表示の指示を出す。
【０１０５】
プレゼンテーションコントローラ３０６からデコード／表示の指示を受けたイメージプロセッサ３１１は対応するＰＮＧデータをイメージメモリ３０８から抜き出し、デコードし、イメージプレーン２０９に描画する。
【０１０６】
また、ＰＮＧデータがメニュー画面用の場合は、プログラムプロセッサ３０２によってデコードタイミングが指示される。プログラムプロセッサ３０２がいつイメージのデコードを指示するかは、プログラムプロセッサ３０２が処理しているＢＤプログラムに因るものであって一概には決まらない。
【０１０７】
イメージデータ及び映像データは、図６で説明したようにそれぞれデコード後にイメージプレーン２０９およびビデオプレーン２１０に描画され、合成処理部２１１によって合成出力される。
【０１０８】
ＢＤ−ＲＯＭ１０４から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ２０４に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ３０５によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ３０６によって読み出され処理される。
【０１０９】
シナリオプロセッサ３０５は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ３０６に指示し、プレゼンテーションコントローラ３０６は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ３１７に指示を出す。
【０１１０】
ドライブコントローラ３１７はプレゼンテーションコントローラ３０６の指示に従い、光ピックアップ２０２を移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ３０８またはトラックバッファ３０９に記録される。
【０１１１】
また、シナリオプロセッサ３０５は、クロック３０７の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ３０２に投げる。
【０１１２】
プログラム記録メモリ２０３に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ３０２がＢＤプログラムを処理するのは、シナリオプロセッサ３０５からイベントが送られてきた場合か、ＵＯマネージャ３０３からイベントが送られてきた場合である。
【０１１３】
ＵＯマネージャ３０３は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ３０２に送る。
【０１１４】
このような各構成部の動作により、ＢＤ−ＲＯＭの再生がおこなわれる。
【０１１５】
（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間を示す図である。
【０１１６】
ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。
【０１１７】
プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。
【０１１８】
一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーヤの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の１つである。
【０１１９】
また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【０１２０】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ３０５からプログラムプロセッサ３０２に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ３０２はＩＤによって対応付けられるイベントハンドラを実行処理する。
【０１２１】
前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【０１２２】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。
【０１２３】
メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ３０２は、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【０１２４】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。
【０１２５】
グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行することができる。
【０１２６】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（Ｔｉｍｅ  ＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図１４を用いて後述する。
【０１２７】
（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成を示す図である。図９に示すように、ＶＯＢは複数のＶｉｄｅｏ  Ｏｂｊｅｃｔ  Ｕｎｉｔ（ＶＯＢＵ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームにおけるＧｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅｓ（ＧＯＰ）を基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。
【０１２８】
ＶＯＢＵは０．４秒から１．０秒の再生時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）であることによって導かれるものである。
【０１２９】
ＶＯＢＵは、その内部に映像データであるビデオパック（Ｖ＿ＰＣＫ）と、音声データであるオーディオパック（Ａ＿ＰＣＫ）とを有している。各パックは１セクタで構成され、本実施の形態の場合は２ｋＢ単位で構成されている。
【０１３０】
図１０は、ＭＰＥＧストリームにおけるパックの構成を示す図である。
【０１３１】
図１０に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。
【０１３２】
パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのか、映像データであるのか音声データであるのか、および、映像データまたは音声データがそれぞれ複数ストリーム分ある場合に、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）、並びに、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプであるＤｅｃｏｄｅ  Ｔｉｍｅ  Ｓｔａｍｐ（ＤＴＳ）及びＰｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ（ＰＴＳ）が記録されている。
【０１３３】
ＤＴＳおよびＰＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。
【０１３４】
パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサ３１０を通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプであるＳｙｓｔｅｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ（ＳＣＲ）が記録されている。
【０１３５】
（ＶＯＢのインターリーブ記録）
図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。
【０１３６】
図１１は、ＡＶデータとＢＤ−ＲＯＭプレーヤの構成との関係を説明するための図である。
【０１３７】
図１１上段の図は、図７を用いて前述したプレーヤ構成図の一部である。図の通り、ＢＤ−ＲＯＭ上のデータは、光ピックアップ２０２を通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファ３０９へ入力され、ＰＮＧ即ちイメージデータであればイメージメモリ３０８へと入力される。
【０１３８】
トラックバッファ３０９はＦｉｒｓｔ−Ｉｎ  Ｆｉｒｓｔ−Ｏｕｔ（ＦＩＦＯ）であり、入力されたＶＯＢのデータは入力された順にデマルチプレクサ３１０へと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファ３０９から引き抜かれデマルチプレクサ３１０を介してビデオプロセッサ３１２またはサウンドプロセッサ３１３へとデータが送り届けられる。
【０１３９】
一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ３０６（図７参照）によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ３０８から削除されるが、メニュー用のイメージデータの場合は、イメージメモリ３０８内にそのまま残される。
【０１４０】
これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
【０１４１】
図１１下段の図は、ＢＤ−ＲＯＭ上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。
【０１４２】
一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。
【０１４３】
しかしながら、連続再生すべきＡＶデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。
【０１４４】
ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤ−ＲＯＭから読み出す事が必要になる。
【０１４５】
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。
【０１４６】
そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、ＶＯＢファイルとイメージデータとをインターリーブ記録する方式を使用する。
【０１４７】
図１１下段はそのインターリーブ記録を説明するための図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリ３０８に格納することが可能になる。
【０１４８】
しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
【０１４９】
図１２は、上記のインターリーブ記録における問題を解決するトラックバッファ３０９を使ったＶＯＢデータ連続供給モデルを説明するための図である。
【０１５０】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファ３０９に蓄積される。トラックバッファ３０９へのデータ入力レートをトラックバッファ３０９からのデータ出力レートより高く設定すると、ＢＤ−ＲＯＭからデータを読み出し続けている限り、トラックバッファ３０９のデータ蓄積量は増加をしていくことになる。
【０１５１】
ここでトラックバッファ３０９への入力レートをＶａ、トラックバッファ３０９からの出力レートをＶｂとする。図１２の上段の図に示すようにＶＯＢの一連続記録領域が論理アドレスの“ａ１”から“ａ２”まで続くとする。また、“ａ２”から“ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
【０１５２】
図１２の下段の図は、トラックバッファ３０９の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ３０９内部に蓄積されているデータ量を示している。時刻“ｔ１”がＶＯＢの一連続記録領域の開始点である“ａ１”の読み出しを開始した時刻を示している。
【０１５３】
この時刻以降、トラックバッファ３０９にはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファ３０９の入出力レートの差である。時刻“ｔ２”は一連続記録領域の終了点である“ａ２”のデータを読み込む時刻である。
【０１５４】
即ち時刻“ｔ１”から“ｔ２”の間レートＶａ−Ｖｂでトラックバッファ３０９内はデータ量が増加していき、時刻“ｔ２”でのデータ蓄積量はＢ（ｔ２）は下記の（式１）によって求めることができる。
【０１５５】
Ｂ（ｔ２）  ＝  （Ｖａ−Ｖｂ）×（ｔ２−ｔ１）        （式１）
【０１５６】
この後、ＢＤ−ＲＯＭ上のアドレス“ａ３”まではイメージデータが続くため、トラックバッファ３０９への入力は０となり、出力レートである“−Ｖｂ”でトラックバッファ３０９内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置“ａ３”まで、つまり、時刻でいう“ｔ３”まで続く。
【０１５７】
ここで大事なことは、時刻“ｔ３”より前にトラックバッファ３０９に蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまうことである。
【０１５８】
しかしながら、時刻“ｔ３”でトラックバッファ３０９にデータが残っている場合には、ＶＯＢの再生がストップすることなく連続して行われることを意味している。
【０１５９】
このＶＯＢの再生がストップすることなく連続して行われるための条件は下記の（式２）によって示すことができる。
【０１６０】
Ｂ（ｔ２）  ≧  −Ｖｂ×（ｔ３−ｔ２）                （式２）
【０１６１】
即ち、（式２）を満たすようにイメージデータの配置を決めればよい事になる。
【０１６２】
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭに記録されたナビゲーションデータ（ＢＤ管理情報）の構造について説明をする。
【０１６３】
図１３は、ＶＯＢ管理情報ファイル（“ＹＹＹ．ＶＯＢＩ”）の内部構造を示す図である。
【０１６４】
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）とを有している。ストリーム属性情報は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、オーディオ属性のデータフィールドの数が特定される。
【０１６５】
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドとそれぞれが持ち得る値の例である。
【０１６６】
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）：
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）：
６０
５９．９４
５０
３０
２９．９７
２５
２４
【０１６７】
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドとそれぞれが持ち得る値の例である。
【０１６８】
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
ＪＰＮ、ＥＮＧ、・・・
【０１６９】
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。
【０１７０】
個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）とを有している。
【０１７１】
図１４は、ＶＯＢＵ情報の詳細を説明するための図である。
【０１７２】
広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つの物理量についての側面を有している。例えば、音声の圧縮規格であるＡｕｄｉｏ  Ｃｏｄｅ  ｎｕｍｂｅｒ  ３（ＡＣ３）は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。
【０１７３】
しかしながらＭＰＥＧビデオデータの場合、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合、１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。
【０１７４】
従って、ＭＰＥＧビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。
【０１７５】
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧストリーム、即ちＶＯＢについても、時間とデータとを一般式の形で表現することは不可能である。
【０１７６】
これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数とをそれぞれエントリとして持つテーブルがタイムマップ（ＴＭＡＰ）である。
【０１７７】
図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。
【０１７８】
図１５は、タイムマップを使ったアドレス情報取得方法を説明するための図である。
【０１７９】
図１５に示すように時刻情報（Ｔｉｍｅ）が与えられた場合、まずは当該時刻がどのＶＯＢＵに属するのかを検索する。具体的には、タイムマップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致するＶＯＢＵが当該時刻に対応するＶＯＢＵになる。
【０１８０】
次に、タイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレス（Ａｄｄｒｅｓｓ）になっている。
【０１８１】
このようにして、ＭＰＥＧストリームにおいて、与えられた時刻情報に対応するアドレスを得ることができる。
【０１８２】
次に図１６を使って、プレイリスト（“ＸＸＸ．ＰＬ”）の内部構造を説明する。
【０１８３】
図１６は、プレイリストの構成を示す図である。
【０１８４】
プレイリストは、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１８５】
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。
【０１８６】
セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
【０１８７】
各セル情報（Ｃｅｌｌ＃〜Ｃｅｌｌ＃ｎ）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。
【０１８８】
有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、それぞれ当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
【０１８９】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）とから構成されている。
【０１９０】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）は、言語情報（Ｌａｎｇｕａｇｅ）と、表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）とから構成され、各字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）とから構成されている。
【０１９１】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成され、各イベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）とから構成されている。
【０１９２】
図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（“ＸＸＸ．ＰＲＯＧ”）の構成を示す図である。
【０１９３】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。
【０１９４】
各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ｅｖｅｎｔ＿ｈａｎｄｌｅｒ  ｉｄ）を持ち、その後に当該プログラムが“ｆｕｎｃｔｉｏｎ”に続く括弧“｛”と“｝”との間に記述される。
【０１９５】
次に図１８を用いてＢＤ−ＲＯＭ全体に関する情報（“ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。
【０１９６】
図１８は、ＢＤ−ＲＯＭ全体情報であるＢＤ．ＩＮＦＯの構成を示す図である。
【０１９７】
ＢＤ−ＲＯＭ全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントリスト（ＥｖｅｎｔＬｉｓｔ）とから構成されている。
【０１９８】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）とから構成されている。
【０１９９】
各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）とを含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【０２００】
チャプターリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプター数（Ｎｕｍｂｅｒ）と各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）とから構成され、各チャプター情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）は当該チャプターが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と各セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）とから構成されている。
【０２０１】
セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【０２０２】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤ−ＲＯＭがプレーヤに挿入された時、最初に実行されるイベントである。
【０２０３】
各グローバルイベントの情報（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
【０２０４】
図１９は、グローバルイベントハンドラテーブル（“ＢＤ．ＰＲＯＧ”）の構成を示す図である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。
【０２０５】
（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。
【０２０６】
図２０は、タイムイベントの例を示す図である。
【０２０７】
前述したとおり、タイムイベントはプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
【０２０８】
タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、ＩＤ“Ｅｘ１”を持つタイムイベントがシナリオプロセッサ３０５からプログラムプロセッサ３０２に対して出力される。
【０２０９】
プログラムプロセッサ３０２は、イベントＩＤ“Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うことなどが可能である。
【０２１０】
図２１は、ユーザのメニュー操作によるユーザイベントの例を示す図である。
【０２１１】
前述したとおり、メニュー操作によるユーザイベントもプレイリスト（“ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
【０２１２】
ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（“ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。
【０２１３】
当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間（“Ｔ１”）レディ状態にある。
【０２１４】
図２１に示すように、ユーザによりリモコンキーの「上」「下」「左」「右」キーのいずれかのキー、または「決定」キーが押された場合、まずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。
【０２１５】
プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流し、シナリオプロセッサ３０５はＵＯイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。
【０２１６】
シナリオプロセッサ３０５は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ３０２に出力する。
【０２１７】
プログラムプロセッサ３０２では、イベントＩＤ、例えば、図２１に示す例の場合では“Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト＃２の再生を開始する。
【０２１８】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯイベントによってプログラムプロセッサ３０２に伝えられ、仮想プレーヤが持つレジスタに記録保持される。
【０２１９】
イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。
【０２２０】
図２２は、グローバルイベントの例を示す図である。
【０２２１】
前述のように、グローバルイベントはＢＤ−ＲＯＭ全体情報（“ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。
【０２２２】
グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が“ＧｌｏｂａｌＥｖｅｎｔ”であるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される。
【０２２３】
ユーザによりメニューキーが押された場合、先ずＵＯイベントがＵＯマネージャ３０３によって生成されプログラムプロセッサ３０２に出力される。プログラムプロセッサ３０２は、シナリオプロセッサ３０５に対してＵＯイベントを流す。
【０２２４】
シナリオプロセッサ３０５は、該当するグローバルイベントを生成し、プログラムプロセッサ３０２に送る。プログラムプロセッサ３０２は、イベントＩＤ“ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、図２２に示す例の場合、プレイリスト＃３の再生を開始している。
【０２２５】
本実施の形態では、単にメニューキーと呼んでいるが、ＤＶＤを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。
【０２２６】
（仮想プレーヤマシン）
図２３は、プログラムプロセッサ３０２の機能的な構成を説明するための図である。
【０２２７】
図２３を用いてプログラムプロセッサ３０２の機能的な構成を説明する。
【０２２８】
プログラムプロセッサ３０２は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行できることを保証している。
【０２２９】
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数である。プレーヤ変数はレジスタに記憶され保持されている。
【０２３０】
プログラミング関数は、Ｊａｖａ（登録商標）  Ｓｃｒｉｐｔをベースとして、以下に記す３つの機能をＢＤ−ＲＯＭ固有関数として定義している。
【０２３１】
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する。
【０２３２】
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃  ：  プレイリスト名
Ｃｅｌｌ＃  ：  セル番号
ｔｉｍｅ  ：  セル内での再生開始時刻
【０２３３】
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーン２０９に描画する。
【０２３４】
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ  ：  ＰＮＧファイル名
Ｘ  ：  Ｘ座標位置
Ｙ  ：  Ｙ座標位置
【０２３５】
イメージプレーンクリア関数：イメージプレーン２０９の指定領域をクリアする。
【０２３６】
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ  ：  Ｘ座標位置
Ｙ  ：  Ｙ座標位置
Ｗ  ：  Ｘ方向幅
Ｈ  ：  Ｙ方向幅
【０２３７】
また、プレーヤ変数は、プレーヤの設定値等を示すシステムパラメータ（ＳＰＲＭ）と、一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０２３８】
図２４は、システムパラメータ（ＳＰＲＭ）の一覧を示す図である。
【０２３９】
ＳＰＲＭ（０）      ：  言語コード
ＳＰＲＭ（１）      ：  音声ストリーム番号
ＳＰＲＭ（２）      ：  字幕ストリーム番号
ＳＰＲＭ（３）      ：  アングル番号
ＳＰＲＭ（４）      ：  タイトル番号
ＳＰＲＭ（５）      ：  チャプター番号
ＳＰＲＭ（６）      ：  プログラム番号
ＳＰＲＭ（７）      ：  セル番号
ＳＰＲＭ（８）      ：  選択キー情報
ＳＰＲＭ（９）      ：  ナビゲーションタイマー
ＳＰＲＭ（１０）    ：  再生時刻情報
ＳＰＲＭ（１１）    ：  カラオケ用ミキシングモード
ＳＰＲＭ（１２）    ：  パレンタル用国情報
ＳＰＲＭ（１３）    ：  パレンタルレベル
ＳＰＲＭ（１４）    ：  プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５）    ：  プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６）    ：  音声ストリーム用言語コード
ＳＰＲＭ（１７）    ：  音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８）    ：  字幕ストリーム用言語コード
ＳＰＲＭ（１９）    ：  字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０）    ：  プレーヤリージョンコード
ＳＰＲＭ（２１）    ：  予備
ＳＰＲＭ（２２）    ：  予備
ＳＰＲＭ（２３）    ：  再生状態
ＳＰＲＭ（２４）    ：  予備
ＳＰＲＭ（２５）    ：  予備
ＳＰＲＭ（２６）    ：  予備
ＳＰＲＭ（２７）    ：  予備
ＳＰＲＭ（２８）    ：  予備
ＳＰＲＭ（２９）    ：  予備
ＳＰＲＭ（３０）    ：  予備
ＳＰＲＭ（３１）    ：  予備
【０２４０】
なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標）
Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標）  Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標）  ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ  Ｓｃｒｉｐｔなど他のプログラミング関数であってもよい。言い換えれば、本発明におけるプログラム言語はＪａｖａ（登録商標）  Ｓｃｒｉｐｔに限定されるものでは無い。
【０２４１】
（プログラムの例）
図２５及び図２６は、イベントハンドラにおけるプログラムの例を示す図である。
【０２４２】
図２５は、２つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。
【０２４３】
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に“１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン［１］が選択されている状態を初期値として持たされている。
【０２４４】
次に、ＰＮＧの描画を描画関数である“Ｄｒａｗ”を使ってボタン［１］、ボタン［２］それぞれについて行っている。ボタン［１］は、座標（１０、２００）を起点（左上端）としてＰＮＧイメージ“１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン［２］は、座標（３３０，２００）を起点（左上端）としてＰＮＧイメージ“２ｗｈｉｔｅ．ｐｎｇ”を描画している。
【０２４５】
また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
【０２４６】
図２６は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。
【０２４７】
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれている。ユーザによりリモコンキーが押された場合、図２１を用いて説明したように、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。
【０２４８】
本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って以下のように分岐処理を行っている。
【０２４９】
条件１）ボタン［１］が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右のボタン［２］に変更する。
【０２５０】
ボタン［１］、ボタン［２］のイメージをそれぞれ書き換える。
【０２５１】
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン［１］が選択されている場合
プレイリスト＃２の再生を開始する。
【０２５２】
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン［２］が選択されている場合
プレイリスト＃３の再生を開始する。
【０２５３】
図２６に示すプログラムは、上記のように解釈され実行される。
【０２５４】
（プレーヤ処理フロー）
図２７から図３０を用いてプレーヤでの処理の流れを説明する。
【０２５５】
図２７は、ＢＤ−ＲＯＭプレーヤにおけるＡＶデータ再生の基本処理の流れを示すフロー図である。
【０２５６】
ＢＤ−ＲＯＭが挿入されると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤは“ＢＤ．ＩＮＦＯ”の読み込みと解析（Ｓ１０２）、および、“ＢＤ．ＰＲＯＧ”の読み込み（Ｓ１０３）を実行する。“ＢＤ．ＩＮＦＯ”及び“ＢＤ．ＰＲＯＧ”は共に管理情報記録メモリ２０４に一旦格納され、シナリオプロセッサ３０５によって解析される。
【０２５７】
続いて、シナリオプロセッサ３０５は、“ＢＤ．ＩＮＦＯ”ファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサ３０２で受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
【０２５８】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる（Ｓ２０１でＮｏ）。
【０２５９】
ＵＯマネージャ３０３は、ユーザからのリモコン操作を受け付けると（Ｓ２０１でＹｅｓ）、プログラムプロセッサ３０２に対するＵＯイベントを生成する（Ｓ２０２）。
【０２６０】
プログラムプロセッサ３０２は、ＵＯイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合（Ｓ２０３でＹｅｓ）は、シナリオプロセッサ３０５にＵＯイベントを流し、シナリオプロセッサ３０５がユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサ３０２は生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
【０２６１】
図２８は、ＢＤ−ＲＯＭプレーヤにおけるプレイリスト再生開始からＶＯＢ再生終了までの処理の流れを示すフロー図である。
【０２６２】
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサ３０５は、再生対象のプレイリスト再生に必要な情報として、プレイリスト“ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、および、プレイリストに対応するプログラム情報“ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。
【０２６３】
続いてシナリオプロセッサ３０５は、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラ３０６に対して要求が出される事を意味し、プレゼンテーションコントローラ３０６はＡＶデータ再生を開始する（Ｓ３０５）。
【０２６４】
ＡＶデータの再生が開始されると、プレゼンテーションコントローラ３０６は、再生するセルに対応するＶＯＢの情報ファイル“ＸＸＸ．ＶＯＢＩ”を読み込み（Ｓ４０２）、解析する。プレゼンテーションコントローラ３０６は、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラ３１７に読み出しアドレスを指示する。ドライブコントローラ３１７は対象となるＶＯＢデータ“ＹＹＹ．ＶＯＢ”を読み出す（Ｓ４０３）。
【０２６５】
読み出されたＶＯＢデータはデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセルが存在する場合（Ｓ４０６でＹｅｓ）、Ｃｅｌｌの再生（Ｓ３０４）へ移行する。また、次のセルが無い場合（Ｓ４０６でＮｏ）は、再生に係る処理が終了する。
【０２６６】
図２９は、ＡＶデータ再生開始後からのイベント処理の流れを示すフロー図である。
【０２６７】
図２９（Ａ）は、ＢＤ−ＲＯＭプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。
【０２６８】
なお、ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。
【０２６９】
ＢＤ−ＲＯＭプレーヤにおいてプレイリスト再生の再生が開始されると（Ｓ５０１）、プレイリスト再生が終了していないことが確認され（Ｓ５０２でＮｏ）、シナリオプロセッサ３０５は、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。
【０２７０】
タイムイベント発生時刻になっている場合（Ｓ５０３でＹｅｓ）には、シナリオプロセッサ３０５はタイムイベントを生成する（Ｓ５０４）。プログラムプロセッサ３０２はタイムイベントを受け取り、イベントハンドラを実行処理する（Ｓ５０５）。
【０２７１】
また、タイムイベント発生時刻になっていない場合（Ｓ５０３でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ５０２）以降の処理を繰り返す。
【０２７２】
また、プレイリスト再生が終了したことが確認されると（Ｓ５０２でＹｅｓ）、タイムイベント系の処理は強制的に終了する。
【０２７３】
図２９（Ｂ）は、ＢＤ−ＲＯＭプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。
【０２７４】
ＢＤ−ＲＯＭプレーヤにおいてプレイリストの再生が開始されると（Ｓ６０１）、プレイリスト再生が終了していないことが確認され（Ｓ６０２でＮｏ）、ＵＯマネージャ３０３は、ＵＯの受け付けがあったかを確認する。
【０２７５】
ＵＯの受け付けがあった場合（Ｓ６０３でＹｅｓ）、ＵＯマネージャ３０３はＵＯイベントを生成する（Ｓ６０４）。プログラムプロセッサ３０２はＵＯイベントを受け取り、そのＵＯイベントがメニューコールであるかを確認する。
【０２７６】
メニューコールであった場合（Ｓ６０５でＹｅｓ）、プログラムプロセッサ３０２はシナリオプロセッサ３０５にイベントを生成させ（Ｓ６０７）、プログラムプロセッサ３０２はイベントハンドラを実行処理する（Ｓ６０８）。
【０２７７】
また、ＵＯイベントがメニューコールで無いと判断された場合（Ｓ６０５でＮｏ）、ＵＯイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ３０５が判断し、有効期間内である場合（Ｓ６０６でＹｅｓ）には、シナリオプロセッサ３０５がユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサ３０２が対象のイベントハンドラを実行処理する（Ｓ６０８）。
【０２７８】
また、ＵＯ受付が無い場合（Ｓ６０３でＮｏ）、現在時刻がユーザイベント有効期間内にない場合（Ｓ６０６でＮｏ）、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認（Ｓ６０２）以降の処理を繰り返す。
【０２７９】
また、プレイリスト再生が終了したことが確認されると（Ｓ６０２でＹｅｓ）、ユーザイベント系の処理は強制的に終了する。
【０２８０】
図３０は、ＢＤ−ＲＯＭプレーヤにおける字幕データの処理の流れを示すフロー図である。
【０２８１】
ＢＤ−ＲＯＭプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認され（Ｓ７０２でＮｏ）、シナリオプロセッサ３０５は、字幕表示開始時刻になったかを確認する。字幕表示開始時刻になっている場合（Ｓ７０３でＹｅｓ）、シナリオプロセッサ３０５はプレゼンテーションコントローラ３０６に字幕描画を指示し、プレゼンテーションコントローラ３０６はイメージプロセッサ３１１に字幕描画を指示する。イメージプロセッサ３１１は、その指示に従い字幕をイメージプレーン２０９に字幕を描画する（Ｓ７０４）。
【０２８２】
また、字幕表示開始時刻になっていない場合（Ｓ７０３でＮｏ）、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合（Ｓ７０５でＹｅｓ）、プレゼンテーションコントローラ３０６がイメージプロセッサ３１１に字幕消去指示を行う。
【０２８３】
イメージプロセッサ３１１は、その指示に従い描画されている字幕をイメージプレーン２０９から消去する（Ｓ７０６）。
【０２８４】
また、イメージプロセッサ３１１による字幕描画（Ｓ７０４）が終了した場合、イメージプロセッサ３１１による字幕消去（Ｓ７０６）のが終了した場合、および、字幕表示終了時刻でないと判断（Ｓ７０５でＮｏ）された場合、プレイリスト再生の終了確認（Ｓ７０２）以降の処理を繰り返す。
【０２８５】
また、プレイリスト再生が終了したことが確認されると（Ｓ７０２でＹｅｓ）、字幕表示系の処理は強制的に終了する。
【０２８６】
以上の動作により、ＢＤ−ＲＯＭプレーヤは、ユーザの指示またはＢＤ−ＲＯＭに記録されているＢＤ管理情報等に基づき、ＢＤ−ＲＯＭの再生に係る基本的な処理を行う。
【０２８７】
（実施の形態２）
次に本発明の実施の形態２について説明する。
【０２８８】
実施の形態２は、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃでの高輝度（ＨＤＲ）映像情報の記録、再生、及び編集に関する内容である。基本的には実施の形態１に基づくため、拡張または異なる部分を中心に説明する。
【０２８９】
図３１は、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃにて使われているシステムストリームファイルの記録フォーマットを説明するための図である。
【０２９０】
各ＭＰＥＧ−２  ｔｒａｎｓｐｏｒｔ  ｐａｃｋｅｔ（ＴＳパケット）には、そのＴＳパケットのＴ−ＳＴＤ（システムターゲットデコーダ）への相対的な入力時刻を２７ＭＨｚの時刻精度で示したＩｎｐｕｔ  Ｔｉｍｅが付与されることで、合計１９２バイトのソースパケット（ｓｏｕｒｃｅ  ｐａｃｋｅｔ）を構成する。システムストリームファイルは、複数のソースパケットから構成される。このソースパケットを３２個集めたデータ単位をＡｌｉｇｎｅｄ  ｕｎｉｔと呼び、Ａｌｉｇｎｅｄ  ｕｎｉｔのサイズは６ＫＢ（３２＊１９２バイト）である。ディスクへは整数個のＡｌｉｇｎｅｄ  ｕｎｉｔから構成したストリームデータを．ｍ２ｔｓという拡張子を持つファイル（システムストリームファイル）として記録する。このような．ｍ２ｔｓという拡張子を持つファイルはｍ２ｔｓファイル、また、その記録フォーマットはｍ２ｔｓ形式とそれぞれ呼ばれており、現行のＢｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃにて利用されている。
【０２９１】
図３２は、新しい暗号化処理を施したシステムストリームファイルの記録フォーマットを説明するための図である。具体的には、図３２の（ａ）は、新しい暗号化処理を施したシステムストリームファイルの構成を示す図である。また、図３２の（ｂ）は、新しいシステムストリームファイルに対応したＶＯＢＩファイルについて説明するための図である。
【０２９２】
図３２の（ａ）に示すように、新しい暗号化処理を施したシステムストリームファイル（以下、「新システムストリームファイル」という。）は、ｍ２ｔｓファイルと比較して、整数個のＡｌｉｇｎｅｄ  ｕｎｉｔから構成される点は同様であるが、一部の区間で偶数個のＡｌｉｇｎｅｄ  ｕｎｉｔから構成されるスクランブル区間（ｓｃｒａｍｂｌｅｄ
ｓｅｇｍｅｎｔ）を含む点が異なる。つまり、新システムストリームファイルは、ｍ２ｔｓファイルとは異なる暗号化処理をされた映像情報を含む。つまり、新ストリームファイルは、第一の区間としてのスクランブル区間と、第二の区間としてのスクランブル区間以外の区間（以下、「非スクランブル区間」という。）とを有する。
【０２９３】
また、新システムストリームファイルは、スクランブル区間では、２つのＡｌｉｎｇｅｄ  ｕｎｉｔのうちプレーヤが持つ第一の復号鍵に応じて奇数番目及び偶数番目のどちらかのＡｌｉｇｎｅｄ  ｕｎｉｔを復号可能であり、他方のＡｌｉｇｎｅｄ  ｕｎｉｔを正しく復号することができない。このため、他方のＡｌｉｇｎｅｄ  ｕｎｉｔは、復号処理が行われた場合、６ＫＢ分のゴミデータに変換されることになる。つまり、スクランブル区間（第一の区間）は、プレーヤ（再生装置）が個別に有する第一の復号鍵を用いて復号できる第一のデータ単位としてのＡｌｉｎｇｅｄ  ｕｎｉｔと、第一のデータ単位と同じデータサイズの第二のデータ単位であって、当該第一の復号鍵で復号できない第二のデータ単位としてのＡｌｉｎｇｅｄ  ｕｎｉｔとを繰り返す。なお、上述したように各Ａｌｉｇｎｅｄ  ｕｎｉｔは、３２個のソースパケットにより構成されるため、第一のデータ単位及び第二のデータ単位は、３２個のソースパケットにより構成される。
【０２９４】
また、新システムストリームファイルは、非スクランブル区間では、ｍ２ｔｓファイルと同じように単一の復号鍵で暗号化されている。つまり、非スクランブル区間（第二の区間）は、プレーヤが他のプレーヤと共通して有する第二の復号鍵を用いて全て復号可能な区間である。
【０２９５】
この新しい記録フォーマットの新システムストリームファイルは、例えば、「．ｓｃｔｓ」という拡張子が付与され、ｓｃｔｓファイルと呼ばれており、「．ｓｃｔｓ」の拡張子によりｍ２ｔｓファイルとは異なる記録フォーマットのファイルであることが示されている。なお、ｓｃｔｓファイルにおいても、ｍ２ｔｓファイルと同様に、ファイル名の数字により、当該ｓｃｔｓファイルに対応するＶＯＢＩファイルを特定できる。
【０２９６】
スクランブル区間がｓｃｔｓファイルのどの場所に存在するのか（つまり、ｓｃｔｓファイルにおけるスクランブル区間の配置位置）は、図３２の（ｂ）に示すように、対応するＶＯＢＩファイルの拡張データ（ＳＳＭＡＰ）において指定される。ＳＳＭＡＰは、スクランブル区間ごとに、そのスクランブル区間の先頭のソースパケット番号（Ｓｔａｒｔ  ＳＰＮ）と最終のソースパケット番号（Ｅｎｄ  ＳＰＮ）とを管理するデータブロックである。これによりプレーヤはソースパケット精度で、ｓｃｔｓファイルにおけるスクランブル区間の配置位置を特定することができる。なお、スクランブル区間における奇数番目及び偶数番目のどちらのＡｌｉｎｇｅｄ  ｕｎｉｔを復号可能なのかを示す情報は、別途暗号化情報としてプレーヤに渡されるがここではその詳細は説明しない。
【０２９７】
ｓｃｔｓ形式のファイルの再生に対応したプレーヤは、スクランブル区間でのＡｌｉｎｇｅｄ  ｕｎｉｔを復号する際に、奇数番目及び偶数番目のどちらかのＡｌｉｇｎｅｄ  ｕｎｉｔの復号に必要な第一の復号鍵を入手して当該Ａｌｉｎｇｅｄ  ｕｎｉｔの復号に成功し、もう片方のＡｌｉｇｎｅｄ  ｕｎｉｔの復号に失敗し６ＫＢ分のゴミデータを発生させる。また、プレーヤは、非スクランブル区間でのＡｌｉｎｇｅｄ  ｕｎｉｔを復号する際に、スクランブル区間でのＡｌｉｎｇｅｄ  ｕｎｉｔを復号するための第一の復号鍵とは異なる第二の復号鍵を用いることで復号に成功しながら再生を継続する。つまり、プレーヤは、ｓｃｔｓファイルの復号においては、スクランブル区間ごとに奇数番目及び偶数番目のどちらか一方のＡｌｉｇｎｅｄ  ｕｎｉｔの復号に失敗し、再生できないストリームデータを生成することになる。プレーヤは、ｓｃｔｓファイル内の非スクランブル区間のストリームデータ（Ａｌｉｎｇｅｄ  ｕｎｉｔ）については正しく復号して再生することができる。
【０２９８】
このような暗号処理を施したストリームを再生するプレーヤは、スクランブル区間と非スクランブル区間との境界を跨ぐ度に、第一の復号鍵及び第二の復号鍵を切り替えながら復号を行うことになる。このため、プレーヤは、復号鍵を切り替えるためのオーバーヘッドが必要になり再生のパフォーマンスが劣化する。また、復号に失敗することで再生できないストリームデータ（Ａｌｉｎｇｅｄ  ｕｎｉｔ）が再生中に発生するため、当該ストリームデータを廃棄する処理が必要になる。しかしながら、特定のパケットから所定のパケット数だけ後に多重化されているパケットデータを破壊しているような、正しく復号するために所定のパケット数などのデータサイズに関する情報を利用したアドレス計算を行うことが必要な暗号が、さらに施されていた場合には、パケットを廃棄する処理を行うことでアドレス計算に狂いが生じる。このため、このような場合には、復号失敗したＡｌｉｇｎｅｄ  ｕｎｉｔを廃棄するだけでは、ストリームデータを再生できないこともある。さらに、このようなパケット単位の処理は、次世代Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃなどでは非常に高レート（最大で約１２８Ｍｂｐｓ）なストリームを扱うため、ソフト処理では到底追いつかず、ハードウェア前提の処理となり、その分プレーヤの開発コストがかさむことも問題である。
【０２９９】
図３３は、このような問題に対処するための新たなプレーヤのシステム構成を説明するための図である。
【０３００】
図３３に示すように、プレーヤ４００は、ドライブ４１０と、コンバータ４２０と、デコーダ４３０と、バッファ４４１と、クロック４４２とを備える。
【０３０１】
ドライブ４１０は、ディスクからストリームデータを含むシステムストリームファイルを読み出し、ＥＣＣ復号器４１１を経由してＥＣＣ復号する。つまり、ドライブ４１０は、読み出し部として機能する。ドライブ４１０は、図３３においてＤｒｉｖｅとして破線で囲んだフロントエンドの構成であり、上記処理を行う。なお、ドライブ４１０は、従来のプレーヤから変更が無い構成要素である。
【０３０２】
デコーダ４３０は、読み込んだストリームデータをプレーヤの最終段において再生する。デコーダ４３０は、ＭＰＥＧ−２  Ｓｙｓｔｅｍ規格に準拠したＴ−ＳＴＤモデルのデコーダであり、これまで同様にビデオ、オーディオ、及びシステムデータのそれぞれを処理するバッファ列及びデコーダから構成される。デコーダ４３０は、ＭＰＥＧ−２  ＴＳ  Ｄｅｃｏｄｅｒ（．ｍ２ｔｓ  ｄｅｃｏｄｅｒ）として破線で囲んだバックエンドの構成であり、上記処理を行う。なお、デコーダ４３０は、従来のプレーヤから変更が無い構成要素である。
【０３０３】
また、プレーヤ４００は、データの流れにおけるデコーダ４３０の直前において、ドライブ４１０からの読み込みデータを一時的に蓄積し、ドライブ４１０の読み込み停止（読み込む対象の記録層の切り替えなどで生じる実質的なデータ読み込みの停止）によって再生を途切れさせず、かつ、各ＴＳパケットを当該ＴＳパケットの所望のタイミング（Ｉｎｐｕｔ  Ｔｉｍｅ）でデコーダ４３０へ入力するためのバッファ（Ｒｅａｄ  Ｂｕｆｆｅｒ）４４１及びクロック（Ｃｌｏｃｋ）４４２を備える。これらのバッファ４４１及びクロック４４２ついても、従来のプレーヤから変更が無い構成要素である。
【０３０４】
ｓｃｔｓファイルに対応するプレーヤ４００が図３２で説明した課題を回避するために新たに備えた構成要素は、図３３の真ん中のＣｏｎｖｅｒｔｅｒとして破線で囲んだ、変換部として機能するコンバータ４２０である。このコンバータ４２０は、読み込んでいるストリームデータにより構成されるファイルの拡張子がｍ２ｔｓか、ｓｃｔｓかに応じて切り替わるスイッチを有し、ｍ２ｔｓファイルの読み込み中ではコンバータ４２０のスイッチをＳＷ２に接続し、ドライブ４１０によって出力されたストリームデータには何も変更を加えない。一方、コンバータ４２０は、ｓｃｔｓファイルの読み込み中ではコンバータ４２０のスイッチをＳＷ１に接続し、ｓｃｔｓ形式のファイルをｍ２ｔｓ形式のファイルへと変換する変換器（ｓｃｔｓ−＞ｍ２ｔｓ  ｃｏｎｖｅｒｔｅｒ）４２１を経由するように動作する。つまり、読み出したシステムストリームファイルの拡張子がｍ２ｔｓ形式を示すか否かに応じて、当該システムストリームファイルがｍ２ｔｓファイルであるか、ｓｃｔｓファイルであるかを判定し、判定の結果、読み出したシステムストリームファイルがｓｃｔｓストリームファイルである場合、変換処理を行うことにより得られたｍ２ｔｓ形式のシステムストリームを出力し、判定の結果、読み出したシステムストリームファイルがｍ２ｔｓファイルである場合、変換処理を行わずに当該ｍ２ｔｓ形式のシステムストリームを出力する。
【０３０５】
これにより、ｓｃｔｓファイルの読み込み中では、コンバータ４２０がｍ２ｔｓ形式にストリームデータを整形して出力するため、後段のデコーダ（ＭＰＥＧ−２  ＴＳ  Ｄｅｃｏｄｅｒ（．ｍ２ｔｓ  ｄｅｃｏｄｅｒ））としてはｍ２ｔｓ形式のシステムストリームを再生しているのと同じように動作することができ、これまでのデコーダをそのまま再利用することができる。つまり、コンバータ４２０は、ドライブ４１０により、ｓｃｔｓファイル（第一のシステムストリームファイル）及びｍ２ｔｓファイル（第二のシステムストリームファイル）の少なくとも一方を有するシステムストリームファイルを読み出した場合、どのシステムストリームファイルを読み出してもｍ２ｔｓ形式のシステムストリームを出力するため、従来と同じｍ２ｔｓファイルをデコードするデコーダを設計変更せずに両方のデータフォーマットに対応させることができる。
【０３０６】
ｍ２ｔｓ形式及びｓｃｔｓ形式のどちらのシステムストリームファイルを再生しているかは、再生しているＰｌａｙＬｉｓｔが参照するＶＯＢＩファイルの番号から、同じ番号を有するシステムストリームファイルの拡張子を取得することで識別することが可能である。つまり、コンバータ４２０は、再生している（ドライブ４１０により読み込まれている）システムストリームファイルの拡張子に応じて、当該システムストリームファイルの形式を変換する処理を行うか否かを判断し、当該システムストリームファイルの拡張子がｍ２ｔｓの場合には何も変換しないＳＷ２に切り替え、当該システムストリームファイルの拡張子がｓｃｔｓの場合には当該システムストリームファイルの形式を変換する処理を行うＳＷ１に切り替えるようにしても良い。
【０３０７】
なお、ｓｃｔｓファイルの再生中にスクランブル区間のみＳＷ１にスイッチを切り替えて、ｍ２ｔｓ形式のシステムストリームに変換してもよい。具体的には、コンバータ４２０は、スクランブル区間の開始位置及び終了位置をＶＯＢＩファイルのＳＳＭＡＰを参照することで取得できる。これにより、コンバータ４２０は、取得したスクランブル区間の開始位置及び終了位置に従って、スクランブル区間であるか否かを特定し、特定したスクランブル区間のストリームデータの場合にはＳＷ１にスイッチを切り替え、特定したスクランブル区間でないストリームデータの場合にはＳＷ２にスイッチを切り替えても良い。
【０３０８】
なお、システムストリームファイルのファイル形式がｍ２ｔｓ形式であるかｓｃｔｓ形式であるかの識別は上記の方法でも可能であるが、ＰｌａｙＬｉｓｔやＶＯＢＩファイルに明示的にどちらの記録フォーマットを再生するのかを識別するための識別情報を記録しておき、当該識別情報に応じてファイル形式がどちらのファイル形式であるかを判定しても良い。
【０３０９】
なお、コンバータ４２０は、復号鍵の切り替えなどでタイムラグを発生させると考えられ、ＥＣＣ復号器４１１（ドライブ４１０）とバッファ４４１との間に配置したが、コンバータ４２０における処理がモデルとして瞬時になされるとすれば、バッファ４４１とデコーダ４３０との間に配置しても良い。
【０３１０】
図３４は、図３３で説明したコンバータによりｓｃｔｓファイルをｍ２ｔｓ形式のシステムストリームに変換する例を示す図である。具体的には、図３４の（ａ）は、新しい暗号化処理を施したシステムストリームファイルの構成を示す図である。また、図３４の（ｂ）は、復号鍵Ａ（Ａ−Ｋｅｙ）を有するプレーヤによってファイル形式が変換されたシステムストリームの構成を示す図である。また、図３４の（ｃ）は、復号鍵Ｂ（Ｂ−Ｋｅｙ）を有するプレーヤによってファイル形式が変換されたシステムストリームの構成を示す図である。
【０３１１】
図３４の（ａ）に示すようなｓｃｔｓファイルを再生した場合、プレーヤ４００は、スクランブル区間で奇数番目のＡｌｉｎｇｅｄ  ｕｎｉｔを復号する経路か、偶数番目のＡｌｉｎｇｅｄ  ｕｎｉｔを復号する経路かどちらの経路を選択するかがプレーヤに応じて示された情報を別途暗号化情報の一部として取得する。そして、プレーヤ４００は、コンバータ４２０において、どちらか一方のＡｌｉｇｎｅｄ  ｕｎｉｔを取得した第一の復号鍵で復号し、当該第一の復号鍵で復号できない他方のＡｌｉｇｎｅｄ  ｕｎｉｔに対しては３２個の連続なＮＵＬＬパケットを生成する。
【０３１２】
コンバータ４２０の処理は、例えば、第一の復号鍵としてＡタイプの復号鍵Ａを持つプレーヤの場合、図３４の（ｂ）のようなＡｌｉｇｎｅｄ  ｕｎｉｔ＃１が復号され、Ａｌｉｇｎｅｄ  ｕｎｉｔ＃２については復号できず当該Ａｌｉｇｎｅｄ  ｕｎｉｔ＃２を３２個の連続なＮＵＬＬパケットに置き換える処理となる。
【０３１３】
コンバータ４２０の処理は、逆に、第一の復号鍵としてＢタイプの復号鍵Ｂを持つプレーヤの場合、図３４の（ｃ）のようなＡｌｉｇｎｅｄ  ｕｎｉｔ＃１については復号できず当該Ａｌｉｇｎｅｄ  ｕｎｉｔ＃１を３２個の連続なＮＵＬＬパケットに置き換え、Ａｌｉｇｎｅｄ  ｕｎｉｔ＃２を正しく復号する処理となる。
【０３１４】
復号鍵Ａを持つプレーヤでも、復号鍵Ｂを持つプレーヤでも、コンバータ４２０を通った後のストリームデータはｍ２ｔｓ形式になることが重要である。つまり、読み出したシステムストリームファイルのうちの、スクランブル区間（第一の区間）の復号できない他方のＡｌｉｎｇｅｄ  ｕｎｉｔ（第二のデータ単位）を構成する３２個のソースパケットを、連続した複数の無効なパケットである３２個のＮＵＬＬパケットに置き換えたシステムストリームに変換する変換処理を行い、変換後のシステムストリームを出力する。このように、デコーダ４３０に向けて必ずｍ２ｔｓ形式のシステムストリームが出力されることによりデコーダの再利用性を担保することができる。なお、変換処理では、スクランブル区間（第一の区間）を第一の復号鍵を用いて復号し、かつ、非スクランブル区間（第二の区間）を第二の復号鍵を用いて復号することにより、システムストリームファイルをｍ２ｔｓ形式のシステムストリームに変換する。
【０３１５】
また、復号できないＡｌｉｎｇｅｄ  ｕｎｉｔをＡｌｉｎｇｅｄ  ｕｎｉｔを構成していた複数のソースパケットと同サイズ及び同数のＮＵＬＬパケットと置き換える処理を行ったため、３２個のソースパケットを同じ３２個のＮＵＬＬパケットで置き換えることになる。このため、復号できる第一のデータ単位を構成する複数のソースパケットの位置を変換処理の前後において同一の位置に配置できる。よって、図３２の説明における最後に述べたようなアドレス計算が必要な暗号化処理が施されたストリームであってもパケット数の増減を発生させずに済む。これにより、デコーダ４３０に、これまで通り、正しく処理させることが可能となり、また、アドレス計算の再計算を行わなくても変換処理後のシステムストリームを再生できるため、処理負荷を低減できる。なお、このコンバータ４２０の処理は、ドライブ４１０とデコーダ４３０との間であれば、任意の位置に配置するように設計しても良い。
【０３１６】
図３５は、復号できない方のＡｌｉｇｎｅｄ  ｕｎｉｔのデータを３２個の連続なＮＵＬＬパケットに置き換える際に各ＮＵＬＬパケットに付与するＩｎｐｕｔ  Ｔｉｍｅの値について説明するための図である。
【０３１７】
ｓｃｔｓファイル内のスクランブル区間の２つのＡｌｉｎｇｅｄ  ｕｎｉｔのうち、復号できない方のＡｌｉｇｎｅｄ  ｕｎｉｔ（図ではＡｌｉｇｎｅｄ  ｕｎｉｔ＃２）に対応する３２個のＮＵＬＬパケットも、コンバータ４２０の後段に配置されるデコーダ４３０にて適切に処理できなければならない。Ｔ−ＳＴＤモデルでは、ＮＵＬＬパケットは、ＰＩＤフィルタリングの直後に即座に廃棄されるためバッファマネージメントは必要ないが、このＮＵＬＬパケットの転送レートがそのシステムストリームファイルの最大転送レート（図１３のＶＯＢＩファイルのＳｙｓＲａｔｅにてビット／秒の単位で記載されている値）を超えたり（図３５でＮＧ  ｃａｓｅ（ｔｏｏ  ｆａｓｔ））、３２個のＮＵＬＬパケットを転送した直後のＴＳパケットのＩｎｐｕｔ  Ｔｉｍｅが過去を指し示すようなこと（図３５でＮＧ  ｃａｓｅ（ｔｏｏ  ｌａｔｅ））があったりしてはならない。このため、変換処理では、３２個のＮＵＬＬパケットのそれぞれに、適切なＩｎｐｕｔ  Ｔｉｍｅ（システムターゲットデコーダへの入力時刻を示すタイムスタンプ）を付与する。
【０３１８】
ＩＴｉは、ＳＰＮｉのソースパケットのＩｎｐｕｔ  Ｔｉｍｅを示し、添え字のｉはｓｃｔｓファイル内の任意の１ソースパケットを示し、添え字のｕは復号できない方のＡｌｉｇｎｅｄ  ｕｎｉｔで最後に生成されるソースパケットを示し（図３５の例ではｓｃｔｓファイル先頭から９６番目のソースパケット（ＳＰ＃９５）など）、ＳｙｓＲａｔｅはこのＭＰＥＧ−２トランスポートストリームの最大ピークレート（ｂｉｔ／ｓｅｃｏｎｄ）を示すとした場合、復号できない方のＡｌｉｇｎｅｄ  ｕｎｉｔのデータを３２個の連続なＮＵＬＬパケットに置き換える際に各ＮＵＬＬパケットに付与するＩｎｐｕｔ  Ｔｉｍｅは、次の条件（１）〜（３）を満たす必要がある。
【０３１９】
条件（１）は、任意のソースパケットを転送する転送レートが０以上、ＳｙｓＲａｔｅ以下であることを満たすことである。つまり、変換処理では、３２個のＮＵＬＬパケットのそれぞれに、当該ＮＵＬＬパケットを転送する転送レートが、システムストリームファイルの最大転送レート以下であることを満たすタイムスタンプを付与する。
【０３２０】
なお、条件（１）は、下記の（式３）及び（式４）のように表される。
【０３２１】
【数１】
2020119623.tif 000003
【０３２２】
条件（２）は、復号できないＡｌｉｇｎｅｄ  ｕｎｉｔの対応データとして生成する３２個のＮＵＬＬパケットの最後のソースパケットのＩｎｐｕｔ  Ｔｉｍｅ（ＩＴ（ｕ））は、その直前のＡｌｉｇｎｅｄ  ｕｎｉｔの最後のソースパケットのＩｎｐｕｔ  Ｔｉｍｅ（ＩＴ（ｕ−３２））から３２個のＴＳパケットをＳｙｓＲａｔｅで伝送するのに必要な時間以上後の時間であることを満たすことである。ｄＩＴは１個のＴＳパケットをＳｙｓＲａｔｅで伝送するのに必要となる２７ＭＨｚ単位の時間であり、Ｃｅｉｌ（）は小数点以下切り上げの関数であるとした場合、条件（２）は、下記の（式４）及び（式５）のように表される。
【０３２３】
【数２】
2020119623.tif 000004
【数３】
2020119623.tif 000005
【０３２４】
条件（３）は、復号できないＡｌｉｇｎｅｄ  ｕｎｉｔの対応データとして生成する３２個のＮＵＬＬパケットの最後のソースパケットのＩｎｐｕｔ  Ｔｉｍｅ（ＩＴ（ｕ））は、その直後の復号可能なＴＳパケットのＩｎｐｕｔ  Ｔｉｍｅ（ＩＴ（ｕ＋１））よりもｄＩＴ分以上小さいことを満たすことである。つまり、変換処理では、一の復号できないＡｌｉｎｇｅｄ  ｕｎｉｔ（第二データ単位）において置き換えた３２個のＮＵＬＬパケットのうちの最後のＮＵＬＬパケットに、当該一の復号できないＡｌｉｎｇｅｄ  ｕｎｉｔの直後のソースパケットに格納されたＩｎｐｕｔ  Ｔｉｍｅ（つまり、当該一の復号できないＡｌｉｎｇｅｄ  ｕｎｉｔの直後のＴＳパケットに付与されたＩｎｐｕｔ  Ｔｉｍｅ）よりも、１つのＴＳパケットをシステムストリームファイルの最大転送レートで転送するのに要する時間以上前の時刻であることを満たすタイムスタンプを付与する。
【０３２５】
【数４】
2020119623.tif 000006
【０３２６】
コンバータ４２０は、これらの条件（１）〜（３）を満たすＩｎｐｕｔ  Ｔｉｍｅを持つ３２個の連続なＮＵＬＬパケットを生成することで、ｍ２ｔｓ（ＭＰＥＧ−２  Ｓｙｓｔｅｍ）準拠のシステムストリームを生成することができる。これにより、デコーダ４３０（Ｔ−ＳＴＤモデル準拠）は、復号できないＡｌｉｇｎｅｄ  ｕｎｉｔの箇所も含めて適切にデコードを継続することが可能となる。
【０３２７】
図３６は、特殊再生におけるパフォーマンスを担保するための多重化制約について説明するための図である。
【０３２８】
図３６の（ａ）は、ＶＯＢＩファイルのＴＭＡＰについて説明するための図である。
【０３２９】
図３６の（ａ）に示すように、ＶＯＢＩファイルのＴＭＡＰは、ＭＰＥＧ−２トランスポートストリーム用に修正されており、ランダムアクセスポイントとなるＩピクチャに対するＰＴＳを含む。つまり、システムストリームファイルに対応する管理情報ファイルとしてのＶＯＢＩファイルは、ランダムアクセスポイントとなるＩピクチャのＰＴＳ（提示時刻）を示すタイムマップを有する。また、当該ＴＭＡＰは、さらに、ランダムアクセスポイントとなるＩピクチャに対する先頭ソースパケット番号（Ｓｔａｒｔ  ＳＰＮ）を含む。つまり、当該ＴＭＡＰでは、さらに、Ｉピクチャが格納されている複数のソースパケットのうちの先頭のソースパケットを特定するＳｔａｒｔ  ＳＰＮが対応づけられている。また、当該ＴＭＡＰは、さらに、ランダムアクセスポイントとなるＩピクチャの多重化終了ソースパケットまでの距離を（ＴＭＡＰサイズ縮小のために）数段階のレベルで表す最終位置情報（Ｉ＿Ｅｎｄ）を含む。つまり、当該ＴＭＡＰでは、さらに、先頭のパケットからのパケット数であって、Ｉピクチャが格納されている複数のソースパケットが含まれることが保証されるパケット数を段階的に示すＩ＿Ｅｎｄが対応づけられている。
【０３３０】
図３６の（ｃ）には、Ｉ＿Ｅｎｄの値の夫々と、当該Ｉ＿Ｅｎｄの値が具体的にどれだけのソースパケット数に相当するのかの一例が示されている。つまり、図３６の（ｃ）は、Ｉ＿Ｅｎｄとソースパケット番号との関係を示す図である。図３６の（ｃ）に示すようにＩ＿Ｅｎｄの値に応じて、実際のＩピクチャ多重化パケット数が５０００パケット単位で段階的に割り振られている。なお、ここではＩ＿Ｅｎｄが１増える毎にソースパケット数が、５０００パケット単位で増加するように、Ｉ＿Ｅｎｄとソースパケット数とが対応づけられているとしたが、５０００パケット単位で増加しなくてもよく、他のパケット数の単位で増加しても良い。また、Ｉ＿Ｅｎｄが１増える毎にソースパケット数が、増加するように割り振られていれば良く、固定された所定のパケット数で増加していなくても良い。
【０３３１】
図３６の（ｂ）は、ＴＭＡＰのＳｔａｒｔ  ＳＰＮ、Ｉ＿Ｅｎｄを使ってＩ−ｐｉｃｔｕｒｅ  ＃１がｓｃｔｓファイルのどこに記録されているかを示している。つまり、図３６の（ｂ）は、ＴＭＡＰのＳｔａｒｔ  ＳＰＮ及びＩ＿Ｅｎｄにより示されるＩ−ｐｉｃｔｕｒｅ  ＃１のｓｃｔｓファイルにおける位置を示す図である。なお、Ｓｔａｒｔ  ＳＰＮはＩピクチャの先頭ソースパケットを正確に指し示すが、Ｉ＿Ｅｎｄは５０００パケット単位で表現するため、実際のＩ−ｐｉｃｔｕｒｅ  ＃１の多重化最終位置よりも後ろを指すこととなる。
【０３３２】
このようにしてＩピクチャのｓｃｔｓファイル内での多重化位置がＴＭＡＰにより取得できるが、ＴＭＡＰに登録されているＩピクチャがスクランブル区間に多重化されていると、早送りなどの特殊生成（トリックプレー）の際に復号鍵を交換する遅延が起こり、滑らかな特殊再生ができなくなってしまう。
【０３３３】
したがって、図３６に示すように、ＶＯＢＩファイルにおけるＴＭＡＰに登録されている全てのＩピクチャの多重化区間（Ｉピクチャのエントリごとに、Ｓｔａｒｔ  ＳＰＮから、Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００までの区間）に、スクランブル区間が発生しないようにＩピクチャを多重化する、もしくはスクランブル区間を調整することが効果的である。つまり、ＶＯＢＩファイルにおけるＴＭＡＰに登録されている全てのＩピクチャは、なめらかな特殊再生を実現するために、スクランブル区間において多重化されない。さらに、言い換えると、ＶＯＢＩファイルにおけるＴＭＡＰにおいてＰＴＳが示されている全てのＩピクチャは、非スクランブル区間（第二の区間）において多重化されている。より具体的には、Ｓｔａｒｔ  ＳＰＮで特定される、Ｉピクチャを構成する先頭のソースパケットは、非スクランブル区間（第二の区間）に配置されている。また、当該先頭のソースパケットから、Ｓｔａｒｔ  ＳＰＮ及びＩ＿Ｅｎｄで特定されるＩピクチャを構成する最終のソースパケット以降に配置されるソースパケットまでの区間は、非スクランブル区間（第二の区間）に配置されている。
【０３３４】
このため、コンバータ４２０は、全てのＩピクチャを、第二の復号鍵を用いて復号することにより、システムストリームファイルをｍ２ｔｓ形式のシステムストリームに変換することができる。このように、ｓｃｔｓファイルを構成することで復号鍵交換を回避し、ｍ２ｔｓファイルと同等の特殊再生レスポンスを実現することができる。
【０３３５】
図３７は、図３６よりも詳細に、情報記録媒体が光ディスクの場合の追加実施例を説明するための図である。
【０３３６】
図の最上段は、ｓｃｔｓファイルの構造であり、スクランブル区間とＩピクチャの多重化位置を例示している。図３６では説明しなかったが、ＤＶＤやＢｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃのような光ディスクは記録面の傷などに対する耐性を高めるために、ＥＣＣブロック単位でエラー訂正される。つまり、光ディスクには、システムストリームファイルが、当該光ディスクに記録されたＡＶデータを再生するプレーヤ（再生装置）に読み出される所定のデータ単位としてのＥＣＣブロック単位で記録されている。
【０３３７】
ドライブ４１０は、このＥＣＣブロック単位でしかアクセスすることができないため、ｓｃｔｓファイルの構成をスクランブル区間とＴＭＡＰで指定されたＩピクチャ多重化位置とが重ならない構成とするだけでは、実は完全には先程の特殊再生レスポンスの低下を防ぎきれてはいない。
【０３３８】
図３７の（ＮＧ−１）は、特殊再生レスポンスの低下を招くデータ構造の一例を示す図であり、最上段で示すｓｃｔｓファイルのスクランブル区間及びＩピクチャの多重化位置と、ＥＣＣブロックとの位置関係を示す図である。ここでは、Ａｌｉｇｎｅｄ  ｕｎｉｔ＃ｋ−１を含むスクランブル区間の最後のパケットと、Ｉピクチャの先頭パケット（Ｓｔａｒｔ  ＳＰＮ）とが、同じＥＣＣブロック（ＥＣＣ＃ｍ）に属している。したがって、プレーヤ４００は、特殊再生時にこのＩピクチャを再生するためにＳｔａｒｔ  ＳＰＮから読み込みを始めるが、ドライブ４１０としてはＥＣＣ単位での読み込み処理となるため、実際には当該Ｉピクチャが含まれるＡｌｉｎｇｅｄ  ｕｎｉｔ＃ｋの直前に配置されているスクランブル区間から読み込みを始めることとなる。その結果、復号鍵の交換による遅延が発生してしまい、特殊再生のレスポンスが低下してしまう。このような状況を避けるためには、図３７の（ＮＧ−１）のようなケースは回避されなければならない。
【０３３９】
図３７の（ＮＧ−２）は、特殊再生レスポンスの低下を招くデータ構造の別の一例を示す図であり、最上段で示すｓｃｔｓファイルのスクランブル区間及びＩピクチャの多重化位置と、ＥＣＣブロックとの位置関係を示す図である。ここでは、Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００で示されるＩピクチャの最後の多重化パケットと、この後にあるスクランブル区間の先頭パケットとが、同じＥＣＣブロック（ＥＣＣ＃ｎ）に属している。したがって、プレーヤ４００は、特殊再生時にこのＩピクチャを再生するためにＳｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００まで読み込むが、ドライブとしてはＥＣＣ単位での読み込み処理となるため、実際には当該Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００より後に配置されているスクランブル区間を含めて読み込みをすることとなる。その結果、復号鍵の交換による遅延が発生してしまい、特殊再生のレスポンスが低下してしまう。このような状況を避けるためには、図３７の（ＮＧ−２）のようなケースは回避されなければならない。
【０３４０】
このような図３７の（ＮＧ−１）や、図３７の（ＮＧ−２）のようなケースを防ぐには、図３６の制約であるＴＭＡＰに登録されている全てのＩピクチャの多重化区間内にスクランブル区間を配置しない条件を満たすことに加えて、次のような条件（１ａ）及び（１ｂ）を満たす必要がある。
【０３４１】
条件（１ａ）は、ＴＭＡＰに登録されるＩピクチャの先頭パケット（Ｓｔａｒｔ  ＳＰＮ）を含むＥＣＣブロックが、スクランブル区間を含んではならないことを満たすことである。
【０３４２】
条件（１ｂ）は、ＴＭＡＰに登録されるＩピクチャの多重化最終パケット保障位置（Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００）を含むＥＣＣブロックが、スクランブル区間を含んではならないことを満たすことである。
【０３４３】
つまり、Ｓｔａｒｔ  ＳＰＮで特定される先頭のソースパケットを含むＥＣＣブロックと、Ｓｔａｒｔ  ＳＰＮ及びＩ＿Ｅｎｄで特定される多重化最終パケット保障位置にあるソースパケットを含むＥＣＣブロックとは、スクランブル区間（第一の区間）の一部または全部を含まないことを満たした状態（非スクランブル区間（第二の区間）にのみ含まれる状態）で、システムストリームファイルは、光ディスクに記録されている必要がある。
【０３４４】
もしくは、ｓｃｔｓファイルを記録する光学ディスクがＢｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃであれば、１ＥＣＣブロック＝６４ＫＢであるため、次のような条件（２ａ）及び（２ｂ）を満たすデータ構造としても良い。
【０３４５】
条件（２ａ）は、ＴＭＡＰに登録されるＩピクチャの先頭パケット（Ｓｔａｒｔ  ＳＰＮ）の直前に位置するスクランブル区間の最終パケットのＳＰＮは、Ｓｔａｒｔ  ＳＰＮ−３４２以下を満たすことである。もしくは、当該スクランブル区間は、Ｓｔａｒｔ  ＳＰＮよりも６４ＫＢ以上前方で終了していることを満たすことである。
【０３４６】
条件（２ｂ）は、ＴＭＡＰに登録されるＩピクチャの多重化最終パケット保障位置（Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００）の直後に位置するスクランブル区間の先頭パケットのＳＰＮは、Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００＋３４２以上を満たすことである。もしくは、当該スクランブル区間は、Ｓｔａｒｔ  ＳＰＮ＋Ｉ＿Ｅｎｄ＊５０００よりも６４ＫＢ以上後方で開始していることを満たすことである。
【０３４７】
ここで、３４２パケットは、６４ＫＢをソースパケットの数で表したものであり、６４＊１０２４／１９２＝３４１．３３３．．．の算出結果である。
【０３４８】
尚、上記の説明は一例に過ぎず、当該技術者にとっては、様々な応用が適用できる。
【産業上の利用可能性】
【０３４９】
本発明では、強固な暗号技術導入のために、ストリームの記録フォーマットさえも異なるような大規模な変更を導入しても、プレーヤの実装負担やコスト上昇を抑えることを可能とする再生方法、再生装置及び記録媒体などとして有用である。
【符号の説明】
【０３５０】
２０２    光ピックアップ
２０３    プログラム記録メモリ
２０４    管理情報記録メモリ
２０５    ＡＶ記録メモリ
２０６    プログラム処理部
２０７    管理情報処理部
２０８    プレゼンテーション処理部
２０９    イメージプレーン
２１０    ビデオプレーン
２１１    合成処理部
３０２    プログラムプロセッサ
３０３    ＵＯマネージャ
３０４    管理情報記録メモリ
３０５    シナリオプロセッサ
３０６    プレゼンテーションコントローラ
３０７    クロック
３０８    イメージメモリ
３０９    トラックバッファ
３１０    デマルチプレクサ
３１１    イメージプロセッサ
３１２    ビデオプロセッサ
３１３    サウンドプロセッサ
４００    プレーヤ
４１０    ドライブ
４１１    ＥＣＣ復号器
４２０    コンバータ
４２１    変換器
４３０    デコーダ
４４１    バッファ
４４２    クロック
【図１】
2020119623.tif 000007
【図２】
2020119623.tif 000008
【図３】
2020119623.tif 000009
【図４】
2020119623.tif 000010
【図５】
2020119623.tif 000011
【図６】
2020119623.tif 000012
【図７】
2020119623.tif 000013
【図８】
2020119623.tif 000014
【図９】
2020119623.tif 000015
【図１０】
2020119623.tif 000016
【図１１】
2020119623.tif 000017
【図１２】
2020119623.tif 000018
【図１３】
2020119623.tif 000019
【図１４】
2020119623.tif 000020
【図１５】
2020119623.tif 000021
【図１６】
2020119623.tif 000022
【図１７】
2020119623.tif 000023
【図１８】
2020119623.tif 000024
【図１９】
2020119623.tif 000025
【図２０】
2020119623.tif 000026
【図２１】
2020119623.tif 000027
【図２２】
2020119623.tif 000028
【図２３】
2020119623.tif 000029
【図２４】
2020119623.tif 000030
【図２５】
2020119623.tif 000031
【図２６】
2020119623.tif 000032
【図２７】
2020119623.tif 000033
【図２８】
2020119623.tif 000034
【図２９】
2020119623.tif 000035
【図３０】
2020119623.tif 000036
【図３１】
2020119623.tif 000037
【図３２】
2020119623.tif 000038
【図３３】
2020119623.tif 000039
【図３４】
2020119623.tif 000040
【図３５】
2020119623.tif 000041
【図３６】
2020119623.tif 000042
【図３７】
2020119623.tif 000043