JP6055093B2 - 信号送受信装置及び信号送受信方法 - Google Patents

Description

本発明は、信号送受信装置及び信号送受信方法に関する。

ビデオ信号処理速度が向上するにつれて、超高解像度（ｕｌｔｒａ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ、ＵＨＤ）ビデオを符号化／復号する方法が研究されている。既存のＨＤ受信機を用いてＵＨＤビデオを受信した場合でも、ＵＨＤだけでなく、ＨＤビデオも問題なく処理する方法が研究されている。例えば、送信されるビデオと受信機の表示装置のアスペクト比が異なる場合、各受信機は表示装置に合うアスペクト比でそのビデオを処理できなければならない。

しかし、従来のデバイスでは、ＵＨＤビデオのアスペクト比である２１：９形式の圧縮ビデオに対する復号がサポートされない。２１：９のビデオが送信される場合、２１：９アスペクト比の受信機は２１：９のビデオをそのまま処理して表示しなければならないし、１６：９アスペクト比の受信機は、２１：９アスペクト比のビデオストリームを受信するとレターボックスの形態で出力するか、又は端を切り取った（クロップされた）１６：９アスペクト比のビデオを受信してビデオ信号を出力しなければならない。さらに、１６：９アスペクト比の受信機は、ストリーム内に字幕がある場合、字幕を処理できるものでなければならない。

このように、既存のＨＤ受信機又はＵＨＤビデオを処理できる受信機のアスペクト比が異なるため、対応するビデオを送信又は受信し、処理する場合に問題点が発生しうる。

本発明の目的は、アスペクト比の異なるビデオを、アスペクト比の異なる表示装置を有する受信機で処理できる信号送受信方法及び信号送受信装置を提供することにある。

本発明の他の目的は、アスペクト比の異なるＨＤビデオ及びＵＨＤビデオをそれぞれ受信機で処理できる後方互換性を有するビデオを送信又は受信することができる信号送受信方法及び信号送受信装置を提供することにある。

本発明の他の目的は、アスペクト比の異なるＨＤビデオ及びＵＨＤビデオをそれぞれ受信機の仕様に応じて別々に処理できる通知情報を処理することができる信号送受信方法及び信号送受信装置を提供することにある。

本発明の一実施例は、ビデオデータを符号化するステップと、符号化されたビデオデータを受信機のアスペクト比に合わせて表示可能な通知情報を生成するステップであって、ここで、通知情報は、第１アスペクト比の高解像度ビデオデータを受信機のアスペクト比によらずに表示するためのアスペクト比制御情報を含む、ステップと、符号化されたビデオデータと通知情報とを多重化し、多重化されたビデオデータ及び通知情報を送信するステップと、を含む、信号送信方法を提供する。

アスペクト比制御情報は、符号化されたビデオデータが分割されて送信されることを示し、分割されたビデオデータを併合（ｍｅｒｇｅ）する併合情報を含むことができる。

アスペクト比制御情報は、符号化されたビデオデータをアスペクト比に合わせて分割可能な分割情報を含むことができる。

アスペクト比制御情報は、符号化されたビデオデータそれぞれのビデオの解像度に応じてビデオの字幕位置を変更するための位置情報を含むことができる。

本発明の他の実施例は、ビデオデータを符号化する符号化器と、符号化されたビデオデータを受信機のアスペクト比に合わせて表示可能な通知情報を生成する通知情報生成部であって、通知情報は、第１アスペクト比の高解像度ビデオデータを受信機のアスペクト比によらずに表示するためのアスペクト比制御情報を含む、通知情報生成部と、符号化されたビデオデータと通知情報とを多重する多重化器と、を備える、信号送信装置を提供する。

本発明の他の実施例は、ビデオストリームと通知情報とを逆多重化する逆多重化器と、逆多重化された通知情報を復号する通知情報復号部であって、通知情報は、第１アスペクト比の高解像度ビデオデータを、受信機のアスペクト比に応じてビデオ形式を変更して表示するためのアスペクト比制御情報を含む、通知情報復号部と、逆多重化されたビデオストリームを復号した通知情報によって復号するビデオ復号器と、を備える、信号受信装置を提供する。

本発明の他の実施例は、ビデオストリームと通知情報とを逆多重化するステップと、逆多重化された通知情報を復号するステップであって、通知情報は、第１アスペクト比の高解像度ビデオデータを、受信機のアスペクト比に応じてビデオ形式を変更して表示するためのアスペクト比制御情報を含む、ステップと、逆多重化されたビデオストリームを復号した通知情報によって復号するステップと、を含む、信号受信方法を提供する。

本発明の実施例によれば、アスペクト比の異なるビデオを、アスペクト比の異なる表示装置を有する受信機で処理することができる。

本発明の実施例によれば、アスペクト比の異なるＨＤビデオ及びＵＨＤビデオをそれぞれ受信機で処理できる後方互換性を有するビデオを送信又は受信することができる。

本発明の実施例によれば、アスペクト比の異なるＨＤビデオ及びＵＨＤビデオをそれぞれ受信機の仕様に応じて別々に処理することができる。

本発明による信号送信方法の一実施例を例示する図である。 本発明の実施例による、高解像度イメージを受信機のアスペクト比に合わせて送信する例を概略的に示す図である。 図２の本発明の実施例による、高解像度イメージを受信機のアスペクト比に合わせて送信するストリーム構造の例を概略的に示す図である。 本発明の実施例による、高解像度イメージを受信機のアスペクト比に合わせて送信するほかの例を概略的に示す図である。 本発明の他の実施例による信号送受信方法を概略的に示す図である。 図５のように送信される場合、字幕が出力される領域を例示する図である。 図５のように送信される場合、ＵＨＤビデオを受信可能な受信機で字幕のための字幕ウィンドウを表示する例を示す図である。 本発明による第１実施例によってビデオデータを送信する場合、ビデオデータを符号化又は復号する方法を例示する図である。 本発明による第２実施例によってビデオデータを送信する場合、ビデオデータを符号化又は復号する方法を例示する図である。 本発明の第１実施例による、高解像度ビデオデータを符号化する符号化器の例を示す図である。 本発明の第１実施例による、分離した原ビデオと分離されたビデオの解像度及びビデオ構成方法を例示する図である。 本発明の第１実施例による、高解像度ビデオデータを復号化する復号器の一例を示す図である。 本発明の第１実施例のクロップされたビデオを併合してフィルタ処理する例を示す図である。 本発明の第２実施例による受信機の第１例を示す図である。 本発明の第３実施例による受信機の動作を例示する図である。 本発明の実施例によるビデオを表示できる通知情報を例示する図である。 本発明の第１実施例による通知情報の具体的な構文値を例示する図である。 本発明の第１実施例に従う場合、ストリームレベル記述子の一例を示す図である。 上記の例示したビデオの解像度及びフレームレートを示す情報の値を例示する図である。 原ビデオのアスペクト比に関する情報を例示する図であって、説明した通知情報のうち、ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ａｓｐｅｃｔ＿ｒａｔｉｏフィールドは、原ＵＨＤビデオのアスペクト比に関する情報を示す図である。 クロップされたビデオの方向情報を例示する図である。 ビデオを構成する方法の例を示す図である。 サブストリームを符号化する場合に符号化方式の例を示す図である。 本発明の第１実施例に従う場合、ストリームレベル記述子を例示する図である。 例示した第３実施例に従う場合、通知情報を例示する図である。 例示したＵＨＤ＿ｖｉｄｅｏ＿ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅフィールドのフィールド値を例示する図である。 例示したＵＨＤ＿ｖｉｄｅｏ＿ｉｎｃｌｕｄｅ＿ｓｕｂｔｉｔｌｅフィールドのフィールド値を例示する図である。 送信ビデオの形式と受信機の表示アスペクト比とが異なる場合、受信機の動作の例を示す図である。 例示した記述子が他の通知情報に含まれる場合を例示する図である。 例示した記述子が他の通知情報に含まれる場合を例示する図である。 例示した記述子が他の通知情報に含まれる場合を例示する図である。 本発明の実施例による、ビデオデータのＳＥＩ領域のペイロードに対する構文を例示する図である。 本発明の実施例によってビデオデータが送信される場合、少なくとも一つ以上の実施例によるビデオデータを復号して表示できる受信装置の一例を示す図である。 本発明による信号受信方法の一実施例を例示する図である。 本発明による信号送信装置の一実施例を例示する図である。 本発明による信号受信装置の一実施例を例示する図である。

以下、本発明を容易に説明できる実施例を、図面を参照して説明する。

図１は、本発明による信号送信方法の一実施例を例示する図である。

ビデオデータを符号化する（Ｓ１１０）。ビデオデータを符号化する場合、以下に開示する実施例によって、ビデオデータの符号化情報を、符号化されたビデオデータに含めることができる。

符号化されたビデオデータの符号化情報は、図３２で詳細に記述する。符号化されたビデオデータは、以下に開示する実施例によって異なる構造を有することができるが、実施例としては、図２及び図３（第１実施例）、図４（第２実施例）、図５乃至図７（第３実施例）を挙げることができる。

例えば、符号化されたビデオデータは、高解像度ビデオが既存のアスペクト比に合わせて分割された構造であり、分割されたビデオデータが、それを再び高解像度ビデオに併合できる情報を含むことができる。又は、符号化されたビデオデータは、高解像度ビデオデータを受信機のアスペクト比に合わせて分割できる情報を含んだり、字幕を配置するためのレターボックス（例えば、有効形式記述（Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ、ＡＦＤ）バー）の位置情報を含んだりすることもできる。

送信信号が放送信号である場合、符号化されたビデオデータとは別に、ビデオデータを受信機のアスペクト比に合わせて表示可能な通知情報を生成する（Ｓ１２０）。通知情報は、各実施例によって、図１６乃至図２７、図２９乃至図３１に例示する情報を含むことができるが、実施例によって、これらの図面に例示する情報が生成され得る。通知情報は、第１アスペクト比の高解像度ビデオデータを受信機にアスペクト比によらずに表示できる通知情報を含むことができる。例えば、受信機のアスペクト比によらずに表示できる通知情報は、高解像度ビデオデータのアスペクト比制御情報を含むことができる。ビデオデータとは別個の通知情報の例は、図１６乃至図２７、及び図２９乃至図３１に例示する。

符号化されたビデオデータと通知情報とを多重化し、多重化されたビデオデータ及び通知情報を送信する（Ｓ１３０）。

送信データが放送信号でない場合は、ビデオデータと多重化される通知情報の生成段階は省略され、Ｓ１１０で記述したビデオデータ領域内に、アスペクト比制御情報を含むビデオデータと異なるデータ（例えば、オーディオデータ）を多重化して出力する。

送信機が各実施例によってビデオデータを送信する場合、受信機表示装置のアスペクト比が様々であるか、又は性能が様々である場合にも、アスペクト比制御情報によってそれぞれ対応する表示のアスペクト比に合わせて高解像度ビデオ又は字幕を表示することができる。また、既存の受信機も、アスペクト比制御情報によって、高解像度ビデオデータをその受信機のアスペクト比に応じて表示することができる。すなわち、受信機は、画面制御情報を用いて、第１アスペクト比の高解像度ビデオデータを受信機のアスペクト比に応じて変更して表示させることができる。

第１実施例によれば、アスペクト比制御情報は、符号化されたビデオデータが分割されて送信されることを示し、分割されたビデオデータを併合する併合情報を含むことができる。第２実施例によれば、アスペクト比制御情報は、符号化されたビデオデータをアスペクト比に合わせて分割可能な分割情報を含むことができる。そして、第３実施例によれば、アスペクト比制御情報は、符号化されたビデオデータそれぞれのビデオの解像度に応じてビデオの字幕位置を変更するための位置情報を含むことができる。

図２は、本発明の実施例によって高解像度イメージを受信機のアスペクト比に合わせて送信する例を概略的に示す図である。この例は、２１：９アスペクト比のＵＨＤビデオを用いて１６：９アスペクト比をサービスできる実施例を例示する。

２１：９ ＵＨＤ ソースビデオ（ビデオ（１））から、１６：９ ＵＨＤ ソースビデオ（ビデオ（２））と、左右をクロップされたビデオ（ビデオ（３）及びビデオ（４））とに分離する。ビデオのクロップ過程などを通じてビデオを３個のビデオに分離することができる。

すなわち、ビデオ（１）は、ビデオ（２）、ビデオ（３）、ビデオ（４）に分離して送信する。

ＵＨＤビデオを表示できる受信装置は、ビデオ（２）、ビデオ（３）、ビデオ（４）を受信して表示する。

そして、ＨＤビデオを表示できる受信装置は、ビデオ（２）を受信し、拡大縮小などを用いて１６：９のＵＨＤビデオ（ビデオ（２））を１６：９ＨＤビデオ（ビデオ（５））に変換して表示することができる。

図３は、図２による本発明の実施例によって、高解像度イメージを受信機のアスペクト比に合わせて送信するストリーム構造の例を概略的に示す図である。

例示したストリームは、１６：９ＵＨＤビデオ、左右をそれぞれクロップされたデータ及び付加データ（ＵＨＤ ｃｏｍｐｏｓｉｔｉｏｎ ｍｅｔａｄａｔａ）を含む。１６：９ＵＨＤビデオは、従来ＨＤサービスを提供できる１６：９アスペクト比のＨＤビデオと、１６：９ＵＨＤビデオと１６：９アスペクト比のＨＤビデオとの差である強化データ（ｅｎｈａｎｃｅｍｅｎｔ ｄａｔａ）とを含むことができる。

