(57)【要約】本発明は、放送信号を送信する方法を提案する。本発明に係る放送信号を送信する方法は、地上波放送網及びインターネット網を用いる次世代ハイブリッド放送をサポートする環境で次世代放送サービスをサポートすることができるシステムを提案する。また、次世代ハイブリッド放送をサポートする環境で、地上波放送網とインターネット網の両方で利用可能な効率的なシグナリング方案を提案する。【選択図】図３３
2018517329.tif 000002
【特許請求の範囲】
【請求項１】
放送サービスのサービスデータ及び前記放送サービスをシグナリングするサービスシグナリング情報を生成するステップであって、前記サービスデータは、前記放送サービスに含まれるサービスコンポーネントを含む、ステップと、
サービスリストテーブルを生成するステップであって、前記サービスリストテーブルは、前記サービスシグナリング情報が伝達される伝送セッションを識別するブートストラップ情報を含む、ステップと、
前記サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして処理するステップと、
前記ＩＰパケットを処理して放送信号を生成し、前記放送信号を放送網を介して伝送するステップとを含む、放送信号送信方法。
【請求項２】
前記サービスシグナリング情報はＵＳＢＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を含み、
前記ＵＳＢＤは、前記放送サービスに関連する技術的情報を記述するシグナリングハブとして動作する、請求項１に記載の放送信号送信方法。
【請求項３】
前記ＵＳＢＤは、サービスタイプ情報をさらに含み、
前記サービスタイプ情報は、複数のサービスコンポーネントが組み合わされてサービスを提供する場合、前記サービスのタイプを示す、請求項２に記載の放送信号送信方法。
【請求項４】
前記放送サービスの前記サービスシグナリング情報がＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される場合、
前記サービスシグナリング情報は、ビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）に関する情報をさらに含み、
前記ビューポジションに関する情報は、３Ｄサービスのためのサービスコンポーネントが右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるか否かを示す右側視点情報を含む、請求項２に記載の放送信号送信方法。
【請求項５】
前記放送サービスの前記サービスシグナリング情報がＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される場合、
前記サービスシグナリング情報は、ビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）に関する情報をさらに含み、
前記ビューポジションに関する情報は、マルチビューサービスのためのサービスコンポーネントが含む視点（ｖｉｅｗ）の総数に対する視点個数情報、及び各視点の位置を示す視点位置情報を含む、請求項２に記載の放送信号送信方法。
【請求項６】
前記サービスデータは、原本ソースビデオに関する情報をＳＥＩ（ｓｕｐｐｌｅｍｅｎｔａｌ  ｅｎｈａｎｃｅｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ）メッセージとして含む、請求項１に記載の放送信号送信方法。
【請求項７】
前記原本ソースビデオに関する情報は、プロダクションフォーマットの解像度情報及びフレームレート情報を含む、請求項６に記載の放送信号送信方法。
【請求項８】
放送サービスのサービスデータ及び前記放送サービスをシグナリングするサービスシグナリング情報を生成するサービスデータ生成部であって、前記サービスデータは、前記放送サービスに含まれるサービスコンポーネントを含む、サービスデータ生成部と、
サービスリストテーブルを生成する下位レベルシグナリング（ｌｏｗ  ｌｅｖｅｌ  ｓｉｇｎａｌｉｎｇ）生成部であって、前記サービスリストテーブルは、前記サービスシグナリング情報が伝達される伝送セッションを識別するブートストラップ情報を含む、下位レベルシグナリング生成部と、
前記サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして処理する伝送レイヤ処理部と、
前記ＩＰパケットを処理して放送信号を生成し、前記放送信号を放送網を介して伝送するフィジカルレイヤ処理部とを含む、放送信号送信装置。
【請求項９】
前記サービスシグナリング情報はＵＳＢＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）を含み、
前記ＵＳＢＤは、前記放送サービスに関連する技術的情報を記述するシグナリングハブとして動作する、請求項８に記載の放送信号送信装置。
【請求項１０】
前記ＵＳＢＤは、サービスタイプ情報をさらに含み、
前記サービスタイプ情報は、複数のサービスコンポーネントが組み合わされてサービスを提供する場合、前記サービスのタイプを示す、請求項９に記載の放送信号送信装置。
【請求項１１】
前記放送サービスの前記サービスシグナリング情報がＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される場合、
前記サービスシグナリング情報は、ビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）に関する情報をさらに含み、
前記ビューポジションに関する情報は、３Ｄサービスのためのサービスコンポーネントが右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるか否かを示す右側視点情報を含む、請求項９に記載の放送信号送信装置。
【請求項１２】
前記放送サービスの前記サービスシグナリング情報がＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）プロトコルによって伝達される場合、
前記サービスシグナリング情報は、ビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）に関する情報をさらに含み、
前記ビューポジションに関する情報は、マルチビューサービスのためのサービスコンポーネントが含む視点（ｖｉｅｗ）の総数に対する視点個数情報、及び各視点の位置を示す視点位置情報を含む、請求項９に記載の放送信号送信装置。
【請求項１３】
前記サービスデータは、原本ソースビデオに関する情報をＳＥＩ（ｓｕｐｐｌｅｍｅｎｔａｌ  ｅｎｈａｎｃｅｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ）メッセージとして含む、請求項８に記載の放送信号送信装置。
【請求項１４】
前記原本ソースビデオに関する情報は、プロダクションフォーマットの解像度情報及びフレームレート情報を含む、請求項１３に記載の放送信号送信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号を送受信する方法に関する。
【背景技術】
【０００２】
アナログ放送信号の送信が終了するに伴い、デジタル放送信号を送受信するための様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてさらに多くの量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加えて、様々なタイプの付加データをさらに含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
デジタル放送システムは、ＵＨＤ（Ｕｌｔｒａ  Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉ  ｃｈａｎｎｅｌ：多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかし、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。
【課題を解決するための手段】
【０００４】
本発明の目的によって、ここに含まれ、概略的に記載されたように、本発明は、地上波放送網及びインターネット網を用いる次世代ハイブリッド放送をサポートする環境で次世代放送サービスを効果的にサポートすることができるシステム及び関連するシグナリング方案を提案する。
【発明の効果】
【０００５】
本発明は、地上波放送網及びインターネット網を用いる次世代ハイブリッド放送をサポートする環境で次世代放送サービスを効果的にサポートすることができる。
【０００６】
本発明は、放送サービスに含まれるサービスコンポーネントに対して、詳細なシグナリングを提供する方法をサポートすることができる。
【０００７】
本発明は、放送サービスを伝達する方案において、３Ｄ、キャプション、ＷＣＧ、ＨＤＲなどの様々な情報を効率的に提供する方法をサポートすることができる。
【図面の簡単な説明】
【０００８】
本発明の更なる理解を提供するために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に、本発明の実施例を示す。
【図１】本発明の一実施例に係るプロトコルスタックを示す図である。
【図２】本発明の一実施例に係るサービスディスカバリ手続を示す図である。
【図３】本発明の一実施例に係るＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）を示す図である。
【図４】本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。
【図５】本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。
【図６】本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ  Ｌａｙｅｒ）動作を示す図である。
【図７】本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）を示す図である。
【図８】本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す図である。
【図９】本発明の一実施例に係るタイムインタリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す図である。
【図１０】本発明の一実施例に係る周波数インタリーバに含まれた各ＦＦＴモードによるメイン−ＰＲＢＳ生成器とサブ−ＰＲＢＳ生成器で構成されたインタリービングアドレス生成器のブロックダイヤグラムを示す図である。
【図１１】本発明の一実施例に係るハイブリッド放送受信装置を示す図である。
【図１２】本発明の一実施例に係るＤＡＳＨベースの適応型（Ａｄａｐｔｉｖｅ）ストリーミングモデルの全般的な動作を示す図である。
【図１３】本発明の一実施例に係る受信機のブロックダイヤグラムを示す図である。
【図１４】本発明の一実施例に係るメディアファイルの構造を示す図である。
【図１５】本発明の一実施例に係るＳＬＴを介したブートストラッピング過程を示す図である。
【図１６】本発明の一実施例に係るＭＭＴプロトコルベースのシグナリングの流れを示す図である。
【図１７】本発明の一実施例に係るケイパビリティディスクリプタを示す図である。
【図１８】本発明の一実施例に係るケイパビリティコードを示す図である。
【図１９】本発明の他の実施例に係るＵＳＢＤの一部を示す図である。
【図２０】本発明の一実施例に係るＭＰテーブルの一部を示す図である。
【図２１】本発明の一実施例に係るアセットグループディスクリプタを示す図である。
【図２２】本発明の一実施例に係る接近（近接）性（ａｃｃｅｓｓｉｂｉｌｉｔｙ）情報を示す図である。
【図２３】本発明の一実施例に係る、ＵＳＢＤ内のＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを示す図である。
【図２４】本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報を示す図である。
【図２５】本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報を示す図である。
【図２６】本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報の活用を示す図である。
【図２７】本発明の一実施例に係るＨＥＶＣビデオコンポーネントディスクリプション情報を示す図である。
【図２８】本発明の一実施例に係るＨＥＶＣタイミング＆ＨＲＤ情報を示す図である。
【図２９】本発明の一実施例に係るキャプション（ｃａｐｔｉｏｎ）情報を示す図である。
【図３０】本発明の一実施例に係るＨＤＲ情報を示す図である。
【図３１】本発明の一実施例に係るＷＣＧ情報を示す図である。
【図３２】本発明の一実施例に係るＨＦＲ情報／プルダウン（Ｐｕｌｌ  Ｄｏｗｎ）情報を示す図である。
【図３３】本発明の一実施例に係る３Ｄサービス及びマルチビューサービス関連シグナリング情報を示す図である。
【図３４】本発明の一実施例に係る、ＨＤＲ情報処理能力に基づいた受信機のメディアエンジンの動作を示す図である。
【図３５】本発明の一実施例に係る、ＷＣＧ情報処理能力に基づいた受信機のメディアエンジンの動作を示す図である。
【図３６】本発明の一実施例に係る、ＨＦＲ情報処理能力に基づいた受信機のメディアエンジンの動作を示す図である。
【図３７】本発明の一実施例に係る、プルダウンリカバリー情報処理能力に基づいた受信機のメディアエンジンの動作を示す図である。
【図３８】本発明の一実施例に係る３Ｄサービスをサポートするためのメタデータを示す図である。
【図３９】本発明の一実施例に係るバー（ｂａｒ）に対するメタデータを示す図である。
【図４０】本発明の一実施例に係るオリジナルソースフォーマットに関するメタデータを示す図である。
【図４１】本発明の一実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてレターボックスを生成する方法を示す図である。
【図４２】本発明の他の実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてレターボックスを生成する方法を示す図である。
【図４３】本発明の一実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてピラーボックス（ｐｉｌｌａｒｂｏｘ）を生成する方法を示す図である。
【図４４】本発明の他の実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてピラーボックスを生成する方法を示す図である。
【図４５】本発明の一実施例に係る放送信号を送信する方法を示す図である。
【図４６】本発明の一実施例に係る放送信号を送信する装置を示す図である。
【発明を実施するための最良の形態】
【０００９】
本発明の好適な実施例について具体的に説明し、その例を添付の図面に示す。添付の図面を参照した下記の詳細な説明は、本発明の具現可能な実施例を限定するものではなく、本発明の好適な実施例を説明するためのものである。下記の詳細な説明は、本発明に関する徹底した理解を提供するために細部事項を含む。しかし、当業者にとってはこれらの細部事項無しにも本発明の実行が可能であるということは明らかである。
【００１０】
本発明で使われる大部分の用語は、当該分野で広く使われる一般的なものから選択されるが、一部の用語は出願人によって任意に選択されてもよく、その意味は、必要時に次の説明で詳しく説明する。したがって、本発明は、用語の単純な名称や意味ではなく、用語の意図された意味に基づいて理解しなければならない。
【００１１】
本発明は、次世代放送サービスに対する放送信号の送信及び受信装置並びに方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）又はＭＩＭＯ方式によって次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式、ＳＩＳＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）方式などを含むことができる。本発明は、特定の用途に要求される性能を達成すると共に、受信機の複雑度を最小化するために最適化されたフィジカルプロファイル（又はシステム）を提案する。
【００１２】
図１は、本発明の一実施例に係るプロトコルスタックを示す図である。
【００１３】
サービスを複数個のレイヤを経て受信機に伝達することができる。まず、送信側ではサービスデータを生成することができる。送信側のデリバリレイヤでは、サービスデータに、伝送のための処理を行い、フィジカルレイヤでは、これを放送信号にエンコードして、放送網又はブロードバンドを介して伝送することができる。
【００１４】
ここで、サービスデータは、ＩＳＯ  ＢＭＦＦ（ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）によるフォーマットで生成することができる。ＩＳＯ  ＢＭＦＦメディアファイルは、放送網／ブロードバンドデリバリ、メディアエンカプセレーション（ｍｅｄｉａ  ｅｎｃａｐｓｕｌａｔｉｏｎ）及び／又は同期化フォーマット（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｆｏｒｍａｔ）で用いることができる。ここで、サービスデータは、サービスに関連した全てのデータであり、リニアサービスを構成するサービスコンポーネント、それに対するシグナリング情報、ＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）データ、その他のファイルなどを含む概念であってもよい。
【００１５】
デリバリレイヤについて説明する。デリバリレイヤはサービスデータに対する伝送機能を提供することができる。サービスデータは、放送網及び／又はブロードバンドを介して伝達することができる。
【００１６】
放送網を介したサービスデリバリ（ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）において、２つの方法を挙げることができる。
【００１７】
第一の方法は、ＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）に基づいて、サービスデータをＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔｓ）として処理し、これをＭＭＴＰ（ＭＭＴ  ｐｒｏｔｏｃｏｌ）を用いて伝送することができる。この場合、ＭＭＴＰによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント及び／又はそれに関するサービスシグナリング情報などを含むことができる。
【００１８】
第二の方法は、ＭＰＥＧ  ＤＡＳＨに基づいて、サービスデータをＤＡＳＨセグメントとして処理し、これをＲＯＵＴＥ（Ｒｅａｌ  ｔｉｍｅ  Ｏｂｊｅｃｔ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を用いて伝送することができる。この場合、ＲＯＵＴＥプロトコルによって伝達されるサービスデータは、リニアサービスのためのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。すなわち、ＮＲＴデータ及びファイルなどのノンタイムド（ｎｏｎ  ｔｉｍｅｄ）データは、ＲＯＵＴＥを用いて伝達することができる。
【００１９】
ＭＭＴＰ又はＲＯＵＴＥプロトコルによって処理されたデータは、ＵＤＰ／ＩＰレイヤを経てＩＰパケットとして処理することができる。放送網を介したサービスデータ伝達において、ＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）もＵＤＰ／ＩＰレイヤを経て放送網を介して伝達することができる。ＳＬＴは、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）テーブルに含めて伝達することができる。ＳＬＴ、ＬＬＳテーブルについては後述する。
【００２０】
ＩＰパケットはリンクレイヤでリンクレイヤパケットとして処理されてもよい。リンクレイヤは、上位レイヤから伝達される様々なフォーマットのデータを、リンクレイヤパケットとしてエンカプセレーションした後、フィジカルレイヤに伝達することができる。リンクレイヤについては後述する。
【００２１】
ハイブリッドサービスデリバリ（ｈｙｂｒｉｄ  ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）においては、少なくとも１つのサービスエレメントをブロードバンドパス（ｐａｔｈ）を通じて伝達することができる。ハイブリッドサービスデリバリの場合、ブロードバンドで伝達されるデータは、ＤＡＳＨフォーマットのサービスコンポーネント、それに関するサービスシグナリング情報、及び／又はＮＲＴデータなどを含むことができる。これらのデータはＨＴＴＰ／ＴＣＰ／ＩＰを経て処理され、ブロードバンド伝送のためのリンクレイヤを経て、ブロードバンド伝送のためのフィジカルレイヤに伝達されてもよい。
【００２２】
フィジカルレイヤは、デリバリレイヤ（上位レイヤ及び／又はリンクレイヤ）から伝達されたデータを処理して、放送網又はブロードバンドを介して伝送することができる。フィジカルレイヤに関する詳細な事項は後述する。
【００２３】
サービスについて説明する。サービスは、全体的にユーザに示すサービスコンポーネントのコレクションであり、コンポーネントは、様々なメディアタイプのものであり、サービスは、連続的又は間欠的であり、サービスは、実時間又は非実時間であってもよく、実時間サービスは、ＴＶ番組のシーケンスで構成することができる。
【００２４】
サービスは種々のタイプを有することができる。第一に、サービスはアプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオサービス又はオーディオだけのサービスであってもよい。第二に、サービスは、ダウンロードされたアプリケーションによってその再生／構成などが制御されるアプリベースのサービスであってもよい。第三に、サービスは、ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）を提供するＥＳＧサービスであってもよい。第四に、緊急警報情報を提供するＥＡ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ）サービスであってもよい。
【００２５】
アプリベースのエンハンスメントを有しないリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、又は（２）１つ以上のＭＭＴＰセッションで伝達することができる。
【００２６】
アプリベースのエンハンスメントを有するリニアサービスを放送網を介して伝達する場合、サービスコンポーネントを、（１）１つ以上のＲＯＵＴＥセッション、及び（２）０個以上のＭＭＴＰセッションで伝達してもよい。この場合、アプリベースのエンハンスメントに用いられるデータは、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達してもよい。本発明の一実施例において、１つのサービスのリニアサービスコンポーネント（ストリーミングメディアコンポーネント）が２つのプロトコルによって同時に伝達されることを許容しなくてもよい。
【００２７】
アプリベースのサービスを放送網を介して伝達する場合、サービスコンポーネントを、１つ以上のＲＯＵＴＥセッションで伝達することができる。この場合、アプリベースのサービスに用いられるサービスデータを、ＮＲＴデータ又はその他のファイルなどの形態でＲＯＵＴＥセッションを通じて伝達することができる。
【００２８】
また、このようなサービスの一部のサービスコンポーネント又は一部のＮＲＴデータ、ファイルなどをブロードバンドを介して伝達してもよい（ハイブリッドサービスデリバリ）。
【００２９】
すなわち、本発明の一実施例で、一つのサービスのリニアサービスコンポーネントをＭＭＴプロトコルによって伝達することができる。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネント及びＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。本発明の他の実施例で、一つのサービスのリニアサービスコンポーネントは、ＭＭＴプロトコルによって伝達し、ＮＲＴデータ（ＮＲＴサービスコンポーネント）は、ＲＯＵＴＥプロトコルによって伝達してもよい。これらの実施例において、サービスの一部のサービスコンポーネント又は一部のＮＲＴデータは、ブロードバンドを介して伝達してもよい。ここで、アプリベースのサービス又はアプリベースのエンハンスメントに関するデータはＮＲＴデータ形態で、ＲＯＵＴＥによる放送網を介して伝達したり、ブロードバンドを介して伝達してもよい。ＮＲＴデータは、ローカリキャッシュドデータ（Ｌｏｃａｌｌｙ  ｃａｓｈｅｄ  ｄａｔａ）などと呼ぶこともできる。
【００３０】
それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的に又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリにおいて、ＬＣＴセッションはオーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアはＤＡＳＨセグメントとしてフォーマットされる。
【００３１】
それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全体又は一部のコンテンツコンポーネントを伝達する１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。
【００３２】
ＮＲＴユーザサービス又はシステムメタデータのデリバリのために、ＬＣＴセッションはファイルベースのコンテンツアイテムを伝達する。これらのコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、サービスシグナリング、又はＥＳＧフラグメントのようなメタデータで構成することができる。サービスシグナリング又はＥＳＧフラグメントのようなシステムメタデータのデリバリも、ＭＭＴＰのシグナリングメッセージモードで行うことができる。
【００３３】
受信機では、チューナが周波数をスキャニングするが、特定周波数で放送シグナルを感知することができる。受信機は、ＳＬＴを抽出してその処理モジュールに送ることができる。ＳＬＴパーサーは、ＳＬＴをパースし、データを取得してチャネルマップに保存することができる。受信機は、ＳＬＴのブートストラップ情報を取得してＲＯＵＴＥ又はＭＭＴクライアントに伝達することができる。これによって受信機はＳＬＳを取得して保存することができる。ＵＳＢＤなどを取得することができ、これはシグナリングパーサーによってパースされてもよい。
【００３４】
図２は、本発明の一実施例に係るサービスディスカバリ手続を示す図である。
【００３５】
フィジカルレイヤの放送信号フレームが伝達するブロードキャストストリームは、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）を運搬することができる。ＬＬＳデータは、フェルノウン（ｗｅｌｌ  ｋｎｏｗｎ）ＩＰアドレス／ポートに伝達されるＩＰパケットのペイロードで運搬することができる。このＬＬＳはそのタイプによってＳＬＴを含むことができる。ＬＬＳデータは、ＬＬＳテーブルの形態にフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの始めであってもよい。図示の実施例とは違い、ＬＬＳデータを伝達するＩＰストリームは、他のサービスデータと共に同一のＰＬＰを介して伝達してもよい。
【００３６】
ＳＬＴは、高速のチャネルスキャンによって受信機がサービスリストを生成できるようにし、ＳＬＳをロケーティング（ｌｏｃａｔｉｎｇ）するためのアクセス情報を提供する。ＳＬＴは、ブートストラップ情報を含むが、このブートストラップ情報は、受信機がそれぞれのサービスに対するＳＬＳ（Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を取得できるようにする。ＳＬＳ、すなわち、サービスシグナリング情報がＲＯＵＴＥで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＬＣＴチャネル又はそのＬＣＴチャネルを含むＲＯＵＴＥセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。ＳＬＳがＭＭＴで伝達される場合、ブートストラップ情報は、ＳＬＳを運搬するＭＭＴＰセッションのデスティネーションＩＰアドレス及びデスティネーションポート情報を含むことができる。
【００３７】
図示された実施例で、ＳＬＴが記述するサービス＃１のＳＬＳはＲＯＵＴＥで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＬＣＴチャネルを含むＲＯＵＴＥセッションに対するブートストラップ情報（ｓＩＰ１，ｄＩＰ１，ｄＰｏｒｔ１）を含むことができる。ＳＬＴが記述するサービス＃２のＳＬＳはＭＭＴで伝達され、ＳＬＴは、当該ＳＬＳが伝達されるＭＭＴＰパケットフローを含むＭＭＴＰセッションに対するブートストラップ情報（ｓＩＰ２，ｄＩＰ２，ｄＰｏｒｔ２）を含むことができる。
【００３８】
ＳＬＳは、当該サービスに対する特性を記述するシグナリング情報であり、当該サービス及び当該サービスのサービスコンポーネントを取得するための情報を提供したり、当該サービスを有意に再生するための受信機キャパビリティ情報などを含むことができる。各サービスに対して別個のサービスシグナリングを有すると、受信機は、ブロードキャストストリーム内で伝達される全てのＳＬＳをパースしないで、所望のサービスに対する適切なＳＬＳを取得すればよい。
【００３９】
ＳＬＳをＲＯＵＴＥプロトコルによって伝達する場合、ＳＬＳを、ＳＬＴが示すＲＯＵＴＥセッションの特定（ｄｅｄｉｃａｔｅｄ）のＬＣＴチャネルを介して伝達することができる。実施例によって、このＬＣＴチャネルはｔｓｉ＝０と識別されるＬＣＴチャネルであってもよい。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｂｕｎｄｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ／Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ−ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｎｓｔａｎｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）及び／又はＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を含むことができる。
【００４０】
ここで、ＵＳＢＤ又はＵＳＤは、ＳＬＳフラグメントの一つであり、サービスの具体的な技術的情報を記述するシグナリングハブの役割を担うことができる。ＵＳＢＤは、サービス識別情報、デバイスキャパビリティ情報などを含むことができる。ＵＳＢＤは、他のＳＬＳフラグメント（Ｓ−ＴＳＩＤ、ＭＰＤなど）へのリファレンス情報（ＵＲＩリファレンス）を含むことができる。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれリファレンシングすることができる。また、ＵＳＢＤは、受信機が伝送モード（放送網／ブロードバンド）を決定できるようにするメタデータ情報をさらに含むことができる。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。
【００４１】
Ｓ−ＴＳＩＤは、ＳＬＳフラグメントの一つであり、当該サービスのサービスコンポーネントを運搬する伝送セッションに対する全体的なセッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッション及び／又はそのＲＯＵＴＥセッションのＬＣＴチャネルに対する伝送セッションデスクリプション情報を提供することができる。Ｓ−ＴＳＩＤは、一つのサービスと関連したサービスコンポーネントのコンポーネント取得（ａｃｑｕｉｓｉｔｉｏｎ）情報を提供することができる。Ｓ−ＴＳＩＤは、ＭＰＤのＤＡＳＨリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と当該サービスコンポーネントのｔｓｉ間のマッピングを提供することができる。Ｓ−ＴＳＩＤのコンポーネント取得情報は、ｔｓｉ、関連ＤＡＳＨリプレゼンテーションの識別子の形態で提供することができ、実施例によってＰＬＰ  ＩＤを含んでも含まなくてもよい。コンポーネント取得情報を用いて、受信機は一つのサービスのオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディアセグメントのバッファリング、デコーディングなどを行うことができる。Ｓ−ＴＳＩＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。Ｓ−ＴＳＩＤの具体的な内容については後述する。
【００４２】
ＭＰＤは、ＳＬＳフラグメントの一つであり、当該サービスのＤＡＳＨメディアプレゼンテーションに関するデスクリプションを提供することができる。ＭＰＤは、メディアセグメントに対するリソース識別子（ｒｅｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ）を提供し、識別されたリソースに対するメディアプレゼンテーション内におけるコンテクスト情報を提供することができる。ＭＰＤは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（サービスコンポーネント）を記述し、またブロードバンドを介して伝達される追加的なＤＡＳＨリプレゼンテーションを記述することができる（ハイブリッドデリバリ）。ＭＰＤは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
【００４３】
ＳＬＳをＭＭＴプロトコルによって伝達する場合、ＳＬＳは、ＳＬＴが示すＭＭＴＰセッションの特定（ｄｅｄｉｃａｔｅｄ）ＭＭＴＰパケットフローで伝達することができる。実施例によって、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄは００の値を有することができる。この場合、ＳＬＳは、ＵＳＢＤ／ＵＳＤ及び／又はＭＭＴ  Ｐａｃｋａｇｅ（ＭＰ）テーブルを含むことができる。
【００４４】
ここで、ＵＳＢＤは、ＳＬＳフラグメントの一つであり、ＲＯＵＴＥにおけるそれと同様にサービスの具体的な技術的情報を記述することができる。ここでのＵＳＢＤも、他のＳＬＳフラグメントへのリファレンス情報（ＵＲＩリファレンス）を含むことができる。ＭＭＴのＵＳＢＤは、ＭＭＴシグナリングのＭＰテーブルをリファレンシングすることができる。実施例によって、ＭＭＴのＵＳＢＤは、Ｓ−ＴＳＩＤ及び／又はＭＰＤへのリファレンス情報も含むことができる。ここで、Ｓ−ＴＳＩＤは、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのためのものであってもよい。ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される場合にも、ＮＲＴデータはＲＯＵＴＥプロトコルによって伝達され得るからである。ＭＰＤは、ハイブリッドサービスデリバリにおいて、ブロードバンドで伝達されるサービスコンポーネントのためのものであってもよい。ＭＭＴのＵＳＢＤの具体的な内容については後述する。
【００４５】
ＭＰテーブルは、ＭＰＵコンポーネントのためのＭＭＴのシグナリングメッセージであり、当該サービスのサービスコンポーネントを運搬するＭＭＴＰセッションに対する全体的なセッションデスクリプション情報を提供することができる。また、ＭＰテーブルは、このＭＭＴＰセッションを通じて伝達されるアセット（Ａｓｓｅｔ）に対するデスクリプションを含むことができる。ＭＰテーブルは、ＭＰＵコンポーネントのためのストリーミングシグナリング情報であり、一つのサービスに該当するアセットのリストとこれらのコンポーネントのロケーション情報（コンポーネント取得情報）を提供することができる。ＭＰテーブルの具体的な内容は、ＭＭＴで定義された形態であってもよく、変形された形態であってもよい。ここでいうアセットは、マルチメディアデータエンティティであり、１つのユニークＩＤで連合し、１つのマルチメディアプレゼンテーションを生成するために用いられるデータエンティティを意味することができる。アセットは、一つのサービスを構成するサービスコンポーネントに該当してもよい。ＭＰテーブルを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。ＭＰテーブルは、前述したように、ＵＳＢＤによってリファレンシングされてもよい。
【００４６】
その他のＭＭＴシグナリングメッセージを定義することもできる。このようなＭＭＴシグナリングメッセージによってＭＭＴＰセッション又はサービスに関連した追加の情報を記述することができる。
【００４７】
ＲＯＵＴＥセッションはソースＩＰアドレス、デスティネーションＩＰアドレス、デスティネーションポートナンバーによって識別される。ＬＣＴセッションはペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔ  ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＭＭＴＰセッションはデスティネーションＩＰアドレス及びデスティネーションポートナンバーによって識別される。ＭＭＴＰパケットフローはペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ＿ｉｄによって識別される。
【００４８】
ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャネルと呼ぶことができる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャネルと呼ぶことができる。
【００４９】
図示した実施例とは違い、１つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰで伝達されてもよい。すなわち、１つのサービスは１つ以上のＰＬＰを介して伝達されてもよい。図示とは違い、実施例によって、１つのサービスを構成するコンポーネントが別個のＲＯＵＴＥセッションで伝達されてもよい。また、実施例によって、１つのサービスを構成するコンポーネントが別個のＭＭＴＰセッションで伝達されてもよい。実施例によって、１つのサービスを構成するコンポーネントがＲＯＵＴＥセッションとＭＭＴＰセッションとに分けて伝達されてもよい。図示してはいないが、１つのサービスを構成するコンポーネントがブロードバンドを介して伝達（ハイブリッドデリバリ）されてもよい。
【００５０】
図３は、本発明の一実施例に係るＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）テーブル及びＳＬＴ（Ｓｅｒｖｉｃｅ  Ｌｉｓｔ  Ｔａｂｌｅ）を示す図である。
【００５１】
図示のＬＬＳテーブルの一実施例（ｔ３０１０）は、ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールド、ｐｒｏｖｉｄｅｒ＿ｉｄフィールド、ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールド及び／又はＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドによる情報を含むことができる。
【００５２】
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドは、当該ＬＬＳテーブルのタイプを識別し、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ＬＬＳテーブルによってシグナルされるサービスに関連したサービスプロバイダを識別することができる。ここで、サービスプロバイダは、当該ブロードキャストストリームの全部又は一部を用いるブロードキャスタであり、ｐｒｏｖｉｄｅｒ＿ｉｄフィールドは、当該ブロードキャストストリームを用いている複数のブロードキャスタのうち１つを識別することができる。ＬＬＳ＿ｔａｂｌｅ＿ｖｅｒｓｉｏｎフィールドは、当該ＬＬＳテーブルのバージョン情報を提供することができる。
【００５３】
ＬＬＳ＿ｔａｂｌｅ＿ｉｄフィールドの値によって、当該ＬＬＳテーブルは、前述したＳＬＴ、コンテンツアドバイザリレーティング（Ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ  ｒａｔｉｎｇ）に関連した情報を含むＲＲＴ（Ｒａｔｉｎｇ  Ｒｅｇｉｏｎ  Ｔａｂｌｅ）、システムタイムに関連した情報を提供するＳｙｓｔｅｍＴｉｍｅ情報、緊急警報に関連した情報を提供するＣＡＰ（Ｃｏｍｍｏｎ  Ａｌｅｒｔ  Ｐｒｏｔｏｃｏｌ）メッセージのうち１つを含むことができる。実施例によって、その他の情報がＬＬＳテーブルに含まれてもよい。
【００５４】
図示のＳＬＴの一実施例（ｔ３０２０）は、＠ｂｓｉｄ属性、＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性、ｓｌｔＩｎｅｔＵｒｌエレメント及び／又はＳｅｒｖｉｃｅエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
【００５５】
＠ｂｓｉｄ属性は、ブロードキャストストリームの識別子であってもよい。＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性は、当該ＳＬＴが記述する全てのサービスをデコードして有意に再生するために必要なキャパビリティ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、当該ＳＬＴのサービスのためのＥＳＧ又はサービスシグナリング情報をブロードバンドを介して得るために用いられるベースＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
【００５６】
Ｓｅｒｖｉｃｅエレメントは、当該ＳＬＴが記述するサービスに関する情報を含むエレメントであり、それぞれのサービスに対してＳｅｒｖｉｃｅエレメントが存在してもよい。Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性、＠ｐｒｏｔｅｃｔｅｄ属性、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性、＠ｈｉｄｄｅｎ属性、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性、＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性、ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメント及び／又はｓｖｃＩｎｅｔＵｒｌエレメントを含むことができる。
【００５７】
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、＠ｓｌｔＳｖｃＳｅｑＮｕｍ属性は、当該サービスに対するＳＬＴ情報のシーケンスナンバーを示すことができる。＠ｐｒｏｔｅｃｔｅｄ属性は、当該サービスの有意な再生のために必要な少なくとも１つのサービスコンポーネントが保護（ｐｒｏｔｅｃｔｅｄ）されているか否かを示すことができる。＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ属性と＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ属性はそれぞれ、当該サービスのメジャーチャネルナンバーとマイナーチャネルナンバーを示すことができる。
【００５８】
＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ属性は、当該サービスのカテゴリーを示すことができる。サービスのカテゴリーとしては、リニアＡ／Ｖサービス、リニアオーディオサービス、アプリベースのサービス、ＥＳＧサービス、ＥＡＳサービスなどを挙げることができる。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ属性は、当該サービスの短い名（Ｓｈｏｒｔ  ｎａｍｅ）を提供することができる。＠ｈｉｄｄｅｎ属性は、当該サービスがテスティング又は独占的（ｐｒｏｐｒｉｅｔａｒｙ）な使用のためのサービスであるか否かを示すことができる。＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ属性は、当該サービスの有意な再生のためにブロードバンドアクセスが必要であるか否かを示すことができる。＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性は、当該サービスのデコーディング及び有意な再生のために必要なキャパビリティ情報を提供することができる。
【００５９】
ＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、当該サービスのブロードキャストシグナリングに関連した情報を提供することができる。このエレメントは、当該サービスの放送網を介したシグナリングに対して、ロケーション、プロトコル、アドレスなどの情報を提供することができる。詳細な事項は後述する。
【００６０】
ｓｖｃＩｎｅｔＵｒｌエレメントは、当該サービスのためのシグナリング情報をブロードバンドを介してアクセスするためのＵＲＬ情報を提供することができる。ｓｌｔＩｎｅｔＵｒｌエレメントは、＠ｕｒｌＴｙｐｅ属性をさらに含むことができるが、これは、当該ＵＲＬから得られるデータのタイプを示すことができる。
【００６１】
前述したＢｒｏａｄｃａｓｔＳｖｃＳｉｇｎａｌｉｎｇエレメントは、＠ｓｌｓＰｒｏｔｏｃｏｌ属性、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、＠ｓｌｓＰｌｐＩｄ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、及び／又は＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性を含むことができる。
【００６２】
＠ｓｌｓＰｒｏｔｏｃｏｌ属性は、当該サービスのＳＬＳを伝達するために用いられるプロトコルを示すことができる（ＲＯＵＴＥ、ＭＭＴなど）。＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性はそれぞれ、当該サービスのＳＬＳを伝達するために用いられるプロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
【００６３】
＠ｓｌｓＰｌｐＩｄ属性は、当該サービスのＳＬＳを伝達するＰＬＰを識別するＰＬＰ識別子を提供することができる。実施例によって、このフィールドは省略されてもよく、ＳＬＳが伝達されるＰＬＰ情報は、後述するＬＭＴ内の情報とＳＬＴのブートストラップ情報とを組み合わせて確認してもよい。
【００６４】
＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、当該サービスのＳＬＳを伝達する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート及びソースＩＰアドレスを示すことができる。これらは、ＳＬＳが伝達される伝送セッション（ＲＯＵＴＥセッション又はＭＭＴＰセッション）を識別することができる。これらはブートストラップ情報に含まれてもよい。
【００６５】
図４は、本発明の一実施例に係る、ＲＯＵＴＥで伝達されるＵＳＢＤ及びＳ−ＴＳＩＤを示す図である。
【００６６】
図示されたＵＳＢＤの一実施例（ｔ４０１０）は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
【００６７】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性、＠ｆｕｌｌＭＰＤＵｒｉ属性、＠ｓＴＳＩＤＵｒｉ属性、ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメント及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
【００６８】
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性は、当該サービスのグローバルにユニークな（ｇｌｏｂａｌｌｙ  ｕｎｉｑｕｅ）識別子であり、ＥＳＧデータとリンクされる上で用いられてもよい（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）。＠ｓｅｒｖｉｃｅＩｄ属性は、ＳＬＴの該当のサービスエントリーに対応するリファレンスであり、ＳＬＴのサービスＩＤ情報と同一であってもよい。＠ｓｅｒｖｉｃｅＳｔａｔｕｓ属性は、当該サービスの状態を示すことができる。このフィールドは、当該サービスがアクティブ状態かインアクティブ（ｉｎａｃｔｉｖｅ）状態かを示すことができる。
【００６９】
＠ｆｕｌｌＭＰＤＵｒｉ属性は、当該サービスのＭＰＤフラグメントをリファレンシングすることができる。ＭＰＤは、前述したように、放送網又はブロードバンドを介して伝達されるサービスコンポーネントに対する再生デスクリプションを提供することができる。＠ｓＴＳＩＤＵｒｉ属性は、当該サービスのＳ−ＴＳＩＤフラグメントをリファレンシングすることができる。Ｓ−ＴＳＩＤは、前述したように、当該サービスを運搬する伝送セッションへのアクセスに関連したパラメータを提供することができる。
【００７０】
ｎａｍｅエレメントは、当該サービスの名を提供することができる。このエレメントは、＠ｌａｎｇ属性をさらに含むことができるが、このフィールドは、ｎａｍｅエレメントが提供する名の言語を示すことができる。ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、当該サービスの利用可能な（ａｖａｉｌａｂｌｅ）言語を示すことができる。すなわち、このエレメントは、当該サービスを提供できる言語を羅列することができる。
【００７１】
ｃａｐａｂｉｌｉｔｙＣｏｄｅエレメントは、当該サービスを有意に再生する上で必要な受信機側のキャパビリティ又はキャパビリティグループ情報を示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるキャパビリティ情報フォーマットと互換されてもよい。
【００７２】
ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、当該サービスの放送網又はブロードバンドを介してアクセスされるコンテンツに対して、伝送関連情報を提供することができる。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及び／又はｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。このエレメントはそれぞれ、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。
【００７３】
ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは放送網を介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、当該サービスメディアプレゼンテーションの全てのピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
【００７４】
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、該当のメディアセグメントが放送網を介して伝達されるということを暗示することができる。
【００７５】
ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーションに対する伝送関連情報を含むことができる。このＤＡＳＨリプレゼンテーションは、該当のサービスメディアプレゼンテーションの全ピリオド（Ｐｅｒｉｏｄ）にわたるメディアコンポーネントを含むことができる。
【００７６】
このエレメントのｂａｓｅＰａｔｔｅｒｎエレメントは、受信機がセグメントＵＲＬとマッチするために用いるキャラクタパターンを示すことができる。これは、ＤＡＳＨクライアントが該当のリプレゼンテーションのセグメントを要求するために用いることができる。マッチされるということは、当該メディアセグメントがブロードバンドを介して伝達されるということを暗示することができる。
【００７７】
図示のＳ−ＴＳＩＤの一実施例（ｔ４０２０）は、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ属性及び／又はＲＳエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
【００７８】
＠ｓｅｒｖｉｃｅＩｄ属性は、当該サービスの識別子であり、ＵＳＢＤ／ＵＳＤの当該サービスをリファレンシングすることができる。ＲＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＲＯＵＴＥセッションに関する情報を記述することができる。このようなＲＯＵＴＥセッションの個数によって、このエレメントは複数個存在してもよい。ＲＳエレメントは、＠ｂｓｉｄ属性、＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性、＠ｄｐｏｒｔ属性、＠ＰＬＰＩＤ属性及び／又はＬＳエレメントをさらに含むことができる。
【００７９】
＠ｂｓｉｄ属性は、当該サービスのサービスコンポーネントが伝達されるブロードキャストストリームの識別子であってもよい。このフィールドが省略された場合、デフォルトブロードキャストストリームは、当該サービスのＳＬＳを伝達するＰＬＰを含むブロードキャストストリームであってもよい。このフィールドの値は、ＳＬＴの＠ｂｓｉｄ属性と同じ値であってもよい。
【００８０】
＠ｓＩｐＡｄｄｒ属性、＠ｄＩｐＡｄｄｒ属性及び＠ｄｐｏｒｔ属性はそれぞれ、該当のＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポートを示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳＬＳを伝達する、すなわち、該当のＳ−ＴＳＩＤを伝達している現在の、ＲＯＵＴＥセッションのソースＩＰアドレス、デスティネーションＩＰアドレス及びデスティネーションＵＤＰポート値であってもよい。現在ＲＯＵＴＥセッションでない、当該のサービスのサービスコンポーネントを伝達する他のＲＯＵＴＥセッションに対しては、本フィールドが省略されなくてもよい。
【００８１】
＠ＰＬＰＩＤ属性は、該当のＲＯＵＴＥセッションのＰＬＰ  ＩＤ情報を示すことができる。このフィールドが省略される場合、デフォルト値は、該当のＳ−ＴＳＩＤが伝達されている現在ＰＬＰのＰＬＰ  ＩＤ値であってもよい。実施例によって、このフィールドは省略され、該当のＲＯＵＴＥセッションのＰＬＰ  ＩＤ情報は、後述するＬＭＴ内の情報と、ＲＳエレメントのＩＰアドレス／ＵＤＰポート情報とを組み合わせて確認してもよい。
【００８２】
ＬＳエレメントは、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルに関する情報を記述することができる。このようなＬＣＴチャネルの個数によって、このエレメントは複数個存在してもよい。ＬＳエレメントは、＠ｔｓｉ属性、＠ＰＬＰＩＤ属性、＠ｂｗ属性、＠ｓｔａｒｔＴｉｍｅ属性、＠ｅｎｄＴｉｍｅ属性、ＳｒｃＦｌｏｗエレメント及び／又はＲｅｐａｉｒＦｌｏｗエレメントを含むことができる。
【００８３】
＠ｔｓｉ属性は、該当のＬＣＴチャネルのｔｓｉ情報を示すことができる。これによって、当該サービスのサービスコンポーネントが伝達されるＬＣＴチャネルを識別することができる。＠ＰＬＰＩＤ属性は、該当のＬＣＴチャネルのＰＬＰ  ＩＤ情報を示すことができる。実施例によって、このフィールドは省略されてもよい。＠ｂｗ属性は、該当のＬＣＴチャネルの最大の帯域幅を示すことができる。＠ｓｔａｒｔＴｉｍｅ属性は、該当のＬＣＴセッションのスタートタイムを示し、＠ｅｎｄＴｉｍｅ属性は、該当のＬＣＴチャネルのエンドタイムを示すことができる。
【００８４】
ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローについて記述することができる。ＲＯＵＴＥのソースプロトコルは、デリバリオブジェクトを伝送するために用いられ、１つのＲＯＵＴＥセッション内で少なくとも１つのソースフローを設定（ｅｓｔａｂｌｉｓｈ）することができる。これらのソースフローは、関連したオブジェクトをオブジェクトフローとして伝達することができる。
【００８５】
ＲｅｐａｉｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローについて記述することができる。ソースプロトコルによって伝達されるデリバリオブジェクトは、ＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）によって保護されてもよいが、リペアプロトコルは、このようなＦＥＣプロテクションを可能にするＦＥＣフレームワーク（ｆｒａｍｅｗｏｒｋ）を定義することができる。
【００８６】
図５は、本発明の一実施例に係る、ＭＭＴで伝達されるＵＳＢＤを示す図である。
【００８７】
図示されたＵＳＢＤの一実施例は、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであってもよい。
【００８８】
ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメント、Ｃｈａｎｎｅｌエレメント、ｍｐｕＣｏｍｐｏｎｅｎｔエレメント、ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメント、ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメント及び／又はＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを含むことができる。各フィールドは、図示されたＵｓｅコラムの値によって省略されてもよく、複数個存在してもよい。
【００８９】
＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ属性、＠ｓｅｒｖｉｃｅＩｄ属性、Ｎａｍｅエレメント及び／又はｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントは、当該サービスのコンテンツアドバイザリ（ａｄｖｉｓｏｒｙ）レーティングを示すことができる。これらの情報は、サービスアナウンスメント（ａｎｎｏｕｎｃｃｅｍｅｎｔ）から提供されるコンテンツアドバイザリレーティング情報フォーマットと互換されてもよい。Ｃｈａｎｎｅｌエレメントは、当該サービスに関連した情報を含むことができる。このエレメントの詳細な内容については後述する。
【００９０】
ｍｐｕＣｏｍｐｏｎｅｎｔエレメントは、当該サービスのＭＰＵとして伝達されるサービスコンポーネントに関するデスクリプションを提供することができる。このエレメントは、＠ｍｍｔＰａｃｋａｇｅＩｄ属性及び／又は＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性をさらに含むことができる。＠ｍｍｔＰａｃｋａｇｅＩｄ属性は、当該サービスのＭＰＵとして伝達されるサービスコンポーネントのＭＭＴパッケージ（Ｐａｃｋａｇｅ）をリファレンシングすることができる。＠ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄ属性は、時間上、＠ｍｍｔＰａｃｋａｇｅＩｄ属性がリファレンシングするＭＭＴパッケージの次に用いられるＭＭＴパッケージをリファレンシングすることができる。このエレメントの情報を用いてＭＰテーブルをリファレンシングすることができる。
【００９１】
ｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、ＲＯＵＴＥで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。リニアサービスコンポーネントがＭＭＴプロトコルで伝達される場合であっても、ＮＲＴデータは、前述したように、ＲＯＵＴＥプロトコルによって伝達されてもよい。このエレメントはこのようなＮＲＴデータに関する情報を記述することができる。このエレメントの詳細な内容については後述する。
【００９２】
ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔエレメントは、ブロードバンドで伝達される当該サービスのサービスコンポーネントに関するデスクリプションを含むことができる。ハイブリッドサービスデリバリにおいて、一つのサービスの一部のサービスコンポーネント又はその他のファイルは、ブロードバンドを介して伝達されてもよい。このエレメントは、このようなデータに関する情報を記述することができる。このエレメントは、＠ｆｕｌｌＭＰＤＵｒｉ属性をさらに含むことができる。この属性は、ブロードバンドで伝達されるサービスコンポーネントについて記述するＭＰＤをリファレンシングすることができる。ハイブリッドサービスデリバリの他にも、トンネル内の走行などによって放送信号が弱くなる場合において、放送網−ブロードバンド間のハンドオフ（ｈａｎｄｏｆｆ）を支援するためにこのエレメントが用いられてもよい。放送信号が弱くなる場合、ブロードバンドを介してサービスコンポーネントを取得するが、再び放送信号が強くなると、放送網を介してサービスコンポーネントを取得し、サービスの連続性を保障することができる。
【００９３】
ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、当該サービスのサービスコンポーネントに関する情報を含むことができる。サービスのサービスコンポーネントの個数によって、このエレメントは複数個存在してもよい。このエレメントは、各サービスコンポーネントのタイプ、ロール（ｒｏｌｅ）、名、識別子、プロテクションの有無などの情報を記述することができる。このエレメントの詳細な情報については後述する。
【００９４】
前述したＣｈａｎｎｅｌエレメントは、＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性、＠ｓｅｒｖｉｃｅＩｃｏｎ属性及び／又はＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントをさらに含むことができる。＠ｓｅｒｖｉｃｅＧｅｎｒｅ属性は、当該サービスのジャンルを示し、＠ｓｅｒｖｉｃｅＩｃｏｎ属性は、当該サービスを代表するアイコン（ｉｃｏｎ）のＵＲＬ情報を含むことができる。ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、当該サービスのサービスデスクリプションを提供するが、このエレメントは、＠ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性及び／又は＠ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇ属性をさらに含むことができる。これらの属性はそれぞれ、当該サービスデスクリプションのテキスト及びそのテキストに用いられる言語を示すことができる。
【００９５】
前述したｒｏｕｔｅＣｏｍｐｏｎｅｎｔエレメントは、＠ｓＴＳＩＤＵｒｉ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性、及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性をさらに含むことができる。
【００９６】
＠ｓＴＳＩＤＵｒｉ属性は、Ｓ−ＴＳＩＤフラグメントをリファレンシングすることができる。このフィールドは、前述したＲＯＵＴＥで伝達されるＵＳＢＤの該当のフィールドと同一であってもよい。このＳ−ＴＳＩＤは、ＲＯＵＴＥで伝達されるサービスコンポーネントに対するアクセス関連情報を提供することができる。このＳ−ＴＳＩＤは、ＭＭＴプロトコルによってリニアサービスコンポーネントが伝達される状況で、ＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータのために存在してもよい。
【００９７】
＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ属性、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ属性及び＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ属性はそれぞれ、前述したＳ−ＴＳＩＤを運搬する伝送パケットのデスティネーションＩＰアドレス、デスティネーションＵＤＰポート、ソースＩＰアドレスを示すことができる。すなわち、これらのフィールドは、前述したＳ−ＴＳＩＤを運搬する伝送セッション（ＭＭＴＰセッション又はＲＯＵＴＥセッション）を識別することができる。
【００９８】
＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性及び＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性は、前述したＳ−ＴＳＩＤを伝達するために用いられる伝送プロトコルのメジャーバージョンナンバー及びマイナーバージョンナンバーを示すことができる。
【００９９】
前述したＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性、＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性、＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性、＠ｃｏｍｐｏｎｅｎｔＩｄ属性及び／又は＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性をさらに含むことができる。
【０１００】
＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性は、当該コンポーネントのタイプを示すことができる。例えば、この属性は、当該コンポーネントがオーディオ、ビデオ、クローズドキャプションコンポーネントのいずれであるかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性は、当該コンポーネントのロール（役割）を示すことができる。例えば、この属性は、当該コンポーネントがオーディオコンポーネントである場合、メインオーディオ、ミュージック、コメンタリなどのいずれであるかを示すことができる。該当のコンポーネントがビデオコンポーネントである場合、プライマリビデオであるかなどを示すことができる。当該コンポーネントがクローズドキャプションコンポーネントである場合、ノーマルキャプションてあるか又はイージーリーダー（ｅａｓｙ  ｒｅａｄｅｒ）タイプであるかなどを示すことができる。
【０１０１】
＠ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性は、当該サービスコンポーネントが保護されたか、例えば暗号化されたかを示すことができる。＠ｃｏｍｐｏｎｅｎｔＩｄ属性は、当該サービスコンポーネントの識別子を示すことができる。この属性の値は、このサービスコンポーネントに該当するＭＰテーブルのａｓｓｅｔ＿ｉｄ（アセットＩＤ）と同じ値であってもよい。＠ｃｏｍｐｏｎｅｎｔＮａｍｅ属性は、当該サービスコンポーネントの名を示すことができる。
【０１０２】
図６は、本発明の一実施例に係るリンクレイヤ（Ｌｉｎｋ  Ｌａｙｅｒ）動作を示す図である。
【０１０３】
リンクレイヤは、フィジカルレイヤとネットワークレイヤとの間のレイヤであり得る。送信側では、ネットワークレイヤからフィジカルレイヤにデータを伝送し、受信側では、フィジカルレイヤからネットワークレイヤにデータを伝送することができる（ｔ６０１０）。リンクレイヤの目的は、フィジカルレイヤによる処理のために全入力パケットタイプを１つのフォーマットに圧縮（ａｂｓｔｒａｃｔｉｎｇ）すること、及びまだ定義されていない入力パケットタイプに対する柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）及び将来の拡張可能性を保障することにあり得る。また、リンクレイヤは、入力パケットのヘッダーの不要な情報を圧縮するオプションを提供することによって、入力データが効率的に伝送されるようにすることができる。リンクレイヤのオーバーヘッドリダクション、エンカプセレーションなどの動作は、リンクレイヤプロトコルと呼ばれ、当該プロトコルによって生成されたパケットは、リンクレイヤパケットと呼ぶことができる。リンクレイヤは、パケットエンカプセレーション（ｐａｃｋｅｔ  ｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッドリダクション（Ｏｖｅｒｈｅａｄ  Ｒｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（Ｓｉｇｎａｌｉｎｇ  Ｔｒａｎｓｍｉｓｓｉｏｎ）などの機能を有することができる。
【０１０４】
送信側基準で、リンクレイヤ（ＡＬＰ）は、入力パケットに対してオーバーヘッドリダクション過程を行った後、それらをリンクレイヤパケットにエンカプセレーションすることができる。また、実施例によって、リンクレイヤは、オーバーヘッドリダクション過程を行わないで、リンクレイヤパケットにエンカプセレーションしてもよい。リンクレイヤプロトコルの使用によって、フィジカルレイヤ上でデータの伝送に対するオーバーヘッドを大きく減少させることができ、本発明に係るリンクレイヤプロトコルは、ＩＰオーバーヘッドリダクション及び／又はＭＰＥＧ−２ＴＳオーバーヘッドリダクションを提供することができる。
【０１０５】
図示の、ＩＰパケットが入力パケットとして入力される場合において（ｔ６０１０）、リンクレイヤは、ＩＰヘッダー圧縮、アダプテーション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。まず、ＲｏＨＣモジュールでＩＰパケットヘッダー圧縮を行って不要なオーバーヘッドを減らし、アダプテーション過程によってコンテクスト情報を抽出し、これを帯域外で伝送することができる。ＩＰヘッダー圧縮及びアダプテーション過程を総称して、ＩＰヘッダー圧縮ということもできる。その後、エンカプセレーション過程を経てＩＰパケットをリンクレイヤパケットにエンカプセレーションすることができる。
【０１０６】
ＭＰＥＧ２ＴＳパケットが入力パケットとして入力される場合において、リンクレイヤは、ＴＳパケットに対するオーバーヘッドリダクション及び／又はエンカプセレーション過程を順に行うことができる。実施例によって、一部の過程は省略されてもよい。オーバーヘッドリダクションにおいて、リンクレイヤは、シンクバイトの除去、ヌルパケットの削除及び／又は共通（ｃｏｍｍｏｎ）ヘッダー除去（圧縮）を提供することができる。シンクバイト除去によってＴＳパケット当たりに１バイトのオーバーヘッドリダクションを提供することができる。受信側で再挿入可能な方式でヌルパケットの削除を行ってもよい。また、連続したヘッダー間の共通した情報を、受信側で復旧可能な方式で削除（圧縮）してもよい。各オーバーヘッドリダクション過程の一部は省略されてもよい。その後、エンカプセレーション過程を経てＴＳパケットをリンクレイヤパケッにエンカプセレーションすることができる。ＴＳパケットのエンカプセレーションに対するリンクレイヤパケット構造は、他のタイプのパケットとは異なってもよい。
【０１０７】
まず、ＩＰヘッダー圧縮（ＩＰ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。
【０１０８】
ＩＰパケットは、固定されたヘッダーフォーマットを有するが、通信環境で必要な一部の情報がブロードキャスト環境では不要な場合がある。リンクレイヤプロトコルは、ＩＰパケットのヘッダーを圧縮することによって、ブロードキャストオーバーヘッドを減らすメカニズムを提供することができる。
【０１０９】
ＩＰヘッダー圧縮は、ヘッダーコンプレッサ／デコンプレッサ及び／又はアダプテーションモジュールを含むことができる。ＩＰヘッダーコンプレッサ（ＲｏＨＣコンプレッサ）は、ＲｏＨＣ方式に基づいて各ＩＰパケットヘッダーのサイズを減少させることができる。その後、アダプテーションモジュールは、コンテクスト情報を抽出し、各パケットストリームからシグナリング情報を生成することができる。受信機は、該当のパケットストリームに関連したシグナリング情報をパースし、コンテクスト情報をそのパケットストリームに付加（ａｔｔａｃｈ）することができる。ＲｏＨＣデコンプレッサは、パケットヘッダーを復旧して元来のＩＰパケットを再構成することができる。以下、ＩＰヘッダー圧縮とは、ヘッダーコンプレッサによるＩＰヘッダー圧縮のみを意味してもよく、ＩＰヘッダー圧縮とアダプテーションモジュールによるアダプテーション過程とを合わせた概念を意味してもよい。デコンプレッシング（ｄｅｃｏｍｐｒｅｓｓｉｎｇ）に対しても同様である。
【０１１０】
以下、アダプテーション（Ａｄａｐｔａｔｉｏｎ）について説明する。
【０１１１】
単方向リンク上の伝送において、受信機がコンテクストの情報を有していないと、デコンプレッサは完全なコンテクストを受信するまでは、受信したパケットヘッダーを復旧することができない。これは、チャネル変更遅延及びターンオンディレー（ｔｕｒｎ−ｏｎ  ｄｅｌａｙ）を招きうる。そこで、アダプテーション機能を用いて、コンプレッサ／デコンプレッサ間のコンフィギュレーションパラメータとコンテクスト情報を帯域外で伝送することができる。アダプテーションファンクション（ｆｕｎｃｔｉｏｎ）は、コンテクスト情報及び／又はコンフィギュレーションパラメータを用いてリンクレイヤシグナリングを生成（ｃｏｎｓｔｒｕｃｔｉｏｎ）することができる。アダプテーションファンクションは、以前（ｐｒｅｖｉｏｕｓ）のコンフィギュレーションパラメータ及び／又はコンテクスト情報を用いて、それぞれのフィジカルフレームを介して周期的にリンクレイヤシグナリングを伝送することができる。
【０１１２】
圧縮されたＩＰパケットからコンテクスト情報を抽出するが、アダプテーションモードによって様々な方法を用いることができる。
【０１１３】
モード＃１は、圧縮されたパケットストリームに対していかなる動作も行わないモードであり、アダプテーションモジュールがバッファとして動作するモードであるといえる。
【０１１４】
モード＃２は、圧縮されたパケットストリームのうち、ＩＲパケットを検出してコンテクスト情報（スタティックチェーン）を抽出するモードであってもよい。抽出の後、ＩＲパケットはＩＲ−ＤＹＮパケットに変換され、ＩＲ−ＤＹＮパケットを元来のＩＲパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
【０１１５】
モード＃３（ｔ６０２０）は、圧縮されたパケットストリームのうち、ＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテクスト情報を抽出するモードであってもよい。ＩＲパケットからスタティックチェーン及びダイナミックチェーンを、ＩＲ−ＤＹＮパケットからダイナミックチェーンを抽出することができる。抽出の後、ＩＲ及びＩＲ−ＤＹＮパケットを一般圧縮パケットに変換することができる。変換されたパケットを、元来のＩＲ及びＩＲ−ＤＹＮパケットに代えてパケットストリーム内で同じ順序で伝送することができる。
【０１１６】
各モードで、コンテクスト情報を抽出して残ったパケットは、圧縮されたＩＰパケットのためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。コンテクスト情報は、リンクレイヤシグナリングであり、シグナリング情報のためのリンクレイヤパケット構造によってエンカプセレーションして伝送することができる。
【０１１７】
抽出されたコンテクスト情報は、ＲＤＴ（ＲｏＨＣ−Ｕ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｔａｂｌｅ）に含めてＲｏＨＣパケットフローとは別に伝送することができる。コンテクスト情報は、他のシグナリング情報と共に特定（ｓｐｅｃｉｆｉｃ）フィジカルデータ経路で伝送することができる。特定フィジカルデータ経路とは、実施例によって、一般ＰＬＰのうちの一つを意味することもでき、ＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）が伝達されるＰＬＰを意味することもでき、指定された（ｄｅｄｉｃａｔｅｄ）ＰＬＰであってもよく、Ｌ１シグナリングパス（ｐａｔｈ）を意味することもできる。ここで、ＲＤＴは、コンテクスト情報（スタティックチェーン及び／又はダイナミックチェーン）及び／又はヘッダーコンプレッションに関連した情報を含むシグナリング情報であってもよい。実施例によって、ＲＤＴは、コンテクスト情報が変わる度に伝送されてもよい。また、実施例によって、ＲＤＴは、毎フィジカルフレームで伝送されてもよい。毎フィジカルフレームでＲＤＴを伝送するために、以前（ｐｒｅｖｉｏｕｓ）のＲＤＴが再利用（ｒｅ−ｕｓｅ）され得る。
【０１１８】
受信機はパケットストリームを取得する前に、最初のＰＬＰを選択してＳＬＴ、ＲＤＴ、ＬＭＴなどのシグナリング情報をまず取得することができる。受信機は、このシグナリング情報が取得されると、これらを組み合わせてサービス−ＩＰ情報−コンテクスト情報−ＰＬＰ間のマッピングを取得することができる。すなわち、受信機は、どのようなサービスがどのＩＰストリームで伝送されるのか、どのようなＰＬＰでどのようなＩＰストリームが伝達されるのか、などを知ることができ、また、ＰＬＰの当該コンテクスト情報を取得することができる。受信機は、特定のパケットストリームを運搬するＰＬＰを選択してデコードすることができる。アダプテーションモジュールは、コンテクスト情報をパースし、これを圧縮されたパケットと組み合わせることができる。これによってパケットストリームを復旧することができ、これをＲｏＨＣデコンプレッサに伝達することができる。その後、デコンプレッションを始めることができる。このとき、受信機は、アダプテーションモードに応じて、ＩＲパケットをディテクトして、最初に受信されたＩＲパケットからデコンプレッションを開始したり（モード１）、ＩＲ−ＤＹＮパケットをディテクトして、最初に受信されたＩＲ−ＤＹＮパケットからデコンプレッションを開始したり（モード２）、どの一般の圧縮パケット（ｃｏｍｐｒｅｓｓｅｄ  ｐａｃｋｅｔ）からデコンプレッションを開始してもよい（モード３）。
【０１１９】
以下、パケットエンカプセレーションについて説明する。
【０１２０】
リンクレイヤプロトコルは、ＩＰパケット、ＴＳパケットなどの全てのタイプのインプットパケットをリンクレイヤパケットにエンカプセレーションすることができる。これによって、フィジカルレイヤは、ネットワークレイヤのプロトコルタイプとは独立して１つのパケットフォーマットだけを処理すればいい（ここでは、ネットワークレイヤパケットの一種としてＭＰＥＧ−２ＴＳパケットを考慮）。各ネットワークレイヤパケット又は入力パケットは、ゼネリックリンクレイヤパケットのペイロードに変形される。
【０１２１】
パケットエンカプセレーション過程では分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワークレイヤパケットが大きすぎてフィジカルレイヤで処理できない場合、ネットワークレイヤパケットを２つ以上のセグメントに分割することができる。リンクレイヤパケットヘッダーは、送信側で分割を実行し、受信側で再結合を実行するためのフィールドを含むことができる。各セグメントを、元来の位置と同じ順序でリンクレイヤパケットにエンカプセレーションすることができる。
【０１２２】
パケットエンカプセレーション過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）を活用することもできる。リンクレイヤパケットのペイロードが複数のネットワークレイヤパケットを含む程度にネットワークレイヤパケットが十分に小さい場合、連鎖を行ってもよい。リンクレイヤパケットヘッダーは、連鎖を実行するためのフィールドを含むことができる。連鎖の場合、各入力パケットを、元来の入力順序と同じ順序でリンクレイヤパケットのペイロードにエンカプセレーションすることができる。
【０１２３】
リンクレイヤパケットは、ヘッダー及びペイロードを含むことができ、ヘッダーは、ベースヘッダー、追加（ａｄｄｉｔｉｏｎａｌ）ヘッダー及び／又はオプショナルヘッダーを含むことができる。追加ヘッダーは、連鎖又は分割などの状況によってさらに追加することができるが、追加ヘッダーには状況に応じて、必要なフィールドを含めることができる。また、追加的な情報の伝達のためにオプショナルヘッダーをさらに追加することもできる。それぞれのヘッダー構造は既に定義されていてもよい。前述したように、入力パケットがＴＳパケットである場合には、他のパケットとは異なるリンクレイヤヘッダー構造を用いることができる。
【０１２４】
以下、リンクレイヤシグナリングについて説明する。
【０１２５】
リンクレイヤシグナリングは、ＩＰレイヤよりも下位レベルで動作することができる。受信側では、ＬＬＳ、ＳＬＴ、ＳＬＳなどのＩＰレベルシグナリングよりもリンクレイヤシグナリングを先に取得することができる。このため、リンクレイヤシグナリングをセッション設定（ｅｓｔａｂｌｉｓｈｍｅｎｔ）の前に取得することができる。
【０１２６】
リンクレイヤシグナリングには、インターナルリンクレイヤシグナリングとエクスターナルリンクレイヤシグナリングがあり得る。インターナルリンクレイヤシグナリングは、リンクレイヤで生成されたシグナリング情報を意味することができる。前述したＲＤＴ又は後述するＬＭＴなどがこれに当たる。エクスターナルリンクレイヤシグナリングは、外部のモジュール又は外部のプロトコル、上位レイヤから伝達されたシグナリング情報であってもよい。リンクレイヤは、リンクレイヤシグナリングをリンクレイヤパケットにエンカプセレーションして伝達することができる。リンクレイヤシグナリングのためのリンクレイヤパケット構造（ヘッダー構造）を定義することができ、この構造によって、リンクレイヤシグナリング情報をエンカプセレーションすることができる。
【０１２７】
図７は、本発明の一実施例に係るＬＭＴ（Ｌｉｎｋ  Ｍａｐｐｉｎｇ  Ｔａｂｌｅ）を示す図である。
【０１２８】
ＬＭＴは、ＰＬＰで運搬される上位レイヤセッションのリストを提供することができる。また、ＬＭＴは、上位レイヤセッションを伝達するリンクレイヤパケットをプロセシングするための追加的な情報を提供することができる。ここで、上位レイヤセッションは、マルチキャスト（ｍｕｌｔｉｃａｓｔ）と呼ぶこともできる。ＬＭＴから、特定のＰＬＰを介していかなるＩＰストリーム、いかなる伝送セッションが伝送されているかに関する情報を取得することができる。逆に、特定の伝送セッションがどのＰＬＰで伝達されるかに関する情報も取得することができる。
【０１２９】
ＬＭＴは、ＬＬＳを運搬するものと識別されたいかなるＰＬＰでも伝達可能である。ここで、ＬＬＳが伝達されるＰＬＰは、フィジカルレイヤのＬ１ディテールシグナリング情報のＬＬＳフラグによって識別され得る。ＬＬＳフラグは、それぞれのＰＬＰに対して、当該ＰＬＰでＬＬＳが伝達されるか否かを示すフラグフィールドであってもよい。ここで、Ｌ１ディテールシグナリング情報は、後述するＰＬＳ２データに該当してもよい。
【０１３０】
すなわち、ＬＭＴは、ＬＬＳと共に、同じＰＬＰで伝達され得る。それぞれのＬＭＴは、前述したように、ＰＬＰとＩＰアドレス／ポートとの間のマッピングを記述することができる。前述したように、ＬＬＳはＳＬＴを含むことができ、ＬＭＴが記述するこのＩＰアドレス／ポートは、当該ＬＭＴと同じＰＬＰで伝達されるＳＬＴが記述する、あらゆる（ａｎｙ）サービスと関連するあらゆる（ａｎｙ）ＩＰアドレス／ポートであってもよい。
【０１３１】
実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報を用いて、ＳＬＴ、ＳＬＳが示す特定伝送セッションがどのＰＬＰで伝送されているかに関する情報を確認することができる。
【０１３２】
他の実施例によって、前述したＳＬＴ、ＳＬＳ等におけるＰＬＰ識別子情報は省略され、ＳＬＴ、ＳＬＳが示す特定伝送セッションに対するＰＬＰ情報は、ＬＭＴ内の情報を参照することによって確認することもできる。この場合、受信機は、ＬＭＴと他のＩＰレベルシグナリング情報とを組み合わせて、所望のＰＬＰを識別することができる。この実施例においても、ＳＬＴ、ＳＬＳ等におけるＰＬＰ情報は省略されず、ＳＬＴ、ＳＬＳ等に残っていてもよい。
【０１３３】
同図の実施例に係るＬＭＴは、ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールド、ＰＬＰ＿ＩＤフィールド、ｎｕｍ＿ｓｅｓｓｉｏｎフィールド及び／又はそれぞれのセッションに関する情報を含むことができる。同図の実施例のＬＭＴは、１つのＰＬＰに対して、そのＰＬＰで伝送されるＩＰストリームを記述しているが、実施例によって、ＬＭＴにＰＬＰループを追加し、複数個のＰＬＰに関する情報を記述してもよい。この場合、ＬＭＴは、前述したように、共に伝達されるＳＬＴが記述するあらゆるサービスと関連するあらゆるＩＰアドレス／ポートに対するＰＬＰを、ＰＬＰループに記述することができる。
【０１３４】
ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドは、当該テーブルによって伝達されるシグナリング情報のタイプを示すことができる。ＬＭＴに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は、０ｘ０１に設定することができる。ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドは省略されてもよい。ＰＬＰ＿ＩＤフィールドは、記述しようとする対象ＰＬＰを識別することができる。ＰＬＰループが用いられる場合、それぞれのＰＬＰ＿ＩＤフィールドは、それぞれの対象ＰＬＰを識別することができる。ＰＬＰ＿ＩＤフィールドからはＰＬＰループ内に含まれてもよい。後述するＰＬＰ＿ＩＤフィールドは、ＰＬＰループにおける一つのＰＬＰに対する識別子であり、以下で説明するフィールドは、その当該ＰＬＰに対するフィールドであってもよい。
【０１３５】
ｎｕｍ＿ｓｅｓｓｉｏｎフィールドは、当該ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションの個数を示すことができる。ｎｕｍ＿ｓｅｓｓｉｏｎフィールドが示す個数によって、各セッションに関する情報が含まれてもよい。この情報は、ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド、ｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールド、ＳＩＤ＿ｆｌａｇフィールド、ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールド、ＳＩＤフィールド及び／又はｃｏｎｔｅｘｔ＿ｉｄフィールドを含むことができる。
【０１３６】
ｓｒｃ＿ＩＰ＿ａｄｄフィールド、ｄｓｔ＿ＩＰ＿ａｄｄフィールド、ｓｒｃ＿ＵＤＰ＿ｐｏｒｔフィールド及びｄｓｔ＿ＵＤＰ＿ｐｏｒｔフィールドは、当該ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰで伝達される上位レイヤセッションのうち、当該伝送セッションに対するソースＩＰアドレス、デスティネーションＩＰアドレス、ソースＵＤＰポート、デスティネーションＵＤＰポートを示すことができる。
【０１３７】
ＳＩＤ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示すことができる。上位レイヤセッションを伝達するリンクレイヤパケットは、そのオプショナルヘッダーにＳＩＤフィールドを有することができ、そのＳＩＤフィールドの値は後述するＬＭＴ内のＳＩＤフィールドと同一であってもよい。
【０１３８】
ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールドは、当該伝送セッションを伝達するリンクレイヤパケットのデータにヘッダーコンプレッションが適用されたか否かを示すことができる。また、本フィールドの値によって、後述するｃｏｎｔｅｘｔ＿ｉｄフィールドの存否が決定されてもよい。ヘッダーコンプレッションが適用された場合（ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇ＝１）、ＲＤＴが存在し得、そのＲＤＴのＰＬＰ  ＩＤフィールドは、本ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇフィールドに関連する当該ＰＬＰ＿ＩＤフィールドと同じ値を有することができる。
【０１３９】
ＳＩＤフィールドは、当該伝送セッションを伝達するリンクレイヤパケットに対するＳＩＤ（ｓｕｂ  ｓｔｒｅａｍ  ＩＤ）を示すことができる。このリンクレイヤパケットは、そのオプショナルヘッダーに本ＳＩＤフィールドと同一の値を有するＳＩＤを含んでいてもよい。これを通じて、受信機は、リンクレイヤパケットを全部パーシングする必要がなく、ＬＭＴの情報及びリンクレイヤパケットヘッダーのＳＩＤ情報を用いて、リンクレイヤパケットをフィルタリングすることができる。
【０１４０】
ｃｏｎｔｅｘｔ＿ｉｄフィールドは、ＲＤＴ内のＣＩＤ（ｃｏｎｔｅｘｔ  ｉｄ）に対するリファレンスを提供することができる。ＲＤＴのＣＩＤ情報は、該当する圧縮ＩＰパケットストリームに対するコンテクストＩＤを示すことができる。ＲＤＴは、該当する圧縮ＩＰパケットストリームに対するコンテクスト情報を提供することができる。本フィールドによってＲＤＴとＬＭＴとが関連付けられてもよい。
【０１４１】
前述した、本発明のシグナリング情報／テーブルの実施例において、それぞれのフィールド、エレメント、属性を省略したり他のフィールドに置き換えてもよく、実施例によって、更なるフィールド、エレメント、属性を追加してもよい。
【０１４２】
本発明の一実施例で、一つのサービスのサービスコンポーネントを複数個のＲＯＵＴＥセッションで伝達することができる。この場合、ＳＬＴのブートストラップ情報を用いてＳＬＳを取得することができる。このＳＬＳのＵＳＢＤを用いてＳ−ＴＳＩＤとＭＰＤをリファレンシングすることができる。Ｓ−ＴＳＩＤは、ＳＬＳを伝達しているＲＯＵＴＥセッションだけでなく、サービスコンポーネントを伝達している他のＲＯＵＴＥセッションに対する伝送セッションデスクリプション情報も記述することができる。これによって、複数個のＲＯＵＴＥセッションで伝達されるサービスコンポーネントを全て収集することができる。このような事項は、一つのサービスのサービスコンポーネントが複数個のＭＭＴＰセッションで伝達される場合にも同様に適用することができる。参考として、１つのサービスコンポーネントが複数個のサービスによって同時に用いられてもよい。
【０１４３】
本発明の他の実施例で、ＥＳＧサービスに対するブートストラピングは放送網又はブロードバンドで行われてもよい。ブロードバンドを介してＥＳＧを取得し、ＳＬＴのＵＲＬ情報を活用することができる。このＵＲＬにＥＳＧ情報などを要求することができる。
【０１４４】
本発明の他の実施例で、一つのサービスのいずれか一つのサービスコンポーネントは放送網で、いずれか他のサービスコンポーネントはブロードバンドで伝達することができる（ハイブリッド）。Ｓ−ＴＳＩＤは、放送網で伝達されるコンポーネントについて記述して、ＲＯＵＴＥクライアントが所望のサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、ベースパターン情報を有しており、どのセグメントが（どのコンポーネントが）どの経路で伝達されるかを記述することができる。したがって、受信機は、これを用いて、ブロードバンドサーバーに要求すべきセグメント、及び放送ストリームから見つけるべきセグメントを識別することができる。
【０１４５】
本発明の他の実施例で、サービスに対するスケーラブル（ｓｃａｌａｂｌｅ）コーディングを行うこともできる。ＵＳＢＤは、当該サービスをレンダリングするために必要な全てのキャパビリティ情報を有することができる。例えば、一つのサービスがＨＤ又はＵＨＤで提供される場合、ＵＳＢＤのキャパビリティ情報は、“ＨＤ又はＵＨＤ”値を有することができる。受信機は、ＭＰＤから、ＵＨＤ又はＨＤサービスをレンダリングするためにはどのコンポーネントを再生しなければならないかが分かる。
【０１４６】
本発明の他の実施例で、ＳＬＳを伝達するＬＣＴチャネルで伝達されるＬＣＴパケットのＴＯＩフィールドから、当該ＬＣＴパケットがどのＳＬＳフラグメントを伝達しているか（ＵＳＢＤ、Ｓ−ＴＳＩＤ、ＭＰＤなど）を識別することができる。
【０１４７】
本発明の他の実施例で、アプリベースのエンハンスメント／アプリベースのサービスに用いられるアプリコンポーネントを、ＮＲＴコンポーネントとして放送網で伝達されたり、又はブロードバンドで伝達してもよい。また、アプリベースのエンハンスメントに対するアプリシグナリングは、ＳＬＳと共に伝達されるＡＳＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｔａｂｌｅ）によって行われてもよい。また、アプリが行う動作に対するシグナリングであるイベントは、ＳＬＳと共にＥＭＴ（Ｅｖｅｎｔ  Ｍｅｓｓａｇｅ  Ｔａｂｌｅ）の形態で伝達されたり、ＭＰＤ内にシグナルされたり、ＤＡＳＨリプレゼンテーション内にｂｏｘ形態でインバンド（ｉｎ−ｂａｎｄ）シグナルされてもよい。ＡＳＴ、ＥＭＴなどはブロードバンドを介して伝達されてもよい。収集されたアプリコンポーネントとこのようなシグナリング情報を用いてアプリベースのエンハンスメントなどを提供することができる。
【０１４８】
本発明の他の実施例で、緊急警報のためにＣＡＰメッセージを前述のＬＳテーブルに含めて提供することができる。緊急警報のためのリーチメディア（Ｒｉｃｈ  Ｍｅｄｉａ）コンテンツも提供することができる。リーチメディアは、ＣＡＰメッセージによってシグナルすることができ、リーチメディアが存在する場合、これは、ＳＬＴによってシグナルされるＥＡＳサービスとして提供することができる。
【０１４９】
本発明の他の実施例で、ＭＭＴプロトコルによってリニアサービスコンポーネントを放送網を介して伝達することができる。この場合、当該サービスに対するＮＲＴデータ（例えば、アプリコンポーネント）をＲＯＵＴＥプロトコルによって放送網で伝達することができる。また、当該サービスに対するデータをブロードバンドで伝達することができる。受信機は、ＳＬＴのブートストラップ情報を用いてＳＬＳを伝達するＭＭＴＰセッションに接近することができる。ＭＭＴによるＳＬＳのＵＳＢＤは、ＭＰテーブルをリファレンシングして、受信機がＭＭＴプロトコルによって伝達されるＭＰＵにフォーマットされたリニアサービスコンポーネントを取得できるようにする。また、ＵＳＢＤは、Ｓ−ＴＳＩＤをさらにリファレンシングして、受信機がＲＯＵＴＥプロトコルによって伝達されるＮＲＴデータを取得するようにしてもよい。また、ＵＳＢＤは、ＭＰＤをさらにリファレンシングして、ブロードバンドを介して伝達されるデータに対する再生デスクリプションを提供することができる。
【０１５０】
本発明の他の実施例で、受信機はそのコンパニオンデバイスに、ストリーミングコンポーネント及び／又はファイルコンテンツアイテム（ファイルなど）を取得できるロケーションＵＲＬ情報を、ウェブソケットなどの方法で伝達することができる。コンパニオンデバイスのアプリケーションはこのＵＲＬにＨＴＴＰ  ＧＥＴなどを用いて要求して該当のコンポーネント、データなどを取得することができる。その他にも、受信機はシステムタイム情報、緊急警報情報などの情報をコンパニオンデバイス側に伝達することができる。
【０１５１】
図８は、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【０１５２】
本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Ｉｎｐｕｔ  Ｆｏｒｍａｔ  ｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック（ＯＦＤＭ  ｇｅｎｅｒａｔｉｏｎ  ｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【０１５３】
本発明の一実施例に係る入力データは、ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳが主な入力フォーマットであり得、他のストリームタイプは一般ストリームとして扱われる。
【０１５４】
インプットフォーマットブロック１０００は、それぞれの入力ストリームを独立したコーディング及び変調が適用される１つ又は多数のデータパイプに逆多重化することができる。データパイプは、ロバスト性（ｒｏｂｕｓｔｎｅｓｓ）の制御のための基本単位であり、これは、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に影響を及ぼす。１つ又は多数のサービス又はサービスコンポーネントが一つのデータパイプによって伝達されてもよい。データパイプは、１つ又は多数のサービス又はサービスコンポーネントを伝達できるサービスデータ又は関連メタデータを伝達する物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）での論理チャネルである。
【０１５５】
ＱｏＳが、本発明の一実施例に係る次世代放送サービスに対する放送信号送信装置によって提供されるサービスの特性に依存するため、それぞれのサービスに該当するデータは、互いに異なる方式を用いて処理されなければならない。
【０１５６】
ＢＩＣＭブロック１０１０は、ＭＩＭＯが適用されないプロファイル（又はシステム）に適用される処理ブロック、及び／又はＭＩＭＯが適用されるプロファイル（又はシステム）の処理ブロックを含むことができ、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１５７】
ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロックは、データＦＥＣエンコーダ、ビットインタリーバ、コンステレーションマッパー（ｍａｐｐｅｒ）、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック、及びタイムインタリーバを含むことができる。ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロックは、セルワードデマルチプレクサ及びＭＩＭＯエンコーディングブロックをさらに含むという点で、ＭＩＭＯが適用されないＢＩＣＭの処理ブロックと区別される。
【０１５８】
データＦＥＣエンコーダは、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成するために、入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。ビットインタリーバは、データＦＥＣエンコーダの出力をインタリーブして、ＬＤＰＣコード及び変調方式の組み合わせにより最適化された性能を達成することができる。コンステレーションマッパーは、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）又は不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いて、ビットインタリーバ又はセルワードデマルチプレクサからのセルワードを変調して、電力が正規化されたコンステレーションポイントを提供することができる。ＮＵＱが任意の形状を有する反面、ＱＡＭ−１６及びＮＵＱは正方形の形状を有することが観察される。ＮＵＱ及びＮＵＣはいずれも各コードレート（ｃｏｄｅ  ｒａｔｅ）に対して特別に定義され、ＰＬＳ２データのパラメータＤＰ＿ＭＯＤによってシグナリングされる。タイムインタリーバは、データパイプレベルで動作することができる。タイムインタリービングのパラメータは、それぞれのデータパイプに対して異ならせて設定されてもよい。
【０１５９】
本発明のタイムインタリーバは、ＢＩＣＭチェーン（ＢＩＣＭ  ｃｈａｉｎ）ブロックとフレームビルダー（Ｆｒａｍｅ  Ｂｕｉｌｄｅｒ）との間に位置し得る。この場合、本発明のタイムインタリーバは、ＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）モードに応じて、コンボリューションインタリーバ（Ｃｏｎｖｏｌｕｔｉｏｎ  Ｉｎｔｅｒｌｅａｖｅｒ、ＣＩ）とブロックインタリーバ（Ｂｌｏｃｋ  Ｉｎｔｅｒｌｅａｖｅｒ、ＢＩ）を選択的に使用してもよく、両方とも使用してもよい。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使用されるフィジカルパス（ｐｈｙｓｉｃａｌ  ｐａｔｈ）であって、呼称は設計者の意図によって変更可能である。本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰの個数に応じて、シングルＰＬＰ（ｓｉｎｇｌｅ  ＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅ  ＰＬＰ）モードを含むことができる。本発明では、ＰＬＰモードに応じて互いに異なるタイムインタリービング方法を適用するタイムインタリービングを、ハイブリッドタイムインタリービング（Ｈｙｂｒｉｄ  Ｔｉｍｅ  Ｉｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。
【０１６０】
ハイブリッドタイムインタリーバは、ブロックインタリーバ（ＢＩ）及びコンボリューションインタリーバ（ＣＩ）を含むことができる。ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインタリーバは適用されず（ブロックインタリーバオフ（ｏｆｆ））、コンボリューションインタリーバのみが適用される。ＰＬＰ＿ＮＵＭ＞１である場合、ブロックインタリーバ及びコンボリューションインタリーバが両方とも適用（ブロックインタリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１である場合に適用されるコンボリューションインタリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１である場合に適用されるコンボリューションインタリーバの構造及び動作と異なってもよい。ハイブリッドタイムデインターリーバは、上述したハイブリッドタイムインタリーバの逆動作に相応する動作を行うことができる。
【０１６１】
セルワードデマルチプレクサは、ＭＩＭＯ処理のために、単一のセルワードストリームを二重セルワードストリームに分離するのに用いられる。ＭＩＭＯエンコーディングブロックは、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサの出力を処理することができる。本発明のＭＩＭＯエンコーディング方式は、受信機側での比較的小さい複雑度の増加で容量増加を提供するためのＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）として定義できる。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ１，ｉ及びｅ２，ｉ）は、ＭＩＭＯエンコーダの入力として供給されると、ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ１，ｉ及びｇ２，ｉ）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって伝送される。
【０１６２】
フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングし、周波数領域ダイバーシチのために周波数インタリービングを行うことができる。
【０１６３】
本発明の一実施例に係るフレームは、プリアンブル、１つ以上のＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）、ノーマルデータシンボルに分離される。プリアンブルは、信号の効率的な送信及び受信のための基本伝送パラメータの集合を提供する特別なシンボルである。プリアンブルは、フレームの基本伝送パラメータ及び伝送タイプをシグナリングすることができる。特に、プリアンブルは、ＥＡＳ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｓｅｒｖｉｃｅ）が現フレームに提供されるか否かを示すことができる。ＦＳＳの主な目的はＰＬＳデータを伝達することである。高速同期化及びチャネル推定、ＰＬＳデータの高速デコーディングのために、ＦＳＳは、ノーマルデータシンボルよりも高密度のパイロットパターンを有する。
【０１６４】
フレームビルディングブロックは、データパイプと該当するＰＬＳデータとの間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（ｃｏ−ｔｉｍｅ）を保障するためのディレイコンペンセーション（ｄｅｌａｙ  ｃｏｍｐｅｎｓａｔｉｏｎ、遅延補償）ブロック、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどをフレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマッピングするためのセルマッパー（ｃｅｌｌ  ｍａｐｐｅｒ）、及び周波数インタリーバ（ｆｒｅｑｕｅｎｃｙ  ｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。
【０１６５】
周波数インタリーバは、セルマッパーから受信されたデータセルをランダムにインタリーブして周波数ダイバーシチを提供することができる。また、周波数インタリーバは、単一のフレームで最大のインタリービング利得を得るために、異なるインタリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）に対応するデータ又は一つのＯＦＤＭシンボルに対応するデータに対して動作することができる。
【０１６６】
ＯＦＤＭ生成ブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは、順次にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。
【０１６７】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）シグナリング情報を生成することができる。本発明の一実施例に係るシグナリング情報はＰＬＳデータを含むことができる。ＰＬＳは、受信機で物理層（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）データパイプに接続できる手段を提供する。ＰＬＳデータはＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１６８】
ＰＬＳ１データは、ＰＬＳ２データをデコードするのに必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームにおいてＦＳＳで伝達されるＰＬＳデータの１番目の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするのに要求されるパラメータを含む基本送信パラメータを提供する。ＰＬＳ２データは、データパイプ及びシステムに関するさらに詳細なＰＬＳデータを伝達し、ＦＳＳで伝送されるＰＬＳデータの２番目の集合である。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データ（ＰＬＳ２−ＳＴＡＴデータ）、及びＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２スタティック（ｓｔａｔｉｃ、静的）データは、フレームグループのデュレーションの間にスタティック（ｓｔａｔｉｃ、静的）なＰＬＳ２データであり、ＰＬＳ２ダイナミック（ｄｙｎａｍｉｃ、動的）データは、フレーム毎にダイナミック（ｄｙｎａｍｉｃ、動的）に変化するＰＬＳ２データである。
【０１６９】
ＰＬＳ２データはＦＩＣ＿ＦＬＡＧ情報を含むことができる。ＦＩＣ（Ｆａｓｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｈａｎｎｅｌ）は、速いサービス取得及びチャネルスキャン（ｆａｓｔ  ｓｅｒｖｉｃｅ  ａｃｑｕｉｓｉｔｉｏｎ  ａｎｄ  ｃｈａｎｎｅｌ  ｓｃａｎｎｉｎｇ）を可能にするクロスレイヤ（ｃｒｏｓｓ−ｌａｙｅｒ）情報を伝送するための専用チャネル（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ）である。ＦＩＣ＿ＦＬＡＧ情報は、１ビットのフィールドであって、ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ、高速情報チャネル）が現フレームグループで用いられるか否かを示す。当該フィールドの値が１に設定されると、ＦＩＣは現フレームで提供される。当該フィールドの値が０に設定されると、ＦＩＣは現フレームで伝達されない。ＢＩＣＭブロック１０１０は、ＰＬＳデータの保護のためのＢＩＣＭブロックを含むことができる。ＰＬＳデータの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダ、ビットインタリーバ、及びコンステレーションマッパーを含むことができる。
【０１７０】
ＰＬＳ  ＦＥＣエンコーダは、ＰＬＳ１データ及びＰＬＳ２データをスクランブルするためのスクランブラ、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いてスクランブルされたＰＬＳ１，２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入するためのＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣコードを用いてエンコーディングを行うためのＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）ブロックを含むことができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットがＬＤＰＣエンコーディングの前にパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）され得る。ビットインタリーバは、それぞれのショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインタリーブし、コンステレーションマッパーは、ビットインタリーブされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
【０１７１】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図８を参照して説明した次世代放送サービスに対する放送信号送信装置の逆過程を行うことができる。
【０１７２】
本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、放送信号送信装置によって行われる手順の逆過程に該当する復調を行う同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ＆  ｄｅｍｏｄｕｌａｔｉｏｎ  ｍｏｄｕｌｅ）、入力信号フレームをパーシングし、ユーザによって選択されたサービスが伝送されるデータを抽出するフレームパーシングモジュール（ｆｒａｍｅ  ｐａｒｓｉｎｇ  ｍｏｄｕｌｅ）、入力信号をビット領域データに変換した後、必要によってビット領域データをデインタリーブし、伝送効率のために適用されたマッピングに対するデマッピングを行い、デコーディングを介して伝送チャネルで発生した誤りを訂正するデマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ  ＆  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）、放送信号送信装置によって適用される様々な圧縮／信号処理手順の逆過程を行う出力プロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）、及び同期及び復調モジュールによって復調された信号からＰＬＳ情報を取得、処理するシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇ  ｄｅｃｏｄｉｎｇ  ｍｏｄｕｌｅ）を含むことができる。フレームパーシングモジュール、デマッピング及びデコーディングモジュール、及び出力プロセッサは、シグナリングデコーディングモジュールから出力されたＰＬＳデータを用いてその機能を実行することができる。
【０１７３】
以下、タイムインタリーバを説明する。本発明の一実施例に係るタイムインタリービンググループは、一つのフレームに直接マッピングされるか、またはＰＩ個のフレームにわたって拡散される。また、それぞれのタイムインタリービンググループは、一つ以上（ＮＴＩ個）のタイムインタリービングブロックに分離される。ここで、それぞれのタイムインタリービングブロックは、タイムインタリーバメモリの一つの使用に該当する。タイムインタリービンググループ内のタイムインタリービングブロックは、互いに異なる個数のＸＦＥＣＢＬＯＣＫを含むことができる。一般に、タイムインタリーバは、フレーム生成過程の前にデータパイプデータに対するバッファとしても機能することができる。
【０１７４】
本発明の一実施例に係るタイムインタリーバは、ツイストされた行−列ブロックインタリーバである。本発明の一実施例に係るツイストされた行−列ブロックインタリーバは、１番目のＸＦＥＣＢＬＯＣＫをタイムインタリービングメモリの１番目の列に列方向に書き込み、２番目のＸＦＥＣＢＬＯＣＫは、次の列に書き込み、同じ方式でタイムインタリービングブロック内の残りのＸＦＥＣＢＬＯＣＫを書き込むことができる。そして、インタリービングアレイにおいて、セルは、１番目の行から（最も左側の列から始まって行に沿って右側に）最後の行まで対角線方向に読み取られ得る。この場合、タイムインタリービングブロック内のＸＦＥＣＢＬＯＣＫの個数に関係なく受信機側で単一のメモリデインタリービングを達成するために、ツイストされた行−列ブロックインタリーバ用インタリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインタリービングメモリに挿入することができる。この場合、受信機側で単一のメモリデインタリービングを達成するために、仮想ＸＦＥＣＢＬＯＣＫは、他のＸＦＥＣＢＬＯＣＫの最も前に挿入されなければならない。
【０１７５】
図９は、本発明の一実施例に係るタイムインタリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す。
【０１７６】
図中の左側に示されたブロックはＴＩメモリアドレスアレイ（ｍｅｍｏｒｙ  ａｄｄｒｅｓｓ  ａｒｒａｙ）を示し、図中の右側に示されたブロックは、連続した２つのＴＩグループに対して、それぞれ仮想（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最も前にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）動作を示す。
【０１７７】
本発明の一実施例に係る周波数インタリーバは、シンボルペアに対応するデータに適用するためのインタリービングアドレスを生成するためのインタリービングアドレス生成器を含むことができる。
【０１７８】
図１０は、本発明の一実施例に係る周波数インタリーバに含まれた各ＦＦＴモードによるメインＰＲＢＳ生成器とサブＰＲＢＳ生成器で構成されたインタリービングアドレス生成器のブロックダイヤグラムを示す図である。
【０１７９】
（ａ）は、８Ｋ  ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示し、（ｂ）は、１６Ｋ  ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示し、（ｃ）は、３２Ｋ  ＦＦＴモードに対するインタリービングアドレス生成器のブロックダイヤグラムを示す。
【０１８０】
ＯＦＤＭシンボルペアに対するインタリービング過程は、一つのインタリービングシーケンスを用い、次のように説明される。まず、一つのＯＦＤＭシンボルＯｍ，ｌでインタリーブされる利用可能なデータセル（セルマッパーからの出力セル）は、ｌ＝０，…，Ｎｓｙｍ−１に対してＯｍ，ｌ＝［ｘｍ，ｌ，０，…，ｘｍ，ｌ，ｐ，…，ｘｍ，ｌ，Ｎｄａｔａ−１］として定義される。このとき、ｘｍ，ｌ，ｐは、ｍ番目のフレームでｌ番目のＯＦＤＭシンボルのｐ番目のセルであり、Ｎｄａｔａは、データセルの個数である。フレームシグナリングシンボルに対してＮｄａｔａ＝ＣＦＳＳであり、ノーマルデータに対してＮｄａｔａ＝Ｃｄａｔａであり、フレームエッジシンボルに対してＮｄａｔａ＝ＣＦＥＳである。また、インタリーブされたデータセルは、ｌ＝０，…，Ｎｓｙｍ−１に対してＰｍ，ｌ＝［ｖｍ，ｌ，０，…，ｖｍ，ｌ，Ｎｄａｔａ−１］として定義される。
【０１８１】
ＯＦＤＭシンボルペアに対して、インタリーブされたＯＦＤＭシンボルペアは、各ペアの１番目のＯＦＤＭシンボルに対してｖｍ，ｌ，Ｈｉ（ｐ）＝ｘｍ，ｌ，ｐ，ｐ＝０，…，Ｎｄａｔａ−１として与えられ、各ペアの２番目のＯＦＤＭシンボルに対してｖｍ，ｌ，ｐ＝ｘｍ，ｌ，Ｈｉ（ｐ），ｐ＝０，…，Ｎｄａｔａ−１として与えられる。このとき、Ｈｌ（ｐ）は、ＰＲＢＳ生成器及びサブＰＲＢＳ生成器の巡回シフト値（シンボルオフセット）に基づいて生成されたインタリービングアドレスである。
【０１８２】
図１１は、本発明の一実施例に係るハイブリッド放送受信装置を示す図である。
【０１８３】
ハイブリッド放送システムは、地上波放送網及びインターネット網を連動して放送信号を送信することができる。ハイブリッド放送受信装置は、地上波放送網（ブロードキャスト）及びインターネット網（ブロードバンド）を介して放送信号を受信することができる。ハイブリッド放送受信装置は、フィジカルレイヤモジュール、フィジカルレイヤＩ／Ｆモジュール、サービス／コンテンツ取得コントローラ、インターネットアクセス制御モジュール、シグナリングデコーダ、サービスシグナリングマネジャー、サービスガイドマネジャー、アプリケーションシグナリングマネジャー、警報信号マネジャー、警報信号パーサー、ターゲッティング信号パーサー、ストリーミングメディアエンジン、非リアルタイムファイルプロセッサ、コンポーネントシンクロナイザ、ターゲッティングプロセッサ、アプリケーションプロセッサ、Ａ／Ｖプロセッサ、デバイスマネジャー、データシェアリング及びコミュニケーションユニット、再分配モジュール、コンパニオンデバイス及び／又は外部モジュールを含むことができる。
【０１８４】
フィジカルレイヤモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍｏｄｕｌｅ（ｓ））は、地上波放送チャネルを介して放送関連信号を受信及び処理し、これを適切な形態に変換してフィジカルレイヤＩ／Ｆモジュールに伝達することができる。
【０１８５】
フィジカルレイヤＩ／Ｆモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｉ／Ｆ  Ｍｏｄｕｌｅ（ｓ））は、フィジカルレイヤモジュールから取得した情報からＩＰデータグラムを取得することができる。また、フィジカルレイヤＩ／Ｆモジュールは、取得されたＩＰデータグラムなどを特定のフレーム（例えば、ＲＳ  Ｆｒａｍｅ、ＧＳＥなど）に変換することができる。
【０１８６】
サービス／コンテンツ取得コントローラ（Ｓｅｒｖｉｃｅ／Ｃｏｎｔｅｎｔ  Ａｃｑｕｉｓｉｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）は、ブロードキャスト（ｂｒｏａｄｃａｓｔ）及び／又はブロードバンド（ｂｒｏａｄｂａｎｄ）チャネルを介したサービス、コンテンツ及びこれに関連するシグナリングデータの取得のための制御動作を行うことができる。
【０１８７】
インターネットアクセス制御モジュール（Ｉｎｔｅｒｎｅｔ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍｏｄｕｌｅ（ｓ））は、ブロードバンドチャネルを介してサービス、コンテンツなどを取得するための受信機の動作を制御することができる。
【０１８８】
シグナリングデコーダ（Ｓｉｇｎａｌｉｎｇ  Ｄｅｃｏｄｅｒ）は、ブロードキャストチャネルなどを介して取得したシグナリング情報をデコードすることができる。
【０１８９】
サービスシグナリングマネジャー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからサービススキャン及びサービス／コンテンツなどに関連するシグナリング情報を抽出、パーシング及び管理することができる。
【０１９０】
サービスガイドマネジャー（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからアナウンス（ａｎｎｏｕｎｃｅｍｅｎｔ）情報を抽出し、ＳＧ（Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）データベース（ｄａｔａｂａｓｅ）を管理し、サービスガイドを提供することができる。
【０１９１】
アプリケーションシグナリングマネジャー（Ａｐｐ  Ｓｉｇｎａｌｉｎｇ  Ｍａｎａｇｅｒ）は、ＩＰデータグラムなどからアプリケーション取得などに関連するシグナリング情報を抽出、パーシング及び管理することができる。
【０１９２】
警報信号パーサー（Ａｌｅｒｔ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどから警報（ａｌｅｒｔｉｎｇ）に関連するシグナリング情報を抽出、パーシング及び管理することができる。
【０１９３】
ターゲッティング信号パーサー（Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）は、ＩＰデータグラムなどからサービス／コンテンツの個人化あるいはターゲッティングに関連するシグナリング情報を抽出、パーシング及び管理することができる。また、ターゲッティング信号パーサーは、パーシングされたシグナリング情報をターゲッティングプロセッサに伝達することができる。
【０１９４】
ストリーミングメディアエンジン（Ｓｔｒｅａｍｉｎｇ  Ｍｅｄｉａ  Ｅｎｇｉｎｅ）は、ＩＰデータグラムなどからＡ／Ｖストリーミングのためのオーディオ／ビデオデータを抽出及びデコードすることができる。
【０１９５】
非リアルタイムファイルプロセッサ（Ｎｏｎ−ｒｅａｌ  ｔｉｍｅ  Ｆｉｌｅ  Ｐｒｏｃｅｓｓｏｒ）は、ＩＰデータグラムなどからＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態のデータを抽出、デコーディング、及び管理することができる。
【０１９６】
コンポーネントシンクロナイザ（Ｃｏｍｐｏｎｅｎｔ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）は、ストリーミングオーディオ／ビデオデータ及びＮＲＴデータなどのコンテンツ及びサービスを同期化することができる。
【０１９７】
ターゲッティングプロセッサ（Ｔａｒｇｅｔｉｎｇ  Ｐｒｏｃｅｓｓｏｒ）は、ターゲッティング信号パーサーから受信したターゲッティングシグナリングデータに基づいてサービス／コンテンツの個人化関連演算を処理することができる。
【０１９８】
アプリケーションプロセッサ（Ａｐｐ  Ｐｒｏｃｅｓｓｏｒ）は、アプリケーション関連情報、ダウンロードされたアプリケーションの状態及びディスプレイパラメータを処理することができる。
【０１９９】
Ａ／Ｖプロセッサ（Ａ／Ｖ  Ｐｒｏｃｅｓｓｏｒ）は、デコードされたオーディオ及びビデオデータ、アプリケーションデータなどに基づいてオーディオ／ビデオレンダリング関連動作を行うことができる。
【０２００】
デバイスマネジャー（Ｄｅｖｉｃｅ  Ｍａｎａｇｅｒ）は、外部装置との接続及びデータ交換動作を行うことができる。また、デバイスマネジャーは、連動可能な外部装置の追加／削除／更新など、外部装置に対する管理動作を行うことができる。
【０２０１】
データシェアリング及びコミュニケーションユニット（Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｃｏｍｍ．）は、ハイブリッド放送受信機と外部装置との間のデータ伝送及び交換に関連する情報を処理することができる。ここで、伝送及び交換可能なデータはシグナリング、Ａ／Ｖデータなどであり得る。
【０２０２】
再分配モジュール（Ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ  Ｍｏｄｕｌｅ（ｓ））は、放送受信機が地上波放送信号を直接受信できない場合、次世代放送サービス及びコンテンツに対する関連情報を取得することができる。また、再分配モジュールは、放送受信機が地上波放送信号を直接受信できない場合、次世代放送システムによる放送サービス及びコンテンツ取得をサポートすることができる。
【０２０３】
コンパニオンデバイス（Ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ（ｓ））は、本発明の放送受信機に接続されて、オーディオ、ビデオ、またはシグナリングを含むデータを共有することができる。コンパニオンデバイスは、放送受信機と接続された外部装置を指すことができる。
【０２０４】
外部モジュール（Ｅｘｔｅｒｎａｌ  Ｍｏｄｕｌｅ（Ｍａｎａｇｅｍｅｎｔ））は、放送サービス／コンテンツの提供のためのモジュールを指すことができ、例えば、次世代放送サービス／コンテンツサーバーであってもよい。外部モジュールは、放送受信機と接続された外部装置を指すことができる。
【０２０５】
図１２は、本発明の一実施例に係るＤＡＳＨベースの適応型（Ａｄａｐｔｉｖｅ）ストリーミングモデルの全般的な動作を示した図である。
【０２０６】
本発明は、ＨＤＲ（Ｈｉｇｈ  Ｄｙｎａｍｉｃ  Ｒａｎｇｅ）をサポートできるコンテンツを提供する次世代メディアサービス提供方案を提案する。豊かな明るさの表現が可能なＨＤＲコンテンツが提供される場合において、本発明は、これに関連するメタデータ及びその伝達方案を提案する。これを通じて、コンテンツの様々な場面別の特性に応じて適応的にコンテンツを調整することができ、コンテンツを改善された画質で提供することができる。
【０２０７】
ＵＨＤ放送などの場合、既存のコンテンツが表現できなかった明るさを表現できるため、高度の臨場感を提供することができる。ＨＤＲの導入でコンテンツ映像の明るさの表現範囲が増加して、コンテンツの場面別特性の差が以前よりも大きくなり得る。コンテンツの場面別特徴を効果的にディスプレイに示すために、メタデータが定義され、これらが受信機に伝達され得る。受信機では、伝達されたメタデータに基づいて、サービスプロバイダの意図に従ってコンテンツの映像を適切に提供することができる。
【０２０８】
図示された実施例に係るＤＡＳＨベースの適応型ストリーミングモデルは、ＨＴＴＰサーバーとＤＡＳＨクライアントとの間の動作を記述している。ここで、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）は、ＨＴＴＰベースの適応型ストリーミングをサポートするためのプロトコルであって、ネットワークの状況に応じて動的にストリーミングをサポートすることができる。これによって、ＡＶコンテンツの再生が途切れることなく提供され得る。
【０２０９】
まず、ＤＡＳＨクライアントはＭＰＤを取得することができる。ＭＰＤは、ＨＴＴＰサーバーなどのサービスプロバイダから伝達され得る。ＭＰＤは、前述したデリバリの実施例に従って伝達されてもよい。ＤＡＳＨクライアントは、ＭＰＤに記述されたセグメントへの接近（近接）情報を用いてサーバーに当該セグメントを要求することができる。ここで、この要求は、ネットワークの状態を反映して行われ得る。
【０２１０】
ＤＡＳＨクライアントは、当該セグメントを取得した後、これをメディアエンジンで処理して画面にディスプレイすることができる。ＤＡＳＨクライアントは、再生時間及び／又はネットワークの状況などをリアルタイムに反映して、必要なセグメントを要求、取得することができる（Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ）。これを通じて、コンテンツが途切れることなく再生され得る。
【０２１１】
ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）は、ＤＡＳＨクライアントがセグメントを動的に取得できるようにするための詳細情報を含むファイルであって、ＸＭＬの形態で表現されてもよい。このＭＰＤは、実施例によって、前述したＭＰＤと同一であってもよい。
【０２１２】
ＤＡＳＨクライアントコントローラ（ＤＡＳＨ  Ｃｌｉｅｎｔ  Ｃｏｎｔｒｏｌｌｅｒ）は、ネットワークの状況を反映して、ＭＰＤ及び／又はセグメントを要求するコマンドを生成することができる。また、このコントローラは、取得された情報をメディアエンジンなどの内部ブロックで利用可能なように制御することができる。
【０２１３】
ＭＰＤパーサー（Ｐａｒｓｅｒ）は、取得したＭＰＤをリアルタイムでパーシングすることができる。これを通じて、ＤＡＳＨクライアントコントローラは、必要なセグメントを取得できるコマンドを生成できるようになる。
【０２１４】
セグメントパーサー（Ｐａｒｓｅｒ）は、取得したセグメントをリアルタイムでパーシングすることができる。セグメントに含まれた情報によって、メディアエンジンなどの内部ブロックは特定の動作を行うことができる。
【０２１５】
ＨＴＴＰクライアントは、必要なＭＰＤ及び／又はセグメントなどをＨＴＴＰサーバーに要求することができる。また、ＨＴＴＰクライアントは、サーバーから取得したＭＰＤ及び／又はセグメントをＭＰＤパーサー又はセグメントパーサーに伝達することができる。
【０２１６】
メディアエンジン（Ｍｅｄｉａ  Ｅｎｇｉｎｅ）は、セグメントに含まれたメディアデータを用いてコンテンツを画面上に表示することができる。このとき、ＭＰＤの情報が活用され得る。
【０２１７】
図１３は、本発明の一実施例に係る受信機のブロックダイヤグラムを示した図である。
【０２１８】
図示された実施例に係る受信機は、チューナー（Ｔｕｎｅｒ）、フィジカルレイヤコントローラ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｃｏｎｔｒｏｌｌｅｒ）、フィジカルフレームパーサー（Ｐｈｙｓｉｃａｌ  Ｆｒａｍｅ  Ｐａｒｓｅｒ）、リンクレイヤフレームプロセッサ（Ｌｉｎｋ  Ｌａｙｅｒ  Ｆｒａｍｅ  Ｐｒｏｃｅｓｓｏｒ）、ＩＰ／ＵＤＰデータグラムフィルター（ＩＰ／ＵＤＰ  Ｄａｔａｇｒａｍ  Ｆｉｌｔｅｒ）、ＤＴＶコントロールエンジン（ＤＴＶ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ）、ＲＯＵＴＥクライアント（Ｒｏｕｔｅ  Ｃｌｉｅｎｔ）、セグメントバッファコントロール（Ｓｅｇｍｅｎｔ  Ｂｕｆｆｅｒ  Ｃｏｎｔｒｏｌ）、ＭＭＴクライアント（ＭＭＴ  Ｃｌｉｅｎｔ）、ＭＰＵリコンストラクション（ＭＰＵ  ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ）、メディアプロセッサ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｏｒ）、シグナリングパーサー（Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）、ＤＡＳＨクライアント（ＤＡＳＨ  Ｃｌｉｅｎｔ）、ＩＳＯ  ＢＭＦＦパーサー（ＩＳＯ  ＢＭＦＦ  Ｐａｒｓｅｒ）、メディアデコーダ（Ｍｅｄｉａ  Ｄｅｃｏｄｅｒ）及び／又はＨＴＴＰアクセスクライアント（ＨＴＴＰ  Ａｃｃｅｓｓ  Ｃｌｉｅｎｔ）を含むことができる。受信機の各細部ブロック（ｂｌｏｃｋ）は、ハードウェアであるプロセッサであってもよい。
【０２１９】
チューナーは、地上波放送チャネルを介して放送信号を受信及び処理し、これを適切な形態（Ｐｈｙｓｉｃａｌ  Ｆｒａｍｅなど）に変換することができる。フィジカルレイヤコントローラは、受信しようとする放送チャネルのＲＦ情報などを用いて、チューナー、フィジカルフレームパーサーなどの動作を制御することができる。フィジカルフレームパーサーは、受信されたフィジカルフレームをパーシングし、これと関連するプロセッシングを通じてリンクレイヤフレームなどを取得することができる。
【０２２０】
リンクレイヤフレームプロセッサは、リンクレイヤフレームからリンクレイヤシグナリングなどを取得するか、またはＩＰ／ＵＤＰデータグラムを取得し、関連する演算を行うことができる。ＩＰ／ＵＤＰデータグラムフィルターは、受信されたＩＰ／ＵＤＰデータグラムから特定のＩＰ／ＵＤＰデータグラムをフィルタリングすることができる。ＤＴＶコントロールエンジンは、各構成間のインターフェースを担当し、パラメータなどの伝達を通じて各構成の動作を制御することができる。
【０２２１】
ＲＯＵＴＥクライアントは、リアルタイムオブジェクト伝送をサポートするＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）パケットを処理し、多数のパケットを収集及び処理して一つ以上のＩＳＯＢＭＦＦ（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ）オブジェクトを生成することができる。セグメントバッファコントロールは、ＲＯＵＴＥクライアントとＤａｓｈクライアントとの間のセグメント（ｓｅｇｍｅｎｔ）伝送に関連するバッファを制御することができる。
【０２２２】
ＭＭＴクライアントは、リアルタイムオブジェクト伝送をサポートするＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）伝送プロトコルパケットを処理し、多数のパケットを収集及び処理することができる。ＭＰＵリコンストラクションは、ＭＭＴＰパケットからＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を再構成することができる。メディアプロセッサは、再構成されたＭＰＵを収集し、処理することができる。
【０２２３】
シグナリングパーサーは、ＤＴＶ放送サービス関連シグナリング（Ｌｉｎｋ  Ｌａｙｅｒ／  Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を取得及びパーシングし、これに基づいてチャネルマップなどを生成及び／又は管理することができる。この構成は、ローレベルシグナリング及びサービスレベルシグナリングを処理することができる。
【０２２４】
ＤＡＳＨクライアントは、リアルタイムストリーミングあるいは適応的ストリーミング関連演算及び取得したＤＡＳＨセグメントなどを処理することができる。ＩＳＯ  ＢＭＦＦパーサーは、ＩＳＯ  ＢＭＦＦオブジェクトからオーディオ／ビデオのデータ及び関連パラメータなどを抽出することができる。メディアデコーダは、受信されたオーディオ及びビデオデータをデコーディング及び／又はプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）処理することができる。ＨＴＴＰアクセスクライアントは、ＨＴＴＰサーバーから特定の情報を要求し、要求に対する応答を処理することができる。
【０２２５】
図１４は、本発明の一実施例に係るメディアファイルの構造を示した図である。
【０２２６】
オーディオ又はビデオなどのメディアデータを格納し、伝送するために、定型化されたメディアファイルフォーマットが定義され得る。実施例によって、本発明のメディアファイルは、ＩＳＯ  ＢＭＦＦ（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）に基づいたファイルフォーマットを有してもよい。
【０２２７】
本発明に係るメディアファイルは、少なくとも１つ以上のボックスを含むことができる。ここで、ボックス（ｂｏｘ）は、メディアデータ又はメディアデータに関連するメタデータなどを含むデータブロック乃至オブジェクトであってもよい。ボックスは、互いに階層的構造をなすことができ、これによって、データが分類されて、メディアファイルが大容量メディアデータの格納及び／又は伝送に適した形態を有するようになる。また、メディアファイルは、ユーザがメディアコンテンツの特定の地点に移動するなど、メディア情報に接近するにおいて容易な構造を有することができる。
【０２２８】
本発明に係るメディアファイルは、ｆｔｙｐボックス、ｍｏｏｖボックス及び／又はｍｄａｔボックスを含むことができる。
【０２２９】
ｆｔｙｐボックス（ファイルタイプボックス）は、当該メディアファイルに対するファイルタイプ又は互換性関連情報を提供することができる。ｆｔｙｐボックスは、当該メディアファイルのメディアデータに対する構成バージョン情報を含むことができる。復号器は、ｆｔｙｐボックスを参照して当該メディアファイルを区分することができる。
【０２３０】
ｍｏｏｖボックス（ムービーボックス）は、当該メディアファイルのメディアデータに対するメタデータを含むボックスであり得る。ｍｏｏｖボックスは、全てのメタデータのためのコンテナの役割を果たすことができる。ｍｏｏｖボックスは、メタデータ関連ボックスのうち最上位層のボックスであり得る。実施例によって、ｍｏｏｖボックスはメディアファイル内に一つのみが存在してもよい。
【０２３１】
ｍｄａｔボックス（メディアデータボックス）は、当該メディアファイルの実際のメディアデータを入れるボックスであり得る。メディアデータは、オーディオサンプル及び／又はビデオサンプルを含むことができ、ｍｄａｔボックスは、このようなメディアサンプルを入れるコンテナの役割を果たすことができる。
【０２３２】
実施例によって、前述したｍｏｏｖボックスは、ｍｖｈｄボックス、ｔｒａｋボックス及び／又はｍｖｅｘボックスなどを下位ボックスとしてさらに含んでもよい。
【０２３３】
ｍｖｈｄボックス（ムービーヘッダーボックス）は、当該メディアファイルに含まれるメディアデータのメディアプレゼンテーション関連情報を含むことができる。すなわち、ｍｖｈｄボックスは、当該メディアプレゼンテーションのメディア生成時間、変更時間、時間規格、期間などの情報を含むことができる。
【０２３４】
ｔｒａｋボックス（トラックボックス）は、当該メディアデータのトラックに関連する情報を提供することができる。ｔｒａｋボックスは、オーディオトラック又はビデオトラックに対するストリーム関連情報、プレゼンテーション関連情報、アクセス関連情報などの情報を含むことができる。ｔｒａｋボックスは、トラックの個数に応じて複数個存在してもよい。
【０２３５】
ｔｒａｋボックスは、実施例によって、ｔｋｈｄボックス（トラックヘッダーボックス）を下位ボックスとしてさらに含んでもよい。ｔｋｈｄボックスは、ｔｒａｋボックスが示す当該トラックに関する情報を含むことができる。ｔｋｈｄボックスは、当該トラックの生成時間、変更時間、トラック識別子などの情報を含むことができる。
【０２３６】
ｍｖｅｘボックス（ムービーエクステンドボックス）は、当該メディアファイルに後述するｍｏｏｆボックスが存在し得ることを示すことができる。特定のトラックの全てのメディアサンプルを知るために、ｍｏｏｆボックスがスキャンされなければならない。
【０２３７】
本発明に係るメディアファイルは、実施例によって、複数個のフラグメントに分けられてもよい（ｔ１４０１０）。これを通じて、メディアファイルが分割されて格納又は伝送され得る。メディアファイルのメディアデータ（ｍｄａｔボックス）は複数個のフラグメントに分けられ、それぞれのフラグメントは、ｍｏｏｆボックス及び分けられたｍｄａｔボックスを含むことができる。実施例によって、フラグメントを活用するためには、ｆｔｙｐボックス及び／又はｍｏｏｖボックスの情報が必要となり得る。
【０２３８】
ｍｏｏｆボックス（ムービーフラグメントボックス）は、当該フラグメントのメディアデータに対するメタデータを提供することができる。ｍｏｏｆボックスは、当該フラグメントのメタデータ関連ボックスのうち最上位層のボックスであり得る。
【０２３９】
ｍｄａｔボックス（メディアデータボックス）は、前述したように、実際のメディアデータを含むことができる。このｍｄａｔボックスは、それぞれの当該フラグメントに該当するメディアデータのメディアサンプルを含むことができる。
【０２４０】
実施例によって、前述したｍｏｏｆボックスは、ｍｆｈｄボックス及び／又はｔｒａｆボックスなどを下位ボックスとしてさらに含んでもよい。
【０２４１】
ｍｆｈｄボックス（ムービーフラグメントヘッダーボックス）は、分割された複数個のフラグメント間の連関性に関連する情報を含むことができる。ｍｆｈｄボックスは、シーケンス番号（ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ）を含むことで、当該フラグメントのメディアデータが分割された何番目のデータであるかを示すことができる。また、ｍｆｈｄボックスを用いて、分割されたデータのうち抜け落ちたものがあるかどうかを確認できる。
【０２４２】
ｔｒａｆボックス（トラックフラグメントボックス）は、当該トラックフラグメントに対する情報を含むことができる。ｔｒａｆボックスは、当該フラグメントに含まれる分割されたトラックフラグメントに対するメタデータを提供することができる。ｔｒａｆボックスは、当該トラックフラグメント内のメディアサンプルが復号化／再生され得るようにメタデータを提供することができる。ｔｒａｆボックスは、トラックフラグメントの個数に応じて複数個存在してもよい。
【０２４３】
実施例によって、前述したｔｒａｆボックスは、ｔｆｈｄボックス及び／又はｔｒｕｎボックスなどを下位ボックスとしてさらに含んでもよい。
【０２４４】
ｔｆｈｄボックス（トラックフラグメントヘッダーボックス）は、当該トラックフラグメントのヘッダー情報を含むことができる。ｔｆｈｄボックスは、前述したｔｒａｆボックスが示すトラックフラグメントのメディアサンプルに対して、基本的なサンプルのサイズ、期間、オフセット、識別子などの情報を提供することができる。
【０２４５】
ｔｒｕｎボックス（トラックフラグメントランボックス）は、当該トラックフラグメント関連情報を含むことができる。ｔｒｕｎボックスは、メディアサンプル毎の期間、サイズ、再生時点などのような情報を含むことができる。
【０２４６】
前述したメディアファイル乃至メディアファイルのフラグメントは、セグメントとして処理されて伝送され得る。セグメントには、初期化セグメント（ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ｓｅｇｍｅｎｔ）及び／又はメディアセグメント（ｍｅｄｉａ  ｓｅｇｍｅｎｔ）があり得る。
【０２４７】
図示された実施例（ｔ１４０２０）のファイルは、メディアデータは除いて、メディアデコーダの初期化に関連する情報などを含むファイルであり得る。このファイルは、例えば、前述した初期化セグメントに該当してもよい。初期化セグメントは、前述したｆｔｙｐボックス及び／又はｍｏｏｖボックスを含むことができる。
【０２４８】
図示された実施例（ｔ１４０３０）のファイルは、前述したフラグメントを含むファイルであり得る。このファイルは、例えば、前述したメディアセグメントに該当してもよい。メディアセグメントは、前述したｍｏｏｆボックス及び／又はｍｄａｔボックスを含むことができる。また、メディアセグメントは、ｓｔｙｐボックス及び／又はｓｉｄｘボックスをさらに含むことができる。
【０２４９】
ｓｔｙｐボックス（セグメントタイプボックス）は、分割されたフラグメントのメディアデータを識別するための情報を提供することができる。ｓｔｙｐボックスは、分割されたフラグメントに対して、前述したｆｔｙｐボックスと同様の役割を果たすことができる。実施例によって、ｓｔｙｐボックスは、ｆｔｙｐボックスと同じフォーマットを有してもよい。
【０２５０】
ｓｉｄｘボックス（セグメントインデックスボックス）は、分割されたフラグメントに対するインデックスを示す情報を提供することができる。これを通じて、当該分割されたフラグメントが何番目のフラグメントであるかを示すことができる。
【０２５１】
実施例によって（ｔ１４０４０）、ｓｓｉｘボックスがさらに含まれてもよく、ｓｓｉｘボックス（サブセグメントインデックスボックス）は、セグメントがサブセグメントにさらに分けられる場合において、そのサブセグメントのインデックスを示す情報を提供することができる。
【０２５２】
メディアファイル内のボックスは、図示された実施例（ｔ１４０５０）のようなボックス乃至フルボックス（ＦｕｌｌＢｏｘ）の形態をベースとして、さらに拡張された情報を含むことができる。この実施例において、ｓｉｚｅフィールド及びｌａｒｇｅｓｉｚｅフィールドは、当該ボックスの長さをバイト単位などで示すことができる。ｖｅｒｓｉｏｎフィールドは、当該ボックスのフォーマットのバージョンを示すことができる。ｔｙｐｅフィールドは、当該ボックスのタイプ乃至識別子を示すことができる。ｆｌａｇｓフィールドは、当該ボックスに関連するフラグなどを示すことができる。
【０２５３】
図１５は、本発明の一実施例に係るＳＬＴを介したブートストラッピング過程を示した図である。
【０２５４】
前述したように、ＳＬＴのブートストラップ情報を介してＳＬＳブートストラッピングが行われてもよい。前述したように、ＳＬＴは、ＩＰ／ＵＤＰで処理されて伝送されてもよく、実施例によって、ＩＰ／ＵＤＰで処理されずに伝送されてもよい。一般に、ＳＬＴなどのＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）は、当該伝送において最も堅固な（ｒｏｂｕｓｔ）方法により伝達され得る。
【０２５５】
ＳＬＳがＲＯＵＴＥプロトコルによって伝送される場合、受信機は、ＳＬＴのブートストラップ情報を介して当該ＳＬＳに接近することができる。ＲＯＵＴＥ  ＳＬＳの情報を用いて当該サービスのサービスコンポーネントを取得することができる。ここで、ＳＬＳ及びサービスコンポーネントは、ＲＯＵＴＥ、ＵＤＰ、及びＩＰプロトコルによって伝送され得る。
【０２５６】
ＳＬＳがＭＭＴプロトコルによって伝送される場合、受信機は、ＳＬＴのブートストラップ情報を介して当該ＳＬＳに接近することができる。ＭＭＴＰ  ＳＬＳの情報を用いて当該サービスのサービスコンポーネントを取得することができる。ＭＭＴＰ  ＳＬＳには、ＵＳＢＤ及び／又はＭＭＴＰメッセージが含まれてもよい。前述したように、ＵＳＢＤは、ＭＭＴＰメッセージをリファレンスすることができ、ＭＭＴＰメッセージにおいてＭＰＴメッセージは、ＭＭＴプロトコルによって伝達されるストリーミングコンポーネントを取得するための情報を提供することができる。ＭＭＴのＵＳＢＤは、ＲＯＵＴＥプロトコルで伝達される当該サービスのＮＲＴコンポーネントを取得するためのＳ−ＴＳＩＤをさらにリファレンスすることができる。前述したＭＰＴメッセージ以外にも、他の情報を提供するための他のＭＭＴＰメッセージが定義されてもよい。ここで、ＳＬＳ及びストリーミングコンポーネントは、ＭＭＴ、ＵＤＰ、及びＩＰプロトコルによって伝達されてもよい。ここで、ＮＲＴコンポーネントは、ＲＯＵＴＥ、ＵＤＰ、及びＩＰプロトコルによって伝送されてもよい。詳細なブートストラッピングの過程は、前述した通りである。
【０２５７】
図１６は、本発明の一実施例に係るＭＭＴプロトコルベースのシグナリングの流れを示した図である。
【０２５８】
まず、ＳＬＴを取得し、これを用いてＳＬＳを取得する過程は同一であってもよい。ＭＭＴベースのシグナリングの場合、ＳＬＳは、ＵＳＢＤ及び／又はＭＭＴＰメッセージを含むことができる。ＵＳＢＤから、当該サービスに関連するＭＭＴパッケージ（Ｐａｃｋａｇｅ）に関する情報を取得することができる。これを用いて、サービスシグナリングチャネルなどからＭＰＴ（ＭＰ  Ｔａｂｌｅ）メッセージを取得することができる。ＭＰＴメッセージを介して、当該サービスのサービスコンポーネントを取得することができる。図示された実施例において、スケーラブルコーディングコンテンツのベースレイヤに対するアセット（Ａｓｓｅｔ）及び／又はエンハンスメントレイヤに対するアセットに関する情報を取得することができる。また、各アセットを取得できる経路（伝送セッションなど...）が取得され得る。ここで、アセットは、サービスのサービスコンポーネントに該当し得る。当該経路を介してＭＰＵを取得し、これをデコードして再生することができる。詳細なブートストラッピングの過程は、前述した通りである。
【０２５９】
実施例によって、ＭＰＴメッセージ以外の他のＭＭＴＰメッセージが定義されてもよい。これらのメッセージを介して、当該サービスに対する付加的な情報を伝達することができる。例えば、スケーラブルコーディング関連情報、３Ｄ関連情報、ＨＤＲ関連情報、カラーガマット関連情報、サービスコンポーネントに対する付加情報などが、これらのメッセージを介して伝達されてもよい。実施例によって、ブロードバンドを介して伝達されるサービスコンポーネントのためのＭＰＤ、またはアプリケーションシグナリングのためのテーブル、イベント情報もまた、このメッセージを介して伝達されてもよい。
【０２６０】
図１７は、本発明の一実施例に係るケイパビリティディスクリプタを示した図である。
【０２６１】
本発明は、放送サービス又はサービスに含まれるサービスコンポーネントのケイパビリティ情報をシグナリングする方案を提案する。サービス／サービスコンポーネントに対するケイパビリティ又はケイパビリティグループに対してシグナリングを行うことができ、ターゲットデバイス（ｔａｒｇｅｔ  ｄｅｖｉｃｅ）に応じて、ケイパビリティ情報がシグナリングされてもよい。
【０２６２】
前述したＳＬＴにはケイパビリティ情報が含まれてもよい。ＳＬＴが記述するサービス全体に対するケイパビリティ情報であってもよく、ＳＬＴが記述するそれぞれのサービスに対するサービスレベルのケイパビリティ情報であってもよい。前述した＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性又は＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性がここに該当し得る。ＳＬＴがバイナリフォーマットを有する場合、ケイパビリティ情報は、ＳＬＴレベルのディスクリプタ又はＳＬＳレベルのディスクリプタとしてＳＬＴに含まれてもよい。
【０２６３】
図示されたケイパビリティディスクリプタは、前述したケイパビリティ情報をディスクリプタの形態で示したものである。しかし、実施例によって、ケイパビリティ情報は、ＸＭＬなどの他のフォーマットで表現されてもよい。また、実施例によって、図示されたケイパビリティディスクリプタ内の情報のような情報が、前述したＳＬＴの＠ｓｌｔＣａｐａｂｉｌｉｔｉｅｓ属性又は＠ｓｖｃＣａｐａｂｉｌｉｔｉｅｓ属性に含まれてもよい。この場合、ディスクリプタタグ、ディスクリプタの長さ情報などは省略されてもよい。以下では、ディスクリプタを基準として、このケイパビリティ情報を説明する。
【０２６４】
図示された実施例のケイパビリティディスクリプタは、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド及び／又はｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｓフィールドを含むことができる。ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールド及びｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、それぞれ、当該ディスクリプタがケイパビリティディスクリプタであることを識別する情報、及び当該ディスクリプタの長さ情報を提供することができる。
【０２６５】
ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｓフィールドは、当該ディスクリプタが含むケイパビリティ情報の個数を示すことができる。実施例によって、このフィールドは、当該ディスクリプタが含むケイパビリティコードの個数を示してもよい。ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅｓフィールドの値に応じて、それぞれのケイパビリティ情報に対する細部フィールドがさらに含まれてもよい。細部フィールドとしては、ｅｓｓｅｎｔｉａｌ＿ｉｎｄｉｃａｔｏｒフィールド、ｃａｐａｂｉｌｉｔｙ＿ｃａｔｅｇｏｒｙフィールド及び／又はｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅフィールドがあり得る。実施例によって、ｅｓｓｅｎｔｉａｌ＿ｉｎｄｉｃａｔｏｒフィールドは省略されてもよい。
【０２６６】
ｅｓｓｅｎｔｉａｌ＿ｉｎｄｉｃａｔｏｒフィールドは、後続するケイパビリティコードが当該サービス又はサービスコンポーネントを再生する際に必ずサポートされなければならないケイパビリティであるか否かを示すことができる。このフィールドの値が１である場合、当該サービス又はサービスコンポーネントを再生する際に、後続するケイパビリティが必ずサポートされなければならないことを知ることができる。
【０２６７】
ｃａｐａｂｉｌｉｔｙ＿ｃａｔｅｇｏｒｙフィールドは、後続するケイパビリティ情報のカテゴリを示すことができる。実施例によって、本フィールドは、後続するケイパビリティ情報が適用される対象を示してもよい。ケイパビリティカテゴリ情報は、ケイパビリティのカテゴリを分類するためであり得る。実施例によって、ケイパビリティカテゴリ情報は、当該サービス又はサービスコンポーネントに対して同一に適用できるケイパビリティをグループ化するためであってもよい。これを通じて、サービス内のコンポーネントに同一に適用されるケイパビリティ或いはコンポーネント別に適用されるケイパビリティ情報などがシグナリングされ得る。
【０２６８】
例えば、本フィールドの値が０ｘ０２である場合、当該ケイパビリティは、ビデオコンポーネントに関連するケイパビリティであってもよい。すなわち、後続するケイパビリティコードがビデオ関連ケイパビリティに対するケイパビリティコードであることを知ることができる。例えば、ビデオコーデック、レゾリューション、ビデオプロビジョンメソッド（ｐｒｏｖｉｓｉｏｎ  ｍｅｔｈｏｄ）、伝送プロトコル、ＦＥＣアルゴリズム、ターゲットデバイスなどに関連するケイパビリティコードが後続してもよい。
【０２６９】
本フィールドの値が０ｘ０３である場合、当該ケイパビリティは、オーディオコンポーネントに関連するケイパビリティであってもよい。すなわち、後続するケイパビリティコードがオーディオ関連ケイパビリティに対するケイパビリティコードであることを知ることができる。例えば、オーディオコーデック、オーディオチャネル、伝送プロトコル、ＦＥＣアルゴリズム、ターゲットデバイスなどに関連するケイパビリティコードが後続してもよい。
【０２７０】
本フィールドの値が０ｘ０４である場合、当該ケイパビリティは、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）に関するケイパビリティであってもよい。例えば、クローズドキャプションのタイプ、伝送プロトコル、ＦＥＣアルゴリズム、ターゲットデバイスなどに関連するケイパビリティコードが後続してもよい。
【０２７１】
本フィールドの値が０ｘ０５である場合、当該ケイパビリティは、アプリケーションに関連するケイパビリティであってもよい。例えば、アプリケーションのタイプ、伝送プロトコル、ＦＥＣアルゴリズム、ターゲットデバイスなどに関連するケイパビリティコードが後続してもよい。
【０２７２】
本フィールドの値が０ｘ０６〜０ｘ０８である場合、当該ケイパビリティは、それぞれ、伝送プロトコル、ＦＥＣアルゴリズム、ターゲットデバイスに関するケイパビリティであってもよい。すなわち、ビデオ／オーディオ／クローズドキャプション／アプリケーションに関連するケイパビリティではない。この場合、後続するケイパビリティコードによって指示される伝送プロトコル、ＦＥＣアルゴリズム及びターゲットデバイスに対する事項は、当該サービス内の全てのコンポーネント（ビデオ／オーディオ／クローズドキャプション／アプリケーション）に同一に適用できる。
【０２７３】
ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅフィールドは、当該サービス又はサービスコンポーネントに対するケイパビリティ情報を示すケイパビリティコードを指示することができる。ここで、ケイパビリティコードは、それぞれのケイパビリティに対して指定されたコード値であってもよい。これについては後述する。
【０２７４】
例えば、ある放送サービスが、ＨＥＶＣをベースとするＵＨＤビデオ、ＭＰＥＧ−Ｈをベースとする７．１チャネルオーディオ、及びＳＭＰＴＥタイムドテキスト（Ｔｉｍｅｄ  Ｔｅｘｔ）をベースとするクローズドキャプションを提供する場合、当該ディスクリプタは、これを示すケイパビリティコードを有することができる。この場合、ｎｕｍ＿ｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅは、０ｘ０５の値を有することができる。５個のｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅは、それぞれ０ｘ１３（ＨＥＶＣ）、０ｘ２２（ｕｌｔｒａ  ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ  ｖｉｄｅｏ）、０ｘ４０（ＭＰＥＧ−Ｈ  ａｕｄｉｏ）、０ｘ５２（７．１ｃｈａｎｎｅｌ）及び／又は０ｘ６０（ＳＭＰＴＥ  ｔｉｍｅｄ  ｔｅｘｔ）の値を有することができる。ここで、ｅｓｓｅｎｔｉａｌ＿ｉｎｄｉｃａｔｏｒフィールドは省略されてもよい。
【０２７５】
図１８は、本発明の一実施例に係るケイパビリティコードを示した図である。
【０２７６】
ケイパビリティコードは、前述したように、当該サービス又はサービスコンポーネントに対するケイパビリティを示すコードであってもよい。図示されたケイパビリティコードは、前述したｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅフィールドに使用可能な値であり得る。図示されたケイパビリティコードの各分類（ビデオ、オーディオなど...）は、前述したｃａｐａｂｉｌｉｔｙ＿ｃａｔｅｇｏｒｙフィールドに使用可能な値であり得る。
【０２７７】
実施例によって、図示されたケイパビリティコードの前部のディジット（例えば、０ｘ０１，０ｘ０２，０ｘ０３...）を、ケイパビリティのカテゴリを識別するのに使用してもよい。この場合、当該ケイパビリティコードの残りのディジットは、当該カテゴリ内で当該ケイパビリティを識別するのに使用することができる。本発明の一実施例に係るケイパビリティコードは、ハイクオリティビデオエンハンスメントタイプ（Ｈｉｇｈ  Ｑｕａｌｉｔｙ  Ｖｉｄｅｏ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｔｙｐｅ）に対するケイパビリティコードを含むことができる。例えば、ケイパビリティコードが０ｘＡ０である場合、ＨＤＲ（ｈｉｇｈ  ｄｙｎａｍｉｃ  ｒａｎｇｅ）、０ｘＡ１である場合、ＷＣＧ（ｗｉｄｅ  ｃｏｌｏｒ  ｇａｍｕｔ）、０ｘＡ２である場合、ＨＦＲ（ｈｉｇｈ  ｆｒａｍｅ  ｒａｔｅ）を示すことができる。
【０２７８】
図１９は、本発明の他の実施例に係るＵＳＢＤの一部を示した図である。
【０２７９】
本発明は、放送サービス又はサービスに含まれるサービスコンポーネントのケイパビリティ情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対するビデオ／オーディオ／クローズドキャプション情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対するＨＥＶＣビデオ関連情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対するＳＭＰＴＥ−ＴＴ又はＣＥＡ−８０９ベースのクローズドキャプションに関する情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対する３Ｄ、スケーラブルコンテンツ、コンポーネントグループ、リアルタイムコンテンツであるか又は非リアルタイムコンテンツであるか、接近（近接）性（ａｃｃｅｓｓｉｂｉｌｉｔｙ）、ディスプレイ領域に対するビューコンフィギュレーション、及びターゲットスクリーンに関する情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対するＨＤＲ（Ｈｉｇｈ  Ｄｙｎａｍｉｃ  Ｒａｎｇｅ）、ＷＣＧ（ｗｉｄｅ  ｃｏｌｏｒ  ｇａｍｕｔ）、ＨＦＲ（Ｈｉｇｈ  Ｆｒａｍｅ  Ｒａｔｅ）、及びプルダウンリカバリーコンフィギュレーション（Ｐｕｌｌ  Ｄｏｗｎ  Ｒｅｃｏｖｅｒｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに対する３Ｄオーディオ、ＡＣ−４、及びＭＰＥＧ−Ｈ関連情報をシグナリングする方案を提案する。また、本発明は、サービス／サービスコンポーネントに関連して、ＰＩＰ（Ｐｉｃｔｕｒｅ  ｉｎ  Ｐｉｃｔｕｒｅ）関連情報をシグナリングする方案を提案する。これと関連して、ＰＩＰのＳＲＤ（Ｓｐａｔｉａｌ  Ｒｅｌａｔｉｏｎｓｈｉｐ  Ｄｅｓｃｒｉｐｔｉｏｎ）関連情報、ディスプレイプライオリティー（ｐｒｉｏｒｉｔｙ）情報、互いに異なるコンテンツソース間のＳＲＤシグナリング情報、各ビュー（ｖｉｅｗ）のディスプレイ領域に対するシグナリング情報、及び各ビュー（ｖｉｅｗ）の役割に関するシグナリング情報がシグナリングされ得る。
【０２８０】
前述した情報は、実施例によって、ＳＬＴ又は他のサービスシグナリング情報に含まれて伝達されてもよい。実施例によって、これらの情報は、ＲＯＵＴＥ又はＭＭＴによるＵＳＢＤに含まれて伝達されてもよい。また、実施例によって、これらの情報は、ＲＯＵＴＥ  ＳＬＳの一つとして定義されて、他のＳＬＳと共に伝達されてもよく、ＭＭＴＰ  ＳＬＳの一つとして定義されて、前述したＭＭＴＰメッセージのうち１つに含まれて伝達されてもよい。実施例によって、これらの情報は、ＭＰＤ内に含まれて伝達されてもよく、この場合、前述したエッセンシャルプロパティ（ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ）及び／又はサプリメンタルプロパティ（ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ）に含まれて伝達されてもよい。実施例によって、これらの情報は、ＭＭＴＰメッセージにおいて前述したＭＰＴメッセージに含まれたり、別に定義されたＭＭＴＰメッセージのうち１つに含まれて伝達されてもよい。実施例によって、これらの情報は、ＸＭＬ又はバイナリ形態の様々なディスクリプタで定義されて伝達されてもよく、エレメントで構成されてＲＯＵＴＥ、ＭＭＴ、３ＧＰＰなどによるシグナリング情報に含まれて伝達されてもよい。この情報については詳細に後述する。
【０２８１】
前述したＲＯＵＴＥ又はＭＭＴのＵＳＢＤは、実施例によって、ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを含んでもよい。ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントについては、前述した通りである。実施例によって、ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、図示されたフィールドをさらに含むように拡張されてもよい。
【０２８２】
図示された実施例において、ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントは、＠ｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩｄ、＠ｅｓｓｅｎｔｉａｌＩｎｄｉｃａｔｏｒ、＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤ、＠ｐｒｏｔｏｃｏｌＴｙｐｅ、＠ｒｔ、＠ｔａｒｇｅｔＤｅｖｉｃｅ、＠ｃｏｍｐｏｎｅｎｔＣｏｄｅｃ、＠ｃｏｍｐｏｎｅｎｔＰｒｏｆｉｌｅ、＠ｃｏｍｐｏｎｅｎｔＬａｎｇ、＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、Ａｃｃｅｓｓｉｂｉｌｉｔｙ、Ｃａｐａｂｉｌｉｔｙ、Ｒａｔｉｎｇ、Ｔａｒｇｅｔｉｎｇ、ＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎ及び／又はＣｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙをさらに含むことができる。実施例によって、この追加されたフィールドの一部のみがＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントに追加されてもよい。
【０２８３】
＠ｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩｄは、コンポーネントグループの識別子であってもよい。ここで、コンポーネントグループはコンポーネントのコレクションであり得る。コンポーネントグループに含まれるコンポーネントは、同じシーン（ｓｃｅｎｅ）を示す、またはプレゼンテーションを生成するために組み合わされるコンポーネントであってもよい。例えば、完成されたオーディオを提供するために使用されるミュージック、ダイアログ、及び音響エフェクトを含むサービスコンポーネントは、一つのコンポーネントグループにグループ化することができる。また、３Ｄ映像の左映像及び右映像を含むサービスコンポーネントは、一つのコンポーネントグループにグループ化することができる。
【０２８４】
＠ｅｓｓｅｎｔｉａｌＩｎｄｉｃａｔｏｒは、当該コンポーネントが当該サービスにおいて必須のコンポーネントであるか否かを示すことができる。このフィールドの値が１である場合、当該コンポーネントは、当該サービスにおいて必須のコンポーネントであってもよい。＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤは、従属的なコンポーネントに対する識別子を示すことができる。例えば、エンハンスドビデオコンポーネントにおいて、このフィールドはベースビデオコンポーネントの識別子を示すことができる。
【０２８５】
＠ｐｒｏｔｏｃｏｌＴｙｐｅは、当該コンポーネントを伝達する伝送プロトコルを示すことができる。例えば、ＲＯＵＴＥ又はＭＭＴプロトコルを示すことができる。＠ｒｔは、当該コンポーネントがリアルタイムコンポーネントであるか否かを示すことができる。
【０２８６】
＠ｔａｒｇｅｔＤｅｖｉｃｅは、当該コンポーネントがターゲットとするターゲットデバイスを示すことができる。例えば、このフィールドの値が０、１、２、３である場合、当該コンポーネントは、それぞれプライマリデバイス、コンパニオンデバイス、プライマリ＆コンパニオンデバイス、プライマリスクリーンのインセットのためのコンポーネントであることを示すことができる。
【０２８７】
＠ｃｏｍｐｏｎｅｎｔＣｏｄｅｃは、当該コンポーネントのためのコーデック情報を提供することができる。＠ｃｏｍｐｏｎｅｎｔＰｒｏｆｉｌｅは、当該コンポーネントのプロファイルを示すことができる。＠ｃｏｍｐｏｎｅｎｔＬａｎｇは、当該コンポーネントで使用される言語を示すことができる。このフィールドは、特にオーディオ及びクローズドキャプションコンポーネントにおいて使用することができる。＠ｗｉｄｔｈは、当該ビデオコンポーネントが伝達するビデオメディアプレゼンテーションの水平幅を示すことができる。＠ｈｅｉｇｈｔは、当該ビデオコンポーネントが伝達するビデオメディアプレゼンテーションの垂直高さを示すことができる。
【０２８８】
Ａｃｃｅｓｓｉｂｉｌｉｔｙは、当該コンポーネントの接近性（ａｃｃｅｓｓｉｂｉｌｉｔｙ）関連情報を提供することができる。Ｃａｐａｂｉｌｉｔｙは、当該コンポーネントのケイパビリティ関連情報を提供することができる。Ｒａｔｉｎｇは、当該コンポーネントのレーティング関連情報を提供することができる。Ｔａｒｇｅｔｉｎｇは、当該コンポーネントのターゲッティング又は個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）関連情報を提供することができる。ＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎは、当該コンポーネントのコンポーネントディスクリプション情報を提供することができる。この情報には、コーデックに従属的なエンコーディングパラメータ（ｃｏｄｅｃ  ｄｅｐｅｎｄｅｎｔ  ｅｎｃｏｄｉｎｇ  ｐａｒａｍｅｔｅｒｓ）が含まれてもよい。ＣｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙは、当該コンポーネントを処理するためのコンポーネント属性を提供することができる。
【０２８９】
また、ＣｏｍｐｏｎｅｎｔＩｎｆｏエレメント内の前述した＠ｃｏｍｐｏｎｅｎｔＴｙｐｅフィールドは、当該コンポーネントのタイプを示すことができ、０、１、２、３の値を有する場合、当該コンポーネントは、それぞれオーディオ、ビデオ、キャプション、アプリケーションコンポーネントであることを示すことができる。
【０２９０】
また、＠ｃｏｍｐｏｎｅｎｔＲｏｌｅフィールドは、当該コンポーネントの役割（ｒｏｌｅ）を示すことができる。この役割は、指示されたコンポーネントタイプに応じて示すことができ、オーディオコンポーネントである場合、本フィールドが１、２、３、４、５、６、７の値を有すると、当該オーディオコンポーネントは、それぞれコンプリートメイン（ｃｏｍｐｌｅｔｅ  ｍａｉｎ）、ミュージック、エフェクト、ダイアログ、コメンタリ、ビジュアリインペアード（ｖｉｓｕａｌｌｙ  ｉｍｐａｉｒｅｄ）、ヒアリングインペアード（ｈｅａｒｉｎｇ  ｉｍｐａｉｒｅｄ）、ボイスオーバー（ｖｏｉｃｅ  ｏｖｅｒ）、サブセット（ｓｕｂｓｅｔ）の役割を果たすことができる。ここで、ビジュアリ／ヒアリングインペアードとは、それぞれ当該オーディオコンポーネントが視覚／聴覚障害者のためのオーディオコンポーネントであることを意味し得る。ボイスオーバーとは、当該オーディオコンポーネントがビデオコンポーネントをデスクライブする役割を果たすことを意味し得る。
【０２９１】
ビデオコンポーネントである場合、本フィールドの値に応じて、当該ビデオコンポーネントは、プライマリビデオ、代替カメラビュー、手話、３Ｄ左映像、３Ｄ右映像、３Ｄビデオの奥行き（ｄｅｐｔｈ）情報、キャプションを含むビデオなどの役割を果たすことを示すことができる。キャプションコンポーネントである場合、本フィールドの値に応じて、当該キャプションコンポーネントは、メイン、代替、付加（ｓｕｐｐｌｅｍｅｎｔａｒｙ）、ノーマル、イージーリーダーなどの役割を果たすことを意味し得る。
【０２９２】
実施例によって、前述したＲＯＵＴＥ又はＭＭＴのＵＳＢＤの残りの部分も変更可能である。このような変更は、それぞれの場合の数に応じて互いに組み合わされてもよい。実施例によって、ＵＳＢＤは、＠ｐｒｏｖｉｄｅｒｉｄ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｐＩｎｄｉｃａｔｏｒ、＠ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ及び／又はｃａｐａｂｉｌｉｔｙＣｏｄｅをさらに含むことができる。
【０２９３】
＠ｐｒｏｖｉｄｅｒｉｄは、当該サービスのサービスプロバイダを識別することができる。＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリを示すことができる。＠ｓｐＩｎｄｉｃａｔｏｒは、前述した＠ｐｒｏｔｅｃｔｅｄ属性と同一であってもよい。＠ｓｅｒｖｉｃｅＳｔａｔｕｓは、前述した＠ｓｅｒｖｉｃｅｓｔａｔｕｓ属性と同一であってもよい。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、当該サービスの短い名（Ｓｈｏｒｔ  ｎａｍｅ）を示すことができる。ｃａｐａｂｉｌｉｔｙＣｏｄｅは、当該サービスの有意なメディアプレゼンテーションを受信機が提供するために必要なケイパビリティ又はケイパビリティグループを示すことができる。
【０２９４】
実施例によって、ＵＳＢＤは、前述したＣｈａｎｎｅｌエレメントに＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ及び／又は＠ｓｅｒｖｉｃｅＬａｎｇをさらに含んでもよい。
【０２９５】
＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、当該サービスのメジャー／マイナーチャネルナンバーを示すことができる。＠ｓｅｒｖｉｃｅＬａｎｇは、当該サービスの主な使用言語（ｐｒｉｍａｒｙ  ｌａｎｇｕａｇｅ）を示すことができる。
【０２９６】
実施例によって、ＵＳＢＤは、前述したｒｏｕｔｅＣｏｍｐｏｎｅｎｔ及びｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔの代わりに、ｄａｓｈＣｏｍｐｏｎｅｎｔエレメントをさらに含んでもよい。ｄａｓｈＣｏｍｐｏｎｅｎｔエレメントは、＠ｆｕｌｌＭＰＤＵｒｉ、＠ｓＴＳＩＤＵｒｉ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントを含むことができる。
【０２９７】
＠ｆｕｌｌＭＰＤＵｒｉは、放送網又はブロードバンドを介して伝達されるサービスコンポーネントのためのＭＰＤへのリファレンス情報を提供することができる。＠ｓＴＳＩＤＵｒｉは、当該サービスのサービスコンポーネントに対する伝送セッション関連情報を提供することができる。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、当該サービスのサービスコンポーネントの伝送関連情報を提供することができる。前述したように、放送網／ブロードバンドを介して伝達されるコンポーネントのそれぞれに対するエレメント、及び／又はそれに対するｂａｓｅＰａｔｔｅｒｎ情報がさらに含まれてもよい。
【０２９８】
図２０は、本発明の一実施例に係るＭＰテーブルの一部を示した図である。
【０２９９】
前述したＭＰＴメッセージはＭＰテーブルを伝達することができる。前述したように、接近（近接）性、３Ｄ、キャプションなどの情報は、ＭＭＴＰメッセージを介して伝達されてもよい。図示のように、ＭＰＴメッセージ内に一部として含まれて伝達されてもよく、別個に定義されるＭＭＴＰメッセージを介してＭＭＴシグナリングとして伝達されてもよい。これらの情報及び伝達形態については詳細に後述する。
【０３００】
これらの情報は、ＭＰＴメッセージ又はその他のＭＭＴＰメッセージ内にディスクリプタの形態で伝達され得、実施例によって、このディスクリプタはアセットディスクリプタに該当してもよい。また、このディスクリプタは、ＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。
【０３０１】
実施例によって、ＭＭＴ上で、サービスコンポーネント（アセット（ａｓｓｅｔ）に該当する）に関する情報は、図示のようにシグナリングされてもよい。ＭＭＴＰメッセージに、後述するフィールドがさらに追加されてもよい。
【０３０２】
ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドは、当該サービスのタイプを示すことができる。すなわち、当該ＭＰテーブルに含まれた少なくとも１つのアセット（ａｓｓｅｔ）を組み合わせて提供できる最終サービスを意味し得る。例えば、当該フィールドは、ステレオスコピック３Ｄサービス、マルチビューサービス、パノラマサービスなどを示すことができる。
【０３０３】
ａｓｓｅｔ＿ｒｏｌｅ＿ｆｌａｇフィールドは、当該サービスコンポーネント（アセット）に対する役割（ｒｏｌｅ）情報が含まれるか否かを示すことができる。ａｓｓｅｔ＿ｔａｒｇｅｔ＿ｆｌａｇフィールドは、当該サービスコンポーネントに対するターゲットスクリーン情報が含まれるか否かを示すことができる。ａｓｓｅｔ＿ｇｒｏｕｐ＿ｆｌａｇフィールドは、当該サービスコンポーネントが特定のコンポーネントグループに属するか否かを示すことができる。特定のコンポーネントグループに含まれる場合、本フィールドの値が１であってもよい。ｒｔ＿ｆｌａｇフィールドは、当該サービスコンポーネントがリアルタイムで伝送されるか、または非リアルタイムで伝送されるかを示すことができる。本フィールドの値が１である場合、当該サービスコンポーネントはリアルタイムで伝送されてもよい。
【０３０４】
ａｓｓｅｔ＿ｒｏｌｅフィールドは、当該サービスコンポーネントの役割（ｒｏｌｅ）を示すことができる。例えば、本フィールドの値が０、１、２、３、４、５、６、又は７である場合、当該サービスコンポーネントは、プライマリビデオ、代替カメラビュー、他の代替ビデオコンポーネント、手話、フォローサブジェクトビデオ（Ｆｏｌｌｏｗ  ｓｕｂｊｅｃｔ  ｖｉｄｅｏ）、３Ｄ左映像、３Ｄ右映像、３Ｄ奥行き情報などの役割を果たすことを示すことができる。
【０３０５】
ａｓｓｅｔ＿ｔａｒｇｅｔフィールドは、当該サービスコンポーネントがターゲットとするターゲットデバイスを示すことができる。前述した＠ｔａｒｇｅｔＤｅｖｉｃｅの定義と同一であってもよい。ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄフィールドは、当該サービスコンポーネントが含まれるコンポーネントグループの識別子を提供することができる。コンポーネントグループについては、前述した通りである。
【０３０６】
図２１は、本発明の一実施例に係るアセットグループディスクリプタを示した図である。
【０３０７】
アセットグループディスクリプタは、サービスがＭＭＴプロトコルを介して伝達される場合において、コンポーネントグループ（アセットグループ）に対して記述することができる。このディスクリプタは、前述したものと同一の経路を介して伝達されてもよい。
【０３０８】
アセットグループディスクリプタは、当該コンポーネントグループを識別するａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄフィールド、当該コンポーネントグループに含まれるコンポーネント（アセット）の個数を示すｎｕｍ＿ｏｆ＿ａｃｃｅｓｓｉｂｌｉｔｙフィールド、及び／又はそれぞれのコンポーネントを識別するａｓｓｅｔ＿ｉｄ（）フィールドを含むことができる。
【０３０９】
図２２は、本発明の一実施例に係る接近（近接）性（ａｃｃｅｓｓｉｂｉｌｉｔｙ）情報を示した図である。
【０３１０】
接近（近接）性情報は、当該サービス又はサービスコンポーネントの接近性に関連する情報を含むことができる。接近性情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。
【０３１１】
図示された実施例（ｔ２５０１０）において、接近性情報は、ディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタが接近性情報に関連する接近性スキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ａｃｃｅｓｓｉｂｉｌｉｔｙ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、接近性スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３１２】
図示された実施例（ｔ２５０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。Ｖｉｓｕａｌｌｙ  ｉｍｐａｉｒｅｄは、当該サービスコンポーネントが視覚障害又は視力の弱い視聴者をターゲットとするサービスコンポーネントであるか否かを示すことができる。Ｈｅａｒｉｎｇ  ｉｍｐａｉｒｅｄは、当該サービスコンポーネントが聴覚障害又は聴力の弱い視聴者をターゲットとするサービスコンポーネントであるか否かを示すことができる。ｅｎｈａｎｃｅｄ−ａｕｄｉｏ−ｉｎｔｅｌｌｉｇｉｂｉｌｉｔｙは、当該オーディオサービスコンポーネントが了解度（ｉｎｔｅｌｌｉｇｉｂｉｌｉｔｙ）の面で強化された（ｅｎｈａｎｃｅｄ）形態のオーディオサービスコンポーネントであるか否かを示すことができる。３Ｄ  ｓｕｐｐｏｒｔｅｄは、当該サービスコンポーネントが３Ｄ機能をサポートするサービスコンポーネントであるか否かを示すことができる。実施例によって、当該サービスコンポーネントが３Ｄサービスに含まれるサービスコンポーネントであるか否かを示してもよい。Ｎｏｒｍａｌは、（主にクローズドキャプションコンポーネントに対して）当該サービスコンポーネントが一般の視聴者のためのサービスコンポーネントであるか否かを示すことができる。Ｅａｓｙ  ｒｅａｄｅｒは、（主にクローズドキャプションコンポーネントに対して）当該サービスコンポーネントがイージーリーダー（ｅａｓｙ  ｒｅａｄｅｒ）形態のサービスコンポーネントであるか否かを示すことができる。イージーリーダーは、読みやすい形態のクローズドキャプションを意味し得る。
【０３１３】
実施例によって、接近性情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有する接近性エレメントの形態で定義されてもよい。
【０３１４】
図示された実施例（ｔ２５０３０）において、接近性情報は、ディスクリプタの形態で定義さできる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。
【０３１５】
ｎｕｍ＿ｏｆ＿ａｃｃｅｓｓｉｂｌｉｔｙフィールドは、後続する接近（近接）性コード（ａｃｃｅｓｓｉｂｌｉｔｙ＿ｃｏｄｅ）の個数を示すことができる。ａｃｃｅｓｓｉｂｌｉｔｙ＿ｃｏｄｅフィールドは接近（近接）性関連情報を示すことができる。接近性関連情報は、接近性コードによって表現されてもよい。例えば、接近性コードが０ｘ００、０ｘ０１、０ｘ０２の値を有する場合、これは、それぞれビジュアリインペアード、ヒアリングインペアード、３Ｄサポートなどの意味を有することができる。これらの接近性情報については、前述した通りである。０ｘ０３〜０ｘＦＦの値は、将来の使用のために残すことができる。
【０３１６】
図２３は、本発明の一実施例に係る、ＵＳＢＤ内のＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントを示した図である。
【０３１７】
図示された実施例（ｔ２６０１０）において、３Ｄビデオをなすそれぞれのコンポーネントに対するシグナリングが行われている。１番目のコンポーネントは、ビデオコンポーネントであって（０ｘ０２，Ｖｉｄｅｏ）、３Ｄ左映像としての役割を果たすことを示し（＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ＝３Ｄ  ｖｉｄｅｏ  ｌｅｆｔ  ｖｉｅｗ）、０ｘ０１のコンポーネントＩＤを有することができる。２番目のコンポーネントもまた、ビデオコンポーネントであって（０ｘ０２，Ｖｉｄｅｏ）、３Ｄ右映像としての役割を果たすことを示し（＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ＝３Ｄ  ｖｉｄｅｏ  ｒｉｇｈｔ  ｖｉｅｗ）、０ｘ０２のコンポーネントＩＤを有することができる。
【０３１８】
２つのサービスコンポーネントは、一つの３Ｄビデオをなすサービスコンポーネントであって、互いに関連があるので、同じコンポーネントグループにグループ化することができる。このコンポーネントグループは、０ｘ０１の識別子を有することができ、この内容が各ｃｏｍｐｏｎｅｎｔＩｎｆｏ．エレメントでシグナリングされ得る。２番目のコンポーネントが１番目のコンポーネントに対して従属性（ｄｅｐｅｎｄｅｎｃｙｕ）がある場合、２番目のコンポーネントの＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤは０ｘ０１の値を有することで、１番目のコンポーネントのコンポーネントＩＤを示すことができる。
【０３１９】
図示された実施例（ｔ２６０２０）において、特定のビデオコンポーネントに対する、他のコンポーネント上のフォローサブジェクトメタデータ（ｆｏｌｌｏｗ−ｓｕｂｊｅｃｔ  ｍｅｔａｄａｔａ）がシグナリングされ得る。１番目のコンポーネントは、ビデオコンポーネントであって、プライマリビデオの役割を果たすことをシグナリングすることができる。２番目のコンポーネントは、１番目のコンポーネントに対するフォローサブジェクトメタデータの役割を果たすコンポーネントであり得る。この役割をシグナリングすることができ、＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤは、１番目のコンポーネントのコンポーネントＩＤを示すことができる。また、関連するコンポーネントとして、１番目／２番目のコンポーネントは、同じコンポーネントグループに含まれ得る（０ｘ０１）。
【０３２０】
図示された実施例（ｔ２６０３０）において、一つのベースビデオコンポーネント及び２つのエンハンスドビデオコンポーネントがシグナリングされている。一つのエンハンスドビデオがベースビデオに対して従属性を有し、他のエンハンスドビデオが１番目のエンハンスドビデオに対して従属性を有する場合、図示のように、＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤフィールドを用いてこの関係がシグナリングされ得る。また、それぞれのビデオコンポーネントが同じシーンを構成できるところ、同じコンポーネントグループに含まれ得る。
【０３２１】
図示された実施例（ｔ２６０４０）において、２つのサービスコンポーネントに対する３Ｄコンポーネントとしての役割及びスケーラブルコーディングの面での役割がシグナリングされている。これらのコンポーネントは同じシーンを構成できるところ、同じコンポーネントグループに含まれ得る。
【０３２２】
１番目のサービスコンポーネント（ＩＤ＝０ｘ０１）は、ベースビデオコンポーネントであると同時に、３Ｄサービスの右映像としての役割を果たすことができる。１番目のサービスコンポーネントに対して２つのＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントが記述することができる。それぞれのエレメントは、同じサービスコンポーネントＩＤを有することができる（ＩＤ＝０ｘ０１）。
【０３２３】
２番目のサービスコンポーネント（ＩＤ＝０ｘ０２）は、エンハンスドビデオコンポーネントであると同時に、３Ｄサービスの左映像としての役割を果たすことができる。同様に、２つのＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントが２番目のサービスコンポーネントを記述することができる。これらのエレメントは、同じサービスコンポーネントＩＤを有することができる（ＩＤ＝０ｘ０２）。また、２番目のサービスコンポーネントは、１番目のコンポーネントに対して従属性を有することができる。＠ｄｅｐｅｎｄｅｎｔＣｏｍｐｏｎｅｎｔＩＤが１番目のサービスコンポーネントのＩＤを示すことができる。
【０３２４】
図２４は、本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報を示した図である。
【０３２５】
コンポーネント属性情報は、当該サービス又はサービスコンポーネントの属性に関連する情報を含むことができる。コンポーネント属性情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。
【０３２６】
コンポーネント属性情報は、実施例によって、ビューコンフィギュレーション情報と呼ぶこともできる。実施例によって、コンポーネント属性情報は、ビデオコンポーネントに対するビューコンフィギュレーション情報を意味してもよい。ここで、当該コンポーネントは、ビデオコンポーネントであって、マルチビューの一部であり得る。ビデオコンポーネントがビデオアレイの一部である場合、ビューコンフィギュレーション情報の＠ｒｏｌｅ属性は、当該コンポーネントが＜ｎ，ｍ＞アレイの＜ｘ，ｙ＞番目のビデオコンポーネントであることを示すことができる。
【０３２７】
図示された実施例（ｔ２７０１０）において、コンポーネント属性情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがコンポーネント属性情報に関連するコンポーネント属性スキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｖｉｅｗ−ｃｏｎｆ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、コンポーネント属性スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。これらの値は、パラメータと呼ぶことができ、それぞれ‘，’によって区分することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３２８】
図示された実施例（ｔ２７０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。Ｖｉｅｗ＿ｘ及び／又はＶｉｅｗ＿ｙは、画面の左側上端（ｌｅｆｔ−ｔｏｐ）を基準として当該ビデオコンポーネントの映像の原点を示すことができる。それぞれのフィールドは、映像の原点のｘ座標及びｙ座標を示すことができる。Ｖｉｅｗ＿ｗｉｄｔｈ及び／又はＶｉｅｗ＿ｈｅｉｇｈｔは、当該ビデオコンポーネントの映像の幅（ｗｉｄｔｈ）及び／又は高さ（ｈｅｉｇｈｔ）を示すことができる。Ｖｉｅｗ＿ｔｏｔａｌ＿ｗｉｄｔｈ及び／又はＶｉｅｗ＿ｔｏｔａｌ＿ｈｅｉｇｈｔは、画面の左側上端（ｌｅｆｔ−ｔｏｐ）を基準としてビデオアレイがディスプレイされる領域全体の幅（ｗｉｄｔｈ）及び／又は高さ（ｈｅｉｇｈｔ）を示すことができる。Ｖｉｅｗ＿ｄｉｓｐｌａｙ＿ｐｒｉｏｒｉｔｙは、当該ビデオコンポーネントの映像の優先順位を示すことができる。優先順位とは、当該映像がディスプレイされる際の優先順位であり得る。映像が重なる場合において、優先順位が高いほど他の映像よりも前にディスプレイされ得る。すなわち、他の映像を重なる部分だけ覆うことができる。本フィールドの値が小さいほど優先順位は高いものと見なすことができる。値が０である場合、画面上で最も前にディスプレイされ得る。Ｓｏｕｒｃｅ＿ｉｄは、当該ビデオコンポーネントのソースに対する識別子であってもよい。同時にディスプレイされるマルチビュー（ビデオアレイ）が複数のビデオコンポーネントに分けられて伝達される場合、各ビデオコンポーネントのソースＩＤは同一であってもよい。
【０３２９】
実施例によって、このコンポーネント属性情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するコンポーネント属性エレメントの形態で定義されてもよい。
【０３３０】
図示された実施例（ｔ２７０３０）において、コンポーネント属性情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。
【０３３１】
ｖｉｅｗ＿ｘ、ｖｉｅｗ＿ｙ、ｖｉｅｗ＿ｗｉｄｔｈ、ｖｉｅｗ＿ｈｅｉｇｈｔ、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、ｓｏｕｒｃｅ＿ｉｄ及び／又はｖｉｅｗ＿ｐｒｉｏｒｉｔｙは、前述した定義と同一であってもよい。ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、及びｖｉｅｗ＿ｐｒｉｏｒｉｔｙは、それぞれｖｉｅｗ＿ｔｏｔａｌ＿ｗｉｄｔｈ、ｖｉｅｗ＿ｔｏｔａｌ＿ｈｅｉｇｈｔ、及びｖｉｅｗ＿ｄｉｓｐｌａｙ＿ｐｒｉｏｒｉｔｙと同一であってもよい。
【０３３２】
ｓｏｕｒｃｅ＿ｉｄ＿ｆｌａｇは、ｓｏｕｒｃｅ＿ｉｄの存否を示すことができる。ｖｉｅｗ＿ｔｏｔａｌ＿ｉｎｆｏ＿ｆｌａｇフィールドは、同時に表示されるマルチビューがディスプレイされる領域に対する情報が含まれるかを示すことができる。このフィールドに応じて、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔが存在し得る。ｖｉｅｗ＿ｐｒｉｏｒｉｔｙ＿ｆｌａｇフィールドは、当該ビデオコンポーネントの映像の優先順位情報が含まれるか否かを示すことができる。このフィールドに応じて、ｖｉｅｗ＿ｐｒｉｏｒｉｔｙが存在し得る。
【０３３３】
図２５は、本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報を示した図である。
【０３３４】
コンポーネント属性情報は、当該サービス又はサービスコンポーネントの属性に関連する情報を含むことができる。コンポーネント属性情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。
【０３３５】
コンポーネント属性情報は、実施例によって、ビューポジションコンフィギュレーション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報と呼ぶこともできる。実施例によって、コンポーネント属性情報は、ビデオコンポーネントに対するビューポジションコンフィギュレーション情報を意味してもよい。ここで、当該コンポーネントはビデオコンポーネントであって、ステレオスコピック３Ｄサービスの一部であり得る。
【０３３６】
図示された実施例（ｄ２５０１０）において、コンポーネント属性情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがコンポーネント属性情報に関連するコンポーネント属性スキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｖｉｅｗ−ｐｏｓｉｔｉｏｎ−ｃｏｎｆ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、コンポーネント属性スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。これらの値は、パラメータと呼ぶことができ、それぞれ‘，’によって区分することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３３７】
図示された実施例（ｄ２５０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ｒｉｇｈｔ＿ｖｉｅｗ＿ｆｌａｇフィールドは、当該ビデオコンポーネント（ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）が右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるか、または左側視点（ｌｅｆｔ  ｖｉｅｗ）であるかを知らせることができる。ビデオコンポーネントが左側視点である場合は０の値、右側視点である場合は１の値を有する。ステレオスコピック（Ｓｔｅｒｅｏｓｃｏｐｉｃ）３Ｄサービスを構成するそれぞれの左側／右側視点のビデオコンポーネント（ｌｅｆｔ／ｒｉｇｈｔ  ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）が分けられて伝達される場合、各ビデオコンポーネントに対するビューポジションコンフィギュレーション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報は、前記のコンポーネント属性情報（ｃｏｍｐｏｎｅｎｔ  ｐｒｏｐｅｒｔｙ  ｅｌｅｍｅｎｔ）を用いてｄ２５０４０のようにシグナリングされ得る。各左側／右側視点のビデオコンポーネント（ｌｅｆｔ／ｒｉｇｈｔ  ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）は、一つのシーン（ｓｃｅｎｅ）を構成するので、同一のコンポーネントグループＩＤ（ｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩｄ）値を有することができる。
【０３３８】
コンポーネント属性情報は、実施例によって、ビューポジションコンフィギュレーション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ２  ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報と呼ぶこともできる。実施例によって、コンポーネント属性情報は、ビデオコンポーネントに対するビューポジションコンフィギュレーション情報を意味してもよい。ここで、当該コンポーネントはビデオコンポーネントであって、マルチビューサービスの一部であり得る。
【０３３９】
図示された実施例（ｄ２５０１０）において、コンポーネント属性情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがコンポーネント属性情報に関連するコンポーネント属性スキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｖｉｅｗ−ｐｏｓｉｔｉｏｎ２−ｃｏｎｆ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、コンポーネント属性スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。これらの値は、パラメータと呼ぶことができ、それぞれ‘，’によって区分することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３４０】
図示された実施例（ｄ２５０３０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。視点位置情報（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎフィールド）は、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）サービスにおいて当該ビデオコンポーネント（ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）のビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報を意味してもよい。視点位置情報（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎフィールド）は、マルチビューのうち最も左側に位置した１番目の視点に対して０に設定されてもよい。また、視点位置情報は、１番目の視点から次の視点に左側から右側に移動する度に１ずつ増加する値に設定されてもよい。ここで、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）は、３Ｄマルチビュー（Ｍｕｌｔｉｖｉｅｗ）又はパノラマ（ｐａｎｏｒａｍａ）のためのマルチビュー（Ｍｕｌｔｉｖｉｅｗ）であってもよい。ここで、３Ｄマルチビューである場合、前述したビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報は、各視点（ｖｉｅｗ）に対する左側視点（ｌｅｆｔ  ｖｉｅｗ）又は右側視点（ｒｉｇｈｔ  ｖｉｅｗ）の意味を含むことができる。すなわち、数字で表現されるビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報から、当該コンポーネントに含まれた視点（ｖｉｅｗ）が３Ｄサービスを提供するための左側視点（ｌｅｆｔ  ｖｉｅｗ）であるか又は右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるかを確認することができる。マルチビューサービスを構成するそれぞれの視点（ｖｉｅｗ）に該当するビデオコンポーネントが分けられて伝達される場合、各ビデオコンポーネントに対するビューポジションコンフィギュレーション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ２  ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報は、前記のコンポーネント属性情報（ｃｏｍｐｏｎｅｎｔ  ｐｒｏｐｅｒｔｙ  ｅｌｅｍｅｎｔ）を用いてｄ２５０４０のようにシグナリングされ得る。マルチビューのうち１つのシーン（ｓｃｅｎｅ）を構成するビデオコンポーネントは、同一のコンポーネントグループＩＤ（ｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩｄ）値を有することができる。また、その他のシーン（ｓｃｅｎｅ）を構成するビデオコンポーネントは、異なるコンポーネントグループＩＤ（ｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩＤ）値を有することができる。
【０３４１】
図２６は、本発明の一実施例に係るコンポーネント属性（Ｃｏｍｐｏｎｅｎｔ  Ｐｒｏｐｅｒｔｙ）情報の活用を示した図である。
【０３４２】
図示された実施例（ｔ２８０１０）において、一つの画面が２つのビデオコンポーネントに分けられて伝達され得る。この場合、各ビデオコンポーネントに対するビューコンフィギュレーション情報は、前述したように、ｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメントを用いてシグナリングされ得る。これらは一つのシーンを構成するので、同一のｃｏｍｐｏｎｅｎｔＧｒｏｕｐＩｄ値を有することができる。各コンポーネントに対するＣｏｍｐｏｎｅｎｔＩｎｆｏエレメントのｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメントは、前述したビューコンフィギュレーション情報を有することができる。
【０３４３】
両方ともｕｒｎ：ａｔｓｃ３．０：ｖｉｅｗ−ｃｏｎｆ：２０１ｘのスキームＩＤを有し、＠ｖａｌｕｅは、それぞれ“１９２０，０，１９２０，２１６０，３８４０，２１６０”、“０，０，１９２０，２１６０，３８４０，２１６０”を有することができる。この＠ｖａｌｕｅのパラメータは、順に、前述したパラメータの定義による意味を有することができる。
【０３４４】
図示された実施例（ｔ２８０２０）において、一つのメインビデオを提供するビデオコンポーネントと共に、別途の手話（ｓｉｇｎ  ｌａｎｇｕａｇｅ）を含むビデオコンポーネントが伝達され得る。この場合、手話ビデオコンポーネントは、当該手話映像が、メインビデオがディスプレイされる領域のどの位置にディスプレイされるかに関する情報を提供することができる。この情報は、前述したビューコンフィギュレーション情報の形態でシグナリングされ得る。
【０３４５】
同様に、ＰＩＰ（Ｐｉｃｔｕｒｅ  ｉｎ  Ｐｉｃｔｕｒｅ）の場合にも、手話の場合と同様の方法でビューコンフィギュレーション情報が提供され得る。ここで、手話映像又はＰＩＰ映像の場合、メインビデオよりも前にディスプレイされなければならないため、メインビデオよりも高い優先順位を有することができる。このコンポーネントは、同一のコンポーネントグループに含まれ得、手話コンポーネント又はＰＩＰコンポーネントは、＠ｔａｒｇｅｔＤｅｖｉｃｅ属性が“プライマリスクリーンのインセット”を示すことができる。
【０３４６】
手話コンポーネント又はＰＩＰコンポーネントのビューコンフィギュレーション情報は、ｕｒｎ：ａｔｓｃ３．０：ｖｉｅｗ−ｃｏｎｆ：２０１ｘのスキームＩＤを有し、＠ｖａｌｕｅは“１２００，５０，１０２４，７６８，３８４０，２１６０，０”を有することができる。この＠ｖａｌｕｅのパラメータは、順に、前述したパラメータの定義による意味を有することができる。
【０３４７】
前述したケイパビリティ情報もまたシグナリングされ得る。ケイパビリティ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。ケイパビリティ情報もまた、それによるケイパビリティスキームＩＤが定義され、その値（ｖａｌｕｅ）が定義され得る。また、＠ｖａｌｕｅの各パラメータをサブフィールドとして有するケイパビリティエレメントの形態で定義されてもよい。ケイパビリティ情報は、ディスクリプタの形態で定義され、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。ケイパビリティ情報の詳細なフィールド、パラメータ、及び構造についての内容は、既に前述した。
【０３４８】
図２７は、本発明の一実施例に係るＨＥＶＣビデオコンポーネントディスクリプション情報を示した図である。
【０３４９】
ＨＥＶＣビデオコンポーネントディスクリプション情報は、当該サービス又はサービスコンポーネントのＨＥＶＣビデオに関連する情報を含むことができる。ＨＥＶＣビデオコンポーネントディスクリプション情報は、ＨＥＶＣビデオ情報と呼ぶこともできる。ＨＥＶＣビデオ情報は、コンポーネント関連エンコーディングパラメータ、或いは当該コンポーネントをレンダリングするためのパラメータなどを含むことができる。ＨＥＶＣビデオ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。
【０３５０】
図示された実施例（ｔ２９０１０）において、ＨＥＶＣビデオ情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがＨＥＶＣビデオ情報に関連するＨＥＶＣビデオスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｈｅｖｃ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、ＨＥＶＣビデオ情報スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３５１】
図示された実施例（ｔ２９０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。
【０３５２】
ｐｒｏｆｉｌｅ＿ｓｐａｃｅは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセット（ｔｅｍｐｏｒａｌ  ｖｉｄｅｏ  ｓｕｂｓｅｔ）またはＨＥＶＣテンポラルビデオサブ−ビットストリーム（ｔｅｍｐｏｒａｌ  ｖｉｄｅｏ  ｓｕｂ−ｂｉｔｓｔｒｅａｍ）である場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅの値と同一であってもよい。
【０３５３】
ｔｉｅｒ＿ｆｌａｇは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｔｉｅｒ＿ｆｌａｇの値と同一であってもよい。
【０３５４】
ｐｒｏｆｉｌｅ＿ｉｄｃは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｉｄｃの値と同一であってもよい。
【０３５５】
ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｉｎｄｉｃａｔｉｏｎは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ［ｉ］の値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ［ｉ］の値と同一であってもよい。
【０３５６】
ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇの値と同一であってもよい。
【０３５７】
ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇの値と同一であってもよい。
【０３５８】
ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値と同一であってもよい。
【０３５９】
ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値と同一であってもよい。
【０３６０】
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓの値と同一であってもよい。
【０３６１】
ｌｅｖｅｌ＿ｉｄｃは、ＨＥＶＣビデオストリームに対しては、ビットストリームのＳＰＳに含まれたｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃの値と同一であってもよい。ＨＥＶＣテンポラルビデオサブセットまたはＨＥＶＣテンポラルビデオサブ−ビットストリームである場合、ビットストリームのＳＰＳに含まれたｓｕｂ＿ｌａｙｅｒ＿ｌｅｖｅｌ＿ｉｄｃの値と同一であってもよい。
【０３６２】
ＨＥＶＣ＿ｓｔｉｌｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ＨＥＶＣビデオストリームまたはＨＥＶＣハイエストテンポラルサブ−レイヤリプレゼンテーション（ｈｉｇｈｅｓｔ  ｔｅｍｐｏｒａｌ  ｓｕｂ−ｌａｙｅｒ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）がＨＥＶＣスティルピクチャーズ（ｓｔｉｌｌ  ｐｉｃｔｕｒｅｓ）を含むか否かを示すことができる。
【０３６３】
ＨＥＶＣ＿２４ｈｒ＿ｐｉｃｔｕｒｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ＨＥＶＣビデオストリームまたはＨＥＶＣハイエストテンポラルサブ−レイヤリプレゼンテーション（ｈｉｇｈｅｓｔ  ｔｅｍｐｏｒａｌ  ｓｕｂ−ｌａｙｅｒ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）がＨＥＶＣ２４アワーズピクチャーズ（２４−ｈｏｕｒｓ  ｐｉｃｔｕｒｅｓ）を含むか否かを示すことができる。
【０３６４】
ｔｅｍｐｏｒａｌ＿ｉｄ＿ｍｉｎ及び／又はｔｅｍｐｏｒａｌ＿ｉｄ＿ｍａｘは、ＨＥＶＣビデオストリームに含まれるＨＥＶＣ  ＡＵのうち最も小さいｔｅｍｐｏｒａｌＩｄ値及び／又は最も大きいｔｅｍｐｏｒａｌＩｄ値を示すことができる。
【０３６５】
実施例によって、ＨＥＶＣビデオ情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するＨＥＶＣビデオ情報エレメントの形態で定義されてもよい。
【０３６６】
図示された実施例（ｔ２９０３０）において、ＨＥＶＣビデオ情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。ＭＭＴアセットがＨＥＶＣビデオストリームコンポーネントである場合、ＭＰテーブルのアセットタイプをＨＥＶＣビデオストリームに該当する値を割り当てることができる。
【０３６７】
ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｔｉｅｒ＿ｆｌａｇ、ｐｒｏｆｉｌｅ＿ｉｄｃ、ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｌｅｖｅｌ＿ｉｄｃ、ＨＥＶＣ＿ｓｔｉｌｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ＨＥＶＣ＿２４ｈｒ＿ｐｉｃｔｕｒｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｍｉｎ及び／又はｔｅｍｐｏｒａｌ＿ｉｄ＿ｍａｘが当該ディスクリプタに含まれてもよく、その意味は前述した通りである。
【０３６８】
図２８は、本発明の一実施例に係るＨＥＶＣタイミング＆ＨＲＤ情報を示した図である。
【０３６９】
ＨＥＶＣタイミング＆ＨＲＤ情報は、ＨＥＶＣビデオストリームコンポーネントに関連するタイミング情報乃至ＨＲＤディスクリプションを含むことができる。ＨＥＶＣタイミング＆ＨＲＤ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメントなどで示されてもよい。
【０３７０】
図示された実施例において、ＨＥＶＣタイミング＆ＨＲＤ情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがＨＥＶＣタイミング＆ＨＲＤ情報に関連するスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｈｅｖｃ−ｔｉｍｉｎｇ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、スキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３７１】
図示された実施例（ｔ３００１０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ｈｒｄ＿ｍａｎａｇｅｍｅｎｔ＿ｖａｌｉｄ＿ｆｌａｇは、ＨＥＶＣビデオストリーム又はＨＥＶＣハイエストテンポラルサブ−レイヤリプレゼンテーション内にバッファリングピリオドＳＥＩ（Ｂｕｆｆｅｒｉｎｇ  Ｐｅｒｉｏｄ  ＳＥＩ）及びピクチャタイミングＳＥＩ（Ｐｉｃｔｕｒｅ  Ｔｉｍｉｎｇ  ＳＥＩ）メッセージが存在するか否かを示すことができる。ｐｉｃｔｕｒｅ＿ａｎｄ＿ｔｉｍｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、９０ｋＨｚのシステムクロックとの正確なマッピングのための９０ｋＨｚ＿ｆｌａｇ及びそれと関連するパラメータが当該ディスクリプタに含まれるか否かを示すことができる。９０ｋＨｚ＿ｆｌａｇは、ＨＥＶＣビデオストリームのタイムベースの周波数（ｆｒｅｑｕｅｎｃｙ）が９０ｋＨｚであるか否かを示すことができる。Ｎ及び／又はＫは、タイムスケールに関連するＮ、Ｋパラメータ値を提供することができる。ＨＥＶＣビデオストリーム又はＨＥＶＣハイエストテンポラルサブ−レイヤリプレゼンテーションにおいて、ＨＥＶＣタイムベースの周波数は、ＶＵＩパラメータのｖｕｉ＿ｔｉｍｅ＿ｓｃａｌｅエレメントによって定義され得る。ＨＥＶＣ  ｔｉｍｅ＿ｓｃａｌｅとＳＴＣとの関係はＮ、Ｋパラメータ値によって定義され得、ＨＥＶＣ  ｔｉｍｅ＿ｓｃａｌｅ＝（Ｎ  ｘ  ｓｙｓｔｅｍ＿ｃｌｏｃｋ＿ｆｒｅｑｕｅｎｃｙ）／Ｋのように表現することができる。９０ｋＨｚ＿ｆｌａｇが１である場合、Ｎは１、Ｋは３００の値を有することができる。９０ｋＨｚ＿ｆｌａｇが０である場合、Ｎ、Ｋの値はＮ、Ｋフィールドによって提供され得る。ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋは、ＶＵＩパラメータのｖｕｉ＿ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋフィールドと同様の方式でコーディングすることができ、本フィールドの値は、当該ＨＥＶＣタイミング＆ＨＲＤディスクリプション情報に関連するＨＥＶＣビデオストリーム又はＨＥＶＣハイエストテンポラルサブ−レイヤリプレゼンテーション全体に適用できる。
【０３７２】
実施例によって、ＨＥＶＣタイミング＆ＨＲＤ情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するＨＥＶＣタイミング＆ＨＲＤ情報エレメントの形態で定義されてもよい。
【０３７３】
図示された実施例（ｔ３００２０）において、ＨＥＶＣタイミング＆ＨＲＤ情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。
【０３７４】
ｈｒｄ＿ｍａｎａｇｅｍｅｎｔ＿ｖａｌｉｄ＿ｆｌａｇ、ｐｉｃｔｕｒｅ＿ａｎｄ＿ｔｉｍｉｎｇ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、９０ｋＨｚ＿ｆｌａｇ、Ｎ、Ｋ及び／又はｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｔｉｃｋが当該ディスクリプタに含まれてもよく、その意味は前述した通りである。
【０３７５】
図２９は、本発明の一実施例に係るキャプション（ｃａｐｔｉｏｎ）情報を示した図である。
【０３７６】
キャプション情報は、当該サービスコンポーネントがクローズドキャプションストリームコンポーネントである場合、それに関連するキャプションディスクリプション情報を含むことができる。キャプション情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメントなどで示されてもよい。
【０３７７】
図示された実施例において、キャプション情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがキャプション情報に関連するキャプションスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｃａｐｔｉｏｎ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、キャプションスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３７８】
図示された実施例（ｔ３１０１０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ｃａｐｔｉｏｎ＿ｃｏｄｅｃは、当該キャプションコンポーネントのエンコーディングタイプを示すことができる。実施例によって、“ＣＥＡ−６０８”、“ＣＥＡ−７０８”、“ＳＭＰＴＥ−ＴＴ”などが示されてもよい。ｌａｎｇは、当該キャプションコンポーネントの言語情報を含むことができる。ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｎｕｍｂｅｒは、当該キャプションコンポーネントのタイプがＣＥＡ−７０８である場合、当該キャプションのサービスナンバーを含むことができる。ｅａｓｙ＿ｒｅａｄｅｒ＿ｆｌａｇは、当該キャプションコンポーネントがイージーリーダータイプであるか否かを示すことができる。ａｓｐｅｃｔ＿ｒａｔｉｏは、当該キャプションコンポーネントのディスプレイの縦横比（ｄｉｓｐｌａｙ  ａｓｐｅｃｔ  ｒａｔｉｏ）を示すことができる。実施例によって、“４：３”又は“１６：９”などが示されてもよい。３Ｄ  ｓｕｐｐｏｒｔｅｄは、当該キャプションコンポーネントが３Ｄをサポートするか否かを示すことができる。
【０３７９】
実施例によって、キャプション情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するキャプションエレメントの形態で定義されてもよい。
【０３８０】
図示された実施例（ｔ３１０２０）において、キャプション情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。ＭＭＴアセットがクローズドキャプションコンポーネントである場合、ＭＰテーブルのアセットタイプをクローズドキャプションストリームに該当する値を割り当てることができる。実施例によって、ＭＰテーブルのアセットタイプは、ＨＥＶＣビデオストリームに該当する値を示しながら、アセットディスクリプタとして図示されたディスクリプタが含まれてもよい。この場合、ＨＥＶＣビデオビットストリーム内にクローズドキャプションデータが含まれたことが示されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。
【０３８１】
ｃａｐｔｉｏｎ＿ｌａｎｇ、ｃａｐｔｉｏｎ＿ｃｏｄｅｃ、ｅａｓｙ＿ｒｅａｄｅｒ、ｗｉｄｅ＿ａｓｐｅｃｔ＿ｒａｔｉｏ、３ｄ＿ｓｕｐｐｏｒｔｅｄ及び／又はｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｎｕｍｂｅｒが当該ディスクリプタに含まれてもよく、その意味は、前述した通りである。ｃａｐｔｉｏｎ＿ｌａｎｇ、ｅａｓｙ＿ｒｅａｄｅｒ、ｗｉｄｅ＿ａｓｐｅｃｔ＿ｒａｔｉｏは、それぞれ、前述したｌａｎｇ、ｅａｓｙ＿ｒｅａｄｅｒ＿ｆｌａｇ、ａｓｐｅｃｔ＿ｒａｔｉｏと同一であってもよい。ｃａｐｔｉｏｎ＿ｃｏｄｅｃの場合、その値が０ｘ０１、０ｘ０２、０ｘ０３、０ｘ０４、０ｘ０５であると、それぞれ、“ＣＥＡ−６０８”、“ＣＥＡ−７０８”、“ＳＭＰＴＥ  ｔｉｍｅｄ  ｔｅｘｔ”、“ＥＢＵ−ＴＴ−Ｄ”、“ＣＦＦ−ＴＴ”のエンコーディングタイプが用いられたことを示すことができる。ｕｒｌ＿ｆｌａｇ、ＵＲＬ＿ｌｅｎｇｔｈ、及びＵＲＬ＿ｔｅｘｔフィールドは、前述したキャプション情報でのそれと同一であってもよい。
【０３８２】
例えば、クローズドキャプションコンポーネントがＳＭＰＴＥ−ＴＴをベースとして英語字幕を含む場合、ディスクリプタは、“ｕｒｎ：ａｔｓｃ３．０：ｃａｐｔｉｏｎ：２０１ｘ”のスキームＩＤを有し、＠ｖａｌｕｅは、それぞれ“ＳＭＰＴＥ−ＴＴ，ＥＮＧ，ｆａｌｓｅ，４：３，ｆａｌｓｅ”の値を有することができる。この＠ｖａｌｕｅのパラメータは、順に、前述したパラメータの定義による意味を有することができる。
【０３８３】
また、ＨＥＶＣビデオストリームコンポーネントのビットストリーム内にＣＥＡ−７０８などをベースとしてクローズドキャプションデータが含まれた場合、上述したＨＥＶＣビデオデータ関連情報と共に、クローズドキャプション関連情報が、前述した方法により共にシグナリングされ得る。
【０３８４】
図３０は、本発明の一実施例に係るＨＤＲ情報を示した図である。
【０３８５】
ＨＤＲ情報は、当該サービスコンポーネントがビデオコンポーネントである場合、それに関連するＨＤＲパラメータ情報を含むことができる。ＨＤＲ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメント又はＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎエレメントなどで示されてもよい。
【０３８６】
図示された実施例において、ＨＤＲ情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがＨＤＲ情報に関連するＨＤＲスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｈｄｒ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、ＨＤＲスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３８７】
図示された実施例（ｔ３２０１０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ＯＥＴＦ＿ｔｙｐｅは、当該ビデオデータのソースＯＥＴＦ（ｏｐｔｏ−ｅｌｅｃｔｒｏｎｉｃ  ｔｒａｎｓｆｅｒ  ｆｕｎｃｔｉｏｎ）のタイプを示すことができる。本フィールドの値が１、２、３である場合、それぞれＩＴＵ−Ｒ  ＢＴ．１８８６、ＩＴＵ−Ｒ  ＢＴ．７０９、ＩＴＵ−Ｒ  ＢＴ．２０２０タイプに該当してもよい。他の値は、将来の使用のために残すことができる。
【０３８８】
ｍａｘ＿ｍａｓｔｅｒｉｎｇ＿ｄｉｓｐｌａｙ＿ｌｕｍｉｎａｎｃｅは、当該ビデオデータのマスタリングディスプレイのピークルミナンス（ｐｅａｋ  ｌｕｍｉｎａｎｃｅ）値を示すことができる。この値は、１００〜１０００の間の整数値であってもよい。ｍｉｎ＿ｍａｓｔｅｒｉｎｇ＿ｄｉｓｐｌａｙ＿ｌｕｍｉｎａｎｃｅは、当該ビデオデータのマスタリングディスプレイの最小ルミナンス（ｍｉｎｉｍｕｍ  ｌｕｍｉｎａｎｃｅ）値を示すことができる。この値は、０〜０．１の間の分数（ｆｒａｃｔｉｏｎａｌ  ｎｕｍｂｅｒ）値であってもよい。
【０３８９】
ａｖｅｒａｇｅ＿ｆｒａｍｅ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌは、一つのビデオサンプルに対してはルミナンスレベルの平均値を示すことができる。また、本フィールドは、サンプルグループ又はビデオトラック（ストリーム）に対しては、それに属するサンプルのそれぞれのルミナンスレベルの平均値のうちの最大値を示すことができる。ｍａｘ＿ｆｒａｍｅ＿ｐｉｘｅｌ＿ｌｕｍｉｎａｎｃｅは、一つのビデオサンプルに対しては、ピクセルルミナンス値のうちの最大値を示すことができる。また、本フィールドは、サンプルグループ又はビデオトラック（ストリーム）に対しては、それに属するサンプルのそれぞれのピクセルルミナンスの最大値のうち最も大きい値を示すことができる。
【０３９０】
ｈｄｒ＿ｔｙｐｅ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオデータに対するＨＤＲ情報が変更されて他のタイプのＨＤＲ情報が適用されるか否かを示すフラグであってもよい。例えば、ｏｅｆｔ：３，ｍａｘ＿ｌｕｍ：１００，ｍｉｎ＿ｌｕｍ：０．５，ｍａｘ＿ｆｒａｍｅ＿ｌｕｍ：０，ｍａｘ＿ｐｉｘｅｌ＿ｌｕｍ：０であったＨＤＲパラメータが、ｏｅｆｔ：１，ｍａｘ＿ｌｕｍ：１０００，ｍｉｎ＿ｌｕｍ：０．０５，ｍａｘ＿ｆｒａｍｅ＿ｌｕｍ：０，ｍａｘ＿ｐｉｘｅｌ＿ｌｕｍ：０などに変更されると、本フィールドがｔｒｕｅ値を有することができる。ｈｄｒ＿ｓｄｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオデータがＨＤＲからＳＤＲに切り替わるか否かを示すフラグであってもよい。ｓｄｒ＿ｈｄｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオデータがＳＤＲからＨＤＲに切り替わるか否かを示すフラグであってもよい。ｓｄｒ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇは、当該ビデオデータがＳＤＲデコーダ乃至ＳＤＲディスプレイと互換可能であるか否かを示すフラグであってもよい。
【０３９１】
実施例によって、ＨＤＲ情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するＨＤＲエレメントの形態で定義されてもよい。
【０３９２】
図示された実施例（ｔ３２０２０）において、ＨＤＲ情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。このディスクリプタは、アセットディスクリプタの一つの種類であってもよい。また、このディスクリプタは、ＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。
【０３９３】
ＯＥＴＦ＿ｔｙｐｅ、ｍａｘ＿ｍａｓｔｅｒｉｎｇ＿ｄｉｓｐｌａｙ＿ｌｕｍｉｎａｎｃｅ、ｍｉｎ＿ｍａｓｔｅｒｉｎｇ＿ｄｉｓｐｌａｙ＿ｌｕｍｉｎａｎｃｅ、ａｖｅｒａｇｅ＿ｆｒａｍｅ＿ｌｕｍｉｎａｎｃｅ＿ｌｅｖｅｌ、ｍａｘ＿ｆｒａｍｅ＿ｐｉｘｅｌ＿ｌｕｍｉｎａｎｃｅ、ｈｄｒ＿ｔｙｐｅ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、ｈｄｒ＿ｓｄｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、ｓｄｒ＿ｈｄｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ及び／又はｓｄｒ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇが当該ディスクリプタに含まれてもよく、その意味は、前述した通りである。
【０３９４】
実施例によって、ＨＤＲＴｙｐｅＴｒａｎｓｉｔｉｏｎＦｌａｇ、ＨＤＲＳＤＲＴｒａｎｓｉｔｉｏｎＦｌａｇ、及びＳＤＲＨＤＲＴｒａｎｓｉｔｉｏｎＦｌａｇは、同時に１つ以上がｔｒｕｅとならなくてもよい。例えば、ＨＤＲＳＤＲＴｒａｎｓｉｔｉｏｎＦｌａｇの値がｔｒｕｅである場合、ＨＤＲＴｙｐｅＴｒａｎｓｉｔｉｏｎＦｌａｇ及びＳＤＲＨＤＲＴｒａｎｓｉｔｉｏｎＦｌａｇの値がｆａｌｓｅとなり得る。
【０３９５】
図３１は、本発明の一実施例に係るＷＣＧ情報を示した図である。
【０３９６】
ＷＣＧ情報は、当該サービスコンポーネントがビデオコンポーネントである場合、それに関連するＷＣＧ情報を含むことができる。ＷＣＧ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメント又はＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎエレメントなどで示されてもよい。
【０３９７】
ＷＣＧ情報はカラーガマット（ｃｏｌｏｒ  ｇａｍｕｔ）情報と呼ぶこともできる。カラーガマット情報は、２つの形態があり得、一つはコンテナカラーガマット（ｃｏｎｔａｉｎｅｒ  ｃｏｌｏｒ  ｇａｍｕｔ）であり、他の一つはコンテンツカラーガマット（ｃｏｎｔｅｎｔ  ｃｏｌｏｒ  ｇａｍｕｔ）であり得る。コンテナカラーガマットは、エンコーディング、デコーディングステップ及び／又はデコードされた画素値をマッピングする過程で用いられるカラーガマット関連情報を含むことができる。コンテンツカラーガマットは、オリジナルソース（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ）のカラーガマットに関する情報を含むことができる。すなわち、コンテンツカラーガマットは、実際のコンテンツに適用された有効なカラースペースボリューム（ｃｏｌｏｒ  ｓｐａｃｅ  ｖｏｌｕｍｅ）を示すことができる。
【０３９８】
図示された実施例（ｔ３３０１０）において、コンテンツＷＣＧ情報は、ディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがコンテンツＷＣＧ情報に関連するコンテンツＷＣＧスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｗｃｇ：ｃｏｎｔｅｎｔ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、コンテンツＷＣＧスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０３９９】
図示された実施例（ｔ３３０１０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。
【０４００】
ｃｏｎｔｅｎｔＣｏｌｏｒＧａｍｕｔＴｙｐｅは、当該ビデオデータに対するカラーガマットのタイプを示すことができる。すなわち、このフィールドは、ソースプライマリ（ｐｒｉｍａｒｉｅｓ）のクロマティシティコーディネート（ｃｈｒｏｍａｔｉｃｉｔｙ  ｃｏｏｒｄｉｎａｔｅｓ）を示すことができる。この値は、ＶＵＩ（ｖｉｄｅｏ  ｕｓａｂｉｌｉｔｙ  ｉｎｆｏｒｍａｔｉｏｎ）のカラープライマリ（ｃｏｌｏｕｒ  ｐｒｉｍａｒｉｅｓ）値と同一であってもよい。ＶＵＩパラメータの値が存在しない場合、ＶＵＩのカラープライマリ値は特定されず（ｕｎｓｐｅｃｉｆｉｅｄ）、以下の８個のパラメータが値（ｖａｌｕｅ）を有することができる。
【０４０１】
ｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＲｘ及びｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＲｙは、それぞれ当該ビデオソースのＲカラーに対するｘ座標値及びｙ座標値を示すことができる。これは、０と１との間の分数（ｆｒａｃｔｉｏｎａｌ  ｎｕｍｂｅｒ）の形態であってもよい。ｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＧｘ及びｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＧｙは、それぞれ当該ビデオソースのＧカラーに対するｘ座標値及びｙ座標値を示すことができる。これは、０と１との間の分数（ｆｒａｃｔｉｏｎａｌ  ｎｕｍｂｅｒ）の形態であってもよい。ｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＢｘ及びｃｏｎｔｅｎｔＣｏｌｏｒＰｒｉｍａｒｙＢｙは、それぞれ当該ビデオソースのＢカラーに対するｘ座標値及びｙ座標値を示すことができる。これは、０と１との間の分数（ｆｒａｃｔｉｏｎａｌ  ｎｕｍｂｅｒ）の形態であってもよい。ｃｏｎｔｅｎｔＷｈｉｔｅＰｘ及びｃｏｎｔｅｎｔＷｈｉｔｅＰｙは、それぞれ当該ビデオソースのホワイトポイント（Ｗｈｉｔｅ  ｐｏｉｎｔ）に対するｘ座標値及びｙ座標値を示すことができる。これは、０と１との間の分数（ｆｒａｃｔｉｏｎａｌ  ｎｕｍｂｅｒ）の形態であってもよい。
【０４０２】
ｃｏｎｔｅｎｔＷＣＧＴｒａｎｓｉｔｉｏｎは、当該ビデオデータのコンテンツカラーガマットがＷＣＧ（Ｗｉｄｅ  Ｃｏｌｏｒ  Ｇａｍｕｔ）からＳＣＧ（Ｓｔａｎｄａｒｄ  Ｃｏｌｏｒ  Ｇａｍｕｔ）に切り替わるか否かを示すフラグであってもよい。実施例によって、ＷＣＧをサポートするビデオデータの終わりが当該ビデオコンポーネントに含まれることを示してもよい。ｃｏｎｔｅｎｔＳＣＧＣｏｍｐａｔｉｂｉｌｉｔｙは、当該ＷＣＧビデオのコンテンツカラーガマットがＳＣＧベースのデコーダ及びディスプレイと互換可能であるか否かを示すフラグであってもよい。
【０４０３】
図示された実施例（ｔ３３０２０）において、コンテナＷＣＧ情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがコンテナＷＣＧ情報に関連するコンテナＷＣＧスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｗｃｇ：ｃｏｎｔａｉｎｅｒ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、コンテナＷＣＧスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０４０４】
図示された実施例（ｔ３３０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。このパラメータは、前述したコンテンツカラーガマットに対するパラメータと同一であってもよい。但し、このパラメータは、コンテナカラーガマットについて記述することができる。例えば、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＧａｍｕｔＴｙｐｅは、当該ビデオのコンテナカラーガマットのタイプを示すことができる。すなわち、エンコーディング時に使用した、またはデコーディング時に使用し得るカラープライマリ（ｃｏｌｏｒ  ｐｒｉｍａｒｉｅｓ）に対するクロマティシティコーディネートを示すことができる。
【０４０５】
ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＲｘ、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＲｙ、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＧｘ、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＧｙ、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＢｘ、ｃｏｎｔａｉｎｅｒＣｏｌｏｒＰｒｉｍａｒｙＢｙ、ｃｏｎｔａｉｎｅｒＷｈｉｔｅＰｘ、ｃｏｎｔａｉｎｅｒＷｈｉｔｅＰｙは、それぞれエンコーディング／デコーディング時に使用した／使用し得るカラープライマリ（ｃｏｌｏｒ  ｐｒｉｍａｒｉｅｓ）のＲＧＢカラー及びホワイトポイントのｘ，ｙ座標を示すことができる。すなわち、コンテナのカラーガマットの座標を示すことができる。
【０４０６】
ｃｏｎｔａｉｎｅｒＷＣＧＴｒａｎｓｉｔｉｏｎは、当該ビデオデータのコンテナカラーガマットがＷＣＧからＳＣＧに切り替わるか否かを示すフラグであってもよい。実施例によって、コンテナのＷＣＧをサポートするビデオデータの終わりが当該ビデオコンポーネントに含まれることを示してもよい。ｃｏｎｔａｉｎｅｒＳＣＧＣｏｍｐａｔｉｂｉｌｉｔｙは、当該ＷＣＧビデオのコンテナカラーガマットがＳＣＧベースのデコーダ及びディスプレイと互換可能であるか否かを示すフラグであってもよい。
【０４０７】
実施例によって、コンテンツ／コンテナＷＣＧ情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するコンテンツ／コンテナＷＣＧエレメントの形態で定義されてもよい。
【０４０８】
図示された実施例（ｔ３３０３０）において、コンテンツ／コンテナＷＣＧ情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。ＭＭＴアセットが、ＷＣＧをサポートするコンテンツを含むビデオストリームコンポーネントである場合、アセットディスクリプタとして図示されたディスクリプタが含まれてもよい。また、このディスクリプタは、ＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。
【０４０９】
このディスクリプタ（ｔ３３０３０）は、コンテンツＷＣＧ情報とコンテナＷＣＧ情報を共に含むこともできる。
【０４１０】
ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅは、前述したｃｏｎｔａｉｎｅｒＣｏｌｏｒＧａｍｕｔＴｙｐｅと同一であってもよい。ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオコンポーネントのビデオサンプルに対して、エンコーディング時に使用した／デコーディング時に使用し得るカラープライマリ（ｃｏｌｏｒ  ｐｒｉｍａｒｉｅｓ）に対するクロマティシティコーディネートが他のクロマティシティコーディネートに変更されるか否かを示すフラグであってもよい。ｗｃｇ＿ｓｃｇ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオコンポーネントのビデオサンプルのコンテナカラーガマットがＷＣＧからＳＣＧに切り替わるか否かを示すフラグであってもよい。例えば、ＢＴ．２０２０からＢＴ．７０９にコンテナカラーガマットが変化するか否かを示すことができる。ｓｃｇ＿ｗｃｇ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオコンポーネントのビデオサンプルのコンテナカラーガマットがＳＣＧからＷＣＧに切り替わるか否かを示すフラグであってもよい。ｓｃｇ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇは、当該ビデオコンポーネントのビデオサンプルのコンテナカラーガマットがＳＣＧベースのデコーダ及びディスプレイと互換可能であるか否かを示すフラグであってもよい。すなわち、既存のＳＣＧデコーダ又はディスプレイが使用される場合において、別途のマッピング情報やアップグレードがなくても当該ＷＣＧビデオをクオリティ問題なしに出力可能であるか否かを、このフィールドによって確認することができる。コンテナカラーガマットに関する情報であるため、このフィールドは、ＳＣＧベースのデコーダ／ディスプレイがＢＴ．２０２０のようなカラーガマットを知らなくても当該ビデオデータをデコードすることができるか否かを示すことができる。ｃｏｌｏｒ＿ｐｒｉｍａｒｙ＿ｆｌａｇは、当該ビデオコンポーネントのビデオサンプルのエンコーディング／デコーディング時に使用し得るカラープライマリ（ｃｏｌｏｒ  ｐｒｉｍａｒｉｅｓ）のクロマティシティコーディネートに関する細部情報が存在するか否かを示すフラグであってもよい。ｃｏｌｏｒ＿ｐｒｉｍａｒｙ＿ｆｌａｇの値に応じて、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＲｘフィールド、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＲｙフィールド、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＧｘフィールド、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＧｙフィールド、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＢｘフィールド、ｃｏｌｏｒ＿ｐｒｉｍａｒｙＢｙフィールド、ｃｏｌｏｒ＿ｗｈｉｔｅＰｘフィールド及び／又はｃｏｌｏｒ＿ｗｈｉｔｅＰｙフィールドが含まれ得る。このフィールドは、それぞれエンコーディング／デコーディング時に使用した／使用し得るカラープライマリ（ｃｏｌｏｒ  ｐｒｉｍａｒｉｅｓ）のＲＧＢカラー及びホワイトポイントのｘ，ｙ座標を示すことができる。
【０４１１】
ｃｏｎｔｅｎｔ＿ｗｃｇ＿ｆｌａｇは、当該ビデオコンポーネントに対して、コンテンツカラーガマットに関する細部情報が当該ディスクリプタに含まれたか否かを示すことができる。ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅは、当該ビデオストリームのコンテンツカラーガマットのタイプを示すことができる。すなわち、このフィールドは、当該ビデオデータのオリジナルソースプライマリ（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ  ｐｒｉｍａｒｉｅｓ）に対するクロマティシティコーディネートを示すことができる。ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｓｐａｃｅ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオコンポーネントのビデオデータのオリジナルソースプライマリ（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ  ｐｒｉｍａｒｉｅｓ）に対して、これらのクロマティシティコーディネートが他のクロマティシティコーディネートに変更されるか否かを示すフラグであってもよい。ｃｏｎｔｅｎｔ＿ｗｃｇ＿ｓｃｇ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇは、当該ビデオコンポーネントのビデオデータのコンテンツカラーガマットがＷＣＧからＳＣＧに切り替わるか否かを示すフラグであってもよい。ｃｏｎｔｅｎｔ＿ｓｃｇ＿ｗｃｇ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇフィールドは、当該ビデオコンポーネントのビデオデータのコンテンツカラーガマットがＳＣＧからＷＣＧに切り替わるか否かを示すフラグであってもよい。ｃｏｎｔｅｎｔ＿ｓｃｇ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇフィールドは、当該ビデオコンポーネントのビデオデータのコンテンツカラーガマットがＳＣＧベースのデコーダ及びディスプレイと互換可能であるか否かを示すフラグであってもよい。すなわち、このフィールドの値が１である場合、当該ビデオデータの有効色表現範囲がＳＣＧと互換可能であり、別途のマッピングなどが不要であることを示すことができる。ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙ＿ｆｌａｇフィールドは、当該ビデオコンポーネントのビデオデータのオリジナルソースプライマリ（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ  ｐｒｉｍａｒｉｅｓ）のクロマティシティコーディネートに関する細部情報が存在するか否かを示すフラグであってもよい。ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙ＿ｆｌａｇフィールドの値に応じて、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＲｘフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＲｙフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＧｘフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＧｙフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＢｘフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｐｒｉｍａｒｙＢｙフィールド、ｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｗｈｉｔｅＰｘフィールド及び／又はｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｗｈｉｔｅＰｙフィールドが含まれ得る。このフィールドは、それぞれオリジナルソースプライマリ（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ  ｐｒｉｍａｒｉｅｓ）のＲＧＢカラー及びホワイトポイントのｘ，ｙ座標を示すことができる。
【０４１２】
実施例によって、前述したｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅ及び／又はｃｏｎｔｅｎｔ＿ｃｏｌｏｒ＿ｇａｍｕｔ＿ｔｙｐｅは、次のような意味を有することができる。
【０４１３】
０：ｒｅｓｅｒｖｅｄ／１：Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．７０９−５，Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．１３６１  ｃｏｎｖｅｎｔｉｏｎａｌ  ｃｏｌｏｕｒ  ｇａｍｕｔ  ｓｙｓｔｅｍ  ａｎｄ  ｅｘｔｅｎｄｅｄ  ｃｏｌｏｕｒ  ｇａｍｕｔ  ｓｙｓｔｅｍ，ＩＥＣ  ６１９６６−２−１（ｓＲＧＢ  ｏｒ  ｓＹＣＣ），ＩＥＣ  ６１９６６−２−４，Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ  ＲＰ  １７７（１９９３）／２：ｕｎｓｐｅｃｉｆｉｅｄ／３：Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ／４：Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．４７０−６  Ｓｙｓｔｅｍ  Ｍ（ｈｉｓｔｏｒｉｃａｌ），Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ  Ｎａｔｉｏｎａｌ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅｅ  １９５３  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  ｆｏｒ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｓｔａｎｄａｒｄｓ  ｆｏｒ  ｃｏｌｏｕｒ  ｔｅｌｅｖｉｓｉｏｎ，Ｕｎｉｔｅｄ  Ｓｔａｔｅｓ  Ｆｅｄｅｒａｌ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｃｏｍｍｉｓｓｉｏｎ  Ｔｉｔｌｅ  ４７  Ｃｏｄｅ  ｏｆ  Ｆｅｄｅｒａｌ  Ｒｅｇｕｌａｔｉｏｎｓ（２００３）  ７３．６８２（ａ）／５：Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．４７０−６  Ｓｙｓｔｅｍ  Ｂ，Ｇ（ｈｉｓｔｏｒｉｃａｌ），Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．６０１−６  ６２５，Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．１３５８  ６２５，Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．１７００  ６２５  ＰＡＬ  ａｎｄ  ６２５  ＳＥＣＡＭ／６：Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．６０１−６  ５２５，Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．１３５８  ５２５，Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．１７００  ＮＴＳＣ，Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ  １７０Ｍ（２００４）／７：Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ  ２４０Ｍ（１９９９）／８：Ｇｅｎｅｒｉｃ  ｆｉｌｍ（ｃｏｌｏｕｒ  ｆｉｌｔｅｒｓ  ｕｓｉｎｇ  Ｉｌｌｕｍｉｎａｎｔ  Ｃ）／９：Ｒｅｃ．ＩＴＵ−Ｒ  ＢＴ．２０２０／１０−２５５：Ｒｅｓｅｒｖｅｄ  ｆｏｒ  ｆｕｔｕｒｅ  ｕｓｅ
【０４１４】
図３２は、本発明の一実施例に係るＨＦＲ情報／プルダウン（Ｐｕｌｌ  Ｄｏｗｎ）情報を示した図である。
【０４１５】
ＨＦＲ情報は、当該ビデオサービスコンポーネントがＨＦＲをサポートする場合、それに関連するＨＦＲ情報を含むことができる。ＨＦＲ情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメント又はＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎエレメントなどで示されてもよい。前述したように、ＨＦＲ情報はＭＰＤなどにも含まれてもよい。
【０４１６】
図示された実施例（ｔ３４０１０）において、ＨＦＲ情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがＨＦＲ情報に関連するＨＦＲスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｈｆｒ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、ＨＦＲスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０４１７】
図示された実施例（ｔ３４０１０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ＳＦＲＣｏｍｐａｔｉｂｉｌｉｔｙは、当該ビデオコンポーネントがＳＦＲ（Ｓｔａｎｄａｒｄ  Ｆｒａｍｅ  Ｒａｔｅ）又はレガシーフレームレートと互換されるか否かを示すことができる。ＳＦＲ＿ＨＦＲ＿Ｔｒａｎｓｉｔｉｏｎは、当該ビデオコンポーネントが一般のフレームレート（ＳＦＲ又はレガシーフレームレート）からＨＦＲへのトランジション（ｔｒａｎｓｉｔｉｏｎ）を含むか否かを示すことができる。ＨＦＲ＿ＳＦＲ＿Ｔｒａｎｓｉｔｉｏｎは、当該ビデオコンポーネントがＨＦＲから一般のフレームレート（ＳＦＲ又はレガシーフレームレート）へのトランジション（ｔｒａｎｓｉｔｉｏｎ）を含むか否かを示すことができる。
【０４１８】
プルダウン情報は、当該サービスコンポーネントに対するプルダウンリカバリーコンフィギュレーション（Ｐｕｌｌ  Ｄｏｗｎ  Ｒｅｃｏｖｅｒｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を含むことができる。プルダウン情報は、前述した実施例に係るディスクリプタのうち１つの形態を有してもよく、エレメントの形態を有してもよい。これは、前述したｃｏｍｐｏｎｅｎｔＰｒｏｐｅｒｔｙエレメント又はＣｏｍｐｏｎｅｎｔＤｅｓｃｒｉｐｔｉｏｎエレメントなどで示されてもよい。
【０４１９】
プルダウンリカバリーコンフィギュレーションについて説明する。例えば、オリジナルソースがフィルムモード（例えば、２４ｐ）である場合、これは、エンコーディングのために他のフレームレートに変更され得る（例えば、６０ｉ）。この場合、ダーティーフレーム（ｄｉｒｔｙ  ｆｒａｍｅｓ）が発生し得る。ダーティーフレームは、次のような方式により生成され得る。
【０４２０】
全てのオリジナルフィルムフレームは、２つのフィールドで構成されていると見なすことができる。一方は、イメージの奇数番目のラインのためであり、他方は、イメージの偶数番目のラインのためであり得る。したがって、４個のフィルムフレーム毎に８個のフィールドがあり得る。ここで、４個のフィルムフレームをそれぞれＡ、Ｂ、Ｃ及びＤと呼ぶことができる。この８個のフィールドは、１０個のフィールドにストレッチ（ｓｔｒｅｔｃｈｅｄ）され得る。これは、２つのフィールドを繰り返すことによって（トップ、ボトム）行われてもよい。
【０４２１】
Ａフレームは、３つのフィールドにわたって（ａｃｒｏｓｓ）いてもよく（Ａｔ，Ａｂ，Ａｂ）、Ｂフレームは、２つのフィールドにわたっていてもよく（Ｂｔ，Ｂｂ）、Ｃフレームは、３つのフィールドにわたっていてもよく（Ｃｔ，Ｃｔ，Ｃｂ）、Ｄフレームは、２つのフィールドにわたっていてもよい（Ｄｔ，Ｄｂ）。これらは、Ａｔ−Ａｂ−Ａｂ−Ｂｔ−Ｂｂ−Ｃｔ−Ｃｔ−Ｃｂ−Ｄｔ−Ｄｂ、３−２−３−２プルダウン、または簡単に３−２プルダウンと表してもよい。ここで、Ａｔは、Ａフレームのトップフィールドという意味であり、Ｂｂは、Ｂフレームのボトムフィールドという意味であり得る。
【０４２２】
“Ａｔ−Ａｂ−Ａｂ−Ｂｔ−Ｂｂ−Ｃｔ−Ｃｔ−Ｃｂ−Ｄｔ−Ｄｂ”のケースにおいて、Ａｂ−Ｂｔフレーム及びＢｂ−Ｃｔフレームはダーティーフレームと呼ぶことができる。しかし、受信機は、オリジナルフレームレートはプルダウンリカバリーコンフィギュレーションを介して知ることができる。受信機は、オリジナルフレームレートストリームをエンコード／伝送されたフレームレートストリームから復旧することができる。ここで、復旧は、ダーティーフレームを除去する過程であり得る。
【０４２３】
プルダウンは、フィルムメイキング／ＴＶプロダクションなどにおいて、フィルム又はビデオの伝達のためのポストプロダクションプロセスと関連して使用される用語であり得る。フィルムフレームレートは、ブロードキャスタによって放送フレームレートに切り替わってもよい。しかし、システムレベルのフレームレート関連情報は放送フレームレート情報のみを含むことができる。したがって、オリジナルフレームレートを復旧するために、システムレベルシグナリングは、オリジナルフレームレートに関連する情報をシグナリングできなければならない。例えば、オリジナルフレームレート（例えば、２４ｐ）情報及び／又はプルダウンタイプ情報（例えば、３：２プルダウン）がシグナリング情報に含まれ得る。また、プルダウンされたビデオのビデオレベル情報は、オリジナルビデオへの復旧を要求することができる。
【０４２４】
図示された実施例（ｔ３４０２０）において、プルダウン情報はディスクリプタの形態で定義できる。＠ｓｃｈｅｍｅＩｄＵｒｉは、当該ディスクリプタがプルダウン情報に関連するプルダウンスキームを有することを識別するためのＵＲＩであってもよい。この場合、＠ｓｃｈｅｍｅＩｄＵｒｉは、ｕｒｎ：ａｔｓｃ３．０：ｐｕｌｌｄｏｗｎ：２０１ｘの値を有することができる。＠ｖａｌｕｅは、プルダウンスキームに応じてその意味が定義される値（ｖａｌｕｅ）を有することができる。この値については後述する。＠ｉｄは、当該ディスクリプタの識別子を示すことができる。同一の識別子を有する場合、同一のスキームＩＤ、値（ｖａｌｕｅ）、及びパラメータを含むことができる。
【０４２５】
図示された実施例（ｔ３４０２０）は、前述した＠ｖａｌｕｅの各パラメータを示すことができる。ＰｕｌｌＤｏｗｎＴｙｐｅは、当該エンコードされたビデオストリームに適用されたプルダウンのタイプを示すことができる。負数ではなく１０進数の整数で表現することができる。本フィールドは、その値に応じて、０−ｒｅｓｅｒｖｅｄ、１−２：２  ｐｕｌｌ−ｄｏｗｎ、２−２：３  ｐｕｌｌ  ｄｏｗｎ、３−３：２  ｐｕｌｌ−ｄｏｗｎ、４−４：４  ｐｕｌｌ−ｄｏｗｎ、５−５：５  ｐｕｌｌ−ｄｏｗｎ、６−６：４  ｐｕｌｌ−ｄｏｗｎ、...、などのタイプを示すことができる。
【０４２６】
ＰｕｌｌＤｏｗｎＴｒａｎｓｉｔｉｏｎは、プルダウンされたデータからオリジナルフレームレートへのトランジションが当該ビデオコンポーネントに含まれるか否かを示すことができる。実施例によって、本フィールドは、プルダウンされたデータの終わりが当該ビデオコンポーネントに含まれるか否かを示してもよい。
【０４２７】
ＯｒｉｇｉｎａｌＦｒａｍｅＲａｔｅは、当該ビデオデータのオリジナルフレームレート（キャプチャード（ｃａｐｔｕｒｅｄ）フレームレート）を示すことができる。本フィールドは、負数ではなく１０進数の整数で表現することができる。この情報は、エンコーディングフレームレートからオリジナルフレームレートに復旧を行うために提供されてもよい。本フィールドは、その値に応じて、０−ｒｅｓｅｒｖｅｄ、１−１２０、２−１２０／１．００１、３−１００、４−６０、５−６０／１．００１、６−５０、７−３０、８−３０／１．００１、９−２５、１０−２４、１１−２４／１．００１、１２〜１４−ｒｅｓｅｒｖｅｄなどのオリジナルフレームレートを示すことができる。
【０４２８】
ＯｒｉｇｉｎａｌＳｃａｎＴｙｐｅは、当該ビデオに該当するオリジナルビデオのスキャニングタイプを示すことができる。本フィールドは、負数ではなく１０進数の整数で表現することができる。本フィールドは、その値に応じて、０−ｒｅｓｅｒｖｅｄ、１−ｉｎｔｅｒｌａｃｅｄ、２−ｐｒｏｇｒｅｓｓｉｖｅ、３−ｕｎｓｐｅｃｉｆｉｅｄなどのタイプを示すことができる。
【０４２９】
実施例によって、プルダウン情報は、前述した＠ｖａｌｕｅの各パラメータをサブフィールドとして有するプルダウンエレメントの形態で定義されてもよい。
【０４３０】
図示された実施例（ｔ３４０３０）において、ＨＦＲ情報＆プルダウン情報はディスクリプタの形態で定義できる。このディスクリプタは、前述したように、ＭＭＴシグナリング情報に含まれて伝達されてもよい。このディスクリプタは、前述したＭＰＴメッセージ又は他のＭＭＴＰメッセージに含まれて伝達されてもよい。ＭＭＴアセットが、ＨＦＲをサポートするコンテンツを含むビデオストリームコンポーネントである場合、アセットディスクリプタとして図示されたディスクリプタが含まれてもよい。また、このディスクリプタは、ＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。
【０４３１】
このディスクリプタ（ｔ３４０３０）は、ＨＦＲ情報＆プルダウン情報を共に含むこともできる。ｓｆｒ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ、ｓｆｒ＿ｈｆｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、ｈｆｒ＿ｓｆｒ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、ｐｕｌｌ＿ｄｏｗｎ＿ｔｙｐｅ、ｐｕｌｌ＿ｄｏｗｎ＿ｔｒａｎｓｉｔｉｏｎ＿ｆｌａｇ、ｏｒｉｇｉｎａｌ＿ｆｒａｍｅｒａｔｅ及び／又はｏｒｉｇｉｎａｌ＿ｓｃａｎ＿ｔｙｐｅは、それぞれ、前述したＳＦＲＣｏｍｐａｔｉｂｉｌｉｔｙ、ＳＦＲ＿ＨＦＲ＿Ｔｒａｎｓｉｔｉｏｎ、ＨＦＲ＿ＳＦＲ＿Ｔｒａｎｓｉｔｉｏｎ、ＰｕｌｌＤｏｗｎＴｙｐｅ、ＰｕｌｌＤｏｗｎＴｒａｎｓｉｔｉｏｎ、ＯｒｉｇｉｎａｌＦｒａｍｅＲａｔｅ、ＯｒｉｇｉｎａｌＳｃａｎＴｙｐｅと同一であってもよい。ｏｒｉｇｉｎａｌ＿ｆｒａｍｅｒａｔｅ＿ｆｌａｇは、当該ディスクリプタにｏｒｉｇｉｎａｌ＿ｆｒａｍｅｒａｔｅフィールドが存在するか否かを示すことができる。ｏｒｉｇｉｎａｌ＿ｓｃａｎｅ＿ｔｙｐｅ＿ｆｌａｇは、当該ディスクリプタにｏｒｉｇｉｎａｌ＿ｓｃａｎｅ＿ｔｙｐｅフィールドが存在するか否かを示すことができる。
【０４３２】
図３３は、本発明の一実施例に係る３Ｄサービス及びマルチビューサービス関連シグナリング情報を示す。ＭＭＴアセットが、ステレオスコピック（ｓｔｅｒｅｏｓｃｏｐｉｃ）３Ｄサービスのためのビデオストリームコンポーネント（ｖｉｄｅｏ  ｓｔｒｅａｍ  ｃｏｍｐｏｎｅｎｔ）である場合、ＭＰ＿ｔａｂｌｅ内のａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒとしてビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）ｄ３３０１０を含むことができる。ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）は、ステレオスコピック３Ｄパラメータ情報などを含むことができる。これは、ＭＭＴの他のシグナリングテーブル或いはＤＶＢのＳＩ（ＳＤＴ又はＥＩＴ）などに含まれてもよい。ビューポジションディスクリプタは、次のフィールドのうち少なくとも１つを含むことができる。ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）に対する識別子であってもよい。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）の長さを示すことができる。ｒｉｇｈｔ＿ｖｉｅｗ＿ｆｌａｇフィールドは、当該ビデオストリーム（ｖｉｄｅｏ  ｓｔｒｅａｍ）のコンポーネント（ｃｏｍｐｏｎｅｎｔ）が右側視点（ｒｉｇｈｔ  ｖｉｅｗ）コンポーネントであるか否かを示すことができる。フィールドの値が０である場合、当該ビデオストリーム（ｖｉｄｅｏ  ｓｔｒｅａｍ）のコンポーネント（ｃｏｍｐｏｎｅｎｔ）が左側視点（ｌｅｆｔ  ｖｉｅｗ）コンポーネントであることを示し、フィールドの値が１である場合、右側視点（ｒｉｇｈｔ  ｖｉｅｗ）コンポーネントであることを示すことができる。
【０４３３】
ＭＭＴアセットが、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）サービスのためのビデオストリームコンポーネント（ｖｉｄｅｏ  ｓｔｒｅａｍ  ｃｏｍｐｏｎｅｎｔ）である場合、ＭＰ＿ｔａｂｌｅ内のａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒとしてビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）ｄ３３０２０を含むことができる。ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）は、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）パラメータ情報などを含むことができる。ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）は、コンポーネント間の依存性（ｄｅｐｅｎｄｅｎｃｙ）情報も含んでいる。これは、ＭＭＴの他のシグナリングテーブル或いはＤＶＢのＳＩ（ＳＤＴ又はＥＩＴ）などに含まれてもよい。ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）は、次のフィールドのうち少なくとも１つを含むことができる。ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）に対する識別子であってもよい。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、当該ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）の長さを示すことができる。ｎｕｍ＿ｏｆ＿ｖｉｅｗｓフィールドは、当該ビューポジションディスクリプタ（ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ２＿ｄｅｓｃｒｉｐｔｏｒ）に含まれたビュー（ｖｉｅｗ）の総数を意味してもよい。すなわち、マルチビューサービスで提供する視点（ｖｉｅｗ）の総数を示すことができる。ｖｉｅｗ＿ｐｏｓｉｔｉｏｎフィールドは、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）である場合、当該ビデオコンポーネント（ｖｉｄｅｏ  ｃｏｍｐｏｎｅｎｔ）のビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報を意味し得る。ここで、視点位置情報は、マルチビューのうち最も左側に位置した１番目の視点に対して０に設定されてもよい。また、視点位置情報は、１番目の視点から次の視点に左側から右側に移動する度に１ずつ増加する値に設定されてもよい。（The view position means the order for the left-most view being equal to 0 and the value of the order increasing by 1 for next view from left to right.）ここで、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）は、３Ｄマルチビュー（Ｍｕｌｔｉｖｉｅｗ）やパノラマ（ｐａｎｏｒａｍａ）のためのマルチビュー（Ｍｕｌｔｉｖｉｅｗ）であってもよい。ここで、３Ｄマルチビューである場合、前述したビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報は、各視点（ｖｉｅｗ）に対する左側視点（ｌｅｆｔ  ｖｉｅｗ）又は右側視点（ｒｉｇｈｔ  ｖｉｅｗ）の意味を含むことができる。すなわち、数字で表現されるビューポジション（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）情報から、当該コンポーネントに含まれた視点（ｖｉｅｗ）が３Ｄサービスを提供するための左側視点（ｌｅｆｔ  ｖｉｅｗ）であるか、または右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるかを確認することができる。
【０４３４】
図３４は、本発明の一実施例に係る、ＨＤＲ情報処理能力に基づいた受信機のメディアエンジンの動作を示した図である。
【０４３５】
受信機のパーサー（ＩＳＯＢＭＦＦパーサー）は、ＩＳＯＢＭＦＦベースのメディアファイル、ＤＡＳＨセグメント及び／又はＭＭＴ  ＭＰＵなどをパーシングすることができる。パーシングの結果によって、ビデオサンプルはビデオデコーダに伝達され、ＨＤＲ情報（メタデータ）はメタデータパーサーに伝達され得る。
【０４３６】
ビデオデコーダは、ビデオサンプルをデコードしてＨＤＲビデオデータを取得することができる。この過程で取得したＨＤＲ情報がある場合、これをメタデータパーサーに伝達することができる。ＤＡＳＨ／ＭＭＴなどのシグナリングメッセージが受信されると、シグナリングプロセッサは、これらからＨＤＲメタデータを抽出してメタデータパーサーに伝達することができる。メタデータパーサーは、受信したＨＤＲメタデータをパーシングすることができる。ここで取得したメタデータを用いて、ビデオデコーダに必要なコントロール情報などがビデオデコーダに伝達され得る。メタデータパーサーは、バッファ又はメタデータアップデートの役割を果たすこともできる。アップデートは、ｓｅｔ＿ｎｕｍｂｅｒ、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒなどを用いて行われてもよい。
【０４３７】
受信機がＨＤＲディスプレイが可能であるか否かによって、場合の数が分けられる。ＨＤＲビデオのディスプレイが不可能な場合、ＨＤＲビデオデータは、ＨＤＲ−ＳＤＲコンバージョンを経てＳＤＲディスプレイブロックに伝達され得る。ＳＤＲディスプレイブロックは、ハードウェアブロックであって、コンバージョンされたＳＤＲビデオを受信して再生することができる。このとき、コンバージョンには、メタデータパーサーから伝達された情報が使用され得る。
【０４３８】
受信機がＨＤＲディスプレイが可能な場合、ＨＤＲビデオに対してクオリティエンハンスメントが行われ得る。このとき、メタデータパーサーから伝達された共通の（ｃｏｍｍｏｎ）ＨＤＲ情報（Ｄｙｎａｍｉｃ  ｒａｎｇｅ，ｔｒａｎｓｆｅｒ  ｆｕｎｃｔｉｏｎ，ｃｏｌｏｒ  ｇａｍｕｔ，ｃｏｌｏｒ  ｔｅｍｐｅｒａｔｕｒｅ，ＤＲ／ＣＧ  ｍａｐｐｉｎｇ，Ｖｉｅｗｉｎｇ  ｃｏｎｄｉｔｉｏｎなど）を用いてクオリティエンハンスメントを行うことができる。
【０４３９】
受信機がシーン／フレーム（ｓｃｅｎｅ／ｆｒａｍｅ）別メタデータを処理できるか否かによって、場合の数が分けられる。シーン／フレーム別メタデータを処理できない場合、受信機のＨＤＲディスプレイブロックは、受信したＨＤＲビデオデータを再生することができる。
【０４４０】
シーン／フレーム別メタデータを処理できる場合、シーン別ＨＤＲビデオクオリティエンハンスメント（Ｓｃｅｎｅ−ｂｙ−Ｓｃｅｎｅ  ＨＤＲ  ｖｉｄｅｏ  ｑｕａｌｉｔｙ  ｅｎｈａｎｃｅｍｅｎｔ）が行われ得る。このとき、メタデータパーサーから伝達されたシーン／フレームＨＤＲメタデータ（Ｗｈｉｔｅ  ｌｅｖｅｌｓ，Ｂｌａｃｋ  ｌｅｖｅｌｓ，ｆｒａｍｅ−ｂｙ−ｆｒａｍｅ，ＤＲ／ＣＧ  ｍａｐｐｉｎｇなど）を用いてクオリティエンハンスメントを行うことができる。この場合、受信機のＨＤＲディスプレイブロックは、エンハンスされたＨＤＲビデオデータを再生することができる。ＨＤＲディスプレイブロックは、ハードウェアブロックであってもよい。
【０４４１】
タイミングコンバータは、メタデータパーサー、シンクロナイザなどにタイム関連情報を伝達することができる。シンクロナイザは、ｓｙｎｃ＿ｓｔａｒｔ、ｓｙｎｃ＿ｄｕｒａｔｉｏｎなどの情報を活用して、シーン別ＨＤＲビデオクオリティエンハンスメント動作に必要な情報を提供することができる。
【０４４２】
図３５は、本発明の一実施例に係る、ＷＣＧ情報処理能力に基づいた受信機のメディアエンジンの動作を示した図である。
【０４４３】
受信機のパーサー（ＩＳＯＢＭＦＦパーサー）は、ＩＳＯＢＭＦＦベースのメディアファイル、ＤＡＳＨセグメント及び／又はＭＭＴ  ＭＰＵなどをパーシングすることができる。パーシングの結果によって、ＷＣＧビデオサンプルはビデオデコーダに伝達され、カラーガマット（ｃｏｌｏｒ  ｇａｍｕｔ）情報（メタデータ）はメタデータパーサーに伝達され得る。
【０４４４】
ビデオデコーダは、ビデオサンプルをデコードしてＷＣＧビデオデータを取得することができる。この過程で取得したカラーガマット関連情報がある場合、これをメタデータパーサーに伝達することができる。ＤＡＳＨ／ＭＭＴなどのシグナリングメッセージが受信されると、シグナリングプロセッサは、これらからカラーガマットメタデータを抽出してメタデータパーサーに伝達することができる。メタデータパーサーは、受信したカラーガマットメタデータをパーシングすることができる。ここで取得したコンテナ／コンテンツカラーガマット情報は受信機の処理過程で活用することができる。メタデータパーサーは、バッファ又はメタデータアップデートの役割を果たすこともできる。アップデートは、ｓｅｔ＿ｎｕｍｂｅｒ、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒなどを用いて行われてもよい。
【０４４５】
受信したデータに対して、コンテンツカラーガマット情報が含まれているか否かによって、場合の数が分けられる。コンテンツカラーガマット情報が含まれていない場合、受信機は、ディスプレイカラーガマットがコンテナカラーガマットよりも大きいか又は同一であるかを判断することができる。ディスプレイカラーガマットがコンテナカラーガマットよりも大きいか又は同一である場合、受信機は、完全な（ｆｕｌｌ）ＷＣＧディスプレイを提供することができる。ディスプレイカラーガマットがコンテナカラーガマットよりも小さい場合、受信機は、コンテナカラーガマットからディスプレイカラーガマットにガマット（ｇａｍｕｔ）マッピングを行うことができる。その後、受信機は、ＳＣＧディスプレイ又はパーシャル（ｐａｒｔｉａｌ）ＷＣＧディスプレイを提供することができる。この過程で、メタデータパーサーから伝達された共通の（ｃｏｍｍｏｎ）コンテナカラーガマット関連情報を活用することができる。
【０４４６】
反対に、受信したデータに対して、コンテンツカラーガマット情報が含まれている場合、受信機は、ディスプレイカラーガマットがコンテンツカラーガマットよりも大きいか又は同一であるかを判断することができる。ディスプレイカラーガマットがコンテンツカラーガマットよりも大きいか又は同一である場合、受信機は、完全な（ｆｕｌｌ）ＷＣＧディスプレイを提供することができる。ディスプレイカラーガマットがコンテンツカラーガマットよりも小さい場合、受信機は、コンテンツカラーガマットからディスプレイカラーガマットにガマット（ｇａｍｕｔ）マッピングを行うことができる。その後、受信機は、ＳＣＧディスプレイ又はパーシャル（ｐａｒｔｉａｌ）ＷＣＧディスプレイを提供することができる。この過程で、メタデータパーサーから伝達された共通の（ｃｏｍｍｏｎ）コンテンツカラーガマット関連情報を活用することができる。
【０４４７】
図３６は、本発明の一実施例に係る、ＨＦＲ情報処理能力に基づいた受信機のメディアエンジンの動作を示した図である。
【０４４８】
受信機のパーサー（ＩＳＯＢＭＦＦパーサー）は、ＩＳＯＢＭＦＦベースのメディアファイル、ＤＡＳＨセグメント及び／又はＭＭＴ  ＭＰＵなどをパーシングすることができる。パーシングの結果によって、ＨＦＲビデオデータが取得され得る。
【０４４９】
ＤＡＳＨ  ＭＰＤ又はＭＭＴベースのシグナリングメッセージが受信されると、シグナリングプロセッサは、これらからＨＦＲメタデータを抽出してメタデータパーサーに伝達することができる。メタデータパーサーは、受信したＨＦＲメタデータをパーシングすることができる。ここで取得したＨＦＲ情報は受信機の処理過程で活用することができる。メタデータパーサーは、バッファ又はメタデータアップデートの役割を果たすこともできる。アップデートは、ｓｅｔ＿ｎｕｍｂｅｒ、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒなどを用いて行われてもよい。
【０４５０】
ＨＦＲビデオデータに対して、ＨＦＲデコーディング／ディスプレイを行うことができる場合、ＨＦＲビデオデータはビデオデコーダに伝達され得る。ＨＦＲビデオデコーダはビデオサンプルをデコードすることができる。このとき、ＨＦＲメタデータが取得されると、これをメタデータパーサーに伝達することもできる。ＨＦＲビデオデコーダは、デコードしたデータをＨＦＲディスプレイに伝達し、ＨＦＲディスプレイはこれをディスプレイすることができる。
【０４５１】
ＨＦＲデコーディング／ディスプレイを行うことができない場合、ＳＦＲとの互換性を確認することができる。ＳＦＲＣｏｍｐａｔｉｂｉｌｉｔｙが１の値を有する場合、互換性があるものであり、フレームレートの変換を行うことができる。変換後のデータは、ＳＦＲ又はレガシービデオデコーダに伝達され得る。この過程で、メタデータパーサーからＨＦＲメタデータを受信して活用することができる。ビデオデコーディング過程でＨＦＲメタデータが取得される場合、これをメタデータパーサーに伝達することもできる。ビデオデコーダは、これをレガシーディスプレイに伝達することができる。このビデオデータは、オリジナルフレームレートに変換されたビデオデータであってもよい。レガシーディスプレイはこれをディスプレイすることができる。
【０４５２】
図３７は、本発明の一実施例に係る、プルダウンリカバリー情報処理能力に基づいた受信機のメディアエンジンの動作を示した図である。
【０４５３】
受信機のパーサー（ＩＳＯＢＭＦＦパーサー）は、ＩＳＯＢＭＦＦベースのメディアファイル、ＤＡＳＨセグメント及び／又はＭＭＴ  ＭＰＵなどをパーシングすることができる。パーシングの結果によって、ビデオサンプルはビデオデコーダに伝達されてデコードされ得る。
【０４５４】
ＤＡＳＨ  ＭＰＤ又はＭＭＴベースのシグナリングメッセージが受信されると、シグナリングプロセッサは、これらからプルダウンリカバリー関連メタデータを抽出してメタデータパーサーに伝達することができる。メタデータパーサーは、受信したプルダウンリカバリー関連メタデータをパーシングすることができる。ここで取得したプルダウンリカバリー関連情報を受信機の処理過程で活用することができる。メタデータパーサーは、バッファ又はメタデータアップデートの役割を果たすこともできる。アップデートは、ｓｅｔ＿ｎｕｍｂｅｒ、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒなどを用いて行われてもよい。
【０４５５】
受信機は、ＰｕｌｌＤｏｗｎＦｌａｇを確認して、デコードされたビデオがプルダウンされたビデオであるか否かを確認することができる。受信機は、プルダウンされたビデオである場合、オリジナルＦＲストリームを、プルダウンされたタイプなどの情報を用いて復旧することができる。この過程で、メタデータパーサーのプルダウンリカバリー関連情報を活用することができる。プルダウンされたビデオではない場合、このような過程を経ない。リカバーされたソースＦＲビデオ又はデコードされたビデオデータは、ディスプレイに伝達されてディスプレイされ得る。
【０４５６】
図３８は、本発明の一実施例に係る３Ｄサービスをサポートするためのメタデータを示す。本発明の一実施例によれば、ビデオデータは、３Ｄサービスをサポートするためのメタデータを含むＳＥＩメッセージを含むことができる。本発明において、３Ｄサービスをサポートするコンテンツを構成するリファレンスビュービデオ（ｒｅｆｅｒｅｎｃｅ  ｖｉｅｗ  ｖｉｄｅｏ）及アディショナルビュービデオ（ａｄｄｉｔｉｏｎａｌ  ｖｉｅｗ  ｖｉｄｅｏ）のためのコンプレッションフォーマットは、ＨＤ又はＵＨＤであってもよい。画面比率と関連して、リファレンスビュービデオ及アディショナルビュービデオは、アクティブ領域（ａｃｔｉｖｅ  ａｒｅａ）に対して同じ画面比率（ａｓｐｅｃｔ  ｒａｔｉｏ）を有することができる。もし、３Ｄサービスを構成する左側イメージ（Ｌｅｆｔ  ｐｉｃｔｕｒｅ）と右側イメージ（ｒｉｇｈｔ  ｐｉｃｔｕｒｅ）の画面比率が正確に同一ではない場合、さらに小さい入力イメージは、レターボックス（ｌｅｔｔｅｒｂｏｘｅｄ）又はピラーボックス（ｐｉｌｌａｒ  ｂｏｘｅｄ）され得る。ここで、レターボックス（ｌｅｔｔｅｒｂｏｘｅｄ）とは、対象イメージの上下に黒色バー（ｂｌａｃｋ  ｂａｒｓ）などを位置させて画面比率を調整することを意味し得る。また、ピラーボックス（ｐｉｌｌａｒ  ｂｏｘｅｄ）とは、対象イメージの左右に黒色バー（ｂｌａｃｋ  ｂａｒｓ）などを位置させて画面比率を調整することを意味し得る。このような動作は、コンプレッションの前に行うことができ、２つのビューがアクティブ領域で同一の画面比率を有するようにすることができる。また、前述したイメージに内蔵された（ｅｍｂｅｄｄｅｄ）バー（ｂａｒｓ）の存在は、アクティブフォーマットディスクリプタ（Ａｃｔｉｖｅ  Ｆｏｒｍａｔ  Ｄｅｓｃｒｉｐｔｉｏｎ、ＡＦＤ）によって示されてもよい。また、バー（ｂａｒｓ）の存在は、選択的には、バーデータ情報（Ｂａｒ  Ｄａｔａ  ｉｎｆｏｒｍａｔｉｏｎ）によって示されてもよい。フレームレート（Ｆｒａｍｅ  ｒａｔｅ）と関連して、アディショナルビュービデオのフレームレートは、リファレンスビュービデオのフレームレートを１又はそれ以上の整数で割った値であってもよい。
【０４５７】
図中の上段に示された実施例（ｄ３８０１０）は、マルチビュービューポジション（ｍｕｌｔｉｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージを示すことができる。当該ＳＥＩメッセージは、ビデオデータに含まれて共に伝送されてもよい。当該ＳＥＩメッセージは、ＳＨＶＣ（Ｓｃａｌａｂｌｅ  ＨＥＶＣ、Ｓｃａｌａｂｌｅ  Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）によって運搬されるステレオスコピックビデオの左側視点及び右側視点（ｌｅｆｔ  ｖｉｅｗ  ａｎｄ  ｒｉｇｈｔ  ｖｉｅｗ）を示すことができる。
【０４５８】
マルチビュービューポジション（ｍｕｌｔｉｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージは、１８０の値を有するペイロードタイプ（ｐａｙｌｏａｄＴｙｐｅ）情報によって識別され得る。図示のように、マルチビュービューポジション（ｍｕｌｔｉｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージは、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１フィールド及びｖｉｅｗ＿ｐｏｓｉｔｉｏｎ［ｉ］情報を含むことができる。ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１フィールドは、マルチビューサービスに含まれたビューの個数を示すことができる。実施例によって、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１フィールドは、マルチビューサービスに含まれたビューの個数よりも１だけ少ない数を示してもよい。マルチビュービューポジション（ｍｕｌｔｉｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージは、各ビュー（ｖｉｅｗ）に対するｖｉｅｗ＿ｐｏｓｉｔｉｏｎ［ｉ］情報を含むことができる。フィクスドアンドモバイル（ｆｉｘｅｄ  ＆  ｍｏｂｉｌｅ）ハイブリッド３Ｄサービスのために、ＳＥＩメッセージ内のｖｉｅｗ＿ｐｏｓｉｔｉｏｎ［ｉ］情報は、ｉと同一のディペンデンシーＩＤ（ＤｅｐｅｎｄｅｎｃｙＩｄ）を有するビューの順序を示すことができる。このようなビューは、ディスプレイのための、左側から右側への順序に従うビューのうちの一つであってもよい。ここで、ビューの順序は、最も左側に位置したビューを０とし、それから右側に１つずつ移動するにつれて１ずつ増加する順序の値を意味し得る。例えば、ベースレイヤビデオが右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であり、エンハンスメントレイヤビデオが左側視点（ｌｅｆｔ  ｖｉｅｗ）であるとき、ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ［０］は１であり、ｖｉｅｗ＿ｐｏｓｉｔｉｏｎ［１］は０であってもよい。すなわち、ディペンデンシーＩＤ  １を有するエンハンスメントレイヤビデオが左側視点であるため、エンハンスメントレイヤビデオのビューポジション情報は０に設定され得る。また、ディペンデンシーＩＤ  ０を有するベースレイヤビデオが右側視点であるため、ベースレイヤビデオのビューポジション情報は１に設定され得る。
【０４５９】
図中の下段に示された実施例（ｄ３８０２０）は、マルチビューシーンポジション（ｍｕｌｔｉｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージを示すことができる。当該ＳＥＩメッセージは、ビデオデータに含まれて共に伝送されてもよい。当該ＳＥＩメッセージは、ｍｉｎ＿ｄｉｓｐａｒｉｔｙ情報及び／又はｍａｘ＿ｄｉｓｐａｒｉｔｙ＿ｒａｎｇｅ情報を含むことができる。マルチビューシーンポジション（ｍｕｌｔｉｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージは、ペイロードタイプ（ｐａｙｌｏａｄＴｙｐｅ）情報によって識別され得る。マルチビューシーンポジション（ｍｕｌｔｉｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージは、イメージを３Ｄディスプレイにレンダリングするに先立って、デコードされたビュー（ｖｉｅｗｓ）をプロセッシングするために使用され得る。最小両眼視差（ｍｉｎｉｍｕｍ  ｄｉｓｐａｒｉｔｙ）は、ビデオ内で最前方に位置するオブジェクト（ｆｒｏｎｔ−ｍｏｓｔ  ｏｂｊｅｃｔ）の３次元位置（ロケーション）を示すことができる。ＯＳＤ（ｏｎ−ｓｃｒｅｅｎ  ｄｉｓｐｌａｙ）のように受信機が生成する（ｒｅｃｅｉｖｅｒ−ｇｅｎｅｒａｔｅｄ）グラフィックを、前記デコードされたビュー（ｖｉｅｗｓ）よりも前方にレンダリングするために、最小両眼視差（ｍｉｎｉｍｕｍ  ｄｉｓｐａｒｉｔｙ）は、
【０４６０】
マルチビューシーンポジション（ｍｕｌｔｉｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージ内に含まれ得る。すなわち、受信機は、ビデオデータ内のＳＥＩメッセージのうちマルチビューシーンポジション（ｍｕｌｔｉｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージに含まれた最小両眼視差（ｍｉｎｉｍｕｍ  ｄｉｓｐａｒｉｔｙ）情報を用いて、当該ビデオデータがディスプレイされる位置よりも前方に、受信機が生成するグラフィック情報をディスプレイすることができる。前述した実施例において、各ＳＥＩメッセージは、ディペンデンシーＩＤをさらに含むことができる。
【０４６１】
図３９は、本発明の一実施例に係るバー（ｂａｒ）に関するメタデータを示すことができる。バー（ｂａｒ）に関する情報は、ビデオデータ内にＳＥＩメッセージとして含まれて伝送されてもよい。バー（ｂａｒ）に関する情報は、別途のテーブル又はディスクリプタとしてＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。バー（ｂａｒ）に関する情報は、次の情報のうち少なくとも１つを含むことができる。ｔｏｐ＿ｂａｒ＿ｆｌａｇフィールドは、ディスプレイされる画面の上側にバー（ｂａｒ）が存在するか否かを示すことができる。ｂｏｔｔｏｍ＿ｂａｒ＿ｆｌａｇフィールドは、ディスプレイされる画面の下側にバーが存在するか否かを示すことができる。ｌｅｆｔ＿ｂａｒ＿ｆｌａｇフィールドは、ディスプレイされる画面の左側にバーが存在するか否かを示すことができる。ｒｉｇｈｔ＿ｂａｒ＿ｆｌａｇフィールドは、ディスプレイされる画面の右側にバーが存在するか否かを示すことができる。ｔｏｐ＿ｂａｒ＿ｆｌａｇフィールドが１に設定される場合、すなわち、画面の上側にバーが存在する場合、ｍａｒｋｅｒ＿ｂｉｔｓフィールド及びｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドがバー（ｂａｒ）に関するメタデータに含まれ得る。ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドは、上側バー（ｔｏｐ  ｂａｒ）の最後のラインナンバー（ｌｉｎｅ  ｎｕｍｂｅｒ）を定義することができる。すなわち、上側バーは、画面の上端からｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドによって定義されるライン（ｌｉｎｅ）までの大きさを有することができる。ｂｏｔｔｏｍ＿ｂａｒ＿ｆｌａｇフィールドが１に設定される場合、すなわち、画面の下側にバーが存在する場合、ｍａｒｋｅｒ＿ｂｉｔｓフィールド及びｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドがバー（ｂａｒ）に関するメタデータに含まれ得る。ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドは、下側バー（ｂｏｔｔｏｍ  ｂａｒ）の開始ラインナンバー（ｌｉｎｅ  ｎｕｍｂｅｒ）を定義することができる。すなわち、下側バーは、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドによって定義されるライン（ｌｉｎｅ）から画面の下端までの大きさを有することができる。ｌｅｆｔ＿ｂａｒ＿ｆｌａｇフィールドが１に設定される場合、すなわち、画面の左側にバーが存在する場合、ｍａｒｋｅｒ＿ｂｉｔｓフィールド及びｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドがバー（ｂａｒ）に関するメタデータに含まれ得る。ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドは、左側バー（ｌｅｆｔ  ｂａｒ）の最後のピクセルナンバー（ｐｉｘｅｌ  ｎｕｍｂｅｒ）を定義することができる。すなわち、左側バーは、画面の左側端からｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドによって定義されるピクセルまでの大きさを有することができる。ｒｉｇｈｔ＿ｂａｒ＿ｆｌａｇフィールドが１に設定される場合、すなわち、画���の右側にバーが存在する場合、ｍａｒｋｅｒ＿ｂｉｔｓフィールド及びｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドがバー（ｂａｒ）に関するメタデータに含まれ得る。ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドは、右側バー（ｒｉｇｈｔ  ｂａｒ）の開始ピクセルナンバー（ｐｉｘｅｌ  ｎｕｍｂｅｒ）を定義することができる。すなわち、右側バーは、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドによって定義されるピクセルから画面の右側端までの大きさを有することができる。追加的に、ａｄｄｉｔｉｏｎａｌ＿ｂａｒ＿ｄａｔａがさらに含まれてもよい。前述したフィールドを用いて、バー（ｂａｒ）に関する情報は、画面上にディスプレイされるバー（ｂａｒ）の大きさを記述することができる。すなわち、レターボックスバー（ｌｅｔｔｅｒ  ｂｏｘ  ｂａｒｓ）の大きさは、前述したように、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールド及びｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドによって示すことができる。また、ピラーボックスバー（ｐｉｌｌａｒ  ｂｏｘ  ｂａｒｓ）の大きさは、前述したように、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールド及びｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドによって示すことができる。しかし、このようなフィールドは、オリジナルソースフォーマット（ｏｒｉｇｉｎａｌ  ｓｏｕｒｃｅ  ｆｏｒｍａｔ）に基づいて作成されたものである。すなわち、当該ビデオコンテンツの製作（ｐｒｏｄｕｃｔｉｏｎ）当時のフォーマットに基づいたライン（ｌｉｎｅ）及びピクセル（ｐｉｘｅｌ）値であるため、受信状況に応じてその値の意味が異なり得る。すなわち、送信端で伝送されたビデオフォーマット、または送信端でエンコードされたビデオフォーマットがオリジナルソースフォーマットと異なる場合が発生し得る。これは、伝送のために当該ビデオコンテンツがリサイズされた場合などを例に挙げることができる。このような場合、受信端でのバー（ｂａｒ）に関する情報の解釈が曖昧になり得る。これは、バー（ｂａｒ）に関する情報がオリジナルソースフォーマットに基づいた値である一方、コンテンツは変更されたフォーマットを有するためである。
【０４６２】
図４０は、本発明の一実施例に係るオリジナルソースフォーマットに関するメタデータを示すことができる。オリジナルソースフォーマットに関する情報は、ビデオデータ内にＳＥＩメッセージとして含まれて伝送されてもよい。オリジナルソースフォーマットに関する情報は、別途のテーブル又はディスクリプタとしてＳＤＴ又はＥＩＴなどのＤＶＢ  ＳＩサービスシグナリングに含まれて伝達されてもよく、共に伝達されてもよい。オリジナルソースフォーマットに関する情報は、次の情報のうち少なくとも１つを含むことができる。ｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは、圧縮フォーマット（ｃｏｍｐｒｅｓｓｉｏｎ  ｆｏｒｍａｔ）と製作フォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）が同一であるか否かを示すことができる。圧縮フォーマットと製作フォーマットが同一である場合に１として、異なる場合に０としてシグナリング（ｓｉｇｎａｌｉｎｇ）されてもよい。ここで、製作フォーマットは、オリジナルソースフォーマットを意味し得る。ｏｒｇ＿ｓｐａｔｉａｌ＿ｒｅｓｏｌｕｔｉｏｎフィールドは、作製（ｐｒｏｄｕｃｔｉｏｎ）端で撮影された実際の空間解像度（ｓｐａｔｉａｌ  ｒｅｓｏｌｕｔｉｏｎ）をシグナリングすることができる。例えば、各フィールド値による解像度は、次の通りである。０ｘ０：ｕｎｓｐｅｃｉｆｉｅｄ；０ｘ１：３８４０ｘ２１６０；０ｘ２：２１６０ｘ１４４０；０ｘ３：１９２０ｘ１０８０；０ｘ４：１２８０ｘ７２０；０ｘ５：９６０ｘ５４０；０ｘ６：６４０ｘ３６０；０ｘ７：ｃｕｓｔｏｍｉｚｅｄ．
【０４６３】
ｏｒｇ＿ｆｒａｍｅ＿ｒａｔｅフィールドは、製作（ｐｒｏｄｕｃｔｉｏｎ）端で撮影された実際のフレームレート（ｆｒａｍｅ  ｒａｔｅ）をシグナリングすることができる。例えば、各フィールド値によるフレームレートは、次の通りである。０ｘ０：ｒｅｓｅｒｖｅｄ；０ｘ１＝２３．９７６Ｈｚ、０ｘ２＝２４Ｈｚ、０ｘ３＝２９．９７Ｈｚ、０ｘ４＝３０Ｈｚ、０ｘ５＝５９．９４Ｈｚ、０ｘ６＝６０Ｈｚ、０ｘ７＝２５Ｈｚ、０ｘ０８＝５０Ｈｚ、０ｘ０９＝１００Ｈｚ、０ｘ０Ａ＝１２０／１．００１Ｈｚ、０ｘ０Ｂ＝１２０Ｈｚ．
【０４６４】
ｓｃａｎｎｉｎｇ＿ｆｏｒｍａｔフィールドは、スキャニングフォーマットがｉｎｔｅｒｌａｃｅｄであるか、またはｐｒｏｇｒｅｓｓｉｖｅであるかをシグナリングすることができる。例えば、各フィールド値によるスキャニングフォーマットは、次の通りである。００：ｕｎｓｐｅｃｉｆｉｅｄ、０１：ｐｒｏｇｒｅｓｓｉｖｅ、１０：ｉｎｔｅｒｌａｃｅｄ、１１：ｒｅｓｅｒｖｅｄ．
【０４６５】
ｏｒｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｓｉｚｅ＿ｄｉｖ＿８フィールド及びｏｒｇ＿ｖｅｒｔｉｃａｌ＿ｓｉｚｅ＿ｄｉｖ＿８フィールドは、製作（ｐｒｏｄｕｃｔｉｏｎ）端で撮影された実際の空間解像度（ｓｐａｔｉａｌ  ｒｅｓｏｌｕｔｉｏｎ）において予め定義されたフォーマット（ｐｒｅ−ｄｅｆｉｎｅｄ  ｆｏｒｍａｔ）ではない場合をシグナリングすることができる。すなわち、予め設定された値をシグナリングするものではなく、実際の製作フォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）の横及び縦解像度の値を示す。実際の横及び縦解像度は、各フィールド値に８を乗じた値であってもよい。このように、オリジナルソースフォーマットに関する情報は、原作者の意図（Ａｒｔｉｓｔｉｃ  ｉｎｔｅｎｔ）を反映できる情報として用いることができる。
【０４６６】
図４１は、本発明の一実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてレターボックスを生成する方法を示す。その第一のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）と同じ場合である。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は３８４０＊２１６０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、同一に３８４０＊２１６０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは１に設定され得る。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４１０１０において、ｔｏｐ＿ｂａｒ＿ｆｌａｇフィールド及びｂｏｔｔｏｍ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、上側バー（ｔｏｐ  ｂａｒ）及び下側バー（ｂｏｔｔｏｍ  ｂａｒ）を用いたレターボックスが生成されることを示すことができる。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４１０１０において、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドはＡ値を有し、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドはＢ値を有することができる。この場合、ｄ４１０２０に示したように、上側バーは、Ａ＋１の垂直サイズを有することができる。ここで、上側バーの水平サイズは、プロダクションフォーマットの水平サイズと同一であってもよい。また、下側バーは、Ｖ−Ｂの垂直サイズを有することができる。ここで、Ｖは、プロダクションフォーマットの垂直サイズを示すことができる。すなわち、プロダクションフォーマットが３８４０＊２１６０であるので、Ｖは２１６０の値を有することができ、下側バーは２１６０−Ｂの垂直サイズを有することができる。ここで、下側バーの水平サイズは、エミッションフォーマット又はプロダクションフォーマットの水平サイズと同一であってもよい。このように、プロダクションフォーマットとエミッションフォーマットが同じ場合、放送受信装置は、エミッションフォーマットにｂａｒ＿ｄａｔａに含まれた情報をそのまま適用してレターボックスのサイズを算出し、レターボックスを生成することができる。放送受信装置のディスプレイで生成されたレターボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４６７】
図４２は、本発明の他の実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてレターボックスを生成する方法を示す。本図では、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）と異なる場合について説明できる。第二のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）よりも小さい場合である（ｄ４２０１０）。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は１９２０＊１０８０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、これより大きい３８４０＊２１６０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは０に設定され得る。また、バーに関する情報において、ｔｏｐ＿ｂａｒ＿ｆｌａｇフィールド及びｂｏｔｔｏｍ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、上側バー（ｔｏｐ  ｂａｒ）及び下側バー（ｂｏｔｔｏｍ  ｂａｒ）を用いたレターボックスが生成されることを示すことができる。また、バーに関する情報において、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドはＡ値を有し、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドはＢ値を有することができる。この場合、ｄ４２０１０に示したように、上側バーは、（Ａ＋１）／Ｒの垂直サイズを有することができる。ここで、Ｒは、エミッションフォーマットとプロダクションフォーマットとの比率である。実施例において、プロダクションフォーマット（３８４０＊２１６０）はエミッションフォーマット（１９２０＊１０８０）の２倍のサイズを有するので、Ｒの値は２であり得る。実施例によって、Ｒは、プロダクションフォーマットの垂直サイズであるＶをエミッションフォーマットの垂直サイズで割った値を意味してもよい。この場合にもＲの値は２である。ここで、上側バーの水平サイズは、エミッションフォーマットの水平サイズと同一であってもよい。また、下側バーは、（Ｖ−Ｂ）／Ｒの垂直サイズを有することができる。ここで、Ｖは、プロダクションフォーマットの垂直サイズを示すことができる。すなわち、プロダクションフォーマットが３８４０＊２１６０であるので、Ｖは２１６０の値を有することができ、下側バーは（２１６０−Ｂ）／２の垂直サイズを有することができる。ここで、下側バーの水平サイズは、エミッションフォーマットの水平サイズと同一であってもよい。このように、プロダクションフォーマットがエミッションフォーマットよりも大きい場合、放送受信装置は、ｂａｒ＿ｄａｔａに含まれた情報をプロダクションフォーマットに適用し、プロダクションフォーマットとエミッションフォーマットとの比率によってスケーリングしてバー（ｂａｒ）のサイズを決定し、バーを生成することができる。すなわち、放送受信装置は、バーに関する情報と共に受信されたオリジナルソースフォーマットに関する情報���用いて、エミッションフォーマットでのバーのサイズを確認し、スケーリングを通じたレターボックスの生成を行うことができる。放送受信装置のディスプレイで生成されたレターボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４６８】
第三のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）よりも大きい場合である（ｄ４２０２０）。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は１９２０＊１０８０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、これより小さい１２８０＊７２０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは０に設定され得る。また、バーに関する情報において、ｔｏｐ＿ｂａｒ＿ｆｌａｇフィールド及びｂｏｔｔｏｍ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、上側バー（ｔｏｐ  ｂａｒ）及び下側バー（ｂｏｔｔｏｍ  ｂａｒ）を用いたレターボックスが生成されることを示すことができる。また、バーに関する情報において、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｔｏｐ＿ｂａｒフィールドはＡ値を有し、ｌｉｎｅ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｂｏｔｔｏｍ＿ｂａｒフィールドはＢ値を有することができる。この場合、ｄ４２０２０に示したように、上側バーは、（Ａ＋１）＊Ｆの垂直サイズを有することができる。ここで、Ｆは、エミッションフォーマットとプロダクションフォーマットとの比率である。実施例において、エミッションフォーマット（１９２０＊１０８０）はプロダクションフォーマット（１２８０＊７２０）の１．５倍のサイズを有するので、Ｆの値は１．５であり得る。実施例によって、Ｆは、エミッションフォーマットの垂直サイズをプロダクションフォーマットの垂直サイズであるＶで割った値を意味してもよい。この場合にもＦの値は１．５である。ここで、上側バーの水平サイズは、エミッションフォーマットの水平サイズと同一であってもよい。また、下側バーは、（Ｖ−Ｂ）＊Ｆの垂直サイズを有することができる。ここで、Ｖは、プロダクションフォーマットの垂直サイズを示すことができる。すなわち、プロダクションフォーマットが１２８０＊７２０であるので、Ｖは７２０の値を有することができ、下側バーは（７２０−Ｂ）＊１．５の垂直サイズを有することができる。ここで、下側バーの水平サイズは、エミッションフォーマットの水平サイズと同一であってもよい。このように、プロダクションフォーマットがエミッションフォーマットよりも小さい場合、放送受信装置は、ｂａｒ＿ｄａｔａに含まれた情報をプロダクションフォーマットに適用し、プロダクションフォーマットとエミッションフォーマットとの比率によってスケーリングしてバー（ｂａｒ）のサイズを決定し、バーを生成することができる。すなわち、放送受信装置は、バーに関する情報と共に受信されたオリジナルソースフォーマットに関する情報を用いて、エミッションフォーマットでのバーのサイズを確認し、スケーリングを通じたレターボックスの生成を行うことができる。放送受信装置のディスプレイで生成されたレターボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４６９】
図４３は、本発明の一実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてピラーボックス（ｐｉｌｌａｒｂｏｘ）を生成する方法を示す。その第一のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）と同じ場合である。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は３８４０＊２１６０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、同一に３８４０＊２１６０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは１に設定され得る。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４３０１０において、ｌｅｆｔ＿ｂａｒ＿ｆｌａｇフィールド及びｒｉｇｈｔ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、左側バー（ｌｅｆｔ  ｂａｒ）及び右側バー（ｒｉｇｈｔ  ｂａｒ）を用いたピラーボックスが生成されることを示すことができる。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４３０１０において、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドはＣ値を有し、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドはＤ値を有することができる。この場合、ｄ４３０２０に示したように、左側バーは、Ｃ＋１の水平サイズを有することができる。ここで、左側バーの垂直サイズは、プロダクションフォーマットの垂直サイズと同一であってもよい。また、右側バーは、Ｈ−Ｄの水平サイズを有することができる。ここで、Ｈは、プロダクションフォーマットの水平サイズを示すことができる。すなわち、プロダクションフォーマットが３８４０＊２１６０であるので、Ｈは２１６０の値を有することができ、右側バーは２１６０−Ｄの水平サイズを有することができる。ここで、右側バーの垂直サイズは、エミッションフォーマット又はプロダクションフォーマットの垂直サイズと同一であってもよい。このように、プロダクションフォーマットとエミッションフォーマットが同じ場合、放送受信装置は、エミッションフォーマットにｂａｒ＿ｄａｔａに含まれた情報をそのまま適用してピラーボックスのサイズを算出し、ピラーボックスを生成することができる。放送受信装置のディスプレイで生成されたピラーボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４７０】
図４４は、本発明の他の実施例に係るバーデータ（ｂａｒ  ｄａｔａ）を用いてピラーボックスを生成する方法を示す。本図では、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）と異なる場合について説明できる。第二のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）よりも小さい場合である（ｄ４４０１０）。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は１９２０＊１０８０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、これより大きい３８４０＊２１６０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは０に設定され得る。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４３０１０において、ｌｅｆｔ＿ｂａｒ＿ｆｌａｇフィールド及びｒｉｇｈｔ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、左側バー（ｌｅｆｔ  ｂａｒ）及び右側バー（ｒｉｇｈｔ  ｂａｒ）を用いたピラーボックスが生成されることを示すことができる。また、バーに関する情報（ｂａｒ＿ｄａｔａ）ｄ４３０１０において、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドはＣ値を有し、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドはＤ値を有することができる。この場合、ｄ４４０１０に示したように、左側バーは、（Ｃ＋１）／Ｒの水平サイズを有することができる。ここで、Ｒは、エミッションフォーマットとプロダクションフォーマットとの比率である。実施例において、プロダクションフォーマット（３８４０＊２１６０）はエミッションフォーマット（１９２０＊１０８０）の２倍のサイズを有するので、Ｒの値は２であり得る。実施例によって、Ｒは、プロダクションフォーマットの水平サイズであるＨをエミッションフォーマットの水平サイズで割った値を意味してもよい。この場合にもＲの値は２である。ここで、左側バーの垂直サイズは、エミッションフォーマットの垂直サイズと同一であってもよい。また、右側バーは、（Ｈ−Ｄ）／Ｒの水平サイズを有することができる。ここで、Ｈは、プロダクションフォーマットの水平サイズを示すことができる。すなわち、プロダクションフォーマットが３８４０＊２１６０であるので、Ｈは３８４０の値を有することができ、右側バーは（３８４０−Ｄ）／２の水平サイズを有することができる。ここで、右側バーの垂直サイズは、エミッションフォーマットの垂直サイズと同一であってもよい。このように、プロダクションフォーマットがエミッションフォーマットよりも大きい場合、放送受信装置は、ｂａｒ＿ｄａｔａに含まれた情報をプロダクションフォーマットに適用し、プロダクションフォーマットとエミッションフォーマットとの比率によってスケーリングしてバー（ｂａｒ）のサイズを決定し、バーを生成することができる。すなわち、放送受信装置は、バー���関する情報と共に受信されたオリジナルソースフォーマットに関する情報を用いて、エミッションフォーマットでのバーのサイズを確認し、スケーリングを通じたピラーボックスの生成を行うことができる。放送受信装置のディスプレイで生成されたピラーボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４７１】
第三のケースとして、放送システムが送出するエミッションフォーマット（ｅｍｉｓｓｉｏｎ  ｆｏｒｍａｔ）がプロダクションフォーマット（ｐｒｏｄｕｃｔｉｏｎ  ｆｏｒｍａｔ）よりも大きい場合である（ｄ４４０２０）。例えば、エミッションフォーマット、すなわち、エンコードされたビデオの解像度は１９２０＊１０８０であってもよい。また、プロダクションフォーマット、すなわち、オリジナルソースビデオの解像度は、これより小さい１２８０＊７２０であってもよい。この場合、前述したオリジナルソースフォーマットに関する情報に含まれたｉｄｅｎｔｉｃａｌ＿ｆｏｒｍａｔ＿ｆｌａｇフィールドは０に設定され得る。また、バーに関する情報において、ｌｅｆｔ＿ｂａｒ＿ｆｌａｇフィールド及びｒｉｇｈｔ＿ｂａｒ＿ｆｌａｇフィールドは１に設定されて、左側バー（ｌｅｆｔ  ｂａｒ）及び右側バー（ｒｉｇｈｔ  ｂａｒ）を用いたピラーボックスが生成されることを示すことができる。また、バーに関する情報において、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｅｎｄ＿ｏｆ＿ｌｅｆｔ＿ｂａｒフィールドはＣ値を有し、ｐｉｘｅｌ＿ｎｕｍｂｅｒ＿ｓｔａｒｔ＿ｏｆ＿ｒｉｇｈｔ＿ｂａｒフィールドはＤ値を有することができる。この場合、ｄ４４０２０に示したように、左側バーは、（Ｃ＋１）＊Ｆの水平サイズを有することができる。ここで、Ｆは、エミッションフォーマットとプロダクションフォーマットとの比率である。実施例において、エミッションフォーマット（１９２０＊１０８０）はプロダクションフォーマット（１２８０＊７２０）の１．５倍のサイズを有するので、Ｆの値は１．５であり得る。実施例によって、Ｆは、エミッションフォーマットの垂直サイズをプロダクションフォーマットの垂直サイズで割った値を意味してもよい。この場合にもＦの値は１．５である。ここで、左側バーの垂直サイズは、エミッションフォーマットの垂直サイズと同一であってもよい。また、右側バーは、（Ｈ−Ｄ）＊Ｆの水平サイズを有することができる。ここで、Ｈは、プロダクションフォーマットの水平サイズを示すことができる。すなわち、プロダクションフォーマットが１２８０＊７２０であるので、Ｈは１２８０の値を有することができ、右側バーは（１２８０−Ｄ）＊１．５の水平サイズを有することができる。ここで、右側バーの垂直サイズは、エミッションフォーマットの垂直サイズと同一であってもよい。このように、プロダクションフォーマットがエミッションフォーマットよりも小さい場合、放送受信装置は、ｂａｒ＿ｄａｔａに含まれた情報をプロダクションフォーマットに適用し、プロダクションフォーマットとエミッションフォーマットとの比率によってスケーリングしてバー（ｂａｒ）のサイズを決定し、バーを生成することができる。すなわち、放送受信装置は、バーに関する情報と共に受信されたオリジナルソースフォーマットに関する情報を用いて、エミッションフォーマットでのバーのサイズを確認し、スケーリングを通じたピラーボックスの生成を行うことができる。放送受信装置のディスプレイで生成されたピラーボックスを除いた領域がアクティブイメージ領域（ａｃｔｉｖｅ  ｉｍａｇｅ  ａｒｅａ）となり得る。
【０４７２】
図４５は、本発明の一実施例に係る放送信号を送信する方法を示した図である。
【０４７３】
本発明の一実施例に係る放送信号を送信する方法は、サービスデータ及びサービスシグナリング情報を生成するステップ（ｄｓ４５０１０）、サービスリストテーブルを生成するステップ（ｄｓ４５０２０）、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして処理するステップ（ｄｓ４５０３０）、及び／又は放送信号を生成し、これを放送網を介して送信するステップ（ｄｓ４５０４０）を含むことができる。
【０４７４】
まず、送信側のサービスデータ生成部（ｄ４６０１０）は、放送サービスのサービスデータ及び／又は放送サービスをシグナリングするサービスシグナリング情報を生成することができる。ここで、サービスデータは、当該放送サービスに含まれるメディアデータ、ＮＲＴデータ、ストリーミングデータなどを総括する概念であってもよい。サービスデータは、当該サービスのサービスコンポーネントを含むことができる。ここで、サービスシグナリング情報は、前述したＳＬＳに該当してもよい。サービスデータ生成部は、サービスプロバイダ側でサービスを提供するために実際のサービスと関連するデータを生成するブロックであって、ハードウェアエレメントであってもよい。
【０４７５】
送信側の下位レベルシグナリング生成部（ｄ４６０２０）は、サービスリストテーブルを生成することができる。サービスリストテーブルは、前述したＳＬＴに該当してもよい。サービスリストテーブルは、前述したように、サービスシグナリング情報が伝達される伝送セッションを識別するブートストラップ情報を含むことができる。ここで、ブートストラップ情報は、前述した通りである。伝送セッションは、実施例によって、ＭＭＴＰセッション及び／又はＲＯＵＴＥセッションであってもよい。下位レベルシグナリング生成部は、ＳＬＴなどのＬＬＳ（Ｌｏｗ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）を生成することを管掌するブロックであって、ハードウェアエレメントであってもよい。
【０４７６】
送信側の伝送レイヤ処理部（ｄ４６０３０）は、生成されたサービスコンポーネント、サービスシグナリング情報及び／又はサービスリストテーブルをＩＰパケットとして処理することができる。これに先立ち、当該データはＵＤＰによって処理され得る。伝送レイヤ処理部は、上位レイヤのデータを伝送のために処理することを担当するブロックであって、ハードウェアエレメントであってもよい。
【０４７７】
送信側のフィジカルレイヤ処理部（ｄ４６０４０）は、生成されたＩＰパケットを処理して放送信号を生成し、放送信号を放送網を介して送信することができる。この過程で、前述したリンクレイヤに他の動作が先に行われて、上位レイヤデータ（ＩＰパケットなど）がリンクレイヤパケットにカプセル化され得る。その後、リンクレイヤパケットが、フィジカルレイヤで定義する動作によってエンコーディング／インタリービングなどの過程を経て放送信号として処理され得る。生成された放送信号は、放送網などを介して伝送されてもよい。実施例によって、前述したデータはブロードバンドで伝達されてもよい。フィジカルレイヤ処理部は、前述したリンクレイヤ及び／又はフィジカルレイヤを担当するブロックであって、ハードウェアエレメントであってもよい。
【０４７８】
本発明の他の実施例に係る放送信号を送信する方法において、サービスシグナリング情報はＵＳＢＤを含むことができる。前述したように、ＵＳＢＤは、放送サービスに関連する技術的情報を記述するシグナリングハブとして動作することができる。ＵＳＢＤは、サービスタイプ情報をさらに含むことができる。ここで、サービスタイプ情報は、ＵＳＢＤで記述するコンポーネントを組み合わせて提供する最終サービス（ｓｅｒｖｉｃｅ）のタイプを意味し得る。サービスタイプ情報は、ステレオスコピック３Ｄ（Ｓｔｅｒｅｏｓｃｏｐｉｃ  ３Ｄ）、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）などであってもよい。
【０４７９】
本発明の更に他の実施例に係る放送信号を送信する方法において、サービスリストテーブル又はＵＳＢＤは、ケイパビリティ情報をさらに含むことができる。これは、前述したＳＬＴ乃至ＵＳＢＤ内に含まれる様々なケイパビリティ情報を意味し得る。ケイパビリティ情報は、放送サービスを有意にプレゼンテーションするのに要求される少なくとも１つ以上のケイパビリティを記述することができる。ここで、ケイパビリティ情報は、予め定義されたケイパビリティコードを用いて記述されてもよい。実施例によって、ケイパビリティ情報は、ケイパビリティのカテゴリを示すケイパビリティカテゴリコードによって記述されてもよい。実施例によって、ケイパビリティカテゴリコードと、当該カテゴリ内で具体的にどのようなケイパビリティ情報を意味するのかを示すケイパビリティコードとを組み合わせて、当該ケイパビリティ情報が記述されてもよい。ケイパビリティ情報については、前述した通りである。
【０４８０】
本発明の更に他の実施例に係る放送信号を送信する方法において、放送サービスのサービスシグナリング情報がＭＭＴプロトコルによって伝達される場合、サービスシグナリング情報は、放送サービスに対するキャプション情報を含むシグナリングメッセージをさらに含むことができる。前述したように、ＭＭＴＰに従ってＳＬＳが伝達される場合、ＭＭＴＰメッセージを介してシグナリング情報が伝達されてもよい。実施例によって、ＭＰＴメッセージ又は新たに定義される他のＭＭＴＰメッセージ内で様々な情報（マルチビュー、キャプション、３Ｄ、ＷＣＧ、ＨＤＲなど）が伝達されてもよい。実施例によって、一つのＭＭＴＰメッセージが複数個の情報を同時に含むこともできる。また、ＭＰＴメッセージ又は新たに定義される他のＭＭＴＰメッセージは、サービスタイプ情報をさらに含むことができる。ここで、サービスタイプ情報は、ＭＰＴメッセージ又は新たに定義される他のＭＭＴＰメッセージで記述するアセット（ａｓｓｅｔ）を組み合わせて提供する最終サービス（ｓｅｒｖｉｃｅ）のタイプを意味し得る。サービスタイプ情報は、ステレオスコピック３Ｄ（Ｓｔｅｒｅｏｓｃｏｐｉｃ  ３Ｄ）、マルチビュー（Ｍｕｌｔｉｖｉｅｗ）などであってもよい。
【０４８１】
このキャプション情報は、当該放送サービスのキャプションの言語を示す言語情報、キャプションの役割を示す役割情報、キャプションの縦横比（ａｓｐｅｃｔ  ｒａｔｉｏ）を示す縦横比情報、キャプションがイージーリーダー（ｅａｓｙ  ｒｅａｄｅｒ）キャプションであるか否かを示すイージーリーダー情報、及び／又はキャプションが３Ｄ（３−Ｄｉｍｅｎｓｉｏｎａｌ）をサポートするか否かを示す３Ｄサポート情報などを含むことができる。キャプション情報については、前述した通りである。前述したように、マルチビュー情報はＭＰＤ内に含まれてもよい。
【０４８２】
本発明の更に他の実施例に係る放送信号を送信する方法において、シグナリングメッセージは、放送サービスのサービスコンポーネントに対する３Ｄ関連情報をさらに含むことができる。ここで、シグナリングメッセージは、ＭＭＴＰメッセージのうちの一つを意味し得る。３Ｄ関連情報は、当該サービスコンポーネントの映像（ｖｉｅｗ）とその映像の隣接（ａｄｊａｃｅｎｔ）映像との間の最小視差情報、及び／又は当該映像と隣接映像との間の最大視差情報を含むことができる。３Ｄ情報については、前述した通りである。実施例によって、３Ｄ関連情報は、当該サービスコンポーネントの映像（ｖｉｅｗ）の順序を示すビューポジション情報をさらに含んでもよい。実施例によって、ビューポジション情報は、他のＭＭＴＰメッセージ又はＭＰＤを介して伝達されてもよい。
【０４８３】
ＭＰＤを介して伝達されるビューポジション情報は、３Ｄサービスと関連して各コンポーネントに対して右側視点情報（ｒｉｇｈｔ  ｖｉｅｗ  ｆｌａｇ）を含むことができる。これは、当該コンポーネントが右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるか、または左側視点（ｌｅｆｔ  ｖｉｅｗ）であるかを示すことができる。また、ＭＰＤを介して伝達されるビューポジション情報は、マルチビューサービスと関連して各コンポーネントのビューポジション情報を含むことができる。ここで、マルチビューサービスは、３Ｄマルチビュー又はパノラママルチビューを意味してもよい。３Ｄマルチビューである場合、ビューポジション情報は左側視点又は右側視点を示すことができる。
【０４８４】
ＭＭＴアセット（ａｓｓｅｔ）が、ステレオスコピック３Ｄサービスのためのビデオストリームコンポーネントである場合、ＭＰテーブル内のａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒとして、ビューポジションディスクリプタを含むことができる。ビューポジションディスクリプタを介して伝達されるビューポジション情報は、３Ｄサービスと関連して各コンポーネントに対して右側視点情報（ｒｉｇｈｔ  ｖｉｅｗ  ｆｌａｇ）を含むことができる。これは、当該コンポーネントが右側視点（ｒｉｇｈｔ  ｖｉｅｗ）であるか、または左側視点（ｌｅｆｔ  ｖｉｅｗ）であるかを示すことができる。また、ＭＰＤを介して伝達されるビューポジション情報は、マルチビューサービスと関連して各コンポーネントのビューポジション情報を含むことができる。ここで、マルチビューサービスは、３Ｄマルチビュー又はパノラママルチビューを意味してもよい。３Ｄマルチビューである場合、ビューポジション情報は左側視点又は右側視点を示すことができる。
【０４８５】
本発明の更に他の実施例に係る放送信号を送信する方法において、ＵＳＢＤは、放送サービスのサービスコンポーネントに関するコンポーネント情報を含むことができる。コンポーネント情報については、前述した通りである。コンポーネント情報は、当該サービスコンポーネントのタイプを示すコンポーネントタイプ情報、及び／又は当該サービスコンポーネントのタイプによって当該サービスコンポーネントの役割を示すコンポーネント役割（ｒｏｌｅ）情報を含むことができる。それぞれの情報は、前述した＠ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性及び／又は＠ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性に該当してもよい。コンポーネント役割情報は、当該放送サービスのオーディオ又はビデオコンポーネントが聴覚又は視覚障害者のためのサービスコンポーネントであるか否かを示すことができる。すなわち、この情報は、当該コンポーネントがｈｅａｒｉｎｇ  ｉｍｐａｉｒｅｄ／ｖｉｓｕａｌｌｙ  ｉｍｐａｉｒｅｄのためのコンポーネントであるか否かを示すことができる。
【０４８６】
本発明の更に他の実施例に係る放送信号を送信する方法において、放送サービスのサービスシグナリング情報がＲＯＵＴＥプロトコルによって伝達される場合、ＵＳＢＤは、ＭＰＤをリファレンスする情報をさらに含むことができる。ＭＰＤは、前述したように、放送サービスのサービスデータに対するリソース識別子及び／又はリソースのコンテクスト（ｃｏｎｔｅｘｔ）情報を含むことができる。前述したように、このＭＰＤは、コンポーネントに対する様々な前述した情報を含むことができる。実施例によって、ＭＰＤは、放送サービスに対するキャプション情報及び／又は３Ｄ関連情報をさらに含むことができる。
【０４８７】
本発明の一実施例に係る放送信号を受信する方法について説明する。この方法は図示していない。
【０４８８】
本発明の一実施例に係る放送信号を受信する方法は、受信側のフィジカルレイヤ処理部が放送信号を処理し、これからＩＰパケットを取得するステップ、下位レベルシグナリング処理部がＳＬＴを取得し、これからブートストラップ情報を取得するステップ、ブートストラップ情報を用いてＳＬＳを伝達する伝送セッションを識別し、その伝送セッションに接近してＳＬＳを取得するステップ、そのＳＬＳを用いて放送サービスのサービスコンポーネントを取得するステップ、及び／又はディスプレイ部が取得されたサービスコンポーネントを用いて放送サービスを提供するステップを含むことができる。実施例によって、ＳＬＴ及び／又はＳＬＳの情報から、前述したキャプション、３Ｄ、ＨＤＲ、ＷＣＧ、マルチビューなどの情報が取得されてもよい。ＭＭＴＰ又はＲＯＵＴＥプロトコルのうちどの伝送プロトコルを使用するかによって、当該情報は、ＳＬＳのＭＰＤ又はＳＬＳのＭＭＴＰメッセージから取得され得る。受信側のフィジカルレイヤ処理部、下位レベルシグナリング処理部及び／又はディスプレイ部は、ハードウェアエレメントであってもよい。
【０４８９】
本発明の実施例に係る放送信号を受信する方法は、前述した本発明の実施例に係る放送信号を送信する方法に対応することができる。放送信号を受信する方法は、放送信号を送信する方法で使用されるモジュール（例えば、サービスデータ生成部、伝送レイヤ処理部、下位レベルシグナリング生成部、フィジカルレイヤ処理部など）に対応するハードウェアモジュールによって行われ得る。放送信号を受信する方法は、前述した放送信号を送信する方法の実施例に対応する実施例を有することができる。
【０４９０】
前述したステップは、実施例によって、省略されてもよく、類似／同一の動作を行う他のステップによって代替されてもよい。
【０４９１】
図４６は、本発明の一実施例に係る放送信号を送信する装置を示した図である。
【０４９２】
本発明の一実施例に係る放送信号を送信する装置は、前述したサービスデータ生成部、伝送レイヤ処理部、下位レベルシグナリング生成部及び／又はフィジカルレイヤ処理部を含むことができる。それぞれのブロック及びモジュールは、前述した通りである。
【０４９３】
本発明の一実施例に係る放送信号を送信する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を送信する方法の実施例を行うことができる。
【０４９４】
本発明の一実施例に係る放送信号を受信する装置を説明する。この装置は図示していない。
【０４９５】
本発明の一実施例に係る放送信号を受信する装置は、前述したフィジカルレイヤ処理部、下位レベルシグナリング処理部及び／又はディスプレイ部を含むことができる。それぞれのブロック及びモジュールは、前述した通りである。
【０４９６】
本発明の一実施例に係る放送信号を受信する装置及びその内部モジュール／ブロックは、前述した本発明の放送信号を受信する方法の実施例を行うことができる。
【０４９７】
前述した装置の内部のブロック／モジュールなどは、メモリに格納された連続した過程を実行するプロセッサであってもよく、実施例によって、装置の内／外部に位置するハードウェアエレメントであってもよい。
【０４９８】
前述したモジュールは、実施例によって、省略されてもよく、類似／同一の動作を行う他のモジュールによって代替されてもよい。
【０４９９】
モジュール又はユニットは、メモリ（又は格納ユニット）に格納された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各ステップは、ハードウェア／プロセッサによって行われてもよい。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実行されてもよい。このコードは、プロセッサが読み取り可能な格納媒体に書き込まれてもよく、したがって、装置（ａｐｐａｒａｔｕｓ）の提供するプロセッサによって読み取られてもよい。
【０５００】
説明の便宜のために各図に分けて説明したが、各図に開示した実施例を組み合わせて新しい実施例を具現するように設計することも可能である。そして、通常の技術者の必要によって、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも、本発明の権利範囲に属する。
【０５０１】
本発明に係る装置及び方法は、上述したように、説明された実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。
【０５０２】
一方、本発明が提案する方法を、ネットワークデバイスに備えられた、プロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することが可能である。プロセッサが読み取り可能な記録媒体は、プロセッサで読み出し可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークに接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み取り可能なコードが格納され、実行されてもよい。
【０５０３】
また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者によって様々な変形実施が可能であることは勿論であり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。
【０５０４】
そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。
【０５０５】
本発明の思想や範囲から逸脱することなく、本発明の様々な変更及び変形が可能であることは、当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。
【０５０６】
本明細書では装置の発明及び方法の発明を両方とも言及しており、装置の発明及び方法の発明の説明を互いに補完して適用することもできる。
〔実施例〕
【０５０７】
様々な実施例が、発明を実施するための最良の形態で説明された。
【産業上の利用可能性】
【０５０８】
本発明は一連の放送信号提供分野で利用される。
【０５０９】
本発明の思想や範囲から逸脱することなく、本発明で様々な変更及び変形が可能であることは当業者には自明である。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むものとして意図される。
【図１】
2018517329.tif 000003
【図２】
2018517329.tif 000004
【図３】
2018517329.tif 000005
【図４】
2018517329.tif 000006
【図５】
2018517329.tif 000007
【図６】
2018517329.tif 000008
【図７】
2018517329.tif 000009
【図８】
2018517329.tif 000010
【図９】
2018517329.tif 000011
【図１０（ａ）】
2018517329.tif 000012
【図１０（ｂ）】
2018517329.tif 000013
【図１０（ｃ）】
2018517329.tif 000014
【図１１】
2018517329.tif 000015
【図１２】
2018517329.tif 000016
【図１３】
2018517329.tif 000017
【図１４】
2018517329.tif 000018
【図１５】
2018517329.tif 000019
【図１６】
2018517329.tif 000020
【図１７】
2018517329.tif 000021
【図１８】
2018517329.tif 000022
【図１９】
2018517329.tif 000023
【図２０】
2018517329.tif 000024
【図２１】
2018517329.tif 000025
【図２２】
2018517329.tif 000026
【図２３】
2018517329.tif 000027
【図２４】
2018517329.tif 000028
【図２５】
2018517329.tif 000029
【図２６】
2018517329.tif 000030
【図２７】
2018517329.tif 000031
【図２８】
2018517329.tif 000032
【図２９】
2018517329.tif 000033
【図３０】
2018517329.tif 000034
【図３１】
2018517329.tif 000035
【図３２】
2018517329.tif 000036
【図３３】
2018517329.tif 000037
【図３４】
2018517329.tif 000038
【図３５】
2018517329.tif 000039
【図３６】
2018517329.tif 000040
【図３７】
2018517329.tif 000041
【図３８】
2018517329.tif 000042
【図３９】
2018517329.tif 000043
【図４０】
2018517329.tif 000044
【図４１】
2018517329.tif 000045
【図４２】
2018517329.tif 000046
【図４３】
2018517329.tif 000047
【図４４】
2018517329.tif 000048
【図４５】
2018517329.tif 000049
【図４６】
2018517329.tif 000050
【手続補正書】
【提出日】平成29年10月10日(2017.10.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
放送サービスのサービスデータ及び前記放送サービスをシグナリングするサービスシグナリング情報を生成するステップであって、前記サービスデータは、前記放送サービスに含まれるサービスコンポーネントを含み、前記サービスコンポーネントのうちの１つは、ＳＨＶＣ（Ｓｃａｌａｂｌｅ  Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）でエンコードされたステレオスコピックビデオである、ステップと、
サービスリストテーブルを生成するステップであって、前記サービスリストテーブルは、前記サービスシグナリング情報を識別するブートストラップ情報を含む、ステップと、
前記サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして処理するステップと、
前記ＩＰパケットを処理して放送信号を生成し、前記放送信号を放送網を介して伝送するステップとを含み、
前記ステレオスコピックビデオは、左視点及び右視点を示すマルチビュービューポジション（ｍｕｌｔｉ−ｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを含む、放送信号送信方法。
【請求項２】
前記マルチビュービューポジションＳＥＩメッセージに含まれた視点位置情報（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）は、複数の視点に対する順序を左から右方向に示す、請求項１に記載の放送信号送信方法。
【請求項３】
前記視点位置情報は、従属識別子（ｄｅｐｅｎｄｅｎｃｙ  ｉｄｅｎｔｉｆｉｅｒｓ）と共に前記視点の順序を示し、前記従属識別子は、ベースレイヤ（ｂａｓｅ  ｌａｙｅｒ）ビデオに対して０に設定され、エンハンスメントレイヤ（ｅｎｈａｎｃｅｍｅｎｔ  ｌａｙｅｒ）ビデオに対して１に設定される、請求項２に記載の放送信号送信方法。
【請求項４】
前記視点位置情報は、最も左側の（ｌｅｆｔ−ｍｏｓｔ）視点に対して０に設定され、前記最も左側の視点から右側に位置した次の視点毎に１ずつ増加する値に設定される、請求項２に記載の放送信号送信方法。
【請求項５】
前記ステレオスコピックビデオはマルチビューシーンポジション（ｍｕｌｔｉ−ｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージを含み、前記マルチビューシーンポジションＳＥＩメッセージは、３Ｄディスプレイにレンダリングするに先立って、視点をプロセッシングするのに使用される、請求項１に記載の放送信号送信方法。
【請求項６】
前記マルチビューシーンポジションＳＥＩメッセージは最小視差情報（ｍｉｎｉｍｕｍ  ｄｉｓｐａｒｉｔｙ  ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記最小視差情報は、前記ステレオスコピックビデオ内の最も前方のオブジェクトの３次元位置を示す、請求項５に記載の放送信号送信方法。
【請求項７】
前記最小視差情報は、前記３Ｄディスプレイ上の前記視点の前方に、ＯＳＤ（ｏｎ−ｓｃｒｅｅｎ  ｄｉｓｐｌａｙ）のような受信機で生成されるグラフィックをレンダリングするのに使用される、請求項６に記載の放送信号送信方法。
【請求項８】
放送サービスのサービスデータ及び前記放送サービスをシグナリングするサービスシグナリング情報を生成するサービスデータ生成部であって、前記サービスデータは、前記放送サービスに含まれるサービスコンポーネントを含み、前記サービスコンポーネントのうちの１つは、ＳＨＶＣ（Ｓｃａｌａｂｌｅ  Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）でエンコードされたステレオスコピックビデオである、サービスデータ生成部と、
サービスリストテーブルを生成する下位レベルシグナリング（ｌｏｗ  ｌｅｖｅｌ  ｓｉｇｎａｌｉｎｇ）生成部であって、前記サービスリストテーブルは、前記サービスシグナリング情報を識別するブートストラップ情報を含む、下位レベルシグナリング生成部と、
前記サービスコンポーネント、前記サービスシグナリング情報及び前記サービスリストテーブルをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして処理する伝送レイヤ処理部と、
前記ＩＰパケットを処理して放送信号を生成し、前記放送信号を放送網を介して伝送するフィジカルレイヤ処理部とを含み、
前記ステレオスコピックビデオは、左視点及び右視点を示すマルチビュービューポジション（ｍｕｌｔｉ−ｖｉｅｗ  ｖｉｅｗ  ｐｏｓｉｔｉｏｎ）ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを含む、放送信号送信装置。
【請求項９】
前記マルチビュービューポジションＳＥＩメッセージに含まれた視点位置情報（ｖｉｅｗ  ｐｏｓｉｔｉｏｎ  ｉｎｆｏｒｍａｔｉｏｎ）は、複数の視点に対する順序を左から右方向に示す、請求項８に記載の放送信号送信装置。
【請求項１０】
前記視点位置情報は、従属識別子（ｄｅｐｅｎｄｅｎｃｙ  ｉｄｅｎｔｉｆｉｅｒｓ）と共に前記視点の順序を示し、前記従属識別子は、ベースレイヤ（ｂａｓｅ  ｌａｙｅｒ）ビデオに対して０に設定され、エンハンスメントレイヤ（ｅｎｈａｎｃｅｍｅｎｔ  ｌａｙｅｒ）ビデオに対して１に設定される、請求項９に記載の放送信号送信装置。
【請求項１１】
前記視点位置情報は、最も左側の（ｌｅｆｔ−ｍｏｓｔ）視点に対して０に設定され、前記最も左側の視点から右側に位置した次の視点毎に１ずつ増加する値に設定される、請求項９に記載の放送信号送信装置。
【請求項１２】
前記ステレオスコピックビデオはマルチビューシーンポジション（ｍｕｌｔｉ−ｖｉｅｗ  ｓｃｅｎｅ  ｐｏｓｉｔｉｏｎ）ＳＥＩメッセージを含み、前記マルチビューシーンポジションＳＥＩメッセージは、３Ｄディスプレイにレンダリングするに先立って、視点をプロセッシングするのに使用される、請求項８に記載の放送信号送信装置。
【請求項１３】
前記マルチビューシーンポジションＳＥＩメッセージは最小視差情報（ｍｉｎｉｍｕｍ  ｄｉｓｐａｒｉｔｙ  ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記最小視差情報は、前記ステレオスコピックビデオ内の最も前方のオブジェクトの３次元位置を示す、請求項１２に記載の放送信号送信装置。
【請求項１４】
前記最小視差情報は、前記３Ｄディスプレイ上の前記視点の前方に、ＯＳＤ（ｏｎ−ｓｃｒｅｅｎ  ｄｉｓｐｌａｙ）のような受信機で生成されるグラフィックをレンダリングするのに使用される、請求項１３に記載の放送信号送信装置。
【国際調査報告】
2018517329.tif 000051
2018517329.tif 000052
2018517329.tif 000053
2018517329.tif 000054