JP2018133124A - 記録装置、記録方法および記録媒体 - Google Patents

Abstract

【課題】１つのストリームが複数の可変長パケットに分割されたデータを記録する記録装置、などを提供する。【解決手段】記録装置２０２であって、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信する受信部１２１と、受信した前記コンテンツを記録媒体２０９に記録する記録部と１２２、を備える。【選択図】図３２

Description

本発明は、コンテンツを多重化して記録する記録装置、記録方法および記録媒体に関する。

高度ＢＳデジタル放送または高度広帯域ＣＳデジタル放送では、通信による伝送との連携を強化するために、新たな多重化フォーマットとしてＭＭＴ／ＴＬＶ方式が採用される。例えば、非特許文献１には、ＭＭＴに従って、符号化されたメディアデータをパケット毎に送信する技術が開示されている。

Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔ − Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ ＤＩＳ ２３００８−１

しかしながら、ＭＭＴ方式などのような１つストリームが複数の可変長パケットに分割されたデータを受信し、記録する記録装置、記録方法および記録媒体については考慮されていない。

そこで、本開示の目的は、１つのストリームが複数の可変長パケットに分割されたデータを記録する記録装置、記録方法および記録媒体を提供することにある。

前記課題を解決するために、本開示の一態様に係る記録装置は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信する受信部と、受信した前記コンテンツを記録媒体に記録する記録部と、を備える。

また、本開示の一態様に係る記録方法は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信し、受信した前記コンテンツを記録媒体に記録する。

また、本開示の一態様に係る記録媒体は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツが記録されている。

本開示の記録方法などは、記録したデータを適切に再生することができる。

図１は、ＢＤディスクの構成の一例を示す図である。 図２は、ＩＮＦＯファイルの内部構成の一例を示す図である。 図３は、プレイリストファイルの内部構成の一例を示す図である。 図４は、プレイアイテムの内部構成の一例を示す図である。 図５は、クリップ情報ファイルの内部構成の一例を示す図である。 図６は、ストリーム属性情報の内部構成の一例を示す図である。 図７は、エントリマップの内部構成の一例を示す図である。 図８は、ＡＶクリップにおけるＴＳパケットおよびソースパケットの構成の一例を示す図である。 図９は、ＰＭＴのデータ構造の一例を示す図である。 図１０は、再生装置の構成の一例を示すブロック図である。 図１１は、システムターゲットデコーダの内部構成の一例を示すブロック図である。 図１２は、ＭＭＴ／ＴＬＶ方式のストリームの構成の一例を模式的に示す図である。 図１３は、ＴＬＶパケットの構成の一例を示す図である。 図１４は、ＩＰパケットの構成の一例を示す図である。 図１５は、ＭＭＴＰパケットの構成の一例を示す図である。 図１６は、ＭＭＴ−ＳＩが格納される場合のＭＭＴＰペイロードの構成の一例を示す図である。 図１７は、ＭＭＴＰペイロードのペイロード領域にＭＭＴ−ＳＩが格納される場合の構成の一例を示す図である。 図１８は、ＭＭＴ−ＳＩが複数に分割されて格納される場合の複数に分割されたＭＭＴ−ＳＩと複数のＭＭＴ−ＳＩを格納する複数のＭＭＴＰパケットとの関係の一例を示す図である。 図１９は、実施の形態に係る記録装置の構成の一例を示すブロック図である。 図２０は、ＭＭＴ／ＴＬＶ方式の放送コンテンツのうちの録画する部分を説明するための図である。 図２１は、ＭＭＴ−ＳＩが複数のＭＭＴＰパケットに分割して格納される場合を説明するための図である。 図２２は、分割ＭＭＴ−ＳＩを再構成する場合の一例を説明するための図である。 図２３は、分割ＭＭＴ−ＳＩを再構成する場合の別の一例を説明するための図である。 図２４は、ＭＭＴＰパケットの再構成処理の一例を示すフローチャートである。 図２５は、Ａｌｉｇｎｅｄ Ｕｎｉｔ単位での暗号方法を説明するための図である。 図２６は、光ディスク上での記録用ＭＭＴ暗号ストリームの記録形態を示す図である。 図２７は、実施の形態に係る再生装置の構成の一例を示すブロック図である。 図２８は、Ａｌｉｇｎｅｄ Ｕｎｉｔ単位での復号方法を説明するための図である。 図２９は、ＭＰＥＧ−２ＴＳ方式とＭＭＴ／ＴＬＶ方式とが混在する場合のプレイリストの内部構成の一例を示す図である。 図３０は、ＴＳ／ＭＭＴ混在フラグによる再生装置の再生処理の一例を示すフローチャートである。 図３１は、ＭＭＴ／ＴＬＶ方式におけるクリップ情報ファイルの内部構成の一例を示す図である。 図３２は、実施の形態に係る記録装置の機能的な構成を示すブロック図である。 図３３は、実施の形態に係る記録装置による記録方法の一例を示すフローチャートである。 図３４は、エントリマップのＥＰコースおよびＥＰファインを説明するための図である。

（本発明の基礎となった知見）
従来、ＭＭＴ／ＴＬＶ方式等で多重化されているコンテンツを受信して記録媒体に記録する記録装置などについては十分に考慮されておらず、例えば、コンテンツを再生するために利用するコンテンツと共に送信される基準時刻情報を記録せずに記録媒体に記録する場合があった。このため、再生装置は、記録媒体に記録されたコンテンツを再生することが難しい場合があった。

以下、具体的に説明する。

デジタル放送やコンテンツ配信では、従来のＳｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎ（ＳＤ）画質やＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ（ＨＤ）のコンテンツにおいては、伝送および蓄積の際の多重化フォーマットとしてＭＰＥＧ２−ＴＳ方式が利用されることが一般的であった。

多重化フォーマットとは、ＡＶコンテンツを構成するビデオ信号およびオーディオ信号を一つのデジタルデータとして扱うためのフォーマットである。多重化フォーマットにおけるデジタルデータは、例えば、ＭＰＥＧ４−ＡＶＣ方式で符号化されたビデオ信号と、ＭＰＥＧ２−ＡＡＣ方式で符号化されたオーディオ信号とを適切なサイズに細分化し、これらの細分化されたデータを再生に必要となる順番で並べ直すとともに、制御用の情報が付与されたデータである。

ＭＰＥＧ２−ＴＳ方式を用いている日本の地上デジタル放送またはＢＳ／ＣＳデジタル放送におけるデジタルデータは、固定長である１８８バイトのサイズのデータを一つの単位として、ビデオ信号およびオーディオ信号を格納している。ここで、一単位のデータは、パケットと呼ばれ、ＭＰＥＧ２−ＴＳ方式ではＴＳパケットと呼ばれる。

ＴＳパケットは制御情報を格納するＴＳヘッダと、実際のビデオ信号またはオーディオ信号を格納するＴＳペイロードとから構成される。

日本の地上デジタル放送またはＢＳ／ＣＳデジタル放送では、ＴＳヘッダは４バイトの固定長であり、ＴＳペイロードは原則として１８４バイトの固定長である。なお、ＴＳペイロードの一部は、Ａｄａｐｔａｔｉｏｎ Ｆｉｅｌｄと呼ばれる追加の制御情報を格納するために利用されることもある。

また、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ（以下、「ＢＤディスク」と記す）では、ＴＳパケットは、更に光ディスクからの読み出し時刻を指示する４バイトのタイムスタンプが先頭に付与され、１９２バイトの固定長のデータを一つの単位として、光ディスクにビデオ信号およびオーディオ信号を格納している。ＢＤディスクで用いられる方式は、ＴＳパケットがタイムスタンプ付きであることから、Ｔｉｍｅ Ｓｔａｍｐｅｄ ＴＳ方式、またはＴＴＳ方式と呼ばれ、一単位のデータはＴＴＳパケットと呼ばれる。

昨今、新たな高画質のコンテンツとして４Ｋコンテンツが注目されている。従来のＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ（ＨＤ）コンテンツは２Ｋコンテンツとも呼ばれ、その画素数は縦１９２０×横１０８０であったが、４Ｋコンテンツは、２Ｋコンテンツを縦横各々２倍として、画素数を縦３８４０×横２１６０とするものである。

４Ｋコンテンツは従来の２Ｋコンテンツと単純比較して４倍の容量が必要となるが、昨今の動画圧縮技術の進展により、おおよそ２倍程度の容量で記録することが可能であると言われている。

また、更なる高画質なコンテンツとして画素数を縦７６８０、横４３２０とする８Ｋコンテンツも検討されている。

４Ｋコンテンツまたは８Ｋコンテンツを放送波で伝送するために、新たに高度ＢＳデジタル放送および高度広帯域ＣＳデジタル放送の開発が進められている。

これらの放送では、４Ｋの場合には３５Ｍｂｐｓ（１秒間に３５Ｍビット）、８Ｋの場合には１００Ｍｂｐｓ（１秒間に１００Ｍビット）の伝送帯域が想定されている。また、これらの放送を格納するための光ディスクも検討されている。

また、高度ＢＳデジタル放送および高度広帯域ＣＳデジタル放送では、通信による伝送との連携を強化するために、新たな多重化フォーマットとしてＭＭＴ／ＴＬＶ方式が採用される。

ＭＭＴ／ＴＬＶ方式におけるデジタルデータは、従来のＭＰＥＧ２−ＴＳ方式と同様にビデオ信号およびオーディオ信号を適切なサイズに細分化し、これら細分化されたデータを再生に必要となる順番で並べ直すとともに、制御用の情報が付与されたデータである。

従来のＭＰＥＧ２−ＴＳ方式との大きな相違点は、この際の細分化のサイズが必ずしも固定ではなく、可変長となっていることである。つまり、ＭＭＴ／ＴＬＶ方式での細分化のサイズは、ＭＰＥＧ２−ＴＳ方式のような一定のサイズではなく、それぞれ異なるサイズとなっている。

さらに、ＭＭＴ／ＴＬＶ方式では従来のＭＰＥＧ２−ＴＳ方式と異なり、実際のデータが格納されている領域にアクセスするまでに、４階層のデータ構造を処理する必要がある。

ＭＭＴ／ＴＬＶ方式では、ＴＬＶパケットを受信した受信装置は、最初にＴＬＶ方式のＴＬＶパケットからヘッダ部分を処理してＩＰパケットが格納されたＴＬＶペイロードを取得する。次に、受信装置は、ＴＬＶペイロードに格納されているＩＰパケットのヘッダ部分を処理してＵＤＰパケットが格納されたＩＰペイロードを取得する。さらに、受信装置は、ＩＰペイロードに格納されているＵＤＰパケットのヘッダ部分を処理してＭＭＴＰパケットが格納されたＵＤＰペイロードを取得する。そして最後に受信装置は、ＭＭＴＰパケットのヘッダ部分を処理することで、実際のデータが格納されている領域にアクセスすることができる。

ＴＬＶパケット、ＩＰパケット、およびＵＤＰパケットの各ヘッダは放送での伝送の際には必要となる情報であるが、光ディスクへの録画の際には不要であるため、データ量削減の観点からは、これらの情報は削除したうえで記録されることが望ましい。

しかしながら、ＭＭＴ／ＴＬＶ方式では、コンテンツ全体の基準となる時刻情報はＴＬＶパケットとして格納されるＮＴＰパケットに記録されており、ＭＭＴＰパケットとしてコンテンツを記録する場合には、基準となる時刻情報はコンテンツから欠落する。このために、正しく時刻同期して再生処理ができないという課題があった。

このような課題を解決するために、本開示の一態様に係る記録装置は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信する受信部と、受信した前記コンテンツを記録媒体に記録する記録部と、を備える。

このため、記録媒体に記録したコンテンツを適切に時刻同期して再生装置に再生させることができる。

また、前記記録部は、（ｉ）前記複数の第１パケットに含まれる１以上の基準時刻情報のうちの最初の基準時刻情報を前記コンテンツの管理情報に含まれる前記コンテンツの基準時刻および前記コンテンツの再生開始時刻として記録し、（ｉｉ）前記再生開始時刻に前記コンテンツの再生時間を加算することにより算出される時刻を前記管理情報に含まれる前記コンテンツの再生終了時刻として記録してもよい。

このため、記録媒体に記録したコンテンツを適切に時刻同期して再生装置に再生させることができる。

また、前記記録部は、（ｉ）前記コンテンツの前記記録媒体における再生開始位置を示す開始位置情報を前記再生開始時刻に対応付けて前記管理情報において記録し、（ｉｉ）前記コンテンツの前記記録媒体における再生終了位置を示す終了位置情報を前記再生終了時刻に対応付けて前記管理情報において記録してもよい。

このため、容易に記録媒体に記録したコンテンツの記録位置を再生装置に特定させることが容易にできる。よって、適切に時刻同期して再生装置に再生させることができる。

また、前記複数の第１パケットのそれぞれは、ＭＭＴ／ＴＬＶ方式により多重化されたＴＬＶパケットであり、前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づく時刻を示す時刻情報であってもよい。

このため、ＭＭＴ／ＴＬＶ方式で多重化されたコンテンツを受信した場合であっても、当該コンテンツを基準時刻情報と共に記録媒体に記録するため、記録媒体に記録したコンテンツを適切に時刻同期して再生装置に再生させることができる。

また、前記記録部は、（ｉ）前記受信部により受信された前記コンテンツが有する前記複数の第１パケットから、前記第１パケットよりも上位層の複数の第２パケットと、前記基準時刻情報とを抽出し、（ｉｉ）抽出した前記複数の第２パケットと、前記基準時刻情報とを記録してもよい。

これによれば、記録媒体に記録するデータ量を削減しても、基準時刻情報を記録媒体に記録するため、記録媒体に記録したコンテンツを適切に時刻同期して再生装置に再生させることができる。