既存のＨＤ受信機は、１６：９アスペクト比のＨＤビデオを受信して処理し、１６：９ＵＨＤ受信機は、１６：９アスペクト比のＨＤビデオと１６：９アスペクト比のＵＨＤビデオのための強化データを受信して処理する。そして、２１：９受信機は、１６：９アスペクト比のＵＨＤビデオ、クロップされた左右のデータ、及び付加データを用いて２１：９ＵＨＤビデオを構成することができる。付加データは、左右のクロップ座標情報を含むことができる。したがって、受信機は、付加データを用いて１６：９アスペクト比のＵＨＤビデオ、クロップされた左右のデータを用いて２１：９アスペクト比のＵＨＤビデオを生成することができる。

したがって、同図の実施例によれば３個の調整可能（ｓｃａｌａｂｌｅ）サービスを提供することができる。

図４は、本発明の実施例によって、高解像度イメージを受信機のアスペクト比に合わせて送信する他の例を概略的に示す図である。この例で、２１：９アスペクト比のＵＨＤビデオは１６：９アスペクト比のＨＤビデオとは別個のストリームとして送信される。

１６：９のＨＤビデオは２１：９アスペクト比のＵＨＤビデオと後方互換性を有しないため、送信機は、ＨＤビデオストリームとは別にＵＨＤビデオストリームを準備する。ＵＨＤビデオストリームは、１６：９ビデオのアスペクト比を生成できるクロップ座標情報を付加情報データ（１６：９抽出情報メタデータ）に含めて送信することができる。

したがって、ＵＨＤビデオ受信機は２１：９アスペクト比のＵＨＤビデオストリームを受信する。そして、ＵＨＤビデオ受信機が２１：９アスペクト比の表示装置を備えるときは、２１：９ＵＨＤサービスを提供するストリームからＵＨＤビデオを抽出することができる。この場合、付加情報データは無視してもよい。

そして、ＵＨＤビデオ受信機が１６：９アスペクト比の表示装置を備えるときは、付加情報データを用いてＵＨＤビデオストリームから１６：９アスペクト比のビデオを抽出してサービスを提供することができる。

従来のＨＤ受信機は、１６：９アスペクト比のＨＤビデオストリームを受信してＨＤビデオを提供することができる。

図５は、本発明による信号送受信方法の他の実施例を概略的に示す図である。

例えば、２１：９のアスペクト比のビデオを送信するが、このビデオ形式を拡大縮小して１６：９のアスペクト比のビデオとして送信し、かつ１６：９のアスペクト比のビデオ内の上下にレターボックス領域を含めて送信することができる。

図６は、図５のように送信される場合に、字幕領域の出力を例示する。既存のＨＤビデオ受信機は、字幕領域のための字幕ウィンドウがレターボックス領域ではなく画面領域に表示される。

図７は、図５のように送信される場合に、ＵＨＤビデオを受信可能な受信機で字幕のための字幕ウィンドウを表示する例を示す。ＵＨＤビデオを送信するストリーム内に字幕が含まれた場合、既存のビデオを左側上端（０，０）から出力し、実際ビデオ領域の外側の部分のレターボックス領域（画面の下端領域、剰余領域）に字幕を表示することによって、画面の空いている部分に字幕が出力され、その結果、実際ビデオ領域との干渉を最小化するとともに画面を効率的に用いることができる。

図８は、本発明による第１実施例によってビデオデータを送信する場合、ビデオデータを符号化又は復号する方法を例示する図である。

送信機は、１６：９ＨＤビデオを基本層（ｂａｓｅ ｌａｙｅｒ）データに符号化し、基本層データに符号化されたデータに基づいて１６：９ＵＨＤを構成するレジデュアルデータを強化層（ｅｎｈａｎｃｅｍｅｎｔ ｌａｙｅｒ）１データに符号化する。そして、残りの左側及び右側がクロップされたデータである２．５：９ビデオに該当する残りのＵＨＤビデオを強化層２データに符号化する。

強化層２に符号化されるビデオデータは、相関を用いて２１：９のＵＨＤビデオ全体で符号化されてもよいし、独立したビデオとして符号化されてもよい。そして、第１実施例で説明したとおり、左側及び右側のクロップされたデータの左右位置に関する情報を送信することもできる。

強化層２に符号化されるビデオデータの左右位置に関する情報は、強化層２に該当するビデオストリーム内のヘッダ又はシステムレベルのセクションデータの記述子形態のような実施例などを用いて送信することができる。これについては後述する。

受信機は、基本層データだけを受信して復号すると１６：９ＨＤビデオ（１９２０×１０８０）を表示することができる。

受信機が基本層データ及び強化層１データを復号すると１６：９ＵＨＤビデオ（３８４０×２１６０）を表示することができる。

そして、受信機が基本層データ、強化層１データ、及び強化層２データをすべて復号すると、２１：９ＵＨＤビデオ（５０４０×２１６０）を表示することができる。この場合、上述した強化層２に符号化されるビデオデータの左右位置に関する情報を用いてもよい。

したがって、受信機の性能に応じて又は機能によって様々なアスペクト比の様々な解像度のビデオを表示することができる。この例は、４Ｋビデオを複数個のビデオに分離して送信する例を示すが、それ以上の解像度によるビデオも、同様の方式で送信可能である。

図９は、本発明による第２実施例によってビデオデータを送信する場合、ビデオデータを符号化又は復号する方法を例示する図である。

例えば、送信機が４Ｋ（５０４０×２１６０）ＵＨＤビデオから１６：９ＵＨＤビデオを分離したとき、送信機は１６：９ビデオの分離開始情報及び分離終了情報を共に送信してもよい。例えば、送信機は、画面上開始座標に該当するｃｒｏｐ＿ｃｏｒｄｉｎａｔｅ＿ｘ１情報及び終了座標のｃｒｏｐ＿ｃｏｒｄｉｎａｔｅ＿ｘ２情報を共に送信する。ここで、ｃｒｏｐ＿ｃｏｒｄｉｎａｔｅ＿ｘ１情報は１６：９ＵＨＤビデオの開始座標、ｃｒｏｐ＿ｃｏｒｄｉｎａｔｅ＿ｘ２情報は１６：９ＵＨＤビデオの終了座標を示す。

受信機は、４Ｋ（５０４０×２１６０）ＵＨＤビデオを受信し、分離開始情報及び分離終了情報を無視して４Ｋ（５０４０×２１６０）ＵＨＤビデオをそのまま表示することができる。

受信機は４Ｋ（５０４０×２１６０）ＵＨＤビデオを受信し、分離開始情報及び分離終了情報を用いて、２１：９ＵＨＤビデオから１６：９ＵＨＤビデオを切り取って表示することができる。

第２実施例によれば、１６：９ＨＤビデオは別のストリームとして送信されるため、受信機は１６：９ＨＤビデオストリームを４Ｋ（５０４０×２１６０）ＵＨＤビデオストリームと別個に受信して表示することができる。

したがって、受信機の性能又は機能に応じて様々なアスペクト比の様々な解像度のビデオを表示することができる。同様に、この例は、４Ｋビデオを複数個のビデオに分離して送信する例を示すが、それ以上の解像度によるビデオも同様の方式で符号化又は復号可能である。

図１０は、本発明の第１実施例によって高解像度ビデオデータを符号化する符号化器の例を示す図である。ここでは、高解像度ビデオデータとして４Ｋの２１：９ＵＨＤビデオデータを例示する。同図で、ビデオに関連したデータはＡ、Ｂ、Ｃ、Ｄ１及びＤ２で示す。

高解像度ビデオデータを符号化する符号化器の一例は、基本層符号化器１１０、第１強化層データ符号化器１２０、及び第２強化層データ符号化器１３０を含むことができる。

例えば、符号化器の一例として、２１：９アスペクト比のＵＨＤビデオを符号化する符号化器は、それぞれ、基本層データ、強化層１データ、強化層２データをそれぞれ処理して符号化することができる。

基本層符号化器１１０のクロップ及びスケール部１１１は、２１：９ＵＨＤビデオデータＡを１６：９にクロップし、サイズを縮小して１６：９ＨＤビデオデータＢとして出力する。第１符号化部１１９は、１６：９ＨＤビデオデータを基本層データとして符号化して出力することができる。

第１強化層データ符号化器１２０のクロップ部１２１は、２１：９ＵＨＤビデオデータＡを１６：９にクロップする。拡大（アップスケール）部１２３は、基本層符号化器１１０のクロップ及びスケール部１１１が出力する縮小（ダウンスケール）されたデータを再び拡大して出力し、第１演算部１２７は、クロップ部１２１がクロップしたデータと拡大部１２３が拡大したデータを用いて、１６：９ＵＨＤビデオのレジデュアルデータＣを出力することができる。第２符号化部１２９は、１６：９ＵＨＤビデオを強化層１データとして符号化して出力することができる。

第２強化層データ処理部１３０の第２演算部１３７は、２１：９ＵＨＤビデオデータＡと、クロップ部１２１がクロップしたデータとを用いて、１６：９ビデオデータと、２１：９ビデオデータのクロップデータである左側ビデオデータＤ１及び右側ビデオデータＤ２とをそれぞれ出力することができる。

左側ビデオデータＤ１及び右側ビデオデータＤ２はそれぞれ、対応するビデオの左側又は右側に関する情報で識別することができる。この情報を通知する例は後述する。ここで、左側ビデオデータの識別情報（ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎ）として０、右側ビデオデータの識別情報（ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎ）として１をそれぞれ例示した。

左側ビデオデータＤ１及び右側ビデオデータＤ２を一つのビデオストリームとして送信すると、受信機は通知情報を用いてそれを復号することができる。この場合、左側ビデオデータＤ１及び右側ビデオデータＤ２は別々に符号化してもよいし、一つのビデオデータとして符号化してもよい。

したがって、左側ビデオデータＤ１及び右側ビデオデータＤ２を２つのビデオストリームで送信したり、一つのストリームで送信したりする場合、それぞれ識別情報を用いてそれらを分離するように通知することができる。

第３符号化部１３９は、クロップされた左側ビデオデータＤ１及び右側ビデオデータＤ２を強化層２データに符号化することができる。

したがって、受信機の性能に応じてそれぞれ基本層データ、強化層１データ、強化層２データを受信すると、ＵＨＤビデオ又はＨＤビデオデータを復元することができる。

受信機が強化層２データを復元する場合、それぞれ基本層データ、強化層１データと関係付けた復号化方式で復号することもでき、それらとは独立して復号することもできる。このような復号化方式は、符号化方式によって決定することができる。

図１１は、本発明の第１実施例によって分離した原ビデオと分離されたビデオとの解像度を例示する図である。

左側上段の例（ａ）は、２１：９アスペクト比を有する５０４０×２１６０解像度のＵＨＤビデオの解像度を示す。

２１：９アスペクト比を有する４Ｋ ＵＨＤビデオは、５０４０×２１６０の解像度を有する。そのうち、１６：９に該当するビデオは既存の放送で１６：９の４Ｋ ＵＨＤと呼ばれる３８４０×２１６０解像度のビデオを意味することができる。

右側上段の例（ｂ）は、２１：９アスペクト比を有する５０４０×２１６０解像度のＵＨＤビデオ上で３８４０×２１６０解像度のＵＨＤビデオを例示する図である。

中央下段の例（ｃ）で、３８４０×２１６０の解像度のビデオは、強化層１データであり、左右の６００×２１６０解像度のビデオを一つのビデオに結合した場合、結合された１２００×２１６０解像度のビデオは強化層１データを有する。このとき、ビデオレベルで剰余ビデオの解像度に対して通知（ｓｉｇｎａｌｉｎｇ）が必要であり、いずれの方向のビデオであるかを示すために左右情報に対する通知を行ってもよい。

この例では、左側ビデオデータの識別情報（ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎ）は０、右側ビデオデータの識別情報（ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎ）は１でそれぞれ示している。

また、強化層２に含まれる残りのビデオは左右のエッジ領域にだけ限定されず、２１：９ビデオのうち、任意の１６：９ビデオを除く残りの領域へと位置を任意に指定することもできる。例えば、２１：９ビデオのうち、抽出する１６：９ビデオを左側領域に設定し、残り右側の５：９ビデオで強化層２を構成する実施例も可能である。また、解像度が異なる場合も可能である。例えば、４Ｋだけでなく、８Ｋ ＵＨＤビデオに対しても、上記のようにビデオを分離して送信することができる。

図１２は、本発明の第１実施例による高解像度ビデオデータを復号化する復号器の一例を示す図である。ここでは、説明の便宜上、高解像度ビデオデータとして４Ｋの２１：９ＵＨＤビデオデータを例示する。同図で、ビデオと関連したデータは、Ａ、Ｂ、Ｄ１、Ｄ２及びＥでそれぞれ示す。

高解像度ビデオデータを復号化する復号器の一例は、基本層復号部２１０、第１強化層データ復号部２２０、及び第２強化層データ復号部２３０のうち少なくとも一つの復号部を含むことができる。信号受信装置の機能によって３つ機能の復号部をすべて含むこともでき、既存のＨＤビデオを出力する信号受信装置の復号器は基本層復号部２１０だけを含むこともできる。この例で、逆多重化器２０１を各復号部が共有してもよいし、それぞれの復号部が別個の逆多重化器２０１を含んでもよい。

例えば、２１：９アスペクト比のＵＨＤビデオを復号する復号器は、それぞれ、基本層データ、強化層１データ、強化層２データをそれぞれ処理して復号することができる。

基本層復号部２１０の第１復号器２１３は、逆多重化された１６：９アスペクト比のＨＤビデオＢを復号して出力することができる。

