Warning: copy(.htaccess): failed to open stream: Permission denied in /home/jp321/public_html/header.php on line 8
宣言型言語で記述された再生制御環境の起動条件を考慮した情報記録媒体およびその再生装置、再生方法。 - 松下電器産業株式会社
米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 松下電器産業株式会社

発明の名称 宣言型言語で記述された再生制御環境の起動条件を考慮した情報記録媒体およびその再生装置、再生方法。
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−11899(P2007−11899A)
公開日 平成19年1月18日(2007.1.18)
出願番号 特願2005−194374(P2005−194374)
出願日 平成17年7月1日(2005.7.1)
代理人 【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
発明者 山口 高弘 / 平位 純一 / 鍵山 隆司 / 松永 繁樹 / 高松 隆一郎
要約 課題
映像データ用BD−ROMで新たにHTMLおよびスクリプトで記述したアプリケーションによる再生制御環境を導入するにあたって、通信サーバ上のHTMLファイルからディスク上のHTMLファイルへの文書遷移や、エラー時に提示するエラー画面を制作者が意図して構築できる仕組みが必要となる。

解決手段
起動種別毎の起動ファイル指定情報とコンテンツの構成情報と各ファイルのOffsetを記載したResource List Fileをアーカイブファイルに配置することで、復帰画面やエラー画面を容易にかつ短期間で提示することが可能である。
特許請求の範囲
【請求項1】
デジタルストリームを含む1つ以上のタイトルと、宣言型言語で記述された複数の文書からなるアプリケーションを記録する情報記録媒体であって、情報記録媒体上にない文書から、情報記録媒体上にある文書の起動を要求されたときに起動する外因起動文書が予め規定されていることを特徴とする情報記録媒体。
【請求項2】
デジタルストリームを含む1つ以上のタイトルと、宣言型言語で記述された複数の文書からなるアプリケーションを記録する情報記録媒体であって、エラーが発生したときに起動するエラー文書が予め規定されていることを特徴とする情報記録媒体。
【請求項3】
前記アプリケーションは、前記情報記録媒体から読出されてメモリ上に生存できる期間が予め規定されていることを特徴とする請求項1、もしくは、請求項2記載の情報記録媒体。
【請求項4】
前記期間は、タイトル毎に管理されることを特徴とする請求項3記載の情報記録媒体。
【請求項5】
前記アプリケーションは、ひとつのタイトルに帰属することを特徴とする請求項4記載の情報記録媒体。
【請求項6】
前記アプリケーションは、前記アプリケーションを構成する複数の文書と各文書が参照するデータをひとつにまとめたアーカイブファイルであることを特徴とする請求項5記載の情報記録媒体。
【請求項7】
前記アーカイブファイル毎に、前記外因起動文書が規定されていることを特徴とする請求項6記載の情報記録媒体。
【請求項8】
前記アーカイブファイル毎に、前記エラー文書が規定されていることを特徴とする請求項6記載の情報記録媒体。
【請求項9】
前記アーカイブファイルは、前記情報記録媒体に1ファイルとして記録されることを特徴とする請求項7、もしくは、請求項8記載の情報記録媒体。
【請求項10】
前記アーカイブファイル単位で、メモリ上に読出し、もしくは、メモリ上から破棄されることを特徴とする請求項9記載の情報記録媒体。
【請求項11】
前記アーカイブファイルの制作段階のディレクトリ構造情報を格納したリソースリストファイルを、アーカイブファイルにアーカイブすることを特徴とする請求項10記載の情報記録媒体。
【請求項12】
前記リソースリストファイルは、前記アーカイブファイルの先頭に配置することを特徴とする請求項11記載の情報記録媒体。
【請求項13】
前記リソースリストファイルに、前記外因起動文書の規定を記載することを特徴とする請求項11、もしくは、請求項12記載の情報記録媒体。
【請求項14】
前記リソースリストファイルに、前記エラー文書の規定を記載することを特徴とする請求項11、もしくは、請求項12記載の情報記録媒体。
【請求項15】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行う再生装置であって、記録媒体に記録されたデジタルストリームを再生するストリーム再生部と、記録媒体に記録された複数の文書の内の1つを読出し、実行する文書実行部と、を備え、前記文書実行部は、アプリケーションに含まれない文書からアプリケーション内の文書への遷移要求を受け付けると、予め規定された外因起動文書を読出して、実行することを特徴とする再生装置。
【請求項16】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行う再生装置であって、記録媒体に記録されたデジタルストリームを再生するストリーム再生部と、記録媒体に記録された複数の文書の内の1つを読出し、実行する文書実行部と、を備え、前記文書実行部は、エラーが発生すると、予め規定されたエラー文書を読出して、実行することを特徴とする再生装置。
【請求項17】
前記文書実行部は、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリに読込むことを特徴とする請求項15、もしくは、請求項16記載の再生装置。
【請求項18】
前記文書実行部は、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリから破棄することを特徴とする請求項15、もしくは、請求項16記載の再生装置。
【請求項19】
前記文書実行部は、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載から外因起動文書を特定することを特徴とする請求項17、もしくは、請求項18記載の再生装置。
【請求項20】
前記文書実行部は、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載からエラー文書を特定することを特徴とする請求項17、もしくは、請求項18記載の再生装置。
【請求項21】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行わせるプログラムであって、 アプリケーションに含まれない文書からアプリケーション内の文書への遷移要求を受け付けると、予め規定された外因起動文書を読出して、実行することを特徴とするプログラム。
【請求項22】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行わせるプログラムであって、エラーが発生すると、予め規定されたエラー文書を読出して、実行することを特徴とするプログラム。
【請求項23】
前記プログラムは、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリに読込む制御をコンピュータに行わせることを特徴とする請求項21、もしくは、請求項22記載のプログラム。
【請求項24】
前記プログラムは、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリから破棄する制御をコンピュータに行わせることを特徴とする請求項21、もしくは、請求項22記載のプログラム。
【請求項25】
前記プログラムは、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載から外因起動文書を特定することを特徴とする請求項23、もしくは、請求項24記載のプログラム。
【請求項26】
前記プログラムは、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載からエラー文書を特定することを特徴とする請求項23、もしくは、請求項24記載のプログラム。
【請求項27】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行う再生方法であって、記録媒体に記録されたデジタルストリームを再生するストリーム再生ステップと、記録媒体に記録された複数の文書の内の1つを読出し、実行する文書実行ステップと、を含み、前記文書実行ステップは、アプリケーションに含まれない文書からアプリケーション内の文書への遷移要求を受け付けると、予め規定された外因起動文書を読出して、実行することを特徴とする再生方法。
【請求項28】
記録媒体に記録されたデジタルストリームの再生と、それぞれ宣言型言語で記述された複数の文書から構成されるアプリケーションの実行を同時に行う再生方法であって、記録媒体に記録されたデジタルストリームを再生するストリーム再生ステップと、記録媒体に記録された複数の文書の内の1つを読出し、実行する文書実行ステップと、を含み、前記文書実行ステップは、エラーが発生すると、予め規定されたエラー文書を読出して、実行することを特徴とする再生方法。
【請求項29】
前記文書実行ステップは、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリに読込む制御をコンピュータに行わせることを特徴とする請求項27、もしくは、請求項28記載の再生方法。
【請求項30】
前記文書実行ステップは、アプリケーションを構成する複数の文書と文書が参照するデータがアーカイブされたアーカイブファイル単位で、メモリから破棄する制御をコンピュータに行わせることを特徴とする請求項27、もしくは、請求項28記載の再生方法。
【請求項31】
前記文書実行ステップは、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載から外因起動文書を特定することを特徴とする請求項29、もしくは、請求項30記載のプログラム。
【請求項32】
前記文書実行ステップは、前記アーカイブファイルのディレクトリ構造情報を格納するリソースリストファイルの記載からエラー文書を特定することを特徴とする請求項29、もしくは、請求項30記載のプログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、BD−ROM等、映像データを記録した情報記録媒体、その再生装置及び再生方法に関し、特に、映像データとプログラムとを含むコンテンツの開発にプログラミング環境を導入する場合の改良に関する。
【背景技術】
【0002】
映像データを記録した情報記録媒体の代表格は、DVD(以下、SD−DVDまたは単にDVDと称する)である。以降、従来のDVDについて説明する。
【0003】
図1は、SD−DVDの構造を示した図である。図1の下段に示すように、DVDディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられ、論理アドレス空間の先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。
【0004】
ファイルシステムとは、ISO9660やUDF(Universal Disc Format)のことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。日常使っているPC(パーソナルコンピュータ)の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。 SD−DVDの場合、UDF及びISO9660両方を使用しており(両方を合わせて「UDFブリッジ」と呼ぶ事がある)、UDFまたはISO9660どちらのファイルシステムドライバによってもデータの読み出し(ここで取り扱うDVDはパッケージメディア用のROMディスクであり、物理的に書き込みが不可能である)ができるようになっている。
【0005】
DVD上に記録されたデータは、UDFブリッジを通して、図1左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ(図中「ROOT」)の直下に「VIDEO_TS」と呼ばれるディレクトリが置かれ、ここにDVDのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下のものがある。
【0006】
VIDEO_TS.IFO ディスク再生制御情報ファイル
VTS_01_0.IFO ビデオタイトルセット#1再生制御情報ファイル
VTS_01_0.VOB ビデオタイトルセット#1ストリームファイル
.....
拡張子として2つの種類が存在する。「IFO」は再生制御情報が記録されたファイルであって、「VOB」はAVデータであるMPEGストリームが記録されたファイルである。再生制御情報とは、DVDで採用されたインタラクティビティ(ユーザの操作に応じて再生を動的に変化させる技術)を実現するための情報や、メタデータのようなタイトルやAVストリームに付属する情報などのことである。また、DVDでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。
【0007】
再生制御情報ファイルは、ディスク全体を管理する「VIDEO_TS.IFO」と、個々のビデオタイトルセット(DVDでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を1枚のディスクに記録することが可能である。)毎の再生制御情報である「VTS_01_0.IFO」がある。ここで、ファイル名ボディにある「01」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット#2の場合は、「VTS_02_0.IFO」となる。
【0008】
図1の右上部は、DVDのアプリケーション層でのDVDナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「VIDEO_TS.IFO」内の情報は、VMGI(VIDEO Manager Information)として、「VTS_01_0.IFO」または、他のビデオタイトルセット毎に存在する再生制御情報はVTSI(Video Title Set Information)としてDVDナビゲーション空間に展開される。
【0009】
VTSIの中にはPGC(Program Chain)と呼ばれる再生シーケンスの情報であるPGCI(Program Chain Information)が記述されている。PGCIは、Cellの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Cell自身はVOB(Video Objectの略であり、MPEGストリームを指す)の一部区間または全部区間の集合であり、Cellの再生は、当該VOBのCellによって指定された区間を再生することを意味している。
【0010】
コマンドは、DVDの仮想マシンによって処理されるものであり、ブラウザ上で実行されるJava(登録商標)スクリプトなどに近いものである。しかしながらJava(登録商標)スクリプトが論理演算の他にウィンドウやブラウザの制御(例えば、新しいブラウザのウィンドを開くなど)を行うのに対して、DVDのコマンドは、論理演算の他にAVタイトルの再生制御、例えば、再生するチャプタの指定などを実行するだけのものである点で異なっている。
【0011】
Cellはディスク上に記録されているVOBの開始及び終了アドレス(論理アドレス)をその内部情報として有しており、プレーヤは、Cellに記述されたVOBの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。
【0012】
図1はAVストリーム中に埋め込まれているナビゲーション情報を説明する概略図である。SD−DVDの特長であるインタラクティビティは前述した「VIDEO_TS.IFO」や「VTS_01_0.IFO」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック(ナビパックまたは、NV_PCKと称する)と呼ばれる専用キャリアを使いVOB内に映像、音声データと一緒に多重化されている。
【0013】
ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には、幾つかのボタンが現れ、夫々のボタンには当該ボタンが選択実行された時の処理が定義されている。また、メニュー上では一つのボタンが選択されており(ハイライトによって選択ボタン上に半透明色がオーバーレイされている)、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることができる。リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する(決定キーを押す)ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプタの再生がコマンドによって実行されている。
【0014】
図2の左上部はNV_PCK内の概要を示している。
NV_PCK内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報(ユーザの上下左右キー操作夫々に対応する移動先ボタンの指定)と、ボタンコマンド情報(当該ボタンが決定された時に実行されるコマンド)が記述されている。
【0015】
メニュー上のハイライトは、図2の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色をつけた物である。このオーバーレイ画像は右部に示す背景画像と合成されて画面上に表示される。
【0016】
上述のようにして、DVDではメニューを実現している。また、何故、ナビゲーションデータの一部をNV_PCKを使ってストリーム中に埋め込んでいるのは、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中5分〜10分の間にだけメニューが表示されるなど、同期タイミングが問題となりやすいアプリケーションの場合でも、問題なく実現できるようにしたためである。
【0017】
図3は、DVDのVOBのイメージである。図に示すように、映像、音声、字幕などのデータ(A段)は、MPEGシステム(ISO/IEC13818−1)規格に基づいて、パケット及びパック化し(B段)、夫々を多重化して1本のMPEGプログラムストリームにしている(C段)。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだNV_PCKも一緒に多重化をされている。
【0018】
MPEGシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。これはMPEGシステムストリームのデコーダモデル(一般にSystem Target Decoder、またはSTDと呼ばれる(図3のD段))が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。このデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、232kB、音声に対しては4kB、字幕に対しては52kBを夫々有している。このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、MPEGシステムストリームとしてビット列を形成する順番と表示(デコード)されるタイミングにずれが生じている。
【0019】
即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。
【0020】
かかるDVDの構成は、以下の特許文献1に記載されている。
【特許文献1】特許第2813245号
【発明の開示】
【発明が解決しようとする課題】
【0021】
ディスク外のHTMLファイルを提示している状態から、ディスク上のHTMLファイルへ文書遷移できなかった。また、文書遷移の際、次に提示するHTMLファイルの取得に失敗など、エラーが発生すると、既存HTMLブラウザは独自のエラー画面を提示する。そのため、制作者の意図した動作(例:一貫したデザインをエラー画面に適用したり、エラー後も継続してAVを再生するなど)を実現できなかった。
【課題を解決するための手段】
【0022】
一連の動作に関連するHTMLファイル、イメージファイルをまとめてコンテンツと呼び、起動、終了の単位として管理する。
【0023】
コンテンツは、複数のHTMLファイル、イメージファイル等のリソースをHTTP/1.1のエンティティ形式やZIP形式等で、アーカイブした1ファイルとして、ディスク上に配置し、コンテンツ内でのディレクトリ構造を実現するため、論理ツリー情報とファイル名、ファイルサイズ、Offset値を格納するリソースリストファイルを、コンテンツファイルの先頭に配置する。
【0024】
このリソースリストファイルの基本情報として、通常起動用HTMLファイル、ディスク外からディスク上のHTMLファイルへの文書遷移要求時に提示すべきHTMLファイル、エラー発生時に提示すべきHTMLファイル等の起動種別HTML指定を可能とする。
【0025】
以上の仕組みにより、通常起動時、ディスク外からの文書遷移要求時、エラー発生時に、指定されたHTMLファイルを起動する。
【発明の効果】
【0026】
ネット上のHTMLファイルなど、ディスク外のHTMLファイル提示状態から、ディスク上のHTMLファイルへ遷移した場合に、元の画面提示状態や、ゲームなどの進捗状態を反映した画面を提示できる。また、通信サーバ上のHTML取得失敗など、エラー発生時に、制作者の意図に従って、エラーに対応した画面を提示したり、継続してAVを再生することができる。
【発明を実施するための最良の形態】
【0027】
(実施例1)
まず最初に本発明の第1の実施の形態について説明する。
(ディスク上の論理データ構造)
図4は、BD−ROM(以降、「BD」と称する場合もある)の構成、特にディスク媒体であるBDディスク(104)と、ディスクに記録されているデータ(101、102、103)の構成を示す図である。BDディスク(104)に記録されるデータは、AVデータ(103)と、AVデータに関する管理情報及びAV再生シーケンスなどのBD管理情報(102)と、インタラクティブを実現するBD再生プログラム(101)である。本実施の形態では、映画などのAVコンテンツを再生するためのAVアプリケーションを主眼においてのBDディスクの説明を行うが、BDディスクをCD−ROMやDVD−ROMの様にコンピュータ用途の記録媒体としてしようすることも当然のことながら可能である。
【0028】
図5は、上述したBDディスクに記録されている論理データを示した図である。BDディスクは、他の光ディスク、例えばDVDやCDなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはBCA(Burst Cutting Area)と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
【0029】
論理アドレス空間には、ファイルシステム情報(ボリューム)を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、UDFやISO9660などのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【0030】
本実施例の場合、BDディスク上のディレクトリ、ファイル構造は、ルートディレクトリ(ROOT)直下にBDVIDEOディレクトリが置かれている。このディレクトリはBD−ROMで扱うAVコンテンツや管理情報などのデータ(図4で説明した101、102、103)が記録されているディレクトリである。
【0031】
BDVIDEOディレクトリの下には、次の7種類のファイルが記録されている。
BD.INFO(ファイル名固定)
「BD管理情報」の一つであり、BDディスク全体に関する情報を記録したファイルである。BDプレーヤは最初にこのファイルを読み出す。
【0032】
BD.PROG(ファイル名固定)
「BD再生プログラム」の一つであり、BDディスク全体に関わるプログラムを記録したファイルである。
【0033】
XXX.PL(「XXX」は可変、拡張子「PL」は固定)
「BD管理情報」の一つであり、シナリオを記録するプレイリスト(Play List)情報を記録したファイルである。プレイリスト毎に1つのファイルを持っている。
【0034】
XXX.PROG(「XXX」は可変、拡張子「PL」は固定)
「BD再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名(「XXX」が一致する)によって識別される。
【0035】
YYY.VOB(「YYY」は可変、拡張子「VOB」は固定)
「AVデータ」の一つであり、VOB(従来例で説明したVOBと同じ)を記録したファイルである。VOB毎に1つのファイルを持っている。
【0036】
YYY.VOBI(「YYY」は可変、拡張子「VOBI」は固定)
「BD管理情報」の一つであり、AVデータであるVOBに関わる管理情報を記録したファイルである。VOBとの対応はファイルボディ名(「YYY」が一致する)によって識別される。
【0037】
ZZZ.PNG(「ZZZ」は可変、拡張子「PNG」は固定)
「AVデータ」の一つであり、字幕及びメニューを構成するためのイメージデータPNG(W3Cによって標準化された画像フォーマットであり「ピング」と読む)を記録したファイルである。1つのPNGイメージ毎に1つのファイルを持つ。
【0038】
(プレーヤの構成)
次に、前述したBDディスクを再生するプレーヤの構成について図6及び図7を用いて説明する。
【0039】
図6は、プレーヤの大まかな機能構成を示すブロック図である。
BDディスク(201)上のデータは、光ピックアップ(202)を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに記録される。BD再生プログラム(「BD.PROG」または「XXX.PROG」ファイルの中身)はプログラム記録メモリ(203)に、BD管理情報(「BD.INFO」、「XXX.PL」または「YYY.VOBI」)は管理情報記録メモリ(204)に、AVデータ(「YYY.VOB」または「ZZZ.PNG」)はAV記録メモリ(205)に夫々記録される。
【0040】
プログラム記録メモリ(203)に記録されたBD再生プログラムはプログラム処理部(206)によって、管理情報記録メモリ(204)に記録されたBD管理情報は管理情報処理部(207)によって、また、AV記録メモリ(205)に記録されたAVデータはプレゼンテーション処理部(208)によって夫々処理される。
【0041】
プログラム処理部(206)は、管理情報処理部(207)より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部(207)に対してプレイリストの再生命令を送ることで実現する
。プログラム処理部(206)は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
【0042】
管理情報処理部(207)は、プログラム処理部(206)の指示を受け、対応するプレイリスト及びプレイリストに対応したVOBの管理情報を解析し、プレゼンテーション処理部(208)に対象となるAVデータの再生を指示する。また、管理情報処理部(207)は、プレゼンテーション処理部(208)より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部(208)にAVデータ再生の停止指示を行い、また、プログラム処理部(206)に対してプログラム実行タイミングを示すイベントを生成する。
【0043】
プレゼンテーション処理部(208)は、映像、音声、字幕/イメージ夫々に対応するデコーダを持ち、管理情報処理部(207)からの指示に従い、AVデータのデコード及び出力を行う。映像データ及び字幕/イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン(210)及びイメージプレーン(209)に描画され、合成処理部(211)によって映像の合成処理が行われTVなどの表示デバイスへ出力される。
【0044】
図6で示すように、BDプレーヤは図4で示したBDディスクに記録されているデータ構成に基づいた構成をとっている。
【0045】
図7は前述したプレーヤ構成を詳細化したブロック図である。図7では、AV記録メモリ(205)はイメージメモリ(308)とトラックバッファ(309)に、プログラム処理部(206)はプログラムプロセッサ(302)とUOPマネージャ(303)に、管理情報処理部(207)はシナリオプロセッサ(305)とプレゼンテーションコントローラ(306)に、プレゼンテーション処理部(208)はクロック(307)、デマルチプレクサ(310)、イメージプロセッサ(311)、ビデオプロセッサ(312)とサウンドプロセッサ(313)に夫々対応/展開している。
【0046】
BDディスク(201)から読み出されたVOBデータ(MPEGストリーム)はトラックバッファ(309)に、イメージデータ(PNG)はイメージメモリ(308)に夫々記録される。デマルチプレクサ(310)がクロック(307)の時刻に基づき、トラックバッファ(309)に記録されたVOBデータを抜き出し、映像データをビデオプロセッサ(312)に音声データをサウンドプロセッサ(313)に夫々送り込む。ビデオプロセッサ(312)及びサウンドプロセッサ(313)は夫々MPEGシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ(310)から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック(307)に従い個々のデコーダでデコード処理される。
【0047】
イメージメモリ(308)に記録されたPNGは、次の2つの処理方法がある。イメージデータが字幕用の場合は、プレゼンテーションコントローラ(306)によってデコードタイミングが指示される。クロック(307)からの時刻情報をシナリオプロセッサ(305)が一旦受け、適切な字幕表示が行えるように、字幕表示時刻(開始及び終了)になればプレゼンテーションコントローラ(306)に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ(306)からデコード/表示の指示を受けたイメージプロセッサ(311)は対応するPNGデータをイメージメモリ(308)から抜き出し、デコードし、イメージプレーン(314)に描画する。
【0048】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ(302)によってデコードタイミングが指示される。プログラムプロセッサ(302)が何時イメージのデコードを指示するかは、プログラムプロセッサ(302)が処理しているBDプログラムに因るものであって一概には決まらない。
【0049】
イメージデータ及び映像データは、図6で説明したように夫々デコード後にイメージプレーン(314)、ビデオプレーン(315)に記録され、合成処理部(316)によって合成出力される。
【0050】
BDディスク(201)から読み出された管理情報(シナリオ、AV管理情報)は、管理情報記録メモリ(304)に記録されるが、シナリオ情報(「BD.INFO」及び「XXX.PL」)はシナリオプロセッサ(305)によって読み出され処理される。また、AV管理情報(「YYY.VOBI」)はプレゼンテーションコントローラ(306)によって読み出され処理される。
【0051】
シナリオプロセッサ(305)は、プレイリストの情報を解析し、プレイリストによって参照されているVOBとその再生位置をプレゼンテーションコントローラ(306)に指示し、プレゼンテーションコントローラ(306)は対象となるVOBの管理情報(「YYY.VOBI」)を解析して、対象となるVOBを読み出すようにドライブコントローラ(317)に指示を出す。
【0052】
ドライブコントローラ(317)はプレゼンテーションコントローラ(306)の指示に従い、光ピックアップを移動させ、対象となるAVデータの読み出しを行う。読み出されたAVデータは、前述したようにイメージメモリ(308)またはトラックバッファ(309)に記録される。
【0053】
また、シナリオプロセッサ(305)は、クロック(307)の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ(302)に投げる。
【0054】
プログラム記録メモリ(301)に記録されたBDプログラム(「BD.PROG」または「XXX.PROG」)は、プログラムプロセッサ302によって実行処理される。プログラムプロセッサ(302)がBDプログラムを処理するのは、シナリオプロセッサ(305)からイベントが送られてきた場合か、UOPマネージャ(303)からイベントが送られたきた場合である。UOPマネージャ(303)は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ(302)にイベントを生成する。
【0055】
(アプリケーション空間)
図8は、BD−ROMのアプリケーション空間をを示す図である。
【0056】
BD−ROMのアプリケーション空間では、プレイリスト(PlayList)が一つの再生単位になっている。プレイリストはセル(Cell)の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。BD−ROMの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択することである。
【0057】
ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【0058】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図7で説明したシナリオプロセッサ(305)からプログラムプロセッサ(302)に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ(302)はIDによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【0059】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく2つのタイプに分けられる。一つ目は、カーソルキー(「上」「下」「左」「右」キー)または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり(プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている)、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【0060】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、DVDのメニューコール(タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する)を実装することができる。
【0061】
プレイリストで静的シナリオを構成する単位であるセル(Cell)はVOB(MPEGストリーム)の全部または一部の再生区間を参照したものである。セルはVOB内の再生区間を開始、終了時刻の情報として持っている。個々のVOBと一対になっているVOB管理情報(VOBI)は、その内部にタイムマップ(Time MapまたはTM)を有しており、このタイムマップによって前述したVOBの再生、終了時刻をVOB内(即ち対象となるファイル「YYY.VOB」内)での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【0062】
(VOBの詳細)
図9は、本実施例で使用するMPEGストリーム(VOB)の構成図である。図9に示すように、VOBは複数のVOBU(Video Object Unit)によって構成されている。VOBUは、MPEGビデオストリームで言うGOP(Group Of Pictures)を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。VOBUは0.4秒から1.0秒の時間を持ち、通常は0.5秒の再生時間を持っている。これはMPEGのGOPの構造が通常は15フレーム/秒(NTSCの場合)によって導かれるものである。
【0063】
VOBUは、その内部にビデオパック(V_PCK)とオーディオパック(A_PCK)を有している。各パックは1セクタ、本実施例の場合は2kB単位で構成されている。
【0064】
図10は、パックの構成を示した図である。
図10に示すように、ビデオデータ及びオーディオデータといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ1つのパケットを構成する。パケットヘッダには、ペイロードに格納してあるデータがどのストリームなのか、ビデオなのかオーディオなのか、また、ビデオまたはオーディオが夫々複数ストリームある場合は、どのストリームのデータなのかを識別するためのID(stream_id)と、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプDTS及びPTSが夫々記録されている。PTS/DTSは必ずしも全てのパケットヘッダに記録されている訳ではなく、MPEGによって記録するルールが規定されている。ルールの詳細についてはMPEGシステム(ISO/IEC13818−1)規格書に記述されているので省略する。
【0065】
パケットには更にヘッダ(パックヘッダ)が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプSCR(System Clock Reference)が記録されている。
【0066】
(VOBのインターリーブ記録)
次に図11及び図12を用いてVOBファイルのインターリーブ記録について説明する。
【0067】
図11上段は、前述したプレーヤ構成図の一部である。図の通り、BDディスク上のデータは、光ピックアップを通してVOB即ちMPEGストリームであればトラックバッファへ入力され、PNG即ちイメージデータであればイメージメモリへと入力される。
【0068】
トラックバッファはFIFOであり、入力されたVOBのデータは入力された順にデマルチプレクサへと送られる。この時、前述したSCRに従って個々のパックはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。
【0069】
図11下段は、BDディスク上でのVOBファイル及びPNGファイルのインターリーブ記録を示す図である。一般的にROM、例えばCD−ROMやDVD−ROMの場合、一連の連続再生単位となるAVデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。BD−ROMの場合も同様に、VOBファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにVOBに記録されている映像データと同期して再生されるデータがあり、VOBファイルと同様に字幕データも何らかの方法によってBDディスクから読み出す事が必要になる。
【0070】
字幕データの読み出し方法の一手段として、VOBの再生開始前に一まとめで字幕用のイメージデータ(PNGファイル)を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、非現実的である。
【0071】
そこで、本実施の形態では、VOBファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図11下段はそのインターリーブ記録を説明した図である。VOBファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、VOBデータの読み込みは当然のことながら停止することになる。
【0072】
図12は、この問題を解決するトラックバッファを使ったVOBデータ連続供給モデルを説明する図である。
【0073】
既に説明したように、VOBのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レートとトラックバッファからのデータ出力レートの間に差を設けると、BDディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。ここでトラックバッファへの入力レートをVa、トラックバッファからの出力レートをVbとする。図12の上段に記すようにVOBの一連続記録領域が論理アドレスの”a1”から”a2”まで続くとする。”a2”から”a3”の間は、イメージデータが記録されていて、VOBデータの読み出しが行えない区間であるとする。
【0074】
図12の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”t1”がVOBの一連続記録領域の開始点である”a1”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートVa−Vbでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”t2”は一連続記録領域の終了点である”a2”のデータを読み込む時刻である。即ち時刻”t1”から”t2”の間レートVa−Vbでトラックバッファ内はデータ量が増加していき、時刻”t2”でのデータ蓄積量はB(t2)は下式によって求めることができる。
【0075】
B(t2) = (Va−Vb)×(t2−t1) (式1)
この後、BDディスク上のアドレス”a3”まではイメージデータが続くため、トラックバッファへの入力は0となり、出力レートである”−Vb”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”a3”まで、時刻でいう”t3”までになる。
【0076】
ここで大事なことは、時刻”t3”より前にトラックバッファに蓄積されているデータ量が0になると、デコーダへ供給するVOBのデータが無くなってしまい、VOBの再生がストップしてしまう可能性がある。しかしながら、時刻”t3”でトラックバッファにデータが残っている場合には、VOBの再生がストップすることなく連続できることを意味している。
【0077】
この条件は下式によって示すことができる。
B(t2) ≧ −Vb×(t3−t2) (式2)
即ち、式2を満たすようにイメージデータの配置を決めればよい事になる。
【0078】
(ナビゲーションデータ構造)
図13から図19を用いて、BD−ROMのナビゲーションデータ(BD管理情報)構造について説明をする。図13は、VOB管理情報情報ファイル(”YYY.VOBI”)の内部構造を示した図である。
【0079】
VOB管理情報は、当該VOBのストリーム属性情報(Attribute)とタイムマップ(TMAP)を有している。ストリーム属性は、ビデオ属性(Video)、オーディオ属性(Audio#0〜Audio#m)個々に持つ構成となっている。特にオーディオストリームの場合は、VOBが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数(Number)によって、データフィールドの有無を示している。
【0080】
下記はビデオ属性(Video)の持つフィールドと夫々が持ち得る値である。
圧縮方式(Coding):
MPEG1
MPEG2
MPEG4
解像度(Resolution):
1920x1080
1280x720
720x480
720x565
アスペクト比(Aspect)
4:3
16:9
フレームレート(Framerate)
60
59.94
50
30
29.97
25
24
下記はオーディオ属性(Audio)の持つフィールドと夫々が持ち得る値である。
【0081】
圧縮方式(Coding):
AC3
MPEG1
MPEG2
LPCM
チャンネル数(Ch):
1〜8
言語属性(Language):
タイムマップ(TMAP)はVOBU毎の情報を持つテーブルであって、当該VOBが有するVOBU数(Number)と各VOBU情報(VOBU#1〜VOBU#n)を持つ。個々のVOBU情報は、VOBUの再生時間長(Duration)とVOBUのデータサイズ(Size)を夫々有している。
【0082】
図14はVOBU情報の詳細を説明する図である。
広く知られているように、MPEGストリームは時間的側面とデータサイズとしての側面との2つを有している。例えば、音声の圧縮規格であるAC3は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は1次式によって求めることができる。しかしながらMPEGビデオデータの場合は、個々のフレームは固定の表示時間、例えばNTSCの場合は1フレームは1/29.97秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるI/P/Bピクチャによってデータサイズは大きく変わってくる。従って、MPEGビデオの場合は、時間とアドレスの関係は一般式の形で表現することは不可能である。
【0083】
当然の事として、MPEGビデオデータを多重化しているMPEGシステムストリーム、即ちVOBも時間とデータとを一般式の形で表現することは不可能である。これに代わって、VOB内での時間とアドレスとの関係を結びつけるのがタイムマップ(TMAP)である。図14に示すように、各VOBU毎にVOBU内のフレーム数と、VOBU内のパック数を夫々エントリーとして持つテーブルがタイムマップ(TMAP)である。
【0084】
図15を使って、タイムマップ(TMAP)の使い方を説明する。
図15に示すように時刻情報が与えられた場合、先ずは当該時刻がどのVOBUに属するのかを検索する。これは、タイム亜マップのVOBU毎のフレーム数を加算して行き、フレーム数の和が当該時刻を(フレーム数に換算して)超えるまたは一致するVOBUが当該VOBUになる。次にタイムマップのVOBU毎のサイズを当該VOBUの直前のVOBUまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレスになっている。
【0085】
次に図16を使って、プレイリスト情報(”XXX.PL”)の内部構造を説明する。
プレイリスト情報は、セルリスト(CellList)とイベントリスト(EventList)から構成されている。
【0086】
セルリスト(CellList)は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト(CellList)の中身は、セルの数(Number)と各セル情報(Cell#1〜Cell#n)である。
【0087】
セル情報(Cell#)は、VOBファイル名(VOBName)、当該VOB内での有効区間開始時刻(In)及び有効区間終了時刻(Out)と、字幕テーブル(SubtitleTable)を持っている。有効区間開始時刻(In)及び有効区間終了時刻(Out)は、夫々当該VOB内でのフレーム番号で表現され、前述したタイムマップ(TMAP)を使うことによって再生に必要なVOBデータのアドレスを得る事ができる。
【0088】
字幕テーブル(SubtitleTable)は、当該VOBと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル(SubtitleTable)最初の情報も言語数(Number)とそれに続く個々の言語ごとのテーブル(Language#1〜Language#k)から構成されている。
【0089】
各言語のテーブル(Language#)は、言語情報(Language)と、個々に表示される字幕の字幕情報数(Number)と、個々に表示される字幕の字幕情報(Speech#1〜Speech#j)から構成され、字幕情報(Speech#)は対応するイメージデータファイル名(Name)、字幕表示開始時刻(In)及び字幕表示終了時刻(Out)と、字幕の表示位置(Position)から構成されている。
【0090】
イベントリスト(EventList)は、当該プレイリスト内であげられるイベントを定義したテーブルである。イベントリストは、イベント数(Number)に続いて個々のイベント(Event#1〜Event#m)から構成され、個々のイベント(Event#)は、イベントの種類(Type)、イベントのID(ID)、イベント生成時刻(Time)と有効期間(Duration)から構成されている。
【0091】
図17は、個々のプレイリスト毎のイベントハンドラ(時間イベントと、メニュー選択用のユーザイベント)を持つイベントハンドラテーブル(”XXX.PROG”)である。
【0092】
イベントハンドラテーブルは、定義されているイベントハンドラ/プログラム数(Number)と個々のイベントハンドラ/プログラム(Program#1〜Program#n)を有している。各イベントハンドラ/プログラム(Program#)内の記述は、イベントハンドラ開始の定義(<event_handler>タグ)と前述したイベントのIDと対になるイベントハンドラのID(ID)を持ち、その後に当該プログラムもFunctionに続く括弧”{”と”}”の間に記述する。
【0093】
次に図18を用いてBDディスク全体に関する情報(”BD.INFO”)の内部構造について説明をする。
【0094】
BDディスク全体情報は、タイトルリスト(TitleList)とグローバルイベント用のイベントテーブル(EventTable)から構成されている。
【0095】
タイトルリスト(TitleList)は、ディスク内のタイトル数(Number)と、これに続く各タイトル情報(Title#1〜Title#n)から構成されている。個々のタイトル情報(Title)は、タイトルに含まれるプレイリストのテーブル(PLTalble)とタイトル内のチャプタリスト(ChapterList)を含んでいる。プレイリストのテーブル(PLTable)はタイトル内のプレイリストの数(Number)と、プレイリスト名(Name)即ちプレイリストのファイル名を有している。
【0096】
チャプタリスト(ChapterList)は、当該タイトルに含まれるチャプタ数(Number)と個々のチャプタ情報(Chapter#1〜Chapter#n)から構成され、チャプタ情報(Chapter#)は当該チャプタが含むセルのテーブル(CellTable)を持ち、セルのテーブル(CellTable)はセル数(Number)と個々のセルのエントリ情報(CellEntry#1〜CellEntry#k)から構成されている。セルのエントリ情報(CellEntry#)は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【0097】
イベントリスト(EventList)は、グローバルイベントの数(Number)と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント(FirstEvent)と呼ばれ、BDディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ(Type)とイベントのID(ID)だけを持っている。
【0098】
図19は、グローバルイベントハンドラのプログラムのテーブル(”BD.PROG”)である。本テーブルは、図17で説明したイベントハンドラテーブルと同一内容である。
(イベント発生のメカニズム)
図20から図22を使ってイベント発生のメカニズムについて説明する。
【0099】
図20はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報(”XXX.PL”)のイベントリスト(EventList)で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ(Type)が”TimeEvent”の場合、イベント生成時刻(”t1”)になった時点で、ID”Ex1”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントID”Ex1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、2つのボタンイメージの描画を行うなどを行うことができる。
【0100】
図21はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報(”XXX.PL”)のイベントリスト(EventList)で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ(Type)が”UserEvent”の場合、イベント生成時刻(”t1”)になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効規格情報(Duration)で記される期間レディ状態にある。
【0101】
図21に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずUOPイベントがUOPマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してUOPイベントを流し、シナリオプロセッサはUOPイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントID”Ev1”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、プレイリスト#2の再生を開始する。
【0102】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、UOPイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタSPRM(8)に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
【0103】
図22はグローバルイベントの例である。
前述したとおり、グローバルイベントはBDディスク全体に関する情報(”BD.INFO”)のイベントリスト(EventList)で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ(Type)が”GlobalEvent”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
【0104】
ユーザが”メニュー”を押した場合、先ずUOPイベントがUOPマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してUOPイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントID”menu”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合ではプレイリスト#3の再生を開始している。
【0105】
本実施例では、単に”メニュー”キーと呼んでいるが、DVDのように複数のメニューキーがあってもよい。各メニューキーに対応するIDを夫々定義することで対応することが可能である。
【0106】
(仮想プレーヤマシン)
図23を用いてプログラムプロセッサの機能構成を説明する。
【0107】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはBD−ROMとして定義された機能モデルであって、各BD−ROMプレーヤの実装には依存しないものである。即ち、どのBD−ROMプレーヤにおいても同様の機能を実行するできることを保証している。
【0108】
仮想プレーヤマシンは大きく2つの機能を持っている。プログラミング関数とプレーヤ変数(レジスタ)である。プログラミング関数は、Java(登録商標) Scriptをベースとして、以下に記す2つの機能をBD−ROM固有関数として定義している。
【0109】
リンク関数:現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Link(PL#,Cell#,time)
PL# : プレイリスト名
Cell# : セル番号
time : セル内での再生開始時刻
PNG描画関数:指定PNGデータをイメージプレーンに描画する
Draw(File,X,Y)
File : PNGファイル名
X : X座標位置
Y : Y座標位置
イメージプレーンクリア関数:イメージプレーンの指定領域をクリアする
Clear(X,Y,W,H)
X : X座標位置
Y : Y座標位置
W : X方向幅
H : Y方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ(SPRM)と一般用途として使用可能なゼネラルパラメータ(GPRM)とがある。
【0110】
図24はシステムパラメータ(SPRM)の一覧である。
SPRM(0) : 言語コード
SPRM(1) : 音声ストリーム番号
SPRM(2) : 字幕ストリーム番号
SPRM(3) : アングル番号
SPRM(4) : タイトル番号
SPRM(5) : チャプタ番号
SPRM(6) : プログラム番号
SPRM(7) : セル番号
SPRM(8) : 選択キー情報
SPRM(9) : ナビゲーションタイマー
SPRM(10) : 再生時刻情報
SPRM(11) : カラオケ用ミキシングモード
SPRM(12) : パレンタル用国情報
SPRM(13) : パレンタルレベル
SPRM(14) : プレーヤ設定値(ビデオ)
SPRM(15) : プレーヤ設定値(オーディオ)
SPRM(16) : 音声ストリーム用言語コード
SPRM(17) : 音声ストリーム用言語コード(拡張)
SPRM(18) : 字幕ストリーム用言語コード
SPRM(19) : 字幕ストリーム用言語コード(拡張)
SPRM(20) : プレーヤリージョンコード
SPRM(21) : 予備
SPRM(22) : 予備
SPRM(23) : 再生状態
SPRM(24) : 予備
SPRM(25) : 予備
SPRM(26) : 予備
SPRM(27) : 予備
SPRM(28) : 予備
SPRM(29) : 予備
SPRM(30) : 予備
SPRM(31) : 予備
なお、本実施例では、仮想プレーヤのプログラミング関数をJava(登録商標) Scriptベースとしたが、Java(登録商標) Scriptではなく、UNIX(登録商標) OSなどで使われているB−Shellや、Perl Scriptなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はJava(登録商標) Scriptに限定されるものでは無い。
【0111】
(プログラムの例)
図25及び図26は、イベントハンドラでのプログラムの例である。
【0112】
図25は、2つの選択ボタンを持ったメニューの例である。
セル(PlayList#1.Cell#1)先頭でタイムイベントを使って図25左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つGPRM(0)に”1”がセットされている。GPRM(0)は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン1が選択されている事を初期値として持たされている。
【0113】
次に、PNGの描画を描画関数であるDrawを使ってボタン1、ボタン2夫々について行っている。ボタン1は、座標(10、200)を起点(左端)としてPNGイメージ”1black.png”を描画している。ボタン2は、座標(330,200)を起点(左端)としてPNGイメージ”2white.png”を描画している。
【0114】
また、本セル最後ではタイムイベントを使って図25右側のプログラムが実行される。ここでは、Link関数を使って当該セルの先頭から再度再生するように指定している。
【0115】
図26は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図21で説明したとおり、ユーザイベントが生成され、図26のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているGPRM(0)の値と、選択されたリモコンキーを識別するSPRM(8)を使って分岐処理を行っている。
【0116】
条件1)ボタン1が選択されている、かつ、選択キーが「右」キーの場合
GPRM(0)を2に再設定して、選択状態にあるボタンを右ボタン2に変更する。
【0117】
ボタン1、ボタン2のイメージを夫々書き換える。
条件2)選択キーが「決定(OK)」の場合で、ボタン1が選択されている場合、プレ
イリスト#2の再生を開始する
条件3)選択キーが「決定(OK)」の場合で、ボタン2が選択されている場合、プレイリスト#3の再生を開始する
上記のようにして実行処理が行われる。
【0118】
(プレーヤ処理フロー)
次に図27から図30を用いてプレーヤでの処理フローを説明する。
【0119】
図27は、AV再生までの基本処理フローである。
BDディスクを挿入すると(S101)、BD−ROMプレーヤはBD.INFOファイルの読み込みと解析(S102)、BD.PROGの読み込み(S103)を実行する。BD.INFO及びBD.PROGは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【0120】
続いて、シナリオプロセッサは、BD.INFOファイル内のファーストイベント(FirstEvent)情報に従い、最初のイベントを生成する(S104)。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する(S105)。
【0121】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。この場合、ユーザイベントを受け付けるのを待ち続けることになる(S201)。BD−ROMプレーヤはがユーザからのリモコン操作を受け付けると、UOPマネージャはプログラムマネージャに対してUOPイベントを立ち上げる(S202)。
【0122】
プログラムマネージャは、UOPイベントがメニューキーによるものであるかを判別し(S203)、メニューキーの場合は、シナリオプロセッサにUOPイベントを流し、シナリオプロセッサがユーザイベントを生成する(S204)。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する(S205)。
【0123】
図28は、PL再生開始からVOB再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される(S301)。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”XXX.PL”の読み込みと解析(S302)、プレイリストに対応するプログラム情報”XXX.PROG”の読み込みを行う(S303)。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を開始する(S304)。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはAV再生を開始する(S305)。
【0124】
AV再生の開始(S401)を開始すると、プレゼンテーションコントローラは再生するセルに対応するVOBの情報ファイル(XXX.VOBI)を読み込み及び解析をする(S402)。プレゼンテーションコントローラは、タイムマップを使って再生開始するVOBUとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるVOBデータを読み出し(S403)、VOBデータがデコーダに送られ再生が開始される(S404)。VOB再生は、当該VOBの再生区間が終了するまで続けられ(S405)、終了すると次のセル再生S304へ移行する。次にセルが無い場合は、再生が停止する(S406)。
【0125】
図29は、AV再生開始後からのイベント処理フローである。
BD−ROMプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
【0126】
S500系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後(S501)、プレイリスト再生が終了しているかを確認するステップ(S502)を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する(S503)。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し(S504)、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する(S505)。
【0127】
ステップS503でタイムイベント発生時刻になっていない場合、または、ステップS504でイベントハンドラ実行処理後は再度ステップS502へ戻り、上述した処理を繰り返す。また、ステップS502でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【0128】
S600系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後(S601)、プレイリスト再生終了確認ステップ(S602)を経て、UOP受付確認ステップの処理に移る(S603)。UOPの受付があった場合、UOPマネージャはUOPイベントを生成し(S604)、UOPイベントを受け取ったプログラムプロセッサはUOPイベントがメニューコールであるかを確認し(S605)、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ(S607)、プログラムプロセッサはイベントハンドラを実行処理する(S608)。
【0129】
ステップS605でUOPイベントがメニューコールで無いと判断された場合、UOPイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し(S606)、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し(S607)、プログラムプロセッサが対象のイベントハンドラを実行処理する(S608)。
【0130】
ステップS603でUOP受付が無い場合、ステップS606で現在時刻がユーザイベント有効期間に無い場合、または、ステップS608でイベントハンドラ実行処理後は再度ステップS602へ戻り、上述した処理を繰り返す。また、ステップS602でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【0131】
図30は字幕処理のフローである。
プレイリスト再生開始後(S701)、プレイリスト再生終了確認ステップ(S702)を経て、字幕描画開始時刻確認ステップに移る(S703)。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する(S704)。ステップS703で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する(S705)。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する(S706)。
【0132】
字幕描画ステップS704終了後、字幕消去ステップS706終了後、または、字幕表示終了時刻確認ステップS705で当該時刻でないことが判断された場合、ステップS702に戻り、上述した処理を繰り返す。また、ステップS702でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
【0133】
(実施例2)
次に本発明の第2の実施の形態について説明する。
【0134】
第2の実施の形態は、BD-ROMにおいてより豊かなインタラクティブ性を実現するため、XML・XHTML・HTMLベースの画面構成環境と、イベントおよびスクリプトを用いたプログラミング環境を導入することに関する内容である。基本的には第1の実施例に基づく内容であり、拡張または異なる部分を中心に説明する。
(HTMLファイルを利用したコンテンツ制御)
図31は、HTMLおよびスクリプトを利用したシナリオ制御に関わるモジュール構成、制御の流れ、イベントなどの伝わり方を示している。
【0135】
ユーザーイベント処理部は、リモコン信号などを受信し、次のモジュールにイベントを割り振るモジュールである。再生制御に関わる、再生/停止/早送り/巻き戻し/スキップ/アングル変更/音声切替/字幕切替などのイベントはAV再生制御部に送られる。ボタンフォーカスの移動(上下左右キー)や決定などのイベントは、HTML処理部に送られる。タイトル切替に関わる、タイトル選択やメニュー呼び出しのイベントは、タイトル制御部に送られる。なお、Index Tableとは、ディスク中のタイトルを列挙したファイルであり、図18のTitle List部分を切り出して1つにしたものである。
【0136】
タイトル制御部は、タイトル切替を要求されるとIndex Tableにしたがってタイトル切替を行うモジュールである。タイトルがHTMLで定義される場合、HTML処理部にタイトルに関連付けられたHTMLファイルを読み込むように制御を行う。
HTML処理部はHTMLファイルを読み込み、スタイル定義情報などにしたがって、画面を構成し、イベントに応じて関連するスクリプトを実行するモジュールである。スクリプトを実行した結果、AVの再生が必要であればAV再生制御部に対して、再生開始などの制御を行い、タイトル切替が必要であれば、タイトル制御部に対して制御を行う。
AV再生制御部は、イベントや指示に従ってAVストリームの再生を行い、AV再生制御部の状態が変化したときやAVストリームの再生位置が特定の位置に達した際にイベントを生成してHTML処理部に通知する。
【0137】
プレーヤの状態が変化したことを通知するイベントとは、ユーザーから再生指示があり、ユーザーイベント処理部が再生開始要求のイベントをAV再生制御部に通知すると、AV再生制御部は再生を開始する。この時に、AV再生制御部が停止状態から再生状態に変化したことを通知するようなイベントである。
【0138】
また、再生位置を通知するイベントとは、AVストリームの終端に達したときや、セルの境界に達したとき、あるいはマークと呼ばれるAVストリームの一時点を示すデータが存在する場合その地点に達したことを通知するイベントである。
【0139】
図32はあるタイトルが選択されたときの動作の様子を示している。
Index Tableで定義されるあるタイトルを選択した場合、タイトルに関連付けられたHTMLファイルが呼び出される。HTMLファイルには、再生制御などを行うスクリプトなども記述されている。 図中の例では、スクリプトファイルを間接的に参照しているが、直接HTMLファイル内に記述することも可能である。また、説明のため、HTMLと表記しているが、XHTML形式であってもよいし、XML形式にのっとっていれば独自のタグなどを利用した形式でもよい。
図中のHTMLファイル内に記述されている“onLoad”属性において、ファイルが読み込まれたときに実行されるスクリプトを規定している。この例では、HTMLファイルが読み込まれたときに、“playTitle1”というスクリプトが呼び出され、スクリプト自体はスクリプトファイル内に記述されている。
また、<event>タグを用いることにより、ユーザーイベント処理部やAV再生制御部から通知されたイベントに対応してスクリプトを実行する仕組みも提供する。この例では、“EndOfStream”イベントが発生した際、“jumpTitle2”というスクリプトを呼び出す例である。なお、“EndOfStream”イベントとは、たとえばAV再生がファイルの終端に達した場合にAV再生制御部が生成するイベントである。
また、予め関数名が予約されているイベント処理用関数(例えば、BDIMoviePlaybackEventHandler()関数など)を、HTML文書のスクリプトタグ内や、スクリプトファイル内に記述しておくことで、ユーザーイベント処理部やAV再生制御部から通知されたイベントに対応して、スクリプトを実行することも可能である。
図33は先ほどの例に、画面生成を加えた例である。たとえば、先ほどと同様にIndex TableからHTMLが呼び出され、そのHTMLはメニュー画面などを生成するための情報が書かれていた場合である。画面構成のスタイルなどはCSSなどのスタイルシートを利用してもよい。
この例では、画面上に2つのボタンを配置している。それぞれのボタンが押されると対応スクリプトが実行される。あるボタンを選択すると、“onClick”属性に定義されているスクリプトが実行される。TitleAと書かれたPNGイメージファイルと関連付けられている左側のボタンを選択すると、“playA”スクリプトが実行され、タイトル1にジャンプする。同様に、TitleBボタンを選択すると、あるAVストリームが再生された後に、タイトル2にジャンプする。
これまで説明した仕組みを用いることのより、HTMLファイルを用いて、メニュー画面を表示し、何らかのボタンを選択を選択するとコンテンツの再生を開始するような仕組みを提供することが可能となる。
また、スクリプト部分と、スクリプトが実行するAPIを追加することにより、より複雑な機能、たとえばインターネット接続やダウンロードサービスといったアプリケーションも実行可能である。
【0140】
(リソース管理)
HTMLファイルがメニュー画面のような画面を構成する際には、PNGイメージファイルなどのデータファイルを参照する。メニューが凝ったものになればなるほど、表示するグラフィクスは複雑なものになり、それを表示するためのイメージデータのサイズは大きくなる。
【0141】
また、HTMLファイルはユーザー操作によって画面を切り替えるように作ることも可能である。メニュー画面の中である項目を選ぶと、さらにサブメニューが出てくるような場合である。このような場合、メニュー画面が表示された最初の瞬間には表示されていなかったイメージデータが、あとから必要になることがある。
【0142】
ところが、さらにそのメニュー画面の背景では動画が表示されている、つまりAVストリームが再生されている場合、必要になってからイメージデータを読み込みに行こうとすると、ディスク上でファイルがある位置にシークを行ってから読み込んで元の位置に戻ってこなければならず、AVストリームの再生が一時的に中断してしまう可能性がある。十分な量のバッファを積んでおり、AVストリームを事前にバッファ一杯に先読みすればこのようなことも回避できるが、画像が高解像度・高画質になり、高ビットレートが必要になってきているので、かなり大容量のバッファを用意しなければならず、コストアップなどにつながり、現実的ではない。
【0143】
また、ハードディスクのようにシーク時間が短く、読み取り速度が速いメディアでは、少量のバッファでもその早さを利用して、AVを中断させずに他のデータを読み込むことも可能であるが、光ディスクメディアのドライブでは、シークには時間がかかり、読み込み速度もそれほど速くないため、実現にはさらなる技術の進歩が必要となる。
【0144】
そのため、一旦AV再生が開始されるとAV以外のデータを読み込みに行かないモデルにすることが望ましい。
【0145】
図34はその様な場合のデータのライフサイクルを示している。
AVの再生が開始される前に、画面を表示するために必要なデータである、HTMLファイルやスクリプトファイル、それらのファイルから参照されるPNGイメージファイルなどのデータファイルをバッファ上にプリロードしておく。
【0146】
一旦AVの再生が開始されると、それらのデータをディスクに読みに行くことはない。
なお、AVの再生が止まってもよい場合は、これらを考慮する必要はない。
【0147】
また、コンテンツにより、AVの再生が止まって欲しくない場合と、止まってもよい場合を区別する必要があるならば、管理情報にこの2つのパターンを区別する識別子を用意しておけばよい。
【0148】
HTML処理部がデータを必要とするときは、バッファからHTML処理部のワークメモリ上に読み込んでおき、画面の表示などに利用する。その画面が表示されなくなったときには、必要なくなったデータをワークメモリから解放し、次に必要になるデータをバッファから読み込んでくる。
【0149】
なお、このワークメモリは、バッファと共有してもよい。
バッファにあるメモリーは、そこに読み込まれているデータが必要なくなるまで保存しておき、必要なくなれば解放する。
【0150】
(データのライフサイクル)
上で述べたように、バッファにデータを読み込んでくるタイミングと、バッファからデータを解放するタイミングを明確に決めることができれば、データのライフサイクルの管理が明確になり、管理がしやすくなる。
【0151】
データの管理がしやすくなれば、コンテンツ作成者がどのプレーヤでも必ず動作させることができるコンテンツ構成を判定しやすくなり、コンテンツ作成が容易になる。
【0152】
データのライフサイクルの開始タイミングと終了タイミングは、AVの再生が停止しているタイミング、あるいは一時的に停止する、連続して再生する場合でもシームレスに再生する必要がないタイミングが望ましい。
【0153】
このようなタイミングとしては、AVストリームの切替点、HTMLファイルで構成される画面の切替点や、タイトル切替のタイミングなどがあり、その他上記の条件を満たすのであればその他の点でもよい。
【0154】
これまで説明した構造を用いると、タイトルの切替のタイミングは、Index Tableで明示的に、かつ静的データとして参照することができ、プレーヤから制御しやすい。そのため、データのライフサイクルとは、あるタイトルが開始するときに開始し、あるタイトルが終了するときにライフサイクルも終了する。
【0155】
つまり、あるタイトルが開始するときに、そのタイトルを再生するために必要な全てのデータをバッファにプリロードしておき、そのタイトルが終了するとき、たとえば他のタイトルにジャンプするときに、バッファから解放する。
【0156】
図35は各モジュール間の制御の流れとデータの流れ、それに合わせたデータのライフサイクルを示したタイミングチャートである。
【0157】
このようなライフサイクルと、バッファのサイズを規定すれば、タイトルを作成するときに、どのくらいのサイズまでイメージデータを使うことができ、どのようなアプリケーションを実行できるか定量的に判断でき、タイトルが非常に作りやすくなる。
【0158】
なお、バッファの解放はタイトル制御部や、より上位のモジュールから強制的に行ってもよいし、HTML処理部が行ってもよい。
【0159】
ユーザー操作によりアプリケーション実行中にタイトルを切り替えられた場合、タイトル制御部は、HTML処理部に現在実行中のスクリプトを中止し、バッファの解放を指示ずる。また、タイトルが切り替わると、次のタイトルに関連するファイルをバッファに読み込むよう指示する。
【0160】
(データ読み込みの保証)
AVストリームの再生開始より前に、AVストリーム以外のファイルをバッファにプリロードしておく必要は上で述べたとおりである。その際、HTMLファイルを解析して必要なファイルをリストアップしていては、時間がかかってしまう。
【0161】
そこで、図36(a)のように、各タイトルで必要なファイルをリストアップしたリソースリストをタイトル毎に作成し、タイトルが選択されたときに、そのタイトルリストに列挙されているファイルを全てバッファに読み込めばよい。
【0162】
また、ファイル数が多い場合、ファイル毎にシークが発生すると読み込みの時間がかかってしまうため、リストアップされたファイルをディスク上の1カ所にまとめて配置することのより、無駄なシークを発生させることなく必要なファイルを全て読み込むことも可能である。
【0163】
あるいは、図36(b)のように、ファイルをディレクトリ構造ごとZIPファイルなどで1つにまとめてしまい、バッファに読み込んだあとでバッファ内でファイルを展開し、ディレクトリ構造などを構成してもよい。ファイルをひとまとめにでき、ディレクトリ構造を保持できるようなフォーマットであれば、ZIPファイルでなくてもよい。また、圧縮ファイルである必要もない。
【0164】
あるいは、図37に示すように、制作段階などにおいてディレクトリ構造を持つ論理ファイルツリー400の各ファイルを、Content Archive File401(以降、CARファイルと記載する)内に、フラットに配置し、HTTPのentity形式などでマルチパート化しておく。さらに、論理ファイルツリー400のディレクトリ構造情報は、Resource List File402に格納して、このResource List File402を、CARファイル401内に配置してもよい。
【0165】
(ZIPファイル、CARファイル401を用いたアーカイブ構成の効果)
図36(b)の構成や、図37の構成をとることで実現できるディスクへの書込み効率/読出し効率の向上について説明する。
もし、HTMLファイルやイメージファイルを、ディスク上に個別配置した場合、1つのファイルに関する情報しか配置できないディスク上のセクターに、何も書き込まれないエリア(フラグメンテーション)が発生し、書込み効率が低下する。
また、読出しにおいては、HTMLファイル、イメージファイルの個数分だけ読出し処理が発生し、読出しの都度、ディスクのSEEK処理が発生し、関連するファイルの読込みに時間がかかってしまい、タイトルの起動が遅くなる。
一方、ZIPファイル、もしくは、CARファイル401を用いた場合、画面提示に利用されるHTMLファイルとそのHTMLファイルが参照するイメージファイル群、そして、そのHTMLファイルから文書遷移して次に提示されるHTMLファイルなど、一連の動作に関連するファイル群(コンテンツ)をアーカイブ化しているので、フラグメンテーションの合計サイズ、個数が抑えられて、ディスクへの書込み効率が高くなり、また、1ファイルにアーカイブされているので、1回の読出し処理しか発生せず、SEEK回数が抑えられ、すばやくディスクから読み出すことができる。
【0166】
また、このような仕組みを用いることにより、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することにより、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【0167】
(Resource List File形式による起動処理フロー)
以下、図36、図37を用いて説明したZIPファイルおよびCARファイルなどのアーカイブファイルを応用した仕組みに関してより詳細な実装を説明する。
【0168】
図39にXMLを用いたResource List Fileを記述した例を図示している。Resource List Fileは各タイトル毎に記述され、各タイトル再生時に実行されるアプリケーションに関する記述がなされる。
【0169】
図32を用いて前述した例では、Index Tableで定義されるタイトルからはHTMLファイルが関連づけられていたが、Index Tableで定義された各タイトルからはResource List Fileが関連づけられており、Index Tableで定義されるあるタイトルを選択した場合、そのタイトルに関連づけられたResource List Fileが最初に呼び出される。
【0170】
また、図32を用いて前述した例では、Index Tableで定義されるタイトルからはHTMLファイルが関連づけられていたが、Index Tableで定義された各タイトルからは、CARファイルが関連づけられていており、さらに、CARファイル内には、Resource List Fileが格納されており、Index Tableで定義されるあるタイトルを選択した場合、そのタイトルに関連づけられたCARファイルが最初に呼び出され、CARファイルに関連付けられたResource List Fileが次に呼び出される。
【0171】
なお、図38のS800系は、Titleが選択されてから、HTMLによる画面提示までのフローを示している。
Index Tableで定義されるあるタイトルを選択されると(S801)、そのタイトルに関連づけられたCARファイルが呼出され、CARファイル用のBufferに格納される(S802)。次に、CARファイルに格納された、Resource List Fileが切り出され、Resource List Fileが解析され、起動すべきHTMLファイルが特定される(S803)。なお、Resource List Fileは、マルチパート化されたCARファイルの先頭に配置することで、Resource List Fileの切り出しをすばやく実現できる。
次に、Resource List Fileに記載された起動すべきHTMLファイルのOffset値を用いて、CARファイル内に格納されたHTMLファイルを切り出し、HTMLファイルを解析する(S804)。なお、Offsetが記載されていない場合には、ディレクトリ構成に記載されたディレクトリ名、ファイル名を付け足して論理パスを構築し、本論理パスを用いて、ZIPファイルにアーカイブされた各ファイルのリソースヘッダに記載されたリソースパスと比較することで、HTMLファイルを特定し、切り出すことができる。
【0172】
HTMLファイルがイメージファイルなどのデータファイルを参照している場合は、さらに、Resource List Fileを解析して、対応するデータファイルを切り出し、レイアウト処理、スクリプト処理を行って、画面が提示される(S805)。
【0173】
さらに、図38のS900系を用いて、画面提示された後、ユーザ操作やスクリプト処理などによって文書遷移処理が発生してから、次の提示画面が提示されるまでの処理フローを説明する。
【0174】
ユーザ操作やスクリプト処理などによって文書遷移が発生すると(S901)、指定されたURIを解析し、同一タイトル内に属するかを判断し、別タイトルに属する場合は、Index Tableを解析して、別タイトルの起動を指示し、(S801)へ移行する(S902)。同タイトルに属する場合、すでにPreloadされているCARファイル内にあるResource List Fileを解析し、指定されたHTMLファイルを特定する(S903)。次に、Resource List Fileに記載されたOffset値を用いて、CARファイル内に格納されたHTMLファイルを切り出し、HTMLファイルを解析する(S904)。イメージファイルなどのデータファイルが参照されている場合は、さらに、Resource List Fileを解析して、対応するデータファイルを切り出し、レイアウト処理、スクリプト処理を行って、画面が提示される(S905)。
【0175】
(XML形式のResource List Fileの構造)
図39は、XML形式のResource List Fileの記述例を示す。XML形式のResource List Fileは、XML宣言と、<application>、<entry>、<toppage>、<linkfile>の四つの要素からなる。
<application>要素のname属性にアプリケーション名が記述される。
【0176】
アプリケーションを実行する上で一番最初に読み込んで解析する必要があるHTML(以降、Toppageと呼ぶ)に関しては、そのファイル名が<toppage>要素のsrc属性として記述されている。
【0177】
Toppageを除く、アプリケーションを構成する各ファイルのファイル名がURI形式で<linkfile>要素のsrc属性としてリストアップされている。
また、これらのアプリケーションを構成するファイル群(Toppageを含む)は、アーカイブファイルとして一纏めにBD−ROM上に記録されるものとし、Resource List Fileには当該アーカイブファイルのファイル名がURI形式で<entry>要素のsrc属性として記述されている。
【0178】
このように、BDプレーヤはタイトル再生時にそのタイトルに対応するResource List Fileを読み込むことで、BD−ROM上にアーカイブファイルとして一纏めに配置されたアプリケーションを構成するファイルを無駄なシークを発生させることなく一括して読み込むことができ、また当該アプリケーションで使用する全てのファイル名を知ることができる。
【0179】
また、Resource List File中の<Toppage>要素を参照することで、HTML及びスクリプトで記述されたアプリケーションを実行する際、どのファイルを一番はじめに解析するのかを知ることができる。
【0180】
現在再生しているタイトルとは違うタイトルが選択された場合、再生していたタイトルのResource List Fileに記述されていたファイルを解放してもよいし、選択されたタイトルに関連づけられたResource List Fileに記載されていないファイルのみ解放してもよい。このようにResource List Fileを用いることで、タイトル毎にリソースを分かりやすく管理し、データの読み込みを効率化することが可能であり、オーサリング時にミスが起こりにくく、プレーヤで制御しやすい仕組みを提供することが可能となる。
【0181】
なお、本実施の形態のResource List Fileでは、<application>要素のname属性にアプリケーションの名前が記述されており、プレーヤは挿入されたBD−ROM Discのタイトル名とこのアプリケーション名を用いてプレーヤにて実行されたアプリケーションを識別可能である。したがって、プレーヤのローカルストレージにそれぞれのアプリケーション用の領域を設定してもよい。また、前記アプリケーション用の領域には当該アプリケーションのみがアクセス可能であり、そのほかのアプリケーションのアクセスを禁止しても良い。
【0182】
(バイナリー形式のResource List Fileの構造)
図40を用いて、CARファイルにアーカイブされるファイルのディレクトリ構造情報を格納したバイナリー形式のResource List Fileの内部構造について説明をする。
<Resource List File>
バイナリー形式のResource List Fileは、Base InfoとBase Directoryから構成される。Base Infoは、Resource List Fileが格納されているCARファイル全般に関わる情報が記載される。
<Base Directory>
Base Directoryは、CARファイルに格納されているHTMLファイル等ファイルのディレクトリ構造情報が記載されており、Information、Number、CARファイルをトップディレクトリとして、この1段下に配置されるDirectory、Fileから構成される。DirectoryとFileの合計数は、Numberに記載された数となる。Informationには、Base Directoryに関する情報が記載される。
<Directory>
Directoryは、Information、Number、本Directoryの1段下に配置されるDirectory、Fileから構成される。DirectoryとFileの合計数は、Numberに記載された数となる。Informationには、Directoryの名前や本Directoryの属性情報が記載される。さらに配下に配置されたDirectoryは、本Directoryと同じ構成となる。
<File>
Fileは、Information、Offset、Nameから構成される。Informationには、本Fileの属性情報が記載される。Nameは名前である。Offsetは、CARファイル内に配置されている本来のファイルの、CARファイルの先頭からのbit長さが記載されている。
【0183】
(バイナリ形式のResource List Fileの効果)
バイナリ形式のResource List Fileの内部構造であるDirectory、Fileを解析していくことで、CARファイル内にフラットに配置され、マルチパート化されたファイルのディレクトリ構造を復元できて、かつ、File内にあるOffsetを用いて、BufferにPreloadされたCARファイルから、実ファイルの位置を計算できるため、数M〜Byteの巨大なCARファイル内から、すばやく目的のファイルを切り出すことができる。
【0184】
(ディスク外のHTML提示状態から、ディスク上のHTMLへの遷移における課題)
図41を用いて、通信サーバ上などのディスク外のHTMLファイルを提示している状態から、ディスク上のHTMLファイルへ文書遷移する場合の課題を説明する。
ディスク上のHTMLファイル間でブラウジングした後など、一旦、通信サーバ上のHTMLファイルへ文書遷移してしまうと、通信サーバ上のHTMLファイル間の文書遷移に関しては問題ないが、いざディスク上のHTMLファイルへ文書遷移しようとした場合、通信サーバ上のHTMLファイルは、現在挿入されているディスクが何であるか、また、どのような論理ディレクトリ構造になっているかなど、ディスク上のHTMLに関する情報を取得できないため、予め情報を保持していない限り、期待するディスク上のHTMLファイルへの文書遷移ができない。結果、タイトルの再起動を行って、画面提示を行うため、以前ディスク上のHTMLファイル間でブラウジングした操作結果が削除されてしまったり、最後に提示したディスク上のHTMLファイルの画面を再提示することができない。
(ディスク外のHTMLファイルから、ディスク上のHTMLファイルへの遷移の方法)
図42は、ディスク外からディスク上のHTMLファイルへの文書遷移要求が発生時に、提示すべきHTMLを指定する仕組みを追加したバイナリー形式のResource List Fileの内部構造を示す。
<Resource List File>
バイナリー形式のResource List Fileは、Base InfoとEntry ListとBase Directoryから構成される。Base Infoは、Resource List Fileが格納されているCARファイル全般に関わる情報が記載される。
<Entry List>
Entry Listは、NumberとEntry Infoから構成される。Entryの数は、Numberに記載された数である。Entry Infoは、Entry TypeとOffsetから構成される。Entry Typeは、ディスク外のHTMLファイルから本タイトルへの文書遷移要求を受けた場合に提示すべきHTMLファイル、などの起動種別を表す。Offsetは、提示すべきHTMLファイルに対応するFile構造体のResource List File内のOffset値である。
<Base Directory>
Base Directoryは、CARファイルに格納されているHTMLファイル等ファイルのディレクトリ構造情報が記載されており、Information、Numberと、CARファイルをトップディレクトリとして、その1段下に配置されるDirectory、Fileから構成される。DirectoryとFileの合計数は、Numberに記載された数となる。Informationには、Base Directoryに関する情報が記載される。
<Directory>
Directoryは、Information、Numberと、本Directoryの1段下に配置されるDirectory、Fileから構成される。DirectoryとFileの合計数は、Numberに記載された数となる。Informationには、Directoryの名前や本Directoryの属性情報が記載される。さらに配下に配置されたDirectoryは、本Directoryと同じ構成となる。
<File>
Fileは、Information、Offset、Nameから構成される。Informationには、本Fileの属性情報が記載される。Nameは名前である。Offsetは、CARファイル内に配置されている本来のファイルの、CARファイルの先頭からのbit長さが記載されている。
【0185】
次に、図43を用いて、本Resource List Fileを用いて、ディスク外からディスク上のHTMLファイルへの文書遷移要求が発生した場合の処理フローを説明する。
【0186】
ディスク外のHTMLファイルから、ディスク上のHTMLファイルへ文書遷移が要求されると(S1001)、指定されたURIを解析し、同一タイトル内に属するか判断し、別タイトルに属する場合は、Index Tableを解析して、別タイトルへの起動を指示すべく、(S801)へ移行する(S1002)。
【0187】
同タイトルに属する場合、すでにPreloadされているCARファイル内にあるResource List Fileを解析し、Entry Listにある“ディスク外からの文書遷移要求時に提示すべきHTMLファイル”を特定し、そのOffsetから、File構造体を解析し、起動すべきHTMLファイルを特定する(S1003)。
【0188】
なお、通信サーバ上のHTMLファイルは、現在PreloadされているCARファイルの属するタイトルを示すURIが判定できない場合があるが、ディスク、タイトルを指定するURIとして、現在挿入中のディスク、現在BufferにPreloadされているタイトルを指定するURI(“bd://−1.−1”など。−1は現在選択されているディスク、もしくは、タイトルを指している)を指定することで、ディスク、タイトルを識別する必要がない。
【0189】
次に、Resource List Fileに記載されたOffset値を用いて、CARファイル内に格納されたHTMLファイルを切り出し、HTMLファイルを解析する(S1004)。
【0190】
ディスク外からの文書遷移要求時にためのHTMLファイルの画面提示処理においては、本HTMLのスクリプト機能を利用することで、ある程度、ディスク外へ文書遷移する前、もしくは、ディスク上のHTMLファイル間でブラウジングしていたときの状態を復帰することができる。
【0191】
例えば、ディスク外へ文書遷移した際のAV再生位置、ゲームの進捗・得点などの遷移前情報が、DOMのcookieやUser Register/Global Registerなどのデータ格納I/Fによりプレイヤー保存領域に退避している場合、スクリプト機能により遷移前情報を読込み、例えば、AVを遷移前の再生位置から再生を再開したり、ゲームを途中から再開することができる(S1005)。
【0192】
以上の仕組みを用いることで、ディスク外のHTMLファイル提示状態から、ディスク上のHTMLファイルへの遷移が発生したときに、毎回同じタイトル起動画面が提示されるのではなく、ディスク上のHTMLファイル間でブラウジングしていたユーザ操作やゲームの進捗・得点などを反映した画面を提示することができる。また、異なるタイトルへの文書遷移でなければ、PreloadされたCARファイルからHTMLファイルを読み出すので、新たなディスクSEEKが発生せず、画面をすみやかに提示することができる。また、PreloadされているCARファイルからHTMLファイルを読出し、提示するので、AVが文書遷移に関係なく継続して再生していても、AV以外のファイルのディスクSEEKに起因するAV再生の途切れや映像乱れが発生しない。
【0193】
(エラー発生時の課題)
図44を用いて、エラー発生時に想定される課題を説明する。
【0194】
既存のPC上で利用されているHTMLブラウザなどにおいて、文書遷移の際、次に提示するHTMLファイルの取得に失敗すると、通信サーバが、HTMLファイルが存在しない等の通知画面を生成し、HTMLファイルとして送信し、これを受信したHTMLブラウザがエラー通知用のHTMLファイルを提示したり、もしくは、HTMLファイルが存在しないことを通知するエラーコード(404番)を受け取ったHTMLブラウザが、ブラウザ内に事前に埋め込んで用意されているエラー用のHTMLファイルを提示していた。
【0195】
そのため、エラーが発生すると、制作者の制作したHTMLファイルが提示されないため、制作者の意図した動作を実現できない。例えば、エラー画面を制作者の意図するデザインにできなかったたり、次のAV操作やスクリプト操作への繋がりが断絶されてしまう。
【0196】
(エラー発生時に制作者の意図する動作を実現する方法)
図42で示したバイナリー形式のResource List FileのEntry ListのEntry Typeに関して、次に示すように、起動種別を追加する。
<Entry List>
Entry Listは、NumberとEntry Infoから構成される。Entryの数は、Numberに記載された数である。Entry Infoは、Entry TypeとOffsetから構成される。Entry Typeは、ディスク外のHTMLから本Titleへの文書遷移要求を受けた場合のHTMLファイル、エラーが発生した場合に提示すべきHTMLファイル、などの起動種別を表す。Offsetは、提示すべきHTMLファイルに対応するFile構造体のResource List File内のOffset値である。
【0197】
図45は、通信サーバ上のHTMLファイルへの文書遷移時にHTMLファイルの取得失敗などのエラーが発生した場合の処理フローを示す。
【0198】
通信サーバ上のHTMLファイルの文書遷移において、HTMLファイルの取得に失敗して、通信サーバからエラーコード404が通知されるなど、エラーが発生すると(S1101)、すでにPreloadされているCARファイル内にあるResource List Fileを解析し、Entry Listの中から、“エラーが発生した場合に提示すべきHTMLファイル”を特定し、そのOffset値から、File構造体を特定して、起動すべきHTMLファイルを特定する(S1102)。
【0199】
次に、特定したFile構造体に記載されたOffset値を用いて、CARファイル内に格納されたHTMLファイルを切り出し、解析する(S1103)。
制作者によって用意されたエラー用のHTMLファイルの画面提示処理においては、スクリプト機能を利用することで、エラーに応じた画面を提示したり、エラーの影響を受けないスクリプト処理を用意したり、など、制作者の意図した処理を実現できる。
【0200】
例えば、エラー画面HTMLのOnLoadスクリプトにより、エラーStatus取得関数をCallし、通信サーバ上のHTMLの取得エラーであることが判明すると、通信エラーであることを通知する画面を提示するとともに、通信サーバ上のHTMLファイルへリンクを抑えた画面を作成して、提示することで、その後のユーザ操作により、同じエラーを回避することができ、継続した画面提示が可能となる(S1104)。
【0201】
以上の仕組みを用いることで、エラーが発生した場合に、ブラウザに組み込まれたエラー用画面が提示されることはなく、制作者の作成したエラー用HTMLが提示され、そのUIや次に繋がる動作を、制作者が意図して制作可能である。また、PreloadされたCARファイルからHTMLファイルを読み出すので、新たなディスクSEEK処理を発生させることがなく、画面をすみやかに提示することができる。また、PreloadされているCARファイルからHTMLファイルを読出し、提示するので、AVが文書遷移に関係なく継続して再生していても、AV以外のファイルのディスクSEEKに起因するAV再生の途切れや映像乱れが発生しない。
【産業上の利用可能性】
【0202】
本発明を利用することにより、映像データとHTMLおよびスクリプトによるAV再生制御を導入することが可能となる。特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用される可能性をもつ。
【図面の簡単な説明】
【0203】
【図1】DVDの構成図
【図2】ハイライトの構成図
【図3】DVDでの多重化の例を示す図
【図4】BD−ROMのデータ階層図
【図5】BD−ROM上の論理空間の構成図
【図6】BD−ROMプレーヤの概要ブロック図
【図7】BD−ROMプレーヤの構成ブロック図
【図8】BD−ROMのアプリケーション空間の説明図
【図9】MPEGストリーム(VOB)の構成図
【図10】パックの構成図
【図11】AVストリームとプレーヤ構成の関係を説明する図
【図12】トラックバッファへのAVデータ連続供給モデル図
【図13】VOB情報ファイル構成図
【図14】タイムマップの説明図
【図15】タイムマップを使ったアドレス情報取得方法説明図
【図16】プレイリストファイルの構成図
【図17】プレイリストに対応するプログラムファイルの構成図
【図18】BDディスク全体管理情報ファイルの構成図
【図19】グローバルイベントハンドラを記録するファイルの構成図
【図20】タイムイベントの例を説明する図
【図21】ユーザイベントの例を説明する図
【図22】グローバルイベントハンドラの例を説明する図
【図23】仮想マシンの構成図
【図24】プレーヤ変数テーブルの図
【図25】イベントハンドラ(タイムイベント)の例を示す図
【図26】イベントハンドラ(ユーザイベント)の例を示す図
【図27】プレーヤの基本処理のフローチャート
【図28】プレイリスト再生処理のフローチャート
【図29】イベント処理のフローチャート
【図30】字幕処理のフローチャート
【図31】モジュール構成や制御の流れを説明する図
【図32】Index TableとHTMLファイルの関係を説明する図
【図33】ボタンが表示されるHTMLファイルの例
【図34】データのライフサイクルを説明する説明図
【図35】データのライフサイクルを説明するタイミングチャート
【図36】データを1つにまとめる方法を説明する図
【図37】データを1つにまとめる方法を説明する図
【図38】Title起動と文書遷移におけるの処理のフローチャート
【図39】XML形式のResource List Fileの例を示す図
【図40】バイナリー形式のResource List File構造図
【図41】ディスク上のHTMLとWeb上のHTMLの関係を説明する図
【図42】バイナリー形式のResource List File構造図
【図43】文書遷移が発生した場合の処理のフローチャート
【図44】エラーが発生した場合のエラー提示画面を説明する図
【図45】エラーが発生した場合の処理のフローチャート
【符号の説明】
【0204】
201 BDディスク
202 光ピックアップ
203 プログラム記録メモリ
204 管理情報記録メモリ
205 AV記録メモリ
206 プログラム処理部
207 管理情報処理部
208 プレゼンテーション処理部
209 イメージプレーン
210 ビデオプレーン
211 合成処理部
301 プログラム記録メモリ
302 プログラムプロセッサ
303 UOPマネージャ
304 管理情報記録メモリ
305 シナリオプロセッサ
306 プレゼンテーションコントローラ
307 クロック
308 イメージメモリ
309 トラックバッファ
310 デマルチプレクサ
311 イメージプロセッサ
312 ビデオプロセッサ
313 サウンドプロセッサ
314 イメージプレーン
315 ビデオプレーン
316 合成処理部
317 ドライブコントローラ
400 の論理ファイルツリー
401 Content Archive File
402 Resource List File
410 HTML Browser
420 エラー用HTMLファイル
S101 ディスク挿入ステップ
S102 BD.INFO読み込みステップ
S103 BD.PROG読み込みステップ
S104 ファーストイベント生成ステップ
S105 イベントハンドラ実行ステップ
S201 UOP受付ステップ
S202 UOPイベント生成ステップ
S203 メニューコール判定ステップ
S204 イベント生成ステップ
S205 イベントハンドラ実行ステップ
S301 プレイリスト再生開始ステップ
S302 プレイリスト情報(XXX.PL)読み込みステップ
S303 プレイリストプログラム(XXX.PROG)読み込みステップ
S304 セル再生開始ステップ
S305 AV再生開始ステップ
S401 AV再生開始ステップ
S402 VOB情報(YYY.VOBI)読み込みステップ
S403 VOB(YYY.VOB)読み込みステップ
S404 VOB再生開始ステップ
S405 VOB再生終了ステップ
S406 次セル存在判定ステップ
S501 プレイリスト再生開始ステップ
S502 プレイリスト再生終了判定ステップ
S503 タイムイベント時刻判定ステップ
S504 イベント生成ステップ
S505 イベントハンドラ実行ステップ
S601 プレイリスト再生開始ステップ
S602 プレイリスト再生終了判定ステップ
S603 UOP受付判定ステップ
S604 UOPイベント生成ステップ
S605 メニューコール判定ステップ
S606 ユーザーイベント有効期間判定ステップ
S607 イベント生成ステップ
S608 イベントハンドラ実行ステップ
S701 プレイリスト再生開始ステップ
S702 プレイリスト再生終了判定ステップ
S703 字幕描画開始判定ステップ
S704 字幕描画ステップ
S705 字幕表示終了判定ステップ
S706 字幕消去ステップ
S801 タイトル起動ステップ
S802 CARファイルPreloadステップ
S803 Resource List File読込みステップ
S804 HTMLファイルの読込みステップ
S805 画面の提示ステップ
S901 文書遷移操作ステップ
S902 タイトル判断ステップ
S903 Resource List File読込みステップ
S904 HTMLファイルの読込みステップ
S905 画面の提示ステップ
S1001 文書遷移操作ステップ
S1002 タイトル判断ステップ
S1003 Resource List File読込みステップ
S1004 HTMLファイルの読込みステップ
S1005 画面の提示ステップ
S1101 エラー発生ステップ
S1102 Resource List File読込みステップ
S1103 HTMLファイルの読込みステップ
S1104 画面の提示ステップ




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013