大容量の再生専用光ディスクで、より自由度の高いインタラクティブ機能を容易に実現可能とする。プレーヤの機能に対応する仮想プレーヤモデルを構築し、Ｊａｖａにより記述する。ＢＤＢａｓｉｃＰｌａｙｅｒ２１０は、ユーザ入力やプレーヤの状態遷移を検出してイベントを発生させる。リスナインターフェイスを実装したオブジェクト２１１は、受信したいイベントに対応するイベントリスナ登録を、当該イベントが発生する前にＢＤＢａｓｉｃＰｌａｙｅｒ２１０に対して行い、不要になったら削除する。ＢＤＢａｓｉｃＰｌａｙｅｒ２１０は、イベントが発生されると対応するイベントリスナ登録がなされたオブジェクト２１１に対してイベントを送信する。オブジェクト２１１は、受信したイベントに応じたメソッドを実行する。イベントとメソッドの関係を柔軟に設定でき、複雑なインタラクティブ機能も容易に実現可能である。

【発明の詳細な説明】
【技術分野】
この発明は、ブルーレイディスク（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）などの大容量の記録媒体に記録されたプログラムに対するユーザによるインタラクティブな操作を可能とする再生装置、再生方法、再生プログラムおよび記録媒体に関する。
【背景技術】
近年、記録可能で記録再生装置から取り外し可能なディスク型記録媒体の規格として、Ｂｌｕ−ｒａｙ Ｄｉｓｃ（ブルーレイディスク）規格が提案されている。Ｂｌｕ−ｒａｙ Ｄｉｓｃ規格では、記録媒体として直径１２ｃｍ、カバー層０．１ｍｍのディスクを用い、光学系として波長４０５ｎｍの青紫色レーザ、開口数０．８５の対物レンズを用いて、最大で２７ＧＢ（ギガバイト）の記録容量を実現している。これにより、日本のＢＳディジタルハイビジョン放送を、画質を劣化させることなく２時間以上記録することが可能である。
この記録可能光ディスクに記録するＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）信号のソース（供給源）としては、従来からの、例えばアナログテレビジョン放送によるアナログ信号によるものと、例えばＢＳディジタル放送をはじめとするディジタルテレビジョン放送によるディジタル信号によるものとが想定されている。Ｂｌｕ−ｒａｙ Ｄｉｓｃ規格では、これらの放送によるＡＶ信号を記録する方法を定めた規格は、既に作られている。
一方で、現状のＢｌｕ−ｒａｙ Ｄｉｓｃの派生規格として、映画や音楽などが予め記録された、再生専用の記録媒体を開発する動きが進んでいる。映画や音楽を記録するためのディスク状記録媒体としては、既にＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）が広く普及しているが、このＢｌｕ−ｒａｙ Ｄｉｓｃの企画に基づいた再生専用光ディスクは、Ｂｌｕ−ｒａｙ Ｄｉｓｃの大容量および高速な転送速度などを活かし、ハイビジョン映像を高画質なままで２時間以上収録できる点が、既存のＤＶＤとは大きく異なり、優位である。
再生専用のＤＶＤビデオ規格においては、メニュー画面上に配置されたボタン画像などを用いて、インタラクティブな機能を実現している。例えば、ＤＶＤビデオにより動画を再生中に、リモートコントロールコマンダなどを用いてメニュー画面を呼び出し、メニュー画面上に配置されたボタン画像を選択して再生場面を変更するなどの処理が可能であった。
ＤＶＤビデオの場合、メニュー画面を固定的なサブピクチャデータにより構成し、メニュー画面が呼び出された際に、動画データにこのサブピクチャデータを合成して表示する。ボタン画像データもこのサブピクチャデータに含まれる。特許文献「特開平１０−３０８９２４号公報」に、このように動画データにサブピクチャデータを合成して記録可能なＤＶＤに記録する構成が記載されている。
しかしながら、再生専用のＤＶＤビデオ規格では、単純なコマンドにより動作が記述されているため、複雑なインタラクティブ機能を実現することが難しいという問題点があった。そのため、複雑なインタラクティブ機能を再生専用のＤＶＤビデオ規格で実現することは、制作者にとって大きな負担になるという問題点があった。
また、再生専用のＤＶＤ規格では、プログラムの動作としては、コマンドが羅列されたコマンド領域を一行ずつ実行していく単純なもので、マルチスレッドプログラミングやイベント駆動のプログラミングを行うことができなかった。ＤＶＤビデオ規格は、インターネットなどのネットワークにアクセスする機能を有していないが、ネットワークアクセス機能を実現することを考えた場合、ネットワークからの応答やユーザからの応答は待ち時間が長く、マルチスレッドで処理を行えるシステム構成であることが、パフォーマンスの向上に非常に有効である。
さらに、このＤＶＤビデオ規格では、映像および音声が多重化されているＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリーム中にもコマンドが埋め込まれている。ＡＶストリームの再生を進めていくに従ってコマンドを取得し、実行するという、いわば芋づるを辿るような動作モデルとなっている。そのため、タイトル選択のメニュー画面や分岐のあるマルチストーリーにおいて、ユーザがボタンを選択実行したときに、始めて次の動作が決まる。したがって、ＤＶＤビデオ規格では、コマンドを先読みして分岐予測や投機実行を行うといった高速処理技術が適用できないという問題点があった。
また、ディスクを制作するオーサリングの観点からも、再生専用のＤＶＤビデオ規格は、問題があった。一例として、ＡＶストリーム上のある時刻に表示されるように想定されたボタン表示に対して、ボタン表示のタイミングを時間軸上で前あるいは後ろにずらしたい場合を考える。例えば、第１図に示されるように、ＡＶストリーム上のボタン表示開時刻ｔ１からボタン表示終了時刻ｔ２まで表示されるように想定されたボタンを、時刻ｔ１より前の時刻ｔ３から表示させるように変更する。
周知のように、再生専用のＤＶＤビデオ規格では、ＡＶストリームは、ＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２）の規定に従い符号化され、パケッタイズされる。再生出力の時刻管理は、ｐｔｓ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）により行われる。第１図の例では、ボタンの表示開始時刻を、時刻ｔ１に対応するｐｔｓ１から時刻ｔ３に対応するｐｔｓ３に変更することになる。
ＤＶＤビデオ規格では、ナビゲーション情報、ビデオデータ、オーディオデータおよびサブピクチャデータがそれぞれパックとして、１本のＡＶストリームに多重化され、ＡＶストリーム中にコマンドなどが埋め込まれた構造となっている。ビデオデータ、オーディオデータおよびサブピクチャデータは、その多重化された時刻に表示されることを想定している。例えば、第２図Ａに示されるように、ｐｔｓ単位で管理される時間軸上の所定時刻に所定のデータが再生されるように、多重化がなされる。
このように多重化がなされているため、時刻ｐｔｓ１に表示されるように想定されたボタンＡを、時刻ｐｔｓ３に表示されるように変更するには、第２図ＡのＡＶストリームを、第２図Ｂに示されるように、ボタン１を表示するサブピクチャデータが時刻ｐｔｓ３の位置にくるように再多重化する必要がある。ボタンが選択されたときに実行するコマンドの内容を変更したい場合にも、同様にして、ＡＶストリームの再多重化を行わなくてはならなかった。再多重化は、例えば、ＤＶＤを再生するプレーヤ内で、再生したＡＶストリームを一旦メモリに格納して行う。
このように、従来では、より自由度の高いインタラクティブ機能を実現するのが困難であり、それを実現しようとすると、制作者側にもより大きい負担が掛かってしまうという問題点があった。
【発明の開示】
したがって、この発明の目的は、大容量の再生専用光ディスクにおいて、より自由度の高いインタラクティブ機能を容易に実現可能な再生装置、再生方法、再生プログラムおよび記録媒体を提供することにある。
この発明は、上述した課題を解決するために、円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生装置において、所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトと、プレーヤオブジェクトの上位にあって、イベントの発生に対応した処理を記述可能なプログラムオブジェクトとを有し、プレーヤオブジェクトは、プログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生装置である。
また、この発明は、円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法において、所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、プレーヤオブジェクトの上位にあって、イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生方法である。
また、この発明は、円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法をコンピュータ装置に実行させる再生プログラムにおいて、再生方法は、所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、プレーヤオブジェクトの上位にあって、イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生プログラムである。
また、この発明は、円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法をコンピュータ装置に実行させる再生プログラムが記録されたコンピュータ装置に読み取り可能な記録媒体において、再生方法は、所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、プレーヤオブジェクトの上位にあって、イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした記録媒体である。
また、この発明は、コンテンツデータが階層構造で記録された円盤状の形状を有する記録媒体において、少なくともコンテンツデータと、イベントの発生に対応した処理を記述可能なプログラムオブジェクトとが記録され、コンテンツデータの再生処理が、所定の変化に応じてイベントを発生させるように構成された、プログラムオブジェクトの下位にあるプレーヤオブジェクトによって、プログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき制御されるようにした記録媒体である。
上述したように、請求の範囲１、請求の範囲１３、請求の範囲１４および請求の範囲１５に記載の発明は、所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、プレーヤオブジェクトの上位にあって、イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにしているため、一つのプレーヤオブジェクトで円盤状記録媒体毎に独自の処理の再生制御を行うことができる。
また、請求の範囲１６に記載の発明は、少なくともコンテンツデータと、イベントの発生に対応した処理を記述可能なプログラムオブジェクトとが記録され、コンテンツデータの再生処理が、所定の変化に応じてイベントを発生させるように構成された、プログラムオブジェクトの下位にあるプレーヤオブジェクトによって、プログラムオブジェクトに記述されたイベントの発生に対応した処理に基づき制御されるようにしているため、一つのプレーヤオブジェクトに対し、記録媒体毎に独自の再生制御を行わせるようにできる。
この発明では、ＢＤ−ＲＯＭプレーヤのＡＶストリーム再生機能を抽象化した仮想プレーヤを構築し、仮想プレーヤに対してイベントモデルを適用して発生するイベントを定めた。また、ユーザ入力により発生するユーザイベントを定義した。そのため、一つのイベントモデルでＤＶＤビデオの持つ機能を実現できるという効果がある。
また、この発明では、ＢＤ−ＲＯＭプレーヤのＡＶストリーム再生機能を抽象化した仮想プレーヤを構築し、仮想プレーヤに対応するＪａｖａクラスを定義している。そして、仮想プレーヤに対してイベントモデルを適用して発生するイベントを定めると共に、ユーザ入力により発生するユーザイベントを定義した。そのため、再生専用ビデオディスクにおける再生制御の方法として、Ｊａｖａのイベントモデルを適用でき、Ｊａｖａプログラムからプレイリストの再生制御が可能となるという効果がある。
そのため、複雑なインタラクティブ機能を組み込む場合でも、ディスク制作者側の負担が軽くて済むという効果がある。
また、この発明は、Ｊａｖａ言語に限らず、ＥＣＭＡスクリプトのようなスクリプト言語にも適用でき、イベントに対応するイベントハンドラの内容をコンテンツ制作者側がスクリプト言語を用いて記述して、イベント発生時にコンテンツ制作者側が意図する動作を容易に実現させることができる効果がある。
【図面の簡単な説明】
第１図は、従来技術によりボタンの表示開始時刻を変更することを説明するための図、第２図Ａおよび第２図Ｂは、ストリームの再多重化を説明するための図、第３図Ａおよび第３図Ｂは、ＢＤ−ＲＯＭ規格のＨＤムービーモードにおける一例のレイヤ構成を示す略線図、第４図は、ＢＤ−ＲＯＭのプレーヤモデルの一例のレイヤ構成を示す略線図、第５図は、ＢＤ基本プレーヤ３０について説明するための図、第６図は、プレイリストの再生中に発生するイベントの例を示す略線図、第７図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第８図Ａ、第８図Ｂおよび第８図Ｃは、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第９図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第１０図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第１１図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第１２図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第１３図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す略線図、第１４図Ａ、第１４図Ｂおよび第１４図Ｃは、Ｄ−ＲＯＭのオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒで生成される一例のイベント定義を一覧して示す略線図、第１５図は、リスナおよびイベントについて説明するための図、第１６図Ａおよび第１６図Ｂは、イベントリスナ登録に関する一例のメソッドを一覧して示す略線図、第１７図は、イベントリスナ登録を用いたプログラム作成の一例の手順を示すフローチャート、第１８図は、イベントリスナ登録を用いたプログラムを再生側が実装する際の一例の処理を示すフローチャート、第１９図Ａ、第１９図Ｂおよび第１９図Ｃは、クリップＡＶストリームファイル、マークデータが格納されるファイルおよびボタンを構成するデータが格納されるファイルを概念的に示す略線図、第２０図は、イベントドリブンモデルによるＢＤ−ＲＯＭ仮想プレーヤモデルについて説明するための図、第２１図Ａ、第２１図Ｂ、第２１図Ｃおよび第２１図Ｄは、ＢＤ−ＲＯＭ仮想プレーヤモデルが受け付けるユーザ入力コマンドの定義の一例を一覧して示す略線図、第２２図は、リモートコントロールコマンダからのキー入力イベントを表すクラスＲｍｔＫｅｙＥｖｅｎｔの例を示す略線図、第２３図は、オブジェクトＲｍｔＫｅｙＥｖｅｎｔが有する一例のメソッドを一覧して示す略線図、第２４図は、メソッドｇｅｔＲｍｔＫｅｙＣｏｄｅによって得られる一例のキーを一覧して示す略線図、第２５図Ａおよび第２５図Ｂは、メソッドｇｅｔＲｍｔＫｅｙＣｏｄｅによって得られる一例のキーを一覧して示す略線図、第２６図は、ユーザ入力イベントをきっかけとして、用意されたプログラムが実行される一例の手順を示すフローチャート、第２７図は、ＢＤ−ＲＯＭのフルプロファイルに適用可能な一例のファイルの管理構造を示す略線図、第２８図Ａ、第２８図Ｂおよび第２８図Ｃは、この発明の実施の第１の形態に適用可能なプレーヤデコーダ１００の一例の構成を示す機能ブロック図、第２９図は、ＵＭＤビデオ規格のレイヤ構成を示す略線図、第３０図は、この実施の第２の形態による一例のプレーヤモデルを模式的に示す図、第３１図は、ムービープレーヤの一例の内部構成を示す略線図、第３２図は、ムービープレーヤの３状態を示す略線図、第３３図は、この発明の実施の第２の形態によるムービープレーヤのイベントモデルを模式的に示す図、第３４図Ａおよび第３４図Ｂは、ムービープレーヤオブジェクトの一例のイベントハンドラを示す略線図である。
【符号の説明】
３０ ＢＤ基本プレーヤ
３１ Ｊａｖａプログラム
３２ ＡＰＩ
３４ 共通パラメータ
３５ プレーヤコマンド
１０４ コードバッファ
１０６ マルチメディアエンジン
２００ ＢＤプレゼンテーションエンジン
２０１ ナビゲーションエンジン
２０２ ＪａｖａＶＭ
２０３ Ｊａｖａアプリケーション
２１０ オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ
２１１ リスナインターフェイス
３００ ムービープレーヤ
３０１ ネイティブ実装プラットフォーム
３０２ スクリプトレイヤ
３１０ ユーザ入力
３１１ 制御コマンド
３１２，３１４ イベント
３１３，３１５ メソッド
３２０ データベース
３２１ プレイバックモジュール
３２２ デコーダエンジン
３２３ プロパティ
Ｓ２０ プレイリスト上のどのシーンでボタンを表示させるか決める
Ｓ２１ その時刻にマークを設定する
Ｓ２２ ボタンオブジェクトにマークに対応するイベントリスナを登録するメソッドをプログラム中に記述する
Ｓ２３ マーク発生イベントに対応するリスナインターフェイスを実装する（イベント発生時に実行させる処理を記述）
Ｓ３０ プレイリスト再生スタート
Ｓ３１ ＢＤＢａｓｉｃＰｌａｙｅｒがプレイリスト再生中にマークがつけられた時刻を通過したことを検出
Ｓ３２ マークイベントに対応するイベントリスナが登録されている
Ｓ３３ イベントリスナを登録したオブジェクトにマークイベント送信
Ｓ３４ イベントの通知を受けたオブジェクトは、マークイベント発生時に実行するメソッドを実行
Ｓ３５ ボタンを表示
Ｓ３６ マーク検出のイベントを通知しない
Ｓ４１ 再生中にユーザが’ネクスト’キーを押した
Ｓ４２ ＲｍｔＫｅｙＥｖｅｎｔが発生
Ｓ４３ 次のチャプタマークの位置をデータベースから知る
Ｓ４４ チャプタマークが有るか？
Ｓ４５ 現在の再生を中止する
Ｓ４６ ＰｌａｙＳｔｏｐｐｅｄＥｖｅｎｔ発生
Ｓ４７ 次のチャプタマークの位置のバイト位置にアクセスしてビデオ再生を開始する
Ｓ４８ ＰｌａｙＳｔａｒｔｅｄＥｖｅｎｔ，ＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔ発生
Ｓ４９ ＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔに対応したリスナを実行開始
Ｓ５０ Ｍａｒｋの種類を知る
Ｓ５１ チャプタマークで有るか？
Ｓ５２ チャプタ先頭であることを示すメッセージを表示
Ｓ５３ リスナ実行終了
【発明を実施するための最良の形態】
以下、この発明について、下記の構成に従い説明する。
１．発明の実施の第１の形態
１−１．ＢＤ−ＲＯＭのＡＶストリーム再生機能について
１−１ａ．ＢＤ−ＲＯＭのＨＤムービーモードについて
１−１ｂ．ＢＤ−ＲＯＭのフルプロファイルについて
１−２．ＪａｖａによるＢＤ仮想プレーヤモデル
１−３．ＢＤ基本プレーヤで生成されるイベントについて
１−３ａ．イベントの分類
１−３ｂ．イベントモデルについて
１−４．ユーザ入力について
１−５．ファイルの管理構造について
１−６．デコーダモデルについて
２．発明の実施の第２の形態
２−１．ＵＭＤビデオ規格について
２−２．ＵＭＤビデオ規格のプレーヤモデルについて
２−３．ムービープレーヤのイベンドモデルについて
２−４．ムービープレーヤオブジェクトおよびユーザ入力について
２−５．ムービープレーヤオブジェクトでのイベントの扱いについて
１．発明の実施の第１の形態
以下、この発明の実施の第１の形態について説明する。先ず、理解を容易とするために、現状のＢｌｕ−ｒａｙ Ｄｉｓｃの派生規格として提案されている、再生専用の記録媒体の規格について、概略的に説明する。以下では、記録可能なＢｌｕ−ｒａｙ Ｄｉｓｃと区別するために、Ｂｌｕ−ｒａｙ Ｄｉｓｃの派生規格の再生専用の記録媒体をＢＤ−ＲＯＭ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）と称し、ＢＤ−ＲＯＭ規格においてＤＶＤビデオと同等のインタラクティブ機能を用意するために、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）ムービーモードが用意されている。
１−１．ＢＤ−ＲＯＭのＡＶストリーム再生機能について
１−１ａ．ＢＤ−ＲＯＭのＨＤムービーモードについて
第３図Ａおよび第３図Ｂは、ＢＤ−ＲＯＭ規格のＨＤムービーモードにおける一例のレイヤ構成を示す。ＢＤ−ＲＯＭ規格のＨＤムービーモードは、下層側から、クリップレイヤ（Ｃｌｉｐ Ｌａｙｅｒ）、プレイリストレイヤ（ＰｌａｙＬｉｓｔ Ｌａｙｅｒ）、ムービーオブジェクトレイヤ（Ｍｏｖｉｅ Ｏｂｊｅｃｔ Ｌａｙｅｒ）およびインデックステーブルレイヤ（Ｉｎｄｅｘ Ｔａｂｌｅ Ｌａｙｅｒ）からなる。
クリップレイヤは、１または複数のクリップからなる。クリップ（Ｃｌｉｐ）は、クリップＡＶストリーム（Ｃｌｉｐ ＡＶ Ｓｔｒｅｅｍ）およびクリップインフォメーション（Ｃｌｉｐ Ｉｎｆｏｒｍａｔｉｏｎ）からなる。ＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリームの実体は、クリップＡＶストリームファイルであり、ＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２）トランスポートストリームにタイムスタンプを付加した形式で記録される。クリップＡＶストリームファイルには、ボタン画像を表示するためのボタンオブジェクトを多重化することができる。
クリップＡＶストリームファイルの記録時に、クリップＡＶストリームファイルに１対１に対応してクリップインフォメーションファイルが同時に作成される。クリップＡＶストリームファイルおよびクリップインフォメーションファイルの一組を、クリップと称する。
クリップは、記録の単位ともいうべきものであり、再生時にどのような順序でクリップを再生するかは、クリップの上位のレイヤで管理する。プレイリストレイヤは、クリップの再生経路を指定するレイヤであり、１または複数のプレイリストを含む。ＢＤ−ＲＯＭ規格のＨＤムービーモードにおいては、プレイリストは、ムービープレイリスト（Ｍｏｖｉｅ ＰｌａｙＬｉｓｔ）と称される１種類が存在する。ムービープレイリストは、プレイアイテム（ＰｌａｙＩｔｅｍ）の集合からなる。プレイアイテムには、クリップの再生範囲を示した一組のＩＮ点およびＯＵＴ点が含まれており、プレイアイテムを連ねることによって、任意の順序でクリップを再生することができるようになる。プレイアイテムは、クリップを重複して指定することができる。クリップＡＶストリームファイルのＩＮ点およびＯＵＴ点は、バイトポジションで指定される。
ムービーオブジェクトは、プレイリストレイヤの上位にあり、１または複数のムービーオブジェクトからなる。ムービーオブジェクトは、プレイリストの再生指示や、プレーヤ設定を行うコマンド列から構成される。ムービーオブジェクトが有するコマンドにより、複数の言語用に用意されたストリームのうちどれを選択するか、或いは、選択されるプレイリストがある条件に従って変化するような、条件分岐を伴うプレイリスト再生を実現することができる。条件分岐を伴うプレイリスト再生を行うアプリケーション例としては、マルチストーリーが挙げられる。ムービーオブジェクトによって、双方向性（インタラクティブ性）が導入されることになる。
インデックステーブルを含むインデックステーブルレイヤは、プレイリストレイヤの上位にある。インデックステーブルは、ディスク挿入時に最初に実行されるムービーオブジェクト、メニューキーが押されたときに実行されるムービーオブジェクトおよびユーザに見せるタイトルの一覧表から構成される。インデックステーブルにより、ユーザインターフェイスが提供される。タイトルは、１または複数のムービーオブジェクトで構成される。インデックステーブルには、各タイトルで最初に実行されるムービーオブジェクトが羅列されている。プレーヤは、このインデックステーブルを基に、各種動作時に最初に実行するムービーオブジェクトを決めている。
ＢＤ−ＲＯＭのＨＤムービーモードにおけるディスク上には、以上説明したようなデータベースが構成される。プレーヤは、ディスク上からこうしたデータベースを読み取り、指定された動作を行う。
次に、プレーヤ側のモデルを説明する。現実のプレーヤ実装においては、さまざまな形態が考えられるが、ここでは、プレーヤモデルを、ハードウェアに近いストリームを再生する機能ブロックと、その上位にありソフトウェアでコマンドを解釈し実行する機能ブロックという、２つの機能ブロックに分ける。第４図は、ＢＤ−ＲＯＭのプレーヤモデルの一例のレイヤ構成を示す。第４図の左側が、ＨＤムービーモードにおける２つの機能ブロックに分けられたレイヤ構成を示している。
ＢＤプレゼンテーションエンジン（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ）２００は、プレイリストやクリップを扱い、ＡＶストリームのデコードを行い、動画や音声を再生する機能ブロックである。字幕ストリームや、ボタン画像やメニューを表示するためのグラフィックスストリームのデコードも、ＢＤプレゼンテーションエンジン２００で行う。
ＢＤプレゼンテーションエンジン２００は、上位レイヤの指示に従って指定のプレイリストを再生する。
ＢＤ−ＲＯＭのＨＤムービーモードでは、ＢＤプレゼンテーションエンジン２００の上に、ナビゲーションエンジン（Ｎａｖｉｇａｔｉｏｎ Ｅｎｇｉｎｅ）２０１が存在する。ナビゲーションエンジン２０１は、インデックステーブルやムービーオブジェクトを解釈し、最終的に再生するプレイリストをＢＤプレゼンテーションエンジン２００に指示する。
１−１ｂ．ＢＤ−ＲＯＭのフルプロファイルについて
次に、ＢＤ−ＲＯＭ規格のフルプロファイルについて説明する。ＢＤ−ＲＯＭ規格のフルプロファイルは、上述したＢＤ−ＲＯＭ規格のＨＤムービーモードに対してより高い自由度と拡張性を持たせた、ＢＤ−ＲＯＭ規格に提案されるモードである。以下、ＢＤ−ＲＯＭ規格のフルプロファイルモードを、フルプロファイルと略称する。
この発明の実施の第１の形態では、高い自由度と拡張性を実現するために、プレーヤモデルに対してＪａｖａ仮想マシン（ＪａｖａＶＭ：Ｊａｖａ Ｖｅｒｔｕａｌ Ｍａｃｈｉｎｅ）を搭載し、Ｊａｖａアプリケーションを実行することで、フルプロファイルを実現している。この点が上述したＢＤ−ＲＯＭのＨＤムービーモードとは大きく異なる点である。なお、Ｊａｖａ、ＪａｖａＶＭなどは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．による登録商標である。
フルプロファイルにおいても、プレーヤの機能は全て利用できることが必要である。これは、ＢＤプレゼンテーションエンジン２００とＪａｖａアプリケーションとの間にＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が定義されており、そのＡＰＩを介してＢＤプレゼンテーションエンジン２００を操作できることを意味する。これは、ＢＤ−ＲＯＭのＨＤムービーモードにおけるナビゲーションエンジン２０１のように、ＪａｖａアプリケーションがＢＤプレゼンテーションエンジン２００の上位に位置すると考えればよい。すなわち、第４図の右側に一例が示されるように、フルプロファイルにおいては、ＢＤプレゼンテーションエンジン２００の上位に、ＪａｖａＶＭ２０２を介してＪａｖａアプリケーション２０３が乗る構成となる。
なお、Ｊａｖａでは、他に、ネットワーク機能やグラフィクス機能を有する。そのため、Ｊａｖａアプリケーション２０３およびＪａｖａＶＭ２０２の下位レイヤとして、ネットワークレイヤ２０４およびＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）レイヤ２０５を有する。
Ｊａｖａアプリケーション２０３からＢＤプレゼンテーションエンジン２００を操作するということは、プレイリストを再生するプレーヤをソフトウェア上で仮想的に考え、そのプレーヤに対して再生、停止、ストリーム選択などの命令を発して、プレーヤ操作を行うと見なせばよい。プレーヤからＪａｖａアプリケーション２０３へは、どのプレイリストを再生しているかといった現在のプレーヤの状態や、ストリーム選択やユーザからの入力など、各種動作の変化の時刻を伝える必要がある。この発明の実施の第１の形態では、こうしたプレーヤの機能を、Ｊａｖａアプリケーション２０３上で抽象化したオブジェクトとして考える。このプレイや機能を抽象化したオブジェクトを、ＢＤ基本プレーヤと称する。
第５図を用いて、ＢＤ基本プレーヤについて説明する。ＢＤ基本プレーヤ３０は、この発明の実施の第１の形態により定義されるディスク状記録媒体を再生するもので、パソコンなどのコンピュータ環境上のオブジェクトである。コンピュータ環境は、汎用的なパーソナルコンピュータに限られず、例えば、この発明の実施の第１の形態により定義されるディスク状記録媒体を再生するように専用的に構成された再生装置および／または記録再生装置に組み込まれたソフトウェア環境も含む。なお、以下、この発明の実施の第１の形態により定義されるディスク状記録媒体を、ディスクと略称する。
ＢＤ基本プレーヤ３０は、ソフトウェア上の抽象化されたオブジェクトである。ＢＤ基本プレーヤ３０の下位に、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）およびハードウェア３３が存在する。ＢＤ基本プレーヤ３０の上位プログラムとして、ＡＰＩ３２を介してＪａｖａプログラム３１が存在する。
ＢＤ基本プレーヤ３０の状態は、概略的には、プレイリストやグラフィクスを再生する状態Ａと、再生が停止された状態Ｂの２つの状態に分類できる。状態Ａは、高速再生、逆転再生といった変速再生や、ディスク上の任意の時刻から再生する飛び込み再生といった特殊再生などの複数の動作を含む。さらに、ＢＤ基本プレーヤ３０は、内部にプレーヤ状態を保持する変数（共通パラメータ３４）を持つ。共通パラメータ３４は、実際には、コンピュータ環境上のレジスタなどからなる。上位レイヤのアプリケーション（Ｊａｖａプログラム３１）は、Ｊａｖａのメソッドを通じて共通パラメータ３４にアクセスすることで、ＢＤ基本プレーヤ３０の状態に応じた個別の処理を行うことができる。
ＢＤ基本プレーヤ３０は、ソフトウェア上の抽象化されたオブジェクトである。ＢＤ基本プレーヤ３０は、Ｊａｖａプログラム３１によるＡＰＩ３２を介しての制御を、最終的に、下位にあるＯＳおよびハードウェア３３への制御に変換していることになる。
ＢＤ基本プレーヤ３０は、ＡＰＩ３２によって上位のプログラム（Ｊａｖａプログラム３１）から制御されると共に、ＢＤ基本プレーヤ３０で発生する状態の変化を上位プログラムに伝える必要がある。なぜなら、今再生しているプレイリストを再生し終わったら別のプレイリストを再生させる、といった複数の動作を順序立ててＢＤ基本プレーヤ３０に行わせるには、ＢＤ基本プレーヤ３０の状態を上位プログラムが把握している必要があるからである。この発明の実施の第１の形態では、このプレーヤの状態を上位レイヤに伝える仕組みとして、イベントモデルを導入する。
第６図は、プレイリストの再生中に発生するイベントの例を示す。再生開始時には、先ず、イベントＰｌａｙＳｔａｒｔｅｄが発生する。それから、プレイリストの再生が開始されるときには、イベントＰｌａｙＬｉｓｔＳｔａｒｔｅｄが発生する。プレイリストの先頭は、プレイアイテムの先頭でもあるため、イベントＰｌａｙＬｉｓｔＳｔａｒｔｅｄの発生と同時にイベントＰｌａｙＩｔｅｍＳａｒｔｅｄも発生する。さらに、プレイリストの先頭にチャプタを示すチャプタマークが打たれている場合には、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄが発生する。
同様に、プレイアイテム中にマークが打たれているときは、当該プレイアイテムを再生中にこのマークが検出されることによりイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄが発生する。プレイアイテムの再生が終了されると、イベントＰｌａｙＩｔｅｍＥｎｄｅｄが発生し、そこでプレイリストも終了していれば、イベントＰｌａｙＬｉｓｔＥｎｄｅｄがさらに発生する。再生終了時には、イベントＰｌａｙＥｎｄｅｄが発生する。
このように、プレーヤの動作中には、様々なイベントが発生するものとし、イベント発生を上位プログラムに伝えることで、上位プログラムは、プレーヤの状態を把握できるようになる。上位プログラム側では、各イベント発生通知時に実行されるプログラムを用意しておくことで、各種イベント発生に対処する。
この発明の実施の第１の形態では、以上のように、プレーヤの抽象化の方法、Ｊａｖａプログラムからプレーヤを操作するメソッドモデルおよびプレーヤの状態をＪａｖａプログラムに伝えるためのイベントモデルを提供し、ＢＤ−ＲＯＭの制御プログラムにＪａｖａ言語を導入する。この実施の第１の形態が適用されたシステムでは、ディスク制作者は、ＡＰＩ３２を介してＢＤ基本プレーヤ３０を操作するＪａｖａプログラム３１を作成することになる。
次に、プレーヤ機能を詳細に分析して抽象化し、Ｊａｖａのクラスで表現した具体例を示す。
１−２．ＪａｖａによるＢＤ仮想プレーヤモデル
ＢＤ−ＲＯＭのフルプロファイルを定めるにあたり、Ｂｌｕ−ｒａｙ Ｄｉｓｃを実行する環境を定義する必要がある。ＢＤ−ＲＯＭを再生する理想的なＢＤ基本プレーヤ３０のモデルを、ＢＤ−ＲＯＭ仮想プレーヤモデルと名づける。ＢＤ基本プレーヤ３０は、ＢＤ−ＲＯＭ仮想プレーヤモデル中のプレイリストを再生する機能ブロックに相当する。ＢＤ−ＲＯＭ仮想プレーヤモデルでは、ＢＤ基本プレーヤ３０の取り得る状態や状態遷移の条件を定義すると共に、ＢＤ基本プレーヤ３０で再生できるストリームの属性、ストリームを制御するコマンドレス（スクリプト）の記述方法などを定義する。ＢＤ−ＲＯＭに格納されたスクリプトやストリームは、このＢＤ−ＲＯＭ仮想プレーヤモデル上で正しく動作するものでなければならない。
また、実際のＢＤ−ＲＯＭプレーヤには、様々な実装方法があるが、実装に依存しないモデルを想定することで、最小限必要なハードウェア資源を明確にすることが可能となる。
この発明の実施の第１の形態で定義されるＢＤ−ＲＯＭ仮想プレーヤモデルでは、ＢＤ基本プレーヤ３０を制御するプログラミング言語として、Ｊａｖａを用いる。Ｊａｖａは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．によって作られたプログラミング言語で、適用するシステムの規模により、Ｊ２ＥＥ、Ｊ２ＳＥ、Ｊ２ＭＥなどの複数のエディションを有する。ここでは、セットトップボックスなどでの組み込みでの使用を想定したエディションであるＪ２ＭＥを一例として使用することを想定している。すなわち、Ｊ２ＭＥをベースとして、ＢＤ−ＲＯＭ仮想プレーヤモデルに必要な拡張を加えるという考え方である。
Ｊａｖａ言語は、新たなクラスを定義することにより容易に拡張ができる特徴がある。例えば、単体ではイベント処理できないＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書でイベント処理を実現するためには、ＨＴＭＬ文書内にイベント処理が可能なスクリプト、例えばＥＣＭＡ（Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ）スクリプトを記述してイベントを処理する。
Ｊａｖａ言語を用いることで、このように、ある機能を実現するために複数の技術を使うのではなく、Ｊａｖａ言語で定められた拡張の方法に従って機能を追加できる。そのため、完成したプログラムも、Ｊａｖａ言語のみを用いて記述されたものとなる。また、Ｊａｖａは、既に数多くのプログラム開発環境が提供されており、制作者にとってディスクを作りやすい環境といえる。
ＢＤ−ＲＯＭ仮想プレーヤモデルをＪａｖａ言語で記述する場合、既にＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．によって規定されているＪａｖａのクラス、ＡＰＩは、そのまま用いることができる。一方、ＢＤ基本プレーヤ３０は、ＢＤ−ＲＯＭ独自の機能であり、既存のクラスやＡＰＩとしては用意されていない。このＢＤ−ＲＯＭ独自の機能をＪａｖａで実現するには、様々な方法が考えられるが、この発明の実施の第１の形態では、ＢＤ基本プレーヤ３０の機能とそれに関するＡＰＩ、イベントモデルなどをＢＤ−ＲＯＭに適した形で構築した。
先ず、ＢＤ基本プレーヤ３０をＪａｖａの一つのクラスとして定義する。そのクラスのクラス名を、ＢＤＢａｓｉｃＰｌａｙｅｒと定義する。第７図〜第１３図は、クラスＢＤＢａｓｉｃＰｌａｙｅｒのメソッドの例を一覧して示す。ＢＤ基本プレーヤ３０に対する命令は、全てこのメソッドを通して行う。
第７図は、プレーヤ設定情報取得に関する一例のメソッドを示す。メソッドｇｅｔＰｌａｙｅｒＳｐｅｅｄ（）で、プレーヤの再生速度を取得する。メソッドｇｅｔＰｌａｙｅｒＤｉｒｅｃｔｉｏｎ（）で、プレーヤの再生方向を取得する。メソッドｇｅｔＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ（）で、プレーヤの表示言語を取得する。メソッドｇｅｔＰｌａｙＬｉｓｔＮｕｍｂｅｒ（）で、現在再生中のプレイリスト番号を取得する。メソッドｇｅｔＣｈａｐｔｅｒＮｕｍｂｅｒ（）で、現在再生中のチャプター番号を取得する。メソッドｇｅｔＰｌａｙｅｒＳｕｐｐｏｒｔ（）で、プレーヤのバージョンおよび当該プレーヤが有する機能を取得する。
第８図Ａ、第８図Ｂおよび第８図Ｃは、プレイリストの再生に関する一例のメソッドを示す。メソッドｐｌａｙＰｌａｙＬｉｓｔ（ｉｎｔ ｐｌａｙＬｉｓｔＮｕｍｂｅｒ，ｌｏｎｇ［ｐｌａｙＬｉｓｔＴｉｍｅ］）で、”ｐｌａｙＬｉｓｔＮｕｍｂｅｒ”で指定されたプレイリストの再生を開始する。なお、”ｐｌａｙＬｉｓｔＴｉｍｅ”は、必須ではない。”ｐｌａｙＬｉｓｔＴｉｍｅ”によりプレイリスト内の経過時刻を指定し、そこからプレイリストを再生する。メソッドｐｌａｙＰｌａｙＬｉｓｔ（Ｓｔｒｉｎｇ ｐｌａｙＬｉｓｔＵＲＬ，ｌｏｎｇ［ＰｌａｙＬｉｓｔＴｉｍｅ］）で、”ｐｌａｙＬｉｓｔＵＲＬ”で指定されたプレイリストの再生を開始する。”ｐｌａｙＬｉｓｔＵＲＬ”は、プレイリストをＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）で指定する。例えばインターネット上にあるプレイリストをＵＲＬで指定することができる。一例として、プレーヤがインターネット接続機能を有していれば、この”ｐｌａｙＬｉｓｔＵＲＬ”で指定されたＵＲＬからプレイリストをダウンロードして再生するようにできる。”ｐｌａｙＬｉｓｔＴｉｍｅ”は、必須ではない。”ｐｌａｙＬｉｓｔＴｉｍｅ”によりプレイリスト内の経過時刻を指定し、そこからプレイリストを再生する。
メソッドｐｌａｙＰｌａｙＩｔｅｍ（ｉｎｔ ｐｌａｙＬｉｓｔＮｕｍｂｅｒ，ｉｎｔ ｐｌａｙＩｔｅｍＮｕｍｂｅｒ）で、”ｐｌａｙＬｉｓｔＮｕｍｂｅｒ”で指定されるプレイリストの、”ｐａｌｙＩｔｅｍＮｕｍｂｅｒ”で指定されるプレイアイテムから再生を開始する。”ｐｌａｙＩｔｅｍＮｕｍｂｅｒ”は、プレイアイテムを識別するための”ＰｌａｙＩｔｅｍ＿ｉｄ”であり、０から始まる数値である。プレイリストの先頭から再生するのであれば、”ｐｌａｙＩｔｅｍＮｕｍｂｅｒ”の値は０になる。メソッドｐｌａｙＰｌａｙＩｔｅｍ（Ｓｔｒｉｎｇ ｐｌａｙＬｉｓｔＵＲＬ，ｉｎｔ ｐｌａｙＩｔｅｍＮｕｍｂｅｒ）で、”ｐｌａｙＬｉｓｔＵＲＬ”で指定されるプレイリストの、”ｐｌａｙＩｔｅｍＮｕｍｂｅｒ”で指定されるプレイアイテムから再生を開始する。”ｐｌａｙＩｔｅｍＮｕｍｂｅｒ”は、”ＰｌａｙＩｔｅｍ＿ｉｄ”であり、０から始まる数値である。プレイリストの先頭から再生するのであれば、”ｐｌａｙＩｔｅｍＮｕｍｂｅｒ”の値は０になる。
メソッドｐｌａｙＣｈａｐｔｅｒＭａｒｋ（ｉｎｔ ｐｌａｙＬｉｓｔＮｕｍｂｅｒ，ｉｎｔ ｃｈａｐｔｅｒＮｕｍｂｅｒ）は、”ｐｌａｙＬｉｓｔＮｕｍｂｅｒ”で決まるプレイリスト中の、”ｃｈａｐｔｅｒＮｕｍｂｅｒ”で指定されるあるチャプタから再生する。”ｐｌａｙＬｉｓｔＮｕｍｂｅｒ”は、”ｐｌａｙＬｉｓｔＵＲＬ”であってもよい。プレイリストの先頭には、必ずＣｈａｐｔｅｒＭａｒｋ（チャプタマーク）が付けられている。
メソッドｍｏｖｅＡｎｄＰｌａｙ（ｓｔｒｉｎｇ ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ）ｐｏｓｉｔｉｏｎ＝（”ｐｒｅｖ”｜”ｎｅｘｔ”｜”ｔｏｐ”｜”ｔａｉｌ”）ｏｂｊｅｃｔ＝（”ＰｌａｙＩｔｅｍ”｜”Ｃｈａｐｔｅｒ”）で、プレイリスト内での移動が指示される。”ｎｅｘｔ”は、現在再生中の箇所から次のプレイアイテムまたはチャプタに飛び、再生を開始する。”ｔｏｐ”は、プレイリストの先頭に移動する。”ｔａｉｌ”は、プレイリストの最後に移動する。”ｐｒｅｖ”は、現在再生中のプレイリストの先頭から再生を開始する。メソッドｓｔｏｐ（）で、再生を停止する。このとき、標準レジスタの値は保持されない。メソッドｐｌａｙＳｏｕｎｄＥｆｆｅｃｔ（ｉｎｔ ｓｏｕｎｄ＿ｉｄ）で、”ｓｏｕｎｄ＿ｉｄ”で選択された効果音を再生する。
第９図は、ビデオストリームに関する一例のメソッドを示す。メソッドｇｅｔＶｉｄｅｏＳｔｒｅａｍＡｖａｉｌａｂｉｌｉｔｙ（）で、指定のビデオストリームが含まれているか否かを取得する。メソッドｓｅｔＶｉｄｅｏＳｔｒｅａｍＮｕｍｂｅｒ（）で、デコードするビデオストリームを指定する。メソッドｇｅｔＶｉｄｅｏＳｔｒｅａｍＮｕｍｂｅｒ（）で、選択中のビデオストリームの番号を取得する。メソッドｇｅｔＶｉｄｅｏＳｔｒｅａｍＡｔｔｒｉｂｕｔｅ（）で、ビデオストリームの属性を取得する。ビデオストリームの属性は、例えば、符号化方式、解像度、アスペクト比、アスペクト比が４：３のときのディスプレイモード、クローズドキャプションか否か、などである。メソッドｓｅｔＡｎｇｌｅＮｕｍｂｅｒ（）で、アングル番号を指定する。メソッドｇｅｔＡｎｇｌｅＮｕｍｂｅｒ（）で、選択中のアングル番号を取得する。メソッドｇｅｔＭａｘＶｉｄｅｏＳｔｒｅａｍｓ（）で、選択可能なビデオストリームの数を取得する。
第１０図は、オーディオストリーム関する一例のメソッドを示す。メソッドｇｅｔＡｕｄｉｏＳｔｒｅａｍＡｖａｉｌａｂｉｌｉｔｙ（）で、指定のオーディオストリームが含まれているか否かを取得する。メソッドｇｅｔＡｕｄｉｏＳｔｒｅａｍＬａｎｇｕａｇｅ（）で、指定のオーディオストリームの言語についての情報を取得する。メソッドｓｅｔＡｕｄｉｏＳｔｒｅａｍＮｕｍｂｅｒ（）で、再生するオーディオストリームを指定する。メソッドｇｅｔＡｕｄｉｏＳｔｒｅａｍＮｕｍｂｅｒ（）で、再生しているオーディオストリームの番号を取得する。メソッドｇｅｔＡｕｄｉｏＳｔｒｅａｍＡｔｔｒｉｂｕｔｅ（）で、オーディオストリームの属性を取得する。オーディオストリームの属性は、例えば、符号化方式、チャンネル数、量子化ビット数、サンプリング周波数などである。メソッドｇｅｔＭａｘＡｕｄｉｏＳｔｒｅａｍｓ（）で、選択可能なオーディオストリームの数を取得する。
第１１図は、サブピクチャストリーム関する一例のメソッドを示す。メソッドｇｅｔＳＰＳｔｒｅａｍＡｖａｉｌａｂｉｌｉｔｙ（）で、指定のサブピクチャストリームが含まれているか否かを取得する。メソッドｇｅｔＳＰＳｔｒｅａｍＬａｎｇｕａｇｅ（）で、指定のサブピクチャストリームの言語を取得する。メソッドｇｅｔＳＰＤｉｓｐｌａｙＳｔａｔｕｓ（）で、サブピクチャストリームの表示状態、すなわち、現在表示されているか、非表示であるかを取得する。メソッドｓｅｔＳＰＤｉｓｐｌａｙＳｔａｔｕｓ（）で、サブピクチャストリームの表示状態、すなわち、表示するか非表示とするかを設定する。メソッドｇｅｔＳＰＳｔｒｅａｍＡｔｔｒｉｂｕｔｅ（）で、サブピクチャストリームの属性を取得する。サブピクチャストリームの属性は、例えば、異なる解像度のサブピクチャストリー厶を持つ場合の解像度別情報、アスペクト比４：３またはワイド用などの情報である。
第１２図は、内蔵タイマに関する一例のメソッドを示す。メソッドｓｌｅｅｐ（）で、指定されたミリ秒間、処理を停止する。メソッドｓｅｔＴｉｍｅｏｕｔ（）で、指定されたミリ秒後に関数や処理を実行する。メソッドｓｅｔＩｎｔｅｒｖａｌ（）で、指定されたミリ秒ごとに処理を実行する。メソッドｃｌｅａｒＴｉｍｅｒ（）で、指定された登録タイマＩＤの処理を中止する。メソッドｐａｕｓｅＴｉｍｅｒ（）で、指定した登録タイマＩＤのタイマを一時停止する。メソッドｒｅｓｕｍｅＴｉｍｅｒ（）で、指定した登録タイマＩＤのタイマを一時停止から再開する。
第１３図は、キー入力に関する一例のメソッドを示す。メソッドｇｅｔＰｒｅｓｓｅｄＫｅｙ（）で、ユーザが押したキーの種類を取得する。
１−３．ＢＤ基本プレーヤで生成されるイベントについて
プレーヤ操作に関するメソッドを実行した際、プレーヤの動作が正常に開始されたかなど、直後に反応を知ることができるものは、メソッドに対する戻り値で知ることができる。しかし、時間のかかる処理を指示した場合、その処理が終了するまで待つような方法では、他の処理ができない。また、いつ発生するかわからない処理もある。このような場合はイベントの仕組みを導入することで効率の良い処理が可能となる。
プレーヤの動作中には、様々なイベントが発生する。どのようなイベントが発生するかは、ＢＤ−ＲＯＭ仮想プレーヤモデルで定義する。プレーヤの動作に変化が生じるとイベントが発生するものとし、そのイベント発生に対処するプログラムが用意されている場合に、そのプログラムが実行される、というモデルをＢＤ−ＲＯＭ仮想プレーヤモデルで定義する。
例えば、複数のプレイリストを指定の順序で再生していく場合、前のプレイリストの再生終了のイベントを受けて次のプレイリストの再生を開始する処理を行うプログラムを用意しておく。また、何らかの原因で次のプレイリストが再生されなかった場合には、例外が発生するものとして例外処理するプログラムを用意しておく。
プログラムとして記述されていない場合には、規格で規定されているプレーヤ組み込みの動作（デフォルトのイベントハンドラ）を実行するか、或いは何も実行されずそのイベントは無視されることになる。何も処理を行う必要がないときには、積極的にイベントを無視することになる。その際は、後述するイベントリスナ登録を行わないか、イベントに対応したプログラムを記述しないようにすることで、イベントを無視することができる。
このように、不定期なイベントが発生し、イベント発生をきっかけに用意しておいたプログラムが実行されるモデルを、イベントドリブンモデルという。
１−３ａ．イベントの分類
ＢＤ−ＲＯＭ仮想プレーヤモデルにおけるイベントは、（１）再生中のコンテンツから発せられるイベント、（２）ユーザからの割り込みによるイベント、（３）プレーヤ状態の変化によるイベント、の３種類に大別することができる。
（１）の、再生中のコンテンツから発せられるイベントは、例えばプレイリストを再生中に、マークで指し示された時刻に来ると発生するマーク検出の割り込みイベントである。このイベント発生を契機として、グラフィックスの表示や消去を行う。この種類のイベントは、予め設定された割り込みで、再生の度に同じタイミングで発生する点が特徴である。
（２）の、ユーザからの割り込みによるイベントは、主として、プレーヤを操作するリモートコントロールコマンダに対するキー入力を想定している。この種類のイベントは、ユーザが何時キー入力をするか分からないため、事前に割り込みのタイミングを知ることができない。
（３）の、プレーヤの状態の変化によるイベントは、プレーヤが停止状態から再生状態に変化したときや、再生中のストリームが変更されたときなど、プレーヤの状態遷移を表すイベントである。また、プログラム中でタイマーを設定した場合は、ある時刻になるとタイマー割り込みのイベントが発生する。プレーヤの状態変化は、上述した（１）再生中のコンテンツから発せられるイベントや、（２）ユーザからの割り込みによるイベントにより引き起こされるイベントでもあることも多い。
第１４図Ａ、第１４図Ｂおよび第１４図Ｃは、ＢＤ−ＲＯＭのオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒで生成される一例のイベント定義を一覧して示す。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、クラスＢＤＢａｓｉｃＰｌａｙｅｒにより生成されるオブジェクトである。
先ず、（１）の、再生中のコンテンツから発せられるイベントについて説明する。第１４図Ａ、第１４図Ｂおよび第１４図Ｃにおいて、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔは、再生中にマークを検出した際に発生される。このイベントは、例えばグラフィクス画面を表示する際に利用される。イベントＶａｌｉｄＰｅｒｉｏｄＳｔａｒｔｅｄＥｖｅｎｔは、ユーザ入力の選択有効期間が開始した際に発生される。イベントＶａｌｉｄＰｅｒｉｏｄＥｎｄｅｄＥｖｅｎｔは、ユーザ入力の有効期間が終了した際に発生される。このイベントは、例えばリンクの強制実行の時に利用される。イベントＰｌａｙＲｅｐｅａｔｅｄＥｖｅｎｔは、繰り返し再生区間の先頭を検出した際に発生される。イベントＶｉｄｅｏＳｔｒｅａｍＣｈａｎｇｅｄＥｖｅｎｔは、再生するビデオストリームが変わった際に発生される。イベントＡｕｄｉｏＳｔｒｅａｍＣｈａｎｇｅｄＥｖｅｎｔは、再生するオーディオストリームが変わった際に発生される。イベントＳｕｂｐｉｃｔｕｒｅＳｔｒｅａｍＣｈａｎｇｅｄＥｖｅｎｔは、再生するサブピクチャストリームが変わった際に発生される。イベントＳｔｒｅａｍＤｉｓｐｌａｙＳｔａｔｕｓＣｈａｎｇｅｄＥｖｅｎｔは、ストリームの表示／非表示状態が変わった際に発生される。イベントＰｌａｙＬｉｓｔＳｔａｒｔｅｄＥｖｅｎｔは、プレイリストの先頭を検出した際に発生される。イベントＰｌａｙＬｉｓｔＥｎｄｅｄＥｖｅｎｔは、プレイリストの終わりを検出した際に発生される。イベントＰｌａｙＩｔｅｍＳｔａｒｔｅｄＥｖｅｎｔは、プレイアイテムの先頭を検出した際に発生される。イベントＰｌａｙＩｔｅｍＥｎｄｅｄＥｖｅｎｔは、プレイアイテムの終わりを検出した際に発生される。
次に、（２）の、ユーザからの割り込みにより発生されるイベントについて説明する。イベントＲｍＫｅｙＥｖｅｎｔは、リモートコントロールコマンダのキーが押された際に発生される。どのキーが押されたかは、対応するイベントリスナ（後述する）内で判定する。
次に、（３）の、プレーヤの状態の変化により発生されるイベントについて説明する。イベントＰｌａｙＳｔａｒｔｅｄＥｖｅｎｔは、プレーヤが再生を開始した際に発生される。イベントＰｌａｙＳｔｏｐｐｅｄＥｖｅｎｔは、プレーヤが再生が停止した際に発生される。イベントＰｌａｙＳｔｉｌｌｅｄＥｖｅｎｔは、プレーヤが再生を一時停止した際に発生される。イベントＳｔｉｌｌＲｅｌｅａｓｅｄＥｖｅｎｔは、プレーヤにおいて再生の一時停止が解除された際に発生される。イベントＰｌａｙＰａｕｓｅｄＥｖｅｎｔは、プレーヤでの再生がユーザにより一時停止（ポーズ）された際に発生される。イベントＰａｕｓｅＲｅｌｅａｓｅｄＥｖｅｎｔは、ポーズが解除された際に発生される。イベントＴｉｍｅｒＦｉｒｅｄＥｖｅｎｔは、カウントダウンタイマが０になった際に発生される。または、カウントアップタイマが指定の値になった際に発生される。
１−３ｂ．イベントモデルについて
第１４図Ａ、第１４図Ｂおよび第１４図Ｃで説明した各イベントは、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ内で発生するものとする。つまり、Ｊａｖａ言語におけるイベントソースは、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒであると定める。イベントは、Ｊａｖａ言語の上では、イベントオブジェクトとして定義される。イベント発生時に実行するメソッドをリスナと呼ぶ。リスナが実行されるためには、イベントソースに対してイベントリスナ登録を行う必要がある。リスナがイベントソースに登録されていれば、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、イベントをイベントリスナに送信する。イベントを受信したオブジェクトは、オブジェクト内に用意したメソッドを実行する。
第１５図を用いて、リスナおよびイベントについて説明する。オブジェクト２１１、２１１、・・・は、イベントを受信しリスナを実行させるリスナインターフェイスを実装している。オブジェクト２１１は、受信したいイベントに対応するリスナを、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ２１０に対して登録する（ステップＳ１０）。あるイベントに対応するリスナをオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ２１０に対して登録することを、イベントリスナ登録と称する。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ２１０に対して、複数のオブジェクト２１１、２１１、・・・からイベントリスナ登録を行うことができきる。
リスナインターフェイスを実装したオブジェクトとは、イベント発生時に実行するメソッドを実装したオブジェクトである。第１５図の例では、あるイベント発生時に実行されるメソッドであるｄｏＡｃｔｉｏｎ（）が、オブジェクト２１１に実装されている。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ２１０内でイベントが発生（ステップＳ１１）し、このイベントがオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ２１０に対してイベントリスナ登録されたイベントであれば、当該イベントリスナ登録を行ったオブジェクト２１１に対して、当該イベントが送信される（ステップＳ１２）。イベントを受信したオブジェクト２１１は、メソッドｄｏＡｃｔｉｏｎ（）を実行する（ステップＳ１３）
第１６図Ａおよび第１６図Ｂは、イベントリスナ登録に関する一例のメソッドを一覧して示す。メソッドａｄｄＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒ（ＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＣｏｎｔｅｎｔｓＥｖｅｎｔを受け取るために、指定されたリスナをオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒに登録する。登録されたリスナは、配列ＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒ（）に追加される。イベントＣｏｎｔｅｎｔｓＥｖｅｎｔは、第１４図Ａ、第１４図Ｂおよび第１４図Ｃを用いて説明した、（１）の、再生中のコンテンツから発せられるイベントの総称である。メソッドａｄｄＲｍｔＫｅｙＬｉｓｔｅｎｅｒ（ＲｍｔＫｅｙＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＲｍｔＫｅｙＥｖｅｎｔ（第１４図Ａ、第１４図Ｂおよび第１４図Ｃを用いて説明した、（２）の、ユーザからの割り込みにより発生されるイベント）を受け取るために、指定されたリスナを登録する。登録されたリスナは、配列ＲｍｔｋｅｙＬｉｓｔｅｎｅｒ（）に追加される。メソッドａｄｄＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒ（ＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＰｌａｙｅｒＳｔａｔｕｓＥｖｅｎｔを受け取るために、指定されたリスナを登録する。登録されたリスナは、配列ＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒ（）に追加される。イベントＰｌａｙｅｒＳｔａｔｕｓＥｖｅｎｔは、第１４図Ａ、第１４図Ｂおよび第１４図Ｃを用いて説明した、（３）の、プレーヤの状態の変化により発生されるイベントの総称である。
メソッドｒｅｍｏｖｅＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒ（ＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＣｏｎｔｅｎｔｓＥｖｅｎｔを受け取らないように、指定されたリスナを削除する。メソッドｒｅｍｏｖｅＲｍｔＫｅｙＬｉｓｔｅｎｅｒ（ＲｍｔＫｅｙＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＲｍｔＫｅｙＥｖｅｎｔを受け取らないように、指定されたリスナを削除する。メソッドｒｅｍｏｖｅＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒ（ＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒ ｌ）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベントＰｌａｙｅｒＳｔａｔｕｓＥｖｅｎｔを受け取らないように、指定されたリスナを削除する。
このように、”ａｄｄ”で始まるメソッドを実行することで、イベントリスナ登録が行われる。イベントリスナ登録は、目的とするイベントが発生する前に行う。イベントを受け取る必要がなくなった時には、”ｒｅｍｏｖｅ”で始まるメソッドを実行することで、イベント送信を停止させることができる。
第１６図Ａおよび第１６図Ｂにおいて、メソッドｇｅｔＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒｓ（）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒに登録されている全てのＣｏｎｔｅｎｔｓＬｉｓｔｅｎｅｒの配列を返す。メソッドｇｅｔＲｍｔｋｅｙＬｉｓｔｅｎｅｒｓ（）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒに登録されている全てのＲｍｔｋｅｙＬｉｓｔｅｎｅｒの配列を返す。メソッドｇｅｔＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒｓ（）で、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒに登録されている全てのＰｌａｙｅｒＳｔａｔｕｓＬｉｓｔｅｎｅｒの配列を返す。
イベントリスナ登録を用いたプログラムの作成について説明する。ここでは、プレイリストを再生中、あるシーンになったときにボタンを表示させる動作を行わせるプログラムを作成する例である。プレイリストを再生中に、特定のシーンに入ったことを知るには、マーク機能を利用すればよい。マークは、プレイリストの任意の時刻に設定することが可能な頭出し点を設ける機能である。マークが設定された時刻に再生がさしかかると、第１４図Ａ、第１４図Ｂおよび第１４図Ｃを用いて説明したイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔが発生する。このイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔの発生をきっかけとしてボタンが表示されるようなリスナインターフェイスを実装したボタンオブジェクトを作成すればよい。すなわち、ボタンのオブジェクトには、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒにイベントリスナ登録をし、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔを受け取った際に表示を開始するようなプログラムを実装しておけばよい。
より具体的には、第１７図に一例が示されるように、先ず、プレイリスト上のどのシーンでボタンを表示させるかを決め（ステップＳ２０）、プレイリスト上のボタンを表示させる時刻に、マークを設定する（ステップＳ２１）。次に、表示させるボタンのオブジェクトに、ステップＳ２１で設定されたマークに対応するイベントリスナ登録を行うメソッドを、プログラム中に記述する（ステップＳ２２）。すなわち、このステップＳ２２では、第１５図で説明したステップＳ１０の動作を行わせる記述がなされる。そして、イベント発生時に実行させる処理をボタンオブジェクトに記述し、ボタンオブジェクトに対して、マーク発生イベントに対応するリスナインターフェイスを実装する（ステップＳ２３）。すなわち、このステップＳ２３では、第１５図で説明したステップＳ１３の内容が記述される。これらのプログラムは、Ｊａｖａ言語で以て記述される。
第１８図は、第１７図のようなプログラミングにより規定された動作を、再生側が実装する際の一例の処理を示す。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒにより、プレイリストの再生が開始される（ステップＳ３０）。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、プレイリストの再生中に、プレイリスト中に設けられたマークを検出したものとする（ステップＳ３１）。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、検出されたマークに対応するイベントリスナが登録されているか否かを調べる（ステップＳ３２）。すなわち、ステップＳ３２では、第１５図を用いて説明した、ステップＳ１０の処理が行われているか否かが調べられる。若し、対応するイベントリスナが登録されていないと判断されれば、処理はステップＳ３６に移行し、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、イベント送信を行わない。
一方、ステップＳ３２で、マークに対応するイベントリスナが登録されていると判断されれば、処理はステップＳ３３に移行する。ステップＳ３３では、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、イベントリスナを登録したオブジェクトに対してイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔを送信する。これは、第１５図を用いて説明した、ステップＳ１２の処理である。このイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔを受けたオブジェクトは、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔの発生時に実行するメソッドの実行を開始する（ステップＳ３４）。すなわち、第１５図を用いて説明した、ステップＳ１３のメソッドｄｏＡｃｔｉｏｎ（）実行される。この例では、このメソッドｄｏＡｃｔｉｏｎ（）は、ボタンを画面上に表示する処理が記述されている。この記述に従い、画面上にボタンが表示される（ステップＳ３５）。
背景技術において第２図Ａおよび第２図Ｂを用いて既に説明したように、従来のＤＶＤビデオでは、ボタンの情報がＡＶストリームに多重化されているため、ボタンの表示開始時刻を変更するためには、ＡＶストリームの再多重化を行う必要があった。
これに対してこの発明の実施の第１の形態による、ＢＤ−ＲＯＭ仮想プレーヤモデルでは、マークの時間軸上の設定位置を変えるだけで、ボタンの表示開始時刻を変更することができる。この発明の実施の第１の形態では、第１９図Ａ、第１９図Ｂおよび第１９図Ｃに概略的に示されるように、クリップＡＶストリームファイル（第１９図Ａ）、マークデータが格納されるファイル（第１９図Ｂ）およびボタンを構成するデータが格納されるファイル（第１９図Ｃ）は、互いに独立的な構成となっている（ファイル構成の詳細は、後述する）。なお、クリップＡＶストリームファイルは、ビデオパックおよびオーディオパックが多重化されたファイルである。
このように、マークの情報は、クリップＡＶストリームとは別のデータベースファイルに格納される。そのため、第１９図Ａ、第１９図Ｂおよび第１９図Ｃに示されるように、当初、表示開始時刻が時刻ｐｔｓ１とされているボタン画像を、時刻ｐｔｓ２から表示させようとする場合でも、例えばデータベースから読み込まれたマーク情報について、時刻ｐｔｓ１を時刻ｐｔｓ２に書き換えるだけでよく、マークの位置を変更しても、クリップＡＶストリームの再多重化を行う必要が無い。
また、この実施の第１の形態では、ボタンを構成するデータも、クリップＡＶストリームとは別のファイルに格納される。そのため、ボタンが選択された際の処理の記述についても、クリップＡＶストリームファイルとは独立して存在するボタンオブジェクトのメソッドを変更するだけでよい。既に説明したように、従来のＤＶＤビデオでは、ボタン選択時の処理を行うボタンコマンドがＡＶストリームに多重化されていたため、ボタンが選択された際の処理の変更は、容易には実現できなかった。
ＢＤ−ＲＯＭのフルプロファイルにおいては、以上のようなＢＤ−ＲＯＭ仮想プレーヤモデルを構築することにより、従来のＤＶＤビデオビデオと比較して、オーサリングの柔軟性、容易性の向上を実現することができる。
上述では、ＢＤ−ＲＯＭ仮想プレーヤモデルを、オブジェクト指向的なイベントリスナのモデルに基づき構築した。ＢＤ−ＲＯＭ仮想プレーヤモデルは、この例に限らず、より簡便な、イベントドリブンモデルで構築することも可能である。
第２０図を用いて、イベントドリブンモデルによるＢＤ−ＲＯＭ仮想プレーヤモデルについて説明する。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒで発生するイベントは、第１５図を用いて説明したオブジェクト指向的なモデルと同一である。このイベントドリブンモデルの場合は、イベント発生時に呼び出されるメソッドが、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ内に定義されたメソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）だけとする。すなわち、このモデルでは、どのイベントが呼び出されても同じメソッドが呼び出される。そのため、イベントの種類によって処理を変えたい場合には、どのイベントが発生したかをメソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）の中で判定する必要がある。
このモデルでは、イベント毎にイベントリスナ登録を行う必要がない。そのため、簡易な構成のモデルを構築できる。しかしながら、イベント発生の度にメソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）が呼び出されるため、効率が悪い。また、処理するメソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）が固定的にオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ内に定義されているため、別のオブジェクト内で新しい処理ルーチンを定義して実行するといった拡張性に乏しい。そのため、拡張性を重視するこの発明の実施の第１の形態には、第１５図を用いて説明したオブジェクト指向的なモデルでＢＤ−ＲＯＭ仮想プレーヤモデルを構築するのが好ましい。
１−４．ユーザ入力について
第２１図Ａ、第２１図Ｂ、第２１図Ｃおよび第２１図Ｄは、ＢＤ−ＲＯＭ仮想プレーヤモデルが受け付けるユーザ入力コマンドの定義の一例を一覧して示す。このユーザ入力は、プレーヤを操作するためのリモートコントロールコマンダに設けられたキーからの入力や、プレーヤ装置から出力されるメニュー画面に応じた入力を想定している。ユーザ入力は、ＢＤ−ＲＯＭ仮想プレーヤモデルにとっては、キー入力イベントの一種である。
コマンドｔｉｍｅＳｅａｒｃｈ（ｐｌａｙｌｉｓｔＮｕｍｂｅｒ，Ｔｉｍｅ）は、再生中のシナリオの、”Ｔｉｍｅ”で指定される時刻からの再生を指示する。コマンドｐｌａｙ（ｐｌａｙｌｉｓｔＮｕｍｂｅｒ，ｃｈａｐｔｅｒＮｕｍｂｅｒ）は、指定のシナリオの、”ｃｈａｐｔｅｒＮｕｍｂｅｒ”で指定されるチャプタからの再生を指示する。コマンドｓｔｏｐ（）は、再生の停止を指示する。コマンドｐｒｅｖ（）は、再生中のチャプタの１つ前のチャプタの先頭からの再生開始を指示する。コマンドｔｏｐ（）は、再生中のチャプタの先頭からの再生開始を指示する。コマンドｎｅｘｔ（）は、再生中のチャプタの次のチャプタの先頭からの再生開始を指示する。コマンドｆｏｒｗａｒｄＳｃａｎ（ｓｐｅｅｄ）は、”ｓｐｅｅｄ”で指定された速度での順方向再生を指示し、コマンドｂａｃｋｗａｒｄＳｃａｎ（ｓｐｅｅｄ）は、”ｓｐｅｅｄ”で指定された速度での逆方向再生を指示する。”ｓｐｅｅｄ”は、０．１〜３６０の範囲で値を指定できる。
コマンドｍｏｖｅＣｕｒｓｏｒ（ｄｉｒｅｃｔｉｏｎ，［ｌｅｖｅｌ］）は、カーソルの上下左右の移動を指示する。”ｄｉｒｅｃｔｉｏｎ”は、”ｕｐｐｅｒ”、”ｌｏｗｅｒ”、”ｌｅｆｔ”または”ｒｉｇｈｔ”の何れかの値であって、それぞれカーソルの上、下、左、右方向への移動を指示する。また、”ｌｅｖｅｌ”は、”０”〜”２５５”の範囲で値を指定できる。”ｌｅｖｅｌ”オプションは、通常は用いないか、値が”０”とされる。”ｌｅｖｅｌ”の値として中間値（”１”〜”２５５”）を使用することで、アナログジョイスティックなどを表現する。
コマンドｃｌｉｃｋ（ｂｕｔｔｏｎＮｕｍｂｅｒ）は、画面上のボタンのクリックを指示する。コマンドｆｏｃｕｓ（ｂｕｔｔｏｎＮｕｍｂｅｒ）は、画面上のボタンにフォーカスを当てる旨を指示する。
コマンドｓｔｉｌｌＯｆｆ（）は、プレーヤによって一時停止された再生の再開を指示する。コマンドｓｔｉｌｌＯｆｆ（）は、コマンドｐａｕｓｅＯｆｆと統合できる。コマンドｐａｕｓｅＯｎ（）は、一時停止を指示する。このコマンドｐａｕｓｅＯｎ（）は、シナリオ再生時にのみ動作できる。コマンドｐａｕｓｅＯｆｆ（）は、一時停止の解除を指示する。
コマンドＬａｎｇｕａｇｅＳｅｌｅｃｔ（ｌａｎｇｕａｇｅＣｏｄｅ）は、メニューの表示言語を指定する。コマンドＳｔｒｅａｍＣｈａｎｇｅ（ＳｔｒｅａｍＮｕｍｂｅｒ）は、再生するストリームの変更を指示する。コマンドｓｅｔＥｎａｂｌｅｄ（ｂｏｏｌｅａｎ）は、ストリームの表示／非表示を指定する。コマンドａｎｇｌｅＣｈａｎｇｅ（ａｎｇｌｅＮｕｍｂｅｒ）は、表示アングルの変更を指示する。コマンドｐａｒｅｎｔａｌＣｏｕｎｔｒｙＳｅｌｅｃｔ（ｃｏｕｎｔｒｙＣｏｄｅ）は、パレンタルレベル用のカントリーコードを設定する。コマンドｖｉｄｅｏＰｒｅｓｅｎｔａｔｉｏｎＭｏｄｅＣｈａｎｇｅ（ｍｏｄｅ）は、ビデオの表示形式を指定する。”ｍｏｄｅ”は、”Ｗｉｄｅ”（ワイド）、”ＬＢ”（レターボックス）または”ＰａｎＳｃａｎ”（パンスキャン）の何れかの値を取る。
第２２図は、リモートコントロールコマンダからのキー入力イベントを表すクラスＲｍｔＫｅｙＥｖｅｎｔの例を示す。パラメータ”ｓｏｕｒｃｅ”は、イベントの発生元のオブジェクトであって、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒを指す。パラメータ”ｉｄ”は、イベントのタイプを表す整数である。パラメータ”ｗｈｅｎ”は、イベントが発生した時刻を指定するｌｏｎｇ形式の整数である。パラメータ”ｍｔＫｅｙＣｏｄｅ”は、入力仮想キーに対応する整数型コードまたは”ＶＫ＿ＵＮＤＥＦＩＮＥＤ”とされる。”ＶＫ＿ＵＮＤＥＦＩＮＥＤ”については、後述する。
第３図Ａおよび第３図Ｂを用いて既に説明したように、リモートコントロールコマンダのキーによるユーザ入力は、先ずハードウェアが受け取り、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒにも伝えられる。このユーザ入力に応じて、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒでは、クラスＲｍｔＫｅｙＥｖｅｎｔによりオブジェクトＲｍｔＫｅｙＥｖｅｎｔが発生し、このオブジェクトＲｍｔＫｅｙＥｖｅｎｔに対応したイベントリスナを登録しているオブジェクトに対して、ユーザ入力によるコマンドが通知される。
第２３図は、オブジェクトＲｍｔＫｅｙＥｖｅｎｔが有する一例のメソッドを一覧して示す。メソッドｇｅｔＲｍｔＫｅｙＣｏｄｅは、このイベントが発生したキーのキーコードを返す。メソッドｓｅｔＲｍｔＫｅｙＣｏｄｅは、このイベントが発生するキーのキーコードを設定する。例えば、メソッドｇｅｔＲｍｔＫｅｙＣｏｄｅを実行することで、どのキーが押されたことによってオブジェクトＲｍｔＫｅｙＥｖｅｎｔが発生したかを知ることができる。
第２４図、ならびに、第２５図Ａおよび第２５図Ｂは、第２３図で説明したメソッドｇｅｔＲｍｔＫｅｙＣｏｄｅによって得られる一例のキーを一覧して示す。第２４図、ならびに、第２５図Ａおよび第２５図Ｂに示される「ＶＫ」で始まる各キーは、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒ上の仮想的なキーである。キーＶＫ＿ＰＯＷＥＲは、電源キーに対応する機能を提供する。キーＶＫ＿ＰＯＷＥＲ＿ＯＮは、電源ＯＮキーに対応する機能を提供する。キーＶＫ＿ＰＯＷＥＲ＿ＯＦＦは、電源ＯＦＦキーに対応する機能を提供する。キーＶＫ＿ＭＥＮＵは、メニューを表示させるメニューキーに対応する機能を提供する。キーＶＫ＿ＥＮＴＥＲは、「決定」を指示する決定キーに対応する機能を提供する。キーＶＫ＿ＲＥＴＵＲＮは、処理のステップを一つ戻す戻るキーに対応する機能を提供する。
キーＶＫ＿ＰＬＡＹは、再生を指示する再生キーに対応する機能を提供する。キーＶＫ＿ＳＴＯＰは、再生の停止を指示する停止キーに対応する機能を提供する。キーＶＫ＿ＰＡＵＳＥは、再生の一時停止を指示する一時停止キーに対応する機能を提供する。キーＶＫ＿ＦＡＳＴ＿ＦＯＲＷＡＲＤは、早送り再生を指示する早送りキーに対応する機能を提供する。キーＶＫ＿ＦＡＳＴ＿ＲＥＶＥＲＳＥは、早戻し再生を指示する早戻しキーに対応する機能を提供する。キーＶＫ＿ＳＬＯＷ＿ＦＯＲＷＡＲＤは、順方向のスロー再生を指示するスロー（順方向）キーに対応する機能を提供する。キーＶＫ＿ＳＬＯＷ＿ＲＥＶＥＲＳＥは、逆方向のスロー再生を指示するスロー（逆方向）キーに対応する機能を提供する。キーＶＫ＿ＳＴＥＰ＿ＦＯＲＷＡＲＤは、順方向のコマ送り再生を指示するコマ送り（順方向）キーに対応する機能を提供する。キーＶＫ＿ＳＴＥＰ＿ＲＥＶＥＲＳＥは、逆方向のコマ送り再生を指示するコマ送り（逆方向）キーに対応する機能を提供する。
キーＶＫ＿ＮＥＸＴは、「次」を意味する値を入力する次指定キーに対応する機能を提供する。キーＶＫ＿ＰＲＥＶＩＯＵＳは、「前」を意味する値を入力する前指定キーに対応する機能を提供する。例えば、キーＶＫ＿ＮＥＸＴおよびキーＶＫ＿ＰＲＥＶＩＯＵＳを用いて、前後のチャプタへの移動を指示することができる。
キーＶＫ＿ＵＰは、「上」を意味する値を入力する上方向指定キーに対応する機能を提供する。キーＶＫ＿ＤＯＷＮは、「下」を意味する値を入力する下方向指定キーに対応する機能を提供する。キーＶＫ＿ＲＩＧＨＴは、「右」を意味する値を入力する右方向指定キーに対応する機能を提供する。キーＶＫ＿ＬＥＦＴは、「左」を意味する値を入力する左方向指定キーに対応する機能を提供する。キーＶＫ＿ＵＰ＿ＲＩＧＨＴは、「右上」を意味する値を入力する右上方向指定キーに対応する機能を提供する。キーＶＫ＿ＵＰ＿ＬＥＦＴは、「左上」を意味する値を入力する左上方向指定キーに対応する機能を提供する。キーＶＫ＿ＤＯＷＮ＿ＲＩＧＨＴは、「右下」を意味する値を入力する右下方向指定キーに対応する機能を提供する。キーＶＫ＿ＤＯＷＮ＿ＬＥＦＴは、「左下」を意味する値を入力する左下方向指定キーに対応する機能を提供する。これらの方向キーを用いることで、例えば画面上のカーソル表示の移動を指示することができる。
キーＶＫ＿ＡＮＧＬＥは、マルチアングルのビデオに対するアングル切り替えを指示するアングル切り替えキーに対応する機能を提供する。キーＶＫ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＧＲＡＰＨＩＣＳは、英語字幕、日本語字幕、字幕表示／非表示などを切り替える字幕切り替えキーに対応する機能を提供する。キーＶＫ＿ＡＵＤＩＯは、サラウンドやバイリンガルなどオーディオ設定を切り替えるオーディオ切り替えに対応する機能を提供する。キーＶＫ＿ＶＩＤＥＯ＿ＡＳＰＥＣＴは、ビデオのアスペクト比切り替えを指示するアスペクト切り替えキーに対応する機能を提供する。キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿１は、色つきファンクションキー１、キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿２は、色つきファンクションキー２、キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿３は、色つきファンクションキー３、キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿４は、色つきファンクションキー４、キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿５は、色つきファンクションキー５、キーＶＫ＿ＣＯＬＯＲＥＤ＿ＫＥＹ＿６は、色つきファンクションキー６にそれぞれ対応する機能を提供する。キーＶＫ＿ＵＮＤＥＦＩＮＥＤは、未定義キーである。
第２４図、ならびに、第２５図Ａおよび第２５図Ｂに一覧したキーは、実際のリモートコントロールコマンダの物理キーと必ずしも一致しない。機器によっては、一つの物理キーに複数の機能を持たせることがある。また画面上にリモコンを表す画像を表示して、表示された画面上のキーをユーザに選択させることもある。そのため、第２４図、ならびに、第２５図Ａおよび第２５図Ｂに示すキーは、機能を抽象化した仮想的なキーである。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒへのユーザ入力を、このような仮想キーで表現することにより、機器に依存しないユーザ入力を定義することができる。
第２６図は、ユーザ入力イベントをきっかけとして、用意されたプログラムが実行される一例の手順を示す。第２６図は、通常再生中に、ユーザにより”ｎｅｘｔ”キーが押されたときに、このキー入力に対応して、次のチャプタにジャンプして再生を開始すると同時に、用意されたメッセージを画面上に表示するプログラムの例である。
”ｎｅｘｔ”キーは、次のチャプタに移動して再生することをプレーヤに対して指示するためのキーであって、例えばリモートコントロールコマンダ上のキーである。第２６図のフローチャートは、ユーザが再生中にこの”ｎｅｘｔ”キーを押すことで開始される（ステップＳ４１）。”ｎｅｘｔ”キーが押されると、オブジェクトＲｍｅＫｅｙＥｖｅｎｔ発生され（ステップＳ４２）、次のチャプタマークを探すため、チャプタマークにデータベースが検索される（ステップＳ４３）。検索結果に基づき次のチャプタマークが存在するか否かが判断され（ステップＳ４４）、存在しなければ、一連の処理が終了され、通常再生が継続される。ステップＳ４４で、次のチャプタマークが存在すると判断されれば、処理はステップＳ４５に移行する。
ステップＳ４５では、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、”ｎｅｘｔ”キーに応答して現在再生中のチャプタの再生が中止される（ステップＳ４５）。プレーヤの再生が中止されると、イベントＰｌａｙＳｔｏｐｐｅｄＥｖｅｎｔが発生される（ステップＳ４６）。オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、ステップＳ４３およびステップＳ４４で取得された次のチャプタマークが指し示す、クリップＡＶストリームファイル内のバイト位置を、クリップ情報ファイルの特徴点情報から取得する。取得されたファイル内バイト位置にアクセスし、その位置からストリームの読み込みを開始して、再生を開始する（ステップＳ４７）。
ステップＳ４８以下は、チャプタが切り替わったことを知らせるメッセージを画面上に表示する一例の手順である。チャプタが切り替わった位置でメッセージを表示するためには、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔに対応するイベントリスナとして、メッセージ表示のメソッドを実装しておけばよい。ストリームの再生が開始されると、イベントＰｌａｙＳｔａｒｔｅｄＥｖｅｎｔが発生される。それと共に、チャプタマークに対応してイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔが発生される（ステップＳ４８）。
イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔの発生に伴い、ステップＳ４９で、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔに対応したリスナの実行が開始される。このリスナでは、先ず、イベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔにより検出されたマークの種別が取得され（ステップＳ５０）、このマークがチャプタマークであるか否かが判断される（ステップＳ５１）。若し、チャプタマークでないと判断されれば、処理はステップＳ５３に移行され、当該リスナの実行が終了される。ステップＳ５１で、検出されたマークがチャプタマークであると判断されれば、処理はステップＳ５２に移行され、チャプタ先頭であることを示すメッセージを表示する。
この例では、ユーザがリモートコントロールコマンダのキーを押したことにより一つのイベントＲｍｔＫｅｙＥｖｅｎｔが発生し、このイベントＲｍｔＫｅｙＥｖｅｎｔの発生をきっかけにした一連の状態遷移によって、イベントＰｌａｙＳｔｏｐｐｅｄＥｖｅｎｔ、イベントＰｌａｙＳｔａｒｔｅｄＥｖｅｎｔおよびイベントＭａｒｋＥｎｃｏｕｎｔｅｒｅｄＥｖｅｎｔといった、複数のイベントが引き起こされる。
このように、この発明の実施の第１の形態によるＢＤ−ＲＯＭ仮想プレーヤモデルでは、ユーザ入力イベントは、プレーヤの状態を変化させ、新たなイベントを発生させる契機ともなり、新たに発生したイベントを利用してさまざまな処理を行わせることができる。
この発明の実施の第１の形態では、上述のようにしてＢＤ−ＲＯＭ仮想プレーヤモデルを定義することで、ＤＶＤビデオにはなかった様々なメリットを得ることができる。例えば、この発明の実施の第１の形態によれば、従来のＤＶＤビデオにおける幾つかの機能を、一つのモデルで実現できる。
第１の例として、字幕の強制出画機能およびＵＯＰ（Ｕｓｅｒ Ｏｐｅｒａｔｉｏｎ）禁止機能が挙げられる。字幕の強制出画機能は、ユーザが字幕表示をオフに設定していても、特定の字幕を特定のシーンで強制的に表示させる機能である。また、ＵＯＰ禁止機能は、ユーザ入力を禁止する機能である。ＤＶＤビデオでは、これらの機能を実現するために、それぞれ専用のデータ構造と動作モデルが定義されていた。
この発明の実施の第１の形態によるＢＤ−ＲＯＭ仮想プレーヤモデルでは、字幕の強制出画機能に関しては、字幕を強制的に出画させたいシーン（時刻）にマークを打っておき、そのマークに対応したイベントリスナ登録を行うと共に、字幕表示のオン／オフにかかわらず画面上に字幕を出画する処理をリスナとして用意しておく。このようにすることで、通常のマークを処理するモデルで、字幕の強制出画機能を同一の処理として実現することができる。
また、ＵＯＰ禁止機能については、リモートコントロールコマンダのキー入力イベントに対するイベントリスナ登録を行わなければ、キー入力によるイベントが発生しても何も処理が行われないので、ユーザ入力が無視され、ＵＯＰが禁止される。
このように、この発明の実施の第１の形態では、一つのイベントモデルでＤＶＤの機能を実現できるので、ディスク制作側の負担が軽くなるというメリットがある。
また例えば、ＤＶＤビデオでは、リモートコントロールコマンダの各キーに対する動作が予め決まっていた。例えば、サブメニューキーを押すと、オーディオ、字幕、アングルの設定を変更するためのサブメニュー画面が表示されることが、サブメニューキーの動作として決められていた。しかしながら、サブメニューはＤＶＤビデオにおいて必須のデータではないので、サブメニューが無いディスクも存在する。この場合、サブメニューキーを押しても、何も反応がないことになる。
一方、この発明の実施の第１の形態のＢＤ−ＲＯＭ仮想プレーヤモデルでは、第２１図Ａ、第２１図Ｂ、第２１図Ｃおよび第２１図Ｄ、第２２図、第２３図、第２４図、ならびに、第２５図Ａおよび第２５図Ｂを用いて説明したように、キーが押されたときにどのような処理を行うかは、ディスク制作側で決めることができる。そのため、サブメニューを用意しない場合でもメッセージを表示するようにプログラムすることで、サブメニューキーが押された場合には、メッセージを表示してサブメニューが無いことをユーザに伝えることが可能となる。
このように、この発明の実施の第１の形態では、ディスク製作の際の自由度が上がり、ユーザにとって操作しやすいディスクを製作することができるようになるというメリットがある。
さらに、この発明の実施の第１の形態では、ＢＤ−ＲＯＭ仮想プレーヤモデルに対応するＪａｖａクラスを定義し、Ｊａｖａプログラムによりプレイリストの再生制御を行うようにしている。Ｊａｖａプログラムを用いることにより、マルチスレッドプログラムが実現でき、ネットワークアクセスやユーザ入力の応答待ちによるタイムラグに容易に対処可能である。また、Ｊａｖａプログラムを用いることにより、コマンド先読みによる分岐予測や投機実行なども、容易に実現可能であり、高速処理が可能となる。
１−５．ファイルの管理構造について
次に、ＢＤ−ＲＯＭのフルプロファイルに適用可能なファイルの管理構造について、第２７図を用いて説明する。ファイルは、ディレクトリ構造により、階層的に管理される。記録媒体上には、必ず１つのディレクトリ（第２７図の例ではルート（ｒｏｏｔ）ディレクトリ）が作成される。このディレクトリの下が、１つの記録再生システムで管理される範囲とする。
ルートディレクトリの下に、ディレクトリＢＤＭＶが置かれる。なお、図示はされていないが、ディレクトリＢＤＭＶは、ルートディレクトリの下に複数を置くことができる。
ディレクトリＢＤＭＶの下には、２つのファイルすなわちファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」およびファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」が置かれると共に、ディレクトリ「ＰＬＡＹＬＩＳＴ」、ディレクトリ「ＣＬＩＰＩＮＦ」、ディレクトリ「ＳＴＲＥＡＭ」といった複数のディレクトリが置かれる。
ファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」は、シナリオが格納されるシナリオファイルである。シナリオは、複数のプレイリストが並べられた構造であって、プレイリストの再生順序などを制御する。シナリオをより細分化した単位でユーザに見せるために、チャプタを設けることができる。設けられる。なお、第３図Ａおよび第３図Ｂを用いて説明した、ＢＤ−ＲＯＭのＨＤムービーモードにおけるムービーオブジェクトは、ファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」に格納される。
ファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」は、シナリオ内の頭出し点（タイトルエントリ）、メニューを構成するプレイリストやプレイリスト群へのエントリポイントなどのメニューに関する情報が格納される。なお、第３図Ａおよび第３図Ｂを用いて説明した、ＢＤ−ＲＯＭのＨＤムービーモードにおけるインデックステーブルは、ファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」に格納される。
ディレクトリ「ＰＬＡＹＬＩＳＴ」は、プレイリストが格納される。一つのプレイリストは、一つのファイル「＊＊＊＊＊．ｍｐｌｓ」に格納される。クリップＡＶストリーム上のマーク位置を表す情報は、当該クリップＡＶストリームの再生範囲を指定したプレイリストファイル「＊＊＊＊＊．ｍｐｌｓ」に格納される。
ディレクトリ「ＣＬＩＰＩＮＦ」は、クリップインフォメーションファイル「＃＃＃＃＃．ｃｌｐｉ」が格納される。ディレクトリ「ＳＴＲＥＡＭ」は、クリップＡＶストリームファイル「％％％％％．ｍ２ｔｓ」が格納される。クリップインフォメーションファイルと、対応するクリップＡＶストリームファイルに対して、互いに関連したファイル名を付与することで、これらのファイルの関連付けが容易となる。例えば、クリップインフォメーションファイルと、対応するクリップＡＶストリームファイルにおいて、拡張子より前の部分「＃＃＃＃＃」と「％％％％％」とを同一とする。
なお、図示しないが、Ｊａｖａプログラムを構成するＪａｖａクラスファイルは、例えばディレクトリＢＤＭＶの下に設けられた所定のディレクトリに格納される。これに限らず、例えば、ルートディレクトリの下に、ディレクトリＢＤＭＶと同階層に設けられたディレクトリに格納するようにしてもよい。
１−６．デコーダモデルについて
次に、この発明の実施の第１の形態に適用可能なプレーヤデコーダ１００について説明する。第２８図Ａ、第２８図Ｂおよび第２８図Ｃは、この発明の実施の第１の形態に適用可能なプレーヤデコーダ１００の一例の構成を示す機能ブロック図である。このプレーヤデコーダ１００は、図示されないドライブ装置に装填されたディスクから再生されたデータを解釈し、コンテンツを構成するＡＶ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリームを出力すると共に、出力されたＡＶストリームに対するユーザによるインタラクティブな操作を可能とする。
なお、プレーヤデコーダ１００は、図示されないＣＰＵにより全体の動作が制御される。例えば、プレーヤデコーダ１００の各部におけるストリームやデータの流れは、ＣＰＵにより監視され、制御される。
図示されないドライブ装置にディスクが装填されると、ＢＤ−ＲＯＭのＨＤムービーモードにおいては、先ず、プレイリストの再生順序を指定したファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」と、メニューやタイトルを構成するプレイリスト群の先頭プレイリストを指すファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」とが再生され、このファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」およびファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」の記述に基づき、必要な他のファイルが読み出され、ディスクに記録されたコンテンツが再生される。
例えば、ファイル「ｓｃｅｎａｒｉｏ．ｈｄｍｖ」およびファイル「ｅｎｔｒｙｌｉｓｔ．ｄａｔａ」の記述に基づき、ビデオプレーン１３４および第２ビデオプレーン１６０に表示するための動画データ、グラフィクスプレーンＡ１３２やグラフィクスプレーンＢ１３３、第２ビデオプレーン１６０に表示するための画像データ、プレイリストファイルなどがディスクから読み出される。フルプロファイルにおいては、プログラムを格納したファイルが読み出され、実行される。
以下では、ディスクから読み出されるこれらのデータのうち、動画データ、サブピクチャ（字幕データ）や音声データといった、連続的に処理する必要があるストリームをリアルタイムストリームと称する。また、シナリオファイル、プレイリストファイル、スクリプトファイルおよびプログラムファイル、ならびに、一部の動画、静止画およびサウンドデータといった、連続的な処理を要求されない非リアルタイムなデータを、ストアオブジェクトと称する。ストアオブジェクトは、メモリ上などに蓄積、展開され、必要に応じて処理される。
プレーヤデコーダ１００は、チャンネル（１）および（２）の２系統の入力チャンネルを有し、入力チャンネル（１）の入力端１０１に、ストアオブジェクトが入力される。入力チャンネル（２）の入力端２０２に、リアルタイムストリームが入力される。入力端２０２に、ストアオブジェクトを入力することも可能である。この実施の第１および第２の形態では、入力端２０２に入力されるリアルタイムストリームおよび一部のストアオブジェクトは、例えばＭＰＥＧ２ ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）である。
なお、入力端２０２に入力されるリアルタイムストリームは、ＭＰＥＧ２ ＴＳに限られない。パケット単位で伝送され、ビデオデータ、オーディオデータ、静止画像データなどを多重化可能であれば、他の形式のストリームを入力するようにしてもよい。このときには、後述するＰＩＤフィルタ１１０は、そのストリーム形式に適合したデマルチプレクサとして用いられ、ビデオデータ、オーディオデータ、静止画像データなどを分離する。
また、例えば、ドライブ装置においてディスクの回転速度を２倍速などの高速回転としてディスクからの読み出し転送レートを上げ、時分割で動作させることにより、ディスクからの、チャンネル（１）および（２）の２系統の読み出しが実現可能である。
先ず、入力チャンネル（１）の系統について説明する。入力端１０１に入力されたストアオブジェクトは、スイッチ回路１０２に入力される。ストアオブジェクトとしてＪａｖａファイルや、ＥＣＭＡ（Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ）スクリプト、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイル（またはＸＨＴＭＬファイル）などによるプログラムコードが入力された場合、スイッチ回路１０２において出力端１０２Ａが選択され、入力されたプログラムコードがコードバッファ１０４に蓄えられる。
一方、ストアオブジェクトとして画像データが入力された場合、スイッチ回路１０２において出力端１０２Ｂが選択され、入力された画像データがスイッチ回路１０３に入力される。入力端２０２に入力されたリアルタイムストリームに、グラフィクスプレーンＡ１３２やグラフィクスプレーンＢ１３３に表示するための画像データが含まれていない場合には、スイッチ回路１０３で入力端１０３Ａが選択され、スイッチ回路１０２から入力された画像データがコンテンツバッファ１０５に蓄えられる。
同様にして、入力端２０２に入力されたリアルタイムストリームに、グラフィクスプレーンＡ１３２やグラフィクスプレーンＢ１３３に表示するための画像データが含まれている場合には、スイッチ回路１０３において入力端１０３Ｂが選択され、当該画像データがコンテンツバッファ１０５に蓄えられる。コードバッファ１０４およびコンテンツバッファ１０５に蓄えられたストアオブジェクトは、必要に応じて読み出され、マルチメディアエンジン１０６に供給される。
コンテンツバッファ１０５に蓄えられたストアオブジェクトのうち画像データは、スイッチ回路１０７および１０８をそれぞれ介して、グラフィクスデコーダＡ１１６およびグラフィクスデコーダＢ１１７にも供給される。
マルチメディアエンジン１０６は、ＸＭＬパーサ１０６Ａ、プログラム／スクリプトインタプリタ１０６Ｂおよびグラフィクスレンダラ１０６Ｃを含む。マルチメディアエンジン１０６は、さらに、サウンドプレーヤ１０６Ｄを有し、オーディオデータの扱いを可能としている。マルチメディアエンジン１０６は、独立的なハードウェアで構成してもよいし、上述した図示されないＣＰＵの、所定のプログラムに基づく処理で実現することも可能である。
ＸＭＬパーサ１０６Ａは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書を解析する機能を有し、ＨＴＭＬ文書やＸＨＴＭＬ文書の解析も可能である。ＸＭＬパーサ１０６Ａで解釈されたＨＴＭＬ文書やＸＨＴＭＬ文書は、このプレーヤデコーダ１００で実行可能な形式に変換される。プログラム／スクリプトインタプリタ１０６Ｂは、Ｊａｖａ（登録商標）プログラムやＥＣＭＡスクリプト等を解析し、このプレーヤデコーダ１００で実行可能な形式に変換される。また、グラフィクスレンダラ１０６Ｃは、画像データを字幕プレーン１１およびグラフィクスプレーン１２に展開可能な形式にデコードする。
マルチメディアエンジン１０６において、バッファ１０９をワークメモリとして、これらＸＭＬパーサ１０６Ａ、プログラム／スクリプトインタプリタ１０６Ｂおよびグラフィクスレンダラ１０６Ｃの処理が行われる。例えば、ＸＭＬパーサ１０６Ａおよびプログラム／スクリプトインタプリタ１０６Ｂにより、バッファ１０９のうちコードバッファ１０９Ａが用いられる。また、グラフィクスレンダラ１０６Ｃにより、バッファ１０９のうちグラフィクスバッファ１０９Ｄが用いられる。バッファ１０９は、上述のコードバッファ１０９Ａおよびグラフィクスバッファ１０９Ｄの他に、文字列の表示に用いるフォントデータが格納されるフォントバッファ１０９Ｂ、ＸＭＬパーサ１０６ＡでＨＴＭＬ文書を解析した結果を階層化された木構造で保持するためのツリーバッファ１０９Ｃ、サウンドプレーヤ１０６Ｄで用いるオーディオデータが格納されるサウンドバッファ１０９Ｅなどが含まれる。
マルチメディアエンジン１０６では、必要に応じて、コードバッファ１０４に蓄えられたＪａｖａプログラムの読み出し、コンテンツバッファ１０５からの画像データの読み出しなどを行う。コードバッファ１０４およびコンテンツバッファ１０５に格納されたデータは、当該データが不要になるまで、コードバッファ１０４やコンテンツバッファ１０５に保持しておくことができる。したがって、これらコードバッファ１０４やコンテンツバッファ１０５に格納されたデータは、必要に応じて何度でも読み出して使うことができる。
マルチメディアエンジン１０６では、上述の他にも、例えば、コードバッファ１０４に蓄えられたＥＣＭＡスクリプトを読み出し、実行することができる。また、読み出されたＥＣＭＡスクリプトの記述に基づき、必要に応じて、コードバッファ１０４から他のＥＣＭＡスクリプトやＨＴＭＬ文書（またはＸＨＴＭＬ文書）を読み出し実行することができる。
さらに、マルチメディアエンジン１０６により、ユーザからの、リモートコントロールコマンダやポインティングデバイスなどによる入力が受け取られ、所定に処理される。ユーザ入力は、さらに、後述するグラフィクスデコーダＡ１１６、グラフィクスデコーダＢ１１７、オーディオデコーダ１１８、ＭＰＥＧビデオデコーダ１２０およびシステムデコーダ１２１にも供給される。
グラフィクスレンダラ１０６Ｃで処理された画像データは、スイッチ回路１３０および１３１をそれぞれ介してグラフィクスプレーンＡ１３２およびグラフィクスプレーンＢ１３３に供給される。なお、この例では、グラフィクスプレーンＡ１３２およびグラフィクスプレーンＢ１３３に供給される画像データとして、ＰＮＧ形式、ランレングス形式、ＪＰＥＧ形式などが挙げられるが特に規定しない。これらの各プレーン１３２、１３３に画像データが供給されるタイミングは、マルチメディアエンジン１０６により制御される。
マルチメディアエンジン１０６は、さらに、後述するプレゼンテーションプロセッサ１５５に対して、ビデオプレーン１３４、第２ビデオプレーン１６０、グラフィクスプレーンＡ１３２およびグラフィクスプレーンＢ１３３の切り換え、アルファ合成などを指示する制御信号を供給する。同様に、マルチメディアエンジン１０６は、後述するプレゼンテーションプロセッサ１５７に対して、オーディオストリーム出力を制御するような制御信号を供給する。
マルチメディアエンジン１０６では、例えば、図示されないＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などに予め格納されたＪａｖａプログラムを読み込み、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒをマルチメディアエンジン１０６上に構築する。また、マルチメディアエンジン１０６では、コードバッファ１０４に蓄えられたＪａｖａプログラムを読み出す。コードバッファ１０４から読み出されたＪａｖａプログラムにより構成されるオブジェクトからオブジェクトＢＤＢａｓｉｃＰｌａｙｅｒに対して、必要に応じてイベントリスナ登録が行われる。
第１５図を用いて説明したように、マルチメディアエンジン１０６上で、例えばユーザ入力に応じて、コードバッファ１０４から読み出されたＪａｖａプログラムによるオブジェクトに対して、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒからイベント送信がなされ、当該オブジェクトにおいて、対応するメソッドが実行される。また、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒは、プレーヤデコーダ１００の状態の変化を検出し、所定の変化が検出されたら、対応するイベントを発生させる。マルチメディアエンジン１０６は、このようにして発生されたイベントに応じたメソッドなどにより、図示されないドライブ装置や、このプレーヤデコーダ１００の各部を制御し、ディスクの再生制御を行うことになる。
次に、入力チャンネル（２）の系統について説明する。入力端２０２にＭＰＥＧ２ ＴＳで入力されたリアルタイムストリームは、ＰＩＤフィルタ１１０に供給され、ＭＰＥＧ２ ＴＳのトランスポートパケットに格納されるＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が抽出され、当該トランスポートパケットに格納されるストリームの属性が検出される。ＰＩＤフィルタ１１０では、このストリーム属性に基づき、入力されたリアルタイムストリームが、トランスポートパケット毎に対応する系統に振り分けられる。
ＰＩＤに基づき、トランスポートパケットがストアオブジェクトに属する画像データが格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１Ａに一旦溜め込まれ、所定のタイミングで読み出されて入力端１０３Ｂが選択されたスイッチ回路１０３に入力され、スイッチ回路１０３を介してコンテンツバッファ１０５に格納される。
ＰＩＤフィルタ１１０において、ＰＩＤに基づき、トランスポートパケットが字幕データが格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１ＢおよびバッファＢｎ１１２Ｂに一旦溜め込まれ、所定のタイミングで読み出されて入力端１０７Ｂが選択されたスイッチ回路１０７に入力され、スイッチ回路１０７を介してグラフィクスデコーダＡ１１６に供給される。
グラフィクスデコーダＡ１１６では、供給されたトランスポートパケットのヘッダ情報を除去すると共に、当該トランスポートパケットに格納された字幕データがデコードされて字幕などを表示するための画像データとされる。この画像データは、所定のタイミングでスイッチ回路１３０の入力端１３０Ｂに入力され、スイッチ回路１３０を介してグラフィクスプレーンＡ１３２に展開される。また、スイッチ回路１３１を介してグラフィクスプレーンＢ１３３にも展開させることが可能である。
ＰＩＤフィルタ１１０において、ＰＩＤに基づき、トランスポートパケットがグラフィクスデータが格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１ＣおよびバッファＢｎ１１２Ｃに一旦溜め込まれ、所定のタイミングで読み出されて入力端１０８Ｂが選択されたスイッチ回路１０８に入力され、スイッチ回路１０８を介してグラフィクスデコーダＢ１１７に供給される。
グラフィクスデコーダＢ１１７では、供給されたトランスポートパケットのヘッダ情報を除去すると共に、当該トランスポートパケットに格納されたグラフィクスデータがデコードされ、グラフィクスデータとされる。この画像データは、所定のタイミングでスイッチ回路１３１の入力端１３１Ｂに入力され、スイッチ回路１３１を介してグラフィクスプレーンＢ１３３に展開される。また、スイッチ回路１３０を介してグラフィクスプレーンＡ１３２にも展開させることが可能である。
なお、グラフィクスデコーダＡ１１６とグラフィクスデコーダＢ１１７には、機能的な違いはない。つまり、モデル上、独立して動作するグラフィクスデコーダが２系統あることを表している。すなわち、字幕データとグラフィクスデータとをそれぞれ独立にデコードできることを想定している。実装においては、１系統の高速なグラフィクスデコーダを時分割で使用し、仮想的に２系統のグラフィクスデコーダが存在しているとみなす方法もある。
ＰＩＤフィルタ１１０において、ＰＩＤに基づき、トランスポートパケットがオーディオデータが格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１ＤおよびバッファＢｎ１１２Ｄに一旦溜め込まれ、所定のタイミングで読み出されてオーディオデコーダ１１８に供給される。このトランスポートパケットに格納されるオーディオデータは、例えばＭＰＥＧに準拠した方式で圧縮符号化されている。
オーディオデコーダ１１８は、例えばリニアＰＣＭ（Ｐｕｌｓｅ ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）オーディオデコーダ１１９も有する。オーディオデコーダ１１８は、入力されたトランスポートストリームのヘッダ情報を除去すると共に、当該トランスポートパケットに格納された圧縮符号化されたオーディオデータをリニアＰＣＭオーディオデータにデコードする。
オーディオデコーダ１１８から出力されたリニアＰＣＭオーディオデータは、オーディオ用のプレゼンテーションプロセッサ１５７に入力され、マルチメディアエンジン１０６の制御に基づき所定の音響効果などが付加されて、出力端１５８に導出される。
ＰＩＤフィルタ１１０において、ＰＩＤに基づき、トランスポートパケットが動画データが格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１Ｅ、バッファＭＢｎ１１３およびバッファＥＢｎ１１４に一旦溜め込まれ、所定のタイミングで読み出されてＭＰＥＧビデオデコーダ１２０に供給される。このトランスポートパケットに格納される動画データは、ＭＰＥＧ２方式により圧縮符号化されている。
ＭＰＥＧビデオデコーダ１２０では、供給されたトランスポートパケットのヘッダ情報を除去すると共に、当該トランスポートパケットに格納された、ＭＰＥＧ２方式で圧縮符号化された動画データをベースバンドの動画データにデコードする。
ＭＰＥＧデコーダ１２０から出力された動画データは、スイッチ回路１２４の入力端１２４Ａに入力される。スイッチ回路１２４において、ＭＰＥＧビデオデコーダ１２０からの動画データとマルチメディアエンジン１０６から出力された動画データが選択される。所定のタイミングで選択された動画データは、スイッチ１２３に入力される。スイッチ１２３では展開先のビデオプレーンが選択され、動画データは、ビデオプレーン１３４あるいは第２ビデオプレーン１６０に展開される。
ＰＩＤフィルタ１１０において、ＰＩＤに基づき、トランスポートパケットがシステム情報が格納されているパケットであるとされれば、当該トランスポートパケットは、バッファＴＢｎ１１１ＦおよびＢｓｙｓ１１５を介してシステムデコーダ１２１に供給される。システムデコーダ１２１では、供給されたトランスポートパケットのヘッド情報が除去され、格納されているシステム情報が取り出される。システム情報は、例えば図示されないＣＰＵに渡される。
グラフィクスプレーンＡ１３２上の画像データは、パレット１５０に供給され、２５６色からなるパレットに対してインデックスによる参照がなされ、ＲＧＢデータが出力されると共に、アルファブレンディングのためのパラメータである不透明度データα１が抜き出される。ＲＧＢデータは、ＲＧＢ／ＹＣｂＣｒ変換回路１５１によりＹＣｂＣｒデータに変換され、ＹＣｂＣｒデータおよび不透明度データα１は、プレゼンテーションプロセッサ１５５に供給される。
グラフィクスプレーンＢ１３３上の画像データは、パレット１５２に供給され、２５６色からなるパレットに対してインデックスによる参照がなされ、ＲＧＢデータが出力されると共に、不透明度データα２が抜き出される。ＲＧＢデータは、ＲＧＢ／ＹＣｂＣｒ変換回路１５３によりＹＣｂＣｒデータに変換され、ＹＣｂＣｒデータおよび不透明度データα２は、プレゼンテーションプロセッサ１５５に供給される。
ビデオプレーン１３４の出力は、アップ／ダウンコンバータ１５４を介してプレゼンテーションプロセッサ１５５に供給される。同様に、第２ビデオプレーン１６０の出力は、アップ／ダウンコンバータ１６１を介してプレゼンテーションプロセッサ１５５に供給される。
なお、アップ／ダウンコンバータ１５４は、画像の解像度を変換する回路であって、例えば高解像度のＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）画像から通常の解像度を有するＳＤ（Ｓｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎ）画像への変換を行う。
プレゼンテーションプロセッサ１５５は、グラフィクスプレーンＡ１３２の画像データによる不透明度α１と、グラフィクスプレーンＢ１３３による不透明度α２とを用いたアルファブレンディング処理を行う。また、プレゼンテーションプロセッサ１５５では、ビデオプレーン１３４および第２ビデオプレーン１６０の出力を画素単位で切り替えて、上述したピクチャインピクチャ機能や壁紙表示機能などを実現する。
すなわち、プレゼンテーションプロセッサ１５５では、ビデオプレーン１３４と第２ビデオプレーン１６０の画像データを図示されないスイッチで切り替えて一つの画像データを構成し、その画像データに対し、グラフィクスプレーンＡ１３２の画像データに設定された不透明度α１に基づき、グラフィクスプレーンＡ１３２の画像データが合成される。さらに、ビデオプレーンとグラフィクスプレーンＡ１３２が合成された画像データに対して、グラフィクスプレーンＢ１３３の画像データに設定された不透明度α２に基づき、グラフィクスプレーンＢ１３３の画像データが合成される。この、グラフィクスプレーンＢ１３３の画像データ、グラフィクスプレーンＡ１３２の画像データ（字幕データ）、ならびに、ビデオプレーン１３４、第２ビデオプレーン１６０の画像データが合成された画像データが出力端１５６に導出される。
なお、プレゼンテーションプロセッサ１５５は、画像データに対してリアルタイムでエフェクト処理を行うこともできる。
上述では、プレーヤデコーダ１００の各部がハードウェアで構成されるように説明したが、これはこの例に限られない。例えば、プレーヤデコーダ１００をソフトウェア上の処理として実現することも可能である。この場合、プレーヤデコーダ１００をコンピュータ装置上で動作させることができる。また、プレーヤデコーダ１００をハードウェアおよびソフトウェアが混合された構成で実現することもできる。例えば、オーディオデコーダ１１８やＭＰＥＧビデオデコーダ１２０をハードウェアで構成し、その他をソフトウェアで構成することが考えられる。
プレーヤデコーダ１００をソフトウェアのみ、または、ハードウェアおよびソフトウェアの混合により構成し、コンピュータ装置で実行させるためのプログラムは、例えばＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）といった記録媒体に記録されて提供される。このＣＤ−ＲＯＭをコンピュータ装置のＣＤ−ＲＯＭドライブに装填し、ＣＤ−ＲＯＭに記録されたプログラムを所定にコンピュータ装置にインストールすることで、上述の処理をコンピュータ装置上で実行可能な状態とすることができる。なお、コンピュータ装置の構成は、極めて周知であるため、説明は省略する。
２．発明の実施の第２の形態
次に、この発明の実施の第２の形態について説明する。この実施の第２の形態は、ＥＣＭＡスクリプトと呼ばれるスクリプト言語を用いてプレーヤモデルを記述する例である。ＥＣＭＡスクリプトは、ＥＣＭＡ（Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ）により定められた、ＪａｖａＳｃｒｉｐｔ（登録商標）に基づいたクロスプラットフォーム用のスクリプト言語である。ＥＣＭＡスクリプトは、ＨＴＭＬ文書との親和性が高いことと、独自のオブジェクトの定義が可能であるため、この発明によるプレーヤモデルに用いて好適である。
なお、第２８図Ａ、第２８図Ｂおよび第２８図Ｃを用いて既に説明したように、プレーヤデコーダ１００は、マルチメディアエンジン１０６においてＥＣＭＡスクリプトの解析や実行が可能であるので、この実施の第２の形態にもそのまま適用することができる。
なお、以下では、このＥＣＭＡスクリプトを元にしたスクリプト言語を用いた、この発明の実施の第２の形態に基づく規格を、ＵＭＤ（Ｕｎｉｖｅｒｓａｌ Ｍｅｄｉａ Ｄｉｓｃ：登録商標）ビデオ規格と呼ぶ。また、ＵＭＤビデオ規格のうち、特にスクリプトに関する部分をＵＭＤビデオスクリプト規格と呼ぶ。
２−１．ＵＭＤビデオ規格について
先ず、理解を容易とするために、この実施の第２の形態に適用可能なＵＭＤビデオ規格について、概略的に説明する。第２９図は、ＵＭＤビデオ規格のレイヤ構成を示す。この第２９図は、実施の第１の形態で説明した第１図に対応するものである。ＵＭＤビデオ規格では、スクリプトレイヤ、プレイリストレイヤおよびクリップレイヤの３層のレイヤ構造が定義され、この構造に基づきストリーム管理がなされる。
ＵＭＤビデオ規格においては、ディジタル符号化されたビデオ、オーディオおよび字幕を、ＭＰＥＧ２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２）のエレメンタリストリームとして多重化したＭＰＥＧ２ストリームとして扱う。このビデオ、オーディオおよび字幕のエレメンタリストリームが多重化されたＭＰＥＧ２ストリームを、クリップＡＶストリーム（Ｃｌｉｐ ＡＶ Ｓｔｒｅａｍ）と呼ぶ。クリップＡＶストリームは、クリップＡＶストリームファイルに格納される。クリップＡＶストリームファイルの記録時に、当該クリップＡＶストリームファイルに１対１に対応して、クリップインフォメーションファイル（Ｃｌｉｐ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅ）が同時に作成される。これらクリップインフォメーションファイルと、対応するクリップＡＶストリームファイルとからなる組を、クリップ（Ｃｌｉｐ）と呼ぶ。
クリップは、ディスクへの記録の単位ともいうべきものであり、再生時にどのような順序でクリップを再生するかは、クリップの上位のレイヤであるプレイリストレイヤで管理する。プレイリストレイヤは、クリップの再生経路を指定するレイヤであり、１または複数のプレイリスト（Ｐｌａｙ Ｌｉｓｔ）を含む。プレイリストは、プレイアイテムの（ＰｌａｙＩｔｅｍ）の集合からなる。プレイアイテムには、クリップの再生範囲を示した一組のイン（Ｉｎ）点およびアウト（Ｏｕｔ）点が含まれており、プレイアイテムを連ねることによって、任意の順序でクリップを再生することができるようになる。プレイアイテムは、クリップを重複して指定することができる。クリップＡＶストリームファイルのイン点およびアウト点は、タイムスタンプ（クリップ内時刻）で指定され、タイムスタンプは、クリップインフォメーションファイルの情報によってクリップＡＶストリームファイル上のバイト位置に変換される。
プレイリストは、クリップの全部または一部を指すプレイアイテムを順序に従って再生していく構造だけを有しており、プレイリストのみを用いて再生順の分岐や、ユーザとの双方向性を実現することは、できない。
スクリプトレイヤは、言語仕様のＥＣＭＡスクリプトを拡張した、ＵＭＤビデオスクリプトによって構築されるレイヤである。ＵＭＤビデオスクリプトは、ＥＣＭＡスクリプトを基本として、ＵＭＤビデオに特有な機能を実現するための拡張を加えたスクリプトである。
スクリプトレイヤは、プレイリストレイヤの上位のレイヤであり、プレイリストの再生指示や、プレーヤ設定を行うコマンド列から構成される。スクリプトレイヤのコマンドにより、複数の言語用に用意されたストリームのうち何れを選択する、ある条件に従って選択されるプレイリストに再生の流れが変化する、というような、条件分岐を伴うプレイリスト再生を実現することができる。このような条件分岐を伴うプレイリスト再生が用いられるアプリケーションの例としては、マルチストーリーが挙げられる。このスクリプトレイヤにより、ユーザとの双方向性機能（インタラクティブ機能）が導入されることになる。
２−２．ＵＭＤビデオ規格のプレーヤモデルについて
次に、ＵＭＤビデオ規格に従ったデータを再生する再生装置（プレーヤ）のモデル、すなわち、プレーヤモデルについて説明する。プレーヤは、先ず、ディスクからスクリプトプログラム、プレイリストおよびクリップインフォメーションファイルを読み出し、次に、これらにより定められている再生順序に従って、クリップＡＶストリームファイルを読み出し、ビデオ、オーディオおよび字幕などを再生する。
スクリプトプログラムの言語仕様においては、プレイリストを再生する機能ブロックを、スクリプトプログラム内のオブジェクトとして実装する。このプレイリスト再生を行うオブジェクトを、ＵＭＤビデオ規格では、ムービープレーヤ（Ｍｏｖｉｅ Ｐｌａｙｅｒ）オブジェクトと呼ぶ。プレイリストの再生指示や、プレーヤ設定を行うコマンドは、このムービープレーヤオブジェクトが有するメソッドとなる。ムービープレーヤオブジェクトは、スクリプトレイヤからのメソッドによって制御される。このとき、ムービープレーヤオブジェクトからスクリプトレイヤに対して、状態の変化や再生位置などを通知する機能が必要となる。これは、ムービープレーヤオブジェクトがスクリプトプログラムに対してイベントを発することに対応し、そのイベントに対応した処理は、イベントハンドラとして記述される。
このように、ムービープレーヤオブジェクトからスクリプトプログラムへの情報伝達は、イベントにより行い、スクリプトプログラムからムービープレーヤオブジェクトに対する制御をメソッドにより行うモデルを構築することにより、クリップＡＶストリームの再生をスクリプトプログラムで制御できるようになる。
第３０図は、上述した、この実施の第２の形態による一例のプレーヤモデルを模式的に示す。ムービープレーヤ３００は、ＵＭＤビデオ規格においてビデオ、オーディオおよび字幕の再生を司るモジュールである。上述したムービープレーヤオブジェクトは、ムービーオブジェクトをスクリプトプログラムから操作するためにスクリプトプログラム内のオブジェクトとしたものである。換言すれば、ムービープレーヤオブジェクトは、ムービープレーヤの機能を実現するためのスクリプトプログラムそのものである。
なお、ムービープレーヤ３００とムービープレーヤオブジェクトは、実質的に同一の対象を表すと考えられるので、以下、これらを同一の符号を付して説明する。
第３０図において、ムービプレーヤ３００は、ユーザ入力３１０などにより引き起こされる下位レイヤ（第３０図の例ではネイティブ実装プラットフォーム３０１）や、上位レイヤであるスクリプトレイヤ３０２からのメソッドに従って、プレイリストおよびクリップインフォメーションのデータベースに基づき、クリップＡＶストリームファイルの読み出し、読み出されたクリップＡＶストリームのデコードおよび表示を行う。
ムービープレーヤオブジェクト３００の内部は、ＵＭＤビデオを再生するＵＭＤビデオプレーヤの実装に依存するものであって、スクリプトレイヤ３０２からは、ブラックボックス化されたオブジェクトとして、メソッドやプロパティといったＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が提供される。ここで、ＵＭＤビデオプレーヤは、ムービープレーヤを実装した実際の機器を指す。全てのＵＭＤビデオプレーヤは、ＵＭＤビデオ規格の制約を守ってムービープレーヤを実装しており、再生互換を有する。
第３０図に示されるように、ムービープレーヤオブジェクト３００は、ネイティブ実装プラットフォーム３０１からの制御コマンド３１１を受け付けるパス、スクリプトレイヤ３０２に対してイベント３１２を通知するパス、スクリプトレイヤ３０２からのメソッド３１３を受け付けるパスの、３本の入出力パスを有する。
制御コマンド３１１は、ネイティブ実装のプラットフォーム３０１からの、ムービープレーヤオブジェクト３００の動作を制御するコマンドである。ネイティブ実装プラットフォーム３０１は、例えば、実際の機器としてのＵＭＤビデオプレーヤにおける、機器に固有の部分とムービープレーヤ３００とのインターフェイスである。イベント３１２は、ムービープレーヤ３００からスクリプトレイヤ３０２に対するスクリプトイベントである。メソッド３１３は、スクリプトレイヤ３０２のスクリプトプログラムからムービープレーヤ３００に渡されるメソッドである。
ムービープレーヤオブジェクト３００は、内部に、ＵＭＤビデオ規格のプレイリストおよびクリップインフォメーションのデータベース３２０を有する。ムービープレーヤオブジェクト３００は、このデータベース３２０を用いて、ユーザ入力３１０に対するマスクや、時刻で指定された再生位置をクリップＡＶストリーム内のバイト位置に変換する処理などを行う。
ムービープレーヤオブジェクト３００内のプレイバックモジュール３２１は、ビデオ、オーディオおよび字幕が多重されたＭＰＥＧ２ＰＳ（Ｐｒｏｇｒａｍ Ｓｔｒｅａｍ）であるクリップＡＶストリームのデコードを行う。プレイバックモジュール３２１は、プレイ、ストップおよびポーズの３状態を持ち、制御命令やメソッドによって、この３状態の間を遷移する（第３１図参照）。
スクリプトレイヤ３０２は、ＵＭＤビデオスクリプト規格に基づくスクリプトプログラムを実行し、ムービープレーヤオブジェクト３００の制御や、画面表示を行うレイヤである。このスクリプトレイヤ３０２は、コンテンツ制作者側の意図したシナリオを実現する役割を果たす。スクリプトレイヤ３０２は、ムービープレーヤオブジェクト３００に対してメソッド３１３を発行し、ムービープレーヤオブジェクト３００からは、イベント３１２を受け取る。スクリプトレイヤ３０２は、ネイティブ実装プラットフォーム３０１との間で、ユーザ入力３１０に応じたキーイベント３１４や、画面描画などをネイティブ実装プラットフォーム３０１に対して指示するメソッド３１５などのやりとりを行う。
例えば、メニュー画面上に配置されるボタンは、スクリプトレイヤ３０２のスクリプトプログラムからネイティブ実装プラットフォーム３０１に渡されるメソッド３１５に基づき、ネイティブ実装プラットフォーム３０１により描画される。ユーザがそのボタンに対して選択操作を行ったときには、ユーザ入力３１０に応じたキーイベント３１４がネイティブ実装プラットフォーム３０１からスクリプトレイヤ３０２に通知され、スクリプトレイヤ３０２内のスクリプトプログラムは、キーイベント３１４に基づきキー入力３１０に応じた処理を行う。
なお、スクリプトプログラムとスクリプトプログラム内で使用する画像、音声などのデータは、ファイルとしてディスク上に記録される。このファイルは、第２５図Ａおよび第２５図Ｂで説明したファイルｓｃｅｎａｒｉｏ．ｈｄｍｖに相当する。
このように、ビデオ、オーディオおよび字幕のデコードや表示制御はムービープレーヤ３００が司り、ボタンなどのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を構成するための部品画像の配置や表示、ならびに、ＧＵＩ部品に対して選択操作がなされたときの処理は、スクリプトレイヤ３０２が行うというように、役割分担がなされている。
ネイティブ実装プラットフォーム３０１は、ムービープレーヤオブジェクト３００やスクリプトプログラムが動作するための基盤となるプラットフォームであって、例えば、実際のＵＭＤビデオプレーヤがハードウェアである場合、ハードウェアとプレーヤモデルとの間の処理を仲介する役割を果たすように、ハードウェアに固有に実装される。
例えば、ネイティブ実装プラットフォーム３０１は、ユーザからのユーザ入力３１０を受け付け、受け付けたユーザ入力３１０がムービープレーヤ３００に対する命令なのか、スクリプトレイヤ３０２で描画および表示しているボタンに対する命令なのかを判定する。ネイティブ実装プラットフォーム３０１は、ユーザ入力３１０がムービープレーヤ３００に対する命令であると判定されれば、ユーザ入力３１０をムービープレーヤ３００に対する内部制御命令である制御コマンド３１１に変換し、ムービープレーヤ３００に対して制御命令を発する。一方、ネイティブ実装プラットフォーム３０１は、ユーザ入力３１０がスクリプトレイヤ３０２で描画および表示しているＧＵＩ部品に対する命令であると判定されれば、ユーザ入力３１０に応じたキーイベント３１４をスクリプトレイヤ３０２に通知する。
次に、ムービープレーヤ３００についてより詳細に説明する。第３１図は、ムービープレーヤ３００の一例の内部構成を示す。上述したように、ムービープレーヤ３００は、データベース３２０およびプレイバックモジュール３２１とから構成される。データベース３２０は、ディスクから読み取ったプレイリストの情報と、クリップの情報すなわちクリップインフォメーションとを格納する領域である。
プレイバックモジュール３２１は、デコーダエンジン３２２と、プレイバックモジュール３２１の状態を表す値であるプロパティ３２３とからなる。プロパティ３２３は、例えば言語コードのように、ムービープレーヤ３００の初期設定で値が決まるプロパティ３２３Ａ（リードオンリーパラメータ）と、プレイバックモジュール３２１の状態によって値が変化するプロパティ３２３Ｂ（プレーヤステータス）の２種類がある。
初期設定で値が決まるプロパティ３２３Ａは、ネイティブなシステム、例えば実際の機器によって値がセットされ、プレイリストやクリップインフォメーション、スクリプトプログラムから値を変更されることがない。プロパティ３２３Ａは、スクリプトプログラムから値を読み出すことのみが可能とされる。一方、プレイバックモジュール３２１の状態を表すプロパティ３２３Ｂは、スクリプトプログラムから値を読み出すことができると共に、一部のスクリプトプログラムから値を書き込むことが可能とされる。
なお、この動作モデルにおいては、プレイリストおよびクリップインフォメーションは、クリップＡＶストリームの再生前にディスクからプリロードされていることを想定している。これに限らず、他の実装であっても、ムービープレーヤモデルで定めた動作を実現できていればよい。
ムービープレーヤオブジェクト３００は、スクリプトレイヤ３０２またはネイティブ実装プラットフォーム３０１からの指示に従い、指定されたプレイリストを再生する。例えば、ムービープレーヤ３００は、データベース３２０を参照し、指定されたプレイリストに対応するクリップＡＶストリームの再生位置をファイル中のバイト位置で得る。プレイバックモジュール３２１において、デコーダエンジン３２２は、この再生位置情報に基づき、クリップＡＶストリームのデコードを制御する。
ムービープレーヤ３００は、第３２図に示されるように、プレイリストの再生状況に応じてプレイ（ｐｌａｙ）、ストップ（ｓｔｏｐ）およびポーズ（ｐａｕｓｅ）の３状態を持つ。プレイ状態は、プレイリストの再生を行っており、時間が経過している状態を指す。通常再生の他、２倍速、１／２倍速といった変速再生や、早送りおよび巻き戻し（早戻し）もプレイ状態に含まれる。ポーズ状態は、プレイリストの再生を行っている状態で、時間軸が停止している状態である。再生をフレーム単位で進めたり戻したりする所謂コマ送り再生は、ポーズ状態とプレイ状態とを繰り返している状態である。ストップ状態は、プレイリストを再生していない状態である。
例えば、ムービープレーヤ３００の状態は、ムービープレーヤ３００内のデコーダエンジン３２２におけるプレイ、ポーズおよびストップの状態遷移に伴うもので、デコーダエンジン３２２の状態遷移に応じてプロパティ３２３Ｂの値が更新される。
リジュームインフォメーションは、ストップ状態直前の状態を記憶する。例えば、ムービープレーヤ３００があるプレイリストをデコードしプレイ状態となっているときに、状態がストップ状態に遷移すると、ストップ状態の直前の状態を記憶する。リジュームインフォメーションは、ハードウェアとしてのプレーヤが持つ不揮発性メモリに、ディスクのタイトル毎に識別可能なように複数を記憶させることができる。
２−３．ムービープレーヤのイベントモデルについて
ムービープレーヤ３００のイベントモデルについて説明する。ムービープレーヤ３００は、プレイリストを再生するプレイ状態で、様々なイベントを発生する。このイベントは、イベントハンドラと呼ばれる、スクリプトで記述された処理プログラムの実行を引き起こす。イベントハンドラは、イベント発生によって呼び出されるメソッドである。このイベント発生によって処理プログラムの実行を開始するプログラム実行モデルを、イベントドリブンモデルと呼ぶ。この実施の第２の形態においては、スクリプトプログラムは、イベントハンドラ群によってムービープレーヤオブジェクト３００の動作を制御する。
第３３図は、この発明の実施の第２の形態によるムービープレーヤ３００のイベントモデルを模式的に示す。第３３図において、イベントハンドラｏｎＥｖｅｎｔＡ（）、ｏｎＥｖｅｎｔＢ（）およびｏｎＥｖｅｎｔＣ（）は、インターフェイスであって、それぞれのイベントハンドラの内容は、スクリプトで記述されている。イベントハンドラの内容は、例えばコンテンツ制作者側で作成され実装される。ＵＭＤビデオスクリプト規格においては、ムービープレーヤオブジェクト３００からスクリプトプログラムに通知されるイベント毎に、イベントハンドラが用意される。第３３図の例では、イベントＡが発生したときに実行される処理プログラムは、イベントハンドラｏｎＥｖｅｎｔＡ（）に決められている。イベントＢおよびイベントＣについても同様に、イベントＢの発生時には対応するイベントハンドラｏｎＥｖｅｎｔＢ（）が実行され、イベントＣの発生時には対応するイベントハンドラｏｎＥｖｅｎｔＣ（）が実行される。
イベント発生に応じて呼び出されるイベントハンドラは、システム側で選択されるため、コンテンツ制作者側では、どのイベントが発生したかを判断する処理を、スクリプトプログラム内に記述しておく必要が無い。
この実施の第２の形態によるイベントモデルは、実施の第１の形態で第１５図を用いて既に説明した、イベント登録、イベント登録削除といった処理が必要なイベントリスナのモデルよりも簡単である。一方、どのようなイベントが発生しても一つのメソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）を呼び出すモデル（第２０図参照）では、どのイベントが発生したかを知り、イベント毎に用意してある処理ルーチンを切り替えるという前処理を、メソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）の中に記述しておく必要がある。メソッドｐｒｏｃｅｓｓＥｖｅｎｔ（）は、コンテンツ制作者側が実装するものであるから、モデルとしては簡単でも、コンテンツ制作者側の負担が大きくなる。さらに、大きな一つの処理プログラム（メソッド）がイベントの発生毎に呼ばれることになり、メモリの領域を多く占有し、実行速度も遅くなると考えられる。この発明の実施の第２の形態による、イベント毎に処理プログラム（イベントハンドラ）を用意するモデルでは、このような点について有利であるといえる。
２−４．ムービープレーヤオブジェクト３００について
次に、ムービープレーヤオブジェクト３００の外部的な仕様について説明する。一般に、ＥＣＭＡスクリプト言語仕様に従う言語により定義されたオブジェクトは、プロパティとメソッドとを持つ。この実施の第２の形態によるムービープレーヤオブジェクト３００も、第３１図および第３２図を用いて既に説明したように、同様にしてプロパティとメソッドとを有する。プロパティは、外部のオブジェクトから、対象となるオブジェクト名とプロパティ名とを指定することで、直接的に読み書きすることが可能である。これに限らず、プロパティ値の設定を行うメソッドｓｅｔＸＸＸ（）（「ＸＸＸ」は、対象のプロパティ名）や、プロパティ値の読み出しを行うメソッドｇｅｔＸＸＸ（）を定義することで、他のオブジェクトのプロパティの読み書きを、メソッドで行うことが可能となる。
この実施の第２の形態によるムービープレーヤオブジェクト３００のプロパティおよびメソッドは、実施の第１の形態において第７図〜第１２図を用いて既に説明したプロパティおよびメソッドと同一の仕様を適用できる。つまり、この実施の第２の形態において、スクリプトレイヤ３０２のスクリプトプログラムとムービープレーヤオブジェクト３００との間の仕様（ＡＰＩ）、すなわち、第３０図を用いて説明したメソッド３１３は、上述した実施の第１の形態においてＪａｖａで定義したクラスと同様に考えることができる。
一方、ユーザからのキー入力については、第３０図を用いて既に説明したように、ユーザ入力３１０をネイティブ実装プラットフォーム３０１が先ず、受け取る。つまり、ネイティブ実装プラットフォーム３０１は、ユーザからのキー入力をユーザ入力３１０として受け取り、ユーザ入力３１０がムービープレーヤ３００に対するコマンドなのか、スクリプトレイヤ３０２のスクリプトプログラムに対するイベントなのかを判定し、判定結果に応じて、制御コマンド３１１またはキーイベント３１４を発生し、対応する上位レイヤ（ムービープレーヤ３００またはスクリプトレイヤ３０２）に通知する。
ユーザ入力３１０は、例えば第２４図、ならびに、第２５図Ａおよび第２５図Ｂを用いて既に説明したキー入力である。ここで、第２４図に示されるキー入力に対応する機能と、第２５図Ａおよび第２５図Ｂに示されるキー入力に対応する機能とでは、役割が異なるため、通知先をネイティブ実装プラットフォーム３０１で振り分ける必要がある。
第２４図に示されるキー入力により、ビデオ、オーディオおよび字幕の再生に関する指示がなされる。ネイティブ実装プラットフォーム３０１は、ユーザ入力３１０として第２４図に示されるキー入力を受け取ると、受け取ったキー入力を第２１図Ａ、第２１図Ｂ、第２１図Ｃおよび第２１図Ｄで説明したようなコマンドに変換する。変換されたコマンドは、ムービープレーヤ３００に対する制御コマンド３１１として通知される。すなわち、第２１図Ａ、第２１図Ｂ、第２１図Ｃおよび第２１図Ｄを用いて説明したユーザ入力コマンドは、第３０図の制御コマンド３１１に対応する。
一方、第２５図Ａおよび第２５図Ｂに示されるキー入力は、ＧＵＩに対するユーザ入力３１０である。ネイティブ実装プラットフォーム３０１は、ユーザ入力３１０として第２５図Ａおよび第２５図Ｂに示されるキー入力を受け取ると、受け取ったキー入力をキーイベント３１４に変換し、スクリプトレイヤ３０２に通知する。
なお、上述した第２５図Ａおよび第２５図Ｂには、キーＶＫ＿ＡＮＧＬＥ、キーＶＫ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＧＲＡＰＨＩＣＳ、キーＶＫ＿ＡＵＤＩＯという、ストリーム切り替えに関するキー入力も含まれているが、これらは、スクリプトプログラムからムービープレーヤ３００に対するメソッドで実現されるようにしているので、スクリプトレイヤ３０２に伝えられるべきキー入力である。
２−５．ムービープレーヤオブジェクト３００でのイベントの扱いについて
Ｊａｖａ言語を用いた上述の実施の第１の形態では、第１４図Ａ、第１４図Ｂおよび第１４図Ｃのようなイベントを、オブジェクトＢＤＢａｓｉｃＰｌａｙｅｒが持つとしていた。そして、第１５図に示されるようなイベントリスナモデルに基づき、第１６図Ａおよび第１６図Ｂを用いて説明したようなメソッドで、リスナの登録や削除を行うようにしていた。この実施の第１の形態によるイベントリスナモデルでは、プログラム実行中に動的にリスナを登録および削除することができるようにされ、イベントへの応答処理をプログラムの途中で変更することが可能である。そのため、より自由度が高く、高度な機能を実現するプログラミングが可能である。
一方、この実施の第２の形態に適用されるＥＣＭＡスクリプトを元にしたスクリプト言語においては、リスナ登録および削除を行うことはせず、イベントに応じて、予め固定的に用意された処理プログラムが呼び出されるようにしている。実施の第１の形態におけるリスナに対応するインターフェイスは、ムービープレーヤオブジェクト３００のイベントハンドラである。イベントハンドラのモデルでは。第１６図Ａおよび第１６図Ｂに示されるようなリスナ登録に関連するメソッドは、不要となる。
この実施の第２の形態では、イベントそれぞれに対応して、第３４図Ａおよび第３４図Ｂに一例が示されるイベントハンドラが設けられる。イベントハンドラ名は、イベント名の先頭に「ｏｎ」を付加したものになる。この第３４図Ａおよび第３４図Ｂに一例が示されるイベントハンドラは、上述した実施の第１の形態において第１４図Ａ、第１４図Ｂおよび第１４図Ｃを用いて説明したイベントに対応するものである。
イベントハンドラｏｎＴｉｍｅｒＦｉｒｅｄ（）は、ムービープレーヤ３００におけるカウントダウンタイマの値が”０”になったか、あるいは、カウントアップタイマの値が指定の値になったときに発生されるイベントに対応する。これにより、あるタイミングにおける処理を実現できる。
イベントハンドラｏｎＰｌａｙＳｔｏｐｐｅｄ（）は、ムービープレーヤ３００における再生が停止された（ストップ）ときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＳｔｉｌｌｅｄ（）は、ムービープレーヤ３００における再生が一時停止された（ポーズ）ときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＳｔａｒｔｅｄ（）は、ムービープレーヤ３００における再生が開始された（スタート）ときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＲｅｐｅａｔｅｄ（）は、ムービープレーヤ３００における繰り返し再生時の先頭を検出したときに発生されるイベントに対応する。これらにより、デコーダエンジン３２２の状態に応じた処理を実現できる。
イベントハンドラｏｎＳＰＤｉｓｐｌａｙＳｔａｔｕｓＣｈａｎｇｅｄ（）は、ムービープレーヤ３００における字幕（サブピクチャ）のストリームの表示および非表示状態が変わったときに発生されるイベントに対応する。イベントハンドラｏｎＳｅｌｅｃｔｅｄＡｕｄｉｏＣｈａｎｇｅｄ（）は、ムービープレーヤ３００における再生するオーディオストリームが変わったときに発生されるイベントに対応する。イベントハンドラｏｎＶｉｄｅｏＳｔｏｐｐｅｄ（）は、ムービープレーヤ３００における再生するビデオストリームが変わったときに発生されるイベントに対応する。これらにより、再生されるストリームの変化に応じた処理を実現できる。
イベントハンドラｏｎＰｌａｙＬｉｓｔＳｔａｒｔｅｄ（）は、ムービープレーヤ３００におけるプレイリストの先頭を検出したときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＬｉｓｔＥｎｄｅｄは、ムービープレーヤ３００におけるプレイリストの終わりを検出したときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＩｔｅｍＳｔａｒｔｅｄ（）は、ムービープレーヤ３００におけるプレイアイテムの先頭を検出したときに発生されるイベントに対応する。イベントハンドラｏｎＰｌａｙＩｔｅｍＥｎｄｅｄ（）は、ムービープレーヤ３００におけるプレイアイテムの終わりを検出したときに発生されるイベントに対応する。プレイリストやプレイアイテムの連続的な再生など、プレイリストやプレイアイテムの再生開始や再生終了に応じた処理を実現できる。
イベントハンドラｏｎＭａｒｋＥｎｃｏｕｎｔｅｒｅｄ（）は、ムービープレーヤ３００における再生中に、プレイリスト中のマークを検出したときに発生されるイベントに対応する。プレイリスト中にある時刻を示すマークを予め設定しておくことで、再生中のプレイリストにおける分岐処理などが実現できる。
これらのイベントハンドラの内容は、コンテンツ制作者側がスクリプト言語により記述する。これにより、イベント発生時にコンテンツ制作者の意図する動作を実現することができる。
【図１】




