以下、この発明の実施の一形態について、下記の順序に従い説明する。
1.UMDビデオ規格について
2.UMDビデオ規格のプレーヤモデルについて
3.ムービープレーヤのイベントモデルについて
4.ムービープレーヤオブジェクトについて
5.スクリプトプログラムの例
6.ファイルの管理構造について
7.ディスク再生装置について
8.ムービープレーヤの状態遷移モデルについて
8−1.ムービープレーヤの状態の定義について
8−2.ムービープレーヤに状態遷移を発生させるメソッドについて
8−3.プレイリスト再生中のムービープレーヤの動作について
8−4.ムービープレーヤの再生復帰機能について
8−5.各データのライフサイクルについて
9.リソースファイルの切り換えについて
1.UMDビデオ規格について
先ず、理解を容易とするために、この実施の一形態に適用可能なシステムについて概略的に説明する。この発明の実施の一形態では、ECMAスクリプトと呼ばれるスクリプト言語を用いてプレーヤモデルを記述している。ECMAスクリプトは、ECMA(European Computer Manufacturers Association)により定められた、JavaScript(登録商標)に基づいたクロスプラットフォーム用のスクリプト言語である。ECMAスクリプトは、HTML文書との親和性が高いことと、独自のオブジェクトの定義が可能であるため、この発明によるプレーヤモデルに用いて好適である。
すなわち、従来からのDVDビデオでは、インタラクティブな機能を実現するための制御プログラムを記述するために、DVDビデオ規格で定義された汎用的ではないコマンドを用いていた。制御プログラムは、複数のファイルやデータファイルの中の複数の箇所、さらには、AVストリームファイル中に分散されて埋め込むようにされ、埋め込まれた制御プログラムが実行される条件や順序は、DVD規格で決められていた。
このようなDVDビデオのシステムでは、汎用的なコンテンツ制作システムを構築することが難しく、そのため、予め決められた脚本に当てはめてストーリーを作る、テンプレートを用いたコンテンツ制作を行っていた。そして、テンプレートでは対応できない、複雑なコンテンツを制作する場合には、先ず、コンテンツ制作システムそのものをカスタムメイドで作成していた。この発明の実施の一形態では、AVコンテンツを制御するために、汎用的で拡張性の高いスクリプト言語であるECMAスクリプトを用いることで、このような問題を解決している。
以下では、このECMAスクリプトを元にしたスクリプト言語を用いた、この発明の実施の一形態に基づく規格を、UMD(Universal Media Disc:登録商標)ビデオ規格と呼ぶ。また、UMDビデオ規格のうち、特にスクリプトに関する部分をUMDビデオスクリプト規格と呼ぶ。
UMDビデオ規格について、概略的に説明する。図1は、UMDビデオ規格のレイヤ構成を示す。UMDビデオ規格では、スクリプトレイヤ、プレイリストレイヤおよびクリップレイヤの3層のレイヤ構造が定義され、この構造に基づきストリーム管理がなされる。
UMDビデオ規格においては、ディジタル符号化されたビデオ、オーディオおよび字幕を、MPEG2(Moving Pictures Experts Group 2)のパケッタイズドエレメンタリストリームとして多重化したMPEG2ストリームとして扱う。このビデオ、オーディオおよび字幕のエレメンタリストリームが多重化されたMPEG2ストリームを、クリップAVストリーム(Clip AV Stream)と呼ぶ。クリップAVストリームは、クリップAVストリームファイルに格納される。クリップAVストリームファイルの記録時に、当該クリップAVストリームファイルに1対1に対応して、クリップインフォメーションファイル(Clip Information File)が同時に作成される。これらクリップインフォメーションファイルと、対応するクリップAVストリームファイルとからなる組を、クリップ(Clip)と呼ぶ。
クリップは、ディスクへの記録の単位ともいうべきものであり、再生時にどのような順序でクリップを再生するかは、クリップの上位のレイヤであるプレイリストレイヤで管理する。プレイリストレイヤは、クリップの再生経路を指定するレイヤであり、1または複数のプレイリスト(PlayList)を含む。プレイリストは、プレイアイテムの(PlayItem)の集合からなる。プレイアイテムには、クリップの再生範囲を示した一組のイン(In)点およびアウト(Out)点が含まれており、プレイアイテムを連ねることによって、任意の順序でクリップを再生することができるようになる。プレイアイテムは、クリップを重複して指定することができる。クリップAVストリームファイルのイン点およびアウト点は、タイムスタンプ(クリップ内時刻)で指定され、タイムスタンプは、クリップインフォメーションファイルの情報によってクリップAVストリーム上のバイト位置に変換される。
プレイリストは、クリップの全部または一部を指すプレイアイテムを順序に従って再生していく構造だけを有しており、プレイリストのみを用いて再生順の分岐や、ユーザとの双方向性を実現することは、できない。この発明の実施の一形態では、複数のプレイリストが1つのファイル"PLAYLIST.DAT"にまとめられている。
スクリプトレイヤは、言語仕様のECMAスクリプトを拡張した、UMDビデオスクリプトによって構築されるレイヤである。UMDビデオスクリプトは、ECMAスクリプトを基本として、UMDビデオに特有な機能を実現するための拡張を加えたスクリプトである。
スクリプトレイヤは、プレイリストレイヤの上位のレイヤであり、プレイリストの再生指示や、プレーヤ設定を行うコマンド列から構成される。スクリプトレイヤのコマンドにより、複数の言語用に用意されたストリームのうち何れを選択する、ある条件に従って選択されるプレイリストに再生の流れが変化する、というような、条件分岐を伴うプレイリスト再生を実現することができる。このような条件分岐を伴うプレイリスト再生が用いられるアプリケーションの例としては、マルチストーリーが挙げられる。このスクリプトレイヤにより、ユーザとの双方向性機能(インタラクティブ機能)が導入されることになる。
なお、この発明の実施の一形態では、スクリプトレイヤは、リソースファイルと呼ばれるファイルにより構成される。リソースファイルは、実際のECMAスクリプトに基づき記述されるスクリプトデータ(スクリプトプログラム)、ボタン操作の際の効果音などを出力するためのサウンドデータ、メニュー画面の背景画像などに用いる画像データからなるスクリーンデザイン、ならびに、ボタン画像などのGUI部品を表示させるための画像データ(ビットマップデータ)が含まれる。
リソースファイルは、複数、存在することができる。また、この実施の一形態においては、リソースファイルは、後述する所定の命名規則に従いファイル名が与えられ、例えば、ファイル名の拡張子「RCO」により当該ファイルがリソースファイルであることが示される。
2.UMDビデオ規格のプレーヤモデルについて
次に、UMDビデオ規格に従ったデータを再生する再生装置(プレーヤ)のモデル、すなわち、プレーヤモデルについて説明する。プレーヤは、先ず、ディスクからリソースファイル、プレイリストフィルおよびクリップインフォメーションファイルを読み出し、次に、これらにより定められている再生順序に従って、クリップAVストリームファイルを読み出し、ビデオ、オーディオおよび字幕などを再生する。
スクリプトプログラムの言語仕様においては、プレイリストを再生する機能ブロックを、スクリプトプログラム内のオブジェクトとして実装する。このプレイリスト再生を行うオブジェクトを、UMDビデオ規格では、ムービープレーヤ(Movie Player)オブジェクトと呼ぶ。プレイリストの再生指示や、プレーヤ設定を行うコマンドは、このムービープレーヤオブジェクトが有するメソッドとなる。ムービープレーヤオブジェクトは、スクリプトレイヤからのメソッドによって制御される。このとき、ムービープレーヤオブジェクトからスクリプトレイヤに対して、状態の変化や再生位置などを通知する機能が必要となる。これは、ムービープレーヤオブジェクトがスクリプトプログラムに対してイベントを発することに対応し、そのイベントに対応した処理は、イベントハンドラとして記述される。
このように、ムービープレーヤオブジェクトからスクリプトプログラムへの情報伝達は、イベントにより行い、スクリプトプログラムからムービープレーヤオブジェクトに対する制御をメソッドにより行うモデルを構築することにより、クリップAVストリームの再生をスクリプトプログラムで制御できるようになる。
図2は、上述した、この発明の実施の一形態による一例のプレーヤモデルを模式的に示す。ムービープレーヤ300は、UMDビデオ規格においてビデオ、オーディオおよび字幕の再生を司るモジュールである。上述したムービープレーヤオブジェクトは、ムービーオブジェクトをスクリプトプログラムから操作するためにスクリプトプログラム内のオブジェクトとしたものである。換言すれば、ムービープレーヤオブジェクトは、ムービープレーヤの機能を実現する実装モジュールを抽象化してスクリプトプログラム上で扱える形にしたものである。
なお、ムービープレーヤ300とムービープレーヤオブジェクトは、実質的に同一の対象を表すと考えられるので、以下、これらを同一の符号を付して説明する。
図2において、ムービプレーヤ300は、ユーザ入力310などにより引き起こされる下位レイヤ(図2の例ではネイティブ実装プラットフォーム301)や、上位レイヤであるスクリプトレイヤ302からのメソッドに従って、プレイリストおよびクリップインフォメーションのデータベースに基づき、クリップAVストリームファイルの読み出し、読み出されたクリップAVストリームのデコードおよび表示を行う。
ムービープレーヤオブジェクト300の内部は、UMDビデオを再生するUMDビデオプレーヤの実装に依存するものであって、スクリプトレイヤ302からは、ブラックボックス化されたオブジェクトとして、メソッドやプロパティといったAPI(Application Programming Interface)が提供される。ここで、UMDビデオプレーヤ(UMD Video Player)は、ムービープレーヤを実装した実際の機器を指す。全てのUMDビデオプレーヤは、UMDビデオ規格の制約を守ってムービープレーヤを実装しており、再生互換を有する。
図2に示されるように、ムービープレーヤオブジェクト300は、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付けるパス、スクリプトレイヤ302に対してイベント312を通知するパス、スクリプトレイヤ302からのメソッド313を受け付けるパスの、3本の入出力パスを有する。
制御コマンド311は、ネイティブ実装のプラットフォーム301からの、ムービープレーヤオブジェクト300の動作を制御するコマンドである。ネイティブ実装プラットフォーム301は、例えば、実際の機器としてのUMDビデオプレーヤにおける、機器に固有の部分とムービープレーヤ300とのインターフェイスである。イベント312は、ムービープレーヤ300からスクリプトレイヤ302に対するスクリプトイベントである。メソッド313は、スクリプトレイヤ302のスクリプトプログラムからムービープレーヤ300に指示されるメソッドである。
ムービープレーヤオブジェクト300は、内部に、UMDビデオ規格のプレイリストおよびクリップインフォメーションのデータベース320を有する。ムービープレーヤオブジェクト300は、このデータベース320を用いて、ユーザ入力310に対する無効化(mask)や、時刻で指定された再生位置をクリップAVストリーム内のバイト位置に変換する処理などを行う。
ムービープレーヤオブジェクト300内のプレイバックモジュール321は、ビデオ、オーディオおよび字幕が多重されたMPEG2 PS(Program Stream)であるクリップAVストリームのデコードを行う。プレイバックモジュール321は、プレイおよびストップの2状態を持ち、制御命令やメソッドによって、この2状態の間を遷移する(図3参照)。なお、クリップAVストリームは、MPEG2 PSに限られない。例えば、クリップAVストリームとしてMPEG2 TS(Transport Stream)を用いても、モデル上は同様に扱うことができる。
スクリプトレイヤ302は、UMDビデオスクリプト規格に基づくスクリプトプログラムを実行し、ムービープレーヤオブジェクト300の制御や、画面表示を行うレイヤである。このスクリプトレイヤ302は、コンテンツ制作者側の意図したシナリオを実現する役割を果たす。スクリプトレイヤ302は、ムービープレーヤオブジェクト300に対してメソッド313を発行し、ムービープレーヤオブジェクト300からは、イベント312を受け取る。スクリプトレイヤ302は、ネイティブ実装プラットフォーム301との間で、ユーザ入力310に応じたキーイベント314や、画面描画などをネイティブ実装プラットフォーム301に対して指示するメソッド315などのやりとりを行う。
なお、ネイティブ実装プラットフォーム301は、UMDビデオ規格で規定した以外の様々な機能を有する。この発明の実施の一形態では、、スクリプトレイヤ302からネイティブ実装プラットフォーム301に働きかけるメソッド315が存在するため、ネイティブ実装プラットフォーム301にも、機能を抽象化したオブジェクトを定義し、メソッド315は、スクリプトプログラム上では、このオブジェクトに属するものと見なす。これは、メソッドは、オブジェクトに属するからである。そこで、ネイティブ実装プラットフォーム301内にコントロールオブジェクト330を定義し、メソッド315は、コントロールオブジェクト330のメソッドであると定める。
例えば、メニュー画面上に配置されるボタンは、スクリプトレイヤ302のスクリプトプログラムからネイティブ実装プラットフォーム301に渡されるメソッド315に基づき、ネイティブ実装プラットフォーム301により描画される。ユーザがそのボタンに対して選択や決定などの操作を行ったときには、ユーザ入力310に応じたキーイベント314がネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知され、スクリプトレイヤ302内のスクリプトプログラムは、キーイベント314に基づきキー入力310に応じた処理を行う。
このように、ビデオ、オーディオおよび字幕のデコードや表示制御はムービープレーヤ300が司り、ボタンなどのGUI(Graphical User Interface)を構成するための部品画像(以下、GUI部品と呼ぶ)の配置や表示、ならびに、GUI部品に対して選択や決定などの操作がなされたときの処理は、スクリプトレイヤ302が行うというように、役割分担がなされている。
ネイティブ実装プラットフォーム301は、ムービープレーヤオブジェクト300やスクリプトプログラムが動作するための基盤となるプラットフォームであって、例えば、実際のUMDビデオプレーヤがハードウェアである場合、ハードウェアとプレーヤモデルとの間の処理を仲介する役割を果たすように、ハードウェアに固有に実装される。
例えば、ネイティブ実装プラットフォーム301は、ユーザからのユーザ入力310を受け付け、受け付けたユーザ入力310がムービープレーヤ300に対する命令なのか、スクリプトレイヤ302で描画および表示しているボタンに対する命令なのかを判定する。ネイティブ実装プラットフォーム301は、ユーザ入力310がムービープレーヤ300に対する命令であると判定されれば、ユーザ入力310をムービープレーヤ300に対する内部制御命令である制御コマンド311に変換し、ムービープレーヤ300に対して制御命令を発する。
一方、ネイティブ実装プラットフォーム301は、ユーザ入力310がスクリプトレイヤ302で描画および表示しているGUI部品に対する命令であると判定されれば、ユーザ入力310に応じたキーイベント314をスクリプトレイヤ302に通知する。そして、このキーイベント314に応じてスクリプトレイヤ302から指示されたメソッド315に基づき、例えば画面上にボタン画像を表示させることができる。すなわち、ネイティブ実装プラットフォーム301とスクリプトレイヤ302とは、ムービープレーヤ300を介さずに、直接的にイベントおよびメソッドの受け渡しを行うことができる。
また例えば、ネイティブ実装プラットフォーム301は、後述するような、ムービープレーヤ300のプロパティにアクセスし、ムービープレーヤ300のステータスを見ることができるようにされている。
次に、ムービープレーヤ300についてより詳細に説明する。図3は、ムービープレーヤ300の一例の内部構成を示す。上述したように、ムービープレーヤ300は、データベース320およびプレイバックモジュール321とから構成される。データベース320は、ディスクから読み取ったプレイリストの情報と、クリップの情報すなわちクリップインフォメーションとを格納する領域である。
プレイバックモジュール321は、デコーダエンジン322と、プレイバックモジュール321の状態を表す値であるプロパティ323とからなる。プロパティ323は、例えば言語コードのように、ムービープレーヤ300の初期設定で値が決まるプロパティ323A(リードオンリーパラメータ)と、プレイバックモジュール321の状態によって値が変化するプロパティ323B(プレーヤステータス)の2種類がある。
初期設定で値が決まるプロパティ323Aは、ネイティブなシステム、例えば実際の機器によって値がセットされ、プレイリストやクリップインフォメーション、スクリプトプログラムから値を変更されることがない。プロパティ323Aは、スクリプトプログラムから値を読み出すことのみが可能とされる。一方、プレイバックモジュール321の状態を表すプロパティ323Bは、スクリプトプログラムから値を読み出すことができると共に、一部のスクリプトプログラムから値を書き込むことが可能とされる。
なお、この動作モデルにおいては、プレイリストおよびクリップインフォメーションは、クリップAVストリームの再生前にディスクからプリロードされていることを想定している。これに限らず、他の実装であっても、ムービープレーヤモデルで定めた動作を実現できていればよい。
ムービープレーヤオブジェクト300は、スクリプトレイヤ302またはネイティブ実装プラットフォーム301からの指示に従い、指定されたプレイリストを再生する。例えば、ムービープレーヤ300は、データベース320を参照し、指定されたプレイリストに対応するクリップAVストリームの再生位置をファイル中のバイト位置で得る。プレイバックモジュール321において、デコーダエンジン322は、この再生位置情報に基づき、クリップAVストリームのデコードを制御する。
ムービープレーヤ300は、図4に示されるように、プレイリストの再生状況に応じてプレイ(play)およびストップ(stop)の2状態を持つ。プレイ状態は、プレイリストが指定され、プレイリストの再生を行っている状態を指す。通常再生の他、2倍速、1/2倍速といった変速再生や、順方向早送りおよび逆方向早送り、一時停止(ポーズ)といった各種の状態(status)がプレイ状態に含まれる。再生をフレーム単位で進めたり戻したりする所謂コマ送り再生は、ポーズ状態とプレイ状態とを繰り返している状態である。ストップ状態は、プレイリストを再生していない状態である。ストップ状態においては、プレイリストが選択されておらず、「現在再生中のプレイリスト番号」を表すプレーヤステータスの値は、不定である。
例えば、ムービープレーヤ300の状態は、ムービープレーヤ300内のデコーダエンジン322におけるプレイおよびストップの状態遷移に伴うもので、デコーダエンジン322の状態遷移に応じてプロパティ323Bの値が更新される。
リジュームインフォメーション324は、ストップ状態直前の状態を記憶する。例えば、ムービープレーヤ300があるプレイリストをデコードしプレイ状態となっているときに、状態がストップ状態に遷移すると、ストップ状態の直前の状態を記憶する。また、リジュームインフォメーション324は、ハードウェアとしてのプレーヤが持つ不揮発性メモリに、ディスクのタイトル毎に識別可能なように複数を記憶させることができる。例えば、ディスクは、ディスクのタイトル毎にユニークな識別情報(タイトルIDと呼ぶ)を有し、リジュームインフォメーション324をこの識別情報と関連付けて記憶する。こうすることで、リジュームインフォメーション324の情報に基づき、識別情報が対応するタイトルのディスクが次にストップ状態からプレイ状態に遷移したときに、当該ディスクの再生を、以前ストップ状態になった直前の位置から開始させることができる。
3.ムービープレーヤのイベントモデルについて
ムービープレーヤ300のイベントモデルについて説明する。ムービープレーヤ300は、プレイリストを再生するプレイ状態で、様々なイベントを発生する。このイベントは、イベントハンドラと呼ばれる、スクリプトで記述された処理プログラムの実行を引き起こす。イベントハンドラは、イベント発生によって呼び出されるメソッドである。このイベント発生によって処理プログラムの実行を開始するプログラム実行モデルを、イベントドリブンモデルと呼ぶ。イベントドリブンモデルでは、不定期なイベントが発生し、イベント発生をきっかけに用意しておいたプログラムが実行される。この実施の一形態においては、スクリプトプログラムは、イベントハンドラ群によってムービープレーヤオブジェクト300の動作を制御する。
図5は、この発明の実施の一形態によるムービープレーヤ300のイベントモデルを模式的に示す。図5において、イベントハンドラonEventA()、onEventB()およびonEventC()は、インターフェイスであって、それぞれのイベントハンドラの内容は、スクリプトで記述されている。イベントハンドラの内容は、例えばコンテンツ制作者側で作成され実装される。UMDビデオスクリプト規格においては、ムービープレーヤオブジェクト300からスクリプトプログラムに通知されるイベント毎に、イベントハンドラが用意される。図5の例では、イベントAが発生したときに実行される処理プログラムは、イベントハンドラonEventA()に決められている。イベントBおよびイベントCについても同様に、イベントBの発生時には対応するイベントハンドラonEventB()が実行され、イベントCの発生時には対応するイベントハンドラonEventC()が実行される。
イベント発生に応じて呼び出されるイベントハンドラは、システム側で選択されるため、コンテンツ制作者側では、どのイベントが発生したかを判断する処理を、スクリプトプログラム内に記述しておく必要が無い。
図6は、プレイリストの再生中に発生する一例のイベントを示す。プレイリストPlayListの先頭には、チャプタマークChapterMarkが設定されているので、プレイリストの先頭からの再生開始時には、先ず、チャプタマークに対応したイベントChapterが発生する。さらに、チャプタが変わる度にイベントChapterがスクリプトレイヤ302に通知され、対応するイベントハンドラonChapterが実行される。また、イベントマークEventMarkが設定されている時刻に再生が到達すると、対応するマークイベントが発生する。そして、プレイリストの最後まで再生が到達すると、プレイリストの最後で再生が一時停止し、イベントPlayListEndがムービープレーヤ300からスクリプトレイヤ302に通知される。スクリプトレイヤ302側では、対応するイベントハンドラonPlayListEnd()内で、別のプレイリストの再生開始が指示される。このようにして、コンテンツ制作者が意図した順序で、一連のプレイリスト再生が継続されていく。
このように、プレーヤの動作中にはさまざまなイベントが発生するものとし、イベント発生を上位プログラムに伝えることで、上位プログラムはプレーヤの状態を把握できるようになる。上位プログラムの方では、各イベント発生通知時に実行されるプログラム(イベントハンドラ)を用意しておくことで、各種イベント発生に対処する。イベントおよびイベントハンドラの詳細については、後述する。
イベントハンドラがコンテンツ制作者によって記述されていない場合には、規格で規定されているプレーヤ組み込みの動作(デフォルトのイベントハンドラ)を実行するか、あるいは、そのイベントが無視され何も実行されない。何も処理を行う必要がないときには、イベントに対応したイベントハンドラを記述しないようにすることで、積極的にイベントを無視することができる。
イベントモデルとしては、上述の他に、あるイベントに対応するリスナをオブジェクトがプレーヤオブジェクトに登録し、プレーヤオブジェクト内で発生したイベントが登録されたイベントであれば、プレーヤオブジェクトから当該イベントを登録したオブジェクトにイベントを送信し、当該オブジェクトで対応するメソッドを実行するようにしたイベントリスナのモデルや、どのようなイベントが発生しても一つのメソッドを呼び出すようにした単一メソッドのモデルなどが考えられる。
この実施の一形態によるイベントモデルは、イベント登録、イベント登録削除といった処理が必要なイベントリスナのモデルよりも簡単である。また、単一メソッドのモデルは、どのイベントが発生したかを知り、イベント毎に用意してある処理ルーチンを切り替えるという前処理を、そのメソッドの中に記述しておく必要がある。メソッドは、コンテンツ制作者側が実装するものであるから、モデルとしては簡単でも、コンテンツ制作者側の負担が大きくなる。さらに、大きな一つの処理プログラム(メソッド)がイベントの発生毎に呼ばれることになり、メモリの領域を多く占有し、実行速度も遅くなると考えられる。この発明の実施の一形態による、イベント毎に処理プログラム(イベントハンドラ)を用意するモデルでは、このような点について有利であるといえる。
4.ムービープレーヤオブジェクトについて
次に、ムービープレーヤオブジェクト300の外部的な仕様について説明する。一般に、ECMAスクリプト言語仕様に従う言語により定義されたオブジェクトは、プロパティとメソッドとを持つ。この実施の一形態によるムービープレーヤオブジェクト300も、図2および図3を用いて既に説明したように、同様にしてプロパティとメソッドとを有する。プロパティは、外部のオブジェクトから、対象となるオブジェクト名とプロパティ名とを指定することで、直接的に読み書きすることが可能である。これに限らず、プロパティ値の設定を行うメソッドsetXXX()(「XXX」は、対象のプロパティ名)や、プロパティ値の読み出しを行うメソッドgetXXX()を定義することで、他のオブジェクトのプロパティの読み書きを、メソッドで行うことが可能となる。
図7は、ムービープレーヤオブジェクト300が有する一例のプロパティを一覧して示す。これは、図3におけるプロパティ323に対応する。図7Aは、図3におけるリードオンリーパラメータ323Aに属する一例のプロパティを示す。プロパティscriptVersionは、UMDビデオスクリプト(UMD Video Script)のバージョンを示す。プロパティaudioChannelCapabilityは、UMDビデオプレーヤが再生可能なオーディオチャンネル数を示す。プロパティlanguageCodeは、UMDビデオプレーヤに設定された、メニュー表示言語の言語コードを示す。プロパティaudioLanguageCodeは、UMDビデオプレーヤに設定された、オーディオ言語の言語コードを示す。プロパティsubtitleLanguageCodeは、UMDビデオプレーヤに設定された、字幕(サブタイトル)言語の言語コードを示す。
ディスクが装填された際には、このリードオンリーパラメータ323Aに設定されたプロパティlanguageCodeに示される言語コードに基づき、ディスクから読み出すスクリプトファイルが決められる。装填されたディスクに、当該言語に対応するスクリプトファイルがない場合は、デフォルトのスクリプトファイルが読み出される。例えば、複数のスクリプトファイルのうち、ディスク上で最も先頭側に配置されるファイルがデフォルトのスクリプトファイルとして読み出される。
図7Bは、図3におけるプレーヤステータス323Bに属する一例のプロパティを示す。プロパティplayListNumberは、現在再生中のプレイリストの番号を示す。プロパティchapterNumberは、現在再生中のチャプタの番号を示す。プロパティvideoNumberは、現在再生中のビデオストリームの番号を示す。プロパティaudioNumberは、現在再生中のオーディオストリームの番号を示す。プロパティsubtitleNumberは、現在再生中の字幕ストリームの番号を示す。プロパティplayListTimeは、プレイリスト先頭を0としたときの時刻を示す。プロパティaudioFlagは、オーディオ再生のON/OFFおよびデュアルモノLRの指定を示す。プロパティsubtitleFlagは、字幕表示のON/OFFを示す。
なお、デュアルモノ(dual mono)は、ステレオオーディオの左右(L、R)チャンネルを、互いに独立したモノラルオーディオチャンネルとして用いるモードである。
このプレーヤステータス323Bに属する各プロパティは、ムービープレーヤ300が再生または一時停止状態のときに、これらの情報が存在する。停止状態に遷移した場合、その時点でプレーヤステータス323Bに属する各プロパティは、リジュームインフォメーション(resumeInformation)324としてバックアップされる。このとき、プレーヤステータス323Bの内容をクリアしてもよい。
図8は、ムービープレーヤオブジェクト300が有する一例のメソッドを一覧して示す。これは、図2におけるメソッド313に対応する。メソッドplay()は、ビデオを再生する。メソッドplayChapter()は、チャプタを指定してビデオを再生する。メソッドresume()は、リジュームインフォメーション324を用いた再生開始を行う。メソッドstop()は、ビデオの再生を停止する。メソッドpause()は、ビデオの再生を一時停止する。メソッドplayStep()は、ビデオをコマ送り再生する。メソッドchangeStream()は、ビデオストリーム、オーディオストリームおよび/または字幕ストリームを変更する。メソッドgetPlayerStatus()は、ムービープレーヤ300における再生、停止、一時停止などの状態を取得する。メソッドchangeResumeInfo()は、リジュームインフォメーション324の内容を変更する。メソッドreset()は、ビデオの再生を停止し、リジュームインフォメーション324の内容をクリアする。
UMDビデオ規格では、表示画面上の一部分にビデオを表示することができるようになっている。以下の4つのメソッドは、この場合のビデオ表示に関するメソッドである。メソッドsetPos()は、ビデオの表示位置を設定する。メソッドgetPos()は、ビデオの表示位置を取得する。メソッドsetSize()は、ビデオの表示サイズを設定する。メソッドgetSize()は、ビデオの表示サイズを取得する。
なお、実際には、ムービープレーヤ300とネイティブ実装プラットフォーム301とは、一体的に構成される。すなわち、実際にディスクが装填され、これを再生するハードウェアとしてのUMDプレーヤと、UMDプレーヤを制御するソフトウェアとの関係に対応付けられ、どの部分をハードウェアで行い、どの部分をソフトウェアで行うかは、実装時の構成に依存する。例えば、UMDプレーヤをパーソナルコンピュータなどで構成する場合は、ディスクドライブ以外は、ソフトウェア的に構成することができる。また、単体のUMDプレーヤとして構成する場合は、ディスクドライブ以外に、例えばビデオデコーダやオーディオデコーダなどをハードウェア的に構成することができる。したがって、ムービープレーヤ300とネイティブ実装プラットフォーム301との間でなされるメソッドやコマンド、イベントは、図2に一例が示されるような明示的なやりとりに限られない。
一方、ユーザからのキー入力については、図2を用いて既に説明したように、ユーザ入力310をネイティブ実装プラットフォーム301が先ず、受け取る。つまり、ネイティブ実装プラットフォーム301は、ユーザからのキー入力をユーザ入力310として受け取り、ユーザ入力310がムービープレーヤ300に対するコマンドなのか、スクリプトレイヤ302のスクリプトプログラムに対するイベントなのかを判定し、判定結果に応じて、制御コマンド311またはキーイベント314を発生し、対応する上位レイヤ(ムービープレーヤ300またはスクリプトレイヤ302)に通知する。
図9および図10は、ユーザ入力310による一例のキー入力を示す。なお、図9および図10に示される「VK」で始まる各キーは、仮想的なキー(Virtual Key)であることを意味する。
図9は、ムービープレーヤ300の操作に関する一例のキー入力を示す。キーVK_PLAYは、再生を指示する再生キーに対応する機能を提供する。キーVK_STOPは、再生の停止を指示する停止キーに対応する機能を提供する。キーVK_PAUSEは、再生の一時停止を指示する一時停止キーに対応する機能を提供する。キーVK_FAST_FORWARDは、早送り再生を指示する早送りキーに対応する機能を提供する。キーVK_FAST_REVERSEは、早戻し再生を指示する早戻しキーに対応する機能を提供する。キーVK_SLOW_FORWARDは、順方向のスロー再生を指示するスロー(順方向)キーに対応する機能を提供する。キーVK_SLOW_REVERSEは、逆方向のスロー再生を指示するスロー(逆方向)キーに対応する機能を提供する。キーVK_STEP_FORWARDは、順方向のコマ送り再生を指示するコマ送り(順方向)キーに対応する機能を提供する。キーVK_STEP_REVERSEは、逆方向のコマ送り再生を指示するコマ送り(逆方向)キーに対応する機能を提供する。
キーVK_NEXTは、「次」を意味する値を入力する次指定キーに対応する機能を提供する。キーVK_PREVIOUSは、「前」を意味する値を入力する前指定キーに対応する機能を提供する。例えば、キーVK_NEXTおよびキーVK_PREVIOUSを用いて、前後のチャプタへの移動を指示することができる。
キーVK_ANGLEは、マルチアングルのビデオに対するアングル切り替えを指示するアングル切り替えキーに対応する機能を提供する。キーVK_SUBTITLEは、英語字幕、日本語字幕、字幕表示/非表示などを切り替える字幕切り替えキーに対応する機能を提供する。キーVK_AUDIOは、サラウンドやバイリンガルなどオーディオ設定を切り替えるオーディオ切り替えに対応する機能を提供する。キーVK_VIDEO_ASPECTは、ビデオのアスペクト比切り替えを指示するアスペクト切り替えキーに対応する機能を提供する。
図10は、メニュー操作に関する一例のキー入力を示す。キーVK_UPは、「上」を意味する値を入力する上方向指定キーに対応する機能を提供する。キーVK_DOWNは、「下」を意味する値を入力する下方向指定キーに対応する機能を提供する。キーVK_RIGHTは、「右」を意味する値を入力する右方向指定キーに対応する機能を提供する。キーVK_LEFTは、「左」を意味する値を入力する左方向指定キーに対応する機能を提供する。キーVK_UP_RIGHTは、「右斜め上」を意味する値を入力する右上方向指定キーに対応する機能を提供する。キーVK_UP_LEFTは、「左斜め上」を意味する値を入力する左上方向指定キーに対応する機能を提供する。キーVK_DOWN_RIGHTは、「右斜め下」を意味する値を入力する右下方向指定キーに対応する機能を提供する。キーVK_DOWN_LEFTは、「左斜め下」を意味する値を入力する左下方向指定キーに対応する機能を提供する。これらの方向キーを用いることで、例えば画面上のカーソル表示の移動を指示することができる。
キーVK_MENUは、メニューを表示させるメニューキーに対応する機能を提供する。キーVK_ENTERは、「決定」を指示する決定キーに対応する機能を提供する。キーVK_RETURNは、処理のステップを一つ戻す戻るキーに対応する機能を提供する。
キーVK_COLORED_KEY_1は、色つきファンクションキー1、キーVK_COLORED_KEY_2は、色つきファンクションキー2、キーVK_COLORED_KEY_3は、色つきファンクションキー3、キーVK_COLORED_KEY_4は、色つきファンクションキー4、キーVK_COLORED_KEY_5は、色つきファンクションキー5、キーVK_COLORED_KEY_6は、色つきファンクションキー6にそれぞれ対応する機能を提供する。
上述の図9に示したキー入力と図10に示したキー入力とでは役割が異なるため、通知先をネイティブ実装プラットフォーム301で振り分ける必要がある。上述したように、図9に示されるキー入力により、ビデオ、オーディオおよび字幕の再生に関する指示がなされる。ネイティブ実装プラットフォーム301は、ユーザ入力310として図9に示されるキー入力を受け取ると、受け取ったキー入力を、図11に示すコマンドに変換してムービープレーヤ300に通知する。
一方、図10に示されるキー入力は、GUIに対するユーザ入力310であるので、このユーザ入力は、画面構成やボタンを配置するスクリプトレイヤ302に通知されて処理される必要がある。ネイティブ実装プラットフォーム301は、ユーザ入力310として図10に示されるキー入力を受け取ると、図2におけるイベント314に変換してスクリプトレイヤ302に通知する。図12は、このキー入力に対応する一例のイベント314を示す。
なお、上述した図9および図10には、キーVK_ANGLE、キーVK_SUBTITLE、キーVK_AUDIOという、ストリーム切り替えに関するキー入力も含まれている。これらは、先ずユーザ入力310がムービープレーヤ300に伝えられ、ムービープレーヤ300からスクリプトにストリーム切り換え要求があったことを示すイベントが通知される。そして、スクリプトプログラムからムービープレーヤ300に対するストリーム切り換えのメソッドで、オーディオや字幕が切り替わるようにしている。そのため、ネイティブ実装プラットフォーム301からムービープレーヤ300に対して伝えられるべきキー入力である。
上述した図11のコマンドについて、より詳細に説明する。コマンドuo_timeSearch(playListTime)は、再生中のプレイリストの指定時刻からの再生を指示する。引数playListTimeは、プレイリストの先頭を0としたときの時刻を表す。このコマンドでは、プレイリスト番号の指定はできないため、引数playListTimeで表される時刻は、現在再生中のプレイリストの範囲内での指定時刻となる。コマンドuo_play()は、1倍速での再生開始を指示する。開始位置は、リジュームインフォメーション324に基づき決められる。リジュームインフォメーション324に対応する情報が無い場合は、このユーザ操作は無効とされる。このコマンドは、プレイリスト番号の指定の無いメソッドplay()を実行したときに対応する。また、このコマンドにおいて、ユーザ操作ではプレイリスト番号を指定できない。
コマンドuo_playChapter(chapterNumber)は、再生中のプレイリストの、引数chapterNumberで指定されたチャプタからの再生開始を指示する。チャプタの指定がない場合には、現在再生中のチャプタの先頭からの再生開始を指示する。これは、チャプタ番号の指定の無いメソッドplayChapter()に対応する。コマンドuo_playPrevChapter()は、現在よりも一つ前のチャプタからの再生開始を指示する。コマンドuo_playNextChapter()は、現在の次のチャプタからの再生開始を指示する。
コマンドuo_jumpToEnd()は、プレイリストの最後へのジャンプを指示する。このコマンドは、ムービープレーヤ300に対して、現在の再生を中止してイベントplayListEndを発生させるように指示するユーザ操作に対応する。このコマンドに対応して、スクリプトレイヤ302では、イベントハンドラonPlayListEndが実行される。コマンドuo_forwardScan(speed)は、引数speedで指定された再生速度での順方向再生を指示する。コマンドuo_backwardScan(speed)は、引数speedで指定された再生速度での逆方向再生を指示する。これらコマンドuo_forwardScan(speed)およびコマンドuo_backwardScan(speed)における引数speedは、UMDビデオプレーヤの実装に依存する。
コマンドuo_playStep(forward)は、順方向のコマ送り再生を指示する。コマンドuo_playStep(backward)は、逆方向のコマ送り再生を指示する。コマンドuo_pauseOn()は、ユーザ操作に基づき再生の一時停止を指示する。コマンドuo_pauseOff()は、ユーザ操作に基づき再生の一時停止状態を解除する。
コマンドuo_setAudioEnabled(boolean)は、オーディオストリームのON/OFFを指定する。このコマンドの実行時に、フラグaudioFlagの値も対応した内容に変更する。コマンドuo_setSubtitleEnabled(boolean)は、字幕ストリームのON/OFFを指定する。このコマンドの実行時に、フラグsubtitleFlagの値も対応した内容に変更する。コマンドuo_angleChange()は、表示アングルの変更を指示する。このコマンドによるユーザ操作がムービープレーヤ300に伝えられると、ムービープレーヤ300は、スクリプトレイヤ302に対してイベントangleChangeを通知する。コマンドuo_audioChange(audioStreamNumber)は、再生するオーディオストリームの変更を指示する。コマンドuo_changeAudioChannel(value)は、オーディオのチャンネル切り換えまたはデュアルモノ再生時の片チャンネル切り替えを指示する。このコマンドの実行時に、フラグaudioFlagの値も対応した内容に変更する。コマンドuo_subtitleChange(subtitleStreamNumber)は、再生する字幕ストリームの変更を指示する。
上述した図12に示すイベントおよびイベントのムービープレーヤ300のメソッドとの関係について、より詳細に説明する。イベントmenuは、メニューにジャンプする。このイベントは、ムービープレーヤ300に対してではなく、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知される。このイベントmenuがスクリプトレイヤ302に受け取られると、スクリプトレイヤ302は、イベントハンドラonMenuを実行する。イベントexitは、ネイティブ実装プラットフォーム301がUMDビデオアプリケーションを終了させる際に、ネイティブ実装プラットフォーム301から発せられるイベントである。このイベントexitがスクリプトレイヤ302に受け取られると、スクリプトレイヤ302は、イベントハンドラonExitを実行する。
イベントresourceChangedは、リソースファイルの切り換えが発生したときに、ネイティブ実装プラットフォーム301から発せられるイベントである。このイベントresouceChangedがスクリプトレイヤ302に受け取られると、スクリプトレイヤ302は、イベントハンドラonResourceChangedを実行する。
イベントup、イベントdown、イベントleft、イベントright、イベントfocusIn、イベントfocusOut、イベントpushおよびイベントcancelは、画面に表示されているGUI部品であるボタン画像にフォーカスが当たっている場合に発生するイベントである。このイベントは、ムービープレーヤ300に対してではなく、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知される。なお、ボタン画像にフォーカスが当たった場合とは、例えば、画面上の位置を指示するためのカーソルがボタン画像の表示座標を示し、当該ボタン画像が選択可能となっているような状態である。イベントup、イベントdown、イベントleftおよびイベントrightは、ボタン画像に対するフォーカスが、それぞれ上、下、左および右のボタン画像に移動した場合に発生する。イベントfocusInは、あるボタン画像にフォーカスが当たった場合に発生し、イベントfocusOutは、フォーカスの当たっていたボタン画像からフォーカスが外れた場合に発生する。また、イベントpushは、フォーカスの当たっているボタン画像に対して押下操作が行われた際に発生する。イベントcancelは、ボタン画像の押下操作に対してキャンセル操作が行われた際に発生する。
イベントautoPlayおよびイベントcontinuePlayは、スクリプトレイヤ302におけるスクリプトの実行開始を指示するイベントである。イベントautoPlayは、ディスクの装填時に自動的にスクリプトの実行を開始するように指示するイベントである。イベントcontinuePlayは、ディスク装填時に、例えばリジュームインフォメーション324に基づき、以前中止された時点からのスクリプトの実行再開を指示する。
図12で示したイベントに対しては、イベントが発生したときに実行されるプログラムが存在する。このイベントに対応したプログラムをイベントハンドラと称する。イベントとイベントハンドラとは、例えば名前で対応関係をつけることができる。一例として、イベント名の先頭に「on」を付加したものがイベントハンドラ名となる。図13および図14は、一例のイベントハンドラを示す。イベントハンドラの内容をコンテンツ制作者が記述することにより、UMDビデオプレーヤにコンテンツ制作者が意図する様々な動作を実行させることが可能になる。
図13は、ムービープレーヤオブジェクト300が持つ一例のイベントの一部と、対応するイベントハンドラとを示す。この図13のイベントは、上述した図2のイベント312に対応し、ムービープレーヤ300からスクリプトレイヤ302に通知される。イベントハンドラは、一種のインターフェイスであって、その内容は、例えばコンテンツ制作者がスクリプト言語を用いて実装する。イベントハンドラをこのように構成することで、イベント発生時に、コンテンツ制作者の意図する動作を実現することができる。
イベントmarkおよびイベントハンドラonMark()は、イベントマーク(Event-mark)が検出された際に実行される。イベントマークは、例えば、プレイリスト中に埋め込まれ、プレイリストの再生中にムービープレーヤ300により検出される。ムービープレーヤ300によりイベントマークが検出されると、ムービープレーヤ300からスクリプトレイヤ302に対してイベントmarkが通知される。スクリプトレイヤ302は、このイベントmarkに対応するイベントハンドラonMark()を実行する。同様にして、イベントpalyListEndおよびイベントハンドラonPlayListEnd()は、プレイリストが終了した際に実行される。イベントchapterおよびイベントハンドラonChapter()は、チャプタマーク(Chapter-mark)検出時に実行される。チャプタマークは、例えば、プレイリスト中に埋め込まれ、プレイリストの再生中にムービープレーヤ300により検出される。
イベントangleChangeおよびイベントハンドラonAngleChange()は、ユーザ操作によりアングル変更が指示されたときに実行される。例えば、ユーザ操作に応じてキー入力VK_ANGLEがユーザ入力310としてネイティブ実装プラットフォーム301に入力されると、ネイティブ実装プラットフォーム301は、当該ユーザ入力310をコマンドuo_angleChange()に変換してムービープレーヤ300に渡す。ムービープレーヤ300は、このコマンドuo_angleChange()に応じてイベントangleChangeを発生させ、スクリプトレイヤ302に渡す。スクリプトレイヤ302は、このイベントangleChangeに対応したイベントハンドラonAngleChange()を実行する。同様にして、イベントaudioChangeおよびイベントハンドラonAudioChange()は、ユーザ操作によりオーディオの変更が指示されたときに実行される。イベントsubtitleChangeおよびイベントハンドラonSubtitleChange()は、ユーザ操作により字幕変更が指示されたときに実行される。
図14は、コントローラオブジェクト330が有する一例のイベントハンドラの一部を示す。この図14に示されるイベントハンドラは、ネイティブ実装プラットフォーム301のコントローラオブジェクト330に属するイベントハンドラであり、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知されることにより実行される。
イベントmenuおよびイベントハンドラonMenu()は、メニューにジャンプする。イベントmenuは、例えば、ユーザ操作などでメニューキーが押下されたときに、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知されるイベントである。スクリプトレイヤ302は、このイベントを受けて、対応するイベントハンドラonMenu()を実行し、イベントハンドラonMenu()内でメニュー画面を構成するGUI部品の配置や表示などを行う。イベントexitおよびイベントハンドラonExit()は、ネイティブ実装プラットフォーム301がUMDビデオアプリケーションを終了させる際に、ネイティブ実装プラットフォーム301から発せられるイベントおよび対応するイベントハンドラである。
イベントexitは、例えば、ユーザ操作などによりUMDビデオプレーヤの動作の終了が指示された際に、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に通知される。スクリプトレイヤ302のスクリプトは、通知されたイベントexitを受けて、イベントハンドラonExit()内で終了処理を行うことができる
イベントresourceChangedおよびイベントハンドラonResourceChanged()は、ネイティブ実装プラットフォーム301がリソースファイルを切り換えた後に、ネイティブ実装プラットフォーム301から発せられるイベントおよび対応するイベントハンドラである。
イベントautoPlayおよびイベントハンドラonAutoPlay()、ならびに、イベントcontinuePlayおよびイベントハンドラonContinuePlay()は、それぞれスクリプトの実行を開始する。
なお、コントローラオブジェクト330のイベントハンドラ以外に、ボタンに関するイベントハンドラがある。このボタンに関するイベントハンドラは、この発明と関連性が低いので、説明を省略する。
図15のフローチャートを用いて、ユーザ入力イベントをきっかけとして、用意されたプログラムが実行される一例の処理について、概略的に説明する。図15は、UMDビデオプレーヤにおいてディスクを通常再生中に、ユーザにより、次のチャプタを再生することを指示するためのキー(例えば"next"キー)が押されたときに、このキー入力に対応して、次のチャプタにジャンプして再生を開始すると共に、用意されたメッセージを画面上に表示する例である。
例えば、UMDビデオプレーヤによりディスクを通常再生中に、ユーザがUMDビデオプレーヤのリモートコントロールコマンダを用いてキー"next"を押下すると(ステップS10)、ネイティブ実装プラットフォーム301に対するユーザ入力310として、キーVK_NEXTが渡される。ネイティブ実装プラットフォーム301では、このユーザ入力310に対応してユーザコマンドuo_playNextChapter()が発生する(ステップS11)。このユーザコマンドuo_playNextChapter()は、ムービープレーヤ300に通知される。
このコマンドuo_playNextChapter()を受け取ったムービープレーヤ300は、データベース320を検索し、プレイリスト情報から現在再生している位置を基準として、次のチャプタマークの位置を取得する(ステップS12)。ステップS13で、次のチャプタマークが存在するか否かが判断され、若し、存在しないと判断された場合、チャプタジャンプを行わず、現在の再生が継続される。
一方、ステップS13で、次のチャプタマークが存在すると判断されれば、処理はステップS14に移行する。ステップS14では、ムービープレーヤ300は、現在の再生を中止し、次のチャプタマークが指し示す、クリップAVストリームファイル内でのバイト位置を、データベース320のクリップインフォメーションファイルの特徴点情報から取得する。そして、ステップS15で、取得されたファイル内バイト位置にアクセスし、その位置からストリームの読み込みを開始して再生を開始する。
ステップS16以下は、チャプタが切り替わったことを知らせるメッセージを画面上に表示するための一連の手順である。チャプタが切り替わりチャプタの先頭からの再生が開始されると、チャプタイベントが発生する(ステップS16)。例えば、チャプタの先頭に設けられたチャプタマークがムービープレーヤ300に検出され、イベントchapterが発生される。このチャプタイベントは、ムービープレーヤ300からスクリプトレイヤ302に通知される。ムービープレーヤ300は、このイベントの通知時に、ジャンプするチャプタのチャプタ番号も共に、スクリプトレイヤ302に対して通知する。スクリプトレイヤ302は、通知されたイベントに対応するイベントハンドラ、例えばイベントハンドラonChapter()の実行を開始する(ステップS17)。
この例では、イベントハンドラ内には、チャプタが切り替わった際に画面上にその旨を知らせるメッセージを表示する動作が記述されているものとする。スクリプトレイヤ302のスクリプトは、このイベントハンドラを実行し、イベント発生時にムービープレーヤ300から通知されたジャンプ先のチャプタ番号を取得し(ステップS18)、ネイティブ実装プラットフォーム301に対して、例えば取得したチャプタ番号のチャプタの先頭であるなど、所定のメッセージを画面上に表示する指示を出す。ネイティブ実装プラットフォーム301は、この指示に応じて、画面上にメッセージを表示し(ステップS19)、イベントハンドラによる処理が終了される(ステップS20)。
上述のような処理により、ユーザが次のチャプタの再生開始を指示するキー"next"を操作することによりチャプタジャンプが行われ、ジャンプ先である次のチャプタの再生開始時にチャプタの先頭であることを示すメッセージが画面上に表示されることになる。
このように、ユーザ入力イベントは、ムービープレーヤ300の状態を変化させ、また、新たなイベントを発生させる契機ともなり、新たに発生したイベントを利用して様々な処理を行わせることができる。
以上のようなプレーヤモデルにより、ビデオ、オーディオおよび字幕の再生が可能となる。コンテンツ制作者が予め設定しておいた、再生中のある時刻にあるイベントを発生させて、予め用意しておいたイベントハンドラが実行されることで、コンテンツ制作者が意図する動作を実現できる。また、プレイリストの再生中にプレーヤに対するユーザ操作があった場合には、ユーザ操作によるユーザ入力310に応じてネイティブ実装プラットフォーム301からムービープレーヤ300に対して制御コマンドが与えられ、ユーザの意図する通りにプレーヤの状態を変化させることができる。さらに、プレーヤに対するユーザ操作によるユーザ入力310を受けたネイティブ実装プラットフォーム301がスクリプトレイヤ302のスクリプトにイベントを通知することにより、ユーザ操作に応じ、コンテンツ制作者が用意した動作を実行させることも可能となる。
このようにプレーヤモデルを構築することで、ビデオ、オーディオおよび字幕の再生と、インタラクティブな操作とをユーザに提供することが可能となる。
5.スクリプトプログラムの例
次に、スクリプトレイヤ302のスクリプトプログラムの例について説明する。先ず、図16に示されるようなコンテンツ再生の流れが、コンテンツ制作者により作られているものとする。図16に示されるコンテンツは、表示される要素としては、プレイリスト400および401、トップメニュー402、ならびに、メッセージ403から構成される。プレイリスト400は、ディスクが装填されると自動的に表示される警告文画面を表示するためのものである。プレイリスト401は、例えばこのコンテンツの主眼である映画の本編である。トップメニュー画面402は、プレイリスト401の再生を指示できるように、ボタンなどのGUI部品が配置される。また、メッセージ403は、プレイリスト401の再生中の任意の時刻に表示される。
さらに、この図16の構成では、幾つかのイベントハンドラが用意されている。イベントハンドラonAutoPlay()は、ディスクがUMDプレーヤに装填されると、プレイリスト400を自動的に再生し、警告文を表示させる。イベントハンドラonPlayListEnd()は、プレイリストの再生が終了すると呼び出されるイベントハンドラで、この図16の例では、プレイリスト400やプレイリスト401の終了で呼び出される。すなわち、イベントハンドラonPlayListEnd()は、どのプレイリストが終了したかを判定し、プレイリスト400の再生が終了した場合には、プレイリスト401の再生開始を指示する。また、プレイリスト401の再生が終了した場合には、トップメニュー画面402を呼び出す。
イベントハンドラonMenu()は、ユーザがメニューキーを操作したときに呼び出され、トップメニュー402を呼び出して画面に表示する。イベントハンドラonMark()は、再生中にマークMarkが指し示す時刻に到達したときに実行される。この図16の例では、プレイリスト401に対してマークMarkが設定されており、プレイリスト401の再生がマークMarkの指し示す時刻に到達すると、画面上にメッセージ403が表示されるようになっている。
すなわち、図16の例では、UMDビデオプレーヤにディスクが装填されると、イベントハンドラonAutoPlayが呼び出されてプレイリスト400が再生され、警告画面が表示される。プレイリスト400の再生時間が経過し、プレイリスト400の最後に到達すると、イベントハンドラonPlayListEndが呼び出され、プレイリスト400が最後まで再生されたことが判定され、次のプレイリスト401が再生される。ここで、プレイリスト401の再生中に、ユーザによりメニューキーが操作されると、イベントハンドラonMenuが呼び出され、トップメニュー画面402が表示される。また、イベントハンドラonMenuにより、トップメニュー画面402に対する所定の操作に応じて、プレイリスト401の先頭から再生が開始される。さらに、プレイリスト401の再生時刻がマークMarkが指し示す時刻に到達したら、イベントハンドラonMarkが呼び出され、メッセージ403が画面上に表示される。プレイリスト401が最後まで再生されると、イベントハンドラonPlayListEndが呼び出され、プレイリスト401が最後まで再生されたことが判定され、トップメニュー画面402が表示される。
図17は、この図16に示すような動作を実現するための一例のスクリプトプログラムを示す。上述したように、スクリプトプログラムは、イベントハンドラが並べられ、イベントの発生に応じて対応するイベントハンドラが実行されるようになっている。スクリプトプログラムは、拡張子が「RCO」であるリソースファイルに格納される。
ムービープレーヤ300に対してプレイリストの再生を指示するメソッドは、「movieplayer.play()」である。括弧内には、引数として、再生するプレイリストの番号を記述する。プレイリストの再生が終了すると、イベントplayListEndが発生する。このイベントplayListEndが発生すると、スクリプトからイベントハンドラmovieplayer.onPlayListEnd()が呼び出される。このとき、スクリプトには、イベントplayListEndと共に、オブジェクトevent_infoが渡される。オブジェクトevent_infoには、どのプレイリストが終了したかを表すプレイリスト番号などが格納される。スクリプトでは、このオブジェクトevent_infoの内容により、次の動作を変えることができる。
6.ファイルの管理構造について
次に、UMDビデオ規格に適用されるファイルの管理構造について、図18を用いて説明する。ファイルは、ディレクトリ構造により階層的に管理されて、ディスク上に記録される。ディスクのファイルシステムは、ISO(International Organization for Standarization)−9660あるいはUDF(Universal Disk Format)などで規定されたファイルシステムを適用することができる。
ルートディレクトリの下に、ファイル"TITLEID.DAT"およびディレクトリ"VIDEO"が置かれる。ディレクトリ"VIDEO"の下には、さらに、ディレクトリ"RESOURCE"、ディレクトリ"CLIP"およびディレクトリ"STREAM"、ならびに、ファイル"PLAYLIST.DAT"が置かれる。
ファイル"TITLEID.DAT"は、タイトル(コンテンツの種類)毎に異なるタイトル識別子が格納されるファイルである。1つのディスクに対し、1つのファイル"TITLEID.DAT"を有する。
ディレクトリ"RESOURCE"の下には、リソースファイル("JA000000.RCO")が置かれる。リソースファイルには、上述したように、スクリプトレイヤ302を構成するスクリプトプログラムが格納されると共に、メニュー画面を構成するために用いられるデータ、例えば画像データやサウンドデータなどの部品データが格納される。ディレクトリ"RESOURCE"の下には、通常、1または複数のリソースファイルが置かれる。複数のリソースファイルは、例えば、表示言語の異なる複数のメニューなどを用意する際に、言語毎に作成される。この場合でも、同時に用いられるリソースファイルは、1個とされる。
ディレクトリ"CLIP"の下には、1以上のクリップインフォメーションファイルが置かれる。クリップインフォメーションファイルは、ファイル名を、デリミタであるピリオドの前が「00001」などの5文字乃至数文字からなる文字列(この例では数字)、ピリオドの後ろの拡張子が「CLP」とされる。拡張子「CLP」により、当該ファイルがクリップインフォメーションファイルであることを識別できる。
ディレクトリ"STREAM"の下には、1以上のクリップAVストリームファイルが置かれる。クリップAVストリームファイルは、ファイル名を、デリミタであるピリオドの前が「00001」などの5文字乃至数文字からなる文字列(この例では数字)、ピリオドの後ろの拡張子が「PS」とされる。拡張子「PS」により、当該ファイルがクリップAVストリームファイルであることを識別できる。この実施の一形態では、クリップAVストリームファイルは、ビデオストリーム、オーディオストリームおよびサブタイトル(字幕)ストリームが多重化され、MPEG2(Moving Pictures Experts Group 2)のプログラムストリームとして、上述の拡張子「PS」で識別されるファイルに格納される。
上述したように、クリップAVストリームファイルは、ビデオデータおよびオーディオデータを圧縮符号化および時分割多重して得られるファイルであって、このファイルを読み込み、デコード処理を行うことで、ビデオデータおよびオーディオデータが得られる。また、クリップインフォメーションファイルは、このクリップAVストリームファイルの性質などが記述されるファイルであって、クリップAVストリームファイルと対応する。この実施の一形態では、クリップインフォメーションファイルと対応するクリップAVストリームファイルとで、ファイル名における、拡張子の前の、5文字乃至数文字からなる文字列を一致させておくことで、両者の対応関係を容易に把握できる。
リソースファイルは、上述したように、スクリプトプログラムが記述されたスクリプトファイルを含み、この実施の一形態が適用されるディスクの再生形態をインタラクティブなものとするために用いるプログラムが格納されている。リソースファイルは、ディスクに格納される他のファイルに先立って読み出される。
ファイル"PLAYLIST.DAT"は、クリップAVストリームの再生順を指定するプレイリストが記述されたプレイリストファイルである。図19〜図21を用いて、ファイル"PLAYLIST.DAT"の内部構造について説明する。図19は、ファイル"PLAYLIST.DAT"の全体構造を表す一例のシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるC言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
フィールドname_lengthは、8ビットのデータ長を有し、このプレイリストファイルに付された名称の長さを示す。フィールドname_stringは、255バイトのデータ長を有し、このプレイリストファイルに付された名称を示す。フィールドname_stringは、その先頭から、フィールドname_lengthが表すバイト長までが、有効な名称として使用される。例えば、フィールドname_lengthが値"10"を持つ場合には、フィールドname_stringの先頭から10バイト分が有効な名称として解釈される。
フィールドnumber_of_PlayListsは、16ビットのデータ長を有し、続けて記述されるブロックPlayList()の個数を示す。次行のforループによりフィールドnumber_of_PlayListsに示される回数分だけ、当該個数のブロックPlayList()が記述される。ブロックPlayList()は、プレイリストそのものである。
ブロックPlayList()の一例の内部構造について説明する。ブロックPlayList()の先頭には、フィールドPlayList_data_lengthが配される。フィールドPlayList_data_lengthは、32ビットのデータ長を有し、当該フィールドPlayList_data_lengthを含むブロックPlayList()のデータ長を示す。続いて、15ビットのデータ長を有するフィールドreserved_for_word_alignmentと、1ビットのデータ長を有するフラグcapture_enable_flag_PlayListとが配される。フィールドreserved_for_word_alignmentは、データ長が1ビットのフラグcapture_enable_flag_PlayListと組み合わせて、ブロックPlayList()内での配置を16ビットの位置に揃えるために用いられる。
フラグcapture_enable_flag_PlayListは、当該capture_enable_flag_PlayListを含むブロックPlayList()に属する動画像の二次利用を許可するか否かを示すフラグである。例えば、このフラグcapture_enable_flag_PlayListの値が"1"であれば、当該PlayList()に属する動画像の、再生機内での2次利用を許可することを示す。
なお、上述では、フラグcapture_enable_flag_PlayListを1ビットのフラグとしたが、これはこの例に限定されない。例えば、フラグcapture_enable_flag_PlayListを複数ビット構成として、2次利用の段階的な許可を記述するようにしてもよい。一例として、フラグcapture_enable_flag_PlayListを2ビット構成とし、値が"0"の場合には2次利用を完全禁止とし、値が"1"の場合には例えば64画素×64ラインなど、所定の解像度以下に圧縮符号化した場合のみ2次利用を可能とする。また、値が"2"であれば、制限無く2次利用を許可するといった利用が考えられる。これに限らず、2ビット構成のうちビット0が値"1"の場合にはコンテンツ再生アプリケーションでの2次使用を許可し、ビット1が値"1"の場合には同一筐体内の他のアプリケーション(例えば壁紙画像やスクリーンセーバ)での2次使用を許可する。この場合には、ビット0およびビット1の値を組み合わせて用いることができる。
フィールドPlayList_name_lengthは、8ビットのデータ長を有し、このブロックPlayList()に付された名称の長さを示す。フィールドPlayList_name_stringは、255ビットのデータ長を有し、このブロックPlayList()に付された名称を示す。フィールドPlayList_name_stringは、その先頭から、フィールドPlayList_name_stringが表すバイト長までが、有効な名称として使用される。
フィールドnumber_of_PlayItemsは、16ビットのデータ長を有し、続けて記述されるブロックPlayItem()の個数を示す。次行のforループによりフィールドnumber_of_PlayItem2に示される回数分だけ、当該個数のブロックPlayItem()が記述される。ブロックPlayItem()は、プレイアイテムそのものである。
ブロックPlayList()内の各ブロックPlayItem()には、識別情報(ID)が付与される。例えば、ブロックPlayList()内の最初に記述されるブロックPlayItem()は、0番とされ、以降、ブロックPlayItem()の出現順に、1番、2番、・・・と通し番号が付される。この通し番号が各ブロックPlayItem()の識別情報として用いられる。ブロックPlauItem()の個数だけ繰り返されるforループの引数iを、対応するブロックPlayItem()の識別情報として用いることができる。ブロックPlayItem()の次に、ブロックPlayListMark()が配置される。
図20を用いて、ブロックPlayItem()の一例の内部構造について説明する。ブロックPlayItem()の先頭には、フィールドlengthが配される。フィールドlengthは、16ビットのデータ長を有し、当該ブロックPlayItem()の長さを示す。続いて、フィールドClip_Information_file_name_lengthが配される。フィールドClip_Information_file_name_lengthは、16ビットのデータ長を有し、このブロックPlayItem()に対応するクリップインフォメーションファイルの名称の長さを示す。フィールドClip_Information_file_nameは、バイト単位で可変長のデータ長を有し、このブロックPlayItem()に対応するクリップインフォメーションファイルの名称を示す。フィールドClip_Information_file_nameは、その先頭から、フィールドClip_Information_file_name_lengthが表すバイト長までが、有効な名称として使用される。フィールドClip_Information_file_nameでクリップインフォメーションファイルが指定されると、上述したファイル名の対応関係により、当該クリップインフォメーションファイルに対応するクリップAVストリームファイルが特定できる。
フィールドIN_timeおよびフィールドOUT_timeは、それぞれ33ビットのデータ長を有し、ブロックPlayItem()内においてフィールドClip_Information_file_nameで指定したクリップインフォメーションファイルに対応するクリップAVストリームファイルの再生開始位置および再生終了位置を指定する時刻情報である。これらフィールドIN_timeおよびフィールドOUT_timeの情報を用いることで、クリップAVストリームファイルの先頭以外の部分からの再生開始を指定することができる。同様に、クリップAVストリームファイルの後端以外の再生終了を指定することができる。フィールドreserved_for_word_aliignmentは、データ構造のデータ長を16ビットの整数倍にするための調整用のフィールドであって、15ビットのデータ長を有する。
図21を用いて、ブロックPlayListMark()の一例の内部構造について説明する。ブロックPlayListMark()の先頭には、フィールドlengthが配される。フィールドlengthは、32ビットのデータ長を有し、当該ブロックPlayListMark()の長さを示す。続いて、フィールドnumber_of_PlayList_marksが配される。フィールドフィールドnumber_of_PlayList_marksは、16ビットのデータ長を有し、続くブロックMark()の個数を示す。次行のforループによりフィールドnumber_of_PlayList_marksに示される回数分だけ、当該個数のブロックMark()が記述される。
ブロックMark()の一例の内部構造について説明する。ブロックMark()は、先頭にフィールドmark_typeが配される。フィールドmark_typeは、8ビットのデータ長を有し、当該フィールドmark_typeを含むブロックMark()の種類を示す。この実施の一形態では、図22に一例が示されるように、チャプタマークおよびイベントマークの2種類のマークが規定されている。チャプタは、プレイリスト(ブロックPlayList())を分割する頭出し単位であり、チャプタマークは、チャプタ位置を時刻情報で示す。イベントマークは、マークイベントを発生させるマークである。
フィールドmark_name_lengthは、8ビットのデータ長を有し、このブロックMark()に付された名称の長さを示す。ブロックMark()の最下行に配されるフィールドmark_name_stringは、このブロックMark()に付された名称を示す。フィールドmark_name_stringは、その先頭から、フィールドmark_name_lengthが表すバイト長までが、有効な名称として使用される。
フィールドref_to_PlayItem_id、フィールドmark_time_stamp、フィールドentry_ES_stream_idおよびフィールドentry_ES_private_stream_idの4要素は、ブロックPlayList()上で定義されるブロックMark()を、クリップAVストリームファイルと対応付ける。すなわち、フィールドref_to_PlayItem_idは、16ビットのデータ長を有し、ブロックPlayItem()の識別情報を示す。これにより、クリップインフォメーションファイルと、クリップAVストリームファイルとが特定される。
フィールドmark_time_stampは、33ビットのデータ長を有し、クリップAVストリームファイル内でのマークの時刻を指定するために用いられる。図23を用いて、概略的に説明する。図23において、プレイリストは、番号0、1および2がそれぞれ指定された3つのプレイアイテム(PlayItem#0、PlayItem#1およびPlayItem#2)からなり、プレイリスト上の時刻t0は、番号1のプレイアイテム(PlayItem#1)に含まれるものとする。また、番号0、1および2の各プレイアイテムは、それぞれ対応するクリップインフォメーションファイルを介してクリップAVストリームファイルのプログラムストリーム(Program Sream)A、BおよびCにそれぞれ対応しているものとする。
このような場合において、プレイリスト上の時刻t0にマークを指定する場合、フィールドref_to_PlayItem_idの値を、時刻t0を含むプレイアイテムを示す"1"とし、さらに、対応するクリップAVストリームファイルB上で時刻t0に相当する時刻を、フィールドmark_time_stampに記述する。
図21の説明に戻り、フィールドmark_time_stampに続けてフィールドentry_ES_stream_idおよびフィールドentry_ES_private_stream_idが配される。フィールドentry_ES_stream_idおよびフィールドentry_ES_private_stream_idは、それぞれ8ビットのデータ長を有し、当該ブロックMark()が特定のエレメンタリストリームに関連付けられている場合に、そのエレメンタリストリームを特定するために用いられる。フィールドentry_ES_stream_idおよびフィールドentry_ES_private_stream_idは、それぞれ該当するエレメンタリストリームが多重化されているパケット(packet())のストリームID(stream_id)と、プライベートパケットヘッダ(private_packet_header())のプライベートストリームID(private_stream_id)を示す。
なお、これらパケット(packet())のストリームID(stream_id)、プライベートパケットヘッダ(private_packet_header())のプライベートストリームID(private_stream_id)は、例えばMPEG2システムのプログラムストリームの規定に基づく。
これらフィールドentry_ES_stream_idおよびフィールドentry_ES_private_stream_idは、例えば、クリップAVストリーム#0とクリップAVストリーム#1とで異なるチャプタ構成である場合などに用いられる。該当するブロックMark()が特定のエレメンタリストリームに関連付けられていない場合には、これら2つのフィールドの値がそれぞれ"0"とされる。
次に、図24〜図28を用いて、クリップインフォメーションファイルの内部構造について説明する。クリップインフォメーションファイル"XXXXX.CLP"は、上述したように、ディレクトリ"STREAM"の下に置かれた、対応するクリップAVストリームファイル"XXXXX.PS"の性質などを記述する。
図24は、クリップAVストリームファイル"XXXXX.CLP"の全体構造を表す一例のシンタクスを示す。クリップAVストリームファイル"XXXXX.CLP"は、先頭に、フィールドpresentation_start_timeおよびフィールドpresentation_end_timeがそれぞれ配される。フィールドpresentation_start_timeおよびフィールドpresentation_end_timeは、それぞれ33ビットのデータ長を有し、対応するクリップAVストリームファイルの先頭と後端の時刻を示す。時刻情報は、MPEG2システムにおけるPTS(Presentation Time Stamp)を用いることができる。PTSは、90kHzの精度を有する。
次に、7ビットのデータ長を有するフィールドreserved_for_word_alignmentと、1ビットのデータ長を有するフラグcapture_enable_flag_Clipとが配される。フィールドreserved_for_word_alignmentは、データ長が1ビットのフラグcapture_enable_flag_Clipと組み合わせて、ファイル"XXXXX.CLP"内での配置を16ビットの位置に揃えるために用いられる。フラグcapture_enable_flag_Clipは、当該ファイル"XXXXX.CLP"に対応するクリップAVストリームファイルに含まれる動画像の2次利用を許可するか否かを示すフラグである。例えば、このフラグcapture_enable_flag_Clipの値が"1"であれば、当該ファイル"XXXXX.CLP"に対応するクリップAVストリームファイルの動画像の、再生機内での2次利用を許可することを示す。
フィールドnumber_of_streamsは、8ビットのデータ長を有し、続くブロックStreamInfo()構造の個数を示す。フィールドnumber_of_streamsの次から、forループによりフィールドnumber_of_streamsで示される回数分だけ、ブロックStreamInfo()が記述される。forループの後には、ブロックEP_map()が配される。
ブロックStreamInfo()の一例の内部構造について説明する。ブロックStreamInfo()の先頭には、フィールドlengthが配される。フィールドlengthは、16ビットのデータ長を有し、当該ブロックStreamInfo()の長さを示す。続いて、それぞれ8ビットのデータ長を有するフィールドstream_idおよびフィールドprivate_stream_idが配され、図25に一例が示されるように、当該ブロックStreamInfo()をエレメンタリストリームに関連付けている。この図25の例では、当該ブロックStreamInfo()は、フィールドstream_idが値"0xE0"〜値"0xEF"でビデオストリームに関連付けられ、値"0xBD"でATRAC(Adaptive Transform Acoustic Coding)オーディオストリーム、LPCM(Linear Pulse Code Modulation)オーディオストリームまたは字幕ストリームと関連付けられる。また、当該ブロックStreamInfo()は、フィールドprivate_stream_idが値"0x00"〜値"0x0F"、値"0x10"〜値"0x1F"および値"0x80"〜値"0x9F"で、ATRACオーディオストリーム、LPCMオーディオストリームおよび字幕ストリームにそれぞれ関連付けられる。
なお、図25での値の表記において、「0x」は、後続する数値が16進表記であることを示す。これは、以下の同様な表現において、共通である。
ここで、ブロックStreamInfo()は、大別して、ストリーム中で変化しない情報とストリーム中で変化する情報との2種類の情報が記述されている。ストリーム中で変化しない情報は、ブロックStaticInfo()に記述される。一方、ストリーム中で変化する情報は、変化点を時刻情報で指定して、ブロックDynamicInfo()に記述される。
ブロックStreamInfo()において、ブロックStaticInfo()の後ろにバイト位置を揃えるための、8ビットのデータ長を有するフィールドreserved_for_word_alignmentが配され、その次に、フィールドnumber_of_DynamicInfoが配される。フィールドnumber_of_DynaminInfoは、8ビットのデータ長を有し、ブロックStreamInfo()内にその後に記述されるブロックDynamicInfo()の個数が示される。forループにより、フィールドnumber_of_DynamicInfoで示される回数分だけ、フィールドpts_change_pointおよびブロックDynamicInfo()が記述される。
フィールドpts_change_pointは、33ビットのデータ長を有し、対応するブロックDynamicInfo()の情報が有効になる時刻をPTSにより示す。ストリーム毎に先頭となる時刻も、フィールドpts_change_pointで示され、これは、ファイル"XXXXX.CLP"内で定義される、上述したフィールドpresentation_start_timeと等しくなる。
図26を用いて、ブロックStaticInfo()の一例の内部構造について説明する。ブロックStaticInfo()は、対応するエレメンタリストリームの種類により内容が異なる。対応するエレメンタリストリームの種類は、図25を用いて説明した、フィールドstream_idおよびフィールドprivate_stream_idの値に基づき判断できる。図26では、ブロックStaticInfo()が対応するエレメンタリストリームの種類がビデオストリーム、オーディオストリームおよびサブタイトル(字幕)ストリームの何れであるかを、if構文を用いてそれぞれ記述している。以下、ブロックStaticInfo()について、エレメンタリストリーム毎に説明する。
エレメンタリストリームがビデオストリームであった場合、ブロックStaticInfo()は、それぞれ4ビットのデータ長を有するフィールドpicture_sizeおよびフィールドframe_rate、1ビットのデータ長を有するフラグcc_flagからなる。フィールドpicture_sizeおよびフィールドframe_rateは、当該ビデオストリームの画像のサイズおよびフレーム周波数をそれぞれ示す。フラグcc_flagは、当該ビデオストリームがクローズドキャプションを含むか否かを示す。例えば、フラグcc_flagの値が"1"で、当該ビデオストリームがクローズドキャプションを含む。フィールドreserved_for_word_alignmentは、データ配置を16ビットに揃えるために用いられる。
エレメンタリストリームがオーディオストリームであった場合、ブロックStaticInfo()は、16ビットのデータ長を有するフィールドaudio_language_code、8ビットのデータ長を有するフィールドchannel_configuration、1ビットのデータ長を有するフラグlfe_exsistanceおよび4ビットのデータ長を有するフィールドsampling_frequencyからなる。フィールドaudio_language_codeは、当該オーディオストリームに含まれている言語を表すコードを示す。フィールドchannel_configurationは、モノラル、ステレオ、マルチチャンネルなど、オーディオデータのチャンネル属性を示す。フィールドlfe_existanceは、低域強調チャンネルが含まれているか否かを示し、例えば値が"1"で、含まれていることを示す。フィールドsampling_frequencyは、オーディオデータのサンプリング周波数を示す。フィールドreserved_for_word_alignmentは、データ配置を16ビットに揃えるために用いられる。
エレメンタリストリームがサブタイトル(字幕)ストリームであった場合、ブロックStaticInfo()は、16ビットのデータ長を有するフィールドsubtitle_language_codeおよび1ビットのデータ長を有するフラグconfigurable_flagからなる。フィールドsubtitle_language_codeは、当該字幕ストリームに含まれている言語を表すコードを示す。フラグconfigurable_flagは、当該字幕ストリームを表示する際に、文字の大きさや位置の変更を許可するか否かを示し、例えば値が"1"で、許可することを示す。フィールドreserved_for_word_alignmentは、データ配置を16ビットに揃えるために用いられる。
図27を用いて、ブロックDynamicInfo()の一例の内部構造について説明する。ブロックDynamicInfo()は、先頭に、8ビットのデータ長を有するフィールドreserved_for_word_alignmentが配される。続く内容は、対応するエレメンタリストリームの種類により異なる。対応するエレメンタリストリームの種類は、図25を用いて説明した、フィールドstream_idおよびフィールドprivate_stream_idの値に基づき判断できる。図27では、ブロックDynamicInfo()が対応するエレメンタリストリームの種類がビデオストリーム、オーディオストリームおよびサブタイトル(字幕)ストリームの何れであるかを、if構文を用いてそれぞれ記述している。以下、ブロックDynamicInfo()について、エレメンタリストリーム毎に説明する。
エレメンタリストリームがビデオストリームであった場合、ブロックDynamicInfo()は、4ビットのデータ長を有するフィールドdisplay_aspect_ratioからなる。フィールドdisplay_aspect_ratioは、ビデオの表示出力アスペクト比が16:9か4:3かを示す。フィールドreserved_for_word_alignmentは、データ配置を16ビットに揃えるために用いられる。
エレメンタリストリームがオーディオストリームであった場合、ブロックDynamicInfo()は、4ビットのデータ長を有するフィールドchannel_assignmentからなる。フィールドchannel_assignmentは、当該オーディオストリームが2チャンネルで構成されている場合に、出力がステレオかデュアルモノかを示す。デュアルモノは、例えば2ヶ国語の音声を再生可能とする際に用いられる。フィールドreserved_for_word_alignmentは、データ配置を16ビットに揃えるために用いられる。
エレメンタリストリームが字幕ストリームであった場合、ブロックDynamicInfo()は、データ配置を16ビットに揃えるために用いられる、フィールドreserved_for_word_alignmentで構成される。すなわち、字幕ストリームに関しては、動的に変化する属性が定義されていない。
図28を用いて、ブロックEP_map()の一例の内部構造について説明する。ブロックEP_map()は、エレメンタリストリーム毎に、ビットストリーム内のデコード開始可能位置(エントリポイント、あるいはランダムアクセスポイント(RAP)ともいう)を、時刻情報と位置情報とを用いて表したものである。位置情報は、例えばエレメンタリストリームが記録される記録媒体における、アクセスの最小単位を用いることができる。各エレメンタリストリームは、ブロックEP_map()で示された位置からのデコード処理が可能であるものとする。
固定レートのストリームでは、デコード開始可能位置を計算で求めることができるので、このブロックEP_map()のような情報は、不要である。一方、可変レートのストリームや、MPEG系のビデオの圧縮符号化方式のようにアクセスユニット毎にデータのサイズが変わるようなストリームの場合には、ランダムアクセスを行うために重要な情報となる。
ブロックEP_map()は、先頭に、配置を16ビットに揃えるために、8ビットのデータ長を有するフィールドreserve_for_word_alignmentが配される。続いて、フィールドnumber_of_stream_id_entriesが配される。フィールドnumber_of_stream_id_entriesは、8ビットのデータ長を有し、このブロックEP_map()に記述されているエレメンタリストリームの数を示す。第1のforループにより、フィールドstream_id、フィールドprivate_stream_idおよびフィールドnumber_of_EP_entriesが、フィールドnumber_of_stream_id_entriesで示される回数分だけ、記述される。さらに、第1のforループの1回の記述毎に、第2のforループにより、フィールドnumber_of_EP_entriesで示される回数分だけ、フィールドPTS_EP_startおよびフィールドRPN_EP_startが配される。
第1のforループ内において、最初に、それぞれ8ビットのデータ長を有するフィールドstream_idおよびフィールドprivate_stream_idが配され、図25に一例が示されるようにして、エレメンタリストリームを特定している。次に、配されるフィールドnumber_of_EP_entriesは、32ビットのデータ長を有し、当該エレメンタリストリームに対して記述されているエントリポイントの数を示す。その後、第2のforループにて、フィールドnumber_of_EP_entriesが示す数だけ、フィールドPTS_EP_startおよびフィールドRPN_EP_startがそれぞれ配される。
フィールドPTS_EP_startおよびフィールドRPN_EP_startは、それぞれ33ビットのデータ長を有し、エントリポイント自体を表す。フィールドPTS_EP_startは、エントリポイントのクリップAVストリームファイル内での時刻をPTSで示す。一方、フィールドRPN_EP_startは、エントリポイントのクリップAVストリームファイル内での位置を例えば2048バイト単位で示す。
この実施の一形態においては、ディスク状のアクセス単位である1セクタが2048バイトとされる。そのため、エントリポイントのクリップAVストリームファイル内での位置は、フィールドRPN_EP_startにより、セクタ単位で示されることになる。
ここで、ビデオストリームの再生開始可能位置の直前には、必ず、パケットprivate_stream_2が配される。このパケットprivate_stream_2は、ビデオストリームをデコードするために利用可能な情報が格納されるパケットである。そのため、ビデオストリームのエントリポイントの位置は、当該パケットprivate_stream_2が格納されるパックpack()の位置とされる。
ブロックEP_map()は、上述のようにして、クリップAVストリーム上の時刻と、クリップAVストリームファイル内での位置とを対応付けている。これにより、クリップAVストリームへのアクセスポイントの時刻情報(タイムスタンプ)が与えられたときに、クリップAVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索することが容易となり、ディスクのランダムアクセスをスムースに行うことができる。
なお、この実施の一形態では、ブロックEP_map()において、エレメンタリストリーム毎の時刻情報と位置情報との組(第2のforループ内のフィールドPTS_EP_startとフィールドRPN_EP_startとの組)は、フィールドPTS_EP_startおよびRPN_EP_startの両方に対して昇順(または降順)に予め並べて登録するようにしている。換言すれば、時刻情報と位置情報とは、予め所定の方向に並べ替えられている。このため、このままのデータに対して二分木検索を実行することが可能である。
なお、この発明の実施の一形態では、ビデオのエレメンタリストリームは、MPEG2−Videoの規格に基づくエレメンタリストリームであるとして説明したが、これはこの例に限定されない。例えば、ビデオのエレメンタリストリームは、MPEG4−Visualや、MPEG4−AVCによるものでもよい。また、オーディオのエレメンタリストリームは、ATRACオーディオのエレメンタリストリームであるとして説明したが、これもこの例に限らず、例えばMPEG1/2/4オーディオにも適用可能である。
7.ディスク再生装置について
次に、この発明の実施の一形態を適用可能なディスク再生装置について説明する。図29は、この発明を適用可能なディスク再生装置100の一例の構成を概略的に示す。バス111に対して、CPU(Central Processing Unit)112、メモリ113、ドライブインターフェイス114、入力インターフェイス115、ビデオデコーダ116、オーディオデコーダ117、ビデオ入出力インターフェイス118およびオーディオ入出力インターフェイス119がそれぞれ接続される。このディスク再生装置100の各部は、バス111を介してビデオストリーム、オーディオストリーム、各種コマンドやデータなどを互いにやりとりできるようになっている。
ドライブインターフェイス114には、さらに、ディスクドライブ102が接続される。ディスクドライブ102は、ドライブインターフェイス114を介してバス111とデータやコマンドのやりとりを行う。
CPU112は、ROM(Read Only Memory)およびRAM(Random Access Memory)を有し(図示しない)、ROMに予め記憶されたプログラムやデータに従い、バス111を介してこのディスク再生装置100の各部とデータやコマンドのやりとりを行い、このディスク装置100の全体を制御する。RAMは、CPU112のワークメモリとして用いられる。
なお、図29では省略されているが、ディスク再生装置100は、データの書き換えが可能で、且つ、ディスク再生装置100の電源をOFFとした後も記憶内容が保持される、フラッシュメモリなどの不揮発性メモリを持つことができる。不揮発性メモリは、例えばバス111に接続され、CPU112による不揮発性メモリに対するデータの書き込みや、この不揮発性メモリからのデータの読み出しが可能なようにされている。
入力インターフェイス115は、ユーザにより実際に入力操作が行われる入力装置からの入力信号が供給される。入力装置は、例えば、赤外線信号などで遠隔的にディスク再生装置100を操作するリモートコントロールコマンダや、このディスク再生装置100に直接的に設けられたキーなどである。入力インターフェイス115は、これらの入力装置から供給された入力信号を、CPU112に対する制御信号に変換して出力する。
ディスク101は、図18以降で説明したようなフォーマットで以て、プレイリスト、スクリプトプログラム、クリップインフォメーションファイル、クリップAVストリームファイルなどが記録されている。ディスク101がディスクドライブ102に装填されると、自動再生またはユーザの入力操作に従いディスク101が再生される。ディスク101から読み出されたスクリプトファイルやプレイリストファイル、クリップインフォメーションファイルは、CPU112に供給され、例えばCPU112が有するRAMに記憶される。CPU112は、RAMに記憶されたこれらのデータやスクリプトプログラムに基づき、ディスク101からクリップAVストリームファイルを読み出す。
ディスク101から読み出されたクリップAVストリームファイルは、メモリ113に一旦格納される。ビデオデコーダ116は、CPU112の命令に基づき、メモリ113に格納されたクリップAVストリームファイルのビデオストリームや字幕ストリームをデコードする。デコードされたビデオデータや字幕データは、例えばCPU112によりそれぞれ拡大、縮小処理などの画像処理を施されると共に、合成、加算処理を施され、1本のビデオデータとされる。これらの画像処理は、これに限らず、ビデオデコーダ116やビデオ出力インターフェイス118において行うこともできる。このビデオデータは、メモリ113にバッファリングされ、ビデオ出力インターフェイス118に供給される。ビデオ出力インターフェイス118は、例えば、供給されたビデオデータをアナログビデオ信号に変換して、ビデオ出力端子120に導出する。
同様に、オーディオデコーダ117は、CPU112の命令に基づき、メモリ113に格納されたクリップAVストリームファイルのオーディオストリームをデコードする。デコードされたオーディオデータは、メモリ113にバッファリングされ、オーディオ出力インターフェイス119に供給される。オーディオ出力インターフェイス119は、供給されたオーディオデータを、例えばアナログオーディオ信号に変換してオーディオ出力端子121に導出する。
なお、ここでは、図29に示される各部がそれぞれ独立したハードウェアで構成されているように説明したが、これはこの例に限定されない。例えば、ビデオデコーダ116および/またはオーディオデコーダ117は、CPU112上で動作するソフトウェアにより構成することができる。
また、上述したディスク再生装置100は、CPU112およびメモリを備え、プログラムにより動作するので、一種のコンピュータ装置として考えることができる。
図30は、図29に示したディスク再生装置100における動作をより詳細に説明するための機能ブロック図である。ディスク再生装置100は、概略的には、オペレーションシステム201と、ビデオコンテンツ再生部210とからなる。ビデオコンテンツ再生部210は、実質的には、オペレーションシステム201上で動作するソフトウェアプログラムである。これに限らず、ビデオコンテンツ再生部210は、ソフトウェアとハードウェアが統合的に動作するものとしてもよい。以下では、ビデオコンテンツ再生部210がソフトウェアであるものとして説明する。なお、図30では、ディスクドライブ102は、省略されている。
オペレーションシステム201は、ディスク再生装置100に電源が投入されるとCPU112において最初に起動し、各部の初期設定など必要な処理を行い、アプリケーションプログラム(ここではビデオコンテンツ再生部210)をROMから呼び出す。オペレーションシステム201は、ビデオコンテンツ再生部210の動作中に、ビデオコンテンツ再生部210に対して、ディスク101からのファイルの読み出しやファイルシステムの解釈といった、基本的なサービスを提供する。例えば、オペレーションシステム201は、ビデオコンテンツ再生部210から渡されたファイル読み出しリクエストに応じて、ドライブインターフェイス114を介してディスクドライブ102を制御し、ディスク101に記録されているデータを読み出す。読み出されたデータは、オペレーションシステム201の制御により、ビデオコンテンツ再生部210に渡される。
また、オペレーションシステム201は、マルチタスク処理機能を備え、複数のソフトウェアモジュールを、例えば時分割制御により見かけ上並列的に制御することができる。すなわち、図30に一例が示される、ビデオコンテンツ再生部210を構成する各モジュールは、オペレーションシステム201のマルチタスク処理機能により、全て、並列的な動作が可能である。
以下、ビデオコンテンツ再生部210の動作について、より具体的に説明する。ビデオコンテンツ再生部210は、内部にさらに幾つかのモジュールを有しており、下記の機能を実現する。
(1)装填されたディスク101がUMDビデオの規格に準じたディスク(以下、UMDビデオディスクと呼ぶ)であるか否かを判断する。
(2)装填されたディスク101がUMDビデオディスクであると判断した場合、ディスク101からリソースファイルを読み出して、スクリプト制御モジュール211に渡す。
(3)装填されたディスク101がUMDビデオディスクであると判断した場合、さらに、データベースを構成するファイル(プレイリストファイル、クリップインフォメーションファイルなど)を読み出して、プレーヤ制御モジュール212に渡す。
以下、ビデオコンテンツ再生部210の各モジュールの動作について説明する。
スクリプト制御モジュール211は、受け取ったリソースファイルを、例えばCPU112の図示されないRAMの所定領域に記憶する。CPU112(スクリプト制御モジュール211)は、このRAMに記憶されたスクリプトプログラムを読み込み、解釈して実行する。リソースファイルをメモリ113の所定領域に記憶させ、必要に応じてCPU112の図示されないRAMに読み込むようにしてもよい。
プレーヤモデルの説明で既に述べたように、メニュー画面などの画像の作成および出力や、ユーザ入力に応じたカーソル移動、メニュー画面の変更といったGUIは、スクリプトプログラムによりグラフィクス処理モジュール219を制御することで実現する。このとき、メモリ113上のリソースファイルに格納された画像データやサウンドデータが用いられ、メニュー画面などの作成が行われる。また、スクリプト制御モジュール211は、スクリプトプログラムの実行により、プレーヤ制御モジュール212の制御などが可能である。
プレーヤ制御モジュール212は、ディスク101から読み出された、プレイリストファイル"PLAYLIST.DAT"や、クリップインフォメーションファイル"XXXXX.CLP"といったファイルに格納されたデータベース情報を参照して、ディスク101に記録されているビデオコンテンツの再生に関わる、以下のような制御を行う。
(1)プレイリストやクリップインフォメーションといったデータベース情報を解析する。
(2)コンテンツデータ供給モジュール213、デコード制御モジュール214およびバッファ制御モジュール215を制御する。
(3)スクリプト制御モジュール211または入力インターフェイス115からの指示に従い、再生、再生停止、再生一時停止といったプレーヤの状態遷移制御や、ストリーム切り替えなどの再生制御処理を行う。
(4)デコード制御モジュール214から、再生中のビデオストリームについて、時刻情報を取得し、時刻表示やマークイベントの生成などを行う。
コンテンツデータ供給モジュール213は、プレーヤ制御モジュール212の指示に従い、ディスク101からクリップAVストリームファイルといったコンテンツデータを読み出し、バッファ制御モジュール215に渡す。バッファ制御モジュール215は、渡されたコンテンツデータをバッファの実体215Aとしてのメモリ113に溜め込む。コンテンツデータ供給モジュール213は、バッファ制御モジュール215を制御し、ビデオデコーダ制御モジュール216、オーディオデコーダ制御モジュール217および字幕デコーダ制御モジュール218からの要求に従い、メモリ113に溜め込まれたコンテンツデータを、これらのモジュール216、217および218に所定に供給する。また、コンテンツデータ供給モジュール213は、バッファ制御モジュール215により溜め込まれるコンテンツデータの量を所定に制御するように、ディスク101からコンテンツデータの読み込みを行う。
デコード制御モジュール214は、プレーヤ制御モジュール212の指示に従い、ビデオデコーダ制御モジュール216、オーディオデコーダ制御モジュール217および字幕デコーダ制御モジュール218の動作を制御する。また、デコード制御モジュール214は、内部に時計機能を有し、ビデオデータとオーディオデータとが同期的に出力されるように、各デコーダ制御モジュール216、217および218の動作を制御する。
バッファ制御モジュール215は、バッファの実体215Aとして、メモリ113の一部を排他的に用いる。また、バッファ制御モジュール215は、データ先頭ポインタおよびデータ書き込みポインタを記憶する。バッファ制御モジュール215は、さらに、内部モジュールとしてビデオ読み出し機能、オーディオ読み出し機能および字幕読み出し機能を有する。ビデオ読み出し機能の内部には、ビデオ読み出しポインタを有する。また、ビデオ読み出し機能の内部には、アクセスユニット情報である情報au_information()を蓄積するためのレジスタを備える。オーディオ読み出し機能の内部には、オーディオ読み出しポインタを有する。字幕読み出し機能の内部には、字幕読み出しポインタと字幕読み出し機能フラグとを有する。字幕読み出し機能フラグは、書き込む値に応じて字幕読み出し機能の有効/無効を制御する。例えば、字幕読み出し機能フラグに"1"を書き込むと、字幕読み出し機能が有効とされ、"0"を書き込むと、字幕読み出し機能が無効とされる。
バッファ制御モジュール215の内部モジュールであるビデオ読み出し機能、オーディオ読み出し機能および字幕読み出し機能は、さらに、ビデオストリーム、オーディオストリームおよび字幕ストリームが多重化されたクリップAVストリームから、それぞれのストリームを分離するデマルチプレクサ機能を有する。この発明の実施の一形態では、MPEG2システムのプログラムストリームの形式で複数のエレメンタリストリームが時分割多重されて、クリップAVストリームが形成されている。したがって、ビデオ読み出し機能、オーディオ読み出し機能および字幕読み出し機能は、MPEG2システムのプログラムストリームに対するデマルチプレクサ機能を有する。
このため、ビデオ読み出し機能は、ストリーム内に所定に配置されるフィールドstream_id(図25参照)の値を読み取り、保持する。同様に、オーディオ読み出し機能および字幕読み出し機能は、フィールドstream_idおよびフィールドprivate_stream_id(図25参照)の値を読み取り、保持する。これらフィールドstream_idやフィールドprivate_stream_idの値は、供給されたビットストリームを解析する際に用いる。
ビデオデコーダ制御モジュール216は、メモリ113からビデオストリームの単一のビデオアクセスユニットを読み出してビデオデコーダ116に供給するように、バッファ制御モジュール215内のビデオ読み出し機能に対して指示を出す。そして、ビデオデコーダ制御モジュール216は、ビデオデコーダ116を制御して、ビデオデコーダ116に供給されたビデオストリームをアクセスユニット単位でデコードする。ビデオストリームをデコードして生成されたビデオデータは、グラフィクス処理モジュール219に供給される。
同様に、オーディオデコーダ制御モジュール217は、メモリ113からオーディオストリームの単一のオーディオアクセスユニットを読み出してオーディオデコーダ117に供給するように、バッファ制御モジュール215内のオーディオ読み出し機能に対して指示を出す。なお、この実施の一形態では、オーディオストリームを構成するアクセスユニット(オーディオフレーム)は、既知の固定長とする。そして、オーディオデコーダ制御モジュール217は、オーディオデコーダ117を制御して、オーディオデコーダ117に供給されたオーディオストリームをアクセスユニット単位でデコードする。オーディオストリームをデコードして生成されたオーディオデータは、オーディオ出力モジュール242に供給される。
さらに、字幕デコーダ制御モジュール218は、メモリ113から字幕ストリームの単一の字幕アクセスユニットを読み出して字幕デコーダ制御モジュール218に供給するように、バッファ制御モジュール215内の字幕読み出し機能に対して指示を出す。なお、この実施の一形態では、字幕ストリームを構成する字幕アクセスユニットは、ユニットの先頭に当該ユニットの長さ情報が格納されている。字幕デコーダ制御モジュール218は、字幕デコード機能を有し、供給された字幕ストリームをデコードすることができる。字幕デコーダ制御モジュール218の字幕デコード機能により字幕ストリームがデコードされた字幕の画像データは、グラフィクス処理モジュール219に供給される。
グラフィクス処理モジュール219は、上述したように、ビデオデコーダ制御モジュール216の制御に基づきビデオデコーダ116でデコードされたビデオデータと、字幕デコーダ制御モジュール218によりデコードされた字幕の画像データとが供給される。グラフィクス処理モジュール219は、供給されたこれらビデオデータに対して字幕の画像データを所定に加算し、出力するためのビデオ信号を生成する。グラフィクス処理モジュール219では、さらに、スクリプト制御モジュール211やプレーヤ制御モジュール212の指示に従い、メニュー画像やメッセージ画像を生成し、出力ビデオ信号に対して合成(オーバーレイ)する。
例えば、グラフィクス処理モジュール219は、供給された字幕の画像データに対して、スクリプト制御モジュール211からの指示に従い拡大処理や縮小処理を行い、ビデオデータに対して所定に加算する。
また、グラフィクス処理モジュール219は、予め指定された出力ビデオデバイスのアスペクトレシオと、ディスク101から再生されたコンテンツ内で指定された出力アスペクトレシオとに基づき、出力信号のアスペクト変換を行う。例えば、出力ビデオデバイスのアスペクトレシオが16:9である場合、出力アスペクトレシオが16:9であれば、ビデオデータをそのまま出力し、出力アスペクトレシオが4:3であれば、出力されるビデオデータを、画像の高さが出力ビデオデバイスの画面高さに一致するようにスクイーズ(縮小)処理し、画像の左右に黒画像を挿入して出力する。出力ビデオデバイスが4:3である場合には、出力アスペクトレシオが4:3であれば、ビデオデータをそのまま出力し、出力アスペクトレシオが16:9であれば、出力されるビデオデータを、画像の幅が出力ビデオデバイスの画面幅に一致するようにスクイーズ処理し、画像の上下に黒画像を挿入して出力する。
グラフィクス処理モジュール219は、さらに、プレーヤ制御モジュール212からの要求に応じて、現在処理中のビデオ信号をキャプチャし、プレーヤ制御モジュール212に返すような処理も行う。
ビデオ出力モジュール241は、メモリ113の一部を排他的に占有してFIFO(First In First Out)のバッファとして用い、グラフィクス処理モジュール219により処理されたビデオデータをこのバッファに一時的に溜め込み、所定のタイミングで読み出す制御を行う。バッファから読み出されたビデオデータは、ビデオ出力インターフェイス118から出力される。
オーディオ出力モジュール242は、メモリ113の一部を排他的に占有してFIFOのバッファとして用い、オーディオデコーダ119から出力されたオーディオデータをこのバッファに溜め込み、所定のタイミングで読み出す制御を行う。バッファから読み出されたオーディオデータは、オーディオ出力インターフェイス119から出力される。
また、オーディオ出力モジュール242は、コンテンツのオーディオモードがデュアルモノ(例えば2ヶ国語)であった場合、予め指定された音声出力モードに従いオーディオデータを出力する。音声出力モードが「主音声」に指定されている場合、例えばメモリ113において左チャンネルのオーディオデータを右チャンネルにもコピーして、2チャンネルの出力を両方とも左チャンネルのオーディオデータとして出力する。音声出力モードが「副音声」であった場合には、例えばメモリ113において右チャンネルのオーディオデータを左チャンネルにもコピーして、2チャンネルの出力を両方とも右チャンネルのオーディオデータとして出力する。音声出力モードが「主・副音声」である場合や、コンテンツがステレオである場合には、オーディオデータをそのまま出力する。
このような音声出力モードの設定は、ビデオコンテンツ再生部210が生成するメニュー画面などにより、ユーザが対話的に行うことができるようになっている。
不揮発性メモリ制御モジュール250は、プレーヤ制御モジュール212からの指示により、ビデオコンテンツ再生部210が終了しても消去されない領域へのデータの書き込みや、当該領域からのデータの読み出しを行う。タイトル識別ID(Title_ID)をキーとして、データSaved_Player_StatusおよびデータSaved_User_Dataの組を複数件、当該領域に記憶する機能を有する。データSaved_Player_Statusとして、プレーヤ制御モジュール212の持つデータBackup_Player_Statusが記憶される。このデータBackup_Player_Statusは、例えば上述したプレーヤステータス323Bの、プレーヤ制御モジュール212が終了する直前のデータに対応し、データSaved_Player_Statusは、リジュームインフォメーション324に対応する。また、データSaved_User_Dataとして、プレーヤ制御モジュール212が持つデータUser_Dataが記憶される。データUser_Dataは、ユーザによりプレーヤ制御モジュール212に対して設定された所定のデータである。
不揮発性メモリ制御モジュール250は、ディスク装置100が有する不揮発性メモリの所定領域にこれらデータSaved_Player_StatusおよびデータSaved_User_Dataの組を、ディスク101のタイトルIDと関連付けて記憶する。不揮発性メモリ制御モジュール250がデータを記憶する記憶媒体は、不揮発性メモリに限らず、例えばハードディスクなどでもよい。
8.ムービープレーヤの状態遷移モデルについて
8−1.ムービープレーヤの状態の定義について
次に、この発明の実施の一形態に適用できるムービープレーヤ300の状態遷移モデルについて、より詳細に説明する。この発明では、ムービープレーヤ300の状態を、ムービープレーヤ300の内部状態においてのみ、定義する。すなわち、この発明では、ムービープレーヤ300の状態を、ムービープレーヤ300それ自身の動作および機能に基づきそれぞれ定義する。
より具体的には、動作面において、プレイリスト再生の観点から、ムービープレーヤ300がプレイ状態にあるかストップ状態にあるかの2状態を定義する。また、機能面において、ムービープレーヤ300がネイティブ実装プラットフォーム301からの制御コマンドを受け付けるか否かの2状態を定義する。
図31は、この発明によるムービープレーヤ300の状態の定義を概念的に示す。ムービープレーヤ300の動作面から見た状態について説明する。図3も参照し、ムービープレーヤ300は、プレイリスト再生の観点から、プレイ状態およびストップ状態の何れかの状態にある。プレイ状態は、ムービープレーヤ300がプレイリストを選択し、選択されたプレイリストの再生を行っている状態である。一方、ストップ状態は、ムービープレーヤ300がプレイリストを再生していない状態である。ストップ状態では、プレイリストは、選択されていない。換言すれば、ムービープレーヤ300のプレイバックモジュール321でクリップAVストリームがデコードされている状態がプレイ状態であって、デコードされていない状態がストップ状態であるといえる。
なお、プレイ状態は、さらに幾つかの状態に細分化される。例えば、順方向1倍速の通常再生、順方向および逆方向への1倍速以外の再生速度で再生する変速再生、一時停止といった、各種の再生状態をプレイ状態に含む。コマ送りおよびコマ戻し再生は、通常再生と一時停止とを交互に行うことで実現される。このような、プレイリストの再生中は、ムービープレーヤ300は、プレイ状態にあることと同義である。
ムービープレーヤ300の機能面から見た状態について説明する。ムービープレーヤ300は、機能の観点から、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付けるモード(ノーマルモードと呼ぶ)と、制御コマンド311を無視するモード(メニューモードと呼ぶ)との2つの動作モードを有する。これらムービープレーヤ300の2つの動作モードを、それぞれムービープレーヤ300の状態として定義する。
ノーマルモードは、ムービープレーヤ300の動作を、スクリプトレイヤ302のスクリプトプログラムを介さずに、ユーザ入力310によって制御することができる。
一方、メニューモードは、ムービープレーヤ300が制御コマンド311を受け付けない。ムービープレーヤ300は、スクリプトレイヤ302からのメソッド313のみを受け付ける。そのため、ムービープレーヤ300の動作を、スクリプトレイヤ302のスクリプトプログラムで全て、制御できる。例えば、ユーザ入力310は、ネイティブ実装プラットフォーム301からのイベント314として、スクリプトレイヤ302に渡される。スクリプトレイヤ302のスクリプトプログラムは、このイベント314に応じたメソッド313を用いて、ムービープレーヤ300の動作を制御する。
すなわち、メニューモードを用いることで、ムービープレーヤ300の動作をコンテンツ制作者側が制御することができる。また、メニューモードを利用することで、少ない種類のキーで多彩な制御を実現することができる。
このように、ムービープレーヤ300は、動作面ではプレイ状態とストップ状態の2状態を有すると共に、機能面ではノーマルモードとメニューモードの2つの動作モードを有する。したがって、ムービープレーヤ300としては、これら動作面の2状態と機能面の2動作モードとをそれぞれ組み合わせた、4状態が定義される。すなわち、ムービープレーヤ300は、生成されてから消滅するまでの間、この4状態のうち何れかの状態に属する。ムービープレーヤ300の生成および消滅については、後述する。
なお、ムービープレーヤ300に対して現在の状態と異なる状態に遷移することを指示するメソッド313を発行すると、モデル上では、ムービープレーヤ300は、発行されたメソッド313に応じて即座に状態を遷移させる。実際の機器においては、ムービープレーヤ300に対してあるメソッド313を発行してから、ムービープレーヤ300が当該メソッド313に応じた状態遷移を完了するまでの時間は、当該機器の実装に依存することになる。
また、ある状態にあるムービープレーヤ300に対して、当該状態と同一の状態に状態遷移させることを指示するメソッド313を発行しても、ムービープレーヤ300の状態は、変化しない。例えば、既にノーマルモードで、且つ、ストップ状態にあるムービープレーヤ300に対して、ムービープレーヤ300の状態をノーマルモードで且つストップ状態に遷移させるようなメソッド313を発行しても、ムービープレーヤ300の状態は、変化しない。
さらに、一時停止(ポーズ)状態は、プレイ状態の一種である。ストップ状態から一時停止状態に遷移させるためには、一時停止を指定する値pauseModeを引数としたメソッドplay()を用いる。
次に、ムービープレーヤ300の2状態と2動作モードとを組み合わせた4状態それぞれの状態と、4状態間の状態遷移について説明する。以下では、ムービープレーヤ300の状態を機能面で分類した状態のうち、ノーマルモードを「normal」とし、メニューモードを「menu」とする。また、ムービープレーヤ300の状態を動作面で分類した状態のうち、プレイ状態を「play」とし、ストップ状態を「stop」とする。そして、ムービープレーヤ300のモード(mode)および状態(status)の組み合わせを、便宜的に、状態{mode,status}と表す。また、以下では、ムービープレーヤ300における状態の変化とモードの切り換えとを、共に状態遷移と呼ぶ。
図31からも分かるように、ムービープレーヤ300の状態遷移は、自らの状態への遷移も含めると、4×4=16通りが存在する。これらの状態遷移は、スクリプトレイヤ302からムービープレーヤ300に渡されるメソッド313によって引き起こされる。すなわち、ムービープレーヤ300における状態遷移は、ムービープレーヤ300の外部から引き起こされ、スクリプトレイヤ302からのメソッドによる指示無しに、ムービープレーヤ300の内部で自動的に状態遷移が発生することが無い。また、ネイティブ実装プラットフォーム301からの制御コマンドでも、ムービープレーヤ300において状態遷移が発生することが無い。
なお、この実施の一形態では、メソッド313の引数の組み合わせに制限があるため、ムービープレーヤ300において可能な16通りの状態遷移の全てをメソッドで発生させることは、できない。
以下、ムービープレーヤ300が取り得る4状態(状態{Menu,Stop}、状態{Normal,Stop}、状態{Menu,Play}および状態{Normal,Play})について、それぞれ説明する。
(1)状態{Menu,Stop}
ムービープレーヤ300がプレイリストの再生を行っていないストップ状態で、且つ、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付けない状態である。この状態は、例えば背景に動画が再生されていないメニュー画面などで用いられる。
ムービープレーヤ300の生成直後にスクリプトプログラムからの制御を確実なものとするためには、その時点でネイティブ実装プラットフォーム301からの制御コマンド311を受け付けないようにすることが有効である。そのため、ムービープレーヤ300の生成直後は、この状態{Menu,Stop}になるように定める。
(2)状態{Normal,Stop}
ムービープレーヤ300がプレイリストの再生を行っていないストップ状態で、且つ、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付ける状態である。この状態は、例えば動画を再生していない状態で用いられる。この状態は、制御コマンド311を受け付けるので、ムービープレーヤ300の生成直後には用いないのが好ましい。
(3)状態{Menu,Play}
ムービープレーヤ300がプレイリストの再生を行っているプレイ状態で、且つ、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付けない状態である。この状態は、例えば背景に動画が再生されているメニュー画面などで用いられる。
(4)状態{Normal,Play}
ムービープレーヤ300がプレイリストの再生を行っているプレイ状態で、且つ、ネイティブ実装プラットフォーム301からの制御コマンド311を受け付ける状態である。この状態は、例えば本編の再生中などに用いられる。
上述した、ムービープレーヤ300が生成される際のモデルについて、概略的に説明する。ムービープレーヤ300の生成は、例えば上述したように、ディスク再生装置100に電源が投入され、CPU112においてオペレーションシステム201が起動されると、各部の初期設定など必要な処理を行うと共に、ビデオコンテンツ再生部210をROMから呼び出す。このビデオコンテンツ再生部210がCPU112により実行されることでなされる。ディスク再生装置100において電源がOFF状態とされると、ムービープレーヤ300が消滅される。
ここで、ムービープレーヤ300は、暗黙の(implicit)オブジェクトが生成されているものと見做され、スクリプトプログラムにおいて明示的にムービープレーヤ300の生成を行う必要はない。
上述したように、ムービープレーヤ300生成直後の状態は、メニューモードのストップ状態(状態{Menu,Stop})とされる。ムービープレーヤ300の生成直後では、例えばムービープレーヤ300が持つ下記のプロパティが不定値となる。
プロパティaudioFlag
プロパティaudioNumber
プロパティchapterNumber
プロパティplayListNumber
プロパティplaySpeed
プロパティsubtitleFlag
プロパティsubtitleNumber
プロパティvideoNumber
なお、前回再生を停止された位置から再生を開始する「続き再生機能」を備えるUMDビデオプレーヤでは、ムービープレーヤ300の初期化において、例えば上述の各プロパティについて、各プロパティのデフォルト値ではなく不揮発性メモリに保存された値を用いて値を設定することができる。例えば、リジュームインフォメーション324を利用できる。
8−2.ムービープレーヤに状態遷移を発生させるメソッドについて
次に、ムービープレーヤ300に状態遷移を発生させるメソッド313について説明する。図32は、現在の状態{Mode,Status}と、メソッド313によって状態遷移した後の状態{Mode,Status}を、ムービープレーヤ300の4状態のそれぞれについて組み合わせて示す。図32から分かるように、ムービープレーヤ300に対して状態遷移を発生させるメソッド313として、メソッドstop()、メソッドplay()およびメソッドresume()が用意される。なお、メソッドresume()は、リジュームインフォメーション324が存在するか否かで動作が変化する。
メソッドstop()について説明する。メソッドstop()は、ムービープレーヤ300の状態の如何に関わらず、ムービープレーヤ300をストップ状態に遷移させる。メソッドstop()は、引数にモードを指定することができ、ストップ状態への遷移と同時に、ムービープレーヤ300のモードを変更することができる。後述するように、ある条件を満たしてメソッドstop()が実行されると、プレーヤステータス323Bがバックアップされ、リジュームインフォメーション324として保持される。
メソッドplay()について説明する。メソッドplay()は、ムービープレーヤ300をプレイ状態に遷移させる。メソッドplay()は、引数にモードを指定することができ、プレイ状態への遷移と同時に、ムービープレーヤ300のモードを変更することができる。後述するように、ある条件を満たしてメソッドplay()が実行されると、プレーヤステータス323Bがバックアップされると共に、リジュームインフォメーション324が保持される。
メソッドresume()について説明する。メソッドresume()は、リジュームインフォメーション324をプレーヤステータス323Bにリストアして再生復帰させるメソッドである。すなわち、メソッドresume()は、ムービープレーヤ300に対して、リジュームインフォメーション324で示された位置からの再生を開始させる。リジュームインフォメーション324が存在しない状態でメソッドresume()が実行されても、ムービープレーヤ300の状態は変化しない。
メソッドresume()によってリジュームインフォメーション324がリストアされる条件は、次の通りである。メソッドresume()が実行された際に、リジュームインフォメーション324が存在し、且つ、現在の状態が状態{Normal,Play}でなければ、ムービープレーヤ300は、リジュームインフォメーション324をリストアする。換言すれば、メソッドresume()が実行された際に、リジュームインフォメーション324が存在し、且つ、現在の状態が状態{Menu,Stop}、状態{Normal,Stop}および状態{Menu,Play}のうち何れかであれば、ムービープレーヤ300は、状態{Normal,Play}に遷移すると同時に、リジュームインフォメーション324をリストアする。
メソッドplay()は、複数の引数を持つ。ここでは、説明のため、メソッドplay()は、引数pauseMode、引数menuModeおよび引数playListNumberの3種類の引数を持つものとする。実際には、さらに多くの引数が定義される。
引数pauseModeは、プレイ状態における再生の状況を指定し、値「x1」、値「pause」および値「-1」の何れかの値を取り得る。値「x1」は、通常速度の順方向再生を指定する。値「pause」は、一時停止を指定する。値「-1」は、現状の再生速度を維持するよう指定する。このように、引数pauseModeは、メソッドplay()実行後のムービープレーヤ300のプレイ状態の詳細を設定する。なお、一時停止を指定した場合、引数で指定される位置のピクチャ、または引数による指定がない場合は、別途定められた選択ルールで指定される位置のピクチャが表示されて一時停止した状態になる。
引数menuModeは、ムービープレーヤ300のモード(ノーマルモードおよびメニューモード)を指定し、値「Normal」、値「Menu」および値「-1」の何れかの値を取り得る。値「Normal」は、ノーマルモードへの切り換えを指定する。値「Menu」は、メニューモードへの切り換えを指定する。値「-1」は、現在のモードを維持するよう指定する。
引数playListNumberは、再生するプレイリストの番号を指定する。引数playListNumberは、省略することができ、その場合には、現在選択しているプレイリストのまま変更がないことを表す。
図33を用いて、メソッドplay()を実行した際のムービープレーヤ300の状態遷移の例について説明する。なお、図33A〜図33Eの各図において、左側は、ムービープレーヤ300の現在の状態340Aを示し、右側は、現在の状態340Aのムービープレーヤ300に対してスクリプトプログラムがメソッド313を発行することで遷移された遷移後の状態340Bを示す。また、状態340Aおよび340Bの下に、その状態において指定されているプレイリスト番号(PL1、PL2)が示される。
図33Aは、状態{Normal,Stop}の状態にあるムービープレーヤ300に、メソッドplay(x1,Normal,PL2)を発行した場合の例である。メソッドplay(x1,Normal,PL2)に応じて、ムービープレーヤ300の状態がプレイリスト番号「PL2」のプレイリストをノーマルモード且つ通常速度で再生する状態になることを表している。ムービープレーヤ300は、状態{Normal,Stop}から状態{Normal,Play}に状態遷移している。
図33Bは、プレイリスト番号「PL1」のプレイリストを再生中に一時停止している、状態{Normal,Play}の状態にあるムービープレーヤ300に、メソッドplay(x1,Normal,PL2)を発行した場合の例である。メソッドplay(x1,Normal,PL2)に応じて、ムービープレーヤ300の状態がプレイリスト番号「PL2」のプレイリストをノーマルモード且つ通常速度で再生を開始する状態になることを表している。この場合、ムービープレーヤ300の再生動作が一時停止から順方向の通常速度再生に変化するが、状態は、メソッドplay(x1,Normal,PL2)の発行の前後で状態{Normal,Play}のままであり、状態遷移は発生していない。
図33Cは、プレイリスト番号「PL1」のプレイリストを順方向の通常速度で再生中の、状態{Normal,Play}の状態にあるムービープレーヤ300に、メソッドplay(-1,-1,PL2)を発行した場合の例である。メソッドplay(-1,-1,PL2)に応じて、ムービープレーヤ300の状態がプレイリスト番号「PL2」のプレイリストをノーマルモード且つ通常速度で再生する状態になることを表している。この場合も、ムービープレーヤ300で再生されるプレイリストが変更されるが、状態は、状態{Normal,Play}のままであり、状態遷移は発生していない。
図33Dは、プレイリスト番号「PL1」のプレイリストを順方向の通常速度で再生中の、状態{Normal,Play}の状態にあるムービープレーヤ300に、メソッドplay(pause,-1,PL2)を発行した場合の例である。メソッドplay(pause,-1,PL2)に応じて、ムービープレーヤ300は、プレイリスト番号「PL2」のプレイリストを選択すると共に、ノーマルモード且つプレイリスト番号「PL2」のプレイリストの先頭で一時停止している状態になることを表している。この場合も、ムービープレーヤ300の再生動作が順方向の通常速度再生から一時停止に変化するが、状態は、状態{Normal,Play}のままであり、状態遷移は発生していない。
図33Eは、プレイリスト番号「PL1」のプレイリストを再生中に一時停止している、状態{Normal,Play}の状態にあるムービープレーヤ300に、メソッドplay(-1,Menu)を発行した場合の例である。メソッドplay()において、引数playListNumberが省略されている。メソッドplay(-1,Menu)に応じて、ムービープレーヤ300は、プレイリスト番号「PL1」のプレイリストを選択すると共に、メニューモード且つプレイリスト番号「PL1」のプレイリストの先頭で一時停止している状態になることを表している。ムービープレーヤ300は、状態{Normal,Play}から状態{Menu,Stop}に状態遷移している。
このように、ムービープレーヤ300は、スクリプトプログラムからのメソッドplay()を受けて様々な動作を行い、その際、条件によっては状態遷移を生じる。コンテンツ制作者は、引数を変えたメソッドplay()をスクリプトプログラムに記述することで、ムービープレーヤ300における様々な動作を実現することができる。
なお、ムービープレーヤ300は、スクリプトプログラムからメソッドplay()を実行することによってのみ、プレイリスト番号を選択したプレイリストの再生を開始する。プレイリストの再生開始とは、ストップ状態からプレイリストの再生を開始すること、あるいは、あるプレイリストの再生を中断して新たなプレイリストを選択し、選択されたプレイリストの再生を開始することを指す。
スクリプトプログラムがムービープレーヤ300に対し、引数付きのメソッドplay()を発行した際には、引数の値がプレーヤステータス323Bにセットされる。省略された引数については、各パラメータ毎に定められたルールに従い、デフォルト値や自動選択によって当該引数の値がセットされる。
また、コンテンツ制作者の意図しない順序でプレイリストを再生できてしまっては問題があるため、ユーザ操作に起因する制御コマンド311では、プレイリスト番号を指定してのプレイリスト再生開始ができないようにされる。これは、この発明の実施の一形態によるムービープレーヤ300の動作モデルにおける特徴の一つである。
さらに、メソッドplay()の引数の値として、無効なプレイリストや、存在しない時刻が指定された場合は、そのメソッドplay()の実行は、失敗する。これは、スクリプトプログラムに誤りがあることを意味し、当該スクリプトプログラムが規格違反を含んでいることになる。このときのエラーハンドリングは、ムービープレーヤ300の実装依存になる。
ここで、プレイアイテム間の再生について説明する。ムービープレーヤ300は、一旦プレイリストの再生を開始すると、そのプレイリストの最後まで再生を継続する。1つのプレイリストの先頭から最後までの再生は、ユーザ操作や、スクリプトプログラムからの制御を要しない。ムービープレーヤ300は、図34に概略的に示されるように、プレイリストを構成するプレイアイテムを、プレイリストファイル"PLAYLIST.DAT"(図19参照)で指定された通りに順次、再生していく。プレイリストを構成するプレイアイテムは、イベントハンドラによる制御無しで、連続的に再生される。
プレイアイテムを再生し終えてから次のプレイアイテムを再生するまでの間の動作は、ムービープレーヤ300の実装依存であり、フォーマットでは規定しない。例えば、プレイアイテムの最後のピクチャを表示し続けるか、直ちに黒画面にしてしまうか、といったプレイアイテム間の動作は、実装依存となる。ただし、プレイアイテムのIN点をランダムアクセスポイント(エントリポイント:図28参照)に設定するなどのオーサリング上の工夫を行うことにより、プレイアイテム間でのギャップ時間ができるだけ短くなるような配慮をすることは、可能である。
8−3.プレイリスト再生中のムービープレーヤの動作について
次に、プレイリスト再生中のムービープレーヤ300の動作について説明する。例えば2倍速再生、3倍速再生といった高速再生や、1/2倍速再生のような低速再生、また、逆方向再生などの、ユーザによる変速再生指示は、ユーザ入力310としてネイティブ実装プラットフォーム301に対して入力され、このユーザ入力310に応じて、実装に依存した制御コマンド311の形でネイティブ実装プラットフォーム301からムービープレーヤ300に伝えられる。
変速再生時の速度は、ムービープレーヤ300の実装に依存する。例えば、速度指定が可能なネイティブ実装プラットフォーム301の命令としてムービープレーヤ300に伝える、「より速く」か「より遅く」を引数としてムービープレーヤ300に渡し、ムービープレーヤ300が実現可能な速度に変換する、などの変速再生の実現方法が考えられ、どの方法を用いるかは、ムービープレーヤ300の実装に依存する。スクリプトプログラムは、メソッドgetPlayerStatus()により、ムービープレーヤ300が決めた速度を知ることができる。
一方、スクリプトプログラムからムービープレーヤ300に対するメソッドplay()では、引数で速度を指定することが出来ない。メソッドplay()は、一時停止(引数「pause」)および通常速度再生(引数「x1」)の2通りのみが指定できる。
ムービープレーヤ300は、プレイリストを順方向で変速再生しているときにプレイアイテムの終わりに到達した場合、次のプレイアイテムの再生を行う。このとき、ムービープレーヤ300は、当該次のプレイアイテムを前のプレイアイテムと同じ向き、同じ速度で再生し、変速再生を継続する。
図35は、プレイリストの再生中にプレイリストの始点、終点に到達したときのムービープレーヤ300の一例の動作を示す。ムービープレーヤ300は、順方向で再生中にプレイリストの最後に到達した場合、最後のピクチャを表示したまま一時停止となる。最後のピクチャを消去するには、イベントハンドラonPlayListEndなどの中で、明示的にムービープレーヤ300に対して停止(メソッドstop()発行)を指示する必要がある。
なお、通常速度よりも高速で再生を行う高速再生時では、プレイリストの終点に到達した際に、プレイリストの最後のピクチャが飛び込み点に該当していなくても、プレイリストの最後のピクチャを表示する。
一方、ムービープレーヤ300は、プレイリストを逆方向で再生中にプレイアイテムの先頭に到達した場合、前のプレイアイテム、すなわち、順方向に再生した場合に時間的に前に再生されるようになっているプレイアイテムの再生を行う。この、前のプレイアイテムの再生も、最後から先頭に向かっての逆方向再生を継続する。再生速度も維持される。また、逆方向再生中にプレイリストの先頭に到達した時には、変速再生は解除され、ムービープレーヤ300は、プレイリストの先頭で一時停止となる。
さらに、ムービープレーヤ300は、一時停止を指示する制御コマンド311によっても、状態が一時停止に変化する。制御コマンド311で一時停止を解除したときのプレイリストの再生方向、再生速度は、UMDビデオプレーヤの実装依存である。
次に、プレイリストの再生中に発生するイベントについて説明する。プレイリスト再生中に発生するイベントには、図13を用いて既に説明したように、ユーザ操作に応じたイベントangleChange、イベントaudioChangeおよびイベントsubtitleChange、ならびに、プレイリスト中に埋め込まれたマークに応じたイベントchapterおよびイベントeventマークがある。また、イベント発生時の動作の詳細な例は、図15を用いて既に説明されている。
ここでは、プレイリストの最後での処理について説明する。既に説明したように、ムービープレーヤ300は、メソッドplay()によって指定された番号のプレイリストを再生する。一旦プレイリストの再生が開始されると、スクリプトプログラムや制御コマンド311による制御無しに、当該プレイリストの最後まで、再生が継続される。再生がプレイリストの最後に到達すると、ムービープレーヤ300は、イベントplayListEndをスクリプトプログラムに通知する。プレイリストの最後に到達するまでの方法については、問わない。すなわち、プレイリストの再生が通常再生、早送り再生、他プレイリストからの飛び込みによる再生などの如何によらず、プレイリストの最後に到達した時点で、ムービープレーヤ300は、イベントplayListEndを発生する。
再生がプレイリストの最後に到達し、イベントplayListEndが発生されると、ムービープレーヤ300の状態が一時停止になり、ムービープレーヤ300が内部的に有するプレイリストの再生時刻は、プレイリストの最後の時刻に一致している。なお、プレイリストの最後の時刻とは、プレイリストの最後のピクチャの再生終了時刻で、再生時間軸上で最後のプレイアイテムのOUT点と一致する。
イベントplayListEndは、プレイリストを一列に再生させる場合や、マルチストーリの分岐点でメニューを表示させるためなどに利用できる。
例えば、スクリプトプログラムは、イベントplayListEndが発生したときに実行するプログラムとして、イベントハンドラonPlayListEndを有していれば、そのイベントハンドラonPlayListEndを実行する。このイベントハンドラonPlayListEndに、他のプレイリストの再生を開始するメソッドplay()が記述されていれば、ムービープレーヤ300は、他のプレイリストの再生を開始することになる。このようにして、プレイリストの再生が継続される。
図36を用いてより具体的に説明すると、プレイリスト番号「PL1」のプレイリストの再生が終了して、イベントplayListEndが発生する。このイベントplayListEndの発生を受けて、スクリプトプログラムが有するイベントハンドラonPlayListEndが実行される。このイベントハンドラonPlayListEndには、プレイリスト番号「PL2」のプレイリストの再生が指定されている。ムービープレーヤ300は、このイベントハンドラonPlayListEndを受けて、指定されたプレイリスト番号「PL2」のプレイリストを再生する。
再生パスは、プレイリスト番号「PL1」のプレイリストの最後から一旦イベントハンドラonPlayListEndに移り、さらにプレイリスト番号「PL2」のプレイリストの先頭に移ることになる。
また例えば、マルチストーリの分岐点でメニューを表示させるような場合には、プレイリストの最後を分岐点とし、イベントplayListEndに対応するイベントハンドラonPlayListEndにメニュー画面を表示させるプレイリストを再生する指示を記述することが考えられる。
図37は、プレイリストの最後におけるスクリプトレイヤ302での処理の流れと、ムービープレーヤ300の動作の一例をより詳細に示す。図37において、ステップS30〜ステップS33がスクリプトレイヤ302側の処理を示し、ステップS40〜ステップS44がムービープレーヤ300側の処理を示す。
あるプレイリストを最後まで再生した後、次のプレイリストが再生されるためには、スクリプトプログラムによる明示的な再生指示が必要である。プレイリストの再生順序は、スクリプトプログラムで決められているため、ムービープレーヤ300側では次に再生すべきプレイリストを自発的に決めることはできない。
再生がプレイリストの最後に到達すると(ステップS40)、ムービープレーヤ300は、イベントplayListEndをスクリプトレイヤ302に通知する(ステップS41)。ムービープレーヤ300は、ステップS40で最後まで再生されたプレイリストの最後のピクチャを表示し続けたまま、一時停止に状態遷移する(ステップS42)。
スクリプトレイヤ302は、イベントplayListEndを受けて、イベントハンドラonPlayListEndが実行される(ステップS30)。ムービープレーヤ300の次の動作は、このイベントハンドラonPlayListEnd内でのスクリプトの記述によって決まる。
なお、ムービープレーヤ300は、ステップS40の後、プレイリストの最後で一時停止しているときに一時停止解除あるいは順方向再生を開始するメソッドや制御コマンド311を受けても、無視する。順方向再生を開始するメソッドは、引数で順方向再生を指示したメソッドplay()およびメソッドplayStep()である。また、順方向再生を開始する制御コマンド311としては、コマンドuo_play()、コマンドuo_playNextChapter()、コマンドuo_forwardScan()、コマンドuo_playStep()、コマンドuo_pauseOn()およびコマンドuo_pauseOff()があり、これらのコマンドは、プレイリストの最後で一時停止しているときには無視される。
プレイリストの最後で一時停止しているときでも、メソッドstop()やメソッドresume()は有効である。また、モード切替も、プレイリストの最後の一時停止状態において有効である。
イベントplayListEndが発生した後でも、ノーマルモードのムービープレーヤ300は、順方向再生を開始する制御コマンド311以外の制御コマンド311を受け付ける。その場合でも、スクリプトプログラムからムービープレーヤ300に対してメソッド313が実行されると、そのメソッド313が指示する動作に従う。
図37の例では、イベントハンドラonPlayListEndでメソッドstop()が指示される(ステップS31)。ムービープレーヤ300は、メソッドstop()の実行により、制御コマンド311によって引き起こされた動作は中断され、ストップ状態に遷移する(ステップS43)。ストップ状態では、例えば直前まで再生していたプレイリストの最後のピクチャが消去され、黒画面とされる。
さらに、スクリプトレイヤ302では、イベントハンドラonPlayListEndにおいて、次のプレイリストを再生するためのメソッド313が指示される(ステップS32)。例えば、メソッドplay()において、引数pauseModeとして値「x1」、引数menuModeとして値「Menu」および引数playListNumberとして次に再生するプレイリスト番号がそれぞれ指定され、ムービープレーヤ300に対して、メニューモードにモードを切り換えると共に、引数playListNumberで指定された番号のプレイリストを通常速度再生で再生することが指示される。そして、スクリプトレイヤ302において、イベントハンドラonPlayListEndが終了される(ステップS33)。ムービープレーヤ300側では、ステップS32で指示されたメソッドplay()に応じてモードが切り換えられると共に、指定されたプレイリストが指定された速度で再生開始される(ステップS44)。
なお、コンテンツ制作者は、ユーザの操作性を高めるため、プレイリストの再生が終わった後は、ムービープレーヤ300に対して次の動作を指定せずに、そのままにしておくべきではない。イベントハンドラonPlayListEnd内に次の動作を記述しておき、ムービープレーヤ300の状態をストップ状態に遷移させるか、メソッドplay()で次のプレイリストの再生を指示するか、メニュー画面に戻るようにオーサリングすべきである。
8−4.ムービープレーヤの再生復帰機能について
次に、ムービープレーヤ300の状態遷移と再生復帰機能について説明する。先ず、図38を用いて、UMDビデオプレーヤが備える3種類のメモリ領域について説明する。UMDビデオプレーヤのモデルでは、必須の3種類のメモリ領域である、プレーヤステータス領域401、リジュームインフォメーション領域402およびユーザデータ領域403が定義される。なお、これら3種類のメモリ領域401、402および403は、例えばメモリ113上に形成される。CPU112のワークメモリとしてのRAM上に形成してもよい。
プレーヤステータス領域401は、ムービープレーヤ300の再生状態を表す情報を保持するメモリ領域である。すなわち、プレーヤステータス領域401には、図3におけるプレーヤステータス323Bが保持される。プレーヤステータス領域401の内容は、スクリプトプログラム400から、メソッドgetPlayerStatus()で読み出すことができる。
リジュームインフォメーション領域402は、プレーヤステータス領域401に保持される情報の一部を一時的に退避(バックアップ)させるためのメモリ領域である。すなわち、プレーヤステータス領域401の一部の情報は、図3におけるリジュームインフォメーション324として、リジュームインフォメーション領域402に保持される。リジュームインフォメーション領域402に退避されれたプレーヤステータス領域401の一部の情報は、必要に応じてプレーヤステータス領域401に復帰される(リストア)。これらバックアップおよびリストアは、ネイティブ実装プラットフォーム301により行われる。リジュームインフォメーション領域402に保持された情報は、以前の再生停止箇所から再生を開始する、リジューム(resume)再生機能で使用される。
リジュームインフォメーション領域402の内容は、スクリプトプログラム400からメソッドgetResumeInfo()で読み出すことができる。リジュームインフォメーション領域402に保持されるリジュームインフォメーション324のうち、ストリームに関係するパラメータは、スクリプトプログラム400からメソッドchangeResumeInfo()で値を変更することが可能である。
リジュームインフォメーション領域402に保持された情報は、ネイティブ実装プラットフォーム301により必要に応じて不揮発性メモリ410に書き込まれる(save)。同様に、リジュームインフォメーション領域402から不揮発性メモリ410に書き込まれた情報は、ネイティブ実装プラットフォーム301により必要に応じて不揮発性メモリ410から読み出されて(load)、リジュームインフォメーション領域402に記憶される。
なお、プレーヤステータス領域401からリジュームインフォメーション領域402へのバックアップと、リジュームインフォメーション領域402からプレーヤステータス領域401へのリストアは、メソッド実行によってムービープレーヤ300が特定の状態遷移を行うことに伴って発生する処理であり、ムービープレーヤ300が自動的に行う。
ユーザデータ領域403は、コンテンツ依存の情報を保持する領域であって、コンテンツ制作者が任意に使用できる。ムービープレーヤ300によるプレイリストの再生経路の履歴、クイズの正解/不正解など、コンテンツによって使い方は任意である。
ユーザデータ領域403に対するデータの書き込みは、スクリプトプログラム400からメソッドsetUserData()により行うことができる。ユーザデータ領域403の内容は、スクリプトプログラム400からメソッドgetUserData()で読み出すことができる。ユーザデータ領域403に保持された情報は、ネイティブ実装プラットフォーム301により必要に応じて不揮発性メモリ410に書き込まれる(save)。同様に、ユーザデータ領域403から不揮発性メモリ410に書き込まれた情報は、ネイティブ実装プラットフォーム301により必要に応じて不揮発性メモリ410から読み出されて(load)、ユーザデータ領域403に記憶される。
再生復帰機能を実現するために、この発明の実施の一形態において構築したUMDビデオプレーヤのモデルについて説明する。
先ず、リジューム動作について、概略的に説明する。リジュームインフォメーション領域402にバックアップされた情報を用いて再生状態を復帰させる動作を、リジューム(resume)と呼ぶ。リジュームは、メソッドresume()によって行われる。
より具体的には、プレーヤステータス領域401内のプレーヤステータス323Bをリジュームインフォメーション領域402にバックアップしてリジュームインフォメーション324とし、メソッドresume()に応じて、リジュームインフォメーション領域402にバックアップされたリジュームインフォメーション324を用いて、再生状態を復帰させる。プレーヤステータス323Bは、ムービープレーヤ300の状態、すなわちムービープレーヤ300が現在再生しているプレイリストの番号、チャプタ番号、選択されたストリーム番号などからなる。
ムービープレーヤ300に対し、メソッドresume()を発行した時のムービープレーヤ300の動作は、リジュームインフォメーション領域402内にリジュームインフォメーション324が存在するか否かにより異なる。リジュームインフォメーション領域402内にリジュームインフォメーション324が存在するときは、当該リジュームインフォメーション324が、プレーヤステータス領域401にプレーヤステータス323Bとしてリストアされる。このとき、リジュームインフォメーション領域402内のリジュームインフォメーション324は、破棄される。
コンテンツ再生中に呼び出したメニューにおいて再生ストリームを変更する場合は、メソッドchangeResumeInfo()を用いる。メソッドchangeResumeInfo()でリジュームインフォメーション領域402に保持されているリジュームインフォメーション324を所定に変更した後に、メソッドresume()でリジュームを行えば、再生ストリームを変更して再生を始めることができる。
メソッドresume()を実行することで、ムービープレーヤ300にリジュームを行わせることができるが、メソッドgetResumeInfo()でリジュームインフォメーション324を取得した上で、引数を指定したメソッドplay()を実行することによっても、リジュームを実現することが可能である。
プレーヤステータス323Bのリジュームインフォメーション領域402へのバックアップについて、図39および図40を用いて説明する。図39は、ムービープレーヤ300に定義される4状態間の状態遷移のうち、プレーヤステータス領域401に保持されているプレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされる状態遷移を示す。図40は、プレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされるときの条件を示す。
プレイリストを再生している、ノーマルモードでプレイ状態(状態{Normal,play})のムービープレーヤ300がストップ状態に遷移すると、プレーヤステータス領域401に保持されているプレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされ、リジュームインフォメーション324として保持される。なお、ストップ状態では、プレーヤステータス323Bの一部の値は、不定になる。
また、ムービープレーヤ300が状態{Normal,play}から状態{Menu,play}に遷移するときにも、プレーヤステータス領域401に保持されているプレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされる。
一方、メニューモードでプレイリストを再生しているムービープレーヤ300が状態遷移をしても、プレーヤステータス領域401に保持されているプレーヤステータス323Bは、リジュームインフォメーション領域401にバックアップされない。
すなわち、プレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされリジュームインフォメーション324とされるのは、次の場合である。
(1)ムービープレーヤ300の現在の状態が状態{Normal,Play}であり、メソッドplay()の実行により状態{Menu,Play}に直接的に状態遷移する場合。
(2)ムービープレーヤ300の状態が状態{Normal,Play}であり、メソッドstop()の実行により、状態{Normal,Stop}あるいは状態{Menu,Stop}に状態遷移する場合。このとき、メソッドstop()の引数resumeInfoClearFlagは、値「false」である。
プレーヤステータス323Bのリジュームインフォメーション領域402への保存(バックアップ)は、本編中の戻り位置を保存しておくために使用されることを想定している。例えば、本編再生中に動画メニューに飛び、再び本編に戻って再生といった一連の動作を実現する際に、リジュームインフォメーション領域402にプレーヤステータス323Bがバックアップされたデータであるリジュームインフォメーション324が用いられることが想定される。
このため本編再生中、すなわちムービープレーヤ300が状態{Normal, Play}の状態では、リジュームインフォメーション領域402内のリジュームインフォメーション324は、破棄されている。ムービープレーヤ300が状態{Normal, Play}の状態からその他の状態に遷移したときに、プレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされ、リジュームインフォメーション324とされる。
このように、リジューム再生を実現するため、ムービープレーヤ300の状態遷移に応じて、プレーヤステータス323Bのリジュームインフォメーション領域402へのバックアップと、リジュームインフォメーション領域402内のリジュームインフォメーション324の破棄が適宜、行われる。また、スクリプトレイヤ302でメソッドresume()が指示されたときに、リジュームインフォメーション領域402内にリジュームインフォメーション324が存在すれば、リジュームインフォメーション324は、プレーヤステータス領域401にリストアされ、プレーヤステータス323Bとされる。
スクリプトレイヤ302から、メソッドgetResumeInfo()を用いて、リジュームインフォメーション領域402内のリジュームインフォメーション324を読み出すことができる。リジュームインフォメーション領域402内のリジュームインフォメーション324における、ストリームに関係するパラメータは、メソッドchangeResumeInfo()によって変更することができる。さらに、メソッドstop()の引数で指定することにより、リジュームインフォメーション領域402内のリジュームインフォメーション324を破棄することができる。
リジュームインフォメーション領域402に保持されたリジュームインフォメーション324のプレーヤステータス領域401へのリストアと、破棄について、図41〜図44を用いて説明する。本編中の戻り位置として保存したリジュームインフォメーション324は、ムービープレーヤ300が本編再生状態、すなわち状態{Normal,Play}の状態に戻った後に破棄される。このとき、リジュームインフォメーション324は、プレーヤステータス領域401にプレーヤステータス323Bとしてリストアされた後に破棄される場合と、リストアされずに破棄される場合の2つの場合がある。
すなわち、このモデルでは、ムービープレーヤ300が状態{Normal,Play}の状態に戻ると、リジュームインフォメーション領域402内のリジュームインフォメーション324が破棄され、その際に、ムービープレーヤ300などが所定の条件を満たしている場合は、リジュームインフォメーション領域402内のリジュームインフォメーション324がプレーヤステータス領域401にリストアされた後に破棄されるという特徴を有する。リジュームインフォメーション324がプレーヤステータス領域401にリストアされる場合には、リジュームインフォメーション324で指定された箇所からの再生開始となり、これがリジューム再生に相当する。
図41は、ムービープレーヤ300に定義される4状態間の状態遷移のうち、リジュームインフォメーション324がプレーヤステータス領域401にリストアされ、その後に破棄される状態遷移を示す。
以下の(1)〜(3)に記す3条件が揃った場合に、リジュームインフォメーション324がリストアされた後に破棄される。
(1)ムービープレーヤ300の現在の状態が状態{Menu,Stop}、状態{Normal,Stop}または状態{Menu,Play}である。
(2)リジュームインフォメーション324がリジュームインフォメーション領域402内に存在する。
(3)メソッドresume()の実行により状態{Normal,Play}に遷移する。
図42は、これらの条件をまとめて示す。なお、ムービープレーヤ300の状態が状態{Normal,Play}の場合は、リジュームインフォメーション324が存在しないため、図42中では定義されていない。
なお、リジュームインフォメーション領域402内にリジュームインフォメーション324が存在するときにメソッドresume()が実行されると、ムービープレーヤ300の状態は、状態{Normal,Play}に遷移する。また、リジュームインフォメーション領域402内にリジュームインフォメーション324が存在しない場合のメソッドresume()は、ムービープレーヤ300の状態を変更しない。このとき、メソッドresume()実行直前の状態{Mode,State}が維持され、プレーヤステータス323Bも変更されない。
一方、以下の(4)〜(6)に記す3条件が揃った場合に、リジュームインフォメーション324がリストアされずに破棄される。
(4)ムービープレーヤ300の現在の状態が、状態{Menu,Stop}、状態{Normal,Stop}または状態{Menu,Play}である
(5)リジュームインフォメーション324がリジュームインフォメーション領域402内に存在する。
(6)Play()メソッドの実行により、状態{Normal,Play}に遷移する。
図43は、これらの条件をまとめて示す。なお、ムービープレーヤ300の状態が状態{Normal,Play}の場合は、リジュームインフォメーション324がリジュームインフォメーション領域402内に存在しないため、図43中では定義されていない。
なお、リジュームインフォメーション324が存在しないときに、メソッドplay()の実行によりムービープレーヤ300の状態が状態{Normal,Play}に遷移した場合、結果として、リジュームインフォメーション324が存在しない状況が保持される。
リジュームインフォメーション領域402内のリジュームインフォメーション324の破棄は、メソッドstop()の引数の設定によっても発生させることができる。具体的には、この発明の実施の一形態では、メソッドstop()の引数として、リジュームインフォメーション領域402内のリジュームインフォメーション324の破棄を行うか否かを指定する引数resumeInfoClearFlagを定義した。図44に示されるように、メソッドstop()の実行時に、引数resumeInfoClearFlagに対して値「True」が指定されたときに、リジュームインフォメーション324の破棄が行われる。
例えば、映画本編を最後まで再生してムービープレーヤ300を停止させた場合は、映画本編の最後の位置がリジュームインフォメーション324として記録されてしまう。その後にユーザが再生(続き再生)をすると、映画本編の最後にジャンプして一時停止した状態になってしまい、使い勝手が悪くなる。
これを改善するには、モデルの定義上、自動的に記録されてしまうリジュームインフォメーション324を破棄する手段が必要になる。映画本編の最後がどこであるかは、コンテンツ制作者しか分からないため、スクリプトプログラム400からムービープレーヤ300に対するメソッドstop()の引数resumeInfoClearFlagによって、リジュームインフォメーション324の破棄を指定することができるようにした。
図45は、メソッドstop()の引数resumeInfoClearFlagを用いたUMDビデオプレーヤの一例の動作を示す。図45において、ステップS50〜ステップS54がスクリプトレイヤ302側の処理を示し、ステップS60〜ステップS64がムービープレーヤ300側の処理を示す。
再生がプレイリストの最後に到達すると(ステップS60)、ムービープレーヤ300は、イベントplayListEndをスクリプトレイヤ302に通知する(ステップS61)。ムービープレーヤ300は、ステップS60で最後まで再生されたプレイリストの最後のピクチャを表示し続けたまま、一時停止に状態遷移する(ステップS62)。
スクリプトレイヤ302は、イベントplayListEndを受けて、イベントハンドラonPlayListEndが実行される(ステップS50)。次のステップS51では、イベントplayListEndが通知されたプレイリストがオーサシナリオの最後であるか否かが判断される。あるプレイリストがシナリオの最後のプレイリストであるか否かは、例えばスクリプトプログラム400に基づき判断することができる。
若し、最後ではないと判断されれば、処理はステップS53に移行し、メソッドstop()の引数resumeInfoClearFlagを値「false」とし、リジュームインフォメーション324を破棄しないメソッドstop()をムービープレーヤ300に対して発行する。ムービープレーヤ300は、このメソッドstop()を受けて、状態がストップ状態に遷移されると共に、プレーヤステータス323Bがリジュームインフォメーション領域402にバックアップされる(ステップS64)。
一方、スクリプトレイヤ302において、ステップS51でシナリオの最後であると判断されれば、処理はステップS52に移行し、メソッドstop()の引数resumeInfoClearFlagを値「True」とし、リジュームインフォメーション324を破棄するメソッドstop()をムービープレーヤ300に対して通知する。ムービープレーヤ300は、このメソッドstop()を受けて、状態がストップ状態に遷移されると共に、リジュームインフォメーション領域402内のリジュームインフォメーション324が破棄(クリア)される(ステップS63)。
なお、スクリプトレイヤ302において、ステップS52の後、スクリプトプログラム400の記述によっては、メソッドend()が実行される(ステップS54)。
8−5.各データのライフサイクルについて
次に、プレーヤステータス323B、リジュームインフォメーション324およびユーザデータのライフサイクルについて説明する。
図46は、プレーヤステータス323Bの一例のライフサイクルを示す。ムービープレーヤ300の生成時に、プレーヤステータス323Bも生成される。ムービープレーヤ300が消滅すると、プレーヤステータス323Bも消滅する。プレーヤステータス323Bは、生成時に初期化される。生成時は、ムービープレーヤ300の状態を表すプロパティは、停止状態を表し、それ以外のプロパティは、不定となる。プレーヤステータス323Bの値は、ムービープレーヤ300における再生状態の変化に伴い変化する。また、プレーヤステータス323Bの値は、リジュームインフォメーション領域402の内容がリストアされたときに、変化する。また、プレーヤステータス323Bは、スクリプトレイヤ302からのメソッドgetPlayerStatus()により読み出すことができる。
なお、プレーヤステータス323Bをどのような形で記憶するかは、ムービープレーヤ300の実装に依存する。スクリプトからメソッドgetPlayerStatus()によって情報を得ることができるようになってさえいれば、どのような形で情報を保持していてもよい。
図47は、リジュームインフォメーション324の一例のライフサイクルを示す。ムービープレーヤ300生成時にリジュームインフォメーションのメモリ領域402が確保され、リジュームインフォメーション324の生成と共に初期化が行われる。初期化されると、リジュームインフォメーション324の内容は、破棄される。不揮発性メモリを実装しているUMDビデオプレーヤは、ムービープレーヤ300を初期化する際に、リジュームインフォメーション324を不揮発性メモリからロード(load)する。このとき、ユーザデータのロードも同時に行われる。
ムービープレーヤ300の状態が状態{Normal,Play}からその他の状態に遷移したとき、プレーヤステータス323Bは、リジュームインフォメーション領域402にバックアップされる。
リジュームインフォメーション324におけるストリームに関係するパラメータvideoNumber、audioNumber、audioFlag、subtitleNumberおよびsubtitleFlagは、スクリプトレイヤ302からのメソッドchangeResumeInfo()によって変更することができる。
ムービープレーヤ300において、ノーマルモードでのプレイリスト再生が開始されたとき、リジュームインフォメーション324の内容は、破棄される。このとき、破棄に先立ってリジュームインフォメーション324のプレーヤステータス323Bへのリストアが行われる場合と行われない場合とがある。また、引数resumeInfoClearFlagの値が「True」とされたstop()メソッドが実行されたときに、リジュームインフォメーション324の内容は破棄される。
リジュームインフォメーション324が存在するときに、メソッドresume()が実行されると、リジュームインフォメーション324のプレーヤステータス323Bへのリストアが行われる。
スクリプトレイヤ302から、メソッドgetResumeInfo()により、リジュームインフォメーション324の値を読み出すことができる。破棄された状態のリジュームインフォメーション324を読み出すと、返値playStatusとして値「0」が戻るため、リジュームインフォメーション324の有無を区別することが出来る。
ムービープレーヤ300が終了(消滅)するときに、リジュームインフォメーション324も消滅する。不揮発性メモリを実装しているUMDビデオプレーヤは、ムービープレーヤ300が終了(消滅)する際に、リジュームインフォメーション324を不揮発性メモリにセーブする。そのとき、ユーザデータのセーブも同時に行われる。
図48は、ユーザデータの一例のライフサイクルを示す。ムービープレーヤ300の生成時にメモリ領域が確保され、ユーザデータが生成される。生成と同時に初期化が行われる。初期化されると、ユーザデータの内容はクリアされる(メソッドgetUserData()で、長さ「0」の配列が返る)。不揮発メモリを実装しているUMDビデオプレーヤは、ムービープレーヤ300の初期化の際に、ユーザデータを不揮発性メモリからロードする。このとき、リジュームインフォメーションのロードも同時に行われる。
メソッドsetUserData()が実行されたときに、ユーザデータ領域403にユーザデータが書き込まれる。メソッドsetUserData()により、最大でデータ長が64ビットのInt型の配列がユーザデータ領域402に保持される。ユーザデータ領域403のデータは、スクリプトレイヤ302からのメソッドgetUserData()で読み出すことができる。ユーザデータがセットされていないときは、長さが0の配列が返る。
スクリプトレイヤ302からユーザデータ領域403の内容をクリアするメソッドは、無い。ユーザデータ領域403に対する上書きにより、内容を書き換えることができる。
ムービープレーヤ300が終了(消滅)するときに、ユーザデータ領域403も消滅する。不揮発性メモリを実装しているUMDビデオプレーヤは、ムービープレーヤ300が終了(消滅)する際に、ユーザデータ領域403の保持されているデータを不揮発性メモリにセーブする。このとき、リジュームインフォメーション324のセーブも同時に行われる。
9.リソースファイルの切り換えについて
次に、この発明の実施の一形態による、リソースファイルの切り換えについて説明する。この発明では、スクリプトプログラムやメニュー画面を構成する画像データなどの、コンテンツの再生制御に関するデータをまとめて格納したリソースファイルを、ディスク上に複数用意し、ディスクの再生開始時に複数のリソースファイルの中から適切なファイルを自動的に選択するようにしたと共に、ディスクの再生中に、ストリームの読み込みが中断されるタイミングで、使用するリソースファイルを適切に切り換えることができるようにしている。
これにより、ディスクに記録されたコンテンツ全体で、ディスク再生装置100が有するメモリ113の容量を超えてリソースファイルを使用することができ、インタラクティイブ機能を有するコンテンツをより高い自由度で制作することができるようになる。
なお、リソースファイルを、例えば日本語、英語などの表示言語別、表示画面のアスペクト比(4:3または16:9)別に用意することで、再生環境により使用しないデータの読み込みを抑えることができる。
リソースファイルは、図49に一例が示されるように、ルートディレクトリの下のディレクトリ"VIDEO"のさらに下のディレクトリ"RESOURCE"下に置かれる。リソースファイルには、既に説明したように、再生制御のためのスクリプトプログラムと、スクリプトプログラムで使用されるデータとがまとめて格納される。スクリプトプログラムで使用されるデータは、例えばボタン画像データやテクスチャ情報、GUI(Graphical User Interface)のレイアウト情報、サウンドデータである。
なお、この実施の一形態によるリソースファイルは、スクリプトプログラムが格納されるスクリプトファイルや、スクリプトプログラムで使用されるデータが格納される各種ファイルが包含されてなるファイルである。すなわち、リソースファイルは、内部に複数のファイルをさらに格納するような構造となっている。
なお、上述のように、リソースファイルをストリームファイルとは独立したファイルとしてディスクに格納することで、リソースファイルの作成がエレメンタリストリームの作成(エンコード)および多重化と独立され、ビデオの制作とメニューの制作とを同時に並行して実施できる。
さらに、メニューなどを表示させるプログラムが独立したファイルとしてディスクに格納され、ストリーム中に分散されて多重化されないため、プログラムのデバッグが容易である。
さらにまた、メニューなどを表示させるプログラムが独立したファイルとしてディスクに格納され、ストリーム中に分散されて多重化されないため、ビデオ再生とプログラム実行とを独立できる。これにより、例えば背景のビデオ再生を継続したまま、メニュー画面をビデオの再生を中断せずに背景ビデオ画像の上に重ねて表示させるような処理も可能となる。
また、メニューなどを表示させるプログラムがストリームに対して独立しているため、プログラムの再利用が容易になる。例えば、他のストリームに対して既存のプログラムを適用する場合でも、ストリーム番号の指定や時刻を指定するリンク情報を書き換えるだけで済む。
1つのディレクトリに複数のファイルが置かれる場合、複数のファイルのファイル名が互いに重複しないようにする必要がある。また、複数のリソースファイルが存在する場合、ディスクの再生開始時に、どのリソースファイルを初期状態で最初に読み込むべきかをディスク再生装置100が認識できるようにする必要がある。
この発明では、リソースファイルのファイル名の命名規則を所定に定めることで、これらを解決している。この発明の実施の一形態では、リソースファイルのファイル名を、図50に一例が示されるように、「CCdannnn.RCO」の形式としている。このリソースファイル名の各部分の意味について説明する。
リソースファイルのファイル名は、全体で12文字からなり、デリミタ(ピリオド)以降の文字列は、拡張子であり、この拡張子の文字列が「RCO」で、このファイルがリソースファイルであることを示す。
フィル名の先頭の2文字「CC」は、このリソースファイルの言語属性を示す。国際標準規格ISO(International Organization for Standarization)−639−1で定められた2文字で表される言語コードを大文字に変換して用いる。例えば、日本語は「JA」、英語は「EN」となる。
3文字目の「d」は、このリソースファイルがデフォルト言語に指定されたリソースファイルであるか否かを示す。なお、デフォルト言語は、当該リソースファイルに対応するコンテンツを再生する上で標準的に選択される言語をいう。「d」が「1」であれば、このリソースファイルがデフォルト言語に指定されたリソースファイルであることを示し、「d」が「0」であれば、デフォルト言語に指定されていないリソースファイルであることを示す。
4文字目の「a」は、リソースファイルが想定する表示デバイスのアスペクト比を示す。「a」が「0」であれば、想定されるアスペクト比が16:9であることを示し、「a」が「1」であれば、想定されるアスペクト比が4:3であることを示す。
5文字目〜8文字目の「nnnn」は、識別番号であり、「n」は、0〜9までの数字である。ファイル名の先頭の2文字「CC」と4文字目の「a」とが同一のリソースファイルが複数、存在する場合に、この識別番号をそれぞれ異ならせることで、これら複数のリソースファイルのファイル名が互いに重複しないようにできる。ファイル名の先頭の2文字「CC」と4文字目の「a」とが同一のリソースファイルが複数、存在する場合、識別番号は、それら複数のファイル間で互いに異なっていればよく、連続番号である必要はない。また、ファイル名の先頭の2文字「CC」と4文字目の「a」とが同一のリソースファイルが複数、存在する場合、そのうちの1ファイルは、識別番号が「0000」である必要がある。
なお、ディレクトリ"RESOURCE"内には、デフォルト言語に指定されたリソースファイルが1乃至2個、存在する。異なるアスペクト比(16:9および4:3)のリソースファイルがそれぞれ用意されている場合には、デフォルト言語に指定されたリソースファイルが2個存在する。デフォルト言語に指定されたリソースファイルが2個、存在する場合には、これら2個のリソースファイルの言語属性は、同一とされる。「d」を「1」に設定できるのは、識別番号が「0000」であるファイルに限るものとする。また、ある言語「CC」に対して「d」を「1」に設定した場合、「d」が「0」で識別番号が「0000」であるファイルが同時に存在してはならないものとする。
なお、リソースファイルの命名規則は、上述に限定されない。すなわち、そのリソースファイルの言語属性を示す情報と、そのリソースファイルがデフォルト言語に指定されたリソースファイルであるか否かを示す情報と、そのリソースファイルにおいて想定される表示デバイスのアスペクト比を示す情報とが含まれ、複数のリソースファイルが同一ディレクトリに存在する場合に互いを区別することができるようにされていれば、他の命名規則に基づきリソースファイルのファイル名を設定してもよい。例えば、ファイル名の長さは、デリミタを含めて12文字に限られないし、拡張子もリソースファイルであることがシステムで識別できれば、「RCO」に限られない。
以上のようにリソースファイルのファイル名の命名規則を定めることにより、以下に説明するリソースファイルの初期選択を実現することが可能となる。再生機すなわちUMDビデオプレーヤにおける、リソースファイルの初期選択の方法について説明する。上述したように、リソースファイルは、ディスク上に必ず1以上が存在する。UMDビデオプレーヤは、「コンテンツ先頭からの再生開始」の指示を受けると、ディスク上に複数が存在し得るリソースファイルの中から最適な1ファイルを選択して実行する。
ディスクのディレクトリ"RESOURCE"下には、言語別に用意されたリソースファイルが複数、存在する可能性がある。さらに、その中に、上述したリソースファイルの命名規則により、デフォルト言語に指定されたリソースファイルが少なくとも1ファイル、最大で2ファイル、存在する。2ファイル存在する場合は、表示アスペクト毎にデフォルト言語のリソースファイルが用意されている。
図51は、リソースファイルの初期選択を行う一例の処理を示すフローチャートである。このフローチャートの処理は、例えば、ビデオコンテンツ再生部210により行われる。ディスク再生装置100にディスク101が装填され、コンテンツ先頭からの再生開始指示が与えられると、ステップS70で、ディスクのディレクトリが検索され、ディレクトリ"RESOURCE"下に置かれたファイルのうち、拡張子が「RCO」であって、ファイル名の識別番号が「0000」であるリソースファイルが選別される。すなわち、リソースファイルの初期選択処理で対象とされるファイルは、ファイル名の識別番号が「0000」であるファイルに限定される。
例えば、ファイル名のピリオドの位置が検索され、ピリオドの後ろ3文字が取得され、取得された3文字からなる文字列が「RCO」であるファイルが選択される。さらに、ピリオドの前4文字が取得され、取得された4文字からなる文字列が「0000」であるファイルが選択される。
次に、ステップS71で、ファイル名の上述した「CC」の部分に示される言語属性が取得される。例えば、ファイル名のピリオドの位置から8文字前および7文字前の文字が取得される。この2文字からなる文字列が当該リソースファイルの言語属性を示す。この言語属性に基づき、プレーヤの設定言語と言語属性が一致するリソースファイルが存在するか否かが判断される。若し、一致するリソースファイルが存在すると判断されれば、処理はステップS72に移行され、プレーヤの設定言語と言語属性が一致するリソースファイルが選択される。ファイルが選択されると、処理はステップS74に移行される。
一方、ステップS71で、プレーヤの設定言語と言語属性が一致するファイルがないと判断されれば、処理はステップS73に移行される。ステップS73では、デフォルト言語に設定されたリソースファイルが選択される。すなわち、ファイル名の上述した「d」の部分に示される文字が取得される。例えばピリオドから6文字前の文字が取得される。そして、取得された文字が「1」であるファイルが選択される。ファイルが選択されると、処理はステップS74に移行される。
ステップS74では、上述のステップS72またはステップS73で選択されたファイルが2個あるか否かが判断される。選択されたファイルが1個であると判断されれば、当該ファイルが初期選択されたリソースファイルとして読み込まれる。
一方、ステップS74で、ステップS72またはステップS73で2個のファイルが選択されたと判断されたら、処理はステップS75に移行される。ステップS75では、ファイル名の「a」の部分に示される文字が取得される。例えばピリオドから5文字前の文字が取得される。そして、取得された文字が示すアスペクト比がプレーヤにおける表示デバイスのアスペクト比設定と一致するリソースファイルが選択される。
なお、上述では、リソースファイルのファイル名から所定の文字または文字列を取得するために、先ずファイル名に含まれるピリオドの位置を検索し、このピリオドの位置に基づき他の文字または文字列の位置を特定するように説明しているが、これは、ファイル名中の所定の文字または文字列を取得する処理を実現可能な一例の方法であって、この方法に限定されるものではない。例えば、ファイル名の先頭から文字列を検索してもよいし、末尾側から検索することも考えられる。
ディスク上には、プレーヤの設定言語と言語属性が一致するリソースファイルが1乃至2個、存在するはずである。上述の図51のフローチャートによる処理を実行することで、適切なリソースファイルを必ず、選択することができる。
一方、若し、上述のフローチャートによる処理を実行しても選択できるリソースファイルが存在しない場合は、ディスクがフォーマット違反か、若しくはディスクエラーになっている場合であると考えられる。このような場合のエラーへの対応は、プレーヤの実装に依存する。例えば、読み込み可能なリソースファイルを1個選択して、再生する方法が考えられる。また、当該ディスクが再生不可のディスクであると判断して、再生を開始しないことも考えられる。
上述のようにして初期選択されたリソースファイルがビデオコンテンツ再生部210により読み込まれ、スクリプト制御モジュール211に渡され、リソースファイルに含まれるスクリプトプログラムに従い、コンテンツの再生が開始される。コンテンツの再生開始後は、スクリプトプログラムにより、次に読み込むリソースファイルが明示的に指定されるため、リソースファイルの選択ルールを決める必要があるのは、再生開始時のみである。
次に、リソースファイルが選択された後、リソースファイル中に含まれるスクリプトプログラムが実行されてイベントドリブンモデルが動作するまでの処理について説明する。図52は、リソースファイルに格納されているスクリプトファイルの一例の内容を示す。スクリプトファイルは、イベントハンドラ群とメイン処理部とからなる。イベントハンドラ群は、1または複数のイベントハンドラが並べられる。スクリプトファイルは、実行前に先頭から評価されていく。その評価の過程で、イベントハンドラの登録、参照の解決、変数の定義、オブジェクトの生成などが行われる。この実行前の一連の処理を、初回実行と呼ぶ。初回実行は、ネイティブ実装プラットフォーム301により行われる。
スクリプトファイルのメイン処理部は、初回実行時に1回だけ、評価される。このメイン処理部には、このスクリプトファイル全体で共通して用いる変数であるグローバル変数の定義を記述することができる(図52では、「var a,b;」として記述されている)。初回実行時は、イベントがキューイングされず、ユーザ操作を受け付けないという制約がある。そのため、メイン処理部にムービープレーヤ300やコントローラオブジェクト330のメソッド、画面を構成する部品(Widget)に関するメソッドを記述することは、禁止としている。
スクリプトの初回実行が終了すると、スクリプトプログラムがイベントを受け付け可能な状態となる。一方、ネイティブ実装プラットフォーム301は、イベントautoPlayまたはイベントcontinuePlayを発生させるまで、他のイベントの発生を抑止する。ネイティブ実装プラットフォーム301のコントローラオブジェクト330は、スクリプトの初回実行が終了すると、イベントautoPlayまたはイベントcontinuePlayのうち何れかのイベントを発生する。発生されたイベントは、スクリプトレイヤ302に渡される。
図53は、スクリプトの初回実行後、最初のイベントハンドラが選択および実行されるまでの一例の処理を示すフローチャートである。ディスク再生装置100にディスク101が装填され、ユーザ操作によりディスク101を最初から再生する(以下、「始めから再生」と呼ぶ)か、当該ディスク101において以前再生を中止した位置の続きから再生する(以下、「続き再生」と呼ぶ)かが選択される(ステップS80)。若し、「続き再生」が選択されたら、処理はステップS81に移行する。「始めから再生」が選択された場合は、処理はステップS86に移行する。
ステップS81では、当該ディスク101に対応するリジュームインフォメーション324が存在するか否かがネイティブ実装プラットフォーム301により判断される。若し、存在しないと判断された場合、「続き再生」ができないので、処理はステップS86に移行される。当該ディスク101に対応するリジュームインフォメーション324が存在すると判断された場合、処理はステップS82に移行される。
ステップS82では、コントローラオブジェクト330からスクリプトレイヤ302に対して、イベントcontinuePlayが通知される。この通知を受けて、ステップS83で、スクリプトレイヤ302において、スクリプトプログラムにこのイベントcontinuePlayに対応するイベントハンドラonContinuePlayが用意されているか否かが判断される。若し、対応するイベントハンドラonContinuePlayが用意されていると判断されれば、処理はステップS84に移行し、当該イベントハンドラonContinuePlayが実行される。
一方、ステップS83で、スクリプトプログラムに対応するイベントハンドラonContinuePlayが用意されていないと判断されれば、処理はステップS85に移行される。ステップS85では、デフォルトのイベントハンドラonContinuePlayが実行される。このデフォルトのイベントハンドラonContinuePlayは、例えばディスク再生装置100に予め組み込まれており、リジュームインフォメーション324を用いた復帰再生が行われる。すなわち、当該ディスク101に対応したリジュームインフォメーション324がプレーヤステータス323Bにリストアされ、ムービープレーヤ300は、このリストアによるプレーヤステータス323Bを用いてコンテンツの再生を行う。
上述したように、ステップS80で、ユーザ操作により「始めから再生」が選択された場合、ならびに、ステップS81でディスク101に対応したリジュームインフォメーション324が存在しないと判断された場合、処理はステップS86に移行する。ステップS86では、コントローラオブジェクト330によりイベントautoPlayが発生され、スクリプトレイヤ302に通知される。次のステップS87で、スクリプトプログラムにこのイベントautoPlayに対応するイベントハンドラonAutoPlayが用意されているか否かが判断される。若し、用意されていると判断されれば、処理はステップS88に移行し、スクリプトレイヤ302において、当該イベントハンドラonAutoPlayが実行される。
一方、ステップS87で、スクリプトプログラムに対応するイベントハンドラonAutoPlayが用意されていないと判断された場合、処理はステップS89に移行される。ステップS89では、何の処理も行われない。このように、何の処理も行われない状態を意図的に作ることもできる。なお、この場合、メニューキーを操作することで、対応するイベントが発生される。
イベントハンドラonAutoPlayをスクリプトプログラム中に用意するか否かは、コンテンツ制作者側が任意に決めることができる。一方、イベントハンドラonAutoPlayが用意されていない場合、例えばユーザがディスク101をディスク再生装置100に装填しても、自動再生が行われなくなる。ユーザの利便性の観点から、イベントハンドラonAutoPlayを用意することが極めて好ましい。
次に、コンテンツの再生中にリソースファイルを切り換える方法について説明する。プレーヤが内蔵するメモリ113などのメモリ容量の制限から、スクリプトプログラムや、メニュー画面などで使用する静止画像、サウンドデータなどのデータを持つリソースファイルは、データサイズに制限がある。リソースファイルを分割し、それらをコンテンツの再生中に切り換えられるようにすることで、より多くのスクリプトプログラムや静止画像データ、サウンドデータなどを扱えるようになる。
図54は、リソースファイルの切り換えを行う一例の処理を示すフローチャートである。リソースファイルの切り換えは、スクリプトレイヤ302からネイティブ実装プラットフォーム301に対するメソッドchangeResource()により実行される。メソッドchangeResource()は、ネイティブ実装プラットフォーム301におけるコントローラオブジェクト330のメソッドである。コンテンツ制作側では、スクリプトプログラム中のリソースファイルを切り換えたい位置に、メソッドchangeResource()を記述しておく。
ステップS100で、スクリプトプログラムからネイティブ実装プラットフォーム301に対してメソッドchangeResource()が発行される。ネイティブ実装プラットフォーム301は、このメソッドchangeResource()を受け取ると、ムービープレーヤ300のプレーヤステータス323Bを参照し、ムービープレーヤ300の動作モードがメニューモードであるか否かが判断される(ステップS101)。若し、メニューモードではないと判断されれば、処理はステップS111に移行され、ネイティブ実装プラットフォーム301のコントローラオブジェクト330が、メソッドchangeResource()の戻り値として値「false」をスクリプトプログラムに対して返し、リソースに切り換えに失敗したとされる(ステップS112)。ステップS112の後、再びステップS100に戻るようにしてもよい。
ステップS101で、ムービープレーヤ300の動作モードがメニューモードであると判断された場合、処理はステップS102に移行する。ステップS102では、ムービープレーヤ300の状態がストップ状態、あるいは、プレイ状態で一時停止状態であるか否かが判断される。すなわち、ステップS102では、ムービープレーヤ300において、コンテンツにおける時刻が進んでいるか否かが判断される。ムービープレーヤ300がストップ状態あるいはプレイ状態で一時停止状態であれば、ディスクからストリームを読み込む必要が無い。プレイ状態の一時停止状態は、例えばビデオ出力モジュール241がバッファに溜め込まれた1フレームのビデオデータが繰り返し読み出されることで実現される。
若し、ムービープレーヤ300の状態がストップ状態あるいはプレイ状態で一時停止状態ではない、すなわち、プレイ状態で再生されるコンテンツの時間軸が進んでいる状態であれば、処理はステップS111に移行され、コントローラオブジェクト330により戻り値として値「false」が返され、ステップS112でリソースファイルの切り換えに失敗したとされる。
一方、ステップS102で、ムービープレーヤ300の状態がストップ状態あるいはプレイ状態で一時停止状態であると判断されれば、処理はステップS103に移行され、ネイティブ実装プラットフォーム301のコントローラオブジェクト330が、メソッドchangeResource()の戻り値として値「true」をスクリプトプログラムに対して返し、次のステップS104で、ネイティブ実装プラットフォーム301により、新たなイベントの発生が抑制される。すなわち、ステップS104では、ネイティブ実装プラットフォーム301からスクリプトレイヤ302に対するイベント314の発行が抑止される。また、次のステップS105で、ネイティブ実装プラットフォーム301において、キューに溜まった全てのイベント314が破棄される。
次のステップS106では、現在表示されている画面(ページ)が消去される。これは、例えばビデオ出力モジュール241がビデオ出力のためにバッファに溜め込んでいるデータのうち、切り換え前のリソースファイルにより表示された画面(ページ)のデータが、バッファ内から消去される。この処理により、切り換え前のリソースファイルにより表示された画像データが消去される。なお、ここでは、ビデオ画像の上に重ねて表示される、リソースデータによって作られたグラフィクス画像が消去されるだけである。ムービープレーヤ300がプレイ状態の一時停止の場合には、背景に一時停止中のビデオ画像が表示されているが、このビデオ静止画像の表示は継続される。
なお、このステップS106の処理は省略することができる。すなわち、リソースファイルが切り替わっている最中や、切り替わった直後でも、バッファ内に画像データが存在すれば、ビデオ出力モジュール241がその画像データを繰り返し読み出すことで、画面(ページ)の表示を継続することができる。
ステップ107では、ネイティブ実装プラットフォーム301により、現在使用中のリソースファイルが破棄され、ディスクから新たなリソースファイルが読み込まれる。読み込むリソースファイルは、切り替わる前の元のリソースファイル内のスクリプトプログラムに記述されている。新たなリソースファイルが読み込まれると、次のステップS108で、ネイティブ実装プラットフォーム301により、読み込まれたリソースファイルの初回実行が行われる。そして、ネイティブ実装プラットフォーム301から新たなスクリプトファイルによるスクリプトレイヤ302に対して、イベントresourceChangedが発行され(ステップS109)、このイベントresourceChangedに応じて、スクリプトレイヤ302においてイベントハンドラonResourceChangedが実行される(ステップS110)。この時点で、新たなイベントの発行が許可される。
イベントドリブンモデルにおいては、新たなイベントを抑止するタイミングや、実行待ちのイベントハンドラの扱いが重要である。したがって、適切な処理を行わないと、意図しないイベントが発生したり、実行待ちであったイベントハンドラが実行されてしまい、所望の動作を達成できない可能性がある。
この発明の実施の一形態では、上述したフローチャートにおけるステップS101により、ユーザ入力310に応じたネイティブ実装プラットフォーム301からの制御コマンド311を受けるか否かを判断し、ステップS102により、ディスクからのストリームの読み込みがなされているか否かを判断している。すなわち、この発明の実施の一形態では、コンテンツ再生中にストリーム切り換えを行う際に不可避なこれらの処理を実行するため、安全にリソースファイルの切り換えを実現することができる。
なお、実際には、上述のステップS101およびステップS102の処理に先立って、メソッドchangeResource()の発生前に、明示的に、ムービープレーヤ300の動作モードをメニューモードとし、状態をストップ状態とするのが望ましい。
リソースファイルの切り換えを実現するためには、リソースファイルの切り換え後の動作を確実に行えるようにする必要がある。そのため、リソースファイルの切り換え前に存在し、プレーヤのメモリに格納された情報の中でも、リソースファイル切り換え後まで維持しておく必要のある情報と、リソースファイル切り換え時には破棄する必要のある情報とがある。
プレーヤステータス323B、リジュームインフォメーション324およびユーザデータ(ユーザデータ領域403に保持されているデータ)は、リソースファイルの切り換え後まで維持する必要があるデータである。
一方、スクリプトレイヤ302で保持するグローバル変数や、イベントハンドラプロパティに代入された値は、リソースファイル切り換え後まで維持されない。
リソースファイル切り換え直前までに、メニューなどとして表示されているページ(画面)やボタン画像などは、消去される。これらの画像データなどがビデオ出力モジュール241のバッファに残っていて、表示が継続される場合でも、メニュー表示ページ(画面)を構成するためのデータは、リソースファイルが記憶されるメモリから消去される。同様に、リソースファイルが切り換えられる直前までに、実行待ちキューに入っているイベントハンドラは、全て破棄する。したがって、リソースファイルの切り替わり後には、イベントハンドラは、キューに溜まっていないことになる。
このように、この発明の実施の一形態では、リソースファイル切り換え後に維持される情報と維持されない情報とをそれぞれ規定し、リソースファイル切り換えの直前までにはイベントハンドラを破棄するという制約を設けている。これより、リソースファイルの切り換えが実現できるようになる。
なお、上述では、この発明がオーディオストリームおよびビデオストリームを共に処理するようなディスク再生装置100に適用されるように説明したが、これはこの例に限定されない。例えば、オーディオストリームのみ、ビデオストリームのみを再生する場合にも、この発明を適用することができる。
また、上述では、コンテンツデータが記録される記録媒体として、ディスク上記録媒体を用いるように説明したが、これはこの例に限定されない。例えば、コンテンツデータが記録される記録媒体として、半導体メモリを用いることができる。
さらに、上述では、この発明が適用されるディスク再生装置100が専用的なハードウェアで構成されるように説明したが、これはこの例に限定されない。すなわち、ディスク再生装置100のディスクドライブ以外の構成は、コンピュータ装置上で動作するソフトウェアによっても実現することができる。この場合、ディスク再生装置100を実現するソフトウェアは、CD−ROM(Compact Disc-Read Only Memory)やDVD−ROM(Digital Versatile Disc-ROM)といった記録媒体に記録されて供給することができる。ディスク再生装置100を実現するためのソフトウェアが記録された記録媒体を、コンピュータ装置のディスクドライブに装填し、記録媒体に記録された当該ソフトウェアをコンピュータ装置にインストールする。コンピュータ装置に対して、UMDに対応したディスクドライブ装置を接続することで、この発明によるディスク再生装置100と同等の構成が実現できる。UMDビデオのコンテンツを記録した記録媒体に、当該ソフトウェアを共に記録して提供することも考えられる。