第１強化層データ復号部２２０の拡大部２２１は、基本層復号部２１０が復号した基本層データを拡大して出力する。

第２復号器２２３は、基本層データ及びレジデュアルデータを用いて調整可能な復号化を行うことができる。

第２復号器２２３は、逆多重化された１６：９のレジデュアルデータを復号し、拡大された基本層データと復号した１６：９のレジデュアルデータを用いて、１６：９アスペクト比のＵＨＤビデオＥに復号することができる。

一方、第２強化層データ復号部２３０の第３復号器２３３は、左側／右側ビデオを復号し、第１強化層データ復号部２２０が復号した強化層１データを用いて出力した１６：９のＵＨＤビデオＥと、復号した左側／右側ビデオ（Ｄ１／Ｄ２）とを併合して、２１：９ＵＨＤビデオＡを復元することができる。

この場合、第２強化層データ復号部２３０は、左側／右側ビデオを識別するための識別情報を用いることができ、２１：９ＵＨＤビデオＡが左側／右側ビデオが併合される部分で連続して自然に表示できるように境界フィルタ処理（ｂｏｕｎｄａｒｙ ｆｉｌｔｅｒｉｎｇ）を行うことができる。この場合、クロップされた左側／右側ビデオに該当するクロップされたビデオは、１６：９ビデオと併合するためにフィルタ処理過程を経る。

ここで、フィルタ処理過程は、既存のコーデックで用いるブロック歪み除去フィルタ（ｄｅｂｌｏｃｋｉｎｇ ｆｉｌｔｅｒ）と類似してもよいが、マクロブロックの境界ごとに適用するのでなく、クロップされたビデオの周辺に適用する。既存のブロック歪み除去フィルタと同様に、実際エッジとクロップされた部分とを併合することによって発生する境界を区別するために、しきい値に応じてフィルタ処理を行うことができる。これについては後述する。

図１３は、本発明の第１実施例においてクロップされたビデオを併合してフィルタ処理する例を示す。基本層のビデオ、強化層１のビデオ、及び強化層２のビデオの境界においてブロック歪みを除去する例を説明する。

同図で、例えば、併合される面を中心に、クロップされたビデオのうち左側ビデオと右側ビデオとを分離して符号化すると、つなぎ合わせた（ｓｔｉｔｃｈ）部分にブロック歪み（ｂｌｏｃｋｉｎｇ ａｒｔｉｆａｃｔ）が発生するため、その境界部分でぼかし処理（ｂｌｕｒｒｉｎｇ）を行う。実際ビデオのエッジと、クロップにより発生する境界とを区別するためにフィルタ処理を行うことができる。フィルタ処理する方法は、左右それぞれ６００×２１６０大きさのビデオを復号した後、１６：９ＵＨＤビデオと併合を行って２１：９のビデオとして再構成した後、ビデオ上でつなぎ合わせた境界から左右水平方向の任意個数の画素（ｐｉｘｅｌ）を用いてフィルタ処理を行う。同図は、左右水平方向の８個画素に対するフィルタ処理を適用する例であり、つなぎ合わせた部分の座標情報を用いることができる。

同図で、第１ビデオと第２ビデオとの併合部分における１フィールドの画素のアドレスをそれぞれＰ_i及びｑ_iと表示し、ｉはｘ座標に沿って０から始まる整数値を有する。ｉの増加方向は、第１ビデオと第２ビデオとの併合部分で変化する。例えば、併合部分のｘ軸において画素のアドレスが５９６、５９７、５９８、５９９（第１ビデオ上の画素）、６００、６０１、６０２、６０３（第２ビデオ上の画素）であると仮定する。

下記の式１で例示する条件１を満たすための条件を求めるために、式２乃至式４を満たすＰ₀、Ｐ₁、Ｐ₂、…値は４タップフィルタ及び５タップフィルタを用いてＰ’₀、Ｐ’₁、Ｐ’₂、…値に更新される。

式１は条件１を示す。

ここで、式２乃至式４に関連した条件１及び式６の条件２を用いると、それぞれ、実際エッジとブロック歪みとを区別することができる。

上記で式１の条件１を満たさない場合、式５のように３タップフィルタを適用してｐ₀とｑ₀の値は、ｐ’₀及びｑ’₀の値に更新する。

式６の条件２は、ｑ ｂｌｏｃｋをフィルタ処理するための条件であり、これを満たす場合、式７乃至式９に例示するように、ｑ₀、ｑ₁、ｑ₂は、４タップフィルタ及び５タップフィルタを用いて、ｑ´₀、ｑ´₁、ｑ´₂の値に更新する。

式６は条件２を示す。

条件２を満たさない場合は、次の式１０を用いてｑ₀値はｑ´₀値に更新される。

条件１及び２におけるα（ｏｆｆｓｅｔ＿ａｌｐｈａ＿ｖａｌｕｅ）及びβ（ｏｆｆｓｅｔ＿ｂｅｔａ＿ｖａｌｕｅ）は、量子化パラメータ（ｑｕａｎｔｉｚａｔｉｏｎ ｐａｒａｍｅｔｅｒ、ＱＰ）によるオフセットによって、フィルタの強度を調整することができる。ＱＰ値によってオフセットでフィルタ強度を調整し、これに応じて平滑フィルタ（ｓｍｏｏｔｈｉｎｇ ｆｉｌｔｅｒ）のオフセットも適切に割り当てるとビデオの細部を調整することができる。

図１４は、本発明の第２実施例による受信機の第１例を示す図である。

本発明の第２実施例によれば、ＨＤビデオのストリーム及びＵＨＤビデオのストリームを別個のストリームとして送信することができる。

したがって、ＨＤビデオだけを表示できる受信機（ａ）は、ＨＤビデオのストリームを逆多重化する逆多重化器及び復号器を備え、逆多重化器は、ＨＤビデオストリームを逆多重化し、復号器は、対応するビデオデータを復号して１６：９ＨＤビデオを表示する。

一方、ＵＨＤビデオを表示できる受信機（ｂ）も、逆多重化器及び復号器を備えることができ、この場合、逆多重化器は、ＵＨＤビデオストリームを逆多重化し、復号器は、対応するビデオデータを復号してＵＨＤビデオを表示する。

ここで、ＵＨＤビデオは、受信機の性能に応じて、ビデオの一部がクロップされたビデオである１６：９ＵＨＤビデオであってもよいし、クロップされない２１：９ＵＨＤビデオであってもよい。受信機は、第２実施例で説明したとおり、その性能に応じて、復号したＵＨＤビデオを表示でき、１６：９アスペクト比のＵＨＤビデオである場合、元の２１：９ＵＨＤビデオのうち、クロップされる位置情報（１６：９ 長方形座標で表示）を用いてビデオをクロップした後、クロップされたビデオを表示することができる。ここでは４Ｋ ＵＨＤビデオを例として説明したが、ビデオの解像度がより高い場合にも同様の方式が適用可能である。

図１５は、本発明の第３実施例による受信機の動作を例示する図である。本発明の第３実施例によれば、２１：９アスペクト比のＵＨＤビデオは、拡大縮小された１６：９アスペクト比のビデオ及びそのビデオの上、下に位置するレターボックスが挿入された形態で送信される。字幕が表示されるビデオの場合、受信機の性能に応じて、字幕が１６：９ビデオ上に表示されるか、又はレターボックス上に表示されるようにできる。

同図で、ビデオＡは、説明した第３実施例によって送信される１６：９ビデオ及びそのビデオ上に表示されるレターボックスを例示する。受信機の性能に応じて、このビデオを処理する方式が異なってもよい。

まず、１６：９アスペクト比の表示を有する受信機においてビデオのための字幕（ｓｕｂｔｉｔｌｅ）が存在しない場合、受信機は、１６：９ビデオ及びレターボックスをそのまま表示することができる。一方、送信されるビデオのための字幕が含まれる場合、この受信機は、上のレターボックス（Ｔｏｐ ＡＦＤ ｂａｒ）を削除又は分離し、下のレターボックス（ｂｏｔｔｏｍ ＡＦＤ ｂａｒ）を２倍に拡張するか、又は上のレターボックスを下のレターボックスに付けて、２倍のサイズのレターボックス（ＡＦＤ＿ｓｉｚｅ＿２Ｎ）にビデオ形式を変換して表示することができる。

すなわち、５０４０×２１６０のＵＨＤビデオを挙げると、受信機は、受信されたビデオに対して、３８４０×Ｎ×２（ここで、Ｎはレターボックスの高さ）サイズのレターボックス（ＡＦＤバー）をビデオの下部に挿入し、その位置に字幕を表示して画面を効率的に配置させることができる。ここで、２×Ｎは１３５になり得る。すなわち、例示した５０４０×２１６０のＵＨＤビデオ形式を１６：９の（ＵＨＤ又はＨＤ）ビデオ形式に変更する場合、ビデオの下部に字幕の表示のために挿入されるレターボックスの高さ（ＡＦＤ＿ｓｉｚｅ＿２Ｎ）は５１５になる（５０４０：３８４０＝２１６０：（２１６０−Ｘ）−＞Ｘ＝５１５＝ＡＦＤ＿ｓｉｚｅ＿２Ｎ）。仮に、ビデオのための字幕が存在しない場合は、既存方法と同様に、ビデオの上下にそれぞれ３８４０×ＮのＡＦＤバーを挿入することができる。これは、より高い解像度のビデオに対しても同様の方式で適用可能である。

一方、２１：９ビデオを送信する場合、２１：９アスペクト比の表示を有する受信機は、字幕がある場合にそのビデオ上に字幕を表示し、そうでない場合は、そのビデオをそのまま受信して表示することができる。

以下では、本発明の実施例によってビデオが送受信される場合、それを処理できる放送信号の通知情報を例示する。

図１６は、本発明の第１実施例によってビデオを表示できる通知情報を例示する図である。同図は、システムレベルで通知情報としてＰＭＴを例示するが、ＰＭＴのｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈの直後にプログラムレベルの記述子と、ＥＳ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドの直後にストリームレベルの記述子とを含むことができる。

同図は、プログラムレベルの記述子の例としてＵＨＤ＿ｐｒｏｇｒａｍ＿ｔｙｐｅ＿ｄｅｓｃｒｉｐｔｏｒを例示する。

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、この記述子の識別子を示す。

そして、ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅは、上述したとおり、それぞれの実施例を識別する情報を含むことができる。

例えば、ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０１の場合は、本発明の第１実施例を示すものであり、送信される２１：９のＵＨＤビデオを、１６：９ＨＤビデオ、１６：９ＵＨＤビデオ、及び２１：９ＵＨＤビデオと１６：９ＵＨＤビデオとの差に該当する領域を別の層データを用いて表示できるビデオ形式であるか、又はそのビデオ形式によるサービスタイプを示す。

ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０２の場合は、本発明の第２実施例を示すものであり、送信される２１：９のＵＨＤビデオを、２１：９ビデオ又は１６：９ビデオのためのクロップ情報を用いて表示できるビデオ形式であるか、又はそのビデオ形式によるサービスタイプを示す。

ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０３の場合は、本発明の第３実施例を示すものであり、送信される２１：９のＵＨＤビデオを、１６：９ビデオと２１：９ビデオのためのレターボックス（ＡＦＤバー）情報を用いて表示できるビデオ形式であるか、又はそのビデオ形式によるサービスタイプを示す。

そして、ストリームレベルの記述子の例として、ＵＨＤ ｃｏｍｐｏｓｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒを例示する。この記述子は、本発明による第１、２、３の実施例に対してサービス又はプログラムを構成するストリームに関する情報を含むことができる。

例えば、第１実施例に従う場合、基本層データ、強化層１データ及び強化層２データをそれぞれ送信するストリームを識別する情報を含むことができる。これについては後述する。

図１７は、本発明の第１実施例による通知情報の具体的な構文値を例示する図である。

本発明の実施例による情報を放送信号の通知情報で通知し、その通知情報がＰＭＴの場合、例示されたフィールド値は次の情報を示すことができる。

第１実施例は、基本層データ、第１強化層データ及び第２強化層データを送信するストリームをそれぞれ送信するが、この実施例はそれらのデータをすべて通知することができる。

まず、第１実施例で、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒフィールドは、２１：９ＵＨＤプログラムに対するプログラム番号情報を示すことができる。

そして、基本層データを送信するストリームに対しては、ＰＭＴに次のような情報を含むことができる。Ｓｔｒｅａｍ＿ｔｙｐｅは、ＭＰＥＧ−２ビデオコーデックによるビデオストリームを示す０ｘ０２などの値になり得る。Ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤは、各プログラムに含まれるエレメントリストリームのＰＩＤ値を示すが、この例は０×１０９Ａという値を示すことを例示する。ストリームレベルの記述子は、ＭＰＥＧ−２ビデオに関連する通知情報を含むことができる。

第１強化層データを送信するストリームに対しては、ＰＭＴに次のような情報を含むことができる。Ｓｔｒｅａｍ＿ｔｙｐｅは、ＨＥＶＣ ｓｃａｌａｂｌｅ ｌａｙｅｒビデオコーデックによるストリームのタイプを示すが、ここでは、この値を０ｘＡ１の値と例示した。Ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤは、各プログラムに含まれるエレメントリストリームのＰＩＤ値を示すが、この例は０×１０９Ｂという値を示することを例示する。ストリームレベルの記述子であるＵＨＤＴＶ＿ｓｕｂ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒ（）は、基本層を用いて１６：９ビデオを構成するために必要な第１強化層データに関連する通知情報を含むことができる。

