(57)【特許請求の範囲】
【請求項１】
コンテンツデータと、該コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力部と、
上記入力部から入力された上記付随データのうちデコード時刻を示す情報が定義された上記第１の単位を記憶する第１の記憶部と、
上記デコード時刻を示す情報を保持する時刻情報保持部と、
上記時刻情報保持部に保持された上記デコード時刻を示す情報に従い上記第１の記憶部から上記第１の単位を取り出してデコードするデコード部と、
上記デコード部でデコードされた上記第１の単位を記憶する第２の記憶部と
を備え、
上記時刻情報保持部は、上記第１の記憶部に記憶される上記第１の単位数の上限に基づく容量を少なくとも有し、
上記第２の記憶部は、
上記付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、
上記付随データにより表示される画像データの属性情報を保持する第４の記憶部と
からなり、
上記第１の記憶部に格納される付随データ数の上限は、上記第３の記憶部に記憶される上記画像データを形成するための情報数の上限と、上記第４の記憶部に記憶される上記画像データの属性情報数の上限とに基づき決定される
再生装置。
【請求項２】
請求項１に記載の再生装置において、
上記付随データは、
ユーザに対して操作を促す操作画面に用いるボタンを表示するための、アニメーション
表示が可能なボタン画像と、該ボタン画像に対する表示制御情報とからなる
ことを特徴とする再生装置。
【請求項３】
請求項１に記載の再生装置において、
上記第１の単位は、上記付随データの構造を示す情報と、該付随データの属性を示す情報と、該付随データの画像情報と、区切りを示す情報と
が定義され、
１の上記構造を示す情報と１の上記区切りを示す情報とを含む複数の上記第１の単位から第２の単位が構成され、
１または複数の上記付随データの属性を示す情報を含む１または複数の上記第２の単位から第３の単位が構成され、
上記付随データは、上記第３の単位の集合体である
再生装置。
【請求項４】
請求項３に記載の再生装置において、
上記デコード時刻を示す情報は、上記第１の単位に対して定義され、上記第１の単位をパケット化した際のパケットヘッダに格納される
再生装置。
【請求項５】
請求項３に記載の再生装置において、
上記デコード時刻を示す情報は、上記構造を示す情報および上記画像情報が格納される上記第１の単位に対して定義される
再生装置。
【請求項６】
請求項５に記載の再生装置において、
上記デコード時刻を示す情報は、さらに、上記属性を示す情報が格納される上記第１の単位に対して定義される
再生装置。
【請求項７】
請求項３に記載の再生装置において、
上記第１の記憶部に記憶される第１の単位数の上限は、上記第３の単位に格納可能とされた、上記構造を示す情報、上記属性を示す情報および上記画像情報が格納される上記第１の単位の数に基づく
再生装置。
【請求項８】
請求項３に記載の再生装置において、
上記第２の記憶部は、上記第３の単位毎にクリアされる
再生装置。
【請求項９】
請求項３に記載の再生装置において、
上記付随データは、出力時刻がさらに定義され、上記時刻情報保持部は、該付随データから取り出された該出力時刻を示す情報をさらに保持し、
上記デコード部でデコードされ上記第２の記憶部に記憶された上記第１の単位を、上記時刻情報保持部に保持された上記出力時刻に従い該第２の記憶部から出力するようにされ、
上記時刻情報保持部は、該時刻情報保持部に格納されている上記出力時刻を示す情報に基づき、上記第２の記憶部に記憶されている上記第１の単位による表示がなされた後、該第１の単位毎にクリアされる
再生装置。
【請求項１０】
請求項９に記載の再生装置において、
上記時刻情報保持部は、
上記デコード時刻を示す情報と上記第１の単位とを関連付ける識別情報がさらに保持され、
上記識別情報は、上記時刻情報保持部に格納されている上記出力時刻を示す情報に基づき、上記第２の記憶部に記憶されている上記第１の単位による表示がなされた後、該第１の単位毎にクリアされる
再生装置。
【請求項１１】
請求項３に記載の再生装置において、
上記時刻情報保持部に保持されている、上記第３の単位に含まれる上記第１の単位に定義される上記デコード時刻を示す情報を、該第３の単位毎にクリアする
再生装置。
【請求項１２】
請求項１１に記載の再生装置において、
上記時刻情報保持部は、
上記デコード時刻を示す情報と上記第１の単位とを対応付ける識別情報がさらに保持され、
上記デコード時刻を示す情報が上記クリアされる際に、該デコード時刻を示す情報に対応する上記識別情報も共にクリアされる
再生装置。
【請求項１３】
コンテンツデータと、該コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力のステップと、
上記入力のステップにより入力された上記付随データのうちデコード時刻を示す情報が定義された上記第１の単位を第１の記憶部に記憶するステップと、
上記デコード時刻を示す情報を時刻情報保持部に保持するステップと、
上記時刻情報保持部に保持された上記デコード時刻を示す情報に従い上記第１の記憶部から上記第１の単位を取り出してデコードするデコードのステップと、
上記デコードのステップによりデコードされた上記第１の単位を第２の記憶部に記憶するステップと
を備え、
上記時刻情報保持部は、上記第２の記憶部に記憶される上記第１の単位数の上限に基づく上記デコード時刻を示す情報を少なくとも保持可能であり、
上記第２の記憶部は、
上記付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、
上記付随データにより表示される画像データの属性情報を保持する第４の記憶部と
からなり、
上記第１の記憶部に格納される付随データ数の上限は、上記第３の記憶部に記憶される上記画像データを形成するための情報数の上限と、上記第４の記憶部に記憶される上記画像データの属性情報数の上限とに基づき決定される
再生方法。
【請求項１４】
コンテンツデータと、該コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力のステップと、
上記入力のステップにより入力された上記付随データのうちデコード時刻を示す情報が定義された上記第１の単位を第１の記憶部に記憶するステップと、
上記デコード時刻を示す情報を時刻情報保持部に保持するステップと、
上記時刻情報保持部に保持された上記デコード時刻を示す情報に従い上記第１の記憶部から上記第１の単位を取り出してデコードするデコードのステップと、
上記デコードのステップによりデコードされた上記第１の単位を第２の記憶部に記憶するステップと
を備え、
上記時刻情報保持部は、上記第２の記憶部に記憶される上記第１の単位数の上限に基づく上記デコード時刻を示す情報を少なくとも保持可能であり、
上記第２の記憶部は、
上記付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、
上記付随データにより表示される画像データの属性情報を保持する第４の記憶部と
からなり、
上記第１の記憶部に格納される付随データ数の上限は、上記第３の記憶部に記憶される上記画像データを形成するための情報数の上限と、上記第４の記憶部に記憶される上記画像データの属性情報数の上限とに基づき決定される
再生方法をコンピュータ装置に実行させる
再生プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ブルーレイディスク(Blu-ray Disc：登録商標)といった大容量の記録媒体に記録された、ビデオデータおよびオーディオデータに対して字幕データおよびボタンデータが多重化されたストリームを再生する再生装置、再生方法および再生プログラムに関する。
【背景技術】
【０００２】
近年、記録可能で記録再生装置から取り外し可能なディスク型記録媒体の規格として、Ｂｌｕ−ｒａｙ  Ｄｉｓｃ（ブルーレイディスク）規格が提案されている。Ｂｌｕ−ｒａｙ  Ｄｉｓｃ規格では、記録媒体として直径１２ｃｍ、カバー層０．１ｍｍのディスクを用い、光学系として波長４０５ｎｍの青紫色レーザ、開口数０．８５の対物レンズを用いて、最大で２７ＧＢ（ギガバイト）の記録容量を実現している。これにより、日本のＢＳディジタルハイビジョン放送を、画質を劣化させることなく２時間以上記録することが可能である。
【０００３】
この記録可能光ディスクに記録するＡＶ(Audio/Video)信号のソース（供給源）としては、従来からの、例えばアナログテレビジョン放送によるアナログ信号によるものと、例えばＢＳディジタル放送をはじめとするディジタルテレビジョン放送によるディジタル信号によるものとが想定されている。Ｂｌｕ−ｒａｙ  Ｄｉｓｃ規格では、これらの放送によるＡＶ信号を記録する方法を定めた規格は、既に作られている。
【０００４】
一方で、現状のＢｌｕ−ｒａｙ  Ｄｉｓｃの派生規格として、映画や音楽などが予め記録された、再生専用の記録媒体の開発が進んでいる。映画や音楽を記録するためのディスク状記録媒体としては、既にＤＶＤ(Digital Versatile Disc)が広く普及しているが、このＢｌｕ−ｒａｙ  Ｄｉｓｃの規格に基づいた再生専用光ディスクは、Ｂｌｕ−ｒａｙ  Ｄｉｓｃの大容量および高速な転送速度などを活かし、ハイビジョン映像を高画質なままで２時間以上収録できる点が、既存のＤＶＤとは大きく異なり、優位である。
【０００５】
このＢｌｕ−ｒａｙ  Ｄｉｓｃにおける再生専用の記録媒体の規格を、以下では、ＢＤ−ＲＯＭ規格(Blu-ray Disc Read-Only Format)と呼ぶ。
【０００６】
再生専用の記録媒体に記録するコンテンツに不可欠の要素として、字幕がある。ＢＤ−ＲＯＭ規格においては、字幕は、動画像が表示されるプレーンとは別のプレーンに表示され、字幕が表示されるプレーンと動画像が表示されるプレーンとを合成することで、字幕と動画像とが重ね合わされて表示される。例えば、字幕を表示する字幕プレーンを動画像を表示する動画像プレーンの前面に配置し、字幕プレーンにおいて字幕以外の部分に透明の属性を持たせることで、動画像上に字幕が表示された１枚の画像データが構成できる。
【０００７】
また、ディスクに映画などのコンテンツを記録して、パッケージメディアとして販売等を行う場合、コンテンツに伴う様々なプログラムの実行などを制御するためのユーザインターフェイスをコンテンツと共にディスクに記録することが行われる。代表的なユーザインターフェイスとしては、メニュー表示が挙げられる。一例として、メニュー表示においては、機能を選択するためのボタンがボタン画像として用意され、所定の入力手段によりボタンを選択し決定することで、当該ボタンに割り当てられた機能が実行されるようになっている。一般的には、プレーヤに対応したリモートコントロールコマンダの十字キーなどを用いて、画面に表示されたボタンを選択し、決定キーを押下することで、当該ボタンに割り当てられた機能が実行される。
【０００８】
特許文献１には、記録再生規格であるＢｌｕ−ｒａｙ  Ｄｉｓｃ規格(Blu-ray Disc Rewritable Format Ver1.0)を元に、動画像および字幕を表示するプレーンをそれぞれ設け、ビデオデータによる動画像と字幕画像データによる字幕とを１画面上に表示する技術や、ボタン画像を用いたメニュー表示を実現するための技術が記載されている。
【特許文献１】特開２００４−３０４７６７号公報
【０００９】
ところで、ＢＤ−ＲＯＭ規格では、ビデオデータやオーディオデータは、ＭＰＥＧ２(Moving Pictures Experts Group 2)システムズに規定される、トランスポートストリーム（ＴＳ）形式でディスクに記録される。すなわち、ビデオデータやオーディオデータは、分割されてＰＥＳ(Packetized Elementary Stream)パケットに詰め込まれ、さらに所定サイズに分割されデータ種類を示す識別情報（ＰＩＤ：Packet Identification）を有するヘッダをそれぞれ付加されて、１８８バイトのＴＳパケットとされて多重化され、ディスクに記録される。
【００１０】
また、上述の字幕画像データや、メニュー画面を表示するための画像データやコマンドも、所定の単位でＰＥＳパケットに詰め込まれ、ＰＥＳパケットが分割され所定のＰＩＤを有するヘッダ情報を付加されてＴＳパケットとされ、ビデオデータやオーディオデータに対してさらに多重化され、ディスクに記録される。
【００１１】
字幕画像データの場合を例として、より詳細に説明する。字幕画像データは、例えばオーサ側が意図する字幕の区切りに基づく単位で構成され、当該単位毎に所定にＰＥＳパケットに格納される。このとき、字幕画像データは、例えばビットマップデータからなる字幕画像データの本体、字幕画像データの表示位置や表示方法を示す情報、字幕画像データが表示可能な表示枠を示す情報など、複数のデータから構成され、これら複数のデータのそれぞれが個別のＰＥＳパケットに格納される。以下では、字幕画像データを構成する複数のデータを総称して、字幕画像データと呼ぶ。
【００１２】
ＰＥＳパケットに詰め込まれた字幕画像データのデコード時刻を示すＤＴＳ(Decoding Time Stamp)と、表示時刻を示すＰＴＳ(Presentation Time Stamp)とが、ＰＥＳパケットのヘッダであるＰＥＳヘッダに格納される。ＰＥＳパケットは、さらに所定サイズに分割され、データ種類を識別するためのＰＩＤを所定に付加され、データサイズが１８８バイトのＴＳパケットとされる。このＴＳパケットがビデオデータやオーディオデータのＴＳパケット、ならびに、後述のボタン画像データのＴＳパケットと多重化されて、ディスクに記録される。
【００１３】
なお、メニュー画面を表示するためのデータも、字幕画像データと略同様にして、メニュー画面を表示するための複数のデータがそれぞれＰＥＳパケット化され、ＰＥＳパケットが所定サイズに分割されてＰＩＤを付されてＴＳパケットとされる。
【００１４】
ディスクを再生して上述した字幕画像データを表示させる場合、ディスクから読み出されたトランスポートストリームに対して、ＴＳパケット毎にヘッダを抽出してＰＩＤを取得し、ＰＩＤに基づき字幕画像データが格納されたＴＳパケットを振り分けてバッファに一旦格納する。バッファに対してＰＥＳパケットを形成できるだけのＴＳパケットが溜め込まれたら、ＰＩＤに基づき同種のＴＳパケットのペイロードからデータが取り出されＰＥＳパケットが再構築される。再構築されたＰＥＳパケットは、ＰＥＳヘッダを取り除かれ、さらに字幕画像データを構成する複数のデータが再構築される。
【００１５】
再構築された字幕画像データを構成する複数のデータは、デコードバッファに一旦格納される。そして、ＰＥＳヘッダに格納されるＤＴＳの時刻にデコードバッファから読み出されてデコードされ、出力側のバッファに格納される。出力側のバッファに格納されたデータは、ＰＥＳヘッダに格納されるＰＴＳの時刻に出力される。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
このように、字幕画像データのデコードタイミングや出力タイミングは、上述したように、ＰＥＳヘッダに格納されるＤＴＳおよびＰＴＳによって指示される。したがって、デコードバッファに溜め込まれている字幕画像データに対応するＤＴＳおよびＰＴＳを、例えばデコードされたデータが出力側のバッファから出力されるまで、メモリに保持しておく必要がある。
【００１７】
ところが、既に説明したように、字幕画像データは、上述のようにオーサ側の意図する字幕の区切りに基づき構成されるため、字幕画像データ毎にサイズが区々となる。そのため、字幕画像データを構成する複数のデータがデコードバッファに何個格納されるかを見積もるのが難しく、デコードバッファの容量に対する、ＤＴＳおよびＰＴＳを保持するためのメモリの容量を見積もることが極めて困難であるという問題点があった。この問題は、メニュー画面を表示するためのデータにおいても、同様である。
【００１８】
この問題を回避するために、このため、ＤＴＳおよびＰＴＳを保持するためのメモリの容量を十分に大きく設計する方法が考えられる。しかしながら、この方法では、装置のコストが嵩んでしまうことになるという問題点があった。
【００１９】
このように、従来では、デコード時刻および出力時刻が構成データ毎にそれぞれ指定された、字幕画像データやメニュー画面を表示するためのデータをデコードするデコーダを適切に設計および構成することが困難であるという問題点があった。
【００２０】
したがって、この発明の目的は、デコード時刻および出力時刻が構成データ毎にそれぞれ指定された、字幕画像データやメニュー画面を表示するためのデータをデコードするデコーダが適切に構成された再生装置、再生方法および再生プログラムを提供することにある。
【課題を解決するための手段】
【００２１】
この発明は、上述した課題を解決するために、コンテンツデータと、コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力部と、入力部から入力された付随データのうちデコード時刻を示す情報が定義された第１の単位を記憶する第１の記憶部と、デコード時刻を示す情報を保持する時刻情報保持部と、時刻情報保持部に保持されたデコード時刻を示す情報に従い第１の記憶部から第１の単位を取り出してデコードするデコード部と、デコード部でデコードされた第１の単位を記憶する第２の記憶部とを備え、時刻情報保持部は、第１の記憶部に記憶される上記第１の単位数の上限に基づく容量を少なくとも有し、第２の記憶部は、付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、付随データにより表示される画像データの属性情報を保持する第４の記憶部とからなり、第１の記憶部に格納される付随データ数の上限は、第３の記憶部に記憶される画像データを形成するための情報数の上限と、第４の記憶部に記憶される画像データの属性情報数の上限とに基づき決定される再生装置である。
【００２２】
また、この発明は、コンテンツデータと、コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力のステップと、入力のステップにより入力された付随データのうちデコード時刻を示す情報が定義された第１の単位を第１の記憶部に記憶するステップと、デコード時刻を示す情報を時刻情報保持部に保持するステップと、時刻情報保持部に保持されたデコード時刻を示す情報に従い第１の記憶部から第１の単位を取り出してデコードするデコードのステップと、デコードのステップによりデコードされた第１の単位を第２の記憶部に記憶するステップとを備え、時刻情報保持部は、第２の記憶部に記憶される第１の単位数の上限に基づくデコード時刻を示す情報を少なくとも保持可能であり、第２の記憶部は、付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、付随データにより表示される画像データの属性情報を保持する第４の記憶部とからなり、第１の記憶部に格納される付随データ数の上限は、第３の記憶部に記憶される画像データを形成するための情報数の上限と、第４の記憶部に記憶される画像データの属性情報数の上限とに基づき決定される
再生方法である。
【００２３】
また、この発明は、コンテンツデータと、コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力される入力のステップと、入力のステップにより入力された付随データのうちデコード時刻を示す情報が定義された第１の単位を第１の記憶部に記憶するステップと、デコード時刻を示す情報を時刻情報保持部に保持するステップと、時刻情報保持部に保持されたデコード時刻を示す情報に従い第１の記憶部から第１の単位を取り出してデコードするデコードのステップと、デコードのステップによりデコードされた第１の単位を第２の記憶部に記憶するステップとを備え、時刻情報保持部は、第２の記憶部に記憶される第１の単位数の上限に基づくデコード時刻を示す情報を少なくとも保持可能であり、第２の記憶部は、付随データにより表示される画像データを形成するための情報を保持する第３の記憶部と、付随データにより表示される画像データの属性情報を保持する第４の記憶部とからなり、第１の記憶部に格納される付随データ数の上限は、第３の記憶部に記憶される画像データを形成するための情報数の上限と、第４の記憶部に記憶される画像データの属性情報数の上限とに基づき決定される
再生方法をコンピュータ装置に実行させる再生プログラムである。
【００２４】
上述したように、この発明は、コンテンツデータと、コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力され、入力された付随データのうちデコード時刻を示す情報が定義された第１の単位を第１の記憶部に記憶すると共に、デコード時刻を示す情報を時刻情報保持部に保持し、時刻情報保持部に保持されたデコード時刻を示す情報に従い第１の記憶部から第１の単位を取り出してデコードし、デコードされた第１の単位を第２の記憶部に記憶するようにされ、時刻情報保持部は、第１の記憶部に記憶される第１の単位数の上限に基づく容量を少なくとも有するようにしているため、時刻情報保持部の容量を容易に見積もることが可能で、デコーダを適切に構成することができる。
【発明の効果】
【００２５】
この発明は、上述したように、コンテンツデータと、コンテンツデータに付随する情報を表示するための複数の第１の単位から構成される付随データとが入力され、入力された付随データのうちデコード時刻を示す情報が定義された第１の単位を第１の記憶部に記憶すると共に、デコード時刻を示す情報を時刻情報保持部に保持し、時刻情報保持部に保持されたデコード時刻を示す情報に従い第１の記憶部から第１の単位を取り出してデコードし、デコードされた第１の単位を第２の記憶部に記憶するようにされ、時刻情報保持部は、第１の記憶部に記憶される第１の単位数の上限に基づく容量を少なくとも有するようにしているため、時刻情報保持部の容量を容易に見積もることが可能で、デコーダを適切に構成することができる効果がある。
【発明を実施するための最良の形態】
【００２６】
以下、この発明の実施の形態を、図面を参照しながら説明する。先ず、理解を容易とするために、Ｂｌｕ−ｒａｙ  Ｄｉｓｃに関し、"Blu-ray Disc Read-Only Format Ver1.0 part3 Audio Visual Specifications"で規定されている、読み出し専用タイプのＢｌｕ−ｒａｙ  ＤｉｓｃであるＢＤ−ＲＯＭに記録されたコンテンツすなわちＡＶ(Audio/Video)データの管理構造について説明する。以下では、このＢＤ−ＲＯＭにおける管理構造をＢＤＭＶフォーマットと称する。
【００２７】
例えばＭＰＥＧ(Moving Pictures Experts Group)ビデオやＭＰＥＧオーディオなどの符号化方式で符号化され、ＭＰＥＧ２システムに従い多重化されたビットストリームは、クリップＡＶストリーム（またはＡＶストリーム）と称される。クリップＡＶストリームは、Ｂｌｕ−ｒａｙ  Ｄｉｓｃに関する規格の一つである"Blu-ray Disc Read-Only Format part2"で定義されたファイルシステムにより、ファイルとしてディスクに記録される。このファイルを、クリップＡＶストリームファイル（またはＡＶストリームファイル）と称する。
【００２８】
クリップＡＶストリームファイルは、ファイルシステム上での管理単位であり、ユーザにとって必ずしも分かりやすい管理単位であるとは限らない。ユーザの利便性を考えた場合、複数のクリップＡＶストリームファイルに分割された映像コンテンツを一つにまとめて再生する仕組みや、クリップＡＶストリームファイルの一部だけを再生する仕組み、さらには、特殊再生や頭出し再生を滑らかに行うための情報などをデータベースとしてディスクに記録しておく必要がある。Ｂｌｕ−ｒａｙ  Ｄｉｓｃに関する規格の一つである"Blu-ray Disc Read-Only Format part3"で、このデータベースが規定される。
【００２９】
図１は、ＢＤ−ＲＯＭのデータモデルを概略的に示す。ＢＤ−ＲＯＭのデータ構造は、図１に示されるように４層のレイヤよりなる。最も最下層のレイヤは、クリップＡＶストリームが配置されるレイヤである（便宜上、クリップレイヤと呼ぶ）。その上のレイヤは、クリップＡＶストリームに対する再生箇所を指定するための、ムービープレイリスト(Movie PlayList)と、プレイアイテム(PlayItem)とが配置されるレイヤである（便宜上、プレイリストレイヤと呼ぶ）。さらにその上のレイヤは、ムービープレイリストに対して再生順などを指定するコマンドからなるムービーオブジェクト(Movie Object)などが配置されるレイヤである（便宜上、オブジェクトレイヤと呼ぶ）。最上層のレイヤは、このＢＤ−ＲＯＭに格納されるタイトルなどを管理するインデックステーブルが配置される（便宜上、インデックスレイヤと呼ぶ）。
【００３０】
クリップレイヤについて説明する。クリップＡＶストリームは、ビデオデータやオーディオデータがＭＰＥＧ２  ＴＳ（トランスポートストリーム）の形式などに多重化されたビットストリームである。このクリップＡＶストリームに関する情報がクリップ情報(Clip Information)としてファイルに記録される。
【００３１】
また、クリップＡＶストリームには、ビデオデータやオーディオデータによるコンテンツデータに対して付随して表示される字幕やメニュー表示を行うためのストリームも多重化される。字幕を表示するためのグラフィクスストリームは、プレゼンテーショングラフィクス（ＰＧ）ストリームと呼ばれる。また、メニュー表示などに用いられるデータをストリームにしたものは、インタラクティブグラフィクス（ＩＧ）ストリームと呼ばれる。
【００３２】
クリップＡＶストリームファイルと、対応するクリップ情報が記録されたクリップ情報ファイルとをひとまとまりのオブジェクトと見なし、クリップ(Clip)と称する。すなわち、クリップは、クリップＡＶストリームとクリップ情報とから構成される、一つのオブジェクトである。
【００３３】
ファイルは、一般的に、バイト列として扱われる。クリップＡＶストリームファイルのコンテンツは、時間軸上に展開され、クリップ中のエントリーポイントは、主に時間ベースで指定される。所定のクリップへのアクセスポイントのタイムスタンプが与えられた場合、クリップＡＶストリームファイルの中でデータの読み出しを開始すべきアドレス情報を見つけるために、クリップ情報ファイルを用いることができる。
【００３４】
プレイリストレイヤについて説明する。ムービープレイリストは、再生するＡＶストリームファイルの指定と、指定されたＡＶストリームファイルの再生箇所を指定する再生開始点（ＩＮ点）と再生終了点（ＯＵＴ点）の集まりとから構成される。この再生開始点と再生終了点の情報を一組としたものは、プレイアイテム(PlayItem)と称される。ムービープレイリストは、プレイアイテムの集合で構成される。プレイアイテムを再生するということは、そのプレイアイテムに参照されるＡＶストリームファイルの一部分を再生するということになる。すなわち、プレイアイテム中のＩＮ点およびＯＵＴ点情報に基づき、クリップ中の対応する区間が再生される。
【００３５】
オブジェクトレイヤについて説明する。ムービーオブジェクトは、ＨＤＭＶナビゲーションコマンドプログラム（ＨＤＭＶプログラム）と、ムービーオブジェクトとを連携するターミナルインフォメーションを含む。ＨＤＭＶプログラムは、プレイリストの再生を制御するためのコマンドである。ターミナルインフォメーションは、ユーザのＢＤ−ＲＯＭプレーヤに対するインタラクティブな操作を許可するための情報を含んでいる。このターミナルインフォメーションに基づき、メニュー画面の呼び出しや、タイトルサーチといったユーザオペレーションが制御される。
【００３６】
ＢＤ−Ｊオブジェクトは、Ｊａｖａプログラム（Ｊａｖａは登録商標）によるオブジェクトからなる。ＢＤ−Ｊオブジェクトは、この発明と関わりが薄いので、詳細な説明を省略する。
【００３７】
インデックスレイヤについて説明する。インデックスレイヤは、インデックステーブルからなる。インデックステーブルは、ＢＤ−ＲＯＭディスクのタイトルを定義する、トップレベルのテーブルである。インデックステーブルに格納されているタイトル情報に基づき、ＢＤ−ＲＯＭ常駐システムソフトウェア中のモジュールマネージャによりＢＤ−ＲＯＭディスクの再生が制御される。
【００３８】
すなわち、図２に概略的に示されるように、インデックステーブル中の任意のエントリは、タイトルと称され、インデックステーブルにエントリされるファーストプレイバック(First Playback)、トップメニュー(Top Menu)およびタイトル(Title)＃１、＃２、・・・は、全てタイトルである。各タイトルは、ムービーオブジェクトあるいはＢＤ−Ｊオブジェクトに対するリンクを示し、各タイトルは、ＨＤＭＶタイトルあるいはＢＤ−Ｊタイトルの何れかを示す。
【００３９】
例えば、ファーストプレイバックは、当該ＢＤ−ＲＯＭに格納されるコンテンツが映画であれば、映画本編に先立って映出される映画会社の宣伝用映像（トレーラ）である。トップメニューは、例えばコンテンツが映画である場合、本編再生、チャプタサーチ、字幕や言語設定、特典映像再生などを選択するためのメニュー画面である。また、タイトルは、トップメニューから選択される各映像である。タイトルがさらにメニュー画面であるような構成も可能である。
【００４０】
図３は、上述のようなクリップＡＶストリーム、クリップ情報(Stream Attributes)、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ(Unified Modeling Language)図である。プレイリストは、１または複数のプレイアイテムに対応付けられ、プレイアイテムは、１のクリップに対応付けられる。１のクリップに対して、それぞれ開始点および／または終了点が異なる複数のプレイアイテムを対応付けることができる。１のクリップから１のクリップＡＶストリームファイルが参照される。同様に、１のクリップから１のクリップ情報ファイルが参照される。また、クリップＡＶストリームファイルとクリップ情報ファイルとは、１対１の対応関係を有する。このような構造を定義することにより、クリップＡＶストリームファイルを変更することなく、任意の部分だけを再生する、非破壊の再生順序指定を行うことが可能となる。
【００４１】
また、図４のように、複数のプレイリストから同一のクリップを参照することもできる。また、１のプレイリストから複数のクリップを指定することもできる。クリップは、プレイリスト中のプレイアイテムに示されるＩＮ点およびＯＵＴ点により、参照される。図４の例では、クリップ３００は、プレイリスト３１０のプレイアイテム３２０から参照されると共に、プレイリスト３１１を構成するプレイアイテム３２１および３２２のうちプレイアイテム３２１から、ＩＮ点およびＯＵＴ点で示される区間が参照される。また、クリップ３０１は、プレイリスト３１１のプレイアイテム３２２からＩＮ点およびＯＵＴ点で示される区間が参照されると共に、プレイリスト３１２のプレイアイテム３２３および３２４のうち、プレイアイテム３２３のＩＮ点およびＯＵＴ点で示される区間が参照される。
【００４２】
なお、プレイリストは、図５に一例が示されるように、主として再生されるプレイアイテムに対応するメインパスに対して、サブプレイアイテムに対応するサブパスを持つことができる。サブプレイアイテムは、例えば、このプレイリストに付けられているアフレコオーディオ用のプレイアイテムである。詳細は省略するが、プレイリストは、所定の条件を満たす場合にだけ、サブプレイアイテムを持つことができる。
【００４３】
次に、"Blu-ray Disc Read-Only Format part3"で規定された、ＢＤ−ＲＯＭに記録されるファイルの管理構造について、図６を用いて説明する。ファイルは、ディレクトリ構造により階層的に管理される。記録媒体上には、先ず、１つのディレクトリ（図６の例ではルート(root)ディレクトリ）が作成される。このディレクトリの下が、１つの記録再生システムで管理される範囲とする。
【００４４】
ルートディレクトリの下に、ディレクトリ"BDMV"およびディレクトリ"CERTIFICATE"が置かれる。ディレクトリ"CERTIFICATE"は、著作権に関する情報が格納される。ディレクトリ"BDMV"に、図１を用いて説明したデータ構造が格納される。
【００４５】
ディレクトリ"BDMV"の直下には、ファイルは、ファイル"index.bdmv"およびファイル"MovieObject.bdmv"の２つのみを置くことができる。また、ディレクトリ"BDMV"の下に、ディレクトリ"PLAYLIST"、ディレクトリ"CLIPINF"、ディレクトリ"STREAM"、ディレクトリ"AUXDATA"、ディレクトリ"META"、ディレクトリ"BDJO"、ディレクトリ"JAR"、およびディレクトリ"BACKUP"が置かれる。
【００４６】
ファイル"index.bdmv"は、ディレクトリBDMVの内容について記述される。すなわち、このファイル"index.bdmv"が上述した最上層のレイヤであるインデックスレイヤにおけるインデックステーブルに対応する。また、ファイルMovieObject.bdmvは、１つ以上のムービーオブジェクトの情報が格納される。すなわち、このファイル"MovieObject.bdmv"が上述したオブジェクトレイヤに対応する。
【００４７】
ディレクトリ"PLAYLIST"は、プレイリストのデータベースが置かれるディレクトリである。すなわち、ディレクトリ"PLAYLIST"は、ムービープレイリストに関するファイルであるファイル"xxxxx.mpls"を含む。ファイル"xxxxx.mpls"は、ムービープレイリストのそれぞれに対して作成されるファイルである。ファイル名において、"."（ピリオド）の前の"xxxxx"は、５桁の数字とされ、ピリオドの後ろの"mpls"は、このタイプのファイルに固定的とされた拡張子である。
【００４８】
ディレクトリ"CLIPINF"は、クリップのデータベースが置かれるディレクトリである。すなわち、ディレクトリCLIPINF"は、クリップＡＶストリームファイルのそれぞれに対するクリップインフォメーションファイルであるファイル"zzzzz.clpi"を含む。ファイル名において、"."（ピリオド）の前の"zzzzz"は、５桁の数字とされ、ピリオドの後ろの"clpi"は、このタイプのファイルに固定的とされた拡張子である。
【００４９】
ディレクトリ"STREAM"は、実体としてのＡＶストリームファイルが置かれるディレクトリである。すなわち、ディレクトリ"STREAM"は、クリップインフォメーションファイルのそれぞれに対応するクリップＡＶストリームファイルを含む。クリップＡＶストリームファイルは、ＭＰＥＧ２(Moving Pictures Experts Group 2)のトランスポートストリーム（以下、ＭＰＥＧ２  ＴＳと略称する）からなり、ファイル名が"zzzzz.m2ts"とされる。ファイル名において、ピリオドの前の"zzzzz"は、対応するクリップインフォメーションファイルと同一することで、クリップインフォメーションファイルとこのクリップＡＶストリームファイルとの対応関係を容易に把握することができる。
【００５０】
ディレクトリ"AUXDATA"は、メニュー表示などに用いられる、サウンドファイル、フォントファイル、フォントインデックスファイルおよびビットマップファイルなどが置かれる。ファイル"sound.bdmv"は、ＨＤＭＶのインタラクティブなグラフィクスストリームのアプリケーションに関連したサウンドデータが格納される。ファイル名は、"sound.bdmv"に固定的とされる。ファイル"aaaaa.otf"は、字幕表示や上述したＢＤ−Ｊアプリケーションなどで用いられるフォントデータが格納される。ファイル名において、ピリオドの前の"aaaaa"は、５桁の数字とされ、ピリオドの後ろの"otf"は、このタイプのファイルに固定的とされた拡張子である。ファイル"bdmv.fontindex"は、フォントのインデックスファイルである。
【００５１】
ディレクトリ"META"は、メタデータファイルが格納される。ディレクトリ"BDJO"およびディレクトリ"JAR"は、上述のＢＤ−Ｊオブジェクトに関連するファイルが格納される。また、ディレクトリ"BACKUP"は、上述までの各ディレクトリおよびファイルのバックアップが格納される。これらディレクトリ"META"、ディレクトリ"BDJO"、ディレクトリ"JAR"およびディレクトリ"BACKUP"は、この発明の主旨と直接的な関わりがないので、詳細な説明を省略する。
【００５２】
上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるＲＯＭ(Read Only Memory)にあらかじめ記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにＢＤ−ＲＯＭの規格に従った動作をさせることから、ＢＤ仮想プレーヤと称される。
【００５３】
図７は、このＢＤ仮想プレーヤの動作を概略的に示す。図７Ａは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると（ステップＳ３０）、１のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される（ステップＳ３１）。そして、次のステップＳ３２で、プログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
【００５４】
図７Ｂは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態（ステップＳ４０）に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される（ＵＯ：User Operation）。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され（ステップＳ４１）、次のステップＳ４２で、プレイリストの再生フェイズに移行する。なお、この場合にレジスタがリセットされない実装としてもよい。
【００５５】
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図８を用いて説明する。ＵＯなどにより、タイトル番号＃１のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図２に示されるインデックステーブル(Index Table)を参照し、タイトル＃１のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル＃１のコンテンツ再生を実現するオブジェクトの番号が＃１であったとすると、プレーヤは、ムービーオブジェクト＃１の実行を開始する。
【００５６】
この図８の例では、ムービーオブジェクト＃１に記述されたプログラムは２行からなり、１行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト＃１の再生を開始する。プレイリスト＃１は、１以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト＃１中のプレイアイテムの再生が終了すると、ムービーオブジェクト＃１の実行に戻り、２行目のコマンドが実行される。図８の例では、２行目のコマンドが"jump TopMenu"であって、このコマンドが実行されインデックステーブルに記述されたトップメニュー(Top Menu)を実現するムービーオブジェクトの実行が開始される。
【００５７】
次に、この発明の実施の形態に適用可能な画像の表示系について説明する。この発明の実施の形態では、画像の表示系について、図９に一例が示されるようなプレーン構成を取る。動画プレーン１０は、最も後ろ側（ボトム）に表示され、プレイリストで指定された画像（主に動画データ）が扱われる。字幕プレーン１１は、動画プレーン１０の上に表示され、動画再生中に表示される字幕データが扱われる。インタラクティブグラフィクスプレーン１２は、最も前面に表示され、メニュー画面を表示するための文字データや、ボタン画像用のビットマップデータなどのグラフィクスデータが扱われる。１つの表示画面は、これら３つのプレーンが合成されて表示される。
【００５８】
なお、以下では、グラフィクスプレーン１２をインタラクティブグラフィクスプレーン１２と称する。
【００５９】
動画プレーン１０、字幕プレーン１１およびインタラクティブグラフィクスプレーン１２は、それぞれ独立して表示が可能とされ、例えば、図１０に一例が示されるような解像度および表示可能色を有する。動画プレーン１０は、解像度が１９２０画素×１０８０ラインで１画素当たりに換算したデータ長が１６ビットであって、輝度信号Ｙ、色差信号Ｃｂ、Ｃｒが４：２：２のシステム（以下、ＹＣｂＣｒ（４：２：２））とされる。なお、ＹＣｂＣｒ（４：２：２）は、各画素当たり輝度信号Ｙが８ビット、色差信号Ｃｂ、Ｃｒがそれぞれ８ビットで、色差信号Ｃｂ、Ｃｒが水平２画素で一つの色データを構成すると見なすカラーシステムである。インタラクティブグラフィクスプレーン１２および字幕プレーン１１は、１９２０画素×１０８０ラインで各画素のサンプリング深さが８ビットとされ、カラーシステムは、２５６色のパレットを用いた８ビットカラーマップアドレスとされる。
【００６０】
インタラクティブグラフィクスプレーン１２および字幕プレーン１１は、２５６段階のアルファブレンディングが可能とされており、他のプレーンとの合成の際に、不透明度を２５６段階で設定することが可能とされている。不透明度の設定は、画素毎に行うことができる。以下では、不透明度αが（０≦α≦１）の範囲で表され、不透明度α＝０で完全に透明、不透明度α＝１で完全に不透明であるものとする。
【００６１】
字幕プレーン１１では、例えばＰＮＧ(Portable Network Graphics)形式の画像データが扱われる。また、インタラクティブグラフィクスプレーン１２でも、例えばＰＮＧ形式の画像データを扱うことができる。ＰＮＧ形式は、１画素のサンプリング深さが１ビット〜１６ビットとされ、サンプリング深さが８ビットまたは１６ビットの場合に、アルファチャンネル、すなわち、それぞれの画素成分の不透明度情報（アルファデータと称する）を付加することができる。サンプリング深さが８ビットの場合には、２５６段階で不透明度を指定することができる。このアルファチャンネルによる不透明度情報を用いてアルファブレンディングが行われる。また、２５６色までのパレットイメージを用いることができ、予め用意されたパレットの何番目の要素（インデックス）であるかがインデックス番号により表現される。
【００６２】
なお、字幕プレーン１１およびインタラクティブグラフィクスプレーン１２で扱われる画像データは、ＰＮＧ形式に限定されない。ＪＰＥＧ方式など他の圧縮符号化方式で圧縮符号化された画像データや、ランレングス圧縮された画像データ、圧縮符号化がなされていないビットマップデータなどを扱うようにしてもよい。
【００６３】
図１１は、上述の図９および図１０に従い３つのプレーンを合成するグラフィクス処理部の一例の構成を示す。動画プレーン１０の動画データが４２２／４４４変換回路２０に供給される。動画データは、４２２／４４４変換回路２０でカラーシステムがＹＣｂＣｒ（４：２：２）からＹＣｂＣｒ（４：４：４）に変換され、乗算器２１に入力される。
【００６４】
字幕プレーン１１の画像データがパレット２２Ａに入力され、ＲＧＢ（４：４：４）の画像データとして出力される。この画像データに対してアルファブレンディングによる不透明度が指定されている場合には、指定された不透明度α１（０≦α１≦１）がパレット２２Ａから出力される。
【００６５】
図１２は、パレット２２Ａの入出力データの一例を示す。パレット２２Ａは、例えばＰＮＧ形式のファイルに対応したパレット情報がテーブルとして格納される。パレット２２Ａは、入力された８ビットの画素データをアドレスとして、インデックス番号が参照される。このインデックス番号に基づき、それぞれ８ビットのデータからなるＲＧＢ（４：４：４）のデータが出力される。それと共に、パレット２２Ａでは、不透明度を表すアルファチャンネルのデータαが取り出される。
【００６６】
図１３は、パレット２２Ａに格納される一例のパレットテーブルを示す。２５６個のカラーインデックス値〔０ｘ００〕〜〔０ｘＦＦ〕（〔０ｘ〕は１６進表記であることを示す）のそれぞれに対して、各々８ビットで表現される三原色の値Ｒ、ＧおよびＢと、不透明度αとが割り当てられる。パレット２２Ａは、入力されたＰＮＧ形式の画像データに基づきパレットテーブルが参照され、画像データにより指定されたインデックス値に対応する、それぞれ８ビットのデータからなるＲ、ＧおよびＢ各色のデータ（ＲＧＢデータ）と、不透明度αとを画素毎に出力する。
【００６７】
パレット２２Ａから出力されたＲＧＢデータは、ＲＧＢ／ＹＣｂＣｒ変換回路２２Ｂに供給され、各データ長が８ビットの輝度信号Ｙと色信号Ｃｂ、Ｃｒのデータに変換される（以下、まとめてＹＣｂＣｒデータと称する）。これは、以降のプレーン間合成を共通のデータ形式で行う必要があるためで、動画データのデータ形式であるＹＣｂＣｒデータに統一している。
【００６８】
ＲＧＢ／ＹＣｂＣｒ変換回路２２Ｂから出力されたＹＣｂＣｒデータと不透明度データα１とがそれぞれ乗算器２３に入力される。乗算器２３では、入力されたＹＣｂＣｒデータに不透明度データα１が乗ぜられる。乗算結果は、加算器２４の一方の入力端に入力される。なお、乗算器２３では、ＹＣｂＣｒデータにおける輝度信号Ｙ、色差信号Ｃｂ、Ｃｒのそれぞれについて、不透明度データα１との乗算が行われる。また、不透明度データα１の補数（１−α１）が乗算器２１に供給される。
【００６９】
乗算器２１では、４２２／４４４変換回路２０から入力された動画データに不透明度データα１の補数（１−α１）が乗ぜられる。乗算結果は、加算器２４の他方の入力端に入力される。加算器２４において、乗算器２１および２３の乗算結果が加算される。これにより、動画プレーン１０と字幕プレーン１１とが合成される。加算器２４の加算結果が乗算器２５に入力される。
【００７０】
インタラクティブグラフィクスプレーン１２の画像データがパレット２６Ａに入力され、ＲＧＢ（４：４：４）の画像データとして出力される。この画像データに対してアルファブレンディングによる不透明度が指定されている場合には、指定された不透明度α２（０≦α２≦１）がパレット２６Ａから出力される。パレット２６Ａから出力されたＲＧＢデータは、ＲＧＢ／ＹＣｂＣｒ変換回路２６Ｂに供給されてＹＣｂＣｒデータに変換され、動画データのデータ形式であるＹＣｂＣｒデータに統一される。ＲＧＢ／ＹＣｂＣｒ変換回路２６Ｂから出力されたＹＣｂＣｒデータが乗算器２７に入力される。
【００７１】
インタラクティブグラフィクスプレーン１２’で用いられる画像データがＰＮＧ形式である場合には、画像データ中に、画素毎に不透明度データα２（０≦α２≦１）を設定することができる。不透明度データα２は、乗算器２７に供給される。乗算器２７では、ＲＧＢ／ＹＣｂＣｒ変換回路２６から入力されたＹＣｂＣｒデータに対し、輝度信号Ｙ、色差信号Ｃｂ、Ｃｒのそれぞれについて、不透明度データα２との乗算が行われる。乗算器２７による乗算結果が加算器２８の一方の入力端に入力される。また、不透明度データα２の補数（１−α２）が乗算器２５に供給される。
【００７２】
乗算器２５では、加算器２４の加算結果に対して不透明度データα２の補数（１−α２）が乗ぜられる。乗算器２５の乗算結果は、加算器２８の他方の入力端に入力され、上述した乗算器２７による乗算結果と加算される。これにより、動画プレーン１０と字幕プレーン１１との合成結果に対して、さらに、インタラクティブグラフィクスプレーン１２が合成される。
【００７３】
字幕プレーン１１およびインタラクティブグラフィクスプレーン１２において、例えば、表示すべき画像の無い領域の不透明度α＝０と設定することで、そのプレーンの下に表示されるプレーンを透過表示させることができ、例えば動画プレーン１０に表示されている動画データを、字幕プレーン１１やインタラクティブグラフィクスプレーン１２の背景として表示することができる。
【００７４】
なお、この図１１に示される構成は、ハードウェアおよびソフトウェアの何れでも実現可能なものである。
【００７５】
次に、図１４を用いて、プレゼンテーショングラフィクス（ＰＧ）ストリームおよびインタラクティブグラフィクス（ＩＧ）ストリームについて説明する。上述したように、ＰＧストリームは、字幕を表示させるための字幕画像データによるストリームであって、より具体的には、例えばビットマップデータからなる字幕画像データそのものや、字幕画像データの表示方法を示すデータなどからなる。また、ＩＧストリームは、メニュー表示などに用いられるデータによるストリームであって、より具体的には、メニュー画面に用いられるボタン画像データ、ボタン画像データの表示方法を示すデータ、ボタンによって指示されるコマンドなどからなる。
【００７６】
ＰＧストリームおよびＩＧストリームは、クリップＡＶストリームに含まれ、１または複数のディスプレイセット(DisplaySet)からなるエポック(epoch)を単位として構成される。ディスプレイセットおよびエポックは、ＭＰＥＧ２(Moving Pictures Experts Group 2)で定義されるピクチャおよびＧＯＰ(Group Of Picture)にそれぞれ例えることができる。
【００７７】
すなわち、ディスプレイセットは、字幕表示上の最小単位であって、１枚の字幕画像に対応する。１または複数のディスプレイセットによりエポックが構成される。エポックは、一般的には、プレイアイテムに対応した単位で構成される。すなわち、あるプレイアイテムの再生中に表示される字幕を表示するためのディスプレイセットによりエポックが構成される。ＰＧストリームをデコードするＰＧデコーダは、字幕プレーン１１および各種のバッファをエポックの単位でクリアする。
【００７８】
ＰＧストリームの場合、図１４に例示されるように、１のエポックに複数のディスプレイセットを含めることができる。一方、ＩＧストリームは、１のエポックに含めることができるディスプレイセットは、例えば１個だけとされる。
【００７９】
実際には、エポックは、プレイアイテム単位に限らず、オーサリング側で任意に構成することができる。例えば、ＰＧストリームの場合、映画などにおいて一連の台詞に対応する複数の字幕のそれぞれを表示する複数のディスプレイセットによりエポックが構成される。また例えば、１つの台詞を文字毎に分解し、分解された文字それぞれを字幕として表示する複数のディスプレイセットによりエポックを構成することもできる。
【００８０】
図１５は、ディスプレイセットの構成を概略的に示す。プレゼンテーショングラフィクスのディスプレイセットは、図１５Ａに示されるように、ＰＣＳ(Presentation Composition Segment)、ＷＤＳ(Window Definision Segment)、ＰＤＳ(Palette Definition Segment)、ＯＤＳ(Object Definition Segment)およびＥＮＤセグメントの５種類のセグメントから構成される。詳細は後述するが、ＰＣＳは、字幕の基本情報が格納される。ＷＤＳは、ウィンドウと呼ばれる字幕を表示する表示枠を定義する。ＷＤＳは、エポック内で変化しない。ＰＤＳは、字幕の色情報を定義するもので、例えばインデックス化された色情報テーブルを内包する。また、ＯＤＳは、字幕の形状情報を保持するもので、例えば字幕を表示するためのビットマップデータが、ランレングス圧縮など所定の圧縮符号化方式で圧縮符号化されて格納される。また、ＥＮＤセグメントは、このディスプレイセットの終わりを示すセグメントである。
【００８１】
インタラクティブグラフィクスのディスプレイセットは、図１５Ｂに示されるように、ＩＣＳ(Interactive Composition Segment)、ＰＤＳ、ＯＤＳおよびＥＮＤセグメントの４種類のセグメントから構成される。４種類のセグメントのうち、ＩＣＳは、インタラクティブグラフィクスの基本構造を保持するためのセグメントである。ＰＤＳ、ＯＤＳおよびＥＮＤセグメントは、プレゼンテーショングラフィクスの場合と同様である。すなわち、ＰＤＳは、ボタン画像の色情報を保持するためのセグメントである。ＯＤＳは、ボタン画像の形状を保持するための情報である。より具体的には、ＯＤＳは、ボタン画像そのもの、例えばボタン画像を表示するためのビットマップデータが、ランレングス圧縮など所定の圧縮符号化方式で圧縮符号化されて格納される。また、ＥＮＤセグメントは、このディスプレイセットの終わりを示すセグメントである。
【００８２】
図１６は、プレゼンテーショングラフィクスのディスプレイセットに関する論理的な構造を概略的に示す。図１６Ａおよび図１６Ｂに例示されるように、ＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳおよびＥＮＤセグメント（図示しない）の４種類のセグメントが集まって、１つのディスプレイセットを構成する。ＰＣＳは、ディスプレイセット中に必ず１だけ存在する。ＷＤＳは、殆どの場合、ディスプレイセット中に１つだけ存在する。但し、後述するＰＣＳ中に定義されるフラグpalette_up_date_flagの値が"１"の場合は、ＷＤＳは、オプションである。ＰＤＳおよびＯＤＳは、オプションであって、ディスプレイセット中に存在しない場合もあり得る。
【００８３】
図１６Ｃに例示されるように、１または複数のディスプレイセットから、エポックが構成される。ここで、詳細は後述するが、ＰＣＳのブロックcomposition_discriptor()に含まれるフィールドcomposition_stateには、エポックスタートディスプレイセット(Epoch Start DisplaySet)を定義することができる。このエポックスタートディスプレイセットに基づき、エポックが定義される。一例として、エポックは、エポックスタートディスプレイセットがＰＣＳに定義されるディスプレイセットから、次のエポックスタートディスプレイセットがＰＣＳに定義されるディスプレイセットの１つ前のディスプレイセットまでのディスプレイセットが集まったものと定義される。エポックの定義の具体例については、後述する。図１６Ｄに例示されるように、プレゼンテーショングラフィクスストリーム（ＰＧストリーム）は、１または複数のエポックが含まれる。
【００８４】
図１７は、インタラクティブグラフィクスのディスプレイセットに関する論理的な構造を概略的に示す。図１７Ａに示されるように、インタラクティブグラフィクスのディスプレイセットは、プレゼンテーショングラフィクスのディスプレイセットに対してセグメントの構成が異なる以外は、全体的な階層構造は、プレゼンテーショングラフィクスのディスプレイセットと同一である。インタラクティブグラフィクスのディスプレイセットにおいても、ＩＣＳのブロックcomposition_discriptor()に含まれるフィールドcomposition_stateにより定義されるエポックスタートディスプレイセットに基づき、エポックが定義される。なお、インタラクティブグラフィクスにおいても、ＰＤＳおよびＯＤＳは、オプションであって、ディスプレイセット中に存在しない場合があり得る。インタラクティブグラフィクスのディスプレイセットについては、繁雑さを避けるために、詳細な説明を省略する。
【００８５】
図１８は、上述したようなディスプレイセットの一例の格納形式を示す。既に説明したように、字幕を表示するためのディスプレイセットは、プレゼンテーショングラフィクスストリームとして、ボタン画像を表示するためのディスプレイセットは、インタラクティブグラフィクスストリームとして、それぞれクリップＡＶストリームに多重化される。ディスプレイセットは、上述したように、複数種類のセグメントから構成される（図１８Ａ）。
【００８６】
ディスプレイセットを構成する複数種類のセグメントは、図１８Ｂに一例が示されるように、それぞれヘッダ情報により区別されてＰＥＳ(Packetized Elementary Stream)パケットのペイロードに格納される。ＰＥＳパケットは、最大サイズが６４ｋＢ（キロバイト）と決められているので、比較的サイズが大きなＯＤＳやＩＣＳは、１セグメントのサイズがこの最大サイズを越えた場合、分割されて複数のＰＥＳパケットのペイロードにそれぞれ詰め込まれる。一方、ＰＣＳ、ＷＤＳおよびＰＤＳは、サイズが６４ｋＢに満たない場合が多いため、１つのＰＥＳパケットに１プレゼンテーショングラフィクス分または１インタラクティブグラフィクス分のデータを格納可能である。ＰＥＳパケットのそれぞれには、ペイロードに格納されたデータがＰＣＳ、ＷＤＳ、ＰＤＳおよびＯＤＳのうち何れであるかの情報（プレゼンテーショングラフィクスの場合）や、パケット毎の順番などを示す識別情報がＰＥＳヘッダに格納される。
【００８７】
また、ＰＥＳヘッダには、このＰＥＳパケットのデコード時刻を指定するＤＴＳ(Decoding Time Stamp)と、デコードされたデータが出力される時刻を指定するＰＴＳ(Presantation Time Stamp)とが格納される。すなわち、ＰＥＳパケットのペイロードに格納されたデータは、ＭＰＥＧシステムズにより規定される基準復号器内部のＳＴＣ(System Time Clock)がＤＴＳに一致したときに、デコードが開始され、ＳＴＣがＰＴＳに一致したときに、デコードされたデータが出力される。
【００８８】
なお、ＰＴＳおよびＤＴＳは、オプションであって、そのＰＥＳパケットのペイロードに所定のアクセスユニットの先頭が含まれている場合に、ＰＥＳヘッダに付加される。例えば、１のセグメントが複数のＰＥＳパケットに分割されて格納されている場合には、セグメントの先頭側が格納されるＰＥＳパケットのみにＰＴＳおよびＤＴＳを持たせるようにできる。
【００８９】
ＰＥＳパケットのそれぞれは、さらに所定に分割され、ＭＰＥＧ  ＴＳ（トランスポートストリーム）によるトランスポートパケット（以下、ＴＳパケット）に詰め込まれる（図１８Ｃ）。ＴＳパケット毎の順序や、ＴＳパケットに格納されたデータを識別する識別情報などがＰＩＤ(Packet Identification)に格納される。
【００９０】
次に、各セグメントのうち、この発明に関わりが深いものについて、内容をより具体的に説明する。先ず、プレゼンテーショングラフィクスのディスプレイセットに含まれる、ＰＣＳおよびＷＤＳについて説明する。図１９は、ＰＣＳの一例の構造を表すシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるＣ言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
【００９１】
ブロックsegment_descriptor()は、フィールドsegment_typeおよびフィールドsegment_lengthからなる（図示しない）。フィールドsegment_typeは、このセグメントの種類を示す。フィールドsegment_typeの値が「０ｘ１６」で、このセグメントがＰＣＳであることが示される。なお、値の記述において「０ｘ」は、１６進表記であることを示す。フィールドsegment_lengthは、このフィールドsegment_length以降のこのセグメントの長さを示す。
【００９２】
ブロックvideo_descriptor()は、フィールドvideo_width、フィールドvideo_heightおよびフィールドframe_rateからなる（図示しない）。フィールドvideo_widthおよびフィールドvideo_heightは、このＰＣＳが含まれるディスプレイセットにより表示される字幕と同時に再生される動画像の画枠を示す。また、フィールドframe_rateは、当該動画像のフレームレートを示す。
【００９３】
ブロックcomposition_descriptor()は、フィールドcomposition_numberおよびフィールドcomposition_stateからなる（図示しない）。フィールドcomposition_numberは、このＰＣＳのエポック内での順番を示す。フィールドcomposition_stateは、このＰＣＳが含まれるディスプレイセットの種類を示す。
【００９４】
ディスプレイセットの種類について、概略的に説明する。ディスプレイセットは、エポックスタートディスプレイセット(Epoch Start DisplaySet)、エポックコンティニューディスプレイセット(Epoch Continue DisplaySet)、アキュジションポイントディスプレイセット(Acquisition Point DisplaySet)およびノーマルケースディスプレイセット(Normal Case DisplaySet)の４種類が定義される。
【００９５】
エポックスタートディスプレイセットは、エポックの先頭のディスプレイセットである。エポックコンティニューディスプレイセットは、エポックがプレイアイテムを跨ぐ場合に用いられるもので、例えばエポックがプレイアイテム＃１と次のプレイアイテム＃２とに跨っている場合に、プレイアイテム＃２の先頭にエポックコンティニューディスプレイセットが設けられる。
【００９６】
アキュジションポイントディスプレイセットは、字幕のデコードに関し、安全なデコード開始点を意味する。すなわち、プレーヤにおいて、ランダムアクセスが行われた場合、アクセス先がエポックの途中になる可能性が高い。そこで、プレーヤは、ランダムアクセス後、ストリームをデコードし再生していく中で、アキュジションポイントディスプレイセットを発見すると、そこから字幕のデコードを開始し字幕表示を行う。
【００９７】
ノーマルケースディスプレイセットは、字幕のデコードに関し、安全なデコード開始点ではないディプレイセットを意味する。例えば、他のディスプレイセットにより表示中の字幕の色や形状を変更したい場合に、変更の内容を記述したディスプレイセットをノーマルケースディスプレイセットに設定する。プレーヤは、字幕のデコードおよび再生中にこのノーマルケースディスプレイセットを発見すると、その内容に従い、現在表示中の字幕の色や形状などを変更する。
【００９８】
ＰＣＳのシンタクスの説明に戻り、フィールドpalette_update_flagは、パレットの更新が行われるか否かを示すフラグである。フィールドpalette_id_refは、このディスプレイセットにより表示される字幕１画面が参照するパレットのＩＤを示す。すなわち、このフィールドpalette_id_refにより、ＰＧストリームにおけるＰＤＳ中の色情報が参照される。
【００９９】
フィールドnumber_of_composition_objectsは、このディスプレイセットにより表示される字幕１画面上に存在するオブジェクトの数を示す。このフィールドnumber_of_composition_objectsで示される回数だけ、次のfor文によるループが繰り返され、ブロックcomposition_object()により、このディスプレイセットにより表示されるオブジェクト毎の定義がなされる。
【０１００】
図２０は、ブロックcomposition_object()の一例の構造を表すシンタクスを示す。フィールドobject_id_refは、このブロックcomposition_object()による字幕表示に用いるＯＤＳに対する参照を示す。フィールドwindow_id_refは、このブロックcomposition_object()による字幕表示に用いるオブジェクトが表示されるウィンドウのＩＤを示す。
【０１０１】
フィールドobject_cropped_flagは、このブロックcomposition_object()による字幕表示に用いるオブジェクトがクロップされるか否かを示すフラグである。すなわち、字幕表示は、ＯＤＳに保持されるサイズから所定サイズを切り出して表示することができる。フラグobject_cropped_flagがクロップすることを示していれば、後述するクロップサイズを示す情報に基づき切り取られた字幕が表示される。
【０１０２】
フィールドforced_on_flagは、このブロックcomposition_object()による字幕表示が、ユーザオペレーションによる字幕表示ＯＮ／ＯＦＦの指示に関わらず強制的に表示されるか否かを示す。
【０１０３】
フィールドcomposition_object_horizontal_positionおよびフィールドcomposition_object_vertical_positionは、それぞれこのブロックcomposition_object()による字幕表示の画面上の水平位置および垂直位置を示す。この水平位置および垂直位置は、例えば後述するＷＤＳに示されるウィンドウの位置情報に対する相対位置で示される。
【０１０４】
上述のフィールドobject_cropped_flagに示されるフラグの値がオブジェクトがクロップされることを示す値であれば、次のif(object_cropped_flag==1b)以下の記述がなされ、字幕を切り出す位置やサイズが指定される。すなわち、ブロックcropping_rectangle()内のフィールドobject_cropping_horizontal_positionおよびフィールドobject_cropping_vertical_positionにより、切り出す原点の水平位置および垂直位置が示され、フィールドobject_cropping_widthおよびフィールドobject_cropping_heightにより切り出す幅および高さが示される。
【０１０５】
図２１は、ＷＤＳの一例の構造を表すシンタクスを示す。ブロックsegment_descriptor()は、フィールドsegment_typeとフィールドsegment_lenghtとからなる（図示しない）。フィールドsegment_typeは、このセグメントの種類を示す。フィールドsegment_typeの値が「０ｘ１７」で、このセグメントがＷＤＳであることが示される。フィールドsegment_lengthは、このフィールドsegment_length以降のこのセグメントの長さを示す。
【０１０６】
フィールドnumber_of_windowsは、このＷＤＳが含まれるディスプレイセットにより表示される字幕１画面に存在するウィンドウの数を示す。このフィールドnumber_of_windowsで示される数だけ、次のfor文によるループが繰り返され、ブロックwindow()によりウィンドウ毎の定義がなされる。
【０１０７】
図２２は、ブロックwindow()の一例の構造を表すシンタクスを示す。フィールドwindow_idは、このウィンドウのＩＤを示す。フィールドwindow_horizontal_positionおよびフィールドwindow_vertical_positionは、このウィンドウの画面の原点に対する水平位置および垂直位置を示す。フィールドwindow_widthおよびフィールドwindow_heigthは、このウィンドウの幅および高さを示す。
【０１０８】
次にインタラクティブグラフィクスのディスプレイセットに含まれる、ＩＣＳについて説明する。ＩＣＳの説明に先んじて、図２３を用いてメニュー画面およびボタンの構成を概略的に示す。図２３Ａに一例が示されるような、複数のボタン３００、３００、・・・が配置されたメニュー画面１１を考える。
【０１０９】
このメニュー画面３０１は、図２３Ｂに一例が示されるように、複数枚のメニュー画面によって階層的に構成することができる。例えば、最前面に表示されたメニュー画面のあるボタン３００を、所定の入力手段によって選択状態から実行状態に遷移させると、そのメニュー画面の１枚後ろに位置するメニュー画面が最前面のメニュー画面となるような構成が考えられる。なお、以下では、「所定の入力手段によりボタンの状態を変化させる」ことを、煩雑さを避けるために、「ボタンを操作する」などと、適宜、表記する。
【０１１０】
メニュー画面３０１に表示される１つのボタン３００は、複数のボタン３０２Ａ、３０２Ｂ、・・・が階層化された構成とすることができる（図２３Ｃおよび図２３Ｄ参照）。これは、換言すれば、１つのボタン表示位置に複数のボタンを選択的に表示することができることを意味する。例えば、複数のボタンのうち所定のボタンを操作した際に、同時に表示されている他の幾つかのボタンの機能および表示が変更されるような場合に、メニュー画面自体を書き換える必要が無いので、用いて好適である。このような、１つのボタン位置に選択的に表示される複数のボタンからなる組を、ＢＯＧｓ(Button Overlap Group)と呼ぶ。
【０１１１】
ＢＯＧｓを構成するボタンのそれぞれは、通常状態、選択状態および実行状態の３状態を有することができる。すなわち、図２３Ｅに一例が示されるように、ＢＯＧｓを構成するボタンのそれぞれに対して、通常状態、選択状態および実行状態をそれぞれ表すボタン３０３Ａ、３０３Ｂおよび３０３Ｃを用意することができる。さらに、これら３状態を表すボタン３０３Ａ、３０３Ｂおよび３０３Ｃのそれぞれに対して、図２３Ｆに一例が示されるように、アニメーション表示を設定することができる。この場合には、アニメーション表示が設定されたボタンは、アニメーション表示に用いるだけの枚数のボタン画像からなることになる。
【０１１２】
なお、以下では、ボタンのアニメーションを構成するための複数枚のボタン画像のそれぞれを適宜、アニメーションフレームと呼ぶことにする。
【０１１３】
図２４は、ＩＣＳのヘッダ情報の一例の構造を表すシンタクスを示す。ＩＣＳのヘッダは、ブロックsegment_descriptor()、ブロックvideo_descriptor()、ブロックcomposition_descriptor()、ブロックsequence_descriptor()およびブロックinteractive_composition_data_fragemnt()からなる。ブロックsegment_descriptor()は、このセグメントがＩＣＳであることを示す。ブロックvideo_descriptor()は、このメニューと同時に表示されるビデオのフレームレートや画枠サイズを示す。ブロックcomposition_descriptor()は、フィールドcomposition_stateを含み（図示しない）、このＩＣＳのステータスを示す。ブロックsequence_descriptor()は、このＩＣＳが複数のＰＥＳパケットに跨るか否かを示す。
【０１１４】
より具体的には、このブロックsequence_descriptor()は、現在のＰＥＳパケットに含まれるＩＣＳが１つのＩＧストリームの先頭または最後尾の何れのＩＣＳであるか否かを示す。
【０１１５】
すなわち、上述したように、データサイズが６４ＫＢと固定的とされたＰＥＳパケットに対して、ＩＣＳのデータサイズが大きい場合には、ＩＣＳが所定に分割されてＰＥＳパケットにそれぞれ詰め込まれる。このとき、この図２４に示されるヘッダ部分は、ＩＣＳが分割して詰め込まれたＰＥＳパケットのうち先頭および最後尾のＰＥＳパケットにだけあればよく、途中のＰＥＳパケットにおいては省略することができる。このブロックsequence_descriptor()が先頭および最後尾を示していれば、ＩＣＳが１つのＰＥＳパケットに収まっていることが分かる。
【０１１６】
図２５は、ブロックinteractive_composition_data_fragemnt()の一例の構造を表すシンタクスを示す。なお、図２５では、自身のブロックがブロックinteractive_composition()として示されている。フィールドintaractive_composition_lengthは、２４ビットのデータ長を有し、ブロックinteractive_composition()のこのフィールドintaractive_composition_length以降の長さを示す。フィールドstream_modelは、１ビットのデータ長を有し、このストリームが多重化されているか否かを示す。すなわち、インタラクティブグラフィクスストリームは、ＡＶストリームに対して多重化することもできるし、単独でクリップＡＶストリームを構成することもできる。
【０１１７】
フィールドuser_interface_modelは、１ビットのデータ長を有し、このストリームが表示するメニューがポップアップメニューか、常時表示メニューの何れであるかを示す。ポップアップメニューは、例えばリモートコントロールコマンダのボタンのＯＮ／ＯＦＦといった、所定の入力手段で表示の有無を制御できるメニューである。一方、常時表示メニューは、ユーザ操作により表示の有無を制御できない。フィールドuser_interface_modelの値が"０"で、ポップアップメニューを示し、"１"で常時表示メニューを示す。
【０１１８】
フィールドuser_interface_modelの値が"０"であれば、If文If(stream_model=='0b'以下のフィールドcomposition_time_out_ptsおよびフィールドselection_time_out_ptsが有効になる。フィールドcomposition_time_out_ptsは、３３ビットのデータ長を有し、このメニュー表示が消える時刻を示す。また、フィールドselection_time_out_ptsは、３３ビットのデータ長を有し、このメニュー表示における選択操作が可能でなくなる時刻を示す。時刻は、それぞれＭＰＥＧ２に規定されるＰＴＳ(Presentation Time Stamp)で記述される。
【０１１９】
フィールドuser_time_out_durationは、２４ビットのデータ長を有し、このメニュー表示の自動初期化時間を示す。次のフィールドnumber_of_pageは、８ビットのデータ長を有し、このメニューが有するページ数を、初期値を"０"として示す。すなわち、このメニュー表示が図２３Ｂを用いて説明した階層構造を有し、複数のページを有するときは、フィールドnumber_of_pageの値は、"１"以上を示す。このフィールドnumber_of_pageで示された回数だけ、次のfor文からのループが繰り返され、メニュー表示における各ページがそれぞれ定義される。
【０１２０】
図２６は、ブロックpage()の一例の構造を表すシンタクスを示す。フィールドpage_idは、８ビットのデータ長を有し、このページを識別するためのＩＤを示し、フィールドpage_version_numberは、８ビットのデータ長を有し、このページのバージョン番号を示す。次のブロックUO_mask_table()は、このページの表示中に禁止される、ユーザの入力手段に対する操作（ＵＯ：User Operation)が記述されるテーブルを示す。
【０１２１】
ブロックin_effect()は、このページが表示される際に表示されるアニメーションブロックを示す。括弧{}内のブロックeffect_sequence()に、アニメーションのシーケンスが記述される。また、ブロックout_effect()は、このページが終了する際に表示されるアニメーションブロックを示す。括弧{}内のブロックeffect_sequence()に、アニメーションのシーケンスが記述される。これらブロックin_effect()およびブロックout_effect()は、それぞれページを移動した際にこのＩＣＳが発見された場合に実行されるアニメーションである。
【０１２２】
次のフィールドanimation_frame_rate_codeは、８ビットのデータ長を有し、このページのボタン画像がアニメーションする場合の、アニメーションフレームレートの設定パラメータを示す。例えば、このＩＣＳが対応するクリップＡＶストリームファイルにおけるビデオデータのフレームレートをＶfrm、当該アニメーションフレームレートをＡfrmとした場合、フィールドanimation_frame_rate_codeの値を、Ｖfrm／Ａfrmのように、これらの比で表すことができる。
【０１２３】
フィールドdefault_selected_button_id_refは、１６ビットのデータ長を有し、このページが表示される際に最初に選択状態とされるボタンを指定するためのＩＤを示す。また、次のフィールドdefault_activated_button_id_refは、１６ビットのデータ長を有し、図２５を用いて説明したフィールドselection_time_out_ptsで示される時間に達した際に、自動的に実行状態となるボタンを指定するためのＩＤを示す。
【０１２４】
フィールドpalette_id_refは、８ビットのデータ長を有し、このページが参照するパレットのＩＤを示す。すなわち、このフィールドpalette_id_refにより、ＩＧストリームにおけるＰＤＳ中の色情報が指定される。
【０１２５】
次のフィールドnumber_of_BOGsは、８ビットのデータ長を有し、このページで用いられるＢＯＧｓの数が示される。このフィールドnumber_of_BOGsで示される回数だけ、次のfor文からのループが繰り返され、ブロックbutton_overlap_group()により、ＢＯＧｓ毎の定義がなされる。
【０１２６】
図２７は、ブロックbutton_overlap_group()の一例の構造を表すシンタクスを示す。フィールドdefault_valid_button_id_refは、１６ビットのデータ長を有し、このブロックbutton_overlap_group()で定義されるＢＯＧｓにおいて最初に表示されるボタンのIDを示す。次のフィールドnumber_of_buttonsは、８ビットのデータ長を有し、このＢＯＧｓで用いられるボタンの数を示す。そして、このフィールドnumber_of_buttonsで示される回数だけ、次のfor文からのループが繰り返され、ブロックbutton()によりボタンそれぞれの定義がなされる。
【０１２７】
すなわち、既に説明したように、ＢＯＧｓは、複数のボタンを持つことができ、ＢＯＧｓが持つ複数のボタンのそれぞれの構造がブロックbutton()で定義される。このブロックbutton()で定義されるボタン構造が、実際に表示されるボタンである。
【０１２８】
図２８は、ブロックbutton()の一例の構造を表すシンタクスを示す。フィールドbutton_idは、１６ビットのデータ長を有し、このボタンを識別するＩＤを示す。フィールドbutton_numeric_select_valueは、１６ビットのデータ長を有し、このボタンがリモートコントロールコマンダ上の数字キーの何番に割り当てられているかを示す。フラグauto_action_flagは、１ビットのデータ長を有するフラグであって、このボタンが選択状態になったときに、当該ボタンに割り当てられた機能が自動的に実行されるか否かを示す。
【０１２９】
次のフィールドbutton_horizontal_positionおよびフィールドbutton_vertical_positioは、それぞれ１６ビットのデータ長を有し、このボタンを表示する画面上の水平方向の位置および垂直方向の位置（高さ）を示す。
【０１３０】
ブロックneighbor_info()は、このボタンの周辺情報を示す。すなわち、このブロックneighbor_info()内の値により、このボタンが例えば選択状態となっている状態からリモートコントロールコマンダにおける上下左右の方向を指示できる方向キーが操作された際に、どのボタンが選択状態に遷移するかを示す。ブロックneighbor_info()内のフィールドにおいて、それぞれ１６ビットのデータ長を有するフィールドupper_button_id_ref、フィールドlower_button_id_ref、フィールドleft_button_id_refおよびフィールドright_button_id_refは、上方向、下方向、左方向および右方向を指示する操作がなされた場合に選択状態に遷移されるボタンのＩＤをそれぞれ示す。
【０１３１】
次からのブロックnormal_state_info()、ブロックselected_state_info()およびブロックactivated_state_info()は、それぞれ、通常状態、選択状態および実行状態時のボタンの情報を示す。
【０１３２】
先ず、ブロックnormal_state_info()について説明する。それぞれ１６ビットのデータ長を有するフィールドnormal_start_object_id_refおよびフィールドnormal_end_object_id_refは、この通常状態のボタンのアニメーションの先頭および末尾のオブジェクトを指定するＩＤがそれぞれ示される。すなわち、これらフィールドnormal_start_object_id_refおよびフィールドnormal_end_object_id_refにより、ボタンのアニメーション表示に用いられるボタン画像（すなわちアニメーションフレーム）が、対応するＯＤＳに対して指定される。
【０１３３】
次のフラグnormal_repeat_flagは、１ビットのデータ長を有するフラグであって、このボタンのアニメーションがリピートするか否かが示される。例えば、フラグnormal_repeat_flagの値が"０"でリピートしないことを示し、値が"１"でリピートすることを示す。
【０１３４】
次のフラグnormal_complete_flagは、１ビットのデータ長を有するフラグであって、このフラグがこの発明により定義される。このフラグnormal_complete_flagは、このボタンが通常状態から選択状態に遷移する際のアニメーション動作を制御するフラグである。
【０１３５】
すなわち、フラグnormal_complete_flagの値が"１"であれば、このボタンが通常状態から選択状態へと遷移する際に、通常状態に定義されているアニメーションを、全て表示する。より具体的には、フラグnormal_complete_flagの値が"１"であったなら、当該ボタンの通常状態のアニメーション表示中に当該ボタンを通常状態から選択状態に遷移させるような入力がなされた場合、その時点で表示されているアニメーションフレームから、上述したフィールドnormal_end_object_id_refで示されるアニメーションフレームまで、アニメーション表示を行う。
【０１３６】
また、フラグnormal_complete_flagの値が"１"であって、且つ、フラグnormal_repeat_flagがリピートすることを示している場合（例えば値"１"）も、その時点で表示されているアニメーションフレームから、上述したフィールドnormal_end_object_id_refで示されるアニメーションフレームまで、アニメーション表示を行う。
【０１３７】
この場合、例えばボタンが選択できない状態にされた場合や、ボタンの表示そのものが消されてしまうような場合でも、これらの状態に遷移する時点がアニメーションの表示中であれば、フィールドnormal_end_object_id_refで示されるアニメーションフレームまでアニメーション表示を行い、その後、ボタンの状態を遷移させる。
【０１３８】
ボタンが選択できない状態は、例えば上述したフィールドselection_time_out_ptsの指定により、ボタンが選択できないような状態になった場合や、フィールドuser_time_out_durationの指定によりメニューが自動的に初期化されるような場合が考えられる。
【０１３９】
一方、フラグnormal_complete_flagの値が"０"であれば、このボタンが通常状態から選択状態へと遷移する際に、通常状態のボタンに定義されたアニメーションをフィールドnormal_end_object_id_refで示されるアニメーションフレームまで表示せずに、状態の遷移が指示された時点でアニメーション表示を停止し、選択状態のボタンを表示する。
【０１４０】
次に、ブロックselected_state_info()について説明する。このブロックselected_state_info()は、上述のブロックnormal_state_info()に対して、サウンドを指示するためのフィールドselected_state_sound_id_refが付加されている。フィールドselected_state_sound_id_refは、８ビットのデータ長を有し、この選択状態のボタンに対して再生されるサウンドファイルを示す。例えば、サウンドファイルは、ボタンが通常状態から選択状態に遷移した際の効果音として用いられる。
【０１４１】
それぞれ１６ビットのデータ長を有するフィールドselected_start_object_id_refおよびフィールドselected_end_object_id_refは、この選択状態のボタンのアニメーションの先頭および末尾のオブジェクトを指定するＩＤがそれぞれ示される。また、次の１ビットのデータ長を有するフラグであるフラグselected_repeat_flagは、このボタンのアニメーションがリピートするか否かが示される。例えば値が"０"でリピートしないことを示し、値が"１"でリピートすることを示す。
【０１４２】
次のフラグselected_complete_flagは、１ビットのデータ長を有するフラグであって、上述のフラグnormal_complete_flagと共に、この発明により定義されるフラグである。このフラグselected_complete_flagは、このボタンが選択状態から他の状態に遷移する際のアニメーション動作を制御するフラグである。すなわち、フラグselected_complete_flagは、ボタンが選択状態から実行状態に遷移する場合と、選択状態から通常状態に遷移する場合とに、用いることができる。
【０１４３】
上述と同様、フラグselected_complete_flagの値が"１"であれば、このボタンが選択状態から他の状態へと遷移する際に、選択状態に定義されているアニメーションを、全て表示する。より具体的には、フラグselected_complete_flagの値が"１"であったなら、当該ボタンの選択状態のアニメーション表示中に当該ボタンを選択状態から他の状態に遷移させるような入力がなされた場合、その時点で表示されているアニメーションフレームから、上述したフィールドselected_end_object_id_refで示されるアニメーションフレームまで、アニメーション表示を行う。
【０１４４】
また、フラグselected_complete_flagの値が"１"であって、且つ、フラグselected_repeat_flagがリピートすることを示している場合（例えば値"１"）も、その時点で表示されているアニメーションフレームから、上述したフィールドselected_end_object_id_refで示されるアニメーションフレームまで、アニメーション表示を行う。
【０１４５】
この場合、例えばボタンが選択できない状態にされた場合や、ボタンの表示そのものが消されてしまうような場合でも、これらの状態に遷移する時点がアニメーションの表示中であれば、フィールドselected_end_object_id_refで示されるアニメーションフレームまでアニメーション表示を行い、その後、ボタンの状態を遷移させる。
【０１４６】
ボタンが選択できない状態は、例えば上述したフィールドselection_time_out_ptsの指定により、ボタンが選択できないような状態になった場合や、フィールドuser_time_out_durationの指定によりメニューが自動的に初期化されるような場合が考えられる。
【０１４７】
一方、フラグselected_complete_flagの値が"０"であれば、このボタンが選択状態から他の状態へと遷移する際に、選択状態のボタンに定義されたアニメーションをフィールドselected_end_object_id_refで示されるアニメーションフレームまで表示せずに、状態の遷移が指示された時点でアニメーション表示を停止し、他の状態のボタンを表示する。
【０１４８】
次のブロックactivated_state_info()は、上述したブロックnormal_state_info()およびブロックselected_state_info()に対して、アニメーションのリピートを行うか否かを示すフラグと、ボタンが実行状態から他の状態に遷移する際のアニメーション動作を制御するフラグが定義されない。ボタンが実行状態にされた後は、当該ボタンに割り当てられた機能が実行されることになり、ボタンが実行状態にある時間は非常に短いと考えられる。また、実行状態にあるボタンが他の状態に遷移するような制御も、一般的には好ましくないといえる。そのため、ブロックactivated_state_info()において、これらのフラグを省略している。勿論、ブロックactivated_state_info()においてこれらのフラグを定義することも可能である。
【０１４９】
ブロックactivated_state_info()において、フィールドactivated_state_sound_id_refは、８ビットのデータ長を有し、この実行状態のボタンに対して再生されるサウンドファイルを示す。それぞれ１６ビットのデータ長を有するフィールドactivated_start_object_id_refおよびフィールドactivated_end_object_id_refは、この実行状態のボタンのアニメーションの先頭および末尾のアニメーションフレームを指定するＩＤがそれぞれ示される。
【０１５０】
ブロックactivated_state_info()の説明を終わり、次のフィールドnumber_of_navigation_commandsは、１６ビットのデータ長を有し、このボタンに埋め込まれるコマンドの数を示す。そして、このフィールドnumber_of_navigation_commandsで示される回数だけ、次のfor文からのループが繰り返され、このボタンにより実行されるコマンドnavigation_command()が定義される。これは、換言すれば、１つのボタンから複数のコマンドを実行させることができることを意味する。
【０１５１】
次に、現時点のＢＤ−ＲＯＭ規格に定義されるプレゼンテーショングラフィクスおよびインタラクティブグラフィクスのデコーダモデルについて説明する。図２９は、プレゼンテーショングラフィクスおよびインタラクティブグラフィクスに共通して適用可能なデコーダモデルを示す。
【０１５２】
先ず、ディスクがプレーヤに装填されると、インデックスファイル"index.bdmv"およびムービーオブジェクトファイル"MovieObject.bdmv"がディスクから読み込まれ、所定にトップメニューが表示される。トップメニューの表示に基づき、再生するタイトルを指示すると、ムービーオブジェクトファイル中の対応するナビゲーションコマンドにより、指示されたタイトルを再生するためのプレイリストファイルが呼び出される。そして、当該プレイリストファイルの記述に従い、プレイリストから再生を要求されたクリップＡＶストリームファイル、すなわち、ＭＰＥＧ２のトランスポートストリームがディスクから読み出される。
【０１５３】
トランスポートストリームは、ＴＳパケットとしてＰＩＤフィルタ１００に供給されてＰＩＤが解析される。ＰＩＤフィルタ１００では、供給されＴＳパケットがビデオデータ、オーディオデータ、メニューデータおよびサブタイトル（字幕）データの何れを格納したパケットであるかを分類する。ＰＩＤがメニューデータすなわちインタラクティブグラフィクスを表している場合、または、サブタイトルすなわちプレゼンテーショングラフィクスを表している場合に、図２９の構成が有効とされる。
【０１５４】
ＰＩＤフィルタ１００において、トランスポートストリームからデコーダモデルが対応するデータを格納するＴＳパケットが選択されて、トランスポートバッファ（以下、ＴＢ：Transport Buffer）１０１に溜め込まれる。そして、ＴＢ１０１上でＴＳパケットのペイロードに格納されているデータが取り出される。ＰＥＳパケットを構成可能なだけのデータがＴＢ１０１に溜め込まれたら、ＰＩＤに基づきＰＥＳパケットが再構築される。すなわち、この段階で、ＴＳパケットに分割されていた各セグメントがそれぞれ統合されることになる。
【０１５５】
各セグメントによるＰＥＳパケットは、ＰＥＳヘッダが取り除かれエレメンタリストリーム形式でデコーダ１０２にそれぞれ供給され、ＣＤＢ(コーデッドデータバッファ：Coded Data Buffer)１１０に一旦溜め込まれる。ＳＴＣに基づき、ＣＤＢ１１０に溜め込まれたエレメンタリストリームのうち、対応するＤＴＳに示される時刻に達したエレメンタリストリームがあれば、当該セグメントは、ＣＤＢ１１０から読み出されてストリームグラフィックプロセッサ１１１に転送され、それぞれデコードされセグメントに展開される。
【０１５６】
ストリームグラフィックプロセッサ１１１は、デコードが完了したセグメントを、ＤＢ(デコーデッドオブジェクトバッファ：Decoded Object Buffer)１１２またはＣＢ(コンポジションバッファ：Composition Buffer)１１３に所定に格納する。ＰＣＳ、ＩＣＳ、ＷＤＳおよびＯＤＳのようにＤＴＳを持つタイプのセグメントであれば、対応するＤＴＳに示されるタイミングで、ＤＢ１１２またはＣＢ１１３に格納する。また、ＰＤＳのようにＤＴＳを持たないタイプのセグメントは、即座にＣＢ１１３に格納される。
【０１５７】
グラフィクスコントローラ１１４は、セグメントを制御する。例えば、このデコーダモデルがプレゼンテーショングラフィクスによるデータ（以下、ＰＧデータ）に対応するモデルである場合、グラフィクスコントローラ１１４は、ＣＢ１１３からＰＣＳを、対応するＰＴＳに示されるタイミングで読み出すと共に、当該ＰＣＳにより参照されるＷＤＳおよびＰＤＳを読み出す。また、グラフィクスコントローラ１１４は、当該ＰＣＳから参照されるＯＤＳをＤＢ１１２から読み出す。そして、読み出されたＰＣＳおよびＷＤＳ、ならびに、ＯＤＳをそれぞれデコードし、字幕を表示するためのデータを形成し、グラフィクスプレーン１０３に書き込む。
【０１５８】
同様に、例えばこのデコーダモデルがインタラクティブグラフィクスによるデータ（以下、ＩＧデータ）に対応するモデルである場合、グラフィクスコントローラ１１４は、ＣＢ１１３からＩＣＳを、当該ＩＣＳに対応するＰＴＳに示されるタイミングで読み出すと共に、当該ＩＣＳにより参照されるＰＤＳを読み出す。また、グラフィクスコントローラ１１４は、当該ＩＣＳから参照されるＯＤＳをＤＢ１１２から読み出す。そして、読み出されたＩＣＳおよびＯＤＳをそれぞれデコードし、ボタン画像などメニュー画面を表示するためのデータを形成し、グラフィクスプレーン１０３に書き込む。
【０１５９】
また、グラフィクスコントローラ１１４は、ＣＢ１１３から読み出されたＰＤＳをデコードして、例えば図１３を用いて説明したようなカラーパレットテーブルを形成し、ＣＬＵＴ１０４に書き込む。
【０１６０】
グラフィクスプレーン１０３に書き込まれた画像イメージは、所定のタイミング、例えばフレームタイミングで読み出され、ＣＬＵＴ１０４のカラーパレットテーブルが参照されて色情報が付加されて出力画像データが構成され、この出力画像データが出力される。プレーヤの仕様によっては、グラフィクスプレーン１０３から読み出されたデータに対してＣＬＵＴ１０４のカラーパレットテーブルに基づく色情報を付加した字幕画像データを、さらにフレームメモリに書き込む場合も考えられる。
【０１６１】
なお、エポックの更新に伴い、グラフィクスコントローラ１１４によりＤＢ１１２、ＣＢ１１３、グラフィクスプレーン１０３およびＣＬＵＴ１０４がクリアされる。これらバッファやプレーンのクリアは、ＣＤＢ１１０から読み出されてデコードされたＰＣＳまたはＩＣＳにおけるブロックcomposition_descriptor()中のフィールドcomposition_stateの記述が、このディスプレイセットがエポックスタートディスプレイセットであることを示している場合に、行われる。エポックの更新に伴い、ＣＤＢ１１０を共にクリアすることも可能である。
【０１６２】
ここで、エポックの定義について説明する。既に説明したように、プレゼンテーショングラフィクスおよびインタラクティブグラフィクスにおいて、エポックは、エポックスタートディスプレイセットに基づき定義される。
【０１６３】
プレゼンテーショングラフィクスについては、次の項目（１）および項目（２）で示す２項目のうち短い方がエポックとして定義される。
【０１６４】
項目（１）：エポックスタートディスプレイセットがＰＣＳに定義されるディスプレイセットから、次のエポックスタートディスプレイセットがＰＣＳに定義されるディスプレイセットの１つ前のディスプレイセットまで。
項目（２）：エポックスタートディスプレイセットがＰＣＳに定義されるディスプレイセットからそのＰＧデータが関連するプレイリストの最後まで。
【０１６５】
なお、より具体的には、項目（１）の場合、エポックスタートディスプレイセットが定義されるＰＣＳのＰＴＳから、次のエポックスタートディスプレイセットが定義されるＰＣＳのＰＴＳまでがエポックとされる。項目（２）の場合も同様に、エポックスタートディスプレイセットが定義されるＰＣＳのＰＴＳから、当該ディスプレイセットが参照されるプレイリストの最後までがエポックとされる。
【０１６６】
インタラクティブグラフィクスについては、次の項目（３）、項目（４）および項目（５）のうち、最も短いものがエポックとして定義される。
【０１６７】
項目（３）：エポックスタートディスプレイセットがＩＣＳに定義されるディスプレイセットから、当該ＩＣＳのフィールドcomposition_time_out_ptsに定義される時刻まで。
項目（４）：エポックスタートディスプレイセットがＩＣＳに定義されるディスプレイセットから、次のエポックスタートディスプレイセットがＩＣＳに定義されるディスプレイセットの１つ前のディスプレイセットまで。
項目（５）：エポックスタートディスプレイセットがＩＣＳに定義されるディスプレイセットから当該ＩＧデータが関連するプレイリストの最後まで。
【０１６８】
図３０は、グラフィクスデコーダ１０２における、ＰＧデータに関するディスプレイセット単位での一例の処理を示すフローチャートである。ステップＳ１０で、ＰＩＤフィルタ１００によりＴＳパケットからＰＩＤに基づきＰＧデータが格納されたパケットが取得され、ＴＢ１０１に溜め込まれる。次のステップＳ１１で、ＴＢ１０１にＰＥＳパケットを構成可能なだけのＴＳパケットが溜め込まれたら、ＰＩＤに基づきＴＳパケットのペイロードからデータが取り出され、ＰＥＳパケットが再構築される。ＰＥＳパケットは、ＰＥＳヘッダが取り除かれてエレメンタリストリーム形式でＣＤＢ１１０に転送される。
【０１６９】
ＰＥＳパケットから取り出されたエレメンタリストリームは、ストリームグラフィックプロセッサ１１１においてセグメントに展開される（ステップＳ１２）。そして、次のステップＳ１３〜ステップＳ１７までで、展開されたセグメントがＰＣＳ、ＷＤＳ、ＰＤＳおよびＯＤＳの何れであるか、若しくは、ＥＮＤセグメントであるか否かが判別され、判別結果に応じた処理が行われる。セグメントの種類は、上述の図１９や図２１などを用いて説明したように、シンタクスの先頭のブロックsegment_description()における最初のフィールドsegment_typeに基づき判別できる。なお、図示しないが、ＷＤＳおよびＯＤＳも、同様の方法でセグメントの種類を判別可能である。
【０１７０】
ステップＳ１３で、セグメントがＰＣＳであるか否かが判別される。若し、セグメントがＰＣＳであると判別されれば、処理はステップＳ１９に移行され、図１９を用いて説明したＰＣＳのシンタクスにおけるブロックcomposition_descriptor()内のフィールドcomposition_stateに基づき、このＰＣＳが含まれるディスプレイセットがエポックスタートディスプレイセットであるか否かが判断される。
【０１７１】
若し、当該ディスプレイセットがエポックスタートディスプレイセットであると判断されれば、処理はステップＳ２０に移行され、字幕表示に関わるバッファのクリアがなされる。例えば、ＤＢ１１２およびＣＢ１１３がステップＳ２０でクリアされる。このとき、ＣＤＢ１１０を共にクリアすることも可能である。そして、次のステップＳ２１で、クリアされ空になったＣＢ１１３に、ＤＴＳのタイミングでＰＣＳが書き込まれる。ＣＢ１１３へのＰＣＳの書き込みが終了すると、処理はステップＳ１０に戻され、パケットの取得が継続される。
【０１７２】
一方、ステップＳ１９で、ＰＣＳがエポックスタートディスプレイセットではないと判断されれば、処理はステップＳ２２に移行され、ＰＣＳがＣＢ１１３にＤＴＳのタイミングで書き込まれる。このとき、ＰＣＳは、ＣＢ１１３の空き領域に所定に書き込まれる。
【０１７３】
上述のステップＳ１３で、セグメントがＰＣＳではないと判別されれば、処理はステップＳ１４に移行され、セグメントがＷＤＳであるか否かが判別される。若し、セグメントがＷＤＳであると判別されれば、処理はステップＳ２３に移行され、ＷＤＳがＣＢ１１３にＤＴＳのタイミングで書き込まれる。ＣＢ１１３へのＷＤＳの書き込みが終了すると、処理はステップＳ１０に戻され、パケットの取得が継続される。ステップＳ１４でセグメントがＷＤＳではないと判別されれば、処理はステップＳ１５に移行される。
【０１７４】
ステップＳ１５では、セグメントがＰＤＳであるか否かが判別される。若し、セグメントがＰＤＳであると判別されれば、処理はステップＳ２４に移行され、ＰＤＳが即座にＣＢ１１３に書き込まれる。これは、ＰＤＳは、ＰＴＳしか定義されず、ＤＴＳを持たないので、ＰＤＳであると判別された時点で、即座にＣＢ１１３に書き込まれる。ＣＢ１１３へのＷＤＳの書き込みが終了すると、処理はステップＳ１０に戻され、パケットの取得が継続される。ステップＳ１５でセグメントがＰＤＳではないと判別されれば、処理はステップＳ１６に移行される。
【０１７５】
ステップＳ１６では、セグメントがＯＤＳであるか否かが判別される。若し、セグメントがＯＤＳであると判別されれば、処理はステップＳ２５に移行され、ＯＤＳに格納された、ランレングス処理されたビットマップデータがＤＴＳのタイミングでデコードされ、ＤＢ１１２に書き込まれる。ＤＢ１１２へのＯＤＳの書き込みが終了すると、処理はステップＳ１０に戻され、パケットの取得が継続される。ステップＳ１６でセグメントがＯＤＳではないと判別されれば、処理はステップＳ１７に移行される。
【０１７６】
ステップＳ１７では、セグメントがディスプレイセットの最後尾を示すＥＮＤセグメントであるか否かが判断される。若し、セグメントがＥＮＤセグメントであると判別されれば、このディスプレイセットに関する一連の処理が終了される。
【０１７７】
一方、ステップＳ１７で、セグメントがＥＮＤセグメントではないと判別されれば、処理はステップＳ１８に移行される。すなわち、この場合には、何らかのエラーが発生したものと判断でき、所定にエラー処理がなされる。
【０１７８】
なお、上述の構成では、ＰＣＳに定義されるＰＴＳのタイミングで、字幕を表示するために用いるＰＣＳがＣＢ１１３から排出され字幕が表示されると共に、当該ＰＣＳがＣＢ１１３上から破棄されるようになっている。これによれば、ユーザオペレーションにより字幕表示ＯＦＦが指示され字幕が消去されてしまうと、次に字幕表示ＯＮを指示して字幕を再び表示させようとしても、字幕表示ＯＮの指示後の、ＰＣＳに定義されたＰＴＳに到達するまで字幕表示を行うことができないことになる。
【０１７９】
そこで、現在アクティブなＯＤＳを保持するためのバッファをＤＢ１１２とは別に設けると共に、現在アクティブなＰＣＳおよびＰＤＳを保持するためのバッファをＣＢ１１３とは別に設けることができる。字幕表示ＯＮが指示されると、これらＤＢ１１２やＣＢ１１３とは別に設けられたバッファに保持されたＯＤＳ、ＰＣＳおよびＰＤＳを用いて、字幕画像イメージおよびカラーパレットテーブルを形成し、グラフィクスプレーン１０３およびＣＬＵＴ１０４に対してそれぞれ書き込む。
【０１８０】
なお、アクティブとは、ＰＴＳにより表示が指示された状態を指し、より具体的には、あるＰＣＳにおいて、自身に定義されたＰＴＳから次の字幕表示に用いられるＰＣＳに定義されたＰＴＳまでの期間がアクティブとされる。
【０１８１】
すなわち、グラフィクスコントローラ１１４は、ＰＣＳ毎に定義されたＰＴＳのタイミングでＣＢ１１３から排出されるＰＣＳを、上述のようにしてグラフィクスプレーン１０３およびＣＬＵＴ１０４にそれぞれ供給すると共に、ＣＢ１１３とは別に設けられたバッファに対し、次のＰＣＳに定義されたＰＴＳのタイミングまで保持するようにしている。ＯＤＳについても同様に、ＤＢ１１２からＰＴＳのタイミングで排出されるＯＤＳをグラフィクスプレーン１０３に供給すると共に、ＤＢ１１２とは別に設けられたバッファに対し、次のＰＣＳに定義されたＰＴＳのタイミングまで保持する。
【０１８２】
このように構成することで、ユーザオペレーションによる字幕表示ＯＦＦの指示に応じて字幕が消去された後に、字幕表示ＯＮを指示した場合に、字幕表示ＯＮのタイミングに応じて即座に、字幕の表示を再開できるようになる。
【０１８３】
すなわち、字幕表示ＯＦＦが指示された後に字幕表示ＯＮが指示されると、ＣＢ１１３とは別に設けられたバッファからＰＣＳを読み出すと共に、ＤＢ１１２とは別に設けられたバッファからＯＤＳを読み出し、これら読み出されたＰＣＳおよびＯＤＳを用いて字幕画像イメージを形成する。形成されたこの字幕画像イメージは、グラフィクスプレーン１０３に書き込まれる。ＰＤＳについても同様に、字幕表示ＯＮの指示のタイミングでＣＢ１１３とは別に設けられたバッファからＰＤＳを読み出し、読み出されたＰＤＳを用いてカラーパレットテーブルを形成する。形成されたカラーパレットテーブルは、ＣＬＵＴ１０４に書き込まれる。
【０１８４】
図３１は、グラフィクスデコーダ１０２における、ＩＧデータに関するディスプレイセット単位での一例の処理を示すフローチャートである。この図３１に一例が示される処理は、ＰＧデータにのみ存在するＷＤＳに関する処理を除き、略図３０に示されるＰＧデータに関する処理と同等である。
【０１８５】
ステップＳ３０で、ＰＩＤフィルタ１００によりＴＳパケットからＰＩＤに基づきＩＧデータが格納されたパケットが取得され、ＴＢ１０１に溜め込まれる。次のステップＳ３１で、ＴＢ１０１に溜め込まれたＴＳパケットのペイロードからＰＩＤに基づきデータが取り出され、ＰＥＳパケットが再構築され、ＰＥＳヘッダが取り除かれてエレメンタリストリーム形式でＣＤＢ１１１に転送される。
【０１８６】
ＰＥＳパケットから取り出されたエレメンタリストリームは、ストリームグラフィックプロセッサ１１１においてセグメントに展開される（ステップＳ３２）。そして、ステップＳ３３以下の処理により、展開されたセグメントがＩＣＳ、ＰＤＳおよびＯＤＳの何れであるか、若しくは、ＥＮＤセグメントであるか否かが判別され、判別結果に応じた処理が行われる。セグメントの種類は、上述の図２４を用いて説明したように、シンタクスの先頭のブロックsegment_description()に基づき判別できる。なお、図示しないが、ＯＤＳも、同様の方法でセグメントの種類を判別可能である。
【０１８７】
ステップＳ３３で、セグメントがＩＣＳであるか否かが判別される。若し、セグメントがＩＣＳであると判別されれば、処理はステップＳ３８に移行され、図２４を用いて説明したＩＣＳのシンタクスにおけるブロックcomposition_descriptor()に基づき、このＩＣＳが含まれるディスプレイセットがエポックスタートディスプレイセットであるか否かが判断される。
【０１８８】
若し、当該ディスプレイセットがエポックスタートディスプレイセットであると判断されれば、処理はステップＳ３９に移行され、メニュー表示に関わるバッファのクリアがなされる。例えば、ＤＢ１１２およびＣＢ１１３がステップＳ３９でクリアされる。このとき、ＣＤＢ１１０を共にクリアすることも可能である。そして、次のステップＳ４０で、クリアされ空になったＣＢ１１３に、ＤＴＳのタイミングでＰＣＳが書き込まれる。ＣＢ１１３へのＰＣＳの書き込みが終了すると、処理はステップＳ３０に戻され、パケットの取得が継続される。
【０１８９】
一方、ステップＳ３８で、ＩＣＳがエポックスタートディスプレイセットではないと判断されれば、処理はステップＳ４１に移行され、ＩＣＳがＣＢ１１３にＤＴＳのタイミングで書き込まれる。このとき、ＩＣＳは、ＣＢ１１３の空き領域に所定に書き込まれる。
【０１９０】
上述のステップＳ３３で、セグメントがＩＣＳではないと判別されれば、処理はステップＳ３４に移行される。ステップＳ３４以降の処理は、上述した図３０のフローチャートにより処理と同様に、セグメントがＰＤＳであるか（ステップＳ３４）、ＯＤＳであるか（ステップＳ３５）、ＥＮＤセグメントであるか（ステップＳ３６）の判断がなされ、それぞれの判断に応じた処理がステップＳ４２、ステップＳ４３およびステップＳ３７において行われる。すなわち、セグメントがＰＤＳであれば、ＣＤ１１３に即座に書き込まれ（ステップＳ４２）、セグメントがＯＤＳであれば、ＤＴＳでデコードされＤＢ１１２に書き込まれる（ステップＳ４３）。
【０１９１】
次に、この発明の実施の一形態について説明する。上述したように、ＢＤ−ＲＯＭ規格で定義されるデコーダモデルによれば、ＰＧデータおよびＩＧデータに関し、ＣＤＢ１１０にセグメントを溜め込み、セグメントのそれぞれに定義されたＤＴＳの時刻でデコードしてＤＢ１１２またはＣＢ１１３に保持し、セグメントのそれぞれに定義されたＰＴＳの時刻で出力するように規定されている。そのため、ＢＤ−ＲＯＭ規格で定義されるデコーダモデルに基づきプレーヤを設計する際には、図３２に一例が示されるように、ＣＤＢ１１０に溜め込まれたセグメントに対応するＤＴＳおよびＰＴＳを格納するメモリ２００（以下、ＰＴＳ／ＤＴＳバッファ２００と呼ぶ）が必須であると考えられる。
【０１９２】
すなわち、このデコーダモデルに基づきプレーヤの制御を行う制御部は、ＣＤＢ１１０に溜め込まれたセグメントに対し、ＰＴＳ／ＤＴＳバッファ２００に格納されたＤＴＳに基づきデコードタイミングを指示し、デコードされＤＢ１１２またはＣＢ１１３に格納されたセグメントに対し、ＰＴＳ／ＤＴＳバッファ２００に格納されたＰＴＳに基づき出力タイミングを指示するように制御する。このＰＴＳ／ＤＴＳバッファ２００は、現時点のＢＤ−ＲＯＭ規格では定義されていない。
【０１９３】
図３３は、ＰＴＳ／ＤＴＳバッファ２００に溜め込まれる一例のデータ構成を示す。ＰＴＳ／ＤＴＳバッファ２００に対して、ＣＤＢ１１０に溜め込まれたセグメントに対応するＤＴＳおよびＰＴＳが格納されると共に、セグメントのそれぞれを識別するセグメントＩＤが格納される。ＤＴＳおよびＰＴＳは、規定に従いそれぞれ３３ビットのデータ長を有する。
【０１９４】
ＰＴＳ／ＤＴＳバッファ２００に対して、セグメント毎にさらに他のデータを格納してもよい。図３３の例では、セグメントＩＤで示されるセグメントのバージョンを示すバージョン情報と、当該セグメントのタイプを示す情報が格納される。セグメントのタイプを示す情報は、ＰＧデータの場合、当該セグメントがＰＣＳ、ＰＤＳ、ＷＤＳおよびＯＤＳの何れであるかを示し、ＩＧデータの場合、当該セグメントがＩＣＳ、ＰＤＳおよびＯＤＳの何れであるかを示す。
【０１９５】
一例として、図３３に示す項目のうちセグメントＩＤのデータ長を１６ビット、バージョン情報のデータ長を８ビット、セグメントタイプのデータ長を４ビットとするとき、１セグメント当たりのデータサイズは、９４ビットとなり、バイト単位で切り上げると１２バイトとなる。
【０１９６】
図３２に示したデコーダモデルに基づき実際にプレーヤを設計する場合、各バッファやメモリについて最低限必要な容量をそれぞれ見積もる必要がある。ＢＤ−ＲＯＭ規格に定義されているバッファであるＴＢ１０１、ＣＤＢ１１０、ＤＢ１１２およびＣＢ１１３については、同規格において既に最低容量が規定されている。したがって、ＢＤ−ＲＯＭ規格に定義されていないＰＴＳ／ＤＴＳバッファ２００について、最低容量を見積もる必要がある。
【０１９７】
既に説明したように、ＰＧデータおよびＩＧデータにおいて、セグメントのデータサイズが可変なので、ＣＤＢ１１０に対して何個のセグメントが溜め込まれるのかを見積もるのは困難である。したがって、ＣＤＢ１１０に溜め込まれたセグメントに対応するＰＴＳおよびＤＴＳの合計数すなわち合計サイズを見積もることも困難となる。
【０１９８】
例えば、ＣＤＢ１１０に対してデータサイズの大きなセグメントが溜め込まれる場合には、ＣＤＢ１１０に格納可能なセグメント数が少なくなるので、対応するＰＴＳおよびＤＴＳの合計サイズが小さなものとなる。例えば、ＰＧデータの場合には、ＯＤＳに大きな字幕画像データが格納される場合が考えられる。ＩＧデータの場合には、ページ数やコマンド数、使用されるボタン数が多い場合のＩＣＳや、ＯＤＳに大きな画像データが格納される場合が考えられる。
【０１９９】
一方、ＣＤＢ１１０に対してデータサイズの小さなセグメントが溜め込まれる場合には、ＣＤＢ１１０に格納可能なセグメント数が多くなるので、対応するＰＴＳおよびＤＴＳの合計サイズが大きくなる。一例として、ＩＧデータにおいて、アニメーション表示が設定されたボタン画像データが多数用いられている場合、ボタン画像データが格納される個々のＯＤＳのデータサイズは小さいが、ＯＤＳが多くなり、それに伴い対応するＰＴＳおよびＤＴＳの数が多くなる。
【０２００】
また、ＩＣＳやＯＤＳについては、セグメントのサイズがＰＥＳパケットの上限サイズの６４ｋＢよりも大きい場合があり、このような場合、既に説明したように、１のセグメントが複数のＰＥＳパケットに跨って格納される。この場合、１のセグメントに対して複数のＤＴＳおよびＰＴＳが存在することになり、ＣＤＢ１１０の容量に基づくＤＴＳおよびＰＴＳの合計サイズの見積もりを困難にする要因となる。
【０２０１】
そこで、この発明の実施の一形態では、プレゼンテーショングラフィクスおよびインタラクティブグラフィクスそれぞれの場合について、ＰＴＳ／ＤＴＳバッファ２００に格納可能なＰＴＳおよびＤＴＳの数に上限を定義し、この上限に基づきＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を規定することができるようにした。
【０２０２】
ＰＴＳ／ＤＴＳバッファ２００に格納されるＰＴＳおよびＤＴＳの数は、ＣＤＢ１１０に格納されるセグメントの数に対応する。したがって、ＰＴＳ／ＤＴＳバッファ２００に格納可能なＰＴＳおよびＤＴＳの数の上限は、ＣＤＢ１１０に格納可能なセグメント数の上限に基づき決めることができる。また、ＣＤＢ１１０にエレメンタリストリームの形式で溜め込まれたＰＧデータまたはＩＧデータのセグメントは、図３０または図３１を用いて説明した処理に従い、対応するＤＴＳでストリームグラフィクスプロセッサ１１１でデコードされてＤＢ１１２またはＣＢ１１３に格納され、対応するＰＴＳで出力される。そのため、ＤＢ１１２またはＣＢ１１３からセグメントが出力されるまで、当該セグメントに対応するＰＴＳを、ＰＴＳ／ＤＴＳバッファ２００で保持しておく必要がある。したがって、ＣＤＢ１１０に格納可能なセグメント数の上限は、ＤＢ１１２およびＣＢ１１３に格納可能なセグメント数に基づき決めることができる。これは、換言すれは、ＰＴＳ／ＤＴＳバッファ２００に格納可能なＰＴＳおよびＤＴＳの数の上限は、ＤＢ１１２およびＣＢ１１３に格納可能なセグメント数に基づき決めることができるということもできる。
【０２０３】
ＢＤ−ＲＯＭ規格においては、ＰＧデータおよびＩＧデータのそれぞれについて、１エポック内のセグメント数の上限が設けられる。これにより、ＰＧデータについては、１エポック内で使用可能な字幕画像データの数などが制限される。また、ＩＧデータについては、１エポック内で使用可能なページ数、コマンド数、ボタン画像データ数などに制限が設けられる。この、ＰＧデータおよびＩＧデータについて設けられる１エポック内のセグメント数の上限に基づき、ＰＧデータおよびＩＧデータそれぞれに対応するデコーダモデルにおいて、ＤＢ１１２およびＣＢ１１３が格納可能とすべきセグメント数を定めることができる。
【０２０４】
なお、ＤＢ１１２およびＣＢ１１３は、上述したように、図３０および図３１のフローチャートを用いて既に説明したように、エポックスタートディスプレイセットによりクリアされる。
【０２０５】
ＰＧデータに関する、１エポック内のセグメント数の上限は、図３４Ａに一例が示されるように、ＰＣＳが８個、ＷＤＳが１個、ＰＤＳが８個、ＯＤＳが６４個、ＥＮＤセグメントが８個となっている。これらのうち、ＥＮＤセグメントは、ＤＴＳを持たないと共に、ＤＢ１１２およびＣＢ１１３に格納されないため、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量の算出対象から除外する。また、ＰＤＳは、ＤＴＳを持たないが、ＣＢ１１３に保持される実装も許されるため、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量の算出対象とする。したがって、ＰＣＳ、ＷＤＳ、ＰＤＳおよびＯＤＳのセグメント数の上限値に基づき、ＰＧデータに対応するデコーダモデルにおけるＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を見積もることができる。
【０２０６】
一例として、上述の図３３に示される全項目をセグメント毎に保持するとした場合、（８個＋１個＋８個＋６４個）×１２バイト＝９７２バイトとなり、ＰＧデータに対応するデコーダモデルにおけるＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を、９７２バイトと見積もることができる。実際には、この最低限の容量に対してある程度余裕を持たせ、例えばＰＧデータの１エポック内のセグメント数の上限を１２８個程度として、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を１．６ｋＢ程度とすることが考えられる。
【０２０７】
ＩＧデータに関する、１エポック内のセグメント数の上限は、図３４Ｂに一例が示されるように、ＩＣＳが１個、ＰＤＳが２５６個、ＯＤＳが４０９６個、ＥＮＤセグメントが１個となっている。これらのうち、ＥＮＤセグメントは、ＤＴＳを持たないと共に、ＤＢ１１２およびＣＢ１１３に格納されないため、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量の算出対象から除外する。また、ＰＤＳは、ＤＴＳを持たないが、ＣＢ１１３に保持される実装も許されるため、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量の算出対象とする。したがって、ＩＣＳ、ＰＤＳおよびＯＤＳのセグメント数の上限値に基づき、ＩＧデータに対応するデコーダモデルにおけるＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を見積もることができる。
【０２０８】
一例として、上述の図３３に示される全項目をセグメント毎に保持するとした場合、（１個＋２５６個＋４０９６個）×１２バイト＝５２２３６バイトとなり、ＩＧデータに対応するデコーダモデルにおけるＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を、５２２３６バイトと見積もることができる。実際には、この最低限の容量に対してある程度余裕を持たせ、例えばＩＧデータの１エポック内のセグメント数の上限を５１２０個程度として、ＰＴＳ／ＤＴＳバッファ２００の最低限必要な容量を６４ｋＢ程度とすることが考えられる。
【０２０９】
なお、図３４Ａおよび図３４Ｂに示したＰＧデータおよびＩＧデータそれぞれについての、１エポック内のセグメント数の上限値は、一例であって、この例に限定されるものではない。
【０２１０】
ＰＴＳ／ＤＴＳバッファ２００は、エポック毎にクリアすることができる。例えば、図３０および図３１のフローチャートを用いて説明した、エポックスタートディスプレイセットによりＤＢ１１２およびＣＢ１１３がクリアされるタイミングで、ＰＴＳ／ＤＴＳバッファ２００をクリアすることができる。ＰＴＳ／ＤＴＳバッファ２００をエポック毎にクリアすることで、データをクリアするタイミングが固定的となり、モデルがシンプルになるメリットがある。
【０２１１】
また、これに限らず、セグメント毎にＰＴＳ／ＤＴＳバッファ２００を管理することもできる。例えば、ＰＴＳ／ＤＴＳバッファ２００に保持されているＰＴＳや、ＰＴＳとＤＴＳとの組み合わせのうち、再生時刻が当該ＰＴＳを過ぎたデータをセグメント単位で消去することが可能である。ＰＴＳによりＰＴＳ／ＤＴＳバッファ２００のクリアを行うことで、ＰＴＳ／ＤＴＳバッファ２００に対して不要なデータを保持しておく必要が無いというメリットがある。
【０２１２】
次に、上述した実施の一形態に適用可能な再生装置について説明する。図３５は、この発明の実施の一形態に適用可能な再生装置１の一例の構成を示す。再生装置１は、ストレージドライブ５０、スイッチ回路５１、ＡＶデコーダ部５２およびコントローラ部５３を有する。ストレージドライブ５０は、例えば、上述したＢＤ−ＲＯＭを装填して再生可能とされているものとする。
【０２１３】
コントローラ部５３は、例えばＣＰＵ(Central Processing Unit)と、ＣＰＵ上で動作されるプログラムが予め格納されたＲＯＭ(Read Only Memory)、ＣＰＵによりプログラムの実行時にワークメモリとして用いられるＲＡＭ(Random Access Memory)などからなり、この再生装置１の全体的な動作を制御する。
【０２１４】
また、図示は省略するが、再生装置１には、ユーザに対して所定の制御情報を提供すると共に、ユーザオペレーションに応じた制御信号を出力するようにされたユーザインターフェイスが設けられる。例えば、赤外線通信など所定の無線通信手段を介して再生装置１と遠隔的に通信を行うリモートコントロールコマンダがユーザインターフェイスとして用いられる。リモートコントロールコマンダ上には、上下左右方向をそれぞれ指示可能な十字キーといった方向キーや、数字キー、各種機能が予め割り当てられた機能キーなど、複数の入力手段が設けられる。
【０２１５】
リモートコントロールコマンダは、これらの入力手段に対してなされた操作に応じた制御信号を生成し、生成された制御信号を例えば赤外線信号に変調して送信する。再生装置１は、図示されない赤外線受信部においてこの赤外線信号を受信し、赤外線信号を電気信号に変換して復調し、元の制御信号を復元する。この制御信号がコントローラ部５３に供給される。コントローラ部５３は、この制御信号に応じて、プログラムに従い、再生装置１の動作を制御する。
【０２１６】
ユーザインターフェイスは、リモートコントロールコマンダに限らず、例えば再生装置１の操作パネルに設けられたスイッチ群により構成することができる。また、再生装置１に、ＬＡＮ(Local Area Network)などを介して通信を行う通信手段を設け、この通信手段を介して外部のコンピュータ装置などから供給された信号を、ユーザインターフェイスによる制御信号としてコントローラ部５３に供給することも可能である。
【０２１７】
また、当該再生装置１の言語設定の初期情報が、再生装置１が有する不揮発性メモリなどに記憶される。この言語設定の初期情報は、例えば再生装置１の電源投入時などにメモリから読み出され、コントローラ部５３に供給される。
【０２１８】
ストレージドライブ５０にディスクが装填されると、コントローラ部５３は、ストレージドライブ５０を介してディスク上のファイル"index.bdmv"やファイル"MovieObject.bdmv"を読み出し、読み出されたファイルの記述に基づきディレクトリ"PLAYLIST"内のプレイリストファイルを読み出す。コントローラ部５３は、プレイリストファイルに含まれるプレイアイテムが参照するクリップＡＶストリームを、ディスクからストレージドライブ５０を介して読み出す。また、コントローラ部５３は、プレイリストがサブプレイアイテムを含む場合は、サブプレイアイテムにより参照されるクリップＡＶストリームやサブタイトルデータも、ディスクからストレージドライブ５０を介して読み出す。
【０２１９】
なお、以下では、サブプレイアイテムに対応するクリップＡＶストリームを、サブクリップＡＶストリームと呼び、サブプレイアイテムに対する主たるプレイアイテムに対応するクリップＡＶストリームを、メインクリップＡＶストリームと呼ぶ。
【０２２０】
ストレージドライブ５０から出力されたデータは、図示されない復調部およびエラー訂正部により復調処理およびエラー訂正処理を所定に施され、多重化ストリームが復元される。ここでの多重化ストリームは、ＰＩＤによりデータの種類や並び順などが識別され、所定サイズに分割され時分割多重されたトランスポートストリームである。この多重化ストリームは、スイッチ回路５１に供給される。コントローラ部５３は、例えばＰＩＤに基づきスイッチ回路５１を所定に制御してデータを種類毎に分類し、メインクリップＡＶストリームのパケットをバッファ６０に供給し、サブクリップＡＶストリームのパケットをバッファ６１に供給し、サウンドデータのパケットをバッファ６２に供給し、テキストデータのパケットをバッファ６３に供給する。
【０２２１】
バッファ６０に溜め込まれたメインクリップＡＶストリームのパケットは、コントローラ部５３の制御に基づきバッファ６０からパケット毎に読み出され、ＰＩＤフィルタ６４に供給される。ＰＩＤフィルタ６４は、供給されたパケットのＰＩＤに基づき、パケットを、ビデオストリームによるパケット、プレゼンテーショングラフィクスストリーム（以下、ＰＧストリーム）によるパケット、インタラクティブグラフィクスストリーム（以下、ＩＧストリーム）によるパケットおよびオーディオストリームによるパケットに振り分ける。
【０２２２】
一方、バッファ６１に溜め込まれたサブクリップＡＶストリームのパケットは、コントローラ部５３の制御に基づきバッファ６１からパケット毎に読み出され、ＰＩＤフィルタ９０に供給される。ＰＩＤフィルタ９０は、供給されたパケットのＰＩＤに基づき、パケットを、ビデオストリームによるパケット、ＰＧストリームによるパケット、ＩＧストリームによるパケットおよびオーディオストリームによるパケットに振り分ける。
【０２２３】
ＰＩＤフィルタ６４により振り分けられたビデオストリームによるパケットと、ＰＩＤフィルタ９０により振り分けられたビデオストリームによるパケットは、それぞれＰＩＤフィルタ６５に供給され、ＰＩＤに応じて振り分けられる。すなわち、ＰＩＤフィルタ６５は、ＰＩＤフィルタ６４から供給された、メインクリップＡＶストリームによるパケットを１ｓｔビデオデコーダ６９に、ＰＩＤフィルタ９０から供給された、サブクリップＡＶストリームによるパケットを２ｎｄビデオデコーダ７２に、それぞれ供給するように、パケットを振り分ける。
【０２２４】
１ｓｔビデオデコーダ６９は、供給されたパケットのペイロードからビデオストリームを所定に取り出し、取り出されたビデオストリームのＭＰＥＧ２方式による圧縮符号を復号化する。１ｓｔビデオデコーダ６９の出力は、１ｓｔビデオプレーン生成部７０に供給され、ビデオプレーンが生成される。ビデオプレーンの生成は、例えばベースバンドのディジタルビデオデータの１フレームがフレームメモリに書き込まれることで生成される。１ｓｔビデオプレーン生成部７０で生成されたビデオプレーンは、ビデオデータ処理部７１に供給される。
【０２２５】
２ｎｄビデオデコーダ７２および２ｎｄビデオプレーン生成部７３において、上述の１ｓｔビデオデコーダ６９および１ｓｔビデオプレーン生成部７０と略同様の処理がなされ、ビデオストリームが復号化されビデオプレーンが生成される。２ｎｄビデオプレーン生成部７３で生成されたビデオプレーンは、ビデオデータ処理部７１に供給される。
【０２２６】
ビデオデータ処理部７１は、１ｓｔビデオプレーン生成部７０で生成されたビデオプレーンと、２ｎｄビデオプレーン生成部７３で生成されたビデオプレーンとを、１つのフレームに例えば所定に嵌め込んで１枚のビデオプレーンを生成することができる。１ｓｔビデオプレーン生成部７０で生成されたビデオプレーンと、２ｎｄビデオプレーン生成部７３で生成されたビデオプレーンとを、選択的に用いてビデオプレーンを生成してもよい。このビデオプレーンは、例えば上述の図９に例示した動画プレーン１０に対応する。
【０２２７】
ＰＩＤフィルタ６４により振り分けられたＰＧストリームによるパケットと、ＰＩＤフィルタ９０により振り分けられたＰＧストリームによるパケットは、それぞれスイッチ回路６６に供給されて一方が所定に選択され、プレゼンテーショングラフィクスデコーダ７４に供給される。
【０２２８】
プレゼンテーショングラフィクスデコーダ７４（図３５中ではＰＧデコーダ７４と表記）は、図３２を用いて説明したデコーダモデルにおけるグラフィクスデコーダ１０２に対応する。このとき、図３２に示されるＰＩＤフィルタ１００およびＴＢ１０１は、例えばスイッチ回路６４および図示されないバッファに対応する。これに限らず、ＰＧデコーダにＰＩＤフィルタ１００およびＴＢ１０１を含んでもよい。
【０２２９】
図３５の例では、ＰＴＳ／ＤＴＳバッファ２００は、このプレゼンテーショングラフィクスデコーダ７４に含まれる。これに限らず、ＰＴＳ／ＤＴＳバッファ２００を、コントローラ５３が有するＲＡＭ上の所定領域とすることもできる。この場合、コントローラ５３は、上述したようにして規定される、ＰＧデータについて、ＰＴＳ／ＤＴＳバッファ２００に最低限必要な容量を、ＲＡＭ上に確保する。
【０２３０】
プレゼンテーショングラフィクスデコーダ７４は、供給されたパケットのペイロードからＰＧストリームを所定に取り出してデコードして字幕を表示するグラフィクスデータを生成し、スイッチ回路７５に供給する。すなわち、プレゼンテーショングラフィクスデコーダ７４は、供給されたパケットのペイロードからデータを取り出して、ＰＩＤの情報に基づきＰＥＳパケットを再構築する。そして、再構築されたＰＥＳパケットのヘッダにＤＴＳおよび／またはＰＴＳが存在すれば、それらを取り出してＰＴＳ／ＤＴＳバッファ２００に保持すると共に、ペイロードのデータを取り出してデコードし、ＰＣＳ、ＷＤＳ、ＰＤＳおよびＯＤＳを形成する。これらＰＣＳ、ＷＤＳ、ＰＤＳおよびＯＤＳは、対応するＤＴＳに示されるタイミングでＤＢ１１２またはＣＢ１１３に格納され、対応するＰＴＳに示されるタイミングでプレゼンテーショングラフィクスデコーダ７４から出力され、スイッチ回路７５に供給される。
【０２３１】
スイッチ回路７５は、このグラフィクスデータと、後述するテキストデータによる字幕データとを所定に選択し、プレゼンテーショングラフィクスプレーン生成部７６に供給する。プレゼンテーショングラフィクスプレーン生成部７６は、供給されたデータに基づきプレゼンテーショングラフィクスプレーンを生成し、ビデオデータ処理部７１に供給する。このプレゼンテーショングラフィクスプレーンは、例えば上述の図９に例示した字幕プレーン１１に対応し、図２４および図２８で説明したグラフィクスプレーン１０３に格納される字幕画像イメージに対応する。
【０２３２】
ＰＩＤフィルタ６４により振り分けられたＩＧストリームによるパケットと、ＰＩＤフィルタ９０により振り分けられたＩＧストリームによるパケットは、それぞれスイッチ回路６７に供給されて一方が所定に選択され、インタラクティブグラフィクスデコーダ７７（図３５ではＩＧデコーダ７７と表記）に供給される。
【０２３３】
インタラクティブグラフィクスデコーダ７７は、図３２を用いて説明したデコーダモデルにおけるグラフィクスデコーダ１０２に対応する。このとき、図３２に示されるＰＩＤフィルタ１００およびＴＢ１０１は、例えばスイッチ回路６７および図示されないバッファに対応する。これに限らず、ＩＧデコーダにＰＩＤフィルタ１００およびＴＢ１０１を含んでもよい。
【０２３４】
図３５の例では、ＰＴＳ／ＤＴＳバッファ２００は、このプレゼンテーショングラフィクスデコーダ７７に含まれる。これに限らず、ＰＴＳ／ＤＴＳバッファ２００を、コントローラ５３が有するＲＡＭ上の所定領域とすることもできる。この場合、コントローラ５３は、上述したようにして規定される、ＩＧデータについて、ＰＴＳ／ＤＴＳバッファ２００に最低限必要な容量を、ＲＡＭ上に確保する。
【０２３５】
インタラクティブグラフィクスデコーダ７７は、供給されたＩＧストリームによるパケットからＩＧストリームのＩＣＳ、ＰＤＳおよびＯＤＳを所定に取り出してデコードする。例えば、インタラクティブグラフィクスデコーダ７７は、供給されたパケットのペイロードからデータを取り出して、ＰＩＤの情報に基づきＰＥＳパケットを再構築する。そして、再構築されたＰＥＳパケットのヘッダにＰＴＳおよび／またはＤＴＳが存在すれば、それらを取り出してＰＴＳ／ＤＴＳバッファ２００に保持すると共に、ペイロードのデータを取り出してデコードし、ＩＧストリームのＩＣＳ、ＰＤＳおよびＯＤＳを形成する。ＩＣＳおよびＯＤＳは、ＰＴＳ／ＤＴＳバッファ２００に保持された、対応するＤＴＳのタイミングでデコードされ、ＤＢ１１２に格納される。ＰＤＳは、即座にデコードされ、ＣＢ１１３に格納される。
【０２３６】
インタラクティブグラフィクスデコーダ７７において、ＰＴＳ／ＤＴＳバッファ２００に保持されたＰＴＳのタイミングで、対応するセグメントがＤＢ１１２またはＣＢ１１３から所定に読み出され、プリロードバッファ７８を介してインタラクティブグラフィクスプレーン生成部７９に供給される。インタラクティブグラフィクスプレーン生成部７９は、供給されたセグメントに基づき、インタラクティブグラフィクスプレーンを生成する。このインタラクティブグラフィクスプレーンは、例えば上述の図９に例示したインタラクティブグラフィクスプレーン１２に対応する。
【０２３７】
ビデオデータ処理部７１は、例えば図１１を用いて説明したグラフィクス処理部を含み、供給されたビデオプレーン（図１１における動画プレーン１０）、プレゼンテーショングラフィクスプレーン（図１１における字幕プレーン１１）およびインタラクティブグラフィクスプレーン（図１１におけるインタラクティブグラフィクスプレーン１２）を、所定に合成して１枚の画像データとし、ビデオ信号にして出力する。
【０２３８】
例えば、図１１を参照し、プレゼンテーショングラフィクスプレーン（すなわち字幕画像イメージ）に関して、パレットテーブル２２Ａ、ＲＧＢ／ＹＣｂＣｒ変換部２２Ｂおよび乗算器２３は、図３２で説明したＣＬＵＴ１０４に対応し、パレットテーブル２２ＡおよびＲＧＢ／ＹＣｂＣｒ変換部２２Ｂで色情報が付加されると共に、乗算器２３で透明属性を付加され、さらに、加算器２４および加算器２９で、ビデオプレーンおよびインタラクティブグラフィクスプレーンと合成され、１枚の画像データとされて出力される。
【０２３９】
ＰＩＤフィルタ６４により振り分けられたオーディオストリームと、ＰＩＤフィルタ９０により振り分けられたオーディオストリームは、それぞれスイッチ回路６８に供給される。スイッチ回路６８は、供給された２つのオーディオストリームのうち一方を１ｓｔオーディオデコーダ８０に、他方を２ｎｄオーディオデコーダ８１に供給するように、所定に選択する。１ｓｔオーディオデコーダ８０および２ｎｄオーディオデコーダ８１でそれぞれデコードされたオーディオストリームは、加算器８２で合成され、さらに加算器８３で、バッファ６２から読み出されたサウンドデータと合成され、出力される。
【０２４０】
バッファ６３から読み出されたテキストデータは、Ｔｅｘｔ−ＳＴコンポジション部で所定に処理され、スイッチ回路７５に供給される。
【０２４１】
上述では、再生装置１の各部がハードウェアで構成されるように説明したが、これはこの例に限られない。例えば、再生装置１をソフトウェア上の処理として実現することも可能である。この場合、再生装置１をコンピュータ装置上で動作させることができる。また、再生装置１をハードウェアおよびソフトウェアが混合された構成で実現することもできる。例えば、再生装置１における各デコーダ、特に、１ｓｔビデオデコーダ６９、２ｎｄビデオデコーダ７２など処理の負荷が他と比べて大きな部分をハードウェアで構成し、その他をソフトウェアで構成することが考えられる。この場合、ＰＴＳ／ＤＴＳバッファ２００は、コンピュータ装置のメモリ上の所定領域として構成される。
【０２４２】
また、上述では、ビデオデータ、オーディオデータ、プレゼンテーショングラフィクスストリームおよびインタラクティブグラフィクスストリームを、光ディスクなどのディスク状記録媒体から読み出す構成として説明したが、これはこの例に限定されない。例えば、これらのデータの一部または全部を再生装置が有するハードディスクドライブや半導体メモリといった、光ディスク以外の記録媒体に保持し、当該記録媒体からこれらのデータを読み出すことも考えられる。
【０２４３】
再生装置１をソフトウェアのみ、または、ハードウェアおよびソフトウェアの混合により構成し、コンピュータ装置で実行させるためのプログラムは、例えばＣＤ−ＲＯＭ(Compact Disc-Read Only Memory)やＤＶＤ−ＲＯＭ(Digital Versatile Disc Read Only Memory)といった記録媒体に記録されて提供される。この記録媒体をコンピュータ装置のドライブに装填し、記録媒体上に記録されたプログラムを所定にコンピュータ装置にインストールすることで、上述の処理をコンピュータ装置上で実行可能な状態とすることができる。プログラムをＢＤ−ＲＯＭに記録することも考えられる。なお、コンピュータ装置の構成は、極めて周知であるため、説明は省略する。
【図面の簡単な説明】
【０２４４】
【図１】ＢＤ−ＲＯＭのデータモデルを概略的に示す。
【図２】インデックステーブルを説明するための略線図である。
【図３】クリップＡＶストリーム、クリップ情報、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ図である。
【図４】複数のプレイリストから同一のクリップを参照する方法を説明するための略線図である。
【図５】サブパスについて説明するための略線図である。
【図６】記録媒体に記録されるファイルの管理構造を説明するための略線図である。
【図７】ＢＤ仮想プレーヤの動作を概略的に示す略線図である。
【図８】ＢＤ仮想プレーヤの動作を概略的に示す略線図である。
【図９】この発明の実施の形態で画像の表示系として用いられるプレーン構造の一例を示す略線図である。
【図１０】動画プレーン、字幕プレーンおよびグラフィクスプレーンの一例の解像度および表示可能色を示す略線図である。
【図１１】動画プレーン、字幕プレーンおよびグラフィクスプレーンを合成する一例の構成を示すブロック図である。
【図１２】パレットの入出力データの一例を示す略線図である。
【図１３】パレットに格納される一例のパレットテーブルを示す略線図である。
【図１４】プレゼンテーショングラフィクスストリームについて説明するための略線図である。
【図１５】ディスプレイセットの構成を概略的に示す略線図である。
【図１６】プレゼンテーショングラフィクスのディスプレイセットに関する論理的な構造を概略的に示す略線図である。
【図１７】インタラクティブグラフィクスのディスプレイセットに関する論理的な構造を概略的に示す略線図である。
【図１８】ディスプレイセットの一例の格納形式を示す略線図である。
【図１９】ＰＣＳの一例の構造を表すシンタクスを示す略線図である。
【図２０】ブロックcomposition_object()の一例の構造を表すシンタクスを示す略線図である。
【図２１】ＷＤＳの一例の構造を表すシンタクスを示す略線図である。
【図２２】ブロックwindow()の一例の構造を表すシンタクスを示す略線図である。
【図２３】メニュー画面およびボタンの構成を概略的に示す略線図である。
【図２４】ＩＣＳのヘッダ情報の一例の構造を表すシンタクスを示す略線図である。
【図２５】ブロックinteractive_composition_data_fragemnt()の一例の構造を表すシンタクスを示す略線図である。
【図２６】ブロックpage()の一例の構造を表すシンタクスを示す略線図である。
【図２７】ブロックbutton_overlap_group()の一例の構造を表すシンタクスを示す略線図である。
【図２８】ブロックbutton()の一例の構造を表すシンタクスを示す略線図である。
【図２９】現時点のＢＤ−ＲＯＭ規格に定義されるプレゼンテーショングラフィクスデータおよびインタラクティブグラフィクスデータのデコーダモデルの一例の構成を示すブロック図である。
【図３０】プレゼンテーショングラフィクスデコーダにおけるディスプレイセット単位での一例の処理を示すフローチャートである。
【図３１】インタラクティブグラフィクスデコーダにおけるディスプレイセット単位での一例の処理を示すフローチャートである。
【図３２】この発明によるプレゼンテーショングラフィクスデータおよびインタラクティブグラフィクスデータのデコーダモデルの一例の構成を示すブロック図である。
【図３３】ＰＴＳ／ＤＴＳバッファに保持されるデータの一例の構成を示す略線図である。
【図３４】プレゼンテーショングラフィクスおよびインタラクティブグラフィクスについて、１エポック内の各セグメント数の上限の例をそれぞれ示す略線図である。
【図３５】発明の実施の一形態に適用可能な再生装置の一例の構成を示すブロック図である。
【符号の説明】
【０２４５】
１  再生装置
５３  コントローラ
７４  プレゼンテーショングラフィクスデコーダ
７６  プレゼンテーショングラフィクスプレーン生成部
７７  インタラクティブグラフィクスデコーダ
７９  インタラクティブグラフィクスプレーン生成部
１００  ＰＩＤフィルタ
１０１  トランスポートバッファ
１０２  ＰＧ／ＩＧデコーダ
１１０  コーデッドデータバッファ
１１１  ストリームグラフィクスプロセッサ
１１２  デコーデッドオブジェクトバッファ
１１３  コンポジションバッファ
１１４  グラフィクスコントローラ
２００  ＰＴＳ／ＤＴＳバッファ
【図１】
0004816262.tif 000002
【図２】
0004816262.tif 000003
【図３】
0004816262.tif 000004
【図４】
0004816262.tif 000005
【図５】
0004816262.tif 000006
【図６】
0004816262.tif 000007
【図７】
0004816262.tif 000008
【図８】
0004816262.tif 000009
【図９】
0004816262.tif 000010
【図１０】
0004816262.tif 000011
【図１１】
0004816262.tif 000012
【図１２】
0004816262.tif 000013
【図１３】
0004816262.tif 000014
【図１４】
0004816262.tif 000015
【図１５】
0004816262.tif 000016
【図１６】
0004816262.tif 000017
【図１７】
0004816262.tif 000018
【図１８】
0004816262.tif 000019
【図１９】
0004816262.tif 000020
【図２０】
0004816262.tif 000021
【図２１】
0004816262.tif 000022
【図２２】
0004816262.tif 000023
【図２３】
0004816262.tif 000024
【図２４】
0004816262.tif 000025
【図２５】
0004816262.tif 000026
【図２６】
0004816262.tif 000027
【図２７】
0004816262.tif 000028
【図２８】
0004816262.tif 000029
【図２９】
0004816262.tif 000030
【図３０】
0004816262.tif 000031
【図３１】
0004816262.tif 000032
【図３２】
0004816262.tif 000033
【図３３】
0004816262.tif 000034
【図３４】
0004816262.tif 000035
【図３５】
0004816262.tif 000036