特許 6236148 ＨＤＭＩを介したディスプレイマネジメントメタデータの送信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6236148

(24)【登録日】2017年11月2日

(45)【発行日】2017年11月22日

(54)【発明の名称】ＨＤＭＩを介したディスプレイマネジメントメタデータの送信

(51)【国際特許分類】

   H04N 21/436 20110101AFI20171113BHJP

   H04N 21/84 20110101ALI20171113BHJP

【ＦＩ】

   H04N21/436

   H04N21/84

【請求項の数】24

【全頁数】44

(21)【出願番号】特願2016-519873(P2016-519873)

(86)(22)【出願日】2014年9月30日

(65)【公表番号】特表2016-538748(P2016-538748A)

(43)【公表日】2016年12月8日

(86)【国際出願番号】US2014058260

(87)【国際公開番号】WO2015050857

(87)【国際公開日】20150409

【審査請求日】2016年5月31日

(31)【優先権主張番号】61/886,026

(32)【優先日】2013年10月2日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507236292

【氏名又は名称】ドルビー ラボラトリーズ ライセンシング コーポレイション

(74)【代理人】

【識別番号】100101683

【弁理士】

【氏名又は名称】奥田 誠司

(74)【代理人】

【識別番号】100155000

【弁理士】

【氏名又は名称】喜多 修市

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部 英隆

(74)【代理人】

【識別番号】100188813

【弁理士】

【氏名又は名称】川喜田 徹

(74)【代理人】

【識別番号】100202197

【弁理士】

【氏名又は名称】村瀬 成康

(72)【発明者】

【氏名】キュ，シェン

(72)【発明者】

【氏名】ヒュルヤルカール，サミール エヌ．

【審査官】 福西 章人

(56)【参考文献】

【文献】 特表２００５−５１４８７３（ＪＰ，Ａ）

【文献】 特表２００９−５３０９７７（ＪＰ，Ａ）

【文献】 特表２００９−５２１８４０（ＪＰ，Ａ）

【文献】 特表２００７−５３７６２０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１８４９７５（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００−２１／８５８

Ｈ０４Ｎ ５／３８−５／４６

Ｈ０４Ｎ ５／７６−５／９５６

(57)【特許請求の範囲】

【請求項1】

ビデオ信号通信路を介して、ビデオ信号をビデオソースシステムからビデオシンクシステムへ送信する方法であって、以下を包含する、方法：
前記ビデオソースシステムは（ａ）基準コード値および（ｂ）１つ以上のマッピング関数のための複数のマッピング関数パラメータを含むソースビデオ信号を受け取り、ここで前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数は前記基準コード値を装置固有の画素値にマッピングし、
前記ビデオソースシステムは（ａ）前記基準コード値の１つ以上の部分および（ｂ）前記複数のマッピング関数パラメータを、第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成し、ここで前記複数のマッピング関数パラメータは、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームに保持されたディスプレイマネジメント（ＤＭ）メタデータの少なくとも一部を表しており、
前記ビデオ信号通信路が、前記第１のビデオ信号フォーマットの前記ビデオ信号の移動をサポートしていることとサポートしていないことにそれぞれ対応して用いられる、第１のモードおよび第２のモードのいずれの送信モードを使用中であるかを、前記ビデオソースシステムは前記ビデオシンクシステムに合図し、
もし前記ビデオ信号通信路が、前記第１のビデオ信号フォーマットのビデオ信号の移動をサポートしていなければ、
第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオ信号フォーマットとの間のマッピングに基づき生成し、
前記ビデオソースシステムは、前記第２のビデオ信号フォーマットの符号化ビデオ信号として、前記１つ以上の第２のビデオフレームを前記ビデオ信号通信路を介して前記ビデオシンクシステムに送り、
もし前記ビデオ信号通信路が前記第１のビデオ信号フォーマットのビデオ信号の移動をサポートしていれば、
前記ビデオソースシステムは、前記１つ以上の第１のビデオフレームを、前記第１のビデオ信号フォーマットの符号化ビデオ信号として、前記ビデオ信号通信路を介して前記ビデオシンクシステムに送る。

【請求項2】

前記第１のビデオ信号フォーマットはＹＣｂＣｒフォーマットを表し、前記第２のビデオ信号フォーマットはＲＧＢフォーマットを表す、請求項１に記載の方法。

【請求項3】

メタデータ情報フレームを、前記第１のビデオ信号フォーマットである元々の（ｕｎｄｅｒｌｙｉｎｇ）ビデオ信号が前記第２のビデオ信号フォーマットの前記符号化ビデオ信号中に保持されていることを示すデータとともに送信することをさらに包含する、請求項１に記載の方法。

【請求項4】

前記１つ以上の第１のビデオフレーム中の前記ＤＭメタデータの１つ以上の部分のビット値にわたって１つ以上の巡回冗長検査（ＣＲＣ）値を算出し、
前記１つ以上の第１のビデオフレーム中の前記１つ以上のＣＲＣ値とともに、前記ＤＭメタデータを送信すること、
をさらに包含する、請求項１に記載の方法。

【請求項5】

前記ビデオシンクシステムが前記１つ以上のマッピング関数に関連するマッピング動作を実行することが可能であることを決定することをさらに包含する、請求項１に記載の方法。

【請求項6】

前記ビデオ信号通信路は、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）リンクＶ−ｂｙ−Ｏｎｅ−ＨＳ（Ｖｘ１）リンク、Ｌｏｗ−Ｖｏｌｔａｇｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｓｉｇｎａｌｉｎｇ（ＬＶＤＳ）リンク、またはＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ（ＨＤ−ＳＤＩ）リンクのうち１つである、請求項１に記載の方法。

【請求項7】

前記複数のマッピング関数パラメータは、前記１つ以上の第１のビデオフレームの複数の最下位ビットフィールドに格納される、請求項１に記載の方法。

【請求項8】

前記１つ以上の第１のビデオフレームは１シーンを形成する、請求項１に記載の方法。

【請求項9】

前記複数のマッピング関数パラメータのうち１つ以上のマッピング関数パラメータが、前記１つ以上の第１のビデオフレームにおいて繰り返される、請求項１に記載の方法。

【請求項10】

前記１つ以上のビデオフレームのうち１つのビデオフレームは、前記１つ以上のマッピング関数に関連するマッピング動作を同じ前記ビデオフレームに対して行うために用いられる、前記複数のマッピング関数パラメータを保持する、請求項１に記載の方法。

【請求項11】

前記１つ以上の第１のビデオフレームのうちの１つの第１のビデオフレームは、前記複数のマッピング関数パラメータを保持せず、前記第１のビデオフレームは、以前に受け取った前記複数のマッピング関数パラメータが、前記１つ以上のマッピング関数に関連するマッピング動作を同じ第１のビデオフレームに行うために用いられるべきであることを示すフラグを表す値を含む、請求項１に記載の方法。

【請求項12】

前記１つ以上のマッピング関数に関連するマッピング動作は、トーンマッピング動作または色域マッピング動作のうち１つ以上を包含する、請求項１に記載の方法。

【請求項13】

前記１つ以上の第１のビデオフレームにおける、前記複数のマッピング関数パラメータを格納する複数のビットフィールドは、スクランブルされている、請求項１に記載の方法。

【請求項14】

前記１つ以上の第１のビデオフレームは、前記マッピング以外のディスプレイマネジメ
ント動作のための、１つ以上のパラメータをさらに保持している、請求項１に記載の方法。

【請求項15】

ビデオ信号通信路を介して、ビデオ信号をビデオソースシステムからビデオシンクシステムによって受信する方法であって、以下を包含する、方法：
前記ビデオ信号通信路が、第１のビデオ信号フォーマットのビデオ信号の移動をサポートしていることとサポートしていないことにそれぞれ対応して用いられる、第１のモードおよび第２のモードのいずれの送信モードを使用中であるかの合図を、前記ビデオシンクシステムが前記ビデオソースシステムより受け取り、
前記ビデオ信号通信路を介して、前記ビデオシンクシステムは前記ビデオソースシステムから符号化ビデオ信号を受け取り、
前記第２のモードを使用中であるとの合図を受け取ったとき、
前記符号化ビデオ信号から、第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを抽出し、
前記第１のビデオ信号フォーマットと前記第２のビデオ信号フォーマットとの間のマッピングに基づき、前記１つ以上の第２のビデオフレームから、前記第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームを抽出し、
前記１つ以上の第１のビデオフレームから、基準コード値の１つ以上の部分および複数のマッピング関数パラメータを抽出し、
前記第１のモードを使用中であるとの合図を受け取ったとき、
前記符号化ビデオ信号から、前記第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームを抽出し、
前記１つ以上の第１のビデオフレームに基づき、基準コード値の１つ以上の部分および複数のマッピング関数パラメータを抽出し、
前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数を適用することにより、前記基準コード値の１つ以上の部分を、マッピング後の装置固有の画素値にマッピングする。

【請求項16】

メタデータ情報フレームを、前記第１のビデオ信号フォーマットである元々のビデオ信号が前記第２のビデオ信号フォーマットの前記符号化ビデオ信号中に保持されていることを示すデータとともに受け取ることをさらに包含する、請求項１５に記載の方法。

【請求項17】

前記基準コード値の１つ以上の部分および複数のマッピング関数パラメータに基づいて構築された１つ以上の画像を描画することをさらに包含する、請求項１５に記載の方法。

【請求項18】

前記ビデオシンクシステムによって、前記第１のビデオ信号フォーマットである前記１つ以上のビデオフレームから、特定のデータ部分を抽出し、
前記ビデオシンクシステムによって、前記特定の抽出されたデータ部分に対して、巡回冗長検査（ＣＲＣ）検査を行い、
前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数を適用することにより、前記基準コード値の１つ以上の部分をマッピング後の画素値にマッピングすることは、前記特定の抽出されたデータ部分に対するＣＲＣテストが合格したときにのみ行われる、
ことをさらに包含する、請求項１５に記載の方法。

【請求項19】

前記１つ以上の第１のビデオフレームから、ソースデバイスにより算出された１つ以上の巡回冗長検査（ＣＲＣ）値を抽出し、
前記１つ以上の第１のビデオフレームの１つ以上の特定の部分のビット値にわたって、１つ以上のＣＲＣ値を算出し、
前記１つ以上のＣＲＣ値を、前記ソースデバイスにより算出された１つ以上のＣＲＣ値に対し比較する、
ことをさらに包含する、請求項１８に記載の方法。

【請求項20】

前記符号化ビデオ信号から抽出された特定のデータ部分に対する前記ＣＲＣテストがある明示された回数不合格であると、前記ビデオシンクシステムを、基準コード値から装置固有の画素値へのマッピングを前記ビデオシンクシステムが行わない第２の特定の動作モードに設定することをさらに包含する、請求項１８に記載の方法。

【請求項21】

前記ビデオシンクシステムは、メタデータ情報フレームを、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータを前記符号化ビデオ信号が含んでいることを示すデータとともに、受け取らないようにされる、請求項１８に記載の方法。

【請求項22】

前記符号化ビデオ信号は第１のビデオ信号フォーマットであり、かつ基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータが符号化された、前記第１のビデオ信号フォーマットのビデオフレームを含む、請求項１８に記載の方法。

【請求項23】

前記符号化ビデオ信号はあるビデオ信号フォーマットのビデオフレームを含み、前記ビデオ信号フォーマットのビデオフレームに、前記ビデオ信号フォーマットと異なる前記第１のビデオ信号フォーマットの第１のビデオフレームがマッピングされ、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータが、前記第１のビデオフレーム中に符号化される、請求項１８に記載の方法。

【請求項24】

前記ビデオソースシステムが、前記第１のビデオ信号フォーマットで特定の画像パターンを格納し、
複数の基準コード値および前記複数のマッピング関数パラメータを、前記第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成し、ここで前記複数の基準コード値は前記特定の画像パターンを表しており、
前記第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオ信号フォーマットとの間のマッピングに基づいて生成し、
前記１つ以上の第２のビデオフレームを、前記ビデオ信号通信路を介して前記ビデオシンクシステムに送り、
色歪みの無い前記特定の画像パターンが前記ビデオシンクシステムによって表示されていることを示すユーザー入力を受け取ると、前記（ａ）前記基準コード値の１つ以上の部分および（ｂ）前記複数のマッピング関数パラメータを、前記第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成することを前記ビデオソースシステムが行う特定の動作モードに、前記ビデオソースシステムを設定する、
ことをさらに包含する、請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１３年１０月２日付け出願の米国仮特許出願Ｎｏ．６１／８８６，０２６に基づく優先権を主張するものであり、この出願の開示内容の全てを本願に援用する。

【0002】

本発明は、メディア処理システム全般に関し、より具体的には、映像リンクを介してディスプレイマネジメントメタデータを送信することに関する。

【背景技術】

【0003】

技術の進歩により、ディスプレイシステムは映像ソースコンテンツの描画を、大きく改善した画質特性で行うことが可能になっている。例えば、比較的最近のディスプレイの中には、スタンダードダイナミックレンジ（ＳＤＲ）よりも高い、あるいはかなり高いダイナミックレンジで、コンテンツを描画することが可能なものもある。

【0004】

逆に、ハイダイナミックレンジ（ＨＤＲ）よりもかなり狭いダイナミックレンジを持つディスプレイもある。携帯機器、タブレット型コンピュータ、ゲーム機器、ローエンドのテレビ、およびコンピュータ用モニタは、ダイナミックレンジや色域や解像度について、映像描画能力が制限され得る。

【発明の概要】

【発明が解決しようとする課題】

【0005】

ＨＤＲカメラによって撮影されたソース画像は、すべてとは言わないが大抵のディスプレイ装置のダイナミックレンジよりも、かなり大きなシーン−リファードダイナミックレンジを有し得る。シーン−リファードのＨＤＲ画像は大量のデータを含んでいることがあり、送信および格納を容易にするために、ポストプロダクションフォーマット（例えばＨＤＭＩビデオ信号など）に変換され得る。描画のために画像がエンドユーザーのディスプレイ装置に送られるとき、その装置固有および／またはそのメーカー固有の画像変換が途中で起こり、描画された画像中において、元のシーン−リファード画像と比較し大量の視覚的に気付き得るエラーや劣化を引き起こす。

【0006】

本節に記載されているアプローチは、探求し得るアプローチではあるが、必ずしもこれまでに着想または探求されてきたアプローチではない。従って、特に反対の記載がない限り、本節に記載されたアプローチのいずれも、本節に記載されているという理由だけで従来技術としての適格性を有すると考えるべきではない。同様に、特に反対の記載がない限り、本節に基づいて、１以上のアプローチに関して特定される問題が、いずれかの先行技術において認識されたことがあると考えるべきではない。

【図面の簡単な説明】

【0007】

【図1】図１は、メディアソースシステムを示す。

【図2】図２は、メディアシンクシステムを示す。

【図3A】図３Ａは、メディアソースシステムおよびメディアシンクシステム間でディスプレイマネジメントメタデータを伝えるための、アルゴリズムまたは処理フロー例を示す。

【図3B】図３Ｂは、メディアソースシステムおよびメディアシンクシステム間でディスプレイマネジメントメタデータを伝えるための、アルゴリズムまたは処理フロー例を示す。

【図4A】図４Ａは、処理フロー例を示す。

【図4B】図４Ｂは、処理フロー例を示す。

【図5】図５は、本明細書に記載のコンピュータまたはコンピューティングデバイスが実装され得る、ハードウェアプラットフォーム例を示す。

【図6A】図６Ａは、メディアソースシステムおよびメディアシンクシステム間の、システム構成例を示す。

【図6B】図６Ｂは、メディアソースシステムおよびメディアシンクシステム間の、システム構成例を示す。

【図7】図７は、ビデオ信号フォーマット例を示す。

【図8A】図８Ａは、追加的な処理フロー例を示す。

【図8B】図８Ｂは、追加的な処理フロー例を示す。

【図8C】図８Ｃは、追加的な処理フロー例を示す。

【図8D】図８Ｄは、追加的な処理フロー例を示す。

【発明を実施するための形態】

【0008】

本発明を、限定ではなく例示として、添付図面の各図により示す。これらの図において、類似の要素には同種の参照符号を付している。

【0009】

映像リンクを介してディスプレイマネジメントメタデータを送信することに関する実施形態例を、本明細書に記載する。以下の記載においては、説明目的のため、本発明を完全に理解できるように多数の詳細事項を説明する。ただし、これらの詳細事項が無くても本発明を実施可能であることは明白であろう。他方、本発明の説明を不必要に煩雑にしたり、不明瞭にしたり、難読化したりしないように、周知の構造およびデバイスの細かな詳細までは説明しない。

【0010】

本明細書において、以下の概略にしたがって実施形態例を記載する。
１．概説
２．基準コード値およびマッピング後の画素値
３．メディアソースシステム
４．メディアシンクシステム
５．ＤＭメタデータを送信および受信するためのアルゴリズム
６．ＨＤＭＩ映像リンク
７．基準コード値およびＤＭデータのトンネル処理
８．ソース・シンク間の明示的な信号送信の不在
９．ＥＤＲ動作のためにソースを構成
１０．処理フロー例
１１．実装メカニズム−ハードウェア概要
１２．均等物、拡張物、代替物、その他

【0011】

１．概説
本概説は、本発明の一実施形態のいくつかの局面の、基本的説明を提供する。本概説は、当該実施形態の持つ局面の広範あるいは網羅的な要約ではないことに留意されたい。また、本概説は、実施形態の特に重要な局面または要素を同定することを意図されたものではなく、実施形態の範囲や本発明全般を特に規定するものでもないことに留意されたい。本概説は、例示的な実施形態に関連するいくつかの着想を凝縮および単純化された形式で単に提示するだけであり、以下に続く実施形態例のより詳細な説明の、概念的な導入部として単に理解されるべきである。

【0012】

