JPWO2007119765A1 - 記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム - Google Patents

記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム Download PDF

Info

Publication number
JPWO2007119765A1
JPWO2007119765A1 JP2008510974A JP2008510974A JPWO2007119765A1 JP WO2007119765 A1 JPWO2007119765 A1 JP WO2007119765A1 JP 2008510974 A JP2008510974 A JP 2008510974A JP 2008510974 A JP2008510974 A JP 2008510974A JP WO2007119765 A1 JPWO2007119765 A1 JP WO2007119765A1
Authority
JP
Japan
Prior art keywords
information
stream
avclip
playback
play item
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2008510974A
Other languages
English (en)
Inventor
澤田　泰治
泰治 澤田
洋 矢羽田
洋 矢羽田
智輝 小川
智輝 小川
上坂　靖
靖 上坂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2007119765A1 publication Critical patent/JPWO2007119765A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/005—Reproducing at a different information rate from the information rate of recording
    • G11B27/007—Reproducing at a different information rate from the information rate of recording reproducing continuously a part of the information, i.e. repeating
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10675—Data buffering arrangements, e.g. recording or playback buffers aspects of buffer control
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10805—Data buffering arrangements, e.g. recording or playback buffers involving specific measures to prevent a buffer overflow
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8227—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being at least another television signal

Abstract

BD-ROM１００は、動画像を背景画としたメニュー表示を、再生装置に行わせるものであり、動画像を構成するAVClip、メニュー表示を介した操作待ちの制御を再生装置に行わせるBD-JObject、PlayList情報がが記録されている。このPlayList情報は、999個のPlayItem情報からなるシーケンスを有しており、このシーケンスは、各々のPlayItem情報が、1つのAVClipに対応していて、このAVClipの再生を999回、繰り返す旨を、再生装置に指示する。

Description

本発明は、対話制御技術の技術分野に属する発明である。
対話制御技術とは、動画像にメニューを合成させ、このメニューに対するユーザ操作に応じて再生制御を実現するという技術である。本技術は、再生すべきタイトルやチャプターの選択、クイズの設問に対する回答等、ユーザ操作に対する対話機能の実現に必須の機能であり、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作品をより多く市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
本発明は、対話制御技術の技術分野に属する発明である。
対話制御技術とは、動画像にメニューを合成させ、このメニューに対するユーザ操作に応じて再生制御を実現するという技術である。本技術は、再生すべきタイトルやチャプターの選択、クイズの設問に対する回答等、ユーザ操作に対する対話機能の実現に必須の機能であり、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シナリオ生成部
１６ リールセット編集部
２０ ＪＡＶＡ（登録商標）プログラミング部
３０ 素材作成/インポート部
４０ ディスク作成部
５０ 検証装置

