JP5545605B2 - キャプション視差データの伝送に対するサービスの連係 - Google Patents

Description

〔関連出願との相互参照〕
本出願は、２０１０年１１月２２日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された「キャプション視差データの伝送に対するサービスの連係（Ｓｅｒｖｉｃｅ Ｌｉｎｋａｇｅ ｔｏ Ｃａｐｔｉｏｎ Ｄｉｓｐａｒｉｔｙ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ）」という名称の米国仮特許出願第６１／４１５，９２４号、２０１０年１１月１９日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された「３Ｄキャプション付けのための視差データシグナリング及び伝送（Ｄｉｓｐａｒｉｔｙ Ｄａｔａ Ｓｉｇｎａｌｉｎｇ ａｎｄ Ｔｒａｎｓｐｏｒｔ ｆｏｒ ３Ｄ Ｃａｐｔｉｏｎｉｎｇ）」という名称の米国仮特許出願第６１／４１５，４５７号、及び２０１０年５月２０日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された「視差データの伝送（Ｄｉｓｐａｒｉｔｙ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ）」という名称の米国仮特許出願第６１／３４６，６５２号、及び２０１０年３月１２日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された米国仮特許出願第６１／３１３，６１２号、２０１０年３月２３日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された「ＣＥＡ−７０８キャプションのための拡張コマンドストリーム（Ｅｘｔｅｎｄｅｄ Ｃｏｍｍａｎｄ Ｓｔｒｅａｍ ｆｏｒ ＣＥＡ−７０８ Ｃａｐｔｉｏｎｓ）」という名称の米国仮特許出願第６１／３１６，７３３号、及び２０１０年８月３１日に出願された、Ｍａｒｋ Ｅｙｅｒ他に付与された「キャプション付け視差データのフレームごとの変化の効率的伝送（Ｅｆｆｉｃｉｅｎｔ Ｔｒａｎｓｐｏｒｔ ｏｆ Ｆｒａｍｅ−ｂｙ−Ｆｒａｍｅ Ｃｈａｎｇｅ ｉｎ Ｃａｐｔｉｏｎｉｎｇ Ｄｉｓｐａｒｉｔｙ Ｄａｔａ）」という名称の米国仮特許出願第６１／３７８，７９２号の優先権の利益を主張するものであり、これらの特許出願の各々はその全体が引用により本明細書に組み入れられる。

〔著作権表示〕
本特許文書の開示部分は、著作権保護の対象内容を含む。著作権の権利所有者は、合衆国特許商標庁の特許ファイル又は記録内に表される通りに特許文書又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。

３次元（３Ｄ）立体ビデオ番組にクローズドキャプション（ＣＣ）が伴う場合、このキャプションをｚ軸（深度）のいずれの場所に表示するか、及びこの情報をいかにして受信機に伝えるべきかを定義する規格は現在のところ存在しない。このようなシグナリングがなければ、ビデオディスプレイ上に、他のビデオオブジェクトを妨げないように、又は他のビデオオブジェクトによって妨げられないように最適にキャプションを配置することはできない。

米国特許出願第１３／０２２，８１０号明細書

Ｎｉｃｋ Ｈｏｌｌｉｍａｎ博士、「３Ｄ表示システム（３Ｄ Ｄｉｓｐｌａｙ Ｓｙｓｔｅｍ）」、英国、Ｄｕｒｈａｍ ＤＨ１ ３ＬＥ、Ｓｏｕｔｈ Ｒｏａｄ、Ｄｕｒｈａｍ大学、科学研究所、コンピュータ科学学科

添付図面と併せて行う以下の詳細な説明を参照することにより、構成及び動作方法を示す特定の例示的な実施形態、並びに目的及び利点を最も良く理解することができる。

本発明のいくつかの実施形態による、ｃａｐｔｉｏｎ＿ｄｉｓｐａｒｉｔｙ＿ｄａｔａ（）コマンドの配列例を示す図である。 本発明のいくつかの実施形態による、作成された視差データの折れ線近似の例を示す図である。 本発明のいくつかの実施形態によるエンコーダ例を示す図である。 本発明のいくつかの実施形態によるデコーダ例を示す図である。 本発明のいくつかの実施形態によるテレビ受信機装置例を示す図である。 本発明のいくつかの実施形態によるプロセッサの様々な動作を示すブロック図例である。 本発明のいくつかの実施形態による処理のフローチャート例である。

本発明は、多くの異なる形の実施形態が可能であるが、このような実施形態の開示は原理の一例として見なすべきであり、図示及び説明する特定の実施形態に本発明を限定することを意図するものではないという理解の下、図面に特定の実施形態を示し本明細書で詳細に説明する。以下の説明では、図面の複数の図における同様の、類似の又は一致する部分については同じ参照番号を使用して説明する。

本明細書で使用する「１つの（英文不定冠詞）」という用語は、１又は１よりも多くの、と定義される。本明細書で使用する「複数の」という用語は、２又は２よりも多い、と定義される。本明細書で使用する「別の」という用語は、少なくとも第２の又はそれ以上の、と定義される。本明細書で使用する「含む（ｉｎｃｌｕｄｉｎｇ）」及び／又は「有する（ｈａｖｉｎｇ）」という用語は、「備える（ｃｏｍｐｒｉｓｉｎｇ）」（すなわち包括的な用語）と定義される。本明細書で使用する「結合される」という用語は、「接続される」と定義されるが、必ずしも直接的な、また必ずしも機械的な接続ではない。本明細書で使用する「プログラム」又は「コンピュータプログラム」という用語又は類似の用語は、コンピュータシステム上での実行を意図された一連の命令であると定義される。「プログラム」又は「コンピュータプログラム」は、実行可能アプリケーション、アプレット、サーブレット、ソースコード、オブジェクトコード、共有ライブラリ／ダイナミックロードライブラリ、及び／又はコンピュータシステム上で実行するように設計されたその他の一連の命令におけるサブルーチン、プログラムモジュール、スクリプト、関数、手順、オブジェクト方法、オブジェクト実装を含むことができる。

