(57)【要約】  BD-ROM１００は、動画像を背景画としたメニュー表示を、再生装置に行わせるものであり、動画像を構成するAVClip、メニュー表示を介した操作待ちの制御を再生装置に行わせるBD-JObject、PlayList情報がが記録されている。このPlayList情報は、999個のPlayItem情報からなるシーケンスを有しており、このシーケンスは、各々のPlayItem情報が、1つのAVClipに対応していて、このAVClipの再生を999回、繰り返す旨を、再生装置に指示する。
2007119765.tif 000002
【特許請求の範囲】
【請求項１】
動画像を背景画としたメニュー表示を、再生装置に行わせる記録媒体であって、
動画像を構成するAVストリームと、
メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムと、
プレイリスト情報とが記録されており、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、プレイアイテムシーケンスは、各々のプレイアイテム情報が、1つのAVストリームに対応していて、当該AVストリームの再生を繰り返す旨を、再生装置に指示する
ことを特徴とする記録媒体。
【請求項２】
前記プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
前記ユーザ操作待ちの制御は、
前記再生コマンドの実行を、再生装置に反復させることでなされる
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
各々のプレイアイテム情報は接続情報を有しており、当該接続情報は、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行うべき旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項４】
前記AVストリームの先端部分の割当符号量は、同じAVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファの容量以下に定められている
ことを特徴とする請求項１記載の記録媒体。
【請求項５】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報は、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報は、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
動画像を背景画としたメニュー表示を実現する再生装置であって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御手段は、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とする再生装置。
【請求項８】
前記制御手段は、プログラムを構成するコマンドを実行するものであり、
前記再生手段は、
制御手段によるコマンドの実行結果に基づき、プレイリスト情報を介したAVストリームの再生を行うものであり、
操作待ち制御は、
プログラムに含まれる再生コマンドの実行を、制御手段が反復することでなされる
ことを特徴とする請求項７記載の再生行装置。
【請求項９】
前記再生手段は、装置内部の基準クロックに基づき、再生動作を行い、
1つのプレイアイテム情報がシームレス接続を意味する接続情報を有している場合、基準クロックにオフセットを加算することにより、１のプレイアイテム情報によるAVストリーム読み出し時と、直前のプレイアイテム情報によるAVストリーム読み出し時とで、基準クロックにて示されるカウント値を、連続させる
ことを特徴とする請求項７記載の再生装置。
【請求項１０】
前記再生手段は、デコーダと、当該デコーダにデータを供給するバッファとを有しており、
前記バッファの容量は、
前記AVストリームの先端部分と、AVストリームの終端部分とを同時に格納しうる容量である
ことを特徴とする請求項７記載の再生装置。
【請求項１１】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報がカレントのプレイアイテム情報として選択されている場合、前記再生手段は、第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報がカレントのプレイアイテムとして選択されている場合、第２のAVクリップの再生を繰り返す
ことを特徴とする請求項７記載の再生装置。
【請求項１２】
記録装置であって、
背景画となる動画像の指定を、ユーザから受け付ける受付手段と、
動画像の素材をエンコードすることで、指定された動画像に対応するAVストリームを得るエンコーダと、
複数のプレイアイテム情報からなるプレイアイテムシーケンスを有するプレイリスト情報を生成する第１生成手段と、
操作待ち制御を再生装置に行わせるプログラムを生成する第２生成手段とを備え、
前記第１生成手段は、
前記1つのAVストリームに対応するプレイアイテム情報を複数生成することで、プレイアイテムシーケンスを得る
ことを特徴とする記録装置。
【請求項１３】
プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
第２生成手段は、
前記再生コマンドの実行を反復させるコマンドを、プログラム内に記述することで、ユーザ操作待ちの制御を、再生装置に行わせる
ことを特徴とする請求項１２記載の記録装置。
【請求項１４】
各々のプレイアイテム情報は接続情報を有しており、
前記第１生成手段は、
プレイアイテムシーケンスの生成にあたって、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行わせる旨を、接続情報に示させる、ことを特徴とする請求項１２記載の記録装置。
【請求項１５】
前記エンコーダは、
AVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファ容量に基づき、入力制限直線を導き出して、かかる入力制限直線に基づき、AVストリームの先端部分に対する割当符号量を決定する
ことを特徴とする請求項１２記載の記録装置。
【請求項１６】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
前記第１生成手段は、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報が、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報が、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示すよう、プレイリスト情報を生成する
ことを特徴とする請求項１２記載の記録装置。
【請求項１７】
AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
ことを特徴とする請求項１２記載の記録装置。
【請求項１８】
再生装置に組込まれ、動画像を背景画としたメニュー表示を再生装置に行わせるシステムLSIであって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御手段は、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とするシステムLSI。
【請求項１９】
動画像を背景画としたメニュー表示を行う再生方法であって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとを有し
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御ステップは、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とする再生方法。  
【請求項２０】
動画像を背景画としたメニュー表示を、コンピュータに行わせるプログラムであって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとをコンピュータに実行させ
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御ステップは、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する制御を、コンピュータに行わせる
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、対話制御技術の技術分野に属する発明である。
【背景技術】
【０００２】
対話制御技術とは、動画像にメニューを合成させ、このメニューに対するユーザ操作に応じて再生制御を実現するという技術である。本技術は、再生すべきタイトルやチャプターの選択、クイズの設問に対する回答等、ユーザ操作に対する対話機能の実現に必須の機能であり、DVDやBD-ROM等の記録媒体やその再生装置、記録装置、システムLSIといった工業製品の開発に、具体的に応用されている。【０００３】
DVDを例に挙げれば、DVDビデオフォーマットには、その機能の一つとして、「静止画メニュー」、「動画メニュー」という機能が存在する。
静止画メニューとは、その背景に静止画が用いられるメニューである。再生装置は背景静止画を表示したまま、ハイライトや静止画で作成されたボタンを背景静止画に重畳して表示し、ユーザ操作の入力待ちを行う。【０００４】
動画メニューとは、その背景に動画が用いられるメニューである。再生装置は背景動画を再生しながら、ハイライトや静止画で作成されたボタンを背景となる動画像に重畳して、ユーザ操作の入力待ちを行う。一般的に背景動画は１分程度の短い映像で作成されており、かかる背景動画と、これに対応するプログラムとを記録媒体に記録する。このプログラムは、２つのコマンドを含む。１つ目のコマンドは、背景動画の再生を再生装置に命じる再生コマンドである。2つ目のコマンドは、ジャンプコマンドであり、1つ目のコマンドへのジャンプを、再生装置に行わせ、再生コマンドの実行を反復させる。かかるプログラムを記述することで、短い映像データを使って、ループ再生を繰り返す動画メニューの作成が可能となる。このような動画メニューを再生装置が高速に読み込むための、ディスク配置における工夫が、以下の特許文献１に、記述されている。
【特許文献１】特開平９-６３２５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述したような動画メニューでは、再生コマンドによる動画再生が終わってから、ジャンプコマンドが実行され、動画再生が再開されるまでに、動画の静止や、メニューの消去が発生する。この間、再生の動画メニューの再生途切れが発生することは避け得ない。ここで、再生途切れが発生じないような入力待ちを実現するには、１時間というような長い時間長のストリームを、動画メニューによる入力待ちのために予め記録しておくことが考えられる。このストリームの中身は、同じ映像の繰り返しであってよい。しかし映画作品の本編とは別に、動画メニューによる入力待ちのために、１時間ものストリームを記録しようというのは、記録領域の無駄であり、容認されるものではない。【０００６】
そのような記録効率の要請からすれば、１時間というような長い時間長のストリームを、動画メニューによる入力待ちのために予め記録しておくという考えは、現実味に欠けた考えであると、結論付けざるを得ない。
本発明の目的は、記録媒体の記録効率を、無駄に落とすことなく、動画メニューによる入力待ちを実現することができる、記録媒体を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を達成するため、本発明にかかる記録媒体は、動画像を背景画としたメニュー表示を、再生装置に行わせる記録媒体であって、動画像を構成するAVストリームと、メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムと、プレイリスト情報とが記録されており、   前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、プレイアイテムシーケンスは、各々のプレイアイテム情報が、1つのAVストリームに対応していて、当該AVストリームの再生を繰り返す旨を、再生装置に指示することを特徴としている。
【発明の効果】
【０００８】
本発明にかかる記録媒体は、上述したように構成されているので、1つのプレイリスト情報内に存在する複数のプレイアイテム情報により、ストリーム再生がなされている間、再生が途切れることがない。ストリームの時間長をＴとし、プレイリスト情報内のプレイアイテム情報の個数をNとしたとすれば、N×Tという期間において、動画メニューの再生途切れがないことが保証される。【０００９】
例えばプレイアイテム情報の最大数を999個として、1分間のデジタルストリームを用意すれば、たとえ、デジタルストリームの再生を命じるコマンドと、当該コマンドの実行を反復させるジャンプコマンドとの間では、動画像の静止やボタン、字幕の消去が発生するとしても、999個のプレイアイテム情報が再生されている間は、動画像の静止やボタン、字幕の消去が生じることはない。999分=１６.５時間ものの間、動画メニューの再生途切れが発生しないので、デジタルストリームの時間長が１分程度であっても、ジャンプコマンドを実行して、再生コマンドの実行を反復することによる再生の途切れは、１６.５時間のうち、１回となり、再生の途切れがない入力待ちを、長い時間継続することができる。【００１０】
また、この継続には、記録媒体の容量を多く費やすることもないので、記録媒体の容量を大きく確保したまま、途切れのない動画メニューを実現したいという、現実的な要請に応えることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの内部構成を示す図である。
【図３】Index.bdmvの内部構成を示す図である。
【図４】MovieObject.bdmvの内部構成を示す図である。
【図５】AVClipの構成を示す図である。
【図６】図５に示した各エレメンタリストリームが、AVClipにおいてどのように多重化されているかを模式的に示す図である。
【図７】PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示した図である。
【図８】AVClipを構成するSourceパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。
【図９】AVClipと、Sourceパケットと、ATSの構成とを、階層的に示す図である。
【図１０】Clip情報の内部構成を示す図である。
【図１１】映画のビデオストリームに対するEP_map設定を示す図である
【図１２】（ａ）（ｂ）PlayList情報のデータ構造と、Multi_Clip_entriesの内部構成とを示す図である。
【図１３】PlayList情報におけるPlayListMark情報の内部構成を示す図である。
【図１４】AVClipと、PlayList情報との関係を示す図である。
【図１５】STN_tableの設定例を示す図である。
【図１６】動画メニューの一般的な階層構造を示す図である。
【図１７】PlayList情報における特徴的なデータ構造を示す図である。
【図１８】図１７のPlayList情報により構成される動画メニューの階層構造を示す図である。
【図１９】（ａ）（ｂ）ATC Sequenceと、STC Sequenceとの関係を示す図である。
【図２０】（ａ）（ｂ）シームレスに接続される2つのAVClip(previousPlayItemにて参照されるAVClip#1、Current PlayItemにて参照されるAVClip#1)を示す図である。
【図２１】Clean Breakの詳細を示す図である。
【図２２】再生装置の内部構成を示す図である。
【図２３】ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の内部構成を示す図である。
【図２４】ATC Diff、STC Diffを示す図である。
【図２５】Read Bufferのバッファ状態を示す図である。
【図２６】ビデオデコーダにおけるElementary Buffer のバッファ状態を示す図である。
【図２７】Elementary Buffer における蓄積量の遷移と、Elementary Buffer におけるバッファ容量の遷移とを示す。
【図２８】入力制限直線を示す図である。
【図２９】previousPlayItemによる再生におけるt_in_endと、Current PlayItemによる再生におけるt_in_startとを同一の時間軸上で、一致させることで、観測されるバッファ遷移を示す図である。
【図３０】ビデオのバッファ遷移と、オーディオのバッファ遷移とを対応付けて示す図である。
【図３１】割当符号量変更前のバッファ遷移と、割当符号量変更後のバッファ遷移とを対比して示す図である。
【図３２】動画メニューの具体例を示す図である。
【図３３】第２実施形態に係る動画メニューの構成を示す図である。
【図３４】マルチアングル区間を構成する3つのAVClip(AVClip#1、AVClip#2、AVClip#3)を示す図である。
【図３５】マルチアングル区間を用いて動画メニューを構成するPlayList情報の構成を示す図である。
【図３６】本発明にかかる記録装置の内部構成を示す図である。
【図３７】タイトル構造作成部１０で作成されるタイトル構造情報のデータ構造の例を示している。
【図３８】メニュー画面構成時におけるGUI画面の一例を記した図である。
【図３９】図３２に示した3つのAVClipを作成するにあたってのAVClip接続情報の記述を示す図である。
【図４０】（ａ）（ｂ）IDクラスソースコードのプレイリストにアクセスするためのヘッダファイルのソースコードの例を図示したものである。
【図４１】ファイル関連付け情報を示す図である。
【図４２】図４１のファイル関連付け情報に基づく、BD-ROM上のアロケーションを示す図である。
【図４３】インターリーブ配置の一例を示す図である。
【図４４】記録装置におけるオーサリング手順を示すフローチャートである。
【図４５】シームレス動画メニューの構成を持つシナリオデータの作成の手順を記したものである。
【図４６】第５実施形態における再生装置の内部構成を示す図である。
【図４７】（ａ）（ｂ）IGストリームの構成と、機能セグメントを変換することで得られるPESパケットとを示す図である。
【図４８】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図４９】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図５０】（ａ）（ｂ）ICSとInteractive_compositionとの対応関係を示す図である。
【図５１】ICSの内部構成を示す図である。
【図５２】1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。
【図５３】Page情報(y)におけるボタン情報(i)の内部構成を示す図である。
【図５４】IGストリームが、IGデコーダ６の構成要素により、どのように処理されるかを示す図である。
【図５５】（ａ）（ｂ）2つのAVClip間で連続性をもつようなEpochを示すと共に、Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。
【図５６】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【図５７】PGストリームの具体的な構成を示す図である。
【図５８】字幕の表示位置と、Epochとの関係を示す図である。
【図５９】（ａ）（ｂ）WDS,PCSのデータ構造を示す図である。
【図６０】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図６１】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【符号の説明】
【００１２】
１  BD-ROMドライブ
２  Read Buffer
３  多重分離部
４  ビデオデコーダ
５  オーディオデコーダ
６  IGデコーダ
７  PGデコーダ
８a,b,c,d  プレーンメモリ
９a  ユーザイベント処理部
９b  データ解析実行部
１０  タイトル構造作成部
１１  BDシナリオ生成部
１６  リールセット編集部
２０  ＪＡＶＡ（登録商標）プログラミング部
３０  素材作成/インポート部
４０  ディスク作成部
５０  検証装置
【発明を実施するための最良の形態】
【００１３】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、BD-ROM１００である。BD-ROM１００は、再生装置３００、テレビ４００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。【００１４】
以降、BD-ROM１００、再生装置２００、リモコン３００について説明を行う。
BD-ROM１００は、映画作品が記録された記録媒体である。
再生装置２００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。
リモコン３００は、再生装置２００に対する操作を、ユーザから受け付ける。このBD-ROM１００により供給される映画作品の具体像は以下の通りである。このBD-ROM１００には、映画作品を構成するTitle#1、Title#2の他に、メニューを構成するメニュータイトルが記録されている。このメニュータイトルは、動画像を背景画としたメニュー表示を、再生装置２００に行わせるものであり、かかるメニューを通じて、Title#1、Title#2のどちらかの選択をユーザに行わせる。以上のように、このBD-ROM１００は、Title#1、Title#2という2つの映画作品の本編と、動画メニューとをユーザに供給するものである。以降、特に断らない限り、本出願明細書では、かかる映画作品の具体像を、説明に使用する。【００１５】
以上が、本発明にかかる記録媒体の使用形態である。
＜BD-ROMの概要＞
先ず始めに、本発明にかかる記録媒体が前提としているデータ構造について説明する。本発明にかかる記録媒体が前提にしているのは、BD-ROMの応用層規格のフォーマットである。図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、第２段目のファイルシステム層、第１段目の応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、第１段目の枠内に示すようなものになる。【００１６】
BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリと呼ばれるサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls)がある。先に述べた具体像における役割分担として、00001.mplsは、動画メニューを構成するものとする。この動画メニューは、2つのタイトル(Title#1、Title#2)の選択をユーザから受け付けるものとする。また00002.mplsは、映画作品の本編を構成するものとする。【００１７】
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts〜00003.m2ts)がある。これらのファイルのうち00001.m2tsは、動画メニュー用AVClipを構成するものとする。また00002.m2ts、00003.m2tsは、映画作品の本編を構成するものとする。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi〜00003.clpi)がある。【００１８】
BDJOディレクトリには、拡張子bdjoが付与されたファイル(00001.bdjo)が存在する。
JARディレクトリには、拡張子jarが付与されたファイル(00001.jar)がある。具体的な役割分担として、これら00001,bdjo,00001.jarは、Title#1の再生時における再生制御を担っているものとする。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
＜BD-ROMの構成その１.Index.bdmv＞
まず、Index.bdmvについて説明する。図３は、Index.bdmvの内部構成を示す図である。Index.bdmvとは、BD-ROMにおけるタイトル構成を定義する最上位層のテーブルである。図３の左側におけるIndex.bdmvは、BD-ROMディスクに格納されるFirstPlaybackについてのIndex Table Entry、TopMenuについてのIndex Table Entry、Title#1についてのIndex Table Entry、Title#2についてのIndex Table Entry,・・・・#Nを含む。このテーブルには、全てのタイトル、TopMenu、FirstPlaybackから最初に実行されるMovie ObjectもしくはBD-J Objectが指定されている。BD-ROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにIndex.bdmvを参照して、所定のMovie ObjectもしくはBD-J Objectを実行する。ここで、"FirstPlayback"とは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるBD-JObjectもしくはBD-J Objectが設定されている。また、TopMenuは、リモコンでのユーザ操作で、"MenuCall"のようなコマンドが実行されるときに、呼び出されるBD-JObjectもしくはBD-J Objectが指定されている。【００１９】
上述したようなタイトル構成は、本図の右側に示すような共通のデータ構造で定義される。本図に示すように当該共通のデータ構造は、『Title_object_type』と、『Title_mobj_id_ref』と、『Title_bdjo_file_name』とを含む。
『Title_object_type』は、"10"に設定されることで、title_idにて特定されるtitleが、BD-J Objectに関連付けられていることを示す。"01"に設定されることで、title_idにて特定されるtitleが、Movie Objectに関連付けられていることを示す。Title_object_typeによる指定、つまり、BD-J Objectに関連付けられるか否かが、このTitle_object_typeに表現される。【００２０】
『Title_mobj_id_ref』は、Titleに関連付けられたMovie Objectの識別子を示す。
『Title_bdjo_file_name』は、Titleに関連付けられたBD-J Objectファイルの名前を特定している。BD-J Objectは、ApplicationManagementTable()を有し、このApplicationManagementTable()は、実行すべきアプリケーションのapplication_idを示しているので、Index Table entry内のTitle_bdjo_file_nameによるBD-J Objectファイルのファイル名が、分岐先となるタイトルにおいて、実行すべきBD-Jアプリケーションを指示する
＜BD-ROMの構成その２.Movie Object＞
Movie Objectは、MovieObject.bdmvというファイルに格納される。図４は、MovieObject.bdmvの内部構成を示す図である。本図の左端に示すようにMovieObject.bdmvは、1つ以上のMovieObjectである『MovieObjects()』を含む。図中の図中の引き出し線vh1はMovieObjectsの内部構成をクローズアップしている。MovieObjects()は、自身のデータ長である『length』と、自身に含まれるMovieObjectの個数である『number_of_mobjs』と、number_of_mobjs個のMovieObjectである『MovieObjects』とからなる。これらnumber_of_mobjs個のMovieObjectは、識別子mobj_idをもって識別される。図中の引き出し線vh2は、識別子mobj_idにより特定される任意のMovieObject[mobj_id]()の内部構成をクローズアップしている。【００２１】
この引き出し線に示すように、MovieObjectは、ナビゲーションコマンドの個数である『number_of_navigation_command』、number_of_navigation_command個の『ナビゲーションコマンド』を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。
PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきPLを指定することができる。第２引数は、そのPLに含まれるPlayItemや、そのPLにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。【００２２】
PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。
JMPコマンド
書式：JMP 引数
JMPコマンドは、現在の動的シナリオを途中で廃棄し(discard)、引数たる分岐先動的シナリオを実行するという分岐である。JMP命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。以上がMovie Objectについての説明である。続いて、BD-Jアプリケーションの詳細について説明する。
＜BD-ROMの構成その３.BD-Jアプリケーション＞
00001.jarは、BD-Jアプリケーションを格納している。BD-Jアプリケーションとは、Ｊａｖａ（登録商標）2Micro_Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsとをフル実装したプラットフォーム部にて動作するＪａｖａ（登録商標）アプリケーションである。【００２３】
このBD-Jアプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destoryed”といった4つの状態をもつ。
上述したＪａｖａ（登録商標）プラットフォーム部は、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードＪａｖａ（登録商標）ライブラリを含む。このため、Ｊａｖａ（登録商標）アプリケーションは、GEM1.0.2にて規定されたHAViフレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含むGUIフレームワークを実現することができる。【００２４】
これにより、Ｊａｖａ（登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
こうしたBD-Jアプリケーションを構成する一連のファイルは、http：//Ｊａｖａ（登録商標）.sun.com/j2se/1.4.2/docs/guide/jar/jar.htmlに記載された仕様に準じた、Ｊａｖａ（登録商標）アーカイブファイルに変換される。Ｊａｖａ（登録商標）アーカイブファイルは、ZIPファイルの形式を、Ｊａｖａ（登録商標）に特化したものであり、市販されているZIP展開ソフトウェアにより中身を確認することができる。【００２５】
以上がBD-Jアプリケーションについての説明である。続いて、BD-JObjectの詳細について説明する。
＜BD-ROMの構成その４.BD-JObject＞
00001.bdjoは、BD-JObjectを格納している。BD-JObjectは、アプリケーション管理テーブル(ApplicationManagementTable())を含み、BD-ROM再生時において、タイトル切り替えに伴うアプリケーションシグナリングをプラットフォーム部に実行させるデータのことである。より具体的にいうと、ApplicationManagementTable()は、実行すべきBD-Jアプリケーションを示すapplication_idと、BD-Jアプリケーションを起動する際の制御を示すapplication_contorol_codeを含む。application_contorol_codeは、タイトル選択後におけるアプリケーションの最初の実行状態を規定しており、またapplication_contorol_codeは、BD-Jアプリケーションを仮想マシンにロードして自動開始するか(AUTOSTART)、BD-Jアプリケーションを仮想マシンにロードするが自動開始はしないか(PRESENT)を規定することができる。【００２６】
＜BD-ROMの構成その５.AVClip＞
拡張子.m2tsが付与されたファイル(00001.m2ts)は、AVClipを格納している。AVClipはMPEG2-Transport Stream形式のデジタルストリームである。
図５は、AVClipの構成を示す図である。本図に示すように、AVClipには、0x1011のPIDをもつビデオストリーム、0x1100から0x111FまでのPIDをもつオーディオストリーム、0x1200から0x121FまでのPIDをもつ32本のPresentation Graphics(PG)ストリーム、0x1400から0x141FまでのPIDをもつ32本のIterractive Graphics(IG)ストリームが多重化されている。【００２７】
図６は、図５に示した各エレメンタリストリームが、AVClipにおいてどのように多重化されているかを模式的に示す図である。AVClipは、デジタル化された映像、デジタル化された音声を(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(Presentatiion Graphics(PG)ストリーム)及び対話系のIGストリーム(Interactive Graphics(IG)ストリーム)を(下１段目、下２段目)、TSパケットに変換して(下３段目)、これらを多重化することで構成される。【００２８】
ここで、ビデオストリームは、本図の第１段目に示すように複数のピクチャから構成されるが、これらピクチャと、Access Unitとの関係は、１Access Unit ＝ １ピクチャである。オーディオストリームも、複数のオーディオフレームから構成されるが、これらオーディオフレームと、Access Unitとの関係も、本図の第１段目に示すように１オーディオフレーム ＝ １Access Unitである。またBD-ROMでは、１PESパケット ＝ １フレームに制限されている。つまり、動画がフレーム構造であれば、１PESパケット ＝ １ピクチャであり、フィールド構造である場合、１PESパケット＝２ピクチャとなる。これらのことから、本図の第２段目に示すPESパケットは、第１段目におけるピクチャやオーディオフレームを、１対１の比率で格納している。【００２９】
以上のAVClipは、1つ以上の“STC Sequence”から構成される。“STC Sequence”とは、デコード時刻、表示時刻を表すMPEG2-TSの時間軸であり、AVストリームのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR(Program Clock Reference)を運ぶPCRパケットの不連続情報(discontinuity_indicator)がONである点である。【００３０】
図７は、PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目は、ビデオストリームを示し、第3段目はオーディオストリームを示す。第2段目は、PESパケット列を示す。本図の矢印yy1,yy2,yy3,yy4に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIDR、Bピクチャ、Pピクチャは、複数に分割され、個々の分割部分が、PESパケットのペイロード(図中のV#1,V#2,V#3,V#4)に格納されることがわかる。またオーディオストリームを構成するAudio Presentation Unitであるオーディオフレームは、矢印aa1,aa2に示すように、個々のPESパケットのペイロード(図中のA#1,A#2)に格納されていることがわかる。【００３１】
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図８は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS_extra_header(図中のハッチング部)が付されて、192バイト長のSourceパケットになる。このTS_extra_headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival_Time_Stampを含む。【００３２】
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC_Seuqence”を構成する。“ATC_Seuqence”とは、AVClipに記されているATSの時間軸を構成するSourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(no arrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケット列を“ATC_Seuqence”という。ATSは以下のようにTSパケットの先頭につけられ、デコーダへの転送時刻を示す。【００３３】
かかるATC_SeuqenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第３段目はAVClipを示し、第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳextent以上のデータ長を有する
ファイルエクステントを構成するSourceパケットは、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のSourceパケットを“Aligned Unit”といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。【００３４】
図９は、AVClipと、Sourceパケットと、ATSの構成とを、階層的に示す図である。第１段目は、AVClipを示し、第２段目は、AVClipを構成するSourceパケット列を示す。第３段目は、SourceパケットにおけるATSの構成を示す。この第３段目に示すように、ATSは、2ビットの予約領域が先頭にあり、その後に、30ビットのATS(Arrival Time Stamp)が続く形になっている。
＜BD-ROMの構成その６.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図１０は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、
i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』からなる。【００３５】
ClipInfoには、このClip情報が参照するAVClipのアプリケーションタイプ（application_type）がある。かかるClipInfoを参照することで、アプリケーションタイプによってAVClipかSubClipかや、動画を含んでいるのか静止画(スライドショー)を含んでいるのかなどが識別できる。
Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、Sequence Infoは設けられている。【００３６】
Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。Program Sequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSD画像からHD画像に変化している点等をいう。【００３７】
続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP_map_for_one_stream_PID(EP_map_for_one_stream_PID[0]〜EP_map_for_one_stream_PID[Ne-1])からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、1つのエレメンタリストリーム上において、Access Unitが存在するエントリー位置のパケット番号(SPN_EP_start)を、エントリー時刻(PTS_EP_start)と対応づけて示す情報である。図中の引き出し線cu3は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。【００３８】
これによると、EP_map_for_one_stream_PIDは、Nc個のEP_High(EP_High(0)〜EP_High(Nc-1))と、Nf個のEP_Low(EP_Low(0)〜EP_Low(Nf-1))とからなることがわかる。ここでEP_Highは、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。【００３９】
図中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN_EP_High[i]』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。【００４０】
図中の引き出し線cu5は、EP_Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point(EP_Low_id)』と、対応するAccess Unitのサイズを示す『I_end_position_offset(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS_EP_Low(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN_EP_Low(EP_Low_id)』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。【００４１】
以下、具体例を通じて、EP_mapについて説明する。図１１は、映画のビデオストリームに対するEP_map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP_mapの設定を示す。【００４２】
第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t1〜t7をエントリー時刻(PTS_EP_start)として示し、これに対応づけてエントリー位置(SPN_EP_start)を示すよう、設定される。  【００４３】
＜BD-ROMの構成その７.PlayList情報＞
拡張子“mpls”が付与されたファイル(00002.mpls)について説明する。本ファイルは、MainPath、Subpathと呼ばれる2種類の再生経路を束ねたものをPlaylist(PL)として定義する情報である。図１２（ａ）は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())と、Subpathを定義するSubpath情報(Subpath())とを含む。【００４４】
＜PlayList情報の詳細その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、ビデオストリームやオーディオストリームに対して定義される再生経路である。MainPathは、矢印mp1で示すように複数のPlayItem情報#1・・・・#mから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。【００４５】
この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name[0]』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection_condition』と、このPlayItemが対象としているSTC Sequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still_mode』と、PlayItemがマルチアングルを構成する場合、かかるマルチアングルを構成する複数のAVClipを示す『Multi_Clip_entries』と、『STN_table』とから構成される。【００４６】
図１２（ｂ）は、Multi_Clip_entriesの内部構成を示す図である。本図に示すように、Multi_Clip_entriesは、マルチアングル区間におけるアングル総数を示す『number_of_angles』、アングル映像において、異なる音声を再生させるかどうかを示す『is_different_audio』を有しており、『Clip_Information_file_name[1]』、『ref_to_STC_id[1]』〜『Clip_Information_file_name[N]』、『ref_to_STC_id[N]』を含む。【００４７】
これらMulti_Clip_entriesにおける『Clip_codec_identifier』、『Clip_Information_file_name』、『ref_to_STC_id[0]』のそれぞれは、マルチアングル区間において、個々のアングル映像を構成するAVClipに対応している。
＜PlayList情報の詳細その２.PlayListMark情報＞
以降、PlayListMark情報について説明をはじめる。【００４８】
図１３は、PlayList情報におけるPlayListMark情報の内部構成を示す図である。本図の図中の引き出し線pm0に示すように、PlayListMark情報は、複数のPLMark情報(#1〜#n)からなる。PLmark情報(PLmark())は、PL時間軸のうち、任意の位置を、チャプター点として指定する情報である。引き出し線pm1に示すようにPLmark情報は、チャプター指定の対象たるPlayItemを示す『ref_to_PlayItem_Id』と、そのPlayItemにおける、チャプター位置を時間表記により示す『mark_time_stamp』とを含む。【００４９】
図１４は、AVClipと、PlayList情報との関係を示す図である。第2段目から第5段目は、図１０の第１段目から第４段目までと同一であり、EP_mapにて参照されているビデオストリームを示す。
本図におけるPlayList情報は、PlayItem情報#1,#2という2つのPlayItem情報を含んでおり、これらPlayItem情報#1,#2のIn_time,Out_timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。【００５０】
本図の第1段目は、PLMark情報と、PlayList時間軸とを示す。この第1段目には、2つのPLMark情報#1〜#2が存在する。矢印kt1,2は、PLMark情報のref_to_PlayItem_Idによる指定を示す。この矢印からもわかるようにPLMark情報のref_to_PlayItem_Idは、参照するPlayItemを指定していることがわかる。また、Mark_time_Stampは、当該PlayItem時間軸のうち、Chapter#1,#2になるべき時点を示す。このように、PLMark情報は、PlayItem時間軸上に、チャプター点を定義することができる。
＜PlayList情報の詳細その３.STN_table＞
以降、STN_tableについて説明する。STN(STream Number)_tableは、Clip情報で参照されるAVClipに多重化されている各エレメンタリストリームの再生が、PlayItem情報において、有効であるか無効であるかを表す。【００５１】
図１５は、STN_tableの設定例を示す図である。左側は、PlayItem情報を示し、真ん中は、AVClipに含まれるエレメンタリストリームの種別を示す。右側は、STN_tableにおける具体的な設定を示す。
本図の表記によると、真ん中のAVClipには、1本のビデオストリームと、3本のオーディオストリーム1,2,3と、4本のPGストリーム1,2,3,4と、3本のIGストリーム1,2,3とが含まれていることがわかる。【００５２】
右側のSTN_tableの具体的な設定によると、ビデオ、オーディオ1,2、プレゼンテーショングラフィックス1,2、インタラクティブグラフィックス1が有効になっていることがわかる。したがって、このPlayItem情報では、STN_tableにおいて有効と設定されているエレメンタリストリームが再生可能であり、その他のエレメンタリストリームは再生が禁止される。またSTN_tableには、各エレメンタリストリームの属性情報も同時に記録されている。ここで属性情報とは、各エレメンタリストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。【００５３】
以上がBD-ROMのデータ構造についての説明である。本発明にかかる記録媒体は、かかるデータ構造を前提にして、動画メニューを構成する。図１６は、動画メニュー用AVClipの一般的な階層構造を示す図である。本図における第１段目は、Index.bdmvを示し、第２段目はMovie Objectを示している。第１段目に描かれたIndex.bdmvは、各タイトルに対応するインデックスを有する。これらのうち、Index.bdmvのTopMenuにはMovieObject#1が設定されており、TopMenuがコールされると、第２段目において、MovieObject#1に設定されているコマンドが順に実行される。MovieObject#1の1番目のコマンドには”PlayPL  PlayList#1”が設定されている。PlayPLコマンドは、引数となるプレイリストを先頭から再生するコマンドである。”PlayPL  PlayList#1”のコマンドが実行されると、再生装置はPlayList情報#1の先頭PlayItem情報である、PlayItem情報#1を解析し、そのPlayItem情報#内のClip_Information_file_nameにて指定されるAVClipの再生を開始する。【００５４】
AVClipは背景動画の映像とともに、ユーザがメニュー操作を行うためのIGストリームが多重化されている。AVClipの長さは、コンテンツに依存するが、あまり長い映像を使うとディスクの容量を逼迫してしまうので、1分程度の短い映像を使うことが一般的である。AVClipの再生が完了すると、次のコマンドに遷移する。図１６の場合、2番目のコマンドには“Jump MovieObject#1”が設定されている。本ジャンプコマンドは、PlayList情報#1の再生後、MovieObject#1にジャンプして、再びPlayPLコマンドの呼び出しを行わせるものである。【００５５】
PlayItem情報#1のIn_Timeは、動画メニュー用AVClipの先頭に存在するピクチャデータのPresentation TiMe(PTM)を示すよう設定されており、Out_Timeは、動画メニュー用AVClipの終端に存在するピクチャデータのPresentation TiMe(PTM)を示すよう設定されている。かかるPlayPLコマンドと、Jumpコマンドとがコマンドプロセッサにて実行されることで、プレイリストの再生が何度も実行されることになる。【００５６】
しかし、このようなデータ構成の場合、PlayList情報#1の再生が終了し、再度PlayList情報#1が再生する間に、AV再生画面の静止と、ボタンの消去が生じる。
具体的にいうと、PlayPLコマンドで指定されたPlayList情報に基づくAVClipの再生が終了すると、PlayPLコマンドを実行して、再度PlayList情報をロードしなおそうとする。この際、テレビにおけるAV再生画面は、PlayItem情報にて参照されている最後のピクチャを表示したままになるので、AV再生画面の静止が発生する。【００５７】
また、PlayList情報の再ロードの際、再生装置は、PlayList情報が配置されたメモリ領域や、デコーダにおけるバッファメモリをフラッシュを行う。このフラッシュにおいて、IGストリームで構成されたメニューを構成するボタンや、PGストリームで構成された字幕が一旦、画面から削除されので、AV再生画面からボタンや字幕が消えてしまう。本実施形態が提案しているのは、このようなAV再生画面の静止やボタン、字幕の消去といった課題を解決することである。【００５８】
図１７は、BD-ROM１００の特徴的なデータ構造を示す図である。左側は、PlayList情報のデータ構造を示し、右側は、PlayItem情報の具体的な設定を示す。左側によると、PlayList情報は、１〜999個のPlayItem情報を含む。PlayItem情報の識別番号は、３桁の数値なので、この３桁の数値で表現可能な最大数のPlayItem情報が、PlayList情報内に存在している。一方、右側における具体的な記述によると、999個の各PlayItem情報の記述は、共通のものになっていることがわかる。つまりClip_Information_file_nameは、動画メニュー用AVClipであるAVClip#1のClip情報を示し、In_Timeが動画メニュー用AVClipの開始PTM(Presentation TiMe)を示し、Out_Timeが動画メニュー用AVClipの終了PTMを示し、connection_condition情報は、CC=5(シームレス接続)を示していることがわかる。かかるPlayList情報のデータ構造を、図１６と同じ表記で示したのが、図１８である。【００５９】
BD-ROM規格において、PlayItem情報の個数が999個以下に制限されているのは、識別番号に割り当てられている桁数に制限があることと、PlayList情報をオンメモリで使用したいとの要望による。つまり、PlayList情報は、AVClipの再生に先立ち、メモリに読み込まれ、PlayList情報に基づくAVClipの再生は、PlayList情報が、メモリに搭載されている状態でなされる。このように、オンメモリで利用されることが前提なので、PlayItem情報の個数をむやみに増やすことは許されず、BD-ROMの応用層規格では、999個以下と定められている。【００６０】
図１８は、第１実施形態における動画メニューの階層構造を示す。図１６との違いは、第２段目におけるPlayList情報#1の構成である。図１６のPlayList情報#1が一つのPlayItem情報から構成されているのに対し、図１８のPlayList情報#1は、999個のPlayItem情報を含み、それら999個のPlayItemのIn_Time、Out_Timeは、同じAVClipの先端部分、終端部分を指定している。そして、999個のPlayItemのうち、先頭にあたるPlayItem情報#1以外は、connection_condition＝5に設定されている。これにより各PlayItem情報間はシームレス接続であることを再生装置に通知することが出来る。【００６１】
また複数のPlayItem情報が参照している共通のメニュー用AVClipにおいて、メニュー用AVClipの終端のエクステントからメニュー用AVClipの先頭が含まれるエクステントまで距離は、最大ジャンプサイズSjump_maxを越えないように設定され、かつ、メニュー用AVClipの終端のエクステントは、そのジャンプ距離をジャンプする時間から算出される最小エクステントサイズ以上のサイズに設定されている。【００６２】
更に複数のPlayItem情報が参照している共通のメニュー用AVClipは、メニュー用AVClipの終端までデコードした後、デコードバッファをクリアせず、引き続きメニュー用AVClipの先頭から再生を行っても、デコードモデルが破綻しないようにデータが作成されている。AVClipの先端部分には、特定の初期状態を想定した符号割り当てがなされている。この特定の初期状態とは、直前のPlayItemでAVClipを再生するにあたって、当該AVClipのバッファ読み込みが完了した時点におけるバッファの状態をいう。【００６３】
先端部分に対する符号量割当て割り当てをこのように設定することによって、メニュー用AVClipは、繰り返しメニュー用AVClipを再生しても、シームレスに再生することができる。
以上説明したデータ構造にすることによって、図１７のPlayList情報#1を再生すると、PlayItem情報#1からPlayItem情報#999まで、同じAVClipの再生を繰り返し、シームレスに再生することになる。例えば、PlayItem情報の数を規格最大数である、999個に設定することによって、短いAVClipを使いながらPlayList情報#1は擬似的に永久にループする。これによって、1つのAVClipの再生のたびに静止が発生したり、メニューを構成するボタンや字幕が消えたりすることを回避できる。例えばPlayItem情報の数を999個として、1分間のAVClipを用意すれば、999分=16.5時間の再生が可能となり、一般的にメニュー操作に必要と想定される時間よりも大幅に長い時間、映像の静止が発生したりメニューを構成するボタンや字幕が消えたりせずに、シームレスにAVClipを再生することが可能となる。つまりJumpコマンドを実行して、PlayPLコマンドを反復することによる再生の途切れは、999回に１回となる。【００６４】
こうすることで、たとえPlayPLコマンドとJumpコマンドとの間では、AV画面の静止やボタン、字幕の消去が発生するとしても、999個のPlayItemが再生されている間は、これらが生じることはない、仮にAVClipの時間長が１分近くの短いものであっても、999分=16.5時間ものの間は、再生の途切れが発生しないので、AVClipの時間長が短いものであっても、再生の途切れがないメニュー操作待ちを実現することができる。【００６５】
以降、PlayList情報内の個々のPlayItem情報の接続は、どのように実現されるかについて説明する。
図１９（ａ）は、ATC Sequenceと、STC Sequenceとの関係を示す図である。本図に示すように、BD-ROMにおけるAV Clipに包含されるATC Sequenceの数は、1つに固定されている。一方、この1つのATC_Sequenceに対して、複数のSTC_Sequenceを包含させることは可能である。【００６６】
図１９（ｂ）は、縦軸にSTC_SequenceにおけるSTCの値をプロットし、横軸に、ATC_SequenceにおけるATCの値をプロットしたグラフである。ATC値と、STC値とは、単調増加の関係にあり、ATC値が増えればSTC値も増える。但し、STC Sequenceの切り替わる時点においては、STCの不連続点が生じていることがわかる。
PlayList情報に含まれる複数のPlayItem情報のうち、任意の一個を“Current PlayItem”と呼び、このCurrent PlayItemの直前に位置するPlayItem情報を“previous PlayItem”という。【００６７】
図２０（ａ）は、シームレスに接続される2つのAVClip(previous PlayItemにて参照されるAVClip#1、Current PlayItemにて参照されるAVClip#1)を示す図である。
図２０（ｂ）は、previous PlayItemにて参照されるAVClip#1におけるVideo Presentation Unit、及び、Audio Presentation Unitと、Current PlayItemにて参照されるAVClip#1におけるVideo Presentation Unit、及び、Audio Presentation Unitとの関係を示す図である。第１段目は、previous PlayItemにて参照されるAVClip#1を構成するVideo Presentation Unit(ビデオフレーム)と、Current PlayItemにて参照されるAVClip#1を構成するVideo Presentation Unit(ビデオフレーム)とを示す。【００６８】
第２段目は、previous PlayItemにて参照されるAVClip#1を構成するAudio Presentation Unit(オーディオフレーム)を示す。第３段目は、Current PlayItemにて参照されるAVClip#1を構成するAudio Presentation Unit(オーディオフレーム)を示す。ここで、previous PlayItemにて参照されるAVClip#1のうち、最後のVideo Presentation Unitの再生時刻を200000とし、Current PlayItemにて参照されるAVClip#1のうち、最初の再生時刻を500000とする。このように、previous PlayItemにて参照されるAVClip#1の最後のVideo Presentation Unitの再生時刻と、Current PlayItemにて参照されるAVClip#1の最初の再生時刻とが不連続であっても、シームレス再生は可能になる。
これら2つのAVClip間は、Clean Breakの条件を満たす必要がある。具体的には以下の制約が課される。【００６９】
(1) シームレス境界では、AudioフレームをOverlapさせる
(2) Clip#1のAudioの終端フレームと、ビデオの終了時刻とがOverlapしている。
(3) Clip#2のAudioの先頭フレームと、ビデオの開始時刻とがOverlapしている。
previous PlayItemにて、再生装置に送り込まれるトランスポートストリームパケット列を“TS1”といい、Current PlayItemにて、再生装置に送り込まれるトランスポートストリームパケット列を“TS2”という。Clean Breakは、previousPlayItemにてデコーダに送り込まれるTS1と、Current PlayItemにてデコーダに送り込まれるTS2とが、図２１のような関係を満たしていることをいう。図２１は、Clean Breakの詳細を示す図である。【００７０】
第1段目は、TS1、TS2における複数のVideo Presentation Unitを示し、第2段目は、TS1におけるAudio Presentation Unit、TS2におけるAudio Presentation Unitを示す。第3段目は、AVClipにおけるSTCの値を示す。第4段目は、AVClipにおけSourceパケット列を示す。
本図において、ハッチングが付されているのは、TS1側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットであり、ハッチングが付されていないのは、TS2側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットである。【００７１】
本図においてClean Breakとは、Video Presentation Unit境界を一致させるものの(第2段目)、AVClipのATCにおいてギャップがあり(第4段目)、AVClipのAudio Presentation Unitでオーバラップが存在する(第2段目)状態をいう。
上述したVideo Presentation Unitの境界とは、TS1側から見れば、第1段目における最後のVideo Presentation Unitの終了点PTS11End+Tppにあたり、TS2側から見れば、第1段目におけるVideo Presentation Unitの開始点PTS22Startにあたる。【００７２】
TS1のうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5a、TS2のうち、時点T4に一致するAudio Presentation Unitの開始点をT3aとした場合、AVClipにおけるオーバラップは、Audio Presentation UnitはT3aからT5aにまでとなる。
この図から、CC＝5を実現するには、Video Presentation Unit、Audio Presentation Unit、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。【００７３】
(1)TS1におけるオーディオストリームの最後のAudio Presentation Unitは、previous PlayItemにて指定されるTS1における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。
(2)TS2におけるオーディオストリームの、最初のAudio Presentation Unitは、カレントPlayItemにて指定されるTS2の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。【００７４】
(3)接続点のAudio Presentation Unit列において、ギャップが存在しない。これは接続点において、Audio Presentation Unit列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、2つのオーディオフレーム再生期間より短い大きさでなければならない。
(4)TS2の最初のパケットは、PAT(Program Allocation Table)を含み、1つ以上のPMT(Program Map Table)がその直後に後続しなければならない。PMTがTSパケットのペイロードより大きければ、PMTは、2パケット以上になることもある。PMTを格納したTSパケットには、PCRやSITが存在しなければならない。以上で、本発明にかかる記録媒体の実施形態についての説明を終える。【００７５】
続いて、本発明にかかる再生装置について説明する。
図２２は、一般的な再生装置２００の構成を示している。再生装置２００は、BD-ROMドライブ１、Read Buffer２、多重分離部３、デコーダ４,５,６,７、プレーンメモリ８a,b,c、ユーザイベント処理部９a、データ解析実行部９bから構成されている。
BD-ROMドライブ１は、データ解析実行部９bからの命令を元に、BD-ROMディスクからデータを読み出し、Read Buffer２にデータを蓄える。BD-ROMディスクから読み出すデータは、AVClipだけでなく、index.bdmv、MovieObject.bdmv, PlayList情報等も含まれる。【００７６】
Read Buffer２は、BD-ROMドライブ１を使って読み込んだSourceパケット列を一時的に格納するメモリ等で構成されたバッファである。
多重分離部３は、Read Buffer２に読み出されたSourceパケットに対して多重分離処理を行う。
デコーダ４,５,６,７は、AVClipのデコードを行い、ディスプレイ等の画面に表示を行う。【００７７】
プレーンメモリ８a,b,cは、ビデオデコーダ４、IGデコーダ６、PGデコーダ７のデコード結果である１画面分の画素データを保持する。
加算部８dは、プレーンメモリ８a,b,cに格納された、一画面分の画素データを合成した上で出力する。かかる出力によって、動画像に、メニューが重畳された合成映像を得ることができる。【００７８】
ユーザイベント処理部９aは、リモコンを通じたユーザ操作に応答して、データ解析実行部９bに処理の実行を依頼する。たとえば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようデータ解析実行部９bに依頼する。
データ解析実行部９bは、BD-ROMに記録されたMovie ObjectやBD-Jアプリケーションに基づき、操作待ち制御を実行する。データ解析実行部９bは、Movie Objectを構成するナビゲーションコマンドを実行するコマンドプロセッサ、BD-Jアプリケーションを実行するＪａｖａ（登録商標）プラットフォーム、再生制御エンジンとを含む。再生制御エンジンは、コマンドプロセッサによるPlayPLコマンドの実行結果やプラットフォーム部によるAPIコールに基づき、PlayList情報を介したAVClipの再生を行う。操作待ち制御は、Movie Objectに含まれるPlayPLコマンドの実行を、コマンドプロセッサが反復して実行し、個々のPlayItem情報に対応するAVClipの読み出しと、ビデオデコーダ４〜PGデコーダ７への、AVClipの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する。上述したようなナビゲーションコマンドやBD-Jアプリケーションの実行は、ユーザイベント処理部９aが受け付けたリモコン操作に基づく。かかる実行により、AVClipの再生やIGストリームのボタンの表示切替等の制御がなされる。ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の制御も行い、たとえばシームレスに再生するAVClip#1とAVClip#2がある場合は、AVClip#1の再生終了時にデコーダのリセット要求を行わずに、AVClip#2を続けてデコーダへ転送する。【００７９】
図２３は、ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の内部構成を示す図である。
＜多重分離部３＞
本図において、多重分離部３は、Source Depacketizer３a、PID Filter３b、ATCカウンタ３c,d、加算部３e、加算部３f、ATC_diff計算部３g、STC_diff計算部３ｈから構成される。【００８０】
ソースデパケッタイザ(Source  De-packetizer)３aは、TS1,TS2を構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、各TSパケットのATSに応じてデコーダへの入力時刻を調整する。具体的には、ATC Counter３cが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS_Recording_Rateで、そのTSパケットだけをPID Filter３bに転送する。【００８１】
PID Filter３bは、ソースデパケッタイザ２bから出力されたSourceパケットのうち、PlayItem情報におけるSTN_tableに記載されたPID参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ５、Interactive Graphicsデコーダ６、Presentation Graphicsデコーダ７に出力する。各デコーダは、PID Filter３bを経由したエレメンタリストリームを受け取って、TS1,TS2のPCRに従いデコードから再生の処理を行う。このようにPID Filter３bを通過して各デコーダに入力されるエレメンタリストリームは、TS1,TS2のPCRに従って、デコード及び再生に供されることになる。【００８２】
ATC Counter３cは、TS1,TS2を構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ３aにATCを出力してゆく。
STC Counter３dは、TS1,TS2のPCRによってリセットされ、STCを出力する。
加算部３eは、ATC Counter３cにより生成されたATC(ATC値1)に、所定のオフセットを加算した上で、PIDフィルタ３aに出力する。【００８３】
加算部３fは、PIDフィルタ３ｄにより生成されたSTC(STC値2)に、所定のオフセットを加算した上で、デマルチプレクサ３bに出力する。
ATC_diff計算部３gは、ATC Sequenceが切り替わった場合、ATC_diffを算出して、加算部３eに出力する。加算部３eが、ATC Counter３cにて生成されているATC値(ATC1)に、当該ATC_diffを加算することで、新しいATC SequenceのATC値(ATC2)が得られる。【００８４】
STC_diff計算部３ｈは、STC Sequenceが切り替わった場合、STC_diffを算出して、加算部３fに出力する。加算部３fが、それまでのSTC SequenceにおけるSTC値(STC1)に、STC_diffを加算するよう、加算部３fを制御することで、新しいSTC SequenceのSTC値(STC2)が得られる。
図２４は、ATC Diff、STC Diffを示す図である。第１段目は、TS1の時間軸を示し、第３段目は、TS2の時間軸を示す。TS1には、図２１に記述した、STC11end、PTS11endが存在する。一方TS2には、STC21end、PTS21startが存在する。第２段目の矢印は、TS1からTS2への写像を模式的に表したものである。つまり第２段目の左側の矢印を追うと、TS2上のSTC21endは、TS1上のSTC11endをTS2上に写像した写像点であることがわかる。一方、右側の矢印を追うと、TS2上のPTS21startは、TS1上のPTS11endからＴpp隔てた時点(PTS11end＋Ｔpp)を、TS2上に写像した写像点であることがわかる。このＴppは、一ビデオフレームの間隔を示す。【００８５】
第４段目は、ATC Diff、STC Diffを算出するための計算式を示す。
STC Diffは、以下の数式に基づき算出される。
STCDiff = PTS11end + Tpp + PTS22start
∴ STC2 = STC1 - STCDiff 
ATCDiffは、以下の数式に基づき算出される。  【００８６】
ATCDiff ＝ STC22start - (STC11end - STC_diff - 188/ts_recording_rate(TS1) )
＝ STC22start - (STC21end - 188/ts_recording_rate(TS1) )
＝ 188/ts_recording_rate(TS1) + STC22start - STC21end 
シームレス接続されるTS1/TS2については、このように計算されたATCDiffを、再生装置内のATCに加算することによってATCを補正した時間軸でバッファモデルを破綻させないようにしている。【００８７】
ATC_diff計算部３g、STC_diff計算部３ｈは1つのPlayItem情報がシームレス接続を意味する、CC=5のConnectioin_condition情報を有している場合、ATCにATC_diffを加算し、STCにSTC_diffを加算する。これにより、１のPlayItem情報によるAVClip読み出し時と、直前のPlayItem情報によるAVClip読み出し時とで、ATCにて示されるカウント値と、STCにて示されるカウント値とを、連続させることができ、かかる連続化により、多重分離部３による多重分離処理や、ビデオデコーダ４〜PGデコーダ７によるデコード処理を途切れなく行うことができる。
＜ビデオデコーダ４＞
ビデオデコーダ４は、Transport Buffer(TB)４a、Multiplexed Buffer(MB)４b、Coded Picture Buffer(CPB)４c、Decoder４d、Re-order Buffer４e、スィッチ４fから構成される。【００８８】
Transport Buffer(TB)４aは、ビデオストリームに帰属するTSパケットがPID Filter３bから出力された際、一旦蓄積されるバッファである。
Multiplexed Buffer(MB)４bは、Transport Buffer４aからElementary Buffer４cにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。【００８９】
Elementary Buffer(EB)４cは、符号化状態にあるピクチャ(Iピクチャ、Bピクチャ、Pピクチャ)が格納されるバッファである。
デコーダ(DEC.)４dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の復号時刻（DTS）ごとにデコードすることにより複数フレーム画像を得て、ビデオプレーン８aに書き込む。【００９０】
Re-order Buffer４eは、復号されたピクチャの順序を、符号化順序から表示順序に入れ替えるためのバッファである。
スィッチ４fは、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
＜オーディオデコーダ５＞
オーディオデコーダ５は、Transport Buffer(TB)５a、Buffer５b、Decoder５cから構成される。【００９１】
Transport Buffer５aは、PID Filter３bから出力されたTSパケットを、先入れ先だし式に格納して、オーディオデコーダ５ｃに供する。
Buffer５bは、PID Filter３bから出力されたTSパケットのうち再生されるべきオーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ５ｃに供する。【００９２】
デコーダ５cは、Buffer５bに格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
＜IGデコーダ６＞
IGデコーダ６は、Transport Buffer(TB)６a、Coded Data Buffer(CDB)６b、Stream Graphics Processor(SGP)６c、Object Buffer(OB)６d、Composition Buffer(CB)６e、Graphics Controller(Ctrl.)６fから構成される。【００９３】
Transport Buffer(TB)６aは、IGストリームに帰属するTSパケットが一旦蓄積されるバッファである。
Coded Data Buffer(CDB)６bは、IGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)６cは、グラフィクスデータを格納したPESパケットをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObject Buffer６dに書き込む。【００９４】
Object Buffer６dは、Stream Graphics Processor６cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer(CB)６eは、グラフィクスデータ描画のための制御情報が配置されるメモリである。
Graphics Controller(Ctrl)６fは、Composition Buffer６eに配置された制御情報を解読して、解読結果に基づく制御をする。
＜PGデコーダ７＞
PGデコーダ７は、Transport Buffer(TB)７a、Coded Data Buffer(CDB)７b、Stream Graphics Processor(SGP)７c、Object Buffer(OB)７d、Composition Buffer(CB)７e、Graphics Controller(Ctrl)７fから構成される。【００９５】
Transport Buffer(TB)７aは、PGストリームに帰属するTSパケットが多重分離部３aから出力された際、一旦蓄積されるバッファである。
Coded Data Buffer(CDB)７bは、PGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)７cは、グラフィクスデータを格納したPESパケット(ODS)をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer７dに書き込む。【００９６】
Object Buffer(OB)７dは、Stream Graphics Processor７cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer(CB)７eは、グラフィクスデータ描画のための制御情報(PCS)が配置されるメモリである。
Graphics Controller(Ctrl)７fは、Composition Buffer７eに配置されたPCSを解読して、解読結果に基づく制御をする。【００９７】
ATC Counnter３ｃ、STC Counter３ｄによるカウント値に、ATC Diff,STC Diffが加算されることで、previous PlayItemにおけるATC Sequenceと、Current PlayItemにおけるATC Sequenceとは連続した値になり、previous PlayItemにおけるSTC Sequenceと、Current PlayItemにおけるSTC Sequenceも連続した値になる。
このように、ATC、STCが連続した値になった状態において、Read Buffer、Elementary Buffer のバッファ状態がどのように変化するかについて説明する。
＜Read Bufferのバッファ状態＞
図２５は、Read Bufferのバッファ状態を示す図である。横軸は時間軸であり、縦軸は各時点における蓄積量を示す。本図に示される蓄積量は、Read BufferにSourceパケットが蓄積されることによる単調増加と、Read BufferからSourceパケットが出力されることによる単調減少とを繰り返す形になっている。かかる単調増加の傾きは、AVClipをRead Bufferに読み出す転送速度(Rud)と、Read BufferからAVClipを出力する転送速度(Rmax)との差、すなわちRud-Rmaxで増加する。この時、データバッファがオーバーフローしないように、ドライブからのAVClip読み出しは、休止しながらなされる。【００９８】
図中の単調減少は、光ディスクからのデータの読み出しがストップするためのものであり、その傾きは、転送速度Rmaxとなる。かかる単調減少は、先端部エクステントの読出し完了後、終端部エクステントへとジャンプする際、発生する。
かかるジャンプの間に、Read Buffer２におけるAVClip#1のデータが枯渇することがなければ、終端部エクステントを読み始めると同時に、再度Rud-Rmaxの速度でデータは増加してゆく。そのため、デコーダへのデータ転送は途切れることなくシームレスな再生を行うことが可能である。つまりシームレスな再生を実現するためには、ジャンプ前の先端部エクステントのサイズが十分に大きければ、次の終端部エクステントへジャンプしている間も、Read Bufferに格納されているデータをデコーダに送り続けることで、データの連続的な供給が保証できる。【００９９】
次にBD-ROMにおいてAVClipのシームレス接続を行うための物理的なディスクの配置についての設定方法および条件を説明する。この説明には、図２５を引用する。
AVClipをシームレス接続するには、各AVClipを構成するエクステントの配置もシームレス接続を満足させるように設定する必要がある。各AVClipがシームレス接続になるようにエクステントを配置するには、各AVClip内のエクステントについてはそれぞれ単独のAVClipとしてシームレスに再生可能なようにエクステントの配置を行う。それとともに、一のAVClipを構成する先端エクステント及び終端エクステントは、一方から他方へと相互にジャンプできるように配置する。具体的にいうと、個々のエクステントの大きさを、所定の最小サイズ以上に設定し、一方から他方へとジャンプするにあたってのジャンプ距離を、最大ジャンプ距離Sjump_maxを越えないように設定する。例えば、図１８の場合、AVClipの終端部分と先端部分とは、シームレス接続を実現する必要があるので、前半エクステントは、終端部分へのジャンプ距離を考慮した最小エクステントサイズ以上に設定する。尚且つ、後半エクステントの終端部分から、前半エクステントの先端部分までのジャンプ距離は最大ジャンプ距離Sjump_max以下になるように設定する。【０１００】
同様に後半エクステントは、最小エクステントサイズ以上に設定し、かつ後半エクステントの終端部分から先端部分までのジャンプ距離は最大ジャンプ距離Sjump_max以下になるように設定する。
以上のことから、エクステントの長さを、Tjumpの間にRead Buffer２に蓄積されたデータが枯渇しないサイズ以上にすることによって、シームレスな再生を保証することができる。シームレスな再生を保証するエクステントのサイズは以下の式で表すことができる。【０１０１】
(Sextent×8)/(Sextent×8/Rud+Tjump)>=Rmax ・・・(1)
式（１）において、Sextentはエクステントのサイズをバイトで表し、Tjumpは一つの先端部エクステントから次の終端部エクステントへの最大ジャンプ時間を秒で表す。RudはディスクからのAVClipの読み出し速度、RmaxはAVClipのビットレートを表し、単位は、ビット/秒である。なお、Sextentに乗じられている「８」は、バイト/ビットの換算のためである。以下、式（１）によって算出されるシームレスな再生を保証するエクステントサイズの最小値を最小エクステントサイズと定義する。【０１０２】
ただし、Read Buffer２のサイズは限られるため、Read Buffer２へ最大にデータを読み出した状態から、シームレスに再生できる最大のジャンプ時間が規定される。例えば、先端部エクステントのサイズの読み出しによって、Read Buffer２に蓄積されるAVClipのRead Buffer２が、バッファサイズ一杯の状態になっても、次のエクステントまでの距離が非常に大きい場合、終端部エクステントまでジャンプし読み出しを開始するまでにバッファが枯渇してしまい、シームレスの再生を行えない。このシームレス再生を保証できる最大のジャンプ時間を最大ジャンプ時間(Tjump_max)とする。また、最大ジャンプ時間内にジャンプできるデータサイズを最大ジャンプサイズ（Sjump_max）と定義する。最大ジャンプサイズの大きさは、Read Buffer２やビットストリーム、ドライブのアクセススピードなどから所定の規格等で定められる。【０１０３】
＜Elementary Buffer の時間的遷移＞
図２６は、ビデオデコーダにおけるElementary Buffer における蓄積量の時間的遷移を示す図である。上段は、previous PlayItemによる再生で、ストリームを読み込む場合の、Elementary Buffer における蓄積量の時間的遷移を示す。下段は、Current PlayItemによる再生で、ストリームを読み込む場合の、Elementary Buffer における蓄積量の時間的遷移を示す。【０１０４】
上段及び下段に示された、グラフの読み方について説明する。横軸は時間軸であり、縦軸は各時点における蓄積量を示す。本図に示すように、Elementary Buffer における蓄積量の時間的遷移は、ノコギリ波形をなす。
t_in_startは、シームレスに接続する場合に、Elementary Buffer への先頭ピクチャデータの入力が開始される時刻を示す。【０１０５】
t_in_endは、Elementary Buffer への最後のピクチャデータの入力が終了する時刻を示す。
t_out_endは、Elementary Buffer からの最後のピクチャデータの出力が終了する時刻を示す。
Last DTSは、最後のピクチャデータのデコードが終了する時点を示す。【０１０６】
First DTSは、先頭のピクチャデータのデコードが終了する時点を示す。
t_in_startからt_in_endまでは、Elementary Buffer の入出力が同時になされている期間を示す。当該期間におけるノコギリ波形は、各ピクチャデータがElementary Buffer に読み込まれることによるバッファ量の単調増加と、ピクチャデータがElementary Buffer から取り出されることによる単調減少とを意味する。傾きは、Elementary Buffer への転送速度Rbx１を示す。【０１０７】
t_in_endからt_out_endまでは、Elementary Buffer からの出力のみになっている期間を示す。当該期間における階段波形は、ピクチャデータがElementary Buffer から取り出されることによる単調減少を意味する。
上述したようなATC Sequence、STC Sequenceに、ATC Diff,STC Diffが加算されることで、previous PlayItemにおけるt_in_endと、Current PlayItemにおけるt_in_startは、一致した時点となる。また Last DTSの一フレーム後に、First DTSが存在している。このような一致が発生すると、バッファオーバーフローの発生が危惧される。【０１０８】
つまり、previous PlayItemにて再生されるべきAVClipと、これに引き続き、Current PlayItemにて再生されるべきAVClipとをシームレスに再生する際、previous PlayItemにより再生されるべきAVClipが、Elementary Buffer に残っている状態を想定して、AVClipの割当符号量を決める必要がある。つまり、connection_condition“=1”での接続状態では、各バッファにはデータがない状態を想定してデータ作成を開始すればよい。しかし、connection_condition＝5で再生されるべきAVClipを作成する場合には、previous PlayItemにより再生されるべきAVClipが、バッファに残っている状態を初期状態として、Current PlayItemにおけるAVClipの作成を開始する必要がある。【０１０９】
動画メニュー用AVClipの場合、AVClipにおける終端部分のデコードが完了した時点でのバッファ状態を初期状態として、デコーダモデルが破綻しないように動画メニュー用AVClipを作成する必要がある。
そこで、動画メニュー用AVClipは、previous PlayItemにて参照されるAVClipのビデオデータのElementary Buffer の遷移において、t_out_end −t_in_endの値がT時間になるように、多重化がなされる。このT時間については、AVClipごとに時間を変化させたり、固定値に設定される。【０１１０】
Current PlayItem側のAVClipにおけるt_in_startは、previousPlayItem側のt_in_endに近い位置に設定されるので、上述したようなT時間にあたる時点から、t_out_startまでの時点には、その後のビデオデータの再生がシームレスに再生されるように符号量を割り当てる必要がある。たとえば、バッファ上限値であるB_maxになるような符号量割当てがなされねばならない。かかる符号量割当てには、入力制限直線が用いられる。どのように用いるかというと、入力制限直線は、Elementary Buffer へのビットレートRbx1を下回るような符号量割当てに利用される。【０１１１】
図２７は、Elementary Buffer における蓄積量の遷移と、Elementary Buffer におけるバッファ容量の遷移とを示す。上段が、previousPlayItemにおけるバッファ容量の時間的遷移を示し、下段が、Current PlayItemにおける蓄積量の時間的遷移を示す。
図２８は、入力制限直線を示す図である。入力制限直線は、データ入力終了時刻(t_in_end)を通過し、バッファ容量を示すノコギリ波形と接する直線を求めることで、導出される。【０１１２】
ストリームの先端部分における符号量割当てが、入力制限直線に等しいか、或はそれ以下であるなら、previous PlayItemに対応する入力期間において、Current PlayItemのためのストリーム読込みを実現するにしても、Elementary Buffer がオーバーフローすることはない。
previous PlayItemによる再生におけるt_in_endと、Current PlayItemによる再生におけるt_in_startとを同一の時間軸上で一致させることで、これらの時間的遷移は、図２９のようになる。かかる一致にて、一個のPlayItem情報による、同一AVClipの再生の繰り返しはシームレスになされる。【０１１３】
以上が、原則的なビデオストリームに対する符号量割り当てである。しかしAVClipに、オーディオストリームが多重化されていると、事情が変わってくる。それは、オーディオはビデオよりもバッファサイズが小さく、フレーム間隔も細かいというオーディオストリームの特性による。かかる特性により、オーディオデータのバッファへの転送終了時刻は遅れるので、ビデオのvbv_delayの値が引きずられる形で小さくなってしまう。【０１１４】
図３０は、ビデオの時間的遷移と、オーディオの時間的遷移とを対応付けて示す図である。第１段目は、previous PlayItemと、Current PlayItemとを連続させる場合のビデオストリームの時間的遷移を示し、第２段目は、previous PlayItemと、Current PlayItemとを連続させる場合のオーディオストリームの時間的遷移を示す。この第１段目における時間的遷移は、基本的には、図２６のものをベースにしているが、その表記を一部変更している。つまり、t_in_startは、V1_startと読み替えており、t_in_endは、V1_endと読み替えている。Last DTSは、V1_DTS1と読み替えている。First DTSは、V2_DTS1と読み替えている。【０１１５】
この第２段目によると、オーディオストリームにおけるElementary Buffer の時間的遷移は、オーディオデータがElementary Buffer に供給されることによる単調増加と、Elementary Buffer からオーディオデータが取り出されることによる単調減少とを繰り返していることがわかる。この第２段目のうち、オーディオデータの転送が終了する時刻を、A1_endとする。バッファサイズが小さく、フレーム間隔も細かいという特性により、オーディオデータの転送終了(A1_end)は、V1_endからかなり遅れていることがわかる。オーディオデータのバッファへの転送終了時刻は遅れるため、Current PlayItemによるビデオデータの転送開始が、かなり遅れることになる。【０１１６】
ここで、Current PlayItemによる最初のデコード時刻をV2_DTS1とする。また、Current PlayItemによるバッファへの転送開始時刻をV2_startとする。これらを用いると、Current PlayItemにおいて、バッファへの転送を開始してから、デコードが終了するまでのバッファリング時間(vbv_delayと呼ばれる)は、以下の数式で与えられる。
vbv_delay = 先頭デコード時刻(V2_DTS1) - バッファへの転送開始時刻(V2_start)
つまり、オーディオデータの転送終了が遅れることで、Current PlayItemにおけるビデオ転送のvbv_delayの値が引きずられる形で小さくなってしまうのである。
そこで、Audioの属性と、トランスポートストリーム(TS)化のオーバヘッド等を元に、Vbv_delayを算出し、その値をを用いて、接続先ビデオ(ここでは、Current PlayItemにより再生されるAVClip#1の先端部分)のエンコードを行う。【０１１７】
以下、Vbv_delayの計算方法について解説する。
（１）. Audioの転送遅延を求める。図３０の第３段目におけるAdelayは、この転送遅延を具体的に示したものである。
Audioの転送Bitrate(bps)     ：Abitrate
Audioのバッファサイズ(bits) ： Abufsize
Audioデータをバッファに蓄積できる時間(sec): Adelay = Abufsize   / Abitrate
この図３０の第２段目に示すように、求めるべきVBV_delayは、かかるAdelayから、以下に求めるVframe,Aoverlapを引いた値となる。【０１１８】
（２）. TS化のオーバヘッドを求める
・ Clip#1は6KB Alignmentの制約がある。
これは、Clip#1の終端に最大(6KB/192)*188のNullパケットを入れる必要があるからである。
・Clip#2の先頭は、4*188byteのシステムパケットが必要となる。
TSOverhead = ( 6*1024/192*188 + 4*188 ) / Ts_recording_rate 
= 36*188 / Ts_recording_rate
（３）Audioのオーバラップ区間を求める。図３０の第２段目における“Aoverlap”は、このオーバラップ区間を示している。ここで、ワーストケースを見積もると、Audioのワーストオーバラップ区間は1frameとなる。よって、ワーストオーバラップ区間は以下の計算により求められる。【０１１９】
Aoverlap = サンプル数 /  サンプリング周波数
（４）Videoの先頭DTSと、PTSの差Vpts1-dts1を求める。これは、ビデオの１フレーム間隔となり、ビデオのフレームレートにより決定される。図３０の第３段目におけるVframeは、このVpts1-dts1の具体的な値を示している。
Vpts1-dts1= 1 / ビデオフレームレート
上述したように、求めるべきVBV_delayは、かかるAdelayから、以下に求めるVframe,Aoverlapを引いた値なので、以下の数式から、VBV_delayを計算することができる。【０１２０】
VBV_delay = Adelay - TSOverhead  - Aoverlap - Vpts1-dts1を求める。
ただし、TSに含まれるAudioが複数ある場合は、上記値の最も小さい値を適用する。
AVClipに以下の2つのビットレートを有するオーディオストリーム(Audio1,Audio2)が多重化されていて、これのオーディオストリームが以下のようなものである場合、vbv_delayがどれだけになるかを計算してみる。
Audio1 = AC3：448kbps, サンプリング周波数=48KHZ, サンプル数=1536
Audio2 = DTS:1509kbps, サンプリング周波数=48KHZ, サンプル数=512
Ts_recording_rate = 48Mpbs
VideoFrameRate = 24Hz
1. まず始めに、Audio1のVBV_delayは、以下の通りとなる。
Adelay   = 18640*8 / 448000 = 0.3328
TSOverhead = 36*188 / 6000000 = 0.0012
Aoverlap = 1538/48000 = 0.0320
Vpts1-dts1 = 1/24 = 0.0416
VBV_Delay = 0.3328 - 0.0012 - 0.0320 - 0.0416 = 0.2580
2. またAudio2のVBV_delayは、以下の通りとなる。
Adelay   = 43972*8 / 1509000 = 0.2331
TSOverhead = 36*188 / 6000000 = 0.0012
Aoverlap = 1538/48000 = 0.0106
Vpts1-dts1 = 1/24 = 0.0416
VBV_Delay = 0.233 - 0.0012 - 0.0106 - 0.0416 = 0.1796
Audio2のVBV_delayの方が小さいため、符号化にあたっては、Audio2のVBV_Delayを採用する。
このようにvbv_delayが算出されれば、V2_DTS1から、vbv_delayを引いた時刻(V2_DTS1−vbv_delay)を指し示すよう、ビデオデータを格納したTSパケット、及びオーディオデータを格納したTSパケットにATSを付すことでSourceパケットを得る。こうすることで、previous PlayItemによるAVClip再生と、Current PlayItemによるAVClip再生とをシームレスに行うことが可能になる。
ビデオストリームに割り当てることができる符号量は、vbv_delayと、Elementary Buffer の入力レートとに依存するので、vbv_delayが短いと、ビデオストリームに対する割り当て符号量を、低い値に変更にする必要がある。図３１は、割当符号量変更前の、ビデオストリーム用Elementary Buffer における時間的遷移と、割当符号量変更後の、ビデオストリーム用Elementary Buffer における時間的遷移とを対比して示す図である。ビデオがデコードされる時点や、ビデオ、オーディオが再生される時点の間隔(ノコギリ波形の個々の間隔や階段波形の個々の間隔)は、本来、一定間隔であるが、本図では、作図の都合上、これらの間隔は必ずしも、一定にはなっていないことは予め留意されたい。破線の時間的遷移が、割当符号量変更前の時間的遷移であり、実線の時間的遷移が、割当符号量変更後の時間的遷移である。破線の時間的遷移は、図２９に示したものと同じである。【０１２１】
vbv_delayを小さくしたため、割当符号量変更の時間的遷移は、総じて縮小化されていることがわかる。このようにビデオストリームのエンコードにあたっては、Elementary Buffer に対するオーディオ入力を考慮して、vbv_delayの調整を行い、これに基づき割当符号量を変化させるので、複数のPlayItem情報で、1つのAVClipを繰り返しデコーダに投入したとしても、当該デコーダにおけるElementary Buffer が破綻することはない。【０１２２】
この図２６から図３１までの説明において、仮の符号量でビデオストリームをエンコードしてみるという第１のパスと、vbv_delayから符号量を算出しなおすという第２のパスとが実行されている。つまり、“ツーパスエンコード”が実現されていることがわかる。第１パスの実行後、ビデオストリームとオーディオストリームとを共にElementary Buffer に読み出すためのvbv_delayを求め、このvbv_delayに基づき、ビデオストリームに割り当てるべき符号量が第２パスで算出されるので、999個のPlayItem情報から同じ動画メニュー用AVClipが繰り返し再生される場合であっても、再生装置におけるバッファモデルを破綻させることはない。こうすることで、999個のPlayItem情報により、AVClipの再生をシームレスに繰り返すという、動画メニュー特有の再生処理を実現することができる。【０１２３】
図３２は、動画メニューの具体例を示す図である。本図において第１段目は、PlayList全体の時間軸を示し、第２段目は、メニュー用AVClipにて再生される複数のピクチャを示す。第１段目は、PlayList情報を構成する、999個のPlayItem情報のうち、先頭の３つ(PlayItem情報#1,#2,#3)を示す。本図によると、PlayList全体の時間軸において、00:00から01:00まで、01:00から02:00まで、02:00以降は、同じ絵柄(Please select!!、Title#1、Title#2の選択を受け付けるボタン、These Title are Playable)が繰り返し表示されていることがわかる。【０１２４】
これらの繰り返しは、PlayList情報内に存在するPlayItem情報によるものである。個々のPlayItem情報の接続状態は、connection_condition情報によりconnection_condition＝5と規定されているので、第２段目におけるピクチャ再生は、途切れることなくなされる。  
以上のように本実施形態によれば、1つのPlayList情報内に、999個のPlayItem情報を設け、これらのPlayItem情報間の接続状態をconnection_condition＝5と規定するので、たとえ、デジタルストリームの再生を命じるコマンドと、当該コマンドの実行を反復させるジャンプコマンドとの間では、動画像の静止やボタン、字幕の消去が発生するとしても、999個のPlayItem情報が再生されている間は、動画像の静止やボタン、字幕の消去が生じることはない。999分=１６.５時間ものの間、動画メニューの再生途切れが発生しないので、デジタルストリームの時間長が１分程度であっても、ジャンプコマンドを実行して、再生コマンドの実行を反復することによる再生の途切れは、１６.５時間のうち、１回となり、再生の途切れがない入力待ちを、長い時間継続することができる。【０１２５】
また、この継続には、記録媒体の容量を多く費やすることもないので、記録媒体の容量を大きく確保したまま、途切れのない動画メニューを実現したいという、現実的な要請に応えることができる。
(第２実施形態)
第１実施形態での図１７ではAVClipを一つだけ用意したが、本実施形態は、2つのAVClipを用意してそれを繰り返し再生するようにPlayItem情報を構成する実施形態である。図３３は、第２実施形態に係る動画メニューの構成を示す図である。第１段目は、動画メニュー用AVClipを構成する2つのAVClip#1,#2を示す。第２段目は、PlayList情報を示す。このPlayList情報には、第１実施形態同様、999個のPlayItem情報が存在する。これら999個のPlayItem情報のうち、奇数番目のPlayItem情報(PlayItem情報#1,#3,#5)にはAVClip#1が設定され、偶数番目のPlayItem情報(PlayItem情報#2,#4,#6)には、AVClip#2が設定されている。【０１２６】
このように設定することで、AVClipの構成に汎用性を持たせることができ、コンテンツメーカーの意図通りにAVClipの構成を変えることが可能である。例えば、図３３では、AVClip#1＝＞AVClip#2＝＞AVClip#1＝＞AVClip#2というように、単純なAVClipのループ再生だけではなく、AVClipの再生内容を組み合わせることが可能となる。
(第３実施形態)
第１実施形態の図１７ではAVClipを一つだけ用意したが、本実施形態は、3つのAVClipを用意してこれらでマルチアングル区間を構成することにより、動画メニューを構成する実施形態である。【０１２７】
図３４は、マルチアングル区間を構成する3つのAVClip(AVClip#1、AVClip#2、AVClip#3)を示す図である。第１段目は、かかる3つのAVClip(AVClip#1、AVClip#2、AVClip#3)を示し、第２段目は、BD-ROMにおけるエクステントの配置を示す。第１段目によると、AVClip#1は3つのエクステントA0,A1,A2、AVClip#2は3つのエクステントB0,B1,B2、AVClip#3は3つのエクステントC0,C1,C2から構成されているが、これらのエクステントは、第２段目に示すように、A0→B0→C0→A1→B1→C1→A2→B2→C2というように、BD-ROM上で交互に配置されていることがわかる。【０１２８】
マルチアングル区間を構成するAVClipのエクステントは、マルチアングル区間の先頭のAVClipのエクステントの先頭にシームレスに接続できるように、エクステントのサイズやジャンプ距離を調整しながらディスク上に配置されている。
例えば、図３４でいえば、AVClip#1、AVClip#2、AVClip#3のそれぞれの終端エクステントA2、B2、C2は、AVClip#1、AVClip#2、AVClip#3のそれぞれの先頭エクステントA０、B０、C０の何れにジャンプすることができるよう、配置及びサイズが決定されている。具体的には、終端エクステントと、先端エクステントとのすべての組み合わせを求め、どの組合せであっても、最大ジャンプ距離を越えないように配置され、各エクステントの大きさが第１実施形態で述べた最小エクステントサイズ以上に設定されている。【０１２９】
図３５は、マルチアングル区間を用いて動画メニューを構成するPlayList情報の構成を示す図である。本図におけるPlayList情報は、第１実施形態に示したものと同様、999個のPlayItem情報を有する。第１段目は、これらのPlayItem情報のうち、先頭の2つのもの(PlayItem情報#1,#2)の構成を示す。第１実施形態で述べたように、PlayItem情報は、In_Time、Out_Timeの設定先となるAVClipを示すClip_Information_file_nameを有する。このClip_Information_file_nameにて、PlayItem情報が対応するAVClipを一意に指定することができる。このClip_Information_file_name以外にも、PlayItem情報はMulti_clip_entriesを有している。このMulti_clip_entries内のClip_Information_file_nameを記述することで、マルチアングル区間を構成する他のAVClipを指定することができる。図中のPlayItem情報では、Multi_clip_entries内のClip_Information_file_nameが、AVClip#2、AVClip#3を指定しており、Multi_clip_entries外のClip_Information_file_nameは、AVClip#1を指定している。これらのマルチアングル区間は、いくつかのAVClipで構成され、例えばAVClipがそれぞれのメニュー映像を示している。これらマルチアングル区間を構成する個々のAVClipが、IGストリームを有している場合、ユーザは、リモコンに対するアングル切り替え操作にて、これら3つのAVClip内のIGストリームを選択的に再生することで、シームレスな動画メニューの切り替えを実現することができる。【０１３０】
(第４実施形態)
本実施形態では、本発明にかかる記録装置を実施するための形態について説明する。
ここで説明する記録装置は、オーサリング装置と呼ばれるものであり、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームイメージを生成するというのが、本発明にかかる記録装置の使用形態である。【０１３１】
図３６は、本発明にかかる記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、１）タイトル構造作成部１０、２）BDシナリオ生成部１１、３）リールセット編集部１６、４）ＪＡＶＡ（登録商標）プログラミング部２０、５)素材作成/インポート部３０、５)素材作成/インポート部３０、６）ディスク作成部４０、７)検証装置５０、８）マスター作成装置６０から構成される。【０１３２】
従来のオーサリングのための記録装置の場合、ＪＡＶＡ（登録商標）プログラムの編集を行う部分とAVClipやシナリオの作成を行う部分を並列的に実行できないという課題があった。そこで、本発明にかかる記録装置では、そうした課題を鑑み、ＪＡＶＡ（登録商標）プログラムの作成手段とシナリオ作成手段を分離できるような構成が採用されている。その内容についても下記で明らかにしていく。
１）タイトル構造作成部１０
タイトル構造作成部１０は、Index.bdmvで示される各タイトルがどのようなコンテンツで構成されるかを決定する。BD-ROMのディスク作成を行う際には、必ずこの構成要素を使ってタイトル構造を定義する。ここで作成されるタイトル構造は、リールセット編集部１６、BDシナリオ生成部１１、ＪＡＶＡ（登録商標）プログラミング部２０、素材作成/インポート部３０で利用される。タイトル構造の定義をオーサリングの最初のステップで実行することによって、リールセット編集部１６、BDシナリオ生成部１１、ＪＡＶＡ（登録商標）プログラミング部２０、素材作成/インポート部３０を利用する作業を並列的に実行できる。並列的に処理を実行する仕組みについては、後述の説明によって明らかにする。
図３７は、タイトル構造作成部１０で作成されるタイトル構造情報のデータ構造の例を示している。タイトル構造情報はツリー構造を持ち、ツリー構造のトップ項目のディスク名ノード[Disc XX]は、ディスクを識別する名前を示し、「タイトルリスト」ノード、「「プレイリストリスト」のノード、「BD-J Objectリスト」のノードと接続している。【０１３３】
「タイトルリスト」のノードは、Index.bdmvの原型であり、その配下には、「FirstPlay」のノード,「TopMenu」のノード,「Title#1」のノード,「Title#2」のノードが存在する。これらは、BD-ROMに収録されるタイトルに対応するノード、つまりタイトルノードであり、個々のノードは、最終的にindex.bdmvで示される各タイトルに対応している。これらのノードに付されたタイトル名“FirstPlay,TopMenu,Title#1,Title#2”は、予約語である。【０１３４】
タイトルノードの配下には、Play MainPlaylistのノード、Play MenuPlaylistのノード、Ｊａｖａ（登録商標） MainＪａｖａ（登録商標）Objectのノード、Play MainPlayListのノードが存在する。これらは、各タイトルがどのような動作するかを定義するものであり、"Play"のようなコマンド名、"Ｊａｖａ（登録商標）"のようなメソッド名と、引数にあたるターゲットとを持つ。【０１３５】
コマンドが"Play"の場合は、引数の内容は、そのタイトルから再生されるプレイリストの名前を示している。各プレイリストの名前によって示されるプレイリストについては、「プレイリストリスト」のノードの下に定義される。また、コマンドが"Ｊａｖａ（登録商標）"の場合は、引数の内容は、そのタイトルから実行されるBD-J Objectを示している。各BD-J Objectの名前によって示されるBD-J Objectについては、BD-J Objectリストのノードの下に定義される。【０１３６】
「プレイリストリスト」のノードの配下には、MenuPlayListのノード、MainPlayListのノードが存在する。これらは、プレイリストのノードであり、MenuPlayList,MainPlayListという予約語で命名されている。MenuPlayListのノード、MainPlayListのノードの配下には、ファイル名「00001」のノード、ファイル名「00002」のノード、ファイル名00003のノードが存在する。これらは、プレイリストファイルのノードである。図中では、これらのプレイリストファイルの名前には、00001,00002というファイル名、つまり、BD-ROMに格納するにあたっての、具体的なファイル名が与えられている。尚、PlayList情報は、タイトル構造作成部１０で設定されず、BDシナリオ生成部１１によって設定される。【０１３７】
BD-J Objectリストのノードの配下には、MainＪａｖａ（登録商標）Objectのノードが存在する。本ノードには、MainＪａｖａ（登録商標）Objectという予約語が命名されている。MainＪａｖａ（登録商標）Objectのノードの配下には、ファイル名 00001のノードが存在する。このノードは、BD-J Objectファイルのノードであり、BD-ROMに格納するにあたっての具体的なファイル名 00001が与えられる。尚、BD-J Objectは、タイトル構造作成部１０では設定されず、ＪＡＶＡ（登録商標）インポート部３５によって設定される。
２）BDシナリオ生成部１１
BDシナリオ生成部１１は、タイトル構造作成部１０によって作成されたタイトル構造情報を利用し、またオーサリングスタッフからのGUIを経由した操作に従ってシナリオを作成し出力する。ここでシナリオとは、デジタルストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、これまでの実施形態で述べたIndexTable、MovieObject、PlayListとして定義されている情報がシナリオにあたる。BD-ROMシナリオデータは、ストリームを構成する素材情報、再生経路情報、メニュー画面配置、メニューの遷移条件情報などを含む。また、BDシナリオ生成部１１が出力するBD-ROMシナリオデータは、後に説明するマルチプレクサ４５での多重化を実現するためのパラメータ等をも含む。ここでBDシナリオ生成部１１は、GUI部１２と、メニュー編集部１３と、PlayList生成部１４と、Movie Object生成部１５とから構成される。【０１３８】
＜GUI部１２＞
GUI部１２は、BDシナリオを編集するための操作を受け付ける。図３８は、メニュー画面構成の設定時のGUI画面の例を記したものである。本図におけるGUIは、画面構成設定ペイン２５０１と、動画プロパティペイン２５０２から構成されている。
画面構成設定ペイン２５０１は、メニューのボタンイメージの配置や構成を設定する操作をオーサリングスタッフから受け付けためのGUI部品である。例えば、オーサリングスタッフはボタンの静止画イメージを読み込み、静止画イメージを、この画面構成設定ペイン２５０１上で表示させて、ドラッグ・ドロップ操作を実行することで、どのような位置に配置するかを設定できる。【０１３９】
動画プロパティペイン２５０２は、メニューの背景に利用する動画のリールセットファイルの設定を受け付ける。具体的には、リールセットファイルのパス名「data/menu/maru/maru.reelset」と、シームレスにするか否かを受け付けるチェックボックスとを含む。
ボタン遷移条件ペイン２５０３は、各ボタン毎に生成され、リモコンの十字キーにおける方向と、各方向が指定された場合の、遷移先ボタンとを表示して、リモコンの十字キーで遷移方向が指定されたときのボタンの遷移先を、オーサリングスタッフに設定させる。例えば、先に述べた図の具体例では、Title#1の選択を受け付けるボタン(Title#1ボタン)と、Title#2の選択を受け付けるボタン(Title#2ボタン)とがピクチャに合成されている。図のGUIの一例では、これのボタン毎に、ボタン遷移条件ペイン２５０３が生成される。Title#1ボタンのボタン遷移条件ペイン２５０３では、右方向の押下時に、Title#2ボタンに遷移するよう遷移条件が規定されていて、左方向の押下時にも、Title#2ボタンに遷移するよう遷移条件が規定されている。【０１４０】
Title#2ボタンのボタン遷移条件ペイン２５０３では、右方向の押下時に、Title#1ボタンに遷移するよう遷移条件が規定されていて、左方向の押下時にも、Title#1ボタンに遷移するよう遷移条件が規定されている。
＜メニュー編集部１３＞
メニュー編集部１３は、オーサリングスタッフからのGUI部１２を経由した操作に従って、IGストリームを構成するボタンの配置や、ボタンの確定時に実行されるナビゲーションコマンド、ボタンアニメーションなどの機能を作成する。【０１４１】
前述したシームレス動画メニューのデータ構造のシナリオを作成するにあたって、ニュー編集部１３は、メニューの背景映像としてシームレスに再生したい映像の選択を受け付ける。
＜PlayList生成部１４＞
PlayList生成部１４は、タイトル構造情報のプレイリストリストの内容を設定した上で、GUI部１２が受け付けたユーザ操作に基づき、999個のPlayItem情報からなるプレイアイテムシーケンスを有するPlayList情報を生成する。この際、PlayList生成部１４は、シームレス動画メニューのデータ構造にあうようにプレイリストを作成する。この作成にあたってPlayList生成部１４は、AVClipの数に合うようにPlayItem情報の個数を調整し、PlayItem情報におけるConnectioin_condition情報を設定する。具体的にいうと、PlayItem情報の個数を999個とし、１のPlayItem情報によるAVClipの再生と、直前のPlayItem情報によるAVClipの再生とを、シームレスに行わせる旨(CC=5)を、各PlayItem情報におけるConnectioin_condition情報に示させる。このようなconnection_condition情報の設定に伴い、マルチプレクサ４５で多重化を実現するパラメータとして、AVClip接続情報を生成する。各AVClip接続情報は、対応するAVClipを構成する個々のAVClipに対応するノードをもち、そのノードについて、Prev項目、Next項目を有する構造になっている。AVClip接続情報における各ノードは、プレイリスト情報に含まれるPlayItem情報にて、連続的に再生される、一群のAVClipのそれぞれを象徴的に表している。これらのノードは、詳細項目としてPrev項目,Next項目をもつ。【０１４２】
図３９は、図３２に示した3つのAVClipを作成するにあたってのAVClip接続情報の記述を示す図である。これまでに述べたように、AVClip#1は、動画メニュー用AVClipを構成するものなので、Prev項目、Next項目には、AVClip#1が設定されている。一方、AVClip#2、AVClip#3は、通常の映画作品を構成するものなので、AVClip#2のPrev項目は無指定「--」、Next項目はAVClip#3と記述され、AVClip#3のPrev項目はAVClip#2、Next項目は、無指定「--」と記述されている。各AVClip接続情報は、プレイリストにて参照される一連のAVClip列毎に作成される。【０１４３】
オーサリングスタッフが動画プロパティペイン２５０２のチェックボックスにチェックを行うと、AVClip接続情報におけるNext項目、Prev項目は、シームレスに接続するAVClipとして自分自身をさすように設定される。つまりシームレス接続ノードのPrevの項目、Nextの項目ともに自分自身であるAVClip#１を設定する。このように設定することで、シームレス動画メニューのための多重化処理をマルチプレクサー４５に行わせることが出来る。
＜Movie Object生成部１５＞
Movie Object生成部１５は、オーサリングスタッフによるプログラム記述を受け付けることで、Movie Objectを生成する。かかるプログラム記述は、BD-ROM規格に規定されているナビゲーションコマンドを、オーサリングスタッフが記述することでなされる。特にMovie Object生成部１５は、PlayPLコマンドの実行を反復させるJumpコマンドを、BD-JObject内に記述することで、ユーザからの操作待ちの制御を、再生装置に行わせる。
３）リールセット編集部１６
リールセット編集部１６は、ユーザ操作に基づき、リールセットの設定を行う。リールセットとは、ビデオ、オーディオ、字幕、ボタンなど映画として完結する複数のエレメンタリーストリームの関係を表す情報の集合である。このリールセットを定義することで、１本の映画が1本のビデオ、２本のオーディオ、３本の字幕、１本のボタンストリームから成る場合に、それらが一本の映画を構成することを指定することができる。またHDMI送受信部１６は、映画本編に対して、一部分だけ映像が異なるようなディレクターズカットを指定したり、複数のアングルを持つマルチアングルを設定したりする機能を有する。リールセット編集部１６から出力されるリールセットファイルとは、前述のような情報をまとめたものである。
４）ＪＡＶＡ（登録商標）プログラミング部２０
ＪＡＶＡ（登録商標）プログラミング部２０はIDクラス作成部２１と、ＪＡＶＡ（登録商標）プログラム編集部２２、BD-J Object作成部２３から構成される。【０１４４】
＜IDクラス作成部２１＞
IDクラス作成部２１は、タイトル構造作成部１０によって作成されたタイトル構造情報を利用しIDクラスソースコードを作成する。IDクラスソースコードは、ＪＡＶＡ（登録商標）プログラムが最終的にディスク上に作成されるIndex.bdmvやPlayList情報にアクセスするためのＪＡＶＡ（登録商標）クラスライブラリのソースコードである。このIDクラスソースコードをコンパイルによって得られるＪＡＶＡ（登録商標）クラスライブラリをIDクラスライブラリと呼ぶことにする。図４０（ａ）は、IDクラスソースコードのプレイリストにアクセスするためのヘッダファイルのソースコードの例を図示したものである。図４０（ａ）のclass PlayListIDは、プレイリスト番号を指定することでディスクから所定のプレイリストファイルを読み込むコンストラクタをもち、このコンストラクタを実行して作成したインスタンスを利用することでAVClipの再生等が実行可能なように設計、実装されている。図４０（ａ）のMainPlaylist, MenuPlaylistのように、IDクラス作成部２１は、タイトル構造情報で定義されるプレイリストノードの名前を利用して、IDクラスライブラリの変数名を定義する。このとき指定するプレイリスト番号は、ダミーの番号を設定しておく。このプレイリスト番号を正しい値への変換は、後述するID変換部４１で行われる。
＜ＪＡＶＡ（登録商標）プログラム編集部２２＞
ＪＡＶＡ（登録商標）プログラム編集部２２は、テキストエディタのようなキーボード入力によってＪＡＶＡ（登録商標）プログラムのソースコードを直接編集することで、ＪＡＶＡ（登録商標）プログラムのソースコードを作成し、ＪＡＶＡ（登録商標）プログラムソースコードを出力する。このとき、ＪＡＶＡ（登録商標）プログラム編集部２２によって作成されるＪＡＶＡ（登録商標）プログラムのうち、BDシナリオ生成部１１で定義される情報をアクセスするメソッド部分の記述には、IDクラスライブラリが用いられる。例えば、図４０（ａ）のIDクラスライブラリを利用して、プレイリストにアクセスする場合、ＪＡＶＡ（登録商標）プログラムは、IDクラスライブラリで定義される変数であるMainPlaylist, MenuPlaylistを利用する。また、ＪＡＶＡ（登録商標）プログラムソースコードから利用されるフォントファイルや静止画、オーディオ等の情報は、プログラム付属情報として出力される。ＪＡＶＡ（登録商標）プログラム編集部２２は、あらかじめＪＡＶＡ（登録商標）プログラムのテンプレートが用意されていて、オーサリングスタッフがGUI等を通じてプログラムを作成する手段であってもよく、ＪＡＶＡ（登録商標）プログラムソースコードを作成できる手段であれば形態は問わない。【０１４５】
＜BD-J Object作成部２３＞
BD-J Object作成部２３は、ＪＡＶＡ（登録商標）プログラム編集部２２で作成したＪＡＶＡ（登録商標）プログラムソースコードとIDクラス作成部２１によって作成したIDクラスソースコードを元に、BD-ROMで定義されるBD-J Objectのデータフォーマットを作成するためのBD-J Objectを作成する。BD-J Objectでは、実行するＪＡＶＡ（登録商標）プログラムから再生されるプレイリスト名を指定する必要があるが、この時点では、IDクラスソースコードを元に、IDクラスライブラリで定義される変数名を設定する。
５)素材作成/インポート部３０
素材作成/インポート部３０は、字幕作成部３１、オーディオインポート部３２、ビデオインポート部３３、ＪＡＶＡ（登録商標）インポート部３５から構成される。入力されるビデオ素材、オーディオ素材、字幕用素材、ＪＡＶＡ（登録商標）プログラムソースコード等を、BD-ROM規格に準拠したビデオストリーム、オーディオストリーム、字幕データ、ＪＡＶＡ（登録商標）プログラムソースコード等に変換し、ディスク作成部４０に受け渡す。
＜字幕作成部３１＞
字幕作成部３１は、字幕と表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠した字幕データを生成して出力する。
＜オーディオインポート部３２＞
オーディオインポート部３２では、あらかじめMPEG-AC3などで圧縮されているオーディオが入力された場合には、対応するビデオに対するタイミング情報などを付加したり、余分なデータを削除したりして出力し、圧縮されていない場合には、オーサリングスタッフが指定するフォーマットに変換して出力する。
＜ビデオインポート部３３＞
ビデオインポート部３３は、あらかじめ圧縮されていない非圧縮ビデオファイルが入力された場合には、かかるビデオファイルをビデオエンコーダにインポートする。あらかじめMPEG２、MPEG４-AVC、VC１などの方式で圧縮されているビデオストリームが入力された場合、必要に応じて不必要な情報を削除するなどしてから出力する。
＜ビデオエンコーダ３４＞
ビデオエンコーダ３４は、オーサリングスタッフが指定するパラメーターに従って、割当符号量の算出を行い、入力されたビデオファイルの圧縮を行って、その結果得られた、圧縮後の符号化系列をビデオストリームとして出力する。動画メニュー用AVClipを構成する場合、ビデオエンコーダ３４は、ビデオストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファ容量に基づき、入力制限直線やvbv_delayを導き出す。この導出の過程は、第１実施形態で述べたようなツーパスエンコードの過程であり、図２６から図３４に示した通りである。そして、こうして導出された入力制限直線やvbv_delayに基づき、AVClipの先端部分に対する割当符号量を決定する。割当符号量を定めた後、エンコードを行う。
＜ＪＡＶＡ（登録商標）インポート部３５＞
ＪＡＶＡ（登録商標）インポート部３５は、ＪＡＶＡ（登録商標）プログラム作成部２０によって作成されたＪＡＶＡ（登録商標）プログラムソースコード、プログラム付属情報、IDクラスソースコード、BD-J Object生成情報をディスク作成部４０に受け渡す。ＪＡＶＡ（登録商標）インポート部３５は、タイトル構造情報を利用し、インポートするＪＡＶＡ（登録商標）プログラムソースコード、プログラム付属情報、IDクラスソースコード、BD-J Object生成情報を構成するファイル群がどのBD-J Objectに対応するのかの関連付けを行い、タイトル構造情報のBD-J ObjectノードのBD-J Object情報を生成する。
６）ディスク作成部４０
ディスク作成部４０は、ID変換部４１、静止画エンコーダー４２、データベース生成部４３、ＪＡＶＡ（登録商標）プログラムビルド部４４、マルチプレクサー４５、フォーマット部４６、ディスクイメージ作成部４７から構成される。【０１４６】
データベースとは、前述のBD-ROMで定義されるIndex.bdmv、BD-JObject、プレイリスト、BD-J Objectなどの総称のことで、ディスク生成部４０は、入力されたBD-ROMシナリオデータ、ID変換部４１から渡されるBD-J Object情報を元にして、BD-ROMに準拠したシナリオデータを生成する。
＜ID変換部４１＞
ID変換部４１は、ＪＡＶＡ（登録商標）インポート部３５によって、ディスク作成部４０に渡されたIDクラスソースコードを、実際のディスク上のタイトル番号、プレイリスト番号と一致するように、変換する。例えば、図４０で言えば、MenuPlaylist、MainPlaylistを作成するために指定するプレイリスト番号を自動的に変更する。この変換は、タイトル構造情報のプレイリストノードを参照してなされる。図４０（ａ）において、MenuPlaylistとMainPlaylistの最終的なファイル名は、それぞれ00001、00002になるので、図４０（ｂ）のように変更されることとなる。また、ID変換部４１は、BD-J Object情報についても同様に変換処理を行う。BD-J Object内で定義されるプレイリスト名を、実際のディスク上のプレイリスト番号と一致するように、変換処理を行う。変換方法については、上記IDクラスソースコードと同じであり、変換されたBD-J Object情報はデータベース生成手段に渡される。【０１４７】
＜静止画エンコーダ４２＞
静止画エンコーダ４２は、入力されたBD-ROMシナリオデータに静止画または静止画が保持されている場所が含まれる場合に、入力素材に含まれる静止画用イメージの中から該当する静止画を選択し、BD-ROMに準拠したMPEG２、MPEG４-AVC、VC１のいずれかの形式に変換する。
＜ＪＡＶＡ（登録商標）プログラムビルド部４４＞
ＪＡＶＡ（登録商標）プログラムビルド部４４は、ID変換部４１によって変換されたIDクラスソースコードとＪＡＶＡ（登録商標）プログラムソースコードに対してコンパイル処理を行い、ＪＡＶＡ（登録商標）プログラムを出力する。
＜マルチプレクサ４５＞
マルチプレクサ４５は、BD-ROMシナリオデータに記述されているビデオ、オーディオ、字幕、ボタンなどの複数のエレメンタリーストリームを多重化して、MPEG２-TS形式のAVClipを得る。マルチプレクサー４５は、多重化パラメータを元にどのAVClipがどのAVClipに接続するかの情報を取得する。【０１４８】
また、マルチプレクサー４５は、上述したようなAVClipを出力すると同時に、AVClipに関する情報を持つClip情報を出力する。Clip情報は、個々のAVClip毎に設けられた管理情報、つまり、デジタルストリームの管理情報であり、EP_mapと、AVClipの符号化情報とを含み、データベースの一つである。マルチプレクサー４５によるClip情報の生成は、以下の手順で行われる。マルチプレクサ４５では、新たにAVClipが作成されるのと同時に、EP_mapを作成する。より具体的には、BD-ROM向けに生成されたデジタルストリームにおいて、含まれるビデオエレメンタリーストリームがMPEG２であればI Picture、MPEG４-AVCであればI PictureかIDR Picture、VC-1であればI Pictureが何処に存在するかを検出し、前述の各Pictureの表示時刻と、MEPG２-TSとなっているAVClipの何パケット目のTSパケットに前述の各Pictureの先頭データが入っているかを対応付けた情報である。マルチプレクサ４５は、自ら生成したEP_mapと、リールセットファイルから検出されるデジタルストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてClip情報を作成する。【０１４９】
EP_Mapをマルチプレクサ４５で作成する理由は、EP_Mapは、マルチプレクサーから出力されるMPEG２-TS形式のAVClipに非常に密接に関係している情報であり、また、BD-ROMでの使用のために作成されるAVClipは、ファイルサイズが非常に大きくなる可能性があるので、もしAVClipを作成後に、EP_Mapを作成しようとすると、大きなファイルサイズのAVClipを再度読み直す必要があるために、EP_Map作成に要する時間が必要となる。これに対して、AVClipを作成しながらEP_Mapを作成すれば、巨大なAVClipファイルを2度に渡って読み直す必要がないため、EP_Map作成のための時間を節減できる。【０１５０】
また、マルチプレクサ４５は、BD-ROMシナリオデータに含まれるマルチプレクサ４５のためのパラメータを利用し、多重化の方法を変える。例えば、多重化する対象となるprevious PlayItemにて参照されるAVClipが、Current PlayItemにて参照されるAVClipとシームレスに接続するようにパラメータが設定されている場合は、前述したようにバッファモデルを破綻させないように、previousPlayItemにて参照されるAVClipをデコードした後のバッファ状態を初期値として、Current PlayItemにて参照されるAVClipの多重化を行う。一つのAVClipを999個のPlayItem情報から参照して再生に供する場合、個々のPlayItem間の接続をシームレスを行うためのAVClipの多重化を行う。【０１５１】
この多重化は前述したように、previousPlayItemにおけるAVClipの、Elementary Buffer への転送が完了したときのバッファの状態を初期状態として、Current PlayItemにおいて、再度同じAVClipをElementary Buffer に読み込もうとした場合、Elementary Buffer の初期状態に影響されることなく、当該読み込みがなされるよう、AVClipを構成する、個々のSourceパケットに付されるべき、ATSの値を調整することでなされる。【０１５２】
＜フォーマット部４６＞
フォーマット部４６は、前述のデータベース、AVClip、ＪＡＶＡ（登録商標）プログラムを入力とし、BD-ROMフォーマットに適合したデータ構造で、ファイルの配置処理を行う。図２で定義されるディレクトリ構造を作成し、各ファイルを適切な箇所に配置する。この時、フォーマット部４６は、ＪＡＶＡ（登録商標）プログラムとAVClipの関連付けを行い、ファイル関連付け情報を作成する。【０１５３】
図４１は、ファイル関連付け情報を示す図である。本図に示すように、ファイル関連付け情報は、1つ以上のブロックに対応するノードからなる。各ノードは、まとまって読み出されるべきファイルを指定することができ、またファイルをシームレスに読み出すかどうかを規定するSeamless Flagを有している。図４１におけるファイル関連付け情報の具体例は、図２のファイルを読み出させることを想定する。図中のBlock#nに対応するノードは、ひとまとまりに読み出されるファイルとして、00001.bdjo、00001.mpls、00001.jar、00001.clpi、00001.m2tsを指定している。【０１５４】
図中のBlock#n+1に対応するノードは、ひとまとまりに読み出されるファイルとして、00002.mpls、00003.mpls、00002.clpi、00003.clpi、00002.m2ts、00003.m2tsを指定している。本図の例では、Block#nは、BD-J Objectである、00001.bdjoが実行される際に必要なファイルをディスクから読み込まれる順にまとめられている。
＜ディスクイメージ作成部４７＞
ディスクイメージ作成部４７は、前述のデータベース、AVClipを入力とし、BD-ROMフォーマットに適合したアドレスに割り付けてボリュームイメージを得る。BD-ROMに適合したフォーマットについては図２を用いて前述により説明した。また、そのボリュームイメージを作る場合には、フォーマット部４６によってファイル関連付け情報が利用される。ディスクイメージ作成部４７は、各ブロックを先頭から配置するようにし、かつ各ブロック内のファイル群は物理的に連続になるように配置する。例えば図４１の例の場合、図４２のように配置される。【０１５５】
図４２は、図４１のファイル関連付け情報に基づく、BD-ROM上のアロケーションを示す図である。本図に示すように、Block#nに属する00001.bdjo、00001.mpls、00001.jar、00001.clpi、00001.m2tsは、BD-ROM上の連続した領域に配置される。また、本図に示すように、Block#n+1に属する00002.mpls、00003.mpls、00002.clpi、00003.clpi、00002.m2ts、00003.m2tsはBD-ROM上の連続した領域に配置される。【０１５６】
このように再生に必要なファイル群を物理的に連続になるように配置することによって、再生するときのディスクの読み出しを効率的に行うことが出来るようになる。また、図４１の一例では、Block#n,#n+1におけるシームレスフラグがOnになっている。この場合は、各AVClipをシームレスに配置するように、前述したシームレスに再生するための物理的な配置の条件である最小エクステントサイズや最大ジャンプ距離を条件に満たすように、BD-ROMにおけるAVClipの配置を決定する。任意的であるが、ファイル関連付け情報におけるブロックには、マルチアングルフラグを追加することができる。この場合、ディスクイメージ作成部４７は、各AVClipがオーサリングスタッフのアングル切り替えに応じてAVClipの切り替えが出来るように、AVClipをインターリーブしてディスク上に配置する。インターリーブとは、AVClipを適切な単位でエクステントに分割され、ディスク上に交互に配置されることであり、その例を図４３に示している。
７)検証装置５０
検証装置５０は、エミュレータ部５１と、ベリファイア部５２とからなる。【０１５７】
＜エミュレータ部５１＞
エミュレータ部５１は、前述のボリュームイメージを入力として、実際の映画コンテンツを再生し、制作者が意図した通りの動作、例えばメニューから本編映画への遷移が正しく行われているか、字幕切り替えやオーディオ切り替えは意図したとおりに動作しているか、映像やオーディオの品質は意図したとおりにできているかなどを検証する。【０１５８】
＜ベリファイア部５２＞
ベリファイア部５２は、前述のボリュームイメージを入力として、制作されたデータが、BD-ROMの規格に準拠しているかどうかを検証する。
このようにボリュームイメージはエミュレータ部５１、およびベリファイア部５２で検証され、エラーが発見されると、然るべき前工程に戻って作業をやり直す。【０１５９】
８）マスター作成部６０
マスター作成部６０は、AVClip、PlayList情報、BD-JObjectを光ディスクに書き込む部材であり、上述したよう内部つの検証過程を経た後、BD-ROMプレス用データが完成させた上で、プレス工程を行うことで、BD-ROMの製造を行う。かかるプレス工程による光ディスクへの書き込みは一例に過ぎず、BD-REや、AVC-HDのような書き換え型の記録媒体に対しては、AVClip、PlayList情報、BD-JObjectをドライブ装置に引き渡すことで、書き込みに供してもよい。【０１６０】
次に図４４を参照しながら、本実施の形態に係る本実施の形態に係る記録装置における、オーサリング手順について説明する。
ステップS1において、タイトル構造作成部１０は、ユーザ操作に基づき、BD-ROMのタイトル構造を作成してゆく。これによりタイトル構造情報が作成される。
ステップS２において、BDシナリオ生成部１１は、ユーザ操作に基づき、シームレス動画メニューの構成を持つシナリオデータの作成を行う。これにより、BD-ROMシナリオデータには、シームレス動画メニューのためのPlayList情報が作成される。【０１６１】
ステップS３において、素材作成/インポート部３０は、オーサリングスタッフにより用意された動画、音声、静止画、字幕を、ディスク作成部４０にインポートする。
ステップＳ４は、タイトル構造情報にＪＡＶＡ（登録商標）タイトルが存在するかどうかを判定するステップである。存在する場合、ステップＳ２〜ステップＳ３と、ステップＳ５〜ステップＳ８とを並列に実行するが、存在しない場合、ステップＳ５〜ステップＳ８を実行せず、ステップＳ２〜ステップＳ３を実行した上、ステップＳ９に移行する。【０１６２】
ステップS５において、ＪＡＶＡ（登録商標）プログラミング部２０は、ユーザ操作に基づき、ＪＡＶＡ（登録商標）タイトル用のＪＡＶＡ（登録商標）プログラムソースコード、プログラム付加情報、IDクラスソースコードを作成する。
ステップS６において、ＪＡＶＡ（登録商標）インポート部３５は、ステップS５にて作成されたＪＡＶＡ（登録商標）プログラムソースコード、プログラム付加情報、IDクラスソースコードをディスク作成部４０にインポートする。以上のステップS５及びステップS６は、ステップＳ２におけるシナリオデータの作成や、ステップＳ３における素材作成/インポート処理と並列的に行われる。【０１６３】
ステップS７にて、ID変換部４１は、IDクラスソースコード、BD-J Object情報を、実際のBD-ROM上のタイトル番号、プレイリスト番号と一致するように変換する。このように変換処理を行うことにより、ステップＳ５とステップＳ６は、ステップＳ２の処理と関係なく、並列的に処理を行うことが可能になっている。
ステップS８にて、ＪＡＶＡ（登録商標）プログラムビルド部４４は、ステップS６で出力されたソースコードをコンパイルすることで、ＪＡＶＡ（登録商標）プログラムのビルドを行う。【０１６４】
ステップS９において静止画エンコーダ４２は、BD-ROMシナリオデータに含まれる静止画、をBD-ROMに準拠したMPEG2、MPEG4-AVC、VC1のいずれかの形式に変換する。BD-ROMシナリオデータが、静止画の保管場所を含んでいる場合、該当する保管場所から静止画データを読み出して、かかる形式変換を行う。
ステップS１０において、マルチプレクサ４５は、BD-ROMシナリオデータに従って、複数のエレメンタリーストリームの多重化を行い、MPEG2-TS形式のAVClipを作成する。【０１６５】
ステップS１１において、データベース生成部４３は、BD-ROMシナリオデータに従って、BD-ROMに準拠したデータベース情報を作成する。
ステップＳ１２において、フォーマット部４６は、ステップＳ８で作成されたＪＡＶＡ（登録商標）プログラム、ステップＳ１０で作成されたAVClip、ステップＳ１１で作成されたデータベース情報を入力とし、BD-ROMに準拠したフォーマットでファイルの配置を行う。ステップＳ１３においてフォーマット部４６は、ＪＡＶＡ（登録商標）プログラムとAVClipの関連付けを行い、ファイル関連情報を作成する。【０１６６】
ステップS１４にて、ディスクイメージ作成部４７は、ファイル関連情報を利用しながら、ステップＳ１１によって作成されたファイル群を、BD-ROMフォーマットに適合したボリュームイメージに変換する。
ステップS１５にて、検証部装置５０は、ステップS１３にて作成されたディスクイメージの検証を行う。もしエラーが発生した場合は、然るべき前工程に戻って作業のやり直しを行う。【０１６７】
以上が本実施の形態に係る記録方法の処理手順の説明である。
次に、動画メニューを持つシナリオデータの作成手順を、図面を参照しながら説明する。
図４５は、シームレス動画メニューの構成を持つシナリオデータの作成の手順を記したものである。この手順について説明する。【０１６８】
ステップS１０１にて、オーサリングスタッフはメニュー編集部１２とGUIを利用し、図２９に示したようなGUIを用いてメニューの画面構成を設定する。
ステップS１０２にて、オーサリングスタッフはメニューを構成する背景動画の内容を、動画プロパティペイン２５０２を用いて設定する。
ステップS１０３にて、AVClip接続情報におけるPrev項目、Next項目を設定することで、1つの背景動画をシームレスに再生させる旨を設定する。ステップS１０４において、AVClip接続情報に基づき、シームレス動画メニューのためのPlayList情報を作成する。【０１６９】
以上のように本実施形態によれば、動画メニュー用AVClipが記録されたBD-ROMを、記録装置を用いて作成することができるので、動画メニューにより操作性を高めた映画作品を、迅速かつ多量に供給することが可能となる。
（第５実施形態）
第１実施形態では、BD-ROM応用層規格に準拠した再生装置ならば、どの再生装置においてもシームレスに再生されるよう、動画メニューのデータ構造を説明した。本実施形態では、第１実施形態に述べたような手順で、AVClipが生成されていない場合でも、シームレス再生を実現できるよう、再生装置の内部構成を工夫するという実施形態に関する。【０１７０】
本実施の形態における再生装置の構成を、図４６を参照しながら説明する。図４６の再生装置は、図２３で説明した再生装置２００と比べて以下の点が異なる。
つまり、デコーダ４におけるバッファ容量が変更されていて、次AVClip保持部９cが追加されており、データ解析実行部９bが、処理に示すような処理を行う。
先ず始めに、デコーダ４におけるバッファ容量について説明する。【０１７１】
デコーダ４は、規格のデコーダモデルで定義されたTransport Buffer, Multiplexed Buffer, Elementary Buffer の最大バッファサイズと比べて、それぞれ、２倍となるバッファ量を持っている。これにより、AVClipの接続地点で、ビデオストリームがTransport Buffer, Multiplexed Buffer, Elementary Buffer 内に２重に存在したとしても、それぞれ入力されたデータ量はデコーダモデルで定義されたTransport Buffer, Multiplexed Buffer, Elementary Buffer 容量以下になるため、バッファからデータがあふれて、破綻することはない。【０１７２】
次に、新規に追加された次AVClip保持部９cについて説明する。
次AVClip保持部９cは、次に再生すべきAVClipに対応するClip情報を保持する。  
以上が次AVClip保持部９cの説明である。続いて、本実施形態におけるデータ解析実行部９bの改良を説明する。
データ解析実行部９bは、一度Movie Objectを解析するときに、再生するAVClipを特定するとともに、その次に再生するAVClipについてのClip情報を取得して、次AVClip保持部９cに格納する。たとえば、図１６のデータ構成を持ったBD-ROMディスクの場合、MovieObject#1は（１）PlayPL  PlayList#1、（２）Jump MovieObject#1のコマンド構成を持つ。ここで、PlayList情報#1はAVClipを一つしか再生指示を持たないが、データ解析実行部９bは、次のコマンドを解析する。この解析により、（２）Jump MovieObject#1で実行されるMovieObject#1の中身が判明する。この解析結果に基づき、次に再生されるAVClipと再生する位置や終了する位置を特定して、次AVClip保持部９ｃに格納する。【０１７３】
以降、データ解析実行部９bは、現在再生されているAVClipのデコーダ４への入力が完了する直後から次AVClip保持部９cが保持するAVClipのデコーダ４への転送が可能なように、BD-ROMドライブ１を制御しながら再生処理を行っていく。
このようにコマンドの解釈をAVClipが再生するよりも前に行い、かつデコーダのバッファ量を規格で決められた値の２倍にすることにより、シームレスな設定がされていないBD-ROMにおいてもできるだけシームレスに再生することができるようになる。【０１７４】
(第６実施形態)
本実施形態は、IGストリームの具体的な構成を開示する実施形態である。図４７（ａ）は、IGストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。【０１７５】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ICS(Interactive Composition Segment)、PDS(Palette Difinition Segment)、ODS(Object_Definition_Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ICSは、画面構成セグメントと呼ばれ、PDS、ODS、ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。【０１７６】
以降、各機能セグメントについて説明する。
『Interactive Composition Segment(ICS)』は、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。対話的な画面構成の1つとして、本実施形態のICSは、マルチページメニューを実現するものとする。
『Object_Definition_Segment(ODS)』は、ランレングス符号化形式のグラフィクスオブジェクトである。ランレングス符号化形式のグラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すPixel Codeと、画素値の連続長とにより、画素列を表現したデータである。Pixel Codeは、8ビットの値であり、0〜255の値をとる。ランレングスデータでは、このPixel Codeによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。【０１７７】
『Palette Difinition Segment(PDS)』は、パレットデータを格納する機能セグメントである。パレットデータとは、0〜255のPixel Codeと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するPixel Codeを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。【０１７８】
『END of Display Set Segment(END)』は、機能セグメントの伝送の終わりを示す指標であり、最後のODSの直後に配置される。以上が各機能セグメントについての説明である。
図４７（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図４７（ｂ）に示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。【０１７９】
これら様々な種別の機能セグメントは、図４８のような論理構造を構築する。図４８は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にEpochを、第２段目にDisplay Setを、第３段目にDisplay Setの類型をそれぞれ示す。図４７（ａ）の第3段目に示した機能セグメントは第４段目に描かれている。
第１段目のEpochについて説明する。IGストリームにおけるEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、表示を構成するグラフィクスオブジェクトを格納しておくためのグラフィクスプレーン、非圧縮グラフィクスオブジェクトを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、シームレス再生が保障される。つまりEpochは、シームレス再生の保障が可能な再生時間軸上の一単位ということができる。グラフィックプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、シームレス再生は保証されない。【０１８０】
尚、ここでのシームレス再生とは、グラフィクスの消去及び再描画が、所定のビデオフレーム数で完遂することをいう。IGストリームの場合、このビデオフレーム数は、4,5フレームとなる。このビデオフレームをどれだけにするかは、グラフィックプレーン全体に対する固定領域の大きさの比率と、オブジェクトバッファ−グラフィックプレーン間の転送レートとによって定まる。【０１８１】
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一つの画面構成を実現するものの集合をいう。図４８における破線hk1は、第２段目のDisplay Setが、どのEpochに帰属しているかという帰属関係を示す。DS1,2,3・・・nは、第１段目のEpochを構成していることがわかる。
第３段目はDisplay Setの類型を示す。Epochの先頭に位置するDisplay Setの類型はEpoch Startである。先頭ではない Display Setの類型は『Acquisition Point』、『Normal Case』、『Epoch Continue』である。本図におけるAcquisition Point、Normal Case、Epoch Continueの順序は、一例にすぎず、どちらが先であってもよい。【０１８２】
『Epoch Start』は、新たなEpochの開始にあたるDisplay Setである。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。Epoch Startは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるDisplay Setである。Acquisition PointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。Acquisition PointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisition Pointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。【０１８３】
『Normal Case』は、”表示アップデート”という表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvは、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、ICSのみのDSv、又は、ODSのみのDSvを設けてこのDSvをNormal CaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。Normal CaseのDSは、差分にすぎないので、Normal Case単独では画面構成は行えない。【０１８４】
『Epoch Continue』とは、AVClipの境界において、Epochが連続していることを示す。1つのDSnのComposition StateがEpoch Continueに設定されていれば、たとえDSnが、その直前に位置するDSn-1と異なるAVClip上に存在していたとしても、同じEpochに属することになる。これらDSn,DSn-1は、同じEpochに帰属するので、たとえこれら2つのDS間で、AVClipの分岐が発生したとしても、グラフィックスプレーン、オブジェクトバッファのフラッシュは発生しない。  【０１８５】
図中の破線kz1は、第４段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。第４段目の機能セグメントは、図４７（ａ）に示したものと同じものなので、これら図４７（ａ）の一連の機能セグメントは、Epoch Startに帰属していることがわかる。Acquisition Pointに帰属する機能セグメントは、Epoch Startに帰属するものと同じであり、Normal Caseに帰属する機能セグメントは、Epoch Startに帰属するものの一部を省略したものである。【０１８６】
以上が機能セグメントにより構成される論理構造についての説明である。続いてこれらICS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplay Setから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。Display Set内のICS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このICS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplay Setの割り当てである。【０１８７】
Epochに属するDisplay Setのうち、任意のDisplay SetをDSnとすると、DSnは、図４９に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。
図４９は、DSnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてDSnの始期は、DSnに属するICSのDTS値(DTS(DSn[ICS]))により示されており、終期は、DSnに属するICSのPTS値(PTS(DSn[ICS]))により示されている。そしてDSnにおいて最初の表示が行われるタイミングは、ICSのPTS値(PTS(DSn[ICS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(DSn[ICS])とを一致させれば、DSnの最初の表示は、そのビデオストリームと同期することになる。【０１８８】
PTS(DSn[ICS])は、DTS(DSn[ICS])に、ODSのデコードに要する期間(DECODEDURATION)と、デコードにより得られたグラフィクスオブジェクトの転送に要する期間(TRANSFERDURATION)とを足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。図４９の期間mc1は、DSnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。【０１８９】
以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
本実施形態は、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための新規な構成は、ICS内のInteractive_compositionに存在する。以降ICS、Interactive_compositionの内部構成について以下説明する。【０１９０】
図５０（ａ）（ｂ）は、ICSとInteractive_compositionとの対応関係を示す図である。ICSとInteractive_compositionとの対応関係には、図５０（ａ）に示すような1対1のものと、図５０（ｂ）に示すような1対多のものとがある。
対応関係が1対1になるのは、Interactive_compositionのサイズが小さく、1つのICS内にInteractive_compositionが収まる場合である。【０１９１】
1対多の対応関係になるのは、Interactive_compositionのサイズが大きく、Interactive_compositionがフラグメント化され、複数ICSに格納される場合である。複数ICSへの格納が可能なので、Interactive_compositionサイズには制限がなく、512Kバイトであろうと、1Mバイトであろうと、Interactive_compositionのサイズを大きくすることができる。ICS、Interactive_compositionには1対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ICS、Interactive_compositionの対応関係は、1対1であるとする。【０１９２】
図５１は、ICSの内部構成を示す図である。ICSには、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部が格納されている。図５１の左側に示すように、ICSは、自身がICSであることを示す『segment_descriptor』と、本ICSが想定している縦横の画素数、フレームレートを示す『video_descriptor』と、本ICSが属するDisplay Setが、Normal Case、Acquisition Point、Epoch Start、Effect_Sequenceの何れであるかを示すcomposition_stateと、画面合成の回数を示すComposition_Stateとを含む『composition_descriptor』と、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部である『Interactive_composition_data_fragment』とからなる。【０１９３】
図５１の矢印cu1は、Interactive_compositionの内部構成をクローズアップしている。この矢印に示すようにInteractive_compositionは、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報(1)(2)・・・(i)・・・(number_of_page-1)』を含む。
図５２は、1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。この図５２の右側に示すようにPage情報(y)は、
i)Page(y)を一意に識別する『page_id』、
ii)Page情報(y)により運搬されるデータ構造の中身にあたる,『in_effect』,『out_effect』,『animation_frame_rate_code』,『default_selected_button_id_ref』、『default_activated_button_id_ref』,『pallet_id_ref』,『ボタン情報(1)(2)・・・・・(number_of_buttons-1)』、
iii)Page情報(y)の中身のバージョンを示す『Page_Version_Number』
から構成される。
先ず初めに、Page情報(y)により運搬されるデータ構造を構成する各フィールドについて説明する。【０１９４】
『in_effect』は、Page(y)の表示開始時あたって再生すべき表示効果を示す。  『out_effect』は、Page(y)の表示終了時あたって再生すべき表示効果を示す。
『animation_frame_rate_code』は、Page(y)にアニメーション表示を適用する際、適用すべきフレームレートを記述する。
『default_selected_button_id_ref』は、Page(y)の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”OxFF”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ(Player Status Register(PSR))の設定値が優先的に解釈され、PSRに示されるボタンがセレクテッド状態になる。本フィールドが0xFFでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『default_selected_button_id_ref』に規定されたボタン番号でPSRを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。【０１９５】
『default_activated_button_id_ref』は、selection_time_out_ptsに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。default_activated_button_id_refが”FF”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このdefault_activated_button_id_refが00であれば、自動選択はなされない。00,FF以外の値であれば本フィールドは、有効なボタン番号として解釈される。【０１９６】
『pallet_id_ref』は、Page(y)において、CLUT部に設定すべきパレットのidを示す。
『ボタン情報(Button_info)』は、Page(y)上に表示される各ボタンを定義する情報である。以上のフィールドにより、マルチページメニューにおける個々のページの中身は特定される。
『Page_Version_Number』は、EpochにおいてPage情報(y)のデータ構造により運搬される中身のバージョンを示すフィールドである。このPage_Version_Numberは本願の主眼となるものであるので、このPage_Version_Numberについて詳しく説明する。ページ情報(y)のバージョンとは、ページ情報で運搬されるデータ構造の中身が、何回目のアップデートを経たものであるかを示す。Page情報(y)のデータ構造において、Page_Version_Number直後のフィールドのうち、どれかの値が変化した場合、又は、Page_Version_Number直後の各フィールドに何等かの変化があった場合、Page情報(y)は、アップデートされたとみなされる。【０１９７】
図５３は、Page情報(y)におけるボタン情報(i)の内部構成を示す図である。
『button_id』は、ボタン(i)を、Interactive_compositionにおいて一意に識別する数値である。
『button_numeric_select_value』は、ボタン(i)の数値選択を許可するか否かを示すフラグである。【０１９８】
『auto_action_flag』は、ボタン(i)を自動的にアクティブ状態にするかどうかを示す。auto_action_flagがオン(ビット値1)に設定されれば、ボタン(i)は、セレクテッド状態になる代わりにアクティブ状態になる。auto_action_flagがオフ(ビット値0)に設定されれば、ボタン(i)は、選択されたとしてもセレクテッド状態になるにすぎない。
『button_horizontal_position』、『button_vertical_position』は、対話画面におけるボタン(i)の左上画素の水平位置、垂直位置を示す。【０１９９】
『neighbor_info』は、ボタン(i)がセレクテッド状態になっていて、上下左右方向へのフォーカス移動が命じられた場合、どのボタンをセレクテッド状態に設定するかを示す情報であり、『upper_button_id_ref』,『lower_button_id_ref』,『left_button_id_ref』,『right_button_id_ref』からなる。
『upper_button_id_ref』は、ボタン(i)がセレクテッド状態である場合においてリモコンが操作され、上方向へのフォーカス移動を命じるキー(MOVEUPキー)が押下された場合、ボタン(i)の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、MOVEUPキーの押下は無視される。【０２００】
『lower_button_id_ref』,『left_button_id_ref』,『right_button_id_ref』は、ボタン(i)がセレクテッド状態である場合において、リモコンが操作され、下方向へのフォーカス移動を命じるキー(MOVE Downキー),左方向へのフォーカス移動を命じるキー(MOVE Left キー),右方向へのフォーカス移動を命じるキー(MOVE Right キー)が押下された場合、ボタン(i)の押下の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、これらのキーの押下は無視される。【０２０１】
『normal_state_info』は、ボタン(i)のノーマル状態を規定する情報であり、『normal_start_object_id_ref』、『normal_end_object_id_ref』、『normal_repeated_flag』を含む。
『normal_start_object_id_ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのnormal_start_object_id_refに記述される。【０２０２】
『normal_end_object_id_ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのnormal_end_object_id_refに記述される。このactivated_end_object_id_refに示されるIDが、normal_start_object_id_refに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタン(i)の絵柄になる。【０２０３】
『normal_repeat_flag』は、ノーマル状態にあるボタン(i)のアニメーション表示を反復継続させるかどうかを示す。
『selected_state_info』は、ボタン(i)のセレクテッド状態を規定する情報であり、 『selected_state_sound_id_ref』、『selected_start_object_id_ref』、『selected_end_object_id_ref』、『selected_repeat_flag』を含む。
『selected_state_sound_id_ref』は、ボタン(i)の状態がセレクテッド状態が変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvと呼ばれるファイルに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。【０２０４】
『selected_start_object_id_ref』は、セレクテッド状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのselected_start_object_id_refに記述される。
『selected_end_object_id_ref』は、セレクト状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのselected_end_object_id_refに記述される。このselected_end_object_id_refに示されるIDが、selected_start_object_id_refに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタン(i)の絵柄になる。【０２０５】
『selected_repeat_flag』は、セレクテッド状態にあるボタン(i)のアニメーション表示を、反復継続するかどうかを示す。selected_start_object_id_refと、selected_end_object_id_refとが同じ値になるなら、本フィールド00に設定される。
『activated_state_info』は、ボタン(i)のアクティブ状態を規定する情報であり、 『activated_state_sound_id_ref』、『activated_start_object_id_ref』、『activated_end_object_id_ref』を含む。【０２０６】
『activated_state_sound_id_ref』は、button情報に対応するボタンのセレクテッド状態が変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。【０２０７】
『activated_start_object_id_ref』は、アクティブ状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのactivated_start_object_id_refに記述される。
『activated_end_object_id_ref』は、アクティブ状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのactivated_end_object_id_refに記述される。【０２０８】
『ナビゲーションコマンド(navigation_command)』は、ボタン(i)がアクティブ状態になれば、実行されるコマンドである。かかるコマンドは、Movie Objectに記述されているナビゲーションコマンドと同じものなので、あるボタンの確定時に、再生装置に実行させたいナビゲーションコマンドを、このボタン情報に記述しておけば、対応するボタンの確定時において、再生装置に所望の制御を行わせることができる。ボタン情報内のナビゲーションコマンドは、Movie Object同様、再生装置に操作待ち制御を行わせるものなので、本発明にかかるプログラム、つまり、メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムは、Movie Objectに記述されたナビゲーションコマンドと、ボタン情報に記述されたナビゲーションコマンドとから構成される。第１実施形態に示した具体例を作成する場合、メニューには、Title#1の選択を受け付けるボタン、Title#2の選択を受け付けるボタンが表示されるので、これらのTitle#1選択ボタンに対応するボタン情報のナビゲーションコマンドに、Title#1へのジャンプを命じるようなナビゲーションコマンドを記述し、Title#2選択ボタンに対応するボタン情報のナビゲーションコマンドに、Title#2へのジャンプを命じるようなナビゲーションコマンドを記述すれば、かかるTitle#1選択ボタン、Title#2選択ボタンの状態変化に応じて、Title#1、Title#2の再生が開始される。【０２０９】
またボタン情報特有のナビゲーションコマンドとして、SetButtonPageコマンドがある。SetButtonPageコマンドは、マルチページメニューの所望のページを表示させ、そのページにおける所望のボタンをセレクテッド状態に設定させることを再生装置に命じるコマンドである。かかるナビゲーションコマンドを用いることにより、オーサリング担当者は、ページ切り換えを簡易に記述することができる。【０２１０】
以上のように構成されたIGストリームが、図２３に示したIGデコーダ６の構成要素により、どのように処理されるかを、図５４を参照しながら説明する。
Coded Data Buffer６bには、ICS、PDS、ODSがDTS、PTSと共に一時的に格納される。
Stream Graphics Processor６cは、ODSをデコードして、デコードにより得られた非圧縮グラフィクスをObject Buffer６dに書き込む。【０２１１】
Object Buffer６dは、Stream Graphics Processor６cのデコードにより得られた非圧縮のグラフィクスオブジェクト(図中の四角枠)が多数配置されるバッファである。このObject Buffer６dにおいて各グラフィクスオブジェクトが占める矩形領域は、Object_idにより識別される。従って、Object Buffer６d上にあるグラフィクスオブジェクトが存在している状態で、同じObject_idをもつグラフィクスオブジェクトが許可要求されれば、Object Buffer６d上においてそのグラフィクスオブジェクトが占める領域は、同じObject_idをもつグラフィクスオブジェクトにより上書きされることになる。【０２１２】
Compositionバッファ６eは、1つ以上のICSに対応する運搬されるInteractive_compositionを格納しておくためのバッファである。格納されているInteractive_compositionは、Graphicsコントローラ６fによる解読に供される。
Graphicsコントローラ６fは、現在の再生時点が新たなDisplay Setに到達する度に、そのDisplay Setに含まれるICSのComposition_Stateが、Epoch Start、Acquisition Point、Normal Caseのどれであるかを判定する、Epoch Startであれば、Coded Dataバッファ６b上の新たなInteractive_compositionを、Coded Dataバッファ６bからCompositionバッファ６eに転送する。【０２１３】
Graphicsコントローラ６fは、Acquisition PointタイプのDisplay SetにおけるICSがCoded Dataバッファ６bに読み出される度に、そのICSに属する各ページ情報のPage_Version_Numberと、Compositionバッファ６eに格納済みのInteractive_compositionにおける各ページ情報のPage_Version_Numberとを照合する。そしてPage_Version_Numberが大きいページ情報がCoded Dataバッファ６b上に存在していれば、そのページ情報をCoded Dataバッファ６bからCompositionバッファ６eに転送することで、Compositionバッファ６eにおける所望のページ情報をアップデートする。そしてそうやってアップデートされたページ情報に該当するページが現在表示中であるか否かを判定し、もし表示中であれば、該当するページの再描画を行う。図中の◎1,2,3,4は、Coded Dataバッファ６bに読み出されたInteractive_compositionにおけるPage_Version_Number参照(◎1)、Page_Version_Numberが高いページ情報の転送(◎2)、アップデートされたページ情報の参照(◎3)、アップデートされたページ情報に基づく再描画(◎4)を模式化している。更に図中の矢印bg1,2,3,4は、Graphics Controller６fによる再描画を象徴的に示している。かかる描画により、ボタン0-A〜ボタン0-Dが配されたページがInteractive Graphicsプレーン１０に現れ、動画に合成されることになる。【０２１４】
Epochは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら1つのAVClip内でEpochは完結していなければならない。しかし第１実施形態で述べたような動画メニューを構成する場合、複数のPlayItem情報にて、メニューを続けて表示させる必要があるので、複数のPlayItem情報間で、連続するようなEpochを定義することが必要になる。ここで、2つのAVClipが順次再生される場合であって、所定の3つの条件が満たされるような場合、2つのAVClip間で連続性をもつようなEpochを定義することができる。【０２１５】
図５５（ａ）は、2つのAVClip間で連続性をもつようなEpochを示す図である。本図における第1段目は、previous PlayItemから再生されるAVClipと、Current PlayItemから再生されるAVClipとを示し、第2段目は、2つのAVClip間で連続性をもつEpochを示す。第3段目は、第2段目のEpochに属するDisplay Setを示す。第2段目におけるEpochは、AVClipにより分断されない。しかし第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplay Setに分断されている。本図において注目すべきは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型が、”Epoch Continueタイプ”になっていることである。【０２１６】
“Epoch Continue”とは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型であり、所定の3つの条件が満たされる場合、Acquisition Pointとして取り扱われる。この3つの条件のうち、1つでも欠落があれば、Epoch Startとして取り扱われる。
図５５（ｂ）は、Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。本図に示すように、Epoch ContinueタイプのDisplay Setは、Current PlayItemから再生されるAVClipからの飛び込み再生が行われる場合、”Epoch Start”として取り扱われ、previous PlayItemから再生されるAVClipから連続再生が行われる場合、”Acquisition Point”として取り扱われることがわかる。【０２１７】
図５６は、2つのAVClip間で連続性をもつための3つの条件を示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、Epochを示す。このEpochが、2つのAVClip間でメモリ管理の連続性をもつEpochである。第3段目は、第２段目におけるEpochのそれぞれに属するDisplay Setを示す。第2段目におけるEpochは、AVClipにより分断されることはなかったが、第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplay Setに分断されている。第4段目は、各Display Setに属する機能セグメントを示す。この第4段目における機能セグメント群は、図５の第4段目に示したものと同じである。図中の◎1,◎2,◎3が、2つのAVClip間で連続性をもつようなEpochの成立条件を示す。1つ目の条件は、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型が、第3段目に示すようにEpoch Continueになっていることである。【０２１８】
2つ目の条件は、DSm+1に属するICSの全ての位置情報におけるComposition Numberが、1つ前のDSmに属するICSの全ての位置情報におけるComposition Number(=A)と同じであること、つまりグラフィクス表示の内容が、AVClip境界の前後で同じであることを意味する。Composition Numberは、Display Setによる画面構成を意味するものである。このComposition Numberが同じであるということは、画面構成で得られるグラフィクスの内容が、DSmと、DSm+1とで同じであることを意味する。【０２１９】
3つ目の条件は、previous PlayItemによるAVClipの再生と、Current PlayItemによるAVClipの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
(i)ビデオ属性情報に示されているビデオストリームの表示方式（NTSC、PAL等）が、2つのAVClip間で同一である。【０２２０】
(ii)オーディオ属性情報に示されているオーディオストリームのエンコード方式（AC-3、MPEG、LPCM等）が、2つのAVClip間で同一である。
以上の(i)〜(ii)においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。【０２２１】
例えば、連続して再生すべき2つのオーディオストリームにおいて、一方の符号化方式がAC-3方式であり、他方がMPEG規格である場合、ストリームがAC-3からMPEGへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
これら(i)〜(ii)の関係が全て満たされた場合のみ、シームレス接続がなされる。(i)〜(ii)の関係のうち、１つでも満たされない場合、シームレス接続はなされない。【０２２２】
かかる3つの条件が満たされれば、Epoch ContinueタイプのDSm+1はAcquisition Pointとして取り扱われることになる。つまりDisplay Set1〜m、Display Setm+1〜n間は1つのEpochを形成することになり、2つのAVClipの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
仮にDSm+1の類型がEpoch Continueであったとしても、残り2つの条件のうち、1つの欠落があれば、Epochは、AVClipの境界前後で2つに分断されることになる。以上のことからEpoch ContinueタイプのDisplay Setは、上述したように3つの条件が全て満たされた場合にAcquisition Pointとして扱われる。1つの条件が欠けた場合は、Epoch Startとして取り扱われることになる。【０２２３】
以上のように本実施形態によれば、PlayList情報において、2つ目以降に存在するPlayItem情報のComposition Typeを、Epoch Continueに設定し、Composition Numberを、先頭のPlayItem情報のComposition Numberと同一に設定することで、PlayItem情報の切り替わりにおいて、メニューの表示が一旦消えることを避けることができる。
(第７実施形態)
本実施形態は、PGストリームの具体的な構成を開示する実施形態である。図５７は、PGストリームの具体的な構成を示す図である。本図の第４段目は、PGストリームを示す。第３段目に、当該PGストリームが属するDisplay Setの類型を示し、第２段目にDisplay Setを、第１段目にEpochをそれぞれ示す。【０２２４】
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線kz1は、第３段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PGストリームを構成する機能セグメントのうち、PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。【０２２５】
ここで、PGストリームにおけるEpochの概念について説明する。第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図５８は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当に」「ごめん」「あれから」「3年がたった」のうち、2つの字幕「本当に」「ごめん」は画面の下側に、「あれから」「3年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplay Setについて説明する。【０２２６】
図５７における破線hk1,2は、第２段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。Epoch Start,Acquisition Point,Normal Caseという一連のDSは、第１段目のEpochを構成していることがわかる。『Epoch Start』、『Acquisition Point』、『Normal Case』は、DSの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。【０２２７】
続いてPGストリームを構成する機能セグメントのうち、特徴的なものについて説明する。ここで、PGストリーム内に存在する機能セグメントのうち、WDS,PCSは、PGストリーム特有の構成である。先ず始めに、WDS(window_definition_segment)について説明する。
『window_definition_segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”window”と呼ばれ、このWDSで定義される。図５９（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window_horizontal_position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window_vertical_position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window_width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。【０２２８】
window_horizontal_position、window_vertical_position、window_width、window_heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦:video_height、横:video_widthという二次元状の大きさをもつ。
window_horizontal_positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、1〜video_widthの値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので1〜video_heightの値をとる。【０２２９】
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、1〜video_width-window_horizontal_positionの値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので1〜video_height-window_vertical_positionの値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。【０２３０】
続いてPCSについて説明する。
PCSは、字幕等の画面を構成する機能セグメントである。PCSは、図５９（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id』と、『composition_object(1)〜(m)』とから構成される。【０２３１】
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、Epoch Startであるかを示す。【０２３２】
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のDisplay Setから、パレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされる場合、本フィールドは”1”に設定される。【０２３３】
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図５９（ｂ）の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id_ref』、『window_id_ref』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。【０２３４】
『object_id_ref』は、グラフィクスオブジェクト識別子(object_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window_id_ref』は、ウィンドゥ識別子(window_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。【０２３５】
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。【０２３６】
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_position』、『object_cropping_width』、『object_cropping_height』からなる。【０２３７】
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。【０２３８】
『object_cropping_width』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
Epochに属するDisplay Setのうち、任意のDisplay SetをDSnとすると、DSnは、図６０に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。図６０は、DSnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてDSnの始期は、DSnに属するPCSのDTS値(DTS(DSn[PCS]))により示されており、終期は、DSnに属するPCSのPTS値(PTS(DSn[PCS]))により示されている。そしてDSnにおいて最初の表示が行われるタイミングも、PCSのPTS値(PTS(DSn[PCS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(DSn[PCS])とを一致させれば、DSnの最初の表示は、そのビデオストリームと同期することになる。【０２３９】
PTS(DSn[PCS])は、DTS(DSn[PCS])に、ODSのデコードに要する期間(DECODEDURATION)を足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。本図の期間mc1は、DSnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。【０２４０】
以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
Epochは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら1つのAVClip内でEpochは完結していなければならない。しかし2つのAVClipが順次再生される場合であって、所定の3つの条件が満たされるような場合、2つのAVClip間で連続性をもつようなEpochを定義することができる。【０２４１】
”Epoch Continue”とは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型であり、第６実施形態で示した所定の3つの条件が満たされる場合、Acquisition Pointとして取り扱われる。この3つの条件のうち、1つでも欠落があれば、Epoch Startとして取り扱われる。つまりEpoch ContinueタイプのDisplay Setは、後続AVClipからの飛び込み再生が行われる場合、”Epoch Start”として取り扱われ、先行AVClipから連続再生が行われる場合、”Acquisition Point”として取り扱われることがわかる。【０２４２】
図６１は、2つのAVClip間で連続性をもつための3つの条件を示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、3つのEpochを示す。この3つのEpochのうち、真ん中のEpochが、2つのAVClip間でメモリ管理の連続性をもつEpochである。第3段目は、3つのEpochのそれぞれに属するDisplay Setを示す。第2段目におけるEpochは、AVClipにより分断されることはなかったが、第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplay Setに分断されている。第4段目は、各Display Setに属する機能セグメントを示す。この第4段目における機能セグメント群は、図５７の第4段目に示したものと同じである。図中の◎1,◎2,◎3が、2つのAVClip間で連続性をもつようなEpochの成立条件を示す。1つ目の条件は、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型が、第3段目に示すようにEpoch Continueになっていることである。【０２４３】
2つ目の条件は、DSm+1に属するPCSのComposition Numberが、1つ前のDSmに属するPCSのComposition Number(=A)と同じであること、つまりグラフィクス表示の内容が、AVClip境界の前後で同じであることを意味する。Composition Numberは、Display Setによる画面構成を意味するものである。このComposition Numberが同じであるということは、画面構成で得られるグラフィクスの内容が、DSmと、DSm+1とで同じであることを意味する。図１５は、DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。本図に示すように、DSmによるグラフィクスの内容は『3年たった』であり、DSm+1によるグラフィクスの内容は『3年たった』であるので、2つのDisplay Set間でグラフィクスの内容は同じであり、Composition Numberが同一値になっていることがわかる。また、ビデオストリームの再生もシームレス接続になされているので、DSm+1はAcquisition Pointとして取り扱われることがわかる。【０２４４】
3つ目の条件は、先行AVClIPの再生と、後続AVClIPの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
(i)ビデオ属性情報に示されているビデオストリームの表示方式（NTSC、PAL等）が、2つのAVClip間で同一である。【０２４５】
(ii)オーディオ属性情報に示されているオーディオストリームのエンコード方式（AC-3、MPEG、LPCM等）が、2つのAVClip間で同一である。
以上の(i)〜(ii)においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。【０２４６】
例えば、連続して再生すべき2つのオーディオストリームにおいて、一方の符号化方式がAC-3方式であり、他方がMPEG規格である場合、ストリームがAC-3からMPEGへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
これら(i)〜(ii)の関係が全て満たされた場合のみ、シームレス接続がなされる。(i)〜(ii)の関係のうち、１つでも満たされない場合、シームレス接続はなされない。【０２４７】
かかる3つの条件が満たされれば、Epoch ContinueタイプのDSm+1はAcquisition Pointとして取り扱われることになる。つまりDisplay Set1〜m、Display Setm+1〜n間は1つのEpochを形成することになり、2つのAVClipの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
仮にDSm+1の類型がEpoch Continueであったとしても、残り2つの条件のうち、1つの欠落があれば、Epochは、AVClipの境界前後で2つに分断されることになる。以上のことからEpoch ContinueタイプのDisplay Setは、上述したように3つの条件が全て満たされた場合にAcquisition Pointとして扱われる。1つの条件が欠けた場合は、Epoch Startとして取り扱われることになる。【０２４８】
以上のように本実施形態によれば、PlayList情報において、2つ目以降に存在するPlayItem情報内に属するPGストリームのComposition Typeを、Epoch Continueに設定し、Composition Numberを、先頭のPlayItem情報のComposition Numberと同一に設定することで、PlayItem情報の切り替わりにおいて、字幕の表示が一旦消えることを避けることができる。
＜備考＞
上記実施形態に基づいて説明してきたが、現在において最善の効果が期待できるシステム例として提示したに過ぎない。本発明はその要旨を逸脱しない範囲で変更実施することができる。代表的な変更実施の形態として、以下のものがある。
(BD-Jアプリケーションによる操作待ち制御)
動画メニューにおける操作待ち制御が、Movie Objectによりなされる場合、メニューに対する制御が、これまでに述べたようなICSにより実現される。一方、操作待ち制御が、BD-Jアプリケーションによりなされる場合、メニューに対する制御に、ICSは用いられない。何故なら、上述したように、BD-Jアプリケーションは、HAViに基づき、GUIフレームワークを描画することができるからである。しかし、かかる場合であっても、動画メニューにおいて背景画として、AVClipを用いることには変りない。よって、BD-Jアプリケーションにて操作待ち制御を実現する場合であっても、999個のPlayItem情報を有するPlayList情報を利用することで、AV画面の途切れのない操作待ち制御を実現することができる。
(PlayItem情報の個数)
第１実施形態において、PlayItem情報の個数を999個にしたのは、BD-ROM規格に基づくものであり、識別番号に割り当てられている桁数に制限があることと、PlayList情報をオンメモリで使用したいとの要請による。しかし、このような制限が存在しない規格上で、動画メニューを作成する場合や、より大きなPlayList情報が認められているような規格上で、動画メニューを作成する場合、逆に、桁数やメモリ規模が厳しく制限されている応用層規格上で動画メニューを作成する場合、PlayItem情報の個数を増減させてよいことはいうまでもない。
（記録媒体のバリエーション）
各実施形態では、AVコンテンツやアプリケーションを記録する記録媒体やオーサリングの対象をBD-ROMとして説明を進めたが、このBD-ROMの物理的性質は、本発明の作用・効果の発揮にさほど貢献していない。BD-ROM同様、AVコンテンツを記録し得る容量を持った記録媒体であるなら、他の記録媒体を採用してもよい。例えば、BD-ROM以外のCD-ROM、CD-R、CD-RW，DVD-ROM、DVD-R、DVD-RW、DVD-RAM、DVD+R、DVD+RW等の他の光ディスクであってよいことはいうまでもない。また、PD、MO等の光磁気ディスクであってもよい。更に、SDメモリカード、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリーカードであってもよい。HDD、フレキシブルディスク、SuperBD-ROM、Zip、Click！等の磁気記録ディスク、ORB、Jaz、SparQ、SyJet、EZFley、マイクロドライブ等のリムーバブルハードディスクドライブであってもよい。無論、ローカルストレージは、再生装置に装填され、所定の著作権保護がなされた記録媒体であるならば、上述したような記録媒体の何れでもよい。【０２４９】
(他の規格への発展)
本実施の形態はBD-ROMを例に挙げたが、AVClipの再生を行う同等のビデオ規格であれば、適応可能であることは明白である。
(第２実施形態における動画メニューの作成法)
第２実施形態の動画メニューを作成する場合、PlayList生成部１４は、PlayList情報内の奇数番目のPlayItem情報が、AVClip#1の再生を、再生装置に命じることで、当該AVClip#1の再生を繰り返す旨を示し、偶数番目のPlayItem情報が、AVClip#2の再生を、再生装置に命じることで、当該AVClip#2の再生を繰り返す旨を示すよう、PlayList情報を生成する。
(システムLSI化)
第１実施形態に示した再生装置の内部構成は、1つのシステムLSIとして構成してもよい。
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。【０２５０】
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。【０２５１】
かかるシステムLSIは、再生装置は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。
具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。【０２５２】
そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。【０２５３】
各実施形態の内部構成のうち、一般的な部分については、既存の回路パターンを定義したIntellectual Propertyを組み合わせて設計するのが望ましい。特徴的な部分については、HDLを用いた抽象度が高い動作レベルを記述やレジスタトランスファレベルでの記述を用いてトップダウン設計を行うのが望ましい。  
回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。【０２５４】
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。【０２５５】
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUT(Look Up Table)に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込むませる必要がある。更に、デコーダを内蔵した映像復調回路は、積和演算機能を内蔵したDSPで実現するのが望ましい。
(アーキテクチャ)
本発明にかかるシステムLSIは、再生装置の機能を実現するものなので、システムLSIは、Uniphierアーキテクチャに準拠させるのが望ましい。【０２５６】
Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。
・データ並列プロセッサDPP
これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。
・命令並列プロセッサIPP
これは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなる「Local Memory Contoroller」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「Processing Unit部」、複数アプリケーションの並列実行をProcessing Unit部に行わせる「Virtual Multi Processor Unit部」で構成される。【０２５７】
・CPUブロック
これは、ARMコア、外部バスインターフェイス(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(General Purpose Input Output)、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。先に述べたコントローラは、このCPUブロックとしてシステムLSIに実装される。【０２５８】
・ストリームI/Oブロック
これは、USBインターフェイスやATA Packetインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。
・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。【０２５９】
・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。
(本発明に係るプログラムの生産形態)
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、ＪＡＶＡ（登録商標）バイトコードというように、様々な種類がある。【０２６０】
本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。【０２６１】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
【産業上の利用可能性】
【０２６２】
本発明に係る情報記録媒体は、動画メニューにおいて、動画再生が静止したり、ボタンが消えることを、できるだけ回避することができ、コンテンツメーカーの意図通りに高度なBD-ROM作品をより多く市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図１】
2007119765.tif 000003
【図２】
2007119765.tif 000004
【図３】
2007119765.tif 000005
【図４】
2007119765.tif 000006
【図５】
2007119765.tif 000007
【図６】
2007119765.tif 000008
【図７】
2007119765.tif 000009
【図８】
2007119765.tif 000010
【図９】
2007119765.tif 000011
【図１０】
2007119765.tif 000012
【図１１】
2007119765.tif 000013
【図１２】
2007119765.tif 000014
【図１３】
2007119765.tif 000015
【図１４】
2007119765.tif 000016
【図１５】
2007119765.tif 000017
【図１６】
2007119765.tif 000018
【図１７】
2007119765.tif 000019
【図１８】
2007119765.tif 000020
【図１９】
2007119765.tif 000021
【図２０】
2007119765.tif 000022
【図２１】
2007119765.tif 000023
【図２２】
2007119765.tif 000024
【図２３】
2007119765.tif 000025
【図２４】
2007119765.tif 000026
【図２５】
2007119765.tif 000027
【図２６】
2007119765.tif 000028
【図２７】
2007119765.tif 000029
【図２８】
2007119765.tif 000030
【図２９】
2007119765.tif 000031
【図３０】
2007119765.tif 000032
【図３１】
2007119765.tif 000033
【図３２】
2007119765.tif 000034
【図３３】
2007119765.tif 000035
【図３４】
2007119765.tif 000036
【図３５】
2007119765.tif 000037
【図３６】
2007119765.tif 000038
【図３７】
2007119765.tif 000039
【図３８】
2007119765.tif 000040
【図３９】
2007119765.tif 000041
【図４０】
2007119765.tif 000042
【図４１】
2007119765.tif 000043
【図４２】
2007119765.tif 000044
【図４３】
2007119765.tif 000045
【図４４】
2007119765.tif 000046
【図４５】
2007119765.tif 000047
【図４６】
2007119765.tif 000048
【図４７】
2007119765.tif 000049
【図４８】
2007119765.tif 000050
【図４９】
2007119765.tif 000051
【図５０】
2007119765.tif 000052
【図５１】
2007119765.tif 000053
【図５２】
2007119765.tif 000054
【図５３】
2007119765.tif 000055
【図５４】
2007119765.tif 000056
【図５５】
2007119765.tif 000057
【図５６】
2007119765.tif 000058
【図５７】
2007119765.tif 000059
【図５８】
2007119765.tif 000060
【図５９】
2007119765.tif 000061
【図６０】
2007119765.tif 000062
【図６１】
2007119765.tif 000063
【手続補正書】
【提出日】平成20年10月1日(2008.10.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
動画像を背景画としたメニュー表示を、再生装置に行わせる記録媒体であって、
動画像を構成するAVストリームと、
メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムと、
プレイリスト情報とが記録されており、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、プレイアイテムシーケンスは、各々のプレイアイテム情報が、1つのAVストリームに対応していて、メニュー表示を介した操作待ちの制御がなされている間、当該AVストリームの再生を繰り返す旨を、再生装置に指示する
ことを特徴とする記録媒体。
【請求項２】
前記プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
前記ユーザ操作待ちの制御は、
前記再生コマンドの実行を、再生装置に反復させることでなされる
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
各々のプレイアイテム情報は接続情報を有しており、当該接続情報は、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行うべき旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項４】
前記AVストリームの先端部分の割当符号量は、同じAVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファの容量以下に定められている
ことを特徴とする請求項１記載の記録媒体。
【請求項５】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報は、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報は、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
動画像を背景画としたメニュー表示を実現する再生装置であって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御手段は、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とする再生装置。
【請求項８】
前記制御手段は、プログラムを構成するコマンドを実行するものであり、
前記再生手段は、
制御手段によるコマンドの実行結果に基づき、プレイリスト情報を介したAVストリームの再生を行うものであり、
操作待ち制御は、
プログラムに含まれる再生コマンドの実行を、制御手段が反復することでなされる
ことを特徴とする請求項７記載の再生行装置。
【請求項９】
前記再生手段は、装置内部の基準クロックに基づき、再生動作を行い、
1つのプレイアイテム情報がシームレス接続を意味する接続情報を有している場合、基準クロックにオフセットを加算することにより、１のプレイアイテム情報によるAVストリーム読み出し時と、直前のプレイアイテム情報によるAVストリーム読み出し時とで、基準クロックにて示されるカウント値を、連続させる
ことを特徴とする請求項７記載の再生装置。
【請求項１０】
前記再生手段は、デコーダと、当該デコーダにデータを供給するバッファとを有しており、
前記バッファの容量は、
前記AVストリームの先端部分と、AVストリームの終端部分とを同時に格納しうる容量である
ことを特徴とする請求項７記載の再生装置。
【請求項１１】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報がカレントのプレイアイテム情報として選択されている場合、前記再生手段は、第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報がカレントのプレイアイテムとして選択されている場合、第２のAVクリップの再生を繰り返す
ことを特徴とする請求項７記載の再生装置。
【請求項１２】
記録装置であって、
背景画となる動画像の指定を、ユーザから受け付ける受付手段と、
動画像の素材をエンコードすることで、指定された動画像に対応するAVストリームを得るエンコーダと、
複数のプレイアイテム情報からなるプレイアイテムシーケンスを有するプレイリスト情報を生成する第１生成手段と、
操作待ち制御を再生装置に行わせるプログラムを生成する第２生成手段とを備え、
前記第１生成手段は、
前記1つのAVストリームに対応するプレイアイテム情報を複数生成することで、プレイアイテムシーケンスを得る
ことを特徴とする記録装置。
【請求項１３】
プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
第２生成手段は、
前記再生コマンドの実行を反復させるコマンドを、プログラム内に記述することで、ユーザ操作待ちの制御を、再生装置に行わせる
ことを特徴とする請求項１２記載の記録装置。
【請求項１４】
各々のプレイアイテム情報は接続情報を有しており、
前記第１生成手段は、
プレイアイテムシーケンスの生成にあたって、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行わせる旨を、接続情報に示させる、ことを特徴とする請求項１２記載の記録装置。
【請求項１５】
前記エンコーダは、
AVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファ容量に基づき、入力制限直線を導き出して、かかる入力制限直線に基づき、AVストリームの先端部分に対する割当符号量を決定する
ことを特徴とする請求項１２記載の記録装置。
【請求項１６】
AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
前記第１生成手段は、
プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報が、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
偶数番目のプレイアイテム情報が、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示すよう、プレイリスト情報を生成する
ことを特徴とする請求項１２記載の記録装置。
【請求項１７】
AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
ことを特徴とする請求項１２記載の記録装置。
【請求項１８】
再生装置に組込まれ、動画像を背景画としたメニュー表示を再生装置に行わせるシステムLSIであって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御手段は、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とするシステムLSI。
【請求項１９】
動画像を背景画としたメニュー表示を行う再生方法であって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとを有し
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御ステップは、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
ことを特徴とする再生方法。  
【請求項２０】
動画像を背景画としたメニュー表示を、コンピュータに行わせるプログラムであって、
記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとをコンピュータに実行させ
前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
前記制御ステップは、
個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する制御を、コンピュータに行わせる
ことを特徴とするプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、対話制御技術の技術分野に属する発明である。
【背景技術】
【０００２】
対話制御技術とは、動画像にメニューを合成させ、このメニューに対するユーザ操作に応じて再生制御を実現するという技術である。本技術は、再生すべきタイトルやチャプターの選択、クイズの設問に対する回答等、ユーザ操作に対する対話機能の実現に必須の機能であり、DVDやBD-ROM等の記録媒体やその再生装置、記録装置、システムLSIといった工業製品の開発に、具体的に応用されている。
【０００３】
DVDを例に挙げれば、DVDビデオフォーマットには、その機能の一つとして、「静止画メニュー」、「動画メニュー」という機能が存在する。
静止画メニューとは、その背景に静止画が用いられるメニューである。再生装置は背景静止画を表示したまま、ハイライトや静止画で作成されたボタンを背景静止画に重畳して表示し、ユーザ操作の入力待ちを行う。
【０００４】
動画メニューとは、その背景に動画が用いられるメニューである。再生装置は背景動画を再生しながら、ハイライトや静止画で作成されたボタンを背景となる動画像に重畳して、ユーザ操作の入力待ちを行う。一般的に背景動画は１分程度の短い映像で作成されており、かかる背景動画と、これに対応するプログラムとを記録媒体に記録する。このプログラムは、２つのコマンドを含む。１つ目のコマンドは、背景動画の再生を再生装置に命じる再生コマンドである。2つ目のコマンドは、ジャンプコマンドであり、1つ目のコマンドへのジャンプを、再生装置に行わせ、再生コマンドの実行を反復させる。かかるプログラムを記述することで、短い映像データを使って、ループ再生を繰り返す動画メニューの作成が可能となる。このような動画メニューを再生装置が高速に読み込むための、ディスク配置における工夫が、以下の特許文献１に、記述されている。
【特許文献１】特開平９-６３２５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述したような動画メニューでは、再生コマンドによる動画再生が終わってから、ジャンプコマンドが実行され、動画再生が再開されるまでに、動画の静止や、メニューの消去が発生する。この間、再生の動画メニューの再生途切れが発生することは避け得ない。ここで、再生途切れが発生じないような入力待ちを実現するには、１時間というような長い時間長のストリームを、動画メニューによる入力待ちのために予め記録しておくことが考えられる。このストリームの中身は、同じ映像の繰り返しであってよい。しかし映画作品の本編とは別に、動画メニューによる入力待ちのために、１時間ものストリームを記録しようというのは、記録領域の無駄であり、容認されるものではない。
【０００６】
そのような記録効率の要請からすれば、１時間というような長い時間長のストリームを、動画メニューによる入力待ちのために予め記録しておくという考えは、現実味に欠けた考えであると、結論付けざるを得ない。
本発明の目的は、記録媒体の記録効率を、無駄に落とすことなく、動画メニューによる入力待ちを実現することができる、記録媒体を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を達成するため、本発明にかかる記録媒体は、動画像を背景画としたメニュー表示を、再生装置に行わせる記録媒体であって、動画像を構成するAVストリームと、メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムと、プレイリスト情報とが記録されており、  前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、プレイアイテムシーケンスは、各々のプレイアイテム情報が、1つのAVストリームに対応していて、メニュー表示を介した操作待ちの制御がなされている間、当該AVストリームの再生を繰り返す旨を、再生装置に指示することを特徴としている。
【発明の効果】
【０００８】
本発明にかかる記録媒体は、上述したように構成されているので、1つのプレイリスト情報内に存在する複数のプレイアイテム情報により、ストリーム再生がなされている間、再生が途切れることがない。ストリームの時間長をＴとし、プレイリスト情報内のプレイアイテム情報の個数をNとしたとすれば、N×Tという期間において、動画メニューの再生途切れがないことが保証される。
【０００９】
例えばプレイアイテム情報の最大数を999個として、1分間のデジタルストリームを用意すれば、たとえ、デジタルストリームの再生を命じるコマンドと、当該コマンドの実行を反復させるジャンプコマンドとの間では、動画像の静止やボタン、字幕の消去が発生するとしても、999個のプレイアイテム情報が再生されている間は、動画像の静止やボタン、字幕の消去が生じることはない。999分=１６.５時間ものの間、動画メニューの再生途切れが発生しないので、デジタルストリームの時間長が１分程度であっても、ジャンプコマンドを実行して、再生コマンドの実行を反復することによる再生の途切れは、１６.５時間のうち、１回となり、再生の途切れがない入力待ちを、長い時間継続することができる。
【００１０】
また、この継続には、記録媒体の容量を多く費やすることもないので、記録媒体の容量を大きく確保したまま、途切れのない動画メニューを実現したいという、現実的な要請に応えることができる。
【発明を実施するための最良の形態】
【００１１】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、BD-ROM１００である。BD-ROM１００は、再生装置３００、テレビ４００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。
【００１２】
以降、BD-ROM１００、再生装置２００、リモコン３００について説明を行う。
BD-ROM１００は、映画作品が記録された記録媒体である。
再生装置２００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。
リモコン３００は、再生装置２００に対する操作を、ユーザから受け付ける。このBD-ROM１００により供給される映画作品の具体像は以下の通りである。このBD-ROM１００には、映画作品を構成するTitle＃1、Title＃2の他に、メニューを構成するメニュータイトルが記録されている。このメニュータイトルは、動画像を背景画としたメニュー表示を、再生装置２００に行わせるものであり、かかるメニューを通じて、Title＃1、Title＃2のどちらかの選択をユーザに行わせる。以上のように、このBD-ROM１００は、Title＃1、Title＃2という2つの映画作品の本編と、動画メニューとをユーザに供給するものである。以降、特に断らない限り、本出願明細書では、かかる映画作品の具体像を、説明に使用する。
【００１３】
以上が、本発明にかかる記録媒体の使用形態である。
＜BD-ROMの概要＞
先ず始めに、本発明にかかる記録媒体が前提としているデータ構造について説明する。本発明にかかる記録媒体が前提にしているのは、BD-ROMの応用層規格のフォーマットである。図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、第２段目のファイルシステム層、第１段目の応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、第１段目の枠内に示すようなものになる。
【００１４】
BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリと呼ばれるサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls)がある。先に述べた具体像における役割分担として、00001.mplsは、動画メニューを構成するものとする。この動画メニューは、2つのタイトル(Title＃1、Title＃2)の選択をユーザから受け付けるものとする。また00002.mplsは、映画作品の本編を構成するものとする。
【００１５】
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts〜00003.m2ts)がある。これらのファイルのうち00001.m2tsは、動画メニュー用AVClipを構成するものとする。また00002.m2ts、00003.m2tsは、映画作品の本編を構成するものとする。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi〜00003.clpi)がある。
【００１６】
BDJOディレクトリには、拡張子bdjoが付与されたファイル(00001.bdjo)が存在する。
JARディレクトリには、拡張子jarが付与されたファイル(00001.jar)がある。具体的な役割分担として、これら00001,bdjo,00001.jarは、Title＃1の再生時における再生制御を担っているものとする。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
＜BD-ROMの構成その１.Index.bdmv＞
まず、Index.bdmvについて説明する。図３は、Index.bdmvの内部構成を示す図である。Index.bdmvとは、BD-ROMにおけるタイトル構成を定義する最上位層のテーブルである。図３の左側におけるIndex.bdmvは、BD-ROMディスクに格納されるFirstPlaybackについてのIndexTable Entry、TopMenuについてのIndex Table Entry、Title＃1についてのIndex Table Entry、Title＃2についてのIndexTable Entry,・・・・＃Nを含む。このテーブルには、全てのタイトル、TopMenu、FirstPlaybackから最初に実行されるMovieObjectもしくはBD-J Objectが指定されている。BD-ROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにIndex.bdmvを参照して、所定のMovieObjectもしくはBD-J Objectを実行する。ここで、”FirstPlayback”とは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるBD-JObjectもしくはBD-JObjectが設定されている。また、TopMenuは、リモコンでのユーザ操作で、”MenuCall”のようなコマンドが実行されるときに、呼び出されるBD-JObjectもしくはBD-JObjectが指定されている。
【００１７】
上述したようなタイトル構成は、本図の右側に示すような共通のデータ構造で定義される。本図に示すように当該共通のデータ構造は、『Title_object_type』と、『Title_mobj_id_ref』と、『Title_bdjo_file_name』とを含む。
『Title_object_type』は、”10”に設定されることで、title_idにて特定されるtitleが、BD-J Objectに関連付けられていることを示す。”01”に設定されることで、title_idにて特定されるtitleが、MovieObjectに関連付けられていることを示す。Title_object_typeによる指定、つまり、BD-J Objectに関連付けられるか否かが、このTitle_object_typeに表現される。
【００１８】
『Title_mobj_id_ref』は、Titleに関連付けられたMovie Objectの識別子を示す。
『Title_bdjo_file_name』は、Titleに関連付けられたBD-J Objectファイルの名前を特定している。BD-J Objectは、ApplicationManagementTable()を有し、このApplicationManagementTable()は、実行すべきアプリケーションのapplication_idを示しているので、IndexTable entry内のTitle_bdjo_file_nameによるBD-J Objectファイルのファイル名が、分岐先となるタイトルにおいて、実行すべきBD-Jアプリケーションを指示する
＜BD-ROMの構成その２.Movie Object＞
Movie Objectは、MovieObject.bdmvというファイルに格納される。図４は、MovieObject.bdmvの内部構成を示す図である。本図の左端に示すようにMovieObject.bdmvは、1つ以上のMovieObjectである『MovieObjects()』を含む。図中の図中の引き出し線vh1はMovieObjectsの内部構成をクローズアップしている。MovieObjects()は、自身のデータ長である『length』と、自身に含まれるMovieObjectの個数である『number_of_mobjs』と、number_of_mobjs個のMovieObjectである『MovieObjects』とからなる。これらnumber_of_mobjs個のMovieObjectは、識別子mobj_idをもって識別される。図中の引き出し線vh2は、識別子mobj_idにより特定される任意のMovieObject[mobj_id]()の内部構成をクローズアップしている。
【００１９】
この引き出し線に示すように、MovieObjectは、ナビゲーションコマンドの個数である『number_of_navigation_command』、number_of_navigation_command個の『ナビゲーションコマンド』を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。
PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきPLを指定することができる。第２引数は、そのPLに含まれるPlayItemや、そのPLにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。
【００２０】
PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。
JMPコマンド
書式：JMP 引数
JMPコマンドは、現在の動的シナリオを途中で廃棄し(discard)、引数たる分岐先動的シナリオを実行するという分岐である。JMP命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。以上がMovieObjectについての説明である。続いて、BD-Jアプリケーションの詳細について説明する。
＜BD-ROMの構成その３.BD-Jアプリケーション＞
00001.jarは、BD-Jアプリケーションを格納している。BD-Jアプリケーションとは、Ｊａｖａ（登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)forpackage media targetsとをフル実装したプラットフォーム部にて動作するＪａｖａ（登録商標）アプリケーションである。
【００２１】
このBD-Jアプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destoryed”といった4つの状態をもつ。
上述したＪａｖａ（登録商標）プラットフォーム部は、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードＪａｖａ（登録商標）ライブラリを含む。このため、Ｊａｖａ（登録商標）アプリケーションは、GEM1.0.2にて規定されたHAViフレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含むGUIフレームワークを実現することができる。
【００２２】
これにより、Ｊａｖａ（登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
こうしたBD-Jアプリケーションを構成する一連のファイルは、http：//Ｊａｖａ（登録商標）.sun.com/j2se/1.4.2/docs/guide/jar/jar.htmlに記載された仕様に準じた、Ｊａｖａ（登録商標）アーカイブファイルに変換される。Ｊａｖａ（登録商標）アーカイブファイルは、ZIPファイルの形式を、Ｊａｖａ（登録商標）に特化したものであり、市販されているZIP展開ソフトウェアにより中身を確認することができる。
【００２３】
以上がBD-Jアプリケーションについての説明である。続いて、BD-JObjectの詳細について説明する。
＜BD-ROMの構成その４.BD-JObject＞
00001.bdjoは、BD-JObjectを格納している。BD-JObjectは、アプリケーション管理テーブル(ApplicationManagementTable())を含み、BD-ROM再生時において、タイトル切り替えに伴うアプリケーションシグナリングをプラットフォーム部に実行させるデータのことである。より具体的にいうと、ApplicationManagementTable()は、実行すべきBD-Jアプリケーションを示すapplication_idと、BD-Jアプリケーションを起動する際の制御を示すapplication_contorol_codeを含む。application_contorol_codeは、タイトル選択後におけるアプリケーションの最初の実行状態を規定しており、またapplication_contorol_codeは、BD-Jアプリケーションを仮想マシンにロードして自動開始するか(AUTOSTART)、BD-Jアプリケーションを仮想マシンにロードするが自動開始はしないか(PRESENT)を規定することができる。
【００２４】
＜BD-ROMの構成その５.AVClip＞
拡張子.m2tsが付与されたファイル(00001.m2ts)は、AVClipを格納している。AVClipはMPEG2-Transport Stream形式のデジタルストリームである。
図５は、AVClipの構成を示す図である。本図に示すように、AVClipには、0x1011のPIDをもつビデオストリーム、0x1100から0x111FまでのPIDをもつオーディオストリーム、0x1200から0x121FまでのPIDをもつ32本のPresentationGraphics(PG)ストリーム、0x1400から0x141FまでのPIDをもつ32本のIterractive Graphics(IG)ストリームが多重化されている。
【００２５】
図６は、図５に示した各エレメンタリストリームが、AVClipにおいてどのように多重化されているかを模式的に示す図である。AVClipは、デジタル化された映像、デジタル化された音声を(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のIGストリーム(Interactive Graphics(IG)ストリーム)を(下１段目、下２段目)、TSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００２６】
ここで、ビデオストリームは、本図の第１段目に示すように複数のピクチャから構成されるが、これらピクチャと、Access Unitとの関係は、１AccessUnit ＝ １ピクチャである。オーディオストリームも、複数のオーディオフレームから構成されるが、これらオーディオフレームと、Access Unitとの関係も、本図の第１段目に示すように１オーディオフレーム＝ １Access Unitである。またBD-ROMでは、１PESパケット ＝ １フレームに制限されている。つまり、動画がフレーム構造であれば、１PESパケット＝ １ピクチャであり、フィールド構造である場合、１PESパケット＝２ピクチャとなる。これらのことから、本図の第２段目に示すPESパケットは、第１段目におけるピクチャやオーディオフレームを、１対１の比率で格納している。
【００２７】
以上のAVClipは、1つ以上の“STC Sequence”から構成される。“STC Sequence”とは、デコード時刻、表示時刻を表すMPEG2-TSの時間軸であり、AVストリームのシステム基準時刻であるSTC(SystemTime Clock)の不連続点(system time-base discontinuity)が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR(ProgramClock Reference)を運ぶPCRパケットの不連続情報(discontinuity_indicator)がONである点である。
【００２８】
図７は、PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目は、ビデオストリームを示し、第3段目はオーディオストリームを示す。第2段目は、PESパケット列を示す。本図の矢印yy1,yy2,yy3,yy4に示すように、ビデオストリームにおける複数のVideoPresentation UnitであるIDR、Bピクチャ、Pピクチャは、複数に分割され、個々の分割部分が、PESパケットのペイロード(図中のV＃1,V＃2,V＃3,V＃4)に格納されることがわかる。またオーディオストリームを構成するAudioPresentation Unitであるオーディオフレームは、矢印aa1,aa2に示すように、個々のPESパケットのペイロード(図中のA＃1,A＃2)に格納されていることがわかる。
【００２９】
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図８は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS_extra_header(図中のハッチング部)が付されて、192バイト長のSourceパケットになる。このTS_extra_headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival_Time_Stampを含む。
【００３０】
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC_Seuqence”を構成する。“ATC_Seuqence”とは、AVClipに記されているATSの時間軸を構成するSourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケット列を“ATC_Seuqence”という。ATSは以下のようにTSパケットの先頭につけられ、デコーダへの転送時刻を示す。
【００３１】
かかるATC_SeuqenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第３段目はAVClipを示し、第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳextent以上のデータ長を有する
ファイルエクステントを構成するSourceパケットは、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のSourceパケットを“AlignedUnit”といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。
【００３２】
図９は、AVClipと、Sourceパケットと、ATSの構成とを、階層的に示す図である。第１段目は、AVClipを示し、第２段目は、AVClipを構成するSourceパケット列を示す。第３段目は、SourceパケットにおけるATSの構成を示す。この第３段目に示すように、ATSは、2ビットの予約領域が先頭にあり、その後に、30ビットのATS(ArrivalTime Stamp)が続く形になっている。
＜BD-ROMの構成その６.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図１０は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、
i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』からなる。
【００３３】
ClipInfoには、このClip情報が参照するAVClipのアプリケーションタイプ（application_type）がある。かかるClipInfoを参照することで、アプリケーションタイプによってAVClipかSubClipかや、動画を含んでいるのか静止画(スライドショー)を含んでいるのかなどが識別できる。
Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。
【００３４】
Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramSequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSD画像からHD画像に変化している点等をいう。
【００３５】
続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP_map_for_one_stream_PID(EP_map_for_one_stream_PID[0]〜EP_map_for_one_stream_PID[Ne-1])からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、1つのエレメンタリストリーム上において、AccessUnitが存在するエントリー位置のパケット番号(SPN_EP_start)を、エントリー時刻(PTS_EP_start)と対応づけて示す情報である。図中の引き出し線cu3は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。
【００３６】
これによると、EP_map_for_one_stream_PIDは、Nc個のEP_High(EP_High(0)〜EP_High(Nc-1))と、Nf個のEP_Low(EP_Low(0)〜EP_Low(Nf-1))とからなることがわかる。ここでEP_Highは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。
【００３７】
図中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN_EP_High[i]』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。
【００３８】
図中の引き出し線cu5は、EP_Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point(EP_Low_id)』と、対応するAccessUnitのサイズを示す『I_end_position_offset(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS_EP_Low(EP_Low_id)』と、対応するAccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN_EP_Low(EP_Low_id)』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。
【００３９】
以下、具体例を通じて、EP_mapについて説明する。図１１は、映画のビデオストリームに対するEP_map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP_mapの設定を示す。
【００４０】
第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t1〜t7をエントリー時刻(PTS_EP_start)として示し、これに対応づけてエントリー位置(SPN_EP_start)を示すよう、設定される。  
【００４１】
＜BD-ROMの構成その７.PlayList情報＞
拡張子“mpls”が付与されたファイル(00002.mpls)について説明する。本ファイルは、MainPath、Subpathと呼ばれる2種類の再生経路を束ねたものをPlaylist(PL)として定義する情報である。図１２（ａ）は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())と、Subpathを定義するSubpath情報(Subpath())とを含む。
【００４２】
＜PlayList情報の詳細その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、ビデオストリームやオーディオストリームに対して定義される再生経路である。MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。
【００４３】
この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name[0]』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection_condition』と、このPlayItemが対象としているSTCSequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still_mode』と、PlayItemがマルチアングルを構成する場合、かかるマルチアングルを構成する複数のAVClipを示す『Multi_Clip_entries』と、『STN_table』とから構成される。
【００４４】
図１２（ｂ）は、Multi_Clip_entriesの内部構成を示す図である。本図に示すように、Multi_Clip_entriesは、マルチアングル区間におけるアングル総数を示す『number_of_angles』、アングル映像において、異なる音声を再生させるかどうかを示す『is_different_audio』を有しており、『Clip_Information_file_name[1]』、『ref_to_STC_id[1]』〜『Clip_Information_file_name[N]』、『ref_to_STC_id[N]』を含む。
【００４５】
これらMulti_Clip_entriesにおける『Clip_codec_identifier』、『Clip_Information_file_name』、『ref_to_STC_id[0]』のそれぞれは、マルチアングル区間において、個々のアングル映像を構成するAVClipに対応している。
＜PlayList情報の詳細その２.PlayListMark情報＞
以降、PlayListMark情報について説明をはじめる。
【００４６】
図１３は、PlayList情報におけるPlayListMark情報の内部構成を示す図である。本図の図中の引き出し線pm0に示すように、PlayListMark情報は、複数のPLMark情報(＃1〜＃n)からなる。PLmark情報(PLmark())は、PL時間軸のうち、任意の位置を、チャプター点として指定する情報である。引き出し線pm1に示すようにPLmark情報は、チャプター指定の対象たるPlayItemを示す『ref_to_PlayItem_Id』と、そのPlayItemにおける、チャプター位置を時間表記により示す『mark_time_stamp』とを含む。
【００４７】
図１４は、AVClipと、PlayList情報との関係を示す図である。第2段目から第5段目は、図１０の第１段目から第４段目までと同一であり、EP_mapにて参照されているビデオストリームを示す。
本図におけるPlayList情報は、PlayItem情報＃1,＃2という2つのPlayItem情報を含んでおり、これらPlayItem情報＃1,＃2のIn_time,Out_timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。
【００４８】
本図の第1段目は、PLMark情報と、PlayList時間軸とを示す。この第1段目には、2つのPLMark情報＃1〜＃2が存在する。矢印kt1,2は、PLMark情報のref_to_PlayItem_Idによる指定を示す。この矢印からもわかるようにPLMark情報のref_to_PlayItem_Idは、参照するPlayItemを指定していることがわかる。また、Mark_time_Stampは、当該PlayItem時間軸のうち、Chapter＃1,＃2になるべき時点を示す。このように、PLMark情報は、PlayItem時間軸上に、チャプター点を定義することができる。
＜PlayList情報の詳細その３.STN_table＞
以降、STN_tableについて説明する。STN(STream Number)_tableは、Clip情報で参照されるAVClipに多重化されている各エレメンタリストリームの再生が、PlayItem情報において、有効であるか無効であるかを表す。
【００４９】
図１５は、STN_tableの設定例を示す図である。左側は、PlayItem情報を示し、真ん中は、AVClipに含まれるエレメンタリストリームの種別を示す。右側は、STN_tableにおける具体的な設定を示す。
本図の表記によると、真ん中のAVClipには、1本のビデオストリームと、3本のオーディオストリーム1,2,3と、4本のPGストリーム1,2,3,4と、3本のIGストリーム1,2,3とが含まれていることがわかる。
【００５０】
右側のSTN_tableの具体的な設定によると、ビデオ、オーディオ1,2、プレゼンテーショングラフィックス1,2、インタラクティブグラフィックス1が有効になっていることがわかる。したがって、このPlayItem情報では、STN_tableにおいて有効と設定されているエレメンタリストリームが再生可能であり、その他のエレメンタリストリームは再生が禁止される。またSTN_tableには、各エレメンタリストリームの属性情報も同時に記録されている。ここで属性情報とは、各エレメンタリストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。
【００５１】
以上がBD-ROMのデータ構造についての説明である。本発明にかかる記録媒体は、かかるデータ構造を前提にして、動画メニューを構成する。図１６は、動画メニュー用AVClipの一般的な階層構造を示す図である。本図における第１段目は、Index.bdmvを示し、第２段目はMovieObjectを示している。第１段目に描かれたIndex.bdmvは、各タイトルに対応するインデックスを有する。これらのうち、Index.bdmvのTopMenuにはMovieObject＃1が設定されており、TopMenuがコールされると、第２段目において、MovieObject＃1に設定されているコマンドが順に実行される。MovieObject＃1の1番目のコマンドには”PlayPL  PlayList＃1”が設定されている。PlayPLコマンドは、引数となるプレイリストを先頭から再生するコマンドである。”PlayPL  PlayList＃1”のコマンドが実行されると、再生装置はPlayList情報＃1の先頭PlayItem情報である、PlayItem情報＃1を解析し、そのPlayItem情報＃内のClip_Information_file_nameにて指定されるAVClipの再生を開始する。
【００５２】
AVClipは背景動画の映像とともに、ユーザがメニュー操作を行うためのIGストリームが多重化されている。AVClipの長さは、コンテンツに依存するが、あまり長い映像を使うとディスクの容量を逼迫してしまうので、1分程度の短い映像を使うことが一般的である。AVClipの再生が完了すると、次のコマンドに遷移する。図１６の場合、2番目のコマンドには“JumpMovieObject＃1”が設定されている。本ジャンプコマンドは、PlayList情報＃1の再生後、MovieObject＃1にジャンプして、再びPlayPLコマンドの呼び出しを行わせるものである。
【００５３】
PlayItem情報＃1のIn_Timeは、動画メニュー用AVClipの先頭に存在するピクチャデータのPresentation TiMe(PTM)を示すよう設定されており、Out_Timeは、動画メニュー用AVClipの終端に存在するピクチャデータのPresentationTiMe(PTM)を示すよう設定されている。かかるPlayPLコマンドと、Jumpコマンドとがコマンドプロセッサにて実行されることで、プレイリストの再生が何度も実行されることになる。
【００５４】
しかし、このようなデータ構成の場合、PlayList情報＃1の再生が終了し、再度PlayList情報＃1が再生する間に、AV再生画面の静止と、ボタンの消去が生じる。
具体的にいうと、PlayPLコマンドで指定されたPlayList情報に基づくAVClipの再生が終了すると、PlayPLコマンドを実行して、再度PlayList情報をロードしなおそうとする。この際、テレビにおけるAV再生画面は、PlayItem情報にて参照されている最後のピクチャを表示したままになるので、AV再生画面の静止が発生する。
【００５５】
また、PlayList情報の再ロードの際、再生装置は、PlayList情報が配置されたメモリ領域や、デコーダにおけるバッファメモリをフラッシュを行う。このフラッシュにおいて、IGストリームで構成されたメニューを構成するボタンや、PGストリームで構成された字幕が一旦、画面から削除されので、AV再生画面からボタンや字幕が消えてしまう。本実施形態が提案しているのは、このようなAV再生画面の静止やボタン、字幕の消去といった課題を解決することである。
【００５６】
図１７は、BD-ROM１００の特徴的なデータ構造を示す図である。左側は、PlayList情報のデータ構造を示し、右側は、PlayItem情報の具体的な設定を示す。左側によると、PlayList情報は、１〜999個のPlayItem情報を含む。PlayItem情報の識別番号は、３桁の数値なので、この３桁の数値で表現可能な最大数のPlayItem情報が、PlayList情報内に存在している。一方、右側における具体的な記述によると、999個の各PlayItem情報の記述は、共通のものになっていることがわかる。つまりClip_Information_file_nameは、動画メニュー用AVClipであるAVClip＃1のClip情報を示し、In_Timeが動画メニュー用AVClipの開始PTM(PresentationTiMe)を示し、Out_Timeが動画メニュー用AVClipの終了PTMを示し、connection_condition情報は、CC=5(シームレス接続)を示していることがわかる。かかるPlayList情報のデータ構造を、図１６と同じ表記で示したのが、図１８である。
【００５７】
BD-ROM規格において、PlayItem情報の個数が999個以下に制限されているのは、識別番号に割り当てられている桁数に制限があることと、PlayList情報をオンメモリで使用したいとの要望による。つまり、PlayList情報は、AVClipの再生に先立ち、メモリに読み込まれ、PlayList情報に基づくAVClipの再生は、PlayList情報が、メモリに搭載されている状態でなされる。このように、オンメモリで利用されることが前提なので、PlayItem情報の個数をむやみに増やすことは許されず、BD-ROMの応用層規格では、999個以下と定められている。
【００５８】
図１８は、第１実施形態における動画メニューの階層構造を示す。図１６との違いは、第２段目におけるPlayList情報＃1の構成である。図１６のPlayList情報＃1が一つのPlayItem情報から構成されているのに対し、図１８のPlayList情報＃1は、999個のPlayItem情報を含み、それら999個のPlayItemのIn_Time、Out_Timeは、同じAVClipの先端部分、終端部分を指定している。そして、999個のPlayItemのうち、先頭にあたるPlayItem情報＃1以外は、connection_condition＝5に設定されている。これにより各PlayItem情報間はシームレス接続であることを再生装置に通知することが出来る。
【００５９】
また複数のPlayItem情報が参照している共通のメニュー用AVClipにおいて、メニュー用AVClipの終端のエクステントからメニュー用AVClipの先頭が含まれるエクステントまで距離は、最大ジャンプサイズSjump_maxを越えないように設定され、かつ、メニュー用AVClipの終端のエクステントは、そのジャンプ距離をジャンプする時間から算出される最小エクステントサイズ以上のサイズに設定されている。
【００６０】
更に複数のPlayItem情報が参照している共通のメニュー用AVClipは、メニュー用AVClipの終端までデコードした後、デコードバッファをクリアせず、引き続きメニュー用AVClipの先頭から再生を行っても、デコードモデルが破綻しないようにデータが作成されている。AVClipの先端部分には、特定の初期状態を想定した符号割り当てがなされている。この特定の初期状態とは、直前のPlayItemでAVClipを再生するにあたって、当該AVClipのバッファ読み込みが完了した時点におけるバッファの状態をいう。
【００６１】
先端部分に対する符号量割当て割り当てをこのように設定することによって、メニュー用AVClipは、繰り返しメニュー用AVClipを再生しても、シームレスに再生することができる。
以上説明したデータ構造にすることによって、図１７のPlayList情報＃1を再生すると、PlayItem情報＃1からPlayItem情報＃999まで、同じAVClipの再生を繰り返し、シームレスに再生することになる。例えば、PlayItem情報の数を規格最大数である、999個に設定することによって、短いAVClipを使いながらPlayList情報＃1は擬似的に永久にループする。これによって、1つのAVClipの再生のたびに静止が発生したり、メニューを構成するボタンや字幕が消えたりすることを回避できる。例えばPlayItem情報の数を999個として、1分間のAVClipを用意すれば、999分=16.5時間の再生が可能となり、一般的にメニュー操作に必要と想定される時間よりも大幅に長い時間、映像の静止が発生したりメニューを構成するボタンや字幕が消えたりせずに、シームレスにAVClipを再生することが可能となる。つまりJumpコマンドを実行して、PlayPLコマンドを反復することによる再生の途切れは、999回に１回となる。
【００６２】
こうすることで、たとえPlayPLコマンドとJumpコマンドとの間では、AV画面の静止やボタン、字幕の消去が発生するとしても、999個のPlayItemが再生されている間は、これらが生じることはない、仮にAVClipの時間長が１分近くの短いものであっても、999分=16.5時間ものの間は、再生の途切れが発生しないので、AVClipの時間長が短いものであっても、再生の途切れがないメニュー操作待ちを実現することができる。
【００６３】
以降、PlayList情報内の個々のPlayItem情報の接続は、どのように実現されるかについて説明する。
図１９（ａ）は、ATC Sequenceと、STC Sequenceとの関係を示す図である。本図に示すように、BD-ROMにおけるAV Clipに包含されるATCSequenceの数は、1つに固定されている。一方、この1つのATC_Sequenceに対して、複数のSTC_Sequenceを包含させることは可能である。
【００６４】
図１９（ｂ）は、縦軸にSTC_SequenceにおけるSTCの値をプロットし、横軸に、ATC_SequenceにおけるATCの値をプロットしたグラフである。ATC値と、STC値とは、単調増加の関係にあり、ATC値が増えればSTC値も増える。但し、STCSequenceの切り替わる時点においては、STCの不連続点が生じていることがわかる。
PlayList情報に含まれる複数のPlayItem情報のうち、任意の一個を“Current PlayItem”と呼び、このCurrent PlayItemの直前に位置するPlayItem情報を“previousPlayItem”という。
【００６５】
図２０（ａ）は、シームレスに接続される2つのAVClip(previous PlayItemにて参照されるAVClip＃1、Current PlayItemにて参照されるAVClip＃1)を示す図である。
図２０（ｂ）は、previous PlayItemにて参照されるAVClip＃1におけるVideo Presentation Unit、及び、AudioPresentation Unitと、Current PlayItemにて参照されるAVClip＃1におけるVideo Presentation Unit、及び、AudioPresentation Unitとの関係を示す図である。第１段目は、previous PlayItemにて参照されるAVClip＃1を構成するVideoPresentation Unit(ビデオフレーム)と、Current PlayItemにて参照されるAVClip＃1を構成するVideoPresentation Unit(ビデオフレーム)とを示す。
【００６６】
第２段目は、previous PlayItemにて参照されるAVClip＃1を構成するAudio Presentation Unit(オーディオフレーム)を示す。第３段目は、CurrentPlayItemにて参照されるAVClip＃1を構成するAudio Presentation Unit(オーディオフレーム)を示す。ここで、previousPlayItemにて参照されるAVClip＃1のうち、最後のVideo Presentation Unitの再生時刻を200000とし、CurrentPlayItemにて参照されるAVClip＃1のうち、最初の再生時刻を500000とする。このように、previous PlayItemにて参照されるAVClip＃1の最後のVideoPresentation Unitの再生時刻と、Current PlayItemにて参照されるAVClip＃1の最初の再生時刻とが不連続であっても、シームレス再生は可能になる。
これら2つのAVClip間は、Clean Breakの条件を満たす必要がある。具体的には以下の制約が課される。
【００６７】
(1) シームレス境界では、AudioフレームをOverlapさせる
(2) Clip＃1のAudioの終端フレームと、ビデオの終了時刻とがOverlapしている。
(3) Clip＃2のAudioの先頭フレームと、ビデオの開始時刻とがOverlapしている。
previous PlayItemにて、再生装置に送り込まれるトランスポートストリームパケット列を“TS1”といい、Current PlayItemにて、再生装置に送り込まれるトランスポートストリームパケット列を“TS2”という。CleanBreakは、previousPlayItemにてデコーダに送り込まれるTS1と、Current PlayItemにてデコーダに送り込まれるTS2とが、図２１のような関係を満たしていることをいう。図２１は、CleanBreakの詳細を示す図である。
【００６８】
第1段目は、TS1、TS2における複数のVideo Presentation Unitを示し、第2段目は、TS1におけるAudio PresentationUnit、TS2におけるAudio Presentation Unitを示す。第3段目は、AVClipにおけるSTCの値を示す。第4段目は、AVClipにおけSourceパケット列を示す。
本図において、ハッチングが付されているのは、TS1側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットであり、ハッチングが付されていないのは、TS2側のVideoPresentation Unit、Audio Presentation Unit、Sourceパケットである。
【００６９】
本図においてClean Breakとは、Video Presentation Unit境界を一致させるものの(第1段目)、AVClipのATCにおいてギャップがあり(第4段目)、AVClipのAudioPresentation Unitでオーバラップが存在する(第2段目)状態をいう。
上述したVideo Presentation Unitの境界とは、TS1側から見れば、第1段目における最後のVideo Presentation Unitの終了点PTS11End+Tppにあたり、TS2側から見れば、第1段目におけるVideoPresentation Unitの開始点PTS22Startにあたる。
【００７０】
TS1のうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5a、TS2のうち、時点T4に一致するAudioPresentation Unitの開始点をT3aとした場合、AVClipにおけるオーバラップは、Audio Presentation UnitはT3aからT5aにまでとなる。
この図から、CC＝5を実現するには、Video Presentation Unit、Audio Presentation Unit、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。
【００７１】
(1)TS1におけるオーディオストリームの最後のAudio Presentation Unitは、previous PlayItemにて指定されるTS1における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。
(2)TS2におけるオーディオストリームの、最初のAudio Presentation Unitは、カレントPlayItemにて指定されるTS2の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。
【００７２】
(3)接続点のAudio Presentation Unit列において、ギャップが存在しない。これは接続点において、Audio PresentationUnit列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、2つのオーディオフレーム再生期間より短い大きさでなければならない。
(4)TS2の最初のパケットは、PAT(Program Allocation Table)を含み、1つ以上のPMT(Program Map Table)がその直後に後続しなければならない。PMTがTSパケットのペイロードより大きければ、PMTは、2パケット以上になることもある。PMTを格納したTSパケットには、PCRやSITが存在しなければならない。以上で、本発明にかかる記録媒体の実施形態についての説明を終える。
【００７３】
続いて、本発明にかかる再生装置について説明する。
図２２は、一般的な再生装置２００の構成を示している。再生装置２００は、BD-ROMドライブ１、Read Buffer２、多重分離部３、デコーダ４,５,６,７、プレーンメモリ８a,b,c、ユーザイベント処理部９a、データ解析実行部９bから構成されている。
BD-ROMドライブ１は、データ解析実行部９bからの命令を元に、BD-ROMディスクからデータを読み出し、Read Buffer２にデータを蓄える。BD-ROMディスクから読み出すデータは、AVClipだけでなく、index.bdmv、MovieObject.bdmv,PlayList情報等も含まれる。
【００７４】
Read Buffer２は、BD-ROMドライブ１を使って読み込んだSourceパケット列を一時的に格納するメモリ等で構成されたバッファである。
多重分離部３は、Read Buffer２に読み出されたSourceパケットに対して多重分離処理を行う。
デコーダ４,５,６,７は、AVClipのデコードを行い、ディスプレイ等の画面に表示を行う。
【００７５】
プレーンメモリ８a,b,cは、ビデオデコーダ４、IGデコーダ６、PGデコーダ７のデコード結果である１画面分の画素データを保持する。
加算部８dは、プレーンメモリ８a,b,cに格納された、一画面分の画素データを合成した上で出力する。かかる出力によって、動画像に、メニューが重畳された合成映像を得ることができる。
【００７６】
ユーザイベント処理部９aは、リモコンを通じたユーザ操作に応答して、データ解析実行部９bに処理の実行を依頼する。たとえば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようデータ解析実行部９bに依頼する。
データ解析実行部９bは、BD-ROMに記録されたMovie ObjectやBD-Jアプリケーションに基づき、操作待ち制御を実行する。データ解析実行部９bは、MovieObjectを構成するナビゲーションコマンドを実行するコマンドプロセッサ、BD-Jアプリケーションを実行するＪａｖａ（登録商標）プラットフォーム、再生制御エンジンとを含む。再生制御エンジンは、コマンドプロセッサによるPlayPLコマンドの実行結果やプラットフォーム部によるAPIコールに基づき、PlayList情報を介したAVClipの再生を行う。操作待ち制御は、MovieObjectに含まれるPlayPLコマンドの実行を、コマンドプロセッサが反復して実行し、個々のPlayItem情報に対応するAVClipの読み出しと、ビデオデコーダ４〜PGデコーダ７への、AVClipの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する。上述したようなナビゲーションコマンドやBD-Jアプリケーションの実行は、ユーザイベント処理部９aが受け付けたリモコン操作に基づく。かかる実行により、AVClipの再生やIGストリームのボタンの表示切替等の制御がなされる。ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の制御も行い、たとえばシームレスに再生するAVClip＃1とAVClip＃2がある場合は、AVClip＃1の再生終了時にデコーダのリセット要求を行わずに、AVClip＃2を続けてデコーダへ転送する。
【００７７】
図２３は、ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の内部構成を示す図である。
＜多重分離部３＞
本図において、多重分離部３は、Source Depacketizer３a、PID Filter３b、ATCカウンタ３c,d、加算部３e、加算部３f、ATC_diff計算部３g、STC_diff計算部３ｈから構成される。
【００７８】
ソースデパケッタイザ(Source  De-packetizer)３aは、TS1,TS2を構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、各TSパケットのATSに応じてデコーダへの入力時刻を調整する。具体的には、ATCCounter３cが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS_Recording_Rateで、そのTSパケットだけをPIDFilter３bに転送する。
【００７９】
PID Filter３bは、ソースデパケッタイザ３aから出力されたSourceパケットのうち、PlayItem情報におけるSTN_tableに記載されたPID参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ５、InteractiveGraphicsデコーダ６、Presentation Graphicsデコーダ７に出力する。各デコーダは、PID Filter３bを経由したエレメンタリストリームを受け取って、TS1,TS2のPCRに従いデコードから再生の処理を行う。このようにPIDFilter３bを通過して各デコーダに入力されるエレメンタリストリームは、TS1,TS2のPCRに従って、デコード及び再生に供されることになる。
【００８０】
ATC Counter３cは、TS1,TS2を構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ３aにATCを出力してゆく。
STC Counter３dは、TS1,TS2のPCRによってリセットされ、STCを出力する。
加算部３eは、ATC Counter３cにより生成されたATC(ATC値1)に、所定のオフセットを加算した上で、PIDフィルタ３aに出力する。
【００８１】
加算部３fは、PIDフィルタ３ｄにより生成されたSTC(STC値2)に、所定のオフセットを加算した上で、デマルチプレクサ３bに出力する。
ATC_diff計算部３gは、ATC Sequenceが切り替わった場合、ATC_diffを算出して、加算部３eに出力する。加算部３eが、ATCCounter３cにて生成されているATC値(ATC1)に、当該ATC_diffを加算することで、新しいATC SequenceのATC値(ATC2)が得られる。
【００８２】
STC_diff計算部３ｈは、STC Sequenceが切り替わった場合、STC_diffを算出して、加算部３fに出力する。加算部３fが、それまでのSTCSequenceにおけるSTC値(STC1)に、STC_diffを加算するよう、加算部３fを制御することで、新しいSTC SequenceのSTC値(STC2)が得られる。
図２４は、ATC Diff、STC Diffを示す図である。第１段目は、TS1の時間軸を示し、第３段目は、TS2の時間軸を示す。TS1には、図２１に記述した、STC11end、PTS11endが存在する。一方TS2には、STC21end、PTS21startが存在する。第２段目の矢印は、TS1からTS2への写像を模式的に表したものである。つまり第２段目の左側の矢印を追うと、TS2上のSTC21endは、TS1上のSTC11endをTS2上に写像した写像点であることがわかる。一方、右側の矢印を追うと、TS2上のPTS21startは、TS1上のPTS11endからＴpp隔てた時点(PTS11end＋Ｔpp)を、TS2上に写像した写像点であることがわかる。このＴppは、一ビデオフレームの間隔を示す。
【００８３】
第４段目は、ATC Diff、STC Diffを算出するための計算式を示す。
STC Diffは、以下の数式に基づき算出される。
STCDiff = PTS11end + Tpp + PTS22start
∴ STC2 = STC1 - STCDiff 
ATCDiffは、以下の数式に基づき算出される。  
【００８４】
ATCDiff ＝ STC22start - (STC11end - STC_diff -188/ts_recording_rate(TS1) )
＝ STC22start - (STC21end - 188/ts_recording_rate(TS1) )
＝ 188/ts_recording_rate(TS1) + STC22start - STC21end 
シームレス接続されるTS1/TS2については、このように計算されたATCDiffを、再生装置内のATCに加算することによってATCを補正した時間軸でバッファモデルを破綻させないようにしている。
【００８５】
ATC_diff計算部３g、STC_diff計算部３ｈは1つのPlayItem情報がシームレス接続を意味する、CC=5のConnectioin_condition情報を有している場合、ATCにATC_diffを加算し、STCにSTC_diffを加算する。これにより、１のPlayItem情報によるAVClip読み出し時と、直前のPlayItem情報によるAVClip読み出し時とで、ATCにて示されるカウント値と、STCにて示されるカウント値とを、連続させることができ、かかる連続化により、多重分離部３による多重分離処理や、ビデオデコーダ４〜PGデコーダ７によるデコード処理を途切れなく行うことができる。
＜ビデオデコーダ４＞
ビデオデコーダ４は、Transport Buffer(TB)４a、Multiplexed Buffer(MB)４b、Coded PictureBuffer(CPB)４c、Decoder４d、Re-order Buffer４e、スィッチ４fから構成される。
【００８６】
Transport Buffer(TB)４aは、ビデオストリームに帰属するTSパケットがPID Filter３bから出力された際、一旦蓄積されるバッファである。
Multiplexed Buffer(MB)４bは、Transport Buffer４aからElementary Buffer４cにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。
【００８７】
Elementary Buffer(EB)４cは、符号化状態にあるピクチャ(Iピクチャ、Bピクチャ、Pピクチャ)が格納されるバッファである。
デコーダ(DEC.)４dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の復号時刻（DTS）ごとにデコードすることにより複数フレーム画像を得て、ビデオプレーン８aに書き込む。
【００８８】
Re-order Buffer４eは、復号されたピクチャの順序を、符号化順序から表示順序に入れ替えるためのバッファである。
スィッチ４fは、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
＜オーディオデコーダ５＞
オーディオデコーダ５は、Transport Buffer(TB)５a、Buffer５b、Decoder５cから構成される。
【００８９】
Transport Buffer５aは、PID Filter３bから出力されたTSパケットを、先入れ先だし式に格納して、オーディオデコーダ５ｃに供する。
Buffer５bは、PID Filter３bから出力されたTSパケットのうち再生されるべきオーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ５ｃに供する。
【００９０】
デコーダ５cは、Buffer５bに格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
＜IGデコーダ６＞
IGデコーダ６は、Transport Buffer(TB)６a、Coded Data Buffer(CDB)６b、Stream GraphicsProcessor(SGP)６c、Object Buffer(OB)６d、Composition Buffer(CB)６e、GraphicsController(Ctrl.)６fから構成される。
【００９１】
Transport Buffer(TB)６aは、IGストリームに帰属するTSパケットが一旦蓄積されるバッファである。
Coded Data Buffer(CDB)６bは、IGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)６cは、グラフィクスデータを格納したPESパケットをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer６dに書き込む。
【００９２】
Object Buffer６dは、Stream Graphics Processor６cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer(CB)６eは、グラフィクスデータ描画のための制御情報が配置されるメモリである。
Graphics Controller(Ctrl)６fは、Composition Buffer６eに配置された制御情報を解読して、解読結果に基づく制御をする。
＜PGデコーダ７＞
PGデコーダ７は、Transport Buffer(TB)７a、Coded Data Buffer(CDB)７b、Stream GraphicsProcessor(SGP)７c、Object Buffer(OB)７d、Composition Buffer(CB)７e、GraphicsController(Ctrl)７fから構成される。
【００９３】
Transport Buffer(TB)７aは、PGストリームに帰属するTSパケットが多重分離部３aから出力された際、一旦蓄積されるバッファである。
Coded Data Buffer(CDB)７bは、PGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor(SGP)７cは、グラフィクスデータを格納したPESパケット(ODS)をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer７dに書き込む。
【００９４】
Object Buffer(OB)７dは、Stream Graphics Processor７cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer(CB)７eは、グラフィクスデータ描画のための制御情報(PCS)が配置されるメモリである。
Graphics Controller(Ctrl)７fは、Composition Buffer７eに配置されたPCSを解読して、解読結果に基づく制御をする。
【００９５】
ATC Counnter３ｃ、STC Counter３ｄによるカウント値に、ATC Diff,STC Diffが加算されることで、previousPlayItemにおけるATC Sequenceと、Current PlayItemにおけるATC Sequenceとは連続した値になり、previousPlayItemにおけるSTC Sequenceと、Current PlayItemにおけるSTC Sequenceも連続した値になる。
このように、ATC、STCが連続した値になった状態において、Read Buffer、Elementary Buffer のバッファ状態がどのように変化するかについて説明する。
＜Read Bufferのバッファ状態＞
図２５は、Read Bufferのバッファ状態を示す図である。横軸は時間軸であり、縦軸は各時点における蓄積量を示す。本図に示される蓄積量は、ReadBufferにSourceパケットが蓄積されることによる単調増加と、Read BufferからSourceパケットが出力されることによる単調減少とを繰り返す形になっている。かかる単調増加の傾きは、AVClipをReadBufferに読み出す転送速度(Rud)と、Read BufferからAVClipを出力する転送速度(Rmax)との差、すなわちRud-Rmaxで増加する。この時、データバッファがオーバーフローしないように、ドライブからのAVClip読み出しは、休止しながらなされる。
【００９６】
図中の単調減少は、光ディスクからのデータの読み出しがストップするためのものであり、その傾きは、転送速度Rmaxとなる。かかる単調減少は、先端部エクステントの読出し完了後、終端部エクステントへとジャンプする際、発生する。
かかるジャンプの間に、Read Buffer２におけるAVClip＃1のデータが枯渇することがなければ、終端部エクステントを読み始めると同時に、再度Rud-Rmaxの速度でデータは増加してゆく。そのため、デコーダへのデータ転送は途切れることなくシームレスな再生を行うことが可能である。つまりシームレスな再生を実現するためには、ジャンプ前の先端部エクステントのサイズが十分に大きければ、次の終端部エクステントへジャンプしている間も、ReadBufferに格納されているデータをデコーダに送り続けることで、データの連続的な供給が保証できる。
【００９７】
次にBD-ROMにおいてAVClipのシームレス接続を行うための物理的なディスクの配置についての設定方法および条件を説明する。この説明には、図２５を引用する。
AVClipをシームレス接続するには、各AVClipを構成するエクステントの配置もシームレス接続を満足させるように設定する必要がある。各AVClipがシームレス接続になるようにエクステントを配置するには、各AVClip内のエクステントについてはそれぞれ単独のAVClipとしてシームレスに再生可能なようにエクステントの配置を行う。それとともに、一のAVClipを構成する先端エクステント及び終端エクステントは、一方から他方へと相互にジャンプできるように配置する。具体的にいうと、個々のエクステントの大きさを、所定の最小サイズ以上に設定し、一方から他方へとジャンプするにあたってのジャンプ距離を、最大ジャンプ距離Sjump_maxを越えないように設定する。例えば、図１８の場合、AVClipの終端部分と先端部分とは、シームレス接続を実現する必要があるので、前半エクステントは、終端部分へのジャンプ距離を考慮した最小エクステントサイズ以上に設定する。尚且つ、後半エクステントの終端部分から、前半エクステントの先端部分までのジャンプ距離は最大ジャンプ距離Sjump_max以下になるように設定する。
【００９８】
同様に後半エクステントは、最小エクステントサイズ以上に設定し、かつ後半エクステントの終端部分から先端部分までのジャンプ距離は最大ジャンプ距離Sjump_max以下になるように設定する。
以上のことから、エクステントの長さを、Tjumpの間にRead Buffer２に蓄積されたデータが枯渇しないサイズ以上にすることによって、シームレスな再生を保証することができる。シームレスな再生を保証するエクステントのサイズは以下の式で表すことができる。
【００９９】
(Sextent×8)/(Sextent×8/Rud+Tjump)>=Rmax ・・・(1)
式（１）において、Sextentはエクステントのサイズをバイトで表し、Tjumpは一つの先端部エクステントから次の終端部エクステントへの最大ジャンプ時間を秒で表す。RudはディスクからのAVClipの読み出し速度、RmaxはAVClipのビットレートを表し、単位は、ビット/秒である。なお、Sextentに乗じられている「８」は、バイト/ビットの換算のためである。以下、式（１）によって算出されるシームレスな再生を保証するエクステントサイズの最小値を最小エクステントサイズと定義する。
【０１００】
ただし、Read Buffer２のサイズは限られるため、Read Buffer２へ最大にデータを読み出した状態から、シームレスに再生できる最大のジャンプ時間が規定される。例えば、先端部エクステントのサイズの読み出しによって、ReadBuffer２に蓄積されるAVClipのRead Buffer２が、バッファサイズ一杯の状態になっても、次のエクステントまでの距離が非常に大きい場合、終端部エクステントまでジャンプし読み出しを開始するまでにバッファが枯渇してしまい、シームレスの再生を行えない。このシームレス再生を保証できる最大のジャンプ時間を最大ジャンプ時間(Tjump_max)とする。また、最大ジャンプ時間内にジャンプできるデータサイズを最大ジャンプサイズ（Sjump_max）と定義する。最大ジャンプサイズの大きさは、ReadBuffer２やビットストリーム、ドライブのアクセススピードなどから所定の規格等で定められる。
【０１０１】
＜Elementary Buffer の時間的遷移＞
図２６は、ビデオデコーダにおけるElementary Buffer における蓄積量の時間的遷移を示す図である。上段は、previous PlayItemによる再生で、ストリームを読み込む場合の、ElementaryBuffer における蓄積量の時間的遷移を示す。下段は、Current PlayItemによる再生で、ストリームを読み込む場合の、ElementaryBuffer における蓄積量の時間的遷移を示す。
【０１０２】
上段及び下段に示された、グラフの読み方について説明する。横軸は時間軸であり、縦軸は各時点における蓄積量を示す。本図に示すように、ElementaryBuffer における蓄積量の時間的遷移は、ノコギリ波形をなす。
t_in_startは、シームレスに接続する場合に、Elementary Buffer への先頭ピクチャデータの入力が開始される時刻を示す。
【０１０３】
t_in_endは、Elementary Buffer への最後のピクチャデータの入力が終了する時刻を示す。
t_out_endは、Elementary Buffer からの最後のピクチャデータの出力が終了する時刻を示す。
Last DTSは、最後のピクチャデータのデコードが終了する時点を示す。
【０１０４】
First DTSは、先頭のピクチャデータのデコードが終了する時点を示す。
t_in_startからt_in_endまでは、Elementary Buffer の入出力が同時になされている期間を示す。当該期間におけるノコギリ波形は、各ピクチャデータがElementaryBuffer に読み込まれることによるバッファ量の単調増加と、ピクチャデータがElementary Buffer から取り出されることによる単調減少とを意味する。傾きは、ElementaryBuffer への転送速度Rbx１を示す。
【０１０５】
t_in_endからt_out_endまでは、Elementary Buffer からの出力のみになっている期間を示す。当該期間における階段波形は、ピクチャデータがElementaryBuffer から取り出されることによる単調減少を意味する。
上述したようなATC Sequence、STC Sequenceに、ATC Diff,STC Diffが加算されることで、previous PlayItemにおけるt_in_endと、CurrentPlayItemにおけるt_in_startは、一致した時点となる。また Last DTSの一フレーム後に、First DTSが存在している。このような一致が発生すると、バッファオーバーフローの発生が危惧される。
【０１０６】
つまり、previous PlayItemにて再生されるべきAVClipと、これに引き続き、Current PlayItemにて再生されるべきAVClipとをシームレスに再生する際、previousPlayItemにより再生されるべきAVClipが、Elementary Buffer に残っている状態を想定して、AVClipの割当符号量を決める必要がある。つまり、connection_condition“=1”での接続状態では、各バッファにはデータがない状態を想定してデータ作成を開始すればよい。しかし、connection_condition＝5で再生されるべきAVClipを作成する場合には、previousPlayItemにより再生されるべきAVClipが、バッファに残っている状態を初期状態として、Current PlayItemにおけるAVClipの作成を開始する必要がある。
【０１０７】
動画メニュー用AVClipの場合、AVClipにおける終端部分のデコードが完了した時点でのバッファ状態を初期状態として、デコーダモデルが破綻しないように動画メニュー用AVClipを作成する必要がある。
そこで、動画メニュー用AVClipは、previous PlayItemにて参照されるAVClipのビデオデータのElementary Buffer の遷移において、t_out_end−t_in_endの値がT時間になるように、多重化がなされる。このT時間については、AVClipごとに時間を変化させたり、固定値に設定される。
【０１０８】
Current PlayItem側のAVClipにおけるt_in_startは、previousPlayItem側のt_in_endに近い位置に設定されるので、上述したようなT時間にあたる時点から、t_out_startまでの時点には、その後のビデオデータの再生がシームレスに再生されるように符号量を割り当てる必要がある。たとえば、バッファ上限値であるB_maxになるような符号量割当てがなされねばならない。かかる符号量割当てには、入力制限直線が用いられる。どのように用いるかというと、入力制限直線は、ElementaryBuffer へのビットレートRbx1を下回るような符号量割当てに利用される。
【０１０９】
図２７は、Elementary Buffer における蓄積量の遷移と、Elementary Buffer におけるバッファ容量の遷移とを示す。上段が、previousPlayItemにおけるバッファ容量の時間的遷移を示し、下段が、CurrentPlayItemにおける蓄積量の時間的遷移を示す。
図２８は、入力制限直線を示す図である。入力制限直線は、データ入力終了時刻(t_in_end)を通過し、バッファ容量を示すノコギリ波形と接する直線を求めることで、導出される。
【０１１０】
ストリームの先端部分における符号量割当てが、入力制限直線に等しいか、或はそれ以下であるなら、previous PlayItemに対応する入力期間において、CurrentPlayItemのためのストリーム読込みを実現するにしても、Elementary Buffer がオーバーフローすることはない。
previous PlayItemによる再生におけるt_in_endと、Current PlayItemによる再生におけるt_in_startとを同一の時間軸上で一致させることで、これらの時間的遷移は、図２９のようになる。かかる一致にて、一個のPlayItem情報による、同一AVClipの再生の繰り返しはシームレスになされる。
【０１１１】
以上が、原則的なビデオストリームに対する符号量割り当てである。しかしAVClipに、オーディオストリームが多重化されていると、事情が変わってくる。それは、オーディオはビデオよりもバッファサイズが小さく、フレーム間隔も細かいというオーディオストリームの特性による。かかる特性により、オーディオデータのバッファへの転送終了時刻は遅れるので、ビデオのvbv_delayの値が引きずられる形で小さくなってしまう。
【０１１２】
図３０は、ビデオの時間的遷移と、オーディオの時間的遷移とを対応付けて示す図である。第１段目は、previous PlayItemと、CurrentPlayItemとを連続させる場合のビデオストリームの時間的遷移を示し、第２段目は、previous PlayItemと、Current PlayItemとを連続させる場合のオーディオストリームの時間的遷移を示す。この第１段目における時間的遷移は、基本的には、図２６のものをベースにしているが、その表記を一部変更している。つまり、t_in_startは、V1_startと読み替えており、t_in_endは、V1_endと読み替えている。LastDTSは、V1_DTS1と読み替えている。First DTSは、V2_DTS1と読み替えている。
【０１１３】
この第２段目によると、オーディオストリームにおけるElementary Buffer の時間的遷移は、オーディオデータがElementary Buffer に供給されることによる単調増加と、ElementaryBuffer からオーディオデータが取り出されることによる単調減少とを繰り返していることがわかる。この第２段目のうち、オーディオデータの転送が終了する時刻を、A1_endとする。バッファサイズが小さく、フレーム間隔も細かいという特性により、オーディオデータの転送終了(A1_end)は、V1_endからかなり遅れていることがわかる。オーディオデータのバッファへの転送終了時刻は遅れるため、CurrentPlayItemによるビデオデータの転送開始が、かなり遅れることになる。
【０１１４】
ここで、Current PlayItemによる最初のデコード時刻をV2_DTS1とする。また、Current PlayItemによるバッファへの転送開始時刻をV2_startとする。これらを用いると、CurrentPlayItemにおいて、バッファへの転送を開始してから、デコードが終了するまでのバッファリング時間(vbv_delayと呼ばれる)は、以下の数式で与えられる。
vbv_delay = 先頭デコード時刻(V2_DTS1) - バッファへの転送開始時刻(V2_start)
つまり、オーディオデータの転送終了が遅れることで、Current PlayItemにおけるビデオ転送のvbv_delayの値が引きずられる形で小さくなってしまうのである。
そこで、Audioの属性と、トランスポートストリーム(TS)化のオーバヘッド等を元に、Vbv_delayを算出し、その値をを用いて、接続先ビデオ(ここでは、CurrentPlayItemにより再生されるAVClip＃1の先端部分)のエンコードを行う。
【０１１５】
以下、Vbv_delayの計算方法について解説する。
（１）. Audioの転送遅延を求める。図３０の第２段目におけるAdelayは、この転送遅延を具体的に示したものである。
Audioの転送Bitrate(bps)     ：Abitrate
Audioのバッファサイズ(bits) ： Abufsize
Audioデータをバッファに蓄積できる時間(sec): Adelay = Abufsize   / Abitrate
この図３０の第２段目に示すように、求めるべきVBV_delayは、かかるAdelayから、以下に求めるVframe,Aoverlapを引いた値となる。
【０１１６】
（２）. TS化のオーバヘッドを求める
・ Clip＃1は6KB Alignmentの制約がある。
これは、Clip＃1の終端に最大(6KB/192)*188のNullパケットを入れる必要があるからである。
・Clip＃2の先頭は、4*188byteのシステムパケットが必要となる。
TSOverhead = ( 6*1024/192*188 + 4*188 ) / Ts_recording_rate 
= 36*188 / Ts_recording_rate
（３）Audioのオーバラップ区間を求める。図３０の第２段目における“Aoverlap”は、このオーバラップ区間を示している。ここで、ワーストケースを見積もると、Audioのワーストオーバラップ区間は1frameとなる。よって、ワーストオーバラップ区間は以下の計算により求められる。
【０１１７】
Aoverlap = サンプル数 /  サンプリング周波数
（４）Videoの先頭DTSと、PTSの差Vpts1-dts1を求める。これは、ビデオの１フレーム間隔となり、ビデオのフレームレートにより決定される。図３０の第２段目におけるVframeは、このVpts1-dts1の具体的な値を示している。
Vpts1-dts1= 1 / ビデオフレームレート
上述したように、求めるべきVBV_delayは、かかるAdelayから、以下に求めるVframe,Aoverlapを引いた値なので、以下の数式から、VBV_delayを計算することができる。
【０１１８】
VBV_delay = Adelay - TSOverhead  - Aoverlap - Vpts1-dts1を求める。
ただし、TSに含まれるAudioが複数ある場合は、上記値の最も小さい値を適用する。
AVClipに以下の2つのビットレートを有するオーディオストリーム(Audio1,Audio2)が多重化されていて、これのオーディオストリームが以下のようなものである場合、vbv_delayがどれだけになるかを計算してみる。
Audio1 = AC3：448kbps, サンプリング周波数=48KHZ, サンプル数=1536
Audio2 = DTS:1509kbps, サンプリング周波数=48KHZ, サンプル数=512
Ts_recording_rate = 48Mpbs
VideoFrameRate = 24Hz
1. まず始めに、Audio1のVBV_delayは、以下の通りとなる。
Adelay   = 18640*8 / 448000 = 0.3328
TSOverhead = 36*188 / 6000000 = 0.0012
Aoverlap = 1538/48000 = 0.0320
Vpts1-dts1 = 1/24 = 0.0416
VBV_Delay = 0.3328 - 0.0012 - 0.0320 - 0.0416 = 0.2580
2. またAudio2のVBV_delayは、以下の通りとなる。
Adelay   = 43972*8 / 1509000 = 0.2331
TSOverhead = 36*188 / 6000000 = 0.0012
Aoverlap = 1538/48000 = 0.0106
Vpts1-dts1 = 1/24 = 0.0416
VBV_Delay = 0.233 - 0.0012 - 0.0106 - 0.0416 = 0.1796
Audio2のVBV_delayの方が小さいため、符号化にあたっては、Audio2のVBV_Delayを採用する。
このようにvbv_delayが算出されれば、V2_DTS1から、vbv_delayを引いた時刻(V2_DTS1−vbv_delay)を指し示すよう、ビデオデータを格納したTSパケット、及びオーディオデータを格納したTSパケットにATSを付すことでSourceパケットを得る。こうすることで、previousPlayItemによるAVClip再生と、Current PlayItemによるAVClip再生とをシームレスに行うことが可能になる。
ビデオストリームに割り当てることができる符号量は、vbv_delayと、Elementary Buffer の入力レートとに依存するので、vbv_delayが短いと、ビデオストリームに対する割り当て符号量を、低い値に変更にする必要がある。図３１は、割当符号量変更前の、ビデオストリーム用ElementaryBuffer における時間的遷移と、割当符号量変更後の、ビデオストリーム用Elementary Buffer における時間的遷移とを対比して示す図である。ビデオがデコードされる時点や、ビデオ、オーディオが再生される時点の間隔(ノコギリ波形の個々の間隔や階段波形の個々の間隔)は、本来、一定間隔であるが、本図では、作図の都合上、これらの間隔は必ずしも、一定にはなっていないことは予め留意されたい。破線の時間的遷移が、割当符号量変更前の時間的遷移であり、実線の時間的遷移が、割当符号量変更後の時間的遷移である。破線の時間的遷移は、図２９に示したものと同じである。
【０１１９】
vbv_delayを小さくしたため、割当符号量変更の時間的遷移は、総じて縮小化されていることがわかる。このようにビデオストリームのエンコードにあたっては、ElementaryBuffer に対するオーディオ入力を考慮して、vbv_delayの調整を行い、これに基づき割当符号量を変化させるので、複数のPlayItem情報で、1つのAVClipを繰り返しデコーダに投入したとしても、当該デコーダにおけるElementaryBuffer が破綻することはない。
【０１２０】
この図２６から図３１までの説明において、仮の符号量でビデオストリームをエンコードしてみるという第１のパスと、vbv_delayから符号量を算出しなおすという第２のパスとが実行されている。つまり、“ツーパスエンコード”が実現されていることがわかる。第１パスの実行後、ビデオストリームとオーディオストリームとを共にElementaryBuffer に読み出すためのvbv_delayを求め、このvbv_delayに基づき、ビデオストリームに割り当てるべき符号量が第２パスで算出されるので、999個のPlayItem情報から同じ動画メニュー用AVClipが繰り返し再生される場合であっても、再生装置におけるバッファモデルを破綻させることはない。こうすることで、999個のPlayItem情報により、AVClipの再生をシームレスに繰り返すという、動画メニュー特有の再生処理を実現することができる。
【０１２１】
図３２は、動画メニューの具体例を示す図である。本図において第１段目は、PlayList全体の時間軸を示し、第２段目は、メニュー用AVClipにて再生される複数のピクチャを示す。第３段目は、PlayList情報を構成する、999個のPlayItem情報のうち、先頭の３つ(PlayItem情報＃1,＃2,＃3)を示す。本図によると、PlayList全体の時間軸において、00:00から01:00まで、01:00から02:00まで、02:00以降は、同じ絵柄(Pleaseselect!!、Title＃1、Title＃2の選択を受け付けるボタン、These Title are Playable)が繰り返し表示されていることがわかる。
【０１２２】
これらの繰り返しは、PlayList情報内に存在するPlayItem情報によるものである。個々のPlayItem情報の接続状態は、connection_condition情報によりconnection_condition＝5と規定されているので、第２段目におけるピクチャ再生は、途切れることなくなされる。  
以上のように本実施形態によれば、1つのPlayList情報内に、999個のPlayItem情報を設け、これらのPlayItem情報間の接続状態をconnection_condition＝5と規定するので、たとえ、デジタルストリームの再生を命じるコマンドと、当該コマンドの実行を反復させるジャンプコマンドとの間では、動画像の静止やボタン、字幕の消去が発生するとしても、999個のPlayItem情報が再生されている間は、動画像の静止やボタン、字幕の消去が生じることはない。999分=１６.５時間ものの間、動画メニューの再生途切れが発生しないので、デジタルストリームの時間長が１分程度であっても、ジャンプコマンドを実行して、再生コマンドの実行を反復することによる再生の途切れは、１６.５時間のうち、１回となり、再生の途切れがない入力待ちを、長い時間継続することができる。
【０１２３】
また、この継続には、記録媒体の容量を多く費やすることもないので、記録媒体の容量を大きく確保したまま、途切れのない動画メニューを実現したいという、現実的な要請に応えることができる。
(第２実施形態)
第１実施形態での図１７ではAVClipを一つだけ用意したが、本実施形態は、2つのAVClipを用意してそれを繰り返し再生するようにPlayItem情報を構成する実施形態である。図３３は、第２実施形態に係る動画メニューの構成を示す図である。第１段目は、動画メニュー用AVClipを構成する2つのAVClip＃1,＃2を示す。第２段目は、PlayList情報を示す。このPlayList情報には、第１実施形態同様、999個のPlayItem情報が存在する。これら999個のPlayItem情報のうち、奇数番目のPlayItem情報(PlayItem情報＃1,＃3,＃5)にはAVClip＃1が設定され、偶数番目のPlayItem情報(PlayItem情報＃2,＃4,＃6)には、AVClip＃2が設定されている。
【０１２４】
このように設定することで、AVClipの構成に汎用性を持たせることができ、コンテンツメーカーの意図通りにAVClipの構成を変えることが可能である。例えば、図３３では、AVClip＃1＝＞AVClip＃2＝＞AVClip＃1＝＞AVClip＃2というように、単純なAVClipのループ再生だけではなく、AVClipの再生内容を組み合わせることが可能となる。
(第３実施形態)
第１実施形態の図１７ではAVClipを一つだけ用意したが、本実施形態は、3つのAVClipを用意してこれらでマルチアングル区間を構成することにより、動画メニューを構成する実施形態である。
【０１２５】
図３４は、マルチアングル区間を構成する3つのAVClip(AVClip＃1、AVClip＃2、AVClip＃3)を示す図である。第１段目は、かかる3つのAVClip(AVClip＃1、AVClip＃2、AVClip＃3)を示し、第２段目は、BD-ROMにおけるエクステントの配置を示す。第１段目によると、AVClip＃1は3つのエクステントA0,A1,A2、AVClip＃2は3つのエクステントB0,B1,B2、AVClip＃3は3つのエクステントC0,C1,C2から構成されているが、これらのエクステントは、第２段目に示すように、A0→B0→C0→A1→B1→C1→A2→B2→C2というように、BD-ROM上で交互に配置されていることがわかる。
【０１２６】
マルチアングル区間を構成するAVClipのエクステントは、マルチアングル区間の先頭のAVClipのエクステントの先頭にシームレスに接続できるように、エクステントのサイズやジャンプ距離を調整しながらディスク上に配置されている。
例えば、図３４でいえば、AVClip＃1、AVClip＃2、AVClip＃3のそれぞれの終端エクステントA2、B2、C2は、AVClip＃1、AVClip＃2、AVClip＃3のそれぞれの先頭エクステントA０、B０、C０の何れにジャンプすることができるよう、配置及びサイズが決定されている。具体的には、終端エクステントと、先端エクステントとのすべての組み合わせを求め、どの組合せであっても、最大ジャンプ距離を越えないように配置され、各エクステントの大きさが第１実施形態で述べた最小エクステントサイズ以上に設定されている。
【０１２７】
図３５は、マルチアングル区間を用いて動画メニューを構成するPlayList情報の構成を示す図である。本図におけるPlayList情報は、第１実施形態に示したものと同様、999個のPlayItem情報を有する。第１段目は、これらのPlayItem情報のうち、先頭の2つのもの(PlayItem＃1,＃2)の構成を示す。第１実施形態で述べたように、PlayItem情報は、In_Time、Out_Timeの設定先となるAVClipを示すClip_Information_file_nameを有する。このClip_Information_file_nameにて、PlayItem情報が対応するAVClipを一意に指定することができる。このClip_Information_file_name以外にも、PlayItem情報はMulti_clip_entriesを有している。このMulti_clip_entries内のClip_Information_file_nameを記述することで、マルチアングル区間を構成する他のAVClipを指定することができる。図中のPlayItem情報では、Multi_clip_entries内のClip_Information_file_nameが、AVClip＃2、AVClip＃3を指定しており、Multi_clip_entries外のClip_Information_file_nameは、AVClip＃1を指定している。これらのマルチアングル区間は、いくつかのAVClipで構成され、例えばAVClipがそれぞれのメニュー映像を示している。これらマルチアングル区間を構成する個々のAVClipが、IGストリームを有している場合、ユーザは、リモコンに対するアングル切り替え操作にて、これら3つのAVClip内のIGストリームを選択的に再生することで、シームレスな動画メニューの切り替えを実現することができる。
【０１２８】
(第４実施形態)
本実施形態では、本発明にかかる記録装置を実施するための形態について説明する。
ここで説明する記録装置は、オーサリング装置と呼ばれるものであり、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームイメージを生成するというのが、本発明にかかる記録装置の使用形態である。
【０１２９】
図３６は、本発明にかかる記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、１）タイトル構造作成部１０、２）BDシナリオ生成部１１、３）リールセット編集部１６、４）ＪＡＶＡ（登録商標）プログラミング部２０、５)素材作成/インポート部３０、５)素材作成/インポート部３０、６）ディスク作成部４０、７)検証５０、８）マスター作成６０から構成される。
【０１３０】
従来のオーサリングのための記録装置の場合、ＪＡＶＡ（登録商標）プログラムの編集を行う部分とAVClipやシナリオの作成を行う部分を並列的に実行できないという課題があった。そこで、本発明にかかる記録装置では、そうした課題を鑑み、ＪＡＶＡ（登録商標）プログラムの作成手段とシナリオ作成手段を分離できるような構成が採用されている。その内容についても下記で明らかにしていく。
１）タイトル構造作成部１０
タイトル構造作成部１０は、Index.bdmvで示される各タイトルがどのようなコンテンツで構成されるかを決定する。BD-ROMのディスク作成を行う際には、必ずこの構成要素を使ってタイトル構造を定義する。ここで作成されるタイトル構造は、リールセット編集部１６、BDシナリオ生成部１１、ＪＡＶＡ（登録商標）プログラミング部２０、素材作成/インポート部３０で利用される。タイトル構造の定義をオーサリングの最初のステップで実行することによって、リールセット編集部１６、BDシナリオ生成部１１、ＪＡＶＡ（登録商標）プログラミング部２０、素材作成/インポート部３０を利用する作業を並列的に実行できる。並列的に処理を実行する仕組みについては、後述の説明によって明らかにする。
図３７は、タイトル構造作成部１０で作成されるタイトル構造情報のデータ構造の例を示している。タイトル構造情報はツリー構造を持ち、ツリー構造のトップ項目のディスク名ノード[DiscXX]は、ディスクを識別する名前を示し、「タイトルリスト」ノード、「「プレイリストリスト」のノード、「BD-J Objectリスト」のノードと接続している。
【０１３１】
「タイトルリスト」のノードは、Index.bdmvの原型であり、その配下には、「FirstPlay」のノード,「TopMenu」のノード,「Title＃1」のノード,「Title＃2」のノードが存在する。これらは、BD-ROMに収録されるタイトルに対応するノード、つまりタイトルノードであり、個々のノードは、最終的にindex.bdmvで示される各タイトルに対応している。これらのノードに付されたタイトル名“FirstPlay,TopMenu,Title＃1,Title＃2”は、予約語である。
【０１３２】
タイトルノードの配下には、Play MainPlaylistのノード、Play MenuPlaylistのノード、Ｊａｖａ（登録商標） MainＪａｖａ（登録商標）Objectのノード、PlayMainPlayListのノードが存在する。これらは、各タイトルがどのような動作するかを定義するものであり、”Play”のようなコマンド名、”Ｊａｖａ（登録商標）”のようなメソッド名と、引数にあたるターゲットとを持つ。
【０１３３】
コマンドが”Play”の場合は、引数の内容は、そのタイトルから再生されるプレイリストの名前を示している。各プレイリストの名前によって示されるプレイリストについては、「プレイリストリスト」のノードの下に定義される。また、コマンドが”Ｊａｖａ（登録商標）”の場合は、引数の内容は、そのタイトルから実行されるBD-JObjectを示している。各BD-J Objectの名前によって示されるBD-J Objectについては、BD-J Objectリストのノードの下に定義される。
【０１３４】
「プレイリストリスト」のノードの配下には、MenuPlayListのノード、MainPlayListのノードが存在する。これらは、プレイリストのノードであり、MenuPlayList,MainPlayListという予約語で命名されている。MenuPlayListのノード、MainPlayListのノードの配下には、ファイル名「00001」のノード、ファイル名「00002」のノードが存在する。これらは、プレイリストファイルのノードである。図中では、これらのプレイリストファイルの名前には、00001,00002というファイル名、つまり、BD-ROMに格納するにあたっての、具体的なファイル名が与えられている。尚、PlayList情報は、タイトル構造作成部１０で設定されず、BDシナリオ生成部１１によって設定される。
【０１３５】
BD-J Objectリストのノードの配下には、MainＪａｖａ（登録商標）Objectのノードが存在する。本ノードには、MainＪａｖａ（登録商標）Objectという予約語が命名されている。MainＪａｖａ（登録商標）Objectのノードの配下には、ファイル名00001のノードが存在する。このノードは、BD-J Objectファイルのノードであり、BD-ROMに格納するにあたっての具体的なファイル名 00001が与えられる。尚、BD-JObjectは、タイトル構造作成部１０では設定されず、ＪＡＶＡ（登録商標）インポート部３５によって設定される。
２）BDシナリオ生成部１１
BDシナリオ生成部１１は、タイトル構造作成部１０によって作成されたタイトル構造情報を利用し、またオーサリングスタッフからのGUIを経由した操作に従ってシナリオを作成し出力する。ここでシナリオとは、デジタルストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、これまでの実施形態で述べたIndexTable、MovieObject、PlayListとして定義されている情報がシナリオにあたる。BD-ROMシナリオデータは、ストリームを構成する素材情報、再生経路情報、メニュー画面配置、メニューの遷移条件情報などを含む。また、BDシナリオ生成部１１が出力するBD-ROMシナリオデータは、後に説明するマルチプレクサ４５での多重化を実現するためのパラメータ等をも含む。ここでBDシナリオ生成部１１は、GUI部１２と、メニュー編集部１３と、PlayList生成部１４と、MovieObject生成部１５とから構成される。
【０１３６】
＜GUI部１２＞
GUI部１２は、BDシナリオを編集するための操作を受け付ける。図３８は、メニュー画面構成の設定時のGUI画面の例を記したものである。本図におけるGUIは、画面構成設定ペイン２５０１と、動画プロパティペイン２５０２から構成されている。
画面構成設定ペイン２５０１は、メニューのボタンイメージの配置や構成を設定する操作をオーサリングスタッフから受け付けためのGUI部品である。例えば、オーサリングスタッフはボタンの静止画イメージを読み込み、静止画イメージを、この画面構成設定ペイン２５０１上で表示させて、ドラッグ・ドロップ操作を実行することで、どのような位置に配置するかを設定できる。
【０１３７】
動画プロパティペイン２５０２は、メニューの背景に利用する動画のリールセットファイルの設定を受け付ける。具体的には、リールセットファイルのパス名「data/menu/maru/maru.reelset」と、シームレスにするか否かを受け付けるチェックボックスとを含む。
ボタン遷移条件ペイン２５０３は、各ボタン毎に生成され、リモコンの十字キーにおける方向と、各方向が指定された場合の、遷移先ボタンとを表示して、リモコンの十字キーで遷移方向が指定されたときのボタンの遷移先を、オーサリングスタッフに設定させる。例えば、先に述べた図の具体例では、Title＃1の選択を受け付けるボタン(Title＃1ボタン)と、Title＃2の選択を受け付けるボタン(Title＃2ボタン)とがピクチャに合成されている。図のGUIの一例では、これのボタン毎に、ボタン遷移条件ペイン２５０３が生成される。Title＃1ボタンのボタン遷移条件ペイン２５０３では、右方向の押下時に、Title＃2ボタンに遷移するよう遷移条件が規定されていて、左方向の押下時にも、Title＃2ボタンに遷移するよう遷移条件が規定されている。
【０１３８】
Title＃2ボタンのボタン遷移条件ペイン２５０３では、右方向の押下時に、Title＃1ボタンに遷移するよう遷移条件が規定されていて、左方向の押下時にも、Title＃1ボタンに遷移するよう遷移条件が規定されている。
＜メニュー編集部１３＞
メニュー編集部１３は、オーサリングスタッフからのGUI部１２を経由した操作に従って、IGストリームを構成するボタンの配置や、ボタンの確定時に実行されるナビゲーションコマンド、ボタンアニメーションなどの機能を作成する。
【０１３９】
前述したシームレス動画メニューのデータ構造のシナリオを作成するにあたって、ニュー編集部１３は、メニューの背景映像としてシームレスに再生したい映像の選択を受け付ける。
＜PlayList生成部１４＞
PlayList生成部１４は、タイトル構造情報のプレイリストリストの内容を設定した上で、GUI部１２が受け付けたユーザ操作に基づき、999個のPlayItem情報からなるプレイアイテムシーケンスを有するPlayList情報を生成する。この際、PlayList生成部１４は、シームレス動画メニューのデータ構造にあうようにプレイリストを作成する。この作成にあたってPlayList生成部１４は、AVClipの数に合うようにPlayItem情報の個数を調整し、PlayItem情報におけるConnectioin_condition情報を設定する。具体的にいうと、PlayItem情報の個数を999個とし、１のPlayItem情報によるAVClipの再生と、直前のPlayItem情報によるAVClipの再生とを、シームレスに行わせる旨(CC=5)を、各PlayItem情報におけるConnectioin_condition情報に示させる。このようなconnection_condition情報の設定に伴い、マルチプレクサ４５で多重化を実現するパラメータとして、AVClip接続情報を生成する。各AVClip接続情報は、対応するAVClipを構成する個々のAVClipに対応するノードをもち、そのノードについて、Prev項目、Next項目を有する構造になっている。AVClip接続情報における各ノードは、プレイリスト情報に含まれるPlayItem情報にて、連続的に再生される、一群のAVClipのそれぞれを象徴的に表している。これらのノードは、詳細項目としてPrev項目,Next項目をもつ。
【０１４０】
図３９は、図３２に示した3つのAVClipを作成するにあたってのAVClip接続情報の記述を示す図である。これまでに述べたように、AVClip＃1は、動画メニュー用AVClipを構成するものなので、Prev項目、Next項目には、AVClip＃1が設定されている。一方、AVClip＃2、AVClip＃3は、通常の映画作品を構成するものなので、AVClip＃2のPrev項目は無指定「--」、Next項目はAVClip＃3と記述され、AVClip＃3のPrev項目はAVClip＃2、Next項目は、無指定「--」と記述されている。各AVClip接続情報は、プレイリストにて参照される一連のAVClip列毎に作成される。
【０１４１】
オーサリングスタッフが動画プロパティペイン２５０２のチェックボックスにチェックを行うと、AVClip接続情報におけるNext項目、Prev項目は、シームレスに接続するAVClipとして自分自身をさすように設定される。つまりシームレス接続ノードのPrevの項目、Nextの項目ともに自分自身であるAVClip＃１を設定する。このように設定することで、シームレス動画メニューのための多重化処理をマルチプレクサー４５に行わせることが出来る。
＜Movie Object生成部１５＞
Movie Object生成部１５は、オーサリングスタッフによるプログラム記述を受け付けることで、Movie Objectを生成する。かかるプログラム記述は、BD-ROM規格に規定されているナビゲーションコマンドを、オーサリングスタッフが記述することでなされる。特にMovieObject生成部１５は、PlayPLコマンドの実行を反復させるJumpコマンドを、BD-JObject内に記述することで、ユーザからの操作待ちの制御を、再生装置に行わせる。
３）リールセット編集部１６
リールセット編集部１６は、ユーザ操作に基づき、リールセットの設定を行う。リールセットとは、ビデオ、オーディオ、字幕、ボタンなど映画として完結する複数のエレメンタリーストリームの関係を表す情報の集合である。このリールセットを定義することで、１本の映画が1本のビデオ、２本のオーディオ、３本の字幕、１本のボタンストリームから成る場合に、それらが一本の映画を構成することを指定することができる。またHDMI送受信部１６は、映画本編に対して、一部分だけ映像が異なるようなディレクターズカットを指定したり、複数のアングルを持つマルチアングルを設定したりする機能を有する。リールセット編集部１６から出力されるリールセットファイルとは、前述のような情報をまとめたものである。
４）ＪＡＶＡ（登録商標）プログラミング部２０
ＪＡＶＡ（登録商標）プログラミング部２０はIDクラス作成部２１と、ＪＡＶＡ（登録商標）プログラム編集部２２、BD-J Object作成部２３から構成される。
【０１４２】
＜IDクラス作成部２１＞
IDクラス作成部２１は、タイトル構造作成部１０によって作成されたタイトル構造情報を利用しIDクラスソースコードを作成する。IDクラスソースコードは、ＪＡＶＡ（登録商標）プログラムが最終的にディスク上に作成されるIndex.bdmvやPlayList情報にアクセスするためのＪＡＶＡ（登録商標）クラスライブラリのソースコードである。このIDクラスソースコードをコンパイルによって得られるＪＡＶＡ（登録商標）クラスライブラリをIDクラスライブラリと呼ぶことにする。図４０（ａ）は、IDクラスソースコードのプレイリストにアクセスするためのヘッダファイルのソースコードの例を図示したものである。図４０（ａ）のclassPlayListIDは、プレイリスト番号を指定することでディスクから所定のプレイリストファイルを読み込むコンストラクタをもち、このコンストラクタを実行して作成したインスタンスを利用することでAVClipの再生等が実行可能なように設計、実装されている。図４０（ａ）のMainPlaylist,MenuPlaylistのように、IDクラス作成部２１は、タイトル構造情報で定義されるプレイリストノードの名前を利用して、IDクラスライブラリの変数名を定義する。このとき指定するプレイリスト番号は、ダミーの番号を設定しておく。このプレイリスト番号を正しい値への変換は、後述するID変換部４１で行われる。
＜ＪＡＶＡ（登録商標）プログラム編集部２２＞
ＪＡＶＡ（登録商標）プログラム編集部２２は、テキストエディタのようなキーボード入力によってＪＡＶＡ（登録商標）プログラムのソースコードを直接編集することで、ＪＡＶＡ（登録商標）プログラムのソースコードを作成し、ＪＡＶＡ（登録商標）プログラムソースコードを出力する。このとき、ＪＡＶＡ（登録商標）プログラム編集部２２によって作成されるＪＡＶＡ（登録商標）プログラムのうち、BDシナリオ生成部１１で定義される情報をアクセスするメソッド部分の記述には、IDクラスライブラリが用いられる。例えば、図４０（ａ）のIDクラスライブラリを利用して、プレイリストにアクセスする場合、ＪＡＶＡ（登録商標）プログラムは、IDクラスライブラリで定義される変数であるMainPlaylist,MenuPlaylistを利用する。また、ＪＡＶＡ（登録商標）プログラムソースコードから利用されるフォントファイルや静止画、オーディオ等の情報は、プログラム付属情報として出力される。ＪＡＶＡ（登録商標）プログラム編集部２２は、あらかじめＪＡＶＡ（登録商標）プログラムのテンプレートが用意されていて、オーサリングスタッフがGUI等を通じてプログラムを作成する手段であってもよく、ＪＡＶＡ（登録商標）プログラムソースコードを作成できる手段であれば形態は問わない。
【０１４３】
＜BD-J Object作成部２３＞
BD-J Object作成部２３は、ＪＡＶＡ（登録商標）プログラム編集部２２で作成したＪＡＶＡ（登録商標）プログラムソースコードとIDクラス作成部２１によって作成したIDクラスソースコードを元に、BD-ROMで定義されるBD-JObjectのデータフォーマットを作成するためのBD-J Objectを作成する。BD-J Objectでは、実行するＪＡＶＡ（登録商標）プログラムから再生されるプレイリスト名を指定する必要があるが、この時点では、IDクラスソースコードを元に、IDクラスライブラリで定義される変数名を設定する。
５)素材作成/インポート部３０
素材作成/インポート部３０は、字幕作成部３１、オーディオインポート部３２、ビデオインポート部３３、ＪＡＶＡ（登録商標）インポート部３５から構成される。入力されるビデオ素材、オーディオ素材、字幕用素材、ＪＡＶＡ（登録商標）プログラムソースコード等を、BD-ROM規格に準拠したビデオストリーム、オーディオストリーム、字幕データ、ＪＡＶＡ（登録商標）プログラムソースコード等に変換し、ディスク作成部４０に受け渡す。
＜字幕作成部３１＞
字幕作成部３１は、字幕と表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠した字幕データを生成して出力する。
＜オーディオインポート部３２＞
オーディオインポート部３２では、あらかじめMPEG-AC3などで圧縮されているオーディオが入力された場合には、対応するビデオに対するタイミング情報などを付加したり、余分なデータを削除したりして出力し、圧縮されていない場合には、オーサリングスタッフが指定するフォーマットに変換して出力する。
＜ビデオインポート部３３＞
ビデオインポート部３３は、あらかじめ圧縮されていない非圧縮ビデオファイルが入力された場合には、かかるビデオファイルをビデオエンコーダにインポートする。あらかじめMPEG２、MPEG４-AVC、VC１などの方式で圧縮されているビデオストリームが入力された場合、必要に応じて不必要な情報を削除するなどしてから出力する。
＜ビデオエンコーダ３４＞
ビデオエンコーダ３４は、オーサリングスタッフが指定するパラメーターに従って、割当符号量の算出を行い、入力されたビデオファイルの圧縮を行って、その結果得られた、圧縮後の符号化系列をビデオストリームとして出力する。動画メニュー用AVClipを構成する場合、ビデオエンコーダ３４は、ビデオストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファ容量に基づき、入力制限直線やvbv_delayを導き出す。この導出の過程は、第１実施形態で述べたようなツーパスエンコードの過程であり、図２６から図３４に示した通りである。そして、こうして導出された入力制限直線やvbv_delayに基づき、AVClipの先端部分に対する割当符号量を決定する。割当符号量を定めた後、エンコードを行う。
＜ＪＡＶＡ（登録商標）インポート部３５＞
ＪＡＶＡ（登録商標）インポート部３５は、ＪＡＶＡ（登録商標）プログラム作成部２０によって作成されたＪＡＶＡ（登録商標）プログラムソースコード、プログラム付属情報、IDクラスソースコード、BD-JObject生成情報をディスク作成部４０に受け渡す。ＪＡＶＡ（登録商標）インポート部３５は、タイトル構造情報を利用し、インポートするＪＡＶＡ（登録商標）プログラムソースコード、プログラム付属情報、IDクラスソースコード、BD-JObject生成情報を構成するファイル群がどのBD-J Objectに対応するのかの関連付けを行い、タイトル構造情報のBD-J ObjectノードのBD-JObject情報を生成する。
６）ディスク作成部４０
ディスク作成部４０は、ID変換部４１、静止画エンコーダー４２、データベース生成部４３、ＪＡＶＡ（登録商標）プログラムビルド部４４、マルチプレクサー４５、フォーマット部４６、ディスクイメージ作成部４７から構成される。
【０１４４】
データベースとは、前述のBD-ROMで定義されるIndex.bdmv、プレイリスト、BD-J Objectなどの総称のことで、ディスク生成部４０は、入力されたBD-ROMシナリオデータ、ID変換部４１から渡されるBD-JObject情報を元にして、BD-ROMに準拠したシナリオデータを生成する。
＜ID変換部４１＞
ID変換部４１は、ＪＡＶＡ（登録商標）インポート部３５によって、ディスク作成部４０に渡されたIDクラスソースコードを、実際のディスク上のタイトル番号、プレイリスト番号と一致するように、変換する。例えば、図４０で言えば、MenuPlaylist、MainPlaylistを作成するために指定するプレイリスト番号を自動的に変更する。この変換は、タイトル構造情報のプレイリストノードを参照してなされる。図４０（ａ）において、MenuPlaylistとMainPlaylistの最終的なファイル名は、それぞれ00001、00002になるので、図４０（ｂ）のように変更されることとなる。また、ID変換部４１は、BD-JObject情報についても同様に変換処理を行う。BD-J Object内で定義されるプレイリスト名を、実際のディスク上のプレイリスト番号と一致するように、変換処理を行う。変換方法については、上記IDクラスソースコードと同じであり、変換されたBD-JObject情報はデータベース生成手段に渡される。
【０１４５】
＜静止画エンコーダ４２＞
静止画エンコーダ４２は、入力されたBD-ROMシナリオデータに静止画または静止画が保持されている場所が含まれる場合に、入力素材に含まれる静止画用イメージの中から該当する静止画を選択し、BD-ROMに準拠したMPEG２、MPEG４-AVC、VC１のいずれかの形式に変換する。
＜ＪＡＶＡ（登録商標）プログラムビルド部４４＞
ＪＡＶＡ（登録商標）プログラムビルド部４４は、ID変換部４１によって変換されたIDクラスソースコードとＪＡＶＡ（登録商標）プログラムソースコードに対してコンパイル処理を行い、ＪＡＶＡ（登録商標）プログラムを出力する。
＜マルチプレクサ４５＞
マルチプレクサ４５は、BD-ROMシナリオデータに記述されているビデオ、オーディオ、字幕、ボタンなどの複数のエレメンタリーストリームを多重化して、MPEG２-TS形式のAVClipを得る。マルチプレクサー４５は、多重化パラメータを元にどのAVClipがどのAVClipに接続するかの情報を取得する。
【０１４６】
また、マルチプレクサー４５は、上述したようなAVClipを出力すると同時に、AVClipに関する情報を持つClip情報を出力する。Clip情報は、個々のAVClip毎に設けられた管理情報、つまり、デジタルストリームの管理情報であり、EP_mapと、AVClipの符号化情報とを含み、データベースの一つである。マルチプレクサー４５によるClip情報の生成は、以下の手順で行われる。マルチプレクサ４５では、新たにAVClipが作成されるのと同時に、EP_mapを作成する。より具体的には、BD-ROM向けに生成されたデジタルストリームにおいて、含まれるビデオエレメンタリーストリームがMPEG２であればIPicture、MPEG４-AVCであればI PictureかIDR Picture、VC-1であればI Pictureが何処に存在するかを検出し、前述の各Pictureの表示時刻と、MEPG２-TSとなっているAVClipの何パケット目のTSパケットに前述の各Pictureの先頭データが入っているかを対応付けた情報である。マルチプレクサ４５は、自ら生成したEP_mapと、リールセットファイルから検出されるデジタルストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてClip情報を作成する。
【０１４７】
EP_Mapをマルチプレクサ４５で作成する理由は、EP_Mapは、マルチプレクサーから出力されるMPEG２-TS形式のAVClipに非常に密接に関係している情報であり、また、BD-ROMでの使用のために作成されるAVClipは、ファイルサイズが非常に大きくなる可能性があるので、もしAVClipを作成後に、EP_Mapを作成しようとすると、大きなファイルサイズのAVClipを再度読み直す必要があるために、EP_Map作成に要する時間が必要となる。これに対して、AVClipを作成しながらEP_Mapを作成すれば、巨大なAVClipファイルを2度に渡って読み直す必要がないため、EP_Map作成のための時間を節減できる。
【０１４８】
また、マルチプレクサ４５は、BD-ROMシナリオデータに含まれるマルチプレクサ４５のためのパラメータを利用し、多重化の方法を変える。例えば、多重化する対象となるpreviousPlayItemにて参照されるAVClipが、Current PlayItemにて参照されるAVClipとシームレスに接続するようにパラメータが設定されている場合は、前述したようにバッファモデルを破綻させないように、previousPlayItemにて参照されるAVClipをデコードした後のバッファ状態を初期値として、CurrentPlayItemにて参照されるAVClipの多重化を行う。一つのAVClipを999個のPlayItem情報から参照して再生に供する場合、個々のPlayItem間の接続をシームレスを行うためのAVClipの多重化を行う。
【０１４９】
この多重化は前述したように、previousPlayItemにおけるAVClipの、Elementary Buffer への転送が完了したときのバッファの状態を初期状態として、CurrentPlayItemにおいて、再度同じAVClipをElementary Buffer に読み込もうとした場合、Elementary Buffer の初期状態に影響されることなく、当該読み込みがなされるよう、AVClipを構成する、個々のSourceパケットに付されるべき、ATSの値を調整することでなされる。
【０１５０】
＜フォーマット部４６＞
フォーマット部４６は、前述のデータベース、AVClip、ＪＡＶＡ（登録商標）プログラムを入力とし、BD-ROMフォーマットに適合したデータ構造で、ファイルの配置処理を行う。図２で定義されるディレクトリ構造を作成し、各ファイルを適切な箇所に配置する。この時、フォーマット部４６は、ＪＡＶＡ（登録商標）プログラムとAVClipの関連付けを行い、ファイル関連付け情報を作成する。
【０１５１】
図４１は、ファイル関連付け情報を示す図である。本図に示すように、ファイル関連付け情報は、1つ以上のブロックに対応するノードからなる。各ノードは、まとまって読み出されるべきファイルを指定することができ、またファイルをシームレスに読み出すかどうかを規定するSeamlessFlagを有している。図４１におけるファイル関連付け情報の具体例は、図２のファイルを読み出させることを想定する。図中のBlock＃nに対応するノードは、ひとまとまりに読み出されるファイルとして、00001.bdjo、00001.mpls、00001.jar、00001.clpi、00001.m2tsを指定している。
【０１５２】
図中のBlock＃n+1に対応するノードは、ひとまとまりに読み出されるファイルとして、00002.mpls、00003.mpls、00002.clpi、00003.clpi、00002.m2ts、00003.m2tsを指定している。本図の例では、Block＃nは、BD-JObjectである、00001.bdjoが実行される際に必要なファイルをディスクから読み込まれる順にまとめられている。
＜ディスクイメージ作成部４７＞
ディスクイメージ作成部４７は、前述のデータベース、AVClipを入力とし、BD-ROMフォーマットに適合したアドレスに割り付けてボリュームイメージを得る。BD-ROMに適合したフォーマットについては図２を用いて前述により説明した。また、そのボリュームイメージを作る場合には、フォーマット部４６によってファイル関連付け情報が利用される。ディスクイメージ作成部４７は、各ブロックを先頭から配置するようにし、かつ各ブロック内のファイル群は物理的に連続になるように配置する。例えば図４１の例の場合、図４２のように配置される。
【０１５３】
図４２は、図４１のファイル関連付け情報に基づく、BD-ROM上のアロケーションを示す図である。本図に示すように、Block＃nに属する00001.bdjo、00001.mpls、00001.jar、00001.clpi、00001.m2tsは、BD-ROM上の連続した領域に配置される。また、本図に示すように、Block＃n+1に属する00002.mpls、00003.mpls、00002.clpi、00003.clpi、00002.m2ts、00003.m2tsはBD-ROM上の連続した領域に配置される。
【０１５４】
このように再生に必要なファイル群を物理的に連続になるように配置することによって、再生するときのディスクの読み出しを効率的に行うことが出来るようになる。また、図４１の一例では、Block＃n,＃n+1におけるシームレスフラグがOnになっている。この場合は、各AVClipをシームレスに配置するように、前述したシームレスに再生するための物理的な配置の条件である最小エクステントサイズや最大ジャンプ距離を条件に満たすように、BD-ROMにおけるAVClipの配置を決定する。任意的であるが、ファイル関連付け情報におけるブロックには、マルチアングルフラグを追加することができる。この場合、ディスクイメージ作成部４７は、各AVClipがオーサリングスタッフのアングル切り替えに応じてAVClipの切り替えが出来るように、AVClipをインターリーブしてディスク上に配置する。インターリーブとは、AVClipを適切な単位でエクステントに分割され、ディスク上に交互に配置されることであり、その例を図４３に示している。
７)検証装置５０
検証装置５０は、エミュレータ部５１と、ベリファイア部５２とからなる。
【０１５５】
＜エミュレータ部５１＞
エミュレータ部５１は、前述のボリュームイメージを入力として、実際の映画コンテンツを再生し、制作者が意図した通りの動作、例えばメニューから本編映画への遷移が正しく行われているか、字幕切り替えやオーディオ切り替えは意図したとおりに動作しているか、映像やオーディオの品質は意図したとおりにできているかなどを検証する。
【０１５６】
＜ベリファイア部５２＞
ベリファイア部５２は、前述のボリュームイメージを入力として、制作されたデータが、BD-ROMの規格に準拠しているかどうかを検証する。
このようにボリュームイメージはエミュレータ部５１、およびベリファイア部５２で検証され、エラーが発見されると、然るべき前工程に戻って作業をやり直す。
【０１５７】
８）マスター作成部６０
マスター作成部６０は、AVClip、PlayList情報、BD-JObjectを光ディスクに書き込む部材であり、上述したよう内部つの検証過程を経た後、BD-ROMプレス用データが完成させた上で、プレス工程を行うことで、BD-ROMの製造を行う。かかるプレス工程による光ディスクへの書き込みは一例に過ぎず、BD-REや、AVC-HDのような書き換え型の記録媒体に対しては、AVClip、PlayList情報、BD-JObjectをドライブ装置に引き渡すことで、書き込みに供してもよい。
【０１５８】
次に図４４を参照しながら、本実施の形態に係る本実施の形態に係る記録装置における、オーサリング手順について説明する。
ステップS1において、タイトル構造作成部１０は、ユーザ操作に基づき、BD-ROMのタイトル構造を作成してゆく。これによりタイトル構造情報が作成される。
ステップS２において、BDシナリオ生成部１１は、ユーザ操作に基づき、シームレス動画メニューの構成を持つシナリオデータの作成を行う。これにより、BD-ROMシナリオデータには、シームレス動画メニューのためのPlayList情報が作成される。
【０１５９】
ステップS３において、素材作成/インポート部３０は、オーサリングスタッフにより用意された動画、音声、静止画、字幕を、ディスク作成部４０にインポートする。
ステップＳ４は、タイトル構造情報にＪＡＶＡ（登録商標）タイトルが存在するかどうかを判定するステップである。存在する場合、ステップＳ２〜ステップＳ３と、ステップＳ５〜ステップＳ８とを並列に実行するが、存在しない場合、ステップＳ５〜ステップＳ８を実行せず、ステップＳ２〜ステップＳ３を実行した上、ステップＳ９に移行する。
【０１６０】
ステップS５において、ＪＡＶＡ（登録商標）プログラミング部２０は、ユーザ操作に基づき、ＪＡＶＡ（登録商標）タイトル用のＪＡＶＡ（登録商標）プログラムソースコード、プログラム付加情報、IDクラスソースコードを作成する。
ステップS６において、ＪＡＶＡ（登録商標）インポート部３５は、ステップS５にて作成されたＪＡＶＡ（登録商標）プログラムソースコード、プログラム付加情報、IDクラスソースコードをディスク作成部４０にインポートする。以上のステップS５及びステップS６は、ステップＳ２におけるシナリオデータの作成や、ステップＳ３における素材作成/インポート処理と並列的に行われる。
【０１６１】
ステップS７にて、ID変換部４１は、IDクラスソースコード、BD-J Object情報を、実際のBD-ROM上のタイトル番号、プレイリスト番号と一致するように変換する。このように変換処理を行うことにより、ステップＳ５とステップＳ６は、ステップＳ２の処理と関係なく、並列的に処理を行うことが可能になっている。
ステップS８にて、ＪＡＶＡ（登録商標）プログラムビルド部４４は、ステップS６で出力されたソースコードをコンパイルすることで、ＪＡＶＡ（登録商標）プログラムのビルドを行う。
【０１６２】
ステップS９において静止画エンコーダ４２は、BD-ROMシナリオデータに含まれる静止画、をBD-ROMに準拠したMPEG2、MPEG4-AVC、VC1のいずれかの形式に変換する。BD-ROMシナリオデータが、静止画の保管場所を含んでいる場合、該当する保管場所から静止画データを読み出して、かかる形式変換を行う。
ステップS１０において、マルチプレクサ４５は、BD-ROMシナリオデータに従って、複数のエレメンタリーストリームの多重化を行い、MPEG2-TS形式のAVClipを作成する。
【０１６３】
ステップS１１において、データベース生成部４３は、BD-ROMシナリオデータに従って、BD-ROMに準拠したデータベース情報を作成する。
ステップＳ１２において、フォーマット部４６は、ステップＳ８で作成されたＪＡＶＡ（登録商標）プログラム、ステップＳ１０で作成されたAVClip、ステップＳ１１で作成されたデータベース情報を入力とし、BD-ROMに準拠したフォーマットでファイルの配置を行う。ステップＳ１３においてフォーマット部４６は、ＪＡＶＡ（登録商標）プログラムとAVClipの関連付けを行い、ファイル関連情報を作成する。
【０１６４】
ステップS１４にて、ディスクイメージ作成部４７は、ファイル関連情報を利用しながら、ステップＳ１１によって作成されたファイル群を、BD-ROMフォーマットに適合したボリュームイメージに変換する。
ステップS１５にて、検証部装置５０は、ステップS１３にて作成されたディスクイメージの検証を行う。もしエラーが発生した場合は、然るべき前工程に戻って作業のやり直しを行う。
【０１６５】
以上が本実施の形態に係る記録方法の処理手順の説明である。
次に、動画メニューを持つシナリオデータの作成手順を、図面を参照しながら説明する。
図４５は、シームレス動画メニューの構成を持つシナリオデータの作成の手順を記したものである。この手順について説明する。
【０１６６】
ステップS１０１にて、オーサリングスタッフはメニュー編集部１２とGUIを利用し、図２９に示したようなGUIを用いてメニューの画面構成を設定する。
ステップS１０２にて、オーサリングスタッフはメニューを構成する背景動画の内容を、動画プロパティペイン２５０２を用いて設定する。
ステップS１０３にて、AVClip接続情報におけるPrev項目、Next項目を設定することで、1つの背景動画をシームレスに再生させる旨を設定する。ステップS１０４において、AVClip接続情報に基づき、シームレス動画メニューのためのPlayList情報を作成する。
【０１６７】
以上のように本実施形態によれば、動画メニュー用AVClipが記録されたBD-ROMを、記録装置を用いて作成することができるので、動画メニューにより操作性を高めた映画作品を、迅速かつ多量に供給することが可能となる。
（第５実施形態）
第１実施形態では、BD-ROM応用層規格に準拠した再生装置ならば、どの再生装置においてもシームレスに再生されるよう、動画メニューのデータ構造を説明した。本実施形態では、第１実施形態に述べたような手順で、AVClipが生成されていない場合でも、シームレス再生を実現できるよう、再生装置の内部構成を工夫するという実施形態に関する。
【０１６８】
本実施の形態における再生装置の構成を、図４６を参照しながら説明する。図４６の再生装置は、図２３で説明した再生装置２００と比べて以下の点が異なる。
つまり、デコーダ４におけるバッファ容量が変更されていて、次AVClip保持部９cが追加されており、データ解析実行部９bが、処理に示すような処理を行う。
先ず始めに、デコーダ４におけるバッファ容量について説明する。
【０１６９】
デコーダ４は、規格のデコーダモデルで定義されたTransport Buffer, Multiplexed Buffer, Elementary Bufferの最大バッファサイズと比べて、それぞれ、２倍となるバッファ量を持っている。これにより、AVClipの接続地点で、ビデオストリームがTransportBuffer, Multiplexed Buffer, Elementary Buffer 内に２重に存在したとしても、それぞれ入力されたデータ量はデコーダモデルで定義されたTransportBuffer, Multiplexed Buffer, Elementary Buffer 容量以下になるため、バッファからデータがあふれて、破綻することはない。
【０１７０】
次に、新規に追加された次AVClip保持部９cについて説明する。
次AVClip保持部９cは、次に再生すべきAVClipに対応するClip情報を保持する。  
以上が次AVClip保持部９cの説明である。続いて、本実施形態におけるデータ解析実行部９bの改良を説明する。
データ解析実行部９bは、一度Movie Objectを解析するときに、再生するAVClipを特定するとともに、その次に再生するAVClipについてのClip情報を取得して、次AVClip保持部９cに格納する。たとえば、図１６のデータ構成を持ったBD-ROMディスクの場合、MovieObject＃1は（１）PlayPL  PlayList＃1、（２）JumpMovieObject＃1のコマンド構成を持つ。ここで、PlayList情報＃1はAVClipを一つしか持たないが、データ解析実行部９bは、次のコマンドを解析する。この解析により、（２）JumpMovieObject＃1で実行されるMovieObject＃1の中身が判明する。この解析結果に基づき、次に再生されるAVClipと再生する位置や終了する位置を特定して、次AVClip保持部９ｃに格納する。
【０１７１】
以降、データ解析実行部９bは、現在再生されているAVClipのデコーダ４への入力が完了する直後から次AVClip保持部９cが保持するAVClipのデコーダ４への転送が可能なように、BD-ROMドライブ１を制御しながら再生処理を行っていく。
このようにコマンドの解釈をAVClipが再生するよりも前に行い、かつデコーダのバッファ量を規格で決められた値の２倍にすることにより、シームレスな設定がされていないBD-ROMにおいてもできるだけシームレスに再生することができるようになる。
【０１７２】
(第６実施形態)
本実施形態は、IGストリームの具体的な構成を開示する実施形態である。図４７（ａ）は、IGストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。
【０１７３】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ICS(Interactive Composition Segment)、PDS(PaletteDifinition Segment)、ODS(Object_Definition_Segment)、END(END of Display SetSegment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ICSは、画面構成セグメントと呼ばれ、PDS、ODS、ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。
【０１７４】
以降、各機能セグメントについて説明する。
『Interactive Composition Segment(ICS)』は、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。対話的な画面構成の1つとして、本実施形態のICSは、マルチページメニューを実現するものとする。
『Object_Definition_Segment(ODS)』は、ランレングス符号化形式のグラフィクスオブジェクトである。ランレングス符号化形式のグラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すPixelCodeと、画素値の連続長とにより、画素列を表現したデータである。Pixel Codeは、8ビットの値であり、0〜255の値をとる。ランレングスデータでは、このPixelCodeによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。
【０１７５】
『Palette Difinition Segment(PDS)』は、パレットデータを格納する機能セグメントである。パレットデータとは、0〜255のPixelCodeと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するPixelCodeを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。
【０１７６】
『END of Display Set Segment(END)』は、機能セグメントの伝送の終わりを示す指標であり、最後のODSの直後に配置される。以上が各機能セグメントについての説明である。
図４７（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図４７（ｂ）に示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。
【０１７７】
これら様々な種別の機能セグメントは、図４８のような論理構造を構築する。図４８は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にEpochを、第２段目にDisplaySetを、第３段目にDisplay Setの類型をそれぞれ示す。図４７（ａ）の第3段目に示した機能セグメントは第４段目に描かれている。
第１段目のEpochについて説明する。IGストリームにおけるEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、表示を構成するグラフィクスオブジェクトを格納しておくためのグラフィクスプレーン、非圧縮グラフィクスオブジェクトを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、シームレス再生が保障される。つまりEpochは、シームレス再生の保障が可能な再生時間軸上の一単位ということができる。グラフィックプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、シームレス再生は保証されない。
【０１７８】
尚、ここでのシームレス再生とは、グラフィクスの消去及び再描画が、所定のビデオフレーム数で完遂することをいう。IGストリームの場合、このビデオフレーム数は、4,5フレームとなる。このビデオフレームをどれだけにするかは、グラフィックプレーン全体に対する固定領域の大きさの比率と、オブジェクトバッファ−グラフィックプレーン間の転送レートとによって定まる。
【０１７９】
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一つの画面構成を実現するものの集合をいう。図４８における破線hk1は、第２段目のDisplaySetが、どのEpochに帰属しているかという帰属関係を示す。DS1,2,3・・・nは、第１段目のEpochを構成していることがわかる。
第３段目はDisplay Setの類型を示す。Epochの先頭に位置するDisplay Setの類型はEpoch Startである。先頭ではないDisplay Setの類型は『Acquisition Point』、『Normal Case』、『Epoch Continue』である。本図におけるAcquisitionPoint、Normal Case、Epoch Continueの順序は、一例にすぎず、どちらが先であってもよい。
【０１８０】
『Epoch Start』は、新たなEpochの開始にあたるDisplay Setである。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。EpochStartは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるDisplay Setである。AcquisitionPointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisition PointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。AcquisitionPointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisitionPointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【０１８１】
『Normal Case』は、”表示アップデート”という表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvは、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、ICSのみのDSv、又は、ODSのみのDSvを設けてこのDSvをNormalCaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。Normal CaseのDSは、差分にすぎないので、NormalCase単独では画面構成は行えない。
【０１８２】
『Epoch Continue』とは、AVClipの境界において、Epochが連続していることを示す。1つのDSnのComposition StateがEpochContinueに設定されていれば、たとえDSnが、その直前に位置するDSn-1と異なるAVClip上に存在していたとしても、同じEpochに属することになる。これらDSn,DSn-1は、同じEpochに帰属するので、たとえこれら2つのDS間で、AVClipの分岐が発生したとしても、グラフィックスプレーン、オブジェクトバッファのフラッシュは発生しない。  
【０１８３】
図中の破線kz1は、第４段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。第４段目の機能セグメントは、図４７（ａ）に示したものと同じものなので、これら図４７（ａ）の一連の機能セグメントは、EpochStartに帰属していることがわかる。Acquisition Pointに帰属する機能セグメントは、Epoch Startに帰属するものと同じであり、NormalCaseに帰属する機能セグメントは、Epoch Startに帰属するものの一部を省略したものである。
【０１８４】
以上が機能セグメントにより構成される論理構造についての説明である。続いてこれらICS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplaySetから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。DisplaySet内のICS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このICS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplaySetの割り当てである。
【０１８５】
Epochに属するDisplay Setのうち、任意のDisplay SetをDSnとすると、DSnは、図４９に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。
図４９は、DSnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてDSnの始期は、DSnに属するICSのDTS値(DTS(DSn[ICS]))により示されており、終期は、DSnに属するICSのPTS値(PTS(DSn[ICS]))により示されている。そしてDSnにおいて最初の表示が行われるタイミングは、ICSのPTS値(PTS(DSn[ICS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(DSn[ICS])とを一致させれば、DSnの最初の表示は、そのビデオストリームと同期することになる。
【０１８６】
PTS(DSn[ICS])は、DTS(DSn[ICS])に、ODSのデコードに要する期間(DECODEDURATION)と、デコードにより得られたグラフィクスオブジェクトの転送に要する期間(TRANSFERDURATION)とを足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。図４９の期間mc1は、DSnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。
【０１８７】
以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
本実施形態は、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための新規な構成は、ICS内のInteractive_compositionに存在する。以降ICS、Interactive_compositionの内部構成について以下説明する。
【０１８８】
図５０（ａ）（ｂ）は、ICSとInteractive_compositionとの対応関係を示す図である。ICSとInteractive_compositionとの対応関係には、図５０（ａ）に示すような1対1のものと、図５０（ｂ）に示すような1対多のものとがある。
対応関係が1対1になるのは、Interactive_compositionのサイズが小さく、1つのICS内にInteractive_compositionが収まる場合である。
【０１８９】
1対多の対応関係になるのは、Interactive_compositionのサイズが大きく、Interactive_compositionがフラグメント化され、複数ICSに格納される場合である。複数ICSへの格納が可能なので、Interactive_compositionサイズには制限がなく、512Kバイトであろうと、1Mバイトであろうと、Interactive_compositionのサイズを大きくすることができる。ICS、Interactive_compositionには1対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ICS、Interactive_compositionの対応関係は、1対1であるとする。
【０１９０】
図５１は、ICSの内部構成を示す図である。ICSには、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部が格納されている。図５１の左側に示すように、ICSは、自身がICSであることを示す『segment_descriptor』と、本ICSが想定している縦横の画素数、フレームレートを示す『video_descriptor』と、本ICSが属するDisplaySetが、Normal Case、Acquisition Point、Epoch Start、Effect_Sequenceの何れであるかを示すcomposition_stateと、画面合成の回数を示すComposition_Numberとを含む『composition_descriptor』と、Interactive_Compositionの全体、又は、Interactive_Compositionをフラグメント化することで得られた一部である『Interactive_composition_data_fragment』とからなる。
【０１９１】
図５１の矢印cu1は、Interactive_compositionの内部構成をクローズアップしている。この矢印に示すようにInteractive_compositionは、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報(1)(2)・・・(i)・・・(number_of_page-1)』を含む。
図５２は、1つのEpochにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。この図５２に示すようにPage情報(y)は、
i)Page(y)を一意に識別する『page_id』、
ii)Page情報(y)により運搬されるデータ構造の中身にあたる,『in_effect』,『out_effect』,『animation_frame_rate_code』,『default_selected_button_id_ref』、『default_activated_button_id_ref』,『pallet_id_ref』,『ボタン情報(1)(2)・・・・・(number_of_buttons-1)』、
iii)Page情報(y)の中身のバージョンを示す『Page_Version_Number』
から構成される。
先ず初めに、Page情報(y)により運搬されるデータ構造を構成する各フィールドについて説明する。
【０１９２】
『in_effect』は、Page(y)の表示開始時あたって再生すべき表示効果を示す。  『out_effect』は、Page(y)の表示終了時あたって再生すべき表示効果を示す。
『animation_frame_rate_code』は、Page(y)にアニメーション表示を適用する際、適用すべきフレームレートを記述する。
『default_selected_button_id_ref』は、Page(y)の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”OxFF”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ(PlayerStatus Register(PSR))の設定値が優先的に解釈され、PSRに示されるボタンがセレクテッド状態になる。本フィールドが0xFFでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『default_selected_button_id_ref』に規定されたボタン番号でPSRを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。
【０１９３】
『default_activated_button_id_ref』は、selection_time_out_ptsに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。default_activated_button_id_refが”FF”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このdefault_activated_button_id_refが00であれば、自動選択はなされない。00,FF以外の値であれば本フィールドは、有効なボタン番号として解釈される。
【０１９４】
『pallet_id_ref』は、Page(y)において、CLUT部に設定すべきパレットのidを示す。
『ボタン情報(Button_info)』は、Page(y)上に表示される各ボタンを定義する情報である。以上のフィールドにより、マルチページメニューにおける個々のページの中身は特定される。
『Page_Version_Number』は、EpochにおいてPage情報(y)のデータ構造により運搬される中身のバージョンを示すフィールドである。このPage_Version_Numberは本願の主眼となるものであるので、このPage_Version_Numberについて詳しく説明する。ページ情報(y)のバージョンとは、ページ情報で運搬されるデータ構造の中身が、何回目のアップデートを経たものであるかを示す。Page情報(y)のデータ構造において、Page_Version_Number直後のフィールドのうち、どれかの値が変化した場合、又は、Page_Version_Number直後の各フィールドに何等かの変化があった場合、Page情報(y)は、アップデートされたとみなされる。
【０１９５】
図５３は、Page情報(y)におけるボタン情報(i)の内部構成を示す図である。
『button_id』は、ボタン(i)を、Interactive_compositionにおいて一意に識別する数値である。
『button_numeric_select_value』は、ボタン(i)の数値選択を許可するか否かを示すフラグである。
【０１９６】
『auto_action_flag』は、ボタン(i)を自動的にアクティブ状態にするかどうかを示す。auto_action_flagがオン(ビット値1)に設定されれば、ボタン(i)は、セレクテッド状態になる代わりにアクティブ状態になる。auto_action_flagがオフ(ビット値0)に設定されれば、ボタン(i)は、選択されたとしてもセレクテッド状態になるにすぎない。
『button_horizontal_position』、『button_vertical_position』は、対話画面におけるボタン(i)の左上画素の水平位置、垂直位置を示す。
【０１９７】
『neighbor_info』は、ボタン(i)がセレクテッド状態になっていて、上下左右方向へのフォーカス移動が命じられた場合、どのボタンをセレクテッド状態に設定するかを示す情報であり、『upper_button_id_ref』,『lower_button_id_ref』,『left_button_id_ref』,『right_button_id_ref』からなる。
『upper_button_id_ref』は、ボタン(i)がセレクテッド状態である場合においてリモコンが操作され、上方向へのフォーカス移動を命じるキー(MOVEUPキー)が押下された場合、ボタン(i)の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、MOVEUPキーの押下は無視される。
【０１９８】
『lower_button_id_ref』,『left_button_id_ref』,『right_button_id_ref』は、ボタン(i)がセレクテッド状態である場合において、リモコンが操作され、下方向へのフォーカス移動を命じるキー(MOVEDownキー),左方向へのフォーカス移動を命じるキー(MOVELeft キー),右方向へのフォーカス移動を命じるキー(MOVE Right キー)が押下された場合、ボタン(i)の押下の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、これらのキーの押下は無視される。
【０１９９】
『normal_state_info』は、ボタン(i)のノーマル状態を規定する情報であり、『normal_start_object_id_ref』、『normal_end_object_id_ref』、『normal_repeat_flag』を含む。
『normal_start_object_id_ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのnormal_start_object_id_refに記述される。
【０２００】
『normal_end_object_id_ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのnormal_end_object_id_refに記述される。このnormal_end_object_id_refに示されるIDが、normal_start_object_id_refに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタン(i)の絵柄になる。
【０２０１】
『normal_repeat_flag』は、ノーマル状態にあるボタン(i)のアニメーション表示を反復継続させるかどうかを示す。
『selected_state_info』は、ボタン(i)のセレクテッド状態を規定する情報であり、 『selected_state_sound_id_ref』、『selected_start_object_id_ref』、『selected_end_object_id_ref』、『selected_repeat_flag』を含む。
『selected_state_sound_id_ref』は、ボタン(i)の状態がセレクテッド状態が変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvと呼ばれるファイルに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。
【０２０２】
『selected_start_object_id_ref』は、セレクテッド状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのselected_start_object_id_refに記述される。
『selected_end_object_id_ref』は、セレクト状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのselected_end_object_id_refに記述される。このselected_end_object_id_refに示されるIDが、selected_start_object_id_refに示されるIDと同じである場合、このIDにて示されるグラフィックスオブジェクトの静止画が、ボタン(i)の絵柄になる。
【０２０３】
『selected_repeat_flag』は、セレクテッド状態にあるボタン(i)のアニメーション表示を、反復継続するかどうかを示す。selected_start_object_id_refと、selected_end_object_id_refとが同じ値になるなら、本フィールド00に設定される。
『activated_state_info』は、ボタン(i)のアクティブ状態を規定する情報であり、 『activated_state_sound_id_ref』、『activated_start_object_id_ref』、『activated_end_object_id_ref』を含む。
【０２０４】
『activated_state_sound_id_ref』は、button情報に対応するボタンのセレクテッド状態が変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。
【０２０５】
『activated_start_object_id_ref』は、アクティブ状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのactivated_start_object_id_refに記述される。
『activated_end_object_id_ref』は、アクティブ状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object_ID』のうち、最後の番号がこのactivated_end_object_id_refに記述される。
【０２０６】
『ナビゲーションコマンド(navigation_command)』は、ボタン(i)がアクティブ状態になれば、実行されるコマンドである。かかるコマンドは、MovieObjectに記述されているナビゲーションコマンドと同じものなので、あるボタンの確定時に、再生装置に実行させたいナビゲーションコマンドを、このボタン情報に記述しておけば、対応するボタンの確定時において、再生装置に所望の制御を行わせることができる。ボタン情報内のナビゲーションコマンドは、MovieObject同様、再生装置に操作待ち制御を行わせるものなので、本発明にかかるプログラム、つまり、メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムは、MovieObjectに記述されたナビゲーションコマンドと、ボタン情報に記述されたナビゲーションコマンドとから構成される。第１実施形態に示した具体例を作成する場合、メニューには、Title＃1の選択を受け付けるボタン、Title＃2の選択を受け付けるボタンが表示されるので、これらのTitle＃1選択ボタンに対応するボタン情報のナビゲーションコマンドに、Title＃1へのジャンプを命じるようなナビゲーションコマンドを記述し、Title＃2選択ボタンに対応するボタン情報のナビゲーションコマンドに、Title＃2へのジャンプを命じるようなナビゲーションコマンドを記述すれば、かかるTitle＃1選択ボタン、Title＃2選択ボタンの状態変化に応じて、Title＃1、Title＃2の再生が開始される。
【０２０７】
またボタン情報特有のナビゲーションコマンドとして、SetButtonPageコマンドがある。SetButtonPageコマンドは、マルチページメニューの所望のページを表示させ、そのページにおける所望のボタンをセレクテッド状態に設定させることを再生装置に命じるコマンドである。かかるナビゲーションコマンドを用いることにより、オーサリング担当者は、ページ切り換えを簡易に記述することができる。
【０２０８】
以上のように構成されたIGストリームが、図２３に示したIGデコーダ６の構成要素により、どのように処理されるかを、図５４を参照しながら説明する。
Coded Data Buffer６bには、ICS、PDS、ODSがDTS、PTSと共に一時的に格納される。
Stream Graphics Processor６cは、ODSをデコードして、デコードにより得られた非圧縮グラフィクスをObject Buffer６dに書き込む。
【０２０９】
Object Buffer６dは、Stream Graphics Processor６cのデコードにより得られた非圧縮のグラフィクスオブジェクト(図中の四角枠)が多数配置されるバッファである。このObjectBuffer６dにおいて各グラフィクスオブジェクトが占める矩形領域は、Object_idにより識別される。従って、Object Buffer６d上にあるグラフィクスオブジェクトが存在している状態で、同じObject_idをもつグラフィクスオブジェクトが許可要求されれば、ObjectBuffer６d上においてそのグラフィクスオブジェクトが占める領域は、同じObject_idをもつグラフィクスオブジェクトにより上書きされることになる。
【０２１０】
Compositionバッファ６eは、1つ以上のICSに対応する運搬されるInteractive_compositionを格納しておくためのバッファである。格納されているInteractive_compositionは、Graphicsコントローラ６fによる解読に供される。
Graphicsコントローラ６fは、現在の再生時点が新たなDisplay Setに到達する度に、そのDisplay Setに含まれるICSのComposition_Stateが、EpochStart、Acquisition Point、Normal Caseのどれであるかを判定する、Epoch Startであれば、Coded Dataバッファ６b上の新たなInteractive_compositionを、CodedDataバッファ６bからCompositionバッファ６eに転送する。
【０２１１】
Graphicsコントローラ６fは、Acquisition PointタイプのDisplay SetにおけるICSがCoded Dataバッファ６bに読み出される度に、そのICSに属する各ページ情報のPage_Version_Numberと、Compositionバッファ６eに格納済みのInteractive_compositionにおける各ページ情報のPage_Version_Numberとを照合する。そしてPage_Version_Numberが大きいページ情報がCodedDataバッファ６b上に存在していれば、そのページ情報をCoded Dataバッファ６bからCompositionバッファ６eに転送することで、Compositionバッファ６eにおける所望のページ情報をアップデートする。そしてそうやってアップデートされたページ情報に該当するページが現在表示中であるか否かを判定し、もし表示中であれば、該当するページの再描画を行う。図中の◎1,2,3,4は、CodedDataバッファ６bに読み出されたInteractive_compositionにおけるPage_Version_Number参照(◎1)、Page_Version_Numberが高いページ情報の転送(◎2)、アップデートされたページ情報の参照(◎3)、アップデートされたページ情報に基づく再描画(◎4)を模式化している。更に図中の矢印bg1,2,3,4は、GraphicsController６fによる再描画を象徴的に示している。かかる描画により、ボタン0-A〜ボタン0-Dが配されたページがInteractive Graphicsプレーン１０に現れ、動画に合成されることになる。
【０２１２】
Epochは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら1つのAVClip内でEpochは完結していなければならない。しかし第１実施形態で述べたような動画メニューを構成する場合、複数のPlayItem情報にて、メニューを続けて表示させる必要があるので、複数のPlayItem情報間で、連続するようなEpochを定義することが必要になる。ここで、2つのAVClipが順次再生される場合であって、所定の3つの条件が満たされるような場合、2つのAVClip間で連続性をもつようなEpochを定義することができる。
【０２１３】
図５５（ａ）は、2つのAVClip間で連続性をもつようなEpochを示す図である。本図における第1段目は、previous PlayItemから再生されるAVClipと、CurrentPlayItemから再生されるAVClipとを示し、第2段目は、2つのAVClip間で連続性をもつEpochを示す。第3段目は、第2段目のEpochに属するDisplaySetを示す。第2段目におけるEpochは、AVClipにより分断されない。しかし第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplaySetに分断されている。本図において注目すべきは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型が、”Epoch Continueタイプ”になっていることである。
【０２１４】
“Epoch Continue”とは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型であり、所定の3つの条件が満たされる場合、AcquisitionPointとして取り扱われる。この3つの条件のうち、1つでも欠落があれば、Epoch Startとして取り扱われる。
図５５（ｂ）は、Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。本図に示すように、EpochContinueタイプのDisplay Setは、Current PlayItemから再生されるAVClipからの飛び込み再生が行われる場合、”EpochStart”として取り扱われ、previous PlayItemから再生されるAVClipから連続再生が行われる場合、”Acquisition Point”として取り扱われることがわかる。
【０２１５】
図５６は、2つのAVClip間で連続性をもつための3つの条件を示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、Epochを示す。このEpochが、2つのAVClip間でメモリ管理の連続性をもつEpochである。第3段目は、第２段目におけるEpochのそれぞれに属するDisplaySetを示す。第2段目におけるEpochは、AVClipにより分断されることはなかったが、第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplaySetに分断されている。第4段目は、各Display Setに属する機能セグメントを示す。この第4段目における機能セグメント群は、図５の第4段目に示したものと同じである。図中の◎1,◎2,◎3が、2つのAVClip間で連続性をもつようなEpochの成立条件を示す。1つ目の条件は、AVClip境界の直後に位置するDisplaySet(DSm+1)の類型が、第3段目に示すようにEpoch Continueになっていることである。
【０２１６】
2つ目の条件は、DSm+1に属するICSの全ての位置情報におけるComposition Numberが、1つ前のDSmに属するICSの全ての位置情報におけるCompositionNumber(=A)と同じであること、つまりグラフィクス表示の内容が、AVClip境界の前後で同じであることを意味する。Composition Numberは、DisplaySetによる画面構成を意味するものである。このComposition Numberが同じであるということは、画面構成で得られるグラフィクスの内容が、DSmと、DSm+1とで同じであることを意味する。
【０２１７】
3つ目の条件は、previous PlayItemによるAVClipの再生と、Current PlayItemによるAVClipの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
(i)ビデオ属性情報に示されているビデオストリームの表示方式（NTSC、PAL等）が、2つのAVClip間で同一である。
【０２１８】
(ii)オーディオ属性情報に示されているオーディオストリームのエンコード方式（AC-3、MPEG、LPCM等）が、2つのAVClip間で同一である。
以上の(i)〜(ii)においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。
【０２１９】
例えば、連続して再生すべき2つのオーディオストリームにおいて、一方の符号化方式がAC-3方式であり、他方がMPEG規格である場合、ストリームがAC-3からMPEGへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
これら(i)〜(ii)の関係が全て満たされた場合のみ、シームレス接続がなされる。(i)〜(ii)の関係のうち、１つでも満たされない場合、シームレス接続はなされない。
【０２２０】
かかる3つの条件が満たされれば、Epoch ContinueタイプのDSm+1はAcquisition Pointとして取り扱われることになる。つまりDisplaySet1〜m、Display Setm+1〜n間は1つのEpochを形成することになり、2つのAVClipの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
仮にDSm+1の類型がEpoch Continueであったとしても、残り2つの条件のうち、1つの欠落があれば、Epochは、AVClipの境界前後で2つに分断されることになる。以上のことからEpochContinueタイプのDisplay Setは、上述したように3つの条件が全て満たされた場合にAcquisition Pointとして扱われる。1つの条件が欠けた場合は、EpochStartとして取り扱われることになる。
【０２２１】
以上のように本実施形態によれば、PlayList情報において、2つ目以降に存在するPlayItem情報のComposition Typeを、EpochContinueに設定し、Composition Numberを、先頭のPlayItem情報のComposition Numberと同一に設定することで、PlayItem情報の切り替わりにおいて、メニューの表示が一旦消えることを避けることができる。
(第７実施形態)
本実施形態は、PGストリームの具体的な構成を開示する実施形態である。図５７は、PGストリームの具体的な構成を示す図である。本図の第４段目は、PGストリームを示す。第３段目に、当該PGストリームが属するDisplaySetの類型を示し、第２段目にDisplay Setを、第１段目にEpochをそれぞれ示す。
【０２２２】
第２段目のDisplay Set(DSと略す)とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線kz1は、第３段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PGストリームを構成する機能セグメントのうち、PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。
【０２２３】
ここで、PGストリームにおけるEpochの概念について説明する。第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図５８は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕「本当に」「ごめん」「あれから」「3年がたった」のうち、2つの字幕「本当に」「ごめん」は画面の下側に、「あれから」「3年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域(window1)になる。一方Epoch2では、画面の上側の余白が字幕の描画領域(window2)になる。これらのEpoch1,2において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplaySetについて説明する。
【０２２４】
図５７における破線hk1,2は、第２段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。EpochStart,Acquisition Point,Normal Caseという一連のDSは、第１段目のEpochを構成していることがわかる。『EpochStart』、『Acquisition Point』、『Normal Case』は、DSの類型である。本図におけるAcquisition Point、NormalCaseの順序は、一例にすぎず、どちらが先であってもよい。
【０２２５】
続いてPGストリームを構成する機能セグメントのうち、特徴的なものについて説明する。ここで、PGストリーム内に存在する機能セグメントのうち、WDS,PCSは、PGストリーム特有の構成である。先ず始めに、WDS(window_definition_segment)について説明する。
『window_definition_segment』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”window”と呼ばれ、このWDSで定義される。図５９（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window_id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window_horizontal_position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window_vertical_position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window_width』と、グラフィックスプレーンにおける縦幅を示す『window_height』とを用いて表現される。
【０２２６】
window_horizontal_position、window_vertical_position、window_width、window_heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦:video_height、横:video_widthという二次元状の大きさをもつ。
window_horizontal_positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、1〜video_widthの値をとり、window_vertical_positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので1〜video_heightの値をとる。
【０２２７】
window_widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、1〜video_width-window_horizontal_positionの値をとり、window_heightは、グラフィックスプレーンにおける縦幅であるので1〜video_height-window_vertical_positionの値をとる。
WDSのwindow_horizontal_position、window_vertical_position、window_width、window_heightにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【０２２８】
続いてPCSについて説明する。
PCSは、字幕等の画面を構成する機能セグメントである。PCSは、図５９（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment_type』と、『segment_length』と、『composition_number』と、『composition_state』と、『pallet_update_flag』と、『pallet_id』と、『composition_object(1)〜(m)』とから構成される。
【０２２９】
『composition_number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition_numberは設定される。
『composition_state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、ACquisition Pointであるか、EpochStartであるかを示す。
【０２３０】
『pallet_update_flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnlyDispley Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは”1”に設定される。
『pallet_id』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnlyDispley Updateとは、直前のDisplay Setから、パレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされる場合、本フィールドは”1”に設定される。
【０２３１】
『composition_object(1)・・・(n)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図５９（ｂ）の破線wd1は、任意のcomposition_object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition_object(i)は、『object_id_ref』、『window_id_ref』、『object_cropped_flag』、『object_horizontal_position』、『object_vertical_position』、『cropping_rectangle情報(1)(2)・・・・・(n)』からなる。
【０２３２】
『object_id_ref』は、グラフィクスオブジェクト識別子(object_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window_id_ref』は、ウィンドゥ識別子(window_id)の参照値である。この参照値は、composition_object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【０２３３】
『object_cropped_flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”1”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”0”と設定された場合、グラフィクスオブジェクトは非表示となる。
【０２３４】
『object_horizontal_position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object_vertical_position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『cropping_rectangle情報(1)(2)・・・・・(n)』は、『object_cropped_flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping_rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping_rectangle情報(i)は、『object_cropping_horizontal_position』、『object_cropping_vertical_position』、『object_cropping_width』、『object_cropping_height』からなる。
【０２３５】
『object_cropping_horizontal_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSIEN 300 743標準規格における”Region”に相当する。
『object_cropping_vertical_position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【０２３６】
『object_cropping_width』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『object_cropping_height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
Epochに属するDisplay Setのうち、任意のDisplay SetをDSnとすると、DSnは、図６０に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。図６０は、DSnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてDSnの始期は、DSnに属するPCSのDTS値(DTS(DSn[PCS]))により示されており、終期は、DSnに属するPCSのPTS値(PTS(DSn[PCS]))により示されている。そしてDSnにおいて最初の表示が行われるタイミングも、PCSのPTS値(PTS(DSn[PCS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(DSn[PCS])とを一致させれば、DSnの最初の表示は、そのビデオストリームと同期することになる。
【０２３７】
PTS(DSn[PCS])は、DTS(DSn[PCS])に、ODSのデコードに要する期間(DECODEDURATION)を足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。本図の期間mc1は、DSnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。
【０２３８】
以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
Epochは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら1つのAVClip内でEpochは完結していなければならない。しかし2つのAVClipが順次再生される場合であって、所定の3つの条件が満たされるような場合、2つのAVClip間で連続性をもつようなEpochを定義することができる。
【０２３９】
”Epoch Continue”とは、AVClip境界の直後に位置するDisplay Set(DSm+1)の類型であり、第６実施形態で示した所定の3つの条件が満たされる場合、AcquisitionPointとして取り扱われる。この3つの条件のうち、1つでも欠落があれば、Epoch Startとして取り扱われる。つまりEpoch ContinueタイプのDisplaySetは、後続AVClipからの飛び込み再生が行われる場合、”Epoch Start”として取り扱われ、先行AVClipから連続再生が行われる場合、”AcquisitionPoint”として取り扱われることがわかる。
【０２４０】
図６１は、2つのAVClip間で連続性をもつための3つの条件を示す図である。本図における第1段目は、連続して再生される2つのAVClipを示し、第2段目は、3つのEpochを示す。この3つのEpochのうち、真ん中のEpochが、2つのAVClip間でメモリ管理の連続性をもつEpochである。第3段目は、3つのEpochのそれぞれに属するDisplaySetを示す。第2段目におけるEpochは、AVClipにより分断されることはなかったが、第3段目におけるDisplay Setは、このAVClip境界の前後で2つのDisplaySetに分断されている。第4段目は、各Display Setに属する機能セグメントを示す。この第4段目における機能セグメント群は、図５７の第4段目に示したものと同じである。図中の◎1,◎2,◎3が、2つのAVClip間で連続性をもつようなEpochの成立条件を示す。1つ目の条件は、AVClip境界の直後に位置するDisplaySet(DSm+1)の類型が、第3段目に示すようにEpoch Continueになっていることである。
【０２４１】
2つ目の条件は、DSm+1に属するPCSのComposition Numberが、1つ前のDSmに属するPCSのComposition Number(=A)と同じであること、つまりグラフィクス表示の内容が、AVClip境界の前後で同じであることを意味する。CompositionNumberは、Display Setによる画面構成を意味するものである。このComposition Numberが同じであるということは、画面構成で得られるグラフィクスの内容が、DSmと、DSm+1とで同じであることを意味する。図１５は、DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。本図に示すように、DSmによるグラフィクスの内容は『3年たった』であり、DSm+1によるグラフィクスの内容は『3年たった』であるので、2つのDisplaySet間でグラフィクスの内容は同じであり、Composition Numberが同一値になっていることがわかる。また、ビデオストリームの再生もシームレス接続になされているので、DSm+1はAcquisitionPointとして取り扱われることがわかる。
【０２４２】
3つ目の条件は、先行AVClIPの再生と、後続AVClIPの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
(i)ビデオ属性情報に示されているビデオストリームの表示方式（NTSC、PAL等）が、2つのAVClip間で同一である。
【０２４３】
(ii)オーディオ属性情報に示されているオーディオストリームのエンコード方式（AC-3、MPEG、LPCM等）が、2つのAVClip間で同一である。
以上の(i)〜(ii)においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。
【０２４４】
例えば、連続して再生すべき2つのオーディオストリームにおいて、一方の符号化方式がAC-3方式であり、他方がMPEG規格である場合、ストリームがAC-3からMPEGへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
これら(i)〜(ii)の関係が全て満たされた場合のみ、シームレス接続がなされる。(i)〜(ii)の関係のうち、１つでも満たされない場合、シームレス接続はなされない。
【０２４５】
かかる3つの条件が満たされれば、Epoch ContinueタイプのDSm+1はAcquisition Pointとして取り扱われることになる。つまりDisplaySet1〜m、Display Setm+1〜n間は1つのEpochを形成することになり、2つのAVClipの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
仮にDSm+1の類型がEpoch Continueであったとしても、残り2つの条件のうち、1つの欠落があれば、Epochは、AVClipの境界前後で2つに分断されることになる。以上のことからEpochContinueタイプのDisplay Setは、上述したように3つの条件が全て満たされた場合にAcquisition Pointとして扱われる。1つの条件が欠けた場合は、EpochStartとして取り扱われることになる。
【０２４６】
以上のように本実施形態によれば、PlayList情報において、2つ目以降に存在するPlayItem情報内に属するPGストリームのCompositionTypeを、Epoch Continueに設定し、Composition Numberを、先頭のPlayItem情報のComposition Numberと同一に設定することで、PlayItem情報の切り替わりにおいて、字幕の表示が一旦消えることを避けることができる。
＜備考＞
上記実施形態に基づいて説明してきたが、現在において最善の効果が期待できるシステム例として提示したに過ぎない。本発明はその要旨を逸脱しない範囲で変更実施することができる。代表的な変更実施の形態として、以下のものがある。
(BD-Jアプリケーションによる操作待ち制御)
動画メニューにおける操作待ち制御が、Movie Objectによりなされる場合、メニューに対する制御が、これまでに述べたようなICSにより実現される。一方、操作待ち制御が、BD-Jアプリケーションによりなされる場合、メニューに対する制御に、ICSは用いられない。何故なら、上述したように、BD-Jアプリケーションは、HAViに基づき、GUIフレームワークを描画することができるからである。しかし、かかる場合であっても、動画メニューにおいて背景画として、AVClipを用いることには変りない。よって、BD-Jアプリケーションにて操作待ち制御を実現する場合であっても、999個のPlayItem情報を有するPlayList情報を利用することで、AV画面の途切れのない操作待ち制御を実現することができる。
(PlayItem情報の個数)
第１実施形態において、PlayItem情報の個数を999個にしたのは、BD-ROM規格に基づくものであり、識別番号に割り当てられている桁数に制限があることと、PlayList情報をオンメモリで使用したいとの要請による。しかし、このような制限が存在しない規格上で、動画メニューを作成する場合や、より大きなPlayList情報が認められているような規格上で、動画メニューを作成する場合、逆に、桁数やメモリ規模が厳しく制限されている応用層規格上で動画メニューを作成する場合、PlayItem情報の個数を増減させてよいことはいうまでもない。
（記録媒体のバリエーション）
各実施形態では、AVコンテンツやアプリケーションを記録する記録媒体やオーサリングの対象をBD-ROMとして説明を進めたが、このBD-ROMの物理的性質は、本発明の作用・効果の発揮にさほど貢献していない。BD-ROM同様、AVコンテンツを記録し得る容量を持った記録媒体であるなら、他の記録媒体を採用してもよい。例えば、BD-ROM以外のCD-ROM、CD-R、CD-RW，DVD-ROM、DVD-R、DVD-RW、DVD-RAM、DVD+R、DVD+RW等の他の光ディスクであってよいことはいうまでもない。また、PD、MO等の光磁気ディスクであってもよい。更に、SDメモリカード、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリーカードであってもよい。HDD、フレキシブルディスク、SuperBD-ROM、Zip、Click！等の磁気記録ディスク、ORB、Jaz、SparQ、SyJet、EZFley、マイクロドライブ等のリムーバブルハードディスクドライブであってもよい。無論、ローカルストレージは、再生装置に装填され、所定の著作権保護がなされた記録媒体であるならば、上述したような記録媒体の何れでもよい。
【０２４７】
(他の規格への発展)
本実施の形態はBD-ROMを例に挙げたが、AVClipの再生を行う同等のビデオ規格であれば、適応可能であることは明白である。
(第２実施形態における動画メニューの作成法)
第２実施形態の動画メニューを作成する場合、PlayList生成部１４は、PlayList情報内の奇数番目のPlayItem情報が、AVClip＃1の再生を、再生装置に命じることで、当該AVClip＃1の再生を繰り返す旨を示し、偶数番目のPlayItem情報が、AVClip＃2の再生を、再生装置に命じることで、当該AVClip＃2の再生を繰り返す旨を示すよう、PlayList情報を生成する。
(システムLSI化)
第１実施形態に示した再生装置の内部構成は、1つのシステムLSIとして構成してもよい。
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
【０２４８】
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
【０２４９】
かかるシステムLSIは、再生装置は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。
具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。
【０２５０】
そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。
【０２５１】
各実施形態の内部構成のうち、一般的な部分については、既存の回路パターンを定義したIntellectual Propertyを組み合わせて設計するのが望ましい。特徴的な部分については、HDLを用いた抽象度が高い動作レベルを記述やレジスタトランスファレベルでの記述を用いてトップダウン設計を行うのが望ましい。  
回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。
【０２５２】
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC(Systemon chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
【０２５３】
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUT(Look Up Table)に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込むませる必要がある。更に、デコーダを内蔵した映像復調回路は、積和演算機能を内蔵したDSPで実現するのが望ましい。
(アーキテクチャ)
本発明にかかるシステムLSIは、再生装置の機能を実現するものなので、システムLSIは、Uniphierアーキテクチャに準拠させるのが望ましい。
【０２５４】
Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。
・データ並列プロセッサDPP
これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。
・命令並列プロセッサIPP
これは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなる「Local Memory Contoroller」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「ProcessingUnit部」、複数アプリケーションの並列実行をProcessing Unit部に行わせる「Virtual Multi Processor Unit部」で構成される。
【０２５５】
・CPUブロック
これは、ARMコア、外部バスインターフェイス(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(GeneralPurpose Input Output)、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。先に述べたコントローラは、このCPUブロックとしてシステムLSIに実装される。
【０２５６】
・ストリームI/Oブロック
これは、USBインターフェイスやATA Packetインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。
・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。
【０２５７】
・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。
(本発明に係るプログラムの生産形態)
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、ＪＡＶＡ（登録商標）バイトコードというように、様々な種類がある。
【０２５８】
本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２５９】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
【産業上の利用可能性】
【０２６０】
本発明に係る情報記録媒体は、動画メニューにおいて、動画再生が静止したり、ボタンが消えることを、できるだけ回避することができ、コンテンツメーカーの意図通りに高度なBD-ROM作品をより多く市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図面の簡単な説明】
【０２６１】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの内部構成を示す図である。
【図３】Index.bdmvの内部構成を示す図である。
【図４】MovieObject.bdmvの内部構成を示す図である。
【図５】AVClipの構成を示す図である。
【図６】図５に示した各エレメンタリストリームが、AVClipにおいてどのように多重化されているかを模式的に示す図である。
【図７】PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示した図である。
【図８】AVClipを構成するSourceパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。
【図９】AVClipと、Sourceパケットと、ATSの構成とを、階層的に示す図である。
【図１０】Clip情報の内部構成を示す図である。
【図１１】映画のビデオストリームに対するEP_map設定を示す図である
【図１２】（ａ）（ｂ）PlayList情報のデータ構造と、Multi_Clip_entriesの内部構成とを示す図である。
【図１３】PlayList情報におけるPlayListMark情報の内部構成を示す図である。
【図１４】AVClipと、PlayList情報との関係を示す図である。
【図１５】STN_tableの設定例を示す図である。
【図１６】動画メニューの一般的な階層構造を示す図である。
【図１７】PlayList情報における特徴的なデータ構造を示す図である。
【図１８】図１７のPlayList情報により構成される動画メニューの階層構造を示す図である。
【図１９】（ａ）（ｂ）ATC Sequenceと、STC Sequenceとの関係を示す図である。
【図２０】（ａ）（ｂ）シームレスに接続される2つのAVClip(previousPlayItemにて参照されるAVClip＃1、CurrentPlayItemにて参照されるAVClip＃1)を示す図である。
【図２１】Clean Breakの詳細を示す図である。
【図２２】再生装置の内部構成を示す図である。
【図２３】ビデオデコーダ４、オーディオデコーダ５、IGデコーダ６、PGデコーダ７の内部構成を示す図である。
【図２４】ATC Diff、STC Diffを示す図である。
【図２５】Read Bufferのバッファ状態を示す図である。
【図２６】ビデオデコーダにおけるElementary Buffer のバッファ状態を示す図である。
【図２７】Elementary Buffer における蓄積量の遷移と、Elementary Buffer におけるバッファ容量の遷移とを示す。
【図２８】入力制限直線を示す図である。
【図２９】previousPlayItemによる再生におけるt_in_endと、Current PlayItemによる再生におけるt_in_startとを同一の時間軸上で、一致させることで、観測されるバッファ遷移を示す図である。
【図３０】ビデオのバッファ遷移と、オーディオのバッファ遷移とを対応付けて示す図である。
【図３１】割当符号量変更前のバッファ遷移と、割当符号量変更後のバッファ遷移とを対比して示す図である。
【図３２】動画メニューの具体例を示す図である。
【図３３】第２実施形態に係る動画メニューの構成を示す図である。
【図３４】マルチアングル区間を構成する3つのAVClip(AVClip＃1、AVClip＃2、AVClip＃3)を示す図である。
【図３５】マルチアングル区間を用いて動画メニューを構成するPlayList情報の構成を示す図である。
【図３６】本発明にかかる記録装置の内部構成を示す図である。
【図３７】タイトル構造作成部１０で作成されるタイトル構造情報のデータ構造の例を示している。
【図３８】メニュー画面構成時におけるGUI画面の一例を記した図である。
【図３９】図３２に示した3つのAVClipを作成するにあたってのAVClip接続情報の記述を示す図である。
【図４０】（ａ）（ｂ）IDクラスソースコードのプレイリストにアクセスするためのヘッダファイルのソースコードの例を図示したものである。
【図４１】ファイル関連付け情報を示す図である。
【図４２】図４１のファイル関連付け情報に基づく、BD-ROM上のアロケーションを示す図である。
【図４３】インターリーブ配置の一例を示す図である。
【図４４】記録装置におけるオーサリング手順を示すフローチャートである。
【図４５】シームレス動画メニューの構成を持つシナリオデータの作成の手順を記したものである。
【図４６】第５実施形態における再生装置の内部構成を示す図である。
【図４７】（ａ）（ｂ）IGストリームの構成と、機能セグメントを変換することで得られるPESパケットとを示す図である。
【図４８】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図４９】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図５０】（ａ）（ｂ）ICSとInteractive_compositionとの対応関係を示す図である。
【図５１】ICSの内部構成を示す図である。
【図５２】1つのEpochにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。
【図５３】Page情報(y)におけるボタン情報(i)の内部構成を示す図である。
【図５４】IGストリームが、IGデコーダ６の構成要素により、どのように処理されるかを示す図である。
【図５５】（ａ）（ｂ）2つのAVClip間で連続性をもつようなEpochを示すと共に、Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。
【図５６】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【図５７】PGストリームの具体的な構成を示す図である。
【図５８】字幕の表示位置と、Epochとの関係を示す図である。
【図５９】（ａ）（ｂ）WDS,PCSのデータ構造を示す図である。
【図６０】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図６１】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【符号の説明】
【０２６２】
１  BD-ROMドライブ
２  Read Buffer
３  多重分離部
４  ビデオデコーダ
５  オーディオデコーダ
６  IGデコーダ
７  PGデコーダ
８a,b,c,d  プレーンメモリ
９a  ユーザイベント処理部
９b  データ解析実行部
１０  タイトル構造作成部
１１  BDシナリオ生成部
１６  リールセット編集部
２０  ＪＡＶＡ（登録商標）プログラミング部
３０  素材作成/インポート部
４０  ディスク作成部
５０  検証装置
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2007119765.tif 000064
【図２】
2007119765.tif 000065
【図３】
2007119765.tif 000066
【図４】
2007119765.tif 000067
【図５】
2007119765.tif 000068
【図６】
2007119765.tif 000069
【図７】
2007119765.tif 000070
【図８】
2007119765.tif 000071
【図９】
2007119765.tif 000072
【図１０】
2007119765.tif 000073
【図１１】
2007119765.tif 000074
【図１２】
2007119765.tif 000075
【図１３】
2007119765.tif 000076
【図１４】
2007119765.tif 000077
【図１５】
2007119765.tif 000078
【図１６】
2007119765.tif 000079
【図１７】
2007119765.tif 000080
【図１８】
2007119765.tif 000081
【図１９】
2007119765.tif 000082
【図２０】
2007119765.tif 000083
【図２１】
2007119765.tif 000084
【図２２】
2007119765.tif 000085
【図２３】
2007119765.tif 000086
【図２４】
2007119765.tif 000087
【図２５】
2007119765.tif 000088
【図２６】
2007119765.tif 000089
【図２７】
2007119765.tif 000090
【図２８】
2007119765.tif 000091
【図２９】
2007119765.tif 000092
【図３０】
2007119765.tif 000093
【図３１】
2007119765.tif 000094
【図３２】
2007119765.tif 000095
【図３３】
2007119765.tif 000096
【図３４】
2007119765.tif 000097
【図３５】
2007119765.tif 000098
【図３６】
2007119765.tif 000099
【図３７】
2007119765.tif 000100
【図３８】
2007119765.tif 000101
【図３９】
2007119765.tif 000102
【図４０】
2007119765.tif 000103
【図４１】
2007119765.tif 000104
【図４２】
2007119765.tif 000105
【図４３】
2007119765.tif 000106
【図４４】
2007119765.tif 000107
【図４５】
2007119765.tif 000108
【図４６】
2007119765.tif 000109
【図４７】
2007119765.tif 000110
【図４８】
2007119765.tif 000111
【図４９】
2007119765.tif 000112
【図５０】
2007119765.tif 000113
【図５１】
2007119765.tif 000114
【図５２】
2007119765.tif 000115
【図５３】
2007119765.tif 000116
【図５４】
2007119765.tif 000117
【図５５】
2007119765.tif 000118
【図５６】
2007119765.tif 000119
【図５７】
2007119765.tif 000120
【図５８】
2007119765.tif 000121
【図５９】
2007119765.tif 000122
【図６０】
2007119765.tif 000123
【図６１】
2007119765.tif 000124
【国際調査報告】
2007119765.tif 000125
2007119765.tif 000126
2007119765.tif 000127
2007119765.tif 000128