Claims (20)

  1. 動画像を背景画としたメニュー表示を、再生装置に行わせる記録媒体であって、
    動画像を構成するAVストリームと、
    メニュー表示を介した操作待ちの制御を再生装置に行わせるプログラムと、
    プレイリスト情報とが記録されており、
    前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、プレイアイテムシーケンスは、各々のプレイアイテム情報が、1つのAVストリームに対応していて、当該AVストリームの再生を繰り返す旨を、再生装置に指示する
    ことを特徴とする記録媒体。
  2. 前記プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
    前記ユーザ操作待ちの制御は、
    前記再生コマンドの実行を、再生装置に反復させることでなされる
    ことを特徴とする請求項１記載の記録媒体。
  3. 各々のプレイアイテム情報は接続情報を有しており、当該接続情報は、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行うべき旨を示す
    ことを特徴とする請求項１記載の記録媒体。
  4. 前記AVストリームの先端部分の割当符号量は、同じAVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファの容量以下に定められている
    ことを特徴とする請求項１記載の記録媒体。
  5. AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
    プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報は、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
    偶数番目のプレイアイテム情報は、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示す
    ことを特徴とする請求項１記載の記録媒体。
  6. AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
    バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
    ことを特徴とする請求項１記載の記録媒体。
  7. 動画像を背景画としたメニュー表示を実現する再生装置であって、
    記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
    記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
    前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
    前記制御手段は、
    個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
    ことを特徴とする再生装置。
  8. 前記制御手段は、プログラムを構成するコマンドを実行するものであり、
    前記再生手段は、
    制御手段によるコマンドの実行結果に基づき、プレイリスト情報を介したAVストリームの再生を行うものであり、
    操作待ち制御は、
    プログラムに含まれる再生コマンドの実行を、制御手段が反復することでなされる
    ことを特徴とする請求項７記載の再生行装置。
  9. 前記再生手段は、装置内部の基準クロックに基づき、再生動作を行い、
    1つのプレイアイテム情報がシームレス接続を意味する接続情報を有している場合、基準クロックにオフセットを加算することにより、１のプレイアイテム情報によるAVストリーム読み出し時と、直前のプレイアイテム情報によるAVストリーム読み出し時とで、基準クロックにて示されるカウント値を、連続させる
    ことを特徴とする請求項７記載の再生装置。
  10. 前記再生手段は、デコーダと、当該デコーダにデータを供給するバッファとを有しており、
    前記バッファの容量は、
    前記AVストリームの先端部分と、AVストリームの終端部分とを同時に格納しうる容量である
    ことを特徴とする請求項７記載の再生装置。
  11. AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
    プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報がカレントのプレイアイテム情報として選択されている場合、前記再生手段は、第１のAVクリップの再生を繰り返す旨を示し、
    偶数番目のプレイアイテム情報がカレントのプレイアイテムとして選択されている場合、第２のAVクリップの再生を繰り返す
    ことを特徴とする請求項７記載の再生装置。
  12. 記録装置であって、
    背景画となる動画像の指定を、ユーザから受け付ける受付手段と、
    動画像の素材をエンコードすることで、指定された動画像に対応するAVストリームを得るエンコーダと、
    複数のプレイアイテム情報からなるプレイアイテムシーケンスを有するプレイリスト情報を生成する第１生成手段と、
    操作待ち制御を再生装置に行わせるプログラムを生成する第２生成手段とを備え、
    前記第１生成手段は、
    前記1つのAVストリームに対応するプレイアイテム情報を複数生成することで、プレイアイテムシーケンスを得る
    ことを特徴とする記録装置。
  13. プログラムは、プレイリスト情報を介したAVストリームの再生を再生装置に命じる再生コマンドを含み、
    第２生成手段は、
    前記再生コマンドの実行を反復させるコマンドを、プログラム内に記述することで、ユーザ操作待ちの制御を、再生装置に行わせる
    ことを特徴とする請求項１２記載の記録装置。
  14. 各々のプレイアイテム情報は接続情報を有しており、
    前記第１生成手段は、
    プレイアイテムシーケンスの生成にあたって、１のプレイアイテム情報によるAVストリームの再生と、直前のプレイアイテム情報によるAVストリームの再生とを、シームレスに行わせる旨を、接続情報に示させる、ことを特徴とする請求項１２記載の記録装置。
  15. 前記エンコーダは、
    AVストリームの終端部分が、デコーダ内のバッファに存在する状態におけるバッファ容量に基づき、入力制限直線を導き出して、かかる入力制限直線に基づき、AVストリームの先端部分に対する割当符号量を決定する
    ことを特徴とする請求項１２記載の記録装置。
  16. AVストリームは、第１のAVクリップ、第２のAVクリップから構成され、
    前記第１生成手段は、
    プレイアイテムシーケンスのうち、奇数番目のプレイアイテム情報が、第１のAVクリップの再生を、再生装置に命じることで、当該第１のAVクリップの再生を繰り返す旨を示し、
    偶数番目のプレイアイテム情報が、第２のAVクリップの再生を、再生装置に命じることで、当該第２のAVクリップの再生を繰り返す旨を示すよう、プレイリスト情報を生成する
    ことを特徴とする請求項１２記載の記録装置。
  17. AVストリームに多重化されているビデオストリームには、バッファリングディレイに基づく符号量が割り当てられており、
    バッファリングディレイとは、1つのプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレーム及びオーディオフレームの、バッファへの入力が終了する入力終了時点から、直後のプレイアイテム情報にて参照されるAVストリームにおいて、ビデオフレームの最初のデコードが終了するデコード終了時点までの時間間隔である
    ことを特徴とする請求項１２記載の記録装置。
  18. 再生装置に組込まれ、動画像を背景画としたメニュー表示を再生装置に行わせるシステムLSIであって、
    記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御手段と、
    記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生手段とを備え、
    前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
    前記制御手段は、
    個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生手段への、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
    ことを特徴とするシステムLSI。
  19. 動画像を背景画としたメニュー表示を行う再生方法であって、
    記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
    記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとを有し
    前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
    前記制御ステップは、
    個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する
    ことを特徴とする再生方法。
  20. 動画像を背景画としたメニュー表示を、コンピュータに行わせるプログラムであって、
    記録媒体に記録されたプログラムに基づき、操作待ち制御を実行する制御ステップと、
    記録媒体に記録されたプレイリスト情報に基づき、AVストリームを再生する再生ステップとをコンピュータに実行させ
    前記プレイリスト情報は、複数のプレイアイテム情報からなるプレイアイテムシーケンスを有しており、
    前記制御ステップは、
    個々のプレイアイテム情報に対応するAVストリームの読み出しと、再生ステップへの、AVストリームの投入とを繰り返し実行することで、背景画となる動画像の再生を継続する制御を、コンピュータに行わせる
    ことを特徴とするプログラム。
JP2008510974A 2006-04-13 2007-04-12 記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム Pending JPWO2007119765A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2006110827 2006-04-13
JP2006110827 2006-04-13
PCT/JP2007/058032 WO2007119765A1 (ja) 2006-04-13 2007-04-12 記録媒体、再生装置、記録装置、システムlsi、方法、プログラム

Publications (1)

Publication Number Publication Date
JPWO2007119765A1 true JPWO2007119765A1 (ja) 2009-08-27