本明細書で使用する「プログラム」という用語は、第２の文脈（上記の定義を第１の文脈とする）で使用することもできる。第２の文脈では、この用語は「テレビ番組」という意味で使用される。この文脈では、この用語は単一のテレビ番組として解釈され、電子番組ガイド（ＥＰＧ）で伝えられるようなあらゆるまとまった一連のオーディオビデオコンテンツを意味するために使用され、このコンテンツが、映画、スポーツイベント、連続番組の一部、ニュース放送などのいずれであるかは関係ない。この用語はまた、電子番組ガイドでは番組として伝えられないコマーシャルスポット及びその他の番組様のコンテンツを含むと解釈することもできる。

本明細書を通じて、「１つの実施形態」、「いくつかの実施形態」、「ある実施形態」、「ある実施構成」、「ある例」、又は同様の用語への言及は、実施形態に関連して説明する特定の特徴、構造又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書を通じて至るところに出現するこのような語句は、必ずしも全てが同じ実施形態について言及するものではない。さらに、上記の特定の特徴、構造又は特性を、本発明を限定することなく１又はそれ以上の実施形態にあらゆる好適な態様で組み合わせることができる。

本明細書で使用する「又は」という用語は包括的なものとして解釈すべきであり、すなわちいずれか１つ又はあらゆる組み合わせを意味する。従って、「Ａ、Ｂ又はＣ」は、「Ａ、Ｂ、Ｃ、ＡとＢ、ＡとＣ、ＢとＣ、ＡとＢとＣ、のいずれか」を意味する。この定義に対する例外は、要素、機能、ステップ又は行為の組み合わせが何らかの点で本質的に互いに相容れない場合にのみ生じる。

３Ｄビデオ番組の表示内にクローズドキャプションを表す場合、ＣＣウィンドウと関連テキストが、異なる、より適切な知覚深度に現れるように表示する措置をとらない限り、これらはスクリーン平面内に表示される可能性が高い。３Ｄコンテンツのシーン内のオブジェクトは、視聴者にとってディスプレイスクリーン平面の前に何らかの距離があると感じられるように表示することができる。万一、ディスプレイ平面と同じ深度に配置されたキャプションウィンドウがこのオブジェクトの前に配置された場合、「深度違反」が発生する。このような場合、相入れない深度表現が視聴者に示され、眼精疲労及び不快感を生じる状況となる。キャプションは、単純にスクリーン平面に位置する場合、シーン内のコンテンツとｚ軸で交差することができるので、キャプションの表示は、ビデオ表示の主題に対して個別に作成されることが好ましい。これを行うために、キャプションテキストを含むウィンドウのｚ軸上の知覚される配置（スクリーン平面の前又は後の指定距離）を定めて効果的な表示を行ってシーン内のオブジェクトへの干渉を避けるための追加情報をキャプションとともに送信することができる。この情報を提供するための技術をいくつか考案することはできるが、これらの多くには欠点がある。

立体３Ｄテレビは、左目用と右目用の別個の表示を、視聴者の目の各々がその目を対象とした画像のみを見るようにする方法と組み合わせてディスプレイ画面に配信するものである。所与のオブジェクトの配置の水平位置で左目と右目の視野が異なる時に、このオブジェクトに関して深度の錯覚が得られる。３次元表示システムに関する基本技術の概要は、英国、Ｄｕｒｈａｍ ＤＨ１ ３ＬＥ、Ｓｏｕｔｈ Ｒｏａｄ、Ｄｕｒｈａｍ大学、科学研究所、コンピュータ科学学科、Ｎｉｃｋ Ｈｏｌｌｉｍａｎ博士による「３Ｄ表示システム（３Ｄ Ｄｉｓｐｌａｙ Ｓｙｓｔｅｍ）」（特に１０〜１１ページ及び図５を参照）に記載されており、この文献はその全体が引用により本明細書に組み入れられる。

本明細書で使用する「視差」という用語は、「網膜歪覚」と区別するものとして、より正式には「画面視差」（すなわち、画面上で測定されるもの）と呼ぶことができ、画面上に表示される一対の位置合わせされた立体画像の右画像及び左画像内の対応点の物理的ｘ座標の差異として定義される。説明を簡単にするために、本明細書では、それほど正式ではない「視差」という用語を使用する。慣例によれば、視差が負の場合（例えば、画面上で左目画像が右目画像の右側に表示される場合）、オブジェクトは、スクリーン平面の前にあるように知覚される。視差が正の場合（例えば、画面上で左目画像が右目画像の左側に表示される場合）、オブジェクトは、スクリーン平面の後にあるように知覚される。

「視差データ」という用語は、キャプションウィンドウ及びその関連テキストなどの所与のグラフィカルオブジェクトを表示する際に使用する視差値を示すあらゆるデータを意味することができる。より一般的には、現在のシーン内のオブジェクトのｚ軸位置を反映するデータを意味するためにこの用語を使用することもできる。シーンエリアを領域内にマッピングして、視聴者に最も近い各領域内のオブジェクトのｚ軸位置をマップ内の座標として記録することができる。このようなマップを、「視差マップ」又は「深度マップ」と呼ぶことができる。視差マップは、フレームごとに変化することができ、多くの方法で表現することができる。なお、視差は、左目画像と右目画像の水平オフセットの尺度であるが、分数の画素オフセットも完全に許容できるので、このオフセットは整数の画素数である必要はない。