また、前記複数の第１パケットのそれぞれは、ＭＭＴ／ＴＬＶ方式により多重化されたＴＬＶパケットであり、前記複数の第２パケットのそれぞれは、ＭＭＴＰ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットであり、前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づく時刻を示す時刻情報であってもよい。

このため、ＭＭＴ／ＴＬＶ方式で多重化されたコンテンツを受信した場合であっても、当該コンテンツを基準時刻情報と共に記録媒体に記録するため、記録媒体に記録したコンテンツを適切に時刻同期して再生装置に再生させることができる。

また、本開示の一態様に係る記録方法は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信し、受信した前記コンテンツを記録媒体に記録する。

また、本開示の一態様に係る記録媒体は、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツが記録されている。

ここでは、本発明に係る実施の形態について、図面を参照しながら説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。

なお、発明者は、当業者が本開示を十分に理解するために添付図面および以下の説明を提供するのであって、これらによって特許請求の範囲に記載の主題を限定することを意図するものではない。

（実施の形態１）
（１）ＢＤディスクの構成
図１は、ＢＤディスクの構成の一例を示す図である。

本図では、第４段目にＢＤディスク１０１を示し、第３段目にＢＤディスク上のトラック１０２を示す。本図のトラック１０２は、ＢＤディスク１０１の内周から外周にかけて螺旋状に形成されているトラック１０２を横方向に引き伸ばして描画している。

ＢＤディスク１０１は、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状の記録領域を有する。ＢＤディスク１０１は、内周のリードインと外周のリードアウトとの間に論理データを記録できるボリューム領域を有する。

ボリューム領域には、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号は、論理アドレスと呼ばれる。光ディスクからのデータの読み出しは、論理アドレスが指定されることで行われる。

ここでは論理アドレスは、光ディスク上の物理的な配置においても、連続していると定義する。すなわち、論理アドレスが連続しているデータは、シークを行わずに読み出すことが可能である。

また、ＢＤディスク１０１のリードインの内側には、ＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用される。

ボリューム領域には、先頭からファイルシステムのボリューム情報が記録され、続いて映像データなどのアプリケーションデータが記録されている。

ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。ＢＤディスク１０１の場合では、ファイルシステムとして、例えばＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ）が用いられる。日常使っているＰＣ（パーソナルコンピュータ）の場合でも、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅｓ）またはＮＴＦＳ（ＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍ）と呼ばれるファイルシステムにより、ディレクトリまたはファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。

このファイルシステムにより、通常のＰＣと同じように記録されている論理データをディレクトリまたはファイル構造を使って読み出しする事が可能になっている。

ＢＤディスク１０１上のディレクトリまたはファイル構造では、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＡＶディレクトリが置かれている。ＢＤＡＶディレクトリは、ＢＤディスク１０１で扱うＡＶコンテンツや管理情報などのデータが記録されているディレクトリである。ＢＤＡＶディレクトリの配下には、ディスクに記録されているプレイリストを管理するテーブルが定義されたＩＮＦＯファイル、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦＯディレクトリ、およびＳＴＲＥＡＭディレクトリが存在する。

また、映像および音声といったＡＶコンテンツが多重化され格納されたＡＶクリップ（ＺＺＺ．Ｍ２ＴＳ、ＡＡＡ．ＭＭＴＳ）、ＡＶクリップの管理情報を格納したクリップ情報ファイル（ＺＺＺ．ＣＬＰＩ、ＡＡＡ．ＣＬＰＩ）、および、ＡＶクリップの論理的な再生経路を定義したプレイリストファイル（ＸＸＸ．ＲＰＬＳ、ＹＹＹ．ＶＰＬＳ）は、それぞれ前述のＳＴＲＥＡＭディレクトリ、ＣＬＩＰＩＮＦディレクトリ、及び、ＰＬＡＹＬＩＳＴディレクトリの下に配置される。

以下に、ＢＤＡＶディレクトリ配下に置かれる各ファイルのデータ構造について説明する。

（２）ＩＮＦＯファイルの内部構成
まずＩＮＦＯファイルについて説明する。

図２は、ＩＮＦＯファイルの内部構成の一例を示す図である。

ＩＮＦＯファイルは、図２で示すディスク情報とプレイリストテーブルとから構成される。

ディスク情報は、ディスク名、記録保護フラグ、ＰＩＮコードなどを含む。ディスク情報では、ディスク名、記録保護フラグ、ＰＩＮコードなどのＢＤディスクに記録されるコンテンツに係る情報が定義される。

ディスク名は、ディスクの名称を示す。

記録保護フラグは、ユーザがディスクに記録したコンテンツを誤って編集したり、削除したりしてしまうことを避けるためのフラグであり、編集禁止を示す。

また、ＰＩＮコードは、ディスクに記録されているコンテンツが他人などに不用意に視聴されることを避けるために視聴可能なユーザを認証するために使用することができる４桁の数字である。

プレイリストテーブルは、ＢＤディスクに格納されるすべてのプレイリストを定義するテーブルである。このテーブルには、プレイリスト番号が指定されている。ＢＤディスクの再生装置は、ＢＤディスクを再生する場合、プレイリストテーブルにあるプレイリストをプログラムメニューとして一覧化して表示させることに使用することができる。

（３）プレイリストファイルの内部構成
次に、プレイリストファイル（ＸＸＸ．ＲＰＬＳ、ＹＹＹ．ＶＰＬＳ）について説明する。

図３は、プレイリストファイルの内部構成の一例を示す図である。

プレイリストは、ＡＶクリップの再生経路を示すものである。図３に示すように、プレイリストは１つ以上のプレイアイテム１２０１から構成される。各プレイアイテム１２０１は、ＡＶクリップ１２０４に対する再生区間を示すクリップ情報ファイル１２０３を参照する。クリップ情報ファイル１２０３は、ＡＶクリップ１２０４の再生区間の再生開始時刻および再生終了時刻を示すと共に、エントリマップによって再生時刻に対応するアドレス情報を有している。エントリマップの詳細の説明は後述する。各プレイアイテムは、参照するクリップ情報ファイルが示す再生区間の範囲内で、再生経路として指定される区間の開始時刻および終了時刻を指し示す。各プレイアイテム１２０１は、それぞれプレイアイテムＩＤで識別され、プレイリスト内で再生されるべき順序で記述されている。

また、プレイリストは、再生開始点を示すエントリマーク１２０２を含んでいる。エントリマーク１２０２は、プレイアイテムで定義される再生区間内に対して付与され、図３に示すように、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。なお、一連のプレイアイテムの再生経路をメインパス１２０５とここでは定義する。

ここで、プレイリストファイルには２種類のファイルが存在する。一つはリアルプレイリスト（ＸＸＸ．ＲＰＬＳ）である。リアルプレイリストは、ＢＤディスクに記録されているＡＶクリップを管理するために使用される。

ＢＤディスクに記録されるＡＶクリップのすべての区間はリアルプレイリストのプレイアイテムと１対１で対応づけられている。よって再生装置は、リアルプレイリストを参照することでＢＤディスクに記録されるＡＶクリップすべてを再生することが可能である。またリアルプレイリストは削除されると、当該リアルプレイリストに対応付けられているＡＶクリップもまた削除されることになる。

もう一つはバーチャルプレイリスト（ＹＹＹ．ＶＰＬＳ）である。バーチャルプレイリストを用いることで、ユーザは、ＡＶクリップの再生経路を自由に編集することができる。バーチャルプレイリストでは、ＡＶクリップの一部を参照してもよいし、ＡＶクリップを重複して参照してもよい。また、バーチャルプレイリストは削除されても、バーチャルプレイリストで参照されているＡＶクリップは削除されることはない。

リアルプレイリストとバーチャルプレイリストとは拡張子によって区別することができる。また、リアルプレイリストとバーチャルプレイリストとのプレイリスト番号（ＸＸＸとＹＹＹ）は重複して存在してはいけない。

（４）プレイアイテムの内部構成
図４は、プレイアイテムの内部構成の一例を示す図である。

プレイアイテムの構成について図４を用いて説明する。

プレイアイテムには、再生するＡＶクリップを示す参照情報１３０１と、接続条件１３０２と、再生開始時刻１３０３と、再生終了時刻１３０４とが含まれている。

再生開始時刻１３０３および再生終了時刻１３０４は時間情報である。このため、再生装置は、クリップ情報ファイルのエントリマップを参照し、プレイアイテムにおいて指定された再生開始時刻１３０３および再生終了時刻１３０４に対応するクリップ内の位置情報を取得し、読み出し開始位置を特定して再生処理を行う。

接続条件１３０２は、前方プレイアイテムとの接続タイプを示している。

プレイアイテムの接続条件１３０２が「１」または「２」であることは、プレイアイテムが指し示すＡＶクリップは、そのプレイアイテムの前のプレイアイテムが指し示すＡＶクリップとシームレス接続が保証されないことを示す。プレイアイテムの接続条件１３０２が「１」であることと「２」であることとの違いは前方のプレイアイテムと現在のプレイアイテムとが参照するクリップが、同一のクリップ内で連続するＳＴＣシーケンスであるか否かの違いである。

プレイアイテムの接続条件１３０２が「３」または「４」であることは、プレイアイテムが指し示すＡＶクリップは、そのプレイアイテムの前のプレイアイテムが指し示すＡＶクリップとシームレスに接続されることが保証されることを示す。

接続条件１３０２が「４」であることは、前方プレイアイテムが参照するＡＶクリップがシームレス接続が可能な条件にて終端処理が実施された状態であることを示す。一方、接続条件１３０２が「３」であることは、前方プレイアイテムが参照するＡＶクリップがシームレス接続が可能な条件にて終端処理が実施されていない状態の場合に、接続点付近を一部切り出して終端処理を施したブリッジクリップを介することにより、シームレス接続を保証していることを示す。

（５）クリップ情報ファイルの内部構成
図５は、クリップ情報ファイルの内部構成の一例を示す図である。

続いて、クリップ情報ファイル（ＺＺＺ．ＣＬＰＩ）について、図５を用いて説明する。

クリップ情報ファイルは、ＡＶクリップの管理情報であり、ＡＶクリップと１対１に対応している。クリップ情報ファイルは、クリップ情報、ストリーム属性情報、およびエントリマップから構成される。

クリップ情報は、システムレート、再生開始時刻、および再生終了時刻から構成されている。システムレートは、ＡＶクリップの、後述するシステムターゲットデコーダのＰＩＤ（Ｐａｃｋｅｔ ＩＤ）フィルタへの最大転送レートを示す。再生開始時刻は、ＡＶクリップの先頭のビデオフレームの表示時刻（ＰＴＳ）である。再生終了時刻は、ＡＶクリップの終端のビデオフレームの表示時刻（ＰＴＳ）に１フレーム分の再生間隔が加算された時刻である。

（６）ストリーム属性情報の内部構成
図６は、ストリーム属性情報の内部構成の一例を示す図である。

ストリーム属性情報は、図６に示すように、ＡＶクリップに含まれる１以上のストリームのそれぞれの属性情報を含む。ストリーム属性情報に含まれる１以上の属性情報は、それぞれ、１以上のストリームのＰＩＤに対応している。1以上の属性情報は、ビデオストリーム（映像ストリーム）、オーディオストリーム（音声ストリーム）、および字幕ストリームのそれぞれに対応しており、互いに異なる。

ビデオストリームの属性情報は、対応するビデオストリームが圧縮された圧縮コーデック、ビデオストリームを構成する個々のピクチャデータの解像度、当該ピクチャデータのアスペクト比、ビデオストリームのフレームレートなどの情報を含む。

オーディオストリームの属性情報は、対応するオーディオストリームが圧縮された圧縮コーデック、対応するオーディオストリームに含まれるチャンネル数、当該オーディオストリームのサンプリング周波数などの情報を含む。

これらの情報は、再生装置が再生する前に行われる再生装置のデコーダの初期化などに利用される。

（７）エントリマップの内部構成
図７は、エントリマップの内部構成の一例を示す図である。

エントリマップは、図７の（ａ）に示すように、エントリマップヘッダ情報１１０１と、ＡＶクリップ内に含まれるビデオストリームの各Ｉピクチャの表示時刻を示す時刻情報と各Ｉピクチャが開始するＡＶクリップの位置情報が記載されたテーブル情報である。ＡＶクリップの位置情報は、ＭＰＥＧ−２ ＴＳ方式の場合はＳＰＮ（Ｓｏｕｒｃｅ Ｐａｃｋｅｔ Ｎｕｍｂｅｒ）で示され、ＭＭＴ方式の場合はＡＶクリップの先頭からのバイト数で示される。

ここではテーブルの１つの行で示される対となる時刻情報と位置情報をエントリポイントと呼ぶことにする。また先頭を０としてエントリポイント毎にインクリメントした値をエントリポイントＩＤ（以下、「ＥＰ＿ＩＤ」という。）と呼ぶことにする。このエントリマップを利用することにより、再生装置はビデオストリームの時間軸上の任意の地点に対応するＡＶクリップのファイル位置を特定することができるようになる。例えば、早送り、巻戻しなどの特殊再生の際には、エントリマップに登録されるＩピクチャを特定し、特定したＩピクチャから再生することによりＡＶクリップを解析することなく効率的に処理を行うことができる。また、エントリマップは、ＡＶクリップ内に多重化されるビデオストリーム毎に作られ、ＰＩＤで管理される。また、エントリマップには、先頭にエントリマップヘッダ情報１１０１が格納される。エントリマップヘッダ情報１１０１には、該当エントリマップが指すビデオストリームのＰＩＤ、エントリポイント数などの情報が格納される。

続いて、ＡＶクリップ（ＺＺＺ．Ｍ２ＴＳ、ＡＡＡ．ＭＭＴＳ）について説明する。

