WO2001082611A1

WO2001082611A1 - Procede et appareil de traitement d'informations, support enregistre, et programme

Info

Publication number: WO2001082611A1
Application number: PCT/JP2001/003418
Authority: WO
Inventors: Motoki Kato; Toshiya Hamada
Original assignee: Sony Corporation
Priority date: 2000-04-21
Filing date: 2001-04-20
Publication date: 2001-11-01
Also published as: US20070217296A1; US8355619B2; US20070217297A1; US7865062B2; US20020150383A1; US7580613B2

Description

明細書情報処理装置及び方法、記録媒体、並びにプログラム技術分野本発明は、情報処理装置及び方法、記録媒体、並びにプログラムに関し、特に、記録媒体に記録されているデ一夕の内容の管理情報をファイル化して記録する情報処理装置及び方法、記録媒体、並びにプログラムに関する。背景技術近年、記録再生装置から取り外し可能なディスク型の記録媒体として、各種の光ディスクが提案されつつある。このような記録可能な光ディスクは、数ギガバイトの大容量メディアとして提案されており、ビデオ信号等の AV (Audio Visu al) 信号を記録するメディアとしての期待が高い。この記録可能な光ディスクに記録するディジタルの A V信号のソース（供給源）としては、 CSディジタル衛星放送や B Sディジタル放送があり、また、将来はディジタル方式の地上波テレビジョン放送等も提案されている。

ここで、これらのソースから供給されるディジタルビデオ信号は、通常 MPE G (Moving Picture Experts Group) 2方式で画像圧縮されているのが一般的である。また、記録装置には、その装置固有の記録レートが定められている。従来の民生用映像蓄積メディアで、ディジタル放送由来のディジ夕ルビデオ信号を記録する場合、アナログ記録方式であれば、ディジタルビデオ信号をデコード後、帯域制限をして記録する。或いは、 MPEG 1 V i d e o, MPEG2 V i d e o、 DV方式をはじめとするディジタル記録方式であれば、 1度デコードされた後に、その装置固有の記録レ一ト ·符号化方式で再エンコードされて記録される。

しかしながら、このような記録方法は、供給されたビットストリームを 1度デコードし、その後で帯域制限や再エンコードを行って記録するため、画質の劣化を伴う。画像圧縮されたディジタル信号の記録をする場合、入力されたデイジ夕ル信号の伝送レートが記録再生装置の記録レ一トを超えない場合には、供給されたビットストリームをデコードや再エンコードすることなく、そのまま記録する方法が最も画質の劣化が少ない。但し、画像圧縮されたディジタル信号の伝送レ ―トが記録媒体としてのディスクの記録レートを超える場合には、記録再生装置でデコード後、伝送レートがディスクの記録レートの上限以下になるように、再ェンコ一ドをして記録する必要はある。

また、入力ディジタル信号のビットレートが時間により増減する可変レート方式によって伝送されている場合には、回転へッドが固定回転数であるために記録レートが固定レートになるテープ記録方式に比べ、 1度バヅファにデータを蓄積し、バ一スト的に記録ができるディスク記録装置が記録媒体の容量をより無駄なく利用できる。

以上のように、ディジタル放送が主流となる将来においては、デ一タストリ一マのように放送信号をディジタル信号のまま、デコードや再エンコードすることなく記録し、記録媒体としてディスクを使用した記録再生装置が求められると予測される。

上述したように、記録媒体の容量が増大することにより、その記録媒体には、多くのデ一夕（この場合、番組に関する映像や音声等）が記録できるようになる ₍ したがって、 1枚のディスクに多くの番組が記録されることになり、ュ一ザが、それらのディスク内に記録されている多くの番組から視聴したい 1番組を選択するといったような操作が煩雑になってしまう。そこで、ュ一ザがディスクの再生時に、簡便に記録されているデータを確認し、所望の番組（デ一夕）が選択できるようにする必要があるといった課題があった。発明の開示本発明はこのような状況に鑑みてなされたものであり、記録媒体に記録されているデータの内容の管理情報をファイル化して記録することにより、記録媒体に記録されているデータ内容、及び、再生情報を適切に管理することができるようにすることを目的とする。

本発明に係る情報処理装置は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成手段と、生成手段により生成された再生指定情報と管理情報を記録媒体に記録する記録手段とを有し、管理情報は、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。

本発明に係る情報処理方法は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成ステツプと、生成ステップの処理により生成された再生指定情報と管理情報を記録媒体に記録する記録ステップとを含み、管理情報は、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。本発明に係る記録媒体のプログラムは、管理情報が、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。

本発明に係るプログラムは、管理情報が、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。

本発明に係る情報処理装置は、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含む管理情報と、再生指定情報に基づく再生が終了された時点の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御手段を備える。

本発明に係る情報処理方法は、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含む管理情報と、再生指定情報に基づく再生が終了された時点の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステップを含む。本発明に係る記録媒体のプログラムは、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含む管理情報と、再生指定情報に基づく再生が終了された時点の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステツプを含む。

本発明に係るプログラムは、記録されている主情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報が記録されている記録媒体から、主情報を再生する情報処理装置を制御するコンピュータに、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含む管理情報と、再生指定情報に基づく再生が終了された時点の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステツプを実行させる。

本発明に係る記録媒体は、管理情報が、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。

本発明に係る情報処理装置は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成手段と、生成手段により生成された再生指定情報と管理情報を記録媒体に記録する記録手段とを有し、管理情報は、管理情報が管理する全ての再生指定情報についての閲覧の許可に闋する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。

本発明に係る情報処理方法は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成ステツプと、生成ステップの処理により生成された再生指定情報と管理情報を記録媒体に記録する記録ステップとを含み、管理情報は、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。

本発明に係る記録媒体のプログラムは、管理情報が、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。本発明に係るプログラムは、管理情報が、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。

本発明に係る記録媒体は、管理情報が、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。

本発明に係る情報処理装置は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成手段と、生成手段により生成された管理情報を記録媒体に記録する記録手段とを有し、管理情報は、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報'を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明に係る情報処理方法は、記録媒体に記録されている情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報を生成する生成ステツブと、生成ステップの処理により生成された管理情報を記録媒体に記録する記録ステップとを含み、管理情報は、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明に係る記録媒体のプログラムは、管理情報が、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明に係るプログラムは、管理情報が、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明に係る情報処理装置は、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含む前記管理情報と、再生区間の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御手段を備える。本発明に係る情報処理方法は、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含む管理情報と、再生区間の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステップを含む。本発明に係る記録媒体のプログラムは、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含む管理情報と、再生区間の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステップを含む。

本発明に係るプログラムは、記録されている主情報の再生手順を指定する再生指定情報と、再生指定情報を管理する管理情報が記録されている記録媒体から、主情報を再生する情報処理装置を制御するコンピュータに、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含む管理情報と、再生区間の時間情報を含む再生指定情報に基づいて、記録媒体の主情報の再生を制御する制御ステヅプを実行させる。

本発明に係る記録媒体は、管理情報が、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明に係る情報処理装置及び方法、記録媒体、並びにプログラム、並びに第 2の情報処理装置及び方法、記録媒体、並びにプログラムにおいては、管理情報は、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報は、再生指定情報に基づく再生が終了された時点の時間情報を含む。

本発明に係る情報処理装置及び方法、記録媒体、並びにプログラム、並びに第 4の情報処理装置及び方法、記録媒体、並びにプログラムにおいては、管理情報は、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報は、再生指定情報の閲覧の許可に関する閲覧許可情報を含む。

本発明に係る情報処理装置及び方法、記録媒体、並びにプログラムにおいては、管理情報は、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報は、その再生区間の時間情報を含む。

本発明の更に他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくよ b詳細な説明によって明らかになるであろう。図面の簡単な説明図 1は、本発明を適用した記録再生装置の構成を示す図である。

図 2は、記録再生装置により記録媒体に記録されるデータのフォーマツトについて説明する図である。

図 3は、 Real PlayListと Virtual PlayListについて説明する図である。

図 4 A〜図 4 Cは、 Real PlayListの作成について説明する図である。

図 5 A〜図 5 Cは、 Real PlayListの削除について説明する図である。

図 6 A及ぴ図 Bは、アセンブル編集について説明する図である。

図 7は、 Virtual PlayListにサブパスを設ける場合について説明する図である, 図 8は、 PlayListの再生順序の変更について説明する図である。

図 9は、 PlayList上のマークと CHp上のマ一クについて説明する図である。図 1 0は、メニューサムネイルについて説明する図である。

図 1 1は、 PlayListに付加されるマ一クについて説明する図である。

図 1 2は、クリヅプに付加されるマークについて説明する図である。

図 1 3は、 PlayList、 Cl ip, サムネイルファイルの関係について説明する図である。

図 1 4は、ディレクトリ構造について説明する図である。

図 1 5は、 info. dvrのシンタクスを示す図である。

図 1 6は、 DVR volumeのシンタクスを示す図である。

図 1 7は、 iiesuinevolumeのシンタクスを示す図である。

図 1 8は、 UIAppInfovolumeのシンタクスを示す図である。

図 1 9は、 Character set valueのテーブルを示す図である。

図 2 0は、 TableOfPlayListのシンタクスを示す図である。

図 2 1は、 TableOfPlayListの他のシンタクスを示す図である。

図 2 2は、 MakersPrivateDataのシンタクスを示す図である。

図 2 3は、 xxxxx.rplsと yyyyy.vplsのシンタクスを示す図である。

図 2 4 A〜図 2 4 Cは、 PlayListについて説明する図である。

図 2 5は、 PlayListのシンタクスを示す図である。図 2 6は、 PlayList_typeのテーブルを示す図である。

図 2 7は、 UIAppinfoPlayListのシンタクスを示す図である。

図 2 8 A〜図 2 8 Cは、図 2 7に示した UIAppinfoPlayListのシン夕クス内のフラグについて説明する図である。

図 2 9は、 Playltemについて説明する図である。

図 3 0は、 Playltemについて説明する図である。

' 図 3 1は、 Playltemについて説明する図である。

図 3 2は、 Playltemのシンタクスを示す図である。

図 3 3は、 IiLtimeについて説明する図である。

図 3 4は、 0UT_timeについて説明する図である。

図 3 5は、 Connection— Conditionのテーブルを示す図である。

図 3 6 A〜図 3 6 Dは、 Connection—Conditionについて説明する図である。図 3 7は、 BridgeSequencelnfoを説明する図である。

図 3 8は、 BridgeSequencelnfoのシンタクスを示す図である。

図 3 9は、 SubPlayltemについて説明する図である。

図 4 0は、 SubPlayltemのシンタクスを示す図である。

図 4 1は、 SubPath_typeのテーブルを示す図である。

図 4 2は、 PlayListMarkのシンタクスを示す図である。

図 4 3は、 Mark_typeのテーブルを示す図である。

図 4 4は、 Mark_tiuie_staDipを説明する図である。

図 4 5は、 zzzzz . cl ipのシンタクスを示す図である。

図 4 6は、 Cl iplnfoのシンタクスを示す図である。

図 4 7は、 Cl ip_streaii_typeのテ一ブルを示す図である。

図 4 8は、 offset_SPNについて説明する図である。

図 4 9は、 offset_SPNについて説明する図である。

図 5 0 A及び図 5 0 Bは、 STC区間について説明する図である。

図 5 1は、 STCJnfoについて説明する図である。

図 5 2は、 STC_Infoのシンタクスを示す図である。

図 5 3は、 Programlnfoを説明する図である。図 5 4は、 Programlnfoのシンタクスを示す図である。

図 5 5は、 VideoCondinglnfoのシンタクスを示す図である。

図 5 6は、 Video— formatのテーブルを示す図である。

図 5 7は、： raiie_rateのテーブルを示す図である。

図 5 8は、 display— aspect_ratioのテーブルを示す図である。

図 5 9は、 AudioCondinglnfoのシンタクスを示す図である。

図 6 0は、 audio_codingのテーブルを示す図である。

図 6 1は、 audio_component_typeのテーブルを示す図である。

図 6 2は、 sampl ing_frequencyのテーブルを示す図である。

図 6 3は、 CPIについて説明する図である。

図 6 4は、 CPIについて説明する図である。

図 6 5は、 CPIのシン夕クスを示す図である。

図 6 6は、 CPI_typeのテーブルを示す図である。

図 6 7は、ビデオ EP_mapについて説明する図である。

図 6 8は、 EP_mapについて説明する図である。

図 6 9は、 EPjnapについて説明する図である。

図 7 0は、 EP_mapのシンタクスを示す図である。

図 7 1は、 EP— type valuesのテーブルを示す図である。

図 7 2は、 EP_map_for— one— stream_PIDのシンタクスを示す図である。

図 7 3は、 TU_mapについて説明する図である。

図 7 4は、 TU_mapのシンタクスを示す図である。

図 7 5は、 Cl ipMarkのシンタクスを示す図である。

図 7 6は、 mark_typeのテーブルを示す図である。

図 7 7は、 mark一 type_stampのテーブルを示す図である。

図 7 8は、 menu. thmbと mark. thmbのシンタクスを示す図である。

図 7 9は、 Thumbnai lのシンタクスを示す図である。

図 8 0は、 thumbnaiし picture一 formatのテーブルを示す図である。

図 8 1 A及ぴ図 8 1 Bは、 tn_blockについて説明する図である。

図 8 2は、 DVR MPEG 2のトランスポートストリームの構造について説明する図である。

図 8 3は、 DVR MPEG 2のトランスポートストリームのレコーダモデルを示す図である。

図 8 4は、 DVR MPEG 2のトランスポートストリームのプレーヤモデルを示す図である。

図 8 5は、 source packetのシンタクスを示す図である。

図 8 6は、 TP_extra_headerのシンタクスを示す図である。

図 8 7は、 copy permiss ion indicatorのテ一ブルを示す図である。

図 8 8は、シームレス接続について説明する図である。

図 8 9は、シームレス接続について説明する図である。

図 9 0は、シームレス接続について説明する図である

図 9 1は、シームレス接続について説明する図である。

図 9 2は、シームレス接続について説明する図である

図 9 3は、オーディオのォ一バーラヅプについて説明する図である。

図 9 4は、 BridgeSequenceを用いたシームレス接続について説明する図である図 9 5は、 BridgeSequenceを用いないシームレス接続について説明する図である。

図 9 6は、 DVR STDモデルを示す図である。

図 9 7は、復号、表示のタイミングチャートを示す図である。

図 9 8は、 info. dvrの作成/更新の処理を説明するフローチャートである。図 9 9は、プレイリストを再生する処理を説明するフローチャートである。図 1 0 0は、 P layLi stの再生順序を変更する処理を説明するフローチャートである。

図 1 0 1は、媒体を説明する図である。発明を実施するための最良の形態以下に、本発明が適用された情報処理装置及び方法、記録媒体、並びにプログラムについて、図面を参照して説明する。図 1は、本発明を適用した記録再生装置 1の内部構成例を示す図である。先ず、外部から入力された信号を記録媒体に記録する動作を行う部分の構成について説明する。記録再生装置 1は、アナログデータ、又は、ディジタルデータを入力し、記録することができる。

端子 1 1には、アナログのビデオ信号が、端子 1 2には、アナログのオーディォ信号が、それぞれ入力される。端子 1 1に入力されたビデオ信号は、解析部 1 4と A Vエンコーダ 1 5に、それぞれ出力される。端子 1 2に入力されたオーディォ信号は、 A Vエンコーダ 1 5に出力される。解析部 1 4は、. 入力されたビデォ信号からシーンチェンジ等の特徴点を抽出する。

A Vエンコーダ 1 5は、入力されたビデオ信号とオーディオ信号を、それそれ符号化し、符号化ビデオストリーム（V ) 、符号化オーディオストリ一ム（A ) 、及び A V同期等のシステム情報（S ) をマルチプレクサ 1 6に出力する。

符号化ビデオストリームは、例えば、 M P E G (Moving Pi cture Expert Grou p) 2方式により符号化されたビデオストリームであり、符号化オーディオストリームは、例えば、 M P E G 1方式により符号化されたオーディオストリームや、ドルビー A C 3方式により符号化されたオーディオストリーム等である。マルチプレクサ 1 6は、入力されたビデオ及びオーディオのストリームを、入力システム情報に基づいて多重化して、スイッチ 1 7を介して多重化ストリーム解析部 1 8とソースバケツタイザ 1 9に出力する。

多重化ストリームは、例えば、 M P E G 2 トランスポートストリームや M P E G 2プログラムストリームである。ソースパケヅ夕ィザ 1 9は、入力された多重化ストリームを、そのストリームを記録させる記録媒体 1 0 0のアプリケーションフォーマヅトに従って、ソースパケヅトから構成される A Vストリームを符号化する。 A Vストリームは、 E C C (誤り訂正）符号化部 2 0、変調部 2 1で所定の処理が施され、書込部 2 2に出力される。書込部 2 2は、制御部 2 3から出力される制御信号に基づいて、記録媒体 1 0 0に A Vストリームファイルを書き込む（記録する）。

ディジ夕ルイン夕フエース又はディジタルテレビジョンチューナから入力されるディジ夕ルテレビジョン放送等のトランスポートストリームは、端子 1 3に入力される。端子 1 3に入力されたトランスポートストリームの記録方式には、 2 通りあり、それらは、トランスペアレントに記録する方式と、記録ビットレートを下げる等の目的のために再エンコードをした後に記録する方式である。記録方式の指示情報は、ユーザィン夕フェースとしての端子 2 4から制御部 2 3へ入力される。

入力トランスポ一トストリ一ムをトランスペアレントに記録する場合、端子 1 3に入力されたトランスポートストリームは、多重化ストリーム解析部 1 8と、ソ一スパケヅ夕ィザ 1 9に出力される。これ以降の記録媒体 1 0 0へ A Vストリームが記録されるまでの処理は、上述の入力オーディオ浸透とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。

入力トランスポ一トストリームを再ェンコ一ドした後に記録する場合、端子 1 3に入力されたトランスポートストリームは、デマルチプレクサ 2 6に入力される。デマルチプレクサ 2 6は、入力されたトランスポートストリームに対してデマルチプレクス処理を施し、ビデオストリーム（V ) 、オーディオストリーム ( A ) 、及びシステム情報（S ) を抽出する。

デマルチプレクサ 2 6により抽出されたストリーム（情報）の内、ビデオストリームは A Vデコーダ 2 7に、オーディオストリームとシステム情報はマルチプレクサ 1 6に、それそれ出力される。 A Vデコーダ 2 7は、入力されたビデオストリームを復号し、その再生ビデオ信号を A Vエンコーダ 1 5に出力する。 A V エンコーダ 1 5は、入力ビデオ信号を符号化し、符号化ビデオストリーム（V ) をマルチプレクサ 1 6に出力する。

一方、デマルチプレクサ 2 6から出力され、マルチプレクサ 1 6に入力されたオーディオストリームとシステム情報、及び、 A Vエンコーダ 1 5から出力されたビデオストリームは、入力システム情報に基づいて、多重化されて、多重化ストリームとして多重化ストリーム解析部 1 8とソースパケヅトタイザ 1 9にスィヅチ 1 7を介して出力される。これ以後の記録媒体 1 0 0へ A Vストリームが記録されるまでの処理は、上述の入力オーディオ信号とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。

本例の記録再生装置 1は、 A Vストリームのファイルを記録媒体 1 0 0に記録すると共に、そのファイルを説明するアプリケーションデータベース情報も記録する。アプリケーションデータベース情報は、制御部 2 3により作成される。制御部 2 3への入力情報は、解析部 1 4からの動画像の特徴情報、多重化ストリーム解析部 1 8からの A Vストリームの特徴情報、及び端子 2 4から入力されるュ一ザからの指示情報である。

解析部 1 4から供給される動画像の特徴情報は、入力動画像信号の中の特徴的な画像に関係する情報であり、例えば、プログラムの開始点、シーンチェンジ点、コマーシャル（C M) の開始 ·終了点等の指定情報（マーク）であり、また、その指定場所の画像のサムネイル画像の情報も含まれる。

多重化ストリーム解析部 1 8からの A Vストリームの特徴情報は、記録される A Vストリームの符号化情報に関係する情報であり、例えば、 A Vストリーム内の I ピクチャのアドレス情報、 A Vストリームの符号化パラメ一夕、 A Vストリ —ムの中の符号化パラメ一夕の変化点情報、ビデオストリームの中の特徴的な画像に関係する情報（マーク）等である。