表示のための３Ｄビデオ及びＣＣコンテンツの配信という背景では、視差は、付随するビデオの幅のパーセンテージとして一般に表される。従って、これは無次元数である。例えば、シグナリング方式には、視差の１つの単位は（一般に、ディスプレイ画面の幅と一致するように表示される）ビデオコンテンツの幅の１／１９２０に等しいという規定がある。ただし、画面の幅が１９２０であっても、１／１９２０の視差が実際の視差の最小増分というわけではない。この定義によれば、視差７は、ビデオコンテンツの幅の７／１９２０に等しい距離を意味する。やはりこの定義によれば、水平解像度が１９２０画素の画面という特別な事例では、視差の完全な１単位が１表示画素と同じということになるが、これは特別な事例と見なすべきである。ディスプレイ画面の水平画素が、例えば１６００などの、１９２０未満の場合、これに応じて視差がスケール調整され、視差７は（７／１９２０）（１６００）＝５．８３画素に等しくなる。従って、最も正確には、視差は、１対の位置合わせされた立体画像の左目画像と右目画像内の対応点のｘ軸（水平）に沿った、画面上の物理的位置の差異と見なすべきである。一般に、ＣＣウィンドウは、ｚ軸に沿って位置付けられた、ディスプレイスクリーン平面に対して平行な平面内に存在すると知覚される２次元ウィンドウである点にも注目されたい。

本明細書の主題は、３Ｄキャプションサービスをサポートするデータの伝送に関する問題に取り組むものである。レガシーな（既存の、在野の）キャプションデコーダとの下位互換性があることをほぼ保証できる、ＣＥＡ−７０８に準拠する装置のＤＴＶキャプションチャネルでデータを配信する方法が必要である。１つの可能性は、本明細書と同日付で出願され、Ｅｙｅｒに付与された、「クローズドキャプション視差のための拡張コマンドストリーム（ＥＸＴＥＮＤＥＤ ＣＯＭＭＡＮＤ ＳＴＲＥＡＭ ＦＯＲ ＣＬＯＳＥＤ ＣＡＰＴＩＯＮ ＤＩＳＰＡＲＩＴＹ）」という名称の米国特許出願第１３／０２２，８１０号に記載されているような拡張チャネルを使用することであり、この特許出願はその全体が引用により本明細書に組み入れられる。

３Ｄオーディオ／ビデオコンテンツのためのクローズドキャプションデータは、キャプションウィンドウ属性の定義及びテキスト、並びに３Ｄビデオ上に各キャプションウィンドウを表示すべきｚ軸位置（深度）を指定する視差データを含む。コンテンツを作成して配信するシナリオには、同じコンテンツの２Ｄバージョンが異なる経路を通じて受信機に配信される（例えば、ケーブル上の異なるチャンネルでブロードキャストされる）ものもある。この２Ｄバージョンのコンテンツは、視差データを含む同じクローズドキャプションデータを伴うことができる。２Ｄバージョンのコンテンツは、３Ｄ非対応受信機（「レガシー」受信機と呼ぶこともできる）によって処理されるので、キャプションデータを処理する場合には、視差データは適当に無視又はスキップされるべきである。

高度なキャプションのＣＥＡ規格であるＣＥＡ−７０８は、規格を将来的に拡張できるように意図された対策をいくつか含んでいた。これらの拡張の１つを視差データの追加に使用することは、正しい選択のように思えるであろうが、ＣＥＡ−７０８キャプションデコーダの実現は、このデコーダがこれらの拡張のいくつかを処理する方法に関して不十分であることが判明した。ＣＥＡ−７０８規格は、領域によっては不明瞭で又は分かりにくく、実際に実施エラー又は脱落を招く。

キャプションストリーム内に視差データが存在することによってレガシーデコーダが悪影響を受けるであろう可能性を最小限に抑える方法が模索されてきた。本明細書で説明する方法は、標準的キャプションサービスの１つに関連することが分かっている別個のキャプションサービス内で視差データを配信するものである。

ＣＥＡ−７０８高度キャプション規格は、複数の同時キャプションサービスをサポートし、従って、例えば同じ番組に異なる言語のキャプションを提供することができる。ＣＥＡ−７０８は、第９項に「最低限のデコーダ」を定義する。最低限のデコーダは、「標準」サービス番号１〜６を処理する必要がある。「拡張」サービス７〜６３の処理は任意である。この規格を引用すると、「デコーダは、標準サービスヘッダ、拡張サービスブロックヘッダ、及びヌルブロックヘッダから成る全てのキャプションチャネルブロックヘッダを復号できるものとする」とある。

本明細書で説明する視差データ伝送方法は、拡張範囲（７〜６３）のサービス番号で識別されるサービスに３Ｄデータを挿入するものである。視差データを搬送するための標準的方法では、例えばサービス番号６３などの１つの拡張サービスが、標準サービス番号１のための３Ｄ関連データを搬送することを想定することができる。しかしながら、この方法は、（英語とスペイン語のキャプションを同時に提供するような）複数の同時キャプションサービスの例に対処するには不十分と思われる。

拡張サービス６３（又は７〜６２の範囲の他のいずれかのサービス番号）が、１又はそれ以上の標準サービスのための３Ｄデータを搬送できるようなシステムを設計することができる。拡張サービス６３内に、例えば、ある３Ｄデータのブロックを標準サービス（１〜６）の特定の１つに関連付けるためのシグナリングを存在させることができる。このような方法は、可能ではあるが扱いにくく非効率的と思われる。３Ｄデータを伝送するタイミングは、キャプションウィンドウ定義及びテキストを確立するキャプションデータと厳密に一致すべきである。複数の標準サービスのための３Ｄデータを１つの拡張サービス内で伝送する場合、デコーダは、復号していない標準サービスのデータブロックに遭遇し、無駄な努力となる。