第２強化層データを送信するストリームに対しては、ＰＭＴに次のような情報を含むことができる。Ｓｔｒｅａｍ＿ｔｙｐｅは、ＨＥＶＣ ｓｃａｌａｂｌｅ ｌａｙｅｒビデオコーデックによるストリームのタイプを示すが、ここでは、この値を０ｘＡ２の値と例示した。Ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤは、各プログラムに含まれるエレメントリストリームのＰＩＤ値を示すが、この例は０×１０９Ｃという値を示することを例示する。ストリームレベルの記述子であるＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ（）は、第２強化層データ及び２１：９ＵＨＤビデオを復元するために、関連する通知情報を含むことができる。

図１８は、本発明の第１実施例に従う場合、ストリームレベル記述子の一例を例示する。

図１６の例によれば、プログラムレベルの記述子に含まれるＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅは、第１実施例に対して０ｘ０１の値を有することができる。

ストリームレベル記述子は、この記述子を識別できるｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ値、この記述子の長さを示すｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ、及びＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ（）を含むことができる。

この例で、ＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ（）に含まれる情報を例示すると、次のとおりである。

ＥＬ２＿ｖｉｄｅｏ＿ｃｏｄｅｃ＿ｔｙｐｅフィールドは、ＵＨＤサービスに含まれるビデオエレメントのコーデック情報を示す。例えば、この値はＰＭＴのｓｔｒｅａｍ＿ｔｙｐｅと同じ値を有することができる。

ＥＬ２＿ｖｉｄｅｏ＿ｐｒｏｆｉｌｅフィールドは、対応するビデオストリームに関するプロファイル情報、すなわち、対応するストリームを復号するために必要な基本仕様に関する情報を示すことができる。対応するビデオストリームの色深度（ｃｏｌｏｒ ｄｅｐｔｈ）（４：２：０、４：２：２など）、ビット深度（ｂｉｔ ｄｅｐｔｈ）（８ｂｉｔ、１０ｂｉｔ）、符号化ツール（ｃｏｄｉｎｇ ｔｏｏｌ）などに関する要求事項情報を含むことができる。

ＥＬ２＿ｖｉｄｅｏ＿ｌｅｖｅｌフィールドは、対応するビデオストリームに関するレベル情報であって、プロファイルで定義した記述要素サポート範囲に関する情報を含むことができる。

ＥＬ２＿ｖｉｄｅｏ＿ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅフィールドは、対応するビデオストリームがＵＨＤサービス構成する場合、いずれのデータを含むかを示す。例えば、ストリームは１６：９ＨＤに該当する基本層データであるか、１６：９の第１強化層データであるか、又は２１：９ＵＨＤのための第２強化層データであるかを示す識別情報を示す。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ｔｙｐｅフィールドは、ＵＨＤビデオ形式に関する情報を通知するものであり、ビデオの解像度及びフレームレートなどのような基本的な情報を示すことができる。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ａｓｐｅｃｔ＿ｒａｔｉｏフィールドは、原ＵＨＤビデオのアスペクト比に関する情報を示す。

ＥＬ２＿ｖｉｄｅｏ＿ｗｉｄｔｈ＿ｄｉｖ１６フィールド及びＥＬ２＿ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｈｅｉｇｈｔ＿ｄｉｖ１６フィールドは、第２強化層データに該当するｓｕｂ＿ｖｉｄｅｏの解像度情報を示す。例えば、第２強化層データとして表示されるビデオの横及び縦のサイズを１６の倍数単位で表現することができる。

ＥＬ２＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎフィールドは、クロップされたビデオの方向情報を示すことができる。

ＥＬ２＿ｖｉｄｅｏ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｙｐｅフィールドは、ＵＨＤビデオのうちｓｕｂ＿ｖｉｄｅｏが一つのビデオにまとめられて一つのストリームとして送信されるとき、ｓｕｂ＿ｖｉｄｅｏを構成する方法を示す。

ＥＬ２＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄｃフィールドは、ＵＨＤビデオの左右のｓｕｂ−ｖｉｄｅｏを圧縮するとき、独立して符号化したか、又は１６：９ＵＨＤビデオとの相関した符号化方式を用いたかに関する情報を示す。

ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｆｉｌｔｅｒ＿ｎｕｍフィールドは、左右のクロップされたビデオを復号化する場合、ビデオにブロック化された領域（歪み（ａｒｔｉｆａｃｔ））が存在するためフィルタ処理を適用することがあるが、このフィルタ処理を適用するか否か、及びフィルタの個数を示す。

ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｆｉｌｔｅｒｉｎｇ＿ｃｏｒｄｉｎａｔｅ＿ｘ＿ｄｉｖ４フィールドと、ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｆｉｌｔｅｒｉｎｇ＿ｃｏｒｄｉｎａｔｅ＿ｙ＿ｄｉｖ４フィールドとは、フィルタ処理を適用すべきビデオの部分のＸ方向、Ｙ方向の最初の画素の座標をそれぞれ示す。実際の座標は、このフィールドに４を乗じた値になり得る。例えば、この場合、座標はＵＨＤビデオを基準にすることができる。すなわち、基本層、第１強化層及び第２強化層を用いて復元したＵＨＤビデオを基準にすることができる。

ｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｆｉｌｔｅｒｉｎｇ＿ｗｉｄｔｈ＿ｄｉｖ４フィールドとｅｎｈａｎｃｅｍｅｎｔ＿ｖｉｄｅｏ＿ｆｉｌｔｅｒｉｎｇ＿ｗｉｄｔｈ＿ｄｉｖ４フィールドは、フィルタ処理を適用すべきビデオ領域のサイズを画素の個数で示すことができる。例えば、フィルタ処理を適用すべき領域のサイズは、実際のサイズに４を乗じた値になり得る。

図１９は、上に例示したビデオの解像度及びフレームレートを示す情報の値を例示する図である。通知情報のうち、ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ｔｙｐｅフィールドは、ビデオの解像度及びフレームレートを示すことができるが、同図では、この値によって様々な解像度及びフレームレートを有し得ることを例示する。例えば、ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ｔｙｐｅフィールドが０１０１値の場合、原ビデオは秒当たり６０フレーム、５０４０×２１６０解像度を有することができる。

図２０は、原ビデオのアスペクト比に関する情報を例示する図である。説明した通知情報のうちｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ａｓｐｅｃｔ＿ｒａｔｉｏフィールドは、原ＵＨＤビデオのアスペクト比に関する情報を示す。同図は、例えば、この値が１０の場合、２１：９アスペクト比を示すことを例示する。

図２１は、クロップされたビデオの方向情報を例示する図である。説明した通知情報のうちＥＬ２＿ｖｉｄｅｏ＿ｄｉｒｅｃｔｉｏｎフィールドは、クロップされたビデオ（第２強化層データ）の方向情報を例示する。例えば、本発明の第１実施例でクロップされた左右ビデオは方向情報を有することができるが、この方向に関する情報値が００のとき左側、０１のとき右側、１０のとき上側、１１のとき下側の方向を有することを例示する。

図２２は、ビデオを構成する方法の例を示す図である。上述したＥＬ２＿ｖｉｄｅｏ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｙｐｅフィールドは、基本層データ、第１強化層データ及び第２強化層データが結合する場合、これらを結合させる通知情報を例示する。

第１実施例において、例えば、このフィールド値が０１のとき、第２強化層データが上下（ｔｏｐ／ｂｏｔｔｏｍ）に結合され、１０のとき第２強化層データが左右（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）に結合されることを例示し、１１のとき、サブストリームが、基本層データ及び第１強化層データと共に、サブストリーム以外の別のストリームとして送信されることを示す。

図２３は、サブストリームを符号化する場合、符号化方式に対する例を示す図である。第１実施例に従うとき、説明したＥＬ２＿ｄｅｐｅｎｄｅｎｃｙ＿ｉｄｃフィールドは、ＵＨＤビデオに含まれる基本層データ、第１強化層データ及び第２強化層データが互いに相関して符号化されるか、又は独立して符号化されるかを示すことができる。例えば、特定データを符号化するとき、時間予測や視点予測に用いられるデータは相関して符号化されるといえる。

例えば、このフィールドの値が０１のとき、第２強化層データが他のデータと相関することなく独立して符号化されたことを示し、１０のとき、第２強化層データが他のデータと相関して符号化されたことを示す。

次に、本発明の第２実施例に従う場合、ビデオを表示できる通知情報を例示する。

図２４は、図１６のＰＭＴに含み得るストリームレベル記述子を例示する図である。

本発明の第２実施例に従う場合、ＨＤビデオストリームとＵＨＤビデオストリームは別個のストリームとして送信することができる。そして、ＵＨＤビデオストリームは、受信機のアスペクト比を考慮して他のアスペクト比に変換できるようにメタデータを含むことができる。

同様に、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇとｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、この記述子の識別子及び長さをそれぞれ示す。

ここで、１６＿９＿ｅｘｔｅｎｓｉｏｎ＿ｉｎｆｏ＿ｍｅｔａｄａｔａ（）は、第２実施例の場合、ＵＨＤビデオを構成するストリームに関する通知情報が含まれている。

例えば、ＥＬ２＿ｖｉｄｅｏ＿ｃｏｄｅｃ＿ｔｙｐｅフィールドは、ＵＨＤサービスに含まれるビデオエレメントのコーデック情報を示す。例えば、この値はＰＭＴのｓｔｒｅａｍ＿ｔｙｐｅと同じ値を有することができる。

ＥＬ２＿ｖｉｄｅｏ＿ｐｒｏｆｉｌｅフィールドは、対応するビデオストリームに関するプロファイル情報、すなわち、対応するストリームを復号するために必要な基本仕様に関する情報を示すことができる。対応するビデオストリームの色深度（４：２：０、４：２：２など）、ビット深度（８ｂｉｔ、１０ｂｉｔ）、符号化ツールなどに関する要求事項情報を含むことができる。

ＥＬ２＿ｖｉｄｅｏ＿ｌｅｖｅｌフィールドは、対応するビデオストリームに関するレベル情報であって、プロファイルで定義した記述要素サポート範囲に関する情報を含むことができる。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ｔｙｐｅフィールドは、ＵＨＤビデオ形式に関する情報を通知する情報であって、ビデオの解像度及びフレームレートなどのようなビデオに関連した情報を示すことができる。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ａｓｐｅｃｔ＿ｒａｔｉｏフィールドは、ＵＨＤビデオのアスペクト比に関する情報を示すことができる。

１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｓｔａｒｔ＿ｘフィールド、１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｓｔａｒｔ＿ｙフィールド、１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｅｎｄ＿ｘフィールド、及び１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｅｎｄ＿ｙフィールドは、ＵＨＤビデオの解像度が５０４０×２１６０のような２１：９形式である場合、この中で有効な１６：９画面領域を指定できる位置情報を示す。対応する領域において左側上端の画素位置は１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｓｔａｒｔ＿ｘ、１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｓｔａｒｔ＿ｙによって指定され、対応する領域において右側下端の画素位置は１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｅｎｄ＿ｘ、１６＿９＿ｒｅｃｔａｎｇｌｅ＿ｅｎｄ＿ｙによって指定され得る。これらのフィールドを用いて、１６：９表示形式を有する受信機は、これらのフィールドによって指定された領域だけを出力することができ、残りの領域はクロップし、表示しなくてもよい。

図２５は、例示した第３実施例に従う場合、通知情報を例示する図である。

本発明の第３実施例に従う場合、２１：９アスペクト比のビデオは１６：９アスペクト比のビデオとして送信される。このとき、受信機の画面によって、１６：９の表示を有する受信機は、従来のように字幕をビデオ上に表示し、２１：９の表示を有する受信機は、画面の空いた部分に字幕を表示することができる。

この場合、ＰＭＴのストリームレベルの記述子は、同図で例示した情報を含むことができる。

同様に、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ及びｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、この記述子の識別子及び長さをそれぞれ示す。ＵＨＤ＿ｓｕｂｔｉｔｌｅ＿ｐｏｓｉｔｉｏｎ＿ｉｎｆｏ（）は、字幕が位置する情報を含むことができる。

ＵＨＤ＿ｖｉｄｅｏ＿ｃｏｄｅｃ＿ｔｙｐｅフィールドは、ＵＨＤサービスに含まれるビデオエレメントのコーデック情報を示す。例えば、この値はＰＭＴのｓｔｒｅａｍ＿ｔｙｐｅと同じ値を有することができる。

ＵＨＤ＿ｖｉｄｅｏ＿ｐｒｏｆｉｌｅフィールドは、対応するビデオストリームに関するプロファイル情報、すなわち、対応するストリームを復号するために必要な基本仕様に関する情報を示すことができる。対応するビデオストリームの色深度（４：２：０、４：２：２など）、ビット深度（８ｂｉｔ、１０ｂｉｔ）、符号化ツールなどに関する要求事項情報を含むことができる。

ＵＨＤ＿ｖｉｄｅｏ＿ｌｅｖｅｌフィールドは、対応するビデオストリームに関するレベル情報であって、プロファイルで定義した技術要素サポート範囲に関する情報を含むことができる。

２１：９ビデオを１６：９表示に合うビデオ形式に変換するとき、ビデオを単純にクロップする場合と、ビデオを拡大縮小（ｓｃａｌｉｎｇ）してレターボックス領域（ＡＦＤバー）を挿入する場合がある。

ＵＨＤ＿ｖｉｄｅｏ＿ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅフィールドは、変換された１６：９ビデオが拡大縮小したビデオか、又はクロップしたビデオかの情報を示す。