端子 2 4からのユーザの指示情報は、 A Vストリームの中の、ユーザが指定した再生区閭の指定情報、その再生区間の内容を説明するキャラクタ一文字、ユーザが好みのシーンにセヅ卜するブックマークゃリジユーム点の情報等である。制御部 2 3は、上記の入力情報に基づいて、 A Vストリームのデータベース (Cl ip)、 A Vストリームの再生区間（Playltem) をグループ化したもの（Pla yList) のデ一夕ベース、記録媒体 1 0 0の記録内容の管理情報（info. dvr) 、及びサムネィル画像の情報を作成する。これらの情報から構成されるアプリケ一シヨンデータべ一ス情報は、 A Vストリームと同様にして、 E C C符号化部 2 0、変調部 2 1で処理されて、書込部 2 2へ入力される。書込部 2 2は、制御部 2 3 から出力される制御信号に基づいて、記録媒体 1 0 0へデータベースファイルを記録する。

上述したアプリケーシヨンデータベース情報についての詳細は後述する。

このようにして記録媒体 1 0 0に記録された A Vストリ一ムファイル（画像デ —夕と音声デ一夕のファイル）と、アプリケーションデータベース情報が再生される場合、先ず、制御部 2 3は、読出部 2 8に対して、記録媒体 1 0 0からアブリケーシヨンデ一夕ベース情報を読み出すように指示する。そして、読出部 2 8 は、記録媒体 1 0 0からアプリケーションデータペース情報を読み出し、そのァプリケーシヨンデータベース情報は、復調部 2 9、 E C C復号部 3 0の処理を経て、制御部 2 3へ入力される。

制御部 2 3は、アブリケ一シヨンデータベース情報に基づいて、記録媒体 1 0 0に記録されている PlayListの一覧を端子 2 4のュ一ザィン夕フヱースへ出力する。ユーザは、 PlayListの一覧から再生したい PlayListを選択し、再生を指定された PlayListに関する情報が制御部 2 3へ入力される。制御部 2 3は、その Play Listの再生に必要な A Vストリームファイルの読み出しを、読出部 2 8に指示する。読出部 2 8は、その指示に従い、記録媒体 1 0 0から対応する A Vストリームを読み出し復調部 2 9に出力する。復調部 2 9に入力された A Vストリームは、所定の処理が施されることにより復調され、更に E C C復号部 3 0の処理を経て、ソースデパケヅタイザ 3 1出力される。

ソースデパケヅ夕ィザ 3 1は、記録媒体 1 0 0から読み出され、所定の処理が施されたアプリケ一シヨンフォーマヅトの A Vストリームを、デマルチプレクサ 2 6に出力できるストリームに変換する。デマルチプレクサ 2 6は、制御部 2 3 により指定された A Vストリームの再生区間（Playltem) を構成するビデオストリーム（V ) 、オーディオストリーム（A ) 、及び A V同期等のシステム情報 ( S ) を、 A Vデコーダ 2 7に出力する。 A Vデコーダ 2 7は、ビデオストリームとオーディオストリームを復号し、再生ビデオ信号と再生オーディオ信号を、それそれ対応する端子 3 と端子 3 3から出力する。

また、ユーザイン夕フェースとしての端子 2 4から、ランダムアクセス再生や特殊再生を指示する情報が入力された場合、制御部 2 3は、 A Vストリームのデ一夕ベース（Cl ip) の内容に基づいて、記憶媒体 1 0 0からの A Vストリームの読み出し位置を決定し、その A Vストリームの読み出しを、読出部 2 8に指示する。例えば、ユーザにより選択された PlayListを、所定の時刻から再生する場合、制御部 2 3は、指定された時刻に最も近いタイムスタンプを持つ Iピクチャからのデータを読み出すように読出部 2 8に指示する。

また、ユーザによって高速再生（Fast-forward playback) が指示された場合、制御部 2 3は、 A Vストリームのデ一夕ペース（Cl ip) に基づいて、 A Vストリームの中の Iピクチャデ一夕を順次連続して読み出すように読出部 2 8に指示する。

読出部 2 8は、指定されたランダムアクセスポィントから A Vストリームのデ —夕を読み出し、読み出されたデ一夕は、後段の各部の処理を経て再生される。次に、ユーザが、記録媒体 1 0 0に記録されている A Vストリームの編集をする場合を説明する。ユーザが、記録媒体 1 0 0に記録されている A Vストリームの再生区間を指定して新しい再生経路を作成したい場合、例えば、番組 Aという歌番組から歌手 Aの部分を再生し、その後続けて、番組 Bという歌番組の歌手 A の部分を再生したいといった再生経路を作成したい場合、ユーザィンタフエースとしての端子 2 4から再生区間の開始点（イン点）と終了点（アウト点）の情報が制御部 2 3に入力される。制御部 2 3は、 A Vストリームの再生区間（Playlt em) をグループ化したもの（PlayList) のデータペースを作成する。

ユーザが、記録媒体 1 0 0に記録されている A Vストリームの一部を消去したい場合、ュ一ザイン夕フエ一スとしての端子 2 4から消去区間のィン点とァゥト点の情報が制御部 2 3に入力される。制御部 2 3は、必要な A Vストリーム部分だけを参照するように PlayListのデ一夕ペースを変更する。また、 A Vストリームの不必要なストリーム部分を消去するように、書込部 2 2に指示する。

ユーザが、記録媒体 1 0 0に記録されている A Vストリームの再生区間を指定して新しい再生経路を作成したい場合であり、且つ、それそれの再生区間をシームレスに接続したい場合について説明する。このような場合、制御部 2 3は、 A Vストリームの再生区間（Playltem) をグループ化したもの（PlayList) のデー夕ベースを作成し、更に、再生区間の接続点付近のビデオストリームの部分的な再エンコードと再多重化を行う。

先ず、端子 2 4から再生区間のイン点のピクチャの情報と、アウト点のピクチャの情報が制御部 2 3へ入力される。制御部 2 3は、読出部 2 8にイン点側ピクチヤとァゥト点側のピクチャを再生するために必要なデータの読み出しを指示する。そして、読出部 2 8は、記録媒体 1 0 0からデ一夕を読み出し、そのデータは、復調部 2 9、 E C C復号部 3 0、ソースデパケヅ夕ィザ 3 1を経て、デマルチプレクサ 2 6に出力される。制御部 2 3は、デマルチプレクサ 2 6に入力されたデ一夕を解析して、ビデオストリームの再エンコード方法（picture— coding_typeの変更、再エンコードする符号化ビット量の割り当て）と、再多重化方式を決定し、その方式を A Vェンコ —ダ 1 5とマルチプレクサ 1 6に供給する。

次に、デマルチプレクサ 2 6は、入力されたストリームをビデオストリーム ( V ) 、オーディオストリーム（A ) 、及びシステム情報（S ) に分離する。ビデォストリームは、「A Vデコーダ 2 7に入力されるデ一夕」と「マルチプレクサ 1 6に入力されるデ一夕」がある。前者のデ一夕は、再エンコードするために必要なデータであり、これは A Vデコーダ 2 7で復号され、復号されたピクチャは A Vエンコーダ 1 5で再ェンコ一ドされて、ビデオス卜リームにされる。後者のデ一夕は、再ェンコ一ドをしないで、ォリジナルのストリ一ムからコピーされるデ一夕である。オーディオストリーム、システム情報については、直接、マルチプレクサ 1 6に入力される。

マルチプレクサ 1 6は、制御部 2 3から入力された情報に基づいて、入力ストリームを多重化し、多重化ストリームを出力する。多重化ストリームは、 E C C 符号化部 2 0、変調部 2 1で処理されて、書込部 2 2に入力される。書込部 2 2 は、制御部 2 3から供給される制御信号に基づいて、記録媒体 1 0 0に A Vストリームを記録する。

以下に、アプリケーションデータベース情報や、その情報に基づく再生、編集といった操作に関する説明をする。図 2は、アプリケーションフォーマヅトの構造を説明する図である。アプリケーションフォーマットは、 A Vストリームの管理のために PlayListと Cl ipの 2つのレイヤを持つ。 Volume Informationは、ディスク内の全ての Clipと PlayListの管理をする。ここでは、 1つの A Vストリ一ムとその付属情報のペアを 1つのオブジェクトと考え、それを Cl ipという。 A Vストリームファイルは Cl ip AV stream fi leといい、その付属情報は、 Cl ip Inform at ion fi leという。

1つの Cl ip AV stream f i leは、 M P E G 2 トランスポートストリームをアプリケ一シヨンフォーマヅトによって規定される構造に配置したデ一夕をストァする。一般的に、ファイルは、バイト列として扱われるが、 Cl ip AV stream fi leのコンテンヅは、時間軸上に展開され、 Cl ipの中のエントリポイントは、主に時間べ一スで指定される。所定の Cl ipへのアクセスボイントのタイムスタンプが与えられたとき、 Cl ip Information： i leは、 Cl ip AV stream fi leの中でデータの読み出しを鬨始すべきアドレス情報を見つけるために役立つ。

PlayListについて、図 3を参照して説明する。 PlayListは、 Clipの中からユーザが見たい再生区間を選択し、それを簡単に編集することができるようにするために設けられている。 1つの PlayListは、 Cl ipの中の再生区間の集まりである。所定の Cl ipの中の 1つの再生区間は、 Playltemと呼ばれ、それは、時間軸上のィン点（ I N ) とアウト点（O U T ) の対で表される。したがって、 PlayListは、複数の Playltemが集まることにより構成される。

PlayListには、 2つのタイプがある。 1つは、 Real PlayListであり、もう 1つは、 Virtual PlayListである。 Real PlayListは、それが参照している Cl ipのストリーム部分を共有している。すなわち、 Real PlayListは、それの参照している C l ipのストリーム部分に相当するデータ容量をディスクの中で占め、 Real PlayLi stが消去された場合、それが参照している Cl ipのストリーム部分もまたデータが消去される。

Virtual PlayListは、 Cl ipのデータを共有していない。したがって、 Virtual PlayListが変更又は消去されたとしても、 Cl ipの内容には何も変化が生じない。次に、 Real PlayListの編集について説明する。図 4 Aは、 Real PlayListのクリエイト（create：作成）に関する図であり、 A Vストリームが新しい Cl ipとして記録される場合、その Cl ip全体を参照する Real PlayListが新たに作成される操作である。

図 4 Bは、 Real PlayListのディバイド（divide：分割）に関する図であり、 R eal PlayListが所望な点で分けられて、 2つの Real PlayListに分割される操作である。この分割という操作は、例えば、 1つの PlayListにより管理される 1つのクリップ内に、 2つの番組が管理されているような場合に、ユーザが 1つ 1つの番組として登録（記録）し直したいといったようなときに行われる。この操作により、 Cl ipの内容が変更される（Cl ip自体が分割される）ことはない。

図 4 Cは、 Real PlayListのコンバイン（combine：結合）に関する図であり、 2つの Real PlayListを結合して、 1つの新しい Real PlayListにする操作である。この結合という操作は、例えば、ユーザが 2つの番組を 1つの番組として登録し直したいといったようなときに行われる。この操作により、 Cl ipが変更される (Clip自体が 1つにされる）ことはない。

図 5 Aは、 Real PlayList全体のデリート（delete：削除）に関する図であり、所定の Real PlayList全体を消去する操作がされた場合、削除された Real PlayLi stが参照する Cl ipの、対応するストリーム部分も削除される。 '

図 5 Bは、 Real PlayListの部分的な削除に関する図であり、 Real PlayListの所望な部分が削除された場合、対応する Playltemが、必要な Cl ipのストリーム部分だけを参照するように変更される。そして、 Cl ipの対応するストリーム部分は削除される。

図 5 Cは、 Real PlayListのミニマイズ（Minimize：最小化）に関する図であり、 Real PlayListに対応する Playltemを、 Virtual PlayListに必要な Cl ipのストリーム部分だけを参照するようにする操作である。 Virtual PlayList にとつて不必要な Cl ipの、対応するストリーム部分は削除される。

上述したような操作により、 Real PlayListが変更されて、その Real PlayList が参照する Cl ipのストリーム部分が削除された場合、その削除された Cl ipを使用している Virtual PlayListが存在し、その Virtual PlayListにおいて、削除された C 1 ipにより問題が生じる可能性がある。

そのようなことが生じないように、ユーザに、削除という操作に対して、「その Real PlayListが参照している Cl ipのストリーム部分を参照している Virtual P layListが存在し、もし、その Real PlayListが消去されると、その Virtual Play Listもまた消去されることになるが、それでも良いか？」といったメッセージ等を表示させることにより、確認（警告）を促した後に、ユーザの指示により削除の処理を実行、又は、キャンセルする。又は、 Virtual PlayListを削除する代わりに、 Real PlayListに対してミニマイズの操作が行われるようにする。

次に、 Virtual PlayListに対する操作について説明する。 Virtual PlayListに対して操作が行われたとしても、 Cl ipの内容が変更されることはない。図 6 A及び図 6 Bは、アセンブル（Assemble) 編集（I N— O U T 編集）に関する図であり、ユーザが見たいと所望した再生区間の Playltemを作り、 Virtual PlayList を作成するといつた操作である。 Playltem間のシームレス接続が、アプリケーシヨンフォ一マヅトによりサポートされている（後述）。

図 6 Aに示したように、 2つの Real PlayList 1 , 2と、それそれの Real Play Listに対応する Cl ip 1 , 2が存在している場合に、ユーザが Real PlayList 1内の所定の区間（In 1乃至 Out 1までの区間： Playltem 1 ) を再生区間として指示し、続けて再生する区間として、 Real PlayList 2内の所定の区間（In 2乃至 0ut 2までの区間： Playltem 2 ) を再生区間として指示したとき、図 6 Bに示すように、 Playltem 1 と Playltem 2から構成される 1つの Virtual PlayListが作成される。次に、 Virtual PlayList の再編集（Re- editing) について説明する。再編集には、 Virtual PlayListの中のイン点やアウト点の変更、 Virtual PlayListへの新しい Playltemの挿入 ( insert) や追加 (append) 、 Virtual PlayListの中の Play Itemの削除等がある。また、 Virtual PlayListそのものを削除することもできる。図 7は、 Virtual PlayListへのオーディオのアフレコ（Audio dubbing (post recording) ) に関する図であり、 Virtual PlayListへのオーディオのアフレコをサブパスとして登録する操作のことである。このオーディオのアフレコは、ァプリケーシヨンフォーマヅトによりサポ一トされている。 Virtual PlayListのメインパスの A Vストリームに、付加的なオーディオストリームが、サブパスとして付加される。

Real PlayListと Virtual PlayListで共通の操作として、図 8に示すような Pla yListの再生順序の変更（Moving) がある。この操作は、ディスク（ボリューム）の中での PlayUstの再生順序の変更であり、アプリケーションフォーマツトにおいて定義される Table Of PlayList (図 2 0等を参照して後述する）によってサボ —トされる。この操作により、 Cl ipの内容が変更されるようなことはない。

次に、マーク（Mark) について説明する。マークは、 Cl ip及び PlayListの中のハイライトゃ特徴的な時間を指定するために設けられている。 Cl ipに付加されるマークは、 A Vストリームの内容に起因する特徴的なシーンを指定する、例えば、シーンチェンジ点等である。 PlayListを再生するとき、その PlayListが参照する Cl ipのマークを参照して、使用することができる。 PlayListに付加されるマ一クは、主にユーザによってセットされる、例えば、ブックマ一クゃリジユーム点等である。 Cl ip又は PlayListにマ一クをセヅトすることは、マークの時刻を示すタイムスタンプをマークリストに追加することにより行われる。また、マークを削除することは、マークリストの中から、そのマークのタイムスタンプを除去することである。したがって、マークの設定や削除により、 A Vストリームは何の変更もされない。

次にサムネイルについて説明する。サムネイルは、 Volume、 PlayList、及び CI ipに付加される静止画である。サムネイルには、 2つの種類があり、 1つは、内容を表す代表画としてのサムネイルである。これは主としてユーザが力一ソル (不図示）等を操作して見たいものを選択するためのメニュー画面で使われるものである。もう 1つは、マークが指しているシーンを表す画像である。

Volumeと各 Playl istは代表画を持つことができるようにする必要がある。 Volu meの代表画は、ディスク（記録媒体 1 0 0、以下、記録媒体 1 0 0はディスク状のものであるとし、適宜、ディスクと記述する）を記録再生装置 1の所定の場所にセットしたときに、そのディスクの内容を表す静止画を最初に表示する場合等に用いられることを想定している。 Playl istの代表画は、 Playl istを選択するメニュー画面において、 Playl istの内容を表すための静止画として用いられることを想定している。

Playl istの代表画として、 Playl istの最初の画像をサムネイル（代表画）にすることが考えられるが、必ずしも再生時刻 0の先頭の画像が内容を表す上で最適な画像とは限らない。そこで、 Playl istのサムネイルとして、任意の画像をユーザが設定できるようにする。以上 2種類のサムネイルをメニューサムネイルという。メニューサムネイルは頻繁に表示されるため、ディスクから高速に読み出される必要がある。このため、全てのメニューサムネイルを 1つのファイルに格納することが効率的である。メニューサムネイルは、必ずしもボリューム内の動画から抜き出したピクチャである必要はなく、図 1 0に示すように、パーソナルコンピュー夕やディジ夕ルスチルカメラから取り込まれた画像でもよい。

一方、 Cl ipと Playl istには、複数個のマークを打てる必要があり、マーク位置の内容を知るためにマーク点の画像を容易に見ることができるようにする必要がある。このようなマーク点を表すピクチャをマークサムネイル（Mark Thumbnai l s) という。したがって、サムネイルの元となる画像は、外部から取り込んだ画像よりも、マーク点の画像を抜き出したものが主となる。

図 1 1は、 PlayListに付けられるマークと、そのマークサムネイルの関係について示す図であり、図 1 2は、 Cl ipに付けられるマークと、そのマークサムネィルの閧係について示す図である。マークサムネイルは、メニューサムネイルと異なり、 Playl istの詳細を表すときに、サブメニュー等で使われるため、短いァクセス時間で読み出されるようなことは要求されない。そのため、サムネイルが必要になる度に、記録再生装置 1がファイルを開き、そのファイルの一部を読み出すことで多少時間がかかっても、問題にはならない。

また、ボリューム内に存在するファイル数を減らすために、全てのマークサムネイルは 1つのファイルに格納するのがよい。 Playl istはメニューサムネイル 1 つと複数のマークサムネイルを有することができるが、 Cl ipは直接ユーザが選択する必要性がない（通常、 Playl ist経由で指定する）ため、メニューサムネイルを設ける必要はない。

図 1 3は、上述したことを考慮した場合のメニュ一サムネイル、マークサムネィル、 PlayList、及び Cl ipの関係について示した図である。メニューサムネイルファイルには、 PlayList毎に設けられたメニューサムネイルがファイルされている。ニューサムネイルファイルには、ディスクに記録されているデ一夕の内容を代表するボリュ一ムサムネイルが含まれている。マークサムネイルファイルは、各 PlayList毎と各 Cl ip毎に作成されたサムネイルがファイルされている。

次に、 C P I (Characteristic Point Information) について説明する。 C P Iは、 Cl ipインフォメーションファイルに含まれるデータであり、主に、それは Cl ipへのアクセスポィントの夕ィムスタンプが与えられたとき、 Clip AV stream fi leの中でデ一夕の読み出しを鬨始すべきデ一夕アドレスを見つけるために用いられる。本例では、 2種類の C P Iを用いる。 1つは、 EPjnapであり、もう一つは、 TU_mapである。

EP_mapは、エントリポイント（EP) デ一夕のリストであり、それはエレメンタリーストリーム及ぴトランスポートストリームから抽出されたものである。これは、 A Vストリームの中でデコードを開始すべきェントリポイン卜の場所を見つけるためのアドレス情報を持つ。 1つの EPデ一夕は、プレゼンテーションタイムスタンプ（P T S ) と、その P T Sに対応するアクセスュニヅトの A Vストリームの中のデ一夕ァドレスの対で構成される。

EP_mapは、主に 2つの目的のために使用される。第 1に、 PlayListの中でプレゼンテーシヨンタイムスタンプによって参照されるアクセスュニヅトの A Vストリームの中のデー夕ァドレスを見つけるために使用される。第 2に、ファーストフォヮ一ド再生やファーストリバース再生のために使用される。記録再生装置 1 が、入力 A Vストリームを記録する場合、そのストリームのシンタクスを解析することができるとき、 EP_mapが作成され、ディスクに記録される。

TUjnapは、ディジタルイン夕フェースを通して入力されるトランスポ一トパケヅトの到着時刻に基づいたタイムュニヅト（T U ) デ一夕のリストを持つ。これは、到着時刻ベースの時間と A Vストリ一ムの中のデ一夕アドレスとの関係を与える。記録再生装置 1が、入力 A Vストリームを記録する場合、そのストリームのシンタクスを解析することができないとき、 TlLmapが作成され、ディスクに記録される。