ＡＶクリップの方式には、ＭＰＥＧ−２ ＴＳ方式のデジタルストリーム（ＺＺＺ．Ｍ２ＴＳ）と、ＭＭＴ／ＴＬＶ方式のデジタルストリーム（ＡＡＡ．ＭＭＴＳ）との２種類の方式がある。ＭＰＥＧ−２ ＴＳ方式のＡＶクリップか、ＭＭＴ／ＴＬＶ方式のＡＶクリップかは、それぞれの拡張子によって判別することができる。なお、ストリーム番号（ＺＺＺおよびＡＡＡ）は、重複して存在してはいけない。

まずは、ＭＰＥＧ−２ ＴＳ方式のＡＶクリップについて説明する。

（８）ＴＳパケットおよびソースパケットの構成
図８は、ＡＶクリップにおけるＴＳパケットおよびソースパケットの構成の一例を示す図である。

図８に示すように、ＴＳパケット列は、複数のＴＳパケットを有する。複数のＴＳパケットのそれぞれは、ストリームを識別するＰＩＤなどの情報を持つ４ＢｙｔｅのＴＳヘッダと、データを格納する１８４ＢｙｔｅのＴＳペイロードとから構成される１８８Ｂｙｔｅ固定長のパケットであり、前述で説明したＰＥＳパケットは分割されＴＳペイロードに格納される。ＢＤの場合、ＴＳパケットに、４ＢｙｔｅのＴＰ＿Ｅｘｔｒａ＿Ｈｅａｄｅｒが付与されることで１９２Ｂｙｔｅのソースパケットが構成され、各ソースパケットがＡＶクリップに書き込まれる。ＴＰ＿Ｅｘｔｒａ＿Ｈｅａｄｅｒには、ＡＴＳ（Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ）などの情報が記載される。ＡＴＳは、当該ＴＳパケットの、後述するシステムターゲットデコーダ１５０３のＰＩＤフィルタへの転送開始時刻を示す。ＡＶクリップは、図８の下段に示すように複数のソースパケットが並んで構成される。ＡＶクリップの先頭からインクリメントする番号はＳＰＮ（ソースパケットナンバー）と呼ばれる。

また、ＡＶクリップに含まれるＴＳパケットには、映像、音声、字幕などの各ストリーム以外にもＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などが含まれる。ＰＡＴは、ＡＶクリップ中に利用されるＰＭＴのＰＩＤが何であるかを示す。ＰＡＴ自身のＰＩＤは０である。ＰＭＴは、ＡＶクリップ中に含まれる映像、音声、字幕などの各ストリームのＰＩＤと各ＰＩＤに対応するストリームの属性情報を有する。また、ＰＭＴは、ＡＶクリップに関する各種ディスクリプタを有する。ディスクリプタには、ＡＶクリップのコピーを許可または不許可を指示するコピーコントロール情報などがある。ＰＣＲは、ＡＴＳの時間軸であるＡＴＣ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋ）と、ＰＴＳおよびＤＴＳの時間軸であるＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）との同期を取るために、そのＰＣＲパケットがデコーダに転送されるＡＴＳに対応するＳＴＣ時間の情報を有する。

（９）ＰＭＴのデータ構造
図９はＰＭＴのデータ構造の一例を示す図である。

ＰＭＴの先頭には、そのＰＭＴに含まれるデータの長さなどを記したＰＭＴヘッダが配置される。その後ろには、ＡＶクリップに関するディスクリプタが複数配置される。前述したコピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、ＡＶクリップに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのＰＩＤ、ストリームの属性情報（フレームレート、アスペクト比など）が記載されたストリームディスクリプタから構成される。ストリームディスクリプタはＡＶクリップに存在するストリームの数だけ存在する。

（１０）再生装置の構成
続いて、ＭＰＥＧ−２ ＴＳ方式のＡＶクリップを格納しているＢＤディスクを再生する再生装置について説明する。

図１０は、再生装置の構成の一例を示すブロック図である。

再生装置１５００は、ＢＤドライブ１５０１、リードバッファ１５０２、システムターゲットデコーダ１５０３、管理情報メモリ１５０５、再生制御部１５０７、ユーザイベント処理部１５０９、およびプレーン加算部１５１０から構成されている。

ＢＤドライブ１５０１は、再生制御部１５０７からの要求を元にＢＤディスクからデータを読み出す。ＢＤディスクから読み出されたＡＶクリップは、リードバッファ１５０２に、ＢＤディスクから読み出されたＩＮＦＯファイル、プレイリストファイル、およびクリップ情報ファイルは、管理情報メモリ１５０５に、それぞれ転送される。

リードバッファ１５０２は、ＢＤドライブ１５０１によりＢＤディスクから読み出されたデータを格納するメモリ等で構成されたバッファである。管理情報メモリ１５０５は、ＢＤドライブ１５０１によりＢＤディスクから読み出されたＩＮＦＯファイル、プレイリストファイル、およびクリップ情報ファイルの管理情報を格納するメモリ等で構成されたバッファである。

システムターゲットデコーダ１５０３は、リードバッファ１５０２に記憶されたソースパケットに対して多重分離処理を行い、ストリームのデコード処理を行う。ＡＶクリップに含まれるストリームのデコードに必要な、コーデック種類やストリーム属性などの情報は、再生制御部１５０７から転送される。システムターゲットデコーダ１５０３は、デコードした主映像ビデオストリームおよび字幕ストリームを、それぞれのプレーンメモリである主映像プレーンおよび字幕プレーンに書き出す。またシステムターゲットデコーダ１５０３は、デコードした主音声ストリームをスピーカなどに出力する。システムターゲットデコーダ１５０３の詳細については後述する。

ユーザイベント処理部１５０９は、リモコンに入力されたユーザ操作を受け付けて、再生制御部１５０７にユーザ操作に応じた処理の実行を依頼する。例えば、リモコンで早送りボタンまたは巻戻しボタンが押された場合には、ユーザイベント処理部１５０９は、早送りボタンまたは巻き戻しボタンに対応するコマンドによる処理（つまり、早送り処理または巻き戻し処理）を実行するように再生制御部１５０７に依頼することで、現在再生しているプレイリストのＡＶクリップに対する早送り処理または巻戻し処理の実行を命令する。

再生制御部１５０７は、ＢＤドライブ１５０１およびシステムターゲットデコーダ１５０３を制御して、ＡＶクリップの再生を制御する。再生制御部１５０７は、ユーザイベント処理部１５０９からの命令に基づき、プレイリスト情報を解釈してＡＶクリップの再生を制御する。

プレーン加算部１５１０は、主映像プレーンと字幕プレーンとを重畳し、重畳することにより得られた映像をＴＶなどの画面に表示する。

（１１）システムターゲットデコーダの構成
図１１は、システムターゲットデコーダの内部構成の一例を示すブロック図である。

システムターゲットデコーダ１５０３は、ソースデパケッタイザ１５０３ａ、ＰＩＤフィルタ１５０３ｂ、ビデオデコーダ１７００、字幕デコーダ１７１０、およびオーディオデコーダ１７２０を有する。

ソースデパケッタイザ１５０３ａは、システムターゲットデコーダ１５０３に転送されるソースパケットを解釈することでＴＳパケットを取り出し、取り出したＴＳパケットをＰＩＤフィルタ１５０３ｂに送出する。ソースデパケッタイザ１５０３ａは、ＴＳパケットの送出にあたって、各ソースパケットのＡＴＳに応じてデコーダへの入力時刻を調整する。ソースデパケッタイザ１５０３ａは、具体的には、ＡＴＣカウンタが生成するＡＴＣの値と、ソースパケットのＡＴＳ値とが同一になった瞬間に、ＡＶクリップの記録レートにしたがって、そのＴＳパケットだけをＰＩＤフィルタに転送する。

ＰＩＤフィルタ１５０３ｂは、ソースデパケッタイザ１５０３ａから出力されたＴＳパケットのうち、ＴＳパケットのＰＩＤが再生に必要とされるＰＩＤに一致するものを、ＰＩＤにしたがって、ビデオデコーダ１７００、字幕デコーダ１７１０、およびオーディオデコーダ１７２０に転送する。

ビデオデコーダ１７００は、ＴＢ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍＢｕｆｆｅｒ）１７０１、ＭＢ（Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｂｕｆｆｅｒ）１７０２、ＥＢ（ＥｌｅｍｅｎｔａｒｙＳｔｒｅａｍＢｕｆｆｅｒ）１７０３、圧縮映像デコーダ１７０４、およびＤＰＢ（Ｄｅｃｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ）１７０５から構成される。

ＴＢ１７０１は、ビデオストリームを含むＴＳパケットがＰＩＤフィルタ１５０３ｂから出力された際、出力されたＴＳパケットをそのまま一時的に蓄積するためのバッファである。

ＭＢ１７０２は、ＴＢ１７０１からＥＢ１７０３にビデオストリームを出力するにあたって、一時的にＰＥＳパケットを蓄積するためのバッファである。ＴＢ１７０１からＭＢ１７０２にデータが転送される際に、ＴＳパケットのＴＳヘッダは、取り除かれる。

ＥＢ１７０３は、符号化状態にあるピクチャ（Ｉピクチャ、ＢピクチャおよびＰピクチャ）を格納するバッファである。ＭＢ１７０２からＥＢ１７０３にデータが転送される際に、ＰＥＳパケットのＰＥＳヘッダは、取り除かれる。

圧縮映像デコーダ１７０４は、ビデオエレメンタリストリームの個々のビデオアクセスユニットを所定の復号時刻（ＤＴＳ）ごとにデコードすることによりフレーム／フィールド画像を作成する。ＡＶクリップに多重化されるビデオストリームの圧縮符号化形式にはＭＰＥＧ−２、ＭＰＥＧ−４ ＡＶＣ、ＨＥＶＣ、ＶＣ１などがあるため、圧縮映像デコーダ１７０４は、ストリームの属性に応じてデコード方法を切り替える。圧縮映像デコーダ１７０４は、デコードされたフレーム／フィールド画像をＤＰＢ１７０５に転送し、表示時刻（ＰＴＳ）のタイミングで対応するフレーム／フィールド画像を主映像プレーンに書き出す。

ＤＰＢ１７０５は、復号されたフレーム／フィールド画像を一時的に保持しておくバッファである。圧縮映像デコーダ１７０４は、ピクチャ間予測符号化されたＰピクチャ、Ｂピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされＤＰＢ１７０５に一時的に保持されたピクチャを参照する。

字幕デコーダ１７１０は、ソースデパケッタイザ１５０３ａから入力されるＴＳパケットから字幕ストリームを抽出してデコードし、非圧縮のグラフィックスデータを表示時刻（ＰＴＳ）のタイミングで字幕プレーンに書き出す。

オーディオデコーダ１７２０は、緩衝バッファを有し、緩衝バッファにデータを蓄えながら、ＴＳヘッダ、ＰＥＳヘッダなどの情報を取り除いくことで音声ストリームのデコード処理を行う。そして、オーディオデコーダ１７２０は、デコード処理により得られた非圧縮のＬＰＣＭ状態のオーディオデータを表示時刻（ＰＴＳ）のタイミングで音声ミキサーに出力する。ＡＶクリップに多重化されるオーディオストリームの圧縮符号化形式には。ＡＣ３、ＤＴＳ、ＭＰＥＧ−４ ＡＡＣなどがあるため、オーディオデコーダ１７２０は、オーディオストリームの属性に応じて圧縮音声の復号化方式を切り替える。

続いて、ＭＭＴ／ＴＬＶ方式のＡＶクリップについて説明する。

（１２）ＭＭＴ／ＴＬＶ方式のストリームの構成
図１２は、ＭＭＴ／ＴＬＶ方式のストリームの構成の一例を模式的に示す図である。

ＭＭＴ／ＴＬＶ方式のストリームは、ＴＬＶパケット、ＩＰパケット、ＵＤＰパケット、およびＭＭＴＰパケットの四層の構造で構成されている。つまり、ＭＭＴ／ＴＬＶ方式は、複数階層の構造で構成されている。

当該ストリームは、１以上の可変長のＴＬＶパケットから構成される。１以上のＴＬＶパケットのそれぞれは、ＴＬＶヘッダとＴＬＶペイロードとから構成される。ＴＬＶペイロードは可変長であり、ここには可変長のＩＰパケットが格納される。

ＩＰパケットは、ＩＰヘッダとＩＰペイロードとから構成されている。ここで、ＩＰヘッダは基本的には固定長であるが、オプションデータが有る際には可変長であることもありえる。

また、４Ｋ／８Ｋ放送コンテンツで用いられるＭＭＴ／ＴＬＶ方式では、ＩＰヘッダとして圧縮形式を用いるケースもある。これは、ＩＰヘッダに記載されるサイズやアドレスなどの情報が、放送の場合にはほぼ変化がないことを利用し、一部のＩＰパケットでのみ全ての情報を記録し、それ以外のＩＰパケットでは「前と同じ」として記録する情報のサイズを減らすものである。この場合には、通常のＩＰヘッダとは長さが異なる。なお、ＩＰペイロードは可変長である。

さらにＩＰペイロードには、可変長のＵＤＰパケットが格納される。ＵＤＰパケットはＵＤＰヘッダとＵＤＰペイロードとから構成される。なお、ＵＤＰヘッダはＩＰヘッダとあわせて圧縮されるケースもある。

