JP6633739B2 - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 - Google Patents

放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Download PDF

Info

Publication number
JP6633739B2
JP6633739B2 JP2018509764A JP2018509764A JP6633739B2 JP 6633739 B2 JP6633739 B2 JP 6633739B2 JP 2018509764 A JP2018509764 A JP 2018509764A JP 2018509764 A JP2018509764 A JP 2018509764A JP 6633739 B2 JP6633739 B2 JP 6633739B2
Authority
JP
Japan
Prior art keywords
information
service
hdr
metadata
type
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.)
Active
Application number
JP2018509764A
Other languages
English (en)
Other versions
JP2018532294A (ja
Inventor
ヒョンムク オ
ヒョンムク オ
チョンヨル ソ
チョンヨル ソ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2018532294A publication Critical patent/JP2018532294A/ja
Application granted granted Critical
Publication of JP6633739B2 publication Critical patent/JP6633739B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Description

本発明は、放送信号送信装置、放送信号受信装置、及び放送信号を送受信する方法に関する。
アナログ放送信号の送信が終了するに伴い、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてさらに多くの量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加えて、様々なタイプの付加データをさらに含むことができる。
デジタル放送システムは、ＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ ｃｈａｎｎｅｌ：多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
本発明の目的によって、ここに含まれ、概略的に記載されたように、本発明は、地上波放送網及びインターネット網を用いる次世代ハイブリッド放送をサポートする環境で次世代放送サービスを効果的にサポートすることができるシステム及び関連するシグナリング方案を提案する。
本発明は、地上波放送網及びインターネット網を用いる次世代ハイブリッド放送をサポートする環境で次世代放送サービスを効果的にサポートすることができる。
本発明は、放送サービスに含まれるサービスコンポーネントに対して、詳細なシグナリングを提供する方法をサポートすることができる。
本発明は、放送サービスを伝達する方案において、３Ｄ、キャプション、ＷＣＧ、ＨＤＲなどの様々な情報を効率的に提供する方法をサポートすることができる。
本発明の更なる理解を提供するために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に、本発明の実施例を示す。
本発明の一実施例に係るプロトコルスタックを示す図である。 本発明の一実施例に係るサービスディスカバリ手続を示す図である。 本発明の一実施例に係るＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）を示す図である。 本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。 本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。 本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）動作を示す図である。 本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）を示す図である。 本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す図である。 本発明の一実施例に係るタイムインタリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す図である。 本発明の一実施例に係る周波数インタリーバに含まれた各ＦＦＴモードによるメイン−ＰＲＢＳ生成器とサブ−ＰＲＢＳ生成器で構成されたインタリービングアドレス生成器のブロックダイヤグラムを示す図である。 本発明の一実施例に係るハイブリッド放送受信装置を示す図である。 本発明の一実施例に係るＤＡＳＨベースの適応型（Ａｄａｐｔｉｖｅ）ストリーミングモデルの全般的な動作を示す図である。 本発明の一実施例に係る受信機のブロックダイヤグラムを示す図である。 本発明の一実施例に係るメタデータベースのＨＤＲ放送サービスを制作、再生する装置を示す図である。 本発明の一実施例に係るＨＤＲビデオに対する受信機の動作方法を示す図である。 本発明の一実施例に係る後処理部を示す図である。 本発明の一実施例に係るＳＥＩメッセージ（ＳＥＩ ｍｅｓｓａｇｅ）及びＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）のシンタックスを示す図である。 本発明の一実施例に係るＳＥＩメッセージ及びＨＤＲ情報ディスクリプタのシンタックスを示す図である。 本発明の一実施例に係るＳＥＩメッセージ及びＨＤＲ情報ディスクリプタのシンタックスを示す図である。 本発明の一実施例に係るＳＥＩメッセージ及びＨＤＲ情報ディスクリプタのシンタックスを示す図である。 ＲＡＰによってメタデータ情報をシグナリングする実施例を示す図である。 ＲＡＰによってメタデータ情報をシグナリングする実施例を示す図である。 本発明の一実施例に係るｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏを示す図である。 本発明の一実施例に係るＨＥＶＣ内に定義されたＳＥＩメッセージを参照する場合を示す図である。 本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＰＭＴを介してシグナリングする実施例を示す図である。 本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＰＭＴを介してシグナリングする実施例を示す図である。 本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＥＩＴを介してシグナリングする実施例を示す図である。 本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＥＩＴを介してシグナリングする実施例を示す図である。 本発明の他の実施例に係るＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）を示す図である。 本発明の一実施例に係る受信機のブロック図及び動作方法を示す図である。 本発明の一実施例に係るＨＤＲ情報ディスクリプタを示す図である。 本発明の一実施例に係るＨＤＲ情報ディスクリプタを示す図である。 本発明の一実施例に係る特性セット（ｆｅａｔｕｒｅ ｓｅｔ）によってフレーム（ｆｒａｍｅ）内の領域を分割する場合を示す図である。 本発明の一実施例に係るＨＤＲ情報及び特性セットをシグナリングする情報を示す図である。 本発明の一実施例に係る空間領域を指定するためのＳｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールドを示す図である。 本発明の一実施例に係る空間領域を指定するためのＣｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙフィールドを示す図である。 本発明の一実施例に係る空間領域を指定するためのＬｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙフィールド及びＬｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙフィールドを示す図である。 本発明の一実施例に係る空間領域を指定するためのＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙフィールドを示す図である。 本発明の一実施例に係る放送送信機を示すブロック図である。 本発明の一実施例に係る放送受信機を示すブロック図である。 本発明の一実施例に係る画質改善メタデータを含む放送信号を送信する方法を示す図である。 本発明の一実施例に係る画質改善メタデータを含む放送信号を受信する方法を示す図である。
本発明の好適な実施例について具体的に説明し、その例を添付の図面に示す。添付の図面を参照した下記の詳細な説明は、本発明の具現可能な実施例を限定するものではなく、本発明の好適な実施例を説明するためのものである。下記の詳細な説明は、本発明に関する徹底した理解を提供するために細部事項を含む。しかし、当業者にとってはこれらの細部事項無しにも本発明の実行が可能であるということは明らかである。
本発明で使われる大部分の用語は、当該分野で広く使われる一般的なものから選択されるが、一部の用語は出願人によって任意に選択されてもよく、その意味は、必要時に次の説明で詳しく説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語の意図された意味に基づいて理解しなければならない。
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置並びに方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）又はＭＩＭＯ方式によって次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）方式などを含むことができる。本発明は、特定の用途に要求される性能を達成すると共に、受信機の複雑度を最小化するために最適化されたフィジカルプロファイル（又はシステム）を提案する。
図１は、本発明の一実施例に係るプロトコルスタックを示す図である。
サービスを複数個のレイヤを経て受信機に伝達することができる。まず、送信側ではサービスデータを生成することができる。送信側のデリバリレイヤでは、サービスデータに、伝送のための処理を行い、フィジカルレイヤでは、これを放送信号にエンコードして、放送網又はブロードバンドを介して伝送することができる。
ここで、サービスデータは、ＩＳＯ ＢＭＦＦ（ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔ）によるフォーマットで生成することができる。ＩＳＯ ＢＭＦＦメディアファイルは、放送網／ブロードバンドデリバリ、メディアエンカプセレーション（ｍｅｄｉａ ｅｎｃａｐｓｕｌａｔｉｏｎ）及び／又は同期化フォーマット（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｆｏｒｍａｔ）で用いることができる。ここで、サービスデータは、サービスに関連した全てのデータであり、リニアサービスを構成するサービスコンポーネント、それに対するシグナリング情報、ＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）データ、その他のファイルなどを含む概念であってもよい。
デリバリレイヤについて説明する。デリバリレイヤはサービスデータに対する伝送機能を提供することができる。サービスデータは、放送網及び／又はブロードバンドを介して伝達することができる。
放送網を介したサービスデリバリ（ｂｒｏａｄｃａｓｔ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）において、２つの方法を挙げることができる。
第一の方法は、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）に基づいて、サービスデータをＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ）として処理し、これをＭＭＴＰ（ＭＭＴ ｐｒｏｔｏｃｏｌ）を用いて伝送することができる。この場合、ＭＭＴＰによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント及び／又はそれに関するサービスシグナリング情報などを含むことができる。
第二の方法は、ＭＰＥＧ ＤＡＳＨに基づいて、サービスデータをＤＡＳＨセグメントとして処理し、これをＲＯＵＴＥ（Ｒｅａｌ ｔｉｍｅ Ｏｂｊｅｃｔ ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を用いて伝送することができる。この場合、ＲＯＵＴＥプロトコルによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。すなわち、ＮＲＴデータ及びファイルなどのノンタイムド（ｎｏｎ ｔｉｍｅｄ）データは、ＲＯＵＴＥを用いて伝達することができる。
ＭＭＴＰ又はＲＯＵＴＥプロトコルによって処理されたデータは、ＵＤＰ／ＩＰレイヤを経てＩＰパケットとして処理することができる。放送網を介したサービスデータ伝達において、ＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）もＵＤＰ／ＩＰレイヤを経て放送網を介して伝達することができる。ＳＬＴは、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブルに含めて伝達することができる。ＳＬＴ、ＬＬＳテーブルについては後述する。
ＩＰパケットはリンクレイヤでリンクレイヤパケットとして処理されてもよい。リンクレイヤは、上位レイヤから伝達される様々なフォーマットのデータを、リンクレイヤパケットとしてエンカプセレーションした後、フィジカルレイヤに伝達することができる。リンクレイヤについては後述する。
ハイブリッドサービスデリバリ（ｈｙｂｒｉｄ ｓｅｒｖｉｃｅ ｄｅｌｉｖｅｒｙ）においては、少なくとも１つのサービスエレメントをブロードバンドパス（ｐａｔｈ）を通じて伝達することができる。ハイブリッドサービスデリバリの場合、ブロードバンドで伝達されるデータは、ＤＡＳＨフォーマットのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。これらのデータはＨＴＴＰ／ＴＣＰ／ＩＰを経て処理され、ブロードバンド伝送のためのリンクレイヤを経て、ブロードバンド伝送のためのフィジカルレイヤに伝達されてもよい。
フィジカルレイヤは、デリバリレイヤ（上位レイヤ及び／又はリンクレイヤ）から伝達されたデータを処理して、放送網又はブロードバンドを介して伝送することができる。フィジカルレイヤに関する詳細な事項は後述する。
サービスについて説明する。サービスは、全体的にユーザに示すサービスコンポーネントのコレクションであり、コンポーネントは、様々なメディアタイプのものであり、サービスは、連続的又は間欠的であり、サービスは、実時間又は非実時間であってもよく、実時間サービスは、ＴＶ番組のシーケンスで構成することができる。
サービスは種々のタイプを有することができる。第一に、サービスはアプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオサービス又はオーディオだけのサービスであってもよい。第二に、サービスは、ダウンロードされたアプリケーションによってその再生／構成などが制御されるアプリベースのサービスであってもよい。第三に、サービスは、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を提供するＥＳＧサービスであってもよい。第四に、緊急警報情報を提供するＥＡ（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ）サービスであってもよい。
アプリベースのエンハンスメントを有しないリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、又は（２）１つ以上のＭＭＴＰセッションで伝達することができる。
アプリベースのエンハンスメントを有するリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、及び（２）０個以上のＭＭＴＰセッションで伝達してもよい。この場合、アプリベースのエンハンスメントに用いられるデータは、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達してもよい。本発明の一実施例において、１つのサービスのリニアサービスコンポーネント（ストリーミングメディアコンポーネント）が２つのプロトコルによって同時に伝達されることを許容しなくてもよい。
アプリベースのサービスを放送網を介して伝達する場合、サービスコンポーネントを、１つ以上のＲＯＵＴＥセッションで伝達することができる。この場合、アプリベースのサービスに用いられるサービスデータを、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達することができる。
また、このようなサービスの一部のサービスコンポーネント又は一部のＮＲＴデータ、ファイルなどをブロードバンドを介して伝達してもよい（ハイブリッドサービスデリバリ）。
すなわち、本発明の一実施例で、一つのサービスのリニアサービスコンポーネントをＭＭＴプロトコルによって伝達することができる。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネント及びＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＭＭＴプロトコルによって伝達し、ＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。これらの実施例において、サービスの一部のサービスコンポーネント又は一部のＮＲＴデータは、ブロードバンドを介して伝達してもよい。ここで、アプリベースのサービス又はアプリベースのエンハンスメントに関するデータはＮＲＴデータ形態で、ＲＯＵＴＥによる放送網を介して伝達したり、ブロードバンドを介して伝達してもよい。ＮＲＴデータは、ローカリキャッシュドデータ（Ｌｏｃａｌｌｙ ｃａｓｈｅｄ ｄａｔａ）などと呼ぶこともできる。
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的に又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリにおいて、ＬＣＴセッションはオーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアはＤＡＳＨセグメントとしてフォーマットされる。
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全体又は一部のコンテンツコンポーネントを伝達する１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
ＮＲＴユーザサービス又はシステムメタデータのデリバリのために、ＬＣＴセッションはファイルベースのコンテンツアイテムを伝達する。これらのコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、サービスシグナリング、又はＥＳＧフラグメントのようなメタデータで構成することができる。サービスシグナリング又はＥＳＧフラグメントのようなシステムメタデータのデリバリも、ＭＭＴＰのシグナリングメッセージモードで行うことができる。
受信機では、チューナーが周波数をスキャニングするが、特定周波数で放送シグナルを感知することができる。受信機は、ＳＬＴを抽出してその処理モジュールに送ることができる。ＳＬＴパーサーは、ＳＬＴをパースし、データを取得してチャネルマップに保存することができる。受信機は、ＳＬＴのブートストラップ情報を取得してＲＯＵＴＥ又はＭＭＴクライアントに伝達することができる。これによって受信機はＳＬＳを取得して保存することができる。ＵＳＢＤなどを取得することができ、これはシグナリングパーサーによってパースされてもよい。
図２は、本発明の一実施例に係るサービスディスカバリ手続を示す図である。
フィジカルレイヤの放送信号フレームが伝達するブロードキャストストリームは、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）を運搬することができる。ＬＬＳデータは、フェルノウン（ｗｅｌｌ ｋｎｏｗｎ）ＩＰアドレス／ポートに伝達されるＩＰパケットのペイロードで運搬することができる。このＬＬＳはそのタイプによってＳＬＴを含むことができる。ＬＬＳデータは、ＬＬＳテーブルの形態にフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの始めであってもよい。図示の実施例とは違い、ＬＬＳデータを伝達するＩＰストリームは、他のサービスデータと共に同一のＰＬＰを介して伝達してもよい。
ＳＬＴは、高速のチャネルスキャンによって受信機がサービスリストを生成できるようにし、ＳＬＳをロケーティング（ｌｏｃａｔｉｎｇ）するためのアクセス情報を提供する。ＳＬＴは、ブートストラップ情報を含むが、このブートストラップ情報は、受信機がそれぞれのサービスに対するＳＬＳ（Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）を取得できるようにする。ＳＬＳ、すなわち、サービスシグナリング情報がＲＯＵＴＥで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＬＣＴチャネル又はそのＬＣＴチャネルを含むＲＯＵＴＥセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。ＳＬＳがＭＭＴで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。
図示された実施例で、ＳＬＴが記述するサービス＃１のＳＬＳはＲＯＵＴＥで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＬＣＴチャネルを含むＲＯＵＴＥセッションに対するブートストラップ情報（ｓＩＰ１，ｄＩＰ１，ｄＰｏｒｔ１）を含むことができる。ＳＬＴが記述するサービス＃２のＳＬＳはＭＭＴで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＭＭＴＰパケットフローを含むＭＭＴＰセッションに対するブートストラップ情報（ｓＩＰ２，ｄＩＰ２，ｄＰｏｒｔ２）を含むことができる。
ＳＬＳは、当該サービスに対する特性を記述するシグナリング情報であり、当該サービス及び当該サービスのサービスコンポーネントを取得するための情報を提供したり、当該サービスを有意に再生するための受信機キャパビリティ情報などを含むことができる。各サービスに対して別個のサービスシグナリングを有すると、受信機は、ブロードキャストストリーム内で伝達される全てのＳＬＳをパースしないで、所望のサービスに対する適切なＳＬＳを取得すればよい。
ＳＬＳをＲＯＵＴＥプロトコルによって伝達する場合、ＳＬＳを、ＳＬＴが示すＲＯＵＴＥセッションの特定（ｄｅｄｉｃａｔｅｄ）のＬＣＴチャネルを介して伝達することができる。実施例によって、このＬＣＴチャネルはｔｓｉ＝０と識別されるＬＣＴチャネルであってもよい。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｂｕｎｄｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）及び／又はＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を含むことができる。
ここで、ＵＳＢＤ又はＵＳＤは、ＳＬＳフラグメントの一つであり、サービスの具体的な技術的情報を記述するシグナリングハブの役割を担うことができる。ＵＳＢＤは、サービス識別情報、デバイスキャパビリティ情報などを含むことができる。ＵＳＢＤは、他のＳＬＳフラグメント（Ｓ−ＴＳＩＤ、ＭＰＤなど）へのリファレンス情報（ＵＲＩリファレンス）を含むことができる。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれリファレンシングすることができる。また、ＵＳＢＤは、受信機が伝送モード（放送網／ブロードバンド）を決定できるようにするメタデータ情報をさらに含むことができる。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
Ｓ−ＴＳＩＤは、ＳＬＳフラグメントの一つであり、当該サービスのサービスコンポーネントを運搬する伝送セッションに対する全体的なセッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッション及び／又はそのＲＯＵＴＥセッションのＬＣＴチャネルに対する伝送セッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、一つのサービスと関連したサービスコンポーネントのコンポーネント取得（ａｃｑｕｉｓｉｔｉｏｎ）情報を提供することができる。Ｓ−ＴＳＩＤは、ＭＰＤのＤＡＳＨリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と当該サービスコンポーネントのｔｓｉ間のマッピングを提供することができる。Ｓ−ＴＳＩＤのコンポーネント取得情報は、ｔｓｉ、関連ＤＡＳＨリプレゼンテーションの識別子の形態で提供することができ、実施例によってＰＬＰ ＩＤを含んでも含まなくてもよい。コンポーネント取得情報を用いて、受信機は一つのサービスのオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディアセグメントのバッファリング、デコーディングなどを行うことができる。Ｓ−ＴＳＩＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。Ｓ−ＴＳＩＤの具体的な内容については後述する。
ＭＰＤは、ＳＬＳフラグメントの一つであり、当該サービスのＤＡＳＨメディアプレゼンテーションに関するデスクリプションを提供することができる。ＭＰＤは、メディアセグメントに対するリソース識別子（ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）を提供し、識別されたリソースに対するメディアプレゼンテーション内におけるコンテクスト情報を提供することができる。ＭＰＤは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（サービスコンポーネント）を記述し、またブロードバンドを介して伝達される追加的なＤＡＳＨリプレゼンテーションを記述することができる（ハイブリッドデリバリ）。ＭＰＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
ＳＬＳをＭＭＴプロトコルによって伝達する場合、ＳＬＳは、ＳＬＴが示すＭＭＴＰセッションの特定（ｄｅｄｉｃａｔｅｄ）ＭＭＴＰパケットフローで伝達することができる。実施例によって、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄは００の値を有することができる。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ及び／又はＭＭＴ Ｐａｃｋａｇｅ（ＭＰ）テーブルを含むことができる。
ここで、ＵＳＢＤは、ＳＬＳフラグメントの一つであり、ＲＯＵＴＥにおけるそれと同様にサービスの具体的な技術的情報を記述することができる。ここでのＵＳＢＤも、他のＳＬＳフラグメントへのリファレンス情報（ＵＲＩリファレンス）を含むことができる。ＭＭＴのＵＳＢＤは、ＭＭＴシグナリングのＭＰテーブルをリファレンシングすることができる。実施例によって、ＭＭＴのＵＳＢＤは、Ｓ−ＴＳＩＤ及び／又はＭＰＤへのリファレンス情報も含むことができる。ここで、Ｓ−ＴＳＩＤは、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのためのものであってもよい。ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される場合にも、ＮＲＴデータはＲＯＵＴＥプロトコルによって伝達され得るからである。ＭＰＤは、ハイブリッドサービスデリバリにおいて、ブロードバンドで伝達されるサービスコンポーネントのためのものであってもよい。ＭＭＴのＵＳＢＤの具体的な内容については後述する。
ＭＰテーブルは、ＭＰＵコンポーネントのためのＭＭＴのシグナリングメッセージであり、当該サービスのサービスコンポーネントを運搬するＭＭＴＰセッションに対する全体的なセッションデスクリプション情報を提供することができる。また、ＭＰテーブルは、このＭＭＴＰセッションを通じて伝達されるアセット（Ａｓｓｅｔ）に対するデスクリプションを含むことができる。ＭＰテーブルは、ＭＰＵコンポーネントのためのストリーミングシグナリング情報であり、一つのサービスに該当するアセットのリストとこれらのコンポーネントのロケーション情報（コンポーネント取得情報）を提供することができる。ＭＰテーブルの具体的な内容は、ＭＭＴで定義された形態であってもよく、変形された形態であってもよい。ここでいうアセットは、マルチメディアデータエンティティであり、１つのユニークＩＤで連合し、１つのマルチメディアプレゼンテーションを生成するために用いられるデータエンティティを意味することができる。アセットは、一つのサービスを構成するサービスコンポーネントに該当してもよい。ＭＰテーブルを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。ＭＰテーブルは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
その他のＭＭＴシグナリングメッセージを定義することもできる。このようなＭＭＴシグナリングメッセージによってＭＭＴＰセッション又はサービスに関連した追加の情報を記述することができる。
ＲＯＵＴＥセッションはソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッションはペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＭＭＴＰセッションはデスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフローはペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ＿ｉｄによって識別される。
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャネルと呼ぶことができる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャネルと呼ぶことができる。
図示した実施例とは違い、１つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰで伝達されてもよい。すなわち、１つのサービスは１つ以上のＰＬＰを介して伝達されてもよい。図示とは違い、実施例によって、１つのサービスを構成するコンポーネントが別個のＲＯＵＴＥセッションで伝達されてもよい。また、実施例によって、１つのサービスを構成するコンポーネントが別個のＭＭＴＰセッションで伝達されてもよい。実施例によって、１つのサービスを構成するコンポーネントがＲＯＵＴＥセッションとＭＭＴＰセッションとに分けて伝達されてもよい。図示してはいないが、１つのサービスを構成するコンポーネントがブロードバンドを介して伝達（ハイブリッドデリバリ）されてもよい。
図３は、本発明の一実施例に係るＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ Ｌｉｓｔ Ｔａｂｌｅ）を示す図である。
図示のＬＬＳテーブルの一実施例（ｔ３０１０）は、ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールド、ｐｒｏｖｉｄｅｒ＿ｉｄフィールド、ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールド及び／又はＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドによる情報を含むことができる。
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドは、当該ＬＬＳテーブルのタイプを識別し、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ＬＬＳテーブルによってシグナルされるサービスに関連したサービスプロバイダを識別することができる。ここで、サービスプロバイダは、当該ブロードキャストストリームの全部又は一部を用いるブロードキャスタであり、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ブロードキャストストリームを用いている複数のブロードキャスタのうち１つを識別することができる。ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールドは、当該ＬＬＳテーブルのバージョン情報を提供することができる。
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドの値によって、当該ＬＬＳテーブルは、前述したＳＬＴ、コンテンツアドバイザリレーティング（Ｃｏｎｔｅｎｔ ａｄｖｉｓｏｒｙ ｒａｔｉｎｇ）に関連した情報を含むＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）、システムタイムに関連した情報を提供するＳｙｓｔｅｍＴｉｍｅ情報、緊急警報に関連した情報を提供するＣＡＰ（Ｃｏｍｍｏｎ Ａｌｅｒｔ Ｐｒｏｔｏｃｏｌ）メッセージのうち１つを含むことができる。実施例によって、その他の情報がＬＬＳテーブルに含まれてもよい。
図示のＳＬＴの一実施例（ｔ３０２０）は、＠ｂｓｉｄ属性、＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性、ｓｌｔＩｎｅｔＵｒｌエレメント及び／又はＳｅｒｖｉｃｅエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｂｓｉｄ属性は、ブロードキャストストリームの識別子であってもよい。＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性は、当該ＳＬＴが記述する全てのサービスをデコードして有意に再生するために必要なキャパビリティ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、当該ＳＬＴのサービスのためのＥＳＧ又はサービスシグナリング情報をブロードバンドを介して得るために用いられるベースＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
Ｓｅｒｖｉｃｅエレメントは、当該ＳＬＴが記述するサービスに関する情報を含むエレメントであり、それぞれのサービスに対してＳｅｒｖｉｃｅエレメントが存在してもよい。Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性、＠ｐｒｏｔｅｃｔｅｄ属性、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性、＠ｈｉｄｄｅｎ属性、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性、＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性、ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメント及び／又はｓｖｃＩｎｅｔＵｒｌエレメントを含むことができる。
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性は、当該サービスに対するＳＬＴ情報のシーケンスナンバーを示すことができる。＠ｐｒｏｔｅｃｔｅｄ属性は、当該サービスの有意な再生のために必要な少なくとも１つのサービスコンポーネントが保護（ｐｒｏｔｅｃｔｅｄ）されているか否かを示すことができる。＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性と＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性はそれぞれ、当該サービスのメジャーチャネルナンバーとマイナーチャネルナンバーを示すことができる。
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性は、当該サービスのカテゴリーを示すことができる。サービスのカテゴリーとしては、リニアＡ／Ｖサービス、リニアオーディオサービス、アプリベースのサービス、ＥＳＧサービス、ＥＡＳサービスなどを挙げることができる。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性は、当該サービスの短い名（Ｓｈｏｒｔ ｎａｍｅ）を提供することができる。＠ｈｉｄｄｅｎ属性は、当該サービスがテスティング又は独占的（ｐｒｏｐｒｉｅｔａｒｙ）な使用のためのサービスであるか否かを示すことができる。＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性は、当該サービスの有意な再生のためにブロードバンドアクセスが必要であるか否かを示すことができる。＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性は、当該サービスのデコーディング及び有意な再生のために必要なキャパビリティ情報を提供することができる。
ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、当該サービスのブロードキャストシグナリングに関連した情報を提供することができる。このエレメントは、当該サービスの放送網を介したシグナリングに対して、ロケーション、プロトコル、アドレスなどの情報を提供することができる。詳細な事項は後述する。
ｓｖｃＩｎｅｔＵｒｌエレメントは、当該サービスのためのシグナリング情報をブロードバンドを介してアクセスするためのＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
前述したＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、＠ｓｌｓＰｒｏｔｏｃｏｌ属性、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＰｌｐＩｄ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、及び／又は＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性を含むことができる。
＠ｓｌｓＰｒｏｔｏｃｏｌ属性は、当該サービスのＳＬＳを伝達するために用いられるプロトコルを示すことができる（ＲＯＵＴＥ、ＭＭＴなど）。＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性はそれぞれ、当該サービスのＳＬＳを伝達するために用いられるプロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
＠ｓｌｓＰｌｐＩｄ属性は、当該サービスのＳＬＳを伝達するＰＬＰを識別するＰＬＰ識別子を提供することができる。実施例によって、このフィールドは省略されてもよく、ＳＬＳが伝達されるＰＬＰ情報は、後述するＬＭＴ内の情報とＳＬＴのブートストラップ情報とを組み合わせて確認してもよい。
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、当該サービスのＳＬＳを伝達する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート及びソースＩＰアドレスを示すことができる。これらは、ＳＬＳが伝達される伝送セッション（ＲＯＵＴＥセッション又はＭＭＴＰセッション）を識別することができる。これらはブートストラップ情報に含まれてもよい。
図４は、本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。
図示されたＵＳＢＤの一実施例（ｔ４０１０）は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性、＠ｆｕｌｌＭＰＤＵｒｉ属性、＠ｓＴＳＩＤＵｒｉ属性、ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメント及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性は、当該サービスのグローバルにユニークな（ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ）識別子であり、ＥＳＧデータとリンクされる上で用いられてもよい（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）。＠ｓｅｒｖｉｃｅＩｄ属性は、ＳＬＴの該当のサービスエントリーに対応するリファレンスであり、ＳＬＴのサービスＩＤ情報と同一であってもよい。＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性は、当該サービスの状態を示すことができる。このフィールドは、当該サービスがアクティブ状態かインアクティブ（ｉｎａｃｔｉｖｅ）状態かを示すことができる。
＠ｆｕｌｌＭＰＤＵｒｉ属性は、当該サービスのＭＰＤフラグメントをリファレンシングすることができる。ＭＰＤは、前述したように、放送網又はブロードバンドを介して伝達されるサービスコンポーネントに対する再生デスクリプションを提供することができる。＠ｓＴＳＩＤＵｒｉ属性は、当該サービスのＳ−ＴＳＩＤフラグメントをリファレンシングすることができる。Ｓ−ＴＳＩＤは、前述したように、当該サービスを運搬する伝送セッションへのアクセスに関連したパラメータを提供することができる。
ｎａｍｅエレメントは、当該サービスの名を提供することができる。このエレメントは、＠ｌａｎｇ属性をさらに含むことができるが、このフィールドは、ｎａｍｅエレメントが提供する名の言語を示すことができる。ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、当該サービスの利用可能な（ａｖａｉｌａｂｌｅ）言語を示すことができる。すなわち、このエレメントは、当該サービスを提供できる言語を羅列することができる。
ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメントは、当該サービスを有意に再生する上で必要な受信機側のキャパビリティ又はキャパビリティグループ情報を示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるキャパビリティ情報フォーマットと互換されてもよい。
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、当該サービスの放送網又はブロードバンドを介してアクセスされるコンテンツに対して、伝送関連情報を提供することができる。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及び／又はｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。このエレメントはそれぞれ、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは放送網を介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、当該サービスメディアプレゼンテーションの全てのピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、該当のメディアセグメントが放送網を介して伝達されるということを暗示することができる。
ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、該当のサービスメディアプレゼンテーションの全ピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、当該メディアセグメントがブロードバンドを介して伝達されるということを暗示することができる。
図示のＳ−ＴＳＩＤの一実施例（ｔ４０２０）は、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性及び／又はＲＳエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、ＵＳＢＤ／ＵＳＤの当該サービスをリファレンシングすることができる。ＲＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッションに関する情報を記述することができる。このようなＲＯＵＴＥセッションの個数によって、このエレメントは複数個存在してもよい。ＲＳエレメントは、＠ｂｓｉｄ属性、＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性、＠ｄｐｏｒｔ属性、＠ＰＬＰＩＤ属性及び／又はＬＳエレメントをさらに含むことができる。
＠ｂｓｉｄ属性は、当該サービスのサービスコンポーネントが伝達されるブロードキャストストリームの識別子であってもよい。このフィールドが省略された場合、デフォルトブロードキャストストリームは、当該サービスのＳＬＳを伝達するＰＬＰを含むブロードキャストストリームであってもよい。このフィールドの値は、ＳＬＴの＠ｂｓｉｄ属性と同じ値であってもよい。
＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性及び＠ｄｐｏｒｔ属性はそれぞれ、該当のＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポートを示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳＬＳを伝達する、すなわち、該当のＳ−ＴＳＩＤを伝達している現在の、ＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポート値であってもよい。現在ＲＯＵＴＥセッションでない、当該のサービスのサービスコンポーネントを伝達する他のＲＯＵＴＥセッションに対しては、本フィールドが省略されなくてもよい。
＠ＰＬＰＩＤ属性は、該当のＲＯＵＴＥセッションのＰＬＰ ＩＤ情報を示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳ−ＴＳＩＤが伝達されている現在ＰＬＰのＰＬＰ ＩＤ値であってもよい。実施例によって、このフィールドは省略され、該当のＲＯＵＴＥセッションのＰＬＰ ＩＤ情報は、後述するＬＭＴ内の情報と、ＲＳエレメントのＩＰアドレス／ＵＤＰポート情報とを組み合わせて確認してもよい。
ＬＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルに関する情報を記述することができる。このようなＬＣＴチャネルの個数によって、このエレメントは複数個存在してもよい。ＬＳエレメントは、＠ｔｓｉ属性、＠ＰＬＰＩＤ属性、＠ｂｗ属性、＠ｓｔａｒｔＴｉｍｅ属性、＠ｅｎｄＴｉｍｅ属性、ＳｒｃＦｌｏｗエレメント及び／又はＲｅｐａｉｒＦｌｏｗエレメントを含むことができる。
＠ｔｓｉ属性は、該当のＬＣＴチャネルのｔｓｉ情報を示すことができる。これによって、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルを識別することができる。＠ＰＬＰＩＤ属性は、該当のＬＣＴチャネルのＰＬＰ ＩＤ情報を示すことができる。実施例によって、このフィールドは省略されてもよい。＠ｂｗ属性は、該当のＬＣＴチャネルの最大の帯域幅を示すことができる。＠ｓｔａｒｔＴｉｍｅ属性は、該当のＬＣＴセッションのスタートタイムを示し、＠ｅｎｄＴｉｍｅ属性は、該当のＬＣＴチャネルのエンドタイムを示すことができる。
ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローについて記述することができる。ＲＯＵＴＥのソースプロトコルは、デリバリオブジェクトを伝送するために用いられ、１つのＲＯＵＴＥセッション内で少なくとも１つのソースフローを設定（ｅｓｔａｂｌｉｓｈ）することができる。これらのソースフローは、関連したオブジェクトをオブジェクトフローとして伝達することができる。
ＲｅｐａｉｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローについて記述することができる。ソースプロトコルによって伝達されるデリバリオブジェクトは、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）によって保護されてもよいが、リペアプロトコルは、このようなＦＥＣプロテクションを可能にするＦＥＣフレームワーク（ｆｒａｍｅｗｏｒｋ）を定義することができる。
図５は、本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。
図示されたＵＳＢＤの一実施例は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメント、Ｃｈａｎｎｅｌエレメント、ｍｐｕＣｏｍｐｏｎｅｎｔエレメント、ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメント、ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメント及び／又はＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント及び／又はｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントは、当該サービスのコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティングを示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるコンテンツアドバイザリレーティング情報フォーマットと互換されてもよい。Ｃｈａｎｎｅｌエレメントは、当該サービスに関連した情報を含むことができる。このエレメントの詳細な内容については後述する。
ｍｐｕＣｏｍｐｏｎｅｎｔエレメントは、当該サービスのＭＰＵとして伝達されるサービスコンポーネントに関するデスクリプションを提供することができる。このエレメントは、＠ｍｍｔＰａｃｋａｇｅＩｄ属性及び／又は＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性をさらに含むことができる。＠ｍｍｔＰａｃｋａｇｅＩｄ属性は、当該サービスのＭＰＵとして伝達されるサービスコンポーネントのＭＭＴパッケージ（Ｐａｃｋａｇｅ）をリファレンシングすることができる。＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性は、時間上、＠ｍｍｔＰａｃｋａｇｅＩｄ属性がリファレンシングするＭＭＴパッケージの次に用いられるＭＭＴパッケージをリファレンシングすることができる。このエレメントの情報を用いてＭＰテーブルをリファレンシングすることができる。
ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、ＲＯＵＴＥで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。リニアサービスコンポーネントがＭＭＴプロトコルで伝達される場合であっても、ＮＲＴデータは、前述したように、ＲＯＵＴＥプロトコルによって伝達されてもよい。このエレメントはこのようなＮＲＴデータに関する情報を記述することができる。このエレメントの詳細な内容については後述する。
ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメントは、ブロードバンドで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。ハイブリッドサービスデリバリにおいて、一つのサービスの一部のサービスコンポーネント又はその他のファイルは、ブロードバンドを介して伝達されてもよい。このエレメントは、このようなデータに関する情報を記述することができる。このエレメントは、＠ｆｕｌｌＭＰＤＵｒｉ属性をさらに含むことができる。この属性は、ブロードバンドで伝達されるサービスコンポーネントについて記述するＭＰＤをリファレンシングすることができる。ハイブリッドサービスデリバリの他にも、トンネル内の走行などによって放送信号が弱くなる場合において、放送網−ブロードバンド間のハンドオフ（ｈａｎｄｏｆｆ）を支援するためにこのエレメントが用いられてもよい。放送信号が弱くなる場合、ブロードバンドを介してサービスコンポーネントを取得するが、再び放送信号が強くなると、放送網を介してサービスコンポーネントを取得し、サービスの連続性を保障することができる。
ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、当該サービスのサービスコンポーネントに関する情報を含むことができる。サービスのサービスコンポーネントの個数によって、このエレメントは複数個存在してもよい。このエレメントは、各サービスコンポーネントのタイプ、ロール（ｒｏｌｅ）、名、識別子、プロテクションの有無などの情報を記述することができる。このエレメントの詳細な情報については後述する。
前述したＣｈａｎｎｅｌエレメントは、＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性、＠ｓｅｒｖｉｃｅＩｃｏｎ属性及び／又はＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントをさらに含むことができる。＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性は、当該サービスのジャンルを示し、＠ｓｅｒｖｉｃｅＩｃｏｎ属性は、当該サービスを代表するアイコン（ｉｃｏｎ）のＵＲＬ情報を含むことができる。ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、当該サービスのサービスデスクリプションを提供するが、このエレメントは、＠ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性及び／又は＠ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇ属性をさらに含むことができる。これらの属性はそれぞれ、当該サービスデスクリプションのテキスト及びそのテキストに用いられる言語を示すことができる。
前述したｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、＠ｓＴＳＩＤＵｒｉ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性をさらに含むことができる。
＠ｓＴＳＩＤＵｒｉ属性は、Ｓ−ＴＳＩＤフラグメントをリファレンシングすることができる。このフィールドは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。このＳ−ＴＳＩＤは、ＲＯＵＴＥで伝達されるサービスコンポーネントに対するアクセス関連情報を提供することができる。このＳ−ＴＳＩＤは、ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される状況で、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのために存在してもよい。
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、前述したＳ−ＴＳＩＤを運搬する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート、ソースＩＰアドレスを示すことができる。すなわち、これらのフィールドは、前述したＳ−ＴＳＩＤを運搬する伝送セッション（ＭＭＴＰセッション又はＲＯＵＴＥセッション）を識別することができる。
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性は、前述したＳ−ＴＳＩＤを伝達するために用いられる伝送プロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
前述したＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性、＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性、＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性、＠ｃｏｍｐｏｎｅｎｔＩｄ属性及び／又は＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性をさらに含むことができる。
＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性は、当該コンポーネントのタイプを示すことができる。例えば、この属性は、当該コンポーネントがオーディオ、ビデオ、クローズドキャプションコンポーネントのいずれであるかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性は、当該コンポーネントのロール（役割）を示すことができる。例えば、この属性は、当該コンポーネントがオーディオコンポーネントである場合、メインオーディオ、ミュージック、コメンタリなどのいずれであるかを示すことができる。該当のコンポーネントがビデオコンポーネントである場合、プライマリビデオであるかなどを示すことができる。当該コンポーネントがクローズドキャプションコンポーネントである場合、ノーマルキャプションであるか又はイージーリーダー（ｅａｓｙ ｒｅａｄｅｒ）タイプであるかなどを示すことができる。
＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性は、当該サービスコンポーネントが保護されたか、例えば暗号化されたかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＩｄ属性は、当該サービスコンポーネントの識別子を示すことができる。この属性の値は、このサービスコンポーネントに該当するＭＰテーブルのａｓｓｅｔ＿ｉｄ（アセットＩＤ）と同じ値であってもよい。＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性は、当該サービスコンポーネントの名を示すことができる。
図６は、本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ Ｌａｙｅｒ）動作を示す図である。
リンクレイヤは、フィジカルレイヤとネットワークレイヤとの間のレイヤであり得る。送信側では、ネットワークレイヤからフィジカルレイヤにデータを伝送し、受信側では、フィジカルレイヤからネットワークレイヤにデータを伝送することができる（ｔ６０１０）。リンクレイヤの目的は、フィジカルレイヤによる処理のために全入力パケットタイプを１つのフォーマットに圧縮（ａｂｓｔｒａｃｔｉｎｇ）すること、及びまだ定義されていない入力パケットタイプに対する柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）及び将来の拡張可能性を保障することにあり得る。また、リンクレイヤは、入力パケットのヘッダーの不要な情報を圧縮するオプションを提供することによって、入力データが効率的に伝送されるようにすることができる。リンクレイヤのオーバーヘッドリダクション、エンカプセレーションなどの動作は、リンクレイヤプロトコルと呼ばれ、当該プロトコルによって生成されたパケットは、リンクレイヤパケットと呼ぶことができる。リンクレイヤは、パケットエンカプセレーション（ｐａｃｋｅｔ ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を有することができる。
送信側基準で、リンクレイヤ（ＡＬＰ）は、入力パケットに対してオーバーヘッドリダクション過程を行った後、それらをリンクレイヤパケットにエンカプセレーションすることができる。また、実施例によって、リンクレイヤは、オーバーヘッドリダクション過程を行わないで、リンクレイヤパケットにエンカプセレーションしてもよい。リンクレイヤプロトコルの使用によって、フィジカルレイヤ上でデータの伝送に対するオーバーヘッドを大きく減少させることができ、本発明に係るリンクレイヤプロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ＴＳオーバーヘッドリダクションを提供することができる。
図示の、ＩＰパケットが入力パケットとして入力される場合において（ｔ６０１０）、リンクレイヤは、ＩＰヘッダー圧縮、アダプテーション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。まず、ＲｏＨＣモジュールでＩＰパケットヘッダー圧縮を行って不要なオーバーヘッドを減らし、アダプテーション過程によってコンテクスト情報を抽出し、これを帯域外で伝送することができる。ＩＰヘッダー圧縮及びアダプテーション過程を総称して、ＩＰヘッダー圧縮ということもできる。その後、エンカプセレーション過程を経てＩＰパケットをリンクレイヤパケットにエンカプセレーションすることができる。
ＭＰＥＧ２ＴＳパケットが入力パケットとして入力される場合において、リンクレイヤは、ＴＳパケットに対するオーバーヘッドリダクション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。オーバーヘッドリダクションにおいて、リンクレイヤは、シンクバイトの除去、ヌルパケットの削除及び／又は共通（ｃｏｍｍｏｎ）ヘッダー除去（圧縮）を提供することができる。シンクバイト除去によってＴＳパケット当たりに１バイトのオーバーヘッドリダクションを提供することができる。受信側で再挿入可能な方式でヌルパケットの削除を行ってもよい。また、連続したヘッダー間の共通した情報を、受信側で復旧可能な方式で削除（圧縮）してもよい。各オーバーヘッドリダクション過程の一部は省略されてもよい。その後、エンカプセレーション過程を経てＴＳパケットをリンクレイヤパケッにエンカプセレーションすることができる。ＴＳパケットのエンカプセレーションに対するリンクレイヤパケット構造は、他のタイプのパケットとは異なってもよい。
まず、ＩＰヘッダー圧縮（ＩＰ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
ＩＰパケットは、固定されたヘッダーフォーマットを有するが、通信環境で必要な一部の情報がブロードキャスト環境では不要な場合がある。リンクレイヤプロトコルは、ＩＰパケットのヘッダーを圧縮することによって、ブロードキャストオーバーヘッドを減らすメカニズムを提供することができる。
ＩＰヘッダー圧縮は、ヘッダーコンプレッサ／デコンプレッサ及び／又はアダプテーションモジュールを含むことができる。ＩＰヘッダーコンプレッサ（ＲｏＨＣコンプレッサ）は、ＲｏＨＣ方式に基づいて各ＩＰパケットヘッダーのサイズを減少させることができる。その後、アダプテーションモジュールは、コンテクスト情報を抽出し、各パケットストリームからシグナリング情報を生成することができる。受信機は、該当のパケットストリームに関連したシグナリング情報をパースし、コンテクスト情報をそのパケットストリームに付加（ａｔｔａｃｈ）することができる。ＲｏＨＣデコンプレッサは、パケットヘッダーを復旧して元来のＩＰパケットを再構成することができる。以下、ＩＰヘッダー圧縮とは、ヘッダーコンプレッサによるＩＰヘッダー圧縮のみを意味してもよく、ＩＰヘッダー圧縮とアダプテーションモジュールによるアダプテーション過程とを合わせた概念を意味してもよい。デコンプレッシング（ｄｅｃｏｍｐｒｅｓｓｉｎｇ）に対しても同様である。
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
単方向リンク上の伝送において、受信機がコンテクストの情報を有していないと、デコンプレッサは完全なコンテクストを受信するまでは、受信したパケットヘッダーを復旧することができない。これは、チャネル変更遅延及びターンオンディレー（ｔｕｒｎ−ｏｎ ｄｅｌａｙ）を招きうる。そこで、アダプテーション機能を用いて、コンプレッサ／デコンプレッサ間のコンフィギュレーションパラメータとコンテクスト情報を帯域外で伝送することができる。アダプテーションファンクション（ｆｕｎｃｔｉｏｎ）は、コンテクスト情報及び／又はコンフィギュレーションパラメータを用いてリンクレイヤシグナリングを生成（ｃｏｎｓｔｒｕｃｔｉｏｎ）することができる。アダプテーションファンクションは、以前（ｐｒｅｖｉｏｕｓ）のコンフィギュレーションパラメータ及び／又はコンテクスト情報を用いて、それぞれのフィジカルフレームを介して周期的にリンクレイヤシグナリングを伝送することができる。
圧縮されたＩＰパケットからコンテクスト情報を抽出するが、アダプテーションモードによって様々な方法を用いることができる。
モード＃１は、圧縮されたパケットストリームに対していかなる動作も行わないモードであり、アダプテーションモジュールがバッファとして動作するモードであるといえる。
モード＃２は、圧縮されたパケットストリームのうち、ＩＲパケットを検出してコンテクスト情報（スタティックチェーン）を抽出するモードであってもよい。抽出の後、ＩＲパケットはＩＲ−ＤＹＮパケットに変換され、ＩＲ−ＤＹＮパケットを元来のＩＲパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
モード＃３（ｔ６０２０）は、圧縮されたパケットストリームのうち、ＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテクスト情報を抽出するモードであってもよい。ＩＲパケットからスタティックチェーン及びダイナミックチェーンを、ＩＲ−ＤＹＮパケットからダイナミックチェーンを抽出することができる。抽出の後、ＩＲ及びＩＲ−ＤＹＮパケットを一般圧縮パケットに変換することができる。変換されたパケットを、元来のＩＲ及びＩＲ−ＤＹＮパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
各モードで、コンテクスト情報を抽出して残ったパケットは、圧縮されたＩＰパケットのためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。コンテクスト情報は、リンクレイヤシグナリングであり、シグナリング情報のためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。
抽出されたコンテクスト情報は、ＲＤＴ（ＲｏＨＣ−Ｕ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）に含めてＲｏＨＣパケットフローとは別に伝送することができる。コンテクスト情報は、他のシグナリング情報と共に特定（ｓｐｅｃｉｆｉｃ）フィジカルデータ経路で伝送することができる。特定フィジカルデータ経路とは、実施例によって、一般ＰＬＰのうちの一つを意味することもでき、ＬＬＳ（Ｌｏｗ Ｌｅｖｅｌ Ｓｉｇｎａｌｉｎｇ）が伝達されるＰＬＰを意味することもでき、指定された（ｄｅｄｉｃａｔｅｄ）ＰＬＰであってもよく、Ｌ１シグナリングパス（ｐａｔｈ）を意味することもできる。ここで、ＲＤＴは、コンテクスト情報（スタティックチェーン及び／又はダイナミックチェーン）及び／又はヘッダーコンプレッションに関連した情報を含むシグナリング情報であってもよい。実施例によって、ＲＤＴは、コンテクスト情報が変わる度に伝送されてもよい。また、実施例によって、ＲＤＴは、毎フィジカルフレームで伝送されてもよい。毎フィジカルフレームでＲＤＴを伝送するために、以前（ｐｒｅｖｉｏｕｓ）のＲＤＴが再利用（ｒｅ−ｕｓｅ）され得る。
受信機はパケットストリームを取得する前に、最初のＰＬＰを選択してＳＬＴ、ＲＤＴ、ＬＭＴなどのシグナリング情報をまず取得することができる。受信機は、このシグナリング情報が取得されると、これらを組み合わせてサービス−ＩＰ情報−コンテクスト情報−ＰＬＰ間のマッピングを取得することができる。すなわち、受信機は、どのようなサービスがどのＩＰストリームで伝送されるのか、どのようなＰＬＰでどのようなＩＰストリームが伝達されるのか、などを知ることができ、また、ＰＬＰの当該コンテクスト情報を取得することができる。受信機は、特定のパケットストリームを運搬するＰＬＰを選択してデコードすることができる。アダプテーションモジュールは、コンテクスト情報をパースし、これを圧縮されたパケットと組み合わせることができる。これによってパケットストリームを復旧することができ、これをＲｏＨＣデコンプレッサに伝達することができる。その後、デコンプレッションを始まることができる。このとき、受信機は、アダプテーションモードに応じて、ＩＲパケットをディテクトして、最初に受信されたＩＲパケットからデコンプレッションを開始したり（モード１）、ＩＲ−ＤＹＮパケットをディテクトして、最初に受信されたＩＲ−ＤＹＮパケットからデコンプレッションを開始したり（モード２）、どの一般の圧縮パケット（ｃｏｍｐｒｅｓｓｅｄ ｐａｃｋｅｔ）からデコンプレッションを開始してもよい（モード３）。
以下、パケットエンカプセレーションについて説明する。
リンクレイヤプロトコルは、ＩＰパケット、ＴＳパケットなどの全てのタイプのインプットパケットをリンクレイヤパケットにエンカプセレーションすることができる。これによって、フィジカルレイヤは、ネットワークレイヤのプロトコルタイプとは独立して１つのパケットフォーマットだけを処理すればいい（ここでは、ネットワークレイヤパケットの一種としてＭＰＥＧ−２ＴＳパケットを考慮）。各ネットワークレイヤパケット又は入力パケットは、ゼネリックリンクレイヤパケットのペイロードに変形される。
パケットエンカプセレーション過程では分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤパケットが大きすぎてフィジカルレイヤで処理できない場合、ネットワークレイヤパケットを２つ以上のセグメントに分割することができる。リンクレイヤパケットヘッダーは、送信側で分割を実行し、受信側で再結合を実行するためのフィールドを含むことができる。各セグメントを、元来の位置と同じ順序でリンクレイヤパケットにエンカプセレーションすることができる。
パケットエンカプセレーション過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）を活用することもできる。リンクレイヤパケットのペイロードが複数のネットワークレイヤパケットを含む程度にネットワークレイヤパケットが十分に小さい場合、連鎖を行ってもよい。リンクレイヤパケットヘッダーは、連鎖を実行するためのフィールドを含むことができる。連鎖の場合、各入力パケットを、元来の入力順序と同じ順序でリンクレイヤパケットのペイロードにエンカプセレーションすることができる。
リンクレイヤパケットは、ヘッダー及びペイロードを含むことができ、ヘッダーは、ベースヘッダー、追加（ａｄｄｉｔｉｏｎａｌ）ヘッダー及び／又はオプショナルヘッダーを含むことができる。追加ヘッダーは、連鎖又は分割などの状況によってさらに追加することができるが、追加ヘッダーには状況に応じて、必要なフィールドを含めることができる。また、追加的な情報の伝達のためにオプショナルヘッダーをさらに追加することもできる。それぞれのヘッダー構造は既に定義されていてもよい。前述したように、入力パケットがＴＳパケットである場合には、他のパケットとは異なるリンクレイヤヘッダー構造を用いることができる。
以下、リンクレイヤシグナリングについて説明する。
リンクレイヤシグナリングは、ＩＰレイヤよりも下位レベルで動作することができる。受信側では、ＬＬＳ、ＳＬＴ、ＳＬＳなどのＩＰレベルシグナリングよりもリンクレイヤシグナリングを先に取得することができる。このため、リンクレイヤシグナリングをセッション設定（ｅｓｔａｂｌｉｓｈｍｅｎｔ）の前に取得することができる。
リンクレイヤシグナリングには、インターナルリンクレイヤシグナリングとエクスターナルリンクレイヤシグナリングがあり得る。インターナルリンクレイヤシグナリングは、リンクレイヤで生成されたシグナリング情報を意味することができる。前述したＲＤＴ又は後述するＬＭＴなどがこれに当たる。エクスターナルリンクレイヤシグナリングは、外部のモジュール又は外部のプロトコル、上位レイヤから伝達されたシグナリング情報であってもよい。リンクレイヤは、リンクレイヤシグナリングをリンクレイヤパケットにエンカプセレーションして伝達することができる。リンクレイヤシグナリングのためのリンクレイヤパケット構造（ヘッダー構造）を定義することができ、この構造によって、リンクレイヤシグナリング情報をエンカプセレーションすることができる。
図７は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）を示す図である。
ＬＭＴは、ＰＬＰで運搬される上位レイヤセッションのリストを提供することができる。また、ＬＭＴは、上位レイヤセッションを伝達するリンクレイヤパケットをプロセシングするための追加的な情報を提供することができる。ここで、上位レイヤセッションは、マルチキャスト（ｍｕｌｔｉｃａｓｔ）と呼ぶこともできる。ＬＭＴから、特定のＰＬＰを介していかなるＩＰストリーム、いかなる伝送セッションが伝送されているかに関する情報を取得することができる。逆に、特定の伝送セッションがどのＰＬＰで伝達されるかに関する情報も取得することができる。
ＬＭＴは、ＬＬＳを運搬するものと識別されたいかなるＰＬＰでも伝達可能である。ここで、ＬＬＳが伝達されるＰＬＰは、フィジカルレイヤのＬ１ディテールシグナリング情報のＬＬＳフラグによって識別され得る。ＬＬＳフラグは、それぞれのＰＬＰに対して、当該ＰＬＰでＬＬＳが伝達されるか否かを示すフラグフィールドであってもよい。ここで、Ｌ１ディテールシグナリング情報は、後述するＰＬＳ２データに該当してもよい。
すなわち、ＬＭＴは、ＬＬＳと共に、同じＰＬＰで伝達され得る。それぞれのＬＭＴは、前述したように、ＰＬＰとＩＰアドレス／ポートとの間のマッピングを記述することができる。前述したように、ＬＬＳはＳＬＴを含むことができ、ＬＭＴが記述するこのＩＰアドレス／ポートは、当該ＬＭＴと同じＰＬＰで伝達されるＳＬＴが記述する、あらゆる（ａｎｙ）サービスと関連するあらゆる（ａｎｙ）ＩＰアドレス／ポートであってもよい。
実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報を用いて、ＳＬＴ、ＳＬＳが示す特定伝送セッションがどのＰＬＰで伝送されているかに関する情報を確認することができる。
他の実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報は省略され、ＳＬＴ、ＳＬＳが示す特定伝送セッションに対するＰＬＰ情報は、ＬＭＴ内の情報を参照することによって確認することもできる。この場合、受信機は、ＬＭＴと他のＩＰレベルシグナリング情報とを組み合わせて、所望のＰＬＰを識別することができる。この実施例においても、ＳＬＴ、ＳＬＳ等におけるＰＬＰ情報は省略されず、ＳＬＴ、ＳＬＳ等に残っていてもよい。
同図の実施例に係るＬＭＴは、ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールド、ＰＬＰ＿ＩＤフィールド、ｎｕｍ＿ｓｅｓｓｉｏｎフィールド及び／又はそれぞれのセッションに関する情報を含むことができる。同図の実施例のＬＭＴは、１つのＰＬＰに対して、そのＰＬＰで伝送されるＩＰストリームを記述しているが、実施例によって、ＬＭＴにＰＬＰループを追加し、複数個のＰＬＰに関する情報を記述してもよい。この場合、ＬＭＴは、前述したように、共に伝達されるＳＬＴが記述するあらゆるサービスと関連するあらゆるＩＰアドレス／ポートに対するＰＬＰを、ＰＬＰループに記述することができる。
ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドは、当該テーブルによって伝達されるシグナリング情報のタイプを示すことができる。ＬＭＴに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は、０ｘ０１に設定することができる。ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドは省略されてもよい。ＰＬＰ＿ＩＤフィールドは、記述しようとする対象ＰＬＰを識別することができる。ＰＬＰループが用いられる場合、それぞれのＰＬＰ＿ＩＤフィールドは、それぞれの対象ＰＬＰを識別することができる。ＰＬＰ＿ＩＤフィールドからはＰＬＰループ内に含まれてもよい。後述するＰＬＰ＿ＩＤフィールドは、ＰＬＰループにおける一つのＰＬＰに対する識別子であり、以下で説明するフィールドは、その当該ＰＬＰに対するフィールドであってもよい。
ｎｕｍ＿ｓｅｓｓｉｏｎフィールドは、当該ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションの個数を示すことができる。ｎｕｍ＿ｓｅｓｓｉｏｎフィールドが示す個数によって、各セッションに関する情報が含まれてもよい。この情報は、ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド、ｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＩＤ＿ｆｌａｇフィールド、ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールド、ＳＩＤフィールド及び／又はｃｏｎｔｅｘｔ＿ｉｄフィールドを含むことができる。
ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド及びｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションのうち、当該伝送セッションに対するソースＩＰアドレス、デスティネーションＩＰアドレス、ソースＵＤＰポート、デスティネーションＵＤＰポートを示すことができる。
ＳＩＤ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示すことができる。上位レイヤセッションを伝達するリンクレイヤパケットは、そのオプショナルヘッダーにＳＩＤフィールドを有することができ、そのＳＩＤフィールドの値は後述するＬＭＴ内のＳＩＤフィールドと同一であってもよい。
ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットのデータにヘッダーコンプレッションが適用されたか否かを示すことができる。また、本フィールドの値によって、後述するｃｏｎｔｅｘｔ＿ｉｄフィールドの存否が決定されてもよい。ヘッダーコンプレッションが適用された場合（ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇ＝１）、ＲＤＴが存在し得、そのＲＤＴのＰＬＰ ＩＤフィールドは、本ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールドに関連する当該ＰＬＰ＿ＩＤフィールドと同じ値を有することができる。
ＳＩＤフィールドは、当該伝送セッションを伝達するリンクレイヤパケットに対するＳＩＤ（ｓｕｂ ｓｔｒｅａｍ ＩＤ）を示すことができる。このリンクレイヤパケットは、そのオプショナルヘッダーに本ＳＩＤフィールドと同一の値を有するＳＩＤを含んでいてもよい。これを通じて、受信機は、リンクレイヤパケットを全部パーシングする必要がなく、ＬＭＴの情報及びリンクレイヤパケットヘッダーのＳＩＤ情報を用いて、リンクレイヤパケットをフィルタリングすることができる。
ｃｏｎｔｅｘｔ＿ｉｄフィールドは、ＲＤＴ内のＣＩＤ（ｃｏｎｔｅｘｔ ｉｄ）に対するリファレンスを提供することができる。ＲＤＴのＣＩＤ情報は、該当する圧縮ＩＰパケットストリームに対するコンテクストＩＤを示すことができる。ＲＤＴは、該当する圧縮ＩＰパケットストリームに対するコンテクスト情報を提供することができる。本フィールドによってＲＤＴとＬＭＴとが関連付けられてもよい。
前述した、本発明のシグナリング情報／テーブルの実施例において、それぞれのフィールド、エレメント、属性を省略したり他のフィールドに置き換えてもよく、実施例によって、更なるフィールド、エレメント、属性を追加してもよい。
本発明の一実施例で、一つのサービスのサービスコンポーネントを複数個のＲＯＵＴＥセッションで伝達することができる。この場合、ＳＬＴのブートストラップ情報を用いてＳＬＳを取得することができる。このＳＬＳのＵＳＢＤを用いてＳ−ＴＳＩＤとＭＰＤをリファレンシングすることができる。Ｓ−ＴＳＩＤは、ＳＬＳを伝達しているＲＯＵＴＥセッションだけでなく、サービスコンポーネントを伝達している他のＲＯＵＴＥセッションに対する伝送セッションデスクリプション情報も記述することができる。これによって、複数個のＲＯＵＴＥセッションで伝達されるサービスコンポーネントを全て収集することができる。このような事項は、一つのサービスのサービスコンポーネントが複数個のＭＭＴＰセッションで伝達される場合にも同様に適用することができる。参考として、１つのサービスコンポーネントが複数個のサービスによって同時に用いられてもよい。
本発明の他の実施例で、ＥＳＧサービスに対するブートストラピングは放送網又はブロードバンドで行われてもよい。ブロードバンドを介してＥＳＧを取得し、ＳＬＴのＵＲＬ情報を活用することができる。このＵＲＬにＥＳＧ情報などを要求することができる。
本発明の他の実施例で、一つのサービスのいずれか一つのサービスコンポーネントは放送網で、いずれか他のサービスコンポーネントはブロードバンドで伝達することができる（ハイブリッド）。Ｓ−ＴＳＩＤは、放送網で伝達されるコンポーネントについて記述して、ＲＯＵＴＥクライアントが所望のサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、ベースパターン情報を有しており、どのセグメントが（どのコンポーネントが）どの経路で伝達されるかを記述することができる。したがって、受信機は、これを用いて、ブロードバンドサーバーに要求すべきセグメント、及び放送ストリームから見つけるべきセグメントを識別することができる。
本発明の他の実施例で、サービスに対するスケーラブル（ｓｃａｌａｂｌｅ）コーディングを行うこともできる。ＵＳＢＤは、当該サービスをレンダリングするために必要な全てのキャパビリティ情報を有することができる。例えば、一つのサービスがＨＤ又はＵＨＤで提供される場合、ＵＳＢＤのキャパビリティ情報は、“ＨＤ又はＵＨＤ”値を有することができる。受信機は、ＭＰＤから、ＵＨＤ又はＨＤサービスをレンダリングするためにはどのコンポーネントを再生しなければならないかが分かる。
本発明の他の実施例で、ＳＬＳを伝達するＬＣＴチャネルで伝達されるＬＣＴパケットのＴＯＩフィールドから、当該ＬＣＴパケットがどのＳＬＳフラグメントを伝達しているか（ＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなど）を識別することができる。
本発明の他の実施例で、アプリベースのエンハンスメント／アプリベースのサービスに用いられるアプリコンポーネントを、ＮＲＴコンポーネントとして放送網で伝達されたり、又はブロードバンドで伝達してもよい。また、アプリベースのエンハンスメントに対するアプリシグナリングは、ＳＬＳと共に伝達されるＡＳＴ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｔａｂｌｅ）によって行われてもよい。また、アプリが行う動作に対するシグナリングであるイベントは、ＳＬＳと共にＥＭＴ（Ｅｖｅｎｔ Ｍｅｓｓａｇｅ Ｔａｂｌｅ）の形態で伝達されたり、ＭＰＤ内にシグナルされたり、ＤＡＳＨリプレゼンテーション内にｂｏｘ形態でインバンド（ｉｎ−ｂａｎｄ）シグナルされてもよい。ＡＳＴ、ＥＭＴなどはブロードバンドを介して伝達されてもよい。収集されたアプリコンポーネントとこのようなシグナリング情報を用いてアプリベースのエンハンスメントなどを提供することができる。
本発明の他の実施例で、緊急警報のためにＣＡＰメッセージを前述のＬＳテーブルに含めて提供することができる。緊急警報のためのリーチメディア（Ｒｉｃｈ Ｍｅｄｉａ）コンテンツも提供することができる。リーチメディアは、ＣＡＰメッセージによってシグナルすることができ、リーチメディアが存在する場合、これは、ＳＬＴによってシグナルされるＥＡＳサービスとして提供することができる。
本発明の他の実施例で、ＭＭＴプロトコルによってリニアサービスコンポーネントを放送網を介して伝達することができる。この場合、当該サービスに対するＮＲＴデータ（例えば、アプリコンポーネント）をＲＯＵＴＥプロトコルによって放送網で伝達することができる。また、当該サービスに対するデータをブロードバンドで伝達することができる。受信機は、ＳＬＴのブートストラップ情報を用いてＳＬＳを伝達するＭＭＴＰセッションに接近することができる。ＭＭＴによるＳＬＳのＵＳＢＤは、ＭＰテーブルをリファレンシングして、受信機がＭＭＴプロトコルによって伝達されるＭＰＵにフォーマットされたリニアサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、Ｓ−ＴＳＩＤをさらにリファレンシングして、受信機がＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータを取得するようにしてもよい。また、ＵＳＢＤは、ＭＰＤをさらにリファレンシングして、ブロードバンドを介して伝達されるデータに対する再生デスクリプションを提供することができる。
本発明の他の実施例で、受信機はそのコンパニオンデバイスに、ストリーミングコンポーネント及び／又はファイルコンテンツアイテム（ファイルなど）を取得できるロケーションＵＲＬ情報を、ウェブソケットなどの方法で伝達することができる。コンパニオンデバイスのアプリケーションはこのＵＲＬにＨＴＴＰ ＧＥＴなどを用いて要求して該当のコンポーネント、データなどを取得することができる。その他にも、受信機はシステムタイム情報、緊急警報情報などの情報をコンパニオンデバイス側に伝達することができる。
図８は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ Ｆｏｒｍａｔ ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ ｉｎｔｅｒｌｅａｖｅｄ ｃｏｄｉｎｇ ＆ ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ ｂｕｉｌｄｉｎｇ ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック（ＯＦＤＭ ｇｅｎｅｒａｔｉｏｎ ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
本発明の一実施例に係る入力データは、ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳが主な入力フォーマットであり得、他のストリームタイプは一般ストリームとして扱われる。
インプットフォーマットブロック１０００は、それぞれの入力ストリームを独立したコーディング及び変調が適用される１つ又は多数のデータパイプに逆多重化することができる。データパイプは、ロバスト性（ｒｏｂｕｓｔｎｅｓｓ）の制御のための基本単位であり、これは、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に影響を及ぼす。１つ又は多数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。データパイプは、１つ又は多数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）での論理チャネルである。
ＱｏＳが、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するため、それぞれのサービスに該当するデータは、互いに異なる方式を用いて処理されなければならない。
ＢＩＣＭブロック１０１０は、ＭＩＭＯが適用されないプロファイル（又はシステム）に適用される処理ブロック、及び／又はＭＩＭＯが適用されるプロファイル（又はシステム）の処理ブロックを含むことができ、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロックは、データＦＥＣエンコーダ、ビットインタリーバ、コンステレーションマッパー（ｍａｐｐｅｒ）、ＳＳＤ（ｓｉｇｎａｌ ｓｐａｃｅ ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック、及びタイムインタリーバを含むことができる。ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロックは、セルワードデマルチプレクサ及びＭＩＭＯエンコーディングブロックをさらに含むという点で、ＭＩＭＯが適用されないＢＩＣＭの処理ブロックと区別される。
データＦＥＣエンコーダは、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。ビットインタリーバは、データＦＥＣエンコーダの出力をインタリーブして、ＬＤＰＣコード及び変調方式の組み合わせにより最適化された性能を達成することができる。コンステレーションマッパーは、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いて、ビットインタリーバ又はセルワードデマルチプレクサからのセルワードを変調して、電力が正規化されたコンステレーションポイントを提供することができる。ＮＵＱが任意の形状を有する反面、ＱＡＭ−１６及びＮＵＱは正方形の形状を有することが観察される。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ ｒａｔｅ）に対して特別に定義され、ＰＬＳ２データのパラメータＤＰ＿ＭＯＤによってシグナリングされる。タイムインタリーバは、データパイプレベルで動作することができる。タイムインタリービングのパラメータは、それぞれのデータパイプに対して異ならせて設定されてもよい。
本発明のタイムインタリーバは、ＢＩＣＭチェーン（ＢＩＣＭ ｃｈａｉｎ）ブロックとフレームビルダー（Ｆｒａｍｅ Ｂｕｉｌｄｅｒ）との間に位置し得る。この場合、本発明のタイムインタリーバは、ＰＬＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｐｉｐｅ）モードに応じて、コンボリューションインタリーバ（Ｃｏｎｖｏｌｕｔｉｏｎ Ｉｎｔｅｒｌｅａｖｅｒ、ＣＩ）とブロックインタリーバ（Ｂｌｏｃｋ Ｉｎｔｅｒｌｅａｖｅｒ、ＢＩ）を選択的に使用してもよく、両方とも使用してもよい。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使用されるフィジカルパス（ｐｈｙｓｉｃａｌ ｐａｔｈ）であって、呼称は設計者の意図によって変更可能である。本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰの個数に応じて、シングルＰＬＰ（ｓｉｎｇｌｅ ＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅ ＰＬＰ）モードを含むことができる。本発明では、ＰＬＰモードに応じて互いに異なるタイムインタリービング方法を適用するタイムインタリービングを、ハイブリッドタイムインタリービング（Ｈｙｂｒｉｄ Ｔｉｍｅ Ｉｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。
ハイブリッドタイムインタリーバは、ブロックインタリーバ（ＢＩ）及びコンボリューションインタリーバ（ＣＩ）を含むことができる。ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインタリーバは適用されず（ブロックインタリーバオフ（ｏｆｆ））、コンボリューションインタリーバのみが適用される。ＰＬＰ＿ＮＵＭ＞１である場合、ブロックインタリーバ及びコンボリューションインタリーバが両方とも適用（ブロックインタリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１である場合に適用されるコンボリューションインタリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１である場合に適用されるコンボリューションインタリーバの構造及び動作と異なってもよい。ハイブリッドタイムデインターリーバは、上述したハイブリッドタイムインタリーバの逆動作に相応する動作を行うことができる。
セルワードデマルチプレクサは、ＭＩＭＯ処理のために、単一のセルワードストリームを二重セルワードストリームに分離するのに用いられる。ＭＩＭＯエンコーディングブロックは、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサの出力を処理することができる。本発明のＭＩＭＯエンコーディング方式は、受信機側での比較的小さい複雑度の増加で容量増加を提供するためのＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ ｓｐａｔｉａｌ ｍｕｌｔｉｐｌｅｘｉｎｇ）として定義できる。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ１，ｉ及びｅ２，ｉ）は、ＭＩＭＯエンコーダの入力として供給されると、ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ１，ｉ及びｇ２，ｉ）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって伝送される。
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングし、周波数領域ダイバーシチのために周波数インタリービングを行うことができる。
本発明の一実施例に係るフレームは、プリアンブル、１つ以上のＦＳＳ（ｆｒａｍｅ ｓｉｇｎａｌｉｎｇ ｓｙｍｂｏｌ）、ノーマルデータシンボルに分離される。プリアンブルは、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルは、フレームの基本伝送パラメータ及び伝送タイプをシグナリングすることができる。特に、プリアンブルは、ＥＡＳ（ｅｍｅｒｇｅｎｃｙ ａｌｅｒｔ ｓｅｒｖｉｃｅ）が現フレームに提供されるか否かを示すことができる。ＦＳＳの主な目的はＰＬＳデータを伝達することである。高速同期化及びチャネル推定、ＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルよりも高密度のパイロットパターンを有する。
フレームビルディングブロックは、データパイプと該当するＰＬＳデータとの間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（ｃｏ−ｔｉｍｅ）を保障するためのディレイコンペンセーション（ｄｅｌａｙ ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロック、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどをフレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングするためのセルマッパー（ｃｅｌｌ ｍａｐｐｅｒ）、及び周波数インタリーバ（ｆｒｅｑｕｅｎｃｙ ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。
周波数インタリーバは、セルマッパーから受信されたデータセルをランダムにインタリーブして周波数ダイバーシチを提供することができる。また、周波数インタリーバは、単一のフレームで最大のインタリービング利得を得るために、異なるインタリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）に対応するデータ又は一つのＯＦＤＭシンボルに対応するデータに対して動作することができる。
ＯＦＤＭ生成ブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）シグナリング情報を生成することができる。本発明の一実施例に係るシグナリング情報はＰＬＳデータを含むことができる。ＰＬＳは、受信機で物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
ＰＬＳ１データは、ＰＬＳ２データをデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームにおいてＦＳＳで伝達されるＰＬＳデータの１番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするのに要求されるパラメータを含む基本送信パラメータを提供する。ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達し、ＦＳＳで伝送されるＰＬＳデータの２番目の集合である。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ（ＰＬＳ２−ＳＴＡＴデータ）、及びＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データは、フレームグループのデュレーションの間にスタティック（ｓｔａｔｉｃ、静的）なＰＬＳ２データであり、ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データは、フレーム毎にダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データである。
ＰＬＳ２データはＦＩＣ＿ＦＬＡＧ情報を含むことができる。ＦＩＣ（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）は、速いサービス取得及びチャネルスキャン（ｆａｓｔ ｓｅｒｖｉｃｅ ａｃｑｕｉｓｉｔｉｏｎ ａｎｄ ｃｈａｎｎｅｌ ｓｃａｎｎｉｎｇ）を可能にするクロスレイヤ（ｃｒｏｓｓ−ｌａｙｅｒ）情報を伝送するための専用チャネル（ｄｅｄｉｃａｔｅｄ ｃｈａｎｎｅｌ）である。ＦＩＣ＿ＦＬＡＧ情報は、１ビットのフィールドであって、ＦＩＣ（ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ、高速情報チャネル）が現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。ＢＩＣＭブロック１０１０は、ＰＬＳデータの保護のためのＢＩＣＭブロックを含むことができる。ＰＬＳデータの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ、ビットインタリーバ、及びコンステレーションマッパーを含むことができる。
ＰＬＳ ＦＥＣエンコーダは、ＰＬＳ１データ及びＰＬＳ２データをスクランブルするためのスクランブラ、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いてスクランブルされたＰＬＳ１，２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入するためのＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣコードを用いてエンコーディングを行うためのＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットがＬＤＰＣエンコーディングの前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）され得る。ビットインタリーバは、それぞれのショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインタリーブし、コンステレーションマッパーは、ビットインタリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図８を参照して説明した次世代放送サービスに対する放送信号送信装置の逆過程を行うことができる。
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、放送信号送信装置によって行われる手順の逆過程に該当する復調を行う同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ＆ ｄｅｍｏｄｕｌａｔｉｏｎ ｍｏｄｕｌｅ）、入力信号フレームをパーシングし、ユーザによって選択されたサービスが伝送されるデータを抽出するフレームパーシングモジュール（ｆｒａｍｅ ｐａｒｓｉｎｇ ｍｏｄｕｌｅ）、入力信号をビット領域データに変換した後、必要によってビット領域データをデインタリーブし、伝送効率のために適用されたマッピングに対するデマッピングを行い、デコーディングを介して伝送チャネルで発生した誤りを訂正するデマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ ＆ ｄｅｃｏｄｉｎｇ ｍｏｄｕｌｅ）、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆過程を行う出力プロセッサ（ｏｕｔｐｕｔ ｐｒｏｃｅｓｓｏｒ）、及び同期及び復調モジュールによって復調された信号からＰＬＳ情報を取得、処理するシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ ｄｅｃｏｄｉｎｇ ｍｏｄｕｌｅ）を含むことができる。フレームパーシングモジュール、デマッピング及びデコーディングモジュール、及び出力プロセッサは、シグナリングデコーディングモジュールから出力されたＰＬＳデータを用いてその機能を実行することができる。
以下、タイムインタリーバを説明する。本発明の一実施例に係るタイムインタリービンググループは、一つのフレームに直接マッピングされるか、またはＰＩ個のフレームにわたって拡散される。また、それぞれのタイムインタリービンググループは、一つ以上（ＮＴＩ個）のタイムインタリービングブロックに分離される。ここで、それぞれのタイムインタリービングブロックは、タイムインタリーバメモリの一つの使用に該当する。タイムインタリービンググループ内のタイムインタリービングブロックは、互いに異なる個数のＸＦＥＣＢＬＯＣＫを含むことができる。一般に、タイムインタリーバは、フレーム生成過程の前にデータパイプデータに対するバッファとしても機能することができる。
本発明の一実施例に係るタイムインタリーバは、ツイストされた行−列ブロックインタリーバである。本発明の一実施例に係るツイストされた行−列ブロックインタリーバは、１番目のＸＦＥＣＢＬＯＣＫをタイムインタリービングメモリの１番目の列に列方向に書き込み、２番目のＸＦＥＣＢＬＯＣＫは、次の列に書き込み、同じ方式でタイムインタリービングブロック内の残りのＸＦＥＣＢＬＯＣＫを書き込むことができる。そして、インタリービングアレイにおいて、セルは、１番目の行から（最も左側の列から始まって行に沿って右側に）最後の行まで対角線方向に読み取られ得る。この場合、タイムインタリービングブロック内のＸＦＥＣＢＬＯＣＫの個数に関係なく受信機側で単一のメモリデインタリービングを達成するために、ツイストされた行−列ブロックインタリーバ用インタリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインタリービングメモリに挿入することができる。この場合、受信機側で単一のメモリデインタリービングを達成するために、仮想ＸＦＥＣＢＬＯＣＫは、他のＸＦＥＣＢＬＯＣＫの最も前に挿入されなければならない。
図９は、本発明の一実施例に係るタイムインタリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す。
図中の左側に示されたブロックはＴＩメモリアドレスアレイ（ｍｅｍｏｒｙ ａｄｄｒｅｓｓ ａｒｒａｙ）を示し、図中の右側に示されたブロックは、連続した２つのＴＩグループに対して、それぞれ仮想（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最も前にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）動作を示す。
本発明の一実施例に係る周波数インタリーバは、シンボルペアに対応するデータに適用するためのインタリービングアドレスを生成するためのインタリービングアドレス生成器を含むことができる。
図１０は、本発明の一実施例に係る周波数インタリーバに含まれた各ＦＦＴモードによるメインＰＲＢＳ生成器とサブＰＲＢＳ生成器で構成されたインタリービングアドレス生成器のブロックダイヤグラムを示す図である。
（ａ）は、８Ｋ ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示し、（ｂ）は、１６Ｋ ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示し、（ｃ）は、３２Ｋ ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示す。
ＯＦＤＭシンボルペアに対するインタリービング過程は、一つのインタリービングシーケンスを用い、次のように説明される。まず、一つのＯＦＤＭシンボルＯｍ，ｌでインタリーブされる利用可能なデータセル（セルマッパーからの出力セル）は、ｌ＝０，…，Ｎｓｙｍ−１に対してＯｍ，ｌ＝［ｘｍ，ｌ，０，…，ｘｍ，ｌ，ｐ，…，ｘｍ，ｌ，Ｎｄａｔａ−１］として定義される。このとき、ｘｍ，ｌ，ｐは、ｍ番目のフレームでｌ番目のＯＦＤＭシンボルのｐ番目のセルであり、Ｎｄａｔａは、データセルの個数である。フレームシグナリングシンボルに対してＮｄａｔａ＝ＣＦＳＳであり、ノーマルデータに対してＮｄａｔａ＝Ｃｄａｔａであり、フレームエッジシンボルに対してＮｄａｔａ＝ＣＦＥＳである。また、インタリーブされたデータセルは、ｌ＝０，…，Ｎｓｙｍ−１に対してＰｍ，ｌ＝［ｖｍ，ｌ，０，…，ｖｍ，ｌ，Ｎｄａｔａ−１］として定義される。
ＯＦＤＭシンボルペアに対して、インタリーブされたＯＦＤＭシンボルペアは、各ペアの１番目のＯＦＤＭシンボルに対してｖｍ，ｌ，Ｈｉ（ｐ）＝ｘｍ，ｌ，ｐ，ｐ＝０，…，Ｎｄａｔａ−１として与えられ、各ペアの２番目のＯＦＤＭシンボルに対してｖｍ，ｌ，ｐ＝ｘｍ，ｌ，Ｈｉ（ｐ），ｐ＝０，…，Ｎｄａｔａ−１として与えられる。このとき、Ｈｌ（ｐ）は、ＰＲＢＳ生成器及びサブＰＲＢＳ生成器の巡回シフト値（シンボルオフセット）に基づいて生成されたインタリービングアドレスである。
図１１は、本発明の一実施例に係るハイブリッド放送受信装置を示す図である。
ハイブリッド放送システムは、地上波放送網及びインターネット網を連動して放送信号を送信することができる。ハイブリッド放送受信装置は、地上波放送網（ブロードキャスト）及びインターネット網（ブロードバンド）を介して放送信号を受信することができる。ハイブリッド放送受信装置は、フィジカルレイヤモジュール、フィジカルレイヤＩ／Ｆモジュール、サービス／コンテンツ取得コントローラ、インターネットアクセス制御モジュール、シグナリングデコーダ、サービスシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、警報信号マネジャー、警報信号パーサー、ターゲッティング信号パーサー、ストリーミングメディアエンジン、非リアルタイムファイルプロセッサ、コンポーネントシンクロナイザ、ターゲッティングプロセッサ、アプリケーションプロセッサ、Ａ／Ｖプロセッサ、デバイスマネジャー、データシェアリング及びコミュニケーションユニット、再分配モジュール、コンパニオンデバイス及び／又は外部モジュールを含むことができる。
フィジカルレイヤモジュール（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｍｏｄｕｌｅ（ｓ））は、地上波放送チャネルを介して放送関連信号を受信及び処理し、これを適切な形態に変換してフィジカルレイヤＩ／Ｆモジュールに伝達することができる。
フィジカルレイヤＩ／Ｆモジュール（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｉ／Ｆ Ｍｏｄｕｌｅ（ｓ））は、フィジカルレイヤモジュールから取得した情報からＩＰデータグラムを取得することができる。また、フィジカルレイヤＩ／Ｆモジュールは、取得されたＩＰデータグラムなどを特定のフレーム（例えば、ＲＳ Ｆｒａｍｅ、ＧＳＥなど）に変換することができる。
サービス／コンテンツ取得コントローラ（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ Ａｃｑｕｉｓｉｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）は、ブロードキャスト（ｂｒｏａｄｃａｓｔ）及び／又はブロードバンド（ｂｒｏａｄｂａｎｄ）チャネルを介したサービス、コンテンツ及びこれに関連するシグナリングデータの取得のための制御動作を行うことができる。
インターネットアクセス制御モジュール（Ｉｎｔｅｒｎｅｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ（ｓ））は、ブロードバンドチャネルを介してサービス、コンテンツなどを取得するための受信機の動作を制御することができる。
シグナリングデコーダ（Ｓｉｇｎａｌｉｎｇ Ｄｅｃｏｄｅｒ）は、ブロードキャストチャネルなどを介して取得したシグナリング情報をデコードすることができる。
サービスシグナリングマネジャー（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからサービススキャン及びサービス／コンテンツなどに関連するシグナリング情報を抽出、パーシング及び管理することができる。
サービスガイドマネジャー（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからアナウンス（ａｎｎｏｕｎｃｅｍｅｎｔ）情報を抽出し、ＳＧ（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）データベース（ｄａｔａｂａｓｅ）を管理し、サービスガイドを提供することができる。
アプリケーションシグナリングマネジャー（Ａｐｐ Ｓｉｇｎａｌｉｎｇ Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからアプリケーション取得などに関連するシグナリング情報を抽出、パーシング及び管理することができる。
警報信号パーサー（Ａｌｅｒｔ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ＩＰデータグラムなどから警報（ａｌｅｒｔｉｎｇ）に関連するシグナリング情報を抽出、パーシング及び管理することができる。
ターゲッティング信号パーサー（Ｔａｒｇｅｔｉｎｇ Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツの個人化あるいはターゲッティングに関連するシグナリング情報を抽出、パーシング及び管理することができる。また、ターゲッティング信号パーサーは、パーシングされたシグナリング情報をターゲッティングプロセッサに伝達することができる。
ストリーミングメディアエンジン（Ｓｔｒｅａｍｉｎｇ Ｍｅｄｉａ Ｅｎｇｉｎｅ）は、ＩＰデータグラムなどからＡ／Ｖストリーミングのためのオーディオ／ビデオデータを抽出及びデコードすることができる。
非リアルタイムファイルプロセッサ（Ｎｏｎ−ｒｅａｌ ｔｉｍｅ Ｆｉｌｅ Ｐｒｏｃｅｓｓｏｒ）は、ＩＰデータグラムなどからＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態のデータを抽出、デコーディング、及び管理することができる。
コンポーネントシンクロナイザ（Ｃｏｍｐｏｎｅｎｔ Ｓｙｎｃｈｒｏｎｉｚｅｒ）は、ストリーミングオーディオ／ビデオデータ及びＮＲＴデータなどのコンテンツ及びサービスを同期化することができる。
ターゲッティングプロセッサ（Ｔａｒｇｅｔｉｎｇ Ｐｒｏｃｅｓｓｏｒ）は、ターゲッティング信号パーサーから受信したターゲッティングシグナリングデータに基づいてサービス／コンテンツの個人化関連演算を処理することができる。
アプリケーションプロセッサ（Ａｐｐ Ｐｒｏｃｅｓｓｏｒ）は、アプリケーション関連情報、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理することができる。
Ａ／Ｖプロセッサ（Ａ／Ｖ Ｐｒｏｃｅｓｓｏｒ）は、デコードされたオーディオ及びビデオデータ、アプリケーションデータなどに基づいてオーディオ／ビデオレンダリング関連動作を行うことができる。
デバイスマネジャー（Ｄｅｖｉｃｅ Ｍａｎａｇｅｒ）は、外部装置との接続及びデータ交換動作を行うことができる。また、デバイスマネジャーは、連動可能な外部装置の追加／削除／更新など、外部装置に対する管理動作を行うことができる。
データシェアリング及びコミュニケーションユニット（Ｄａｔａ Ｓｈａｒｉｎｇ ＆ Ｃｏｍｍ．）は、ハイブリッド放送受信機と外部装置との間のデータ伝送及び交換に関連する情報を処理することができる。ここで、伝送及び交換可能なデータはシグナリング、Ａ／Ｖデータなどであり得る。
再分配モジュール（Ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ Ｍｏｄｕｌｅ（ｓ））は、放送受信機が地上波放送信号を直接受信できない場合、次世代放送サービス及びコンテンツに対する関連情報を取得することができる。また、再分配モジュールは、放送受信機が地上波放送信号を直接受信できない場合、次世代放送システムによる放送サービス及びコンテンツ取得をサポートすることができる。
コンパニオンデバイス（Ｃｏｍｐａｎｉｏｎ ｄｅｖｉｃｅ（ｓ））は、本発明の放送受信機に接続されて、オーディオ、ビデオ、またはシグナリングを含むデータを共有することができる。コンパニオンデバイスは、放送受信機と接続された外部装置を指すことができる。
外部モジュール（Ｅｘｔｅｒｎａｌ Ｍａｎａｇｅｍｅｎｔ）は、放送サービス／コンテンツの提供のためのモジュールを指すことができ、例えば、次世代放送サービス／コンテンツサーバーであってもよい。外部モジュールは、放送受信機と接続された外部装置を指すことができる。
図１２は、本発明の一実施例に係るＤＡＳＨベースの適応型（Ａｄａｐｔｉｖｅ）ストリーミングモデルの全般的な動作を示した図である。
本発明は、ＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）をサポートできるコンテンツを提供する次世代メディアサービス提供方案を提案する。豊かな明るさの表現が可能なＨＤＲコンテンツが提供される場合において、本発明は、これに関連するメタデータ及びその伝達方案を提案する。これを通じて、コンテンツの様々な場面別の特性に応じて適応的にコンテンツを調整することができ、コンテンツを改善された画質で提供することができる。
ＵＨＤ放送などの場合、既存のコンテンツが表現できなかった明るさを表現できるため、高度の臨場感を提供することができる。ＨＤＲの導入でコンテンツ映像の明るさの表現範囲が増加して、コンテンツの場面別特性の差が以前よりも大きくなり得る。コンテンツの場面別特徴を効果的にディスプレイに示すために、メタデータが定義され、これらが受信機に伝達され得る。受信機では、伝達されたメタデータに基づいて、サービスプロバイダの意図に従ってコンテンツの映像を適切に提供することができる。
図示された実施例に係るＤＡＳＨベースの適応型ストリーミングモデルは、ＨＴＴＰサーバーとＤＡＳＨクライアントとの間の動作を記述している。ここで、ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）は、ＨＴＴＰベースの適応型ストリーミングをサポートするためのプロトコルであって、ネットワークの状況に応じて動的にストリーミングをサポートすることができる。これによって、ＡＶコンテンツの再生が途切れることなく提供され得る。
まず、ＤＡＳＨクライアントはＭＰＤを取得することができる。ＭＰＤは、ＨＴＴＰサーバーなどのサービスプロバイダから伝達され得る。ＭＰＤは、前述したデリバリの実施例に従って伝達されてもよい。ＤＡＳＨクライアントは、ＭＰＤに記述されたセグメントへの接近情報を用いてサーバーに当該セグメントを要求することができる。ここで、この要求は、ネットワークの状態を反映して行われ得る。
ＤＡＳＨクライアントは、当該セグメントを取得した後、これをメディアエンジンで処理して画面にディスプレイすることができる。ＤＡＳＨクライアントは、再生時間及び／又はネットワークの状況などをリアルタイムに反映して、必要なセグメントを要求、取得することができる（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ）。これを通じて、コンテンツが途切れることなく再生され得る。
ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＤＡＳＨクライアントがセグメントを動的に取得できるようにするための詳細情報を含むファイルであって、ＸＭＬの形態で表現されてもよい。このＭＰＤは、実施例によって、前述したＭＰＤと同一であってもよい。
ＤＡＳＨクライアントコントローラ（ＤＡＳＨ Ｃｌｉｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ）は、ネットワークの状況を反映して、ＭＰＤ及び／又はセグメントを要求するコマンドを生成することができる。また、このコントローラは、取得された情報をメディアエンジンなどの内部ブロックで利用可能なように制御することができる。
ＭＰＤパーサー（Ｐａｒｓｅｒ）は、取得したＭＰＤをリアルタイムでパーシングすることができる。これを通じて、ＤＡＳＨクライアントコントローラは、必要なセグメントを取得できるコマンドを生成できるようになる。
セグメントパーサー（Ｐａｒｓｅｒ）は、取得したセグメントをリアルタイムでパーシングすることができる。セグメントに含まれた情報によって、メディアエンジンなどの内部ブロックは特定の動作を行うことができる。
ＨＴＴＰクライアントは、必要なＭＰＤ及び／又はセグメントなどをＨＴＴＰサーバーに要求することができる。また、ＨＴＴＰクライアントは、サーバーから取得したＭＰＤ及び／又はセグメントをＭＰＤパーサー又はセグメントパーサーに伝達することができる。
メディアエンジン（Ｍｅｄｉａ Ｅｎｇｉｎｅ）は、セグメントに含まれたメディアデータを用いてコンテンツを画面上に表示することができる。このとき、ＭＰＤの情報が活用され得る。
図１３は、本発明の一実施例に係る受信機のブロックダイヤグラムを示した図である。
図示された実施例に係る受信機は、チューナー（Ｔｕｎｅｒ）、フィジカルレイヤコントローラ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｃｏｎｔｒｏｌｌｅｒ）、フィジカルフレームパーサー（Ｐｈｙｓｉｃａｌ Ｆｒａｍｅ Ｐａｒｓｅｒ）、リンクレイヤフレームプロセッサ（Ｌｉｎｋ Ｌａｙｅｒ Ｆｒａｍｅ Ｐｒｏｃｅｓｓｏｒ）、ＩＰ／ＵＤＰデータグラムフィルター（ＩＰ／ＵＤＰ Ｄａｔａｇｒａｍ Ｆｉｌｔｅｒ）、ＤＴＶコントロールエンジン（ＤＴＶ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ）、ＲＯＵＴＥクライアント（Ｒｏｕｔｅ Ｃｌｉｅｎｔ）、セグメントバッファコントロール（Ｓｅｇｍｅｎｔ Ｂｕｆｆｅｒ Ｃｏｎｔｒｏｌ）、ＭＭＴクライアント（ＭＭＴ Ｃｌｉｅｎｔ）、ＭＰＵリコンストラクション（ＭＰＵ ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ）、メディアプロセッサ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｏｒ）、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ Ｐａｒｓｅｒ）、ＤＡＳＨクライアント（ＤＡＳＨ Ｃｌｉｅｎｔ）、ＩＳＯ ＢＭＦＦパーサー（ＩＳＯ ＢＭＦＦ Ｐａｒｓｅｒ）、メディアデコーダ（Ｍｅｄｉａ Ｄｅｃｏｄｅｒ）及び／又はＨＴＴＰアクセスクライアント（ＨＴＴＰ Ａｃｃｅｓｓ Ｃｌｉｅｎｔ）を含むことができる。受信機の各細部ブロック（ｂｌｏｃｋ）は、ハードウェアであるプロセッサであってもよい。
チューナーは、地上波放送チャネルを介して放送信号を受信及び処理し、これを適切な形態（Ｐｈｙｓｉｃａｌ Ｆｒａｍｅなど）に変換することができる。フィジカルレイヤコントローラは、受信しようとする放送チャネルのＲＦ情報などを用いて、チューナー、フィジカルフレームパーサーなどの動作を制御することができる。フィジカルフレームパーサーは、受信されたフィジカルフレームをパーシングし、これと関連するプロセッシングを通じてリンクレイヤフレームなどを取得することができる。
リンクレイヤフレームプロセッサは、リンクレイヤフレームからリンクレイヤシグナリングなどを取得するか、またはＩＰ／ＵＤＰデータグラムを取得し、関連する演算を行うことができる。ＩＰ／ＵＤＰデータグラムフィルターは、受信されたＩＰ／ＵＤＰデータグラムから特定のＩＰ／ＵＤＰデータグラムをフィルタリングすることができる。ＤＴＶコントロールエンジンは、各構成間のインターフェースを担当し、パラメータなどの伝達を通じて各構成の動作を制御することができる。
ＲＯＵＴＥクライアントは、リアルタイムオブジェクト伝送をサポートするＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ Ｏｂｊｅｃｔ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）パケットを処理し、多数のパケットを収集及び処理して一つ以上のＩＳＯＢＭＦＦ（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）オブジェクトを生成することができる。セグメントバッファコントロールは、ＲＯＵＴＥクライアントとＤａｓｈクライアントとの間のセグメント（ｓｅｇｍｅｎｔ）伝送に関連するバッファを制御することができる。
ＭＭＴクライアントは、リアルタイムオブジェクト伝送をサポートするＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）伝送プロトコルパケットを処理し、多数のパケットを収集及び処理することができる。ＭＰＵリコンストラクションは、ＭＭＴＰパケットからＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を再構成することができる。メディアプロセッサは、再構成されたＭＰＵを収集し、処理することができる。
シグナリングパーサーは、ＤＴＶ放送サービス関連シグナリング（Ｌｉｎｋ Ｌａｙｅｒ／ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｓｉｇｎａｌｉｎｇ）を取得及びパーシングし、これに基づいてチャネルマップなどを生成及び／又は管理することができる。この構成は、ローレベルシグナリング及びサービスレベルシグナリングを処理することができる。
ＤＡＳＨクライアントは、リアルタイムストリーミングあるいは適応的ストリーミング関連演算及び取得したＤＡＳＨセグメントなどを処理することができる。ＩＳＯ ＢＭＦＦパーサーは、ＩＳＯ ＢＭＦＦオブジェクトからオーディオ／ビデオのデータ及び関連パラメータなどを抽出することができる。メディアデコーダは、受信されたオーディオ及びビデオデータをデコーディング及び／又はプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）処理することができる。ＨＴＴＰアクセスクライアントは、ＨＴＴＰサーバーから特定の情報を要求し、要求に対する応答を処理することができる。
本発明は、豊かな明るさの表現が可能なＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）コンテンツが提供されるとき、コンテンツ内に含まれた様々な場面の特性に対して適応的にコンテンツを調整できる要素を受信機に伝送することによって、改善された画質の映像にコンテンツを変換し、表現できる方法を提供することができる。ＵＨＤ放送では、既存のコンテンツで表現できなかった明るさを表現することによって、既存の放送との差別性を提供し、高度の臨場感を提供することができる。ＨＤＲ（ｈｉｇｈ ｄｙｎａｍｉｃ ｒａｎｇｅ）の導入を通じて、映像の明るさの表現範囲が増加することによって、コンテンツ内に含まれた場面間の特性の差が以前よりも大きくなり得る。これによって、放送送信装置は、各場面の特徴を効果的にディスプレイに示すための情報を追加的に提供し、受信装置は、伝送された情報に基づいて映像効果を提供することによって、制作者が意図した方向に適した方法で映像を表現することができる。
ＵＨＤ放送は、様々な方法を通じて、既存のＨＤ放送に比べて向上した画質及び没入感を視聴者に提供することができる。そのための方法の一つとして、ＵＨＤ放送は、コンテンツで表現する明るさの表現及び色相の表現の範囲を実際に人間の視覚系で認知可能な明るさ及び色相の範囲に拡張する方法を提供することができる。すなわち、ＵＨＤコンテンツに対してＨＤＲ（ｈｉｇｈ ｄｙｎａｍｉｃ ｒａｎｇｅ）及びＷＣＧ（ｗｉｄｅ ｃｏｌｏｒ ｇａｍｕｔ）を適用することができる。すなわち、コンテンツで向上した高コントラスト及び色感を提供することによって、ＵＨＤコンテンツを鑑賞するユーザは、さらに大きな没入感及び臨場感を経験するようになる。本発明では、コンテンツをディスプレイで再生するとき、効果的に制作者の意図などによって映像の明るさ及び色感を再生できる方法を提示することによって、ユーザがより向上した画質の映像を視聴できるようにする。
図１４は、本発明の一実施例に係るメタデータベースのＨＤＲ放送サービスを制作、再生する装置を示した図である。ＨＤＲビデオ制作装置は、キャプチャー／フィルムスキャナー１０１、ポストプロダクションブロック（マスタリング部）１０２及び／又はエンコーダ／マルチプレクサ１０３のうちの少なくとも１つを含むことができる。ＨＤＲビデオ再生装置は、デマルチプレクサ１０４、デコーダ１０５、メタデータプロセッサ１０６、ポストプロセッサ１０７、シンクロナイザ１０８及び／又はディスプレイ１０９のうちの少なくとも１つを含むことができる。図面では、ビデオストリームに含まれて受信されるメタデータを示したが、本発明のメタデータは、放送信号だけでなく、他の経路（例えば、ＩＰベースの放送／通信、有／無線通信、有／無線インターフェース、近距離無線通信など）でも送受信され得る。
ＨＤＲビデオ制作装置のキャプチャー／フィルムスキャナー１０１は、天然色で構成されたシーン（ｎａｔｕｒａｌ ｓｃｅｎｅ）をデジタルイメージに変換することができる。例えば、キャプチャー／フィルムスキャナーは、ビデオカメラ、カメラ、スキャナーなどの光学イメージをデジタルイメージに変換する装置であってもよい。キャプチャー／フィルムスキャナー１０１は、光学イメージをセンシングしてロー（Ｒａｗ）ＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）ビデオを出力することができる。
ポストプロダクションブロック（マスタリング部）１０２は、ロー（Ｒａｗ）ＨＤＲビデオを受信して、マスタリングされたＨＤＲビデオ及びＨＤＲメタデータを出力することができる。ポストプロダクションブロックは、マスタリングディスプレイ情報、視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）情報、カラーエンコーディング情報、色領域（Ｇａｍｕｔ）マッピング情報、及び／又はＤＲ（ｄｙｎａｍｉｃ ｒａｎｇｅ）情報などを受信してマスタリングを行うことができる。ここで、カラーエンコーディング情報は、例えば、ＥＯＴＦ（ｅｌｅｃｔｒｏ−ｏｐｔｉｃａｌ ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）、ＢＴ．２０２０を例に挙げることができる。
エンコーダ／マルチプレクサ１０３は、少なくとも１つ以上のマスタリングされたＨＤＲビデオ及びＨＤＲメタデータをエンコードし、多重化することができる。
ＨＤＲビデオ再生装置のデマルチプレクサ１０４は、ＨＤＲストリームを受信して逆多重化することができる。一つのＨＤＲストリームには複数のコンテンツが含まれ得、デマルチプレクサは、デコーディングの対象であるＨＤＲストリームをデコーダに出力することができる。
デコーダ１０５は、ＨＤＲストリームを受信してデコーディングを行うことができる。この過程でデコーダは、デコードされたＨＤＲビデオ及びＨＤＲメタデータを出力することができる。デコードされたＨＤＲビデオはポストプロセッサに出力され、ＨＤＲメタデータはメタデータプロセッサに出力され得る。
メタデータプロセッサ１０６は、ＨＤＲメタデータを受信して格納することができる。メタデータプロセッサは、ＨＤＲメタデータ内に含まれたセット（ｓｅｔ）ナンバー又はバージョンナンバーを確認して、格納されたＨＤＲメタデータに対する変更があるかを確認し、変更がある場合、既存のＨＤＲメタデータをアップデートすることができる。メタデータプロセッサは、シンクロナイザから受信されるタイミング情報に従ってＨＤＲメタデータをポストプロセッサに出力することができる。
ポストプロセッサ１０７は、メタデータプロセッサから受信したＨＤＲメタデータを用いて、デコーダから受信したＨＤＲビデオに対して後処理作業を行うことができる。この過程を通じて、ＨＤＲビデオは、ＨＤＲメタデータが反映された改善されたＨＤＲビデオに変換され得る。
シンクロナイザ１０８は、メタデータプロセッサ及びポストプロセッサにタイミング情報を提供することによって、ＨＤＲビデオ全体、または各場面、各ビデオクリップ又は各フレーム別に正確な時点でメタデータが適用されるようにすることができる。ここで、メタデータは、マスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）に関する情報を示してもよく、チャネル（ｃｈａｎｎｅｌ）、プログラム（ｐｒｏｇｒａｍ）、コンテンツ（ｃｏｎｔｅｎｔ）の単位で共通に適用される情報、または連続した場面、ビデオクリップ、フレームのそれぞれに適用される情報を意味してもよい。
ＨＤＲディスプレイ１０９は、改善されたＨＤＲビデオをディスプレイしてユーザに提供することができる。
図１５は、本発明の一実施例に係るＨＤＲビデオに対する受信機の動作方法を示す。本発明では、受信機の動作を主に説明するが、関連シグナルを生成する場合にも同じ事項を考慮し得、プロダクション（ｐｒｏｄｕｃｔｉｏｎ）間の伝達信号及びマスタリング（ｍａｓｔｅｒｉｎｇ）信号に対しても適用することができる。また、ソース（ｓｏｕｒｃｅ）とシンク（ｓｉｎｋ）との間の情報伝送の場合にも、本発明で考慮する事項が伝達され得る。
ビデオストリームが受信されると、受信機は、ビデオデコーダ２０１を用いてＨＤＲメタデータをＨＤＲビデオ信号から分離して別途のメタデータプロセッサ２０２に格納することができる。メタデータプロセッサは、メタデータパーサー、メタデータバッファ及びメタデータアップデーターを含むことができる。ＨＤＲメタデータは、共通適用情報（ｃｏｍｍｏｎ ＨＤＲ ｍｅｔａｄａｔａ）及び部分適用情報（ｓｃｅｎｅ／ｆｒａｍｅ ＨＤＲ ｍｅｔａｄａｔａ）を含むことができる。共通適用情報は、コンテンツ全般に対して適用可能なメタデータであり、チャネル、プログラム、コンテンツの単位で共通に適用される情報を意味し得る。
部分適用情報は、コンテンツの一部分に限定して適用可能なメタデータを示すことができ、連続した場面、ビデオクリップまたはフレームのそれぞれに適用される情報を意味し得る。受信機は、再生可能なコンテンツ種類に対する性能を判断した後、受信された共通情報あるいは部分情報をコンテンツに適用してプロセッシングすることができる。ＨＤＲビデオを再生できる受信機は、受信されたメタデータを用いてコンテンツを変換することができる。受信機は、プロセッシング作業の後の変換されたコンテンツを最終映像としてディスプレイすることができる。具体的な受信機の動作方法は、次の通りである。
第一のステップとして、受信機は、ビデオストリームをデコードし、ＨＤＲメタデータを取得することができる。ＨＤＲメタデータは、ＨＤＲビデオ情報（以下、ＨＤＲ＿ｉｎｆｏ（））を意味し得る。受信機は、ビデオストリームから取得したメタデータをメタデータパーサー（ｍｅｔａｄａｔａ ｐａｒｓｅｒ）２０２に伝達して分析し、メモリに格納することができる。メタデータは、共通適用情報（ｃｏｍｍｏｎ ＨＤＲ ｍｅｔａｄａｔａ）と部分適用情報（ｓｃｅｎｅ／ｆｒａｍｅ ＨＤＲ ｍｅｔａｄａｔａ）とに区分できる。本発明では、後述するタイプ情報（ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ）を用いて当該メタデータが適用される範囲を伝達することによって、マスタリングディスプレイに応じてメタデータを適用したり、チャネル、プログラム、コンテンツの単位で共通にメタデータを適用したり、連続した場面、ビデオクリップ、フレームのそれぞれにメタデータを適用したりすることができる。
これに加えて、メタデータは、当該メタデータが適用される区間、例えば、当該メタデータと適用される映像フレームをマッチングできる情報を同期化開始情報（ｓｙｎｃ＿ｓｔａｒｔ）、同期化区間情報（ｓｙｎｃ＿ｄｕｒａｔｉｏｎ）の形式でさらに含むことができる。
実施例によって、共通適用情報は、例えば、最大最小明るさ又は高コントラストのようにコンテンツ／マスタリングディスプレイ／フレームのダイナミックレンジ（ｄｙｎａｍｉｃ ｒａｎｇｅ）を示すことができる値、ＥＯＴＦのような変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）、コンテンツあるいはマスタリングディスプレイの色空間、コンテンツあるいはマスタリングディスプレイの色温度、明るさ範囲変換関数、色空間変換関数及び／又は視聴環境情報のうちの少なくとも１つの情報を含むことができる。
本明細書において、コンテンツ／マスタリングディスプレイ／フレームのダイナミックレンジを示すことができる値は、ＤＲ情報タイプ（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ）及びＤＲバリュー情報（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｖａｌｕｅ［ｉ］）を通じて伝送されてもよい。また、ＥＯＴＦのような変換関数は、変換関数タイプ（ｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ｔｙｐｅ）を通じて伝送されてもよい。コンテンツあるいはマスタリングディスプレイの色空間は、ＣＧ情報タイプ（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ）を通じて伝送されてもよい。コンテンツあるいはマスタリングディスプレイの色温度は、色温度情報タイプ（ｃｏｌｏｒ＿ｔｅｍｐｅｒａｔｕｒｅ＿ｔｙｐｅ）を通じて伝送されてもよい。明るさ範囲変換関数は、ＤＲマッピング情報タイプ（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ）を通じて伝送されてもよい。色空間変換関数は、ＣＧマッピング情報タイプ（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ）を通じて伝送されてもよい。視聴環境情報は、視聴環境情報タイプ（ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｔｙｐｅ）を通じて伝送されてもよい。各情報のシンタックス及び含むフィールドについては後述する。
部分適用情報は、共通適用情報と同一又は類似の情報を含むことができ、その適用範囲に関する情報を共に含むことができる。部分適用情報は、その適用範囲がコンテンツの一定の部分に限定されているという点でさらに具体的な情報を伝達することができる。例えば、共通適用情報は、コンテンツ全体に適用される明るさ範囲をｆ−ｓｔｏｐや高コントラストのような値として伝達することができる。これに比べて部分適用情報は、フレーム単位に対しては最大最小値を伝達して、さらに具体的な情報を伝達することができる。これを通じて、伝送される適用情報の種類によって、情報伝達範囲を各ステップ別に差等的に適用することができる。同様に、ダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）の場合、共通適用情報として全般的なコンテンツ変換情報を伝達した後、部分適用情報を通じて場面毎の特徴を生かし得る複雑な変換関数を伝達することができる。
第二のステップとして、受信機は、自身が含むディスプレイがＨＤＲディスプレイであるか否かを決定することができる。受信機は、共通情報を用いて取得したコンテンツに関する情報（又はマスタリングディスプレイに関する情報）に基づいて受信機の再生環境が適しているか否かを決定することができる。例えば、受信機は、上述した共通適用情報を用いることができ、もし、コンテンツ再生環境が適していない場合、ＳＤＲディスプレイ、あるいはＳＤＲとＨＤＲとの間の性能に該当するディスプレイを考慮することができる。
まず、受信機に含まれたディスプレイがＳＤＲディスプレイ又はこれに準ずる性能を有するディスプレイである場合について説明する。受信機のディスプレイがデコードされたＨＤＲコンテンツを完全に再生できないと決定される場合、受信機は、ＨＤＲコンテンツを再生しないか、またはコンテンツを再生するための変換を行うことができる。ＨＤＲビデオをＳＤＲビデオに変換できる受信機は、受信されたＨＤＲビデオをＳＤＲビデオに変換して再生することができる。そのために、ＨＤＲメタデータは、ＨＤＲビデオをＳＤＲビデオに変換する変換関数に関する情報を含むことができる。例えば、上述した変換関数に関する情報として、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ又はｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅなどを使用することができ、ＨＤＲメタデータは、必要であれば、当該情報がＨＤＲビデオをＳＤＲビデオに変換する用途に使用されるということを追加的にシグナリングすることができる。
次に、受信機に含まれたディスプレイがＨＤＲディスプレイである場合について説明する。これは、受信機のディスプレイがデコードされたコンテンツを完全に再生可能であると決定される場合に該当する。この場合、ＨＤＲメタデータに含まれた共通適用情報を用いてビデオに対する画質改善が可能であり、ダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）、カラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境マッピング（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｍａｐｐｉｎｇ）などを用いて画質改善を行うことができる。実施例によって、共通適用情報を用いたコンテンツ全般に対する画質改善は、後述する第三のステップで部分適用情報の適用が可能な場合、省略されてもよい。また、共通適用情報を用いたビデオに対する画質改善作業は、別途のモジュールを通じて具現してもよく、図１６で説明するポストプロセッシング（ｐｏｓｔ ｐｒｏｃｅｓｓｉｎｇ）モジュールと連携して適用してもよい。
第三のステップとして、受信機は、ＨＤＲビデオの場面別に画質改善作業を行うことができる。メタデータ情報に基づいて受信機がＨＤＲコンテンツを再生できると決定される場合、受信機は、追加的なＨＤＲメタデータの処理が可能であるかを決定することができる。
図１５では、場面別（ｓｃｅｎｅ−ｂｙ−ｓｃｅｎｅ）（又はクリップ別（ｃｌｉｐ−ｂｙ−ｃｌｉｐ）又はフレーム別（ｆｒａｍｅ−ｂｙ−ｆｒａｍｅ））の処理を追加で行う場合を例に挙げており、この場合、各場面、クリップ、またはフレームの単位で提供されるメタデータを用いて各コンテンツの場面、ビデオクリップまたはフレーム別にディテールな動的変換を通じて、さらに向上した画質のＨＤＲビデオをディスプレイすることができる。この場合、本発明の一実施例によって、放送送信装置は、ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅを用いて、受信機が場面、ビデオクリップまたはフレーム単位の情報が伝送されることをＳＥＩ（ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）メッセージ内で識別するようにすることができる。また、放送送信装置は、同期化情報タイプ（ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ）、同期化開始情報（ｓｙｎｃ＿ｓｔａｒｔ）、同期化区間情報（ｓｙｎｃ＿ｄｕｒａｔｉｏｎ）を用いて、受信機に、場面又はフレーム単位の情報を適用しなければならない時点に関する情報を提供することができる。受信機は、ＨＤＲビデオ情報タイプ（ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ）を介して場面、ビデオクリップまたはフレーム単位の情報が伝送されることを識別し、ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ、ｓｙｎｃ＿ｓｔａｒｔ、ｓｙｎｃ＿ｄｕｒａｔｉｏｎを介して場面、ビデオクリップまたはフレーム単位の情報を適用する時点に関するタイミング情報を取得することができる。また、必要に応じて、受信機は、メタデータを介して提供されるタイミング情報を、映像とｓｙｎｃを取るための情報に変換することもできる。
また、放送送信装置は、共通適用情報を提供するとき、後でどのような種類の場面、ビデオクリップまたはフレーム単位のメタデータが提供されるかを受信機に知らせることができる。放送送信装置は、ＨＤＲ＿ｖｉｄｅｏ＿ｅｎｈａｎｃｅｍｅｎｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｔｙｐｅを介して前記情報を受信機に予め知らせることができる。すなわち、受信機は、共通適用情報から、部分適用情報の受信有無及びその種類に関する情報を予め取得することによって、関連モジュールの動作を準備することができる。実施例によって、放送送信装置は、共通適用情報を用いて、フレーム、ビデオクリップまたは場面の単位のメタデータが提供されるという事実自体を示したり、フレーム単位、ビデオクリップ単位または場面単位で具体的にどのような情報があるかを示すことができる。例えば、放送送信装置は、共通適用情報を用いて、フレーム単位又は場面単位でダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）又は／及びカラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）情報が提供されることを示すことができる。
実施例によって、受信機は、共通適用情報及び場面適用情報をＨＤＲビデオに対して段階的に適用してもよく、一つの動作として適用してもよい。また、受信機は、ダイナミックレンジマッピング及びカラーガマットマッピング別に共通適用情報及び場面適用情報をＨＤＲビデオに適用してもよく、一つの変換式で適用してもよい。
図１６は、本発明の一実施例に係る後処理部を示す。本発明において、後処理部（ｐｏｓｔ ｐｒｏｃｅｓｓｏｒ）は、ＤＲマッピングブロック（Ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）３０１、ＣＧマッピングブロック（Ｃｏｌｏｒ Ｇａｍｕｔ ｍａｐｐｉｎｇ）３０２及び視聴環境調整ブロック（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ａｄｊｕｓｔｍｅｎｔ）３０３を含むことができる。後処理部は、ＨＤＲビデオデータの入力を受けてダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）、カラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境マッピング（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｍａｐｐｉｎｇ）などを用いて画質改善を行うことができる。ＤＲマッピングブロック（Ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）３０１は、入力されたＨＤＲビデオデータに対してダイナミックレンジ（ｄｙｎａｍｉｃ ｒａｎｇｅ）情報、変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）情報及びＤＲマッピング情報を適用して画質改善作業を行うことができる。ＣＧマッピングブロック（Ｃｏｌｏｒ Ｇａｍｕｔ ｍａｐｐｉｎｇ）３０２は、入力されたＨＤＲビデオデータに対してカラーガマット（Ｃｏｌｏｒ ｇａｍｕｔ）情報、色温度（ｃｏｌｏｒ ｔｅｍｐｅｒａｔｕｒｅ）情報、及びＣＧマッピング情報を適用して画質改善作業を行うことができる。視聴環境調整ブロック（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ａｄｊｕｓｔｍｅｎｔ）３０３は、視聴環境情報をＨＤＲビデオデータに適用して画質改善作業を行うことができる。各情報に関する詳細な説明は、図１７乃至図２９で後述する。
図１７乃至図２０は、本発明の一実施例に係るＳＥＩメッセージ及びＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）のシンタックスを示す。
ＳＥＩメッセージはＨＤＲ情報ディスクリプタを含むことができ、ＨＤＲ情報ディスクリプタは、次のフィールドのうち少なくとも１つのフィールドを含むことができる。本発明において、ＨＤＲ情報（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ）は、ＨＤＲビデオ情報（ＨＤＲ ｖｉｄｅｏ ｉｎｆｏｒｍａｔｉｏｎ）と同じ意味で使用することができる。
ＨＤＲ情報タイプ（ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、ＨＤＲ情報ディスクリプタ内の情報が適用される単位を示すことができる。例えば、マスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）に対する情報を示すか、またはチャネル（ｃｈａｎｎｅｌ）、プログラム（ｐｒｏｇｒａｍ）、コンテンツ（ｃｏｎｔｅｎｔ）の単位で共通に適用され得る。また、連続した場面、ビデオクリップ、フレームのそれぞれに適用される形態で区分することができ、他の方法（例えば、変換前と変換後、伝送フォーマット、変換後の目標対象フォーマット、ｓｔａｔｉｃ／ｄｙｎａｍｉｃ ｍｅｔａｄａｔａなど）で分類される場合を追加してもよい。
前記のような分類によって、現在のｐａｙｌｏａｄＴｙｐｅ内で定義されたＨＤＲ情報（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ）の種類を区分することができる。このとき、図１７の実施例のように、ｐａｙｌｏａｄＴｙｐｅ内に１つのＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅに該当する細部情報のみが記述されてもよく、２つ以上の情報が全て記述されてもよい。この場合、それぞれのＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅによって分類された情報が連続して位置するようにシンタックス（ｓｙｎｔａｘ）を構成することができる。
また、情報が適用される単位をＳＥＩメッセージ内で分類する方法だけでなく、互いに異なるｐａｙｌｏａｄＴｙｐｅを割り当てて区分することもできる。例えば、ｐａｙｌｏａｄＴｙｐｅ＝５２（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）、ｐａｙｌｏａｄＴｙｐｅ＝５３（ｃｈａｎｎａｌ）、ｐａｙｌｏａｄＴｙｐｅ＝５４（ｐｒｏｇｒａｍ）、ｐａｙｌｏａｄＴｙｐｅ＝５５（ｃｏｎｔｅｎｔ）、ｐａｙｌｏａｄＴｙｐｅ＝５６（ｓｃｅｎｅ）、ｐａｙｌｏａｄＴｙｐｅ＝５７（ｃｌｉｐ）、ｐａｙｌｏａｄＴｙｐｅ＝５８（ｆｒａｍｅ）のように区分することができる。
トランジションフラグ（ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）情報は、現在記述しているＳＥＩメッセージと関連するコンテンツの終了時点に対するシグナルである。例えば、ＨＤＲコンテンツが終了し、ＳＤＲコンテンツに切り替わる場合、最後のフレームに対してｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇを１にセットする。このとき、適用分野に応じてＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）の伝送が終了するという意味として考慮することもでき、受信機では、本シグナルに基づいて、ＨＤＲ情報ディスクリプタと関連するモジュールをｏｆｆさせるなどの動作につながり得る。もし、受信機がＳＴＢ（ｓｅｔｔｏｐ ｂｏｘ）とｄｉｓｐｌａｙ ｄｅｖｉｃｅに区分されて有／無線インターフェースで接続された場合（例えば、ＨＤＭＩ、ＤｉｓｐｌａｙＰｏｒｔ、ＭＨＬなど）、これと類似に、ＨＤＲ関連情報の中断あるいはＨＤＲコンテンツの終了のような情報をＳＴＢからｄｉｓｐｌａｙ ｄｅｖｉｃｅに伝達することができる。ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは終了時点を知らせるという意味でＨＤＲ情報ディスクリプタが終了するフレームで知らせることができる。予め約束された場合、終了フレームが含まれたＲＡＰで知らせる方法も適用することができる。
セット（ｓｅｔ＿ｎｕｍｂｅｒ）情報は、ＨＤＲ情報ディスクリプタの固有の識別番号を示すことができる。すなわち、時間単位又はフレーム単位で複数のＨＤＲ情報ディスクリプタが放送送信装置から受信機に伝達される状況で、それぞれのＨＤＲ情報ディスクリプタを区分する役割を果たすことができる。必要であれば、上述したＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅと連携してチャネル（ｃｈａｎｎｅｌ）、プログラム（ｐｒｏｇｒａｍ）、コンテンツ（ｃｏｎｔｅｎｔ）、フレーム（ｆｒａｍｅ）、シーン（ｓｃｅｎｅ）、クリップ（ｃｌｉｐ）などのそれぞれに対して複数のディスクリプタを区分する役割を果たすことができる。例えば、様々な種類の輝度（ｌｕｍｉｎａｎｃｅ）を有するディスプレイのサポートを目的で互いに異なるＤＲ ｍａｐｐｉｎｇ ｆｕｎｃｔｉｏｎを伝達する場合、上述したＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅと連携してチャネル、プログラム、コンテンツ、フレーム、シーン、クリップなどのそれぞれに対して複数のディスクリプタを区分する役割を果たすことができる。
バージョン（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）情報は、ＨＤＲ情報ディスクリプタのバージョンを示すことができる。ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ及びｓｅｔ＿ｎｕｍｂｅｒのうちの少なくとも１つと連携して現在のディスクリプタにおいて情報の変更があることを示すことができる。例えば、同じＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ及び／又はｓｅｔ＿ｎｕｍｂｅｒを有するディスクリプタに対して同じバージョンナンバー（ｖｅｒｓｉｏｎ ｎｕｍｂｅｒ）を有する場合、メタデータプロセッサ（ｍｅｔａｄａｔａ ｐｒｏｃｅｓｓｏｒ）内の情報を映像にそのまま適用することができる。しかし、放送受信装置は、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒが変更された場合、メタデータバッファ（ｍｅｔａｄａｔａ ｂｕｆｆｅｒ）内の情報をアップデートし、新しい情報を映像に適用することができる。
ＤＲフラグ（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）情報は、ディスクリプタ内にダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）関連情報が含まれていることを示すことができる。
ＣＧフラグ（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）情報は、ディスクリプタ内にガマットマッピング（ｇａｍｕｔ ｍａｐｐｉｎｇ）関連情報が含まれていることを示すことができる。
視聴環境フラグ（ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）情報は、ディスクリプタ内に視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）関連情報が含まれていることを示すことができる。
追加改善情報個数（ｎｕｍｂｅｒ＿ｏｆ＿ＨＤＲ＿ｖｉｄｅｏ＿ｅｎｈａｎｃｅｍｅｎｔ＿ｉｎｆｏ）情報は、現在のＳＥＩメッセージと関連する追加のＳＥＩメッセージがある場合に対して関連する情報の数を示す。または、向上した情報を提供することもできる。例えば、ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ＝００１１（ｃｏｎｔｅｎｔ）情報を伝達している場合、マスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）、シーン（ｓｃｅｎｅ）に対する情報がこれと関連して伝達され得、この場合、３値を有するようになる。このとき、受信機では、トーンマッピング（ｔｏｎｅ ｍａｐｐｉｎｇ）、ガマットマッピング（ｇａｍｕｔ ｍａｐｐｉｎｇ）などの画質処理を行うとき、性能に応じてコンテンツ（ｃｏｎｔｅｎｔ）内の情報のみを用いることができる。また、より詳細な情報を有していると判断される場合、例えば、ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ＝０１００（ｓｃｅｎｅ）の情報のみを用いたり、実施例によっては、全ての情報を総合して用いることができる。
追加改善情報種類（ＨＤＲ＿ｖｉｄｅｏ＿ｅｎｈａｎｃｅｍｅｎｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｔｙｐｅ）情報は、現在のＳＥＩメッセージと関連する追加情報の種類を示し、図１８のＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅと同じ値を用いて定義することができる。このとき、ｅｎｈ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｅｎｈ＿ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｅｎｈ＿ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを通じてＤＲマッピング（ＤＲ ｍａｐｐｉｎｇ）、ガマットマッピング（ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）関連情報が伝達されるか否かを知らせることができ、これに対する情報処理のための受信機の動作を予め準備したり、現在の情報に比べて向上した情報が使用されるか否かを判断するときに用いることができる。
改善ＤＲフラグ（ｅｎｈ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）は、その値が１である場合、関連するメタデータ情報に対してＤＲマッピング（ＤＲ ｍａｐｐｉｎｇ）情報が存在することを示すことができる。
改善ＣＧフラグ（ｅｎｈ＿ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）は、その値が１である場合、関連するメタデータ情報に対してガマットマッピング（ｇａｍｕｔ ｍａｐｐｉｎｇ）情報が存在することを示すことができる。
改善視聴環境フラグ（ｅｎｈ＿ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）は、その値が１である場合、関連するメタデータ情報に対して視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）情報が存在することを示すことができる。
メタデータタイプ（ｍｅｔａｄａｔａ ｔｙｐｅ）が、ＨＤＲ情報（ＨＤＲ ｉｎｆｏ）ではなく、ＳＥＩメッセージのｐａｙｌｏａｄＴｙｐｅの値で区分される場合、前記のようにＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ及びそれと関連するフラグ（ｆｌａｇ）を用いる方法以外にも、当該ＳＥＩメッセージのｐａｙｌｏａｄＴｙｐｅの値を直接伝達することができる。すなわち、前記の例に対して、ｐａｙｌｏａｄＴｙｐｅ＝５３（ｃｏｎｔｅｎｔ）に対する追加（向上）情報として、ｐａｙｌｏａｄＴｙｐｅ＝５２（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）、ｐａｙｌｏａｄＴｙｐｅ＝５６（ｓｃｅｎｅ）を伝達することができる。または、ｐａｙｌｏａｄＴｙｐｅを追加してＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅと共に情報を提供することもできる。
同期化情報タイプ（ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、ＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）内の情報が適用されなければならないコンテンツ、シーン、クリップまたはフレームとの同期化のための情報の表現方法を示すことができる。例えば、デコーダ内で使用されるＰＯＣ（Ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ）値を伝達してもよく、またはｐｉｃ＿ｏｒｄｅｒ＿ｃｏｕｎｔ＿ｌｓｂ値を直接伝達してもよい。ストレージメディア（Ｓｔｏｒａｇｅ ｍｅｄｉａ）である場合、メディアタイム（ｍｅｄｉａ ｔｉｍｅ）情報を使用することができ、ビデオ開始に対するリファレンスタイム（ｒｅｆｅｒｅｎｃｅ ｔｉｍｅ）を基準とした累積フレーム（ｆｒａｍｅ）の数で定めることもできる。
同期化開始（ｓｙｎｃ＿ｓｔａｒｔ）情報は、同期化の開始地点と関連する情報である。フレーム毎に関連情報を送る場合ではなく、ＲＡＰなどの特定の周期毎に当該情報を伝達する場合、当該情報が使用される区間の始まりと終わりをビデオフレームと連結させる必要がある。本発明では、ｓｙｎｃ＿ｓｔａｒｔ情報を使用して当該情報が適用される区間又はフレームの開始情報をｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅと連携して時間、ＰＯＣ、フレームの数、ＰＴＳなどの情報として示す実施例を適用することができる。ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅは、時間、時間差、開始順序、ＰＯＣ（ｐｉｃｔｕｒｅ ｏｒｄｅｒ ｃｏｕｎｔ）、ＰＴＳ、合算されたフレームの数として同期化情報のタイプを定義することができる。
例えば、２秒のＲＡＰ間隔を有する５０ｆｐｓビデオストリームに対して２〜４秒のＲＡＰ区間内で３つのメタデータがそれぞれ２秒（開始時点）、２．５秒、３．５秒に適用される場合を考慮することができる。
Ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ＝０×００である場合、同期化情報のタイプは時間として設定され、各メタデータのｓｙｎｃ＿ｓｔａｒｔ情報を２０００、２５００、３５００として伝達することができる。また、追加的に、ｓｙｎｃ＿ｄｕｒａｔｉｏｎを５００、１０００、１０００としてシグナリングすることができる。このとき、時間の判断のために時間に対する基準が必要な場合があり、ＴＳヘッダーのアダプテーションフィールド（ａｄａｐｔａｔｉｏｎ ｆｉｅｌｄ）に時間を定義することのように別途にシグナリングすることができる。
Ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ＝０×０１である場合、同期化情報のタイプは時間差として設定され得る。放送送信装置は、ｓｙｎｃ＿ｓｔａｒｔ＝０、５００、１０００としてそれぞれシグナリングすることによって、それぞれ直ちに適用、ＲＡＰから０．５秒後に適用、ＲＡＰから１．５秒後に適用であることを受信機に知らせることができる。
Ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ＝０×０２である場合、同期化情報のタイプは開始順序として設定され、ｓｙｎｃ＿ｓｔａｒｔ＝０、１、２のように順序を知らせることができる。開始順序がシグナリングされると、受信機は、一定の時間間隔で順序に従って同期化情報を適用できる。一定の時間間隔は、固定された値であってもよく、順序に従って定められた値を有してもよい。例えば、０は、直ちに適用開始、１は、ＲＡＰ＋０．５秒に適用、２は、ＲＡＰ＋１．５秒に適用のように推定することができる。
Ｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ＝０×０３である場合、同期化情報のタイプはＰＯＣとして設定され得る。この場合、メタデータの適用時点のビデオのＰＯＣ値を１００、１２５、１７５のように伝達することができ、後述するｄｕｒａｔｉｏｎも、ＰＯＣの単位に応じて２５、５０、５０のように伝達することができる。また、ビデオコーデックシンタックス（ｖｉｄｅｏ ｃｏｄｅｃ ｓｙｎｔａｘ）内のＰＯＣと関連する値を直接伝達することもできる。
ＰＴＳ（ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅ ｓｔａｍｐ）、フレームの数をシグナリングする場合にも、前記のＰＯＣの例とほぼ同様に、ＰＴＳ、フレームの数の情報を通じてメタデータの適用時点を示すことができる。
同期化区間（ｓｙｎｃ＿ｄｕｒａｔｉｏｎ）情報は、同期化開始（ｓｙｎｃ＿ｓｔａｒｔ）から持続する区間に関する情報である。先の例のように、同期化終了地点はｓｙｎｃ＿ｓｔａｒｔ＋ｓｙｎｃ＿ｄｕｒａｔｉｏｎで計算することができ、必要であれば、ｓｙｎｃ＿ｄｕｒａｔｉｏｎと共に、又はその代わりに同期化終了時点情報を直接伝達することもできる。Ｌｉｖｅ放送の場合、終了時間を予め定めることができないため、ＦＦＦＦのように予め約束された値に設定することができる。もし、ｓｙｎｃ＿ｓｔａｒｔ情報のみでメタデータの適用時間に対する判断が可能な場合、ｓｙｎｃ＿ｄｕｒａｔｉｏｎ値が使用されなくてもよい。この場合、ｓｙｎｃ＿ｄｕｒａｔｉｏｎは、当該メタデータの後に他のメタデータが伝送されるか否かのような追加情報を提供するフラグとして使用してもよい。
ＤＲ情報個数（ｎｕｍｂｅｒ＿ｏｆ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ）情報は、マスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）、チャネル（ｃｈａｎｎｅｌ）、プログラム（ｐｒｏｇｒａｍ）、コンテンツ（ｃｏｎｔｅｎｔ）、シーン（ｓｃｅｎｅ）、クリップ（ｃｌｉｐ）またはフレーム（ｆｒａｍｅ）に該当するダイナミックレンジ情報の表現方法の数を示すことができる。
ＤＲ情報タイプ（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、マスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当するダイナミックレンジ情報の表現方法を示す。ダイナミックレンジを表現するための方法は、図１９の下段の通りであり得る。ダイナミックレンジは、最大明るさ、最小明るさ、平均明るさ、一定の成分で構成された平均又はメディアン（ｍｅｄｉａｎ）値のうちの少なくとも１つを用いて示すことができる。また、ｗｈｉｔｅの場合にも、ｎｏｒｍａｌ ｗｈｉｔｅ、ｄｉｆｆｕｓｅ ｗｈｉｔｅ、ｓｐｅｃｕｌａｒ ｗｈｉｔｅのように、明るい部分を特性に応じて細部的に区分することができ、ｂｌａｃｋの場合にも、ｎｏｒｍａｌ ｂｌａｃｋ、ｄｅｅｐ ｂｌａｃｋ、ｐｉｔｃｈ ｄａｒｋのように、特性に応じて種類を区分して表示することができる。
下記の例示のように、放送送信装置は、ＨＤＲ情報（ＨＤＲ ｉｎｆｏ）を介してｓｐｅｃｕｌａｒ ｗｈｉｔｅ及びｐｉｔｃｈ ｄａｒｋのような情報を提供することによって、コンテンツ内に明部及び暗部に対して明るさを細分化して表現することができ、このような情報は、受信機のディスプレイ環境に対する判断基準として用いたり、ディスプレイ環境によるマッピングのための情報として活用したりすることができる。
ＤＲ情報バリュー（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｖａｌｕｅ）情報は、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅに応じて該当する値を伝達することができる。すなわち、下記のようにｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅに応じてコンテンツ、マスタリングディスプレイ、シーンのＤＲのそれぞれを細かく表現することができる。または、コンテナビデオフォーマット（ｃｏｎｔａｉｎｅｒ ｖｉｄｅｏ ｆｏｒｍａｔ）と実際のコンテンツ（ｃｏｎｔｅｎｔ）の特性を区分して記述するために使用してもよい。
Ｅｘ）ｃｏｎｔｅｎｔ：ｐｅａｋ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌ＝２０００（ｎｉｔ），ｍｉｎｉｍｕｍ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌ＝０．１（ｎｉｔ）
ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ：ｐｅａｋ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌ＝４０００（ｎｉｔ），ｍｉｎｉｍｕｍ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌ＝０．０１（ｎｉｔ）
ｓｃｅｎｅ：ｗｈｉｔｅ＿ｌｅｖｅｌ＿Ａ＝８００（ｎｉｔ），ｗｈｉｔｅ＿ｌｅｖｅｌ＿Ｂ＝１５００（ｎｉｔ），ｂｌａｃｋ＿ｌｅｖｅｌ＿Ａ＝１（ｎｉｔ），ｂｌａｃｋ＿ｌｅｖｅｌ＿Ｂ＝０．１（ｎｉｔ）
変換関数タイプ（ｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ｔｙｐｅ）情報は、ＨＤＲビデオのマスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに使用された変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）の種類を示すことができる。例えば、ＳＭＰＴＥ ＳＴ ２０８４、ＩＴＵ ＢＴ．１８８６、ＢＴ．２０２０などのように予め定められたＥＯＴＦがシグナリングされてもよい。変換関数の種類によって絶対明るさ表現方法、相対明るさ表現方法などのように区分し、具体的な方法をシグナリングすることもできる。必要であれば、任意の変換関数の係数を伝達することもできる。
ＣＧタイプ（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ）情報は、ＨＤＲビデオのマスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当するカラーガマット（ｃｏｌｏｒ ｇａｍｕｔ）の種類を示すことができる。例えば、ＢＴ．７０９、ＢＴ．２０２０、ＤＣＩ−Ｐ３のような標準カラーガマットを示したり、必要によっては、ＲＧＢ ｃｏｌｏｒ ｐｒｉｍａｒｙ（ＸＹＺ、ＲＧＢＷなども可能）を通じて任意のカラーガマットを示すことができる。
色温度タイプ（ｃｏｌｏｒ＿ｔｅｍｐｅｒａｔｕｒｅ＿ｔｙｐｅ）情報は、マスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当する基準ｗｈｉｔｅに対する情報を示すことができる。例えば、Ｄ６５、Ｄ５０のような標準光源色温度であってもよく、必要によっては、ｗｈｉｔｅに対するＲＧＢ ｃｏｌｏｒ ｐｒｉｍａｒｙ（ＸＹＺ、ＲＧＢＷなども可能）のように色温度に対する代表性を帯びる任意の値を示してもよい。
ＤＲマッピングタイプ（ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、マスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当するダイナミックレンジマッピング情報の種類を示す。例えば、図２０の上段に示したように、ＨＥＶＣに含まれているＫｎｅｅ ｆｕｎｃｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅ又はＴｏｎｅ ｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅを指称することによって、他のＳＥＩメッセージの情報を参照することができる。また、予め約束されたＨＤＲ情報ディスクリプタ内に直接内容を記述することもできる。
ＣＧマッピングタイプ（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、マスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当するカラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）情報の種類を示す。例えば、図２０の下段に示したように、ＨＥＶＣに含まれているＣｏｌｏｕｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅに定義された情報を引用することができる。また、予め約束されたＨＤＲ情報ディスクリプタ内に直接内容を記述することもできる。
視聴環境タイプ（ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、マスタリングディスプレイ、チャネル、プログラム、コンテンツ、シーン、クリップまたはフレームに該当する視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）情報の種類を示す。例えば、ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｔｙｐｅ情報は、別途のＳＥＩメッセージとして定義されたｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎに定義された情報を引用してもよく、予め約束されたＨＤＲ情報ディスクリプタ内に直接内容を記述してもよい。
上述したｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ、ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ、ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｔｙｐｅに対して外部のＳＥＩメッセージを参考する場合、前記とは異なり、ＳＥＩメッセージのｐａｙｌｏａｄＴｙｐｅを直接シグナリングする方法を用いることもできる。例えば、Ｋｎｅｅ ｆｕｎｃｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅを参考する場合、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ＝０、ｐａｙｌｏａｄＴｙｐｅ＝１４１を通じてより具体的に知らせる方法を用いることもできる。
図２１は、本発明の一実施例に係る時間の流れに基づいてメタデータ情報をシグナリングする方法を示す。
時間によるメタデータの伝送は、１）毎フレームごとに当該情報を全て伝送する方法、２）ＲＡＰ内でメタデータが変更されて適用される区間の時点のフレーム内に伝送する方法、３）ＲＡＰなどの周期をもって周期内で適用されるメタデータを周期時点に一度に伝送する方法、４）適用時点と関連するＲＡＰの前に伝送する方法のように様々な方法を考慮することができる。また、１）〜４）の方法を混合して用いてもよい。
図２１は、ＲＡＰによってメタデータ情報をシグナリングする実施例を示す。ビデオ全体に適用される共通適用情報（ｃｏｍｍｏｎ ｔｙｐｅ）は、各ＲＡＰ毎に伝送され得る。これは、図２１でＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅが００００に設定された場合である。共通適用情報は繰り返される情報であるが、放送送信装置は、ＲＡＰ毎に共通適用情報を伝送することによって伝送誤りによる情報の損失を補完するようにすることができる。
場面によって異なって適用される情報を提供する必要がある場合、シーンメタデータ（Ｓｃｅｎｅ ｍｅｔａｄａｔａ）を用いて伝送することができる。これは、図２１でＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅが０１００に設定された場合である。この場合、ＲＡＰ時点に該当する情報、及びＲＡＰ内のシーンチェンジ（ｓｃｅｎｅ ｃｈａｎｇｅ）の後に適用される情報を共に伝送することができる。ＲＡＰ時点に該当する情報及びＲＡＰ内のシーンチェンジの後に適用される情報は、それぞれを互いに異なる役割を果たすｓｅｔとして定義することができ、互いに異なるｓｅｔ＿ｎｕｍｂｅｒが付与されることによって区分することができる。また、実施例によって、同じ場面に適用される情報でも、互いに異なる役割を果たす情報を分離して別途に伝達する場合、これを区分するための目的としても互いに異なるｓｅｔ＿ｎｕｍｂｅｒを使用することができる。もし、同じ情報が２つ以上のＲＡＰにわたって適用される場合には、同じｓｅｔ＿ｎｕｍｂｅｒを有し、細部情報のアップデートがない場合、同じｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒを設定することができる。ここで、細部情報の変更がある場合には異なるｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒを有するようにすることによって、メタデータプロセッサ（ｍｅｔａｄａｔａ ｐｒｏｃｅｓｓｏｒ）がどのｓｅｔに情報の変更があるかを確認し、アップデートするか否かを決定することができる。次のＲＡＰが到来すると、ｓｃｅｎｅ開始時点が新しいＲＡＰに変わるため、ｓｙｎｃ＿ｓｔａｒｔが新しいＲＡＰに変わって適用され得る。この場合、シンク区間の終了地点（ｓｙｎｃ＿ｓｔａｒｔ＋ｓｙｎｃ＿ｄｕｒａｔｉｏｎ）が同一である場合、情報の変更がないと見なし、同じｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒを適用することができる。
プログラム内で使用されるメタデータの適用時点と関連するＲＡＰが到来する前に適用情報を予め伝送する場合には、時間差、順序、フレームの数のように相対的な概念を通じて適用時点を知らせることができる。この場合、Ｓｙｎｃ＿ｓｔａｒｔ＝ＦＦＦＦのように予め約束されたシグナリング或いはＲＡＰよりも長い区間の長さでシグナリングする方法を用いて、当該ＲＡＰではなく後で適用されるメタデータであることを知らせることもできる。
図２１の００：００：００：００〜００：００：０２：００の区間で２番目のＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ＝０１００は、ｓｙｎｃ＿ｓｔａｒｔ＝０及びｓｙｎｃ＿ｄｕｒａｔｉｏｎ＝１８０に設定され、００：００：０２：００〜００：００：０４：００の区間で２番目のＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅ＝０１００は、ｓｙｎｃ＿ｓｔａｒｔ＝０及びｓｙｎｃ＿ｄｕｒａｔｉｏｎ＝６０に設定され得る。Ｓｔａｒｔ時点が００：００：００：００から００：００：０２：００に変わることによって、同一の情報（ｓｅｔ １，ｖｅｒ ０）に対してｄｕｒａｔｉｏｎを変更してシグナリングすることができる。同一の情報であることが確認される場合、受信機ではメタデータアップデート（ｍｅｔａｄａｔａ ｕｐｄａｔｅ）を行わない。
以前の情報と同じ役割を果たす情報に対して細部内容の変更がある場合、放送送信装置は、共通適用情報のｓｅｔ＿ｎｕｍｂｅｒは維持したまま、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒを増加させることができる。受信機のメタデータプロセッサ（ｍｅｔａｄａｔａ ｐｒｏｃｅｓｓｏｒ）は、変更されたｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒに基づいて情報の変更を認知することができ、既存の情報を新しい情報にアップデートすることができる。
図２１に示したように、００：００：０４：００〜００：００：０６：００の区間でメタデータ内の情報の変更がある場合、追加で開始時点などの情報を伝達することもできる。メタデータ内の情報の変更がある場合、例えば、図示のように、Ｂ情報がＢ’に変更されると、新しいバージョンナンバー（ｖｅｒｓｉｏｎ ｎｕｍｂｅｒ）を付与することができる。図面で００：００：０２：００〜００：００：０４：００の区間でｓｅｔ＿ｎｕｍｂｅｒ＝２に対するバージョンナンバーが０であったが、００：００：０４：００〜００：００：０６：００の区間ではバージョンナンバーが１に増加したことが確認できる。終了時点が変わる場合などにも、バージョンナンバーを通じて、アップデートされなければならないことを知らせることができる。
図２２は、本発明の他の実施例に係る時間の流れに基づいてメタデータ情報をシグナリングする方法を示す。図２２は、メタデータ情報をシグナリングするにおいて、ＨＤＲとＳＤＲとの間に切り替えがある場合を示す。図示のように、３番目のＲＡＰでＨＤＲビデオストリームはＳＤＲビデオストリームに切り替わり、この場合、３番目のＲＡＰの後にはＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）がこれ以上送受信されない。
ＨＤＲ情報ディスクリプタの伝送が中断される場合、放送送信装置は、ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇを介して受信機に知らせることができる。コンテンツのＤＲがＨＤＲからＳＤＲに切り替わる場合、ＨＤＲ／ＷＣＧコンテンツに対するビデオ特性を伝達していたＳＥＩメッセージの伝達が中断され、コンテンツの切り替え時点の後にこれ以上の情報が伝達されなくなり得る。勿論、ＳＤＲコンテンツに対してもマスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）情報、カラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ）のようにＨＤＲ情報ディスクリプタを使用する場合も発生し得るが、本例示では、ＨＤＲ情報ディスクリプタを使用しないｌｅｇａｃｙ ＳＤＲ ｃｏｎｔｅｎｔに対して考慮し得る。この場合、ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇをｏｎする時点、すなわち、１にセットする時点が重要であり、前記の例示のように切り替えが起こる時点の直前のフレーム及びそのフレームを含むＲＡＰ（図面において２番目のＲＡＰ）でｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇをｏｎにセットすることができる。
図２３は、本発明の一実施例に係るｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏを示した図である。図２０の上段で説明したｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅが０×０３に設定されると、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）がＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒ内で直接定義され得る。ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅが、マスタリングディスプレイ（Ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）又はビデオ（ｖｉｄｅｏ）と関連する共通適用情報としてチャネル、プログラムまたはコンテンツである場合、映像（チャネル、プログラムまたはコンテンツ）の全般にわたって図２２で説明する情報を使用することができ、部分適用情報としてシーンタイプ（ｓｃｅｎｅ ｔｙｐｅ）又はフレームタイプ（ｆｒａｍｅ ｔｙｐｅ）である場合、該当する区間に対して図２２で説明する情報を使用することができる。以下では、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）が含むフィールドについて説明する。
本発明の一実施例に係るｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）は、最大基準明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｍａｘ）、最小基準明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｍｉｎ）、任意のＥＯＴＦ情報（ｐｒｉｖａｔｅ＿ＥＯＴＦ）、ＥＯＴＦ係数個数情報（ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｅｆｆ）、ＥＯＴＦ係数情報（ｔｒａｎｓｆｅｒ＿ｃｕｒｖｅ＿ｃｏｅｆｆ［ｉ］）、クリッピングフラグ情報（ｃｌｉｐｐｉｎｇ＿ｆｌａｇ）、線形マッピングフラグ情報（ｌｉｎｅａｒ＿ｍａｐｐｉｎｇ＿ｆｌａｇ）、クリッピング最大明るさ範囲情報（ｌｕｍａ＿ｃｌｉｐｐｉｎｇ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）、クリッピング最小明るさ範囲情報（ｌｕｍａ＿ｃｌｉｐｐｉｎｇ＿ｌｏｗｅｒ＿ｂｏｕｎｄ）、最大明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）、最小明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｌｏｗｅｒ＿ｂｏｕｎｄ）、最大明るさデジタル値（ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ）、最小明るさデジタル値（ｌｕｍａ＿ｌｏｗｅｒ＿ｖａｌｕｅ）、核心領域変換曲線タイプ情報（ｍｉｄ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）、核心領域変換曲線細部情報（ｍｉｄ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））、核心明るさ範囲領域割合情報（ｍｉｄ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ）、上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）、上位領域変換曲線細部情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））、上位明るさ範囲領域割合情報（ｕｐｐｅｒ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ）、下位領域変換曲線タイプ情報（ｌｏｗｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）、下位領域変換曲線細部情報（ｌｏｗｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））、追加領域個数情報（ｎｕｍｂｅｒ＿ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ）、追加領域差情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ［ｉ］）、追加領域差デジタル値（ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ＿ｄｉｆｆ［ｉ］）、変更上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ［ｉ］）、変更上位領域変換曲線細部情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））、変更上位明るさ範囲領域割合情報（ｕｐｐｅｒ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ［ｉ］）及び／又は変更核心明るさ範囲領域割合情報（ｍｉｄ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ［ｉ］）を含むことができる。
最大基準明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｍａｘ）は、超高画質放送コンテンツで表現された最大基準明るさを示す。すなわち、明るさ範囲（ＤＲ）の最大値を示す。例えば、参照モニタ（ｒｅｆｅｒｅｎｃｅ ｍｏｎｉｔｏｒ）の場合、１００ｃｄ／ｍ２を最大基準明るさとして定めており、この場合、一般的な範囲を考慮して前記値を１００（１０進数）で割った値の商である１が伝送され得る。
最小基準明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｍｉｎ）は、超高画質放送コンテンツで表現された最小基準明るさを示す。すなわち、明るさ範囲（ＤＲ）の最小値を示す。例えば、参照モニタ（ｒｅｆｅｒｅｎｃｅ ｍｏｎｉｔｏｒ）の場合、０．０５ｃｄ／ｍ２を最小基準明るさとして定めており、この場合、一般的な範囲を考慮して前記値に１００（１０進数）を乗じた値である５が伝送され得る。
任意のＥＯＴＦ情報（ｐｒｉｖａｔｅ＿ＥＯＴＦ）は、任意のＥＯＴＦ関数が使用されるか否かを示す。一般的にＩＴＵ−Ｒ ＢＴ．１８８６、ＲＥＣ．７０９、ＢＴ．２０２０などのように広く使用されるＥＯＴＦが使用される場合には、ＶＵＩ情報によって伝達され得る。しかし、まだ標準として定められていないＥＯＴＦが使用される場合、当該フィールド値を１に設定して示すことができる。例えば、標準として定められていないＥＯＴＦ、すなわち、任意のＥＯＴＦとして知覚量子化（ｐｅｒｃｅｐｔｕａｌ ｑｕａｎｔｉｚａｔｉｏｎ）が使用されてもよい。
ＥＯＴＦ係数個数情報（ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｅｆｆ）は、任意のＥＯＴＦに使用された係数の個数を示す。
ＥＯＴＦ係数情報（ｔｒａｎｓｆｅｒ＿ｃｕｒｖｅ＿ｃｏｅｆｆ［ｉ］）は、任意のＥＯＴＦに使用された係数を示す。
クリッピングフラグ情報（ｃｌｉｐｐｉｎｇ＿ｆｌａｇ）は、クリッピングオプションが使用されるか否かを示す情報であって、クリッピングオプションの使用が許容される場合、１の値を有することができる。
線形マッピングフラグ情報（ｌｉｎｅａｒ＿ｍａｐｐｉｎｇ＿ｆｌａｇ）は、線形明るさ範囲変換（ｌｉｎｅａｒ ｄｙｎａｍｉｃ ｒａｎｇｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎ）方法が使用されるか否かを示す。線形明るさ範囲変換（ｌｉｎｅａｒ ｄｙｎａｍｉｃ ｒａｎｇｅ ｔｒａｎｓｆｏｒｍａｔｉｏｎ）方法が使用される場合、１の値を有する。
クリッピング最大明るさ範囲情報（ｌｕｍａ＿ｃｌｉｐｐｉｎｇ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）は、クリッピングオプションが使用される場合にディスプレイされる明るさ範囲（ＤＲ）で上位臨界点に対するデジタル値（ｄｉｇｔａｌ ｖａｌｕｅ）を示す。
クリッピング最小明るさ範囲情報（ｌｕｍａ＿ｃｌｉｐｐｉｎｇ＿ｌｏｗｅｒ＿ｂｏｕｎｄ）は、クリッピングオプションが使用される場合にディスプレイされる明るさ範囲（ＤＲ）で下位臨界点に対するデジタル値（ｄｉｇｔａｌ ｖａｌｕｅ）を示す。
最大明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）は、超高画質放送コンテンツで表現された明るさ範囲において必須に表現されなければならない明るさ範囲の最大値（ｎｉｔ単位）を示す。最大明るさ情報は、受信装置のディスプレイの種類を判断する基準となり得る。また、受信装置のディスプレイの種類を判断する別途の基準をシグナリングすることができる。
最小明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｌｏｗｅｒ＿ｂｏｕｎｄ）は、超高画質放送コンテンツで表現された明るさ範囲において必須に表現されなければならない明るさ範囲の最小値（ｎｉｔ単位）を示す。最小明るさ情報は、受信装置のディスプレイの種類を判断する基準となり得る。また、受信装置のディスプレイの種類を判断する別途の基準をシグナリングすることができる。
最大明るさデジタル値（ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ）は、最大明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）に該当するデジタル値（ｄｉｇｉｔａｌ ｖａｌｕｅ）を示す。
最小明るさデジタル値（ｌｕｍａ＿ｌｏｗｅｒ＿ｖａｌｕｅ）は、最小明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｌｏｗｅｒ＿ｂｏｕｎｄ）に該当するデジタル値（ｄｉｇｉｔａｌ ｖａｌｕｅ）を示す。
核心領域変換曲線タイプ情報（ｍｉｄ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）は、核心明るさ範囲領域で使用される明るさ範囲変換曲線を識別する。変換曲線は、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）、Ｓ曲線（ｓ ｃｕｒｖｅ）、ログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）、多数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）及びＬＵＴ（Ｌｏｏｋ Ｕｐ Ｔａｂｌｅ）のいずれか１つを使用することができる。
核心領域変換曲線細部情報（ｍｉｄ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））は、核心領域変換曲線タイプ情報（ｍｉｄ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）によって識別された変換曲線による追加情報を示す。例えば、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）が使用される場合、勾配情報が伝送され得、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）やログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）が使用される場合、底に関する情報が伝送され得、Ｓ曲線（ｓ ｃｕｒｖｅ）が使用される場合、変曲点の座標及び各区間に対する底とｙ切片に関する情報が伝送され得、複数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）が使用される場合、各区間のｘ座標、各区間の曲線の種類及び当該グラフに関する情報が伝送され得る。
核心明るさ範囲領域割合情報（ｍｉｄ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ）は、超高画質放送コンテンツの明るさ範囲における核心明るさ範囲領域が受信装置のディスプレイの全体明るさ範囲（ＤＲ）において占める割合を示す。
上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）は、上位明るさ範囲領域で使用される明るさ範囲変換曲線を識別する。変換曲線は、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）、Ｓ曲線（ｓ ｃｕｒｖｅ）、ログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）、多数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）及びＬＵＴ（Ｌｏｏｋ Ｕｐ Ｔａｂｌｅ）のいずれか１つを使用することができる。
上位領域変換曲線細部情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））は、上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）によって識別された変換曲線による追加情報を示す。例えば、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）が使用される場合、勾配情報が伝送され得、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）やログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）が使用される場合、底に関する情報が伝送され得、Ｓ曲線（ｓ ｃｕｒｖｅ）が使用される場合、変曲点の座標及び各区間に対する底とｙ切片に関する情報が伝送され得、多数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）が使用される場合、各区間のｘ座標、各区間の曲線の種類及び当該グラフに関する情報が伝送され得る。
上位明るさ範囲領域割合情報（ｕｐｐｅｒ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ）は、超高画質放送コンテンツの明るさ範囲における上位明るさ範囲領域が受信装置のディスプレイの全体明るさ範囲（ＤＲ）において占める割合を示す。
下位領域変換曲線タイプ情報（ｌｏｗｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）は、下位明るさ範囲領域で使用される明るさ範囲変換曲線を識別する。変換曲線は、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）、Ｓ曲線（ｓ ｃｕｒｖｅ）、ログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）、多数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）及びＬＵＴ（Ｌｏｏｋ Ｕｐ Ｔａｂｌｅ）のいずれか１つを使用することができる。
下位領域変換曲線細部情報（ｌｏｗｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））は、下位領域変換曲線タイプ情報（ｌｏｗｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ）によって識別された変換曲線による追加情報を示す。例えば、線形曲線（ｌｉｎｅａｒ ｃｕｒｖｅ）が使用される場合、勾配情報が伝送され得、指数曲線（ｅｘｐｏｎｅｎｔｉａｌ ｃｕｒｖｅ）やログ曲線（ｌｏｇａｒｉｔｈｍｉｃ ｃｕｒｖｅ）が使用される場合、底に関する情報が伝送され得、Ｓ曲線（ｓ ｃｕｒｖｅ）が使用される場合、変曲点の座標及び各区間に対する底とｙ切片に関する情報が伝送され得、多数の曲線が組み合わされた曲線（ｃｏｍｂｉｎａｔｉｏｎ ｃｕｒｖｅ）が使用される場合、各区間のｘ座標、各区間の曲線の種類及び当該グラフに関する情報が伝送され得る。
追加領域個数情報（ｎｕｍｂｅｒ＿ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ）は、核心明るさ範囲領域を拡張するために使用される変数の個数を示す。
追加領域差情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ［ｉ］）は、超高画質放送コンテンツでｉ＋１番目の明るさ値を構成するための差値を示す。既存の明るさ範囲より広い明るさ範囲を有するが、超高画質放送コンテンツで表現された明るさ範囲を全て受容できないディスプレイ（ケース２）で核心明るさ範囲領域を拡張する場合、最大明るさ情報（ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ）は、ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＋ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ［０］＋…＋ｌｕｍｉｎａｎｃｅ＿ｕｐｐｅｒ＿ｂｏｕｎｄ＿ｄｉｆｆ［ｉ］が示す値に変更され得る。
追加領域差デジタル値（ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ＿ｄｉｆｆ［ｉ］）は、超高画質放送コンテンツでｉ＋１番目の明るさ値に対するデジタル値（ｄｉｇｉｔａｌ ｖａｌｕｅ）を示す。既存の明るさ範囲より広い明るさ範囲を有するが、超高画質放送コンテンツで表現された明るさ範囲を全て受容できないディスプレイ（ケース２）で核心明るさ範囲領域を拡張する場合、最大明るさデジタル値（ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ）は、ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ＋ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ＿ｄｉｆｆ［０］＋…＋ｌｕｍａ＿ｕｐｐｅｒ＿ｖａｌｕｅ＿ｄｉｆｆ［ｉ］が示す値に変更され得る。
変更上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ［ｉ］）は、ｉ＋１番目の明るさ範囲をサポートする場合、変更された上位明るさ範囲領域で使用される変換曲線を識別することができる。すなわち、変更上位領域変換曲線タイプ情報は、核心明るさ範囲領域が拡張される場合、これに従って変更された上位明るさ範囲領域で使用される変換曲線を識別することができる。
変更上位領域変換曲線細部情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ（））は、変更上位領域変換曲線タイプ情報（ｕｐｐｅｒ＿ＤＲ＿ｔｒａｎｓｆｏｒｍａｔｉｏｎ＿ｃｕｒｖｅ＿ｔｙｐｅ［ｉ］）によって識別された変換曲線による追加情報を示す。すなわち、ｉ＋１番目の明るさ範囲をサポートする場合、変更された上位明るさ範囲領域で使用される変換曲線に対する細部事項を示す。
変更上位明るさ範囲領域割合情報（ｕｐｐｅｒ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ［ｉ］）は、超高画質放送コンテンツの核心明るさ範囲領域が変更される場合、これに従って変更された上位明るさ範囲領域が受信装置のディスプレイの全体明るさ範囲（ＤＲ）において占める割合を示す。
変更核心明るさ範囲領域割合情報（ｍｉｄ＿ＤＲ＿ｐｅｒｃｅｎｔａｇｅ［ｉ］）は、超高画質放送コンテンツの核心明るさ範囲領域が変更される場合、変更された核心明るさ範囲領域が受信装置のディスプレイの全体明るさ範囲（ＤＲ）において占める割合を示す。
図２４は、本発明の一実施例に係るＨＥＶＣ内に定義されたＳＥＩメッセージを参照する場合を示す。図２０の下段で説明したｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅが０×００に設定されると、ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）がＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒ内に直接定義されず、ＨＥＶＣに定義されたＳＥＩメッセージを参照することができる。ここで、ＳＥＩメッセージは、ＨＥＶＣに定義されたｃｏｌｏｕｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅ ｓｙｎｔａｘに従うことができる。
ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅがマスタリングディスプレイ（Ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）又はビデオ（ｖｉｄｅｏ）と関連する共通適用情報としてチャネル、プログラムまたはコンテンツである場合、映像（チャネル、プログラムまたはコンテンツ）の全般にわたって参照された情報を使用することができ、部分適用情報としてシーンタイプ（ｓｃｅｎｅ ｔｙｐｅ）又はフレームタイプ（ｆｒａｍｅ ｔｙｐｅ）である場合、該当する区間にのみ参照された情報を適用することができる。
図２５及び図２６は、本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＰＭＴを介してシグナリングする実施例を示す。ＰＭＴは、プログラムマッピングテーブル（ｐｒｏｇｒａｍ ｍａｐｐｉｎｇ ｔａｂｌｅ）を意味し、テーブル識別子情報、セクションシンタックス指示子情報、セクション長情報、プログラム番号情報、バージョン番号情報、ｃｕｒｒｅｎｔ＿ｎｅｘｔ指示子情報、セクション番号情報、ＰＣＲ＿ＰＩＤ情報、ｐｒｏｇｒａｍ ｉｎｆｏ長情報、第１ディスクリプタ情報、ストリームタイプ情報、基本ＰＩＤ（ｅｌｅｍｅｎｔａｒｙ ＰＩＤ）情報、エレメンタリストリーム情報長（Ｅｓ＿ｉｎｆｏ＿ｌｅｎｇｔｈ）情報、第２ディスクリプタ情報、ＣＲＣ情報などを含むことができる。第１ディスクリプタ情報は、ｐｒｏｇｒａｍ ｉｎｆｏ長情報に後続する１番目のループに含まれたディスクリプタ情報を示すことができ、第２ディスクリプタ情報は、エレメンタリストリーム情報長情報に後続する２番目のループに含まれたディスクリプタ情報を示すことができる。
本発明の一実施例に係るＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴに含まれた第１ディスクリプタ情報内に含まれてシグナリングされ得、前述したＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴに含まれた第２ディスクリプタ情報内に含まれてシグナリングされ得る。
ＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒは、図２６の上段に示したように、ディスクリプタタグ（ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ）情報、ディスクリプタ長（ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ）情報及びサービスタイプ情報（ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅ）のうちの少なくとも１つを含むことができる。ここで、サービスタイプ情報（ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅ）は、図２６の下段に示したように、ＵＨＤサービスの種類を示すことができる。例えば、サービスタイプ情報は、ＵＨＤ１（４Ｋ）、ＵＨＤ２（８Ｋ）、またはｑｕａｌｉｔｙによる区分など、ユーザが指定したＵＨＤサービスの種類を示すことができる。これを通じて、受信機に様々なＵＨＤサービスを提供することができる。本発明の場合、ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅ＝１１００（ＵＨＤ１ ｓｅｒｖｉｃｅ ｗｉｔｈ ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｍｅｔａｄａｔａ、４Ｋの例）に指定して、ビデオ、シーン、クリップまたはフレームなどの互いに異なる段階又は単位に対するＨＤＲ情報（ＨＤＲ ｉｎｆｏ）が提供されることを示すことができる。
図２７及び図２８は、本発明の一実施例に係るＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒをＥＩＴを介してシグナリングする実施例を示す。ＡＴＳＣ及びＤＶＢシステムは、シグナリングテーブルとしてＥＩＴを含むことができ、その中に含まれたシンタックスは、図２７及び図２８の通りである。
本発明の一実施例に係るＡＴＳＣ及びＤＶＢシステムのＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）は、共通にｔａｂｌｅ＿ｉｄフィールド、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド、ｓｏｕｒｃｅ＿ｉｄ（ｓｅｒｖｉｃｅ＿ｉｄ）フィールド、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールド、ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールド、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド、ｎｕｍ＿ｅｖｅｎｔｓ＿ｉｎ＿ｓｅｃｔｉｏｎ（ｓｅｇｍｅｎｔ＿ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ）フィールド、ｅｖｅｎｔ＿ｉｄフィールド、ｓｔａｒｔ＿ｔｉｍｅフィールド、ｌｅｎｇｔｈ＿ｉｎ＿ｓｅｃｏｎｄｓ（ｄｕｒａｔｉｏｎ）フィールド、ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈフィールド、ｄｅｓｃｒｉｐｔｏｒ（）フィールド及び／又はＣＲＣ＿３２フィールドを含むことができる。
ｔａｂｌｅ＿ｉｄフィールドは、当該テーブルがＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）であることを識別する。ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＭＰＥＧ−２ ｐｒｉｖａｔｅ＿ｓｅｃｔｉｏｎ ｔａｂｌｅのロング（ｌｏｎｇ）形態を示すために１にセットされる１ビットフィールドである。ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、このフィールドの後にあるテーブルセクションの長さをバイト数で示す。ｓｏｕｒｃｅ＿ｉｄフィールドは、当該セクションで記述されるイベントを伝送する仮想チャネルのソースＩＤ（ｓｏｕｒｃｅ ｉｄ）を示す。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、テーブルのバージョン番号を示す５ビットフィールドである。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、１ビットフィールドであって、このテーブルが現在適用可能であるか、それとも次に適用可能であるかを示す。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、セクションの番号を示す。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、最後のセクションの番号を識別する。ｎｕｍ＿ｅｖｅｎｔｓ＿ｉｎ＿ｓｅｃｔｉｏｎフィールドは、当該テーブルセクションに含まれたイベントの個数を示す。ｅｖｅｎｔ＿ｉｄフィールドは、記述されたイベントを示す特定の数字を識別する。ｓｔａｒｔ＿ｔｉｍｅフィールドは、当該イベントの開始時間をＧＰＳセカンドを基準として示す。仮想チャネルでイベントの開始時間を示す値は、放映中のイベントの終了時間を示す値よりも大きくなり得る。イベントの終了時間は、イベントの開始時間とイベントの長さを時間で表した値との和として定義できる。ｌｅｎｇｔｈ＿ｉｎ＿ｓｅｃｏｎｄｓ（ｄｕｒａｔｉｏｎ）フィールドは、イベントの持続時間を秒単位で示す。ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈフィールドは、後続して記述されるイベントディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ（））の全長を示す。ｄｅｓｃｒｉｐｔｏｒ（）は、テーブル内に位置するディスクリプタループ（ｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐ）である。ディスクリプタループ（ｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐ）は、追加的なディスクリプタを含むことができる。ＥＩＴ内には、０個以上のディスクリプタが含まれてもよく、当該ディスクリプタは、各イベント毎に適用される情報を記述するイベントレベルディスクリプタ（ｅｖｅｎｔ ｌｅｖｅｌ ｄｅｓｃｒｉｐｔｏｒ）に該当し得る。本発明の一実施例によって、ＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ及びＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒは、イベントレベルディスクリプタに含まれて伝送されてもよい。ＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒは、ＵＨＤサービスの種類を区分するために使用することができ、ＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒは、イベントレベル（ｅｖｅｎｔ ｌｅｖｅｌ）でＨＤＲ映像情報メタデータが含まれているか否かを確認することができ、受信機で受容可能であるか否かを判断するために使用することができる。ケーブル放送の場合、前記ディスクリプタの代わりに、ＡＥＩＴに同じ情報を提供することができる。
ＣＲＣ＿３２フィールドは、データの無欠性をチェックできるＣＲＣ値を含む。ＣＲＣ値は、ＥＩＴセクション全体が処理された後、Ａｎｎｅｘ Ａ ｏｆ ＩＳＯ−１３８１８−１ “ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ”に定義されているデコーダ内のレジスタから０値が出力されることを保証することができる。
ＥＩＴを介してシグナリングされるＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒのＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅが１１００に設定されると、受信機は、適正視聴環境に対する情報がメタデータを介して伝達されることを確認できる。例えば、ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅが１１００である場合、受信機は、当該サービスがＵＨＤ１ ｓｅｒｖｉｃｅ ｗｉｔｈ ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｍｅｔａｄａｔａ、４Ｋであることを確認できる。
ＥＩＴを介してシグナリングされるＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒのＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅが００００に設定されると、受信機は、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）が存在するか否かを確認し、ビデオ、シーンまたはフレームなどの互いに異なる段階又は単位に対するＨＤＲ情報（ＨＤＲ ｉｎｆｏ）が提供されることを知ることができる。ここで、ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅが００００であると、ＵＨＤ１サービスであることを示すことができる。
上述した場合に対して、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）を用いて、コンテンツ供給者が望むマスタリングディスプレイ、コンテンツ、シーンまたはフレーム単位の情報を視聴者のディスプレイで活用できるかを判断することができる。これを用いて、現在又は未来の時点で再生されるコンテンツに対してコンテンツ、シーンまたはフレーム単位のメタデータが使用されるか否かを予め判断することができ、予約録画などの状況のためのセッティングを受信機で予め準備することができる効果がある。
図２９は、本発明の他の実施例に係るＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）を示す。一つのイベント（ｅｖｅｎｔ）に対して複数の情報が存在し得る。すなわち、コンテンツに情報が一貫して適用されるものではなく、時間によって、又は挿入されたコンテンツの有無などによって適用される情報が変換され得る。または、一つのコンテンツに対して制作者が意図する様々なモードをサポートすることもできる。このとき、受信機のディスプレイでこのようなモードを受容可能であるかを判断する必要があり、これに関する情報は、放送送信装置によってｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｍｅｔａｄａｔａを介して提供され得る。ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｍｅｔａｄａｔａ内のシンタックスは、ＳＥＩメッセージの視聴環境ディスクリプタタ（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）の定義に従うことができる。
ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒは、図２９の上端に示したように、ディスクリプタタグ（ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ）情報、ディスクリプタ長（ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ）情報、及び情報の個数（ｎｕｍｂｅｒ＿ｏｆ＿ｉｎｆｏ）情報のうちの少なくとも１つを含むことができる。ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒはループを含むことができ、ｎｕｍｂｅｒ＿ｏｆ＿ｉｎｆｏが指示する個数だけのＨＤＲ＿ｉｎｆｏ＿ｍｅｔａｄａｔａ（）を含むことができる。ＨＤＲ＿ｉｎｆｏ＿ｍｅｔａｄａｔａ（）のシンタックスは、図１７のＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）構成の実施例のスクリプト又はその一部が伝達され得る。
図３０は、本発明の一実施例に係る受信機のブロック図及び動作方法を示す。前述した方法を通じてＨＤＲ情報（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ）が伝送される場合、受信機でシグナルを分析し、これに基づいてＨＤＲ映像に情報を適用するプロセスは、次の通りである。
本発明の一実施例に係る受信機は、チューナー及びデモジュレータ１６０１を用いてＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルから放送信号を受信することができる。図示していないが、放送信号は、ＲＦチャネルだけでなく、他の経路でも受信することができる。例えば、放送信号は、ＩＰベースの放送／通信、有／無線通信、有／無線インターフェースを介して受信されてもよい。また、放送信号及び後述するメタデータは、互いに異なる経路で受信されてもよい。後述するメタデータは、放送信号だけでなく、他の経路（例えば、ＩＰベースの放送／通信、有／無線通信、有／無線インターフェース、近距離無線通信など）でも送受信可能である。
受信機は、チャネルデコーダ１６０２を用いて、受信された放送信号をデコードすることができる。ここで、チャネルデコーダは、ＶＳＢ又はＱＡＭ方式を用いてデコードすることができる。デコードされた放送信号は、デマルチプレクサ１６０３によって放送コンテンツデータ及びシグナリングデータに逆多重化することができる。放送コンテンツデータは、ＨＤＲビデオデータを含むことができ、ビデオデコーダ１６０５によってデコードすることができる。シグナリングデータは、放送コンテンツデータに関する情報を含むことができ、実施例によって、ＰＭＴ、ＶＣＴ、ＥＩＴ、ＳＤＴなどのシグナリングテーブル又はシグナリング情報を含むことができる。受信機は、セクションデータプロセッサ１６０４を用いてシグナリング情報（例えば、ＰＭＴ）からＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒを抽出することができる。
受信機は、ＵＨＤ＿ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒを用いて、原本ＵＨＤＴＶ放送を構成するために追加で受信しなければならない別途のサービスやメディアがあるかを把握する。本発明の実施例では、受信機が、ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅ＝１１００であることを受信する場合、ＳＥＩメッセージを通じて追加情報があることを把握できる。または、受信機は、ＵＨＤ＿ｓｅｒｖｉｃｅ＿ｔｙｐｅ＝００００（８Ｋは０００１）を受信した後、ＥＩＴを介して、ＳＥＩメッセージを通じたビデオ関連追加情報があることを把握できる。
追加情報が存在することを確認した受信機は、ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅ又はＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅに基づいて、追加情報が適用される範囲がチャネル単位であるか、プログラム単位であるか、コンテンツ単位であるか、シーン、クリップ又はフレームであるかを区分することができる。また、各場合に対して追加情報が適用される範囲を同期化するために、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、追加情報の開始時点及び終了時点に関する情報を含むことができる。本発明の一実施例では、ビデオフレーム（ｖｉｄｅｏ ｆｒａｍｅ）を基準として同期化するための情報であるｓｙｎｃ＿ｉｎｆｏ＿ｔｙｐｅ、ｓｙｎｃ＿ｓｔａｒｔ、及びｓｙｎｃ＿ｄｕｒａｔｉｏｎを例示として用いた。また、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＨＤＲの終了時点を示すｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ情報を含むことができる。
また、ＨＤＲ＿ｉｎｆｏ＿ｔｙｐｅがコンテンツ（ｃｏｎｔｅｎｔ）全般に対して適用される情報である場合、シグナリング情報は、ＨＤＲ＿ｖｉｄｅｏ＿ｅｎｈａｎｃｅｍｅｎｔ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｔｙｐｅを介して、追加的にシーン、クリップ、フレームの単位の情報が提供されるか否かをシグナリングすることができる。これを通じて、受信機は、後でシーン、クリップまたはフレーム単位の情報が提供されることを予め知ることができ、シーン、クリップまたはフレーム単位のメタデータ処理及びＨＤＲ映像画質改善のためのセッティングを予め行うことができる。
受信機は、シグナリング情報を介してダイナミックレンジ（ｄｙｎａｍｉｃ ｒａｎｇｅ）を表現できる情報として高コントラストに関する情報や明るさを示す情報の種類を、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅを通じて把握することができる。例えば、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅは、高コントラスト情報としてアスペクト比（ａｓｐｅｃｔ ｒａｔｉｏ）、ｆ−ｓｔｏｐを指示するか、または明るさ情報としてｐｅａｋ ｌｕｍｉｎａｎｃｅ、ｍｉｎｉｍｕｍ ｌｕｍｉｎａｎｃｅなどを指示することができる。各タイプによるバリューは、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｖａｌｕｅ［ｉ］を介して受信機に伝達することができる。特に、本発明の一実施例によれば、コンテンツ（ｃｏｎｔｅｎｔ）、マスタリングディスプレイ（ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ）、フレーム（ｆｒａｍｅ）、シーン（ｓｃｅｎｅ）の特徴によるダイナミックレンジ情報をそれぞれ示すことができ、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅを通じて明るさをさらに細分化して示すことができる。これと共に、受信機は、カラー符号化（ｃｏｌｏｒ ｅｎｃｏｄｉｎｇ）に使用されたＥＯＴＦの種類、カラーガマット（ｃｏｌｏｒ ｇａｍｕｔ）の種類、及び色温度（ｃｏｌｏｒ ｔｅｍｐｅｒａｔｕｒｅ）の種類を、それぞれｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ｔｙｐｅ、ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ、及びｃｏｌｏｒ＿ｔｅｍｐｅｒａｔｕｒｅ＿ｔｙｐｅを通じて把握することができる。
ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、追加的な情報として、ダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）、カラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境情報（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）などを受信機に提供することができる。追加的な情報を様々な方法で提供できる場合、それぞれに対してｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ、ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ＿ｔｙｐｅ、ｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ＿ｔｙｐｅを通じてＨＥＶＣ内に定義されたＳＥＩメッセージ又は予め約束されたＳＥＩメッセージを指定することができる。ＨＤＲ＿ｉｎｆｏ ｄｅｓｃｒｉｐｔｏｒ内で追加情報を直接定義する場合、受信機は、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）、ｃｏｌｏｒ＿ｇａｍｕｔ＿ｍａｐｐｉｎｇ＿ｉｎｆｏ（）、及びｖｉｅｗｉｎｇ＿ｃｏｎｄｉｔｉｏｎ＿ｉｎｆｏ（）を通じて細部情報を把握することができる。
上述したシグナリング情報は、受信機のメタデータプロセッサ１６０６に格納することができる。格納されたシグナリング情報は、前述したセット番号（ｓｅｔ ｎｕｍｂｅｒ）又はバージョン（ｖｅｒｓｉｏｎ）が変更される場合にアップデートされ得る。受信機は、シンクロナイザ１６０７を用いて、メタデータプロセッサ１６０６に格納された画質改善情報が適用単位によってビデオデータに適用され得るように、画質改善情報（シグナリング情報）とビデオデータを同期化することができる。
受信機は、与えられた情報に基づいてコンテンツ、シーンまたはフレーム単位のダイナミックレンジ情報をＨＤＲアルゴリズム又は既存の後処理部（ｐｏｓｔ−ｐｒｏｃｅｓｓｉｎｇ ｍｏｄｕｌｅ）１６０８のような画質改善部に伝達して画質を向上させることができる。また、受信機は、ダイナミックレンジマッピン（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）、カラーガマットマッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）、視聴環境情報（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）と関連する細部情報がある場合、トーンマッピング（ｔｏｎｅ ｍａｐｐｉｎｇ）、カラーマッピング（ｃｏｌｏｒ ｍａｐｐｉｎｇ）、色補正（ｃｏｌｏｒ ｃｏｒｒｅｃｔｉｏｎ）、ホワイトバランス（ｗｈｉｔｅ ｂａｌａｎｃｅ）などのように関連するモジュールを直接連結して画質を向上させることができる。もし、受信機の内部で映像処理がｌｉｎｅａｒ ｌｕｍｉｎａｎｃｅ ｄｏｍａｉｎで行われる場合、ｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ｔｙｐｅを通じて把握したＥＯＴＦを適用することができる。
受信機は、後処理されたＨＤＲビデオをディスプレイ部１６０９を介して表示し、ユーザに提供することができる。
図３１は、本発明の一実施例に係るＨＤＲ情報ディスクリプタを示す。本発明で提示するＨＤＲ情報（ｉｎｆｏｒｍａｔｉｏｎ）をより正確に適用するためには、入力ビデオフォーマット（ｉｎｐｕｔ ｖｉｄｅｏ ｆｏｒｍａｔ）及び出力ビデオフォーマット（ｏｕｐｕｔ ｖｉｄｅｏ ｆｏｒｍａｔ）について詳述する必要がある。すなわち、放送信号送信装置は、ビデオデータに対するプロセッシングの前及びプロセッシング後に適用されるビデオフォーマットに関する情報を追加的にシグナリングすることによって、放送信号受信装置がより正確なカラーマッピングを行うことができる。図示された情報は、図１７で説明したＨＤＲ情報ディスクリプタに含まれた情報と共に追加的に当該ディスクリプタに含まれ得る。図示された情報は、本実施例のように、ＳＥＩメッセージ内の全てのＨＤＲビデオプロセッシング（ｖｉｄｅｏ ｐｒｏｃｅｓｓｉｎｇ）に同一に適用することができる。また、それぞれのＨＤＲビデオプロセッシング、例えば、色相表現マッピング（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ）及びダイナミックレンジマッピング（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ）にそれぞれ定義されて、互いに異なる入力／出力（ｉｎｐｕｔ／ｏｕｔｐｕｔ）特性を定義することもできる。
入力色空間タイプ情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）は、本発明で伝達するＨＤＲビデオプロセッシングの対象となる映像に関する情報のうち、カラー表現の基準を示すことができる。カラー表現の基準としては、ＲＧＢ、ＹＣｂＣｒ、ｘｖＹＣＣ、ＸＹＺなどを使用することができる。すなわち、入力色空間タイプ情報が００００に設定される場合、カラー表現の基準がＲＧＢであることを示し、０００１である場合にＹＣｂＣｒ、００１０である場合にｘｖＹＣＣ、００１１である場合にＸＹＺであることを示すことができる。０１００〜１１１１である場合は、将来の使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）され得る。また、入力色空間タイプ情報は、カラーガマットタイプ情報（ｃｏｌｏｒ ｇａｍｕｔ ｔｙｐｅ）と共に使用され得る。例えば、入力色空間タイプ情報（ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）がＲＧＢであり、カラーガマットタイプ情報（ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ）がＢＴ．２０２０一定輝度（ｃｏｎｓｔａｎｔ ｌｕｍｉｎａｎｃｅ）である場合、映像がＢＴ．２０２０ ＣＬベースのＲＧＢで表現されたことを示すことができる。
入力色相精度情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｐｒｅｃｉｓｉｏｎ）は、カラー表現の正確度を示し、必要であれば、入力色空間タイプ情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）と連動して使用されてもよい。例えば、ＲＧＢの場合、同じ色に対しても１０ビット／１２ビット／１４ビットのように異なる精度で表現することができる。または、浮動小数点（ｆｌｏａｔｉｎｇ ｐｏｉｎｔ）で示す必要がある場合、少数点以下の何桁まで精度を有するかについて示すこともできる。
出力色空間タイプ情報（Ｏｕｔｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）は、入力色空間タイプ情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）と反対の概念であって、ＨＤＲビデオプロセッシングの後にターゲットとする最終カラー表現の基準を示す。カラー表現の基準としては、ＲＧＢ、ＹＣｂＣｒ、ｘｖＹＣＣ、ＸＹＺなどを使用することができる。すなわち、出力色空間タイプ情報が００００に設定される場合、カラー表現の基準がＲＧＢであることを示し、０００１である場合にＹＣｂＣｒ、００１０である場合にｘｖＹＣＣ、００１１である場合にＸＹＺであることを示すことができる。０１００〜１１１１である場合は、将来の使用のためにリザーブド（ｒｅｓｅｒｖｅｄ）され得る。出力色相精度情報（Ｏｕｔｐｕｔ＿ｃｏｌｏｒ＿ｐｒｅｃｉｓｉｏｎ）はカラー表現の正確度を示し、必要であれば、出力色空間タイプ情報（Ｏｕｔｐｕｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）と連動して使用されてもよい。出力色相精度情報に対する実施例は、入力色相精度情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｐｒｅｃｉｓｉｏｎ）の実施例と同一に適用することができる。プロセッシング色空間タイプ情報（ｐｒｏｃｅｓｓｉｎｇ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）は、ＨＤＲビデオプロセッシングが行われる色空間（Ｃｏｌｏｒ ｓｐａｃｅ）を示す。一般的にＸＹＺのような中立色空間を使用することができるが、特定の色空間（ｃｏｌｏｒ ｓｐａｃｅ）を指定して使用してもよい。プロセッシング色空間としては、ＸＹＺ、ＹＣｂＣｒ（ＢＴ．２０２０，ｎｏｎ−ＣＬ）、ＹＣｂＣｒ（ＢＴ．２０２０，ＣＬ）、ＣＩＥ Ｌ＊ａ＊ｂ＊、及びＹＵＶを使用することができる。すなわち、プロセッシング色空間タイプ情報の値が００００に設定された場合にＸＹＺ、０００１に設定された場合にＹＣｂＣｒ（ＢＴ．２０２０，ｎｏｎ−ＣＬ）、００１０に設定された場合にＹＣｂＣｒ（ＢＴ．２０２０，ＣＬ）、００１１に設定された場合にＣＩＥ Ｌ＊ａ＊ｂ＊、及び０１００に設定された場合にＹＵＶが色空間タイプとして指定され得る。
プロセッシング色相精度情報（Ｐｒｏｃｅｓｓｉｎｇ＿ｃｏｌｏｒ＿ｐｒｅｃｉｓｉｏｎ）はカラー表現の正確度を示し、必要であれば、プロセッシング色空間タイプ情報（ｐｒｏｃｅｓｓｉｎｇ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）と連動して使用することができる。これに対する実施例は、入力色相精度情報（Ｉｎｐｕｔ＿ｃｏｌｏｒ＿ｐｒｅｃｉｓｉｏｎ）の実施例と同一に適用することができる。
ＨＤＲ情報ディスクリプタは、ターゲット情報をさらに含むことができる。ダイナミックレンジ情報に対してターゲット情報は、ＨＤＲ情報ディスクリプタを介して当該フレーム／場面の画質改善を追求するときに目標（ｔａｒｇｅｔ）となる結果に関する情報を示す。ここで、目標は、ビデオフォーマットまたは目標となるディスプレイなどであってもよい。
ターゲット情報は、次のような要素を含むことができる。ターゲットダイナミックレンジ情報タイプ個数（Ｎｕｍｂｅｒ＿ｏｆ＿ｔａｒｇｅｔ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、ターゲットダイナミックレンジ情報タイプの個数を示すことができる。ターゲットダイナミックレンジ情報タイプ（ｔａｒｇｅｔ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ）情報は、ＨＤＲビデオプロセッシングがターゲットとするダイナミックレンジ情報の種類を定義することができる。これに対して、ターゲットダイナミックレンジ情報バリュー（ｔａｒｇｅｔ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｖａｌｕｅ）情報は、ターゲットダイナミックレンジ情報タイプ情報が定義した情報に対する具体的な値を示すことができる。ターゲット変換関数タイプ情報（ｔａｒｇｅｔ＿ｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ｔｙｐｅ）、ターゲットカラーガマットタイプ情報（ｔａｒｇｅｔ＿ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ）、及びターゲットカラー温度タイプ情報（ｔａｒｇｅｔ＿ｃｏｌｏｒ＿ｔｅｍｐｅｒａｔｕｒｅ＿ｔｙｐｅ）は、それぞれターゲットとする変換関数の種類、カラーガマットの種類、カラー温度の種類に関する情報を示すことができる。これらの情報は、前述したＮｕｍｂｅｒ＿ｏｆ＿ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｔｙｐｅ、ｄｙｎａｍｉｃ＿ｒａｎｇｅ＿ｉｎｆｏ＿ｖａｌｕｅ、ｔｒａｎｓｆｅｒ＿ｆｕｎｃｔｉｏｎ＿ ｔｙｐｅ、ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ、及びｃｏｌｏｒ＿ｔｅｍｐｅｒａｔｕｒｅ＿ｔｙｐｅに対応する意味を有することができる。ここで、既存に定義した値は、ＨＤＲビデオプロセッシングの対象となる映像のダイナミックレンジ（ｄｙｎａｍｉｃ ｒａｎｇｅ）、カラーガマット（ｃｏｌｏｒ ｇａｍｕｔ）、及び変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）を示すものと意味を具体化して適用できる。
図３２は、本発明の一実施例に係るＨＤＲ情報ディスクリプタを示す。図示された情報は、図１７で説明したＨＤＲ情報ディスクリプタに含まれた情報と共に追加的に当該ディスクリプタに含まれ得る。ＨＤＲ情報ディスクリプタは、追加で、ＨＤＲプログラムトランジションフラグ情報、トランジションセットナンバー情報、及びトランジションバージョンナンバー情報をさらに含むことができる。ＨＤＲトランジションフラグ情報（ＨＤＲ＿ｐｒｏｇｒａｍ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）は、ＨＤＲ情報ディスクリプタに主要な変化がある場合を示す。例えば、当該フラグが１である場合、現在のＨＤＲプログラム／コンテンツの終了の意味を有することができる。また、当該フラグが１である場合、ＨＤＲコンテンツの変化、適用されるＨＤＲ情報の種類の変化などを意味し得る。放送送信装置は、上述した変化が発生した後、一定のフレーム／時間の間１にセットすることによって、ＨＤＲ情報ディスクリプタに主要な変化、ＨＤＲコンテンツ／プログラムの変化があることを知らせてもよい。または、変化が起こる直前に一定のフレーム／時間の間１にセットすることによって、一定のフレーム／時間の後にＨＤＲ情報ディスクリプタに変化があること、すなわち、ＨＤＲコンテンツ／プログラムの変化がある予定であることを知らせることができる。本フラグがシグナリングされる場合、主要な変化事項を適用するために、当該ＳＥＩメッセージを必須に参考するように条件を与えることもできる。必要に応じて、このようなシグナリングは、ビデオレベルだけでなく、システムレベル又はサービスレベルでも行うことができる。トランジションセットナンバー情報（ｔｒａｎｓｉｔｉｏｎ＿ｓｅｔ＿ｎｕｍｂｅｒ）及びトランジションバージョンナンバー情報（ｔｒａｎｓｉｔｉｏｎ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）は、変更されたＨＤＲコンテンツ／プログラムの特徴を知らせるための追加情報として伝送され得る。例えば、トランジションセットナンバー（ｓｅｔ＿ｎｕｍｂｅｒ）情報を介して、変更された又は変更されるＨＤＲコンテンツ／プログラムで使用するＨＤＲシステムをシグナリングするか、または多数のＨＤＲターゲットに関する情報がある場合、現在のターゲットと連携されたセットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）をシグナリングすることができる。セットナンバー（Ｓｅｔ＿ｎｕｍｂｅｒ）情報だけでなくトランジションバージョンナンバー（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）情報も、次のＨＤＲコンテンツ／プログラムに関する情報として提供することができる。必要に応じて、様々な種類の情報に対するリンクを提供することもできる。例えば、１０００ｎｉｔ／５００ｎｉｔ／１００ｎｉｔのターゲットディスプレイ（ｔａｒｇｅｔ ｄｉｓｐｌａｙ）に該当するそれぞれのセットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）及びバージョンナンバー情報（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）を提供することができる。
ＨＤＲトランジションフラグ情報と関連して図１７で説明したトランジションフラグ情報（ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）は、次のように使用することができる。トランジションフラグ情報（Ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）の意味を拡張して、ＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）に主要な変化がある場合を示すように設定することができる。すなわち、トランジションフラグ情報（ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）の値が１である場合、現在の又は現在のプログラムに該当するＨＤＲ情報ディスクリプタ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ）の伝送が終了するという意味を付与することによって、ＳＤＲが開始されるという意味だけでなく、他のＨＤＲプログラムが開始されるか、または他の種類のメタデータを適用するという意味などで使用することができる。具体的なシグナリングの意味及び方法は、ＨＤＲ＿ｐｒｏｇｒａｍ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇに従うようにすることができる。ここで、トランジションフラグ情報（ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）が単独で使用されるか、またはＨＤＲトランジションフラグ情報（ＨＤＲ＿ｐｒｏｇｒａｍ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）と連携して２つの信号を全て使用することができる。例えば、トランジションフラグ情報（ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）は、当該ＨＤＲ情報ディスクリプタの終了時点（ＨＤＲコンテンツの終了時点）にシグナリングし、ＨＤＲトランジションフラグ情報（ＨＤＲ＿ｐｒｏｇｒａｍ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ）は、次のＨＤＲコンテンツの開始時点にシグナリングすることができる。
ＨＤＲトランジションフラグ情報と関連して図１７で説明したセットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）は、その意味を拡張して使用することができる。セットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）の意味を拡張して、ＨＤＲ情報ディスクリプタに主要な変化がある場合を示すように設定することができる。すなわち、プログラム／コンテンツ／チャネルに応じてＨＤＲ情報ディスクリプタに互いに異なるセットナンバー（ｓｅｔ＿ｎｕｍｂｅｒ）を指定することができ、この場合、ＨＤＲ情報ディスクリプタの内容が変化したという意味を付与し、ＨＤＲコンテンツが終了し、新しいＨＤＲコンテンツが開始されるなどの変化が起こったことを知らせることができる。また、セットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）が特定のＨＤＲ情報ディスクリプタに対して固定値を有するように設定することもできる。例えば、ＨＤＲシステムに応じて互いに異なる種類のパラメータの伝達が可能な場合、それぞれのＨＤＲシステムをセットナンバー情報（ｓｅｔ＿ｎｕｍｂｅｒ）を用いて区分することができる。
ＨＤＲトランジションフラグ情報と関連して図１７で説明したバージョンナンバー情報（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）は、その意味を拡張して使用することができる。バージョンナンバー情報（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）の意味を拡張して、ＨＤＲ情報ディスクリプタに主要な変化がある場合を示すように設定することができる。すなわち、放送送信装置は、ＨＤＲ情報ディスクリプタに変化があるとき、変更されたバージョンナンバー（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）を付与し、放送受信装置が、変更されたＨＤＲ情報ディスクリプタが適用されるフレームからは新しいＨＤＲ情報ディスクリプタを必須に参考するように設定することができる。この場合、プログラム内でフレーム／場面単位の変化だけでなく、チャネル内でプログラム／コンテンツ自体が変わる場合、すなわち、現在のＨＤＲコンテンツが他の種類のＨＤＲコンテンツに変更される場合にも使用することができる。このとき、放送送信装置は、特定のバージョンナンバー（ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ）を付与してシグナリングすることによって、プログラム／コンテンツ自体が変わる場合のように主要な切り替えが起こる場合を特徴的に知らせることもできる。
図３３は、本発明の一実施例に係る特性セット（ｆｅａｔｕｒｅ ｓｅｔ）によってフレーム（ｆｒａｍｅ）内の領域を分割する場合を示す。ここで、フレームは、画面を構成するピクチャ内の全てのピクセルを含む全領域範囲を意味し得、実施例によっては、ウィンドウと呼ぶこともできる。ダイナミックメタデータ（Ｄｙｎａｍｉｃ ｍｅｔａｄａｔａ）は、時間によって変更されるフレーム又はシーン（ｆｒａｍｅ／ｓｃｅｎｅ）の特性を反映する情報であり得る。これと関連して、一つのフレーム内でも一定の特性に応じて互いに異なるメタデータプロセッシング（ｍｅｔａｄａｔａ ｐｒｏｃｅｓｓｉｎｇ）を適用することができる。例えば、フレーム内に暗い領域と明るい領域が共に存在する場合、それぞれの領域に対して互いに異なるプロセッシングを適用することによって、ＨＤＲ映像の効果を極大化することができる。この場合、送信端では、それぞれの特性（ｆｅａｔｕｒｅ）を区分する特徴を伝達することができ、各領域に対する互いに異なる処理方法を伝達することができる。受信端では、受信された領域別の特性（ｆｅａｔｕｒｅ）の特徴又は処理方法に基づいて領域適応的（ａｒｅａ−ａｄａｐｔｉｖｅ）に処理するようにすることができる。ここで、領域とは、閉曲線内で定義される単一の領域を意味してもよく、または同一又は類似の特性を有する少なくとも１つ以上の領域の集合を意味してもよい。例えば、図示のように、一つのフレームを構成する３つの領域が存在し得る。３つの領域は、互いに異なる特性（ｆｅａｔｕｒｅ）を有することができる。ここで、互いに異なる領域間に重なる（ｏｖｅｒｌａｐｐｅｄ）部分が存在し得る。この場合には、各領域の優先順位（ｐｒｉｏｒｉｔｙ）を指定して処理するようにすることができる。各領域別の優先順位は、映像制作者が指定することができ、制作者の意図が反映され得る。例えば、図示のように、特性セット１（ｆｅａｔｕｒｅ ｓｅｔ １）と特性セット２（ｆｅａｔｕｒｅ ｓｅｔ ２）が重なる場合があり得る。この場合、優先順位１（ｐｒｉｏｒｉｔｙ １）を有する特性セット２がさらに高い優先順位を有するため、重なった領域に対しては特性セット２を適用することができる。また、領域を指定する場合、各領域の和集合がフレーム（ｆｒａｍｅ）全体となるように指定して、全ての領域に対するプロセッシングが可能なようにすることができる。すなわち、フレーム全体において、領域の指定から除外されてプロセッシングされない部分が発生しないようにすることができる。勿論、意図的に処理しないようにすることができるが、一般的にこの場合にも、意図的に処理しないというシグナルを伝達することが必要である。前述したように領域を指定又は区分するための基準として、位置、色相特性、明るさ特性などを使用することができる。また、特定の物体（ｏｂｊｅｃｔ）に対するトラッキング（ｔｒａｃｋｉｎｇ）をサポートする場合、当該物体を領域として指定することもできる。この場合、当該物体がフレーム内で移動する場合、指定された領域も共に移動することができる。
図３４は、本発明の一実施例に係るＨＤＲ情報（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ）及び特性セット(ｆｅａｔｕｒｅ ｓｅｔ)をシグナリングする情報を示す。一つのフレームを多数の領域に対応する特性セットに区分し、各特性（ｆｅａｔｕｒｅ）に応じてそれぞれに互いに異なるプロセッシングを適用できる。そのために、各領域別に特性セットの特徴を指定し、これに従ってそれぞれマッチングされる情報を並べることができる。図面では、一つのメタデータ内に情報が並列的に記述される場合を示した。すなわち、ＨＤＲ情報タイプ（ＨＤＲ ｉｎｆｏｒｍａｔｉｏｎ ｔｙｐｅ）、ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、セットナンバー（ｓｅｔ ｎｕｍｂｅｒ）、バージョンナンバー（ｖｅｒｓｉｏｎ ｎｕｍｂｅｒ）、ｓｙｎｃ情報、及び入力／出力／プロセッシング色空間タイプ（ｉｎｐｕｔ／ｏｕｔｐｕｔ／ｐｒｏｃｅｓｓｉｎｇ ｃｏｌｏｒ ｓｐａｃｅ ｔｙｐｅ）のようにフレーム全体に適用される情報を除いたダイナミックレンジマッピング情報（ｄｙｎａｍｉｃ ｒａｎｇｅ ｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）、カラーガマットマッピング情報（ｃｏｌｏｒ ｇａｍｕｔ ｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）、及び視聴環境情報（ｖｉｅｗｉｎｇ ｃｏｎｄｉｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）のように特性セットによる処理過程を並列的に伝達するものである。特性セットを区分するための基準として、位置、カラー、明るさ、ヒストグラムなどを考慮することができ、これらの積集合でセット（ｓｅｔ）を定義することができる。同一のフレームに対して複数の特性セットが適用される場合、ＨＤＲ情報は、次のようなフィールドを含むことができる。
ｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｆｅａｔｕｒｅ＿ｓｅｔｓ＿ｉｎ＿ａ＿ｆｒａｍｅフィールドは、フレーム内で区分される特性セット（ｆｅａｔｕｒｅ ｓｅｔ）の個数を示すことができる。領域が区分されない場合は、当該フィールドを１に指定することができる。
ｆｅａｔｕｒｅ＿ｓｐａｔｉａｌ＿ｂｏｕｎｄａｒｙフィールドは、特性セットを指定する基準の一つとして、領域の位置を直接指定することができる。領域の位置は、一般的にｘ，ｙ ｉｎｄｅｘで示すことができる。例えば、領域の形状に応じて、四角形である場合、開始地点の座標（ｘ，ｙ）及び終了地点の座標（ｘ＋Ｎ，ｙ＋Ｍ）で示すことができる。または、開始地点及び各辺の長さＮ，Ｍで示すことができる。領域の形状が円形である場合、円の中心部及び直径で示すこともできる。特定の値を有する場合、使用しないことを示すこともできる。これについての詳細な実施例は、後述する図面で説明する。
ｆｅａｔｕｒｅ＿ｃｏｌｏｒｉｍｅｔｒｙ＿ｂｏｕｎｄａｒｙフィールドは、特性セットを指定する基準の一つとして、特定のカラーを有する領域を指定することができる。一般的にＲＧＢ ｃｏｌｏｒｉｍｅｔｒｙをＣＩＥ ｘｙ座標で示すことができる。または色空間（ｃｏｌｏｒ ｓｐａｃｅ）内で中心座標及び円（又は球）の直径で示してもよく、または任意の範囲を指定するようにしてもよい。特定の値を有する場合、使用しないことを示すこともできる。
ｆｅａｔｕｒｅ＿ｌｕｍｉｎａｎｃｅ＿ｂｏｕｎｄａｒｙフィールドは、特性セットを指定する基準の一つとして、特定の明るさを有する領域を指定することができる。明るさの最大最小値の範囲又は特定の明るさを中心に加減（＋−）される明るさ範囲を知らせることもできる。特定の値を有する場合、使用しないことを示すこともできる。
ｆｅａｔｕｒｅ＿ｈｉｓｔｏｇｒａｍ＿ｂｏｕｎｄａｒｙフィールドは、特性セットを指定する基準の一つとして、ヒストグラムの特性によって領域を区分する場合に使用することができる。例えば、映像ヒストグラムのｌｏｃａｌ ｍａｘｉｍｕｍを有する部分の中心明るさ（又はデジタル値）情報及びｂｏｕｎｄａｒｙ情報を伝達することができる。このとき、ヒストグラムは、ｌｕｍｉｎａｎｃｅに対する明るさ分布、又はＲＧＢのうち特定のチャネルあるいはそれぞれに関する情報を伝達して特性（ｆｅａｔｕｒｅ）を指定することができる。特定の値を有する場合、使用しないことを示すこともできる。
ｆｅａｔｕｒｅ＿ｐｒｉｏｒｉｔｙフィールドは、特性セットとして指定された領域が重なる場合に適用される優先順位を示すことができる。前述した実施例のように、全ての特性セットに対して互いに異なる優先順位が適用されてもよく、複数の特性セットが同じ優先順位を有してもよい。また、当該フィールドが０である場合、重なる領域に対してブレンディング（ｂｌｅｎｄｉｎｇ）のような処理が行われるように指定することができる。前記に記述した部分以外にも、区分される領域間のバウンダリ（ｂｏｕｎｄａｒｙ）処理に関連する部分が追加されてもよい。
フレーム内で領域に応じて互いに異なるメタデータによる処理のためには、フレーム内の領域を区分するための特徴を伝達しなければならない。このとき、前述した図面で定義したように、ｓｐａｔｉａｌ、ｃｏｌｏｒｉｍｅｔｒｙ、ｌｕｍｉｎａｎｃｅ、ｃｏｌｏｒ ｖｏｌｕｍｅ、ｈｉｓｔｏｇｒａｍのような互いに異なるカテゴリーに対するシグナリングを考慮することができる。また、少なくとも２つ以上のカテゴリーの積集合として１つの領域を区分することができる。例えば、ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールドで矩形領域を指定し、その矩形領域内でｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙフィールドで特定のカラーを有する領域を指定することができる。すなわち、ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールド及びｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙフィールドがそれぞれ示す指定領域を同時に満足させる領域を特定の特性セット（ｆｅａｔｕｒｅ ｓｅｔ）に対応させることができる。各カテゴリーに対するシグナリングは１つ以上使用することができ、各カテゴリーについての具体的な実施例として、以下のようなシグナリングを考慮することができる。
図３５は、本発明の一実施例に係る空間領域を指定するためのＳｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールドを示した図である。空間領域を指定するための方法として、フレーム内の一定の領域に対するシグナリングを考慮することができる。第一の方法として、矩形領域を空間領域として指定することができる（ｄ３５０１０）。Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールドは、矩形領域の頂点をシグナリングすることができ、より効率的なシグナリングとして、図示のように、左上端及び右下端の点をシグナリングすることができる。図面において、ｔｏｐ＿ｌｅｆｔ＿ｃｏｒｎｅｒ＿ｘ＿ａｘｉｓ及びｔｏｐ＿ｌｅｆｔ＿ｃｏｒｎｅｒ＿ｙ＿ａｘｉｓは、それぞれ矩形の左上端に位置した頂点のｘ，ｙ座標を示す。同様に、ｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｃｏｒｎｅｒ＿ｘ＿ａｘｉｓ及びｂｏｔｔｏｍ＿ｒｉｇｈｔ＿ｃｏｒｎｅｒ＿ｙ＿ａｘｉｓは、矩形の右下端に位置した頂点のｘ，ｙ座標を示す。ｄ３５０１０に示された方法を用いて領域がシグナリングされる場合、対角線に位置した２つの頂点によって決定される矩形の内部を含む領域を空間領域として指定することができる。
第二の方法として、矩形ではなく円形状の領域を指定する場合、円の内部に属する領域を空間領域として指定することができる。この場合、Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙフィールドは、円の中心座標（ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｘ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｙ＿ａｘｉｓ）及び円の半径（ｒａｄｉｕｓ＿ｏｆ＿ｃｉｒｃｌｅ）に対する情報をシグナリングすることができる（ｄ３５０２０）。この方法を用いて領域がシグナリングされる場合、円の内部に属するピクセル（ｐｉｘｅｌ）を全て含むものと考慮することができる。
第三の方法として、前述した矩形及び円以外にも、楕円などのよく知られた図形の形状を考慮できる。任意の多角形としてシグナリングする場合、ｄ３５０３０に示したように、多角形の頂点の数（ｎｕｍｂｅｒ＿ｏｆ＿ｐｏｉｎｔｓ＿ｍｉｎｕｓ＿２）及び各頂点の位置（ｘ＿ａｘｉｓ ［ｉ］，ｙ＿ａｘｉｓ ［ｉ］）をシグナリングすることができる。このとき、多角形を作るために、頂点の個数は最小３個となり得る。ｎｕｍｂｅｒ＿ｏｆ＿ｐｏｉｎｔｓ＿ｍｉｎｕｓ＿２フィールドは、多角形の実際の頂点の個数より２だけ少ない数をシグナリングすることもできる。例えば、ｎｕｍｂｅｒ＿ｏｆ＿ｐｏｉｎｔｓ＿ｍｉｎｕｓ＿２フィールドが２である場合は、前述した矩形の形状をシグナリングすることができる。このように、任意の多角形としてシグナリングされる場合、当該多角形に含まれた点を全て使用して構成される多角形の内部の領域を指称するものと考慮することができる。
第四の方法は、任意の多角形に対する他のシグナリング方法として、予め定められた又は予め伝送された領域を使用することができる。このとき、ｄ３５０４０に示したように、マスク（ｍａｓｋ）の種類（ｍａｓｋ＿ｔｙｐｅ）、マスクの開始又は中心位置（ｌｏｃａｔｉｏｎ＿ｘ＿ａｘｉｓ，ｌｏｃａｔｉｏｎ＿ｙ＿ａｘｉｓ）、マスクのサイズ（ｒａｔｉｏ：基準サイズに対する比率）のような情報を通じて、一定の形状の領域を指定することができる。このとき、マスクの種類は、予め指定又は伝送された領域を使用することができる。マスクの種類による領域の形状のディテールは、静的メタデータ（ｓｔａｔｉｃ ｍｅｔａｄａｔａ）を介して予め伝送されてもよく、以前のフレーム情報を使用してもよく、マスクを直接ピクセルデータ（ｐｉｘｅｌ ｄａｔａ）として送ってもよい。
図３６は、本発明の一実施例に係る空間領域を指定するためのＣｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙフィールドを示した図である。特性セット（ｆｅａｔｕｒｅ ｓｅｔ）に対応する領域を指定するために、ＨＤＲ情報は、色度平面上での色相範囲を指定することもできる。一般的に映像において基本的に使用する色空間をベースとする色度平面を使用することができる。しかし、場合によって、制作者が意図する特定の色度平面上での色相範囲を考慮することができる。制作者が意図する特定の色度平面上での色相範囲をシグナリングするためには、当該色度平面に対するシグナリングが必要となり得る。この場合、ｄ３６０１０に示したように、特定の色空間タイプ（ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｙｐｅ）、及び必要に応じて変換式（ｃｏｅｆｆｉｃｉｅｎｔ ［ｉ］）を提供することもできる。ここで、色空間タイプ（ｃｏｌｏｒ ｓｐａｃｅ ｔｙｐｅ）は、ｄ３６０２０に示したように、ＹＣｂＣｒ、Ｌａｂ、Ｙｕｖなどの色空間を使用することができる。また、ｌｕｍｉｎａｎｃｅ表現方法（ｌｉｎｅａｒ，ｎｏｎ−ｌｉｎｅａｒ）、ｌｕｍｉｎａｎｃｅ変換式（ＥＯＴＦ ａ，ＥＯＴＦ ｂ）、中心色温度（Ｄ６５，Ｄ５０など）のような基準によって区分されてもよい。実施例によって、既存に定義された色空間ではなく任意の色空間を使用してもよく、この場合、ＸＹＺのような中立（ｎｅｕｔｒａｌ）色空間から任意の色空間への変換式を用いて定義することができる。
色相範囲を指定するための色座標が指定された後、与えられた色空間内での一定の範囲内の色相の集合として色相範囲を考慮することができる。この場合、色座標上での任意の多角形、円、楕円などで色相範囲を指定することができる。多角形の場合、ｄ３６０３０に示したように、点の個数（ｎｕｍｂｅｒ＿ｏｆ＿ｐｏｉｎｔｓ＿ｍｉｎｕｓ＿３）による頂点の座標値（ｘ＿ａｘｉｓ［ｉ］，ｙ＿ａｘｉｓ［ｉ］）を通じて指定された多角形の内部のカラー領域を限定することができる。具体的な領域の指定は、前の図面で説明した通りである。
また、ｄ３６０４０に示したように、特定のカラー座標（ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｘ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｙ＿ａｘｉｓ）を中心に一定の半径（ｒａｄｉｕｓ＿ｏｆ＿ｃｉｒｃｌｅ）内のカラーの集合としてカラー領域をシグナリングすることができる。
これと同様に、ｄ３６０５０に示したように、特定のカラー座標（ｃｅｎｔｅｒ＿ｏｆ＿ｅｌｌｉｐｓｏｉｄ＿ｘ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｅｌｌｉｐｓｏｉｄ＿ｙ＿ａｘｉｓ）を中心にする一定の勾配（ａｎｇｌｅ）を有する軸を中心に楕円の形状（ｃｏｅｆｆｉｃｉｅｎｔ＿ａ，ｃｏｅｆｆｉｃｉｅｎｔ＿ｂ）でカラー領域を限定することもできる。
図３７は、本発明の一実施例に係る空間領域を指定するためのＬｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙフィールド及びＬｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙフィールドを示した図である。特性セット（ｆｅａｔｕｒｅ ｓｅｔ）に対応する領域を指定するために、ＨＤＲ情報は、明るさの範囲を指定するか、または映像内の明るさ分布を指定することができる。Ｌｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙフィールドは、ｄ３７０１０に示したように、明るさの範囲として領域を指定することができる。ピクセル（Ｐｉｘｅｌ）の明るさがｂｌａｃｋ−ｗｈｉｔｅの両極端を結ぶ線分上に存在するという仮定下に、当該線分上の点で明るさ範囲を区分することができる。このとき、明るさに対する表現は、明るさの相対分布を示すデジタル値（ｄｉｇｉｔａｌ＿ｖａｌｕｅ）で表現されるか、または絶対明るさ値（ｌｕｍｉｎａｎｃｅ＿ｖａｌｕｅ）で表現されてもよい。
Ｌｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙフィールドは、ｄ３７０２０に示したように、明るさ分布として領域を指定することができる。明るさ範囲による特性（ｆｅａｔｕｒｅ）区分の他の方法の一つとして、映像内の明るさ分布を用いることができる。このとき、明るさ範囲を区分するために、明るさが主要に分布する地点の明るさ（ｌｏｃａｌ＿ｍａｘｉｍｕｍ）を基準として高い明るさ限界（ｕｐｐｅｒ＿ｂｏｕｎｄ）及び低い明るさ限界（ｌｏｗｅｒ＿ｂｏｕｎｄ）を指定することができる。すなわち、基準明るさを基準として上限及び下限をシグナリングすることができる。ここで、各フィールド値は、明るさの相対分布を示すデジタル値（ｄｉｇｉｔａｌ＿ｖａｌｕｅ）又は絶対明るさ値（ｌｕｍｉｎａｎｃｅ＿ｖａｌｕｅ）であってもよく、必要に応じて、図示のように２つを全て使用してもよい。本発明では、明るさ分布に対する代表例として、ヒストグラム（ｈｉｓｔｏｇｒａｍ）分布に基づいて範囲を指定する例を示したが、実施例によっては、明るさ累積分布のような他の種類の分布を用いることができる。
図３８は、本発明の一実施例に係る空間領域を指定するためのＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙフィールドを示した図である。特性セット（ｆｅａｔｕｒｅ ｓｅｔ）に対応する領域は、一つの色空間内で定義され得る。すなわち、前述した実施例とは異なり、カラー領域と明るさ領域を一つの色空間内で定義することができる。このとき、色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）が定義された色空間（ｃｏｌｏｒ ｓｐａｃｅ）に対する定義が別途に必要な場合、上述したｆｅａｔｕｒｅ＿ｃｏｌｏｒ＿ｓｐａｃｅを用いることができる。
色空間内で色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）を定義する方法としては、多面体の頂点を定義することができる。ここで、ｄ３８０１０に示したように、頂点の個数（ｎｕｍｂｅｒ＿ｏｆ＿ｐｏｉｎｔｓ）及び各頂点の座標（ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｘ＿ａｘｉｓ，ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｙ＿ａｘｉｓ）を通じて多面体を定義することができる。すなわち、色空間内でこのように定義された多面体の内部に含まれる色相を色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）の必要領域として指定することができる。
次に、色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内での範囲を指定する他の方法として、ｄ３８０２０に示したように、明るさの段階によるカラリメトリー（ｃｏｌｏｒｉｍｅｔｒｙ）を定義する方法を考慮することができる。例えば、ＨＳＩ（Ｈｕｅ Ｓａｔｕｒａｔｉｏｎ Ｉｎｔｅｎｓｉｔｙ）色空間（ｃｏｌｏｒ ｓｐａｃｅ）のようにカラー（ｈｕｅ，ｓａｔｕｒａｔｉｏｎ）と明るさ（ｉｎｔｅｎｓｉｔｙ）が分離される場合、色相（ｈｕｅ）、彩度（ｓａｔｕｒａｔｉｏｎ）及び明度（ｉｎｔｅｎｓｉｔｙ）のそれぞれをｘｙｚ座標平面上の各軸に対応させることができる。この場合、明るさの段階（ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｚ＿ａｘｉｓ）を一定の個数（ｎｕｍｂｅｒ＿ｏｆ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌｓ）に対応するレベルに分け、各明るさの段階による多角形の色座標（ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｘ＿ａｘｉｓ，ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｙ＿ａｘｉｓ）を定義することができる。すなわち、明るさのレベルによるカラリメトリーを定義し、各層間は補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）を通じて色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）を定義することができる。言い換えれば、色空間（ｃｏｌｏｒ ｓｐａｃｅ）内で定義しようとする色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）を、色空間内で区分された少なくとも１つ以上の明るさ区間に対してそれぞれ定義された少なくとも１つ以上の色相範囲を通じて示すことができる。例えば、色空間内で第１明るさ区間に対しては第１色相範囲をシグナリングし、第２明るさ区間に対しては第２色相範囲をシグナリングして、各明るさ区間別に互いに異なって定義される色相範囲を示すことができる。このような色相範囲に対するシグナリングは、フレーム全体に対して定義することができ、また、実施例によって、一つのフレームを構成する複数の領域に対してそれぞれ定義されてもよい。ここで、フレームとは、画面を構成するピクチャ内の全てのピクセルを含む全領域範囲を意味し得、実施例によってはウィンドウと呼ぶこともできる。
明るさレベルの区分による色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）のシグナリングに対する他の例として、ｄ３８０３０に示したように、カラリメトリー（ｃｏｌｏｒｉｍｅｔｒｙ）を円の形態でシグナリングすることができる。すなわち、区分される明るさ値（ｃｏｌｏｒ＿ｖｏｌｕｍｅ＿ｚ＿ａｘｉｓ）で定義されるカラープレーン（ｃｏｌｏｒ ｐｌａｎｅ）に対して中心色相のカラー座標（ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｘ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｙ＿ａｘｉｓ）と類似のカラーが含まれるものと予想される半径（ｒａｄｉｕｓ＿ｏｆ＿ｃｉｒｃｌｅ）をシグナリングし、カラープレーンの間は、補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）を通じて全体色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）に関する情報を提供することができる。
色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内で特定の明るさでの特定のカラーに対するバウンダリ（ｂｏｕｎｄａｒｙ）をシグナリングする方法として、ｄ３８０４０に示したように、対象カラー座標（ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｘ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｙ＿ａｘｉｓ，ｃｅｎｔｅｒ＿ｏｆ＿ｃｉｒｃｌｅ＿ｚ＿ａｘｉｓ）及び対象カラーを中心にする類似のカラーに対する半径（ｒａｄｉｕｓ＿ｏｆ＿ｃｉｒｃｌｅ）に対してシグナリングする方法を用いて、色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）情報を提供することもできる。この場合、当該カラー座標を中心にした類似のカラーに対する半径を有する球（ｓｐｈｅｒｅ）の内部として色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）が定義され得る。
上述した方法以外にも、カラープレーン（ｃｏｌｏｒ ｐｌａｎｅ）での楕円又は楕円をベースとした立体図形を色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）として考慮することもできる。一般に、類似のカラー／明るさ群は、中心カラーから一定の範囲内に存在するようになり、このとき、方向性による互いに異なる加重値が必要な場合、楕円又は楕円形の立体のような形状を使用することができる。
図３９は、本発明の一実施例に係る放送送信機を示したブロック図である。本発明に係る放送送信機ｄ３９０１０は、エンコーダｄ３９０２０、多重化部ｄ３９０３０及び／又は送信部ｄ３９０４０を含むことができる。
放送送信機ｄ３９０１０に入力されるビデオデータの解像度はＵＨＤであってもよい。また、放送送信機ｄ３９０１０に入力されるメタデータは、ＵＨＤビデオに対する画質改善メタデータを含むことができる。画質改善メタデータは、ビデオデータと共に伝送されるＳＥＩメッセージに含まれて伝送されてもよい。図１７乃至図３８で前述したように、画質改善メタデータはＨＤＲ情報ディスクリプタ（ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ）を含むことができ、これは、ＵＨＤビデオの画質改善に必要な情報を含むことができる。ＵＨＤビデオの画質改善に必要な情報は、コンテンツ全体（ｃｈａｎｎｅｌ、ｐｒｏｇｒａｍ、ｃｏｎｔｅｎｔ）、シーン（ｓｃｅｎｅ）、クリップ（ｃｌｉｐ）またはフレームの単位で適用され得、コンテンツ全体に適用される共通適用情報、及びシーン、クリップまたはフレーム単位で適用される部分適用情報を共に含むこともできる。また、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＨＤＲの終了時点を示すｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ情報を含むことができる。
また、ＨＤＲ情報ディスクリプタは、前述したように、画質改善のためのプロセッシングステップに対するプロセッシング色空間タイプ情報及びプロセッシング色相精度情報を含むことができる。これに加えて、ＨＤＲ情報ディスクリプタは、プロセッシングステップの前に対する入力色空間タイプ情報及び入力色相精度情報、及びプロセッシングステップの後に対する出力色空間タイプ情報及び出力色相精度情報をさらに含むことができる。また、ＨＤＲ情報ディスクリプタは、画質改善プロセッシングがターゲットとするダイナミックレンジ、変換関数タイプ、カラーガマット、及び色温度タイプに関する情報も含むことができる。また、ＨＤＲコンテンツ又はＨＤＲ情報に対する変更が予定されていることを示すＨＤＲプログラムトランジションフラグ情報、及びそのトランジションの対象となるセットナンバー情報及びバージョンナンバー情報を含むことができる。
また、ＨＤＲ情報ディスクリプタは、フレーム内に含まれた複数の領域を区分することができ、各領域に対応する特性セット（ｆｅａｔｕｒｅ ｓｅｔ）情報を含むことができる。特性セット情報は、同じフレーム内でも領域別に互いに異なるメタデータプロセッシングを適用することができる。各特性セットは、領域位置によって区分されるか、または色空間で一定の範囲内の色相によって区分されてもよい。また、特性セットは、明るさ範囲や明るさ分布によって区分されてもよい。また、色空間内で定義された多面体によって区分される色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内で、前述した位置、色相、明るさ範囲、及び明るさ分布のうちの少なくとも１つによって区分されてもよい。ＨＤＲ情報ディスクリプタは、前述した特性セットを区分する情報を含むことができ、例えば、Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙ情報、Ｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙ情報、及びＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙ情報のうちの少なくとも１つを含むことができる。各情報についての詳細な説明は、図３５乃至図３８で説明した通りである。
放送送信機ｄ３９０１０に入力されたビデオデータは、エンコーダｄ３９０２０によってエンコードされ得る。送信端は、ビデオデータに対するエンコーディング方式としてＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）を用いることができる。送信端は、エンコードされたビデオデータと画質改善メタデータを同期化し、多重化部ｄ３９０３０を用いて多重化することができる。画質改善メタデータは同期化情報をさらに含むことができる。画質改善メタデータは、同期化方法に応じて、時間、時間差、開始順序、ＰＯＣ、ＰＴＳ、累積されたフレームの個数などの同期化情報を含むことができる。
送信部ｄ３９０４０は、多重化部ｄ３９０３０から出力されたトランスポートストリームを放送信号として送信することができる。ここで、トランスポートストリームは、送信の前にチャネルコーディング及び変調された後、放送信号として送信され得る。本発明の他の実施例によれば、メタデータは、放送信号だけでなく、他の経路（例えば、ＩＰベースの放送／通信、有／無線通信、有／無線インターフェース、近距離無線通信など）でも送信することができる。また、ビデオデータと別途の経路で送信されてもよい。
図４０は、本発明の一実施例に係る放送受信機を示したブロック図である。本発明に係る放送受信機ｄ４００１０は、受信部ｄ４００２０、逆多重化部ｄ４００３０及び／又はデコーダｄ４００４０を含むことができる。
受信部ｄ４００２０によって受信された放送信号は、復調された後、チャネルデコードされ得る。チャネルデコードされた放送信号は、逆多重化部ｄ４００３０に入力されてビデオストリーム及び画質改善メタデータに逆多重化され得る。メタデータは、放送信号だけでなく、他の経路（例えば、ＩＰベースの放送／通信、有／無線通信、有／無線インターフェース、近距離無線通信など）でも受信することができる。逆多重化部の出力は、デコーダｄ４００４０に入力され得る。デコーダは、ビデオデコーダ及びメタデータプロセッサを含むことができる。すなわち、ビデオストリームはビデオデコーダによって、画質改善メタデータはメタデータプロセッサを介してデコードされ得る。それぞれデコードされたビデオストリーム及び画質改善メタデータは、図１９で説明したように、後処理部によってＵＨＤビデオの画質改善に使用することができる。受信機は、画質改善メタデータに基づいてデコードされたビデオデータを後処理することができ、ＨＤＲ及びＷＣＧのうちの少なくとも１つに対してビデオデータの画質を改善する効果を得ることができる。前記画質改善メタデータは、前述したように、ＨＤＲ情報ディスクリプタを含むことができ、また、ＨＤＲ情報ディスクリプタは、前述したように、画質改善のためのプロセッシングステップに対するプロセッシング色空間タイプ情報、及びプロセッシング色相精度情報を含むことができる。これに加えて、ＨＤＲ情報ディスクリプタは、プロセッシングステップの前に対する入力色空間タイプ情報及び入力色相精度情報及びプロセッシングステップの後に対する出力色空間タイプ情報及び出力色相精度情報をさらに含むことができる。また、ＨＤＲ情報ディスクリプタは、画質改善プロセッシングがターゲットとするダイナミックレンジ、変換関数タイプ、カラーガマット、及び色温度タイプに関する情報も含むことができる。また、ＨＤＲコンテンツ又はＨＤＲ情報に対する変更が予定されていることを示すＨＤＲプログラムトランジションフラグ情報、及びそのトランジションの対象となるセットナンバー情報及びバージョンナンバー情報を含むことができる。
また、ＨＤＲ情報ディスクリプタは、フレーム内に含まれた複数の領域を区分することができ、各領域に対応する特性セット（ｆｅａｔｕｒｅ ｓｅｔ）情報を含むことができる。特性セット情報は、同じフレーム内でも領域別に互いに異なるメタデータプロセッシングを適用することができる。各特性セットは、領域位置によって区分されるか、または色空間で一定の範囲内の色相によって区分されてもよい。また、特性セットは、明るさ範囲や明るさ分布によって区分されてもよい。また、色空間内で定義された多面体によって区分される色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内で、前述した位置、色相、明るさ範囲、及び明るさ分布のうちの少なくとも１つによって区分されてもよい。ＨＤＲ情報ディスクリプタは、前述した特性セットを区分する情報を含むことができ、例えば、Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙ情報、Ｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙ情報、及びＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙ情報のうちの少なくとも１つを含むことができる。各情報についての詳細な説明は、図３５乃至図３８で説明した通りである。
図４１は、本発明の一実施例に係る画質改善メタデータを含む放送信号を送信する方法を示した図である。画質改善メタデータを含む放送信号を送信する方法は、ビデオストリームをエンコードしてビデオデータを生成するステップ（ｄｓ４１０１０）、生成されたビデオデータ及び画質改善メタデータを含む放送信号を生成するステップ（ｄｓ４１０２０）、及び生成された放送信号を送信するステップ（ｄｓ４１０３０）を含むことができる。
ビデオストリームをエンコードしてビデオデータを生成するステップ（ｄｓ４１０１０）は、ＵＨＤの解像度を有するビデオストリームを受信し、ビデオストリームをエンコードしてビデオデータを生成することができる。ここで、ビデオストリームは、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）によってエンコードされ得る。これと共に、ビデオデータを生成するステップ（ｄｓ４１０１０）は画質改善メタデータを生成することができる。前述したように、放送送信装置は、ビデオデータを生成するステップ（ｄｓ４１０１０）でビデオデータの全体コンテンツ（ｃｈａｎｎｅｌ、ｐｒｏｇｒａｍ、ｃｏｎｔｅｎｔ）、シーン（ｓｃｅｎｅ）、クリップ（ｃｌｉｐ）またはフレーム（ｆｒａｍｅ）の単位で適用される画質改善メタデータを共に生成することができる。画質改善メタデータは、ＨＤＲ及びＷＣＧのうちの少なくとも１つに対するデータであってもよく、適用単位に応じて互いに異なる情報量を有することができる。画質改善メタデータは、前述したＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）に含まれて送信され得る。また、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＨＤＲの終了時点を示すｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ情報を含むことができる。また、ＨＤＲ情報ディスクリプタは、前述したように、画質改善のためのプロセッシングステップに対するプロセッシング色空間タイプ情報及びプロセッシング色相精度情報を含むことができる。これに加えて、ＨＤＲ情報ディスクリプタは、プロセッシングステップの前に対する入力色空間タイプ情報及び入力色相精度情報、及びプロセッシングステップの後に対する出力色空間タイプ情報及び出力色相精度情報をさらに含むことができる。また、ＨＤＲ情報ディスクリプタは、画質改善プロセッシングがターゲットとするダイナミックレンジ、変換関数タイプ、カラーガマット、及び色温度タイプに関する情報も含むことができる。また、ＨＤＲコンテンツ又はＨＤＲ情報に対する変更が予定されていることを示すＨＤＲプログラムトランジションフラグ情報、及びそのトランジションの対象となるセットナンバー情報及びバージョンナンバー情報を含むことができる。
また、ＨＤＲ情報ディスクリプタは、フレーム内に含まれた複数の領域を区分することができ、各領域に対応する特性セット（ｆｅａｔｕｒｅ ｓｅｔ）情報を含むことができる。特性セット情報は、同じフレーム内でも領域別に互いに異なるメタデータプロセッシングを適用することができる。各特性セットは、領域位置によって区分されるか、または色空間で一定の範囲内の色相によって区分されてもよい。また、特性セットは、明るさ範囲や明るさ分布によって区分されてもよい。また、色空間内で定義された多面体によって区分される色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内で、前述した位置、色相、明るさ範囲、及び明るさ分布のうちの少なくとも１つによって区分されてもよい。ＨＤＲ情報ディスクリプタは、前述した特性セットを区分する情報を含むことができ、例えば、Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙ情報、Ｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙ情報、及びＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙ情報のうちの少なくとも１つを含むことができる。各情報についての詳細な説明は、図３５乃至図３８で説明した通りである。
また、画質改善メタデータは、シグナリング情報内で直接定義されるか、または他のメッセージを参照する方式で生成されてもよい。このような画質改善メタデータは、受信機にとって、適用単位に応じてビデオデータの画質を改善する参照データとなり得る。結果的に、受信機は、ビデオデータと共に受信される画質改善メタデータを用いて、ビデオデータの画質を動的に改善することができる。
生成されたビデオデータ及び画質改善メタデータを含む放送信号を生成するステップ（ｄｓ４１０２０）は、放送信号フレームをビルドし、変調過程を用いて放送信号を生成することができる。
生成された放送信号を送信するステップ（ｄｓ４１０３０）は、トランスポートストリームを放送信号として送信することができる。
図４２は、本発明の一実施例に係る画質改善メタデータを含む放送信号を受信する方法を示した図である。画質改善メタデータを含む放送信号を受信する方法は、放送信号を受信するステップ（ｄｓ４２０１０）、受信された放送信号をビデオデータ及び画質改善メタデータに逆多重化するステップ（ｄｓ４２０２０）、及びビデオデータ及び画質改善メタデータをデコードし、適用するステップ（ｄｓ４２０３０）を含むことができる。
放送信号を受信するステップ（ｄｓ４２０１０）は、受信部を用いて放送信号を受信し、受信された放送信号は、復調された後、チャネルデコードされ得る。放送信号は、ＵＨＤ放送信号を含むことができ、ＵＨＤ放送コンテンツ（ｃｏｎｔｅｎｔ）に対する画質改善メタデータをさらに含むことができる。画質改善メタデータについての詳細な説明は、図１７乃至図３８で説明した通りである。
受信された放送信号をビデオデータ及び画質改善メタデータに逆多重化するステップ（ｄｓ４２０２０）は、チャネルデコードされた放送信号を、逆多重化部を用いてビデオデータ及び画質改善メタデータに逆多重化することができる。ビデオデータはＵＨＤビデオデータを含むことができ、画質改善メタデータは、ＵＨＤビデオデータに適用されるＨＤＲ又はＷＣＧ関連データを含むことができる。画質改善メタデータは、前述したＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）に含まれて受信されてもよい。また、ＨＤＲ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ（）は、ＨＤＲの終了時点を示すｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ情報を含むことができる。ここで、画質改善メタデータは、その適用範囲によって共通適用情報と部分適用情報に区分できる。画質改善メタデータは、共通適用情報及び部分適用情報のうちの少なくとも１つを含むことができる。共通適用情報は、チャネル全体、プログラム全体、または一つのコンテンツを形成するビデオデータ全体に対して適用される情報であり、部分適用情報は、ビデオデータの一部のシーン、クリップまたはフレームに部分的に適用可能なデータであり得る。画質改善メタデータは、放送信号のシグナリング情報内で直接定義されるか、または予め定義されたメッセージを参照する方式が用いられてもよい。
ビデオデータ及び画質改善メタデータをそれぞれデコードし、適用するステップ（ｄｓ４２０３０）は、ビデオデコーダを用いてビデオデータをデコードし、ビデオデータを取得することができる。このステップで、画質改善メタデータに対しては、シグナリングデータパーサー又はメタデータデコーダを用いて画質改善メタデータを取得することができる。受信機は、画質改善メタデータに基づいて、デコードされたビデオデータの画質を改善することができる。画質改善メタデータは、ビデオデータに対するＨＤＲ又はＷＣＧ情報を含むことができ、各情報が適用される時点を示す同期化情報をさらに含むことができる。前記画質改善メタデータは、前述したようにＨＤＲ情報ディスクリプタを含むことができ、また、ＨＤＲ情報ディスクリプタは、前述したように、画質改善のためのプロセッシングステップに対するプロセッシング色空間タイプ情報及びプロセッシング色相精度情報を含むことができる。これに加えて、ＨＤＲ情報ディスクリプタは、プロセッシングステップの前に対する入力色空間タイプ情報及び入力色相精度情報、及びプロセッシングステップの後に対する出力色空間タイプ情報及び出力色相精度情報をさらに含むことができる。また、ＨＤＲ情報ディスクリプタは、画質改善プロセッシングがターゲットとするダイナミックレンジ、変換関数タイプ、カラーガマット、及び色温度タイプに関する情報も含むことができる。また、ＨＤＲコンテンツ又はＨＤＲ情報に対する変更が予定されていることを示すＨＤＲプログラムトランジションフラグ情報、及びそのトランジションの対象となるセットナンバー情報及びバージョンナンバー情報を含むことができる。
また、ＨＤＲ情報ディスクリプタは、フレーム内に含まれた複数の領域を区分することができ、各領域に対応する特性セット（ｆｅａｔｕｒｅ ｓｅｔ）情報を含むことができる。特性セット情報は、同じフレーム内でも領域別に互いに異なるメタデータプロセッシングを適用することができる。各特性セットは、領域位置によって区分されるか、または色空間で一定の範囲内の色相によって区分されてもよい。また、特性セットは、明るさ範囲や明るさ分布によって区分されてもよい。また、色空間内で定義された多面体によって区分される色相範囲（ｃｏｌｏｒ ｖｏｌｕｍｅ）内で、前述した位置、色相、明るさ範囲、及び明るさ分布のうちの少なくとも１つによって区分されてもよい。ＨＤＲ情報ディスクリプタは、前述した特性セットを区分する情報を含むことができ、例えば、Ｓｐａｔｉａｌ ｂｏｕｎｄａｒｙ情報、Ｃｏｌｏｒｉｍｅｔｒｙ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｂｏｕｎｄａｒｙ情報、Ｌｕｍｉｎａｎｃｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｂｏｕｎｄａｒｙ情報、及びＣｏｌｏｒ ｖｏｌｕｍｅ ｂｏｕｎｄａｒｙ情報のうちの少なくとも１つを含むことができる。各情報についての詳細な説明は、図３５乃至図３８で説明した通りである。
画質改善メタデータは、同期化情報に基づいてビデオデータに適用され得る。これを通じて、ビデオデータは、全体的に又は区間別に画質改善が適用され得る。ユーザは、既存のＵＨＤコンテンツに追加的に適用されたＨＤＲ又はＷＣＧ情報を通じて改善された画質のＵＨＤコンテンツの提供を受けることができる。
モジュール又はユニットは、メモリ（又は格納ユニット）に格納された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各ステップは、ハードウェア／プロセッサによって行われてもよい。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実行されてもよい。このコードは、プロセッサが読み取り可能な格納媒体に書き込まれてもよく、したがって、装置（ａｐｐａｒａｔｕｓ）の提供するプロセッサによって読み取られてもよい。
説明の便宜のために各図に分けて説明したが、各図に開示した実施例を組み合わせて新しい実施例を具現するように設計することも可能である。そして、通常の技術者の必要によって、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも、本発明の権利範囲に属する。
本発明に係る装置及び方法は、上述したように、説明された実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
一方、本発明が提案する方法を、ネットワークデバイスに備えられた、プロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することが可能である。プロセッサが読み取り可能な記録媒体は、プロセッサで読み出し可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み取り可能なコードが格納され、実行されてもよい。
また、以上では、本発明の好適な実施例について図示し、説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者によって様々な変形実施が可能であることは勿論であり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。
本発明の思想や範囲から逸脱することなく、本発明の様々な変更及び変形が可能であることは、当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。
本明細書では装置の発明及び方法の発明を両方とも言及しており、装置の発明及び方法の発明の説明を互いに補完して適用することもできる。
様々な実施例が、発明を実施するための最良の形態で説明された。
本発明は一連の放送信号提供分野で利用される。
本発明の思想や範囲から逸脱することなく、本発明で様々な変更及び変形が可能であることは当業者には自明である。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。

Claims (6)

  1. 放送信号を送信する方法であって、
    ビデオデータを生成するステップと、
    画質改善メタデータを生成するステップと、
    前記ビデオデータと前記画質改善メタデータを含む前記放送信号を送信するステップと、を含み、
    前記画質改善メタデータは、ＳＥＩ（ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）メッセージであり、
    前記ＳＥＩメッセージは、前記ビデオデータのフレーム内の矩形領域の個数を特定するための個数情報及び各領域の位置を特定するための座標情報を含み、
    ＨＥＶＣで定義されるｃｏｌｏｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅは、前記矩形領域の少なくとも１つに適用され、
    前記ｃｏｌｏｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅは、前記ビデオデータのカラーサンプルのリマッピングに対する情報を提供する、放送信号送信方法。
  2. 前記ＳＥＩメッセージは、前記矩形領域を区分する明るさ範囲情報又は明るさ分布情報を更に含む、請求項１に記載の放送信号送信方法。
  3. 前記ＳＥＩメッセージは、前記矩形領域を区分する色相範囲情報を更に含む、請求項１に記載の放送信号送信方法。
  4. 放送信号を受信する方法であって、
    ビデオデータ及び画質改善メタデータを含む前記放送信号を受信するステップと、
    前記放送信号を前記ビデオデータ及び前記画質改善メタデータに逆多重化するステップと、
    前記ビデオデータ及び前記画質改善メタデータをそれぞれデコードするステップと、
    前記画質改善メタデータを前記ビデオデータに適用するステップと、を含み、
    前記画質改善メタデータは、ＳＥＩ（ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）メッセージであり、
    前記ＳＥＩメッセージは、前記ビデオデータのフレーム内の矩形領域の個数を特定するための個数情報及び各領域の位置を特定するための座標情報を含み、
    ＨＥＶＣで定義されるｃｏｌｏｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅは、前記矩形領域の少なくとも１つに適用され、
    前記ｃｏｌｏｒ ｒｅｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ＳＥＩ ｍｅｓｓａｇｅは、前記ビデオデータのカラーサンプルのリマッピングに対する情報を提供する、放送信号受信方法。
  5. 前記ＳＥＩメッセージは、前記矩形領域を区分する明るさ範囲情報又は明るさ分布情報を更に含む、請求項４に記載の放送信号受信方法。
  6. 前記ＳＥＩメッセージは、前記矩形領域を区分する色相範囲情報を更に含む、請求項４に記載の放送信号受信方法。
JP2018509764A 2015-08-20 2016-08-22 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Active JP6633739B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562207896P 2015-08-20 2015-08-20
US62/207,896 2015-08-20
US201562210438P 2015-08-26 2015-08-26
US62/210,438 2015-08-26
PCT/KR2016/009230 WO2017030425A1 (ko) 2015-08-20 2016-08-22 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Publications (2)

Publication Number Publication Date
JP2018532294A JP2018532294A (ja) 2018-11-01
JP6633739B2 true JP6633739B2 (ja) 2020-01-22

Family

ID=58051091

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018509764A Active JP6633739B2 (ja) 2015-08-20 2016-08-22 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Country Status (5)

Country Link
US (1) US20190007709A1 (ja)
EP (1) EP3340636A4 (ja)
JP (1) JP6633739B2 (ja)
CN (1) CN107925780B (ja)
WO (1) WO2017030425A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI763074B (zh) * 2020-10-12 2022-05-01 宏碁股份有限公司 動態調整顯示螢幕色彩的方法

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102241672B1 (ko) * 2013-04-30 2021-04-16 소니 주식회사 송신 장치, 송신 방법, 수신 장치 및 수신 방법
US10476693B2 (en) * 2014-02-24 2019-11-12 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
EP3329673A1 (en) * 2015-08-28 2018-06-06 ARRIS Enterprises LLC Color volume transforms in coding of high dynamic range and wide color gamut sequences
US11102495B2 (en) * 2016-05-17 2021-08-24 Qualcomm Incorporated Methods and systems for generating and processing content color volume messages for video
UA124806C2 (uk) * 2016-10-05 2021-11-24 Долбі Леборетеріз Лайсенсінг Корпорейшн Обмін повідомленнями з інформацією про вихідний колірний об'єм
WO2020000135A1 (zh) * 2018-06-25 2020-01-02 华为技术有限公司 一种包含字幕的高动态范围视频处理的方法及装置
JP2020022118A (ja) 2018-08-02 2020-02-06 ソニーセミコンダクタソリューションズ株式会社 受信装置、通信システム、および、受信装置の制御方法
US10652512B1 (en) * 2018-11-20 2020-05-12 Qualcomm Incorporated Enhancement of high dynamic range content
US10791296B2 (en) * 2018-11-23 2020-09-29 Sony Corporation Apparatus and method for tuner control by middleware
JP7118911B2 (ja) 2019-03-08 2022-08-16 株式会社東芝 画像処理装置
US11838680B2 (en) 2021-08-06 2023-12-05 Sony Group Corporation Techniques for ATSC 3.0 broadcast boundary area management using complete service reception during scan to determine signal quality of frequencies carrying the duplicate service
WO2023012727A1 (en) * 2021-08-06 2023-02-09 Sony Group Corporation Techniques for atsc 3.0 broadcast boundary area management using signal quality and packet errors to differentiate between duplicated services on different frequencies during scan
US11601707B2 (en) 2021-08-06 2023-03-07 Sony Group Corporation Techniques for ATSC 3.0 broadcast boundary area management using plural tuners
US11611792B2 (en) 2021-08-06 2023-03-21 Sony Group Corporation ATSC 3 reception across boundary conditions using location data
US11611799B2 (en) 2021-08-06 2023-03-21 Sony Group Corporation ATSC 3 application context switching and sharing
US11848716B2 (en) 2021-08-06 2023-12-19 Sony Group Corporation Techniques for ATSC 3.0 broadcast boundary area management using signal quality and packet errors to differentiate between duplicated services on different frequencies during scan
US11611790B2 (en) 2021-08-06 2023-03-21 Sony Group Corporation RF channel description for multiple frequency networks
US11711568B2 (en) 2021-08-06 2023-07-25 Sony Group Corporation Techniques for ATSC 3.0 broadcast boundary area management using plural tuners handing off between presentation and scanning
US11962545B2 (en) 2021-12-27 2024-04-16 Samsung Electronics Co., Ltd. Method and device for providing chatbot participating chat service
CN114693567B (zh) * 2022-05-30 2022-09-20 深圳思谋信息科技有限公司 图像颜色调整方法、装置、计算机设备和存储介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009038409A2 (en) * 2007-09-21 2009-03-26 Lg Electronics Inc. Digital broadcasting system and method of processing data in digital broadcasting system
CN104301705B (zh) * 2009-02-01 2016-09-07 Lg电子株式会社 广播接收机和三维视频数据处理方法
EP2422522A1 (en) * 2009-04-20 2012-02-29 Dolby Laboratories Licensing Corporation Directed interpolation and data post-processing
WO2010147289A1 (en) * 2009-06-16 2010-12-23 Lg Electronics Inc. Broadcast transmitter, broadcast receiver and 3d video processing method thereof
WO2012070901A2 (ko) * 2010-11-24 2012-05-31 엘지전자 주식회사 부가 서비스 수신 방법 및 그를 이용한 영상 표시 장치
US10349077B2 (en) * 2011-11-21 2019-07-09 Canon Kabushiki Kaisha Image coding apparatus, image coding method, image decoding apparatus, image decoding method, and storage medium
WO2013165687A1 (en) * 2012-04-30 2013-11-07 Dolby Laboratories Licensing Corporation Reference card for scene referred metadata capture
EP3008902A1 (en) * 2013-06-10 2016-04-20 Thomson Licensing Encoding and decoding methods for adapting the average luminance of high dynamic range pictures and corresponding encoder and decoder
JP6038360B2 (ja) * 2013-06-17 2016-12-07 ドルビー ラボラトリーズ ライセンシング コーポレイション エンハンストダイナミックレンジ信号の階層符号化のための適応的再構成
EP2819414A3 (en) * 2013-06-28 2015-02-25 Samsung Electronics Co., Ltd Image processing device and image processing method
KR102176398B1 (ko) * 2013-06-28 2020-11-09 삼성전자주식회사 영상처리장치 및 영상처리방법
JP2016530780A (ja) * 2013-07-14 2016-09-29 エルジー エレクトロニクス インコーポレイティド デジタル放送システムにおける高品質の色感表現のための超高画質放送信号送受信方法及び装置
US9483816B2 (en) * 2013-09-03 2016-11-01 Litel Instruments Method and system for high accuracy and reliability registration of multi modal imagery
KR101797504B1 (ko) * 2013-10-29 2017-11-15 엘지전자 주식회사 Hevc 기반의 ip 방송 서비스 제공을 위한 방송 신호 송수신 방법 및 장치
KR101797505B1 (ko) * 2013-11-13 2017-12-12 엘지전자 주식회사 Hdr 방송 서비스 제공을 위한 방송 신호 송수신 방법 및 장치
EP3094096B1 (en) * 2014-01-06 2018-09-26 LG Electronics Inc. Method and device for transmitting and receiving broadcast signal on basis of color gamut resampling
WO2015119477A1 (ko) * 2014-02-10 2015-08-13 엘지전자 주식회사 3d (3-dimentional) 방송 서비스를 위한 방송 신호 송수신 방법 및 장치
EP3329679A1 (en) * 2015-07-28 2018-06-06 VID SCALE, Inc. High dynamic range video coding architectures with multiple operating modes

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI763074B (zh) * 2020-10-12 2022-05-01 宏碁股份有限公司 動態調整顯示螢幕色彩的方法

Also Published As

Publication number Publication date
JP2018532294A (ja) 2018-11-01
WO2017030425A1 (ko) 2017-02-23
EP3340636A1 (en) 2018-06-27
CN107925780A (zh) 2018-04-17
EP3340636A4 (en) 2019-01-09
US20190007709A1 (en) 2019-01-03
CN107925780B (zh) 2021-03-19

Similar Documents

Publication Publication Date Title
JP6633739B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
US11178436B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US10841627B2 (en) Broadcast signal transmission method, broadcast signal reception method, broadcast signal transmission apparatus, and broadcast signal reception apparatus
US11323755B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US20230007316A1 (en) Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US10171849B1 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US10349095B2 (en) Transmission device for processing video data related to HDR/SDR and method for controlling the same
US10666549B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method and broadcast signal reception method
US10616618B2 (en) Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method and broadcast signal receiving method
KR102023018B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10237591B2 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
EP3448043B1 (en) Broadcast signal transmission/reception method and apparatus for providing high-quality media in dash-based system

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180322

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180322

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190214

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190226

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190524

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20191112

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191212

R150 Certificate of patent or registration of utility model

Ref document number: 6633739

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250