STCInfoは、 M P E G 2 トランスポートストリームをストァしている A Vストリームファイルの中にある S T Cの不連続点情報をストァする。 A Vストリームが S T Cの不連続点を持つ場合、その A Vストリームファイルの中で同じ値の P T Sが現れるかもしれない。そのため、 A Vストリーム上のある時刻を P T Sベ一スで指す場合、アクセスポィントの P T Sだけではそのボイントを特定するためには不十分である。更に、その P T Sを含むところの連続な S T C区間のインデヅクスが必要である。連続な S T C区間を、このフォーマットでは STC- sequenc eと呼ぴ、そのインデックスを STC-sequence-idと呼ぶ。 STC- sequenceの情報は、 Clip Information f i leの STCInfoで定義される。

STC-sequence- idは、 EP_mapを持つ A Vストリームファイルで使用するものであり、 TUjnapを持つ A Vストリームファイルではオプションである。

プログラムは、エレメン夕リストリームの集まりであり、これらのストリームの同期再生のために、ただ 1つのシステムタイムベースを共有するものである。再生装置（図 1の記録再生装置 1 ) にとつて、 A Vストリームのデコードに先だち、その AVストリームの内容が分かることは有用である。例えば、ビデオやォ一ディォのエレメン夕リーストリームを伝送するトランスポートパケヅトの P I Dの値や、ビデオやオーディオのコンポーネント種類（例えば、 HDTVのビデォと MPEG— 2 AA Cのオーディオストリーム等）等の情報である。この情報は AVストリームを参照するところの PlayListの内容をュ一ザに説明するところのメニュー画面を作成するのに有用であるし、また、 AVストリームのデコードに先だって、再生装置の A Vデコーダ及びデマルチプレクサの初期状態をセヅトするために役立つ。

この理由のために、 Clip Information fileは、プログラムの内容を説明するための Programlnfoを持つ。

MPEG 2 トランスポートストリ一ムをストアしている AVストリームフアイルは、ファイルの中でプログラム内容が変化するかもしれない。例えば、ビデオエレメン夕リーストリームを伝送するところのトランスポートパケットの P I D が変化したり、ビデオストリームのコンポ一ネント種類が S D T Vから HD T V に変化する等である。 Programlnfoは、 A Vストリームファイルの中でのプログラム内容の変化点の情報をストアする。 A Vストリームファイルの中で、このフォ —マヅトで定めるところのプログラム内容が一定である区間を Program-sequence と呼ぶ。

Program-sequenceは、 £?_1^ を持っストリームファイルで使用するものであり、 TUjnapを持つ AVストリームファイルではオプションである。

本例では、セルフエンコードのストリームフォーマヅト（SE SF) を定義する。 SE S Fは、アナログ入力信号を符号化する目的、及びディジタル入力信号 (例えば DV) をデコードしてから MP E G 2 トランスポートストリームに符号化する場合に用いられる。

SE SFは、 MPEG— 2トランスポートストリーム及ぴ A Vストリームについてのエレメンタリーストリームの符号化制限を定義する。記録再生装置 1が、 S E S Fストリームをエンコードし、記録する場合、 EP_inapが作成され、デイスクに記録される。ディジ夕ル放送のストリームは、次に示す方式の内のいずれかが用いられて記録媒体 100に記録される。先ず、ディジタル放送のストリームを S E S Fストリームにトランスコーディングする。この場合、記録されたストリームは、 SE S Fに準拠しなければならない。この場合、 EPjnapが作成されて、ディスクに記録されなければならない。

或いは、ディジタル放送ストリームを構成するエレメン夕リーストリームを新しいエレメン夕リストリームにトランスコ一ディングし、そのディジタル放送ストリームの規格化組織が定めるストリ一ムフォーマヅトに準拠した新しい卜ランスボートストリームに再多重化する。この場合、 EP_mapが作成されて、ディスクに記録されなければならない。

例えば、入カストリ一ムが I S DB (日本のディジタル B S放送の規格名称）準拠の MP EG— 2トランスポートストリームであり、それが HDTVビデオストリームと MPEG AACオーディオストリームを含むとする。 HDTVビデオストリームを SD TVビデオストリームにトランスコーディングし、その SDT Vビデオストリームとオリジナルの A ACオーディオストリームを T Sに再多重化する。 S D T Vストリームと記録されるトランスポートストリームは、共に I SDBフォーマツ卜に準拠しなければならない。

ディジタル放送のストリームが、記録媒体 100に記録される際の他の方式として、入力トランスポートストリームをトランスペアレントに記録する（入力トランスポートストリームを何も変更しないで記録する）場合であり、そのときに EP_mapが作成されてディスクに記録される。

又は、入力トランスポートストリームをトランスペアレントに記録する（入力トランスポートストリームを何も変更しないで記録する）場合であり、そのときに TU_mapが作成されてディスクに記録される。

次にディレクトリとファイルについて説明する。以下、記録再生装置 1を DV R (Digital Video Recording) と適宜記述する。図 14はディスク上のディレクトリ構造の一例を示す図である。 DVRのディスク上に必要なディレクトリは、図 14に示したように、 "DVR"ディレクトリを含む rootディレクトリ、 "PLAYLIST "ディレクトリ、 "CLIPINF"ディレクトリ、 "M2TS"ディレクトリ、及び" DATA"ディレクトリを含む" DVE"ディレクトリである。 rootディレクトリの下に、これら以外のディレクトリを作成されるようにしてもよいが、それらは、本例のアプリケ一シヨンフォーマットでは、無視されるとする。

"DVR"ディレクトリの下には、 D V Rアプリケーションフォーマットによって規定される全てのファイルとディレクトリがストアされる。 "DVR"ディレクトリは、 4個のディレクトリを含む。 "PLAYLIST"ディレクトリの下には、 Real PlayListと Virtual PlayListのデ一夕ベースファイルが置かれる。このディレクトリは、 P1 ayListが 1つもなくても存在する。

"CLIPINF"ディレクトリの下には、 Cl ipのデ一夕ペースが置かれる。このディレクトリも、 Cl ipが 1つもなくても存在する。 "M2TS"ディレクトリの下には、 A V ストリームファイルが置かれる。このディレクトリは、 A Vストリームファイルが 1つもなくても存在する。 "DATA"ディレクトリは、ディジタル TV放送等のデ一夕放送のファイルがストァされる。

"DVR"ディレクトリは、次に示すファイルをストアする。 "info. dvr"ファイルは、 D V Rディレクトリの下に作られ、アプリケーションレイヤの全体的な情報をストァする。 D V Rディレクトリの下には、ただ 1つの info . dvrがなければならない。ファイル名は、 info . dvrに固定されるとする。 "menu. thmb"ファイルは、メニュ一サムネイル画像に関連する情報をストァする。 D V Rディレクトリの下には、 ◦又は 1つのメニューサムネイルがなければならない。ファイル名は、 memu.thm bに固定されるとする。メニューサムネイル画像が 1つもない場合、このファイルは、存在しなくてもよい。

"mark.thmb"ファイルは、マークサムネイル画像に関連する情報をストァする。 D V Rディレクトリの下には、 0又は 1つのマークサムネイルがなければならない。ファイル名は、 mark.thmbに固定されるとする。メニューサムネイル画像が 1 つもない場合、このファイルは、存在しなくてもよい。

"PLAYLIST"ディレクトリは、 2種類の PlayListファイルをストァするものであり、それらは、 Real PlayListと Virtual PlayListである。 "xxxxx.rpls" フアイルは、 1つの Real PlayListに関連する情報をストアする。それぞれの Real Play List毎に、 1つのファイルが作られる。ファイル名は、 "xxxxx.rpls"である。ここで、 "xxxxx"は、 5個の 0乃至 9まで数字である。ファイル拡張子は、 "rpls"でなければならないとする。

"yjTJT. vpls"ファイルは、 1つの Virtual PiayListに閧連する情報をストアする。それぞれの Virtual PlayList毎に、 1つのファイルが作られる。ファイル名は、 "yyyyy.vpls"である。ここで、 "yyyyy"は、 5個の 0乃至 9まで数字である。ファイル拡張子は、 "vpls"でなければならないとする。

"CLIPINF"ディレクトリは、それそれの A Vストリームファイルに対応して、 1 つのファイルをストァする。 "zzzzz.clpi" フアイルは、 1つの A Vストリームフアイル（Cl ip AV stream file 又は Bridge-Cl ip AV stream fi le) に対応する C l ip Information ： f i leである。ファイル名は、 "zzzzz . clpi"であり、 "zzzzz"は、 5個の 0乃至 9までの数字である。ファイル拡張子は、 "clpi "でなければならないとする。

"M2TS"ディレクトリは、 A Vストリームのファイルをストァする。 "zzzzz. Di2t s"ファイルは、 D V Rシステムにより扱われる A Vストリームファイルである。これは、 Cl ip AV stream fi le又は Bridge-Cl ip AV streamである。ファイル名は、 "zzzzz . m2ts"であり、 "zzzzz"は、 5個の 0乃至 9までの数字である。ファイル拡張子は、 "m2ts"でなければならないとする。

"DATA"ディレクトリは、デ一夕放送から伝送されるデータをストァするものであり、データとは、例えば、 XML f ileや MHEGファイル等である。

次に、各ディレクトリ（ファイル）のシンタクスとセマンティクスを説明する。先ず、 "info. dvr"ファイルについて説明する。図 1 5は、 " info. dvr"ファイルのシンタクスを示す図である。 " info.dvr"ファイルは、 3個のオブジェクトから構成され、それらは、 DVHVoluiDe () 、 TableOfPlayLists () 、及び MakerPrivateD ata () である。

図 1 5に示した info.dvrのシンタクスについて説明すると、 TableOfPlayLists _Start— addressは、 info.dvrファイルの先頭のバイ卜からの相対バイト数を単位として、 TableOfPlayList () の先頭アドレスを示す。相対バイト数は 0からカウントされる。

MakerPrivateData Start addressは、 info.dvrファイルの先頭のバイトからの相対バイト数を単位として、 MakerPrivateData ( ) の先頭アドレスを示す。相対バイト数は 0からカウントされる。 padding— word (パディングワード）は、 info, dvrのシンタクスに従って揷入される。 N 1とN 2は、 0又は任意の正の整数である。それそれのパディングワードは、任意の値を取るようにしてもよい。

DVRVolume ( ) は、ボリューム（ディスク）の内容を記述する情報をストアする ₍ 図 1 6は、 DVRVolume () のシンタクスを示す図である。図 1 6に示した DVR Vol ume () のシンタクスを説明すると、 version_numbe ま、この DVRVolume () のノ一ジョンナンバを示す 4個のキャラク夕一文字を示す。 version_numberは、 I S 0 6 4 6に従って、 " 0045"と符号化される。

lengthは、この lengthフィールドの直後から DVH Volume () の最後までの DVEVo lume () のバイト数を示す 32ビッ卜の符号なし整数で表される。

ResumeVolume ( ) は、ボリュームの中で最後に再生した Real PlayList又は Vir tual PlayListのファイル名を記憶している。但し、 Real PlayList又は Virtual PlayListの再生をユーザが中断したときの再生位置は、 PlayListMark () において定義される resume- markにストァされる。

図 1 7は、 ResumeVolume () のシンタクスを示す図である。図 1 7に示した Re sumeVolume () のシンタクスを説明すると、 val id_flagは、この 1ビットのフラグが 1にセヅトされている場合、 resume_PlayList_nameフィールドが有効であることを示し、このフラグが 0にセットされている場合、 resume_PlayUst一 nameフィールドが無効であることを示す。

resume— PlayList_naneの 1 0バイトのフィールドは、リジュームされるべき Re al PlayList又は Virtual PlayListのファイル名を示す。

図 1 6に示した DVRVolume () のシンタクスのなかの、 UIAppInf oVolume は、ボリユームについてのユーザィン夕フェースアプリケーションのパラメ一夕をストァする。図 1 8は、 UIAppInfoVol.umeのシンタクスを示す図であり、そのセマンテイクスを説明すると、 character_setの 8ビットのフィールドは、 Volume_nanieフィールドに符号化されているキャラクタ一文字の符号化方法を示す。その符号化方法は、図 1 9に示される値に対応する。

name lengthの 8ビヅトフィールドは、 Volume_nameフィールドの中に示されるボリューム名のバイト長を示す。 Volume_nameのフィールドは、ボリュームの名称を示す。このフィールドの中の左から name_length数のバイト数が、有効なキャラクタ一文字であり、それはボリュームの名称を示す。 Vol ume_naiieフィールドの中で、それら有効なキャラク夕一文字の後の値は、どんな値が入っていてもよい。

Volume_protect_: lagは、ボリュームの中のコンテンヅを、ユーザに制限することなしに見せてよいかどうかを示すフラグである。このフラグが 1にセットされている場合、ユーザが正しく P I N番号（パスワード）を入力できたときだけ、そのボリュームのコンテンツを、ユーザに見せること（再生されること）が許可される。このフラグが 0にセヅトされている場合、ユーザが P I N番号を入力しなくても、そのボリュ一厶のコンテンヅを、ユーザに見せることが許可される。最初に、ユーザが、ディスクをプレーヤへ挿入した時点において、もしこのフラグが 0にセットされているか、又は、このフラグが 1にセットされていてもュ —ザが P I N番号を正しく入力できたならば、記録再生装置 1は、そのディスクの中の PlayListの一覧を表示させる。それそれの PlayListの再生制限は、 volume _protect_flagとは無関係であり、それは UIAppInfoPlayList () の中に定義される playback— control_f lagによつて示される。

P I Nは、 4個の 0乃至 9までの数字で構成され、それそれの数字は、 I S O / I E C 6 4 6に従って符号化される。 ref_thumbnai l_indexのフィールドは、ボリュ一ムに付加されるサムネイル画像の情報を示す。 ref_thMbnaiし indexフィ一ルドが、 OxFP Fでない値の場合、そのボリュームにはサムネイル画像が付加されており、そのサムネイル画像は、 menu. thumファイルの中にストアされている。その画像は、 menu. thumフアイルの中で ref— thumbnai Lindexの値を用いて参照される。 ref_thumbnaiし indexフィールドが、 OxFFFF である場合、そのボリュームにはサムネイル画像が付加されていないことを示す。

rp_info_val id_flagは、これが 1である場合に次に続く rp efjo—PlayUstf i le_name, rp— ref— to_PlayItem_id及び rp— time— stampが有効な値を持つこと示す。 rp_ref_to_PlayList_file_nameは、上記のボリユームを代表するメニューサムネイルが、ある PlayList中の画像から抜き出した画像から作られていることを示し、その PlayListファイルの名前を示す。 rp_ref_to_P 1 a ltem_i dはヽ rp—ref _to一 Pi ayL i st— f i 1 e_naieで示される P 1 ayL i s tの中の 1つの Playltemを指す Playltem_idを示し、且つ、上記のボリュームを代表するメニューサムネイルが、その Playltem中の画像から抜き出した画像から作られていることを示す。

rp— time— stampは、 rp_ref_to_PlayItein— idが指す Playltem中の 1つの画像のブレゼンテーシヨンタイムスタンプを示し、且つ、その画像から上記のボリュームを代表するメニュ一サムネィルが作られていることを示す。

次に図 1 5に示した info. dvrのシンタクス内の TableOfPlayLists () について説明する。 TableOfPlayLists () は、 PlayList (Real PlayListと Virtual PlayL ist) のファイル名をストアする。ボリュームに記録されている全ての PlayListフアイルは、 TaMeOfPlayList () の中に含まれる。 TableOfPlayLists () は、ポリユームの中の PlayListのデフオルトの再生順序を示す。

図 2 0は、 TableOfPlayLists () のシンタクスを示す図であり、そのシンタクスについて説明すると、 1"&1)160^13^1^8セ8の^ 1011_11 11361¹は、この TableOfPla yListsのバージョンナンバを示す 4個のキャラクタ一文字を示す。 version_nuinb erは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。

lengthは、この lengthフィールドの直後から TableOfPlayLists () の最後までの TableOfPlayLists () のバイト数を示す 3 2ビットの符号なしの整数である。 number_of— PlayListsの 1 6ビットのフィールドは、 PlayList_f i le— nameを含む f or - loopのループ回数を示す。この数字は、ボリュームに記録されている PlayLis tの数に等しくなければならない。？1& 1^81;_ 16ー11&]116の 1 0バイトの数字は、 P layListのファイル名を示す。

図 2 1は、 TableOfPlayLists ( ) のシンタクスを別実施の構成を示す図である。図 2 1に示したシンタクスは、図 2 0に示したシンタクスに、 UIAppinfoPlayLis t (後述）を含ませた構成とされている。このように、 UIAppinfoPlayListを含ませた構成とすることで、 TableOfPlayListsを読み出すだけで、メニュー画面を作成することが可能となる。ここでは、図 2 0に示したシンタクスを用いるとして以下の説明をする。

図 1 5に示した info.dvrのシンタクス内の MakersPrivateDataについて説明する, MakersPrivateDataは、記録再生装置 1のメ一力が、各社の特別なアプリケ一ションのために、 MakersPrivateData () の中にメーカのプライベートデ一夕を挿入できるように設けられている。各メーカのプライペートデ一夕は、それを定義したメーカを識別するために標準化された] naker_IDを持つ。 MakersPrivateData () は、 1つ以上の nakerJDを含んでもよい。

所定のメーカが、プライペートデータを挿入したいときに、既に他のメーカのプライベートデ一夕が MakersPrivateData ( ) に含まれていた場合、他のメーカは、既にある古いプライべ一トデ一夕を消去するのではなく、新しいプライべ一トデ一夕を MakersPrivateData () の中に追加するようにする。このように、本例においては、複数のメーカのプライべ一トデ一夕が、 1っの^18_1½1^>3?1>^&160^& () に含まれることが可能であるようにする。

図 2 2は、 MakersPrivateDataのシンタクスを示す図である。図 2 2に示した M akersPrivateDataのシンタクスについて説明すると、 version_numberは、この Ma kersPrivateData () のバージョンナンバを示す 4個のキャラクタ一文字を示す。 version_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。 lengthは、この lengthフィールドの直後から MakersPrivateData ( ) の最後までの MakersPrivateData () のバイト数を示す 3 2ビヅトの符号なし整数を示す。 mpd— blocks— start一 addressiま、 MakersPrivateData () の先頭のノィトカらの相対バイト数を単位として、最初の mpd_block () の先頭バイトアドレスを示す。相対バイト数は 0からカウントされる。 number— of jaaker— entriesは、 MakersPriva teData () の中に含まれているメーカプライべ一トデ一夕のェントリ数を与える 1 6ビットの符号なし整数である。 MakersPrivateData () の中に、同じ maker一 I Dの値を持つメーカプライベートデータが 2個以上存在してはならない。

mpd— block_sizeは、 1 0 2 4バイトを単位として、 1つの]] ipd_blockの大きさを与える 1 6ビヅトの符号なし整数である。例えば、 mpd_block_size= lならば、それは 1つの mpd_blockの大きさが 1 0 2 4パイトであることを示す。 number一 of_m pd_blocksは、 MakersPrivateData () の中に含まれる mpd_blockの数を与える 1 6 ビヅトの符号なし整数である。 maker_IDは、そのメーカプライベートデータを作成した D V Rシステムの製造メーカを示す 1 6 ビヅトの符号なし整数である。 ma ke IDに符号化される値は、この D V Rフォ一マヅトのライセンサによって指定される。

maker_modeし codeは、そのメーカプライベートデ一夕を作成した D V Rシステムのモデルナンパコードを示す 1 6 ビヅ卜の符号なし整数である。 maker_model_ codeに符号化される値は、このフォーマヅ卜のライセンスを受けた製造メーカによって設定される。 start_mpd_block_numberは、そのメーカプライベートデ一夕が開始される mpd_blockの番号を示す 1 6 ビットの符号なし整数である。メーカプライべ—トデ一夕の先頭デ一夕は、 _mpd_blockの先頭にァラインされなければならなレヽ。 startjnpd一 block—画 berは、 mpd— blockの for - loopの中の変数 jに対応する。 mpd_lengthは、バイト単位でメーカプライベートデ一夕の大きさを示す 3 2ビヅトの符号なし整数である。 mpdjD l ockは、メーカプライペートデ一夕がストアされる領域である。 MakersPrivateData () の中の全ての mpd_blockは、同じサイズでなければならない。

次に、 Real PlayList ： i leと Virtual PlayList fi leについて、換言すれば、 x xxxx. rplsと yyyyy.vplsについて説明する。図 2 3は、 xxxxx. rpls (Real PlayLi st) 、又は、 yyyyy.vpls (Virtual PlayList) のシンタクスを示す図である。 xx xxx-rplsと yyyyy-vplsはヽ同一のシン夕クス構成を持つ ₀ xxxx . r 1 s yyyy . vp Isは、それそれ、 3個のオブジェクトから構成され、それらは、 PlayList () 、 PlayListMark () 、及ぴ MakerPrivateData () である。

PlayListMark_Start— addressは、 PlayListファイルの先頭のバイトからの相対バイト数を単位として、 PlayListMark () の先頭アドレスを示す。相対バイト数は 0からカウントされる。