本主題は、サービス番号１〜６と６つの拡張サービス番号との間のマッピングを定義することによって上記の制限を克服する。３Ｄ対応受信機が、標準サービス＃１のキャプションを復号する際に、標準サービス＃１にマッピングされる拡張サービスのサービスブロックも処理する。このマッピングされる拡張サービスは、標準サービス＃１に関連する３Ｄデータのみを含み、その他のサービスに関連するデータは含まない。簡単かつ効率的にするために、標準マッピングを使用することができる。本主題のさらなる態様は、３Ｄ視差データを伝送するために使用するデータ構造が、ＣＥＡ−７０８−Ｄ、第７項、１．１１．２で定義されるような「可変長」コマンドと呼ばれるＣＥＡ−７０８の拡張機能を使用する方法に関する。この機能に対応できないレガシー受信機は大量に存在すると考えられるので、このような方法は、標準サービスを背景とした使用には適さないと思われる。このような受信機がこれらの可変長コマンドの１つに遭遇すると、画面上に表示されるキャプション出力が文字化けする恐れがある。しかしながら、拡張サービス番号のサービスブロックで視差データを配信する場合、このことは問題ではない。全ての既存の受信機は、現在復号していないサービス番号に対応するサービスブロック（拡張サービスを含む）をスキップできると考えられる。いずれかのレガシー受信機が視差データの復号を試みた場合（キャプションサービス記述子では、視差データを含むキャプションサービスは通知されないので、通常は行われないはずである）、この受信機は、ＣＥＡ−７０８−Ｄに基づいて構築されていれば、コマンドの内容を単純に無視する。

以上から要約すると、対処すべきいくつかの問題点は以下の通りである。
１．レガシー装置と互換性のある（例えば、２Ｄバージョンのブロードキャストのためのキャプションデータを処理する際に異常な出力を行わない）３Ｄ視差データの配信方法の必要性。
２．「拡張」範囲内（７〜６３）の１つのサービス番号を使用することは有用であるが、完全な解決策ではない。
３．拡張サービス番号で識別されるキャプションサービス内で３Ｄ視差データを送信する場合、完全な２Ｄデータを複製する必要（帯域幅の浪費）、又はこの３Ｄサービスが関連する２Ｄサービスのサービス番号を送信する必要（これも帯域幅の浪費）がある。
４．拡張サービス番号で識別されるサービス内の３Ｄ視差データを、レガシーデコーダによって復号できる可能性がある（このようなデコーダが、ユーザが番号でサービスを選択できるようにしていた場合）。この場合、レガシー装置は、ＣＥＡ−７０８−Ｄに準拠して構築されていれば、正しく復号を行い、３Ｄデータを未サポートのコマンドとして単純に破棄するはずである。

標準化委員会内でこの問題に対処してきた限り、解決策は、３Ｄ視差サービスの数を１つに限定し、レガシー装置が３Ｄデータストリームを認識した場合にこれらの動作を考慮しないことであった。拡張サービス番号を使用する場合、コマンドシンタックスのための方法が必要である。

従って、本発明の実施形態を実現することによる１つの解決策では、複数の３Ｄ視差データサービスを配信する（例えば、３Ｄデータを必要とする複数の同時キャプションサービスをサポートする）能力を提供するために、マッピングスキームを使用する。以下のマッピングテーブル例は、使用できるマッピングの一例である。

この例で番号４９を選択したのは、２進数では、この番号が対応する（例えば、追加コマンドを提供する）サービス番号が、最下位３ビットで示されるからである。このようにして、サービス番号に「ビットマスク」を適用すると、拡張サービス番号は、このサービス番号に都合良く「セルフマッピング」を行う。例えば、（拡張サービス番号）のビットごとに７（２進数で１１１）を論理積演算すると、関連する主要キャプションサービス番号となる。しかしながら、その他のマッピングも同様に選択できるので、この方法を限定的なものと見なすべきではない。例えば、１は５１に、２は５２に関連付けることができ、以下同様である。別の例では、被マップ側拡張サービス番号を、１から５７、２から５８、３から５９、４から６０、５から６１、６から６２のようにマッピングすることができる。別の例では、被マップ側拡張サービス番号に、連続していること、上記の例から選択されること、又は２進数で表した時にいずれかの特定のビット配列を有すること、といった制限がなくてもよい。

レガシーデコーダとの互換性を最適化するために（全てのレガシーデコーダが新規のコマンドを適当に無視できることを完全に保証できるわけではないが）、ＣＥＡ−７０８−Ｄ、第７項、１．１１．２で定義されるような可変長コマンドを使用することができる。このようなコマンドは、「Ｃ３」コマンド（「Ｃ３コードセット−拡張制御コードセット２」）を使用する。正しく実施された場合、レガシーデコーダは、可変長コマンドをスキップし、予測不能な行動をとらないことが保証されるはずである。

従って、レガシーデコーダが視差データを処理しようと試みることに起因して誤動作しないことを保証する助けとするために、視差データに拡張サービス番号を使用する。標準サービス番号１〜６にマッピングされた異なる拡張サービス番号（７〜６３）を使用することにより、複数のキャプションサービスに対応することができる。本明細書の教示に従ってこれを行った場合、サービス番号が拡張サービス番号に自動的にマッピングされるので、データ構造内のサービス番号を明示的に識別する必要はない。レガシーデコーダがこのサービスを行おうと試みるのをさらに防ぐために、可変長コマンドを使用していずれかの好適な方法で視差データを定義することができる。レガシーデコーダの中には、ＣＥＡ−７０８に定義されるような「可変長の拡張をスキップする」機能を正しく実施できないものもあるが、これらの拡張は、（例えば、キャプションの言語を選択するように）ユーザが一般に選択できない非通知サービスなので、とにかく拡張サービス番号を選択する選択肢が視聴者に与えられることは決してない。これらのサービスは、ＡＴＳＣ Ａ／６５のＰｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＰＳＩＰ）で定義されるキャプションサービス記述子（ＣＳＤ）では通知されず、ほとんどの受信機は拡張サービス番号を実施しない（すなわち、これらの受信機は、ＣＥＡ−７０８、第９項の最低要件にしか従わない）。