本明細書に記載の技術によれば、ソースビデオ信号、ソースビデオビットストリーム、ソースビデオファイルなどにおいて、（例えばシーン−リファードなどの）ハイダイナミックレンジ、広色域、および高解像度のソースコンテンツを、基準コード値（例えば暗レベルと最大輝度レベル間の基準ダイナミックレンジにあるコード値や、カリフォルニア州サンフランシスコのＤｏｌｂｙ Ｌａｂｏｒａｔｏｒｉｅｓ，Ｉｎｃ．によって開発された技術における拡張ダイナミックレンジ（ＥＤＲ）にあるコード値コード値など）として、ディスプレイマネジメント（ＤＭ）メタデータとともに、規格準拠の映像リンクを介して下流の描画装置に送ることができる。ソースコンテンツ中のＤＭメタデータは、各描画装置が、ソースコンテンツ中の基準コード値をマッピング後の画素値にマッピングすることによって、その描画装置上において描画装置の最大能力を利用するように描画するために用いられることができる。ＤＭメタデータは、ルックアップテーブル、マッピング曲線、区分的線分（ｐｉｅｃｅｗｉｓｅ ｌｉｎｅ ｓｅｇｍｅｎｔｓ）を包含するマッピング関数、線分または曲線分のピボット点その他を表す、マッピングパラメータを含み得る。

【0013】

一例においてＤＭメタデータは、Ｒｅｃ．７０９ダイナミックレンジをサポートする描画装置が、基準コード値を、描画装置によってサポートされるＲｅｃ．７０９ダイナミックレンジをフルに利用するような、マッピング後の輝度画素値にマッピングするために用いられることができる。別の例において、ＤＭメタデータは、Ｒｅｃ．６０１ダイナミックレンジをサポートする描画装置が、基準コード値を、描画装置によってサポートされるＲｅｃ．６０１ダイナミックレンジをフルに利用するような、マッピング後の輝度画素値にマッピングするために用いられることができる。様々な態様において、ＤＭメタデータは、Ｒｅｃ．６０１およびＲｅｃ．７０９よりも高いあるいは低いダイナミックレンジをサポートする描画装置が、ハイダイナミックレンジにある基準コード値を、これらの描画装置によってサポートされるより高いあるいは低いダイナミックレンジをフルに利用するような、マッピング後の輝度画素値にマッピングするために用いられることができる。これに加えてかつ／またはオプションとして、ＤＭメタデータは、Ｒｅｃ．６０１およびＲｅｃ．７０９より広いあるいは狭い、またはこれと同じ色域をサポートする描画装置が、基準コード値を、これらの描画装置によってサポートされるより広いか狭いまたは同じ色域をフルに利用するような、マッピング後のクロマまたは色チャンネル画素値にマッピングするために用いられることができる。これに加えてかつ／またはオプションとして、ＤＭメタデータは、Ｒｅｃ．６０１およびＲｅｃ．７０９より高いあるいは低い、またはこれと同じ空間解像度をサポートする描画装置が、基準コード値によって表される空間解像度を、これらの描画装置によってサポートされるより高いか低いまたは同じ空間解像度をフルに利用するような、最適な装置固有の空間解像度に変換するために用いられることができる。

【0014】

いくつかの実施形態において、ＤＭメタデータは、ＤＭメタデータに基づいたディスプレイマネジメント動作が行われるべき、対応する基準コード値に依存しかつこれと共変である。例えば、第１の画像または第１のシーンについての第１のＤＭメタデータは、第２の異なる画像または第２のあるいは異なるシーンについての第２のＤＭメタデータとは異なり得る。いくつかの実施形態において、ＤＭメタデータおよびその対応する基準コード値（ある画像またはシーンを表す）は、同じビデオフレーム（例えば、ある時間順ビデオフレームのシーケンス内における、時間順ビデオフレームの部分的シーケンスなど）で送られる。いくつかの実施形態において、ＤＭメタデータおよびその対応する基準コード値（ある画像またはシーンを表す）は、厳密な時間ウィンドウ（例えば１ビデオフレーム、２ビデオフレーム．．．、Ｎ個のビデオフレーム未満のうちの１つ。ここで、Ｎは予め設定された小さな整数など）内にある、互いに隣接するビデオフレームで送られる。例えば、ＤＭメタデータは、時刻（Ｔ−１）のビデオフレームで送られる一方、対応する基準コード値は、時刻Ｔの別のビデオフレームで送られ得る。様々な実施形態において、ＤＭメタデータおよびその対応する基準コード値に対し、他の時刻同期送信のバリエーションを用いてもよい。

【0015】

いくつかの実施形態において、ＤＭメタデータおよび基準コード値は、映像リンク規格やビデオ送信規格などにより、描画用の画素値などを保持するように指定された、ビデオフレームを構成する画素に多重化され得る。一実施形態例においてＤＭメタデータは、ビデオフレームを構成する画素内の複数のビットフィールドに保持されることができる−−ここでこれらの複数のビットフィールドは、映像リンク規格によって、クロマまたは色チャンネル画素値の最下位ビット値を保持するように特に指定されたものである。人間の視覚はクロマ情報に対してはルマ情報ほど感受性を有さないため、これらのビットフィールドにＤＭメタデータを保持させることによって引き起こされる視覚的欠陥や劣化は、比較的少ない可能性がある。

【0016】

ビデオフレームは、映像リンクを通じて送信される映像データの基本的な部分を構成するため、ＤＭメタデータおよび基準コード値をビデオフレーム中において送ることは、映像リンクが幅広く様々な異なるタイプのうちいずれであったとしても、ＤＭメタデータが比較的高い信頼性で時刻同期的に受信側のデバイスに到達することを可能にする。

【0017】

本明細書に記載の技術は、映像リンク（または映像データパイプライン）がビデオフレームを送ることが可能であるかぎり、ＨＤＭＩなどを含むがこれに限定されない任意のタイプの映像リンクにおいて、実現することができる。いくつかの実施形態において、ある特定の１つの映像リンクタイプ（例えばＨＤＭＩなど）は、表示能力の限定された携帯機器から優れた表示能力を持つハイエンドのプロフェッショナルディスプレイシステムまで、無数の（例えば何十億個のなど）シンクシステムをサポートし得る。本明細書に記載の技術によれば、基準コード値およびＤＭメタデータを含むソースコンテンツを、１つの統一的なパイプラインを通じてこれらシンクシステムのすべてに送ることができる。そしてこれらのシンクシステムは、パイプライン内のＤＭメタデータを用いて、同じパイプライン中の基準コード値を、ターゲットディスプレイのそれぞれの表示能力を最大化するようにターゲットディスプレイ上で描画されるための、装置固有、メーカー固有、あるいは規格固有の画素値として適応化することができる。

【0018】

本明細書に記載の技術は、必要であれば非常に大量のＤＭメタデータまでをビデオフレーム中に保持するために用いることができる。なぜならば、１つのビデオフレームには多数の画素（例えば走査線毎につき１ｋ画素など）を有することができ、ここから特定のビットフィールドを選んでＤＭメタデータ送信パケットを保持させればよいからである。様々な実施形態において、１ビデオフレーム中における、固定数あるいは可変数の走査線（例えば開始走査線、ボトム走査線、中間走査線、インターリーブ化走査線、連続走査線、非連続走査線など）や、規則的パターン、不規則パターン、ラスター順の画素などを、ＤＭメタデータを保持するために用いることができる。異なるビデオフレームは、異なる量のＤＭメタデータを保持していてもよい。いくつかの実施形態において、一部のビデオフレームはＤＭメタデータを保持せずに、むしろ他のビデオフレームで送信されたＤＭメタデータを利用することで、前者のビデオフレームにおける基準コード値をマッピングしてもよい。いくつかの実施形態において、ＤＭメタデータは冗長的に送信されてもよく、もしある特定のビットフィールド、走査線、画像ブロック、ビデオフレームなどで破損が発生しても、映像リンクの送信パイプラインにおけるＤＭメタデータの他のコピーを代わりに用いることができる。いくつかの実施形態において、エラー検出および回復を助けるための巡回冗長値を、ＤＭメタデータ送信パケットについて算出し、これがＤＭメタデータとともにＤＭメタデータ送信パケット中において送信されてもよい。

【0019】

いくつかの実施形態において、規格準拠のメタデータ送信メカニズム（例えば規格準拠のメタデータ情報フレームなど）を、本明細書に記載の技術とともに用いることができる。しかし、本明細書に記載の技術は、これら規格準拠のメタデータ送信メカニズムが利用可能であることには依存せず、必要であれば独立に実行することができる。

【0020】

いくつかの実施形態において、本明細書に記載のソースシステムおよびシンクシステムは、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などする際に、最初のホットプラグ信号において能力情報を交換することができる。例えば、２つの通信しているソースシステムおよびシンクシステムが交渉を行って、本明細書に記載の技術が両デバイスにおいて相互にサポートされているか、かつ／またはシンクシステム上において現在実行中のディスプレイアプリケーションによってサポートされているか否かを、判断してもよい。もしサポートされているならば、後続のビデオフレームを本明細書に記載の技術で符号化することにより、基準コード値およびＤＭメタデータの両方を保持させることができる。一方、もしシンクシステムが本明細書に記載の技術を実現しないか、あるいは本明細書に記載の技術を実現しないディスプレイアプリケーションをシンクシステムが実行中であるならば、後続のビデオフレームは、本明細書に記載のＤＭメタデータを有さない、展開状態の（ｄｅｃｏｍｐｒｅｓｓｅｄ）映像データと組み合わされ（ａｓｓｅｍｂｌｅｄ）ればよい。

【0021】

いくつかの実施形態において、基準コード値（例えばハイダイナミックレンジ、広色域、高解像度などのソースコンテンツを表す）およびＤＭメタデータ（例えば、基準コード値のためのマッピング関数などを含む）は、ソースシステムによって第１のビデオ信号フォーマットのビデオ信号に符号化され、またシンクシステムによって第１のビデオ信号フォーマットのビデオ信号から復号化され得る。第１のビデオ信号フォーマットのビデオ信号は、第１のビデオ信号フォーマットのビデオ信号の送信をサポートするビデオ信号通信路を用いて、ソースシステムおよびシンクシステム間を移動され得る。ビデオ信号通信路とは、特定の再生環境における映像リンクを指している。

【0022】

これに加えて、または代替的に、あるいはオプションとして、いくつかの実施形態において、第１のビデオ信号フォーマットのビデオ信号は、第１のビデオ信号フォーマットのビデオ信号の送信をサポートしないビデオ信号通信路を用いて、ソースシステムおよびシンクシステム間を移動されてもよい。様々な実施形態において、ソースシステムおよびシンクシステムの一方または両方に関する１つ以上の制約が、ソースシステムおよびシンクシステムが用いられている映像再生環境などに対して存在する場合があり、第１のビデオ信号フォーマット以外の異なるビデオ信号フォーマットがビデオ信号通信路によってサポートされる場合がある。

【0023】

本明細書に記載の技術を用いて、第１のビデオ信号フォーマットをサポートしないが、第１のビデオ信号フォーマットとは異なる１つ以上の第２のビデオ信号フォーマットのビデオ信号の送信をサポートするようなビデオ信号通信路を介して、第１のビデオ信号フォーマットで符号化された基準コード値およびＤＭメタデータの移動を行うことができる。

【0024】

いくつかの実施形態において、本明細書に記載されるソースシステムとシンクシステムとの間の通信路は、オーディオビデオレシーバー（ＡＶＲ）などの１つ以上の第３のデバイスを介して、リレーされてもよい。

【0025】

いくつかの実施形態において、ソースシステムおよびシンクシステム間の通信をリレーするＡＶＲは、ソースシステムおよびシンクシステム間の、（例えば規格準拠、独自、またはその他などの）メタデータ送信メカニズム（例えば規格準拠のメタデータ情報フレーム、独自のメタデータ情報フレーム、その他など）をサポートする。ソースシステムおよびシンクシステムは、メタデータ送信メカニズムなどを介して、最初のホットプラグ信号（例えば規格準拠のハンドシェークによる、ベンダー固有のデータブロックを介する、ベンダー固有の情報フレームを介するなど）において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択する、などすることができる。

【0026】

いくつかの実施形態において、最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などするために用いることができるメタデータ送信メカニズムが、本明細書に記載されるソースシステムおよびシンクシステムが動作する特定の映像再生環境において、利用可能でない場合がある。例えば、ソースシステムおよびシンクシステム間の通信をリレーするＡＶＲ（例えば旧式のデバイスなど）は、ソースシステムおよびシンクシステムが最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などすることを可能にするようなメタデータ送信メカニズムをサポートしていないかもしれない。

【0027】

本明細書に記載の技術は、本明細書に記載のシンクシステムが、本明細書に記載のソースシステムから受け取った基準コード値およびＤＭデータに基づいて、特定のディスプレイマネジメント動作を実行することを可能にするために用いられ得る。これは、ソースシステムおよびシンクシステムが動作する特定の映像再生環境において、ソースシステムおよびシンクシステムが最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などすることを可能にするようなメタデータ送信メカニズムが、利用可能であるか否かに関わらない。さらにこれらの技術は、本明細書に記載のソースシステムから受け取った基準コード値およびＤＭデータに基づいて、シンクシステムが表示動作を行うことが可能であるか否かを、本明細書に記載のソースシステムが検出することを可能にするための技術を含み得る。

【0028】

いくつかの実施形態において、本明細書に記載のメカニズムは、メディア処理システムの一部分を形成する。そのようなメディア処理システムは、ハンドヘルド型デバイス、ゲーム機器、テレビ、ホームシアターシステム、セットトップボックス、タブレット、携帯機器、ラップトップコンピュータ、ネットブックコンピュータ、セルラー無線電話、電子ブックリーダー、ＰＯＳ端末装置（ｐｏｉｎｔ ｏｆ ｓａｌｅ ｔｅｒｍｉｎａｌ）、デスクトップコンピュータ、コンピュータワークステーション、コンピュータキオスク、様々なその他の種類の端末ならびにメディアプロセッサ、などを含むがこれらに限定されない。

【0029】

本明細書に記載された好適な実施形態および一般的原則特徴に対する様々な改変が、当業者には容易に明らかである。したがって、本開示は、ここに示した実施形態に限定されることを意図されておらず、本明細書に記載の原則および特徴と整合するかぎり最も広範な範囲を与えられるべきであることが意図される。

【0030】

２．基準コード値およびマッピング後の画素値
本明細書に記載のソースビデオ信号中の基準コード値は、広いダイナミックレンジ（例えば、ハイダイナミックレンジ、視覚ダイナミックレンジ、Ｒｅｃ．７０９より広いなど）をサポートするために用いることができる。いくつかの実施形態において、基準コード値は、輝度値の数値やガンマ値によるベキ関数で調整された輝度値の数値からなるものではない。そうではなく、基準コード値は、サポートされるダイナミックレンジにわたる輝度値の複数の量子化レベルのなかの、特定の１つの量子化レベルを（例えばインデックス値として）表している。いくつかの実施形態において、基準コード値は、ディスプレイマネジメントメタデータ中のマッピング関数パラメータを用いた１つ以上のマッピング関数によって、大きな輝度範囲（またはダイナミックレンジ）内にある数値にマッピングされ得る。例えば、本明細書に記載の基準コード値からマッピングされた中間調または輝度値は、０あるいは約０（例えば１０^-7ｃｄ／ｍ²、１０^-5ｃｄ／ｍ²、１０^-4ｃｄ／ｍ²など）から、大きな輝度値（例えば１２，０００ｃｄ／ｍ²、５０００ｃｄ／ｍ²、６００ｃｄ／ｍ²など）までわたり得る。基準コード値はまた、異なる周囲光レベルを有する広い範囲で視聴および／または表示するケースと、異なる暗黒レベルを有する広い範囲のディスプレイ装置（例えば劇場、屋内、屋外など）とをサポートするように用いられ得る。これに加えて、またはオプションとして、基準コード値を、マッピング関数パラメータを用いた１つ以上のマッピング関数によって、ある色空間（あるいは色域）の大きな部分における色数値（例えばクロマ値、ＲＧＢ値など）に、マッピングすることができる。本明細書に記載の個々のビデオフレームにおける基準コード値は、複数の量子化レベルにおける量子化レベルの部分集合を表していてもよく、ある特定のビット深度（例えば８ビット、１０ビット、１２ビットなど）の符号空間中にある、利用可能なコード値（例えば２５６個の利用可能なコード値、１０２４個の利用可能なコード値、４０９６個の利用可能なコード値など）に圧縮されてもよい。

【0031】

いくつかの実施形態において、本明細書に記載の基準コード値は知覚的量子化（ＰＱ）符号化されていてもよいが、これに限定されない。例えば、いくつかの実施形態において、基準コード値は、輝度値の複数の知覚的量子化レベルの中のある特定の知覚的量子化レベルを表す（例えばインデックス値としてなど）。輝度値２つの隣接する知覚的量子化レベルの間の輝度差は、ぎりぎり気付き得る差（ｊｕｓｔ ｎｏｔｉｃｅａｂｌｅ ｄｉｆｆｅｒｅｎｃｅ）すなわちＪＮＤ、ＪＮＤの比、ＪＮＤに一定の乗数を乗算したもの、その他であってもよい。複数の知覚的量子化レベルは、本明細書に記載のソースビデオ信号がサポートするように構成された幅広いダイナミックレンジの全体を、カバーし得る。

【0032】

本明細書に記載のＤＭメタデータとは、ビデオ画像描画動作の一部としてのディスプレイマネジメント動作を行うために、メディアシンクシステムによって用いられるメタデータを指す。ＤＭメタデータの例は以下を含むが、これらに限定されない。すなわち、輝度マッピング関数のためのマッピング関数パラメータ、色差マッピング関数のためのマッピング関数パラメータ、グローバルな画像またはフレーム特性、ソースビデオフレームのアスペクト比、信号変換行列の係数、ガンマ値、ビット深度、色空間、サンプリングフォーマット、黒レベル、輝度値範囲、クロマ値範囲、ソースディスプレイの（例えば最小、最大、平均など）輝度値、他のグローバル特性など、１シーンまたは個々の画像の（例えば最小、最大、平均など）輝度値、その他のグローバル特性など、ソースディスプレイ（例えばリファレンスディスプレイなど）の対角サイズ、などである。いくつかの実施形態において、ＤＭメタデータに含まれる動作パラメータのうち少なくとも一部（例えばマッピング関数のためのマッピング関数パラメータなど）は、画像依存的である。いくつかの実施形態において、マッピング関数パラメータをＤＭメタデータ中に持つマッピング関数の少なくとも一部が、メディアシンクシステムによって適用されることより、基準コード値をマッピング後の画素値にマッピングしてもよい。ＤＭメタデータ中のマッピングパラメータは、ルックアップテーブル、マッピング曲線、区分的線分を包含するマッピング関数、線分または曲線分のピボット点、またはその他を表し得る。