MakerPrivateData— Start— addressiま、 PlayListファイスレの先頭のノ¹^？ィ卜：^らの相対バイト数を単位として、 MakerPrivateData ( ) の先頭アドレスを示す。相対バイト数は 0からカウントされる。

padding_word (パディングワード）は、 PlayListファイルのシンタクスに従つて揷入され、 N 1と N 2は、 0又は任意の正の整数である。それそれのパディングヮ一ドは、任意の値を取るようにしてもよい。

ここで、既に、簡便に説明したが、 PlayListについて更に説明する。ディスク内にある全ての Real PlayListによって、 Bridge-Clip (後述）を除く全ての Cl ip の中の再生区間が参照されていなければならない。且つ、 2つ以上の Real Play Listが、それらの Playltemで示される再生区間を同一の Cl ipの中でォ一バーラヅプさせてはならない。

図 2 4 A〜図 2 4 Cを参照して更に説明すると、図 2 4 Aに示したように、全ての Cl ipは、対応する Real PlayListが存在する。この規則は、図 2 4 Bに示したように、編集作業が行われた後においても守られる。したがって、全ての Cl ipは、どれかしらの Real PlayListを参照することにより、必ず視聴することが可能である。

図 2 4 Cに示したように、 Virtual PlayListの再生区間は、 Real PlayListの再生区間又は Bridge- Cl ipの再生区間の中に含まれていなければならない。どの Vir tual PlayListにも参照されない Bridge-Cl ipがディスクの中に存在してはならない。

Real PlayListは、 Playltemのリストを含むが、 SubPlayltemを含んではならない。 Virtual PlayListは、 Playltemのリストを含み、 PlayList ( ) の中に示される CPI— typeが EP—map typeであり、且つ PlayList_typeが 0 (ビデオとオーディオを含む PlayList) である場合、 Virtual PlayListは、 1つの SubPlayltemを含むことができる。本例における PlayList () では、 SubPlaylteはオーディオのアフレコの目的にだけに使用される、そして、 1つの Virtual PlayListが持つ SubPlaylte mの数は、 0又は 1でなければならない。

次に、 PlayListについて説明する。図 2 5は、 PlayListのシンタクスを示す図である。図 2 5に示した PlayListのシンタクスを説明すると、 version_numberは、この PlayList () のバージョンナンバを示す 4個のキャラク夕一文字である。 ve rsion_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない _c lengthは、この lengthフィールドの直後から PlayList () の最後までの PlayList ( ) のバイト数を示す 3 2 ビヅトの符号なし整数である。 PIayList_typeは、この PlayListのタイプを示す 8ビヅトのフィールドであり、その一例を図 2 6に示す。

CPI_typeは、 1 ビヅトのフラグであり、 Playltem () 及び SubPlayltem () によつて参照される Cl ipの CPI typeの値を示す。 1つの PlayListによって参照される全ての Cl ipは、それらの CPI () の中に定義される CPI_typeの値が同じでなければならない。醒 be r_of一 Play Itemsは、 PlayListの中にある Playltemの数を示す 1 6 ビヅトのフィールドである。

所定の Playltem () に対応する Playltem_idは、 Playltem ( ) を含む for-loopの中で、その Playltem () の現れる順番により定義される。 Playlteia_idは、 0から鬨始される。 number_of一 SubPlayltemsは、 PlayListの中にある SubPlayltemの数を示す 1 6ビットのフィールドである。この値は、 0又は 1である。付加的なォーディォストリームのパス（オーディオストリームパス）は、サブパスの一種である。

次に、図 2 5に示した PlayListのシンタクスの UIAppInfoPlayListについて説明. する。 UIAppInfoPlayListは、 PlayListについてのユーザインタフェースアプリケ —シヨンのパラメータをストアする。図 2 7は、 UIAppInfoPlayListのシンタクスを示す図である。図 2 7に示した UIAppInfoPlayListのシンタクスを説明すると、 character_setは、 8ビットのフィールドであり、 PlayList_immeフィールドに符号化されているキャラクタ一文字の符号化方法を示す。その符号化方法は、図 1 9に示したテーブルに準拠する値に対応する。

name— lengthは、 8ビットフィールドであり、 PlayList— nameフィールドの中に示される PlayList名のバイト長を示す。 PlayList_nameのフィ一ルドは、 PlayLis tの名称を示す。このフィールドの中の左から name一 length数のバイト数が、有効なキャラクタ一文字であり、それは PlayListの名称を示す。 PlayList_nameフィールドの中で、それら有効なキャラク夕一文字の後の値は、どんな値が入っていてもよい。

record_time_and_dateは、 PlayListが記録されたときの日時をストァする 5 6 ビットのフィールドである。このフィールドは、年 /月/日/時/分ノ秒について、 1 4個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。例えば、 2001/12/23: 01 :02 : 03 は、 "0x20011223010203"と符号化される。

durationは、 PlayListの総再生時間を時間/分/秒の単位で示した 2 4ビヅトのフィールドである。このフィールドは、 6個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。例えば、 01 :45 : 30は、 "0x014530 "と符号化される。

val id一 periodは、 PlayListが有効である期間を示す 3 2ビヅトのフィールドである。このフィールドは、 8個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。例えば、記録再生装置 1は、この有効期間の過ぎた P layListを自動消去する、といったように用いられる。例えば、 2001/05/07 は、 "0x20010507"と符号化される。

maker_idは、その PlayListを最後に更新した D V Rプレーヤ（記録再生装置 1 ) の製造者を示す 1 6ビヅトの符号なし整数である。 makerjdに符号化される値は、 D V Rフォーマヅトのライセンサによって割り当てられる。 maker«_codeは、その PlayListを最後に更新した D V Rプレーヤのモデル番号を示す 1 6ビットの符号なし整数である。 maker— codeに符号化される値は、 D V Rフォーマットのラィセンスを受けた製造者によって決められる。

playback一 controし: Hagのフラグが 1にセヅトされている場合、ユーザが正しく P I N番号を入力できた場合にだけ、その PlayListは再生される。このフラグが 0にセヅトされている場合、ュ一ザが P I N番号を入力しなくても、ユーザは、その PlayListを視聴することができる。

write_protect_flagは、図 2 8 Aにテーブルを示すように、 1にセットされている場合、 write_protect_flagを除いて、その PlayListの内容は、消去及び変更されない。このフラグが 0にセットされている場合、ユーザは、その PlayListを自由に消去及び変更できる。このフラグが 1にセヅトされている場合、ュ一ザが、その PlayListを消去、編集、又は上書きする前に、記録再生装置 1はユーザに再確認するようなメッセージを表示させる。 · write_protect_flagが 0にセヅトされている Real PlayListが存在し、且つ、その Real PlayListの Cl ipを参照する Virtual PlayListが存在し、その Virtual Pla yListの write_protect_:Hagが 1にセヅ卜されていてもよい。ュ一ザが、 Real PI ayListを消去しょうとする場合、記録再生装置 1は、その Real PlayListを消去する前に、上記 Virtual PlayListの存在をユーザに警告するか、又は、その Real P 1 ayListを" Minimize"する。 is_played_flagは、図 2 8 Bに示すように、フラグが 1にセヅトされている場合、その PlayListは、記録されてから 1度は再生されたことを示し、 0にセットされている場合、その ayListは、記録されてから 1度も再生されたことがないことを示す。

archiveは、図 2 8 Cに示すように、その PlayListがオリジナルであるか、コピ —されたものであるかを示す 2ビヅトのフィールドである。 ref_tlmmbnai l一 inde のフィールドは、 PlayListを代表するサムネイル画像の情報を示す。 ref_thum bnaiし indexフィールドが、 OxFFFFでない値の場合、その PlayListには、 PlayLis tを代表するサムネイル画像が付加されており、そのサムネイル画像は、 menu. th um ファイルの中にストアされている。その画像は、 menu. thumファイルの中で re f— thumbnaiし: indexの値を用いて参照される。 ref一 thumbnaiし indexフィ一ルドが、 OxFFFF である場合、その ayListには、 PlayListを代表するサムネイル画像が付加されていない。

次に Playltemについて説明する。 1つの Playltem () は、基本的に次のデータを含む。 Cl ipのファイル名を指定するための Cl ip— information_fi le— name、 Cl ip の再生区間を特定するための IN_timeと 0UT_timeのペア、 PlayList () において定義される CPし typeが EP_map typeである場合、 Iii—timeと 0UT_tinieが参照するところの STC_sequence_id、及び、先行する Playltemと現在の Playltemとの接続の状態 ¾示すところの connection一 conditionである。

PlayListが 2つ以上の Playltemから構成されるとき、それらの Playltemは Play Listのグローバル時間軸上に、時間のギヤヅプ又はオーバ一ラップなしに 1列に並べられる。 PlayList () において定義される CPし typeが EPjaap typeであり、且つ現在の Playltemが BridgeSequence () を持たないとき、その Playltemにおいて定義される IN_t imeと 0UT_t imeのペアは、 STC_sequence一 i dによって指定される同じ S T C連続区間上の時間を指していなければならない。そのような例を図 2 9 に示す。

図 3 0は、 PlayList () において定義される CPI_typeが EPjuap typeであり、且つ現在の Playltemが BridgeSequence () を持つとき、次に説明する規則が適用される場合を示している。現在の Playltemに先行する Playltemの IN time (図の中で IN_timelと示されているもの）は、先行する Playltemの STC_sequence_idによつて指定される S T C連続区間上の時間を指している。先行する Playltemの OUT— ti me (図の中で 0UT_timelと示されているもの）は、現在の Playltemの BridgeSeque ncelnfo ( ) の中で指定される Bridge-Cl ipの中の時間を指している。この 0UT_ti meは、後述する符号化制限に従っていなければならない。

現在の Playltemの IN_time (図の中で IN_time2と示されているもの）は、現在の Playltemの BridgeSequencelnfo ( ) の中で指定される Bridge- Cl ipの中の時間を指している。この IN_timeも、後述する符号化制限に従っていなければならない。現在の Playltemの Playltemの 0UT_time (図の中で 0UT_time2と示されているもの）は、現在の Playltemの STC_sequence一 idによって指定される S T C連続区間上の時間を指している。

図 3 1に示すように、 PlayList ( ) の CPI_typeが TU_map typeである場合、 Pla yltemの IILtimeと 0UT_timeのペアは、同じ Cl ip A Vストリーム上の時間を指している。

Playltemのシンタクスは、図 3 2に示すようになる。図 3 2に示した Playltem のシンタクスを説明すると、 Cl ip_Iiiformatioii_fi le_nameのフィールドは、 Cl ip

Information fi leのファイル名を示す。この Cl ip Information fi leの Cl iplnf o ( ) において定義される Cnp_stream_typeは、 Cl ip AV streamを示していなければならない。

STC_sequence_idは、 8ビヅトのフィールドであり、 Playltemが参照する S T C 連続区間の STC_sequence_idを示す。 PlayList ( ) の中で指定される CPI— typeが T ILmap typeである場合、この 8ビヅトフィールドは何も意味を持たず、 0にセットされる。 IN— timeは、 3 2ビットフィールドであり、 Playltemの再生開始時刻をストアする。 IN_timeのセマンティクスは、図 3 3に示すように、 PlayList () において定義される CH_typeによって異なる。

0UT_timeは、 3 2ビヅトフィールドであり、 Playltemの再生終了時刻をストアする。 0UT_timeのセマンティクスは、図 3 4に示すように、 PlayList ( ) において定義される CPし typeによって異なる。

Connection Conditionは、図 3 5に示したような先行する Playltemと、現在の Playltemとの間の接続状態を示す 2ビヅトのフィールドである。図 3 6 A〜図 3 6 Dは、図 3 5に示した Connection_Conditionの各状態について説明する図である。

次に、 BridgeSequencelnfoについて、図 3 7を参照して説明する。 BridgeSequ encelnfo () は、現在の Playltemの付属情報であり、次に示す情報を持つ。 Brid ge-Cl ip AV streamファイルとそれに対応する Cl ip Information fi leを指定する Bri dge_C 1 ip_I nf ormat i on_f i 1 e_name ¾含む。

また、先行する Playltemが参照する Cl ip AV stream上のソ一スパケヅトのアドレスであり、このソースパケヅトに続いて Bridge-Cl ip AV streamファイルの最初のソースパケヅ卜が接続される。このアドレスは、 RSPN_exit_from_preWous_Cl ipと称される。更に現在の Playltemが参照する Clip AV stream上のソースパケットのァドレスであり、このソースパケヅトの前に Bridge-Cl ip AV streamファイルの最後のソースパケットが接続される。このアドレスは、 RSPN_enter_to_curren t_Cl ipと称される。

図 3 7において、 RSPN_arrivaし time— discontinuityは、 the Bridge-Cl ip AV streamフアイルの中でァライバルタイムペースの不連続点があるところのソースパケットのアドレスを示す。このアドレスは、 Cl iplnfo ( ) の中において定義される。

図 3 8は、 BridgeSequenceinfoのシンタクスを示す図である。図 3 8に示した BridgeSequenceinfoのシンタクスを説明すると、 Bridge_Cl ip— Information_fi le _naiieのフィールドは、 Bridge-Cl ip AV streamファイルに対応する Cl ip Informa tion f i leのファイル名を示す。この Cl ip Information fi leの Cl iplnfo () において定義される Cl ip_stream_typeは、 ' Bridge-Cl ip AV stream'を示していなければならない。

RSPN_exit_fr>om_previous_Cl ipの 3 2ビヅトフィールドは、先行する Playltem が参照する Cl ip AV stream上のソースパケヅトの相対ァドレスであり、このソースパケヅトに続いて Bridge-Cl ip AV streamファイルの最初のソースパケヅトが接続される。 RSPN_exit_from_previous_Cl ipは、ソースパケット番号を単位とする大きさであり、先行する Playltemが参照する Cl ip AV streamファイルの最初のソースパケットから Cliplnfo () において定義される offset_SPNの値を初期値としてカウントされる。

RSPN—enter— to_current一 Cl ipの 3 2ビヅトフィールドは、現在の Hayltemが参照する Cl ip AV stream上のソースパケヅトの相対ァドレスであり、このソ一スパケヅトの前に Bridge- Cl ip AV streamファイルの最後のソースパケヅトが接続される。 RSPN_exit_from_previous_Cl ipは、ソースパケヅト番号を単位とする大きさであり、現在の Playltemが参照する Cl ip AV streamファイルの最初のゾ一スパケヅトから Cl iplnfo ( ) において定義される offset_SPNの値を初期値としてカウントされる。

次に、 SubPlayltemについて、図 3 9を参照して説明する。 SubPlayltem ( ) の使用は、 PlayList ( ) の CPし typeが EPjnap typeである場合だけに許される。本例においては、 SubPlayltemはオーディオのアフレコの目的のためだけに使用されるとする。 SubPlayltem ( ) は、次に示すデータを含む。先ず、 PlayListの中の sub pathが参照する Cl ipを指定するための Cl ip_information_fi le_ nameを含む。また、 Cl ipの中の sub pathの再生区間を指定するための SubPath_IN— time と S ubPath_OUT_timeを含む。更に、 main pathの時間軸上で sub pathが再生開始する時刻を指定するための sync— Playltem_id と sync_start_PTS_of_PlayItemを含む。 sub pathに参照されるオーディオの Cl ip AV streamは、 S T C不連続点（システムタイムベースの不連続点）を含んではならない。 sub pathに使われる Cl ipのォ —ディオサンプルのクロヅクは、 main pathのオーディオサンプルのクロヅクに口ヅクされている。

図 4 0は、 SubPlayltemのシンタクスを示す図である。図 4 0に示した SubPlay Itemのシンタクスを説明すると、 Cl ip_Information_:fi le_nameのフィールドは、 Cl ip Information fi leのファイル名を示し、それは PlayListの中で sub pathによつて使用される。この Cl ip Information f i leの Cl iplnfo ( ) において定義される Cl ip— stream— typeは、 Cl ip AV streamを示していなければならない。

SubPath_typeの 8ビットのフィールドは、 sub pathのタイプを示す。ここでは、図 4 1に示すように、 ⁵ 0x00'しか設定されておらず、他の値は、将来のために確保されている。 sync_PlayItem_idの 8ビヅトのフィールドは、 main pathの時間軸上で sub pat hが再生開始する時刻が含まれる Hayltemの Playltemjdを示す。所定の Playltem に対応する Playlteia_idの値は、 PlayList () において定義される（図 2 5参照）， sync_start_PTS_of_PlayItemの 3 2ビットのフィールドは、 main pathの時間軸上で sub pathが再生開始する時刻を示し、 sync_PlayItem_idで参照される Playlt eni上の P T S (Presentaiotn Time Stamp) の上位 3 2ビットを示す。 SubPath_I N_timeの 3 2 ビヅトフィ一ルドは、 Sub pathの再生閧始時刻をストァする。 SubP ath一 IN— timeは、 Sub Pathの中で最初のプレゼンテーションュニヅトに対応する 3 3ビヅト長の P T Sの上位 3 2 ビヅトを示す。

SubPath_OUT_timeの 3 2ビットフィ一ルドは、 Sub pathの再生終了時刻をストァする。 SubPath_OUTJ imeは、次式によって算出される Presenation一 end_TSの値の上位 3 2ビットを示す。

Presentation_end_TS = PTS一 out + AU_duration

ここで、 PTS— outは、 SubPathの最後のプレゼンテーションユニットに対応する 33 ビヅト長の P T Sである。 AU_durationは、 SubPathの最後のプレゼンテーションユニットの 9 0 k H z単位の表示期間である。

次に、図 2 3に示した xxxxx. rplsと yyyyy.vplsのシンタクス内の PlayListMark ( ) について説明する。 PlayListについてのマーク情報は、この PlayListMarkにストアされる。図 4 2は、 PlayListMarkのシンタクスを示す図である。図 4 2に示した PlayListMarkのシンタクスについて説明すると、 versioiuumberは、この PlayListMark ( ) のバージョンナンバを示す 4個のキャラクタ一文字である。 ve rsion_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない < lengthは、この lengthフィールドの直後から PlayListMark () の最後までの PI ayListMark () のバイト数を示す 3 2ビヅ卜の符号なし整数である。 number一 of_ PlayListjnarksは、 PI ayListMarkの中にストァされているマークの個数を示す 1 6ビットの符号なし整数である。 number_of_P 1 ayL ist_marks は、 0であってもよい。 mark_typeは、マークのタイプを示す 8ビットのフィ一ルドであり、図 4 3に示すテーブルに従って符号化される。

mark一 time stampの 32ビヅトフィールドは、マークが指定されたポイントを示すタイムスタンプをストァする。 mark__time_stafflpのセマンテイクスは、図 4 4に示すように、 PlayList () において定義される CPI一 typeによって異なる。 Playltem —idは、マークが置かれているところの Playltemを指定する 8ビットのフィールドである。所定の Playltemに対応する Playltemjdの値は、 PlayList () において定義される（図 2 5参照）。

character_set© 8ビヅトのフィ一ルドは、 mark— nameフィールドに符号化されているキャラクタ一文字の符号化方法を示す。その符号化方法は、図 1 9に示した値に対応する。 namejengthの 8ビヅトフィールドは、 Mark—nameフィールドの中に示されるマーク名のバイト長を示す。 markjiameのフィールドは、マークの名称を示す。このフィールドの中の左から name_length数のバイト数が、有効なキヤラク夕一文字であり、それはマークの名称を示す。 Mark_nameフィールドの中で、それら有効なキャラクタ一文字の後の値は、どのような値が設定されてもよい。 ref— thumbnaiし indexのフィールドは、マークに付加されるサムネイル画像の情報を示す。 ref_thumbnaiし indexフィ一ルドが、 OxFfTFでない値の場合、そのマ一クにはサムネイル画像が付加されており、そのサムネイル画像は、 mark. thmbファィルの中にストアされている。その画像は、 mark. thmbファイルの中で ref_thumb nai l_indexの値を用いて参照される（後述）。 ref—thumbnaiし indexフィールドが、 OxFFFF である場合、そのマークにはサムネイル画像が付加されていないことを示す。

次に、 Cl ip information fi leについて説明する。 zzzzz . clpi (Cl ip informat ion fi leファイル）は、図 4 5に示すように 6個のオブジェクトから構成される。それらは、 Cl iplnfo () 、 STC_Info () 、 Programlnfo () 、 CPI () 、 Cl ipMark ( ) 、及び MakerPrivateData () である。 A Vストリーム（Clip A Vストリーム又は Bridge-Cl ip AV stream) とそれに対応する Cl ip Informationファイルは、同じ数字列の" zzzzz"が使用される。

図 4 5に示した zzzzz. clpi (Clip information fi leファイル）のシンタクスについて説明すると、 Cl ipInfo_Start_addressは、 zzzzz . clpiファイルの先頭のパィトからの相対バイト数を単位として、 Cl iplnfo ( ) の先頭アドレスを示す。相対バイト数は 0からカウントされる。 STC_Info_Start_addressは、 zzzzz. dpiファイルの先頭のバイトからの相対バイト数を単位として、 STC_Info () の先頭アドレスを示す。相対バイト数は 0からカウントされる。 Programlnfo— Start一 address ίま、 zzzzz. clpiファィノレの先頭のバイ卜からの相対バイト数を単位として、 Programlnfo () の先頭アドレスを示す _t 相対バイト数は 0からカウントされる。 CPI_Start__addi>essは、 zzzzz.clpiフアイルの先頭のバイ卜からの相対バイト数を単位として、 CPI () の先頭アドレスを示す。相対バイト数は 0からカウントされる。

ClipMark— Start_addressは、 zzzzz.clpiファイルの先頭のバイトからの相対パィト数を単位として、 ClipMark () の先頭アドレスを示す。相対バイト数は 0からカゥント..される。 MakerPrivateData_Start_addressfis zzzzz.clpiフアイレの先頭のバイトからの相対バイト数を単位として、 MakerPrivateData () の先頭ァドレスを示す。相対バイト数は 0からカウントされる。 padding_woni (パディングワード）は、 zzzzz.clpiファイルのシンタクスに従って挿入される。 N l , N 2 , N 3 , N4、及び N 5は、 0又は任意の正の整数でなければならない。それそれのパディングヮ一ドは、任意の値がとられるようにしてもよい。

次に、 Cliplnfoについて説明する。図 46は、 Cliplnfoのシンタクスを示す図である。 Cliplnfo () は、それに対応する AVストリームファイル（Clip AVストリ一ム又は Bridge- Clip AVストリームファイル）の属性情報をストアする。図 46に示した Cliplnfoのシンタクスについて説明すると、 version_numberは、この Cliplnfo () のバージョンナンパ'を示す 4個のキャラク夕一文字である。 ve rsion_numberは、 I SO 646に従って、 "0045"と符号化されなければならない _c lengthは、この lengthフィ一ルドの直後から Cliplnfo () の最後までの Cliplnfo () のバイト数を示す 32ビヅトの符号なし整数である。 Clip_stream_typeの 8 ビットのフィールドは、図 47に示すように、 Clip Informationファイルに対応する AVストリームのタイプを示す。それそれのタイプの A Vストリームのストリーム夕ィプについては後述する。

offset_SPNの 32ビヅトのフィールドは、 A Vストリーム（Clip A Vストリーム又は Bridge- Clip AVストリーム）ファイルの最初のソ一スパケヅトについてのソースパケヅト番号のオフセヅト値を与える。 AVストリームファイルが最初にディスクに記録されるとき、この offset_SPNは 0でなければならない。

図 4 8に示すように、 A Vストリームファイルのはじめの部分が編集によって消去されたとき、 offset_SPNは、 0以外の値をとつてもよい。本例では、 offset _SPNを参照する相対ソースパケット番号（相対アドレス）が、しばしば、 RSPN_x XX (XXXは変形する。例. RSPN_EP_start) の形式でシンタクスの中に記述されている。相対ソースパケット番号は、ソースパケット番号を単位とする大きさであり、 A Vストリームファイルの最初のソースパケヅトから off set一 SPNの値を初期値としてカウントされる。

A Vストリ一ムファイルの最初のソースパケヅトから相対ソースパケヅト番号で参照されるソースパケットまでのソースパケットの数（SPN_xxx) は、次式で算出される。

SPN_xxx = RSPN_xxx - offset_SPN

図 4 8に、 offset_SPNが 4である場合の例を示す。

TS_recording_rateは、 2 4ビットの符号なし整数であり、この値は、 D V Rドライブ（書込部 2 2 ) へ又は D V Rドライブ（読出部 2 8 ) からの A Vストリ一ムの必要な入出力のビヅトレートを与える。 record一 time一 and_dateは、 Cl ipに対応する A Vストリームが記録されたときの日時をストァする 5 6ビットのフィ一ルドであり、年/月/日 Z時/分/秒について、 1 4個の数字を 4ビットの Bina ry Coded Decimal ( B C D ) で符号化したものである。例えば、 2001/12/23: 01 : 02: 03 は、 "0x20011223010203"と符号化される。

durati onは、 Cl ipの総再生時間をァライバルタイムクロヅクに基づいた時間分/秒の単位で示した 2 4ビヅトのフィールドである。このフィールドは、 6個の数字を 4ビットの Binary Coded Decimal ( B C D ) で符号化したものである。例えば、 01 :45 :30は、 "0x014530"と符号化される。

time— controI IecUflag:のフラグは、 A Vストリ一ムファイルの記録モードを示す。この time一 control led_flagが 1である場合、記録モードは、記録してからの時間経過に対してファイルサイズが比例するようにして記録されるモードであることを示し、次式に示す条件を満たさなければならない。

TS_average_rate*192/188* (t - start一 time) - a <= size clip (t) <= TS一 average— rate* 192/188* (t - start— time) + a

ここで、 TS_average_rateは、 A Vストリームファイルのトランスポートストリームの平均ビットレ一トを bytes/second の単位で表したものである。

また、上式において、七は、秒単位で表される時間を示し、 start—tineは、 A Vストリームファイルの最初のソースパケヅトが記録されたときの時刻であり、秒単位で表される。 si ze_cl ip ( t) は、時刻 tにおける A Vストリームファイルのサイズをバイト単位で表したものであり、例えば、 start_timeから時刻 tまでに 1 0個のソースパケッ卜が記録された場合、 s i ze_cl ip (t) は 10*192バイトである。 aは、 TS_average_rateに依存する定数である。

time_control led_flagが 0にセットされている場合、記録モードは、記録の時間経過と A Vストリームのファイルサイズが比例するように制御していないことを示す。例えば、これは入力トランスポ一トストリームをトランスペアレント記録する場合である。

TS_average— rateま、 time— control led_flag力 s 1 ίこセットされて ¾ る場合、この 2 4ビヅトのフィールドは、上式で用いている TS_average— rateの値を示す。 tim e_control led_flagが 0にセヅトされている場合、このフィールドは、何も意味を持たず、 0にセットされなければならない。例えば、可変ビットレートのトランスポ一トストリームは、次に示す手順により符号化される。先ずトランスポートレートを TS一 recording_rateの値にセヅトする。次に、ビデオストリームを可変ビヅトレートで符号化する。そして、ヌルパケヅトを使用しないことによって、間欠的にトランスポートパケットを符号化する。

RSPN— arrivaし time_discontinuityの 3 2 ビヅトフィールドは、 Bridge - Cl ip A V streamファイル上でァライバル夕ィムペースの不連続が発生する場所の相対ァドレスである。 RSPN_airivaし time_di scontiimityは、ソースパケット番号を単位とする大きさであり、 Bridge- Cl ip AV streamファイルの最初のソースパケヅトから Cl iplnfo ( ) において定義される offset_SPNの値を初期値としてカウントされる。その Bridge- Cl ip AV streamファイルの中での絶対アドレスは、上述した

SPN_xxx = RSPN— XXX - offset_SPN

に基づいて算出される。 reserved一: or— system一 useの 144ビヅトのフィールドは、システム用にリザーブされている。 is— formatjdentifier^val idのフラグが 1であるとき、 formatjde ntifierのフィールドが有効であることを示す。 is_originaし network_ID_val idのフラグが 1である場合、 originaし network_IDのフィ一ルドが有効であることを示す。 is一 tr薦 port_stream_ID一 val idのフラグが 1である場合、 transport_stream —IDのフィールドが有効であることを示す。 is_servece_ID一 val idのフラグが 1である場合、 servece_IDのフィ一ルドが有効であることを示す。

is— country一 code—val idのフラグが 1であるとき、 country一 codeのフィ一ルドが有効であることを示す。 format一 identifierの 32ビヅトフィールドは、トランスポートストリームの中で registration deascriotor ( IS0/IEG13818- 1で定義されている）が持つ: ormat—identifierの値を示す。 originaし network_IDの 1 6ビヅトフィールドは、トランスポ一トストリームの中で定義されている originaし net work_IDの値を示す。 transport_stream_IDの 1 6ビットフィールドは、トランスポートストリームの中で定義されている transport_streain_IDの値を示す。

servece_IDの 1 6ビヅトフィ一ルドは、トランスポートストリームの中で定義されている senrece_IDの値を示す。 country_codeの 2 4ビヅトのフィールドは、 I S 0 3 1 6 6によって定義されるカントリーコードを示す。それそれのキャラクタ一文字は、 I S 0 8 8 5 9— 1で符号化される。例えば、日本は" JPN"と表され、 " 0x4A 0x50 0x4E"と符号化される。 streaia— forEat_nameは、トランスポ一トストリームのストリーム定義をしているフォーマヅト機関の名称を示す I S O— 6 4 6の 1 6個のキャラクターコードである。このフィ一ルドの中の無効なバイトは、値， OxFF，がセヅトされる。

f or at一 ldentif ier、 original_network_ID_s transport一 stream— ID、 servece— ID, country— code 、及び stream一 format一 nameは、卜ランスポー卜ス卜リームのサ —ビスプロバイダを示すものであり、これにより、オーディオやビデオストリームの符号化制限、 SI (サービスインフォメーション）の規格やオーディオビデオストリーム以外のプライペートデータストリームのストリーム定義を認識することができる。これらの情報は、デコーダが、そのストリームをデコードできるか否か、そしてデコードできる場合にデコ一ド開始前にデコ一ダシステムの初期設定を行うために用いることが可能である。

次に、 STC_Infoについて説明する。ここでは、 M P E G— 2 トランスポートストリームの中で S T Cの不連続点（システムタイムベースの不連続点）を含まない時間区間を STC_sequenceといい、 Cl ipの中で、 STC_sequenceは、 STC_sequence _idの値によって特定される。図 5 O A及び図 5 0 Bは、連続な S T C区間について説明する図である。同じ STC_sequenceの中で同じ S T Cの値は、決して現れない（但し、後述するように、 Cl ipの最大時間長は制限されている）。したがって、同じ STC_sequenceの中で同じ P T Sの値もまた、決して現れない。 A Vストリ一ムが、 N (N>0) 個の S T C不連続点を含む場合、 Cl ipのシステムタイムベースは、

(N+1) 個の STC_sequenceに分割される。

STC_Infoは、 S T Cの不連続（システムタイムベースの不連続）が発生する場所のアドレスをストアする。図 5 1を参照して説明するように、 RSPN一 STC_start が、そのアドレスを示し、最後の STC_sequenceを除く k番目（k>=0) の STC_sequ enceは、 k番目の RSPN_STC_startで参照されるソースパケットが到着した時刻から始まり、（k + 1 ) 番目の RSPN_STC_startで参照されるソースパケットが到着した時刻で終わる。最後の STC—sequenceは、最後の BSPN_STC_startで参照されるソースパケヅトが到着した時刻から始まり、最後のソースパケヅトが到着した時刻で終了する。

図 5 2は、 STC— Infoのシンタクスを示す図である。図 5 2に示した STC_Infoのシンタクスについて説明すると、 version_numberは、この STC_Info ( ) のパージヨンナンバを示す 4個のキャラク夕一文字である。 version_numberは、 I S O 6 4 6に従って、 "0045"と符号化されなければならない。

lengthは、この lengthフィールドの直後から STC_Info ( ) の最後までの STC_In fo ( ) のバイト数を示す 3 2ビヅ卜の符号なし整数である。 CPI ( ) の CPし typeが TUjnap typeを示す場合、この lengthフィールドは 0をセットしてもよい。 CPI ( ) の CPI_typeが EP_map typeを示す場合、 num_of_STC_sequencesは 1以上の値でなければならない。

num_of_STC_sequencesの 8ビヅトの符号なし整数は、 Cl ipの中での STC_sequen ceの数を示す。この値は、このフィールドに続く for-loopのループ回数を示す。所定の STC_sequenceに対応する STC_sequence_idは、 RSPN_STC_s tartを含む for- 1 oopの中で、その STC_sequenceに対応する RSPN_STC_startの現れる順番により定義されるものである。 STC一 sequence_idは、 0から開始.される。

RSPN— STC一 startの 3 2ビヅトフィールドは、 A Vストリ一ムファイル上で STC_ sequenceが開始するアドレスを示す。 RSPN_STC一 startは、 A Vストリームフアイルの中でシステムタイムベースの不連続点が発生するアドレスを示す。 RSPN_STC _startは、 A Vストリームの中で新しいシステムタイムベースの最初の P C Rを持つソースパケットの相対アドレスとしてもよい。 RSPN_STC_startは、ソースパケット番号を単位とする大きさであり、 A Vストリームファイルの最初のソースパケヅトから Cl iplnfo () において定義される offset_SPNの値を初期値として力ゥントされる。その AV streamファイルの中での絶対アドレスは、既に上述した

SPN_xxx = RSPN_xxx - off set一 SPN

により算出される。

次に、図 4 5に示した zzzzz . cl ipのシン夕クス内の Programlnfoについて説明する。図 5 3を参照しながら説明すると、ここでは、 Cl ipの中で次の特徴を持つ時間区間を program_sequenceと呼ぶ。先ず、 PCB_PIDの値が変わらない。次に、ビデォエレメンタリーストリームの数が変化しない。また、それそれのビデオストリームについての P I Dの値とその VideoCodinglnfoによって定義される符号化情報が変化しない。更に、オーディオエレメンタリーストリームの数が変化しない。また、それそれのオーディオストリームについての P I Dの値とその AudioCodin glnfoによって定義される符号化情報が変化しない。

prograai_sequenceは、同一の時刻において、ただ 1つのシステムタイムベースを持つ。 program_sequenceは、同一の時刻において、ただ 1つの P M Tを持つ。 Programlnfo () は、 program_sequenceが開始する場所のアドレスをストアする。 RSPN— program— sequence_startが、そのアドレスを示す。

図 5 4は、 Programlnfoのシンタクスを示す図である。図 5 4に示した Program Infoのシン夕クを説明すると、 version_numberは、この Programlnfo () のバ一ジヨンナンパを示す 4個のキャラクタ一文字である。 version_numbe ま、 I S O 6 4 6に従って、 "0045"と符号化されなければならない。 lengthは、この lengthフィールドの直後から Programlnfo ( ) の最後までの Pro gramlnfo ( ) のバイト数を示す 3 2 ビヅトの符号なし整数である。 CPI ( ) の CPI _typeが TU_map typeを示す場合、この lengthフィールドは 0にセットされてもよい。 CPI ( ) の CPI— typeが EPjaap typeを示す場合、 number\_o;f_prograiiisは 1以上の値でなければならない。

number一 of— program— sequencesの 8ビヅ卜の符号なし整数は、 Cl ipの中での pro gram_sequenceの数を示す。この値は、このフィールドに続く for- loopのループ回数示す。 Cl ipの中で program一 sequenceが変化しない場合、 number一 of一 program一 sequencesは 1をセヅ卜されなければならない。 RSPN_program_sequence_startの 3 2ビヅトフィールドは、 A Vストリームファイル上でプログラムシーケンスが開始する場所の相対ァドレスである。

RSPN_program_sequence_startは、ソースパケヅト番号を単位とする大きさであり、 A Vストリームファイルの最初のソースパケヅ卜から Cl iplnfo ( ) において定義される o«set_SPNの値を初期値としてカウントされる。その A Vストリームファイルの中での絶対ァドレスは、

SPN_xxx = RSPN_xxx - offset_SPN

により算出される。シンタクスの for- loopの中で RSPN_program_sequence_start値は、昇順に現れなければならない。

PCR_PIDの 1 6ビヅトフィールドは、その program一 sequenceに有効な P C Rフィールドを含むトランスポ一トパケットの P I Dを示す。 number_of一 videosの 8ビヅトフィーレド fま、 video— stream一 PIDと VideoCodinglnfo ( ) を含む： for— loopのレープ回数を示す。 number_of_audiosの 8ビヅトフィ一ルドは、 audio— streaii_PID と AudioCodinglnfo () を含む： for-loopのループ回数を示す。 video_stream_PIDの 1 6ビヅトフィールドは、その program一 sequenceに有効なビデオストリームを含むトランスポートパケヅトの P I Dを示す。このフィールドに続く VideoCodingl nfo () は、その video_stream_PIDで参照されるビデオストリームの内容を説明しなければならない。

audio_stream_PID© 1 6ビヅトフィールドは、その pr"ogram_sequenceに有効なオーディオストリームを含むトランスポートパケヅトの P I Dを示す。このフィ一ルドに続く AudioCodinglnfo () は、その audio_stream_PIDで参照されるビデオストリームの内容を説明しなければならない。

なお、シンタクスの for- loopの中で video一 stream_PIDの値の現れる順番は、その prograui_sequenceに有効な P M Tの中でビデオストリームの P I Dが符号化されている順番に等しくなければならない。また、シンタクスの for-loopの中で au dio_stream_PIDの値の現れる順番は、その program_sequence.に有効な P M Tの中でオーディオストリームの: P I Dが符号化されている順番に等しくなければならない。

図 5 5は、図 5 4に示した Programinfoのシンタクス内の VideoCodinglnfoのシン夕クスを示す図である。図 5 5に示した VideoCodinglnfoのシンタクスを説明すると、 video一 formatの 8ビヅトフィールドは、図 5 6に示すように、 Programlnf 0 ( ) の中の video_stream_PIDに対応するビデオフォーマットを示す。

frame— rateの 8ビヅトフィールドは、図 5 7に示すように、 Programlnfo () の中の video_streain_PIDに対応するビデオのフレームレートを示す。 display_aspe ct—ratioの 8ビヅトフィ一ルドは、図 5 8に示すように、 Program I nfo ( ) の中の video_stream_PIDに対応するビデオの表示ァスぺクト比を示す。

図 5 9は、図 5 4に示した Programinfoのシンタクス内の AudioCodinglnfoのシン夕クスを示す図である。図 5 9に示した AudioCodinglnfoのシンタクスを説明すると、 audio_codingの 8ビヅトフィールドは、図 6 0に示すように、 Programlnf 0 ( ) の中の audio— stream_PIDに対応するォ一ディォの符号化方法を示す。

audi o_component_type © 8ビヅトフィ一ルドは、図 6 1に示すように、 Progra mlnfo ( ) の中の audio_stream_PIDに対応するオーディオのコンポーネントタイプを示す。 sampl ingjrequencyの 8ビットフィールドは、図 6 2に示すように、 Pr ogramlnfo () の中の audio—stream—PIDに対応するオーディオのサンプリング周波数を示す。

次に、図 4 5に示した zzzzz . cl ipのシンタクス内の C P I (Characteristic Point Information) について説明する。 C P Iは、 A Vストリームの中の時間情報とそのファイルの中のァドレスとを関連付けるためにある。 C P Iには 2つの夕イブがあり、それらは EPjnapと TUjnapである。図 6 3に示すように、 CPI ( ) の中の CPし typeが EP_map typeの場合、その CPI () は EPjnapを含む。図 6 4に示すように、 CPI () の中の CPI_typeが TU_map typeの場合、その CPI () は TU_mapを含む。 1つの A Vストリームは、 1つの EP_map又は 1つの TU_mapを持つ。 A Vストリームが S E S Fトランスポートストリ一ムの場合、それに対応する Cl ipは EP_m apを持たなければならない。

図 6 5は、 C P Iのシンタクスを示す図である。図 6 5に示した C P Iのシンタクスを説明すると、 version_numberは、この CPI () のバ一ジョンナンバを示す 4個のキャラクタ一文字である。 version_numberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。 lengthは、この lengthフィールドの直後から CPI ( ) の最後までの CPI () のバイト数を示す 3 2ビットの符号なし整数である。 CPI_typeは、図 6 6に示すように、 1ビットのフラグであり、 Cl ipの C P I の夕イブを表す。

次に、図 6 5に示した C P Iのシンタクス内の EP_mapについて説明する。 EP_m apには、 2つのタイプがあり、それはビデオストリーム用の EP一 mapとオーディオストリーム用の EP_mapである。 EPjmapの中の EP_map_typeが、 EP_mapのタイプを区別する。 Cl ipが 1つ以上のビデオストリームを含む場合、ビデオストリーム用の EP_mapが使用されなければならない。 Cl ipがビデオストリームを含まず、 1っ以上のオーディオストリームを含む場合、オーディオストリ一ム用の EPjnapが使用されなければならない。

ビデオストリ一ム用の EP_mapについて図 6 7を参照して説明する。ビデオストリーム用の EPjnapは、 stream_PID、 PTS_EP_start、及び、 RSPN_EP— startというデ —夕を持つ。 stream_PIDは、ビデオストリームを伝送するトランスポートパケヅトの P I Dを示す。 PTS_EP_startは、ビデオストリームのシーケンスへヅダから始めるアクセスュニヅトの P T Sを示す。 RSPN_EP_startは、 A Vストリームの中で PTS_EP— startにより参照されるアクセスュニヅトの第 1バイト目を含むソースポケットのァドレスを示す。

EP_map_f or_one_stream_P ID () と呼ばれるサブテーブルは、同じ P I Dを持つトランスポートパケットによって伝送されるビデオストリーム毎に作られる。 C1 ipの中に複数のビデオストリームが存在する場合、 EPjnapは複数の EP_map_for_o ne_stream_PID ( ) を含んでもよい。

オーディオストリーム用の EPjnapは、 stream_P ID、 PTS_EP_start、及び RSPN_E P一 startというデータを持つ。 stream— P IDは、オーディオストリームを伝送するトランスポートパケヅトの P I Dを示す。 PTS_EP— startは、オーディオストリームのアクセスユニットの P T Sを示す。 RSPN_EP_startは、 A Vストリームの中で P TS_EP一 startで参照されるアクセスュニットの第 1バイト目を含むソースポケットのァドレスを示す。

EP_map_for_one_stream_P ID ( ) と呼ばれるサブテ一ブルは、同じ P I Dを持つトランスポートパケヅトによって伝送されるオーディオストリーム毎に作られる。 C l ipの中に複数のオーディオストリームが存在する場合、 EP_mapは複数の EPjap _for_one_stream_P ID ( ) を含んでもよい。

EPjnapと ST Infoの閧係を説明すると、 1つの EP_map_:for— one_stream_PID ( ) は、 S T Cの不連続点に関係なく 1つのテーブルに作られる。 RSPN_EP_startの値と STC一 Info ( ) において定義される RSPN_STC_startの値を比較することにより、それそれの STC_sequenceに属する EPJ LPのデータの境界が分かる（図 6 8を参照）。 EPjiapは、同じ P I Dで伝送される連続したストリームの範囲に対して、 1つの EP_map_f or_one_stream一 P IDを持たねばならない。図 6 9に示したような場合、 program#lと program#3は、同じビデオ P I Dを持つが、データ範囲が連続していないので、それそれのプログラム毎に EP_map_for一 one_stream_PIDを持たねばならない。

図 7 0は、 EP— mapのシンタクスを示す図である。図 7 ◦に示した EPjnapのシン夕クスを説明すると、 EP_typeは、 4ビヅトのフィールドであり、図 7 1に示すように、 EP_mapのエントリポイントタイプを示す。 EP_typeは、このフィールドに続くデ一夕フィールドのセマンティクスを示す。 C l ipが 1つ以上のビデオストリームを含む場合、 EP_typeは 0 (' vi deo' ) にセヅトされなければならない。又は、 C l ipがビデオストリームを含まず、 1つ以上のオーディオストリームを含む場合、 EP_typeは 1 (' audi o' ) にセヅトされなければならない。

num e r_o f _s t r e am_P IDs© 1 6ビヅトのフィールドは、 EPjnap ( ) の中の numbe r of .stream PIDsを変数に持つ for-loopのループ回数を示す。 stream PID (k) の 1 6ビットのフィールドは、 EP— map一 for— one_stream一 PID (num_EP— entries (k) ) によって参照される k番目のエレメンタリーストリーム（ビデオ又はォーディォストリーム）を伝送するトランスポートパケヅトの P I Dを示す。 EP_typ eが 0 (' video' ) に等しい場合、そのエレメン夕リストリームはビデオストリームでなければならない。また、 EP_typeが 1 (' audio' ) に等しい場合、そのエレメンタリストリームはオーディオストリームでなければならない。

nui_EP_entries (k) の 1 6ビヅトのフィーノレド ίま、 EP— map— f,or_one— stream一 Ρ ID (num_EP— entries (k) ) によって参照される num— EP_entries (k) を示す。 EP _map_for_one_stream_PID_Start_address (k) ：この 32ビヅトのフィールドは、 EP_map ( ) の中で EP_map— for— one— stream_PID (匪一 EP_entries (k) ) が始まる相対バイト位置を示す。この値は、 EP_map () の第 1バイト目からの大きさで示される。

padding_wordは、 EPjnap () のシンタクスに従って挿入されなければならない。 Xと Yは、 0又は任意の正の整数でなければならない。それそれのパディングヮードは、任意の値を取ってもよい。

図 7 2は、 EP_map_for_one_streani_PIDのシンタクスを示す図である。図 7 2に示した EP_map_for_one— stream一 PIDのシンタクスを説明すると、 PTS_EP_startの 3 2ビットのフィールドのセマンティクスは、 EPjaap () において定義される EP_t ypeにより異なる。 EP— typeが 0 (' video' ) に等しい場合、このフィールドは、ビデォストリームのシーケンスへヅダで始まるアクセスユニットの 3 3ビヅト精度の P T Sの上位 3 2ビヅトを持つ。 EP_typeが 1 (' audio' ) に等しい場合、このフィールドは、オーディオストリームのアクセスュニヅトの 3 3ビヅト精度の P T Sの上位 3 2ビットを持つ。

RSPN— EP_startの 3 2ビットのフィールドのセマンティクスは、 EP_map () において定義される EP_typeにより異なる。 EP_typeが 0 (' video' ) に等しい場合、このフィールドは、 A Vストリームの中で PTS_EP_startにより参照されるアクセスュニヅトのシーケンスへヅダの第 1バイト目を含むソースポケヅ卜の相対ァドレスを示す。又は、 EP_typeが 1 (' audio' ) に等しい場合、このフィールドは、 A Vストリームの中で PTS EP startにより参照されるアクセスュニヅトのォ一ディオフレームの第一バイト目を含むソースポケヅトの相対ァドレスを示す。

RSPN— EP_startは、ソースパケット番号を単位とする大きさであり、 A Vストリームファイルの最初のソースパケットから Cl iplnfo () において定義される offset — SPIiの値を初期値としてカウントされる。その A Vストリームファイルの中での絶対ァドレスは、

SPN一 XXX = RSPN.xxx - offset— SPN

により算出される。シンタクスの for-loopの中で RSPN_EP_startの値は、昇順に現れなければならない。

次に、 TUjaapについて、図 7 3を参照して説明する。 TU_mapは、ソースパケットのァライバルタイムクロック（到着時刻ペースの時計）に基づいて、 1つの時間軸を作る。その時間軸は、 TU_map_time一 axisと呼ばれる。 TU_map— time_axisの原点は、 TU_map () の中の offset—tineによって示される。 TU_map_time_axisは、 offset_timeから一定の単位に分割される。その単位を、 tinie_unitという。

A Vストリームの中の各々の time_uni tの中で、最初の完全な形のソースパケヅトの A Vストリームフアイル上のァドレスが、 TU_mapにストアされる。これらのアドレスを、 RSPN_time_unit_startという。 TUjiap_time_axis上において、 k (k>=0) 番目の time_unitが始まる時刻は、 TU_start_time (k) と呼ばれる。この値は次式に基づいて算出される。

TU— start— time (k = offset— time + k*time一 unit— size

TU_start_time (k) は、 4 5 k H zの精度を持つ。

図 7 5は、 TU_mapのシンタクスを示す図である。図 7 5に示した TUjnapのシン夕クスを説明すると、 0 361;_^1116の3 2 13 長のフィールドは、 TUjaap_tiiiie_ax isに対するオフセットタイムを与える。この値は、 Cl ipの中の最初の time_unitに対するオフセヅト時刻を示す。 offset_tii eは、 2 7 M H z精度のァライバルタイムクロックから導き出される 4 5 k H zクロヅクを単位とする大きさである。 A Vストリームが新しい Cl ipとして記録される場合、 offset_timeは 0にセヅトされなければならない。

tiine_unit_sizeの 3 2 ビヅトフィールドは、 time_unitの大きさを与えるものであり、それは 2 7 M H z精度のァライバルタイムクロヅクから導き出される 4 5 k H zクロックを単位とする大きさである。 time_unit_sizeは、 1秒以下（time — unit_sizeく =45000) にすることがよい。 number— of— time_un i t— entriesの 3 2ビヅトフィールドは、 TU_map () の中にストァされている tiine_unitのェントリ数を示す。

RSPN_tine_unit_startの 3 2ビヅトフィールドは、 A Vストリームの中でそれそれの time_unitが開始する場所の相対ァドレスを示す。 RSPN一 time— unit— startは、ソースパケヅト番号を単位とする大きさであり、 AV streamファイルの最初のソースパケットから Cl iplnfo ( ) において定義される offset_SPNの値を初期値としてカウントされる。その AV streamファイルの中での絶対ァドレスは、

SPN_xxx = RSPN_xxx - offset_SPN

により算出される。シンタクスの for- loopの中で RSPfLtime_iinit_startの値は、昇順に現れなければならない。（k + 1 ) 番目の tiiie_unitの中にソースパケヅトが何もない場合、（k + 1 ) 番目の RSPN_time_unit— startは、 k番目の RSPN—tim e_unit_startと等しくなければならない。

図 4 5に示した zzzzz. cl ipのシンタクス内の Cl ipMarkについて説明する。 Cl ip Markは、クリヅプについてのマーク情報であり、 Cl ipMarkの中にストアされる。このマークは、記録器（記録再生装置 1 ) によってセヅトされるものであり、ュ —ザによってセットされるものではない。

図 7 5は、 Cl ipMarkのシンタクスを示す図である。図 7 5に示した Cl ipMarkのシンタクスを説明すると、 version_miniberは、この Cl ipMark () のバージョンナンバを示す 4個のキャラクタ一文字である。 version_numberは、 I S O 6 4 6に従って、 "0045"と符号化されなければならない。

lengthは、この lengthフィールドの直後から Cl ipMark ( ) の最後までの Cl ipMa rk ( ) のバイト数を示す 3 2 ビヅトの符号なし整数である。 number_of_Cl ip_iiiar ksは、 Cl ipMarkの中にストァされているマークの個数を示す 1 6 ビヅトの符号なし整数であり、 number— of— Cl ipjuarks は、 0であってもよい。 mark_typeは、マークのタイブを示す 8ビットのフィールドであり、図 7 6に示すテーブルに従つて符号化される。

mark_time stampは、 3 2ビットフィールドであり、マークが指定されたボイントを示すタイムスタンプをストアする。 mark_tinie_staiiipのセマンティクスは、図 7 7に示すように、 PlayList () の中の CPし typeにより異なる。

STC_sequence_idは、 CPI () の中の CPし typeが EPjnap typeを示す場合、この 8 ビヅトのフィールドは、マークが置かれているところの S T C連続区間の STC_se quence_idを示す。 CPI () の中の CPし typeが TUjaap typeを示す場合、この 8ビヅトのフィールドは何も意味を持たず、 0にセットされる。 character_setの 8ビヅトのフィ一ルドは、 markjiameフィ一ルドに符号化されているキャラク夕一文字の符号化方法を示す。その符号化方法は、図 1 9に示される値に対応する。

name— lengthの 8ビヅトフィールドは、 Mark_nameフィールドの中に示されるマーク名のバイト長を示す。 mark— nameのフィールドは、マークの名称を示す。このフィールドの中の左から namejength数のバイト数が、有効なキャラクタ一文字であり、それはマークの名称を示す。 ] nark_nameフィールドの中で、それら有効なキャラク夕一文字の後の値は、どんな値が入っていてもよい。