可変長の視差コマンド例を、図１に１００として示している。ＣＥＡ−７０８−Ｄ、第７項、１．１１．２に規定されるように、可変長コマンドは、後に０ｘ９０〜０ｘ９Ｆの数字が続くＥＸＴ１文字によって示され、この場合の「０ｘ」の表記は、１６進形式で表される数字を示す。図１に示すコマンドフォーマットでは、ＥＸＴ１文字（０ｘ１０）の後に０ｘ９０が続く。この背景では、０ｘ９０は、ＳｅｔＤｉｓｐａｒｉｔｙコマンドのコマンド識別子である。ＣＥＡ−７０８−Ｄ、第７項、１．１１．２に定義されるシンタックスによれば、次のバイトは２ビットのＴｙｐｅフィールドを含み、０ビット、そして５ビットの長さフィールドが続く。

長さフィールドを含むバイトの後に、ｃａｐｔｉｏｎ＿ｄｉｓｐａｒｉｔｙ＿ｄａｔａ（）のデータ構造が続く。以下の表１に、キャプション視差データの一例のシンタックスを疑似コードで示す。

表１−キャプション視差データシンタックス例

表１では、「ｂｓｌｂｆ」が、「ビットシリアル、左端ビットが最初」を意味し、「ｕｉｍｓｂｆ」が、「符号なし整数、最上位ビットが最初」を意味し、「ｓｉｍｓｂｆ」が、「符号付き整数、最上位ビットが最初」を意味する。「ｒｅｓｅｒｖｅｄ」と表記されたフィールドは今のところ未定義であるが、受信機は、将来的な規格の発表でこれらのフィールドが定義される時までこれらのフィールドを無視する。

この例示的な表１は、例えば、本出願と同日付けで出願された、Ｅｙｅｒ他に付与された、「視差データ伝送及びシグナリンク（Ｄｉｓｐａｒｉｔｙ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ ａｎｄ Ｓｉｇｎａｌｉｎｇ）」という名称の米国特許出願第＿＿＿＿＿＿＿号に記載されており、この特許出願はその全体が引用により本明細書に組み入れられる。この方法では、上記出願に記載されるように、各線分の傾斜及びこの傾斜が当てはまるフレーム数を使用して視差を定義する。この技術による折れ線近似の例を、図２に２００として示しており、最初の傾斜を０と仮定して、一連の線分を（フレーム、傾斜変化）＝（２，＋７），（１０，＋９），（８，−７），（１０，−９）によって表している。しかしながら、この機構を利用して、他のあらゆる好適な視差表現を望む通りに実現することもできる。

この例示的な表１で上述した変数は、（限定ではなく一例として）以下の意味を有し、提示する定義は、ＣＥＡ−７０８高度キャプション規格の更新などの技術規格での使用に適した形式である。
・ｃａｐｔｉｏｎ＿ｗｉｎｄｏｗ＿ｃｏｕｎｔ：このｃａｐｔｉｏｎ＿ｄｉｓｐａｒｉｔｙ＿ｄａｔａ（）のインスタンスに含まれるキャプションウィンドウの数を示す３ビットの符号なし整数。
・ｃａｐｔｉｏｎ＿ｗｉｎｄｏｗ＿ｉｄ：この「ｆｏｒ」ループの繰り返しにおいて視差データが与えられる対応するサービス内のウィンドウＩＤを識別する３ビットの符号なし整数。
・ｔｅｍｐｏｒａｌ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ：「１」に設定した場合、時変視差パスを識別するデータが含まれることを示す１ビットのフラグ。
・ｄｉｓｐａｒｉｔｙ［ｉ］：１９２０の水平画素に対する関連するキャプションウィンドウの視差値を示す９ビットの符号付き整数。値０はスクリーン平面（視差なし）を示す。負の値は、画面の面の知覚深度に対応し、正の値は画面の後の知覚深度に対応する。
・ａｌｔｅｒｎａｔｅ＿ｄｉｓｐａｒｉｔｙ［ｉ］：ｄｉｓｐａｒｉｔｙ［ｉ］と同様に符号化される９ビットの符号付き整数。時変キャプションウィンドウを表示できないデコーダが折れ線経路で与えられる値の代わりに使用できる視差値を与える。
・ｓｅｇｍｅｎｔ＿ｃｏｕｎｔ：後続のセグメント数を示す１〜３１の範囲の５ビットの符号なし整数。
・ｆｒａｍｅ＿ｃｏｕｎｔ：後続のｓｅｇｍｅｎｔ＿ｓｌｏｐｅ＿ｃｈａｎｇｅを適用する前に待機すべきビデオフレーム数を示す０〜３１の範囲の５ビットの符号なし整数。
・ｓｅｇｍｅｎｔ＿ｓｌｏｐｅ＿ｃｈａｎｇｅ：ｆｒａｍｅ＿ｃｏｕｎｔで示されるフレームで適用する傾斜の変化量を示す−１６〜＋１５の範囲の５ビットの２の補数符号付き整数。傾斜は、３２個のフレームにわたる視差の画素数で指定される。

ここで図３を参照すると、放送局などのサービスプロバイダの基本図を示している。一般的に言えば、１つのサービスプロバイダは、１又はそれ以上のトランスポートストリームを介して複数の番組を提供することができる。エンコーダにオーディオ、ビデオ、及びキャプションデータが提供され、このエンコーダが、これらのデータを、上述したようなキャプションデータパケットを含む配信に適したパケットに符号化する。図示のように、エンコーダ４０２及び４０４によって番組Ａ及び番組Ｂが符号化され、次にこれらがトランスポートストリームマルチプレクサ４１０に提供され、次にこのマルチプレクサが、ケーブル又は衛星放送などの物理チャネル媒体を介して配信できる出力を提供する。