最後にＵＤＰペイロードには、可変長のＭＭＴＰパケットが格納される。ＭＭＴパケットは、ＭＭＴＰヘッダとＭＭＴＰペイロードとから構成される。ＭＭＴＰヘッダは、少なくともＭＭＴＰ基本ヘッダを含む。ＭＭＴＰ基本ヘッダは、基本的には固定長であるが、オプションデータがある際には可変長であることもありえる。また、ＭＭＴＰヘッダは、ＭＭＴＰ基本ヘッダのあとにＭＭＴＰ拡張ヘッダを有していることもある。ＭＭＴＰ拡張ヘッダには、たとえば暗号処理の制御に関する情報などが格納される。ＭＭＴＰ拡張ヘッダは、固定長のものもあれば、可変長のものもある。ＭＭＴＰヘッダのあとに、ＭＭＴＰペイロードが続く。ＭＭＴＰペイロードには、分割されたビデオ信号、オーディオ信号などが格納される。

（１３）ＴＬＶパケットの構成
図１３は、ＴＬＶパケットの構成の一例を示す図である。

先述したとおり、ＴＬＶパケットは、ＴＬＶヘッダとＴＬＶペイロードとから構成される。ＴＬＶヘッダの先頭には、先頭を示すデリミタとして常に二進数で０１という値が２ビット分記載される。ＴＬＶヘッダには、このデリミタに引き続いて６ビットの将来拡張用フィールドが用意される。現時点ではこのフィールドは全て１の値が設定されるが、将来何らかの理由で拡張が必要となった場合には、ここにゼロの値が記載されることもありえる。

次に、ＴＬＶヘッダには、ＴＬＶパケットのペイロード内に格納されるデータの種別を示す８ビットのｐａｃｋｅｔ＿ｔｙｐｅが格納される。

ＴＬＶペイロードの中身は、先述したとおり原則としてＩＰパケットであるが、ＩＰｖ４パケットが格納されるケースとＩＰｖ６パケットが格納されるケースとがある。また、放送の場合にはＩＰパケット内のＩＰヘッダの値がほぼ一定の値となることから、ＩＰヘッダを圧縮形式で記載する圧縮ＩＰパケットもあり得る。また、ＩＰパケットのかわりに、放送伝送路に多重化されたＩＰパケットを受信機が多重解除するための制御情報であるＴＬＶ−ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）をＴＬＶペイロードに格納することもある。さらには、リアルタイムで伝送される放送では、必ずしも全ての時間で意味のあるデータを送信しているわけではないことから、その間を埋めるためのヌルパケットをＴＬＶペイロードに格納することもありえる。先述したｐａｃｋｅｔ＿ｔｙｐｅには、これらＩＰパケット、圧縮ＩＰパケット、ＴＬＶ−ＳＩ、ヌルパケットのいずれかがＴＬＶペイロードに格納されているかを示すために用いられる。

ここで、後述する図１９に示すＴＬＶ／ＩＰ処理モジュール２０３は、ＴＬＶペイロードに格納されているデータがＴＬＶ−ＳＩであった場合には、これを制御用の情報として、制御モジュール２０４に出力する。

なお、ＴＬＶ−ＳＩは平文で伝送されるため、特に復号処理などを行う必要はない。制御モジュール２０４ではＴＬＶ−ＳＩに記載された制御情報に従って、ＴＬＶ／ＩＰ処理モジュール２０３、後述するＭＭＴ処理・復号モジュール２０５、またはデマルチ・デコードモジュール３０６の動作を制御する。

また、ＴＬＶ／ＩＰ処理モジュール２０３は、ＴＬＶペイロードに格納されているデータがヌルパケットであった場合には、単にこれを無視する。これに対して、ＴＬＶ／ＩＰ処理モジュール２０３は、ＴＬＶペイロード内の情報がＩＰパケットや圧縮ＩＰパケットであった場合には、更にＩＰパケットに関する処理を継続する。

（１４）ＩＰパケットの構造
図１４は、ＩＰパケットの構成の一例を示す図である。

図１４では非圧縮のＩＰｖ６パケットの場合のみを代表事例として示す。圧縮形式であった場合またはＩＰｖ４であった場合には異なる挙動となるが、本願の趣旨には無関係であるため説明を割愛する。

ＩＰパケットは、先述したとおりＩＰヘッダとＩＰペイロードとから構成されている。図１４に示すとおり、ＩＰヘッダの先頭にはバージョンを示す４ビットのｖｅｒｓｉｏｎが記載される。ＩＰヘッダの先頭にはＩＰｖ６であれば６が指定される。

続く８ビットのｔｒａｆｆｉｃ＿ｃｌａｓｓは、当該ＩＰパケットの取り扱いに関する優先順位を規定するフィールドである。ｔｒａｆｆｉｃ＿ｃｌａｓｓは、放送の場合には常に０として優先順位の規定なく運用される。

続く２０ビットのｆｌｏｗ＿ｌａｂｅｌは、通信の制御に関する情報を格納可能である。ｆｌｏｗ＿ｌａｂｅｌは、放送の場合にはやはり常に０として運用される。

続く１６ビットのｐａｙｌｏａｄ＿ｌｅｎｇｔｈは、ＩＰペイロードのバイト長を示す情報である。ｐａｙｌｏａｄ＿ｌｅｎｇｔｈは、可変長のＩＰペイロードを取り扱うことを示すためのフィールドである。

続く８ビットのｎｅｘｔ＿ｈｅａｄｅｒは、ＩＰヘッダに続くヘッダを示すものである。ｎｅｘｔ＿ｈｅａｄｅｒは、放送の場合には必ず次にＵＤＰヘッダがくるため、固定値である「０００１ ０００１」が記載される。

そして、ルータによる中継可能な上限数を示す８ビットのｈｏｐ＿ｌｉｍｉｔ、配信元のＩＰアドレスを示す１２８ビットのｓｏｕｒｃｅ＿ａｄｄｒｅｓｓ、配信先のＩＰアドレスを示す１２８ビットのｄｅｓｔｉｎａｔｉｏｎ＿ａｄｄｒｅｓｓがこれに続く。ｈｏｐ＿ｌｉｍｉｔ、ｓｏｕｒｃｅ＿ａｄｄｒｅｓｓおよびｄｅｓｔｉｎａｔｉｏｎ＿ａｄｄｒｅｓｓは、本願の趣旨には無関係であるため、詳細な説明を割愛する。

次にＩＰヘッダの直後には図１４に示すとおりＵＤＰパケットのＵＤＰヘッダが続く。

ＵＤＰヘッダは、各１６ビットのｓｏｕｒｃｅ＿ｐｏｒｔ、ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ、ｌｅｎｇｔｈ、およびｃｈｅｃｋ＿ｓｕｍのフィールドから構成される。このうちで、ｌｅｎｇｔｈは、このＵＤＰヘッダと以降に続くＵＤＰペイロードとを合計したサイズをバイト単位で示したものである。なお、ｓｏｕｒｃｅ＿ｐｏｒｔ、ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ、およびｃｈｅｃｋ＿ｓｕｍの各項目については、本願の趣旨には無関係であるため、説明を割愛する。

ＵＤＰヘッダのあとには可変長のＵＤＰペイロードが続く。

このＵＤＰペイロードには、可変長のＭＭＴパケットが通常は格納される。ここで通常と書いたのは、ＭＭＴパケット以外に受信装置に時刻を出力するためのＮＴＰ形式のＵＤＰパケットが出力されることがあるためである。ＩＰｖ６の場合において、宛先ＩＰアドレスとしてＦＦ０２：：１０１が指定されている場合には、このＩＰペイロードに含まれるのはＮＴＰの情報である。なお、ＮＴＰ形式のＩＰパケットについても平文で伝送されるため、特に復号処理などを行う必要はない。

これまで説明してきたＴＬＶパケット内のＴＬＶヘッダ、ＩＰパケット内のＩＰヘッダ、およびＵＤＰパケット内のＵＤＰヘッダを後述するＴＬＶ／ＩＰ処理モジュール２０３で処理することにより得られたＭＭＴ暗号ストリームは、ＭＭＴ処理・復号モジュール２０５に出力される。

（１５）ＭＭＴＰパケットの構成
図１５は、ＭＭＴＰパケットの構成の一例を示す図である。

ＭＭＴＰパケットは、ＭＭＴヘッダとＭＭＴＰペイロードとから構成される。ＭＭＴＰパケットには少なくともＭＭＴＰ基本パケットが含まれる。

ＭＭＴＰ基本パケットは、まず２ビットのｖｅｒｓｉｏｎから始まる。ｖｅｒｓｉｏｎは、ＭＭＴプロトコルのバージョン番号を示し、このフィールドには００が指定される。

次の１ビットのｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ＿ｆｌａｇには、後述するｐａｃｋｅｔ＿ｃｏｕｎｔｅｒフィールドが存在するか否かが指定される。ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ＿ｆｌａｇは、存在する場合は「１」となり、存在しない場合には「０」となる。ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ＿ｆｌａｇの値によって、ＭＭＴＰ基本ヘッダのサイズが変わることとなる。なお、ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ＿ｆｌａｇは、日本の４Ｋ／８Ｋ放送の場合には、常に「０」が指定され、ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒフィールドは運用されない。

１ビットのｅｘｔｅｎｔｉｏｎ＿ｆｌａｇは、ＭＭＴＰ拡張ヘッダが存在するか否かを指定する１ビットのフラグである。ｅｘｔｅｎｔｉｏｎ＿ｆｌａｇは、ＭＭＴＰ拡張ヘッダが存在する場合には「１」となり、ＭＭＴＰ拡張ヘッダが存在しない場合には「０」となる。ｅｘｔｅｎｔｉｏｎ＿ｆｌａｇは、その値によって、ＭＭＴＰヘッダ全体のサイズとＭＭＴＰパケット全体のサイズが変わることとなる。

６ビットのｐａｙｌｏａｄ＿ｔｙｐｅは、ＭＭＴＰペイロードの、特にヘッダ部分のデータ構造を示すフラグである。ｐａｙｌｏａｄ＿ｔｙｐｅは、ビデオ、オーディオなどの実コンテンツを格納するＭＭＴＰペイロードの場合には「０」が指定され、制御情報であるＭＭＴ−ＳＩを格納するＭＭＴＰペイロードの場合には「２」が指定される。

１６ビットのｐａｃｋｅｔ＿ｉｄは、対応するＭＭＴＰペイロードに格納されるデータの種別を識別するための情報である。このｐａｃｋｅｔ＿ｉｄは、その値によって、ペイロードに格納されているデータがビデオ信号であるか、オーディオ信号であるか、制御用の情報（ＭＭＴ−ＳＩ）であるかなどを示すことが可能である。

ここで、ＭＭＴＰペイロードに格納されているデータがＭＭＴ−ＳＩであった場合には、さらにそのＭＭＴ−ＳＩの中身が識別され、必要に応じて図１９で示す制御モジュール２０４、またはＣＡＳモジュール２０６に出力される。ここで、ＣＡＳモジュール２０６に出力する必要がある情報は、加入者毎の契約情報や共通情報の暗号を解くためのワーク鍵などを含むＥＭＭ（Ｅｎｔｉｔｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｍｅｓｓａｇｅ）、または、番組に関する情報と復号に必要となる鍵などを含むＥＣＭ（Ｅｎｔｉｔｌｅｍｅｎｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ）である。これ以外の情報は、制御モジュール２０４へ出力され、制御モジュール２０４はその内容に応じて、ＭＭＴ処理・復号モジュール２０５およびＭＭＴ暗号モジュール２０７を制御するために利用される。なお、ＭＭＴ−ＳＩは、基本的には平文で、ＭＭＴ処理・復号モジュール２０５で復号処理が行われる必要はない。ただし、ＥＭＭまたはＥＣＭは別の方式によって暗号化が行われているが、この復号はＣＡＳモジュール２０６によって実行される。このため、ＥＭＭまたはＥＣＭの復号は、ＭＭＴ処理・復号モジュール２０５で行われない。

続く１６ビットのｔｉｍｅｓｔａｍｐには、このＭＭＴパケットの先頭バイトが図１９で示す放送局２０１から送出される時刻が示され、短形式ＮＴＰタイムスタンプで記載される。なお、ＦＥＣ＿ｔｙｐｅ（２ビット）、ＲＡＰ＿ｆｌａｇ（１ビット）、ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ（３２ビット）、およびｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ（３２ビット、オプション）の各項目については、本願の趣旨には無関係であるため、説明を割愛する。

先述したように、ｅｘｔｅｎｔｉｏｎ＿ｆｌａｇに１が指定されていた場合には、ＭＭＴＰヘッダは、ＭＭＴＰ基本ヘッダに続いてＭＭＴＰ拡張ヘッダを含むこととなる。

ＭＭＴＰ拡張ヘッダは、一つのＭＭＴＰパケットに複数記載されることがあるが、図１５では一つのＭＭＴＰ拡張ヘッダが記載された例を示している。なお、ＭＭＴＰヘッダは、ＭＭＴＰ拡張ヘッダを有していないケースもありえる。

ＭＭＴＰ拡張ヘッダが存在する場合、ＭＭＴＰ拡張ヘッダは、その先頭１６ビットのｅｘｔｅｎｓｉｏｎ＿ｔｙｐｅにおいて、マルチタイプヘッダー拡張を示す「０ｘ００００」が指定される。

さらに、続く１６ビットのｅｘｔｅｎｔｉｏｎ＿ｌｅｎｇｔｈは、この情報以降に引き続くＭＭＴＰ拡張ヘッダのサイズがバイト単位で記載される。

次の１ビットのマルチヘッダー拡張終了フラグは、このＭＭＴＰ拡張ヘッダが最後のものであるか否かを示す。マルチヘッダー拡張終了フラグは、複数のＭＭＴＰ拡張ヘッダを記載する場合には、「０」が指定される。

続く１５ビットのマルチヘッダー拡張タイプは、このＭＭＴＰ拡張ヘッダに含まれる情報の種別が記載される。ＭＭＴＰペイロードに暗号化の対象となるビデオ信号やオーディオ信号が格納される場合、ＭＭＴＰ拡張ヘッダに暗号の制御に関する情報が格納される。この場合には、マルチヘッダー拡張タイプには、「０ｘ０００１」が設定される。

