JP2002159004A - 符号化装置および方法、記録媒体、並びにプログラム - Google Patents
符号化装置および方法、記録媒体、並びにプログラムInfo
- Publication number
- JP2002159004A JP2002159004A JP2001112756A JP2001112756A JP2002159004A JP 2002159004 A JP2002159004 A JP 2002159004A JP 2001112756 A JP2001112756 A JP 2001112756A JP 2001112756 A JP2001112756 A JP 2001112756A JP 2002159004 A JP2002159004 A JP 2002159004A
- Authority
- JP
- Japan
- Prior art keywords
- stream
- time
- encoding
- video
- clip
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Television Signal Processing For Recording (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Abstract
望の情報の検索を、簡便に行えるようにする。 【解決手段】 ステップS20で、トランスポートスト
リームの多重化ビットレートTS_recording_rateおよび
ビデオ符号化の平均ビットレートが設定される。ステッ
プS21で、ビデオストリームを、あらかじめ設定した
所定の時間区間毎に所定の平均ビットレートが保証され
る様に、可変ビットレートでエンコードするようにビデ
オエンコーダが制御される。ステップS22で、トラン
スポートパケット化するエレメンタリストリームがない
場合にヌルパケットを発生しないようにマルチプレクサ
が制御される。ステップS23で、各トランスポートパ
ケットにアライバルタイムスタンプを付加して、ソース
パケット化するように、ソースパケッタイザ19が制御
される。
Description
法、記録媒体、並びにプログラムに関し、特に、記録媒
体に記録されているデータの内容の管理情報をファイル
化して記録する符号化装置および方法、記録媒体、並び
にプログラムに関する。
ディスク型の記録媒体として、各種の光ディスクが提案
されつつある。このような記録可能な光ディスクは、数
ギガバイトの大容量メディアとして提案されており、ビ
デオ信号等のAV(Audio Visual)信号を記録するメディア
としての期待が高い。この記録可能な光デイスクに記録
するデジタルのAV信号のソース(供給源)としては、CS
デジタル衛星放送やBSデジタル放送があり、また、将来
はデジタル方式の地上波テレビジョン放送等も提案され
ている。
ジタルビデオ信号は、通常MPEG(Moving Picture Exper
ts Group)2方式で画像圧縮されているのが一般的であ
る。また、記録装置には、その装置固有の記録レートが
定められている。従来の民生用映像蓄積メディアで、デ
ジタル放送由来のデジタルビデオ信号を記録する場合、
アナログ記録方式であれば、デジタルビデオ信号をデコ
ード後、帯域制限をして記録する。あるいは、MPEG1 V
ideo、MPEG2 Video、DV方式をはじめとするデジタル記
録方式であれば、1度デコードされた後に、その装置固
有の記録レート・符号化方式で再エンコードされて記録
される。
給されたビットストリームを1度デコードし、その後で
帯域制限や再エンコードを行って記録するため、画質の
劣化を伴う。画像圧縮されたデジタル信号の記録をする
場合、入力されたデジタル信号の伝送レートが記録再生
装置の記録レートを超えない場合には、供給されたビッ
トストリームをデコードや再エンコードすることなく、
そのまま記録する方法が最も画質の劣化が少ない。ただ
し、画像圧縮されたデジタル信号の伝送レートが記録媒
体としてのディスクの記録レートを超える場合には、記
録再生装置でデコード後、伝送レートがディスクの記録
レートの上限以下になるように、再エンコードをして記
録する必要はある。
時間により増減する可変レート方式によって伝送されて
いる場合には、回転ヘッドが固定回転数であるために記
録レートが固定レートになるテープ記録方式に比べ、1
度バッファにデータを蓄積し、バースト的に記録ができ
るディスク記録装置が記録媒体の容量をより無駄なく利
用できる。
将来においては、データストリーマのように放送信号を
デジタル信号のまま、デコードや再エンコードすること
なく記録し、記録媒体としてディスクを使用した記録再
生装置が求められると予測される。
媒体の容量が増大することにより、その記録媒体には、
多くのデータ(この場合、番組に関する映像や音声な
ど)が記録できるようになる。従って、1枚のディスク
に多くの番組が記録されることになり、ユーザが、それ
らのディスク内に記録されている多くの番組から視聴し
たい1番組を選択するといったような操作が煩雑になっ
てしまう。そこで、ユーザがディスクの再生時に、簡便
に記録されているデータを確認し、所望の番組(デー
タ)が選択できるようにする必要があるといった課題が
あった。
ものであり、記録媒体に記録されているデータの内容の
管理情報をファイル化して記録する事により、記録媒体
に記録されているデータ内容、および、再生情報を適切
に管理することができるようにすることを目的とする。
映像データを可変レートにより符号化する符号化器と、
時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御部とを有することを特徴とする。
化データ発生量が所定量に満たないときにはスタッフィ
ングバイトを符号化するよう制御することができる。
際に発生するデータ量に応じてスタッフィングバイトを
符号化するか否かを判定することができる。
フローしないようにスタッフィングバイトを符号化する
よう制御することができる。
ータ量がほぼ比例するように符号化する符号化モードと
通常の符号化モードのどちらか一方で符号化するように
制御することができる。
に対して符号化データ量がほぼ比例するように符号化す
るモードか否かを示す付加情報を生成することができ
る。
レートにより符号化する符号化ステップと、時間経過に
対して映像符号化データ量がほぼ比例するように制御す
る制御ステップとを含むことを特徴とする。
ータを可変レートにより符号化する符号化ステップと、
時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御ステップとを含むことを特徴とする。
レートにより符号化する符号化ステップと、時間経過に
対して映像符号化データ量がほぼ比例するように制御す
る制御ステップとを実行させる。
体、並びにプログラムにおいては、映像データが可変レ
ートによって符号化され、時間経過に対して映像符号化
データ量がほぼ比例するように制御される。
データに対応するオーディオデータを含むAVストリーム
ファイルと、AVストリームファイルの記録モードを示す
フラグとが記録されていることを特徴とする。
ることができる。
対してファイルサイズが比例するようにして記録される
モードであることを示すようにすることができる。
と、映像データに対応するオーディオデータを含むAVス
トリームファイルと、AVストリームファイルの記録モー
ドを示すフラグとが記録されている。
いて、図面を参照して説明する。図1は、本発明を適用
した記録再生装置1の内部構成例を示す図である。ま
ず、外部から入力された信号を記録媒体に記録する動作
を行う部分の構成について説明する。記録再生装置1
は、アナログデータ、または、デジタルデータを入力
し、記録することができる構成とされている。
端子12には、アナログのオーディオ信号が、それぞれ
入力される。端子11に入力されたビデオ信号は、解析
部14とAVエンコーダ15に、それぞれ出力される。端
子12に入力されたオーディオ信号は、AVエンコーダ1
5に出力される。解析部14は、入力されたビデオ信号
からシーンチェンジなどの特徴点を抽出する。
号とオーディオ信号を、それぞれ符号化し、符号化ビデ
オストリーム(V)、符号化オーディオストリーム(A)、お
よびAV同期等のシステム情報(S)をマルチプレクサ16
に出力する。
(Moving Picture Expert Group)2方式により符号化
されたビデオストリームであり、符号化オーディオスト
リームは、例えば、MPEG1方式により符号化されたオー
ディオストリームや、ドルビーAC3方式により符号化さ
れたオーディオストリーム等である。マルチプレクサ1
6は、入力されたビデオおよびオーディオのストリーム
を、入力システム情報に基づいて多重化して、スイッチ
17を介して多重化ストリーム解析部18とソースパケ
ッタイザ19に出力する。
ンスポートストリームやMPEG2プログラムストリームで
ある。ソースパケッタイザ19は、入力された多重化ス
トリームを、そのストリームを記録させる記録媒体10
0のアプリケーションフォーマットに従って、ソースパ
ケットから構成されるAVストリームを符号化する。AVス
トリームは、ECC(誤り訂正)符号化部20、変調部2
1で所定の処理が施され、書き込み部22に出力され
る。書き込み部22は、制御部23から出力される制御
信号に基づいて、記録媒体100にAVストリームファイ
ルを書き込む(記録する)。
レビジョンチューナから入力されるデジタルテレビジョ
ン放送等のトランスポートストリームは、端子13に入
力される。端子13に入力されたトランスポートストリ
ームの記録方式には、2通りあり、それらは、トランス
ペアレントに記録する方式と、記録ビットレートを下げ
るなどの目的のために再エンコードをした後に記録する
方式である。記録方式の指示情報は、ユーザインタフェ
ースとしての端子24から制御部23へ入力される。
ペアレントに記録する場合、端子13に入力されたトラ
ンスポートストリームは、多重化ストリーム解析部18
と、ソースパケッタイザ19に出力される。これ以降の
記録媒体100へAVストリームが記録されるまでの処理
は、上述の入力オーディオ浸透とビデオ信号を符号化し
て記録する場合と同一の処理なので、その説明は省略す
る。
ードした後に記録する場合、端子13に入力されたトラ
ンスポートストリームは、デマルチプレクサ26に入力
される。デマルチプレクサ26は、入力されたトランス
ポートストリームに対してデマルチプレクス処理を施
し、ビデオストリーム(V)、オーディオストリーム(A)、
およびシステム情報(S)を抽出する。
トリーム(情報)のうち、ビデオストリームはAVデコー
ダ27に、オーディオストリームとシステム情報はマル
チプレクサ16に、それぞれ出力される。AVデコーダ2
7は、入力されたビデオストリームを復号し、その再生
ビデオ信号をAVエンコーダ15に出力する。AVエンコー
ダ15は、入力ビデオ信号を符号化し、符号化ビデオス
トリーム(V)をマルチプレクサ16に出力する。
れ、マルチプレクサ16に入力されたオーディオストリ
ームとシステム情報、および、AVエンコーダ15から出
力されたビデオストリームは、入力システム情報に基づ
いて、多重化されて、多重化ストリームとして多重化ス
トリーム解析部18とソースパケットタイザ19にスイ
ッチ17を介して出力される。これ以後の記録媒体10
0へAVストリームが記録されるまでの処理は、上述の入
力オーディオ信号とビデオ信号を符号化して記録する場
合と同一の処理なので、その説明は省略する。
リームのファイルを記録媒体100に記録すると共に、
そのファイルを説明するアプリケーションデータベース
情報も記録する。アプリケーションデータベース情報
は、制御部23により作成される。制御部23への入力
情報は、解析部14からの動画像の特徴情報、多重化ス
トリーム解析部18からのAVストリームの特徴情報、お
よび端子24から入力されるユーザからの指示情報であ
る。
報は、入力動画像信号の中の特徴的な画像に関係する情
報であり、例えば、プログラムの開始点、シーンチェン
ジ点、コマーシャル(CM)の開始・終了点などの指定
情報(マーク)であり、また、その指定場所の画像のサ
ムネイル画像の情報も含まれる。
リームの特徴情報は、記録されるAVストリームの符号化
情報に関係する情報であり、例えば、AVストリーム内の
Iピクチャのアドレス情報、AVストリームの符号化パラ
メータ、AVストリームの中の符号化パラメータの変化点
情報、ビデオストリームの中の特徴的な画像に関係する
情報(マーク)などである。
トリームの中の、ユーザが指定した再生区間の指定情
報、その再生区間の内容を説明するキャラクター文字、
ユーザが好みのシーンにセットするブックマークやリジ
ューム点の情報などである。
て、AVストリームのデータベース(Clip)、 AVストリー
ムの再生区間(PlayItem)をグループ化したもの(PlayLi
st)のデータベース、記録媒体100の記録内容の管理
情報(info.dvr)、およびサムネイル画像の情報を作成す
る。これらの情報から構成されるアプリケーションデー
タベース情報は、AVストリームと同様にして、ECC符号
化部20、変調部21で処理されて、書き込み部22へ
入力される。書き込み部22は、制御部23から出力さ
れる制御信号に基づいて、記録媒体100へデータベー
スファイルを記録する。
報についての詳細は後述する。
たAVストリームファイル(画像データと音声データのフ
ァイル)と、アプリケーションデータベース情報が再生
される場合、まず、制御部23は、読み出し部28に対
して、記録媒体100からアプリケーションデータベー
ス情報を読み出すように指示する。そして、読み出し部
28は、記録媒体100からアプリケーションデータベ
ース情報を読み出し、そのアプリケーションデータベー
ス情報は、復調部29、ECC復号部30の処理を経て、
制御部23へ入力される。
ース情報に基づいて、記録媒体100に記録されている
PlayListの一覧を端子24のユーザインタフェースへ出
力する。ユーザは、PlayListの一覧から再生したいPlay
Listを選択し、再生を指定されたPlayListに関する情報
が制御部23へ入力される。制御部23は、そのPlayLi
stの再生に必要なAVストリームファイルの読み出しを、
読み出し部28に指示する。読み出し部28は、その指
示に従い、記録媒体100から対応するAVストリームを
読み出し復調部29に出力する。復調部29に入力され
たAVストリームは、所定の処理が施されることにより復
調され、さらにECC復号部30の処理を経て、ソースデ
パケッタイザ31出力される。
00から読み出され、所定の処理が施されたアプリケー
ションフォーマットのAVストリームを、デマルチプレク
サ26に出力できるストリームに変換する。デマルチプ
レクサ26は、制御部23により指定されたAVストリー
ムの再生区間(PlayItem)を構成するビデオストリーム
(V)、オーディオストリーム(A)、およびAV同期等のシス
テム情報(S)を、AVデコーダ27に出力する。AVデコー
ダ27は、ビデオストリームとオーディオストリームを
復号し、再生ビデオ信号と再生オーディオ信号を、それ
ぞれ対応する端子32と端子33から出力する。
24から、ランダムアクセス再生や特殊再生を指示する
情報が入力された場合、制御部23は、AVストリームの
データベース(Clip)の内容に基づいて、記憶媒体100
からのAVストリームの読み出し位置を決定し、そのAVス
トリームの読み出しを、読み出し部28に指示する。例
えば、ユーザにより選択されたPlayListを、所定の時刻
から再生する場合、制御部23は、指定された時刻に最
も近いタイムスタンプを持つIピクチャからのデータを
読み出すように読み出し部28に指示する。
ard playback)が指示された場合、制御部23は、AVス
トリームのデータベース(Clip)に基づいて、AVストリー
ムの中のI-ピクチャデータを順次連続して読み出すよう
に読み出し部28に指示する。
クセスポイントからAVストリームのデータを読み出し、
読み出されたデータは、後段の各部の処理を経て再生さ
れる。
れているAVストリームの編集をする場合を説明する。ユ
ーザが、記録媒体100に記録されているAVストリーム
の再生区間を指定して新しい再生経路を作成したい場
合、例えば、番組Aという歌番組から歌手Aの部分を再
生し、その後続けて、番組Bという歌番組の歌手Aの部
分を再生したいといった再生経路を作成したい場合、ユ
ーザインタフェースとしての端子24から再生区間の開
始点(イン点)と終了点(アウト点)の情報が制御部2
3に入力される。制御部23は、AVストリームの再生区
間(PlayItem)をグループ化したもの(PlayList)のデー
タベースを作成する。
るAVストリームの一部を消去したい場合、ユーザインタ
フェースとしての端子24から消去区間のイン点とアウ
ト点の情報が制御部23に入力される。制御部23は、
必要なAVストリーム部分だけを参照するようにPlayList
のデータベースを変更する。また、AVストリームの不必
要なストリーム部分を消去するように、書き込み部22
に指示する。
るAVストリームの再生区間を指定して新しい再生経路を
作成したい場合であり、かつ、それぞれの再生区間をシ
ームレスに接続したい場合について説明する。このよう
な場合、制御部23は、AVストリームの再生区間(PlayI
tem)をグループ化したもの(PlayList)のデータベース
を作成し、さらに、再生区間の接続点付近のビデオスト
リームの部分的な再エンコードと再多重化を行う。
クチャの情報と、アウト点のピクチャの情報が制御部2
3へ入力される。制御部23は、読み出し部28にイン
点側ピクチャとアウト点側のピクチャを再生するために
必要なデータの読み出しを指示する。そして、読み出し
部28は、記録媒体100からデータを読み出し、その
データは、復調部29、ECC復号部30、ソースデパケ
ッタイザ31を経て、デマルチプレクサ26に出力され
る。
力されたデータを解析して、ビデオストリームの再エン
コード方法(picture_coding_typeの変更、再エンコー
ドする符号化ビット量の割り当て)と、再多重化方式を
決定し、その方式をAVエンコーダ15とマルチプレクサ
16に供給する。
たストリームをビデオストリーム(V)、オーディオスト
リーム(A)、およびシステム情報(S)に分離する。ビデオ
ストリームは、「AVデコーダ27に入力されるデータ」
と「マルチプレクサ16に入力されるデータ」がある。
前者のデータは、再エンコードするために必要なデータ
であり、これはAVデコーダ27で復号され、復号された
ピクチャはAVエンコーダ15で再エンコードされて、ビ
デオストリームにされる。後者のデータは、再エンコー
ドをしないで、オリジナルのストリームからコピーされ
るデータである。オーディオストリーム、システム情報
については、直接、マルチプレクサ16に入力される。
力された情報に基づいて、入力ストリームを多重化し、
多重化ストリームを出力する。多重化ストリームは、EC
C符号化部20、変調部21で処理されて、書き込み部
22に入力される。書き込み部22は、制御部23から
供給される制御信号に基づいて、記録媒体100にAVス
トリームを記録する。
報や、その情報に基づく再生、編集といった操作に関す
る説明をする。図2は、アプリケーションフォーマット
の構造を説明する図である。アプリケーションフォーマ
ットは、AVストリームの管理のためにPlayListとClipの
2つのレイヤをもつ。Volume Informationは、ディスク
内のすべてのClipとPlayListの管理をする。ここでは、
1つのAVストリームとその付属情報のペアを1つのオブ
ジェクトと考え、それをClipと称する。AVストリームフ
ァイルはClip AV stream fileと称し、その付属情報
は、Clip Information fileと称する。
ンスポートストリームをアプリケーションフォーマット
によって規定される構造に配置したデータをストアす
る。一般的に、ファイルは、バイト列として扱われる
が、Clip AV stream fileのコンテンツは、時間軸上に
展開され、Clipの中のエントリーポイントは、主に時間
ベースで指定される。所定のClipへのアクセスポイント
のタイムスタンプが与えられた時、Clip Information f
ileは、Clip AV stream fileの中でデータの読み出しを
開始すべきアドレス情報を見つけるために役立つ。
る。PlayListは、Clipの中からユーザが見たい再生区間
を選択し、それを簡単に編集することができるようにす
るために設けられている。1つのPlayListは、Clipの中
の再生区間の集まりである。所定のClipの中の1つの再
生区間は、PlayItemと呼ばれ、それは、時間軸上のイン
点(IN)とアウト点(OUT)の対で表される。従って、P
layListは、複数のPlayItemが集まることにより構成さ
れる。
は、Real PlayListであり、もう1つは、Virtual PlayL
istである。Real PlayListは、それが参照しているClip
のストリーム部分を共有している。すなわち、Real Pla
yListは、それの参照しているClipのストリーム部分に
相当するデータ容量をディスクの中で占め、Real PlayL
istが消去された場合、それが参照しているClipのスト
リーム部分もまたデータが消去される。
していない。従って、Virtual PlayListが変更または消
去されたとしても、Clipの内容には何も変化が生じな
い。
する。図4(A)は、Real PlayListのクリエイト(crea
te:作成)に関する図であり、AVストリームが新しいCli
pとして記録される場合、そのClip全体を参照するReal
PlayListが新たに作成される操作である。
ド(divide:分割)に関する図であり、Real PlayListが
所望な点で分けられて、2つのReal PlayListに分割さ
れる操作である。この分割という操作は、例えば、1つ
のPlayListにより管理される1つのクリップ内に、2つ
の番組が管理されているような場合に、ユーザが1つ1
つの番組として登録(記録)し直したいといったような
ときに行われる。この操作により、Clipの内容が変更さ
れる(Clip自体が分割される)ことはない。
ン(combine:結合)に関する図であり、2つのReal Play
Listを結合して、1つの新しいReal PlayListにする操
作である。この結合という操作は、例えば、ユーザが2
つの番組を1つの番組として登録し直したいといったよ
うなときに行われる。この操作により、Clipが変更され
る(Clip自体が1つにされる)ことはない。
ート(delete:削除)に関する図であり、所定のReal Pla
yList全体を消去する操作がされた場合、削除されたRea
l PlayListが参照するClipの、対応するストリーム部分
も削除される。
削除に関する図であり、Real PlayListの所望な部分が
削除された場合、対応するPlayItemが、必要なClipのス
トリーム部分だけを参照するように変更される。そし
て、Clipの対応するストリーム部分は削除される。
ズ(Minimize:最小化)に関する図であり、Real PlayLis
tに対応するPlayItemを、Virtual PlayListに必要なCli
pのストリーム部分だけを参照するようにする操作であ
る。Virtual PlayList にとって不必要なClipの、対応
するストリーム部分は削除される。
tが変更されて、そのReal PlayListが参照するClipのス
トリーム部分が削除された場合、その削除されたClipを
使用しているVirtual PlayListが存在し、そのVirtual
PlayListにおいて、削除されたClipにより問題が生じる
可能性がある。
に、削除という操作に対して、「そのReal PlayListが
参照しているClipのストリーム部分を参照しているVirt
ual PlayListが存在し、もし、そのReal PlayListが消
去されると、そのVirtual PlayListもまた消去されるこ
とになるが、それでも良いか?」といったメッセージな
どを表示させることにより、確認(警告)を促した後
に、ユーザの指示により削除の処理を実行、または、キ
ャンセルする。または、Virtual PlayListを削除する代
わりに、Real PlayListに対してミニマイズの操作が行
われるようにする。
て説明する。Virtual PlayListに対して操作が行われた
としても、Clipの内容が変更されることはない。図6
は、アセンブル(Assemble) 編集 (IN-OUT 編集)に関す
る図であり、ユーザが見たいと所望した再生区間のPlay
Itemを作り、Virtual PlayListを作成するといった操作
である。PlayItem間のシームレス接続が、アプリケーシ
ョンフォーマットによりサポートされている(後述)。
layList1,2と、それぞれのRealPlayListに対応するC
lip1,2が存在している場合に、ユーザがReal PlayLi
st1内の所定の区間(In1乃至Out1までの区間:PlayI
tem1)を再生区間として指示し、続けて再生する区間
として、Real PlayList2内の所定の区間(In2乃至Out
2までの区間:PlayItem2)を再生区間として指示した
とき、図6(B)に示すように、PlayItem1とPlayItem
2から構成される1つのVirtual PlayListが作成され
る。
ting)について説明する。再編集には、Virtual PlayLis
tの中のイン点やアウト点の変更、Virtual PlayListへ
の新しいPlayItemの挿入(insert)や追加(append)、Virt
ual PlayListの中のPlayItemの削除などがある。また、
Virtual PlayListそのものを削除することもできる。
のアフレコ(Audio dubbing (post recording))に関する
図であり、Virtual PlayListへのオーディオのアフレコ
をサブパスとして登録する操作のことである。このオー
ディオのアフレコは、アプリケーションフォーマットに
よりサポートされている。Virtual PlayListのメインパ
スのAVストリームに、付加的なオーディオストリーム
が、サブパスとして付加される。
の操作として、図8に示すようなPlayListの再生順序の
変更(Moving)がある。この操作は、ディスク(ボリュー
ム)の中でのPlayListの再生順序の変更であり、アプリ
ケーションフォーマットにおいて定義されるTable Of P
layList(図20などを参照して後述する)によってサ
ポートされる。この操作により、Clipの内容が変更され
るようなことはない。
マークは、ClipおよびPlayListの中のハイライトや特徴
的な時間を指定するために設けられている。Clipに付加
されるマークは、AVストリームの内容に起因する特徴的
なシーンを指定する、例えば、シーンチェンジ点などで
ある。PlayListを再生する時、そのPlayListが参照する
Clipのマークを参照して、使用する事ができる。
ザによってセットされる、例えば、ブックマークやリジ
ューム点などである。ClipまたはPlayListにマークをセ
ットすることは、マークの時刻を示すタイムスタンプを
マークリストに追加することにより行われる。また、マ
ークを削除することは、マークリストの中から、そのマ
ークのタイムスタンプを除去する事である。従って、マ
ークの設定や削除により、AVストリームは何の変更もさ
れない。
イルは、Volume、PlayList、およびClipに付加される静
止画である。サムネイルには、2つの種類があり、1つ
は、内容を表す代表画としてのサムネイルである。これ
は主としてユーザがカーソル(不図示)などを操作して
見たいものを選択するためのメニュー画面で使われるも
のである。もう1つは、マークが指しているシーンを表
す画像である。
できるようにする必要がある。Volumeの代表画は、ディ
スク(記録媒体100、以下、記録媒体100はディス
ク状のものであるとし、適宜、ディスクと記述する)を
記録再生装置1の所定の場所にセットした時に、そのデ
ィスクの内容を表す静止画を最初に表示する場合などに
用いられることを想定している。Playlistの代表画は、
Playlistを選択するメニュー画面において、Playlistの
内容を表すための静止画として用いられることを想定し
ている。
の画像をサムネイル(代表画)にすることが考えられる
が、必ずしも再生時刻0の先頭の画像が内容を表す上で
最適な画像とは限らない。そこで、Playlistのサムネイ
ルとして、任意の画像をユーザが設定できるようにす
る。以上2種類のサムネイルをメニューサムネイルと称
する。メニューサムネイルは頻繁に表示されるため、デ
ィスクから高速に読み出される必要がある。このため、
すべてのメニューサムネイルを1つのファイルに格納す
ることが効率的である。メニューサムネイルは、必ずし
もボリューム内の動画から抜き出したピクチャである必
要はなく、図10に示すように、パーソナルコンピュー
タやデジタルスチルカメラから取り込こまれた画像でも
よい。
クを打てる必要があり、マーク位置の内容を知るために
マーク点の画像を容易に見ることが出来るようにする必
要がある。このようなマーク点を表すピクチャをマーク
サムネイル(Mark Thumbnails)と称する。従って、サ
ムネイルの元となる画像は、外部から取り込んだ画像よ
りも、マーク点の画像を抜き出したものが主となる。
と、そのマークサムネイルの関係について示す図であ
り、図12は、Clipに付けられるマークと、そのマーク
サムネイルの関係について示す図である。マークサムネ
イルは、メニューサムネイルと異なり、Playlistの詳細
を表す時に、サブメニュー等で使われるため、短いアク
セス時間で読み出されるようなことは要求されない。そ
のため、サムネイルが必要になる度に、記録再生装置1
がファイルを開き、そのファイルの一部を読み出すこと
で多少時間がかかっても、問題にはならない。
を減らすために、すべてのマークサムネイルは1つのフ
ァイルに格納するのがよい。Playlistはメニューサムネ
イル1つと複数のマークサムネイルを有することができ
るが、Clipは直接ユーザが選択する必要性がない(通
常、Playlist経由で指定する)ため、メニューサムネイ
ルを設ける必要はない。
メニューサムネイル、マークサムネイル、PlayList、お
よびClipの関係について示した図である。メニューサム
ネイルファイルには、PlayList毎に設けられたメニュー
サムネイルがファイルされている。メニューサムネイル
ファイルには、ディスクに記録されているデータの内容
を代表するボリュームサムネイルが含まれている。マー
クサムネイルファイルは、各PlayList毎と各Clip毎に作
成されたサムネイルがファイルされている。
ation)について説明する。CPIは、Clipインフォメーシ
ョンファイルに含まれるデータであり、主に、それはCl
ipへのアクセスポイントのタイムスタンプが与えられた
時、Clip AV stream fileの中でデータの読み出しを開
始すべきデータアドレスを見つけるために用いられる。
本実施の形態では、2種類のCPIを用いる。1つは、EP_
mapであり、もう一つは、TU_mapである。
のリストであり、それはエレメンタリストリームおよび
トランスポートストリームから抽出されたものである。
これは、AVストリームの中でデコードを開始すべきエン
トリーポイントの場所を見つけるためのアドレス情報を
持つ。1つのEPデータは、プレゼンテーションタイムス
タンプ(PTS)と、そのPTSに対応するアクセスユニット
のAVストリームの中のデータアドレスの対で構成され
る。
れる。第1に、PlayListの中でプレゼンテーションタイ
ムスタンプによって参照されるアクセスユニットのAVス
トリームの中のデータアドレスを見つけるために使用さ
れる。第2に、ファーストフォワード再生やファースト
リバース再生のために使用される。記録再生装置1が、
入力AVストリームを記録する場合、そのストリームのシ
ンタクスを解析することができるとき、EP_mapが作成さ
れ、ディスクに記録される。
て入力されるトランスポートパケットの到着時刻に基づ
いたタイムユニット(TU)データのリストを持つ。これ
は、到着時刻ベースの時間とAVストリームの中のデータ
アドレスとの関係を与える。記録再生装置1が、入力AV
ストリームを記録する場合、そのストリームのシンタク
スを解析することができないとき、TU_mapが作成され、
ディスクに記録される。
トリームフォーマット(SESF)を定義する。SESFは、ア
ナログ入力信号を符号化する目的、およびデジタル入力
信号(例えばDV)をデコードしてからMPEG2トランスポ
ートストリームに符号化する場合に用いられる。
およびAVストリームについてのエレメンタリストリーム
の符号化制限を定義する。記録再生装置1が、SESFスト
リームをエンコードし、記録する場合、EP_mapが作成さ
れ、ディスクに記録される。
式のうちのいずれかが用いられて記録媒体100に記録
される。まず、デジタル放送のストリームをSESFストリ
ームにトランスコーディングする。この場合、記録され
たストリームは、SESFに準拠しなければならない。この
場合、EP_mapが作成されて、ディスクに記録されなけれ
ばならない。
するエレメンタリストリームを新しいエレメンタリスト
リームにトランスコーディングし、そのデジタル放送ス
トリームの規格化組織が定めるストリームフォーマット
に準拠した新しいトランスポートストリームに再多重化
する。この場合、EP_mapが作成されて、ディスクに記録
されなければならない。
ジタルBS放送の規格名称)準拠のMPEG-2トランスポート
ストリームであり、それがHDTVビデオストリームとMPEG
AACオーディオストリームを含むとする。HDTVビデオス
トリームをSDTVビデオストリームにトランスコーディン
グし、そのSDTVビデオストリームとオリジナルのAACオ
ーディオストリームをTSに再多重化する。SDTVストリー
ムと記録されるトランスポートストリームは、共にISDB
フォーマットに準拠しなければならない。
00に記録される際の他の方式として、入力トランスポ
ートストリームをトランスペアレントに記録する(入力
トランスポートストリームを何も変更しないで記録す
る)場合であり、その時にEP_mapが作成されてディスク
に記録される。
トランスペアレントに記録する(入力トランスポートス
トリームを何も変更しないで記録する)場合であり、そ
の時にTU_mapが作成されてディスクに記録される。
する。以下、記録再生装置1をDVR(Digital Video Rec
ording)と適宜記述する。図14はディスク上のディレ
クトリ構造の一例を示す図である。DVRのディスク上に
必要なディレクトリは、図14に示したように、"DVR"
ディレクトリを含むrootディレクトリ、"PLAYLIST"ディ
レクトリ、"CLIPINF"ディレクトリ、"M2TS"ディレクト
リ、および"DATA"ディレクトリを含む"DVR"ディレクト
リである。rootディレクトリの下に、これら以外のディ
レクトリを作成されるようにしても良いが、それらは、
本実施の形態のアプリケーションフォーマットでは、無
視されるとする。
ケーションフォーマットによって規定される全てのファ
イルとディレクトリがストアされる。"DVR"ディレクト
リは、4個のディレクトリを含む。"PLAYLIST"ディレク
トリの下には、Real PlayListとVirtual PlayListのデ
ータベースファイルが置かれる。このディレクトリは、
PlayListが1つもなくても存在する。
データベースが置かれる。このディレクトリも、Clipが
1つもなくても存在する。"M2TS"ディレクトリの下に
は、AVストリームファイルが置かれる。このディレクト
リは、AVストリームファイルが1つもなくても存在す
る。"DATA"ディレクトリは、デジタルTV放送などのデー
タ放送のファイルがストアされる。
をストアする。"info.dvr"ファイルは、 DVRディレクト
リの下に作られ、アプリケーションレイヤの全体的な情
報をストアする。DVRディレクトリの下には、ただ一つ
のinfo.dvrがなければならない。ファイル名は、info.d
vrに固定されるとする。"menu.thmb"ファイルは、メニ
ューサムネイル画像に関連する情報をストアする。DVR
ディレクトリの下には、ゼロまたは1つのメニューサム
ネイルがなければならない。ファイル名は、memu.thmb
に固定されるとする。メニューサムネイル画像が1つも
ない場合、このファイルは、存在しなくても良い。
ル画像に関連する情報をストアする。DVRディレクトリ
の下には、ゼロまたは1つのマークサムネイルがなけれ
ばならない。ファイル名は、mark.thmbに固定されると
する。メニューサムネイル画像が1つもない場合、この
ファイルは、存在しなくても良い。
Listファイルをストアするものであり、それらは、Real
PlayListとVirtual PlayListである。”xxxxx.rpls"
ファイルは、1つのReal PlayListに関連する情報をス
トアする。それぞれのReal PlayList毎に、1つのファ
イルが作られる。ファイル名は、"xxxxx.rpls"である。
ここで、"xxxxx"は、5個の0乃至9まで数字である。
ファイル拡張子は、"rpls"でなければならないとする。
PlayListに関連する情報をストアする。それぞれのVirt
ual PlayList毎に、1つのファイルが作られる。ファイ
ル名は、"yyyyy.vpls"である。ここで、"yyyyy"は、5
個の0乃至9まで数字である。ファイル拡張子は、"vpl
s"でなければならないとする。
ストリームファイルに対応して、1つのファイルをスト
アする。"zzzzz.clpi" ファイルは、1つのAVストリー
ムファイル(Clip AV stream file または Bridge-Clip
AV stream file)に対応するClip Information fileであ
る。ファイル名は、"zzzzz.clpi"であり、"zzzzz"は、
5個の0乃至9までの数字である。ファイル拡張子
は、"clpi"でなければならないとする。
ァイルをストアする。"zzzzz.m2ts"ファイルは、DVRシ
ステムにより扱われるAVストリームファイルである。こ
れは、Clip AV stream fileまたはBridge-Clip AV stre
amである。ファイル名は、"zzzzz.m2ts"であり、"zzzz
z"は、5個の0乃至9までの数字である。ファイル拡張
子は、"m2ts"でなければならないとする。
伝送されるデータをストアするものであり、データと
は、例えば、XML fileやMHEGファイルなどである。
タクスとセマンティクスを説明する。まず、”info.dv
r”ファイルについて説明する。図15は、”info.dv
r”ファイルのシンタクスを示す図である。”info.dv
r”ファイルは、3個のオブジェクトから構成され、そ
れらは、DVRVolume()、TableOfPlayLists()、およびMak
erPrivateData()である。
いて説明するに、TableOfPlayLists_Start_addressは、
info.dvrファイルの先頭のバイトからの相対バイト数を
単位として、TableOfPlayList()の先頭アドレスを示
す。相対バイト数はゼロからカウントされる。
o.dvrファイルの先頭のバイトからの相対バイト数を単
位として、MakerPrivateData()の先頭アドレスを示す。
相対バイト数はゼロからカウントされる。padding_word
(パディングワード)は、info.dvrのシンタクスに従っ
て挿入される。N1とN2は、ゼロまたは任意の正の整
数である。それぞれのパディングワードは、任意の値を
取るようにしても良い。
の内容を記述する情報をストアする。図16は、DVRVol
ume()のシンタクスを示す図である。図16に示したDVR
Volume()のシンタクスを説明するに、version_number
は、このDVRVolume()のバージョンナンバーを示す4個
のキャラクター文字を示す。version_numberは、ISO 64
6に従って、"0045"と符号化される。
らDVRVolume()の最後までのDVRVolume()のバイト数を示
す32ビットの符号なし整数で表される。
に再生したReal PlayListまたはVirtual PlayListのフ
ァイル名を記憶している。ただし、Real PlayListまた
はVirtual PlayListの再生をユーザが中断した時の再生
位置は、PlayListMark()において定義されるresume-mar
kにストアされる。
示す図である。図17に示したResumeVolume()のシンタ
クスを説明するに、valid_flagは、この1ビットのフラ
グが1にセットされている場合、resume_PlayList_name
フィールドが有効であることを示し、このフラグが0に
セットされている場合、resume_PlayList_nameフィール
ドが無効であることを示す。
ールドは、リジュームされるべきReal PlayListまたはV
irtual PlayListのファイル名を示す。
のなかの、UIAppInfoVolume は、ボリュームについての
ユーザインタフェースアプリケーションのパラメータを
ストアする。図18は、UIAppInfoVolumeのシンタクス
を示す図であり、そのセマンティクスを説明するに、ch
aracter_setの8ビットのフィールドは、Volume_nameフ
ィールドに符号化されているキャラクター文字の符号化
方法を示す。その符号化方法は、図19に示される値に
対応する。
me_nameフィールドの中に示されるボリューム名のバイ
ト長を示す。Volume_nameのフィールドは、ボリューム
の名称を示す。このフィールドの中の左からname_lengt
h数のバイト数が、有効なキャラクター文字であり、そ
れはボリュームの名称を示す。Volume_nameフィールド
の中で、それら有効なキャラクター文字の後の値は、ど
んな値が入っていても良い。
のコンテンツを、ユーザに制限することなしに見せてよ
いかどうかを示すフラグである。このフラグが1にセッ
トされている場合、ユーザが正しくPIN番号(パスワー
ド)を入力できたときだけ、そのボリュームのコンテン
ツを、ユーザに見せる事(再生される事)が許可され
る。このフラグが0にセットされている場合、ユーザが
PIN番号を入力しなくても、そのボリュームのコンテン
ツを、ユーザに見せる事が許可される。
挿入した時点において、もしこのフラグが0にセットさ
れているか、または、このフラグが1にセットされてい
てもユーザがPIN番号を正しく入力できたならば、記録
再生装置1は、そのディスクの中のPlayListの一覧を表
示させる。それぞれのPlayListの再生制限は、volume_p
rotect_flagとは無関係であり、それはUIAppInfoPlayLi
st()の中に定義されるplayback_control_flagによって
示される。
され、それぞれの数字は、ISO/IEC 646に従って符号化
される。ref_thumbnail_indexのフィールドは、ボリュ
ームに付加されるサムネイル画像の情報を示す。ref_th
umbnail_indexフィールドが、0xFFFFでない値の場合、
そのボリュームにはサムネイル画像が付加されており、
そのサムネイル画像は、menu.thumファイルの中にスト
アされている。その画像は、menu.thumファイルの中でr
ef_thumbnail_indexの値を用いて参照される。ref_thum
bnail_indexフィールドが、0xFFFF である場合、そのボ
リュームにはサムネイル画像が付加されていないことを
示す。
内のTableOfPlayLists()について説明する。TableOfPla
yLists()は、PlayList(Real PlayListとVirtual PlayLi
st)のファイル名をストアする。ボリュームに記録され
ているすべてのPlayListファイルは、TableOfPlayLis
t()の中に含まれる。TableOfPlayLists()は、ボリュー
ムの中のPlayListのデフォルトの再生順序を示す。
スを示す図であり、そのシンタクスについて説明する
に、TableOfPlayListsのversion_numberは、このTableO
fPlayListsのバージョンナンバーを示す4個のキャラク
ター文字を示す。version_numberは、ISO 646に従っ
て、"0045"と符号化されなければならない。
らTableOfPlayLists()の最後までのTableOfPlayLists()
のバイト数を示す32ビットの符号なしの整数である。
number_of_PlayListsの16ビットのフィールドは、Pla
yList_file_nameを含むfor-loopのループ回数を示す。
この数字は、ボリュームに記録されているPlayListの数
に等しくなければならない。PlayList_file_nameの10
バイトの数字は、PlayListのファイル名を示す。
スを別実施の構成を示す図である。図21に示したシン
タクスは、図20に示したシンタクスに、UIAppinfoPla
yList(後述)を含ませた構成とされている。このよう
に、UIAppinfoPlayListを含ませた構成とすることで、T
ableOfPlayListsを読み出すだけで、メニュー画面を作
成することが可能となる。ここでは、図20に示したシ
ンタクスを用いるとして以下の説明をする。
MakersPrivateDataについて説明する。MakersPrivateDa
taは、記録再生装置1のメーカが、各社の特別なアプリ
ケーションのために、MakersPrivateData()の中にメー
カのプライベートデータを挿入できるように設けられて
いる。各メーカのプライベートデータは、それを定義し
たメーカを識別するために標準化されたmaker_IDを持
つ。MakersPrivateData()は、1つ以上のmaker_IDを含
んでも良い。
入したい時に、すでに他のメーカのプライベートデータ
がMakersPrivateData()に含まれていた場合、他のメー
カは、既にある古いプライベートデータを消去するので
はなく、新しいプライベートデータをMakersPrivateDat
a()の中に追加するようにする。このように、本実施の
形態においては、複数のメーカのプライベートデータ
が、1つのMakersPrivateData()に含まれることが可能
であるようにする。
スを示す図である。図22に示したMakersPrivateData
のシンタクスについて説明するに、version_numberは、
このMakersPrivateData()のバージョンナンバーを示す
4個のキャラクター文字を示す。version_numberは、IS
O 646に従って、"0045"と符号化されなければならな
い。lengthは、このlengthフィールドの直後からMakers
PrivateData()の最後までのMakersPrivateData()のバイ
ト数を示す32ビットの符号なし整数を示す。
ateData()の先頭のバイトからの相対バイト数を単位と
して、最初のmpd_block()の先頭バイトアドレスを示
す。相対バイト数はゼロからカウントされる。number_o
f_maker_entriesは、MakersPrivateData()の中に含まれ
ているメーカプライベートデータのエントリー数を与え
る16ビットの符号なし整数である。MakersPrivateDat
a()の中に、同じmaker_IDの値を持つメーカプライベー
トデータが2個以上存在してはならない。
として、1つのmpd_blockの大きさを与える16ビット
の符号なし整数である。例えば、mpd_block_size=1な
らば、それは1つのmpd_blockの大きさが1024バイ
トであることを示す。number_of_mpd_blocksは、Makers
PrivateData()の中に含まれるmpd_blockの数を与える1
6ビットの符号なし整数である。maker_IDは、そのメー
カプライベートデータを作成したDVRシステムの製造メ
ーカを示す16ビットの符号なし整数である。maker_IDに
符号化される値は、このDVRフォーマットのライセンサ
によって指定される。
ートデータを作成したDVRシステムのモデルナンバーコ
ードを示す16ビットの符号なし整数である。maker_mo
del_codeに符号化される値は、このフォーマットのライ
センスを受けた製造メーカによって設定される。start_
mpd_block_numberは、そのメーカプライベートデータが
開始されるmpd_blockの番号を示す16ビットの符号な
し整数である。メーカプライベートデータの先頭データ
は、mpd_blockの先頭にアラインされなければならな
い。start_mpd_block_numberは、mpd_blockのfor-loop
の中の変数jに対応する。
ベートデータの大きさを示す32ビットの符号なし整数
である。mpd_blockは、メーカプライベートデータがス
トアされる領域である。MakersPrivateData()の中のす
べてのmpd_blockは、同じサイズでなければならない。
List fileについて、換言すれば、xxxxx.rplsとyyyyy.v
plsについて説明する。図23は、xxxxx.rpls(Real Pl
ayList)、または、yyyyy.vpls(Virtual PlayList)の
シンタクスを示す図である。xxxxx.rplsとyyyyy.vpls
は、同一のシンタクス構成をもつ。xxxxx.rplsとyyyyy.
vplsは、それぞれ、3個のオブジェクトから構成され、
それらは、PlayList()、PlayListMark()、およびMakerP
rivateData()である。
ファイルの先頭のバイトからの相対バイト数を単位とし
て、PlayListMark()の先頭アドレスを示す。相対バイト
数はゼロからカウントされる。
Listファイルの先頭のバイトからの相対バイト数を単位
として、MakerPrivateData()の先頭アドレスを示す。相
対バイト数はゼロからカウントされる。
ayListファイルのシンタクスにしたがって挿入され、N
1とN2は、ゼロまたは任意の正の整数である。それぞ
れのパディングワードは、任意の値を取るようにしても
良い。
stについてさらに説明する。ディスク内にあるすべての
Real PlayListによって、Bridge-Clip(後述)を除くす
べてのClipの中の再生区間が参照されていなければなら
ない。かつ、2つ以上のRealPlayListが、それらのPlay
Itemで示される再生区間を同一のClipの中でオーバーラ
ップさせてはならない。
4(A)に示したように、全てのClipは、対応するReal
PlayListが存在する。この規則は、図24(B)に示
したように、編集作業が行われた後においても守られ
る。従って、全てのClipは、どれかしらのReal PlayLis
tを参照することにより、必ず視聴することが可能であ
る。
ayListの再生区間は、Real PlayListの再生区間またはB
ridge-Clipの再生区間の中に含まれていなければならな
い。どのVirtual PlayListにも参照されないBridge-Cli
pがディスクの中に存在してはならない。
むが、SubPlayItemを含んではならない。Virtual PlayL
istは、PlayItemのリストを含み、PlayList()の中に示
されるCPI_typeがEP_map typeであり、かつPlayList_ty
peが0(ビデオとオーディオを含むPlayList)である場
合、Virtual PlayListは、ひとつのSubPlayItemを含む
事ができる。本実施の形態におけるPlayList()では、Su
bPlayIteはオーディオのアフレコの目的にだけに使用さ
れる、そして、1つのVirtual PlayListが持つSubPlayI
temの数は、0または1でなければならない。
は、PlayListのシンタクスを示す図である。図25に示
したPlayListのシンタクスを説明するに、version_numb
erは、このPlayList()のバージョンナンバーを示す4個
のキャラクター文字である。version_numberは、ISO 64
6に従って、"0045"と符号化されなければならない。len
gthは、このlengthフィールドの直後からPlayList()の
最後までのPlayList()のバイト数を示す32ビットの符
号なし整数である。PlayList_typeは、このPlayListの
タイプを示す8ビットのフィールドであり、その一例を
図26に示す。
ayItem()およびSubPlayItem()によって参照されるClip
のCPI_typeの値を示す。1つのPlayListによって参照さ
れる全てのClipは、それらのCPI()の中に定義されるCPI
_typeの値が同じでなければならない。number_of_PlayI
temsは、PlayListの中にあるPlayItemの数を示す16ビ
ットのフィールドである。
は、PlayItem()を含むfor-loopの中で、そのPlayItem()
の現れる順番により定義される。PlayItem_idは、0か
ら開始される。number_of_SubPlayItemsは、PlayListの
中にあるSubPlayItemの数を示す16ビットのフィール
ドである。この値は、0または1である。付加的なオー
ディオストリームのパス(オーディオストリームパス)
は、サブパスの一種である。
スのUIAppInfoPlayListについて説明する。UIAppInfoPl
ayListは、PlayListについてのユーザインタフェースア
プリケーションのパラメータをストアする。図27は、
UIAppInfoPlayListのシンタクスを示す図である。図2
7に示したUIAppInfoPlayListのシンタクスを説明する
に、character_setは、8ビットのフィールドであり、P
layList_nameフィールドに符号化されているキャラクタ
ー文字の符号化方法を示す。その符号化方法は、図19
に示したテーブルに準拠する値に対応する。
り、PlayList_nameフィールドの中に示されるPlayList
名のバイト長を示す。PlayList_nameのフィールドは、P
layListの名称を示す。このフィールドの中の左からnam
e_length数のバイト数が、有効なキャラクター文字であ
り、それはPlayListの名称を示す。PlayList_nameフィ
ールドの中で、それら有効なキャラクター文字の後の値
は、どんな値が入っていても良い。
された時の日時をストアする56ビットのフィールドで
ある。このフィールドは、年/月/日/時/分/秒につ
いて、14個の数字を4ビットのBinary Coded Decimal
(BCD)で符号化したものである。例えば、2001/12/23:0
1:02:03 は、"0x20011223010203"と符号化される。
/分/秒の単位で示した24ビットのフィールドであ
る。このフィールドは、6個の数字を4ビットのBinary
CodedDecimal(BCD)で符号化したものである。例えば、
01:45:30は、"0x014530"と符号化される。
間を示す32ビットのフィールドである。このフィール
ドは、8個の数字を4ビットのBinary Coded Decimal(B
CD)で符号化したものである。例えば、記録再生装置1
は、この有効期間の過ぎたPlayListを自動消去する、と
いったように用いられる。例えば、2001/05/07 は、"0x
20010507"と符号化される。
たDVRプレーヤ(記録再生装置1)の製造者を示す16
ビットの符号なし整数である。maker_idに符号化される
値は、DVRフォーマットのライセンサによって割り当て
られる。maker_codeは、そのPlayListを最後に更新した
DVRプレーヤのモデル番号を示す16ビットの符号なし
整数である。maker_codeに符号化される値は、DVRフォ
ーマットのライセンスを受けた製造者によって決められ
る。
ットされている場合、ユーザが正しくPIN番号を入力で
きた場合にだけ、そのPlayListは再生される。このフラ
グが0にセットされている場合、ユーザがPIN番号を入
力しなくても、ユーザは、そのPlayListを視聴すること
ができる。
ーブルを示すように、1にセットされている場合、writ
e_protect_flagを除いて、そのPlayListの内容は、消去
および変更されない。このフラグが0にセットされてい
る場合、ユーザは、そのPlayListを自由に消去および変
更できる。このフラグが1にセットされている場合、ユ
ーザが、そのPlayListを消去、編集、または上書きする
前に、記録再生装置1はユーザに再確認するようなメッ
セージを表示させる。
るReal PlayListが存在し、かつ、そのReal PlayListの
Clipを参照するVirtual PlayListが存在し、そのVirtua
l PlayListのwrite_protect_flagが1にセットされてい
ても良い。ユーザが、RealPlayListを消去しようとする
場合、記録再生装置1は、そのReal PlayListを消去す
る前に、上記Virtual PlayListの存在をユーザに警告す
るか、または、そのReal PlayListを"Minimize”する。
うに、フラグが1にセットされている場合、そのPlayLi
stは、記録されてから一度は再生されたことを示し、0
にセットされている場合、そのPlayListは、記録されて
から一度も再生されたことがないことを示す。
そのPlayListがオリジナルであるか、コピーされたもの
であるかを示す2ビットのフィールドである。ref_thum
bnail_index のフィールドは、PlayListを代表するサム
ネイル画像の情報を示す。ref_thumbnail_indexフィー
ルドが、0xFFFFでない値の場合、そのPlayListには、Pl
ayListを代表するサムネイル画像が付加されており、そ
のサムネイル画像は、menu.thum ファイルの中にストア
されている。その画像は、menu.thumファイルの中でref
_thumbnail_indexの値を用いて参照される。ref_thumbn
ail_indexフィールドが、0xFFFF である場合、そのPlay
Listには、PlayListを代表するサムネイル画像が付加さ
れていない。
ayItem()は、基本的に次のデータを含む。Clipのファイ
ル名を指定するためのClip_information_file_name、Cl
ipの再生区間を特定するためのIN_timeとOUT_timeのペ
ア、PlayList()において定義されるCPI_typeがEP_map t
ypeである場合、IN_timeとOUT_timeが参照するところの
STC_sequence_id、および、先行するPlayItemと現在のP
layItemとの接続の状態を示すところのconnection_cond
itionである。
れる時、それらのPlayItemはPlayListのグローバル時間
軸上に、時間のギャップまたはオーバーラップなしに一
列に並べられる。PlayList()において定義されるCPI_ty
peがEP_map typeであり、かつ現在のPlayItemがBridgeS
equence()を持たない時、そのPlayItemにおいて定義さ
れるIN_timeとOUT_timeのペアは、STC_sequence_idによ
って指定される同じSTC連続区間上の時間を指していな
ければならない。そのような例を図29に示す。
CPI_typeがEP_map typeであり、かつ現在のPlayItemがB
ridgeSequence()を持つ時、次に説明する規則が適用さ
れる場合を示している。現在のPlayItemに先行するPlay
ItemのIN_time (図の中でIN_time1と示されているもの)
は、先行するPlayItemのSTC_sequence_idによって指定
されるSTC連続区間上の時間を指している。先行するPla
yItemのOUT_time(図の中でOUT_time1と示されているも
の)は、現在のPlayItemのBridgeSequenceInfo()の中で
指定されるBridge-Clipの中の時間を指している。このO
UT_timeは、後述する符号化制限に従っていなければな
らない。
me2と示されているもの)は、現在のPlayItemのBridgeS
equenceInfo()の中で指定されるBridge-Clipの中の時間
を指している。このIN_timeも、後述する符号化制限に
従っていなければならない。現在のPlayItemのPlayItem
のOUT_time (図の中でOUT_time2と示されているもの)
は、現在のPlayItemのSTC_sequence_idによって指定さ
れるSTC連続区間上の時間を指している。
peがTU_map typeである場合、PlayItemのIN_timeとOUT_
timeのペアは、同じClip AVストリーム上の時間を指し
ている。
うになる。図32に示したPlayItemのシンタクスを説明
するに、Clip_Information_file_nameのフィールドは、
ClipInformation fileのファイル名を示す。このClip I
nformation fileのClipInfo()において定義されるClip_
stream_typeは、Clip AV streamを示していなければな
らない。
ドであり、PlayItemが参照するSTC連続区間のSTC_seque
nce_idを示す。PlayList()の中で指定されるCPI_typeが
TU_map typeである場合、この8ビットフィールドは何
も意味を持たず、0にセットされる。IN_timeは、32
ビットフィールドであり、PlayItemの再生開始時刻をス
トアする。IN_timeのセマンティクスは、図33に示す
ように、PlayList()において定義されるCPI_typeによっ
て異なる。
り、PlayItemの再生終了時刻をストアする。OUT_timeの
セマンティクスは、図34に示すように、PlayList()に
おいて定義されるCPI_typeによって異なる。
ような先行するPlayItemと、現在のPlayItemとの間の接
続状態を示す2ビットのフィールドである。図36は、
図35に示したConnection_Conditionの各状態について
説明する図である。
7を参照して説明する。BridgeSequenceInfo()は、現在
のPlayItemの付属情報であり、次に示す情報を持つ。Br
idge-Clip AV streamファイルとそれに対応するClip In
formation fileを指定するBridge_Clip_Information_fi
le_nameを含む。
V stream上のソースパケットのアドレスであり、このソ
ースパケットに続いてBridge-Clip AV streamファイル
の最初のソースパケットが接続される。このアドレス
は、RSPN_exit_from_previous_Clipと称される。さらに
現在のPlayItemが参照するClip AV stream上のソースパ
ケットのアドレスであり、このソースパケットの前にBr
idge-Clip AV streamファイルの最後のソースパケット
が接続される。このアドレスは、RSPN_enter_to_curren
t_Clipと称される。
ontinuityは、the Bridge-Clip AVstreamファイルの中
でアライバルタイムベースの不連続点があるところのソ
ースパケットのアドレスを示す。このアドレスは、Clip
Info()の中において定義される。
スを示す図である。図38に示したBridgeSequenceinfo
のシンタクスを説明するに、Bridge_Clip_Information_
file_nameのフィールドは、Bridge-Clip AV streamファ
イルに対応するClip Information fileのファイル名を
示す。このClip Information fileのClipInfo()におい
て定義されるClip_stream_typeは、'Bridge-Clip AV st
ream'を示していなければならない。
トフィールドは、先行するPlayItemが参照するClip AV
stream上のソースパケットの相対アドレスであり、この
ソースパケットに続いてBridge-Clip AV streamファイ
ルの最初のソースパケットが接続される。RSPN_exit_fr
om_previous_Clipは、ソースパケット番号を単位とする
大きさであり、先行するPlayItemが参照するClip AV st
reamファイルの最初のソースパケットからClipInfo()に
おいて定義されるoffset_SPNの値を初期値としてカウン
トされる。
フィールドは、現在のPlayItemが参照するClip AV stre
am上のソースパケットの相対アドレスであり、このソー
スパケットの前にBridge-Clip AV streamファイルの最
後のソースパケットが接続される。RSPN_exit_from_pre
vious_Clipは、ソースパケット番号を単位とする大きさ
であり、現在のPlayItemが参照するClip AV streamファ
イルの最初のソースパケットからClipInfo()において定
義されるoffset_SPNの値を初期値としてカウントされ
る。
照して説明する。SubPlayItem()の使用は、PlayList()
のCPI_typeがEP_map typeである場合だけに許される。
本実施の形態においては、SubPlayItemはオーディオの
アフレコの目的のためだけに使用されるとする。SubPla
yItem()は、次に示すデータを含む。まず、PlayListの
中のsub pathが参照するClipを指定するためのClip_inf
ormation_file_ nameを含む。
定するためのSubPath_IN_time と SubPath_OUT_timeを
含む。さらに、main pathの時間軸上でsub pathが再生
開始する時刻を指定するためのsync_PlayItem_id と sy
nc_start_PTS_of_PlayItemを含む。sub pathに参照され
るオーディオのClip AV streamは、STC不連続点(シス
テムタイムベースの不連続点)を含んではならない。su
b pathに使われるClipのオーディオサンプルのクロック
は、main pathのオーディオサンプルのクロックにロッ
クされている。
す図である。図40に示したSubPlayItemのシンタクス
を説明するに、Clip_Information_file_nameのフィール
ドは、Clip Information fileのファイル名を示し、そ
れはPlayListの中でsub pathによって使用される。この
Clip Information fileのClipInfo()において定義され
るClip_stream_typeは、Clip AV streamを示していなけ
ればならない。
sub pathのタイプを示す。ここでは、図41に示すよう
に、'0x00'しか設定されておらず、他の値は、将来のた
めに確保されている。
は、main pathの時間軸上でsub pathが再生開始する時
刻が含まれるPlayItemのPlayItem_idを示す。所定のPla
yItemに対応するPlayItem_idの値は、PlayList()におい
て定義される(図25参照)。
のフィールドは、main pathの時間軸上でsub pathが再
生開始する時刻を示し、sync_PlayItem_idで参照される
PlayItem上のPTS(Presentaiotn Time Stamp)の上位32
ビットを示す。SubPath_IN_timeの32ビットフィール
ドは、Sub pathの再生開始時刻をストアする。SubPath_
IN_timeは、Sub Pathの中で最初のプレゼンテーション
ユニットに対応する33ビット長のPTSの上位32ビッ
トを示す。
は、Sub pathの再生終了時刻をストアする。SubPath_OU
T_timeは、次式によって算出されるPresenation_end_TS
の値の上位32ビットを示す。 Presentation_end_TS = PTS_out + AU_duration ここで、PTS_outは、SubPathの最後のプレゼンテーショ
ンユニットに対応する33ビット長のPTSである。AU_dura
tionは、SubPathの最後のプレゼンテーションユニット
の90kHz単位の表示期間である。
vplsのシンタクス内のPlayListMark()について説明す
る。PlayListについてのマーク情報は、このPlayListMa
rkにストアされる。図42は、PlayListMarkのシンタク
スを示す図である。図42に示したPlayListMarkのシン
タクスについて説明するに、version_numberは、このPl
ayListMark()のバージョンナンバーを示す4個のキャラ
クター文字である。version_numberは、ISO 646に従っ
て、"0045"と符号化されなければならない。
らPlayListMark()の最後までのPlayListMark()のバイト
数を示す32ビットの符号なし整数である。number_of_
PlayList_marksは、PlayListMarkの中にストアされてい
るマークの個数を示す16ビットの符号なし整数であ
る。number_of_PlayList_marks は、0であってもよ
い。mark_typeは、マークのタイプを示す8ビットのフ
ィールドであり、図43に示すテーブルに従って符号化
される。
は、マークが指定されたポイントを示すタイムスタンプ
をストアする。mark_time_stampのセマンティクスは、
図44に示すように、PlayList()において定義されるCP
I_typeによって異なる。PlayItem_idは、マークが置か
れているところのPlayItemを指定する8ビットのフィー
ルドである。所定のPlayItemに対応するPlayItem_idの
値は、PlayList()において定義される(図25参照)。
は、mark_nameフィールドに符号化されているキャラク
ター文字の符号化方法を示す。その符号化方法は、図1
9に示した値に対応する。name_lengthの8ビットフィ
ールドは、Mark_nameフィールドの中に示されるマーク
名のバイト長を示す。mark_nameのフィールドは、マー
クの名称を示す。このフィールドの中の左からname_len
gth数のバイト数が、有効なキャラクター文字であり、
それはマークの名称を示す。Mark_nameフィールドの中
で、それら有効なキャラクター文字の後の値は、どのよ
うな値が設定されても良い。
ークに付加されるサムネイル画像の情報を示す。ref_th
umbnail_indexフィールドが、0xFFFFでない値の場合、
そのマークにはサムネイル画像が付加されており、その
サムネイル画像は、mark.thmbファイルの中にストアさ
れている。その画像は、mark.thmbファイルの中でref_t
humbnail_indexの値を用いて参照される(後述)。ref_
thumbnail_indexフィールドが、0xFFFF である場合、そ
のマークにはサムネイル画像が付加されていない事を示
す。
明する。zzzzz.clpi(Clip information fileファイ
ル)は、図45に示すように6個のオブジェクトから構
成される。それらは、ClipInfo()、STC_Info()、Progra
mInfo()、CPI()、ClipMark()、およびMakerPrivateData
()である。AVストリーム(Clip AVストリームまたはBrid
ge-Clip AV stream)とそれに対応するClip Information
ファイルは、同じ数字列の"zzzzz"が使用される。
tion fileファイル)のシンタクスについて説明する
に、ClipInfo_Start_addressは、zzzzz.clpiファイルの
先頭のバイトからの相対バイト数を単位として、ClipIn
fo()の先頭アドレスを示す。相対バイト数はゼロからカ
ウントされる。
ァイルの先頭のバイトからの相対バイト数を単位とし
て、STC_Info()の先頭アドレスを示す。相対バイト数は
ゼロからカウントされる。ProgramInfo_Start_address
は、zzzzz.clpiファイルの先頭のバイトからの相対バイ
ト数を単位として、ProgramInfo()の先頭アドレスを示
す。相対バイト数はゼロからカウントされる。CPI_Star
t_addressは、zzzzz.clpiファイルの先頭のバイトから
の相対バイト数を単位として、CPI()の先頭アドレスを
示す。相対バイト数はゼロからカウントされる。
ァイルの先頭のバイトからの相対バイト数を単位とし
て、ClipMark()の先頭アドレスを示す。相対バイト数は
ゼロからカウントされる。MakerPrivateData_Start_add
ressは、zzzzz.clpiファイルの先頭のバイトからの相対
バイト数を単位として、MakerPrivateData ()の先頭ア
ドレスを示す。相対バイト数はゼロからカウントされ
る。padding_word(パディングワード)は、zzzzz.clpi
ファイルのシンタクスにしたがって挿入される。N1,
N2,N3,N4、およびN5は、ゼロまたは任意の正
の整数でなければならない。それぞれのパディングワー
ドは、任意の値がとられるようにしても良い。
は、ClipInfoのシンタクスを示す図である。ClipInfo()
は、それに対応するAVストリームファイル(Clip AVス
トリームまたはBridge-Clip AVストリームファイル)の
属性情報をストアする。
いて説明するに、version_numberは、このClipInfo()の
バージョンナンバーを示す4個のキャラクター文字であ
る。version_numberは、ISO 646に従って、"0045"と符
号化されなければならない。lengthは、このlengthフィ
ールドの直後からClipInfo()の最後までのClipInfo()の
バイト数を示す32ビットの符号なし整数である。Clip
_stream_typeの8ビットのフィールドは、図47に示す
ように、Clip Informationファイルに対応するAVストリ
ームのタイプを示す。それぞれのタイプのAVストリーム
のストリームタイプについては後述する。
AVストリーム(Clip AVストリームまたはBridge-Clip A
Vストリーム)ファイルの最初のソースパケットについ
てのソースパケット番号のオフセット値を与える。AVス
トリームファイルが最初にディスクに記録される時、こ
のoffset_SPNは0でなければならない。
ルのはじめの部分が編集によって消去された時、offset
_SPNは、ゼロ以外の値をとっても良い。本実施の形態で
は、offset_SPNを参照する相対ソースパケット番号(相
対アドレス)が、しばしば、RSPN_xxx(xxxは変形す
る。例.RSPN_EP_start)の形式でシンタクスの中に記
述されている。相対ソースパケット番号は、ソースパケ
ット番号を単位とする大きさであり、AVストリームファ
イルの最初のソースパケットからoffset_SPNの値を初期
値としてカウントされる。
ットから相対ソースパケット番号で参照されるソースパ
ケットまでのソースパケットの数(SPN_xxx)は、次式
で算出される。 SPN_xxx = RSPN_xxx - offset_SPN 図48に、offset_SPN が、4である場合の例を示す。
なし整数であり、この値は、DVRドライブ(書き込み部
22)へまたはDVRドライブ(読み出し部28)からのA
Vストリームの必要な入出力のビットレートを与える。r
ecord_time_and_dateは、Clipに対応するAVストリーム
が記録された時の日時をストアする56ビットのフィー
ルドであり、年/月/日/時/分/秒について、14個
の数字を4ビットのBinary Coded Decimal(BCD)で符号
化したものである。例えば、2001/12/23:01:02:03は、0
x20011223010203"と符号化される。
ルタイムクロックに基づいた時間/分/秒の単位で示し
た24ビットのフィールドである。このフィールドは、
6個の数字を4ビットのBinary Coded Decimal(BCD)で
符号化したものである。例えば、01:45:30は、0x01453
0"と符号化される。
トリームファイルの記録モードを示す。このtime_contr
olled_flagが1である場合、記録モードは、記録してか
らの時間経過に対してファイルサイズが比例するように
して記録されるモードであることを示し、次式に示す条
件を満たさなければならない。 TS_average_rate*192/188*(t - start_time)−α <= size_clip(t) <= TS_average_rate*192/188*(t - start_time)+α ここで、TS_average_rateは、AVストリームファイルの
トランスポートストリームの平均ビットレートをbytes/
second の単位で表したものである。
れる時間を示し、start_timeは、AVストリームファイル
の最初のソースパケットが記録された時の時刻であり、
秒単位で表される。size_clip(t)は、 時刻tにおけるA
Vストリームファイルのサイズをバイト単位で表したも
のであり、例えば、start_timeから時刻tまでに10個
のソースパケットが記録された場合、size_clip(t)は10
*192バイトである。αは、TS_average_rateに依存する
定数である。
いる場合、記録モードは、記録の時間経過とAVストリー
ムのファイルサイズが比例するように制御していないこ
とを示す。例えば、これは入力トランスポートストリー
ムをトランスペアレント記録する場合である。
gが1にセットされている場合、この24ビットのフィ
ールドは、上式で用いているTS_average_rateの値を示
す。time_controlled_flagが0にセットされている場
合、このフィールドは、何も意味を持たず、0にセット
されなければならない。例えば、可変ビットレートのト
ランスポートストリームは、次に示す手順により符号化
される。まずトランスポートレートをTS_recording_rat
eの値にセットする。次に、ビデオストリームを可変ビ
ットレートで符号化する。そして、ヌルパケットを使用
しない事によって、間欠的にトランスポートパケットを
符号化する。
ビットフィールドは、Bridge-Clip AV streamファイル
上でアライバルタイムベースの不連続が発生する場所の
相対アドレスである。RSPN_arrival_time_discontinuit
yは、ソースパケット番号を単位とする大きさであり、B
ridge-Clip AV streamファイルの最初のソースパケット
からClipInfo() において定義されるoffset_SPNの値を
初期値としてカウントされる。そのBridge-Clip AV str
eamファイルの中での絶対アドレスは、上述した SPN_xxx = RSPN_xxx - offset_SPN に基づいて算出される。
ィールドは、システム用にリザーブされている。is_for
mat_identifier_validのフラグが1である時、format_i
dentifierのフィールドが有効であることを示す。is_or
iginal_network_ID_validのフラグが1である場合、ori
ginal_network_IDのフィールドが有効であることを示
す。is_transport_stream_ID_validのフラグが1である
場合、transport_stream_IDのフィールドが有効である
ことを示す。is_servece_ID_validのフラグが1である
場合、servece_IDのフィールドが有効であることを示
す。
る時、country_codeのフィールドが有効であることを示
す。format_identifierの32ビットフィールドは、トラ
ンスポートストリームの中でregistration deascriotor
(ISO/IEC13818-1で定義されている)が持つformat_ide
ntifierの値を示す。original_network_IDの16ビット
フィールドは、トランスポートストリームの中で定義さ
れているoriginal_network_IDの値を示す。transport_s
tream_IDの16ビットフィールドは、トランスポートス
トリームの中で定義されているtransport_stream_IDの
値を示す。
ランスポートストリームの中で定義されているservece_
IDの値を示す。country_codeの24ビットのフィールド
は、ISO3166によって定義されるカントリーコードを示
す。それぞれのキャラクター文字は、ISO8859-1で符号
化される。例えば、日本は"JPN"と表され、"0x4A 0x500
x4E"と符号化される。stream_format_nameは、トランス
ポートストリームのストリーム定義をしているフォーマ
ット機関の名称を示すISO-646の16個のキャラクター
コードである。このフィールドの中の無効なバイトは、
値'0xFF'がセットされる。
D、transport_stream_ID、 servece_ID,country_code
、およびstream_format_nameは、トランスポートスト
リームのサービスプロバイダを示すものであり、これに
より、オーディオやビデオストリームの符号化制限、SI
(サービスインフォメーション)の規格やオーディオビデ
オストリーム以外のプライベートデータストリームのス
トリーム定義を認識することができる。これらの情報
は、デコーダが、そのストリームをデコードできるか否
か、そしてデコードできる場合にデコード開始前にデコ
ーダシステムの初期設定を行うために用いることが可能
である。
は、MPEG-2トランスポートストリームの中でSTCの不連
続点(システムタイムベースの不連続点)を含まない時
間区間をSTC_sequenceと称し、Clipの中で、STC_sequen
ceは、STC_sequence_idの値によって特定される。図5
0は、連続なSTC区間について説明する図である。同
じSTC_sequenceの中で同じSTCの値は、決して現れない
(ただし、後述するように、Clipの最大時間長は制限さ
れている)。従って、同じSTC_sequenceの中で同じPTS
の値もまた、決して現れない。AVストリームが、N(N>0)
個のSTC不連続点を含む場合、Clipのシステムタイムベ
ースは、(N+1)個のSTC_sequenceに分割される。
ムベースの不連続)が発生する場所のアドレスをストア
する。図51を参照して説明するように、RSPN_STC_sta
rtが、そのアドレスを示し、最後のSTC_sequenceを除く
k番目(k>=0)のSTC_sequenceは、k番目のRSPN_STC_sta
rtで参照されるソースパケットが到着した時刻から始ま
り、(k+1)番目のRSPN_STC_startで参照されるソースパ
ケットが到着した時刻で終わる。最後のSTC_sequence
は、最後のRSPN_STC_startで参照されるソースパケット
が到着した時刻から始まり、最後のソースパケットが到
着した時刻で終了する。
である。図52に示したSTC_Infoのシンタクスについて
説明するに、version_numberは、このSTC_Info()のバー
ジョンナンバーを示す4個のキャラクター文字である。
version_numberは、ISO 646に従って、"0045"と符号化
されなければならない。
らSTC_Info()の最後までのSTC_Info()のバイト数を示す
32ビットの符号なし整数である。CPI()のCPI_typeがT
U_map typeを示す場合、このlengthフィールドはゼロを
セットしても良い。CPI()のCPI_typeがEP_map typeを示
す場合、num_of_STC_sequencesは1以上の値でなければ
ならない。
し整数は、Clipの中でのSTC_sequenceの数を示す。この
値は、このフィールドに続くfor-loopのループ回数を示
す。所定のSTC_sequenceに対応するSTC_sequence_id
は、RSPN_STC_startを含むfor-loopの中で、そのSTC_se
quenceに対応するRSPN_STC_startの現れる順番により定
義されるものである。STC_sequence_idは、0から開始
される。
は、AVストリームファイル上でSTC_sequenceが開始する
アドレスを示す。RSPN_STC_startは、AVストリームファ
イルの中でシステムタイムベースの不連続点が発生する
アドレスを示す。RSPN_STC_startは、AVストリームの中
で新しいシステムタイムベースの最初のPCRを持つソー
スパケットの相対アドレスとしても良い。RSPN_STC_sta
rtは、ソースパケット番号を単位とする大きさであり、
AVストリームファイルの最初のソースパケットからClip
Info()において定義されるoffset_SPNの値を初期値とし
てカウントされる。そのAV streamファイルの中での絶
対アドレスは、既に上述したSPN_xxx = RSPN_xxx - off
set_SPNにより算出される。
クス内のProgramInfoについて説明する。図53を参照
しながら説明するに、ここでは、Clipの中で次の特徴を
もつ時間区間をprogram_sequenceと呼ぶ。まず、PCR_PI
Dの値が変わらない。次に、ビデオエレメンタリストリ
ームの数が変化しない。また、それぞれのビデオストリ
ームについてのPIDの値とそのVideoCodingInfoによって
定義される符号化情報が変化しない。さらに、オーディ
オエレメンタリストリームの数が変化しない。また、そ
れぞれのオーディオストリームについてのPIDの値とそ
のAudioCodingInfoによって定義される符号化情報が変
化しない。
て、ただ1つのシステムタイムベースを持つ。program_
sequenceは、同一の時刻において、ただ1つのPMTを持
つ。ProgramInfo()は、program_sequenceが開始する場
所のアドレスをストアする。RSPN_program_sequence_st
artが、そのアドレスを示す。
す図である。図54に示したProgramInfoのシンタクを
説明するに、version_numberは、このProgramInfo()の
バージョンナンバーを示す4個のキャラクター文字であ
る。version_numberは、ISO 646に従って、"0045"と符
号化されなければならない。
らProgramInfo()の最後までのProgramInfo()のバイト数
を示す32ビットの符号なし整数である。CPI()のCPI_t
ypeがTU_map typeを示す場合、このlengthフィールドは
ゼロにセットされても良い。CPI()のCPI_typeがEP_map
typeを示す場合、number_of_programsは1以上の値でな
ければならない。
の符号なし整数は、Clipの中でのprogram_sequenceの数
を示す。この値は、このフィールドに続くfor-loopのル
ープ回数を示す。Clipの中でprogram_sequenceが変化し
ない場合、number_of_program_sequencesは1をセット
されなければならない。RSPN_program_sequence_start
の32ビットフィールドは、AVストリームファイル上で
プログラムシーケンスが開始する場所の相対アドレスで
ある。
パケット番号を単位とする大きさであり、AVストリーム
ファイルの最初のソースパケットからClipInfo()におい
て定義されるoffset_SPNの値を初期値としてカウントさ
れる。そのAVストリームファイルの中での絶対アドレス
は、 SPN_xxx = RSPN_xxx - offset_SPN により算出される。シンタクスのfor-loopの中でRSPN_p
rogram_sequence_start値は、昇順に現れなければなら
ない。
rogram_sequenceに有効なPCRフィールドを含むトランス
ポートパケットのPIDを示す。number_of_videosの8ビ
ットフィールドは、video_stream_PIDとVideoCodingInf
o()を含むfor-loopのループ回数を示す。number_of_aud
iosの8ビットフィールドは、audio_stream_PIDとAudio
CodingInfo()を含むfor-loopのループ回数を示す。vide
o_stream_PIDの16ビットフィールドは、そのprogram_
sequenceに有効なビデオストリームを含むトランスポー
トパケットのPIDを示す。このフィールドに続くVideoCo
dingInfo()は、そのvideo_stream_PIDで参照されるビデ
オストリームの内容を説明しなければならない。
は、そのprogram_sequenceに有効なオーディオストリー
ムを含むトランスポートパケットのPIDを示す。このフ
ィールドに続くAudioCodingInfo()は、そのaudio_strea
m_PIDで参照されるビデオストリームの内容を説明しな
ければならない。
stream_PIDの値の現れる順番は、そのprogram_sequence
に有効なPMTの中でビデオストリームのPIDが符号化され
ている順番に等しくなければならない。また、シンタク
スのfor-loopの中でaudio_stream_PIDの値の現れる順番
は、そのprogram_sequenceに有効なPMTの中でオーディ
オストリームのPIDが符号化されている順番に等しくな
ければならない。
シンタクス内のVideoCodingInfoのシンタクスを示す図
である。図55に示したVideoCodingInfoのシンタクス
を説明するに、video_formatの8ビットフィールドは、
図56に示すように、ProgramInfo()の中のvideo_strea
m_PIDに対応するビデオフォーマットを示す。
7に示すように、ProgramInfo()の中のvideo_stream_PI
Dに対応するビデオのフレームレートを示す。display_a
spect_ratioの8ビットフィールドは、図58に示すよ
うに、ProgramInfo()の中のvideo_stream_PIDに対応す
るビデオの表示アスペクト比を示す。
シンタクス内のAudioCodingInfoのシンタクスを示す図
である。図59に示したAudioCodingInfoのシンタクス
を説明するに、audio_codingの8ビットフィールドは、
図60に示すように、ProgramInfo()の中のaudio_strea
m_PIDに対応するオーディオの符号化方法を示す。
ドは、図61に示すように、ProgramInfo()の中のaudio
_stream_PIDに対応するオーディオのコンポーネントタ
イプを示す。sampling_frequencyの8ビットフィールド
は、図62に示すように、ProgramInfo()の中のaudio_s
tream_PIDに対応するオーディオのサンプリング周波数
を示す。
クス内のCPI (Characteristic Point Information)につ
いて説明する。CPIは、AVストリームの中の時間情報と
そのファイルの中のアドレスとを関連づけるためにあ
る。CPIには2つのタイプがあり、それらはEP_mapとTU_
mapである。図63に示すように、CPI()の中のCPI_type
がEP_map typeの場合、そのCPI()はEP_mapを含む。図6
4に示すように、CPI()の中のCPI_typeがTU_map typeの
場合、そのCPI()はTU_mapを含む。1つのAVストリーム
は、1つのEP_mapまたは一つのTU_mapを持つ。AVストリ
ームがSESFトランスポートストリームの場合、それに対
応するClipはEP_mapを持たなければならない。
る。図65に示したCPIのシンタクスを説明するに、ver
sion_numberは、このCPI()のバージョンナンバーを示す
4個のキャラクター文字である。version_numberは、IS
O 646に従って、"0045"と符号化されなければならな
い。lengthは、このlengthフィールドの直後からCPI()
の最後までのCPI()のバイト数を示す32ビットの符号
なし整数である。CPI_typeは、図66に示すように、1
ビットのフラグであり、ClipのCPIのタイプを表す。
のEP_mapについて説明する。EP_mapには、2つのタイプ
があり、それはビデオストリーム用のEP_mapとオーディ
オストリーム用のEP_mapである。EP_mapの中のEP_map_t
ypeが、EP_mapのタイプを区別する。Clipが1つ以上の
ビデオストリームを含む場合、ビデオストリーム用のEP
_mapが使用されなければならない。Clipがビデオストリ
ームを含まず、1つ以上のオーディオストリームを含む
場合、オーディオストリーム用のEP_mapが使用されなけ
ればならない。
7を参照して説明する。ビデオストリーム用のEP_map
は、stream_PID、PTS_EP_start、および、RSPN_EP_star
tというデータを持つ。stream_PIDは、ビデオストリー
ムを伝送するトランスポートパケットのPIDを示す。PTS
_EP_startは、ビデオストリームのシーケンスヘッダか
ら始めるアクセスユニットのPTSを示す。RSPN_EP_start
は、AVストリームの中でPTS_EP_startにより参照される
アクセスユニットの第1バイト目を含むソースポケット
のアドレスを示す。
サブテーブルは、同じPIDを持つトランスポートパケッ
トによって伝送されるビデオストリーム毎に作られる。
Clipの中に複数のビデオストリームが存在する場合、EP
_mapは複数のEP_map_for_one_stream_PID()を含んでも
良い。
am_PID、PTS_EP_start、およびRSPN_EP_startというデ
ータを持つ。stream_PIDは、オーディオストリームを伝
送するトランスポートパケットのPIDを示す。PTS_EP_st
artは、オーディオストリームのアクセスユニットのPTS
を示す。RSPN_EP_startは、AVストリームの中でPTS_EP_
startで参照されるアクセスユニットの第1バイト目を
含むソースポケットのアドレスを示す。
サブテーブルは、同じPIDを持つトランスポートパケッ
トによって伝送されるオーディオストリーム毎に作られ
る。Clipの中に複数のオーディオストリームが存在する
場合、EP_mapは複数のEP_map_for_one_stream_PID()を
含んでも良い。
つのEP_map_for_one_stream_PID()は、STCの不連続点に
関係なく1つのテーブルに作られる。RSPN_EP_startの
値とSTC_Info()において定義されるRSPN_STC_startの値
を比較する事により、それぞれのSTC_sequenceに属する
EP_mapのデータの境界が分かる(図68を参照)。EP_m
apは、同じPIDで伝送される連続したストリームの範囲
に対して、1つのEP_map_for_one_stream_PIDを持たね
ばならない。図69に示したような場合、program#1とp
rogram#3は、同じビデオPIDを持つが、データ範囲が連
続していないので、それぞれのプログラム毎にEP_map_f
or_one_stream_PIDを持たねばならない。
ある。図70に示したEP_mapのシンタクスを説明する
に、EP_typeは、4ビットのフィールドであり、図71
に示すように、EP_mapのエントリーポイントタイプを示
す。EP_typeは、このフィールドに続くデータフィール
ドのセマンティクスを示す。Clipが1つ以上のビデオス
トリームを含む場合、EP_typeは0('video')にセットさ
れなければならない。または、Clipがビデオストリーム
を含まず、1つ以上のオーディオストリームを含む場
合、EP_typeは1('audio')にセットされなければならな
い。
ィールドは、EP_map()の中のnumber_of_stream_PIDsを
変数にもつfor-loopのループ回数を示す。stream_PID
(k)の16ビットのフィールドは、EP_map_for_one_stre
am_PID(num_EP_entries(k))によって参照されるk番目の
エレメンタリストリーム(ビデオまたはオーディオスト
リーム)を伝送するトランスポートパケットのPIDを示
す。EP_typeが0 ('video')に等しい場合、そのエレメン
タリストリームはビデオストリームでなけれならない。
また、EP_typeが1('audio')に等しい場合、そのエレメ
ンタリストリームはオーディオストリームでなければな
らない。
ルドは、EP_map_for_one_stream_PID(num_EP_entries
(k))によって参照されるnum_EP_entries(k)を示す。EP_
map_for_one_stream_PID_Start_address(k): この32ビ
ットのフィールドは、EP_map()の中でEP_map_for_one_s
tream_PID(num_EP_entries(k))が始まる相対バイト位置
を示す。この値は、EP_map()の第1バイト目からの大き
さで示される。
したがって挿入されなければならない。XとYは、ゼロま
たは任意の正の整数でなければならない。それぞれのパ
ディングワードは、任意の値を取っても良い。
シンタクスを示す図である。図72に示したEP_map_for
_one_stream_PIDのシンタクスを説明するに、PTS_EP_st
artの32ビットのフィールドのセマンティクスは、EP_
map()において定義されるEP_typeにより異なる。EP_typ
eが0 ('video')に等しい場合、このフィールドは、ビデ
オストリームのシーケンスヘッダで始まるアクセスユニ
ットの33ビット精度のPTSの上位32ビットを持つ。E
P_typeが1 ('audio')に等しい場合、このフィールド
は、オーディオストリームのアクセスユニットの33ビ
ット精度のPTSの上位32ビットを持つ。
のセマンティクスは、EP_map()において定義されるEP_t
ypeにより異なる。EP_typeが0 ('video')に等しい場
合、このフィールドは、AVストリームの中でPTS_EP_sta
rtにより参照されるアクセスユニットのシーケンスヘッ
ダの第1バイト目を含むソースポケットの相対アドレス
を示す。または、EP_typeが1 ('audio')に等しい場合、
このフィールドは、AVストリームの中でPTS_EP_startに
より参照されるアクセスユニットのオーディオフレーム
の第一バイト目を含むソースポケットの相対アドレスを
示す。
単位とする大きさであり、AVストリームファイルの最初
のソースパケットからClipInfo()において定義されるof
fset_SPNの値を初期値としてカウントされる。そのAVス
トリームファイルの中での絶対アドレスは、 SPN_xxx = RSPN_xxx - offset_SPN により算出される。シンタクスのfor-loopの中でRSPN_E
P_startの値は、昇順に現れなければならない。
説明する。TU_mapは、ソースパケットのアライバルタイ
ムクロック(到着時刻ベースの時計)に基づいて、1つ
の時間軸を作る。その時間軸は、TU_map_time_axisと呼
ばれる。TU_map_time_axisの原点は、TU_map()の中のof
fset_timeによって示される。TU_map_time_axisは、off
set_timeから一定の単位に分割される。その単位を、ti
me_unitと称する。
で、最初の完全な形のソースパケットのAVストリームフ
ァイル上のアドレスが、TU_mapにストアされる。これら
のアドレスを、RSPN_time_unit_startと称する。TU_map
_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)は、45kHzの精度を持つ。
ある。図75に示したTU_mapのシンタクスを説明する
に、offset_timeの32bit長のフィールドは、TU_map_t
ime_axisに対するオフセットタイムを与える。この値
は、Clipの中の最初のtime_unitに対するオフセット時
刻を示す。offset_timeは、27MHz精度のアライバルタ
イムクロックから導き出される45kHzクロックを単位
とする大きさである。AVストリームが新しいClipとして
記録される場合、offset_timeはゼロにセットされなけ
ればならない。
は、time_unitの大きさを与えるものであり、それは2
7MHz精度のアライバルタイムクロックから導き出され
る45kHzクロックを単位とする大きさである。time_unit
_sizeは、1秒以下(time_unit_size<=45000)にするこ
とが良い。number_of_time_unit_entriesの32ビット
フィールドは、TU_map()の中にストアされているtime_u
nitのエントリー数を示す。
ルドは、AVストリームの中でそれぞれのtime_unitが開
始する場所の相対アドレスを示す。RSPN_time_unit_sta
rtは、ソースパケット番号を単位とする大きさであり、
AV streamファイルの最初のソースパケットからClipInf
o()において定義されるoffset_SPNの値を初期値として
カウントされる。そのAV streamファイルの中での絶対
アドレスは、 SPN_xxx = RSPN_xxx - offset_SPN により算出される。シンタクスのfor-loopの中でRSPN_t
ime_unit_startの値は、昇順に現れなければならない。
(k+1)番目のtime_unitの中にソースパケットが何もない
場合、(k+1)番目のRSPN_time_unit_startは、k番目のRS
PN_time_unit_startと等しくなければならない。
のClipMarkについて説明する。ClipMarkは、クリップに
ついてのマーク情報であり、ClipMarkの中にストアされ
る。このマークは、記録器(記録再生装置1)によって
セットされるものであり、ユーザによってセットされる
ものではない。
である。図75に示したClipMarkのシンタクスを説明す
るに、version_numberは、このClipMark()のバージョン
ナンバーを示す4個のキャラクター文字である。versio
n_numberは、ISO 646に従って、"0045"と符号化されな
ければならない。
らClipMark()の最後までのClipMark()のバイト数を示す
32ビットの符号なし整数である。number_of_Clip_mar
ksは、 ClipMarkの中にストアされているマークの個数
を示す16ビットの符号なし整数。number_of_Clip_mar
ks は、0であってもよい。mark_typeは、マークのタイ
プを示す8ビットのフィールドであり、図76に示すテ
ーブルに従って符号化される。
ドであり、マークが指定されたポイントを示すタイムス
タンプをストアする。mark_time_stampのセマンティク
スは、図77に示すように、PlayList()の中のCPI_type
により異なる。
がEP_map typeを示す場合、この8ビットのフィールド
は、マークが置かれているところのSTC連続区間のSTC_s
equence_idを示す。CPI()の中のCPI_typeがTU_map type
を示す場合、この8ビットのフィールドは何も意味を持
たず、ゼロにセットされる。character_setの8ビット
のフィールドは、mark_nameフィールドに符号化されて
いるキャラクター文字の符号化方法を示す。その符号化
方法は、図19に示される値に対応する。
k_nameフィールドの中に示されるマーク名のバイト長を
示す。mark_nameのフィールドは、マークの名称を示
す。このフィールドの中の左からname_length数のバイ
ト数が、有効なキャラクター文字であり、それはマーク
の名称を示す。mark_nameフィールドの中で、それら有
効なキャラクター文字の後の値は、どんな値が入ってい
ても良い。
ークに付加されるサムネイル画像の情報を示す。ref_th
umbnail_indexフィールドが、0xFFFFでない値の場合、
そのマークにはサムネイル画像が付加されており、その
サムネイル画像は、mark.thmbファイルの中にストアさ
れている。その画像は、mark.thmbファイルの中でref_t
humbnail_indexの値を用いて参照される。ref_thumbnai
l_indexフィールドが、0xFFFF である場合、そのマーク
にはサムネイル画像が付加されていない。
参照して既に説明したので、その説明は省略する。
umbnail Information)について説明する。サムネイル
画像は、menu.thmbファイルまたはmark.thmbファイルに
ストアされる。これらのファイルは同じシンタクス構造
であり、ただ1つのThumbnail()を持つ。menu.thmbファ
イルは、メニューサムネイル画像,すなわちVolumeを代
表する画像、および、それぞれのPlayListを代表する画
像をストアする。すべてのメニューサムネイルは、ただ
1つのmenu.thmbファイルにストアされる。
画像,すなわちマーク点を表すピクチャをストアする。
すべてのPlayListおよびClipに対するすべてのマークサ
ムネイルは、ただ1つのmark.thmbファイルにストアさ
れる。サムネイルは頻繁に追加、削除されるので、追加
操作と部分削除の操作は容易に高速に実行できなければ
ならない。この理由のため、Thumbnail()はブロック構
造を有する。画像のデータはいくつかの部分に分割さ
れ、各部分は一つのtn_blockに格納される。1つの画像
データはは連続したtn_blockに格納される。tn_blockの
列には、使用されていないtn_blockが存在してもよい。
1つのサムネイル画像のバイト長は可変である。
クスを示す図であり、図79は、図78に示したmenu.t
hmbとmark.thmbのシンタクス内のThumbnailのシンタク
スを示す図である。図79に示したThumbnailのシンタ
クスについて説明するに、version_numberは、このThum
bnail()のバージョンナンバーを示す4個のキャラクタ
ー文字である。version_numberは、ISO 646に従って、"
0045"と符号化されなければならない。
らThumbnail()の最後までのMakersPrivateData()のバイ
ト数を示す32ビットの符号なし整数である。tn_block
s_start_addressは、Thumbnail()の先頭のバイトからの
相対バイト数を単位として、最初のtn_blockの先頭バイ
トアドレスを示す32ビットの符号なし整数である。相
対バイト数はゼロからカウントされる。number_of_thum
bnailsは、Thumbnail()の中に含まれているサムネイル
画像のエントリー数を与える16ビットの符号なし整数
である。
て、1つのtn_blockの大きさを与える16ビットの符号な
し整数である。例えば、tn_block_size=1ならば、そ
れは1つのtn_blockの大きさが1024バイトであることを
示す。number_of_tn_blocksは、このThumbnail()中のtn
_blockのエントリ数を表す116ビットの符号なし整数
である。thumbnail_indexは、このthumbnail_indexフィ
ールドから始まるforループ一回分のサムネイル情報で
表されるサムネイル画像のインデクス番号を表す16ビ
ットの符号なし整数である。thumbnail_index として、
0xFFFFという値を使用してはならない。thumbnail_inde
x はUIAppInfoVolume()、UIAppInfoPlayList()、PlayLi
stMark()、およびClipMark()の中のref_thumbnail_inde
xによって参照される。
画像のピクチャフォーマットを表す8ビットの符号なし
整数で、図80に示すような値をとる。表中のDCFとPNG
は”menu.thmb”内でのみ許される。マークサムネイル
は、値"0x00" (MPEG-2 Video I-picture)をとらなけれ
ばならない。
バイト長をバイト単位で示す32ビットの符号なし整数
である。start_tn_block_numberは、サムネイル画像の
データが始まるtn_blockのtn_block番号を表す16ビッ
トの符号なし整数である。サムネイル画像データの先頭
は、tb_blockの先頭と一致していなければならない。tn
_block番号は、0から始まり、tn_blockのfor-ループ中
の変数kの値に関係する。
レーム画枠の水平方向のピクセル数を表す16ビットの
符号なし整数である。y_picture_lengthは、サムネイル
画像のフレーム画枠の垂直方向のピクセル数を表す16
ビットの符号なし整数である。tn_blockは、 サムネイ
ル画像がストアされる領域である。Thumbnail()の中の
すべてのtn_blockは、同じサイズ(固定長)であり、そ
の大きさはtn_block_sizeによって定義される。
うにtn_blockに格納されるかを模式的に表した図であ
る。図81のように、各サムネイル画像データはtn_blo
ckの先頭から始まり、1 tn_blockを超える大きさの場合
は、連続する次のtn_blockを使用してストアされる。こ
のようにすることにより、可変長であるピクチャデータ
が、固定長のデータとして管理することが可能となり、
削除といった編集に対して簡便な処理により対応する事
ができるようになる。
する。AVストリームファイルは、"M2TS"ディレクトリ
(図14)にストアされる。AVストリームファイルに
は、2つのタイプがあり、それらは、Clip AVストリー
ムとBridge-Clip AVストリームファイルである。両方の
AVストリーム共に、これ以降で定義されるDVR MPEG-2ト
ランスポートストリームファイルの構造でなければなら
ない。
ームについて説明する。DVR MPEG-2トランスポートスト
リームの構造は、図82に示すようになっている。AVス
トリームファイルは、DVR MPEG2トランスポートストリ
ームの構造を持つ。DVR MPEG2トランスポートストリー
ムは、整数個のAligned unitから構成される。Alignedu
nitの大きさは、6144 バイト (2048*3 バイト)である。
Aligned unitは、ソースパケットの第1バイト目から始
まる。ソースパケットは、192バイト長である。一つの
ソースパケットは、TP_extra_headerとトランスポート
パケットから成る。TP_extra_headerは、4バイト長で
あり、またトランスポートパケットは、188バイト長で
ある。
ケットから成る。DVR MPEG2トランスポートストリーム
の中の最後のAligned unitも、また32個のソースパケ
ットから成る。よって、DVR MPEG2トランスポートスト
リームは、Aligned unitの境界で終端する。ディスクに
記録される入力トランスポートストリームのトランスポ
ートパケットの数が32の倍数でない時、ヌルパケット
(PID=0x1FFFのトランスポートパケット)を持ったソー
スパケットを最後のAligned unitに使用しなければなら
ない。ファイルシステムは、DVR MPEG2トランスポート
ストリームに余分な情報を付加してはならない。
リームのレコーダモデルを示す。図83に示したレコー
ダは、レコーディングプロセスを規定するための概念上
のモデルである。DVR MPEG-2トランスポートストリーム
は、このモデルに従う。
イミングについて説明する。入力MPEG2トランスポート
ストリームは、フルトランスポートストリームまたはパ
ーシャルトランスポートストリームである。入力される
MPEG2トランスポートストリームは、ISO/IEC13818-1ま
たはISO/IEC13818-9に従っていなければならない。MPEG
2トランスポートストリームのi番目のバイトは、T-STD
(ISO/IEC13818-1で規定されるTransport stream system
target decoder)とソースパケッタイザへ、時刻t(i)に
同時に入力される。Rpkは、トランスポートパケットの
入力レートの瞬時的な最大値である。
波数を発生する。27MHzクロックの周波数は、MPEG-2
トランスポートストリームのPCR (Program Clock Refer
ence)の値にロックされる。arrival time clock counte
r53は、27MHzの周波数のパルスをカウントするバイ
ナリーカウンターである。Arrival_time_clock(i)は、
時刻t(i)におけるArrival time clock counterのカウン
ト値である。
ンスポートパケットにTP_extra_headerを付加し、ソー
スパケットを作る。Arrival_time_stampは、トランスポ
ートパケットの第1バイト目がT-STDとソースパケッタ
イザの両方へ到着する時刻を表す。Arrival_time_stamp
(k)は、次式で示されるようにArrival_time_clock(k)の
サンプル値であり、ここで、kはトランスポートパケッ
トの第1バイト目を示す。 arrival_time_stamp(k) = arrival_time_clock(k)% 230
パケットの時間間隔が、230/27000000秒(約40秒)以上
になる場合、その2つのトランスポートパケットのarri
val_time_stampの差分は、230/27000000秒になるように
セットされるべきである。レコーダは、そのようになる
場合に備えてある。
ートストリームのビットレートをスムージングする。ス
ムージングバッファは、オーバーフロウしてはならな
い。Rmaxは、スムージングバッファが空でない時のスム
ージングバッファからのソースパケットの出力ビットレ
ートである。スムージングバッファが空である時、スム
ージングバッファからの出力ビットレートはゼロであ
る。
ムのレコーダモデルのパラメータについて説明する。Rm
axという値は、AVストリームファイルに対応するClipIn
fo()において定義されるTS_recording_rateによって与
えられる。この値は、次式により算出される。 Rmax = TS_recording_rate * 192/188 TS_recording_rateの値は、bytes/secondを単位とする
大きさである。
ンスポートストリームの場合、Rpkは、AVストリームフ
ァイルに対応するClipInfo()において定義されるTS_rec
ording_rateに等しくなければならない。入力トランス
ポートストリームがSESFトランスポートストリームでな
い場合、この値はMPEG-2 transport streamのデスクリ
プター,例えばmaximum_bitrate_descriptorやpartial_
transport_stream_descriptorなど、において定義され
る値を参照しても良い。
ポートストリームがSESFトランスポートストリームの場
合、スムージングバッファの大きさはゼロである。入力
トランスポートストリームがSESFトランスポートストリ
ームでない場合、スムージングバッファの大きさはMPEG
-2 transport streamのデスクリプター、例えばsmoothi
ng_buffer_descriptor、short_smoothing_buffer_descr
iptor、partial_transport_stream_descriptorなどにお
いて定義される値を参照しても良い。
ヤ)は、十分なサイズのバッファを用意しなければなら
ない。デフォールトのバッファサイズは、1536 bytes
である。
ムのプレーヤモデルについて説明する。図84は、DVR
MPEG-2トランスポートストリームのプレーヤモデルを示
す図である。これは、再生プロセスを規定するための概
念上のモデルである。DVR MPEG-2トランスポートストリ
ームは、このモデルに従う。
生する。27MHz周波数の誤差範囲は、+/-30 ppm (2700
0000 +/- 810 Hz)でなければならない。arrival time c
lock counter62は、27MHzの周波数のパルスをカウ
ントするバイナリーカウンターである。Arrival_time_c
lock(i)は、時刻t(i)におけるArrival time clock coun
terのカウント値である。
スムージングバッファがフルでない時のスムージングバ
ッファへのソースパケットの入力ビットレートである。
スムージングバッファがフルである時、スムージングバ
ッファへの入力ビットレートはゼロである。
イミングを説明するに、現在のソースパケットのarriva
l_time_stampがarrival_time_clock(i)のLSB 30ビッ
トの値と等しい時、そのソースパケットのトランスポー
トパケットは、スムージングバッファから引き抜かれ
る。Rpkは、トランスポートパケットレートの瞬時的な
最大値である。スムージングバッファは、アンダーフロ
ウしてはならない。
レーヤモデルのパラメータについては、上述したDVR MP
EG-2トランスポートストリームのレコーダモデルのパラ
メータと同一である。
示す図である。transport_packet()は、ISO/IEC 13818-
1で規定されるMPEG-2トランスポートパケットである。
図85に示したSource packetのシンタクス内のTP_Extr
a_headerのシンタクスを図86に示す。図86に示した
TP_Extra_headerのシンタクスについて説明するに、cop
y_permission_indicatorは、トランスポートパケットの
ペイロードのコピー制限を表す整数である。コピー制限
は、copy free、no more copy、copy once、またはcopy
prohibitedとすることができる。図87は、copy_perm
ission_indicatorの値と、それらによって指定されるモ
ードの関係を示す。
トランスポートパケットに付加される。IEEE1394デジタ
ルインタフェースを使用して入力トランスポートストリ
ームを記録する場合、copy_permission_indicatorの値
は、IEEE1394 isochronouspacket headerの中のEMI (En
cryption Mode Indicator)の値に関連付けても良い。IE
EE1394デジタルインタフェースを使用しないで入力トラ
ンスポートストリームを記録する場合、copy_permissio
n_indicatorの値は、トランスポートパケットの中に埋
め込まれたCCIの値に関連付けても良い。アナログ信号
入力をセルフエンコードする場合、copy_permission_in
dicatorの値は、アナログ信号のCGMS-Aの値に関連付け
ても良い。
持つ整数値である。
AVストリームは、上述したような定義がされるDVR MPEG
-2トランスポートストリームの構造を持たねばならな
い。arrival_time_clock(i)は、Clip AVストリームの中
で連続して増加しなければならない。Clip AVストリー
ムの中にシステムタイムベース(STCベース)の不連続
点が存在したとしても、そのClip AVストリームのarriv
al_time_clock(i)は、連続して増加しなければならな
い。
のarrival_time_clock(i)の差分の最大値は、26時間
でなければならない。この制限は、MPEG2トランスポー
トストリームの中にシステムタイムベース(STCベー
ス)の不連続点が存在しない場合に、Clip AVストリー
ムの中で同じ値のPTS(Presentation Time Stamp)が決し
て現れないことを保証する。MPEG2システムズ規格は、P
TSのラップアラウンド周期を233/90000秒(約26.5時間).
と規定している。
に、Bridge-Clip AVストリームは、上述したような定義
がされるDVR MPEG-2トランスポートストリームの構造を
持たねばならない。Bridge-Clip AVストリームは、1つ
のアライバルタイムベースの不連続点を含まなければな
らない。アライバルタイムベースの不連続点の前後のト
ランスポートストリームは、後述する符号化の制限に従
わなければならず、かつ後述するDVR-STDに従わなけれ
ばならない。
ayItem間のビデオとオーディオのシームレス接続をサポ
ートする。PlayItem間をシームレス接続にすることは、
プレーヤ/レコーダに"データの連続供給"と"シームレ
スな復号処理"を保証する。"データの連続供給"とは、
ファイルシステムが、デコーダにバッファのアンダーフ
ロウを起こさせる事のないように必要なビットレートで
データを供給する事を保証できることである。データの
リアルタイム性を保証して、データをディスクから読み
出すことができるように、データが十分な大きさの連続
したブロック単位でストアされるようにする。
が、デコーダの再生出力にポーズやギャップを起こさせ
る事なく、ディスクに記録されたオーディオビデオデー
タを表示できることである。
するAVストリームについて説明する。先行するPlayItem
と現在のPlayItemの接続が、シームレス表示できるよう
に保証されているかどうかは、現在のPlayItemにおいて
定義されているconnection_conditionフィールドから判
断することができる。PlayItem間のシームレス接続は、
Bridge-Clipを使用する方法と使用しない方法がある。
先行するPlayItemと現在のPlayItemの関係を示してい
る。図88においては、プレーヤが読み出すストリーム
データが、影をつけて示されている。図88に示したTS
1は、Clip1(Clip AVストリーム)の影を付けられたス
トリームデータとBridge-ClipのRSPN_arrival_time_dis
continuityより前の影を付けられたストリームデータか
ら成る。
ータは、先行するPlayItemのIN_time(図88においてI
N_time1で図示されている)に対応するプレゼンテーシ
ョンユニットを復号する為に必要なストリームのアドレ
スから、RSPN_exit_from_previous_Clipで参照されるソ
ースパケットまでのストリームデータである。TS1に含
まれるBridge-ClipのRSPN_arrival_time_discontinuity
より前の影を付けられたストリームデータは、Bridge-C
lipの最初のソースパケットから、RSPN_arrival_time_d
iscontinuityで参照されるソースパケットの直前のソー
スパケットまでのストリームデータである。
AVストリーム)の影を付けられたストリームデータとB
ridge-ClipのRSPN_arrival_time_discontinuity以後の
影を付けられたストリームデータから成る。TS2に含ま
れるBridge-ClipのRSPN_arrival_time_discontinuity以
後の影を付けられたストリームデータは、RSPN_arrival
_time_discontinuityで参照されるソースパケットか
ら、Bridge-Clipの最後のソースパケットまでのストリ
ームデータである。TS2のClip2の影を付けられたストリ
ームデータは、RSPN_enter_to_current_Clipで参照され
るソースパケットから、現在のPlayItemのOUT_time(図
88においてOUT_time2で図示されている)に対応する
プレゼンテーションユニットを復号する為に必要なスト
リームのアドレスまでのストリームデータである。
の先行するPlayItemと現在のPlayItemの関係を示してい
る。この場合、プレーヤが読み出すストリームデータ
は、影をつけて示されている。図89におけるTS1は、C
lip1 (Clip AVストリーム)の影を付けられたストリーム
データから成る。TS1のClip1の影を付けられたストリー
ムデータは、先行するPlayItemのIN_time(図89にお
いてIN_time1で図示されている)に対応するプレゼンテ
ーションユニットを復号する為に必要なストリームのア
ドレスから始まり、Clip1の最後のソースパケットまで
のデータである。また、図89におけるTS2は、Clip2
(Clip AVストリーム)の影を付けられたストリームデー
タから成る。
ータは、Clip2の最初のソースパケットから始まり、現
在のPlayItemのOUT_time(図89においてOUT_time2で
図示されている)に対応するプレゼンテーションユニッ
トを復号する為に必要なストリームのアドレスまでのス
トリームデータである。
ースパケットの連続したストリームである。次に、TS1
とTS2のストリーム規定と、それらの間の接続条件につ
いて考える。まず、シームレス接続のための符号化制限
について考える。トランスポートストリームの符号化構
造の制限として、まず、TS1とTS2の中に含まれるプログ
ラムの数は、1でなければならない。TS1とTS2の中に含
まれるビデオストリームの数は、1でなければならな
い。TS1とTS2の中に含まれるオーディオストリームの数
は、2以下でなければならない。TS1とTS2の中に含まれ
るオーディオストリームの数は、等しくなければならな
い。TS1および/またはTS2の中に、上記以外のエレメン
タリストリームまたはプライベートストリームが含まれ
ていても良い。
明する。図90は、ピクチャの表示順序で示すシームレ
ス接続の例を示す図である。接続点においてビデオスト
リームをシームレスに表示できるためには、OUT_time1
(Clip1のOUT_time)の後とIN_time2(Clip2のIN_tim
e)の前に表示される不必要なピクチャは、接続点付近
のClipの部分的なストリームを再エンコードするプロセ
スにより、除去されなければならない。
geSequenceを使用してシームレス接続を実現する例を、
図91に示す。RSPN_arrival_time_discontinuityより
前のBridge-Clipのビデオストリームは、図90のClip1
のOUT_time1に対応するピクチャまでの符号化ビデオス
トリームから成る。そして、そのビデオストリームは先
行するClip1のビデオストリームに接続され、1つの連
続でMPEG2規格に従ったエレメンタリストリームとなる
ように再エンコードされている。
nuity以後のBridge-Clipのビデオストリームは、図90
のClip2のIN_time2に対応するピクチャ以後の符号化ビ
デオストリームから成る。そして、そのビデオストリー
ムは、正しくデコード開始する事ができて、これに続く
Clip2のビデオストリームに接続され、1つの連続でMPE
G2規格に従ったエレメンタリストリームとなるように再
エンコードされている。Bridge-Clipを作るためには、
一般に、数枚のピクチャは再エンコードしなければなら
ず、それ以外のピクチャはオリジナルのClipからコピー
することができる。
を使用しないでシームレス接続を実現する例を図92に
示す。Clip1のビデオストリームは、図90のOUT_time1
に対応するピクチャまでの符号化ビデオストリームから
成り、それは、1つの連続でMPEG2規格に従ったエレメ
ンタリストリームとなるように再エンコードされてい
る。同様にして、Clip2のビデオストリームは、図90
のClip2のIN_time2に対応するピクチャ以後の符号化ビ
デオストリームから成り、それは、一つの連続でMPEG2
規格に従ったエレメンタリストリームとなるように再エ
ンコードされている。
明するに、まず、TS1とTS2のビデオストリームのフレー
ムレートは、等しくなければならない。TS1のビデオス
トリームは、sequence_end_codeで終端しなければなら
ない。TS2のビデオストリームは、Sequence Header、GO
P Header、そしてI-ピクチャで開始しなければならな
い。TS2のビデオストリームは、クローズドGOPで開始し
なければならない。
プレゼンテーションユニット(フレームまたはフィール
ド)は、接続点を挟んで連続でなければならない。接続
点において、フレームまたはフィールドのギャップがあ
ってはならない。接続点において、トップ―ボトムのフ
ィールドシーケンスは連続でなければならない。3-2プ
ルダウンを使用するエンコードの場合は、"top_field_f
irst" および "repeat_first_field"フラグを書き換え
る必要があるかもしれない,またはフィールドギャップ
の発生を防ぐために局所的に再エンコードするようにし
ても良い。
について説明するに、TS1とTS2のオーディオのサンプリ
ング周波数は、同じでなければならない。TS1とTS2のオ
ーディオの符号化方法(例.MPEG1レイヤ2, AC-3, SESF
LPCM, AAC)は、同じでなければならない。
符号化制限について説明するに、TS1のオーディオスト
リームの最後のオーディオフレームは、TS1の最後の表
示ピクチャの表示終了時に等しい表示時刻を持つオーデ
ィオサンプルを含んでいなければならない。TS2のオー
ディオストリームの最初のオーディオフレームは、TS2
の最初の表示ピクチャの表示開始時に等しい表示時刻を
持つオーディオサンプルを含んでいなければならない。
ションユニットのシーケンスにギャップがあってはなら
ない。図93に示すように、2オーディオフレーム区間
未満のオーディオプレゼンテーションユニットの長さで
定義されるオーバーラップがあっても良い。TS2のエレ
メンタリストリームを伝送する最初のパケットは、ビデ
オパケットでなければならない。接続点におけるトラン
スポートストリームは、後述するDVR-STDに従わなくて
はならない。
明するに、TS1とTS2は、それぞれの中にアライバルタイ
ムベースの不連続点を含んではならない。
合にのみ適用される。TS1の最後のソースパケットとTS2
の最初のソースパケットの接続点においてのみ、Bridge
-ClipAVストリームは、ただ1つのアライバルタイムベ
ースの不連続点を持つ。ClipInfo()において定義される
RSPN_arrival_time_discontinuityが、その不連続点の
アドレスを示し、それはTS2の最初のソースパケットを
参照するアドレスを示さなければならない。
RSPN_exit_from_previous_Clipによって参照されるソー
スパケットは、Clip1の中のどのソースパケットでも良
い。それは、Aligned unitの境界である必要はない。Br
idgeSequenceInfo()において定義されるRSPN_enter_to_
current_Clipによって参照されるソースパケットは、Cl
ip2の中のどのソースパケットでも良い。それは、Align
ed unitの境界である必要はない。
するPlayItemのOUT_time(図88、図89において示さ
れるOUT_time1)は、TS1の最後のビデオプレゼンテーシ
ョンユニットの表示終了時刻を示さなければならない。
現在のPlayItemのIN_time(F図88、図89において示
されるIN_time2)は、TS2の最初のビデオプレゼンテー
ションユニットの表示開始時刻を示さなければならな
い。
ケーションの制限について、図94を参照して説明する
に、シームレス接続は、ファイルシステムによってデー
タの連続供給が保証されるように作られなければならな
い。これは、Clip1(Clip AVストリームファイル)とCl
ip2(Clip AVストリームファイル)に接続されるBridge
-Clip AVストリームを、データアロケーション規定を満
たすように配置することによって行われなければならな
い。
1(Clip AVストリームファイル)のストリーム部分が、
ハーフフラグメント以上の連続領域に配置されているよ
うに、RSPN_exit_from_previous_Clipが選択されなけれ
ばならない。Bridge-Clip AVストリームのデータ長は、
ハーフフラグメント以上の連続領域に配置されるよう
に、選択されなければならない。RSPN_enter_to_curren
t_Clip以後のClip2(Clip AVストリームファイル)のス
トリーム部分が、ハーフフラグメント以上の連続領域に
配置されているように、RSPN_enter_to_current_Clipが
選択されなければならない。
続する場合のデータアロケーションの制限について、図
95を参照して説明するに、シームレス接続は、ファイ
ルシステムによってデータの連続供給が保証されるよう
に作られなければならない。これは、Clip1(Clip AVス
トリームファイル)の最後の部分とClip2(Clip AVスト
リームファイル)の最初の部分を、データアロケーショ
ン規定を満たすように配置することによって行われなけ
ればならない。
後のストリーム部分が、ハーフフラグメント以上の連続
領域に配置されていなければならない。Clip2(Clip AV
ストリームファイル)の最初のストリーム部分が、ハー
フフラグメント以上の連続領域に配置されていなければ
ならない。
は、DVR MPEG2トランスポートストリームの生成および
検証の際におけるデコード処理をモデル化するための概
念モデルである。また、DVR-STDは、上述したシームレ
ス接続された2つのPlayItemによって参照されるAVスト
リームの生成および検証の際におけるデコード処理をモ
デル化するための概念モデルでもある。
示したモデルには、DVR MPEG-2トランスポートストリー
ムプレーヤモデルが構成要素として含まれている。n, T
Bn,MBn, EBn, TBsys, Bsys, Rxn, Rbxn, Rxsys, Dn, Ds
ys, OnおよびPn(k)の表記方法は、ISO/IEC13818-1のT-S
TDに定義されているものと同じである。すなわち、次の
通りである。nは、エレメンタリストリームのインデク
ス番号である。TBnは、エレメンタリストリームnのトラ
ンスポートバッファでる。
ッファである。ビデオストリームについてのみ存在す
る。EBnは、エレメンタリストリームnのエレメンタリス
トリームバッファである。ビデオストリームについての
み存在する。TBsysは、復号中のプログラムのシステム
情報のための入力バッファである。Bsysは、復号中のプ
ログラムのシステム情報のためのシステムターゲットデ
コーダ内のメインバッファである。Rxnは、データがTBn
から取り除かれる伝送レートである。Rbxnは、PESパケ
ットペイロードがMBnから取り除かれる伝送レートであ
る。ビデオストリームについてのみ存在する。
伝送レートである。Dnは、エレメンタリストリームnの
デコーダである。Dsysは、復号中のプログラムのシステ
ム情報に関するデコーダである。Onは、ビデオストリー
ムnのre-ordering bufferである。Pn(k)は、エレメンタ
リストリームnのk番目のプレゼンテーションユニットで
ある。
て説明する。単一のDVR MPEG-2トランスポートストリー
ムを再生している間は、トランスポートパケットをTB1,
TBnまたはTBsysのバッファへ入力するタイミングは、
ソースパケットのarrival_time_stampにより決定され
る。TB1, MB1, EB1, TBn, Bn, BsysおよびTBsysのバッ
ファリング動作の規定は、ISO/IEC 13818-1に規定され
ているT-STDと同じである。復号動作と表示動作の規定
もまた、ISO/IEC 13818-1に規定されているT-STDと同じ
である。
いる間のデコーディングプロセスについて説明する。こ
こでは、シームレス接続されたPlayItemによって参照さ
れる2つのAVストリームの再生について説明をすること
にし、以後の説明では、上述した(例えば、図88に示
した)TS1とTS2の再生について説明する。TS1は、先行
するストリームであり、TS2は、現在のストリームであ
る。
それにシームレスに接続された次のAVストリーム(TS
2)へと移る時のトランスポートパケットの入力,復
号,表示のタイミングチャートを示す。所定のAVストリ
ーム(TS1)からそれにシームレスに接続された次のAV
ストリーム(TS2)へと移る間には、TS2のアライバルタ
イムベースの時間軸(図97においてATC2で示される)
は、TS1のアライバルタイムベースの時間軸(図97に
おいてATC1で示される)と同じでない。
軸(図97においてSTC2で示される)は、TS1のシステ
ムタイムベースの時間軸(図97においてSTC1で示され
る)と同じでない。ビデオの表示は、シームレスに連続
していることが要求される。オーディオのプレゼンテー
ションユニットの表示時間にはオーバーラップがあって
も良い。
する。時刻T1までの時間、すなわち、TS1の最後のビデ
オパケットがDVR-STDのTB1に入力終了するまでは、DVR-
STDのTB1、TBn またはTBsysのバッファへの入力タイミ
ングは、TS1のソースパケットのarrival_time_stampに
よって決定される。
te(TS1)のビットレートでDVR-STDのTBnまたはTBsysのバ
ッファへ入力されなければならない。ここで、TS_recor
ding_rate(TS1)は、Clip1に対応するClipInfo()におい
て定義されるTS_recording_rateの値である。TS1の最後
のバイトがバッファへ入力する時刻は、時刻T2であ
る。従って、時刻T1からT2までの区間では、ソースパ
ケットのarrival_time_stampは無視される。
のトランスポートパケットのバイト数とすると、時刻T
1乃至T2までの時間DT1は、N1バイトがTS_recording_ra
te(TS1)のビットレートで入力終了するために必要な時
間であり、次式により算出される。 ΔT1=T2−T1=N1 / TS_recording_rate (TS1) 時刻T1乃至T2までの間は、RXnとRXsysの値は共に、TS
_recording_rate(TS1)の値に変化する。このルール以外
のバッファリング動作は、T-STDと同じである。
counterは、TS2の最初のソースパケットのarrival_time
_stampの値にリセットされる。DVR-STDのTB1, TBn また
はTBsysのバッファへの入力タイミングは、TS2のソース
パケットのarrival_time_stampによって決定される。RX
nとRXsysは共に、T-STDにおいて定義されている値に変
化する。
システムデータバッファリングについて説明するに、オ
ーディオデコーダとシステムデコーダは、時刻T1からT
2までの区間の入力データを処理することができるよう
に、T-STDで定義されるバッファ量に加えて付加的なバ
ッファ量(約1秒分のデータ量)が必要である。
ついて説明するに、ビデオプレゼンテーションユニット
の表示は、接続点を通して、ギャップなしに連続でなけ
ればならない。ここで、STC1は、TS1のシステムタイム
ベースの時間軸(図97ではSTC1と図示されている)と
し、STC2は、TS2のシステムタイムベースの時間軸(図
97ではSTC2と図示されている。正確には、STC2は、TS
2の最初のPCRがT-STDに入力した時刻から開始する。)
とする。
に決定される。PTS1 endは、TS1の最後のビデオプレゼン
テーションユニットに対応するSTC1上のPTSであり、PTS
2 sta rtは、TS2の最初のビデオプレゼンテーションユニ
ットに対応するSTC2上のPTSであり、Tppは、TS1の最後
のビデオプレゼンテーションユニットの表示期間とする
と、2つのシステムタイムベースの間のオフセットSTC_
deltaは、次式により算出される。 STC_delta = PTS1 end + Tpp - PTS2 start
ングについて説明するに、接続点において、オーディオ
プレゼンテーションユニットの表示タイミングのオーバ
ーラップがあっても良く、それは0乃至2オーディオフ
レーム未満である(図97に図示されている"audio ove
rlap"を参照)。どちらのオーディオサンプルを選択す
るかということと、オーディオプレゼンテーションユニ
ットの表示を接続点の後の補正されたタイムベースに再
同期することは、プレーヤ側により設定されることであ
る。
て説明するに、時刻T5において、TS1の最後のオーディ
オプレゼンテーションユニットが表示される。システム
タイムクロックは、時刻T2からT5の間にオーバーラッ
プしていても良い。この区間では、DVR-STDは、システ
ムタイムクロックを古いタイムベースの値(STC1)と新
しいタイムベースの値(STC2)の間で切り替える。STC2
の値は、次式により算出される。 STC2=STC1−STC_delta
る。STC11 video_endは、TS1の最後のビデオパケットの
最後のバイトがDVR-STDのTB1へ到着する時のシステムタ
イムベースSTC1上のSTCの値である。STC22 video_start
は、TS2の最初のビデオパケットの最初のバイトがDVR-S
TDのTB1へ到着する時のシステムタイムベースSTC2上のS
TCの値である。STC21 video_endは、STC11 video_end の
値をシステムタイムベースSTC2上の値に換算した値であ
る。STC21 video_endは、次式により算出される。 STC21 video_end = STC11 video_end - STC_delta
満たす事が要求される。まず、TS2の最初のビデオパケ
ットのTB1への到着タイミングは、次に示す不等式を満
たさなければならない。そして、次に示す不等式を満た
さなければならない。 STC22 video_start > STC21 video_end + ΔT1 この不等式が満たされるように、Clip1および、また
は、Clip2の部分的なストリームを再エンコードおよ
び、または、再多重化する必要がある場合は、その必要
に応じて行われる。
たシステムタイムベースの時間軸上において、TS1から
のビデオパケットの入力とそれに続くTS2からのビデオ
パケットの入力は、ビデオバッファをオーバーフローお
よびアンダーフローさせてはならない。
に基づく事により、記録媒体に記録されているデータの
内容、再生情報などを適切に管理することができ、もっ
て、ユーザが再生時に適切に記録媒体に記録されている
データの内容を確認したり、所望のデータを簡便に再生
できるようにすることができる。
スの中にあるtime_controlled_flagを1にセットする場
合のAVストリームファイルの記録について、詳細な内
容を説明する。time_controlled_flagを1にセットする
場合、AVストリームの時間経過とAVストリームのデ
ータバイト量が、次の関係にあることを示す。すなわ
ち、AVストリームの時間経過とAVストリームのデー
タバイト量との関係が、所定の誤差の範囲内で比例す
る、ことを保証する。 TS_average_rate*192/188 * (t -α)<= AV_file_size(t) <= TS_average_rate*192/188 * (t +α) ...式(1)
trolled_flagの説明の中で示した式とは、すこし形式が
違うが本質的には同じである。
ムファイル(DVRトランスポートストリームファイ
ル)の平均ビットレートをbytes/second の単位で表し
たものであり、ClipInfoの中の同名のフィールドにより
示される。また、tは、AVストリームファイルの最初の
ソースパケットからのアライバルライムベースの経過時
刻を秒単位で示す。AV_file_size(t)は、 時刻tにおけ
るAVストリームファイルのサイズをバイト単位で表した
ものである。αは、所定の一定値であり、例えば、300
秒である。
ションによって所定に値に決める。例えば、長時間録画
モード(LPモード),標準録画モード(SPモー
ド)、高画質録画モード(HQモード)といった記録モ
ードに応じて、それぞれのモード用のTS_average_rate
値を決める。
ァイルが記録されている場合、そのストリームのある時
間分だけ部分的にストリームを消去すると、消去した時
間分だけ前記ストリームのTS_average_rateで示される
ビットレートで記録可能な空き領域をディスク上に作れ
ることを保証できる。例えば、SPモードのAVストリ
ームファイルのある時間分だけ部分的にストリームを消
去すると、消去した時間分だけ、同じSPモードで記録
可能な空き領域をディスク上に作ることができる。
Vストリームのデータバイト量との関係が、所定の誤差
の範囲内で比例するように、可変ビットレートを制御す
る場合の、図1の記録再生装置1のAVエンコーダ15の動
作を説明するブロック図である。図98と図1で、同じ
番号がつけられているブロックは同一のものである。
ユーザーからLP, SPモードなどの記録モードが制御部23
に入力される。制御部23は記録モードに応じて、記録す
るAVストリーム(DVRトランスポートストリーム)の
多重化ビットレート、およびビデオ符号化の平均ビット
レートを設定する(図99のフローチャートのステップ
S20参照)。
にセットし、多重化ストリームの平均ビットレートをTS
_average_rateとし、また多重化ビットレートをTS_reco
rding_rateとする。制御部23は、time_controlled_fl
ag,TS_recording_rateとTS_average_rateをClipInfoに
設定したClip Informationファイルのデータベースを出
力する。Clip Informationファイルは、図1で説明した
ようにECC符号化部20の処理を通して、記録媒体に記
録される。
合は、端子11からビデオが入力される。または、ディ
ジタル放送入力のビデオをトランスコードする場合は、
AVデコーダ27からのビデオが入力される。入力ビデオ
は、ビデオエンコーダ151へ入力される。制御部23
は、所定時間あたりのビデオに対する割り当て符号化ビ
ット量を計算して、それをビデオエンコーダに指定す
る。ビデオエンコーダ115は、所定時間あたりのビデ
オをエンコードして、実際に発生した符号化ビット量を
制御部23へ入力する。例えば、所定時間の大きさは、
ビデオのGOPであり、0.5秒である。制御部23
は、エンコーダから入力される実際に発生した符号化ビ
ット量のエンコード開始後の累計値に基づいて、AVス
トリームの時間経過とAVストリームのデータバイト量
との関係が、所定の誤差の範囲内で比例するように、ビ
デオ符号化の可変ビットレートの制御をして、次の所定
時間あたりのビデオに対する割り当て符号化ビット量を
計算する。また、この時に、制御部23が、エンコーダ
からビデオの符号化難易度(動きベクトル予測の予測残
差の大きさ、DCT係数の量子化スケールの大きさ、な
ど)を供給されることができれば、さらに高画質な可変
ビットレートを実現できる。すなわち、ビデオの符号化
難易度が高いほど、所定時間あたりのビデオに対する割
り当て符号化ビット量を大きくするように制御する。
ームをマルチプレクサ16へ入力する。マルチプレクサ
16へはまた、オーディオストリームとAV同期等のシス
テム情報(S)が入力される。また、オーディオ入力のエ
ンコード処理の流れ、および、AV同期等のシステム情報
(S)については、図1の説明と同じである。
ディオストリームを、所定の多重化ビットレートのトラ
ンスポートストリームに多重化する。この時、ビデオと
オーディオのパケット化は、MPEG2トランスポート
ストリームのシステムターゲットデコーダ(T−ST
D)を破綻させないように制御しなければならない。T
−STDの制限によって、ビデオのアクセスユニット
(符号化されたI, P, Bのピクチャ)およびオーディオ
のアクセスユニット(オーディオフレーム)をパケット
化することができない場合、マルチプレクサ16は、ヌ
ルパケット(パケットIDが、0x1FFFであるパケット)
を発生しないように多重化する。この多重化制御によ
り、連続するトランスポートパケットの時間間隔は不規
則になり、パケットは間欠的に発生する。
スポートパケットは、ソースパケッタイザ19へ入力さ
れる。ソースパケッタイザ19は、各トランスポートパ
ケットにアライバルタイムスタンプを付加して、ソース
パケット化する。そして、ソースパケット列を前詰し
て、AVストリームファイルを生成する。AVストリームフ
ァイルは、図1で説明したようにECC符号化部20の処
理を通して、記録媒体に記録される。
Vストリームのデータバイト量との関係が、所定の誤差
の範囲内で比例することを保証する符号化モード(time
_controlled_flag=1)において、ビデオを可変ビットレ
ート符号化して、AVストリームを記録する動作を説明す
るフローチャートである。
スポートストリームの多重化ビットレートTS_recording
_rateおよびビデオ符号化の平均ビットレートを設定す
る。
verage_rateから、オーディオ符号化の一定のビットレ
ートと多重化のオーバヘッドのビットレートを差し引い
た値とする。ここで、TS_average_rateは、記録器のア
プリケーション(LP, SPモードなど)によって所定に値
に決められる。
トレート符号化の最大ビットレートに、オーディオ符号
化の一定のビットレートと多重化のオーバヘッドのビッ
トレートを加えた値よりも大きい値である。
ストリームを、あらかじめ設定した所定の時間区間毎に
所定の平均ビットレートが保証される様に、可変ビット
レートでエンコードするようにビデオエンコーダ151
を制御する。
スポートパケット化するエレメンタリストリームがない
場合にヌルパケットを発生しないようにマルチプレクサ
16を制御する。この多重化制御により、連続する2個
のトランスポートパケットの時間間隔は不規則になり、
パケットは間欠的に発生する。
ンスポートパケットにアライバルタイムスタンプを付加
して、ソースパケット化するように、ソースパケッタイ
ザ19を制御し、そして、ソースパケット列を前詰し
て、AVストリームファイルとして記録するように制御す
る。
する場合のMPEGのVBV(Video Buffe
ring Verifier)の制御方法について説明
する。VBVは、MPEGが規定する理論的なデコーダモデ
ルである(図100を参照)。MPEGビデオエンコー
ダは、VBVを正しく動作させるようにビデオストリー
ムをエンコードしなければならない。これにより、エン
コード方法を制限する(主に量子化制御およびピクチャ
のビット量の制限)。VBVの持つバッファをVBVバッファ
と呼ぶ。これは現実のデコーダに理論上、最低必要なバ
ッファサイズである。MPEG2メインプロファイルメ
インレベルの場合、VBVバッファサイズは、1.75 Mbits
である。
は、一般に、図101で示す方法が広く知られている。
すなわち、図101は、VBVバッファに空きがあるとき
は、バッファへの入力ビットレートがVBR(Variable Bit
-Rate、可変ビットレート)の最大ビットレートであり、
VBVバッファのビット占有量がフルの場合は、バッファ
への入力ビットレートがゼロになる場合のVBV制御を説
明する図である。図101において、右上がりの線の傾
きは、VBRの最大ビットレートを示し、VBVバッファに空
きがあるときは、VBRの最大ビットレートでバッファ占
有量が増える。また、VBVバッファのビット占有量がフ
ルの場合は、バッファへの入力ビットレートがゼロとな
り、バッファ占有量は変わらない。横軸は時間軸であ
り、T1は一つのデコード時刻を示し、時刻T1において図
示するT1の時刻のピクチャが瞬時にデコードされて、
バッファ占有量が減少する。以後、所定の時間間隔で同
様にして、ピクチャがデコードされて、バッファ占有量
が減少する。この図101で示す方法では、ビデオエン
コーダがビデオストリーム中にスタッフィングバイトを
発生することはない。
02に示すように制御する。すなわち、所定の時間(例
えば、GOP)毎にビットレートを変更する可変ビット
レートにおいて、所定の時間内ではCBR(Constant Bit-R
ate、固定ビットレート)のVBV制御を行う。図102
は、GOP(例えば、0.5秒のビデオシーケンス)内でCBR
の場合のVBV制御を示す。すなわち、VBVバッファへの入
力ビットレートが、現在のGOPの符号化ビットレートで
あり、VBVバッファがオーバーフローしないようにスタ
ッフィングバイトを挿入する場合のVBV制御を説明する
図である。
の判断と、挿入する場合のスタッフィングバイトの量の
計算は、次の手順で行う。以下の説明において、 VBV_BUFFER_SIZE = 1.75*1024*1024 bit gop_bit_rate: GOP毎のビットレート [bit/second] とする。
ト量の計算。図102の時刻d1のピクチャを例として説
明する。まず、時刻d1のピクチャをVBVがデコードす
る直前のVBVバッファのビット占有量vbv_bを得る。
次に、ビット占有量vbv_bに、時刻d1からその次のピク
チャのデコード時刻d2までの間(tau)にビットレートg
op_bit_rateで入力されるビット量を加えた値tmpを計算
する。現在、符号化するピクチャの最低ビット量min_pi
cture_bitは、tmp と VBV_BUFFER_SIZEから次のように
計算できる。 tmp = vbv_b + gop_bit_rate*tau min_picture_bit = tmp - VBV_BUFFER_SIZE
が必要かのチェック。現在のピクチャの実際の符号化ビ
ットgen_picture_bitが、min_picture_bitより小さい場
合は、次に示す計算式で示す大きさのスタッフィングバ
イト発生する。現在符号化したpictureの後にnum_stuff
ing_byteの数のstuffing bytesをビデオエンコーダが符
号化する。一つのスタッフィングバイトは、8ビットの"
0000 0000"の符号である。 if (gen_picture_bit < min_picture_bit) num_stuffing_byte=(min_picture_bit-gen_picture_bit
+4)/8
コーダが所定時間のビデオに割り当てられたビット量を
使うように制御することを目的として、VBVバッファへ
の入力ビットレートが現在のGOPの符号化ビットレート
であり、VBVバッファがオーバーフローしないようにビ
デオエンコーダがスタッフィングバイトを発生する。
ンセプトである、AVストリームの時間経過とAVスト
リームのデータバイト量との関係が図103に示すよう
に、所定の誤差範囲内で比例することを保証するため
に、有効である。図101に示すVBV制御を使うと、
入力ビデオの中に長い時間の静止画像があると、図10
3の関係を保証できなくなる。すなわち、静止画像は情
報量が比較的小さいため、その情報量よりも符号化の割
り当てビット量を大きくしても、実際に符号化して発生
するビット量はある比較的小さな値に飽和してしまう。
したがって、この場合、AVストリームの時間経過とA
Vストリームのデータバイト量の関係が図104に示す
ように、比例しない。このような場合でも、図102に
示すVBV制御を使えば、ビデオエンコーダが所定時間
のビデオに割り当てられたビット量を使うように制御す
ることを目的として、VBVバッファへの入力ビットレー
トが現在のGOPの符号化ビットレートであり、VBVバッフ
ァがオーバーフローしないようにビデオエンコーダがス
タッフィングバイトを発生するので、AVストリームの
時間経過とAVストリームのデータバイト量との関係が
図103に示すように、所定の誤差範囲内でほぼ比例す
ることを保証できる。
のAVストリームを消去しても、その部分の占めるデー
タバイト量は、平均ビットレートに消去時間を掛けたデ
ータサイズよりも小さいため、消去した時間分だけ前記
ストリームのTS_average_rateで示されるビットレート
で記録可能な空き領域をディスク上に作れることができ
ない。一方、図103の場合、AVストリームのある時
間分だけ部分的にストリームを消去すると、消去した時
間分だけ前記ストリームのTS_average_rateで示される
ビットレートで記録可能な空き領域をディスク上に作れ
ることができる。
の処理における、ビデオの可変ビットレート制御の処理
の詳細を説明するフローチャートである。
に初期値SV1をセットする。本発明の可変ビットレート
制御は、AVストリームの時間経過とAVストリームの
データバイト量との関係が所定の誤差範囲内で比例する
ことを保証するために、VBRの余裕量sv_nowが、ゼロか
ら最大値SVMAXになるように制御を行う。
00秒の場合、SV1, SVMAXは次の値である。ここで、ビ
デオの平均符号化ビットレートは、図99のステップS
20で決定された値である(図107を参照)。 SV1 = (ビデオの平均符号化ビットレート) * 300 SVMAX = SV1 * 2
り当てビットb_allocの計算する。
立つかを調べる。このステップSは、VBRの余裕量がマ
イナスにならないかどうかチェックである。 sv_now + b_av - b_alloc >= 0
トレートから計算される、GOPあたりの符号化の割り当
てビット量の平均値である。GOPの時間長を、0.5秒
とするとb_avは次の値である。 b_av = (ビデオの平均ビットレート)* 0.5
ップS203へ進む。ステップS202でNoの場合
は、ステップS204へ進み、b_allocをb_avとし、ス
テップS205へ進む。
り立つかを調べる。このステップSは、VBRの余裕量が
最大値SVMAXを超えないかどうかチェックである。 sv_now + b_av - b_alloc <= SVMAX
ップS205へ進む。ステップS203でNoの場合
は、ステップS204へ進み、b_allocをb_avとし、ス
テップS205へ進む。
ードする。そして、現在のGOPを割り当てビット量b_all
ocでエンコードし、その時のVBV制御は、VBVバッファへ
の入力ビットレートを現在のGOPの符号化ビットレート
とし、VBVバッファがオーバーフローしないようにスタ
ッフィングバイトを挿入するように制御する。この処理
の詳細については、図106で説明する。
owを次式のように更新する。ここで、b_genは、ステッ
プS205で、現在のGOPのエンコードした結果、得ら
れた現GOPの符号化ビット量である。 sv_now += b_av - b_gen
あるか調べる。ステップS207で、Yesの場合は、
処理を終了する。ステップS207で、Noの場合は、
ステップS201へ戻る。
205の処理における、VBV制御の処理の詳細を説明
するフローチャートである。
に割り当てられた符号化ビット量を符号化ビットレート
gop_bit_rateに変換する。 gop_bit_rate = b_alloc / (15/ 29.97)
符号化するピクチャの最低ビット量min_picture_bitを
次式により計算する。 tmp = vbv_b + gop_bit_rate*tau min_picture_bit = tmp - VBV_BUFFER_SIZE
するピクチャをデコードする直前のVBVバッファのビ
ット占有量である(図102参照)。
ド時刻と その次のピクチャのデコード時刻の差である
(図102参照)。
あり、MPEG2 MP@MLの場合、1.75 Mbitであ
る。
ンコードし、その発生ビット量gen_picture_bitを得
る。
る。 gen_picture_bit < min_picture_bit
ップS304へ進む。ステップS303でNoの場合
は、ステップS305へ進む。
ureの後にnum_stuffing_byteの数のスタッフィングバイ
トをビデオエンコーダが現在符号化し、それらを符号化
ピクチャの後ろに付加する(図102参照)。 num_stuffing_byte=(min_picture_bit-gen_picture_bit
+4)/8
ャかどうか調べる。ステップS305で、Yesの場合
は、処理を終了する。ステップS305で、Noの場合
は、ステップS301へ戻る。
変ビットレート符号化を制御し、AVストリームファイ
ルを生成することにより、AVストリームの時間経過と
AVストリームのデータバイト量との関係が、所定の誤
差の範囲内で比例することを保証することできる。これ
により、そのストリームのある時間分だけ部分的にスト
リームを消去すると、消去した時間分だけ前記ストリー
ムのTS_average_rateで示されるビットレートで記録可
能な空き領域をディスク上に作れることを保証できる。
経過とAVストリームのデータバイト量との関係が比例
することを保証しない符号化モード(time_controlled_
flag=0)におけるAVストリームの記録方法の例を2つ示
す。
例は、ディジタル放送のAVストリーム(プログラム)
のトランスポートストリームをトランスペアレント記録
する場合である。ディジタル放送が統計多重を用いてい
る場合、一般に、その中のAVストリームは可変ビット
レートである。一般に、この場合のAVストリームの時
間経過とAVストリームのデータバイト量との関係が比
例することは保証されないので、このAVストリームを
トランスペアレント記録してClipを作成した場合、その
Clipのtime_controlled_flagをゼロにセットする。
例は、ビデオを可変ビットレート符号化する場合に、ビ
デオストリームを、あらかじめ設定した所定の時間区間
毎に所定の平均ビットレート以下になる様に、可変ビッ
トレートでエンコードする場合である。これは、図10
1で説明したように、ビデオ符号化のVBV制御が、VBVバ
ッファに空きがあるときは、バッファへの入力ビットレ
ートをVariable Bit-Rateの最大ビットレートにし、VBV
バッファのビット占有量がフルの場合は、バッファへの
入力ビットレートをゼロにする場合である。図108と
図109を用いて、この場合のAVストリームの記録方
法を説明する。
AVストリームのデータバイト量との関係が、比例する
ことを保証しない符号化モード(time_controlled_flag
=0)において、ビデオを可変ビットレート符号化して、
AVストリームを記録する動作を説明するフローチャート
を示す。
ある。
を、あらかじめ設定した所定の時間区間毎に所定の平均
ビットレート以下になる様に、可変ビットレートでエン
コードするようにビデオエンコーダ151を制御する。
400の処理における、ビデオの可変ビットレート制御
の処理の詳細を説明するフローチャートである。
に初期値SV1をセットする。この場合の可変ビットレー
ト制御は、VBRの余裕量sv_nowが、負の値にならないよ
うに制御を行う。
り当てビットb_allocの計算する。
立つかを調べる。このステップSは、VBRの余裕量がマ
イナスにならないかどうかチェックである。 sv_now + b_av - b_alloc >= 0
トレートから計算される、GOPあたりの符号化の割り当
てビット量の平均値である。GOPの時間長を、0.5秒
とするとb_avは次の値である。 b_av = (ビデオの平均ビットレート)* 0.5
ップS504へ進む。ステップS502でNoの場合
は、ステップS504へ進み、b_allocをb_avとし、ス
テップS504へ進む。
ードする。そして、現在のGOPを割り当てビット量b_all
ocでエンコードし、その時のVBV制御は、その時のVBV制
御は、VBVバッファに空きがあるときは、バッファへの
入力ビットレートをVBR(Variable Bit-Rate)の最大ビッ
トレートにし、VBVバッファのビット占有量がフルの場
合は、バッファへの入力ビットレートをゼロにする場合
のVBV制御とする(図101参照)。このステップSで
は、ビデオストリームにスタッフィングバイトを符号化
しない。
owを次式のように更新する。ここで、b_genは、ステッ
プS504で、現在のGOPのエンコードした結果、得ら
れた現GOPの符号化ビット量である。 sv_now += b_av - b_gen
あるか調べる。ステップS506で、Yesの場合は、
処理を終了する。ステップS506で、Noの場合は、
ステップS501へ戻る。
の場合、前述したようにAVストリームの時間経過とA
Vストリームのデータバイト量との関係が所定の誤差範
囲内で比例することを保証しない。例えば、入力ビデオ
の中に長い時間の静止画像があると、AVストリームの
時間経過とAVストリームのデータバイト量との関係が
図104に示したようになる。すなわち、静止画像は情
報量が比較的小さいため、その情報量よりも符号化の割
り当てビット量を大きくしても、実際に符号化して発生
するビット量はある比較的小さな値に飽和してしまう。
したがって、この場合、AVストリームの時間経過とA
Vストリームのデータバイト量の関係が、比例しない。
オに割り当てられたビット量を使うように制御すること
を目的として、VBVバッファへの入力ビットレートが現
在のGOPの符号化ビットレートであり、VBVバッファがオ
ーバーフローしないようにビデオエンコーダがスタッフ
ィングバイトを発生するように制御すれば、AVストリ
ームの時間経過とAVストリームのデータバイト量との
関係が、所定の誤差範囲内でほぼ比例することを保証で
きる。
トリームのデータバイト量との関係が、比例することを
保証する符号化モード(time_controlled_flag=1)を簡
単に実現する方法として、トランスポートストリームを
多重化する時にヌルパケットを挿入して、一定ビットレ
ートのトランスポートストリームを記録することも考え
られる。これは、主にテープ記録媒体(D−VHS等)
で用いられている符号化方法である。ここで、ヌルパケ
ットは、そのパケットID(PID)が、0x1FFFにセッ
トされている、情報としては何も意味をもたないトラン
スポートパケットである。
110に、所定の一定ビットレートのトランスポートス
トリームを符号化することによって、AVストリームの
時間経過とAVストリームのデータバイト量との関係
が、比例することを保証する符号化モードのフローチャ
ートを示す。
ームの多重化ビットレートおよびビデオ符号化のビット
レートを設定する ステップS601で、ビデオストリー
ムを、所定の一定のビットレート、または、そのビット
レート以下で、エンコードする。
ト化するエレメンタリストリームがない場合にヌルパケ
ット(情報としては意味をもたないトランスポートパケ
ット)を発生して多重化し、所定の一定の多重化ビット
レートのトランスポートストリームを符号化する。
ットにアライバルタイムスタンプを付加して、ソースパ
ケット化する。ソースパケットを記録媒体に記録する。
して記録した場合、そのClipのtime_controlled_flagは
1にセットされる。しかしながら、この方法は、ヌルパ
ケットを使用するため、ビデオ符号化に効率良く符号ビ
ットを使用していないので、図99の符号化方法よりも
ビデオの画質が劣る問題がある(このことについては、
例えば特願平11-220727の従来の技術の欄に詳しく述べ
ている)。そのため、本発明では上記の図110の記録
方法を推奨しない。
分だけ部分的にストリームを消去する方法について説明
する。
ファイルと、そのストリームの部分的な再生範囲のスト
リームを消去する編集を行った後のAVストリームファ
イルの例を示す。編集前に、Virtual PlayListは、オリ
ジナルAVストリーム上のIN_timeとOUT_timeを指してい
るとする。この時、Virtual PlayListが使用していない
ストリーム部分を消去する編集(ミニマイズ編集)をし
た場合、それはオリジナルAVストリームを図111に示
す編集後のストリームへ変える。オリジナルAVストリー
ムの先頭からX点までのデータと、Y点から最後までの
データが消去される。以下の説明では、このX点とY点
を決める方法の例を説明する。
ることをしないで、IN点の前の不要なデータを消去する
方法を説明する図である。PlayListはオリジナルAVスト
リーム上のIN点を指す。また、そのAVストリームのEP_m
apを図示する。IN点が指すピクチャをデコードするため
には、アドレスISA2から開始するIピクチャが必要であ
る。
ットが必要である。RSPN_EP_start=ISA1のPTSはpts1で
あり、RSPN_EP_start=ISA2のPTSはpts2である。pts1とp
ts2のシステムタイムベースの時間差が100 msec以上な
らば、アドレスISA1とISA2の間にはPAT, PMTおよびPCR
パケットが存在する(少なくとも、SESF, DVB, ATSC, I
SDBの場合はそうである)。
められる。そして、X点はアラインドユニットの境界で
なければならない。記録装置は、AVストリームの内容を
解析することをしないで、X点をEP_mapを使用して次の
ステップSで決めることができる。 (S1)システムタイムベース上でIN timeのPTSに最も
近く、かつそれよりも過去の表示時刻のPTSの値を持つS
PN_EP_startを見つける。 (S2)ステップS1で見つけたSPN_EP_startのPTSの値
よりも少なくとも100 msec過去の表示時刻のPTSの値を
持つSPN_EP_startを見つける。 (S3)X点は、ステップS2で見つけたSPN_EP_start
よりも前に決められる。そして、X点はアラインドユニ
ットの境界でなければならない。
リームのデータを読み出し、その内容を解析することを
必要としないので、簡単である。しかし、編集後のAVス
トリームは、そのPlayListの再生には不要なデータを残
してしまう場合がある。もし、X点を決めるためにAV
ストリームのデータを読み出し、その内容を解析するな
らば、そのPlayListの再生には不要なデータをより効率
良く消去できる。
ることをしないで、OUT点の後ろの不要なデータを消去
する方法を説明する図である。PlayListはオリジナルAV
ストリーム上のOUT点を指す。また、そのAVストリーム
のEP_mapを図示する。
ーケンスは次に示すものであることを前提とする。 I2 B0 B1 P5 … ここで、I,P,BはそれぞれIピクチャ,PピクチャそしてB
ピクチャを表す。数字は表示順序を表す。この処理にお
いて、記録装置がAVストリームの内容を解析しない場
合、記録装置はOUT_timeのPTSが参照するところのピク
チャの情報(ピクチャコーディングタイプ,テンポラル
・レファレンスなど)がわからない。OUT_timeのPTSはピ
クチャB0またはB1を参照しているかもしれない(記録装
置がAVストリームの内容を解析しない場合、このことは
わからない)、この場合、ピクチャB0,B1をデコードす
るためにはI2が必要である。I2のPTSはOUT timeのPTSよ
りも大きい(OUT_time < pts4, ここでpts4はI2のPTSで
ある)。I2のPTSはOUT_timeのPTSよりも大きいが、B0,
B1のためにI2が必要である。
の後ろに決められる。ISA5は、EP_mapの中でISA4の直後
にあるSPN_EP_startの値である。Y点はまたアラインド
ユニットの境界でなければならない。
ることをしないで、Y点をEP_mapを使用して次のステッ
プSで決めることができる。 (S1)システムタイムベース上でOUT timeのPTSに最
も近く、かつそれよりも未来の表示時刻のPTSの値を持
つSPN_EP_startを見つける。 (S2)ステップS1で見つけたSPN_EP_startの直後に
あるSPN_EP_start を見つける。 (S3)Y点は、ステップS2で見つけたSPN_EP_start
よりも後ろに決められる。そして、Y点はアラインドユ
ニットの境界でなければならない。
リームのデータを読み出し、その内容を解析することを
必要としないので、簡単である。しかし、編集後のAVス
トリームは、そのPlayListの再生には不要なデータを残
してしまう場合がある。もし、Y点を決めるためにAV
ストリームのデータを読み出し、その内容を解析するな
らば、そのPlayListの再生には不要なデータをより効率
良く消去できる。
フローチャートを用いて説明する。この処理は図1の記
録再生装置の多重化ストリーム解析部18で行われる。
録するAVプログラムのビデオのPIDをセットする。トラ
ンスポートストリームの中に複数のビデオが含まれてい
る場合は、それぞれのビデオPIDをセットする。
デオのトランスポートパケットを受信する。
ンスポートパケットのペイロード(パケットヘッダーに
続くデータ部)がPESパケットの第一バイト目から開始
しているかを調べる(PESパケットは、MPEG2で規定され
ているパケットであり、エレメンタリストリームをパケ
ット化するものである)。これは、トランスポートパケ
ットヘッダにある"payload_unit_start_indicator"の値
を調べることによりわかり、この値が1である場合、ト
ランスポートパケットのペイロードがPESパケットの第
一バイト目から開始する。ステップS13でNoの場合は、
ステップS12へ戻り、Yesの場合は、ステップS14へ進
む。
パケットのペイロードが、MPEGビデオのsequence_heade
r_code(32ビット長で"0x000001B3"の符号)の第一バイト
目から開始しているかを調べる。ステップS14でNoの場
合は、ステップS12へ戻り、Yesの場合は、ステップS1
5へ進む。
スポートパケットをエントリーポイントとする。ステッ
プS16でストリーム解析部は、上記パケットのパケット
番号と上記sequence_header_code から開始するIピクチ
ャのPTSとそのエントリーポイントが属するビデオのPID
を取得し、制御部23へ入力する。制御部23はEP_mapを作
成する。
入力されるトランスポートパケットであるかどうかを判
定する。最後のパケットでない場合、ステップS12へ戻
る。最後のパケットである場合、処理を終了する。
り実行させることもできるが、ソフトウェアにより実行
させることもできる。一連の処理をソフトウェアにより
実行させる場合には、そのソフトウェアを構成するプロ
グラムが専用のハードウェアに組み込まれているコンピ
ュータ、または、各種のプログラムをインストールする
ことで、各種の機能を実行することが可能な、例えば汎
用のパーソナルコンピュータなどに、記録媒体からイン
ストールされる。
コンピュータとは別に、ユーザにプログラムを提供する
ために配布される、プログラムが記録されている磁気デ
ィスク221(フロッピディスクを含む)、光ディスク
222(CD-ROM(Compact Disk-Read Only Memory),D
VD(Digital Versatile Disk)を含む)、光磁気ディス
ク223(MD(Mini-Disk)を含む)、若しくは半導体
メモリ224などよりなるパッケージメディアにより構
成されるだけでなく、コンピュータに予め組み込まれた
状態でユーザに提供される、プログラムが記憶されてい
るROM202や記憶部208が含まれるハードディスク
などで構成される。
されるプログラムを記述するステップSは、記載された
順序に従って、時系列的に行われる処理は勿論、必ずし
も時系列的に処理されなくとも、並列的あるいは個別に
実行される処理をも含むものである。
複数の装置により構成される装置全体を表すものであ
る。
て記録する時に、そのAVストリームの属性情報とし
て、time_controlled_flag, TS_average_rateを記録す
る。time_controlled_flagを1にセットする場合、AV
ストリームの時間経過とAVストリームのデータバイト
量との関係が、所定の誤差の範囲内で比例することを保
証する。また、TS_average_rateは、AVストリームファ
イル(トランスポートストリーム)の平均ビットレート
をbytes/second の単位で表したものである。TS_averag
e_rateは、記録器のアプリケーションによって所定に値
に決める。例えば、長時間録画モード(LPモード),
標準録画モード(SPモード)、高画質録画モード(H
Qモード)といった記録モードに応じて、それぞれのモ
ードのTS_average_rateの値を決める。
d_flagが1にセットされている場合、そのストリームの
ある時間分だけ部分的にストリームを消去すると、消去
した時間分だけ前記ストリームのTS_average_rateで示
されるビットレートで記録可能な空き領域をディスク上
に作れることを保証できる。例えば、SPモードのAV
ストリームファイルのある時間分だけ部分的にストリー
ムを消去すると、消去した時間分だけ、同じSPモード
で記録可能な空き領域をディスク上に作ることができ
る。
合、次のようにしてAVストリームを符号化する。 (1)トランスポートストリームの多重化ビットレート
およびビデオ符号化の平均ビットレートを設定する。 (2)ビデオストリームを、あらかじめ設定した所定の
時間区間毎に所定の平均ビットレートが保証される様
に、可変ビットレートでエンコードする。ここで、MPEG
ビデオ符号化のVBV(Video Buffering Verifier)制御
は、ビデオエンコーダが所定時間のビデオに割り当てら
れたビット量を使うように制御することを目的として、
VBVバッファへの入力ビットレートが現在の符号化ビッ
トレートであり、VBVバッファがオーバーフローしない
ようにビデオエンコーダがスタッフィングバイトを発生
するようにする。 (3)トランスポートパケット化するエレメンタリスト
リームがない場合にヌルパケットを発生しないように多
重化の制御をする。 (4)各トランスポートパケットにアライバルタイムス
タンプを付加して、ソースパケット化し、そして、ソー
スパケット列を前詰して、AVストリームファイルとして
記録する。
して記録することにより、そのストリームのある時間分
だけ部分的にストリームを消去すると、消去した時間分
だけ前記ストリームのTS_average_rateで示されるビッ
トレートで記録可能な空き領域をディスク上に作れるこ
とを保証できる。
の構成を示す図である。
ータのフォーマットについて説明する図である。
明する図である。
る。
る。
いて説明する図である。
である。
説明する図である。
る。
る図である。
る図である。
について説明する図である。
る。
る。
ある。
る。
である。
ある。
図である。
ある。
クス内のフラグについて説明する図である。
ある。
ある。
ある。
る。
る。
ある。
る。
ある。
る。
示す図である。
る。
である。
図である。
造について説明する図である。
コーダモデルを示す図である。
レーヤモデルを示す図である。
る。
る。
す図である。
る図である。
いて説明する図である。
ついて説明する図である。
ある。
る。
トリームを記録する動作を説明するフローチャートであ
る。
ある。
す図である。
である。
フローチャートである。
するフローチャートである。
ムのデータバイト量との関係を説明する図である。
ストリームを記録する動作を説明するフローチャートで
ある。
するフローチャートである。
ムのデータバイト量との関係が、比例することを保証す
る符号化モードを説明するフローチャートである。
である。
トリームデータを消去する例を示す図である。
ストリームデータを消去する例を示す図である。
トである。
析部, 15 AVエンコーダ, 16 マルチプレク
サ, 17 スイッチ, 18 多重化ストリーム解析
部, 19 ソースパケッタイザ, 20 ECC符号化
部, 21 変調部, 22 書き込み部, 23 制
御部, 24 ユーザインタフェース,26 デマルチ
プレクサ, 27 AVデコーダ, 28 読み出し部,
29復調部, 30 ECC復号部, 31 ソースパ
ケッタイザ, 32,33 端子
Claims (12)
- 【請求項1】 映像データを符号化する符号化装置にお
いて、 前記映像データを可変レートにより符号化する符号化器
と、 時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御部とを有することを特徴とする符号化
装置。 - 【請求項2】 前記制御部は、単位時間あたりの映像符
号化データ発生量が所定量に満たないときにはスタッフ
ィングバイトを符号化するよう制御することを特徴とす
る請求項1に記載の符号化装置。 - 【請求項3】 前記制御部は、各々のピクチャの符号化
の際に発生するデータ量に応じてスタッフィングバイト
を符号化するか否かを判定することを特徴とする請求項
2に記載の符号化装置。 - 【請求項4】 前記制御部は、VBVバッファがオーバ
ーフローしないようにスタッフィングバイトを符号化す
るよう制御することを特徴とする請求項2に記載の符号
化装置。 - 【請求項5】 前記制御部は、時間経過に対して符号化
データ量がほぼ比例するように符号化する符号化モード
と通常の符号化モードのどちらか一方で符号化するよう
に制御することを特徴とする請求項1に記載の符号化装
置。 - 【請求項6】 前記制御部は、前記符号化モードが、時
間経過に対して符号化データ量がほぼ比例するように符
号化するモードか否かを示す付加情報を生成することを
特徴とする請求項5に記載の符号化装置。 - 【請求項7】 映像データを符号化する符号化装置の符
号化方法において、 前記映像データを可変レートにより符号化する符号化ス
テップと、 時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御ステップとを含むことを特徴とする符
号化方法。 - 【請求項8】 映像データを符号化する符号化装置を制
御するプログラムにおいて、 前記映像データを可変レートにより符号化する符号化ス
テップと、 時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御ステップとを含むことを特徴とするコ
ンピュータが読み取り可能なプログラムが記録されてい
る記録媒体。 - 【請求項9】 映像データを符号化する符号化装置を制
御するコンピュータに、 前記映像データを可変レートにより符号化する符号化ス
テップと、 時間経過に対して映像符号化データ量がほぼ比例するよ
うに制御する制御ステップとを実行させるプログラム。 - 【請求項10】 映像データが記録されている記録媒体
において、 前記映像データと、前記映像データに対応するオーディ
オデータを含むAVストリームファイルと、 前記AVストリームファイルの記録モードを示すフラグと
が記録されていることを特徴とする記録媒体。 - 【請求項11】 前記フラグは、time_controlled_flag
であることを特徴とする請求項10に記載の記録媒体。 - 【請求項12】 前記フラグは、記録してからの時間経
過に対してファイルサイズが比例するようにして記録さ
れるモードであることを示すことを特徴とする請求項1
1に記載の記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001112756A JP2002159004A (ja) | 2000-04-21 | 2001-04-11 | 符号化装置および方法、記録媒体、並びにプログラム |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000183770 | 2000-04-21 | ||
JP2000-183770 | 2000-04-21 | ||
JP2000-268042 | 2000-09-05 | ||
JP2000268042 | 2000-09-05 | ||
JP2001112756A JP2002159004A (ja) | 2000-04-21 | 2001-04-11 | 符号化装置および方法、記録媒体、並びにプログラム |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011012107A Division JP5047371B2 (ja) | 2000-04-21 | 2011-01-24 | 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体製造方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2002159004A true JP2002159004A (ja) | 2002-05-31 |
Family
ID=27343768
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001112756A Pending JP2002159004A (ja) | 2000-04-21 | 2001-04-11 | 符号化装置および方法、記録媒体、並びにプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2002159004A (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005065262A (ja) * | 2003-08-14 | 2005-03-10 | Ricoh Co Ltd | イベントマーカーの伝送方法 |
JP2007523438A (ja) * | 2004-02-21 | 2007-08-16 | サムスン エレクトロニクス カンパニー リミテッド | Avデータに同期されたテキストサブタイトルデータを記録した情報記録媒体、再生方法及び装置 |
JP2007531183A (ja) * | 2004-02-10 | 2007-11-01 | エルジー エレクトロニクス インコーポレーテッド | 多様なデータストリームを管理するためのデータ構造を有する記録媒体、記録再生方法及び装置 |
WO2008059574A1 (en) * | 2006-11-16 | 2008-05-22 | Fujitsu Microelectronics Limited | Gop-to-gop management device |
JP2009289400A (ja) * | 2003-10-10 | 2009-12-10 | Sharp Corp | 再生装置、ビデオデータの再生方法、コンテンツ記録媒体、制御プログラム、制御プログラムを記録したコンピュータ読み取り可能な記録媒体 |
US7660511B2 (en) | 2003-04-23 | 2010-02-09 | Panasonic Corporation | Recording medium, playback device, recording method, playback program, and playback method designating cue-up position using playlist mark information |
US8233770B2 (en) | 2003-10-10 | 2012-07-31 | Sharp Kabushiki Kaisha | Content reproducing apparatus, recording medium, content recording medium, and method for controlling content reproducing apparatus |
JP2012531657A (ja) * | 2009-06-25 | 2012-12-10 | サムスン エレクトロニクス カンパニー リミテッド | 仮想世界処理装置および方法 |
US8452153B2 (en) | 2003-07-11 | 2013-05-28 | Ricoh Company, Ltd. | Associating pre-generated barcodes with temporal events |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0865683A (ja) * | 1994-08-17 | 1996-03-08 | Graphics Commun Lab:Kk | 動画像符号量制御方法と装置 |
JPH08280012A (ja) * | 1995-04-08 | 1996-10-22 | Sony Corp | データ記録方法及び装置、データ再生方法及び装置、記録媒体、データ伝送方法及び装置 |
JPH0946691A (ja) * | 1995-07-31 | 1997-02-14 | Victor Co Of Japan Ltd | 情報蓄積出力方法及び情報蓄積出力装置 |
JPH09162830A (ja) * | 1995-12-13 | 1997-06-20 | Sony Corp | オーサリングシステム,このシステムで使用される符号化装置及び多重化装置並びに多重ビットストリームを生成する方法 |
JPH1023070A (ja) * | 1996-07-02 | 1998-01-23 | Sony Corp | 伝送装置及び伝送方法 |
JPH11122623A (ja) * | 1997-10-15 | 1999-04-30 | Mega Chips Corp | 画像符号化装置 |
-
2001
- 2001-04-11 JP JP2001112756A patent/JP2002159004A/ja active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0865683A (ja) * | 1994-08-17 | 1996-03-08 | Graphics Commun Lab:Kk | 動画像符号量制御方法と装置 |
JPH08280012A (ja) * | 1995-04-08 | 1996-10-22 | Sony Corp | データ記録方法及び装置、データ再生方法及び装置、記録媒体、データ伝送方法及び装置 |
JPH0946691A (ja) * | 1995-07-31 | 1997-02-14 | Victor Co Of Japan Ltd | 情報蓄積出力方法及び情報蓄積出力装置 |
JPH09162830A (ja) * | 1995-12-13 | 1997-06-20 | Sony Corp | オーサリングシステム,このシステムで使用される符号化装置及び多重化装置並びに多重ビットストリームを生成する方法 |
JPH1023070A (ja) * | 1996-07-02 | 1998-01-23 | Sony Corp | 伝送装置及び伝送方法 |
JPH11122623A (ja) * | 1997-10-15 | 1999-04-30 | Mega Chips Corp | 画像符号化装置 |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7660511B2 (en) | 2003-04-23 | 2010-02-09 | Panasonic Corporation | Recording medium, playback device, recording method, playback program, and playback method designating cue-up position using playlist mark information |
US8452153B2 (en) | 2003-07-11 | 2013-05-28 | Ricoh Company, Ltd. | Associating pre-generated barcodes with temporal events |
JP2005065262A (ja) * | 2003-08-14 | 2005-03-10 | Ricoh Co Ltd | イベントマーカーの伝送方法 |
JP4524149B2 (ja) * | 2003-08-14 | 2010-08-11 | 株式会社リコー | イベントマーカーの伝送方法 |
US7685428B2 (en) | 2003-08-14 | 2010-03-23 | Ricoh Company, Ltd. | Transmission of event markers to data stream recorder |
JP2009289400A (ja) * | 2003-10-10 | 2009-12-10 | Sharp Corp | 再生装置、ビデオデータの再生方法、コンテンツ記録媒体、制御プログラム、制御プログラムを記録したコンピュータ読み取り可能な記録媒体 |
JP2009289401A (ja) * | 2003-10-10 | 2009-12-10 | Sharp Corp | 再生装置、ビデオデータの再生方法、制御プログラム、及びコンテンツ記録媒体 |
US8565575B2 (en) | 2003-10-10 | 2013-10-22 | Sharp Kabushiki Kaisha | Reproducing apparatus, method for controlling reproducing apparatus, content recording medium, and non-transitory recording medium storing control program |
US8798440B2 (en) | 2003-10-10 | 2014-08-05 | Sharp Kabushiki Kaisha | Video data reproducing apparatus and method utilizing acquired data structure including video data and related reproduction information, non-transitory recording medium containing the data structure and non-transitory recording medium storing control program for causing computer to operate as reproducing apparatus |
JP4641046B2 (ja) * | 2003-10-10 | 2011-03-02 | シャープ株式会社 | 再生装置、ビデオデータの再生方法、コンテンツ記録媒体、制御プログラム、制御プログラムを記録したコンピュータ読み取り可能な記録媒体 |
US8792026B2 (en) | 2003-10-10 | 2014-07-29 | Sharp Kabushiki Kaisha | Video data reproducing apparatus and method utilizing acquired data structure including video data and related reproduction information, and non-transitory recording medium storing control program for causing computer to operate as reproducing apparatus |
US8233770B2 (en) | 2003-10-10 | 2012-07-31 | Sharp Kabushiki Kaisha | Content reproducing apparatus, recording medium, content recording medium, and method for controlling content reproducing apparatus |
US8625962B2 (en) | 2003-10-10 | 2014-01-07 | Sharp Kabushiki Kaisha | Method and apparatus for reproducing content data, non-transitory computer-readable medium for causing the apparatus to carry out the method, and non-transitory content recording medium for causing the apparatus to carry out the method |
US8625966B2 (en) | 2003-10-10 | 2014-01-07 | Sharp Kabushiki Kaisha | Reproducing apparatus, method for operating reproducing apparatus and non-transitory computer-readable recording medium storing control program |
JP2007531183A (ja) * | 2004-02-10 | 2007-11-01 | エルジー エレクトロニクス インコーポレーテッド | 多様なデータストリームを管理するためのデータ構造を有する記録媒体、記録再生方法及び装置 |
JP2011187156A (ja) * | 2004-02-21 | 2011-09-22 | Samsung Electronics Co Ltd | Avデータに同期されたテキストサブタイトルデータを記録した情報記録媒体、再生方法及び装置 |
JP2007523438A (ja) * | 2004-02-21 | 2007-08-16 | サムスン エレクトロニクス カンパニー リミテッド | Avデータに同期されたテキストサブタイトルデータを記録した情報記録媒体、再生方法及び装置 |
KR101034832B1 (ko) | 2006-11-16 | 2011-05-17 | 후지쯔 세미컨덕터 가부시키가이샤 | Gop간 관리 장치 |
US8315508B2 (en) | 2006-11-16 | 2012-11-20 | Fujitsu Semiconductor Limited | Inter-GOP management apparatus |
JP4755257B2 (ja) * | 2006-11-16 | 2011-08-24 | 富士通セミコンダクター株式会社 | Gop間管理装置 |
WO2008059574A1 (en) * | 2006-11-16 | 2008-05-22 | Fujitsu Microelectronics Limited | Gop-to-gop management device |
JP2012531657A (ja) * | 2009-06-25 | 2012-12-10 | サムスン エレクトロニクス カンパニー リミテッド | 仮想世界処理装置および方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5500398B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
KR100746821B1 (ko) | 정보 처리 장치와 방법, 기록매체 | |
KR100875782B1 (ko) | 정보 처리 장치와 방법, 및 기록 매체 | |
JP4517267B2 (ja) | 記録装置および方法、再生装置および方法、プログラム、並びに記録媒体 | |
JP4682434B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
JP4355988B2 (ja) | 情報処理装置、情報処理方法、プログラム記録媒体、プログラム、および情報記録媒体 | |
JP2002158965A (ja) | 情報処理装置および方法、記録媒体、プログラム、並びに記録媒体 | |
JP2002159004A (ja) | 符号化装置および方法、記録媒体、並びにプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080306 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091222 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100105 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100308 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101125 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110124 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111110 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111219 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120209 |