【0033】

いくつかの実施形態において、ＤＭメタデータは、復号化された画素情報に付随することで復号化された画素情報の再符号化または画像の再構築を容易にするような、符号化情報（例えば４×４、８×８などの画像ブロックレベルの）ではない。むしろ、ＤＭメタデータは、ビデオ画像がターゲットディスプレイ上で描画されたときに、ターゲットディスプレイの表示能力が最大化されたり、クリップした輝度値および／またはクリップした色差値を持つ画素の数が最少化されたりするように、ビデオ画像をターゲットディスプレイ上で描画するための、対応する基準コード値をマッピング後の画素値にマッピングする、メタデータである。ＤＭメタデータの一部または全部は、それを保持するビデオフレームにおいて、エラー保護および回復のために繰り返されてもよい。いくつかの実施形態において、ＤＭメタデータは、カラー管理アプリケーションまたは他のアプリケーションによって導出されてもよい。

【0034】

一例として、ソース画像（例えばシーン−リファード画像など）から導出されたビデオ画像が、暗輝度レベル分布中において１つ以上の顕著な物体を示すとき、暗輝度レベルにマッピングされ得る比較的多数の基準コード値を、このビデオ画像を本明細書に記載のソースビデオ信号に符号化するために用い得る。マッピングされた暗輝度レベルは、メディアシンクシステムによってレンダリングされることにより、描画された画像中の暗い顕著な物体に対して、シーン−リファード画像をよく近似する、同じまたは実質的に（例えばＪＮＤの５％、１０％、２０％以内など）同じ輝度レベルを生成することができる。

【0035】

別の例として、ソース画像（例えばシーン−リファード画像など）から導出されたビデオ画像が、明輝度レベル分布中において１つ以上の顕著な物体を示すとき、明輝度レベルにマッピングされ得る比較的多数の基準コード値を、このビデオ画像を本明細書に記載のソースビデオ信号に符号化するために用い得る。マッピングされた明輝度レベルは、メディアシンクシステムによってレンダリングされることにより、描画された画像中の明るい顕著な物体に対して、シーン−リファード画像をよく近似する、同じまたは実質的に（例えばＪＮＤの５％、１０％、２０％以内など）同じ輝度レベルを生成することができる。

【0036】

本明細書に記載の技術は、広いダイナミックレンジのソース画像の顕著なコンテンツを捉える多数の画素を、メディアシンクシステムにおける対応する描画された画像中の、同じまたは実質的に同じ輝度レベルにマッピングするために用いることができる。本明細書に記載の技術によるアプローチは、他のアプローチと比べ、描画された画像中においてソース画像の知覚的品質を比較的高度に維持する。

【0037】

本明細書に記載の技術はまた、採用した色空間の１つ以上のプライマリチャンネル（例えばクロマチャンネル、赤、緑、青その他）を、個別にグローバルに変調するために用いることができる。プライマリチャンネルの個別の変調は、色域におけるカラーバランスを再構成でき、特定の色（画像における色相および彩度領域）が他の色よりも支配的である場合に有利である。例えば、赤が支配的であり、弱めの青が少量だけ存在するシーンにおいて、比較的多数の赤基準コード値および比較的少数の青基準コード値を割り当てることができる。

【0038】

いくつかの実施形態において、あるビデオフレームの基準コード値によって表されるビデオ画像は、他のビデオ画像に対してのハイライトを多く含んでいるかもしれない。この場合、基準コード値における輝度レベルを映像描画装置のマッピング後の輝度レベルにマッピングするために用いられる、輝度マッピング関数のためのマッピング関数パラメータは、メディアシンクシステム（例えば映像描画装置など）が、より多くの明るい輝度レベルを割り当てることを可能にする。同様に、あるビデオフレームの基準コード値によって表されるビデオ画像は、他のビデオ画像に対して暗い領域を多く含んでいるかれしれない。この場合、基準コード値における輝度レベルを映像描画装置のマッピング後の輝度レベルにマッピングするために用いられる、輝度マッピング関数のためのマッピング関数パラメータは、映像描画装置が、より多くの低輝度レベルを割り当てることを可能にする。これに加えてかつ／またはオプションとして、ＤＭメタデータはまた、ビデオ画像におけるより支配的な色に対して、より多くの色レベルまたは値の区別を割り当てるために用いることができる。これに加えてかつ／またはオプションとして、ＤＭメタデータはまた、他のＤＭ動作パラメータ（例えばビデオフレームのアスペクト比など）をメディアシンクシステムに伝えるために用いることができる。この結果、本明細書に記載のＤＭメタデータを利用する映像描画装置は、より高いダイナミックレンジかつより広い色域を有する、ビデオ画像を生成することが可能になる。

【0039】

いくつかの実施形態において、本明細書で用いられる「マッピング後の画素値、輝度値、およびクロマ値」とは、装置固有の画素値、輝度値、およびクロマ値（例えば独自のダイナミックレンジまたは色域などを表し得る）を指し得る。いくつかの実施形態において、本明細書で用いられる「マッピング後の画素値、輝度値、およびクロマ値」とは、ある規格（例えばＲｅｃ．７０９、スタンダードダイナミックレンジすなわちＳＤＲ、携帯機器を規定するビデオ規格、タブレット型コンピュータを規定するビデオ規格、その他など）に従った、規格準拠の画素値、輝度値、およびクロマ値を指し得る。

【0040】

本明細書で用いられる映像リンクとは、映像および関連のデータを、ソースシステムからシンクシステムへ送るパイプライン（例えばビデオ信号、ビデオビットストリームなど）を指す。いくつかの実施形態において、基準コード値は、ＤＭメタデータとともに、映像リンクを規定する１つ以上の映像リンク規格に従って、ソースシステムからシンクシステムへ映像リンクを介して送られる。

【0041】

３．メディアソースシステム
図１は、１つ以上の実施形態によるメディアソースシステム（１００）を示す。図１に示すように、システム（１００）は、ソースビデオ受信器（１０４）、ビデオフレーム発生器（１０６）、ビデオエンコーダ（１１０）、およびビデオメモリ（１０８）を有する。ビデオメモリ（１０８）は、フレームバッファ、ディスプレイマネジメント（ＤＭ）メタデータバッファなどを含む。

【0042】

これら構成要素の各々を下記に説明するが、これらは、同じデバイス（例えばセットトップボックス、コンピュータ、サーバーシステム、クライアントシステムなど）上に位置してもよく、あるいは、有線および／または無線セグメントを用いて、ネットワーク（例えばインターネット、イントラネット、エキストラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）など）により結合された、別々のデバイス上に位置していてもよい。１つ以上の実施形態において、システム１００はクライアント−サーバー形態を用いて実現される。システム（１００）自体が１つ以上のコンピュータ上で実行中のアプリケーションであってもよく、またいくつかの実施形態においてはピア・トゥ・ピアシステムであってもよく、あるいは単一のコンピューティングシステム上に存在してもよい。また、システム（１００）は、システム１００にアクセスするための１つ以上のインターフェースまたは他の任意のツールを用いて、他の機器からアクセス可能である。１つ以上の実施形態において、システム（１００）は、インターネットなどのネットワーク接続を介してアクセス可能である。システム（１００）によって提供される情報および／またはサービスはまた、格納されてネットワーク接続を介してアクセスされてもよい。

【0043】

一実施形態例において、ソースビデオ受信器１０４は、ソースビデオ信号１０２を受け取り、１つ以上のビデオフレームにおける基準コード値およびその基準コード値に具体的に対応しているＤＭメタデータを、そのソースビデオ信号（１０２）から導出（例えば抽出、復号化、生成、決定、算出など）するように構成された、ソフトウェアおよび／またはハードウェアに相当する。この１つ以上のビデオフレームは、ソースビデオ受信器１０４によってソースビデオ信号（１０２）から復号化されたビデオフレームの時間的シーケンスの一部であってもよい。

【0044】

ソースビデオ受信器１０４は、ソースビデオ信号（１０２）に保持された異なるデータコンポーネントを導出し分離するように構成されていてもよい。例えば、ソースビデオ信号中の音声／映像データおよびＤＭメタデータは、デマルチプレクサを用いて、別々のコンポーネント（例えば音声コンポーネント、映像コンポーネント、メタデータコンポーネントなど）に分離されてもよい。いくつかの実施形態において、ＤＭメタデータは、映像コンポーネントに埋め込まれていて、そこから抽出されてもよい。いくつかの実施形態において、ＤＭメタデータは、ソースビデオ信号の別々のメタデータコンポーネントに保持されていて、そこから復号化されてもよい。

【0045】

一実施形態例において、ビデオフレーム発生器（１０６）は、ソースビデオ信号（１０２）から導出された基準コード値およびＤＭメタデータを受け取り、ＤＭメタデータを格納するＤＭメタデータ送信パケットを生成し、基準コード値およびＤＭメタデータを含んだＤＭメタデータ送信パケットの両方を、ビデオメモリ（１０８）における１つ以上のビデオフレームのビットフィールドに格納／設定するように構成された、ソフトウェアおよび／またはハードウェアに相当する。一例において、ビデオフレーム発生器（１０６）は、ソースビデオ信号（１０２）より導出されたＤＭメタデータを、ソースビデオ受信器（１０４）から受け取ってもよい。別の例において、ビデオフレーム発生器（１０６）は、ソースビデオ受信器（１０４）以外のモジュールからＤＭメタデータを受け取ってもよい。いくつかの実施形態において、ビデオフレーム発生器（１０６）は、１つ以上のビデオフレームの特定のビットフィールドを、ＤＭメタデータを含んだＤＭメタデータ送信パケットを格納するために選択するように構成されている。いくつかの実施形態において、ＤＭメタデータを保持するように選択される特定のビットフィールドは、本来は、メディアソースシステムから下流のメディアシンクシステムへの映像リンクを規定する１つ以上のビデオ信号規格によって、採用した色空間（例えばＹＣｂＣｒ、ＲＧＢなど）の１つ以上のチャンネル（例えばクロマチャンネル、輝度チャンネル、赤、緑および／または青チャンネルなど）のコンポーネント画素値の最下位ビットを保持するように指定されたものである。限定的ではない一実施形態例において、特定のビットフィールドは、本来はクロマ画素値を格納するように指定されたビットフィールドのみから選択される。いくつかの実施形態において、ＤＭメタデータを格納するように選択されるビットフィールドは、ビデオフレーム中の複数の連続画素からのものである。いくつかの実施形態において、ＤＭメタデータを格納するように選択されるビットフィールドは、ビデオフレーム中の複数の非連続画素からのものである。いくつかの実施形態において、ＤＭメタデータを格納するように選択されるビットフィールドは、あるビデオフレームの、１つ以上の走査線（例えば１つ以上の開始走査線、１つ以上の終了走査線、１つ以上の中間走査線など）中の複数の画素からのものである。いくつかの実施形態において、少なくともＤＭメタデータの一部を含むＤＭメタデータ送信パケットの単一のコピーが、ビデオフレームのビットフィールドに格納、すなわち埋め込まれている。いくつかの実施形態において、冗長性を提供してＤＭメタデータの送信信頼性を増大するために、少なくともＤＭメタデータの一部を含むＤＭメタデータ送信パケットの複数のコピーが、ビデオフレームのビットフィールドに格納、すなわち埋め込まれている。いくつかの実施形態において、あるビデオフレームは、そのビデオフレームにはビデオフレームの画素値に対するディスプレイマネジメント動作を行うために用いられるべきＤＭメタデータを含んでいず、別のＤＭメタデータ送信パケットにおいて受け取られたあるいは受け取られるであろうＤＭメタデータがそのような動作を行うために用いられるべきだという指標（ｉｎｄｉｃａｔｉｏｎ）を含んでいてもよい。

【0046】

本明細書に記載のＤＭメタデータ送信パケットとは、ペイロード部と、少なくとも１つの巡回冗長値、および可能性として他の制御または信号情報１つ以上の他の部分とを有する、任意のデータ格納体を指す。一態様例において、巡回冗長値は、ペイロード部に格納されまたＤＭメタデータ送信パケットの後続バイト（ｔｒａｉｌｉｎｇ ｂｙｔｅｓ）（例えばペイロード部とは別の部分など）に置かれる、バイトまたはワード値から算出されることができる。別の態様例において、巡回冗長値は少なくとも部分的には、ＤＭメタデータ送信パケットのヘッダー部のバイトまたはワード値から、算出され得る。本明細書に記載のＤＭメタデータ送信パケットを上流デバイス（例えばメディアソースシステムなど）から下流デバイス（例えばメディアシンクシステムなど）へ送信する際に発生し得るエラー（例えばビットエラー、ジッター、クロストークなど）から保護および回復するために、パケット冗長性やＣＲＣ値以外の他のエラー保護および訂正メカニズムの１つ以上（例えば生成多項式により算出されるなど）を用いてもよい。

【0047】

本発明の１つ以上の実施形態において、ビデオメモリ（１０８）は、バルクメモリコピー動作、バルクメモリムーブ動作、高速なメモリ埋め動作などを含むがこれらに限定されない、比較的高速な映像処理動作を扱うよう構成されたメモリ空間に相当する。ビデオメモリ（１０８）は、静的および／または動的なメモリ割り当てをサポートするように構成され得る。ビデオメモリ（１０８）は、１つ以上のビデオフレームの全ビットフィールドを保持するビデオフレームバッファと、ビデオフレームバッファの当該１つ以上のビデオフレームに埋められた基準コード値に関連するＤＭメタデータを保持するＤＭメタデータバッファと、を有し得る。ビデオメモリ（１０８）に格納されるビデオフレームは、ＹＣｂＣｒ色空間やＲＧＢ色空間などを含むがこれらに限定されない、様々な色空間のうちの１つに関連し得る。ビデオメモリ（１０８）に格納されたビデオフレームは、４：４：４サンプリングフォーマット、４：２：２サンプリングフォーマット、４：２：０サンプリングフォーマットなどを含むがこれらに限定されない、様々なサンプリングフォーマット（例えばクロマサンプリングフォーマットなど）のうちの１つに関連し得る。メモリ空間を構築してビデオメモリ（１０８）に映像データを格納するために、多くの実装形態（例えばアレイ、シーケンス、データ構造、連結リスト、環状バッファ、ハッシュテーブルなど）を用い得る。

【0048】

一実施形態例において、ビデオエンコーダ（１１０）は、ビデオメモリ（１０８）内の基準コード値を有する１つ以上のビデオフレームを取り出し、ＤＭメタデータを前記基準コード値を有するビデオフレームに合成（例えばパケット化、クロマチャンネルのＬＳＢに埋め込みなど）し、ビデオメモリ（１０８）内の取り出されたビデオフレームに少なくとも部分的に基づき、メディアシンクシステムに送信されるべき符号化ビデオ信号（１１２）を生成／符号化するように構成された、ソフトウェアおよび／またはハードウェアに相当する。本明細書において、符号化ビデオ信号とは、ビデオ信号中の一部または全てのビデオフレームの画素中にＤＭメタデータが埋め込まれた、ビデオ信号（例えばクロマチャンネルのＬＳＢに埋め込まれたメタデータを有する符号化ビデオ信号１１２など）を指し、また、符号化ビデオ信号を生成または符号化するとは、ＤＭメタデータがビデオフレームの画素に埋め込まれたビデオ信号を、生成または符号化することを指す。取り出されたビデオフレーム、あるいはその中のビットフィールドは、基準コード値（コンポーネント画素値の最下位ビットのうち一部を、ＤＭメタデータを含んだＤＭメタデータ送信パケットのビット値によって置きかえたものなど）と、下流のメディアシンクシステムが、基準コード値に対して映像描画動作の一環としてディスプレイマネジメント動作を行うために用いられるＤＭメタデータ、との両方を含んでいる。ビデオエンコーダによって生成／符号化される符号化ビデオ信号（１１２）は、ビデオフォーマットおよび送信プロトコルに関して、下流のメディアシンクシステムとの映像リンクを規定する映像リンク規格に従うが、ただし、符号化ビデオ信号（１１２）に保持されるビデオフレームは、基準コード値およびＤＭメタデータの両方を保持している。ＤＭメタデータを格納するためにクロマ画素値の最下位ビットのみが選択される実施形態においては、クロマ画素値の最下位ビットを失うことに起因する知覚し得るアーチファクトは少ないため、本明細書に記載の技術を実装しないメディアシンクシステムは、元の品質に近いビデオ画像を描画することが可能である。さらに、本明細書に記載の技術を実装したメディアシンクシステムでは、ＤＭメタデータを用いることにより、元のシーン−リファード画像において捉えられていたものをよく近似する、ハイダイナミックレンジ、広色域、細やかな知覚可能な画像ディテールなどを備えた高品質なビデオ画像を描画することができる。

【0049】

４．メディアシンクシステム
図２は、１つ以上の実施形態によるメディアシンクシステム（２００）を示す。図２に示すように、システム（２００）は、符号化ビデオ受信器（２０４）と、ＤＭメタデータ抽出器（２０６）と、ビデオ描画器（２１０）と、符号化ビデオ信号（１１２）から導出されたＤＭメタデータを格納するためのＤＭメタデータバッファ（２０８）を有するビデオメモリ（不図示）と、を備える。

【0050】

