[0030] 本開示は、マージ候補リスト、AMVPリスト、およびイントラMPMリストといった候補リストの構築のための優先度または挿入順序を決定するために、現在ブロックと隣接ブロックとの間のジオメトリ情報に基づいて優先度を導入することによって、ビデオコーデックにおける候補リストの構築およびコンテキストモデル化を改善するように使用され得る技法を説明する。さらに、このジオメトリ情報は、CABACコーディングのためのコンテキストの決定に使用され得る。複数の候補(たとえば、マージ候補、最も可能性のある(most probable)イントラモード候補)の順序は、ジオメトリ優先度によって適応する形で(adaptively)決定され得る。それは、HEVCの拡張版またはビデオコーディング規格の次世代版といったアドバンスドビデオコーデックのコンテキストで使用され得る。
[0031] ビデオコーディング規格は、ITU−T H.261、ISO/IEC MPEG−1ビジュアル、ITU−T H.262またはISO/IEC MPEG−2ビジュアル、ITU−T H.263、ISO/IEC MPEG−4ビジュアル、およびITU−T H.264(ISO/IEC MPEG−4AVCとしても知られている)を含み、そのSVC(Scalable Video Coding)およびMVC(MultiView Video Coding)拡張版も含む。MVCの最新の共同ドラフトは、2010年3月付のITU−T勧告H.264「Advanced video coding for generic audiovisual services」で説明されている。
[0032] 加えて、新たに開発されたビデオコーディング規格、即ち、ITU−TのJCT−VC(Joint Collaboration Team on Video Coding)、VCEG(Video Coding Experts Group)、およびISO/IEC MPEG(Motion Picture Experts Group)によって開発された高効率ビデオコーディング(HEVC:High Efficiency Video Coding)が存在する。最新のHEVCドラフト仕様は、以下ではHEVC WDと称されており、phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1から入手可能である。HEVC規格は、IEEE Transactions on Circuits and Systems for Video Technology(IEEE)22巻12号のG.J.Sullivan、J.-R.Ohm、W.-J.Han、T.Wiegand(2012年12月付)による「Overview of the High Efficiency Video Coding (HEVC) Standard」(PDF)で完結されている(has been finalized)。
[0033] ITU−T VCEG(Q6/16)およびISO/IEC MPEG(JTC 1/SC29/WG11)は、現在のHEVC規格(スクリーンコンテンツコーディングおよび高ダイナミックレンジコーディングについてのその現在の拡張版および近い未来の拡張版を含む)の圧縮能力を著しく上回る圧縮能力をもつ将来的なビデオコーディング技術の標準化を求める潜在的なニーズを今研究している。該団体は、この領域のエキスパートによって提案された圧縮技術設計を評価するために、JVET(Joint Video Exploration Team)として知られている共同の試みでこの調査活動に関して協力し合っている。JVETが最初に集ったのは2015年10月19日〜21日の間である。そして、参照ソフトウェアの最新バージョン、即ちJEM3(Joint Exploration Model 3)は、jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16. 6-JEM-3.0/からダウンロードされ得るだろう。JEM3についてのアルゴリズムの説明は、JVET−C1001のJ.Chen,E.Alshina,G.J.Sullivan,J.-R.Ohm,J.Boyce(サンディエゴ、2016年3月)による「Algorithm description of Joint Exploration Test Model 3」で説明されている。
[0034] 各ブロックについて、1セットの動き情報が利用可能であり得る。1セットの動き情報は、前方予測方向および後方予測方向についての動き情報を保有する。ここで、前方予測方向および後方予測方向は、現在のピクチャまたはスライスの参照ピクチャリスト0(RefPicList0)および参照ピクチャリスト1(RefPicList1)に対応する2つの予測方向である。「前方」および「後方」という用語は、必ずしもジオメトリな意味を有するわけではない。代わりに、どの参照ピクチャリストに動きベクトルが基づくかを区別するために、それらは使用される。前方予測は、参照リスト0に基づいて形成された予測を意味し、それに対して後方予測は、参照リスト1に基づいて形成された予測を意味する。参照リスト0と参照リスト1との両方が所与のブロックについて予測を形成するために使用されるケースでは、それは双方向予測と呼ばれる。
[0035] 所与のピクチャまたはスライスについて、1つの参照ピクチャリストのみが使用される場合、ピクチャまたはスライス内部の全てのブロックが前方予測される。所与のピクチャまたはスライスについて両方の参照ピクチャリストが使用される場合、ピクチャまたはスライス内部のブロックは前方予測され得るか、または後方予測され得るか、または双方向予測され得る。
[0036] 各予測方向について、動き情報は、参照インデックスおよび動きベクトルを保有する。参照インデックスは、対応する参照ピクチャリスト(たとえば、RefPicList0またはRefPicList1)中の参照ピクチャを識別するために使用される。動きベクトルは水平成分と垂直成分との両方を有し、その各々が水平方向および垂直方向それぞれに沿ったオフセット値を示す。いくつかの説明では、簡潔さのために、「動きベクトル」という言葉が、動きベクトルとそれに関連する参照インデックスとの両方を示すために、動き情報と交換可能に使用され得る。
[0037] ピクチャ順序カウント(POC:picture order count)が、ピクチャの表示順序を識別するためにビデオコーディング規格で広く使用されている。1つのコーディングされたビデオシーケンス内の2つのピクチャが同じPOC値を有し得るケースが存在するけれども、それは通常、1つのコーディングビデオシーケンス内では起こらない。複数のコーディングされたビデオシーケンスが1つのビットストリームに存在するとき、POCの同じ値をもつピクチャは、復号順序の観点から互いにより近くにあり得る。
[0038] ピクチャのPOC値は通常、参照ピクチャリスト構築、HEVCにあるような参照ピクチャセットの導出、および動きベクトルスケーリングに使用される。
[0039] IEEE Transactions on Circuits and Systems for Video Technology13巻7号のWiegand,Thomas、Sullivan,Gary J、Bjontegaard,Gisle、Luthra,Ajay(2003年7月付)による「Overview of the H.264/AVC Video Coding Standard」(PDF)のH.264/AVC(アドバンスドビデオコーディング)では、各インターマクロブロックは、4つの異なる方法に分割され得る:
・1つの16x16MB区分
・2つの16x8MB区分
・2つの8x16MB区分
・4つの8x8MB区分
[0040] 1つのMB中の異なるMB区分が、方向(RefPicList0またはRefPicList1)毎に異なる参照インデックス値を有し得る。1つのMBが4つの8x8MB区分に分割されないとき、それは各方向においてMB区分毎に1つの動きベクトルのみを有する。1つのMBが4つの8x8MB区分に分割されるとき、各8x8MB区分はサブブロックにさらに分割され得、該サブブロックの各々が各方向に異なる動きベクトルを有し得る。8x8MB区分からサブブロックを得るためには4つの異なる方法が存在する:
・1つの8x8サブブロック
・2つの8x4サブブロック
・2つの4x8サブブロック
・4つの4x4サブブロック
[0041] 各サブブロックは、各方向に異なる動きベクトルを有し得る。したがって、動きベクトルは、サブブロックと等しいかまたはより高いレベルに存在する。
[0042] AVCでは、時間ダイレクトモードが、BスライスにおけるスキップまたはダイレクトモードのためにMBレベルまたはMB区分レベルのどちらかにおいてイネーブルにされ得る。各MB区分について、現在ブロックのRefPicList1[0]中の現在のMB区分とコロケートされたブロックの動きベクトルが、動きベクトルを導出するために使用される。コロケートされたブロックにおける各動きベクトルは、POCの距離に基づいてスケーリングされる。
[0043] AVCでは、空間ダイレクトモードもまた、空間的隣接から動き情報を予測するために使用され得る。
[0044] HEVCでは、スライス中の最大符号化ユニットは、符号化ツリーブロック(CTB)または符号化ツリーユニット(CTU)と呼ばれる。CTBは四分木を保有し、そのノードは符号化ユニット(CU)である。
[0045] CTBのサイズは、(厳密には、8x8CTBサイズはサポートされ得るが)HEVCメインプロファイルでは16x16〜64x64の範囲に及び得る。符号化ユニット(CU)は、CTBの同じサイズであり得るが、8x8程に小さくあり得るだろう。各符号化ユニットは1つのモードを用いてコーディングされる。CUがインターコーディングされるとき、それは2つまたは4つの予測ユニット(PU)にさらに分割され得るか、またはさらなる分割が適用されないときはたった1つのPUになり得る。1つのCUに2つのPUが存在するとき、それらは、ハーフサイズの矩形であり得るか、またはCUの1/4サイズまたは3/4サイズの2つの矩形サイズであり得る。
[0046] CUがインターコーディングされるとき、1セットの動き情報が各PUに存在する。加えて、各PUは、該1セットの動き情報を導出するために、一意のインター予測モードを用いてコーディングされる。
[0047] HEVC規格では、1つの予測ユニット(PU)に対してそれぞれ、マージモード(スキップはマージの特別なケースと見なされる)および高度動きベクトル予測(AMVP)モードと名付けられた、2つのインター予測モードが存在する。
[0048] AMVPモードまたはマージモードのどちらでも、動きベクトル(MV)候補リストが、複数の動きベクトル予測子のために維持される。現在のPUの(1つまたは複数の)動きベクトル、およびマージモードでの参照インデックスが、MV候補リストから1つの候補を取ることによって生成される。
[0049] MV候補リストは、マージモードについては最大5つの候補を、およびAMVPモードについては2つの候補のみを保有する。マージ候補は、動き情報のセット、たとえば両方の参照ピクチャリスト(リスト0およびリスト1)に対応する動きベクトル、ならびに参照インデックスを保有し得る。マージ候補がマージインデックスによって識別される場合、参照ピクチャが現在ブロックの予測に使用され、同様に、関連する動きベクトルが決定される。しかしながら、リスト0またはリスト1のどちらかからの各潜在的な予測方向についてのAMVPモード下では、AMVP候補が1つの動きベクトルのみを保有するので、MV候補リストへの1つのMVPインデックスと共に、1つの参照インデックスが明示的にシグナリングされる必要がある。AMVPモードでは、予測された動きベクトルが、さらに補正され得る。
[0050] 上記から分かるように、マージ候補が動き情報の完全なセットに対応するのに対し、AMVP候補は、特定の予測方向についてのたった1つの動きベクトルおよび1つの参照インデックスを保有する。つまり一般に、動き情報は、動きベクトル予測子、参照ピクチャリスト、参照ピクチャリスト中へのインデックス、およびAMVPのケースでは動きベクトル予測子に適用されるべき差分を含む。HEVCにしたがうと、マージモードでは、動きベクトル、参照ピクチャリスト、およびインデックスが選択された候補から引き継がれるのに対し、AMVPでは、動きベクトル予測子が選択された候補の動きベクトルに対応し、参照ピクチャリスト、インデックス、および動きベクトル差分値がシグナリングされる。
[0051] 両方のモードについての候補が、同じ空間的および時間的隣接ブロックから同様に導出される。
[0052] 図1は、HEVCにおける空間的隣接候補を例示する概念図である。空間MV候補は、特定のPU(PU0)について、図1で示されている隣接ブロックから導出されるが、ブロックから候補を生成する方法は、マージモードとAMVPモードとでは異なる。
[0053] マージモードでは、最大4つの空間MV候補が、番号付きで図1(a)に示されている順序で導出され得、順序は、図1(a)で示されているように、以下:左(0、A1)、上(1、B1)、右上(2、B0)、左下(3、A0)、および左上(4、B2)である。
[0054] マージモードでは、最大4つの空間MV候補が、番号付きで図1(a)で示されている順序で導出され得、順序は、図1(a)で示されているように、以下:左(0、A1)、上(1、B1)、右上(2、B0)、左下(3、A0)、および左上(4、B2)である。つまり図4(a)では、ブロック100は、PU0 104AおよびPU1 104Bを含む。ビデオコーダ(たとえば、ビデオエンコーダまたはビデオデコーダ)が、マージモードを使用してPU0 104Aについての動き情報をコーディング(符号化または復号)することになるとき、ビデオコーダは、空間的隣接ブロック108A、108B、108C、108D、および108Eからの動き情報を、その順序で候補リストに加える。ブロック108A、108B、108C、108D、および108Eはまた、HEVCにおけるように、ブロックA1、B1、B0、A0、およびB2ともそれぞれ称され得る。
[0055] AVMPモードでは、隣接ブロックは、図1(b)に示されているように、2つのグループ:ブロック0および1を含む左グループ、ならびにブロック2、3、および4を含む上グループに分割される。これらのブロックは、図1(b)において、ブロック110A、110B、110C、110D、および110Eとそれぞれラベル付けされる。特に図1(b)では、ブロック102は、PU0 106AおよびPU1 106Bを含み、ブロック110A、110B、110C、110D、および110Eは、PU0 106Aに対する空間的隣接を表す。各グループについて、シグナリングされた参照インデックスによって示されたものと同じ参照ピクチャを指す隣接ブロックにおける潜在的な候補が、グループの最終的な候補を形成するために選ばれるための最高の優先度を有する。全ての隣接ブロックが同じ参照ピクチャを指す動きベクトルを保有しないこともあり得る。したがって、そのような候補が発見できない場合、最初に利用可能な候補が最終的な候補を形成するためにスケーリングされることになり、したがって、時間的な距離差分が補償され得る。
[0056] 図2は、HEVCにおける時間動きベクトル予測を例示する概念図である。特に図2(a)は、PU0 122AおよびPU1 122Bを含む例となるCU120を例示している。PU0 122Aは、PU 122Aについての中央ブロック126およびPU0 122Aに対する右下ブロック124を含む。図2(a)はまた、外部ブロック128を示し、それについての動き情報が、以下で説明されるように、PU0 122Aの動き情報から予測され得る。図2(b)は、現在ブロック138を含む現在のピクチャ130を例示しており、現在ブロック138についての動き情報が予測されることになる。特に図2(b)は、現在のピクチャ130に対するコロケートされたピクチャ134(現在ブロック138に対するコロケートされたブロック140を含む)、現在の参照ピクチャ132、およびコロケートされた参照ピクチャ136を例示している。コロケートされたブロック140は、動きベクトル144を使用して予測され、該動きベクトル144は、ブロック138の動き情報についての時間動きベクトル予測子(TMVP)142として使用される。
[0057] TMVPが有効にされ、TMVP候補が利用可能である場合、ビデオコーダは、任意の空間動きベクトル候補の後に、TMVP候補(たとえば、TMVP候補142)をMV候補リスト中に加え得る。TMVP候補についての動きベクトル導出のプロセスは、マージモードとAMVPモードとの両方について同じである。しかしながら、マージモードにおけるTMVP候補についてのターゲット参照インデックスは、HEVCにしたがうと、0に設定される。
[0058] TMVP候補導出のためのプライマリブロック位置は、空間的隣接候補を生成するために使用される上ブロックおよび左ブロックに対するバイアスを補償するために、図2(a)でPU0 122Aに対するブロック124として示されているようなコロケートされたPU外部の右下ブロックである。しかしながら、ブロック124が現在のCTBの行の外部に位置するか、または動き情報がブロック124について利用可能でない場合、該ブロックは、図2(a)で示されているようなPUの中央ブロック126と置き換えられる。
[0059] TMVP候補142についての動きベクトルは、スライスレベル情報で示されるような、コロケートされたピクチャ134のコロケートされたブロック140から導出される。コロケートされたPUについての動きベクトルは、コロケートされたMVと呼ばれる。
[0060] AVCにおける時間ダイレクトモードと同様に、TMVP候補の動きベクトルは動きベクトルスケーリングされやすく、動きベクトルスケーリングは、現在のピクチャ130と現在の参照ピクチャ132との間、およびコロケートされたピクチャ134と、コロケートされた参照ピクチャ136との間のピクチャ順序カウント(POC)距離の差分および/または時間距離距離(temporal distance distances)を補償するために実行される。つまり動きベクトル144は、これらのPOC/時間距離差分に基づいて、TMVP候補142を作り出すためにスケーリングされ得る。
[0061] マージモードおよびAMVPモードのいくつかの態様は、以下の通り、言及するに値する。
[0062] 動きベクトルスケーリング:動きベクトルの値が、提示時間(presentation time)におけるピクチャの距離に比例することが前提とされる。動きベクトルが2つのピクチャ、即ち参照ピクチャおよび動きベクトルを保有するピクチャ(即ち保有ピクチャ(the containing picture))を関連付ける。動きベクトルが他の動きベクトルを予測するために利用されるとき、保有ピクチャと参照ピクチャとの距離が、ピクチャ順序カウント(POC)値に基づいて計算される。
[0063] 動きベクトルが予測されるために、それに関連する保有ピクチャと参照ピクチャとの両方が異なり得る。したがって、(POCに基づく)新たな距離が計算される。そして動きベクトルは、これらの2つのPOC距離に基づいてスケーリングされる。空間的隣接候補では、2つの動きベクトルのための保有ピクチャは同じであるが、参照ピクチャは異なる。HEVCでは、空間的および時間的隣接候補について、動きベクトルスケーリングがTMVPとAMVPとの両方に適用される。
[0064] 疑似(artificial)動きベクトル候補生成:動きベクトル候補リストが完成していない場合、リストが全ての候補を有するまで、疑似動きベクトル候補が生成され、リストの末尾に挿入される。
[0065] マージモードでは、2つのタイプの疑似MV候補:Bスライスのためだけに導出された結合候補(combined candidate)と、1つ目のタイプが十分な疑似候補を提供しない場合にAMVPにのみ使用されるゼロ候補とが存在する。
[0066] 候補リスト中に既に存在し、必要な動き情報を有する候補の各ペアでは、双方向結合動きベクトル候補が、リスト0中の1つのピクチャを指す第1の候補の動きベクトルと、リスト1中の1つのピクチャを指す第2の候補の動きベクトルとの結合によって導出される。
[0067] 候補挿入のためのプルーニング(pruning)プロセス:異なるブロックからの候補が偶然同じであり得、このことは、マージ/AMVP候補リストの効率を下げる。プルーニングプロセスが、この問題を解決するために適用される。それは、ある特定の範囲で同一の候補を挿入するのを避けるために、現在の候補リスト中で1つの候補を他の候補に対して比較する。複雑性を低減するために、各潜在的な候補を全ての他の既存の候補と比較するのではなく、限られた数のプルーニングプロセスのみが適用される。
[0068] 図3は、3D−HEVCについての例となる予測構造を例示する。3D−HEVCは、JCT−3Vによって開発中のHEVCの3Dビデオ拡張である。3D−HEVCは、JCT−3VのGerhard Tech、Krzysztof Wegner、Ying Chen、Sehoon Yea(2015年2月18日付)による「3D-HEVC Draft Text 7」で説明されている。本開示の技法に関連するある特定の技法が、以下の図3および図4に関係して説明される。
[0069] 図3は、3つのビューのケースについてのマルチビュー予測構造を示す。V3はベースビューを表し、非ベースビュー(V1またはV5)中のピクチャは、同じ時間インスタンスの依存(ベース)ビュー中のピクチャから予測され得る。
[0070] (再構築されたサンプルからの)ビュー間サンプル予測がMV−HEVCにおいてサポートされ、その典型的な予測構造が図3で示されていることは言及に値する。
[0071] MV−HEVCと3D−HEVCとの両方が、ベース(テクスチャ)ビューがHEVC(バージョン1)デコーダによって復号可能である点で、HEVCと互換性がある。
[0072] MV−HEVCでは、非ベースビュー中の現在のピクチャは、同じビュー中のピクチャと、同じ時間インスタンスの参照ビュー中のピクチャとの両方によって、これらのピクチャの全てを該ピクチャの参照ピクチャリストに入れることで予測され得る。したがって、現在のピクチャの参照ピクチャリストは、時間参照ピクチャ(temporal reference picture)とビュー間参照ピクチャ(inter-virw reference picture)との両方を保有する。
[0073] 時間参照ピクチャに対応する参照インデックスに関連付けられた動きベクトルは、時間動きベクトル(temporal motion vector)として表される。
[0074] ビュー間参照ピクチャに対応する参照インデックスに関連付けられた動きベクトルは、視差動きベクトルとして表される。
[0075] 3D−HEVCは、MV−HEVCにおける全ての特徴をサポートする。したがって、上で言及されたようなビュー間サンプル予測がイネーブルにされる。
[0076] 加えて、より高度なテキスチャオンリコーディングツールおよび深度関連/依存コーディングツールがサポートされる。
[0077] テキスチャオンリコーディングツールはしばしば、同じオブジェクトに属し得る(ビュー間で)対応するブロックの識別を必要とする。したがって、視差ベクトル導出は、3D−HEVCにおけるベース技術である。
[0078] (再構築されたサンプルからの)ビュー間サンプル予測はMV−HEVCにおいてサポートされ、その典型的な予測構造は図5で示される。
[0079] 図4は、3D−HEVCにおけるサブPUベースのビュー間動き予測を例示する概念図である。図4は、現在のビュー(V1)の現在のピクチャ160および参照ビュー(V0)でのコロケートされたピクチャ162を示す。現在のピクチャ160は、4つのサブPus166A〜166D(サブPU166)を含む現在のPU164を含む。それぞれの視差ベクトル174A〜174D(視差ベクトル174)は、コロケートされたピクチャ162中のサブPU166に対応するサブPU168A〜168Dを識別する。3D−HEVCにおける、ビュー間マージ候補、即ち参照ビュー中の参照ブロックから導出された候補についてのサブPUレベルのビュー間動き予測方法。
[0080] そのようなモードがイネーブルにされたとき、現在のPU164は、参照ビューでの参照エリア(現在のPUと同じサイズが視差ベクトルによって識別される)に対応し得、該参照エリアは、通常PUについての1セットの動き情報を生成するのに必要とされるよりも豊富な動き情報を有し得る。したがって、図4で示されるように、サブPUレベルのビュー間動き予測(SPIVMP)方法が使用され得る。
[0081] このモードはまた、特別なマージ候補としてもシグナリングされ得る。サブPUの各々が、完全な動き情報のセットを保有する。したがって、PUは、動き情報の複数のセットを保有し得る。
[0082] 同様に、3D−HEVCの深度コーディングにおいて、テクスチャビューから導出された動きパラメータ継承(MPI:Motion Parameter Inheritance)候補もまた、サブPUレベルのビュー間動き予測と同様の形で拡張され得ることが設計される。
[0083] たとえば、現在の深度PUが、複数のPUを保有するコロケートされた領域を有する場合、該現在の深度PUはサブPUに分割され得、その各々は、動き情報の異なるセットを有し得る。
[0084] この方法は、サブPU MPIと呼ばれる。
[0085] 例となる2DビデオコーディングのためのサブPUに関連する技法が、米国出願第14/497,128号で説明されており、その全体が、本明細書に参照により組み込まれている。米国出願第14/497,128号では、サブPUベースの高度TMVP(ATMVP)設計が提案されている。
[0086] 単層コーディングでは、2段階の高度時間動きベクトル予測子設計が提案される。第1段階は、参照ピクチャにおける現在の予測ユニット(PU)の対応するブロックを識別するベクトルを導出するために利用され、第2段階は、該対応するブロックから動き情報の複数のセットを抽出し、それらをPUのサブPUに割り当てることとする。したがってPUの各サブPUは、別個に動き補償される。ATMVPのコンセプトは以下の通りに要約される:(1)第1段階におけるベクトルは、現在のPUの空間的および時間的隣接ブロックから導出され得る。(2)このプロセスは、全ての他のマージ候補のうちから1つのマージ候補をアクティブにするときに達成され得る。
[0087] 単層コーディングおよびサブPU時間動きベクトル予測に適用可能、PUまたはCUは、予測子に加えて(on top of)伝達されるべき動きリファインメント(refinement)データを有し得る。
[0088] 米国出願第14/497,128号のいくつかの設計態様が以下の通りにハイライトされる:
1.ベクトル導出の第1段階はまた、0ベクトルのみによって簡略化され得る。
2.ベクトル導出の第1段階は、動きベクトルとそれに関連するピクチャとを合わせて識別することを含み得る。関連するピクチャを選択し、動きベクトルを第1段階のベクトルであるとさらに決める様々な方法が提案されている。
3.上記プロセス中の動き情報が利用可能でない場合、「第1段階のベクトル」は代用(substitution)に使用される。
4.時間的隣接から識別される動きベクトルは、TMVPにおける動きベクトルスケーリングと同様の形で、現在のサブPUに使用されるようにスケーリングされなければならない。しかしながら、そのような動きベクトルがどの参照ピクチャにスケーリングされ得るかは、以下の方法のうちの1つで設計され得る:
a.ピクチャは、現在のピクチャの固定の参照インデックスによって識別される。
b.ピクチャは、現在のピクチャの参照ピクチャリストにおいても利用可能である場合、対応する時間的隣接の参照ピクチャであると識別される。
c.ピクチャは、第1段階で、動きベクトルが獲得されるところから(from where the motion vectors are grabbed from)識別される、コロケートされたピクチャであると設定される。
[0089] 米国出願第14/497,128号におけるいくつかの設計課題に対処するために、以下の技法が米国出願第15/005,564号において提案されており、その内容全体が、本明細書に参照により組み込まれている:
1.たとえばマージ候補リストとして挿入される場合、ATMVP候補の位置は、
a.空間候補およびTMVP候補が、ある特定の順序でマージ候補リストに挿入されることを前提とする。ATMVP候補は、それらの候補の任意の相対的に固定の位置に挿入され得る。
i.一代替例では、たとえば、ATMVP候補は、マージ候補リスト中に、最初の2つの空間候補、たとえばA1およびB1の後に、挿入され得る。
ii.一代替例では、たとえば、最初の3つの空間候補、たとえばA1およびB1およびB0の後に、ATMVP候補が挿入され得る。
iii.一代替例では、たとえば、最初の4つの候補、たとえばA1、B1、B0、およびA0の後に、ATMVP候補が挿入され得る。
iv.一代替例では、たとえば、TMVP候補の直前に、ATMVP候補が挿入され得る。
v.一代替例では、たとえば、TMVP候補の直後に、ATMVP候補が挿入され得る。
b.代わりとして、候補リスト中のATMVP候補の位置が、ビットストリームにおいてシグナリングされ得る。TMVP候補を含む他の候補の位置も、加えてシグナリングされ得る。
2.ATMVP候補の利用可能性検査が、たった1セットの動き情報にアクセスすることによって適用できる。そのようなセットの情報が利用可能でない、たとえば1つのブロックがイントラコーディングされるとき、全ATMVP候補が利用可能でないと見なされる。そのケースでは、ATMVPはマージリスト中に挿入されない。
a.中央位置または中央サブPUが、ATMVP候補の利用可能性を純粋に検査するために使用される。中央サブPUが使用されるとき、該中央サブPUは中央の位置をカバーするものになるように選択される(たとえば、PUの左上のサンプルに対して相対的な座標(W/2,H/2)をもつ中央3位置、ここにおいて、WxHはPUのサイズである)。そのような位置または中央サブPUは、動きソースピクチャ中の対応するブロックを識別するために時間ベクトルと共に使用され得る。対応するブロックの中央位置をカバーするブロックからの動き情報のセットが識別される。
3.サブPUからATMVPコーディングされたPUについての代表的な動き情報のセット。
a.ATMVP候補を形成するために、代表的な動き情報のセットが最初に形成される。
b.そのような代表的な動き情報のセットは、固定の位置または固定のサブPUから導出され得る。それは、箇条書き2.で説明されたようなATMVP候補の利用可能性を決定するために使用された動き情報のセットのものと同じ方法で選ばれ得る。
c.サブPUがそれ自体の動き情報のセットを識別して、それが利用可能でないとき、それは代表的な動き情報のセットに等しくなるように設定される。
d.代表的な動き情報のセットがサブPUのものになるように設定される場合、最悪ケースのシナリオでは、現在のCTUまたはスライスについてさらなる動き記憶がデコーダ側で必要とされない。
e. 復号プロセスが1セットの動き情報によってPU全体が表されることを必要とするとき、全てのシナリオにおいて、そのような代表的な動き情報のセットは使用され、プルーニングを含め、該プロセスが結合双予測マージ候補を生成するために使用される。
4.ATMVP候補はTMVP候補を用いてプルーニングされ、TMVPとATMVPとの間の相互作用が考慮され得る:詳細な技法が以下に挙げられる。
a.サブPUベースの候補、たとえばATMVP候補、の通常の候補を用いたプルーニングが、そのようなサブPUベースの候補についての(箇条書き3.にあるような)代表的な動き情報のセットを使用することによって行われ得る。そのような動き情報のセットが通常のマージ候補と同じである場合、2つの候補は同じと見なされる。
b.代わりとして、加えて、ATMVPが複数のサブPusについての複数の異なるセットの動き情報を保有するかどうかを決定するために、検査が行われる;もし2つの異なるセットが識別された場合、サブPUベースの候補はプルーニングに使用されず、これは即ち、任意の他の候補に対しても異なると見なされる。そうでない場合、それはプルーニングに使用され得る(たとえば、プルーニングプロセス中にプルーニングされ得る)。
c.代わりとして、加えて、ATMVP候補は、A1およびB1で表されている位置にある空間候補、たとえば左および上の候補のみ、を用いてプルーニングされ得る。
d.代わりとして、ATMVP候補またはTMVP候補のどちらかである、1つの候補のみが時間参照から形成される。ATMVPが利用可能であるとき、候補はATMVPであり、そうでなければ候補はTMVPである。そのような候補は、TMVPの位置と同様の位置でマージ候補リスト中に挿入される。このケースでは、最大数の候補が変化されないまま維持され得る。
i.代わりとして、TMVPは、ATMVPが利用可能でないときでさえ、常にディセーブルにされている。
ii.代わりとして、TMVPは、ATMVPが利用可能でないときにのみ使用される。
e.代わりとして、ATMVPが利用可能であり、かつTMVPが利用可能でないとき、1つのサブPUの1セットの動き情報がTMVP候補として使用される。このケースではさらに、ATMVPとTMVPとの間のプルーニングプロセスは適用されない。
f.代わりとして、または加えて、ATMVPに使用される時間ベクトルはまた、TMVPにも使用され得、よって、HEVCにおける現在のTMVPに使用されるような右下位置または中央3位置が使用される必要がない。
i.代わりとして、時間ベクトルによって識別される位置と、右下および中央3位置とは合わせて、利用可能なTMVP候補を提供すると見なされる。
5.ATMVP候補がより正確で効率的になる可能性をより高くする(give higher chances)ために、ATMVPのための複数の利用可能性検査がサポートされる。(たとえば、図9で示されるような)第1の時間ベクトルによって識別されるような動きソースピクチャからの現在のATMVP候補が利用可能でないとき、他のピクチャが動きソースピクチャと見なされ得る。別のピクチャが考慮されるとき、それは、異なる第2の時間ベクトルに関連付けられ得るか、または利用可能でないATMVP候補を指す第1の時間ベクトルからスケーリングされた第2の時間ベクトルに単に関連付けられ得る。
a.第2の時間ベクトルは、第2の動きソースピクチャ中のATMVP候補を識別し得、同じ利用可能性検査が適用され得る。第2の動きソースピクチャから導出されるようなATMVP候補が利用可能である場合、ATMVP候補は導出され、他のピクチャは検査される必要がない。そうでない場合、動きソースピクチャとしての他のピクチャが検査される必要がある。
b.検査されるピクチャは、所与の順序をもつ現在のピクチャの参照ピクチャリスト中のピクチャであり得る。各リストについて、ピクチャは、参照インデックスの昇順で検査される。リストXが最初に検査され、(1−Xである)リストY中のピクチャが後に続く。
i.リストXが、TMVPに使用されるコロケートされたピクチャを保有するリストになるように、リストXは選ばれる。
ii.代わりとして、Xは、単に1または0に設定される。
c.検査されるピクチャは、所与の順序をもつ空間的隣接の動きベクトルによって識別されるピクチャである。
6.現在のATMVPが適用されるPUの区分は、2Nx2N、NxN、2NxN、Nx2N、または2NxN/2のような非対称の動き区分(AMP)の区分であり得る。
a.代わりとして、加えて、他の区分サイズが許容され得る場合、ATMVPもサポートされ得、そのようなサイズは、たとえば64x8を含み得る。
b.代わりとして、モードは、ある特定の区分、たとえば2Nx2Nにのみ適用され得る。
7.ATMVP候補は、異なるタイプのマージ候補としてマークされる。
8.隣接からベクトル(第1段階にあるような時間ベクトル)を識別するとき、複数の隣接位置、たとえばマージ候補リスト構築で使用されるものが順番に検査され得る。隣接の各々について、参照ピクチャリスト0(リスト0)または参照ピクチャリスト1(リスト1)に対応する動きベクトルが順番に検査され得る。2つの動きベクトルが利用可能であるとき、リストX中の動きベクトルが最初に検査され、その後にリストY(ここで、Yは1−Xに等しい)が続き得、その結果、リストXがTMVPに使用されるコロケートされたピクチャを保有するリストになる。ATMVPでは、時間ベクトルがサブPUの任意の中央位置のシフトとして加えられるように使用され、ここにおいて、時間ベクトルの成分は、整数にシフトされる必要があり得る。そのようなシフトされた中央位置は、たとえば現在の中央位置をカバーする4x4のサイズをもつ、動きベクトルが割り振られ得る最小ユニットを識別するために使用される。
a.代わりとして、リスト0に対応する動きベクトルが、リスト1に対応するものの前に検査され得る。
b.代わりとして、リスト1に対応する動きベクトルが、リスト0に対応するものの前に検査され得る。
c.代わりとして、全ての空間的隣接中のリストXに対応する全ての動きベクトルが順番に検査され、その後にリストY(ここで、Yは1−Xに等しい)に対応する動きベクトルが続く。ここで、リスト「X」は、コロケートされたピクチャが属するところを示すリストであり得るか、または単に0または1に設定されるだけであり得る。
d.空間的隣接の順序は、HEVCマージモードで使用されるものと同じであり得る。
9.第1段階で、参照ピクチャを識別する情報を含まない時間ベクトルを識別するとき、図9で示されているような動きソースピクチャは単に、固定のピクチャ、たとえばTMVPに使用されるコロケートされたピクチャに設定され得る。
a.そのようなケースでは、ベクトルは、そのような固定のピクチャを指す動きベクトルからのみ識別され得る。
b.そのようなケースでは、ベクトルは、任意のピクチャを指す動きベクトルからのみ識別されるが、固定のピクチャに向かってさらにスケーリングされ得る。
10.ベクトルを識別する第1段階が、参照ピクチャ、即ち図9で示されているような動きソースピクチャを識別することを含む(consist)とき、以下の追加の検査のうちの1つまたは複数が、候補の動きベクトルについて適用され得る。
a.動きベクトルがイントラコーディングされるピクチャまたはスライスに関連付けられる場合、そのような動きベクトルは利用可能でないと見なされ、ベクトルに変換されるようには使用されることができない。
b.動きベクトルが、関連付けられるピクチャにおいて、(たとえば、動きベクトルを現在の中央座標に加えることによって)イントラブロックを識別する場合、そのような動きベクトルは、利用可能でないと見なされ、ベクトルに変換されるように使用されることができない。
11.第1段階がベクトルを識別するとき、ベクトルの成分は、(現在のPUの半分の幅、現在のPUの半分の高さ)に設定され得、結果、それが動きソースピクチャ中の右下ピクセル位置を識別するようにする。ここで、(x,y)は、1つの動きベクトルの水平および垂直成分を示す。
a.代わりとして、ベクトルの成分は、(sum(現在のPUの半分の幅,M),sum(現在のPUの半分の高さ,N))に設定され得、ここで、関数sum(a,b)は、aとbの合計を返す。一例では、動き情報が4x4ユニットで記憶されるとき、MおよびNは両方とも、2に等しくなるように設定される。別の例では、動き情報が8x8ユニットで記憶されるとき、MおよびNは両方とも、4に等しくなるように設定される。
12.ATMVPが適用されるときのサブブロック/サブPUサイズは、パラメータセット、たとえばピクチャパラメータセットのシーケンスパラメータセットに、おいてシグナリングされる。サイズは、少なくともPUサイズからCTUサイズに及ぶ。サイズはまた、予め定義されるか、またはシグナリングされ得る。サイズは、たとえば4x4程の小ささであり得る。代わりとして、サブブロック/サブPUサイズは、PUまたはCUのサイズに基づいて導出され得る。たとえば、サブブロック/サブPUは、最大値(4x4,(CUの幅)>>M)に等しく設定され得る。Mの値は、予め定義され得るか、ビットストリームにおいてシグナリングされ得る。
13.マージ候補の最大数は、ATMVPが新たなマージ候補として見なされ得るという事実に起因して1だけ増加し得る。たとえば、プルーニング後にマージ候補リストに最大5つの候補を入れるHEVCと比較すると、マージ候補の最大数は、6まで増加し得る。
a.代わりとして、従来のTMVP候補を用いたプルーニングまたは従来のTMVP候補との統合が、マージ候補の最大数が変化されないまま維持され得るように、ATMVPについて実行され得る。
b.代わりとして、ATMVPが利用可能であると識別されるとき、1つの空間的隣接候補が、マージ候補リストから排除され、たとえば、フェッチ順序で最後の空間的隣接候補が排除される。
14.複数の空間的隣接動きベクトルが時間ベクトルを導出するために考慮されるとき、現在のPUの隣接動きベクトルと、ある動きベクトルに等しく設定されている特定の時間ベクトルによって識別された隣接動きベクトルとに基づいて、動きベクトルの類似度が計算され得る。最高の動きの類似度に導くものが、最終的な時間ベクトルとして選ばれ得る。
a.一代替例では、隣接位置Nからの各動きベクトルについて、動きベクトルは、動きソースピクチャ中のブロック(現在のPUと同じサイズ)を識別し、ここにおいて、その隣接位置Nは、1セットの動き情報を保有する。この1セットの動きベクトルは、現在ブロックの隣接位置Nにあるような1セットの動き情報と比較される。
b.別の代替例では、隣接位置Nからの各動きベクトルについて、それは動きソースピクチャ中のブロックを識別し、ここにおいて、その隣接位置は、動き情報の複数のセットを保有する。これらの動きベクトルの複数のセットは、同じ関連する(the same relative)位置にある現在のPUの隣接位置からの動き情報の複数のセットと比較される。動き情報の類似度が計算される。たとえば、現在のPUは、A1、B1、A0、およびB0からの以下の動き情報のセット、MIA1、MIB1、MIA0、およびMIB0と表される、を有する。時間ベクトルTVでは、それは、動きソースピクチャ中のPUに対応するブロックを識別する。そのようなブロックは、同じ関連する(the same relative)A1、B1、A0、およびB0の位置からの動き情報を有し、TMIA1、TMIB1、TMIA0、およびTMIB0と表される。TVによって決定されるような動きの類似度は、MStv=ΣN∈{A1,B1,A0,B0}MVSim(MIN,TMIN)として計算され、ここにおいて、MVSimは、2セットの動き情報間の類似度を定義する。
c.上記ケースの両方において、動きの類似度MVSimが使用され得、ここにおいて、2つの入力パラメータは2つの動き情報であり、その各々が、最大2つの動きベクトルおよび2つの参照インデックスを保有する。リストX中の動きベクトルの各ペアは、実際、異なるピクチャの異なるリストX中の参照ピクチャ、現在のピクチャ、および動きソースピクチャに関連付けられているので。2つの動きベクトルMVXNおよびTMVXNの各々(ここで、Xは0または1に等しい)について、動きベクトル差分MVDXNが、MVXN-TMVXNとして計算され得る。その後、差分MVSimXが、たとえばabs(MVDXN[0])+abs(MVDXN[1])、または(MVDXN[0]*MVDXN[0]+MVDXN[1]*MVDXN[1])として計算される。両方の動き情報のセットが利用可能な動きベクトルを保有する場合、MVSimは、MVSim0+MVSim1に等しく設定される。
i.動き差分の統一的計算を有するために、動きベクトルの両方が、同じ固定のピクチャ、たとえば現在のピクチャのリストXの第1の参照ピクチャRefPicListX[0]であり得るピクチャ、に向かってスケーリングされる必要がある。
ii.第1のセットからのリストX中の動きベクトルの利用可能性と、第2のセットからのリストX中の動きベクトルの利用可能性とが異なる、即ち、1つの参照インデックスが−1であるのに対してもう一方がそうでない場合、そのような2セットの動き情報は方向Xで類似しないと見なされる。2セットが両方のセットにおいて類似しない場合、最終的なMVSim関数は大きい値Tを返し得、Tは、たとえば無限と見なされ得る。
iii.代わりとして、ペアの動き情報のセットについて、一方がリストX(Xは0または1に等しい)から予測されるがリストY(Yは1−Xに等しい)からは予測されず、他方が同じステータスを有する場合、1と2との間の重み(たとえば、MVSimがMVSimX*1.5に等しい)が使用され得る。1セットがリストXからのみ予測され、もう一方がリストYからのみ予測されるとき、MVSimは、大きい値Tに設定される。
iv.代わりとして、動き情報の任意のセットについて、1つの動きベクトルが利用可能である限り、両方の動きベクトルが作り出されることになる。(リストXに対応する)1つの動きベクトルのみが利用可能であるケースでは、それは、もう一方のリストYに対応する動きベクトルを形成するようにスケーリングされる。
d.代わりとして、現在のPUの隣接ピクセルと、動きベクトルによって識別されたブロック(現在のPUと同じサイズ)の隣接ピクセルとの間の差分に基づいて、動きベクトルが測定され得る。最小の差分を導く動きベクトルが、最終的な時間ベクトルとして選ばれ得る。
15.現在ブロックの時間ベクトルを導出するとき、ATMVPを用いてコーディングされる隣接ブロックからの時間ベクトルおよび/または動きベクトルは、他の隣接ブロックからの動きベクトルよりも高い優先度を有し得る。
a.一例では、隣接ブロックの時間ベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときにのみ、通常の時間ベクトルがさらに検査される。このケースでは、ATMVPコーディングされたブロックについての時間ベクトルが記憶される必要がある。
b.別の例では、ATMVPコーディングされた隣接ブロックからの動きベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルが存在しないときにのみ、通常の時間ベクトルがさらに検査される。
c.別の例では、ATMVPコーディングされた隣接ブロックからの動きベクトルのみが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条書き15a.にあるものと同様に継続する。
d.別の例では、隣接ブロックからの時間ベクトルが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような動きベクトルが利用可能でない場合、時間ベクトルの検査は、箇条書き15b.にあるものと同様に継続する。
e.別の例では、ATMVPコーディングされた隣接ブロックの時間ベクトルおよび動きベクトルが最初に検査され、最初に利用可能なものが、現在ブロックの時間ベクトルに設定され得る。そのような時間ベクトルおよび動きベクトルが存在しないときにのみ、通常の動きベクトルがさらに検査される。
16.複数の空間的隣接動きベクトルが時間ベクトルを導出するために考慮されるとき、動きベクトルが、ピクセルドメインから計算される歪みを最小化するように選ばれ得、たとえば、テンプレートマッチングが時間ベクトルを導出するために使用され得、最小のマッチングコストに導くものが最終的な時間ベクトルとして選択される。
17.動きベクトルが、何れのリストXについても、対応するブロックで利用可能である(動きベクトルをMVXと表す)ときに、ATMVP候補の現在のサブPUについて、該動きベクトルが(MVXをスケーリングすることによって)リストXについて利用可能であると見なされる形で、(動きソースピクチャ中の)対応するブロックからの動き情報のセットの導出がなされる。動きベクトルが何れのリストXについても、対応するブロックで利用可能でない場合、動きベクトルは、リストXについて利用可能でないと見なされる。
a.代わりとして、対応するブロックにおける動きベクトルが、リストXについては利用可能でないが、リスト1−X(Yで1−Xを表し、動きベクトルをMVYと表す)については利用可能であるとき、動きベクトルは依然として、(リストX中のターゲット参照ピクチャに対してMVYをスケーリングすることによって)リストXについて利用可能であると見なされる。
b.代わりとして、または加えて、リストXおよびリストY(1−Xに等しい)についての対応するブロックにおける両方の動きベクトルが利用可能であるとき、リストXおよびリストYからの動きベクトルは、直接スケーリングする必要はなく(are not necessary used to directly scale)、スケーリングすることによって現在のサブPUの2つの動きベクトルを生成する。
i.一例では、ATMVP候補を作る(formulating)とき、TMVPで行われるような低遅延検査が各サブPUに適用される。現在のスライスの全ての参照ピクチャリスト中の全てのピクチャ(refPicによって表されている)について、refPicのピクチャ順序カウント(POC)値は、現在のスライスのPOCよりも小さい場合、現在のスライスは低遅延モードで考慮される。この低遅延モードでは、リストXおよびリストYからの動きベクトルは、リストXおよびリストYそれぞれについて現在のサブPUの動きベクトルを生成するようにスケーリングされる。低遅延モードにないとき、MVXまたはMVYから1つの動きベクトルMVZのみが選ばれ、現在のサブPUについての2つの動きベクトルを生成するためにスケーリングされる。TMVPと同様に、Zがcollocated_from_l0_flagに等しく設定されるケースにおいて、それは、TMVPにあるようなコロケートされたピクチャが現在ピクチャのリストXにあるのか、またはリストYにあるかに依存することを意味する。代わりとして、Zは以下の通りに設定される。動きソースピクチャがリストXから識別される場合、ZはXに設定される。代わりとして、加えて、動きソースピクチャが両方の参照ピクチャリストに属し、RefPicList0[idx0]は、最初にリスト0に存在する動きソースピクチャであり、RefPicList(1)[idx1]は、最初にリスト1に存在する動きソースピクチャであるとき、Zは、idx0がidx1以下である場合には0に設定され、そうでなければ1に設定される。
18.動きソースピクチャはシグナリングされ得、たとえば、ビデオエンコーダ20によって生成され、コーディングされたビットストリームにおいてシグナリングされ得る。詳細には、動きソースピクチャがリスト0からのものか、リスト1からのものかを示すフラグが、Bスライスのためにシグナリングされる。代わりとして、加えて、現在のピクチャのリスト0またはリスト1への参照インデックスが、動きソースピクチャを識別するためにシグナリングされ得る。
[0090] 時間ベクトルを識別するとき、ベクトルは、それが、関連する動きソースピクチャ中のイントラコーディングされたブロックを指す場合、利用可能でないと見なされる(従って他のベクトルが考慮され得る)。
[0091] 図5は、参照ピクチャからのサブPU動き予測を例示する概念図である。この例では、現在のピクチャ180は、現在のPU184(たとえばPU)を含む。この例では、動きベクトル192は、PU184に対する参照ピクチャ182のPU186を識別する。PU186は、サブPU188A〜188Dに分割され、その各々がそれぞれの動きベクトル190A〜190Dを有する。したがって、現在のPU184は、実際には別個のサブPUに分割されないが、この例では、現在のPU184は、サブPU188A〜188Dからの動き情報を使用して予測され得る。特に、ビデオコーダは、現在のPU184のサブPUをそれぞれの動きベクトル190A〜190Dを使用して、コーディングし得る。しかしながら、ビデオコーダは、現在のPU184がサブPUに分けられることを示すシンタックス要素をコーディングする必要はない。このように、現在のPU184は事実上、現在のPU184を複数のサブPUに分けるために使用されるシンタックス要素のシグナリングオーバーヘッドなしで、それぞれのサブPU188A〜188Dから受け継がれる複数の動きベクトル190A〜190Dを使用して予測され得る。
[0092] 図6は、(TMVPに類似する)ATMVPにおける関連するピクチャを例示する概念図である。特に、図9は、現在のピクチャ204、動きソースピクチャ206、および参照ピクチャ200、202を例示する。より具体的には、現在のピクチャ204は現在ブロック208を含む。時間動きベクトル212は、現在ブロック208に対する動きソースピクチャ206の対応するブロック210を識別する。対応するブロック210が今度は、参照ピクチャ202を指し、現在ブロック208の少なくとも一部分、たとえば現在ブロック208のサブPUについての高度時間動きベクトル予測子(advanced temporal motion vector predictor)としての役割をする動きベクトル214を含む。つまり動きベクトル214は、現在ブロック208についての候補の動きベクトル予測子として加えられ得る。選択された場合、現在ブロック208の少なくとも一部分は、対応する動きベクトル、すなわち参照ピクチャ200を指す動きベクトル216を使用して予測され得る。
[0093] HEVCのためのサブPU関連技法はまた、米国出願第62/174,393号および第62/295,329号でも説明されており、その両方の内容全体が、本明細書に参照により組み込まれている。時空間動きベクトル予測子(spatial-temporal motion vector predictor)導出についての例となる技法を示すフローチャートが、以下の図7において示される。
[0094] サブPU動き予測を使用するパフォーマンスを高めるために、隣接サブPUの時空間動き情報(ATMVP_EXT)が、米国出願第62/174,393号および第62/295,329号で説明されているように利用される。この例では、サブPU毎の動きベクトルが、3次元ドメインにおける隣接ブロックの情報から導出される。それは、隣接ブロックが、現在のピクチャ中の空間的隣接であるか、または前にコーディングされたピクチャ中の時間的隣接であり得ることを意味する。図7は、時空間動きベクトル予測子(STMVP)導出プロセスのフローチャートを示す。以下で説明されることに加えて、ATMVPについて上で説明された方法(たとえば、箇条書き1、2、3、4、6、7、12、13)がSTMVPに直接拡張され得る。
[0095] 図7の方法は、(以下でより詳細に説明されるように)ビデオエンコーダ20および/またはビデオデコーダ30によって実行され得る。一般性のために(for generality)、図7の方法は、「ビデオコーダ」によって実行されるものとして説明されるが、この場合も同様に、「ビデオコーダ」は、ビデオエンコーダ20またはビデオデコーダ30のどちらかに対応し得る。
[0096] 最初に、ビデオコーダは、PUの現在のサブPUについての空間的または時間的隣接ブロックから利用可能な動きフィールドを取得する(230)。ビデオコーダはその後、取得された隣接動きフィールドから動き情報を導出する(232)。ビデオコーダはその後、PUの全てのサブPUについての動き情報が導出されたかどうかを決定する(234)。導出されていない(not)場合(234の「NO」の分岐)、ビデオコーダは、残りのサブPUについての動き情報を導出する(230)。一方で、全てのサブPUについての動作情報が導出された場合(234の「YES」の分岐)、ビデオコーダは、たとえば上で説明されたように、時空間サブPU動き予測子の利用可能性を決定する(236)。時空間サブPU動き予測子が利用可能である場合、ビデオコーダは、マージリスト中に時空間サブPU動き予測子を挿入する(238)。
[0097] 図7の方法では示されていないけれども、ビデオコーダはその後、マージ候補リストを使用して、PU(たとえば、PUのサブPUの各々)をコーディングし得る。たとえば、ビデオエンコーダ20によって実行されるとき、ビデオエンコーダ20は、予測子としてサブPUを使用して、PUについての(たとえば、サブPU毎の)(1つまたは複数の)残差ブロックを計算し、該(1つまたは複数の)残差ブロックを変換および量子化し、結果として得た量子化された変換係数をエントロピー符号化し得る。ビデオデコーダ30も同様に、受信されたデータをエントロピー復号して、量子化された変換係数を再生成し、これらの係数を逆量子化および逆変換して(1つまたは複数の)残差ブロックを再生成し、その後、該(1つまたは複数の)残差ブロックを対応するサブPUと結合して(combine)、当該PUに対応するブロックを復号し得る。
[0098] 以下の説明では、「ブロック」という用語は、たとえば、インターまたはイントラ予測、イントラ予測モード、動き情報等の予測関連情報の記憶のためのブロックユニットを参照するために使用される。そのような予測情報は、将来的なブロックをコーディングするため、たとえば将来的なブロックについて予測モード情報を予測するために記憶され、使用され得る。AVCおよびHEVCでは、そのようなブロックのサイズは4x4である。以下の説明では、「PU」はインターコーディングされるブロックユニットを示すために使用され、サブPUは隣接ブロックから動き情報を導出するユニットを示すために使用される。
[0099] 以下の技法の何れの組合せも適用され得る。
[0100] 図8は、例となる現在の予測ユニット(PU)250および隣接サブPU252A〜252Iを例示する概念図である。現在ブロック250は、サブPU254A〜254Pを含む。PUが複数のサブPUを含むとき、サブPUの各々のサイズは通常、その隣接ブロックサイズ以上である。図8の例では、サブPU252A〜252Iは、現在のPU250の外側にある隣接ブロックを表し、サブPU254A〜254Pは、現在のPU250中のサブPUを表す。この例では、サブPU254A〜254Pと隣接サブPU252A〜252Iとのサイズは同じである。たとえば、サイズは4x4に等しくなり得る。
[0101] 一方、図9は、隣接ブロック264A〜264Iよりも大きいサブPU262A〜262Dを含む別の例となる現在のPU260を例示する概念図である。他の例では、サブPUは、矩形(rectangles)または三角形のような非正方形(non-square shapes)を有し得る。
[0102] いくつかの例では、サブPUのサイズは、サブPUに分割されたブロックを含むスライスのスライスヘッダにおいてシグナリングされ得る。
[0103] 代わりとして、ATMPVに関連する上記説明の箇条書き12.におけるプロセスが拡張され得る。図8におけるケースを考慮すると、ラスタ走査順序(254A、254B、254C、254D、254Eなど)が、サブPU254A〜254Pに対して、以下の説明におけるそれらの動き予測導出のために適用されることを前提とする。しかしながら、他の走査順序も適用され得、本開示の技法がラスタ走査順序のみに限定されないことに留意されたい。
[0104] ここで、隣接ブロックは、2つの異なるタイプ:空間的および時間的、に分類され得る。空間的隣接ブロックは、図8の空間的隣接サブPU252A〜252Iのような、現在のピクチャまたはスライス中にある、現在のサブPUに隣接する、既にコーディングされたブロックまたは既に走査されたサブPUである。時間的隣接ブロック(図8では図示せず)は、前にコーディングされたピクチャ中にある、現在のサブPUのコロケートされたブロックに隣接するブロックである。一例では、現在のPUに関連付けられた全ての参照ピクチャが、時間的隣接ブロックを取得するために使用される。別の例では、参照ピクチャのサブセットがSTMVP導出に使用され、たとえば、各参照ピクチャリストの最初のエントリのみが使用される。
[0105] この定義にしたがうと、サブPU254Aについて、全ての隣接ブロック252A〜252Pおよび前にコーディングされたピクチャ中のそれらのコロケートされたブロックが、利用可能と扱われる空間的および時間的隣接ブロックである。ラスタ走査順序にしたがうと、ブロック254B〜254Pは空間的に利用可能でない。しかしながら、全てのサブPU(254A〜254P)は、それらの動き情報が前にコーディングされたピクチャ中のそれらのコロケートされたブロックにおいて発見され得るので、サブPU(A)についての時間的に利用可能な隣接ブロックである。サブPU254Gを別の例として挙げると、それの利用可能な空間的隣接ブロックは、252A〜252Iからのもの、そしてまた254A〜254Fからのものを含む。いくつかの例では、ある特定の制限が空間的隣接ブロックに適用され得、たとえば、空間的隣接ブロック(即ち、サブPU252A〜252I)は、「利用可能」と見なされるためには、現在ブロック250と同じLCU/スライス/タイルに存在するように制限され得る。
[0106] 全ての利用可能な隣接ブロックのサブセットが、各サブPUのための動き情報または動きフィールドを導出するために選択され得る。各PUの導出に使用されるサブセットは予め定義され得、代わりとして、それは、スライスヘッダ/PPS/SPSにおいて高レベルシンタックスとしてシグナリングされ得る。コーディングパフォーマンスを最適化するために、サブセットは各サブPUについて異なり得る。実際、簡潔さのために、サブセットについてのロケーションの固定パターンが好ましい。たとえば、各サブPUは、そのすぐ上の空間的隣接、そのすぐ左の空間的隣接、およびそのすぐ右下の時間的隣接、をサブセットとして使用し得る。図8で示されているように、サブPU254Jを考慮するとき、上ブロック(サブPU254F)および左ブロック(サブPU254I)が空間的に利用可能な隣接ブロックであり、右下ブロック(サブPU254O)が時間的に利用可能な隣接ブロックである。そのようなサブセットを用いて、現在のPU250中のサブPU254A〜254Pは、処理依存に起因して、シーケンシャルに、処理され得る。
[0107] 現在のPU250中のサブPU254A〜254Pの各々の並列処理を可能にするために、隣接サブPU252A〜252Iの異なるサブセットが定義および使用され得る。一例では、サブセットは、現在のPU250に属さない空間的隣接ブロック、たとえば隣接サブPU252A〜252Iのみを保有する。このケースでは、並列処理が可能だろう。別の例では、サブPU254A〜254Pの所与の1つについて、その空間的隣接ブロックが現在のPU250内にある場合、その空間的隣接ブロックのコロケートされたブロックがサブセットに置かれ、現在のサブPUの動き情報を導出するために使用され得る。たとえば、サブPU254Jを考慮するとき、上ブロック(サブPU254F)と左ブロック(サブPU254I)と右下ブロック(サブPU254O)との時間的にコロケートされたブロックが、サブPU(サブPU254J)の動きを導出するためにサブセットとして選択される。このケースでは、サブPU254Jのためのサブセットは、3つの時間的隣接ブロックを保有する。別の例では、部分的な並列処理がイネーブルにされ得、ここにおいて、1つのPUがいくつかの領域に分けられ、(いくつかのサブPUをカバーする)各領域が別個に処理され得るだろう。
[0108] 時折、隣接ブロックがイントラコーディングされ、より良好な動き予測およびコーディング効率のために、それらのブロックについての置き換え動き情報(replacement motion information)を決定する規則を有することが望ましくあり得る。たとえば、サブPU254Aを考慮すると、サブPU252B、252C、および252Fがイントラコーディングされ、サブPU252A、252D、252E、252G、252H、および252Iがインターコーディングされるケースが存在するかもしれない。
[0109] 空間的隣接では、予め定義された順序が、イントラコーディングされたブロックの動き情報に、最初に発見されたインターコーディングされたブロックの動き情報を投入するために使用され得る。たとえば、上の隣接の探索順序は、真上の隣接から始まり右方向に右端(rightmost)の隣接まで向かうように設定され、これはサブPU252B、252C、252D、および252Eの順序を意味する。左の隣接の探索順序は、すぐ左の隣接から始まり下方向に最下部(bottommost)の隣接まで向かうように設定され、これはサブPU252F、252G、252H、および252Iの順序を意味する。インターコーディングされたブロックが探索プロセスを通じて発見されない場合、上または左の空間的隣接が利用可能でないと見なされる。
[0110] 時間的隣接では、TMVP導出で指定されているものと同じ規則が使用され得る。しかしながら、他の規則、たとえば、動き方向、時間距離(異なる参照ピクチャにおける探索)、および空間的ロケーション等に基づく規則も使用され得ることに留意されたい。
[0111] 各隣接ブロックについて、全ての隣接ブロックの動きベクトルを各リスト中の同じ参照ピクチャにマッピングするために、動きベクトルスケーリングが各参照ピクチャリストに基づいてその動きベクトルに適用される。ステップは2つある:第1に、スケーリングに使用されるべきソース動きベクトルを決定する。第2に、ソース動きベクトルが投影されるターゲット参照ピクチャを決定する。第1のステップでは、いくつかの方法が使用され得る。
(a)各参照リストについて、動きベクトルスケーリングが、別の参照リストにおける動きベクトルから独立している;所与のブロックの動き情報について、参照リストに動きベクトルがない(たとえば、双予測モードではなく単一予測モード)場合、どの動きベクトルスケーリングも、そのリストについては実行されない。
(b)動きベクトルスケーリングが、別の参照リストにおける動きベクトルから独立していない;所与のブロックの動き情報について、参照リストにおいてどの動きベクトルも利用不可能でない場合、それは、別の参照リストにおけるものからスケーリングされ得る。
(c)両方の動きベクトルが、(上で言及されたTMVPにあるような)1つの予め定義された参照リストからスケーリングされる。
[0112] 一例として、方法(a)は空間的隣接ブロックの動きベクトルをスケーリングするために使用され、方法(c)は時間的隣接ブロックの動きベクトルをスケーリングするために使用される。
[0113] 第2のステップに関しては、ターゲット参照ピクチャは、利用可能な空間的隣接ブロックの動き情報(たとえば、参照ピクチャ)に基づくある特定の規則にしたがって選択され得る。そのような規則の一例は、多数決原理、即ちブロックの大多数によって共有される参照ピクチャを選択することである。このケースでは、エンコーダからデコーダへの、ターゲット参照ピクチャについて必要なシグナリングが存在せず、これは、デコーダ側でも同じ規則を使用して、同じ情報が推論され得るからである。代わりとして、そのような参照ピクチャはまた、明示的にスライスヘッダにおいて指定され得るか、または何らかの他の方法でデコーダにシグナリングされ得る。ターゲット参照ピクチャは、各参照リストの第1の参照ピクチャ(refidx=0)として決定される。
[0114] 前章で例示されたように隣接ブロックから動き情報を検索した後、および(必要であれば)動きスケーリングプロセスの後、現在のサブPUの動き情報が導出される。1つの所与のサブPUについての動き情報をもつN個の利用可能な隣接ブロックが存在することを前提とする。最初に、予測方向(InterDir)が決定されなければならない。最もシンプルな方法は以下の通りである:
a.InterDirが0として初期化され、その後、N個の利用可能な隣接ブロックの動き情報をループする(loop through)。
b.リスト0に少なくとも1つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR 1)である。
c.リスト1に少なくとも1つの動きベクトルがある場合、InterDir=(InterDir bitwiseOR 2)である。
ここで、「bitwiseOR」は、ビット単位の論理和演算(bitwise OR operation)を表す。InterDirの値は以下の通りに定義される:0(インター予測なし)、1(リスト0に基づくインター予測)、2(リスト1に基づくインター予測)、および3(リスト0とリスト1との両方に基づくインター予測)。
[0115] 代わりとして、上で説明された動きベクトルスケーリングのためのターゲット参照ピクチャに関する決定と同様に、多数決原理が、全ての利用可能な隣接ブロックの動き情報に基づいて、所与のサブPUについてのInterDirの値を決定するために使用され得る。
[0116] InterDirが決定された後、動きベクトルが導出され得る。導出されたInterDirに基づく各参照リストについて、上で説明されたように、ターゲット参照ピクチャに対する動きベクトルスケーリングを通じて利用可能なM(M<=N)個の動きベクトルが存在し得る。参照リストについての動きベクトルは、以下の通りに導出され得る:
ここで、wiおよびwjは、水平および垂直動き成分それぞれについての重み係数(weighting factors)であり、OiおよびOjは、重み係数に依存するオフセット値である。
[0117] 重み係数は、様々な係数に基づいて決定され得る。一例では、同じ規則が1つのPU内の全てのサブPUに適用され得る。規則は以下の通りに定義され得る。
[0118] たとえば、重み係数は、現在のサブPUと対応する隣接ブロックとのロケーション距離に基づいて決定され得る。
[0119] 別の例では、重み係数はまた、ターゲット参照ピクチャと、スケーリング前の対応する隣接ブロックの動きベクトルに関連付けられた参照ピクチャとの間のPOC距離に基づいても決定され得る。
[0120] また別の例では、重み係数は、動きベクトルの差分または一貫性に基づいて決定され得る。
[0121] 簡略さのために、全ての重み係数が、1に設定されることもあり得る。
[0122] 代わりとして、異なる規則が1つのPU内のサブPUに適用され得る。たとえば、上記規則が適用され得、それに加えて、第1の行/第1のカラムに位置するサブPUについて、時間的隣接ブロックから導出された動きベクトルについての重み係数が0に設定され、残りのブロックについては、空間的隣接ブロックから導出された動きベクトルについての重み係数が0に設定される。
[0123] 実際、上記数式は、そのまま実施され(implemented)得るか、または簡単な実施のために簡略化され得ることに留意されたい。たとえば、除算または浮動小数点演算を避けるために、固定小数点演算が、上記数式を近似するために使用され得る。一例は、3による除算を避けるために、代わりに、除算演算を乗算およびビットシフトで置き換えるために、43/128で乗算することを選び得る。それらの実施(implementation)のバリエーションが、本開示の技法と同じ趣旨の下でカバーされると見なされるべきである。
[0124] 代わりとして、メジアンフィルター(median filter)のような非線形演算もまた、動きベクトルを導出するために適用され得る。
[0125] いくつかの例では、各サブPUの動きベクトル予測子が利用可能であるときでさえ、STMVPモードがリセットされ、1つのPUについて利用可能でなくなり得る。
[0126] たとえば、一度各サブPUの動きベクトル予測子が所与のPUについて導出されると、STMVPモードが該所与のPUについて利用可能にされるべきであるかどうかを決定するために、いくつかの利用可能性検査が実行される。そのような演算は、STMVPモードが所与のPUについて最終的に選ばれる可能性が非常に低いケースを排除するために使用される。STMVPモードが利用可能でないとき、モードシグナリングはSTMVPを含まない。STMVPをマージリストに挿入することによってSTMVPモードが実装されるケースでは、STMVPモードが利用可能でないと決定されるとき、マージリストは、このSTMVP候補を含まない。結果として、シグナリングオーバーヘッドは低減され得る。
[0127] M個のサブPUに分割される1つのPUを検討する。一例では、M個のサブPUのうちのN1(N1<=M)個のサブPUが同じ動きベクトル予測子(即ち、同じ動きベクトルおよび同じ参照ピクチャインデックス)を有する場合、N1がしきい値よりも小さいか、または該予測子が、マージリスト中の(より小さいマージインデックスをもつ)他の動きベクトル予測子とは異なるときにのみ、STMVPは利用可能にされる。別の例では、STMVPモード下のN2(N2<=M)個のサブPUが、ATMVP下の対応するサブPUと同じ動きベクトル予測子を共有する場合、N2が別のしきい値よりも小さいときにのみ、STMVPは利用にされる。
[0128] 本開示の一例では、N1についてのしきい値とN2についてのしきい値との両方とも、Mに等しく設定される。
[0129] いくつかの例では、STMVPが利用可能である場合、それはマージリストに挿入される。上記箇条書き1.におけるプロセスが拡張され得、STMVPがATMVPの前またはATMVPの後のどちらかで挿入され得る。一例では、STMVPは、ATMVPの直後に、マージリストに挿入される。
[0130] シンタックス要素が、CABAC(context adaptive binary arithmetic coding)でコーディングされるとき、コンテキストモデルが、条件付き確率を表すために適用される。HEVCでは、CABACコーダは、異なるシンタックス要素について異なるコンテキストモデルを決定する。CABACコーダは、いくつかの例では、復号された隣接ブロックのビン数または情報のようなコーディングコンテキストに基づいて、シンタックス要素のために、いくつかの候補のコンテキストモデルから1つのコンテキストモデルを選び得る。たとえば、skip_flag_C[0]、skip_flag_C[1]、およびskip_flag_C[2]という名称の3つの候補のコンテキストモデルが、1つのCUがスキップモードでコーディングされるか否かを示すシンタックス要素cu_skip_flagをコーディングするために使用され得る。
[0131] 3つの候補から適切なコンテキストを選ぶために、CABACコーダがコンテキストインデックスxを以下の通りに計算し得る:
x=(cu_skip_flag[xNbL][yNbL] && availableL)+(cu_skip_flag[xNbA][yNbA] &&
availableA)
ここにおいて、ルーマロケーション(x0,y0)は、現在のピクチャの左上のサンプルに対する現在のルーマブロックの左上のルーマサンプルを指定し、ロケーション(xNbL,yNbL)は、(x0-1,y0)に等しく設定され、変数availableLは、現在ブロックのすぐ左に位置するブロック、即ち図10におけるブロックLの利用可能性を指定し、ロケーション(xNbA,yNbA)は、(x0,y0-1)に等しく設定され、変数availableAは、現在ブロックの真上に位置するコーディングブロック、即ち図10におけるブロックAの利用可能性を指定し、cu_skip_flag[xNbL][yNbL]およびcu_skip_flag[xNbA][yNbA]は、図10における左ブロックLおよび上ブロックAのcu_skip_flagをそれぞれ表す。cu_skip_flagのコンテキスト情報を導出するために使用される隣接ブロックが図10で例示される。
[0132] 上で説明されたように、多くの優先度ベースの候補リストが存在する。各候補は、予め定義された優先度にしたがって候補リストに挿入される。たとえば、HEVCでは、マージ候補リスト、AMVP候補リスト、イントラMPM(most probable mode)リストが、予め定義された順序に基づいて(または予め定義された優先度にしたがって)候補を挿入することによって構築される。図11で示されるように、マージ候補リストは、予め定義された順序(A1→B1→B0→A0→B2)で空間的マージ候補を挿入することによって構築される。そのような固定の順序は、局所的な特性をキャプチャできないことがある。選択される可能性がより高い候補を他の候補よりも前に置くことによってフレキシブルな順序が適用され得る場合、より高いコーディングパフォーマンスが期待され得る。
[0133] 本開示の技法では、マージ候補リスト、AMVPリスト、およびイントラMPMリストのような候補リストの構築のための優先度または挿入順序を決定するために、現在ブロックと隣接ブロックとの間でジオメトリ情報が使用され得る。さらに、このジオメトリ情報は、CABACコーディングのためのコンテキストの決定にも使用され得る。
[0134] 以下の箇条書きにされた方法が個別に適用され得る。代わりとして、それらの任意の組合せも適用され得る。
[0135] (1)一例では、現在ブロックの代表点と、候補が属する隣接ブロックの代表点との間の距離が、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。ここで使用される「ブロック」(たとえば、図12におけるブロック0〜ブロック4および現在ブロック)という用語は、コーディングユニット/ブロック、予測ユニット/ブロック、サブPU、変換ユニット/ブロック、または任意の他のコーディング構造でもあり得る。さらに、ユニットブロックは、動き情報(動きベクトル、参照ピクチャインデックス、インター予測方向等)、イントラ予測モード、変換情報等といったコーディング情報を記憶するための基本ユニットである。たとえば、このユニットブロックのサイズは4x4であり得る。図12で示されているように、候補A0、A1、B0、B1、およびB2が、隣接ブロックのブロック0、ブロック1、ブロック2、ブロック3、およびブロック4によってそれぞれカバーされているユニットブロックから導出される。
a.一例では、候補の代表点と現在の代表点との間の距離がより短いと、より高い優先度を有し、またはその逆も同様である。
b.一例では、該距離は、LNノルム距離であり得る(Nは、1、2、または任意の他の正の整数であり得る)。
[0136] (2)項目1では、現在ブロックの代表点は、現在ブロック内の任意の点でもあり得る。一例では、図12で示されているように、現在ブロックの代表点は、現在ブロックの中央点である。図12は、空間的マージ候補のジオメトリ情報の例である。
[0137] (3)項目1では、隣接ブロックの代表点は、隣接ブロック内の任意の点でもあり得る。一例では、図12で示されているように、隣接ブロックの代表点は、隣接ブロックの中央点である。
[0138] (4)代わりとして、図13で示されているように、隣接ブロックの代表点は、隣接ブロックによってカバーされたサブPUの中央点である。たとえば、隣接ブロックが、FRUC、Affine、ATMVPといったサブPUモードとしてコーディングされる場合、そのサブPUの中央点は、そのブロックについての代表点として使用される。図13は、空間的マージ候補のジオメトリ情報の例を例示する。図13で示されているように、ブロック1がサブPUモードとしてコーディングされるため、候補A1が属するサブPUの代表点が、ジオメトリ優先度を導出するために使用される。
[0139] (5)加えて、または代わりとして、代表点は、MV、参照ピクチャ情報、イントラモード、変換係数、残差情報等といったコーディング情報にしたがって適応的に決定される隣接ブロックまたは現在ブロック内の任意の点でもあり得る。
a.一例では、イントラモード候補リストを構築するために、中央点が、ブロック内の左上点で置き換えられ得る。
[0140] (6)上で言及された方法は、個々に、または他の優先度の任意の組合せで、候補リストを構築するための優先度を決定するために適用され得る。
a.一例では、2つ以上の候補が同じジオメトリ優先度(たとえば、代表点間で同じ距離)を有するとき、予め定義された優先度が、それらを区別するために使用され得る。たとえば、挿入順序(A1→B1→B0→A0→B2)が使用され得る。
b.代わりとして、他の優先度は、インター予測方向(たとえば、L0、L1、または双方向)、MV、イントラ予測モード、参照ピクチャのPOC等といったコーディング情報であり得る。
[0141] (7)上で言及された方法は、ある特定のブロックに適用され得る。
a.一例では、上記方法は、異なる幅および高さのブロックに適用される。
b.代わりとして、上記方法は、幅と高さの比がKよりも大きい、または1/Kよりも小さいブロックに適用され、ここにおいて、Kは、正の整数値であり、1よりも大きい。
c.代わりとして、上記方法は、ある特定のサイズのブロックに適用される。
[0142] (8)上で言及された方法は、候補のうちのいくつかに部分的に適用され得る。
a.一例では、ジオメトリ情報は、空間的マージ/イントラモード候補、即ち空間的隣接ブロックから導出された候補、の順序を決定するためにのみ使用される。
b.一例では、ジオメトリ情報は、ペアにされた候補(A1,B1)の順序を決定するためにのみ使用される。
b.一例では、ジオメトリ情報は、ペアにされた候補(A0,B0)の順序を決定するためにのみ使用される。
[0143] (9)ジオメトリベースの優先度を使用すべきかどうかは、ビットストリーム中でシグナリングされ得る。
a.一例では、コーディングユニット/予測ユニット/変換ユニットについて、ジオメトリベースの優先度が使用されるべきか、または予め定義された優先度リストが使用されるべきか、を示すために、フラグがシグナリングされ得る。
[0144] (10)マージ候補リストの順序が、ジオメトリベースの優先度にしたがって修正されるとき、再順序づけ後の最初の候補が、ATMVPおよび/またはSTMVPプロセスについての第1段階において使用される。
a.代わりとして、予め定義された順序から導出された最初の候補が、ATMVPおよび/またはSTMVPプロセスについての第1段階において使用される。
[0145] (11)ジオメトリ情報は、隣接ブロックからの情報が利用されるときに、CABACコーディングのためのコンテキストの決定のために使用され得る。
a.一例では、(図10で示されているLのような)左ブロック、および(図10で示されているAのような)上ブロックに加えて、図11で示されているようなA0、A1、B0、B1、およびB2(図10におけるAと同じ)といったより多くの隣接ブロックが、現在ブロックのcu_skip_flagのコンテキストを導出するために使用される。
b.複数の隣接ブロック(Mで総数を示す)が、コンテキストモデル化のために利用されるとき、ジオメトリ優先度に基づく最初のN個のブロックからの情報のみが考慮される。ここで、NはMよりも小さい。一例では、Nは2に設定され、Mは5に設定される。
c.代わりとして、さらに、限定されないが、cu_transquant_bypass_flag、cu_skip_flag、cbf、pred_mode_flag、rqt_root_cbf、merge_idx、merge_flag、cbf_luma、cbf_cb、cbf_crを含む他のシンタックス要素のコンテキストモデル化(context modeling)もまた、上記方法を使用し得る。
d.一例では、上記方法は、ある特定のブロックに適用され得、たとえば、ブロックの幅および高さが異なるか、あるいは幅と高さの比がしきい値よりも大きいか、またはある特定のサイズのブロックに適用される。
e.一例では、CABACコンテキストは、関連する重み係数によってスケーリングされた隣接ブロックのコーディング情報によって決定される。関連する重み係数は、ジオメトリ情報を用いて導出される。たとえば、スキップフラグをコーディングするためのコンテキストを選択するとき、xは、以下の数式によって導出され得る。
x=WL*(cu_skip_flag[xNbL][yNbL]&&availableL)+WA(cu_skip_flag[xNbA][yNbA]&&availableA)
WLおよびWAは、それぞれ、左および上の隣接ブロックについての関連する重み係数である。WLおよびWAは、それらのジオメトリ情報にしたがって導出され得る。一例では、隣接ブロックと現在ブロックとの代表点間の距離が、予め定義されたしきい値よりも大きいとき、関連する重み係数は、値Mに設定され、そうでなければ(該距離が予め定義されたしきい値以下であるとき)、関連する重み係数は、値Nに設定される。
f.項目11.eにおいて、隣接ブロックは、HEVCで使用される左および上ブロックに限定されない。隣接ブロックは、前にコーディングされたブロックのうちの任意の1つであり得る。
g.項目11.eにおいて、より多くの値が、より多くのしきい値を導入することによって、重み係数について割り当てられ得る。
[0146] (12)別の例では、隣接ブロックのジオメトリ情報は、マージ候補リスト、AMVPリスト、およびイントラMPMリストのような候補リストの構築のための優先度または挿入順序を決定するために使用され得る。さらに、このジオメトリ情報は、CABACコーディングのためのコンテキストの決定に使用され得る。
[0147] (13)一例では、候補が属する隣接ブロックのエリアが、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。ここで使用されている「ブロック」という用語は、コーディングユニット/ブロック、予測ユニット/ブロック、サブPU、変換ユニット/ブロック、または任意の他のコーディング構造でもあり得る。より小さいエリアをもつブロックは、より高い優先度を持ち、逆もまた同様である。
[0148] (14)エリアベースのジオメトリ情報は、項目6〜11で説明されたような上述の方法と同じように適用され得る。
[0149] 図14は、動きベクトル予測のための本開示の技法を実行するように構成され得る、例となるビデオ符号化および復号システム10を例示するブロック図である。図14で示されているように、システム10は、宛先デバイス14によって後に復号されるべき符号化されたビデオデータを提供するソースデバイス12を含む。特に、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを提供する。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(即ちラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレイヤ、ビデオゲーム機、ビデオストリーミングデバイス、または同様のものを含む、幅広いデバイスの何れも備え得る。いくつかのケースでは、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備され得る。
[0150] 宛先デバイス14は、コンピュータ可読媒体16を介して復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化されたビデオデータを移動させることが可能な何れのタイプの媒体またはデバイスも備え得る。一例では、コンピュータ可読媒体16は、ソースデバイス12がリアルタイムに符号化されたビデオデータを直接宛先デバイス14に送信することを可能にする通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格にしたがって変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトル、または1つまたは複数の物理的な伝送線路のような何れのワイヤレスまたは有線通信媒体も備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークといったパケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするのに役立ち得る何れの他の機器も含み得る。
[0151] いくつかの例では、符号化されたデータは、出力インターフェース22から記憶デバイスに出力され得る。同様に、符号化されたデータは、記憶デバイスから入力インターフェースによってアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、DVD、CD−ROM、フラッシュメモリ、揮発性または非揮発性メモリ、あるいは符号化されたビデオデータを記憶するためのあらゆる他の適したデジタル記憶媒体といった様々な分散型または局所的にアクセスされるデータ記憶媒体の何れも含み得る。さらなる例では、記憶デバイスは、ファイルサーバ、またはソースデバイス12によって生成された符号化されたビデオを記憶し得る別の中間記憶デバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、記憶デバイスから、記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶すること、およびその符号化されたビデオデータを宛先デバイス14に送信することが可能な何れのタイプのサーバでもあり得る。例となるファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続記憶(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、あらゆる標準データ接続を通じて、符号化されたビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適している、ワイヤレスチャネル(たとえば、Wi−Fi接続)、有線接続(たとえば、DSL、ケーブルモデム等)、またはその両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0152] 本開示の技法は、ワイヤレスアプリケーションまたは設定に必ずしも限定されるわけではない。この技法は、OTA(over the air)テレビブロードキャスト、ケーブルテレビ送信、衛星テレビ送信、HTTPを介した動的適応型ストリーミング(DASH)のようなインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、様々なマルチメディアアプリケーションの何れもサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話といったアプリケーションをサポートするための、一方向または二方向ビデオ送信をサポートするように構成され得る。
[0153] 図14の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。本開示にしたがうと、ソースデバイス12のビデオエンコーダ20および宛先デバイス14のビデオデコーダ30は、動きベクトル予測のための本開示の候補リスト構築技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは配置を含み得る。たとえば、ソースデバイス12は、外部のカメラのような外部のビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、統合されたディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェース接続し得る。
[0154] 図14の例示されているシステム10は一例に過ぎない。動きベクトル予測のための本開示の技法は、何れのデジタルビデオ符号化および/または復号デバイスによっても実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスによって実行されるけれども、本技法は、通常「CODEC」と称されるビデオエンコーダ/デコーダによっても実行され得る。さらに本開示の技法はまた、ビデオプレプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は単に、ソースデバイス12が宛先デバイス14への送信のためのコーディングされたビデオデータを生成するようなコーディングデバイスの例に過ぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化および復号コンポーネントを含むような実質的に対称的な形で動作し得る。したがってシステム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス12とビデオデバイス14との間の一方向または二方向ビデオ送信をサポートし得る。
[0155] ソースデバイス12のビデオソース18は、ビデオカメラのようなキャプチャデバイス、前にキャプチャされたビデオを保有するビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替例として、ビデオソース18は、ソースビデオとしてコンピュータグラフィックベースのデータを、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ処理されたビデオの組合せを生成し得る。いくつかのケースでは、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラ電話またはビデオ電話を形成し得る。しかしながら上で言及されたように、本開示で説明されている技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線アプリケーションに適用され得る。各ケースでは、キャプチャされた、事前キャプチャされた、またはコンピュータ処理されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオ情報はその後、コンピュータ可読媒体16上に出力インターフェース22によって出力され得る。
[0156] コンピュータ可読媒体16は、ワイヤレスブロードキャストまたは有線ネットワーク送信のような一時的媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体のような記憶媒体(つまり非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)は、ソースデバイス12から符号化されたビデオデータを受信し、たとえばネットワーク送信を介して、宛先デバイス14に該符号化されたビデオデータを提供し得る。同様に、ディスクスタンピングファシリティのような媒体製造ファシリティ(medium production facility)のコンピューティングデバイスが、ソースデバイス12から符号化されたビデオデータを受信し、該符号化されたビデオデータを保有するディスクを作り出し得る。したがって、コンピュータ可読媒体16は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むように理解され得る。
[0157] 宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロックおよび他のコーディングされたユニット、たとえばGOP、の処理および/または特性を記述するシンタックス要素を含む、ビデオエンコーダ20によって定義され、そしてまたビデオデコーダ30によっても使用されるシンタックス情報を含み得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、ブラウン管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスといった様々なディスプレイデバイスの何れも備え得る。
[0158] ビデオエンコーダ20およびビデオデコーダ30は、高効率ビデオコーディング(HEVC)規格、HEVC規格の拡張版、またはITU−T H.266のような後続する規格のような、ビデオコーディング規格にしたがって動作し得る。代わりとして、ビデオエンコーダ20およびビデオデコーダ30は、MPEG―4、Part10、アドバンスドビデオコーディング(AVC)、またはそのような規格の拡張版と代わりに称される、ITU−T H.264規格のような他の専有または工業規格にしたがって動作し得る。しかしながら本開示の技法は、何れの特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG−2およびITU−T H.263を含む。図14には示されていないけれども、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリームにおけるオーディオとビデオとの両方の符号化を扱うのに適切なMUX−DEMUXユニットまたは他のハードウェアおよびソフトウェアを含み得る。適用可能である場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。
[0159] ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組合せのような、様々な適切なエンコーダ回路の何れかとしても実装され得る。技法がソフトウェアにおいて部分的に実装されるとき、デバイスは、適した非一時的なコンピュータ可読媒体にソフトウェアのための命令を記憶し得、本開示の技法を実行するために、1つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれ得、エンコーダまたはデコーダのどちらも、それぞれのデバイスにおいて組み合わされたエンコーダ/デコーダ(CODEC)の一部として統合され得る。
[0160] ビデオコーディング規格は、ITU−T H.261、ISO/IEC MPEG−1ビジュアル、ITU−T H.262またはISO/IEC MPEG−2ビジュアル、ITU−T H.263、ISO/IEC MPEG−4ビジュアル、および(ISO/IEC MPEG−4 AVCとしても知られている)ITU−T H.264を含み、そのSVC(Scalable Video Coding)およびMVC(MultiView Video Coding)拡張版も含む。MVCの1つの共同ドラフトは、2010年3月付のITU−T勧告H.264「Advanced video coding for generic audiovisual services」で説明されている。
[0161] 加えて、新たに開発されたビデオコーディング規格、即ちITU−Tビデオコーディング専門家グループ(VCEG)およびISO/IEC動画専門家グループ(MPEG)のビデオコーディングに関する共同チーム(JCT−VC)よって開発された高効率ビデオコーディング(HEVC)が存在する。HEVCの最新のドラフトは、phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zipから利用可能である。HEVC規格はまた、勧告ITU−T H.265および国際規格ISO/IEC23008−2においても共同で提示されており、この両方が「High efficiency video coding」と題し、またこの両方が、2014年10月付で公表されている。
[0162] JCT−VCは、HEVC規格を開発した。HEVC標準化の試みは、HEVCテストモデル(HM)と称されるビデオコーディングデバイスの発展型モデルに基づく。HMは、たとえば、ITU−T H.264/AVCにしたがった既存のデバイスと比較して、ビデオコーディングデバイスのいくつかの追加の能力を想定する。たとえば、H.264が9個のイントラ予測符号化モードを提供するのに対し、HEVC HMは、33個程に多くのイントラ予測符号化モードを提供し得る。
[0163] 一般に、HMの作業モデル(working model)は、ビデオフレームまたはピクチャがルーマサンプルとクロマサンプルとの両方を含む、ツリーブロックのシーケンス、または、最大符号化ユニット(LCU)に分割され得ることを記述する。ビットストリーム内のシンタックスデータは、ピクセル数の観点で最大の符号化ユニットであるLCUのサイズを定義し得る。スライスは、いくつかの連続するツリーブロックをコーディング順序で含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに分割され得る。各ツリーブロックは四分木にしたがってコーディングユニット(CU)に分けられ得る。一般に、四分木データ構造は、CU毎の1つのノードを含み、ツリーブロックに対応する1つのルートノードをもつ。CUが4つのサブCUに分けられる場合、CUに対応するノードは4つのリーフノードを含み、その各々がサブCUのうちの1つに対応する。
[0164] 四分木データ構造の各ノードは、対応するCUにシンタックスデータを提供し得る。たとえば、四分木におけるノードは、ノードに対応するCUがサブCUに分けられるかどうかを示す、分割フラグ(split flag)を含み得る。CUについてのシンタックス要素は再帰的に定義され得、CUが複数のサブCUに分けられるかどうかに依存し得る。CUがこれ以上分けられない場合、それはリーフCUと称される。本開示では、リーフCUの4つのサブCUもまた、元のリーフCUの明示的分割が存在しない場合でも、リーフCUと称されることになる。たとえば、16x16のサイズのCUがこれ以上分けられない場合、4つの8x8のサブCUもまた、16x16のCUが全く分けられなかったといえども、リーフCUと称されることになる。
[0165] CUは、CUがサイズの区別(a size distinction)を有さない点を除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは4つの子ノード(サブCUとも称される)に分けられ得、各子ノードは、今度は親ノードになり、別の4つの子ノードに分けられ得る。四分木のリーフノードと称される最後の分割されない子ノードは、リーフCUとも称されるコーディングノードを備える。コーディングされたビットストリームに関連付けられたシンタックスデータは、最大CU深度と称される、ツリーブロックが分けられ得る最大回数を定義し得、またコーディングノードの最小サイズも定義し得る。したがって、ビットストリームはまた、最小コーディングユニット(SCU)も定義し得る。本開示は、HEVCのコンテキストにおけるCU、PU、またはTUの何れも指すように、あるいは他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるそのマクロブロックおよびサブブロック)を指すように、「ブロック」という用語を使用する。
[0166] CUは、コーディングノード、ならびに該コーディングノードに関連付けられた予測ユニット(PU)および変換ユニット(TU)を含む。CUのサイズはコーディングノードのサイズに対応し、形状が正方形(square)でなければならない。CUのサイズは、8x8ピクセルから、最大64x64ピクセルまたはそれより大きいツリーブロックのサイズまでの範囲に及び得る。各CUは、1つまたは複数のPU、および1つまたは複数のTUを保有し得る。CUに関連付けられたシンタックスデータは、たとえば、CUの1つまたは複数のPUへの分割を記述し得る。分割モードは、CUが、スキップまたはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、インター予測モード符号化されるかで異なり得る。PUは、形状が非正方形(non-square)になるように分割され得る。CUに関連付けられたシンタックスデータはまた、たとえば、四分木にしたがったCUの1つまたは複数のTUへの分割を記述し得る。TUは、形状が正方形または非正方形(たとえば、長方形(rectangular))であり得る。
[0167] HEVC規格は、異なるCUでは異なり得る、TUにしたがった変換を許容する。TUは通常、分割されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ化されるが、常にこれが起こり得るわけではない。TUは通常、PUと同じサイズであるかそれより小さい。いくつかの例では、CUに対応する残差サンプルは、「残差四分木」(RQT:residual quad tree)として知られる四分木構造を使用してより小さいユニットにさらに分割され(subdivided)得る。RQTのリーフノードは、変換ユニット(TU)と称され得る。TUに関連付けられたピクセル差分値は、変換係数を作り出すために変換され得、変換係数は量子化され得る。
[0168] リーフCUは、1つまたは複数の予測ユニット(PU)を含み得る。一般に、PUは、対応するCUの全てまたは一部分に対応する空間エリアを表し、該PUについての参照サンプルを検索するためのデータを含み得る。さらにPUは、予測に関連するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUについてのデータは残差四分木(RQT)に含まれ得、それは、PUに対応するTUのためのイントラ予測モードを記述するデータを含み得る。別の例として、PUがインターモード符号化されるとき、PUは、PUについての1つまたは複数の動きベクトルを定義するデータを含み得る。PUについての動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度(たとえば、4分の1ピクセル精度または8分の1ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルについての参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)を記述し得る。
[0169] 現在ブロックと隣接ブロックとの間のジオメトリ情報は、動きベクトルについての参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)の構築のための優先度または挿入順序を決定し得る。ジオメトリ情報は、現在ブロックの代表点(たとえば中央点)と、候補が属する隣接ブロックの代表点との間の距離を含み得る。その代表点と現在ブロックの代表点との間でより短い距離をもつ隣接ブロックに対し、より高い優先度が示され得る。代表点は、ブロック内の何れの点(たとえば中央点)でもあり得る。
[0170] 1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換ユニット(TU)も含み得る。変換ユニットは、上で説明されたように、RQT(TU四分木構造とも称される)を使用して指定され得る。たとえば、分割フラグ(split flag)は、リーフCUが4つの変換ユニットに分割されるかどうかを示し得る。その後、各変換ユニットが、さらなるサブTUにさらに分けられ得る。TUがこれ以上分けられないとき、それはリーフTUと称され得る。一般に、イントラコーディングでは、1つのリーフCUに属する全てのリーフTUが、同じイントラ予測モードを共有する。つまり一般に、1つのリーフCUの全てのTUについて予測される値を計算するために同じイントラ予測モードが適用される。イントラコーディングでは、ビデオエンコーダは、各リーフTUについての残差値を、イントラ予測モードを使用して、TUに対応するCUの一部分と元のブロックとの間の差分として、計算し得る。1つのTUは、1つのPUのサイズに限定される必要はない。したがって、TUは、PUより大きいことも小さいこともある。イントラコーディングでは、PUは、同じCUについての対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
[0171] さらに、リーフCUのTUはまた、残差四分木(RQT)と称される、それぞれの四分木データ構造とも関連付けられ得る。つまりリーフCUは、リーフCUがどのようにTUに分割されるかを示す四分木を含み得る。TU四分木のルートノードは一般に、リーフCUに対応するのに対し、CU四分木のルートノードは一般に、ツリーブロック(またはLCU)に対応する。分けられないRQTのTUは、リーフTUと称される。一般に、本開示は、そうではないと注釈されない限り、リーフCUおよびリーフTUそれぞれを指すためにCUおよびTUという用語を使用する。
[0172] ビデオシーケンスは通常、一連のビデオフレームまたはピクチャを含む。ピクチャのグループ(GOP:group of picture)は一般に、一連の1つまたは複数のビデオピクチャを備える。GOPは、GOPのヘッダ、1つまたは複数のピクチャのヘッダ、またはその他の場所に、当該GOPに含まれるいくつかのピクチャ(a number of pictures)を記述するシンタックスデータを含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対してオペレートする。ビデオブロックは、CU内のコーディングノードに対応し得る。ビデオブロックは、固定か、または変動するサイズを有し得、指定されたコーディング規格にしたがってサイズが異なり得る。
[0173] 例として、HMは、様々なPUサイズにおける予測をサポートする。特定のCUのサイズが2Nx2Nであることを前提とすると、HMは、2Nx2NまたはNxNのPUサイズにおけるイントラ予測、および2Nx2N、2NxN、Nx2N、またはNxNの対称PUサイズにおけるインター予測をサポートする。HMはまた、2NxnU、2NxnD、nLx2N、およびnRx2NのPUサイズにおけるインター予測のための非対称分割をサポートする。非対称分割では、CUの一方向は分割されないが、他の方向は25%および75%に分割される。25%区分に対応するCUの一部分は、「n」と、その後に続く「Up(上)」、「Down(下)」、「Left(左)」、または「Right(右)」のインジケーションとによって示される。したがって、たとえば、「2NxnU」は、上に2Nx0.5NのPUと、下に2Nx1.5NのPUとに、水平に分割される2Nx2NのCUを指す。
[0174] 一般に、イントラ予測は、ブロックを、(同じピクチャ内の)当該ブロックに対して隣接する前にコーディングされたピクセルを使用して、予測することを伴う。水平、垂直、および様々な対角モードといった様々なイントラ予測モード、ならびにDCおよび平面(planar)モードが使用され得る。さらに、ある特定のモードが、隣接ブロックをイントラ予測するために使用されるイントラ予測モードに基づいて、「最も可能性のある(most probable)」と見なされ得る。本開示の技法にしたがうと、ビデオエンコーダ20およびビデオデコーダ30は、現在ブロックに対する隣接ブロックを候補として含むMPM(most probable mode)リストを、上で説明されたように、たとえば現在ブロックおよび隣接ブロックについてのジオメトリ情報にしたがってMPMリスト内の候補が順序付けされる形で構築し得る。
[0175] 本開示では、「NxN」および「N×N(N by N)」は、垂直次元および水平次元の観点からビデオブロックのピクセル次元、たとえば、16x16ピクセルまたは16×16(16 by 16)ピクセルを指すように、交換可能に使用され得る。一般に、16×16ブロックは、垂直方向に16ピクセル(y=16)、および水平方向に16ピクセル(x=16)を有することになる。同様に、NxNブロックは一般に、垂直方向にNピクセル、および水平方向にNピクセルを有し、ここで、Nは負でない整数の値を表す。ブロックにおけるピクセルは、行と列に配置され得る。さらに、ブロックは、垂直方向と同じ数のピクセルを水平方向に必ずしも有する必要はない。たとえば、ブロックは、N×Mピクセルを備え得るが、Mは必ずしもNと等しいわけではない。
[0176] CUのPUを使用するイントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ20は、CUのTUについての残差データを計算し得る。PUは、空間ドメイン(ピクセルドメインとも称される)において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え、TUは、変換、たとえば離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または残差ビデオデータに対する概念的に類似する変換の適用にしたがう変換ドメインにおける係数を備え得る。残差データは、PUに対応する予測値と符号化されていないピクチャのピクセルとの間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUについての残差データを含むTUを形成し、その後、CUについての変換係数を作り出すためにTUを変換し得る。
[0177] 変換係数を作り出すための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量を出来る限り減少させるために、変換係数が量子化されるプロセスを指し、さらなる圧縮を提供する。量子化プロセスは、係数のいくつかまたは全てに関連付けられたビット深度を低減し得る。たとえば、nビット値は量子化中にmビット値に丸められ得、ここにおいて、nはmよりも大きい。
[0178] 量子化にしたがうと、ビデオエンコーダは変換係数を走査して、量子化された変換係数を含む2次元行列から1次元ベクトルを作り出し得る。走査は、より高いエネルギー(ひいては、より低い周波数)係数をアレイの前方に置き、より低いエネルギー(ひいては、より高い周波数)係数をアレイの後方に置くように設計され得る。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化されることができる直列にされたベクトルを生成するために、量子化された変換係数を走査するのに予め定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は、適応走査を実行し得る。1次元ベクトルを形成するために量子化された変換係数を走査した後に、ビデオエンコーダ20は、たとえばCAVLC(context adaptive variable length coding)、CABAC(context adaptive binary arithmetic coding)、SBAC(syntax-based context-adaptive binary arithmetic coding)、PIPE(Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法にしたがって、当該1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30によって使用される、符号化されたビデオデータに関連付けられたシンタックス要素をエントロピー符号化し得る。
[0179] CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非ゼロであるか否かに関連し得る。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボルのために可変長コードを選択し得る。VLCにおけるコードワードは、比較的に短いコードがより確率の高いシンボルに対応する一方、より長いコードがより確率の低いシンボルに対応するように構築され得る。このように、VLCの使用は、たとえば、送信されるべき各シンボルについて等しい長さのコードワードを使用することにより、ビット節約を達成し得る。確率の決定は、シンボルに割り当てられたコンテキストに基づき得る。
[0180] 図15は、ジオメトリベースの優先度リストについての本開示の技法を実行するように構成され得るビデオエンコーダ20の例を例示するブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または取り除くための空間予測に依存する。インターコーディングは、ビデオシーケンスの隣り合ったフレームまたはピクチャ内のビデオの時間的冗長性を低減または取り除くための時間予測に依存する。イントラ(I)モードは、いくつかの空間ベースのコーディングモードのうちの何れも指し得る。単一方向予測(Pモード)または双予測(Bモード)のようなインターモードは、いくつかの時間ベースのコーディングモードの何れも指し得る。
[0181] 図15で示されているように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図15の例では、ビデオエンコーダ20は、モード選択ユニット40、参照ピクチャメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピー符号化ユニット56を含む。モード選択ユニット40が今度は、動き補償ユニット44、動き推定ユニット42、イントラ予測ユニット46、および分割ユニット48を含む。ビデオブロック再構築のためには、ビデオエンコーダ20は、逆量子化ユニット58、逆変換ユニット60、および加算器62も含む。デブロッキングフィルタ(図15には図示せず)もまた、再構築されたビデオからブロッキネスアーティファクト(blockiness artifact)を取り除くのにブロック境界をフィルタリングするために含まれ得る。望ましくは、デブロッキングフィルタは通常、加算器62の出力をフィルタリングし得る。(ループ中またはループ後の)追加のフィルタもまた、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは簡潔さのために示されていないが、望ましくは、(インループフィルタとして)加算器50の出力をフィルタリングし得る。
[0182] 符号化プロセス中、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間予測を提供するために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は代わりとして、空間予測を提供するために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータの各ブロックに適切なコーディングモードを選択するために複数のコーディングパスを実行し得る。
[0183] さらに、分割ユニット48は、前のコーディングパスにおける前の分割スキームの評価に基づいて、ビデオデータのブロックをサブブロックに分割し得る。たとえば、分割ユニット48は最初に,フレームまたはスライスを複数のLCUに分割し、レート−歪分析(たとえばレート−歪最適化)に基づいて、LCUの各々をサブCUに分割し得る。モード選択ユニット40はさらに、LCUのサブCUへの分割を示す四分木データ構造を作り出し得る。当該四分木のリーフノードCUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。
[0184] モード選択ユニット40は、たとえば、誤差(error)結果に基づいて、コーディングモードのうちの1つ、イントラかまたはインターか、選択し、結果として生じたイントラまたはインターコーディングされたブロックを、残差ブロックデータを生成するために加算器50に提供し、および参照フレームとして使用のために符号化されたブロックを再構築するために加算器62に提供する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、分割情報、および他のそのようなシンタックス情報といったシンタックス要素を、エントロピー符号化ユニット56に提供する。
[0185] 動き推定ユニット42および動き補償ユニット44は高度に統合され得るが、概念上の目的で別個に例示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックについての動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のビデオフレームまたはピクチャ内のビデオブロックのPUの、該現在のフレーム(または他のコーディングされたユニット)内でコーディングされている現在ブロックに関連する参照フレーム(または他のコーディングされたユニット)内の予測ブロックに対する変位を示し得る。予測ブロックは、差分絶対値和(SAD:sum of absolute difference)、差分二乗和(SSD:sum of square difference)、または他の差分メトリックによって決定され得るピクセル差分の観点から、コーディングされるべきブロックに厳密に一致すると分かった(found)ブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置についての値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの4分の1ピクセル位置、8分の1ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置および分数のピクセル位置に対して動き探索を実行し、分数のピクセル精度をもつ動きベクトルを出力し得る。
[0186] 動き推定ユニット42は、インターコーディングされたスライス中のビデオブロックのPUについての動きベクトルを、該PUの位置を参照ピクチャの予測ブロックの位置と比較することによって計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、該リストの各々は、参照ピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、該計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44に送る。
[0187] 動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて、予測ブロックをフェッチすることまたは生成することを伴い得る。ここでもまた、いくつかの例では、動き推定ユニット42および動き補償ユニット44は機能的に統合され得る。現在のビデオブロックのPUについての動きベクトルを受信すると、動き補償ユニット44は、該動きベクトルが指す予測ブロックを、参照ピクチャリストのうちの1つに置く(locate)。加算器50は、以下で説明されるように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット42は、ルーマ成分に関して動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分との両方のために、ルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用される、ビデオブロックおよびビデオスライスに関連付けられたシンタックス要素を生成し得る。
[0188] さらに、エントロピー符号化ユニット56、または動き補償ユニット44は、たとえばマージモードまたはAMVPモードを使用して動きベクトル予測を実行するとき、本開示の技法を適用し得る。特に、現在ブロックについての動きベクトルを予測するために使用される候補リスト(たとえば、マージ候補リストまたはAMVP候補リスト)を構築するとき、エントロピー符号化ユニット56または動き補償ユニット44は、候補についての優先度値にしたがって候補リスト内に候補を配置し得、ここで、本開示で説明されているように、優先度値は、候補についてのジオメトリ情報を表し得る。ジオメトリ情報は、たとえば、現在ブロックと、該現在ブロックに対する隣接ブロック(空間的および/または時間的隣接ブロックを含み得る)との代表点間の距離であり得る。上で説明されたように、代表点は、ブロックの中央点、ブロックの左上点、または同様のものであり得る。エントロピー符号化ユニット56または動き補償ユニット44は、優先度値を計算するとき、本開示の様々な技法のうちの任意のものを、単独または任意の組合せで、使用し得る。
[0189] ビデオエンコーダ20は、図14に関係して上で説明され、および以下でより詳細に説明されることになるような、本開示の様々な技法の何れも実行するように構成され得る。たとえば、動き補償ユニット44は、本開示の技法にしたがって、AMVPまたはマージモードを使用して、ビデオデータのブロックについての動き情報をコーディングするように構成され得る。加えて、または代わりとして、イントラ予測ユニット46は、本開示の技法にしたがってイントラ予測モードをコーディングするように構成され得る。加えて、または代わりとして、エントロピー符号化ユニット56は、本開示の技法を使用してCABACコーディングのためのコンテキスト情報を決定するように構成され得る。
[0190] たとえば、動き補償ユニット44がマージモードを実行することを選ぶとすると、動き補償ユニット44は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット44は、特定の、予め定められた順序に基づいて、候補リストに候補を加え得る。動き補償ユニット44はまた、上で説明されたように、追加の候補を加え、候補リストのプルーニングを実行し、候補リストに優先順位をつける。最終的には、モード選択ユニット40が、候補のうちのどれが現在ブロックの動き情報を符号化するために使用されるべきかを決定し、選択された候補を表すマージインデックスを符号化し得る。
[0191] イントラ予測ユニット46は、上で説明されたような、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測の代わりとして、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット46は、たとえば別個の符号化パス中に様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット46(または、いくつかの例ではモード選択ユニット40)は、テストされたモードから使用すべき適切なイントラ予測モードを選択し得る。
[0192] たとえば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードについてレート−歪分析を使用してレート−歪値を計算し、テストされたモードのうち、最良のレート−歪特性を有するイントラ予測モードを選択し得る。レート−歪分析は概して、符号化されたブロックと、該符号化されたブロックを作り出すために符号化された元の、符号化されないブロックとの間の歪み(または誤差)の量、ならびに該符号化されたブロックを作り出すために使用されるビットレート(つまりビット数)を決定する。イントラ予測ユニット46は、どのイントラ予測モードがブロックについて最良のレート−歪値を提示しているかを決定するために、様々な符号化されたブロックについてのレートおよび歪みから比率(ratio)を計算し得る。
[0193] ブロックのためのイントラ予測モードを選択した後で、イントラ予測ユニット46は、該ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供し得る。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。上で説明されたように、イントラ予測ユニット46および/またはエントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化するために本開示の技法を使用し得る。特に、エントロピー符号化ユニット56は、ジオメトリ情報、たとえばブロックと隣接ブロックとの代表点間の距離に基づいて、該ブロックに対する隣接ブロックから1つまたは複数の最も可能性のあるモード(most probable mode)を決定し得る。エントロピー符号化ユニット56はさらに、ブロックをイントラ予測するために使用されるイントラ予測モードが最も可能性のあるモード(most probable mode)のうちの1つであるか、または異なるモードであるかを示すデータをさらにエントロピー符号化し得、もし異なるモードの場合、最も可能性のあるモード(most probable mode)を除いてイントラ予測モードのリスト中へインデックスをエントロピー符号化し得る。
[0194] ビデオエンコーダ20は、複数のイントラ予測モードインデックス表および(コードワードマッピング表とも称される)複数の修正されたイントラ予測モードインデックス表を含み得る送信されるビットストリーム構成データ中に、様々なブロックについての符号化コンテキストの定義、および該コンテキストの各々について使用すべき最も可能性のあるイントラ予測モードと、イントラ予測モードインデックス表と、修正されたイントラ予測モードインデックス表との指示を含め得る。
[0195] ビデオエンコーダ20は、コーディングされている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数のコンポーネントを表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念上同様の変換のような変換を、残差ブロックに適用し、残差変換係数値を備えるビデオブロックを作り出す。変換処理ユニット52は、DCTと概念上同様である他の変換も実行し得る。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換もまた使用され得る。
[0196] 何れのケースでも、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを作り出す。変換は、残差情報を、ピクセル値ドメインから周波数ドメインのような変換ドメインへ転換する(convert)し得る。変換処理ユニット52は、結果として得た変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数のいくつかまたは全てに関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54はその後、量子化された変換係数を含む行列の走査を実行し得る。代わりとして、エントロピー符号化ユニット56が走査を実行し得る。
[0197] 量子化に続いて、エントロピー符号化ユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、CAVLC(context adaptive variable length coding)、CABAC(context adaptive binary arithmetic coding)、SBAC(syntax-based context-adaptive binary arithmetic coding)、PIPE(probability interval partitioning entropy)コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストベースのエントロピーコーディングのケースでは、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス(たとえばビデオデコーダ30)に送信され得るか、または後の送信または検索のためにアーカイブされ得る。
[0198] エントロピー符号化ユニット56は、CABACコーディングのためのコンテキスト情報の決定に使用され得るジオメトリ情報を使用し得る。たとえば、ブロックのシンタックス要素についての値をCABACコーディングするとき、エントロピー符号化ユニット56は、当該ブロックに対し、ジオメトリ情報、たとえば、該ブロックと隣接ブロックとの代表点間の距離、に基づいて、コンテキスト情報を形成するために使用される情報が検索される1つまたは複数の隣接ブロックを決定し得る。いくつかの例では、エントロピー符号化ユニット56は、上で説明されたように、ジオメトリ情報にしたがって、2つ以上の隣接ブロックからのデータの寄与に重み付けし得る。
[0199] 逆量子化ユニット58および逆変換ユニット60は、たとえば、参照ブロックとして後に使用されるようピクセルドメインにおける残差ブロックを再構築するために、逆量子化および逆変換をそれぞれ適用する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに加えることによって、参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用されるようサブ整数ピクセル値を計算するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用し得る。加算器62は、参照ピクチャメモリ64への記憶用に再構築されたビデオブロックを作り出すために、動き補償ユニット44によって作り出された動き補償された予想ブロックに再構築された残差ブロックを加える。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために参照ブロックとして動き推定ユニット42および動き補償ユニット44によって使用され得る。
[0200] 図16は、本開示の動きベクトル予測技法を実行するように構成され得るビデオデコーダ30の例を例示するブロック図である。図16の例において、ビデオデコーダ30は、エントロピー復号ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照ピクチャメモリ82、および加算器80を含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図15)に関係して説明された符号化パスに対して概して逆の復号パスを実行し得る。動き補償ユニット72がエントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得る一方で、イントラ予測処理ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
[0201] 復号プロセス中、ビデオデコーダ30は、ビデオエンコーダ20からの符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化されたビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、量子化された係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するために、ビットストリームをエントロピー復号する。いくつかの例では、エントロピー復号ユニット70は、シンタックス要素の値をエントロピー復号するためのコンテキスト情報を決定するために、本開示の技法を使用し得る。たとえば、エントロピー復号ユニット70は、現在ブロックについてのシンタックス要素の値をCABAC復号するために使用されるべきコンテキスト情報を決定するために、ジオメトリ情報(たとえば、現在ブロックの代表点と隣接ブロックの代表点との間の距離)を使用して、1つまたは複数の隣接ブロック(および、いくつかの例では重み)を決定し得る。エントロピー復号ユニット70は、動き補償ユニット72に、動きベクトルおよび他のシンタックス要素を転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0202] ビデオスライスがイントラコーディング(I)スライスとしてコーディングされるとき、イントラ予測処理ユニット74は、現在のフレームまたはピクチャの前に復号されたブロックからデータおよびシグナリングされたイントラ予測モードに基づいて、現在のビデオスライスのビデオブロックについての予測データを生成し得る。ビデオフレームがインターコーディングされる(即ち、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックについての予測ブロックを作り出す。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから作り出され得る。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づいてデフォルトの構築技法を使用して、参照フレームリスト、即ちリスト0およびリスト1を構築し得る。
[0203] 動き補償ユニット72は、たとえばマージモードまたはAMVPモードを使用して動きベクトルを復号するときに、マージ候補リストまたはAMVP候補リストといった候補リストの構築のための優先度または挿入順序を決定するために現在ブロックと隣接ブロックとの間のジオメトリ情報を使用して、候補リストを形成し得る。加えて、または代わりとして、イントラ予測ユニット74は、最も可能性のあるモード(most probable mode)についての優先度または挿入順序を決定するために現在ブロックと隣接ブロックとの間のジオメトリ情報を使用して、イントラ予測のための1つまたは複数の最も可能性のあるモード(most probable mode)(ここで、最も可能性のあるモード(most probable mode)は1つの候補リストに対応する)を決定し得る。一例では、現在ブロックの代表点と隣接ブロックの代表点との間の距離が、候補リストの構築のための優先度または挿入順序を決定するためにジオメトリ情報として使用される。一例では、その候補の代表点と現在の代表点との間の距離が短いほど、より優先度は高くなり、またはその逆も同様である。別の例では、該距離は、LNノルム距離であり得る(Nは、1、2、または何れの他の正の整数でもあり得る)。
[0204] 動き補償ユニット72は、動きベクトルおよび他のシンタックス要素をパースすることによって現在のビデオスライスのビデオブロックについての予測情報を決定し、該予測情報を使用して、復号されている現在のビデオブロックについての予測ブロックを作り出す。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライスのための1つまたは複数の参照ピクチャリストについての構築情報、スライスの各インター符号化されたビデオブロックについての動きベクトル、スライスの各インターコーディングされたビデオブロックについてのインター予測ステータス、および現在のビデオスライス中のビデオブロックを復号するための他の情報を決定するために、受信されたシンタックス要素のうちのいくつかを使用する。
[0205] 動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、参照ブロックのサブ整数ピクセルについての補間された値を計算するために、ビデオブロックの符号化中にビデオエンコーダ20によって使用されたような補間フィルタを使用し得る。このケースでは、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを作り出すために補間フィルタを使用し得る。
[0206] ビデオデコーダ30は、図14に関係して上で説明され、および以下でより詳細に説明されることになるような本開示の様々な技法の何れも実行するように構成され得る。たとえば、動き補償ユニット72は、本開示の技法にしたがって、AMVPまたはマージモードを使用して動きベクトル予測を実行すると決定するように構成され得る。エントロピー復号ユニット70は、どのように動き情報が現在ブロックについてコーディングされるかを表す1つまたは複数のシンタックス要素を復号し得る。
[0207] マージモードが実行されるとシンタックス要素が示すことを前提とすると、動き補償ユニット72は、マージ候補のセットを含む候補リストを形成し得る。動き補償ユニット72は、特定の予め定められた順序に基づいて、候補を候補リストに加え得る。動き補償ユニット72はまた、上で説明されたように、追加の候補を加え、候補リストのプルーニングを実行し得る。最終的には、動き補償ユニット72は、候補のうちのどれが現在ブロックについての動き情報をコーディングするために使用されるかを示すマージインデックスを復号し得る。
[0208] 逆量子化ユニット76は、ビットストリームにおいて提供され、かつエントロピー復号ユニット70によってエントロピー復号された量子化された変換係数を、逆量子化をする、即ち非量子化する(de-quantizes)。逆量子化プロセスは、量子化の程度、および同様に、適用されるべき逆量子化の程度を決定するためにビデオスライス中の各ビデオブロックについてビデオデコーダ30によって計算された量子化パラメータQPYの使用を含み得る。
[0209] 逆変換ユニット78は、ピクセルドメインにおいて残差ブロックを作り出すために、逆変換、たとえば逆DCT、逆整数変換、または概念上同様の逆変換プロセス、を変換係数に適用する。
[0210] 動き補償ユニット72が、動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオブロックについての予測ブロックを生成した後に、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックに動き補償ユニット72によって生成された対応する予測ブロックを加算することによって、復号されたビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数のコンポーネントを表す。望ましくは、ブロッキネスアーティファクトを取り除くよう、デブロッキングフィルタもまた復号されたブロックをフィルタするために適用され得る。他のループフィルタ(コーディングループ中またはコーディングループ後のどちらかの)もまた、ピクセル遷移を円滑にするために、または別の方法でビデオ品質を改善するために使用され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックはその後、後続の動き補償に使用される参照ピクチャを記憶する参照ピクチャメモリ82に記憶される。参照ピクチャメモリ82はまた、図14のディスプレイデバイス32のようなディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。
[0211] 図17は、本開示の技法にしたがった、ビデオデータを符号化する例となる方法を例示するフローチャートである。例および説明の目的で、図17の方法は、図15のビデオエンコーダ20によって実行されるものとして説明される。しかしながら、他のデバイスも、この方法または類似の方法を実行するように構成され得ることは理解されるべきである。
[0212] 最初に、ビデオエンコーダ20は、符号化されるべき現在ブロックを受信する(300)。モード選択ユニット40はその後、現在ブロックを予測するために使用されるべき予測モードを決定する(302)。たとえば、モード選択ユニット40は最初に、イントラ予測モードを使用すべきか、またはインター予測モードを使用すべきかを決定し得る。モード選択ユニット40がイントラ予測を使用すると決定した場合、モード選択ユニット40は、様々なイントラ予測モード(たとえば、方向性(directional)モード、DCモード、平面モード、または同様のもの)のうちの、現在ブロックを予測するために使用されるべき1つをさらに決定し得る。モード選択ユニット40がインター予測モードを使用すると決定した場合、動き推定ユニット42は、現在ブロックの1つまたは複数の予測ユニット(PU)についての動きベクトルを決定するために動き探索を実行し得る。
[0213] 何れのケースでも、ビデオエンコーダ20は、予測モードを使用して現在ブロックを予測し得る(304)。たとえば、インター予測モードでは、動き補償ユニット44が、現在ブロックについての予測されたブロックを計算するために、動き推定ユニット42によって決定された動きベクトルを使用し得る。別の例として、イントラ予測モードでは、イントラ予測ユニット46が、決定されたイントラ予測モードにしたがって、現在ブロックに対する隣接ピクセルの値を使用して、予測されたブロックを生成し得る。
[0214] ビデオエンコーダ20はその後、現在ブロックの代表点と、空間的および/または時間的隣接ブロックのような隣接ブロックの代表点との間の距離を決定し得る(306)。代表点は、たとえば、ブロックの中央点(たとえば図12および図13で示されている)、またはブロックの左上点のような他の代表点に対応し得る。隣接ブロックは、上で説明されたように、符号化ユニット、PU、またはサブPUに対応し得る。
[0215] ビデオエンコーダ20はその後、決定された距離にしたがって、1つまたは複数の隣接ブロックからのデータを候補リストに加える(308)。たとえば、イントラ予測では、ビデオエンコーダ20は、隣接ブロックからの1つまたは複数の最も可能性のあるイントラ予測モード(たとえば、最も短い距離を有する隣接ブロックを予測するために使用されるイントラ予測モード)のリストを決定し得、ここで、これらのブロックは、候補リストに含まれる候補と称され得る。別の例として、インター予測では、ビデオエンコーダ20は、動きベクトルを符号化するためのマージモードまたはAMVPモードの候補リストを形成し得る。
[0216] 何れのケースでも、エントロピー符号化ユニット56は、候補リストを使用して予測情報を符号化し得る(310)。たとえば、イントラ予測では、エントロピー符号化ユニット56は、現在ブロックを予測するために、最も可能性のあるモード(most probable mode)が使用されるかどうか、および最も可能性のあるモード(most probable mode)のうちのどれが使用されるかを表すシンタックス要素を符号化し得る。最も可能性のあるモード(most probable mode)のうちのどれも、現在ブロックを予測するためには使用されない場合、エントロピー符号化ユニット56はさらに、残りのセットのイントラ予測モードのうちののどれが、現在ブロックを予測するために使用されるかを表す情報を符号化し得る。別の例として、インター予測では、エントロピー符号化ユニット56は、マージモードまたはAMVPモードにしたがって、動き情報を符号化し得る。たとえば、マージモードでは、エントロピー符号化ユニット56は、候補リスト中へのインデックスをエントロピー符号化し得る。別の例として、AMVPモードでは、エントロピー符号化ユニット56は、候補リスト中へのインデックス、動きベクトル差分情報、参照ピクチャリスト識別子、および参照ピクチャリスト中へのインデックスをエントロピー符号化し得る。
[0217] ビデオエンコーダ20はまた、現在ブロックについての残差ブロックを計算し得る(312)。つまり上で説明されたように、加算器50が、残差ブロックを計算するために、予測されたブロックと元の現在ブロックとの間のピクセル毎の(pixel-by-pixel)差分を計算し得る。変換処理ユニット52がその後、該残差ブロックのピクセル差分を、変換係数を作り出すためにピクセルドメイン(または空間ドメイン)から周波数ドメインに変換し得、量子化ユニット54がその後、該変換係数を量子化し、それにより残差ブロックを変換および量子化し得る(314)。エントロピー符号化ユニット56がその後、該量子化された変換係数をエントロピー符号化し得る(316)。
[0218] 図17の例では示されていないけれども、ステップ306〜310のものと同様のステップを含む方法が、加えて、または代わりとして、ビデオデータの現在ブロックの1つまたは複数のシンタックス要素についての値をエントロピー符号化するためにエントロピー符号化ユニット56によって使用され得る。そのようなシンタックス要素は、たとえば、コーディングユニットトランスクアント(coding unit transquant)バイパスフラグ、コーディングユニットスキップフラグ、コーディングブロック(coded block)フラグ、予測モードフラグ、残差四分木変換ルートコーディングブロック(residual quadtree transform root coded block)フラグ、マージインデックス、マージフラグ、ルミナンスブロックについてのコーディングブロック(coded block)フラグ、またはクロミナンスブロックについてのコーディングブロック(coded block)フラグのうちの何れかまたは全てを含み得る。一般にそのような方法は、CABACコーディングのためのコンテキスト情報を決定する目的で、隣接ブロックまでの距離を決定することを含み得る。エントロピー符号化ユニット56は、最も確率が高いシンボルまたは最も確率の低いシンボルに等しい値を有する2値化された値のビットの確率を表すコンテキストモデルを初期化および/または更新するために、コンテキスト情報を使用し得る。
[0219] このように図17の方法は、ビデオデータの現在ブロックの第1の代表点と、現在ブロックに対する複数の隣接ブロックの複数の第2の代表点との間の複数の距離を決定することと、第1の代表点と第2の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングする(特にこの例では、符号化する)ことと、を含むビデオデータをコーディングする方法の例を表す。
[0220] 図18は、本開示の技法したがった、ビデオデータを復号する例となる方法を例示するフローチャートである。例および説明の目的で、図18の方法は、図16のビデオデコーダ30によって実行されるものとして説明される。しかしながら、他のデバイスも、この方法または類似の方法を実行するように構成され得ることは理解されるべきである。
[0221] 最初に、この例では、ビデオデコーダ30は、復号されるべき現在ブロックを受信する(330)。現在ブロックは、たとえば、コーディングユニット(CU)、予測ユニット(PU)、PUに対応するCUの一部分、サブPUの集合、または同様のものであり得る。本開示の技法にしたがうと、ビデオデコーダ30は、ジオメトリ情報、即ち、現在ブロックの代表点と、現在ブロックに対する隣接ブロックの代表点との間の距離、を決定する(332)。代表点は、たとえば、ブロックの中央、ブロックの左上の角(corner)、または同様のものであり得る。隣接ブロックは、いくつかの例では、PUまたはサブPUであり得る。さらに、隣接ブロックは、空間的および/または時間的隣接であり得る。
[0222] ビデオデコーダ30はその後、決定された距離にしたがって、隣接ブロックからのデータを候補リストに加える(334)。距離は一般に、候補リスト中のデータの順序付けのための優先度を表し得、ここで、より短い距離は一般に、より高い優先度を表し得る。上で説明されたように、候補リストは、現在ブロックがインター予測される場合は、動きベクトルのマージモードまたはAMVPモード復号の候補リストであり得、または、現在ブロックがイントラ予測される場合は、1つまたは複数の最も可能性のあるモード(most probable mode)のリストであり得る。ビデオデコーダ30はまた、予測モード、たとえばインター予測またはイントラ予測のどちらかを決定し(338)、該予測モードにしたがい、予測リストを使用してブロックを予測する(340)。特に、予測モードがイントラ予測である場合、イントラ予測ユニット74は、最も可能性のあるモード(most probable mode)のうちの1つが使用されることをデータが示すかどうかに基づいて、ブロックを予測するために使用されるべき実際のイントラモードを決定し、そうでない場合、実際の予測モードの識別子を決定する。一方で、予測モードがインター予測である場合、動き補償ユニット72は、マージモードまたはAMVPモードにしたがって、現在ブロックについての動きベクトルを復号し、参照ピクチャメモリ82からの動きベクトルによって識別されるデータを検索することによって、動きベクトルを使用して予測されたブロックを生成し得る。
[0223] 加えて、エントロピー復号ユニット70は、現在ブロックの量子化された変換係数をエントロピー復号する(342)。逆量子化ユニット76が、現在ブロックについての量子化された変換係数を逆量子化し、逆変換ユニット78が、変換係数に逆変換を適用し、それにより、量子化された変換係数を逆量子化および逆変換し(344)、残差ブロックを作り出す。加算器80がその後、現在ブロックを復号するために、ピクセル毎のベースで予測されたブロックの値を残差ブロックの値に加える(346)。
[0224] この場合もやはり、いくつかの例では、様々なシンタックス要素の値のエントロピー復号を実行するとき、ビデオデコーダ30が図18のステップ332〜336と同様のステップを含む方法を適用し得ることは理解されるべきである。そのようなシンタックス要素は、たとえば、コーディングユニットトランスクアント(transquant)バイパスフラグ、コーディングユニットスキップフラグ、コーディングブロックフラグ、予測モードフラグ、残差四分木変換ルートコーディングブロックフラグ、マージインデックス、マージフラグ、ルミナンスブロックについてのコーディングブロックフラグ、またはクロミナンスブロックについてのコーディングブロックフラグのうちの何れかまたは全てを含み得る。一般にそのような方法は、CABACコーディングのためのコンテキスト情報を決定する目的で、隣接ブロックまでの距離を決定することを含み得る。エントロピー復号ユニット70は、最も確率が高いシンボルまたは最も確率の低いシンボルに等しい値を有する2値化された値のビットの確率を表すコンテキストモデルを初期化および/または更新するために、コンテキスト情報を使用し得る。
[0225] このように図18の方法は、ビデオデータの現在ブロックの第1の代表点と、現在ブロックに対する複数の隣接ブロックの複数の第2の代表点との間の複数の距離を決定することと、第1の代表点と第2の代表点との間の距離にしたがった順序で、1つまたは複数の隣接ブロックを候補として現在ブロックの候補リストに加えることと、候補リストを使用して現在ブロックをコーディングする(特にこの例では、復号する)ことと、を含むビデオデータをコーディングする方法の例を表す。
[0226] 例に応じて、本明細書で説明されている技法のうちの何れの特定の動作またはイベントも、異なるシーケンスで実行されるか、加えられ得るか、マージされ得るか、または完全に除外され得る(たとえば、全ての説明されている動作またはイベントが技法の実施のために必要であるわけではない)ことは認識されるものとする。さらに、ある特定の例では、動作またはイベントは、たとえば、マルチスレッド処理、割り込み処理、または複数のプロセッサを通じて、シーケンシャルにではなく同時に実行され得る。
[0227] 1つまたは複数の例では、説明されている機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらのあらゆる組合せで実装され得る。ソフトウェアで実装される場合、機能は、コンピュータ可読媒体上で1つまたは複数の命令またはコードとして記憶または送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルにしたがって、コンピュータプログラムの1つの場所から別の場所への転送を容易にする何れの媒体も含む通信媒体、またはデータ記憶媒体のような有体の媒体に対応するコンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は一般に、(1)非一時的である有体のコンピュータ可読記憶媒体、または(2)信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示において説明されている技法の実装のための命令、コード、および/またはデータ構造を検索するために、1つまたは複数のコンピュータ、または1つまたは複数のプロセッサによってアクセスされ得る何れの利用可能な媒体でもあり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0228] 限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光学ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態で望ましいプログラムコードを記憶するために使用され得、およびコンピュータによってアクセスされ得るあらゆる他の媒体を備え得る。また、何れの接続手段も、厳密にはコンピュータ可読媒体と名付けられる。たとえば、命令が、ウェブサイトから、サーバから、または同軸ケーブル、ファイバ光ケーブル、ツイストペア、デジタル加入者線(DSL)、もしくは赤外線や、無線や、マイクロ波のようなワイヤレス技術を使用する他の遠隔ソースから送信される場合、同軸ケーブル、ファイバ光ケーブル、ツイストペア、DSL、または赤外線や、無線や、マイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続手段、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的で有形の記憶媒体を対象にすることは理解されるべきである。ディスク(disk)およびディスク(disc)は、本明細書で使用される場合、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光学ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびブルーレイディスク(disc)を含み、ここで、ディスク(disk)は大抵、磁気的にデータを再生する一方で、ディスク(disc)は、レーザーを用いて光学的にデータを再生する。上記の組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
[0229] 命令は、1つまたは複数のデジタルシグナルプロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の同等の集積(integrated)またはディスクリート論理回路といった1つまたは複数のプロセッサによって実行され得る。したがって、「プロセッサ」という用語は、本明細書で使用される場合、前述の構造、または本明細書で説明されている技法の実装に適したあらゆる任意の他の構造の何れも指し得る。加えて、いくつかの態様では、本明細書で説明されている機能性は、符号化および復号のために構成された専用ハードウェアモジュールおよび/またはソフトウェアモジュール内に設けられ得るか、あるいは組み合わせられたコデックに組み込まれ得る。また、技法は、1つまたは複数の回路または論理要素において十分に実装され得るだろう。
[0230] 本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえばチップセット)を含む、幅広い種類のデバイスまたは装置において実装され得る。様々なコンポーネント、モジュール、またはユニットが、開示されている技法を実行するように構成されたデバイスの機能的な態様を強調するために本開示において説明されているけれども、必ずしも異なるハードウェアユニットによる実現を要求するわけではない。むしろ、上記で説明されたように、様々なユニットがコデックハードウェアユニットにおいて組み合わせられ得るか、あるいは適したソフトウェアおよび/またはファームウェアと連携する、上で説明されたような1つまたは複数のプロセッサを含む、対話型(interoperative)ハードウェアユニットの集合によって提供され得る。
[0231] 様々な例が説明されてきた。これらのおよび他の例は、以下の請求項の範囲内にある。