ref_thuinbnaiし indexのフィ一ルドは、マークに付加されるサムネイル画像の情報を示す。 ref_thumbnai l— indexフィールドが、 OxFFFFでない値の場合、そのマ一クにはサムネイル画像が付加されており、そのサムネイル画像は、 mark. thmbファィルの中にストアされている。その画像は、 mark. thmbファイルの中で ref_thumb naiし indexの値を用いて参照される。 ref— thumbnai l— indexフィールドが、 OxFFF F である場合、そのマークにはサムネイル画像が付加されていない。

MakersPrivateDataについては、図 2 2を参照して既に説明したので、その説明は省略する。

次に、サムネイルインフォメーション（Thumbnai l Information) について説明する。サムネイル画像は、 menu. thmbファイル又は mark. thmbファイルにストアされる。これらのファイルは同じシンタクス構造であり、ただ 1つの Thumbnail () を持つ。 memi. thmbファイルは、メニューサムネイル画像，すなわち Volumeを代表する画像、及び、それそれの PlayListを代表する画像をストアする。全てのメニユーサムネイルは、ただ 1つの menu. thmbファイルにストァされる。

mark. thnilDファイルは、マ一クサムネイル画像，すなわちマーク点を表すピクチャをストァする。全ての PlayList及び Cl ipに対する全てのマークサムネイルは、ただ 1つの mark. thmbファイルにストアされる。サムネイルは頻繁に追加、削除されるので、追加操作と部分削除の操作は容易に高速に実行できなければならない。この理由のため、 Thumbnai l () はプロヅク構造を有する。画像のデ一夕はいくつかの部分に分割され、各部分は 1つの tn_blockに格納される。 1つの画像デ一夕は連続した tn_blocliに格納される。 tn_blockの列には、使用されていない tn_b】o ckが存在してもよい。 1つのサムネイル画像のパイト長は可変である。

