(57)【特許請求の範囲】
【請求項１】
ビデオ情報を符号化するための装置であって、
ビデオ情報を記憶するように構成されたメモリと、
前記メモリに動作可能に結合され、
シグナリングするための１つまたは複数のビュー識別子のビット深度を決定すること、ここにおいて、前記１つまたは複数のビュー識別子のそれぞれが符号化されるべきレイヤに関連付けられ、前記ビット深度は、前記ビュー識別子をシグナリングするために使用されるビット単位での長さである、と、
ビットストリームのビデオパラメータセット（ＶＰＳ）内で前記１つまたは複数のビュー識別子の前記ビット深度をシグナリングすること、ここにおいて、前記ＶＰＳは、前記ビットストリームで全てのレイヤに、およびアクセスユニットのシーケンスにわたって適用されるパラメータのセットを含む、と、
前記ＶＰＳにおけるシンタックス要素に基づいて、ビットストリーム内で１つまたは複数のビュー識別子をシグナリングするかどうかを決定し、および前記ビュー識別子が前記ビットストリーム内でシグナリングされるとき、前記ＶＰＳにおいて、前記シグナリングされたビット深度によって示される前記決定されたビット深度のビットの数を使用して、前記ビットストリーム内で前記１つまたは複数のビュー識別子をシグナリングすることと
を行うように構成されたコンピューティングハードウェアと
を備え、
前記シグナリングされたビット深度によって示されるビットの数が１ビットと１６ビットとの間である、
装置。
【請求項２】
ビデオ情報を復号するための装置であって、
ビデオ情報を記憶するように構成されたメモリと、
前記メモリに動作可能に結合され、
ビデオパラメータセット（ＶＰＳ）におけるシンタックス要素に基づいて、ビットストリーム内で１つまたは複数のビュー識別子を復号するかどうかを決定すること、ここにおいて、前記ＶＰＳは、前記ビットストリームで全てのレイヤに、およびアクセスユニットのシーケンスにわたって適用されるパラメータのセットを含む、と、
前記ビュー識別子が復号されるとき、前記１つまたは複数のビュー識別子値を受信して、前記ＶＰＳにおいて受信されたビット深度インジケータを復号すること、前記ビット深度インジケータは、前記１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示し、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられる、と、
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として復号することと
を行うように構成されたコンピューティングハードウェアと
を備え、
前記シグナリングされたビット深度によって示されるビットの数が１ビットと１６ビットとの間である、
装置。
【請求項３】
前記コンピューティングハードウェアが、符号化されるべきビューの最大数に基づいて、前記１つまたは複数のビュー識別子の前記ビット深度を決定するようにさらに構成される、請求項１に記載の装置。
【請求項４】
前記装置が、
デスクトップコンピュータ、ノートブックコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、電話ハンドセット、スマートフォン、ワイヤレス通信デバイス、スマートパッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、またはビデオストリーミングデバイス
のうちの１つまたは複数を備える、請求項１または請求項２に記載の装置。
【請求項５】
ビデオデータをキャプチャするように構成されたカメラをさらに備える、請求項１または請求項２に記載の装置。
【請求項６】
復号されたビデオデータを表示するように構成されたディスプレイをさらに備える、請求項１または請求項２に記載の装置。
【請求項７】
ビュー識別子ビット深度をシグナリングする方法であって、
シグナリングするための１つまたは複数のビュー識別子のビット深度を決定すること、ここにおいて、前記１つまたは複数のビュー識別子のそれぞれが符号化されるべきレイヤに関連付けられ、前記ビット深度は、前記ビュー識別子をシグナリングするために使用されるビット単位での長さである、と、
ビットストリームのビデオパラメータストリーム（ＶＰＳ）内で前記１つまたは複数のビュー識別子の前記ビット深度をシグナリングすること、ここにおいて、前記ＶＰＳは、前記ビットストリームで全てのレイヤに、およびアクセスユニットのシーケンスにわたって適用されるパラメータのセットを含む、と、
前記ＶＰＳにおけるシンタックス要素に基づいて、前記ビットストリーム内で１つまたは複数のビュー識別子をシグナリングするかどうかを決定し、および前記ビュー識別子が前記ビットストリーム内でシグナリングされるとき、前記ＶＰＳにおいて、前記シグナリングされたビット深度によって示される前記決定されたビット深度のビットの数を使用して、前記１つまたは複数のビュー識別子をシグナリングすることと
を備え、
前記シグナリングされたビット深度によって示されるビットの数が１ビットと１６ビットとの間である、
方法。
【請求項８】
ビデオ情報を復号する方法であって、
ビデオパラメータセット（ＶＰＳ）におけるシンタックス要素に基づいて、ビットストリーム内で１つまたは複数のビュー識別子を復号するかどうかを決定すること、ここにおいて、前記ＶＰＳは、前記ビットストリームで全てのレイヤに、およびアクセスユニットのシーケンスにわたって適用されるパラメータのセットを含む、と、
前記ビュー識別子が復号されるとき、前記１つまたは複数のビュー識別子値を受信して、前記ＶＰＳにおいて受信されたビット深度インジケータを復号すること、前記ビット深度インジケータは、１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示し、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤに関連付けられる、と
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として復号することと
を備え、
前記シグナリングされたビット深度によって示されるビットの数が１ビットと１６ビットとの間である、
方法。
【請求項９】
符号化されるべきビューの最大数に基づいて、前記１つまたは複数のビュー識別子の前記ビット深度を決定することをさらに備える、請求項７に記載の方法。
【請求項１０】
コンピューティングハードウェアを備えるプロセッサ上で実行されると、前記プロセッサに、請求項７から請求項９のいずれか一項に記載の方法を実行させる命令を備える、
非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本開示は、ビデオコーディングおよび圧縮の分野に関する。詳細には、本開示は、アドバンストビデオコーディング（ＡＶＣ）のためのスケーラブルビデオコーディング（ＳＶＣ）を含むＳＶＣ、ならびにスケーラブルＨＥＶＣ（ＳＨＶＣ）とも呼ばれる高効率ビデオコーディング（ＨＥＶＣ）のためのＳＶＣに関する。本開示は、ＭＶ−ＨＥＶＣおよび３Ｄ−ＨＥＶＣと呼ばれる、ＨＥＶＣのマルチビュー拡張などの３Ｄビデオコーディングにも関する。様々な実施形態は、ビデオパラメータセット（ＶＰＳ）内でビュー識別子（ＩＤ）ビット深度をシグナリングして、ビットレート情報および／またはピクチャレート情報をシグナリングするためのシステムおよび方法、ならびに関連プロセスに関する。
【背景技術】
【０００２】
[0002]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ  １０，Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法など、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００３】
[0003]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコーディングされた（Ｉ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコーディングされた（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００４】
[0004]空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コード化ブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて、残差変換係数が得られ得、その残差変換係数は、次いで量子化され得る。量子化変換係数は、最初は２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するために、エントロピーコーディングが適用され得る。
【発明の概要】
【０００５】
[0005]一般的に、本開示は、スケーラブルビデオコーディング（ＳＶＣ）に関する技法を説明する。以下で説明する様々な技法は、ＶＰＳ内でビューＩＤビット深度をシグナリングして、ビットレート情報および／またはピクチャレート情報をシグナリングするための方法およびデバイスを提供する。
【０００６】
[0006]特定の態様によるビデオ情報を符号化するための装置は、メモリとコンピューティングハードウェアとを含む。メモリは、ビデオ情報を記憶するように構成されている。コンピューティングハードウェアは、シグナリングするための１つまたは複数のビュー識別子のビット深度を決定するように構成されており、ここにおいて、１つまたは複数のビュー識別子のそれぞれは符号化されるべきレイヤに関連付けられている。コンピューティングハードウェアは、ビットストリーム内で１つまたは複数のビュー識別子のビット深度をシグナリングするようにさらに構成されている。
【０００７】
[0007]特定の態様によるビデオ情報を復号するための装置は、メモリとコンピューティングハードウェアとを含む。メモリは、ビデオ情報を記憶するように構成されている。コンピューティングハードウェアは、１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信するように構成されており、ここにおいて、１つまたは複数のビュー識別子値のそれぞれは、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられている。コンピューティングハードウェアは、１つまたは複数のビュー識別子値のそれぞれを、示された数のビットを有する値として受信するようにさらに構成されている。
【０００８】
[0008]特定の態様によるビデオ情報をコーディングするための装置は、メモリとコンピューティングハードウェアとを含む。メモリは、ビデオ情報を記憶するように構成されている。コンピューティングハードウェアは、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示す第１の信号、または、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示す第２の信号のうちの少なくとも１つを処理するように構成されている。
【０００９】
[0009]１つまたは複数の例の詳細を、添付の図面および以下の説明に記載し、これは、本明細書で説明する本発明の概念の完全な範囲を限定するものではない。他の特徴、目的、および利点は、その説明および図面から、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１０】
[0010]図面全体にわたって、参照される要素間の対応を示すために参照番号が再使用される場合がある。図面は、本明細書に記載される例示的な実施形態を図示するために提供され、本開示の範囲を限定するものではない。
【図１】[0011]本開示で説明する態様に従って技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２Ａ】[0012]本開示で説明する態様に従って技法を実装し得るビデオエンコーダの一例を示すブロック図。
【図２Ｂ】[0013]本開示で説明する態様に従って技法を実装し得るビデオエンコーダの一例を示すブロック図。
【図３Ａ】[0014]本開示で説明する態様に従って技法を実装し得るビデオデコーダの一例を示すブロック図。
【図３Ｂ】[0015]本開示で説明する態様に従って技法を実装し得るビデオデコーダの一例を示すブロック図。
【図４】[0016]本開示の態様による、ビューＩＤビット深度をシグナリングするための方法を示すフローチャート。
【図５】[0017]本開示の態様による、ビューＩＤビット深度を復号するための方法を示すフローチャート。
【図６】[0018]本開示の態様による、ＶＰＳ内でビットレート情報および／またはピクチャレート情報をシグナリングするための方法を示すフローチャート。
【発明を実施するための形態】
【００１１】
[0019]本開示で説明する技法は、概して、スケーラブルビデオコーディング（ＳＨＶＣ、ＳＶＣ）およびマルチビュー／３Ｄビデオコーディング（たとえば、マルチビューコーディングプラス深度、ＭＶＣ＋Ｄ）に関係する。たとえば、本技法は、高効率ビデオコーディング（ＨＥＶＣ）のスケーラブルビデオコーディング（ＳＨＶＣと呼ばれることがある、ＳＶＣ）拡張に関係し、それとともにまたはそれの中で使用され得る。ＳＨＶＣ、ＳＶＣ拡張では、ビデオ情報の複数のレイヤがあり得る。ビデオ情報の最下位レベルのレイヤは、ベースレイヤ（ＢＬ）または参照レイヤ（ＲＬ）の機能を果たすことができ、ビデオ情報の最上部のレイヤ（または、最上位レイヤ）は、エンハンスメントレイヤ（ＥＬ）の機能を果たすことができる。「エンハンストレイヤ」は「エンハンスメントレイヤ」と呼ばれることがあり、これらの用語は互換的に使用され得る。ベースレイヤは「参照レイヤ」と呼ばれることがあり、これらの用語は互換的に使用され得る。ベースレイヤとトップレイヤとの間のすべてのレイヤは、追加のＥＬおよび／または参照レイヤの機能を果たすことができる。たとえば、所与のレイヤは、ベースレイヤまたは任意の介在エンハンスメントレイヤなどの、所与のレイヤの下の（たとえば、先行する）レイヤにとってＥＬであり得る。さらに、所与のレイヤはまた、所与のレイヤの上の（たとえば、それに続く）１つまたは複数のエンハンスメントレイヤにとってＲＬの機能を果たすことができる。ベースレイヤ（たとえば、たとえばレイヤ識別子（ＩＤ）セットを有する、または「１」と等しい、最下位レイヤ）と、トップレイヤ（または、最上位レイヤ）との間の任意のレイヤは、所与のレイヤよりも上位のレイヤによるレイヤ間予測のための参照として使用することができ、また、所与のレイヤよりも下位のレイヤをレイヤ間予測のための参照として使用することができる。たとえば、所与のレイヤは、所与のレイヤよりも下位のレイヤをレイヤ間予測のための参照として使用して決定され得る。
【００１２】
[0020]簡単のために、ＢＬおよびＥＬのただ２つのレイヤに関して例を提示するが、以下で説明するアイデアおよび実施形態が複数のレイヤを用いる場合にも適用可能であることを十分理解されたい。さらに、説明を簡単にするために、「フレーム」または「ブロック」という用語をしばしば使用する。ただし、これらの用語は限定的なものではない。たとえば、以下で説明する技法は、限定はしないが、ピクセル、ブロック（たとえば、ＣＵ、ＰＵ、ＴＵ、マクロブロックなど）、スライス、フレーム、ピクチャなどを含む様々なビデオユニットのいずれかとともに使用され得る。
【００１３】
ビデオコーディング
[0021]ビデオコーディング規格は、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ）拡張と、マルチビュービデオコーディング（ＭＶＣ）拡張と、マルチビューコーディングプラス深度（ＭＶＣ＋Ｄ）と拡張とを含む、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４を含む。以下、ＨＥＶＣ  ＷＤ１０と呼ばれる、最新のＨＥＶＣのドラフト仕様書が、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１３＿Ｉｎｃｈｅｏｎ／ｗｇ１１／ＪＣＴＶＣ−Ｍ０４３２−ｖ３．ｚｉｐから入手可能である。ＨＥＶＣへのマルチビュー拡張、すなわちＭＶ−ＨＥＶＣもまた、ＪＣＴ−３Ｖによって開発されている。以下、ＭＶ−ＨＥＶＣ  ＷＤ４の最新のワーキングドラフト（ＷＤ）が、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／４＿Ｉｎｃｈｅｏｎ／ｗｇ１１／ＪＣＴ３Ｖ−Ｄ１００４−ｖ４．ｚｉｐから入手可能である。ＨＥＶＣへのスケーラブル拡張、すなわちＳＨＶＣもまた、ＪＣＴ−ＶＣによって開発されている。ＳＨＶＣの最近のワーキングドラフト（ＷＤ）であり、以下でワーキングドラフト２と呼ばれるものは、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１３＿Ｉｎｃｈｅｏｎ／ｗｇ１１／ＪＣＴＶＣ−Ｍ１００８−ｖ３．ｚｉｐから入手可能である。一態様によれば、ＪＣＴ３Ｖ−Ｄ０１９６（ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／４＿Ｉｎｃｈｅｏｎ／ｗｇ１１／ＪＣＴ３Ｖ−Ｄ０１９６−ｖ１．ｚｉｐ）は、ビデオパラメータセット（ＶＰＳ）内でビューＩＤをシグナリングするための方法を含む。一態様によれば、ＪＣＴＶＣ−Ｋ０１２５（ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１１＿Ｓｈａｎｇｈａｉ／ｗｇ１１／ＪＣＴＶＣ−Ｋ０１２５−ｖ１．ｚｉｐ）は、ＶＰＳ内でビットレートおよびピクチャレート情報をシグナリングするための方法を含む。
【００１４】
[0022]スケーラブルビデオコーディング（ＳＶＣ）は、（信号対雑音比（ＳＮＲ）とも呼ばれる）品質スケーラビリティ、空間スケーラビリティ、および／または時間スケーラビリティを実現するために使用され得る。たとえば、一実施形態では、参照レイヤ（たとえば、ベースレイヤ）は、第１の品質レベルでビデオを表示するのに十分なビデオ情報を含み、エンハンスメントレイヤは、参照レイヤと比べてさらなるビデオ情報を含み、その結果、参照レイヤおよびエンハンスメントレイヤは一緒に、第１の品質レベルよりも高い第２の品質レベル（たとえば、少ない雑音、大きい解像度、より良いフレームレートなど）でビデオを表示するのに十分なビデオ情報を含む。強調レイヤは、ベースレイヤとは異なる空間解像度を有し得る。たとえば、ＥＬとＢＬとの間の空間アスペクト比は、垂直および水平方向に１．０、１．５、２．０、または他の異なる比率であり得る。言い換えれば、ＥＬの空間アスペクトは、ＢＬの空間アスペクトの１．０倍、１．５倍、または２．０倍に等しい場合がある。いくつかの例では、ＥＬの倍率は、ＢＬの倍率よりも大きい場合がある。たとえば、ＥＬ内のピクチャのサイズは、ＢＬ内のピクチャのサイズよりも大きい場合がある。このようにして、限定ではないが、ＥＬの空間解像度がＢＬの空間解像度よりも大きいことは可能であり得る。
【００１５】
[0023]Ｈ．２６４のＳＶＣ拡張、またはＨ．２６５のＳＨＶＣ拡張を参照するＳＶＣでは（上述のように）、現在のブロックの予測は、ＳＶＣのために提供される異なるレイヤを使用して実行され得る。そのような予測は、レイヤ間予測と呼ばれる場合がある。レイヤ間予測方法は、レイヤ間冗長性を低減するためにＳＶＣにおいて利用され得る。レイヤ間予測のいくつかの例としては、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測があり得る。レイヤ間イントラ予測は、ベースレイヤ中のコロケートブロックの再構成を使用してエンハンスメントレイヤ中の現在ブロックを予測する。レイヤ間動き予測は、エンハンスメントレイヤにおける動きを予測するために、ベースレイヤの動き情報（動きベクトルを含む）を使用する。レイヤ間残差予測は、ベースレイヤの残差を使用してエンハンスメントレイヤの残差を予測する。
【００１６】
概要
[0024]ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョン（たとえば、ワーキングドラフト２）では、レイヤのビューＩＤは、固定された数のビットを使用してシグナリングされていた。たとえば、ＳＨＶＣの初期バージョンは、１つのレイヤについていくつのビューが利用可能であるかに関わらず、ビューＩＤをシグナリングするために１０ビットを使用した。しかしながら、ビューＩＤをシグナリングするために固定されたビット深度（たとえば、固定された数のビット）を使用することは、利用可能なビューの数が、１０ビットを使用してシグナリングされ得るビューの数と比較して少ない（たとえば、１〜４ビュー）場合は特に、非効率性につながる場合がある。１０ビットの固定されたビット深度を使用することにより、１つのレイヤについて最大１０２４（２10）ビューのシグナリングを可能にすることができるが、多くの場合、１つのレイヤについての合計ビューの数は１０２４ビューよりもはるかに少ない。
【００１７】
[0025]さらに、ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョンでは、レイヤセット、および各レイヤセットのサブレイヤごとに、ビットレート情報とピクチャレート情報とがシグナリングされる。レイヤセットごとに、ビットレート情報とピクチャレート情報（たとえば、ｂｉｔ＿ｒａｔｅ＿ｐｉｃ＿ｒａｔｅ（））とを含むシンタックス構造がシグナリングされる。レイヤセットのサブレイヤごとに、ビットレート情報が存在するかどうかを示すフラグがシグナリングされて、ピクチャレート情報が存在するかどうかを示すフラグがシグナリングされる。このプロセスは、たとえ任意のレイヤセットまたはサブレイヤについて、どのようなビットレート情報もピクチャレート情報もない可能性がある場合でも実行される。たとえば、すべてのレイヤセットおよびサブレイヤについてビットレート情報および／またはピクチャレート情報がないことを示すために、レイヤセットごとに、およびサブレイヤごとに、フラグの値として０がシグナリングされる。これは、たとえば、多くのレイヤセットと、レイヤセットの多くのサブレイヤとがあり得るので、非効率性、ならびに不要なシグナリングおよび／または処理につながる場合がある。
【００１８】
[0026]これらおよび他の問題に対処するために、本開示の技法は、ビューＩＤのビット深度をシグナリングして、ビット深度を介してシグナリングされるいくつかのビットを使用してビューＩＤの値をシグナリングすることができる。たとえば、２つのビューだけが使用される場合、ビューＩＤのビット深度は１ビットであり得、ビューＩＤの値は１ビットを使用してシグナリングされ得る。３つのビューが使用される場合、ビューＩＤのビット深度は２ビットでよく、ビューＩＤの値は２ビットを使用してシグナリングされ得る。ビューＩＤをシグナリングするために利用されるビット深度は可変であり得る（たとえば、１と１６ビットとの間）。このように、ビューＩＤは、多くの場合、ビューＩＤの値をシグナリングする際に使用されるビットの数を減少させることによって、より効率的にシグナリングされ得る。シグナリングされるビューの数は、現在の固定された数のビット（たとえば、１０ビット）を使用してシグナリングされ得る最大数未満である可能性が高い。
【００１９】
[0027]本技法は、ＶＰＳ内でビットレート情報および／またはピクチャレート情報をシグナリングすることもできる。たとえば、本技法は、任意のレイヤセットおよび／またはレイヤセットの任意のサブレイヤが、ビットレート情報および／またはピクチャレート情報を有するかどうかを示すことができる。一実施形態では、本技法は、任意のレイヤセットおよび／またはサブレイヤについてのビットレート情報が存在するかどうかを示すグローバルフラグをＶＰＳ内でシグナリングして、任意のレイヤセットおよび／またはサブレイヤについてのピクチャレート情報が存在するかどうかを示すグローバルフラグをＶＰＳ内でシグナリングすることができる。ＶＰＳ内にグローバルフラグを含めることによって、ビットレートピクチャレートシンタックス構造は、グローバルフラグが、少なくとも１つのレイヤセットまたはレイヤセットのサブレイヤについてビットレート情報および／またはピクチャレート情報が存在すると示す時だけ、シグナリングおよび／またはアクセスされ得る。グローバルフラグが、どのレイヤセットについてのビットレート情報および／またはピクチャレート情報も存在しないと示す場合、ビットレートピクチャレートシンタックス構造はシグナリングおよび／またはアクセスされる必要はなく、ビットレートピクチャレートシンタックス構造内の個々のレイヤセットの個々のサブレイヤについてのフラグは送信される（たとえば、シグナリングされる）必要はない。さらに、グローバルフラグは、効率的な方法でビットレート情報とピクチャレート情報との別々の処理を可能にすることができる。ビットレート情報についてのグローバルフラグが、少なくとも１つのレイヤセット内にビットレート情報がないと示す場合、任意のサブレイヤについてのビットレート情報についてのそれぞれのフラグはシグナリングおよび／または処理される必要はない。同様に、ピクチャレート情報についてのグローバルフラグが、少なくとも１つのレイヤセットについてのピクチャレート情報がないと示す場合、任意のサブレイヤについてのピクチャレート情報についてのそれぞれのフラグはシグナリングおよび／または処理される必要はない。以前は、ビットレート情報かピクチャレート情報のうちの１つだけをシグナリングすることも可能であったが、各レイヤセットのサブレイヤごとのビットレート情報についての１つのフラグ、および各レイヤセットのサブレイヤごとのピクチャレート情報についての１つのフラグの、複数の個々のフラグのシグナリングおよび処理が必要であった。
【００２０】
[0028]添付の図面を参照しながら新規のシステム、装置、および方法の様々な態様について以下でより十分に説明する。ただし、本開示は、多くの異なる形態で実施され得、本開示全体にわたって提示する任意の特定の構造または機能に限定されるものと解釈すべきではない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるように与えられる。本明細書の教示に基づいて、本開示の範囲は、本発明の他の態様とは無関係に実装されるにせよ、または本発明の他の態様と組み合わされるにせよ、本明細書で開示する新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者なら諒解されたい。たとえば、本明細書に記載した態様をいくつ使用しても、装置は実装され得、または方法は実施され得る。さらに、本発明の範囲は、本明細書に記載の本発明の様々な態様に加えてまたはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実施されるそのような装置または方法をカバーするものとする。本明細書で開示するどの態様も請求項の１つまたは複数の要素によって実施され得ることを理解されたい。
【００２１】
[0029]本明細書では特定の態様が記載されるが、これらの態様の多くの変形形態および置換は本開示の範囲内に入る。好ましい態様のいくつかの利益および利点が言及されるが、本開示の範囲は、特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であるものとし、それらのいくつかを例として、図および好適な態様についての以下の説明において示す。発明を実施するための形態および図面は、本開示を限定するものではなく説明するものにすぎず、本開示の範囲は添付の特許請求の範囲およびそれの均等物によって定義される。
【００２２】
ビデオコーディングシステム
[0030]図１は、本開示で説明する態様による技法を利用し得る例示的なビデオコーディングシステム１０を示すブロック図である。本明細書で使用し説明する「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化とビデオ復号とを総称的に指すことがある。
【００２３】
[0031]図１に示すように、ビデオコーディングシステム１０は、ソースデバイス１２と宛先デバイス１４とを含む。ソースデバイス１２は符号化ビデオデータを生成する。宛先デバイス１４は、ソースデバイス１２によって生成された符号化ビデオデータを復号し得る。ソースデバイス１２は、コンピュータ可読記憶媒体または他の通信チャネルを含み得る通信チャネル１６を介して宛先デバイス１４にビデオデータを提供することができる。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、車内コンピュータ、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスを含み得る。ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。
【００２４】
[0032]宛先デバイス１４は、通信チャネル１６を介して復号されるべき符号化ビデオデータを受信し得る。通信チャネル１６は、ソースデバイス１２から宛先デバイス１４に符号化されたビデオデータを移動させることができるタイプの媒体またはデバイスを備え得る。たとえば、通信チャネル１６は、ソースデバイス１２が、符号化ビデオデータを宛先デバイス１４にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路など、ワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または他の機器を含み得る。
【００２５】
[0033]いくつかの実施形態では、符号化データは、出力インターフェース２２から記憶デバイスに出力され得る。そのような例では、チャネル１６は、ソースデバイス１２によって生成された符号化されたビデオデータを記憶する記憶デバイスまたはコンピュータ可読記憶媒体に対応し得る。たとえば、宛先デバイス１４は、ディスクアクセスまたはカードアクセスを介してコンピュータ可読記憶媒体にアクセスし得る。同様に、符号化データは、入力インターフェース２８によってコンピュータ可読記憶媒体からアクセスされ得る。コンピュータ可読記憶媒体は、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性もしくは不揮発性メモリ、またはビデオデータを記憶するための他のデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。コンピュータ可読記憶媒体は、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介してコンピュータ可読記憶媒体から、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能なタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。コンピュータ可読記憶媒体からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。
【００２６】
[0034]本開示の技法は、ワイヤレス適用例または設定に加えて適用例または設定を適用することができる。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：dynamic adaptive streaming over HTTP）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例をサポートするビデオコーディングに適用され得る。いくつかの実施形態では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【００２７】
[0035]図１では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。ソースデバイス１２のビデオエンコーダ２０は、複数の規格または規格拡張に準拠するビデオデータを含むビットストリームをコーディングするための技法を適用するように構成され得る。他の実施形態では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなど、外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【００２８】
[0036]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、あらかじめキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。いくつかの実施形態では、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラフォンまたはビデオフォンを形成し得る。キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオ情報は、出力インターフェース２２によって、上記で説明したコンピュータ可読記憶媒体を含み得る通信チャネル１６に出力され得る。
【００２９】
[0037]コンピュータ可読記憶媒体は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（たとえば、非一時的記憶媒体）を含み得る。ネットワークサーバ（図示せず）は、（たとえば、ネットワーク送信を介して）ソースデバイス１２から符号化されたビデオデータを受信し、宛先デバイス１４に符号化されたビデオデータを与え得る。ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、通信チャネル１６は、様々な形態の１つまたは複数のコンピュータ可読記憶媒体を含むと理解され得る。
【００３０】
[0038]宛先デバイス１４の入力インターフェース２８は、通信チャネル１６から情報を受信し得る。通信チャネル１６の情報は、ビデオエンコーダ２０によって定義され、ビデオデコーダ３０によって使用され得る、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを含み得る。
【００３１】
[0039]ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ  １０，Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格など、他のプロプライエタリ規格もしくは業界規格、またはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例としては、ＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。
【００３２】
[0040]図１は例にすぎず、本開示の技法は、符号化デバイスと復号デバイスとの間の任意のデータ通信を必ずしも含むとは限らないビデオコーディング設定（たとえば、ビデオ符号化、またはビデオ復号）に適用することができる。他の例では、データは、ローカルメモリから取り出されてもよく、ネットワークを介してストリーミングされてもよく、または同様の方法で取得されてもよい。符号化デバイスがデータを符号化してメモリに記憶してもよく、および／または復号デバイスがメモリからデータを取り出して復号してもよい。多くの例では、符号化および復号は、相互に通信しないデバイスによって実行されるが、単にデータをメモリに符号化して、および／またはメモリからデータを取り出して復号する。
【００３３】
[0041]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組合せなど、様々な好適なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
【００３４】
[0042]ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。
【００３５】
[0043]概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding unit）に分割され得ることを記載している。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
【００３６】
[0044]４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵをリーフＣＵとも呼ぶ。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵをリーフＣＵとも呼ぶ。
【００３７】
[0045]ＣＵは、ＣＵがサイズの差異を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、４つの子ノード（サブＣＵとも呼ばれる）に分割され得、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ：smallest coding unit）をも定義し得る。本開示では、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、もしくはＴＵ、または他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。
【００３８】
[0046]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ：prediction unit）および変換ユニット（ＴＵ：transform unit）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、ならびに形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルを有するツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化もしくはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が方形または非方形（たとえば、矩形）であり得る。
【００３９】
[0047]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従う変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差クワッドツリー」（ＲＱＴ：residual quad tree）として知られるクワッドツリー構造を使用して、より小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、量子化され得る変換係数を生成するために変換され得る。
【００４０】
[0048]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間的エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵについてのデータは、ＰＵに対応するＴＵについてのイントラ予測モードを記述するデータを含み得る残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、またはリストＣ）を記述し得る。
【００４１】
[0049]１つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上記で説明したように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらに、さらなるサブＴＵに分割され得る。ＴＵがさらに分割されないとき、そのＴＵはリーフＴＵと呼ばれることがある。概して、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、概して、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダ２０は、イントラ予測モードを使用して各リーフＴＵの残差値をＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵはＰＵよりも大きくまたは小さくなり得る。イントラコーディングの場合、ＰＵは、同じＣＵの対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。
【００４２】
[0050]さらに、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。概して、本開示では、特に明記しない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
【００４３】
[0051]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、概して、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に応じてサイズが異なり得る。
【００４４】
[0052]一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ  ＰＵと下部の２Ｎ×１．５Ｎ  ＰＵとで水平方向に区分された２Ｎ×２Ｎ  ＣＵを指す。
【００４５】
[0053]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ただし、Ｎは非負整数値を表す。ブロック中のピクセルは行と列で構成され得る。さらに、ブロックは、必ずしも、水平方向に垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ただし、Ｍは必ずしもＮに等しいとは限らない。
【００４６】
[0054]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、ＴＵは、変換、たとえば、残差ビデオデータへの離散サイン変換（ＤＳＴ）、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。
【００４７】
[0055]変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、その最も広い通常の意味を有することが意図された広義の用語である。一実施形態では、量子化は、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、ただし、ｎはｍよりも大きい。
【００４８】
[0056]量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応型走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【００４９】
[0057]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルのための可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
【００５０】
[0058]ビデオエンコーダ２０は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびＧＯＰベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送り得る。ＧＯＰシンタックスデータは、それぞれのＧＯＰ中のいくつかのフレームを記述し得、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化／予測モードを示し得る。
【００５１】
ビデオエンコーダ
[0059]図２Ａは、本開示で説明する態様による技法を実装し得るビデオエンコーダの例を示すブロック図である。ビデオエンコーダ２０は、ＨＥＶＣのような、ビデオビットストリームの単一のレイヤを処理するように構成され得る。さらに、ビデオエンコーダ２０は、これに限定されないが、ＶＰＳ内のビューＩＤビット深度のシグナリング、ビットレート情報および／またはピクチャレート情報のシグナリングの方法、ならびに上記および以下で図４〜図６に関してより詳細に説明する関連プロセスを含む、本開示の技法のいずれかまたはすべてを実行するように構成され得る。一例として、レイヤ間予測ユニット６６（与えられる場合）は、本開示で説明する技法のいずれかまたはすべてを実行するように構成され得る。ただし、本開示の態様はそのように限定されない。いくつかの例では、本開示で説明する技法は、ビデオエンコーダ２０の様々な構成要素間で共有され得る。いくつかの例では、さらに、または代替で、プロセッサ（図示せず）は、本開示において説明する技法のいずれかまたはすべてを実行するように構成され得る。
【００５２】
[0060]説明のために、本開示は、ＨＥＶＣコーディングの文脈でビデオエンコーダ２０を説明する。しかしながら、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。図２Ａのエンコーダ２０は、コーデックの単一のレイヤを示している。しかしながら、図２Ｂを参照してさらに説明するように、ビデオエンコーダ２０のうちのいくつかまたはすべては、マルチレイヤコーデックによる処理のために複製され得る。
【００５３】
[0061]ビデオエンコーダ２０は、ビデオスライス内のビデオブロックの（イントラコーディング、レイヤコーディング、またはレイヤ間コーディングといつか呼ばれる）イントラ予測、インター予測、およびレイヤ間予測を実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。レイヤ間コーディングは、同じビデオコーディングシーケンス内の異なるレイヤ内のビデオに基づく予測に依拠する。イントラモード（Ｉモード（登録商標））は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
【００５４】
[0062]図２Ａに示すように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図２Ａの例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照フレームメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、今度は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、レイヤ間予測ユニット６６と、パーティションユニット４８とを含む。参照フレームメモリ６４は、復号されたピクチャバッファを含み得る。復号されたピクチャバッファは、その通常の意味を有する、およびいくつかの実施形態では、参照フレームのビデオコーデックが管理するデータ構造を指す、広義の用語である。
【００５５】
[0063]ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ（図２Ａに図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタ処理することになる。また、デブロッキングフィルタに加えて追加のフィルタ（ループ内またはループ後）が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、（ループ内フィルタとして）加算器５０の出力をフィルタ処理し得る。
【００５６】
[0064]符号化プロセス中に、ビデオエンコーダ２０は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対して、受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は、代替的に、空間的予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
【００５７】
[0065]その上、パーティションユニット４８は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、パーティションユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化など）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、ＬＣＵをサブＣＵに区分することを示す４分木データ構造をさらに生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵおよび１つまたは複数のＴＵを含み得る。
【００５８】
[0066]モード選択ユニット４０は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラ予測モード、インター予測モード、またはレイヤ間予測モードのうちの１つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロック、インターコード化ブロック、またはレイヤ間コード化ブロックを加算器５０に与え、参照フレームとして使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロック、インターコード化ブロック、またはレイヤ間コード化ブロックを加算器６２に与え得る。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット５６に与える。
【００５９】
[0067]動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または他のコード化ユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照フレームメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
【００６０】
[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]逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット７０によって復号された量子化変換係数を逆量子化（inverse quantize）、たとえば、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオデコーダ３０によって計算される量子化パラメータＱＰＹの使用を含み得る。
【００８６】
[0094]逆変換ユニット７８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば逆ＤＣＴ、逆ＤＳＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
【００８７】
[0095]動き補償ユニット７２が、動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックのための予測ブロックを生成した後に、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックに加算することによって、復号されたビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、他のループフィルタも（コーディングループ中またはコーディングループ後のいずれかで）使用され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照フレームメモリ８２に記憶される。参照フレームメモリ８２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上での後の表示のための、復号されたビデオを記憶する。
【００８８】
マルチレイヤデコーダ
[0096]図３Ｂは、本開示で説明する態様に従って技法を実装し得るマルチレイヤビデオデコーダ３１の例を示すブロック図である。ビデオデコーダ３１は、ＳＨＶＣおよびマルチビューコーディングのような、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオデコーダ３１は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。
【００８９】
[0097]ビデオデコーダ３１は、ビデオデコーダ３０Ａとビデオデコーダ３０Ｂとを含み、それらの各々は、図３Ａのビデオデコーダ３０として構成され得、ビデオデコーダ３０に関して上記で説明した機能を実行し得る。さらに、参照番号の再利用によって示されるように、ビデオデコーダ３０Ａと３０Ｂとは、ビデオデコーダ３０としてシステムとサブシステムとのうちの少なくともいくつかを含み得る。ビデオデコーダ３１は、２つのビデオデコーダ３０Ａと３０Ｂとを含むものとして示されているが、ビデオデコーダ３１はそのように限定されず、任意の数のビデオデコーダ３０レイヤを含み得る。いくつかの実施形態では、ビデオデコーダ３１は、アクセスユニット内のピクチャまたはフレームごとにビデオデコーダ３０を含み得る。たとえば、５個のピクチャを含むアクセスユニットは、５個のデコーダレイヤを含むビデオデコーダによって処理されてもよく、復号されてもよい。いくつかの実施形態では、ビデオデコーダ３１は、アクセスユニット内のフレームよりも多くのデコーダレイヤを含み得る。いくつかのそのようなケースでは、ビデオデコーダレイヤのうちのいくつかは、いくつかのアクセスユニットを処理する際に非アクティブであり得る。
【００９０】
[0098]ビデオデコーダ３０Ａと３０Ｂとに加えて、ビデオデコーダ３１はアップサンプリングユニット９２を含み得る。いくつかの実施形態では、アップサンプリングユニット９２は、フレームまたはアクセスユニットのための参照ピクチャリストに追加されるべきエンハンストレイヤを作成するために、受信されたビデオフレームのベースレイヤをアップサンプリングし得る。このエンハンストレイヤは、参照フレームメモリ８２（たとえば、その復号されたピクチャバッファなど）に記憶され得る。いくつかの実施形態では、アップサンプリングユニット９２は、図２Ｂのリサンプリングユニット９０に関して説明する実施形態のうちのいくつかまたはすべてを含み得る。いくつかの実施形態では、アップサンプリングユニット９２は、スライス境界ルールのセットおよび／またはラスタ走査ルールを順守するために、レイヤをアップサンプリングして、１つまたは複数のスライスを再編成、再定義、修正、または調整するように構成される。場合によっては、アップサンプリングユニット９２は、受信されたビデオフレームのレイヤをアップサンプリングおよび／またはダウンサンプリングするように構成されたリサンプリングユニットであり得る。
【００９１】
[0099]アップサンプリングユニット９２は、下位層デコーダ（たとえば、ビデオデコーダ３０Ａ）の復号されたピクチャバッファ８２からピクチャまたはフレーム（あるいは、ピクチャに関連付けられるピクチャ情報）を受信して、ピクチャ（または、受信されたピクチャ情報）をアップサンプリングするように構成され得る。次いで、アップサンプリングされたピクチャは、下位層デコーダと同じアクセスユニット内のピクチャを復号するように構成された上位層デコーダ（たとえば、ビデオデコーダ３０Ｂ）のレイヤ間予測ユニット７５に提供され得る。場合によっては、上位層デコーダは、下位層デコーダから除去された１つのレイヤである。他の場合では、図３Ｂのレイヤ０デコーダとレイヤ１デコーダとの間に、１つまたは複数の上位層デコーダがあり得る。
【００９２】
[0100]場合によっては、アップサンプリングユニット９２は、省略または迂回され得る。そのような場合、ビデオデコーダ３０Ａの復号されたピクチャバッファ８２からのピクチャは、直接、または少なくともアップサンプリングユニット９２、ビデオデコーダ３０Ｂのレイヤ間予測ユニット７５に提供されることなしに提供され得る。たとえば、ビデオデコーダ３０Ｂに提供されたビデオデータ、およびビデオデコーダ３０Ａの復号されたピクチャバッファ８２からの参照ピクチャが、同じサイズまたは解像度である場合、参照ピクチャは、アップサンプリングなしにビデオデコーダ３０Ｂに提供され得る。さらに、いくつかの実施形態では、アップサンプリングユニット９２は、ビデオデコーダ３０Ａの復号されたピクチャバッファ８２から受信された参照ピクチャをアップサンプリングまたはダウンサンプリングするように構成されたリサンプリングユニット９０であり得る。
【００９３】
[00101]図３Ｂに示されるように、ビデオデコーダ３１は、デマルチプレクサ９９、すなわちｄｅｍｕｘをさらに含み得る。ｄｅｍｕｘ９９は、符号化されたビデオビットストリームを複数のビットストリームに分割することができ、ｄｅｍｕｘ９９によって出力された各ビットストリームが、異なるビデオデコーダ３０Ａと３０Ｂとに提供されている。複数のビットストリームは、ビットストリームを受信することによって作成され得、ビデオデコーダ３０Ａと３０Ｂとの各々は、所与の時間にビットストリームの一部分を受信する。場合によっては、ｄｅｍｕｘ９９で受信されたビットストリームからのビットは、ビデオデコーダの各々（たとえば、図３Ｂの例におけるビデオデコーダ３０Ａと３０Ｂ）の間で一度に１ビットがオルタネートされ得るが、多くの場合、ビットストリームは異なるように分割される。たとえば、ビットストリームは、どのビデオデコーダがビットストリームを一度に１ブロック受信するかをオルタネートすることによって分割され得る。別の例では、ビットストリームは、ビデオデコーダ３０Ａと３０Ｂとの各々へのブロックの非１：１比によって分割され得る。たとえば、２つのブロックは、ビデオデコーダ３０Ａに提供されたブロックごとにビデオデコーダ３０Ｂに提供され得る。いくつかの実施形態では、ｄｅｍｕｘ９９によるビットストリームの分割は事前にプログラムされ得る。他の実施形態では、ｄｅｍｕｘ９９は、宛先デバイス１４上のプロセッサからなどの、ビデオデコーダ３１の外部のシステムから受信された制御信号に基づいて、ビットストリームを分割することができる。制御信号は、入力インターフェース２８からのビデオの解像度またはビットレートに基づいて、チャネル１６の帯域幅に基づいて、ユーザに関連付けられるサブスクリプション（たとえば、有料購読対、無料購読）に基づいて、あるいは、ビデオデコーダ３１によって取得可能な解像度を決定するための他の任意の要因に基づいて生成され得る。
【００９４】
ＶＰＳ内のビューＩＤビット深度のシグナリング、ならびにビットレート情報および／またはピクチャレート情報のシグナリング
[00102]ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョン（たとえば、ワーキングドラフト２）では、レイヤのビューＩＤは、固定された数のビットを使用してシグナリングされていた。たとえば、ＳＨＶＣの初期バージョンは、１つのレイヤについていくつのビューが利用可能であるかに関わらず、ビューＩＤをシグナリングするために１０ビットを使用した。しかしながら、ビューＩＤをシグナリングするために固定されたビット深度を使用することは、利用可能なビューの数が少ない（たとえば、１〜４ビュー）場合は特に、非効率性につながる場合がある。１０ビットの固定されたビット深度を使用することにより、１つのレイヤについて最大１０２４（２10）ビューのシグナリングを可能にすることができるが、多くの場合、１つのレイヤについての合計ビューの数はそれよりもはるかに少ない。
【００９５】
[00103]さらに、ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョンでは、レイヤごとに、および各レイヤセットのサブレイヤごとに、ビットレートおよびピクチャレート情報がシグナリングおよび／または処理される。レイヤセットごとに、ビットレートおよびピクチャレート情報（たとえば、ｂｉｔ＿ｒａｔｅ＿ｐｉｃ＿ｒａｔｅ（））を含むシンタックス構造がシグナリングされる。各レイヤセットのサブレイヤごとに、ビットレート情報が存在するかどうかを示すそれぞれのフラグがシグナリングされて、ピクチャレート情報が存在するかどうかを示すそれぞれのフラグがシグナリングされる。このプロセスは、たとえ任意のレイヤセットまたはサブレイヤについての任意のビットレート情報および／またはピクチャレート情報が存在するか否かに関わらず実行される。たとえば、すべてのレイヤセットおよびサブレイヤについてビットレート情報および／またはピクチャレート情報がないことを示すために、レイヤセットごとに、およびそれぞれのサブレイヤごとに、フラグの値として０がシグナリングされる。これは、たとえば、多くのレイヤセットと、レイヤセットの多くのサブレイヤとがあり得るので、非効率性、ならびに不要なシグナリングおよび／または処理につながる場合がある。
【００９６】
[00104]これらおよび他の問題に対処するために、本開示の技法は、ビューＩＤのビット深度をシグナリングすることと、シグナリングされたビット深度を使用してビューＩＤの値をシグナリングすることとを可能にすることができる。たとえば、２つのビューだけが使用される場合、ビューＩＤのビット深度は１ビットであり得、ビューＩＤの値は１ビットを使用してシグナリングされ得る。３つのビューが使用される場合、ビューＩＤのビット深度は２ビットでよく、ビューＩＤの値は２ビットを使用してシグナリングされ得る。ビューＩＤのビット深度は可変であり得る（たとえば、１と１６ビットとの間）。このように、ビューＩＤは、ビューＩＤの値をシグナリングする際に使用されるビットの数を減少させることによって、より効率的にシグナリングされ得る。
【００９７】
[00105]本開示の技法は、ＶＰＳ内でビットレート情報および／またはピクチャレート情報をシグナリングすることを可能にすることができる。たとえば、本技法は、任意のレイヤセットおよび／またはレイヤセットの任意のサブレイヤが、ビットレート情報および／またはピクチャレート情報を有するかどうかを示すことができる。一実施形態では、本技法は、任意のレイヤセットおよび／またはサブレイヤについてのビットレート情報が存在するかどうかを示すグローバルフラグをＶＰＳ内でシグナリングして、任意のレイヤセットおよび／またはサブレイヤについてのピクチャレート情報が存在するかどうかを示すグローバルフラグをＶＰＳ内でシグナリングすることができる。ＶＰＳ内にグローバルフラグを含めることによって、ビットレートピクチャレートシンタックス構造は、グローバルフラグが、少なくとも１つのレイヤセットまたは少なくとも１つのサブレイヤについてビットレート情報および／またはピクチャレート情報が存在すると示す時だけ、シグナリングおよび／またはアクセスされ得る。グローバルフラグが、どのレイヤについてのビットレート情報および／またはピクチャレート情報も存在しないと示す場合、ビットレートピクチャレートシンタックス構造はシグナリングおよび／またはアクセスされる必要はない。さらに、グローバルフラグは、効率的な方法でビットレート情報とピクチャレート情報との別々の処理を可能にすることができる。ビットレート情報についてのグローバルフラグが、ビットレート情報がないと示す場合、サブレイヤについてのビットレート情報についてのフラグはシグナリングおよび／または処理される必要はない。同様に、ピクチャレート情報についてのグローバルフラグが、サブレイヤについてのピクチャレート情報がないと示す場合、サブレイヤについてのピクチャレート情報についてのフラグはシグナリングおよび／または処理される必要はない。以前は、ビットレート情報かピクチャレート情報のうちの１つだけをシグナリングすることが可能であったが、各レイヤセットのサブレイヤごとのビットレート情報についての１つのフラグ、および各レイヤセットのサブレイヤごとのピクチャレート情報についての１つのフラグの、複数の個々のフラグのシグナリングおよび処理が必要であった。
【００９８】
[00106]本開示を通じて使用される様々な用語は、それらの通常の意味を有する広義の用語である。さらに、いくつかの実施形態では、特定の用語は以下のビデオ概念に関連する。ピクチャは、その用語が現在の規格（たとえば、ＨＥＶＣ、ＳＨＶＣ、ＭＶ−ＨＥＶＣ等）で使用されるので、ビデオピクチャを指すことができる。ビデオパラメータセット（ＶＰＳ）は、複数のレイヤに、およびアクセスユニットのシーケンスにわたってグローバルに適用されるパラメータの任意のセットを指すことができる。補助強化情報（ＳＥＩ）は、適合する（ｃｏｎｆｏｒｍｉｎｇ）ビットストリーム内のピクチャの正確な復号のために必ずしも必要ではないが、改善されたユーザ経験のために（たとえば、送信エラーがあるビデオ品質の向上を助けるために、等）有用である、任意の情報を指すことができる。ビュー識別子（ＩＤ）は、ビューの識別子（カメラの表現）、または触覚信号（たとえば、触覚センサの表現）を指すことができる。セッションネゴシエーションは、能力交換、オファーアンサー等を指すことができる。本開示の技法はまた、ランダムアクセス期間、各タイプのコーディングされたピクチャ（イントラコーディングされた、片方向予測されたピクチャ、双方向予測された、等）の数などの、ビットレートおよびピクチャレート以外のビットストリーム特性のシグナリングに適用することができる。いくつかの実施形態では、コンピューティングハードウェアは、コンピュータハードウェアを備える１つまたは複数のコンピューティングデバイスを含み得る。
【００９９】
ビューＩＤビット深度のシグナリング
[00107]上記で説明したように、レイヤのビューＩＤは、可変ビット深度を使用してシグナリングされ得る。一実施形態では、ビット深度は、ビット深度が適切に、たとえば、シグナリングされるビューの数に基づいて選択され得るという点で可変であり得る。特定の実施形態では、ビット深度はＶＰＳ内でシグナリングされる。一実施形態では、ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョンのｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックスおよびセマンティクスは、イタリック体で示されるように変更され得る。そのような変更は、ＪＣＴ３Ｖ−Ｄ０１９６における方法からの変更であり得る。ビューＩＤをシグナリングするために使用されるビットの数は、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１のビュー内のビューＩＤ値ｖｉｅｗ＿ｉｄ＿ｖａｌの長さをシグナリングすることによって適切に調節され得る。
【表１】
0006495268.tif 000002
【０１００】
上記の様々なシンタックス要素または変数は、以下のように定義され得る。
【０１０１】
・１と等しいｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ＿ｆｌａｇ［ｉ］は、表Ｆ−１内のｉ番目のスケーラビリティ次元に対応するｄｉｍｅｎｓｉｏｎ＿ｉｄシンタックス要素が存在することを示している。０と等しいｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ＿ｆｌａｇ［ｉ］は、ｉ番目のスケーラビリティ次元に対応するｄｉｍｅｎｓｉｏｎ＿ｉｄシンタックス要素が存在しないことを示している。
【表２】
0006495268.tif 000003
【０１０２】
・ｄｉｍｅｎｓｉｏｎ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１［ｊ］プラス１は、ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］シンタックス要素の長さをビット単位で指定する。
【０１０３】
・ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが１と等しい場合、以下が適用される：
−変数ｄｉｍＢｉｔＯｆｆｓｅｔ［０］が０と等しく設定され、１からＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１まで（両方を含めて）の範囲内のｊについて、ｄｉｍＢｉｔＯｆｆｓｅｔ［ｊ］が以下のように導出される。
【数１】
0006495268.tif 000004
【０１０４】
−ｄｉｍｅｎｓｉｏｎ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１［ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１］の値は、５？ｄｉｍＢｉｔＯｆｆｓｅｔ［ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１］と等しいと推測される。
【０１０５】
−ｄｉｍＢｉｔＯｆｆｓｅｔ［ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ］の値が６と等しく設定される。
【０１０６】
−ｄｉｍＢｉｔＯｆｆｓｅｔ［ＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１］が６未満であることは、ビットストリームの適合性の要件である。
【０１０７】
・１と等しいｖｐｓ＿ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、１からｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１まで（両方を含めて）のｉについて、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］が存在することを指定する。０と等しいｖｐｓ＿ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、１からｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１まで（両方を含めて）のｉについて、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］が存在しないことを指定する。
【０１０８】
・ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］は、ｉ番目のレイヤのＶＣＬ  ＮＡＬユニット内のｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素の値を指定する。０からｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１まで（両方を含めて）の範囲内のｉについて、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］が存在しない場合、値はｉと等しいと推測される。
【０１０９】
−ｉが０を上回る場合、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］はｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ−１］を上回ることになる。
【０１１０】
−０からｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１まで（両方を含めて）のｉについて、変数ＬａｙｅｒＩｄｘＩｎＶｐｓ［ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］］がｉと等しく設定される。
【０１１１】
・ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］は、ｉ番目のレイヤのｊ番目に存在するスケーラビリティ次元タイプの識別子を指定する。ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］の表現のために使用されるビットの数は、ｄｉｍｅｎｓｉｏｎ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１［ｊ］＋１ビットである。
【０１１２】
−ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが１と等しい場合、０からｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１まで（両方を含めて）のｉ、および０からＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１まで（両方を含めて）のｊについて、ｄｉｍｅｎｓｉｏｎ＿ｉｄ［ｉ］［ｊ］は（（ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］＆（（１＜＜ｄｉｍＢｉｔＯｆｆｓｅｔ［ｊ＋１］）−１））＞＞ｄｉｍＢｉｔＯｆｆｓｅｔ［ｊ］）と等しいと推測される。
【０１１３】
−ｓｐｌｉｔｔｉｎｇ＿ｆｌａｇが１と等しくない場合、０からＮｕｍＳｃａｌａｂｉｌｉｔｙＴｙｐｅｓ−１まで（両方を含めて）のｊについて、ｄｉｍｅｎｓｉｏｎ＿ｉｄ［０］［ｊ］は０と等しいと推測される。
【０１１４】
−ｉ番目のレイヤのｓｍＩｄｘ−ｔｈスケーラビリティ次元タイプの識別子を指定している変数ＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［ｓｍＩｄｘ］、およびｉ番目のレイヤがビュースケーラビリティ拡張レイヤかどうかを指定している変数ＶｉｅｗＳｃａｌＥｘｔＬａｙｅｒＦｌａｇが、以下のように導出される。
【数２】
0006495268.tif 000005
【０１１５】
・１と等しいｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇは、ビュー識別子が、ＶＰＳによって指定されたいくつかまたはすべてのレイヤに明示的に割り当てられていることを指定する。０と等しいｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇは、ビュー識別子が、ＶＰＳによって指定されたレイヤに明示的に割り当てられていないことを指定する。
【０１１６】
・ｖｕｌｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１プラス１は、ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］シンタックス要素の長さをビット単位で指定する。
【０１１７】
・１と等しいｖｉｅｗ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｏｒ＿ａｌｌ＿ｌａｙｅｒｓ＿ｆｌａｇは、ＶＰＳによって指定されたレイヤごとのビュー識別子が明示的にシグナリングされていることを指定する。０と等しいｖｉｅｗ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｏｒ＿ａｌｌ＿ｌａｙｅｒｓ＿ｆｌａｇは、ビュー識別子が、ＶＰＳによって指定されたいくつかのレイヤに明示的にシグナリングされて、ＶＰＳによって指定された他のレイヤのために導出されることを指定する。
【０１１８】
・ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］は、ＶＰＳによって指定されたｉ番目のレイヤのビュー識別子を指定する。ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］シンタックス要素は、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１ビットによって表される。
【０１１９】
−ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇが１と等しい場合、ｖｉｅｗ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｏｒ＿ａｌｌ＿ｌａｙｅｒｓ＿ｆｌａｇは０と等しく、ｉ％２は１と等しく、ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］の値はｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ−１］と等しいと推測される。
【０１２０】
−ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇが０と等しい場合、ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］の値はＳｃａｌａｂｉｌｉｔｙＩｄ［ｉ］［０］と等しいと推測される。
【０１２１】
−ｎｕｈＬａｙｅｒＩｄと等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤごとに、変数ＶｉｅｗＩｄがｖｉｅｗ＿ｉｄ＿ｖａｌ［ＬａｙｅｒＩｄｘＩｎＶｐｓ［ｎｕｈＬａｙｅｒＩｄ］］と等しく設定される。レイヤ内の各ピクチャは、レイヤのＶｉｅｗＩｄに関連付けられると考えられる。
【０１２２】
・ＳＨＶＣにとって、ｖｉｅｗ＿ｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は０と等しいことが必要とされる場合がある。深度を含むＭＶ−ＨＥＶＣの潜在的な拡張では、１つのビューの、テクスチャおよび深度構成要素は、２つの隣接するレイヤであり、同じｖｉｅｗ＿ｉｄを有する。テクスチャおよび深度が常に対になっている場合、ｖｉｅｗ＿ｉｄ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを１に等しく、およびｖｉｅｗ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｏｒ＿ａｌｌ＿ｌａｙｅｒｓ＿ｆｌａｇを０に等しく設定することが望ましい。
【０１２３】
[00108]上記の実施形態では、ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇは、ビュー識別子が明示的にシグナリングされることを示すためにシグナリングされる。ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇは、ＶＰＳ内でシグナリングされ得る。ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇが１と等しい場合、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１がシグナリングされる。ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１は、１つまたは複数のビュー識別子マイナス１をシグナリングする際に使用されるべきビット深度を示すことができる。一例では、ビット深度は１と１６との間であり得る。ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］は、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１によって示されるビット深度を使用してシグナリングされる。ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］の長さは、シグナリングされる必要があるビューの数に応じて可変であり得る。
【０１２４】
[00109]同様に、デコーダ側で、たとえばＶＰＳ内でｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇが受信される。ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇは、ビュー識別子が明示的にシグナリングされていることを示すことができる。ｖｉｅｗ＿ｉｄ＿ｅｘｐｌｉｃｉｔｌｙ＿ｓｉｇｎａｌｌｅｄ＿ｆｌａｇが１と等しい場合、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１が処理される。ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１は、１つまたは複数のビュー識別子マイナス１をシグナリングする際に使用されるビット深度を示すことができる。ｖｉｅｗ＿ｉｄ＿ｖａｌ［ｉ］は、ｖｉｅｗ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１の長さを有する値として受信され得る。
【０１２５】
[00110]このように、可変ビット深度は、ビューＩＤのビット深度をシグナリングすることによって、レイヤのビューＩＤをシグナリングするために使用され得る。次いで、ビューＩＤは、ビット深度によって示されるビットの数を使用して復号され得る。いくつかの実施形態では、ビット深度は、ビューＩＤの長さとも呼ばれ得る。
【０１２６】
ＶＰＳ内のビットレート情報および／またはピクチャレート情報のシグナリング
[00111]ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョンでは、セッションネゴシエーションおよびコンテンツ選択のために有用である、プロファイル、層、およびレベルに関する情報が、ＶＰＳ内でシグナリングされる。しかしながら、ビットレートおよびピクチャレートなどの、同じ目的のためにやはり重要である他の情報は、ＶＰＳ内でシグナリングされない。ビットレートおよびピクチャレート情報のシグナリングは、それぞれスケーラビリティ情報補助強化情報（ＳＥＩ）メッセージ、およびビュースケーラビリティ情報ＳＥＩメッセージ内のＳＶＣおよびＭＶＣ内でサポートされる。ＨＥＶＣマルチレイヤ拡張では、スケーラビリティ情報ＳＥＩメッセージおよびビュースケーラビリティ情報ＳＥＩメッセージ（ＡＶＣ拡張の）内で搬送されるセッションネゴシエーションにとって重要な情報のうちのいくつかまたはすべてが今はＶＰＳ内に含まれ得る。
【０１２７】
[00112]したがって、本開示の一態様では、ビットレート情報および／またはピクチャレート情報がＶＰＳ内でシグナリングされる。そのような情報のセマンティクスは、国際標準化機構（ＩＳＯ）ベースのメディアファイル形式およびその拡張ファイル形式などのシステム仕様におけるそれらの対応と整列される。
【０１２８】
[00113]ＪＣＴＶＣ−Ｋ０１２５における方法と比較して、本開示の技法は、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとのフラグを含めることと、シンタックス構造およびシンタックス要素を調整する際にそれらを使用することを通じて、ビットレート情報とピクチャレート情報とのうちの１つだけのより効率的なシグナリングを可能にすることができる。
【０１２９】
[00114]一実施形態では、ＭＶ−ＨＥＶＣおよびＳＨＶＣの初期バージョンのｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックスおよびセマンティクスは、イタリック体で示されるように変更され得る。
【表３】
0006495268.tif 000006
【０１３０】
・１と等しいｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇ、または１と等しいｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇは、レイヤセットごとにＶＰＳ内にｂｉｔ＿ｒａｔｅ＿ｐｉｃ＿ｒａｔｅ（）シンタックス構造が存在することを指定する。０と等しいｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇ、および０と等しいｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇは、ｂｉｔ＿ｒａｔｅ＿ｐｉｃ＿ｒａｔｅ（）シンタックス構造がＶＰＳ内にまったく存在しないことを指定する。
【表４】
0006495268.tif 000007
【０１３１】
・１と等しいｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］は、レイヤセットのｉ番目のサブセットについてのビットレート情報が存在することを指定する。０と等しいｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］は、レイヤセットのｉ番目のサブセットについてのビットレート情報が存在しないことを指定する。レイヤセットのｉ番目のサブセットは、それがレイヤセットｉで呼び出される場合、サブ−ビットストリーム抽出プロセスの出力であり、入力としてレイヤセットに関連付けられるレイヤ識別子リストである。存在しない場合、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］の値は０と等しいと推測される。
【０１３２】
・１と等しいｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］は、レイヤセットのｉ番目のサブセットについてのピクチャレート情報が存在することを指定する。０と等しいｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］は、レイヤセットのｉ番目のサブセットについてのピクチャレート情報が存在しないことを指定する。存在しない場合、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］の値は０と等しいと推測される。
【０１３３】
・ａｖｇ＿ｂｉｔ＿ｒａｔｅ［ｉ］は、レイヤセットのｉ番目のサブセットの平均ビットレートをビット／秒で示している。値は、
【数３】
0006495268.tif 000008
【０１３４】
によって指定される関数ＢｉｔＲａｔｅＢＰＳ（）を有するＢｉｔＲａｔｅＢＰＳ（ａｖｇ＿ｂｉｔ＿ｒａｔｅ［ｉ］）によって与えられる。
【０１３５】
−平均ビットレートは、ＳＨＶＣ  ＷＤ２およびＭＶ−ＨＥＶＣ  ＷＤ４のＡｎｎｅｘ  Ｆ．１３において指定されるアクセスユニット除去時間に応じて導出される。以下では、ｂＴｏｔａｌは、レイヤセットのｉ番目のセットのすべてのＮＡＬユニットにおけるビットの数であり、ｔ1はＶＰＳが適用される第１のアクセスユニットの除去時間（秒単位）であり、ｔ2はＶＰＳが適用される最後のアクセスユニット（復号順）の除去時間（秒単位）である。
【０１３６】
−ｘがａｖｇ＿ｂｉｔ＿ｒａｔｅ［ｉ］の値を指定する場合、以下が適用される。
【０１３７】
○ｔ1がｔ2と等しくない場合、以下の条件は真であるものとする。
【数４】
0006495268.tif 000009
【０１３８】
そうではない（ｔ1がｔ2と等しい）場合、以下の条件は真であるものとする。
【数５】
0006495268.tif 000010
【０１３９】
・ｍａｘ＿ｂｉｔ＿ｒａｔｅ＿ｌａｙｅｒ［ｉ］は、Ａｎｎｅｘ  Ｆ．１３で指定されたアクセスユニット除去時間の任意の１秒の時間窓（ｏｎｅ−ｓｅｃｏｎｄ  ｔｉｍｅ  ｗｉｎｄｏｗ）における、レイヤセットのｉ番目のサブセットのビットレートについての上界を示している。ビット／秒でのビットレートについての上界は、ＢｉｔＲａｔｅＢＰＳ（ｍａｘ＿ｂｉｔ＿ｒａｔｅ＿ｌａｙｅｒ［ｉ］）によって与えられる。ビットレート値は、Ａｎｎｅｘ  Ｆ．１３で指定されたアクセスユニット除去時間に応じて導出される。以下では、ｔ1は時間内の任意の点（秒単位）であり、ｔ2はｔ1＋１÷１００と等しく設定され、ｂＴｏｔａｌは、ｔ1以上でありｔ2未満である除去時間を有するアクセスユニットのすべてのＮＡＬユニットにおけるビットの数である。ｘがｍａｘ＿ｂｉｔ＿ｒａｔｅ＿ｌａｙｅｒ［ｉ］の値を指定する場合、ｔ1のすべての値について以下の条件が守られるものとする。
【数６】
0006495268.tif 000011
【０１４０】
・ｃｏｎｓｔａｎｔ＿ｐｉｃ＿ｒａｔｅ＿ｉｄｃ［ｉ］は、レイヤセットのｉ番目のサブセットのピクチャレートが一定であるかどうかを示している。以下では、時間セグメントｔＳｅｇは、復号順で、レイヤセットのｉ番目のサブセットの２つ以上の連続するアクセスユニットの任意のセットであり、ｆＴｏｔａｌ（ｔＳｅｇ）は、時間セグメントｔＳｅｇ内のアクセスユニットの数であり、ｔ1（ｔＳｅｇ）は時間セグメントｔＳｅｇの第１のアクセスユニット（復号順）の除去時間（秒単位）であり、ｔ2（ｔＳｅｇ）は、時間セグメントｔＳｅｇの最後のアクセスユニット（復号順）の除去時間（秒単位）であり、ａｖｇＦＲ（ｔＳｅｇ）は、
【数７】
0006495268.tif 000012
【０１４１】
によって与えられる、時間セグメントｔＳｅｇ内の平均ピクチャレートである。
【０１４２】
−レイヤセットのｉ番目のサブセットが１つまたは２つのアクセスユニットだけを含むか、ａｖｇＦＲ（ｔＳｅｇ）の値がすべての時間セグメントにわたって一定である場合、ピクチャレートは一定であり、そうではない場合、ピクチャレートは一定ではない。
【０１４３】
−０と等しいｃｏｎｓｔａｎｔ＿ｐｉｃ＿ｒａｔｅ＿ｉｄｃ［ｉ］は、レイヤセットのｉ番目のサブセットのピクチャレートが一定ではないことを示している。１と等しいｃｏｎｓｔａｎｔ＿ｐｉｃ＿ｒａｔｅ＿ｉｄｃ［ｉ］は、レイヤセットのｉ番目のサブセットのピクチャレートが一定であることを示している。２と等しいｃｏｎｓｔａｎｔ＿ｐｉｃ＿ｒａｔｅ＿ｉｄｃ［ｉ］は、レイヤセットのｉ番目のサブセットのピクチャレートが一定でもよく、一定でなくてもよいことを示している。ｃｏｎｓｔａｎｔ＿ｐｉｃ＿ｒａｔｅ＿ｉｄｃ［ｉ］の値は、０から２まで（両方を含めて）の範囲内であるものとする。
【０１４４】
・ａｖｇ＿ｐｉｃ＿ｒａｔｅ［ｉ］は、レイヤセットのｉ番目のサブセットの平均ピクチャレートを２５６秒あたりのピクチャの単位で示している。ｆＴｏｔａｌがレイヤセットのｉ番目のサブセット内のアクセスユニットの数であり、ｔ1がＶＰＳが適用される第１のアクセスユニットの除去時間（秒単位）であり、ｔ2がＶＰＳが適用される最後のアクセスユニット（復号順）の除去時間（秒単位）である場合、以下が適用される。
【０１４５】
−ｔ1がｔ2と等しくない場合、以下の条件は真であるものとする。
【数８】
0006495268.tif 000013
【０１４６】
−そうではない場合（ｔ1がｔ2と等しい）、以下の条件は真であるものとする。
【数９】
0006495268.tif 000014
【０１４７】
[00115]上記の実施形態では、グローバルフラグｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとがＶＰＳ内でシグナリングされる。ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇは、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示し、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇは、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示している。ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとの両方が０と等しい場合、どのビットレートピクチャレートシンタックス構造もＶＰＳ内でシグナリングされない。ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇまたはｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ビットレートピクチャレートシンタックス構造がレイヤセットごとにシグナリングされる。レイヤセットは、１つまたは複数のレイヤのグループを指す場合がある。レイヤセットごとのビットレートピクチャレートシンタックス構造内で、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがサブレイヤごとにシグナリングされてよく、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがサブレイヤごとにシグナリングされてよい。
【０１４８】
[00116]同様に、デコーダ側で、グローバルフラグｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとがＶＰＳ内で受信される。ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇとが両方とも０と等しい場合、どのビットレートピクチャレートシンタックス構造もアクセスおよび／または処理されない。ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇまたはｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ビットレートピクチャレートシンタックス構造は、レイヤセットごとにアクセスおよび／または処理される。レイヤセットごとのビットレートピクチャレートシンタックス構造内で、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ｂｉｔ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがサブレイヤごとにアクセスおよび／または処理されてよく、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｖｐｓ＿ｆｌａｇが１と等しい場合、ｐｉｃ＿ｒａｔｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがサブレイヤごとにアクセスおよび／または処理されてよい。
【０１４９】
[00117]このように、本技法は、ＶＰＳ内で示されるすべてのレイヤについて、それぞれビットレート情報および／またはピクチャレート情報が存在するかどうかを示すグローバルフラグをＶＰＳ内に含めることによって、ビットレート情報および／またはピクチャレート情報を符号化および／または復号するためのリソースを減少させることができる。ビットレートピクチャレートシンタックス構造は、それがビットレート情報および／またはピクチャレート情報を含む場合のみアクセスされ得る。さらに、ビットレート情報およびピクチャレート情報は、別々にシグナリングおよび／または処理され得る。たとえば、ビットレート情報だけが必要な場合、ピクチャレート情報をシグナリングせずに、ビットレート情報だけをシグナリングすることができ、逆もまた同様である。
【０１５０】
[00118]本技法に関連する特定の詳細は図４〜図６を参照して以下で説明する。図４に関して説明するすべての特徴および／または実施形態は、単独で実装されてもよく、または図４〜図６で説明する他の特徴および／または実施形態との任意の組合せで実装されてもよい。
【０１５１】
ビューＩＤビット深度のシグナリングの方法
[00119]図４は、本開示の態様による、ビューＩＤビット深度をシグナリングまたは符号化するための方法を示すフローチャートである。プロセス４００は、実施形態に応じて、エンコーダ（たとえば、図２Ａ、図２Ｂ等に示されるエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂ等に示されるデコーダ）、または他の何らかの構成要素によって実行され得る。プロセス４００のブロックは、図２Ｂのエンコーダ２１に関連して説明されているが、プロセス４００は上述のデコーダなどの他の構成要素によって実行され得る。エンコーダ２１のレイヤ１ビデオエンコーダ２０Ｂ、および／またはエンコーダ２１のレイヤ０エンコーダ２０Ａは、実施形態に応じてプロセス４００を実行することができる。図４に関連して説明されるすべての実施形態は別々に実装されてもよく、相互に組み合わせて実装されてもよい。プロセス４００に関連する特定の詳細は、たとえば図５および図６に関して上記および以下で説明される。
【０１５２】
[00120]プロセス４００はブロック４０１から開始する。エンコーダ２１は、ビデオ情報を記憶するためのメモリ（たとえば、参照フレームメモリ６４）を含み得る。
【０１５３】
[00121]ブロック４０２で、エンコーダ２１は、シグナリングするための１つまたは複数のビュー識別子のビット深度を決定する。１つまたは複数のビュー識別子のそれぞれは、符号化されるべきレイヤに関連付けられ得る。１つまたは複数のビュー識別子のビット深度は、たとえば、同じビットストリーム内で符号化され得るビューの最大数に基づいて決定され得る。たとえば、符号化するためのビューの数（たとえば、最大値）に応じて適切にビット深度が選択され得るという意味で、ビュー識別子をシグナリングするためのビット深度は可変であり得る。レイヤは、スケーラブルビデオコーディング（たとえば、ＳＨＶＣ）におけるレイヤ、または３−Ｄビデオコーディング（たとえば、ＭＶ−ＨＥＶＣ）におけるレイヤなどの、ビデオ情報に関連付けられるレイヤを指す場合がある。ＳＨＶＣビットストリームは、通常、１台のカメラによってキャプチャされたビデオ信号を表し、ビットストリームは複数のレイヤを含むことができ、各レイヤは、異なる品質または異なる空間解像度を有するビデオ信号の表現に対応する。ＭＶ−ＨＥＶＣビットストリームは、通常、複数のカメラによってキャプチャされたビデオ信号を表し、ビットストリームは複数のレイヤを含むことができ、各レイヤは、別個のカメラによってキャプチャされたビデオ信号の一部の表現に対応する。ＭＶ−ＨＥＶＣにおけるレイヤもビューと呼ばれる場合がある。
【０１５４】
[00122]ブロック４０３で、エンコーダ２１は、ビットストリーム内で１つまたは複数のビュー識別子のビット深度をシグナリングする。いくつかの実施形態では、１つまたは複数のビュー識別子のビット深度がビデオパラメータセット（ＶＰＳ）内でシグナリングされる。一実施形態では、シグナリングされたビット深度によって示されるビットの数は１と１６との間である。シグナリングされたビット深度は、たとえば図５に関連して説明したように、デコーダによって受信および復号され得る。
【０１５５】
[00123]特定の実施形態では、エンコーダ２１は、ビットストリーム内でビュー識別子を明示的にシグナリングするかどうかをシグナリングする。一実施形態では、エンコーダ２１は、ビュー識別子明示的シグナリングフラグ（ｖｉｅｗ  ｉｄｅｎｔｉｆｉｅｒ  ｅｘｐｌｉｃｉｔｌｙ  ｓｉｇｎａｌｌｅｄ  ｆｌａｇ）をシグナリングすることによって、ビットストリーム内でビュー識別子を明示的にシグナリングするかどうかをシグナリングする。いくつかの実施形態では、エンコーダ２１は、シグナリングされたビット深度によって示されるビットの数を使用して、１つまたは複数のビュー識別子をシグナリングする。
【０１５６】
[00124]プロセス４００は、ブロック４０４において終了する。プロセス４００におけるブロックは実施形態に応じて追加および／または省略されてよく、プロセス４００のブロックは実施形態に応じて異なる順序で実行されて得る。
【０１５７】
[00125]本開示でリサンプリングに関して説明した任意の特徴および／または実施形態は、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図５〜図６に関連して説明した任意の特徴および／または実施形態は、図４に関連して説明した任意の特徴および／または実施形態との任意の組合せで実装されてよく、逆もまた同様である。
【０１５８】
[00126]図５は、本開示の態様による、ビューＩＤビット深度を復号するための方法を示すフローチャートである。プロセス５００は、実施形態に応じて、エンコーダ（たとえば、図２Ａ、図２Ｂ等に示されるエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂ等に示されるデコーダ）、または他の何らかの構成要素によって実行され得る。プロセス５００のブロックは、図３Ｂのデコーダ３１に関連して説明されているが、プロセス５００は上述のエンコーダなどの他の構成要素によって実行され得る。デコーダ３１のレイヤ１ビデオデコーダ３０Ｂ、および／またはデコーダ３１のレイヤ０デコーダ３０Ａは、実施形態に応じてプロセス５００を実行することができる。図５に関連して説明されるすべての実施形態は別々に実装されてもよく、相互に組み合わせて実装されてもよい。プロセス５００に関連する特定の詳細は上記で、たとえば図４〜図６に関連して説明される。
【０１５９】
[00127]プロセス５００はブロック５０１から開始する。デコーダ３１は、ビデオ情報を記憶するためのメモリ（たとえば、参照フレームメモリ８２）を含み得る。
【０１６０】
[00128]ブロック５０２で、デコーダ３１は、１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信する。１つまたは複数のビュー識別子値のそれぞれは、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられ得る。ビット深度インジケータは、図４に関連して上記で説明したように、エンコーダ２１によって符号化またはシグナリングされたビット深度であり得る。一実施形態では、ビット深度インジケータによって示されるビットの数は１と１６との間である。ビット深度インジケータは、符号化され得るビューの最大数を示すことができる。
【０１６１】
[00129]ブロック５０３で、デコーダ３１は、示された数のビットを有する値として、１つまたは複数のビュー識別子値のそれぞれを受信する。ビット深度インジケータと１つまたは複数のビュー識別子値とは、ＶＰＳ内で受信され得る。
【０１６２】
[00130]プロセス５００は、ブロック５０４において終了する。プロセス５００におけるブロックは実施形態に応じて追加および／または省略されてよく、プロセス５００のブロックは実施形態に応じて異なる順序で実行され得る。
【０１６３】
[00131]本開示でリサンプリングに関して説明した任意の特徴および／または実施形態は、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図４および図６に関連して説明した任意の特徴および／または実施形態は、図５に関連して説明した任意の特徴および／または実施形態との任意の組合せで実装されてよく、逆もまた同様である。
【０１６４】
ＶＰＳ内のビットレート情報および／またはピクチャレート情報のシグナリングの方法
[00132]図６は、本開示の態様による、ＶＰＳ内でビットレート情報および／またはピクチャレート情報をシグナリングするための方法を示すフローチャートである。プロセス６００は、実施形態に応じて、エンコーダ（たとえば、図２Ａ、図２Ｂ等に示されるエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂ等に示されるデコーダ）、または他の何らかの構成要素によって実行され得る。プロセス６００のブロックは図３Ｂのデコーダ３１に関して説明されるが、プロセス６００は、上述のエンコーダなどの他の構成要素によって実行され得る。実施形態に応じて、デコーダ３１のレイヤ１ビデオデコーダ３０Ｂおよび／またはデコーダ３１のレイヤ０デコーダ３０Ａがプロセス６００を実行し得る。図６に関して説明されるすべての実施形態は別々に実装されてもよく、相互に組み合わせて実装されてもよい。プロセス６００に関連する特定の詳細は、たとえば図４〜図５に関して上記および以下で説明される。
【０１６５】
[00133]プロセス６００はブロック６０１から開始する。デコーダ３１は、ビデオ情報を記憶するためのメモリ（たとえば、参照フレームメモリ８２）を含むことができる。
【０１６６】
[00134]ブロック６０２で、デコーダ３１は、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示す信号を処理する。レイヤセットは、１つまたは複数のレイヤのセットを指す場合があり、レイヤセットが複数のレイヤを含み得る点で、レイヤとは異なる場合がある。たとえば、信号は、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示すグローバルフラグであり得る。グローバルフラグは、ＶＰＳ内に含まれ得る。一実施形態では、信号を処理することは、信号を符号化することである。別の実施形態では、信号を処理することは、信号を復号することである。特定の実施形態では、コンピューティングデバイスは、エンコーダとデコーダとの両方の機能を実装し得る。
【０１６７】
[00135]ブロック６０３で、デコーダ３１は、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示す信号を処理する。たとえば、信号は、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示すグローバルフラグであり得る。グローバルフラグは、ＶＰＳ内に含まれ得る。一実施形態では、信号を処理することは、信号を符号化することである。別の実施形態では、信号を処理することは、信号を復号することである。特定の実施形態では、コンピューティングデバイスは、エンコーダとデコーダとの両方の機能を実装し得る。
【０１６８】
[00136]特定の実施形態では、デコーダ３１は、（１）第１の信号が、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤがシグナリングするためのビットレート情報を有することを示す場合、または、（２）第２の信号が、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤがシグナリングするためのピクチャレート情報を有することを示す場合のいずれかに、ビットレートピクチャレートシンタックス構造を処理する。いくつかの実施形態では、デコーダ３１は、第１の信号が、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有することを示す場合、１つまたは複数のレイヤセットのうちの１つのレイヤのサブレイヤがビットレート情報を有するかどうかを示すフラグを処理することと、また、第２の信号が、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有することを示す場合、１つまたは複数のレイヤセットのうちの１つのレイヤのサブレイヤが、ピクチャレート情報を有するかどうかを示すフラグを処理することとによって、ビットレートピクチャレートシンタックス構造を処理する。一実施形態では、ビットレートピクチャレートシンタックス構造を処理することは、ビットレートピクチャレートシンタックス構造を符号化することである。別の実施形態では、ビットレートピクチャレートシンタックス構造を処理することは、ビットレートピクチャレートシンタックス構造を復号することである。特定の実施形態では、コンピューティングデバイスは、エンコーダとデコーダとの両方の機能を実装し得る。
【０１６９】
[00137]いくつかの実施形態では、１つの信号は、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうか、および、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示すために使用され得る。たとえば、同じグローバルフラグは、１つまたは複数のレイヤセットおよび／またはサブレイヤが、ビットレート情報およびピクチャレート情報を有するかどうかを示すことができる。一実施形態では、情報の種類ごとのグローバルフラグは、１つのグローバルフラグに統合され得る。そのようなグローバルフラグは、ＶＰＳに含まれ得る。
【０１７０】
[00138]特定の態様によれば、デコーダ３１は、コンピューティングハードウェアは、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示す第１の信号、または、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示す第２の信号のうちの少なくとも１つを処理する。たとえば、ブロック６０２と６０３との両方を実行する代わりに、デコーダ３１は、たとえば１つのブロックにおいて、第１の信号と第２の信号とのうちの少なくとも１つを処理することができる。いくつかの実施形態では、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのビットレート情報を有するかどうかを示す信号だけが、ＶＰＳ内に含まれて、デコーダ３１によって処理され得る。他の実施形態では、１つまたは複数のレイヤセットのうちの少なくとも１つのサブレイヤが、シグナリングするためのピクチャレート情報を有するかどうかを示す信号だけが、ＶＰＳ内に含まれて、デコーダ３１によって処理され得る。
【０１７１】
[00139]プロセス６００はブロック６０４において終了する。プロセス６００におけるブロックは実施形態に応じて追加および／または省略されてよく、プロセス６００のブロックは実施形態に応じて異なる順序で実行され得る。
【０１７２】
[0140]本開示においてリサンプリングに関連して説明される任意の特徴および／または実施形態は、別々に実装されてもよく、それらの任意の組合せで実装されてもよい。たとえば、図４〜図５に関連して説明される任意の特徴および／または実施形態は、図６に関連して説明される任意の特徴および／または実施形態との任意の組合せで実装されてもよく、その逆でもよい。
【０１７３】
用語
[00141]上記の開示は特定の実施形態を記載しているが、多くの変形形態が可能である。たとえば、上述されたように、上記の技法は３Ｄビデオコーディングに適用され得る。３Ｄビデオのいくつかの実施形態では、参照レイヤ（たとえば、ベースレイヤ）は、ビデオの第１のビューを表示するのに十分なビデオ情報を含み、エンハンスメントレイヤは、参照レイヤに比べてさらなるビデオ情報を含み、その結果、参照レイヤおよびエンハンスメントレイヤは一緒に、ビデオの第２のビューを表示するのに十分な情報を含む。これらの２つのビューは、立体的な画像を生成するために使用され得る。上記で説明されたように、本開示の態様に従って、エンハンスメントレイヤ内でビデオユニットを符号化または復号するとき、参照レイヤからの動き情報は、さらなる暗黙的な仮説を識別するために使用され得る。これにより、３Ｄビデオのビットストリームについてのより大きいコーディング効率が実現され得る。
【０１７４】
[00142]例によっては、本明細書で説明された技法のうちいずれかの、いくつかの行為またはイベントは、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る（たとえば、すべての説明した作用またはイベントが、本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、同時に実行され得る。
【０１７５】
[00143]本明細書で開示される情報および信号は、多種多様な技術および技法のいずれかを使用して表され得る。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。
【０１７６】
[00144]本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、概してそれらの機能に関して上記で説明した。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課された設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
【０１７７】
[00145]本明細書で説明した技術は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなど、様々なデバイスのいずれかにおいて実装され得る。モジュールまたは構成要素として説明した任意の特徴は、集積論理デバイスに一緒に、または個別であるが相互運用可能な論理デバイスとして別々に実装され得る。ソフトウェアで実装された場合、本技法は、実行されたとき、上記で説明した方法のうちの１つまたは複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含むことがあるコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、シンクロナスダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュメモリ、磁気または光学データ記憶媒体など、メモリまたはデータ記憶媒体を備え得る。本技法は、追加または代替として、伝搬信号または電波など、命令またはデータ構造の形態でプログラムコードを搬送または伝達し、コンピュータによってアクセスされ、読み取られ、および／または実行され得るコンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
【０１７８】
[00146]プログラムコードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、または他の等価の集積回路もしくはディスクリート論理回路など、１つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明する技法のいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、ＤＳＰおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明する技法の実装に好適な他の構造または装置のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のソフトウェアモジュールもしくはハードウェアモジュール内に提供され得、または複合ビデオエンコーダ／デコーダ（コーデック）に組み込まれ得る。
【０１７９】
[00147]本明細書に記載のコーディング技法は、例示的なビデオ符号化および復号システムにおける実施形態であり得る。システムは、後に宛先デバイスによって復号されるべき符号化されたビデオデータを提供するソースデバイスを含む。特に、ソースデバイスは、コンピュータ可読媒体を介してビデオデータを宛先デバイスに提供する。ソースデバイスおよび宛先デバイスは、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、広い範囲のデバイスのいずれかを備え得る。場合によっては、ソースデバイスおよび宛先デバイスはワイヤレス通信のために装備され得る。
【０１８０】
[00148]宛先デバイスは、コンピュータ可読媒体を介して復号されるべき符号化されたビデオデータを受信することができる。コンピュータ可読媒体は、符号化されたビデオデータをソースから宛先デバイスに移動させることが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体は、ソースデバイス１２が、符号化されたビデオデータをリアルタイムに宛先デバイスに直接伝送することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に応じて変調されて、宛先デバイスに伝送され得る。通信媒体は、無線周波数（ＲＦ）スペクトル、あるいは１つまたは複数の物理的伝送回線などの、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネット等のグローバルネットワークなどの、パケットベースのネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイスから宛先デバイスへの通信を容易にするために有用であり得る他の何らかの装置を含み得る。
【０１８１】
[00149]いくつかの例では、符号化されたデータが、出力インターフェースから記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化されたビデオデータを記憶するための他の何らかの適切なデジタル記憶媒体などの、様々な分散された、またはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる例では、記憶デバイスが、ソースデバイスによって生成された、符号化されたビデオを記憶することができるファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイスは、ストリーミングまたはダウンロードを介して、記憶デバイスから記憶されたビデオデータにアクセスすることができる。ファイルサーバは、符号化されたビデオデータを記憶して、その符号化されたビデオデータを宛先デバイスに伝送することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、ウェブサーバ（たとえば、ウェブサイト用の）、ＦＴＰサーバ、ネットワーク接続型記憶（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイスは、インターネット接続を含む任意の標準的なデータ接続を通じて、符号化されたビデオデータにアクセスすることができる。これは、ファイルサーバに記憶された、符号化されたビデオデータにアクセスするために適したワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデム等）、または両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの伝送は、ストリーミング伝送、ダウンロード伝送、またはそれらの組合せであり得る。
【０１８２】
[00150]本開示の技法は、必ずしもワイヤレスアプリケーションまたは設定に限定されるとは限らない。本技法は、無線テレビ放送、ケーブルテレビ伝送、衛星テレビ伝送、動的適応型ＨＴＴＰストリーミング（ＤＡＳＨ）などのインターネットストリーミングビデオ伝送、データ記憶媒体に符号化されたデジタルビデオなどの、データ記憶媒体に記憶されたデジタルビデオの復号、または他のアプリケーションなどの、様々なマルチメディアアプリケーションのいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システムは、ビデオストリーミング、ビデオ再生、ビデオ放送、および／またはビデオ電話などのアプリケーションをサポートするために、一方向または双方向ビデオ伝送をサポートするように構成され得る。
【０１８３】
[00151]一例では、ソースデバイスは、ビデオソースと、ビデオエンコーダと、出力インターフェースとを含む。宛先デバイスは、入力インターフェースと、ビデオエンコーダと、ディスプレイデバイスとを含み得る。ソースデバイスのビデオエンコーダは、本明細書に開示された技法を適用するように構成され得る。他の例では、ソースデバイスと宛先デバイスは、他の構成要素または配置を含み得る。たとえば、ソースデバイスは、外部カメラなどの外部のビデオソースからビデオデータを受信することができる。同様に、宛先デバイスは、一体型ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースすることができる。
【０１８４】
[00152]上記の例示的なシステムは、一例に過ぎない。ビデオデータを並列に処理するための技法は、任意のデジタルビデオ符号化および／または復号化デバイスによって実行され得る。本開示の技法は、一般的にビデオエンコーディングデバイスによって実行されるが、本技法はまた、典型的に「ＣＯＤＥＣ」と呼ばれるビデオエンコーダ／デコーダによって実行され得る。さらに、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイスと宛先デバイスは、ソースデバイスが、宛先デバイスに伝送するための符号化されたビデオデータを生成するようなコーディングデバイスの単なる例である。いくつかの例では、ソースデバイスと宛先デバイスは、デバイスのそれぞれがビデオ符号化および復号化構成要素を含むように、実質的に対称的に動作することができる。したがって、例示的なシステムは、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のための、ビデオデバイス間の一方向または双方向ビデオ伝送をサポートすることができる。
【０１８５】
[00153]ビデオソースは、ビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースなどのビデオキャプチャデバイスを含み得る。さらなる代替として、ビデオソースは、ソースビデオとしてのコンピュータグラフィックベースのデータ、またはライブビデオと、アーカイブされたビデオと、コンピュータ生成ビデオとの組合せを生成することができる。場合によっては、ビデオソースがビデオカメラの場合、ソースデバイスと宛先デバイスは、いわゆるカメラ付き電話またはビデオ電話を形成することができる。しかしながら、上述のように、本開示に記載された技法は、一般的なビデオコーディングに適用可能でよく、ワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。各場合において、キャプチャされた、事前にキャプチャされた、またはコンピュータで生成されたビデオは、ビデオエンコーダによって符号化され得る。次いで、符号化されたビデオ情報は、出力インターフェースによってコンピュータ可読媒体上に出力され得る。
【０１８６】
[00154]上述のように、コンピュータ可読媒体は、ワイヤレスブロードキャストまたはワイヤードネットワーク伝送などの一時的媒体を含んでもよく、ハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含んでもよい。いくつかの例では、ネットワークサーバ（図示せず）が、ソースデバイスから符号化されたビデオデータを受信して、たとえばネットワーク伝送を介して、符号化されたビデオデータを宛先デバイスに提供することができる。同様に、ディスクスタンピング設備などの、媒体製造設備（ｍｅｄｉｕｍ  ｐｒｏｄｕｃｔｉｏｎ  ｆａｃｉｌｉｔｙ）のコンピューティングデバイスは、ソースデバイスから符号化されたビデオデータを受信して、符号化されたビデオデータを含むディスクを生成することができる。したがって、様々な例において、コンピュータ可読媒体は、様々な形態の１つまたは複数のコンピュータ可読媒体を含むものと理解され得る。
【０１８７】
[00155]宛先デバイスの入力インターフェースは、コンピュータ可読媒体から情報を受信する。コンピュータ可読媒体の情報は、ビデオエンコーダによって定義され、ビデオデコーダによっても使用され得る、ブロックおよび他の符号化されたユニット、たとえば画像のグループ（ＧＯＰ）の特性および／またはプロセスを記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイスは、復号されたビデオデータをユーザに表示して、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。本発明の様々な実施形態を説明してきた。これらおよび他の実施形態は、以下の特許請求の範囲内である。
【０１８８】
[00156]本発明の様々な実施形態について説明した。これらおよび他の実施形態は、以下の特許請求の範囲内に入る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］  ビデオ情報を符号化するための装置であって、
ビデオ情報を記憶するように構成されたメモリと、
前記メモリに動作可能に結合され、
シグナリングするための１つまたは複数のビュー識別子のビット深度を決定して、ここにおいて、前記１つまたは複数のビュー識別子のそれぞれが符号化されるべきレイヤに関連付けられる、
ビットストリーム内で前記１つまたは複数のビュー識別子の前記ビット深度をシグナリングするように構成されたコンピューティングハードウェアとを備える、装置。
［Ｃ２］  前記コンピューティングハードウェアが、符号化されるべきビューの最大数に基づいて、前記１つまたは複数のビュー識別子の前記ビット深度を決定するようにさらに構成される、Ｃ１に記載の装置。
［Ｃ３］  前記コンピューティングハードウェアが、ビデオパラメータセット（ＶＰＳ）内で前記ビュー識別子の前記ビット深度をシグナリングするようにさらに構成される、Ｃ１に記載の装置。
［Ｃ４］  前記コンピューティングハードウェアが、前記ビットストリーム内でビュー識別子を明示的にシグナリングするようにさらに構成される、Ｃ１に記載の装置。
［Ｃ５］  前記コンピューティングハードウェアが、ビュー識別子明示的シグナリングフラグをシグナリングすることによって、前記ビットストリーム内でビュー識別子を明示的にシグナリングするかどうかをシグナリングするように構成される、Ｃ４に記載の装置。
［Ｃ６］  前記コンピューティングハードウェアが、前記シグナリングされたビット深度によって示されるビットの前記数を使用して、前記１つまたは複数のビュー識別子をシグナリングするようにさらに構成される、Ｃ１に記載の装置。
［Ｃ７］  前記シグナリングされたビット深度によって示されるビットの前記数が１と１６との間である、Ｃ６に記載の装置。
［Ｃ８］  前記装置が、デスクトップコンピュータ、ノートブックコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、電話ハンドセット、スマートフォン、スマートパッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、およびビデオストリーミングデバイスのうちの１つまたは複数からなる群から選択される、Ｃ１に記載の装置。
［Ｃ９］  ビデオ情報を復号するための装置であって、
ビデオ情報を記憶するように構成されたメモリと、
前記メモリに動作可能に結合され、
１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信して、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられる、
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として受信するように構成されたコンピューティングハードウェアとを備える、装置。
［Ｃ１０］  前記ビット深度インジケータによって示されるビットの前記数が１と１６との間である、Ｃ９に記載の装置。
［Ｃ１１］  前記ビット深度インジケータと前記１つまたは複数のビュー識別子値とがＶＰＳ内で受信される、Ｃ９に記載の装置。
［Ｃ１２］  前記装置が、デスクトップコンピュータ、ノートブックコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、電話ハンドセット、スマートフォン、スマートパッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、およびビデオストリーミングデバイスのうちの１つまたは複数からなる群から選択される、Ｃ９に記載の装置。
［Ｃ１３］  ビュー識別子ビット深度をシグナリングする方法であって、
シグナリングするための１つまたは複数のビュー識別子のビット深度を決定することと、ここにおいて、前記１つまたは複数のビュー識別子のそれぞれが符号化されるべきレイヤに関連付けられる、
ビットストリーム内で前記１つまたは複数のビュー識別子の前記ビット深度をシグナリングすることとを備える、方法。
［Ｃ１４］  符号化されるべきビューの最大数に基づいて、前記１つまたは複数のビュー識別子の前記ビット深度を決定することをさらに備える、Ｃ１３に記載の方法。
［Ｃ１５］  前記１つまたは複数のビュー識別子の前記ビット深度が、ビデオパラメータセット（ＶＰＳ）内でシグナリングされる、Ｃ１３に記載の方法。
［Ｃ１６］  前記ビットストリーム内でビュー識別子を明示的にシグナリングするかどうかをシグナリングすることをさらに備える、Ｃ１３に記載の方法。
［Ｃ１７］  前記ビットストリーム内でビュー識別子を明示的にシグナリングするかどうかを前記シグナリングすることが、ビュー識別子明示的シグナリングフラグをシグナリングすることを備える、Ｃ１６に記載の方法。
［Ｃ１８］  前記コンピューティングハードウェアが、前記シグナリングされたビット深度によって示されるビットの前記数を使用して、前記ビュー識別子をシグナリングするようにさらに構成される、Ｃ１３に記載の方法。
［Ｃ１９］  前記シグナリングされたビット深度によって示されるビットの前記数が１と１６との間である、Ｃ１８に記載の方法。
［Ｃ２０］  ビデオ情報を復号する方法であって、
１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信することと、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤに関連付けられる、
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として受信することとを備える、方法。
［Ｃ２１］  前記ビット深度インジケータによって示されるビットの前記数が１と１６との間である、Ｃ２０に記載の方法。
［Ｃ２２］  前記ビット深度インジケータと前記１つまたは複数のビュー識別子値とがＶＰＳ内で受信される、Ｃ２０に記載の方法。
［Ｃ２３］  コンピューティングハードウェアを備えるプロセッサ上で実行されると、前記プロセッサに、
１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信することと、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられる、
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として受信することとを行わせる命令を備える、非一時的コンピュータ可読媒体。
［Ｃ２４］  前記ビット深度インジケータによって示されるビットの前記数が１と１６との間である、Ｃ２３に記載のコンピュータ可読媒体。
［Ｃ２５］  前記ビット深度インジケータと前記１つまたは複数のビュー識別子値とがＶＰＳ内で受信される、Ｃ２３に記載のコンピュータ可読媒体。
［Ｃ２６］  ビデオ情報をコーディングするように構成された装置であって、
１つまたは複数のビュー識別子値をシグナリングするために使用されるビットの数を示すビット深度インジケータを受信するための手段と、ここにおいて、前記１つまたは複数のビュー識別子値のそれぞれが、復号されるべき１つまたは複数のレイヤのうちの１つに関連付けられる、
前記１つまたは複数のビュー識別子値のそれぞれを、前記示された数のビットを有する値として受信するための手段とを備える、装置。
［Ｃ２７］  前記ビット深度インジケータによって示されるビットの前記数が１と１６との間である、Ｃ２６に記載の装置。
［Ｃ２８］  前記ビット深度インジケータと前記１つまたは複数のビュー識別子値とがＶＰＳ内で受信される、Ｃ２６に記載の装置。
【図１】
0006495268.tif 000015
【図２Ａ】
0006495268.tif 000016
【図２Ｂ】
0006495268.tif 000017
【図３Ａ】
0006495268.tif 000018
【図３Ｂ】
0006495268.tif 000019
【図４】
0006495268.tif 000020
【図５】
0006495268.tif 000021
【図６】
0006495268.tif 000022