次に１６ビットの拡張領域長フィールドには、このＭＭＴＰ拡張ヘッダのサイズがバイト単位で記載される。

次の３ビットのリザーブ領域を飛ばして、続く２ビットのＭＭＴスクランブル制御ビットは、ＭＭＴＰペイロードに格納されるビデオ信号またはオーディオ信号が暗号化されているか否かを示し、ビデオ信号またはオーディオ信号が暗号化されている場合にはイーブン鍵およびオッド鍵のどちらを用いるかを示すこととなる。

次の１ビットのスクランブル方式識別制御ビットは、後述するスクランブル方式識別子が記録されているか否かを示す。１ビットのＭＭＴスクランブル初期値制御ビットは、後述するＭＭＴスクランブル初期値情報が記載されているか否かを示す。なお、１ビットのメッセージ認証制御ビットは本願の趣旨との関係が薄いため、説明を割愛する。

先述したスクランブル方式識別制御ビットは、「１」である場合、８ビットのスクランブル方式識別子が記載され、スクランブル方式識別子を用いて実際に利用される暗号化方式が判定される。スクランブル方式識別子が「０ｘ０１」である場合、広く利用されている鍵長１２８ｂｉｔｓのＡＥＳ暗号化方式が利用されていることが示される。

続く１６ビットのペイロード長には、後述するＭＭＴスクランブル初期値情報の長さがバイト単位で指定される。ここでＭＭＴスクランブル初期値情報の長さは、１６バイトであるため、このペイロード長には「０ｘ００１０」が指定される。

最後にＭＭＴスクランブル初期値情報には、ＡＥＳ暗号化方式を利用する場合の初期値であるカウンタ情報が記載される。なお、ＭＭＴスクランブル初期値制御ビットが０である場合、カウンタ情報としてＭＭＴペイロードスクランブル初期値情報に記載される値ではなく、ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒまたはｐａｃｋｅｔ＿ｉｄの値を用いて計算される値が利用されることとなる。

（１６）ＭＭＴ−ＳＩが格納される場合のＭＭＴＰペイロードの構成
図１６は、ＭＭＴ−ＳＩが格納される場合のＭＭＴＰペイロードの構成の一例を示す図である。

ＭＭＴＰペイロードは、更に、ヘッダ領域とペイロード領域とを有する。

ヘッダ領域の先頭には、ＭＭＴＰペイロードに格納すべきＭＭＴ−ＳＩが分割されて記録されているか否かを示す２ビットのｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒが格納される。

通常、一つのＭＭＴＰパケットは、１５００バイト前後のサイズであるが、ＭＭＴ−ＳＩとして記録すべき制御情報はこれ以上のサイズとなる可能性がある。このような場合、ＭＭＴ−ＳＩは、分割されて、複数のＭＭＴＰパケットに格納される。

ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒは、分割されずに一つのＭＭＴＰパケットに格納されているか、分割されたＭＭＴ−ＳＩの先頭部分を含むか、分割されたＭＭＴ−ＳＩの中間部分を含むか、分割されたＭＭＴ−ＳＩの末尾部分を含むかを示す。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒは、二進数で「００」である場合、分割されずに一つのＭＭＴＰパケットに格納されていることを示す。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒは、二進数で「０１」である場合、分割されたＭＭＴ−ＳＩの先頭部分を含むことを示す。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒは、二進数で「１０」である場合、分割されたＭＭＴ−ＳＩの中間部分を含むことを示す。ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒは、二進数で「１１」である場合、分割されたＭＭＴ−ＳＩの末尾部分を含むことを示す。

なお、日本の４Ｋ／８Ｋ放送の場合には、最大でも三分割までとの規定があるため、中間部分の場合には分割の２番目であり、末尾部分の場合には分割の３番目（先行する分割が先頭部分の場合には２番目）であることが保証される。

なお、１ビットのｌｅｎｇｔｈ＿ｅｘｔｅｎｔｉｏｎ＿ｆｌａｇ、１ビットのａｇｇｒｅｇａｔｉｏｎ＿ｃｏｕｎｔｅｒ、および８ビットのｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒについては本願の趣旨とは無関係なため、詳細な説明を割愛する。

（１７）ＭＭＴ−ＳＩがＭＭＴＰペイロードのペイロード領域に格納される場合の構成
図１７は、ＭＭＴＰペイロードのペイロード領域にＭＭＴ−ＳＩが格納される場合の構成の一例を示す図である。

ペイロード領域の先頭にはＭＭＴ−ＳＩの種別を示す１６ビットのｍｅｓｓａｇｅ＿ｉｄが格納される。ＭＭＴ−ＳＩには、スクランブルの制御に関するＥＣＭ／ＥＭＭ、ビデオまたはオーディオのストリームとＭＭＴＰパケット群との対応関係を示すＭＰＴ／ＰＬＴなどがあり、それぞれのＭＭＴ−ＳＩに対してｍｅｓｓａｇｅ＿ｉｄが付与されている。

続く８ビットのｖｅｒｓｉｏｎは、ＭＭＴ−ＳＩのバージョンを示す。次の３２ビットのｌｅｎｇｔｈは、ＭＭＴ−ＳＩのバイト数を示す。ここで示されるバイト数は、当該ＭＭＴＰパケットに格納されるＭＭＴ−ＳＩのバイト数ではなく、分割前のＭＭＴ−ＳＩのバイト数である。

先述したようにＭＭＴ−ＳＩが最大３分割して格納される場合、ｌｅｎｇｔｈフィールドは、分割された複数のＭＭＴＰパケットのうち先頭のＭＭＴＰパケットのみに格納される。

（１８）ＭＭＴ−ＳＩが複数に分割されて格納される場合の構成
図１８は、ＭＭＴ−ＳＩが複数に分割されて格納される場合の複数に分割されたＭＭＴ−ＳＩと複数のＭＭＴ−ＳＩを格納する複数のＭＭＴＰパケットとの関係の一例を示す図である。

一つのＭＭＴ−ＳＩは、先頭部分に配置されるｍｅｓｓａｇｅ＿ｉｄ、ｖｅｒｓｉｏｎおよびｌｅｎｇｔｈを含むヘッダ領域と、ヘッダ領域の後に配置される実際のｍｅｓｓａｇｅ部とから構成される。ＭＭＴ−ＳＩは、複数（図１８では３つ）に分割される場合、このデータ構造のままで分割される。よって、ＭＭＴ−ＳＩのヘッダ領域のｌｅｎｇｔｈのフィールドは、先頭のＭＭＴＰパケットのみに格納される。

ここで、これまで図１５および図１７で説明したとおり、ＭＭＴＰパケット自身には、ＭＭＴ−ＳＩの先頭に記載されるｌｅｎｇｔｈの情報を除いてＭＭＴＰパケットまたはＭＭＴＰパケットのペイロードに関する長さを示す情報が存在しないことに注意する必要がある。なお、ＭＭＴＰパケットにＭＭＴ−ＳＩではなくＡ／Ｖデータが格納される場合のＭＭＴＰペイロードの先頭領域には、当該ＭＭＴＰパケットに格納されるＡ／Ｖデータのサイズが格納されるため、この問題は発生しない。

こうして得られたＭＭＴ−ＳＩは、先述したｍｅｓｓａｇｅ＿ｉｄの値に応じて制御モジュール２０４またはＣＡＳモジュール２０６に出力され、各々適切な処理が行われる。

なお、先述したとおり、ＭＭＴ−ＳＩが分割されている場合には、ＭＭＴ処理・復号モジュール２０５自身ではＭＭＴＰパケットの長さを判断することはできない。しかしながら、ＴＬＶ／ＩＰ処理モジュール２０３から各ＭＭＴＰパケットの長さに関する情報をあわせて取得することにより、ＭＭＴ処理・復号モジュール２０５では適切な処理が可能である。

（１９）記録装置の構成
図１９は、実施の形態に係る記録装置の構成の一例を示すブロック図である。

記録装置２０２は、ＴＬＶ／ＩＰ処理モジュール２０３、制御モジュール２０４、ＭＭＴ処理・復号モジュール２０５、ＣＡＳモジュール２０６、ＭＭＴ暗号モジュール２０７、記録モジュール２０８および記録媒体２０９を備える。

ＡＶコンテンツは、ＭＭＴ／ＴＬＶ方式で多重化された暗号ストリームとして放送局２０１から記録装置２０２へと伝送される。記録装置２０２は、例えば、Ｂｌｕ−ｒａｙ（登録商標）レコーダである。また、記録装置２０２は、ＵＳＢ接続されるＨＤＤを外付けすることで、テレビ受信機、セットトップボックス（ＳＴＢ）などであってもよい。

放送局２０１から受信した放送波は、チューナー（図示しない）でアナログ信号からデジタル信号へと変換され、ＭＭＴ／ＴＬＶ方式の暗号ストリームとしてＴＬＶ／ＩＰ処理モジュール２０３へと送られる。

ＴＬＶ／ＩＰ処理モジュール２０３は、受信したＭＭＴ／ＴＬＶ方式のストリームを、必要に応じてＴＬＶ−ＳＩまたはＮＴＰの処理を行いながら、ＴＬＶヘッダ、ＩＰヘッダ、ＵＤＰヘッダを除去し、さらにＴＬＶ−ＮＵＬＬを廃棄する処理を行う。ＴＬＶ／ＩＰ処理モジュール２０３は、上記処理により得られたＭＭＴ暗号ストリームをＭＭＴ処理・復号モジュール２０５に出力する。

こうしてＭＭＴ処理・復号モジュール２０５に出力されたＭＭＴ暗号ストリームは、ＭＭＴ処理・復号モジュール２０５によって一旦復号化される。ＭＭＴ処理・復号モジュール２０５によって復号化されることで得られた整形ＭＭＴ平文ストリームは、ＭＭＴ暗号モジュールに出力され、ＭＭＴ暗号モジュール２０７により再度暗号化されることによって録画対象のデータとなる。録画対象のデータは、記録モジュール２０８を介して記録媒体２０９に記録される。

（２０）ＭＭＴ／ＴＬＶ方式の放送コンテンツの録画する部分
図２０は、ＭＭＴ／ＴＬＶ方式の放送コンテンツのうちの録画する部分を説明するための図である。

図２０に示すように、受信したＭＭＴ／ＴＬＶ方式の放送コンテンツのデータのうち、灰色で示された部分のみが録画の対象となる。

ＭＭＴ／ＴＬＶ方式の放送コンテンツのデータには、ＴＬＶ−ＮＵＬＬのように明らかに録画時には廃棄しても問題がないデータに加えて、伝送制御のために必要となるＴＬＶ−ＳＩ、端末の時刻あわせのために必要となるＮＴＰも含まれる。つまり、ＴＬＶ−ＮＵＬＬ、ＴＬＶ−ＳＩ、ＮＴＰなどのデータは、録画したコンテンツを再生するためには必要のないデータであり、録画領域を効率的に利用するためには、廃棄しても良い。

ＴＬＶヘッダ、ＩＰｖ６ヘッダ、ＵＤＰヘッダ、圧縮ＩＰヘッダなどの各ヘッダも、すべて伝送制御のために各ＭＭＴＰパケットに付与された情報であり、録画した後で再生を行うにあたっては不要なデータであるので、これらのデータは、録画領域の効率活用のために廃棄してもよい。

結果として、記録すべきデータは、ＭＭＴ−ＳＩを含むＭＭＴＰパケット、および、Ａ／Ｖデータを含むＭＭＴＰパケットのみとなる。

なお、ＭＭＴ−ＳＩは、ＥＣＭ／ＥＭＭのように、スクランブルされた放送を復号する際には利用するが、いったん平文として再度別の鍵情報を用いて再暗号化した上で録画したコンテンツを再生する場合には利用しないデータを含む。このため、ＭＭＴ−ＳＩに含まれるデータであっても、コンテンツを再生する場合には利用しないデータについては記録しなくてもよく、録画領域の効率活用のために廃棄しても良い。

また、Ａ／Ｖデータも必ずしも全てが記録される必要はない。Ａ／Ｖデータのうちたとえば副音声用のオーディオデータについては録画せずに廃棄してもよいし、データ放送用コンテンツなどの付加的なコンテンツデータも録画せずに廃棄してもよい。

このように、不要なデータを削除した上でＭＭＴ処理・復号モジュール２０５に送付されたＭＭＴＰパケット群は、ＡＥＳ−ＣＴＲモードを用いて復号される。

さて、ここで先述したとおり、Ａ／Ｖデータの場合にはＭＭＴＰペイロードに格納されるデータのサイズは必ずＭＭＴＰペイロード先頭の領域に記録される。このため、記録装置２０２は、ひとつのＭＭＴＰパケットから正しくＡ／Ｖデータを取り出し、次のＭＭＴＰパケットの先頭位置を特定することが可能である。同様にＭＭＴ−ＳＩを格納するＭＭＴＰパケットについても、ＭＭＴ−ＳＩが分割記録されていなければ、記録装置２０２は、正しくＭＭＴ−ＳＩのメッセージを取り出し、次のＭＭＴＰパケットの先頭位置を特定することが可能である。しかしながら、ＭＭＴ−ＳＩが２分割、または３分割されている場合には、これが実現できなくなる。

（２１）ＭＭＴ−ＳＩが分割格納される例
図２１は、ＭＭＴ−ＳＩが複数のＭＭＴＰパケットに分割して格納される場合を説明するための図である。なお、以降では、分割されたＭＭＴ−ＳＩを分割ＭＭＴ−ＳＩとも言う。