図４に示すように、この物理チャネルからの符号化データが、テレビ受信機装置（テレビ又はセットトップボックスなど）で受け取られる。このトランスポートストリームが、トランスポートストリームデマルチプレクサ５０４で逆多重化されて、オーディオ、ビデオ、及びキャプションデータ（並びに、場合によっては図示していないその他のデータ）を含む１又はそれ以上の番組ストリームが生成される。番組Ａからのビデオパケットは、デマルチプレクサ５０４からビデオパーサ５０８に転送される。番組Ａからのオーディオパケットは、デマルチプレクサ５０４からオーディオデコーダ５１２に転送され、このオーディオデコーダ５１２がオーディオ出力を生成する。ビデオパーサ５０８は、ビデオストリームからビデオパケットを抽出し、これらをビデオデコーダ５１４に転送する。ビデオパーサ５０８は、ビデオストリームからユーザデータを抽出し、これをユーザデータパーサ５１０に転送する。ユーザデータパーサ５１０は、ユーザデータパケット内からクローズドキャプションデータを抽出し、これをキャプションプロセッサ５１６に転送する。キャプションプロセッサ５１６内では、関心のあるキャプションサービス以外のキャプションサービス用データを含むキャプションサービスブロックをフィルタ除去して破棄する。ビデオコンテンツが３Ｄの場合、キャプションプロセッサ５１６は、関心のある主要サービスに対応するキャプションサービスブロックを処理すると同時に、被マップ側拡張サービスに対応するキャプションサービスブロックを処理する。キャプションプロセッサ５１６の出力は、クローズドキャプションのグラフィカル表現であり、通常はキャプションウィンドウに入れられたテキストである。３Ｄコンテンツでは、キャプションプロセッサ５１６の出力は、各キャプションウィンドウの知覚深度（ｚ平面位置）を確立するために適当な視差が適用された、左目視野及び右目視野のための別個のキャプション出力である。

キャプションデータパケット内のデータに基づいてｘ、ｙ、及びｚ平面内にキャプションを配置した３Ｄビデオを生成するために、合成器５２０においてキャプショングラフィックスがビデオデータと合成される。このようなデータは、キャプションをｚ軸内に静的に、又はキャプションデータの作成に基づいて動的に配置することができる。

図５に、受信機装置をより詳細に示しており、ここでは地上波放送、ケーブル、又は衛星などのあらゆる適当な発信源を介して、受信機６００のチューナ／復調器６０２においてコンテンツが受け取られる。チューナ／復調器６０２からのトランスポートストリームは、デマルチプレクサ６０６においてオーディオ及びビデオストリームに逆多重化される。オーディオデコーダ６１０においてオーディオが復号され、ビデオデコーダ６１４においてビデオが復号される。選択的に利用できる非圧縮Ａ／Ｖインターフェイス６１８を介して、非圧縮Ａ／Ｖデータを受け取ることもできる。

ＩＰテレビコンテンツを復号するために、ネットワークインターフェイス６２６を介してインターネット６２２経由でＡ／Ｖコンテンツを受け取ることもできる。また、非リアルタイム（ＮＲＴ）で保存されるコンテンツのためのストレージ６３０を提供することもできる。このＮＲＴコンテンツは、６０６において、他のコンテンツソースと同様の方法で逆多重化することにより再生することができる。一般に、受信機は、ワーキングメモリ６４０及びプログラムメモリ６４２に相互接続されるとともに６５０などの１又はそれ以上のバスを介してグラフィックサブシステム６４４に相互接続されたＣＰＵ６３８などのプロセッサの制御下で動作する。

ＣＰＵ６３８は、デマルチプレクサ６０６からクローズドキャプションデータを受け取るとともに、本明細書で説明した機構を介して視差データを受け取り、拡張サービス内のデータを解析することによって、いずれのｚ位置、並びにｘ及びｙ位置にキャプションデータを位置付けるかを決定する。この情報が、グラフィックサブシステム６４４に転送され、合成器６６０において画像が合成されて、処理及びビデオディスプレイ上の表示に適した出力が生成される。

図６に、本明細書で説明した方法で供給されるキャプションデータを処理するために使用するプログラムモジュールの１つの実施構成を示す。この例示的な実施構成では、プログラムメモリ６４２からのプログラム制御により動作してワーキングメモリ６４０を使用するＣＰＵ６３８が、逆多重化したトランスポートストリームをデマルチプレクサ６０６から受け取り、パーサモジュール７０４が、７０８においてキャプションデータ（すなわち、キャプションテキスト）を生成し、提示されたサービス番号で参照されるサービスが、拡張サービスマップテーブル７１４内でマッピングされた拡張サービスに対応することを拡張サービス処理モジュール７１２から判断し、グラフィックサブシステム６４４が処理に使用する拡張サービスのサービスデータブロックから視差データが抽出される。パーサ７０４は、７０６によって示すその他のデータ処理モジュールに対してその他データを解析することもできる。次に、この処理されたキャプションデータが、合成器６６０においてデマルチプレクサ６０６からのビデオデータと合成されて、ＣＣデータの位置がｚ軸内に指定通りに配置された表示用データが生成される。

従って、クローズドキャプションの視差データを処理するテレビ受信機装置は、１〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータを受け取る受信機を有する。６３８などの１又はそれ以上のプロセッサが、このサービス番号を、非通知サービスである対応する被マップ側拡張サービスにマッピングする。７０４などのパーサ処理が、被マップ側拡張サービス内に現れるクローズドキャプションデータから視差データを解析する。このパーサは、トランスポートストリームからクローズドキャプションテキストデータをさらに受け取る。６６０などの合成器が、視差データ及びキャプションテキストを受け取って処理し、キャプションテキストの表示上の視差データにより定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成する。