Family

ID=38609525

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008510974A Pending JPWO2007119765A1 (ja) 2006-04-13 2007-04-12 記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム

Country Status (3)

Country Link
US (1) US20090055744A1 (ja)
JP (1) JPWO2007119765A1 (ja)
WO (1) WO2007119765A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008053515A1 (en) * 2006-10-30 2008-05-08 Thomson Licensing Editing device and editing method using metadata
JP4882989B2 (ja) * 2007-12-10 2012-02-22 ソニー株式会社 電子機器、再生方法及びプログラム
US8515052B2 (en) 2007-12-17 2013-08-20 Wai Wu Parallel signal processing system and method
FR2976098B1 (fr) * 2011-06-06 2013-07-12 Myriad France Procede d'affichage d'une image elementaire d'une image composee et dispositif de visualisation associe

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0963251A (ja) * 1995-08-21 1997-03-07 Matsushita Electric Ind Co Ltd マルチメディア光ディスクおよび再生装置および記録方法
US5990972A (en) * 1996-10-22 1999-11-23 Lucent Technologies, Inc. System and method for displaying a video menu
WO2004032141A1 (ja) * 2002-10-01 2004-04-15 Pioneer Corporation 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
WO2005004477A1 (ja) * 2003-07-01 2005-01-13 Pioneer Corporation 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
WO2005045840A1 (ja) * 2003-11-10 2005-05-19 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム、再生方法、システム集積回路

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU698969B2 (en) * 1995-04-14 1998-11-12 Kabushiki Kaisha Toshiba Recording medium, device and method for recording data on the medium, and device and method for reproducing data from the medium
US20030113096A1 (en) * 1997-07-07 2003-06-19 Kabushiki Kaisha Toshiba Multi-screen display system for automatically changing a plurality of simultaneously displayed images
ID29305A (id) * 1997-12-15 2001-08-16 Matsushita Electric Ind Co Ltd Piringan optik, aparatus perekaman, media penyimpanan komputer-yang-dapat-membaca yang menyimpan program perekaman, dan metoda perekaman
US6573905B1 (en) * 1999-11-09 2003-06-03 Broadcom Corporation Video and graphics system with parallel processing of graphics windows
US6538656B1 (en) * 1999-11-09 2003-03-25 Broadcom Corporation Video and graphics system with a data transport processor
US6678332B1 (en) * 2000-01-04 2004-01-13 Emc Corporation Seamless splicing of encoded MPEG video and audio
EP1133190A1 (en) * 2000-03-06 2001-09-12 Canon Kabushiki Kaisha Moving image generation apparatus, moving image playback apparatus, their control method, and storage medium
EP1551027A4 (en) * 2002-09-12 2009-08-05 Panasonic Corp RECORDING MEDIUM, REPRODUCTION DEVICE, PROGRAM, REPRODUCTION METHOD, AND RECORDING METHOD
US7043477B2 (en) * 2002-10-16 2006-05-09 Microsoft Corporation Navigating media content via groups within a playlist
US7136874B2 (en) * 2002-10-16 2006-11-14 Microsoft Corporation Adaptive menu system for media players
KR101193397B1 (ko) * 2004-12-01 2012-10-24 파나소닉 주식회사 재생장치, 화상합성방법, 컴퓨터 판독 가능한 기록매체 및 집적회로
US20060143566A1 (en) * 2004-12-28 2006-06-29 Meng-Han Tsai Recording medium, method for previewing on-demand digital multimedia data on the recording medium

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0963251A (ja) * 1995-08-21 1997-03-07 Matsushita Electric Ind Co Ltd マルチメディア光ディスクおよび再生装置および記録方法
US5990972A (en) * 1996-10-22 1999-11-23 Lucent Technologies, Inc. System and method for displaying a video menu
WO2004032141A1 (ja) * 2002-10-01 2004-04-15 Pioneer Corporation 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
WO2005004477A1 (ja) * 2003-07-01 2005-01-13 Pioneer Corporation 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
WO2005045840A1 (ja) * 2003-11-10 2005-05-19 Matsushita Electric Industrial Co., Ltd. 記録媒体、再生装置、プログラム、再生方法、システム集積回路

Also Published As

Publication number Publication date
US20090055744A1 (en) 2009-02-26
WO2007119765A1 (ja) 2007-10-25

Similar Documents

Publication Publication Date Title
JP4268637B2 (ja) 記録媒体、再生装置、プログラム、再生方法。
JP4886837B2 (ja) 再生装置
JP4676493B2 (ja) 記録媒体、再生装置、記録方法
JP4395543B2 (ja) 再生装置
JP4571213B2 (ja) 再生装置、プログラム、再生方法
US7873264B2 (en) Recording medium, reproduction apparatus, program, and reproduction method
JPWO2007119765A1 (ja) 記録媒体、再生装置、記録装置、システムｌｓｉ、方法、プログラム
JP4870493B2 (ja) 再生装置、記録方法、再生方法、システムｌｓｉ、プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111108

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120105

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120131