図 7 8は、 menu. thmbと mark. thmbのシンタクスを示す図であり、図 7 9は、図 7 8に示した menu . thibと mark . thmbのシンタクス内の Thumbnai 1のシンタクスを示す図である。図 7 9に示した Thumbnai lのシンタクスについて説明すると、 versi on_numberは、この Thumbnai l () のバ一ジョンナンバを示す 4個のキャラクター文字である。 version_iminberは、 I S O 6 4 6に従って、 " 0045"と符号化されなければならない。

lengthは、この lengthフィールドの直後から Thumbnai l ( ) の最後までの Maker sPrivateData () のバイト数を示す 3 2 ビヅトの符号なし整数である。 tn_block s_start_addressは、 Thumbnai l () の先頭のバイトからの相対バイト数を単位として、最初の tn_blockの先頭バイトァドレスを示す 3 2 ビヅトの符号なし整数である。相対バイト数は 0からカウントされる。 number一 of— thumbnai Isは、 Thumbn ai l () の中に含まれているサムネイル画像のェントリ数を与える 1 6ビットの符号なし整数である。

tn_block_sizeは、 1 0 2 4バイトを単位として、 1つの tn_Mockの大きさを与える 1 6ビットの符号なし整数である。例えば、 tn_block_si e= 1ならば、それは 1つの tn_blockの大きさが 1024バイトであることを示す。 number_o tn_block sは、この Thumbnai l () 中の tn_blockのエントリ数を表す 1 1 6ビヅトの符号なし整数である。 thumbnaiし indexは、この thumbnaiし indexフィールドから始まる fo rループ一回分のサムネイル情報で表されるサムネイル画像のィンデクス番号を表す 1 6ビヅトの符号なし整数である。 thumbnai l_index として、 OxFFFFという値を使用してはならない。 thumbnai l一 index は UIAppInfoVolume () 、 UIAppInfoPl ayList () 、 PlayListMark ( ) 、及び Cl ipMark () の中の ref_thumbnaiし index によって参照される。 thumbnaiし picture— formatは、サムネイル画像のピクチャフォーマヅトを表す 8ビットの符号なし整数で、図 80に示すような値をとる。表中の DCFと PNGは" m enu.thmb"内でのみ許される。マークサムネイルは、値" 0x00" (MP E G - 2 V ideo I-picture) をとらなければならない。

picture_data_sizeは、サムネイル画像のバイト長をバイト単位で示す 32ビヅトの符号なし整数である。 start_tn_block_numberは、サムネイル画像のデータが始まる tn_blockの tnjlock番号を表す 1 6ビットの符号なし整数である。サムネィル画像デ一夕の先頭は、 tb— blockの先頭と一致していなければならない。 tn_b lock番号は、 0から始まり、 tn_blockの for-ル一プ中の変数 kの値に関係する。 x_picture_lengthは、サムネイル画像のフレーム画枠の水平方向のピクセル数を表す 1 6ビットの符号なし整数である。 y_picture_lengthは、サムネイル画像のフレーム画枠の垂直方向のピクセル数を表す 1 6ビッ卜の符号なし整数である。 tn_blockは、サムネイル画像がストアされる領域である。 Thumbnail () の中の全ての tnjalockは、同じサイズ（固定長）であり、その大きさは tn_block_sizeによって定義される。

図 8 1 A及ぴ図 81 Bは、サムネイル画像デ一夕がどのように tn_blockに格納されるかを模式的に表した図である。図 8 1 A及び図 8 1 Bのように、各サムネィル画像デ一夕は tn_blockの先頭から始まり、 1 tn_blockを超える大きさの場合は、連続する次の tn_blockを使用してストアされる。このようにすることにより、可変長であるピクチャデータが、固定長のデータとして管理することが可能となり、削除といつた編集に対して簡便な処理により対応することができるようになる。

次に、 AVストリームファイルについて説明する。 AVストリームファイルは、 "M2TS"ディレクトリ（図 14) にストアされる。 AVストリームファイルには、 2つのタイプがあり、それらは、 Clip AVストリームと Bridge-Clip AVストリームファイルである。両方の AVストリーム共に、これ以降で定義される DVR MPEG— 2 トランスポートストリームファイルの構造でなければならない。先ず、 DVR MPEG— 2 トランスポートストリームについて説明する。 D VR MPEG— 2 トランスポートストリームの構造は、図 82に示すようになつている。 AVストリームファイルは、 DVR MP E G 2 トランスポートストリームの構造を持つ。 DVR MPEG2 トランスポ一トストリームは、整数個の A ligned unitから構成される。 Aligned unitの大きさは、 6 144 ノ¹？イト（204 8*3 バイト）である。 Aligned unitは、ソースパケヅトの第 1パイト目から始まる。ソースパケヅトは、 192バイト長である。 1つのソースパケットは、 TP_e xtrajieaderとトランスポートパケットからなる。 TP_extra_heade ま、 4バイト長であり、またトランスポートパケットは、 1 88バイト長である。

1つの Aligned unitは、 32個のソ一スパケヅトからなる。 DVR MP E G 2 トランスポートストリームの中の最後の Aligned unitも、また 32個のソースパケヅトからなる。よって、 DVR MPEG 2 トランスポートストリームは、 Ali . gned unitの境界で終端する。ディスクに記録される入力トランスポ一トストリ一ムのトランスポートパケットの数が 32の倍数でないとき、ヌルパケット（PID- OxlFFFのトランスポートパケヅト）を持ったソースパケヅトを最後の Aligned un itに使用しなければならない。ファイルシステムは、 DVR MPEG 2 トランスポートストリームに余分な情報を付加してはならない。

図 83に、 DVR MPE G— 2 トランスポ一トストリームのレコ一ダモデルを示す。図 83に示したレコーダは、レコーディングプロセスを規定するための概念上のモデルである。 DVR MPEG— 2 トランスポ一トストリームは、このモァレに従う。

MPEG— 2 トランスポートストリームの入力タイミングについて説明する。入力 MP EG 2 トランスポートストリームは、フルトランスポートストリーム又はパーシャルトランスポートストリームである。入力される MPEG 2 トランスポートストリームは、 I SO/I E C 1 3818— 1又は I SO/I E C 138 1 8— 9に従っていなければならない。 MPEG2 トランスポートストリームの i番目のバイトは、 T— S TD ( I S 0/1 E C 1 381 8— 1で規定される Tra nsport stream system target decoder) とソースノケヅ夕ィザ一へ、時刻 t (i) に同時に入力される。 Rpkは、トランスポートパケットの入力レートの瞬時的な最大値である。

27MHz PLL52は、 27 MH zクロックの周波数を発生する。 27MH zクロヅクの周波数は、 M P E G— 2 トランスポートストリームの P C R (Program C lock Reference) の値にロヅクされる。 arrival time clock counter 5 3は、 2 7 M H zの周波数のパルスをカウン卜するバイナリーカウンタ一である。 Arriva 1—time— clock ( i) は、時刻 t ( i) における Arrival time clock counterのカウント値である。

source packetizer 5 4 ίま、全てのトランスポートノケヅト【こ TP一 extra— header を付加し、ソースパケヅトを作る。 Arrival_time_stampは、トランスポートパケヅ卜の第 1バイト目が T— S T Dとソースパケヅ夕ィザ一の両方へ到着する時刻を表す。 Arrival一 time一 stamp (k) は、次式で示されるように Arrival_time—cloc k (k) のサンプル値であり、ここで、 kはトランスボ一トパケヅトの第 1バイト目を示す。

arrival— time— stamp (k) 二 arrival— time_clock (k) % 230

2つの連続して入力されるトランスポートパケヅトの時間間隔が、 230/270000 00秒（約 40秒）以上になる場合、その 2つのトランスポートパケットの arrival一 time一 stampの差分は、 230/27000000秒になるようにセヅトされるべきである。レコーダは、そのようになる場合に備えてある。