いくつかの実施構成では、拡張サービスが、７〜６３のサービス番号に対応する。いくつかの実施構成では、視差データが、ＣＥＡ−７０８に準拠する可変長コマンドで搬送される。いくつかの実施構成では、被マップ側拡張サービス番号が、１から４９、２から５０、３から５１、４から５２、５から５３、及び６から５４のようにマッピングされ、他の実施構成では、被マップ側拡張サービス番号が、１から５７、２から５８、３から５９、４から６０、５から６１、及び６から６２のようにマッピングされる。いくつかの実施構成では、被マップ側拡張サービス番号が、２進数で表した場合、拡張サービス番号の最下位３ビットによって関連サービス番号を一意に識別する。

本発明の実施構成例による全体的な処理を図７のフローチャート８００に示しており、この処理は８０２から開始する。８０４においてキャプションが有効になった場合、サービス番号１〜６のいずれかにキャプションデータが存在する旨を示すデータを受け取る。８１０において、選択したサービス番号を、７〜６３の範囲の拡張サービス番号にマッピングする。８１４において、クローズドキャプションテキストを受け取り、８１８において、クローズドキャプション視差データを受け取る。これらのイベントは、テキスト及びキャプションデータが継続的に受け取られる連続フローであり、従ってこの表現を正確に時間を示すものであると解釈すべきではないことが理解されよう。８２２において視差データを処理して、クローズドキャプションテキスト及びこのテキストを含むクローズドキャプションウィンドウのｚ軸位置を決定し、次にこのデータを出力して合成表示データを生成する。この処理は、８２６において視差データ及びキャプションデータが終了するまでクローズドキャプションテキスト及び視差データを受け取り続け、８３０において戻る。８２６において、さらなるキャプションが利用可能な場合、処理は８０４へ進み、依然としてキャプションが有効であれば繰り返す。８０４においてキャプションが無効になった場合、処理は８３０において戻る。

従って、３次元ビデオのためのクローズドキャプションの視差データを処理する方法は、１〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータを受け取るステップと、８１０のように、このサービス番号を、非通知サービスである７〜６３のサービス番号を有する対応する被マップ側拡張サービスにマッピングするステップとを含む。被マップ側拡張サービス内に現れるクローズドキャプションデータから視差データを解析する。次に、この処理は、クローズドキャプションテキストデータを受け取り、キャプションテキスト及び視差データを処理して、キャプションテキストの表示上の、ＣＥＡ−７０８に準拠する可変長コマンドで搬送された視差データにより定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成する。

いくつかの実施構成では、３次元ビデオのためのクローズドキャプションの視差データを処理する方法が、１〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータを受け取るステップと、このサービス番号を、７〜６３のサービス番号を有する対応する被マップ側拡張サービスにマッピングするステップと、この被マップ側拡張サービス内に現れるクローズドキャプションデータから視差データを解析するステップと、クローズドキャプションテキストデータを受け取るステップと、キャプションテキスト及び視差データを処理し、キャプションテキストの表示上の、視差データによって定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成するステップとを含む。

当業者であれば、本教示を検討した時に多くの変形例が浮かぶであろう。例えば、いくつかの実施構成では、レガシー受信機がより高い番号の拡張サービスに対して動作するのをさらに防ぐために、視差データが、ＣＥＡ−７０８に準拠する可変長コマンドで搬送される。いくつかの実施構成では、被マップ側拡張サービス番号が、１から４９、２から５０、３から５１、４から５２、５から５３、及び６から５４のようにマッピングされ、他の実施構成では、被マップ側拡張サービス番号が、１から５７、２から５８、３から５９、４から６０、５から６１、及び６から６２のようにマッピングされる。いくつかの実施構成では、被マップ側拡張サービス番号が、２進数で表した場合、拡張サービス番号の最下位３ビットによって関連サービス番号を一意に識別する。

３次元ビデオのためのクローズドキャプションの視差データを処理する別の方法例は、１〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータを受け取るステップと、このサービス番号を、非通知サービスである対応する被マップ側拡張サービスにマッピングするステップと、被マップ側拡張サービス内に現れるクローズドキャプションデータから視差データを解析するステップと、クローズドキャプションテキストデータを受け取るステップと、キャプションテキスト及び視差データを処理し、キャプションテキストの表示上の、視差データによって定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成するステップとを含む。

いくつかの実施構成では、拡張サービスが、７〜６３のサービス番号に対応する。いくつかの実施構成では、視差データが、ＣＥＡ−７０８に準拠する可変長コマンドで搬送される。いくつかの実施構成では、被マップ側拡張サービス番号が、１から４９、２から５０、３から５１、４から５２、５から５３、及び６から５４のようにマッピングされ、他の実施構成では、１から５７、２から５８、３から５９、４から６０、５から６１、及び６から６２などの他のマッピングを使用することができる。いくつかの実施構成では、被マップ側拡張サービス番号が、２進数で表した場合、拡張サービス番号の最下位３ビットによって関連サービス番号を一意に識別する。

当業者であれば、１又はそれ以上のプログラムされたプロセッサ上で実行された時に方法を実行する命令を記憶する非一時的記憶媒体を含む１又はそれ以上のコンピュータ可読記憶媒体を使用することにより、上述の処理を実施できると理解するであろう。

なお、視差データは、連続ストリームとして配信することができ、或いは予め配信しておくこともできる。