ＵＨＤ＿ｖｉｄｅｏ＿ｉｎｃｌｕｄｅ＿ｓｕｂｔｉｔｌｅフィールドは、対応するストリームによるビデオ内に字幕が提供されるか否かを示す。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ｔｙｐｅフィールドは、ＵＨＤビデオ形式に関する情報を通知する情報であって、ビデオの解像度及びフレームレートなどのような、ビデオに関連する情報を示すことができる。

ｏｒｉｇｉｎａｌ＿ＵＨＤ＿ｖｉｄｅｏ＿ａｓｐｅｃｔ＿ｒａｔｉｏフィールドは、ＵＨＤビデオのアスペクト比に関する情報を示すことができる。

ＡＦＤ＿ｓｉｚｅ＿２Ｎフィールドは、ＵＨＤ＿ｖｉｄｅｏ＿ｉｎｃｌｕｄｅ＿ｓｕｂｔｉｔｌｅでストリームによるビデオに字幕が含まれていない場合には、（横解像度×ＡＦＤ＿ｓｉｚｅ＿２Ｎ／２）のＡＦＤバーを上下にそれぞれ追加し、字幕が含まれているビデオに対するストリームの場合は、（横解像度×ＡＦＤ＿ｓｉｚｅ＿２Ｎ）分のＡＦＤ＿ｂａｒを下端に追加できることを示すことができる。字幕をビデオ上に表示できる場合、字幕はレターボックス領域（ＡＦＤバー）上に表示することができる。受信機は、このフィールドを用いて上下のレターボックス領域を除く残りの２１：９ビデオ領域を出力する過程で、ビデオは上方に上げ、残る領域に字幕を表示させることによって、字幕位置を調整する機能を提供することができる。

図２６は、例示したＵＨＤ＿ｖｉｄｅｏ＿ｃｏｍｐｏｎｅｎｔ＿ｔｙｐｅフィールドのフィールド値を例示する。例えば、このフィールドを用いると、受信される１６：９ビデオは、クロップしたビデオか又は拡大縮小後にレターボックス（ＡＦＤバー）を挿入したビデオかを識別できる。

図２７は、例示したＵＨＤ＿ｖｉｄｅｏ＿ｉｎｃｌｕｄｅ＿ｓｕｂｔｉｔｌｅフィールドのフィールド値を例示する。例えば、この値が０か又は１かによって、ストリーム又はストリームによるビデオに字幕が含まれているか又は含まれていないかを示すことができる。

図２８は、送信ビデオの形式と受信機の表示アスペクト比とが異なる場合、受信機の動作の例を示す図である。

同図で、送信されるビデオの形式は最右列（Ａ−１、Ｂ−１、Ｃ−１）に例示し、中間列は受信機の動作（Ａ−２、Ｂ−２、Ｃ−２）、最左列は受信機動作によって表示できる画面（Ａ−３、Ａ−４、Ｂ−３、Ｂ−４、Ｃ−３、Ｃ−４）を例示する。説明を簡単にするために、送信ビデオ形式は２１：９、受信機の表示は１６：９とする。

例えば、送信ビデオが２１：９のビデオ形式を有する場合（Ａ−１）、受信機は、表示装置又はその性能に応じて、当該ビデオにレターボックス領域（ＡＦＤバー）を挿入し、当該ビデオに対して拡大縮小を行う（Ａ−２）。このとき、例示した通知情報によって字幕がない場合（Ａ−３）、受信機は、レターボックス領域をビデオの上下に挿入して表示し、字幕がある場合（Ａ−４）は、受信機はレターボックス領域をビデオの下端に追加してレターボックス領域に字幕を表示することができる。

他の例として、送信ビデオが２１：９のビデオ形式を有する場合（Ａ−２）、受信機は、表示装置又はその性能に応じて当該ビデオをクロップする（Ｂ−２）。仮に、例示した第１実施例の場合（Ｂ−３）、互いに関係付けて、又は独立して符号化した基本層データ、第１強化層データ、第２強化層データを復号して、１６：９アスペクト比の表示に表示することができる。この場合、第２強化層データは復号しないか、又は復号されたデータを使用しなくてもよい。

第２実施例の場合（Ｂ−４）、通知情報に含まれたクロップ座標情報を用いて１６：９画面の表示に表示することができる。

他の例として、送信ビデオが２１：９の形式を有するが、１６：９のビデオ符号化形式に２１：９のビデオ形式及びＡＦＤバーイメージが追加された１６：９のビデオ形式を有する場合（Ｃ−１）、受信機は、受信されたビデオをそのまま表示することができる（Ｃ−２）。

このとき、受信機は、送信ビデオの１６：９ビデオ符号化形式を有効形式としてビデオ形式１６：９にＡＦＤが追加された形態を識別して、レターボックス領域を上下にそのまま表示することもでき（Ｃ−３）、ストリームの内部に字幕があると、既存に挿入されたｂａｒ領域を切り出して下端に追加し、その領域に字幕を表示することもできる（Ｃ−４）。

図２９は、例示した記述子が、他の通知情報に含まれる場合を例示する。同図は、例示した記述子がＳＤＴに含まれる場合を例示する。

ｔａｂｌｅ＿ｉｄフィールドは、テーブルの識別子を示す。

ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＳＤＴテーブルセクション対して１に設定される１ビットフィールドである（ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ：このｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒは、“１”に設定しなければならない１ビットフィールドである）

ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、セクションの長さをバイト数で示す。（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ：１２ビットフィールドで、このフィールドの最初の２ビットは“００”に設定しなければならない。このフィールドは、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドに直ちに続いて開始され、かつＣＲＣを含むセクションのバイト数を特定する。このｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈは、全体セクションが１０２４バイトの最大長さを有するように１０２１バイトを超えてはならない）

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、送信システム内の他の多重ストリームと区別して、このＳＤＴが提供するＴＳ識別子を示す。（ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ：送信システム内の他の多重ストリームと区別して、このＳＤＴが知らせるＴＳの識別子として機能する１６ビットフィールドである。）

ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、このサブテーブルのバージョン番号を示す。（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ：この５ビットフィールドは、ｓｕｂ＿ｔａｂｌｅのバージョン番号である。このｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、ｓｕｂ＿ｔａｂｌｅ内の運ばれる情報に変化が発生した場合１ずつ増加しなければならない。値“３１”に到達したときは“０”に戻る。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒが“１”に設定されたときは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは現在適用可能なｓｕｂ＿ｔａｂｌｅのものでなければならない。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒが“０”に設定されたときは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、次に適用可能なｓｕｂ＿ｔａｂｌｅのものでなければならない。）

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、このサブテーブルが現在適用可能か又は次に適用可能かを示す。（ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ：この１ビット指示子は、“１”に設定されたときは、ｓｕｂ＿ｔａｂｌｅが現在適用可能なｓｕｂ＿ｔａｂｌｅであることを示す。上記ビットが“０”に設定されたときは、送信されたｓｕｂ＿ｔａｂｌｅはまだ適用不可であり、次に有効なｓｕｂ＿ｔａｂｌｅであることを示す。）

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、セクションの番号を示す。（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドはセクションの番号を提供する。ｓｕｂ＿ｔａｂｌｅの最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、“０ｘ００”でなければならない。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、同じｔａｂｌｅ＿ｉｄ、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ、及びｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄを有する各付加セクションに対して１ずつ増加しなければならない。）

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、最後のセクションの番号を示す。（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドは、ｓｕｂ＿ｔａｂｌｅの一部である最後のセクション（すなわち、このセクションは最も高いｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒを有する）の番号を特定する。）

ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄフィールドは、送信システムのネットワークＩＤの識別子を示す。（ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ：この１６ビットフィールドは、送出する送信システムのｎｅｔｗｏｒｋ＿ｉｄを識別する識別子を提供する。）

ｓｅｒｖｉｃｅ＿ｉｄフィールドは、ＴＳ内サービス識別子を示す。（ｓｅｒｖｉｃｅ＿ｉｄ：ＴＳ内の他のサービスと区別して、このサービスを識別するための識別子として機能する１６ビットフィールドである。このｓｅｒｖｉｃｅ＿ｉｄは、対応するｐｒｏｇｒａｍ＿ｍａｐ＿ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ＿ｎｕｍｂｅｒと同一である。）

ＥＩＴ＿ｓｃｈｅｄｕｌｅ＿ｆｌａｇフィールドは、サービスに対するＥＩＴスケジュール情報が現在ＴＳにあるかを示すことができる（ＥＩＴ＿ｓｃｈｅｄｕｌｅ＿ｆｌａｇ：“１”に設定されたときは、サービスに対するＥＩＴスケジュール情報が現在ＴＳに存在することを示す１ビットフィールドであり、ＥＩＴスケジュールｓｕｂ＿ｔａｂｌｅの発生間の最大時間間隔に関する情報に対するＴＲ １０１ ２１１ ［ｉ．２］を参照されたい。このフラグが０に設定されたときは、サービスに対するＥＩＴスケジュール情報がＴＳに存在してはならない。）

ＥＩＴ＿ｐｒｅｓｅｎｔ＿ｆｏｌｌｏｗｉｎｇ＿ｆｌａｇフィールドは、現在ＴＳにサービスに対するＥＩＴ＿ｐｒｅｓｅｎｔ＿ｆｏｌｌｏｗｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ情報があるかを示すことができる（ＥＩＴ＿ｐｒｅｓｅｎｔ＿ｆｏｌｌｏｗｉｎｇ＿ｆｌａｇ：“１”に設定されたときは、サービスに対するＥＩＴ＿ｐｒｅｓｅｎｔ＿ｆｏｌｌｏｗｉｎｇｉｎ ｆｏｒｍａｔｉｏｎが現在ＴＳに存在することを示す１ビットフィールドであり、ＥＩＴ現在／後続ｓｕｂ＿ｔａｂｌｅの発生間の最大時間間隔に関する情報に対するＴＲ １０１ ２１１ ［ｉ．２］を参照されたい。このフラグが０に設定されたときは、サービスに対するＥＩＴ現在／後続情報がＴＳに存在してはならない。）

ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓフィールドは、ＤＶＢ−ＳＩ文書のテーブル６に定義されたサービスの状態を示すことができる（ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓ：サービスの状態を表６に定義されたように示す３ビットフィールドである。ＮＶＯＤ参照サービスに対して、ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓの値は“０”に設定しなければならない。）

ｆｒｅｅ＿ＣＡ＿ｍｏｄｅフィールドは、サービスのすべてのコンポーネントストリームがスクランブルされているかを示す。（ｆｒｅｅ＿ＣＡ＿ｍｏｄｅ：この１ビットフィールドは、“０”に設定されたときは、サービスのすべてのコンポーネントストリームがスクランブルされていないことを示す。“１”に設定されたときは、一つ以上のストリームへのアクセスがＣＡシステムにより制御されてもよいことを示す。）

ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールドは、後続する記述子の長さを示す。（ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈ：この１２ビットフィールドは、後続する記述子の全体バイト長を示す）。

ＣＲＣ＿３２は、ＣＲＣ値を含む３２ビットフィールドである（ＣＲＣ＿３２：復号器におけるレジスタのゼロ出力を示すＣＲＣ値を含む３２ビットフィールドである。）

ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールドは、次の記述子位置に、図１６で例示したＵＨＤ＿ｐｒｏｇｒａｍ＿ｔｙｐｅ＿ｄｅｓｃｒｉｐｔｏｒと、本発明の実施例によって図１８、図２４、又は図２５に例示したＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを含むことができる。

ＤＶＢのＳＤＴにＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒが含まれる場合、ＵＨＤ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドを更に含むことができる。ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドは、ＰＳＩレベルであるＰＭＴで通知する対応するストリームに対するＰＩＤ値を示すことができる。受信機は、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドを用いてＰＭＴと共に対応するストリームのＰＩＤ値を探すことができる。

図３０は、例示した記述子が他の通知情報に含まれる場合を例示する。同図は、例示した記述子がＥＩＴに含まれる場合を例示する。

ＥＩＴは、ＥＴＳＩ ＥＮ３００ ４６８に従うことができる。これを用いて各フィールドを述べると、下記のとおりである。

ｔａｂｌｅ＿ｉｄ：テーブル識別子を示す。

ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＥＩＴテーブルセクション対して１に設定される１ビットフィールドである（ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ：このｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒは、“１”に設定しなければならない１ビットフィールドである。）

ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、セクションの長さをバイト数で示す。（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ：１２ビットフィールドである。このフィールドは、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドに直ちに続いて開始され、かつＣＲＣを含むセクションのバイト数を特定する。このｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈは、全体セクションが４０９６バイトの最大長を有するように４０９３バイトを超えてはならない。）