smoothing buffer 5 5は、入力トランスポートストリームのビヅトレ一トをスム一ジングする。スムージングバッファは、オーバーフロウしてはならない。 Rm axは、スムージングバヅファが空でないときのスムージングバヅファからのソ一スパケヅトの出力ビヅトレートである。スム一ジングバッファが空であるとき、スム一ジングバヅファからの出力ビットレートは 0である。

次に、 D V R M P E G— 2 トランスポートストリームのレコーダモデルのパラメータについて説明する。 Rmaxという値は、 A Vストリームファイルに対応する Cl iplnfo ( ) において定義される TS_recording_rateによって与えられる。この値は、次式により算出される。

Rmax = TS— recording— rate * 192/188

TS_recording一 rateの値は、 bytes/secondを単位とする大きさである。

入力トランスポートストリームが S E S F トランスポートストリームの場合、 Rpkは、 A Vストリームファイルに対応する Cl iplnfo ( ) において定義される TS recording_rateに等しくなければならない。入力トランスポートストリ一ムが S E S Fトランスポートストリームでない場合、この値は MP EG— 2 transport streamのテスクリプター, 例； Lば maximum一 bitrate一 descriptorや partial— trans port_streaBi_descriptor等において定義される値を参照してもよい。

smoothing buffer sizeは、入力トランスポ一トストリームが SE SFトランスポートストリームの場合、スム一ジングバッファの大きさは 0である。入力トランスポ一トストリームが SE SFトランスポートストリームでない場合、スムージングバッファの大きさは MP E G— 2 transport streamのデスクリブ夕一、例兄ば smoothing—buf:fer_descriptor、 short_smoothing一 buffer— descriptor、 part ial一 transport— stream_descriptor等において定義される値を参照してもよい。記録機（レコーダ）及び再生機（プレーヤ）は、十分なサイズのバッファを用意しなければならない。デフォルトのバヅファサイズは、 1536 bytes である。次に、 DVR MPE G— 2 トランスポートストリームのプレーヤモデルについて説明する。図 84は、 DVR MPEG— 2 トランスポートストリームのプレーャモデルを示す図である。これは、再生プロセスを規定するための概念上のモデルである。 DVR MPEG— 2 トランスポートストリームは、このモデルに従う <

27MHz X-tal 6 1は、 27 M H zの周波数を発生する。 27 MHz周波数の誤差範囲は、 +/-30 ppm (27000000 +/- 810 Hz) でなければならない。 arrival tim e clock counter 62は、 27 MH zの周波数のパルスをカウントするバイナリ一カウン夕一である。 Arrivaし tinie_clock (i) は、時刻 t ( i ) における Arrival time clock counterのカウン卜値である。

smoothing buffer 64において、 Rmaxは、スム一ジングバヅファがフルでないときのスムージングバヅファへのソースパケヅトの入力ビットレ一トである。スムージングバッファがフルであるとき、スムージングバヅファへの入力ビヅトレ —トは 0である。

MPEG- 2 トランスポートストリームの出力タイミングを説明すると、現在のソースパケヅトの arrival— time— stampが arrival_time— clock (i) の LSB 30ビヅトの値と等しいとき、そのソースパケットのトランスポートパケットは、スム一ジングバヅファから引き抜かれる。 Rpkは、トランスポートパケヅトレートの瞬時的な最大値である。スムージングバッファは、アンダーフロウしてはならない。

D VR MPEG— 2 トランスポートストリームのプレーヤモデルのパラメ一夕については、上述した D VR MPEG— 2 トランスポートストリームのレコーダモデルのパラメ一夕と同一である。

図 85は、 Source packetのシンタクスを示す図である。 transport_packet () は、 I SO/I E C 13818— 1で規定される MP E G— 2 トランスポートパケットである。図 85に示した Source packetのシンタクス内の TP— Extrajiead erのシンタクスを図 86に示す。図 86に示した TP_Extra_headerのシンタクスについて説明すると、 copy_permission_indicatorは、トランスポートパケヅトのぺィロードのコピ一制限を表す整数である。コピ一制限は、 copy frees no more c opy、 copy once、又は copy prohibitedとすることができる。図 87は、 copy_pe rmission_indicatorの値と、それらによつて指定されるモードめ関係を示す。 copy— permission— indicatorは、全てのトランスポートパケヅトに付加される。 I E E E 1394ディジタルイン夕フェースを使用して入力トランスポートストリームを記録する場合、 copy_permission_indicatorの値は、 IEEE1394 isochron ous packet headerの中の EMI (Encryption Mode Indicator) の値に関連付けてもよい。 I EEE 1 394ディジタルインタフェースを使用しないで入カトランスボ一トストリームを記録する場合、 copy一 permission—indicatorの値は、卜ランスポートパケットの中に埋め込まれた C C Iの値に関連付けてもよい。アナログ信号入力をセルフエンコードする場合、 copy_permission— indicatorの値は、アナログ信号の CGMS-Aの値に関連付けてもよい。

arrival— time— stampは、次式

arrivaし time— stamp (k) = arrival— time— clock (k) % 230

において、 arrivaし time_staiipによって指定される値を持つ整数値である。

Clip AVストリームの定義をすると、 Clip AVストリームは、上述したような定義がされる DVR MPEG— 2トランスポートストリームの構造を持たねばならない。 arrivaし time_clock (i) は、 Clip A Vストリームの中で連続して增加しなければならない。 Clip AVストリームの中にシステムタイムベース（ST Cベース）の不連続点が存在したとしても、その Clip A Vストリームの arrival _time_clock (i) は、連続して増加しなければならない。

Clip AVストリームの中の開始と終了の間の arrivaし time_clock ( i ) の差分の最大値は、 2 6時間でなければならない。この制限は、 MPEG 2 トランスポ —トストリームの中にシステムタイムベース（S T Cペース）の不連続点が存在しない場合に、 Clip A Vストリームの中で同じ値の P T S (Presentation Time Stamp) が決して現れないことを保証する。 MP E G 2システムズ規格は、 PT Sのラップアラウンド周期を 233/90000秒（約 26.5時間） .と規定している。

Bridge-Clip AVストリームの定義をすると、 Bridge-Clip AVストリームは、上述したような定義がされる DVR MPEG— 2 トランスポ一トストリームの構造を持たねばならない。 Bridge-Clip AVストリームは、 1つのァライバル夕ィムペースの不連続点を含まなければならない。ァライバルタイムペースの不連続点の前後のトランスポ一トストリームは、後述する符号化の制限に従わなければならず、且つ後述する DVR— S TDに従わなければならない。

本例においては、編集における Playltem間のビデオとオーディオのシームレス接続をサポートする。 Playltem間をシームレス接続にすることは、プレーヤ/レ . コーダに"デ一夕の連続供給"と"シームレスな復号処理"を保証する。 "デ一夕の連続供給"とは、ファイルシステムが、デコーダにバッファのアンダーフロウを起こさせることのないように必要なビットレ一トでデ一夕を供給することを保証できることである。データのリアルタイム性を保証して、データをディスクから読み出すことができるように、データが十分な大きさの連続したブロック単位でストァされるようにする。

"シームレスな復号処理"とは、プレーヤが、デコーダの再生出力にポーズゃギャヅブを起こさせることなく、ディスクに記録されたオーディオビデオデ一夕を表示できることである。

