特許7139517デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-09
(45)【発行日】2022-09-20
(54)【発明の名称】デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム
(51)【国際特許分類】
H04N 19/70 20140101AFI20220912BHJP
【ＦＩ】
H04N19/70
【請求項の数】
20
(21)【出願番号】P 2021512373
(86)(22)【出願日】2019-10-16
(65)【公表番号】
(43)【公表日】2021-08-26
(86)【国際出願番号】 US2019056459
(87)【国際公開番号】W WO2020086347
(87)【国際公開日】2020-04-30
【審査請求日】2020-11-04
(31)【優先権主張番号】62/749,283
(32)【優先日】2018-10-23
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/504,443
(32)【優先日】2019-07-08
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ウェンジャー，ステファン
(72)【発明者】
【氏名】リィウ，シャン
【審査官】岩井 健二
(56)【参考文献】
【文献】国際公開第２０１４／０５５７５３（ＷＯ，Ａ１）
【文献】国際公開第２０１４／０５００５９（ＷＯ，Ａ１）
【文献】Jill Boyce, Xavier Ducloux, Arianne Hinds, and Stephan Wenger，Interoperability point signaling for VVC，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K0311v1，11th Meeting: Ljubljana, SI，2018年07月，pp.1-4
【文献】Jill Boyce, Zhipin Deng, Sam Wong, and Lidong Xu，AHG15: Proposed interoperability point syntax，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-L0044-v1，12th Meeting: Macao, CN，2018年09月，pp.1-6
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ １９／００ － １９／９８
(57)【特許請求の範囲】
【請求項1】
デコーダが実行するメディアの復号方法であって、第１サブプロファイルに従う符号化されたビデオシーケンスを生成するようビデオシーケンスを符号化するためにエンコーダによって使用可能であり、かつ、前記第１サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第１の定義された組を識別する前記第１サブプロファイルを示す第１指示をシンタックス構造から復号するステップと、
第２サブプロファイルに従う前記符号化されたビデオシーケンスを生成するよう前記ビデオシーケンスを符号化するために前記エンコーダによって使用可能であり、かつ、前記第２サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第２の定義された組を識別する前記第２サブプロファイルを示す第２指示を前記シンタックス構造から復号するステップと、
前記第１指示及び前記第２指示のうちの少なくとも１つに基づいて、前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップと、
前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかの判定に基づいて、前記符号化されたビデオシーケンスを選択的に復号するステップと
を有し、
前記シンタックス構造は、サブプロファイルの数を示すシンタックス要素を含み、該サブプロファイルのリストを、固定回数の繰り返しを有するループの形で含む、方法。
【請求項2】
前記第１指示は、ＩＴＵ－Ｔ推奨Ｔ．３５に従って符号化される、請求項１に記載の方法。
【請求項3】
前記第１指示は、第１高位シンタックス構造に存在する複数の第１指示のうちの１つであり、前記第１高位シンタックス構造は、少なくとも前記符号化されたビデオシーケンスに関係がある、
請求項２に記載の方法。
【請求項4】
前記複数の第１指示は、第１指示のリストとしてまとめられ、該リスト内の第１指示の数は、可変長さの符号なしコードワードとして前記第１高位シンタックス構造において符号化される、請求項３に記載の方法。
【請求項5】
前記第１指示は、第１高位シンタックス構造に存在し、前記第２指示は、第２高位シンタックス構造に存在し、前記第１高位シンタックス構造は、前記第２高位シンタックス構造とは異なる、請求項１に記載の方法。
【請求項6】
前記第１指示は、長さが少なくとも３つのオクテットのオクテット列として符号化され、前記第１指示は、前記第２指示のサブプロファイルである、
請求項１に記載の方法。
【請求項7】
前記第１指示及び前記第２指示を結合するステップと、前記第１指示及び前記第２指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別するステップと
を更に有する、請求項１に記載の方法。
【請求項8】
結合されたコンフォーマンスポイントと前記デコーダのケイパビリティ情報とを比較するステップを更に有し、前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップは、
前記結合されたコンフォーマンスポイントと前記デコーダの前記ケイパビリティ情報との比較に基づいて、前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップを有する、
請求項１に記載の方法。
【請求項9】
メディアビットストリームは、前記第１指示及び前記第２指示の両方に対応する、請求項１に記載の方法。
【請求項10】
前記符号化されたビデオシーケンスが前記デコーダによって復号可能であると決定するステップを更に有し、前記符号化されたビデオシーケンスを選択的に復号するステップは、
前記符号化されたビデオシーケンスが前記デコーダによって復号可能である決定に基づいて、前記符号化されたビデオシーケンスを復号するステップを有する、
請求項１に記載の方法。
【請求項11】
メディア復号化のためのデバイスであって、プログラムコードを記憶するよう構成される少なくとも１つのメモリと、
前記プログラムコードを読み出し、該プログラムコードによって指示されるように動作するよう構成される少なくとも１つのプロセッサと
を有し、
前記プログラムコードは、
前記少なくとも１つのプロセッサに、
第１サブプロファイルに従う符号化されたビデオシーケンスを生成するようビデオシーケンスを符号化するためにエンコーダによって使用可能であり、かつ、前記第１サブプロファイルに従う前記符号化されたビデオシーケンスを復号するためにデコーダによって使用可能であるツールの第１の定義された組を識別する前記第１サブプロファイルを示す第１指示をシンタックス構造から復号させ、
第２サブプロファイルに従う前記符号化されたビデオシーケンスを生成するよう前記ビデオシーケンスを符号化するために前記エンコーダによって使用可能であり、かつ、前記第２サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第２の定義された組を識別する前記第２サブプロファイルを示す第２指示を前記シンタックス構造から復号させるよう構成される復号化コードと、
前記少なくとも１つのプロセッサに、前記第１指示及び前記第２指示のうちの少なくとも１つに基づいて、前記符号化されたビデオシーケンスが前記デコーダとしての当該デバイスによって復号可能であるかどうかを判定させるよう構成される判定コードと、
前記少なくとも１つのプロセッサに、前記符号化されたビデオシーケンスが当該デバイスによって復号可能であるかどうかの判定に基づいて、前記符号化されたビデオシーケンスを選択的に復号させるよう構成される選択的復号化コードと
を含み、
前記シンタックス構造は、サブプロファイルの数を示すシンタックス要素を含み、該サブプロファイルのリストを、固定回数の繰り返しを有するループの形で含む、
デバイス。
【請求項12】
前記第１指示は、ＩＴＵ－Ｔ推奨Ｔ．３５に従って符号化される、請求項１１に記載のデバイス。
【請求項13】
前記第１指示は、第１高位シンタックス構造に存在する複数の第１指示のうちの１つであり、前記第１高位シンタックス構造は、少なくとも前記符号化されたビデオシーケンスに関係がある、
請求項１２に記載のデバイス。
【請求項14】
前記複数の第１指示は、第１指示のリストとしてまとめられ、該リスト内の第１指示の数は、可変長さの符号なしコードワードとして前記第１高位シンタックス構造において符号化される、請求項１３に記載のデバイス。
【請求項15】
前記第１指示は、第１高位シンタックス構造に存在し、前記第２指示は、第２高位シンタックス構造に存在し、前記第１高位シンタックス構造は、前記第２高位シンタックス構造とは異なる、請求項１１に記載のデバイス。
【請求項16】
前記第１指示は、長さが少なくとも３つのオクテットのオクテット列に符号化され、前記第１指示は、前記第２指示のサブプロファイルである、
請求項１１に記載のデバイス。
【請求項17】
前記プログラムコードは、前記少なくとも１つのプロセッサに、前記第１指示及び前記第２指示を結合させるよう構成される結合コードと、
前記少なくとも１つのプロセッサに、前記第１指示及び前記第２指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別させるよう構成される識別コードと
を更に含む、
請求項１１に記載のデバイス。
【請求項18】
前記プログラムコードは、前記少なくとも１つのプロセッサに、結合されたコンフォーマンスポイントと当該デバイスのケイパビリティ情報とを比較させるよう構成される比較コードを更に含み、前記判定コードは、前記少なくとも１つのプロセッサに、前記結合されたコンフォーマンスポイントと当該デバイスの前記ケイパビリティ情報との比較に基づいて、前記符号化されたビデオシーケンスが当該デバイスによって復号可能であるかどうかを判定させるよう更に構成される、
請求項１１に記載のデバイス。
【請求項19】
メディアビットストリームは、前記第１指示及び前記第２指示の両方に対応する、請求項１１に記載のデバイス。
【請求項20】
コンピュータに、請求項１乃至１０の何れか一項に記載の方法を実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
開示されている対象は、メディア符号化及び復号化に、より具体的には、ビットストリーム内のプロファイル、サブプロファイル、ティア、又はレベルなどの複数のコンフォーマンスポイントの表現に関係がある。
【背景技術】
【0002】
動き補償を伴ったインターピクチャ予測を用いるビデオ符号化及び復号化は、数十年にわたって知られている。無圧縮デジタルビデオは、ピクチャの連続から成ることができ、各ピクチャは、例えば、１９２０×１０８０の輝度サンプル及び関連する色度サンプルの空間次元を有している。ピクチャの連続は、例えば、毎秒６０ピクチャ、すなわち６０Ｈｚの固定又は可変のピクチャレート（俗に、フレームレートとして知られる）を有することができる。無圧縮ビデオは、重要なビットレート要件を有している。例えば、８ビット／サンプルでの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚフレームレートでの１９２０×１０８０輝度サンプル解像度）は、１．５Ｇｂｉｔ／ｓバンド幅に近い必要がある。そのようなビデオの１時間は、６０ＧＢよりも大きい記憶空間を必要とする。
【0003】
ビデオ符号化及び復号化の１つの目的は、圧縮による入力ビデオ信号の冗長性の低減であることができる。圧縮は、いくつかの場合に２桁以上、上記のバンド幅又は記憶空間要件を低減することを助け得る。可逆及び不可逆の両方の圧縮並びにそれらの組み合わせが用いられ得る。可逆圧縮は、原信号の正確なコピーが、圧縮された原信号から再構成され得る技術を指す。不可逆圧縮を使用する場合に、再構成された信号は、原信号と同一でないことがあるが、原信号と再構成された信号との間の歪みは、再構成された信号を意図された用途にとって有用なものとするほど十分に小さい。ビデオの場合には、不可逆圧縮が広く用いられている。受け入れられる歪みの量は用途に依存する。例えば、特定の消費者ストリーミング用途のユーザは、テレビジョン投稿用途のユーザよりも高い歪みを許容し得る。達成可能な圧縮比は、より高い許容可能な／受け入れ可能な歪みがより高い圧縮比をもたらし得ることを反映することができる。
【0004】
ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化、及びエントロピ符号化を含むいくつかの広いカテゴリからの技術を利用することができる。それらの技術のうちのいくつかは、以下で紹介される。
【0005】
デコーダ又は基礎をなすシステムが、所与の符号化されたメディアビットストリームが復号可能であるかどうかを判定することを助けるために、更には、ケイパビリティネゴシエーション（capability negotiation）などのタスクを支援するために、コンフォーマンスポイント（conformance points）が導入されている。例えば、ＭＰＥＧ及び同様の標準規格において、プロファイルは、ビットストリームに存在する可能性があるツールの集合の中の定義されたサブセットを示し得る。例えば、Ｈ．２６４において、ベースラインプロファイルは、インターレース符号化に関連したツールを含まず、一方で、メインプロファイルは、そのようなツールを含む。同様に、レベルは、ビットストリームの複雑さの上限を示し得る。同様に、ティアは、所与の標準規格のビットストリームの複雑さ（所与の時間－空間分解能についての最大ビットレート）を示し得る。
【0006】
２００３年頃までに、標準規格は、オニオン形（onion-shaped）をしたプロファイルをしばしば導入した。レベル及びティアは、今日でさえオニオン形として定義されている。ここで、オニオン形は、“より低い”プロファイル（なお、通常は、数値的により低いプロファイルインジケータ値によって常には示されない）のために定義された全てのツールがより高いプロファイルに含まれたことを暗示する。図１を参照すると、ベースラインプロファイル（１０１）は、小さい円として示されており、メインプロファイル（１０２）を示すより大きい円によって完全に囲まれている。この図は、ベースラインプロファイル（１０１）の全てのツールがやはりメインプロファイル（１０２）に含まれていることを表す。ベースラインプロファイルは、０のプロファイルＩＤによって表され、メインプロファイルは、１のプロファイルＩＤによって表されるとする。結果として、ビデオビットストリームにおいて符号化されているプロファイルＩＤの単一値を、デコーダ又は基礎をなすシステムが復号化することができるプロファイルＩＤと比較することは、プロファイル視点から所与のビットストリームが復号可能であるかどうか否かを定めるのに十分であった。例えば、デコーダがメインプロファイル（ＩＤ＝１を有する）を復号することができた場合に、次いで、ＩＤ＝０を有するベースラインプロファイルにさらされるとき、デコーダは、ビットストリームを復号することができる。レベルは、処理要件（例えば、サンプル／秒）及びメモリ要件（例えば、ピクチャ内の最大サンプル数、ビット深さ、など）の組み合わせにおいてしばしば測定される、ビットストリームの複雑さの更なる次元を提供する。ＭＰＥＧ標準規格におけるレベルは、一般に、オニオン形である。所与のビットストリームを復号するために、ビットストリームのプロファイル及びレベルの両方が、デコーダのプロファイル及びレベル以下である必要がある。
【0007】
２００３年のＨ．２６４の最終決定によれば、オニオン形でないプロファイルが導入された。例えば、Ｈ．２６４の（制約なし）ベースラインは、フレキシブル・マクロブロック・オーダリング（Flexible Macroblock Ordering，ＦＭＯ）（２０２）として知られているツールを含み、一方、メインプロファイル（２０３）はそのツールを含まない。同様に、メインプロファイルは、インターレース符号化をサポートするためのツールを含むが、そのツールはベースラインプロファイルには含まれていない。多数の他のツールは、両方のプロファイルに共通である（２０５）。Ｈ．２６４は、ビットストリームがベースライン及びメインの両方のプロファイルと互換性があることを示すことを可能にしたメカニズムを当初含んでいなかった。これは、ベースラインプロファイル及びメインプロファイルの両方のアプリケーション空間が別種と見なされるということで、問題と考えられなかった。
【0008】
Ｈ．２６５では、おおよそ２０１３年頃に、非重複プロファイルが作られた。ここで、しかしながら、標準委員会は、複数のプロファイルとの互換性の指示が望ましいと決定した。実装された解決法は、とり得るプロファイルの有限かつ小さい番号空間（Ｈ．２６５の場合に３２）に依存する。好ましいプロファイルは、５ビット整数によって示される。残りの３１個のプロファイルとの互換性は、３２ビットマスクにより示され得る。その場合に、各ビットは、そのように番号付けされたプロファイルとの互換性を示す。
【0009】
バーサタイル・ビデオ・コーディング（Versatile Video Coding）、すなわちＶＶＣとして一応知られている新しいビデオ符号化標準が検討中である。ＶＶＣは、特定の市場実態を反映するようにユーザ定義のプロファイル又はサブプロファイルをサポートすることが見込まれている。いくつのプロファイル及びサブプロファイルをユーザが作る可能性があるかは、はじめから明らかではないので、数百、数千、又はそれ以上のプロファイル及び／又はサブプロファイルをサポートする必要性が存在し得る。更に、ユーザ定義のプロファイルのための軽快な登録メカニズムが望ましいということで、ユーザ定義のプロファイル及び／又はサブプロファイルのための広い番号空間も望ましい。そのため、ビットマスクによる複数のプロファイル互換性の表現は実際的ではない。同様の考えは、レベル又はティアなどの他のコンフォーマンスポイントにも当てはまり得る。更に、特定の環境で、プロファイル及びサブプロファイルなどの、同じビットストリーム内の異なるカテゴリの複数のコンフォーマンスポイントとの互換性を表すことが必要であることがある。
【発明の概要】
【0010】
本開示の態様に従って、デコーダによるメディア復号化のための方法は、符号化されたビデオシーケンスの第１コンフォーマンスポイントを示す第１指示を復号するステップと、符号化されたビデオシーケンスの第２コンフォーマンスポイントを示す第２指示を復号するステップと、第１コンフォーマンスポイント及び第２コンフォーマンスポイントのうちの少なくとも１つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定するステップと、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号するステップとを含む。
【0011】
本開示の態様に従って、メディア復号化のためのデバイスは、プログラムコードを記憶するよう構成される少なくとも１つのメモリと、プログラムコードを読み出し、プログラムコードによって指示されるように動作するよう構成される少なくとも１つのプロセッサとを含み、プログラムコードは、少なくとも１つのプロセッサに、符号化されたビデオシーケンスの第１コンフォーマンスポイントを示す第１指示を復号させ、符号化されたビデオシーケンスの第２コンフォーマンスポイントを示す第２指示を復号させるよう構成される復号化コードと、少なくとも１つのプロセッサに、第１指示及び第２指示のうちの少なくとも１つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定させるよう構成される判定コードと、少なくとも１つのプロセッサに、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号させるよう構成される選択的復号化コードとを含む。
【0012】
本開示の態様に従って、非一時的なコンピュータ可読媒体は命令を含み、命令は、デバイスの１つ以上のプロセッサによって実行されるときに、１つ以上のプロセッサに、符号化されたビデオシーケンスの第１コンフォーマンスポイントを示す第１指示を復号するステップと、符号化されたビデオシーケンスの第２コンフォーマンスポイントを示す第２指示を復号するステップと、第１指示及び第２指示のうちの少なくとも１つに基づいて、符号化されたビデオシーケンスがデバイスによって復号可能であるかどうかを判定するステップと、符号化されたビデオシーケンスがデバイスによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号するステップとを実行させる１つ以上の命令を含む。
【0013】
開示されている対象の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面から更に明らかになる。
【図面の簡単な説明】
【0014】
【図1】関連する技術に従うプロファイルの概略図である。
【図2】実施形態に従う通信システムの略ブロック図の概略図である。
【図3】実施形態に従う通信システムの略ブロック図の概略図である。
【図4】実施形態に従うデコーダの略ブロック図の概略図である。
【図5】実施形態に従うエンコーダの略ブロック図の概略図である。
【図6】複数のコンフォーマンスポイントをサポートするシンタックスのシンタックス図である。
【図7】実施形態に従うプロセスの例のフローチャートである。
【図8】実施形態に従うコンピュータシステムの概略図である。
【発明を実施するための形態】
【0015】
少なくともＶＶＣサブプロファイルは、数十億とは言わないまでも数百万の選択を可能にし、ＵＵＩＤ（長さが１６バイトであり、従って、最大２（８×１６）までのサブプロファイルを可能にする）、ＵＲＩ（実際には無限な長さの文字列であるが、通常は１０から１００文字範囲内であり、１００文字とすれば２（８×１００）のサブプロファイルを可能にする）、又はＴ．３５ストリングス（実際上、２２４のサブプロファイルに沿って長さが少なくとも３つのオクテットであるべきである）などのメカニズムを通じてサブプロファイルの自己登録（self-registration）ならば更に可能にすると現在予想されている。これらのオプションの最小値であるＴ．３５でさえ、２２４サイズのビットマスクが必要になるため、メディア符号化にとって実用的ではない。従って、１よりも多いプロファイル又はサブプロファイルとのビットストリーム互換性を示すには、新しいメカニズムが必要である。
【0016】
図２は、本開示の実施形態に従う通信システム（２００）の略ブロック図を表す。システム（２００）は、ネットワーク（２５０）を介して相互接続されている少なくとも２つの端末（２１０～２２０）を含んでよい。データの一方向伝送のために、第１端末（２１０）は、ネットワーク（２５０）を介した他の端末（２２０）への伝送のためにその場でビデオデータを符号化してよい。第２端末（２２０）は、ネットワーク（２５０）から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、回復されたビデオデータを表示してよい。一方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。
【0017】
図２は、例えば、ビデオ会議中に行われ得る符号化されたビデオの双方向伝送をサポートするために設けられた端末（２３０、２４０）の第２の対を表す。データの双方向伝送のために、各端末（２３０、２４０）は、その場で捕捉されたビデオデータを、ネットワーク（２５０）を介した他の端末への伝送のために符号化してよい。各端末（２３０、２４０）はまた、他の端末によって送信された符号化されたビデオデータを受信し、符号化されたデータを復号し、回復されたビデオデータをローカルの表示デバイスで表示してよい。
【0018】
図２において、端末（２１０～２４０）は、サーバ、パーソナルコンピュータ、及びスマートフォンとして表され得るが、本開示の原理は、そのように限定され得ない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤー、及び／又は専用のビデオ会議装置により用途を見出す。ネットワーク（２５０）は、例えば、有線及び／又は無線通信ネットワークを含む、端末（２１０～２４０）の間で符号化されたビデオデータを伝達する任意数のネットワークを表す。通信ネットワーク（２５０）は、回路交換及び／又はパケット交換チャネルにおいてデータを交換し得る。代表的なネットワークには、電気通信網、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又はインターネットがある。本議論のために、ネットワーク（２５０）のアーキテクチャ及びトポロジは、以降で説明されない限りは本開示の動作に無関係であり得る。
【0019】
図３は、開示されている対象の応用例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を表す。開示されている対象は、例えば、ビデオ会議、デジタルＴＶ、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタル媒体上での圧縮されたビデオの記憶、などを含む他のビデオ対応用途に同様に適用可能であることができる。
【0020】
ストリーミングシステムは、例えば無圧縮ビデオサンプルストリーム（３０２）を生成するビデオソース（３０１）、例えばデジタルカメラ、を含むことができる捕捉サブシステム（３１３）を含んでよい。そのサンプルストリーム（３０２）は、符号化されたビデオビットストリームと比較して高いデータボリュームを強調するために太線で表されており、カメラ（３０１）へ結合されたエンコーダ（３０３）によって処理され得る。エンコーダ（３０３）は、以下で更に詳細に記載されるように、開示されている対象の態様を可能に又は実装するためのハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。符号化されたビデオビットストリーム（３０４）は、サンプルストリームと比較して低いデータボリュームを強調するために細線で表されており、将来の使用のためにストリーミングサーバ（３０５）に記憶され得る。１以上のストリーミングクライアント（３０６、３０８）は、符号化されたビデオビットストリーム（３０４）のコピー（３０７、３０９）を読み出すためにストリーミングサーバ（３０５）にアクセスすることができる。クライアント（３０６）は、ビデオデコーダ（３１０）を含むことができる。ビデオデコーダ（３１０）は、符号化されたビデオビットストリーム（３０７）の入来するコピーを復号し、ディスプレイ（３１２）又は他のレンダリングデバイス（図示せず。）にレンダリングされ得る送出ビデオサンプルストリーム（３１１）を生成する。いくつかのストリーミングシステムにおいて、ビデオビットストリーム（３０４、３０７、３０９）は、特定のビデオコーディング／圧縮標準規格に従って符号化され得る。そのような標準規格の例には、ＩＴＵ－Ｔ推奨Ｈ．２６５がある。バーサタイル・ビデオ・コーディング又はＶＶＣとして俗に知られているビデオ符号化標準が開発中である。開示されている対象は、ＶＶＣに関連して使用されてよい。
【0021】
図４は、本発明の実施形態に従うビデオデコーダ（３１０）の機能ブロック図であり得る。
【0022】
受信器（４１０）は、デコーダ（３１０）によって復号されるべき１つ以上の符号化されたビデオシーケンスを、同じ又は他の実施形態では、一度に１つの符号化されたビデオシーケンスを受信してよい。ここで、夫々の符号化されたビデオシーケンスの復号化は、他の符号化されたビデオシーケンスから独立している。符号化されたビデオシーケンスは、チャネル（４１２）から受信されてよい。チャネルは、符号化されたビデオデータを記憶している記憶デバイスへのハードウェア／ソフトウェアリンクであってよい。受信器（４１０）は、符号化されたビデオデータを、他のデータ、例えば、符号化されたオーディオデータ及び／又は付随的なデータストリームとともに受信してよく、それらは、それらの各々の使用エンティティ（図示せず。）へ転送されてよい。受信器（４１０）は、符号化されたビデオシーケンスを他のデータから分離してよい。ネットワークジッタに対抗するために、バッファメモリ（４１５）が受信器（４１０）とエントロピデコーダ／パーサ（４２０）（以降「パーサ」）との間に結合されてよい。受信器（４１０）が十分なバンド幅及び可制御性の記憶／転送デバイスから、又はアイソクロナス（isosychronous／isochronous）ネットワークからデータを受信しているときに、バッファ（４１５）は必要とされなくてもよく、あるいは、小さくてよい。インターネットなどのベストエフォートのパケットネットワークでの使用のために、バッファ（４１５）は、比較的に大きく、有利なことには適応サイズであることができる。
【0023】
ビデオデコーダ（３１０）は、エントロピ符号化されたビデオシーケンスからシンボル（４２１）を再構成するためのパーサ（４２０）を含んでよい。それらのシンボルのカテゴリは、デコーダ（３１０）の動作を管理するために使用される情報と、潜在的に、デコーダの必須部分でないが図３に示されたようにそれへ結合され得るディスプレイ（３１２）などのレンダリングデバイスを制御するための情報とを含む。レンダリングデバイスのための制御情報は、ＳＥＩ（Supplementary Enhancement Information）メッセージ又はＶＵＩ（Video Usability Information）パラメータセットフラグメント（図示せず。）の形をとってよい。パーサ（４２０）は、受信された符号化されたビデオシーケンスをパース／エントロピ復号してよい。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術又は標準規格に従うことができ、可変長符号化、ハフマン符号化、文脈依存による又はよらない算術符号化、などを含む、当業者によく知られている原理に従うことができる。パーサ（４２０）は、符号化されたビデオシーケンスから、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダにおけるピクセルのサブグループのうちの少なくとも１つについてのサブグループパラメータの組を取り出してよい。サブグループは、グループ・オブ・ピクチャ（Groups of Pictures，ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、符号化単位（Coding Units，ＣＵ）、ブロック、変換単位（Transform Units，ＴＵ）、予測単位（Prediction Units，ＰＵ）、などを含むことができる。エントロピデコーダ／パーサはまた、変換係数などの符号化されたビデオシーケンスの情報から、量子化パラメータ値、動きベクトル、なども取り出してよい。
【0024】
パーサ（４２０）は、シンボル（４２１）を生成するために、バッファ（４１５）から受信されたビデオシーケンスに対してエントロピ復号化／パーシング動作を実行してよい。
【0025】
シンボル（４２１）の再構成は、符号化されたビデオピクチャ又はその部分のタイプ（例えば、インター及びイントラピクチャ、インター及びイントラブロック）並びに他の因子に依存して多種多様なユニットを有することができる。どのユニットがどのように含まれるかは、符号化されたビデオシーケンスからパーサ（４２０）によってパースされたサブグループ制御情報によって制御され得る。パーサ（４２０）と以下の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明りょうさのために表されていない。
【0026】
既に述べられた機能ブロックを超えて、デコーダ３１０は、概念的に、以下で記載されるように多数の機能ユニットに細分され得る。商業上の制約の下で動作する実際の実施では、それらのユニットの多くが互いに密に相互作用し、少なくとも部分的に互いに組み込まれ得る。なお、開示されている対象を説明するために、以下、機能ユニットへの概念的細分は適切である。
【0027】
第１ユニットは、スケーラ／逆変換ユニット（４５１）である。スケーラ／逆変換ユニット（４５１）は、パーサ（４２０）からシンボル（４２１）として、量子化された変換係数とともに、使用するために変換するもの、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報を受信する。パーサ（４２０）は、サンプル値を含むブロックを出力することができ、これはアグリゲータ（４５５）へ入力され得る。
【0028】
いくつかの場合に、スケーラ／逆変換器（４５１）の出力サンプルは、イントラ符号化されたブロック、すなわち、前に再構成されたピクチャからの予測情報を使用しておらず、現在のピクチャの前の再構成された部分からの予測情報を使用することができるブロックに関係することができる。そのような予測情報は、イントラピクチャ予測ユニット（４５２）によって供給され得る。いくつかの場合に、イントラピクチャ予測ユニット（４５２）は、現在の（部分的に再構成された）ピクチャ（４５６）からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックの同じサイズ及び形状のブロックを生成する。アグリゲータ（４５５）は、いくつかの場合に、サンプルごとに、イントラ予測ユニット（４５２）が生成した予測情報を、スケーラ／逆変換ユニット（４５１）によって供給される出力サンプル情報に加える。
【0029】
他の場合に、スケーラ／逆変換ユニット（４５１）の出力サンプルは、インター符号化された、そして潜在的に動き補償されたブロックに関係することができる。そのような場合に、動き補償予測ユニット（４５３）は、予測のために使用されるサンプルをフェッチするために参照ピクチャメモリ（４５７）にアクセスすることができる。ブロックに関係するシンボル（４２１）に従ってフェッチされたサンプルを動き補償した後、それらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（４５５）によってスケーラ／逆変換ユニットの出力（この場合に、残差サンプル又は残差信号と呼ばれる）に加えられる得る。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、例えば、Ｘ、Ｙ及び参照ピクチャコンポーネントを有することができるシンボル（４２１）の形で動き補償ユニットが利用することができる動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズムなどを含むことができる。
【0030】
アグリゲータ（４５５）の出力サンプルは、ループフィルタユニット（４５６）において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタリング技術を含むことができる。この技術は、符号化されたビデオビットストリームに含まれており、パーサ（４２０）からのシンボルとしてループフィルタユニット（４５６）に利用可能にされたパラメータによって制御されるが、符号化されたピクチャ又は符号化されたビデオシーケンスの（復号化順序において）前の部分の復号化の間に得られたメタ情報にも応答することができ、更には、前に構成されたループフィルタ処理されたサンプル値に応答することができる。
【0031】
ループフィルタフィルタ（４５６）の出力は、レンダリングデバイス（３１２）へ出力され、更には、将来のインターピクチャ予測における使用のために参照ピクチャメモリ（４５６）に記憶され得るサンプルストリームであることができる。
【0032】
特定の符号化されたピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用され得る。符号化されたピクチャが完全に再構成され、符号化されたピクチャが（例えば、パーサ（４２０）によって）参照ピクチャとして識別されると、現在の参照ピクチャ（４５６）は、参照ピクチャバッファの部分になることができ、新しい現在ピクチャメモリが、後続の符号化されたピクチャの再構成を開始する前に再割当てされ得る。
【0033】
ビデオデコーダ４２０は、ＩＴＵ－Ｔ推奨Ｈ．２６５などの標準規格において文書化され得る所定のビデオ圧縮技術に従って復号化動作を実行してよい。符号化されたビデオシーケンスは、それが、ビデオ圧縮技術文書又は標準規格において、具体的にその中のプロファイル文書において規定されているビデオ圧縮技術又は標準規格のシンタックスに従うという意味で、使用中のビデオ圧縮技術又は標準規格によって規定されたシンタックスに従い得る。また、符号化されたビデオシーケンスの複雑さは、ビデオ圧縮技術又は標準規格のレベルによって定義された境界内にあることが、順守のために必要である。いくつかの場合に、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、メガサンプル／秒で測定される）、最大参照ピクチャサイズ、などを制限する。レベルによって設定される制限は、いくつかの場合に、ハイポセティカル・リファレンス・デコーダ（Hypothetical Reference Decoder，ＨＲＤ）仕様及び符号化されたビデオシーケンスにおいて示されたＨＲＤバッファ管理のためのメタデータを通じて更に制限され得る。
【0034】
実施形態において、受信器（４１０）は、符号化されたビデオとともに、追加の（冗長の）データを受信してもよい。追加のデータは、符号化されたビデオシーケンスの部分としても含まれてもよい。追加のデータは、ビデオデコーダ（４２０）によって、データを適切に復号するために及び／又は原ビデオデータをより正確に再構成するために使用されてよい。追加のデータは、例えば、時間、空間、又はＳＮＲエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正符号、などの形をとることができる。
【0035】
図５は、本開示の実施形態に従うビデオエンコーダ（３０３）の機能ブロック図であり得る。
【0036】
エンコーダ（３０３）は、エンコーダ（３０３）によって符号化されるべきビデオ画像を捕捉し得るビデオソース（３０１）（エンコーダの部分ではない）からビデオサンプルを受信してよい。
【0037】
ビデオソース（３０１）は、任意の適切なビット深さ（例えば、８ビット、１０ビット、１２ビットなど）、任意の色空間（例えば、ＢＴ．６０１ Ｕ ＣｒＣＢ、ＲＧＢなど）、及び任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であることができるデジタルビデオサンプルストリームの形で、エンコーダ（３０３）によって符号化されるべきソースビデオシーケンスを供給してよい。メディアサービングシステムでは、ビデオソース（３０１）は、前にパースされたビデオを記憶している記憶デバイスであってよい。ビデオ会議システムでは、ビデオソース（３０１）は、ローカル画像情報をビデオシーケンスとして捕捉するカメラであってよい。ビデオデータは、順に見られる場合に動きを授ける複数の個別ピクチャとして供給されてもよい。ピクチャ自体は、ピクセルの空間アレイとして編成されてよく、各ピクセルは、使用中にサンプリング構造、色空間、などに依存する１つ以上のサンプルを有することができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。本明細書は、以下、サンプルに焦点を当てる。
【0038】
実施形態に従って、エンコーダ（３０３）は、実時間において又は用途によって必要とされる任意の他の時間制約の下で、ソースビデオシーケンスを、符号化されたビデオシーケンス（５４３）へと符号化及び圧縮してよい。適切な符号化速度を強いることは、コントローラ（５５０）の一機能である。コントローラは、以下で記載されるように他の機能ユニットを制御し、それらのユニットへ機能上結合される。結合は明りょうさのために表されていない。コントローラによってセットされるパラメータには、レート制御に関連したパラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値、など）、ピクチャサイズ、グループ・オブ・ピクチャ（ＧＯＰ）レイアウト、最大動きベクトル探索範囲、などが含まれ得る。当業者であれば、コントローラ（５５０）の他の機能を、それらが特定のシステム設計のために最適化されたビデオエンコーダ（３０３）に関係し得るということで、容易に識別することができる。
【0039】
いくつかのビデオエンコーダは、当業者が「符号化ループ」として容易に認識するものにおいて動作する。過度に単純化された記載として、符号化ループは、（符号化されるべき入力ピクチャと、参照ピクチャとに基づいて、シンボルを生成することに関与する）エンコーダの符号化部分（５３０）（以降「ソースコーダ」）と、（遠隔の）デコーダも生成することになる（シンボルと符号化されたビデオビットストリームとの間の如何なる圧縮も、開示されている対象で考えられているビデオ圧縮技術において可逆である場合）サンプルデータを生成するようにシンボルを再構成する、エンコーダ（３０３）に埋め込まれた（ローカルの）デコーダ（５３３）とからなることができる。その再構成されたサンプルストリームは、参照ピクチャメモリ（５３４）へ入力される。シンボルストリームの復号化は、デコーダの場所（ローカル又は遠隔）に依存しないビットパーフェクト（bit-exact）な結果をもたらすので、参照ピクチャバッファコンテンツも、ローカルのエンコーダと遠隔のエンコーダとの間でビットパーフェクトである。すなわち、エンコーダの予測部分は、デコーダが復号化の間に予測を使用するときに“見る”ことになるのとまさに同じサンプル値を参照ピクチャサンプルとして“見る”。参照ピクチャのシンクロニシティ（及び、例えば、チャネルエラーのために、シンクロニシティが維持され得ない場合に、結果として生じるドリフト）のこの基本原理は、当業者によく知られている。
【0040】
“ローカル”のデコーダ（５３３）の動作は、図４とともに先に詳細に既に説明されている“遠隔”のデコーダ（３１０）のそれと同じであることができる。一時的に同じく図４を参照すると、しかしながら、シンボルは利用可能であり、エントロピコーダ（５４５）及びパーサ（４２０）による符号化されたビデオシーケンスへのシンボルの符号化／復号化は可逆であることができるので、チャネル（４１２）、受信器（４１０）、バッファ（４１５）、及びパーサ（４２０）を含むデコーダ（３１０）のエントロピ復号化部分は、ローカルのデコーダ（５３３）において完全には実施されなくてよい。
【0041】
この時点で行われ得る観察は、デコーダに存在するパーシング／エントロピデコーダを除く如何なるデコーダ技術も、対応するエンコーダにおいて、実質的に同じ機能形態で、必ずしも存在する必要がないことである。この理由のために、開示されている対象は、デコーダの動作に焦点を当てる。符号化技術の説明は、それらが包括的に記載される復号化技術の逆であるということで、省略され得る。特定の範囲においてのみ、より詳細な説明が必要とされ、以下で与えられている。
【0042】
その動作の部分として、ソースコーダ（５３０）は、動き補償された予測符号化を実行してよい。これは、「参照フレーム」として指定されたビデオシーケンスからの１つ以上の前に符号化されたフレームを参照して予測的に入力フレームを符号化する。このようにして、符号化エンジン（７３２）は、入力フレームに対する予測参照として選択され得る参照フレームのピクセルブロックと入力フレームのピクセルブロックとの間の差を符号化する。
【0043】
ローカルのビデオデコーダ（５３３）は、ソースコーダ（５３０）によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータを復号してよい。符号化エンジン（７３２）は、有利なことに、不可逆プロセスであってよい。符号化されたビデオデータがビデオデコーダ（図５には図示せず。）で復号化され得るとき、再構成されたビデオシーケンスは、通常は、いくらかのエラーを伴ったソースビデオシーケンスの複製であり得る。ローカルのビデオデコーダ（５３３）は、参照フレームに対してビデオデコーダによって実行され得る復号化プロセスを再現し、再構成された参照フレームを参照ピクチャキャッシュ（５３４）に格納されるようにしてよい。このように、エンコーダ（３０３）は、（伝送エラーなしで）遠端のビデオデコーダによって取得されることになる再構成された参照フレームと共通の内容を有している再構成された参照フレームのコピーをローカルで記憶し得る。
【0044】
予測器（５３５）は、符号化エンジン（７３２）の予測探索を実行してよい。すなわち、新しいフレームが符号化されるために、予測器（５３５）は、新しいピクチャのための適切な予測基準となり得る参照ピクチャ動きベクトル、ブロック形状、などの特定のメタデータ又は（候補参照ピクセルブロックとしての）サンプルデータを参照ピクチャメモリ（５３４）から探してよい。予測器（５３５）は、適切な予測基準を見つけるためにサンプルブロック・バイ・ピクセルブロックベース（sample block-by-pixel block basis）で動作してよい。いくつかの場合に、予測器（５３５）によって取得された探索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（５３４）に記憶されている複数の参照ピクチャから引き出された予測基準を有してよい。
【0045】
コントローラ（５５０）は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含め、ビデオコーダ（５３０）の符号化動作を管理してよい。
【0046】
上記の全ての機能ユニットの出力は、エントロピコーダ（５４５）においてエントロピ符号化を受けてよい。エントロピコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化などとして当業者に知られている技術に従ってシンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを、符号化されたビデオシーケンスへと変換する。
【0047】
送信器（５４０）は、エントロピコーダ（５４５）によって生成された符号化されたビデオシーケンスを、それを通信チャネル（５６０）を介した伝送のために準備するようにバッファに入れてよい。通信チャネル（５６０）は、符号化されたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアリンクであってよい。送信器（５４０）は、ビデオコーダ（５３０）からの符号化されたビデオデータを、送信されるべき他のデータ、例えば、符号化されたオーディオデータ及び／又は付随的なデータストリーム（ソースは図示せず）とマージしてもよい。
【0048】
コントローラ（５５０）は、エンコーダ（３０３）の動作を管理してよい。符号化の間、コントローラ（５５０）は、各々のピクチャに適用され得る符号化技術に影響を及ぼす可能性がある特定の符号化されたピクチャタイプを夫々の符号化されたピクチャに割り当ててよい。例えば、ピクチャはしばしば、次のフレームタイプのうちの１つとして割り当てられてよい。
【0049】
イントラピクチャ（Intra Picture）（Ｉピクチャ）は、予測のソースとしてシーケンス内の如何なる他のフレームも使用せずに符号化及び復号化され得るピクチャであってよい。いくつかのビデオコーデックは、例えば、独立したデコーダリフレッシュピクチャ（Independent Decoder Refresh Pictures）を含む種々のタイプのイントラピクチャを許容する。当業者であれば、Ｉピクチャのそのような変形並びにそれらの各々の応用及び特徴に気づく。
【0050】
予測ピクチャ（Predictive Picture）（Ｐピクチャ）は、各ブロックのサンプル値を予測するために多くても１つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。
【0051】
双方向予測ピクチャ（Bi-directionally Predictive Picture）（Ｂピクチャ）は、各ブロックのサンプル値を予測するために多くても２つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。同様に、多重予測ピクチャは、単一のブロックの再構成のために２よりも多い参照ピクチャ及び関連するメタデータを使用することができる。
【0052】
ソースピクチャは、一般に、複数のサンプルブロック（例えば、夫々、４×４、８×８、４×８、又は１６×１６のサンプルのブロック）に空間的に細分され、ブロックごとに符号化されてよい。ブロックは、ブロックの各々のピクチャに適用されている符号化割り当てによって決定される他の（既に符号化された）ブロックを参照して予測的に符号化されてよい。例えば、Ｉピクチャのブロックは、非予測的に符号化されてよく、あるいは、それらは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい（空間予測又はイントラ予測）。Ｐピクチャのピクセルブロックは、非予測的に、あるいは、１つの前に符号化された参照ピクチャを参照して空間予測により又は時間予測により、符号化されてよい。Ｂピクチャのブロックは、非予測的に、あるいは、１つ又は２つの前に符号化された参照ピクチャを参照して空間予測により又は時間予測により、符号化されてよい。
【0053】
ビデオエンコーダ（３０３）は、ＩＴＵ－Ｔ推奨Ｈ．２６５のような所定のビデオ符号化技術又は標準規格に従って符号化動作を実行してよい。その動作中に、ビデオエンコーダ（３０３）は、入力ビデオシーケンスにおける時間及び空間冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してよい。従って、符号化されたビデオデータは、使用されているビデオ符号化技術又は標準規格によって定められているシンタックスに従い得る。
【0054】
実施形態において、送信器（５４０）は、符号化されたビデオとともに追加のデータを送信してもよい。ビデオコーダ（５３０）は、符号化されたビデオシーケンスの部分としてそのようなデータを含めてよい。追加のデータは、時間／空間／ＳＮＲエンハンスメント、冗長ピクチャ及びスライスのような他の形式の冗長データ、ＳＥＩ（Supplementary Enhancement Information）メッセージ又はＶＵＩ（Video Usability Information）パラメータセットフラグメント、などを有してよい。
【0055】
以下では、より古いビデオ符号化標準規格及び技術で一般的な８ビットのビット列によるプロファイル表現、並びにＴ．３５文字列によるサブプロファイル表現が考えられる。ＩＴＵ－Ｔ推奨Ｔ．３５は、最低限２つのオクテットから構成される登録フォーマットを規定する。第１オクテットは、国際連合加盟国の国名コードを運ぶ。登録を得るために、エンティティ（例えば、ビジネス、又はいくつかの国では、個人）は、現地の規制当局に働きかけ、第２オクテットにおいて符号化されている２５６のコードポイントのうちの１つを要求することができる。組織内で、第３、第４、第５などのオクテットが割り当てられ得る。Ｔ．３５文字列におけるそれら２つ以上のオクテットの内容は登録され得る。更なるオクテットが必要に応じてＴ．３５文字列に加えられてよく、たとえ番号空間の管理が第１及び第２オクテットにより識別されるビジネス又は個人に付与されているとしても、その番号空間の増大を可能にする。
【0056】
開示されている対象は、Ｔ．３５文字列によるプロファイル又はサブプロファイル表現に限られない。他のオプションには、ユニフォーム・リソース・アイデンティファイア（ＵＲＩ，ＩＡＮＡを通じて登録され得る文字列）、ユニバーサリー・ユニーク・アイデンティファイア（ＵＵＩＤ，一意性のためにハッシュ関数及び膨大な番号空間に依存して自己登録される１２８ビット長の識別子）などがある。本願で開示されているプロファイル及びサブプロファイル識別と、ＭＰＥＧ及び他のメディア標準規格で使用される従来のプロファイルＩＤとの間の相違を区別することは、プロファイル若しくはサブプロファイル又はそれら２つの組み合わせの番号空間がビットマスクによって合理的に表現されるには大きすぎることである。すなわち、番号空間は、ビットマスク符号化が、多くのメディア符号化標準規格の目標、すなわち圧縮を否定し得るほどに大きい可能性がある。
【0057】
以下では、一例としてプロファイル及びサブプロファイルを使用する複数のコンフォーマンスポイントのシグナリングについて記載する。なお、開示されている対象は、他の非オニオン形コンフォーマンスポイントのために同様に使用され得る。考えられるところでは、レベルは、オニオン形でなくてもよく、例えば、特定の４：３アスペクト比ビデオ画像のみをカバーするレベルと、特定の９：１６アスペクト比ビデオ画像のみをカバーする他のレベルとを考える。更に別のものは、レベルが現在Ｈ．２６５にあるということで、アスペクト比に対して不可知的である。そのようなレベル定義はＭＰＥＧの歴史では珍しいかもしれないが、一方で、それらは、特定のアプリケーション標準規格で使用中である。
【0058】
図６を参照すると、実施形態に従って、Ｔ．３５文字列、ＵＵＩＤ、ＵＲＩ、又は長さが少なくとも２４ビットの同様の表現によって表される１つ以上のサブプロファイルは、文字列のリスト（６０４）の形をとるビットストリームへと符号化され得る。各文字列は、終端記号を用いながら一定の所定の長さ又は可変長さを有することを有する。例えば、開示されている対象において使用されているＴ．３５文字列は、例えば、３、４、５などのオクテットの所定長さを有することができる。ＵＵＩＤは、定義によって、１２８ビット又は１６オクテットの長さを有する。ＵＲＩは、ゼロ終端文字列として形成され得る。このとき、ゼロの値を有しているオクテットは、文字列の終わりをマークし、文字列は、可変な長さを有することができる。Ｔ．３５文字列の４オクテット表現を前提とするシンタックス図が以下で示される。
【0059】
図６を参照すると、同じ又は他の実施形態で、リストは、シンタックス図（６０１）において、一定数の繰り返しを有するループ（６０３）の形で容易に表現され得る。シンタックス要素“num_sub_profiles”（６０２）は、表されるべきサブプロファイルの数を示すことができる。そのシンタックス要素（６０２）は、固定長バイナリ符号化されても、可変長符号化されても、あるいは、何らかの他の適切な符号化スキームに従ってもよい。ue(v)によって示されるように、可変長符号化されたシンタックス要素が示されている。
【0060】
サブプロファイリングメカニズムが任意である環境では、シンタックス要素は、Ｈ．２６４又はＨ．２６５のue(v)定義を用いて可変長符号化され得る。シングルビット表現は、サブプロファイルリストに含まれるべきゼロサブプロファイルの数を示す。プロファイルのために使用されるとき、少なくとも１つのプロファイルを伝達することが有利であることができ、従って、ue(v)符号化スキームのシングルビット値を１つのプロファイルの符号化に割り当てることができ、シンタックス違反なしで最低限必要とされるものにする。
【0061】
サブプロファイルインジケータ（６０４）は、如何なる適切なエントロピ符号化フォーマットでも表現され得る。ここでは、b(32)によって表される３２ビットのビット列が示されている。このビット列は、サブプロファイルＩＤの４オクテットＴ．３５表現を符号化するのに十分である。他の長さのサブプロファイルインジケータ（６０４）も可能である。特に、Ｔ．３５符号化サブプロファイルインジケータの最低限の検知可能な長さは。２４ビット、すなわち、国名コード用の８ビット、ターミナルプロバイダコード用の８ビット、及びその国においてそのターミナルプロバイダによって定義されるサブプロファイルコード用の８ビット、であることができる。
【0062】
シンタックス構造（６０１）は、例えば、デコーダパラメータセット、ビデオパラメータセット（Ｈ．２６５で定義されるＶＰＳ）、シーケンスパラメータセット（Ｈ．２６４及びＨ．２６５で定義されるＳＰＳ）などの高位パラメータセットにおいて、並びにシーケンスヘッダ、ＧＯＰヘッダ、又はＭＰＥＧ－２若しくはＭＰＥＧ－４で定義されるピクチャヘッダなどの高位ヘッダ構造において含まれ得る。シンタックス構造はまた、例えば、ケイパビリティアナウンス又は交換のためのプロトコルで使用されるメタデータの形で、ビットストリームの外で利用可能であってよい。その中で、それは、例えば、ＡＳＮ．１、ＳＤＰ、ＸＭＬ、などのようなシンタックスにおいて、符号化され得る。
【0063】
ビットストリームコンフォーマンスポイントはまた、本願で記載されるように複数のコンフォーマンスポイントの組み合わせとして定義されてもよい。例えば、ビットストリームコンフォーマンスポイントは、例えば、８ビット固定長さコードワードによって表現され得るプロファイルＩＤと、Ｔ．３５文字列によって表現され得るサブプロファイルＩＤとの組み合わせとして定義されてよい。その場合に、Ｔ．３５文字列は、プロファイルＩＤによって識別されるサブプロファイルを識別し得る。結果として、同じサブプロファイルＩＤは、プロファイルに応じて、異なるビットストリームコンフォーマンスポイントを識別し得る。
【0064】
ビットストリームにおいて、又は上記のメカニズム若しくはそれと実質的に類似したメカニズムに従うメタデータの形で、複数のコンフォーマンスポイントの存在のための多数の可能な使用が存在する。
【0065】
一例として、夫々がおそらくは互いにわずかに異なる複数のデコーダエコシステムの存在を考える。そのようなエコシステムは、特定の国家標準（例えば、米国におけるＡＴＳＣ、欧州におけるＤＶＢ、日本におけるＡＲＩＢ）であってよく、それらの夫々は、国又は地域の好み又はニーズに従って“メイン”プロファイルをサブプロファイリングすることを必要とする。また、デコーダ要件が夫々わずかに異なっている複数の“ウォールド・ガーデン”（walled garden）エコシステムを考える。例えば、テンセント、Ｎｅｔｆｌｉｘ（登録商標）、Ｈｕｌｕ（登録商標）、及びＹｏｕＴｕｂｅ（登録商標）を考える。
【0066】
これより、複数のエンコーダを実行せずに複数のエコシステムへコンテンツを提供したいと望むコンテンツプロバイダを考える。そうすることには、多くの商業上の利点がある。コンテンツプロバイダは、それがサービスを提供したいと望む全てのエコシステムの詳細な要件を、それらのサブプロファイリングＴ．３５文字列とともに、よく知っていることがある。エコシステム間の要件が矛盾しない限りは、コンテンツプロバイダは、一方では条件下で任意の圧縮性能を可能にするが、他方では全ての対象とされるエコシステムのデコーダによる復号化を依然として可能にする最大ツールセットを識別するために、最小公分母アプローチを使用することができる。
【0067】
コンテンツプロバイダは、その最小公分母アプローチに従ってソース素材を符号化し、“メインプロファイル”をプロファイルとして示し、全ての例えばＡＴＳＣ、ＤＶＢ、及びＡＲＩＢのためのサブプロファイルを示す。夫々のＡＴＳＣ、ＤＶＢ、及びＡＲＩＢは、それらの関連するサブプロファイルＩＤを適切な登録機関に、Ｔ．３５の場合に、例えば、ＩＴＵ－Ｔに及び／又は関連する現地の規制当局によって定められた現地の登録機関に登録していることがある。例えば、ＡＴＳＣは、その関連するサブプロファイルを米国の規制当局に登録し、１８１（米国の国名コード）に等しいオクテットから始まって、例えば、残り３つのオクテットの値が０１、０２及び０３である４オクテットＴ．３５文字列を受理していることがある。同様に、ＤＶＢは、６６、０４、０５、０６に等しい４オクテット文字列を受理し、ＡＲＩＢは、００ ０７ ０８ ０９に等しい文字列を受理していてよい。結果として得られるサブプロファイルテーブルは、次のとおりである：
num_sub_profile = 2
sub_profile_t35_string[0] = 181 01 02 03
sub_profile_t35_string[1] = 66 04 05 06
sub_profile_t35_string[2] = 00 07 08 09
num_sub_profile = 2
sub_profile_t35_string[0] = 181 01 02 03
sub_profile_t35_string[1] = 66 04 05 06
sub_profile_t35_string[2] = 00 07 08 09
【0068】
目下、エコシステムデコーダは、所与のプロファイルＩＤ、しばしばメイン、しかし、所与のエコシステムによって必要とされる他の制約の無言の順守を広く期待する。そのような適合性は、サブプロファイルＩＤにおいて示され得る。コンテンツプロバイダからビットストリームを取得したコンテンツサーバを考える。コンテンツサーバは、所与のビットストリームがエコシステムと互換性があるかどうかを確認するためにサブプロファイルＩＤをパースし、互換性がある場合にのみそれを差し出しかつそれを提供することができる。
【0069】
上記の例では、ロシアにあるサードパーティプロバイダからビットストリームを受信した、日本にあってＡＲＩＢ標準に従うコンテンツサーバを考える。ビットストリームは、メインプロファイルを示し得る。その情報だけでは、開示されている対象を欠くために、コンテンツサーバは、ＡＲＩＢ標準に従って作動する日本国内のデコーダが、ＡＲＩＢ仕様互換性を確かめるためにビットストリーム全体をパースすることを少なくともなしとせずに、ロシアのビットストリームを有意義に受信及び復号することができるかどうかを知らない。しかし、ビットストリームが上述されたようにマークされる場合には、コンテンツサーバは、サブプロファイル文字列を期待することができる高位シンタックス構造をパースすることができる。ＡＲＩＢ指示を含むサブプロファイル指示を見つけると、それは、ビットストリームがＡＲＩＢ標準の要件を順守しながら符号化されたと考え、躊躇なくそれを（ＡＲＩＢ対応）デコーダへ提供することができる。同様に、ドイツに位置し、ＤＶＢ対応コンテンツを期待するコンテンツサーバ、又は米国に位置し、ＡＴＳＣ対応コンテンツを期待するコンテンツサーバは、それらの各々のデコーダへビットストリームを同じく提供することができる。
【0070】
代替案として、特定のエコシステムデコーダは、適切なサブプロファイルＩＤが、復号化を試みる前でさえ、ビットストリームに存在することを求めてもよい。
【0071】
図７は、実施形態に従うプロセスの例のフローチャートである。
【0072】
図７に示されるように、プロセス７００は、符号化されたビデオシーケンスの第１コンフォーマンスポイントを示す第１指示を復号すること（ブロック７１０）を含んでよい。
【0073】
図７に更に示されるように、プロセス７００は、符号化されたビデオシーケンスの第２コンフォーマンスポイントを示す第２指示を復号すること（ブロック７２０）を含んでよい。
【0074】
図７に更に示されるように、プロセス７００は、第１指示及び第２指示に基づいて、結合されたコンフォーマンスポイントを識別すること（ブロック７３０）を含んでよい。
【0075】
図７に更に示されるように、プロセス７００は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定すること（ブロック７４０）を含んでよい。
【0076】
図７に更に示されるように、プロセス７００は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号することを含んでよい。例えば、符号化されたビデオシーケンスがデコーダによって復号可能でない場合（ブロック７４０－いいえ）、次いで、プロセス７００は、符号化されたビデオシーケンスの復号化を阻止すること（ブロック７５０）を含んでよい。代替的に、符号化されたビデオシーケンスがデコーダによって復号可能である場合（ブロック７４０－はい）、次いで、プロセス７００は、符号化されたビデオシーケンスを復号すること（ブロック７６０）を含んでよい。
【0077】
追加的に、又は代替的に、プロセス７００は、符号化されたビデオシーケンスの第１コンフォーマンスポイントを示す第１指示を復号することを含んでよい。更に、プロセス７００は、符号化されたビデオシーケンスの第２コンフォーマンスポイントを示す第２指示を復号することを含んでよい。更に、プロセス７００は、第１コンフォーマンスポイント及び第２コンフォーマンスポイントのうちの少なくとも１つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定することを含んでよい。また更には、プロセス７００は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号することを含んでよい。
【0078】
いくつかの場合に、第１指示は、ＩＴＵ－Ｔ推奨Ｔ．３５に従って符号化される。追加的に、又は代替的に、第１指示は、第１高位シンタックス構造に存在する複数の第１指示のうちの１つであり、第１高位シンタックス構造は、少なくとも符号化されたビデオシーケンスに関係がある。追加的に、又は代替的に、複数の第１指示は、第１指示のリストとしてまとめられ、リスト内の第１指示の数は、可変長さの符号なしコードワードとして第１高位シンタックス構造において符号化される。
【0079】
いくつかの場合に、第１指示は、第１高位シンタックス構造に存在し、第２指示は、第２高位シンタックス構造に存在し、第１高位シンタックス構造は、第２高位シンタックス構造とは異なる。
【0080】
いくつかの場合に、第１指示は、長さが少なくとも３つのオクテットのオクテット列に符号化され、第１指示は、第２指示のサブプロファイルである。
【0081】
いくつかの場合に、プロセス７００は、第１指示及び第２指示を結合することと、第１指示及び第２指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別することとを含む。追加的に、又は代替的に、プロセス７００は、結合されたコンフォーマンスポイントとデコーダのケイパビリティ（capability information）とを比較することと、結合されたコンフォーマンスポイントとデコーダのケイパビリティ情報との比較に基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定することとを含む。
【0082】
いくつかの場合に、メディアビットストリームは、第１コンフォーマンスポイント及び第２コンフォーマンスポイントの両方に対応する。
【0083】
メディア符号化において複数のコンフォーマンスポイントを伝達するための上記の技術は、コンピュータ読み出し可能な命令を使用しかつ１つ以上のコンピュータ可読媒体に物理的に記憶されているコンピュータソフトウェアとして、実装され得る。例えば、図８は、開示されている対象の特定の実施形態を実装することに適したコンピュータシステム８００を示す。
【0084】
コンピュータソフトウェアは、中央演算処理装置（ＣＰＵ）、グラフィクス処理ユニット（ＧＰＵ）などによって直接に又は解釈、マイクロコード実行などを通じて実行され得る命令を含むコードを生成するようにアセンブリ、コンパイル、リンキングなどを受け得る如何なる適切な機械コード又はコンピュータ言語によっても符号化され得る。
【0085】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネット（Internet of Things）のためのデバイス、などを含む様々なタイプのコンピュータ又はその構成要素で実行され得る。
【0086】
コンピュータシステム８００に関して図８に示される構成要素は、本質的に例示であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関して如何なる制限も示唆することを意図しない。構成要素の構成は、コンピュータシステム８００の例となる実施形態に表されている構成要素のうちのいずれか１つ又は組み合わせに関して何らかの依存又は要件も有するものとして解釈されるべきではない。
【0087】
コンピュータシステム８００は、特定のヒューマンインターフェイス入力デバイスを含んでよい。そのようなヒューマンインターフェイス入力デバイスは、例えば、触覚入力（例えば、キーボード、スワイプ、データグロープ動作）、音声入力（例えば、声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず。）を通じた一人以上のユーザによる入力に関与してよい。ヒューマンインターフェイスデバイスはまた、音声（例えば、発話、音楽、周囲音）、画像（例えば、スキャンされた画像、静止画カメラから取得された写真画像）、映像（例えば、二次元映像、立体視映像を含む三次元映像）など、人による意識的な入力に必ずしも直接には関係しない特定のメディアを捕捉するためにも使用され得る。
【0088】
入力ヒューマンインターフェイスデバイスは、キーボード８０１、マウス８０２、トラックパッド８０３、タッチスクリーン８１０、データグローブ８０４、ジョイスティック８０５、マイク８０６、スキャナ８０７、カメラ８０８のうちの１つ以上（夫々表されているもののうちの１つのみ）を含んでよい。
【0089】
コンピュータシステム８００は、特定のヒューマンインターフェイス出力デバイスも含んでよい。そのようなヒューマンインターフェイス出力デバイスは、例えば、触覚出力、音響、光、及び匂い／味を通じて一人以上のユーザの感覚を刺激し得る。そのようなヒューマンインターフェイス出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン８１０、データグローブ８０４、又はジョイスティック８０５による触覚フィードバック、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る）、音声出力デバイス（例えば、スピーカ８０９、ヘッドホン（図示せず））、視覚出力デバイス（例えば、タッチスクリーン入力機能の有無によらず、触覚フィードバック機能の有無によらず、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含み、それらのいくつかは、立体視出力、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）などの手段により二次元視覚出力又は三次元よりも多い次元の出力を出力する機能がある、スクリーン８１０）、及びプリンタ（図示せず。）を含んでよい。
【0090】
コンピュータシステム８００は、人がアクセス可能な記憶デバイス及びそれらの関連する媒体、例えば、ＣＤ／ＤＶＤ又は同様の媒体８２１を伴ったＣＤ／ＤＶＤ ＲＯＭ／ＲＷ８２０、サムドライブ８２２、リムーバブルハードディスク又はソリッドステートドライブ８２３、レガシー磁気媒体、例えば、テープ及びフロッピー（登録商標）ディスク（図示せず）、専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースデバイス、例えば、セキュリティドングル（図示せず）、なども含むことができる。
【0091】
当業者であれば、目下開示されている対象に関連して使用されている語「コンピュータ可読媒体」が、伝送媒体、搬送波、又は他の一時的な信号を含まないことも理解するはずである。
【0092】
コンピュータシステム８００は、１つ以上の通信ネットワークへのインターフェイスも含むことができる。ネットワークは、例えば、無線、有線、光であることができる。ネットワークは更に、ローカル、ワイドエリア、メトロポリタン、車両及び工業、実時間、遅延耐性、などであることができる。ネットワークの例には、イーサネット（登録商標）などのローカルエリアネットワーク、ワイヤレスＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛生ＴＶ、及び地上放送ＴＶを含むＴＶ有線又は無線ワイドエリアデジタルネットワーク、ＣＡＮバスを含む車載及び工場ネットワーク、などがある。特定のネットワークは、一般に、コンピュータシステム８００の例えばＵＳＢポートなどの特定の汎用デジタルポート又はペリフェラルバス（８４９）に取り付けられた外付けネットワークインターフェイスアダプタを必要とする。他は、一般に、後述されるようにシステムバスへの取り付け（例えば、ＰＣコンピュータシステムへのイーサネットネットワーク、又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェイス）によってコンピュータシステム８００のコアに組み込まれる。それらのネットワークのいずれかを使用して、コンピュータシステム８００は他のエンティティと通信することができる。そのような通信は、単方向の受信専用（例えば、ブロードキャストＴＶ）、単方向の送信専用（例えば、特定のＣＡＮバスデバイスへのＣＡＮバス）、又は例えば、ローカル若しくはワイドエリアデジタルネットワークを用いて他のコンピュータシステムに対して双方向であることができる。特定のプロトコル又はプロトコルスタックが、上述されたネットワーク及びネットワークインターフェイスの夫々で使用可能である。
【0093】
上記のヒューマンインターフェイスデバイス、人がアクセス記憶デバイス、及びネットワークインターフェイスは、コンピュータシステム８００のコア８４０へ取り付けられ得る。
【0094】
コア８４０は、１つ以上の中央演算処理装置（ＣＰＵ）８４１、グラフィクス処理ユニット（ＧＰＵ）８４２、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）８４３の形をとる専用のプログラム可能処理ユニット、特定のタスクのためのハードウェアアクセラレータ８４４、などを含むことができる。それらのデバイスは、リードオンリーメモリ（ＲＯＭ）８４５、ランダムアクセスメモリ（ＲＡＭ）８４６、内部のユーザアクセス不能ハードドライブなどの内蔵大容量記憶装置、ＳＳＤ、など８４７とともに、システムバス８４８を通じて接続されてよい。いくつかのコンピュータシステムでは、システムバス８４８は、更なるＣＰＵ、ＧＰＵなどによって拡張を可能にするように、１つ以上の物理プラグの形でアクセス可能であることができる。コアのシステムバス８４８へ直接似又はペリフェラルバス８４９を通じて、周辺機器が取り付けられ得る。ペリフェラルバスのためのアーキテクチャには、ＰＣＩ、ＵＳＢなどがある。
【0095】
ＣＰＵ８４１、ＧＰＵ８４２、ＦＰＧＡ８４３、及びアクセラレータ８４４は、組み合わせて上記のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ８４５又はＲＡＭ８４６に記憶され得る。一時データもＲＡＭ８４６に記憶可能であり、一方、永続データは、例えば、内蔵大容量記憶装置８４７に記憶可能である。メモリデバイスのいずれかへの高速な格納及び読み出しは、キャッシュメモリの使用により可能にされ得る。キャッシュメモリは、１つ以上のＣＰＵ８４１、ＧＰＵ８４２、大容量記憶装置８４７、ＲＯＭ８４５、ＲＡＭ８４６などと密接に関連し得る。
【0096】
コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構成されたものであることができ、あるいは、それらは、コンピュータソフトウェア技術で通常の知識を有するものによく知られており利用可能である種類のものであることができる。
【0097】
例として、制限なしに、アーキテクチャ８００、具体的にはコア８４０を有するコンピュータシステムは、１つ以上の有形なコンピュータ可読媒体において具現されているソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ、などを含む）の結果として機能を提供することができる。そのようなコンピュータ可読媒体は、コア内蔵大容量記憶装置８４７又はＲＯＭ８４５などの非一時的な性質であるコア８４０の特定の記憶装置に加えて、先に紹介されたユーザアクセス可能な大容量記憶装置に関連した媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア８４０によって実行され得る。コンピュータ可読媒体には、特定のニーズに従って、１つ以上のメモリデバイス又はチップが含まれ得る。ソフトウェアは、コア８４０、具体的にはその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ８４６に記憶されているデータ構造を定義し、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することを含め、本願で記載される特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。加えて、又は代替案として、コンピュータシステムは、本願で記載される特定のプロセス又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はそれとともに動作することができる、回路内でハードウェアにより実現されるか又は別なふうに具現されるロジックの結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶している回路（例えば、集積回路（ＩＣ））、実行のためのロジックを具現する回路、又は両方を包含することができる。本開示は、ハードウェア及びソフトウェアの如何なる適切な組み合わせも包含する。
【0098】
本開示は、いくつかの例となる実施形態について記載してきたが、本開示の範囲内にある代替、交換、及び様々な置換均等物が存在する。よって、明らかなように、当業者であれば、たとえ本願で明示的に図示又は記載されていなくても、本開示の原理を具現し、よって、その主旨及び適用範囲の中にある多数のシステム及び方法に想到可能である。
【0099】
［関連出願の相互参照］
本願は、米国特許商標庁において、２０１８年１０月２３日付けで出願された米国特許仮出願第６２／７４９２８３号及び２０１９年７月８日付けで出願された米国特許出願第１６／５０４４４３号に対して、３５ Ｕ．Ｓ．Ｃ第１１９条の下で、優先権を主張する。なお、これら米国特許出願の開示は、その全文を参照により本願に援用される。
本願は、米国特許商標庁において、２０１８年１０月２３日付けで出願された米国特許仮出願第６２／７４９２８３号及び２０１９年７月８日付けで出願された米国特許出願第１６／５０４４４３号に対して、３５ Ｕ．Ｓ．Ｃ第１１９条の下で、優先権を主張する。なお、これら米国特許出願の開示は、その全文を参照により本願に援用される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