【図４】

【図５】

【図６】

【図７】




【図９】

【図１０】

【図１１】

【図１２】

【図１３】




【図１５】



【図１７】

【図１８】


【図２０】





【図２２】

【図２３】

【図２４】



【図２６】

【図２７】




【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【特許請求の範囲】
【請求項１】
円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生装置において、
所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトと、
上記プレーヤオブジェクトの上位にあって、上記イベントの発生に対応した処理を記述可能なプログラムオブジェクトと
を有し、
上記プレーヤオブジェクトは、上記プログラムオブジェクトに記述された上記イベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生装置。
【請求項２】
請求の範囲１に記載の再生装置において、
上記プログラムオブジェクトは、上記記録媒体から再生される再生装置。
【請求項３】
請求の範囲１に記載の再生装置において、
上記プログラムオブジェクトが上記イベントの発生に対応した処理を上記プレーヤオブジェクトに登録することで、該イベントの発生に対応した処理が上記プレーヤオブジェクトで実行される再生装置。
【請求項４】
請求の範囲３に記載の再生装置において、
上記コンテンツデータの再生中に上記登録を行うことができるようにした再生装置。
【請求項５】
請求の範囲３に記載の再生装置において、
上記コンテンツデータの再生中に、上記登録された上記処理を削除できるようにした再生装置。
【請求項６】
請求の範囲１に記載の再生装置において、
上記所定の変化は、上記コンテンツデータの再生中の変化である再生装置。
【請求項７】
請求の範囲６に記載の再生装置において、
上記所定の変化は、上記コンテンツデータに設定された該コンテンツデータ内の時刻を表すマークの、再生中の検出である再生装置。
【請求項８】
請求の範囲１に記載の再生装置において、
ユーザの入力を受け付けて上記プレーヤオブジェクトに通知するユーザ入力手段をさらに有し、
上記所定の変化は、上記ユーザ入力手段に対する入力に基づく再生装置。
【請求項９】
請求の範囲８に記載の再生装置において、
上記ユーザ入力手段の物理キーに対して上記プログラムオブジェクトにより仮想キーが割り当てられ、上記所定の変化は、上記仮想キーに対する入力に基づく再生装置。
【請求項１０】
請求の範囲１に記載の再生装置において、
上記所定の変化は、プレーヤの状態遷移である再生装置。
【請求項１１】
請求の範囲１に記載の再生装置において、
上記イベントに基づく上記変化に応じて、１または複数のイベントがさらに発生できる再生装置。
【請求項１２】
請求の範囲１に記載の再生装置において
上記再生処理は、上記円盤状記録媒体から上記コンテンツデータを再生する際の再生制御と、上記円盤状記録媒体から再生された上記コンテンツデータに対する処理とを含む再生装置。
【請求項１３】
円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法において、
所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、上記プレーヤオブジェクトの上位にあって、上記イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述された上記イベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生方法。
【請求項１４】
円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法をコンピュータ装置に実行させる再生プログラムにおいて、
上記再生方法は、
所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、上記プレーヤオブジェクトの上位にあって、上記イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述された上記イベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした再生プログラム。
【請求項１５】
円盤状記録媒体に階層構造で記録されたコンテンツデータを再生する再生方法をコンピュータ装置に実行させる再生プログラムが記録されたコンピュータ装置に読み取り可能な記録媒体において、
上記再生方法は、
所定の変化に応じてイベントを発生させるように構成されたプレーヤオブジェクトにより、上記プレーヤオブジェクトの上位にあって、上記イベントの発生に対応した処理を記述可能なプログラムオブジェクトに記述された上記イベントの発生に対応した処理に基づき、円盤状記録媒体に階層構造で記録されたコンテンツデータの再生処理を制御するようにした記録媒体。
【請求項１６】
コンテンツデータが階層構造で記録された円盤状の形状を有する記録媒体において、
少なくともコンテンツデータと、イベントの発生に対応した処理を記述可能なプログラムオブジェクトとが記録され、
上記コンテンツデータの再生処理が、所定の変化に応じてイベントを発生させるように構成された、上記プログラムオブジェクトの下位にあるプレーヤオブジェクトによって、上記プログラムオブジェクトに記述された上記イベントの発生に対応した処理に基づき制御されるようにした記録媒体。
【請求項１７】
請求の範囲１６に記載の記録媒体において、
上記プログラムオブジェクトが上記イベントの発生に対応した処理を上記プレーヤオブジェクトに登録することで、該イベントの発生に対応した処理が上記プレーヤオブジェクトで実行される記録媒体。
【請求項１８】
請求の範囲１７に記載の記録媒体において、
上記プログラムオブジェクトは、上記コンテンツデータの再生中に上記登録を行うことができるようにした記録媒体。
【請求項１９】
請求の範囲１７に記載の記録媒体において、
上記プログラムオブジェクトは、上記コンテンツデータの再生中に、上記登録された上記処理を削除できるようにした記録媒体。
【請求項２０】
請求の範囲１６に記載の記録媒体において、
上記所定の変化は、上記コンテンツデータの再生中の変化である記録媒体。
【請求項２１】
請求の範囲２０に記載の記録媒体において、
上記所定の変化は、上記コンテンツデータに設定された、該コンテンツデータ内の時刻を表すマークに基づく記録媒体。
【請求項２２】
請求の範囲１６に記載の記録媒体において、
上記所定の変化は、ユーザ入力手段に対する入力に基づく記録媒体。
【請求項２３】
請求の範囲２２に記載の記録媒体において、
上記プログラムオブジェクトは、入力に基づき上記所定の変化を生じさせる仮想キーを、上記ユーザ入力手段の物理キーに対して割り当てる記録媒体。
【請求項２４】
請求の範囲１６に記載の記録媒体において、
上記所定の変化は、プレーヤの状態遷移である記録媒体。
【請求項２５】
請求の範囲１６に記載の記録媒体において、
上記イベントに基づく上記変化に応じて、１または複数のイベントがさらに発生できる記録媒体。
【請求項２６】
請求の範囲１６に記載の記録媒体において、
上記再生処理は、上記コンテンツデータを再生する際の再生制御と、再生された上記コンテンツデータに対する処理とを含む記録媒体。

【国際公開番号】ＷＯ２００５／０５２９４０
【国際公開日】平成１７年６月９日（２００５．６．９）
【発行日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願番号】特願２００５−５１５７３５（Ｐ２００５−５１５７３５）
【国際出願番号】ＰＣＴ／ＪＰ２００４／０１２２４３
【国際出願日】平成１６年８月１９日（２００４．８．１９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】