図２１の例では、一つのＭＭＴ−ＳＩメッセージが二つのＭＭＴＰパケットに分割されて記録されている。このケースでは、ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒを運用しないことにより固定長となるＭＭＴＰ基本ヘッダと、固定サイズの領域と長さ指定つきの領域を持つＭＭＴＰ拡張ヘッダとにより、記録装置２０２は、一つ目のＭＭＴＰパケットの先頭から、順にＭＭＴＰ拡張ヘッダの先頭、ＭＭＴＰペイロードの先頭へとアクセスすることが可能である。記録装置２０２は、一つ目のＭＭＴＰペイロードの中でも、ｆａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒなどから構成され、必ず固定長である先頭のヘッダ領域を識別して、ＭＭＴ−ＳＩが格納された領域の先頭までアクセスすることも可能である。記録装置２０２は、さらにＭＭＴ−ＳＩの先頭に記載されたｍｅｓｓａｇｅ＿ｉｄ、ｖｅｒｓｉｏｎ、およびｌｅｎｇｔｈも取得可能である。しかしながら、ここで取得できるｌｅｎｇｔｈは、一つ目のＭＭＴＰパケットのＭＭＴＰペイロードの長さではなく、分割される前のＭＭＴ−ＳＩメッセージの長さを示している。このため、記録装置２０２は、ｌｅｎｇｔｈを取得できても、ＭＭＴＰペイロードがどこで終わるかを判断することができず、次のＭＭＴＰ基本ヘッダの冒頭位置も識別ができない。

このような問題を解決するために、本実施の形態に係る記録装置２０２は、分割されたＭＭＴ−ＳＩを再統合したうえでＭＭＴＰパケットに格納する。

（２２）分割ＭＭＴ−ＳＩの再構成する例
図２２は、分割ＭＭＴ−ＳＩを再構成する場合の一例を説明するための図である。

図２２の例では、一つのＭＭＴ−ＳＩメッセージが三つのＭＭＴＰパケットに分割されて記録されている。一つ目と三つ目のＭＭＴＰパケットは、ＭＭＴＰ基本ヘッダに加えてＭＭＴＰ拡張ヘッダが記録されており、二つ目のＭＭＴＰパケットにはＭＭＴＰ基本ヘッダのみが記録されている。このようなケースにおいて、ＭＭＴ処理・復号モジュール２０５は、各ＭＭＴＰペイロードに格納された部分的なＭＭＴ−ＳＩメッセージを取得し、これを再構成して一つのＭＭＴ−ＳＩメッセージとする。そして、ＭＭＴ処理・復号モジュール２０５は、一つのＭＭＴ−ＳＩメッセージを一つのＭＭＴＰパケットに格納する。なお、図２２では、ＭＭＴＰ拡張ヘッダを持たないＭＭＴＰパケットとして再構成しているが、ＭＭＴＰ拡張ヘッダを含めて再構成しても良い。また、先に述べたようにＭＭＴＰパケット群となった状態では、既に分割されたＭＭＴ−ＳＩメッセージを格納した各ＭＭＴＰパケットの長さがわからないが、これは各ＭＭＴＰパケットのサイズ情報をＴＬＶ／ＩＰ処理モジュール２０３から入手することで処理可能である。

（２３）分割ＭＭＴ−ＳＩを再構成する別の例
図２３は、分割ＭＭＴ−ＳＩを再構成する場合の別の一例を説明するための図である。

場合によっては、再構成前のＭＭＴＰパケット群と再構成後のＭＭＴＰパケット群とのサイズが変わらないことが望ましい場合もある。これは、後述するタイムサーチマップを作成する際に再生時間（ビデオのフレーム数）とストリーム内でのアドレス（先頭からのバイト数）とが必要となるためである。この処理は、リアルタイムに行う必要があり、通常ＭＭＴ処理・復号モジュール２０５で、ＭＭＴ−ＳＩの再構成処理を行う前に処理される。このため、データサイズが処理前と処理後とで変わることは好ましくない。この問題を解決するために、図２３で示すように再構成前のＭＭＴＰパケット群と長さを合わせるためにＮＵＬＬデータを含むＭＭＴＰパケットを挿入してもよい。なお、分割されたＭＭＴＰパケット群の場合には少なくとも余分なＭＭＴＰ基本ヘッダがあるため、ＮＵＬＬデータを含むＭＭＴＰパケットを挿入したとしても、挿入後のほうが長くなることはない。

（２４）ＭＭＴＰパケットの再構成処理
図２４は、ＭＭＴＰパケットの再構成処理の一例を示すフローチャートである。

最初に、記録装置２０２のＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０１において、処理対象となるＭＭＴＰパケットのデータをひとつ読み出す。なお、本フローチャートでは示していないが、放送録画の終了時点では、ＭＭＴＰパケットのデータが読み出せなくなるため、フローチャートのループを抜け出すことになる。

ＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０２において、ステップＳ１５０１で読み出したＭＭＴＰパケットについて、分割ＭＭＴ−ＳＩを含むＭＭＴＰパケットか否かを判定する。

ＭＭＴ処理・復号モジュール２０５は、ＭＭＴＰパケットに分割ＭＭＴ−ＳＩが含まれないと判定した場合、つまりステップＳ１５０２においてＮｏの場合、ステップＳ１５０３に進む。具体的には、ＭＭＴ処理・復号モジュール２０５は、ＭＭＴＰパケットが、通常のＡ／Ｖデータを含むパケットである場合、または、ＭＭＴ−ＳＩを含むＭＭＴＰパケットであったとしても分割ＭＭＴ−ＳＩではない場合、ステップＳ１５０３を行う。

ＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０３において、対象となったＭＭＴＰパケットを特に加工せずにそのまま、後工程であるＭＭＴ暗号モジュール２０７に送信する。

一方で、ＭＭＴ処理・復号モジュール２０５は、ＭＭＴＰパケットに分割ＭＭＴ−ＳＩが含まれると判定した場合、つまりステップＳ１５０２においてＹｅｓの場合、ステップＳ１５０４に進む。

ＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０４において、当該ＭＭＴＰパケットが末尾のＭＭＴ−ＳＩを含むか否かを判定する。先述したとおり、この判定はｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒを参照することによって可能である。ＭＭＴ処理・復号モジュール２０５は、ここで末尾ではないと判定した場合、つまり、ステップＳ１５０４でＮｏの場合、ステップＳ１５０５に進む。

ＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０５において、当該ＭＭＴＰパケットの中で部分的に記録されているＭＭＴ−ＳＩメッセージをバッファに保持させる。この場合は、ＭＭＴ処理・復号モジュール２０５は、当該ＭＭＴＰパケットを出力せずに一旦破棄する。なお、ＭＭＴ処理・復号モジュール２０５は、ＭＭＴ−ＳＩメッセージの部分をバッファに蓄積するとしたが、当該ＭＭＴＰパケットがＭＭＴ−ＳＩメッセージの先頭を含む場合には、ＭＭＴＰ基本ヘッダを含めてバッファに格納しても良い。これは、後ほどステップＳ１５０６にてＭＭＴＰパケットを出力する際に、ここで格納しておいたＭＭＴＰ基本ヘッダを利用するためである。また、ＭＭＴ処理・復号モジュール２０５は、異なるｍｅｓｓａｇｅ＿ｉｄを持ったＭＭＴ−ＳＩメッセージを、当該ＭＭＴ−ＳＩメッセージが各々分割された上で入り混じった状態で、ステップＳ１５０１において取得するケースもありえる。この場合、ＭＭＴ処理・復号モジュール２０５は、Ｓ１５０５で述べたバッファに、互いに異なるｍｅｓｓｅｇｅ＿ｉｄを有する複数のＭＭＴ−ＳＩを保持させる。

最後に、ＭＭＴ処理・復号モジュール２０５は、ＭＭＴＰパケットが末尾のＭＭＴ−ＳＩを含むＭＭＴＰパケットであると判定した場合、つまりステップＳ１５０４でＹｅｓの場合、ステップＳ１５０６に進む。ＭＭＴ処理・復号モジュール２０５は、ステップＳ１５０６において、ＭＭＴＰパケットを再構成し、再構成したＭＭＴＰパケットを出力する。再構成については先に図２２で示したとおり、それまでにステップＳ１５０５で示すバッファに格納されたＭＭＴ−ＳＩのメッセージに、さらに末尾のＭＭＴ−ＳＩのメッセージを付加することにより得られた一つのＭＭＴＰパケットを、後工程であるＭＭＴ暗号モジュール２０７に出力する。なお、ステップＳ１５０１で取得された当該ＭＭＴＰパケットはここで破棄される。また、ＭＭＴ暗号モジュール２０７に出力されるＭＭＴＰパケットのＭＭＴＰ基本ヘッダには、ステップＳ１５０１で取得された当該ＭＭＴＰパケットのＭＭＴＰ基本ヘッダが利用されるか、先にステップＳ１５０５でバッファに保持しておいたＭＭＴ−ＳＩの先頭を含むＭＭＴＰパケットのＭＭＴＰ基本ヘッダが利用される。また、先に図２３で示したとおり、更に、再構成したＭＭＴＰパケットの後にＮＵＬＬデータを含むＭＭＴＰパケットを出力しても良い。なお、この際にはＭＭＴ−ＳＩメッセージとして出力したＭＭＴＰパケットのＭＭＴＰ基本ヘッダと同様のＭＭＴＰ基本ヘッダを利用するのが基本であるが、そのｔｉｍｅｓｔａｍｐだけは調整する必要がある。つまり、ｔｉｍｅｓｔａｍｐには、先行するＭＭＴＰパケットのサイズと転送レートに応じて適切な値が記録される。

こうして、整形された平文のＭＭＴストリームは、図１９で示すＭＭＴ暗号モジュール２０７に出力される。ＭＭＴ暗号モジュール２０７は、このＭＭＴストリームを６１４４バイト単位のＡｌｉｇｎｅｄ Ｕｎｉｔで暗号化する。

（２５）Ａｌｉｇｎｅｄ Ｕｎｉｔの暗号方法
図２５は、Ａｌｉｇｎｅｄ Ｕｎｉｔ単位での暗号方法を説明するための図である。

録画対象のコンテンツは、ＭＭＴ暗号モジュール２０７において、タイトル鍵（図ではＫｔと記載）と呼ぶデータを用いて暗号化される。ＭＭＴ暗号モジュール２０７は、各６１４４バイトのデータを、先頭の１６バイトと残る６１２８バイトとに分離する。ＭＭＴ暗号モジュール２０７は、先頭の１６バイトを対象として、先述したタイトル鍵を用いてＡＥＳ暗号方式の暗号処理であるＡＥＳ＿Ｅで処理する。ＭＭＴ暗号モジュール２０７は、こうして得られたデータをさらに先頭１６バイトのデータとＸＯＲしたうえで、これを鍵として残る６１２８バイト分のデータをＡＥＳ−ＣＢＣモードで暗号化する。ＭＭＴ暗号モジュール２０７は、こうして得られた暗号文のデータに先頭１６バイトのデータを付け加えることで、６１４４バイト分の暗号文を得る。この方式は、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃの著作権保護方式であるＡＡＣＳにて採用されている方式であり、既に様々なＬＳＩで実装されている。つまり、暗号方式に、上記方式を用いることで新たな開発を行うことなく、暗号化の適用が可能である。なお、本願では過去の実装を活用するという目的でＡｌｉｇｎｅｄ Ｕｎｉｔ単位での暗号化を行うと記載したが、本願としてはこれに限定するものではない。例えば、光ディスクの一般的なセクタサイズである２０４８バイト単位、あるいは光ディスク上のエラー訂正符号ブロック（ＥＣＣブロック）のサイズである６４Ｋバイト単位でＡＥＳ−ＣＢＣモードを用いて暗号化するという方法なども想定されうる。

こうして得られた記録用ＭＭＴ暗号ストリームは、暗号化の際に用いたタイトル鍵とともに記録モジュール２０８に出力される。記録モジュール２０８は、タイトル鍵と記録用ＭＭＴ暗号化ストリームとをあわせて記録媒体２０９に記録する。ここで、記録媒体２０９は、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃなどの光ディスクを想定するが、これに限るものではない。記録装置２０２がテレビである場合には、記録媒体２０９は、外付けのＵＳＢ ＨＤＤであってもよい。また、記録装置２０２がレコーダである場合にも、記録媒体２０９は、必ずしも可搬型の光ディスクではなく、機器に内蔵されたＨＤＤであってもよい。

また、図１９では、単純化のためにタイトル鍵がそのまま記録媒体に格納されるかのように記載したが、セキュリティ観点では、タイトル鍵は更なる保護を加えた上で記録媒体２０９に記録されるべきである。例えば、記録媒体２０９が内蔵ＨＤＤの場合には、機器が持つデバイス鍵を用いて暗号化されたタイトル鍵が記録されることが望ましい。また、記録媒体２０９がＢｌｕ−ｒａｙ（登録商標） Ｄｉｓｃをはじめとする光ディスクの場合には、メディアごとに付与された固有のメディア鍵で暗号化されたタイトル鍵が記録されることが望ましい。

（２６）光ディスク上でのコンテンツの構成
図２６は、光ディスク上での記録用ＭＭＴ暗号ストリームの記録形態を示す図である。

光ディスク上では、記録用ＭＭＴ暗号ストリームは、ストリーム毎に固有の番号を付与され、ストリームファイルとして例えば「ＸＸＸＸＸ．ＭＭＴＳ」というファイル名で記録される。ここで「ＸＸＸＸＸ」は５桁の番号であり、この番号で各ファイルが識別されうる。ストリームファイルは、先述したような６１４４バイト単位のＡｌｉｇｎｅｄ Ｕｎｉｔに分割されており、分割された複数のＡｌｉｇｎｅｄ Ｕｎｉｔの各々が図２５で示した暗号方式で暗号化されている。なお、図示はしていないが、各ストリームファイルに対応するタイトル鍵も同様に当該光ディスクに記録されている。当該タイトル鍵も先述したとおり、当該メディアに付与されたメディア鍵で暗号化された上で、暗号化タイトル鍵として記録されていることが望ましい。