これら構成要素の各々を下記に説明するが、これらは、同じデバイス（例えばテレビ、セットトップボックス、タブレット、携帯機器、コンピュータ、サーバーシステム、クライアントシステムなど）上に位置してもよく、あるいは、有線および／または無線セグメントを用いて、ネットワーク（例えばインターネット、イントラネット、エキストラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）など）により結合された、別々のデバイス上に位置してもよい。１つ以上の実施形態において、システム２００はクライアント−サーバー形態を用いて実現される。システム（２００）自体が１つ以上のコンピュータ上で実行中のアプリケーションであってもよく、またいくつかの実施形態においてはピア・トゥ・ピアシステムであってもよく、あるいは単一のコンピューティングシステム上に存在してもよい。また、システム（２００）は、システム２００にアクセスするための１つ以上のインターフェースまたは他の任意のツールを用いて、他の機器からアクセス可能である。１つ以上の実施形態において、システム（２００）は、インターネットなどのネットワーク接続を介してアクセス可能である。システム（２００）によって提供される情報および／またはサービスはまた、格納されてネットワーク接続を介してアクセスされてもよい。

【0051】

一実施形態例において、符号化ビデオ受信器２０４は、符号化ビデオ信号１１２を受け取り、基準コード値およびその基準コード値に具体的に対応しているＤＭメタデータを含む１つ以上のビデオフレームを、その符号化ビデオ信号（１１２）から導出（例えば抽出、復号化、生成、決定、算出など）するように構成された、ソフトウェアおよび／またはハードウェアに相当する。符号化ビデオ受信器２０４によって符号化ビデオ信号（１１２）から復号化された、基準コード値およびＤＭメタデータを含むこの１つ以上のビデオフレームは、ビデオフレームの時間的シーケンスの一部であってもよい。

【0052】

符号化ビデオ受信器２０４は、映像リンク（これを介して符号化ビデオ信号１１２が受け取られる）を規定する映像リンク規格に従った、映像リンク受信器として構成されてもよい。符号化ビデオ受信器２０４はさらに、符号化ビデオ信号（１１２）に保持された異なるデータコンポーネントを導出し分離するように構成されてもよい。例えば、符号化ビデオ信号（１１２）中の音声／映像データは、デマルチプレクサを用いて、別々のコンポーネント（例えば音声コンポーネント、映像コンポーネントなど）に分離されてもよい。

【0053】

一実施形態例において、ＤＭメタデータ抽出器（２０６）は、符号化ビデオ信号（１１２）から導出された基準コード値およびＤＭメタデータを含む１つ以上のビデオフレームを受け取り、ビデオフレーム中の複数のビットフィールドからＤＭメタデータを格納するＤＭメタデータ送信パケットを取り出し、ＤＭメタデータ送信パケットからＤＭメタデータを抽出／導出し、ＤＭデータをＤＭメタデータバッファ（２０８）に格納／キャッシュするように構成された、ソフトウェアおよび／またはハードウェアに相当する。例えば、ＤＭメタデータ抽出器（２０６）は、１つ以上のビデオフレームの特定のビットフィールド（例えば特定のチャンネルの最下位ビット、１つ以上の特定の走査線上のビットフィールド、ビデオフレームのあるパターン中のビットフィールドなど）を選択し、これらの特定のビットフィールドからビット値を抽出し、抽出されたビット値をＤＭメタデータ送信パケットに組み合わせ（ａｓｓｅｍｂｌｅ）、ＤＭメタデータ送信パケットのペイロードから、ＤＭメタデータを抽出してＤＭメタデータバッファ（２０８）に入れるように構成され得る。

【0054】

ＤＭメタデータ抽出器（２０６）は、ＤＭメタデータ送信パケットの単一のコピーまたは同じＤＭメタデータ送信パケットの複数のコピーのうちの１つを、ビデオフレームから取り出すように構成され得る。いくつかの実施形態において、ＤＭメタデータ抽出器（２０６）は、ＤＭメタデータ送信パケットが破損しているかをベリファイするように構成される。例えば、ＤＭメタデータ抽出器（２０６）は、ＤＭメタデータ送信パケット（例えばパケットの最初の９９２ビットなど）からＣＲＣ値を算出し、算出されたＣＲＣ値が伝えられたＣＲＣ値（例えばＤＭメタデータ送信パケットの後続バイト中など）と合致するかを決定し得る。もしＣＲＣ値が合致しないならば、ＤＭメタデータ抽出器（２０６）は、ＤＭメタデータ送信パケットが破損しているものとして破棄し、同じビデオフレーム（例えばビデオフレーム中のビットフィールドの異なる部分または異なる部分集合など）、または異なるビデオフレーム（例えば破損コピーを含んだビデオフレームの１ビデオフレーム前か後ろなど）に保持された、同じＤＭメタデータ送信パケットの別のコピーを取り出すことを試みるように構成されてもよい。

【0055】

本発明の１つ以上の実施形態において、ＤＭメタデータバッファ（２０８）は、バルクメモリコピー動作、バルクメモリムーブ動作、高速なメモリ埋め動作などを含むがこれらに限定されない、比較的高速な映像処理動作を扱うよう構成されたメモリ空間に相当する。ＤＭメタデータバッファ（２０８）は、静的および／または動的なメモリ割り当てをサポートするように構成され得る。ＤＭメタデータバッファ（２０８）は、符号化ビデオ信号（１１２）から最初に復号化された１つ以上のビデオフレームの全ビットフィールドを保持するためのビデオフレームバッファをさらに含んだビデオメモリの、一部であってもよい。符号化ビデオ信号（１１２）から復号化されたビデオフレームは、ＹＣｂＣｒ色空間やＲＧＢ色空間などを含むがこれらに限定されない、様々な色空間のうちの１つに関連し得る。符号化ビデオ信号（１１２）から復号化されたビデオフレームは、４：４：４サンプリングフォーマット、４：２：２サンプリングフォーマット、４：２：０サンプリングフォーマットなどを含むがこれらに限定されない、様々なサンプリングフォーマット（例えばクロマサンプリングフォーマットなど）のうちの１つに関連し得る。

【0056】

一実施形態例において、ビデオ描画器（２１０）は、符号化ビデオ信号（１１２）から復号化された１つ以上のビデオフレームから、基準コード値（例えばあるビデオフレームのうちのいくつかの画素における特定のビット値を欠いたもの、１つ以上の走査線の画素の最下位ビット値を欠いたものなど）を取り出し、基準コード値にディスプレイマネジメント動作を適用（基準コード値中のコンポーネント画素値をマッピング後のコンポーネント画素値にマッピングすることを含む）し、マッピング後のコンポーネント画素値に基づいて、映像描画動作を実行し、ビデオフレーム中の基準コード値によって表される画像を描画するために用いられ得る映像表示信号（２０２）を生成するように構成された、ソフトウェアおよび／またはハードウェアに相当する。本明細書に記載のメディアシンクシステムは、ＤＭメタデータを用いて、本明細書に記載の技術を実装しない他のアプローチよりも高いダイナミックレンジ、広い色域、細やかな知覚可能な画像ディテールなどを備えた高品質ビデオ画像を描画することができる。

【0057】

５．ＤＭメタデータを送信および受信するためのアルゴリズム
ディスプレイマネジメント動作を実行するための技術は、メディアシンクシステム（例えば図２の２００など）を通じて、ターゲットディスプレイ上に実装され得る。符号化ビデオ信号（例えば図１および図２の１１２など）は、メディアシンクシステム（２００）とともに動作するかあるいはその一部であってもよいターゲットディスプレイの、外側において生成されることができる。符号化ビデオ信号（１１２）は、ディスプレイマネジメント動作に必要なＤＭメタデータとともに、映像リンクを介して（例えばＨＤＭＩリンクなど）メディアシンクシステム（２００）に送信され得る。

【0058】

図３Ａは、ＤＭメタデータをメディアソースシステム（例えば図１の１００など）からメディアシンクシステム（例えば図２の２００など）へ送信する、アルゴリズムまたは処理フローの例を示す。いくつかの実施形態例において、１つ以上のコンピューティングデバイスまたは構成要素（例えばメディアソースシステム１００、ソースビデオ受信器１０４、ビデオフレーム発生器１０６、ビデオエンコーダ１１０など）が、この処理フローを実行し得る。

【0059】

例示目的のみとしてであるが、ビデオフレーム発生器（１０６）は、１つ以上のビデオフレームの基準コード値および、基準コード値に対してディスプレイマネジメント動作を行うために用いられるＤＭメタデータを受け取る。基準コード値およびＤＭメタデータは、ソースビデオ受信器（例えば図１の１０４など）によって、ソースビデオ信号（１０２）から復号化されてもよい。

【0060】

ブロック３０２において、ビデオフレーム発生器（１０６）は、前記基準コード値を有する１つ以上のビデオフレームをフレームバッファ（例えばＹＣｂＣｒ ４：２：２フレームバッファなど）に格納し、ＤＭメタデータをＤＭメタデータバッファ（例えば図１のビデオメモリ１０８などにおいて）に格納する。ＤＭメタデータは、Ｎバイトを占め得る。ある態様例において、ＤＭメタデータバッファ内のＤＭメタデータの１つ以上の（例えば埋まっていないなどの）部分を、順番にして１つ以上の（例えば埋められていないなどの）ＤＭメタデータ送信パケットのペイロード中に、例えばバイト境界、ワード境界などに従って埋め込む。

【0061】

ブロック３０４において、ビデオフレーム発生器（１０６）は、１つ以上のＤＭメタデータ送信パケットに対し、ＮバイトのＤＭメタデータを保持するためのメモリ（例えば図１のビデオメモリ１０８などにおいて）を割り当てる。いくつかの実施形態において、１つのＤＭメタデータパケットは、最大Ｍバイトを保持できるペイロードを含んでいてもよい。

【0062】

ブロック３０６において、ビデオフレーム発生器（１０６）は、割り当てられたＤＭメタデータ送信パケットのうちの最後のＤＭメタデータ送信パケットが埋められたか否かを判断する。最後のＤＭメタデータ送信パケットが埋められていないと判断すると（図３Ａの「ｎｏ」）、処理フローはブロック３０８に移る。

【0063】

ブロック３０８において、ビデオフレーム発生器（１０６）は、１つ以上の残りの埋められていないＤＭメタデータ送信パケットのうちの１番目のペイロードを、ＤＭメタデータバッファ中のＤＭメタデータの１つ以上の残りの埋まっていない部分のうちの１番目によって埋める。

【0064】

ブロック３１０において、ビデオフレーム発生器（１０６）は現在処理中のパケット（ペイロードがブロック３０８において埋められたＤＭメタデータ送信パケット）のヘッダーを設定／ポピュレートし、現在処理中のパケット（例えばパケットの最初の９９２ビットなど）からＣＲＣ値（例えばＣＲＣ−３２値など）を算出し、現在処理中のパケットの後尾（例えば最後の４つの後続バイトなど）にＣＲＣ値を格納する。そして処理フローはブロック３０６に移る。

【0065】

もし最後のＤＭメタデータ送信パケットが埋められていると判断すると（図３Ａの「ｙｅｓ」）、処理フローはブロック３１２に移り、ビデオフレーム発生器（１０６）が、フレームバッファに格納された１つ以上のビデオフレームの複数のビットフィールドに、ＤＭメタデータ送信パケットの各々を埋める。ＤＭメタデータ送信パケットの埋め込みのために、特定のビットフィールド（例えばクロマ画素値の最下位ビットなど）が選択されてもよい。

【0066】

ブロック３１４において、メディアソースシステム（１００）は、フレームバッファ内のビデオフレームを下流デバイス（例えば図２のメディアシンクシステム２００など）へ、例えば符号化ビデオ信号（１１２）として、映像リンク（例えばＨＤＭＩ、ＬＶＤＳ、Ｖｘ１、ＨＤ−ＳＤＩなど）を介して送信する。

【0067】

図３Ｂは、ＤＭメタデータをメディアソースシステム（例えば図１の１００など）からメディアシンクシステム（例えば図２の２００など）によって受け取る、アルゴリズムまたは処理フローの例を示す。いくつかの実施形態例において、１つ以上のコンピューティングデバイスまたは構成要素（例えばメディアシンクシステム２００、符号化ビデオ受信器２０４、ＤＭメタデータ抽出器２０６、ビデオ描画器など）が、この処理フローを実行し得る。

【0068】

ブロック３５２において、メディアシンクシステム（２００）は、１つ以上のビデオフレーム（例えばＹＣｂＣｒ ４：２：２フレームなど）をフレームバッファ（例えばメディアシンクシステム２００のビデオメモリなど）に格納する。ビデオフレームは、映像リンク（例えばＨＤＭＩ、ＬＶＤＳ、Ｖｘ１、ＨＤ−ＳＤＩなど）を介して受け取った符号化ビデオ信号（１１２）から、メディアシンクシステム（２００）によって復号化されてもよい。

【0069】

ブロック３５４において、メディアシンクシステム（２００）はフレームバッファ内のビデオフレームの複数の画素から、１つ以上のＤＭメタデータ送信パケットを抽出する。いくつかの実施形態において、ＤＭメタデータパケットは、最大Ｍバイトを保持できるペイロードを含んでいてもよい。１つ以上のＤＭメタデータ送信パケットの各々は、前記複数の画素のうち選択された画素（例えば１０２４画素など）の各グループにあってもよい。複数の画素のうち選択されたビットフィールド（例えばクロマチャンネルの最下位ビットなど）を、ビデオフレーム中の１つ以上のＤＭメタデータ送信パケットを保持するために用い得る。

【0070】

ブロック３５６において、メディアシンクシステム（２００）は、ＤＭメタデータ送信パケットのペイロードからＤＭメタデータを抽出する。

【0071】

いくつかの実施形態において、メディアシンクシステム（２００）は、抽出されたＤＭメタデータ送信パケットに対してＣＲＣテストを実行することにより、抽出されたＤＭメタデータ送信パケットにエラーが存在するか否かを検出する。もしＣＲＣテストにおいて検出されたエラーがあれば、メディアシンクシステム（２００）は、ＤＭメタデータ送信パケットの複製／冗長的コピーをビデオフレームから抽出するように構成される。もしＣＲＣテストによって検出されたエラーが存在しなければ、メディアシンクシステム（２００）は、ビデオフレーム中のＤＭメタデータ送信パケットの複製／冗長的コピーをスキップするように構成される。

【0072】

いくつかの実施形態において、ＤＭメタデータは、映像描画動作においてＤＭメタデータに少なくとも部分的に基づいたディスプレイマネジメント動作を行おうとする、対応するビデオフレームに対して精確に同期されている。いくつかの実施形態において、このＤＭメタデータを対応するビデオフレームの基準コード値と同期的に受信側デバイスへ送信することは、映像リンクを介して符号化ビデオ信号を送信する前に、符号化ビデオ信号における同じビデオフレームまたは互いに隣接したビデオフレーム中にＤＭメタデータとともに基準コード値を埋め込むことによって達成される。このようにしてＤＭメタデータは、対応する基準コード値と同時に（例えば同じビデオフレームにおいてや、対応するビデオフレームの前のビデオフレームにおいてなど）、あるいは実質的に同時に（例えば対応するビデオフレームからある固定の時間ウィンドウ内のビデオフレームにおいてなど）、受信側デバイスのディスプレイマネジメントモジュールに到達する。

【0073】

いくつかの実施形態において、符号化ビデオ信号においてあるタイムスタンプＴを有するＤＭメタデータが、タイムスタンプＴ−１、Ｔ−２などを有するビデオフレームバッファの基準コード値とともに送信されることにより、ディスプレイマネジメントモジュールはＤＭメタデータを処理（初期化動作などを含むがこれに限定されない）するための十分な時間を有し得る。

【0074】

６．ＨＤＭＩ映像リンク
本明細書に記載の技術は、ＨＤＭＩ映像リンク（例えばＨＤＭＩ１．４映像リンク、ＨＤＭＩ２．０映像リンクなど）を介したディスプレイマネジメントメタデータ送信をサポートする態様例によって、さらに例示することができる。映像リンク規格に関する一般的な情報は、以下を含むがこれらに限定されない、様々な文献において見出すことができる。すなわち、ＣＥＡ−８６１−Ｆ，Ａ ＤＴＶ Ｐｒｏｆｉｌｅ ｆｏｒ Ｕｎｃｏｍｐｒｅｓｓｅｄ Ｈｉｇｈ Ｓｐｅｅｄ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅｓ，Ｄｒａｆｔ Ｖ１５，７／３１／１２、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．４ａ、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ２．０ Ｒ１０、Ｆｏｒ Ｔｅｌｅｖｉｓｉｏｎ−Ｔｒａｎｓｐｏｒｔｉｎｇ ＭＰＥＧ−２ Ｒｅｃｏｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｔｈｒｏｕｇｈ ４：２：２ Ｃｏｍｐｏｎｅｎｔ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅｓ，ＳＭＰＴＥ ３１９Ｍ−２０００など。これらをその全体について、本願において元々開示したかの如く援用する。

【0075】

いくつかの実施形態において、ＨＤＭＩ規格は、本明細書に記載の技術によって、符号化ビデオ信号を、メディアソースシステム（例えばセットトップボックス、図１のメディアソースシステム１００など）からメディアシンクシステム（例えばＨＤＭＩインターフェースを有するＴＶ、図２のメディアシンクシステム２００など）へと送るように拡張されることができる。本明細書に記載の技術は、ＨＤＭＩ規格において明示されたビデオフレームフォーマットおよび送信プロトコルを、ＨＤＭＩ映像リンクがこれらのビデオフレームフォーマットおよび送信プロトコルに従ってＤＭメタデータを基準コード値とともにビデオフレームの画素中において送信するために、利用することができる。

【0076】

いくつかの実施形態において、本明細書に記載のメディア処理装置は、ＨＤＭＩバージョン１．４ａ以上に準拠しており、プログレッシブタイミングのＨＤおよびＵＨＤ解像度（例えばフレームレート毎秒６０フレーム（ｆｐｓ）までのＨＤ解像度、フレームレート３０ｆｐｓまでの４Ｋ×２Ｋ解像度など）をサポートする。いくつかの実施形態において、本明細書に記載のメディア処理装置はＨＤＭＩバージョン２．０に準拠し、フレームレート６０ｆｐｓまでの４Ｋ×２Ｋ解像度をサポートする。本明細書で用いられる「準拠する（ｃｏｍｐｌｉａｎｃｅ）」の語は、映像リンク規格（例えばＨＤＭＩ１．４ａ、ＨＤＭＩ２．０など）において明示されたビデオフォーマットに準拠したビデオフレームに対して、ビデオフレームのビットフィールドを、映像リンク規格が本来は画素値のみをビデオフレームのこれらのビットフィールドに格納するように指定しているにも関わらず、基準コード値およびＤＭメタデータでポピュレート、格納、埋め、送信、受信、復号化などすることを指す。