ｓｅｒｖｉｃｅ＿ｉｄフィールドは、ＴＳ内サービス識別子を示す。（ｓｅｒｖｉｃｅ＿ｉｄ：ＴＳ内の他のサービスと区別して、このサービスを識別するための識別子として機能する１６ビットフィールドである。このｓｅｒｖｉｃｅ＿ｉｄは、対応するｐｒｏｇｒａｍ＿ｍａｐ＿ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ＿ｎｕｍｂｅｒと同一である。）

ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、このサブテーブルのバージョン番号を示す。（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ：この５ビットフィールドは、ｓｕｂ＿ｔａｂｌｅのバージョン番号である。このｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、ｓｕｂ＿ｔａｂｌｅ内の運ばれる情報に変化が発生した場合、１ずつ増加しなければならない。値“３１”に到達したときは“０”に戻る。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒが“１”に設定されたときは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、現在適用可能なｓｕｂ＿ｔａｂｌｅのものでなければならない。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒが“０”に設定されたときは、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、次に適用可能なｓｕｂ＿ｔａｂｌｅのものでなければならない。）

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、このサブテーブルが現在適用可能か又は次に適用可能かを示す。（ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ：この１ビット指示子は、“１”に設定されたときは、ｓｕｂ＿ｔａｂｌｅが現在適用可能なｓｕｂ＿ｔａｂｌｅであることを示す。上記ビットが“０”に設定されたときは、送信されたｓｕｂ＿ｔａｂｌｅはまだ適用不可であり、次に有効なｓｕｂ＿ｔａｂｌｅであることを示す。）

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、セクションの番号を示す。（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドはセクションの番号を提供する。ｓｕｂ＿ｔａｂｌｅの最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは“０ｘ００”でなければならない。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは同じｔａｂｌｅ＿ｉｄ、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ、及びｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄを有する各付加セクションに対して１ずつ増加しなければならない。この場合、ｓｕｂ＿ｔａｂｌｅは、多数のセグメントで構成することができる。各セグメント内で、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、各付加セクションに対して１ずつ増加するが、番号付けの間隔は、セグメントの最後のセクションと隣接セグメントの最初のセクションとの間で許容される。）

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、最後のセクションの番号を示す。（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドは、ｓｕｂ＿ｔａｂｌｅの一部である最後のセクション（すなわち、このセクションは最も高いｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒを有する）の番号を特定する。））

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、送信システム内の他の多重ストリームと区別して、このＳＤＴが提供するＴＳ識別子を示す。（ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ：送信システム内の他の多重ストリームと区別して、このＥＩＴが知らせるＴＳの識別子として機能する１６ビットフィールドである。）

ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄフィールドは、送信システムのネットワークＩＤの識別子を示す。（ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ：この１６ビットフィールドは、送出する送信システムのｎｅｔｗｏｒｋ＿ｉｄを識別する識別子を提供する。）

ｓｅｇｍｅｎｔ＿ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、このサブテーブルのこのセグメントの最後のセクション番号を示す。（ｓｅｇｍｅｎｔ＿ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドはｓｕｂ＿ｔａｂｌｅのこのセグメントの最後のセクション番号を示す。分割されないサブテーブルに対して、このフィールドはｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドと同じ値に設定しなければならない。）

ｌａｓｔ＿ｔａｂｌｅ＿ｉｄフィールドは、用いられる最後のｔａｂｌｅ＿ｉｄを示す８ビットフィールドである（表２参照）。

ｅｖｅｎｔ＿ｉｄフィールドは、イベントの識別番号を示す。（ｅｖｅｎｔ＿ｉｄ：記述されるイベントの識別番号を含む１６ビットフィールドである（サービス定義内で固有に割り当てられる））。

ｓｔａｒｔ＿ｔｉｍｅフィールドは、イベントの開始時刻を含む。（ｓｔａｒｔ＿ｔｉｍｅ：この４０ビットフィールドは、協定世界時（ＵＴＣ：Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ、Ｃｏ−ｏｒｄｉｎａｔｅｄ）及び修正ユリウス日（ＭＪＤ：Ｍｏｄｉｆｉｅｄ Ｊｕｌｉａｎ Ｄａｔｅ）によるイベントの開始時刻を含む（付録Ｃを参照）。このフィールドは、４ビットの２進化１０進数（ＢＣＤ：ＢｉｎａｒｙＣｏｄｅｄＤｅｃｉｍａｌ）で６桁として符号化された２４ビットが後続するＭＪＤの１６ ＬＳＢを提供する１６ビットとして符号化される。開始時刻が定義されると（例えば、（ＮＶＯＤ基準サービスのイベントに対しては）このフィールドのすべてのビットは“１”に設定される。）

ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓフィールドは、ＤＶＢＳＩ文書の表６に定義されたイベントの状態を示す。（ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓ：表６に定義されたようなイベントの状態を示す３ビットフィールドである。ＮＶＯＤ基準イベントに対して、ｒｕｎｎｉｎｇ＿ｓｔａｔｕｓの値は“０”に設定しなければならない。）

ｆｒｅｅ＿ＣＡ＿ｍｏｄｅフィールドは、サービスのすべてのコンポーネントストリームがスクランブルされているかを示す。（ｆｒｅｅ＿ＣＡ＿ｍｏｄｅ：この１ビットフィールドは、“０”に設定されたときは、サービスのすべてのコンポーネントストリームがスクランブルされていないことを示す。“１”に設定されたときは、一つ以上のストリームへのアクセスがＣＡシステムにより制御されることを示す。）

ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールドは、後続する記述子の長さを示す。（ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈ：この１２ビットフィールドは、後続する記述子の全体バイト長を提供する）。

ＣＲＣ＿３２は、ＣＲＣ値を含む３２ビットフィールドである（ＣＲＣ＿３２：復号器においてレジスタのゼロ出力を提供するＣＲＣ値を含む３２ビットフィールドである）。

ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｏｏｐ＿ｌｅｎｇｔｈフィールドは、次の記述子位置に、図１６で例示したＵＨＤ＿ｐｒｏｇｒａｍ＿ｔｙｐｅ＿ｄｅｓｃｒｉｐｔｏｒと、本発明の実施例によって図１８、図２４、又は図２５に例示したＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒとを含むことができる。

ＤＶＢのＥＩＴにＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒが含まれる場合、ＵＨＤ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒは、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドを更に含むことができる。ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドは、ＰＳＩレベルであるＰＭＴで通知する対応するストリームに対するＰＩＤ値を示すことができる。受信機は、ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドを用いてＰＭＴと共に対応するストリームのＰＩＤ値を探すことができる。

図３１は、例示した記述子が他の通知情報に含まれる場合を例示する。同図は、例示した記述子がＶＣＴに含まれる場合を例示する。

ＶＣＴは、ＡＴＳＣ ＰＳＩＰ規格に従うことができる。ＡＴＳＣＰＳＩＰによれば、各フィールドの説明は、下記のとおりである。各ビットの説明を下記のように開示する。

ｔａｂｌｅ＿ｉｄフィールドは、テーブルセクションのタイプを示す８ビット符号無し整数を示す。（ｔａｂｌｅ＿ｉｄ：ここに定義されるテーブルセクションのタイプを示す８ビット符号無し整数である。ｔｅｒｒｅｓｔｒｉａｌ＿ｖｉｒｔｕａｌ＿ｃｈａｎｎｅｌ＿ｔａｂｌｅ＿ｓｅｃｔｉｏｎ（）に対して、ｔａｂｌｅ＿ｉｄは０ｘＣ８でなければならない。）

ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＶＣＴテーブルセクション対して１に設定される１ビットフィールドである（ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ：このｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒは、ｔｅｒｒｅｓｔｒｉａｌ＿ｖｉｒｔｕａｌ＿ｃｈａｎｎｅｌ＿ｔａｂｌｅ＿ｓｅｃｔｉｏｎ（）に対して‘１’に設定しなければならない１ビットフィールドである）。

ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは１に設定される（ｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒ−この１ビットフィールドは‘１’に設定しなければならない）

ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、セクションの長さをバイト数で示す。（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ−１２ビットのフィールドで、その最初の２ビットは‘００’でなければならない。このフィールドは、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドに直ちに後続し、かつＣＲＣを含むセクションのバイト数を特定する。）

ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄフィールドは、ＴＶＣＴを識別できるＰＡＴでのように、ＭＰＥＧ−ＴＳＩＤを示す。（ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ：１６ビットＭＰＥＧ−２送信ストリームＩＤは、この多重ストリームに対してゼロのＰＩＤ値により識別されるＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）でのように示される。ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄは、このＴｅｒｒｅｓｔｒｉａｌ ＶＣＴを他のＰＴＣで放送され得るほかのものと区別する。）

ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、ＶＣＴのバージョン番号を示す。（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ：この５ビットフィールドは、ＶＣＴ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）のバージョン番号である。現在ＶＣＴに対して（ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ＝‘１’）、バージョン番号は、現在ＶＣＴの定義が変化する度に１ずつ増加しなければならない。値３１に到達したときは、０に戻らなければならない。次のＶＣＴに対して（ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ＝‘０’）、バージョン番号は、現在ＶＣＴよりも多い一つのユニットでなければならない（モジューロ３２演算でも）。いずれの場合も、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの値は、該当するＭＧＴの各値と一致しなければならない。）

ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、このＶＣＴテーブルが現在適用可能か又は次に適用可能かを示す。（ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ：この１ビット指示子は、“１”に設定されたときは、送信されたＶＣＴが現在適用可能であることを示す。上記ビットが“０”に設定されたときは、送信されたテーブルはまだ適用不可であり、次に有効なｓｕｂ＿ｔａｂｌｅでなければならないことを示す。この標準は、“次の”テーブル（これらはｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒが‘０’に設定される）が送信されなければならないという要求事項を賦課しない。現在適用可能なテーブルに対するアップデートは、増加するｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドにより通知される。）

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、セクションの番号を示す。（ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ−この８ビットフィールドは、このセクションの番号を提供する。Ｔｅｒｒｅｓｔｒｉａｌ ＶＣＴの最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、“０ｘ００”でなければならない。これは、Ｔｅｒｒｅｓｔｒｉａｌ ＶＣＴにおいて各付加セクションに対して１ずつ増加しなければならない。）

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、最後のセクションの番号を示す。（ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ：この８ビットフィールドは、完全なＴｅｒｒｅｓｔｒｉａｌ ＶＣＴの最後のセクション（すなわち、このセクションは最も高いｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒを有する）の番号を特定する。）

ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、将来、現在プロトコルと異なるように定義されるパラメータのためのプロトコルバージョンを示す。（ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ：将来、このテーブルタイプが、現在プロトコルに定義されたのと異なるように定義され得るパラメータを運ぶことを許容する機能を有する８ビット符号無し整数フィールドである。現在、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎに対する有効な値は、ゼロだけである。ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎの非零値は、この標準の将来のバージョンにより用いられて、定義的に異なるテーブルを示することができる。）

ｎｕｍ＿ｃｈａｎｎｅｌｓ＿ｉｎ＿ｓｅｃｔｉｏｎフィールドは、このＶＣＴの仮想チャネルの数を示す。（ｎｕｍ＿ｃｈａｎｎｅｌｓ＿ｉｎ＿ｓｅｃｔｉｏｎ：この８ビットフィールドは、このＶＣＴセクションの仮想チャネルの数を特定する。このチャネルの数はセクション長によって制限される。）

ｓｈｏｒｔ＿ｎａｍｅフィールドは、仮想チャネルの名前を示す。（ｓｈｏｒｔ＿ｎａｍｅ：仮想チャネルの名前は、ユニコード文字データのＵＴＦ−１６ ｒｅｐｒｅｓｅｎｔａｔｉｏｎによって解釈される、１から７の１６ビットコード値シーケンスで表現される。名前の長さが７の１６ビットコード値よりも少なく必要な場合は、このフィールドは、ユニコードヌル文字（０ｘ００００）を用いて７の１６ビットコード値に詰め込まれなければならない。ユニコード文字データは、ユニコード規格、バージョン３．０ ［１３］に従うことができる。）

ｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、仮想チャネルに関係付けたメジャーチャネル番号を示す。（ｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ：“ｆｏｒ”ループの反復で定義される仮想チャネルと関係付けた“メジャー”チャネル番号を示す１０ビット数である。各仮想チャネルは、メジャー及びマイナチャネル番号と関連付けられる。メジャーチャネル番号は、マイナチャネル番号と共に、仮想チャネルに対するユーザの参照番号として機能する。ｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは、から９９であってもよい。ｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒの値は、ＴＶＣＴ内で重複するｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ／ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ対が存在する場合がないように設定しなければならない。米国のｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ割当については付録Ｂを参照されたい。）

ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、仮想チャネルと関係付けたマイナチャネル番号を示す。（ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ：“ｍｉｎｏｒ”又は“ｓｕｂ”チャネル番号を示す、０から９９９までの範囲の１０ビット数である。このフィールドは、ｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒと共に、２部分チャネル番号として機能し、ここで、ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは、上記番号の２番目又は右側部分を示す。ｓｅｒｖｉｃｅ＿ｔｙｐｅがアナログテレビである場合、ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒは０に設定される。ｓｅｒｖｉｃｅ＿ｔｙｐｅがＡＴＳＣ＿ｄｉｇｉｔａｌ＿ｔｅｌｅｖｉｓｉｏｎ、ＡＴＳＣ＿ａｕｄｉｏ＿ｏｎｌｙ、又はｕｎａｓｓｏｃｉａｔｅｄ／ｓｍａｌｌ＿ｓｃｒｅｅｎ＿ｓｅｒｖｉｃｅであるサービスは、１から９９のマイナ番号を用いる。ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒの値は、ＴＶＣＴ内で重複するｍａｊｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ／ｍｉｎｏｒ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ対が存在する場合がないように設定しなければならない。データ放送のような他のタイプのサービスに対しては、有効マイナ仮想チャネル番号は１から９９９である。）

ｍｏｄｕｌａｔｉｏｎ＿ｍｏｄｅモードは、仮想チャネルと関係付けた搬送波の変調モードを示す。（ｍｏｄｕｌａｔｉｏｎ＿ｍｏｄｅ：この仮想チャネルと関係付けた送信される搬送波に対する変調モードを示す８ビット符号無し整数を示す。ｍｏｄｕｌａｔｉｏｎ＿ｍｏｄｅの値は、表６．５のように定義される。デジタル信号に対して、変調モードの標準値（０ｘ８０よりも小さい値）は、適切な標準に対する参照によって、送信フレーム構造、チャネル符号化、インタリーブ、チャネル変調、順方向誤り訂正、シンボルレート、及び他の送信関連パラメータを示す。このｍｏｄｕｌａｔｉｏｎ＿ｍｏｄｅは、非活性のチャネルに対しては無視される。）

