(57)【要約】  ビデオデータをコーディングするためのデバイスであって、本デバイスは、ビデオデータを記憶するように構成されたメモリと、ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測することと、ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測することとを行うように構成された１つまたは複数のプロセッサを備えるビデオコーダとを備える、デバイス。
2017508345.tif 000002
【特許請求の範囲】
【請求項１】
ビデオデータを復号する方法であって、前記方法が、
前記ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、
前記コーディングユニットに関連する複数のベクトルから、前記コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、
前記ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第１のクロマ参照ブロックが前記ピクチャ中にあり、
前記第１のクロマ参照ブロックに基づいて前記第１のクロマブロックを予測することと、
前記第１のクロマ参照ブロックの位置を特定するために使用されたのと同じベクトルを使用して、同じコーディングユニットの第２のクロマブロックのための第２のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、および前記第１のクロマ参照ブロックとは異なり、
前記第２のクロマ参照ブロックに基づいて前記コーディングユニットの前記第２のクロマブロックを予測することと
を備える、方法。
【請求項２】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、前記第１のクロマブロックが前記コーディングユニットの第１の予測ユニットに対応し、前記第２のクロマブロックが前記コーディングユニットの第２の予測ユニットに対応し、ここにおいて、前記コーディングユニットの前記第１のクロマブロックのための前記ベクトルを決定することが、前記第１の予測ユニットのためのベクトルを取得することを備える、請求項１に記載の方法。
【請求項３】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、各予測ユニットが、関連するベクトルを有し、前記方法が、
前記コーディングユニットの第１の予測ユニットに関連する前記ベクトルを使用して第１のルーマ参照ブロックの位置を特定することと、
前記コーディングユニットの前記第２の予測ユニットに関連する前記ベクトルを使用して第２のルーマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第１のクロマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第２のクロマ参照ブロックの位置を特定することと
をさらに備える、請求項１に記載の方法。
【請求項４】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：０であり、ここにおいて、前記複数のベクトルから決定された前記ベクトルが前記コーディングユニットの右下ブロックに関連する、請求項１に記載の方法。
【請求項５】
前記第２のクロマブロックが前記コーディングユニットの右上ブロックであり、前記方法は、
前記ベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第１の参照ブロックに基づいて第３のクロマブロックを予測することと、ここにおいて、前記第３のクロマブロックが前記コーディングユニットの左上ブロックであり、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記第２の参照ブロックに基づいて前記コーディングユニットの第４のクロマブロックを予測することと、ここにおいて、前記第４のクロマブロックが前記コーディングユニットの左下ブロックである、
をさらに備える、請求項４に記載の方法。
【請求項６】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：２であり、ここにおいて、前記第１のクロマブロックが右上ブロックであり、前記第２のクロマブロックが前記コーディングユニットの左上ブロックである、請求項１に記載の方法。
【請求項７】
前記コーディングユニットの第３のクロマブロックのための第２のベクトルを決定することと、
前記第２のベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第３のクロマブロックのための予測子として前記第３の参照ブロックを使用することと、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記コーディングユニットの第４のクロマブロックのための予測子として前記第４の参照ブロックを使用することと
をさらに備える、請求項６に記載の方法。
【請求項８】
前記コーディングユニットが残差データを備える、請求項１に記載の方法。
【請求項９】
ビデオデータを符号化する方法であって、前記方法は、
コーディングユニットに関連する複数のベクトルから、ピクチャのコーディングユニットの第１のクロマブロックのためのベクトルを決定することと、
前記ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第１のクロマ参照ブロックが前記ピクチャ中にあり、
前記第１のクロマ参照ブロックに基づいて前記第１のクロマブロックを予測することと、
前記第１のクロマ参照ブロックの位置を特定するために使用されたのと同じベクトルを使用して、同じコーディングユニットの第２のクロマブロックのための第２のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、および前記第１のクロマ参照ブロックとは異なり、
前記第２のクロマ参照ブロックに基づいて前記コーディングユニットの第２のクロマブロックを予測することと、
前記符号化ビデオデータ中に含めるために、前記ピクチャの前記コーディングユニットがイントラブロックコピーモードを使用してコーディングされているという指示と、前記コーディングユニットの各ルーマブロックのためのベクトルの指示とを生成することと
を備える、方法。
【請求項１０】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、前記第１のクロマブロックが第１の予測ユニットに対応し、前記第２のクロマブロックが第２の予測ユニットに対応し、ここにおいて、前記コーディングユニットの前記第２のクロマブロックのためのベクトルを決定することが、前記第１の予測ユニットのためのベクトルを取得することを備える、請求項９に記載の方法。
【請求項１１】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、各予測ユニットが、関連するベクトルを有し、前記方法が、
前記第１の予測ユニットに関連する前記ベクトルを使用して第１のルーマ参照ブロックの位置を特定することと、
前記第２の予測ユニットに関連する前記ベクトルを使用して第２のルーマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第１のクロマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第２のクロマ参照ブロックの位置を特定することと
をさらに備える、請求項９に記載の方法。
【請求項１２】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：０であり、ここにおいて、前記複数のベクトルから決定された前記ベクトルが前記コーディングユニットの右下ブロックに関連する、請求項９に記載の方法。
【請求項１３】
前記第２のクロマブロックが前記コーディングユニットの右上ブロックであり、前記方法は、
前記ベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第１の参照ブロックに基づいて第３のクロマブロックを予測することと、ここにおいて、前記第３のクロマブロックが前記コーディングユニットの左上ブロックであり、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記第２の参照ブロックに基づいて前記コーディングユニットの第４のクロマブロックを予測することと、ここにおいて、前記第４のクロマブロックが前記コーディングユニットの左下ブロックである、
をさらに備える、請求項１２に記載の方法。
【請求項１４】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：２であり、ここにおいて、前記第１のクロマブロックが右上ブロックであり、前記第２のクロマブロックが前記コーディングユニットの左上ブロックである、請求項９に記載の方法。
【請求項１５】
前記コーディングユニットの第３のクロマブロックのための第２のベクトルを決定することと、
前記第２のベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第３のクロマブロックのための予測子として前記第３の参照ブロックを使用することと、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記コーディングユニットの第４のクロマブロックのための予測子として前記第４の参照ブロックを使用することと
をさらに備える、請求項１４に記載の方法。
【請求項１６】
前記コーディングユニットが残差データを備える、請求項９に記載の方法。
【請求項１７】
ビデオデータをコーディングするためのデバイスであって、前記デバイスは、
ビデオデータを記憶するように構成されたメモリと、
コーディングユニットに関連する複数のベクトルから、前記ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、
前記コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、
前記ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第１のクロマ参照ブロックが前記ピクチャ中にあり、
前記第１のクロマ参照ブロックに基づいて前記第１のクロマブロックを予測することと、
前記第１のクロマ参照ブロックの位置を特定するために使用されたのと同じベクトルを使用して、同じコーディングユニットの第２のクロマブロックのための第２のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、および前記第１のクロマ参照ブロックとは異なり、
前記第２のクロマ参照ブロックに基づいて前記コーディングユニットの第２のクロマブロックを予測することと
を行うように構成された１つまたは複数のプロセッサを備えるビデオコーダと
を備える、デバイス。
【請求項１８】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、前記第１のクロマブロックが第１の予測ユニットに対応し、前記第２のクロマブロックが第２の予測ユニットに対応し、ここにおいて、前記コーディングユニットの前記第２のクロマブロックのためのベクトルを決定することが、前記第１の予測ユニットのためのベクトルを取得することを備える、請求項１７に記載のデバイス。
【請求項１９】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、各予測ユニットが、関連するベクトルを有し、ここにおいて、前記１つまたは複数のプロセッサが、
前記第１の予測ユニットに関連する前記ベクトルを使用して第１のルーマ参照ブロックの位置を特定することと、
前記第２の予測ユニットに関連する前記ベクトルを使用して第２のルーマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第１のクロマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第２のクロマ参照ブロックの位置を特定することと
を行うようにさらに構成された、請求項１７に記載のデバイス。
【請求項２０】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：０であり、ここにおいて、前記複数のベクトルから決定された前記ベクトルが前記コーディングユニットの右下ブロックに関連する、請求項１７に記載のデバイス。
【請求項２１】
前記第２のクロマブロックが前記コーディングユニットの右上ブロックであり、ここにおいて、前記１つまたは複数のプロセッサは、
前記ベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第１の参照ブロックに基づいて第３のクロマブロックを予測することと、ここにおいて、前記第３のクロマブロックが前記コーディングユニットの左上ブロックであり、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記第２の参照ブロックに基づいて前記コーディングユニットの第４のクロマブロックを予測することと、ここにおいて、前記第４のクロマブロックが前記コーディングユニットの左下ブロックである、
を行うようにさらに構成された、請求項２０に記載のデバイス。
【請求項２２】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：２であり、ここにおいて、前記第１のクロマブロックが右上ブロックであり、前記第２のクロマブロックが前記コーディングユニットの左上ブロックである、請求項１７に記載のデバイス。
【請求項２３】
前記１つまたは複数のプロセッサは、
前記コーディングユニットの第３のクロマブロックのための第２のベクトルを決定することと、
前記第２のベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第３のクロマブロックのための予測子として前記第３の参照ブロックを使用することと、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記コーディングユニットの第４のクロマブロックのための予測子として前記第４の参照ブロックを使用することと
を行うようにさらに構成された、請求項２２に記載のデバイス。
【請求項２４】
前記コーディングユニットが残差データを備える、請求項１７に記載のデバイス。
【請求項２５】
前記デバイスが、
マイクロプロセッサと、
集積回路（ＩＣ）と、
ビデオエンコーダを備えるワイヤレス通信デバイスと
のうちの１つを備える、請求項１７に記載のデバイス。
【請求項２６】
前記ビデオコーダがビデオエンコーダを備える、請求項１７に記載のデバイス。
【請求項２７】
前記ビデオコーダがビデオデコーダを備える、請求項１７に記載のデバイス。
【請求項２８】
ビデオデータをコーディングするための装置であって、前記装置は、
コーディングユニットに関連する複数のベクトルから、前記ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定するための手段と、
前記コーディングユニットの第１のクロマブロックのためのベクトルを決定するための手段と、
同じコーディングユニットの第２のクロマブロックのための第２のクロマ参照ブロックの位置を特定するために、第１のクロマ参照ブロックの位置を特定するために使用されたのと同じベクトルを使用するための手段と、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、および前記第１のクロマ参照ブロックとは異なり、
前記第１のクロマ参照ブロックに基づいて前記第１のクロマブロックを予測するための手段と、
前記ベクトルを使用して第２のクロマ参照ブロックの位置を特定するための手段と、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、
前記第２のクロマ参照ブロックに基づいて前記コーディングユニットの第２のクロマブロックを予測するための手段と
を備える、装置。
【請求項２９】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、前記第１のクロマブロックが第１の予測ユニットに対応し、前記第２のクロマブロックが第２の予測ユニットに対応し、ここにおいて、前記コーディングユニットの前記第２のクロマブロックのためのベクトルを決定するための手段が、前記第１の予測ユニットのためのベクトルを取得するための手段を備える、請求項２８に記載の装置。
【請求項３０】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、各予測ユニットが、関連するベクトルを有し、前記装置が、
前記第１の予測ユニットに関連する前記ベクトルを使用して第１のルーマ参照ブロックの位置を特定するための手段と、
前記第２の予測ユニットに関連する前記ベクトルを使用して第２のルーマ参照ブロックの位置を特定するための手段と、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第１のクロマ参照ブロックの位置を特定するための手段と、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第２のクロマ参照ブロックの位置を特定するための手段と
をさらに備える、請求項２８に記載の装置。
【請求項３１】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：０であり、ここにおいて、前記複数のベクトルから決定された前記ベクトルが前記コーディングユニットの右下ブロックに関連する、請求項２８に記載の装置。
【請求項３２】
前記第２のクロマブロックが前記コーディングユニットの右上ブロックであり、前記装置は、
前記ベクトルを使用して第３の参照ブロックの位置を特定するための手段と、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第１の参照ブロックに基づいて第３のクロマブロックを予測するための手段と、ここにおいて、前記第３のクロマブロックが前記コーディングユニットの左上ブロックであり、
前記ベクトルを使用して第４の参照ブロックの位置を特定するための手段と、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記第２の参照ブロックに基づいて前記コーディングユニットの第４のクロマブロックを予測するための手段と、ここにおいて、前記第４のクロマブロックが前記コーディングユニットの左下ブロックである、
をさらに備える、請求項３１に記載の装置。
【請求項３３】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：２であり、ここにおいて、前記第１のクロマブロックが右上ブロックであり、前記第２のクロマブロックが前記コーディングユニットの左上ブロックである、請求項２８に記載の装置。
【請求項３４】
前記コーディングユニットの第３のクロマブロックのための第２のベクトルを決定するための手段と、
前記第２のベクトルを使用して第３の参照ブロックの位置を特定するための手段と、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第３のクロマブロックのための予測子として前記第３の参照ブロックを使用するための手段と、
前記ベクトルを使用して第４の参照ブロックの位置を特定するための手段と、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記コーディングユニットの第４のクロマブロックのための予測子として前記第４の参照ブロックを使用するための手段と
をさらに備える、請求項３３に記載の装置。
【請求項３５】
前記コーディングユニットが残差データを備える、請求項２８に記載の装置。
【請求項３６】
１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
コーディングユニットに関連する複数のベクトルから、前記ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、
前記コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、
同じコーディングユニットの第２のクロマブロックのための第２のクロマ参照ブロックの位置を特定するために、第１のクロマ参照ブロックの位置を特定するために使用されたのと同じベクトルを使用することと、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、および前記第１のクロマ参照ブロックとは異なり、
前記第１のクロマ参照ブロックに基づいて前記第１のクロマブロックを予測することと、
前記ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、前記第２のクロマ参照ブロックが前記ピクチャ中にあり、
前記第２のクロマ参照ブロックに基づいて前記コーディングユニットの第２のクロマブロックを予測することと
を行わせる命令を記憶するコンピュータ可読記憶媒体。
【請求項３７】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、前記第１のクロマブロックが第１の予測ユニットに対応し、前記第２のクロマブロックが第２の予測ユニットに対応し、ここにおいて、前記コーディングユニットの前記第２のクロマブロックのためのベクトルを決定することが、前記第１の予測ユニットのためのベクトルを取得することを備える、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３８】
前記コーディングユニットが２つまたはそれ以上の予測ユニットを備え、ここにおいて、各予測ユニットが、関連するベクトルを有し、ここにおいて、前記コンピュータ可読記憶媒体が、前記１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
前記第１の予測ユニットに関連する前記ベクトルを使用して第１のルーマ参照ブロックの位置を特定することと、
前記第２の予測ユニットに関連する前記ベクトルを使用して第２のルーマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第１のクロマ参照ブロックの位置を特定することと、
前記第１の予測ユニットに関連する前記ベクトルを使用して前記第２のクロマ参照ブロックの位置を特定することと
を行わせるさらなる命令を記憶する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項３９】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：０であり、ここにおいて、前記複数のベクトルから決定された前記ベクトルが前記コーディングユニットの右下ブロックに関連する、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項４０】
前記第２のクロマブロックが前記コーディングユニットの右上ブロックであり、ここにおいて、前記コンピュータ可読記憶媒体は、前記１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
前記ベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第１の参照ブロックに基づいて第３のクロマブロックを予測することと、ここにおいて、前記第３のクロマブロックが前記コーディングユニットの左上ブロックである、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記第２の参照ブロックに基づいて前記コーディングユニットの第４のクロマブロックを予測することと、ここにおいて、前記第４のクロマブロックが前記コーディングユニットの左下ブロックである、
を行わせるさらなる命令を記憶する、請求項３９に記載のコンピュータ可読記憶媒体。
【請求項４１】
前記コーディングユニットのためのクロマサンプリングフォーマットが４：２：２であり、ここにおいて、前記第１のクロマブロックが右上ブロックであり、前記第２のクロマブロックが前記コーディングユニットの左上ブロックである、請求項３６に記載のコンピュータ可読記憶媒体。
【請求項４２】
前記１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
前記コーディングユニットの第３のクロマブロックのための第２のベクトルを決定することと、
前記第２のベクトルを使用して第３の参照ブロックの位置を特定することと、ここにおいて、前記第３の参照ブロックが前記ピクチャ中にあり、
前記第３のクロマブロックのための予測子として前記第３の参照ブロックを使用することと、
前記ベクトルを使用して第４の参照ブロックの位置を特定することと、ここにおいて、前記第４の参照ブロックが前記ピクチャ中にあり、
前記コーディングユニットの第４のクロマブロックのための予測子として前記第４の参照ブロックを使用することと
を行わせるさらなる命令を記憶する、請求項４１に記載のコンピュータ可読記憶媒体。
【請求項４３】
前記コーディングユニットが残差データを備える、請求項３６に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]本出願は、その各々の内容全体が参照により本明細書に組み込まれる、以下の米国仮出願、すなわち、２０１４年１月９日に出願された米国仮出願第６１／９２５，６４７号、２０１４年１月１０日に出願された米国仮出願第６１／９２６，２２４号の利益を主張する。
【０００２】
[0002]本開示はビデオコーディングに関し、より詳細には、他のビデオブロックに基づくビデオブロックの予測に関する。
【背景技術】
【０００３】
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００４】
[0004]ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を実行する。ブロックベースのビデオコーディングでは、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部分）がビデオブロックに区分され得、これらのビデオブロックは、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることもある。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００５】
[0005]空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコード化ブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコード化ブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換され、残差変換係数が生じ得、その残差変換係数は、次いで量子化され得る。最初に２次元アレイで構成される量子化変換係数は、変換係数の１次元ベクトルを生成するために走査され得、なお一層の圧縮を達成するためにエントロピーコーディングが適用され得る。
【発明の概要】
【０００６】
[0006]概して、本開示では、イントラＢＣまたはイントラＭＣモードと呼ばれることがある、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のためのモードを含むビデオデータをコーディングするための技法について説明する。
【０００７】
[0007]一例では、ビデオデータを復号する方法は、ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、コーディングユニットに関連する複数のベクトルから、コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測することと、ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測することとを含む。
【０００８】
[0008]別の例では、ビデオデータを符号化する方法は、コーディングユニットに関連する複数のベクトルから、ピクチャのコーディングユニットの第１のクロマブロックのためのベクトルを決定することと、ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測することと、ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測することと、符号化ビデオデータ中に含めるために、ピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされているという指示と、コーディングユニットの各ルーマブロックのためのベクトルの指示とを生成することとを含む。
【０００９】
[0009]別の例では、ビデオデータをコーディングするための装置は、コーディングユニットに関連する複数のベクトルから、ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定するための手段と、コーディングユニットの第１のクロマブロックのためのベクトルを決定するための手段と、ベクトルを使用して第１のクロマ参照ブロックの位置を特定するための手段と、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測するための手段と、ベクトルを使用して第２のクロマ参照ブロックの位置を特定するための手段と、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測するための手段とを含む。
【００１０】
[0010]ビデオデータをコーディングするためのデバイスであって、本デバイスは、ビデオデータを記憶するように構成されたメモリと、コーディングユニットに関連する複数のベクトルから、ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測することと、ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測することとを行うように構成された１つまたは複数のプロセッサを備えるビデオコーダとを備える、デバイス。
【００１１】
[0011]別の例では、１つまたは複数のプロセッサによって実行されたとき、１つまたは複数のプロセッサに、コーディングユニットに関連する複数のベクトルから、ビデオデータのピクチャのコーディングユニットがイントラブロックコピーモードを使用してコーディングされていると決定することと、コーディングユニットの第１のクロマブロックのためのベクトルを決定することと、ベクトルを使用して第１のクロマ参照ブロックの位置を特定することと、ここにおいて、第１のクロマ参照ブロックがピクチャ中にあり、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測することと、ベクトルを使用して第２のクロマ参照ブロックの位置を特定することと、ここにおいて、第２のクロマ参照ブロックがピクチャ中にあり、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測することとを行わせる命令を記憶するコンピュータ可読記憶媒体。
【００１２】
[0012]１つまたは複数の例の詳細が以下の添付の図面および説明に記載されている。他の特徴、目的、および利点は、説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１３】
【図１】[0013]本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２】[0014]本開示の技法による、現在ピクチャ内のビデオデータの現在ブロックを予測するための現在ピクチャ内のビデオデータの例示的な予測ブロックを示す概念図。
【図３】[0015]ビデオデータの予測ブロックがそこから選択され得る、対象とする領域を定義するための例示的な技法を示す概念図。
【図４】[0016]ビデオデータの現在ブロック、およびビデオデータの現在ブロックのための候補予測ベクトルがそこから導出され得るビデオデータの隣接ブロックの一例概念図。
【図５Ａ】[0017]マージモードのための空間隣接動きベクトル候補の一例を示す図。
【図５Ｂ】[0018]高度動きベクトル予測（ＡＭＶＰ：Advanced Motion Vector Prediction）モードのための空間隣接動きベクトル候補の一例を示す図。
【図６】[0019]本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図。
【図７】[0020]本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図。
【図８】[0021]本開示の技法によるビデオデータを符号化するための例示的な方法を示す流れ図。
【図９】[0022]本開示の技法によるビデオデータデータを復号するための例示的な方法を示す流れ図。
【発明を実施するための形態】
【００１４】
[0023]ビデオシーケンスは、概して、ピクチャのシーケンスとして表される。一般に、ブロックベースのコーディング技法は、個々のピクチャの各々をコーディングするために使用される。すなわち、各ピクチャはブロックに分割され、ブロックの各々は個別にコーディングされる。ビデオデータのブロックをコーディングすることは、概して、ブロックの予測値を形成することと、残差値、すなわち、元のブロックと予測値との間の差分をコーディングすることとを伴う。詳細には、ビデオデータの元のブロックはピクセル値の行列を含み、予測値は予測されたピクセル値の行列を含む。残差値は、元のブロックのピクセル値と予測されたピクセル値との間のピクセルごとの差分に対応する。
【００１５】
[0024]ビデオデータのブロックのための予測技法は、概して、イントラ予測およびインター予測としてカテゴリー分類される。イントラ予測、または空間予測は、概して、前にコーディングされたブロックの一部である隣接するピクセル値からブロックを予測することを伴う。インター予測、または時間予測は、概して、前にコーディングされたピクチャ（たとえば、フレームまたはスライス）のピクセル値からブロックを予測することを伴う。
【００１６】
[0025]リモートデスクトップ、リモートゲーミング、ワイヤレスディスプレイ、自動車インフォテインメント、クラウドコンピューティングなどの多くの適用例が日常生活におけるルーチンになりつつある。これらの適用例におけるビデオコンテンツは、通常、自然コンテンツ、テキスト、人工グラフィックス、および他のコンテンツの組合せである。テキストおよび人工グラフィックス領域では、（文字、アイコン、シンボルなどの）反復パターンがしばしば存在する。
【００１７】
[0026]イントラブロックコピー（イントラＢＣ）またはイントラ動き補償（イントラＭＣ）と呼ばれることがある、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測は、ビデオコーダが、そのような冗長性を除去し、イントラフレームコーディング効率を改善することを可能にし得る技法である。いくつかのビデオコーディング技法では、ビデオコーダは、現在ビデオブロックの予測のために、同じピクチャ中のビデオデータの現在ブロックのすぐ上またはすぐ下あるいは現在ブロックに対して水平方向に一直線上のいずれかにある、前に再構成されたビデオデータのブロックを使用し得る。言い換えれば、ビデオデータのピクチャまたはフレームが２Ｄグリッドに課された場合、ビデオデータの各ブロックは、ｘ値およびｙ値の一意の範囲を占有する。したがって、いくつかのビデオコーダは、ｘ値の同じセット（すなわち、現在ビデオブロックに対して垂直方向に一直線上にある）またはｙ値の同じセット（すなわち、現在ビデオブロックに対して水平方向に一直線上にある）のみを共有する同じピクチャ中の前にコーディングされたビデオデータのブロックに基づいてビデオデータの現在ブロックを予測し得る。
【００１８】
[0027]ビデオコーダが、必ずしもビデオデータの現在ブロックのすぐ上またはすぐ左（すぐ右またはすぐ下）にあるとは限らない、同じフレーム、すなわち、同じピクチャ内のビデオデータの前に再構成されたブロックから現在ビデオブロックを予測することが有利であり得る。予測セット中により多くのビデオブロックを含めることによって、ビデオコーダは、現在ビデオブロックのより正確な予測を実現し得、それによってコーディング効率が高まる。
【００１９】
[0028]概して、本開示では、イントラＢＣまたはイントラＭＣモードと呼ばれることがある、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のためのモードを含むビデオデータをコーディングするための技法について説明する。本開示のイントラＢＣまたはイントラＭＣ技法は、ビデオデータの現在ブロックのためのビデオデータの予測ブロックを識別することを含み得る。ビデオデータの予測ブロックは、たとえば、ビデオデータの現在ブロックと同じピクチャ内のビデオデータの再構成されたブロックに対応し得る。ビデオデータの予測ブロックは、ピクチャ内にある対象とする領域、たとえば、ビデオデータの現在ブロックの上、右上、左上、および／または左の領域内からであり得る。ビデオデータの予測ブロックは現在ビデオブロックのすぐ上またはすぐ左のいずれかにあることに限定されず、したがって、現在ブロックに対する予測ブロックを識別するために使用されるベクトルは必ずしも１次元ベクトルであるとは限らない。代わりに、ビデオデータの予測ブロックを識別または決定するために、ビデオコーダは、ビデオデータの現在ブロックに対する水平変位成分および垂直変位成分を含む２次元ベクトルを定義する１つまたは複数のシンタックス要素をコーディングし得る。２次元ベクトルは、ブロックベクトル、オフセットベクトル、または動きベクトルと呼ばれることがあり、たとえば、現在ブロックの左上コーナーに対する予測ブロックを識別するために使用され得る。
【００２０】
[0029]以下でより詳細に説明するように、コーディングユニットと呼ばれるビデオデータのブロックは複数の予測ユニットを含み得る。各予測ユニットは別個に予測され得る。したがって、各予測ユニットについて、ブロックベクトルはビットストリーム中でシグナリングされ得、ビデオデコーダは、予測ユニットのルーマ成分と予測ユニットの２つのクロマ成分とを予測するためにそのブロックベクトルを使用し得る。ビデオデータのクロマサブサンプリングフォーマットに応じて、ビデオデコーダは、予測ユニットの２つのクロマ成分を予測するためにブロックベクトルをスケーリングし得る。クロマ成分を予測するためのブロックベクトルのスケーリングは、可読性を支援するために複数回繰り返されない。クロマ成分を予測するためのブロックベクトルのそのようなスケーリングは、クロマ成分を予測したときに行われ得るが、ブロックベクトルのそのようなスケーリングは、クロマ成分を予測することのあらゆる事例において必要であるとは限らないことを理解されたい。
【００２１】
[0030]既存の技法によれば、コーディングユニットの各予測ユニットのための参照ブロックを識別するために、異なるブロックベクトルが使用され得る。たとえば、コーディングユニットの第１の予測ユニットのための第１のブロックベクトルが、第１の予測ユニットのルーマ成分のためのルーマ参照ブロック（すなわち、ルーマサンプルの予測ブロック）を識別するために使用され、第１の予測ユニットの２つのクロマ成分のためのクロマ参照ブロック（すなわち、クロマサンプルの２つの対応するクロマブロック）を識別するために使用され得る。コーディングユニットの第２の予測ユニットのための第２のブロックベクトルが、第２の予測ユニットのルーマ成分のためのルーマ参照ブロック（すなわち、ルーマサンプルの予測ブロック）を識別するために使用され、第２の予測ユニットの２つのクロマ成分のためのクロマ参照ブロック（すなわち、クロマサンプルの２つの対応するクロマブロック）を識別するために使用され得、以下同様である。
【００２２】
[0031]しかしながら、本開示の技法によれば、異なるブロックベクトルが、コーディングユニットの各予測ユニットのルーマ成分を予測するために使用され得、同じブロックベクトルが、コーディングユニットの予測ユニットの２つまたはそれ以上のクロマ成分を予測するために使用され得る。たとえば、上記のように、コーディングユニットの第１の予測ユニットのための第１のブロックベクトルが、第１の予測ユニットのルーマ成分のためのルーマ参照ブロック（すなわち、ルーマサンプルの予測ブロック）を識別するために使用され、第１の予測ユニットの２つのクロマ成分のためのクロマ参照ブロック（すなわち、クロマサンプルの２つの対応するクロマブロック）を識別するために使用され得る。しかしながら、第２の予測ユニットの２つのクロマ成分の場合、（上記の例の場合のように）第２のブロックベクトルを使用するのではなく、同じ第１のブロックベクトルが、クロマ参照ブロックを識別するために使用される。第２のブロックベクトルは、依然として、第２の予測ユニットのルーマ成分のためのルーマ参照ブロックを識別するために使用され得る。
【００２３】
[0032]より詳細には、本開示では、ピクチャまたはスライス内で予測されたブロックを用いたブロックのコーディングをサポートするための技法について説明する。提案する技法は、たとえば、高ビット深度（たとえば８ビット超）と（たとえば、４：４：４および４：２：２を含む）高クロマサンプリングフォーマットとをサポートし得る新生のＨＥＶＣ範囲拡張（ＲＣＥｘ）とともに使用され得る。本開示の技法はスクリーンコンテンツコーディングにも適用され得る。
【００２４】
[0033]本明細書で使用する「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、総称的にビデオ符号化またはビデオ復号を指すことがある。したがって、別段に記載されていない限り、コーディングに関して説明する技法はビデオエンコーダまたはビデオデコーダのいずれかによって実行され得ると仮定されるべきである。本出願のいくつかの部分では、いくつかの技法について、ビデオ復号またはビデオデコーダに関して説明し得る。しかしながら、そのような技法は、ビデオ符号化に適用可能でないか、またはビデオエンコーダによって実行されないことがあると仮定されるべきでない。そのような技法は、たとえば、ビデオデータをどのように符号化するかを決定することの一部として実行され得るか、またはビデオエンコーダ中のビデオ復号ループの一部として実行され得る。
【００２５】
[0034]本開示で使用する現在ブロックという用語は、すでにコーディングされているまたはまだコーディングされていないブロックとは対照的に、現在コーディングされているブロックを指す。同様に、現在コーディングユニット、現在予測ユニット、または現在変換ユニットは、現在コーディングされているコーディングユニット、予測ユニット、または変換ユニットを指す。
【００２６】
[0035]図１は、本明細書で説明する技法のうちの１つまたは複数を実装し得る例示的なビデオ符号化および復号システムを示すブロック図である。図１に示されているように、システム１０は、宛先デバイス１４によって復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲のデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。
【００２７】
[0036]宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体１６は、ソースデバイス１２から宛先デバイス１４に符号化ビデオデータを移動させることが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、リアルタイムで宛先デバイス１４に直接符号化ビデオデータを送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、インターネットなどのグローバルネットワーク、ワイドエリアネットワーク、またはローカルエリアネットワークなどのパケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得る任意の他の機器を含み得る。
【００２８】
[0037]いくつかの例では、コンピュータ可読媒体１６はストレージデバイスを備え得、ソースデバイスは、出力インターフェース２２を介してストレージデバイスに符号化ビデオデータを出力し得る。同様に、符号化データは入力インターフェース２８によってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。たとえば、ディスクスタンピング設備など、媒体製造施設のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。さらなる一例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介してストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブがある。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、またはその両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【００２９】
[0038]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【００３０】
[0039]図１は一例にすぎず、本開示の技法は、符号化デバイスと復号デバイスとの間のデータ通信を必ずしも含むとは限らないビデオコーディング設定（たとえば、ビデオ符号化またはビデオ復号）に適用され得る。他の例では、データがローカルメモリから取り出されること、ネットワークを介してストリーミングされることなどが行われる。ビデオ符号化デバイスはデータを符号化し、メモリに記憶し得、および／またはビデオ復号デバイスはメモリからデータを取り出し、復号し得る。多くの例では、符号化および復号は、互いに通信しないが、単にメモリにデータを符号化し、および／またはメモリからデータを取り出し、復号するデバイスによって実行される。
【００３１】
[0040]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなど、外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、一体化したディスプレイデバイス３２を含むのではなく、外部ディスプレイデバイス３２とインターフェースし得る。
【００３２】
[0041]図１の図示されたシステム１０は、一例にすぎない。任意のデジタルビデオ符号化および／または復号デバイスが本明細書で説明する技法を実行し得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法はビデオプリプロセッサによっても実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４への送信のためのコーディングされたビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオテレフォニーのための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートし得る。
【００３３】
[0042]ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４はいわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。いくつかの例では、出力インターフェース２２は、変調器／復調器（モデム）および／または送信機を含み得る。
【００３４】
[0043]宛先デバイス１４の入力インターフェース２８はコンピュータ可読媒体１６から情報を受信する。いくつかの例では、入力インターフェース２８は受信機および／またはモデムを含む。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、ビデオデコーダ３０によって使用され、ブロックおよび他のコード化ユニット、たとえば、スライス、ピクチャ、ピクチャグループ（ＧＯＰ）、またはビデオデータの特性および／または処理を記述する符号化ビデオデータおよび他のシンタックス情報を含み得る、符号化ビデオビットストリームを含み得る。ディスプレイデバイス３２は、ユーザに復号ビデオデータを表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００３５】
[0044]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法がソフトウェアで部分的に実装されるとき、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、本開示の技法を実行するために１つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。
【００３６】
[0045]本開示では、概して、ビデオエンコーダ２０が、ある情報をビデオデコーダ３０などの別のデバイスに「シグナリング」することに言及することがある。「シグナリング」という用語は、概して、圧縮ビデオデータを復号するために使用されるシンタックス要素および／または他のデータの通信を指し得る。そのような通信は、リアルタイムまたはほぼリアルタイムに行われ得る。代替的に、そのような通信は、符号化時に符号化ビットストリーム中でシンタックス要素をコンピュータ可読記憶媒体に記憶するときに行われることがあるなど、ある時間期間にわたって行われ得、次いで、これらの要素は、この媒体に記憶された後の任意の時間に復号デバイスによって取り出され得る。
【００３７】
[0046]ビデオエンコーダ２０およびビデオデコーダ３０について、本開示では、例示のために、１つまたは複数のビデオコーディング規格に従って動作するように構成されるものとして説明する。しかしながら、本開示の技法は、必ずしも任意の特定のコーディング規格に限定されるとは限らず、様々な異なるコーディング規格のために適用され得る。
【００３８】
[0047]ビデオエンコーダ２０およびビデオデコーダ３０は、任意の拡張、変更、または追加を含む、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ  Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、またはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例としては、ＭＰＥＧ−２およびＩＴＵ−Ｔ  Ｈ．２６３がある。
【００３９】
[0048]他のプロプライエタリまたは業界規格の例としては、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４、あるいはそのような規格の拡張、変更、または追加がある。さらに、Ｈ．２６４／ＡＶＣへの３次元ビデオ（３ＤＶ：three-dimensional video）コーディング拡張、すなわちＡＶＣベース３ＤＶを生成するための取り組みが進行中である。言い換えれば、例示的なビデオコーディング規格としては、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、およびそれのスケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む、（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４がある。Ｈ．２６４規格は、ＩＴＵ−Ｔ研究グループによる２００５年３月付けのＩＴＵ−Ｔ勧告Ｈ．２６４、Advanced Video Coding for generic audiovisual servicesに記載されており、本明細書ではＨ．２６４規格またはＨ．２６４仕様、あるいはＨ．２６４／ＡＶＣ規格または仕様と呼ぶことがある。ジョイントビデオチーム（ＪＶＴ）は、Ｈ．２６４／ＭＰＥＧ−４  ＡＶＣへの拡張に取り組み続けている。ＭＶＣの最近のジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１０年３月に記載されている。
【００４０】
[0049]さらに、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ：Video Coding Experts Group）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）とのジョイントコラボレーションチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）によって開発された、新開発のビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）がある。図１の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、ＨＥＶＣに従って動作し得る。その内容全体が参照により組み込まれる、２０１３年１０月１７日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１２＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｌ１００３−ｖ３４．ｚｉｐから入手可能である、Ｂｒｏｓｓら、「High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Last Call)、ＩＴＵ−Ｔ  ＳＧ１６  ＷＰ３とＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオンビデオコーディング（ＪＣＴ−ＶＣ：Joint Collaborative Team on Video Coding）、第１２回会議：ジュネーブ、スイス、２０１３年１月１４日〜２３日、文書ＪＣＴＶＣ−Ｌ１００３−ｖ３４、以下、「ＪＣＴＶＣ−Ｌ１００３−ｖ３４」はＨＥＶＣの最近のドラフトである。ＪＣＴＶＣ−Ｌ１００３−ｖ３４において定義されたＨＥＶＣのバージョンはＨＥＶＣバージョン１または「ＨＥＶＣｖ１」と呼ばれることがある。その内容全体が参照により組み込まれる、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝８１４３から入手可能である、ＭｃＣａｎｎら、「High Efficiency Video Coding (HEVC) Test Model 12 (HM 12) Encoder Description」、文書ＪＣＴＶＣ−
Ｎ１００２はＨＥＶＣの最近のエンコーダの説明である。
【００４１】
[0050]３ＤサービスをサポートするＨＥＶＣの２つの拡張が、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ）およびＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ）のジョイントコラボレーションチームオン３Ｄビデオコーディング（ＪＣＴ−３Ｖ：Joint Collaboration Team on 3D Video coding）によって開発中である。すなわち、この２つの拡張はそれぞれ、ＭＶ−ＨＥＶＣおよび３Ｄ−ＨＥＶＣである。図１の例では、ビデオエンコーダ２０およびビデオデコーダ３０は、ＭＶ−ＨＥＶＣおよび／または３Ｄ−ＨＥＶＣに従って動作し得る。
【００４２】
[0051]ＭＶ−ＨＥＶＣは、ブロックレベル設計を変更することなしに複数の（テクスチャ）ビューのコーディングをサポートする。その内容全体が参照により組み込まれる、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００４−ｖ６．ｚｉｐから入手可能である、Ｔｅｃｈら、「MV-HEVC Draft Text 5」、ＩＴＵ−Ｔ  ＳＧ  １６  ＷＰ  ３とＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、文書番号ＪＣＴ３Ｖ−Ｅ１００４−ｖ６はＭＶ−ＨＥＶＣの最近のドラフトである。
【００４３】
[0052]３Ｄ−ＨＥＶＣは、マルチビュービデオ＋深度フォーマットをコーディングし、ＨＥＶＣコーディングモジュールに加えて組み込まれた新しいコーディングツールを含む。新たに導入されたコーディングツールは、テクスチャコーディングと深度コーディングの両方に適用可能である。その内容全体が参照により組み込まれる、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００１−ｖ３．ｚｉｐから入手可能である、Ｔｅｃｈら、「3D-JEVC Draft Text 1」、ＩＴＵ−Ｔ  ＳＧ  １６  ＷＰ  ３とＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、第５回会議：ウィーン、オーストリア、２０１３年７月２７日〜８月２日、文書番号ＪＣＴ３Ｖ−Ｅ１００１−ｖ３は３Ｄ−ＨＥＶＣの最近のドラフトである。３Ｄ−ＨＥＶＣのための最近のソフトウェア３Ｄ−ＨＴＭは、以下のリンク、すなわち、［３Ｄ−ＨＴＭ  ｖｅｒｓｉｏｎ  ８．０］：ｈｔｔｐｓ：／／ｈｅｖｃ．ｈｈｉ．ｆｒａｕｎｈｏｆｅｒ．ｄｅ／ｓｖｎ／ｓｖｎ＿３ＤＶＣＳｏｆｔｗａｒｅ／ｔａｇｓ／ＨＴＭ−８．０／からダウンロードされ得る。最近のソフトウェアの説明、すなわち、その内容全体が参照により組み込まれる、Ｚｈａｎｇら、「3D-HEVC Test Model 5」、ＩＴＵ−Ｔ  ＳＧ  １６  ＷＰ  ３とＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオン３Ｄビデオコーディング拡張開発、第５回会議：ウィーン、オーストリア、２０１３年７月２７日〜８月２日、文書番号ＪＣＴ３Ｖ−Ｅ１００５は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝１３６０から入手可能である。
【００４４】
[0053]ＨＥＶＣ規格のさらなる開発および拡張はＨＥＶＣ範囲拡張を含む。ＨＥＶＣ範囲拡張の例は、その全体が参照により本明細書に組み込まれる、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝８１３９において入手可能である、Ｆｌｙｎｎら、「High Efficiency Video Coding (HEVC) Range Extensions text specification: Draft 4」、ＩＴＵ−Ｔ  ＳＧ  １６  ＷＰ  ３とＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオンビデオコーディング（ＪＣＴ−ＶＣ）、文書ＪＣＴＶＣ−Ｎ１００５＿ｖ３、第１３回会議：仁川、韓国、２０１３年４月１８日〜２６日に記載されている。
【００４５】
[0054]ＨＥＶＣ規格のさらなる開発および拡張はスクリーンコンテンツコーディング（ＳＣＣ：screen content coding）拡張を含む。
【００４６】
[0055]ＨＥＶＣおよび他のビデオコーディング仕様では、ビデオシーケンスは一般に一連のピクチャを含む。ピクチャは「フレーム」と呼ばれることもある。ピクチャは、ＳL、ＳCbおよびＳCrと示される３つのサンプルアレイを含み得る。ＳLはルーマサンプルの２次元アレイ（すなわち、ブロック）である。ＳCbはＣｂクロミナンスサンプルの２次元アレイである。ＳCrはＣｒクロミナンスサンプルの２次元アレイである。クロミナンスサンプルは、本明細書では「クロマ」サンプルと呼ばれることもある。他の事例では、ピクチャは、モノクロームであり得、ルーマサンプルのアレイのみを含み得る。
【００４７】
[0056]ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ  Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを与えるが、ＨＭは３３個ものイントラ予測符号化モードを与え得る。
【００４８】
[0057]概して、ＨＭの作業モデルは、ビデオエンコーダ２０が、ビデオフレームまたはピクチャを、最大コーディングユニット（ＬＣＵ：largest coding unit）またはツリーブロックとも呼ばれる、コーディングツリーユニット（ＣＴＵ：coding tree unit）のシーケンスに分割し得ることを記載している。ＣＴＵの各々は、ルーマサンプルのコーディングツリーブロック（ＣＴＢ：coding tree block）と、クロマサンプルの２つの対応するコーディングツリーブロックと、それらのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは別個のカラープレーン（color plane）を備えるピクチャでは、ＣＴＵは、単一のコーディングツリーブロックと、単一のコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。
【００４９】
[0058]ビットストリーム内のシンタックスデータは、ピクセルの数に関して最大コーディングユニットである、ＣＴＵのサイズを定義し得る。ＣＴＵはサンプルのＮ×Ｎブロックであり得る。ＨＥＶＣのＣＴＵは、Ｈ．２６４／ＡＶＣなど、他のビデオコーディング規格のマクロブロックに広い意味で類似し得る。しかしながら、ＣＴＵは、必ずしも特定のサイズに限定されるとは限らず、１つまたは複数のコーディングユニット（ＣＵ）を含み得る。
【００５０】
[0059]ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。スライスは、コーディング順序または走査順序でいくつかの連続するＣＴＵを含む。各ＣＴＵは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。ＣＵはサンプルのＮ×Ｎブロックであり得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割される場合、ＣＵに対応するノードは４つのリーフノードを含み、その各々はサブＣＵのうちの１つに対応する。ＣＵ、またはＣＵと呼ばれることもあるサブＣＵは、ルーマサンプルアレイとＣｂサンプルアレイとＣｒサンプルアレイとを有するピクチャのルーマサンプルのコーディングブロックと、そのピクチャのクロマサンプルの２つの対応するコーディングブロックと、それらのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは別個のカラープレーンを備えるピクチャでは、ＣＵは、単一のコーディングブロックと、単一のコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。
【００５１】
[0060]４分木データ構造の各ノードは、対応するＣＵのためのシンタックスデータを与え得る。たとえば、４分木中のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのためのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵはリーフＣＵと呼ばれることもある。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、その１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵはリーフＣＵと呼ばれることもある。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。したがって、ビットストリームはまた、最小コーディングユニット（ＳＣＵ：smallest coding unit）を定義し得る。
【００５２】
[0061]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ：transform unit）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４ピクセル以上をもつツリーブロックのサイズまでに及び得る。概して、ビデオエンコーダ２０およびビデオデコーダ３０は、１つのモード、たとえば、イントラ予測またはインター予測を用いて各ＣＵをコーディングする。
【００５３】
[0062]各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含んでいることがある。ＣＵに関連するシンタックスデータは、たとえば、ＣＵの１つまたは複数のＰＵへの区分を記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。ＰＵは、形状が非正方形（たとえば、矩形）に区分され得る。ＣＵに関連するシンタックスデータはまた、たとえば、４分木に従うＣＵの１つまたは複数のＴＵへの区分を記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。
【００５４】
[0063]ＣＵのＰＵおよびＴＵは、ピクチャのルーマサンプルの１つの予測ブロックと、クロマサンプルの２つの対応する予測ブロックと、予測ブロックサンプルを予測するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ２０は、ＣＵの各ＰＵについて予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロックを生成し得る。モノクロームピクチャまたは別個のカラープレーンを備えるピクチャでは、ＰＵは、単一の予測ブロックと、単一の予測ブロックを予測するために使用されるシンタックス構造とを備え得る。
【００５５】
[0064]ビデオエンコーダ２０およびビデオデコーダ３０は、様々なサイズを有するＰＵをサポートし得る。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測と、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称ＰＵサイズでのインター予測とをサポートし得る。ビデオエンコーダ２０およびビデオデコーダ３０は、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測に対する非対称区分をもサポートし得る。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％および７５％に区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ  ＰＵと下部の２Ｎ×１．５Ｎ  ＰＵとで水平方向に区分された２Ｎ×２Ｎ  ＣＵを指す。ＨＥＶＣでは、最小ＰＵサイズは８×４および４×８である。
【００５６】
[0065]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）、および水平方向に１６ピクセル（ｘ＝１６）を有する。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここでＮは非負整数値を表す。ブロック中のピクセルは行および列に配列され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。
【００５７】
[0066]概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのためのデータは、ＰＵに対応する予測ブロックのためのイントラ予測モードを記述し得る。
【００５８】
[0067]別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分と、動きベクトルの垂直成分と、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）とを記述し得る。ＰＵは、参照ピクチャを含む参照ピクチャリストへのインデックスなど、動きベクトルが指す参照ピクチャを識別するデータをも含み得る。
【００５９】
[0068]インター予測は単方向（すなわち、単予測）または双方向（すなわち、双予測）であり得る。単予測または双予測を実行するために、ビデオエンコーダ２０およびビデオデコーダは、現在ピクチャに対して、第１の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０）と第２の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ１）とを生成し得る。参照ピクチャリストの各々は１つまたは複数の参照ピクチャを含み得る。参照ピクチャリストが構成された後（すなわち、利用可能な場合、ＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１）、参照ピクチャリスト中に含まれる任意の参照ピクチャを識別するために、参照ピクチャリストへの参照インデックスが使用され得る。
【００６０】
[0069]参照ピクチャは、時間順序、たとえば、表示順序での前のピクチャ、将来のピクチャ、あるいは２つまたはそれ以上の前に符号化されたピクチャからの予測の組合せであり得る。ビデオコーダ、たとえば、ビデオエンコーダ２０およびビデオデコーダ３０は、ピクチャの時間順序を識別するためにピクチャ順序カウント（ＰＯＣ）を使用する。ビデオコーダはまた、参照ピクチャリストの構成および動きベクトルのスケーリングのためにピクチャのＰＯＣ値を使用する。ビデオエンコーダ２０またはビデオデコーダ３０は、参照ピクチャを、参照ピクチャメモリ、たとえば、参照ピクチャメモリ３６８（図６）および参照ピクチャメモリ３９６（図７）に記憶し得る。
【００６１】
[0070]現在ビデオブロック、たとえば、ＰＵが、本開示の技法によるイントラＢＣを使用してコーディングされたとき、そのブロックのための（ブロックベクトル、オフセットベクトル、動きベクトル、または変位ベクトルと呼ばれることがある）２次元ベクトルを定義するデータは、たとえば、ベクトルの水平成分、ベクトルの垂直成分、ベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）を表し得る。しかしながら、本開示の技法によるイントラＢＣを使用して予想されたＰＵのデータは、参照ブロックが現在ビデオブロックと同じフレームまたはピクチャ内にあるので、動きベクトルが指す参照ピクチャを識別する必要がない。
【００６２】
[0071]ビデオエンコーダ２０がＣＵの１つまたは複数のＰＵのための予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロックを生成した後、ビデオエンコーダ２０は、ＣＵのためのルーマ残差ブロックを生成し得る。ＣＵのルーマ残差ブロック中の各サンプルは、ＣＵのＰＵの予測ルーマブロック中のルーマサンプルとＣＵの元のルーマコーディングブロック中の対応するサンプルとの間の差分を示す。さらに、ビデオエンコーダ２０はＣＵのためのＣｂ残差ブロックを生成し得る。ＣＵのＣｂ残差ブロック中の各サンプルは、ＣＵのＰＵの予測Ｃｂブロック中のＣｂサンプルとＣＵの元のＣｂコーディングブロック中の対応するサンプルとの間の差分を示し得る。ビデオエンコーダ２０はまた、ＣＵのためのＣｒ残差ブロックを生成し得る。ＣＵのＣｒ残差ブロック中の各サンプルは、ＣＵのＰＵの予測Ｃｒブロック中のＣｒサンプルとＣＵの元のＣｒコーディングブロック中の対応するサンプルとの間の差分を示し得る。
【００６３】
[0072]１つまたは複数のＰＵを有するリーフＣＵは１つまたは複数の変換ユニット（ＴＵ）をも含み得る。ＣＵのＴＵは、ルーマサンプルの変換ブロックと、クロマサンプルの２つの対応する変換ブロックと、それらの変換ブロックサンプルを変換するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ２０は、変換係数を生成するためにＴＵに関連する残差ブロック内のピクセル差分値を変換し得、その変換係数は量子化され得る。たとえば、ビデオエンコーダ２０は、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換を残差ビデオデータに適用し得る。
【００６４】
[0073]ＴＵは、上記で説明したように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらなるサブＴＵにさらに分割され得る。ＴＵがさらに分割されないとき、それはリーフＴＵと呼ばれることがある。ＴＵは、必ずしもＰＵのサイズに限定されるとは限らない。したがって、ＴＵは、ＰＵよりも大きいことも小さいこともある。イントラコーディングの場合、ＰＵは、同じＣＵのための対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。概して、本開示では、別段に明記されていない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
【００６５】
[0074]本開示では、本明細書で説明するように、サンプルの任意の１つまたは複数のブロックと、サンプルの１つまたは複数のブロックのサンプルをコーディングするために使用されるシンタックス構造とを指すために、「ビデオユニット」、「ビデオブロック」、または「ビデオデータのブロック」という用語を使用し得る。例示的なタイプのビデオブロックは、ＨＥＶＣのコンテキストにおけるＣＴＵ、ＣＵ、ＰＵ、またはＴＵ、あるいは他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそのマクロブロック区分）を含み得る。
【００６６】
[0075]変換係数を生成するための変換の後で、ビデオエンコーダ２０は変換係数の量子化を実行し得る。量子化は、概して、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、ｎビット値は、量子化中にｍビット値に切り捨てられ得、ここで、ｎはｍよりも大きい。
【００６７】
[0076]量子化の後に、ビデオエンコーダは、変換係数を走査し、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、アレイの前部により高いエネルギー（したがって、より低い周波数）係数を配置し、アレイの後部により低いエネルギー（したがって、より高い周波数）係数を配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応型走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【００６８】
[0077]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルのための可変長コードを選択し得る。ＶＬＣ中のコードワードは、比較的より短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのための等長コードワードを使用することに勝るビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
【００６９】
[0078]さらに、ビデオエンコーダ２０は、たとえば、残差データを逆量子化し、逆変換することによって符号化ピクチャを復号し、残差データを予測データと組み合わせ得る。このようにして、ビデオエンコーダ２０は、ビデオデコーダ３０によって実行される復号プロセスをシミュレートすることができる。したがって、ビデオエンコーダ２０とビデオデコーダ３０の両方は、イントラピクチャ予測、インターピクチャ予測、またはイントラＢＣ予測において使用するための、実質的に同じ復号ビデオデータ、たとえば、ピクチャまたはピクチャからのブロックへのアクセスを有する。
【００７０】
[0079]ビデオエンコーダ２０は、シンタックス要素を含む、コード化ピクチャおよび関連データの表現を形成するビットのシーケンスを含む符号化ビデオビットストリームを出力し得る。ビットストリームは、ネットワークアブストラクションレイヤ（ＮＡＬ：network abstraction layer）ユニットのシーケンスを備え得る。ＮＡＬユニットの各々は、ＮＡＬユニットヘッダを含み得、ローバイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）をカプセル化し得る。ＮＡＬユニットヘッダは、ＮＡＬユニットタイプコードを示すシンタックス要素を含み得る。ＮＡＬユニットのＮＡＬユニットヘッダによって指定されるＮＡＬユニットタイプコードは、ＮＡＬユニットのタイプを示す。ＲＢＳＰは、ＮＡＬユニット内にカプセル化された整数個のバイトを含んでいるシンタックス構造を備え得る。いくつかの事例では、ＲＢＳＰは０ビットを含む。
【００７１】
[0080]異なるタイプのＮＡＬユニットは、異なるタイプのＲＢＳＰをカプセル化し得る。たとえば、第１のタイプのＮＡＬユニットはパラメータセットのためのＲＢＳＰをカプセル化し得、第２のタイプのＮＡＬユニットはコード化スライスのためのＲＢＳＰをカプセル化し得、第３のタイプのＮＡＬユニットは補足エンハンスメント情報（ＳＥＩ：supplemental enhancement information）のためのＲＢＳＰをカプセル化し得、以下同様である。（パラメータセットおよびＳＥＩメッセージのためのＲＢＳＰとは対照的に）ビデオコーディングデータのためのＲＢＳＰをカプセル化するＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ：video coding layer）ＮＡＬユニットと呼ばれることがある。コード化スライスをカプセル化するＮＡＬユニットは、本明細書ではコード化スライスＮＡＬユニットと呼ばれることがある。コード化スライスのためのＲＢＳＰはスライスヘッダとスライスデータとを含み得る。
【００７２】
[0081]ビデオエンコーダ２０は、符号化ビデオデータに加えて、ビデオデータの特定のブロックをどのように復号すべきか、またはそれのグルーピングをビデオデコーダに通知するシンタックス要素を符号化ビデオビットストリーム中に含め得る。ビデオエンコーダ２０は、たとえば、それが参照するビデオ構造のタイプ（たとえば、シーケンス、ピクチャ、スライス、ブロック）、およびそれの値がどのくらい頻繁に変化し得るかに応じて、シンタックス要素を様々なシンタックス構造中に含め得る。たとえば、ビデオエンコーダ２０は、シンタックス要素を、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、またはピクチャパラメータセット（ＰＰＳ）など、パラメータセット中に含め得る。他の例として、ビデオエンコーダ２０は、シンタックス要素をＳＥＩメッセージおよびスライスヘッダ中に含め得る。
【００７３】
[0082]概して、ビデオデコーダ３０は、ビデオエンコーダによって実行される符号化プロセスの逆である復号プロセスを実行し得る。たとえば、ビデオデコーダ３０は、量子化されたビデオデータをエントロピー符号化するためにビデオエンコーダによって使用されるエントロピー符号化技法の逆を使用してエントロピー復号を実行し得る。ビデオデコーダ３０は、ビデオエンコーダ２０によって採用される量子化技法の逆を使用してビデオデータをさらに逆量子化し得、量子化された変換係数を生成するためにビデオエンコーダ２０によって使用された変換の逆を実行し得る。ビデオデコーダ３０は、次いで、最終的な表示のためにビデオブロックを生成するために、隣接参照ビデオデータ（イントラ予測）、別のピクチャからの予測ブロック（インター予測）、または同じピクチャからの予測ブロック（イントラＢＣ）に、得られた残差ブロックを適用し得る。ビデオデコーダ３０は、ビデオデコーダ３０によって受信されたビットストリーム中の符号化ビデオデータとともに、ビデオエンコーダ２０によって与えられるシンタックス要素に基づいて、ビデオエンコーダ２０によって実行される様々なプロセスの逆を実行するために構成、命令、制御、または指示され得る。
【００７４】
[0083]各ピクチャは、ルーマ成分と１つまたは複数のクロマ成分とを備え得る。したがって、本明細書で説明するブロックベースの符号化および復号動作は、ルーマピクセル値またはクロマピクセル値を含むか、あるいはそれに関連する、ブロック、たとえば、ＣＵ、ＰＵおよびＴＵに等しく適用可能であり得る。
【００７５】
[0084]（イントラＢＣとも呼ばれる）イントラＭＣは、Ｂｕｄａｇａｖｉら、「AHG8: Video coding using Intra motion compensation」、文書：ＪＣＴＶＣ−Ｍ０３５０、ＩＴＵ−Ｔ  ＳＧ  １６  ＷＰ  ３とＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ  ２９／ＷＧ  １１とのジョイントコラボレーティブチームオンビデオコーディング（ＪＣＴ−ＶＣ）、第１３回会議、仁川、韓国、２０１３年４月１８日〜２６日（以下、「ＪＣＴ−ＶＣ  Ｍ０３０５０」）において報告されるように、イントラピクチャ冗長性を除去し、イントラフレームコーディング効率を改善することを可能にする専用技法である。ＪＣＴ−ＶＣ  Ｍ０３５０は、その全体が参照により本明細書に組み込まれ、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝７６０１からダウンロードのために利用可能である。ＪＣＴ−ＶＣ  Ｍ０３５０によれば、イントラＭＣは、（１）現在ビデオブロック、たとえば、ＣＵから変位された予測信号の位置、たとえば、同じフレームまたはピクチャ内のブロックを示す１次元オフセットまたは（ここではブロックベクトル、動きベクトル、または「ＭＶ」とも呼ばれる）変位ベクトルを（２）残差信号とともにコーディングすることを含む。イントラＭＣを使用するＣＵまたは他のブロックの場合、予測信号は、同じピクチャ中のすでに再構成された領域から取得される。
【００７６】
[0085]図２は、本開示による、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のためのモードに従って、たとえば、本開示の技法によるイントラＢＣモードに従って、現在ピクチャ１０３内のビデオデータの現在ブロック１０２を予測するための例示的な技法を示す概念図である。図２は、現在ピクチャ１０３内のビデオデータの予測ブロック１０４を示している。ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、本開示の技法によるイントラＢＣモードに従って現在ビデオブロック１０２を予測するために予測ビデオブロック１０４を使用し得る。
【００７７】
[0086]ビデオエンコーダ２０は、ビデオデータの前に再構成されたブロックのセットから、現在ビデオブロック１０２を予測するための予測ビデオブロック１０４を選択する。ビデオエンコーダ２０は、符号化ビデオビットストリーム中にも含まれるビデオデータを逆量子化し、逆変換し、得られた残差ブロックを、ビデオデータの再構成ブロックを予測するために使用される予測ブロックと加算することによって、ビデオデータのブロックを再構成する。図２の例では、「対象とするエリア」または「ラスタエリア」とも呼ばれることがある、ピクチャ１０３内の対象とする領域１０８は、前に再構成されたビデオブロックのセットを含む。ビデオエンコーダ２０は、以下でより詳細に説明するように、様々な方法でピクチャ１０３内の対象とする領域１０８を定義し得る。ビデオエンコーダ２０は、対象とする領域１０８内の様々なビデオブロックに基づいて現在ビデオブロック１０２を予測しコーディングする相対的な効率と精度との分析に基づいて、対象とする領域１０８中のビデオブロックの中から現在ビデオブロック１０２を予測するための予測ビデオブロック１０４を選択し得る。
【００７８】
[0087]ビデオエンコーダ２０は、現在ビデオブロック１０２に対する予測ビデオブロック１０４のロケーションまたは変位を表す２次元ベクトル１０６を決定する。２次元ブロックベクトル１０６は、それぞれ現在ビデオブロック１０２に対する予測ビデオブロック１０４の水平変位および垂直変位を表す、水平変位成分１１２および垂直変位成分１１０を含む。ビデオエンコーダ２０は、２次元ブロックベクトル１０６を識別または定義する、たとえば、水平変位成分１１２および垂直変位成分１１０を定義する１つまたは複数のシンタックス要素を符号化ビデオビットストリーム中に含め得る。ビデオデコーダ３０は、２次元ブロックベクトル１０６を決定するために１つまたは複数のシンタックス要素を復号し、現在ビデオブロック１０２のための予測ビデオブロック１０４を識別するために、決定されたベクトルを使用し得る。
【００７９】
[0088]いくつかの例では、２次元ブロックベクトル１０６の解像度は、整数ピクセルであり、たとえば、整数ピクセル解像度を有するように制約され得る。そのような例では、水平変位成分１１２および垂直変位成分１１０の解像度は整数ピクセルであり得る。そのような例では、ビデオエンコーダ２０およびビデオデコーダ３０は、現在ビデオブロック１０２のための予測子を決定するために予測ビデオブロック１０４のピクセル値を補間する必要はない。
【００８０】
[0089]他の例では、水平変位成分１１２および垂直変位成分１１０の一方または両方の解像度はサブピクセルであり得る。たとえば、成分１１２および１１４のうちの一方は整数ピクセル解像度を有し得、他方はサブピクセル解像度を有する。いくつかの例では、水平変位成分１１２および垂直変位成分１１０の両方の解像度はサブピクセルであり得るが、水平変位成分１１２および垂直変位成分１１０は異なる解像度を有し得る。
【００８１】
[0090]いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、特定のレベル、たとえば、ブロックレベル、スライスレベル、またはピクチャレベルの適応に基づいて、水平変位成分１１２および垂直変位成分１１０の解像度を適応させる。たとえば、ビデオエンコーダ２０は、スライスレベルにおいて、たとえば、スライスヘッダ中で、水平変位成分１１２および垂直変位成分１１０の解像度が整数ピクセル解像度であるのか整数ピクセル解像度でないのかを示すフラグをシグナリングし得る。水平変位成分１１２および垂直変位成分１１０の解像度が整数ピクセル解像度でないことをフラグが示す場合、ビデオデコーダ３０は、解像度がサブピクセル解像度であると推論し得る。いくつかの例では、必ずしもフラグであるとは限らない、１つまたは複数のシンタックス要素が、水平変位成分１１２および／または垂直変位成分１１０の集合的な解像度または個々の解像度を示すために、ビデオデータのスライスまたは他のユニットごとに送信され得る。
【００８２】
[0091]さらに他の例では、フラグまたはシンタックス要素の代わりに、ビデオエンコーダ２０は、水平変位成分１１２および／または垂直変位成分１１０の解像度を解像度コンテキスト情報に基づいて設定し得、ビデオデコーダ３０は、解像度コンテキスト情報から水平変位成分１１２および／または垂直変位成分１１０の解像度を推論し得る。解像度コンテキスト情報は、例として、現在ビデオブロック１０２を含むピクチャまたはピクチャのシーケンスについての色空間（たとえば、ＹＵＶ、ＲＧＢなど）、特定のカラーフォーマット（たとえば、４：４：４、４：２：２、４：２：０など）、フレームサイズ、フレームレート、または量子化パラメータ（ＱＰ）を含み得る。少なくともいくつかの例では、ビデオコーダは、前にコーディングされたフレームまたはピクチャに関係する情報に基づいて、水平変位成分１１２および／または垂直変位成分１１０の解像度を決定し得る。このようにして、水平変位成分１１２の解像度および垂直変位成分１１０のための解像度は、あらかじめ定義され、シグナリングされ得るか、他のサイド情報（たとえば、解像度コンテキスト情報）から推論され得るか、またはすでにコーディングされたフレームに基づき得る。
【００８３】
[0092]現在ビデオブロック１０２は、ＣＵ、またはＣＵのＰＵであり得る。いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、イントラＢＣに従って予測されるＣＵをいくつかのＰＵに分割し得る。そのような例では、ビデオコーダは、ＣＵのＰＵの各々について、それぞれの（たとえば、異なる）２次元ベクトル１０６を決定し得る。たとえば、ビデオコーダは、２Ｎ×２Ｎ  ＣＵを２つの２Ｎ×Ｎ  ＰＵ、２つのＮ×２Ｎ  ＰＵ、または４つのＮ×Ｎ  ＰＵに分割し得る。他の例として、ビデオコーダは、２Ｎ×２Ｎ  ＣＵを（（Ｎ／２）×Ｎ＋（３Ｎ／２）×Ｎ）ＰＵ、（（３Ｎ／２）×Ｎ＋（Ｎ／２）×Ｎ）ＰＵ、（Ｎ×（Ｎ／２）＋Ｎ×（３Ｎ／２））ＰＵ、（Ｎ×（３Ｎ／２）＋Ｎ×（Ｎ／２））ＰＵ、４つの（Ｎ／２）×２Ｎ  ＰＵ、または４つの２Ｎ×（Ｎ／２）ＰＵに分割し得る。いくつかの例では、ビデオコーダは２Ｎ×２Ｎ  ＰＵを使用して２Ｎ×２Ｎ  ＣＵを予測し得る。
【００８４】
[0093]現在ビデオブロック１０２は、ルーマビデオブロック、またはルーマビデオブロックに対応するクロマビデオブロックであり得る。いくつかの例では、ビデオエンコーダ２０は、ルーマビデオブロックのための２次元ベクトル１０６を定義する１つまたは複数のシンタックス要素のみを符号化ビデオビットストリーム中に符号化し得る。そのような例では、ビデオデコーダ３０は、ルーマブロックについてシグナリングされた２次元ベクトルに基づいて、ルーマブロックに対応する１つまたは複数のクロマブロックの各々について２次元ベクトル１０６を導出し得る。
【００８５】
[0094]カラーフォーマット、たとえば、カラーサンプリングフォーマットまたはクロマサンプリングフォーマットに応じて、ビデオコーダは、ルーマビデオブロックに対して、対応するクロマビデオブロックをダウンサンプリングし得る。カラーフォーマット４：４：４はダウンサンプリングを含まず、これは、クロマブロックが水平方向および垂直方向においてルーマブロックと同数のサンプルを含むことを意味する。カラーフォーマット４：２：２は水平方向においてダウンサンプリングされ、これは、ルーマブロックに対してクロマブロック中では水平方向において半数のサンプルがあることを意味する。カラーフォーマット４：２：０は水平方向および垂直方向においてダウンサンプリングされ、これは、ルーマブロックに対してクロマブロック中では水平方向および垂直方向において半分の数のサンプルがあることを意味する。
【００８６】
[0095]ビデオコーダが、対応するルーマブロックのためのベクトル１０６に基づいてクロマビデオブロックのためのベクトル１０６を決定する例では、ビデオコーダはルーマベクトルを変更する必要があり得る。たとえば、ルーマベクトル１０６が、水平変位成分１１２および／または垂直変位成分１１０が奇数のピクセルである整数解像度を有し、カラーフォーマットが４：２：２または４：２：０である場合、変換されたルーマベクトルは、対応するクロマブロック中の整数ピクセルロケーションを指さないことがある。そのような例では、ビデオコーダは、対応するクロマブロックを予測するためのクロマベクトルとして使用するためにルーマベクトルをスケーリングし得る。いくつかの例では、ビデオエンコーダ２０は、クロマブロックを予測するために使用される変換されたルーマベクトル１０６が、再構成されない、またはインループフィルタ処理された予測クロマブロックを指さないことがあるように、対象とする領域１０８を定義するか、または変換されたベクトルをスケーリングし得る。本開示では、クロマブロックのためのベクトルのスケーリングが明示的に言及されない場合、そのようなスケーリングが行われないと仮定されるべきでない。クロマブロックのためのベクトルのスケーリングは、本開示で説明する例において明示的に説明されない場合でも行われ得る（しかし、あらゆる場合において必要であるとは限らない）。
【００８７】
[0096]図３は、ビデオエンコーダ２０が、ビデオデータの現在ブロックを予測するためのビデオデータの予測ブロックをそこから選択し得る、対象とする領域を定義するための例示的な技法を示す概念図である。図３によって示されている例では、ビデオエンコーダ２０は、ビデオデータの現在ブロック１２２を予測し、符号化している。ビデオエンコーダ２０は、現在ビデオブロック１２２を予測するために、対象とする領域１２８内のビデオデータの予測ブロック１２４を選択する。ビデオエンコーダ２０は、現在ビデオブロック１２２に対する予測ビデオブロック１２４の変位を示す、水平変位成分１３２および垂直変位成分１３０を含む、２次元ベクトル１２６を決定する。ビデオエンコーダ２０は、２次元ベクトル１２６を定義する符号化ビデオビットストリーム中の１つまたは複数のシンタックス要素を符号化する。
【００８８】
[0097]いくつかの例では、ビデオエンコーダ２０は、特にビデオデコーダ３０における実装形態および処理の複雑さが低減され得るように、対象とする領域１２８を定義し、たとえば、高さ、幅、または他の寸法など、対象とする領域のサイズを定義する。そうする際に、ビデオエンコーダ２０は、２次元ベクトル１２６のサイズを限定し得、たとえば、垂直変位成分１３０および／または水平変位成分１３２のサイズを限定する。いくつかの例では、ビデオエンコーダ２０は、ビデオエンコーダ２０およびビデオデコーダ３０によるビデオデータ並列処理を可能にするために、対象とする領域１２８を限定し得る。いくつかの例では、ビデオエンコーダ２０は、デブロッキングおよびサンプル適応オフセット（ＳＡＯ：sample adaptive offset）フィルタ処理などのインループフィルタ処理なしに、ならびにビデオコーダのメモリ要件に過度に負担をかけることまたはそのようなインループフィルタ処理の適用を遅延させることなしに、予測ビデオブロックの使用を可能にするために、対象とする領域１２８を限定し得る。
【００８９】
[0098]図３に示されているように、現在ビデオブロック１２２は現在ＬＣＵ１３４内にある。図３は、現在ＬＣＵの左に隣接する（左）ＬＣＵ１３６をも示している。左ＬＣＵ１３６は、ピクチャのビデオブロックが、一般に、左上から右下へのラスタ走査順序で符号化されるので、図３に示されている。ピクチャのビデオブロックが異なる順序でコーディングされる例では、左ＬＣＵ１３６に関する以下の説明は、現在ＬＣＵ１３４の異なる隣接ＬＣＵに適用され得る。
【００９０】
[0099]いくつかの例では、ビデオエンコーダ２０は、フェッチされた予測ビデオブロック１２４が現在ビデオブロック１２２と同じＬＣＵ内、すなわち、現在ＬＣＵ１３４内にあるように、対象とする領域１２８を限定し得る。対象とする領域１２８を現在ＬＣＵ１３４に限定することは、ビデオコーダの処理ユニットが、現在ＬＣＵのブロックをコーディングするときに別のＬＣＵからの情報を必要としないことがあるので、ビデオコーダによるＬＣＵの並列処理を可能にし得る。
【００９１】
[0100]対象とする領域１２８が現在ＬＣＵ１３４に限定されるいくつかの例では、２次元ベクトル１２６は、現在ビデオブロック１２２が現在ＬＣＵ１３４の最上ブロックである場合、水平ベクトルに限定され、現在ビデオブロック１２２が現在ＬＣＵ１３４の最左ブロックである場合、垂直ベクトルに限定され得る。そのような例では、ビデオエンコーダ２０は、２次元ベクトル１２６の水平変位成分１３２を定義する１つまたは複数のシンタックス要素を符号化し得、現在ビデオブロック１２２が現在ＬＣＵ１３４の最上ブロックである場合、ゼロになるであろう、２次元ベクトル１２６の垂直変位成分１３０を定義する１つまたは複数のシンタックス要素を符号化する必要はない。同様に、ビデオエンコーダ２０は、２次元ベクトル１２６の垂直変位成分１３０を定義する１つまたは複数のシンタックス要素を符号化し得、現在ビデオブロック１２２が現在ＬＣＵ１３４の最左ブロックである場合、ゼロになるであろう、２次元ベクトル１２６の水平変位成分１３２を定義する１つまたは複数のシンタックス要素を符号化する必要はない。同様に、対象とする領域１２８が現在ＬＣＵ１３４に限定され、現在ビデオブロック１２２が現在ＬＣＵ１３４の左上ユニットである場合、２次元ベクトル１２６の垂直変位成分１３０と水平変位成分１３２の両方はゼロでなければならない。この状況に遭遇するいくつかの例では、ビデオエンコーダ２０は、イントラＢＣを実行しないことがあり、２次元ベクトル１２６を示すためのシンタックス要素など、イントラＢＣのためのシンタックス要素、または現在ビデオブロック１２２がイントラＢＣに従って予測されるかどうかを示すフラグをシグナリングする必要はない。
【００９２】
[0101]対象とする領域が現在ＬＣＵに限定され、現在ビデオブロックが現在ＬＣＵ内の特定の位置内にあるときにイントラＢＣのためのシグナリングを低減するためのこれらの技法は、同様に、ＪＣＴ−ＶＣ  Ｍ０３５０において提案された技法など、１次元動きベクトルに限定されたイントラＢＣ技法にも適用され得る。たとえば、垂直動きベクトルが現在ＬＣＵ内にあるように制限され、現在ユニットが最上ユニットである場合、動きが垂直方向であるのか水平方向であるのかをシグナリングする必要はない。
【００９３】
[0102]いくつかの例では、ビデオエンコーダ２０は、対象とする領域１２８が現在ＬＣＵ１３４および１つまたは複数の隣接ＬＣＵ、たとえば、図３に示されているように左ＬＣＵ１３６中の再構成されたエリアの一部内にあるように限定し得る。このようにして、ビデオエンコーダ２０は、現在ＬＣＵ１３４内の再構成されたブロックに加えて、図３に示されているように、左ＬＣＵ１３６などの１つまたは複数の隣接ＬＣＵの再構成されたエリア中のブロックのみを２次元ベクトル１２６が参照し得るように、それらを限定する。
【００９４】
[0103]いくつかの例では、ビデオエンコーダ２０は、現在ＬＣＵ１３４のサイズに基づいて、対象とする領域１２８のサイズを限定する。たとえば、図３に示されているように、ビデオエンコーダ２０は、対象とする領域１２８が、現在ＬＣＵ１３４および左ＬＣＵ１３６を越えて垂直方向に延びないように、現在ＬＣＵ１３４の高さ（または垂直方向上限）に基づいて、対象とする領域１２８の高さ１３８を限定し得る。ＬＣＵ（またはＣＴＢ）のサイズは、ビデオエンコーダ２０によって、たとえば、スライスヘッダ、パラメータセット、またはＳＥＩメッセージを介して、符号化ビデオビットストリーム中でビデオデコーダ３０にシグナリングされ得、したがって、ＬＣＵサイズに基づく対象とする領域に対する限定もビデオデコーダ３０に効果的にシグナリングされ得る。いくつかの例では、ビデオエンコーダ２０は、整数個のピクセルに基づいて、サイズ、たとえば、対象とする領域１２８の現在ビデオブロック１２２の左側の幅１４０または高さ１３８を限定する。たとえば、ビデオエンコーダ２０は、現在ビデオブロック１２２の左側の幅１４０を、ＬＣＵ１３４および１３６の幅に対応し得る、６４個など、整数個のピクセルに限定し得る。
【００９５】
[0104]ビデオエンコーダ２０は、デブロッキングおよびサンプル適応オフセット（ＳＡＯ）フィルタ処理などのインループフィルタ処理なしに、再構成されたビデオブロックを含むように、対象とする領域１２８を限定し得る。このようにして、ビデオエンコーダ２０は、現在ＬＣＵ１３４に加えて、インループフィルタ処理が実行されなかった、左ＬＣＵ１３６などの隣接ＬＣＵの再構成されたエリア中のブロックのみをイントラＢＣのための２次元ベクトルが参照し得るように、それらを限定し得る。ビデオエンコーダ２０は、対象とする領域１２８のサイズを増加させることができるが、そのような増加は、対象とする領域中のビデオブロックのインループフィルタ処理およびさらなる処理を遅延させるか、またはインループフィルタ処理より前にサンプルを記憶するための追加のメモリを必要とし得る。したがって、ビデオエンコーダ２０は、予測精度と効率との間のバランスをとるために、たとえば、本明細書で説明するように、対象とする領域１２８を限定し得る。
【００９６】
[0105]図４は、ビデオデータの現在ブロック２６０、およびビデオデータの現在ブロックのための候補予測ベクトルがそこから導出され得るビデオデータの隣接ブロック２６２、２６４、２６６の一例概念図である。いくつかの例では、インター予測のためのマージモードまたは高度動きベクトル予測（ＡＭＶＰ）モードと同様に、ビデオコーダは、イントラＢＣを使用して、隣接ビデオブロック、たとえば、ＰＵを予測するために使用される２次元ベクトルに基づいて、現在ビデオブロック、たとえばＰＵのための予測２次元ベクトルを決定し得る。図４に示された隣接ブロックは、左隣接ブロック２６２と、上（above）（上（top））隣接ブロック２６４と、左上（above-left）（左上（top-left））隣接ブロック２６６とを含む。図４に示された隣接ブロックは一例である。他の例では、ビデオコーダは、より多くの隣接ブロック、より少ない隣接ブロック、および／またはインター予測のためのマージモードおよびＡＭＶＰモードに従って考慮され得る任意の隣接ブロックなど異なる隣接ブロックのベクトルを考慮し得る。
【００９７】
[0106]予測子は、隣接ブロックのうちの選択された隣接ブロックからの２次元ブロックベクトルの水平変位成分および／または垂直変位成分であり得る。いくつかの例では、予測子は、常に、特定の隣接ユニット、たとえば、上隣接ユニットまたは左隣接ユニットからである。いくつかの例では、隣接ブロックのうちのどれが現在ＰＵのための予測２次元ブロックベクトルを与えるかは、ＰＵのインデックスおよび／またはＰＵ形状に基づいて決定される。いくつかの例では、予測子は、複数の隣接ユニットからの２次元ブロックベクトルの水平および／または垂直成分の（平均値または中央値などの）関数であり得る。
【００９８】
[0107]概して、隣接ブロックが予測２次元ベクトルを与えることができない場合、予測２次元ベクトル（または候補予測２次元ベクトル）はゼロまたはデフォルト２次元ベクトルに設定され得る。いくつかの例では、隣接ブロックのベクトルは、隣接ビデオブロックがイントラＢＣに従って予測されたとき、現在ビデオブロックのための予測ベクトルとして利用可能であるにすぎないことがある。言い換えれば、イントラＭＣモードを用いてコーディングされない隣接ブロックは、現在ビデオブロックのためのブロックベクトル予測のために利用不可能であると見なされ得る。たとえば、予測子が常に左隣接ブロックからであり、左隣接ブロックがイントラＭＣモードを用いて予測されたとき、それの２次元ベクトルは予測２次元ベクトルとして使用される。予測子が常に左隣接ブロックからであり、左隣接ブロックが、イントラＭＣモードを用いて予測されなかったとき、ビデオコーダは、現在ビデオブロックのための予測２次元ベクトルとしてゼロベクトルまたはデフォルトベクトルを使用し得る。
【００９９】
[0108]いくつかの例では、ビデオコーダは、隣接ビデオブロックの２次元ベクトルが、現在ビデオブロック、たとえば、ＣＵまたはＰＵと同じＬＣＵあるいは他のより大きいまたは最も大きいコーディングユニット中にない場合、隣接ビデオブロックの２次元ベクトルを現在ビデオブロックの２次元ベクトルの予測のために利用不可能であると見なし得る。いくつかの例では、現在ビデオブロック、たとえば、ＰＵまたはＣＵのための現在２次元ベクトルが現在ＣＵまたはＬＣＵの第１のものである場合、現在ビデオブロックのための予測２次元ベクトルはゼロまたはデフォルト２次元ベクトルに設定され得る。上隣接ＣＵと現在ＣＵとが同じＬＣＵ中にない場合、上隣接ＣＵが利用不可能であると見なされることが可能である。また、左隣接ＣＵと現在ＣＵとが同じＬＣＵ中にない場合、左隣接ＣＵが利用不可能であると見なされることが可能である。
【０１００】
[0109]いくつかの例では、インター予測のためのマージモードおよびＡＭＶＰモードと同様の様式で、ビデオエンコーダ２０およびビデオデコーダ３０は、いくつかの隣接ブロックのブロックベクトルを含む現在ビデオブロックのための候補予測ベクトルのセットを構成し得る。そのような例では、ビデオエンコーダ２０は、現在ビデオブロックのための予測２次元ベクトルを与えるためにどの候補が使用されるかをシグナリングするインデックスを符号化し得、ビデオデコーダ３０はそれを復号し得る。いくつかの例では、ビデオコーダは、それぞれ、たとえば、異なる隣接ブロックからの異なる候補ベクトルに基づいて予測２次元ベクトルの水平変位成分および垂直変位成分を決定し得る。そのような例では、ビデオコーダは、それぞれのインデックスを候補リスト水平変位成分および垂直変位成分にコーディングし得る。
【０１０１】
[0110]一例として、イントラＢＣモードに従ってコーディングされた現在ＣＵの場合、それのブロックベクトルをコーディングするために、ビデオコーダは左隣接ＣＵおよび上隣接ＣＵをチェックする。それらのいずれも利用可能でなく、たとえば、イントラＢＣに従ってコーディングされなかった場合、ビデオコーダは、現在ＣＵの予測２次元ベクトルが（水平成分と垂直成分の両方について）ゼロベクトルであると決定し得る。隣接ＣＵのうちの１つのみが利用可能であり、たとえば、イントラＢＣによってコーディングされた場合、ビデオコーダは、現在ＣＵの現在２次元ベクトルの予測２次元ベクトルとして利用可能な隣接ＣＵを予測するために使用されたベクトルを使用する。両方の隣接ＣＵが利用可能であり、たとえば、イントラＢＣによってコーディングされており、それらの２次元ベクトルが同じである場合、この２次元ベクトルは予測２次元ベクトルとして使用される。両方の隣接ＣＵが利用可能であり、たとえば、イントラＢＣによってコーディングされており、それらのブロックベクトルが異なる場合、ビデオコーダは、上隣接ＣＵからのブロックベクトルが現在ＣＵのための予測２次元ベクトルとして使用されるのか、左隣接ＣＵからのブロックベクトルが現在ＣＵのための予測２次元ベクトルとして使用されるのかを示すためのフラグまたは他のシンタックス要素をコーディングし得る。
【０１０２】
[0111]別の例では、ビデオコーダは、（非制限的な例として）セット（−ｗ，０）、（−２ｗ，０）、（−８，０）、（０，０）、（０，８）、（０，−ｈ）、（０，−２ｈ）からであり得る、２つまたはそれ以上のデフォルトブロックベクトルを定義し得、ここで、ｗおよびｈは、現在ビデオブロック、たとえば、ＣＵの幅および高さであり、第１の成分は水平変位であり、第２の成分は垂直変位である。左隣接ＣＵと上隣接ＣＵの両方が利用可能である場合、ビデオコーダは、それらのベクトルを現在ＣＵのための第１および第２の予測２次元ベクトルとして使用し得る。それらの一方が利用可能でない場合、ビデオコーダは、候補予測ベクトルのリスト中の利用不可能な予測ベクトルを置き換えるために、デフォルト予測ベクトルを使用し得る。それらの両方が利用可能でない場合、ビデオコーダは、候補予測ベクトルのリスト中の利用不可能な予測ベクトルを置き換えるために、同じまたは異なり得る２つのデフォルト予測ベクトルを使用し得る。利用不可能な予測ベクトルを候補リスト中のデフォルトベクトルと置き換えることの利点は、ビデオデコーダ３０がこのフラグを条件付きでパースする必要がないように、予測子間の選択のためのフラグも符号化ビデオビットストリーム中に含められ得ることである。本明細書では、例について、２つの隣接ブロックから導出される２つの予測ベクトルを含む候補リストに関して説明するが、他の例では、ブロック／ベクトルが利用可能である場合、ビデオコーダは、より多いまたはより少ない隣接ブロックを考慮し、より多いまたはより少ない予測２次元ベクトルを候補リスト中に含め得る。
【０１０３】
[0112]いくつかの例では、各ＬＣＵ中の第１のビデオブロックおよびイントラＢＣのために使用される対応する２次元ベクトルについて、ビデオコーダは、ＬＣＵ内の他のブロックおよび関連するベクトルの場合とは異なる、それの予測２次元ベクトルを決定するための導出プロセスを使用し得る。たとえば、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＬＣＵ中の第１のビデオブロックのための予測２次元ベクトルおよびイントラＢＣのために使用される対応する２次元ベクトルがデフォルト２次元ベクトルであると決定し得る。デフォルト２次元ベクトルは（−ｗ，０）であり得、ここで、ｗは現在ビデオブロック、たとえば、ＣＵの幅である。他の例では、デフォルト２次元ベクトルは、（−２ｗ，０）、（−８，０）、（０，０）、（０，８）、（０，−ｈ）、（０，−２ｈ）であり得、ここで、ｗおよびｈは、現在ビデオブロック、たとえば、ＣＵの幅および高さである。他の例では、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＬＣＵ中の第１のビデオブロックのための予測２次元ベクトルと、イントラＢＣのために使用される対応する２次元ベクトルとを導出し得る。いくつかの例では、ビデオコーダは、ＬＣＵ中の異なるサイズをもつまたは異なる位置における、ビデオブロック、たとえば、ＣＵの場合とは別様に、ＬＣＵ中のイントラＢＣを使用してコーディングされた第１のビデオブロックのための予測２次元ベクトルを導出し得るか、あるいは言い換えれば、ＬＣＵ中のビデオブロックサイズまたは位置に基づいて、ＬＣＵ中のイントラＢＣを使用してコーディングされた第１のビデオブロックのための予測２次元ベクトルを別様に導出し得る。
【０１０４】
[0113]いくつかの例では、ビデオコーダは、現在ビデオブロックの２次元ベクトルの水平および垂直成分が、フラグ、シンタックス要素に基づくか、または他の情報に基づき得る（特定の色空間（たとえば、ＹＵＶ、ＲＧＢなど）、特定のカラーフォーマット（たとえば、４：２：０、４：４：４など）、フレームサイズ、フレームレート、または量子化パラメータ（ＱＰ）あるいは前にコーディングされたフレームに基づき得る）と決定するために使用される１つまたは複数の方法を選択し得る。
【０１０５】
[0114]いくつかの例では、ビデオエンコーダ２０は、ビデオブロック、たとえば、ＣＵが、イントラＭＣまたはイントラＢＣモードと呼ばれることがある、同じピクチャ中の予測ビデオブロックに基づいて現在ビデオブロックを予測するためのモードを使用して符号化されるかどうかをビデオデコーダ３０に示すためのフラグ、たとえば、ＩｎｔｒａＭＣ＿ｆｌａｇまたはＩｎｔｒａＢＣ＿ｆｌａｇを符号化し得る。フラグは、値が、１つまたは複数のＣＵ、あるいは他のブロックまたはユニットが、たとえば、本明細書で説明するようにイントラＭＣまたはイントラＢＣモードを使用して符号化されるか否かを示す１ビットフラグであり得る。ビデオコーダは、各ビデオブロック、たとえば、ＣＵまたはＰＵのためのフラグの値をコーディングし得るか、あるいは、たとえば、スライス内の、またはフレームもしくはピクチャ、またはピクチャのシーケンス内の複数のビデオブロックの各々に対するフラグの値をコーディングし得る。ビデオコーダは、例として、スライスヘッダ、パラメータセット（たとえば、ＰＰＳ）、またはＳＥＩメッセージ中にフラグをコーディングし得る。
【０１０６】
[0115]ビデオコーダは、バイパスモードでフラグをコーディングするか、またはコンテキストを用いてフラグを算術符号化し、たとえば、ＣＡＢＡＣ符号化し得る。いくつかの例では、ビデオコーダは、隣接ビデオブロックに依存しない単一の固定コンテキストを用いてフラグを算術コーディングし、たとえば、ＣＡＢＡＣ符号化し得る。他の例では、ビデオコーダは、隣接ビデオブロックから導出されたコンテキストを用いてフラグを算術コーディングし、たとえば、ＣＡＢＡＣ符号化し得る。
【０１０７】
[0116]図４を参照すると、ビデオコーダがＣＡＢＡＣコンテキストを使用して現在ビデオブロック２６０のためのフラグをコーディングしたとき、コンテキストの値は、上（上）隣接ビデオブロック２６４、左上（左上）隣接ビデオブロック２６６、または左隣接ビデオブロック２６２などの隣接ビデオブロックから導出され得る。ビデオコーダは、上隣接ビデオブロック２６４などの隣接ビデオブロックを、それが現在ビデオブロックと同じＬＣＵ内にあるとき、現在ビデオブロックのためのコンテキストを導出するために利用可能であり、隣接ビデオブロックが現在ＬＣＵの外側にあるとき、利用不可能であると見なし得る。
【０１０８】
[0117]一例として、現在ビデオブロックの場合、ビデオコーダはコンテキスト値＝（ｔｏｐ  ＩｎｔｒａＭＣ＿ｆｌａｇ＝＝０）？０：１＋（ｌｅｆｔ  ＩｎｔｒａＭＣ＿ｆｌａｇ＝＝０）？０：１を導出し得る。いくつかの例では、ビデオコーダは、常に、隣接ビデオブロック２６２、２６４、２６６のうちの特定の隣接ビデオブロック、たとえば、左隣接ビデオブロック２６２から現在ビデオブロック２６０のためのコンテキストを導出し得、現在ビデオブロックのためのコンテキスト値は（ｌｅｆｔ  ＩｎｔｒａＭＣ＿ｆｌａｇ＝＝０）？０：１である。いくつかの例では、ビデオコーダは、ビデオブロック、たとえば、ＣＵのサイズに依存するコンテキスト値を使用してフラグをコーディングする。いくつかの例では、異なるサイズをもつビデオブロックは、異なるコンテキスト値を有する。言い換えれば、各ビデオブロック、たとえば、ＣＵのサイズは、それぞれの一意のコンテキスト値に関連し得る。いくつかの例では、異なるあらかじめ定義されたサイズをもついくつかのビデオブロック、たとえば、ＣＵは、同じコンテキスト値を共有し、他のサイズをもつビデオブロックは１つまたは複数の異なるコンテキスト値を使用する。言い換えれば、ビデオコーダは、複数のコンテキスト値の各々を、考えられるビデオブロック、たとえば、ＣＵのサイズのそれぞれのセットまたは（１つまたは複数の）範囲に関連付け得る。
【０１０９】
[0118]いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、単項コードに基づいてイントラＢＣのための２次元ベクトルの水平変位成分および垂直変位成分（たとえば、図２の２次元ベクトル１０６の水平変位成分１１２および垂直変位成分１１０）をコーディングし得る。他の例では、ビデオコーダは、指数ゴロムコードまたはライスゴロムコードに基づいて水平変位成分および垂直変位成分をコーディングし得る。
【０１１０】
[0119]いくつかの例では、水平変位成分および垂直変位成分は、現在ビデオブロックの上および左の領域のみを示し得、ビデオコーダは、これらの値のための符号ビットを保持またはコーディングする必要がないことがある。いくつかの例では、ビデオコーダは、現在ビデオブロックの上および左のエリアが現在ビデオブロックに対して正の方向を表し得るように基準系を構成し得る。そのような例では、現在ビデオブロックの上および／または左のビデオブロックのみが候補予測ビデオブロックと見なされる場合、ビデオコーダは、水平変位成分および垂直変位成分のすべての値が正（または負）値を表し、現在ビデオブロックの上および／または左のビデオブロックを示すことがあらかじめ定義され得るので、符号ビットを保持またはコーディングする必要がないことがある。
【０１１１】
[0120]いくつかの例では、これらの２次元ベクトルの最大サイズ（または残差２次元ベクトルなど、１つまたは複数の２次元ベクトル間の差）は、上記で説明したように、たとえば、対象とする領域の定義および／またはパイプライン制約により、小さくなり得る。そのような例では、ビデオエンコーダ２０は、切捨て値を用いてこれらの２次元ブロックベクトルを２値化し得る。いくつかの例では、ビデオエンコーダ２０は、２次元ベクトルをエントロピー符号化する際に、たとえば、２次元ベクトルの水平変位成分および垂直変位成分を符号化する際に、切捨て単項コード、切捨て指数ゴロムコード、または切捨てゴロムライスコードを採用し得る。
【０１１２】
[0121]本明細書で説明する様々な切捨て符号化方式のいずれかにおいてビデオエンコーダ２０が使用し得る切捨て値は、たとえば、ＬＣＵサイズに基づいて一定であり得る。いくつかの例では、切捨て値は、水平変位成分と垂直変位成分とについて同じであり得る。他の例では、切捨て値は、水平変位成分と垂直変位成分とについて異なり得る。
【０１１３】
[0122]１つの例示的な例として、ＬＣＵのサイズが６４、たとえば、６４×６４であり、たとえば、図３に関して上記で説明したように、２次元ベクトルの垂直成分がＬＣＵ内にあると限定される場合、切捨ては、２次元ベクトルの水平成分の場合、６３に等しく、２次元ベクトルの垂直成分の場合、６３−ＭｉｎＣＵＳｉｚｅに等しくなり得る。いくつかの例では、切捨て値は、ＬＣＵ内の現在ビデオブロックの位置に応じて適応され得る。たとえば、２次元ベクトルの垂直成分がＬＣＵ内にあるように限定される場合、ビデオエンコーダは、ベクトル２値化を現在ビデオブロックの上位置とＬＣＵの上位置との間の差に切り捨てることができる。
【０１１４】
[0123]ビデオエンコーダ２０は、バイパスモードを使用して２次元ベクトルの水平および垂直成分の２値化をエントロピー符号化し得るか、または、たとえば、ＣＡＢＡＣコンテキストを用いて、２値化を算術符号化し得る。たとえば、ビデオエンコーダ２０は、たとえば、図３に示されているように、予測ビデオブロックの探索を対象とする領域に限定し、２次元ベクトル（ＭＶ）の成分の分布はゼロを中心としないことがある。たとえば、ＭＶ＿ｘは、（同じ行の）現在ビデオブロック、たとえば、ＣＵの右のピクセルが符号化／再構成されていないので、負になる傾向がある。同様に、ＭＶ＿ｙは、（同じ列の）現在ビデオブロック、たとえば、ＣＵの下のピクセルが符号化／再構成されていないので、負になる傾向がある。
【０１１５】
[0124]バイパスモードでは、０と１とについて等しい確率を仮定し得る。符号について、これは、バイパスモードが、正または負になる等しい確率を仮定することを意味する。２次元ベクトルの成分は、正または負になる等しい確率を有しないので、ビデオエンコーダ２０は、コンテキストを用いて、たとえば０．５以外の初期確率を用いて符号を算術符号化し、たとえば、ＣＡＢＡＣ符号化し得る。
【０１１６】
[0125]ビデオエンコーダ２０が２次元ベクトルの水平成分（ＭＶ＿ｘ）をどのように符号化し得るかについての一例は以下の通りである。ＭＶ＿ｘに関して説明するが、本技法はまた、２次元ベクトルの垂直成分（ＭＶ＿ｙ）、または現在ベクトルと予測ベクトルとの間の差を表す残差２次元ベクトルの水平または垂直成分、たとえば、ｍｖｄ＿ｘおよびｍｖｄ＿ｙを符号化するために適用され得る。
【０１１７】
[0126]ＭＶ＿ｘは、符号値と、（ａｂｓ（ＭＶ＿ｘ）のための）２値化ストリングｂ０ｂ１．．．とによって表され得る。第１のビンｂ０は、ａｂｓ（Ｍｖ＿ｘ）＞０である場合は（ｂ０＝１）、またはａｂｓ（Ｍｖ＿ｘ）＞０でない場合は（ｂ０＝０）を示す。ビデオエンコーダ２０は、コンテキストをもつＣＡＢＡＣを使用して第１のビンｂ０をエンコーダし得る。Ｍｖ＿ｘおよびＭｖ＿ｙのためのｂ０は、別個のコンテキストを有し得るか、または同じコンテキストを共有し得る。いくつかの例では、イントラＢＣのＭＶコーディングにおけるｉ番目のビンは、インター動き補償のブロックベクトルコーディングにおけるｉ番目のビンと同じコンテキストを共有する。いくつかの例では、イントラＢＣのＭＶコーディングにおけるｉ番目のビンとインター動き補償のブロックベクトルコーディングにおけるｉ番目のビンとはコンテキストを共有しない。
【０１１８】
[0127]後続のビンｂ１ｂ２．．．はａｂｓ（ＭＶ＿ｘ）−１の値を表し、ビデオエンコーダ２０は、バイパスモードでパラメータ３をもつ指数ゴロムコードを使用してこれらのビンを符号化し得る。いくつかの例では、ビデオエンコーダ２０は、指数ゴロムコードの他の次数、たとえば、１、２、４、５を使用する。いくつかの例では、ｂ１は、ａｂｓ（ＭＶ＿ｘ）＝１である場合は（ｂ１＝１）、またはａｂｓ（ＭＶ＿ｘ）＝１でない場合は（ｂ１＝０）を表す。いくつかの例では、ビデオエンコーダ２０は、バイパスモードを用いてまたはＣＡＢＡＣコンテキストを用いてｂ１を符号化し得る。
【０１１９】
[0128]いくつかの例では、ｂ２ｂ３．．．はａｂｓ（ＭＶ＿ｘ）−２の値を表し、ビデオエンコーダ２０は、バイパスモードで、パラメータ３をもつ指数ゴロムコードを使用して、または指数ゴロムコードの他の次数を使用して、これらのビンを符号化し得る。最後のビンはＭＶ＿ｘの符号を示し得、ビデオエンコーダ２０は、コンテキストを用いずにバイパスモードでこのビンを符号化し得る。他の例では、ビデオエンコーダ２０は、１つまたは複数のコンテキストをもつＣＡＢＡＣを使用して符号化された符号ビンを符号化し得る。ＭＶ＿ｘおよびＭＶ＿ｙの符号ビンは別個のコンテキストを有し得るか、またはそれらが同じコンテキストを共有することが可能である。
【０１２０】
[0129]いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、イントラＢＣモードの適用、およびフラグ、ベクトル成分、または他のシンタックスの関連するコーディングを、特定のサイズの、すなわち、特定のサイズ基準を満たすビデオブロックに限定し得る。サイズ基準は、最大ブロックサイズおよび／または最小ブロックサイズ（たとえば、ＩｎｔｒａＭＣ＿ＭａｘＳｉｚｅおよびＩｎｔｒａＭＣ＿ＭｉｎＳｉｚｅ）の一方または両方であり得る。ビデオエンコーダ２０は、たとえば、フラグまたは他のシンタックス要素を使用して、符号化ビデオビットストリーム中で１つまたは複数のサイズ基準をビデオデコーダ３０に示し得るか、あるいは、ビデオコーダは、特定の色空間（たとえば、ＹＵＶ、ＲＧＢなど）、特定のカラーフォーマット（たとえば、４：２：０、４：４：４など）、フレームサイズ、フレームレート、量子化パラメータ（ＱＰ）など、他の情報に基づいて、または前にコーディングされたフレームに基づいてサイズ基準を暗黙的に決定し得る。たとえば、小さいサイズのためのイントラＢＣは、システムのメモリ帯域幅要件に影響を及ぼし得、ビデオコーダは、イントラＢＣをサイズしきい値を上回るブロックに制限するように最小ブロックサイズ基準を適用し得る。
【０１２１】
[0130]図５Ａおよび図５Ｂに、２つのＰＵ（すなわちＰＵ０とＰＵ１）に分割されるＣＵの一例を示す。図５Ａおよび図５Ｂは、ＨＥＶＣ  ＡＭＶＰおよびマージのための空間ネイバー導出の図解イメージを示している。空間ネイバーは、イントラＢＣ  ＡＭＶＰモードまたはイントラＢＣマージモードのための候補を決定するためになど、ブロックベクトルコーディングのために使用され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、特定のＰＵ（ＰＵ０）について、図５Ａおよび図５Ｂに示されている隣接ブロックから空間ＭＶ候補を導出し得るが、ブロックから候補を生成する方法は、マージモードおよびＡＭＶＰモードについて異なり得る。マージモードでは、ビデオエンコーダ２０および／またはビデオデコーダ３０は、図５Ａに示されている順序を使用して最高４つの空間ＭＶ候補を導出し得る。順序は、図５Ａに示されているように、左（０）、上（１）、右上（２）、左下（３）、および左上（４）である。
【０１２２】
[0131]ＡＶＭＰモードでは、隣接ブロックは、図５Ｂに示されているように、２つのグループ、すなわち、ブロック０および１からなる左グループと、ブロック２、３、および４からなる上グループとに分割される。各グループについて、シグナリングされた参照インデックスによって示された参照ピクチャと同じ参照ピクチャを指す隣接ブロック中の潜在的な候補は、そのグループの最終候補を形成するために選定される最高優先順位を有する。すべての隣接ブロックが、同じ参照ピクチャを指すブロックベクトルを含んでいるとは限らない可能性があり得る。したがって、そのような候補が見つけられ得ない場合、第１の利用可能な候補は、最終候補を形成するためにスケーリングされ得、したがって、時間距離差分が補償され得る。
【０１２３】
[0132]イントラＢＣのための現在の技法はいくつかの潜在的な問題を有し得る。一例では、クロマサンプリングフォーマットが４：４：４でない（すなわち、４：２：０または４：２：２のいずれかである）とき、クロマ動き補償ブロックサイズは、２×２と同じくらい小さくなり、したがって、ベースＨＥＶＣ仕様においてサポートされるような最小ブロックサイズよりも小さくなり得る。参照ブロックにアクセスするとき、ビデオコーダは、一般に、あらかじめ定義されたメモリブロックのユニット（たとえば４×２、８×２）のブロックを読み取る。したがって、ブロックサイズが、あらかじめ定義されたメモリブロックユニットよりも小さい場合、補償において使用されないことがある余分のピクセルがアクセスされ、したがって、メモリアクセス効率が低下する。
【０１２４】
[0133]潜在的な問題の別の例として、クロマ成分のためにルーマブロックベクトルを単にスケーリングすることにより、現在ＣＵまたはＰＵ内の領域を指すブロックベクトルが生じ得る。別の例として、ブロックベクトル予測のＡＭＶＰ様式は、イントラＢＣの既存の実装形態において十分にサポートされない。
【０１２５】
[0134]本開示は、イントラＢＣ予測を改善し得る技法を導入する。本開示の一技法によれば、コード化ビデオデータが４：２：０のクロマサンプリングフォーマットを有するとき、ビデオデコーダ３０は、対応するルーマ成分を予測するために使用されるブロックベクトルとは異なる、クロマ成分を予測するためのブロックベクトルを使用し得る。たとえば、第１のルーマ成分のためのブロックベクトルとそれの対応する第１のクロマ成分のためのブロックベクトルとは同じであり得るが、第２のクロマ成分のためのブロックベクトルは、それの対応する第２のルーマ成分のためのブロックベクトルと同じでないことがある。そうではなく、第２のクロマ成分のためのブロックベクトルは、第１のルーマ成分のためのブロックベクトルと同じであり得る。
【０１２６】
[0135]ビデオデコーダ３０は、ルーマのために使用されるブロックベクトルからクロマのためのブロックベクトルを導出し得る。たとえば、４つのＮ×Ｎ  ＰＵに分割された２Ｎ×２Ｎ  ＣＵの場合、ビデオエンコーダ２０は、現在ＣＵ中の４つのＰＵ／ＴＵについて、コーディング順序で、４つのＢＶ、すなわちＢＶ1、ＢＶ2、ＢＶ3、およびＢＶ4をシグナリングし得る。本開示の技法によれば、ビデオデコーダ３０は、現在ＣＵのルーマ成分のイントラＢＣ予測のために、およびＣＵ全体の複数のクロマブロックのイントラＢＣ予測のための１つの単一のブロックベクトルの導出のために、４つのＢＶを使用し得る。したがって、４つのＰＵ／ＴＵを含んでいるＣＵが、複数のＰＵのクロマブロックのための（ＢＶcとして示される）１つの共通ブロックベクトルを共有し得る。
【０１２７】
[0136]ビデオデコーダ３０は、４つのルーマブロックベクトルから共通クロマブロックベクトルを生成し、クロマ成分のための動き補償の前に、ＨＥＶＣバージョン１において行われるようにルーマブロックベクトルをクロマブロックベクトルに変換するか、またはルーマブロックベクトルをクロマブロックベクトルとして直接使用し得る。ビデオデコーダ３０は、以下の方法のうちの１つによってルーマブロックベクトルＢＶLを導出し得る。
【０１２８】
１．ビデオデコーダ３０は、ＢＶ1、ＢＶ2、ＢＶ3、ＢＶ4のうちの最小ブロックベクトルＢＶLを選択し、たとえばスケーリングによって、ＢＶLをＢＶcに変換する。説明の目的で、ブロックベクトルＢＶaは、以下の可能な方法のうちの１つにおいて他のＢＶbよりも小さいと定義される。
【０１２９】
ａ．ＢＶa（ＢＶa［０］）の水平成分がＢＶbの水平成分よりも小さい場合
ｂ．ＢＶaの水平成分の（値ａに関して、｜ｘ｜として示される）絶対値がＢＶbの絶対値よりも小さい場合
ｃ．｜ＢＶa［０］｜＋｜ＢＶa［１］｜が｜ＢＶb［０］｜＋｜ＢＶb［１］｜のものよりも小さい場合
ｄ．ＢＶa（ＢＶa［１］）の垂直成分がＢＶbの垂直成分よりも小さい場合
２．上記の最小ブロックベクトル選択と同様に、ビデオデコーダ３０は、上記で定義したように１つのベクトルが他のベクトルよりも小さいとの様々な定義のうちの１つを用いて、４つのブロックベクトルのうちの最大ブロックベクトルを選択し得る。
【０１３０】
３．ビデオデコーダ３０は、ルーマブロックベクトルＢＶLを導出するために４つのルーマブロックベクトルのための水平および垂直成分を平均化することによって、平均ブロックベクトルを決定し得、ここにおいて、＋２／−２を加算することの丸めが、平均化中に適用することも適用しないこともある。ＢＶLは、共通クロマブロックベクトルを決定するためにスケーリングされ得る。
【０１３１】
４．ビデオデコーダ３０は、ＢＶLとしてＢＶ1、ＢＶ2、ＢＶ3、およびＢＶ4から１つのブロックベクトルを選択し得る。選定されたブロックベクトルは、たとえば、常にＢＶ1、常にＢＶ2など、４つのうちの固定された１つであり得るか、またはビットストリーム中で明示的にシグナリングされ得る。
【０１３２】
[0137]本開示の別の技法によれば、コード化ビデオデータが４：２：２のクロマサンプリングフォーマットを有するとき、ビデオデコーダ３０は、ルーマのために使用されるＢＶとは異なる、クロマのためのＢＶを使用し得る。代わりに、ビデオデコーダ３０は、ルーマのために使用される（１つまたは複数の）ＢＶからクロマのために使用されるＢＶを導出し得る。たとえば、イントラＢＣは、ＰＵ／ＴＵに拡張され、ＰＵ／ＴＵが２Ｎ×２Ｎ  ＣＵについてＮ×Ｎであると仮定し得、次いで、現在ＣＵ中の２つのＰＵ／ＴＵについて、コーディング順序で、２つのＢＶ、すなわちＢＶ1、およびＢＶ2がある。上記で説明した技法と同様に、最小ベクトル、最大ベクトル、または平均ベクトルは、ＣＵ全体のクロマブロックのために現在ＰＵの２つのＰＵ／ＴＵの２つのブロックベクトルから生成され得る。
【０１３３】
[0138]本開示の一技法によれば、４つのＮ×ＮイントラＢＣ  ＰＵ／ＴＵを用いてコーディングされる２Ｎ×２Ｎ  ＣＵの場合、ビデオデコーダ３０は、クロマサンプリングフォーマットが４：４：４でないとき、Ｎ×Ｎ  ＰＵ／ＴＵのブロックベクトルから生成された単一のブロックベクトルを用いてクロマ成分を予測し得る。しかしながら、ビデオデコーダ３０は、依然として、ＰＵのルーマ成分を予測するために４つの別個のブロックベクトルを使用し得る。たとえば、４つのＮＸＮ  ＰＵに分割される２Ｎ×２Ｎ  ＣＵの場合、ビデオエンコーダ２０は、４つの別個のブロックベクトル、すなわち、ＣＵの各ＰＵのためのブロックベクトルをシグナリングし得る。ビデオデコーダ３０は、それらの４つの別個のブロックベクトルを復号し、４つのＰＵのルーマ成分を予測するために４つの別個のブロックベクトルを使用し得る。しかしながら、４つのＰＵのクロマ成分について、ビデオデコーダ３０は、４つのブロックベクトルのうちの１つを選択し、ＣＵのＰＵのうちの２つ以上のためのクロマ成分を予測するためにその１つのブロックベクトルを使用し得る。いくつかの事例では、ビデオデコーダ３０は、ＣＵのすべての４つのＰＵのためのクロマ成分を予測するために１つのブロックベクトルを使用し得る。
【０１３４】
[0139]別の例では、４つのＮ×ＮイントラＢＣ  ＰＵ／ＴＵを用いてコーディングされる２Ｎ×２Ｎ  ＣＵの場合、ビデオデコーダ３０は、クロマサンプリングフォーマットが４：４：４以外であるとき、Ｎ×Ｎ  ＰＵ／ＴＵのブロックベクトルから生成された２つのブロックベクトルを用いてクロマ成分を予測し得る。２つのブロックベクトルの各々は、１つのＮ／２ｘＮブロックまたはＮｘＮ／２ブロックを予測するために使用され得る。言い換えれば、２つのブロックベクトルの各々は、ＣＵの４つのＰＵのうちの２つを予測するために使用され得る。ビデオデコーダ３０は、ＣＵのＰＵの４つのブロックベクトルのうちの少なくとも１つがチェックされ、２つのルーマブロックベクトルがこれらのブロックベクトルに応じて導出されることをチェックし得る。より詳細には、たとえば、４つのブロックベクトルは比較され、他のペアよりも近い距離をもつ２つの隣接ブロックベクトルが選定され得る。
【０１３５】
[0140]一例では、ｄｉｓ（ＢＶ0、ＢＶ1）、ｄｉｓ（ＢＶ0、ＢＶ2）、ｄｉｓ（ＢＶ1、ＢＶ3）およびｄｉｓ（ＢＶ2、ＢＶ3）が計算される。（１）最小のものは、２Ｎ×ＮまたはＮ×２Ｎブロックに結合され得るペアに対応する。たとえば、ｄｉｓ（ＢＶ0、ＢＶ1）が最小である場合、上の２つのＮ×Ｎブロックは２Ｎ×Ｎブロックに結合される。残りのものは、自動的に他の２Ｎ×Ｎブロックになる。（２）最大のものは、２Ｎ×ＮまたはＮ×２Ｎブロックに結合されないことがあるペアに対応する。たとえば、ｄｉｓ（ＢＶ0、ＢＶ1）が最大である場合、左の２つのＮ×Ｎブロックは２Ｎ×Ｎブロックに結合される。残りのものは、自動的に他の２Ｎ×Ｎブロックになる。（３）各結合された２Ｎ×Ｎブロックについて、２つのブロックベクトルは、処理され、単一のルーマブロックベクトルを導出する。（４）２つのブロックベクトルの距離は、２つのブロックベクトルＢＶaおよびＢＶbのための（ＢＶa［０］−ＢＶb［０］）の絶対値＋（ＢＶa［１］−ＢＶb［１］）の絶対値として単に定義され得る。代替的に、非負値を返す他の距離定義も適用し得る。
【０１３６】
[0141]本開示の別の技法によれば、ビデオデータが４：２：０または４：２：２フォーマットに従ってコーディングされたとき、ビデオデコーダ３０は、４つのＮ×Ｎ  ＰＵ／ＴＵの４つのブロックベクトルから１つの動きを導出し得る。一例では、ビデオデコーダ３０は、右下ブロック（すなわち右下ＰＵ）のためのブロックベクトルを導出し、ＣＵの４つのＰＵを予測するためにこのブロックベクトルを使用し得る。右下ＰＵのブロックベクトルを選択することによって、ブロックベクトルがＣＵの別のＰＵを指さないことが保証され得る。
【０１３７】
[0142]他の例では、ビデオデコーダ３０は、左下ブロック、右上ブロック、左上ブロックのブロックベクトルが、このＣＵのクロマブロックのためのブロックベクトルを生成するための唯一のブロックベクトルであるように選択し得る。
【０１３８】
[0143]本開示の別の技法によれば、ビデオデータが４：２：２フォーマットに従ってコーディングされたとき、１つのブロックベクトルは２つのブロックベクトルから導出され得る。そのような実装形態では、４つのＮ×Ｎ  ＰＵに分割される２Ｎ×２Ｎ  ＣＵの場合、ビデオデコーダ３０は、ＣＵの４つのＰＵの２つを予測するために同じブロックベクトルを使用し得る。一例では、ビデオデコーダ３０は、右上ＰＵと左上ＰＵの両方を予測するために右上ブロック（すなわち右上ＰＵ）のブロックベクトルを使用し得る。この例では、ビデオデコーダ３０は、左下ＰＵと右下ＰＵとを予測するために右下ブロック（すなわち右下ＰＵ）のブロックベクトルを使用し得る。別の例では、ビデオデコーダ３０は、ＣＵの上の２つのクロマブロックを予測するために左上ブロックのブロックベクトルを使用し、下の２つのクロマブロックを予測するために左下ブロックのブロックベクトルを使用し得る。
【０１３９】
[0144]ビデオデータが４：２：０または４：２：２フォーマットに従ってコーディングされたとき、および２Ｎ×２Ｎ  ＣＵが２Ｎ×ＮまたはＮ×２ＮイントラＢＣ  ＰＵ／ＴＵに分割されたとき、ビデオデコーダ３０は、異なるブロックベクトルを用いてＰＵ／ＴＵのクロマブロックを予測し得る。本開示の別の技法によれば、ビデオデコーダ３０は、２つのルーマブロックベクトルから１つのブロックベクトルを導出し、ＣＵ全体の両方のクロマブロックを予測するために１つのブロックベクトルを使用し得る。一例では、ビデオデコーダ３０は、ＣＵのクロマブロックのためのブロックベクトルとして、（Ｎ×２Ｎを用いてコーディングされたとき）右ブロックのブロックベクトルを選択するか、または（２Ｎ×Ｎを用いてコーディングされたとき）下ブロックのブロックベクトルを選択し得る。別の例では、ビデオデコーダ３０は、ＣＵのクロマブロックを予測するためのブロックベクトルとして、（Ｎ×２Ｎを用いてコーディングされたとき）左ブロックのブロックベクトルを選択するか、または（２Ｎ×Ｎを用いてコーディングされたとき）上ブロックのブロックベクトルを選択し得る。
【０１４０】
[0145]ビデオデコーダ３０がルーマＰＵからどのようにブロックベクトルを導出するかにかかわらず（導出されたブロックベクトルをｄＢＶとして示す）、最終クロマブロックベクトルを形成するために、ビデオデコーダ３０は、正当なブロックベクトルを生成するために、導出されたルーマブロックベクトルをクリッピングし得る。一例では、ビデオデコーダ３０は、クロマブロックベクトルが同じＰＵ／ＴＵ内のピクセルを指していない方法でクリッピングを実行し得る。別の例では、ビデオデコーダ３０は、クロマブロックベクトルが同じＣＵ内のピクセルを指していない方法でクリッピングを実行し得る。
【０１４１】
[0146]２Ｎ×２Ｎ  ＣＵが４つのＮ×Ｎ  ＰＵに分割される場合、ビデオデコーダ３０は水平クリッピング動作と垂直クリッピング動作とを実行し得る。ビデオデコーダ３０は、以下のように水平クリッピングを適用し得る。
【０１４２】
水平クリップ：ｍａｘ（−ｌｅｆｔＷ−（ＣＵｘ％ｃｔｂＷ），ｄＢＶ［０］）であり、ここにおいて、
１．ｌｅｆｔＷは、たとえば、６４のフィックス値であるか、あるいは、現在ＣＴＵの幅、またはビットストリーム中で、たとえば、ビデオパラメータセット、シーケンスパラメータセットおよびピクチャパラメータセットなど、高レベルシンタックス中で送信された他の値であり得る。
【０１４３】
２．ＣＵｘは現在ＣＵの左上ピクセルの水平座標である。
【０１４４】
３．ｃｔｂＷはＣＴＢの幅である。
【０１４５】
垂直クリップ：ｍａｘ（−ＣＵｙ％ｃｔｂＨ，ｄＢＶ［１］）であり、ここにおいて、
１．ＣＵｙは現在ＣＵの左上ピクセルの垂直座標である。
【０１４６】
２．ｃｔｂＨはＣＴＢの高さである。
【０１４７】
[0147]いくつかの例によれば、ビデオデコーダ３０は、たとえば、２Ｎ×２Ｎ  ＣＵがＮ×２Ｎ  ＰＵに分割されたとき、水平クリッピングのみを実行するか、または、２Ｎ×２Ｎ  ＣＵが２Ｎ×Ｎ  ＰＵに分割されたとき、垂直クリッピングのみを実行し得る。上記で説明したように、２つのＮ×Ｎブロックからの２つのブロックベクトルがＮ×２Ｎブロックのために結合されるべきである事例では、ビデオデコーダ３０は水平クリッピングのみを適用し得る。上記で説明したように、２つのＮ×Ｎブロックからの２つのブロックベクトルが２Ｎ×Ｎブロックのために結合されるべきである事例では、ビデオデコーダ３０は垂直クリッピングのみを適用し得る。
【０１４８】
[0148]いくつかの実装形態では、上記で説明した様々なプロセスは、特定のＣＵサイズのためにのみ実装され得る。たとえば、ビデオデコーダ３０は、８×８に等しいまたはより小さいＣＵサイズのための複数のクロマブロックを予測するために、単一のブロックベクトルのみを使用し得る。本明細書で説明する技法は、たとえば、３２×３２、１６×１６、または８×８など、あらかじめ定義されたサイズよりも大きくないＣＵサイズのためにのみ適用され得る。このサイズは、あらかじめ定義され得るか、または代替的に、ｓｐｓ／ｐｐｓ／スライスレベルにおいてシグナリングされ得る。
【０１４９】
[0149]図６は、本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの冗長性を低減または除去するために時間予測またはビュー間予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースの圧縮モードのいずれかを指すことがある。単方向予測（Ｐモード）または双予測（Ｂモード）などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを含み得る。ビデオエンコーダ２０はまた、本明細書で説明するように、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のためのモード、たとえば、イントラＢＣモードまたはイントラＭＣモードを利用するように構成され得る。
【０１５０】
[0150]図６の例では、ビデオエンコーダ２０は、ビデオデータメモリ３３４と、区分ユニット３３５と、予測処理ユニット３４１と、対象領域メモリ３６４と、フィルタ処理ユニット３６６と、参照ピクチャメモリ３６８と、加算器３５０と、変換処理ユニット３５２と、量子化処理ユニット３５４と、エントロピー符号化ユニット３５６とを含む。予測処理ユニット３４１は、動き推定ユニット３４２と、動き補償ユニット３４４と、イントラ予測処理ユニット３４６と、イントラブロックコピー（イントラＢＣ）ユニット３４８とを含む。ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化処理ユニット３５８と、逆変換処理ユニット３６０と、加算器３６２とを含む。
【０１５１】
[0151]様々な例では、ビデオエンコーダ２０のユニットは、本開示の技法を実行する役割を担い得る。また、いくつかの例では、本開示の技法は、ビデオエンコーダ２０のユニットのうちの１つまたは複数の中で分割され得る。たとえば、イントラＢＣユニット３４８は、本開示の技法を、単独で、または、動き推定ユニット３４２、動き補償ユニット３４４、イントラ予測処理ユニット３４６、対象領域メモリ３６４、およびエントロピー符号化ユニット３５６など、ビデオエンコーダの他のユニットと組み合わせて実行し得る。
【０１５２】
[0152]ビデオデータメモリ３３４は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオデータメモリ３３４に記憶されるビデオデータは、たとえば、ビデオソース１８から取得され得る。対象領域メモリ３６４は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ブロックメモリであり得る。ビデオデータメモリ３３４および対象領域メモリ３６４は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ３３４および対象領域メモリ３６４は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ３３４は、ビデオエンコーダ２０の他の構成要素とともにオンチップであるか、またはそのような構成要素に対してオフチップであり得る。
【０１５３】
[0153]区分ユニット３３５は、ビデオデータメモリ３３４からのデータをビデオブロックに区分する。この区分は、たとえば、ＬＣＵおよびＣＵの４分木構造に応じて、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分をも含み得る。ビデオエンコーダ２０は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに（および、場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。
【０１５４】
[0154]予測処理ユニット３４１は、誤差結果（たとえば、コーディングレートおよびひずみレベル）に基づいて現在ビデオブロックのために、複数のイントラコーディングモードのうちの１つ、複数のインターコーディングモードのうちの１つ、または本開示で説明する技法によるイントラＢＣモードなど、複数の可能なコーディングモードのうちの１つを選択し得る。予測処理ユニット３４１は、得られた予測ブロックを、残差ブロックデータを生成するために加算器２５０に与え、たとえば、参照ピクチャとして他のビデオブロックの予測において使用するための現在ブロックを再構成するために加算器２６２に与え得る。
【０１５５】
[0155]予測処理ユニット３４１内のイントラ予測処理ユニット３４６は、空間圧縮を行うために、コーディングされるべき現在ブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して現在ビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット３４１内の動き推定ユニット３４２および動き補償ユニット３４４は、たとえば、時間圧縮を行うために、１つまたは複数の参照ピクチャ中の１つまたは複数の予測ブロックに対して現在ビデオブロックのインター予測コーディングを実行する。
【０１５６】
[0156]動き推定ユニット３４２は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを決定するように構成され得る。動き推定ユニット３４２および動き補償ユニット３４４は、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット３４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。同様に、本開示の技法によるイントラＢＣに使用される２次元ベクトルは、同じフレームまたはピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示す。イントラＢＣユニット３４８は、インター予測のための動き推定ユニット３４２による動きベクトルの決定と同様の様式でイントラＢＣコーディングのための２次元ベクトル、たとえば、ブロックベクトルまたは動きベクトルを決定し得るか、または２次元ベクトルを決定するために動き推定ユニット３４２を利用し得る。
【０１５７】
[0157]たとえば、インター予測またはイントラＢＣ予測のために動き推定ユニット３４２および／またはイントラＢＣユニットによって識別される予測ブロックは、絶対差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのＰＵにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、対象領域メモリ３６４に記憶された現在ピクチャの対象とする領域または参照ピクチャメモリ３６８に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット３４２および／またはイントラＢＣユニット３４８は、フルピクセル位置と分数ピクセル位置とに対して予測ブロックの探索を実行し、分数ピクセル精度をもつベクトルを出力し得る。
【０１５８】
[0158]動き推定ユニット３４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵのための動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０またはＲｅｆＰｉｃＬｉｓｔ０）または第２の参照ピクチャリスト（リスト１またはＲｅｆＰｉｃＬｉｓｔ１）から選択され得、それらの参照ピクチャリストの各々は、参照ピクチャメモリ３６８に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット３４２は、計算された動きベクトルをエントロピー符号化ユニット３５６と動き補償ユニット３４４とに送る。
【０１５９】
[0159]動き補償ユニット３４４によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを伴い得る。現在ビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット３４４は、動きベクトルが参照ピクチャリストのうちの１つにおいて指す予測ブロックの位置を特定し得る。
【０１６０】
[0160]いくつかの例では、イントラＢＣユニット３４８は、動き推定ユニット３４２および動き補償ユニット３４４に関して上記で説明した様式と同様の様式で、２次元ベクトルを生成し、予測ブロックをフェッチし得るが、予測ブロックは現在ブロックと同じピクチャまたはフレーム中にある。他の例では、イントラＢＣユニット３４８は、本明細書で説明する技法によるイントラＢＣ予測のためのそのような機能を実行するために、動き推定ユニット３４２および動き補償ユニット３４４を全体的または部分的に使用し得る。いずれの場合も、イントラＢＣでは、予測ブロックは、絶対差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、または他の差分メトリックによって決定され得る、ピクセル差分に関して、コーディングされるべきブロックとぴったり一致することがわかるブロックであり、ブロックの識別は、サブ整数ピクセル位置の値の計算を含み得る。
【０１６１】
[0161]予測ビデオブロックがイントラＢＣ予測に従って同じピクチャからであるのか、インター予測に従って異なるピクチャからであるのかにかかわらず、ビデオエンコーダ２０は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成し得る。ピクセル差分値は、ブロックの残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器２５０は、この減算演算を実行する１つまたは複数の構成要素を表す。イントラＢＣユニット３４８および／または動き補償ユニット３４４はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するための、ビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。シンタックス要素は、たとえば、予測ブロックを識別するために使用されるベクトル、予測モードを示す任意のフラグ、または本開示の技法に関して説明する任意の他のシンタックスを定義する、シンタックス要素を含み得る。
【０１６２】
[0162]イントラ予測処理ユニット３４６は、上記で説明したように、動き推定ユニット３４２と動き補償ユニット３４４とによって実行されるインター予測、またはイントラＢＣユニット３４８によって実行されるイントラＢＣ予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測処理ユニット３４６は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット３４６は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ビデオブロックを符号化し得、イントラ予測処理ユニット３４６（または、いくつかの例では、予測処理ユニット３４１）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。たとえば、イントラ予測処理ユニット３４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測処理ユニット３４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのひずみおよびレートから比を計算し得る。
【０１６３】
[0163]いずれの場合も、ブロックのためのイントラ予測モードを選択した後に、イントラ予測処理ユニット３４６は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット３５６に与え得る。エントロピー符号化ユニット３５６は、本開示の技法に従って、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを送信ビットストリーム中に含め得る。
【０１６４】
[0164]予測処理ユニット３４１が、インター予測、イントラ予測、またはイントラＢＣ予測を介して現在ビデオブロックの予測ブロックを生成した後に、ビデオエンコーダ２０は、たとえば加算器３５０を介して、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、１つまたは複数のＴＵ中に含まれ、変換処理ユニット３５２に適用され得る。変換処理ユニット３５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット３５２は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。
【０１６５】
[0165]変換処理ユニット３５２は、得られた変換係数を量子化処理ユニット３５４に送り得る。量子化処理ユニット３５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化処理ユニット３５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット３５６が走査を実行し得る。
【０１６６】
[0166]量子化の後に、エントロピー符号化ユニット３５６は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット３５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングあるいは別のエントロピー符号化方法または技法を実行し得る。エントロピー符号化ユニット３５６は、イントラＢＣモードによる予測のために、ベクトル成分、フラグ、および他のシンタックス要素を含む、シンタックス要素の２値化および符号化のための本明細書で説明する技法のいずれかを実行し得る。エントロピー符号化ユニット３５６によるエントロピー符号化の後に、符号化ビデオビットストリームは、ビデオデコーダ３０に送信されるか、あるいは後で送信するかまたはビデオデコーダ３０よって取り出すためにアーカイブされ得る。
【０１６７】
[0167]逆量子化処理ユニット３５８および逆変換処理ユニット３６０は、他のビデオブロックの予測のために参照ブロックとして後で使用するためにピクセル領域において残差ブロックを再構成するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット３４４および／またはイントラＢＣユニット３４８は、残差ブロックを参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット３４４および／またはイントラＢＣユニット３４８はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構成された残差ブロックに１つまたは複数の補間フィルタを適用し得る。
【０１６８】
[0168]加算器３６２は、再構成されたビデオブロックを生成するために、再構成された残差ブロックを、動き補償ユニット３４４および／またはイントラＢＣユニット３４８によって生成された動き補償予測ブロックに加算する。対象領域メモリ３６４は、本明細書で説明するように、ビデオエンコーダ２０、たとえば、イントラＢＣユニット３４８によって、現在ビデオブロックのイントラＢＣのための対象とする領域の定義に従って、再構成されたビデオブロックを記憶する。対象領域メモリ３６４は、フィルタ処理ユニット３６６によってインループフィルタ処理されていない再構成されたビデオブロックを記憶し得る。加算器３６２は、再構成されたビデオブロックを対象領域メモリ３６４と並列にフィルタ処理ユニット３６６に与え得るか、または対象領域メモリ３６４は、イントラＢＣのための対象とする領域がもはや必要でないとき、再構成されたビデオブロックをフィルタ処理ユニット３６６に解放し得る。いずれの場合も、イントラＢＣユニット３４８は、現在ビデオブロックを予測するために、対象領域メモリ３６４中の再構成されたビデオブロックを現在ビデオブロックと同じピクチャ内の予測ビデオブロックについて探索し得る。
【０１６９】
[0169]フィルタ処理ユニット３６６は、再構成されたビデオブロックに対してインループフィルタ処理を実行し得る。インループフィルタ処理は、再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するためのデブロックフィルタ処理を含み得る。インループフィルタ処理は、再構成されたビデオを改善するためにＳＡＯフィルタ処理をも含み得る。そのうちのいくつかがインループフィルタ処理され得る、再構成されたブロックは、参照ピクチャとして参照ピクチャメモリ３６８に記憶され得る。参照ピクチャは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット３４２および動き補償ユニット３４４によって予測ブロックとして使用され得る再構成されたブロックを含み得る。
【０１７０】
[0170]このようにして、ビデオエンコーダ２０は、たとえば、イントラＢＣモードに従って、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のための本開示の例示的な技法を実装するように構成され得る。たとえば、ビデオエンコーダ２０は、同じピクチャ内のビデオデータの予測ブロックからのビデオデータのブロックのイントラ予測のためのモードを含むビデオデータを符号化する方法を実行するように構成されたビデオエンコーダの一例であり得、本方法は、ビデオデータの現在ブロックと同じピクチャ内のビデオデータの前に符号化されたブロックのセットからビデオデータの現在ブロックのためのビデオデータの予測ブロックを選択することを備える。本方法は、２次元ベクトルを決定することをさらに備え、ここにおいて、２次元ベクトルが水平変位成分と垂直変位成分とを有し、ここにおいて、水平変位成分が、ビデオデータの予測ブロックとビデオデータの現在ブロックとの間の水平変位を表し、垂直変位成分が、ビデオデータの予測ブロックとビデオデータの現在ブロックとの間の垂直変位を表す。本方法は、ビデオデータの現在ブロックとビデオデータの予測ブロックとに基づいて残差ブロックを決定することと、符号化ビデオビットストリーム中で、２次元ベクトルの水平変位成分および垂直変位成分ならびに残差ブロックを定義する１つまたは複数のシンタックス要素を符号化することとをさらに備える。
【０１７１】
[0171]ビデオエンコーダ２０はまた、符号化ビデオビットストリームを記憶するように構成されたメモリと、１つまたは複数のプロセッサとを備えるビデオエンコーダの一例であり得る。１つまたは複数のプロセッサは、ビデオデータの現在ブロックと同じピクチャ内のビデオデータの前に符号化されたブロックのセットからビデオデータの現在ブロックのためのビデオデータの予測ブロックを選択するように構成される。１つまたは複数のプロセッサは、２次元ベクトルを決定するようにさらに構成され、ここにおいて、２次元ベクトルが水平変位成分と垂直変位成分とを有し、ここにおいて、水平変位成分が、ビデオデータの予測ブロックとビデオデータの現在ブロックとの間の水平変位を表し、垂直変位成分が、ビデオデータの予測ブロックとビデオデータの現在ブロックとの間の垂直変位を表す。１つまたは複数のプロセッサは、ビデオデータの現在ブロックとビデオデータの予測ブロックとに基づいて残差ブロックを決定することと、符号化ビデオビットストリーム中で、２次元ベクトルの水平変位成分および垂直変位成分ならびに残差ブロックを定義する１つまたは複数のシンタックス要素を符号化することとを行うようにさらに構成される。
【０１７２】
[0172]図７は、本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図である。図７の例では、ビデオデコーダ３０は、ビデオデータメモリ３７８と、エントロピー復号ユニット３８０と、予測処理ユニット３８１と、逆量子化処理ユニット３８６と、逆変換処理ユニット３８８と、加算器３９０と、対象領域メモリ３９２と、フィルタ処理ユニット３９４と、参照ピクチャメモリ３９６とを含む。予測処理ユニット３８１は、動き補償ユニット３８２と、イントラ予測処理ユニット３８４と、イントラブロックコピー（イントラＢＣ）ユニット３８５とを含む。ビデオデコーダ３０は、いくつかの例では、図６からのビデオエンコーダ２０に関して説明した符号化パスとは概して逆の復号パスを実行し得る。
【０１７３】
[0173]様々な例では、ビデオデコーダ３０のユニットは、本開示の技法を実行する役割を担い得る。また、いくつかの例では、本開示の技術は、ビデオデコーダ３０のユニットのうちの１つまたは複数の中で分割され得る。たとえば、イントラＢＣユニット３８５は、本開示の技法を、単独で、または、動き補償ユニット３８２、イントラ予測処理ユニット３８４、対象領域メモリ３９２、およびエントロピー復号ユニット３８０など、ビデオデコーダ３０の他のユニットと組み合わせて実行し得る。
【０１７４】
[0174]復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダから、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデータメモリ３７８は、ビデオデコーダ３０の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ３７８内に記憶されたビデオデータは、たとえば、コンピュータ可読媒体１６から、たとえば、カメラなどのローカルビデオソースから、ビデオデータのワイヤードまたはワイヤレスのネットワーク通信を介して、あるいは物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ３７８は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ（ＣＰＢ）を形成し得る。対象領域メモリ３９２は、たとえば、イントラブロックコーディングモードでビデオデコーダ３０によってビデオデータを複号する際に使用するための、参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ３７８および対象領域メモリ３９２は、ＳＤＲＡＭを含むＤＲＡＭ、ＭＲＡＭ、ＲＲＡＭ、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ３７８および対象領域メモリ３９２は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ３７８は、ビデオデコーダ３０の他の構成要素とともにオンチップであるか、またはそのような構成要素に対してオフチップであり得る。
【０１７５】
[0175]ビデオデコーダ３０のエントロピー復号ユニット３８０は、量子化係数と、インター予測のための動きベクトルと、イントラＢＣ予測のための２次元ベクトルと、本明細書で説明する他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット３８０は、イントラＢＣモードによる予測のために、ベクトル成分、フラグ、および他のシンタックス要素を含む、シンタックス要素の２値化および符号化のための本明細書で説明する技法のいずれかの逆を実行し得る。エントロピー復号ユニット３８０は、予測処理ユニット３８１にベクトルおよび他のシンタックス要素をフォワーディングする。ビデオデコーダ３０は、シーケンスレベル、ピクチャレベル、ビデオスライスレベルおよび／またはビデオブロックレベルにおいてシンタックス要素を受信し得る。
【０１７６】
[0176]ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされたとき、予測処理ユニット３８１のイントラ予測処理ユニット３８４は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（すなわち、ＢまたはＰ）スライスとしてコーディングされたとき、予測処理ユニット３８１の動き補償ユニット３８２は、エントロピー復号ユニット２８０から受信された動きベクトルおよび他のシンタックス要素に基づいて現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ３９６に記憶された参照ピクチャに基づいて、デフォルト構成技法または任意の他の技法を使用して、参照フレームリスト、すなわち、ＲｅｆＰｉｃＬｉｓｔ０とＲｅｆＰｉｃＬｉｓｔ１とを構成し得る。ビデオブロックが、本明細書で説明するイントラＢＣモードに従ってコーディングされたとき、予測処理ユニット３８１のイントラＢＣユニット３８５は、エントロピー復号ユニット３８０から受信された２次元ベクトルおよび他のシンタックス要素に基づいて、現在ビデオブロックのための予測ブロックを生成する。予測ブロックは、ビデオエンコーダ２０によって定義され、対象領域メモリ３９２から取り出される現在ビデオブロックと同じピクチャ内の対象とする領域内にあり得る。
【０１７７】
[0177]動き補償ユニット３８２およびイントラＢＣユニット３８５は、ベクトルおよび他のシンタックス要素をパースすることによって現在ビデオスライスのビデオブロックのための予測情報を決定し、復号されている現在ビデオブロックのための予測ブロックを生成するために予測情報を使用する。たとえば、動き補償ユニット２８２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラ予測またはインター予測）と、インター予測スライスタイプ（たとえば、ＢスライスまたはＰスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつかを使用する。同様に、イントラＢＣユニット３８５は、現在ビデオブロックがイントラＢＣモードを使用して予測されたこと、ピクチャのどのビデオブロックが対象とする領域内にあり、対象領域メモリに記憶されるべきであるかを示す対象領域メモリ３９２のための構成情報、スライスの各イントラＢＣ予測ビデオブロックのための２次元ベクトル、スライスの各イントラＢＣ予測ビデオブロックのためのイントラＢＣ予測ステータス、および現在ビデオスライス中のビデオブロックを復号するための他の情報を決定するために、受信されたシンタックス要素のうちのいくつか、たとえば、フラグを使用し得る。
【０１７８】
[0178]動き補償ユニット３８２およびイントラＢＣユニット３８５はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット３８２およびイントラＢＣユニット３８５は、予測ブロックのサブ整数ピクセルのための補間値を計算するために、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット３８２およびイントラＢＣユニット３８５は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、予測ブロックを生成するために補間フィルタを使用し得る。
【０１７９】
[0179]逆量子化処理ユニット３８６は、ビットストリーム中で与えられ、エントロピー復号ユニット３８０によって復号された、量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（dequantize）する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中の各ビデオブロックについてビデオエンコーダ２０によって計算される量子化パラメータの使用を含み得る。逆変換処理ユニット３８８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
【０１８０】
[0180]動き補償ユニット３８２またはイントラＢＣユニット３８５が、ベクトルおよび他のシンタックス要素に基づいて現在ビデオブロックのための予測ブロックを生成した後に、ビデオデコーダ３０は、逆変換処理ユニット３８８からの残差ブロックを動き補償ユニット３８２およびイントラＢＣユニット３８５によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器３９０は、再構成されたビデオブロックを生成するためにこの加算演算を実行する１つまたは複数の構成要素を表す。
【０１８１】
[0181]対象領域メモリ３９２は、本明細書で説明するように、ビデオエンコーダ２０によって現在ビデオブロックのイントラＢＣのための対象とする領域の定義に従って、再構成されたビデオブロックを記憶する。対象領域メモリ３９２は、フィルタ処理ユニット３９４によってインループフィルタ処理されていない再構成されたビデオブロックを記憶し得る。加算器３９０は、再構成されたビデオブロックを対象領域メモリ３９２と並列にフィルタ処理ユニット３９４に与え得るか、または対象領域メモリ３９２は、イントラＢＣのための対象とする領域がもはや必要でないとき、再構成されたビデオブロックをフィルタ処理ユニット３９４に解放し得る。いずれの場合も、イントラＢＣユニット３８５は、対象領域メモリ３９２から現在ビデオブロックのための予測ビデオブロックを取り出す。
【０１８２】
[0182]フィルタ処理ユニット３９４は、再構成されたビデオブロックに対してインループフィルタ処理を実行し得る。インループフィルタ処理は、再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するためのデブロックフィルタ処理を含み得る。インループフィルタ処理は、再構成されたビデオを改善するためにＳＡＯフィルタ処理をも含み得る。そのうちのいくつかがインループフィルタ処理され得る、再構成されたブロックは、参照ピクチャとして参照ピクチャメモリ３６８に記憶され得る。参照ピクチャは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き補償ユニット３８２によって予測ブロックとして使用され得る再構成されたブロックを含み得る。参照ピクチャメモリ３９６はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上での後の表示のための、復号ビデオを記憶する。
【０１８３】
[0183]このようにして、ビデオデコーダ３０は、同じピクチャ内のビデオデータの予測ブロックに基づいてビデオデータの現在ブロックをイントラ予測するための本開示の例示的な技法を実装するように構成され得る。たとえば、ビデオデコーダ３０は、同じピクチャ内のビデオデータの予測ブロックからビデオデータのブロックのイントラ予測のためのモードを含むビデオデータを復号する方法を実行するように構成されたビデオデコーダの一例であり得、本方法は、符号化ビデオビットストリーム中で、２次元ベクトルの水平変位成分および垂直変位成分ならびにビデオデータの現在ブロックのための残差ブロックを定義する１つまたは複数のシンタックス要素を受信することと、１つまたは複数のシンタックス要素を復号することとを備える。本方法は、２次元ベクトルの水平変位成分および垂直変位成分を定義する復号されたシンタックス要素に基づいてビデオデータの現在ブロックのためのビデオデータの予測ブロックを決定することと、ここにおいて、ビデオデータの予測ブロックが、ビデオデータの現在ブロックと同じピクチャ内のビデオデータの再構成されたブロックであり、ビデオデータの予測ブロックと残差ブロックとに基づいてビデオデータの現在ブロックを再構成することとをさらに備える。
【０１８４】
[0184]ビデオデコーダ３０はまた、ビデオデータを符号化する符号化ビデオビットストリームを記憶するように構成されたメモリと、１つまたは複数のプロセッサとを備えるビデオデコーダの一例であり得る。ビデオデコーダの１つまたは複数のプロセッサは、１つまたは複数のシンタックス要素を復号することと、２次元ベクトルの水平変位成分および垂直変位成分を定義する復号されたシンタックス要素に基づいてビデオデータの現在ブロックのためのビデオデータの予測ブロックを決定することと、ここにおいて、ビデオデータの予測ブロックが、ビデオデータの現在ブロックと同じピクチャ内のビデオデータの再構成されたブロックであり、ビデオデータの予測ブロックと残差ブロックとに基づいてビデオデータの現在ブロックを再構成することとを行うように構成され得る。
【０１８５】
[0185]図８は、本開示で説明する技法による、ビデオデータを符号化するための例示的な方法を示すフローチャートである。図８の技法について、ビデオエンコーダ２０など、ビデオエンコーダに関して説明する。ビデオエンコーダ２０は、コーディングユニットに関連する複数のベクトルから、ピクチャのＣＵの第１のクロマブロックのためのベクトルを決定する（４０２）。ビデオエンコーダ２０は、ベクトルを使用して第１のクロマ参照ブロックの位置を特定する（４０４）。第１のクロマ参照ブロックはＣＵと同じピクチャ中にあり得る。ビデオエンコーダ２０は、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測する（４０６）。ビデオエンコーダ２０は、ベクトルを使用して第２のクロマ参照ブロックの位置を特定する（４０８）。第２のクロマ参照ブロックはＣＵと同じピクチャ中にあり得る。ビデオエンコーダ２０は、第２のクロマ参照ブロックに基づいてコーディングユニットの第２のクロマブロックを予測する（４１０）。
【０１８６】
[0186]ビデオエンコーダ２０は、符号化ビデオデータ中に含めるために、ピクチャのＣＵがイントラブロックコピーモードを使用してコーディングされているという指示と、ＣＵの各ルーマブロックのためのベクトルの指示とを生成する（４１２）。上記で説明したように、ビデオエンコーダ２０は、別個のブロックベクトルを使用してルーマ成分の各々を予測するが、ルーマ成分を予測するために使用される別個のブロックベクトルから決定される共通ブロックベクトルを使用してＣＵのクロマ成分を予測し得る。したがって、ビデオエンコーダ２０は、符号化ビデオデータ中に、ＣＵの各ルーマ成分のための別個のブロックベクトル指示を含め得る。
【０１８７】
[0187]図９は、本開示で説明する技法による、ビデオデータを復号するための例示的な方法を示すフローチャートである。図９の技法について、ビデオデコーダ３０など、ビデオデコーダに関して説明する。ビデオデコーダ３０は、ビデオデータのピクチャのＣＵがイントラブロックコピーモードを使用してコーディングされていると決定する（４２０）。ビデオデコーダ３０は、コーディングユニットに関連する複数のベクトルから、ＣＵの第１のクロマブロックのためのベクトルを決定する（４２２）。ビデオデコーダ３０は、ベクトルを使用して第１のクロマ参照ブロックの位置を特定する（４２４）。第１のクロマ参照ブロックはＣＵと同じピクチャ中にある。ビデオデコーダ３０は、第１のクロマ参照ブロックに基づいて第１のクロマブロックを予測する（４２６）。ビデオデコーダ３０は、ベクトルを使用して第２のクロマ参照ブロックの位置を特定する（４２８）。第２のクロマ参照ブロックはＣＵと同じピクチャ中にある。ビデオデコーダ３０は、第２のクロマ参照ブロックに基づいてＣＵの第２のクロマブロックを予測する（４３０）。
【０１８８】
[0188]ＣＵは、たとえば、２つまたはそれ以上のＰＵを含み得、第１のクロマブロックは第１のＰＵに対応し、第２のクロマブロックは第２のＰＵに対応する。ビデオデコーダ３０は、第１のＰＵのためのベクトルを取得することによってＣＵの第２のクロマブロックのためのベクトルを決定し得る。
【０１８９】
[0189]一例では、ＣＵは２つまたはそれ以上のＰＵを含み得、各ＰＵは、関連するベクトルを有する。ビデオデコーダ３０は、第１の予測ユニットに関連するベクトルを使用して第１のルーマ参照ブロックの位置を特定し得る。第１のルーマ参照ブロックは第１のＰＵに対応し得る。ビデオデコーダ３０は、第２のＰＵに関連するベクトルを使用して第２のルーマ参照ブロックの位置を特定し得る。第２の参照ルーマブロックは第２のＰＵに対応し得る。ビデオデコーダ３０は、第１のＰＵに関連するベクトルを使用して第１のクロマ参照ブロックの位置を特定し、第１のＰＵに関連するベクトルを使用して第２のクロマ参照ブロックの位置を特定し得る。
【０１９０】
[0190]一例では、ＣＵのためのクロマサンプリングフォーマットが４：２：０であるとき、第１のクロマブロックはＣＵの右下ブロックであり得る。第２のクロマブロックはＣＵの右上ブロックであり得、ビデオデコーダ３０は、ベクトルを使用して第３の参照ブロックの位置を特定し得る。第３の参照ブロックはピクチャ中にあり得る。ビデオデコーダ３０は、第１の参照ブロックに基づいて第３のクロマブロックを予測し得る。第３のクロマブロックはＣＵの左上ブロックであり得る。ビデオデコーダ３０は、ベクトルを使用して第４の参照ブロックの位置を特定し、第２の参照ブロックに基づいてＣＵの第４のクロマブロックを予測し得る。第４の参照ブロックはピクチャ中にあり得、第４のクロマブロックはＣＵの左下ブロックであり得る。
【０１９１】
[0191]一例では、ＣＵのためのクロマサンプリングフォーマットが４：２：２であり得る。第１のクロマブロックは右上ブロックであり得、第２のクロマブロックはＣＵの左上ブロックであり得る。ビデオデコーダ３０は、ＣＵの第３のクロマブロックのための第２のベクトルを決定し、第２のベクトルを使用して第３の参照ブロックの位置を特定し得る。第３の参照ブロックはピクチャ中にあり得る。ビデオデコーダ３０は、第３のクロマブロックのための予測子として第３の参照ブロックを使用し得る。ビデオデコーダ３０は、ベクトルを使用して第４の参照ブロックの位置を特定し得る。第４の参照ブロックはピクチャ中にあり得る。ビデオデコーダ３０は、ＣＵの第４のクロマブロックのための予測子として第４の参照ブロックを使用し得る。
【０１９２】
[0192]上記例に応じて、本明細書で説明した技法のいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行され得、全体的に追加、マージ、または除外され得る（たとえば、すべての説明した行為またはイベントが本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して同時に実行され得る。
【０１９３】
[0193]１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【０１９４】
[0194]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【０１９５】
[0195]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明した技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
【０１９６】
[0196]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
【０１９７】
[0197]様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
【図１】
2017508345.tif 000003
【図２】
2017508345.tif 000004
【図３】
2017508345.tif 000005
【図４】
2017508345.tif 000006
【図５Ａ】
2017508345.tif 000007
【図５Ｂ】
2017508345.tif 000008
【図６】
2017508345.tif 000009
【図７】
2017508345.tif 000010
【図８】
2017508345.tif 000011
【図９】
2017508345.tif 000012
【国際調査報告】
2017508345.tif 000013
2017508345.tif 000014
2017508345.tif 000015