【0077】

いくつかの実施形態において、本明細書に記載のメディア処理装置は、映像リンク規格において明示された、様々なビデオフレームフォーマットのうちの１つ（例えばＹＣｂＣｒ ４：２：２ビデオフレームなど）ように構成される。本明細書に記載のビデオフレームフォーマットは、様々なビット深度のうちの１つの色値（例えば１２＋ビット／カラーなど）を保持し得る。

【0078】

いくつかの実施形態において、本明細書に記載のメディア処理装置は、映像リンク規格において明示された信号送信プロトコルを用いるように構成される。いくつかの実施形態において、メディアソースシステムは、下流デバイスの能力情報（例えば下流デバイスから受け取ったＥ−ＥＤＩＤ（ｅｎｈａｎｃｅｄ ｅｘｔｅｎｄｅｄ ｄｉｓｐｌａｙ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｄａｔａ）など）を読み取り、下流デバイスがサポートするオーディオおよびビデオフォーマットのみを送るように構成される。いくつかの実施形態において、本明細書に記載のメディアシンクシステムは、ビデオフレームの画素中において基準コード値とともに送られたＤＭメタデータで動作することが可能であることを、Ｅ−ＥＤＩＤのＨＤＭＩのベンダー固有のデータブロックに１ビットフラグをセットすることにより、示す。

【0079】

逆に、本明細書に記載の技術を実装する下流デバイスは、上流デバイスの能力情報（例えば上流デバイスから受け取ったＩｎｆｏＦｒａｍｅの内など）を読み出し、受け取った音声および映像データを適切に処理するように構成され得る。いくつかの実施形態において、メディアソースシステムは、ＨＤＭＩのベンダー固有のＩｎｆｏＦｒａｍｅに１ビットフラグをセットすることによって、本明細書に記載の符号化ビデオ信号の送信の合図を送る。

【0080】

いくつかの実施形態において、ＤＭメタデータおよび基準コード値をビデオフレームの画素中で処理および送信するための能力情報は、映像リンク規格によって明示された、情報フレーム、データブロックなど中の１つ以上の予約ビットに設定される。

【0081】

いくつかの実施形態において、ビデオフレーム中のＤＭメタデータを送信する前に、メディアソースシステム（例えば図１の１００など）は、メディアシンクシステム（例えば図２の２００など）によって与えられた能力指標を読み出す。もしメディアシンクシステムが、ビデオフレームに埋め込まれたＤＭメタデータをサポートする能力を示していなければ、メディアソースシステムは、ＤＭメタデータをビデオフレームに埋め込まないように構成されてもよく、代わりにメディアソースシステムは、本明細書に記載のＤＭ動作を行うことなく下流デバイスによって復号化され描画されることができる画素値を用いてビデオフレームをポピュレートするように構成されてもよい。もしメディアシンクシステムが、ビデオフレームに埋め込まれたＤＭメタデータをサポートする能力を示すなら、メディアソースシステムはさらに、メディアシンクシステムがＤＭメタデータで動作するディスプレイアプリケーション設定にあるか否かを決定するように構成されてもよい。もしメディアシンクシステムが、そのディスプレイアプリケーション設定がＤＭメタデータで動作することを示していれば、メディアソースシステムは引き続き、相互にサポートされているビデオフレームフォーマット（例えばＹＣｂＣｒ ４：２：２フレームなど）と相互にサポートされているビデオタイミング方式（例えば３０ｆｐｓ、６０ｆｐｓなど）とを選択し、サポートされたビデオフレームフォーマットのビデオフレーム中にＤＭメタデータを生成／符号化し、相互にサポートされているビデオフレームフォーマットおよび相互にサポートされているビデオタイミング方式を有するビデオフレームが、ＤＭメタデータとともに符号化されていることの指標を符号化ビデオ信号に設定し、この符号化ビデオ信号を、指標とともにメディアシンクシステムに送ってもよい。メディアシンクシステムは、ビデオフレームに埋め込まれたＤＭメタデータを抽出し、同じビデオフレームから抽出された基準コード値にＤＭ動作を適用し、ディスプレイアプリケーション設定における基準コード値によって表されたビデオ画像を描画する。いくつかの実施形態において、ＤＭ動作は、マッピング関数を基準コード値に適用することで、マッピング後の輝度値およびクロマ値を、描画された画像における知覚可能な画像ディテールを保存しながら比較的ハイダイナミックレンジおよび比較的広色域で導出することを含むが、これに限定されない。

【0082】

いくつかの実施形態においては、複数のビデオフレーム（例えば１シーンなど）が、１セットのＤＭメタデータを共有する。いくつかの実施形態においては、１つ以上のビデオフレームのそれぞれ個々のビデオフレームが、自身のためのＤＭメタデータのセットを有する。ＤＭメタデータは、その対応するビデオフレーム（単数または複数）に同期されており、この対応するビデオフレーム（単数または複数）の基準コード値は、ＤＭメタデータに少なくとも部分的に基づいたＤＭ動作による動作を受ける。

【0083】

いくつかの実施形態において、対応するビデオフレームについてＤＭメタデータの新しいセットが下流デバイスに送信されるたびに、新たなＤＭメタデータ識別子（例えば順にインクリメントされる数字など）が用いられる。いくつかの実施形態において、ＤＭメタデータ送信パケットは２つのフィールドを含む。すなわち、ＤＭメタデータ送信パケットに保持される第１のＤＭメタデータのセットのための第１のＤＭメタデータ識別子および、ＤＭメタデータ送信パケットを保持するビデオフレームに対するＤＭ動作に用いられる、第２のＤＭメタデータのセットのための第２のＤＭメタデータ識別子である。従って、もし第１および第２のＤＭメタデータ識別子が同じであれば、そのＤＭメタデータのセットが、ＤＭメタデータ送信パケットを保持するビデオフレームに対するＤＭ動作に用いられる。そうでなければ、第１のＤＭメタデータのセットが、第１のＤＭメタデータ識別子によって特定されている他のビデオフレーム（例えば後続のビデオフレームなど）のためのＤＭ動作に用いられる（第１のＤＭメタデータ識別子は、当該他のビデオフレームに対して第２のＤＭメタデータ識別子となる）。

【0084】

ＤＭメタデータ送信パッケージは、ＤＭメタデータパケットを保持している同じビデオフレームにおいて、送信されているＤＭメタデータがあるか否かを示すために用いられる、ヘッダーフィールドを保持していてもよい。他の情報（メタデータバージョン情報、メタデータタイプ情報、パケットタイプ情報などを含むがこれらに限定されない）が、ＤＭメタデータ送信パケットの一部分として、例えばパケットのヘッダーに含まれていてもよい。いくつかの実施形態において、パケットタイプ情報は、このＤＭメタデータ送信パケットが、ＤＭメタデータの１セット（全体）を保持している１個のパケットなのか、このパケットは、ＤＭメタデータのセットを保持する複数のパケットのうちの１番目のパケットなのか、あるいはこのパケットは複数のパケットのうちの中間パケットなのか、それともこのパケットが複数のパケットのうちの最後のパケットなのかを示すために、用いられ得る。

【0085】

７．基準コード値およびＤＭデータのトンネル処理
いくつかの実施形態において、本明細書に記載のソースシステムは、基準コード値およびＤＭメタデータを、あるビデオ信号フォーマットに対応するビデオ信号に符号化し、当該ビデオ信号をその同じビデオ信号フォーマットで、受信側のシンクシステムなどに送信するように構成される。

【0086】

いくつかの実施形態において、本明細書に記載のソースシステムは、基準コード値およびＤＭメタデータを第１のビデオ信号フォーマットに対応する第１のビデオ信号に符号化し、第１のビデオ信号フォーマットの第１のビデオ信号の色チャンネル（例えば第１の色空間のコンポーネントなど）を、第２のビデオ信号フォーマットの第２のビデオ信号にマッピングし、第２のビデオ信号フォーマットの第２のビデオ信号を受信側のシンクシステムなどに送信するように構成される。

【0087】

図６Ａに示すシステム構成例は、ソースシステム６０２および、ビデオ信号通信路６０６を介して、基準コード値およびＤＭメタデータが符号化された第１のビデオ信号フォーマットとは異なる第２のビデオ信号フォーマットのビデオ信号を通信する、シンクシステム６０４を備えている。いくつかの実施形態において、図６Ａおよび図６Ｂのソースシステム（６０２）は、ソースシステム（１００）と同一であるか、図１のソースシステム（１００）の一部または全ての構成要素を実現していればよい。いくつかの実施形態において、図６Ａおよび図６Ｂのシンクシステム（６０４）は、シンクシステム（２００）と同一であるか、図２のシンクシステム（２００）の一部または全ての構成要素を実現していればよい。

【0088】

例示として、第１のビデオ信号フォーマットは１２ビットＹＣｂＣｒビデオ信号フォーマットであり、第２のビデオ信号フォーマットは８ビットＲＧＢビデオ信号フォーマットであり、ビデオ信号通信路（６０６）は、幅広く様々なメディアデバイスでサポートされたＨＤＭＩリンクであってもよい。いくつかの実施形態において、第１のビデオ信号フォーマットは、後世のデバイスにより実現されるものである。いくつかの実施形態において、第２のビデオ信号フォーマットは、幅広く様々な以前の（例えば旧式など）および／または後世のデバイスにより実現される。

【0089】

ソースシステム（６０２）は、基準コード値およびＤＭメタデータを第１のビデオ信号フォーマットのビデオ信号に符号化するように構成され得る。ある一例のケースにおいては、ソースシステム（６０２）は、基準コード値およびＤＭメタデータを第１のビデオ信号フォーマットのビデオ信号に符号化することをサポートしないようなソフトウェア、ファームウェア、ハードウェアなどの組み合わせとして、当初リリースされたものである。例えば、ソースシステム（６０２）は、画素値を第２のビデオ信号フォーマット（例えば８ビットＲＧＢビデオフォーマットなど）のビデオ信号に符号化し、この第２のビデオ信号フォーマットのビデオ信号を（例えば８ビットＨＤＭＩリンクなどを介して）送信などするように、当初構成されていてもよい。後に、ソフトウェアアップデート、ファームウェアアップデートその他を受け取りインストールしたとき、ソースシステム（６０２）は、基準コード値およびＤＭメタデータを第１のビデオ信号フォーマットのビデオ信号に処理し符号化する能力を得る。

【0090】

シンクシステム（６０４）は、第１のビデオ信号フォーマットのビデオ信号から、基準コード値およびＤＭメタデータを復号化するように構成され得る。ある一例のケースにおいては、シンクシステム（６０４）は、第１のビデオ信号フォーマットのビデオ信号から基準コード値およびＤＭメタデータを復号化することをサポートしないようなソフトウェア、ファームウェア、ハードウェアなどの組み合わせとして、当初ユーザーにリリースされたものである。例えば、シンクシステム（６０４）は、第２のビデオ信号フォーマット（例えば８ビットＨＤＭＩリンクなどを介して）のビデオ信号を受け取り、第２のビデオ信号フォーマット（例えば８ビットＲＧＢフォーマットなど）のビデオ信号から画素値を復号化などするように、当初構成されていてもよい。後に、ソフトウェアアップデート、ファームウェアアップデートその他を受け取りインストールしたとき、シンクシステム（６０４）は、第１のビデオ信号フォーマットのビデオ信号から基準コード値およびＤＭメタデータを復号化するように構成されることとなる。

【0091】

いくつかの実施形態においては、ソースシステム（６０２）およびシンクシステム（６０４）間の通信路は、第１のビデオ信号フォーマットで符号化されたビデオ信号の送信をサポートしない。これは、ソースシステム（６０２）、シンクシステム（６０４）、映像再生環境、ソースシステム（６０２）およびシンクシステム（６０４）間の通信路中の１つ以上の中間デバイスなどのうち１つ以上に関連した、ソフトウェア、ファームウェア、ハードウェアなどのうち１つ以上の有する、１つ以上の制約に起因し得る。

【0092】

代わりに、ソースシステム（６０２）およびシンクシステム（６０４）間の通信路は、第２のビデオ信号フォーマットのビデオ信号の送信をサポートしていてもよい。第２のビデオ信号フォーマットは、幅広く様々なセットトップボックス、タブレット型コンピュータ、ゲームコンソール、ディスプレイ装置などにおいてサポート（例えば通常一般的になど）されたビデオ信号フォーマットの任意の１つであってもよいが、これらに限定されない。

【0093】

本明細書に記載の技術は、第１のビデオ信号フォーマットで符号化された基準コード値およびＤＭメタデータを有するビデオ信号を、第１のビデオ信号とは異なるビデオ信号フォーマット（例えば第２のビデオ信号フォーマットなど）をサポートするビデオ信号通信路を介して、送信する方法を提供するために用いられ得る。これらの技術は、一般におよび／または広く実装されているＨＤＭＩインターフェースをサポートするために用いられることができ、その結果、タブレット、ゲームコンソール、セットトップボックスなどの幅広く様々なデバイスが、本明細書に記載の基準コード値およびＤＭメタデータを用いて高品質な表示動作を行うことを可能にし得る。

【0094】

例示目的のみとしてであるが、第１のビデオ信号フォーマットは、１２ビットＹＣｂＣｒ ４：２：２（ビデオ信号）フォーマットであってもよく、一方第２のビデオ信号フォーマットは、８ビットＲＧＢ（ビデオ信号）フォーマットであってもよい。８ビットＲＧＢフォーマットは、ソースシステム（６０２）における８ビットＨＤＭＩ（例えば送信器など）インターフェース、シンクシステム（６０４）における８ビットＨＤＭＩ（例えば受信器など）インターフェース、ソースシステム（６０２）およびシンクシステム（６０４）間のビデオ信号通信路（６０６）における通信をリレーする１つ以上の中間デバイス（ＡＶＲなど）を介して確立されたビデオ信号通信路（６０６）によってサポートされる。

【0095】

図７は、１２ビットＹＣｂＣｒ ４：２：２フォーマット（本例における第１のビデオ信号フォーマット）で符号化された基準コード値およびＤＭメタデータを保持するために用いられ得る、８ビットＲＧＢフォーマット（本例における第２のビデオ信号フォーマット）の一例を示している。

【0096】

いくつかの実施形態において、ソースシステム（６０２）はまず、第１のビデオ信号（７０２）中の基準コード値を、１２ビットＹＣｂＣｒ ４：２：２フォーマットで符号化、格納、などする。色空間変換、マッピング、逆マッピング、量子化、逆量子化、ダウンサンプリング、アップサンプリングなどの動作の１つ以上を、基準コード値を１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）に符号化、格納などすることの一環として、行ってもよい。

【0097】

これに加えて、またはオプションとして、あるいは代替的に、いくつかの実施形態においては、ソースシステム（６０２）は、１２ビットＹＣｂＣｒ ４：２：２フォーマットの同じ第１のビデオ信号（７０２）におけるＤＭメタデータを、基準コード値とともに符号化、格納などする。ソースシステム（６０２）は、ＤＭメタデータをスクランブルし、スクランブルされたＤＭメタデータを、第１のビデオ信号（７０２）内の、クロマまたは色チャンネル画素値の最下位ビット値を保持するように指定された（例えばビデオ信号規格などにより）位置に格納するように構成されてもよい。本例において、基準コード値は、輝度に関連した基準コード値およびクロマに関連した基準コード値を含み得る。１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）の輝度チャンネルは、輝度に関連した基準コード値を格納してもよく、受信側のディスプレイ装置がこれらを、ＤＭメタデータを用いて少なくとも部分的に構築された、マッピング関数、マッピング曲線などに基づき、装置固有の輝度値にマッピングすることができる。１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）のクロマチャンネルは、クロマに関連した基準コード値およびスクランブルされたＤＭメタデータを格納してもよい。スクランブルされたＤＭメタデータは、第１のビデオ信号（７０２）のクロマチャンネル中の、クロマまたは色チャンネル画素値の最下位ビット値を格納するように指定された（例えばビデオ信号規格などにより）位置に格納されてもよい。

【0098】

いくつかの実施形態において、ソースシステム（６０２）は、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）を、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）にマッピングするように構成される。

【0099】

一実施形態例において、図７に示すように、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）の各輝度チャンネル（例えば１２ビットなど）サンプル（例えば「Ｙ₀」、「Ｙ₁」、「Ｙ₂」、「Ｙ₃」、「Ｙ₄」など）は、第１のサンプル部分（例えばビット３〜０など）と第２のサンプル部分（例えばビット１１〜４など）とに分割されてもよい。第１のサンプル部分（例えばビット３〜０など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の青チャンネル（例えば「Ｂ」など）の第１の部分に格納され得る。第２のサンプル部分（例えばビット１１〜４など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の緑チャンネル（例えば「Ｇ」など）に格納され得る。

【0100】

１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）の各（例えばサブサンプリングされたなどの）ＣＢクロマチャンネルサンプル（例えば「ＣＢ₀」、「ＣＢ₂」、「ＣＢ₄」など）もまた、第１のサンプル部分（例えばビット３〜０など）と第２のサンプル部分（例えばビット１１〜４など）とに分割されてもよい。第１のサンプル部分（例えばビット３〜０など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の青チャンネル（例えば「Ｂ」など）の第２の部分に格納され得る。第２のサンプル部分（例えばビット１１〜４など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の赤チャンネル（例えば「Ｒ」など）に格納され得る。

【0101】

