(57)【特許請求の範囲】
【請求項１】
ＨＥＶＣのスケーラブルビデオコーディング拡張にしたがってビデオ情報をコーディングするための装置であって、
１つまたは複数のレイヤに関連付けられたビデオ情報を記憶するためのメモリと、
前記メモリに動作可能に結合され、
複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングすることと、前記複数のレイヤは、第１のレイヤ識別子（ＩＤ）シンタックス要素ｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する参照レイヤと、前記第１のレイヤＩＤよりも高い第２のレイヤＩＤシンタックス要素ｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つの対応するエンハンスメントレイヤとを含み、前記現在のＡＵは、２つ以上のシーケンス終了（ＥＯＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むことができ、
前記現在のＡＵにおいて、前記参照レイヤに関連付けられた第１のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じ第１のレイヤＩＤシンタックス要素を有し、
前記現在のＡＵにおいて、前記エンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じ第２のレイヤＩＤを有し、各レイヤはそれ自体のＥＯＳ  ＮＡＬユニットを有することができ、特定のレイヤ中のＥＯＳ  ＮＡＬユニットはその特定のレイヤのみに適用可能である、
を行うように構成されたハードウェアプロセッサと
を備える、装置。
【請求項２】
前記ハードウェアプロセッサは、
(i)前記第１のレイヤＩＤを有する前記第１のＥＯＳ  ＮＡＬユニットを含む前記現在のＡＵおよび(ii)前記第１のレイヤＩＤを有する第１のＩＲＡＰピクチャを含む後のＡＵ、に応答して、第１のＩＲＡＰピクチャの第１のＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを１に等しくさせることと、
(i)前記第２のレイヤＩＤを有する前記第２のＥＯＳ  ＮＡＬユニットを含む前記現在のＡＵおよび(ii)前記第２のレイヤＩＤを有する第２のＩＲＡＰピクチャを含む後のＡＵに応答して、第２のＩＲＡＰピクチャの第２のＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを１に等しくさせることと、
に基づいて前記現在のＡＵの後のＡＵをコーディングすること、
を行うようにさらに構成された、請求項１によるビデオ情報をコーディングするための装置。
【請求項３】
前記現在のＡＵの後のＡＵ中にあり、前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、切断リンクアクセス（ＢＬＡ）ピクチャ、またはクリーンランダムアクセス（ＣＲＡ）ピクチャのうちの１つまたは複数から選択されたイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、請求項１に記載の装置。
【請求項４】
前記現在のＡＵの後のＡＵ中にあり、前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャである、請求項１に記載の装置。
【請求項５】
前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤＩＤまたは前記参照レイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のビデオコーディングレイヤ（ＶＣＬ）ユニットの後にあり、前記第１のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、請求項１に記載の装置。
【請求項６】
前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤまたは前記エンハンスメントレイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、前記第２のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、請求項１に記載の装置。
【請求項７】
ＨＥＶＣのスケーラブルビデオコーディング拡張にしたがってビデオ情報をコーディングする方法であって、
１つまたは複数のレイヤに関連付けられたビデオ情報を記憶することと、
複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングすることと、前記複数のレイヤは、第１のレイヤ識別子（ＩＤ）シンタックス要素ｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する参照レイヤと、前記第１のレイヤＩＤよりも高い第２のレイヤＩＤシンタックス要素ｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つの対応するエンハンスメントレイヤとを含み、前記現在のＡＵは、２つ以上のシーケンス終了（ＥＯＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むことができ、
前記現在のＡＵにおいて、前記参照レイヤに関連付けられた第１のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じ第１のレイヤＩＤシンタックス要素を有し、
前記現在のＡＵにおいて、前記エンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じ第２のレイヤＩＤを有し、各レイヤはそれ自体のＥＯＳ  ＮＡＬユニットを有することができ、特定のレイヤ中のＥＯＳ  ＮＡＬユニットはその特定のレイヤのみに適用可能である、
を備える、方法。
【請求項８】
(i)前記第１のレイヤＩＤを有する前記第１のＥＯＳ  ＮＡＬユニットを含む前記現在のＡＵおよび(ii)前記第１のレイヤＩＤを有する第１のＩＲＡＰピクチャを含む後のＡＵ、に応答して、第１のＩＲＡＰピクチャの第１のＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを１に等しくさせることと、
(i)前記第２のレイヤＩＤを有する前記第２のＥＯＳ  ＮＡＬユニットを含む前記現在のＡＵおよび(ii)前記第２のレイヤＩＤを有する第２のＩＲＡＰピクチャを含む後のＡＵに応答して、第２のＩＲＡＰピクチャの第２のＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを１に等しくさせることと、
に基づいて前記現在のＡＵの後のＡＵをコーディングすること、
をさらに備える、請求項７に記載の方法。
【請求項９】
前記現在のＡＵの後のＡＵ中にあり、前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、切断リンクアクセス（ＢＬＡ）ピクチャ、またはクリーンランダムアクセス（ＣＲＡ）ピクチャのうちの１つまたは複数から選択されたイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、請求項７に記載の方法。
【請求項１０】
前記現在のＡＵの後のＡＵ中にあり、前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャである、請求項７に記載の方法。
【請求項１１】
前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤＩＤまたは前記参照レイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のビデオコーディングレイヤ（ＶＣＬ）ユニットの後にあり、前記第１のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、請求項７に記載の方法。
【請求項１２】
前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤまたは前記エンハンスメントレイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、前記第２のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、請求項７に記載の方法。
【請求項１３】
コンピュータハードウェアを備えるプロセッサ上で実行されたとき、請求項７〜１２のいずれか一項に記載の方法を前記プロセッサに行わせる命令を備える、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本開示は、シングルレイヤビデオコーディングとマルチレイヤビデオコーディングの両方を含む、ビデオコーディングおよび圧縮の分野に関する。マルチレイヤビデオコーディングは、スケーラブルビデオコーディング、マルチビュービデオコーディング、３次元（３Ｄ）ビデオコーディングなどを含み得る。
【背景技術】
【０００２】
[0002]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法などのビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００３】
[0003]ビデオ圧縮技法は、ビデオシーケンスにおける固有の冗長性を低減または除去するために空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を実施する。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレーム、ビデオフレームの一部分など）が、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック内の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００４】
[0004]空間予測または時間予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コード化ブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて、残差変換係数が得られ得、その残差変換係数は、次いで量子化され得る。量子化変換係数は、最初は２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するために、エントロピー符号化が適用され得る。
【発明の概要】
【０００５】
[0005]スケーラブルビデオコーディング（ＳＶＣ）は、参照レイヤ（ＲＬ：reference layer）と呼ばれることがあるベースレイヤ（ＢＬ：base layer）と、１つまたは複数のスケーラブルエンハンスメントレイヤ（ＥＬ：enhancement layer）とが使用されるビデオコーディングを指す。ＳＶＣでは、ベースレイヤは、ベースレベルの品質でビデオデータを搬送することができる。１つまたは複数のエンハンスメントレイヤは、たとえば、より高い空間レベル、時間レベル、および／または信号対雑音（ＳＮＲ：signal-to-noise）レベルをサポートするために追加のビデオデータを搬送することができる。エンハンスメントレイヤは、前に符号化されたレイヤに対して定義され得る。たとえば、最下位レイヤはＢＬとして働き得、最上位レイヤはＥＬとして働き得る。中間レイヤは、ＥＬまたはＲＬのいずれか、あるいはその両方として働き得る。たとえば、中間レイヤ（たとえば、最下位レイヤでも最上位レイヤでもないレイヤ）が、ベースレイヤまたは任意の介在エンハンスメントレイヤ（intervening enhancement layer）など、中間レイヤの下のレイヤのためのＥＬであり、同時に、中間レイヤの上の１つまたは複数のエンハンスメントレイヤのためのＲＬとして働き得る。同様に、ＨＥＶＣ規格のマルチビューまたは３Ｄ拡張では、複数のビューがあり得、１つのビューの情報は、別のビューの情報（たとえば、動き推定、動きベクトル予測および／または他の冗長）をコーディング（たとえば、符号化または復号）するために利用され得る。
【０００６】
[0006]いくつかの態様による、ビデオ情報をコーディングするための装置は、メモリとプロセッサとを含む。メモリは、複数のレイヤに関連付けられたビデオ情報を記憶するように構成される。プロセッサは、第１のシンタックス要素がビットストリーム中に存在するかどうかを決定するように構成され、第１のシンタックス要素は、シーケンスパラメータセット（ＳＰＳ）と、ＳＰＳを参照するピクチャのための参照ピクチャの時間識別子（ＩＤ）がネスティングされ（be nested）得るかどうかを示す第１のフラグとに関連付けられる。プロセッサは、第１のシンタックス要素がビットストリーム中に存在しないと決定したことに応答して、複数のレイヤのうちの特定のレイヤ中の時間サブレイヤの最大数を示す第２のシンタックス要素を取得することと、第１のフラグの値を第２のフラグの値に等しく設定すべきかどうかを決定することと、第２のフラグは、第２のシンタックス要素の値に少なくとも部分的に基づいて、任意のピクチャのための参照ピクチャの時間ＩＤがネスティングされ得るかどうかを示し、を行うようにさらに構成される。
【０００７】
[0007]いくつかの態様による、ビデオ情報をコーディングするための装置は、メモリとプロセッサとを含む。メモリは、１つまたは複数のレイヤに関連付けられたビデオ情報を記憶するように構成される。プロセッサは、複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングするように構成され、複数のレイヤは、参照レイヤと、少なくとも１つの対応するエンハンスメントレイヤとを含む。プロセッサは、現在のＡＵ中の参照レイヤに関連付けられた第１のシーケンス終了（ＥＯＳ：end of sequence）ネットワークアブストラクションレイヤ（ＮＡＬ：network abstraction layer）ユニットをコーディングするようにさらに構成され、第１のＥＯＳ  ＮＡＬユニットは参照レイヤと同じレイヤ識別子（ＩＤ）を有する。プロセッサはまた、現在のＡＵ中のエンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングするように構成され、第２のＥＯＳ  ＮＡＬユニットはエンハンスメントレイヤと同じレイヤＩＤを有する。
【０００８】
[0008]本開示のシステム、方法およびデバイスは、それぞれいくつかの発明的態様を有し、それらのうちの単一の態様が、本明細書で開示する望ましい属性を単独で担当するとは限らない。１つまたは複数の例の詳細は添付の図面および以下の説明に記載される。添付の図面および以下の説明は、本明細書で説明する発明的概念の全範囲を限定するものではない。他の特徴、目的、および利点は、説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【０００９】
【図１Ａ】[0009]本開示で説明する態様による技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図１Ｂ】[0010]本開示で説明する態様による技法を実施し得る別の例示的なビデオ符号化および復号システムを示すブロック図。
【図２Ａ】[0011]本開示で説明する態様による技法を実装し得るビデオエンコーダの一例を示すブロック図。
【図２Ｂ】[0012]本開示で説明する態様による技法を実装し得るビデオエンコーダの一例を示すブロック図。
【図３Ａ】[0013]本開示で説明する態様による技法を実装し得るビデオデコーダの一例を示すブロック図。
【図３Ｂ】[0014]本開示で説明する態様による技法を実装し得るビデオデコーダの一例を示すブロック図。
【図４】[0015]本開示の一実施形態による、異なるレイヤにおけるピクチャの例示的な構成を示すブロック図。
【図５】[0016]本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャート。
【図５Ａ】[0017]本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャート。
【図６】[0018]本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャート。
【発明を実施するための形態】
【００１０】
[0019]概して、本開示は、シングルレイヤコーディング、ならびにＨＥＶＣ（高効率ビデオコーディング）など、アドバンストビデオコーデックのコンテキストにおけるスケーラブルビデオコーディングのためのレイヤ間予測に関する。より詳細には、本開示は、ＳＨＶＣと呼ばれることがある、ＨＥＶＣのスケーラブルビデオコーディング拡張におけるレイヤ間予測の改善された性能のためのシステムおよび方法に関する。
【００１１】
[0020]以下の説明では、いくつかの実施形態に関係するＨ．２６４／アドバンストビデオコーディング（ＡＶＣ）技法が説明され、ＨＥＶＣ規格および関係する技法も説明される。いくつかの実施形態は、ＨＥＶＣおよび／またはＨ．２６４規格のコンテキストにおいて本明細書で説明されるが、本明細書で開示するシステムおよび方法が任意の好適なビデオコーディング規格に適用可能であり得ることを、当業者は諒解されよう。たとえば、本明細書で開示する実施形態は、以下の規格、すなわち、国際電気通信連合（ＩＴＵ）電気通信規格化セクタ（ＩＴＵ−Ｔ）Ｈ．２６１、国際標準化機構（ＩＳＯ）および国際電気標準会議（ＩＥＣ）（ＩＳＯ／ＩＥＣ）ムービングピクチャエキスパートグループ（ＭＰＥＧ：Moving Picture Experts Group）１（ＭＰＥＧ−１）  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４のうちの１つまたは複数に適用可能であり得る。
【００１２】
[0021]ＨＥＶＣは、概して、多くの点で、前のビデオコーディング規格のフレームワークに従う。ＨＥＶＣにおける予測のユニットは、いくつかの前のビデオコーディング規格における予測のユニット（たとえば、マクロブロック）とは異なる。事実上、マクロブロックの概念は、いくつかの前のビデオコーディング規格において理解されているように、ＨＥＶＣ中に存在しない。マクロブロックは、考えられる利益の中でも、高いフレキシビリティを与え得る、４分木方式に基づく階層構造と置き換えられる。たとえば、ＨＥＶＣ方式内で、３つのタイプのブロック、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ：Prediction Unit）、および変換ユニット（ＴＵ：Transform Unit）が定義される。ＣＵは領域分割の基本ユニットを指すことがある。ＣＵはマクロブロックの概念に類似すると見なされ得るが、ＨＥＶＣは、ＣＵの最大サイズを制限せず、コンテンツ適応性を改善するために４つの等しいサイズのＣＵへの再帰的分割（recursive splitting）を可能にし得る。ＰＵはインター／イントラ予測の基本ユニットと見なされ得、単一のＰＵは、不規則な画像パターンを効果的にコーディングするために、複数の任意の形状パーティションを含んでいることがある。ＴＵは変換の基本ユニットと見なされ得る。ＴＵは、ＰＵとは無関係に定義され得るが、ＴＵのサイズは、ＴＵが属するＣＵのサイズに制限され得る。３つの異なる概念へのブロック構造のこの分離は、各ユニットがユニットのそれぞれの役割に従って最適化されることを可能にし得、それによりコーディング効率が改善され得る。
【００１３】
[0022]単に説明の目的で、本明細書で開示するいくつかの実施形態が、ビデオデータのただ２つのレイヤ（たとえば、ベースレイヤなどの下位レイヤ、およびエンハンスメントレイヤなどの上位レイヤ）を含む例を用いて説明される。ビデオデータの「レイヤ」は、概して、ビュー、フレームレート、解像度などの少なくとも１つの共通の特性を有するピクチャのシーケンスを指すことがある。たとえば、レイヤは、マルチビュービデオデータの特定のビュー（たとえば、パースペクティブ（perspective））に関連付けられたビデオデータを含み得る。別の例として、レイヤは、スケーラブルビデオデータの特定のレイヤに関連付けられたビデオデータを含み得る。したがって、本開示は、ビデオデータのレイヤおよびビューを互換的に指すことがある。すなわち、ビデオデータのビューはビデオデータのレイヤと呼ばれることがあり、ビデオデータのレイヤはビデオデータのビューと呼ばれることがある。さらに、（マルチレイヤビデオコーダまたはマルチレイヤエンコーダデコーダとも呼ばれる）マルチレイヤコーデックは、マルチビューコーデックまたはスケーラブルコーデック（たとえば、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、ＳＨＶＣ、または別のマルチレイヤコーディング技法を使用するビデオデータを符号化および／または復号するように構成されたコーデック）を共同で指すことがある。ビデオ符号化およびビデオ復号は両方とも、概して、ビデオコーディングと呼ばれることがある。そのような例は、複数のベースレイヤおよび／またはエンハンスメントレイヤを含む構成に適用可能であり得ることを理解されたい。さらに、説明を簡単にするために、以下の開示は、いくつかの実施形態に関して「フレーム」または「ブロック」という用語を含む。ただし、これらの用語は限定的なものではない。たとえば、以下で説明する技法は、ブロック（たとえば、ＣＵ、ＰＵ、ＴＵ、マクロブロックなど）、スライス、フレームなど、任意の好適なビデオユニットとともに使用され得る。
【００１４】
ビデオコーディング規格
[0023]ビデオ画像、ＴＶ画像、静止画像、あるいはビデオレコーダまたはコンピュータによって生成された画像など、デジタル画像は、水平ラインおよび垂直ラインで構成されたピクセルまたはサンプルからなり得る。単一の画像中のピクセルの数は一般に数万個である。各ピクセルは、一般に、ルミナンス情報とクロミナンス情報とを含んでいる。圧縮がなければ、画像エンコーダから画像デコーダに搬送されるべき情報の甚だしい量（sheer quantity）は、リアルタイム画像送信を不可能にするであろう。送信されるべき情報の量を低減するために、ＪＰＥＧ、ＭＰＥＧおよびＨ．２６３規格など、いくつかの異なる圧縮方法が開発された。
【００１５】
[0024]ビデオコーディング規格は、ＩＴＵ−Ｔ  Ｈ．２６１と、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌと、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌと、ＩＴＵ−Ｔ  Ｈ．２６３と、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌと、それのＳＶＣおよびＭＶＣ拡張を含む（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４とを含む。
【００１６】
[0025]さらに、新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）が、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）とのジョイントコラボレーションチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）によって開発されている。ＨＥＶＣドラフト１０についての完全引用は、文書ＪＣＴＶＣ−Ｌ１００３、Ｂｒｏｓｓら、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ＩＴＵ−Ｔ  ＳＧ１６  ＷＰ３およびＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１のジョイントコラボレーティブチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaborative Team on Video Coding）、第１２回会合：ジュネーブ、スイス、２０１３年１月１４日〜２０１３年１月２３日である。ＨＥＶＣのマルチビュー拡張すなわちＭＶ−ＨＥＶＣ、およびＳＨＶＣと称されるＨＥＶＣのスケーラブル拡張も、それぞれＪＣＴ−３Ｖ（ＩＴＵ−Ｔ／ＩＳＯ／ＩＥＣのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発）およびＪＣＴ−ＶＣによって開発されている。
【００１７】
概要
[0026]マルチレイヤビットストリームでは、レイヤは１つまたは複数の時間サブレイヤを含むことができ、各時間サブレイヤは、時間ＩＤと呼ばれる、それに関連付けられた識別子（ＩＤ）を有することができる。概して、現在のピクチャよりも高い時間ＩＤを有するピクチャは現在のピクチャのための参照ピクチャとして使用されない。フラグｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇは、現在のピクチャの時間ＩＤに等しいかまたは現在のピクチャの時間ＩＤよりも低い時間ＩＤを有する特定のピクチャが、特定のピクチャよりも低い時間ＩＤを有し、復号順序において特定のピクチャに後続するが、復号順序において現在のピクチャに先行する、別のピクチャが存在するとき、参照ピクチャとして使用され得るかどうかをさらに示すことができる。
【００１８】
[0027]ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョン（たとえば、ＳＨＶＣのワーキングドラフト５およびＭＶ−ＨＥＶＣのワーキングドラフト７）は、ビットストリーム中にシンタックス要素が存在しないとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの導出において矛盾（conflict）を生じる。いくつかの条件下では、フラグの値が、０または１のいずれかであると決定されないことがある。これらおよび他のチャレンジに対処するために、いくつかの態様による技法は、矛盾をなくすために、そのような条件の下でｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値をどのように導出するかを定義する（たとえば、導出プロセスにおいて優先順位を設定する）ことができる。
【００１９】
[0028]さらに、ＨＥＶＣでは、１つのＡＵはただ１つのレイヤからのピクチャを含んでおり、しばしば、ピクチャの概念とＡＵの概念とは互換的に使用され得る。対照的に、ＳＨＶＣおよびＭＶ−ＨＥＶＣでは、１つのＡＵは２つ以上のレイヤからのピクチャを含んでいることがあり、これは、変数またはフラグが、特定のレイヤ（たとえば、ベースレイヤ）に関連付けられるべきなのか、ＡＵ全体に適用されるべきなのかを不確定にすることがある。そのような変数の一例はＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇである。変数ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは、ＣＲＡピクチャをＢＬＡピクチャとして処理すべきかどうかを示すことができる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンは、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇが、ベースレイヤのみに関連付けられるのか、ＡＵに関連付けられるのかを不明瞭にする。これらおよび他のチャレンジに対処するために、いくつかの態様による技法はまた、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇが、ベースレイヤのみに関連付けられるべきなのか、ＡＵに関連付けられるべきなのかを定義することができる。
【００２０】
[0029]その上、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇに関して上記で説明したように、ＳＨＶＣおよびＭＶ−ＨＥＶＣでは、１つのＡＵが２つ以上のレイヤからのピクチャを有することができるので、ＥＯＳ  ＮＡＬユニットが、特定のレイヤ（たとえば、ベースレイヤ）に関連付けられるべきなのか、ＡＵ全体に適用されるべきなのかは不確定であり得る。ＥＯＳ  ＮＡＬユニットは、コード化ビデオシーケンス（ＣＶＳ：coded video sequence）の終了を示すことができ、概して、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャなど、ＩＲＡＰピクチャが後続する。ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンは、ＥＯＳ  ＮＡＬユニットが、ベースレイヤのみに関連付けられるのか、ＡＵに関連付けられるのかを明瞭にしない。これらおよび他のチャレンジに対処するために、いくつかの態様による技法は、ＥＯＳ  ＮＡＬユニットがベースレイヤのみに関連付けられるべきなのか、ＡＵに関連付けられるべきなのかを定義することができる。
【００２１】
ビデオコーディングシステム
[0030]添付の図面を参照しながら新規のシステム、装置、および方法の様々な態様が以下でより十分に説明される。ただし、本開示は、多くの異なる形態で実施され得、本開示全体にわたって提示する任意の特定の構造または機能に限定されるものと解釈されるべきではない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるために与えられるものである。本明細書の教示に基づいて、本開示の範囲は、本開示の他の態様とは無関係に実装されるにせよ、本開示の他の態様と組み合わせて実装されるにせよ、本明細書で開示する新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者なら諒解されたい。たとえば、本明細書に記載される態様をいくつ使用しても、装置は実装され得、または方法は実施され得る。さらに、本開示の範囲は、本明細書に記載する本開示の様々な態様に加えてまたはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実施されるそのような装置または方法をカバーするものとする。本明細書で開示するどの態様も請求項の１つまたは複数の要素によって実施され得ることを理解されたい。
【００２２】
[0031]本明細書では特定の態様が説明されるが、これらの態様の多くの変形および置換は本開示の範囲内に入る。好適な態様のいくつかの利益および利点が説明されるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であるものとし、それらのいくつかが例として、図および好適な態様の以下の説明において示される。発明を実施するための形態および図面は、本開示を限定するものではなく説明するものにすぎず、本開示の範囲は添付の特許請求の範囲およびそれの均等物によって定義される。
【００２３】
[0032]添付の図面は例を示している。添付の図面中の参照番号によって示される要素は、以下の説明における同様の参照番号によって示される要素に対応する。本開示では、序数語（たとえば、「第１の」、「第２の」、「第３の」など）で始まる名前を有する要素は、必ずしもそれらの要素が特定の順序を有することを暗示するとは限らない。むしろ、そのような序数語は、同じまたは同様のタイプの異なる要素を指すために使用されるにすぎない。
【００２４】
[0033]図１Ａは、本開示で説明する態様による技法を利用し得る例示的なビデオコーディングシステム１０を示すブロック図である。本明細書で使用し説明する「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化とビデオ復号とを総称的に指すことがある。ビデオエンコーダおよびビデオデコーダに加えて、本出願で説明する態様は、トランスコーダ（たとえば、ビットストリームを復号し、別のビットストリームを再符号化することができるデバイス）およびミドルボックス（たとえば、ビットストリームを変更、変換、および／または場合によっては操作することができるデバイス）など、他の関係するデバイスに拡張され得る。
【００２５】
[0034]図１Ａに示されているように、ビデオコーディングシステム１０は、宛先デバイス１４によって後で復号されるべき符号化されたビデオデータを生成するソースデバイス１２を含む。図１Ａの例では、ソースデバイス１２および宛先デバイス１４は、別個のデバイスを構成する。ただし、ソースデバイス１２および宛先デバイス１４は、図１Ｂの例に示されているように、同じデバイス上にあるかまたは同じデバイスの一部であり得ることに留意されたい。
【００２６】
[0035]もう一度図１Ａを参照すると、ソースデバイス１２および宛先デバイス１４は、それぞれ、デスクトップコンピュータ、ノートブック（たとえば、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。
【００２７】
[0036]宛先デバイス１４は、復号されるべき符号化されたビデオデータをリンク１６を介して受信し得る。リンク１６は、ソースデバイス１２から宛先デバイス１４に符号化されたビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。図１Ａの例では、リンク１６は、ソースデバイス１２が符号化されたビデオデータをリアルタイムで宛先デバイス１４に送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワークなどのパケットベースネットワーク、またはインターネットなどのグローバルネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得る任意の他の機器を含み得る。
【００２８】
[0037]代替的に、符号化されたデータは出力インターフェース２２から随意のストレージデバイス３１に出力され得る。同様に、符号化されたデータは、たとえば、宛先デバイス１４の入力インターフェース２８によってストレージデバイス３１からアクセスされ得る。ストレージデバイス３１は、ハードドライブ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス３１は、ソースデバイス１２によって生成された符号化されたビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介してストレージデバイス３１から記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス１４に送信することができる任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を通して符号化されたビデオデータにアクセスし得る。これは、ファイルサーバ上に記憶された符号化されたビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）接続）、ワイヤード接続（たとえば、デジタル加入者線（ＤＳＬ）、ケーブルモデムなど）、またはその両方の組合せを含み得る。ストレージデバイス３１からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはその両方の組合せであり得る。
【００２９】
[0038]本開示の技法はワイヤレス適用例または設定に限定されない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信（たとえば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）上での動的適応ストリーミングなど）、データ記憶媒体上に記憶するためのデジタルビデオの符号化、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、ビデオコーディングシステム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【００３０】
[0039]図１Ａの例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。場合によっては、出力インターフェース２２は、変調器／復調器（モデム）および／または送信機を含み得る。ソースデバイス１２において、ビデオソース１８は、ビデオキャプチャデバイス、たとえばビデオカメラ、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および／またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、あるいはそのようなソースの組合せを含み得る。一例として、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、図１Ｂの例に示されているように、いわゆる「カメラフォン」または「ビデオフォン」を形成し得る。ただし、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。
【００３１】
[0040]キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオデータは、ソースデバイス１２の出力インターフェース２２を介して宛先デバイス１４に送信され得る。符号化ビデオデータは、さらに（または代替として）、復号および／または再生のための宛先デバイス１４または他のデバイスによる後のアクセスのためにストレージデバイス３１上に記憶され得る。図１Ａおよび図１Ｂに示されているビデオエンコーダ２０は、図２Ａ示されているビデオエンコーダ２０、図２Ｂに示されているビデオエンコーダ２３、または本明細書で説明する任意の他のビデオエンコーダを備え得る。
【００３２】
[0041]図１Ａの例では、宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。場合によっては、入力インターフェース２８は、受信機および／またはモデムを含み得る。宛先デバイス１４の入力インターフェース２８は、リンク１６を介しておよび／またはストレージデバイス３１から符号化されたビデオデータを受信し得る。リンク１６を介して通信され、またはストレージデバイス３１上に与えられた符号化されたビデオデータは、ビデオデータを復号する際に、ビデオデコーダ３０などのビデオデコーダが使用するためのビデオエンコーダ２０によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信された、記憶媒体上に記憶された、またはファイルサーバに記憶された符号化されたビデオデータに含まれ得る。図１Ａおよび図１Ｂに示されているビデオデコーダ３０は、図３Ａ示されているビデオデコーダ３０、図３Ｂに示されているビデオデコーダ３３、または本明細書で説明する任意の他のビデオデコーダを備え得る。
【００３３】
[0042]ディスプレイデバイス３２は、宛先デバイス１４と一体化されるかまたはその外部にあり得る。いくつかの例では、宛先デバイス１４は、一体型ディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス１４はディスプレイデバイスであり得る。概して、ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００３４】
[0043]関係する態様では、図１Ｂは例示的なビデオ符号化および復号システム１０’を示し、ここにおいて、ソースデバイス１２および宛先デバイス１４はデバイス１１上にあるかまたはデバイス１１の一部である。デバイス１１は、「スマート」フォンなどの電話ハンドセットであり得る。デバイス１１は、ソースデバイス１２および宛先デバイス１４と動作可能に通信している随意のコントローラ／プロセッサデバイス１３を含み得る。図１Ｂのシステム１０’は、ビデオエンコーダ２０と出力インターフェース２２との間のビデオ処理ユニット２１をさらに含み得る。いくつかの実装形態では、図１Ｂに示されているように、ビデオ処理ユニット２１は別個のユニットであるが、他の実装形態では、ビデオ処理ユニット２１は、ビデオエンコーダ２０および／またはプロセッサ／コントローラデバイス１３の一部分として実装され得る。システム１０’はまた、ビデオシーケンス中の関心（interest）のオブジェクトを追跡することができる随意のトラッカー２９を含み得る。追跡されるべきオブジェクトまたは関心は、本開示の１つまたは複数の態様に関して説明する技法によってセグメント化され得る。関係する態様では、追跡することは、単独でまたはトラッカー２９とともに、ディスプレイデバイス３２によって実施され得る。図１Ｂのシステム１０’およびそれの構成要素は、場合によっては図１Ａのシステム１０およびそれの構成要素と同様である。
【００３５】
[0044]ビデオエンコーダ２０およびビデオデコーダ３０は、ＨＥＶＣなどのビデオ圧縮規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，ＡＶＣと呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、またはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例はＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３を含む。
【００３６】
[0045]図１Ａおよび図１Ｂの例には示されていないが、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。
【００３７】
[0046]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体中にソフトウェアのための命令を記憶し、本開示の技法を実施するために１つまたは複数のプロセッサを使用してその命令をハードウェアで実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。
【００３８】
ビデオコーディングプロセス
[0047]上記で手短に述べたように、ビデオエンコーダ２０はビデオデータを符号化する。ビデオデータは１つまたは複数のピクチャを備え得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。いくつかの事例では、ピクチャはビデオ「フレーム」と呼ばれることがある。ビデオエンコーダ２０がビデオデータを符号化するとき、ビデオエンコーダ２０はビットストリームを生成し得る。ビットストリームは、ビデオデータのコード化された表現を形成するビットのシーケンスを含み得る。ビットストリームは、コード化されたピクチャと関連データとを含み得る。コード化されたピクチャとは、ピクチャのコード化された表現である。
【００３９】
[0048]ビットストリームを生成するために、ビデオエンコーダ２０は、ビデオデータ中の各ピクチャに対して符号化演算を実施し得る。ビデオエンコーダ２０がピクチャに対して符号化演算を実施するとき、ビデオエンコーダ２０は、一連のコード化されたピクチャと関連データとを生成し得る。関連データは、ビデオパラメータセット（ＶＰＳ）と、シーケンスパラメータセット（ＳＰＳ）と、ピクチャパラメータセット（ＰＰＳ）と、適応パラメータセット（ＡＰＳ）と、他のシンタックス構造とを含み得る。ＳＰＳは、ピクチャの０個以上のシーケンスに適用可能なパラメータを含んでいることがある。ＰＰＳは、０個以上のピクチャに適用可能なパラメータを含んでいることがある。ＡＰＳは、０個以上のピクチャに適用可能なパラメータを含んでいることがある。ＡＰＳ中のパラメータは、ＰＰＳ中のパラメータよりも変化する可能性が高いパラメータであり得る。
【００４０】
[0049]コード化されたピクチャを生成するために、ビデオエンコーダ２０は、ピクチャを等しいサイズのビデオブロックに区分し得る。ビデオブロックはサンプルの２次元アレイであり得る。ビデオブロックの各々はツリーブロックに関連付けられる。いくつかの事例では、ツリーブロックは、最大コーディングユニット（ＬＣＵ：largest coding unit）と呼ばれることがある。ＨＥＶＣのツリーブロックは、Ｈ．２６４／ＡＶＣなど、以前の規格のマクロブロックに広い意味で類似し得る。しかしながら、ツリーブロックは、必ずしも特定のサイズに限定されるとは限らず、１つまたは複数のコーディングユニット（ＣＵ）を含み得る。ビデオエンコーダ２０は、ツリーブロックのビデオブロックを、ＣＵに関連付けられたビデオブロックに区分するために、４分木区分（quadtree partitioning）を使用し得、したがって「ツリーブロック」という名前がある。
【００４１】
[0050]いくつかの例では、ビデオエンコーダ２０はピクチャを複数のスライスに区分し得る。スライスの各々は整数個のＣＵを含み得る。いくつかの事例では、スライスは整数個のツリーブロックを備える。他の事例では、スライスの境界はツリーブロック内にあり得る。
【００４２】
[0051]ピクチャに対して符号化演算を実施することの一部として、ビデオエンコーダ２０は、ピクチャの各スライスに対して符号化演算を実施し得る。ビデオエンコーダ２０がスライスに対して符号化演算を実施するとき、ビデオエンコーダ２０は、スライスに関連付けられた符号化されたデータを生成し得る。スライスに関連付けられた符号化されたデータは「コード化されたスライス」と呼ばれることがある。
【００４３】
[0052]コード化されたスライスを生成するために、ビデオエンコーダ２０は、スライス中の各ツリーブロックに対して符号化演算を実施し得る。ビデオエンコーダ２０がツリーブロックに対して符号化演算を実施するとき、ビデオエンコーダ２０はコード化されたツリーブロックを生成し得る。コード化されたツリーブロックは、ツリーブロックの符号化されたバージョンを表すデータを備え得る。
【００４４】
[0053]ビデオエンコーダ２０がコード化されたスライスを生成するとき、ビデオエンコーダ２０は、ラスタ走査順序に従って、スライス中のツリーブロックに対して符号化演算を実施し得る（たとえば、そのツリーブロックを符号化し得る）。たとえば、ビデオエンコーダ２０は、スライス中のツリーブロックの一番上の行にわたって左から右に進み、次いでツリーブロックの次の下の行にわたって左から右に進み、以下同様に進む順序で、ビデオエンコーダ２０がスライス中のツリーブロックの各々を符号化するまで、スライスのツリーブロックを符号化し得る。
【００４５】
[0054]ラスタ走査順序に従ってツリーブロックを符号化した結果として、所与のツリーブロックの上および左のツリーブロックは符号化されていることがあるが、所与のツリーブロックの下および右のツリーブロックはまだ符号化されていない。したがって、ビデオエンコーダ２０は、所与のツリーブロックを符号化するとき、所与のツリーブロックの上および左のツリーブロックを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ２０は、所与のツリーブロックを符号化するとき、所与のツリーブロックの下および右のツリーブロックを符号化することによって生成された情報にアクセスすることができないことがある。
【００４６】
[0055]コード化されたツリーブロックを生成するために、ビデオエンコーダ２０は、ビデオブロックを徐々により小さいビデオブロックに分割するために、ツリーブロックのビデオブロックに対して４分木区分を再帰的に実施し得る。より小さいビデオブロックの各々は、異なるＣＵに関連付けられ得る。たとえば、ビデオエンコーダ２０は、ツリーブロックのビデオブロックを４つの等しいサイズのサブブロックに区分し、サブブロックのうちの１つまたは複数を、４つの等しいサイズのサブサブブロックに区分し得、以下同様である。区分されたＣＵは、それのビデオブロックが、他のＣＵに関連付けられたビデオブロックに区分された、ＣＵであり得る。区分されていないＣＵは、それのビデオブロックが、他のＣＵに関連付けられたビデオブロックに区分されていない、ＣＵであり得る。
【００４７】
[0056]ビットストリーム中の１つまたは複数のシンタックス要素は、ビデオエンコーダ２０がツリーブロックのビデオブロックを区分し得る最大の回数を示し得る。ＣＵのビデオブロックは形状が正方形であり得る。ＣＵのビデオブロックのサイズ（たとえば、ＣＵのサイズ）は、８×８ピクセルから、最大６４×６４以上のピクセルをもつツリーブロックのビデオブロックのサイズ（たとえば、ツリーブロックのサイズ）までに及び得る。
【００４８】
[0057]ビデオエンコーダ２０は、ｚ走査順序に従って、ツリーブロックの各ＣＵに対して符号化演算を実施し得る（たとえば、各ＣＵを符号化し得る）。言い換えれば、ビデオエンコーダ２０は、左上のＣＵと、右上のＣＵと、左下のＣＵと、次いで右下のＣＵとを、その順序で符号化し得る。ビデオエンコーダ２０が、区分されたＣＵに対して符号化演算を実施するとき、ビデオエンコーダ２０は、ｚ走査順序に従って、区分されたＣＵのビデオブロックのサブブロックに関連付けられたＣＵを符号化し得る。言い換えれば、ビデオエンコーダ２０は、左上のサブブロックに関連付けられたＣＵと、右上のサブブロックに関連付けられたＣＵと、左下のサブブロックに関連付けられたＣＵと、次いで右下のサブブロックに関連付けられたＣＵとを、その順序で符号化し得る。
【００４９】
[0058]ｚ走査順序に従ってツリーブロックのＣＵを符号化した結果として、所与のＣＵの上、左上、右上、左、および左下のＣＵは符号化されていることがある。所与のＣＵの下および右のＣＵはまだ符号化されていない。したがって、ビデオエンコーダ２０は、所与のＣＵを符号化するとき、所与のＣＵに隣接するいくつかのＣＵを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ２０は、所与のＣＵを符号化するとき、所与のＣＵに隣接する他のＣＵを符号化することによって生成された情報にアクセスすることができないことがある。
【００５０】
[0059]ビデオエンコーダ２０が、区分されていないＣＵを符号化するとき、ビデオエンコーダ２０は、ＣＵのために１つまたは複数の予測ユニット（ＰＵ）を生成し得る。ＣＵのＰＵの各々は、ＣＵのビデオブロック内の異なるビデオブロックに関連付けられ得る。ビデオエンコーダ２０は、ＣＵの各ＰＵについて予測されたビデオブロックを生成し得る。ＰＵの予測されたビデオブロックはサンプルのブロックであり得る。ビデオエンコーダ２０は、ＰＵのための予測されたビデオブロックを生成するために、イントラ予測またはインター予測を使用し得る。
【００５１】
[0060]ビデオエンコーダ２０がＰＵの予測されたビデオブロックを生成するためにイントラ予測を使用するとき、ビデオエンコーダ２０は、ＰＵに関連付けられたピクチャの復号されたサンプルに基づいて、ＰＵの予測されたビデオブロックを生成し得る。ビデオエンコーダ２０がＣＵのＰＵの予測されたビデオブロックを生成するためにイントラ予測を使用する場合、ＣＵはイントラ予測されたＣＵである。ビデオエンコーダ２０がＰＵの予測されたビデオブロックを生成するためにインター予測を使用するとき、ビデオエンコーダ２０は、ＰＵに関連付けられたピクチャ以外の１つまたは複数のピクチャの復号されたサンプルに基づいて、ＰＵの予測されたビデオブロックを生成し得る。ビデオエンコーダ２０がＣＵのＰＵの予測されたビデオブロックを生成するためにインター予測を使用する場合、ＣＵはインター予測されたＣＵである。
【００５２】
[0061]さらに、ビデオエンコーダ２０がＰＵのための予測されたビデオブロックを生成するためにインター予測を使用するとき、ビデオエンコーダ２０はＰＵの動き情報を生成し得る。ＰＵの動き情報は、ＰＵの１つまたは複数の参照ブロックを示し得る。ＰＵの各参照ブロックは参照ピクチャ内のビデオブロックであり得る。参照ピクチャはＰＵに関連付けられたピクチャ以外のピクチャであり得る。いくつかの事例では、ＰＵの参照ブロックはＰＵの「参照サンプル」と呼ばれることもある。ビデオエンコーダ２０は、ＰＵの参照ブロックに基づいて、ＰＵのための予測されたビデオブロックを生成し得る。
【００５３】
[0062]ビデオエンコーダ２０がＣＵの１つまたは複数のＰＵのための予測されたビデオブロックを生成した後、ビデオエンコーダ２０は、ＣＵのＰＵのための予測されたビデオブロックに基づいて、ＣＵの残差データを生成し得る。ＣＵの残差データは、ＣＵのＰＵのための予測されたビデオブロック中のサンプルと、ＣＵの元のビデオブロック中のサンプルとの間の差を示し得る。
【００５４】
[0063]さらに、区分されていないＣＵに対して符号化演算を実施することの一部として、ビデオエンコーダ２０は、ＣＵの残差データを、ＣＵの変換ユニット（ＴＵ）に関連付けられた残差データの１つまたは複数のブロック（たとえば、残差ビデオブロック）に区分するために、ＣＵの残差データに対して再帰的な４分木区分を実施し得る。ＣＵの各ＴＵは異なる残差ビデオブロックに関連付けられ得る。
【００５５】
[0064]ビデオエンコーダ２０は、ＴＵに関連付けられた変換係数ブロック（たとえば、変換係数のブロック）を生成するために、ＴＵに関連付けられた残差ビデオブロックに１つまたは複数の変換を適用し得る。概念的に、変換係数ブロックは変換係数の２次元（２Ｄ）行列であり得る。
【００５６】
[0065]変換係数ブロックを生成した後、ビデオエンコーダ２０は、変換係数ブロックに対して量子化プロセスを実施し得る。量子化は、一般に、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、変換係数の一部または全部に関連付けられたビット深度を低減し得る。たとえば、量子化中にｎビットの変換係数がｍビットの変換係数に切り捨てられることがあり、ここで、ｎはｍよりも大きい。
【００５７】
[0066]ビデオエンコーダ２０は、各ＣＵを量子化パラメータ（ＱＰ：quantization parameter）値に関連付け得る。ＣＵに関連付けられたＱＰ値は、ビデオエンコーダ２０が、ＣＵに関連付けられた変換係数ブロックをどのように量子化するかを決定し得る。ビデオエンコーダ２０は、ＣＵに関連付けられたＱＰ値を調整することによって、ＣＵに関連付けられた変換係数ブロックに適用される量子化の程度を調整し得る。
【００５８】
[0067]ビデオエンコーダ２０が変換係数ブロックを量子化した後、ビデオエンコーダ２０は、量子化された変換係数ブロック中で変換係数を表すシンタックス要素のセットを生成し得る。ビデオエンコーダ２０は、これらのシンタックス要素のうちのいくつかに、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：Context Adaptive Binary Arithmetic Coding）演算などのエントロピー符号化演算を適用し得る。コンテンツ適応型可変長コーディング（ＣＡＶＬＣ：content adaptive variable length coding）、確率間隔区分エントロピー（ＰＩＰＥ：probability interval partitioning entropy）コーディング、または他のバイナリ算術コーディングなど、他のエントロピーコーディング技法も使用され得る。
【００５９】
[0068]ビデオエンコーダ２０によって生成されるビットストリームは、一連のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含み得る。ＮＡＬユニットの各々は、ＮＡＬユニット中のデータのタイプの指示と、データを含んでいるバイトとを含んでいるシンタックス構造であり得る。たとえば、ＮＡＬユニットは、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、コード化されたスライス、補足エンハンスメント情報（ＳＥＩ：supplemental enhancement information）、アクセスユニット区切り文字（access unit delimiter）、フィラーデータ（filler data）、または別のタイプのデータを表すデータを含み得る。ＮＡＬユニット中のデータは様々なシンタックス構造を含み得る。
【００６０】
[0069]ビデオデコーダ３０は、ビデオエンコーダ２０によって生成されたビットストリームを受信し得る。ビットストリームは、ビデオエンコーダ２０によって符号化されたビデオデータのコード化された表現を含み得る。ビデオデコーダ３０がビットストリームを受信するとき、ビデオデコーダ３０は、ビットストリームに対してパース演算（parsing operation）を実施し得る。ビデオデコーダ３０がパース演算を実施するとき、ビデオデコーダ３０は、ビットストリームからシンタックス要素を抽出し得る。ビデオデコーダ３０は、ビットストリームから抽出されたシンタックス要素に基づいて、ビデオデータのピクチャを再構成し得る。シンタックス要素に基づいてビデオデータを再構成するためのプロセスは、一般に、シンタックス要素を生成するためにビデオエンコーダ２０によって実施されるプロセスとは逆であり得る。
【００６１】
[0070]ビデオデコーダ３０がＣＵに関連付けられたシンタックス要素を抽出した後、ビデオデコーダ３０は、シンタックス要素に基づいて、ＣＵのＰＵのための予測されたビデオブロックを生成し得る。さらに、ビデオデコーダ３０は、ＣＵのＴＵに関連付けられた変換係数ブロックを逆量子化し得る。ビデオデコーダ３０は、ＣＵのＴＵに関連付けられた残差ビデオブロックを再構成するために変換係数ブロックに対して逆変換を実施し得る。予測されたビデオブロックを生成し、残差ビデオブロックを再構成した後、ビデオデコーダ３０は、予測されたビデオブロックと残差ビデオブロックとに基づいて、ＣＵのビデオブロックを再構成し得る。このようにして、ビデオデコーダ３０は、ビットストリーム中のシンタックス要素に基づいて、ＣＵのビデオブロックを再構成し得る。
【００６２】
ビデオエンコーダ
[0071]図２Ａは、本開示で説明する態様による技法を実装し得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、ＨＥＶＣの場合など、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオエンコーダ２０は、限定はしないが、図４および図５に関して上記および下記でより詳細に説明するＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇを推論する方法および関係するプロセスを含む、本開示の技法のいずれかまたはすべてを実施するように構成され得る。一例として、予測処理ユニット１００は、本開示で説明する技法のいずれかまたはすべてを実施するように構成され得る。別の実施形態では、ビデオエンコーダ２０は、本開示で説明する技法のいずれかまたはすべてを実施するように構成された随意のレイヤ間予測ユニット１２８を含む。他の実施形態では、レイヤ間予測は予測処理ユニット１００（たとえば、インター予測ユニット１２１および／またはイントラ予測ユニット１２６）によって実施され得、その場合、レイヤ間予測ユニット１２８は省略され得る。ただし、本開示の態様はそのように限定されない。いくつかの例では、本開示で説明する技法は、ビデオエンコーダ２０の様々な構成要素間で共有され得る。いくつかの例では、追加または代替として、プロセッサ（図示せず）が、本開示で説明する技法のいずれかまたはすべてを実施するように構成され得る。
【００６３】
[0072]説明の目的で、本開示は、ＨＥＶＣコーディングのコンテキストにおいてビデオエンコーダ２０について説明する。しかしながら、本開示の技法は、他のコーディング規格または方法にも適用可能であり得る。図２Ａに示された例はシングルレイヤコーデックのためのものである。しかしながら、図２Ｂに関してさらに説明するように、ビデオエンコーダ２０の一部または全部はマルチレイヤコーデックの処理のために複製され得る。
【００６４】
[0073]ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実施し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間冗長性を低減または削除するために、時間予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースコーディングモードのいずれかを指すことがある。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指すことがある。
【００６５】
[0074]図２Ａの例では、ビデオエンコーダ２０は複数の機能構成要素を含む。ビデオエンコーダ２０の機能構成要素は、予測処理ユニット１００と、残差生成ユニット１０２と、変換処理ユニット１０４と、量子化ユニット１０６と、逆量子化ユニット１０８と、逆変換ユニット１１０と、再構成ユニット１１２と、フィルタユニット１１３と、復号されたピクチャバッファ１１４と、エントロピー符号化ユニット１１６とを含む。予測処理ユニット１００は、インター予測ユニット１２１と、動き推定ユニット１２２と、動き補償ユニット１２４と、イントラ予測ユニット１２６と、レイヤ間予測ユニット１２８とを含む。他の例では、ビデオエンコーダ２０は、より多数の、より少数の、または異なる機能構成要素を含み得る。さらに、動き推定ユニット１２２と動き補償ユニット１２４とは、高度に統合され得るが、図２Ａの例では、説明の目的で別々に表されている。
【００６６】
[0075]ビデオエンコーダ２０はビデオデータを受信し得る。ビデオエンコーダ２０は、様々なソースからビデオデータを受信し得る。たとえば、ビデオエンコーダ２０は、（たとえば、図１Ａまたは図１Ｂに示された）ビデオソース１８、または別のソースからビデオデータを受信し得る。ビデオデータは一連のピクチャを表し得る。ビデオデータを符号化するために、ビデオエンコーダ２０は、ピクチャの各々に対して符号化演算を実施し得る。ピクチャに対して符号化演算を実施することの一部として、ビデオエンコーダ２０は、ピクチャの各スライスに対して符号化演算を実施し得る。スライスに対して符号化演算を実施することの一部として、ビデオエンコーダ２０は、スライス中のツリーブロックに対して符号化演算を実施し得る。
【００６７】
[0076]ツリーブロックに対して符号化演算を実施することの一部として、予測処理ユニット１００は、ビデオブロックを徐々により小さいビデオブロックに分割するためにツリーブロックのビデオブロックに対して４分木区分を実施し得る。より小さいビデオブロックの各々は、異なるＣＵに関連付けられ得る。たとえば、予測処理ユニット１００は、ツリーブロックのビデオブロックを４つの等しいサイズのサブブロックに区分し、サブブロックの１つまたは複数を、４つの等しいサイズのサブサブブロックに区分し得、以下同様である。
【００６８】
[0077]ＣＵに関連付けられたビデオブロックのサイズは、８×８サンプルから、最大６４×６４以上のサンプルをもつツリーブロックのサイズまでに及び得る。本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのサンプル寸法、たとえば、１６×１６（16x16）サンプルまたは１６×１６（16 by 16）サンプルを指すために互換的に使用され得る。概して、１６×１６ビデオブロックは、垂直方向に１６個のサンプルを有し（ｙ＝１６）、水平方向に１６個のサンプルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮ個のサンプルを有し、水平方向にＮ個のサンプルを有し、ここで、Ｎは非負整数値を表す。
【００６９】
[0078]さらに、ツリーブロックに対して符号化演算を実施することの一部として、予測処理ユニット１００は、ツリーブロック用の階層的な４分木データ構造を生成し得る。たとえば、ツリーブロックは、４分木データ構造のルートノードに対応し得る。予測処理ユニット１００が、ツリーブロックのビデオブロックを４つのサブブロックに区分する場合、ルートノードは、４分木データ構造中に４つの子ノードを有する。子ノードの各々は、サブブロックのうちの１つに関連付けられたＣＵに対応する。予測処理ユニット１００が、サブブロックのうちの１つを４つのサブサブブロックに区分する場合、サブブロックに関連付けられたＣＵに対応するノードは、サブサブブロックのうちの１つに関連付けられたＣＵに各々が対応する、４つの子ノードを有し得る。
【００７０】
[0079]４分木データ構造の各ノードは、対応するツリーブロックまたはＣＵのシンタックスデータ（たとえば、シンタックス要素）を含み得る。たとえば、４分木の中のノードは、そのノードに対応するＣＵのビデオブロックが４つのサブブロックに区分される（たとえば、分割される）かどうかを示すスプリットフラグを含み得る。ＣＵのためのシンタックス要素は、再帰的に定義され得、ＣＵのビデオブロックがサブブロックに分割されるかどうかに依存し得る。それのビデオブロックが区分されていないＣＵは、４分木データ構造におけるリーフノードに対応し得る。コード化されたツリーブロックは、対応するツリーブロック用の４分木データ構造に基づくデータを含み得る。
【００７１】
[0080]ビデオエンコーダ２０は、ツリーブロックの区分されていない各ＣＵに対して符号化演算を実施し得る。ビデオエンコーダ２０が、区分されていないＣＵに対して符号化演算を実施するとき、ビデオエンコーダ２０は、区分されていないＣＵの符号化された表現を表すデータを生成する。
【００７２】
[0081]ＣＵに対して符号化演算を実施することの一部として、予測処理ユニット１００は、ＣＵの１つまたは複数のＰＵの中で、ＣＵのビデオブロックを区分し得る。ビデオエンコーダ２０およびビデオデコーダ３０は、様々なＰＵサイズをサポートし得る。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズと、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、２Ｎ×ｎＵ、ｎＬ×２Ｎ、ｎＲ×２Ｎ、または同様の対称ＰＵサイズでのインター予測とをサポートし得る。ビデオエンコーダ２０およびビデオデコーダ３０は、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズに対する非対称区分をもサポートし得る。いくつかの例では、予測処理ユニット１００は、ＣＵのビデオブロックの辺（sides）に直角に接触しない境界に沿って、ＣＵのＰＵの間でＣＵのビデオブロックを区分するように、幾何学的な区分を実施し得る。
【００７３】
[0082]インター予測ユニット１２１はＣＵの各ＰＵに対してインター予測を実施し得る。インター予測は時間圧縮を実現し得る。ＰＵに対してインター予測を実施するために、動き推定ユニット１２２はＰＵの動き情報を生成し得る。動き補償ユニット１２４は、動き情報と、ＣＵに関連付けられたピクチャ以外のピクチャ（たとえば、参照ピクチャ）の復号されたサンプルとに基づくＰＵのための予測されたビデオブロックを生成し得る。本開示では、動き補償ユニット１２４によって生成された予測されたビデオブロックは、インター予測されたビデオブロックと呼ばれることがある。
【００７４】
[0083]スライスは、Ｉスライス、Ｐスライス、またはＢスライスであり得る。動き推定ユニット１２２および動き補償ユニット１２４は、ＰＵがＩスライス中にあるか、Ｐスライス中にあるか、Ｂスライス中にあるかに応じて、ＣＵのＰＵに対して異なる演算を実施し得る。Ｉスライス中では、すべてのＰＵがイントラ予測される。したがって、ＰＵがＩスライス中にある場合、動き推定ユニット１２２および動き補償ユニット１２４は、ＰＵに対してインター予測を実施しない。
【００７５】
[0084]ＰＵがＰスライス中にある場合、ＰＵを含んでいるピクチャは、「リスト０」と呼ばれる参照ピクチャのリストに関連付けられる。リスト０中の参照ピクチャの各々は、他のピクチャのインター予測に使用され得るサンプルを含んでいる。動き推定ユニット１２２が、Ｐスライス中のＰＵに関して動き推定演算を実施するとき、動き推定ユニット１２２は、ＰＵのための参照ブロックについて、リスト０中の参照ピクチャを探索し得る。ＰＵの参照ブロックは、ＰＵのビデオブロック中のサンプルに最も密接に対応するサンプルのセット、たとえば、サンプルのブロックであり得る。動き推定ユニット１２２は、参照ピクチャ中のサンプルのセットがどの程度密接にＰＵのビデオブロック中のサンプルに対応するかを決定するために様々なメトリクスを使用し得る。たとえば、動き推定ユニット１２２は、絶対差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって、参照ピクチャ中のサンプルのセットがどの程度密接にＰＵのビデオブロック中のサンプルに対応するかを決定し得る。
【００７６】
[0085]Ｐスライス中のＰＵの参照ブロックを識別した後、動き推定ユニット１２２は、参照ブロックを含んでいる、リスト０中の参照ピクチャを示す参照インデックスと、ＰＵと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。様々な例において、動き推定ユニット１２２は動きベクトルを異なる精度に生成し得る。たとえば、動き推定ユニット１２２は、１／４サンプル精度、１／８サンプル精度、または他の分数のサンプル精度で動きベクトルを生成し得る。分数のサンプル精度の場合、参照ブロック値は、参照ピクチャ中の整数位置のサンプル値から補間され得る。動き推定ユニット１２２は、ＰＵの動き情報として、参照インデックスと動きベクトルとを出力し得る。動き補償ユニット１２４は、ＰＵの動き情報によって識別された参照ブロックに基づいて、ＰＵの予測されたビデオブロックを生成し得る。
【００７７】
[0086]ＰＵがＢスライス中にある場合、ＰＵを含んでいるピクチャは、「リスト０」および「リスト１」と呼ばれる参照ピクチャの２つのリストに関連付けられ得る。いくつかの例では、Ｂスライスを含んでいるピクチャは、リスト０とリスト１の組合せである、リストの組合せに関連付けられ得る。
【００７８】
[0087]さらに、ＰＵがＢスライス中にある場合、動き推定ユニット１２２は、ＰＵについての単方向予測または双方向予測を実施し得る。動き推定ユニット１２２が、ＰＵについての単方向予測を実施するとき、動き推定ユニット１２２は、ＰＵのための参照ブロックについて、リスト０またはリスト１の参照ピクチャを探索し得る。動き推定ユニット１２２は、次いで、参照ブロックを含んでいる、リスト０またはリスト１中の参照ピクチャを示す参照インデックスと、ＰＵと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット１２２は、ＰＵの動き情報として、参照インデックスと、予測方向インジケータと、動きベクトルとを出力し得る。予測方向インジケータは、参照インデックスが、リスト０中の参照ピクチャを示すか、リスト１中の参照ピクチャを示すかを示し得る。動き補償ユニット１２４は、ＰＵの動き情報によって示された参照ブロックに基づいて、ＰＵの予測されたビデオブロックを生成し得る。
【００７９】
[0088]動き推定ユニット１２２が、ＰＵについての双方向予測を実施するとき、動き推定ユニット１２２は、ＰＵのための参照ブロックについて、リスト０中の参照ピクチャを探索し得、また、ＰＵのための別の参照ブロックについて、リスト１中の参照ピクチャを探索し得る。動き推定ユニット１２２は、次いで、参照ブロックを含んでいる、リスト０およびリスト１中の参照ピクチャを示す参照インデックスと、参照ブロックとＰＵの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット１２２は、ＰＵの動き情報としてＰＵの参照インデックスと動きベクトルとを出力し得る。動き補償ユニット１２４は、ＰＵの動き情報によって示された参照ブロックに基づいて、ＰＵの予測されたビデオブロックを生成し得る。
【００８０】
[0089]いくつかの例では、動き推定ユニット１２２は、ＰＵの動き情報のフルセットをエントロピー符号化ユニット１１６に出力しない。そうではなく、動き推定ユニット１２２は、別のＰＵの動き情報を参照して、ＰＵの動き情報をシグナリングし得る。たとえば、動き推定ユニット１２２は、ＰＵの動き情報が、隣接ＰＵの動き情報と十分に類似していると決定し得る。この例では、動き推定ユニット１２２は、ＰＵに関連付けられたシンタックス構造において、ＰＵが隣接ＰＵと同じ動き情報を有することをビデオデコーダ３０に示す値を示し得る。別の例では、動き推定ユニット１２２は、ＰＵに関連付けられたシンタックス構造において、隣接ＰＵと動きベクトル差分（ＭＶＤ：motion vector difference）とを識別し得る。動きベクトル差分は、ＰＵの動きベクトルと、示される隣接ＰＵの動きベクトルとの間の差分を示す。ビデオデコーダ３０は、ＰＵの動きベクトルを決定するために、示される隣接ＰＵの動きベクトルと、動きベクトル差分とを使用し得る。第２のＰＵの動き情報をシグナリングするときに第１のＰＵの動き情報を参照することによって、ビデオエンコーダ２０は、より少数のビットを使用して、第２のＰＵの動き情報をシグナリングすることが可能であり得る。
【００８１】
[0090]図５および図６に関して以下でさらに説明するように、予測処理ユニット１００は、図５および図６に示されている方法を実施することによってＰＵ（または任意の他の参照レイヤブロックおよび／またはエンハンスメントレイヤブロックまたはビデオユニット）をコーディング（たとえば、符号化または復号）するように構成され得る。たとえば、（たとえば、動き推定ユニット１２２および／または動き補償ユニット１２４を介した）インター予測ユニット１２１、イントラ予測ユニット１２６、またはレイヤ間予測ユニット１２８は、一緒にまたは別々に、図５および図６に示されている方法を実施するように構成され得る。
【００８２】
[0091]ＣＵに対して符号化演算を実施することの一部として、イントラ予測ユニット１２６は、ＣＵのＰＵに対してイントラ予測を実施し得る。イントラ予測は空間圧縮を実現し得る。イントラ予測ユニット１２６がＰＵに対してイントラ予測を実施するとき、イントラ予測ユニット１２６は、同じピクチャ中の他のＰＵの復号されたサンプルに基づいて、ＰＵの予測データを生成し得る。ＰＵの予測データは、予測されたビデオブロックと様々なシンタックス要素とを含み得る。イントラ予測ユニット１２６は、Ｉスライス、Ｐスライス、およびＢスライス中のＰＵに対してイントラ予測を実施し得る。
【００８３】
[0092]ＰＵに対してイントラ予測を実施するために、イントラ予測ユニット１２６は、ＰＵの予測データの複数のセットを生成するために複数のイントラ予測モードを使用し得る。イントラ予測ユニット１２６が、ＰＵの予測データのセットを生成するためにイントラ予測モードを使用するとき、イントラ予測ユニット１２６は、イントラ予測モードに関連付けられた方向および／または勾配で、隣接ＰＵのビデオブロックからＰＵのビデオブロックにわたって、サンプルを延ばし得る。隣接ＰＵは、ＰＵ、ＣＵ、およびツリーブロックについて左から右、上から下の符号化順序を仮定すると、ＰＵの上、右上、左上、または左にあり得る。イントラ予測ユニット１２６は、ＰＵのサイズに応じて、様々な数のイントラ予測モード、たとえば、３３個の方向性イントラ予測モードを使用し得る。
【００８４】
[0093]予測処理ユニット１００は、ＰＵについての、動き補償ユニット１２４によって生成された予測データ、またはＰＵについての、イントラ予測ユニット１２６によって生成された予測データの中から、ＰＵの予測データを選択し得る。いくつかの例では、予測処理ユニット１００は、予測データのセットのレート／ひずみメトリックに基づいて、ＰＵのための予測データを選択する。
【００８５】
[0094]予測処理ユニット１００が、イントラ予測ユニット１２６によって生成された予測データを選択する場合、予測処理ユニット１００は、ＰＵの予測データを生成するために使用されたイントラ予測モード、たとえば、選択されたイントラ予測モードをシグナリングし得る。予測処理ユニット１００は、選択されたイントラ予測モードを様々な方法でシグナリングし得る。たとえば、選択されたイントラ予測モードは、隣接ＰＵのイントラ予測モードと同じであることがあり得る。言い換えれば、隣接ＰＵのイントラ予測モードは現在ＰＵに対して最確モード（most probable mode）であり得る。したがって、予測処理ユニット１００は、選択されたイントラ予測モードが隣接ＰＵのイントラ予測モードと同じであることを示すための、シンタックス要素を生成し得る。
【００８６】
[0095]上記で説明したように、ビデオエンコーダ２０はレイヤ間予測ユニット１２８を含み得る。レイヤ間予測ユニット１２８は、ＳＶＣにおいて利用可能である１つまたは複数の異なるレイヤ（たとえば、ベースレイヤまたは参照レイヤ）を使用して現在のブロック（たとえば、ＥＬ中の現在のブロック）を予測するように構成される。そのような予測はレイヤ間予測と呼ばれることがある。レイヤ間予測ユニット１２８は、レイヤ間冗長性を低減するために予測方法を利用し、それによって、コーディング効率を改善し、計算リソース要件を低減する。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するためにベースレイヤ中のコロケートブロックの再構成を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動作を予測するためにベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するためにベースレイヤの残差を使用する。レイヤ間予測方式の各々は、より詳細に以下で説明される。
【００８７】
[0096]予測処理ユニット１００がＣＵのＰＵの予測データを選択した後、残差生成ユニット１０２は、ＣＵのビデオブロックからＣＵのＰＵの予測されたビデオブロックを差し引くこと（たとえば、マイナス符号によって示される）によって、ＣＵの残差データを生成し得る。ＣＵの残差データは、ＣＵのビデオブロック中のサンプルの異なるサンプル成分（sample components）に対応する、２Ｄ残差ビデオブロックを含み得る。たとえば、残差データは、ＣＵのＰＵの予測されたビデオブロック中のサンプルのルミナンス成分と、ＣＵの元のビデオブロック中のサンプルのルミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。さらに、ＣＵの残差データは、ＣＵのＰＵの予測されたビデオブロック中のサンプルのクロミナンス成分と、ＣＵの元のビデオブロック中のサンプルのクロミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。
【００８８】
[0097]予測処理ユニット１００は、ＣＵの残差ビデオブロックをサブブロックに区分するために４分木区分を実施し得る。各分割されていない残差ビデオブロックは、ＣＵの異なるＴＵに関連付けられ得る。ＣＵのＴＵに関連付けられた残差ビデオブロックのサイズおよび位置は、ＣＵのＰＵに関連付けられたビデオブロックのサイズおよび位置に基づくことも基づかないこともある。「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造は、残差ビデオブロックの各々に関連付けられたノードを含み得る。ＣＵのＴＵはＲＱＴのリーフノードに対応し得る。
【００８９】
[0098]変換処理ユニット１０４は、ＴＵに関連付けられた残差ビデオブロックに１つまたは複数の変換を適用することによって、ＣＵの各ＴＵのための１つまたは複数の変換係数ブロックを生成し得る。変換係数ブロックの各々は、変換係数の２Ｄ行列であり得る。変換処理ユニット１０４は、ＴＵに関連付けられた残差ビデオブロックに様々な変換を適用し得る。たとえば、変換処理ユニット１０４は、離散コサイン変換（ＤＣＴ）、方向性変換、または概念的に同様の変換を、ＴＵに関連付けられた残差ビデオブロックに適用し得る。
【００９０】
[0099]変換処理ユニット１０４が、ＴＵに関連付けられた変換係数ブロックを生成した後、量子化ユニット１０６は、変換係数ブロック中の変換係数を量子化し得る。量子化ユニット１０６は、ＣＵに関連付けられたＱＰ値に基づいて、ＣＵのＴＵに関連付けられた変換係数ブロックを量子化し得る。
【００９１】
[00100]ビデオエンコーダ２０は、様々な方法でＱＰ値をＣＵに関連付け得る。たとえば、ビデオエンコーダ２０は、ＣＵに関連付けられたツリーブロックに対してレートひずみ分析を実施し得る。レートひずみ分析では、ビデオエンコーダ２０は、ツリーブロックに対して符号化演算を複数回実施することによって、ツリーブロックの複数のコード化された表現を生成し得る。ビデオエンコーダ２０がツリーブロックの異なる符号化された表現を生成するとき、ビデオエンコーダ２０は、異なるＱＰ値をＣＵに関連付け得る。ビデオエンコーダ２０は、最小のビットレートおよびひずみメトリックを有するツリーブロックのコード化された表現で所与のＱＰ値がＣＵに関連付けられるとき、所与のＱＰ値がＣＵに関連付けられることをシグナリングし得る。
【００９２】
[00101]逆量子化ユニット１０８および逆変換ユニット１１０は、変換係数ブロックから残差ビデオブロックを再構成するために、それぞれ、変換係数ブロックに逆量子化と逆変換とを適用し得る。再構成ユニット１１２は、ＴＵに関連付けられた再構成されたビデオブロックを生成するために、再構成された残差ビデオブロックを、予測処理ユニット１００によって生成された１つまたは複数の予測されたビデオブロックからの対応するサンプルに追加し得る。このようにＣＵの各ＴＵのためのビデオブロックを再構成することによって、ビデオエンコーダ２０は、ＣＵのビデオブロックを再構成し得る。
【００９３】
[00102]再構成ユニット１１２がＣＵのビデオブロックを再構成した後、フィルタユニット１１３は、ＣＵに関連付けられたビデオブロックにおけるブロッキングアーティファクトを低減するためにデブロッキング演算を実施し得る。１つまたは複数のデブロッキング演算を実施した後、フィルタユニット１１３は、復号されたピクチャバッファ１１４中にＣＵの再構成されたビデオブロックを記憶し得る。動き推定ユニット１２２および動き補償ユニット１２４は、後続ピクチャのＰＵに対してインター予測を実施するために、再構成されたビデオブロックを含んでいる参照ピクチャを使用し得る。さらに、イントラ予測ユニット１２６は、ＣＵと同じピクチャの中の他のＰＵに対してイントラ予測を実施するために、復号されたピクチャバッファ１１４中の再構成されたビデオブロックを使用し得る。
【００９４】
[00103]エントロピー符号化ユニット１１６は、ビデオエンコーダ２０の他の機能構成要素からデータを受信し得る。たとえば、エントロピー符号化ユニット１１６は、量子化ユニット１０６から変換係数ブロックを受信し得、予測処理ユニット１００からシンタックス要素を受信し得る。エントロピー符号化ユニット１１６がデータを受信するとき、エントロピー符号化ユニット１１６は、エントロピー符号化されたデータを生成するために１つまたは複数のエントロピー符号化演算を実施し得る。たとえば、ビデオエンコーダ２０は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context adaptive variable length coding）演算、ＣＡＢＡＣ演算、変数間（Ｖ２Ｖ：variable-to-variable）レングスコーディング演算、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）演算、確率間隔区分エントロピー（ＰＩＰＥ）コーディング演算、または別のタイプのエントロピー符号化演算をデータに対して実施し得る。エントロピー符号化ユニット１１６は、エントロピー符号化されたデータを含むビットストリームを出力し得る。
【００９５】
[00104]データに対してエントロピー符号化演算を実施することの一部として、エントロピー符号化ユニット１１６は、コンテキストモデルを選択し得る。エントロピー符号化ユニット１１６がＣＡＢＡＣ演算を実施している場合、コンテキストモデルは、特定の値を有する特定のビンの確率の推定値を示し得る。ＣＡＢＡＣのコンテキストでは、「ビン」という用語は、シンタックス要素の２値化されたバージョンのビットを指すために使用される。
【００９６】
マルチレイヤビデオエンコーダ
[00105]図２Ｂは、本開示で説明する態様による技法を実装し得る（単にビデオエンコーダ２３とも呼ばれる）マルチレイヤビデオエンコーダ２３の一例を示すブロック図である。ビデオエンコーダ２３は、ＳＨＶＣおよびマルチビューコーディングの場合など、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオエンコーダ２３は、本開示の技法のいずれかまたはすべてを実施するように構成され得る。
【００９７】
[00106]ビデオエンコーダ２３はビデオエンコーダ２０Ａとビデオエンコーダ２０Ｂとを含み、それらの各々はビデオエンコーダ２０として構成され得、ビデオエンコーダ２０に関して上記で説明した機能を実施し得る。さらに、参照番号の再利用によって示されるように、ビデオエンコーダ２０Ａおよび２０Ｂは、ビデオエンコーダ２０としてシステムとサブシステムとのうちの少なくともいくつかを含み得る。ビデオエンコーダ２３は、２つのビデオエンコーダ２０Ａおよび２０Ｂを含むものとして示されているが、ビデオエンコーダ２３は、そのようなものとして限定されず、任意の数のビデオエンコーダ２０レイヤを含み得る。いくつかの実施形態では、ビデオエンコーダ２３はアクセスユニット中の各ピクチャまたはフレームについてビデオエンコーダ２０を含み得る。たとえば、５つのピクチャを含むアクセスユニットは、５つのエンコーダレイヤを含むビデオエンコーダによって処理または符号化され得る。いくつかの実施形態では、ビデオエンコーダ２３は、アクセスユニット中のフレームよりも多くのエンコーダレイヤを含み得る。いくつかのそのような場合では、ビデオエンコーダレイヤのいくつかは、いくつかのアクセスユニットを処理するときに非アクティブであり得る。
【００９８】
[00107]ビデオエンコーダ２０Ａおよび２０Ｂに加えて、ビデオエンコーダ２３はリサンプリングユニット９０を含み得る。リサンプリングユニット９０は、場合によっては、たとえば、エンハンスメントレイヤを作成するために、受信されたビデオフレームのベースレイヤをアップサンプリングし得る。リサンプリングユニット９０は、フレームの受信されたベースレイヤに関連付けられた特定の情報をアップサンプリングするが、他の情報をアップサンプリングしないことがある。たとえば、リサンプリングユニット９０は、ベースレイヤの空間サイズまたはピクセルの数をアップサンプリングし得るが、スライスの数またはピクチャ順序カウントは定数のままであり得る。場合によっては、リサンプリングユニット９０は、受信されたビデオを処理しないことがあるか、および／または随意であり得る。たとえば、場合によっては、予測処理ユニット１００はアップサンプリングを実施し得る。いくつかの実施形態では、リサンプリングユニット９０は、レイヤをアップサンプリングすることと、スライス境界ルールおよび／またはラスタ走査ルールのセットに準拠するために１つまたは複数のスライスを再編成、再定義、変更、または調整することとを行うように構成される。アクセスユニット中のベースレイヤまたは下位レイヤをアップサンプリングするものとして主に説明したが、場合によっては、リサンプリングユニット９０はレイヤをダウンサンプリングし得る。たとえば、ビデオのストリーミング中に帯域幅が減少した場合、フレームは、アップサンプリングされるのではなく、ダウンサンプリングされ得る。
【００９９】
[00108]リサンプリングユニット９０は、下位レイヤエンコーダ（たとえば、ビデオエンコーダ２０Ａ）の復号されたピクチャバッファ１１４からピクチャまたはフレーム（またはピクチャに関連付けられたピクチャ情報）を受信し、ピクチャ（または受信されたピクチャ情報）をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤエンコーダと同じアクセスユニット中のピクチャを符号化するように構成された上位レイヤエンコーダ（たとえば、ビデオエンコーダ２０Ｂ）の予測処理ユニット１００に与えられ得る。場合によっては、上位レイヤエンコーダは、下位レイヤエンコーダから削除された１つのレイヤである。他の場合には、図２Ｂのレイヤ０ビデオエンコーダとレイヤ１エンコーダとの間に１つまたは複数の上位レイヤエンコーダがあり得る。
【０１００】
[00109]場合によっては、リサンプリングユニット９０は省略またはバイパスされ得る。そのような場合、ビデオエンコーダ２０Ａの復号されたピクチャバッファ１１４からのピクチャは、直接、または少なくともリサンプリングユニット９０に与えられることなしに、ビデオエンコーダ２０Ｂの予測処理ユニット１００に与えられ得る。たとえば、ビデオエンコーダ２０Ｂに与えられたビデオデータと、ビデオエンコーダ２０Ａの復号されたピクチャバッファ１１４からの参照ピクチャとが同じサイズまたは解像度である場合、参照ピクチャは、リサンプリングなしにビデオエンコーダ２０Ｂに与えられ得る。
【０１０１】
[00110]いくつかの実施形態では、ビデオエンコーダ２３は、ビデオエンコーダ２０Ａにビデオデータを与える前に、ダウンサンプリングユニット９４を使用して下位レイヤエンコーダに与えられるべきビデオデータをダウンサンプリングする。代替的に、ダウンサンプリングユニット９４は、ビデオデータをアップサンプリングまたはダウンサンプリングすることが可能なリサンプリングユニット９０であり得る。また他の実施形態では、ダウンサンプリングユニット９４は省略され得る。
【０１０２】
[00111]図２Ｂに示されているように、ビデオエンコーダ２３は、マルチプレクサ９８、またはｍｕｘをさらに含み得る。ｍｕｘ９８は、ビデオエンコーダ２３から合成ビットストリームを出力することができる。合成ビットストリームは、ビデオエンコーダ２０Ａおよび２０Ｂの各々からビットストリームを取り、所与の時間において出力されるビットストリームを交替することによって作成され得る。場合によっては、２つの（または、３つ以上のビデオエンコーダレイヤの場合には、より多くの）ビットストリームからのビットが一度に１ビットずつ交替され得るが、多くの場合、ビットストリームは別様に合成され得る。たとえば、出力ビットストリームは、選択されたビットストリームを一度に１ブロックずつ交替すること（alternating）によって作成され得る。別の例では、出力ビットストリームは、ビデオエンコーダ２０Ａおよび２０Ｂの各々からブロックの非１：１比を出力することによって作成され得る。たとえば、ビデオエンコーダ２０Ａから出力された各ブロックについて、２つのブロックがビデオエンコーダ２０Ｂから出力され得る。いくつかの実施形態では、ｍｕｘ９８からの出力ストリームはプリプログラムされ得る。他の実施形態では、ｍｕｘ９８は、ソースデバイス１２を含むソースデバイス上のプロセッサからなど、ビデオエンコーダ２３の外部のシステムから受信された制御信号に基づいて、ビデオエンコーダ２０Ａ、２０Ｂからのビットストリームを合成し得る。制御信号は、ビデオソース１８からのビデオの解像度またはビットレートに基づいて、リンク１６の帯域幅に基づいて、ユーザに関連付けられたサブスクリプション（たとえば、有料サブスクリプション対無料サブスクリプション）に基づいて、またはビデオエンコーダ２３から望まれる解像度出力を決定するための他のファクタに基づいて生成され得る。
【０１０３】
ビデオデコーダ
[00112]図３Ａは、本開示で説明する態様による技法を実装し得るビデオデコーダ３０の一例を示すブロック図である。ビデオデコーダ３０は、ＨＥＶＣの場合など、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオデコーダ３０は、限定はしないが、図４および図５に関して上記および下記でより詳細に説明するＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇを推論する方法および関係するプロセスを含む、本開示の技法のいずれかまたはすべてを実施するように構成され得る。一例として、動き補償ユニット１６２および／またはイントラ予測ユニット１６４は、本開示で説明する技法のいずれかまたはすべてを実施するように構成され得る。一実施形態では、ビデオデコーダ３０は、場合によっては、本開示で説明する技法のいずれかまたはすべてを実施するように構成されたレイヤ間予測ユニット１６６を含み得る。他の実施形態では、レイヤ間予測は予測処理ユニット１５２（たとえば、動き補償ユニット１６２および／またはイントラ予測ユニット１６４）によって実施され得、その場合、レイヤ間予測ユニット１６６は省略され得る。ただし、本開示の態様はそのように限定されない。いくつかの例では、本開示で説明する技法は、ビデオデコーダ３０の様々な構成要素間で共有され得る。いくつかの例では、追加または代替として、プロセッサ（図示せず）が、本開示で説明する技法のいずれかまたはすべてを実施するように構成され得る。
【０１０４】
[00113]説明の目的で、本開示は、ＨＥＶＣコーディングのコンテキストにおいてビデオデコーダ３０を説明する。しかしながら、本開示の技法は、他のコーディング規格または方法にも適用可能であり得る。図３Ａに示された例はシングルレイヤコーデックのためのものである。しかしながら、図３Ｂに関してさらに説明するように、ビデオデコーダ３０の一部または全部はマルチレイヤコーデックの処理のために複製され得る。
【０１０５】
[00114]図３Ａの例では、ビデオデコーダ３０は複数の機能構成要素を含む。ビデオデコーダ３０の機能構成要素は、エントロピー復号ユニット１５０と、予測処理ユニット１５２と、逆量子化ユニット１５４と、逆変換ユニット１５６と、再構成ユニット１５８と、フィルタユニット１５９と、復号されたピクチャバッファ１６０とを含む。予測処理ユニット１５２は、動き補償ユニット１６２と、イントラ予測ユニット１６４と、レイヤ間予測ユニット１６６とを含む。いくつかの例では、ビデオデコーダ３０は、図２Ａのビデオエンコーダ２０に関して説明された符号化経路とは全般に逆の復号経路を実施し得る。他の例では、ビデオデコーダ３０は、より多数の、より少数の、または異なる機能構成要素を含み得る。
【０１０６】
[00115]ビデオデコーダ３０は、符号化されたビデオデータを備えるビットストリームを受信し得る。ビットストリームは複数のシンタックス要素を含み得る。ビデオデコーダ３０がビットストリームを受信したとき、エントロピー復号ユニット１５０は、ビットストリームに対してパース演算を実施し得る。ビットストリームに対してパース演算を実施した結果として、エントロピー復号ユニット１５０は、ビットストリームからシンタックス要素を抽出し得る。パース演算を実施することの一部として、エントロピー復号ユニット１５０は、ビットストリーム中のエントロピー符号化されたシンタックス要素をエントロピー復号し得る。予測処理ユニット１５２、逆量子化ユニット１５４、逆変換ユニット１５６、再構成ユニット１５８、およびフィルタユニット１５９は、ビットストリームから抽出されたシンタックス要素に基づいて、復号されたビデオデータを生成する再構成演算を実施し得る。
【０１０７】
[00116]上記で説明したように、ビットストリームは、一連のＮＡＬユニットを備え得る。ビットストリームのＮＡＬユニットは、ビデオパラメータセットＮＡＬユニット、シーケンスパラメータセットＮＡＬユニット、ピクチャパラメータセットＮＡＬユニット、ＳＥＩ  ＮＡＬユニットなどを含み得る。ビットストリームに対してパース演算を実施することの一部として、エントロピー復号ユニット１５０は、シーケンスパラメータセットＮＡＬユニットからのシーケンスパラメータセット、ピクチャパラメータセットＮＡＬユニットからのピクチャパラメータセット、ＳＥＩ  ＮＡＬユニットからのＳＥＩデータなどを抽出しエントロピー復号する、パース演算を実施し得る。
【０１０８】
[00117]さらに、ビットストリームのＮＡＬユニットはコード化されたスライスＮＡＬユニットを含み得る。ビットストリームに対してパース演算を実施することの一部として、エントロピー復号ユニット１５０は、コード化されたスライスＮＡＬユニットからコード化されたスライスを抽出しエントロピー復号する、パース演算を実施し得る。コード化されたスライスの各々は、スライスヘッダとスライスデータとを含み得る。スライスヘッダは、スライスに関するシンタックス要素を含んでいることがある。スライスヘッダ中のシンタックス要素は、スライスを含んでいるピクチャに関連付けられたピクチャパラメータセットを識別するシンタックス要素を含み得る。エントロピー復号ユニット１５０は、スライスヘッダをリカバーする（recover）ために、コード化されたスライスヘッダ中のシンタックス要素に対して、ＣＡＢＡＣ復号演算などのエントロピー復号演算を実施し得る。
【０１０９】
[00118]コード化されたスライスＮＡＬユニットからスライスデータを抽出することの一部として、エントロピー復号ユニット１５０は、スライスデータ中のコード化されたＣＵからシンタックス要素を抽出するパース演算を実施し得る。抽出されたシンタックス要素は、変換係数ブロックに関連付けられたシンタックス要素を含み得る。エントロピー復号ユニット１５０は、次いで、シンタックス要素のうちのいくつかに対してＣＡＢＡＣ復号演算を実施し得る。
【０１１０】
[00119]エントロピー復号ユニット１５０が区分されていないＣＵに対してパース演算を実施した後、ビデオデコーダ３０は、区分されていないＣＵに対して再構成演算を実施し得る。区分されていないＣＵに対して再構成演算を実施するために、ビデオデコーダ３０はＣＵの各ＴＵに対して再構成演算を実施し得る。ＣＵの各ＴＵについて再構成演算を実施することによって、ビデオデコーダ３０は、ＣＵに関連付けられた残差ビデオブロックを再構成し得る。
【０１１１】
[00120]ＴＵに対して再構成演算を実施することの一部として、逆量子化ユニット１５４は、ＴＵに関連付けられた変換係数ブロックを逆量子化（inverse quantize）、たとえば、逆量子化（de-quantize）し得る。逆量子化ユニット１５４は、ＨＥＶＣ用に提案された、またはＨ．２６４復号規格によって定義された逆量子化プロセスと同様の方式で、変換係数ブロックを逆量子化し得る。逆量子化ユニット１５４は、量子化の程度を決定し、同様に、逆量子化ユニット１５４が適用すべき逆量子化の程度を決定するために、変換係数ブロックのＣＵのためにビデオエンコーダ２０によって計算される量子化パラメータＱＰを使用し得る。
【０１１２】
[00121]逆量子化ユニット１５４が変換係数ブロックを逆量子化した後、逆変換ユニット１５６は、変換係数ブロックに関連付けられたＴＵのための残差ビデオブロックを生成し得る。逆変換ユニット１５６は、ＴＵのための残差ビデオブロックを生成するために、変換係数ブロックに逆変換を適用し得る。たとえば、逆変換ユニット１５６は、変換係数ブロックに、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ：Karhunen-Loeve transform）、逆回転変換、逆方向変換、または別の逆変換を適用し得る。いくつかの例では、逆変換ユニット１５６は、ビデオエンコーダ２０からのシグナリングに基づいて、変換係数ブロックに適用すべき逆変換を決定し得る。そのような例では、逆変換ユニット１５６は、変換係数ブロックに関連付けられたツリーブロックの４分木のルートノードにおいてシグナリングされた変換に基づいて、逆変換を決定し得る。他の例では、逆変換ユニット１５６は、ブロックサイズ、コーディングモードなど、１つまたは複数のコーディング特性から逆変換を推論し得る。いくつかの例では、逆変換ユニット１５６はカスケードされた逆変換を適用し得る。
【０１１３】
[00122]いくつかの例では、動き補償ユニット１６２は、補間フィルタに基づく補間を実施することによって、ＰＵの予測されたビデオブロックを改良し得る。サブサンプル精度をもつ動き補償のために使用されるべき補間フィルタのための識別子が、シンタックス要素中に含まれ得る。動き補償ユニット１６２は、参照ブロックのサブ整数サンプルについての補間された値を計算するために、ＰＵの予測されたビデオブロックの生成中にビデオエンコーダ２０によって使用された同じ補間フィルタを使用し得る。動き補償ユニット１６２は、受信されたシンタックス情報に従って、ビデオエンコーダ２０によって使用された補間フィルタを決定し、予測されたビデオブロックを生成するためにその補間フィルタを使用し得る。
【０１１４】
[00123]図５および図６に関して以下でさらに説明するように、予測処理ユニット１５２は、図５および図６に示されている方法を実施することによってＰＵ（または任意の他の参照レイヤブロックおよび／またはエンハンスメントレイヤブロックまたはビデオユニット）をコーディング（たとえば、符号化または復号）し得る。たとえば、動き補償ユニット１６２、イントラ予測ユニット１６４、またはレイヤ間予測ユニット１６６は、一緒にまたは別々に、図５及び図６に示されている方法を実施するように構成され得る。
【０１１５】
[00124]ＰＵが、イントラ予測を使用して符号化される場合、イントラ予測ユニット１６４は、ＰＵのための予測されたビデオブロックを生成するためにイントラ予測を実施し得る。たとえば、イントラ予測ユニット１６４は、ビットストリーム中のシンタックス要素に基づいて、ＰＵのためのイントラ予測モードを決定し得る。ビットストリームは、ＰＵのイントラ予測モードを決定するためにイントラ予測ユニット１６４が使用し得るシンタックス要素を含み得る。
【０１１６】
[00125]いくつかの事例では、シンタックス要素は、現在のＰＵのイントラ予測モードを決定するために、イントラ予測ユニット１６４が別のＰＵのイントラ予測モードを使用すべきであることを示し得る。たとえば、現在のＰＵのイントラ予測モードは隣接ＰＵのイントラ予測モードと同じであることがあり得る。言い換えれば、隣接ＰＵのイントラ予測モードは、現在のＰＵに対して最確モードであり得る。したがって、この例では、ビットストリームは、ＰＵのイントラ予測モードが隣接ＰＵのイントラ予測モードと同じであることを示す、小さいシンタックス要素を含み得る。イントラ予測ユニット１６４は、次いで、空間的に隣接するＰＵのビデオブロックに基づいて、ＰＵの予測データ（たとえば、予測されたサンプル）を生成するためにイントラ予測モードを使用し得る。
【０１１７】
[00126]上記で説明したように、ビデオデコーダ３０もレイヤ間予測ユニット１６６を含み得る。レイヤ間予測ユニット１６６は、ＳＶＣにおいて利用可能である１つまたは複数の異なるレイヤ（たとえば、ベースレイヤまたは参照レイヤ）を使用して、現在のブロック（たとえば、ＥＬ中の現在のブロック）を予測するように構成される。そのような予測はレイヤ間予測と呼ばれることがある。レイヤ間予測ユニット１６６は、レイヤ間冗長性を低減するための予測方法を利用し、それによって、コーディング効率を改善し、計算リソース要件を低減する。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するために、ベースレイヤ中のコロケートされたブロックの再構成を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動きを予測するためにベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するためにベースレイヤの残差を使用する。レイヤ間予測方式の各々は、より詳細に以下で説明される。
【０１１８】
[00127]再構成ユニット１５８は、ＣＵのビデオブロックを再構成するために、適用可能なとき、ＣＵのＴＵに関連付けられた残差ビデオブロックとＣＵのＰＵの予測されたビデオブロックとを使用し、たとえば、イントラ予測データまたはインター予測データのいずれかを使用し得る。したがって、ビデオデコーダ３０は、ビットストリーム中のシンタックス要素に基づいて、予測されたビデオブロックと残差ビデオブロックとを生成し得、予測されたビデオブロックと残差ビデオブロックとに基づいて、ビデオブロックを生成し得る。
【０１１９】
[00128]再構成ユニット１５８がＣＵのビデオブロックを再構成した後、フィルタユニット１５９は、ＣＵに関連付けられたブロッキングアーティファクトを低減するためにデブロッキング演算を実施し得る。フィルタユニット１５９が、ＣＵに関連付けられたブロッキングアーティファクトを低減するためにデブロッキング演算を実施した後、ビデオデコーダ３０はＣＵのビデオブロックを復号されたピクチャバッファ１６０中に記憶し得る。復号されたピクチャバッファ１６０は、後続の動き補償、イントラ予測、および図１Ａまたは図１Ｂのディスプレイデバイス３２などのディスプレイデバイス上での提示のために、参照ピクチャを与え得る。たとえば、ビデオデコーダ３０は、復号されたピクチャバッファ１６０中のビデオブロックに基づいて、他のＣＵのＰＵに対してイントラ予測演算またはインター予測演算を実施し得る。
【０１２０】
マルチレイヤデコーダ
[00129]図３Ｂは、本開示で説明する態様による技法を実装し得る（単にビデオデコーダ３３とも呼ばれる）マルチレイヤビデオデコーダ３３の一例を示すブロック図である。ビデオデコーダ３３は、ＳＨＶＣおよびマルチビューコーディングの場合など、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオデコーダ３３は、本開示の技法のいずれかまたはすべてを実施するように構成され得る。
【０１２１】
[00130]ビデオデコーダ３３はビデオデコーダ３０Ａとビデオデコーダ３０Ｂとを含み、それらの各々はビデオデコーダ３０として構成され得、ビデオデコーダ３０に関して上記で説明した機能を実施し得る。さらに、参照番号の再利用によって示されるように、ビデオデコーダ３０Ａおよび３０Ｂは、ビデオデコーダ３０としてシステムとサブシステムとのうちの少なくともいくつかを含み得る。ビデオデコーダ３３は、２つのビデオデコーダ３０Ａおよび３０Ｂを含むものとして示されているが、ビデオデコーダ３３は、そのようなものとして限定されず、任意の数のビデオデコーダ３０レイヤを含み得る。いくつかの実施形態では、ビデオデコーダ３３はアクセスユニット中の各ピクチャまたはフレームについてビデオデコーダ３０を含み得る。たとえば、５つのピクチャを含むアクセスユニットは、５つのデコーダレイヤを含むビデオデコーダによって処理または復号され得る。いくつかの実施形態では、ビデオデコーダ３３は、アクセスユニット中のフレームよりも多くのデコーダレイヤを含み得る。いくつかのそのような場合では、ビデオデコーダレイヤのいくつかは、いくつかのアクセスユニットを処理するときに非アクティブであり得る。
【０１２２】
[00131]ビデオデコーダ３０Ａおよび３０Ｂに加えて、ビデオデコーダ３３はアップサンプリングユニット９２を含み得る。いくつかの実施形態では、アップサンプリングユニット９２は、フレームまたはアクセスユニットのための参照ピクチャリストに追加されるべきエンハンストレイヤを作成するために、受信されたビデオフレームのベースレイヤをアップサンプリングし得る。このエンハンストレイヤは復号されたピクチャバッファ１６０中に記憶され得る。いくつかの実施形態では、アップサンプリングユニット９２は、図２Ａのリサンプリングユニット９０に関して説明した実施形態の一部または全部を含むことができる。いくつかの実施形態では、アップサンプリングユニット９２は、レイヤをアップサンプリングすることと、スライス境界ルールおよび／またはラスタ走査ルールのセットに準拠するために１つまたは複数のスライスを再編成、再定義、変更、または調整することとを行うように構成される。場合によっては、アップサンプリングユニット９２は、受信されたビデオフレームのレイヤをアップサンプリングおよび／またはダウンサンプリングするように構成されたリサンプリングユニットであり得る。
【０１２３】
[00132]アップサンプリングユニット９２は、下位レイヤデコーダ（たとえば、ビデオデコーダ３０Ａ）の復号されたピクチャバッファ１６０からピクチャまたはフレーム（またはピクチャに関連付けられたピクチャ情報）を受信し、ピクチャ（または受信されたピクチャ情報）をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤデコーダと同じアクセスユニット中のピクチャを復号するように構成された上位レイヤデコーダ（たとえば、ビデオデコーダ３０Ｂ）の予測処理ユニット１５２に与えられ得る。場合によっては、上位レイヤデコーダは、下位レイヤデコーダから削除された１つのレイヤである。他の場合には、図３Ｂのレイヤ０デコーダとレイヤ１デコーダとの間に１つまたは複数の上位レイヤデコーダがあり得る。
【０１２４】
[00133]場合によっては、アップサンプリングユニット９２は省略またはバイパスされ得る。そのような場合、ビデオデコーダ３０Ａの復号されたピクチャバッファ１６０からのピクチャは、直接、または少なくともアップサンプリングユニット９２に与えられることなしに、ビデオデコーダ３０Ｂの予測処理ユニット１５２に与えられ得る。たとえば、ビデオデコーダ３０Ｂに与えられたビデオデータと、ビデオデコーダ３０Ａの復号されたピクチャバッファ１６０からの参照ピクチャとが同じサイズまたは解像度である場合、参照ピクチャは、アップサンプリングなしにビデオデコーダ３０Ｂに与えられ得る。さらに、いくつかの実施形態では、アップサンプリングユニット９２は、ビデオデコーダ３０Ａの復号されたピクチャバッファ１６０から受信された参照ピクチャをアップサンプリングまたはダウンサンプリングするように構成されたリサンプリングユニット９０であり得る。
【０１２５】
[00134]図３Ｂに示されているように、ビデオデコーダ３３は、デマルチプレクサ９９、またはｄｅｍｕｘをさらに含み得る。ｄｅｍｕｘ９９は符号化されたビデオビットストリームを複数のビットストリームにスプリットすることができ、ｄｅｍｕｘ９９によって出力された各ビットストリームは異なるビデオデコーダ３０Ａおよび３０Ｂに与えられる。複数のビットストリームは、ビットストリームを受信することによって作成され得、ビデオデコーダ３０Ａおよび３０Ｂの各々は、所与の時間においてビットストリームの一部分を受信する。場合によっては、ｄｅｍｕｘ９９において受信されるビットストリームからのビットは、ビデオデコーダの各々（たとえば、図３Ｂの例ではビデオデコーダ３０Ａおよび３０Ｂ）の間で一度に１ビットずつ交替され得るが、多くの場合、ビットストリームは別様に分割される。たとえば、ビットストリームは、一度に１ブロックずつビットストリームを受信するビデオデコーダを交替することによって分割され得る。別の例では、ビットストリームは、ブロックの非１：１比によって、ビデオデコーダ３０Ａおよび３０Ｂの各々に分割され得る。たとえば、２つのブロックは、ビデオデコーダ３０Ａに与えられる各ブロックについてビデオデコーダ３０Ｂに与えられ得る。いくつかの実施形態では、ｄｅｍｕｘ９９によるビットストリームの分割はプリプログラムされ得る。他の実施形態では、ｄｅｍｕｘ９９は、宛先モジュール１４を含む宛先デバイス上のプロセッサからなど、ビデオデコーダ３３の外部のシステムから受信された制御信号に基づいてビットストリームを分割し得る。制御信号は、入力インターフェース２８からのビデオの解像度またはビットレートに基づいて、リンク１６の帯域幅に基づいて、ユーザに関連付けられたサブスクリプション（たとえば、有料サブスクリプション対無料サブスクリプション）に基づいて、またはビデオデコーダ３３によって取得可能な解像度を決定するための任意の他のファクタに基づいて生成され得る。
【０１２６】
イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャ
[00135]いくつかのビデオコーディング方式は様々なランダムアクセスポイントを、ビットストリームが、ビットストリームの中でそれらのランダムアクセスポイントに先行するいかなるピクチャも復号する必要なしに、それらのランダムアクセスポイントのいずれかから始めて復号され得るように、ビットストリーム全体にわたって与え得る。そのようなビデオコーディング方式では、（たとえば、ランダムアクセスポイントを与えるピクチャと同じアクセスユニット中にあるピクチャを含む）出力順序においてランダムアクセスポイントに後続するすべてのピクチャは、ランダムアクセスポイントに先行するいかなるピクチャも使用することなしに正しく復号され得る。たとえば、ビットストリームの一部分が送信の間または復号の間に失われても、デコーダは、次のランダムアクセスポイントから始めてビットストリームの復号を再開することができる。ランダムアクセスのサポートは、たとえば、動的なストリーミングサービス、シーク動作、チャネル切替えなどを容易にし得る。
【０１２７】
[00136]いくつかのコーディング方式では、そのようなランダムアクセスポイントは、ＩＲＡＰピクチャと呼ばれるピクチャによって与えられ得る。たとえば、アクセスユニット（「ａｕＡ」）中に含まれているエンハンスメントレイヤ（「ｌａｙｅｒＡ」）中の（たとえば、エンハンスメントレイヤＩＲＡＰピクチャによって与えられる）ランダムアクセスポイントは、各参照レイヤ（「ｌａｙｅｒＢ」）中にあり、復号順序においてａｕＡに先行するアクセスユニット（「ａｕＢ」）中に含まれているランダムアクセスポイント（または、ａｕＡ中に含まれているランダムアクセスポイント）を有するｌａｙｅｒＡのｌａｙｅｒＢ（たとえば、ｌａｙｅｒＡを予測するために使用されるレイヤである参照レイヤ）に関して出力順序においてａｕＢに後続する（ａｕＢ中に位置するピクチャを含む）ｌａｙｅｒＡ中のピクチャが、ａｕＢに先行するｌａｙｅｒＡ中のいかなるピクチャも復号する必要なしに正しく復号可能であるように、レイヤ特有のランダムアクセスを与え得る。
【０１２８】
[00137]ＩＲＡＰピクチャは、イントラ予測を使用してコーディングされ（たとえば、他のピクチャを参照することなしにコーディングされ）得、たとえば、瞬時復号リフレッシュ（ＩＤＲ：instantaneous decoding refresh）ピクチャと、クリーンランダムアクセス（ＣＲＡ：clean random access）ピクチャと、切断リンクアクセス（ＢＬＡ：broken link access）ピクチャとを含み得る。ビットストリーム中にＩＤＲピクチャがあるとき、復号順序においてＩＤＲピクチャに先行するすべてのピクチャは、復号順序においてＩＤＲピクチャに後続するピクチャによる予測のために使用されない。ビットストリーム中にＣＲＡピクチャがあるとき、ＣＲＡピクチャに後続するピクチャは、復号順序においてＣＲＡピクチャに先行するピクチャを予測のために使用してよく、または使用しなくてもよい。復号順序においてＣＲＡピクチャに後続するが、復号順序においてＣＲＡピクチャに先行するピクチャを使用するピクチャは、ランダムアクセススキップリーディング（ＲＡＳＬ：random access skipped leading）ピクチャと呼ばれることがある。復号順序においてＩＲＡＰピクチャに後続し、出力順序においてＩＲＡＰピクチャに先行する別のタイプのピクチャは、復号順序においてＩＲＡＰピクチャに先行するいかなるピクチャへの参照も含んでいないことがあるランダムアクセス復号可能リーディング（ＲＡＤＬ：random access decodable leading）ピクチャである。ＣＲＡピクチャに先行するピクチャが利用可能でない場合、ＲＡＳＬピクチャはデコーダによって廃棄され得る。ＢＬＡピクチャは、（たとえば、２つのビットストリームが互いにスプライスされ、ＢＬＡピクチャが復号順序において第２のビットストリームの最初のピクチャであるので）ＢＬＡピクチャに先行するピクチャがデコーダにとって利用可能でないことがあることを、デコーダに示す。ＩＲＡＰピクチャであるベースレイヤピクチャ（たとえば、０のレイヤＩＤ値を有するピクチャ）を含んでいるアクセスユニット（たとえば、複数のレイヤにわたって同じ出力時間に関連付けられたすべてのコード化されたピクチャからなるピクチャのグループ）は、ＩＲＡＰアクセスユニットと呼ばれることがある。
【０１２９】
ＩＲＡＰピクチャのクロスレイヤ整合
[00138]ＳＶＣでは、ＩＲＡＰピクチャは、異なるレイヤにわたって整合される（たとえば、同じアクセスユニットに含まれている）ことを必要とされないことがある。たとえば、ＩＲＡＰピクチャが整合されることを必要とされる場合、少なくとも１つのＩＲＡＰピクチャを含んでいるいかなるアクセスユニットもＩＲＡＰピクチャのみを含んでいることになる。一方、ＩＲＡＰピクチャが、単一のアクセスユニット中で、整合されることを必要とされない場合、（たとえば、第１のレイヤ中の）あるピクチャがＩＲＡＰピクチャであり得、（たとえば、第２のレイヤ中の）別のピクチャが非ＩＲＡＰピクチャであり得る。ビットストリーム中にそのような非整合ＩＲＡＰピクチャを有することは、いくつかの利点を与え得る。たとえば、２レイヤビットストリーム中で、エンハンスメントレイヤ中よりも多くのＩＲＡＰピクチャがベースレイヤ中にある場合、ブロードキャストおよびマルチキャストの適用例において、小さい同調遅延（low tune-in delay）および高いコーディング効率が達成され得る。
【０１３０】
[00139]いくつかのビデオコーディング方式では、ピクチャ順序カウント（ＰＯＣ：picture order count）が、復号されたピクチャが表示される相対的な順序を追跡するために使用され得る。そのようなコーディング方式のうちのいくつかにより、ＰＯＣ値は、いくつかのタイプのピクチャがビットストリーム中に出現するときはいつでもリセットされる（たとえば、０に設定されるか、またはビットストリーム中でシグナリングされた何らかの値に設定される）ことになり得る。たとえば、あるＩＲＡＰピクチャのＰＯＣ値がリセットされ得、復号順序においてそれらのＩＲＡＰピクチャに先行する他のピクチャのＰＯＣ値もリセットされることになる。ＩＲＡＰピクチャが異なるレイヤにわたって整合されることを必要とされないとき、このことが問題となり得る。たとえば、あるピクチャ（「ｐｉｃＡ」）がＩＲＡＰピクチャであり、同じアクセスユニット中の別のピクチャ（「ｐｉｃＢ」）がＩＲＡＰピクチャでないとき、ｐｉｃＡがＩＲＡＰピクチャであることに起因してリセットされる、ｐｉｃＡを含んでいるレイヤ中のピクチャ（「ｐｉｃＣ」）のＰＯＣ値は、ｐｉｃＢを含んでいるレイヤ中のリセットされないピクチャ（「ｐｉｃＤ」）のＰＯＣ値と異なることがあり得、ここで、ｐｉｃＣおよびｐｉｃＤは同じアクセスユニット中にある。このことは、それらが同じアクセスユニット（たとえば、同じ出力時間）に属していても、ｐｉｃＣおよびｐｉｃＤが異なるＰＯＣ値を有することを引き起こす。したがって、この例では、ｐｉｃＣおよびｐｉｃＤのＰＯＣ値を導出するための導出プロセスは、ＰＯＣ値およびアクセスユニットの定義と一致するＰＯＣ値を生成するように修正され得る。
【０１３１】
レイヤ初期化ピクチャ（ＬＩＰ）
[00140]いくつかのコーディング方式では、レイヤ初期化ピクチャ（「ＬＩＰピクチャ」）は、１に設定されたＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇフラグ（たとえば、１に設定される場合はＲＡＳＬピクチャが出力されないことを示し、０に設定される場合はＲＡＳＬピクチャが出力されることを示すフラグ）を有するＩＲＡＰピクチャであるピクチャ、またはベースレイヤピクチャ（たとえば、０のレイヤＩＤまたはビットストリーム中で定義される最小のレイヤＩＤを有するピクチャ）が、１に設定されたＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有する、ＩＲＡＰアクセスユニットである初期ＩＲＡＰアクセスユニットに含まれているピクチャとして定義され得る。
【０１３２】
[00141]いくつかの実施形態では、ＳＰＳは、各ＬＩＰピクチャにおいてアクティブにされ得る。たとえば、１に設定されたＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇフラグを有する各ＩＲＡＰピクチャ、または初期ＩＲＡＰアクセスユニット中に含まれている各ピクチャ、（たとえば、異なるピクチャ解像度を指定するなど）前にアクティブにされたＳＰＳとは異なり得る、新しいＳＰＳ。しかしながら、ＬＩＰピクチャがＩＲＡＰピクチャ（たとえば、初期ＩＲＡＰアクセスユニット中に含まれている任意のピクチャ）でなく、初期ＩＲＡＰアクセスユニット中のベースレイヤピクチャが、０に設定されたフラグＮｏＣｌｒａｓＯｕｔｐｕｔＦｌａｇフラグ（たとえば、１に設定される場合はクロスレイヤランダムアクセススキップピクチャが出力されないことを示し、０に設定される場合はクロスレイヤランダムアクセススキップピクチャが出力されることを示すフラグ）をもつＩＤＲピクチャである場合、ＬＩＰピクチャは新しいＳＰＳをアクティブにすることを許容されるべきでない。そのような場合、そのようなＬＩＰピクチャにおいて新しいＳＰＳがアクティブにされる場合、詳細には、新しいＳＰＳのＳＰＳ  ＲＢＳＰのコンテンツが初期ＩＲＡＰアクセスユニットの前にあらかじめアクティブであったＳＰＳのコンテンツとは異なるとき、異なるピクチャ解像度および誤り耐性（error resilience）において問題があることがある。たとえば、新しいＳＰＳは、解像度を更新し、異なるサイズのピクチャを参照するための時間予測を使用し得る。
【０１３３】
ピクチャのバンピングおよびフラッシング
[00142]復号されたピクチャは、（たとえば、それらが表示され、または他のピクチャを予測するために使用され得るように）復号されたピクチャバッファ（ＤＰＢ）中に記憶される。出力されるべきであるピクチャは、「出力のために必要とされる」とマークされ得、他のピクチャを予測するために使用されるべきであるピクチャは、「参照のために使用される」とマークされ得る。「出力のために必要とされる」とも「参照のために使用される」ともマークされない復号されたピクチャ（たとえば、最初に「参照のために使用される」または「出力のために必要とされる」とマークされたが、その後、「参照のために使用されない」または「出力のために必要とされない」とマークされたピクチャ）は、それらが復号プロセスによって削除されるまでＤＰＢ中に存在し得る。出力順序適合のデコーダでは、ピクチャをＤＰＢから削除するプロセスが、しばしば、「出力のために必要とされる」とマークされたピクチャの出力の直後にくる。出力およびその後の削除のこのプロセスは、「バンピング」と呼ばれることがある。
【０１３４】
[00143]これらのピクチャが「出力のために必要とされる」とマークされていても、デコーダがＤＰＢ中のピクチャを出力することなく削除し得る状況もある。本明細書での説明を簡単にするために、ＩＲＡＰピクチャを復号するときにＤＰＢ中に存在する復号されたピクチャは、（復号されたピクチャが「出力のために必要とされる」とマークされたのか「参照のために使用される」とマークされたのかにかかわらず）ＩＲＡＰピクチャに関連付けられた「遅れＤＰＢピクチャ（lagging DPB picture）」、またはＩＲＡＰピクチャの「関連付けられた遅れＤＰＢピクチャ」と呼ばれる。そのような状況のいくつかの例は、ＨＥＶＣのコンテキストにおいて以下で説明される。
【０１３５】
[00144]一例では、「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＣＲＡピクチャがビットストリームの中間に存在する（たとえば、ビットストリーム中の最初のピクチャでない）とき、ＣＲＡピクチャに関連付けられた遅れＤＰＢピクチャは、出力されないことになり、ＤＰＢから削除されることになる。２つのビットストリームが互いに接合され、後者のビットストリームの最初のピクチャが「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇをもつＣＲＡピクチャであるスプライスポイントにおいて、そのような状況が起こる可能性が高い。別の例では、「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するとともにＣＲＡピクチャでないＩＲＡＰピクチャｐｉｃＡ（たとえば、ＩＤＲピクチャ）がビットストリームの中間に存在し、ピクチャの解像度が（たとえば、新しいＳＰＳのアクティブ化とともに）ｐｉｃＡにおいて変化するとき、ｐｉｃＡの関連付けられた遅れＤＰＢピクチャは、関連付けられた遅れＤＰＢピクチャがＤＰＢを占有し続ける場合、ｐｉｃＡから始まるピクチャの復号が、たとえば、バッファオーバーフローに起因して問題となり得るので、それらが出力され得る前にＤＰＢから削除され得る。この場合、ｐｉｃＡに関連付けられたｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇ（たとえば、１に設定される場合は前に復号されＤＰＢ中に記憶されたピクチャが出力されることなくＤＰＢから削除されるべきであることを示し、０に設定される場合は前に復号されＤＰＢ中に記憶されたピクチャが出力されることなくＤＰＢから削除されるべきでないことを示すフラグ）の値は、エンコーダまたはスプライサによって「１」の値に等しく設定されるべきであり、または、ＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇ（たとえば、ビットストリーム中に含まれる情報に基づいて決定され得る導出値）は、遅れピクチャをＤＰＢの外へ出力することなくフラッシングするように、デコーダによって「１」の値に等しいものとして導出され得る。スプライシング動作は、図４に関して以下でさらに説明される。
【０１３６】
[00145]関連付けられた遅れＤＰＢピクチャを出力することなくＤＰＢから削除するこのプロセスは、「フラッシング」と呼ばれることがある。上述されない状況においても、デコーダがＩＲＡＰピクチャの関連付けられたＤＰＢ遅れピクチャをフラッシングするように、ＩＲＡＰピクチャは、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇの値を「１」の値に等しく指定し得る。
【０１３７】
スプライスポイントを含むビットストリーム
[00146]図４を参照しながら、スプライスポイントを有する例示的なビットストリームが説明される。図４は、スプライシングビットストリーム４１０および４２０によって作り出されたマルチレイヤビットストリーム４００を示す。ビットストリーム４１０は、エンハンスメントレイヤ（ＥＬ）４１０Ａとベースレイヤ（ＢＬ）４１０Ｂとを含み、ビットストリーム４２０は、ＥＬ４２０ＡとＢＬ４２０Ｂとを含む。ＥＬ４１０ＡはＥＬピクチャ４１２Ａを含み、ＢＬ４１０ＢはＢＬピクチャ４１２Ｂを含む。ＥＬ４２０Ａは、ＥＬピクチャ４２２Ａ、４２４Ａ、および４２６Ａを含み、ＢＬ４２０Ｂは、ＢＬピクチャ４２２Ｂ、４２４Ｂ、および４２６Ｂを含む。マルチレイヤビットストリーム４００は、アクセスユニット（ＡＵ）４３０〜４６０をさらに含む。ＡＵ４３０は、ＥＬピクチャ４１２ＡとＢＬピクチャ４１２Ｂとを含み、ＡＵ４４０は、ＥＬピクチャ４２２ＡとＢＬピクチャ４２２Ｂとを含み、ＡＵ４５０は、ＥＬピクチャ４２４ＡとＢＬピクチャ４２４Ｂとを含み、ＡＵ４６０は、ＥＬピクチャ４２６ＡとＢＬピクチャ４２６Ｂとを含む。図４の例では、ＢＬピクチャ４２２ＢはＩＲＡＰピクチャであり、ＡＵ４４０の中の対応するＥＬピクチャ４２２Ａは、末尾のピクチャ（たとえば、非ＩＲＡＰピクチャ）であり、したがって、ＡＵ４４０は非整合ＩＲＡＰ  ＡＵである。また、ＡＵ４４０がスプライスポイント４７０の直後にくるアクセスユニットであることに留意されたい。
【０１３８】
[00147]図４の例は２つの異なるビットストリームが互いに接合される場合を示すが、いくつかの実施形態では、ビットストリームの一部分が削除されるとき、スプライスポイントが存在し得る。たとえば、ビットストリームは部分Ａ、Ｂ、およびＣを有し得、部分Ｂは部分ＡとＣとの間にある。部分Ｂがビットストリームから削除される場合、残りの部分ＡおよびＣは互いに接合され得、それらが互いに接合される点はスプライスポイントと呼ばれることがある。より一般に、本出願で説明されるようなスプライスポイントは、１つまたは複数のシグナリングまたは導出されたパラメータまたはフラグが所定の値を有するとき、存在すると見なされ得る。たとえば、スプライスポイントが特定のロケーションにおいて存在するという特定の指示を受信しなければ、デコーダは、フラグ（たとえば、ＮｏＣｌｒａｓＯｕｔｐｕｔＦｌａｇ）の値を決定し、フラグの値に基づいて本出願で説明する１つまたは複数の技法を実施し得る。
【０１３９】
マルチレイヤコンテキストにおけるピクチャのフラッシング
[00148]ピクチャをフラッシングするプロセスは、マルチレイヤビットストリームにおいても関連する。より具体的には、それは初期ＩＲＡＰアクセスユニットに属するすべてのピクチャと関連し、初期ＩＲＡＰアクセスユニット中にないＩＲＡＰピクチャとも関連する。上記で説明したように、ＳＨＶＣおよびＭＶ−ＨＥＶＣなどのいくつかの既存の実装形態では、ＩＲＡＰアクセスユニットは、（アクセスユニット中の他のピクチャがＩＲＡＰピクチャであるかどうかにかかわらず）「０」の値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＩＲＡＰピクチャを含んでいるアクセスユニットとして定義され得、初期ＩＲＡＰアクセスユニットは、（この場合も、アクセスユニット中の他のピクチャがＩＲＡＰピクチャであるかどうかにかかわらず）「０」の値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有し「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャを含んでいるアクセスユニットとして定義され得る。
【０１４０】
[00149]ＳＨＶＣおよびＭＶ−ＨＥＶＣにおいて、非整合ＩＲＡＰピクチャをアクセスユニット中に有する可能性がある（たとえば、アクセスユニットはＩＲＡＰピクチャと非ＩＲＡＰピクチャの両方を含み得る）場合、ＨＥＶＣのコンテキストにおいて前のセクションで説明した状況は、ＳＨＶＣ／ＭＶ−ＨＥＶＣビットストリームの異なるレイヤにおいて起こり得る。たとえば、「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＣＲＡピクチャｐｉｃＡは、エンハンスメントレイヤにおいてｐｉｃＡと同じレイヤ中にＣＲＡピクチャを有しない初期ＩＲＡＰアクセスユニットを用いて開始するビットストリームの中間に（たとえば、ビットストリームの第１のアクセスユニット中でない）存在し得る。また、ピクチャの解像度変化は、ベースレイヤの解像度が変化しない場合、アクセスユニットにおけるエンハンスメントレイヤ中でＩＲＡＰピクチャにおいて発生し得、またはその逆も同様である。類似の状況が、異なるＤＰＢサイズに対して起こり得る。
【０１４１】
ＳＶＣおよびＭＶＣにおけるピクチャのフラッシング
[00150]ＳＶＣの単一ループコーディング設計に起因して、いわゆる中粒度スケーラビリティ（ＭＧＳ：medium-granular scalability）が使用される場合を除いて、アクセスユニットごとに１つの再構成ピクチャのみがＤＰＢ中に挿入される（その場合、ＤＰＢ中に記憶されるいわゆるキーピクチャアクセスユニットからの２つの復号されたピクチャがあり得る）。しかしながら、各アクセスユニット中で、最上位レイヤの復号されたピクチャのみが出力され得る。ピクチャのフラッシングを含む、ＤＰＢを管理するための動作は、したがって、主に、ベースレイヤの復号されたピクチャはエンハンスメントレイヤを予測するためにＤＰＢ中に存在することが必要とされないので、最上位レイヤ中のピクチャのみに関係する。
【０１４２】
[00151]ＭＶＣでは、２つ以上のビューがターゲット出力ビューであり得、復号されたビューコンポーネントは、それらが同じレイヤ中のビューコンポーネントを予測するために必要とされなくても、他のレイヤ中のビューコンポーネントを予測するために維持される必要がある。したがって、２つ以上のビューからのビューコンポーネントがＤＰＢ中に存在し得る。フラグｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが、各ＩＤＲビューコンポーネントについてシグナリングされ（たとえば、非ベースビューのＩＤＲビューコンポーネントが「０」の値に等しいｎｏｎ＿ｉｄｒ＿ｆｌａｇを用いてシグナリングされる）、ビューコンポーネントのフラッシングはレイヤ特有（またはビュー特有）である。ＭＶＣでは、簡単のために、ＭＶＣにおけるアクセスユニット中のＩＤＲビューコンポーネントは整合される。たとえば、アクセスユニット中のあるビューコンポーネントがＩＤＲビューコンポーネントである場合、そのアクセスユニット中のすべてのビューコンポーネントもＩＤＲビューコンポーネントである。したがって、フラッシング動作はまた、動作がビュー／レイヤ特有であり得ても、ビットストリーム中のすべてのビューにわたって実施される。
【０１４３】
ＳＨＶＣおよびＭＶ−ＨＥＶＣにおけるピクチャのフラッシング
[00152]フラッシングがＳＨＶＣおよびＭＶ−ＨＥＶＣにおける現在の設計のもとで発生すると、ＤＰＢ中のすべてのピクチャは出力（たとえば、表示）されることなく削除される。（ベースレイヤのみがビットストリーム中に存在する自明な場合を除いて）ビットストリーム中の１つのレイヤのみのピクチャがフラッシングされることは可能でなく、したがって、フラッシングはレイヤ特有でない。
【０１４４】
出力タイミング適合
[00153]ＳＨＶＣワーキングドラフト（ＷＤ）５およびＭＶ−ＨＥＶＣワーキングドラフト７など、いくつかの実装形態（たとえば、ＳＨＶＣ、ＭＶ−ＨＥＶＣなど）では、出力タイミング適合に関して、ＤＰＢからのピクチャの出力および削除は、以下で説明するように実施される。
【表１−１】
0006622211.tif 000002
【表１−２】
0006622211.tif 000003
【０１４５】
出力順序適合
[00154]いくつかの実装形態（たとえば、ＳＨＶＣ、ＭＶ−ＨＥＶＣなど）では、出力順序適合に関して、ＤＰＢからのピクチャの出力および削除は、以下で説明するように実施される。
【表２−１】
0006622211.tif 000004
【表２−２】
0006622211.tif 000005
【表２−３】
0006622211.tif 000006
【０１４６】
出力タイミング適合および出力順序適合の比較
[00155]上記で説明したように、出力タイミング適合および出力順序適合は、ともに同じフラッシングの挙動をもたらさないことがある。たとえば、出力タイミング適合デコーダに関して、フラッシングは、ビットストリーム中のレイヤの最初のピクチャでなく「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有する、レイヤ中の各ピクチャに対して呼び出される。フラッシングが呼び出されると、ＤＰＢ中のそのレイヤのすべての復号されたピクチャがフラッシングされる。一方、出力順序適合デコーダに関して、フラッシングは、ビットストリーム中の最初のピクチャでなく「１」の値に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有する、ベースレイヤ中のピクチャのみに対して呼び出される。フラッシングが呼び出されると、ＤＰＢ中のすべてのレイヤのすべての復号されたピクチャがフラッシングされる。
【０１４７】
[00156]２つのレイヤを有するビットストリームでは、ＩＲＡＰピクチャでありＩＲＡＰ  ＡＵに属さない、ＥＬ中のＬＩＰピクチャが異なる解像度をアクティブにし、ＢＬピクチャが非ＩＲＡＰ  ＡＵ中にある（たとえば、ＩＲＡＰピクチャでない）ことに起因してＢＬの解像度がこのＡＵにおいて変化することができないとき、ピクチャのレイヤ特有のフラッシングが望まれることがある。ここで、ＥＬからのピクチャのみがフラッシングされるべきであり、ＢＬからのピクチャはフラッシングされるべきでない。この特徴は、出力順序適合に対して利用可能でない。
【０１４８】
[00157]２つのレイヤを有するビットストリームでは、アクセスユニットが、ＩＤＲピクチャであるＢＬピクチャと、非ＩＲＡＰピクチャであるＥＬピクチャとを含む場合、ＢＬピクチャの解像度はそのアクセスユニットにおいて更新され得るが、ＥＬピクチャの解像度は更新されない。そのような場合、フラッシングはＢＬからのピクチャのみに対して実施されるべきであり、ＥＬピクチャはフラッシングされるべきでない。この特徴は、出力順序適合に対して利用可能でない。
【０１４９】
前のピクチャの出力を示すフラグのシグナリング
[00158]いくつかの実施形態では、変数ＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇ（たとえば、ＩＲＡＰピクチャを復号するとき、ＤＰＢがフラッシングされる前にＤＰＢ中のピクチャを出力すべきか否かを決定するためにデコーダによって導出される値）は、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇおよび他の条件に基づいて導出される。たとえば、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇは、ビットストリーム中でシグナリングされる値であり得、ＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇは、ビットストリーム中に含まれる情報に基づいてエンコーダによって導出される値であり得る。デコーダは、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇの値および他の条件に基づいてＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇの値を導出し、次いで、ピクチャを出力すべきか否かを決定するためにＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇの導出された値を使用し得る。いくつかの実施形態では、フラグＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇは、現在のアクセスユニットが、２つの異なるビットストリームが互いに縫合される（stitched）スプライスポイントを備えるかどうかを示し得る。
【０１５０】
[00159]いくつかの実施形態では、ＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇおよびＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇは、ビットストリーム中に含まれる情報に基づいて導出される変数であり得る。たとえば、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇは、（たとえば、ＢＬおよび／またはＥＬ中の）あらゆるＩＲＡＰピクチャに対して導出され得、ＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇは、最下位レイヤピクチャ（たとえば、ＢＬピクチャ）のみに対して導出され得る。ＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇおよびＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの各々の値は、ビットストリーム中のいくつかのピクチャが、いくつかの参照ピクチャの非利用可能性に起因して正しく復号可能でないことがあることを示し得る。参照ピクチャのそのような非利用可能性は、ランダムアクセスポイントにおいて発生し得る。クロスレイヤランダムアクセススキップ（ＣＬ−ＲＡＳ）ピクチャは、いくつかの点で、ＲＡＳＬピクチャのマルチレイヤ等価物である。デコーダがランダムアクセスポイント（たとえば、ＢＬ  ＩＲＡＰピクチャを有するアクセスユニット）においてビットストリームを復号することを開始し、アクセスユニット中のＥＬピクチャがＩＲＡＰピクチャでない場合、そのＥＬピクチャはＣＬ−ＲＡＳピクチャである。ＥＬ中のすべてのピクチャは、ＩＲＡＰピクチャがＥＬ中に発生するまで（たとえば、復号可能であるが、正しく復号可能ではない）ＣＬ−ＲＡＳピクチャであり得る。そのようなＥＬ  ＩＲＡＰピクチャがビットストリーム中で与えられるとき、ＥＬは初期化されたと言われることがある。
【０１５１】
[00160]たとえば、図４の例では、ＥＬピクチャ４２２ＡはＩＲＡＰピクチャでないＬＩＰピクチャであり得、ＢＬピクチャ４２２Ｂはそれに関連付けられたフラグＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャであり得る。この例では、ＥＬピクチャ４２２Ａに関連付けられたＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇの値は、ＢＬピクチャ４２２Ｂに関連付けられたＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇの値に基づいて推論され得る。たとえば、ＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇが「１」の値に等しい場合、ＥＬピクチャ４２２ＡのためのＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇはまた、「１」の値に設定され得、ＤＰＢ中のピクチャは、それらがＤＰＢから削除される前に出力されないことになる。一方、ＮｏＣｌＲａｓＯｕｔｐｕｔＦｌａｇが「０」の値に等しい場合、ＥＬピクチャ４２２ＡのためのＮｏＯｕｔｐｕｔＯｆＰｒｉｏｒＰｉｃｓＦｌａｇはまた、「０」の値に設定され得、ＤＰＢ中のピクチャは、出力の後にＤＰＢから削除されることになる。
【０１５２】
マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報およびシーケンス終了（ＥＯＳ）ＮＡＬユニット情報の導出
[00161]マルチレイヤビットストリームでは、レイヤは１つまたは複数の時間サブレイヤを含むことができる。各時間サブレイヤは、時間ＩＤと呼ばれる、それに関連付けられた識別子（ＩＤ）を有することができる。たとえば、マルチレイヤビットストリーム中のベースレイヤが２つの時間サブレイヤを有する場合、第１の時間サブレイヤのための時間ＩＤは０であり、第２の時間サブレイヤのための時間ＩＤは１である。概して、現在のピクチャよりも高い時間ＩＤを有するピクチャは現在のピクチャのための参照ピクチャとして使用されない。フラグｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇは、現在のピクチャの時間ＩＤに等しいかまたは現在のピクチャの時間ＩＤよりも低い時間ＩＤを有する特定のピクチャが、特定のピクチャよりも低い時間ＩＤを有し、復号順序において特定のピクチャに後続するが、復号順序において現在のピクチャに先行する、別のピクチャが存在するとき、参照ピクチャとして使用され得るかどうかをさらに示すことができる。たとえば、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇが有効にされた（たとえば、１に等しく設定された）とき、ピクチャＡが、現在のピクチャよりも低いかまたは現在のピクチャに等しい時間ＩＤを有するが、ピクチャＢが、ピクチャＡよりも低い時間ＩＤを有し、復号順序においてピクチャＡと現在のピクチャとの間にある（たとえば、ピクチャＡのＰＯＣ値と現在のピクチャのＰＯＣ値との間のＰＯＣ値）場合、ピクチャＡは現在のピクチャのための参照ピクチャとして使用されないことがある。一方、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇが有効にされない（たとえば、０に等しく設定された）とき、ピクチャＡが、現在のピクチャよりも低いかまたは現在のピクチャに等しい時間ＩＤを有するが、ピクチャＢが、ピクチャＡよりも低い時間ＩＤを有し、復号順序においてピクチャＡと現在のピクチャとの間にある（たとえば、ピクチャＡのＰＯＣ値と現在のピクチャのＰＯＣ値との間のＰＯＣ値）場合、ピクチャＡは現在のピクチャのための参照ピクチャとして使用され得る。
【０１５３】
[00162]ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョン（たとえば、ＳＨＶＣのワーキングドラフト５およびＭＶ−ＨＥＶＣのワーキングドラフト７）は、ビットストリーム中にシンタックス要素が存在しないとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの導出において矛盾を生じる。いくつかの条件下では、フラグの値が、０または１のいずれかであると決定されないことがある。これらおよび他のチャレンジに対処するために、いくつかの態様による技法は、矛盾をなくすために、そのような条件の下でｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値をどのように導出するかを定義する（たとえば、導出プロセスにおいて優先順位を設定する）ことができる。
【０１５４】
[00163]さらに、ＨＥＶＣでは、１つのＡＵはただ１つのレイヤからのピクチャを含んでおり、しばしば、ピクチャの概念とＡＵの概念とは互換的に使用され得る。対照的に、ＳＨＶＣおよびＭＶ−ＨＥＶＣでは、１つのＡＵは２つ以上のレイヤからのピクチャを含んでいることがあり、これは、変数またはフラグが、特定のレイヤ（たとえば、ベースレイヤ）に関連付けられるべきなのか、ＡＵ全体に適用されるべきなのかを不確定にすることがある。そのような変数の一例はＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇである。変数ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは、ＣＲＡピクチャをＢＬＡピクチャとして処理すべきかどうかを示すことができる。たとえば、ビットストリームがＣＲＡにおいてランダムにアクセスまたはスプライスされたとき、たとえば、ＣＲＡに後続する任意のＲＡＳＬピクチャを削除するために、ＣＲＡはＢＬＡに変換されることになる。ＣＲＡをＢＬＡとして扱うプロセスを可能にするために、たとえば、外部手段を介して、変数が導入され得る。デコーダまたはスプライサは、ＣＲＡのスライスヘッダを変更することを必要とすることがある、ＣＲＡをＢＬＡに実際に変換することの代わりに、変数の値に基づいて、ＣＲＡをＢＬＡとして容易に処理することができる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンは、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇが、ベースレイヤのみに関連付けられるのか、ＡＵに関連付けられるのかを不明瞭にする。これらおよび他のチャレンジに対処するために、いくつかの態様による技法はまた、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇが、ベースレイヤのみに関連付けられるべきなのか、ＡＵに関連付けられるべきなのかを定義することができる。
【０１５５】
[00164]その上、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇに関して上記で説明したように、ＳＨＶＣおよびＭＶ−ＨＥＶＣでは、１つのＡＵが２つ以上のレイヤからのピクチャを有することができるので、ＥＯＳ  ＮＡＬユニットが、特定のレイヤ（たとえば、ベースレイヤ）に関連付けられるべきなのか、ＡＵ全体に適用されるべきなのかは不確定であり得る。ＥＯＳ  ＮＡＬユニットは、コード化されたビデオシーケンス（ＣＶＳ）の終了を示すことができ、概して、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャなど、ＩＲＡＰピクチャが後続する。ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンは、ＥＯＳ  ＮＡＬユニットが、ベースレイヤのみに関連付けられるのか、ＡＵに関連付けられるのかを明瞭にしない。これらおよび他のチャレンジに対処するために、いくつかの態様による技法は、ＥＯＳ  ＮＡＬユニットがベースレイヤのみに関連付けられるべきなのか、ＡＵに関連付けられるべきなのかを定義することができる。
【０１５６】
[00165]マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報およびＥＯＳ  ＮＡＬユニット情報の導出、ならびにＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの導出に関係するいくつかの詳細が以下でさらに説明される。本開示全体にわたって使用される様々な用語は、それらの通常の意味を有する広義の用語である。さらに、いくつかの実施形態では、いくつかの用語は以下のビデオ概念に関係する。外部手段は、エンコーダまたはデコーダの一部ではないが、たとえば、アプリケーションプログラミングインターフェース（ＡＰＩ）を通して、エンコーダまたはデコーダと対話する、任意の装置またはエンティティを指すことがある。いくつかの実施形態では、外部手段は外部装置と呼ばれることもある。
【０１５７】
マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出
[00166]ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンでは、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇのセマンティクスは以下のように指定され得る。
【表３】
0006622211.tif 000007
【０１５８】
[00167]ＳＨＶＣおよびＭＶ−ＨＥＶＣの早期バージョンでは、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇが１に等しいとき、以下が適用され得る。
・  ｔＩｄＡを現在のピクチャｐｉｃＡのＴｅｍｐｏｒａｌＩｄの値とする。
・  復号順序においてピクチャｐｉｃＢに後続し、復号順序においてピクチャｐｉｃＡに先行する、ｔＩｄＢよりも小さいＴｅｍｐｏｒａｌＩｄを有するピクチャｐｉｃＣが存在するとき、ｔＩｄＡよりも小さいかまたはｔＩｄＡに等しいｔＩｄＢに等しいＴｅｍｐｏｒａｌＩｄをもつ任意のｐｉｃＢは、ｐｉｃＡのＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、またはＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒ中に含まれないものとする。
【０１５９】
[00168]シンタックス要素が存在しないかまたは示されないとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの推論に関する問題があり得る。条件および／または制約のいくつかは以下の通りであり得る。１）存在しないとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇはｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇに等しいと推論され、２）ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０に等しいとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇは１に等しい。
【０１６０】
[00169]ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇが存在せず、ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値とｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１の値が両方とも０に等しいとき、矛盾が発生し得る。そのような場合、上述の条件の両方が同時に満たされず、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値が、０に等しいと推論されるべきなのか、１に等しいと推論されるべきなのかが明瞭でないことがある。
【０１６１】
例示的な実施形態１
[00170]矛盾に対処するために、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇのセマンティクスは以下のように変更され得る。本開示における例示的な実施形態は、ＳＨＶＣおよびＭＶ−ＨＥＶＣ（たとえば、ＳＨＶＣ  ＷＤ５およびＭＶ−ＨＥＶＣ  ＷＤ７）の以前のバージョンのコンテキストにおいて与えられる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンへの追加はイタリック体で示され、ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンからの削除は取消し線で示されている。
【表４】
0006622211.tif 000008
【０１６２】
[00171]いくつかの実施形態によれば、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの推論において使用されるシンタックス要素および変数は、以下を指すことがある。
・  シンタックス要素または変数ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇはｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇと同様であり得、ＶＰＳに関連付けられる。
−  たとえば、ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇは、現在のピクチャの時間ＩＤに等しいかまたは現在のピクチャの時間ＩＤよりも低い時間ＩＤを有する特定のピクチャが、特定のピクチャよりも低い時間ＩＤを有し、復号順序において特定のピクチャに後続するが、復号順序において現在のピクチャに先行する、別のピクチャが存在するとき、参照ピクチャとして使用され得るかどうかをＶＰＳレベルで示すことができる。
−  ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇは、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇよりも低い優先順位を有し得る。特定のレイヤについてｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇとｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの両方が存在する場合、ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値ではなく、そのレイヤのためのｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値が使用される。
・  シンタックス要素または変数ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１は、特定のレイヤ中の時間サブレイヤの最大数−１を指す。
−  たとえば、レイヤ中に１つの時間サブレイヤのみがある場合、レイヤ中の時間サブレイヤの最大数は１であり、したがって、ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１の値は０である。別の例では、レイヤ中に２つの時間サブレイヤがある場合、レイヤ中の時間サブレイヤの最大数は２であり、したがって、ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１の値は１である。
【０１６３】
[00172]この実施形態では、シンタックス要素ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇがビットストリーム中に存在しないとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値は、ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１の値を検査することによって推論され得る。ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０よりも大きい場合、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値はｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値に等しく設定される。ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０よりも小さいかまたは０に等しい場合、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値は１に等しく設定される。例示的な実施形態１は、上記の条件および／または制約１）および２）うちのいずれが最初に適用されるべきかについて優先順位を設定する。例示的な実施形態１は、ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０よりも大きいとき、この場合、レイヤが２つ以上の時間サブレイヤを有するので、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値をどのように推論するかを最初に定義することができる。ｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０よりも小さいかまたは０に等しいとき、レイヤは２つ以上の時間サブレイヤを有し、したがって、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値はそれほど重要でないことがある。
【０１６４】
[00173]このようにして、本技法は、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇがビットストリーム中に存在せず、ｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの値とｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１の値が両方とも０に等しいとき、ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇの導出における矛盾をなくすことができる。
【０１６５】
マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出の方法
[00174]図５は、本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャートである。本方法は、マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出に関する。プロセス５００は、実施形態によっては、エンコーダ（たとえば、図２Ａ、図２Ｂなどに示されているエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂなどに示されているデコーダ）、または任意の他の構成要素によって実施され得る。プロセス５００のブロックは図３Ｂ中のデコーダ３３に関して説明されるが、プロセス５００は、上述のように、エンコーダなど、他の構成要素によって実施され得る。デコーダ３３のレイヤ１ビデオデコーダ３０Ｂおよび／またはデコーダ３３のレイヤ０デコーダ３０Ａが、実施形態によっては、プロセス５００を実施し得る。図５に関して説明するすべての実施形態は、別々に、または互いと組み合わせて実装され得る。プロセス５００に関係するいくつかの詳細が、たとえば、図４に関して上記で説明されている。
【０１６６】
[00175]プロセス５００はブロック５０１において開始する。デコーダ３３は、複数のレイヤに関連付けられたビデオ情報を記憶するためのメモリを含むことができる。
【０１６７】
[00176]ブロック５０２において、デコーダ３３は、第１のシンタックス要素がビットストリーム中に存在するかどうかを決定する。第１のシンタックス要素は、ＳＰＳと、ＳＰＳを参照するピクチャのための参照ピクチャの時間ＩＤがネスティングされ得るかどうかを示す第１のフラグとに関連付けられ得る。一実施形態では、第１のフラグは、ＳＰＳを参照する現在のＡＵ中の現在のピクチャが第１のピクチャを参照ピクチャとして使用することができるかどうかを示し、ここにおいて、第２のピクチャが第１のピクチャの時間ＩＤよりも低い時間ＩＤを有し、復号順序において第１のピクチャに後続するが、現在のピクチャに先行するとき、第１のピクチャは、現在のピクチャの時間ＩＤよりも低いかまたは現在のピクチャの時間ＩＤに等しい時間ＩＤを有し、復号順序において現在のピクチャに先行する。いくつかの実施形態では、第１のフラグはｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇを含む。第１のフラグの値が１に等しく設定されたとき、第１のピクチャは参照ピクチャとして使用されないことがある。第１のシンタックス要素はｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇを含むことができる。
【０１６８】
[00177]ブロック５０３において、第１のシンタックス要素がビットストリーム中に存在しない場合、デコーダ３３は、複数のレイヤのうちの特定のレイヤ中の時間サブレイヤの最大数を示す第２のシンタックス要素を取得する。第２のシンタックス要素はｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１を含むことができる。
【０１６９】
[00178]ブロック５０４において、第１のシンタックス要素がビットストリーム中に存在しない場合、デコーダ３３は、第１のフラグの値を第２のフラグの値に等しく設定すべきかどうかを決定し、第２のフラグは、第２のシンタックス要素の値に少なくとも部分的に基づいて、任意のピクチャのための参照ピクチャの時間ＩＤがネスティングされ得るかどうかを示す。一実施形態では、第２のフラグは、現在のＡＵ中の現在のピクチャが第３のピクチャを参照ピクチャとして使用することができるかどうかを示し、ここにおいて、第４のピクチャが第３のピクチャの時間ＩＤよりも低い時間ＩＤを有し、復号順序において第３のピクチャに後続するが、現在のピクチャに先行するとき、第３のピクチャは、現在のピクチャの時間ＩＤよりも低いかまたは現在のピクチャの時間ＩＤに等しい時間ＩＤを有し、復号順序において現在のピクチャに先行する。いくつかの実施形態では、第２のフラグはｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇを含む。
【０１７０】
[00179]デコーダ３３は、第２のシンタックス要素の値が０よりも大きいことに応答して、第１のフラグの値を第２のフラグの値に等しく設定し得、第２のフラグはビットストリーム中のＶＰＳに関連付けられる。デコーダ３３は、第２のシンタックス要素の値が０よりも小さいかまたは０に等しいことに応答して、第１のフラグの値を１に等しく設定し得る。
【０１７１】
[00180]プロセス５００はブロック５０５において終了する。ブロックは、実施形態によっては、プロセス５００において追加および／または省略され得、プロセス５００のブロックは、実施形態によっては、異なる順序で実施され得る。プロセス５００に関係するいくつかの詳細は以下で図５Ａに関して説明される。
【０１７２】
[00181]本開示におけるマルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出に関して説明したいかなる特徴および／または実施形態も、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図１〜図４に関して説明したいかなる特徴および／または実施形態、ならびに本開示の他の部分も、図５に関して説明した任意の特徴および／または実施形態との任意の組合せで実装され得、その逆も同様である。
【０１７３】
[00182]図５Ａは、本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャートである。本方法は、マルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出に関する。プロセス５００Ａは、実施形態によっては、エンコーダ（たとえば、図２Ａ、図２Ｂなどに示されているエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂなどに示されているデコーダ）、または任意の他の構成要素によって実施され得る。プロセス５００Ａのブロックは図３Ｂ中のデコーダ３３に関して説明されるが、プロセス５００Ａは、上述のように、エンコーダなど、他の構成要素によって実施され得る。デコーダ３３のレイヤ１ビデオデコーダ３０Ｂおよび／またはデコーダ３３のレイヤ０デコーダ３０Ａが、実施形態によっては、プロセス５００Ａを実施し得る。図５Ａに関して説明するすべての実施形態は、別々に、または互いと組み合わせて実装され得る。プロセス５００Ａに関係するいくつかの詳細が、たとえば、図４および図５に関して上記で説明されている。
【０１７４】
[00183]プロセス５００Ａはブロック５０１Ａにおいて開始する。デコーダ３３は、複数のレイヤに関連付けられたビデオ情報を記憶するためのメモリを含むことができる。
【０１７５】
[00184]ブロック５０２Ａにおいて、デコーダ３３は、第１のフラグに関連付けられた第１のシンタックス要素がビットストリーム中に存在するかどうかを決定する。第１のフラグは、参照ピクチャの時間ＩＤがネスティングされ得るかどうかを示すことができ、ビットストリーム中のＳＰＳに関連付けられ得る。第１のフラグは、現在のＡＵ中の現在のピクチャが第１のピクチャを参照ピクチャとして使用することができるかどうかを示し得、ここで、第２のピクチャが第１のピクチャの時間ＩＤよりも低い時間ＩＤを有し、復号順序において第１のピクチャに後続するが、現在のピクチャに先行するとき、第１のピクチャは、現在のピクチャの時間ＩＤよりも低いかまたは現在のピクチャの時間ＩＤに等しい時間ＩＤを有し、復号順序において現在のピクチャに先行する。第１のフラグの値が１に等しく設定されたとき、第１のピクチャは参照ピクチャとして使用されないことがある。一実施形態では、第１のシンタックス要素はｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇである。一実施形態では、第１のフラグはｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇである。
【０１７６】
[00185]ブロック５０３Ａにおいて、第１のシンタックス要素がビットストリーム中に存在しない場合、デコーダ３３は、複数のレイヤのうちの特定のレイヤ中の時間サブレイヤの最大数を示す第２のシンタックス要素を取得する。一実施形態では、第２のシンタックス要素はｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１である。
【０１７７】
[00186]ブロック５０４Ａにおいて、第２のシンタックス要素の値が０よりも大きい場合、ブロック５０５Ａにおいて、デコーダ３３は、第１のフラグの値を、参照ピクチャの時間ＩＤがネスティングされ得るかどうかを示す第２のフラグの値に等しく設定し、ここで、第２のフラグはビットストリーム中のＶＰＳに関連付けられる。第２のフラグは、現在のＡＵ中の現在のピクチャが第３のピクチャを参照ピクチャとして使用することができるかどうかを示し得、ここで、第４のピクチャが第３のピクチャの時間ＩＤよりも低い時間ＩＤを有し、復号順序において第３のピクチャに後続するが、現在のピクチャに先行するとき、第３のピクチャは、現在のピクチャの時間ＩＤよりも低いかまたは現在のピクチャの時間ＩＤに等しい時間ＩＤを有し、復号順序において現在のピクチャに先行する。第３のピクチャおよび第４のピクチャは、それぞれ上記の第１のピクチャおよび第２のピクチャと同じピクチャを指すことがある。第１および第２のフラグは、現在のピクチャと同じかまたは現在のピクチャよりも低い時間ＩＤを有する特定のピクチャが、特定のピクチャよりも低い時間ＩＤを有し、復号順序において特定のピクチャに後続するが、現在のピクチャに先行する、別のピクチャが存在するとき、参照ピクチャとして使用され得るかどうかを示すことができる。一実施形態では、第２のフラグはｖｐｓ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇである。
【０１７８】
[00187]ブロック５０４Ａにおいて、第２のシンタックス要素の値が０よりも小さいかまたは０に等しい場合、ブロック５０６Ａにおいて、デコーダ３３は第１のフラグの値を１に等しく設定する。
【０１７９】
[00188]プロセス５００Ａはブロック５０７Ａにおいて終了する。ブロックは、実施形態によっては、プロセス５００Ａにおいて追加および／または省略され得、プロセス５００Ａのブロックは、実施形態によっては、異なる順序で実施され得る。
【０１８０】
[00189]本開示におけるマルチレイヤビットストリームのためのＳＰＳ時間ＩＤネスティング情報の導出に関して説明したいかなる特徴および／または実施形態も、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図１〜図５に関して説明したいかなる特徴および／または実施形態、ならびに本開示の他の部分も、図５Ａに関して説明した任意の特徴および／または実施形態との任意の組合せで実装され得、その逆も同様である。
【０１８１】
マルチレイヤビットストリームのためのシーケンス終了ＮＡＬユニット情報
[00190]ＳＨＶＣおよびＭＶ−ＨＥＶＣが１つまたは複数のレイヤのピクチャを含んでいることがあるとすれば、アクセスユニットは、異なるレイヤからのピクチャであるが、同じＰＯＣ値を有するピクチャを含んでいることがある。したがって、シーケンス終了ＮＡＬユニットが、あるレイヤに適用されるのか、レイヤのいくつかまたはすべてに適用されるのかは明瞭でないことがある。ＥＯＳ  ＮＡＬユニットは、ピクチャまたはアクセスユニットのシーケンスの終了を示すことができる。たとえば、ＥＯＳの後のピクチャまたはアクセスユニットは別のシーケンスに属する。マルチレイヤビットストリーム（たとえば、ＳＨＶＣまたはＭＶ−ＨＥＶＣ）では、アクセスユニットが２つ以上のピクチャを含んでいることがあるので、シーケンス終了ＮＡＬユニットの範囲がピクチャに関連付けられるのかアクセスユニットに関連付けられるのかは明瞭でない。したがって、いくつかの態様による技法は、ＥＯＳ  ＮＡＬユニットが、特定のレイヤに適用されるのか、レイヤのいくつかまたはすべてに適用されるのかを明瞭にするために、ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンを変更することができる。
【０１８２】
例示的な実施形態２
[00191]本開示における例示的な実施形態は、ＳＨＶＣおよびＭＶ−ＨＥＶＣ（たとえば、ＳＨＶＣ  ＷＤ５およびＭＶ−ＨＥＶＣ  ＷＤ７）の以前のバージョンのコンテキストにおいて与えられる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンを変更するための命令はイタリック体で示され、ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンからの削除は取消し線で示されている。
【表５】
0006622211.tif 000009
【０１８３】
[00192]この実施形態では、ＡＵ中に、そのＡＵ中のすべてのレイヤに適用される１つのＥＯＳ  ＮＡＬユニットがある。たとえば、ＡＵ中に存在するＥＯＳ  ＮＡＬユニットは、０に等しいレイヤＩＤを有する。ＥＯＳ  ＮＡＬユニットが、０よりも大きいレイヤＩＤを有する場合、デコーダはＥＯＳ  ＮＡＬユニットを無視することができる。ＮＡＬユニットは様々なタイプを有し得、タイプＥＯＳ＿ＮＵＴは、そのＮＡＬユニットがＥＯＳを含んでいることを示し得る。いくつかの態様によれば、ＥＯＳ＿ＮＵＴのタイプであるＮＡＬユニットはＥＯＳ  ＮＡＬユニットと呼ばれることがある。
【０１８４】
[00193]例示的な実施形態２は、ＥＯＳ  ＮＡＬユニットがすべてのレイヤに適用されることを明瞭にし、それによって、マルチレイヤビットストリーム中のＥＯＳ  ＮＡＬユニットを処理する際のあいまいさをなくす。
【０１８５】
例示的な実施形態３
[00194]本開示における例示的な実施形態は、ＳＨＶＣおよびＭＶ−ＨＥＶＣ（たとえば、ＳＨＶＣ  ＷＤ５およびＭＶ−ＨＥＶＣ  ＷＤ７）の以前のバージョンのコンテキストにおいて与えられる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンを変更するための命令はイタリック体で示されている。ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンへの追加はイタリック体および下線で示され、ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンからの削除は取消し線で示されている。
【表６−１】
0006622211.tif 000010
【表６−２】
0006622211.tif 000011
【０１８６】
[00195]この実施形態では、特定のレイヤ中のＥＯＳ  ＮＡＬユニットはそのレイヤのみに適用可能である。たとえば、各レイヤはそれ自体のＥＯＳ  ＮＡＬユニットを有することができ、ＡＵは２つ以上のＥＯＳ  ＮＡＬユニットを含むことができる。特定のレイヤのＥＯＳ  ＮＡＬユニットに後続するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャであることができる、ＩＲＡＰピクチャであるべきである。特定のレイヤについてＥＯＳ  ＮＡＬユニットが存在するとき、ＥＯＳ  ＮＡＬユニットは、その特定のレイヤと同じＩＤまたはその特定のレイヤよりも低いレイヤＩＤをもつビデオコーディングレイヤ（ＶＣＬ：Video Coding Layer）ＮＡＬユニットに後続し、ＡＵ中にビットストリーム終了（ＥＯＢ：end of bitstream）ＮＡＬユニットが存在するとき、それに先行することができる。
【０１８７】
[00196]このようにして、例示的な実施形態３は、特定のレイヤ中のＥＯＳ  ＮＡＬユニットがその特定のレイヤのみに適用されることを明瞭にし、それによって、マルチレイヤビットストリーム中のＥＯＳ  ＮＡＬユニットを処理する際のあいまいさをなくす。
【０１８８】
マルチレイヤビットストリームのためのＥＯＳ  ＮＡＬユニット情報の導出の方法
[00197]図６は、本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャートである。本方法は、マルチレイヤビットストリームのためのＥＯＳ  ＮＡＬユニット情報の導出に関する。プロセス６００は、実施形態によっては、エンコーダ（たとえば、図２Ａ、図２Ｂなどに示されているエンコーダ）、デコーダ（たとえば、図３Ａ、図３Ｂなどに示されているデコーダ）、または任意の他の構成要素によって実施され得る。プロセス６００のブロックは図３Ｂ中のデコーダ３３に関して説明されるが、プロセス６００は、上述のように、エンコーダなど、他の構成要素によって実施され得る。デコーダ３３のレイヤ１ビデオデコーダ３０Ｂおよび／またはデコーダ３３のレイヤ０デコーダ３０Ａが、実施形態によっては、プロセス６００を実施し得る。図６に関して説明するすべての実施形態は、別々に、または互いと組み合わせて実装され得る。プロセス６００に関係するいくつかの詳細が、たとえば、図４および図５に関して上記で説明されている。
【０１８９】
[00198]プロセス６００はブロック６０１において開始する。デコーダ３３は、１つまたは複数のレイヤに関連付けられたビデオ情報を記憶するためのメモリを含むことができる。
【０１９０】
[00199]ブロック６０２において、デコーダ３３は、複数のレイヤを含むビットストリーム中の現在のＡＵをコーディングし、複数のレイヤは、参照レイヤと、少なくとも１つの対応するエンハンスメントレイヤとを含む。
【０１９１】
[00200]ブロック６０３において、デコーダ３３は、現在のＡＵ中の参照レイヤに関連付けられた第１のＥＯＳ  ＮＡＬユニットをコーディングし、第１のＥＯＳ  ＮＡＬユニットは参照レイヤと同じレイヤＩＤを有する。現在のＡＵの後のＡＵ中にあり、第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャであり得る。いくつかの実施形態では、第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する。いくつかの実施形態では、第１のＥＯＳ  ＮＡＬユニットは、参照レイヤと同じレイヤＩＤまたは参照レイヤよりも低いレイヤＩＤを有する、現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、第１のＥＯＳ  ＮＡＬユニットは現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する。
【０１９２】
[00201]ブロック６０４において、デコーダ３３は、現在のＡＵ中のエンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングし、第２のＥＯＳ  ＮＡＬユニットはエンハンスメントレイヤと同じレイヤＩＤを有する。現在のＡＵの後のＡＵ中にあり、第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャであり得る。いくつかの実施形態では、第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する。いくつかの実施形態では、第２のＥＯＳ  ＮＡＬユニットは、エンハンスメントレイヤと同じレイヤＩＤまたはエンハンスメントレイヤよりも低いレイヤＩＤを有する、現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、第２のＥＯＳ  ＮＡＬユニットは現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する。
【０１９３】
[00202]プロセス６００はブロック６０５において終了する。ブロックは、実施形態によっては、プロセス６００において追加および／または省略され得、プロセス６００のブロックは、実施形態によっては、異なる順序で実施され得る。
【０１９４】
[00203]本開示におけるマルチレイヤビットストリームのためのＥＯＳ  ＮＡＬユニット情報の導出に関して説明したいかなる特徴および／または実施形態も、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図１〜図５に関して説明したいかなる特徴および／または実施形態、ならびに本開示の他の部分も、図６に関して説明した任意の特徴および／または実施形態との任意の組合せで実装され得、その逆も同様である。
【０１９５】
マルチレイヤビットストリームのためにＣＲＡをＢＬＡとして処理すること
[00204]ＳＨＶＣおよびＭＶ−ＨＥＶＣの場合のように、１つのＡＵが２つ以上のレイヤからのピクチャを含んでいる場合、変数ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇなど、特定のレイヤ（たとえば、ベースレイヤ）に関連付けられた変数またはフラグが、ＡＵ全体に適用されるべきなのか、それが関連付けられた特定のレイヤのみに適用されるべきなのかは不確定であり得る。ＳＨＶＣ／ＭＶ−ＨＥＶＣへの既存の手法では、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは各ＣＲＡピクチャに関連付けられ得る。システムがＣＲＡピクチャをＢＬＡピクチャに変更することができない場合、ランダムアクセスまたはスプライシングを容易にする外部手段として変数が導入され得る。マルチレイヤコンテキストでは、ランダムアクセスおよびスプライシングは、ベースレイヤにあるＩＲＡＰピクチャ（たとえば、ＩＲＡＰアクセスユニット）において行われ得る。したがって、ベースレイヤ中のまたは任意の他のレイヤ中のＣＲＡピクチャのためのＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値は同じであるべきである。たとえば、ベースレイヤ中のＣＲＡピクチャをもつＩＲＡＰアクセスユニットにおいてランダムアクセスが起こり、同じアクセスユニット中の１つまたは複数の（さらにはすべての）エンハンスメントレイヤピクチャもＣＲＡピクチャであるとき、デコーダがそれらのピクチャを同じ様式で扱うかまたは処理するように、それらのピクチャがＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの同じ値を有することが望ましいことがある。したがって、変数ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは、ピクチャに関連付けられるのではなく、アクセスユニットに関連付けられるように簡略化され得る。
【０１９６】
例示的な実施形態４
[00205]本開示における例示的な実施形態は、ＳＨＶＣおよびＭＶ−ＨＥＶＣ（たとえば、ＳＨＶＣ  ＷＤ５およびＭＶ−ＨＥＶＣ  ＷＤ７）の以前のバージョンのコンテキストにおいて与えられる。ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンへの追加はイタリック体で示され、ＳＨＶＣおよびＭＶ−ＨＥＶＣの以前のバージョンからの削除は取消し線で示されている。
【表７】
0006622211.tif 000012
【０１９７】
[00206]この実施形態では、ＡＵが１つまたは複数のＣＲＡピクチャを含んでいるとき、変数ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは、そのＡＵ中のすべてのＣＲＡピクチャについて同じであるように導出される。外部手段がＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値を与えることができる場合、外部手段によって与えられる値が、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値を設定するために使用される。そうでない場合、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは０に等しく設定される。
【０１９８】
[00207]ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇを各ＣＲＡピクチャに関連付けることは、異なるＣＲＡピクチャについてＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇのための異なる値を有することに潜在的につながり得る。したがって、本技法は、ＡＵ中のすべてのＣＲＡピクチャについてＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値が同じであることを確実にすることによって、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値の推論を簡略化することができる。
【０１９９】
[00208]本明細書で開示される情報および信号は、多種多様な技術および技法のいずれかを使用して表され得る。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。
【０２００】
[00209]本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概してそれらの機能に関して上記で説明された。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。
【０２０１】
[00210]本明細書で説明した技術は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなど、様々なデバイスのいずれかにおいて実装され得る。モジュールまたは構成要素として説明した任意の特徴は、集積論理デバイスに一緒に、または個別であるが相互運用可能な論理デバイスとして別々に実装され得る。ソフトウェアで実装した場合、本技法は、実行されたとき、上記で説明した方法のうちの１つまたは複数を実施する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含むことがあるコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュメモリ、磁気または光学データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。本技法は、追加または代替として、伝搬信号または電波など、命令またはデータ構造の形態でプログラムコードを搬送または伝達し、コンピュータによってアクセスされ、読み取られ、および／または実行され得るコンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
【０２０２】
[00211]プログラムコードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、または他の等価の集積回路またはディスクリート論理回路など、１つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明する技法のいずれかを実施するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明する技法の実装に好適な任意の他の構造または装置のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のソフトウェアモジュールもしくはハードウェアモジュール内に与えられ得、または複合ビデオエンコーダ／デコーダ（コーデック）に組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
【０２０３】
[00212]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示する技法を実施するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって与えられ得る。
【０２０４】
[00213]本開示の様々な実施形態が説明された。これらおよび他の実施形態は以下の特許請求の範囲内に入る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオ情報をコーディングするための装置であって、
１つまたは複数のレイヤに関連付けられたビデオ情報を記憶するためのメモリと、
前記メモリに動作可能に結合され、
複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングすることと、前記複数のレイヤは、参照レイヤと、少なくとも１つの対応するエンハンスメントレイヤとを含み、
前記現在のＡＵ中の前記参照レイヤに関連付けられた第１のシーケンス終了（ＥＯＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングすることと、前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤ識別子（ＩＤ）を有し、
前記現在のＡＵ中の前記エンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤを有し、
を行うように構成されたハードウェアプロセッサと
を備える、装置。
［Ｃ２］
前記現在のＡＵの後のＡＵ中にあり、前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、切断リンクアクセス（ＢＬＡ）ピクチャ、またはクリーンランダムアクセス（ＣＲＡ）ピクチャのうちの１つまたは複数から選択されたイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、Ｃ１に記載の装置。
［Ｃ３］
前記現在のＡＵの後のＡＵ中にあり、前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャである、Ｃ１に記載の装置。
［Ｃ４］
前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ１に記載の装置。
［Ｃ５］
前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ１に記載の装置。
［Ｃ６］
前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤＩＤまたは前記参照レイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のビデオコーディングレイヤ（ＶＣＬ）ユニットの後にあり、前記第１のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ１に記載の装置。
［Ｃ７］
前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤまたは前記エンハンスメントレイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、前記第２のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ１に記載の装置。
［Ｃ８］
ビデオ情報をコーディングする方法であって、
１つまたは複数のレイヤに関連付けられたビデオ情報を記憶することと、
複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングすることと、前記複数のレイヤは、参照レイヤと、少なくとも１つの対応するエンハンスメントレイヤとを含み、
前記現在のＡＵ中の前記参照レイヤに関連付けられた第１のシーケンス終了（ＥＯＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングすることと、前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤ識別子（ＩＤ）を有し、
前記現在のＡＵ中の前記エンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤを有し、
を備える、方法。
［Ｃ９］
前記現在のＡＵの後のＡＵ中にあり、前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、切断リンクアクセス（ＢＬＡ）ピクチャ、またはクリーンランダムアクセス（ＣＲＡ）ピクチャのうちの１つまたは複数から選択されたイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、Ｃ８に記載の方法。
［Ｃ１０］
前記現在のＡＵの後のＡＵ中にあり、前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、ＩＤＲピクチャ、ＢＬＡピクチャ、またはＣＲＡピクチャのうちの１つまたは複数から選択されたＩＲＡＰピクチャである、Ｃ８に記載の方法。
［Ｃ１１］
前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ８に記載の方法。
［Ｃ１２］
前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ８に記載の方法。
［Ｃ１３］
前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤＩＤまたは前記参照レイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のビデオコーディングレイヤ（ＶＣＬ）ユニットの後にあり、前記第１のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ８に記載の方法。
［Ｃ１４］
前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤまたは前記エンハンスメントレイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、前記第２のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ８に記載の方法。
［Ｃ１５］
コンピュータハードウェアを備えるプロセッサ上で実行されたとき、
１つまたは複数のレイヤに関連付けられたビデオ情報を記憶することと、
複数のレイヤを含むビットストリーム中の現在のアクセスユニット（ＡＵ）をコーディングすることと、前記複数のレイヤは、参照レイヤと、少なくとも１つの対応するエンハンスメントレイヤとを含み、
前記現在のＡＵ中の前記参照レイヤに関連付けられた第１のシーケンス終了（ＥＯＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングすることと、前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤ識別子（ＩＤ）を有し、
前記現在のＡＵ中の前記エンハンスメントレイヤに関連付けられた第２のＥＯＳ  ＮＡＬユニットをコーディングすることと、前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤを有し、
を前記プロセッサに行わせる命令を備える、非一時的コンピュータ可読媒体。
［Ｃ１６］
前記現在のＡＵの後のＡＵ中にあり、前記第１のＥＯＳ  ＮＡＬユニットまたは前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有するピクチャは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、切断リンクアクセス（ＢＬＡ）ピクチャ、またはクリーンランダムアクセス（ＣＲＡ）ピクチャのうちの１つまたは複数から選択されたイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、Ｃ１５に記載のコンピュータ可読媒体。
［Ｃ１７］
前記第１のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ１５に記載のコンピュータ可読媒体。
［Ｃ１８］
前記第２のＥＯＳ  ＮＡＬユニットと同じレイヤＩＤを有する、前記現在のＡＵの後のＡＵ中のＩＲＡＰピクチャは、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値を有する、Ｃ１５に記載のコンピュータ可読媒体。
［Ｃ１９］
前記第１のＥＯＳ  ＮＡＬユニットは、前記参照レイヤと同じレイヤＩＤまたは前記参照レイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のビデオコーディングレイヤ（ＶＣＬ）ユニットの後にあり、前記第１のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ１５に記載のコンピュータ可読媒体。
［Ｃ２０］
前記第２のＥＯＳ  ＮＡＬユニットは、前記エンハンスメントレイヤと同じレイヤＩＤまたは前記エンハンスメントレイヤよりも低いレイヤＩＤを有する、前記現在のＡＵ中の１つまたは複数のＶＣＬユニットの後にあり、前記第２のＥＯＳ  ＮＡＬユニットは、前記現在のＡＵ中のいずれのビットストリーム終了ＮＡＬユニットにも先行する、Ｃ１５に記載のコンピュータ可読媒体。
【図１Ａ】
0006622211.tif 000013
【図１Ｂ】
0006622211.tif 000014
【図２Ａ】
0006622211.tif 000015
【図２Ｂ】
0006622211.tif 000016
【図３Ａ】
0006622211.tif 000017
【図３Ｂ】
0006622211.tif 000018
【図４】
0006622211.tif 000019
【図５】
0006622211.tif 000020
【図５Ａ】
0006622211.tif 000021
【図６】
0006622211.tif 000022