また、当該ストリームファイルを先頭からリアルタイムに通常再生していく場合には不要であるが、早送り、巻き戻し、時間指定位置からの再生などの特殊再生を行う場合にはタイムサーチマップと呼ぶデータ構造をあわせて光ディスクに格納しておくことが好ましい。タイムサーチマップでは、圧縮符号化されたビデオストリームにおける圧縮単位（ＧＯＰ：Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅなどと呼ぶ）ごとに、ファイル先頭からの記録位置とフレーム数とが対応付けて記録される。これによって、再生装置は、記録媒体における、たとえば先頭から１０００フレーム目の記録位置を瞬時に識別し、１０００フレーム目から再生することが容易にできる。

なお、従来一般的に利用されていた多重化方式であるＭＰＥＧ２−ＴＳ方式では、タイムスタンプつきの場合には１９２バイト単位のデータ構造となっている。ここでの記録位置は、このタイムスタンプ付ＴＳパケットの単位で指定することができる。ＭＰＥＧ２−ＴＳでは、この単位を用いて、５０ＧＢの光ディスクでも、３２ビットで十分に記録位置を表現することができる。

一方、多重化方式としてＭＭＴ／ＴＬＶ方式を用いる場合には、ＭＭＴＰパケットが可変長の構造となっているため、パケット単位で記録位置を指定することは難しい。よって、ファイルの記録位置は、バイト単位で指定される。このため５０ＧＢの光ディスクでは、ファイルの記録位置を３２ビットで表現することが難しく、たとえば４０ビットで表現することが必要となる。ただし、３２ビットでの表現でもカウンタをサイクリック表現にするなどの工夫を行えば、ファイルの記録位置をバイト単位で表現することが可能となる。

（２７）再生装置の構成
図２７は、実施の形態に係る再生装置の構成の一例を示すブロック図である。

再生装置３０２は、記録媒体２０９に格納された記録用ＭＭＴ暗号ストリームをタイトル鍵を用いて復号しながら再生する。

最初に再生装置３０２は、記録媒体２０９からタイトル鍵を読み出し、読み出したタイトル鍵をＭＭＴ処理・復号モジュール３０５にセットする。この鍵が、記録装置２０２におけるスクランブル鍵の代わりとなる。

次に再生装置３０２は、記録媒体２０９から記録用ＭＭＴ暗号ストリームを読み出し、ＭＭＴ処理・復号モジュール３０５に出力する。ここでＭＭＴ処理・復号モジュール３０５は、セットされたタイトル鍵を用いてＡｌｉｇｎｅｄ Ｕｎｉｔ単位で暗号化されている記録用ＭＭＴ暗号ストリームを復号する。

なお、再生装置３０２のＭＭＴ処理・復号モジュール３０５は、記録装置２０２のＭＭＴ処理・復号モジュール２０５と同様の構成である。ＭＭＴ処理・復号モジュール３０５において復号されたＭＭＴ平文ストリームは、デマルチ・デコードモジュール３０６に出力される。

（２８）Ａｌｉｇｎｅｄ Ｕｎｉｔの復号方法
図２８は、Ａｌｉｇｎｅｄ Ｕｎｉｔ単位での復号方法を説明するための図である。

録画対象のコンテンツは、タイトル鍵（図ではＫｔと記載）と呼ぶデータを用いて暗号化されている。ＭＭＴ処理・復号モジュール３０５は、各６１４４バイトのデータを先頭の１６バイトと残る６１２８バイトとに分離する。ＭＭＴ処理・復号モジュール３０５は、先頭の１６バイトを対象として、先述したタイトル鍵を用いてＡＥＳ暗号方式の暗号処理であるＡＥＳ＿Ｅで処理する。ＭＭＴ処理・復号モジュール３０５は、こうして得られたデータをさらに先頭１６バイトのデータとＸＯＲしたうえで、これを鍵として残る６１２８バイト分のデータをＡＥＳ−ＣＢＣモードで復号する。ＭＭＴ処理・復号モジュール３０５は、こうして得られた平文のデータに先頭１６バイトのデータを付け加えることで、６１４４バイト分の平文を得る。

こうして得られた平文のＭＭＴストリームは、ＭＭＴ処理・復号モジュール３０５で処理される。記録装置２０２の場合には、特に分割されたＭＭＴ−ＳＩを含むＭＭＴＰパケットを正しく処理するために、各ＭＭＴＰパケットのサイズについてＴＬＶ／ＩＰ処理モジュール２０３からの情報が必要であった。これに対して、再生装置３０２で扱う記録用ＭＭＴ暗号ストリームの場合には、各ＭＭＴＰパケットにおいてペイロードのサイズに関する情報が必ず存在していることが保証される。これにより、ＭＭＴ処理・復号モジュール３０５は、正しくＭＭＳ−ＳＩを取り出して制御モジュール３０４に出力すること、または、残るＡ／Ｖデータを含むＭＭＴ平文ストリームをデマルチ・デコードモジュール３０６に出力することが可能である。こうして通知されたＡ／Ｖデータは、デマルチ・デコードモジュール３０６で復号され、表示モジュール３０７で表示される。

（２９）混在フラグ
以上で説明したように、ＭＰＥＧ−２ ＴＳ方式のＡＶクリップとＭＭＴ／ＴＬＶ方式のＡＶクリップとでは、記録するデータ構造から再生するための復号処理方法までの差異が種々存在する。

ＡＶクリップと１対１対応で管理するリアルプレイリストにおいては、同一プレイリスト内でＭＭＴ／ＴＬＶ方式とＭＰＥＧ−２ ＴＳ方式とが混在して管理されることはない。一方のユーザの編集により作成されるバーチャルプレイリストでは、ＭＰＥＧ−２ ＴＳ方式のＡＶクリップとＭＭＴ／ＴＬＶ方式のＡＶクリップとが混在するように作成してもよい。

図３で説明したように各プレイアイテムは、いずれかのＡＶクリップを参照するが、バーチャルプレイリストの再生では、バーチャルプレイリストに記載されるプレイアイテムが順次連続して再生される。このため、バーチャルプレイリストに記載されるプレイアイテムが切り替わるところでＡＶクリップの記録方式が別の記録方式に変化したとき、再生装置は、その復号処理を切り替えなければ、切り替わった後のＡＶクリップを正しく再生することができない。したがって、再生装置は、多重化方式の異なるＡＶクリップが混在しているバーチャルプレイリストによる再生を行う場合、あらかじめ混在することを知る必要がある。

そこで、図２９に示すようにバーチャルプレイリストファイルの中にプレイリスト情報としてＴＳ／ＭＭＴ混在フラグを設ける。図２９は、ＭＰＥＧ−２ＴＳ方式とＭＭＴ／ＴＬＶ方式とが混在する場合のプレイリストの内部構成の一例を示す図である。ＴＳ／ＭＭＴ混在フラグが真（ＴＲＵＥ）を示すならば、当該バーチャルプレイリストの中にＭＰＥＧ−２ ＴＳ方式のＡＶクリップとＭＭＴ／ＴＬＶ方式のＡＶクリップとの両方が存在することを表す。このため、再生装置は、両方の方式のＡＶクリップを再生するための復号処理をあらかじめ準備することに役立つ。また、再生装置によっては、ＭＰＥＧ−２ ＴＳ方式のみ、ＭＭＴ／ＴＬＶ方式のみしか再生できないケースもありうる。このような再生装置では、前記混在フラグを確認することにより、当該バーチャルプレイリストを再生候補として提示しないという方法も取ることが可能となる。

（３０）混在フラグによる再生処理
図３０は、ＴＳ／ＭＭＴ混在フラグによる再生装置の再生処理の一例を示すフローチャートである。

再生装置は、ステップＳ３００１において、プレイリスト情報を取得する。

再生装置は、ステップＳ３００２において、取得したプレイリスト情報からＴＳ／ＭＭＴ混在フラグの値を取得し、ＴＳ／ＭＭＴ混在フラグが真であるか否かを判定することで、これから再生を開始するプレイリストに多重化方式が混在するか否かを判定する。

再生装置は、ＴＳ／ＭＭＴ混在フラグの値が真（ＴＲＵＥ）である場合、つまりステップＳ３００２においてＹｅｓである場合、バーチャルプレイリストにはＭＰＥＧ−２ ＴＳ方式のＡＶクリップとＭＭＴ／ＴＬＶ方式のＡＶクリップとの両方が存在するため、再生開始時に両方のデコーダの起動をスタンバイする（Ｓ３００３）。

その後、再生装置は、ステップＳ３００４において、バーチャルプレイリストの再生開始にあたり、各プレイアイテムが参照するＡＶクリップがいずれの多重化方式であるかをチェックし、ＡＶクリップが対応する多重化方式に応じてデコーダを切替えて再生する。

一方、再生装置は、ＴＳ／ＭＭＴ混在フラグの値が偽（ＦＡＬＳＥ）である場合、つまりステップＳ３００２においてＮｏである場合、バーチャルプレイリストにはＭＰＥＧ−２ ＴＳ方式のＡＶクリップおよびＭＭＴ／ＴＬＶ方式のＡＶクリップの一方だけであると判断できる。このため、再生装置は、ステップＳ３００５において、バーチャルプレイリストの再生開始にあたり、先頭のプレイアイテムが参照するＡＶクリップの多重化方式をチェックし、当該ＡＶクリップの多重化方式に応じたデコーダを起動する。再生装置は、２番目以降のプレイアイテムの再生においては、先頭のプレイアイテムで用いたのと同じ多重化方式と同じであるので、混在時のようにプレイアイテムの切り替わりの度に多重化方式をチェックする必要はなくなる。

なお、先に述べた混在のケースは、多重化方式の他にも、異なるビデオ解像度のＡＶクリップが混在するケースにも利用できる。ビデオ解像度が異なる大きさに変化する場合にも、復号処理に大きく影響を及ぼすことがあるためである。

従来の２Ｋコンテンツに比べ、４Ｋ、８Ｋ解像度のビデオコンテンツを再生するときには、復号されるピクチャを格納するのに、それぞれ４倍、１６倍のメモリサイズが必要となる。

８Ｋビデオを復号できる再生装置では、８Ｋ解像度のピクチャを格納するメモリサイズを確保されるが、８Ｋコンテンツを含まないプレイリストを再生するのに、常時８Ｋ解像度のピクチャに必要なメモリサイズを確保する必要はなく、結果としてプレイリストで再生される最も大きい解像度のビデオを再生するのに必要なメモリサイズさえ確保されればよい。したがって、プレイリスト情報に、どの解像度のビデオコンテンツが存在するかを示す情報を記載することにより、再生装置は、あらかじめ適切なメモリサイズを設定することが可能となる。

この場合、プレイリスト情報には、例えば２Ｋコンテンツ存在フラグ、４Ｋコンテンツ存在フラグ、８Ｋコンテンツ存在フラグ、として記載され、それぞれ２Ｋ解像度のビデオコンテンツを含むならば２Ｋコンテンツ存在フラグは真（ＴＲＵＥ）を示し、４Ｋ解像度のビデオコンテンツを含むならば４Ｋコンテンツ存在フラグは真（ＴＲＵＥ）を示し、８Ｋ解像度のビデオコンテンツを含むならば８Ｋコンテンツ存在フラグは真（ＴＲＵＥ）を示す。なお、プレイリスト情報には前述のフラグ形式に限定されることはなく、例えばプレイリストに含まれるビデオ解像度の中で最も大きい解像度を記載することでもよい。

（３１）ＭＭＴの時間表現
ＭＰＥＧ−２ ＴＳ方式のＡＶクリップでは、再生時間は、ＡＶクリップ内に格納されるＰＣＲに記述されるシステム時間を基点とするＳＴＣによって表現される。

一方、ＭＭＴ／ＴＬＶ方式では、ＭＭＴＰパケットにｔｉｍｅｓｔａｍｐが短形式ＮＴＰタイムスタンプで記載される。また、ＭＭＴ／ＴＬＶ方式では、ＭＰＥＧ−２ ＴＳ方式のＰＣＲに相当する基軸時間は、ＭＭＴＰパケットとは別に受信されるＮＴＰパケットに記述される時刻であり、それはすなわちＵＴＣ時間を基軸としている。

ＡＶクリップとしてＭＭＴＰパケット以下のみを記録する場合、ＡＶクリップ内から基軸となる時間を取得することができないことになる。

図５にて説明したクリップ情報ファイルには、ＡＶクリップの再生開始時刻および再生終了時刻が記述される。従来のＭＰＥＧ−２ ＴＳ方式では、再生開始時刻と再生終了時刻とはＳＴＣ時間を基軸としたビデオフレームの表示時刻により再生開始時刻と再生終了時刻とを定義することができた。

しかしながら、ＭＭＴ／ＴＬＶ方式においては、基軸となる時間を取得できない場合が存在し得る。ＮＴＰパケットは、ＴＬＶパケット階層以下にあり、ＭＭＴＰパケット階層の上位に含まれる。このため、ＡＶクリップとしてＭＭＴＰパケット以上を記録する場合には、ＮＴＰパケットが廃棄されるため、基軸となる時間を取得できない。

そのため、ＡＶクリップとしてＭＭＴＰパケット以上のみを記録する場合、ＮＴＰパケットの起点となる時刻をクリップ情報ファイルの中に記載することでＡＶクリップのＳＴＣ時間として規定することができる。

図３１は、ＭＭＴ／ＴＬＶ方式におけるクリップ情報ファイルの内部構成の一例を示す図である。