同様に、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）の各（例えばサブサンプリングされたなどの）ＣＲクロマチャンネルサンプル（例えば「ＣＲ₀」、「ＣＲ₂」など）は、第１のサンプル部分（例えばビット３〜０など）と第２のサンプル部分（例えばビット１１〜４など）とに分割されてもよい。第１のサンプル部分（例えばビット３〜０など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の青チャンネル（例えば「Ｂ」など）の第２の部分に格納され得る。第２のサンプル部分（例えばビット１１〜４など）は、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）の赤チャンネル（例えば「Ｒ」など）に格納され得る。

【0102】

図７に示すように、ＣＢサンプル（例えば「ＣＢ₀」、「ＣＢ₂」、「ＣＢ₄」など）は、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）と同様に、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）においてＣＲサンプル（例えば「ＣＲ₀」、「ＣＲ₂」など）でインターリーブされている。

【0103】

一実施形態例において、ソースシステム（６０２）は次に、ある送信モード（これを「トンネルモード」と呼んでもよい）において、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）を、８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）として送信する。これとは対照的に、第１のビデオ信号（７０２）を８ビットＲＧＢ４：４：４フォーマットなどの別のビデオ信号フォーマットにマッピングせずに、１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）をソースシステムからシンクシステムへ送信することは、「ノーマルモード」とよばれ得る送信モードにおいて行われる。

【0104】

いくつかの実施形態において、ソースシステム（６０２）は、通信路（６０６）においてどちらの送信モードを用いているかをシンクシステム（６０４）に合図するように構成される。例えば、ソースシステム（６０２）は、広く実装されている規格準拠のメタデータ情報フレーム（例えばＨＤＭＩ Ａｕｘｉｌｉａｒｙ Ｖｉｄｅｏ Ｉｎｆｏｒｍａｔｉｏｎ（ＡＶＩ）ＩｎｆｏＦｒａｍｅなど）の１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）その他などを、特定の値（例えばＹ０＝０，Ｙ１＝０など）にセットし得る。ソースシステム（６０２）は、規格準拠のメタデータ情報フレームを含む１つ以上のデータパケットを、シンクシステム（６０４）に送ることにより、通信路（６０６）がトンネルモードで動作中であることを合図し得る。

【0105】

いくつかの実施形態において、シンクシステム（６０４）は、どの送信モードが通信路（６０６）中であるかを検出するように構成される。例えば、シンクシステム（６０４）は、１つ以上のデータパケットを受け取り、その１つ以上のデータパケット中の、規格準拠のメタデータ情報フレーム（例えばＨＤＭＩ ＡＶＩ ＩｎｆｏＦｒａｍｅなど）の１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）その他を読み出すなどし得る。シンクシステム（６０４）は、規格準拠のメタデータ情報フレーム（例えばＨＤＭＩ ＡＶＩ ＩｎｆｏＦｒａｍｅなど）の１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）その他に特定の値（例えばＹ０＝０，Ｙ１＝０など）があるか否かを決定することにより、通信路（６０６）がトンネルモードで動作中であるか否かを決定できる。

【0106】

いくつかの実施形態において、通信路（６０６）がトンネルモードで動作中であることを決定すると、シンクシステム（６０４）は、通信路（６０６）から受け取った８ビットＲＧＢ４：４：４フォーマットの第２のビデオ信号（７０４）を１２ビットＹＣｂＣｒ ４：２：２フォーマットの第１のビデオ信号（７０２）にマッピングし戻し、１２ビットＹＣｂＣｒ ４：２：２フォーマットから基準コード値およびＤＭメタデータを抽出するなどする。８ビットＲＧＢ４：４：４フォーマットから１２ビットＹＣｂＣｒ ４：２：２フォーマットへのマッピングは、例えば、第１のビデオ信号（７０２）および第２のビデオ信号（７０４）に別々のフレームバッファを用い、８ビットＲＧＢ４：４：４フォーマットまたは１２ビットＹＣｂＣｒ ４：２：２フォーマットなどの１つ以上中のバイトまたはビット位置を指す、１つ以上のデータポインタを用いて行ってもよい。

【0107】

いくつかの実施形態において、シンクシステム（６０４）は、ＤＭメタデータを逆スクランブルし、（例えば逆スクランブルなどされた）ＤＭメタデータなどに基づき、基準コード値に対してディスプレイマネジメント動作を行い得る。

【0108】

８．ソース・シンク間の明示的な信号送信の不在
いくつかの実施形態において、本明細書に記載のソースシステムおよびシンクシステムは１つ以上の（例えば規格準拠、独自、またはその他などの）ハンドシェークプロトコルを行って、ある通信路が、本明細書に記載の基準コード値およびＤＭメタデータで符号化されたビデオ信号を保持するものであるか否かを決定する。ソースシステムおよびシンクシステムは、最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などするために用いられ得るメタデータ送信メカニズム（例えば規格準拠のメタデータ送信メカニズム、独自の送信メカニズムなど）を用いて、１つ以上のハンドシェークプロトコルのプロトコルメッセージをやり取りし得る。例えば、シンクシステムは、メタデータ送信メカニズムを用いてシンクシステムからソースシステムに送られたベンダー固有のデータブロック（ＶＳＤＢ）を介して、本明細書に記載の基準コード値およびＤＭメタデータを処理する能力を自身が有しているものとして識別してもよい。一方、ソースシステムは、この通信路が、本明細書に記載の基準コード値およびＤＭメタデータを保持するべきものであると、メタデータ送信メカニズムを用いてソースシステムからシンクシステムに送られたベンダー固有の情報フレームまたはＩｎｆｏＦｒａｍｅ（ＶＳＩＦ）を介して、明示し得る。

【0109】

このようなメタデータ送信メカニズムは、すべての映像再生環境で利用可能ではない場合がある。例えば、ソースシステムおよびシンクシステム間のＡＶＲ（例えば旧式のデバイスなど）は、そのようなメタデータ送信メカニズムをサポートしていない場合がある。

【0110】

図６Ｂは、ソースシステム（例えば６０２など）およびシンクシステム（例えば６０４など）間の通信路（例えば６０６など）が、オーディオビデオレシーバー（ＡＶＲ）などの１つ以上の第３のデバイス（例えば６０８など）を介してリレーされる、システム構成を示している。通信路（６０６）は、複数の通信リンク（例えば６１０−１、６１０−２など）を含む。ソースシステム（６０２）は、図１のメディアソースシステム（１００）における構成要素の一部または全てを実現し得る。シンクシステム（６０４）は、図２のメディアシンクシステム（２００）における構成要素の一部または全てを実現し得る。

【0111】

いくつかの実施形態において、ソースシステム（６０２）およびシンクシステム（６０４）間の通信をリレーする１つ以上の第３のデバイス（６０８）のうちの少なくとも１つは、最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などするために用いられ得るメタデータ送信メカニズム（例えば規格準拠のメタデータ送信メカニズム、独自の送信メカニズムなど）を、サポートしない。これは、通信路（６０６）中のＡＶＲが、プロトコルパケット（例えばＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＩｎｆｏＦｒａｍｅパケットなど）を落とす場合や、ソースシステム（６０２）がフラグ（例えばＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＩｎｆｏＦｒａｍｅにおけるＥＤＲ＿Ｖａｌｉｄビットなど）の設定を許可しない場合などに該当する。

【0112】

いくつかの実施形態において、シンクシステム（６０４）は本明細書に記載の技術を実装することにより、ソースシステム（６０２）およびシンクシステム（６０４）が最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などすることを可能にするようなメタデータ送信メカニズムが、通信路（６０６）を介して利用可能であるか否かに関わらず、ソースシステム（６０２）から受け取った基準コード値およびＤＭデータに基づき特定のディスプレイマネジメント動作を実行する。いくつかの実施形態において、ソースシステム（６０２）は、本明細書に記載の技術を実装することにより、シンクシステムがソースシステム（６０２）から受け取った基準コード値およびＤＭデータに基づき特定の表示動作を実行することが可能か否かを検出する。

【0113】

いくつかの実施形態において、ソースシステム（６０２）が本明細書に記載の基準コード値およびＤＭメタデータを送り始めることを決定すると、ソースシステム（６０２）は、第１のビデオ信号フォーマット（例えば１２ビットＹＣｂＣｒ ４：２：２フォーマットなど）に対応するフレームバッファ（例えば１２ビットＹＣｂＣｒ ４：２：２ ビデオバッファなど）に、ＤＭメタデータを埋め込む。いくつかの実施形態においては、ソースシステム（６０２）は、第１のビデオ信号フォーマットに対応するフレームバッファの内容が、第１のビデオ信号フォーマットの第１のビデオ信号としてシンクシステム（６０４）に移動されるノーマルモードで、フレームバッファの内容を送信する。いくつかの実施形態においては、ソースシステム（６０２）は、第１のビデオ信号フォーマットに対応するフレームバッファの内容が、第２のビデオ信号フォーマット（例えば８ビットＲＧＢ４：４：４フォーマットなど）にマッピングされるトンネルモードで、フレームバッファの内容を送信する。第２のビデオ信号フォーマットであるマッピング後の内容は、第２のビデオ信号フォーマットの第２のビデオ信号として、シンクシステム（６０４）に移動される。

【0114】

いくつかの実施形態において、ソースシステム（６０２）は、ＤＭメタデータのビット値の一部または全部にわたって、１つ以上のＣＲＣ値（例えばＣＲＣ−３２値など）を算出し、シンクシステム（６０４）に送信すべきＤＭメタデータをスクランブル（例えばクロマの最下位ビット値いくつか、あるいは色チャンネル画素値など）し、ＤＭメタデータの一部としてあるいはＤＭメタデータとともに、ＣＲＣ値をシンクシステム（６０４）へ送信するなどする。

【0115】

いくつかの実施形態において、シンクシステム（６０４）は、ビデオ信号が本明細書に記載の基準コード値およびＤＭメタデータを保持しているか否かを決定するために、例えばＨＤＭＩ受信器インターフェースに対してレディ状態に設定される。

【0116】

いくつかの実施形態において、シンクシステム（６０４）は、通信路（６０６）がトンネルモードで動作中であるか否かを決定する。例えば、シンクシステム（６０４）は、（例えば規格準拠のなど）メタデータ情報フレーム（例えばＨＤＭＩ ＡＶＩ ＩｎｆｏＦｒａｍｅなど）において、１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）などに特定の値（例えばＹ０＝０，Ｙ１＝０など）が存在するか否かを決定する。もし存在するならば、シンクシステム（６０４）は、通信路（６０６）がトンネルモードで動作中であると決定し、このトンネルモードにおいて、ソースシステム（６０２）は、可能性として（例えばＣＲＣ値に基づくさらなる検査を待っている間など）基準コード値およびＤＭメタデータを１２ビットＹＣｂＣｒ ４：２：２フォーマットなどの第１のビデオ信号フォーマットにある第１のビデオ信号として格納し、第１のビデオ信号を８ビットＲＧＢ４：４：４フォーマットなどの第２のビデオ信号にマッピングし、通信路（６０６）を介して第２のビデオ信号をシンクシステム（６０４）へ送信するなどし得る。

【0117】

一方、もし特定の値（例えばＹ０＝０，Ｙ１＝０など）が１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）などに存在しないと決定された場合、シンクシステム（６０４）は、通信路（６０６）がノーマルモードで動作中であると決定し、このノーマルモードにおいて、ソースシステム（６０２）は、可能性として（例えばＣＲＣ値に基づくさらなる検査を待っている間など）基準コード値およびＤＭメタデータ１２ビットＹＣｂＣｒ ４：２：２フォーマットなどの第１のビデオ信号フォーマットの第１のビデオ信号として格納し、第１のビデオ信号を通信路（６０６）を介してシンクシステム（６０４）へ送信などし得る。

【0118】

いくつかの実施形態において、シンクシステム（６０４）は、通信路（６０６）が動作しているモード（例えばノーマルモード、トンネルモードなど）に対応する、抽出モードを設定する。通信路（６０６）のノーマルモードに対応する第１の抽出モードにおいて、シンクシステム（６０４）は、第１のビデオ信号フォーマットに基づいて、可能性として基準コード値を表している第１のデータ部分および可能性としてＤＭメタデータを表している第２のデータ部分を、通信路（６０６）中のビデオ信号から抽出するように構成される。通信路（６０６）のトンネルモードに対応する第２の抽出モードにおいて、シンクシステム（６０４）は、通信路（６０６）中の第２のビデオ信号フォーマットのビデオ信号をマッピング後の第１のビデオ信号フォーマットのビデオ信号（例えばフレームバッファなどを用いる）にマッピングし、第１のビデオ信号フォーマットに基づいて、マッピング後のビデオ信号から可能性として基準コード値を表している第１のデータ部分および可能性としてＤＭメタデータを表している第２のデータ部分を抽出などするように構成される。

【0119】

いくつかの実施形態において、シンクシステム（６０２）は、第２のデータ部分のビット値の一部または全部にわたって、受け取ったビデオ信号から逆スクランブルされたＤＭメタデータを可能性として表す１つ以上のＣＲＣ値（例えばＣＲＣ−３２値など）を算出し、受け取ったビデオ信号などから、１つ以上の可能なソースＣＲＣ値を抽出する。１つ以上の可能なソースＣＲＣ値は可能性として（例えば、可能なソースＣＲＣ値が算出されたＣＲＣ値と合致するか否かなどに基づきＣＲＣ値に基づくさらなる検査を待っている間など）、ソースシステム（６０２）により算出されたＣＲＣ値であり、ＤＭメタデータの一部としてあるいはＤＭメタデータとともに提供されるなどしてもよい。

【0120】

いくつかの実施形態において、シンクシステムは、例えば、シンクシステムによって算出された１つ以上のＣＲＣ値が、受け取ったビデオ信号から抽出された可能なＣＲＣ値の１つ以上と合致するか否かを決定することにより、ＣＲＣテストを実行する。もしシンクシステムによって算出された１つ以上のＣＲＣ値が受け取ったビデオ信号から抽出された可能なＣＲＣ値の１つ以上と合致しないと判断されれば、ＣＲＣテストは不合格である。逆にシンクシステムによって算出された１つ以上のＣＲＣ値が受け取ったビデオ信号から抽出された可能なＣＲＣ値の１つ以上と合致すると判断されれば、ＣＲＣテストは合格である。

【0121】

ＣＲＣテストが不合格であると、シンクシステム（６０４）は、ソースシステム（６０２）から受け取ったビデオ信号が本明細書に記載の基準コード値およびＤＭメタデータを保持していないと判断し、シンクシステム（６０４）が本明細書に記載の基準コード値およびＤＭメタデータに関してディスプレイマネジメント動作を行うような特定の動作モード（例えばＥＲＲ動作モードなど）に移らない。

【0122】

一方、ＣＲＣテストが合格であると、シンクシステム（６０４）は、ソースシステム（６０２）から受け取ったビデオ信号が本明細書に記載の基準コード値およびＤＭメタデータを保持すると判断し、シンクシステム（６０４）が、本明細書に記載の基準コード値およびＤＭメタデータに関してディスプレイマネジメント動作を行う特定の動作モードに移る。

【0123】

いくつかの実施形態において、シンクシステム（６０４）は、ＣＲＣテストが合格し続けるかぎり、特定の動作モードのままであり続ける。いくつかの実施形態において、シンクシステム（６０４）は、（例えば連続する）ＣＲＣテスト不合格の総数があるしきい値（例えば１２、１８、２４、３０個などの連続するビデオフレームについてＣＲＣテストが不合格であるなど）を超えると、特定の動作モードをやめる。

【0124】

いくつかの実施形態において、シンクシステム（６０４）は、ハンドシェークプロトコル的方法（例えばＨＤＭＩ ＶＳＩＦなどに基づく）を実施することに加えて、受け取ったビデオ信号が本明細書に記載の基準コード値およびＤＭメタデータを保持するか否かを決定するために、上述のＣＲＣテスト的方法を実施する。これらの方法のうち１つが他の方法の１つよりも優先される場合がある。いくつかの実施形態において、ＣＲＣテスト的方法はハンドシェークプロトコル的方法より優先される。いくつかの実施形態において、ハンドシェークプロトコル的方法はＣＲＣテスト的方法より優先される。

【0125】

９．ＥＤＲ動作のためにソースを構成
いくつかの実施形態において、シンクシステム（６０４）からのＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｂｌｏｃｋ（ＶＳＤＢ）送信は、ソースシステム（例えば６０２など）側には検出し得ない場合もある。これに加えて、またはオプションとして、あるいは代替的に、ソースシステム（６０２）は、本明細書に記載の基準コード値およびＤＭメタデータに基づいた特定のディスプレイマネジメント動作を行うことのサポートを示す、あるメタデータパケットまたはブロック中の１つ以上のビット（例えばシンクシステムから送られたＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｂｌｏｃｋ中のｓｕｐｐｏｒｔ＿ＥＤＲビットなど）のポーリングを可能にするようには構成されない場合もある。

【0126】

通信路（例えば６０６）を介してソースシステムに接続されたシンクシステム（例えば６０４など）が、基準コード値およびＤＭメタデータに関連した特定の表示動作を実行することを可能にされたデバイスであるかを決定するために、本明細書に記載の技術はソースシステム（例えば６０２など）に実装され得る。これは、ソースシステムおよびシンクシステムが動作する特定の映像再生環境において、ソースシステムおよびシンクシステムが最初のホットプラグ信号において能力情報を交換し、相互にサポートされているビデオフレームおよび／またはビデオタイミングを選択などすることを可能にするようなメタデータ送信メカニズムが、利用可能であるか否かに関わらない。

【0127】

いくつかの実施形態において、ソースシステム（６０２）は、フレームバッファ、データ格納部、メモリ空間の一部などに、１２ビットＹＣｂＣｒ ４：２：２フォーマットなどの第１のビデオ信号フォーマットで、特定の画像パターン（例えば１つ以上の画像、画像の時間的シーケンス、静止画など）を格納する。

【0128】

いくつかの実施形態において、ソースシステム（６０２）は、第１のビデオ信号フォーマットのあるビット位置（例えば第１のビデオ信号フォーマットのビデオフレームにおけるクロマサンプルのいくつかのＬＳＢ位置など）にＤＭメタデータをスクランブルする。

【0129】