ｃａｒｒｉｅｒ＿ｆｒｅｑｕｅｎｃｙフィールドは、搬送周波数を識別できるフィールドである（ｃａｒｒｉｅｒ＿ｆｒｅｑｕｅｎｃｙ：この３２ビットの推奨値はゼロである。搬送周波数を識別するためのこのフィールドの使用は許容されるが、近い将来に廃止される予定である。）

ｃｈａｎｎｅｌ＿ＴＳＩＤフィールドは、この仮想チャネルによって参照されたＭＰＥＧ−２プログラムを送信するＴＳと関係付けたＭＰＥＧ−２ ＴＳＩＤを示す。（ｃｈａｎｎｅｌ＿ＴＳＩＤ−この仮想チャネル８によってり参照されるＭＰＥＧ−２プログラムを搬送する送信ストリームと関係付けたＭＰＥＧ−２送信ストリームＩＤを示す、０ｘ００００から０ｘＦＦＦＦ範囲の１６ビット符号無し整数フィールドである。非活性のチャネルに対して、ｃｈａｎｎｅｌ＿ＴＳＩＤは、チャネルが活性化する場合、サービスを運ぶようになる送信ストリームのＩＤを示す。受信機は、ｃｈａｎｎｅｌ＿ＴＳＩＤを用いて、ある受信された送信ストリームが実際所望の多重ストリームであるかを確認すると予想される。アナログチャネルに対して（ｓｅｒｖｉｃｅ＿ｔｙｐｅ ０ｘ０１）、ｃｈａｎｎｅｌ＿ＴＳＩＤは、ＮＴＳＣ信号のＶＢＩに含まれるアナログＴＳＩＤの値を示す。アナログＴＳＩＤの使用に関する議論については付録Ｄセクション９を参照されたい。）

ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒフィールドは、この仮想チャネルとＰＭＴとが関係付けられて定義される整数値を示す。（ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒ：ここに定義される仮想チャネルをＭＰＥＧ−２プログラムアソシエーション及びＴＳプログラムマップテーブルと関連付ける１６ビット符号無し整数である。アナログサービスを示す仮想チャネルに対して、０ｘＦＦＦＦの値はｐｒｏｇｒａｍ＿ｎｕｍｂｅｒに対して特定される。非活性チャネル（これらのチャネルは、送信ストリームに現在存在しない）に対して、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒはゼロに設定される。この番号は、プログラムマップテーブル（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）項目を示すと解釈されてはならない。）

ＥＴＭ＿ｌｏｃａｔｉｏｎフィールドは、拡張テキストメッセージ（Ｅｘｔｅｎｄｅｄ Ｔｅｘｔ Ｍｅｓｓａｇｅ、ＥＴＭ）の存在及び位置を示す。（ＥＴＭ＿ｌｏｃａｔｉｏｎ−この２ビットフィールドは、ＥＴＭの存在及び位置を特定し、表６．６に定義したとおりである。）

ａｃｃｅｓｓ＿ｃｏｎｔｒｏｌｌｅｄフィールドは、アクセス制御（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）された仮想チャネルと関係付けたイベントを示すことができる。（ａｃｃｅｓｓ＿ｃｏｎｔｒｏｌｌｅｄ：設定されたときは、この仮想チャネルと関係付けられたイベントがアクセス制御され得ることを示す１ビットのブールフラグである。フラグが‘０’に設定されたときは、イベントアクセスは制限されない。）

ｈｉｄｄｅｎフィールドは仮想チャネルがユーザの直接チャネル入力によってアクセスされない場合を示すことができる。（ｈｉｄｄｅｎ：設定されたときは、仮想チャネルが仮想チャネル番号の直接入力を用いてユーザによってアクセスされないことを示す１ビットブールフラグである。隠蔽（Ｈｉｄｄｅｎ）仮想チャネルは、ユーザがチャネルサーフィンをしている場合はスキップされ、直接チャネル入力によってアクセスされると、未定義のように表示される。隠蔽チャネルに対する標準的なアプリケーションは、テスト信号及びＮＶＯＤサービスである。隠蔽チャネル及びそのイベントがＥＰＧ表示に示されるか否かは、ｈｉｄｅ＿ｇｕｉｄｅビットの状態による。）

ｈｉｄｅ＿ｇｕｉｄｅフィールドは、仮想チャネル及びそのイベントがＥＰＧに表示できるかを示すことができる。（ｈｉｄｅ＿ｇｕｉｄｅ：隠蔽チャネルに対して‘０’に設定されたときは、仮想チャネル及びそのイベントがＥＰＧ表示に表示され得ることを示すブールフラグである。このビットは、隠蔽ビットセットを有しないチャネルについては無視される。よって、隠されていないチャネル及びそのイベントは、ｈｉｄｅ＿ｇｕｉｄｅビットの状態に関係なく常にＥＰＧ表示に含まれてもよい。ｈｉｄｅ＿ｇｕｉｄｅビットが‘１’に設定された隠蔽チャネルに対する標準的なアプリケーションは、テスト信号、及びアプリケーションレベルポインタを通じてアクセス可能なサービスである。）

ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドは、サービスタイプ識別子を示す。（ｓｅｒｖｉｃｅ＿ｔｙｐｅ：この６ビットフィールドは、サービスタイプ識別子を運ばなければならない。サービスタイプ及び上記関係付けたｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドは、Ａ／５３ Ｐａｒｔ １ ［１］に定義され、仮想チャネルで運ばれるサービスのタイプを識別する。値０ｘ００は予約される。値０ｘ０１は、アナログテレビプログラミングを意味する。他の値は、Ａ／５３ Ｐａｒｔ ３ ［３］に定義され、他のＡＴＳＣ標準は他のサービスタイプ９を定義することができる。）

ソース＿ｉｄフィールドは、仮想チャネルと関係付けたプログラムソースを識別する識別番号である（ソース＿ｉｄ：仮想チャネルと関連付くプログラミングソースを識別する１６ビット符号無し整数である。これと関連して、ソースは、ビデオ、テキスト、データ、又はオーディオプログラミングのうちの一つの特定ソースである。ソースＩＤ値０は予約される。０ｘ０００１から０ｘ０ＦＦＦ範囲のソースＩＤ値は、ＶＣＴを運ぶ送信ストリーム内で固有であり、０ｘ１０００から０ｘＦＦＦＦの値は局所レベルで固有である。ソース＿ｉｄｓ ０ｘ１０００及びそれ以上に対する値は発行されて、ＡＴＳＣで指定する登録機関によって運営されなければならない。）

ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈフィールドは、後続する記述子の長さを示す。（ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈ：後続するこの仮想チャネルに対する記述子の全体長さ（バイト））

ｄｅｓｃｒｉｐｔｏｒ（）に記述子を含むことができる。（ｄｅｓｃｒｉｐｔｏｒ（）：ゼロ又はそれ以上の記述子を、必要によって含むことができる。）

本発明の実施例によってビデオサービスが送信される場合、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドは、ｐａｒａｍｅｔｅｒｉｚｅｄ ｓｅｒｖｉｃｅ（０ｘ０７）又はｅｘｔｅｎｄｅｄ ｐａｒａｍｅｔｅｒｉｚｅｄ ｓｅｒｖｉｃｅ（０ｘ０９）、又はｓｃａｌａｂｌｅ ＵＨＤＴＶサービスを示すフィールド値を有することができる。

そして、記述子位置に、図１６で例示したＵＨＤ＿ｐｒｏｇｒａｍ＿ｔｙｐｅ＿ｄｅｓｃｒｉｐｔｏｒ、図１８、図２４、図２５で例示したＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを配置してもよい。

次に、本発明の実施例によってビデオデータが送信される場合、ビデオデータの構文を開示する。

図３２は、本発明の実施例によるビデオデータのＳＥＩ領域のペイロードに対する構文を例示する。

ＳＥＩペイロードにおいてｐａｙｌｏａｄＴｙｐｅが特定値（この例では５１）に設定されたときは、例示したとおり、ビデオデータの形式を通知する情報（ＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ（ｐａｙｌｏａｄＳｉｚｅ））を含むことができる。

ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅは、図１６で例示したとおりであり、例えば、ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０１の場合、本発明の第１実施例を示すものであり、送信される２１：９のＵＨＤビデオが、１６：９ＨＤビデオ、１６：９ＵＨＤビデオ、及び２１：９ＵＨＤビデオと１６：９ＵＨＤビデオとの差である領域を別のレイヤデータを用いて表示できるビデオ形式であることを示す。

このとき、ビデオデータは、ＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ値を含むことができる。この値は、図１８で例示したとおりである。

ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０２の場合は、本発明の第２実施例を示すものであり、送信される２１：９のＵＨＤビデオが、２１：９ビデオ又は１６：９ビデオのためのクロップ情報を用いて表示され得るビデオ形式であることを示す。

このとき、ビデオデータは１６＿９＿Ｅｘｔｒａｃｔｉｏｎ＿Ｉｎｆｏ＿Ｍｅｔａｄａｔａ値を含むことができる。この値は、図２４で例示したとおりである。

ＵＨＤ＿ｐｒｏｇｒａｍ＿ｆｏｒｍａｔ＿ｔｙｐｅが０ｘ０３の場合は、本発明の第３実施例を示すものであり、送信される２１：９のＵＨＤビデオが、１６：９ビデオと２１：９ビデオのためのレターボックス（ＡＦＤバー）情報を用いて表示されるビデオ形式であることを示す。

このとき、ビデオデータは、ＵＨＤ＿ｓｕｂｔｉｔｌｅ＿ｐｏｓｉｔｉｏｎ＿ｉｎｆｏ値を含むことができる。この値は、図２５で例示したとおりである。

受信機のビデオ復号器は、それぞれ上に例示したＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ ＳＥＩ ｍｅｓｓａｇｅをパースすることができる。ＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ（）は、符号化されたビデオデータソースであるＳＥＩ ＲＢＳＰ（ｒａｗ ｂｙｔｅ ｓｅｑｕｅｎｃｅ ｐａｙｌｏａｄ）を通じて受信される。

ビデオ復号器は、ＡＶＣ又はＨＥＶＣ ＮＡＬ ｕｎｉｔをパースし、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値がＳＥＩデータに該当する値である場合、ｐａｙｌｏａｄＴｙｐｅが５１であるＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ ＳＥＩ ｍｅｓｓａｇｅを読む。

そして、同図で例示したＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ（）を復号し、現在ビデオデータに関するＵＨＤ＿ｃｏｍｐｏｓｉｔｉｏｎ情報、１６：９ｅｘｔｒａｃｔｉｏｎ情報、又はＵＨＤ＿ｓｕｂｔｉｔｌｅ＿ｐｏｓｉｔｉｏｎ情報を得ることができる。ビデオデータ領域の情報を用いて、受信機は、１６：９ＨＤ及びＵＨＤ、２１：９ＵＨＤストリームの構成情報などを把握して、最終的にＵＨＤビデオを出力することができる。

したがって、受信機は、通知情報領域とビデオデータ領域から、本発明で開示する実施例によるビデオデータを判断し、それに基づいてビデオ形式を変換して受信機に応じて表示することができる。

図３３は、本発明の実施例によってビデオデータが送信される場合、少なくとも一つの実施例によるビデオデータを復号して表示できる受信装置の一例を示す図である。同図で、ビデオに関連するデータは、Ａ、Ｂ、Ｄ１、Ｄ２及びＥでそれぞれ示す。

本発明による信号受信装置の一例は、逆多重化器４００、通知情報処理部５００、及びビデオ復号器６００を含むことができる。

逆多重化器４００は、本発明の実施例によるビデオストリーム及び通知情報をそれぞれ逆多重化することができる。例えば、ビデオストリームは、図２乃至図５で例示したビデオを送信するストリームを含むことができる。

通知情報処理部５００は、図１６乃至図２７、図２９乃至図３１で例示した通知情報又は受信機の性能に応じてその一部を復号することができる。例えば、通知情報処理部５００は、図１８、図２４、及び図２５のうち少なくとも一つの記述子の通知情報を復号することができる。

ビデオ復号器６００は、通知情報処理部５００が処理した通知情報によって、逆多重化器４００が逆多重化したビデオデータを復号することができる。この場合、図３２で例示したビデオデータの構文によるビデオデータの符号化情報又は通知情報を用いてビデオデータを復号することができる。

ビデオ復号器６００は、第１復号器６１０、第２復号器６２０、及び第３復号器６３０のうち少なくとも一つのビデオ復号器を含むことができる。

例えば、第１実施例によれば、ビデオ復号器６００は、第１復号器６１０、第２復号器６２０、及び第３復号器６３０を含むことができる。

第１復号器６１０は、逆多重化された１６：９ＨＤビデオを復号して出力することができる。この場合、第１復号器６１０は、図３２で例示した符号化情報（ＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ）を復号することができる。第１復号器６１０が復号したビデオデータは、基本層データである１６：９ＨＤビデオデータＡとして出力され得る。

拡大器（アップスケーラ）６１５は、基本層データである１６：９ＨＤビデオデータを拡大して２１：９ビデオデータを出力する。

第２復号器６２０は、拡大された基本層データ及びレジデュアルデータを用いて調整可能な復号化を行うことができる。この場合、第２復号器６２０は、図３２で例示した符号化情報（ＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ）を復号することができる。第２復号器６２０が復号したビデオデータは、第２強化層データである１６：９ＵＨＤビデオデータＢとして出力することができる。