シームレス接続されている Playltemが参照する A Vストリームについて説明する。先行する Playltemと現在の Playltemの接続が、シームレス表示できるように保証されているかどうかは、現在の Playltemにおいて定義されている connection —conditionフィールドから判断することができる。 Playltem間のシームレス接続は、 Bridge-Clipを使用する方法と使用しない方法がある。図 8 8は、 Bridge-Cl ipを使用する場合の先行する Playltemと現在の Playltemの関係を示している。図 8 8においては、プレーヤが読み出すストリームデ一夕が、影を付けて示されている。図 8 8に示した T S 1は、 Cl ipl (Cl ip A Vストリ一ム）の影を付けられたストリームデ一夕と Bridge-Clipの RSPN_arrival_time一 dis continuityより前の影を付けられたストリームデ一夕からなる。

T S 1の Cl iplの影を付けられたストリームデータは、先行する Playltemの IN_ time (図 8 8において IN_timelで図示されている）に対応するプレゼンテ一ションュニヅトを復号するために必要なストリームのァドレスから、 RSPN一 exit_from _previous— Cl ipで参照されるソースパケヅトまでのストリームデ一夕である。 T S 1に含まれる Bridge - Cl ipの RSPN_arrival— time— discontinuityより前の影を付けられたストリームデ一夕は、 Bridge- Cl ipの最初のソースパケットから、 RSPN_ arrival一 time_discontinuityで参照されるソースパケヅトの直前のソースパケヅトまでのストリームデータである。

また、図 8 8における T S 2は、 Cl ip2 (Cl ip A Vストリーム）の影を付けられたストリームデ一夕と Bridge - Cl ipの RSPN_arrival_time— discontinuity以後の影を付けられたストリ一ムデ一夕からなる。 T S 2に含まれる Bridge-Cl ipの RSP N_arrivaし time_discontinuity以後の影を付けられたストリームデ一夕は、 RSPN —arrival— time— discontinuityで参照されるソースパケヅトから、 Bridge— Cl ipの最後のソースパケヅトまでのストリームデータである。 T S 2の Cl ip2の影を付けられたストリームデータは、 RSPN_entei _to_curren1 _Cl ipで参照されるソースパケヅトから、現在の Playltemの 0UT_time (図 8 8において 0UT_time2で図示されている）に対応するプレゼンテーションュニヅトを復号するために必要なストリームのアドレスまでのストリ一ムデ一夕である。

図 8 9は、 Bridge-Cl ipを使用しない場合の先行する Playltemと現在の Playlte πιの関係を示している。この場合、プレーヤが読み出すストリームデ一夕は、影を付けて示されている。図 8 9における T S 1は、 Cl ipl (Cl ip A Vストリーム）の影を付けられたストリームデ一夕からなる。 T S 1の Cl iplの影を付けられたストリームデータは、先行する Playltemの IN_time (図 8 9において IN— timelで図示されている）に対応するプレゼンテーションュニヅトを復号するために必要なストリームのァドレスから始まり、 Cliplの最後のソースパケヅトまでのデ一夕である。また、図 89における TS 2は、 Clip2 (Clip A Vストリーム）の影を付けられたストリームデ一夕からなる。

T S 2の Clip2の影を付けられたストリームデ一夕は、 Clip2の最初のソースパケットから始まり、現在の Playltemの 0UT_time (図 89において 0UT_time2で図示されている）に対応するプレゼンテーションュニヅトを復号するために必要なストリームのァドレスまでのストリームデ一夕である。

図 88と図 89において、丁 31と丁 32は、ソ一スパケットの連続したストリームである。次に、 T S 1と T S 2のストリーム規定と、それらの間の接続条件について考える。先ず、シームレス接続のための符号化制限について考える。トランスポートストリームの符号化構造の制限として、先ず、で31とで32の中に含まれるプログラムの数は、 1でなければならない。 T S 1と T S 2の中に含まれるビデオストリームの数は、 1でなければならない。丁31と？ 32の中に含まれるオーディオストリームの数は、 2以下でなければならない。 TS 1と T S 2の中に含まれるオーディオストリームの数は、等しくなければならない。 T S 1及び/又は T S 2の中に、上記以外のエレメン夕リーストリーム又はブラィペートストリームが含まれていてもよい。

ビデオビヅトストリームの制限について説明する。図 90は、ピクチャの表示順序で示すシームレス接続の例を示す図である。接続点においてビデオストリームをシームレスに表示できるためには、 OUT— timel (Cliplの 0UT_time) の後と IN _time2 (Clip2の IILtime) の前に表示される不必要なピクチャは、接続点付近の Clipの部分的なストリームを再ェンコ一ドするプロセスにより、除去されなければならない。

図 90に示したような場合において、 BridgeSequenceを使用してシームレス接続を実現する例を、図 9 1に示す。 RSPN_arrival一 time_discontinuityより前の B ridge-Clipのビデオストリームは、図 90の Cliplの OUT一 timelに対応するピクチャまでの符号化ビデオストリームからなる。そして、そのビデオストリームは先行する Cliplのビデオストリームに接続され、 1つの連続で MP E G 2規格に従つたエレメンタリーストリームとなるように再ェンコ一ドされている。同様にして、 RSPN_arrivaし time— discontinuity以後の Bridge- Cl ipのビデオストリームは、図 9 0の Cl ip2の IN_time2に対応するピクチャ以後の符号化ビデオストリ一ムからなる。そして、そのビデオストリームは、正しくデコ一ド開始することができて、これに続く Cl ip2のビデオストリームに接続され、 1つの連続で M P E G 2規格に従ったエレメン夕リーストリームとなるように再エンコードされている。 Bridge- Cl ipを作るためには、一般に、数枚のピクチャは再エンコードしなければならず、それ以外のピクチャはオリジナルの C 1 i pからコピーすることができる。

図 9 0に示した例の場合に BridgeSequenceを使用しないでシームレス接続を実現する例を図 9 2に示す。 Cl iplのビデオストリームは、図 9 ◦の 0UT_timelに対応するピクチャまでの符号化ビデオストリームからなり、それは、 1つの連続で M P E G 2規格に従ったエレメン夕リーストリームとなるように再エンコードされている。同様にして、 Cl ip2のビデオストリームは、図 9 0の Cl ip2の IN_time2 に対応するピクチャ以後の符号化ビデオストリームからなり、それは、 1つの連続で M P E G 2規格に従ったエレメン夕リーストリームとなるように再ェンコ一ドされている。

ビデオストリームの符号化制限について説明すると、先ず、 3 1と 3 2のビデオストリームのフレームレートは、等しくなければならない。 T S 1のビデォストリームは、 sequence_end_codeで終端しなければならない。 T S 2のビデオストリームは、 Sequence Header^ GOP Header, そして Iピクチャで開始しなければならない。 T S 2のビデオストリームは、クローズド G0Pで開始しなければならない。

ビットストリームの中で定義されるビデオプレゼンテーションュニヅト（フレ —ム又はフィールド）は、接続点を挾んで連続でなければならない。接続点において、フレ一ム又はフィールドのギャップがあってはならない。接続点において、トップ一ボトムのフィールドシーケンスは連続でなければならない。 3— 2プルダウンを使用するエンコードの場合は、 "top_field_first" 及び "repeat_f irst 一 field"フラグを書き換える必要があるかもしれない，又はフィ一ルドギャップの発生を防く、ために局所的に再ェンコードするようにしてもよい。オーディオビヅトストリームの符号化制限について説明すると、 T S 1と T S 2のオーディオのサンプリング周波数は、同じでなければならない。 T S 1と T S 2のォ一ディォの符号化方法（例. MP E G 1レイヤ 2 , AC— 3 , SE S F LP CM, AAC) は、同じでなければならない。

次に、 MPEG— 2 トランスボートストリームの符号化制限について説明すると、 T S 1のオーディオストリームの最後のオーディオフレームは、 T S 1の最後の表示ピクチャの表示終了時に等しい表示時刻を持つオーディオサンプルを含んでいなければならない。 TS 2のオーディオストリームの最初のオーディオフレームは、 T S 2の最初の表示ピクチャの表示開始時に等しい表示時刻を持つォ一ディオサンプルを含んでいなければならない。

接続点において、オーディオプレゼンテーションュニヅトのシーケンスにギヤヅプがあってはならない。図 93に示すように、 2オーディオフレーム区間未満のオーディオプレゼンテーションュニヅ卜の長さで定義されるオーバ一ラヅプがあってもよい。 T S 2のエレメンタリーストリームを伝送する最初のパケヅトは、ビデオパケヅトでなければならない。接続点におけるトランスポ一トストリームは、後述する D VR— S TDに従わなくてはならない。

Clip及び Bridge- Clipの制限について説明すると、 T S 1と T S 2は、それそれの中にァライバルタイムベースの不連続点を含んではならない。

以下の制限は、 Bridge-Clipを使用する場合にのみ適用される。 T S 1の最後のソースパケヅトと T S 2の最初のソースパケヅトの接続点においてのみ、 Bridge -Clip AVストリームは、ただ 1つのァライバルタイムベースの不連続点を持つ _c Cliplnfo () において定義される RSPN_arrivaし time一 discontinuityが、その不連続点のァドレスを示し、それは TS 2の最初のソースパケットを参照するァドレスを示さなければならない。

Bridge Sequence Info () こおヽて定義される RSPN一 exit_from一 previous一 Glip : よって参照されるソ一スパケヅトは、 Cliplの中のどのソースパケヅトでもよい。それは、 Aligned unitの境界である必要はない。 BridgeSequencelnfo () において定義される RSPN_enter_to—current_C 1 ipによって参照されるソースパケットは、 Clip2の中のどのソースパケットでもよい。それは、 Aligned unitの境界である必要はない。

Playltemの制限について説明すると、先行する Playlteiu OUTJime (図 88、図 89において示される 0UT_timel) は、 T S 1の最後のビデオプレゼンテーションュニットの表示終了時刻を示さなければならない。現在の Playltemの IN一 time 図88、図 89において示される IN_tinie2) は、 T S 2の最初のビデオプレゼンテーシヨンュニットの表示開始時刻を示さなければならない。

Bridge- Clipを使用する場合のデータァロケ一シヨンの制限について、図 94を参照して説明すると、シームレス接続は、ファイルシステムによってデータの連続供給が保証されるように作られなければならない。これは、 Clipl (Clip AV ストリームファイル）と Clip2 (Clip A Vストリームファイル）に接続される Br idge-Clip A Vストリームを、デ一夕アロケーション規定を満たすように配置することによって行われなければならない。

RSPN_exit一む om—previous_Clip以前の Clipl (Clip AVストリームファイル）のストリーム部分が、ハーフフラグメント以上の連続領域に配置されているように、 RSPN_exit_from_previous_Clipが選択されなければならない。 Bridge-Clip AVストリームのデ一夕長は、ハーフフラグメント以上の連続領域に配置されるように、選択されなければならない。 RSPN_enter—to_current— Clip以後の Clip2 (Clip AVストリームファイル）のストリーム部分が、ハーフフラグメント以上の連続領域に配置されているように、 RSPN— enter_to_current_Clipが選択されなければならない。

Bridge-Clipを使用しないでシームレス接続する場合のデ一夕アロケーションの制限について、図 95を参照して説明すると、シームレス接続は、ファイルシステムによってデ一夕の連続供給が保証されるように作られなければならない。これは、 Clipl (Clip AVストリームファイル）の最後の部分と Clip2 (Clip AV ストリームファイル）の最初の部分を、デ一夕アロケーション規定を満たすように配置することによって行われなければならない。

Clipl (Clip AVストリームファイル）の最後のストリーム部分が、ハーフフラグメント以上の連続領域に配置されていなければならない。 Clip2 (Clip A V ストリームファイル）の最初のストリーム部分が、ハーフフラグメント以上の連続領域に配置されていなければならない。

次に、 D VR— S T Dについて説明する。 DVR— S TDは、 DVR MPEG •2 トランスポートストリームの生成及び検証の際におけるデコード処理をモデル化するための概念モデルである。また、 DVR— S TDは、上述したシームレス接続された 2つの PI ay I temによって参照される A Vストリームの生成及び検証の際におけるデコード処理をモデル化するための概念モデルでもある。

D VR - S T Dモデルを図 96に示す。図 96に示したモデルには、 D VR M PEG— 2 トランスポートストリームプレーヤモデルが構成要素として含まれている。 n, TBn, MBn, EBn, TBsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Dsys, On及び P n (k) の表記方法は、 I SOZI E C 1 381 8— 1の T一 S TDに定義されているものと同じである。すなわち、次の通りである。 nは、エレメンタリ一ストリ一ムのィンデクス番号である。 TBnは、エレメン夕リーストリーム nのトランスポートバヅファである。

MBnは、エレメンタリーストリーム nの多重バッファである。ビデオストリームについてのみ存在する。 EBnは、エレメンタリーストリーム nのエレメンタリーストリ一ムバッファである。ビデオストリームについてのみ存在する。 TBsysは、復号中のプログラムのシステム情報のための入力バッファである。 Bsysは、復号中のプログラムのシステム情報のためのシステム夕一ゲヅトデコーダ内のメインバヅファである。 Rxnは、デ一夕が TBnから取り除かれる伝送レートである。 Rbxnは、 P E Sパケヅトペイロードが MBnから取り除かれる伝送レ一トである。ビデオストリームについてのみ存在する。

Rxsysは、デ一夕が TBsysから取り除かれる伝送レートである。 Dnは、エレメン夕リ一ストリーム nのデコーダである。 Dsysは、復号中のプログラムのシステム情報に関するデコーダである。 Onは、ビデオストリーム nの re-ordering bufferである。 Pn (k) は、エレメン夕リーストリーム nの k番目のプレゼンテーションュニヅトである。

DVR— S T Dのデコーディングプロセスについて説明する。単一の DVR M PEG— 2 トランスポートストリームを再生している間は、トランスポ一トパケヅトを TBI, TBn又は TBsysのバッファへ入力するタイミングは、ソ一スパケットの arrivaし time_stauipにより決定される。 TB1， MBl, EB1， TBn, Bn， TBsys及び Bsy sのバヅファリング動作の規定は、 I S 0/1 E C 138 18— 1に規定されている T— S TDと同じである。復号動作と表示動作の規定もまた、 I S 0/1 E C 138 1 8— 1に規定されている T一 STDと同じである。

シームレス接続された Playltemを再生している間のデコーディングプロセスについて説明する。ここでは、シームレス接続された Playltemによって参照される 2つの A Vストリームの再生について説明をすることにし、以後の説明では、上述した（例えば、図 88に示した） T S 1と T S 2の再生について説明する。 T S 1は、先行するストリームであり、 T S 2は、現在のストリームである。

図 97は、ある AVストリーム（T S 1) からそれにシームレスに接続された次の AVストリーム（T S 2) へと移るときのトランスポートパケヅトの入力，復号，表示のタイミングチヤ一トを示す。所定の A Vストリーム（T S 1 ) からそれにシームレスに接続された次の AVストリーム（T S 2) へと移る間には、 T S 2のァライバル夕ィムベースの時間軸（図 97において AT C 2で示される）は、 T S 1のァライバルタイムべ一スの時間軸（図 97において A T C 1で示される）と同じでない。

また、 T S 2のシステムタイムベースの時間軸（図 97において S T C 2で示される）は、 T S 1のシステムタイムペースの時間軸（図 97において S T C 1 で示される）と同じでない。ビデオの表示は、シームレスに連続していることが要求される。ォ一ディォのプレゼンテーションュニヅトの表示時間にはオーバーラヅプがあってもよい。

DVR—STD への入力タイミングについて説明する。時刻 T1までの時間、すなわち、 T S 1の最後のビデオパケヅトが DVR— S TDの TB 1に入力終了するまでは、 0 11ー3 0の781、 TBn又は TBsysのバッファへの入力夕ィミングは、 TS 1のソースパケヅトの arrivaし time_stampによって決定される。

T S 1の残りのパケヅトは、 TS_recoi>ding— rate (T S 1 ) のビヅトレートで D VR - S T Dの TBn又は TBsysのバヅファへ入力されなければならない。ここで、 TS_recording_rate (TS 1) は、 Cliplに対応する Cliplnfo () において定義される TS_recording rateの値である。 T S 1の最後のバイ卜がバッファへ入力する時刻は、時刻 T2である。したがって、時刻 T1から Τ2までの区間では、ソースパケヅトの arrival_time— stampfま無視される。

N 1を T S 1の最後のビデオパケヅトに続く T S 1のトランスポートパケヅトのパイト数とすると、時刻 T1乃至 T2までの時間 D T 1は、 N 1バイトが TS—rec ording.rate (T S 1 ) のビットレートで入力終了するために必要な時間であり、次式により算出される。

厶 T1=T2— T1 = N1 / TS— recording一 rate (T S 1 )

時刻 Tl乃至 T2までの間は、 RXnと RXsysの値は共に、 TS_i>ecording_rate (T S 1 ) の値に変化する。このルール以外のバッファリング動作は、 T— S TDと同じである。

T2の時刻において、 arrival time clock counterは、 T S 2の最初のソースパケヅトの arrivaし time_sta即の値にリセットされる。 DVR— STDの TBI, TBn 又は TBsysのバヅファへの入力夕ィミングは、 T S 2のソースパケヅトの arriva l_time_stampによって決定される。 RXnと RXsysは共に、 T一 S TDにおいて定義されている値に変化する。

付加的なオーディオバヅファリング及びシステムデータパヅファリングについて説明すると、オーディオデコーダとシステムデコーダは、時刻 T 1から T2までの区間の入力データを処理することができるように、 T一 S T Dで定義されるバヅファ量に加えて付加的なバッファ量（約 1秒分のデータ量）が必要である。ビデオのプレゼンテーションタイミングについて説明すると、ビデオプレゼンテーシヨンユニットの表示は、接続点を通して、ギヤヅプなしに連続でなければならない。ここで、 S T C 1は、 T S 1のシステム夕ィムベースの時間軸（図 9 7では S T C 1と図示されている）とし、 ST C 2は、 TS 2のシステム夕ィムベースの時間軸（図 97では ST C 2と図示されている。正確には、 S TC 2は、 T S 2の最初の P CRが T— S TDに入力した時刻から開始する。）とする。

STC 1と S T C 2の間のオフセヅトは、次のように決定される。 PTSlendは、 T S 1の最後のビデオプレゼンテーションュニヅトに対応する S T C 1上の P T Sであり、 PTS2startは、 T S 2の最初のビデオプレゼンテーションュニヅトに対応する S TC 2上の PTSであり、 Tppは、 T S 1の最後のビデオプレゼンテーシヨンュニヅ卜の表示期間とすると、 2つのシステムタイムベースの間のオフセヅト STC_deltaは、次式により算出される。

STC_delta = PTSlend + Τρρ一 PTS2start

オーディオのプレゼンテ一ションのタイミングについて説明すると、接続点において、オーディオプレゼンテ一シヨンュニ、ソトの表示夕ィミングのオーバ一ラヅプがあっても良く、それは 0乃至 2オーディオフレーム未満である（図 97に図示されている" audio overlap"を参照）。どちらのオーディオサンプルを選択するかということと、オーディオプレゼンテーションュニヅトの表示を接続点の後の補正されたタイムベースに再同期することは、プレーヤ側により設定されることである。

DVR— S TDのシステムタイムクロックについて説明すると、時刻 T 5において、 T S 1の最後のォ一ディオプレゼンテーシヨンユニットが表示される。システムタイムクロヅクは、時刻 T 2から T 5の間にオーバーラヅプしていてもよい。この区間では、 DVR— S TDは、システム夕ィムクロックを古いタイムべ一スの値（ST C 1 ) と新しいタイムペースの値（S TC 2) の間で切り替える。 S TC 2の値は、次式により算出される。

STC2 = STCl-STC_delta

バッファリングの連続性について説明する。 STCllvideo_endは、 T S 1の最後のビデオパケヅトの最後のバイトが DVR— S TDの TB 1へ到着するときのシステムタイムベース S T C 1上の S T Cの値である。 STC22video_startは、 T S 2の最初のビデオパケヅ卜の最初のバイトが DVR— S TDの TB 1へ到着するときのシステムタイムベース S T C 2上の S T Cの値である。 STC21video_endは、 STCllvideo_end の値をシステム夕ィムベース S T C 2上の値に換算した値である < STC21video— endは、次式により算出される。

STC21video_end = STCllvideo— end - STC— delta

D VR— S TDに従うために、次の 2つの条件を満たすことが要求される。先ず、 T S 2の最初のビデオパケットの TB 1への到着タイミングは、次に示す不等式を満たさなければならない。そして、次に示す不等式を満たさなければならない。 STC22video_start > STC21video— end + Δ Τ1

この不等式が満たされるように、 Cl ip 1及び、又は、 Cl ip 2の部分的なストリームを再エンコード及び、又は、再多重化する必要がある場合は、その必要に応じて行われる。

次に、 S T C 1と S T C 2を同じ時間軸上に換算したシステムタイムベースの時間軸上において、 T S 1からのビデオパケヅトの入力とそれに続く T S 2からのビデオパケットの入力は、ビデオバッファをオーバ一フロウ及びアンダーフロ —させてはならない。

このようなシンタクス、データ構造、規則に基づくことにより、記録媒体に記録されているデータの内容、再生情報等を適切に管理することができ、もって、ユーザが再生時に適切に記録媒体に記録されているデ一夕の内容を確認したり、所望のデ一夕を簡便に再生できるようにすることができる。

なお、本例は、多重化ストリームとして M P E G 2 トランスポートストリームを例にして説明しているが、これに限らず、 M P E G 2プログラムストリームや米国の D i r e c T Vサービス（商標）で使用されている DSSトランスポートスドリームについても適用することが可能である。

図 9 8は、 Info. dvrの作成又は更新の処理を説明するフローチヤ一トを示す。図 1の記録再生装置 1のプロツク図を参照しながら説明する。

ステヅプ S I 1で、ユーザがディスクに再生制限をかける場合、制御部 2 3はュ一ザイン夕フェースを通して、 P I Nを取得する。

ステップ S 1 2で、制御部 2 3は、ユーザイン夕フェースを通して、ディスク名又は/及びディスクを代表するサムネイルを取得する。

ステップ S 1 3で、制御部 2 3は、新規に記録された PlayListのファイル名を Tab 1 eOf PlayListヘストァする。

ステップ S 1 4で、制御部 2 3は、最後に再生した PlayListのファイル名を取得する。これは、 resume_PlayList一 nameへストアされる。

ステップ S 1 5で、制御部 2 3は、メーカの特別なアプリケーションのためのメーカプライベートデ一夕を取得する。これは、 MakersPtivateDataへストアされる。ステヅプ S I 6で、制御部 2 3は、最後に再生した PlayListの再生中断時刻を取得する。これは PlayListファイルの ayListMarkのレジュ一ムマーカ一ヘストァされる。

ステヅプ S 1 7で、制御部 2 3は、ュ一ザイン夕フェースを通して、ユーザに PlayListの再生制限をかけるかを確認する。制御部 2 3は、ユーザが再生制限をかけることを指示した PlayListの UIAppInfoPlayListの playback_controし flagをセットする。

ステップ S 1 8で、制御部 2 3は、 info . dvrをディスクに記録する.ように指示する。

ステップ S 1 9で、制御部 2 3は、変更された、又は新規に作られた PlayList ファイルをディスクに記録するように指示する。

図 9 9は、ディスクの記録内容をユーザインタフェースへ提示する処理を説明するフローチャートを示す。図 1の記録再生装置 1のプロヅク図を参照しながら説明する。

ステヅブ S 3 1で、制御部 2 3はディスクに記録されている info. dvr, Cl ip I nformation fi le, PlayList f i le及び Thumbnail f i leの情報を取得する。

ステヅブ S 3 2で、制御部 2 3は Volunie_protect一： flagがセヅトされている場合は、ユーザインタフェースを通して、 P I Nの入力をユーザに要求する。

ステップ S 3 3で、制御部 2 3はディスク名及びディスク内容を代表するサムネイルをュ一ザインタフェースを通して、 G U Iに提示する。

ステップ S 3 4で、制御部 2 3は、 TableOfPlayListにエントリされている順番に PlayListの名前を並べた PlayList—覧画面を、 G U Iに提示する。

ステップ S 3 5で、制御部 2 3は、リジュ一ム（Resume) できる PlayListがある場合は、それを G U Iに提示する。

ステヅプ S 3 6で、ユーザインタフェースを通して、ユーザが 1つの PlayList の'再生を指示する。

ステヅプ S 3 7で、制御部 2 3は、指示された PlayListの playback一 controし f lagがセットされている場合は、ユーザインタフェースを通して、 P I Nの入力をユーザに要求する。ステップ S 3 8で、制御部 2 3は、 PlayListの再生開始点を先頭時刻又は resu meマーカ一の時刻のどちらにするかをユーザに確認する。

ステップ S 3 9で、制御部 2 3は、指示された時刻から PlayListを再生する。このようにして、ディスクの記録内容をユーザイン夕フェースへ提示し、ユーザは再生したい 1つの PlayListを選択し、プレーヤは選択された PlayListを再生する。

図 1 0 0は、 TableOfPlayListに複数の PlayListがエントリされている場合、それら PlayListの再生順序を変更する処理を説明するフローチヤ一トである。図 1の記録再生装置 1のプロック図を参照しながら説明する。

ステップ S 5 1で、制御部 2 3はディスクに記録されている info. dvr， Cl ip I nformation fi le, PlayList fi le及び Thumbnai l f i leの情報を取得する。

ステップ S 5 2で、制御部 2 3は、 TableOfPlayListにエントリされている順番に PlayListの名前を並べた PlayList—覧画面を、 G U Iに提示する。

ステップ S 5 3で、ユーザがユーザインタフェースを通して、 PlayListの再生順序の変更を指示する。

ステヅプ S 5 4で、制御部 2 3は、上記の新しい順序に基づいて TableOfPlayL istを更新する。

ステップ S 5 5で、制御部 2 3は、 info. dvrをディスクに記録することを指示する。

このようにして、ディスクに複数の PlayListが記録されている場合に、それらのデフォルトの再生順序を TableOfPlayListに記録することができるようにすることにより、ユーザはこの再生順序を自由に設定できる。

このようなシンタクス、データ構造、規則に基づくことにより、記録媒体に記録されているデータの内容、再生情報等を適切に管理することができ、もって、ユーザが再生時に適切に記録媒体に記録されているデータの内容を確認したり、所望のデータを簡便に再生できるようにすることができる。すなわち、 Info. dvr を用いて、ユーザが所望の PlayListを選択する際の処理を簡便化することができる。

また、 Info. dvrのファイルを PlayListファイルや Cl ip Info mat ionファイルとは分離して記録することにより、 Info. dvrのファイルサイズを非常に小さくできる。そのため、 Info. dvrファイルの内容を変更して、それを記録するときに必要な時間を小さくできる。また、 11^0. ]の変更に関係のなぃ？1&71^81;ファィルゃ Cl ip Informationファイルを変更する必要がない。

もし、 Info. dvr, PlayList及び Cl ip Informationの内容を 1つのファイルにして記録すると、ファイルサイズは非常に大きくなる。そのために、そのファイルの内容を変更して、それを記録するためにかかる時間は、 Info. dvrだけを 1つのファイルで記録する場合に比べて、非常に大きくなる。

新規に PlayL istを記録する場合（図 9 8 ) やユーザが PlayListの再生順序を変更するという場合（図 1 0 0 ) 等において、 Info. dvrファイルが書きかえられる。 Info.dvrの書き換えは、 PlayListファイルや Cl ip Informationファイルに比べて、頻繁に行われるので、 Info . dvrを 1つのファイルにして管理することは、この書き換え時の処理時間の短縮に効果が大きい。

また、 Info. dvrは小さなファイルであるので、ディスクから読み出す時間も小さい。最初に Info. dvrだけを読み出して、その内容に基づいて、ディスクの記録内容をユーザイン夕フェースへ提示する場合（図 9 9 ) 、ユーザの待ち時間を小さくすることができる。

上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウヱァにより実行させる場合には、そのソフトウエアを構成するプログラムが専用のハードウヱァに組み込まれているコンピュータ、又は、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンビュ一夕等に、記録媒体からインストールされる。

この記録媒体は、図 1 0 1に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク 2 2 1 (フロヅピディスクを含む）、光ディスク 2 2 2 ( C D - R O M (Comp act Disk-Read Only Memory) , D V D (Digital Versati le Disk) を含む）、光磁気ディスク 2 2 3 (M D (Mini-Disk) を含む）、若しくは半導体メモリ 2 2 4 等よりなるパヅケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されている R O M 2 0 2や記憶部 2 0 8が含まれるハードディスク等で構成される。

なお、本明細書において、媒体により提供されるプログラムを記述するステヅプは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。産業上の利用可能性以上のごとく、本発明に係る情報処理装置及び方法、記録媒体、並びにプログラム、並びに第 2の情報処理装置及び方法、記録媒体、並びにプログラムによれば、管理情報が、再生指定情報に基づく再生が終了された時点で再生指定情報に付けられていた名称に関する名称情報を含み、再生指定情報が、再生指定情報に基づく再生が終了された時点の時間情報を含むようにすることができる。

本発明に係る情報処理装置及び方法、記録媒体、並びにプログラム、並びに第 4の情報処理装置及び方法、記録媒体、並びにプログラムによれば、管理情報が、管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、再生指定情報が、再生指定情報の閲覧の許可に関する閲覧許可情報を含むようすることができる。

本究明に係る情報処理装置及び方法、記録媒体、並びにプログラムによれば、管理情報が、管理情報が管理する全ての再生指定情報を再生順に登録する再生順序情報を含み、再生指定情報が、その再生区間の時間情報を含むようにすることができる。

したがって、いずれの場合においても、記録媒体に記録されているデータ内容、及び、再生情報を適切に管理することができる。

Claims

請求の範囲

1 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成手段と、

前記生成手段により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録手段とを有し、

前記管理情報は、前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含み、

前記再生指定情報は、前記再生指定情報に基づく再生が終了された時点の時間情報を含む情報処理装置。

2 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録ステツプとを含み、

前記再生指定情報は、前記再生指定情報に基づく再生が終了された時点の時間情報を含む情報処理方法。

3 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録ステツプとを含むプログラムにおいて、

前記管理情報は、前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に闋する名称情報を含み、

前記再生指定情報は、前記再生指定情報に基づく再生が終了された時点の時間情報を含むコンピュー夕が読み取り可能なプログラムが記録されている記録媒体 _c

4 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、前記生成ステップの処理により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録ステヅプとをコンピュータに実行させるプログラムにおいて、

前記再生指定情報は、前記再生指定情報に基づく再生が終了された時点の時間情報を含むプログラム。

5 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置において、

前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含む前記管理情報と、前記再生指定情報に基づく再生が終了された時点の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御手段を備える情報処理装置。

6 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置の情報再生方法において、

前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含む前記管理情報と、前記再生指定情報に基づく再生が終了された時点の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステップを含む情報処理方法。

7 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置のプログラムにおいて、

前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含む前記管理情報と、前記再生指定情報に基づく再生が終了された時点の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステップを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。

8 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置を制御するコンピュータに、

前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含む前記管理情報と、前記再生指定情報に基づく再生が終了された時点の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステップを実行させるプログラム。

9 . 主情報と、記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体において、前記管理情報は、前記再生指定情報に基づく再生が終了された時点で前記再生指定情報に付けられていた名称に関する名称情報を含み、

前記再生指定情報は、前記再生指定情報に基づく再生が終了された時点の時間情報を含む記録媒体。

1 0 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成手段と、

前記管理情報は、前記管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、

前記再生指定情報は、前記再生指定情報の閲覧の許可に関する閲覧許可情報を含む情報処理装置。

1 1 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記再生指定情報は、前記再生指定情報の閲覧の許可に関する閲覧許可情報を含む情報処理方法。

1 2 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録ステップとを含むプログラムにおいて、

前記再生指定情報は、前記再生指定情報の閲覧の許可に関する閲覧許可情報を含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。

1 3 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記再生指定情報と前記管理情報を前記記録媒体に記録する記録ステヅプとをコンピュータに実行させるプログラにおいて、

前記再生指定情報は、前記再生指定情報の閲覧の許可に関する閲覧許可情報を含むプログラム。

1 4 . 主情報と、記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体において、前記管理情報は、前記管理情報が管理する全ての再生指定情報についての閲覧の許可に関する閲覧許可情報を含み、

前記再生指定情報は、前記再生指定情報の閲覧の許可に関する閲覧許可情報を含む記録媒体。

1 5 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成手段と、

前記生成手段により生成された前記管理情報を前記記録媒体に記録する記録手段とを有し、

前記管理情報は、前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含み、前記再生指定情報は、その再生区間の時間情報を含む情報処理装置。

1 6 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記管理情報を前記記録媒体に記録する記録ステツプとを含み、

前記管理情報は、前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含み、

前記再生指定情報は、その再生区間の時間情報を含む情報処理方法。

1 7 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成スチップと、.

前記生成ステップの処理により生成された前記管理情報を前記記録媒体に記録する記録ステヅプとを含むプログラムにおいて、

前記再生指定情報は、その再生区間の時間情報を含むコンピュー夕が読み取り可能なプログラムが記録されている記録媒体。

1 8 . 記録媒体に記録されている情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報を生成する生成ステップと、

前記生成ステップの処理により生成された前記管理情報を前記記録媒体に記録する記録ステップとをコンピュータに実行させるプログラムにおいて、

前記再生指定情報は、その再生区間の時間情報を含むプログラム。

1 9 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置において、

前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含む前記管理情報と、再生区間の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御手段を備える情報処理装置。

2 0 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置の情報処理方法において、

前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含む前記管理情報と、再生区間の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステップを含む情報処理方法

2 1 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置のプログラムにおいて、

前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含む前記管理情報と、再生区間の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステツプを含むコンピュータが読み取り可能なプログラムが記録されている記録媒体。

2 2 . 記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体から、前記主情報を再生する情報処理装置を制御するコンピュータに、

前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含む前記管理情報と、再生区間の時間情報を含む前記再生指定情報に基づいて、前記記録媒体の主情報の再生を制御する制御ステップを実行させるプログラム。

2 3 . 主情報と、記録されている主情報の再生手順を指定する再生指定情報と、前記再生指定情報を管理する管理情報が記録されている記録媒体において、前記管理情報は、前記管理情報が管理する全ての前記再生指定情報を再生順に登録する再生順序情報を含み、

前記再生指定情報は、その再生区間の時間情報を含む記録媒体。