いくつかの実施形態において、ソースシステム（６０２）ＥＤＲソースは、特定の画像パターン（からＤＭメタデータを格納するために使用されるビット位置の特定のビット値を引いたもの）およびＤＭメタデータを、８ビットＲＧＢ４：４：４フォーマットなどの第２のビデオ信号フォーマットの画像格納部（例えばフレームバッファなど）にパックする。

【0130】

いくつかの実施形態において、ソースシステム（６０２）は、（例えば規格準拠のなど）メタデータ情報フレーム（例えばＨＤＭＩ ＡＶＩ ＩｎｆｏＦｒａｍｅなど）における１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）などを、１つ以上の特定の値（例えばＹ０＝０，Ｙ１＝０など）に設定することにより、第２のビデオ信号フォーマットのビデオ信号が通信路（６０６）を介して送られていることを示す。

【0131】

本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を行うことが可能であれば、シンクシステム（６０４）は、（例えば規格準拠のなど）メタデータ情報フレーム（例えばＨＤＭＩ ＡＶＩ ＩｎｆｏＦｒａｍｅなど）における１つ以上のインジケータ、１つ以上のフラグ、データフィールド（例えばＹ０，Ｙ１など）など中に１つ以上の特定の値が検出されたことに少なくとも部分的に基づき、受け取った第２のビデオ信号フォーマットのビデオ信号が、予めマッピング済みの第１のビデオ信号フォーマットのビデオ信号を保持していると判断または理解するように構成されてもよい。

【0132】

シンクシステム（６０４）は、そのＤＭメタデータ抽出動作において、ＣＲＣテストを引き続き行い得る。さらに、シンクシステム（６０４）は、基準コード値を抽出し、基準コード値およびＤＭメタデータを用いて特定のディスプレイマネジメント動作を実行し得る。特定のディスプレイマネジメント動作から得られた装置固有の画素値をシンクシステム（６０４）が用いて、シンクシステム（６０４）の一部であるか、あるいはシンクシステム（６０４）と動作可能にリンクされたディスプレイ上で想定されるように、特定の画像パターンを描画／表示してもよい。

【0133】

ただし、本明細書に記載の技術を実装しないシンクシステム（例えば旧式のディスプレイなど）は、受け取った第２のビデオ信号フォーマットのビデオ信号が第２のビデオ信号フォーマット（例えば８ビットＲＧＢ４：４：４フォーマットなど）の画素値（例えばＲＧＢ画素値など）を保持していると理解し、これに従い受け取ったビデオ信号を復号化することになる。したがって、そのようなシンクシステムによって描画された画像は、前記特定の画像パターンあるいは本明細書に記載の技術を実装するシンクシステムによって描画された画像に比較して、有意な色歪みを示す。

【0134】

いくつかの実施形態において、ソースシステム（６０２）は、ユーザーからの入力と対話しこれを受け取る１つ以上の（例えばｏｖｅｒ−ｔｈｅ−ｔｏｐあるいはＯＴＴ、セットトップなど）を有するように構成される。ソースシステム（６０２）は、色歪みの無い画像パターンが見えるかどうかを、ユーザー（例えば特定の画像パターン上のテキストメッセージなどで）に確認することができる。

【0135】

ソースシステム（６０２）は、ユーザーが色歪みの無い画像パターンを見ているかを示す、ユーザーからのユーザー入力を受け取る（例えばリモートデバイスまたはソースシステム（６０２）上のボタンを押すことなどにより）。

【0136】

ユーザーに色歪みの無い画像パターンが見えることの指標（ユーザー入力から決定される）を受け取ると、ソースシステム（６０２）は、通信路（６０６）に接続されたシンクシステム（６０４）が、本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を行うことが可能であると判断する。したがってソースシステム（６０２）はこれに従い、ゼロ個、１つ、またはそれ以上のメディアプログラム（例えば本明細書に記載の基準コード値およびＤＭメタデータなどによって表される）をシンクシステム（６０４）に送信することに移行する。

【0137】

ユーザーに色歪みの無い画像パターンが見えないことの指標（ユーザー入力から決定される）を受け取ると、ソースシステム（６０２）は、通信路（６０６）に接続されたシンクシステム（６０４）が、本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を行う能力を有していないと判断し、これに従い、ゼロ個、１つ、またはそれ以上のメディアプログラム（例えば本明細書に記載の基準コード値およびＤＭメタデータ以外の画素値、ＳＤＲ画素値、ＲＧＢ画素値などにより表される）をシンクシステム（６０４）に送信することに移行、あるいは切り替える。

【0138】

いくつかの実施形態において、シンクシステムが本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を実行可能であるかどうかを示すメタデータ情報フレーム（例えばＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｂｌｏｃｋなど）を受け取ったり、そこから特定のビットをポーリングすることをサポートしないソースシステムにおいて、このＥＤＲシンクシステム検出方法は実装される。いくつかの実施形態において、シンクシステムが本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を実行可能であるかどうかを示すメタデータ情報フレーム（例えばＨＤＭＩ Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ Ｄａｔａ Ｂｌｏｃｋなど）を受け取ったり、そこから特定のビットをポーリングすることをサポートするソースシステムにおいて、このＥＤＲシンクシステム検出方法は実装される。これらの実施形態において、メタデータ情報フレームの特定のビットをポーリングする方法はＨＤＭＩ ＶＳＤＢに優先し得、ユーザー入力に部分的に基づくＥＤＲシンクシステム検出方法に優先して実装される。いくつかの実施形態において、ポーリング法は、ソースシステムおよびシンクシステムの一方または両方が、メタデータ情報フレーム中のこれらのビットをポーリングすることが可能であるか如何によらず、ある種の再生環境では、１つ以上の制約が存在し得るために可能でない場合がある。すなわち、ソースシステムおよびシンクシステム間での、メタデータ情報フレームに基づいたＥＤＲ能力決定のエンドツーエンドの信号合図をサポートしないような１つ以上の旧式の中間デバイス（例えば旧式のＡＶＲなど）などである。

【0139】

信号合図のために選ばれる特定の画像パターンは、視覚的差異が明確に見て取れる限り、まったく任意であり得る。例えば、特定の画像パターンを、ＹＣｂＣｒ色空間中のグレーフレーム（ｇｒｅｙ ｆｒａｍｅ）によって表し得る。例えば図７に従い１２ビットＹＣｂＣｒ色空間から８ビットＲＧＢフォーマットにマッピングされたそのようなグレーフレームは、ＲＧＢ空間にグレーフレームを生成せず、むしろ何らかの色を生む。したがって、テキストメッセージ（例えば白黒の）を特定の画像パターン中に用いて、そのテキストメッセージの周囲の画素において、グレー以外の「何らかの」色をユーザーが見えるかどうかを訊けばよい。もしユーザーが「Ｎｏ」と答えれば、特定の画像パターンは、本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を実行することが可能なシンクシステムにより、正確に検出されている。そうでなければ、シンクシステムは、本明細書に記載の基準コード値およびＤＭメタデータを用いた特定のディスプレイマネジメント動作を実行する能力を有していない、旧式のデバイスである。

【0140】

１０．処理フロー例
図４Ａおよび図４Ｂに、処理フロー例を示す。いくつかの実施形態において、１つ以上のコンピューティングデバイスまたはユニット（例えば図１のメディアソースシステム１００、図２のメディアシンクシステム２００など）が、処理フローを実行し得る。

【0141】

ブロック４０２において、メディアソースシステム（例えば図１の１００など）が、ａ）基準コード値および（ｂ）１つ以上のマッピング関数のための複数のマッピング関数パラメータを含むソースビデオ信号を受け取る。この複数のマッピング関数パラメータを有する１つ以上のマッピング関数を用いて、基準コード値を、ある映像描画装置に対して特異的な、マッピング後の画素値にマッピングし得る。

【0142】

ブロック４０４において、メディアソースシステム（１００）は、基準コード値および複数のマッピング関数パラメータを、１つ以上のビデオフレーム中の複数の画素に合成する。ここで、複数の画素は、映像描画装置への映像リンクを規定する１つ以上の映像リンク規格によって、画素値のみを保持するように特に指定されている。

【0143】

ブロック４０４において、メディアソースシステム（１００）は、映像リンクを介して、映像描画装置に、前記基準コード値および複数のマッピング関数パラメータを有する１つ以上のビデオフレームを送る。

【0144】

一実施形態例において、メディアソースシステム（１００）は、前記１つ以上のマッピング関数に関連するマッピング動作を、映像描画装置が実行することが可能であることを決定するように構成される。

【0145】

ブロック４５２において、メディアシンクシステム（例えば図２の２００など）が、映像リンクを介して受け取った符号化ビデオ信号（例えば図２の１１２など）を、１つ以上のビデオフレームに復号化する。前記１つ以上のビデオフレームは、（ａ）基準コード値および（ｂ）１つ以上のマッピング関数のための複数のマッピング関数パラメータを格納する、複数の画素を有する。前記複数の画素は、映像リンクを規定する１つ以上の映像リンク規格によって、画素値のみを保持するように特に指定されている。

【0146】

ブロック４５４において、メディアシンクシステム（２００）は、前記１つ以上のビデオフレームの複数の画素から、前記基準コード値および複数のマッピング関数パラメータを抽出する。

【0147】

ブロック４５６において、メディアシンクシステム（２００）は、前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数を適用することにより、基準コード値をマッピング後の画素値にマッピングする。

【0148】

一実施形態例において、メディアシンクシステム（２００）はさらに、あるビデオシンクシステムが前記１つ以上のマッピング関数に関連するマッピング動作を実行することが可能であることを示すように構成される。ここで前記方法は、前記ビデオシンクシステムによって実行される。

【0149】

一実施形態例において、前記映像リンクは、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）リンク、Ｖ−ｂｙ−Ｏｎｅ−ＨＳ（Ｖｘ１）リンク、Ｌｏｗ−Ｖｏｌｔａｇｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｓｉｇｎａｌｉｎｇ（ＬＶＤＳ）リンク、Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ（ＨＤ−ＳＤＩ）リンクなどのうち１つである。

【0150】

一実施形態例において、前記複数のマッピング関数パラメータおよび基準コード値は、前記１つ以上のビデオフレームのうち同一のビデオフレーム内にある。

【0151】

一実施形態例において、前記１つ以上のビデオフレームは、ビデオフレームの時間的シーケンスの一部を表しており、前記複数のマッピング関数パラメータは、前記１つ以上のビデオフレームのうち第１のビデオフレーム内にあり、前記基準コード値は、前記時間的シーケンス中の前記第１のビデオフレームの前である第２のビデオフレーム内にある。

【0152】

一実施形態例において、前記複数のマッピング関数パラメータは、前記複数の画素のビットフィールドのうち複数の最下位ビットフィールドに格納される。

【0153】

一実施形態例において、前記複数のマッピング関数パラメータは、前記複数の画素内の複数のビットフィールドに格納されており、前記複数の画素内の前記複数のビットフィールド以外のビットフィールドは、ある色空間のチャンネルの組のうち各チャンネルについてのコンポーネント基準コード値を保持しており、複数のビットフィールドは、映像リンクを規定する映像リンク規格によって、前記色空間のチャンネルの組のうち適切なチャンネルの部分集合のためのコンポーネント画素値に対して本来指定されている。

【0154】

一実施形態例において、前記色空間のチャンネルの組は、少なくとも１つのクロマコンポーネントを含み、前記適切なチャンネルの部分集合は、前記色空間のチャンネルの組における前記少なくとも１つのクロマコンポーネントを包含する。

【0155】

一実施形態例において、前記色空間は、ＲＧＢ色空間またはＹＣｂＣｒ色空間のうち１つである。

【0156】

一実施形態例において、ソースビデオ信号は、映像コンテンツのみか、または音声コンテンツ映像コンテンツの両方のうち一方を含むソースメディアデータ中にある。メディアデータは、無線（ｏｖｅｒ−ｔｈｅ−ａｉｒ）放送信号、ケーブル放送信号、衛星放送信号、メディアデータビットストリーム、メディアデータファイルなどのうち１つとして受け取られ得る。

【0157】

一実施形態例において、前記１つ以上のビデオフレームは１シーンを形成する。

【0158】

一実施形態例において、前記１つ以上のビデオフレームは、４−４−４サンプリングフォーマット、４−２−２サンプリングフォーマット、４−２−０サンプリングフォーマットなどのうち１つである。

【0159】

一実施形態例において、前記複数のマッピング関数パラメータのうち１つ以上のマッピング関数パラメータが、前記１つ以上のビデオフレームにおいて繰り返される。

【0160】

一実施形態例において、前記複数のマッピング関数パラメータは、映像描画装置に対し、ＤＭメタデータ送信パケットのペイロード中において、前記ＤＭメタデータ送信パケットのビット値のうち一部から算出された１つ以上の巡回冗長検査（ＣＲＣ）値とともに送られる。

【0161】

一実施形態例において、前記１つ以上のビデオフレームのうち１つのビデオフレームは、前記１つ以上のマッピング関数に関連するマッピング動作を同じ前記ビデオフレームに対して行うために用いられる、前記複数のマッピング関数パラメータを保持する。

【0162】

一実施形態例において、前記１つ以上のビデオフレームのうち１つのビデオフレームは、前記複数のマッピング関数パラメータを保持せず、ここで前記ビデオフレームは、以前に受け取った前記複数のマッピング関数パラメータが、前記１つ以上のマッピング関数に関連するマッピング動作を同じ前記ビデオフレームに対して行うために用いられるべきことを示すフラグを表す値を含む。

【0163】

一実施形態例において、前記１つ以上のマッピング関数に関連するマッピング動作は、トーンマッピング動作、色域マッピング動作などのうち１つ以上を包含する。

【0164】

一実施形態例において、前記複数の画素内の、前記複数のマッピング関数パラメータを格納する複数のビットフィールドは、スクランブルされている。

【0165】

一実施形態例において、複数の画素はさらなる非画素値を保持しており、前記非画素値は、前記複数のマッピング関数パラメータに関連するマッピング動作以外のディスプレイマネジメント動作のための、１つ以上の動作パラメータを格納する。

【0166】

図８Ａから図８Ｄにさらなる処理フロー例を示す。いくつかの実施形態において、１つ以上のコンピューティングデバイスまたはユニット（例えば図１のメディアソースシステム１００、図２のメディアシンクシステム２００、図６Ａまたは図６Ｂのソースシステム６０２、図６Ａまたは図６Ｂのシンクシステム６０４など）が、処理フローを実行し得る。

【0167】

図８Ａは、本明細書に記載の基準コード値およびＤＭデータを保持するために用いられるビデオ信号フォーマットを、特定の再生環境においてサポートされる別のビデオ信号フォーマットで送信する処理フロー例を示す。ブロック８０２において、ソースシステム（例えば図６Ａまたは図６Ｂの６０２など）は、（ａ）基準コード値および（ｂ）１つ以上のマッピング関数のための複数のマッピング関数パラメータを含むソースビデオ信号を受け取る。前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数は、前記基準コード値を装置固有の画素値にマッピングするために用いられ得る。

【0168】

ブロック８０４において、ソースシステム（６０２）は、基準コード値の１つ以上の部分と前記複数のマッピング関数パラメータとを、第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成する。

【0169】

ブロック８０６において、ソースシステム（６０２）は、第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオフォーマットとの間のマッピングに基づいて生成する。

【0170】

ブロック８０８において、ソースシステム（６０２）は、前記１つ以上の第２のビデオフレームを、前記映像リンクを介してビデオシンクデバイスに送る。

【0171】

一実施形態例において、前記第１のビデオ信号フォーマットは１２ビットＹＣｂＣｒフォーマットを表しており、前記第２のビデオ信号フォーマットは８ビットＲＧＢフォーマットを表している。

【0172】

一実施形態例において、ソースシステム（６０２）はさらに、メタデータ情報フレームを、前記第１のビデオ信号フォーマットである元々の（ｕｎｄｅｒｌｙｉｎｇ）ビデオ信号が前記第２のビデオ信号フォーマットの前記符号化ビデオ信号中に保持されていることを示すデータとともに送信するように構成される。

【0173】

一実施形態例において、ソースシステム（６０２）はさらに、前記１つ以上の第１のビデオフレーム中の前記ＤＭメタデータの１つ以上の部分のビット値にわたって１つ以上の巡回冗長検査（ＣＲＣ）値を算出することと、前記１つ以上の第１のビデオフレーム中の前記１つ以上のＣＲＣ値とともに、前記ＤＭメタデータを送信することを行うように構成される。

【0174】

一実施形態例において、ソースシステム（６０２）はさらに、前記ビデオシンクデバイスが前記１つ以上のマッピング関数に関連するマッピング動作を実行することが可能であることを決定するように構成される。

【0175】

一実施形態例において、映像リンクは、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ）リンク、Ｖ−ｂｙ−Ｏｎｅ−ＨＳ（Ｖｘ１）リンク、Ｌｏｗ−Ｖｏｌｔａｇｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｓｉｇｎａｌｉｎｇ（ＬＶＤＳ）リンク、Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ（ＨＤ−ＳＤＩ）リンクなどのうち１つである。

【0176】

一実施形態例において、前記複数のマッピング関数パラメータは、前記１つ以上の第１のビデオフレームの複数の最下位ビットフィールドに格納される。一実施形態例において、前記複数のマッピング関数パラメータのうち１つ以上のマッピング関数パラメータが、前記１つ以上の第１のビデオフレームにおいて繰り返される。

【0177】

一実施形態例において、前記１つ以上の第１のビデオフレームは１シーンを形成する。一実施形態例において、前記１つ以上のビデオフレームのうち１つのビデオフレームは、前記１つ以上のマッピング関数に関連するマッピング動作を同じ前記ビデオフレームに対して行うために用いられる、前記複数のマッピング関数パラメータを保持する。一実施形態例において、前記１つ以上の第１のビデオフレームのうちの１つの第１のビデオフレームは、前記複数のマッピング関数パラメータを保持せず、前記第１のビデオフレームは、以前に受け取った前記複数のマッピング関数パラメータが、前記１つ以上のマッピング関数に関連するマッピング動作を同じ第１のビデオフレームに行うために用いられるべきであることを示すフラグを表す値を含む。