当業者であれば、上記の教示を検討した時に、上記の例示的な実施形態のいくつかが、プログラムされたプロセッサの使用に基づくものであると認識するであろう。しかしながら、特殊用途向けハードウェア及び／又は専用プロセッサなどのハードウェアコンポーネントの同等物を使用して他の実施形態を実施することもできるので、本発明はこのような例示的な実施形態に限定されるものではない。同様に、汎用コンピュータ、マイクロプロセッサベースのコンピュータ、マイクロコントローラ、光学コンピュータ、アナログコンピュータ、専用プロセッサ、特定用途向け回路及び／又は専用配線論理を使用して、別の同等の実施形態を構成することもできる。

当業者であれば、上記の教示を検討した時に、本発明の特定の実施形態から逸脱することなく、ディスク型記憶装置、並びに、例えば、リードオンリメモリ（ＲＯＭ）装置、ランダムアクセスメモリ（ＲＡＭ）装置、ネットワークメモリ装置、光学記憶装置、磁気記憶装置、光磁気記憶装置、フラッシュメモリ、コアメモリ及び／又はその他の同等の揮発性及び不揮発性記憶装置技術などを含む非一時的記憶装置のような他の形の記憶装置を使用して、上述した実施形態のいくつかを実現するために使用されるプログラム動作及び処理及び関連データを実現できると理解するであろう。非一時的という用語は、電力の停止又はその他の動作によって情報が失われないことを示唆するものではない。このような代替の記憶装置も同等物と見なすべきである。

本明細書で説明したいくつかの実施形態は、いずれかの適当な電子憶媒又はコンピュータ可読記憶媒体上に記憶できる、フロー図の形で広義に上述したプログラミング命令を実行するプログラムされたプロセッサを使用して実施され又は実施することができる。しかしながら、当業者であれば、本教示を検討した時に、本発明の実施形態から逸脱することなく上述の処理をあらゆる数の変形形態で、及び多くの好適なプログラム言語で実施できることを理解するであろう。例えば、多くの場合、本発明のいくつかの実施形態から逸脱することなく、実施されるいくつかの動作の順序を変更することができ、さらなる動作を追加することができ、或いは動作を削除することもできる。本発明のいくつかの実施形態から逸脱することなく、エラートラップを追加及び／又は強化することができ、動作フロー、ユーザインターフェイス及び情報提示の変形例を作成することもできる。このような変形例は想定されており、同等物と見なされる。

いくつかの例示的な実施形態について説明したが、当業者には、上述の説明に照らして多くの代替、修正、置換、及び変形が明らかになることが明白である。

６０６ デマルチプレクサ
６３８ ＣＰＵ
６４４ グラフィックサブシステム
６６０ 合成器
７０４ パーサ
７０６ その他のデータ処理
７０８ ＣＣデータ
７１２ 拡張サービス処理
７１４ 拡張サービスマップ

Claims (9)

1. ３次元ビデオのためのクローズドキャプションの視差データを処理する方法であって、 トランスポートストリームから１〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータを受け取るステップと、
   前記サービス番号を、非通知サービスである７〜６３のサービス番号を有する対応する被マップ側拡張サービスにマッピングするステップと、
   前記被マップ側拡張サービス内に現れる前記クローズドキャプションデータから前記視差データを解析するステップと、
   前記トランスポートストリームからクローズドキャプションテキストデータを受け取るステップと、
   前記キャプションテキスト及び視差データを処理し、前記キャプションテキストの表示上の、ＣＥＡ−７０８に準拠する可変長コマンドで搬送された前記視差データにより定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成するステップと、
   を含むことを特徴とする方法。
2. 前記被マップ側拡張サービス番号が、１から４９、２から５０、３から５１、４から５２、５から５３及び６から５４のようにマッピングされる、
   ことを特徴とする請求項１に記載の方法。
3. 前記被マップ側拡張サービス番号が、１から５７、２から５８、３から５９、４から６０、５から６１及び６から６２のようにマッピングされる、
   ことを特徴とする請求項１に記載の方法。
4. 前記被マップ側拡張サービス番号が、２進数で表した場合、関連するサービス番号を前記拡張サービス番号の最下位３ビットによって一意に識別する、
   ことを特徴とする請求項１に記載の方法。
5. １又はそれ以上のプログラムされたプロセッサ上で実行された時に請求項１に記載の方法を実行する命令を記憶する、
   ことを特徴とするコンピュータ可読記憶媒体。
6. クローズドキャプションの視差データを処理するテレビ受信機装置であって、
   １〜６のサービス番号を有するサービスブロック内にクローズドキャプションテキストを含むクローズドキャプションデータをトランスポートストリームから受け取る受信機と、
   前記サービス番号を、非通知サービスである７〜６３のサービス番号を有する対応する被マップ側拡張サービスにマッピングする１又はそれ以上のプロセッサと、
   前記被マップ側拡張サービス内に現れる前記クローズドキャプションデータから前記視差データを解析し、さらに前記トランスポートストリームからクローズドキャプションテキストデータを生成するパーサと、
   前記視差データ及び前記キャプションテキストを受け取って処理し、前記キャプションテキストの表示上の、ＣＥＡ−７０８に準拠する可変長コマンドで搬送された前記視差データにより定義されるｚ軸位置に３次元画像の表示を定義するのに適した出力を生成する合成器と、
   を備えることを特徴とする装置。
7. 前記被マップ側拡張サービス番号が、１から４９、２から５０、３から５１、４から５２、５から５３及び６から５４のようにマッピングされる、
   ことを特徴とする請求項６に記載の装置。
8. 前記被マップ側拡張サービス番号が、１から５７、２から５８、３から５９、４から６０、５から６１及び６から６２のようにマッピングされる、
   ことを特徴とする請求項６に記載の装置。
9. 前記被マップ側拡張サービス番号が、２進数で表した場合、関連するサービス番号を前記拡張サービス番号の最下位３ビットによって一意に識別する、
   ことを特徴とする請求項６に記載の装置。

Images