JP6181848B2 - ３ｄ放送信号を処理する方法及び装置 - Google Patents

Description

本発明は、放送信号を処理する方法及び装置に関する。より詳細には、本発明は、３Ｄ放送システムにおいて、２Ｄサービスと３Ｄサービス間の互換性を維持しながら放送サービスを提供する方法及び装置に関する。

放送設備及び放送システムの発展に伴い、放送を介した３Ｄコンテンツの提供が可能となり、また、ソース（ｓｏｕｒｃｅ）から様々な画面比率で製作されたコンテンツの提供が可能となった。したがって、放送受信機において３Ｄ放送コンテンツを適切に再生できるようにする３Ｄ放送コンテンツの伝送方式、及びそれと関連するシグナリング方法も共に開発されている。

しかし、現在の３Ｄ放送システムでは、３Ｄ放送コンテンツの再生が不可能な既存の放送受信機において、２Ｄで当該放送コンテンツを再生できないという問題がある。

また、現在の３Ｄ放送システムでは、３Ｄ放送と２Ｄ放送間の互換性を維持しながら、提供されるコンテンツの画面比率及び受信機の画面比率を考慮して放送コンテンツをレンダリングすることができないという問題があった。

本発明が達成しようとする技術的課題は、上述した問題点を解決するためのもので、３Ｄ放送システム内で、３Ｄ再生が不可能であるか、または３Ｄ再生ではなく２Ｄで放送コンテンツを消費しようとする受信機において、効果的な２Ｄ放送コンテンツを再生できるようにするものである。

また、本発明が達成しようとする技術的課題は、３Ｄ放送と２Ｄ放送間の互換性を維持しながら、提供されるコンテンツの画面比率及び受信機の画面比率を考慮して放送コンテンツをレンダリングできるシグナリング方式を提示することにある。

上述した技術的課題を解決するための本発明の一実施例に係る３Ｄ放送受信機は、プログラムマップテーブル（ＰＭＴ）と３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータとを含む放送信号を受信するチューナーと、ここで、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含み、前記ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報が、ＦＰＡ ＳＥＩメッセージが前記３Ｄビデオデータに含まれていることを示す場合、前記ＦＰＡ ＳＥＩメッセージをパージングし、前記ＦＰＡ ＳＥＩメッセージに含まれた、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報をパージングし、前記３Ｄビデオデータに含まれたＤｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータをパージングし、前記３Ｄビデオデータをデコーディングするデコーダと、前記３Ｄビデオフォーマット情報及び前記ＤＤＷ情報によって、前記デコーディングされた３Ｄビデオデータのビデオフレーム内で２Ｄディスプレイのための２Ｄ映像を抽出する２Ｄ抽出部と、前記抽出された２Ｄ映像を、前記ＡＦＤ情報及びＢａｒデータ情報を用いて、受信機の画面比率に合わせてレンダリングする比率変換部と、前記レンダリングされた２Ｄ映像をディスプレイするディスプレイ処理部とを含む。

好ましくは、前記ＤＤＷ情報は、前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれることを特徴とする。

好ましくは、前記ＤＤＷ情報は、ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含むことを特徴とする。

好ましくは、前記ＡＦＤ情報は、関心のある領域の画面比率を識別する情報を含むことを特徴とする。

好ましくは、前記放送信号は、前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含むことを特徴とする。

上述した技術的課題を解決するための本発明の一実施例に係る３Ｄ放送受信機における放送信号処理方法は、プログラムマップテーブル（ＰＭＴ）と３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータとを含む放送信号を受信するステップと、ここで、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含み、前記ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報が、ＦＰＡ ＳＥＩメッセージが前記３Ｄビデオデータに含まれていることを示す場合、前記ＦＰＡ ＳＥＩメッセージをパージングし、前記ＦＰＡ ＳＥＩメッセージに含まれた、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報をパージングし、前記３Ｄビデオデータに含まれたＤｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータをパージングし、前記３Ｄビデオデータをデコーディングするステップと、前記３Ｄビデオフォーマット情報及び前記ＤＤＷ情報によって、前記デコーディングされた３Ｄビデオデータのビデオフレーム内で２Ｄディスプレイのための２Ｄ映像を抽出するステップと、前記抽出された２Ｄ映像を、前記ＡＦＤ情報及びＢａｒデータ情報を用いて、受信機の画面比率に合わせてレンダリングするステップと、前記レンダリングされた２Ｄ映像をディスプレイするステップとを含む。

好ましくは、前記ＤＤＷ情報は、前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれることを特徴とする。

好ましくは、前記ＤＤＷ情報は、ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含むことを特徴とする。

好ましくは、前記ＡＦＤ情報は、関心のある領域の画面比率を識別する情報を含むことを特徴とする。

好ましくは、前記放送信号は、前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含むことを特徴とする。

前述した技術的課題を解決するための本発明の一実施例に係る、３Ｄ放送送信機は、プログラムマップテーブル（ＰＭＴ）をエンコーディングする第１シグナリングエンコーダと、ここで、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含み、前記ＦＰＡ ＳＥＩメッセージは、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報を含み、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータをエンコーディングする第２シグナリングエンコーダと、３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータ、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータを含むビデオシーケンスをエンコーディングするビデオエンコーダと、前記ＰＭＴ及び前記ビデオシーケンスを含む放送信号を生成する放送信号生成器とを含む。

好ましくは、前記ＤＤＷ情報は、前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれることを特徴とする。

好ましくは、前記ＤＤＷ情報は、ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含むことを特徴とする。

好ましくは、前記ＡＦＤ情報は、関心のある領域の画面比率を識別する情報を含むことを特徴とする。

好ましくは、前記放送信号は、前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含むことを特徴とする。

本発明によれば、３Ｄ放送システム内で、３Ｄ再生が不可能であるか、または３Ｄ再生ではなく２Ｄで放送コンテンツを消費しようとする受信機において、効果的な２Ｄ放送コンテンツを再生することができる効果がある。

また、本発明によれば、３Ｄ放送と２Ｄ放送間の互換性を維持しながら、提供されるコンテンツの画面比率及び受信機の画面比率を考慮して放送コンテンツをレンダリングすることができる効果がある。

本発明の実施例に係るイメージディスプレイ装置の一例を説明するために示した図である。 本発明の実施例に係る３Ｄイメージディスプレイ装置の他の例を説明するために示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｌｉｓｔ ｄｅｓｃｒｉｐｔｏｒを含んだＮＩＴセクションの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｌｉｓｔ ｄｅｓｃｒｉｐｔｏｒの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒを含んだＳＤＴセクションの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒを含んだＰＭＴセクション及びＥＩＴセクションの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒを含んだＰＭＴセクション及びＥＩＴセクションの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係る３Ｄ ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒの一例に対するビットストリームシンタックスを示した図である。 本発明の実施例に係る表３を追加説明するために示した図である。 本発明の実施例に係る表３を追加説明するために示した図である。 本発明の実施例に係る表３を追加説明するために示した図である。 本発明の実施例に係るｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒのビットストリームシンタックスの一例を示した図である。 本発明の実施例に係るｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒのビットストリームシンタックスの一例を示した図である。 本発明の実施例に係るｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒを用いて、対応する３Ｄサービスをシグナリングする方法の一例を示した図である。 本発明の実施例に係る３Ｄシグナリング情報を用いてステレオスコピックビデオ信号を出力する一例を説明するために示したフローチャートである。 本発明の実施例に係るＵＩの一例を示した図である。 本発明の実施例に係るＥＰＧ画面の一例を示した図である。 本発明の実施例に係るＥＰＧ画面の他の例を示した図である。 本発明の実施例に係るＥＰＧ画面の更に他の例を示した図である。 本発明の実施例に係るＥＰＧ画面の更に他の例を示した図である。 本発明の実施例に係るＥＰＧ画面の更に他の例を示した図である。 本発明の実施例に係る３Ｄバージョンの存在有無を知らせるＵＩの一例を示した図である。 本発明の実施例に係るＥＰＧの更に他の例を示した図である。 本発明の実施例に係る図２４の詳細ＵＩの例示を示した図である。 本発明の実施例に係る様々な映像フォーマットの立体映像マルチプレクシングフォーマットを例示する図である。 本発明の実施例に係る３Ｄ放送サービスの概念図を例示する図である。 本発明の実施例に係るフル解像度の３Ｄ放送サービスを提供するための方法を示す概念的なブロック図を例示する図である。 本発明の実施例に係る３Ｄ放送サービスを提供するための方法を例示する図である。 本発明の他の実施例に係る３Ｄ放送サービスを提供するための方法を例示する図である。 本発明の他の実施例に係る３Ｄ放送サービスを提供するための方法を例示する図である。 本発明の他の実施例に係る３Ｄ放送サービスを提供するための方法を例示する図である。 本発明の実施例に係る３Ｄ放送サービスを提供するためのフルフォワード及びバックワードの相互運用性（ｆｕｌｌ ｆｏｒｗａｒｄ ａｎｄ ｂａｃｋｗａｒｄ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）を例示する図である。 本発明の実施例に係る第一世代３ＤＴＶ及び第二世代３ＤＴＶに互換可能な３Ｄ放送サービスのサービスモデルを例示する図である。 本発明の実施例に係る３Ｄ相補型ビデオ情報を含むＴＶＣＴのシンタックス構造（ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅ）を例示する図である。 本発明の実施例に係るＴＶＣＴに含まれた３Ｄ相補型ビデオデスクリプタのシンタックス構造を例示する図である。 本発明の実施例に係る３Ｄ相補型ビデオ情報に含まれたｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値に応じて映像を構成する方法を例示する図である。 本発明の実施例に係る３Ｄ相補型ビデオ情報を含むＰＭＴのシンタックス構造を例示する図である。 本発明の他の実施例に係る３Ｄ相補型ビデオ情報を含むＰＭＴのシンタックス構造を例示する図である。 本発明の実施例に係る３Ｄ相補型ビデオ情報に含まれたビデオＥＳのピクチャ拡張及びユーザデータのシンタックス構造を例示する図である。 本発明の実施例に係る３Ｄ相補型ビデオ情報をデコーディングするためのユーザ識別子及び構造のＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）シンタックス構造を例示する図である。 本発明の実施例に係る３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する図である。 本発明の他の実施例に係る３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する図である。 本発明の更に他の実施例に係る３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する図である。 本発明の更に他の実施例に係る３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する図である。 本発明の実施例に係るＳＤＴを用いて３ＤＴＶサービスをシグナリングする方法を例示する図である。 本発明の実施例に係るＳＤＴを用いて３ＤＴＶサービスをシグナリングするサービスタイプ値を例示する図である。 本発明の実施例に係るＳＤＴを用いて３ＤＴＶサービスをシグナリングする追加的なサービスタイプ値及びディスクリプションを例示する図である。 本発明の実施例に係るＤＶＢ放送サービスのためのそれぞれのエレメンタリーストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）を示すコンポーネントデスクリプタを例示する図である。 本発明の実施例に係るＤＶＢ放送システムにおいてフル解像度の３Ｄ立体サービスを示すストリームコンテンツ、コンポーネントタイプ及びディスクリプションを例示する図である。 本発明の実施例に係るＳＤＴのための３Ｄ相補型ビデオデスクリプタのシンタックス構造を例示する図である。 本発明の実施例に係るリンケージデスクリプタ（ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒ）を用いてＳｐｅｃ−Ａ及びＳｐｅｃ−Ｂ ３Ｄサービスをシグナリングする方法を例示する図である。 本発明の実施例に係る３Ｄ信号をパージングすることによって立体ビデオ信号を出力するためのプロセスを示すフローチャートを例示する図である。 本発明の他の実施例に係るリンケージデスクリプタを用いてＳｐｅｃ−Ａ及びＳｐｅｃ−Ｂ ３Ｄサービスをシグナリングする方法を例示する図である。 本発明の実施例に係るＡＴＳＣ ＰＳＩＰ ＥＩＴセクションに位置したフル解像度の３ＤＴＶサービスに関する情報を例示する図である。 本発明の実施例に係るＤＶＢ ＳＩ ＥＩＴセクションに位置したフル解像度の３ＤＴＶサービスに関する情報を例示する図である。 本発明の実施例に係るＡＴＳＣ ＰＳＩＰ ＥＩＴを用いて３Ｄ相補型ビデオデスクリプタをパージング及びレンダリングすることによって立体ビデオ信号を出力するためのプロセスを示すフローチャートを例示する図である。 本発明の実施例に係るＤＶＢ ＳＩ ＥＩＴを用いて３Ｄ相補型ビデオデスクリプタをパージング及びレンダリングすることによって立体ビデオ信号を出力するためのプロセスを示すフローチャートを例示する図である。 本発明の一実施例に係る３Ｄビデオデコーダを備えた放送受信機のブロック図を例示する図である。 本発明の一実施例に係る３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）の概念図を例示する図である。 本発明の一実施例に係る３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングする方法を示す図である。 本発明の一実施例に係るコンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るリンケージデスクリプタのｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ及び／又はｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係る受信機のブロック図を示す図である。 本発明の一実施例に係る３Ｄサービス３．０の概念図を例示する図である。 本発明の一実施例に係るＳＦＣ−３ＤＴＶサービスをシグナリングする方法を示す図である。 本発明の一実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るコンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るコンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るコンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係るリンケージデスクリプタのｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ及び／又はｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄを示す図である。 本発明の一実施例に係る受信機のブロック図を示す図である。 本発明の一実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ情報によるＡｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）を示す図である。 本発明の一実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ及び伝送されるフレームのａｓｐｅｃｔ ｒａｔｉｏによる受信機のディスプレイの例を示す図である。 本発明の他の実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ及び伝送されるフレームのａｓｐｅｃｔ ｒａｔｉｏによる受信機のディスプレイの例を示す図である。 本発明の一実施例に係るｂａｒ ｄａｔａを示す図である。 本発明の一実施例に係る受信機を示す図である。

以下、本明細書では、添付の図面を参照して、本発明に係るイメージ処理方法及び装置の様々な実施例を詳細に記述する。

特に、本明細書では、本発明に係る３Ｄ（３−Ｄｉｍｅｎｓｉｏｎａｌ）サービスの識別及び処理に関して様々なシグナリング情報（ｓｉｇｎａｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を定義し、送／受信端でこれを処理できるように、イメージ処理方法及び装置を提供する。

本明細書では、このような本発明の理解を助け、説明の便宜のため、イメージディスプレイ装置は、３Ｄサービスを処理できる構成を含んだデジタル受信機（ｄｉｇｉｔａｌ ｒｅｃｅｉｖｅｒ）を例に挙げて説明する。このようなデジタル受信機は、デジタルテレビ受信機（ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｒｅｃｅｉｖｅｒ）、３Ｄサービスを処理できる構成を含んだセットトップボックス（ＳＴＢ；Ｓｅｔ−Ｔｏｐ Ｂｏｘ）と処理された３Ｄイメージを出力するディスプレイ機器（ｄｉｓｐｌａｙ ｕｎｉｔ）とを含んだ受信機セット（ｒｅｃｅｉｖｉｎｇ ｓｅｔ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、携帯電話（ｍｏｂｉｌｅ ｐｈｏｎｅ）、スマートフォン（ｓｍａｒｔ ｐｈｏｎｅ）など、３Ｄイメージデータを受信して処理又は／及び提供できる全ての機器を含むことができる。また、前記デジタル受信機は、３Ｄ専用受信機及び２Ｄ／３Ｄ兼用受信機のいずれか１つであってもよい。

これと関連して、３Ｄイメージを表現する方法には、２つの視点を考慮するステレオスコピックイメージディスプレイ方式（ｓｔｅｒｅｏｓｃｏｐｉｃ ｉｍａｇｅ ｄｉｓｐｌａｙ ｍｅｔｈｏｄ）、及び３つ以上の視点を考慮する多視点イメージディスプレイ方式（ｍｕｌｔｉ−ｖｉｅｗ ｉｍａｇｅ ｄｉｓｐｌａｙ ｍｅｔｈｏｄ）がある。

ステレオスコピックイメージディスプレイ方式は、一定距離離隔している２つのカメラ、すなわち、左側カメラと右側カメラで同じ被写体を撮影して獲得した左右一対のイメージを使用する。また、多視点イメージディスプレイ方式は、一定の距離や角度を有する３つ以上のカメラで撮影して獲得した３つ以上のイメージを使用する。

また、ステレオスコピックイメージの伝送フォーマットとしては、シングルビデオストリームフォーマット（ｓｉｎｇｌｅ ｖｉｄｅｏ ｓｔｒｅａｍ ｆｏｒｍａｔ）とマルチプルビデオストリームフォーマット（またはマルチ−ビデオストリーム）（ｍｕｌｔｉ ｖｉｄｅｏ ｓｔｒｅａｍ ｆｏｒｍａｔ）がある。

シングルビデオストリームフォーマットとしては、サイドバイサイド（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）、トップ／ダウン（ｔｏｐ／ｄｏｗｎ）、インターレースド（ｉｎｔｅｒｌａｃｅｄ）、フレームシーケンシャル（ｆｒａｍｅ ｓｅｑｕｅｎｔｉａｌ）、チェッカーボード（ｃｈｅｃｋｅｒ ｂｏａｒｄ）、アナグリフ（ａｎａｇｌｙｐｈ）などがあり、マルチプルビデオストリームフォーマットとしては、フル左／右（Ｆｕｌｌ ｌｅｆｔ／ｒｉｇｈｔ）、フル左／ハーフ右（Ｆｕｌｌ ｌｅｆｔ／Ｈａｌｆ ｒｉｇｈｔ）、２Ｄビデオ／奥行き（２Ｄ ｖｉｄｅｏ／ｄｅｐｔｈ）などがある。

前記において、ステレオイメージまたは多視点イメージは、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）を含め、様々なイメージ圧縮符号化方式によって圧縮符号化されて伝送されてもよい。

例えば、前記サイドバイサイドフォーマット、トップ／ダウンフォーマット、インターレースドフォーマット、チェッカーボードなどのようなステレオ映像は、Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方式で圧縮符号化して伝送されてもよい。このとき、受信システムにおいて、Ｈ．２６４／ＡＶＣコーディング方式の逆に、前記ステレオ映像に対して復号（ｄｅｃｏｄｉｎｇ）を行って３Ｄイメージを得ることができる。

また、フル左／ハーフ右のフォーマットの左イメージまたは多視点イメージのいずれか１つのイメージは、基本層（ｂａｓｅ ｌａｙｅｒ）イメージに、残りのイメージは上位層（ｅｎｈａｎｃｅｄ ｌａｙｅｒ）イメージに割り当てた後、基本層のイメージは、モノスコピックイメージと同様の方式で符号化し、上位層のイメージは、基本層のイメージと上位層のイメージ間の相関情報に対してのみ符号化して伝送することができる。前記基本層のイメージに対する圧縮符号化方式の例としては、ＪＰＥＧ、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４、Ｈ．２６４／ＡＶＣ方式などを用いることができる。そして、上位層のイメージに対する圧縮符号化方式は、Ｈ．２６４／ＭＶＣ（Ｍｕｌｔｉ−ｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方式を用いることができる。このとき、ステレオイメージは、基本層のイメージと１つの上位層のイメージに割り当てられるが、多視点イメージは、１つの基本層のイメージと複数個の上位層のイメージに割り当てられる。前記多視点イメージを基本層のイメージと１つ以上の上位層のイメージとに区分する基準は、カメラの位置によって決定されてもよく、またはカメラの配列形態によって決定されてもよい。または、特別な基準なしに任意に決定されてもよい。

このような３Ｄイメージディスプレイは、ステレオスコピック（ｓｔｅｒｅｏｓｃｏｐｉｃ）方式と、体積表現（ｖｏｌｕｍｅｔｒｉｃ）方式と、ホログラフィック（ｈｏｌｏｇｒａｐｈｉｃ）方式とに大別される。例えば、ステレオスコピック技術を適用した３Ｄイメージディスプレイ装置は、２Ｄ映像に奥行き（ｄｅｐｔｈ）情報を付加し、この奥行き情報を用いて、観察者が立体の生動感(liveliness)と現実感を感じることができるようにする画像表示装置である。

そして、３Ｄイメージを視聴する方式は、メガネ（ｇｌａｓｓｅｓ）を着用する方式と、メガネを着用しない裸眼方式とに大別される。

メガネ方式は、パッシブ（ｐａｓｓｉｖｅ）方式とアクティブ（ａｃｔｉｖｅ）方式とに区分される。パッシブ方式は、偏光フィルタ（ｐｏｌａｒｉｚｅｄ ｌｉｇｈｔ ｆｉｌｔｅｒ）を使用して、左映像イメージと右映像イメージとを区分して見せる方式である。このようなパッシブ方式は、両眼にそれぞれ青色と赤色の色眼鏡をかけて見る方式を含む。これとは異なり、アクティブ方式は、液晶シャッター（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｓｈｕｔｔｅｒ）を用いて左／右眼を区分する方式であって、時間的に左眼と右眼のレンズを順次開閉することによって、左映像イメージと右映像イメージを区分する方式である。このようなアクティブ方式は、時分割された画面を周期的に反復させ、該周期に同期させた電子シャッター（ｅｌｅｃｔｒｏｎｉｃ ｓｈｕｔｔｅｒ）が設置されたメガネをかけて見る方式であり、時分割方式（ｔｉｍｅ ｓｐｌｉｔ ｔｙｐｅ）またはシャッターグラス（ｓｈｕｔｔｅｒｅｄ ｇｌａｓｓ）方式とも呼ぶ。

裸眼方式の代表例としては、円筒形のレンズアレイ（ｌｅｎｓ ａｒｒａｙ）を垂直に配列したレンティキュラー（ｌｅｎｔｉｃｕｌａｒ）レンズ板を映像パネルの前方に設置するレンティキュラー方式、及び映像パネルの上部に周期的なスリット（ｓｌｉｔ）を有するバリア層（ｂａｒｒｉｅｒ ｌａｙｅｒ）を備えるパララックスバリア（ｐａｒａｌｌａｘ ｂａｒｒｉｅｒ）方式がある。ただし、以下、本明細書では、説明の便宜のため、メガネ方式を例に挙げて説明する。

また、以下、本明細書では、３Ｄ信号、特に、ステレオスコピックビデオ信号を地上波ＤＴＶ放送チャネルを介して送受信するために、ＳＩ（ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）を用いてステレオスコピックサービスをシグナリングするためにシグナリング方法について記述する。

本発明で使用される用語は、本発明における機能を考慮した上、できるだけ現在広く使用されている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分で詳細にその意味を記載する。したがって、本発明で使用される用語は、単純な用語の名称ではなく、その用語が持つ実際的な意味と本発明の全般にわたる内容に基づいて解釈されなければならないということは明らかである。

本明細書において‘シグナリング（ｓｉｇｎａｌｉｎｇ）’は、放送システム、インターネット放送システム、及び／又は放送／インターネット融合システムで提供されるサービス情報（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ；ＳＩ）を伝送／受信することを示す。サービス情報は、現在存在する各放送システムで提供される放送サービス情報（例えば、ＡＴＳＣ−ＳＩ及び／又はＤＶＢ−ＳＩ）を含む。

本明細書において‘放送信号’は、地上波放送、ケーブル放送、衛星放送、及び／又はモバイル放送以外にも、インターネット放送、ブロードバンド放送、通信放送、データ放送、及び／又はＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）などの両方向放送で提供される信号及び／又はデータを含む概念として定義する。

本明細書において‘ＰＬＰ’は、物理的層に属するデータを伝送する一定のユニットを意味する。したがって、本明細書において‘ＰＬＰ’と命名された内容は、‘データユニット’または‘データパイプ（ｄａｔａ ｐｉｐｅ）’に変えて命名されてもよい。

デジタル放送（ＤＴＶ）サービスにおいて活用される有力なアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）の１つとして、放送網とインターネット網との連動を通じたハイブリッド放送サービスを挙げことができる。ハイブリッド放送サービスは、地上波放送網を介して伝送される放送Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）コンテンツと関連するエンハンスメントデータ（ｅｎｈａｎｃｅｍｅｎｔ ｄａｔａ）あるいは放送Ａ／Ｖコンテンツの一部を、インターネットを介してリアルタイムで伝送することによって、ユーザが様々なコンテンツを経験できるようにする。

本発明は、次世代デジタル放送システムにおいて、ＩＰ ｐａｃｋｅｔ、ＭＰＥＧ−２ＴＳ ｐａｃｋｅｔ、及びその他の放送システムで使用可能なｐａｃｋｅｔをｐｈｙｓｉｃａｌ ｌａｙｅｒに伝達できるようにｅｎｃａｐｓｕｌａｔｉｏｎする方法を提示することを目的とする。また、同一のヘッダーフォーマットでｌａｙｅｒ ２ ｓｉｇｎａｌｉｎｇも共に伝送できるようにする方法も提案する。

本発明において、３Ｄ映像は、左目に見せる左映像及び右目に見せる右映像を含む。人間は、左目で見る左映像と右目で見る右映像にある事物の水平的距離差（ｄｉｓｐａｒｉｔｙ）によって立体感を感じる。

放送を介して３Ｄ映像または３Ｄサービスを提供する方法は、１つのフレームに左映像と右映像を共に伝送するｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式、及び左映像と右映像をそれぞれの伝送ストリーム、エレメンタリーストリーム、またはレイヤストリーム（ｌａｙｅｒ ｓｔｒｅａｍ）で伝送するｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ方式があり得る。Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式では、１つのフレーム内に、左映像と右映像が上／下に位置したり（ｔｏｐ−ａｎｄ−ｂｏｔｔｏｍ）、または左／右に位置（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）してもよい。ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅの定義は、３Ｄサービスと２Ｄサービス間の互換が可能であることを意味することができる。すなわち、３Ｄサービスのために左映像と右映像を提供するシステム内で、２Ｄサービスに対する質（ｑｕａｌｉｔｙ）を維持しながら、２Ｄサービスに当該左映像及び／又は右映像を使用できる方式を、ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅとして定義することができる。

図１は、本発明に係るイメージディスプレイ装置の一例を説明するために示すブロック図である。

図１を参照すると、本発明に係るイメージディスプレイ装置の一例は、大きく、コンテンツソース（ｃｏｎｔｅｎｔｓ ｓｏｕｒｃｅ）１１０から入力されるソースを処理する処理部（ｐｒｏｃｅｓｓｉｎｇ ｐａｒｔ）１３０、及び処理部１３０で処理されたＡＶデータ（Ａｕｄｉｏ／Ｖｉｄｅｏ ｄａｔａ）を出力する出力部１４０（ｏｕｔｐｕｔｔｉｎｇ ｐａｒｔ）で構成される。ここで、前記ソースは、例えば、３Ｄイメージを含む。また、前記イメージディスプレイ装置は、前記コンテンツソース１１０以外に、外部機器（ｅｘｔｅｒｎａｌ ｄｅｖｉｃｅ）１２０から入力されるソースの処理のためのインターフェース部（ｉｎｔｅｒｆａｃｉｎｇ ｐａｒｔ）１３５をさらに含むことができる。その他に、前記イメージディスプレイ装置は、出力部１４０から提供されるソースの視聴のために必要な３Ｄメガネ１５０に、３Ｄイメージの視聴のための同期信号（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｉｇｎａｌ）、例えば、シンク情報を出力するＩＲエミッタ１４５をさらに含むことができる。

図１においてイメージディスプレイ装置は、処理部１３０とディスプレイ部１４０がデジタル受信機として、１つのセット（ｓｅｔ）であるか、または、前記処理部１３０は一種のセットトップボックスの形態であり、ディスプレイ部１４０は、前記セットトップボックスで処理された信号を出力するディスプレイ機器のような機能のみを行ってもよい。特に、後者の場合には、前記処理部１３０と出力部１４０との間に、データ交換のために前述したインターフェース部１３５が用いられてもよい。

前記において、インターフェース部１３５は、例えば、３Ｄサービスの支援が可能なＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）規格を支援するインターフェース（Ｉ／Ｆ）であってもよい。

また、３Ｄイメージは、例えば、地上波放送（ｔｅｒｒｅｓｔｒｉａｌ ｂｒｏａｄｃａｓｔｉｎｇ）、ケーブル放送（ｃａｂｌｅ ｂｒｏａｄｃａｓｔｉｎｇ）、衛星放送（ｓａｔｅｌｌｉｔｅ ｂｒｏａｄｃａｓｔｉｎｇ）、光ディスク（ｏｐｔｉｃａｌ ｄｉｓｃ）、ＩＰＴＶ放送（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｔｅｌｅｖｉｓｉｏｎ ｂｒｏａｄｃａｓｔｉｎｇ）などのコンテンツソース１１０から伝送される信号またはソースに含まれるか、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）、ゲームコンソール（ｇａｍｅ ｃｏｎｓｏｌｅ）などのような外部機器１２０から直接入力されてもよい。後者の場合には、特に、インターフェース部１３５において、外部機器１２０から提供された情報に基づいて、出力のためのシグナリング情報が定義されて提供されなければならない。

外部機器１２０を介する場合には、ＤｉｖＸ、コンポーネント（ｃｏｍｐｏｎｅｎｔ）、ＡＶ、Ｓｃａｒｔ（Ｓｙｎｄｉｃａｔ ｄｅｓ Ｃｏｎｓｔｒｕｃｔｅｕｒｓ ｄ’Ａｐｐａｒｅｉｌｓ Ｒａｄｉｏｒｅｃｅｐｔｅｕｒｓ ｅｔ Ｔｅｌｅｖｉｓｅｕｒｓ、Ｒａｄｉｏ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｒｅｃｅｉｖｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ’ Ａｓｓｏｃｉａｔｉｏｎ）などの様々なフォーマット（ｆｏｒｍａｔ）の３Ｄイメージが入力され得、イメージディスプレイ装置は、前記のフォーマットを処理するための構成を含むことができる。

３Ｄメガネ１５０は、３Ｄエミッタ１４５から出力される同期信号を受信する受信部（ｒｅｃｅｉｖｉｎｇ ｐａｒｔ）（図示せず）を用いて、出力部１４０から提供される３Ｄイメージを適切に視聴することができる。ここで、前記３Ｄメガネ１５０は、２Ｄ／３Ｄ視聴モード切替のための手段をさらに備えることができ、前記視聴モード切替手段に従って個別的にシンク情報を生成する生成部（図示せず）をさらに備えることができる。また、前記で３Ｄメガネ１５０から生成されるシンク情報は、前記視聴モード切替手段から視聴モード切替要請をイメージディスプレイに伝送し、シンク情報を前記イメージディスプレイ装置から受信するか、またはイメージディスプレイ装置から既に受信されたシンク情報を参照して自体生成することができる。このとき、３Ｄメガネ１５０は、それ自体に、イメージディスプレイ装置から既に受信されたシンク情報を格納する格納部をさらに備えてもよい。

図２は、本発明に係る３Ｄイメージディスプレイ装置の他の例を説明するために示した図である。ここで、図２は、例えば、上述した図１の処理部１３０の詳細構成に対するブロック図（ｂｌｏｃｋ ｄｉａｇｒａｍ）であり得る。

図２を参照すると、本発明に係るイメージディスプレイ装置は、受信部（ａ ｒｅｃｅｉｖｉｎｇ ｐａｒｔ）２１０、復調部（ａ ｄｅｍｏｄｕｌａｔｉｎｇ ｐａｒｔ）２２０、逆多重化部（ａ ｄｅｍｕｌｔｉｐｌｅｘｉｎｇ ｐａｒｔ）２３０、シグナリング情報処理部（ＳＩ ｐｒｏｃｅｓｓｉｎｇ ｐａｒｔ）２４０、ビデオデコーダ（ａ ｖｉｄｅｏ ｄｅｃｏｄｅｒ）２５０、３Ｄイメージフォーマッタ２６０及び制御部（ａ ｃｏｎｔｒｏｌｌｉｎｇ ｐａｒｔ）２７０を含む。

以下、各構成の基本動作について記述し、本発明と関連して、詳細は、後述する各実施例においてより詳細に説明する。

受信部２１０は、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルを介して、コンテンツソース１１０から３Ｄイメージデータを含んだデジタル放送信号を受信する。

復調部２２０は、変調方式に対応する復調方式を用いて、受信部２１０で受信されたデジタル放送信号を復調する。

逆多重化部２３０は、復調されたデジタル放送信号から、オーディオデータ、ビデオデータ及びシグナリング情報を逆多重化（ｄｅｍｕｌｔｉｐｌｅｘ）する。そのために、逆多重化部２３０は、ＰＩＤ（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ）を用いてフィルタリング（ｆｉｌｔｅｒｉｎｇ）することによって、前記デジタル放送信号を逆多重化することができる。逆多重化部２３０は、前記逆多重化されたビデオ信号は後段のビデオデコーダ２５０に出力し、シグナリング情報はシグナリング情報プロセッサに出力する。ここで、前記シグナリング情報は、説明の便宜のため、ＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）、ＰＳＩＰ（Ｐｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＤＶＢ−ＳＩ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のようなＳＩ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）情報を例に挙げて説明する。

シグナリング情報プロセッサ２４０は、逆多重化部２３０から入力されるシグナリング情報を処理して制御部２７０に出力する。ここで、シグナリング情報プロセッサ２４０は、処理されるシグナリング情報を一時格納するデータベース（ＤＢ：Ｄａｔａｂａｓｅ）を内部または外部に備えてもよい。このようなシグナリング情報については、後述する各実施例でより詳細に説明する。

シグナリング情報プロセッサ２４０は、コンテンツが２Ｄイメージであるか、３Ｄイメージであるかを知らせるシグナリング情報が存在するか否かを判断する。シグナリング情報プロセッサ２４０は、判断の結果、前記シグナリング情報が存在すると、これを読み出して制御部２７０に伝送する。

ビデオデコーダ２５０は、逆多重化されたビデオデータを受信してデコーディングする。ここで、前記デコーディングは、例えば、シグナリング情報プロセッサ２４０で処理されたシグナリング情報に基づいて行われてもよい。

３Ｄイメージフォーマッタ２６０は、ビデオデコーダ２５０でデコーディングされた３Ｄイメージデータを出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）し、出力部１４０に出力する。ここで、３Ｄイメージフォーマッタ２６０は、例えば、デコーディングされたイメージデータが３Ｄイメージデータである場合にのみ活性化されてもよい。言い換えると、デコーディングされたイメージデータが２Ｄイメージデータである場合には非活性化、すなわち、３Ｄイメージフォーマッタ２６０は、入力されるイメージデータを別途に加工せずにそのまま出力、例えば、バイパス（ｂｙｐａｓｓ）することができる。

３Ｄイメージフォーマッタ２６０は、入力（デコーディングされた）ビデオフォーマットからネイティブ３Ｄディスプレイフォーマットに要求された変換を行う。アーチファクトリダクション（ａｒｔｉｆａｃｔ ｒｅｄｕｃｔｉｏｎ）、シャープネス（ｓｈａｒｐｎｅｓｓ）、コントラストエンハンスメント（ｃｏｎｔｒａｓｔ ｅｎｈａｎｃｅｍｅｎｔ）、デインタレーシング（ｄｅ−ｉｎｔｅｒｌａｃｉｎｇ）、フレームレートコンバージョン（ｆｒａｍｅ ｒａｔｅ ｃｏｎｖｅｒｓｉｏｎ）、及びクオリティーエンハンスメントブロック（ｑｕａｌｉｔｙ ｅｎｈａｎｃｅｍｅｎｔ ｂｌｏｃｋｓ）の他のタイプのようなビデオプロセシングは、ビデオデコーダ２５０と３Ｄイメージフォーマッタ２６０との間に存在してもよい。

前述したように、本発明は、３Ｄビデオ処理機能を支援するＤＴＶ受信装置において、ＤＴＶ放送信号を介して伝送される３Ｄビデオ放送信号を処理し、３Ｄビデオデータを画面に出力するための機能を具現するためのものである。

そのために、ステレオスコピック３Ｄ放送信号の受信を支援するための、３Ｄサービス／イベントのための１つまたはそれ以上のデスクリプタを定義し、これを用いてステレオスコピック放送信号を受信し、ステレオスコピックディスプレイ出力を支援する方法を記述する。既存の地上波ＤＴＶ受信標準は、２Ｄビデオコンテンツを基準としており、特に、３ＤＴＶがサービスされる場合、３Ｄコーデックに対するデスクリプタが定義されなければならない。また、受信機は、このような変更された信号を適切に処理して、３Ｄ放送サービス受信及び出力を支援するようにしなければならない。

既存のＤＶＢ伝送と関連するＳＩ標準は、２Ｄビデオサービスに限定される。したがって、３ＤＴＶ信号、特に、ステレオスコピックビデオ信号を地上波ＤＴＶ放送チャネルを介して受信するためには、既存のＳＩ標準でステレオスコピックサービスをシグナリングできなければならず、これを効果的に処理するためには、ＤＴＶ受信機も、３Ｄ放送受信を支援するために新しい設計及び具現方法が適用されなければならない。

ＳＤＴのサービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）などにおいて３Ｄサービスを示すためのサービスタイプ（ｓｅｒｖｉｃｅ ｔｙｐｅ）を定義する。３Ｄサービス及びイベント（プログラム）に対する詳細情報を知らせるための３Ｄサービスデスクリプタを定義する。ＥＩＴを通じて３Ｄサービスを知らせるために、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔとｃｏｍｐｏｎｅｎｔ_ｔｙｐｅを通じて３Ｄを示すための方法を定義する。受信機が新たに定義された３Ｄシグナリングを処理し、２Ｄ／３Ｄサービス切替を円滑に行う方法を定義する。

以下では、本発明に係る３Ｄシグナリングと関連して、各レベル（ｌｅｖｅｌ）による様々なシグナリング方法について記述する。ここで、レベルは、例えば、サービス単位のサービスレベル、サービス内のコンテンツ、イベント単位であるコンテンツレベルなどを意味する。

ここで、本明細書では、本発明に係るシグナリング方法を記述するにおいて、主にデスクリプタ形式を用いる。ただし、これは例示に過ぎず、テーブルセクションの従来のフィールドの概念拡張や新しいフィールドの追加などでシグナリングしてもよい。

図３は、本発明に係るサービスリストデスクリプタ（ｓｅｒｖｉｃｅ ｌｉｓｔ ｄｅｓｃｒｉｐｔｏｒ）を含んだＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）セクションの一例に対するビットストリームシンタックスを示した図であり、図４は、本発明に係るサービスリストデスクリプタの一例に対するビットストリームシンタックスを示した図である。

ＮＩＴは、与えられたネットワークを介して伝送されるマルチプレックス／ＴＳのフィジカルオーガニゼイション（ｐｈｙｓｉｃａｌ ｏｒｇａｎｉｚａｔｉｏｎ）、及び前記ネットワーク自体の特性に関する情報を伝送する。ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄとｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄとの組み合わせは、本明細書のアプリケーションの領域を通じて唯一に識別されるように各ＴＳを許容する。ネットワークは、ネットワークのための唯一の識別コードとして提供される個別ｎｅｔｗｏｒｋ_ｉｄ値を割り当てる。ｎｅｔｗｏｒｋ_ｉｄとｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄは同一の値を有してもよく、またはｎｅｔｗｏｒｋ_ｉｄとｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄのための割り当てられた制限に拘束されるように異なる値を有してもよい。

受信機は、チャネル（チャネルホッピング（ｃｈａｎｎｅｌ ｈｏｐｉｎｇ））間の切り替え時のアクセスタイムが最小化されるように、不揮発性メモリにＮＩＴ情報を格納することができる。それは、実際のネットワークに加えて、他のネットワークを介してＮＩＴを伝送できるようにする。実際のネットワークのためのＮＩＴと他のネットワークのためのＮＩＴとの間の差別化は、異なるｔａｂｌｅ_ｉｄ値からなることができる。

ＮＩＴの部分を形成するあるセクションは、０ｘ００１０のＰＩＤ値を有するＴＳパケット内に伝送され得る。実際のネットワークを説明するＮＩＴのあるセクション（即ち、部分としてＮＩＴを含むＴＳのネットワーク）は、同じｔａｂｌｅ_ｉｄ_ｅｘｔｅｎｓｉｏｎ（ｎｅｔｗｏｒｋ_ｉｄ）を有したｔａｂｌｅ_ｉｄ ０ｘ４０を有することができる。ｎｅｔｗｏｒｋ_ｉｄフィールドは、実際のネットワークに対して割り当てられた値を取る。

以下、図３を参照して、ＮＩＴセクションの各フィールドに対して説明すると、次の通りである。

ｔａｂｌｅ_ｉｄフィールドは、予め定義された値によって、本テーブルセクションがＮＩＴセクションであることを示すことができる。ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは、“１”に設定されてもよい。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈは、１２−ビットフィールドであって、先頭の２ビットは００となる。それは直ちに始まり、次のｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドとＣＲＣを含め、セクションのバイトの数を説明し得る。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは１０２１を超えず、全セクションは、最大長さ１０２４バイトを有する。

ｎｅｔｗｏｒｋ_ｉｄフィールドは、他のあるデリバリーシステム（ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ）からＮＩＴインフォームに対するデリバリーシステムを識別するラベル（ｌａｂｅｌ）を与えることができる。ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは、ｓｕｂ_ｔａｂｌｅ内に伝送される情報の変更が発生すると、１ずつ増加し得る。その値が３１に到達すると、０にラップアラウンド（ｗｒａｐ ａｒｏｕｎｄ）される。ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが１に設定される場合、その後、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは現在のｓｕｂ_ｔａｂｌｅに適用可能であることを示し、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが０であれば、ｔａｂｌｅ_ｉｄとｎｅｔｗｏｒｋ_ｉｄによって定義される次のｓｕｂ_ｔａｂｌｅに適用可能である。

ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、セクションのナンバーを与えることができる。ｓｕｂ_ｔａｂｌｅ内の最初のセクションのｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、０ｘ００であってもよい。ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、同一のｔａｂｌｅ_ｉｄとｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄを有する各追加的なセクションと共に１ずつ増加するはずである。ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、本セクションの部分であって、ｓｕｂ_ｔａｂｌｅの最後のセクション（即ち、最も高いｓｅｃｔｉｏｎ_ｎｕｍｂｅｒを有するセクション）のナンバーを説明する。ｎｅｔｗｏｒｋ_ｄｅｓｃｒｉｐｔｏｒｓ_ｌｅｎｇｔｈフィールドは、次のネットワークデスクリプタのバイトで全長を与えることができる。ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｌｏｏｐ_ｌｅｎｇｔｈフィールドは、最初のＣＲＣ−３２バイトの以前に直ちにエンディングされる次のＴＳループのバイト単位の全長を説明し得る。ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄフィールドは、デリバリーシステム内の他のマルチプレックスからＥＩＴインフォームに対するＴＳの識別のためのラベルとして提供し得る。ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄフィールドは、オリジネイティングデリバリーシステムのｎｅｔｗｏｒｋ_ｉｄを識別するラベルを与えることができる。ｔｒａｎｓｐｏｒｔ_ｄｅｓｃｒｉｐｔｏｒｓ_ｌｅｎｇｔｈフィールドは、次のＴＳデスクリプタのバイトで全長を説明し得る。

ＣＲＣフィールドは、セクション全体をプロセシングした後に、デコーダでレジスタのゼロ出力を与えるＣＲＣ値を含むことができる。

図４を参照すると、サービスリストデスクリプタはＮＩＴのデスクリプタであって、これを用いることによって、全体的な３Ｄサービスの目録を把握することができる。

図４の本発明に係るサービスリストデスクリプタをより詳細に説明すると、次の通りである。

サービスリストデスクリプタは、ｓｅｒｖｉｃｅ_ｉｄとｓｅｒｖｉｃｅ_ｔｙｐｅによってサービスをリスティング（ｌｉｓｔｉｎｇ）する手段を提供する。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇの予め定義された値によって当該デスクリプタを識別することができる。ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは、本デスクリプタの全長に対する情報を提供する。

ｓｅｒｖｉｃｅ_ｉｄフィールドは、ＴＳ内のサービスを唯一に識別する。前記ｓｅｒｖｉｃｅ_ｉｄは、ｓｅｒｖｉｃｅ_ｔｙｐｅフィールドの値が０ｘ０４、０ｘ１８または０ｘ１Ｂ（ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅｓ）である場合を除いては、当該ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ_ｎｕｍｂｅｒと同一である。前記ｓｅｒｖｉｃｅ_ｉｄは、当該ｐｒｏｇｒａｍ_ｎｕｍｂｅｒを持たない。

ｓｅｒｖｉｃｅ_ｔｙｐｅフィールドは、サービスのタイプを説明することができる。サービスのためのｓｅｒｖｉｃｅ_ｔｙｐｅ値は、表１でより詳細に説明される。

上述したように、イメージディスプレイ装置は、図３のＮＩＴセクションをフィルタリングし、フィルタリングされたＮＩＴセクションに含まれた、本発明に係る図４のｓｅｒｖｉｃｅ_ｌｉｓｔ_ｄｅｓｃｒｉｐｔｏｒをパージングした後、ｓｅｒｖｉｃｅ_ｔｙｐｅフィールドが“ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ３ＤＴＶ”サービスであるｓｅｒｖｉｃｅ_ｉｄを把握し、３Ｄサービス（プログラム）目録のみを別に整理して出力することができる。

図５は、本発明に係るサービスデスクリプタ（ｓｅｒｖｉｃｅ_ｄｅｓｃｒｉｐｔｏｒ）を含んだＳＤＴ（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）セクションの一例に対するビットストリームシンタックスを示した図であり、図６は、本発明に係るサービスデスクリプタの一例に対するビットストリームシンタックスを示した図である。

ＳＤＴの各ｓｕｂ_ｔａｂｌｅは、特定のＴＳ内に含まれるサービスを説明する。前記サービスは、実際のＴＳまたは他のＴＳの部分であってもよい。これらは、ｔａｂｌｅ_ｉｄによって識別され得る。ＳＤＴの部分を形成するあるセクションは、０ｘ００１１のＰＩＤ値を有するＴＳパケットによって伝送され得る。実際のＴＳを説明するＳＤＴのあるセクションは、同一のｔａｂｌｅ_ｉｄ_ｅｘｔｅｎｓｉｏｎ（ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ）及び同一のｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄを有するｔａｂｌｅ_ｉｄ ０ｘ４２の値を有する。実際のＴＳと異なるＴＳを参照するＳＤＴの他のセクションは、ｔａｂｌｅ_ｉｄ値として０ｘ４６を有することができる。

以下、図５を参照して、ＳＤＴセクションの各フィールドに対して詳細に説明すると、次の通りである。

ｔａｂｌｅ_ｉｄフィールドは、予め定義された値によって、本テーブルセクションがＳＤＴセクションであることを示すことができる。ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは、“１”に設定されてもよい。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈは、１２−ビットのフィールドであって、先頭の２ビットは００となる。それは直ちに始まり、次のｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドとＣＲＣを含め、セクションのバイトの数を説明し得る。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは１０２１を超えず、全セクションは、最大長さ１０２４バイトを有する。

ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄフィールドは、デリバリーシステム内の他のマルチプレックスからＳＤＴインフォームに対するＴＳの識別のためのラベルとして提供し得る。

ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは、ｓｕｂ_ｔａｂｌｅ内に伝送される情報の変更が発生すると、１ずつ増加し得る。その値が３１に到達すると、０にラップアラウンド（ｗｒａｐ ａｒｏｕｎｄ）される。ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが１に設定されると、その後、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは現在のｓｕｂ_ｔａｂｌｅに適用可能であることを示し、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが０であれば、ｔａｂｌｅ_ｉｄとｎｅｔｗｏｒｋ_ｉｄによって定義される次のｓｕｂ_ｔａｂｌｅに適用可能である。

ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、セクションのナンバーを与えることができる。ｓｕｂ_ｔａｂｌｅ内の最初のセクションのｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、０ｘ００であってもよい。ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、同一のｔａｂｌｅ_ｉｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ及びｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄを有する各追加的なセクションと共に１ずつ増加するはずである。ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、本セクションの部分であって、ｓｕｂ_ｔａｂｌｅの最後のセクション（即ち、最も高いｓｅｃｔｉｏｎ_ｎｕｍｂｅｒを有するセクション）のナンバーを説明する。ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄフィールドは、オリジネイティングデリバリーシステム（ｏｒｉｇｉｎａｔｉｎｇ ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ）のｎｅｔｗｏｒｋ_ｉｄを識別するラベルを与えることができる。Ｓｅｒｖｉｃｅ_ｉｄは、１６−ビットのフィールドであって、ＴＳ内の他のサービスから本サービスを識別するためのラベルとして提供される。前記ｓｅｒｖｉｃｅ_ｉｄは、当該ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ_ｎｕｍｂｅｒと同一であってもよい。

ＥＩＴ_ｓｃｈｅｄｕｌｅ_ｆｌａｇは、１−ビットのフィールドであって、１に設定される場合、サービスのためのＥＩＴスケジュール情報が現在のＴＳ内に存在することを示し、フラグが０であれば、サービスのためのＥＩＴスケジュール情報が現在のＴＳ内に存在しないことを示す。ＥＩＴ_ｐｒｅｓｅｎｔ_ｆｏｌｌｏｗｉｎｇ_ｆｌａｇは、１−ビットのフィールドであって、１に設定される場合、現在のＴＳ内にサービスのためのＥＩＴ_ｐｒｅｓｅｎｔ_ｆｏｌｌｏｗｉｎｇ情報が存在することを示し、ＥＩＴ現在／次のｓｕｂ_ｔａｂｌｅの発生間に最大タイムインターバルに関する情報のためのものである。前記フラグが０であれば、ＴＳ内にサービスのためのＥＩＴ現在／次のｓｕｂ_ｔａｂｌｅが存在しない。

ｒｕｎｎｉｎｇ_ｓｔａｔｕｓは、３−ビットのフィールドであって、サービスの状態を示すことができる。ＮＶＯＤレファレンスイベントのために、ｒｕｎｎｉｎｇ_ｓｔａｔｕｓの値は０に設定されてもよい。ｆｒｅｅ_ＣＡ_ｍｏｄｅは、１−ビットのフィールドであって、０に設定されると、イベントの全てのコンポーネントストリームはスクランブルされない。１に設定される場合、１つまたはそれ以上のストリームはＣＡシステムによって制御される。ｄｅｓｃｒｉｐｔｏｒｓ_ｌｏｏｐ_ｌｅｎｇｔｈフィールドは、次のデスクリプタのバイトで全長を与えることができる。

ＣＲＣフィールドは、セクション全体をプロセシングした後に、デコーダでレジスタのゼロ出力を与えるＣＲＣ値を含むことができる。

図６を参照すると、サービスデスクリプタは、ＳＤＴのデスクリプタであって、ＳＤＴの特定のｓｅｒｖｉｃｅ_ｉｄに対する、３Ｄであるか否かを判断するためには、サービスデスクリプタ内に含まれたｓｅｒｖｉｃｅ_ｔｙｐｅフィールドを用いる。また、サービスデスクリプタを用いることによって、当該３Ｄサービスのデコーディング及び出力可能であるか否かも判断することができる。

以下、図６の本発明に係るサービスデスクリプタをより詳細に説明すると、次の通りである。

サービスデスクリプタは、ｓｅｒｖｉｃｅ_ｔｙｐｅと共に、テキストフォームでサービスとサービスプロバイダーのネームを提供する。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇの予め定義された値によって当該デスクリプタを識別することができる。ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは、本デスクリプタの全長に対する情報を提供する。

ｓｅｒｖｉｃｅ_ｔｙｐｅフィールドは、サービスのタイプを説明することができる。サービスのためのｓｅｒｖｉｃｅ_ｔｙｐｅの割当は、表１で説明される。

あるサービスのために、表１からｓｅｒｖｉｃｅ_ｔｙｐｅの割当は自明である。例えば、ＭＰＥＧ−２ＨＤデジタルテレビサービスを挙げることができる。しかし、決定は常にストレートフォワードに行われるものではない。

また、ｓｅｒｖｉｃｅ_ｔｙｐｅの値が０ｘ０１である場合、デジタルテレビ受信機を示す。ジェネリックケース（ｇｅｎｅｒｉｃ ｃａｓｅ）において、このようなｓｅｒｖｉｃｅ_ｔｙｐｅは、エンコーディングされるサービスのコンポーネントのための方法に対する受信機で明示的なインディケーション（ｉｎｄｉｃａｔｉｏｎ）を提供しない。もちろん、特定のプラットホームの場合には、特定のエンコーディングは、受信機に参照される本ｓｅｒｖｉｃｅ_ｔｙｐｅに暗示的にリンクされることはある。しかし、そのようなアレンジメント（ａｒｒａｎｇｅｍｅｎｔ）は、本明細書の範囲を逸脱する。本ｓｅｒｖｉｃｅ_ｔｙｐｅは、ＭＰＥＧ−２ ＳＤデジタルテレビサービスのために用いられてもよい。しかし、それは、例えば、ＭＰＥＧ−２ ＨＤデジタルテレビサービスのような、特定のエントリーを有するエンコーディングを含んだ他のエンコーディングを用いたサービスのために使用されてもよい。

ＤＶＢは、他の（ｎｏｎ−ＭＰＥＧ−２ ＳＤ）エンコーディングのコンテクスト（ｃｏｎｔｅｘｔ）内に既に存在し、利用中であるので、ＭＰＥＧ−２ ＳＤデジタルテレビサービスにデジタルテレビサービスからｓｅｒｖｉｃｅ_ｔｙｐｅの定義を変えない。一例として、全ての受信機は、ＭＰＥＧ−２ ＳＤエンコーディングされたマテリアル（ｍａｔｅｒｉａｌ）をデコーディングし、出力し得る。全ての受信機は、それがＭＰＥＧ−２ ＳＤコーディングされたマテリアルであることに基づいて、ユーザの選択のためにｓｅｒｖｉｃｅ_ｔｙｐｅをあるサービスに割り当て、出力し得る。しかし、上述したように、これは、受信機が実際エンコーディングを利用することを支持するものでない。受信機の無能力は、それが達成しようとするユーザの経験に基づいてケア（ｃａｒｅ）されるように割り当てるサービス提供者が必要とするｓｅｒｖｉｃｅ_ｔｙｐｅ手段が、割り当てられたサービスをデコーディングし、出力できるか否かによって決定される。

例えば、ＭＰＥＧ−２ ＳＤエンコーディングと異なるものに基づいた、あるサービスに関するプラットホームを考慮してみよう。それらの全てはＭＰＥＧ−２ ＳＤ−ｏｎｌｙとＭＰＥＧ−２ ＳＤ／ＨＤ受信機の混合されたポピュレーション（ｐｏｐｕｌａｔｉｏｎ）を伝達する。ＭＰＥＧ−２ ＳＤエンコーディングに基づいたサービスのために、ｓｅｒｖｉｃｅ_ｔｙｐｅの０ｘ０１（デジタルテレビサービス）の割当は自明である。しかし、ＭＰＥＧ−２ ＨＤエンコーディングに基づいたサービスのために、たとえ、それらが選択されると実際に見られなくても、ｓｅｒｖｉｃｅ_ｔｙｐｅの割当は、サービス提供者ＭＰＥＧ−２ ＳＤ−ｏｎｌｙ受信機のユーザに提示したどのサービスリストに含まれたサービスを望むかによる。

もし、所望のユーザ経験があれば、サービスは、ｓｅｒｖｉｃｅ_ｔｙｐｅを０ｘ０１（デジタルテレビサービス）として割り当てる。しかし、所望のユーザ経験が、単にＭＰＥＧ−２ ＳＤ−ｏｎｌｙ受信機のユーザに割り当てられたサービスであれば、受信機は実際に見られ、サービスは、ｓｅｒｖｉｃｅ_ｔｙｐｅが０ｘ１１（ＭＰＥＧ−２ ＨＤデジタルテレビサービス）として割り当てられる。このようなｓｅｒｖｉｃｅ_ｔｙｐｅは、サービスとして割り当てられ、前記サービスは、ＭＰＥＧ−２ ＳＤエンコーディングと同一のマテリアルに対するＭＰＥＧ−４ ＨＤのような代替エンコーディングを両方とも含む。このような仮定は合理的であり、全ての受信機は、ＭＰＥＧ−２ ＳＤエンコーディングされたマテリアルをデコーディングし、提示することができる。したがって、ユーザに、少なくともＭＰＥＧ−２ ＳＤコーディングされたフォームで提示され得る。しかし、使用時に受信機の能力に依存すれば、ユーザに代替、典型的なスーペリア（ｓｕｐｅｒｉｏｒ）、コーディングされたフォームで提示され得る。他のエンコーディングのために使用されるコンポーネントは、ＰＳＩ内のｓｔｒｅａｍ_ｔｙｐｅのために割り当てられた値によるデコーディングの観点、及び／又はＳＩ内のコンポーネントデスクリプタの利用間に差別化され得る。

また、ｓｅｒｖｉｃｅ_ｔｙｐｅの値は、アドバンスドコーデック（ａｄｖａｎｃｅｄ ｃｏｄｅｃ）を示すことができる。前記アドバンスドコーデックｓｅｒｖｉｃｅ_ｔｙｐｅは、サービスがＭＰＥＧ−２ではなく、他のものを用いてエンコーディングされたことを示すことができる。より詳細には、このようなｓｅｒｖｉｃｅ_ｔｙｐｅのうちの１つの割当は、受信機は、前記サービスをデコーディングし、提示できるように、ＭＰＥＧ−２以外のコーデックを支援しなければならない。これに基づいて、ＭＰＥＧ−２ ＳＤ−ｏｎｌｙ受信機は、ユーザの選択のためのｓｅｒｖｉｃｅ_ｔｙｐｅのうちの１つが割り当てられたサービスを出力できないことがある。このようなｓｅｒｖｉｃｅ_ｔｙｐｅのうちの１つの割当は、特別ではないアドバンスドコーデックの使用のためのジェネリックインディケーション（ｇｅｎｅｒｉｃ ｉｎｄｉｃａｔｉｏｎ）を提供する。それは、受信機が、このようなｓｅｒｖｉｃｅ_ｔｙｐｅのうちの１つが割り当てられたサービスをデコーディングし、出力できるように決定するように許諾されない。もちろん、特定のプラットホームの場合に、特定のエンコーディングは、ｓｅｒｖｉｃｅ_ｔｙｐｅの１つと暗示的にリンクされ、受信機によって参照される。しかし、そのようなアレンジメントは、本明細書の範囲を逸脱する。サービスは、アドバンスドコーデックｓｅｒｖｉｃｅ_ｔｙｐｅのために割り当てられた場合、コンポーネントデスクリプタはＳＩ内に用いられ、これは、使用された特定のアドバンスドコーデックを示すためである。これは、受信機に適切にハンドルすることができ、サービスをデコーディングし、出力するようにするか否かを混同なしに決定するように許諾する。

また、ｓｅｒｖｉｃｅ_ｔｙｐｅの値は、アドバンスドコーデックフレームコンパチブルステレオスコピックＨＤを示すことができる。前記フレームコンパチブルステレオスコピックＨＤ値は、ブロードキャスタ（ｂｒｏａｄｃａｓｔｅｒ）にサービスが（主に）ステレオスコピックサービスとして動作するようにシグナリングを許諾する。このような値の利用は、レガシー受信機ポピュレーション（ｌｅｇａｃｙ ｒｅｃｅｉｖｅｒ ｐｏｐｕｌａｔｉｏｎｓ）のための結果を注意深く考慮することが要求される。ここで、レガシー受信機ポピュレーションは、結果的にこのようなサービスを無視する。したがって、ブロードキャスタは、ノーマルＨＤサービスとしてフレームコンパチブルステレオスコピックサービスをシグナリングするように代わりに選択し、サービス（またはイベント）がフレームコンパチブルステレオスコピックフォーマット内であることを示すように代替シグナリングに用いられる。ｓｅｒｖｉｃｅ_ｐｒｏｖｉｄｅｒ_ｎａｍｅ_ｌｅｎｇｔｈフィールドは、サービス提供者のネームのキャラクターを説明する次のｓｅｒｖｉｃｅ_ｐｒｏｖｉｄｅｒ_ｎａｍｅ_ｌｅｎｇｔｈフィールドのバイトの数を説明する。Ｃｈａｒは８−ビットである。Ｃｈａｒフィールドのストリングは、サービス提供者またはサービスのネームを説明する。テキスト情報は、キャラクターセット及び方法を用いてコーディングされる。Ｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈフィールドは、サービスのネイムのキャラクターを説明する次のｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈフィールドのバイトの数を説明する。

図７及び図８は、本発明に係るサービスデスクリプタを含んだＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）セクション及びＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）セクションの一例に対するビットストリームシンタックスを示した図であり、図９は、本発明に係る３Ｄサービスデスクリプタの一例に対するビットストリームシンタックスを示した図である。

ＰＭＴは、プログラムナンバーと、それらを含むプログラムエレメント（ｐｒｏｇｒａｍ ｅｌｅｍｅｎｔｓ）との間でマッピング（ｍａｐｐｉｎｇ）を提供することができる。そのようなマッピングのシングルインスタンス（ｓｉｎｇｌｅ ｉｎｓｔａｎｃｅ）は、プログラムデフィニション（ｐｒｏｇｒａｍ ｄｅｆｉｎｉｔｉｏｎ）として参照され得る。ＰＭＴは、ＴＳのための全てのプログラムデフィニションの完全なコレクション（ｃｏｌｌｅｃｔｉｏｎ）である。このようなテーブルはパケットで伝送され、ＰＩＤ値は、エンコーダによって選択される。セクションは、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒフィールドによって識別される。

以下、図７を参照して、ＰＭＴセクションの各フィールドに対して詳細に説明すると、次の通りである。

ｔａｂｌｅ_ｉｄフィールドは、予め定義された値によって、本テーブルセクションがＮＩＴセクションであることを示すことができる。ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは、“１”に設定されてもよい。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈは、１２−ビットのフィールドであって、先頭の２ビットは００であり、残りの１０ビットは直ちに始まり、次のｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドとＣＲＣを含め、セクションのバイトの数を説明し得る。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは、１０２１（０ｘ３ＦＤ）を超えない。

ｐｒｏｇｒａｍ_ｎｕｍｂｅｒフィールドは、適用可能なｐｒｏｇｒａｍ_ｍａｐ_ＰＩＤのプログラムを説明する。１つのプログラムデフィニション（ｐｒｏｇｒａｍ ｄｅｆｉｎｉｔｉｏｎ）は、単に１つのＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ内に伝送される。これは、１つのプログラムデフィニションは、１０１６（０ｘ３Ｆ８）よりも長くないという意味である。Ｐｒｏｇｒａｍ_ｎｕｍｂｅｒは、例えば、放送チャネルのためのデジグネーション（ｄｅｓｉｇｎａｔｉｏｎ）として用いられてもよい。プログラムに属する異なるプログラムエレメントを説明することによって、異なるソースから得たデータ（例えば、シーケンシャルイベント）は、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒを用いてストリームの連続的なセットを共に形成するようにｃｏｎｃａｔｅｎａｔｅｄされる。ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは、ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎのバージョンナンバーであってもよい。このバージョンナンバーは、セクション内に伝送される情報の変更が発生する場合、１モジュールずつ３２に増加する。バージョンナンバーは、シングルプログラムのデフィニションを参照し、したがって、シングルセクションに関するものである。ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが１に設定される場合、その後、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは、現在のＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎに適用可能であることを示し、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが０である場合、ｔａｂｌｅ_ｉｄとｎｅｔｗｏｒｋ_ｉｄによって定義される次のＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎに適用可能である。

ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、０ｘ００であり得る。ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは０ｘ００である。ＰＣＲ_ＰＩＤフィールドは、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒによって説明されるプログラムのための有効なＰＣＲフィールドを含むＴＳパケットのＰＩＤを示す。プライベートストリーム（ｐｒｉｖａｔｅ ｓｔｒｅａｍｓ）のためのプログラムデフィニションと関連するＰＣＲがない場合、本フィールドは０ｘ１ＦＦＦの値を有する。ｐｒｏｇｒａｍ_ｉｎｆｏ_ｌｅｎｇｔｈは１２−ビットのフィールドである。先頭の２ビットは００であり、残りの１０ビットは直後のｐｒｏｇｒａｍ_ｉｎｆｏ_ｌｅｎｇｔｈフィールドのデスクリプタのバイトナンバーを説明する。

ｓｔｒｅａｍ_ｔｙｐｅは、８−ビットのフィールドであって、ｅｌｅｍｅｎｔａｒｙ_ＰＩＤによって説明される値のＰＩＤを有するパケット内に伝送されるプログラムエレメントのタイプを説明する。補助ストリームは、オーディオ、ビデオ、そして、ＤＳＭ−ＣＣよりも、プログラムストリームディレクトリ及びプログラムストリームマップのような、本明細書によって定義されるデータタイプを利用可能である。Ｅｌｅｍｅｎｔａｒｙ_ＰＩＤは、１３−ビットのフィールドであって、関連するプログラムエレメントを伝送するＴＳパケットのＰＩＤを説明する。ＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈは、１２−ビットのフィールドであって、先頭の２ビットは００であり、残りの１０ビットは、直後のＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈフィールドと関連するプログラムエレメントのデスクリプタのバイトの数を説明する。

ＣＲＣフィールドは、ＴＳプログラムマップセクション全体をプロセシングした後に、デコーダでレジスタのゼロ出力を与えるＣＲＣ値を含むことができる。

ＥＩＴは、各サービス内に含まれるイベントに対するクロニクルオーダー内の情報を提供することができる。実際のＴＳのための全てのＥＩＴ ｓｕｂ−ｔａｂｌｅは、同一のｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ及びｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ値を有する。現在／次のテーブルは、２つのイベントディスクリプションよりもさらに有したＮＶＯＤレファレンスサービスの場合を除いて、実際のＴＳまたは他のＴＳ上の与えられたサービスによって伝送される現在イベント及び年代記的な次のイベントを持続する情報を含むことができる。実際のＴＳまたは他のＴＳのためのイベントスケジュールテーブルは、スケジュールフォーム内にイベントのリストを含むことができる。すなわち、前記スケジュールは、次のイベントなしに所定の時間に発生するイベントを含む。イベント情報は、年代記的にオーダーされ得る。ＥＩＴの部分を形成するあるセクションは、０ｘ００１２のＰＩＤ値を有するＴＳパケット内に伝送され得る。

以下、図８を参照して、ＥＩＴセクションの各フィールドに対して詳細に説明すると、次の通りである。

ｔａｂｌｅ_ｉｄフィールドは、予め定義された値によって、本テーブルセクションがＥＩＴセクションであることを示すことができる。ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒフィールドは、“１”に設定されてもよい。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは、直ちに始まり、次のｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドとＣＲＣを含め、セクションのバイトの数を説明し得る。ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈフィールドは４０９３を超えず、セクション全体は、最大長さ４０９６バイトを有する。

ｓｅｒｖｉｃｅ_ｉｄフィールドは、ＴＳ内の他のサービスから本サービスを識別するようにラベルとして提供することができる。ｓｅｒｖｉｃｅ_ｉｄは、当該ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ_ｎｕｍｂｅｒと同一であってもよい。ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒフィールドは、ｓｕｂ_ｔａｂｌｅのバージョンナンバーである。前記ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは、ｓｕｂ_ｔａｂｌｅ内に伝送される情報の変更が発生する場合、１ずつ増加し得る。その値が３１に到達すると、０にラップアラウンド（ｗｒａｐ ａｒｏｕｎｄ）される。ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが１に設定される場合、その後、ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒは現在のｓｕｂ_ｔａｂｌｅに適用可能であることを示し、ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒが０である場合、次のｓｕｂ_ｔａｂｌｅに適用可能である。

ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、セクションのナンバーを与えることができる。ｓｕｂ_ｔａｂｌｅ内の最初のセクションのｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは０ｘ００であってもよい。ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、同一のｔａｂｌｅ_ｉｄ、ｓｅｒｖｉｃｅ_ｉｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ、そして、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄを有する各追加的なセクションと共に１ずつ増加するはずである。この場合、前記ｓｕｂ_ｔａｂｌｅは、セグメントのナンバーとして構造化されてもよい。各セグメント内のｓｅｃｔｉｏｎ_ｎｕｍｂｅｒは、各追加的なセクションと共に１ずつ増加し、ナンバリングにおけるギャップは、セグメントの最後のセクションと、隣接するセグメントの最初のセクションとの間で許容される。ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、本セクションの部分であって、ｓｕｂ_ｔａｂｌｅの最後のセクション（即ち、最も高いｓｅｃｔｉｏｎ_ｎｕｍｂｅｒを持つセクション）のナンバーを説明する。

ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄフィールドは、デリバリーシステム内の他のマルチプレックスからＥＩＴインフォームに対するＴＳの識別のためのラベルとして提供することができる。ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄフィールドは、オリジネイティングデリバリーシステムのｎｅｔｗｏｒｋ_ｉｄを識別するラベルを与えることができる。ｓｅｇｍｅｎｔ_ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドは、ｓｕｂ_ｔａｂｌｅの本セグメントの最も最後のセクションのナンバーを説明し得る。セグメント化されていないｓｕｂ_ｔａｂｌｅのために、本フィールドは、ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒフィールドと同じ値に設定されてもよい。ｌａｓｔ_ｔａｂｌｅ_ｉｄフィールドは、利用された最も最後のｔａｂｌｅ_ｉｄを識別することができる。ｅｖｅｎｔ_ｉｄフィールドは、説明されたイベント（サービス定義内にユニークに割り当てられた）の識別ナンバーを含むことができる。

ｓｔａｒｔ_ｔｉｍｅフィールドは、ＵＴＣ（Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ、Ｃｏ−ｏｒｄｉｎａｔｅｄ）及びＭＪＤ（Ｍｏｄｉｆｉｅｄ Ｊｕｌｉａｎ Ｄａｔｅ）内イベントの開始時刻を含むことができる。本フィールドは、４−ビットのＢＣＤ（Ｂｉｎａｒｙ Ｃｏｄｅｄ Ｄｅｃｉｍａｌ）内６ディジットにコーディングされた２４ビットによって、続くＭＪＤの１６ ＬＳＢを与える１６ビットにコーディングされる。ｓｔａｒｔ_ｔｉｍｅが定義されない場合（例えば、ＮＶＯＤレファレンスサービス内のイベントのために）、フィールドの全てのビットは１に設定されてもよい。例えば、９３／１０／１３ １２：４５：００は、“０ｘＣ０７９１２４５００”にコーディングされる。Ｄｕｒａｔｉｏｎフィールドは、時間、分、及び秒でイベントのデュレーションを含む。フォーマットは、６ディジット、４−ビットのＢＣＤ、すなわち、２４ビットである。例えば、０１：４５：３０は、“０ｘ０１４５３０”にコーディングされる。

ｒｕｎｎｉｎｇ_ｓｔａｔｕｓフィールドは、イベントの状態を示すことができる。ＮＶＯＤレファレンスイベントのために、ｒｕｎｎｉｎｇ_ｓｔａｔｕｓの値は０に設定されてもよい。ｆｒｅｅ_ＣＡ_ｍｏｄｅは、１−ビットのフィールドであって、０に設定される場合、イベントの全てのコンポーネントストリームはスクランブルされない。１に設定される場合、１つまたはそれ以上のストリームはＣＡシステムによって制御される。ｄｅｓｃｒｉｐｔｏｒｓ_ｌｏｏｐ_ｌｅｎｇｔｈフィールドは、次のデスクリプタのバイトで全長を与えることができる。ＣＲＣフィールドは、プライベートセクション全体をプロセシングした後に、デコーダでレジスタのゼロ出力を与えるＣＲＣ値を含むことができる。

図９を参照すると、本発明に係る３Ｄサービスデスクリプタは、前述した図５のＳＤＴや図７のＰＭＴに含まれてもよい。イメージディスプレイ装置では、例えば、３Ｄサービスデスクリプタが、前記ＳＤＴまたはＰＭＴ内の特定のサービスまたはプログラムに含まれる場合、当該サービスまたはプログラムは３Ｄであることを知ることができる。なお、３Ｄサービスデスクリプタに含まれた情報を用いて、３Ｄビデオフォーマット情報などを把握することができる。また、ＥＩＴに含まれた３Ｄサービスデスクリプタを用いて、予め特定のイベントに対する３Ｄであるか否かを知ることができる。

３Ｄサービスデスクリプタは、３Ｄサービス／プログラムに関する詳細情報を含み、ＰＭＴまたはＳＤＴに位置する。（ＥＩＴに位置してもよく、この場合には、アナウンスされるプログラム／イベントに対する３Ｄ情報を示す。）

３Ｄサービスデスクリプタは、ｓｅｒｖｉｃｅ_ｔｙｐｅが“ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ３ＤＴＶ”である場合、またはイベントに対するｓｔｒｅａｍ_ｃｏｎｔｅｎｔ及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが“ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ３Ｄ”である場合に存在し、次のようなフィールドを含む。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇの予め定義された値によって、当該デスクリプタを識別することができる。ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは、本デスクリプタの全長に対する情報を提供する。

３Ｄ_ｓｔｒｕｃｔｕｒｅフィールドは、３Ｄプログラムのビデオフォーマットを示し、例えば、表２のように定義されてもよい。

表２を参照すると、例えば、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が００００であれば、フルレゾリューション左＆右（ｆｕｌｌ ｒｅｓｏｌｕｔｉｏｎ Ｌｅｆｔ ＆ Ｒｉｇｈｔ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が０００１であれば、フィールドオルターナティブ（ｆｉｅｌｄ ａｌｔｅｒｎａｔｉｖｅ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が００１０であれば、ラインオルターナティブ（ｌｉｎｅ ａｌｔｅｒｎａｔｉｖｅ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が０１００であれば、左映像＋デプス（Ｌ＋ｄｅｐｔｈ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が０１１０であれば、トップ−アンド−ボトム（ＴａＢ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が０１１１であれば、フレームシーケンシャル（Ｆｒａｍｅ ｓｅｑｕｅｎｔｉａｌ）を意味し、３Ｄ_ｓｔｒｕｃｔｕｒｅフィールド値が１０００であれば、サイド−バイ−サイド（ＳｂＳ）を意味するものと定義することができる。ただし、前記表２に示したフィールド値及び意味は一例であって、前記の値及び意味に限定されるものではない。

３Ｄ_ｍｅｔａｄａｔａ_ｌｏｃａｔｉｏｎ_ｆｌａｇフィールドの値が‘０１’である場合、３Ｄサービスデスクリプタ内に３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅ、３Ｄ_ｍｅｔａｄａｔａ_ｌｅｎｇｔｈ、３Ｄ_ｍｅｔａｄａｔａフィールドなどがさらに存在する。‘００’である場合には、当該データを伝送せず、‘１０’である場合には、３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅ、３Ｄ_ｍｅｔａｄａｔａ_ｌｅｎｇｔｈ、３Ｄ_ｍｅｔａｄａｔａフィールドなどをビデオ領域で伝送する。

３Ｄ_ｓａｍｐｌｉｎｇフィールドは、３Ｄプログラムのフレーム−コンパチブルフォーマットに対する情報を知らせ、例えば、表３のように定義することができる。

また、本フィールドの説明は、図１０乃至図１２を参照して説明する。ここで、図１０（ａ）、図１１（ａ）及び図１２（ａ）は奇数ポジション（ｏｄｄ ｐｏｓｉｔｉｏｎ）、図１０（ｂ）、図１１（ｂ）、及び図１２（ｂ）は偶数ポジション（ｅｖｅｎ ｐｏｓｉｔｉｏｎ）を意味する。

図１０及び図１１を参照すると、例えば、３Ｄ_ｓａｍｐｌｉｎｇフィールド値が００００−００１１である場合には、サブ−サンプリング（ｓｕｂ−ｓａｍｐｌｉｎｇ）を意味する。より詳細に説明すると、３Ｄ_ｓａｍｐｌｉｎｇフィールド値が００００である場合には、サブ−サンプリング（ｓｕｂ−ｓａｍｐｌｉｎｇ）に関するもので、特に、奇数レフト（Ｌ）、そして奇数ライト（Ｒ）を意味し、０００１である場合には、サブ−サンプリング（ｓｕｂ−ｓａｍｐｌｉｎｇ）に関するもので、特に、奇数レフト（Ｌ）、そして偶数ライト（Ｒ）を意味し、００１０である場合には、サブ−サンプリングに関するもので、特に偶数レフト（Ｌ）、そして奇数ライト（Ｒ）を意味し、００１１である場合には、サブ−サンプリング（ｓｕｂ−ｓａｍｐｌｉｎｇ）に関するもので、特に偶数レフト（Ｌ）、そして偶数ライト（Ｒ）を意味する。

また、図１２を参照すると、３Ｄ_ｓａｍｐｌｉｎｇフィールド値が０１００−０１１１であるい場合には、クインカンクスマトリクス（ｑｕｉｎｃｕｎｘ ｍａｔｒｉｘ）を意味する。例えば、３Ｄ_ｓａｍｐｌｉｎｇフィールド値が０１００である場合には、クインカンクスマトリクスに関するもので、特に、奇数レフト（Ｌ）、そして奇数ライト（Ｒ）を意味し、０１０１である場合には、クインカンクスマトリクスに関するもので、特に、奇数レフト（Ｌ）、そして偶数ライト（Ｒ）を意味し、０１１０である場合には、クインカンクスマトリクスに関するもので、特に偶数レフト（Ｌ）、そして奇数ライト（Ｒ）を意味し、０１１１である場合には、クインカンクスマトリクスに関するもので、特に偶数レフト（Ｌ）、そして偶数ライト（Ｒ）を意味する。また、上記では、３ＤビデオフォーマットがＳｂＳである場合を例示して説明するが、同様の方式でＴａＢとして定義してもよく、前記の例示に付加的に定義されてもよい。

３Ｄ_ｏｒｉｅｎｔａｔｉｏｎフィールドは、３Ｄプログラム内のレフト及びライトビューイメージデータの画素配列の形態を知らせ、例えば、表４のように定義することができる。

表４を参照すると、３Ｄ_ｏｒｉｅｎｔａｔｉｏｎフィールド値が００であれば、ビデオの３Ｄオリエンテーションは、レフトピクチャ及びライトピクチャの両方ともインバートされずに正常な（ｎｏｒｍａｌ）場合を意味し、０１であれば、ビデオの３Ｄオリエンテーションは、ライトピクチャのみがインバートされた場合を意味し、１０であれば、ビデオの３Ｄオリエンテーションは、レフトピクチャのみがインバートされた場合を意味し、１１であれば、ビデオの３Ｄオリエンテーションは、レフト及びライトの両方がインバートされた場合を意味することができる。

３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅフィールドは、３Ｄ_ｍｅｔａｄａｔａ_ｅｘｉｓｔ_ｆｌａｇが‘１’であるときに有効なフィールドであり、このフィールドを用いて、３Ｄ_ｍｅｔａｄａｔａ_ｌｅｎｇｔｈ及び３Ｄ_ｍｅｔａｄａｔａが表５のように定義され得る。

３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅフィールドの値が０００である場合には、３Ｄ_ｍｅｔａｄａｔａ_ｌｅｎｇｔｈは４であり、３Ｄ_ｍｅｔａｄａｔａは、４つの値のうちの少なくとも１つを有するか、または４つの全ての値を有してもよい。前記４つの値において、３Ｄ_ｍｅｔａｔｄａｔ［０］はｐａｒａｌｌａｘ_ｚｅｒｏ、３Ｄ_ｍｅｔａｔｄａｔ［１］はｐａｒａｌｌａｘ_ｓｃａｌｅ、３Ｄ_ｍｅｔａｔｄａｔ［２」はＤｒｅｆ、そして、３Ｄ_ｍｅｔａｔｄａｔ［３］はＷｒｅｆを意味する。これとは異なり、３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅフィールドの値が００１である場合には、３Ｄ_ｍｅｔａｄａｔａ_ｌｅｎｇｔｈも４であり、３Ｄ_ｍｅｔａｄａｔａは、４つの値のうちの少なくとも１つを有するか、または４つの全ての値を有してもよい。前記４つの値において、３Ｄ_ｍｅｔａｔｄａｔ［０］はｘＢ、３Ｄ_ｍｅｔａｔｄａｔ［１］はＺｒｅｆ、３Ｄ_ｍｅｔａｔｄａｔ［２」はＤｒｅｆ、そして、３Ｄ_ｍｅｔａｔｄａｔ［３］はＷｒｅｆを意味する。

これと関連して、表５によるパラメータは、３Ｄコンテンツを製作する過程で意図された環境値であって、受信機において、これらを用いて、製作者が意図した立体感を再現するのに使用される。各パラメータは、デプスマップ（Ｄｅｐｔｈ ｍａｐ）のようにパララックスマップ（ｐａｒａｌｌａｘ ｍａｐ）を伝送する場合、各パララックス（ｐａｒａｌｌａｘ）を正確に解釈するためのデータである。言い換えると、パララックスマップを受信すると、各値に対してレファレンス（ｒｅｆｅｒｅｎｃｅ）値及び現在の視聴環境を考慮して変換されたパララックス値を適用し、新しい視点に対する映像を作る。

Ｄｒｅｆパラメータは、３Ｄコンテンツの製作過程においてレファレンスとして定義した視聴者と画面との間の距離である（単位：ｃｍ）。Ｗｒｅｆパラメータは、３Ｄコンテンツの製作過程においてレファレンスとして定義した画面の横サイズである（単位：ｃｍ）。Ｚｒｅｆパラメータは、３Ｄコンテンツの製作過程においてレファレンスとして定義したデプス（ｄｅｐｔｈ）値である（単位：ｃｍ）。ｘＢパラメータは、レファレンスとして定義した視聴者の両眼間の距離（基準値は、６５ｍｍ）である。

レファレンスパララックスＰｒｅｆを数式１を用いて計算する（パララックスマップの各値は、Ｎ−ｂｉｔで表現されると仮定する）。

実際のスクリーン上でのＦａｒｒｅｌｌレックスは、数式２のように計算される（数式の誘導は、ＩＳＯ２３００２−３を参照）。

数式２において、ＤとＷは、受信機と視聴者との距離及び画面の横サイズを意味する。３Ｄ_ｍｅｔａｄａｔａ_ｔｙｐｅが０００である場合には、ｘＢパラメータが伝送されず、このときには、６５ｍｍという値として仮定し、計算する。

図１３は、本発明に係るコンポーネントデスクリプタ（ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）のビットストリームシンタックスの一例を示した図である。

ここで、図１３のコンポーネントデスクリプタは、例えば、図５のＳＤＴのデスクリプタとして定義されることによって、当該サービスが３Ｄであるか否かを判断することができ、図８のＥＩＴのデスクリプタとして定義されることによって、当該イベントが３Ｄであるか否かを判断することもできる。

コンポーネントデスクリプタは、コンポーネントストリームのタイプを識別し、エレメンタリーストリームのテキストディスクリプション（ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）を提供するのに使用することができる。

以下、図１３を参照して、コンポーネントデスクリプタの各フィールドについてより詳細に説明すると、次の通りである。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇフィールドは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇの予め定義された値によって、当該デスクリプタを識別することができる。ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈフィールドは、本デスクリプタの全長に関する情報を提供する。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔフィールドは、ストリームのタイプ（ビデオ、オーディオ、又はＥＢＵ−データ）を説明することができる。本フィールドのコーディングはテーブルに説明される。Ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅフィールドは、ビデオ、オーディオ、またはＥＢＵ−ｄａｔａコンポーネントのタイプを説明する。

ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは、コンポーネントストリームのためのストリーム識別子デスクリプタ（ＰＳＩプログラムマップセクション内に存在すれば）内のｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドと同一の値を有する。

ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅフィールドは、コンポーネント（オーディオまたはＥＢＵ−データの場合）のランゲージ（ｌａｎｇｕａｇｅ）を識別し、本デスクリプタ内に含まれるテキストディスクリプションを識別する。ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅフィールドは、ＩＳＯ−６３９−２に説明される３−キャラクターコードを含むことができる。各キャラクターは、８ビットにコーディングされ、２４−ビットのフィールドに挿入される。例えば、フレンチは、３−キャラクターコードが“ｆｒｅ”、”０１１００１１００１１１００１００１１００１０１”にコーディングされる。

Ｔｅｘｔ_ｃｈａｒフィールドは、コンポーネントストリームのテキストディスクリプションを説明するストリングを有することができる。テキスト情報は、キャラクターセット及び方法を用いてコーディングされる。

特に、図１３のコンポーネントデスクリプタ内のｓｔｒｅａｍ_ｃｏｎｔｅｎｔフィールド及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅフィールドを表６のように定義することによって、イメージディスプレイ装置は、本コンポーネントデスクリプタを通じて、当該サービスまたはイベントの３Ｄサービスまたは３Ｄイベントを識別することができる。

表６を参照すると、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔが０ｘ０１である場合には、ＭＰＥＧ−２ビデオを示し、この場合、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ１１である場合には、２５Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示し、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ１２である場合には、３０Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔが０ｘ０５である場合には、Ｈ．２６４／ＡＶＣ ＳＤ（ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ）ビデオを示し、この場合、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ１１である場合には、２５Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示し、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ１２である場合には、３０Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔが０ｘ０３であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ１５である場合には、３Ｄモニタ上にディスプレイのためのＤＶＢサブタイトルズ（ｎｏｒｍａｌ）を示し、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔが０ｘ０３であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅが０ｘ２５である場合には、３Ｄモニタ上にディスプレイのためのＤＶＢサブタイトルズ（ｆｏｒ ｔｈｅ ｈａｒｄ ｏｆ ｈｅａｒｉｎｇ）を示すことができる。

ここで、トランスレーションサブタイトリング（Ｔｒａｎｓｌａｔｉｏｎ Ｓｕｂｔｉｔｌｉｎｇ）とハード−オブ−ヒアリング（Ｈａｒｄ−ｏｆ−ｈｅａｒｉｎｇ）とを比較すると、次の通りである。

トランスレーションサブタイトルズは、一般的にホワイトであり、画面の中央に位置する。ヒアリングオーディエンスは、単にサブタイトルズ内に必要なダイアローグのために、スピーカーとサウンドイフェクトを識別するのに用いられる。ハード−オブ−ヒアリングは、デフ／ハード−オブ−ヒアリングオーディエンスのエキストラニーズを認識するためのものである。結局、ノーマル（ｎｏｒｍａｌ）は、ダイアローグ中心であり、ハードオブヒアリングは、耳がよく聞こえない人のために、誰が話しているかなどの全体的な状況情報も含むといえる。

したがって、イメージディスプレイ装置は、図１３のコンポーネントデスクリプタをパージングして、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔとｃｏｍｐｏｎｅｎｔ_ｔｙｐｅフィールド値を抽出し、当該サービスが３Ｄサービスであるか否かを識別することができ、当該サービスまたはイベントのデコーディング及び出力可否も知ることができる。

図１４は、本発明に係るリンケージデスクリプタ（ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒ）のビットストリームシンタックスの一例を示した図であり、図１５は、本発明に係るリンケージデスクリプタを用いて、対応する３Ｄサービスをシグナリングする方法の一例を示した図である。

このようなリンケージデスクリプタは、例えば、ＳＤＴまたはＥＩＴに含まれ、これによって、イメージディスプレイ装置は、現在視聴している特定の２Ｄ ｓｅｒｖｉｃｅ_ｉｄまたは今後放送される特定の２Ｄ ｅｖｅｎｔ_ｉｄに対して対応する３Ｄサービスまたはイベントを把握することができる。

図１４を参照すると、リンケージデスクリプタに含まれたｌｉｎｋａｇｅ_ｔｙｐｅが０ｘ０５（ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅ）であり、追加的にｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅ領域においてリプレースメントタイプを３Ｄとして指定することもできる。

更に他の方法は、ＥＩＴにリンケージデスクリプタを伝送する場合、ｌｉｎｋａｇｅ_ｔｙｐｅを０ｘ０Ｄ（ｅｖｅｎｔ ｌｉｎｋａｇｅ）として指定し、ＥＩＴを通じてｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄに対する３Ｄサービスデスクリプタまたはコンポーネントデスクリプタを用いて、対応する３Ｄサービスの存在を把握することができる。

更に他の方法は、ｌｉｎｋａｇｅ_ｔｙｐｅを０ｘ０Ｅの新しい値を指定し、当該ディスクリプションは“３Ｄサービス”として指定する方法を使用することができる。

更に他の方法は、ｌｉｎｋａｇｅ_ｔｙｐｅを０ｘ０５（ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅ）を使用し、ターゲットサービスに対するｓｅｒｖｉｃｅ_ｔｙｐｅは、そのサービスに対するＳＤＴ、ＥＩＴなどを直接パージングして３Ｄであるか否かを把握する方法を使用する。この方法は、３Ｄに対応する２Ｄサービスを探す方法として使用することができる。

リンケージデスクリプタは、ＳＩシステムによって説明される特定の個体と関連する追加的な情報のためのユーザの要求がある場合に、サービスを識別するために提供される。シンタックス内のリンケージデスクリプタの位置は、追加的な情報が利用可能な個体を示す。例えば、ＮＩＴ内に位置するリンケージデスクリプタは、ネットワーク上に追加的な情報を提供するサービスを示し、ＢＡＴ内のリンケージデスクリプタは、ブーケ（ｂｏｕｑｕｅｔ）のようなものに対するサービス情報とのリンクを提供する。

ＣＡリプレースメントサービスは、リンケージデスクリプタを用いて識別可能である。このようなサービスは、もし、ＣＡが、ＳＩシステムによって説明される前記特定の個体に対するアクセスを拒否する場合、ＩＲＤによって自動で選択されてもよい。サービスリプレースメントサービスは、リンケージデスクリプタを用いて識別可能である。このようなサービスリプレースメントサービスは、現在サービスのランニング状態がｎｏｔ_ｒｕｎｎｉｎｇに設定されるとき、ＩＲＤによって自動で選択されてもよい。

以下、図１４を参照して、リンケージデスクリプタの各フィールドについてより詳細に説明すると、次の通りである。

ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄフィールドは、指示されたインフォメーションサービス（ｉｎｆｏｒｍａｔｉｏｎ ｓｅｒｖｉｃｅ）を含むＴＳを識別する。

ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄフィールドは、指示されたインフォメーションサービスのオリジネイティングデリバリーシステムのｎｅｔｗｏｒｋ_ｉｄを識別するラベルを与えることができる。

ｓｅｒｖｉｃｅ_ｉｄフィールドは、ＴＳ内にインフォメーションサービスを唯一に識別する。Ｓｅｒｖｉｃｅ_ｉｄは、当該ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ_ｎｕｍｂｅｒと同じ値を有する。もし、ｌｉｎｋａｇｅ_ｔｙｐｅフィールドが０ｘ０４値を有すれば、ｓｅｒｖｉｃｅ_ｉｄフィールドは関係なく、０ｘ００００に設定される。

Ｌｉｎｋａｇｅ_ｔｙｐｅフィールドは、情報としてリンケージのタイプを説明する。

ここで、前記ｌｉｎｋａｇｅ_ｔｙｐｅが０ｘ０Ｄまたは０ｘ０Ｅを有する場合、前記デスクリプタがＥＩＴ内に伝送されるときにのみ有効である。

ｍｏｂｉｌｅ_ｈａｎｄ−ｏｖｅｒ_ｉｎｆｏ（）フィールドは、予め定義された方式に従ってコーディングされる。ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）フィールドも、予め定義された方式に従ってコーディングされる。ｅｘｔｅｎｄｅｄ_ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）フィールドも、予め定義された方式に従ってコーディングされる。ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅは８−ビットのフィールドであり、プライベートに定義された値を有する。

図１５を参照すると、ＰＡＴは、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒ値及び当該プログラムのＰＭＴ_ＰＩＤを定義する。イメージディスプレイ装置は、ＰＡＴからＰＭＴを抽出してパージングする。

ここで、ＰＭＴは、２Ｄサービスである場合には当該プログラムのｓｔｒｅａｍ_ｔｙｐｅ及びｐｒｏｇｒａｍ_ｎｕｍｂｅｒを示す。例えば、ｓｔｒｅａｍ_ｔｙｐｅが０ｘ０２である場合には、当該ストリームはオーディオストリームであり、そのとき、オーディオＥＳのＰＩＤは０ｘ１１１であることを示すことができる。また、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒが０ｘｂｃである場合には、当該ストリームはビデオストリームであり、そのとき、ビデオＥＳのＰＩＤは０ｘ１１２であることを示すことができる。

ただし、ＰＭＴは、３Ｄサービスである場合には、前述したｓｔｒｅａｍ_ｔｙｐｅ及びｐｒｏｇｒａｍ_ｎｕｍｂｅｒ以外に、１つのｐｒｏｇｒａｍ_ｎｕｍｂｅｒをさらに定義する。例えば、図１５では、ｐｒｏｇｒａｍ_ｎｕｍｂｅｒが０ｘｂｄである場合には３Ｄエキステンション（ｅｘｔｅｎｓｉｏｎ）であることを示すことができ、この場合、ビデオＥＳのＰＩＤは０ｘ１１３であることを示すことができる。したがって、３Ｄサービスを支援可能なイメージディスプレイ装置では、ＰＭＴから１つのｓｔｒｅａｍ_ｔｙｐｅ値及び２つのｐｒｏｇｒａｍ_ｎｕｍｂｅｒ値を抽出及びパージングして、３Ｄサービスを識別及び処理することができる。

このとき、ＳＤＴは、ｓｅｒｖｉｃｅ_ｉｄを通じてＰＭＴのｐｒｏｇｒａｍ_ｎｕｍｂｅｒとマッピングさせて、当該サービスをシグナリングすることができる。

この場合、ＳＤＴのｓｅｒｖｉｃｅ_ｉｄが２である場合には、ＰＭＴのｐｒｏｇｒａｍ_ｎｕｍｂｅｒ ２と対応し、ＳＤＴ内のサービスデスクリプタにおいてｓｅｒｖｉｃｅ_ｔｙｐｅを０ｘ１Ｂ（Ｈ．２６４ ＨＤ）として定義して、２Ｄサービスであることをシグナリングすることができ、リンケージデスクリプタを通じて、ｓｅｒｖｉｃｅ_ｉｄ ３であり、ｌｉｎｋａｇｅ_ｔｙｐｅが０ｘ０５である場合には、サービスリプレースメントサービス（ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅ）であり、ｐｒｉｖａｔｅ_ｄａｔａ（）及びｒｅｐｌａｃｅｍｅｎｔ_ｔｙｐｅ（０ｘ０２）を通じて３Ｄを指示して、前記ｓｅｒｖｉｃｅ_ｉｄ ２に対応する３Ｄサービスの存在及び処理をシグナリングすることができる。類似の方式で、ｓｅｒｖｉｃｅ_ｉｄ ３である場合にも、サービスデスクリプタにおいてｓｅｒｖｉｃｅ_ｔｙｐｅを０ｘ１Ｃとして定義して、直ちに３Ｄサービスであることをシグナリングすることができる。

これに関連して、ｒｅｐｌａｃｅｍｅｎｔ_ｔｙｐｅは、サービス間の関係を表８のように定義し、ＨＤサイマルキャスト（ｓｉｍｕｌｃａｓｔ）であるか、または３Ｄであるかを識別することができる。

図１６は、本発明に係る３Ｄシグナリング情報を用いてステレオスコピックビデオ信号を出力する一例を説明するために示したフローチャートである。

逆多重化部２３０は、受信されるデジタル放送信号からＳＤＴセクションをフィルタリングしてパージングする。ここで、前述したように、逆多重化部は、ＰＩＤフィルタリングを通じてＳＤＴセクションをフィルタリングし、このとき、ＰＩＤは、例えば、０ｘ００１１に設定し、当該ＰＩＤを有するＴＳパケットをフィルタリングして、ｔａｂｌｅ_ｉｄ＝０ｘ４２であるセクションデータをパージングすることができる（Ｓ１６０２）。

シグナリング情報処理部２４０は、パージングされたＳＤＴ内のサービスループにおいてサービスデスクリプタから、レガシーサービスタイプを有するサービスに対する情報を獲得及び格納する。すなわち、シグナリング情報処理部は、２Ｄサービスに対するＰＭＴ情報を獲得及び格納する（Ｓ１６０４）。

シグナリング情報処理部２４０は、パージングされたＳＤＴ内のサービスループから、３Ｄサービスタイプを有するサービスに対する情報を獲得及び格納する。すなわち、シグナリング情報処理部は、３Ｄサービスに対するＰＭＴ情報を獲得及び格納する（Ｓ１６０６）。

シグナリング情報処理部２４０は、シグナリング情報からリンケージデスクリプタをパージングし、パージングされたリンケージデスクリプタの情報を用いて、接続されるレガシー３ＤサービスＩＤ（３Ｄ ｓｅｒｖｉｃｅ ｉｄ）情報を把握する（Ｓ１６０８）。

シグナリング情報処理部２４０は、３Ｄ ＰＭＴ情報を用いて、エキステンディドビュー（Ｅｘｔｅｎｄｅｄ Ｖｉｅｗ）ストリームに対するＰＩＤ情報を把握する（Ｓ１６１０）。

デジタル受信機は、視聴モードの設定を受信する（Ｓ１６１２）。

以下、視聴モードによって２つに分かれ、まず、３Ｄ視聴モード設定の場合について説明すると、次の通りである。

デジタル受信機は、３Ｄステレオスコピックビデオ（ｆｒａｍｅ−ｃｏｍｐａｔｉｂｌｅ ｓｔｅｒｅｏｓｃｏｐｉｃ ３Ｄ）を提供するｓｅｒｖｉｃｅ_ｉｄを選択する（Ｓ１６１４）。このとき、前記ｓｅｒｖｉｃｅ_ｉｄのｓｅｒｖｉｃｅ_ｔｙｐｅは、例えば、フレーム−コンパチブル３ＤＴＶであってもよい。

デジタル受信機は、基本Ａ／Ｖストリームに対するＰＩＤフィルタリング及びビデオ／オーディオＥＳデコーディングを行う（Ｓ１６１６）。

制御部２７０は、３Ｄサービスデスクリプタ情報を用いて３Ｄイメージフォーマッタでデコーディングした３Ｄステレオスコピックビデオが出力されるように制御する（Ｓ１６１８）。

３Ｄイメージフォーマッタを経た３Ｄビデオを、出力部を介して画面上に出力する（Ｓ１６２０）。

次に、２Ｄ視聴モード設定の場合について説明すると、次の通りである。

デジタル受信機は、２Ｄビデオ（ｂａｓｅ ｖｉｅｗ ｖｉｄｅｏ）を提供するｓｅｒｖｉｃｅ_ｉｄを選択する（Ｓ１６２２）。前記ｓｅｒｖｉｃｅ_ｉｄを有するチャネルは、例えば、レガシーチャネルである。

制御部２７０は、逆多重化及びデコーダを制御して、基本Ａ／Ｖストリームに対するＰＩＤフィルタリング及びビデオ／オーディオＥＳデコーディング（Ｂａｓｅ Ｖｉｅｗ Ｖｉｄｅｏ Ｄｅｃｏｄｅｒ）を行う（Ｓ１６２４）。

制御部２７０は、デコーディングされた２Ｄビデオを出力部を介して出力する（１６２６）。

図１７は、本発明によって構成したＵＩの一例を示した図である。

図１７（ａ）、図１７（ｂ）、そして、図１７（ｃ）の場合には、ユーザが、ＥＰＧを介さずに、直接チャネルをアップ／ダウン制御し、チャネルサーチ過程でサーチされたチャネルが３Ｄサービスを提供している場合に、これを２Ｄサービスを提供するチャネルと区分するために構成したＵＩまたはＯＳＤ画面である。ただし、この場合にも、受信機は、当該チャネルが３Ｄサービスを提供するか否かを知ることができる。例えば、前述した図４のサービスリストデスクリプタ、図６のサービスデスクリプタ、図９の３Ｄサービスデスクリプタ、または図１３のコンポーネントデスクリプタから、予め当該チャネルが３Ｄサービスを提供するか否かを判断することができる。

これは、視聴者が直接チャネルをサーチする過程において、前述した場合とは異なり、事前に当該チャネルに関する情報を得ることができないので、当該チャネルが現在３Ｄサービスを提供しているということを表示するためである。

図１７（ａ）の場合には、チャネルサーチ過程で現れるチャネルバナー上に、本発明によって構成された３Ｄインジケーターを含めて構成したＵＩが示されている。

図１７（ｂ）の場合には、接近したチャネルが３Ｄサービスを提供していることを知らせるために構成したＯＳＤ画面の一例である。

図１７（ｃ）の場合には、接近したチャネルが３Ｄサービスを提供していることを知らせるために、当該サービスのタイトルと共に３Ｄインジケーターを表示して構成したＯＳＤ画面の他の例である。

図１７（ｂ）及び図１７（ｃ）の場合には、視聴者が事前情報なしにチャネルを直接サーチする場合に、接近した特定のチャネルが、現在、３Ｄサービスを提供する場合、適切な視聴モードで当該チャネルを視聴できるように、チャネル切替過程で予めＯＳＤ画面に３Ｄサービスであることを表示して提供する内容である。したがって、視聴者は、このようなＯＳＤ画面を通じて適切にチャネルをスキップしたり、または視聴モードを変更してチャネルで提供する３Ｄサービスを視聴できるようになる。

次は、ＥＰＧ画面に関する。

図１８、図１９及び図２０は、本発明に係るＥＰＧ画面の実施例を示すものである。また、他の実施例及び構成も全て本発明の範囲に属する。

図１８乃至図２０は、例えば、前述した各テーブルセクションまたは各デスクリプタに含まれた３Ｄサービス／イベント関連データを予めパージングし、抽出して、受信機で抽出された３Ｄサービス／イベント関連データを組み合わせて構成したものである。

図１８のＥＰＧ画面１８００は、現在のチャネルを表示する第１項目１８０５と、当該チャネルでの時間帯別コンテンツリストが示される第２項目１８１０と、第２項目１８１０の選択された特定のプログラムに対するプレビューイメージがディスプレイされる第３項目１８２０と、前記第３項目でディスプレイされるプレビューイメージと関連する付加情報が含まれる第４項目１８３０と、その他のメニュー事項がディスプレイされる第５項目１８４０とを含んで構成される。

図１８では、本発明によって様々な方式で３Ｄインジケーターを含むＥＰＧ画面１８００を例示している。

第２項目１８１０のコンテンツリスト上には３Ｄインジケーターを表示せずに、第３項目１８２０のプレビューイメージ上に３Ｄインジケーターを表示する方式である。図１８を参照すると、第２項目１８１０のコンテンツリスト上に選択されたコンテンツ１８１１上には３Ｄインジケーターがなく、第３項目１８２０のプレビューイメージ上にのみ３Ｄインジケーター１８２５がある。

第３項目１８２０のプレビューイメージ上には３Ｄインジケーターを表示せずに、第２項目１８１０のコンテンツリスト上にのみ３Ｄインジケーターを表示する方式である。図１８を参照すると、第２項目のコンテンツリストにおける２つのコンテンツ上に３Ｄインジケーター１８１３，１８１５が表示されている。

前記２つの方式を混用するものである。

前記において、３Ｄインジケーターは２Ｄまたは３Ｄで具現することができ、前記インジケーターと共に又は別個にＥＰＧ画面上で色や奥行き情報（ｄｅｐｔｈ ｉｎｆｏｒｍａｔｉｏｎ）を用いて当該コンテンツが３Ｄコンテンツであることを表示してもよい。

図１９は、例えば、図１８のＥＰＧ画面から選択された特定のコンテンツに関する詳細情報を示したガイド画面１９００である。

図１９のガイド画面１９００は、現在のチャネル及び現在時刻情報を表示する第１項目１９１０と、コンテンツタイトル及び当該コンテンツに関する時間情報を含む第２項目１９２０と、プレビューイメージがディスプレイされる第３項目１９３０と、当該コンテンツに関する詳細情報がディスプレイされる第４項目１９４０とを含んで構成される。

当該コンテンツが３Ｄコンテンツである場合、映像信号処理装置は、図１９に示したように、ＥＰＧ画面の第２項目１９２０上に３Ｄインジケーター１９２５を表示したり、または第３項目１９３０上に３Ｄインジケーター１９３５を表示したり、または前記第２項目１９２０と第３項目１９３０の両方に３Ｄインジケーターを表示してもよい。この場合においても、３Ｄインジケーターは２Ｄまたは３Ｄフォーマットで構成されてもよい。

図２０のＥＰＧ画面２０００は、図１８のＥＰＧ画面１８００とは異なり、設定によって３Ｄコンテンツのみ表示されたＥＰＧ画面を例示したものである。

図１８及び図２０を参照すると、図２０のＥＰＧ画面では、図１８のＥＰＧ画面における３Ｄインジケーター１８１１，１８１３，１８１５が表示されたコンテンツのみ表示され、残りの２Ｄコンテンツは表示しなかった。

図２０ではＥＰＧ画面上で構成したが、これとは異なり、３ＤコンテンツをＥＰＧ画面ではなく他の方式で表現してもよい。

図２１及び図２２は、本発明に係るＥＰＧ画面の更に他の例を示した図である。

イメージ処理装置は、例えば、前述した図１４及び図１５のリンケージデスクリプタを用いて、各サービスに対する対応する２Ｄ／３Ｄサービスが存在するか否かを把握することができる。したがって、イメージ処理装置は、互いに対応する２Ｄと３Ｄサービスが存在すれば、サービスペア（ｓｅｒｖｉｃｅ ｐａｉｒ）を把握し、このように把握されたサービスペアは、サービス目録を提供するとき、図２１又は図２２のように同一のＥＰＧ画面を提供することができる。

この場合、イメージ処理装置は、ユーザの設定に従うか、または自動で１つのサービスに対してサービスペアも共にダウンロードすることができる。もし、イメージ処理装置でサービスペアも共にダウンロードした場合には、ユーザが、格納されたサービスまたはコンテンツを再生する過程において２Ｄ／３Ｄ切替ボタンを押すと、対応するコンテンツにスイッチングして再生することによって、ユーザに利便性を提供することができる。

受信機は、ユーザの選択または自動でサービスまたはコンテンツペアをいずれも受信できるようにダウンロード（ｄｏｗｎｌｏａｄ）予約をすることができる。この場合、当該コンテンツが放送される時点では、予約録画されたコンテンツに対応するｓｅｒｖｉｃｅ_ｉｄを見つけ、全て受信して格納する。受信機は、パージングされたＥＩＴから、各コンテンツに対するｓｅｒｖｉｃｅ_ｉｄ値を用いることができる。したがって、ユーザが、格納されたコンテンツを再生するとき、２Ｄ／３Ｄ切替ボタンを押すと、該当するコンテンツにスイッチング（ｓｗｉｔｃｈｉｎｇ）して再生することによって、ユーザに利便性を提供することができる。

図２３は、本発明に係る３Ｄバージョンの存在有無を知らせるＵＩの一例を示した図であり、図２４は、本発明に係るＥＰＧの更に他の例を示した図であり、そして、図２５は、図２４の詳細ＵＩの例示を示した図である。

図２３を参照すると、受信機は、上述した受信機のシグナリング情報に基づいて、既存放送画面の視聴中にＥＩＴを通じて格納された２Ｄコンテンツに対する対応するコンテンツ、すなわち、３Ｄバージョンが存在すれば、例えば、図２３に示したように、そのような情報を知らせるためにテキストバー（ｔｅｘｔ ｂａｒ）がスクロール（ｓｃｒｏｌｌ）されるようにすることができる。ただし、必ずしも図２３の図示に限定されるものではなく、別途のＵＩを構成し、ＯＳＤ（Ｏｎ−Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ）画面で３Ｄバージョンの存在有無と関連する制御動作を選択及び設定できるようにすることができる。

図２４は、ＳＤＴまたはＥＩＴのうちの少なくともいずれか１つをパージングして得たＥＰＧの画面を示し、例えば、図２３において、ユーザがＲＥＤのような特定のボタン（ＲＥＤのような）を押した場合にも、同一のＥＰＧが提供され得る。図２４を参照すると、ユーザの要求によって提供されるＥＰＧでは、各コンテンツに対して当該コンテンツが２Ｄであるか、または３Ｄであるかを識別できるインジケーターを提供する。特に、本発明と関連して、特定のコンテンツに対して対応するコンテンツ、例えば、１２時にＳＢＳで２Ｄバージョンの‘妻が帰ってきた２２回’ ＮＲＴコンテンツを提供するという情報と共に、前記コンテンツに対応する３Ｄバージョンの‘妻が帰ってきた２２回’がＳＢＳで１５：３０分から提供されることを知ることができる。この場合、前記３Ｄバージョンのコンテンツは、必ずしも同一のエピソードのコンテンツに限定されず、例えば、他のエピソード（２１回、２３回、スペシャルなど）に対するコンテンツであってもよい。また、図２４では、同じチャネルでのみ特定のコンテンツと対応するコンテンツに関する情報提供を例示したが、必ずしもこれに限定されるものではなく、他のチャネルに対する情報も提供できるだけでなく、互いに異なる媒体において対応するコンテンツに関する情報を提供することもできる。

図２５は、図２４で例示された太祖王建３０回（３Ｄ）コンテンツをユーザが選択した場合に、それに関する詳細な情報及び関連処理を説明する。例えば、図２５では、選択されたコンテンツは、既に録画された２Ｄの‘太祖王建３０回’の３Ｄバージョンであることを知らせる内容と共に、録画予約機能、戻り機能などを提供する。この場合、受信機は、図示していないが、ＳＤＴまたはＥＩＴから得たシグナリング情報を用いて、当該コンテンツのより詳細な情報、例えば、あらすじ情報、関連エピソード情報、放送開始時刻情報、放送終了時刻情報、サムネイル情報（ｔｈｕｍｂｎａｉｌ ｉｎｆｏｒｍａｔｉｏｎ）などの様々な情報を一緒に提供してもよい。

ビデオフォーマットトランジションは、上述したコンテンツを参照するために以下で説明される。

フレームコンパチブルステレオスコピック３ＤＴＶサービスは、フレームコンパチブルステレオスコピックビデオフォーマットの２つの中でビデオフォーマットを切り替えることができる。または、フレームコンパチブルステレオスコピックビデオフォーマットのうちの一つから、またはＨＤＴＶビデオフォーマット（即ち、ノン−フレームコンパチブルステレオスコピック３ＤＴＶビデオフォーマット）から切り替わってもよい。サイド−バイ−サイドとトップ−アンド−ボトムフレームパッキングアレンジメントとの間でフォーマット切替はｕｎｌｉｋｅｌｙに適用されてもよい。しかし、そのようなトランジション（ｔｒａｎｓｉｔｉｏｎ）が禁止されるものではない。

ビデオフォーマット切替は、ＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｉｎｇ Ｒｅｆｒｅｓｈ）ビデオフレームを有するＲＡＰ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）でのみ適用され得る。ビデオストリーム内のピクチャの発生とＴＳ内のＰＭＴの発生との間にタイトな同期化の不足のため、もし、ビデオフォーマットがランニングフレームコンパチブルステレオスコピック３ＤＴＶサービス中に切り替わると、短い期間不一致が起こることがある。ＨＤＴＶ（即ち、ノン−３ＤＴＶ）ビデオフォーマットコンテンツの運送は、一般に、フレームパッキングアレンジメントＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージが適用されないことを意味する。しかし、そのようなフォーマット切替を出力するＩＲＤは、ＰＭＴの以前発生において含まれた情報を持つ一時的な不一致のため、正確にトランジションをハンドルできない。これは、１０８０ｉ ２５Ｈｚサイド−バイ−サイドフレームコンパチブルステレオスコピック３ＤＴＶビデオを１０８０ｉ ２５Ｈｚ ＨＤＴＶビデオにビデオフォーマット切替することを例示し得る。

このような例示として、ビデオフォーマット切替後にフレームパッキングアレンジメントＳＥＩメッセージによって伝達される情報と、ビデオフォーマット切替前にＰＭＴの最後の発生時に伝送される情報との間に不一致がある。このような不一致は、ＩＲＤが不一致期間の間に不正確なビデオフォーマットを仮定するようになる原因となる。これは、上述したように、コーディングされたビデオピクチャとＰＭＴとの間のタイトな同期化の不足のため、その不一致期間を正確に知ることができないからである。

フォーマットトランジションアシスタンスシグナリングは、ＩＲＤ内にデコーディングプロセスのロバストネス（ｒｏｂｕｓｔｎｅｓｓ）の確実をイネーブルするように定義される。このようなフォーマットトランジションアシスタンスシグナリングは、フレームコンパチブルステレオスコピック３ＤＴＶサービスがノン−３ＤＴＶビデオフォーマット内にコンテンツのピリオドを含むときに適用されることを推奨する。

フォーマットトランジションアシスタンスシグナリングは、ＨＤＴＶフォーマットビデオコンテンツを含むビデオストリーム内にフレームパッキングアレンジメントＳＥＩメッセージを含むことによって構成される。このとき、前記ビデオストリームは、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇを１に設定して、確実にフレームコンパチブルステレオスコピック３ＤＴＶビデオフォーマットが現在伝送されていないことをシグナリングする。

ＩＲＤ内のデコーディングプロセスのロバストネスを最大化するために、フレームコンパチブルステレオスコピック３ＤＴＶサービスに、少なくともＨＤＴＶビデオフォーマットとフレームコンパチブルステレオスコピック３ＤＴＶビデオフォーマットとの間にフォーマット切替前と後の約２秒の期間の間に、ＨＤＴＶフォーマットが伝送される間にはフレームパッキングアレンジメントＳＥＩメッセージが適用されることを推奨する。

ＨＤＴＶビデオフォーマットから、またはビデオフォーマットトランジションが発生するとき、フレームコンパチブルステレオスコピック３ＤＴＶビデオフォーマットからＨＤＴＶビデオフォーマットに、または、ＨＤＴＶビデオフォーマットからフレームコンパチブルステレオスコピック３ＤＴＶビデオフォーマットにフォーマット切替が発生した後、少なくとも２秒の期間には、フレームパケットアレンジメントＳＥＩメッセージ内のｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇは、ノン−３ＤＴＶビデオフォーマットが伝送されていることを知らせるように１に設定されなければならない。

１に設定されたｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇを持つフレームパッキングアレンジメントＳＥＩメッセージの運送は、サービス提供者の認識があるとき、ＨＤＴＶビデオフォーマットコンテンツの間に維持されなければならない。

フレームコンパチブルステレオスコピック３ＤＴＶサービス内のビデオフォーマットトランジションのＩＲＤによってハンドリングされるロバストネスの増加のために、ＩＲＤは、他のサービスからフレームコンパチブルステレオスコピック３ＤＴＶサービスにホップ（ｈｏｐ）する。同じ状況において、その運送を中断するより、同一のシグナリングを適用するように維持する方が遥かに便利であり得る。

ある場合に、フレームパッキングアレンジメントＳＥＩメッセージのシグナリングは、伝送されるビデオフォーマットで一貫してもよく、ビデオフォーマットと関連する他のシグナリングを通じて予測されてもよい。上述したＰＭＴによる一時的な不一致が発生する場合、上述したように、フォーマットトランジションアシスタンスシグナリングの適用によって軽減することができる。

前述したように、前記発明を実施するための最良の形態において、関連する事項を記述した。

以上、上述した本発明によれば、３ＤＴＶにおいて、ステレオスコピックビデオ放送サービスに対するシグナリング情報を処理するための方法及び具現に対する方案を提示する。特に、当該シグナリング情報を用いて放送サービスを受信する方法、及びステレオスコピックディスプレイの出力を制御するための３ＤＴＶの動作及び具現方法を提案する。

なお、本発明を利用して３ＤＴＶ及び２Ｄレガシー、前述したように、本発明は、デジタル放送システムに全体的または部分的に適用することができる。レガシーＴＶサービスを別途の独立かつ分離されたロジカルチャネル（ｖｉｒｔｕａｌ ｃｈａｎｎｅｌ）を介して区分して受信できるので、ユーザは、チャネル変更を通じて２Ｄサービスから３ＤＴＶサービスへの切り替えを行うことができるという効果がある。

すなわち、ＤＴＶ放送環境において２Ｄと３Ｄサービスが混在する状況で、受信機は、明確に２つのサービスの対応関係を把握し、２Ｄ及び対応する３Ｄサービスの存在有無を知ることができ、ユーザがサービス切替を要求するときに対応可能である。

前述したように、本発明は、デジタル放送システムに全体的または部分的に適用できる。

以下、本発明の好ましい実施例を詳細に参照し、これらの例が添付の図面に図示される。可能な場合、図面全般にわたって同一の図面符号は同一又は類似の構成要素を示す。

たとえ、本発明で使用される用語は、一般的に知られており、使用されている用語から選択されるが、本発明の明細書に言及されるこれら用語の一部は、習慣又は新しい技術の出現によって、通常の知識を有する者によって変更されてもよい。また、ある場合において、本発明の詳細な説明に言及された用語の一部は出願人の裁量で選択されたものもあり、これらの場合、詳細な意味は本発明の詳細な説明の関連部分に記述され、これらは、ここで使用する用語の単純な名称ではなく、本発明の詳細な説明内で及び全体的な内容に基づいた各用語の実際の意味として理解されなければならない。

３Ｄ映像の表現方法は、２つのパースペクティブ（即ち、観点）を考慮する立体映像（ｓｔｅｒｅｏｓｃｏｐｉｃ ｉｍａｇｅ）方法、及び３つ以上のパースペクティブ（即ち、観点）を考慮するマルチ視覚映像方法を含むことができる。これとは反対に、関連技術の単一視覚映像は、モノ映像（ｍｏｎｏｓｃｏｐｉｃ ｉｍａｇｅ）方法と呼ぶことができる。

立体映像方法は、所定の距離で互いに離隔している左側カメラ及び右側カメラで同一の対象を撮影することによって獲得された左／右映像のペアを使用する。マルチ視覚映像は、所定の距離で互いに離隔し、互いに異なる角度で配置された少なくとも３つの互いに異なるカメラで撮影することによって獲得された少なくとも３つの映像セットを使用する。以下で本発明の実施例に係る立体映像方法が説明されるが、本発明の思想はマルチ視覚映像方法にも適用可能である。また、以下で、立体（ｓｔｅｒｅｏｓｃｏｐｉｃ）は、短縮して立体（ｓｔｅｒｅｏ）と呼んでもよい。

前記立体映像またはマルチ視覚映像は、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）フォーマットでまたは様々な方法を用いて圧縮エンコーディングされ、それによって伝送される。

例えば、立体映像あるいはマルチ視覚映像がＨ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方法を用いて圧縮−エンコーディングされ、それによって伝送される。このとき、前記受信システムは、Ｈ．２６４／ＡＶＣ方法とは反対のプロセスとして前記受信された映像に対してデコーディングプロセスを行い、それによって３Ｄ映像を獲得する。

さらに、立体映像の左側視覚映像または右側視覚映像のいずれか一つの映像、あるいはマルチ視覚映像の任意の１つの映像がベース層の映像として割り当てられ、残りの映像はエンハンスメント層の映像として割り当てられてもよい。その後、前記ベース層の映像は、モノ映像をエンコーディングするために利用されるものと同様の方法を用いてエンコーディングされてもよい。そして、前記エンハンスメント層の映像において、前記ベース層の映像と前記エンハンスメント層の映像間の関連情報のみがエンコーディングされる。その後、前記プロセシングされた映像が伝送される。

ベース層に対する圧縮−エンコーディング方法の例には、ＪＰＥＧ、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４、及びＨ．２６４／ＡＶＣが含まれる。そして、本発明のこの実施例では、Ｈ．２６４／ＡＶＣ方法が採択された。さらに、本発明の実施例によれば、エンハンスメント層の映像の圧縮−エンコーディングプロセスのために、Ｈ．２６４／ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）またはＭＶＣ（Ｍｕｌｔｉ−ｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方法が採択された。

地上波（即ち、地上）ＤＴＶ伝送及び受信は２Ｄビデオコンテンツに基づく。したがって、３Ｄ ＴＶ放送コンテンツをサービスするためには、３Ｄ ＴＶ放送コンテンツのための伝送及び受信の標準が追加的に定義されなければならない。受信機が、前記追加された伝送及び受信の標準に従って放送信号を受信し、前記受信された信号を十分にプロセシングし、それによって、３Ｄ放送サービスを支援する。

本発明の詳細な説明において、本発明の実施例に係る従来のＤＴＶ伝送及び受信の標準を説明するためにＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ）標準が使用される。

前記ＡＴＳＣシステムの場合に、放送コンテンツをプロセシングするための情報が前記システム情報に含まれ、それによって伝送される。

システム情報は、例えば、サービス情報と呼ぶことができる。ここで、例えば、該システム情報は、チャネル情報、プログラム情報、イベント情報などを含むことができる。ＡＴＳＣ標準方法の場合に、該システム情報は、ＰＳＩ／ＰＳＩＰ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ／Ｐｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）内に含まれることによって伝送及び受信されてもよい。しかし、本発明がこの例のみに限定されるものではない。そして、システム情報をテーブルフォーマット（ｔａｂｌｅ ｆｏｒｍａｔ）で伝送するプロトコルの場合、該プロトコルは、その用語（即ち、名称）に関係なく、本発明に適用されてもよい。

本発明の実施例によれば、ＰＳＩテーブルは、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、及びＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）を含むことができる。

ＰＡＴは、ＰＩＤが‘０’であるデータパケットによって伝送される特殊情報に対応する。ＰＡＴは、それぞれのプログラムに対して、対応するＰＭＴのＰＩＤ情報を伝送し得る。ＰＭＴは、伝送ストリーム（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ、ＴＳ）パケットのＰＩＤ情報を伝送し（ここでは、プログラム識別番号、及びその対応するプログラムを構成するビデオとオーディオデータの個別ビットシーケンスが伝送される）、そして、また、ＰＣＲが伝送されるＰＩＤ情報も伝送する。その後、ＰＡＴから獲得されたＰＭＴをパージング（ｐａｒｓｉｎｇ）することによって、その対応するプログラムを構成する要素間の相関情報も獲得できる。

本発明の実施例によれば、ＰＳＩＰテーブルは、ＶＣＴ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）、ＳＴＴ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｔａｂｌｅ）、ＲＲＴ（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ）、ＥＴＴ（Ｅｘｔｅｎｄｅｄ Ｔｅｘｔ Ｔａｂｌｅ）、ＤＣＣＴ（Ｄｉｒｅｃｔ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ Ｔａｂｌｅ）、ＤＤＣＳＣＴ（Ｄｉｒｅｃｔ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ Ｓｅｌｅｃｔｉｏｎ Ｃｏｄｅ Ｔａｂｌｅ）、ＥＩＴ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、及びＭＧＴ（Ｍａｓｔｅｒ Ｇｕｉｄｅ Ｔａｂｌｅ）を含むことができる。

ＶＣＴは、仮想チャネルに関する情報（例えば、チャネルを選択するためのチャネル情報のようなもの）、及びオーディオ及び／又はビデオデータを受信するためのＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）のような情報を伝送することができる。より具体的には、ＶＣＴがパージングされるとき、チャネル名及びチャネル番号と共にチャネルを介して伝送される、放送プログラム（ｂｒｏａｄｃａｓｔ ｐｒｏｇｒａｍ）のオーディオ／ビデオデータのＰＩＤが獲得され得る。ＳＴＴは、現在のデータに関する情報及びタイミング情報（ｔｉｍｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を伝送することができ、ＲＲＴは、地域（ｒｅｇｉｏｎ）に関する情報及びプログラムの等級（ｒａｔｉｎｇｓ）のための協議機関（ｃｏｎｓｕｌｔａｔｉｏｎ ｏｒｇａｎｓ）に関する情報を伝送することができる。ＥＴＴは、特定チャネル及び放送プログラムの追加的な説明を伝送することができ、そして、ＥＩＴは、仮想チャネルイベントに関する情報を伝送することができる。ＤＣＣＴ／ＤＣＣＳＣＴは、自動で（あるいは直接）チャネル変更と関連する情報を伝送することができ、そして、ＭＧＴは、ＰＳＩＰ内のそれぞれのテーブルのバージョン（ｖｅｒｓｉｏｎ）及びＰＩＤ情報を伝送することができる。

立体映像の伝送フォーマットは、単一のビデオストリームフォーマット及び多重−ビデオストリームフォーマット（ｍｕｌｔｉ−ｖｉｄｅｏ ｓｔｒｅａｍ ｆｏｒｍａｔ）を含む。単一のビデオストリームフォーマットは、２つのパースペクティブのビデオデータを単一のビデオストリームにマルチプレクシング（ｍｕｌｔｉｐｌｅｘｉｎｇ）して、該単一のビデオストリームを伝送する方法に対応する。ここで、ビデオデータは、１つのビデオストリームで伝送されるので、単一のビデオストリームフォーマットは、３Ｄ放送サービスを提供するために追加的に要求される帯域幅が広くならないという点で利点がある。多重−ビデオストリームフォーマットは、多重ビデオデータを多重ビデオストリームで伝送する方法に対応する。ここで、たとえ帯域幅の使用が増加するが、高容量のデータを伝送できるので、多重−ビデオストリームフォーマットは、高画質のビデオデータ（ｈｉｇｈ ｐｉｃｔｕｒｅ ｑｕａｌｉｔｙ ｖｉｄｅｏ ｄａｔａ）をディスプレイできるという点で利点がある。

図２６は、本発明の実施例に係る、様々な映像フォーマットの立体映像マルチプレクシングフォーマットを示す。

３Ｄ放送サービスの映像フォーマットは、（ａ）に示したサイド−バイ−サイドフォーマット（ｓｉｄｅ−ｂｙ−ｓｉｄｅ ｆｏｒｍａｔ）、（ｂ）に示したトップ−ボトムフォーマット（ｔｏｐ−ｂｏｔｔｏｍ ｆｏｒｍａｔ）、（ｃ）に示したインターレースドフォーマット（ｉｎｔｅｒｌａｃｅｄ ｆｏｒｍａｔ）、（ｄ）に示したフレーム順次フォーマット（ｆｒａｍｅ ｓｅｑｕｅｎｔｉａｌ ｆｏｒｍａｔ）、（ｅ）に示したチェッカーボードフォーマット（ｃｈｅｃｋｅｒ ｂｏａｒｄ ｆｏｒｍａｔ）、及び（ｆ）に示したアナグリフフォーマット（ａｎａｇｌｙｐｈ ｆｏｒｍａｔ）を含む。

（ａ）に示したサイド−バイ−サイドフォーマットは、左側映像と右側映像が水平方向に１／２ダウン−サンプリング（ｄｏｗｎ−ｓａｍｐｌｉｎｇ）されたフォーマットに対応する。ここで、サンプリングされた映像のうちの一方は左側に位置し、他方は右側に位置して単一の立体映像を生成する。（ｂ）に示したトップ−ボトムフォーマットは、左側映像と右側映像が垂直方向に１／２ダウン−サンプリングされたフォーマットに対応する。ここで、サンプリングされた映像のうちの一方は上側に位置し、他方は下側に位置して単一の立体映像を生成する。（ｃ）に示したインターレースドフォーマットは、左側映像と右側映像が水平方向に１／２ダウン−サンプリングされて、２つの映像が１ラインずつ交互に現れるようになり、これによって単一の立体映像を生成するフォーマットに対応するか、または、左側映像と右側映像が垂直方向に１／２ダウン−サンプリングされて、２つの映像が１ラインずつ交互に現れるようになり、これによって単一の立体映像を生成するフォーマットに対応する。（ｄ）に示したフレーム順次フォーマットは、左側映像と右側映像が時間的に（ｔｅｍｐｏｒａｌｌｙ）交互に現れ、単一のビデオストリームで構成されるフォーマットに対応する。（ｅ）に示したチェッカーボードフォーマットは、左側映像と右側映像が１／２ダウン−サンプリングされて、左側映像と右側映像が水平方向と垂直方向のそれぞれにおいて交互に現れるようになり、これによって２つの映像を単一の映像として構成するようになるフォーマットに対応する。（ｆ）に示したアナグリフフォーマット（ａｎａｇｌｙｐｈ ｆｏｒｍａｔ）は、補色対比（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｃｏｌｏｒ ｃｏｎｔｒａｓｔ）を用いることによって、映像が立体感を提供できるように構成するフォーマットに対応する。

現在のデジタル放送は、限定されたシステムリソース（ｌｉｍｉｔｅｄ ｓｙｓｔｅｍ ｒｅｓｏｕｒｃｅ）を使用することによって放送サービスを提供する。デジタル放送環境のシステムリソースは、伝送帯域幅、プロセシング能力などを含む。特に、周波数の配分（即ち、割当）において使用可能な帯域幅は限定されている。このデジタル放送環境において、３Ｄ放送サービスが提供される場合に、対応する３Ｄ放送サービスもデジタル放送環境で使用される限定されたリソースを使用することになる。

本発明の実施例によれば、立体映像技法（ｓｔｅｒｅｏｓｃｏｐｉｃ ｉｍａｇｅ ｓｃｈｅｍｅ）を使用する３Ｄ放送サービスの場合に、左側−視覚映像（ｌｅｆｔ−ｖｉｅｗ ｉｍａｇｅ）と右側−視覚映像（ｒｉｇｈｔ−ｖｉｅｗ ｉｍａｇｅ）が伝送されなければならない。したがって、従来のデジタル放送の帯域幅を使用して高解像度で２つの映像を伝送することは難しい。例えば、デジタル放送の帯域幅を使用してフル解像度のビデオデータを伝送する場合、同一の帯域幅を使用して２−セットのフル解像度のビデオデータを伝送することは難しい。したがって、２−セットのハーフ解像度のビデオデータを伝送する方法が提案されている。

それにもかかわらず、高画質に対するユーザの要求を充足させるために、フル解像度の３Ｄ放送サービスの提供が要求される。しかし、フル解像度の３Ｄ放送サービスが提供されている場合にも、フル解像度の３Ｄ放送サービスは、従来のハーフ解像度の３Ｄ放送サービスと互換可能でなければならない。

図２７は、本発明の実施例に係る３Ｄ放送サービスの概念図を示す。図２７の実施例によれば、フル解像度の映像を提供する３Ｄ放送サービス２０１０は、以下で、３Ｄサービス２．０あるいは３ＤサービスＳｐｅｃ−Ｂと呼ぶことにする。ハーフ解像度の映像を提供する３Ｄ放送サービス２０２０は、以下で、３Ｄサービス１．０あるいは３ＤサービスＳｐｅｃ−Ａと呼ぶことにする。

３Ｄサービス１．０ ２０２０は、ハーフ解像度の左側映像及びハーフ解像度の右側映像としてサービスされてもよい。フル解像度の映像を提供する３Ｄサービス２．０ ２０１０は、フル解像度の映像を新たに伝送する代わりに、３Ｄサービス１．０ ２０２０と互換可能でなければならないので、３Ｄサービス１．０ ２０２０の映像伝送を維持し、そして、フル解像度の映像を伝送するための差動データ（ｄｉｆｆｅｒｅｎｔｉａｌ ｄａｔａ）あるいは追加データを提供する方法が使用されてもよい。より具体的には、図２７に示したように、３Ｄサービス１．０ ２０２０のハーフ解像度のビデオ要素に３Ｄサービス２．０の相補型ビデオ要素（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｖｉｄｅｏ ｅｌｅｍｅｎｔ）２０３０を加えることによって、フル解像度の３Ｄ放送サービス２０１０が提供され得る。結局、３Ｄサービス１．０を支援し得る放送受信機は、３Ｄサービス１．０ ２０２０のデータを受信及びプロセシングすることによって、ハーフ解像度の映像を提供することができ、３Ｄサービス２．０を支援し得る放送受信機は、３Ｄサービス１．０ ２０２０のデータ及び３Ｄサービス２．０の相補型データを受信及びプロセシングすることによって、フル解像度の映像を提供することができる。

図２８は、本発明の実施例に係るフル解像度の３Ｄ放送サービスを提供するための方法を示す概念的なブロック図を例示する。

本発明では、フル解像度の３Ｄ映像を提供し得るデジタル放送受信機３０３０と、そして、ハーフ解像度の３Ｄ映像を支援し得るデジタル放送受信機３０４０をそれぞれ提供することができる。

３Ｄ放送サービスを提供する放送システムは、ベース層３０２０を介してハーフ解像度の３Ｄビデオデータを伝送し、エンハンスメント層３０１０を介してフル解像度の３Ｄ映像を提供するための追加的なハーフ解像度の３Ｄビデオデータを伝送することができる。

ハーフ解像度の３Ｄ映像を支援し得るデジタル放送受信機３０４０は、ベース層３０２０のビデオデータを受信及びプロセシングすることによって、ハーフ解像度の３Ｄ映像を提供することができる。また、フル解像度の３Ｄ映像を提供し得るデジタル放送受信機３０３０は、ベース層３０２０のビデオデータとエンハンスメント層３０１０のビデオデータを受信及びプロセシングすることによって、フル解像度の３Ｄ映像を提供することができる。説明を簡潔にするために、以下で、ベース層のビデオデータあるいはビデオコンポーネントは、それぞれ、ベースビデオデータあるいはベースビデオコンポーネントと呼び、そして、エンハンスメント層のビデオデータあるいはビデオコンポーネントは、それぞれ、相補型ビデオデータあるいは相補型ビデオコンポーネントと呼ぶことができる。

図２９は、本発明の実施例に係る３Ｄ放送サービスを提供するための方法を例示する。

図２９を参照すると、３ＤサービスＳｐｅｃ−Ａ ４０１０は、ベース層を介して伝送される３Ｄビデオデータを示し、図２９の実施例によれば、３Ｄビデオデータは、ハーフ解像度のトップ−ボトム映像フォーマットで提供される。

３ＤサービスＳｐｅｃ−Ｂ ４０２０は、エンハンスメント層を介してそれぞれのパースペクティブの映像に対する相補型データを伝送する。受信システムは、前記伝送された相補型データを受信する。そして、前記受信された相補型データは、３ＤサービスＳｐｅｃ−Ａ ４０１０から伝送された３Ｄビデオデータに追加的にプロセシングされ、受信システムがフル解像度の立体映像を提供できるようにする。

図３０は、本発明の更に他の実施例に係る、３Ｄ放送サービスを提供するための方法を例示する。

本発明の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ５０１０は、トップ−ボトム映像フォーマットに対応し、そして、空間的ハーフ解像度の３Ｄビデオデータ及び時間的フル解像度の３Ｄビデオデータを含むことができる。本発明の他の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ５０１０のビデオデータは、空間的フル解像度及び時間的ハーフ解像度で提供されるように、受信システムにおいて補間（ｉｎｔｅｒｐｏｌａｔｅ）されてもよい。３ＤサービスＳｐｅｃ−Ｂ ５０２０の受信システムは、空間的フル解像度の映像及び時間的フル解像度の映像の両方を提供するように、相補型情報を追加的にプロセシングすることができる。

時間的ハーフ解像度及び空間的フル解像度の鮮明度において、伝送され得るビデオデータ（あるいは伝送可能なビデオデータ）の大きさ又は量は、システムリソースの制限によって限定され得る。ビデオデータは、フレーム−単位の映像（ｆｒａｍｅ−ｕｎｉｔ ｉｍａｇｅ）を含むことができる。ここで、伝送可能なビデオデータの大きさに応じて、（時間的に配置され得る）フレーム−単位の映像間の距離も、映像の解像度と共に、限定され得る。例えば、所定の帯域幅での制限によって、もし、伝送可能なビデオデータのセットが空間的にはハーフ解像度であり、時間的にはフル解像度であれば、そして、空間的フル解像度の映像が同一の帯域幅の制限内で伝送されている場合、単に、時間的ハーフ解像度（例えば、時間的フル解像度の場合にフレームの距離の２倍の距離）のビデオデータのみが伝送され得る。

受信システムでの解像度に応じてビデオデータをプロセシングする方法に関する様々な実施例が利用可能である。

３ＤサービスＳｐｅｃ−Ａ ５０１０の受信システムは、フル解像度に近い映像（Ｌｂ’あるいはＲｂ’）（図３０の左側下部に図示）を提供するように、その受信された映像（ＬｂあるいはＲｂ）に対して補間を行うことができる。

３ＤサービスＳｐｅｃ−Ｂ ５０２０の受信システムは、ベース層で受信されたビデオデータ及びエンハンスメント層で受信されたビデオデータを使用することができる。受信システムは、ベース層の受信された映像（ＬｂあるいはＲｂ）及びエンハンスメント層の受信された映像（ＬｅあるいはＲｅ）の水平ラインをインターリーブ（ｉｎｔｅｒｌｅａｖｅ）及び結合（ｃｏｍｂｉｎｅ）することができ、それによって、フル解像度の映像（ＬｆあるいはＲｆ）を提供するようになる。また、受信システムは、ベース層の受信された映像（ＬｂあるいはＲｂ）に対してローパスフィルタリング（ｌｏｗ−ｐａｓｓ ｆｉｌｔｅｒｉｎｇ）を行うことができ、エンハンスメント層の受信された映像（ＬｅあるいはＲｅ）に対してハイパスフィルタリング（ｈｉｇｈ−ｐａｓｓ ｆｉｌｔｅｒｉｎｇ）を行うことができ、それによって、２つの映像を結合してフル解像度の映像（ＬｆあるいはＲｆ）を復元するようになる。また、受信システムは、ベース層の受信された映像（ＬｂあるいはＲｂ）に対して補間を行うことができ、補間された（フル解像度に近い）フル解像度の映像（Ｌｂ’あるいはＲｂ’）を相補型情報映像（ＬｅあるいはＲｅ）で補充（ｓｕｐｐｌｅｍｅｎｔ）することができ、それによって、フル解像度の映像（ＬｆあるいはＲｆ）（図３０の右側下部に図示）を提供するようになる。

図３１は、本発明の他の実施例に係る、３Ｄ放送サービスを提供するための方法を例示する。

本発明の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ６０１０は、サイド−バイ−サイド映像フォーマットに対応し、そして、空間的ハーフ解像度の３Ｄビデオデータ及び時間的フル解像度の３Ｄビデオデータを含むことができる。本発明の他の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ６０１０のビデオデータは、空間的フル解像度及び時間的ハーフ解像度で提供されるように、受信システムにおいて補間されてもよい。３ＤサービスＳｐｅｃ−Ｂ ６０２０の受信システムは、空間的フル解像度の映像及び時間的フル解像度の映像の両方を提供するように、相補型情報を追加的にプロセシングすることができる。

図３１の場合において、映像フォーマットがサイド−バイ−サイド映像フォーマットに対応する点以外は、図３１の残りの説明は図３０の説明と同一である。したがって、説明を簡潔にするために、本発明の重複する説明は省略される。しかし、図３１を参照すると、ベース層の受信された映像（ＬｂあるいはＲｂ）及びエンハンスメント層の受信された映像（ＬｅあるいはＲｅ）をインターリーブする場合に、３ＤサービスＳｐｅｃ−Ｂ ６０２０の受信システムは垂直ラインをインターリーブ及び結合することができ、それによって、フル解像度の映像を提供するようになる。

図３２は、本発明の他の実施例に係る、３Ｄ放送サービスを提供するための方法を例示する。

本発明の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ７０１０は、フレーム順次映像フォーマットに対応し、そして、空間的フル解像度の３Ｄビデオデータ及び時間的ハーフ解像度の３Ｄビデオデータを含むことができる。本発明の他の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ７０１０のビデオデータは、空間的ハーフ解像度及び時間的フル解像度で提供されるように、受信システムにおいてフォーマット−変換されてもよい。３ＤサービスＳｐｅｃ−Ｂ ７０２０の受信システムは、空間的フル解像度の映像及び時間的フル解像度の映像の両方を提供するように、相補型情報を追加的にプロセシングすることができる。

本発明の実施例によれば、３ＤサービスＳｐｅｃ−Ａ ７０１０の受信システムは、受信された映像（ＬｂあるいはＲｂ）に対してデシメーション（ｄｅｃｉｍａｔｉｏｎ）を行うことができ、それによって、トップ−ボトムフォーマットあるいはサイド−バイ−サイドフォーマットのハーフ解像度の映像（Ｌｂ’あるいはＲｂ’）を生成（あるいは発生）させる。このとき、デシメーションを行う間、受信システムは、トップ−ボトムフォーマットあるいはサイド−バイ−サイドフォーマットでハーフ解像度の映像（Ｌｂ’あるいはＲｂ’）を獲得する。このとき、デシメーションを行う間、受信システムは、フレームレート変換（ｆｒａｍｅ ｒａｔｅ ｃｏｎｖｅｒｓｉｏｎ）を通じて時間的に拡張された（例えば、２倍になった）ハーフ解像度の映像のペアを獲得し、それによって、空間的フル解像度の映像及び時間的フル解像度の映像を提供できるようになる。

他の実施例によれば、３ＤサービスＳｐｅｃ−Ｂ ７０２０の受信システムは、エンハンスメント層を介して受信された映像（ＬｅあるいはＲｅ）を、ベース層を介して受信されたそれぞれの連続する映像（ＬｂあるいはＲｂ）の間にそれぞれ挿入し、それによって、空間的フル解像度の映像及び時間的フル解像度の映像を提供できるようになる。

上述したように、高解像度の３Ｄ放送サービスを提供するために、現在提供されている解像度の３Ｄ放送サービスのために相補型ビデオデータが提供されなければならず、そして、この相補型ビデオデータと共に、相補型ビデオデータに対するシグナリング情報（ｓｉｇｎａｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）も伝送／受信及びプロセシングされることが要求される。

以下では、相補型ビデオデータ及びこの補型ビデオデータに関する情報をシグナリングするための方法が詳細に説明される。本発明の実施例によれば、相補型ビデオデータは、レイヤード映像圧縮エンコーディング方法（ｌａｙｅｒｅｄ ｉｍａｇｅ ｃｏｍｐｒｅｓｓｉｏｎ ｅｎｃｏｄｉｎｇ ｍｅｔｈｏｄ）として、Ｈ．２６４／ＳＶＣ（Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）あるいはＭＶＣ（Ｍｕｌｔｉ−ｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方法を用いることができる。そして、このとき、相補型ビデオデータは、エンハンスメント層を介して伝送されてもよい。

相補型ビデオデータに関する前記伝送されたシグナリング情報は、３Ｄ相補型ビデオ情報と呼ぶことができる。３Ｄ相補型ビデオ情報は、本発明の実施例に係るデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）あるいはテーブルフォーマットで提供されてもよく、ここで、３Ｄ相補型ビデオ情報は、３Ｄ相補型ビデオデスクリプタあるいは３Ｄ相補型ビデオテーブルと呼ぶことができる。

本発明の実施例によれば、３Ｄ相補型ビデオ情報は、ＰＳＩＰ（これは、ＡＴＳＣ放送システムから伝送される）に含まれてもよく、特に、ＰＳＩＰのＴＶＣＴ（あるいはＶＣＴ）に含まれてもよく、それによって伝送されるようになる。また、３Ｄ相補型ビデオ情報は、ＰＳＩ（これは、ＡＴＳＣ放送システムから伝送される）に含まれてもよく、特に、ＰＳＩのＰＭＴに含まれてもよい。さらに、３Ｄ相補型ビデオ情報は、相補型ビデオ情報に含まれてもよく、特に、相補型ビデオＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）のヘッダー情報（ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）に含まれてもよく、それによって伝送されるようになる。

図３３は、本発明に係るフルフォワード及びバックワード相互運用性（ｆｕｌｌ ｆｏｒｗａｒｄ ａｎｄ ｂａｃｋｗａｒｄ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）を例示する。

本発明は、現世代あるいは次世代のソースデバイス、そして、まもなく登場するハーフ解像度の３ＤＴＶ及び次世代フル解像度の３ＤＴＶ間に、フルフォワード及びバックワード相互運用性を提供する。これらがどのように動作するかに関する例が提供される。現在のＢＤプレーヤー／ＳＴＢでプレーされるＳｐｅｃ−Ａコンテンツは、２種類のモード、すなわち、消費者が、まもなく登場する３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見るモード、及び次世代３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見るモードを有することができる。次世代ＢＤプレーヤー／ＳＴＢでプレーされるＳｐｅｃ−Ａコンテンツに対して、消費者は、まもなく登場する３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見ることができ、そして、消費者は、次世代３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見ることができる。現在のＢＤプレーヤー／ＳＴＢでプレーされるＳｐｅｃ−Ｂコンテンツに対して、消費者は、まもなく登場する３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見ることができ、そして、消費者は、次世代３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見ることができる。最後に、次世代ＢＤプレーヤー／ＳＴＢでプレーされるＳｐｅｃ−Ｂコンテンツに対して、消費者は、まもなく登場する３ＤＴＶ上でハーフ解像度の３Ｄ立体コンテンツを見ることができ、そして、消費者は、次世代３ＤＴＶ上でフル解像度の３Ｄ立体コンテンツを見ることができる。

本発明でのトップ−ボトム及びサイド−バイ−サイドのような空間ハーフ解像度方法は、既存のＢＤ／ＤＶＤオーサリングシステム（ａｕｔｈｏｒｉｎｇ ｓｙｓｔｅｍｓ）においてよく支援されており、変更なしにあるいは若干の処理を通じて、次のような特徴、例えば、プレゼンテーショングラフィックモード（ｐｒｅｓｅｎｔａｔｉｏｎ ｇｒａｐｈｉｃ ｍｏｄｅ）を使用する３Ｄサブタイトル（ｓｕｂｔｉｔｌｅｓ）、フレームのトップ＆ボトム部分でのシフトされたオブジェクトを配置する３Ｄグラフィック、（それぞれのフレームを編集する必要なしに）クリップ（ｃｌｉｐ）全体にわたるエフェクト（ｅｆｆｅｃｔ）の適用、そして、ＢＤライブコンテンツオーサリング（ＢＤ Ｌｉｖｅ ｃｏｎｔｅｎｔ ａｕｔｈｏｒｉｎｇ）のようなものを容易にする。

図３４は、第一世代３ＤＴＶと第二世代３ＤＴＶ間の互換性を提供するサービスモデルを例示する。

上述したように、もし、左側及び右側映像がＳｐｅｃ−Ａを介して立体３Ｄビデオを構成すれば、それぞれの半分はハーフ解像度であり、そして、将来の立体３ＤＴＶサービスは高解像度で提供され得る。ここで、従来のビデオ要素は、既にハーフ解像度を支援しているので、フル解像度を支援するために、差動信号（ｄｉｆｆｅｒｅｎｔｉａｌ ｓｉｇｎａｌ）が相補型ビデオ要素を介して伝送される。結果的に、Ｓｐｅｃ−Ｂを支援する結果、受信機は、相補型ビデオ要素をＳｐｅｃ−Ａに加えることによって、フル解像度の３ＤＴＶサービスを提供することができる。そして、本発明は、Ｓｐｅｃ−Ｂに対する３ＤＴＶサービスを支援するために、相補型ビデオ要素を伝送する方法を提供する。

図３５は、本発明の実施例に係る３Ｄ相補型ビデオ情報を含むＴＶＣＴのシンタックス構造（ｓｙｎｔａｘ ｓｔｒｕｃｔｕｒｅ）を例示する。

図３５のＴＶＣＴに含まれたフィールド（ｆｉｅｌｄ）の説明は、次の通りである。

‘ｔａｂｌｅ_ｉｄ’フィールドは、テーブルセクション（ｔａｂｌｅ ｓｅｃｔｉｏｎ）のタイプを表示する８−ビットの符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ ｎｕｍｂｅｒ）フィールドである。

‘ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒ’フィールドは、１−ビットのフィールドであって、このフィールドは、‘ｔｅｒｒｅｓｔｒｉａｌ_ｖｉｒｔｕａｌ_ｃｈａｎｎｅｌ_ｔａｂｌｅ_ｓｅｃｔｉｏｎ（）’フィールドに対して‘１’に設定される。

‘ｐｒｉｖａｔｅ_ｉｎｄｉｃａｔｏｒ’フィールドは、‘１’に設定される１−ビットのフィールドである。

‘ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈ’フィールドは、先頭の２ビットが‘００’に設定される１２−ビットのフィールドであり、そして、‘ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈ’フィールドの直後に始まる、そして、ＣＲＣを含むセクションのバイトの数を特定する。

‘ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ’フィールドは、１６−ビットのＭＰＥＧ−２伝送ストリーム（ＴＳ）ＩＤを表示する。‘ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ’フィールドは、ＴＶＣＴ（Ｔｅｒｒｅｓｔｒｉａｌ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）を、互いに異なるＰＴＣで放送され得る他のものと区分する。

５−ビットのフィールドとしてサービスを提供する‘ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒ’フィールドは、ＶＣＴ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）のバージョン番号を表示する。

‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドは、１−ビットの表示子（ｉｎｄｉｃａｔｏｒ）である。‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドが‘１’に設定された場合、これは、伝送されたＶＣＴ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）が現在適用可能であることを意味する。‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドのビットが‘０’に設定された場合、これは、伝送されたテーブルがまだ適用不可能であり、次のテーブルが有効になることを意味する。

‘ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ’フィールドは、このセクションの数を提供する８−ビットのフィールドである。

８−ビットのフィールドとしてサービスを提供する‘ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ’フィールドは、完全なＴＶＣＴ（Ｔｅｒｒｅｓｔｒｉａｌ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）の最後のセクション（即ち、最も高いｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ値を有するセクション）の番号を特定する。

８−ビットの符号なし整数フィールドとしてサービスを提供する‘ｐｒｏｔｏｃｏｌ_ｖｅｒｓｉｏｎ’フィールドは、将来に、テーブルタイプが（現在のプロトコルで定義されたものとは異に構成され得る）パラメータを運搬できるようにするのに使用される。

８−ビットのフィールドとしてサービスを提供する‘ｎｕｍ_ｃｈａｎｎｅｌｓ_ｉｎ_ｓｅｃｔｉｏｎ’フィールドは、このＶＣＴセクションにおいて仮想チャネルの番号を特定する。

‘ｓｈｏｒｔ_ｎａｍｅ’フィールドは、仮想チャネルの名称を表示することができ、これは、ユニコードキャラクターデータ（ｕｎｉｃｏｄｅ ｃｈａｒａｃｔｅｒ ｄａｔａ）に対するＵＴＦ−１６標準に従って解釈される１〜７の１６−ビットのコード値のシーケンスとして表現される。

‘ｍａｊｏｒ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ’フィールドは、‘ｆｏｒ’ループ（ｌｏｏｐ）の繰り返しで定義される仮想チャネルと関連する‘メジャー（ｍａｊｏｒ）’チャネル番号を表現する１０−ビットの数を表示する。

‘ｍｉｎｏｒ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ’フィールドは、‘マイナー（ｍｉｎｏｒ）’あるいは‘サブ（ｓｕｂ）’チャネル番号を示すように、‘０’〜‘９９９’の範囲の１０−ビットの数を表示する。‘ｍａｊｏｒ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ’フィールドと共に、この‘ｍｉｎｏｒ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒ’フィールドは２−部分のチャネル番号を表示することができ、ここで、ｍｉｎｏｒ_ｃｈａｎｎｅｌ_ｎｕｍｂｅｒは、番号の第２あるいは右側部分を示す。

８−ビットの符号なし整数を含む‘ｍｏｄｕｌａｔｉｏｎ_ｍｏｄｅ’フィールドは、仮想チャネルと関連する伝送されたキャリアに対する変調モードを表示することができる。

‘ｃａｒｒｉｅｒ_ｆｒｅｑｕｅｎｃｙ’フィールドは、許容されたキャリア周波数を表示することができる。

‘ｃｈａｎｎｅｌ_ＴＳＩＤ’フィールドは、０ｘ００００〜０ｘＦＦＦＦの範囲の１６−ビットの符号なし整数フィールドである。‘ｃｈａｎｎｅｌ_ＴＳＩＤ’フィールドは、仮想チャネルによって参照されるＭＰＥＧ−２プログラムを運搬する伝送ストリーム（ＴＳ）と関連するＭＰＥＧ−２伝送ストリーム（ＴＳ）ＩＤを示す。

‘ｐｒｏｇｒａｍ_ｎｕｍｂｅｒ’フィールドは、ここで定義される仮想チャネルをＭＰＥＧ−２プログラム関連及びＴＳプログラムマップテーブルと関連付ける１６−ビットの符号なし整数を含む。

２−ビットのフィールドとしてサービスを提供する‘ＥＴＭ_ｌｏｃａｔｉｏｎ’フィールドは、拡張されたテキストメッセージ（Ｅｘｔｅｎｄｅｄ Ｔｅｘｔ Ｍｅｓｓａｇｅ、ＥＴＭ）の存在及び位置を特定する。‘ａｃｃｅｓｓ_ｃｏｎｔｒｏｌｌｅｄ’フィールドは、１−ビットのブールフラグ（Ｂｏｏｌｅａｎ ｆｌａｇ）を表示する。‘ａｃｃｅｓｓ_ｃｏｎｔｒｏｌｌｅｄ’フィールドのブールフラグが設定される場合、これは、仮想チャネルと関連するイベントにアクセスすることが制御され得ることを意味する。

‘ｈｉｄｄｅｎ’フィールドは、１−ビットのブールフラグを表示する。‘ｈｉｄｄｅｎ’フィールドのブールフラグが設定される場合、これは、仮想チャネルが仮想チャネル番号のダイレクトエントリー（ｄｉｒｅｃｔ ｅｎｔｒｙ）によってユーザによってアクセスされないことを意味する。

‘ｈｉｄｅ_ｇｕｉｄｅ’フィールドは、ブールフラグを表示する。‘ｈｉｄｅ_ｇｕｉｄｅ’フィールドのブールフラグがヒドンチャネル（ｈｉｄｄｅｎ ｃｈａｎｎｅｌ）に対してゼロ（‘０’）に設定される場合、これは、仮想チャネル及び仮想チャネルイベントがＥＰＧディスプレイに現れ得ることを意味する。

‘ｓｅｒｖｉｃｅ_ｔｙｐｅ’フィールドは、仮想チャネルで運搬されるサービスのタイプを識別し得る６−ビットの列挙型フィールド（６−ｂｉｔ ｅｎｕｍｅｒａｔｅｄ ｔｙｐｅ ｆｉｅｌｄ）である。

‘ｓｏｕｒｃｅ_ｉｄ’フィールドは、仮想チャネルと関連するプログラミングソースを識別し得る１６−ビットの符号なし整数を含む。

‘ｄｅｓｃｒｉｐｔｏｒｓ_ｌｅｎｇｔｈ’フィールドは、仮想チャネルに対するデスクリプタの全長（単位はバイト）を表示することができる。

‘ｄｅｓｃｒｉｐｔｏｒ（）’フィールドは、‘ｄｅｓｃｒｉｐｔｏｒ（）’フィールドに対して適切であると決定されたゼロ（０）あるいは１つ以上のデスクリプタをを含むことができる。

‘ａｄｄｉｔｉｏｎａｌ_ｄｅｓｃｒｉｐｔｏｒｓ_ｌｅｎｇｔｈ’フィールドは、ＶＣＴデスクリプタリスト（ｄｅｓｃｒｉｐｔｏｒ ｌｉｓｔ）の全長（単位はバイト）を表示することができる。

‘ＣＲＣ_３２’フィールドは、ＴＶＣＴ（Ｔｅｒｒｅｓｔｒｉａｌ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｔａｂｌｅ）セクション全体のプロセシングの後、ＩＳＯ／ＩＥＣ １３８１８ １ “ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ” ［８］のＡｎｎｅｘ Ａで定義されたデコーダ内のレジスタのゼロ（０）出力を保障するＣＲＣ値が含まれた３２−ビットのフィールドである。

対応するチャネルから提供される放送サービスが３Ｄサービス２．０である場合、ｓｅｒｖｉｃｅ_ｔｙｐｅフィールド８０１０は、この情報を表示するフィールドに対応する。例えば、ｓｅｒｖｉｃｅ_ｔｙｐｅフィールド８０１０のフィールド値が０ｘ１３である場合、これは、３Ｄ放送プログラム（３Ｄ立体映像をディスプレイするためのオーディオ、ビデオ、及び相補型ビデオデータ）が、対応する仮想チャネルから提供されていることを表示する。デスクリプタフィールド８０２０は、３Ｄ相補型ビデオ情報を含み、これについては、添付の図面を参照して詳細に後述する。

図３６は、本発明の実施例に係るＴＶＣＴに含まれた３Ｄ相補型ビデオデスクリプタのシンタックス構造を例示する。

図３６の３Ｄ相補型ビデオデスクリプタに含まれたフィールドが、次のように説明される。

ｎｕｍｂｅｒ_ｅｌｅｍｅｎｔｓフィールドは、それぞれの仮想チャネルを構成するビデオ要素の数を表示する。放送受信機は、３ＤＴＶサービス位置デスクリプタを受信することができ、これによって、回数としてｎｕｍｂｅｒ_ｅｌｅｍｅｎｔｓフィールドの下のフィールドに含まれた情報をパージングする（この数は、それぞれの仮想チャネルを構成するビデオ要素の数に対応する）。

ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータあるいは相補型ビデオストリームを構成する方法を表示する。フル解像度の映像が出力される場合、受信システムは、ベースビデオデータ及び相補型ビデオデータをフル解像度の映像で再構成（あるいは再建）するために、このフィールドの情報を用いる。

ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドは、ベースビデオコンポーネント及び相補型ビデオコンポーネントが構成されている場合、サブサンプリング（ｓｕｂｓａｍｐｌｉｎｇ）が行われているか否か、あるいは、ローパスフィルタリング及びハイパスフィルタリングが行われているか否かを表示する。例えば、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値が１と同一であれば、これは、サブサンプリングが行われていることを示す。そして、このフィールド値が０と同一であれば、これは、ローパスフィルタリング及びハイパスフィルタリングが行われていることを示す。

ｃｏｄｅｃ_ｔｙｐｅフィールドは、相補型ビデオコンポーネントをエンコーディングあるいは圧縮するために使用されるビデオコーデックのタイプを表示する。例えば、ｃｏｄｅｃ_ｔｙｐｅフィールドのフィールド値に応じて、ＭＰＥＧ−２、ＡＶＣ／Ｈ．２６４、ＳＶＣ拡張などのようなコーディング技法を示すことができる。

ｈｏｒｉｚｏｎｔａｌ_ｓｉｚｅフィールド、ｖｅｒｔｉｃａｌ_ｓｉｚｅフィールド、及びｆｒａｍｅ_ｒａｔｅフィールドは、それぞれ、相補型ビデオコンポーネントの水平サイズ、垂直サイズ、及びフレームレートを表示する。ここで、水平サイズ及び垂直サイズは空間解像度を表示することができ、そして、フレームレートは時間解像度を表示することができる。例えば、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が０ｘ０００４と同一である場合、相補型ビデオコンポーネントの空間／時間解像度は両方ともフル解像度となり得る。

ｉｎｔｅｒｐｏｌａｔｉｏｎ_ｆｉｌｔｅｒ_ａｖａｉｌａｂｌｅ_ｆｌａｇフィールドは、ベースビデオコンポーネントに対して補間が行われる場合、追加のカスタマイズされたフィルター（ｅｘｔｒａ ｃｕｓｔｏｍｉｚｅｄ ｆｉｌｔｅｒ）が使用されているか否かを表示する。このとき、本発明の実施例によれば、フィルターを具現するためのフィルター係数のような情報が、ＴＶＣＴあるいはＰＭＴ内の相補型ビデオコンポーネントに対するデスクリプタループに含まれてもよく、デスクリプタのフォーマットで提供されてもよい。そして、本発明の他の実施例によれば、この情報は、ビデオ要素内のヘッダー情報あるいはメッセージ情報に含まれてもよく、それによって提供されるようになる。相補型ビデオ情報を構成する左側視覚に対するビデオデータ及び右側視覚に対するビデオデータのうち、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドは、２つのビデオデータのどちらが先に起こるか（あるいは発生するか）を表示する。本発明の実施例によれば、左側視覚に対応するビデオデータが先に受信される場合、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は１に設定されてもよい。

ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドは、フル解像度の映像を構成する手順の間、ベースビデオコンポーネントと相補型ビデオコンポーネントを結合する順序を表示する。本発明の実施例によれば、ベースビデオコンポーネントに対応するビデオデータが、相補型ビデオコンポーネントに対応するビデオデータよりも先行する場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は１に設定されてもよい。

図３７は、本発明の実施例に係る、３Ｄ相補型ビデオ情報に含まれたｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値に応じて映像を構成する方法を例示する。

図３６に含まれたｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータあるいは相補型ビデオストリームを構成する方法を表示する。そして、受信システムは、ベースビデオデータ及び相補型ビデオデータをフル解像度の映像で再構成（あるいは再建）するために、このフィールドの情報を用いる。ここで、本発明の実施例によれば、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値によるフル解像度の映像の再構成（あるいは再建）は、図３７に示したように様々に行われてもよい。

１）ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が０と同一である場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータがラインインターリーブ（ｌｉｎｅｉｎｔｅｒｌｅａｖｅ）され、相補型ラインのためのビデオデータを運搬していることを示す。

相補型ビデオデータは、偶数ラインあるいは奇数ラインに対するビデオデータを含むことができ、これらは、フル解像度の映像を構成するためにベースビデオデータに加えられる。偶数ラインあるいは奇数ラインに対するビデオデータは、ベースビデオデータのマルチプレクシングフォーマットに従って水平または垂直にライン−インターリーブされてもよく、それによって発生（あるいは生成）するようになる。本発明の実施例によれば、ベースビデオデータがサイド−バイ−サイドフォーマットに対応する場合、垂直ライン−インターリーブが行われ、そして、ベースビデオデータがトップ−ボトムフォーマットに対応する場合、水平ライン−インターリーブが行われてもよい。

２）ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が１と同一である場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータがピクセルインターリーブ（ｐｉｘｅｌｉｎｔｅｒｌｅａｖｅ）され、それぞれのラインに対して交互（あるいは変更）する映像のパースペクティブに関する順序情報を運搬していることを示す。ここで、順序情報は、フル解像度の映像を再構成するためのピクセルに関する情報に対応する。

相補型ビデオデータは、ピクセル単位でインターリーブされてもよく、それによってチェッカーボードのフォーマットで伝送され得る。この場合に、左側映像のピクセルと右側映像のピクセルが単一のライン内でピクセル単位で（あるいはピクセル別に）交互してもよい。また、フル解像度の映像を正常的に復元するために、受信システムは、交互の順序に関するこの情報を伝送するように要求される。この場合に、再構成（あるいは再建）されているフル解像度の映像の第１ピクセルに含まれたビデオデータに関して、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドは、第１ピクセルに含まれたビデオデータがどのパースペクティブあるいは層に対応するかを表示する。

３）ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が２と同一である場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータがフレーム−インターリーブ（ｆｒａｍｅ−ｉｎｔｅｒｌｅａｖｅ）され、フル解像度の映像を再構成（あるいは再建）するための相補型フレームを含むことを示す。

本発明の実施例によれば、フル解像度は時間解像度を意味する。この場合に、相補型ビデオデータは、フレーム単位で（あるいはフレーム別に）インターリーブされた映像データを含むことができ、そして、フレーム別に（あるいはフレーム順次に）ビデオデータを含むこともできる。ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドは、相補型ビデオコンポーネントを介して受信されているビデオフレームが、ベースビデオコンポーネントを介して受信されているビデオフレームの前に位置するか、または後に位置するかを受信システムに知らせることができる。

４）ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が３と同一である場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータがフィールドインターリーブ（ｆｉｅｌｄｉｎｔｅｒｌｅａｖｅ）され、フル解像度の映像を再構成（あるいは再建）するための相補型フレームを含むことを示す。

本発明の実施例によれば、フル解像度は時間解像度を意味する。この場合に、相補型ビデオデータは、フィールド単位で（あるいはフィールド別に）インターリーブされた映像データを含むことができ、そして、フィールド別にビデオデータを含むこともできる。ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドは、相補型ビデオコンポーネントを介して受信されているビデオフィールドが、フル解像度の映像に対する偶数フィールドに対応するか、または奇数フィールドに対応するかを受信システムに知らせることができる。

５）ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値が４と同一である場合、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドは、相補型ビデオデータがフル解像度の映像を再構成（あるいは再建）するための残留（ｒｅｓｉｄｕａｌ）あるいは増分（ｉｎｃｒｅｍｅｎｔａｌ）データを含むことを示すことができる。

本発明の実施例によれば、ベースビデオコンポーネントの立体−マルチプレクシングフォーマットに関係なく、相補型ビデオコンポーネントは、フル解像度の映像を再構成（あるいは再建）するための残留あるいは増分データを含む。この場合に、相補型ビデオデータとベースビデオデータを結合させる前に、受信システムは、ベースビデオデータに対して補間あるいはダブリング（ｄｏｕｂｌｉｎｇ）を行うことができる。

図３８は、ＰＭＴでの３Ｄ相補型ビデオデスクリプタのシグナリングの実施例を例示する。言い換えると、ＰＭＴ内の３Ｄ相補型ビデオデスクリプタは、フル解像度の３Ｄ立体プログラムを構成する相補型ビデオ要素を提供する。

３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ_ＰＭＴは、ＰＭＴ内でＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈフィールドの後に位置し、エレメンタリーストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）に対応する情報を含む。それぞれのフィールドの意味は３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ_ＶＣＴと同一である。ｃｏｄｅｃ_ｔｙｐｅが、ＰＭＴ内でｓｔｒｅａｍ_ｔｙｐｅフィールドで代替されてもよく、この場合、３Ｄ相補型ビデオデスクリプタは省略してもよい。

次いで、ＰＭＴを使用して３Ｄ相補型ビデオ情報をシグナリングするための方法が詳細に説明される。

図３９は、本発明の実施例に係る３Ｄ相補型ビデオ情報を含むＰＭＴのシンタックス構造を例示する。

図３９のＰＭＴに含まれたフィールドは、次のように説明される。‘ｔａｂｌｅ_ｉｄ’フィールドは、‘ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ’フィールドにおいて常に‘０ｘ０２’に設定される８−ビットのフィールドである。

‘ｓｅｃｔｉｏｎ_ｓｙｎｔａｘ_ｉｎｄｉｃａｔｏｒ’フィールドは、‘１’に設定される１−ビットのフィールドである。

‘ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈ’フィールドは、先頭の２ビットが‘００’に設定される１２−ビットのフィールドであり、そして、‘ｓｅｃｔｉｏｎ_ｌｅｎｇｔｈ’フィールドの直後に始まり、そして、ＣＲＣを含むセクションのバイトの数を特定する。

‘ｐｒｏｇｒａｍ_ｎｕｍｂｅｒ’フィールドは、１６−ビットのフィールドであり、これは、‘ｐｒｏｇｒａｍ_ｍａｐ_ＰＩＤ’フィールドが適用可能なプログラムを特定する。

‘ｖｅｒｓｉｏｎ_ｎｕｍｂｅｒ’フィールドは、５−ビットのフィールドであり、これは、‘ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ’フィールドのバージョン番号を表示する。

‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドは、１−ビットのフィールドである。‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドのビットが‘１’に設定される場合、これは、伝送された‘ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ’フィールドが現在適用可能であることを意味する。‘ｃｕｒｒｅｎｔ_ｎｅｘｔ_ｉｎｄｉｃａｔｏｒ’フィールドのビットが‘０’に設定された場合、これは、伝送された‘ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ’フィールドがまだ適用不可能であり、次の‘ＴＳ_ｐｒｏｇｒａｍ_ｍａｐ_ｓｅｃｔｉｏｎ’フィールドが有効になるということを意味する。

‘ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ’フィールドは、‘０ｘ００’となる８−ビットのフィールドの値を含む。

‘ｌａｓｔ_ｓｅｃｔｉｏｎ_ｎｕｍｂｅｒ’フィールドは、‘０ｘ００’となる８−ビットのフィールドの値を含む。

‘ＰＣＲ_ＰＩＤ’は、‘ｐｒｏｇｒａｍ_ｎｕｍｂｅｒ’フィールドによって特定されたプログラムに対して有効なＰＣＲフィールドを含む伝送ストリーム（ＴＳ）パケットのＰＩＤを表示する１３−ビットのフィールドである。この場合、いかなるＰＣＲもプライベートストリーム（ｐｒｉｖａｔｅ ｓｔｒｅａｍ）に対するプログラムの定義と関連しなければ、このフィールドは、‘０ｘ１ＦＦＦ’の値を取ることになる。

‘ｐｒｏｇｒａｍ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドは、１２−ビットのフィールドであり、その先頭の２ビットは‘００’である。‘ｐｒｏｇｒａｍ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドは、‘ｐｒｏｇｒａｍ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドの直後のデスクリプタのバイトの数を特定する。

‘ｓｔｒｅａｍ_ｔｙｐｅ’フィールドは、ＰＩＤ（その値は、‘ｅｌｅｍｅｎｔａｒｙ_ＰＩＤ’フィールドによって特定される）を有するパケット内で運搬されるエレメンタリーストリームあるいはペイロード（ｐａｙｌｏａｄ）のタイプを特定する８−ビットのフィールドである。追加的に、‘ｓｔｒｅａｍ_ｔｙｐｅ’フィールドは、対応するビデオ要素のコーディングタイプを表示することができる。例示的なコーディングタイプとして、ＪＰＥＧ、ＭＰＥＧ−２、ＭＰＥＧ−４、Ｈ．２６４／ＡＶＣ、Ｈ．２６４／ＳＶＣあるいはＨ．２６４／ＭＶＣ技法を用いることができる。

‘ｅｌｅｍｅｎｔａｒｙ_ＰＩＤ’フィールドは、関連するエレメンタリーストリームあるいはペイロードを運搬する伝送ストリーム（ＴＳ）パケットのＰＩＤを特定する１３−ビットのフィールドである。このＰＩＤは、１次ビデオデータ（ｐｒｉｍａｒｙ ｖｉｄｅｏ ｄａｔａ）あるいは２次ビデオデータ（ｓｅｃｏｎｄａｒｙ ｖｉｄｅｏ ｄａｔａ）として用いることができる。

‘ＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドは、１２−ビットのフィールドであり、その先頭の２ビットは‘００’となる。‘ＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドは、‘ＥＳ_ｉｎｆｏ_ｌｅｎｇｔｈ’フィールドの直後の、関連するエレメンタリーストリームのデスクリプタのバイトの数を特定することができる。

‘ＣＲＣ_３２’フィールドは、伝送ストリームプログラムマップセクション全体のプロセシングの後、Ａｎｎｅｘ Ｂにおいて定義されたデコーダ内のレジスタのゼロ（０）出力を提供するＣＲＣ値が含まれた３２−ビットのフィールドである。

デスクリプタフィールド１１０１０は３Ｄ相補型ビデオ情報を含み、これについては、添付の図面を参照して詳細に後述する。

次いで、相補型ビデオデータに含まれた相補型ビデオＥＳを通じて３Ｄ相補型ビデオ情報をシグナリングするための方法について詳細に後述する。

図４０は、本発明の実施例に係る、３Ｄ相補型ビデオ情報を含むビデオＥＳのピクチャ拡張及びユーザデータ（Ｐｉｃｔｕｒｅ Ｅｘｔｅｎｓｉｏｎ ａｎｄ ｕｓｅｒ Ｄａｔａ）のシンタックス構造を例示する。

本発明の実施例によれば、ＡＴＳＣ遠隔通信システムは、ＰＩＳＰ階の代わりに、ビデオＥＳのヘッダー情報に３Ｄ相補型ビデオ情報を含むことができ、対応する情報をシグナリングすることができる。より具体的に、３Ｄ相補型ビデオ情報（ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｉｎｆｏ（））１３０３０は、相補型ビデオＥＳに含まれてもよく、それによって伝送されるようになり、そして、ビデオデコーダ内の対応する情報をパージングすることによって、受信システムは、ディスプレイ出力を制御するために要求される情報を獲得することができる。

本発明の実施例によれば、相補型ビデオデータが、ＭＰＥＧ−２ビデオコーディング技法を用いてエンコーディングされるとき、３Ｄ相補型ビデオ情報は、ピクチャ拡張及びユーザデータのｕｓｅｒ_ｄａｔａ（）１３０１０内に含まれてもよく、それによって伝送されることになる。ピクチャ拡張及びユーザデータは、ピクチャヘッダー及びピクチャコーディング拡張の後に受信されてもよくて、それによってデコーディングされる。

図４０の実施例において、ｕｓｅｒ_ｄａｔａ_ｓｔａｒｔ_ｃｏｄｅフィールドのフィールド値は、０ｘ００００ ０１Ｂ２に固定される。

ｕｓｅｒ_ｄａｔａ_ｉｄｅｎｔｉｆｉｅｒ（あるいはＡＴＳＣ_ｉｄｅｎｔｉｆｉｅｒ）フィールドのフィールド値は、０ｘ４７４１ ３９３４の値が与えられる３２−ビットのコードに対応する。

ｕｓｅｒ_ｄａｔａ_ｔｙｐｅ_ｃｏｄｅフィールドは、ＡＴＳＣユーザデータ１３０２０のデータタイプを表示し、８ビットのフィールド値を有することができる。本発明の実施例によれば、０ｘ１０の値を用いることによって、このフィールドは、３Ｄ相補型ビデオ情報１３０３０が含まれていることを示すことができる。

Ｈ．２６４あるいはＡＶＣビデオの場合に、対応する情報は、図４１に例示したようにＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）領域に伝送される。ｕｓｅｒ_ｉｄｅｎｔｉｆｉｅｒ及びｕｓｅｒ_ｓｔｒｕｃｔｕｒｅがｕｓｅｒ_ｄａｔａ_ｒｅｇｉｓｔｅｒｅｄ_ｉｔｕ_ｔ_１３５（）に含まれる。したがって、対応する情報が、ｕｓｅｒ_ｄａｔａ（）の代わりにＳＥＩペイロードで伝達される。

以下では、３ＤビデオサービスＳｐｅｃ−Ｂから受信された、ベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオデータを用いてフル解像度の映像を提供するための方法が詳細に説明される。

図４２は、本発明の実施例に係る、３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する。

図４２の実施例において、ベースビデオデータの映像はトップ−ボトムフォーマットで受信され、ここで、左側映像は上側に位置し、右側映像は下側に位置する。３Ｄ相補型ビデオ情報の場合に、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値は‘０ｘ００００’として表示され、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、そして、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘０’として表示される。より具体的には、３Ｄ相補型ビデオ情報は、相補型ビデオデータがライン−インターリーブでプロセシングされることを表示し、ローパスフィルタリング及びハイパスフィルタリングはサブサンプリングの実行時に行われないことを表示し、左側視覚に対応するビデオデータが先に提示されることを表示し、そして、ベースビデオに対応するビデオデータが、相補型ビデオに対応するビデオデータよりも先行することを表示する。

３Ｄ相補型ビデオ情報に従って、受信システムは、トップ−ボトムフォーマットのベースビデオフレーム１６０１０から左側映像部分Ｌｂ１〜Ｌｂ５を抽出し、相補型ビデオフレーム１６０２０から左側映像部分Ｌｃ１〜Ｌｃ５を抽出し、そして、抽出されたビデオデータをライン別に再構成（あるいは再建）し、それによって、フル解像度の左側映像１６０３０が獲得される。同様に、３Ｄ相補型ビデオ情報に従って、受信システムは、トップ−ボトムフォーマットのベースビデオフレーム１６０１０から右側映像部分Ｒｂ１〜Ｒｂ５を抽出し、相補型ビデオフレーム１６０２０から右側映像部分Ｒｃ１〜Ｒｃ５を抽出し、そして、抽出されたビデオデータをライン別に再構成（あるいは再建）し、それによって、フル解像度の右側映像１６０４０が獲得される。

受信システムが、獲得されたフル解像度の左側映像１６０３０及び右側映像１６０４０をフレーム順次技法を用いてディスプレイすることができる。この場合、２つのフレーム１６０３０，１６０４０は、１つのフレーム１６０１０からフレーム単位で発生したので、時間的フル解像度のディスプレイが利用可能となる。

図４３は、本発明の更に他の実施例に係る、３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する。

図４３の実施例において、ベースビデオデータの映像はトップ−ボトムフォーマットで受信され、ここで、左側映像は上側に位置し、右側映像は下側に位置する。３Ｄ相補型ビデオ情報の場合に、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値は‘０ｘ００００’として表示され、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値は‘０’として表示され、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、そして、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘０’として表示される。より具体的には、３Ｄ相補型ビデオ情報は、相補型ビデオデータがライン−インターリーブでプロセシングされることを表示し、ローパスフィルタリング及びハイパスフィルタリングはサブサンプリングの実行時に行われなければならないことを表示し、左側視覚に対応するビデオデータが先に提示されることを表示し、そして、ベースビデオに対応するビデオデータが、相補型データに対応するビデオデータよりも先行することを表示する。

まず、３Ｄ相補型ビデオ情報に従って、受信システムは、ベースビデオフレームに対してローパスフィルタリングを行い、それによって、フィルタリングされたベースビデオフレームＬｂ１’〜Ｌｂ５’及びＲｂ１’〜Ｒｂ５’が獲得される。また、受信システムは、相補型ビデオフレームに対してハイパスフィルタリングを行い、それによって、フィルタリングされた相補型ビデオフレームＬｃ１’〜Ｌｃ５’及びＲｃ１’〜Ｒｃ５’が獲得される。

３Ｄ相補型ビデオ情報に従って、受信システムは、トップ−ボトムフォーマットのベースビデオフレームから、ローパスフィルタリングされた左側映像部分Ｌｂ１’〜Ｌｂ５’を抽出し、相補型ビデオフレームから、ローパスフィルタリングされた左側映像部分Ｌｃ１’〜Ｌｃ５’を抽出する。その後、受信システムは、抽出されたビデオデータをライン別に再構成（あるいは再建）し、それによってフル解像度の左側映像１７０３０が獲得される。同様に、３Ｄ相補型ビデオ情報に従って、受信システムは、トップ−ボトムフォーマットのベースビデオフレームから、ローパスフィルタリングされた右側映像部分Ｒｂ１’〜Ｒｂ５’を抽出し、相補型ビデオフレームから、ローパスフィルタリングされた右側映像部分Ｒｃ１’〜Ｒｃ５’を抽出する。その後、受信システムは、抽出されたビデオデータをライン別に再構成（あるいは再建）し、それによってフル解像度の右側映像１７０４０が獲得される。

受信システムが、獲得されたフル解像度の左側映像１７０３０及び右側映像１７０４０をフレーム順次技法を用いてディスプレイすることができる。この場合、２つのフレーム１７０３０，１７０４０は、１つのフレーム１７０１０からフレーム単位で発生したので、時間的フル解像度のディスプレイが利用可能となる。

図４４は、本発明の更に他の実施例に係る、３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する。

図４４の実施例において、ベースビデオデータの映像は、トップ−ボトムフォーマットで受信され、ここで、左側映像は上側に位置し、右側映像は下側に位置する。３Ｄ相補型ビデオ情報の場合に、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値は‘０ｘ０００４’として表示され、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、そして、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘０’として表示される。より具体的には、３Ｄ相補型ビデオ情報は、相補型ビデオデータがベースビデオデータ（０ｘ０００４）に対する残留ビデオデータを含むことを表示し、ローパスフィルタリング及びハイパスフィルタリングはサブサンプリングの実行時に行われないことを表示し、左側視覚に対応するビデオデータが先に提示されることを表示し、そして、ベースビデオに対応するビデオデータが、相補型ビデオに対応するビデオデータよりも先行することを表示する。

受信システムは、先に受信されたベースフレーム１８０１０に対してライン別補間を行い、それによって、空間的に２倍になったビデオフレーム１８０４０が獲得される。その後、受信システムは、補間されたラインＬｉ１，Ｌｉ２，．．．，Ｒｉ５を相補型ビデオフレーム１８０２０の残留データラインＬｃ１〜Ｌｃ１０及びＲｃ１〜Ｒｃ１０と結合させる。その後、該結合されたラインをライン別にベースビデオフレームのラインと共に位置させることによって、フル解像度の左側映像１８０５０及び右側映像１８０６０が獲得される。本発明の実施例によれば、左側映像の場合、補間されたベースビデオフレーム１８０４０のラインＬｉ１は、相補型ビデオフレーム１８０２０のラインＬｃ１及びＬｃ２のデータと結合され、それによって、フル解像度の映像１８０５０のライン映像Ｌｃ１が獲得される。次いで、該ライン映像Ｌｃ１をライン映像Ｌｂ１とＬｂ２との間に位置させる方法を用いることによって、フル解像度の左側映像１８０５０を獲得することができる。

受信システムは、獲得されたフル解像度の左側映像１８０５０及び右側映像１８０６０をフレーム順次技法を用いてディスプレイすることができる。この場合、２つのフレーム１８０５０，１８０６０は、１つのフレーム１８０１０からフレーム単位で発生したので、時間的フル解像度のディスプレイが利用可能となる。

図４５は、本発明の更に他の実施例に係る、３ＤビデオサービスＳｐｅｃ−Ｂから受信されたベースビデオデータ、相補型ビデオデータ、及び３Ｄ相補型ビデオ情報を用いてフル解像度の映像を提供するための方法を例示する。図４５の実施例において、ベースビデオデータの映像は、チェッカーボードフォーマットで受信され、ここで、左側映像は、左側端部（ｌｅｆｔ−ｅｎｄ ｐｏｒｔｉｏｎ）の最上位ピクセル（ｕｐｐｅｒｍｏｓｔ ｐｉｘｅｌ）に位置する。３Ｄ相補型ビデオ情報の場合に、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅフィールドのフィールド値は‘０ｘ０００１’として表示され、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘１’として表示され、そして、ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇフィールドのフィールド値は‘０’として表示される。より具体的には、３Ｄ相補型ビデオ情報は、相補型ビデオデータがベースビデオ映像（０ｘ０００１）に対する相補型ビデオ映像のライン−交互順序（ｌｉｎｅ−ａｌｔｅｒｎａｔｉｎｇ ｏｒｄｅｒ）を含むことを表示し、ローパスフィルタリング及びハイパスフィルタリングはサブサンプリングの実行時に行われないことを表示し、左側視覚に対応するビデオデータが先に提示されることを表示し、そして、ベースビデオに対応するビデオデータが、相補型データに対応するビデオデータよりも先行することを表示する。

受信システムは、３Ｄ相補型ビデオ情報を用いることによって、それぞれの順序に従ってそれぞれのラインに対して、受信されたベースビデオフレーム１９０１０に含まれた左側視覚のピクセルと右側視覚のピクセルを整列し、そして、受信された相補型ビデオフレーム１９０２０に含まれた左側視覚のピクセルと右側視覚のピクセルを整列する。したがって、フル解像度の左側映像１９０３０及び右側映像１９０４０を獲得することができる。また、本発明の実施例によれば、受信システムは、受信されたベースビデオフレーム１９０１０及び相補型ビデオフレーム１９０２０をサイド−バイ−サイドフォーマットあるいはトップ−ボトム映像フォーマットで再構成（あるいは再建）する。その後、受信システムは、再構成されたビデオフレームを３Ｄ相補型ビデオ情報に従って整列し、それによって、フル解像度の左側映像１９０３０及び右側映像１９０４０が獲得される。

受信システムは、獲得されたフル解像度の左側映像１９０３０及び右側映像１９０４０をフレーム順次技法を用いてディスプレイすることができる。この場合、２つのフレーム１９０３０，１９０４０は、１つのフレーム１９０１０からフレーム単位で発生したので、時間的フル解像度のディスプレイが利用可能となる。

ベースビデオコンポーネントと相補型ビデオコンポーネントとを結合させることによってフル解像度のビデオコンポーネントを獲得する受信システムの動作は、本発明の上述した実施例に係る様々な実施例によって行われてもよい。

本発明の実施例によれば、ベースビデオコンポーネントをＢとし、そして、相補型ビデオコンポーネントをＣとし、そして、フル解像度のビデオコンポーネントをＦとする場合、次のような動作シナリオが利用可能である。

ケース１（ｃａｓｅ１）：Ｆ＝Ｂ＋Ｃ

ケース２（ｃａｓｅ２）：Ｆ＝Ｂ’＋Ｃ

ケース３（ｃａｓｅ３）：Ｆ＝Ｂ’＋Ｃ”

ここで、Ｂ’及びＣ’は、補間／フィルタリングでプロセシングされたＢ及びＣにそれぞれ対応する。

ケース１は、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値が‘１’と同じ例に対応する。したがって、このケースは、２つのサブサンプリングされたビデオコンポーネントがインターリーブされ、整列される実施例に対応する。

ケース２は、Ｂが補間／フィルタリングでプロセシングされ、その後にＣと結合され、それによってＦが獲得される例に対応する。ここで、Ｃは、残留／増分データフォーマットに対応し得る。（特に、ＳＶＣコーディング技法が用いられる場合に、この形態の結合が行われてもよい。）

ケース３は、ｎａｉｖｅ_ｓｕｂｓａｍｐｌｉｎｇ_ｆｌａｇフィールドのフィールド値が‘０’と同じ例に対応する。したがって、このケースは、ＢとＣの両方とも補間／フィルタリングでプロセシングされ、Ｂ’がＣ”と結合され、それによってＦが獲得される実施例に対応する。

図４６は、ＳＤＴを用いて３ＤＴＶサービスをシグナリングすることを示す他の実施例である。

サービスデスクリプタは、（ビデオデータがＳｐｅｃ−Ｂの支援のために含まれるか否かをシグナリングする）３ＤＴＶ ２．０サービスであることを表示するサービスタイプを含む。また、ｄｅｓｃｒｉｐｔｏｒ（）は、Ｓｐｅｃ−Ｂに対応する３ＤＴＶサービスを構成する相補型ビデオコンポーネントに関する情報を含む。

図４７は、本発明の実施例に係る、Ｓｐｅｃ−Ｂを支援するためのフル解像度の立体３ＤＴＶサービスのサービスタイプを例示する。サービスタイプの値は、ＤＶＢのサービスデスクリプタに含まれたＳＤＴのデスクリプタループに含まれてもよい。従来のＳｐｅｃ−Ａと比較して、本発明に係る改善点は次の通りである。

１）Ｓｐｅｃ−Ａ及びＳｐｅｃ−Ｂサービスは個別的に定義されるが、それぞれのサービスを構成するストリームは共有される。Ｓｐｅｃ−Ｂの場合において、サービスタイプは、図４７で説明したように定義される。サービスを構成するベース層ストリームが共有されてもよく、そして、さらに、Ｓｐｅｃ−Ｂサービスは、フル解像度の３ＤＴＶサービスを提供するためにエンハンスメント層ストリームを含む。

２）単にＳｐｅｃ−Ａを構成してフル解像度のサービスを提供することも可能である。この場合、エンハンスメントストリームは個別値を持たず、これによって、従来のＳｐｅｃ−Ａ受信機は、エンハンスメントストリームを無視することになり、単にベース層ストリームでハーフ解像度を提供することになる。Ｓｐｅｃ−Ｂ支援受信機において、エンハンスメントストリームが認識され、受信機は、フル解像度のサービスを提供するためにベース層と結合することになる。

図４８は、ＳＤＴを用いて３ＤＴＶサービスをシグナリングするために付加されるＳｅｒｖｉｃｅ_ｔｙｐｅを例示する。図４９は、従来のコンポーネントデスクリプタのシンタックスを例示する。そして、図５０は、ＤＶＢ放送システムにおいてフル解像度の３Ｄ立体サービスを表示するためのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅの定義及び説明を例示する。

ＤＶＢのために構成されたそれぞれのエレメンタリーストリームは、ＳＤＴのデスクリプタ内にコンポーネントデスクリプタを加えることによってシグナリングを行う。本発明において、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅは、フル解像度の３Ｄ立体サービスを提供するために３Ｄ相補型ビデオを分離するように、図５０に示したように定義される。ＭＰＥＧ−２ビデオに対して、ストリームのタイプを表示するストリームタイプは０ｘ０１として定義され、そして、Ｈ．２６４ビデオに対して、これは０ｘ０５であるものと定義される。

図５１は、本発明の実施例に係る、ＳＤＴに含まれた３Ｄ相補型ビデオデスクリプタのシンタックス構造を例示する。

３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ_ＳＤＴは、ＳＤＴでのｄｅｓｃｒｉｐｔｏｒｓ_ｌｏｏｐ_ｌｅｎｇｔｈフィールドのデスクリプタ内に位置し、３Ｄ相補型エレメンタリーストリームに関する情報を含む。それぞれのフィールドの意味は、図３６で例示したように、３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ_ＶＣＴと同一である。ｃｏｄｅｃ_ｔｙｐｅが、ＳＤＴでのコンポーネントデスクリプタ内でｓｔｒｅａｍ_ｃｏｎｔｅｎｔ及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅフィールドで代替されてもよく、この場合、これはまた３Ｄ相補型ビデオデスクリプタから省略されてもよい。

さらに、ｃｏｍｐｏｎｅｎｔ_ｔａｇは、ＰＭＴのＥＳ_ｌｏｏｐのＥＳとコンポーネントデスクリプタとの関係を表示するために使用することができる。

３Ｄ相補型ビデオデスクリプタをＴＶＣＴを介して受信する受信機動作プロセスが説明される。

まず、ＴＶＣＴのｓｅｒｖｉｃｅ_ｔｙｐｅを使用して、対応する仮想チャネルがフル解像度の立体３ＤＴＶサービスを提供するか否かが決定される。また、Ｓｐｅｃ−Ｂを支援する受信機は、フル解像度の立体３ＤＴＶサービスが提供されるか、あるいは、ハーフ解像度の立体３ＤＴＶサービスと同一のｓｅｒｖｉｃｅ_ｔｙｐｅを使用することによって、３Ｄ相補型ビデオデスクリプタの存在によってそうでないかを決定することができる。

次に、もし、フル解像度の立体３ＤＴＶサービスが提供されると、３Ｄ立体ベースビデオコンポーネントのｅｌｅｍｅｎｔａｒｙ_ＰＩＤ情報（ＰＩＤ_Ｂ）が立体フォーマットデスクリプタを使用して受信される。

その後、相補型ビデオコンポーネントに関するエレメンタリーＰＩＤ情報（ＰＩＤ_Ｃ）が３Ｄ相補型ビデオデスクリプタを使用して受信される。

ＰＩＤ_Ｂに対応するベースビデオがデコーディングされ、その後、ＰＩＤ_Ｃに対応する相補型ビデオ信号がデコーディングされる。

フル解像度の左側映像及び右側映像が、３Ｄ相補型ビデオデスクリプタに含まれたｃｏｍｐｌｅｍｅｎｔａｒｙ_ｔｙｐｅ、ｌｅｆｔ_ｉｍａｇｅ_ｆｉｒｓｔ_ｆｌａｇ、及びｃｏｍｐｌｅｍｅｎｔａｒｙ_ｆｉｒｓｔ_ｆｌａｇを使用してベースビデオと相補型ビデオ信号とを結合することによって獲得される。その後、左側映像及び右側映像が、ユーザに３Ｄディスプレイを提供するためにフル解像度の立体ディスプレイに出力される。

図５２は、本発明の実施例に係る、３Ｄ相補型ビデオデスクリプタがＰＭＴを介してどのように受信されるかを例示する。

まず、ＰＭＴから、シグナリングされたエレメンタリーストリームにおいてＳｐｅｃ−Ａに対応するストリームが識別される。次に、ＰＭＴから、シグナリングされたエレメンタリーストリームにおいて相補型ビデオストリームが識別される。ＴＶＣＴを介して提供された情報及びｐｒｏｇｒａｍ_ｎｕｍｂｅｒフィールドを用いて、マッピング（ｍａｐｐｉｎｇ）が行われる。その後、ベースビデオが相補型ビデオ信号のデコーディングと共にデコーディングされる。

その後、左側映像及び右側映像を有するフル解像度が獲得される。最後に、フル解像度の立体ディスプレイが、ユーザに３Ｄとしてディスプレイされる。

図５３は、３Ｄ信号をパージングすることによって立体ビデオ信号を出力するためのフロープロセスを例示する。このプロセスは、以下で説明される。

まず、ＳＤＴが獲得され、ＴＳパケットがフィルタリングされる。その後、対応するサービスに関するＰＭＴ情報が獲得される。ＳＤＴ内でのサービスループを調べることによって、Ｓｐｅｃ−Ｂ ３Ｄサービスタイプ情報が獲得され、格納される。サービスに対応するＰＭＴ情報が獲得され、格納される。リンケージデスクリプタ（ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒ）を通じて、Ｓｐｅｃ−Ａ及びＳｐｅｃ−Ｂ情報が決定される。Ｓｐｅｃ−Ｂに対するＰＭＴ情報が、相補型ビデオストリームに対するＰＩＤ情報を決定するために用いられる。

もし、受信機がＳｐｅｃ−Ｂを受信できれば、Ｓｐｅｃ−Ｂ ３Ｄビデオを提供するｓｅｒｖｉｃｅ_ｉｄが選択され、相補型ビデオストリームのＰＩＤフィルター及び従来のＡ／Ｖストリームと共に、ビデオ／オーディオに関するＥＳデコーディングが行われる。その後、フル解像度の３Ｄビデオが再構成制御によって出力され、３Ｄビデオ出力の変換が、相補型ビデオデスクリプタ情報を用いて行われる。

もし、受信機がＳｐｅｃ−Ａを受信できれば、Ｓｐｅｃ−Ａに含まれたフレーム−互換可能ビデオによって提供されるｓｅｒｖｉｃｅ_ｉｄが選択される。その後、ビデオ／オーディオＥＳデコーディング及びＰＩＤフィルターがＡ／Ｖストリームに関して行われる。最後に、ハーフ解像度の３Ｄビデオが出力される。

図５４は、Ｓｐｅｃ−ＡイベントとＳｐｅｃ−Ｂイベントとを連結させるイベント連結を拡張させるプロセスを詳細に例示する。従来のＳＤイベント及びＨＤイベントにおいて、ターゲットイベントサービスタイプに関する個別情報は提供されなかった。ｔａｒｇｅｔ_ｅｖｅｎｔ ｔｙｐｅを拡張させることによって、２Ｄ ＨＤ、ハーフ解像度の３Ｄ、フル解像度の３Ｄが区分可能である。そして、これに基づいて、ハーフ解像度の３Ｄイベントとフル解像度の３Ｄイベント間の連結が存在する。

図５５は、３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒの位置が、ＡＴＳＣ ＰＳＩＰ ＥＩＴに対するフル解像度の３Ｄ ＴＶサービスガイドを提供するためにｅｖｅｎｔ_ｉｎｆｏｒｍａｔｉｏｎ_ｔａｂｌｅ_ｓｅｃｔｉｏｎ（）内にあることを例示する。

ｄｅｓｃｒｉｐｔｏｒ（）は、フル解像度の３Ｄ ＴＶサービスがそれぞれのプログラム及びイベントに対して利用可能であるか否かを表示するために、ｆｏｒループ内にある。

図５６は、ＤＶＢ ＳＩ ＥＩＴのｅｖｅｎｔ_ｉｎｆｏｒｍａｔｉｏｎ_ｓｅｃｔｉｏｎ（）のｆｏｒループ内に、コンポーネントデスクリプタあるいは３Ｄ_ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒの位置を表示する。

上記で言及したように、ＡＴＳＣ伝送において、３Ｄ_Ｃｏｍｐｌｅｍｅｎｔａｒｙ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ_ＴＶＣＴがＥＩＴに含まれてフル解像度の３ＤＴＶにシグナリングし、ＤＶＢに対して、ＡＴＳＣに対する同一の方法に追加して、コンポーネントデスクリプタも使用される。

図５７は、ＡＴＳＣ ＰＳＩＰ ＥＩＴに対する３Ｄ相補型ビデオデスクリプタをパージング及びレンダリングするプロセスを例示し、図５８は、ＤＶＢ ＳＩ ＥＩＴに対するプロセスを例示する。

ＡＴＳＣ ＰＳＩＰ ＥＩＴにおいて、０ｘ１ＦＦＢのＰＩＤ値を有するＴＳパケットに対してフィルタリングが行われる。次いで、０ｘＣ７及び０ｘＣ８と同一のテーブルｉｄを有するセクションデータがパージングされる。次いで、ＭＧＴから、ＥＩＴを有するストリームのＰＩＤに関する情報が獲得される。次いで、獲得されたＥＩＴ ＰＩＤからＴＳパケットがフィルタリングされる。ＥＩＴ内のそれぞれのイベントの３Ｄ相補型ビデオデスクリプタを使用して、それぞれのＶＣイベントの３Ｄ相補型ビデオに関する情報が獲得される。

その後、放送ガイド情報に関するフル解像度３Ｄサービスの利用可能度が、３Ｄ放送イベントに関するフル解像度モードを見るために表示される。次いで、ＴＶＣＴ内のＳＬＤを使用する基本的なＡ／ＶストリームのＰＩＤの情報が獲得される。ＥＩＴから、３Ｄ相補型ビデオデスクリプタを通じて３Ｄ相補型ビデオの情報の獲得が行われる。次いで、基本的なＡ／ＶストリームのＰＩＤのフィルタリングが行われ、ビデオ／オーディオＥＳデコーディングが行われる。

最後に、フル解像度の３Ｄビデオの出力が、相補型ビデオデスクリプタ情報を用いて、出力フォーマッタ（ｏｕｔｐｕｔ ｆｏｒｍａｔｔｅｒ）からの変換及びフル解像度３Ｄビデオの再構成制御によって行われる。

図５８は、ＤＶＢ ＳＩ ＥＩＴに対する３Ｄ相補型ビデオデスクリプタをパージング及びレンダリングするプロセスを示す。

まず、ＴＳパケットがＰＩＤ値（０ｘ００１１）に対してフィルタリングされる。次いで、ｔａｂｌｅ_ｉｄ＝０ｘ４２を有するセクションデータがパージングされる。ＰＩＤ（０ｘ００１２）を有するＴＳパケットがフィルタリングされ、ｔａｂｌｅ_ｉｄ＝０ｘ４Ｅを有するセクションデータがパージングされる。ＡＴＳＣとＤＶＢとの差異は、ＤＶＢにおいて、３Ｄ相補型ビデオデスクリプタあるいはコンポーネントデスクリプタが３Ｄ相補型ビデオストリームの存在を決定するために使用され得るという点である。

最後に、図５９は、３Ｄビデオデコーダを備えた放送受信機のブロック図を例示する。

２つの層でのビデオストリームは、新しい世代の放送受信機を経ることになり、ベース層ビデオストリームは、１次ビデオデコーダでデコーディングされる。

エンハンスメント層ビデオストリームは、２次ビデオデコーダでデコーディングされる。さらに、ＰＳＩ／ＰＳＩＰ／ＳＩプロセッサは、新しい世代のＡＴＳＣスペック（ｓｐｅｃ）及びＤＶＢスペックから３Ｄ立体情報をパージングし、ここで、ＰＭＴ／ＴＶＣＴ／ＳＤＴは、３Ｄサービスを支援するために新たなシグナリングシンタックスを含む。そして、次世代受信機は、フル解像度３Ｄビデオフォーマットを、様々な種類の３ＤＴＶあるいは３Ｄディスプレイに応じて、特定の立体フォーマットに変換することができる。

図６０は、本発明の一実施例に係る、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）の概念図を例示する。

同図は、本発明の実施例に係る３Ｄサービスの概念図を示す。同図の実施例によれば、フル解像度の映像を提供する３ＤサービスＣ１００００は、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）及び／又は３Ｄサービス２Ｂと呼ぶことにする。ハーフ解像度の映像を提供する３Ｄサービス１．０ Ｃ１００１０は、以下で、Ｆｒａｍｅ Ｃｏｍｐａｔｉｂｌｅ ３Ｄサービス（ＦＣ−３Ｄサービス）、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）、及び／又は３Ｄサービス１Ａと呼ぶことにする。

３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０は、ハーフ解像度の左側映像及びハーフ解像度の右側映像としてサービスされてもよい。フル解像度の映像を提供する３Ｄサービス２．０（Ｓｐｅｃ−Ｂ） Ｃ１００２０は、フル解像度の映像を新たに伝送する代わりに、３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０と互換可能でなければならないので、３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０の映像伝送を維持し、そして、フル解像度の映像を伝送するための差動データ（ｄｉｆｆｅｒｅｎｔｉａｌ ｄａｔａ）あるいは追加データを提供する方法が用いられてもよい。より具体的に、３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０のハーフ解像度のビデオ要素に３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）の相補型ビデオ要素（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｖｉｄｅｏ ｅｌｅｍｅｎｔ） Ｃ１００２０を加えることによって、フル解像度の３ＤサービスＣ１００００が提供され得る。結局、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）を支援し得る放送受信機は、３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０のデータを受信及びプロセシングすることによって、ハーフ解像度の映像を提供することができ、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）を支援し得る放送受信機は、３Ｄサービス１．０（Ｓｐｅｃ−Ａ） Ｃ１００１０のデータ及び３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）の相補型データを受信及びプロセシングすることによって、フル解像度の映像を提供することができる。

図６１は、本発明の一実施例に係る、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングする方法を示す図である。

３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングするシグナリング情報は、システムレベル及び／又はビデオレベルで定義されてもよい。

システムレベルで定義される場合、シグナリング情報は、ＰＳＩ、ＡＴＳＣ−ＰＳＩＰ、及び／又はＤＶＢ−ＳＩなどに含まれてもよい。本発明の実施例によれば、ＰＳＩテーブルは、ＰＡＴ、及び／又はＰＭＴを含むことができる。また、ＤＶＢ ＳＩテーブルは、ＮＩＴ、ＳＤＴ、及び／又はＥＩＴを含むことができる。また、ＡＴＳＣ ＰＳＩＰテーブルは、ＶＣＴ、ＳＴＴ、ＲＲＴ、ＥＴＴ、ＤＣＣＴ、ＤＤＣＳＣＴ、ＥＩＴ、及び／又はＭＧＴを含むことができる。ＰＳＩテーブル、ＤＶＢ ＳＩテーブル、及び／又はＡＴＳＣ ＰＳＩＰテーブルに関する具体的な内容は、前述した内容と同一であるので、前述した内容で代替する。以下では、シグナリング情報がＰＳＩテーブル及び／又はＤＶＢ ＳＩテーブルで定義される場合を中心に説明する。

ビデオレベルで定義される場合、シグナリング情報は、ビデオＥＳのヘッダーに含まれてもよい。ビデオデータがＭＰＥＧ−２またはＭＰＥＧ−４ビデオコーディング技法を用いてエンコーディングされる場合、シグナリング情報は、ピクチャ拡張及びユーザデータのｕｓｅｒ_ｄａｔａ（）１３０１０内に含まれてもよい。ビデオデータがＨ．２６４／ＡＶＣまたはＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされる場合、シグナリング情報はＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージに含まれてもよい。シグナリング情報がビデオレベルで定義されることは、ＡＴＳＣ伝送過程だけでなく、ＤＶＢ伝送過程でも同一に適用され得る。以下では、シグナリング情報が、ビデオデータがＨ．２６４／ＡＶＣビデオコーディング技法を用いてエンコーディングされる場合を中心に説明する。

シグナリング情報は、サービスデスクリプタ、ベースレイヤのコンポーネントデスクリプタ、及び／又はエンハンスメントレイヤのコンポーネントデスクリプタを含むことができる。サービスデスクリプタ、ベースレイヤのコンポーネントデスクリプタ、及び／又はエンハンスメントレイヤのコンポーネントデスクリプタについての具体的な内容は後述する。

以下では、ＭＰＥＧ及び／又はＤＶＢ標準において３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングする方法を中心に説明する。

図面を参照すると、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）のシグナリングのためのシグナリング情報は、ＰＭＴ、ビデオＥＳ、サブタイトル、ＳＤＴ、及び／又はＥＩＴのうちの少なくとも１つに含まれるデスクリプタ及び／又はフィールドであってもよい。

ＰＭＴは、ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ及び／又はサブタイトリングデスクリプタを含むことができる。また、各ビデオＥＳはＳＥＩメッセージを含むことができ、サブタイトルはディスパリティー情報及び／又はＤｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）を含むことができる。また、ＳＤＴは、ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ及び／又はｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒを含むことができる。ＥＩＴは、ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ、ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ、ｃｏｎｔｅｎｔ ｄｅｓｃｒｉｐｔｏｒ、及び／又はｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒを含むことができる。シグナリング情報に関する具体的な内容は、以下で説明する。

３Ｄサービス１．０（Ｓｐｅｃ−Ａ）を支援できる受信機は、シグナリング情報に基づいてベース層のベースビデオデータ及び／又は３Ｄビデオ情報を受信及びプロセシングすることによって、ハーフ解像度の３Ｄ映像を提供することができる。また、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）を支援できる受信機は、シグナリング情報に基づいて、ベース層のベースビデオデータ及び／又は３Ｄビデオ情報だけでなく、エンハンスメント層の相補型ビデオデータ及び／又は３Ｄ相補型ビデオ情報を受信及びプロセシングすることによって、フル解像度の３Ｄ映像を提供することができる。

本発明の実施例に係るベースビデオデータ、３Ｄビデオ情報、相補型ビデオデータ、３Ｄ相補型ビデオ情報、及び／又は３ＤＴＶサービスを提供する具体的な方法は、前述した内容と同一であるので、前述した内容で代替する。

以下では、シグナリング情報について具体的に説明する。

まず、シグナリング情報はＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒを含むことができる。

ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、ＡＶＣビデオストリームのＳｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ＳＰＳ）に含まれたプロファイル（ｐｒｏｆｉｌｅ）及び／又はレベルパラメータ（ｌｅｖｅｌ ｐａｒａｍｅｔｅｒｓ）のような、関連するＡＶＣビデオストリームのコーディングパラメータを識別する基本情報を含むことができる。ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、３Ｄサービスを伝送するトランスポートストリーム（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）のＰＭＴにおいてそれぞれのエレメンタリーストリームエントリー（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ ｅｎｔｒｙ）に対してデスクリプタループ（Ｄｅｓｃｒｉｐｔｏｒ ｌｏｏｐ）に含まれてもよい。ＳＰＳは、プロファイル及び／又はレベルなどのシーケンス全体の符号化にわたっている情報が含まれているヘッダー情報である。

ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｐｒｏｆｉｌｅ_ｉｄｃ ｆｉｅｌｄ、ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ０_ｆｌａｇ ｆｉｅｌｄ、ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ１_ｆｌａｇ ｆｉｅｌｄ、ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ２_ｆｌａｇ ｆｉｅｌｄ、ＡＶＣ_ｃｏｍｐａｔｉｂｌｅ_ｆｌａｇｓ ｆｉｅｌｄ、ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄ、ＡＶＣ_ｓｔｉｌｌ_ｐｒｅｓｅｎｔ ｆｉｅｌｄ、ＡＶＣ_２４_ｈｏｕｒ_ｐｉｃｔｕｒｅ_ｆｌａｇ ｆｉｅｌｄ、及び／又はＲｅｓｅｒｖｅｄ ｆｉｅｌｄを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄは、ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒを識別する情報を含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄは、ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒの大きさを示す情報を含むことができる。

ｐｒｏｆｉｌｅ_ｉｄｃ ｆｉｅｌｄは、ビットストリームが基にしているプロファイルを示すことができる。例えば、プロファイルは、Ｂａｓｅｌｉｎｅ ｐｒｏｆｉｌｅ、Ｍａｉｎ ｐｒｏｆｉｌｅ、及び／又はＥｘｔｅｎｄｅｄ ｐｒｏｆｉｌｅを含むことができる。

ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ０_ｆｌａｇ ｆｉｅｌｄは、Ｂａｓｅｌｉｎｅ ｐｒｏｆｉｌｅにデコーディング可能であるか否かを示すことができる。

ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ１_ｆｌａｇ ｆｉｅｌｄは、Ｍａｉｎ ｐｒｏｆｉｌｅにデコーディング可能であるか否かを示すことができる。

ｃｏｎｓｔｒａｉｎｔ_ｓｅｔ２_ｆｌａｇ ｆｉｅｌｄは、Ｅｘｔｅｎｄｅｄ ｐｒｏｆｉｌｅにデコーディング可能であるか否かを示すことができる。

ＡＶＣ_ｃｏｍｐａｔｉｂｌｅ_ｆｌａｇｓ ｆｉｅｌｄは、‘０’の値を有する５ビットのデータであってもよい。デコーダは、この５ビットを無視し得る。

ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄは、ビットストリームのレベルを示すことができる。各プロファイルでは、映像の大きさに応じてレベルが定められる。レベルは、対応する映像の大きさに応じてパラメータの制限を規定する。ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄは、５つのレベル及びその中間レベルを含むことができる。

ＡＶＣ_ｓｔｉｌｌ_ｐｒｅｓｅｎｔ ｆｉｅｌｄは、ＡＶＣビデオストリームがＡＶＣ ｓｔｉｌｌ ｐｉｃｔｕｒｅｓを含んでいるか否かを示すことができる。ＡＶＣ ｓｔｉｌｌ ｐｉｃｔｕｒｅｓは、ＩＤＲ ｐｉｃｔｕｒｅを含むＡＶＣ Ａｃｃｅｓｓ Ｕｎｉｔを含むことができる。ＩＤＲ ｐｉｃｔｕｒｅは、ＩＤＲ ｐｉｃｔｒｕｅを正確にデコーディングするための十分な情報を伝送するＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）ＮＡＬ ｕｎｉｔ及び／又はＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）ＮＡＬ ｕｎｉｔなどに後続してもよい。

ＡＶＣ_２４_ｈｏｕｒ_ｐｉｃｔｕｒｅ_ｆｌａｇ ｆｉｅｌｄは、関連するＡＶＣビデオストリームがＡＶＣ ２４−ｈｏｕｒ ｐｉｃｔｕｒｅｓを含んでいるか否かを示すことができる。ＡＶＣ ２４−ｈｏｕｒ ｐｉｃｔｕｒｅは、２４時間以上の未来のプレゼンテーションタイムを含むＡＶＣ Ａｃｃｅｓｓ Ｕｎｉｔを意味する。

ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄをさらに含むことができる。

Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンス（または、ビデオＥＳ）にｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在するか否かを示すことができる。Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、ビデオシーケンスが３ＤＴＶビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを示すことができる。

例えば、３Ｄビデオフォーマットの伝送の間、Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在することをシグナルするために‘０’にセットされてもよい。また、ＨＤＴＶビデオフォーマットの伝送の間、Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在することをシグナルするために、‘０’にセットされてもよい。

また、ＨＤＴＶビデオフォーマットのみが使用されるか、または３Ｄビデオフォーマットにフォーマット切替（ｔｒａｎｓｉｔｉｏｎ）が発生する予定がないか、及び／又は３Ｄビデオフォーマットにフォーマット切替（ｔｒａｎｓｉｔｉｏｎ）が発生したことのない場合に、Ｆｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在しないことをシグナルするために、‘１’にセットされてもよい。

ベースレイヤストリームにおいて、受信機は、シグナリング情報に基づいてベースビデオデータをプロセシングすることができる。

エンハンスメントレイヤストリームにおいて、ＰＭＴのｓｔｒｅａｍ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”であれば、エンハンスメントレイヤのビデオストリームは、“ＭＶＣ ｖｉｄｅｏ ｓｕｂ−ｂｉｔｓｔｒｅａｍ ｏｆ ａｎ ＡＶＣ ｖｉｄｅｏ ｓｔｒｅａｍ”を示すことができる。受信機は、ＡＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒのＦｒａｍｅ_Ｐａｃｋｉｎｇ_ＳＥＩ_ｎｏｔ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄに基づいて、ビットストリームにｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在するか否かを識別することができる。

また、シグナリング情報は、サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）は、サービスの類型、サービス提供者、及び／又はサービスのネームを説明するデスクリプタである。サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）は、ＰＭＴ、ＳＤＴ、及び／又はＥＩＴに含まれてもよい。

サービスデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｐｒｏｖｉｄｅｒ_ｎａｍｅ_ｌｅｎｇｔｈ ｆｉｅｌｄ、サービス提供者のネームを示すｃｈａｒ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈ ｆｉｅｌｄ、及び／又はサービスのネームを示すｃｈａｒ ｆｉｅｌｄを含むことができる。サービスデスクリプタについての具体的な内容は、前述した内容で代替する。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄは、サービスのタイプを示すことができる。サービスのためのｓｅｒｖｉｃｅ_ｔｙｐｅの割当は、前述した内容で代替する。

追加的に、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ０Ｂ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ｍｏｓａｉｃ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ｍｏｓａｉｃ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１６”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＳＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＳＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１７”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＳＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＳＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１８”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＳＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＳＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１９”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ａ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｂ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。

また、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｃ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｄ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｅ”であれば、“ａｄｖａｎｃｅｄ ｃｏｄｅｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６４／ＡＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｃ”、“０ｘ１Ｄ”、及び／又は“０ｘ１Ｅ”のいずれか１つであれば、“Ｈ．２６４／ＡＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤ”サービスを示すことができる。受信機は、ベースビデオデータ及び／又はエンハンスメントビデオデータのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｃ”、“０ｘ１Ｄ”、及び／又は“０ｘ１Ｅ”のいずれか１つであれば、当該ビデオサービスは、“Ｈ．２６４／ＡＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤ”であると判断することができる。

また、シグナリング情報は、コンテンツデスクリプタ（ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

コンテンツデスクリプタは、イベントの分類情報を提供することができる。コンテンツデスクリプタは、ＥＩＴ及び／又はＳＩＴに含まれてもよい。コンテンツデスクリプタについての具体的な内容は後述する。

また、シグナリング情報は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを含むことができる。

３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）は、２Ｄイベントと３Ｄイベントとの間で動的な切り替えのためのシグナリングを提供することができる。エンコーディングされたビデオストリームは、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングするためにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ）Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ（ＳＥＩ）メッセージを含むことができる。３ＤＴＶビデオフォーマットとＨＤＴＶビデオフォーマット（例えば、ｎｏｎ−３ＤＴＶフォーマット）をスイッチングし得る３Ｄサービスは、３ＤＴＶビデオフォーマットのビデオストリームの伝送時間の間だけでなく、ＨＤＴＶビデオフォーマットのビデオストリームの伝送時間の間にもＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩメッセージを含むことができる。

Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩメッセージは、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングする情報を含むことができる。例えば、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩメッセージは、Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄ、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）ビデオストリームのフォーマットのような他の特性情報を含むことができる。

Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームが３Ｄビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを示すことができる。

例えば、Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘０’であれば、３Ｄビデオフォーマットが使用されることを示すことができ、当該デスクリプタの他のフィールドは、３Ｄビデオストリームのフォーマット及び／又は他の特性をシグナルすることができる。

Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘１’であれば、ＨＤＴＶビデオフォーマット（即ち、ｎｏｎ−３Ｄビデオフォーマット）が使用されると示すことができる。例えば、Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘１’であれば、ＨＤＴＶビデオフォーマットが使用されることを示すことができる。

受信機は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅに基づいてサンプルを再配列することができ、構成フレーム（左映像及び／又は右映像）のサンプルをディスプレイするのに適するように処理することができる。

Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、エンハンスメントレイヤストリームには存在せず、ベースレイヤストリームにのみ存在してもよい。

ただし、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、前述した３Ｄサービスデスクリプタに含まれたフィールド、及び／又は前述した３Ｄ相補型ビデオ情報に含まれたフィールドを含むことができる。３Ｄサービスデスクリプタは、ベースビデオデータに対するシグナリング情報を含むことができる。３Ｄ相補型ビデオ情報は、エンハンスメントビデオデータに対するシグナリング情報を含むことができる。３Ｄサービスデスクリプタ及び／又は３Ｄ相補型ビデオ情報は前述した内容と同一であるので、前述した内容で代替する。

以下では、サブタイトルと関連するシグナリング情報を説明する。

受信機は、サブタイトル及び／又はグラフィックなどのような付加的なコンテンツを、３Ｄイメージに遮られないようにディスプレイすることができる。サブタイトルは、ＳＤＴＶ及び／又はＨＤＴＶだけでなく、３Ｄサービスの重要な要素である。オンスクリーン（ｏｎ−ｓｃｒｅｅｎ）グラフィックと共に、サブタイトルが、３Ｄビデオコンテンツ上に、奥行きとタイミング条件下で、正確に位置することは非常に重要である。

第一に、シグナリング情報は、Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）を含むことができる。

ＤＳＳは、領域内でサブ領域の定義を含むことができる。Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）はサブタイトルに含まれてもよい。

第二に、シグナリング情報は、ＤＶＢサブタイトルに関する情報を含むことができる。コンポーネントデスクリプタにおいてｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が“０ｘ０３”である場合、シグナリング情報は、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に従ってＤＶＢサブタイトルに関する情報を含むことができる。

第三に、シグナリング情報は、サブタイトリングデスクリプタ（ｓｕｂｔｉｔｌｉｎｇ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

サブタイトリングデスクリプタは、ＤＶＢサブタイトルに関する情報を含むことができる。サブタイトリングデスクリプタはＰＭＴに含まれてもよい。

第四に、シグナリング情報は、ディスパリティー情報を含むことができる。ディスパリティー情報は、物体がスクリーンの前方からどれくらい近い所にあるのか、またはスクリーンの後方からどれくらい遠い所にあるのかを示す情報である。ディスパリティー情報はサブタイトルに含まれてもよい。

第五に、シグナリング情報は、ビデオデプスレンジデスクリプタ（Ｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。３Ｄビデオの上端にディスプレイされるグラフィック（例えば、テキスト及び／又はアイコン）の配置を最適化するために、ビデオデプスレンジデスクリプタは、３Ｄビデオの意図されたデプスレンジ（ｄｅｐｔｈ ｒａｎｇｅ）を示すことができる。

第六に、シグナリング情報は、マルチリージョンディスパリティー（Ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ）を含むことができる。マルチリージョンディスパリティーは、ビデオレベルでのディスパリティー情報を提供する。

Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）、ＤＶＢサブタイトルに関する情報、サブタイトリングデスクリプタ（ｓｕｂｔｉｔｌｉｎｇ ｄｅｓｃｒｉｐｔｏｒ）、ディスパリティー情報、ビデオデプスレンジデスクリプタ（Ｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒ）、及び／又はマルチリージョンディスパリティー（Ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ）に関する具体的な内容は後述する。

図６２は、本発明の一実施例に係る、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

また、シグナリング情報はコンポーネントデスクリプタ（ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

コンポーネントデスクリプタは、コンポーネントストリームのタイプを識別し、エレメンタリーストリームのテキストディスクリプション（ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）を提供するのに用いることができる。コンポーネントデスクリプタ（ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）はＳＤＴ及び／又はＥＩＴに含まれてもよい。すなわち、コンポーネントデスクリプタは、ＳＤＴのデスクリプタとして定義されることによって、当該サービスが３ＤＴＶサービスであるか否かを判断することができ、ＥＩＴのデスクリプタとして定義されることによって、当該イベントが３ＤＴＶであるか否かも判断することができる。

コンポーネントデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｒｅｓｅｒｖｅｄ_ｆｕｔｕｒｅ_ｕｓｅ ｆｉｅｌｄ、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ、ｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄ、ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅ ｆｉｅｌｄ、及び／又はｔｅｘｔ_ｃｈａｒ ｆｉｅｌｄを含むことができる。コンポーネントデスクリプタについての具体的な内容は、前述した内容で代替する。

コンポーネントストリームの類型は、少なくとも１つのパラメータを含むことができる。例えば、パラメータは、ビットストリーム情報、ビデオストリームのコーデック情報、プロファイル（ｐｒｏｆｉｌｅ）情報、レゾリューション情報、画面比率情報、フレームレート情報、映像フォーマット情報、及び／又はＢｉｔｄｅｐｔｈ情報を含むことができる。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０１’である場合にはＭＰＥＧ−２ビデオを示し、この場合、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ１１’である場合には２５Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示し、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ１２’である場合には３０Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’である場合にはＨ．２６４／ＡＶＣ ＳＤ（ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ）ビデオを示し、この場合、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ１１’である場合には２５Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示し、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ１２’である場合には３０Ｈｚのフレーム−コンパチブル３Ｄビデオであることを示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０３’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ１４’である場合には、３Ｄモニタ上にディスプレイのためのＤＶＢサブタイトルズ（ｎｏｒｍａｌ）を示し、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０３’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ２４’である場合には、３Ｄモニタ上にディスプレイのためのＤＶＢサブタイトルズ（ｆｏｒ ｔｈｅ ｈａｒｄ ｏｆ ｈｅａｒｉｎｇ）を示すことができる。

図面を参照すると、本発明の一実施例に係るコンポーネントデスクリプタは、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）に適用可能な新たなｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを含むことができる。

ベースレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８０’である場合、ベースビデオデータは、Ｈ．２６４／ＡＶＣ ｐｌａｎｏｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、及び／又はＳｉｄｅ−ｂｙ−Ｓｉｄｅを示すことができる。

ベースレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８１’である場合、ベースビデオデータは、Ｈ．２６４／ＡＶＣ ｐｌａｎｏｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍを示すことができる。

ベースレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８２’である場合、ベースビデオデータは、Ｈ．２６４／ＡＶＣ ｐｌａｎｏｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅを示すことができる。

ベースレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８３’である場合、ベースビデオデータは、Ｈ．２６４／ＡＶＣ ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍを示すことができる。

本発明の一実施例によれば、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’である場合、エンハンスメントレイヤのために新たなｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを含むことができる。この場合、３Ｄシステムの類型に関係なく、ベースレイヤに対応するエンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄは、それぞれ１つの同一の値を有することができる。ただし、実施例によって、それぞれ異なる値を有してもよい。

例えば、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合、エンハンスメントビデオデータは、Ｈ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏを示すことができる。ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値は固定された値ではなく、実施例によって変更可能である。例えば、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８４’である場合にもＨ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏを示すことができる。

具体的には、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合には、Ｈ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏ、２５Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅを示すことができる。また、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合には、Ｈ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏ、２５Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍを示すことができる。また、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合には、Ｈ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏ、３０Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅを示すことができる。また、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合には、Ｈ．２６４／ＭＶＣ ｄｅｐｅｎｄｅｎｔ ｖｉｅｗ、ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｖｉｄｅｏ、３０Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍを示すことができる。

受信機は、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄに基づいてビデオストリームの類型を識別することができる。例えば、ベースレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８０’である場合、ベースビデオデータのフォーマットがフレーム−コンパチブルビデオフォーマットであることを示すことができる。また、エンハンスメントレイヤのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄが‘０ｘ０５’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ８５’である場合、エンハンスメントビデオデータのフォーマットがフレーム−コンパチブルビデオフォーマットであることを示すことができる。このとき、ベースビデオデータ及び／又はエンハンスメントビデオデータのフォーマットは、サイド−バイ−サイド及び／又はトップ−ボトムのいずれか１つであってもよい。

ベースビデオデータ及び／又はエンハンスメントビデオデータのフォーマットがそれぞれフレーム−コンパチブルビデオフォーマットであれば、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）を示すことができる。

図６３は、本発明の一実施例に係る、リンケージデスクリプタのｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ及び／又はｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

また、シグナリング情報はリンケージデスクリプタ（ｌｉｎｋａｇｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

リンケージデスクリプタは、ＳＩシステム内の特定のｅｎｔｉｔｙに関連する付加情報が要求されるときに存在し得るサービスを示すことができる。リンケージデスクリプタは、付加情報を提供するサービスが要求される当該テーブル内に存在してもよい。Ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅのような場合、リンケージデスクリプタを用いて指定することができ、現在行われているサービスのｒｕｎｎｉｎｇ ｓｔａｔｕｓが‘ｎｏｎ ｒｕｎｎｉｎｇ’状態のとき、受信機で当該ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅを自動的に選択することができる。

例えば、リンケージデスクリプタは、ＳＤＴ及び／又はＥＩＴに含まれてもよく、受信機は、リンケージデスクリプタに基づいて、現在視聴している特定の２Ｄ ｓｅｒｖｉｃｅ_ｉｄまたは今後放送される特定の２Ｄ ｅｖｅｎｔ_ｉｄに対応する３Ｄサービスまたはイベントを把握することができる。

リンケージデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｉｄ ｆｉｅｌｄ、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ、ｍｏｂｉｌｅ_ｈａｎｄ−ｏｖｅｒ_ｉｎｆｏ（）ｆｉｅｌｄ、ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄ、ｅｘｔｅｎｄｅｄ_ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄ、及び／又はｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅ ｆｉｅｌｄを含むことができる。リンケージデスクリプタに関する具体的な内容は、前述した内容で代替する。

ｍｏｂｉｌｅ_ｈａｎｄ−ｏｖｅｒ_ｉｎｆｏ（）ｆｉｅｌｄは、モバイル受信機がハンドオーバ（ｈａｎｄ−ｏｖｅｒ）するサービスを識別することができる。このサービスは、ｓｅｒｖｉｃｅ_ｉｄでこれ以上実際のサービスを受信できないとき、受信機によって自動的に選択されてもよい。

ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄは、２つのイベントを同一にシグナリングするときに用いることができる。リンクされたイベントは、サイマルキャスト（ｓｉｍｕｌｃａｓｔ）またはタイムオフセット（ｔｉｍｅ ｏｆｆｓｅｔ）であってもよい。ターゲットイベントがさらに高い品質を有する場合には、ｅｖｅｎｔ_ｓｉｍｕｌｃａｓｔ ｆｉｌｅｄがセットされてもよい。

ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄは、ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄ ｆｉｅｌｄ、ｔａｒｇｅｔ_ｌｉｓｔｅｄ ｆｉｅｌｄ、ｅｖｅｎｔ_ｓｉｍｕｌｃａｓｔ ｆｉｅｌｄ、及び／又はｒｅｓｅｒｖｅｄ ｆｉｅｌｄを含むことができる。

ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄ ｆｉｅｌｄは、ソースイベントに対応するターゲットイベントを識別するイベント識別（ｅｖｅｎｔ_ｉｄ）情報を含むことができる。ソースイベントは、当該ｌｉｎｋａｇｅ_ｄｅｓｃｒｉｐｔｏｒが属するイベントであり、当該ｌｉｎｋａｇｅ_ｄｅｓｃｒｉｐｔｏｒの位置によって識別されるイベントである。ターゲットイベントは、当該ｌｉｎｋａｇｅ_ｄｅｓｃｒｉｐｔｏｒによって指定されたイベントであり、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ及び／又はｓｅｒｖｉｃｅ_ｉｄによって定義されるサービスで伝送されるイベントである。

ｔａｒｇｅｔ_ｌｉｓｔｅｄ ｆｉｅｌｄは、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄ及び／又はｓｅｒｖｉｃｅ_ｉｄ ｆｉｅｌｄによって定義されたサービスが、当該ＴＳで伝送されるＳＤＴに含まれるか否かを示すことができる。

ｅｖｅｎｔ_ｓｉｍｕｌｃａｓｔ ｆｉｅｌｄは、ターゲットイベント及びソースイベントがサイマルキャスト（ｓｉｍｕｌｃａｓｔ）されるか否かを示すことができる。

ｅｘｔｅｎｄｅｄ_ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄは、少なくとも１つのイベントを同一にシグナリングするときに用いることができる。リンクされたイベントは、サイマルキャスト（ｓｉｍｕｌｃａｓｔ）またはタイムオフセット（ｔｉｍｅ ｏｆｆｓｅｔ）であってもよい。

ｅｘｔｅｎｄｅｄ_ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（）ｆｉｅｌｄは、ｌｏｏｐ_ｌｅｎｇｔｈ及び／又は少なくとも１つのループ（ｌｏｏｐ）を含むことができる。それぞれのループは、リンクされたイベントを示すことができる。それぞれのループは、ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄ ｆｉｅｌｄ、ｔａｒｇｅｔ_ｌｉｓｔｅｄ ｆｉｅｌｄ、ｅｖｅｎｔ_ｓｉｍｕｌｃａｓｔ ｆｉｅｌｄ、ｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄ、ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ、ｕｓｅｒ_ｄｅｆｉｎｅｄ_ｉｄ ｆｉｅｌｄ、ｔａｒｇｅｔ_ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄ、ｔａｒｇｅｔ_ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄ、及び／又はｔａｒｇｅｔ_ｓｅｒｖｉｃｅ_ｉｄ ｆｉｅｌｄを含むことができる。

ｌｏｏｐ_ｌｅｎｇｔｈ ｆｉｅｌｄは、次のループ（ｌｏｏｐ）のバイト単位の大きさを示すことができる。

ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄは、ソースイベントに対応するターゲットイベントを識別するイベント識別（ｅｖｅｎｔ_ｉｄ）情報を含むことができる。

ｔａｒｇｅｔ_ｌｉｓｔｅｄ ｆｉｅｌｄは、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄ及び／又はｓｅｒｖｉｃｅ_ｉｄ ｆｉｅｌｄによって定義されたサービスが、当該ＴＳで伝送されるＳＤＴに含まれるか否かを示すことができる。

ｅｖｅｎｔ_ｓｉｍｕｌｃａｓｔ ｆｉｅｌｄは、ターゲットイベント及びソースイベントがサイマルキャスト（ｓｉｍｕｌｃａｓｔ）されるか否かを示すことができる。

ｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄは、ターゲットサービスのタイプを示すことができる。

図面を参照すると、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが“０ｘ０Ｅ”であり、ｌｉｎｋ_ｔｙｐｅが“０”であれば、リンケージタイプは“ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ”であり、ターゲットサービスのタイプはＳｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎ Ｖｉｄｅｏ（ＳＤ）を示すことができる。また、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが“０ｘ０Ｅ”であり、ｌｉｎｋ_ｔｙｐｅが“１”であれば、リンケージタイプは“ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ”であり、ターゲットサービスのタイプはＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｖｉｄｅｏ（ＨＤ）を示すことができる。また、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが“０ｘ０Ｅ”であり、ｌｉｎｋ_ｔｙｐｅが“２”であれば、リンケージタイプは“ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ”であり、ターゲットサービスのタイプはｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ Ｈ．２６４／ＡＶＣであることを示すことができる。また、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが“０ｘ０Ｅ”であり、ｌｉｎｋ_ｔｙｐｅが“３”であれば、リンケージタイプは“ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ”であり、ターゲットサービスのタイプはｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＭＶＣであることを示すことができる。

ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄは、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ及び／又はｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄと共に、ターゲットサービスを識別することができる。

ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄが“０”であれば、シングルターゲットサービスを識別するためにｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄが使用され得ることを示す。ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄが“１”であれば、シングルターゲットサービスを識別するために、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄの代わりにｔａｒｇｅｔ_ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄが使用され得ることを示す。ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄが“２”であれば、ターゲットサービスは少なくとも１つのトランスポートストリーム（ｗｉｌｄｃａｒｄｅｄ ＴＳｉｄ）に含まれることを示す。ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄが“３”であれば、ターゲットサービスはｕｓｅｒ ｄｅｆｉｎｅｄ ｉｄｅｎｔｉｆｉｅｒによってマッチングされてもよい。

ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄは、ターゲットサービスを決定するために、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄの代わりにｔａｒｇｅｔ_ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄが使用されるか否かを示すことができる。

ｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄは、ターゲットサービスを決定するために、ｓｅｒｖｉｃｅ_ｉｄの代わりにｔａｒｇｅｔ_ｓｅｒｖｉｃｅ_ｉｄが使用されるか否かを示すことができる。

ｕｓｅｒ_ｄｅｆｉｎｅｄ_ｉｄ ｆｉｅｌｄが使用される場合、リンケージデスクリプタはｐｒｉｖａｔｅ ｄａｔａ ｓｐｅｃｉｆｉｅｒ ｄｅｓｃｒｉｐｔｏｒの範囲に含まれてもよい。したがって、受信機は、ｕｓｅｒ_ｄｅｆｉｎｅｄ_ｉｄ ｆｉｅｌｄの意味を決定することができる。

ｔａｒｇｅｔ_ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄは、ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ、及び／又はｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄの統制下に指示される情報サービスを含む代案の（ａｌｔｅｒｎａｔｅ）ＴＳを識別することができる。

ｔａｒｇｅｔ_ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄは、ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ、及び／又はｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄの統制下に指示される情報サービスを含む代案の（ａｌｔｅｒｎａｔｅ）オリジネイティングデリバリーシステム（ｏｒｉｇｉｎａｔｉｎｇ ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ）のネットワーク識別（ｎｅｔｗｏｒｋ_ｉｄ）情報を含むことができる。

ｔａｒｇｅｔ_ｓｅｒｖｉｃｅ_ｉｄは、ｔａｒｇｅｔ_ｉｄ_ｔｙｐｅ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ_ｆｌａｇ ｆｉｅｌｄ、及び／又はｓｅｒｖｉｃｅ_ｉｄ_ｆｌａｇ ｆｉｅｌｄの統制下に指示される代案の（ａｌｔｅｒｎａｔｅ）情報サービスを識別することができる。

本発明の一実施例に係るリンケージデスクリプタを用いて３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングする方法を説明する。

第一に、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ０５’であれば、リンケージタイプは“ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅ”を示すことができる。また、ｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅ領域においてリプレースメントタイプを３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）として指定してもよい。

第二に、ＥＩＴでリンケージデスクリプタを伝送する場合、ｌｉｎｋａｇｅ_ｔｙｐｅが‘０ｘ０Ｄ’であれば、リンケージタイプは“ｅｖｅｎｔ ｌｉｎｋａｇｅ”を示すことができる。受信機は、ＥＩＴを介して、ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄに対する３Ｄサービスデスクリプタまたはコンポーネントデスクリプタを用いて、対応する３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングすることができる。

第三に、ＥＩＴでリンケージデスクリプタを伝送する場合、ｌｉｎｋａｇｅ_ｔｙｐｅが‘０ｘ０Ｅ’であれば、リンケージタイプは“ｅｘｔｅｎｄｅｄ ｅｖｅｎｔ ｌｉｎｋａｇｅ”を示すことができる。また、ｌｉｎｋ_ｔｙｐｅが‘２’であれば、ターゲットサービスのタイプはｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ Ｈ．２６４／ＡＶＣを示すことができる。ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ０Ｅ’であり、ｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄが‘２’であれば、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）を示すことができる。したがって、受信機は、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ及び／又はｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄに基づいて、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングすることができる。また、受信機は、ＥＩＴを介して、ｔａｒｇｅｔ_ｅｖｅｎｔ_ｉｄに対する３Ｄサービスデスクリプタまたはコンポーネントデスクリプタを用いて、対応する３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングすることができる。

第四に、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄに‘０ｘ０Ｆ’の新たな値を指定し、当該ディスクリプションは“３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）”として指定することができる。

第五に、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄが‘０ｘ０５’であれば、リンケージタイプは“ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅ”を示すことができる。受信機は、ターゲットサービスに対するｓｅｒｖｉｃｅ_ｔｙｐｅは、そのサービスに対するＳＤＴ、ＥＩＴなどを直接パージングして３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングすることができる。この方法に基づいて、受信機は、３Ｄに対応する２Ｄサービスを探してもよい。

図６４は、本発明の一実施例に係る受信機のブロック図を示す図である。

本発明の一実施例に係る受信機は、前述した３Ｄイメージディスプレイ装置及び／又は放送受信機の機能を含むことができる。

図面を参照すると、本発明の一実施例に係る受信機は、受信部Ｃ１０２１０、復調部Ｃ１０２２０、逆多重化部Ｃ１０２３０、シグナリング情報処理部Ｃ１０２４０、３ＤビデオデコーダＣ１０２５０、及び／又は出力フォーマッタＣ１０２６０を含む。

受信部Ｃ１０２１０は、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルを介して放送信号を受信する。

復調部Ｃ１０２２０は、受信した放送信号を復調する。

逆多重化部Ｃ１０２３０は、復調された放送信号から、オーディオデータ、ビデオデータ及び／又はシグナリング情報を逆多重化（ｄｅｍｕｌｔｉｐｌｅｘ）する。そのために、逆多重化部Ｃ１０２３０は、ＰＩＤ（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ）を用いてフィルタリング（ｆｉｌｔｅｒｉｎｇ）することによって、放送信号を逆多重化することができる。逆多重化部Ｃ１０２３０は、逆多重化されたビデオ信号を後段の３ＤビデオデコーダＣ１０２５０に出力し、シグナリング情報をシグナリング情報処理部Ｃ１０２４０に出力する。ここで、シグナリング情報は、前述したＰＳＩ、ＡＴＳＣ−ＰＳＩＰ、及び／又はＤＶＢ−ＳＩのようなシステム情報を含むことができる。

シグナリング情報処理部Ｃ１０２４０は、逆多重化部Ｃ１０２３０から伝達されたシグナリング情報を処理することができる。ここで、シグナリング情報処理部Ｃ１０２４０は、処理されるシグナリング情報を一時格納するデータベース（ＤＢ：Ｄａｔａｂａｓｅ）を内部または外部に備えてもよい。

シグナリング情報処理部Ｃ１０２４０は、前述した３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）をシグナリングするシグナリング情報を処理することができる。例えば、シグナリング情報は、３Ｄサービスであるか否かを識別する情報、ベースビデオデータに関する具体的な情報を提供する３Ｄサービス情報（３Ｄサービスデスクリプタ）、及び／又はエンハンスメントビデオデータに関する具体的な情報を提供する３Ｄ相補型ビデオ情報を含むことができる。３Ｄサービスであるか否かを識別する情報は、コンテンツが２Ｄであるか、または３Ｄであるかを識別する情報、コンテンツが３Ｄサービス１．０（Ｓｐｅｃ−Ａ）であるか、または３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）であるかを識別する情報を含むことができる。

ビデオデコーダＣ１０２５０は、逆多重化されたビデオデータを受信してデコーディングする。例えば、ビデオデコーダＣ１０２５０は、シグナリング情報に基づいてビデオデータをデコーディングすることができる。ビデオデコーダＣ１０２５０は、ベースビデオデータをデコーディングするベースビデオデコーダ（Ｃ１０２５２）、及び／又はエンハンスメントビデオデータをデコーディングするエンハンスメントビデオデコーダ（Ｃ１０２５４）を含むことができる。

出力フォーマッタＣ１０２６０は、３ＤビデオデコーダＣ１０２５０でデコーディングされた３Ｄビデオデータを、出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）して出力部（図示せず）に出力する。ここで、出力フォーマッタＣ１０２６０は、デコーディングされたビデオデータが３Ｄビデオデータである場合には、３Ｄ出力のための出力フォーマットに合わせてフォーマッティングすることができる。出力フォーマッタＣ１０２６０は、デコーディングされたビデオデータが２Ｄビデオデータである場合には、２Ｄ出力のための出力フォーマットに合わせてビデオデータを別途に加工せずに、そのまま出力することができる。

以下では、本発明の一実施例に係る受信機が放送信号を処理する方法を説明する。

逆多重化部Ｃ１０２３０は、受信される放送信号からＳＤＴ及び／又はＥＩＴセクションをフィルタリングしてパージングする。ここで、前述したように、逆多重化部は、ＰＩＤフィルタリングを介してＳＤＴ及び／又はＥＩＴセクションをフィルタリングすることができる。

シグナリング情報処理部Ｃ１０２４０は、パージングされたＳＤＴ及び／又はＥＩＴ内のサービスループにおいて、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）タイプを有するサービスに対する情報を獲得及び格納する。その後、シグナリング情報処理部は、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）に対するＰＭＴ情報を獲得及び格納する。

また、シグナリング情報処理部Ｃ１０２４０は、パージングされたＳＤＴ及び／又はＥＩＴ内のサービスループにおいて、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）タイプを有するサービスに対する情報を獲得及び格納する。すなわち、シグナリング情報処理部は、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）に対するＰＭＴ情報を獲得及び格納する。

シグナリング情報処理部Ｃ１０２４０は、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）に対するＰＭＴ情報及び／又は３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）に対するＰＭＴ情報を用いて、ベースビデオストリームに対するＰＩＤ情報及び／又はエンハンスメントビデオストリームに対するＰＩＤ情報を獲得することができる。

受信機の動作は、サービスの種類に応じて３つに分かれる。

まず、２Ｄサービスについて説明すると、次の通りである。

受信機は、２Ｄビデオ（ｂａｓｅ ｖｉｅｗ ｖｉｄｅｏ）を提供するｓｅｒｖｉｃｅ_ｉｄを選択する。ｓｅｒｖｉｃｅ_ｉｄを有するチャネルは、例えば、レガシーチャネルである。

３ＤビデオデコーダＣ１０２５０は、２Ｄデータに該当するビデオストリームに対するＰＩＤフィルタリング及びビデオＥＳデコーディングを行う。その後、受信機は、デコーディングされた２Ｄビデオを出力部を介して出力する。

次いで、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）について説明すると、次の通りである。

受信機は、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）を提供するｓｅｒｖｉｃｅ_ｉｄを選択する。このとき、前記ｓｅｒｖｉｃｅ_ｉｄのｓｅｒｖｉｃｅ_ｔｙｐｅは、例えば、ハーフ−レゾリューション３Ｄサービスであってもよい。

３ＤビデオデコーダＣ１０２５０は、ベースレイヤのベースビデオストリームに対するＰＩＤフィルタリング及びビデオＥＳをデコーディングする。

出力フォーマッタＣ１０２６０は、シグナリング情報及び／又は３Ｄサービスデスクリプタに基づいて、３Ｄビデオデータを出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）し、出力部（図示せず）に出力する。

受信機は、出力部を介してハーフ解像度の３Ｄビデオを画面上に出力する。

最後に、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）について説明すると、次の通りである。

受信機は、３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）を提供するｓｅｒｖｉｃｅ_ｉｄを選択する。このとき、前記ｓｅｒｖｉｃｅ_ｉｄのｓｅｒｖｉｃｅ_ｔｙｐｅは、例えば、フル−レゾリューション３Ｄサービスであってもよい。

３ＤビデオデコーダＣ１０２５０は、ベースレイヤのベースビデオストリームに対するＰＩＤフィルタリング及びビデオＥＳをデコーディングする。また、３ＤビデオデコーダＣ１０２５０は、エンハンスメントレイヤのエンハンスメントビデオストリームに対するＰＩＤフィルタリング及びビデオＥＳをデコーディングする。

出力フォーマッタＣ１０２６０は、シグナリング情報、３Ｄサービス情報、及び／又は３Ｄ相補型ビデオ情報に基づいて、３Ｄビデオデータを出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）し、出力部（図示せず）に出力する。

受信機は、出力部を介してフル解像度の３Ｄビデオを画面上に出力する。

一方、シグナリング情報処理部Ｃ１０２４０は、シグナリング情報からリンケージデスクリプタをパージングし、パージングされたリンケージデスクリプタの情報を用いて、２Ｄサービス、３Ｄサービス１．０（Ｓｐｅｃ−Ａ）、及び／又は３Ｄサービス２．０（Ｓｐｅｃ−Ｂ）間の連結情報を把握することができる。

図６５は、本発明の一実施例に係る、３Ｄサービス３．０の概念図を例示する。

同図は、本発明の一実施例に係る３Ｄサービス３．０ Ｃ２００００の概念図を示す。

本発明の一実施例に係る３Ｄサービス３．０ Ｃ２００００は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたビデオストリームの放送信号を伝送及び／又は受信するための機能を具現するためのものである。

３Ｄサービス３．０ Ｃ２００００は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたサービス（例えば、ビデオストリーム、ビデオデータなど）に対するサービス−フレーム−コンパチブル３Ｄサービス（Ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ Ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ３ＤＴＶ ｆｏｒ ＨＥＶＣ ｃｏｄｅｄ ｓｅｒｖｉｃｅｓ、ＳＦＣ ３ＤＴＶサービス）を示す。

ＳＦＣ−３Ｄサービスは、ビデオビットストリームにシグナリング情報を選択的に伝送するフレーム−コンパチブルサービス（ＦＣ−３Ｄサービス）である。シグナリング情報は、ＦＣ−３Ｄサービスのビデオストリームに含まれた２つの映像（例えば、左映像及び右映像）からいずれか１つの映像（例えば、左映像）を抽出するための制御情報を含むことができる。また、シグナリング情報は、ＨＤＴＶサービスの受信をシミュレート（ｓｉｍｕｌａｔｅ）するために抽出した映像をアップスケーリング（ｕｐ−ｓｃａｌｅ）する制御情報を含むことができる。ＨＤＴＶ受信機は、シグナリング情報に基づいて、ＦＣ−３Ｄサービスのビデオストリームに含まれた２つの映像（例えば、左映像及び右映像）からいずれか１つの映像（例えば、左映像）を抽出し、ＨＤＴＶサービスの受信をシミュレート（ｓｉｍｕｌａｔｅ）するために抽出した映像をアップスケーリング（ｕｐ−ｓｃａｌｅ）することができる。

ＳＦＣ−３Ｄサービスは、３Ｄサービスのビデオコンポーネントがフレームコンパチブルビデオフォーマットビットストリームである点でＨＤＴＶサービスと異なる。

ＳＦＣ−３Ｄサービスのビデオビットストリームは、ビデオレイヤのシグナリング情報を除いては、ＨＤＴＶサービスのビデオフォーマットの要求条件に従う。

３ＤＴＶサービス（または３Ｄサービス）は、３ＤＴＶイベントを伝送し得るＤＶＢサービスを示す。ＳＦＣ−３Ｄサービスは、“ＨＥＶＣデジタルテレビサービス”を示すｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄ（後述する）によってシグナリングされてもよい。ＳＦＣ−３Ｄイベント（またはＳＦＣ−３ＤＴＶイベント）は、ＳＦＣ−３Ｄフォーマットのビデオストリームを含むＤＶＢサービスイベントである。

シグナリング情報は、ＳＦＣ−３ＤサービスのためのＨＤビデオエンコーディングパラメータ（例えば、コーデック／プロファイル、レゾリューション、及び／又はフレームレートなど）を含むことができる。シグナリング情報は、３ＤＴＶモードとＨＤＴＶモードとの間でスイッチングする３Ｄサービス（または３ＤＴＶサービス）のために、ビデオフォーマットトランジション（ｖｉｄｅｏ ｆｏｒｍａｔ ｔｒａｎｓｉｔｉｏｎ）をシグナリングする情報を含むことができる。

既存のイベントリンケージサービス情報は、他のサービスタイプの増加した番号と共に、より多くの便利なイベントリンケージシグナリングシナリオを許容するために拡張され得る。

以下では、サービス−フレーム−コンパチブル３ＤＴＶサービスは、ＳＦＣ−３ＤＴＶサービス及び／又はＳＦＣ−３Ｄサービスで表すことができる。ＳＦＣ−３Ｄサービスは、サービス−コンパチブル３Ｄサービス及びフレーム−コンパチブル３Ｄサービスを含むことができる。

フレーム−コンパチブル３Ｄサービス（ＦＣ−３Ｄサービス）は、ビデオコンテンツを構成する左映像Ｃ２００１０及び右映像Ｃ２００２０を、空間的に多重化して配列して伝送するサービスである。したがって、フレーム−コンパチブル３Ｄサービスを支援する３Ｄ受信機は、受信した左映像Ｃ２００１０及び右映像Ｃ２００２０に基づいて３Ｄ映像をディスプレイすることができる。ただし、フレーム−コンパチブル３Ｄサービスを支援しない既存の２Ｄ受信機は、受信した左映像Ｃ２００１０及び右映像Ｃ２００２０をまるで一般的な２Ｄイメージ（ＨＤＴＶイメージ）のように１つの画面に全て出力するようになる。

サービス−コンパチブル３Ｄサービス（ＳＣ−３Ｄサービス）は、既存の２Ｄ受信機（例えば、ＨＤＴＶ）がフレーム−コンパチブル３Ｄサービスからビデオコンテンツの２Ｄバージョンを抽出できるように左映像Ｃ２００１０及び右映像Ｃ２００２０を配列して伝送するサービスである。

ＳＦＣ−３Ｄサービス及び既存のＨＤＴＶサービスは、１つのＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍにマルチプレクシングされて受信機に伝達されてもよい。ＳＦＣ−３Ｄサービスのための伝送システムは、ＤＶＢサービスを伝送するためにＤＶＢ ＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍを用いるいかなるブロードキャスト及び／又はデリバリーチャネルにも適用可能である。

本発明の一実施例に係るＳＦＣ−３Ｄサービスによれば、サービス提供者は、３Ｄ映像をディスプレイできるビデオストリームを、既存の２Ｄ受信機（例えば、ＨＤＴＶ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）にも提供することができる。既存の２Ｄ受信機は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたビデオストリームを受信し、受信したビデオストリームに含まれた左映像Ｃ２００１０及び右映像Ｃ２００２０のうちの１つを抽出することができる。その後、既存の２Ｄ受信機は、抽出された１つの映像（例えば、左映像Ｃ２００１０）をアップスケーリングし、２Ｄ映像（例えば、ＨＤＴＶ）をディスプレイすることができる。

また、３Ｄ受信機は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたビデオストリームを受信し、受信したビデオストリームを２Ｄ映像として出力するか、または３Ｄ映像として出力するかを決定することができる。もし、２Ｄ映像として出力する場合、前述したように、受信したビデオストリームに含まれた左映像Ｃ２００１０及び右映像Ｃ２００２０のうちの１つを抽出することができる。その後、３Ｄ受信機は、抽出された１つの映像をアップスケーリングし、２Ｄ映像（例えば、ＨＤＴＶ）をディスプレイすることができる。もし、３Ｄ映像として出力する場合、受信したビデオストリームに含まれた左映像Ｃ２００１０及び右映像Ｃ２００１０をフォーマッティングして３Ｄ映像をディスプレイすることができる。

また、３Ｄ受信機は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされた２Ｄビデオストリーム及び３Ｄビデオストリームを受信し、各ビデオストリームの関係情報（例えば、関係情報は、シグナリング情報に含まれてもよい）に基づいて、ビデオコンテンツに対する２Ｄ映像及び３Ｄ映像を選択的にスイッチングして出力することができる。

前述したようなＳＦＣ−３Ｄサービスの提供のために、本発明の一実施例に係るＳＦＣ−３Ｄサービスはシグナリング情報を提供することができる。以下では、ＳＦＣ−３Ｄサービスをシグナリングするためのシグナリング情報について具体的に説明する。

図６６は、本発明の一実施例に係る、ＳＦＣ−３ＤＴＶサービスをシグナリングする方法を示す図である。

図面を参照すると、ＤＶＢ伝送システムにおいてＳＦＣ−３Ｄサービスの伝送のための様々なシグナリング情報が示されている。

ＳＦＣ−３Ｄサービスをシグナリングするシグナリング情報は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたビデオストリームを伝送、受信、及び／又は処理するための全ての制御情報を示すことができる。シグナリング情報は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ）コーディング技法を用いてエンコーディングされたビデオストリームを伝送、受信、及び／又は処理するための全ての制御情報を示すことができる。

例えば、シグナリング情報は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅ、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、ＡＦＤ／ｂａｒ ｄａｔａ、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ、コンテンツデスクリプタ（ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ）、Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）、ＤＶＢサブタイトルに関する情報、サブタイトリングデスクリプタ（ｓｕｂｔｉｔｌｉｎｇ ｄｅｓｃｒｉｐｔｏｒ）、ディスパリティー情報、ビデオデプスレンジデスクリプタ（Ｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒ）、マルチリージョンディスパリティー（Ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ）、サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）、コンポーネントデスクリプタ、及び／又はリンケージデスクリプタのうちの少なくとも１つを含むことができる。

ＳＦＣ−３Ｄサービス（３Ｄサービス３．０）をシグナリングするシグナリング情報は、ビデオストリーム、伝送レイヤ、及び／又はサブタイトルのうちの少なくとも１つに含まれてもよい。

シグナリング情報がビデオストリームに含まれる場合、シグナリング情報はビデオＥＳに含まれてもよい。ビデオデータがＭＰＥＧ−２またはＭＰＥＧ−４ビデオコーディング技法を用いてエンコーディングされる場合、シグナリング情報は、ピクチャ拡張及びユーザデータのｕｓｅｒ_ｄａｔａ（）１３０１０内に含まれてもよい。ビデオデータがＨ．２６４／ＡＶＣまたはＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされる場合、シグナリング情報はＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージに含まれてもよい。以下では、ビデオデータがＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされる場合を中心に説明する。

シグナリング情報が伝送レイヤに含まれる場合、シグナリング情報は、ＰＳＩ、ＡＴＳＣ−ＰＳＩＰ、及び／又はＤＶＢ−ＳＩなどに含まれてもよい。ＰＳＩ、ＡＴＳＣ−ＰＳＩＰ、及び／又はＤＶＢ−ＳＩについての具体的な内容は、前述した内容と同一であるので、前述した内容で代替する。以下では、シグナリングデータがＰＳＩ及び／又はＤＶＢ−ＳＩに含まれる場合を中心に説明する。

シグナリング情報がサブタイトルに含まれる場合、シグナリング情報はディスパリティー情報を含むことができ、ＰＳＩ及び／又はＤＶＢ−ＳＩに含まれる他の情報と共にサブタイトルをシグナリングすることができる。

まず、シグナリング情報はＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを含むことができる。

ＳＦＣ−３Ｄサービスのコーディングされたビデオストリームは、ＦＣ−３ＤサービスのビデオコンポーネントのフォーマットをシグナリングするためにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを含むことができる。もし、ビデオがＳＦＣ−３Ｄサービスのフォーマットであれば、ＳＦＣ−３Ｄサービスのコーディングされたビデオストリームは、全てのビデオフレームに対してＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを含むことができる。

Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、フレームコンパチブル（Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ）なビデオフォーマットが使用されるか否かを識別するＦｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄを含むことができる。また、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、３Ｄビデオストリームのフォーマット及び／又は他の特性をシグナルする情報を含むことができる。

例えば、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、前述した３Ｄサービスデスクリプタに含まれたフィールドを含むことができる。３Ｄサービスデスクリプタは、ビデオデータに対するシグナリング情報を含むデスクリプタである。３Ｄサービスデスクリプタは、前述した内容と同一であるので、前述した内容で代替する。

Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームが３Ｄビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを示すことができる。

例えば、Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘０’であれば、フレームコンパチブル（Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ）なビデオフォーマットが使用されることを示すことができる。また、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅの他のフィールドは、３Ｄビデオストリームのフォーマット及び／又は他の特性をシグナルすることができる。

Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘１’であれば、ｎｏｎ−３Ｄビデオフォーマットが使用されることを示すことができる。例えば、Ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が‘１’であれば、ＨＤＴＶビデオフォーマットが使用されることを示すことができる。

３ＤＴＶ及びｎｏｎ−３ＤＴＶ（例えば、ＨＤＴＶ）をスイッチングできるＳＦＣ−３Ｄサービスは、ＨＤＴＶフォーマットのビデオストリームの伝送中にもＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを伝送することができる。

したがって、受信機は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩメッセージのＦｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄに基づいてＳＦＣ−３Ｄサービスをシグナリングすることができる。また、受信機は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅに基づいてサンプルを再配列することができ、構成フレーム（左映像及び／又は右映像）のサンプルをディスプレイするのに適するように処理することができる。

以下では、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅの具体的な内容を説明する。

一実施例として、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｉｄ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ、ｑｕｉｎｃｕｎｘ_ｓａｍｐｌｉｎｇ_ｆｌａｇ ｆｉｅｌｄ、ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄ、ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｆｌｉｐｐｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｉｅｌｄ_ｖｉｅｗｓ_ｆｌａｇ ｆｉｅｌｄ、ｃｕｒｒｅｎｔ_ｆｒａｍｅ_ｉｓ_ｆｒａｍｅ０_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ１_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄ、ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄ、ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄ、ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｓｅｒｖｅｄ_ｂｙｔｅ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｐｅｔｉｔｉｏｎ_ｐｅｒｉｏｄ ｆｉｅｌｄ、及び／又はｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｅｘｔｅｎｓｉｏｎ_ｆｌａｇ ｆｉｅｌｄを含むことができる。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｉｄ ｆｉｅｌｄは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを識別する情報を含むことができる。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが出力順序において以前のｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅの持続（ｐｅｒｓｉｓｔｅｎｃｅ）を取り消すか否かを示すことができる。例えば、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄの値が“０”であれば、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ情報は、以前のｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ情報に従うことができる。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ ｆｉｅｌｄは、パッキングアレンジメント（ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ）の類型を示すことができる。例えば、パッキングアレンジメント（ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ）の類型は、チェッカーボードフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝０）、コラム（ｃｏｌｕｍｎ）インターレースドフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝１）、ロー（ｒｏｗ）インターレースドフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝２）、サイド−バイ−サイドフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝３）、トップ−ボトムフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝４）、フレーム順次フォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝５）、２Ｄフォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝６）を含むことができる。

ｑｕｉｎｃｕｎｘ_ｓａｍｐｌｉｎｇ_ｆｌａｇ ｆｉｅｌｄは、それぞれの構成フレーム（左映像及び／又は右映像）のカラーコンポーネントプレーン（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ ｐｌａｎｅ）がクインカンクスサンプリングされたか（ｑｕｉｎｃｕｎｘ ｓａｍｐｌｅｄ）否かを示すことができる。

ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄは、構成フレーム（左映像及び／又は右映像）に対して意図された解釈を示すことができる。例えば、ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄの値が“０”であれば、構成フレーム間に何ら関連性がないことを示すことができる。ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄの値が“１”であれば、２つの構成フレームは、それぞれ、ステレオビュー場面の左映像と右映像を示すことができ、“フレーム０”は左映像を示し、“フレーム１”は右映像を示すことができる。ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄの値が“２”であれば、２つの構成フレームは、それぞれ、ステレオビュー場面の左映像と右映像を示すことができ、“フレーム０”は右映像を示し、“フレーム１”は左映像を示すことができる。

ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄは、左映像及び右映像のいずれかの映像が、本来意図した方向と比較して空間的にフリッピングされるか否かを示すことができる。例えば、サイド−バイ−サイドフォーマットの場合、ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄの値が“１”であれば、左映像及び右映像のいずれかの映像が水平的にフリッピングされることを示すことができる。トップ−ボトムフォーマットの場合、ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄの値が“１”であれば、左映像及び右映像のうちの一方の映像が垂直的にフリッピングされることを示すことができる。

ｆｒａｍｅ０_ｆｌｉｐｐｅｄ_ｆｌａｇ ｆｉｅｌｄは、ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄの値が“１”であれば、２つの構成フレーム（左映像及び右映像）のいずれがフリッピングされるかを示すことができる。

ｆｉｅｌｄ_ｖｉｅｗｓ_ｆｌａｇ ｆｉｅｌｄは、現在コーディングされたビデオシーケンス内にある全てのピクチャがコンプリメンタリフィールドペア（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｆｉｅｌｄ ｐａｉｒｓ）としてコーディングされるか否かを示すことができる。

ｃｕｒｒｅｎｔ_ｆｒａｍｅ_ｉｓ_ｆｒａｍｅ０_ｆｌａｇ ｆｉｅｌｄは、フレーム順次フォーマット（ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ＝５）の場合、現在デコーディングされるフレームが左映像であるか、または右映像であるかを示すことができる。例えば、ｃｕｒｒｅｎｔ_ｆｒａｍｅ_ｉｓ_ｆｒａｍｅ０_ｆｌａｇ ｆｉｅｌｄの値が“１”である場合、現在デコーディングされるフレームは左映像であり、次にデコーディングされるフレームは右映像であることを示すことができる。

ｆｒａｍｅ０_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスの第１構成フレーム（例えば、左映像）のサンプルに対するデコーディングプロセスにおいて第２構成フレーム（例えば、右映像）のサンプルを参照する、インタープレディクション動作（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ ｏｐｅｒａｔｉｏｎｓ）を行うか否かを示すことができる。

ｆｒａｍｅ１_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスの第２構成フレーム（例えば、右映像）のサンプルに対するデコーディングプロセスにおいて第１構成フレーム（例えば、右映像）のサンプルを参照する、インタープレディクション動作（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ ｏｐｅｒａｔｉｏｎｓ）を行うか否かを示すことができる。

ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄは、第１構成フレーム（例えば、左映像）に対する（ｘ，ｙ）座標対のｘコンポーネントを示す。

ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄは、第１構成フレーム（例えば、左映像）に対する（ｘ，ｙ）座標対のｙコンポーネントを示す。

ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄは、第２構成フレーム（例えば、右映像）に対する（ｘ，ｙ）座標対のｘコンポーネントを示す。

ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄは、第２構成フレーム（例えば、右映像）に対する（ｘ，ｙ）座標対のｙコンポーネントを示す。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｓｅｒｖｅｄ_ｂｙｔｅ ｆｉｅｌｄは、未来に使用可能な予約されたバイトであってもよい。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｐｅｔｉｔｉｏｎ_ｐｅｒｉｏｄ ｆｉｅｌｄは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅの持続（ｐｅｒｓｉｓｔｅｎｃｅ）を示すことができる。また、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｐｅｔｉｔｉｏｎ_ｐｅｒｉｏｄ ｆｉｅｌｄは、フレームオーダーカウントインターバル（ｆｒａｍｅ ｏｒｄｅｒ ｃｏｕｎｔ ｉｎｔｅｒｖａｌ）を示すことができる。ｆｒａｍｅ ｏｒｄｅｒ ｃｏｕｎｔ ｉｎｔｅｒｖａｌ内で同一のｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｉｄ値を有する異なるｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅまたはコーディングされたビデオシーケンスの最後の部分がビットストリームに現れてもよい。

ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｅｘｔｅｎｓｉｏｎ_ｆｌａｇ ｆｉｅｌｄは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅ内に追加的なデータがあるか否かを示すことができる。

また、シグナリング情報は、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報を含むことができる。

ＤＤＷ情報は、３Ｄ映像から２Ｄ映像を抽出するための情報を含むことができる。例えば、ＤＤＷ情報は、３Ｄ映像から左映像及び右映像のいずれか１つの映像を抽出するための情報を含むことができる。また、ＤＤＷは、３Ｄ映像において左映像または右映像に該当する座標範囲を含むことができる。ＤＤＷは、ＳＰＳのＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｏｎ（ＶＵＩ）の内部に含まれてもよい。

また、シグナリング情報はＡＦＤ／ｂａｒ ｄａｔａを含むことができる。

ＡＦＤ／ｂａｒ ｄａｔａは、エンコーディングされたビデオ領域全体において有効領域を抽出する情報を含むことができる。例えば、送信機で第１画面比率（例えば、２１：９）のビデオコンテンツを伝送し、受信機で第２画面比率（例えば、１６：９）のビデオコンテンツを処理できる場合、ＡＦＤ／ｂａｒ ｄａｔａは、第２画面比率を抽出するための情報を含むことができる。ＡＦＤ／ｂａｒ ｄａｔａはビデオＥＳに含まれてもよい。

また、シグナリング情報は、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒを含むことができる。

ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、ＨＥＶＣビデオストリームに関連するコーディングパラメータを識別する情報を含むことができる。

ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｐｒｏｆｉｌｅ_ｉｄｃ ｆｉｅｌｄ、ｒｅｓｅｒｖｅｄ_ｚｅｒｏ_８ｂｉｔｓ ｆｉｅｌｄ、ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄ、ｔｅｍｐｏｒａｌ_ｌａｙｅｒ_ｓｕｂｓｅｔ_ｆｌａｇ ｆｉｅｌｄ、ＨＥＶＣ_ｓｔｉｌｌ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄ、ＨＥＶＣ_２４ｈｒ_ｐｉｃｔｕｒｅ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄ 、ｔｅｍｐｏｒａｌ_ｉｄ_ｍｉｎ ｆｉｅｌｄ、及び／又はｔｅｍｐｏｒａｌ_ｉｄ_ｍａｘ ｆｉｅｌｄを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄは、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒを識別する情報を含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄは、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒの大きさを示す情報を含むことができる。

ｐｒｏｆｉｌｅ_ｉｄｃ ｆｉｅｌｄは、ビットストリームが基にしているプロファイルを示すことができる。例えば、プロファイルは、ＨＥＶＣスペックに定義されたＭａｉｎ ｐｒｏｆｉｌｅ、Ｍａｉｎ １０ ｐｒｏｆｉｌｅ、及び／又はＭａｉｎ Ｓｔｉｌｌ Ｐｉｃｔｕｒｅ ｐｒｏｆｉｌｅを含むことができる。

ｒｅｓｅｒｖｅｄ_ｚｅｒｏ_８ｂｉｔｓ ｆｉｅｌｄは、ＨＥＶＣスペックに従ってｓｅｑｕｅｎｃｅ_ｐａｒａｍｅｔｅｒ_ｓｅｔにあるｐｒｏｆｉｌｅ_ｉｄｃ ｆｉｅｌｄの直後の８ビットの情報を含むことができる。

ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄは、ＨＥＶＣスペックに定義されたビットストリームのレベルを示すことができる。各プロファイルでは、映像の大きさに応じてレベルが定められる。レベルは、対応する映像の大きさに応じてパラメータの制限を規定する。ｌｅｖｅｌ_ｉｄｃ ｆｉｅｌｄは、六つのレベルとその中間レベルを含むことができる。

ｔｅｍｐｏｒａｌ_ｌａｙｅｒ_ｓｕｂｓｅｔ_ｆｌａｇ ｆｉｅｌｄは、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒにｔｅｍｐｏｒａｌ ｌａｙｅｒのサブセット（ｓｕｂｓｅｔ）を記述するシンタックスエレメントが存在するか否かを示すことができる。

ＨＥＶＣ_ｓｔｉｌｌ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、ＨＥＶＣビデオストリームがＡＶＣ ｓｔｉｌｌ ｐｉｃｔｕｒｅｓを含んでいるか否かを示すことができる。ＡＶＣ ｓｔｉｌｌ ｐｉｃｔｕｒｅｓは、ＩＤＲ ｐｉｃｔｕｒｅを含むＡＶＣ Ａｃｃｅｓｓ Ｕｎｉｔを含むことができる。ＩＤＲ ｐｉｃｔｕｒｅは、ＩＤＲ ｐｉｃｔｒｕｅを正確にデコーディングするための十分な情報を伝送するＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ） ＮＡＬ ｕｎｉｔ及び／又はＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ） ＮＡＬ ｕｎｉｔなどに後続してもよい。

ＨＥＶＣ_２４ｈｒ_ｐｉｃｔｕｒｅ_ｐｒｅｓｅｎｔ_ｆｌａｇ ｆｉｅｌｄは、関連するＨＥＶＣビデオストリームがＨＥＶＣ ２４−ｈｏｕｒ ｐｉｃｔｕｒｅｓを含んでいるか否かを示すことができる。ＨＥＶＣ ２４−ｈｏｕｒ ｐｉｃｔｕｒｅは、２４時間以上の未来のプレゼンテーションタイムを含むＨＥＶＣ Ａｃｃｅｓｓ Ｕｎｉｔを意味する。

ｔｅｍｐｏｒａｌ_ｉｄ_ｍｉｎ ｆｉｅｌｄは、関連するビデオＥＳに対するＮＡＬ ｕｎｉｔヘッダーにあるｔｅｍｐｏｒａｌ_ｉｄ ｆｉｅｌｄの最小値を示す。

ｔｅｍｐｏｒａｌ_ｉｄ_ｍａｘ ｆｉｅｌｄは、関連するビデオＥＳに対するＮＡＬ ｕｎｉｔヘッダーにあるｔｅｍｐｏｒａｌ_ｉｄ ｆｉｅｌｄの最大値を示す。

ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒは、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄをさらに含むことができる。

ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在するか否かをシグナルすることができる。ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームが３ＤＴＶビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを示すことができる。

例えば、３Ｄビデオフォーマットの伝送の間、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在することをシグナルするために‘０’にセットされてもよい。また、ＨＤＴＶビデオフォーマットの伝送の間、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在することをシグナルするために‘０’にセットされてもよい。

また、ＨＤＴＶビデオフォーマットのみが使用されるか、または３Ｄビデオフォーマットにフォーマット切替（ｔｒａｎｓｉｔｉｏｎ）が発生する予定がないか、及び／又は３Ｄビデオフォーマットにフォーマット切替（ｔｒａｎｓｉｔｉｏｎ）が発生したことのない場合に、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、コーディングされたビデオシーケンスにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在しないことをシグナルするために‘１’にセットされてもよい。

受信機は、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄに基づいて、ビットストリーム内にｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在するか否かを識別することができる。

また、シグナリング情報はコンテンツデスクリプタ（ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

コンテンツデスクリプタは、イベントの分類情報を提供することができる。コンテンツデスクリプタはＥＩＴ及び／又はＳＩＴに含まれてもよい。

コンテンツデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、及び／又は少なくとも１つのｆｏｒループ（ｌｏｏｐ）を含むことができる。それぞれのｆｏｒループは、イベントの分類情報を含むことができる。それぞれのｆｏｒループは、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄ、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄ、及び／又はｕｓｅｒ_ｂｙｔｅ ｆｉｅｌｄを含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄは、コンテンツデスクリプタを識別する情報を含むことができる。

ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄは、次のｆｏｒループ（ｌｏｏｐ）のバイト単位の大きさを示すことができる。

ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄは、４ビットであってもよく、第１レベルのコンテンツ識別子を示す。

ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄは、４ビットであってもよく、第２レベルのコンテンツ識別子を示す。第２レベルは、第１レベルの細部分野であってもよい。

ｕｓｅｒ_ｂｙｔｅ ｆｉｅｌｄは、８ビットであってもよく、送信機によって定義されてもよい。

ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄは、“０ｘ０”乃至“０ｘＦ”の値を有することができる。ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ０”であれば、第１レベルのコンテンツ分類情報は“ｕｎｄｅｆｉｎｅｄ ｃｏｎｔｅｎｔ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ１”であれば、第１レベルのコンテンツ分類情報は“Ｍｏｖｉｅ／Ｄｒａｍａ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ２”であれば、第１レベルのコンテンツ分類情報は“Ｎｅｗｓ／Ｃｕｒｒｅｎｔ ａｆｆａｉｒｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ３”であれば、第１レベルのコンテンツ分類情報は“Ｓｈｏｗ／Ｇａｍｅ ｓｈｏｗ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ４”であれば、第１レベルのコンテンツ分類情報は“Ｓｐｏｒｔｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ５”であれば、第１レベルのコンテンツ分類情報は“Ｃｈｉｌｄｒｅｎ’ｓ／Ｙｏｕｔｈ ｐｒｏｇｒａｍｍｅｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ６”であれば、第１レベルのコンテンツ分類情報は“Ｍｕｓｉｃ／Ｂａｌｌｅｔ／Ｄａｎｃｅ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ７”であれば、第１レベルのコンテンツ分類情報は“Ａｒｔｓ／Ｃｕｌｔｕｒｅ（ｗｉｔｈｏｕｔ ｍｕｓｉｃ）”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ８”であれば、第１レベルのコンテンツ分類情報は“Ｓｏｃｉａｌ／Ｐｏｌｉｔｉｃａｌ ｉｓｓｕｅｓ／Ｅｃｏｎｏｍｉｃｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘ９”であれば、第１レベルのコンテンツ分類情報は“Ｅｄｕｃａｔｉｏｎ／Ｓｃｉｅｎｃｅ／Ｆａｃｔｕａｌ ｔｏｐｉｃｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘＡ”であれば、第１レベルのコンテンツ分類情報は“Ｌｅｉｓｕｒｅ ｈｏｂｂｉｅｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘＢ”であれば、第１レベルのコンテンツ分類情報は“Ｓｐｅｃｉａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘＣ”乃至“０ｘＥ”であれば、第１レベルのコンテンツ分類情報は“Ｒｅｓｅｒｖｅｄ ｆｏｒ ｆｕｔｕｒｅ ｕｓｅ”を示すことができる。また、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘＦ”であれば、第１レベルのコンテンツ分類情報は“Ｕｓｅｒ ｄｅｆｉｎｅｄ”を示すことができる。

ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄは、“０ｘ０”〜“０ｘＦ”の値を有することができる。ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄは、それぞれのｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄに対して特定の値を有することができ、第１レベルのコンテンツ分類情報に対してより細分化された分類情報を示すことができる。

例えば、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄが“０ｘＢ”であれば、第１レベルのコンテンツ分類情報は“Ｓｐｅｃｉａｌ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ”であり、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄが“０ｘ４”であれば、第２レベルのコンテンツ分類情報は“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ３ＤＴＶ ｆｏｒｍａｔ”を示すことができる。

したがって、コンポーネントデスクリプタの受信機は、ｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_１ ｆｉｅｌｄ及び／又はｃｏｎｔｅｎｔ_ｎｉｂｂｌｅ_ｌｅｖｅｌ_２ ｆｉｅｌｄに基づいてビデオストリームの分類情報を識別することができる。また、受信機は、コンポーネントデスクリプタに基づいて、ＥＰＧにおいて３Ｄサービスを支援するイベントをハイライトすることができる。

以下では、サブタイトルと関連するシグナリング情報を説明する。

受信機は、サブタイトル及び／又はグラフィックのような付加的なコンテンツを、３Ｄイメージに遮られないようにディスプレイすることができる。サブタイトルは、ＳＤＴＶ及び／又はＨＤＴＶだけでなく、３Ｄサービスの重要な要素である。オンスクリーン（ｏｎ−ｓｃｒｅｅｎ）グラフィックと共に、サブタイトルが、３Ｄビデオコンテンツ上に、奥行きとタイミング条件下で、正確に位置することは非常に重要である。

第一に、シグナリング情報は、Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）を含むことができる。

ＤＳＳは、領域内でサブ領域の定義を含むことができる。Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）はサブタイトルに含まれてもよい。

ページ及び／又は領域内の変化する奥行きにおいてサブタイトルの配置を可能にする異なるディスパリティー値が、それぞれのサブ領域に対して伝送されてもよい。ディスパリティー情報は、サブ−ピクセルアキュラシ（ｓｕｂ−ｐｉｘｅｌ ａｃｃｕｒａｃｙ）情報と共に伝送されてもよい。サブ−ピクセルアキュラシ情報は、３Ｄ場面内でサブタイトルを最適に配置できる情報を含むことができる。

ＤＳＳは、領域またはサブ領域に対するディスパリティー値に基づいて、３Ｄコンテンツのサブタイトリングを支援することができる。

第二に、シグナリング情報は、ＤＶＢサブタイトルに関する情報を含むことができる。

コンポーネントデスクリプタにおいてｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が“０ｘ０３”である場合、シグナリング情報は、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に応じてＤＶＢサブタイトルに関する情報を含むことができる。

例えば、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が“０ｘ０３”であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１４”であれば、“ＤＶＢ ｓｕｂｔｉｔｌｅｓ （ｎｏｒｍａｌ） ｆｏｒ ｄｉｓｐｌａｙ ｏｎ ａ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｍｏｎｉｔｏｒ”を示してもよい。また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が“０ｘ０３”であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１５”であれば、“ＤＶＢ ｓｕｂｔｉｔｌｅｓ （ｎｏｒｍａｌ） ｗｉｔｈ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｄｉｓｐａｒｉｔｙ ｆｏｒ ｄｉｓｐｌａｙ ｏｎ ａ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｍｏｎｉｔｏｒ”を示してもよい。

第三に、シグナリング情報は、サブタイトリングデスクリプタ（ｓｕｂｔｉｔｌｉｎｇ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

サブタイトリングデスクリプタは、ＤＶＢサブタイトルに関する情報を含むことができる。サブタイトリングデスクリプタはＰＭＴに含まれてもよい。サブタイトリングデスクリプタは、ＰＭＴテーブルにおいてＤＶＢサブタイトルを伝送するパケットのｓｔｒｅａｍ_ｔｙｐｅ＝０ｘ０６として指定される。

サブタイトリングデスクリプタは、ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅ ｆｉｅｌｄ、ｓｕｂｔｉｔｌｉｎｇ_ｔｙｐｅ ｆｉｅｌｄ、ｃｏｍｐｏｓｉｔｉｏｎ_ｐａｇｅ_ｉｄ ｆｉｅｌｄ、及び／又はａｎｃｉｌｌａｒｙ_ｐａｇｅ_ｉｄ ｆｉｅｌｄを含むことができる。

ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅ ｆｉｅｌｄは、３字のテキストで表現される言語コードを示すことができる。

ｓｕｂｔｉｔｌｉｎｇ_ｔｙｐｅ ｆｉｅｌｄは、サブタイトルのコンテンツ、及び適用するディスプレイに関する情報を含むことができる。ｓｕｂｔｉｔｌｉｎｇ_ｔｙｐｅ ｆｉｅｌｄは、ｃｏｍｐｏｎｅｎｔ_ｄｅｓｃｒｉｐｔｏｒにおいてｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が“０ｘ０３”である場合のｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ別に定義されたコードを示すことができる。

ｃｏｍｐｏｓｉｔｉｏｎ_ｐａｇｅ_ｉｄ ｆｉｅｌｄは、ｃｏｍｐｏｓｉｔｉｏｎ ｐａｇｅを識別する情報を含むことができる。

ａｎｃｉｌｌａｒｙ_ｐａｇｅ_ｉｄ ｆｉｅｌｄは、ａｎｃｉｌｌａｒｙ ｐａｇｅを識別する情報を含むことができる。

第四に、シグナリング情報はディスパリティー情報を含むことができる。

サブタイトルはディスパリティー情報を含むことができる。ディスパリティー情報は、物体がスクリーンの前方からどれくらい近い所にあるのか、またはスクリーンの後方からどれくらい遠い所にあるのかを示す情報である。。ディスパリティー情報は、ビデオデプスレンジデスクリプタ及び／又はマルチリージョンデスクリプタに含まれてもよい。

第五に、シグナリング情報は、ビデオデプスレンジデスクリプタ（Ｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

３Ｄビデオの上端にディスプレイされるグラフィック（例えば、テキスト及び／又はアイコン）の配置を最適化するために、ビデオデプスレンジデスクリプタは、３Ｄビデオの意図されたデプスレンジ（ｄｅｐｔｈ ｒａｎｇｅ）を示すことができる。ビデオデプスレンジデスクリプタは、サービス及び／又はイベントレベルでのディスパリティー情報を提供する。ディスパリティー情報は、当該サービス及び／又は当該イベントの期間の間、静的な（ｓｔａｔｉｃ）値を有することができる。

ビデオデプスレンジデスクリプタは、ｒａｎｇｅ_ｔｙｐｅ ｆｉｅｌｄ、ｒａｎｇｅ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｐｒｏｄｕｃｔｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｈｉｎｔ_ｉｎｆｏ（） ｆｉｅｌｄ、及び／又はｒａｎｇｅ_ｓｅｌｅｃｔｏｒ_ｂｙｔｅ ｆｉｅｌｄを含むことができる。

ｒａｎｇｅ_ｔｙｐｅ ｆｉｅｌｄは、デプスレンジ（ｄｅｐｔｈ ｒａｎｇｅ）の類型を示す。ｒａｎｇｅ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ００’であれば、デプスレンジの類型は“ｐｒｏｄｕｃｔｉｏｎ ｄｉｓｐａｒｉｔｙ ｈｉｎｔ”であり、ｒａｎｇｅ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０１’であれば、デプスレンジの類型は“ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ ＳＥＩ ｐｒｅｓｅｎｔ”を示すことができる。もし、ｒａｎｇｅ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０１’であれば、ビデオＥＳにｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ ＳＥＩデータが存在することを示すことができる。この場合、ｒａｎｇｅ_ｌｅｎｇｔｈ ｆｉｅｌｄの値は‘０’であってもよい。

第六に、シグナリング情報は、マルチリージョンディスパリティー（Ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ）を含むことができる。

マルチリージョンディスパリティーは、ビデオレベルでのディスパリティー情報を提供する。マルチリージョンディスパリティーは、３Ｄビデオの全てのフレーム及び／又は各フレームの異なる空間領域に対する動的な（ｄｙｎａｍｉｃ）値を有することができる。

受信機は、マルチリージョンディスパリティーに基づいて付加的な情報（グラフィック、メニューなど）をオーバーレイ（ｏｖｅｒｌａｙ）するために、ディスパリティー値の形態の奥行き情報を伝送することができる。その結果、受信機は、３Ｄ ｖｉｄｅｏ（ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｖｉｄｅｏ）とグラフィックとの間にデプスバイオレーション（ｄｅｐｔｈ ｖｉｏｌａｔｉｏｎ）を避けることができる。

それぞれのフレームにおいて、１つの最大ディスパリティー値が伝送されてもよい。領域（ｒｅｇｉｏｎ）は、予め定義されたイメージパーティショニングパターン（ｉｍａｇｅ ｐａｒｔｉｔｉｏｎｉｎｇ ｐａｔｔｅｒｎ）の集合によって定義されてもよい。それぞれのフレームのそれぞれの領域に対して、正確に１つの最小ディスパリティー値が伝送されてもよい。

マルチリージョンディスパリティーは、ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｍａｘ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｐｉｃｔｕｒｅ ｆｉｅｌｄ、及び／又はｍｉｎ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎ_ｉ ｆｉｅｌｄを含むことができる。

ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄは、８ビットであってもよく、ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ（）においてｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値として定義されるバイトの直後のバイトの数を規定することができる。

また、ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄは、領域パターンの類型をシグナルすることができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄは、予め定義されたイメージパーティショニングパターン（ｉｍａｇｅ ｐａｒｔｉｔｉｏｎｉｎｇ ｐａｔｔｅｒｎ）に該当する値の制限された集合を含むことができる。それぞれのイメージパーティショニングパターンは、イメージのいくつかの領域を定義することができる。

例えば、ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘０’であれば、“ｎｏ ｄｉｓｐａｒｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ ｉｓ ｔｏ ｂｅ ｄｅｌｉｖｅｒｅｄ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘２’であれば、“ｏｎｅ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎ ｉｓ ｃｏｄｅｄ ａｓ ｒｅｐｒｅｓｅｎｔｉｎｇ ｔｈｅ ｍｉｎｉｍｕｍ ｖａｌｕｅ ｉｎ ｏｖｅｒａｌｌ ｐｉｃｔｕｒｅ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘３’であれば、“ｔｗｏ ｖｅｒｔｉｃａｌ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎｓ ａｒｅ ｃｏｄｅｄ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘４’であれば、“ｔｈｒｅｅ ｖｅｒｔｉｃａｌ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎｓ ａｒｅ ｃｏｄｅｄ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘５’であれば、“ｆｏｕｒ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎｓ ａｒｅ ｃｏｄｅｄ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘１０’であれば、“ｎｉｎｅ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎｓ ａｒｅ ｃｏｄｅｄ”を示すことができる。ｍｕｌｔｉ_ｒｅｇｉｏｎ_ｄｉｓｐａｒｉｔｙ_ｌｅｎｇｔｈ ｆｉｅｌｄの値が‘１７’であれば、“ｓｉｘｔｅｅｎ ｍｉｎｉｍｕｍ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎｓ ａｒｅ ｃｏｄｅｄ”を示すことができる。

ｍａｘ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｐｉｃｔｕｒｅ ｆｉｅｌｄは、ピクチャ内で最大ディスパリティー値を規定することができる。

ｍｉｎ_ｄｉｓｐａｒｉｔｙ_ｉｎ_ｒｅｇｉｏｎ_ｉ ｆｉｅｌｄは、第ｉ番目の領域において最小ディスパリティー値を規定することができる。

図６７は、本発明の一実施例に係る、ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報は、サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。

サービスデスクリプタは、サービスの類型、サービス提供者、及び／又はサービスのネームを説明するデスクリプタである。サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）は、ＳＤＴ及び／又はＳＩＴ（Ｓｅｌｅｃｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）に含まれてもよい。

サービスデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｐｒｏｖｉｄｅｒ_ｎａｍｅ_ｌｅｎｇｔｈ ｆｉｅｌｄ、サービス提供者のネームを示すｃｈａｒ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｎａｍｅ_ｌｅｎｇｔｈ ｆｉｅｌｄ、及び／又はサービスのネームを示すｃｈａｒ ｆｉｅｌｄを含むことができる。サービスデスクリプタについての具体的な内容は、前述した内容で代替する。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄは、サービスのタイプを説明することができる。サービスのためのｓｅｒｖｉｃｅ_ｔｙｐｅの割当は、前述した内容で代替する。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”であれば、サービスタイプ（または、サービスタイプ情報）は、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２１”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄは、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”、“０ｘ２０”、及び／又は“０ｘ２１”のいずれか１つであれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”を示すことができる。

ここで、サービスデスクリプタは、既存の２Ｄサービス（２Ｄ ＨＥＶＣ）で使用されるｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値（ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”）を含むことができる。

既存の２Ｄ受信機は、既存の２Ｄサービスで使用されるｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像をディスプレイすることができる。

本発明の一実施例に係るＳＦＣ−３Ｄサービスを支援する受信機は、新たに定義されたｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像及び／又は３Ｄ映像をディスプレイすることができる。

受信機は、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄに基づいて、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、受信機は、ビデオストリームのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”であれば、サービスタイプは“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”であると判断することができる。

また、受信機は、ビデオストリームのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”及び／又は“０ｘ２１”のいずれか１つであれば、当該ビデオサービスは、ＨＥＶＣビデオサービスであると判断することができる。例えば、受信機は、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”及び／又は“０ｘ２１”のいずれか１つであれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”であると判断することができる。

図６８は、本発明の一実施例に係る、ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報は、サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）を含むことができる。サービスデスクリプタについての具体的な内容は、前述した内容と同一であるので、前述した内容で代替する。

図面を参照すると、サービスタイプは、ｂｉｔｄｅｐｔｈの値によってより細分化することができる。Ｂｉｔｄｅｐｔｈは、カラー（または灰色の影）を再現できるカラー（またはグレースケールイメージの場合、明るさの程度）数の単位を示すことができる。例えば、Ｂｉｔｄｅｐｔｈは、８−ｂｉｔ Ｂｉｔｄｅｐｔｈ及び／又は１０−ｂｉｔ Ｂｉｔｄｅｐｔｈを含むことができる。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ８ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ８ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２１”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ８ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。

また、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２２”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ １０ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２３”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又はＨ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ １０ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ＮＶＯＤ ｔｉｍｅ−ｓｈｉｆｔｅｄ ｓｅｒｖｉｃｅ”を示すことができる。ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２４”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ １０ ｂｉｔ ｂｉｔｄｅｐｔｈ ＨＤ ＮＶＯＤ ｒｅｆｅｒｅｎｃｅ ｓｅｒｖｉｃｅ”を示すことができる。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄは、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”、“０ｘ２０”、“０ｘ２１”、“０ｘ２２”、“０ｘ２３”、及び／又は“０ｘ２４”のいずれか１つであれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”を示すことができる。

受信機は、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄに基づいて、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、受信機は、ビデオストリームのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”であれば、サービスタイプは“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”であると判断することができる。

また、受信機は、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄに基づいて、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、受信機は、ビデオストリームのｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ２０”、“０ｘ２１”、“０ｘ２２”、“０ｘ２３”、及び／又は“０ｘ２４”のいずれか１つであれば、当該ビデオサービスは“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”であると判断することができる。

図６９は、本発明の一実施例に係る、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報は、コンポーネントデスクリプタを含むことができる。

コンポーネントデスクリプタは、コンポーネントストリームのタイプを識別し、エレメンタリーストリームのテキストディスクリプション（ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）を提供するのに使用することができる。コンポーネントデスクリプタ（ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）はＳＤＴ及び／又はＥＩＴに含まれてもよい。

コンポーネントデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｒｅｓｅｒｖｅｄ_ｆｕｔｕｒｅ_ｕｓｅ ｆｉｅｌｄ、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ（または、第１ストリームコンテンツ情報）、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ（または、コンポーネントタイプ情報）、ｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄ、ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅ ｆｉｅｌｄ、及び／又はｔｅｘｔ_ｃｈａｒ ｆｉｅｌｄを含むことができる。コンポーネントデスクリプタについての具体的な内容は、前述した内容で代替する。

コンポーネントデスクリプタは、既存の２Ｄサービス（２Ｄ ＨＥＶＣ）で使用されるｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値を含むことができる。また、コンポーネントデスクリプタは、ＳＦＣ−３Ｄサービスに適用可能な新たなｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値を含むことができる。

図面を参照すると、本発明の一実施例に係るＳＦＣ−３Ｄサービスは、１つのコンポーネントデスクリプタに基づいてコンポーネントタイプ情報（例えば、ビットストリーム、コンポーネントストリーム、及び／又はビデオストリームの類型）を識別することができる。コンポーネントタイプ情報は、少なくとも１つのパラメータを含むことができる。

例えば、パラメータは、ビットストリーム情報、ビデオストリームのコーデック情報（エンコーディングタイプ情報）、プロファイル（ｐｒｏｆｉｌｅ）情報、レゾリューション情報、画面比率情報、フレームレート情報、映像フォーマット情報、及び／又はＢｉｔｄｅｐｔｈ情報を含むことができる。

ビットストリーム情報は、ビットストリームのタイプに関する情報である。例えば、ビットストリーム情報は、ビデオストリーム、オーディオストリーム、及び／又はサブタイトルストリームを含むことができる。コーデック情報は、ビットストリームをエンコーディングしたコーデックに関する情報である。例えば、コーデック情報は、Ｈ．２６５／ＨＥＶＣを含むことができる。レゾリューション情報は、ビットストリームに関する解像度情報である。例えば、レゾリューション情報は、Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ及び／又はＳｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎを含むことができる。画面比率情報は、ビデオデータをディスプレイする場合、フレームに対する横サイズと縦サイズとの比率情報である。例えば、画面比率情報は、１６：９ ａｓｐｅｃｔ ｒａｔｉｏを含むことができる。フレームレート情報は、１秒にビデオフレームが何回出力されるかに関する情報である。例えば、フレームレート情報は、２５Ｈｚ及び／又は３０Ｈｚを含むことができる。映像フォーマット情報は、ビデオストリームに含まれた左映像及び右映像の配列に関する情報である。例えば、映像フォーマット情報は、サイド−バイ−サイド及び／又はトップ−アンド−ボトムを含むことができる。Ｂｉｔｄｅｐｔｈ情報は、カラー（または灰色の影）を再現できるカラー（またはグレースケールイメージの場合、明るさの程度）数の単位を示す情報である。例えば、Ｂｉｔｄｅｐｔｈは、８−ｂｉｔ Ｂｉｔｄｅｐｔｈ及び／又は１０−ｂｉｔ Ｂｉｔｄｅｐｔｈを含むことができる。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅの値が‘０ｘ８０’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ”を示すことができる。

ここで、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’である場合には、Ｈ．２６５／ＨＥＶＣビデオを示すことができる。また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値である‘０ｘ０９’及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値である‘０ｘ８０’は固定された値ではないので、変更可能である。

また、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ”は、ビットストリームはビデオストリームであり、ビデオストリームはＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされ、ビデオストリームは、フレーム−コンパチブル３Ｄサービスを支援するＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎビデオを示すことができる。

また、“１６：９ ａｓｐｅｃｔ ｒａｔｉｏ”は、ビデオストリームの画面比率情報を示し、“２５Ｈｚ”は、ビデオストリームのフレームレート情報を示し、“Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ”は、ビデオストリームに含まれた左映像及び／又は右映像の映像フォーマット情報を示すことができる。以下では、同一の表現方式は同一の意味を示すので、簡単に説明する。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８１’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ”を示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８２’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ”を示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８３’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ”を示すことができる。

既存の２Ｄ受信機は、既存の２Ｄサービスで使用されるｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像をディスプレイすることができる。

本発明の一実施例に係るＳＦＣ−３Ｄサービスを支援する受信機は、新たに定義されたｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像及び／又は３Ｄ映像をディスプレイすることができる。

図７０は、本発明の一実施例に係る、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報は、コンポーネントデスクリプタを含むことができる。コンポーネントデスクリプタは、コンポーネントストリームのタイプを識別することができる。コンポーネントデスクリプタについての具体的な内容は、前述した内容と同一であるので、前述した内容で代替する。

図面を参照すると、コンポーネントタイプは、ｂｉｔｄｅｐｔｈの値によってより細分化することができる。Ｂｉｔｄｅｐｔｈは、カラー（または灰色の影）を再現できるカラー（またはグレースケールイメージの場合、明るさの程度）数の単位を示すことができる。例えば、Ｂｉｔｄｅｐｔｈは、８−ｂｉｔ Ｂｉｔｄｅｐｔｈ及び／又は１０−ｂｉｔ Ｂｉｔｄｅｐｔｈを含むことができる。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８０’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ、８ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８１’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ、８ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８２’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ、８ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８３’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ、８ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。

また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８４’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ、１０ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８５’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、２５Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ、１０ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８６’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ、１０ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’であり、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ８７’である場合、ビデオデータは、“Ｈ．２６５／ＨＥＶＣ ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、３０Ｈｚ、Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ、１０ ｂｉｔ ｂｉｔｄｅｐｔｈ”を示すことができる。

受信機は、コンポーネントデスクリプタに基づいて、コンポーネントストリーム（例えば、ビデオストリーム）のタイプを識別することができる。例えば、受信機は、コンポーネントデスクリプタに基づいて、ビデオストリームがＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされたｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏであることを識別することができる。また、受信機は、コンポーネントデスクリプタに基づいて、ビデオストリームに含まれた左映像及び右映像の映像フォーマット情報は“ｔｏｐ ａｎｄ ｂｏｔｔｏｍ”であることを識別することができる。

図７１は、本発明の一実施例に係る、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報は、複数のコンポーネントデスクリプタを含むことができる。

コンポーネントデスクリプタは、コンポーネントストリーム（例えば、ビデオストリーム）のタイプを識別し、エレメンタリーストリームのテキストディスクリプション（ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）を提供するのに使用することができる。コンポーネントデスクリプタ（ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）はＳＤＴ及び／又はＥＩＴに含まれてもよい。

コンポーネントデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄ、ｒｅｓｅｒｖｅｄ_ｆｕｔｕｒｅ_ｕｓｅ ｆｉｅｌｄ、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ（第１ストリームコンテンツ情報）、ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ（コンポーネントタイプ情報）、ｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄ、ＩＳＯ_６３９_ｌａｎｇｕａｇｅ_ｃｏｄｅ ｆｉｅｌｄ、及び／又はｔｅｘｔ_ｃｈａｒ ｆｉｅｌｄを含むことができる。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄ（第２ストリームコンテンツ情報）は、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄと組み合わされてストリームのタイプを識別することができる。コンポーネントデスクリプタは、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄをさらに含み、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔが定義され得る空間を拡張することができる。

ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは、コンポーネントストリームを識別する情報を含むことができる。すなわち、ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは、コンポーネントデスクリプタがどのようなビデオストリームに関するものかを識別することができる。例えば、ｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドは、コンポーネントストリームのためのストリーム識別子デスクリプタ（ＰＳＩプログラムマップセクション内に存在する場合）内のｃｏｍｐｏｎｅｎｔ_ｔａｇフィールドと同一の値を有する。

同一のｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄの値に対して複数のコンポーネントデスクリプタが存在してもよい。例えば、ＳＤＴ及び／又はＥＩＴは、それぞれ複数のコンポーネントデスクリプタを含むことができる。また、ＳＤＴは、１つのコンポーネントデスクリプタを含み、ＥＩＴは、複数のコンポーネントデスクリプタを含んでもよい。

また、コンポーネントストリーム（例えば、ビデオストリーム）のタイプ（例えば、１６：９ ａｓｐｅｃｔ ｒａｔｉｏ、ｓｉｄｅ−ｂｙ−ｓｉｄｅ、及び／又はｔｏｐ ａｎｄ ｂｏｔｔｏｍ）を識別するために、１つのコンポーネントストリームに対して複数のコンポーネントデスクリプタが存在してもよい。

その他のコンポーネントデスクリプタについての具体的な内容は、前述した内容で代替する。

図面を参照すると、本発明の一実施例に係る追加的なコンポーネントデスクリプタは、ビデオストリームに含まれた左映像及び右映像の映像フォーマット情報を含むことができる。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘＡ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ００’である場合、映像フォーマット情報は“Ｔｏｐ−ａｎｄ−Ｂｏｔｔｏｍ”を示すことができる。また、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘＡ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０１’である場合、映像フォーマット情報は“Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ”を示すことができる。ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値、及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値は固定された値ではなく、変更可能である。

シグナリング情報は、複数のコンポーネントデスクリプタを含むことができる。このとき、少なくとも１つのコンポーネントデスクリプタは、同一のビットストリームを識別することができる。また、少なくとも１つのコンポーネントデスクリプタの一部は、同一のビットストリームを識別する同一の内容のコンポーネントデスクリプタであってもよい。また、少なくとも１つのコンポーネントデスクリプタの残りの一部は、同一のビットストリームを識別する異なる内容のコンポーネントデスクリプタであってもよい。

ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの組み合わせによって、ビットストリーム（例えば、ビデオストリーム及び／又はオーディオストリームのエンコーディングタイプ情報（圧縮情報）、３Ｄサービスを提供するビデオストリームに含まれた左映像及び右映像の映像フォーマット情報、ビデオデータのプロファイル情報（例えば、ＨＥＶＣのプロファイル情報）、画面比率情報、フレームレート情報、及び／又はその他のビットストリーム（ビデオデータ、サブタイトル、及び／又はオーディオデータを含む）の類型を識別できる情報のうちの少なくとも１つが識別されてもよい。

したがって、それぞれのコンポーネントデスクリプタは、ビットストリーム（例えば、ビデオストリーム及び／又はオーディオストリーム）のエンコーディングタイプ情報（圧縮情報）、３Ｄサービスを提供するビデオストリームに含まれた左映像及び右映像の映像フォーマット情報、ビデオデータのプロファイル情報（例えば、ＨＥＶＣのプロファイル情報）、画面比率情報、フレームレート情報、及び／又はその他のビットストリームの類型（ビデオデータ、サブタイトル、及び／又はオーディオデータを含む）を識別できる情報のうちの少なくとも１つを含むことができる。

受信機は、少なくとも１つのコンポーネントデスクリプタを組み合わせて、ビットストリームのエンコーディングタイプ情報、３Ｄサービスを提供するビデオストリームに含まれた左映像及び右映像の映像フォーマット情報、及び／又はビットストリームに関する追加情報を獲得することができる。例えば、受信機は、少なくとも１つのコンポーネントデスクリプタを組み合わせて、ビットストリームがＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされたという情報、及び／又は映像フォーマットの形態はサイド−バイ−サイドフォーマットであるという情報を獲得することができる。また、受信機は、少なくとも１つのコンポーネントデスクリプタを組み合わせて、ビットストリームがＳＦＣ−３Ｄサービスを提供するという情報を獲得することができる。

コンポーネントデスクリプタは、既存の２Ｄサービス（２Ｄ ＨＥＶＣ）で使用されるｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値、及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値を含むことができる。例えば、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ００’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、５０Ｈｚ”を示すことができる。また、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０１’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ １０ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、５０Ｈｚ”を示すことができる。また、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０２’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、６０Ｈｚ”を示すことができる。また、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０３’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ １０ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、６０Ｈｚ”を示すことができる。また、コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０４’である場合、ビデオデータは、“ＨＥＶＣ ｕｌｔｒａ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ”を示すことができる。

また、コンポーネントデスクリプタは、ＳＦＣ−３Ｄサービスに適用可能な新たなｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値、及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値を含むことができる。

したがって、既存の２Ｄ受信機は、既存の２Ｄサービスで使用されるｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値、及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像をディスプレイすることができる。また、ＳＦＣ−３Ｄサービスを支援する受信機は、新たに定義されたｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値、及び／又はｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値に基づいてビデオデータを処理して、２Ｄ映像及び／又は３Ｄ映像をディスプレイすることができる。

また、本発明の一実施例に係るＳＦＣ−３Ｄサービスは、複数の（ｍｕｌｔｉｐｌｅ）コンポーネントデスクリプタに基づいて、同一の１つのビットストリーム（例えば、ビデオストリーム）の類型を識別することができる。

例えば、シグナリング情報は、第１コンポーネントデスクリプタ、第２コンポーネントデスクリプタ、第３コンポーネントデスクリプタ、及び／又は第４コンポーネントデスクリプタを含むことができる。第１コンポーネントデスクリプタ、第２コンポーネントデスクリプタ、第３コンポーネントデスクリプタ、及び／又は第４コンポーネントデスクリプタは、同一のｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄの値を用いて、同一のビットストリームを識別することができる。

第１コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ００’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、５０Ｈｚ”を示すことができる。

第２コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０Ｂ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘＦ’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０３’である場合、ビデオデータは、“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”を示すことができる。

第３コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０Ｂ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘＦ’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０１’である場合、ビデオデータは、“１６：９ ａｓｐｅｃｔ ｒａｔｉｏ”を示すことができる。

第４コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０Ｂ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘＦ’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０３’である場合、ビデオデータは、“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”を示すことができる。ここで、第２コンポーネントデスクリプタと第４コンポーネントデスクリプタは、同一のストリームを識別する、同一の内容のコンポーネントデスクリプタである。

したがって、シグナリング情報は、第１コンポーネントデスクリプタ、第２コンポーネントデスクリプタ、第３コンポーネントデスクリプタ、及び／又は第４コンポーネントデスクリプタのうちの少なくとも１つを組み合わせて、同一の１つのビデオストリームを識別することができる。

受信機は、少なくとも１つのコンポーネントデスクリプタに基づいて、受信したビットストリームのタイプを識別することができる。受信機は、複数のコンポーネントデスクリプタの一部のコンポーネントデスクリプタを認識できなくても、サービスを受信することができる。すなわち、複数のコンポーネントデスクリプタ間の関係を“ｏｒ”演算で処理して、一部のコンポーネントデスクリプタのみに基づいてサービスを受信することができる。

例えば、受信機が第１コンポーネントデスクリプタのみを受信すれば、受信機は、受信したビデオストリームがＨ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされたｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏであることを識別することができる。

また、受信機が第１コンポーネントデスクリプタ及び第２コンポーネントデスクリプタを受信すれば、受信機は、第１コンポーネントデスクリプタと第２コンポーネントデスクリプタとを組み合わせて、受信したビデオストリームが、Ｈ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされたＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏであり、ビデオストリームに含まれた左映像及び右映像の映像フォーマット情報が、“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”であることを識別することができる。

また、受信機は、シグナリング情報の受信中に複数のコンポーネントデスクリプタのうちの少なくとも１つのコンポーネントデスクリプタを受できなくても、残りのコンポーネントデスクリプタを受信することによって、同一の１つのビデオストリームを識別することができる。例えば、受信機が第４コンポーネントデスクリプタを受信できなくても、受信機は、第２コンポーネントデスクリプタを受信し、ビデオストリームに含まれた左映像及び右映像の映像フォーマット情報を“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”として識別することができる。

図７２は、本発明の一実施例に係る、リンケージデスクリプタのｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ及び／又はｌｉｎｋ_ｔｙｐｅ ｆｉｅｌｄを示す図である。

シグナリング情報はリンケージデスクリプタを含むことができる。

リンケージデスクリプタは、ＳＩシステム内の特定のｅｎｔｉｔｙに関連する付加情報が要求されるときに存在し得るサービスを示すことができる。リンケージデスクリプタは、付加情報を提供するサービスが要求される当該テーブル内に存在してもよい。Ｓｅｒｖｉｃｅ ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅのような場合、リンケージデスクリプタを使用して指定することができ、現在行われているサービスのｒｕｎｎｉｎｇ ｓｔａｔｕｓが‘ｎｏｎ ｒｕｎｎｉｎｇ’状態のとき、受信機で当該ｒｅｐｌａｃｅｍｅｎｔ ｓｅｒｖｉｃｅを自動的に選択することができる。

例えば、リンケージデスクリプタは、ＳＤＴ及び／又はＥＩＴに含まれてもよい。ただし、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０Ｄ’乃至‘０ｘ１Ｆ’の範囲である場合、リンケージデスクリプタはＥＩＴにのみ含まれてもよい。受信機は、リンケージデスクリプタに基づいて、現在視聴している特定の２Ｄ ｓｅｒｖｉｃｅ_ｉｄまたは今後放送される特定の２Ｄ ｅｖｅｎｔ_ｉｄに対して対応する３Ｄサービスまたはイベントを把握することができる。

リンケージデスクリプタは、ｄｅｓｃｒｉｐｔｏｒ_ｔａｇ ｆｉｅｌｄ、ｄｅｓｃｒｉｐｔｏｒ_ｌｅｎｇｔｈ ｆｉｅｌｄ、ｔｒａｎｓｐｏｒｔ_ｓｔｒｅａｍ_ｉｄ ｆｉｅｌｄ、ｏｒｉｇｉｎａｌ_ｎｅｔｗｏｒｋ_ｉｄ ｆｉｅｌｄ、ｓｅｒｖｉｃｅ_ｉｄ ｆｉｅｌｄ、ｌｉｎｋａｇｅ_ｔｙｐｅ ｆｉｅｌｄ、ｍｏｂｉｌｅ_ｈａｎｄ−ｏｖｅｒ_ｉｎｆｏ（） ｆｉｅｌｄ、ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（） ｆｉｅｌｄ、ｅｘｔｅｎｄｅｄ_ｅｖｅｎｔ_ｌｉｎｋａｇｅ_ｉｎｆｏ（） ｆｉｅｌｄ、及び／又はｐｒｉｖａｔｅ_ｄａｔａ_ｂｙｔｅ ｆｉｅｌｄを含むことができる。リンケージデスクリプタについての具体的な内容は、前述した内容で代替する。

図７３は、本発明の一実施例に係る、受信機のブロック図を示す図である。

図面を参照すると、本発明の一実施例に係る受信機は、受信部Ｃ２０２１０、復調部Ｃ２０２２０、逆多重化部Ｃ２０２３０、シグナリング情報処理部Ｃ２０２４０、デコーディング部Ｃ２０２５０、及び／又は出力部Ｃ２０２６０を含む。前述した内容は放送信号送信装置に適用できる。

受信部Ｃ２０２１０は、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チャネルを介して放送信号を受信する。

受信部Ｃ２０２１０は、ビデオコンポーネントに対するビデオストリームと、ビデオストリームをシグナリングするシグナリング情報とを含む放送信号を受信することができる。ビデオストリームは、フレームコンパチブル（Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ）な３−Ｄｉｍｅｎｓｉｏｎａｌ Ｔｅｌｅｖｉｓｉｏｎ（３ＤＴＶ）サービス及びＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｎ（ＨＤＴＶ）サービスのうちの１つを提供することができる。

例えば、シグナリング情報は、ビデオストリームがフレームコンパチブルな３ＤＴＶビデオフォーマットであるか、またはＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｎ（ＨＤＴＶ）ビデオフォーマットであるかを示す第１情報、ビデオストリームのサービスタイプがＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ） ｓｅｒｖｉｃｅであることを示すサービスタイプ情報、及びビデオストリームに対してＨＥＶＣサービスのタイプを示す複数のコンポーネントデスクリプタを含むことができる。

また、シグナリング情報は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅ、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、ＡＦＤ／ｂａｒ ｄａｔａ、ＨＥＶＣ_ｖｉｄｅｏ_ｄｅｓｃｒｉｐｔｏｒ、コンテンツデスクリプタ（ｃｏｎｔｅｎｔ_ｄｅｓｃｒｉｐｔｏｒ）、Ｄｉｓｐａｒｉｔｙ Ｓｉｇｎａｌｌｉｎｇ Ｓｅｇｍｅｎｔ（ＤＳＳ）、ＤＶＢサブタイトルに関する情報、サブタイトリングデスクリプタ（ｓｕｂｔｉｔｌｉｎｇ ｄｅｓｃｒｉｐｔｏｒ）、ディスパリティー情報、ビデオデプスレンジデスクリプタ（Ｖｉｄｅｏ ｄｅｐｔｈ ｒａｎｇｅ ｄｅｓｃｒｉｐｔｏｒ）、マルチリージョンディスパリティー（Ｍｕｌｔｉ−ｒｅｇｉｏｎ ｄｉｓｐａｒｉｔｙ）、サービスデスクリプタ（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｏｒ）、コンポーネントデスクリプタ、及び／又はリンケージデスクリプタのうちの少なくとも１つを含むことができる。

復調部Ｃ２０２２０は、受信した放送信号を復調する。

逆多重化部Ｃ２０２３０は、復調された放送信号から、オーディオデータ、ビデオデータ及び／又はシグナリング情報を逆多重化（ｄｅｍｕｌｔｉｐｌｅｘ）する。そのために、逆多重化部Ｃ２０２３０は、ＰＩＤ（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ）を用いてフィルタリング（ｆｉｌｔｅｒｉｎｇ）することによって、放送信号を逆多重化することができる。逆多重化部Ｃ２０２３０は、逆多重化されたビデオ信号を後段のデコーディング部Ｃ２０２５０に出力し、シグナリング情報をシグナリング情報処理部Ｃ２０２４０に出力する。

シグナリング情報処理部Ｃ２０２４０は、逆多重化部Ｃ２０２３０から伝達されたシグナリング情報を処理することができる。また、シグナリング情報処理部Ｃ２０２４０は、シグナリング情報に基づいてビデオストリームの類型を識別することができる。ここで、シグナリング情報処理部Ｃ１０２４０は、処理されるシグナリング情報を一時格納するデータベース（ＤＢ：Ｄａｔａｂａｓｅ）を内部または外部に備えてもよい。

シグナリング情報処理部Ｃ２０２４０は、シグナリング情報に基づいて、３ＤＴＶビデオフォーマットとＨＤＴＶビデオフォーマットとの間でスイッチングを指示することができる。一方、受信機は、ユーザから、ビデオストリームを２Ｄ映像モードで出力することを指示するスイッチング情報が入力され得る。この場合、シグナリング情報はスイッチング情報を含むことができる。

デコーディング部Ｃ２０２５０は、逆多重化されたビデオデータを受信してデコーディングする。例えば、デコーディング部Ｃ２０２５０は、シグナリング情報に基づいてビデオデータをデコーディングすることができる。デコーディング部Ｃ２０２５０は、３ＤＴＶビデオフォーマット及び／又はＨＤＴＶビデオフォーマットのビデオストリームをデコーディングすることができる。

出力部Ｃ２０２６０は、デコーディングされたビデオデータを出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）して出力することができる。出力部Ｃ２０２６０は、ビデオストリームを３ＤＴＶビデオフォーマット及びＨＤＴＶビデオフォーマットのいずれか１つのフォーマットで出力することができる。

ここで、出力部は、デコーディングされたビデオデータが３ＤＴＶビデオデータである場合には、３Ｄ出力のための出力フォーマットに合わせてフォーマッティングすることができる。出力部Ｃ２０２６０は、デコーディングされたビデオデータが２Ｄビデオデータである場合には、２Ｄ出力のための出力フォーマットに合わせてビデオデータを別途に加工せずに、そのまま出力することができる。

以下では、本発明の一実施例に係る放送信号の受信方法を説明する。

シグナリング情報処理部Ｃ２０２４０は、ＰＭＴに含まれたシグナリング情報を処理する。シグナリング情報処理部Ｃ２０２４０は、シグナリング情報に基づいて受信したチャネル情報を獲得し、チャネルマップを生成することができる。

シグナリング情報処理部Ｃ２０２４０は、受信したビデオストリームが３ＤＴＶビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを識別することができる。

例えば、シグナリング情報処理部Ｃ２０２４０は、ＰＭＴ内に含まれたＨＥＶＣ ｖｉｄｅｏ ｄｅｓｃｒｉｐｔｏｒのｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇを確認する。ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームが３ＤＴＶビデオフォーマットであるか、またはＨＤＴＶビデオフォーマットであるかを示すことができる。また、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄは、ビデオストリームにＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在するか否かをシグナルすることができる。

例えば、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄが、ビデオストリームが３ＤＴＶビデオフォーマットであることを示す場合、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在してもよい。また、ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ ｆｉｅｌｄが、ビデオストリームがＨＤＴＶビデオフォーマットであることを示す場合、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが存在しなくてもよい。

もし、ビデオストリームがＨＤＴＶビデオフォーマットであれば、デコーディング部Ｃ２０２５０は、ＨＤＴＶビデオフォーマットのビデオストリームをデコーディングすることができる。また、出力部Ｃ２０２６０は、デコーディングされたビデオストリームを２Ｄ映像として出力することができる。

もし、ビデオストリームが３ＤＴＶビデオフォーマットであれば、シグナリング情報処理部Ｃ２０２４０は、ビデオストリームのサービスのタイプ及びコンポーネントストリームのタイプを識別することができる。

まず、シグナリング情報処理部Ｃ２０２４０は、サービスデスクリプタのサービスタイプ情報（ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄ）に基づいてサービスのタイプを識別することができる。

ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄは、放送信号（例えば、ＭＰＥＧ−ＴＳ）にＨＥＶＣビデオサービスが存在するか否かをシグナルすることができる。例えば、ｓｅｒｖｉｃｅ_ｔｙｐｅ ｆｉｅｌｄの値が“０ｘ１Ｆ”であれば、サービスタイプは、“ＨＥＶＣ ｄｉｇｉｔａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｅｒｖｉｃｅ”及び／又は“Ｈ．２６５／ＨＥＶＣ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ ＨＤサービス”を示すことができる。

その後、シグナリング情報処理部Ｃ２０２４０は、コンポーネントデスクリプタの第１ストリームコンテンツ情報（ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄ）、第２ストリームコンテンツ情報、及びコンポーネントタイプ情報（ｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ）に基づいて、コンポーネントストリームのタイプを識別することができる。

例えば、それぞれのコンポーネントデスクリプタは、ビデオストリームのタイプを示す第１ストリームコンテンツ情報、第１ストリームコンテンツ情報と組み合わせてビデオストリームのタイプを示す第２ストリームコンテンツ情報、及びビデオコンポーネントのタイプを示すコンポーネントタイプ情報を含むことができる。コンポーネントデスクリプタは、第１ストリームコンテンツ情報、第２ストリームコンテンツ情報、及びコンポーネントタイプ情報に基づいて、前記ＨＥＶＣサービスのタイプを示すことができる。．

同一のｃｏｍｐｏｎｅｎｔ_ｔａｇ ｆｉｅｌｄの値に対して、複数のコンポーネントデスクリプタが存在してもよい。例えば、ＳＤＴ及び／又はＥＩＴは、それぞれ複数のコンポーネントデスクリプタを含むことができる。また、ＳＤＴは１つのコンポーネントデスクリプタを含み、ＥＩＴは複数のコンポーネントデスクリプタを含んでもよい。また、コンポーネントストリーム（例えば、ビデオストリーム）のタイプ（例えば、１６：９ａｓｐｅｃｔ ｒａｔｉｏ、ｓｉｄｅ−ｂｙ−ｓｉｄｅ、及び／又はｔｏｐ ａｎｄ ｂｏｔｔｏｍ）を識別するために、１つのコンポーネントストリームに対して複数のコンポーネントデスクリプタが存在してもよい。

例えば、第１コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０９’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘ０’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ００’である場合、ビデオデータは、“ＨＥＶＣ Ｍａｉｎ Ｐｒｏｆｉｌｅ ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏ、５０Ｈｚ”を示すことができる。

第２コンポーネントデスクリプタのｓｔｒｅａｍ_ｃｏｎｔｅｎｔ ｆｉｅｌｄの値が‘０ｘ０Ｂ’、ｓｔｒｅａｍ_ｃｏｎｔｅｎｔ_ｅｘｔ ｆｉｅｌｄの値が‘０ｘＦ’、及びｃｏｍｐｏｎｅｎｔ_ｔｙｐｅ ｆｉｅｌｄの値が‘０ｘ０３’である場合、ビデオデータは、“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”を示すことができる。

本発明の一実施例によれば、サービスタイプ情報及び第１コンポーネントデスクリプタはＳＤＴに含まれ、第２コンポーネントデスクリプタはＥＩＴに含まれてもよい。

また、本発明の一実施例によれば、ＳＤＴ及び／又はＥＩＴは、複数のコンポーネントデスクリプタを含むことができる。例えば、ＳＤＴ及び／又はＥＩＴは、少なくとも１つの第１コンポーネントデスクリプタ、及び／又は少なくとも１つの第２コンポーネントデスクリプタを含むことができる。

シグナリング情報処理部Ｃ２０２４０は、第１コンポーネントデスクリプタ及び第２コンポーネントデスクリプタを組み合わせて、受信したビデオストリームが、Ｈ．２６５／ＨＥＶＣビデオコーディング技法を用いてエンコーディングされたＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ ｖｉｄｅｏであり、ビデオストリームに含まれた左映像及び右映像の映像フォーマット情報が、“ｐｌａｎｏ−ｓｔｅｒｅｏｓｃｏｐｉｃ ｔｏｐ ａｎｄ ｂｏｔｔｏｍ（ＴａＢ） ｆｒａｍｅ−ｐａｃｋｉｎｇ”であることを識別することができる。

シグナリング情報処理部Ｃ２０２４０は、ビデオストリームに含まれたＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅを獲得することができる。シグナリング情報処理部Ｃ２０２４０は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅに基づいて、ビデオストリームに関する具体的な情報を獲得することができる。例えば、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅは、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｉｄ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｃａｎｃｅｌ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｔｙｐｅ ｆｉｅｌｄ、ｑｕｉｎｃｕｎｘ_ｓａｍｐｌｉｎｇ_ｆｌａｇ ｆｉｅｌｄ、ｃｏｎｔｅｎｔ_ｉｎｔｅｒｐｒｅｔａｔｉｏｎ_ｔｙｐｅ ｆｉｅｌｄ、ｓｐａｔｉａｌ_ｆｌｉｐｐｉｎｇ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｆｌｉｐｐｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｉｅｌｄ_ｖｉｅｗｓ_ｆｌａｇ ｆｉｅｌｄ、ｃｕｒｒｅｎｔ_ｆｒａｍｅ_ｉｓ_ｆｒａｍｅ０_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ１_ｓｅｌｆ_ｃｏｎｔａｉｎｅｄ_ｆｌａｇ ｆｉｅｌｄ、ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄ、ｆｒａｍｅ０_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄ、ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｘ ｆｉｅｌｄ、ｆｒａｍｅ１_ｇｒｉｄ_ｐｏｓｉｔｉｏｎ_ｙ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｓｅｒｖｅｄ_ｂｙｔｅ ｆｉｅｌｄ、ｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｒｅｐｅｔｉｔｉｏｎ_ｐｅｒｉｏｄ ｆｉｅｌｄ、及び／又はｆｒａｍｅ_ｐａｃｋｉｎｇ_ａｒｒａｎｇｅｍｅｎｔ_ｅｘｔｅｎｓｉｏｎ_ｆｌａｇ ｆｉｅｌｄを含むことができる。

出力部Ｃ２０２６０は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅに基づいて、ビデオストリームを３Ｄ映像として出力することができる。

出力部Ｃ２０２６０は、Ｆｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅに基づいて、３Ｄ映像を左映像と右映像とに分離することができる。また、出力部Ｃ２０２６０は、左映像及び右映像をフォーマッティングして、３Ｄ映像として出力することができる。そのために、出力部Ｃ２０２６０は、左映像及び右映像を３Ｄ出力フォーマットに合わせてフォーマッティング（ｆｏｒｍａｔｔｉｎｇ）するフォーマッタ（図示せず）をさらに含むことができる。

また、出力部Ｃ２０２６０は、ＡＦＤ／ｂａｒ ｄａｔａに基づいて、受信機のａｓｐｅｃｔ ｒａｔｉｏに合せて映像の画面比を効率的に変更して３Ｄ映像を出力することができる。

一方、受信機は、ユーザから、ビデオストリームを２Ｄ映像モードで出力することを示すスイッチング情報が入力されてもよい。この場合、シグナリング情報は、スイッチング情報を含むことができる。

もし、シグナリング情報が２Ｄ映像モードで出力することを示す場合、シグナリング情報処理部Ｃ２０２４０は、ビデオストリームから、左映像または右映像のいずれか１つの映像を抽出することができる。また、出力部Ｃ２０２６０は、抽出された１つの映像を２Ｄ映像として出力することができる。

例えば、シグナリング情報処理部Ｃ２０２４０は、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報及び／又はＡＦＤ／ｂａｒ ｄａｔａを獲得することができる。すなわち、Ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ ＳＥＩ ｍｅｓｓａｇｅが含まれたｓｔｒｅａｍである場合、ＤＤＷ情報は、３Ｄ映像から２Ｄ映像を抽出するための情報を含むことができ、ＡＦＤ／ｂａｒ ｄａｔａは、エンコーディングされたビデオ領域全体において有効領域を抽出する情報を含むことができる。

出力部Ｃ２０２６０は、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報に基づいて３Ｄ映像から２Ｄ映像を抽出し、ＡＦＤ／ｂａｒ ｄａｔａに基づいて有効領域を分離することができる。

また、出力部Ｃ２０２６０は、抽出された１つの映像をアップスケーリングすることができる。

本発明の一実施例に係る放送信号送信装置は、第１エンコーダ（図示せず）、第２エンコーダ（図示せず）、及び／又は送信部（図示せず）を含むことができる。

第１エンコーダは、ビデオコンポーネントにビデオストリームを生成することができる。ビデオストリームは、フレームコンパチブル（Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ）な３−Ｄｉｍｅｎｓｉｏｎａｌ Ｔｅｌｅｖｉｓｉｏｎ（３ＤＴＶ）サービス及びＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｎ（ＨＤＴＶ）サービスのいずれか１つを提供することができる。

シグナリング情報は、ビデオストリームがフレームコンパチブルな３ＤＴＶビデオフォーマットであるか、またはＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅｖｉｓｉｏｎ（ＨＤＴＶ）ビデオフォーマットであるかを示す第１情報、ビデオストリームのサービスタイプがＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）ｓｅｒｖｉｃｅであることを示すサービスタイプ情報、及びビデオストリームに対して前記ＨＥＶＣサービスのタイプを示す複数のコンポーネントデスクリプタを含むことができる。送信部は、ビデオストリーム及びシグナリング情報を含む放送信号を伝送することができる。

また、本発明の一実施例に係る放送信号送信方法は、前述した放送信号送信装置を用いて行われてもよく、放送信号受信方法の逆の過程で行われてもよい。前述した内容は、放送信号送信装置及び／又は放送信号送信方法に適用できる。

図７４は、本発明の一実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ情報によるＡｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）を示す図である。

ＡＦＤは、ｃｏｄｅｄ ｖｉｄｅｏ ｆｒａｍｅにおいて関心のある特定の領域を説明する情報である。放送送信機は、関心のある特定の領域をシグナリングするために、ａｃｔｉｖｅ_ｆｏｒｍａｔ情報を伝送し、受信機は、関心のある特定の領域を識別するために、ａｃｔｉｖｅ_ｆｏｒｍａｔ情報を用いることができる。

ＡＦＤは、後述するｂａｒ ｄａｔａと共に、関心のある特定の領域を識別するのに用いることができる。ｂａｒ ｄａｔａは、画面の上端又は下端に表示される上端または下端バー（ｌｅｔｔｅｒ ｂｏｘ）、または画面の左側又は右側に表示される側面バー（ｐｉｌｌａｒ ｂｏｘ）のサイズ情報を含む。

ＡＦＤは、プログラムのソースフォーマット、プログラムの伝送のためのフォーマット及び当該プログラムを消費する対象受信機のフォーマット間の互換性の問題を解決するための用途に用いることができる。例えば、ワイドスクリーン用に製作された１４：９コンテンツ（またはプログラム）は、４：３の画面を有する受信機のユーザのために、４：３でコーディングされたフレーム内でｌｅｔｔｅｒ ｂｏｘを含む形態で伝送されてもよい。しかし、この場合、ワイドスクリーン受信機を有するユーザは、望まないｌｅｔｔｅｒ ｂｏｘをディスプレイしたり、または画面の比率が合わない状態で１４：９のコンテンツを消費しなければならないという問題が発生することがある。したがって、受信機の画面比率に合せて、受信機が、当該コンテンツにおいて関心のある領域を識別し、当該領域をディスプレイできるように、シグナリング情報を提供することができ、これが、ＡＦＤ及び／又はｂａｒ ｄａｔａに該当することができる。ここで、‘関心のある領域’は、コンテンツの内容が含まれる画面の領域として定義することができる。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報は、受信機において、ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏと共に用いられてもよい。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏは、伝送されるｓｏｕｒｃｅコンテンツのａｓｐｅｃｔ ｒａｔｉｏを示す。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏは、伝送される放送データのコーディング方式に応じて、シグナリング情報として提供されるか、または提供されるシグナリング情報を用いて受信機で計算してもよい。

例えば、ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが１６：９を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが１６：９ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームの全領域が‘関心のある領域’となる。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが４：３を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが１６：９ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームにｌｅｔｔｅｒ ｂｏｘが存在することを知ることができる。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが１６：９を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが４：３ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームにｐｉｌｌａｒ ｂｏｘが存在することを知ることができる。

他の例において、例えば、ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが１６：９を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが１６：９ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームの全領域が‘関心のある領域’となる。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが１６：９を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが２１：９ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームにｌｅｔｔｅｒ ｂｏｘが存在することを知ることができる。ｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏが２１：９を示し、ａｃｔｉｖｅ_ｆｏｒｍａｔが１６：９ ｃｅｎｔｅｒを示す場合、受信機は、伝送されるフレームにｐｉｌｌａｒ ｂｏｘが存在することを知ることができる。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報は、放送ストリーム内に含まれて伝達されてもよい。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が００００である場合、‘関心のある領域’が定義されていないか、または活用不可能なことを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が００１０である場合、‘関心がある領域’は、１６：９の比率を有し、画面上側に位置することを示す。すなわち、画面比率の異なる受信機では、下側にｂａｒがディスプレイされ得る。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が００１１である場合、‘関心のある領域’は、１４：９の比率を有し、画面上側に位置することを示す。すなわち、画面比率の異なる受信機では、下側にｂａｒがディスプレイされ得る。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が０１００である場合、‘関心のある領域’は、ａｓｐｅｃｔ ｒａｔｉｏが１６：９よりも大きい領域に該当し、画面の中央に‘関心のある領域’がディスプレイされることを示す。この場合、後述するｂａｒ ｄａｔａを用いて映像の大きさ（横または縦の長さ）を計算しなければならない。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１０００である場合、‘関心のある領域’のａｓｐｅｃｔ ｒａｔｉｏが、コーディングされたフレームのａｓｐｅｃｔ ｒａｔｉｏと同一であることを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１００１である場合、‘関心のある領域’は、４：３の比率を有し、画面の中央に位置することを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１０１０である場合、‘関心のある領域’は、１６：９の比率を有し、画面の中央に位置することを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１０１１である場合、‘関心のある領域’は、１４：９の比率を有し、画面の中央に位置することを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１１０１である場合、‘関心のある領域’は、４：３の比率を有し、フレームは、１４：９の比率を基準としてｐｒｏｔｅｃｔされたことを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１１１０である場合、‘関心のある領域’は、１６：９の比率を有し、フレームは、１４：９の比率を基準としてｐｒｏｔｅｃｔされたことを示す。

Ａｃｔｉｖｅ_ｆｏｒｍａｔ情報の値が１１１１である場合、‘関心のある領域’は、１６：９の比率を有し、フレームは、４：３の比率を基準としてｐｒｏｔｅｃｔされたことを示す。

図７５は、本発明の一実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ及び伝送されるフレームのａｓｐｅｃｔ ｒａｔｉｏによる受信機のディスプレイの例を示す図である。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が００１０を有する場合、４：３でコーディングされたフレームは、フレームの下側にバー（ｂａｒ）を含むようになり、１６：９でコーディングされたフレームは、別途のバーが存在しない。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が００１１を有する場合、４：３でコーディングされたフレームは、フレームの下側にバー（ｂａｒ）を含むようになり、１６：９でコーディングされたフレームは、側面にバーを含むようになる。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が０１００を有する場合、４：３でコーディングされたフレームは、フレームの下側にバー（ｂａｒ）を含むようになり、１６：９でコーディングされたフレームは、フレームの下側にバーを含むようになる。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１０００を有する場合、４：３でコーディングされたフレーム及び１６：９でコーディングされたフレームは両方とも別途のバーを含まない。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１００１を有する場合、４：３でコーディングされたフレームは、別途のバーを含まず、１６：９でコーディングされたフレームは、側面にバーを含むようになる。

上述したような例示は、１６：９でコーディングされたフレームが伝送され、ａｃｔｉｖｅ_ｆｏｒｍａｔが示す内容が、関心のある領域が１６：９、２１：９、または２１：９以上のｗｉｄｅ領域であることを示す場合にも、同様に適用可能である。

図７６は、本発明の他の実施例に係る、ａｃｔｉｖｅ_ｆｏｒｍａｔ及び伝送されるフレームのａｓｐｅｃｔ ｒａｔｉｏによる受信機のディスプレイの例を示す図である。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１０１０を有する場合、４：３でコーディングされたフレームは、フレームの上側及び下側の領域にバーを含み、１６：９でコーディングされたフレームは、別途のバーが存在しない。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１０１１を有する場合、４：３でコーディングされたフレームは、フレームの上側及び下側の領域にバーを含み、１６：９でコーディングされたフレームは、フレームの左／右側面にバーを含む。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１１０１を有する場合、４：３でコーディングされたフレームは、別途のバーを含まず、１６：９でコーディングされたフレームは、フレームの左／右側面にバーを含む。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１１１０を有する場合、４：３でコーディングされたフレームは、フレームの上側及び下側の領域にバーを含み、１６：９でコーディングされたフレームは、別途のバーが存在しない。

ａｃｔｉｖｅ_ｆｏｒｍａｔの値が１１１１を有する場合、４：３でコーディングされたフレームは、フレームの上側及び下側の領域にバーを含み、１６：９でコーディングされたフレームは、別途のバーが存在しない。

上述したような例示は、１６：９でコーディングされたフレームが伝送され、ａｃｔｉｖｅ_ｆｏｒｍａｔが示す内容が、関心のある領域が１６：９、２１：９、または２１：９以上のｗｉｄｅ領域であることを示す場合にも、同様に適用可能である。

図７７は、本発明の一実施例に係るｂａｒ ｄａｔａを示す図である。

ｂａｒ ｄａｔａは、ビデオｕｓｅｒ ｄａｔａに含まれてもよい。ｂａｒ ｄａｔａは、ビデオストリームに含まれてもよい。またはｂａｒ ｄａｔａは、別途のシグナリング信号を介して伝送されてもよい。

本発明の一実施例に係るｂａｒ ｄａｔａは、ｔｏｐ_ｂａｒ_ｆｌａｇ情報、ｂｏｔｔｏｍ_ｂａｒ_ｆｌａｇ情報、ｌｅｆｔ_ｂａｒ_ｆｌａｇ情報、ｒｉｇｈｔ_ｂａｒ_ｆｌａｇ情報、ｍａｒｋｅｒ_ｂｉｔｓ情報、ｌｉｎｅ_ｎｕｍｂｅｒ_ｅｎｄ_ｏｆ_ｔｏｐ_ｂａｒ情報、ｌｉｎｅ_ｎｕｍｂｅｒ_ｓｔａｒｔ_ｏｆ_ｂｏｔｔｏｍ_ｂａｒ情報、ｐｉｘｅｌ_ｎｕｍｂｅｒ_ｅｎｄ_ｏｆ_ｌｅｆｔ_ｂａｒ情報、及び／又はｐｉｘｅｌ_ｎｕｍｂｅｒ_ｓｔａｒｔ_ｏｆ_ｒｉｇｈｔ_ｂａｒ情報を含む。

ｔｏｐ_ｂａｒ_ｆｌａｇ情報は、ｔｏｐ ｂａｒが存在するか否かを識別する。この情報の値が１である場合、ｔｏｐ ｂａｒが存在することを示す。

ｂｏｔｔｏｍ_ｂａｒ_ｆｌａｇ情報は、ｂｏｔｔｏｍ ｂａｒが存在するか否かを識別する。この情報の値が１である場合、ｂｏｔｔｏｍ ｂａｒが存在することを示す。

ｌｅｆｔ_ｂａｒ_ｆｌａｇ情報は、ｌｅｆｔ ｂａｒが存在するか否かを識別する。この情報の値が１である場合、ｌｅｆｔ ｂａｒが存在することを示す。

ｒｉｇｈｔ_ｂａｒ_ｆｌａｇ情報は、ｒｉｇｈｔ ｂａｒが存在するか否かを識別する。この情報の値が１である場合、ｒｉｇｈｔ ｂａｒが存在することを示す。

ｌｉｎｅ_ｎｕｍｂｅｒ_ｅｎｄ_ｏｆ_ｔｏｐ_ｂａｒ情報は、フレームの上端に位置する、水平のｌｅｔｔｅｒ ｂｏｘバーの領域の最後のｌｉｎｅを識別する。

ｌｉｎｅ_ｎｕｍｂｅｒ_ｓｔａｒｔ_ｏｆ_ｂｏｔｔｏｍ_ｂａｒ情報は、フレームの下端に位置する、水平のｌｅｔｔｅｒ ｂｏｘバーの領域の最初のｌｉｎｅを識別する。

ｐｉｘｅｌ_ｎｕｍｂｅｒ_ｅｎｄ_ｏｆ_ｌｅｆｔ_ｂａｒ情報は、フレームの左側面に位置する、垂直のｐｉｌｌａｒ ｂｏｘバーの最後のｈｏｒｉｚｏｎｔａｌ ｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

ｐｉｘｅｌ_ｎｕｍｂｅｒ_ｓｔａｒｔ_ｏｆ_ｒｉｇｈｔ_ｂａｒ情報は、フレームの右側面に位置する、垂直のｐｉｌｌａｒ ｂｏｘバーの最初のｈｏｒｉｚｏｎｔａｌ ｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

ｂａｒ ｄａｔａは、フレームに含まれるｂａｒの位置を識別するシグナリング情報に該当する。

図７８は、本発明の一実施例に係る受信機を示す図である。

前述したｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式及びｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ方式の３Ｄサービス以外に、ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式の３Ｄサービスが追加的に定義されてもよい。ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式は、ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅのように、１つのフレームにおいて左映像及び右映像を伝送／受信し、当該フレームから左映像または右映像を抽出して、これをｕｐ−ｓｃａｌｅし、ｆｕｌｌ ｒｅｓｏｌｕｔｉｏｎの２Ｄサービスを提供できる方式である。

ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式によれば、１つのフレームから２Ｄ映像として使用するイメージ領域を抽出するために、ＤＤＷ情報が必要であり、送信端で伝送するコンテンツのａｓｐｅｃｔ ｒａｔｉｏと受信機のａｓｐｅｃｔ ｒａｔｉｏとの差を補償するためのＡＦＤ情報及び／又はＢａｒ ｄａｔａが共に必要である。すなわち、ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式は、１つのフレーム内で、左映像及び右映像のそれぞれが正確にフレームの半分を占めているが、ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式は、１つのフレーム内において左映像及び右映像がそれぞれ占める領域の比率が変わり得る。したがって、ＤＤＷ情報を通じて、左映像及び／又は右映像の領域を抽出することができる。また、例えば、この過程で２１：９のｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅな３Ｄ映像を、１６：９の受信機が受信する場合には、前述したＡＦＤ情報及び／又はＢａｒ ｄａｔａを用いた、画面比率に対するレンダリングが必要である。したがって、この例では、ＤＤＷ情報及びＡＦＤ情報／Ｂａｒ ｄａｔａの全てを送／受信し、これら情報によって、ｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ方式の映像を処理できる受信機が必要である。

本発明の一実施例に係る受信機は、放送受信部（図示せず）、デマルチプレクサー（ｄｅｍｕｌｔｉｐｌｅｘｅｒ）、デコーダ（ｄｅｃｏｄｅｒ）、２Ｄ／３Ｄスイッチ（２Ｄ／３Ｄ ｓｗｉｔｃｈ）、２Ｄ抽出部（２Ｄ ｅｘｔｒａｃｔｉｎｇ）、第１比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）、Ｌ／Ｒ分離部（Ｌ／Ｒ ｓｐｌｉｔｔｅｒ）、フォーマッタ（ｆｏｒｍａｔｔｅｒ）、及び／又は第２比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）を含むことができる。

ビデオストリームのＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）メッセージは、Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）を含むことができる。ＶＵＩは、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）に関する情報を含むことができる。ＤＤＷ情報は、ｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及び／又はｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含むことができる。

ｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報は、ＤＤＷに関する情報が存在するか否かを識別する。または、ｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報は、ＤＤＷが存在するか否かを識別する。

ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報は、ＤＤＷの左側縁部の位置を識別する。ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報は、ＤＤＷの左側縁部が位置する地点のｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報は、ＤＤＷの右側縁部の位置を識別する。ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報は、ＤＤＷの右側縁部が位置する地点のｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報は、ＤＤＷの上端縁部の位置を識別する。ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報は、ＤＤＷの上端縁部が位置する地点のｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報は、ＤＤＷの下端縁部の位置を識別する。ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報は、ＤＤＷの下端縁部が位置する地点のｌｕｍｉｎａｎｃｅ ｓａｍｐｌｅを識別する。

Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）は、１つのフレーム内で、基準となるイメージの領域を示す。ＤＤＷは、１つのフレームに含まれる２つ以上のイメージのうち、基準イメージとなるイメージの領域を識別する。Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅの３Ｄサービスにおいて、ＤＤＷは、フレーム内のｔｏｐ−ａｎｄ−ｂｏｔｔｏｍまたはｓｉｄｅ−ｂｙ−ｓｉｄｅで区分された左映像と右映像のうち、２Ｄサービスに使用される基準映像の領域を示す四角の領域表示に該当することができる。受信機は、ＤＤＷの情報が示す領域のイメージを、Ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅの３Ｄサービスのフレームにおいて２Ｄサービスのための映像として抽出する。

放送受信部（図示せず）は放送信号を受信する。放送受信部は、放送信号インターフェースまたはチューナーに該当することができる。

デマルチプレクサー（ｄｅｍｕｌｔｉｐｌｅｘｅｒ）は、放送信号を逆多重化して、シグナリング情報（ＰＳＩ／ＳＩ）、ビデオデータ、オーディオデータを抽出する。放送信号は、ＰＳＩ／ＳＩ情報、シグナリング情報、ＤＤＷと関連する情報、ＡＦＤ情報、ｂａｒ ｄａｔａ及び／又はＦｒａｍｅ Ｐａｃｋｉｎｇ Ａｒｒａｎｇｅｍｅｎｔ Ｓｕｐｐｌｅｍｅｎｔａｌ ｅｎｈａｎｃｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ（ＦＰＡ ＳＥＩ）を含むことができる。

デコーダ（ｄｅｃｏｄｅｒ）は、ビデオデータ及び／又はオーディオデータをデコーディングする。デコーダ（ｄｅｃｏｄｅｒ）は、デコーディング過程で受信したシグナリング情報を用いることができる、シグナリング情報は、シグナリングデコーダ（図示せず）によってデコーディングされてもよい。

２Ｄ／３Ｄスイッチ（２Ｄ／３Ｄ ｓｗｉｔｃｈ）は、２Ｄ視聴モードまたは３Ｄ視聴モードに関する制御情報を受信することができ、これによって、ビデオデータの２Ｄまたは３Ｄへの処理を制御する。２Ｄ／３Ｄスイッチ（２Ｄ／３Ｄ ｓｗｉｔｃｈ）は、２Ｄ視聴モードが選択された場合、受信したビデオデータを２Ｄにレンダリングできる装置に伝達する。２Ｄ／３Ｄスイッチ（２Ｄ／３Ｄ ｓｗｉｔｃｈ）は、３Ｄ視聴モードが選択された場合、受信したビデオデータを３Ｄにレンダリングできる装置に伝達する。

２Ｄ抽出部（２Ｄ ｅｘｔｒａｃｔｉｎｇ）は、左映像及び右映像が含まれたフレームをビデオデータとして受信した場合、左映像または右映像を分離する。一実施例において、２Ｄ抽出部（２Ｄ ｅｘｔｒａｃｔｉｎｇ）は、左映像を抽出して２Ｄ映像として使用することができる。２Ｄ抽出部（２Ｄ ｅｘｔｒａｃｔｉｎｇ）は、左映像または右映像を抽出する過程において、前述したＤＤＷ情報を用いて、ＤＤＷが示す領域の映像を抽出する。

第１比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）は、前述したＡＦＤ情報及び／又はｂａｒ ｄａｔａ情報を用いて、フレーム内のバーを挿入又は除去したり、またはフレームのａｓｐｅｃｔ ｒａｔｉｏを調整する。第１比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）は、２Ｄ抽出部（２Ｄ ｅｘｔｒａｃｔｉｎｇ）に含まれてもよい。

Ｌ／Ｒ分離部（Ｌ／Ｒ ｓｐｌｉｔｔｅｒ）は、ビデオデータから、左映像を伝送するビデオデータ（ストリーム）、及び右映像を伝送するビデオデータ（ストリーム）を分離する。

フォーマッタ（ｆｏｒｍａｔｔｅｒ）は、左映像及び右映像を配置して、３Ｄ映像をフォーマッティングする。

第２比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）は、前述したＡＦＤ情報及び／又はｂａｒ ｄａｔａ情報を用いて、フレーム内のバーを挿入又は除去したり、またはフレームのａｓｐｅｃｔ ｒａｔｉｏを調整する。

以下では、説明の便宜のため、２Ｄ ｃｏｍｐａｔｉｂｌｅな２１：９ ｔｏｐ−ａｎｄ−ｂｏｔｔｏｍ ｆｏｒｍａｔの３Ｄ映像を受信した場合、１６：９受信機の動作を説明する。映像は２１：９の画面比、受信機は１６：９の画面比を有する場合を例に挙げて説明するが、入力映像の画面比と受信機の画面比とが異なる場合にも、以下の説明は適用可能である。

比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ、第１比率変換部及び／又は第２比率変換部を含む）は、左映像と右映像が分離されていない状態でその動作を行ってもよい。すなわち、Ｌ／Ｒ分離部（Ｌ／Ｒ ｓｐｌｉｔｔｅｒ）の前に比率変換部（ａｓｐｅｃｔ ｒａｔｉｏ ｃｏｎｖｅｒｔｅｒ）が位置してもよい。

受信機は、ＰＭＴ内にｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ ｌｅｖｅｌ ｄｅｓｃｒｉｐｔｏｒに含まれているＨＥＶＣ ｖｉｄｅｏ ｄｅｓｃｒｉｐｔｏｒのｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇを確認する。ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージがビデオシーケンスに含まれているか否かを識別する。ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ値が０であれば、ビデオシーケンスにＦＰＡ ＳＥＩメッセージが含まれていることを示す。ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ値が０であれば、受信機は、それぞれのＡＵ（Ａｃｃｅｓｓ Ｕｎｉｔ）毎に伝達されるＦＰＡ ＳＥＩ ｍｅｓｓａｇｅを介して、３Ｄサービス／コンテンツがどのような３Ｄ ｆｏｒｍａｔ（Ｓｅｒｖｉｃｅ ｃｏｍｐａｔｉｂｌｅ、Ｔｏｐ ａｎｄ ｂｏｔｔｏｍ、Ｓｉｄｅ−ｂｙ−Ｓｉｄｅ及び／又はｓｅｒｖｉｃｅ ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅ）でｅｎｃｏｄｉｎｇされたかに関する情報を把握する。

受信機は、視聴モードが２Ｄ ｍｏｄｅである場合、ＤＤＷ情報、ＡＦＤ情報、ｂａｒ ｄａｔａ、及び／又はＦＰＡ ＳＥＩ ｍｅｓｓａｇｅがｂｉｔｓｔｒｅａｍ内に含まれていれば、ＶＵＩ（Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）の内部のＤＤＷを用いて、ｌｅｆｔまたはｒｉｇｈｔである２Ｄ映像を分離（ｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ，ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ ａｎｄ ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔを用いる）する。

受信機は、ｖｉｄｅｏ ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍのａｕｘｉｌｉａｒｙ ｄａｔａに含まれるＡＦＤ情報、及び／又はｂａｒ ｄａｔａ ｓｉｇｎａｌｉｎｇを用いて、受信機のａｓｐｅｃｔ ｒａｔｉｏに合せて映像の画面比を効率的に変更し、２Ｄとして出力する。

受信機は、３Ｄ ｍｏｄｅである場合、ＤＤＷ情報、ＡＦＤ情報、ｂａｒ ｄａｔａ、及び／又はＦＰＡ ＳＥＩ ｍｅｓｓａｇｅがｂｉｔｓｔｒｅａｍ内に含まれていれば、ＶＵＩ（Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）の内部のＤＤＷ情報は無視し、ＦＰＡ ＳＥＩ ｍｅｓｓａｇｅを用いて３Ｄ映像をＬ／Ｒに分離し、ｖｉｄｅｏ ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍのａｕｘｉｌｉａｒｙ ｄａｔａに含まれるＡＦＤ情報、及び／又はｂａｒ ｄａｔａ ｓｉｇｎａｌｉｎｇを用いて、受信機のａｓｐｅｃｔ ｒａｔｉｏに合せて映像の画面比を効率的に変更し、３Ｄとしてｄｉｓｐｌａｙする。

従来は、ｄｅｆａｕｌｔ ｄｉｓｐｌａｙ ｗｉｎｄｏｗ（ＤＤＷ）とＡＦＤ／ｂａｒ ｄａｔａを同時に含むことができなかった。したがって、従来は、３Ｄから２Ｄ映像を抽出する過程において、伝送されるコーディングされたフレームのａｓｐｅｃｔ ｒａｔｉｏと受信機の画面のａｓｐｅｃｔ ｒａｔｉｏとが合わない場合、映像処理に問題があった。そこで、本発明によれば、受信機は、受信される映像が３Ｄであることを把握すると、ａｃｔｉｖｅ ａｒｅａと２Ｄ領域の両方ともｅｘｔｒａｃｔｉｏｎできるようにＤＤＷとＡＦＤ／ｂａｒ ｄａｔａを共に使用することで、適切な２Ｄ映像を抽出することができる。

送信機では、ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅフォーマットの３Ｄ映像と２Ｄ映像との互換性獲得するために、ｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報を“１”にセットし、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及び／又はｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報の値を設定して、２Ｄ映像のために使用される領域を知らせるシグナリング情報を生成し、これを受信機に伝送する。この場合、それぞれのＡＵにＦＰＡ ＳＥＩメッセージを含ませる。

受信機は、ｆｒａｍｅ ｃｏｍｐａｔｉｂｌｅフォーマットの３Ｄ映像から２Ｄ映像を抽出するために、ＤＤＷ、ＡＦＤ情報及びＢａｒ ｄａｔａがいずれもＦＰＡ ＳＥＩメッセージに存在するか否かを先に判断する。受信機は、ＦＰＡ ＳＥＩメッセージにＤＤＷ、ＡＦＤ情報及びＢａｒ ｄａｔａがいずれも存在すれば、ＤＤＷ情報を用いて、３Ｄ映像から、２Ｄ映像のために使用されるイメージを分離／抽出する。受信機は、分離／抽出されたイメージを、ＡＦＤ情報及びＢａｒ ｄａｔａを用いて、受信機の画面比率に合せてレンダリングする。

説明の便宜のため、各図を分けて説明したが、各図に述べられている実施例を併合して新しい実施例を具現するように設計することも可能である。そして、当業者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み取り可能な記録媒体を設計することも本発明の権利範囲に属する。

本発明に係る装置及び方法は、上述したように説明された実施例の構成及び方法が限定されて適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部または一部が選択的に組み合わされて構成されてもよい。

一方、本発明のデータ処理方法は、ネットワークデバイスに備えられたプロセッサが読み取り可能な記録媒体に、プロセッサが読み取り可能なコードとして具現することが可能である。プロセッサが読み取り可能な記録媒体は、プロセッサが読み取り可能なデータが格納されるいかなる種類の記録装置をも含む。プロセッサが読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み取り可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み取り可能なコードが格納され、実行されてもよい。

また、以上では、本発明の好ましい実施例について図示し、説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者によって、様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。

そして、当該明細書では、物の発明及び方法の発明が全て説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。

発明の実施のための形態は、前述したように、発明を実施するための最良の形態で詳述された。

本発明は、放送産業全般において利用可能である。

Claims (15)

1. プログラムマップテーブル（ＰＭＴ）と３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータとを含む放送信号を受信するチューナーであって、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含む、前記チューナーと、
   前記ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報が、ＦＰＡ ＳＥＩメッセージが前記３Ｄビデオデータに含まれていることを示す場合、前記ＦＰＡ ＳＥＩメッセージをパージングし、前記ＦＰＡ ＳＥＩメッセージに含まれた、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報をパージングし、前記３Ｄビデオデータに含まれたＤｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、ＡｃｔｉｖｅＦｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ （ＡＦＤ）情報及びＢａｒデータをパージングし、前記３Ｄビデオデータをデコーディングするデコーダと、
   前記３Ｄビデオフォーマット情報及び前記ＤＤＷ情報によって、前記デコーディングされた３Ｄビデオデータのビデオフレーム内で２Ｄディスプレイのための２Ｄ映像を抽出する２Ｄ抽出部と、
   前記抽出された２Ｄ映像を、前記ＡＦＤ情報及びＢａｒデータ情報を用いて、受信機の画面比率に合わせてレンダリングする比率変換部と、
   前記レンダリングされた２Ｄ映像をディスプレイするディスプレイ処理部と、
   を含む、３Ｄ放送受信機。
2. 前記ＤＤＷ情報は、
   前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれる、請求項１に記載の３Ｄ放送受信機。
3. 前記ＤＤＷ情報は、
   ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含む、請求項２に記載の３Ｄ放送受信機。
4. 前記ＡＦＤ情報は、
   関心のある領域の画面比率を識別する情報を含む、請求項３に記載の３Ｄ放送受信機。
5. 前記放送信号は、
   前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含む、請求項４に記載の３Ｄ放送受信機。
6. プログラムマップテーブル（ＰＭＴ）と３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータとを含む放送信号を受信するステップであって、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含む前記ステップと、
   前記ｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報が、ＦＰＡ ＳＥＩメッセージが前記３Ｄビデオデータに含まれていることを示す場合、前記ＦＰＡ ＳＥＩメッセージをパージングし、前記ＦＰＡ ＳＥＩメッセージに含まれた、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報をパージングし、前記３Ｄビデオデータに含まれたＤｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、ＡｃｔｉｖｅＦｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータをパージングし、前記３Ｄビデオデータをデコーディングするステップと、
   前記３Ｄビデオフォーマット情報及び前記ＤＤＷ情報によって、前記デコーディングされた３Ｄビデオデータのビデオフレーム内で２Ｄディスプレイのための２Ｄ映像を抽出するステップと、
   前記抽出された２Ｄ映像を、前記ＡＦＤ情報及びＢａｒデータ情報を用いて、受信機の画面比率に合わせてレンダリングするステップと、
   前記レンダリングされた２Ｄ映像をディスプレイするステップと、
   を含む、３Ｄ放送受信機における放送信号処理方法。
7. 前記ＤＤＷ情報は、
   前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれる、請求項６に記載の３Ｄ放送受信機における放送信号処理方法。
8. 前記ＤＤＷ情報は、
   ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含む、請求項７に記載の３Ｄ放送受信機における放送信号処理方法。
9. 前記ＡＦＤ情報は、
   関心のある領域の画面比率を識別する情報を含む、請求項８に記載の３Ｄ放送受信機における放送信号処理方法。
10. 前記放送信号は、
    前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含む、請求項９に記載の３Ｄ放送受信機における放送信号処理方法。
11. ３Ｄ放送コンテンツのための３−ｄｉｍｅｎｓｉｏｎａｌ（３Ｄ）ビデオデータ、Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ ＦｏｒｍａｔＤｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータを含むビデオシーケンスをエンコーディングするビデオエンコーダと、
    プログラムマップテーブル（ＰＭＴ）をエンコーディングする第１シグナリングエンコーダであって、前記ＰＭＴは、ｆｒａｍｅ ｐａｃｋｉｎｇ ａｒｒａｎｇｅｍｅｎｔ（ＦＰＡ） ＳＥＩメッセージが前記３Ｄビデオデータに含まれているか否かを示すｎｏｎ_ｐａｃｋｅｄ_ｃｏｎｓｔｒａｉｎｔ_ｆｌａｇ情報を含み、前記ＦＰＡ ＳＥＩメッセージは、３Ｄビデオのフォーマットを識別する３Ｄビデオフォーマット情報を含む、前記第１シグナリングエンコーダと、
    Ｄｅｆａｕｌｔ Ｄｉｓｐｌａｙ Ｗｉｎｄｏｗ（ＤＤＷ）情報、Ａｃｔｉｖｅ Ｆｏｒｍａｔ Ｄｅｓｃｒｉｐｔｉｏｎ（ＡＦＤ）情報及びＢａｒデータをエンコーディングする第２シグナリングエンコーダと、
    前記ＰＭＴと前記ビデオシーケンスとを含む放送信号を生成する放送信号生成器と、
    を含む、３Ｄ放送送信機。
12. 前記ＤＤＷ情報は、
    前記３Ｄビデオデータに含まれるＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）データに含まれる、請求項１１に記載の３Ｄ放送送信機。
13. 前記ＤＤＷ情報は、
    ＤＤＷが存在するか否かを識別するｄｅｆａｕｌｔ_ｄｉｓｐｌａｙ_ｗｉｎｄｏｗ_ｆｌａｇ情報、ＤＤＷの左側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｌｅｆｔ_ｏｆｆｓｅｔ情報、ＤＤＷの右側縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｒｉｇｈｔ_ｏｆｆｓｅｔ情報、ＤＤＷの上端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｔｏｐ_ｏｆｆｓｅｔ情報、及びＤＤＷの下端縁部の位置を識別するｄｅｆ_ｄｉｓｐ_ｗｉｎ_ｂｏｔｔｏｍ_ｏｆｆｓｅｔ情報を含む、請求項１２に記載の３Ｄ放送送信機。
14. 前記ＡＦＤ情報は、
    関心のある領域の画面比率を識別する情報を含む、請求項１３に記載の３Ｄ放送送信機。
15. 前記放送信号は、
    前記３Ｄビデオデータの、伝送時に意図された画面比率を示すｓｏｕｒｃｅ ａｓｐｅｃｔ ｒａｔｉｏ情報を含む、請求項１４に記載の３Ｄ放送送信機。

Images