図３１に示すＮＴＰ基準時刻は、受信したＭＭＴ／ＴＬＶストリームに対し、記録装置が記録開始をした時点から最初に出現したＮＴＰパケットに記載される時刻を示す。

ＡＶクリップがＭＭＴＰパケット以上のみで記録されている場合、ＡＶクリップから起点となる時刻を取得できないので、ＡＶクリップの再生開始時刻は、このＮＴＰ基準時刻を起点として設定する。再生開始時刻には、ＮＴＰ基準時刻を４５ｋＨｚ系の時刻に換算した時刻が設定される。再生終了時刻には、再生開始時刻にＡＶクリップに含まれるビデオストリームの再生時間を加算した時刻が設定される。すなわち、ＡＶクリップがＭＭＴＰパケット以上で記録される場合、基準時刻情報、再生開始時刻および再生終了時刻は、以下に示す関係で表される。

ＮＴＰ基準時刻 ＝ ［記録開始時に最初に出現したＮＴＰパケットに記載の時刻］
再生開始時刻 ＝ ［ＮＴＰ基準時刻］
再生終了時刻 ＝ ［再生開始時刻］ ＋ ［ＡＶクリップ内のビデオの再生時間］

ＡＶクリップがＴＬＶパケット以上で記録されている場合、ＡＶクリップ内にＮＴＰパケットが存在するので、記録されたＡＶクリップ内で最初に見つかったＮＴＰパケットからＮＴＰ基準時刻を取得できる。このため、クリップ情報の中に特に何も記載していなくてもよい。このとき再生開始時刻は、例えば０を起点としてもよい。再生終了時刻には、再生開始時刻にＡＶクリップに含まれるビデオストリームの再生時間を加算した時刻が設定される。

すなわち、ＡＶクリップがＴＬＶパケット以下で記録される場合、基準時刻情報、再生開始時刻および再生終了時刻は、以下に示す関係で表される。

ＮＴＰ基準時刻 ＝ ０
再生開始時刻 ＝ ０
再生終了時刻 ＝ ［ＡＶクリップ内のビデオの再生時間］

なお、再生開始時刻は、０を起点としているが、０でなくてもよく任意の値であればよい。

上記のようにＭＭＴ／ＴＬＶ方式の放送コンテンツを受信し、受信した放送コンテンツを記録する記録装置について図３２を用いて説明する。

図３２は、実施の形態に係る記録装置の機能的な構成の一例を示すブロック図である。

記録装置２０２は、コンテンツを受信する受信部１２１と、受信したコンテンツを記録媒体２０９に記録する記録部１２２とを備える。受信部１２１は、例えば、放送波を受信する受信アンテナおよびチューナにより実現される。記録部１２２は、例えば、専用回路により実現されてもよいし、プログラムを格納しているメモリおよびメモリを用いた処理を行うプロセッサにより実現されてもよい。記録部１２２は、図１９におけるＴＬＶ／ＩＰ処理モジュール２０３、制御モジュール２０４、ＣＡＳモジュール２０６、ＭＭＴ暗号モジュール２０７および記録モジュール２０８により構成されていてもよい。

コンテンツは、具体的には、ＭＭＴ／ＴＬＶ方式で多重化されている暗号ストリームである。つまり、コンテンツは、複数の第１パケットにより構成される。複数の第１パケットのそれぞれは、複数階層の可変長パケット構造を有する。複数の第１パケットのそれぞれは、ＭＭＴ／ＴＬＶ方式により多重化されたＴＬＶパケットである。また、複数の第１パケットの少なくとも１つは、基準時刻情報を含む。基準時刻情報は、ＮＴＰに基づく時刻を示す時刻情報である。基準時刻情報は、ＮＴＰパケットに含まれる。

記録部１２２は、複数の第１パケットに含まれる１以上の基準時刻情報のうちの最初の基準時刻情報をコンテンツの管理情報に含まれるコンテンツの基準時刻（ＮＴＰ基準時刻）およびコンテンツの再生開始時刻として記録してもよい。また、記録部１２２は、再生開始時刻にコンテンツの再生時間を加算することにより算出される時刻をコンテンツの生成終了時刻として記録媒体２０９に記録してもよい。コンテンツの管理情報は、例えばクリップ情報ファイルのクリップ情報である。

また、記録部１２２は、コンテンツの記録媒体２０９における再生開始位置を示す開始位置情報を再生開始時刻に対応付けて管理情報において記録してもよい。また、記録部１２２は、コンテンツの記録媒体２０９における再生終了位置を示す終了位置情報を再生終了時刻に対応付けて管理情報において記録してもよい。

また、記録部１２２は、受信部１２１により受信されたコンテンツが有する複数の第１パケットから、第１パケットよりも上位層の複数の第２パケットと、基準時刻情報とを抽出し、抽出した複数の第２パケットと、基準時刻情報とを記録してもよい。この場合、複数の第２パケットのそれぞれは、ＭＭＴＰ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットである。

図３３は、実施の形態に係る記録装置による記録方法の一例を示すフローチャートである。

記録装置２０２の受信部１２１は、コンテンツを受信する（Ｓ３３０１）。

次に、記録部１２２は、受信部１２１が受信したコンテンツを記録媒体２０９に記録する（Ｓ３３０２）。

（３２）エントリポイントのバイト表現について
図３４は、エントリマップのＥＰコースおよびＥＰファインを説明するための図である。

図７で説明した、ＭＰＥＧ−２ ＴＳ方式のＡＶクリップにおけるエントリマップでは、エントリポイントが示す時間情報は３３ビットで表され、位置情報は３２ビットで表される。また、当該エントリマップでは、隣接するエントリポイントの位置の差は、通常３２ビットよりも十分小さいビット数によって表現することができる。時間情報についても同様に、隣接するエントリポイントの時間差は、３３ビットよりも十分小さいビット数によって表現可能である。

そこで、各エントリポイントの時間情報と位置情報とは、それぞれの差分が表現できるだけの下位ビット分で記述する、例えば位置情報は下位１７ビット、時間情報は下位２０ビットのうち９ビット分を除いた１１ビットで記述することとし、これをＥＰファインと呼ぶ。また、ＥＰファインの時間情報および位置情報が桁あふれする位置においては、時間情報および位置情報の上位ビットを記述することとし、これをＥＰコースと呼ぶ。つまり、ＥＰファインおよびＥＰコースのような２階層構造によりエントリポイントが表現されてもよい。

この位置情報の表現方法によりエントリマップのデータ量を削減するとともに、エントリポイントへの探索処理を向上が図られる。

ＭＭＴ／ＴＬＶ方式のエントリマップについても、ＭＰＥＧ−２ＴＳ方式と同様にＥＰコースおよびＥＰファインの２段階構造のエントリマップで構成される。このエントリマップで管理する時間情報と位置情報とは、ＭＰＥＧ−２ＴＳ方式のＡＶクリップとは記録対象が異なる。

ＡＶクリップがＭＰＥＧ−２ ＴＳ方式のストリームである場合、時刻情報はＰＣＲパケットに記述されるシステム時間を基準とする時刻を示し、位置情報はソースパケット番号を示す。一方、ＡＶクリップがＭＭＴ／ＴＬＶ方式のストリームである場合、時刻情報はＮＴＰパケットに記述されるＵＴＣ時間を基準とする時刻を示し、位置情報はクリップ先頭からのバイト数を示す。

位置情報を表現するのに、ＭＰＥＧ−２ ＴＳ方式ではタイムスタンプつきの場合には、１９２バイト単位のデータ構造となっている。このため、ＭＰＥＧ−２ ＴＳ方式では、記録位置をタイムスタンプ付ＴＳパケットの単位で指定することができた。よって、タイムスタンプ付ＴＳパケット単位を用いて、１００ＧＢの光ディスクでも、３２ビットで十分に記録位置を表現することができた。

一方で、ＭＭＴ／ＴＬＶ方式の場合にはＭＭＴＰパケットが可変長の構造となっているため、パケット単位で位置情報を指定することはできないため、ファイルの記録位置をバイト単位で指定する必要がある。

しかしながら１００ＧＢの光ディスクでは、３２ビットでの表現では不十分であり、たとえば３７ビットでの表現が必要となる。ただし、３２ビットでもカウンタをサイクリック表現にするなどの工夫を行えば、記録位置をバイト単位で表現することが可能となる。

さらに、ＥＰファインで表現される位置情報についてもまた、従来のＭＰＥＧ−２ ＴＳ方式ではパケット単位で指定していた。一方で、ＭＭＴ／ＴＬＶ方式では、バイト単位で指定すると、ＭＰＥＧ−２ ＴＳ方式で表現可能な分解能を十分得ることができないので、ＭＰＥＧ−２ ＴＳ方式の分解能相当を表現するためには、１バイト分多くデータ量が必要である。

ＥＰコースで粗い間隔の位置情報を従来のＭＰＥＧ−２ ＴＳ方式では３２ビット分すべて記述していた。一方で、ＭＭＴ／ＴＬＶ方式のバイト単位で表現する場合、位置情報の３７ビットのうちその上位１６ビットだけを表現するとしてもよい。この場合、下位ビットを表現するＥＰファインの値との合算によって３７ビット分を表現することができるため、ＥＰコースのデータ量を削減することができ、エントリマップ全体でのデータ量の増加を軽減できる。

なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の記録装置、記録方法などを実現するソフトウェアは、次のようなプログラムである。

すなわち、このプログラムは、コンピュータに、少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信し、受信した前記コンテンツを記録媒体に記録する記録方法を実行させる。

以上、本発明の一つまたは複数の態様に係る記録装置、記録方法および記録媒体について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つまたは複数の態様の範囲内に含まれてもよい。

本発明は、ＭＭＴ／ＴＬＶパケット構造を持つ次世代４Ｋ／８Ｋ放送やコンテンツ配信を受信して記録媒体に記録するレコーダ、および記録媒体を再生するプレイヤーにおいて、放送規格で定める物理フレームや、ＴＬＶ／ＩＰなどの下位レイヤなく、直接上位レイヤであるＭＭＴパケットを記録しても多重化データの処理が可能となり、データサイズの圧縮に貢献する。

１０１ ＢＤディスク
１０２ トラック
２０１ 放送局
２０２ 記録装置
２０３ ＴＬＶ／ＩＰ処理モジュール
２０４ 制御モジュール
２０５ ＭＭＴ処理・復号モジュール
２０６ ＣＡＳモジュール
２０７ ＭＭＴ暗号モジュール
２０８ 記録モジュール
２０９ 記録媒体
１２０１ プレイアイテム
１２０２ エントリマーク
１２０３ クリップ情報ファイル
１２０４ ＡＶクリップ
１２０５ メインパス
１３０１ 参照情報
１３０２ 接続条件
１３０３ 再生開始時刻
１３０４ 再生終了時刻
１５００ 再生装置
１５０１ ＢＤドライブ
１５０２ リードバッファ
１５０３ システムターゲットデコーダ
１５０３ａ ソースデパケッタイザ
１５０３ｂ ＰＩＤフィルタ
１５０５ 管理情報メモリ
１５０７ 再生制御部
１５０９ ユーザイベント処理部
１５１０ プレーン加算部
１７００ ビデオデコーダ
１７０１ ＴＢ
１７０２ ＭＢ
１７０３ ＥＢ
１７０４ 圧縮映像デコーダ
１７０５ ＤＰＢ
１７１０ 字幕デコーダ
１７２０ オーディオデコーダ

Claims (8)

1. 少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信する受信部と、
   受信した前記コンテンツを記録媒体に記録する記録部と、を備える
   記録装置。
2. 前記記録部は、
   （ｉ）前記複数の第１パケットに含まれる１以上の基準時刻情報のうちの最初の基準時刻情報を前記コンテンツの管理情報に含まれる前記コンテンツの基準時刻および前記コンテンツの再生開始時刻として記録し、
   （ｉｉ）前記再生開始時刻に前記コンテンツの再生時間を加算することにより算出される時刻を前記管理情報に含まれる前記コンテンツの再生終了時刻として記録する
   請求項１に記載の記録装置。
3. 前記記録部は、
   （ｉ）前記コンテンツの前記記録媒体における再生開始位置を示す開始位置情報を前記再生開始時刻に対応付けて前記管理情報において記録し、
   （ｉｉ）前記コンテンツの前記記録媒体における再生終了位置を示す終了位置情報を前記再生終了時刻に対応付けて前記管理情報において記録する
   請求項２に記載の記録装置。
4. 前記複数の第１パケットのそれぞれは、ＭＭＴ／ＴＬＶ方式により多重化されたＴＬＶパケットであり、
   前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づく時刻を示す時刻情報である
   請求項１から３のいずれか１項に記載の記録装置。
5. 前記記録部は、
   （ｉ）前記受信部により受信された前記コンテンツが有する前記複数の第１パケットから、前記第１パケットよりも上位層の複数の第２パケットと、前記基準時刻情報とを抽出し、
   （ｉｉ）抽出した前記複数の第２パケットと、前記基準時刻情報とを記録する
   請求項１から３のいずれか１項に記載の記録装置。
6. 前記複数の第１パケットのそれぞれは、ＭＭＴ／ＴＬＶ方式により多重化されたＴＬＶパケットであり、
   前記複数の第２パケットのそれぞれは、ＭＭＴＰ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットであり、
   前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づく時刻を示す時刻情報である
   請求項５に記載の記録装置。
7. 少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツを受信し、
   受信した前記コンテンツを記録媒体に記録する
   記録方法。
8. 少なくとも１つが基準時刻情報を含む複数の第１パケットであって、それぞれが複数階層の可変長パケット構造を有する複数の第１パケットにより構成されるコンテンツが記録された記録媒体。

Images