【0178】

一実施形態例において、前記１つ以上のマッピング関数に関連するマッピング動作は、トーンマッピング動作または色域マッピング動作のうち１つ以上を包含する。一実施形態例において、前記１つ以上の第１のビデオフレームにおける、前記複数のマッピング関数パラメータを格納する複数のビットフィールドは、スクランブルされている。一実施形態例において、前記１つ以上の第１のビデオフレームは、前記マッピング以外のディスプレイマネジメント動作のための、１つ以上のパラメータをさらに保持している。

【0179】

図８Ｂは、別のビデオ信号フォーマットのビデオ信号をトンネル処理するために用いられるビデオ信号フォーマットを復号化する処理フロー例を示しており、ここで、特定の再生環境における本明細書に記載の基準コード値およびＤＭデータは、まず他方のビデオ信号フォーマットで符号化される。ブロック８２２において、シンクシステム（例えば図６Ａまたは図６Ｂの６０４など）は、映像リンクを介して符号化ビデオ信号を受け取る。ここで、基準コード値の１つ以上の部分および複数のマッピング関数パラメータを、第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成してもよい。前記符号化ビデオ信号は、第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを有する。前記１つ以上の第２のビデオフレームは、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオフォーマットとの間のマッピングに基づいて生成される。

【0180】

ブロック８２４において、シンクシステム（６０４）は、前記第２のビデオ信号フォーマットである前記１つ以上の第２のビデオフレームを、前記符号化ビデオ信号から抽出する。

【0181】

ブロック８２６において、シンクシステム（６０４）は、前記基準コード値の１つ以上の部分および前記複数のマッピング関数パラメータを、前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオフォーマットとの間のマッピングに基づいて抽出する。

【0182】

ブロック８２８において、シンクシステム（６０４）は、前記複数のマッピング関数パラメータを有する１つ以上のマッピング関数を適用することにより、前記基準コード値の１つ以上の部分をマッピング後の画素値にマッピングする。

【0183】

一実施形態例において、シンクシステム（６０４）はさらに、メタデータ情報フレームを、前記第１のビデオ信号フォーマットである元々のビデオ信号が前記第２のビデオ信号フォーマットの前記符号化ビデオ信号中に保持されていることを示すデータとともに受け取るように構成される。

【0184】

一実施形態例において、シンクシステム（６０４）はさらに、前記基準コード値の１つ以上の部分および前記複数のマッピング関数パラメータに基づいて構築された、１つ以上の画像を描画するように構成される。

【0185】

図８Ｃは、別のビデオ信号フォーマットのビデオ信号をトンネル処理するために用いられるビデオ信号フォーマットの存在を決定する処理フロー例を示しており、ここで、特定の再生環境における本明細書に記載の基準コード値およびＤＭデータは、まず他方のビデオ信号フォーマットで符号化される。ブロック８４２において、シンクシステム（例えば図６Ａまたは図６Ｂの６０４など）は、符号化ビデオ信号中に符号化された１つ以上のビデオフレームから、特定のデータ部分を抽出する。符号化ビデオ信号は、シンクシステム（６０４）のビデオ受信器インターフェースから受け取られる。

【0186】

ブロック８４４において、シンクシステム（６０４）は、前記符号化ビデオ信号から抽出された前記特定のデータ部分に対し、ＣＲＣテストを行う。

【0187】

ブロック８４６において、前記符号化ビデオ信号から抽出された前記特定のデータ部分に対するＣＲＣテストが合格すると、シンクシステム（６０４）は、ビデオシンクシステムを、前記符号化ビデオ信号から抽出された前記特定のデータ部分に保持される複数のマッピング関数パラメータに少なくとも部分的に基づき、前記符号化ビデオ信号から抽出された複数の基準コード値を、装置固有の画素値にマッピングする特定の動作モードに、設定する。

【0188】

一実施形態例において、シンクシステム（６０４）はさらに、前記１つ以上の第１のビデオフレームから、ソースデバイスにより算出された１つ以上の巡回冗長検査（ＣＲＣ）値を抽出し、前記１つ以上の第１のビデオフレームの１つ以上の特定の部分のビット値にわたって、１つ以上のＣＲＣ値を算出し、前記１つ以上のＣＲＣ値を、前記ソースデバイスにより算出された１つ以上のＣＲＣ値に対し比較することを行うように構成される。

【0189】

一実施形態例において、シンクシステム（６０４）はさらに、前記符号化ビデオ信号から抽出された特定のデータ部分に対する前記ＣＲＣテストがある明示された回数不合格であると、前記ビデオシンクシステムを、基準コード値から装置固有の画素値へのマッピングを前記ビデオシンクシステムが行わない第２の特定の動作モードに設定するように構成される。

【0190】

一実施形態例において、前記ビデオシンクシステムは、メタデータ情報フレームを、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータを前記符号化ビデオ信号が含んでいることを示すデータとともに、受け取らないようにされる。

【0191】

一実施形態例において、前記符号化ビデオ信号は第１のビデオ信号フォーマットであり、かつ基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータが符号化された、前記第１のビデオ信号フォーマットのビデオフレームを含む。

【0192】

一実施形態例において、前記符号化ビデオ信号はあるビデオ信号フォーマットのビデオフレームを含み、前記ビデオ信号フォーマットのビデオフレームに、前記ビデオ信号フォーマットと異なる第１のビデオ信号フォーマットの第１のビデオフレームがマッピングされ、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータが、前記第１のビデオフレーム中に符号化される。

【0193】

図８Ｄは、シンクシステムが、特定の再生環境において、本明細書に記載の基準コード値およびＤＭデータに基づくディスプレイマネジメント動作を行うことが可能かどうかを決定する、処理フロー例を示す。ブロック８６２において、ソースシステム（例えば図６Ａまたは図６Ｂの６０２など）は、複数の基準コード値および複数のマッピング関数パラメータを、第１のビデオ信号フォーマットである１つ以上の第１のビデオフレームに合成する。前記複数の基準コード値は、特定の画像パターンを表す。複数のマッピング関数パラメータは、前記複数の基準コード値を複数の装置固有の画素値にマッピングするための１つ以上のマッピング関数に関する。

【0194】

ブロック８６４において、ソースシステム（６０２）は、第２のビデオ信号フォーマットである１つ以上の第２のビデオフレームを、前記第１のビデオ信号フォーマットである前記１つ以上の第１のビデオフレームおよび、前記第１のビデオ信号フォーマットと前記第２のビデオフォーマットとの間のマッピングに基づいて生成する。

【0195】

ブロック８６６において、ソースシステム（６０２）は、前記１つ以上の第２のビデオフレームを、映像リンクを介してビデオシンクシステムに送る。

【0196】

ブロック８６８において、色歪みの無い前記特定の画像パターンが前記ビデオシンクシステムによって表示されていることを示すユーザー入力を受け取ると、ソースシステム（６０２）は、前記ビデオソースシステムが前記ビデオシンクシステムに、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータが符号化されたさらなるビデオフレームを送る特定の動作モードであって、前記さらなるビデオフレーム中の前記基準コード値は、１つ以上のメディアプログラムの映像コンテンツの少なくとも一部を表している特定の動作モードに、ビデオソースシステムを設定する。

【0197】

一実施形態例において、前記特定の画像パターンは、前記ビデオシンクシステムに格納されたグレースケール画像パターンである。

【0198】

一実施形態例において、ソースシステム（６０２）はさらに、色歪みのある前記特定の画像パターンが前記ビデオシンクシステムによって表示されていることを示すユーザー入力を受け取ると、ビデオソースシステムを、前記ビデオソースシステムが前記ビデオシンクシステムに、基準コード値および前記基準コード値を装置固有の画素値にマッピングするために用いられるマッピング関数パラメータ無しにさらなるビデオフレームを送る第２の特定の動作モードに、設定するように構成される。

【0199】

実施形態は、本明細書に記載の方法のうち任意の１つを実行するように構成されたメディア処理システムを含む。

【0200】

実施形態は、プロセッサを備え、前記方法のうち任意の１つを実行するように構成された装置を含む。

【0201】

実施形態は、１つ以上のプロセッサによって実行されたとき前記方法のうち任意の１つを実行させる、ソフトウェア命令を格納した、非一時的なコンピュータ読み取り可能な記憶媒体を含む。

【0202】

別個の実施形態について述べたが、本明細書において述べた実施形態および／または部分的な実施形態の任意の組み合わせを結合して、さらなる実施形態を構成することができることに留意されたい。

【0203】

１１．実装メカニズム−ハードウェア概要
一実施形態において、本明細書に記載の技術は、１つ以上の専用コンピューティングデバイスにより実現される。専用コンピューティングデバイスは、上記技術を実行するようにハードワイヤードされていてもよく、あるいは上記技術を行うように永続的にプログラムされた１つ以上の特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのデジタル電子機器を含んでもよく、あるいはファームウェア、メモリ、その他の記憶装置、または組み合わせ中のプログラム命令にしたがって上記技術を実行するようにプログラムされた、１つ以上の汎用ハードウェアプロセッサを含んでもよい。そのような専用コンピューティングデバイスはまた、上記技術を達成するためのカスタムプログラミングを有するカスタムのハードワイヤード論理回路、ＡＳＩＣ、またはＦＰＧＡを組み合わせていてもよい。専用コンピューティングデバイスは、デスクトップコンピュータシステム、ポータブルコンピュータシステム、ハンドヘルド型デバイス、ネットワーキングデバイスまたは、上記技術を実現するためのハードワイヤードおよび／またはプログラム論理回路を備えた他の任意のデバイスであってもよい。

【0204】

例えば、図５は、本発明の一実施形態を実装し得るコンピュータシステム５００を示すブロック図である。コンピュータシステム５００は、情報を通信するためのバス５０２その他の通信メカニズムおよび、情報を処理するためにバス５０２に結合されたハードウェアプロセッサ５０４を有する。ハードウェアプロセッサ５０４は例えば、汎用マイクロプロセッサであってもよい。

【0205】

コンピュータシステム５００はまた、バス５０２に結合されておりプロセッサ５０４によって実行される命令および情報を格納する、ランダムアクセスメモリ（ＲＡＭ）またはその他のダイナミック記憶装置などのメインメモリ５０６を有する。メインメモリ５０６はまた、プロセッサ５０４によって実行されるべき命令の実行中において、一時変数またはその他の中間情報を格納するためにも用いられ得る。そのような命令は、プロセッサ５０４によりアクセス可能な非一時的な記憶媒体に格納されたとき、コンピュータシステム５００を、それら命令において明示された動作を実行するような装置固有的な専用機器へと変える。

【0206】

コンピュータシステム５００はさらに、バス５０２に結合されておりプロセッサ５０４への命令およびスタティック情報を格納する、リードオンリーメモリ（ＲＯＭ）５０８またはその他のスタティック記憶装置を有する。磁気ディスクまたは光ディスクなどの記憶装置５１０が、情報および命令を格納するために設けられ、バス５０２に結合される。

【0207】

コンピュータシステム５００は、バス５０２を介して、コンピュータのユーザーに情報を表示するための液晶ディスプレイ（ＬＣＤ）などのディスプレイ５１２に結合される。英数字およびその他のキーを含む入力装置５１４がバス５０２に結合され、情報およびコマンド選択をプロセッサ５０４に伝える。別のタイプのユーザー入力装置としては、方向情報およびコマンド選択をプロセッサ５０４に伝え、ディスプレイ５１２上でのカーソル移動を制御するための、マウス、トラックボールまたはカーソル方向キーなどのカーソルコントロール５１６がある。この入力装置は典型的には、第１の軸（例えばｘ）および第２の軸（例えばｙ）の２軸において２自由度を有しており、装置が平面内での位置を特定することを可能にする。

【0208】

コンピュータシステム５００は、本明細書に記載の技術を、装置固有のハードワイヤード論理回路、１つ以上のＡＳＩＣまたはＦＰＧＡ、ファームウェアおよび／またはプログラム論理回路を用いることによって実現してもよい。これらは、コンピュータシステムと組み合わせることによってコンピュータシステム５００を専用機器とさせる（プログラムする）。一実施形態において本明細書における技術は、メインメモリ５０６に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ５０４が実行することにより、コンピュータシステム５００によって実行される。このような命令は、記憶装置５１０などの別の記憶媒体からメインメモリ５０６に読み込まれてもよい。メインメモリ５０６に含まれる命令のシーケンスの実行により、プロセッサ５０４が、本明細書に記載の処理ステップを実行ことになる。別の実施形態において、ソフトウェア命令の代わりにあるいはソフトウェア命令と組み合わせて、ハードワイヤード回路を用いてもよい。

【0209】

本明細書で用いられる「記憶媒体」の語は、機器に特定の動作を起こさせるデータおよび／または命令を格納する、任意の非一時的媒体を指す。そのような記憶媒体は、不揮発性媒体および／または揮発性媒体を含み得る。不揮発性媒体は、例えば、記憶装置５１０などの光または磁気ディスクを含む。揮発性媒体は、メインメモリ５０６などのダイナミックメモリを含む。記憶媒体の一般的な形態としては、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープその他の磁気データ記憶媒体、ＣＤ−ＲＯＭその他の光学的データ記憶媒体、穴のパターンを有する任意の物理媒体、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、ＮＶＲＡＭ、他の任意のメモリチップまたはカートリッジが含まれる。

【0210】

記憶媒体は送信媒体とは異なるが、送信媒体とともに用いられ得る。送信媒体は、情報を記憶媒体間で移動させることに関与する。例えば、送信媒体は、同軸ケーブル、銅線および光ファイバーを含み、バス５０２を構成する配線も含まれる。送信媒体はまた、電波および赤外線データ通信において生成されるような、音波または光波の形態を取り得る。

【0211】

１つ以上の命令の１つ以上のシーケンスを、実行のためプロセッサ５０４へ運ぶことにおいて、様々な形態の媒体が含まれ得る。例えば、命令をまず、リモートコンピュータの磁気ディスクまたはソリッドステートドライブ上に保持してもよい。リモートコンピュータは、これらの命令を自身のダイナミックメモリにロードし、そしてモデムを用いて命令を電話線を介して送ることができる。コンピュータシステム５００のローカルにあるモデムが、電話線上のデータを受け取り、赤外線送信器を用いてデータを赤外線信号へと変換することができる。赤外線信号に保持されたデータを赤外線検出器が受け取り、適切な回路によってデータをバス５０２上に置くことができる。バス５０２は、データをメインメモリ５０６へと運び、ここからプロセッサ５０４が命令を取り出して実行する。メインメモリ５０６が受け取った命令は、オプションとして、プロセッサ５０４による実行の前か後に記憶装置５１０に格納されてもよい。

【0212】

コンピュータシステム５００はまた、バス５０２に結合された通信インターフェース５１８を有する。通信インターフェース５１８は、ローカルネットワーク５２２に接続されたネットワークリンク５２０に、双方向データ通信接続を提供する。例えば、通信インターフェース５１８は、サービス総合ディジタル網（ｉｎｔｅｇｒａｔｅｄ ｓｅｒｖｉｃｅｓ ｄｉｇｉｔａｌ ｎｅｔｗｏｒｋ：ＩＳＤＮ）カード、ケーブルモデム、衛星モデム、またはデータ通信接続を対応するタイプの電話線に提供するモデムであってもよい。別の例として、通信インターフェース５１８は、適合するＬＡＮへデータ通信接続を提供するためのローカルエリアネットワーク（ＬＡＮ）カードであってもよい。また無線リンクを実現してもよい。このような態様のいずれにおいても、通信インターフェース５１８は、様々なタイプの情報を表すデジタルデータストリームを保持する、電気、電磁気または光信号を授受する。

【0213】

ネットワークリンク５２０は典型的には、１つ以上のネットワークを通じてデータ通信を他のデータ装置に提供する。例えば、ネットワークリンク５２０は、ローカルネットワーク５２２を通じて、インターネットサービスプロバイダ（ＩＳＰ）５２６に管理されるホストコンピュータ５２４またはデータ機器への接続を提供してもよい。そしてＩＳＰ５２６は、現在では一般に「インターネット」と呼称されるワールドワイドパケットデータ通信ネットワーク５２８を介して、データ通信サービスを提供する。ローカルネットワーク５２２およびインターネット５２８の両方とも、デジタルデータストリームを保持する電気、電磁気または光信号を用いる。様々なネットワークを通る信号およびネットワークリンク５２０上および通信インターフェース５１８を通る信号（コンピュータシステム５００へ、またコンピュータシステム５００からのデジタルデータを保持する）が、送信媒体の形態例である。

【0214】

コンピュータシステム５００は、ネットワーク（単数または複数）、ネットワークリンク５２０および通信インターフェース５１８を介して、プログラムコードを含むメッセージを送りデータを受け取り得る。インターネットの例において、サーバー５３０は、あるアプリケーションプログラムへの要求されたコードを、インターネット５２８、ＩＳＰ５２６、ローカルネットワーク５２２および通信インターフェース５１８を介して、送信し得る。

【0215】

受け取ったコードは、プロセッサ５０４によって受け取りとともに実行されるか、かつ／または記憶装置５１０またはその他の不揮発性記憶装置に格納されて、後で実行されてもよい。

【0216】

１２．均等物、拡張物、代替物、その他
以上の明細書において、各実装毎に異なり得る多数の具体的な詳細に言及しながら本発明の実施形態を説明した。従って、本発明が如何なるものかおよび出願人は本発明が如何なるものであると意図しているかについての唯一且つ排他的な指標は、後の訂正を含む、これら請求項が生じる具体的な形態の、本願から生じる１組の請求項である。当該請求項に含まれる用語に対して本明細書中に明示したあらゆる定義が、請求項内で使用される当該用語の意味を決定するものとする。よって、請求項に明示的に記載されていない限定事項、構成要素、特性、特徴、利点または属性は、いかなる形であれ請求の範囲を限定するものではない。従って、本明細書および図面は、限定的ではなく、例示的であると認識されるべきものである。

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5】

【図6A】

【図6B】

【図7】

【図8A】

【図8B】

【図8C】

【図8D】