(57)【要約】１つの例では、ビデオエンコーダまたはビデオデコーダなどのビデオコーダは、ビデオデータの１つまたは複数のレイヤについてのＶＰＳをコーディングし、ビデオデータの前記１つまたは複数のレイヤの各々はビデオパラメータセット（ＶＰＳ）を参照し、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの１つまたは複数のレイヤをコーディングするように構成される。ビデオコーダは、高効率ビデオコーディング、マルチビュービデオコーディング、スケーラブルビデオコーディング、または他のビデオコーディング規格もしくはビデオコーディング規格の拡張に準拠するビデオデータのＶＰＳをコーディングし得る。ＶＰＳは、様々な異なるレイヤ（たとえば、ビュー、品質レイヤなど）内のビデオデータの対応するシーケンスについてのパラメータを指定するデータを含み得る。ＶＰＳのパラメータは、対応するビデオデータがどのようにコーディングされるかのインジケーションを与え得る。
2015507428.tif 000002
【特許請求の範囲】
【請求項１】
ビデオデータをコーディングする方法であって、
ビデオデータの１つまたは複数のレイヤについてビデオパラメータセット（ＶＰＳ）をコーディングすることと、ビデオデータの前記１つまたは複数のレイヤのそれぞれは前記ＶＰＳを参照し、
前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすることと、
を備える方法。
【請求項２】
前記ＶＰＳをコーディングすることは、前記１つまたは複数のレイヤにおける時間レイヤの最大数を示す前記ＶＰＳのデータをコーディングすることを備える、請求項１に記載の方法。
【請求項３】
前記ＶＰＳをコーディングすることは、前記１つまたは複数のレイヤのうちの少なくとも１つにおいて並べ替えられるフレームの数を示す前記ＶＰＳのデータをコーディングすることを備える、請求項１に記載の方法。
【請求項４】
前記ＶＰＳをコーディングすることは、前記１つまたは複数のレイヤの復号中に復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数を示す前記ＶＰＳのデータをコーディングすることを備える、請求項１に記載の方法。
【請求項５】
前記ＶＰＳをコーディングすることは、仮想参照デコーダ（ＨＲＤ）パラメータの１つまたは複数のセットを示す前記ＶＰＳのデータをコーディングすることを備える、請求項１に記載の方法。
【請求項６】
前記ＶＰＳをコーディングすることは、前記ＶＰＳが対応する規格を超える拡張を含むかどうかを示す前記ＶＰＳのデータと、前記ＶＰＳが前記拡張を含むときの前記拡張のためのデータとをコーディングすることを備える、請求項１に記載の方法。
【請求項７】
前記１つまたは複数のレイヤをコーディングすることは、高効率ビデオコーディング（ＨＥＶＣ）に従って前記１つまたは複数のレイヤをコーディングすることを備える、請求項１に記載の方法。
【請求項８】
前記１つまたは複数のレイヤをコーディングすることは、マルチビュービデオコーディング（ＭＶＣ）およびスケーラブルビデオコーディング（ＳＶＣ）のうちの少なくとも１つに従って前記１つまたは複数のレイヤをコーディングすることを備える、請求項１に記載の方法。
【請求項９】
前記ＶＰＳをコーディングすることは、ビデオデータの前記１つまたは複数のレイヤの１つまたは複数の次元について、ビデオデータの前記１つまたは複数のレイヤにおける優先レイヤの数、ビデオデータの前記１つまたは複数のレイヤにおける従属レイヤの数、ビデオデータの前記１つまたは複数のレイヤにおける時間レイヤの数、ビデオデータの前記１つまたは複数のレイヤにおける前記従属レイヤのいずれかについての品質レイヤの最大数、およびビデオデータの前記１つまたは複数のレイヤにおけるビューの最大数のうちの１つまたは複数を指定する情報をコーディングすることを備える、請求項１に記載の方法。
【請求項１０】
前記ビデオデータの前記１つまたは複数のレイヤのサブセットが、同じ空間解像度および同じビット深度を有するとき、前記サブセットの前記レイヤの各々は、前記従属レイヤのうちの異なる１つに対応する、請求項２に記載の方法。
【請求項１１】
前記ＶＰＳをコーディングすることは、特性マッピングに対するサンプルインデックスを定義する情報をコーディングすることを備え、特性マッピングに対する前記サンプルインデックスを定義する前記情報をコーディングすることは、ビデオデータの前記１つまたは複数のレイヤの次元の特性インジケータが０からサンプル次元カウンタ−１までのインデックス範囲内にないとき、複数の特性インデックスの各々についてのそれぞれの特性インジケータを指定する情報をコーディングすることを備える、請求項１０に記載の方法。
【請求項１２】
前記ＶＰＳをコーディングすることは、特性マッピングに対するサンプルインデックスを定義する情報をコーディングすることを備え、特性マッピングに対する前記サンプルインデックスを定義する前記情報をコーディングすることは、複数の従属インデックスの各々についてのそれぞれの空間解像度、複数の時間インデックスの各々についてのフレームレート、複数のビューインデックスの各々についてのビュー識別子、複数のビット深度インデックスの各々のルミナンスおよびクロミナンスについての特定の深度値の対、および複数のクロミナンスサンプリングフォーマットの各々についての特定のクロミナンスサンプリングフォーマットインジケータのうちの１つまたは複数をコーディングすることを備える、請求項１０に記載の方法。
【請求項１３】
前記ＶＰＳをコーディングすることは、制御パラメータ、および１つまたは複数のツール有効化／無効化フラグを定義する情報をコーディングすることを備える、請求項１に記載の方法。
【請求項１４】
前記制御パラメータおよび前記１つまたは複数のツール有効化／無効化フラグは、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ１、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ１、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｌｉｃｅ＿ｆｌａｇ、ｐｃｍ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｄｉｓａｂｌｅ＿ｆｌａｇ、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇ、１つまたは複数のタイル関連のシンタックス要素、ｃｈｒｏｍａ＿ｐｒｅｄ＿ｆｒｏｍ＿ｌｕｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓａｍｐｌｅ＿ａｄａｐｔｉｖｅ＿ｏｆｆｓｅｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ａｄａｐｔｉｖｅ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、およびｉｎｔｅｒ＿４×４＿ｅｎａｂｌｅｄ＿ｆｌａｇのうちの１つまたは複数を備える、請求項１３に記載の方法。
【請求項１５】
前記ＶＰＳをコーディングすることは、１つまたは複数のオペレーションポイント記述子を定義する情報をコーディングすることを備える、請求項１に記載の方法。
【請求項１６】
前記１つまたは複数のオペレーションポイント記述子を定義する前記情報をコーディングすることは、最大オペレーションポイントの数、異なるレイヤまたはビュー間の従属性、前記オペレーションポイントの各々についてのプロファイルおよびレベル、各オペレーションポイントについて、オペレーションポイントビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニット表示、各次元について、特定のインデックス値、前記次元についての潜在的なインデックス値の範囲、およびインデックス値のリストのうちの１つもしくは複数、前記オペレーションポイントの各々についてのビットレート、前記オペレーションポイント間の従属性、前記オペレーションポイントの各々についての制限、前記オペレーションポイントの各々についてのビデオユーザビリティ情報（ＶＵＩ）、および前記１つまたは複数のレイヤの各々についてのＶＵＩのうちの１つまたは複数を定義する情報をコーディングすることを備える、請求項１５に記載の方法。
【請求項１７】
ビデオデータの前記１つまたは複数のレイヤの各々についてのそれぞれのレイヤードシーケンスパラメータセット（ＬＰＳ）をコーディングすることをさらに備え、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすることは、前記ＶＰＳおよび前記それぞれのＬＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすることを備える、請求項１に記載の方法。
【請求項１８】
前記１つまたは複数のレイヤの各々についての前記それぞれのＬＰＳをコーディングすることは、各次元について、各次元に対するインデックスを示すサンプル次元表示を定義する情報をコーディングすることを備える、請求項１７に記載の方法。
【請求項１９】
前記１つまたは複数のレイヤの各々についての前記それぞれのＬＰＳをコーディングすることは、制御パラメータおよびツール有効化／無効化フラグを定義する情報をコーディングすることを備える、請求項１７に記載の方法。
【請求項２０】
前記制御パラメータおよび前記１つまたは複数のツール有効化／無効化フラグは、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ１、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ１、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｌｉｃｅ＿ｆｌａｇ、ｐｃｍ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｄｉｓａｂｌｅ＿ｆｌａｇ、１つまたは複数のタイル関連のシンタックス要素、ｃｈｒｏｍａ＿ｐｒｅｄ＿ｆｒｏｍ＿ｌｕｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓａｍｐｌｅ＿ａｄａｐｔｉｖｅ＿ｏｆｆｓｅｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ａｄａｐｔｉｖｅ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、およびコーディングユニット（ＣＵ）ハイアラーキのうちの１つまたは複数を備える、請求項１９に記載の方法。
【請求項２１】
前記１つまたは複数のレイヤの各々についての前記それぞれのＬＰＳをコーディングすることは、スライス、スライスのグループ、ピクチャ、および共通のピクチャパラメータセット（ＰＰＳ）を参照するいくつかのピクチャのうちの少なくとも１つに適用する１つまたは複数の他のパラメータセットの情報を定義する情報をコーディングすることを備える、請求項１７に記載の方法。
【請求項２２】
１つまたは複数のピクチャパラメータセット（ＰＰＳ）が、前記ＶＰＳを参照せず、かつ、ビデオデータの前記１つまたは複数のレイヤのレイヤードシーケンスパラメータセット（ＬＰＳ）を参照しないように、前記１つまたは複数のＰＰＳをコーディングすることをさらに含む、請求項１に記載の方法。
【請求項２３】
前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすることは、前記ＶＰＳ、前記ＰＰＳ、および前記ＬＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすること、を備え、前記ＰＰＳのうちの１つのシンタックス要素が前記ＶＰＳまたは前記ＬＰＳのうちのそれぞれ１つと相反するとき、前記ＰＰＳのうちの前記１つの前記シンタックス要素に基づいてビデオデータの前記１つまたは複数のレイヤのうちの対応する１つをコーディングする、請求項２２に記載の方法。
【請求項２４】
ビデオデータの前記１つまたは複数のレイヤについての、前記ＶＰＳを含む、すべてのパラメータセットを一緒にグルーピングするグルーピングパラメータセット（ＧＰＳ）をコーディングすることをさらに備える、請求項１に記載の方法。
【請求項２５】
前記ＧＰＳをコーディングすることは、前記ＧＰＳの識別子を定義する情報をコーディングすることを備え、前記方法は、前記ＧＰＳの前記識別子に対応するスライスヘッダの情報をコーディングすることをさらに備える、請求項２４に記載の方法。
【請求項２６】
前記ビデオデータの１つまたは複数のレイヤをコーディングすることは、ビデオデータの前記１つまたは複数のレイヤを復号することを備え、前記ＶＰＳをコーディングすることは、前記ＶＰＳをパーシングすることを備える、請求項１に記載の方法。
【請求項２７】
前記ビデオデータの１つまたは複数のレイヤをコーディングすることは、ビデオデータの前記１つまたは複数のレイヤを符号化することを備え、前記ＶＰＳをコーディングすることは、前記ＶＰＳを構成することを備える、請求項１に記載の方法。
【請求項２８】
ビデオデータをコーディングするためのデバイスであって、
ビデオデータの１つまたは複数のレイヤについてビデオパラメータセット（ＶＰＳ）をコーディングし、ビデオデータの前記１つまたは複数のレイヤのそれぞれは前記ＶＰＳを参照し、
前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングするように構成されたビデオコーダ
を備える、デバイス。
【請求項２９】
前記ビデオコーダは、前記１つまたは複数のレイヤにおける時間レイヤの最大数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３０】
前記ビデオコーダは、前記１つまたは複数のレイヤのうちの少なくとも１つにおいて並べ替えられるフレームの数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３１】
前記ビデオコーダは、前記１つまたは複数のレイヤの復号中に復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３２】
前記ビデオコーダは、仮想参照デコーダ（ＨＲＤ）パラメータの１つまたは複数のセットを示す前記ＶＰＳのデータをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３３】
前記ビデオコーダは、前記ＶＰＳが対応する規格を超える拡張を含むかどうかを示す前記ＶＰＳのデータと、前記ＶＰＳが前記拡張を含むときの前記拡張のためのデータとをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３４】
前記ビデオコーダは、高効率ビデオコーディング（ＨＥＶＣ）、マルチビュービデオコーディング（ＭＶＣ）、およびスケーラブルビデオコーディング（ＳＶＣ）のうちの１つに従って前記１つまたは複数のレイヤをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３５】
前記ビデオコーダはビデオデコーダを備える、請求項２８に記載のデバイス。
【請求項３６】
前記ビデオコーダはビデオエンコーダを備える、請求項２８に記載のデバイス。
【請求項３７】
集積回路と、
マイクロプロセッサと、
前記ビデオコーダを含むワイヤレス通信デバイスと、
のうちの少なくとも１つを備える、請求項２８に記載のデバイス。
【請求項３８】
ビデオデータをコーディングするためのデバイスであって、
ビデオデータの１つまたは複数のレイヤについてビデオパラメータセット（ＶＰＳ）をコーディングする手段と、ビデオデータの前記１つまたは複数のレイヤのそれぞれは前記ＶＰＳを参照し、
前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングする手段と、
を備える、デバイス。
【請求項３９】
前記ビデオコーダは、前記１つまたは複数のレイヤにおける時間レイヤの最大数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４０】
前記ビデオコーダは、前記１つまたは複数のレイヤのうちの少なくとも１つにおいて並べ替えられるフレームの数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４１】
前記ビデオコーダは、前記１つまたは複数のレイヤの復号中に復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数を示す前記ＶＰＳのデータをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４２】
前記ビデオコーダは、仮想参照デコーダ（ＨＲＤ）パラメータの１つまたは複数のセットを示す前記ＶＰＳのデータをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４３】
前記ビデオコーダは、前記ＶＰＳが対応する規格を超える拡張を含むかどうかを示す前記ＶＰＳのデータと、前記ＶＰＳが前記拡張を含むときの前記拡張のためのデータとをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４４】
前記ビデオコーダは、高効率ビデオコーディング（ＨＥＶＣ）、マルチビュービデオコーディング（ＭＶＣ）、およびスケーラブルビデオコーディング（ＳＶＣ）のうちの１つに従って前記１つまたは複数のレイヤをコーディングするように構成される、請求項３８に記載のデバイス。
【請求項４５】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されるとき、プロセッサに、
ビデオデータの１つまたは複数のレイヤについてビデオパラメータセット（ＶＰＳ）をコーディングさせ、ビデオデータの前記１つまたは複数のレイヤのそれぞれは前記ＶＰＳを参照し、
前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングさせる、
コンピュータ可読記憶媒体。
【請求項４６】
前記プロセッサに前記ＶＰＳをコーディングさせる前記命令は、前記プロセッサに前記１つまたは複数のレイヤにおける時間レイヤの最大数を示す前記ＶＰＳのデータをコーディングさせる命令を備える、請求項４５に記載のコンピュータ可読記憶媒体。
【請求項４７】
前記プロセッサに前記ＶＰＳをコーディングさせる前記命令は、前記プロセッサに前記１つまたは複数のレイヤの少なくとも１つにおいて並べ替えられるフレームの数を示す前記ＶＰＳのデータをコーディングさせる命令を備える、請求項４５に記載のコンピュータ可読記憶媒体。
【請求項４８】
前記プロセッサに前記ＶＰＳをコーディングさせる前記命令は、前記プロセッサに前記１つまたは複数のレイヤの復号中に復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数を示す前記ＶＰＳのデータをコーディングさせる命令を備える、請求項４５に記載のコンピュータ可読記憶媒体。
【請求項４９】
前記プロセッサに前記ＶＰＳをコーディングさせる前記命令は、前記プロセッサに仮想参照デコーダ（ＨＲＤ）パラメータの１つまたは複数のセットを示す前記ＶＰＳのデータをコーディングさせる命令を備える、請求項４５に記載のコンピュータ可読記憶媒体。
【請求項５０】
前記プロセッサに前記ＶＰＳをコーディングさせる前記命令は、前記ＶＰＳが対応する規格を超える拡張を含むかどうかを示す前記ＶＰＳのデータと、前記ＶＰＳが前記拡張を含むときの前記拡張のためのデータとを前記プロセッサにコーディングさせる命令を備える、請求項４５に記載のコンピュータ可読記憶媒体。
【請求項５１】
前記プロセッサに前記１つまたは複数のレイヤをコーディングさせる前記命令は、高効率ビデオコーディング（ＨＥＶＣ）、マルチビュービデオコーディング（ＭＶＣ）、およびスケーラブルビデオコーディング（ＳＶＣ）のうちの１つに従って前記１つまたは複数のレイヤを前記プロセッサにコーディングさせる命令を備える、請求項４５に記載のデバイス。
【発明の詳細な説明】
【優先権の主張】
【０００１】
本出願は、各々の内容全体が参照により本明細書に組み込まれる、
２０１２年１月１４日に出願された米国仮出願第６１／５８６，７７７号、
２０１２年１月１６日に出願された米国仮出願第６１／５８７，０７０号、
２０１２年１月１９日に出願された米国仮出願第６１／５８８，６２９号、
２０１２年４月２３日に出願された米国仮出願第６１／６３７，１９５号、および
２０１２年４月２４日に出願された米国仮出願第６１／６３７，７７４号の利益を主張する。
【技術分野】
【０００２】
本開示は、ビデオコーディングに関する。
【背景技術】
【０００３】
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ  １０、アドバンストビデオコーディング（ＡＶＣ）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法のような、ビデオコーディング技法を実装する。今度のＨＥＶＣ規格の最近のドラフトは、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／７＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｇ１１０３−ｖ３．ｚｉｐにおいて入手可能である。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００４】
[0004]ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコーディングされた（Ｉ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコーディングされた（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の近隣ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００５】
[0005]空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコーディングブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコーディングブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて残差変換係数をもたらすことができ、その残差変換係数は、次いで量子化することができる。量子化変換係数は、最初に２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査することができ、なお一層の圧縮を達成するためにエントロピーコーディングを適用することができる。
【発明の概要】
【０００６】
[0006]概して、本開示は、ビデオコーディング用のパラメータセットおよびネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングするための技法について説明する。これらの技法は、２次元ビデオデータなどのシングルレイヤコーディングデータに適用され、スケーラブルビデオコーディング（ＳＶＣ）ビデオデータおよびマルチビュービデオコーディング（ＭＶＣ）ビデオデータにも適用され得る。したがって、パラメータセットおよびＮＡＬユニットは、様々なタイプのビデオデータ間で相互に互換性があり得る。たとえば、ビデオエンコーダまたはビデオデコーダなどのビデオコーダは、ビデオデータの１つまたは複数のレイヤに関するパラメータを定義するビデオパラメータセット（ＶＰＳ）をコーディングし得る。レイヤは、たとえば、ＳＶＣレイヤ（様々なフレームレート、空間解像度、および／または品質レベルを有する）および／またはＭＶＣデータのビュー（たとえば、水平軸の周りの様々なカメラパースペクティブから捕捉されるシーンの画像シーケンス）に対応し得る。
【０００７】
[0007]一例では、ビデオデータをコーディングする方法は、ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）を含むビデオデータをコーディングすることと、ビデオデータの前記１つまたは複数のレイヤのそれぞれは、前記ＶＰＳを参照し、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングすることと、を含む。
【０００８】
[0008]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオエンコーダまたはビデオデコーダなどのビデオコーダを含み、当該ビデオコードは、ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）を含むビデオデータをコーディングし、ビデオデータの前記１つまたは複数のレイヤのそれぞれは、前記ＶＰＳを参照し、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングするように構成される。
【０００９】
[0009]別の例では、ビデオデータをコーディングするためのデバイスは、ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）を含むビデオデータをコーディングする手段と、ビデオデータの前記１つまたは複数のレイヤのそれぞれは、前記ＶＰＳを参照し、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングする手段と、を含む。
【００１０】
[0010]別の例では、コンピュータ可読記憶媒体は、実行されるとき、プロセッサに、
ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）を含むビデオデータをコーディングさせ、ビデオデータの前記１つまたは複数のレイヤのそれぞれは、前記ＶＰＳを参照し、前記ＶＰＳに少なくとも部分的に基づいてビデオデータの前記１つまたは複数のレイヤをコーディングさせる命令を記憶する。
【００１１】
[0011]１つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１２】
【図１】ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングするための技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２】ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびＮＡＬユニットをコーディングするための技法を実装し得るビデオエンコーダ２０の一例を示すブロック図。
【図３】ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびＮＡＬユニットをコーディングするための技法を実装し得るビデオデコーダ３０の一例を示すブロック図。
【図４】例示的なＭＶＣの予測パターンを示す概念図。
【図５】ビデオパラメータセット（ＶＰＳ）および様々なレイヤパラメータセット（ＬＰＳ）を示す概念図。
【図６】例示的なグルーピングパラメータセット（ＧＰＳ）と、ＧＰＳの他のパラメータセットおよびスライスヘッダとの関係を示す概念図。
【図７】本開示の技法による、ビデオデータを符号化するための例示的な方法を示すフローチャート。
【図８】本開示の技法による、ビデオデータを復号するための例示的な方法を示すフローチャート。
【図９】ＶＰＳにおいてシグナリングされる時間レイヤの数に少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャート。
【図１０】復号ピクチャバッファに記憶される１つまたは複数のレイヤおよびピクチャにおいて並べ替えられるピクチャの数に少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャート。
【図１１】ＶＰＳにおいてシグナリングされる仮想参照デコーダ（ＨＲＤ）パラメータに少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャート。
【図１２】ＶＰＳにおいてシグナリングされる拡張データに少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャート。
【発明を実施するための形態】
【００１３】
[0024]一般に、本開示は、ビデオパラメータセット（ＶＰＳ）を使用してビデオデータをコーディングすることについて説明する。ビデオデータは、複数のレイヤと、所与のレイヤ内のピクチャのシーケンスと、シーケンス内のピクチャと、ピクチャ内のスライスと、スライス内のブロック（たとえば、マクロブロックまたはコーディングツリーユニット）とを含むものとして階層的に分類され得る。シーケンスパラメータセット（ＳＰＳ）は、ピクチャのシーケンスのまれに変化するパラメータをシグナリングするために使用され得、ピクチャパラメータセット（ＰＰＳ）は、個々のピクチャのまれに変化するパラメータをシグナリングするために使用され得る。
【００１４】
[0025]本開示の技法によれば、ＶＰＳは、それぞれのレイヤにわたる複数のシーケンスのまれに変化するパラメータをシグナリングすることができる。すなわち、ＶＰＳは、様々なレイヤの時間的にコロケートされるシーケンスの組のパラメータを含み得る。様々なレイヤは、たとえば、マルチビュービデオデータの様々なビュー、様々な品質レイヤ、様々な空間解像レイヤ（ｓｐａｔｉａｌ  ｒｅｓｏｌｕｔｉｏｎ  ｌａｙｅｒ）、時間的スケーラブルレイヤ（ｔｅｍｐｏｒａｌｌｙ  ｓｃａｌａｂｌｅ  ｌａｙｅｒ）（すなわち、様々なフレームレートを可能にするレイヤ）などを含み得る。このように、１つのＶＰＳは、それぞれのレイヤの各々に共通のパラメータ（たとえば、それぞれのレイヤ内のそれぞれのシーケンス）をシグナリングするように、複数の異なるレイヤに与えられ得る。ビットストリームは、複数のレイヤの各々を含むものと言うことができ、それぞれのレイヤは、それぞれのサブビットストリームを形成することができる。さらに、サブビットストリームは、２つ以上のレイヤの組合せに対応し得る。
【００１５】
[0026]本開示は、ＶＰＳに含まれ得るデータの様々な例について説明する。そのようなデータは、いくつかの例では、対応するレイヤ内のサブレイヤの数（たとえば、サブレイヤの最大数）の表示を含み得る。たとえば、ＶＰＳは、時間レイヤの数および／または時間レイヤの最大数をシグナリングするデータ（たとえば、最上時間レイヤ識別子）を含み得る。
【００１６】
[0027]別の例として、ＶＰＳは、追加または代替で、ＳＰＳにおいて以前にシグナリングされた（すなわち、従来のＳＰＳにおいてシグナリングされた）任意のデータと実質的に同様のデータを含み得る。このように、ビットストリームの２つ以上のレイヤのシーケンスが、実質的に同様な、または同一のパラメータを含むとき、ビデオコーダは、異なるレイヤの間で様々なシーケンスについてのそれぞれのＳＰＳにおけるそのようなデータを冗長にコーディングするのではなく、複数のレイヤの複数のシーケンスについてのパラメータをシグナリングするためにＶＰＳをコーディングし得る。
【００１７】
[0028]ＶＰＳは、追加または代替として、ビデオ表現情報、仮想参照デコーダ（ＨＲＤ）パラメータ、および／またはビットストリーム制限情報などのビデオユーザビリティ情報（ＶＵＩ）を定義するデータを含み得る。ビットストリーム制限情報は、動きベクトルレンジと、復号ピクチャバッファ（ＤＰＢ）サイズ（たとえば、ＤＰＢによって保持されるピクチャの数に関する）と、並べ替えフレームの数（すなわち、復号順序から表示順序へ並べ替えられるフレームの数の表示）と、コーディングされたブロック（たとえば、マクロブロック（ＭＢ）またはコーディングツリーユニット）のサイズと、コーディングされたピクチャのサイズとに関する制限を含み得る。ＶＰＳは、時期ＨＥＶＣ規格への将来の規格または拡張によって拡張され得るように、１つまたは複数のＶＰＳ拡張用のデータをさらに与え得る。
【００１８】
[0029]図１は、ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをコーディングするための技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示すように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介してビデオデータを宛先デバイス１４に与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。
【００１９】
[0030]宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体１６は、符号化ビデオデータをソースデバイス１２から宛先デバイス１４に移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、符号化ビデオデータを宛先デバイス１４にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【００２０】
[0031]いくつかの例では、符号化データは、出力インターフェース２２からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介してストレージデバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【００２１】
[0032]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：dynamic adaptive streaming over HTTP）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【００２２】
[0033]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、ビデオデータの１つまたは複数のレイヤのパラメータセットおよびＮＡＬユニットをコーディングするための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【００２３】
[0034]図１の図示のシステム１０は一例にすぎない。ビデオデータの１つまたは複数のレイヤのパラメータセットおよびＮＡＬユニットをコーディングするための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコーディングされたビデオデータを生成する、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話のための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートすることができる。
【００２４】
[0035]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き携帯電話またはビデオ電話を形成することができる。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。各々の場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータで生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
【００２５】
[0036]コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたは有線ネットワーク送信などの時間媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非時間的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、たとえば、ネットワーク送信を介して、ソースデバイス１２から符号化されたビデオデータを受信し、宛先デバイス１４に符号化されたビデオデータを与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化されたビデオデータを受信し、その符号化されたビデオデータを含むディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
【００２６】
[0037]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコーディングユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００２７】
[0038]ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ  １０、アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格などの、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３がある。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。
【００２８】
[0039]ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４（ＡＶＣ）規格は、Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｔｅａｍ（ＪＶＴ）として知られる共同パートナーシップの成果として、ＩＳＯ／ＩＥＣ  Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）とともにＩＴＵ−Ｔ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＶＣＥＧ）によって策定された。いくつかの態様では、本開示で説明する技法は、一般にＨ．２６４規格に準拠するデバイスに適用することができる。Ｈ．２６４規格は、ＩＴＵ−Ｔ研究グループによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４「Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  ｆｏｒ  ｇｅｎｅｒｉｃ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ」に記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ぶ。Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｔｅａｍ（ＪＶＴ）はＨ．２６４／ＭＰＥＧ−４  ＡＶＣへの拡張に取り組み続けている。
【００２９】
[0040]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非時間的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。
【００３０】
[0041]ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。
【００３１】
[0042]一般に、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマとクロマの両方のサンプルを含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ）に分割され得ることを記載する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。一般に、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
【００３２】
[0043]４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵをリーフＣＵとも呼ぶ。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵをリーフＣＵとも呼ぶ。
【００３３】
[0044]ＣＵは、ＣＵがサイズ差異を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、４つの子ノード（サブＣＵとも呼ばれる）に分割され得、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コーディングビットストリームに関連するシンタックスデータは、最大ＣＵ深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズも定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ：smallest coding unit）をも定義し得る。本開示では、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵ、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。
【００３４】
[0045]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ：prediction unit）および変換ユニット（ＴＵ：transform unit）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルを有するツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。
【００３５】
[0046]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従った変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用して、より小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、量子化され得る変換係数を生成するために変換され得る。
【００３６】
[0047]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含むことができる。一般に、ＰＵは、対応するＣＵの全部または一部に対応する空間的エリアを表し、そのＰＵ用の参照サンプルを取り出すためのデータを含むことができる。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのデータは、ＰＵに対応するＴＵのイントラ予測モードを記述するデータを含み得る、残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、もしくはリストＣ）を記述し得る。
【００３７】
[0048]１つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上記で説明したように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらに、さらなるサブＴＵに分割され得る。ＴＵがさらに分割されないとき、そのＴＵはリーフＴＵと呼ばれ得る。概して、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、概して、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵはＰＵよりも大きくまたは小さくなり得る。イントラコーディングの場合、ＰＵは、同じＣＵについて対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。
【００３８】
[0049]さらに、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。概して、本開示では、特に明記しない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
【００３９】
[0050]ビデオシーケンスは、一般に、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、概して、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、サイズを固定することも変更することもでき、指定のコーディング規格に応じてサイズが異なることがある。
【００４０】
[0051]一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ  ＰＵと下部の２Ｎ×１．５Ｎ  ＰＵとで水平方向に区分された２Ｎ×２Ｎ  ＣＵを指す。
【００４１】
[0052]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６ピクセルまたは１６by１６ピクセルを指すために互換的に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここでＮは非負整数値を表す。ブロック内のピクセルは行と列で構成することができる。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備えてよく、ただし、Ｍは必ずしもＮに等しいとは限らない。
【００４２】
[0053]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。
【００４３】
[0054]変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ得、ただし、ｎはｍよりも大きい。
【００４４】
[0055]量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【００４５】
[0056]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルのための可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率判断は、シンボルに割り当てられるコンテキストに基づき得る。
【００４６】
[0057]本開示の技法によれば、ビデオエンコーダ２０またはビデオデコーダ３０などのビデオコーダは、ビデオデータの１つまたは複数のレイヤのビデオパラメータセット（ＶＰＳ）をコーディングし、ＶＰＳに少なくとも部分的に基づいてビデオデータの１つまたは複数のレイヤをコーディングするように構成され得る。以下でより詳細に説明する表２および表５は、ＶＰＳの例示的なシンタックス要素の組を含む。ビデオデータの１つまたは複数のレイヤの各々は、ＶＰＳ、すなわち同じＶＰＳを参照し得る。言い換えれば、ＶＰＳは、共通の組のビデオデータのすべてのレイヤ、たとえば、すべてのＳＶＣレイヤ、および／またはＭＶＣビデオデータのすべてのビューに適用され得る。
【００４７】
[0058]ＶＰＳは、様々な情報カテゴリーを含み得る。たとえば、ＶＰＳは、サンプル次元カウンタ記述部（ＳＤＣＤ：sample dimension counter description）を含み得る。すなわち、各次元に関して、ビデオコーダは、１組のインデックスをシグナリングし得る。考えられる次元は、ｃｎｔ＿ｐ、すなわちコード化ビデオシーケンスに含まれる優先レイヤの数と、ｃｎｔ＿ｄ、すなわちビットストリーム内の異なる従属レイヤ、同じ空間解像度およびビット深度を有する複数のレイヤのどれくらいの数が異なる従属レイヤに属しているかと、ｃｎｔ＿ｔ、すなわちビットストリーム内の時間レイヤの数と、ｃｎｔ＿ｑ、すなわちビットストリーム内の任意の従属レイヤに関する品質レイヤの最大数と、ｃｎｔ＿ｖ、すなわちビューの最大数とを含む。ビット深度設定値は、８ビットまたは１２ビットを含むことができ、異なる色成分により異なる可能性がある。クロマサンプルフォーマットは、４:０:０、４:２:０、および４:４:４を含み得る。
【００４８】
[0059]ＶＰＳは、特性マッピングに対するサンプルインデックスも含み得る。各々の次元に関して、特性インジケータが、０からサンプル次元カウンタマイナス１までの範囲のインデックスに等しくない場合、各特性インデックスの特性インジケータを指定するために、ループが導入され得る。マッピングは、各従属インデックスに関して、特定のビット深度値および特定のクロマサンプルフォーマットを有する特定の空間解像度を含み得る。デコーダにおいて常に、固定された参照用テーブルが存在する場合、たとえば、０が４：２：０に対応し、１が４：４：４に対応し、２が４：０：０に対応し得る場合、これは省略され得ることに留意されたい。マッピングは、追加または代替として、各時間インデックス／ｉｄについて特定のフレームレートまたは平均フレームレートと、各ビューインデックスについて特定のビューｉｄと、各ビット深度インデックスについてルーマおよびクロマの特定のビット深度値のぺアと、各クロマサンプルフォーマットについて特定のクロマサンプルフォーマットインジケータと、を含み得る。
【００４９】
[0060]ＶＰＳは、次のｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ１と、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ１と、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｌｉｃｅ＿ｆｌａｇと、ｐｃｍ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｄｉｓａｂｌｅ＿ｆｌａｇと、ｔｅｍｐｏｒａｌ＿ｉｄ＿ｎｅｓｔｉｎｇ＿ｆｌａｇと、１つまたは複数のタイルに関連のシンタックス要素と、ｃｈｒｏｍａ＿ｐｒｅｄ＿ｆｒｏｍ＿ｌｕｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、ｓａｍｐｌｅ＿ａｄａｐｔｉｖｅ＿ｏｆｆｓｅｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、ａｄａｐｔｉｖｅ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、ｉｎｔｅｒ＿４×４＿ｅｎａｂｌｅｄ＿ｆｌａｇなどの、制御パラメータおよびツール有効化（enabling）／無効化(disabling)フラグも含み得る。
【００５０】
[0061]ＶＰＳは、１つまたは複数のオペレーションポイント記述部も含み得る。オペレーションポイントは、概して、ビットストリームに含まれるビデオデータのビューの総数のサブセットについて説明する。オペレーションポイントは、出力を目的とされる特定の数のビューと、復号、出力、またはその両方のときに参照用に使用され得る他のビューとを含み得る。ビットストリームは、オペレーションポイント記述部によって説明される１つまたは複数のオペレーションポイントを含み得る。オペレーションポイント記述部は、最大オペレーションポイントの数、異なるレイヤもしくはビューの間の従属関係、各オペレーションポイントに関するプロファイルおよびレベル、各オペレーションポイントに関するビットレート、オペレーションポイント間の従属関係、各オペレーションポイントに関する他の制限、各オペレーションポイントに関するビデオユーザビリティ情報（ＶＵＩ）もしくはＶＵＩの一部、および／または各レイヤもしくはビューに関するＶＵＩもしくはＶＵＩの一部を定義する情報を含み得る。追加または代替として、オペレーションポイント記述部は、各オペレーションポイントに関するオペレーションポイントビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニット表示を含み得る。いくつかの例では、オペレーションポイントＶＣＬ  ＮＡＬユニット表示は、各次元に関する３つの可能な選択肢、すなわち（１）特定のインデックス値：たとえば、空間解像度の場合、クロマサンプルフォーマットのビット深度の場合；（２）インデックス値の範囲：たとえば、時間レイヤの場合には０から最上時間レイヤｉｄまで、品質レイヤの場合には０から最高品質レイヤｉｄまで；または（３）インデックス値のリスト、たとえば、ビューの場合にはビューインデックス値のリスト、を含み得る。
【００５１】
[0062]いくつかの例では、ＶＰＳは、ビットストリームのレイヤのうちの時間レイヤの最大数を示すデータを含み得る。すなわち、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するビットストリームの時間レイヤの最大数を示すデータを含むＶＰＳをコーディングするように構成され得る。たとえば、ビデオエンコーダ２０は、時間レイヤの最大数を決定し、決定された時間レイヤの最大数を表すデータを含むようにＶＰＳを符号化し得るが、ビデオデコーダ３０は、時間レイヤの最大数を決定するためにＶＰＳを復号し得る。ビデオエンコーダ２０およびビデオデコーダ３０は、時間レイヤの決定された最大数に基づいてビットストリームのビデオデータをコーディングすることもできる。たとえば、時間レイヤの最大数は、様々な時間レイヤを表すのに必要な時間識別子の数に影響を及ぼし得る。別の例として、時間レイヤの最大数は、たとえばピクチャ順序カウント（ＰＯＣ）値を使用してビデオエンコーダ２０およびビデオデコーダ３０が参照ピクチャ識別子をコーディングする方法に影響を及ぼし得る。
【００５２】
[0063]さらに別の例として、ビデオエンコーダ２０およびビデオデコーダ３０は、特定の時間レイヤのデータを、同じ時間レイヤを含み、かつ、同じ時間レイヤまでの参照データのみを使用して、コーディングするように構成され得る。言い換えれば、ビデオエンコーダ２０およびビデオデコーダ３０は、より上位の時間レイヤの参照データを使用して特定の時間レイヤのデータをコーディングすることを避けるように構成され得る。このように、ビデオデコーダ３０は、サブビットストリーム抽出後でさえ、所与の組の時間レイヤのビデオデータを正確に復号することを確実にされ得る。すなわち、サブビットストリーム抽出が実行される場合、抽出されたサブビットストリームの最上位レイヤよりも上のいくつかの時間レイヤは、参照のために利用可能ではない。現在のレイヤにおけるまたは現在のレイヤよりも下のレイヤのデータのみを参照して各時間レイヤのデータをコーディングすることによって、そうでなければ、サブビットストリーム抽出の結果として失われるであろう、より上位のレイヤからのデータに依存する特定のレイヤにおけるデータを有することに起因するエラーを避けることができる。
【００５３】
[0064]いくつかの例では、ＶＰＳは、追加または代替として、ビットストリームの１つまたは複数のレイヤにおいて並べ替えられるピクチャの数、および／または復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数のいずれかまたは両方を示すデータを含む。上述のように、そのようなデータは、ビットストリーム制限情報と呼ばれ得る。したがって、宛先デバイス１４は、ビデオデコーダ３０の性能を決定し、対応するビットストリームがビデオデコーダ３０によって復号されるのに適するかどうか、または宛先デバイス１４が（たとえば、コンテンツの複数のバージョンが利用可能であると仮定すれば、ネットワークベースコンテンツプロバイダから）代替のコンテンツを選択すべきかどうかを決定するためにビットストリーム制限情報を使用し得る。
【００５４】
[0065]さらに、ビデオエンコーダ２０およびビデオデコーダ３０は、ビデオデータのコーディングの間、ビットストリーム制限情報を使用することができる。たとえば、ビデオエンコーダ２０は、ビットストリーム制限情報が破られないことを確実にし得る。すなわち、高々Ｎ個のピクチャまでしかＤＰＢに記憶されるべきでないとビットストリーム制限情報が示すと仮定すると、ビデオエンコーダ２０は、所与の時間に１つまたは複数の参照ピクチャリストの任意の組合せにただＮ個のピクチャが含まれることを確実にし得る。別の例として、ピクチャが高々Ｍ個のピクチャだけシフトされるべきであるとピクチャ並べ替え情報が示すと仮定すると、ビデオエンコーダ２０は、ピクチャがＭ個のピクチャよりも多くシフトされないことを確実にし得る。この方法におけるピクチャのシフトは、概して、ピクチャの復号順序と表示順序との間の差に対応する。同様に、ビデオデコーダ３０は、たとえば、ＤＰＢフラッシングなどのＤＰＢ管理を実行するために、コーディング中にそのような情報を使用し得る。ビデオエンコーダ２０およびビデオデコーダ３０は、参照ピクチャ識別子値をコーディングするときのＤＰＢに記憶されるピクチャの最大数、および／または並べ替えられるピクチャの数などのビットストリーム制限情報も使用し得る。
【００５５】
[0066]いくつかの例では、ＶＰＳは、追加または代替として、仮想参照デコーダ（ＨＲＤ）パラメータを示すデータを含む。ＨＲＤパラメータは、たとえば、データがコーディングピクチャバッファ（ＣＰＢ）から除去されべき時刻（タイム）について記述するデータを含む。ビデオデコーダ３０などのデコーダでは、ＣＰＢは、データが復号の準備ができるまでコード化ビデオデータが記憶されるバッファを表す。ビデオデコーダ３０などのデコーダは、たとえば、インター予測データのために、また復号順序から表示順序へのピクチャの並べ替えのために参照データとして使用される復号ビデオデータが記憶される復号ピクチャバッファ（ＤＰＢ）も含み得る。
【００５６】
[0067]ＨＲＤパラメータは、特定のピクチャがＣＰＢから除去され、復号されるべきときを示すデータを含み得る。したがって、ビデオエンコーダ２０は、ピクチャがＣＰＢから除去され、復号され得るときを示すためにＶＰＳのＨＲＤパラメータを符号化し得、一方、ビデオデコーダ３０は、ＣＰＢからピクチャをいつ除去すべきかを決定するためにＶＰＳのＨＲＤパラメータを復号し得る。同様に、ビデオエンコーダ２０およびビデオデコーダ３０は、たとえば、ＨＲＤパラメータによって示されるコーディング順序で、ＨＲＤパラメータに従ってピクチャをコーディングし得る。このように、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＨＲＤパラメータを含むＶＰＳをコーディングし、ＨＲＤパラメータに少なくとも部分的に基づいてＶＰＳに対応するビデオデータをコーディングするように構成され得る。
【００５７】
[0068]ＶＰＳは、たとえば１つまたは複数の追加のコーディングツール用のデータを与えるために、ＶＰＳが拡張されてきたかどうかを示す拡張データも含み得る。そのようなコーディングツールは、たとえばＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣまたは今度のＨＥＶＣ規格などの、対応するビデオコーディング規格のツールとは異なるツールである可能性がある。さらに、そのようなコーディングツールは、コンフィギュレーションデータを必要とし得る。このコンフィギュレーションデータは、ＶＰＳの拡張データ内に与えられ得る。このように、そのようなコーディングツールを使用してビデオデータをコーディングするとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、拡張データが存在するかどうかを示すＶＰＳと、そうであれば、ＶＰＳの拡張データとをコーディングすることができる。さらに、そのような拡張データが存在するとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、拡張データを使用してビデオデータをコーディングするために対応するコーディングツールを実行することができる。
【００５８】
[0069]様々なビデオコーディング規格は、エラーのないビットストリームの対応するシンタックスと、セマンティクスと、復号プロセスとを定義し、そのいずれもいくつかのプロファイルまたはレベルに準拠する。ビデオコーディング規格は、概して、エンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダの規格に準拠することを保証することを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびブロック処理レートに関連するデコーダメモリおよび計算などの、デコーダリソース消費の制限に対応する。プロファイルはｐｒｏｆｉｌｅ＿ｉｄｃ（プロファイルインジケータ）値でシグナリングされ得るが、レベルはｌｅｖｅｌ＿ｉｄｃ（レベルインジケータ）値でシグナリングされ得る。本開示の技法によれば、プロファイルおよびレベル情報は、上記で説明したように、オペレーションポイント記述部において指定され得る。
【００５９】
[0070]いくつかの例では、ビットストリームの各レイヤまたはビューは、ビデオパラメータセット（ＶＰＳ）を参照し、レイヤシーケンスパラメータセット（ＬＰＳ）は、各レイヤに関してアクティブであり得る。ＬＰＳは、設計においてＶＰＳを参照することによってできる限り軽量に保たれ得る。ＬＰＳは、以下で説明する情報のいずれかまたはすべてを含み得る。ＬＰＳは、各次元に関して、各次元のインデックスを示すサンプル次元表示を含み得る。たとえば、ＶＰＳにおいて、空間解像度０に対するインデックスが３２０×２４０の空間特性に割り当てられ、空間解像度１に対するインデックスが６４０×４８０の空間特性に割り当てられ、現在のレイヤに６４０×４８０の解像度を与えられる場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、現在のレイヤに関して１の値を有するシンタックス要素をコーディングし得る。すなわち、ビデオエンコーダ２０は、シンタックス要素が６４０×４８０の解像度を指定するために１の値をシグナリングし得、ビデオデコーダ３０は、１の値を有するシンタックス要素を含む現在のレイヤが、シンタックス要素に関する１の値に基づいて６４０×４８０の解像度を有すると決定し得る。
【００６０】
[0071]ＬＰＳは、制御パラメータおよびツール有効化／無効化フラグも含み得る。たとえば、制御パラメータおよびツール有効化／無効化フラグは、次のｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ１と、ｐｃｍ＿ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ１と、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｌｉｃｅ＿ｆｌａｇと、ｐｃｍ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｄｉｓａｂｌｅ＿ｆｌａｇと、１つまたは複数のタイル関連のシンタックス要素と、ｃｈｒｏｍａ＿ｐｒｅｄ＿ｆｒｏｍ＿ｌｕｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、ｓａｍｐｌｅ＿ａｄａｐｔｉｖｅ＿ｏｆｆｓｅｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、ａｄａｐｔｉｖｅ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇと、コーディングユニット（ＣＵ）ハイアラーキとを含み得る。
【００６１】
[0072]ＬＰＳは、スライス、スライスのグループ、１つのピクチャ、またはいくつかのピクチャに適用する他のタイプのパラメータセットの情報をさらに含み得る。これらのパラメータセットの各々は、特定のピクチャパラメータセット（ＰＰＳ）を参照し得る。
【００６２】
[0073]ビデオエンコーダ２０およびビデオデコーダ３０などのビデオコーダは、ＰＰＳがＬＰＳまたはＶＰＳを参照しないことを確実にし、および／または決定するように構成され得る。したがって、ビデオコーダは、ビットストリームの各ＰＰＳがＬＰＳまたはＶＰＳを参照しないことを確実にすることができる。ＰＰＳのパーシング（parsing）は、独立している可能性がある。ＰＰＳがＶＰＳまたはＬＰＳと同じシンタックス要素のうちの１つまたは複数を含むとき、ＰＰＳのシンタックス要素は、ＶＰＳまたはＬＰＳのシンタックス要素を上書きし得る。
【００６３】
[0074]ビデオコーダは、すべてのパラメータセットを共にグルーピングするグルーピングパラメータセット（ＧＰＳ）をコーディングするようにさらに構成され得る。ビデオコーダは、各々が個々のＧＰＳ識別子（ｉｄ）を有するＧＰＳ内の複数の異なるグループをコーディングすることができる。ＧＰＳ内のグループの各々は、パラメータセットの異なる組合せを含み得る。このように、スライスヘッダは、対応するＧＰＳ  ｉｄへの参照のみを含む必要があり、パラメータセットのタイプの表示を含む必要はない。また、２０１２年１月２５日に出願された米国仮特許出願第６１／５９０，７０２号は、様々なタイプのパラメータセットが共にグルーピングされ、パラメータセットグルーピングのＩＤ  ＲＢＳＰのみがスライスヘッダにおいてシグナリングされる技法についてより詳細に記載する。
【００６４】
[0075]上記で説明したように、ビデオエンコーダ２０またはビデオデコーダ３０などのビデオコーダは、ビデオパラメータセットおよび／またはグルーピングパラメータセットをコーディングするように構成され得る。ビデオパラメータセットの例については図５を参照してより詳細に説明されるが、グルーピングパラメータセットの例については図６を参照してより詳細に説明される。
【００６５】
[0076]ビデオエンコーダ２０は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびＧＯＰベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送り得る。ＧＯＰシンタックスデータは、それぞれのＧＯＰ中のいくつかのフレームを記述し得、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化／予測モードを示し得る。
【００６６】
[0077]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
【００６７】
[0078]図２は、ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびＮＡＬユニットをコーディングするための技法を実装し得るビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
【００６８】
[0079]図２に示されるように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、今度は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、区分ユニット４８とを含む。ビデオブロックの復元のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。復元されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングする、デブロッキングフィルタ（図２に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは一般に、加算器６２の出力をフィルタリングすることになる。また、デブロッキングフィルタに加えて追加のフィルタ（ループ内またはループ後）が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、（ループ内フィルタとして）加算器５０の出力をフィルタ処理し得る。
【００６９】
[0080]符号化プロセス中に、ビデオエンコーダ２０はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的な予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は代替的に、空間的な予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
【００７０】
[0081]その上、区分ユニット４８は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、さらに、ＬＣＵをサブＣＵに区分することを示す４分木データ構造を生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。
【００７１】
[0082]モード選択ユニット４０は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラまたはインターのうちの１つを選択することができ、残差ブロックデータを生成するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器５０に与え、参照フレームとして使用するための符号化されたブロックを復元するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器６２に与える。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット５６に与える。
【００７２】
[0083]動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または他のコード化ユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるブロックにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
【００７３】
[0084]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵについての動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得、それらの参照ピクチャリストの各々は、参照ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。
【００７４】
[0085]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。現在のビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、参照ピクチャリストのうちの１つにおいて動きベクトルが指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明するように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
【００７５】
[0086]イントラ予測ユニット４６は、上記で説明したように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
【００７６】
[0087]たとえば、イントラ予測ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのひずみおよびレートから比率を計算し得る。
【００７７】
[0088]ブロック用のイントラ予測モードを選択した後、イントラ予測ユニット４６は、ブロック用に選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット５６に提供することができる。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ２０は、（コードワードマッピングテーブルとも呼ばれる）複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブルと、様々なブロック用の符号化コンテキストの定義と、最も可能性のある（most probable）最確イントラ予測モードの指示とを含む送信されたビットストリーム構成データの中に、コンテキストの各々について使用する、イントラ予測モードインデックステーブルと修正されたイントラ予測モードインデックステーブルとを含めることができる。
【００７８】
[0089]ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって、残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。
【００７９】
[0090]いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。
【００８０】
[0091]量子化の後、エントロピー符号化ユニット５６は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングの後、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されるか、または後で送信するかもしくは取り出すためにアーカイブすることができる。
【００８１】
[0092]逆量子化ユニット５８および逆変換ユニット６０は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックを参照ピクチャメモリ６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６２は、再構成された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ６４に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。
【００８２】
[0093]ビデオエンコーダ２０は、本開示の技法によれば、ビデオパラメータセット（ＶＰＳ）、レイヤパラメータセット（ＬＰＳ）、および／またはグルーピングパラメータセット、ならびに、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、適合パラメータセット（ＡＰＳ：adaptation parameter set）、または他のそのようなシグナリングデータ構造をコーディングするようにさらに構成され得る。より詳細には、エントロピー符号化ユニット５６は、これらのデータ構造のいずれかまたはすべてをコーディングするように構成され得る。これらの様々なデータ構造のパラメータがコーディング性能に影響を及ぼし得る範囲で、モード選択ユニット４０は、適切なパラメータを選択し、たとえばＶＰＳ内に含むためにエントロピー符号化ユニット５６にパラメータを渡すことができる。時間レイヤの数、並べ替えられるピクチャの数、および復号ピクチャバッファに記憶されるピクチャの数などの他のパラメータは、ユーザ、たとえば管理者によって選択され得る。他の例では、ＨＲＤパラメータなどのいくつかのパラメータは、符号化プロセスを介して生じる可能性がある。
【００８３】
[0094]エントロピー符号化ユニット５６は、本開示によって説明されるデータの様々なタイプのいずれかまたはすべてを含むようにＶＰＳをコーディングすることができる。ビデオエンコーダ２０は、ＶＰＳのパラメータに従ってデータを符号化することもできる。より詳細には、ビデオエンコーダ２０は、ＶＰＳのパラメータに従ってＶＰＳが対応するビデオデータの１つまたは複数のレイヤのうちのピクチャのシーケンスをコーディングすることができる。
【００８４】
[0095]このように、図２のビデオエンコーダ２０は、各々がビデオパラメータセット（ＶＰＳ）を参照する、ビデオデータの１つまたは複数のレイヤに関するＶＰＳをコーディングし、ＶＰＳに少なくとも部分的に基づいてビデオデータの１つまたは複数のレイヤをコーディングするように構成されたビデオエンコーダの例を表す。
【００８５】
[0096]概してビデオエンコーダに関して説明されるが、ＶＰＳの符号化は、他のデバイス、たとえばメディアアウェア（media-aware）ネットワーク要素（ＭＡＮＥ）によって実行され得る。ＭＡＮＥは、ソースデバイス（図１のソースデバイス１２など）と宛先デバイス（宛先デバイス１４など）との間のネットワーク要素に対応する。ＭＡＮＥは、本開示の技法に従ってＶＰＳを符号化するように構成され得る。ＭＡＮＥは、ＭＡＮＥによって受信される他のデータ構造のデータ、たとえばシーケンスパラメータセットを使用してＶＰＳを生成することができる。
【００８６】
[0097]図３は、ビデオデータの１つまたは複数のレイヤ用のパラメータセットおよびＮＡＬユニットをコーディングするための技法を実装し得るビデオデコーダ３０の一例を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照ピクチャメモリ８２と、加算器８０とを含む。参照ピクチャメモリ８２は、「復号ピクチャバッファ」またはＤＰＢとも呼ばれ得る。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明した符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
【００８７】
[0098]復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。
【００８８】
[0099]ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた（すなわち、Ｂ、ＰまたはＧＰＢ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ８２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト０およびリスト１を構成し得る。
【００８９】
[0100]動き補償ユニット７２は、動きベクトルと他のシンタックス要素とを解析する(parse)ことによって現在ビデオスライスのビデオブロックについての予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数についての構成情報と、スライスの各インター符号化ビデオブロックについての動きベクトルと、スライスの各インターコード化ビデオブロックについてのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報と、を決定するために、受信されたシンタックス要素のいくつかを使用する。
【００９０】
[0101]動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット７２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。
【００９１】
[0102]逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット８０によって復号された量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、ビデオスライス中の各ビデオブロックについてビデオデコーダ３０によって計算される量子化パラメータＱＰＹを使用して量子化の程度を決定し、同様に、適用すべき逆量子化の程度を決定することを含み得る。逆変換ユニット７８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換処理を変換係数に適用して、ピクセル領域において残差ブロックを生成する。
【００９２】
[0103]動き補償ユニット７２が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャの復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ８２に記憶される。参照ピクチャメモリ８２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。
【００９３】
[0104]本開示の技法によれば、ビデオデコーダ３０は、本開示の技法によれば、ビデオパラメータセット（ＶＰＳ）、レイヤパラメータセット（ＬＰＳ）、および／またはグルーピングパラメータセット、ならびに、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、適合パラメータセット（ＡＰＳ）、または他のそのようなシグナリングデータ構造を復号することができる。より詳細には、エントロピー復号ユニット７０は、これらのデータ構造のいずれかまたはすべてを復号するように構成され得る。これらの様々なデータ構造を復号することによって、エントロピー復号ユニット７０は、対応するビデオデータを復号するために使用されるパラメータを決定することができる。たとえば、ビデオデコーダ３０は、復号されたＶＰＳのパラメータを使用して１つまたは複数のレイヤのビデオデータの対応するシーケンスを復号することができる。
【００９４】
[0105]図３には示されないが、ビデオデコーダ３０は、コーディングピクチャバッファ（ＣＰＢ）をさらに含み得る。ＣＰＢは、通常、エントロピー復号ユニット７０の前に与えられる。代替として、ＣＰＢは、一次記憶のためにエントロピー復号ユニット７０に、または、エントロピー復号データを、そのようなデータが復号されるまで記憶するためにエントロピー復号ユニット７０の出力部に、結合され得る。概して、ＣＰＢは、たとえばビデオデコーダ３０が復号されたＶＰＳから抽出し得るＨＲＤパラメータによって示されるように、コード化ビデオデータが復号されるまでコード化ビデオデータを記憶する。同様に、ビデオデコーダ３０の他の要素は、たとえばＶＰＳを使用してビデオデータを復号するように構成され得る。たとえば、ビデオデコーダ３０は、様々な時間レイヤのピクチャの時間識別子、参照ピクチャメモリ８２（ＤＰＢを表す）で並べ替えられる、および／または、記憶されるピクチャの数を示すデータを復号し得る。
【００９５】
[0106]さらに、ビデオデコーダ３０は、ビデオコーディング規格の拡張によって与えられる様々なコーディングツールに応じてビデオデータを処理するための追加の処理ユニットを含み得る。代替として、図３に示されるビデオデコーダ３０の既存の要素は、そのような拡張されたコーディングツールを実行するように構成され得る。エントロピー復号ユニット７０はＶＰＳ拡張データを復号し、拡張によって与えられるコーディングツールを実行するように構成されたユニットにそのような拡張データを与えるように構成され得る。
【００９６】
[0107]このように、図３のビデオデコーダ３０は、ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）をコーディングし、ここにおいて当該１つまたは複数のレイヤのそれぞれはＶＰＳを参照し、当該ＶＰＳに少なくとも部分的に基づいてビデオデータの当該１つまたは複数のレイヤをコーディングするように構成されたビデオデコーダの例を表す。
【００９７】
[0108]概してビデオデコーダに関して説明されるが、ＶＰＳの復号は、他のデバイス、たとえばメディアアウェアネットワーク要素（ＭＡＮＥ）によって実行され得る。ＭＡＮＥは、本開示の技法に従ってＶＰＳを復号するように構成され得る。ＭＡＮＥは、ＶＰＳのデータを使用して、１つまたは複数のシーケンスパラメータセットなどの他のパラメータセットデータをさらに生成することができる。このように、ＭＡＮＥは、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣなどの以前の規格との下位互換性を与えることができる。
【００９８】
[0109]図４は、例示的なＭＶＣの予測パターンを示す概念図である。マルチビュービデオコーディング（ＭＶＣ）は、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣの拡張である。同様の技法が、ＨＥＶＣに適用され得る。図４の例では、（ビューＩＤ「Ｓ０」〜「Ｓ７」を有する）８つのビューが示され、各ビューについて１２個の時間ロケーション（「Ｔ０」〜「Ｔ１１」）が示されている。すなわち、図４中の各行はビューに対応し、各列は時間ロケーションを示す。
【００９９】
[0110]図４に、マルチビュービデオコーディング用の典型的なＭＶＣ予測（各ビュー内のインターピクチャ予測とインタービュー予測の両方を含む）構造が示され、予測参照のために矢印の始点のオブジェクトを使用して矢印の終点のオブジェクトへの矢印によって予測が示される。ＭＶＣでは、ビュー間予測は視差動き補償によってサポートされ、視差動き補償は、Ｈ．２６４／ＡＶＣ動き補償のシンタックスを使用することができるが、異なるビュー中のピクチャが参照ピクチャとして使用されることを可能にする。
【０１００】
[0111]２つのビューのコーディングは、ＭＶＣによってサポートされる可能性もあり、ＭＶＣの利点の１つは、ＭＶＣエンコーダが３Ｄビデオ入力として３つ以上のビューをとらえることができ、ＭＶＣデコーダがそのようなマルチビュー表現を復号することができることである。したがって、ＭＶＣデコーダを含む任意のレンダラは、３つ以上のビューを含む３Ｄビデオコンテンツを受信するように構成され得る。
【０１０１】
[0112]ＭＶＣがＨ．２６４／ＡＶＣデコーダによって復号可能である、いわゆるベースビューを有し、また、ステレオビューペアがＭＶＣによってサポートされ得るが、ＭＶＣの利点は、ＭＶＣが、３Ｄビデオ入力として２より多いビューを使用し、複数のビューによって表されるこの３Ｄビデオを復号する例をサポートすることができることである。ＭＶＣデコーダを有するクライアントのレンダラは、複数のビューを用いて３Ｄビデオコンテンツを予想し得る。
【０１０２】
[0113]典型的なＭＶＣ復号順序は、タイムファーストコーディングと呼ばれる。アクセスユニットは、１つの出力時間インスタンスのためのすべてのビューのコーディングされたピクチャを含み得る。たとえば、時刻Ｔ０のピクチャの各々は、共通のアクセスユニットに含まれ得るが、時刻Ｔ１のピクチャの各々は、第２の共通のアクセスユニットに含まれ得る、など。復号順序は、出力または表示順序と必ずしも同一とは限らない。
【０１０３】
[0114]図４中のフレームは、対応するフレームがイントラコーディングされる（すなわち、Ｉフレームである）のか、一方向に（すなわち、Ｐフレームとして）インターコーディングされるのか、複数の方向に（すなわち、Ｂフレームとして）インターコーディングされるのかを指定する、文字を含む影付きブロックを使用して、図４中の各行と各列との交差部において示されている。概して、予測は矢印によって示され、ここで矢印の終点のフレームは、予測参照のために矢印の始点のオブジェクトを使用する。たとえば、時間位置Ｔ０にあるビューＳ２のＰフレームは、時間位置Ｔ０にあるビューＳ０のＩフレームから予測される。
【０１０４】
[0115]シングルビュービデオ符号化の場合と同様に、マルチビュービデオコーディングビデオシーケンスのフレームは、異なる時間ロケーションにおけるフレームに関して予測符号化され得る。たとえば、時間ロケーションＴ１におけるビューＳ０のｂフレームは、時間ロケーションＴ０におけるビューＳ０のＩフレームからそのｂフレームに向けられた矢印を有し、その矢印は、ｂフレームがＩフレームから予測されることを示す。しかしながら、さらに、マルチビュービデオ符号化のコンテキストにおいて、フレームは、ビュー間予測され得る。すなわち、ビュー成分は、参照のために他のビュー中のビュー成分を使用することができる。ＭＶＣでは、たとえば、別のビュー中のビュー成分がインター予測参照であるかのように、ビュー間予測が実現される。潜在的なビュー間参照は、シーケンスパラメータセット（ＳＰＳ）ＭＶＣ拡張においてシグナリングされ、インター予測またはビュー間予測参照のフレキシブルな順序付けを可能にする参照ピクチャリスト構成プロセスによって変更され得る。
【０１０５】
[0116]Ｈ．２６４／ＡＶＣのＭＶＣ拡張では、一例として、ビュー間予測は視差動き補償によってサポートされ、視差動き補償は、Ｈ．２６４／ＡＶＣ動き補償のシンタックスを使用するが、異なるビュー中のピクチャが参照ピクチャとして使用されることを可能にする。２つのビューのコーディングは、ＭＶＣによってサポートされ得るが、概して、立体視ビューと呼ばれる。ＭＶＣの利点の１つは、ＭＶＣエンコーダが３Ｄビデオ入力として３つ以上のビューをとらえることができ、ＭＶＣデコーダがそのようなマルチビュー表現を復号することができることである。したがって、ＭＶＣデコーダを含む任意のレンダリングデバイスは、３つ以上のビューを含む３Ｄビデオコンテンツを予想し得る。
【０１０６】
[0117]ＭＶＣでは、ビュー間予測（ＩＶＰ）は、同じアクセスユニット（すなわち、同じ時間インスタンスを有する）内の画像間で可能になる。アクセスユニットは、概して共通の時間インスタンスのすべてのビュー成分（たとえば、すべてのＮＡＬユニット）を含むデータユニットである。したがって、ＭＶＣにおいて、ビュー間予測は、同じアクセスユニットにおけるピクチャ間で許可される。非ベースビューのうちの１つの中のピクチャをコーディングするとき、ピクチャが異なるビュー中にあるが同じ時間インスタンス（たとえば、同じＰＯＣ値、したがって同じアクセスユニットにおいて）を伴う場合、そのピクチャは参照ピクチャリストに追加され得る。ビュー間予測の参照ピクチャは、任意のインター予測の参照ピクチャと同様に、参照ピクチャリストの任意の位置に置かれ得る。
【０１０７】
[0118]マルチビュービデオコーディングのコンテキストでは、２種類の動きベクトルが存在する。一方は、時間参照ピクチャを指す通常の動きベクトルであり、対応するインター予測モードは、動き補償予測（ＭＣＰ：motion compensated prediction）と呼ばれる。他方は、異なるビュー内のピクチャを指す視差動きベクトルであり、対応するビュー間予測モードは、視差補償予測（ＤＣＰ：disparity-compensation prediction）と呼ばれる。
【０１０８】
[0119]従来のＨＥＶＣでは、動きパラメータの予測に関する２つのモードが存在し、一方はマージモードであり、他方は高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）である。マージモードでは、動きパラメータ（参照ピクチャおよび動きベクトル）の候補リストが構成され、候補は、空間隣接ブロックまたは時間隣接ブロックからであり得る。空間および時間隣接ブロックは、候補リスト、すなわち動き予測情報が選択され得る１組の候補を形成することができる。したがって、ビデオエンコーダ２０は、インデックスを候補リストにコーディングによって動き予測情報として選択される動きパラメータをコーディングすることができる。ビデオデコーダ３０がインデックスを復号した後、インデックスが指す対応するブロックのすべての動きパラメータは、マージモードにおいて継承され得る。
【０１０９】
[0120]ＡＭＶＰ、したがって従来のＨＥＶＣでは、各動き仮定のための動きベクトル予測子の候補リストは、コーディングされた参照インデックスに基づいて導出される。このリストは、同じ参照インデックスと、時間参照ピクチャにおいてコロケートされたブロックの隣接ブロックの動きパラメータに基づいて導出される時間動きベクトル予測子とに関連する隣接ブロックの動きベクトルを含む。選択された動きベクトルは、インデックスを候補リストに送信することによってシグナリングされる。加えて、参照インデックス値および動きベクトル差分もシグナリングされる。
【０１１０】
[0121]図４は、ビュー間予測の様々な例を提供する。図４の例では、ビューＳ１のフレームは、ビューＳ１の異なる時間ロケーションにおけるフレームから予測されるものとして、ならびに同じ時間ロケーションにおけるビューＳ０およびＳ２のフレームのうちのフレームからビュー間予測されるものとして示されている。たとえば、時間位置Ｔ１にあるビューＳ１のｂフレームは、時間位置Ｔ０およびＴ２にあるビューＳ１のＢフレームの各々、ならびに時間位置Ｔ１にあるビューＳ０およびビューＳ２のｂフレームから予測される。
【０１１１】
[0122]図４の例では、大文字の「Ｂ」および小文字の「ｂ」は、異なる符号化方法ではなく、フレーム間の異なる階層関係を示すものとする。一般に、大文字の「Ｂ」フレームは、小文字の「ｂ」フレームよりも予測階層が比較的高い。図４はまた、異なるレベルの陰影を使用して予測階層の変形形態を示し、より大きい量の陰影の（すなわち、比較的暗い）フレームは、より少ない陰影を有する（すなわち、比較的明るい）それらのフレームよりも予測階層が高い。たとえば、図４内のすべてのＩフレームは完全陰影を用いて示されるが、Ｐフレームはいくぶん明るい陰影を有し、Ｂフレーム（および小文字のｂフレーム）は、互いに対して様々なレベルの陰影を有するが、ＰフレームおよびＩフレームの陰影よりも常に明るい。
【０１１２】
[0123]概して、階層が比較的高いそれらのフレームが、階層が比較的低いフレームの復号中に参照フレームとして使用され得るように、予測階層が比較的高いフレームは、階層が比較的低いフレームを復号する前に復号されるべきであるという点で、予測階層はビュー順序インデックスに関係する。ビュー順序インデックスは、アクセスユニット中のビュー成分の復号順序を示すインデックスである。Ｈ．２６４／ＡＶＣ（ＭＶＣ追補）の付属書類Ｈにおいて規定されているように、ビュー順序インデックスはＳＰＳ  ＭＶＣ拡張において暗示されている。ＳＰＳでは、各インデックスｉについて、対応するｖｉｅｗ＿ｉｄがシグナリングされる。いくつかの例では、ビュー成分の復号は、ビュー順序インデックスの昇順に従う。すべてのビューが提示された場合、ビュー順序インデックスは、０からｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ＿１までの連続する順序になっている。
【０１１３】
[0124]このように、参照フレームとして使用されるフレームは、その参照フレームを参照して符号化されたフレームを復号する前に復号され得る。ビュー順序インデックスは、アクセスユニット中のビュー成分の復号順序を示すインデックスである。各ビュー順序インデックスｉについて、対応するｖｉｅｗ＿ｉｄがシグナリングされる。ビュー成分の復号は、ビュー順序インデックスの昇順に従う。すべてのビューが提示された場合、ビュー順序インデックスのセットは、０からビューの全数よりも１少ない数までの連続的な順序付きセットを備え得る。
【０１１４】
[0125]階層の等しいレベルにおけるいくつかのフレームの場合、復号順序は、互いに重要でないことがある。たとえば、時間ロケーションＴ０におけるビューＳ０のＩフレームは、時間ロケーションＴ０におけるビューＳ２のＰフレームのための参照フレームとして使用され、そのＰフレームは今度は、時間ロケーションＴ０におけるビューＳ４のＰフレームのための参照フレームとして使用される。したがって、時間ロケーションＴ０におけるビューＳ０のＩフレームは、時間ロケーションＴ０におけるビューＳ２のＰフレームの前に復号されるべきであり、そのＰフレームは、時間ロケーションＴ０におけるビューＳ４のＰフレームの前に復号されるべきである。しかしながら、ビューＳ１およびＳ３は、予測のために互いに依拠しないが、代わりに、予測階層がより高いビューからのみ予測されるので、ビューＳ１とＳ３との間で復号順序は重要でない。その上、ビューＳ１がビューＳ０およびＳ２の後に復号される限り、ビューＳ１はビューＳ４の前に復号され得る。
【０１１５】
[0126]このように、ビューＳ０〜Ｓ７を記述するために階層順序が使用され得る。表記法ＳＡ＞ＳＢは、ビューＳＡがビューＳＢの前に復号されるべきであることを意味する。この表記法を使用すると、図４の例では、Ｓ０＞Ｓ２＞Ｓ４＞Ｓ６＞Ｓ７である。また、図４の例に関して、Ｓ０＞Ｓ１、Ｓ２＞Ｓ１、Ｓ２＞Ｓ３、Ｓ４＞Ｓ３、Ｓ４＞Ｓ５、およびＳ６＞Ｓ５である。これらの要件に違反しないビューのための任意の復号順序が可能である。したがって、いくつかの制限のみをもつ、多くの異なる復号順序が可能である。
【０１１６】
[0127]本開示の技法によれば、ビューＳ０〜Ｓ７の各々は、対応するビットストリームのそれぞれのレイヤと見なされ得る。したがって、ＶＰＳは、ビューＳ０〜Ｓ７のいずれかまたはすべてに適用可能なビットストリームのパラメータについて記述することができるが、個々のレイヤパラメータセットは、ビューＳ０〜Ｓ７のいずれかまたはすべてに与えられ得る。加えて、グルーピングパラメータセットは、ビューＳ０〜Ｓ７の個々のピクチャ内のスライスがグルーピングパラメータセットの識別子を簡単に参照することができるように、パラメータセットのグループに与えられ得る。
【０１１７】
[0128]図４に示すように、ビュー成分は、参照のために他のビュー中のビュー成分を使用することができる。これは、ビュー間予測と呼ばれる。ＭＶＣでは、別のビュー中のビュー成分がインター予測の参照であるかのように、ビュー間予測が実現される。ビデオエンコーダ２０およびビデオデコーダ３０は、（表１の例に示すように）シーケンスパラメータセット（ＳＰＳ）ＭＶＣ拡張における潜在的ビュー間参照値をコーディングすることができる。ビデオエンコーダ２０およびビデオデコーダ３０は、参照ピクチャリスト構成プロセスを実行することによって潜在的ビュー間参照値をさらに変更することができ，これは、インター予測またはビュー間予測参照値のフレキシブルな順序付けを可能にし得る。
【表１】
2015507428.tif 000003
【０１１８】
[0129]表１に示すＳＰＳのＭＶＣ拡張では、ビューごとに、参照ピクチャリスト０と参照ピクチャリスト１とを形成するために使用され得るビューの数をシグナリングされる。ＳＰＳのＭＶＣ拡張でシグナリングされたアンカーピクチャ用の予測関係は、同じビューの（ＳＰＳのＭＶＣ拡張でシグナリングされた）非アンカーピクチャ用の予測関係とは異なる場合がある。
【０１１９】
[0130]ビデオコーディング規格には、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、ならびに、そのスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）の拡張を含む（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られている）ＩＴＵ−Ｔ  Ｈ．２６４が含まれる。
【０１２０】
[0131]加えて、ＩＴＵ−Ｔ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＶＣＥＧ）およびＩＳＯ／ＩＥＣ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）のＪｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｏｎ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって開発されている新しいビデオコーディング規格、すなわち高効率ビデオコーディング（ＨＥＶＣ）が存在する。以下でＨＥＶＣ  ＷＤ４と呼ぶ、ＨＥＶＣの最近のワーキングドラフト（ＷＤ）は、ＨＥＶＣ  ＷＤ４ｄ１として示されたｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／６＿Ｔｏｒｉｎｏ／ｗｇ１１／ＪＣＴＶＣ−Ｆ８０３-ｖ３．ｚｉｐから入手可能である。
【０１２１】
[0132]シーケンスおよびピクチャパラメータセット機構は、コーディングブロックデータの送信から、まれに変化する情報の送信を分離する。シーケンスおよびピクチャパラメータセットは、適用例によっては、信頼性の高い伝達機構を使用して「帯域外で」伝達され得る。ピクチャパラメータセットローバイトシーケンスペイロード（ＲＢＳＰ）は、１つまたは複数のコーディングピクチャのコーディングスライスネットワークアブストラクションレイヤ（ＮＡＬ）ユニットによって参照され得るパラメータを含み得る。シーケンスパラメータセットＲＢＳＰは、１つまたは複数のピクチャパラメータセットＲＢＳＰ、またはバッファリング期間補足エンハンスメント情報（ＳＥＩ）メッセージを含む１つまたは複数のＳＥＩ  ＮＡＬユニットによって参照され得るパラメータを含み得る。シーケンスパラメータセットＲＢＳＰは、１つまたは複数のピクチャパラメータセットＲＢＳＰ、またはバッファリング期間ＳＥＩメッセージを含む１つまたは複数のＳＥＩ  ＮＡＬユニットによって参照され得るパラメータを含み得る。
【０１２２】
[0133]シーケンスパラメータセットは、ビデオユーザビリティ情報（ＶＵＩ）と呼ばれるオプションのパラメータのセットを含み得る。ＶＵＩは、次の３つのカテゴリーのオプションの情報、すなわちビデオ表示情報、仮想参照デコーダ（ＨＲＤ）情報、およびビットストリーム制限情報を含み得る。ビデオ表示情報としては、アスペクト比、ルーマに対する色空間変換関連情報クロマ位相シフト、およびフレームレートがある。ＨＲＤは、コード化ビデオシーケンスについてのビデオバッファリングパラメータを含む。ビットストリーム制限情報は、動きベクトル範囲と、復号ピクチャバッファ（ＤＰＢ）サイズと、並べ替えられるフレームの数と、ブロック（たとえばマクロブロックまたはコーディングユニット（ＣＵ））およびピクチャのコード化サイズとに関する制限を含む。
【０１２３】
[0134]ＨＥＶＣ  ＷＤ５は、サポート適合パラメータセット（ＡＰＳ）を含む。適合パラメータセット（ＡＰＳ）の概念は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／６＿Ｔｏｒｉｎｏ／ｗｇ１１／ＪＣＴＶＣ−Ｆ７４７-ｖ４．ｚｉｐから入手可能なＪＣＴＶＣ−Ｆ７４７において見出すこともできる。
【０１２４】
[0135]統合されたＮＡＬユニットヘッダは、ＨＥＶＣの非スケーラブルビットストリームと、ＨＥＶＣの潜在的なスケーラブル拡張またはマルチビュー拡張に準拠するスケーラブルビットストリームの両方に関して使用され得る。統合されたＮＡＬユニットヘッダは次の態様において現在のＨＥＶＣ  ＮＡＬユニットヘッダとは異なる可能性があり、すなわち、１つのコード化ビデオシーケンス全体について固定のＮＡＬユニットヘッダ長が存在し得、その長さが異なるコード化ビデオシーケンスにわたって変化する間、ＮＡＬユニットヘッダ内のスケーラビリティシンタックス要素の効率的なコーディングを可能にし、特定のシンタックス要素が必要とされない場合、それは存在する必要がない。そのような設計では、異なるＮＡＬユニットタイプまたはパラメータセットは、ビットストリーム全体に関して使用され得る。
【０１２５】
[0136]図５は、ビデオパラメータセット（ＶＰＳ）および様々なレイヤパラメータセット（ＬＰＳ）を示す概念図である。図５の第２のＬＰＳに続く円は、任意の数ＮｎｏＶＰＳが存在し得ることを示す意図であり、ここでＮは整数である。たとえば、各レイヤ（たとえば、各ＳＶＣレイヤまたは各ＭＶＣビュー）は、対応するＬＰＳを有し得る。ビデオエンコーダ２０またはビデオデコーダ３０などのビデオコーダは、たとえば図５に示すような、ＶＰＳおよび１つまたは複数のＬＰＳをコーディングするように構成され得る。
【０１２６】
[0137]以下の表２は、ＶＰＳの例示的なローバイトシーケンスペイロード（ＲＢＰＳ）シンタックスを与える。
【表２−１】
2015507428.tif 000004
【表２−２】
2015507428.tif 000005
【０１２７】
[0138]ビデオコーダは、コード化ビデオシーケンス（たとえば、１つまたは複数のレイヤを含むビットストリーム）が１つのアクティブなビデオパラメータセット（ＶＰＳ）のみを有することができるように設定され得る。ＶＰＳは、特定のタイプのＮＡＬユニット内にカプセル化され得る。たとえば、ＶＰＳ  ＲＢＳＰについてのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは１０であり得る。表２のＶＰＳの例示的なセマンティクスが、以下で説明される。
【０１２８】
[0139]この例では、ｖｉｄｅｏ＿ｐａｒａ＿ｓｅｔ＿ｉｄは、対応するビデオパラメータセット（ＶＰＳ）を識別する。
【０１２９】
[0140]この例では、ｃｎｔ＿ｐは、対応するコード化ビデオシーケンス中に存在するｐｒｉｏｒｉｔｙ＿ｉｄ値の最大数を指定する。
【０１３０】
[0141]この例では、ｃｎｔ＿ｄは、対応するコード化ビデオシーケンス中に存在する従属レイヤの最大数を指定する。同じ解像度を有する複数のビューは、同じ従属レイヤに属するものと見なされ得る。２つの従属レイヤは、同じ空間解像度を有し得る。
【０１３１】
[0142]この例では、ｃｎｔ＿ｔは、コード化ビデオシーケンス中に存在する時間レイヤの最大数を指定する。
【０１３２】
[0143]この例では、ｃｎｔ＿ｑは、コード化ビデオシーケンス中の従属レイヤ中に存在する品質レイヤの最大数を指定する。
【０１３３】
[0144]この例では、ｃｎｔ＿ｖは、コード化ビデオシーケンス中に存在するビューの最大数を指定する。
【０１３４】
[0145]この例では、ｃｎｔ＿ｆは、ＮＡＬユニットヘッダ中のｒｅｓｅｒｖｅｄ＿ｆｌａｇｓシンタックス要素を表すために使用されるビットの数を指定する。
【０１３５】
[0146]この例では、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］およびｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、それぞれ、ルーマサンプルの単位のｉ番目の従属レイヤの幅および高さの解像度を指定する。
【０１３６】
[0147]この例では、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８［ｉ］ｐｌｕｓ８およびｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８［ｉ］ｐｌｕｓ８は、ｉ番目のビット深度表示のルーマ成分およびクロマ成分のビット深度を指定する。
【０１３７】
[0148]この例では、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ［ｉ］は、ｉ番目のクロマサンプルフォーマット表示のクロマサンプルフォーマットを指定する。たとえば、０に等しい値は４：２：０を示し、１に等しい値は４：４：４を示し、２に等しい値は４：２：２を示し、３に等しい値は４：０：０を示し得る。
【０１３８】
[0149]この例では、ａｖｅｒａｇｅ＿ｆｒａｍｅ＿ｒａｔｅ［ｉ］は、２５６秒当りのフレームの単位で、ｉ番目の時間レイヤ表現の平均フレームレートを指定する。
【０１３９】
[0150]この例では、ｖｉｅｗ＿ｉｄ［ｉ］は、ｉに等しいビュー順序インデックスを有する、ｉ番目のビューのビュー識別子を指定する。存在しないとき、ｖｉｅｗ＿ｉｄ［０］の値は、０であると推測され得る。０に等しいｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素がビデオパラメータセットＲＢＳＰシンタックス構造中に存在しないことを指定する。ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、今度のＨＥＶＣ規格に従うビットストリーム中で０に等しくなり得る。ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、たとえば、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約され得る。ビデオデコーダ３０などのデコーダは、ビデオパラメータセットＮＡＬユニット中のｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１に続くすべてのデータを無視し得る。
【０１４０】
[0151]この例では、ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、任意の値を有し得る。それは、今度のＨＥＶＣ規格に規定されるプロファイルへの準拠に影響を及ぼさないが、今度の規格のさらなる発展を可能にする。
【０１４１】
[0152]ＶＰＳ中の他のシンタックス要素は、現在のＨＥＶＣワーキングドラフトのＳＰＳにおける同じ名前を有するシンタックス要素と同じセマンティクスを有し得る。これらのシンタックス要素は、下位レベルのパラメータセットによって上書きされなければ、このＶＰＳを参照するコード化ビデオシーケンスに適用し得る。
【０１４２】
[0153]いくつかの例では、３ＤＶ＿ｆｌａｇは、深さがコード化ビデオシーケンスに存在するかどうかを示すためにＶＰＳにおいてさらにシグナリングされ得る。
【０１４３】
[0154]いくつかの例では、ＶＵＩパラメータは、ＬＰＳにおいてシグナリングされる。
【０１４４】
[0155]いくつかの例では、シンタックス要素ｃｎｔ＿ｐ、ｃｎｔ＿ｔ、ｃｎｔ＿ｄ、ｃｎｔ＿ｑ、およびｃｎｔ＿ｖは、ｐｒｉｏｒｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘをそれぞれコーディングするために使用されるビットの数を指定し、コード化ビデオシーケンス中に存在する、ｐｒｉｏｒｉｔｙ＿ｉｄ値、時間レイヤ、従属レイヤ、品質レイヤ、およびビューの最大数もＶＰＳにおいてシグナリングされ得る。
【０１４５】
[0156]いくつかの例では、別のタイプのＮＡＬユニットは、シンタックス要素ｃｎｔ＿ｐ、ｃｎｔ＿ｔ、ｃｎｔ＿ｄ、ｃｎｔ＿ｑ、ｃｎｔ＿ｖ、およびｃｎｔ＿ｆを含むように導かれ得る。この新規のＮＡＬユニットタイプは識別子（ＩＤ）を含み得、ＩＤは、ＶＰＳにおいて参照され得る。
【０１４６】
[0157]いくつかの例では、表２のｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿１ｓｂ＿ｍｉｎｕｓ４からｉｎｔｅｒ＿４×４＿ｅｎａｂｌｅｄ＿ｆｌａｇまでのシンタックス要素は、ＶＰＳにおいてシグナリングされないが、代わりに、ビデオエンコーダ２０およびビデオデコーダ３０は、ＬＰＳにおいてこれらのシンタックス要素をコーディングすることができる。
【０１４７】
[0158]いくつかの例では、表２のｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔ＿ｄｅｓｃｒｉｐｔｉｏｎ（）シンタックス構造は、ＶＰＳに含まれず、代わりに、ビデオエンコーダ２０およびビデオデコーダ３０または他の要素（たとえば出力インターフェース２２および／または入力インターフェース２８）は、補足エンハンスメント情報（ＳＥＩ）メッセージ中のｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔ＿ｄｅｓｃｒｉｐｔｉｏｎ（）シンタックス構造中のコンテンツをコーディングし得る。
【０１４８】
[0159]いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＶＰＳ中のビデオユーザビリティ情報（ＶＵＩ）パラメータをコーディングし得る。たとえば、ＶＰＳは、動きベクトル範囲と、ＤＰＢサイズと、並べ替えられるフレームの数と、ブロック（たとえば、マクロブロックまたはＣＵ）およびピクチャのコード化サイズとに関する制限などの、ビットストリーム制限情報を指定するデータを含み得る。このように、ＶＰＳは、ビデオデコーダ（ビデオデコーダ３０など）が、対応するビットストリーム、すなわちＶＰＳを含むビットストリームを適切に復号するために、必要なＤＰＢサイズを示す情報を指定し得る。同様に、ＶＰＳは、ピクチャ並べ替え情報、すなわち復号順序で所与のピクチャに先行し得、出力順序（すなわち、表示順序）で当該所与のピクチャに続くピクチャの数を指定し得る。
【０１４９】
[0160]追加または代替として、ＶＰＳは、仮想参照デコーダ（ＨＲＤ）情報を指定するデータを含み得る。上述のように、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＶＰＳ中のＨＲＤ情報を含み得るＶＵＩパラメータをコーディング（すなわち、シグナリング）することができる。したがって、ＶＰＳは、たとえば対応するビットストリームのオペレーションポイントについて記述するデータを含み得る。たとえば、ＶＰＳは、最大オペレーションポイント数、異なるレイヤ間またはビュー間の依存性、各オペレーションポイントについてのプロファイルおよびレベル情報、各オペレーションポイントについてのオペレーションポイントＶＣＬ  ＮＡＬユニット表示、各オペレーションポイントにおけるビットレート、オペレーションポイント間の依存性、各オペレーションポイントにおける制限、各オペレーションポイントにおけるＶＵＩもしくは部分的ＶＵＩ、および／または各レイヤもしくはビューにおけるＶＵＩもしくは部分的ＶＵＩのうちの１つまたは複数について記述するデータを含み得る。
【０１５０】
[0161]ＶＰＳは、各次元に関して、特定のインデックス値、インデックス値の範囲、またはインデックス値のリストを含み得る。たとえば、ＶＰＳが特定のインデックス値について記述するデータを含むとき、インデックス値は、空間解像度について、クロマサンプリングフォーマットのビット深度に対応し得る。別の例として、ＶＰＳが時間レイヤについてインデックス値の範囲を含むとき、その範囲は、ゼロ（０）から最上時間レイヤＩＤまでを備え、品質レイヤについては、その範囲は、ゼロ（０）から最上品質レイヤＩＤまでを備え得る。さらに別の例として、ＶＰＳがインデックス値のリストについて記述するデータを含むとき、そのリストは複数のビューに関するビューインデックス値のリストを備え得る。
【０１５１】
[0162]いくつかの例では、ビデオエンコーダ２０は、１つまたは複数の表示（representation）フォーマットパラメータ（幅、高さ、ビット深度など）を符号化（すなわち、シグナリング）し、ビデオデコーダは、１つまたは複数の表示フォーマットパラメータを復号し、表示フォーマットパラメータの様々なセットが存在し得る。レイヤまたはオペレーションポイントは、次いで、表示フォーマットパラメータのそのようなセットのインデックスを参照し得る。そのようなセットのシンタックス設計の例は、以下の表３に示される。
【表３】
2015507428.tif 000006
【０１５２】
[0163]いくつかの例では、ｒｅｆ＿ｆｏｒｍａｔ＿ｉｄｘは、代わりに、レイヤパラメータセット内でシグナリングされ得る。
【０１５３】
[0164]以下の表４は、オペレーションポイント記述に関する例示的なシンタックスを与える。
【表４】
2015507428.tif 000007
【０１５４】
[0165]表４の様々なシンタックス要素のセマンティクスの例について、以下で説明する。
【０１５５】
[0166]この例では、ｎｕｍ＿ｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔ＿ｍｉｎｕｓ１＿ｐｌｕｓ１は、コード化ビデオシーケンス中に存在するオペレーションポイントの最大数を指定し、そのオペレーションポイントについて、オペレーションポイント情報が次のシンタックス要素によってシグナリングされる。
【０１５６】
[0167]この例では、ｏｐ＿ｐｒｏｆｉｌｅ＿ｌｅｖｅｌ＿ｉｄｃ［ｉ］、ｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔ＿ｉｄ［ｉ］、ｐｒｉｏｒｉｔｙ＿ｉｄ［ｉ］、ｎｕｍ＿ｔａｒｇｅｔ＿ｏｕｔｐｕｔ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１［ｉ］、ｆｒｍ＿ｒａｔｅ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｉ］、ａｖｇ＿ｂｉｔｒａｔｅ［ｉ］、ｍａｘ＿ｂｉｔｒａｔｅ［ｉ］、ｍａｘ＿ｂｉｔｒａｔｅ＿ｃａｌｃ＿ｗｉｎｄｏｗ［ｉ］、ｃｏｎｓｔａｎｔ＿ｆｒｍ＿ｒａｔｅ＿ｉｄｃ［ｉ］、およびｎｕｍ＿ｄｉｒｅｃｔｌｙ＿ｄｅｐｅｎｄｅｎｔ＿ｖｉｅｗｓ［ｉ］は、Ｈ．２６４のビュースケーラビリティ情報ＳＥＩメッセージ中の同じ名前を有するシンタックス要素と同じセマンティクスを有し得る。
【０１５７】
[0168]この例では、ｑｕａｌｉｔｙ＿ｉｄ［ｉ］およびｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］は、Ｈ．２６４のスケーラビリティ情報ＳＥＩメッセージ中の同じ名前を有するシンタックス要素と同じセマンティクスを有し得る。
【０１５８】
[0169]この例では、ｄｉｒｅｃｔｌｙ＿ｄｅｐｅｎｄｅｎｔ＿ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］は、現在のオペレーションポイントのターゲット出力ビューが現在のオペレーションポイントの表示内で直接依存するｊ番目のビューのビューインデックスを指定する。
【０１５９】
[0170]この例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［ｉ］は、ｉに等しいビュー順序インデックスを有するビュー成分を復号する際の最初の参照ピクチャリストＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１におけるビュー間予測のためにビュー成分の数を指定する。この例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［ｉ］の値は、Ｍｉｎ（１５，ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１）よりも大きくなるべきでない。いくつかの例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［０］の値は０に等しい。
【０１６０】
[0171]この例では、ｒｅｆ＿ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］は、ｉに等しいビュー順序インデックスを有するビュー成分を復号する際の最初の参照ピクチャリストＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１におけるビュー間予測のためにｊ番目のビュー成分のビュー順序インデックスを指定する。この例では、ｒｅｆ＿ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］の値は、両端値を含む０〜３１の範囲内であるべきである。
【０１６１】
[0172]いくつかの例では、代替として、（Ｈ．２６４に記述された）スケーラビリティ情報ＳＥＩメッセージにおけるシンタックス要素のいくつか、たとえば、レイヤ従属情報関連シンタックス要素は、表４のｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔｓ＿ｄｅｓｃｒｉｐｔｉｏｎ（）シンタックス構造に含まれ得る。
【０１６２】
[0173]いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、表４のｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔｓ＿ｄｅｓｃｒｉｐｔｉｏｎ（）シンタックス構造中のいくつかのＶＵＩパラメータをコーディング（すなわち、シグナリング）し得る。
【０１６３】
[0174]以下の表５は、ビデオパラメータセットのための代わりのシンタックスを与える。
【表５−１】
2015507428.tif 000008
【表５−２】
2015507428.tif 000009
【表５−３】
2015507428.tif 000010
【０１６４】
[0175]表５のビデオパラメータセットのシンタックスに関するセマンティクスの例について、以下で説明する。概して、以下で説明しない同様の名前のシンタックス要素は、表２に関する上述のものと同じセマンティクスを有し得る。他のシンタックス要素に関するセマンティクスは、次のようになり得る。
【０１６５】
[0176]この例では、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅは、１（すなわちバイナリ「１」値）に等しい。
【０１６６】
[0177]この例では、０に等しいｅｘｔｅｎｔｉｏｎ＿ｔｙｐｅは、複数のビューレイヤがビットストリーム中に存在し得ることを示す。この例では、１に等しいｅｘｔｅｎｔｉｏｎ＿ｔｙｐｅは、複数の従属レイヤおよび／または品質レイヤがビットストリーム中に存在し得ることを指定する。
【０１６７】
[0178]この例では、ｎｕｍ＿ｒｅｐ＿ｆｏｒｍａｔ＿ｍｉｎｕｓ１ｐｌｕｓ１は、このビデオパラメータセットによってサポートされる表示フォーマットの異なるセットの最大数を指定し、表示フォーマットには、ビット深度およびクロマフォーマット（すなわち、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ値のセット）、ピクチャ解像度、およびコード化ビデオシーケンスにおけるクロッピングウィンドウ情報を含む。ｎｕｍ＿ｒｅｐ＿ｆｏｒｍａｔｓ＿ｍｉｎｕｓ１の値は、両端値を含む０〜Ｘの範囲内であり得る。ビデオエンコーダ２０およびビデオデコーダ３０は、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃによってベースレイヤについてのビット深度およびクロマフォーマットのセットをコーディングし、ビット深度およびクロマフォーマットのセットは、シンタックス要素の次のセット、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８［ｉ］、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８［ｉ］、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ［ｉ］によってエンハンスメントレイヤについてシグナリングされる。
【０１６８】
[0179]ビデオエンコーダ２０およびビデオデコーダ３０は、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｃｒｏｐｐｉｎｇ＿ｆｌａｇ、ｐｉｃ＿ｃｒｏｐ＿ｌｅｆｔ＿ｏｆｆｓｅｔ、ｐｉｃ＿ｃｒｏｐ＿ｒｉｇｈｔ＿ｏｆｆｓｅｔ、ｐｉｃ＿ｃｒｏｐ＿ｔｏｐ＿ｏｆｆｓｅｔ、およびｐｉｃ＿ｃｒｏｐ＿ｂｏｔｔｏｍ＿ｏｆｆｓｅｔによって表示フォーマットの第１のセットをコーディングし得る。
【０１６９】
[0180]この例では、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８［ｉ］、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８［ｉ］、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ［ｉ］は、それぞれ、コード化ビデオシーケンスにおけるｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ値のｉ番目のセットを指定する。
【０１７０】
[0181]この例では、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］およびｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、それぞれ、ｉ番目の表示フォーマットを使用してルーマサンプルの単位で各復号ピクチャの幅および高さを指定する。
【０１７１】
[0182]この例では、ｐｉｃ＿ｃｒｏｐｐｉｎｇ＿ｆｌａｇ［ｉ］、ｐｉｃ＿ｃｒｏｐ＿ｌｅｆｔ＿ｏｆｆｓｅｔ［ｉ］、ｐｉｃ＿ｃｒｏｐ＿ｒｉｇｈｔ＿ｏｆｆｓｅｔ［ｉ］、ｐｉｃ＿ｃｒｏｐ＿ｔｏｐ＿ｏｆｆｓｅｔ［ｉ］、およびｐｉｃ＿ｃｒｏｐ＿ｂｏｔｔｏｍ＿ｏｆｆｓｅｔ［ｉ］は、表示フォーマットのｉ番目のセットについて、出力用のピクチャ座標において指定される矩形領域の観点から、復号プロセスから出力されるコード化ビデオシーケンスにおけるピクチャのサンプルを指定する。
【０１７２】
[0183]この例では、ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘ［ｉ］は、ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤに適用する、追加のビット深度およびクロマフォーマットのセットにインデックス値を指定する。ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤについてのｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値は、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８［ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘ［ｉ］］、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８［ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘ［ｉ］］、およびｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ［ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘ［ｉ］］にそれぞれ等しい。ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘ［ｉ］の値は、両端値を含む０〜Ｘの範囲内にあるべきである。
【０１７３】
[0184]この例では、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］は、ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤについて従属識別子を指定する。ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］は、両端値を含む０〜Ｘの範囲内であり得る。ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］は、存在しないとき、０であると推測され得る。ｎｕｍ＿ｄｉｒｅｃｔｌｙ＿ｄｅｐｅｎｄｅｎｔ＿ｌａｙｅｒｓ［ｉ］が０よりも大きいとき、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］は、ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤが依存する任意のレイヤの従属識別子に等しいかまたはそれよりも大きい。
【０１７４】
[0185]この例では、ｑｕａｌｉｔｙ＿ｉｄ［ｉ］は、ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤに品質識別子を指定する。ｑｕａｌｉｔｙ＿ｉｄ［ｉ］は、両端値を含む０〜Ｘの範囲内であり得る。ｑｕａｌｉｔｙ＿ｉｄ［ｉ］は、存在しないとき、０であると推測され得る。ｎｕｍ＿ｄｉｒｅｃｔｌｙ＿ｄｅｐｅｎｄｅｎｔ＿ｌａｙｅｒｓ［ｉ］が０よりも大きいとき、ｑｕａｌｉｔｙ＿ｉｄ［ｉ］は、ｉに等しいｌａｙｅｒ＿ｉｄをもつレイヤが依存し、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ［ｉ］に等しい従属識別子を有する、任意のレイヤの品質識別子に等しいかまたはそれよりも大きい。
【０１７５】
[0186]この例では、ｎｕｍ＿ｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔｓは、ビデオパラメータセットにおいて指定される短期参照ピクチャセットの数を指定する。ｎｕｍ＿ｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔｓの値は、両端値を含む０〜６４の範囲内であり得る。
【０１７６】
[0187]この例では、１に等しいｄｅｐｔｈ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇは、現在の３ＤＶオペレーションポイントが深度を含むことを示す。この例では、０に等しいｄｅｐｔｈ＿ｉｎｃｌｕｄｅｄ＿ｆｌａｇは、現在の３ＤＶオペレーションポイントが深度を含まないことを示す。
【０１７７】
[0188]表５のビュー従属要素についての例示的なシンタックスが、以下の表６に与えられる。
【表６】
2015507428.tif 000011
【０１７８】
[0189]以下の表７は、各非ベースビューのビュー従属性がシーケンスレベルにおいて直接シグナリングされるデータの例示的なセットを定義する。
【表７】
2015507428.tif 000012
【０１７９】
[0190]この例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［ｉ］は、ｉに等しいビュー順序インデックスを有するビュー成分を復号する際の最初の参照ピクチャリストＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１におけるビュー間予測のためにビュー成分の数を指定する。この例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［ｉ］の値は、Ｍｉｎ（１５，ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１）よりも大きくない。この例では、ｎｕｍ＿ｒｅｆ＿ｖｉｅｗｓ［０］の値は０に等しい。
【０１８０】
[0191]この例では、ｒｅｆ＿ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］は、ｉに等しいビュー順序インデックスを有するビュー成分を復号する際の最初の参照ピクチャリストＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１におけるビュー間予測のためにｊ番目のビュー成分のビュー順序インデックスを指定する。この例では、ｒｅｆ＿ｖｉｅｗ＿ｉｄｘ［ｉ］［ｊ］の値は、両端値を含む０〜３１の範囲内である。
【０１８１】
[0192]上述のように、特定のタイプのＮＡＬユニット（たとえば、ＮＡＬユニットタイプ１０）は、ビデオパラメータセットをカプセル化するために使用され得る。ＮＡＬユニットシンタックスは、以下の表８の例に示すように変更され得る。
【表８−１】
2015507428.tif 000013
【表８−２】
2015507428.tif 000014
【０１８２】
[0193]この例では、従来のＮＡＬユニットシンタックスに対して、「ｉｆ（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ！＝１０）」ステートメント内の要素が加えられる。この例では、シンタックス要素ｐｒｉｏｒｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘをシグナリングするのに使用されるビットの数は、それぞれ、Ｃｅｉｌ（ｌｏｇ２（ｃｎｔ＿ｐ））、Ｃｅｉｌ（ｌｏｇ２（ｃｎｔ＿ｔ））、Ｃｅｉｌ（ｌｏｇ２（ｃｎｔ＿ｄ））、Ｃｅｉｌ（ｌｏｇ２（ｃｎｔ＿ｑ））、およびＣｅｉｌ（ｌｏｇ２（ｃｎｔ＿ｖ））である。同様に、この例では、シンタックス要素ｐｒｉｏｒｉｔｙ＿ｉｄ、ｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘのうちのいずれかが存在しないとき、そのシンタックス要素の値は、０に等しいものと推測される。
【０１８３】
[0194]ビットの数および引き出され得る推測に関して上記で定義したものを除いて、表８のシンタックス要素に関するセマンティクスは、次のように定義され得る。ｐｒｉｏｒｉｔｙ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、およびｑｕａｌｉｔｙ＿ｉｄのセマンティクスは、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣのＳＶＣ拡張において定義され得る。ｔｅｍｐｏｒａｌ＿ｉｄのセマンティクスは、ＨＥＶＣのＷＤ４において定義され得る。この例では、ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔは、１に等しい。ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔの値０は、ＨＥＶＣ規格の将来の拡張によって規定され得る。ビデオデコーダ３０などのデコーダは、ｒｅｓｅｒｖｅｄ＿ｏｎｅ＿ｂｉｔの値を無視するように構成され得る。
【０１８４】
[0195]この例では、ｖｉｅｗ＿ｉｄｘは、ビューのビュー順序インデックスを指定する。ｖｉｅｗ＿ｉｄｘのセマンティクスはＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣのＭＶＣ拡張において規定されているシンタックス要素「ビュー順序インデックス」と同じであり得る。
【０１８５】
[0196]この例では、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの各ビットは１に等しい。ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの他の値は、今度のＨＥＶＣ規格の将来の拡張によって規定され得る。ビデオデコーダ３０などのデコーダは、セマンティクスをｒｅｓｅｒｖｅｄ＿ｆｌａｇｓのビットに割り当てる拡張に従って動作するように構成されなければ、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓの値を無視するように構成され得る。この例では、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓを表すのに使用されるビットの数は、ｒｅｓｅｒｖｅｄ＿ｆｌａｇｓ_ｌｅｎである。
【０１８６】
[0197]この例では、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの各ビットは１に等しい。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの他の値は、今度のＨＥＶＣ規格の将来の拡張によって規定され得る。ビデオデコーダ３０などのデコーダは、ここでも、そのような将来の拡張に従って構成されなければ、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓの値を無視するように構成され得る。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓを表すのに使用されるビットの数は、この例では、（（ｍ+７＞＞３）＜＜３）−ｍである。
【０１８７】
[0198]以下の表９は、レイヤパラメータセットに関する例示的なシンタックスを与える。同じシンタックスは、いくつかの例では、図５のＬＰＳの各々に関して使用され得る。
【表９−１】
2015507428.tif 000015
【表９−２】
2015507428.tif 000016
【０１８８】
[0199]表９のＬＰＳシンタックスに関するセマンティクスの例について、以下で説明する。異なるレイヤ（たとえば、ＭＶＣにおける異なるビューまたはＳＶＣにおける異なるレイヤ）は、異なるＬＰＳを参照する。同じ従属レイヤにおける異なる品質レイヤは、同じＬＰＳを共有し得る。同じ従属レイヤにおける異なる時間レイヤは、同じＬＰＳを共有し得る。代替として、異なるビューは同じＬＰＳを参照し、異なる従属レイヤは同じＬＰＳを参照し得る。
【０１８９】
[0200]この例では、１に等しいｄｅｐｔｈ＿ｆｌａｇは、ＬＰＳがＬＰＳ  ＮＡＬユニットのｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘの値によって識別される深度表示に適用されることを指定する。０に等しいｄｅｐｔｈ＿ｆｌａｇは、ＬＰＳがＬＰＳ  ＮＡＬユニットのｔｅｍｐｏｒａｌ＿ｉｄ、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ、ｑｕａｌｉｔｙ＿ｉｄ、およびｖｉｅｗ＿ｉｄｘの値によって識別されるテクスチャ表示に適用されることを指定する。
【０１９０】
[0201]この例では、ｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄは、現在のレイヤパラメータセット（ＬＰＳ）のｉｄを指定する。ｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値と同じ値をもつ異なるレイヤパラメータセットは、それぞれ、ｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄについての１つの値空間を共有するが、それは、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄとｖｉｅｗ＿ｉｄｘの異なる組合せを有する異なるＬＰＳがｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄの同じ値を有し得ることを意味する。
【０１９１】
[0202]代替として、すべてのＬＰＳは１つの値空間を共有し得るが、それは、各ＬＰＳがｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄの固有の値を有することを意味する。
【０１９２】
[0203]この例では、ｖｐｓ＿ｉｄは、このレイヤパラメータセットが参照するビデオパラメータセットを識別する。
【０１９３】
[0204]この例では、０に等しいｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素がレイヤパラメータセットＲＢＳＰシンタックス構造中に存在しないことを指定する。この例では、ｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、今度のＨＥＶＣ規格に従うと、ビットストリーム中で０に等しくなり得る。ｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約される。ビデオデコーダ３０などのデコーダは、レイヤパラメータセットＮＡＬユニット中のｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１に続くすべてのデータを無視し得る。
【０１９４】
[0205]この例では、ｌｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、任意の値を有し得、今度のＨＥＶＣ規格において規定されるプロファイルへの準拠に影響を及ぼさない。
【０１９５】
[0206]他のシンタックス要素は、ＨＥＶＣ  ＷＤのＳＰＳにおける名前と同じ名前を有するシンタックス要素と同じセマンティクスを有し得るが、このＬＰＳを参照するピクチャのみに適用される。
【０１９６】
[0207]ＬＰＳは、ＮＡＬユニットに含まれ得、ＮＡＬユニットのヘッダは、上記の表８に従って定義され得る。次のシンタックス要素は、ＬＰＳに関連するとき、次のわずかに変更されたセマンティクスを有する。
【０１９７】
[0208]この例では、ｐｒｉｏｒｉｔｙ＿ｉｄは、このＬＰＳを参照するすべてのＮＡＬユニットのｐｒｉｏｒｉｔｙ＿ｉｄ値の最小値に等しい。
【０１９８】
[0209]この例では、ｔｅｍｐｏｒａｌ＿ｉｄは、このＬＰＳを参照するすべてのＮＡＬユニットのｔｅｍｐｏｒａｌ＿ｉｄの最小値に等しい。
【０１９９】
[0210]この例では、ｄｅｐｅｎｄｅｎｃｙ＿ｉｄは、このＬＰＳを参照するすべてのＮＡＬユニットのｄｅｐｅｎｄｅｎｃｙ＿ｉｄに等しい。
【０２００】
[0211]この例では、ｑｕａｌｉｔｙ＿ｉｄは、このＬＰＳを参照するすべてのＮＡＬユニットのｑｕａｌｉｔｙ＿ｉｄの最小値に等しい。
【０２０１】
[0212]この例では、ｖ＿ｉｄｘは、現在のＬＰＳのビューインデックスである。このＬＰＳを参照するすべてのピクチャは、ｖｉｅｗ＿ｉｄ［ｖ＿ｉｄｘ］のビューｉｄを有し得る。
【０２０２】
[0213]代替として、上記のシンタックス要素は、表１０の例に示すように、レイヤパラメータセットシンタックステーブル内で直接シグナリングされ得る。より詳細なシンタックステーブルは、以下の表９に従って設計され得る。この場合、これらのシンタックス要素は、ＬＰＳのＮＡＬユニットヘッダ中になく、ＬＰＳのパーシングは、ｖｐｓ＿ｉｄに等しいＩＤを有するＶＰＳに依存する可能性がある。
【表１０】
2015507428.tif 000017
【０２０３】
[0214]この場合のＬＰＳは、上記のシンタックス要素を複製するＮＡＬユニットヘッダを有する必要がない。ＬＰＳをカプセル化するＮＡＬユニットのＮＡＬユニットタイプがたとえば５であると仮定すると、ＮＡＬユニットヘッダシンタックスは、表１１に示すように、わずかに変更され得、表８の「ｉｆ」ステートメント中に例外（exception）「＆＆  ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ！＝５」を追加する。
【表１１−１】
2015507428.tif 000018
【表１１−２】
2015507428.tif 000019
【０２０４】
[0215]他の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、以下の表１２の例に示すように、固定長コーディングを使用してスケーラブル特性関連シンタックス要素をコーディングし得る。
【表１２】
2015507428.tif 000020
【０２０５】
[0216]表１３は、本開示の技法による、ピクチャパラメータセット（ＰＰＳ）のシンタックスの例を与える。この例では、ピクチャパラメータセットは、従来のＨＥＶＣのＰＰＳに反して、「ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ」をシグナリングする必要がない。
【表１３】
2015507428.tif 000021
【０２０６】
[0217]表１３のＰＰＳに関するセマンティクスの例について、以下で説明する。
【０２０７】
[0218]この例では、０に等しいｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇシンタックス要素がピクチャパラメータセットＲＢＳＰシンタックス構造中に存在しないことを指定する。この例では、ｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、今度のＨＥＶＣ規格に従うビットストリーム中で０に等しい。ｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約され得る。ビデオデコーダ３０などのデコーダは、ピクチャパラメータセットＮＡＬユニット中のｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１に続くすべてのデータを無視し得る。
【０２０８】
[0219]この例では、ｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、任意の値を有し得る。それは、今度のＨＥＶＣ規格に規定されるプロファイルへの準拠に必ずしも影響を及ぼさない。ｐｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇの値に関するセマンティクスは、ＨＥＶＣ規格のさらなる発展またはその規格の拡張において、本開示の技法と相反することなく割り当てられ得る。
【０２０９】
[0220]本開示の技法では、シーケンスパラメータセットｉｄまたはレイヤパラメータセットｉｄは、ＰＰＳにおいてシグナリングされる必要がない。ＰＰＳ中のいくつかの他のシンタックス要素は、ＬＰＳに移動され得る。すなわち、ビデオエンコーダ２０および／またはビデオデコーダ３０は、表１３に示すシンタックス要素と同様のデータを含む１つまたは複数のＬＰＳをコーディングするように構成され得る。
【０２１０】
[0221]図６は、例示的なグルーピングパラメータセット（ＧＰＳ）と、ＧＰＳと他のパラメータセットおよびスライスヘッダとの関係を示す概念図である。この例では、他のパラメータセットは、ＬＰＳ、ＳＰＳ、ＰＰＳ、タイプ０の適合パラメータセット（ＡＰＳ）（たとえば、ＡＰＳシグナリング適合ループフィルタ（ＡＬＦ）パラメータ）、タイプ１のＡＰＳ（たとえば、ＡＰＳシグナリング量子化行列）、および他のパラメータセットを含む。この例では、ＧＰＳは、各々が固有のＧＰＳ  ＩＤ（グループＩＤとも呼ばれる）を有する、複数の異なるグループを含み、各グループは、パラメータセットＩＤによって様々なパラメータセットの各々の特定の１つを示す。このように、スライスヘッダは、ｇｒｏｕｐ＿ｉｄを有するグループに対応するパラメータセットの各々を指定するために、そのｇｒｏｕｐ＿ｉｄだけを指定する必要がある。
【０２１１】
[0222]以下の表１４および表１５は、グルーピングパラメータセットＲＢＳＰに関するシンタックスの代替例を与える。
【表１４】
2015507428.tif 000022
【表１５】
2015507428.tif 000023
【０２１２】
[0223]ビデオエンコーダ２０およびビデオデコーダ３０などのビデオコーダは、たとえば表１４または表１５に従って、グルーピングパラメータセットをコーディングするように構成され得る。グルーピングパラメータセットのシンタックスに関するセマンティクスの例が、以下に与えられる。
【０２１３】
[0224]この例では、ｎｕｍｂｅｒ＿ｓｉｇｎａｌｌｅｄ＿ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐｓ＿ｍｉｎｕｓ１ｐｌｕｓ１は、シグナリングされるパラメータグループの数を指定する。この値は、両端値を含む０〜３０の範囲内であり得る。
【０２１４】
[0225]この例では、ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐ＿ｉｄ［ｉ］は、ｉ番目のシグナリングされたパラメータセットグループのＩＤを指定する。ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐ＿ｉｄ［ｉ］の値は、両端値を含む０〜３１の範囲内にあるべきである。
【０２１５】
[0226]この例では、ｐａｒａ＿ｓｅｔ＿ｔｙｐｅ＿ｉｄ［ｉ］［ｊ］は、ｉ番目のパラメータセットグループについてのｊ番目のパラメータセットタイプのＩＤを指定する。
【０２１６】
[0227]この例では、ｌｐｓ＿ｉｄ［ｉ］は、ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐ＿ｉｄ［ｉ］のグループｉｄを有するパラメータセットグループによって参照されるレイヤパラメータセットのｉｄを示す。ｌｐｓ＿ｉｄ［ｉ］に等しいｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄを有するＬＰＳのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値は、それぞれ、パラメータセットグループＮＡＬユニットのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値と同一であり得る。
【０２１７】
[0228]パラメータセットグルーピングＲＢＳＰのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値は、表１４および表１５の例における、このＲＢＳＰのＮＡＬユニットヘッダ中に存在し、ＬＰＳのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値は、このＬＰＳのＮＡＬユニットヘッダ中またはＬＰＳのシンタックステーブル中のいずれかに存在し得る。
【０２１８】
[0229]代替的に、ｌｐｓ＿ｉｄ［ｉ］に等しいｌａｙｅｒ＿ｐａｒａ＿ｓｅｔ＿ｉｄを有するＬＰＳのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値は、それぞれ、パラメータセットグループＮＡＬユニットのｄｅｐｅｎｄｅｎｃｙ＿ｉｄおよびｖｉｅｗ＿ｉｄｘの値と同一でない。
【０２１９】
[0230]この例では、ｐｐｓ＿ｉｄ［ｉ］は、ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐ＿ｉｄ［ｉ］のグループｉｄを有するパラメータセットグループによって参照されるピクチャパラメータセットのｉｄを示す。
【０２２０】
[0231]この例では、ａｐｓ＿ｉｄ［ｉ］は、ｐａｒａ＿ｓｅｔ＿ｇｒｏｕｐ＿ｉｄ［ｉ］のグループｉｄを有するパラメータセットグループによって参照される適合パラメータセットのｉｄを示す。
【０２２１】
[0232]この例では、０に等しいｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素がパラメータセットグルーピングＲＢＳＰシンタックス構造中に存在しないことを指定する。ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、今度のＨＥＶＣ規格に従うビットストリーム中で０に等しい。ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約され得る。ビデオデコーダ３０などのデコーダは、パラメータセットグルーピングＮＡＬユニット中のｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１に続くすべてのデータを無視し得る。概して、ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは任意の値を有し得る。それは、今度のＨＥＶＣ規格に規定されるプロファイルへの準拠に影響を及ぼす必要がない。
【０２２２】
[0233]いくつかの例では、ｐａｒａ＿ｓｅｔ＿ｔｙｐｅ＿ｉｄ［ｉ］［ｊ］は、代わりに、上述のａｐｓ＿ｉｄ［ｉ］と同様のセマンティクスを有するａｐｓ＿ｉｄ［ｉ］［ｊ］であり得る。
【０２２３】
[0234]図６に示すように、本開示の技法によれば、スライスヘッダ中のピクチャパラメータセットＩＤを参照する代わりに、スライスヘッダは、パラメータセットグループＩＤを参照し、したがって、間接的に、ＬＰＳ、ＰＰＳ、および各タイプのＡＰＳ（たとえばＡＬＦパラメータおよび量子化行列を与えるＡＰＳ）を参照し得る。
【０２２４】
[0235]ビデオコーダは、ＶＣＬ  ＮＡＬユニット（コーディングスライスを含む）が、たとえばＨ．２６４／ＡＶＣ設計主旨に基づいてパラメータセットを間接的に参照するとき、ビデオパラメータセットまたはレイヤパラメータセットをアクティブにすることができる。
【０２２５】
[0236]いくつかの例では、パラメータセットは、コード化スライスによってではなく、特定のタイプのＮＡＬユニットによってアクティブにされ得る。たとえば、この特定のタイプのＮＡＬユニットタイプ（パラメータセットアクティベーションＮＡＬユニット）は、ビットストリーム中に存在する場合、１つのかつ正確に１つのＶＰＳをアクティブにし得る。様々な選択肢において、さらに、そのようなタイプのＮＡＬユニットは、少なくとも１つのＬＰＳをアクティブにし得る。さらに、そのようなタイプのＮＡＬユニットは、少なくとも１つのＰＰＳをアクティブにすることができる。さらに、そのようなタイプのＮＡＬユニットは、少なくとも１つのＡＰＳをアクティブにし得る。パラメータセットアクティベーションＮＡＬユニットは、グルーピングパラメータセットＲＢＳＰであり得る。パラメータセットアクティベーション（ＰＳＡ）ＮＡＬユニットは、１つのコード化ビデオシーケンスに適用可能であり得る。ＰＳＡ  ＮＡＬユニットは、非ＶＣＬ  ＮＡＬユニットと見なされ、すなわちビデオコーダに直接関連がない。ＰＳＡ  ＮＡＬユニットのＮＡＬユニットヘッダシンタックスは、ＶＰＳ  ＮＡＬユニットと同じであり得る。
【０２２６】
[0237]いくつかの例では、ＰＳＡ  ＮＡＬユニットは、アクセスユニット中に存在する場合、アクセスユニットの第１のＶＣＬ  ＮＡＬユニットに先行し得る。たとえばＩＤＲピクチャなど、コード化ビデオシーケンスの第１のアクセスユニット中に少なくとも１つのＰＳＡ  ＮＡＬユニットが存在し得る。同じコード化ビデオシーケンス中の複数のＰＳＡ  ＮＡＬユニットは、同じＶＰＳ  ｉｄを含み得、したがって、異なるビデオパラメータセットが、同じコード化ビデオシーケンス内でアクティブにされる必要がない。ＰＳＡ  ＮＡＬユニットは、アクセスユニット中に存在する場合、任意のＬＰＳ、ＰＰＳ、ＡＰＳ、またはＳＥＩ  ＮＡＬユニット（存在する場合）に先行し得る。ＶＰＳ  ＮＡＬユニットは、アクセスユニット中に存在する場合、任意のＬＰＳ、ＰＰＳ、ＡＰＳ、またはＳＥＩ  ＮＡＬユニット（存在する場合）に先行し得る。様々な選択肢において、さらに、ＰＳＡ  ＮＡＬユニットは、アクセスユニット中に存在する場合、ＶＰＳ  ＮＡＬユニット（存在する場合）に先行し得る。
【０２２７】
[0238]いくつかの例では、ビデオエンコーダ２０およびビデオデコーダ３０などのビデオコーダは、たとえばＨＥＶＣの従来のシーケンスパラメータセット（ＳＰＳ）シンタックスとは反対に、ＳＰＳに関して表１６のシンタックスを利用するように構成され得る。
【表１６−１】
2015507428.tif 000024
【表１６−２】
2015507428.tif 000025
【表１６−３】
2015507428.tif 000026
【０２２８】
[0239]表１６の例示的なＳＰＳは、従来のＳＰＳシンタックスから、ｐｒｏｆｉｌｅ＿ｉｄｃ、ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿８ｂｉｔｓ、ｌｅｖｅｌ＿ｉｄｃ、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇおよび対応する条件文「ｉｆ」、ｍａｘ＿ｔｅｍｐｏｒａｌ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｃｒｏｐｐｉｎｇ＿ｆｌａｇ、ｐｉｃ＿ｃｒｏｐ＿ｌｅｆｔ＿ｏｆｆｓｅｔ、ｐｉｃ＿ｃｒｏｐ＿ｒｉｇｈｔ＿ｏｆｆｓｅｔ、ｐｉｃ＿ｃｒｏｐ＿ｔｏｐ＿ｏｆｆｓｅｔ、およびｐｉｃ＿ｃｒｏｐ＿ｂｏｔｔｏｍ＿ｏｆｆｓｅｔおよび対応する条件文「ｉｆ」ステートメント、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、ｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８、ｎｕｍ＿ｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔｓ、ならびにｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔ（ｉ）および対応する条件文「ｉｆ」ステートメントを除去する。さらに、表１６の例示的なＳＰＳは、ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄおよびｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘを追加する。他の残りのシンタックス要素についてのセマンティクスは、従来のＨＥＶＣにおいて定義されているものと同じであり得る。追加された要素ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄおよびｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘについてのセマンティクスは、次のように定義され得る。
【０２２９】
[0240]この例では、ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、現在のＳＰＳによって参照されるビデオパラメータセット（ＶＰＳ）を識別する。代替として、ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、シグナリングされる必要がなく、ＧＰＳは、ＳＰＳを特定のＶＰＳにリンクさせるために使用され得る。
【０２３０】
[0241]この例では、ｒｅｐ＿ｆｏｒｍａｔ＿ｉｄｘは、参照されるビデオパラメータセットにおいてシグナリングされる表示フォーマットへのインデックスを指定する。
【０２３１】
[0242]さらに別の代替として、表１７は、グルーピングパラメータセットについてのシンタックスの別の例を与える。この例では、ビデオパラメータセットＩＤシンタックス要素が、上述のように、ＳＰＳシンタックス中に存在しないことを仮定する。
【表１７】
2015507428.tif 000027
【０２３２】
[0243]表１７のシンタックス要素に関するセマンティクスは、次のように定義され得る。
【０２３３】
[0244]この例では、ｇｐｓ＿ｉｄは、グループパラメータセット（ＧＰＳ）の識別子を指定する。
【０２３４】
[0245]この例では、ｖｐｓ＿ｉｄは、ＧＰＳによって参照されるビデオパラメータセットの識別子を指定する。
【０２３５】
[0246]この例では、ｓｐｓ＿ｉｄは、ＧＰＳによって参照されるシーケンスパラメータセットの識別子を指定する。
【０２３６】
[0247]この例では、ｐｐｓ＿ｉｄは、ＧＰＳによって参照されるピクチャシーケンスパラメータセットの識別子を指定する。
【０２３７】
[0248]この例では、ｎｕｍ＿ｒｅｆ＿ａｐｓ＿ｉｄｓは、次のｒｅｆ＿ａｐｓ＿ｉｄ［ｉ］シンタックス要素の数を指定する。ｎｕｍ＿ｒｅｆ＿ａｐｓ＿ｉｄｓの値は、両端値を含む０〜４の範囲内であるべきである。
【０２３８】
[0249]この例では、ｒｅｆ＿ａｐｓ＿ｉｄ［ｉ］は、グループパラメータセットによって参照されるｉ番目の適合パラメータセットを識別する。
【０２３９】
[0250]ｒｅｆ＿ａｐｓ＿ｉｄ［ｉ］の同じ値は、ループに２度以上存在し得、したがって、同じＡＰＳからＡＰＳパラメータの２つ以上のタイプが、同じＧＰＳによって参照され得、当該ＧＰＳを参照するコード化スライスに適用し得る。
【０２４０】
[0251]この例では、ｒｅｆ＿ａｐｓ＿ｐａｒａｍ＿ｔｙｐｅ［ｉ］は、グループパラメータセットによって参照されるｉ番目の適合パラメータセットに含まれるＡＰＳパラメータのタイプを指定する。ｒｅｆ＿ａｐｓ＿ｐａｒａｍｅ＿ｔｙｐｅ［ｉ］の値は、両端値を含む０〜３の範囲内であり得る。ｒｅｆ＿ａｐｓ＿ｐａｒａｍｅ＿ｔｙｐｅ［ｉ］に関する両端値を含む０〜３の値は、スケーリングリスト、デブロッッキングフィルタ、サンプル適合オフセット（ＳＡＯ）、およびＡＬＦのＡＰＳパラメータタイプにそれぞれ対応する。ｉの任意の２つの異なる値についてのｒｅｆ＿ａｐｓ＿ｐａｒａｍｅ＿ｔｙｐｅ［ｉ］の値は、いくつかの例では、同一となるべきでない。
【０２４１】
[0252]この例では、０に等しいｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックス要素がパラメータセットグルーピングＲＢＳＰシンタックス構造中に存在しないことを指定する。ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは、今度のＨＥＶＣ規格に従うビットストリーム中で０に等しい。ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの１という値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約され得る。ビデオデコーダ３０などのデコーダは、パラメータセットグルーピングＮＡＬユニット中のｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇの値１に続くすべてのデータを無視し得る。
【０２４２】
[0253]この例では、ｇｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇは、任意の値を有し得る。それは、今度のＨＥＶＣ規格に規定されるプロファイルへの準拠に影響を及ぼす必要がない。
【０２４３】
[0254]ビデオエンコーダ２０およびビデオデコーダ３０などのビデオコーダは、ＧＰＳが表１７に従って指定されるか、または表１７の例に実質的に準拠するとき、シングルレイヤまたはシングルビュービットストリームについてのパラメータセットをアクティブにするために次のプロセスを適用し得る。
【０２４４】
[0255]適合パラメータセットＲＢＳＰは、コード化スライスＮＡＬユニットによって参照される１つまたは複数のグループパラメータセットを介して１つまたは複数のコード化ピクチャのコード化スライスＮＡＬユニットによって間接的に参照され得るパラメータを含み得る。各適合パラメータセットＲＢＳＰは、最初は、復号プロセスの動作の開始時にアクティブでないと見なされ得る。復号プロセスの動作中の所与の瞬間において、多くとも１つの適合パラメータセットＲＢＳＰが、ＡＰＳパラメータの各タイプについてアクティブであると見なされ、ＡＰＳパラメータの特定のタイプについての任意の特定の適合パラメータセットＲＢＳＰのアクティブ化は、ＡＰＳパラメータのその特定のタイプに関して、（もしあれば）前のアクティブ適合パラメータセットＲＢＳＰの非アクティブ化を生じる。
【０２４５】
[0256]適合パラメータセットＲＢＳＰ（ａｐｓ＿ｉｄの特定の値を有する）は、ＡＰＳパラメータの特定のタイプについてアクティブでなく、コード化スライスＮＡＬユニットによって参照されるグループパラメータセットを介して（ａｐｓ＿ｉｄのその値を使用して）ＡＰＳパラメータのその特定のタイプについてのコード化スライスＮＡＬユニットによって間接的に参照されるとき、ＡＰＳパラメータのその特定のタイプについてアクティブにされ得る。この適合パラメータセットＲＢＳＰは、それがＡＰＳパラメータのその特定のタイプについての別の適合パラメータセットＲＢＳＰのアクティブ化によって非アクティブにされるまで、ＡＰＳパラメータのその特定のタイプに関するアクティブ適合パラメータセットＲＢＳＰと呼ばれる。ａｐｓ＿ｉｄのその特定の値を有する適合パラメータセットＲＢＳＰは、そのアクティブ化より前の復号プロセスに利用可能であり得る。
【０２４６】
[0257]ピクチャパラメータセットＲＢＳＰは、１つまたは複数のコード化ピクチャのコード化スライスＮＡＬユニットによって、当該コード化スライスＮＡＬユニットによって参照される１つまたは複数のグループパラメータセットを介して間接的に参照され得るパラメータを含み得る。各ピクチャパラメータセットＲＢＳＰは、最初は、復号プロセスの動作の開始時にアクティブでないと見なされ得る。多くとも１つのピクチャパラメータセットＲＢＳＰが、復号プロセスの動作中の所与の瞬間においてアクティブであると見なされ得、任意の特定のピクチャパラメータセットＲＢＳＰのアクティブ化は、（もしあれば）前のアクティブピクチャパラメータセットＲＢＳＰの非アクティブ化を生じる。
【０２４７】
[0258]ピクチャパラメータセットＲＢＳＰ（ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの特定の値を有する）は、アクティブでなく、（ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその値を使用して）コード化スライスＮＡＬユニットによって、当該コード化スライスＮＡＬユニットによって参照されるグループパラメータセットを介して間接的に参照されるとき、アクティブにされ得る。このピクチャパラメータセットＲＢＳＰは、それが別のピクチャパラメータセットＲＢＳＰのアクティブ化によって非アクティブにされるまで、アクティブピクチャパラメータセットＲＢＳＰと呼ばれる。ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその特定の値を有するピクチャパラメータセットＲＢＳＰは、そのアクティブ化より前の復号プロセスに利用可能であり得る。
【０２４８】
[0259]コード化ピクチャのアクティブピクチャパラメータセットＲＢＳＰについてのｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を含む任意のピクチャパラメータセットＮＡＬユニットは、当該コード化ピクチャの最後のＶＣＬ  ＮＡＬユニットに続き、別のコード化ピクチャの第１のＶＣＬ  ＮＡＬユニットに先行しなければ、当該コード化ピクチャについてのアクティブピクチャパラメータセットＲＢＳＰと同じコンテンツを有し得る。
【０２４９】
[0260]シーケンスパラメータセットＲＢＳＰは、１つまたは複数のコード化ピクチャのコード化スライスＮＡＬユニットによって、当該コード化スライスＮＡＬユニットによって参照される１つまたは複数のグループパラメータセットを介して、間接的に参照されるか、または、バッファリング期間ＳＥＩメッセージを含む１つまたは複数のＳＥＩ  ＮＡＬユニットによって参照される、パラメータを含み得る。各シーケンスパラメータセットＲＢＳＰは、最初は、復号プロセスの動作の開始時にアクティブでないと見なされ得る。多くとも１つのシーケンスパラメータセットＲＢＳＰが、復号プロセスの動作中の所与の瞬間においてアクティブであると見なされ得、任意の特定のシーケンスパラメータセットＲＢＳＰのアクティブ化は、（もしあれば）前のアクティブシーケンスパラメータセットＲＢＳＰの非アクティブ化を生じる。
【０２５０】
[0261]シーケンスパラメータセットＲＢＳＰ（ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの特定の値を有する）は、まだアクティブでなく、コード化スライスＮＡＬユニットによって、（ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその値を使用して）当該コード化スライスＮＡＬユニットによって参照されるグループパラメータセットを介して、間接的に参照されるか、または（ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその値を使用して）バッファリング期間ＳＥＩメッセージを含むＳＥＩ  ＮＡＬユニットによって参照されるとき、アクティブにされ得る。このシーケンスパラメータセットＲＢＳＰは、それが別のシーケンスパラメータセットＲＢＳＰのアクティブ化によって非アクティブにされるまで、アクティブシーケンスパラメータセットＲＢＳＰと呼ばれる。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその特定の値を有し、０に等しいｔｅｍｐｏｒａｌ＿ｉｄを有するアクセスユニット内に含まれるシーケンスパラメータセットＲＢＳＰは、そのアクティブ化より前の復号プロセスに利用可能であり得る。アクティブ化シーケンスパラメータセットＲＢＳＰは、コード化ビデオシーケンス全体についてアクティブのままであるべきである。
【０２５１】
[0262]ビデオパラメータセットＲＢＳＰは、１つまたは複数のコード化ピクチャのコード化スライスＮＡＬユニットによって、当該コード化スライスＮＡＬユニットによって参照される１つまたは複数のグループパラメータセットを介して間接的に参照され得るか、またはバッファリング期間ＳＥＩメッセージを含む１つまたは複数のＳＥＩ  ＮＡＬユニットによって参照され得る、パラメータを含み得る。各ビデオパラメータセットＲＢＳＰは、最初は、復号プロセスの動作の開始時にアクティブでないと見なされ得る。多くとも１つのビデオパラメータセットＲＢＳＰが、復号プロセスの動作中の所与の瞬間においてアクティブであると見なされ得、任意の特定のビデオパラメータセットＲＢＳＰのアクティブ化は、（もしあれば）前のアクティブビデオパラメータセットＲＢＳＰの非アクティブ化を生じる。
【０２５２】
[0263]ビデオパラメータセットＲＢＳＰ（ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの特定の値を有する）は、まだアクティブでなく、コード化スライスＮＡＬユニットによって、（ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその値を使用して）当該コード化スライスＮＡＬユニットによって参照されるグループパラメータセットを介して、間接的に参照されるか、または、（ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその値を使用して）バッファリング期間ＳＥＩメッセージを含むＳＥＩ  ＮＡＬユニットによって参照されるとき、アクティブにされ得る。このビデオパラメータセットＲＢＳＰは、それが別のビデオパラメータセットＲＢＳＰのアクティブ化によって非アクティブにされるまで、アクティブビデオパラメータセットＲＢＳＰと呼ばれる。ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄのその特定の値を有し、０に等しいｔｅｍｐｏｒａｌ＿ｉｄを有するアクセスユニット内に含まれるビデオパラメータセットＲＢＳＰは、そのアクティブ化より前の復号プロセスに利用可能であるべきである。アクティブ化されたビデオパラメータセットＲＢＳＰは、コーディングビデオシーケンス全体についてアクティブのままであるべきである。
【０２５３】
[0264]コード化ビデオシーケンスのアクティブシーケンスパラメータセットＲＢＳＰについてのｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を含む任意のシーケンスパラメータセットＮＡＬユニットは、コード化ビデオシーケンスの最後のアクセスユニットに続き、別のコード化ビデオシーケンスの第１のＶＣＬ  ＮＡＬユニットおよびバッファリング期間ＳＥＩメッセージを含む第１のＳＥＩ  ＮＡＬユニット（存在する場合）に先行しなければ、コード化ビデオシーケンスについてのアクティブシーケンスパラメータセットＲＢＳＰと同じコンテンツを有し得る。
【０２５４】
[0265]コード化ビデオシーケンスのアクティブビデオパラメータセットＲＢＳＰについてのｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を含む任意のビデオパラメータセットＮＡＬユニットは、コード化ビデオシーケンスの最後のアクセスユニットに続き、別のコード化ビデオシーケンスの第１のＶＣＬ  ＮＡＬユニットおよびバッファリング期間ＳＥＩメッセージ（存在する場合）を含む第１のＳＥＩ  ＮＡＬユニットに先行することができなければ、コーディングビデオシーケンスに関するアクティブビデオパラメータセットＲＢＳＰと同じコンテンツを有し得る。
【０２５５】
[0266]ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、および適合パラメータセットにおけるシンタックス要素の値（およびこれらのシンタックス要素から派生した変数の値）および他のシンタックス要素の値の間の関係に対して表現されるすべての制約は、ＡＰＳパラメータの各特定のタイプについてのアクティブビデオパラメータセット、アクティブシーケンスパラメータセット、アクティブピクチャパラメータセット、およびアクティブ適合パラメータセットだけに適用し得る制約の表現である。ビットストリーム中でアクティブにされない任意のビデオパラメータセットＲＢＳＰが存在する場合、そのシンタックス要素は、他の準拠するビットストリームにおける参照によってアクティブにされる場合、指定された制約に準拠する値を有し得る。ビットストリーム中でアクティブにされない任意のシーケンスパラメータセットＲＢＳＰが存在する場合、そのシンタックス要素は、他の準拠するビットストリームにおける参照によってアクティブにされる場合、指定された制約に準拠する値を有し得る。ビットストリーム中で絶対にアクティブにされない任意のピクチャパラメータセットＲＢＳＰが存在する場合、そのシンタックス要素は、他の準拠するビットストリームにおける参照によってアクティブにされる場合、指定された制約に準拠する値を有し得る。ビットストリーム中で絶対にアクティブにされない任意の適合パラメータセットＲＢＳＰが存在する場合、そのシンタックス要素は、他の準拠するビットストリームにおける参照によってアクティブにされる場合、指定された制約に準拠する値を有し得る。
【０２５６】
[0267]復号プロセスの動作中、ＡＰＳパラメータの各タイプについてのアクティブビデオパラメータセット、アクティブシーケンスパラメータセット、アクティブピクチャパラメータセット、およびアクティブ適合パラメータセットのパラメータの値は、有効であるとみなされ得る。ＳＥＩメッセージの解釈に関して、同じアクセスユニット内のコード化ピクチャのＶＣＬ  ＮＡＬユニットの復号プロセスの動作についてアクティブである、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、および適合パラメータセットのパラメータの値は、そうではなくＳＥＩメッセージセマンティクスで規定されていないならば、有効であるとみなされ得る。
【０２５７】
[0268]図７は、本開示の技法による、ビデオデータを符号化するための例示的な方法を示すフローチャートである。ビデオエンコーダ２０に関して説明するが、他のビデオ符号化デバイスは図７の方法を実行するように構成され得ることを理解されたい。
【０２５８】
[0269]最初に、この例では、ビデオエンコーダ２０は、ロー（raw）ビデオデータの１つまたは複数のレイヤを含むビットストリームを受信する（１００）。たとえば、ビデオソース１８（図１）は、ビデオエンコーダ２０にマルチビュービデオデータを与え得る。代替として、ビデオエンコーダ２０またはそのプリプロセッサは、ロービデオビットストリームを複数の様々なレイヤ、たとえば空間解像度レイヤ、品質レイヤ、時間レイヤなどに分割することができる。さらに他の例では、ビットストリームは、様々なレイヤの組合せ、たとえば、ビュー、空間解像度レイヤ、品質レイヤ、時間レイヤなどの任意の組合せに区分され得る。
【０２５９】
[0270]ビデオエンコーダ２０は、レイヤのセットのなかから、対応するシーケンスについて１つまたは複数の共通のパラメータを決定し得る（１０２）。対応するシーケンスは、異なるレイヤにおいて対応する時間位置を有するシーケンスであり得る。すなわち、開始時刻（表示時刻に関する）Ｔ１および終了時刻（同様に表示時刻に関する）Ｔ２を有する第１のシーケンスと、同様に開始時刻Ｔ１および終了時刻Ｔ２を有する第２のシーケンスとは、互いに対応すると言われ得る。特に、第１のシーケンスは、第１のレイヤの一部を形成し得、第２のシーケンスは、第２の異なるレイヤの一部を形成し得る。「シーケンス」は、たとえば、復号順序において瞬時復号リフレッシュ（ＩＤＲ）ピクチャで開始し、続くＩＤＲピクチャの直前に終了する、復号順序における一連の連続するピクチャを含み得る。概して、パラメータは、１つまたは複数のレイヤ、たとえばＮ個のレイヤ（Ｎは整数）の1セットの対応するシーケンスに対応し得る。次いで、ビデオエンコーダ２０は、決定されたパラメータについてのデータを含むＶＰＳを符号化し得る（１０４）。たとえば、ビデオエンコーダ２０は、表２または表５の例のうちの１つに対応するＶＰＳをコーディングし得る。
【０２６０】
[0271]ビデオエンコーダ２０はまた、１つのレイヤ内の１つのシーケンスについて共通のパラメータを決定し得る（１０６）。当該シーケンスは、ＶＰＳがコーディングされた他のレイヤにおける他のシーケンスに対応するシーケンスのうちの１つを備え得る。ビデオエンコーダ２０は、当該シーケンスの共通のパラメータを含むシーケンスパラメータセット（ＳＰＳ）をコーディングし得る（１０８）。したがって、ＶＰＳおよびＳＰＳは、別のデータ構造であり、ビデオデータの異なるタイプに対応することを理解されたい。ＶＰＳが、複数のレイヤ間の1セットの対応するシーケンスに対応し得る一方、ＳＰＳは、１つのレイヤ内の１つのシーケンスに対応する。ＳＰＳは、Ｈ．２６４／ＡＶＣのＳＰＳ、（上記の表１に示す）ＭＶＣによって拡張されたＨ．２６４／ＡＶＣのＳＰＳ、今度のＨＥＶＣ規格、または上述の表１６の例に実質的に準拠し得る。さらに、ビデオエンコーダ２０は、シーケンス内のピクチャについてのピクチャパラメータセット（ＰＰＳ）をコーディングし得る（１１０）。ＰＰＳは、Ｈ．２６４／ＡＶＣのＳＰＳ、今度のＨＥＶＣ規格、または上述の表１３の例に実質的に準拠し得る。図７の方法は１つのＰＰＳだけのコーディングを示すが、複数のＰＰＳがコーディングされ得ることを理解されたい。１つまたは複数のピクチャが、同じＰＰＳを参照し得る。
【０２６１】
[0272]次いで、ビデオエンコーダ２０は、ＳＰＳおよびＰＰＳがコーディングされた最新のレイヤが最終レイヤかどうかを決定し得る（１１２）。最終レイヤがまだ処理（address）されていない場合（１１２の「ＮＯ」分岐）、ビデオエンコーダ２０は、次のレイヤを選択し、たとえば、ステップ１０６〜１１０に従って、次のレイヤについてＳＰＳおよび１つまたは複数のＰＰＳをコーディングし得る。最終レイヤが処理された後（１１２の「ＹＥＳ」分岐）、ビデオエンコーダ２０は、ＶＰＳ、ＳＰＳ、およびＰＰＳのデータに基づいて様々なレイヤのビデオデータを符号化し得る。ＶＰＳに少なくとも部分的に基づいてビデオデータをコーディングする様々な例は、図９〜図１２に関して以下でより詳細に説明する。
【０２６２】
[0273]図７の例には示されていないが、いくつかの例では、ビデオエンコーダ２０は、上述のように、１つもしくは複数のＬＰＳ、および／または１つもしくは複数のＧＰＳをさらに符号化することができる。ＬＰＳは、表９、表１０、または表１２の例に実質的に準拠し得るが、ＧＰＳは、表１４、表１５、または表１７の例に実質的に準拠し得る。そのような例では、ビデオエンコーダ２０はまた、ＬＰＳおよび／またはＧＰＳに少なくとも部分的に基づいて、ビデオデータをコーディングする。
【０２６３】
[0274]このように、図７の方法は、各々がビデオパラメータセット（ＶＰＳ）を参照する、ビデオデータの１つまたは複数のレイヤに関するＶＰＳをコーディングすることと、ＶＰＳに少なくとも部分的に基づいてビデオデータの１つまたは複数のレイヤをコーディングすることとを含む方法の例を表す。
【０２６４】
[0275]図８は、本開示の技法による、ビデオデータを復号するための例示的な方法を示すフローチャートである。ビデオデコーダ３０に関して説明するが、他のビデオ復号デバイスは図８の方法を実行するように構成され得ることを理解されたい。
【０２６５】
[0276]最初に、ビデオデコーダ３０は、コーディングビデオデータのレイヤについてのＶＰＳ、１つまたは複数のＳＰＳ、および１つまたは複数のＰＰＳを含むビットストリームを受信する（１２０）。ビデオデコーダ３０は、次いで、１つまたは複数のレイヤのうち、対応するシーケンスについての共通のパラメータを含むＶＰＳを復号し得る（１２２）。同様に、ビデオデコーダ３０は、１つのレイヤのシーケンスについて共通のパラメータを含むシーケンスパラメータセットを復号し得る（１２４）。さらに、ビデオデコーダ３０は、当該シーケンスのピクチャについてのパラメータを含むピクチャパラメータセットを復号し得る（１２６）。上述のように、１つまたは複数のピクチャは、同じＰＰＳを参照することができ、したがって、ＰＰＳのパラメータは、１つまたは複数のピクチャに共通であると見なされ得る。同様に、ビデオデコーダ３０は、図８には示されていないが、当該シーケンスについての複数のＰＰＳを復号し得る。
【０２６６】
[0277]さらに、ビデオデコーダ３０は、最新のレイヤが処理されるべき最終レイヤであったかどうかを決定し得る（１２８）。最新のレイヤが最終レイヤでない場合（１２８の「ＮＯ」分岐）、ビデオデコーダ３０は、ステップ１２４〜１２６に従って、次のレイヤについてのＳＰＳおよび１つまたは複数のＰＰＳを復号するために進む。一方、最新のレイヤが最終レイヤであった場合（１２８の「ＹＥＳ」分岐）、ビデオデコーダ３０は、ＶＰＳ、ＳＰＳ、およびＰＰＳに基づいてレイヤのビデオデータを復号するために進み得る（１３０）。ＶＰＳに少なくとも部分的に基づいてビデオデータをコーディングする例は、図９〜図１２に関してより詳細に説明する。
【０２６７】
[0278]図８の例には示されていないが、いくつかの例では、ビデオデコーダ３０は、上述のように、１つもしくは複数のＬＰＳ、および／または１つもしくは複数のＧＰＳをさらに復号し得る。ＬＰＳは、表９、表１０、または表１２の例に実質的に準拠し得るが、ＧＰＳは、表１４、表１５、または表１７の例に実質的に準拠し得る。そのような例では、ビデオデコーダ３０はまた、ＬＰＳおよび／またはＧＰＳに少なくとも部分的に基づいて、ビデオデータを復号する。
【０２６８】
[0279]このように、図８の方法は、ビデオデータの１つまたは複数のレイヤについてのビデオパラメータセット（ＶＰＳ）をコーディングすることと、ビデオデータの該１つまたは複数のレイヤのそれぞれは該ＶＰＳを参照し、該ＶＰＳに少なくとも部分的に基づいてビデオデータの該１つまたは複数のレイヤをコーディングすることと、を含む方法の例を表す。
【０２６９】
[0280]図９は、ＶＰＳにおいてシグナリングされる時間レイヤの数に少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャートである。図９の方法は、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得る。例として、図９の方法についてビデオデコーダ３０に関して説明する。
【０２７０】
[0281]この例では、ビデオデコーダ３０は、たとえばＶＰＳが対応する１つまたは複数のレイヤのうちの、ビデオデータ中の時間レイヤの数を示すＶＰＳをコーディング（すなわち、復号）する（１５０）。たとえば、ビデオデコーダ３０は、上記の表２に関して説明したように、「ｃｎｔ＿ｔ」を復号し得る。別の例として、ビデオデコーダ３０は、上記の表５に関して説明したように、ｎｕｍ＿ｔｅｍｐｏｒａｌ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１を復号し得る。
【０２７１】
[0282]この例では、ビデオデコーダ３０は、この表示に基づいて、時間レイヤの各々についての時間識別子を復号する（１５２）。同様に、ビデオデコーダ３０は、時間レイヤの数に基づいて参照ピクチャ識別子値を決定し得る（１５４）。たとえば、ビデオデコーダ３０は、レイヤＮにおける現在のピクチャについて、現在のピクチャが、参照のためにレイヤＮ＋１におけるピクチャまたはそれより上のレイヤのピクチャを使用しないことを決定するように構成され得る。したがって、ビデオデコーダ３０は、レイヤＮにおけるピクチャまたはそれより下のレイヤにおける潜在的な参照ピクチャについての識別子を決定し得る。さらに、ビデオデコーダ３０は、レイヤＮ（レイヤＮを含む）までのレイヤの参照データを使用して時間レイヤＮにおけるピクチャのデータを復号し得る（１５６）。したがって、図９は、ビデオデータの１つまたは複数のレイヤ中の時間レイヤの最大数を示すＶＰＳのデータをコーディングすることと、該ＶＰＳに少なくとも部分的に基づいて該１つまたは複数のレイヤをコーディングすることとを含む方法の例を表す。
【０２７２】
[0283]図１０は、復号ピクチャバッファに記憶される１つまたは複数のレイヤおよびピクチャにおいて並べ替えられるピクチャの数に少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャートである。図１０の方法は、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得る。例として、図１０の方法についてビデオデコーダ３０に関して説明する。
【０２７３】
[0284]この例では、ビデオデコーダ３０は、所与の時刻における、ビデオデータの１つまたは複数のレイヤにおいて並べ替えられるピクチャの数と、復号ピクチャバッファ（たとえば、参照ピクチャメモリ８２）に記憶されるピクチャの数とを示すＶＰＳを復号する（１６０）。たとえば、ビデオデコーダ３０は、上記の表１６および／またはＤＰＢサイズを指定するビットストリーム制限情報に関して説明したように、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｐｉｃｓに実質的に対応するＶＰＳのシンタックス要素を復号し得る。他の例では、ＶＰＳは、並べ替えられるピクチャの数、および復号ピクチャバッファに記憶されるピクチャの数の一方または他方のみを含み、必ずしも両方を含む必要はない。ビデオデコーダ３０は、次いで、並べ替えられるピクチャおよび／または記憶されるピクチャの数に基づいて復号ピクチャバッファ（たとえば、参照ピクチャメモリ８２）を管理することができる（１６２）。たとえば、ビデオデコーダ３０は、記憶されるべきピクチャの数を超えるピクチャが、参照ピクチャメモリ８２に記憶されるとき、参照ピクチャメモリ８２からピクチャを除去し得る。
【０２７４】
[0285]ビデオデコーダ３０は、ＤＰＢ中（すなわち、参照ピクチャメモリ８２中）のピクチャの数に基づいて参照ピクチャ識別子値を決定することもし得る（１６４）。さらに、ビデオデコーダ３０は、参照ピクチャ識別子値に基づいてピクチャのデータを復号し得る（１６６）。したがって、図１０の方法は、１つまたは複数のレイヤの復号中に復号ピクチャバッファ（ＤＰＢ）に記憶されるピクチャの数を示すＶＰＳのデータをコーディングすることを含む方法、および、１つまたは複数のレイヤのうちの少なくとも１つにおいて並べ替えられるフレームの数を示すＶＰＳのデータをコーディングすることを含む方法の例を表す。
【０２７５】
[0286]図１１は、ＶＰＳにおいてシグナリングされる仮想参照デコーダ（ＨＲＤ）パラメータに少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャートである。図１１の方法は、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得る。例として、図１１の方法についてビデオデコーダ３０に関して説明する。
【０２７６】
[0287]この例では、ビデオデコーダ３０は、ＨＲＤパラメータを示すＶＰＳを復号する（１７０）。ビデオデコーダ３０は、ＨＲＤパラメータに基づいてコーディングピクチャバッファ（ＣＰＢ）からのピクチャの除去タイム（removal time）をさらに決定することができる（１７２）。ビデオデコーダ３０は、次いで、決定された除去タイムに基づいてＣＰＢからデータを除去し（１７４）、ＣＰＢから除去されたデータを復号することができる。したがって、図１１の方法は、１つまたは複数の仮想参照デコーダ（ＨＲＤ）パラメータを示すＶＰＳのデータをコーディングすることと、該ＨＤＲパラメータに基づいて１つまたは複数のレイヤのデータをコーディングすることとを含む方法の例を表す。
【０２７７】
[0288]図１２は、ＶＰＳにおいてシグナリングされる拡張データに少なくとも部分的に基づいてビデオデータをコーディングする例示的な方法を示すフローチャートである。図１２の方法は、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得る。例として、図１２の方法についてビデオデコーダ３０に関して説明する。
【０２７８】
[0289]ビデオデコーダ３０は、この例では、ＶＰＳが拡張データを含むかどうかを示すＶＰＳのデータを復号する（１８０）。たとえば、ビデオデコーダ３０は、ＶＰＳのｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇを復号し得る。ビデオデコーダ３０は、次いで、ＶＰＳが拡張データを含むことをデータが示すどうかを決定する（１８２）。ＶＰＳが拡張データを含むことをデータが示す場合（１８２の「ＹＥＳ」分岐）、ビデオデコーダ３０は、１つまたは複数の拡張コーディングツールのためのＶＰＳ拡張データをコーディングし（１８４）、拡張コーディングツールおよび拡張データを使用してビデオデータを復号する（１８６）。他方、ＶＰＳが拡張データを含まないことをデータが示す場合（１８２の「ＮＯ」分岐）、ビデオデコーダ３０は、従来のコーディングツールを使用してビデオデータを復号し得る（１８８）。このように、図１２の方法は、ＶＰＳが対応する規格を超える拡張を含むかどうかを示すＶＰＳのデータ、およびＶＰＳが拡張を含むときの拡張のためのデータをコーディングすることと、該ＶＰＳの該拡張データに基づいてビデオデータをコーディングすることとを含む方法の例を表す。
【０２７９】
[0290]例によっては、本明細書で説明された技法のうちいずれかの、いくつかの行為またはイベントは、異なる順番で実行される可能性があり、追加され、統合され、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが、本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。
【０２８０】
[0291]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【０２８１】
[0292]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０２８２】
[0293]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
【０２８３】
[0294]さらに他の例では、本開示は、その上に記憶されたデータ構造を備えるコンピュータ可読媒体を企図し、データ構造は本開示に一致する符号化ビットストリームを含む。特に、符号化ビットストリームは、ビデオデータの１つまたは複数のレイヤと、ビデオデータの１つまたは複数のレイヤに関するビデオパラメータセット（ＶＰＳ）とを含むことができ、ビデオデータの１つまたは複数のレイヤ各々は、ＶＰＳを参照し、ビデオデータの１つまたは複数のレイヤは、ＶＰＳに少なくとも部分的に基づいてコーディングされる。
【０２８４】
[0295]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
【０２８５】
[0296]様々な例について説明してきた。これらおよび他の例は以下の特許請求の範囲内に入る。
【図１】
2015507428.tif 000028
【図２】
2015507428.tif 000029
【図３】
2015507428.tif 000030
【図５】
2015507428.tif 000031
【図６】
2015507428.tif 000032
【図７】
2015507428.tif 000033
【図８】
2015507428.tif 000034
【図９】
2015507428.tif 000035
【図１０】
2015507428.tif 000036
【図１１】
2015507428.tif 000037
【図１２】
2015507428.tif 000038
【図４】
2015507428.tif 000039
【国際調査報告】
2015507428.tif 000040
2015507428.tif 000041
2015507428.tif 000042
2015507428.tif 000043
2015507428.tif 000044