第３復号器６３０は、２１：９ビデオデータからクロップされたデータを復号したビデオデータＣを出力することができる。第３復号器６３０は、１６：９ＵＨＤビデオデータＢと関連した符号化方式によって復号を行うこともできる。同様に、この場合、第１復号器６３０は、図３２で例示した符号化情報（ＵＨＤＴＶ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｉｎｆｏ）を復号することができる。

そして、併合部６４０は、第２復号器６２０が出力する１６：９ＵＨＤビデオデータＢと第３復号器６３０が出力するクロップされたデータとを併合して出力することができる。

そして、フィルタ部６４０は、ビデオのうち併合された部分に対してフィルタ処理を行うことができる。フィルタ処理方式は、図１３及び式１乃至式１０で例示した。

図３４は、本発明による信号受信方法の一実施例を例示する図である。

本発明による信号受信方法の一実施例は、ビデオストリームと通知情報を逆多重化する（Ｓ２１０）。

ビデオストリームに含まれたビデオデータは、実施例によって異なる構造を有することができるが、この実施例は、図２及び図３（第１実施例）、図４（第２実施例）、図５乃至図７（第３実施例）によって異なる。例えば、受信されたビデオデータは、高解像度ビデオが既存のアスペクト比に合わせて分割されて送信され、これを再び高解像度ビデオに併合し得るデータを含むことができる。又は、受信されたビデオデータは、高解像度ビデオデータを受信機のアスペクト比に合わせて分割できる情報を含んでもよく、字幕を配置するためのレターボックス（例えば、ＡＦＤバー）の位置情報を含んでもよい。

受信する信号が放送信号である場合、図１６乃至図２７、図２９乃至図３１に例示した通知情報は、ビデオデータと別に逆多重化することができる。

受信する信号が放送信号である場合、逆多重化した通知情報を復号する（Ｓ２２０）。受信信号が放送信号でない場合にＳ２２０段階は省略され、次のビデオデータ復号段階でビデオデータ内の通知情報を復号する。放送信号に含まれて逆多重化された通知情報は、各実施例によって、図１６乃至図２７、図２９乃至図３１に例示した情報を含むことができるが、実施例によって上の図面で例示した情報を復号することができる。通知情報は、第１アスペクト比の高解像度ビデオデータを受信機にアスペクト比によらずに表示できる通知情報を含むことができる。例えば、受信機にアスペクト比によらずに表示できる通知情報は、高解像度ビデオデータのアスペクト比制御情報を含むことができる。

実施例による通知情報に基づいてビデオデータを復号する（Ｓ２３０）。ビデオデータは、図３２で例示したビデオデータ構文による符号化情報を含むビデオデータ情報を含むことができる。ビデオデータを復号する場合、実施例によって、対応するビデオデータを復号したとおり出力したり、併合したり、又は字幕を配置して出力したりすることができる。通知情報は、高解像度ビデオが既存のアスペクト比に合わせて分割されて送信された場合、これを再び高解像度ビデオに併合し得るデータを含むことができる。又は、通知情報は、高解像度ビデオデータを受信機のアスペクト比に合わせて分割し得る情報を含んでもよく、字幕を配置するためのレターボックス（例えば、ＡＦＤバー）の位置情報を含んでもよい。

すなわち、受信機は、画面制御情報を用いて第１アスペクト比の高解像度ビデオデータを受信機のアスペクト比に応じて変更して表示させることができる。

第１実施例によれば、アスペクト比制御情報は、符号化されたビデオデータが分割されて送信されることを示し、分割されたビデオデータを併合する併合情報を含むことができる。第２実施例によれば、アスペクト比制御情報は、符号化されたビデオデータをアスペクト比に合わせて分割可能な分割情報を含むことができる。そして、第３実施例によれば、アスペクト比制御情報は、符号化されたビデオデータそれぞれのビデオの解像度に応じてビデオの字幕位置を変更するための位置情報を含むことができる。

したがって、送信機で各実施例によってビデオデータを送信する場合、受信機の表示装置のアスペクト比が様々であるか、性能が様々であっても、それぞれ、対応する表示のアスペクト比に応じて高解像度ビデオ又は字幕を表示することができる。また、既存の受信機でも高解像度ビデオデータをその受信機のアスペクト比に応じて表示することができる。

図３５は、本発明による信号送信装置の一実施例を示す図である。

信号送信装置の一実施例は、符号化器５１０、通知情報生成部５２０、及び多重化器５３０を含むことができる。

符号化器５１０は、ビデオデータを符号化する。ビデオデータを符号化する場合、本発明の実施例によって、ビデオデータの符号化情報を符号化されたビデオデータに含めることができる。符号化されたビデオデータに含み得る符号化情報は、図３２で詳しく記述した。

符号化されたビデオデータは、開示した実施例によって異なる構造を有することができるが、この実施例は、図２及び図３（第１実施例）、図４（第２実施例）、図５乃至図７（第３実施例）によって異なる。

例えば、符号化されたビデオデータは、高解像度ビデオが既存のアスペクト比に合わせて分割された構造であり、分割されたビデオデータが、これを再び高解像度ビデオに併合できる情報を含むことができる。又は、符号化されたビデオデータは、高解像度ビデオデータを受信機のアスペクト比に合わせて分割し得る情報を含むか、又は字幕を配置するためのレターボックス（例えば、ＡＦＤバー）の位置情報を含むことができる。

送信信号が放送信号である場合、信号送信装置の一実施例は、符号化器５１０と別個に通知情報生成部５２０を含む。通知情報生成部５２０は、符号化されたビデオデータを受信機のアスペクト比に合わせて表示可能な通知情報を生成する。通知情報の例としては、各実施例によって、図１６乃至図２７、図２９乃至図３１に例示した情報を含むことができるが、実施例によって、図面で例示した情報を生成することができる。通知情報は、第１アスペクト比の高解像度ビデオデータを、アスペクト比によらず受信機に表示できる通知情報を含むことができる。例えば、アスペクト比によらず受信機に表示できる通知情報は、高解像度ビデオデータのアスペクト比制御情報を含むことができる。

多重化器５３０は、符号化されたビデオデータと通知情報とを多重化し、多重化されたビデオデータと通知情報を送信する。

送信機が各実施例によってビデオデータを送信する場合、受信機表示装置のアスペクト比が様々であるか、性能が様々である場合にも、それぞれ、対応する表示のアスペクト比に応じて高解像度ビデオ又は字幕を表示することができる。また、既存の受信機でも高解像度ビデオデータをその受信機のアスペクト比に応じて表示することができる。

送信データが放送信号でない場合には、ビデオデータと多重化される通知情報を生成する通知情報生成部５２０は省略され、多重化器５３０は、符号化器５１０が符号化したビデオデータ領域内に通知情報だけ含めたビデオデータと他のデータ（例えば、オーディオデータ）を多重化して出力する。

図３６は、本発明による信号受信装置の一実施例を例示する図である。

信号受信装置の一実施例は、逆多重化器６１０、通知情報復号部６２０、及びビデオ復号器６３０を含むことができる。

逆多重化器６１０は、ビデオストリーム及び通知情報を逆多重化する。

ビデオストリームに含まれたビデオデータは、実施例によって異なる構造を有することができるが、この実施例は、図２及び図３（第１実施例）、図４（第２実施例）、図５乃至図７（第３実施例）によって異なる。例えば、受信されたビデオデータは、高解像度ビデオが既存のアスペクト比に合わせて分割されて送信され、これを再び高解像度ビデオに併合し得るデータを含むことができる。又は、受信されたビデオデータは、高解像度ビデオデータを受信機のアスペクト比に合わせて分割できる情報を含んでもよく、字幕を配置するためのレターボックス（例えば、ＡＦＤバー）の位置情報を含んでもよい。

通知情報復号部６２０は、逆多重化した通知情報を復号する。逆多重化された通知情報は、各実施例によって、図１６乃至図２７、図２９乃至図３１に例示した情報を含むことができるが、実施例によって、上の図面で例示した情報を復号することができる。通知情報は、第１アスペクト比の高解像度ビデオデータを受信機にアスペクト比によらずに表示できる通知情報を含むことができる。例えば、受信機にアスペクト比によらずに表示できる通知情報は、高解像度ビデオデータのアスペクト比制御情報を含むことができる。

ビデオ復号器６３０は、実施例による通知情報によってビデオデータを復号する。ビデオデータは、図３２で例示したビデオデータ構文による符号化情報を含むビデオデータ情報を含むことができる。ビデオデータを復号する場合、実施例によって、対応するビデオデータを復号したまま出力したり、併合したり、又は字幕を配置して出力したりすることができる。

アスペクト比制御情報は、受信された高解像度ビデオが既存のアスペクト比に合わせて分割されて送信された場合、これを再び高解像度ビデオに併合し得るデータを含むことができる。又は、通知情報は、高解像度ビデオデータを受信機のアスペクト比に合わせて分割し得る情報を含んでもよく、字幕を配置するためのレターボックス（例えば、ＡＦＤバー）の位置情報を含んでもよい。

したがって、送信機で各実施例によってビデオデータを送信する場合、受信機表示装置のアスペクト比が様々であるか、性能が様々である場合にも、それぞれ、対応する表示のアスペクト比に応じて高解像度ビデオ又は字幕を表示することができる。また、既存の受信機でも高解像度ビデオデータをアスペクト比制御情報によってその受信機のアスペクト比に応じて表示することができる。

（実施例）
発明の実施例は、以上説明した発明を実施するための形態で併せて記述された。

本願の発明は、放送及びビデオ信号処理分野で使用可能であり、反復可能な産業上利用可能性がある。

Claims (8)

1. 信号を送信する方法であって、
   ビデオデータを符号化するステップであって、
   符号化された前記ビデオデータは、超高解像度（ＵＨＤ）サービスに関する超高解像度（ＵＨＤ）ビデオデータを有し、
   前記ビデオデータは、基本層に関する第１エレメントと強化層に関する第２エレメントとを分離するよう符号化される、ステップと、
   通知情報を生成するステップであって、
   前記通知情報は、前記ＵＨＤサービスの符号化形式及びフレームレートを示す情報を有し、
   前記通知情報は、前記ＵＨＤサービスに関する前記第１エレメント及び前記第２エレメントのコーデック情報によるストリームタイプ情報を有し、
   前記通知情報は、前記ＵＨＤサービスに関するアスペクト比情報をさらに有し、
   前記ストリームタイプ情報は、前記ＵＨＤサービスの前記第２エレメントに関するＨＥＶＣコーデック情報を識別する、ステップと、
   前記符号化されたビデオデータと前記通知情報とを多重化し、前記多重化されたビデオデータ及び通知情報を送信するステップと、を有し、
   前記第１エレメントは、高解像度（ＨＤ）ビデオに対応し、前記第２エレメントは、超高解像度（ＵＨＤ）ビデオに対応し、
   前記第１エレメント及び前記第２エレメントは、ＨＥＶＣスケーラブルコーデックを用いて符号化される、方法。
2. 前記通知情報は、前記ＵＨＤサービスの前記第１エレメントと前記第２エレメントとの結合に関するアスペクト比制御情報を有し、
   前記アスペクト比制御情報は、前記符号化されたビデオデータが分割されて送信されることを示し、前記分割されたビデオデータを併合する併合情報を含む、請求項１に記載の方法。
3. 前記アスペクト比制御情報は、前記符号化されたビデオデータをアスペクト比に合わせて分割可能な分割情報を含む、請求項２に記載の方法。
4. 前記アスペクト比制御情報は、前記符号化されたビデオデータの前記第１エレメント及び前記第２エレメントの解像度に応じて、前記ビデオの字幕位置を変更するための位置情報を含む、請求項２に記載の方法。
5. 信号を送信する装置であって、
   ビデオデータを符号化する符号化器であって、
   前記ビデオデータは、超高解像度（ＵＨＤ）サービスに関する超高解像度（ＵＨＤ）ビデオデータを有し、
   前記ビデオデータは、基本層に関する第１エレメントと強化層に関する第２エレメントとを分離するよう符号化される、符号化器と、
   通知情報を生成する通知情報生成部であって、
   前記通知情報は、前記ＵＨＤサービスの符号化形式及びフレームレートを示す情報を有し、
   前記通知情報は、前記ＵＨＤサービスに関する前記第１エレメント及び前記第２エレメントのコーデック情報によるストリームタイプ情報を有し、
   前記通知情報は、前記ＵＨＤサービスに関するアスペクト比情報をさらに有し、
   前記ストリームタイプ情報は、前記ＵＨＤサービスの前記第２エレメントに関するＨＥＶＣコーデック情報を識別する、通知情報生成部と、
   前記符号化されたビデオデータと前記通知情報とを多重化する多重化器と、を備え、
   前記第１エレメントは、高解像度（ＨＤ）ビデオに対応し、前記第２エレメントは、超高解像度（ＵＨＤ）ビデオに対応し、
   前記第１エレメント及び前記第２エレメントは、ＨＥＶＣスケーラブルコーデックを用いて符号化される、装置。
6. 前記通知情報は、前記ＵＨＤサービスの前記第１エレメントと前記第２エレメントとの結合に関するアスペクト比制御情報を有し、
   前記アスペクト比制御情報は、前記符号化されたビデオデータが分割されて送信されることを示し、前記分割されたビデオデータを併合する併合情報を含む、請求項５に記載の装置。
7. 前記アスペクト比制御情報は、前記符号化されたビデオデータをアスペクト比に合わせて分割可能な分割情報を含む、請求項６に記載の装置。
8. 前記アスペクト比制御情報は、前記符号化されたビデオデータの前記第１エレメント及び前記第２エレメントの解像度に応じて、前記ビデオの字幕位置を変更するための位置情報を含む、請求項６に記載の装置。

Images