[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、2014年10月9日に出願された米国仮特許出願62/062,122号の利益を主張する。
[0030]最近開発された高効率ビデオコーディング(HEVC)規格を含む様々なビデオコーディング規格は、ビデオブロックのための予測コーディングモードを含み、ここで、現在コーディングされているブロックは、ビデオデータのすでにコーディングされたブロックに基づいて予測される。イントラ予測モードでは、現在ブロックは、現在ブロックと同じピクチャ中の1つまたは複数の前にコーディングされた隣接するブロックに基づいて予測され、インター予測モードでは、現在ブロックは、異なるピクチャ中のすでにコーディングされたブロックに基づいて予測される。インター予測モードでは、予測ブロックとして使用するために前にコーディングされたフレームのブロックを決定するプロセスは動き推定と呼ばれることがあり、動き推定は概してビデオエンコーダによって実行され、予測ブロックを識別し、取り出すプロセスは動き補償と呼ばれることがあり、動き補償はビデオエンコーダとビデオデコーダの両方によって実行される。
[0031]ビデオエンコーダは、一般に、複数のコーディングシナリオを使用してビデオをコーディングすることと、望ましいレートひずみトレードオフを生じるコーディングシナリオを識別することとによって、ビデオデータのシーケンスをどのようにコーディングすべきかを決定する。特定のビデオブロックのためのイントラ予測コーディングシナリオをテストするとき、ビデオエンコーダは、一般に、ピクセルの隣接する行(すなわち、コーディングされているブロックのすぐ上のピクセルの行)をテストし、ピクセルの隣接する列(すなわち、コーディングされているブロックのすぐ左側のピクセルの列)をテストする。対照的に、インター予測シナリオをテストするとき、ビデオエンコーダは、一般に、はるかに大きい探索エリア中の候補予測ブロックを識別し、ここで、探索エリアは、ビデオデータの前にコーディングされたフレーム中のビデオブロックに対応する。
[0032]しかしながら、テキスト、シンボル、または繰返しパターンを含むビデオ画像など、ビデオ画像のいくつかのタイプの場合、イントラ動き補償(IMC)モードと呼ばれることもあるイントラブロックコピー(IBC)モードを使用することによって、コーディング利得がイントラ予測およびインター予測に対して達成され得ることが発見されている。様々なコーディング規格の発展において、IMCモードという用語が当初使用されたが、後にIBCモードに変更された。IBCモードでは、ビデオエンコーダは、イントラ予測モードの場合のように、コーディングされているブロックと同じフレームまたはピクチャ中の予測ブロックを探索するが、ビデオエンコーダは、ピクセルの隣接する行および列だけでなく、より広い探索エリアを探索する。
[0033]IBCモードでは、ビデオエンコーダは、予測されているブロックと同じフレームまたはピクチャ内の予測ブロックを識別するために、動きベクトルまたはブロックベクトルとも呼ばれることがある、オフセットベクトルを決定し得る。オフセットベクトルは、たとえば、x成分とy成分とを含み、ここで、x成分は、予測されているビデオブロックと予測ブロックとの間の水平変位を識別し、y成分は、予測されているビデオブロックと予測ブロックとの間の垂直変位を識別する。ビデオエンコーダは、ビデオデコーダが、符号化ビットストリームを復号するとき、ビデオエンコーダによって選択された同じ予測ブロックを識別することができるように、符号化ビットストリーム中で、決定されたオフセットベクトルをシグナリングする。
[0034]HEVCを含む様々なビデオコーディング規格は、同じピクチャ内の異なるブロックが同時に復号され得るように、タイルおよび波面並列処理など、並列処理機構をもサポートする。タイルは、ビデオデコーダが複数のタイルを並列に復号することができるような、複数の単独で復号可能な(パーシングおよび再構成を含む)領域へのピクチャの(コード化ツリーブロック(CTB)グラニュラリティを用いた)矩形区分を提供する。タイルとは異なり、波面は単独で復号可能でないが、ビデオデコーダは、様々な波面の復号が開始する時間をスタッガすることによって、複数の波面を並列に復号することが依然として可能であり得る。たとえば、ビデオデコーダが第1の波面の下の第2の波面を復号し始める前に第1の波面の2つのブロックを復号する場合、ビデオデコーダは、第2の波面を復号するために必要な第1の波面のいかなる情報もすでに復号されており、したがって第2の波面を復号する際に使用するために利用可能であることを保証することができる。
[0035]本開示は、IBCモードが有効化されるときの並列処理を潜在的に向上させるための技法を紹介する。より詳細には、本開示は、デコーダが、波面並列処理と呼ばれることがある、非ラスタ走査順序で並列に複数のCTUを処理することができるような、IBCブロックベクトル(BV)に対する制限を紹介する。本開示の技法は、限定はしないが、4:4:4、4:2:2、4:2:0、4:0:0など、場合によっては(possibly)高ビット深度(8ビット超)の異なるクロマサンプリングフォーマットのサポートを含む、スクリーンコンテンツコーディングを対象とする。
[0036]図1は、IBCモードにおいてブロックをコーディングするための技法と並列処理のための技法とを含む、本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示されているように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを生成するソースデバイス12を含む。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14はワイヤレス通信のために装備され得る。
[0037]宛先デバイス14は、リンク16を介して復号されるべき符号化ビデオデータを受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、リンク16は、ソースデバイス12が、符号化ビデオデータをリアルタイムで宛先デバイス14に直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルあるいは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0038]代替的に、符号化データは出力インターフェース22からストレージデバイス17に出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイス17からアクセスされ得る。ストレージデバイス17は、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス17は、ソースデバイス12によって生成された符号化ビデオを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイス17から、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することと、その符号化ビデオデータを宛先デバイス14に送信することとが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi-Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、またはその両方の組合せを含み得る。ストレージデバイス17からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。
[0039]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0040]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。場合によっては、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえばビデオカメラ、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、あるいはそのようなソースの組合せを含み得る。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。
[0041]キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化ビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に直接送信され得る。符号化ビデオデータは、さらに(または代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのためにストレージデバイス17上に記憶され得る。
[0042]宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。場合によっては、入力インターフェース28は、受信機および/またはモデムを含み得る。宛先デバイス14の入力インターフェース28は、リンク16を介して符号化ビデオデータを受信する。リンク16を介して通信され、またはストレージデバイス17上に与えられた符号化ビデオデータは、ビデオデータを復号する際に、ビデオデコーダ30など、ビデオデコーダが使用するためのビデオエンコーダ20によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体上に記憶されるか、またはファイルサーバ記憶される符号化ビデオデータとともに含まれ得る。
[0043]ディスプレイデバイス32は、宛先デバイス14と一体化されるかまたはその外部にあり得る。いくつかの例では、宛先デバイス14は、一体型ディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス14はディスプレイデバイスであり得る。概して、ディスプレイデバイス32は、復号ビデオデータをユーザに表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
[0044]ビデオエンコーダ20およびビデオデコーダ30は、HEVCなどのビデオ圧縮規格に従って動作し得、HEVCテストモデル(HM)に準拠し得る。「HEVCワーキングドラフト10」または「HEVC WD10」と呼ばれる、HEVC規格のワーキングドラフトは、Brossら、「Editors’ proposed corrections to HEVC version 1」、ITU-T SG16 WP3とISO/IEC JTC1/SC29/WG11とのジョイントコラボレーティブチームオンビデオコーディング(JCT-VC)、第13回会議、仁川、韓国、2013年4月に記載されている。別のHEVCドラフト仕様は、http://phenix.int-evry.fr/jct/doc_end_user/documents/15_Geneva/wg11/JCTVC-O1003-v2.zipから入手可能である。本開示で説明する技法はまた、現在開発中であるHEVC規格の拡張に従って動作し得る。
[0045]代替または追加として、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4,Part10,アドバンストビデオコーディング(AVC)と呼ばれるITU-T H.264規格など、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例としては、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびそれのスケーラブルビデオコーディング(SVC:Scalable Video Coding)拡張とマルチビュービデオコーディング(MVC:Multiview Video Coding)拡張とを含む、(ISO/IEC MPEG-4 AVCとしても知られる)ITU-T H.264がある。
[0046]HEVCの設計は、最近、ITU-Tビデオコーディングエキスパートグループ(VCEG)とISO/IECモーションピクチャエキスパートグループ(MPEG)とのJCT-VCによって確定された。HEVC RExtと呼ばれるHEVCの範囲拡張も、JCT-VCによって開発されている。以下でRExt WD7と呼ばれる、範囲拡張の最近のワーキングドラフト(WD)が、http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q1005-v4.zipから入手可能である。
[0047]本開示は、概して、最近確定されたHEVC仕様テキストをHEVCバージョン1またはベースHEVCと呼ぶ。範囲拡張仕様は、HEVCのバージョン2になり得る。動きベクトル予測など、多くのコーディングツールに関して、HEVCバージョン1と範囲拡張仕様とは、技術的に同様である。したがって、本開示がHEVCバージョン1に対する変更について説明するときはいつでも、概してベースHEVC仕様+いくつかの追加のコーディングツールを含む範囲拡張仕様にも、同じ変更が適用され得る。さらに、概して、HEVC範囲拡張を実装するデコーダにもHEVCバージョン1モジュールが組み込まれ得ると仮定され得る。
[0048]動きがあるグラフィックスおよびテキストなど、スクリーンコンテンツ材料のための新しいコーディングツールが、現在開発中であり、HEVCの将来のバージョンを含む将来のビデオコーディング規格中に含めることが企図されている。これらの新しいコーディングツールは、スクリーンコンテンツのためのコーディング効率を潜在的に改善する。新規の専用コーディングツールを用いてスクリーンコンテンツの特性を活用することによってコーディング効率の有意な改善が得られ得るという証拠があるので、SCC)のための特定のツールを含む、HEVC規格の場合によっては将来の拡張を開発することを目標とした提案の募集(CfP)が発行されている。企業および団体は、この募集に応答して提案を提出するように勧誘されている。このCfPの使用事例および要件が、MPEGドキュメントN14174に記載されている。第17回JCT-VC会議中に、SCCテストモデル(SCM:screen content coding test model)が確立された。SCCの最近のワーキングドラフト(WD)は、http://phenix.int-evry.fr/jct/doc_end_user/documents/18_Sapporo/wg11/JCTVC-R1005-v3.zipから入手可能である。
[0049]概して、ソースデバイス12のビデオエンコーダ20は、これらの現在または将来の規格のいずれかに従ってビデオデータを符号化するように構成され得ることが企図される。同様に、概して、宛先デバイス14のビデオデコーダ30は、これらの現在または将来の規格のいずれかに従ってビデオデータを復号するように構成され得ることも企図される。
[0050]図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれ、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0051]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合され得る。
[0052]上記で紹介したように、JCT-VCは最近、HEVC規格の開発を確定した。HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づいていた。HMは、たとえば、ITU-T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、H.264は9つのイントラ予測符号化モードを与えるが、HMは35個ものイントラ予測符号化モードを与え得る。
[0053]HEVCおよび他のビデオコーディング仕様では、ビデオシーケンスは一般に一連のピクチャを含む。ピクチャは「フレーム」と呼ばれることもある。ピクチャは、SL、SCb、およびSCrと示される3つのサンプルアレイを含み得る。SLはルーマサンプルの2次元アレイ(すなわち、ブロック)である。SCbはCbクロミナンスサンプルの2次元アレイである。SCrはCrクロミナンスサンプルの2次元アレイである。クロミナンスサンプルは、本明細書では「クロマ」サンプルと呼ばれることもある。他の事例では、ピクチャはモノクロームであり得、ルーマサンプルのアレイのみを含み得る。
[0054]ピクチャの符号化表現を生成するために、ビデオエンコーダ20はコーディングツリーユニット(CTU:coding tree unit)のセットを生成し得る。CTUの各々は、ルーマサンプルのコーディングツリーブロック(CTB)と、クロマサンプルの2つの対応するコーディングツリーブロックと、それらのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは3つの別々の色平面を有するピクチャでは、CTUは、単一のコーディングツリーブロックと、そのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。コーディングツリーブロックはサンプルのN×Nブロックであり得る。CTUは「ツリーブロック」または「最大コーディングユニット」(LCU:largest coding unit)と呼ばれることもある。HEVCのCTUは、H.264/AVCなど、他の規格のマクロブロックに広い意味で類似し得る。しかしながら、CTUは、必ずしも特定のサイズに限定されるとは限らず、1つまたは複数のコーディングユニット(CU)を含み得る。スライスは、ラスタ走査順序で連続的に順序付けられた整数個のCTUを含み得る。
[0055]コード化CTUを生成するために、ビデオエンコーダ20は、コーディングツリーブロックをコーディングブロックに分割するためにCTUのコーディングツリーブロック(CTB)に対して4分木区分を再帰的に実行し得、したがって「コーディングツリーユニット」という名称がある。コーディングブロックはサンプルのN×Nブロックであり得る。CUは、ルーマサンプルアレイとCbサンプルアレイとCrサンプルアレイとを有するピクチャのルーマサンプルのコーディングブロックと、そのピクチャのクロマサンプルの2つの対応するコーディングブロックと、それらのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは3つの別々の色平面を有するピクチャでは、CUは、単一のコーディングブロックと、そのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。
[0056]ビデオエンコーダ20は、CUのコーディングブロックを1つまたは複数の予測ブロックに区分し得る。予測ブロックは、同じ予測が適用されるサンプルの矩形(すなわち、正方形または非正方形)ブロックである。CUの予測ユニット(PU:prediction unit)は、ルーマサンプルの予測ブロックと、クロマサンプルの2つの対応する予測ブロックと、それらの予測ブロックを予測するために使用されるシンタックス構造とを備え得る。モノクロームピクチャまたは3つの別々の色平面を有するピクチャでは、PUは、単一の予測ブロックと、その予測ブロックを予測するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ20は、CUの各PUのルーマ予測ブロックとCb予測ブロックとCr予測ブロックとのための予測ルーマブロックと予測Cbブロックと予測Crブロックとを生成し得る。
[0057]ビデオエンコーダ20は、PUのための予測ブロックを生成するためにイントラ予測またはインター予測を使用し得る。ビデオエンコーダ20がPUの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ20は、PUに関連付けられたピクチャの復号サンプルに基づいてPUの予測ブロックを生成し得る。ビデオエンコーダ20が、PUの予測ブロックを生成するためにインター予測を使用する場合、ビデオエンコーダ20は、PUに関連付けられたピクチャ以外の1つまたは複数のピクチャの復号サンプルに基づいて、PUの予測ブロックを生成し得る。
[0058]ビデオエンコーダ20がCUの1つまたは複数のPUのための予測ルーマブロック、予測Cbブロック、および予測Crブロックを生成した後、ビデオエンコーダ20は、CUのためのルーマ残差ブロックを生成し得る。CUのルーマ残差ブロック中の各サンプルは、CUの予測ルーマブロックのうちの1つ中のルーマサンプルとCUの元のルーマコーディングブロック中の対応するサンプルとの間の差を示す。さらに、ビデオエンコーダ20はCUのためのCb残差ブロックを生成し得る。CUのCb残差ブロック中の各サンプルは、CUの予測Cbブロックのうちの1つ中のCbサンプルとCUの元のCbコーディングブロック中の対応するサンプルとの間の差を示し得る。ビデオエンコーダ20はCUのためのCr残差ブロックをも生成し得る。CUのCr残差ブロック中の各サンプルは、CUの予測Crブロックのうちの1つ中のCrサンプルとCUの元のCrコーディングブロック中の対応するサンプルとの間の差を示し得る。
[0059]さらに、ビデオエンコーダ20は、CUのルーマ残差ブロックとCb残差ブロックとCr残差ブロックとを1つまたは複数のルーマ変換ブロックとCb変換ブロックとCr変換ブロックとに分解するために4分木区分を使用し得る。変換ブロックは、同じ変換が適用されるサンプルの矩形(たとえば、正方形または非正方形)ブロックである。CUの変換ユニット(TU:transform unit)は、ルーマサンプルの変換ブロックと、クロマサンプルの2つの対応する変換ブロックと、それらの変換ブロックサンプルを変換するために使用されるシンタックス構造とを備え得る。したがって、CUの各TUは、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロックに関連付けられ得る。TUに関連付けられたルーマ変換ブロックはCUのルーマ残差ブロックのサブブロックであり得る。Cb変換ブロックはCUのCb残差ブロックのサブブロックであり得る。Cr変換ブロックはCUのCr残差ブロックのサブブロックであり得る。モノクロームピクチャまたは3つの別々の色平面を有するピクチャでは、TUは、単一の変換ブロックと、その変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。
[0060]ビデオエンコーダ20は、TUのためのルーマ係数ブロックを生成するために、TUのルーマ変換ブロックに1つまたは複数の変換を適用し得る。係数ブロックは変換係数の2次元アレイであり得る。変換係数はスカラー量であり得る。ビデオエンコーダ20は、TUのためのCb係数ブロックを生成するために、TUのCb変換ブロックに1つまたは複数の変換を適用し得る。ビデオエンコーダ20は、TUのためのCr係数ブロックを生成するために、TUのCr変換ブロックに1つまたは複数の変換を適用し得る。
[0061]係数ブロック(たとえば、ルーマ係数ブロック、Cb係数ブロックまたはCr係数ブロック)を生成した後に、ビデオエンコーダ20は、係数ブロックを量子化し得る。量子化は、一般に、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。ビデオエンコーダ20が係数ブロックを量子化した後に、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素をエントロピー符号化し得る。たとえば、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素に対してコンテキスト適応型バイナリ算術コーディング(CABAC:Context-Adaptive Binary Arithmetic Coding)を実行し得る。
[0062]ビデオエンコーダ20は、コード化ピクチャと関連データとの表現を形成するビットのシーケンスを含むビットストリームを出力し得る。ビットストリームは、NALユニットのシーケンスを備え得る。NALユニットは、NALユニット中のデータのタイプの指示と、必要に応じてエミュレーション防止ビットが点在させられたRBSPの形態でそのデータを含んでいるバイトとを含んでいる、シンタックス構造である。NALユニットの各々は、NALユニットヘッダを含み、RBSPをカプセル化する。NALユニットヘッダは、NALユニットタイプコードを示すシンタックス要素を含み得る。NALユニットのNALユニットヘッダによって指定されるNALユニットタイプコードは、NALユニットのタイプを示す。RBSPは、NALユニット内にカプセル化された整数個のバイトを含んでいるシンタックス構造であり得る。いくつかの事例では、RBSPは0ビットを含む。
[0063]異なるタイプのNALユニットは、異なるタイプのRBSPをカプセル化し得る。たとえば、第1のタイプのNALユニットはPPSのためのRBSPをカプセル化し得、第2のタイプのNALユニットはコード化スライスのためのRBSPをカプセル化し得、第3のタイプのNALユニットはSEIメッセージのためのRBSPをカプセル化し得、以下同様である。(パラメータセットおよびSEIメッセージのためのRBSPとは対照的に)ビデオコーディングデータのためのRBSPをカプセル化するNALユニットは、VCL NALユニットと呼ばれることがある。
[0064]ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信し得る。さらに、ビデオデコーダ30は、ビットストリームからシンタックス要素を取得するために、ビットストリームをパースし得る。ビデオデコーダ30は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいてビデオデータのピクチャを再構成し得る。ビデオデータを再構成するためのプロセスは、概して、ビデオエンコーダ20によって実行されるプロセスの逆であり得る。さらに、ビデオデコーダ30は、現在CUのTUに関連付けられた係数ブロックを逆量子化し得る。ビデオデコーダ30は、現在CUのTUに関連付けられた変換ブロックを再構成するために係数ブロックに対して逆変換を実行し得る。ビデオデコーダ30は、現在CUのPUのための予測ブロックのサンプルを現在CUのTUの変換ブロックの対応するサンプルに加算することによって、現在CUのコーディングブロックを再構成し得る。ピクチャの各CUのためのコーディングブロックを再構成することによって、ビデオデコーダ30はピクチャを再構成し得る。
[0065]クロマフォーマットと呼ばれることもあるビデオサンプリングフォーマットは、CU中に含まれるルーマサンプルの数に対して、CU中に含まれるクロマサンプルの数を定義し得る。クロマ成分のためのビデオサンプリングフォーマットに応じて、U成分およびV成分の、サンプルの数に関するサイズは、Y成分のサイズと同じであるかまたはそれとは異なり得る。HEVC規格では、chroma_format_idcと呼ばれる値が、ルーマ成分に対して、クロマ成分の異なるサンプリングフォーマットを示すように定義される。HEVCでは、chroma_format_idcはSPS中でシグナリングされる。表1は、chroma_format_idcの値と、関連するクロマフォーマットとの間の関係を示す。
[0066]表1では、変数SubWidthCおよびSubHeightCが、ルーマ成分のためのサンプルの数と各クロマ成分のためのサンプルの数との間の、水平および垂直のサンプリングレートの比を示すために使用され得る。表1に記載されているクロマフォーマットでは、2つのクロマ成分は同じサンプリングレートを有する。したがって、4:2:0サンプリングでは、2つのクロマアレイの各々はルーマアレイの半分の高さと半分の幅とを有するが、4:2:2サンプリングでは、2つのクロマアレイの各々はルーマアレイの同じ高さと半分の幅とを有する。4:4:4サンプリングでは、2つのクロマアレイの各々はルーマアレイと同じ高さと幅とを有し得、または場合によっては、3つの色平面はすべて、モノクロームサンプリングされたピクチャとして別個に処理され得る。
[0067]表1の例では、4:2:0フォーマットの場合、水平方向と垂直方向の両方について、ルーマ成分のためのサンプリングレートは、クロマ成分のサンプリングレートの2倍である。結果として、4:2:0フォーマットに従ってフォーマットされたコーディングユニットの場合、ルーマ成分のためのサンプルのアレイの幅および高さは、クロマ成分のためのサンプルの各アレイの幅および高さの2倍である。同様に、4:2:2フォーマットに従ってフォーマットされたコーディングユニットの場合、ルーマ成分のためのサンプルのアレイの幅は、各クロマ成分のためのサンプルのアレイの幅の2倍であるが、ルーマ成分のためのサンプルのアレイの高さは、各クロマ成分のためのサンプルのアレイの高さに等しい。4:4:4フォーマットに従ってフォーマットされたコーディングユニットの場合、ルーマ成分のためのサンプルのアレイは、各クロマ成分のためのサンプルのアレイと同じ幅と高さとを有する。YUV色空間に加えて、ビデオデータはRGB空間色に従って定義され得ることに留意されたい。このようにして、本明細書で説明するクロマフォーマットはYUV色空間またはRGB色空間のいずれかに適用され得る。RGBクロマフォーマットは、一般に、赤サンプルの数と、緑サンプルの数と、青サンプルの数とが等しくなるようにサンプリングされる。したがって、本明細書で使用する「4:4:4クロマフォーマット」という用語は、YUV色空間またはRGB色空間のいずれかを指すことがあり、ここにおいて、サンプルの数はすべての色成分について等しい。
[0068]図2A~図2Cは、ビデオデータのための異なるサンプルフォーマットを示す概念図である。図2Aは、4:2:0サンプルフォーマットを示す概念図である。図2Aに示されているように、4:2:0サンプルフォーマットの場合、クロマ成分はルーマ成分の4分の1のサイズである。したがって、4:2:0サンプルフォーマットに従ってフォーマットされたCUの場合、クロマ成分のサンプルごとに4つのルーマサンプルがある。図2Bは、4:2:2サンプルフォーマットを示す概念図である。図2Bに示されているように、4:2:2サンプルフォーマットの場合、クロマ成分はルーマ成分の2分の1のサイズである。したがって、4:2:2サンプルフォーマットに従ってフォーマットされたCUの場合、クロマ成分のサンプルごとに2つのルーマサンプルがある。図2Cは、4:4:4サンプルフォーマットを示す概念図である。図2Cに示されているように、4:4:4サンプルフォーマットの場合、クロマ成分はルーマ成分と同じサイズである。したがって、4:4:4サンプルフォーマットに従ってフォーマットされたCUの場合、クロマ成分のサンプルごとに1つのルーマサンプルがある。
[0069]図3は、4:2:0サンプルフォーマットに従ってフォーマットされた16×16コーディングユニットの一例を示す概念図である。図3は、CU内のルーマサンプルに対するクロマサンプルの相対位置を示す。上記で説明したように、CUは、一般に、水平方向および垂直方向のルーマサンプルの数に従って定義される。したがって、図3に示されているように、4:2:0サンプルフォーマットに従ってフォーマットされた16×16CUは、ルーマ成分の16×16サンプルと、各クロマ成分のための8×8サンプルとを含む。さらに、上記で説明したように、CUはより小さいCUに区分され得る。たとえば、図3に示されているCUは、4つの8×8CUに区分され得、ここで、各8×8CUは、ルーマ成分のための8×8サンプルと、各クロマ成分のための4×4サンプルとを含む。
[0070]図4は、4:2:2サンプルフォーマットに従ってフォーマットされた16×16コーディングユニットの一例を示す概念図である。図4は、CU内のルーマサンプルに対するクロマサンプルの相対位置を示す。上記で説明したように、CUは、一般に、水平方向および垂直方向のルーマサンプルの数に従って定義される。したがって、図4に示されているように、4:2:2サンプルフォーマットに従ってフォーマットされた16×16CUは、ルーマ成分のための16×16サンプルと、各クロマ成分のための8×16サンプルとを含む。さらに、上記で説明したように、CUはより小さいCUに区分され得る。たとえば、図4に示されているCUは、4つの8×8CUに区分され得、ここで、各CUは、ルーマ成分のための8×8サンプルと、各クロマ成分のための4×8サンプルとを含む。
[0071]図5に、IBCモードの概念説明図を示す。ビデオエンコーダ20およびビデオデコーダ30は、たとえば、IBCモードを使用してビデオデータのブロックを符号化および復号するように構成され得る。リモートデスクトップ、リモートゲーミング、ワイヤレスディスプレイ、自動車インフォテインメント、クラウドコンピューティングなど、多くのアプリケーションは、人々の日常生活では日常的になりつつあり、そのようなコンテンツをコーディングするときのコーディング効率は、IBCモードの使用によって改善され得る。図1のシステム10は、これらのアプリケーションのいずれかを実行するように構成されたデバイスを表し得る。これらの適用例におけるビデオコンテンツは、しばしば、自然コンテンツ、テキスト、人工グラフィックスなどの組合せである。ビデオフレームのテキストおよび人工グラフィックス領域では、(文字、アイコン、シンボルなどの)繰返しパターンがしばしば存在する。上記で紹介したように、IBCは、JCT-VC M0350において報告されたように、この種類の冗長性を除去することと、フレーム内コーディング効率を潜在的に改善することとを可能にする専用の技法である。図5に示されているように、IBCを使用するCUの場合、予測信号は同じフレーム(たとえば、ピクチャ)中のすでに再構成された領域から取得される。最後に、現在CUから変位させられた予測信号の位置を示すオフセットまたはブロックベクトルは、残差信号とともに符号化される。
[0072]たとえば、図5は、本開示の技法によるIBCモードに従って現在ピクチャ103内のビデオデータの現在ブロック102を予測するための例示的な技法を示している。図5に、現在ピクチャ103内の予測ビデオブロック104を示す。ビデオコーダ、たとえば、ビデオエンコーダ20および/またはビデオデコーダ30は、本開示の技法によるIBCモードに従って現在ビデオブロック102を予測するために、予測ビデオブロック104を使用し得る。
[0073]ビデオエンコーダ20は、ビデオデータの前に再構成されたブロックのセットから現在ビデオブロック102を予測するための予測ビデオブロック104を選択する。ビデオエンコーダ20は、符号化ビデオビットストリーム中にも含まれるビデオデータを逆量子化および逆変換することと、得られた残差ブロックをビデオデータの再構成ブロックを予測するために使用される予測ブロックと加算することとによって、ビデオデータのブロックを再構成する。図5の例では、「対象とするエリア」または「ラスタエリア」と呼ばれることもある、ピクチャ103内の対象とする領域108は、前に再構成されたビデオブロックのセットを含む。ビデオエンコーダ20は、以下でより詳細に説明するように、様々な方法でピクチャ103内の対象とする領域108を定義し得る。ビデオエンコーダ20は、対象とする領域108内の様々なビデオブロックに基づいて現在ビデオブロック102を予測およびコーディングすることの相対的な効率と精度との分析に基づいて、対象とする領域108中のビデオブロックの中から現在ビデオブロック102を予測するための予測ビデオブロック104を選択し得る。
[0074]対象とする領域108は、本開示では、IBC予測領域と呼ばれることもある。本開示は、対象とする領域108中にどのブロックが含まれるかを変更し(modify)得る様々な技法について説明する。したがって、本開示の技法を実装するとき、対象とする領域108のサイズおよび形状は、図5の例において示されるサイズおよび形状とは異なり得る。
[0075]ビデオエンコーダ20は、現在ビデオブロック102に対する予測ビデオブロック104のロケーションまたは変位を表す2次元ベクトル106を決定する。オフセットベクトルの一例である2次元ベクトル106は、それぞれ、現在ビデオブロック102に対する予測ビデオブロック104の水平変位と垂直変位とを表す、水平変位成分112と垂直変位成分110とを含む。ビデオエンコーダ20は、2次元ベクトル106を識別または定義する、たとえば、水平変位成分112と垂直変位成分110とを定義する、1つまたは複数のシンタックス要素を符号化ビデオビットストリーム中に含め得る。ビデオデコーダ30は、2次元ベクトル106を決定するために1つまたは複数のシンタックス要素を復号し、現在ビデオブロック102のための予測ビデオブロック104を識別するために、決定されたベクトルを使用し得る。
[0076]いくつかの例では、2次元ベクトル106の解像度は、整数ピクセルであり得、たとえば、整数ピクセル解像度を有するように制約され得る。そのような例では、水平変位成分112および垂直変位成分110の解像度は整数ピクセルである。そのような例では、ビデオエンコーダ20およびビデオデコーダ30は、現在ビデオブロック102のための予測子を決定するために予測ビデオブロック104のピクセル値を補間する必要はない。
[0077]他の例では、水平変位成分112と垂直変位成分110の一方または両方の解像度はサブピクセルであり得る。たとえば、成分112および成分110の一方は整数ピクセル解像度を有し得、他方はサブピクセル解像度を有する。いくつかの例では、水平変位成分112と垂直変位成分110の両方の解像度はサブピクセルであり得るが、水平変位成分112と垂直変位成分110とは異なる解像度を有し得る。
[0078]いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ20および/またはビデオデコーダ30は、特定のレベル、たとえば、ブロックレベル、スライスレベル、またはピクチャレベルの適応に基づいて、水平変位成分112および垂直変位成分110の解像度を適応させる。たとえば、ビデオエンコーダ20は、スライスレベルにおいて、たとえば、スライスヘッダ中で、水平変位成分112および垂直変位成分110の解像度が整数ピクセル解像度であるのか整数ピクセル解像度でないのかを示すフラグをシグナリングし得る。フラグが、水平変位成分112および垂直変位成分110の解像度が整数ピクセル解像度ではないことを示す場合、ビデオデコーダ30は、解像度がサブピクセル解像度であると推論し得る。いくつかの例では、必ずしもフラグであるとは限らない1つまたは複数のシンタックス要素は、ビデオデータのスライスまたは他のユニットごとに、水平変位成分112および/または垂直変位成分110の集合的な解像度または個々の解像度を示すために送信され得る。
[0079]さらに他の例では、フラグまたはシンタックス要素の代わりに、ビデオエンコーダ20は、解像度コンテキスト情報に基づいて水平変位成分112および/または垂直変位成分110の解像度を設定し得、ビデオデコーダ30は、解像度コンテキスト情報から水平変位成分112および/または垂直変位成分110の解像度を推論し得る。解像度コンテキスト情報は、例として、現在ビデオブロック102を含むピクチャまたはピクチャのシーケンスのための色空間(たとえば、YUV、RGBなど)、特定の色フォーマット(たとえば、4:4:4、4:2:2、4:2:0など)、フレームサイズ、フレームレート、または量子化パラメータ(QP)を含み得る。少なくともいくつかの例では、ビデオコーダは、前にコーディングされたフレームまたはピクチャに関する情報に基づいて、水平変位成分112および/または垂直変位成分110の解像度を決定し得る。このようにして、水平変位成分112の解像度および垂直変位成分110のための解像度は、あらかじめ定義され、シグナリングされ得るか、他のサイド情報(たとえば、解像度コンテキスト情報)から推論され得るか、またはすでにコーディングされたフレームに基づき得る。
[0080]現在ビデオブロック102は、CU、またはCUのPUであり得る。いくつかの例では、ビデオコーダ、たとえば、ビデオエンコーダ20および/またはビデオデコーダ30は、IBCに従って予測されたCUをいくつかのPUに分割し得る。そのような例では、ビデオコーダは、CUのPUの各々について、それぞれの(たとえば、異なる)2次元ベクトル106を決定し得る。たとえば、ビデオコーダは、2N×2N CUを2つの2N×N PU、2つのN×2N PU、または4つのN×N PUに分割し得る。他の例として、ビデオコーダは、2N×2N CUを((N/2)×N+(3N/2)×N)PU、((3N/2)×N+(N/2)×N)PU、(N×(N/2)+N×(3N/2))PU、(N×(3N/2)+N×(N/2))PU、4つの(N/2)×2N PU、または4つの2N×(N/2)PUに分割し得る。いくつかの例では、ビデオコーダは、2N×2N PUを使用して2N×2N CUを予測し得る。
[0081]現在ビデオブロック102は、ルーマビデオブロック(たとえば、ルーマ成分)と、ルーマビデオブロックに対応するクロマビデオブロック(たとえば、クロマ成分)とを含む。いくつかの例では、ビデオエンコーダ20は、ルーマビデオブロックのための2次元ベクトル106を定義する1つまたは複数のシンタックス要素のみを符号化ビデオビットストリーム中に符号化し得る。そのような例では、ビデオデコーダ30は、ルーマブロックのためにシグナリングされた2次元ベクトルに基づいて、ルーマブロックに対応する1つまたは複数のクロマブロックの各々のための2次元ベクトル106を導出し得る。本開示で説明する技法では、1つまたは複数のクロマブロックのための2次元ベクトルの導出において、ビデオデコーダ30は、ルーマブロックのための2次元ベクトルがクロマサンプル内のサブピクセル位置を指す場合、ルーマブロックのための2次元ベクトルを変更し得る。
[0082]色フォーマット、たとえば、色サンプリングフォーマットまたはクロマサンプリングフォーマットに応じて、ビデオコーダは、ルーマビデオブロックに対して、対応するクロマビデオブロックをダウンサンプリングし得る。色フォーマット4:4:4はダウンサンプリングを含まず、これは、クロマブロックが水平方向および垂直方向においてルーマブロックと同じ数のサンプルを含むことを意味する。色フォーマット4:2:2は水平方向においてダウンサンプリングされ、これは、クロマブロック中にルーマブロックに対して水平方向において半分の数のサンプルがあることを意味する。色フォーマット4:2:0は水平方向および垂直方向においてダウンサンプリングされ、これは、クロマブロック中にルーマブロックに対して水平方向および垂直方向において半分の数のサンプルがあることを意味する。
[0083]ビデオコーダがクロマビデオブロックのためのベクトル106を対応するルーマブロックのためのベクトル106に基づいて決定する例では、ビデオコーダは、ルーマベクトルを変更する必要があり得る。たとえば、ルーマベクトル106が、水平変位成分112および/または垂直変位成分110が奇数のピクセルである整数解像度を有し、色フォーマットが4:2:2または4:2:0である場合、変換されたルーマベクトルは、対応するクロマブロック中の整数ピクセルロケーションを指さないことがある。そのような例では、ビデオコーダは、対応するクロマブロックを予測するためのクロマベクトルとして使用するためにルーマベクトルをスケーリングし得る。
[0084]説明したように、図5は、IBCモードでコーディングされている現在CUを示している。現在CUのための予測ブロックは、探索領域から取得され得る。探索領域は、現在CUと同じフレームからのすでにコーディングされたブロックを含む。たとえば、フレームがラスタ走査順序で(すなわち、左から右におよび上から下に)コーディングされていると仮定すると、フレームのすでにコーディングされたブロックは、図5に示されているように、現在CUの左側および上にあるブロックに対応する。いくつかの例では、探索領域はフレーム中のすでにコーディングされたブロックのすべてを含み得るが、他の例では、探索領域はすでにコーディングされたブロックのすべてよりも少ないブロックを含み得る。動きベクトルまたは予測ベクトルと呼ばれることがある、図5中のオフセットベクトルは、現在CUの左上ピクセルと予測ブロックの左上ピクセルとの間の差分(図5中の標示された予測信号)を識別する。したがって、符号化ビデオビットストリーム中でオフセットベクトルをシグナリングすることによって、ビデオデコーダは、現在CUがIBCモードでコーディングされるとき、現在CUのための予測ブロックを識別することができる。
[0085]IBCは、HEVCへのSCC拡張を含む、SCCの様々な実装形態中に含まれている。IBCの一例について、図5に関して上記で説明したが、ここで、現在CU/PUは、現在ピクチャ/スライスのすでに復号されたブロックから予測される。IBCでは、予測ブロック(たとえば図5中の予測ビデオブロック104)は、ループフィルタ処理されなかった、たとえばデブロックフィルタ処理またはSAOフィルタ処理されなかった再構成ブロックであり得る。
[0086]IBCを用いてコーディングされるルーマ成分またはクロマ成分の場合、ブロック補償が整数ブロック補償を用いて行われ、したがって補間が必要とされない。したがって、ブロックベクトルは、整数レベル精度において予測され、シグナリングされる。
[0087]SCCの現在の実装形態では、ブロックベクトル予測子は、各CTBの始まりにおいて(-w,0)に設定され、ここで、wはCUの幅に対応する。そのようなブロックベクトル予測子は、それがIBCモードを用いてコーディングされる場合、最新のコード化CU/PUのうちの1つであるように更新される。CU/PUがIBCを用いてコーディングされない場合、ブロックベクトル予測子は不変のままである。ブロックベクトル予測の後、ブロックベクトル差分は、HEVCなどにおけるMV差分(MVD:MV difference)コーディング方法を使用して符号化される。
[0088]IBCの現在の実装形態は、CUレベルとPUレベルの両方におけるIBCコーディングを有効化する。PUレベルのIBCの場合、2N×NおよびN×2N PU区分(partitions)が、すべてのCUサイズについてサポートされる。さらに、CUが最も小さいCUであるとき、N×N PU区分がサポートされる。
[0089]上記で紹介したように、HEVCは、タイルおよび波面並列処理(WPP)を含む、コーデックをより並列フレンドリー(parallel-friendly)にするためのいくつかの提案を含んでいる。HEVCは、タイルのコーディングツリーブロックラスタ走査において連続的に順序付けられた、1つの列および1つの行中で同時に発生する整数個のコーディングツリーブロックとしてタイルを定義する。各ピクチャをタイルに分割することは区分である。
[0090]図6に、タイルが使用されるときのピクチャのラスタ走査を示す。ピクチャ内のタイルは、図6に示されているように、ピクチャのタイルラスタ走査において連続的に順序付けられる。タイルの数およびそれらの境界のロケーションは、シーケンス全体について定義されるか、またはピクチャごとに変更され得る。タイル境界は、スライス境界と同様に、タイルが独立して処理され得るように、パースおよび予測依存性を断つ。ただし、ループ内フィルタ(デブロッキングおよびSAO)は、タイル境界を依然として越え得る。HEVCはまた、スライスとタイルとの間の関係に対するいくつかの制約を規定する。図6の例では、ライン114Aおよび114Bは垂直タイル境界を表し、ライン114Cおよび114Dは水平タイル境界を表す。各タイル内の番号は、タイル内のCTBのためのラスタ走査順序を表す。たとえば、左上端のタイルの場合、0と標示されたブロックが最初に復号され、次いで1と標示されたブロックが復号され、次いで2と標示されたブロックが復号され、以下同様である。
[0091]タイルを使用することの潜在的な利点は、そのタイルが、ビデオデコーダ30など、エントロピー復号および動き補償再構成のためのビデオデコーダのプロセッサ間の通信を常に必要とするとは限らないことである。しかしながら、そのような通信は、シンタックス要素loop_filter_across_tiles_enabled_flagが1に設定される場合、必要とされ得る。スライスと比較して、タイルが、スライスよりも潜在的に高い相関をもつサンプルを含んでいるピクチャ区分形状を可能にするので、また、タイルがスライスヘッダオーバーヘッドを潜在的に低減するので、タイルは、潜在的により良好なコーディング効率を有する。
[0092]HEVCにおけるタイル設計は、いくつかの利益を与え得る。一例として、タイルは、ビデオデコーダ30による並列処理を有効化し得る。別の例として、タイルは、スライスの使用と比較して、CTUの変更された復号順序を可能にすることによってコーディング効率を改善し得るが、主要な利益は第1の利益である。タイルがシングルレイヤコーディングにおいて使用されるとき、シンタックス要素min_spatial_segmentation_idcは、デコーダが並列復号情報を最大限に利用することを想定して、1つの処理スレッドによって処理されるべきルーマサンプルの最大数を計算するためにデコーダによって使用され得る。HEVCでは、たとえば、エントロピーコーディング同期あるいはタイル境界またはスライス境界を越えるデブロッキングフィルタ処理により、異なるスレッド間に同じピクチャの相互依存性があり得る。HEVCは、エンコーダがmin_spatial_segmentation_idcの値を最高の可能な値であるように設定することを奨励する注釈を含む。
[0093]上記で紹介したように、HEVCはまた、WPPをサポートする。WPPが有効化されるとき、ピクチャの各CTU行は、分離された区分である。しかしながら、スライスおよびタイルと比較すると、WPPでは、コーディング依存性がCTU行の境界において断たれない。さらに、コーディング損失をさらに低減するために、CABAC確率が、前の行の第2のCTUから伝搬される。また、WPPは、通常のラスタ走査順序を変更しない。依存性が断たれないので、WPPビットストリームのレートひずみ損失は、非並列ビットストリームのレートひずみ損失と比較して小さくなり得る。
[0094]WPPが有効化されるとき、CTU行の数までの数のプロセッサが、CTU行(またはライン)を処理するために並列に動作し得る。しかしながら、波面依存性は、すべてのCTU行がピクチャの始まりにおいて復号を開始することを可能にするとは限らない。したがって、CTU行はまた、ピクチャの終わりにおいて、復号を同時に終了することができない。これは、多数のプロセッサが使用されるときにより明白になる、並列化非効率性をもたらす。
[0095]図7に、各行が、上の行の第2のCTBを処理した後に利用可能なCABAC確率を用いて開始する、CTBの行を並列に処理するWPPの一例を示す。行116A~116Gの各々が並列に復号され得るが、各行が上の行の情報に潜在的に依存するので、すべての行の復号が同時に開始することが可能であるとは限らない。たとえば、ビデオデコーダ30は、行116Cの一定数のブロックが復号されるまで、行116Dを復号することを開始することができない。同様に、ビデオデコーダ30は、116Dの一定数のブロックがすでに復号されるまで、116Eを復号することを開始することができない。以下でより詳細に説明するように、上の行を復号することを開始した後、ある行を復号する前にビデオデコーダ30が待つ時間の量は、遅延と呼ばれることがある。図7の例では、グレーのブロックは、すでに復号されたブロックを表し、白のブロックは、まだ復号されていないブロックを表す。図7に見られるように、行は、一般に、すぐ下の行よりも多くのすでに復号されたブロックを有する。
[0096]タイルおよびWPPなどの並列処理技法とともにIBCモードにおいてビデオデータをコーディングすることは、潜在的困難を生じ(pose)得る。IBCモードは、同じピクチャ内の前に復号されたフィルタ処理されていないサンプルを予測のために使用する。現在のテストモデルでは、IBCモードの場合、探索範囲は、無制限であり、現在ピクチャのいかなるフィルタ処理されていない復号されたサンプルをも使用することができる(全探索IBC)。リアルタイム適用例では、同時に複数のCTUを有効化された処理することのために、非ラスタ順序(たとえばWPP)で処理することが一般的である。HEVCは、WPPまたはentropy_coding_sync_enabled_flagが有効化されるときのエントロピー復号順序を定義する。
[0097]WPPおよびタイルを用いたSCCのいくつかの実装形態は、非ラスタ走査が有効化されるとき、潜在的にいくつかの問題を有する。第1の例として、予測サンプルの利用可能性が、常にラスタ順序順次処理に基づいて考慮される。これは、システムの並列処理能力に潜在的に著しく影響を及ぼす。第2の例として、最近のJCT-VC会議において、WPPが有効化されるときエントロピーパーシング(entropy parsing)に対して同様のライン中のIBC予測領域を制限するためのいくつかの提案があった。しかしながら、これは、IBCモードのために利用可能である限られた探索範囲により、コーディング効率に潜在的に著しい影響を及ぼす。
[0098]並列処理方式のようなWPPを可能にし、コーディング効率損失を低減するために、本開示は、IBC探索範囲および/またはIBCブロックベクトルに対するいくつかのフレキシブルな制限を追加するための技法について説明する。
[0099]以下の技法の各々は、別々にまたは一緒に適用され得る。本開示で説明する技法は、IBC予測のための予測領域の利用可能性を詳述する。さらに、この領域は、WPPに基づいて有効化されるか否かに依存し得る。
[0100]第1の技法によれば、サンプルを再構成することの固定の処理順序が考慮され得る。(たとえばWPPが有効化されるときのエントロピーパーシング順序または以下の処理順序のうちのいずれか)。すでに復号/再構成されたサンプルが、予測のためにのみ使用され得る。
[0101]第2の技法によれば、サンプルを再構成することの固定の処理順序が考慮され得る。(たとえばWPPが有効化されるときのエントロピーパーシング順序または以下の処理順序のうちのいずれか)。すでに復号/再構成されたサンプルが、予測のためにのみ使用され得る。さらに、現在CTBの下のいかなる領域もIBC予測のために利用可能でないと見なされる。
[0102]第3の技法によれば、サンプルを再構成することの固定の処理順序が考慮され得る。(たとえばWPPが有効化されるときのエントロピーパーシング順序または以下の処理順序のうちのいずれか)、および現在のCTBの下のいかなる領域も、IBC予測のために利用可能でないと見なされ、部分領域が、SPSヘッダ中で指定された最大TUサイズに基づいて、現在CTBの上のために利用可能でないと見なされる。
[0103]第4の技法によれば、サンプルを再構成することの固定の処理順序が考慮され得る。(たとえばWPPが有効化されるときのエントロピーパーシング順序または以下の処理順序のうちのいずれか)、および部分領域が、SPSヘッダ中で指定された最大TUサイズに基づいて、現在CTBの上のために利用可能でないと見なされる。
[0104]第5の技法によれば、サンプルを再構成することのフレキシブルな処理順序が、IBC予測のために有効であると見なされ得、この領域がビットストリーム中でシグナリングされる。
[0105]第6の技法によれば、サンプルを再構成することのフレキシブルな処理順序が、IBC予測のために有効であると見なされ得、この領域がビットストリーム中でシグナリングされ、現在CTBの下のいかなる領域も、IBC予測のために利用可能でないと見なされる。次に、上記で紹介した様々な技法の例をより詳細に示す。
[0106]図8~図12に、WPPを使用して復号されるように構成されたブロックの例を示す。図8~図12に示されている領域の各々は、CTBに対応する。図8~図12の例では、Xで標示されたCTBは、復号されている現在ブロックを表す。IBC予測の場合、1で標示されたブロックはIBCのために使用されることがあり、0で標示されたブロックはIBCのために使用されないことがある。
[0107]図8に、上のCTB行に関して1CTB遅延をもつIBC処理順序を用いた第1の例について次に説明するを示す。図8に示されているような以下の制限が、どのIBCブロックも、0でマークされた領域から予測しないように、IBCブロックベクトルに対して適用される。図8では、「1」でマークされた領域は、すでに再構成された有効な予測された領域である。これらの制限は、「0」でマークされたいかなる領域も現在ブロックxと並列に処理することを可能にする。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
および
[0108]本開示の一技法によれば、波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのために、ビデオデコーダ30は、CTBの第1の行が復号され始めるときと、CTBの第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、CTB遅延を決定し得る。IBCモードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの現在ブロックのために、ビデオデコーダ30は、WPPが有効化されてコーディングされる1つまたは複数のブロックのために決定されたCTB遅延に基づいて、現在ブロックを含むピクチャ内の現在ブロックのためのIBC予測領域を決定し得る。言い換えれば、ビデオデコーダ30は、WPPが有効化または無効化されるか否かにかかわらないことを意味する、entropy_coding_sync_enabled_flagの値にかかわらず、CTB遅延に基づいて、現在ブロックのためのIBC予測領域を決定し得る。常に、CTB遅延に基づいてIBC予測領域を決定することによって、全体的復号複雑さは低減されるが、ビデオデコーダ30がWPPが有効化されてIBCモードをサポートすることを依然として可能にする方法で低減される。
[0109]いくつかの代替実装形態では、上記の制限は、どのIBCブロックも、復号されない領域から予測しないように、entropy_coding_sync_enabled_flagが1に等しいとき、IBCブロックベクトルに対して適用されるにすぎないことがある。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
entropy_coding_sync_enabled_flagが1に等しいとき
およびentropy_coding_sync_enabled_flagが1に等しいとき
[0110]次に、上のCTB行に関して2CTB遅延をもつIBC処理順序を用いた第2の例について説明する。図9に示されているような以下の制限が、どのIBCブロックも「0」領域から予測しないように、IBCブロックベクトルに対して適用される。図9では、1でマークされた領域は、すでに再構成された有効な予測された領域である。これらの制限は、「0」でマークされたいかなる領域も現在ブロックxと並列に処理することを可能にする。ここで、各領域はCTBに対応する。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
および
[0111]代替的に、上記の制限条件は、どのIBCブロックも、復号されない領域から予測しないように、entropy_coding_sync_enabled_flagが1に等しいときのみ、IBCブロックベクトルに対して適用される。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
entropy_coding_sync_enabled_flagが1に等しいとき
およびentropy_coding_sync_enabled_flagが1に等しいとき
[0112]次に、タイル形の領域をもつIBC処理順序を用いた第3の例について説明する。図10に示されているような以下の制限が、どのIBCブロックも「0」領域から予測しないように、IBCブロックベクトルに対して適用される。図10では、1でマークされた領域は、すでに再構成された有効な予測された領域である。これらの制限は、「0」でマークされたいかなる領域も現在ブロックxと並列に処理することを可能にする。ここで、各領域はCTBに対応する。
[0113]一例では、上記の制限は、以下のようにentropy_coding_sync_enabled_flagが1に等しいときのみ適用される。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
----
- 以下は、ビットストリーム適合の要件である。
[0114]代替的に、上記の制限条件は、どのIBCブロックも、復号されない領域から予測しないように、entropy_coding_sync_enabled_flagが1に等しいときのみ、IBCブロックベクトルに対して適用される。以下は、ビットストリーム適合の要件である。entropy_coding_sync_enabled_flagが1に等しいとき
[0115]次に、上のCTB行に関して1未満のCTB遅延をもつIBC処理順序を用いた第4の例について説明する。この例では、上記で説明した「上のCTB行に関して1CTB遅延をもつIBC処理順序」と同様に、ただし、代わりに、1未満のCTB遅延である最大TUブロックの遅延を用いて、IBCのための予測サンプルを制限することが提案される。最大TUサイズmaxTUSizeYが、maxTUSizeY=1<<MaxTbLog2SizeYとして導出されるものとする。(SPS中でシグナリングされる)。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
および
[0116]代替的に、上記の制限条件は、どのIBCブロックも、復号されない領域から予測しないように、entropy_coding_sync_enabled_flagが1に等しいときのみ、IBCブロックベクトルに対して適用される。
8.4.4 イントラブロックコピー予測モードにおけるブロックベクトル成分のための導出プロセス
- 以下は、ビットストリーム適合の要件である。
entropy_coding_sync_enabled_flagが1に等しいとき
およびentropy_coding_sync_enabled_flagが1に等しいとき
[0117]波面並列処理は、ピクチャ中の各CTB行を並列処理することを可能にする。たとえば、1080pピクチャでは、システムが17個の並列処理コアを有する場合、17個までのCTB行が並列に処理され得る。しかしながら、たいていのマルチコアシステムでは、限られた数(たとえば4つ)の並列処理コアのみが使用されることが一般的である。このシナリオでは、4つのCTB行のみが並列に処理され、第5のCTB行が、上の4つのCTB行のうちの1つの完了の後に処理される。そのようなシナリオでは、第5のCTB行が、前の4つのCTB行からのすでに復号された領域から予測することが可能である。この例では、各CTB行のために、すべてのそれの前の復号されたCTB行のための有効な復号された領域(CTB)をシグナリングすることが提案される。別の実施形態では、各CTB行のために、すべてのそれのCTB行のための有効な復号された領域(CTB)をシグナリングすることが提案される。この情報は、SPS、VPS、PPS、スライスヘッダまたはそれらのそれぞれの拡張中でシグナリングされ得る。代替的に、この情報は、SEIメッセージ中でシグナリングされ得る。
[0118]一例では、entropy_coding_sync_enabled_flagが1に等しいときに基づいて、以下の情報が条件付きでシグナリングされる。代替的に以下の情報は、entropy_coding_sync_enabled_flagが有効化されるか否かとは無関係にシグナリングされる。
[0119]別の例では、以下の情報は、少なくとも1つのパラメータセット(PPS、SPS、VPS)またはそれの拡張中でシグナリングされ得る、IBCツール有効化フラグ上で条件付きでシグナリングされる。
[0120]第1の例では、各CTB行のために、それの上のCTBの行のすべてのためのIBC予測のための利用可能性領域がシグナリングされる。たとえば図11参照。現在CTBの下の領域は、IBC予測のために利用可能でないと見なされる。以下は、スライスヘッダにおける提案する方法の例示的な実装形態である。
1に等しいpps_ibc_ref_avail_restriction_present_flagは、イントラブロックコピー参照使用制限が存在し、スライスのすべてのコード化ツリーブロックのためにスライスセグメントヘッダ中でシグナリングされることを指定する。0に等しいpps_ibc_ref_avail_restriction_present_flagは、イントラブロックコピー参照使用情報がスライスセグメントヘッダ中に存在しないことを指定するpps_ibc_ref_avail_restriction_present_flagが存在しないとき、それは0であると推論される。
num_ctbY_in_slice_minus1+1は、スライス中のCTB行の数を指定する。
max_delay_IBCPred_in_CTBs[i][j]は、現在CTB行iのために、IBC予測のために利用可能である、前の各CTB行jのためのCTBに関するその最大遅延を指定する。存在しないとき、それは行中のCTBの数に等しいと推論される。
[0121]別の例示的な実装形態では、各CTB行のために、すべてのCTBの行のためのIBC予測のための利用可能性領域がシグナリングされる。たとえば図12参照。以下は、スライスヘッダにおける提案する方法の例示的な実装形態である。
1に等しいpps_ibc_ref_avail_restriction_present_flagは、イントラブロックコピー参照使用制限が存在し、スライスのすべてのコード化ツリーブロックのためにスライスセグメントヘッダ中でシグナリングされることを指定する。0に等しいpps_ibc_ref_avail_restriction_present_flagは、イントラブロックコピー参照使用情報がスライスセグメントヘッダ中に存在しないことを指定するpps_ibc_ref_avail_restriction_present_flagが存在しないとき、それは0であると推論される。
num_ctbY_in_slice_minus1+1は、スライス中のCTB行の数を指定する。
max_delay_IBCPred_in_CTBs[i][j]は、現在CTB行iのために、IBC予測のために利用可能である、前の各CTB行jのためのCTBに関するその最大遅延を指定する。存在しないとき、それは行中のCTBの数に等しいと推論される。
[0122]代替的に、これは、SPS VUIまたはSEIメッセージにおいてシグナリングされ、JCTVC-S0145および2014年10月7日に出願された米国仮特許出願62/061,063号において提案された態様と組み合わせられ得る。
[0123]本開示の別の例示的な技法は、マージのためのIBCモードのシグナリングに関する。本開示は、マージモードのためのIBCモードの使用をシグナリングする技法を紹介する。提案する方法は、主に、場合によっては高ビット深度(8ビット超)のサポート、4:4:4、4:2:2、4:2:0、4:0:0などの異なるクロマサンプリングフォーマットなどを含む、スクリーンコンテンツコーディングに関係する。
[0124]最近のJCT-VC会議では、IBCモードが使用されるときのマージ候補リスト生成を変更するための提案があった。IBCの予測特性がインターとは異なることが観測されたので、マージ候補リスト生成プロセスがインターとは異なって変更されるとき、コーディング効率を与えることが示された。
[0125]図13に、IBCマージプロセスがインターマージプロセスとは別々にシグナリングされる、例示的なシグナリング技法を示す。図13の例では、ビデオデコーダ30は、PUのために、PUのCUがインターモードにおいてコーディングされるかどうかを示すシンタックス要素(210)を受信する。CUのためのcu_skip_flagが真(212、Yes)である場合、CUは、スキップモードにおいてコーディングされ、ビデオデコーダ30は、CUのためのマージインデックス(214)を受信または推論し、決定されたマージインデックスに関連する動き情報に従ってCUをコーディングする。CUのためのcu_skip_flagが偽(212、No)である場合、ビデオデコーダ30は、シンタックス要素intra_bc_flag(216)とマージフラグ(218)とを受信する。マージフラグが真(220、Yes)である場合、ビデオデコーダ30は、マージインデックス(214)を受信し、マージインデックスに関連する動き情報に従ってCUを復号する。マージフラグが偽(220、No)である場合、ビデオデコーダ30は、別のintra_bc_flag(224)を受信する。intra_bc_flagが真(224、Yes)である場合、ビデオデコーダ30は、ブロックベクトル情報(226)を受信する。受信されたブロックベクトル情報に基づいて、ビデオデコーダ30はCUを復号する。intra_bc_flagが偽(224、No)である場合、ビデオデコーダ30は動きベクトル情報(228)を受信する。動きベクトル情報に基づいて、ビデオデコーダ30はCUを復号する。
[0126] 図13で説明するシグナリングの方式は、潜在的問題を有する。一例として、インターモードとIBCモードを分離するためのあらゆるPUのためのintra_bc_flagのシグナリングは、IBCモードとインターモードとの統一のために効率的でないことがある。この問題に関係する態様/解決策は、2014年10月7日に出願された米国仮特許出願62/061,121号、2015年10月6日に出願された米国特許出願14/876,699号、およびJCTVC-S0113においてカバーされる。インター予測に関して、BVDおよびBVP_idxのコーディングをMVDおよびMVPインデックスのコーディングと整合させることが提案された。
[0127]本開示の一技法によれば、図14に示されているように、現在PUがマージである(すなわちmerge_flagが1である)ときのみ、intra_bc_flagをシグナリングすることが提案される。さらに、intra_bc_flagは、少なくとも1つのパラメータセット(PPS、SPS、VPS)中でまたは他の場所でシグナリングされ得る、IBCツール有効化フラグ上で条件付きでシグナリングされ得る。本開示は、マージPUの場合のみシグナリングされるintra_bc_flagに基づいて、IBCマージプロセスをインターマージプロセスから分離するための技法を紹介する。そのような事例では、IBCモードのためのマージ候補リストと従来のインター予測のためのマージ候補リストとは異なり得る。シンタックス要素intra_bc_flagは、以下の場合、シグナリングされず、1として推論されないことがある。(1)現在スライスがIスライスである、(2)現在CUサイズが8×8であり、それの区分サイズがN×Nである。
[0128]図14に、図13の別々にシグナリングすることと比較してIBCマージプロセスが1回のみシグナリングされる例示的なシグナリング技法を示す。図14の例では、ビデオデコーダ30は、PUのために、PUのCUがインターモードにおいてコーディングされるかどうかを示すシンタックス要素(230)を受信する。CUのためのcu_skip_flagが真(232、Yes)である場合、CUは、スキップモードにおいてコーディングされ、ビデオデコーダ30は、intra_bc_flag(234)とCUのためのマージインデックス(214)とを受信し、決定されたマージインデックスに関連する動き情報に従ってCUをコーディングする。CUのためのcu_skip_flagが偽(232、No)である場合、ビデオデコーダ30は、マージフラグ(240)を受信する。マージフラグが真(240、Yes)である場合、ビデオデコーダ30は、intra_bc_flag(234)とマージインデックス(236)とを受信し、マージインデックスに関連する動き情報に従ってCUを復号する。マージフラグが偽(240、No)である場合、ビデオデコーダ30は、動き情報(242)を受信し、場合によってはIBCブロックベクトル情報を含み、動き情報に従ってCUを復号する。
[0129]図15は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は、ビデオを後処理エンティティ27に出力するように構成され得る。後処理エンティティ27は、ビデオエンコーダ20からの符号化ビデオデータを処理し得る、MANEまたはスプライシング/編集デバイスなど、ビデオエンティティの一例を表すものとする。いくつかの事例では、後処理エンティティ27はネットワークエンティティの一例であり得る。いくつかのビデオ符号化システムでは、後処理エンティティ27およびビデオエンコーダ20は別個のデバイスの一部であり得、他の事例では、後処理エンティティ27に関して説明する機能は、ビデオエンコーダ20を備える同じデバイスによって実行され得る。いくつかの例では、後処理エンティティ27は図1のストレージデバイス17の一例である。
[0130]ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディング、インターコーディング、およびIBCコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去するために空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間冗長性を低減または除去するために時間予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースの圧縮モードのいずれかを指すことがある。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指すことがある。IBCコーディングモードは、上記で説明したように、ビデオデータのフレームから空間冗長性を除去し得るが、従来のイントラモードとは異なり、IBCコーディングコードは、イントラ予測コーディングモードに依拠するのではなく、フレーム内のより大きい探索エリア中の予測ブロックの位置を特定し、オフセットベクトルを用いて予測ブロックを指すために使用され得る。
[0131]図15の例では、ビデオエンコーダ20は、ビデオデータメモリ33と、区分ユニット35と、予測処理ユニット41と、フィルタユニット63と、復号ピクチャバッファ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。予測処理ユニット41は、動き推定ユニット42と、動き補償ユニット44と、イントラ予測処理ユニット46と、IBCユニット48とを含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換処理ユニット60と、加算器62とを含む。フィルタユニット63は、デブロッキングフィルタ、適応ループフィルタ(ALF:adaptive loop filter)、およびサンプル適応オフセット(SAO:sample adaptive offset)フィルタなど、1つまたは複数のループフィルタを表すものとする。図15ではフィルタユニット63はループ内フィルタであるとして示されているが、他の構成では、フィルタユニット63はループ後フィルタとして実装され得る。
[0132]様々な例では、ビデオエンコーダ20の固定またはプログラマブルハードウェアユニットは、本開示の技法を実行する役割を担い得る。また、いくつかの例では、本開示の技法は、図15に示されているビデオエンコーダ20の図示された固定またはプログラマブルハードウェアユニットのうちの1つまたは複数の間で分割され得るが、他のデバイスも本開示の技法を実行し得る。たとえば、図15の例に従って、ビデオエンコーダ20のIBCユニット48は、単独で、または、動き推定ユニット42、動き補償ユニット44、イントラ予測処理ユニット46、およびエントロピー符号化ユニット56など、ビデオエンコーダ20の他のユニットと組み合わせて、本開示の技法を実行し得る。いくつかの例では、ビデオエンコーダ20はIBCユニット48を含まないことがあり、IBCユニット48の機能は、動き推定ユニット42および/または動き補償ユニット44など、予測処理ユニット41の他の構成要素によって実行され得る。
[0133]ビデオデータメモリ33は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオデータメモリ33に記憶されるビデオデータは、たとえば、ビデオソース18から取得され得る。復号ピクチャバッファ64は、たとえば、イントラコーディングモード、インターコーディングモード、またはIBCコーディングモードにおいてビデオエンコーダ20によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ33および復号ピクチャバッファ64は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗性RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなど、様々なメモリデバイスのうちのいずれかによって形成され得る。ビデオデータメモリ33および復号ピクチャバッファ64は、同じメモリデバイスまたは別個のメモリデバイスによって与えられ得る。様々な例では、ビデオデータメモリ33は、ビデオエンコーダ20の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
[0134]図15に示されているように、ビデオエンコーダ20はビデオデータを受信し、ビデオデータをビデオデータメモリ33に記憶する。区分ユニット35はデータをビデオブロックに区分する。この区分はまた、たとえば、LCUおよびCUの4分木構造に従って、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分を含み得る。ビデオエンコーダ20は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに(および、場合によっては、タイルと呼ばれるビデオブロックのセットに)分割され得る。予測処理ユニット41は、誤差結果(たとえば、コーディングレートおよびひずみレベル)に基づいて現在ビデオブロックのために、複数のイントラコーディングモードのうちの1つ、複数のインターコーディングモードのうちの1つ、または複数のIBCコーディングモードのうちの1つなど、複数の可能なコーディングモードのうちの1つを選択し得る。予測処理ユニット41は、得られたイントラコード化ブロック、インターコード化ブロック、またはIBCコード化ブロックを、残差ブロックデータを生成するために加算器50に与え、参照ピクチャとして使用するための符号化ブロックを再構成するために加算器62に与え得る。
[0135]予測処理ユニット41内のイントラ予測処理ユニット46は、空間圧縮を行うために、コーディングされるべき現在ブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対して現在ビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44は、時間圧縮を行うために、1つまたは複数の参照ピクチャ中の1つまたは複数の予測ブロックに対して現在ビデオブロックのインター予測コーディングを実行し得る。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44はまた、空間圧縮を行うために、同じピクチャ中の1つまたは複数の予測ブロックに対して現在ビデオブロックのIBCコーディングを実行し得る。
[0136]動き推定ユニット42は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードまたはIBCモードを決定するように構成され得る。所定のパターンは、シーケンス中のビデオスライスをPスライス、BスライスまたはGPBスライスに指定し得る。動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。IBCコーディングの場合、IBCにおいてオフセットベクトルと呼ばれることがある動きベクトルは、現在ビデオフレーム内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。IBCユニット48は、インター予測のための動き推定ユニット42による動きベクトルの決定と同様の様式で、IBCコーディングのためのベクトル、たとえば、ブロックベクトルを決定し得るか、またはブロックベクトルを決定するために動き推定ユニット42を利用し得る。
[0137]予測ブロックは、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのPUにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ20は、復号ピクチャバッファ64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置と分数ピクセル位置とに対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0138]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの各々が、復号ピクチャバッファ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56と動き補償ユニット44とに送る。
[0139]いくつかの例では、IBCユニット48は、動き推定ユニット42および動き補償ユニット44に関して上記で説明した様式と同様の様式で、ベクトルを生成し、予測ブロックをフェッチし得るが、予測ブロックは、現在ブロックと同じピクチャまたはフレーム中にあり、ベクトルは、動きベクトルの対語としてブロックベクトルと呼ばれる。他の例では、IBCユニット48は、本明細書で説明する技法に従ってIBC予測のためのそのような機能を実行するために、全体的にまたは部分的に、動き推定ユニット42および動き補償ユニット44を使用し得る。いずれの場合も、IBCでは、予測ブロックは、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックであり得、ブロックの識別は、サブ整数ピクセル位置のための値の計算を含み得る。
[0140]動き補償ユニット44によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを伴い得る。補間フィルタ処理は、既知のピクセルサンプルから追加のピクセルサンプルを生成し、したがって、ビデオブロックをコーディングするために使用され得る候補予測ブロックの数を潜在的に増加させ得る。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、動きベクトルが参照ピクチャリストのうちの1つにおいて指す、またはIBCコーディングの場合、コーディングされているピクチャ内の、予測ブロックの位置を特定し得る。ビデオエンコーダ20は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。ピクセル差分値は、ブロックの残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。動き補償ユニット44はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
[0141] イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測、またはIBCユニット48によって実行されるIBCの代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測処理ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測処理ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。たとえば、イントラ予測処理ユニット46は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット46は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化ブロックのひずみおよびレートから比を計算し得る。
[0142]いずれの場合も、ブロックのためのイントラ予測モードを選択した後に、イントラ予測処理ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に与え得る。エントロピー符号化ユニット56は、本開示の技法に従って、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを送信ビットストリーム中に含め得る。
[0143]予測処理ユニット41が、インター予測、イントラ予測、またはIBCのいずれかを介して、現在ビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ20は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、1つまたは複数のTU中に含まれ、変換処理ユニット52に適用され得る。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット52は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。
[0144]変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
[0145]量子化の後に、エントロピー符号化ユニット56は量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型バイナリ算術コーディング(CABAC)あるいは別のエントロピー符号化方法または技法を実行し得る。エントロピー符号化ユニット56によるエントロピー符号化の後に、符号化ビットストリームは、ビデオデコーダ30に送信されるか、あるいはビデオデコーダ30が後で送信するかまたは取り出すためにアーカイブされ得る。エントロピー符号化ユニット56はまた、コーディングされている現在ビデオスライスのための動きベクトルと他のシンタックス要素とをエントロピー符号化し得る。
[0146]逆量子化ユニット58および逆変換処理ユニット60は、参照ピクチャの参照ブロックとして後で使用するためにピクセル領域において残差ブロックを再構成するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット44は、残差ブロックを参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構成された残差ブロックに1つまたは複数の補間フィルタを適用し得る。補間フィルタ処理は、既知のピクセルサンプルから追加のピクセルサンプルを生成し、したがって、ビデオブロックをコーディングするために使用され得る候補予測ブロックの数を潜在的に増加させ得る。加算器62は、復号ピクチャバッファ64に記憶するための参照ブロックを生成するために、再構成された残差ブロックを動き補償ユニット44によって生成された動き補償予測ブロックに加算する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために、動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
[0147]ビデオエンコーダ20は、本開示の技法による、ビデオデータを符号化するように構成されたビデオエンコーダの一例を表す。たとえば、ビデオエンコーダ20は、WPPが有効化されてコーディングされる1つまたは複数のブロックのためのCTB遅延を決定し得る。CTB遅延は、たとえば、CTBの第1の行が復号され始めるときと、CTBの第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別し得る。イントラブロックコピー(IBC)モードにおいてコーディングされ、WPPが無効化されてコーディングされるビデオデータの第1のブロックのために、ビデオエンコーダ20は、CTB遅延に基づいて、第1のブロックのためのIBC予測領域を決定し得る。ビデオエンコーダ20は、第1のブロックのためのIBC予測領域内から、第1のブロックのための予測ブロックを識別し、予測ブロックの位置を特定するためのブロックベクトルを示すためのシンタックスを生成し得る。
[0148]図16は、本開示で説明する技法を実装し得る例示的なビデオデコーダ30を示すブロック図である。図16の例では、ビデオデコーダ30は、ビデオデータメモリ78と、エントロピー復号ユニット80と、予測処理ユニット81と、逆量子化ユニット86と、逆変換処理ユニット88と、加算器90と、フィルタユニット91と、復号ピクチャバッファ(DPB)92とを含む。予測処理ユニット81は、動き補償ユニット82と、イントラ予測処理ユニット84と、IBCユニット85とを含む。ビデオデコーダ30は、いくつかの例では、図15からのビデオエンコーダ20に関して説明した符号化パスとは概して逆の復号パスを実行し得る。
[0149]様々な例では、ビデオデコーダ30のユニットは、本開示の技法を実行する役割を担い得る。また、いくつかの例では、本開示の技法は、ビデオデコーダ30のユニットのうちの1つまたは複数の間で分割され得る。たとえば、IBCユニット85は、単独で、または、動き補償ユニット82、イントラ予測処理ユニット84、およびエントロピー復号ユニット80など、ビデオデコーダ30の他のユニットと組み合わせて、本開示の技法を実行し得る。いくつかの例では、ビデオデコーダ30はIBCユニット85を含まないことがあり、IBCユニット85の機能は、動き補償ユニット82など、予測処理ユニット81の他の構成要素によって実行され得る。
[0150]復号プロセス中に、ビデオデコーダ30は、ビデオデータ、たとえば、符号化ビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化ビデオビットストリームを、ビデオエンコーダ20から受信する。ビデオデコーダ30は、ビデオデータをネットワークエンティティ29から受信し、ビデオデータをビデオデータメモリ78に記憶し得る。ビデオデータメモリ78は、ビデオデコーダ30の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ78に記憶されたビデオデータは、たとえば、ストレージデバイス17から、たとえば、カメラなどのローカルビデオソースから、ビデオデータのワイヤードまたはワイヤレスネットワーク通信を介して、あるいは物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ78は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファを形成し得る。したがって、図16では別々に示されているが、ビデオデータメモリ78およびDPB92は、同じメモリデバイスまたは別々のメモリデバイスによって与えられ得る。ビデオデータメモリ78およびDPB92は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗性RAM(RRAM)、または他のタイプのメモリデバイスなど、様々なメモリデバイスのいずれかによって形成され得る。様々な例では、ビデオデータメモリ78は、ビデオデコーダ30の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
[0151]ネットワークエンティティ29は、たとえば、上記で説明した技法のうちの1つまたは複数を実装するように構成されたサーバ、MANE、ビデオエディタ/スプライサ、または他のそのようなデバイスであり得る。ネットワークエンティティ29は、ビデオエンコーダ20などのビデオエンコーダを含むことも、含まないこともある。本開示で説明する技法のうちのいくつかは、ネットワークエンティティ29が符号化ビデオビットストリームをビデオデコーダ30に送信するより前に、ネットワークエンティティ29によって実装され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ29およびビデオデコーダ30は別個のデバイスの部分であり得るが、他の事例では、ネットワークエンティティ29に関して説明する機能は、ビデオデコーダ30を備える同じデバイスによって実行され得る。ネットワークエンティティ29は、場合によっては、図1のストレージデバイス17の一例であり得る。
[0152]ビデオデコーダ30のエントロピー復号ユニット80は、量子化係数と、動きベクトルと、他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット80は、動きベクトルと他のシンタックス要素とを予測処理ユニット81に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0153]ビデオスライスがイントラコード化(I)スライスとしてコーディングされたとき、予測処理ユニット81のイントラ予測処理ユニット84は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化(すなわちBまたはP)スライスとしてコーディングされたときまたはブロックがIBCコーディングされたとき、予測処理ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルおよび他のシンタックス要素に基づいて現在ビデオスライスのビデオブロックのための予測ブロックを生成する。インター予測の場合、予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、DPB92に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0とリスト1とを構成し得る。IBCコーディングの場合、予測ブロックは、予測されているブロックと同じピクチャから生成され得る。
[0154]他の例では、ビデオブロックが、本明細書で説明するIBCモードに従ってコーディングされたとき、予測処理ユニット81のIBCユニット85は、エントロピー復号ユニット80から受信されたブロックベクトルおよび他のシンタックス要素に基づいて、現在ビデオブロックのための予測ブロックを生成する。予測ブロックは、ビデオエンコーダ20によって定義され、DPB92から取り出される現在ビデオブロックと同じピクチャ内の再構成された領域内にあり得る。
[0155]動き補償ユニット82および/またはIBCユニット85は、動きベクトルおよび他のシンタックス要素をパースすることによって現在ビデオスライスのビデオブロックのための予測情報を決定し得、復号されている現在ビデオブロックのための予測ブロックを生成するためにその予測情報を使用する。たとえば、動き補償ユニット82は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラ予測またはインター予測)と、インター予測スライスタイプ(たとえば、BスライスまたはPスライス)と、スライスの参照ピクチャリストのうちの1つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつかを使用する。
[0156]同様に、IBCユニット85は、現在ビデオブロックがIBCモードを使用して予測されたことと、ピクチャのどのビデオブロックが再構成された領域内にあり、DPB92に記憶されるべきであるかを示す構成情報と、スライスの各IBC予測ビデオブロックのためのブロックベクトルと、スライスの各IBC予測ビデオブロックのためのIBC予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつか、たとえば、フラグを使用し得る。
[0157]動き補償ユニット82はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット82は、参照ブロックのサブ整数ピクセルの補間値を計算するために、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット82は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するためにその補間フィルタを使用し得る。
[0158]逆量子化ユニット86は、ビットストリーム中で与えられ、エントロピー復号ユニット80によって復号された、量子化変換係数を逆量子化(inverse quantize)、すなわち、量子化解除(de-quantize)する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中の各ビデオブロックについてビデオエンコーダ20によって計算される量子化パラメータの使用を含み得る。逆変換処理ユニット88は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
[0159]動き補償ユニット82またはIBCユニット85が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後に、ビデオデコーダ30は、逆変換処理ユニット88からの残差ブロックを動き補償ユニット82によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器90は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、(コーディングループ内またはコーディングループ後のいずれかの)ループフィルタも、ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために使用され得る。フィルタユニット91は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなど、1つまたは複数のループフィルタを表すものとする。図16では、フィルタユニット91はループ内フィルタであるとして示されているが、他の構成では、フィルタユニット91はループ後フィルタとして実装され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶するDPB92に記憶される。DPB92は、図1のディスプレイデバイス32など、ディスプレイデバイス上での後の提示のために、復号されたビデオをも記憶するメモリの一部であり得るか、またはそのようなメモリとは別個であり得る。
[0160]ビデオデコーダ30は、本開示の技法による、ビデオデータを復号するように構成されたビデオデコーダの一例を表す。WPPが有効化されてコーディングされる1つまたは複数のブロックのために、ビデオデコーダ30は、CTBの第1の行が復号され始めるときと、CTBの第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、CTB遅延を決定する。CTB遅延は、たとえば、CTBの単位であり得る。IBCモードにおいてコーディングされ、WPPが無効化されてコーディングされるビデオデータの現在ブロックのために、ビデオデコーダ30は、WPPが有効化されてコーディングされる1つまたは複数のブロックのために決定されたCTB遅延に基づいて、現在ブロックを含むピクチャ内の現在ブロックのためのIBC予測領域を決定する。ビデオデコーダ30は、現在ブロックのための決定されたIBC予測領域内から、現在ブロックのための予測ブロックを識別し、予測ブロックに基づいて現在ブロックをIBC復号する。IBCモードにおいてコーディングされ、WPPが有効化されてコーディングされるビデオデータの第2のブロックのために、ビデオデコーダ30はまた、CTB遅延に基づいて、第2のブロックのためのIBC予測領域を決定し、第2のブロックのためのIBC予測領域内から、第2のブロックのための予測ブロックを識別し、予測ブロックに基づいて現在ブロックをIBC復号し得る。
[0161]ビデオデコーダ30は、たとえば、シンタックス要素(たとえば上記で説明したentropy_coding_sync_enabled)の値に基づいて、WPPが第1のブロックのために無効化されると決定し得る。シンタックス要素は、たとえば、コンテキスト変数のための特定の同期プロセスが呼び出されるべきであるかどうかを示す同期プロセス有効化シンタックス要素であり得る。
[0162]第1のブロックのためのIBC予測領域は、前に復号されたフィルタ処理されていないCTBを含み得る。追加または代替として、IBC予測領域は、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上に位置する、対角線方向に位置するCTBを含み得、対角線方向に位置するCTBの直下のCTBを除外する。対角線方向に位置するCTBのために、ビデオデコーダ30は、第1のブロックと並列に、対角線方向に位置するCTBの直下のCTBを復号し得る。
[0163]ビデオデコーダ30は、ビデオデータの符号化ビットストリーム中で、ビデオデータの第1のブロックのためのコーディングモードがIBCモードであることを示す1つまたは複数のシンタックス要素を受信し、ビデオデータの符号化ビットストリーム中で、ビデオデータの第1のブロックのためのブロックベクトルを識別する1つまたは複数のシンタックス要素を受信し得る。第1のブロックのためのIBC予測領域内から、第1のブロックのための予測ブロックを識別するために、ビデオデコーダ30は、ブロックベクトルを用いて予測ブロックの位置を特定し得る。
[0164]図17は、本開示の技法による、ビデオデータを符号化するための技法を示す流れ図である。図17の技法について、一般的なビデオエンコーダに関して説明する。一般的なビデオエンコーダは、ビデオエンコーダ20の特徴を組み込み得るか、またはビデオエンコーダの異なる構成であり得る。WPPが有効化されてコーディングされる1つまたは複数のブロックのために、ビデオエンコーダは、CTB遅延を決定する(300)。CTB遅延は、CTBの単位で、CTBの第1の行が復号され始めるときと、CTBの第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する。CTB遅延は、たとえば、1つのCTB、2つのCTB、または何らかの他のそのような遅延であり得る。IBCモードにおいてコーディングされ、WPPが無効化されてコーディングされるビデオデータの第1のブロックのために、ビデオエンコーダは、CTB遅延に基づいて、第1のブロックのためのIBC予測領域を決定する(302)。ビデオエンコーダは、第1のブロックのためのIBC予測領域内から、第1のブロックのための予測ブロックを識別し(304)、予測ブロックの位置を特定するためのブロックベクトルを示すためのシンタックスを生成する(306)。
[0165]IBCモードにおいてコーディングされ、WPPが有効化されてコーディングされるビデオデータの第2のブロックのために、ビデオエンコーダは、CTB遅延に基づいて、第2のブロックのためのIBC予測領域を決定し、第2のブロックのためのIBC予測領域内から、第2のブロックのための予測ブロックを識別し得る。IBC予測領域は、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上のCTBを含み、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上のCTBの直下のCTBを除外し得る。
[0166]図18は、本開示の技法による、ビデオデータを復号するための技法を示す流れ図である。図18の技法について、一般的なビデオデコーダに関して説明する。一般的なビデオデコーダは、ビデオデコーダ30の特徴を組み込み得るか、またはビデオデコーダの異なる構成であり得る。WPPが有効化されてコーディングされる1つまたは複数のブロックのために、ビデオデコーダは、CTB遅延を決定する(310)。CTB遅延は、CTBの単位で、CTBの第1の行が復号され始めるときと、CTBの第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する。CTB遅延は、たとえば、1つのCTB、2つのCTB、または何らかの他のそのような遅延であり得る。IBCモードにおいてコーディングされ、WPPが無効化されてコーディングされるビデオデータの第1のブロックのために、ビデオデコーダは、CTB遅延に基づいて、第1のブロックのためのIBC予測領域を決定する(312)。ビデオデコーダは、第1のブロックのためのIBC予測領域内から、第1のブロックのための予測ブロックを識別する(314)。ビデオデコーダ30は、予測ブロックに基づいて現在ブロックをIBC復号する(316)。
[0167]IBCモードにおいてコーディングされ、WPPが有効化されてコーディングされるビデオデータの第2のブロックのために、ビデオデコーダは、CTB遅延に基づいて、第2のブロックのためのIBC予測領域を決定し、第2のブロックのためのIBC予測領域内から、第2のブロックのための予測ブロックを識別する。ビデオデコーダは、さらに、シンタックス要素を受信し、シンタックス要素の値に基づいて、WPPが第1のブロックのために無効化されると決定する。シンタックス要素は、たとえば、コンテキスト変数のための特定の同期プロセスが呼び出されるべきであるかどうかを示す同期プロセス有効化シンタックス要素(たとえば上記で説明したentropy_coding_sync_enabled_flag)であり得る。
[0168]第1のブロックのためのIBC予測領域は、たとえば、前に復号されたフィルタ処理されていないCTBを含み得る。IBC予測領域は、たとえば、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上のCTBを含み得、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上のCTBの直下のCTBを除外する。ビデオデコーダは、第1のブロックの右側および第1のブロックの少なくとも2つまたはそれ以上の行上のCTBの直下のCTBを第1のブロックと並列に復号し得る。
[0169]ビデオデコーダは、さらに、ビデオデータの符号化ビットストリーム中で、ビデオデータの第1のブロックのためのコーディングモードがIBCモードであることを示す1つまたは複数のシンタックス要素を受信し、ビデオデータの符号化ビットストリーム中で、ビデオデータの第1のブロックのためのブロックベクトルを識別する1つまたは複数のシンタックス要素を受信し得る。第1のブロックのためのIBC予測領域内から、第1のブロックのための予測ブロックを識別するために、ビデオデコーダは、ブロックベクトルを用いて予測ブロックの位置を特定し得る。
[0170]1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
[0171]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlu-rayディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
[0172]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、あるいは他の等価な集積回路またはディスクリート論理回路など、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素で十分に実装され得る。
[0173]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置で実装され得る。本開示では、開示した技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明した1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合によって与えられ得る。
[0174]様々な例について説明した。これらおよび他の例は以下の特許請求の範囲内に入る。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビデオデータを復号する方法であって、前記方法は、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのために、コーディングツリーブロック(CTB)遅延を決定することと、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの現在ブロックのために、波面並列処理が有効化されてコーディングされる前記1つまたは複数のブロックのために決定された前記CTB遅延に基づいて、前記現在ブロックを含むピクチャ内の前記現在ブロックのためのIBC予測領域を決定することと、
前記現在ブロックのための前記決定されたIBC予測領域内から、前記現在ブロックのための予測ブロックを識別することと、
前記予測ブロックに基づいて前記現在ブロックをIBC復号することと
を備える、方法。
[C2]
前記現在ブロックが第1のブロックを備え、前記方法は、
前記IBCモードにおいてコーディングされ、波面並列処理が有効化されてコーディングされるビデオデータの第2のブロックのために、前記CTB遅延に基づいて、前記第2のブロックのためのIBC予測領域を決定することと、
前記第2のブロックのための前記IBC予測領域内から、前記第2のブロックのための予測ブロックを識別することと、
前記予測ブロックに基づいて前記現在ブロックをIBC復号することと
をさらに備える、C1に記載の方法。
[C3]
シンタックス要素を受信することと、
前記シンタックス要素の値に基づいて、波面並列処理が前記第1のブロックのために無効化されると決定することと
をさらに備える、C1に記載の方法。
[C4]
前記シンタックス要素は、コンテキスト変数のための特定の同期プロセスが呼び出されるべきであるかどうかを示す同期プロセス有効化シンタックス要素を備える、C3に記載の方法。
[C5]
前記第1のブロックのための前記IBC予測領域が、前に復号されたフィルタ処理されていないCTBを備える、C1に記載の方法。
[C6]
前記IBC予測領域が、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上に位置する、対角線方向に位置するCTBを含み、前記対角線方向に位置するCTBの直下のCTBを除外する、C1に記載の方法。
[C7]
前記第1のブロックと並列に、前記対角線方向に位置するCTBの直下の前記CTBを復号すること
をさらに備える、C6に記載の方法。
[C8]
前記CTB遅延が1つのCTBを備える、C1に記載の方法。
[C9]
前記CTB遅延が2つのCTBを備える、C1に記載の方法。
[C10]
ビデオデータの符号化ビットストリーム中で、ビデオデータの前記第1のブロックのためのコーディングモードが前記IBCモードであることを示す1つまたは複数のシンタックス要素を受信することと、
ビデオデータの前記符号化ビットストリーム中で、ビデオデータの前記第1のブロックのためのブロックベクトルを識別する1つまたは複数のシンタックス要素を受信することと、ここにおいて、前記第1のブロックのための前記IBC予測領域内から、前記第1のブロックのための前記予測ブロックを識別することが、前記ブロックベクトルを用いて前記予測ブロックの位置を特定することを備える、
をさらに備える、C1に記載の方法。
[C11]
前記CTB遅延を決定することが、CTBの単位で前記CTB遅延を決定することを備える、C1に記載の方法。
[C12]
ビデオデータを符号化する方法であって、前記方法は、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのためにコーディングツリーブロック(CTB)遅延を決定することと、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの第1のブロックのために、前記CTB遅延に基づいて、前記第1のブロックのためのIBC予測領域を決定することと、
前記第1のブロックのための前記IBC予測領域内から、前記第1のブロックのための予測ブロックを識別することと、
前記予測ブロックの位置を特定するためのブロックベクトルを示すためのシンタックスを生成することと
を備える、方法。
[C13]
前記IBCモードにおいてコーディングされ、波面並列処理が有効化されてコーディングされるビデオデータの第2のブロックのために、前記CTB遅延に基づいて、前記第2のブロックのためのIBC予測領域を決定することと、
前記第2のブロックのための前記IBC予測領域内から、前記第2のブロックのための予測ブロックを識別することと
をさらに備える、C12に記載の方法。
[C14]
前記IBC予測領域が、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上のCTBを含み、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上の前記CTBの直下のCTBを除外する、C12に記載の方法。
[C15]
前記CTB遅延が1つのCTBを備える、C12に記載の方法。
[C16]
前記CTB遅延が2つのCTBを備える、C12に記載の方法。
[C17]
ビデオ復号を実行するためのデバイスであって、前記デバイスが、
ビデオデータを記憶するためのメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのためにコーディングツリーブロック(CTB)遅延を決定することと、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの現在ブロックのために、波面並列処理が有効化されてコーディングされる前記1つまたは複数のブロックのために決定された前記CTB遅延に基づいて、前記現在ブロックを含むピクチャ内の前記現在ブロックのためのIBC予測領域を決定することと、
前記現在ブロックのための前記決定されたIBC予測領域内から、前記現在ブロックのための予測ブロックを識別することと、
前記予測ブロックに基づいて前記現在ブロックをIBC復号することと
を行うように構成された、
デバイス。
[C18]
前記現在ブロックが第1のブロックを備え、ここにおいて、前記1つまたは複数のプロセッサは、
前記IBCモードにおいてコーディングされ、波面並列処理が有効化されてコーディングされるビデオデータの第2のブロックのために、前記CTB遅延に基づいて、前記第2のブロックのためのIBC予測領域を決定することと、
前記第2のブロックのための前記IBC予測領域内から、前記第2のブロックのための予測ブロックを識別することと、
前記予測ブロックに基づいて前記現在ブロックをIBC復号することと
を行うようにさらに構成された、C17に記載のデバイス。
[C19]
前記1つまたは複数のプロセッサは、
シンタックス要素を受信することと、
前記シンタックス要素の値に基づいて、波面並列処理が前記第1のブロックのために無効化されると決定することと
を行うようにさらに構成された、C17に記載のデバイス。
[C20]
前記シンタックス要素は、コンテキスト変数のための特定の同期プロセスが呼び出されるべきであるかどうかを示す同期プロセス有効化シンタックス要素を備える、C19に記載のデバイス。
[C21]
前記第1のブロックのための前記IBC予測領域が、前に復号されたフィルタ処理されていないCTBを備える、C17に記載のデバイス。
[C22]
前記IBC予測領域が、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上に位置する、対角線方向に位置するCTBを含み、前記対角線方向に位置するCTBの直下のCTBを除外する、C17に記載のデバイス。
[C23]
前記1つまたは複数のプロセッサが、
前記第1のブロックと並列に、前記対角線方向に位置するCTBの直下の前記CTBを復号する
ようにさらに構成された、C22に記載のデバイス。
[C24]
前記CTB遅延が1つのCTBを備える、C17に記載のデバイス。
[C25]
前記CTB遅延が2つのCTBを備える、C17に記載のデバイス。
[C26]
前記1つまたは複数のプロセッサは、
ビデオデータの符号化ビットストリーム中で、ビデオデータの前記第1のブロックのためのコーディングモードが前記IBCモードであることを示す1つまたは複数のシンタックス要素を受信することと、
ビデオデータの前記符号化ビットストリーム中で、ビデオデータの前記第1のブロックのためのブロックベクトルを識別する1つまたは複数のシンタックス要素を受信することと、ここにおいて、前記第1のブロックのための前記IBC予測領域内から、前記第1のブロックのための前記予測ブロックを識別することが、前記ブロックベクトルを用いて前記予測ブロックの位置を特定することを備える、
を行うようにさらに構成された、C17に記載のデバイス。
[C27]
前記CTB遅延を決定するために、前記1つまたは複数のプロセッサが、CTBの単位で前記CTB遅延を決定するようにさらに構成された、C17に記載のデバイス。
[C28]
前記デバイスが、
集積回路、
マイクロプロセッサ、または
ディスプレイを備えるワイヤレス通信デバイス
のうちの少なくとも1つを備える、C17に記載のデバイス。
[C29]
ビデオ符号化を実行するためのデバイスであって、前記デバイスが、
ビデオデータを記憶するためのメモリと、
1つまたは複数のプロセッサと
を備え、前記1つまたは複数のプロセッサは、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのためにコーディングツリーブロック(CTB)遅延を決定することと、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの第1のブロックのために、前記CTB遅延に基づいて、前記第1のブロックのためのIBC予測領域を決定することと、
前記第1のブロックのための前記IBC予測領域内から、前記第1のブロックのための予測ブロックを識別することと、
前記予測ブロックの位置を特定するためのブロックベクトルを示すためのシンタックスを生成することと
を行うように構成された、
デバイス。
[C30]
前記1つまたは複数のプロセッサは、
前記IBCモードにおいてコーディングされ、波面並列処理が有効化されてコーディングされるビデオデータの第2のブロックのために、前記CTB遅延に基づいて、前記第2のブロックのためのIBC予測領域を決定することと、
前記第2のブロックのための前記IBC予測領域内から、前記第2のブロックのための予測ブロックを識別することと
を行うようにさらに構成された、C29に記載のデバイス。
[C31]
前記IBC予測領域が、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上のCTBを含み、前記第1のブロックの右側および前記第1のブロックの少なくとも2つまたはそれ以上の行上の前記CTBの直下のCTBを除外する、C29に記載のデバイス。
[C32]
前記CTB遅延が1つのCTBを備える、C29に記載のデバイス。
[C33]
前記CTB遅延が2つのCTBを備える、C29に記載のデバイス。
[C34]
前記デバイスが、
集積回路、
マイクロプロセッサ、または
カメラを備えるワイヤレス通信デバイス
のうちの少なくとも1つを備える、C33に記載のデバイス。
[C35]
ビデオデータを復号するための装置であって、前記装置は、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのためにコーディングツリーブロック(CTB)遅延を決定するための手段と、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの現在ブロックのために、波面並列処理が有効化されてコーディングされる前記1つまたは複数のブロックのために決定された前記CTB遅延に基づいて、前記現在ブロックを含むピクチャ内の前記現在ブロックのためのIBC予測領域を決定するための手段と、
前記現在ブロックのための前記決定されたIBC予測領域内から、前記現在ブロックのための予測ブロックを識別するための手段と、
前記予測ブロックに基づいて前記現在ブロックをIBC復号するための手段と
を備える、装置。
[C36]
1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
波面並列処理が有効化されてコーディングされる1つまたは複数のブロックのためにコーディングツリーブロック(CTB)遅延を決定することと、ここにおいて、前記CTB遅延は、CTBの第1の行が復号され始めるときと、CTBの前記第1の行の下のCTBの第2の行が復号され始めるときとの間の遅延を識別する、
イントラブロックコピー(IBC)モードにおいてコーディングされ、波面並列処理が無効化されてコーディングされるビデオデータの現在ブロックのために、波面並列処理が有効化されてコーディングされる前記1つまたは複数のブロックのために決定された前記CTB遅延に基づいて、前記現在ブロックを含むピクチャ内の前記現在ブロックのためのIBC予測領域を決定することと、
前記現在ブロックのための前記決定されたIBC予測領域内から、前記現在ブロックのための予測ブロックを識別することと、
前記予測ブロックに基づいて前記現在ブロックをIBC復号することと
を行わせる、命令を記憶するコンピュータ可読記憶媒体。