Nothing Special   »   [go: up one dir, main page]

JP6908618B2 - ２レベルのマルチタイプツリーフレームワークを使用したビデオデータのデコーディング - Google Patents

２レベルのマルチタイプツリーフレームワークを使用したビデオデータのデコーディング Download PDF

Info

Publication number
JP6908618B2
JP6908618B2 JP2018549271A JP2018549271A JP6908618B2 JP 6908618 B2 JP6908618 B2 JP 6908618B2 JP 2018549271 A JP2018549271 A JP 2018549271A JP 2018549271 A JP2018549271 A JP 2018549271A JP 6908618 B2 JP6908618 B2 JP 6908618B2
Authority
JP
Japan
Prior art keywords
tree
region
prediction
decoding
video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018549271A
Other languages
English (en)
Other versions
JP2019512963A5 (ja
JP2019512963A (ja
Inventor
シアン・リ
ジエンレ・チェン
リ・ジャン
シン・ジャオ
シャオ−チアン・チュアン
フェン・ゾウ
マルタ・カルチェヴィッチ
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2019512963A publication Critical patent/JP2019512963A/ja
Publication of JP2019512963A5 publication Critical patent/JP2019512963A5/ja
Application granted granted Critical
Publication of JP6908618B2 publication Critical patent/JP6908618B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/583—Motion compensation with overlapping blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H04N19/45—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder performing compensation of the inverse transform mismatch, e.g. Inverse Discrete Cosine Transform [IDCT] mismatch
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本出願は、各々の内容全体が参照により本明細書に組み込まれる、2016年3月21日に出願された米国仮出願第62/311,248号、および2016年9月28日に出願された米国仮出願第62/401,016号の利益を主張するものである。
本開示は、ビデオコーディングに関する。
デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレス放送システム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラー無線電話または衛星無線電話、いわゆる「スマートフォン」、ビデオ会議デバイス、ビデオストリーミングデバイスなどを含む広範囲のデバイスに組み込まれてもよい。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)、High Efficiency Video Coding(HEVC)規格、およびそのような規格の拡張によって定義された規格に記載されるものなどのビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信し、受信し、符号化し、復号し、かつ/または記憶することができる。
ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間的(ピクチャ内)予測および/または時間的(ピクチャ間)予測を含む。ブロックベースのビデオコーディングのために、ビデオスライス(たとえば、ビデオピクチャ、またはビデオピクチャの一部分)がビデオブロックにパーティショニングされることがあり、ビデオブロックは、コーディングツリー単位(CTU)、コーディング単位(CU)、および/またはコーディングノードと呼ばれることもある。ピクチャのイントラコーディングされた(I)スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコーディングされた(PまたはB)スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用することができる。ピクチャは、フレームと呼ばれることがあり、参照ピクチャは、参照フレームと呼ばれることがある。
空間的予測または時間的予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルに従って符号化され、残差データは、コーディングされたブロックと予測ブロックとの差分を示す。イントラコーディングされるブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、画素領域から変換領域に変換され、残差変換係数をもたらすことがあり、その残差変換係数は、次いで量子化されてもよい。最初に2次元アレイに配置される量子化された変換係数は、変換係数の1次元ベクトルを生成するためにスキャンされることがあり、エントロピーコーディングが、さらなる圧縮を実現するために適用されることがある。
米国仮出願第62/279,233号 米国出願第13/678,329号 米国出願第13/311,834号
全般に、本開示は、ブロックベースのビデオコーディングにおけるコーディング単位(すなわち、ビデオデータのブロック)の編成のための技法を説明する。これらの技法は、既存のまたは未来のビデオコーディング規格に適用されてもよい。具体的には、これらの技法は、領域ツリーおよび1つまたは複数の予測ツリーを含む、マルチタイプツリーをコーディングすることを含む。予測ツリーは、領域ツリーリーフノードに由来してもよい。コーディングツール情報などのある情報が、たとえば、領域ツリーノードに対応する領域のためのコーディングツールを有効または無効にするために、領域ツリーのノードにおいてシグナリングされてもよい。
一例では、ビデオデータを復号する方法は、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4である、ステップと、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定するステップと、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義する、ステップと、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定するステップと、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号するステップとを含む。
別の例では、ビデオデータを復号するためのデバイスは、ビデオデータを記憶するように構成されるメモリと、回路で実装されるプロセッサとを含み、このプロセッサが、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号し、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4であり、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定し、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号し、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義し、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定し、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号するように構成される。
別の例では、ビデオデータを復号するためのデバイスは、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号するための手段であって、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4である、手段と、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定するための手段と、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号するための手段であって、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義する、手段と、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定するための手段と、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号するための手段とを含む。
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、この命令は、実行されると、プロセッサに、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号させ、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4であり、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定させ、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号させ、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義し、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定させ、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号させる。
1つまたは複数の例の詳細が、添付の図面および以下の説明に記載される。他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。
2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を利用してもよい、例示的なビデオ符号化および復号システムを示すブロック図である。 2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を実装してもよい、ビデオエンコーダの例を示すブロック図である。 2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を実装してもよい、ビデオデコーダの例を示すブロック図である。 例示的なコーディングツリーブロック(CTB)を示すブロック図である。 CUの例示的な予測単位(PU)を示すブロック図である。 例示的な4分木2分木(QTBT)構造および対応するCTBを示す概念図である。 重複ブロック動き補償(OBMC:overlapped block motion compensation)を使用してコーディングされたブロックを示す概念図である。 HEVCにおいて適用されるようなOBMC、すなわちPUベースのOBMCの例を示す概念図である。 サブPUレベルのOBMCを実行する例を示す概念図である。 64×64ブロックに対する非対称の動きパーティションの例を示す概念図である。 HEVCに従った残差4分木に基づく例示的な変換方式を示す概念図である。 マルチタイプツリーの第1のレベルおよびマルチタイプツリーの第2のレベルの例を示す概念図である。 本開示の技法による、コーディングツリーブロックを符号化するための例示的な方法を示すフローチャートである。 本開示の技法による、コーディングツリーブロックを復号するための例示的な方法を示すフローチャートである。
ビデオコーディングにおいて、ビデオブロックのパーティションを表すためにツリーデータ構造が使用されてもよい。たとえば、High Efficiency Video Coding(HEVC)では、コーディング単位(CU)へのコーディングツリーブロック(CTB)のパーティションを表すために4分木(quadtree)が使用される。他のブロックベースのビデオコーディングパラダイムには、他のツリー構造が使用されてきた。たとえば、2つの水平ブロックまたは2つの垂直ブロックのいずれかへのブロックのパーティションを表すために、2分木(binary tree)が使用されてきた。4分木2分木(QTBT)などのマルチタイプツリーが、4分木と2分木を結合するために使用されてもよい。
ビデオコーディング規格は、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)拡張とマルチビュービデオコーディング(MVC)拡張とを含むITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)を含む。加えて、新しいビデオコーディング規格、すなわちHigh Efficiency Video Coding(HEVC)またはITU-T H.265が、その範囲拡張、スクリーンコンテンツコーディング拡張、3Dビデオコーディング拡張(3D-HEVC)、マルチビュー拡張(MV-HEVC)およびスケーラブル拡張(SHVC)を含めて、Joint Collaboration Team on Video Coding(JCT-VC)、ならびに、ITU-T Video Coding Experts Group(VCEG)およびISO/IEC Motion Picture Experts Group(MPEG)のJoint Collaboration Team on 3D Video Coding Extension Development(JCT-3V)によって最近開発された。例として、HEVCの設計の態様が、ブロックのパーティションに注目して以下で論じられる。HEVCと他の技法とで共通の概念および用語が以下で論じられる。
マルチタイプツリー構造は一種のフラットな構造である。すべてのツリーのタイプがツリーノードにとっては等しく重要であり、このことはマルチタイプツリーの横断を複雑にする。加えて、マルチタイプツリー構造に関する従来のコーディング技法では、一部のコーディングツールは、マルチタイプツリー構造および/またはQTBT構造に適合しない。たとえば、マルチタイプツリーまたはQTBTとともに使用されるときは、重複ブロック動き補償(OBMC)はあまり効率的ではなく、それはこれらのツリーのタイプではPU境界がないからである。この場合、OBMCは、CU境界の一辺にしか適用できない。同様に、重複変換技法を適用することができず、それは、PU境界がなく、重複変換がCU境界にまたがることを許容されないからである。サブブロックが同じ量子化パラメータ(QP)予測値を共有して、マルチタイプツリー構造またはQTBT構造を使用するときにQPの変動を効率的にシグナリングできるように、領域を定義することも難しい。
本開示の技法は、これらのまたは他のそのような課題を克服するために適用されてもよい。以下で論じられる様々な技法は、個々に、または任意の組合せで適用されてもよい。
一般に、ITU-T H.265によれば、ビデオピクチャは、ルーマサンプルとクロマサンプルとの両方を含んでもよいコーディングツリー単位(CTU)(または最大コーディング単位(LCU))のシーケンスへと分割されてもよい。代替的に、CTUはモノクロームデータ(すなわち、ルーマサンプルのみ)を含んでもよい。ビットストリーム内のシンタックスデータは、ピクセル数の観点から最大のコーディング単位であるCTUのサイズを定義してもよい。スライスは、コーディング順にいくつかの連続するCTUを含む。ビデオピクチャは、1つまたは複数のスライスへとパーティショニングされてもよい。各CTUは、4分木に従ってコーディング単位(CU)へと分割されてもよい。一般に、4分木データ構造はCUごとに1つのノードを含み、ルートノードがCTUに対応する。CUが4つのサブCUに分割される場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
4分木データ構造の各ノードは、対応するCUのためのシンタックスデータを提供することができる。たとえば、4分木内のノードは、ノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含んでもよい。CUのシンタックス要素は再帰的に定義されることがあり、CUがサブCUに分割されるかどうかに依存することがある。CUがそれ以上分割されない場合、それはリーフCUと呼ばれる。本開示では、リーフCUの4つのサブCUも、元のリーフCUの明示的な分割がなくても、リーフCUと呼ばれる。たとえば、16×16サイズのCUがそれ以上分割されない場合、その16×16のCUが決して分割されなかったとしても、4つの8×8のサブCUがリーフCUと呼ばれる。
CUは、CUがサイズの区別を持たないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、CTUは、4つの(サブCUとも呼ばれる)子ノードに分割されることがあり、各子ノードは、次に親ノードになり、別の4つの子ノードに分割されることがある。最後の、4分木のリーフノードと呼ばれる分割されていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コーディングされたビットストリームと関連付けられるシンタックスデータは、最大CU深度と呼ばれる、CTUが分割されてもよい最大の回数を定義することができ、コーディングノードの最小のサイズを定義することもできる。したがって、ビットストリームはまた、最小コーディング単位(SCU)を定義することができる。本開示は、HEVCの文脈におけるCU、予測単位(PU)、もしくは変換単位(TU)のいずれか、または他の規格の文脈における同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそのサブブロック)を指すために、「ブロック」という用語を使用する。
CUは、コーディングノードと、コーディングノードと関連付けられる予測単位(PU)および変換単位(TU)とを含む。CUのサイズはコーディングノードのサイズに対応し、一般に、形状が正方形である。CUのサイズは、8×8ピクセルから最大のサイズ、たとえば64×64ピクセル以上のCTUのサイズまでの範囲であってもよい。各CUは、1つまたは複数のPUと1つまたは複数のTUとを含んでもよい。CUと関連付けられるシンタックスデータは、たとえば、1つまたは複数のPUへのCUのパーティションを記述してもよい。パーティションモードは、CUがスキップモードもしくは直接モードで符号化されるか、イントラ予測モードで符号化されるか、またはインター予測モードで符号化されるかに応じて異なってもよい。PUは、形状が非正方形であるようにパーティショニングされてもよい。CUと関連付けられるシンタックスデータはまた、たとえば、4分木に従った1つまたは複数のTUへのCUのパーティションを記述してもよい。TUは、形状が正方形または非正方形(たとえば、矩形)であることが可能である。
HEVC規格は、CUによって異なってもよい、TUに従う変換を可能にする。TUは、典型的には、パーティショニングされたCTUについて定義された所与のCU内のPUのサイズに基づいてサイズが決められるが、これは必ずしもそうではないことがある。TUは通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT)として知られる4分木構造を使用して、より小さい単位に細分されてもよい。RQTのリーフノードは、変換単位(TU)と呼ばれてもよい。TUと関連付けられるピクセル差分値は、変換係数を生成するために変換されることがあり、変換係数は量子化されることがある。
HEVCでは、リーフCUは、1つまたは複数の予測単位(PU)を含んでもよい。一般に、PUは、対応するCUのすべてまたは一部分に対応する空間領域を表し、PUのための参照サンプルを取り出すためのおよび/または生成するためのデータを含んでもよい。その上、PUは予測に関するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUのためのデータは、PUに対応するTUのイントラ予測モードを記述するデータを含んでもよい、残差4分木(RQT)に含まれてもよい。RQTは、変換ツリーとも呼ばれてもよい。いくつかの例では、イントラ予測モードは、RQTの代わりにリーフCUシンタックスの中でシグナリングされてもよい。別の例として、PUがインターモード符号化されるとき、PUは、PUの1つまたは複数の動きベクトルなどの動き情報を定義するデータを含んでもよい。PUの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの分解能(たとえば、1/4ピクセル精度または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルのための参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)を記述してもよい。
またHEVCでは、1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換単位(TU)を含んでもよい。変換単位は、上で論じられたように、RQT(TU4分木構造とも呼ばれる)を使用して指定されてもよい。たとえば、分割フラグは、リーフCUが4つの変換単位に分割されるかどうかを示してもよい。次いで、各変換単位は、さらなるサブTUにさらに分割されてもよい。TUは、それ以上分割されないとき、リーフTUと呼ばれてもよい。一般に、イントラコーディングでは、1つのリーフCUに属するすべてのリーフTUは、同じイントラ予測モードを共有する。すなわち、同じイントラ予測モードは、一般に、リーフCUのすべてのTUに対する予測される値を計算するために適用される。イントラコーディングでは、ビデオエンコーダは、各リーフTUの残差値をTUに対応するCUの部分と元のブロックとの間の差として、イントラ予測モードを使用して計算してもよい。TUは、必ずしもPUのサイズに限定されるとは限らない。したがって、TUは、PUより大きいことも小さいこともある。イントラコーディングでは、PUは、同じCUのための対応するリーフTUと同じ位置にあってもよい。いくつかの例では、リーフTUの最大のサイズは、対応するリーフCUのサイズに対応してもよい。
その上、HEVCにおけるリーフCUのTUはまた、残差4分木(RQT)と呼ばれるそれぞれの4分木データ構造と関連付けられてもよい。すなわち、リーフCUがTUへとどのようにパーティショニングされるかを示す4分木をリーフCUは含んでもよい。TU4分木のルートノードは一般にリーフCUに対応し、一方、CU4分木のルートノードは一般にCTU(またはLCU)に対応する。分割されないRQTのTUは、リーフTUと呼ばれる。一般に、本開示は、別段述べられていない限り、リーフCUを指すためにCUという用語をリーフTUを指すためにTUという用語を使用する。
ビデオシーケンスは通常、ランダムアクセスポイント(RAP)ピクチャで開始する、一連のビデオフレームまたはピクチャを含む。ビデオシーケンスは、ビデオシーケンスの特性を記述するシンタックスデータをシーケンスパラメータセット(SPS)の中に含んでもよい。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含んでもよい。ビデオコーダは通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコーディングノードに対応してもよい。ビデオブロックは固定サイズまたは可変サイズを有することがあり、指定されるコーディング規格に従ってサイズが異なることがある。
例として、予測は様々なサイズのPUに対して実行されてもよい。特定のCUのサイズが2N×2Nであると仮定すると、イントラ予測は、2N×2NまたはN×NのPUサイズに対して実行されることがあり、インター予測は、2N×2N、2N×N、N×2N、またはN×Nの対称のPUサイズに対して実行されることがある。インター予測のための非対称のパーティションは、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズに対しても実行されてもよい。非対称のパーティションでは、CUの1つの方向はパーティショニングされないが、他の方向は25%と75%にパーティショニングされる。25%のパーティションに対応するCUの部分は、"n"とその後に続く「上」、「下」、「左」、または「右」の表示によって示される。したがって、たとえば、"2N×nU"は、上側の2N×0.5NのPUおよび下側の2N×1.5NのPUにより水平方向にパーティショニングされた2N×2NのCUを指す。
図1は、2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を利用してもよい、例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示されるように、システム10は、デスティネーションデバイス14によって後で復号されるべき符号化されたビデオデータを提供するソースデバイス12を含む。具体的には、ソースデバイス12は、コンピュータ可読媒体16を介してデスティネーションデバイス14にビデオデータを提供する。ソースデバイス12およびデスティネーションデバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、表示デバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス、などを含む、広範囲のデバイスのうちのいずれかを備えてもよい。場合によっては、ソースデバイス12およびデスティネーションデバイス14は、ワイヤレス通信に対応してもよい。
デスティネーションデバイス14は、コンピュータ可読媒体16を介して、復号されるべき符号化されたビデオデータを受信することができる。コンピュータ可読媒体16は、ソースデバイス12からデスティネーションデバイス14に符号化されたビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備えてもよい。一例では、コンピュータ可読媒体16は、ソースデバイス12が符号化されたビデオデータをデスティネーションデバイス14へリアルタイムに直接送信することを可能にする通信媒体を備えてもよい。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、デスティネーションデバイス14に送信されてもよい。通信媒体は、高周波(RF)スペクトルなどの任意のワイヤレス通信媒体もしくは有線通信媒体、または1つまたは複数の物理的伝送線を備えてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどのパケットベースのネットワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12からデスティネーションデバイス14への通信を容易にするために有用であってもよい任意の他の機器を含んでもよい。
いくつかの例では、符号化されたデータは、出力インターフェース22から記憶デバイスに出力されてもよい。同様に、符号化されたデータは、入力インターフェースによって記憶デバイスからアクセスされてもよい。記憶デバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの様々な分散されたまたは局所的にアクセスされるデータ記憶媒体のうちのいずれかを含んでもよい。さらなる例では、記憶デバイスは、ソースデバイス12によって生成された符号化されたビデオを記憶してもよいファイルサーバまたは別の中間記憶デバイスに対応してもよい。デスティネーションデバイス14は、ストリーミングまたはダウンロードを介して記憶デバイスからの記憶されたビデオデータにアクセスしてもよい。ファイルサーバは、符号化されたビデオデータを記憶し、デスティネーションデバイス14にその符号化されたビデオデータを送信することが可能な任意のタイプのサーバであってもよい。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。デスティネーションデバイス14は、インターネット接続を含む任意の標準的なデータ接続を介して、符号化されたビデオデータにアクセスすることができる。データ接続は、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含んでもよい。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであってもよい。
本開示の技法は、必ずしもワイヤレスの用途または設定に限定されるとは限らない。この技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、dynamic adaptive streaming over HTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上へ符号化されるデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例などの様々なマルチメディア適用例のうちのいずれかをサポートするビデオコーディングに適用されてもよい。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオ放送、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向ビデオ送信をサポートするように構成されてもよい。
図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。デスティネーションデバイス14は、入力インターフェース28と、ビデオデコーダ30と、表示デバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を適用するように構成されてもよい。他の例では、ソースデバイスおよびデスティネーションデバイスは、他の構成要素または配置を含んでもよい。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信することがある。同様に、デスティネーションデバイス14は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースすることがある。
図1の示されるシステム10は一例にすぎない。2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行されてもよい。一般に、本開示の技法はビデオ符号化デバイスによって実行されるが、この技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行されてもよい。その上、本開示の技法は、ビデオプリプロセッサによっても実行されてもよい。ソースデバイス12およびデスティネーションデバイス14は、ソースデバイス12がデスティネーションデバイス14に送信するためのコーディングされたビデオデータを生成するようなコーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素および復号構成要素を含むように実質的に対称的な方法で動作してもよい。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のためのビデオデバイス12、14間の一方向または双方向ビデオ送信をサポートしてもよい。
ソースデバイス12のビデオソース18は、ビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェースなどのビデオキャプチャデバイスを含んでもよい。さらなる代替として、ビデオソース18は、ソースビデオとしてコンピュータグラフィックスベースのデータをまたは、ライブビデオ、アーカイブされたビデオ、およびコンピュータにより生成されたビデオの組合せを生成することができる。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12およびデスティネーションデバイス14は、いわゆるカメラ付き携帯電話またはビデオ付き携帯電話を形成してもよい。しかしながら、上述されたように、本開示において説明される技法は、一般に、ビデオコーディングに適用可能であることがあり、ワイヤレス用途および/または有線用途に適用されることがある。各々の場合において、キャプチャされた、事前にキャプチャされた、またはコンピュータにより生成されたビデオは、ビデオエンコーダ20によって符号化されてもよい。次いで、符号化されたビデオ情報は、出力インターフェース22によって、コンピュータ可読媒体16に出力されてもよい。
コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含んでもよい。いくつかの例では、ネットワークサーバ(図示せず)は、ソースデバイス12から符号化されたビデオデータを受信することができ、たとえば、ネットワーク送信を介して、デスティネーションデバイス14に符号化されたビデオデータを提供することができる。同様に、ディスクスタンプ設備などの媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化されたビデオデータを受信することができ、符号化されたビデオデータを含むディスクを製造することができる。したがって、コンピュータ可読媒体16は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むと理解されてもよい。
デスティネーションデバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、ビデオデコーダ30によっても使用されるシンタックス情報を含むことがあり、このシンタックス情報は、ブロックおよび他のコーディングされた単位の特性および/または処理を記述するシンタックス要素を含む。表示デバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプの表示デバイスなどの様々な表示デバイスのうちのいずれかを備えてもよい。
ビデオエンコーダ20およびビデオデコーダ30は、ITU-T H.265とも呼ばれるHigh Efficiency Video Coding(HEVC)規格などのビデオ圧縮規格に従って動作してもよい。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、Advanced Video Coding(AVC)と呼ばれるITU-T H.264規格、またはそのような規格の拡張などの他のプロプライエタリ規格または業界規格に従って動作してもよい。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG-2とITU-T H.263とを含む。図1には示されないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと一体化されることがあり、共通のデータストリームまたは別々のデータストリームにおけるオーディオとビデオとの両方の符号化を処理するために、適切なMUX-DEMUXユニットまたは他のハードウェアおよびソフトウェアを含むことがある。該当する場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠してもよい。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの様々な適切なエンコーダ回路のいずれかとして実装されてもよい。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を適切な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行してもよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれることがあり、これらのいずれもが、それぞれのデバイスの中で複合エンコーダ/デコーダ(コーデック)の一部として統合されることがある。
本開示では、"N×N"および「N対N」は、垂直方向および水平方向の次元に関するビデオブロックのピクセルの次元、たとえば、16×16のピクセル、または16対16のピクセルを指すために、互換的に使用されてもよい。一般に、16×16のブロックは、垂直方向に16ピクセル(y=16)と水平方向に16ピクセル(x=16)とを有する。同様に、N×Nのブロックは、一般に、垂直方向にNピクセルと水平方向にNピクセルとを有し、ここでNは、負ではない整数値を表す。ブロック中のピクセルは、行および列に配置されてもよい。その上、ブロックは、必ずしも水平方向で垂直方向と同じ数のピクセルを有しなくてもよい。たとえば、ブロックは、N×Mのピクセルを備えることがあり、ここでMは、必ずしもNと等しいとは限らない。
CUのPUを使用するイントラ予測またはインター予測コーディングに続いて、ビデオエンコーダ20は、CUのTUの残差データを計算してもよい。PUは、空間領域(ピクセル領域とも呼ばれる)における予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備えることがあり、TUは、変換、たとえば離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換を残差ビデオデータに適用した後の、変換領域における係数を備えることがある。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差に対応してもよい。ビデオエンコーダ20は、CUの残差データを表す量子化された変換係数を含むようにTUを形成してもよい。すなわち、ビデオエンコーダ20は、残差データを(残差ブロックの形式で)計算し、残差ブロックを変換して変換係数のブロックを作成し、変換係数を量子化して量子化された変換係数を形成してもよい。ビデオエンコーダ20は、量子化された変換係数、ならびに他のシンタックス情報(たとえば、TUのための分割情報)を含む、TUを形成してもよい。
上で述べられたように、変換係数を作成するための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行してもよい。量子化は、一般に、係数を表すために使用されるデータの量をできる限り減らすために変換係数が量子化され、さらなる圧縮が行われるプロセスを指す。量子化プロセスは、係数の一部またはすべてと関連付けられたビット深度を低減することができる。たとえば、nビット値は、量子化の間にmビット値に切り捨てられることがあり、ここでnはmよりも大きい。
量子化に続いて、ビデオエンコーダは、変換係数をスキャンすることができ、量子化された変換係数を含む2次元行列から1次元ベクトルを作成する。スキャンは、より高いエネルギー(したがってより低い周波数)の係数をアレイの前方に置き、より低いエネルギー(したがってより高い周波数)の係数をアレイの後方に置くように設計されてもよい。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化されることが可能なシリアル化されたベクトルを作成するために、事前に定義されたスキャン順序を利用して量子化された変換係数をスキャンしてもよい。他の例では、ビデオエンコーダ20は、適応スキャンを実行してもよい。量子化された変換係数をスキャンして1次元ベクトルを形成した後、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースのコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔パーティショニングエントロピー(PIPE)コーディング、または別のエントロピー符号化方法に従って、1次元ベクトルをエントロピー符号化することができる。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30により使用するための符号化されたビデオデータと関連付けられるシンタックス要素をエントロピー符号化してもよい。
CABACを実行するために、ビデオエンコーダ20は、送信されるべきシンボルにコンテキストモデル内のコンテキストを割り当ててもよい。コンテキストは、たとえば、シンボルの隣接値が0ではないかどうかに関連してもよい。CAVLCを実行するために、ビデオエンコーダ20は、送信されるべきシンボルのための可変長コードを選択してもよい。VLCにおけるコードワードは、比較的より短いコードがより可能性が高いシンボルに対応し、より長いコードがより可能性が低いシンボルに対応するように構築されてもよい。このように、VLCの使用は、たとえば、送信されるべき各シンボルに等長コードワードを使用して、ビットの節約を達成してもよい。確率の決定は、シンボルに割り当てられたコンテキストに基づいてもよい。
一般に、ビデオデコーダ30は、ビデオエンコーダ20により実行されるものと実質的に同様の、しかし逆のプロセスを実行して、符号化されたデータを復号する。たとえば、ビデオデコーダ30は、受信されたTUの係数を逆量子化および逆変換して残差ブロックを再生する。ビデオデコーダ30は、シグナリングされた予測モード(イントラ予測またはインター予測)を使用して、予測されたブロックを形成する。次いで、ビデオデコーダ30は、予測されたブロックと残差ブロックを(ピクセルごとに)組み合わせて元のブロックを再生する。デブロッキングプロセスを実行してブロック境界に沿った視覚的なアーティファクトを減らすことなどの追加の処理が実行されてもよい。さらに、ビデオデコーダ30は、ビデオエンコーダ20のCABAC符号化プロセスと実質的に同様の、しかし逆の方式で、CABACを使用してシンタックス要素を復号してもよい。
ビデオエンコーダ20およびビデオデコーダ30は、以下で論じられる様々な技法のいずれかを単独で、または任意の組合せで実行するように構成されてもよい。
本開示の技法は、2レベルのマルチタイプツリー構造を含む。第1のレベル(「領域ツリーレベル」と呼ばれる)では、ビデオデータのピクチャまたはブロックは領域へと分割され、領域の各々が、大きいブロックを小さいブロックへと迅速に(たとえば、4分木または16分木を使用して)パーティショニングすることが可能な、単一ツリータイプまたは複数ツリータイプを伴う。第2のレベル(予測レベル)では、領域はさらにマルチタイプツリー(さらなる分割を含まない)を用いて分割される。予測ツリーのリーフノードは、本開示では簡潔にするためにコーディング単位(CU)と呼ばれる。
したがって、以下のことが本開示のマルチタイプツリーに当てはまることがある。
a)予測ツリーのルートはある領域ツリーのあるリーフノードである。
b)「さらなる分割なし」は領域ツリーと予測ツリーとの両方に対して特別なツリータイプと見なされる。
c)領域ツリーと予測ツリーに対して別々に最大のツリー深度をビデオエンコーダ20はシグナリングし、ビデオデコーダ30は受信してもよい。すなわち、構造の各レベルの最大深度(すなわち、領域ツリーおよび予測ツリー)は、独立の変数によって制御されてもよい。代替的に、構造の最大の全体深度は、各レベルの最大深度の合計としてシグナリングされてもよい。一例では、最大深度は、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、および/またはスライスヘッダにおいてシグナリングされる。別の例では、領域ツリーの最大深度および予測ツリーの最大深度が、領域ツリーの各深度に加えて、スライスヘッダにおいてシグナリングされる。たとえば、領域ツリーの最大深度は3としてシグナリングされる。次いで、領域ツリーのdepth0、depth1、depth2、およびdepth3に加えて予測ツリーの最大深度を示すために、4つの値がさらにシグナリングされる。
d)代替的に、領域ツリーおよび予測ツリーのツリー深度情報は一緒にシグナリングされてもよい。たとえば、最大のCTUサイズを仮定すると、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、および/またはスライスヘッダにおいて、まず最大の領域ツリー深度がシグナリングされてもよい。次いで、予測ツリーの開始レベルを示す、領域ツリーのルートレベルに対する相対的なオフセットがシグナリングされてもよい。最後に、予測ツリーレベル情報がシグナリングされてもよい。異なる時間レベルのピクチャが同じツリー深度の制約を有することも有しないこともあることに留意されたい。たとえば、より時間レベルの低いピクチャは(領域ツリーもしくは予測ツリーのいずれか、または両方に対して)より大きなツリー深度を有してもよいが、より時間レベルの高いピクチャは(領域ツリーもしくは予測ツリーのいずれか、または両方に対して)より小さなツリー深度を有してもよい。領域ツリーと予測ツリーとの間の相対的なツリー深度のオフセットは、同じであることも同じではないこともある。
e)「強制分割」(ピクチャ/スライス/タイル境界に達したときのシグナリングを伴わない自動分割)は、領域ツリーレベルのみ、または予測ツリーレベルのみにあることが可能であり、それらとの両方にあることは可能ではない。領域ツリーの最も低いレベルがそれでもすべての境界ピクセルを含むことができないとき、最も低い領域ツリーレベルを使用する境界ピクセルを含めるために、境界パディングが発動される。「強制分割」によるツリー深度は、事前に定義されたまたはシグナリングされた最大ツリー深度によって制約される必要はないことに留意されたい。
f)領域ツリー深度および予測ツリー深度は互いに重複することもあり、または重複しないこともある。それは、シグナリングされたツリー深度情報から導出されることがあり、またはシーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、および/もしくはスライスヘッダにおいて個別のフラグとしてシグナリングされることがある。
g)領域ツリーリーフノード内の予測ツリーの分割情報は、構文解析の間に領域ツリーリーフノード内のCUの数が領域ツリーリーフノード内の最初のCUを解析する前に知られるように、領域ツリーリーフのCU情報(限定はされないが、スキップフラグ、マージインデックス、インター/イントラモード、予測情報、動き情報、変換情報、残差および量子化情報を含む)の前にシグナリングされてもよい。
加えて、または代わりに、ビデオエンコーダ20およびビデオデコーダ30は、領域ツリーレベルでいくつかのコーディングツールを適用またはシグナリングするように構成されてもよい。言い換えると、いくつかのコーディングツールの利用可能性は領域ツリーレベルに依存してもよい。コーティングツールは、CUの境界にまたがって、それらのCUが同じ領域ツリーノードまたは領域ツリーリーフノードに属する限り、適用されてもよい。一部のコーディングツールは、ある領域ツリーのあるリーフノードのみにおいて適用および/またはシグナリングされてもよい。たとえば、次の通りである。
a.OBMC:OBMCが領域ツリーリーフ内で関連付けられる領域内で有効であるかどうかを示すために、フラグまたはモード情報が領域ツリーリーフノードレベルでシグナリングされてもよい。OBMCが有効である場合、領域内のCU境界は、HEVCにおけるPU境界またはJEMにおけるCU内のサブPU境界と同じ方法で扱われる。すなわち、OBMCは、領域ツリーリーフノードと関連付けられる領域内のCU境界の各辺に適用されてもよい。
1.OBMCが有効であるかどうかは、領域のサイズなどのコーディングされた情報に基づいて導出され、または部分的に導出されてもよい。たとえば、領域サイズが閾値(16×16など)より大きいとき、OBMCはオンであると見なすことができるので、シグナリングは不要である。領域サイズが閾値より小さいとき、フラグまたはOBMCモード情報がシグナリングされてもよい。
ii.重複変換:ブロックサイズを有する変換が、領域ツリーリーフノード内の予測ブロックのすべてまたはグループの領域をカバーし、予測された残差をコーディングするために使用される。
1.一例では、重複変換が領域のために使用されるかどうかを示すために、フラグまたは変換ツリー情報が領域ツリーリーフノードレベルでシグナリングされる。
a.一例では、さらに、変換ツリー情報がシグナリングされるとき、それは予測ツリーとは異ならなければならない。
b.別の例では、現在の領域ツリーリーフノードと同じ大きさの単一の変換が使用されるか、または予測ブロックサイズと各々が揃っている複数の変換が使用されるかを示すために、フラグまたは変換ツリー情報が領域ツリーリーフノードレベルでシグナリングされる。
2.重複変換が領域のために使用されるとき、その領域の内部のすべてのCUのコーディング済ブロックフラグ(CBF)情報が、CUレベルの代わりに領域ツリーリーフレベルでシグナリングされてもよい。
3.一例では、重複変換が領域ツリーリーフノードのために適用されるとき、OBMCは常に領域ツリーリーフノードのために適用される。
iii.スーパースキップ/マージモード:領域内のすべてのCUがスキップモードまたはマージモードでコーディングされるので、モード情報がCUレベルでシグナリングされないことを示すために、フラグまたはモード情報が領域ツリーリーフレベルでシグナリングされてもよい。
iv.スーパーイントラ/インターコーディングモード:CUが同じモード情報を使用すべきであることを示すために、フラグまたはモード情報のインデックス(イントラモードまたはインターモードなど)が領域ツリーリーフレベルでシグナリングされてもよい。
v.スーパーFRUCモード:領域ツリー内のすべてのCUがFRUCモードでコーディングされることを示すために、フラグまたはモード情報が領域ツリーリーフレベルでシグナリングされてもよい。
vi.スーパーモード情報(スーパースキップ/マージ、スーパーイントラ/インター、およびスーパーFRUCなど)が、領域ツリーリーフノード内のCUの数が閾値より大きいときにのみシグナリングされてもよい。
1.閾値は事前に定義されることがあり、またはVPS、SPS、PPS、もしくはスライスヘッダなどの中のビットストリームにおいてシグナリングされることがある。
加えて、または代わりに、ビデオエンコーダ20およびビデオデコーダ30は、領域ツリーの任意のノードにおいてコーディングツールを表すデータを適用および/またはコーディングしてもよい。たとえば、サンプル適応オフセット(SAO)および/または適応ループフィルタ(ALF)などのフィルタリングツールは、SAO情報がCTUレベルでシグナリングされることが可能であり、SAOおよびALFなどのフィルタリングツールのための情報が領域ツリーの任意のノードで(必ずしもリーフノードではない)シグナリングされることが可能であるので、フィルタリングされるべき領域がノードと関連付けられる領域であるという点で、HEVCと異なってもよい。
加えて、または代わりに、ビデオエンコーダ20およびビデオデコーダ30は、HEVC型のコーディングツリー構造に加えて、中央−側部3分木に似たパーティションを使用するように構成されてもよい。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、AMPに加えて、またはAMPを置き換えるために、PUパーティションタイプとして中央−側部3分木などの新しいパーティションを使用してもよい。
加えて、または代わりに、領域ツリーのリーフノードは、コーディング効率と複雑さとの間でバランスがとれた、量子化パラメータ(QP)デルタコーディングのための点を提供してもよい。近隣が領域ツリーにおいてよく定義されているので、QP予測子は、上の、左の、および以前にコーディングされたQP値を使用して、ある領域ツリーのリーフノードにおいて計算されてもよい。QP値はCUごとに変化することがあり、CUはコーディングのために親領域ツリーノードからの同じ基本値を共有することがある。
それらのいずれかまたは両方がビデオエンコーダ20およびビデオデコーダ30によって実行されてもよい追加の例が、以下の図12に関してより詳細に説明される。
ビデオエンコーダ20はさらに、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、およびシーケンスベースのシンタックスデータなどのシンタックスデータをたとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはシーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、もしくはビデオパラメータセット(VPS)などの他のシンタックスデータにおいて、ビデオデコーダ30に送信することができる。
ビデオエンコーダ20およびビデオデコーダ30は各々、該当する場合、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの様々な適切なエンコーダ回路またはデコーダの回路のうちのいずれかとして実装されてもよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれることがあり、これらのいずれもが、複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合されることがある。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/または携帯電話などのワイヤレス通信デバイスを備えてもよい。
図2は、2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を実装してもよい、ビデオエンコーダ20の例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行してもよい。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのうちのいずれかを指してもよい。単方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのうちのいずれかを指してもよい。
図2に示されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照ピクチャメモリ64(復号ピクチャバッファ(DPB)とも呼ばれてもよい)と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。モード選択ユニット40は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、パーティションユニット48とを含む。ビデオブロック再構築のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。ブロック境界をフィルタリングしてブロッキネスアーティファクトを再構築されたビデオから除去するために、デブロッキングフィルタ(図2に示さず)も含まれてもよい。所望される場合、デブロッキングフィルタは、一般に、加算器62の出力をフィルタリングする。追加のフィルタ(ループ内またはループ後)も、デブロッキングフィルタに加えて使用されてもよい。そのようなフィルタは、簡潔のために示されないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタリングしてもよい。
符号化プロセスの間に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割されてもよい。動き推定ユニット42および動き補償ユニット44は、時間的予測を行うために、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対する受信されたビデオブロックのインター予測符号化を実行する。代替的に、イントラ予測ユニット46は、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測符号化を実行してもよい。ビデオエンコーダ20は、たとえば、ビデオデータの各ブロックに対する適切なコーディングモードを選択するために、複数のコーディングパスを実行してもよい。
その上、パーティションユニット48は、本開示の技法を使用してビデオデータのコーディングツリーブロックをパーティショニングしてもよい。すなわち、パーティションユニット48は最初に、マルチタイプツリーの領域ツリーを使用してCTBをパーティショニングすることができ、最終的に1つまたは複数の領域ツリーリーフノードをもたらす。様々な例において、パーティションユニット48は、4分木パーティションまたは16分木パーティションに従って領域ツリーをパーティショニングしてもよい。4分木パーティションは各非リーフノードを4つの子ノードへとパーティショニングすることを含むが、16分木パーティションは各非リーフノードを16個の子ノードへとパーティショニングすることを含む。
パーティションユニット48はさらに、それぞれの予測ツリーを使用して領域ツリーリーフノードの各々をパーティショニングしてもよい。予測ツリーは、2分木、中央−側部3分木、および/または4分木としてパーティショニングされてもよい。すなわち、パーティションユニット48は、予測ツリーの各ノードを(4分木のように)4つの等しいサイズの部分へと、(2分木のように)水平もしくは垂直に2つに等しいサイズの部分へと、または(中央−側部3分木のように)水平もしくは垂直に中央領域および2つのより小さな側部領域へとパーティショニングしてもよい。加えて、または代わりに、パーティションユニット48は、非対称動きパーティション(AMP)を使用して予測ツリーのノードをパーティショニングしてもよい。いくつかの例では、中央−側部3分木パーティションはAMPを置き換えてもよいが、他の例では、中央−側部3分木パーティションはAMPを補足してもよい。図1に関して説明されたように、パーティションユニット48は、CTBのためのマルチタイプツリーがどのようにパーティショニングされるかを示すシンタックス要素の値を生成することができ、このシンタックス要素はエントロピー符号化ユニット56によって符号化されてもよい。
モード選択ユニット40は、たとえば誤差結果に基づいて(たとえば、レート歪み分析を使用して)予測モードのうちの1つ(イントラ、インター、またはスキップ)を選択することができ、得られた予測されたブロックを、残差データを生成するために加算器50に提供し、参照フレームとして使用するための符号化されたブロックを再構築するために加算器62に提供することができる。モード選択ユニット40はまた、動きベクトル(たとえば、マージモードまたはAMVPモードに従ってコーディングされる)、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット56に与える。
動き推定ユニット42および動き補償ユニット44は、高度に集積されてもよいが、概念的な目的のために別々に示される。動き推定ユニット42によって実行される動き推定は、ビデオブロックに対する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(またはコーディングされた他のユニット)内でコーディングされている現在のブロックに対する、参照フレーム(またはコーディングされた他のユニット)内の予測ブロックに対する、現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示してもよい。予測ブロックは、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分尺度によって決定されてもよい、ピクセル差分の観点で、コーディングされるべきブロックと厳密に一致することが見出されるブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64内に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算してもよい。たとえば、ビデオエンコーダ20は、参照ピクチャの4分の1ピクセル位置の値、8分の1ピクセル位置の値、または他の分数ピクセル位置の値を補間してもよい。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力してもよい。
動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライス中のビデオブロックのPUの動きベクトルを計算する。参照ピクチャは、その各々が参照ピクチャメモリ64内に記憶された1つまたは複数の参照ピクチャを識別する、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されてもよい。動き推定ユニット42は、エントロピー符号化ユニット56および動き補償ユニット44に計算された動きベクトルを送信する。
動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを伴ってもよい。やはり、動き推定ユニット42および動き補償ユニット44は、いくつかの例では、機能的に統合されてもよい。現在のビデオブロックのPUの動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つの中で動きベクトルが指す予測ブロックの位置を特定してもよい。加算器50は、以下で論じられるように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット42は、ルーマ成分に対する動き推定を実行し、動き補償ユニット44は、ルーマ成分に基づいて計算された動きベクトルをクロマ成分とルーマ成分との両方に使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用するためのビデオブロックおよびビデオスライスと関連付けられるシンタックス要素を生成してもよい。
イントラ予測ユニット46は、上で説明されたように、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測の代替として、現在のブロックをイントラ予測してもよい。具体的には、イントラ予測ユニット46は、現在のブロックを符号化するために使用するイントラ予測モードを決定してもよい。いくつかの例では、イントラ予測ユニット46は、たとえば、別々の符号化パスの間、様々なイントラ予測モードを使用して現在のブロックを符号化することができ、イントラ予測ユニット46(または、いくつかの例ではモード選択ユニット40)は、試験されたモードから使用すべき適切なイントラ予測モードを選択することができる。
たとえば、イントラ予測ユニット46は、様々な試験されたイントラ予測モードに対してレート歪み分析を使用してレート歪み値を計算し、試験されたモードの中から最良のレート歪み特性を有するイントラ予測モードを選択してもよい。レート歪み分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間の歪み(または誤差)の量、ならびに、符号化されたブロックを生成するために使用されたビットレート(すなわち、ビット数)を決定する。イントラ予測ユニット46は、どのイントラ予測モードがブロックのための最良のレート-歪み値を示すのかを決定するために、様々な符号化されたブロックに対する歪みおよびレートから比を計算してもよい。
ブロックのためのイントラ予測モードを選択した後、イントラ予測ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供してもよい。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化してもよい。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)を含んでもよい、送信されるビットストリーム構成データの中に、コンテキストの各々のために使用する、様々なブロックのための符号化コンテキストの定義と、最もあってもよいイントラ予測モードの指示と、イントラ予測モードインデックステーブルと、修正されたイントラ予測モードインデックステーブルとを含んでもよい。
ビデオエンコーダ20は、モード選択ユニット40からの予測データをコーディングされている元のビデオブロックから減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、変換係数値を備えるビデオブロックを作成する。DCTの代わりに、ウェーブレット変換、整数変換、サブバンド変換、離散サイン変換(DST)、または他のタイプの変換が使用されてもよい。いずれの場合にも、変換処理ユニット52は、残差ブロックに変換を適用し、変換係数のブロックを作成する。変換は、残差情報をピクセル領域から周波数領域などの変換領域に変換してもよい。変換処理ユニット52は、得られた変換係数を量子化ユニット54に送信してもよい。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部またはすべてと関連付けられたビット深度を低減することができる。量子化の程度は、量子化パラメータを調整することによって修正されてもよい。
量子化に続いて、エントロピー符号化ユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースのコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔パーティションエントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行してもよい。コンテキストベースのエントロピーコーディングの場合には、コンテキストは、隣接ブロックに基づいてもよい。エントロピー符号化ユニット56によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)へ送信されるか、または後の送信もしくは取出しのためにアーカイブされてもよい。
逆量子化ユニット58および逆変換ユニット60は、ピクセル領域における残差ブロックを再構築するために、それぞれ、逆量子化および逆変換を適用する。具体的には、加算器62は、動き補償ユニット44またはイントラ予測ユニット46によって前に作成された動き補償された予測ブロックに再構築された残差ブロックを加算して、参照ピクチャメモリ64に記憶するための再構築されたビデオブロックを作成する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために、参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用されてもよい。
さらに、本開示の技法に従って、モード選択ユニット40は、コーディングツリーブロック(CTB)のいくつかの予測ツリーのために1つまたは複数の「スーパーモード」を実行することを選んでもよい。そのようなスーパーモードは、たとえば、スーパースキップモード、スーパーマージモード、スーパーイントラモード、スーパーインターモード、またはスーパーFRUCモードを含んでもよい。一般に、スーパーモードでは、ビデオエンコーダ20は、CTBの予測ツリーのルートノードにおいて(または領域ツリーリーフノードにおいて)対応する「スーパーモード」情報を符号化し、この情報を予測ツリーのすべてのCUに適用するので、ビデオエンコーダ20は予測ツリーのCUに対して別々の対応する情報を符号化するのを避ける。たとえば、スーパースキップモードでは、ビデオエンコーダ20は、スキップモードを使用して予測ツリーのすべてのCUを符号化し、CUに対していかなる追加の予測情報も符号化しない。別の例として、スーパーイントラモードまたはスーパーインターモードでは、ビデオエンコーダ20は、予測ツリーに対してイントラ予測情報またはインター予測情報を1回符号化し、この同じ予測情報を予測ツリーのすべてのCUに適用する。ビデオエンコーダ20は、領域ツリーレベルおよび予測ツリーレベルの分割情報、ならびに変換情報をなどの他の情報を平常通り符号化する。
いくつかの例では、ビデオエンコーダ20は、予測ツリーに含まれるCUの数が閾値より大きいときにのみ、スーパーモードを有効にする。ビデオエンコーダ20は、たとえば、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、スライスヘッダ、CTBヘッダなどにおいて、閾値を定義するシンタックス要素を符号化してもよい。
その上、本開示の技法によれば、ビデオエンコーダ20は、1つまたは複数の有効なコーディングツールを表すシンタックス要素を符号化し、また、CTBの符号化またはCTBの予測ツリーの間に有効なコーディングツールを適用してもよい。たとえば、ビデオエンコーダ20は、重複ブロック動き補償(OBMC)、重複変換、および/もしくは上で論じられた様々なスーパーモードのいずれかの、いずれかまたはすべてを有効にしてもよい。動き補償ユニット44は、たとえば図7および図8に関して、以下でより詳細に論じられるようにOBMCを実行するように構成されてもよい。変換処理ユニット52は、上で論じられたように重複変換を実行するように構成されてもよい。
このようにして、図2のビデオエンコーダ20は、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を符号化し、領域ツリーが1つまたは複数の領域ツリーリーフノードを有し、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を符号化し、予測ツリーがそれぞれのコーディング単位(CU)を定義する1つまたは複数の予測リーフノードを有し、CUの各々に対するビデオデータを符号化するように構成される、ビデオエンコーダの例を表す。
図3は、2レベルのマルチタイプツリーフレームワークを使用してビデオデータをコーディングするための技法を実装してもよい、ビデオデコーダ30の例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明された符号化パスと全体的に逆の復号パスを実行してもよい。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成することができ、一方、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成することができる。
ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックの予測データを生成してもよい。ビデオフレームがインターコーディングされる(すなわち、BまたはP)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックの予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照フレームリスト、リスト0およびリスト1を構築してもよい。
復号プロセスの間に、ビデオデコーダ30は、ビデオエンコーダ20から符号化されたビデオスライスのビデオブロックと関連するシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化された係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成する。エントロピー復号ユニット70は、動き補償ユニット72に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信してもよい。
コーディングツリーブロック(CTB)レベルのシンタックス要素は、CTBのマルチタイプツリーがどのようにパーティショニングされるかを示すシンタックス要素を含んでもよい。具体的には、エントロピー復号ユニット70は、領域ツリーレベルでCTBの1つまたは複数のシンタックス要素を復号することができ、最終的に1つまたは複数の領域ツリーリーフノードを生み出す。各領域ツリーリーフノードは、対応する予測ツリーシンタックス要素と関連付けられてもよい。予測ツリーシンタックス要素は、対応する領域ツリーリーフノードがどのようにパーティショニングされるか、たとえば、水平もしくは垂直の2分木パーティションに従ってパーティショニングされるか、水平もしくは垂直の中央−側部3分木パーティションに従ってパーティショニングされるか、4分木パーティションに従ってパーティショニングされるか、または非対称動きパーティション(AMP)に従ってパーティショニングされるかを示してもよい。予測ツリーは最終的に、1つまたは複数のコーディング単位(CU)を生み出してもよい。
動き補償ユニット72は、動きベクトルと他のシンタックス要素とを構文解析することによって、現在のビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して、復号されている現在のビデオブロックの予測ブロックを生成する。たとえば、動き補償ユニット72は、受信されたシンタックス要素の一部を使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、BスライスまたはPスライス)と、スライスのための参照ピクチャリストのうちの1つまたは複数のための構築情報と、スライスの各々のインター符号化されたビデオブロックのための動きベクトルと、スライスの各々のインターコーディングされたビデオブロックのためのインター予測状態と、現在のビデオスライスの中のビデオブロックを復号するための他の情報とを決定する。
動き補償ユニット72はまた、補間フィルタに基づいて補間を実行してもよい。動き補償ユニット72は、ビデオブロックの符号化の間にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための補間された値を計算してもよい。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、補間フィルタを使用して、予測ブロックを生成してもよい。
逆量子化ユニット76は、ビットストリームにおいて提供され、エントロピー復号ユニット70によって復号された、量子化された変換係数を逆量子化する(inverse quantize)、すなわち逆量子化する(de-quantize)。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオデコーダ30によって計算された量子化パラメータQPYをビデオスライス中の各ビデオブロックのために使用することを含んでもよい。
逆変換ユニット78は、ピクセル領域における残差ブロックを生成するために、変換係数に逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを適用する。
動き補償ユニット72が、動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックの予測ブロックを生成した後、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号されたブロックをフィルタリングするように、デブロッキングフィルタも適用されてもよい。(コーディングループ内またはコーディングループ後のいずれかの)他のループフィルタも、ピクセル遷移を滑らかにするために、または別様にビデオ品質を改善するために使用されてもよい。次いで、所与のフレームまたはピクチャ中の復号されたビデオブロックは、参照ピクチャメモリ82に記憶され、参照ピクチャメモリ82は、後続の動き補償のために使用される参照ピクチャを記憶する。参照ピクチャメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上で後に提示するための復号されたビデオを記憶する。
さらに、本開示の技法に従って、エントロピー復号ユニット70は、コーディングツリーブロック(CTB)のいくつかの予測ツリーのために1つまたは複数の「スーパーモード」が有効であるかどうかを表すシンタックス要素を復号してもよい。そのようなスーパーモードは、たとえば、スーパースキップモード、スーパーマージモード、スーパーイントラモード、スーパーインターモード、またはスーパーFRUCモードを含んでもよい。一般に、スーパーモードでは、ビデオデコーダ30は、CTBの予測ツリーのルートノードにおいて(または領域ツリーリーフノードにおいて)対応する「スーパーモード」情報を復号し、この情報を予測ツリーのすべてのCUに適用するので、ビデオデコーダ30は予測ツリーのCUに対して別々の対応する情報を復号するのを避ける。たとえば、スーパースキップモードでは、ビデオデコーダ30は、スキップモードを使用して予測ツリーのすべてのCUを復号し、CUに対していかなる追加の予測情報も復号しない。別の例として、スーパーイントラモードまたはスーパーインターモードでは、ビデオデコーダ30は、予測ツリーに対してイントラ予測情報またはインター予測情報を1回復号し、この同じ予測情報を予測ツリーのすべてのCUに適用する。ビデオデコーダ30は、領域ツリーレベルおよび予測ツリーレベルの分割情報、ならびに変換情報をなどの他の情報を平常通り復号する。
いくつかの例では、ビデオデコーダ30は、予測ツリーに含まれるCUの数が閾値より大きいときにのみ、スーパーモードを有効にする。ビデオデコーダ30は、たとえば、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、スライスヘッダ、CTBヘッダなどにおいて、閾値を定義するシンタックス要素を復号してもよい。
その上、本開示の技法によれば、ビデオデコーダ30は、1つまたは複数の有効なコーディングツールを表すシンタックス要素を復号し、また、CTBの復号またはCTBの予測ツリーの間に有効なコーディングツールを適用してもよい。たとえば、ビデオデコーダ30は、重複ブロック動き補償(OBMC)、重複変換、および/もしくは上で論じられた様々なスーパーモードのいずれかの、いずれかまたはすべてを有効にしてもよい。動き補償ユニット72は、たとえば図7および図8に関して、以下でより詳細に論じられるようにOBMCを実行するように構成されてもよい。逆変換ユニット78は、上で論じられたように重複変換を実行するように構成されてもよい。
このようにして、図3のビデオデコーダ30は、ビデオデータを記憶するように構成されるメモリと、回路で実装されるプロセッサとを含む、ビデオデコーダの例を表し、このプロセッサは、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号し、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4であり、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定し、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号し、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義し、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定し、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号するように構成される。
図4は、例示的なコーディングツリーブロック(CTB)100の例を示すブロック図である。HEVCでは、スライスの中の最大のコーディング単位は、コーディングツリーブロック(CTB)と呼ばれる。CTB100などのCTBは、そのノードがコーディング単位(CU)に対応する、4分木データ構造(または単に4分木)を含む。具体的には、4分木データ構造のルートノードはCTBに対応する。4分木データ構造の中の各ノードは、リーフノード(子ノードを有しない)または4つの子ノードを有する親ノードのいずれかである。CU102は、4分木のリーフノードに対応するCUの一例を表す。CTBのサイズは、HEVCメインプロファイルにおいて16×16ピクセル〜64×64ピクセルにわたる(ただし、技術的には8×8のCTBサイズをサポートすることができる)。CTBは、図4に示されるものなどの4分木の方式でコーディング単位(CU)へと再帰的に分割されてもよい。4分木データ構造のリーフノードは、予測単位(PU)および変換単位(TU)を含むCUに対応する。
CUは、CTBと同じサイズであってもよいが、8×8程度の小ささであってもよい。各符号化ユニットは、イントラモードまたはインターモードのいずれかであってもよい、1つの予測モードを用いてコーディングされてもよい。CUがインターコーディングされるとき(すなわち、インターモード予測が適用されるとき)、CUは、2つもしくは4つの予測単位(PU)へとさらにパーティショニングされることがあり、またはさらなるパーティションが適用されないときには1つだけのPUになることがある。1つのCUの中に2つのPUが存在するとき、それらのPUは、CUの半分のサイズの長方形であってもよく、またはCUの1/4もしくは3/4のサイズを有する2つの長方形であってよい。
図5は、CUの例示的な予測単位(PU)を示すブロック図である。図5に示されるように、HEVCにおいて、インター予測モードでコーディングされるCUに対して8つの予測モード、すなわち、PART_2N×2N、PART_2N×N、PART_N×2N、PART_N×N、PART_2N×nU、PART_2N×nD、PART_nL×2N、およびPART_nR×2Nがある。CUがインターコーディングされるとき、動き情報の1つのセットが各PUに対して存在する。加えて、HEVCによれば、各PUは、動き情報のセットを導出するために固有のインター予測モードでコーディングされる。CUがHEVCに従ってイントラコーディングされるとき、2N×2NおよびN×Nのみが許されるPU形状であり、各PU内で、単一のイントラ予測モードがコーディングされる(一方でクロマ予測モードはCUレベルでシグナリングされる)。HEVCによれば、現在のCUサイズがSPSにおいて定義される最小のCUサイズに等しいとき、N×NのイントラPU形状のみが許容される。
図6は、例示的な4分木2分木(QTBT)構造120および対応するCTB122を示す概念図である。VCEG proposal COM16-C966(J. An、Y.-W. Chen、K. Zhang、H. Huang、Y.-W. Huang、およびS. Lei.、"Block partitioning structure for next generation video coding"、国際電気通信連合、COM16-C966、2015年9月)において、4分木2分木(QTBT)がHEVCを超える未来のビデオコーディング規格のために提案された。提案されたQTBT構造は、使用されるHEVCにおいて4分木構造より効率的であることをシミュレーションが示している。
COM16-C966の提案されるQTBT構造において、CTBはまず4分木によってパーティショニングされ、ここでノードが最小の許容される4分木リーフノードサイズ(MinQTSize)に達するまで、1つのノードの4分木分割を繰り返すことができる。4分木リーフノードサイズが最大の許容される2分木ルートノードサイズ(MaxBTSize)より大きくない場合、これは2分木によってさらにパーティショニングすることができる。ノードが最小の許容される2分木リーフノードサイズ(MinBTSize)または最大の許容される2分木深度(MaxBTDepth)に達するまで、1つのノードの2分木分割を繰り返すことができる。2分木リーフノードはCUと名付けられ、これは、さらなるパーティションなしで予測(たとえば、ピクチャ内またはピクチャ間予測)および変換のために使用される。
COM16-C966によれば、2分木分割において、対称的な水平分割および対称的な垂直分割という2つの分割タイプがある。
QTBTパーティション構造の一例では、CTUサイズは128×128(ルーマサンプルおよび2つの対応する64×64クロマサンプル)として設定され、MinQTSizeは16×16として設定され、MaxBTSizeは64×64として設定され、MinBTSize(幅と高さとの両方に対して)は4として設定され、MaxBTDepthは4として設定される。4分木リーフノードを生成するために、4分木パーティションがまずCTUに適用される。4分木リーフノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)のサイズを有してもよい。リーフ4分木ノードが128×128である場合、それは2分木によってさらに分割されず、それはサイズがMaxBTSize(すなわち、64×64)を超えるからである。それ以外の場合、リーフ4分木ノードはさらに2分木によってパーティショニングされる。したがって、4分木リーフノードは2分木のルートノードでもあり、2分木深度を0として有する。
2分木深度がMaxBTDepth(一例では4)に達するとき、それはさらなる分割が許可されないことを示唆する。2分木ノードの幅がMinBTSize(一例では4)に等しいとき、それはさらなる水平の分割が許可されないことを示唆する。同様に、2分木ノードの高さがMinBTSizeに等しいとき、それはさらなる垂直の分割が許可されないことを示唆する。2分木のリーフノードはCUと名付けられ、さらなるパーティションなしで予測および変換に従ってさらに処理される。
図6のCTB122は、QTBTを使用することによるブロックパーティションの例を表し、図6のQTBT120は、CTB122に対応する例示的なQTBTを表す。実線は4分木分割を表し、点線は2分木分割を示す。2分木の各分割(すなわち、非リーフ)ノードでは、どの分割タイプ(すなわち、水平または垂直)が使用されるかを示すために1つのフラグがシグナリングされ、この例では0が水平の分割を示し、1が垂直の分割を示す。4分木分割では、ブロックを水平および垂直に等しいサイズの4つのサブブロックへと常に分割するので、分割タイプを示す必要はない。したがって、QTBT120の領域ツリーレベル(すなわち、実線)のためのシンタックス要素(分割情報など)およびQTBT120の予測ツリーレベル(すなわち、破線)のためのシンタックス要素(分割情報など)をビデオエンコーダ20は符号化し、ビデオデコーダ30は復号することができる。QTBT120の予測ツリーの予測ツリーリーフノードのCUのための予測データおよび変換データなどのビデオデータをビデオエンコーダ20は符号化し、ビデオデコーダ30は復号することができる。
2016年1月15日に出願された、Li他、米国仮出願第62/279,233号は、マルチタイプツリー構造を説明する。上記の仮出願の方法を用いると、2分木、対称的な中央−側部ツリー(center-side tree)、および4分木などの複数ツリーのタイプを用いて、ツリーノードをさらに分割することができる。マルチタイプツリー構造が4分木2分木構造よりはるかに効率的であることをシミュレーションが示した。
QTBT120の例では、領域ツリーレベルは4分木を含み(ここで各非リーフノードは4つの子ノードを含む)、予測ツリーレベルは2分木を含む(ここで各非リーフノードは2つの子ノードを含む)。しかしながら、一般には、本開示の技法によれば、領域ツリーは、4以上の第1の数のノードを有する非リーフノード(たとえば、4つ、5つ、6つなどのノード)を含むことがあり、各領域ツリーリーフノードは、2以上の第2の数のノード(たとえば、2つ、3つ、4つなどのノード)を有する予測ツリーのルートノードとして活動してもよい。各予測ツリーリーフノードはCUに対応することがあり、これは本開示の技法によれば、予測情報および変換情報を含むが、いかなる分割情報もさらに含む必要がない。したがって、本開示の技法の例によれば、予測単位および変換単位は、予測単位および変換単位を含むCUと同じサイズであってもよい。
図7は、重複ブロック動き補償(OBMC)を使用してコーディングされたブロック130を示す概念図である。OBMCは、H.263(Video Coding for Low Bitrate Communication、document Rec. H.263、ITU-T、1995年4月)の開発において提案された。H.263において、OBMCは、8×8ブロックに対して実行され、2つの接続された隣接する8×8ブロックの動きベクトルが、図7の現在のブロック130などの現在のブロックのために使用される。たとえば、現在のブロック130の中の第1の8×8ブロック132に対して、それ自体の動きベクトルの他に、上および左の隣接する動きベクトルも、2つの追加の予測ブロックを生成するために適用される。このようにして、第1の8×8ブロック132の中の各画素は、3つの予測値を有し、これらの3つの予測値の加重平均が、最終的な予測として使用される。第2の8×8ブロック134は、それ自体の動きベクトル、ならびに上および右の隣接するブロックの動きベクトルを使用して予測される。第3の8×8ブロック136は、それ自体の動きベクトル、ならびに左の隣接するブロックの動きベクトルを使用して予測される。第4の8×8ブロック138は、それ自体の動きベクトル、ならびに右の隣接するブロックの動きベクトルを使用して予測される。
隣接ブロックが、コーディングされないかイントラモードを使用してコーディングされる、すなわち、隣接ブロックが、利用可能な動きベクトルを有しないとき、現在の8×8ブロックの動きベクトルが、隣接動きベクトルとして使用される。一方、現在のブロック130(図7に示されるような)第3の8×8ブロック136および第4の8×8ブロック138に対して、下の隣接ブロックは使用されない。言い換えれば、各MBに対して、その下のMBからの動き情報は、OBMCの間に現在のMBのピクセルを再構築するために使用されない。
図8は、HEVCにおいて適用されるようなOBMC、すなわちPUベースのOBMCの例を示す概念図である。2012年11月15日に出願された、Chien他、米国出願第13/678,329号、および2011年12月6日に出願された、Guo他、米国出願第13/311,834号は、境界140、142などのHEVCにおけるPU境界を平滑化するためのOBMCの適用を記述する。ChienおよびGuoの出願において提案された方法の例が図8に示される。たとえば、CUが、2つ(またはより多く)のPUを含むとき、これらの適用形態の技法に従って、PU境界付近の行/列は、OBMCによって平滑化される。PU0またはPU1の中で"A"または"B"を用いてマークされたピクセルに対して、2つの予測値が生成され、すなわち、それぞれPU0およびPU1の動きベクトルを適用することによって生成され、予測値の加重平均が、最終的な予測として使用される。
図9は、サブPUレベルのOBMCを実行する例を示す概念図である。Joint Exploration Test Model 2 (JEM) (J. Chen、E. Alshina、G. J. Sullivan、J.-R. Ohm、J. Boyce "Algorithm description of Joint Exploration Test Model 2"、JVET-B1001、2016年2月)では、サブPUレベルのOBMCが適用される。この例では、OBMCは、CUの右および下の境界を除き、すべての動き補償された(MC)ブロック境界のために実行される。その上、OBMCはルーマ成分とクロマ成分との両方に対して適用される。HEVCでは、MCブロックはPUに対応する。JEMでは、PUがサブPUモードでコーディングされるとき、PUの各サブブロックはMCブロックである。CU/PU境界を均一に処理するために、OBMCはすべてのMCブロック境界に対してサブブロックレベルで実行され、ここで図9に示されるようにサブブロックサイズは4×4に等しく設定される。
JEMでは、OBMCが現在のサブブロック(たとえば、図9の例では右から左へのハッシングで影を付けられたブロック)に適用されるとき、現在の動きベクトルの他に、4つの接続された隣接するサブブロックの動きベクトルも、利用可能であり現在の動きベクトルと同一ではない場合、現在のサブブロックの予測ブロックを導出するために使用される。複数の動きベクトルに基づくこれらの複数の予測ブロックは、現在のサブブロックの最終的な予測信号を生成するために重み付けられる。
隣接サブブロックの動きベクトルに基づいて予測ブロックをPNと表記し、Nは上、下、左、および右の隣接サブブロックのインデックスを示し、現在のサブブロックの動きベクトルに基づく予測ブロックをPCと表記する。PNがPCと同じPUに属するとき(およびしたがって、同じ動き情報を含むとき)、OBMCはPNから実行されない。それ以外の場合、PNの1つ1つのピクセルがPC中の同じピクセルに加算され、すなわち、PNの4つの行/列がPCに加算される。{1/4, 1/8, 1/16, 1/32}という例示的な加重係数がPNのために使用されることがあり、対応する加重係数{3/4, 7/8, 15/16, 31/32}がPCのために使用されることがある。
例外には、PNの2つの行/列しかPCに追加されない、小さいMCブロックがあってもよい(すなわち、PUサイズが8×4、4×8に等しいとき、またはPCがATMVPモードでコーディングされるとき)。この場合、{1/4, 1/8}という加重係数がPNのために使用されることがあり、加重係数{3/4, 7/8}がPCのために使用されることがある。PNが垂直に(または水平に)隣接するサブブロックの動きベクトルに基づいて生成されるとき、PNの同じ行(列)の中のピクセルは、同じ加重係数を用いてPCに加算されてもよい。PU境界のために、OBMCは境界の各側に適用されてもよい。図9の例では、OBMCはPU1とPU2の間の境界に沿って2回適用されてもよい。まず、OBMCは、PU1の内部の境界に沿って影付きブロックにPU2のMVを用いて適用されてもよい。第2に、OBMCは、PU2の内部の境界に沿って影付きブロックにPU1のMVを用いて適用されてもよい。他の例では、OBMCはCU境界の一辺に適用されることがあり、それは、現在のCUをコーディング(符号化または復号)するとき、ビデオコーダはコーディングされたCUを変更できないからである。
図10は、様々な64×64ブロックに対する非対称の動きパーティションの例を示す概念図である。重複変換は、PU境界にまたがるブロックに対して実行される変換である。一般に、普通は予測境界が不連続であるので、変換ブロックは予測ブロックと揃う。したがって、予測ブロックの境界にまたがる変換ブロックは、コーディング性能に有害であってもよい高周波の係数を作り出してもよい。しかしながら、普通はほとんど予測残差を示さないインターコーディングされたブロックに対して、エネルギーをより圧縮して様々な変換ブロックサイズの不要なシグナリングを避けるために、予測ブロックより大きい変換ブロックが時々有用であってもよい。
HEVCでは、残差4分木(RQT)を使用した変換コーディング構造が適用され、これは、http://www.hhi.fraunhofer.de/fields-of-competence/image-processing/research-groups/image-video-coding/hevc-high-efficiency-video-coding/transform-coding-using-the-residual-quadtree-rqt.htmlにおいて入手可能な、"Transform Coding Using the Residual Quadtree (RQT)"において論じられるように簡単に説明される。HEVCのデフォルト構成では通常は64×64の画像ブロックであるCTUから開始して、画像ブロックはさらに、より小さい正方形のコーディング単位(CU)へと分割されてもよい。CTUがCUに再帰的に分割された後に、各CUは、予測単位(PU)および変換単位(TU)へとさらに分割される。
HEVCでは、PUへのCUのパーティションは、いくつかの事前に定義された候補から選択される。CUのサイズが2N×2Nであると仮定すると、イントラCUに対して、CUのサイズが8×8である場合、CUを1つの2N×2NのPUまたは4つのN×NのPUにパーティショニングすることができ、CUサイズが8×8より大きい場合、PUは常にCUのサイズ、すなわち2N×2Nに等しい。インターCUに対して、予測サイズは、2N×2N、N×2N、2N×N、または2N×nU、2N×nD、nL×2N、およびnR×2Nを含む、非対称動きパーティション(AMP)であってもよい。HEVCに従った64×64ブロックのための非対称動きパーティションの例が図10に示される。
図11は、HEVCに従った残差4分木に基づく例示的な変換方式を示す概念図である。TUへのCUのパーティションは、4分木の手法に基づいて再帰的に行われる。したがって、各CUの残差信号は、ツリー構造、すなわち残差4分木(RQT)によってコーディングされる。RQTは、4×4から32×32ルーマサンプルまでのTUサイズを許容する。図11は、CUが、文字aからjによりラベリングされた10個のTUと、対応するブロックパーティションとを含む例を示す。RQTの各ノードは実際には変換単位(TU)である。
個々のTUは、深度優先のツリー横断順序で処理され、この深度優先のツリー横断順序は、図ではアルファベットの順序として示され、これは深度優先の横断を用いる再帰的なZスキャンに従う。4分木手法は、残差信号の変化する空間周波数特性に対する変換の適応を可能にする。通常、より大きい空間をサポートするより大きい変換ブロックサイズは、より良い周波数分解能を提供する。しかしながら、より小さい空間をサポートするより小さい変換ブロックサイズは、より良い空間分解能を提供する。この2つ、すなわち空間分解能と周波数分解能との間のトレードオフは、たとえばレート歪み最適化技法に基づいて、エンコーダのモード判断によって選ばれる。エンコーダは、レート歪み最適化技法を実行して、コーディングモード(たとえば、特定のRQT分割構造)ごとにコーディングビットと再構築歪みとの加重和、すなわちレート歪みコストを計算し、最小のレート歪みコストを有するコーディングモードを最良のモードとして選択する。
インターコーディングされたCUに対して、変換ブロックが予測ブロックまたは動きブロックの境界にまたがるとき、高周波の係数が生成され、これはコーディング性能に負の影響を与えることがある。非対称動きパーティション(AMP)の場合、この問題はより深刻であることがあり、それは、第1のレベルおよび第2のレベルの変換ブロックが対応する動きブロックの境界にまたがるからである。しかしながら、インターコーディングされたCUに対して、対応するPUより大きい変換単位、たとえば2N×2Nの変換単位がそれでも有用であることがあり、このことは、コーディング単位の内部の残差が小さいときに2N×2Nの変換がより良好な結果を得ることができるという理由に基づき、2N×2NのTUを使用することもシグナリングビットを節約することができ、これはコーディング効率を改善することの助けになることがある。
HEVCでは、イントラコーディングされたCUに対して、TUは予測境界、すなわちPU境界にまたがることができない。しかしながら、インターコーディングされたCUに対して、TUはCUサイズと同じ大きさであることがあり、これは、変換が予測境界にまたがって実行されてもよいことを意味する。
HEVCでは、QP値はCUレベルで変更されることが許容される。量子化グループは、単一の基本QP値が領域内のすべてのCUに対するQP値の差分をコーディングするために使用されるような領域として定義される。しかしながら、同様の概念は既存のマルチタイプツリー構造において定義するのは難しいことがあり、それは、リーフノードの論理グループが非常に多様な形状であってもよいので、QPデルタのコーディングのために良い共通の予測子を見つけるのが困難であってもよいからである。
たとえば、長方形を使用してパーティショニングされてもよいオブジェクト境界において、より低いQP値を前景のパーティションのために使用することができ、より高いQP値が背景のパーティションのために必要とされることがある。符号化されたビデオの知覚的品質をさらに改善するために、異なるパーティションに対して異なるQP値を使用するのが望ましい。
図12は、マルチタイプツリーの第1のレベル150およびマルチタイプツリーの第2のレベル160'の例を示す概念図である。第1のレベル150は領域ツリーとも呼ばれることがあり、第2のレベル160'は予測ツリーと呼ばれることがある。第2のレベル160'は、第1のレベル150のブロック160に対応する。具体的には、第1のレベル150は4分木でパーティショニングされ、第2のレベル160'はより小さいブロックへと2分木および中央−側部3分木でさらに分割される領域ツリーに対応する。この例では、CTBは4つの4分木のリーフ152、154、156、および158へとパーティショニングされ、これらのうちの2番目(ブロック154)が4つのさらなる4分木のリーフ160、162、164、および166へとパーティショニングされ、(全体で7つの領域ツリーリーフノードを有する)第1のレベル150をもたらす。図12の例では、ブロック160は、領域ツリーリーフノードを表し、中央−側部3分木の第1のセット172、174、176へとパーティショニングされ、それらのうちの右側のもの(176)も中央−側部3分木178、184、186へとパーティショニングされ、それらのうちの最初のもの(ブロック178)が2分木を使用して(すなわち、ブロック180、182に対応する2分木リーフへと)パーティショニングされる。したがって、第2のレベル160'は全体で6つのリーフノードを含む。これらの6つのリーフノードは、本開示の技法によれば、コーディング単位(CU)に対応してもよい。CUの各々(たとえば、ブロック172、174、180、182、184、および186の各々)のためのビデオデータ(たとえば、予測データおよび変換データ)をビデオエンコーダ20は符号化することができ、ビデオデコーダ30は復号することができる。
一例では、ビデオエンコーダ20およびビデオデコーダ30は、領域ツリーを有するマルチタイプツリーを使用してCTBをパーティショニングするように構成されることがあり、その領域ツリーのリーフノードは2分木および/または中央−側部3分木を使用してパーティショニングされる。図12は、4分木ベースの領域ツリーが左側にあり(第1のレベル150をもたらす)、2分木/3分木ベースの予測ツリーが右側にある(第2のレベル160'をもたらす)、例を示す。長い破線は、水平の中央−側部3分木による、第2のレベル160'の領域ツリーリーフの第1の深度の分割を示し、短い破線は、垂直の中央−側部3分木による第2の深度の分割を表し、点破線は水平の2分木による第3の深度の分割のためのものである。
一例では、ビデオエンコーダ20およびビデオデコーダ30は、OBMCが領域ツリーリーフのレベルにあるかどうかをシグナリング/決定してもよい。図12の例では、第2のレベル160'は領域ツリーリーフを表し、第2のレベル160'の内側ブロック172、174、176、178、180、182、184、および186は予測ツリーによるパーティションを示す。内側の線は、予測ツリーリーフのCU、すなわち、ブロック172、174、180、182、184、および186の境界を表す。OBMCがこの領域ツリーリーフ(すなわち、第2のレベル160')に対して有効であるとき、内側の線(すなわち、長い破線、短い破線、および点破線)はHEVCのPU境界と同じものと見なすことができるので、PU境界のOBMCは、ブロック172、174、180、182、184、および186の間の境界の両辺に適用されてもよい。この場合、OBMCは、領域ツリーリーフ全体を符号化/復号した後の、追加の改良またはフィルタリングと見なされてもよい。
一例では、ビデオエンコーダ20およびビデオデコーダ30は、そのレベルまたは領域ツリーリーフレベルにおいて重複変換を適用してもよい。図12の第2のレベル160'に示されるように、領域ツリーリーフはいくつかのCU(すなわち、ブロック172、174、180、182、184、および186)を含む。ビデオエンコーダ20またはビデオデコーダ30は、領域ツリーリーフのための重複変換を可能にし、ビデオエンコーダ20および/またはビデオデコーダ30は、領域ツリーリーフと同じサイズの大きい変換を第2のレベル160'(すなわち、領域ツリーリーフ全体)に適用してもよい。ビデオエンコーダ20またはビデオデコーダ30は、変換ツリーを領域ツリーリーフに適用してもよい。
一例では、ビデオエンコーダ20および/またはビデオデコーダ30は領域ツリーリーフのレベルでスキップ/マージモードを適用してもよい。そのようなスーパースキップ/マージモードが有効であるとき、ビデオエンコーダ20またはビデオデコーダ30は、スキップ/マージモードを使用して、図12の第2のレベル160'に示されるブロック172、174、180、182、184、および186などの領域ツリーリーフ内でCUのすべてをコーディング(すなわち、符号化または復号)するので、各CU(すなわち、ブロック172、174、180、182、184、および186の各々)に対して独立に、ビデオエンコーダ20はスキップ/マージフラグを符号化せず、ビデオデコーダ30はそれを復号しない。
一例では、ビデオエンコーダ20およびビデオデコーダ30は、領域ツリーリーフのレベルで基本QPを適用してもよい。QPデルタコーディングが有効であるとき、ビデオエンコーダ20およびビデオデコーダ30は、領域ツリーリーフ(すなわち、ブロック172、174、180、182、184、および186の各々)の中のすべてのCU/ブロックに対するデルタQP値をコーディングするために、同じ基本QPを使用してもよい。
図13は、本開示の技法による、コーディングツリーブロックを符号化するための例示的な方法を示すフローチャートである。例および説明を目的に、図13の方法は、ビデオエンコーダ20に関して説明される。しかしながら、他の例では、他のユニットが、図13の技法を実行するように構成されてもよい。
この例では、最初に、モード選択ユニット40が、コーディングツリーブロック(CTB)の領域ツリーレベルでブロックのサイズを決定する(200)。たとえば、モード選択ユニット40は、様々な異なる符号化パスを実行し、レート歪み分析に基づいて領域ツリーレベルでブロックのサイズを決定してもよい。モード選択ユニット40は次いで、領域ツリーノードに対応するブロックがどのようにパーティショニングされるかを示す分割フラグなどの領域ツリーシンタックス要素を符号化のためにエントロピー符号化ユニット56に送信してもよい(202)。分割フラグはさらに、領域ツリーの枝が、予測ツリーのルートノードとして活動する領域ツリーリーフノードで終端するときを示してもよい。本開示の技法によれば、領域ツリーの各非リーフノードは、4つ、5つ、6つなどの子ノードなどの少なくとも4つの子ノードである、ある数の子ノードへと分割される。
加えて、モード選択ユニット40は、CTBのために様々なコーディングツールを有効にするかどうかを判定し、シンタックス要素を符号化のためのエントロピー符号化ユニット56に送信することができ、ここでシンタックス要素は有効にされたコーディングツールを表す。これらのシンタックス要素は、領域ツリーリーフノードなどの領域ツリーレベル情報に含まれてもよい。シンタックス要素は、たとえば、上で論じられたような重複ブロック動き補償(OBMC)、重複変換、スーパースキップモード、スーパーマージモード、スーパーイントラ予測モード、スーパーインター予測モード、および/またはスーパーフレームレートアップコンバージョン(FRUC)モードを含んでもよい。いくつかの例では、モード選択ユニット40は、領域ツリーリーフノードに含まれるCUの数が閾値より大きいとき、スーパーモード(スーパースキップモード、スーパーマージモード、スーパーイントラ予測モード、スーパーインター予測モード、および/またはスーパーFRUCモード)を有効にする。閾値は事前に定義されることがあり、またはエントロピー符号化ユニット56は、たとえばSPS、PPS、スライスヘッダなどにおいて、閾値を定義するシンタックス要素を符号化してもよい。
モード選択ユニット40は次いで、領域ツリーリーフノードの各々に対して予測ツリーレベルでブロックのサイズを決定してもよい(204)。やはり、領域ツリーリーフノードの各々は、それぞれの予測ツリーのルートノードとしても活動してもよい。領域ツリーのすべての枝が必ずしも同じサイズではないので、CTBの予測ツリーは様々な領域ツリーの深度で開始してもよいことを理解されたい。モード選択ユニット40は、再び様々な符号化パスを試験し、レート歪み分析を使用して予測ツリーレベルに対応するブロックのサイズを決定してもよい(すなわち、最良の試験されたレート歪み特性を生み出すブロックサイズを選択することによって)。モード選択ユニット40は次いで、予測ツリーのための分割フラグなどのシンタックス要素をエントロピー符号化のためにエントロピー符号化ユニット56に提供してもよい(206)。本開示の技法によれば、予測ツリーの各非リーフノードは、2つ、3つ、4つなどの子ノードなどの少なくとも2つの子ノードである、ある数の子ノードへと分割されてもよい。その上、いくつかの例では、ビデオエンコーダ20は、中央−側部3分木パーティションを使用して、2つの子予測ツリーノードまたは3つの子予測ツリーノードのいずれかへと予測ツリーノードを分割してもよい。
いくつかの例では、ビデオエンコーダ20は、領域ツリーレベルと予測ツリーレベルのいずれかまたは両方で、いくつかのシンタックス要素を符号化してもよい。たとえば、ビデオエンコーダ20は、領域ツリーレベルと予測ツリーレベルのいずれかまたは両方で、サンプル適応オフセット(SAO)および/または適応ループフィルタ(ALF)パラメータなどのフィルタリングツールパラメータを符号化してもよい。さらに、ビデオエンコーダ20は、必ずしもリーフノードだけではなく、領域ツリーおよび/または予測ツリーの任意のノードにおいて、これらのシンタックス要素を符号化してもよい。
本開示の技法によれば、予測ツリーリーフノードは、予測データおよび変換データを有するコーディング単位(CU)に対応する。したがって、予測ツリーノードを予測ツリーリーフノードへとパーティショニングした後で、ビデオエンコーダ20は、CUの各々(すなわち、予測ツリーリーフノード)のための予測データおよび変換データを符号化してもよい。具体的には、モード選択ユニット40は、イントラ予測モード、インター予測モード、またはスキップモードを使用してCUを予測するかどうかを判定し(208)、次いで、予測情報(たとえば、イントラモード、マージモードまたはAMVPモード情報などの動き情報、など)をエントロピー符号化するためにシンタックス情報をエントロピー符号化ユニット56に送信してもよい(210)。
モード選択ユニット40はまた、対応するCUの残差ブロックを計算する加算器50に、CUの予測されたブロックを提供する。このようにして、ビデオエンコーダ20は、対応するCUの残差情報を決定する(212)。変換処理ユニット52は、変換を残差ブロックに適用して残差データを変換し(214)、次いで、量子化ユニット54は、変換された残差情報(すなわち、変換係数)を量子化して(216)、量子化された変換係数(量子化された変換情報と呼ばれる)を生成する。エントロピー符号化ユニット56は次いで、量子化された変換情報をエントロピー符号化する(218)。エントロピー符号化ユニット56はさらに、量子化パラメータ(QP)情報などの他のシンタックス要素をエントロピー符号化してもよい。本開示の技法によれば、いくつかの例では、CTBのCUの各々の各QPは、CTB全体の基本QPから予測されてもよい。
このようにして、図13の方法は、ビデオデータを符号化する方法の例を表し、本方法は、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルにある領域ツリーノードがどのように子領域ツリーノードへと分割されるべきかを決定するステップであって、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4である、ステップと、領域ツリーが領域ツリーノードへとどのように分割されるかを少なくとも表す領域ツリーレベルの1つまたは複数のシンタックス要素を符号化するステップと、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーの領域ツリーリーフノードの各々のための予測ツリーレベルにある予測ツリーノードがどのように子予測ツリーノードへと分割されるようにパーティショニングされるかを決定するステップであって、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が少なくとも2つの予測ツリー子ノードを有し、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義する、ステップと、予測ツリーが予測ツリーノードへとどのように分割されるかを少なくとも表す予測ツリーレベルの1つまたは複数のシンタックス要素を符号化するステップと、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを符号化するステップとを含む。
図14は、本開示の技法による、コーディングツリーブロックを復号するための例示的な方法を示すフローチャートである。例および説明として、図14の方法は、ビデオデコーダ30に関して説明される。しかしながら、他の例では、他のユニットが、図14の技法を実行するように構成されてもよい。
この例では、最初に、エントロピー復号ユニット70は、コーディングツリーブロック(CTB)のための領域ツリーレベルのシンタックス要素をエントロピー復号する(220)。ビデオデコーダ30は次いで、領域ツリーレベルのシンタックス要素から領域ツリーレベルのブロックのサイズを決定してもよい(222)。たとえば、シンタックス要素は、領域ツリーノードに対応するブロックがどのようにパーティショニングされるかを示す分割フラグを含んでもよい。分割フラグはさらに、領域ツリーの枝が、予測ツリーのルートノードとして活動する領域ツリーリーフノードで終端するときを示してもよい。本開示の技法によれば、領域ツリーの各非リーフノードは、4つ、5つ、6つなどの子ノードなどの少なくとも4つの子ノードである、ある数の子ノードへと分割される。
加えて、エントロピー復号ユニット70は、CTBのための様々なコーディングツールが有効であるかどうかを表すシンタックス要素を復号してもよい。これらのシンタックス要素は、領域ツリーレベル情報に含まれてもよい。シンタックス要素は、たとえば、上で論じられたような重複ブロック動き補償(OBMC)、重複変換、スーパースキップモード、スーパーマージモード、スーパーイントラ予測モード、スーパーインター予測モード、および/またはスーパーフレームレートアップコンバージョン(FRUC)モードを表してもよい。いくつかの例では、ビデオデコーダ30は、領域ツリーリーフノードに含まれるCUの数が閾値より大きいときにのみ、スーパーモード(スーパースキップモード、スーパーマージモード、スーパーイントラ予測モード、スーパーインター予測モード、および/またはスーパーFRUCモード)を有効にしてもよい。閾値は事前に定義されることがあり、またはエントロピー復号ユニット70は、たとえばSPS、PPS、スライスヘッダなどにおいて、閾値を定義するシンタックス要素を復号してもよい。
エントロピー復号ユニット70は次いで、領域ツリーリーフノードに対応する予測ツリーのための予測ツリーシンタックス要素を復号してもよい(224)。ビデオデコーダ30は次いで、予測ツリーレベルのシンタックス要素に基づいて、領域ツリーリーフノードの各々に対して予測ツリーレベルのブロックのサイズを決定してもよい(226)。やはり、領域ツリーリーフノードの各々は、それぞれの予測ツリーのルートノードとしても活動してもよい。たとえば、シンタックス要素は、予測ツリーのための分割フラグを含んでもよい。本開示の技法によれば、予測ツリーの各非リーフノードは、2つ、3つ、4つなどの子ノードなどの少なくとも2つの子ノードである、ある数の子ノードへと分割されてもよい。その上、いくつかの例では、ビデオデコーダ30は、予測ツリーノードにおいてシグナリングされるシンタックス要素に基づいて、中央−側部3分木パーティションを使用して、2つの子予測ツリーノードまたは3つの子予測ツリーノードのいずれかへと予測ツリーノードを分割してもよい。
いくつかの例では、ビデオデコーダ30は、領域ツリーレベルと予測ツリーレベルのいずれかまたは両方で、いくつかのシンタックス要素を復号してもよい。たとえば、ビデオデコーダ30は、領域ツリーレベルと予測ツリーレベルのいずれかまたは両方で、サンプル適応オフセット(SAO)および/または適応ループフィルタ(ALF)パラメータなどのフィルタリングツールパラメータを復号してもよい。さらに、ビデオデコーダ30は、必ずしもリーフノードだけではなく、領域ツリーおよび/または予測ツリーの任意のノードにおいて、これらのシンタックス要素を復号してもよい。
本開示の技法によれば、予測ツリーのリーフノードは、予測データおよび変換データを有するコーディング単位(CU)に対応する。したがって、予測ツリーノードを予測ツリーリーフノードへとパーティショニングした後で、ビデオデコーダ30は、CUの各々(すなわち、予測ツリーリーフノード)のための予測データおよび変換データを復号してもよい。具体的には、エントロピー復号ユニット70は、イントラ予測モードを使用してCUを予測するか、インター予測モードを使用してCUを予測するか、またはスキップモードを使用してCUを予測するかを示すシンタックス情報などの予測情報を表すシンタックス情報を復号してもよい(228)。ビデオデコーダ30は次いで、各CU(230)の予測モード、たとえば、各CUがイントラモードを使用して予測されるか、インターモードを使用して予測されるか(ならびにマージモードまたはAMVPモード情報などのモード情報)などを決定してもよい。動き補償ユニット72またはイントラ予測ユニット74は、CUの各々のための予測されたブロックを形成するために予測情報を使用する。
エントロピー復号ユニット70はまた、量子化された変換情報をエントロピー復号する(232)。逆量子化ユニット76は、量子化された変換情報を逆量子して(234)、変換係数(変換情報とも呼ばれる)を再生する。逆変換ユニット78は、変換情報を逆変換して(236)、CUの残差ブロックを再生する(238)。加算器80は、それぞれのCUの各々のための残差ブロックおよび予測されたブロックを組み合わせて(240)CUを再生し、参照として後で使用し、復号されたビデオデータとして出力するために、CUを参照ピクチャメモリ82に記憶する。
このようにして、図14の方法は、ビデオデータを復号する方法の例を表し、本方法は、ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、領域ツリーが0個以上の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、領域ツリー非リーフノードの各々が第1の数の子領域ツリーノードを有し、第1の数が少なくとも4である、ステップと、領域ツリーレベルのシンタックス要素を使用して、領域ツリーノードが子領域ツリーノードへとどのように分割されるかを決定するステップと、CTBのためのツリーデータ構造の1つまたは複数の予測ツリーの領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、予測ツリーが各々、0個以上の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードを有し、予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、第2の数が少なくとも2であり、予測リーフノードの各々がそれぞれのコーディング単位(CU)を定義する、ステップと、予測ツリーレベルのシンタックス要素を使用して、予測ツリーノードが子予測ツリーノードへとどのように分割されるかを決定するステップと、領域ツリーレベルのシンタックス要素および予測ツリーレベルのシンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、CUの各々に対するビデオデータを復号するステップとを含む。
例によっては、本明細書において説明された技法のうちのいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行されてよく、追加され、統合され、または完全に除外されてよい(たとえば、説明されたすべての行為またはイベントが技法の実践にとって必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて並行して実行されてよい。
1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せとして実装されてもよい。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信されることがあり、かつハードウェアに基づく処理ユニットによって実行されることがある。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、またはたとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含んでもよい。このようにして、コンピュータ可読媒体は一般に、(1)非一時的である有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応してもよい。データ記憶媒体は、本開示において説明される技法の実施のための命令、コードおよび/もしくはデータ構造を取り出すために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされてもよい任意の利用可能な媒体であってもよい。コンピュータプログラム製品はコンピュータ可読媒体を含んでもよい。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされてもよい任意の他の媒体を含んでもよい。また、いかなる接続も厳密にはコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書では、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-rayディスク(登録商標)(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるものとする。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の等価の集積論理回路もしくはディスクリート論理回路などの1つまたは複数のプロセッサによって実行されてもよい。したがって、本明細書において使用される「プロセッサ」という用語は、前述の構造、または本明細書において説明された技法の実施に適した任意の他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書において説明される機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/もしくはソフトウェアモジュール内で与えられることがあり、または複合コーデックに組み込まれることがある。また、技法は、1つまたは複数の回路または論理要素において完全に実施されてもよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またICのセット(たとえば、チップセット)を含む、様々なデバイスまたは装置において実装されてもよい。本開示では、開示される技法を実行するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが説明されているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて結合されることがあり、または適切なソフトウェアおよび/もしくはファームウェアとともに、上で説明されたような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されることがある。
様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
10 ビデオ符号化および復号システム
12 ソースデバイス
14 デスティネーションデバイス
16 コンピュータ可読媒体
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
32 表示デバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 パーティションユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピー符号化ユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 参照ピクチャメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 参照ピクチャメモリ
100 コーディングツリーブロック(CTB)
102 CT
120 4分木2分木(QTBT)構造
122 CTB
130 ブロック
132 ブロック
134 ブロック
136 ブロック
138 ブロック
150 第１のレベル
152 ブロック
154 ブロック
156 ブロック
158 ブロック
160 ブロック
160' 第２のレベル
162 ブロック
164 ブロック
166 ブロック
172 ブロック
174 ブロック
176 ブロック
178 ブロック
180 ブロック
182 ブロック
184 ブロック
186 ブロック

Claims (16)

  1. ビデオデータを復号する方法であって、
    ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、前記領域ツリーが１つまたは複数の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、前記領域ツリー非リーフノードの各々が4つの子領域ツリーノードを有する、ステップと、
    前記領域ツリーレベルの前記シンタックス要素を使用して、前記領域ツリーノードが前記子領域ツリーノードへとどのように分割されるかを決定するステップと、
    前記CTBのための前記ツリーデータ構造の1つまたは複数の予測ツリーの前記領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号するステップであって、前記予測ツリーが各々、前記領域ツリーリーフノードの1つまたは複数に対応するルートノードと、１つまたは複数の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードとを有し、前記予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、前記第2の数が2または3であり、前記予測ツリーリーフノードの各々がそれぞれのコーディング単位(CU)を定義する、ステップと、
    前記予測ツリーレベルの前記シンタックス要素を使用して、前記予測ツリーノードが前記子予測ツリーノードへとどのように分割されるかを決定するステップと、
    前記領域ツリーレベルの前記シンタックス要素および前記予測ツリーレベルの前記シンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、前記CUの各々に対するビデオデータを復号するステップであって、前記予測データが、前記CUの対応する1つについての予測ブロックを形成するための予測モードを示し、前記変換データが、前記CUの前記対応する1つについての変換された残差データを表す残差変換係数を含む、ステップと、
    前記領域ツリーレベルで前記シンタックス要素を復号するステップが、前記領域ツリーレベルで1つまたは複数の有効なコーディングツールを表す1つまたは複数のシンタックス要素を復号するステップを備え、
    前記方法が、前記CUの各々のための前記ビデオデータを復号する前に、分割情報を示すシンタックス要素を使用して前記領域ツリーリーフノードに含まれるCUの数を決定するステップと、
    前記CUの数が閾値より大きいとき、前記領域ツリーリーフノードに含まれるCUの全てに適用される予測モードであるスーパーモードを有効にするステップと、をさらに備える
    方法。
  2. 前記領域ツリーレベルで前記シンタックス要素を復号するステップおよび前記予測ツリーレベルで前記シンタックス要素を復号するステップが、前記領域ツリーレベルまたは前記予測ツリーレベルのうちの少なくとも1つのための1つまたは複数のさらなる分割のないツリータイプを復号するステップを備え、前記さらなる分割のないツリータイプは、さらなる分割が許可されないことを意味する、請求項1に記載の方法。
  3. 前記領域ツリーレベルに対する最大の領域ツリー深度を表すデータを復号するステップをさらに備える、請求項1に記載の方法。
  4. 前記予測ツリーレベルに対する最大の予測ツリー深度を表すデータを復号するステップをさらに備え、
    前記最大の領域ツリー深度と前記最大の予測ツリー深度の合計が最大の合計深度値より小さい、
    請求項3に記載の方法。
  5. 前記最大の領域ツリー深度を表す前記データを復号するステップが、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数から前記最大の領域ツリー深度を表す前記データを復号するステップを備える、請求項3に記載の方法。
  6. 前記領域ツリーレベルに対する最大の領域ツリー深度と前記予測ツリーレベルに対する最大の予測ツリー深度との両方を一緒に表す1つのシンタックス要素を復号するステップをさらに備え、
    前記最大の領域ツリー深度と前記最大の予測ツリー深度とを一緒に表す前記1つのシンタックス要素を復号するステップが、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、またはスライスヘッダのうちの1つまたは複数から前記1つのシンタックス要素を復号するステップを備える、
    請求項1に記載の方法。
  7. 前記領域ツリーノードのうちの少なくとも1つまたは前記予測ツリーノードのうちの少なくとも1つを備える少なくとも1つのノードが分割されることを前記ノードのための分割されたデータを復号することなく推測するステップをさらに備え、
    推測するステップが、前記少なくとも1つのノードが、ピクチャ境界、スライス境界、またはタイル境界のうちの少なくとも1つにまたがる、前記ノードに対応するブロックに基づいて分割されることを推測するステップを備える、
    請求項1に記載の方法。
  8. 前記CUの各々の前記ビデオデータが、スキップフラグ、マージインデックス、前記CUがインターモードもしくはイントラモードを使用して予測されるか表すシンタックス要素、イントラモード予測情報、動き情報、変換情報、残差情報、または量子化情報のうちの1つまたは複数を備える、請求項1に記載の方法。
  9. 前記方法が、前記CUの境界が前記領域ツリーの前記領域ツリーリーフノードのうちの1つによって示されるような共通の領域内にあるとき、前記CUの前記境界にまたがって前記コーディングツールを適用するステップをさらに備える、
    請求項1に記載の方法。
  10. 前記有効なコーディングツールのうちの1つまたは複数を表す前記シンタックス要素を復号するステップが、重複ブロック動き補償(OBMC)が前記領域ツリーリーフノードのうちの前記1つに対応する前記ビデオデータのブロックに対して有効であるかどうかを表す、前記領域ツリーリーフノードの各々の中のOBMCモード情報を復号するステップを備えるか、
    前記有効なコーディングツールの1つまたは複数を表す前記シンタックス要素を復号するステップが、重複変換が前記領域ツリーリーフノードのうちの前記1つに対応する前記ビデオデータのブロックに対して有効であるかどうかを表す、前記領域ツリーリーフノードの各々の中の重複変換情報を復号するステップを備え、重複変換が、前記領域ツリーリーフノードのうちの前記1つに対応する領域の2つの予測ブロックの間の境界と変換ブロックが重複することが許可されるコーディングツールを備えるか、または
    前記有効なコーディングツールのうちの1つまたは複数を表す前記シンタックス要素を復号するステップが、前記領域ツリーリーフノードに対応する領域内の前記CUのすべてが、スキップモード、マージモード、イントラモード、インターモード、またはフレームレートアップコンバージョン(FRUC)モードを使用してコーディングされるかを示す、前記領域ツリーリーフノードのうちの1つまたは複数の中のデータを復号するステップを備え、前記領域のうちの1つの中の前記CUのすべてが共通のモードを使用してコーディングされるとき、CU別のモード情報を復号しない、
    請求項9に記載の方法。
  11. 前記領域ツリーレベルで前記シンタックス要素を復号するステップが、サンプル適応オフセット(SAO)パラメータまたは適応ループフィルタ(ALF)パラメータのうちの少なくとも1つを復号するステップを備えるか、または、
    前記方法が、前記領域ツリーレベルまたは前記予測ツリーレベルのうちの少なくとも1つにおいて前記第2の数が3であり、1つまたは複数の中央−側部3分木シンタックス要素を復号するステップをさらに備えるか、または
    前記方法が、前記CUの各々のためのそれぞれの量子化パラメータ(QP)を計算するステッ
    プをさらに備え、前記QPを計算するステップは、前記領域ツリーリーフノードの各々の基本QPを決定するステップと、前記CUの前記対応する領域ツリーリーフノードの前記基本QPに基づいて前記それぞれのQPを計算するステップとを備える
    請求項1に記載の方法。
  12. 前記ビデオデータを復号する前に前記ビデオデータを符号化するステップをさらに備える、請求項1に記載の方法。
  13. ビデオデータを復号するためのデバイスであって、
    ビデオデータを記憶するように構成されるメモリと、
    回路で実装されるプロセッサであって、前記回路が、
    ビデオデータのコーディングツリーブロック(CTB)のためのツリーデータ構造の領域ツリーの領域ツリーレベルで1つまたは複数のシンタックス要素を復号することであって、前記領域ツリーが1つまたは複数の領域ツリー非リーフノードおよび1つまたは複数の領域ツリーリーフノードを含む1つまたは複数の領域ツリーノードを有し、前記領域ツリー非リーフノードの各々が4つの子領域ツリーノードを有する、復号することと、
    前記領域ツリーレベルの前記シンタックス要素を使用して、前記領域ツリーノードが前記子領域ツリーノードへとどのように分割されるかを決定することと、
    前記CTBのための前記ツリーデータ構造の1つまたは複数の予測ツリーの前記領域ツリーリーフノードの各々のために予測ツリーレベルで1つまたは複数のシンタックス要素を復号することであって、前記予測ツリーが各々、前記領域ツリーリーフノードの1つまたは複数に対応するルートノードと、1つまたは複数の予測ツリー非リーフノードおよび1つまたは複数の予測ツリーリーフノードを含む1つまたは複数の予測ツリーノードとを有し、前記予測ツリー非リーフノードの各々が第2の数の子予測ツリーノードを有し、前記第2の数が2または3であり、前記予測ツリーリーフノードの各々がそれぞれのコーディング単位(CU)を定義する、復号することと、
    前記予測ツリーレベルの前記シンタックス要素を使用して、前記予測ツリーノードが前記子予測ツリーノードへとどのように分割されるかを決定することと、
    前記領域ツリーレベルの前記シンタックス要素および前記予測ツリーレベルの前記シンタックス要素に少なくとも部分的に基づいて、予測データおよび変換データを含む、前記CUの各々に対するビデオデータを復号することと、を行うように構成され、
    前記予測データが、前記CUの対応する1つについての予測ブロックを形成するための予測モードを示し、前記変換データが、前記CUの前記対応する1つについての変換された残差データを表す残差変換係数を含み、
    前記領域ツリーレベルで前記シンタックス要素を復号することが、前記領域ツリーレベルで1つまたは複数の有効なコーディングツールを表す1つまたは複数のシンタックス要素を復号することを含み、
    前記回路が、前記CUの各々のための前記ビデオデータを復号する前に、分割情報を示すシンタックス要素を使用して前記領域ツリーリーフノードに含まれるCUの数を決定することと、
    前記CUの数が閾値より大きいとき、前記領域ツリーリーフノードに含まれるCUの全てに適用される予測モードであるスーパーモードを有効にすることと、
    をさらに行うように構成される、プロセッサと
    を備える、デバイス。
  14. 前記復号されたビデオデータを表示するように構成されるディスプレイ、または
    前記ビデオデータをキャプチャするように構成されるカメラのうちの少なくとも1つをさらに備える、請求項１３に記載のデバイス。
  15. 前記デバイスが、カメラ、コンピュータ、モバイルデバイス、ブロードキャストレシーバデバイス、またはセットトップボックスのうちの1つまたは複数を備える、請求項１３に記載のデバイス。
  16. プロセッサに、請求項１〜１２のいずれか一項に記載の方法を実施させる命令を記憶した、非一時的コンピュータ可読記憶媒体。
JP2018549271A 2016-03-21 2017-03-21 ２レベルのマルチタイプツリーフレームワークを使用したビデオデータのデコーディング Active JP6908618B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201662311248P 2016-03-21 2016-03-21
US62/311,248 2016-03-21
US201662401016P 2016-09-28 2016-09-28
US62/401,016 2016-09-28
US15/463,398 2017-03-20
US15/463,398 US11223852B2 (en) 2016-03-21 2017-03-20 Coding video data using a two-level multi-type-tree framework
PCT/US2017/023351 WO2017165375A1 (en) 2016-03-21 2017-03-21 Decoding video data using a two-level multi-type-tree framework

Publications (3)

Publication Number Publication Date
JP2019512963A JP2019512963A (ja) 2019-05-16
JP2019512963A5 JP2019512963A5 (ja) 2020-04-16
JP6908618B2 true JP6908618B2 (ja) 2021-07-28

Family

ID=59847996

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018549271A Active JP6908618B2 (ja) 2016-03-21 2017-03-21 ２レベルのマルチタイプツリーフレームワークを使用したビデオデータのデコーディング

Country Status (20)

Country Link
US (1) US11223852B2 (ja)
EP (1) EP3434018B1 (ja)
JP (1) JP6908618B2 (ja)
KR (1) KR102465214B1 (ja)
CN (1) CN108781293B9 (ja)
AU (1) AU2017238068B2 (ja)
BR (1) BR112018068927A2 (ja)
CA (1) CA3014785A1 (ja)
CL (1) CL2018002664A1 (ja)
CO (1) CO2018009880A2 (ja)
ES (1) ES2901503T3 (ja)
HK (1) HK1256749A1 (ja)
HU (1) HUE057252T2 (ja)
MX (1) MX2018011376A (ja)
NZ (1) NZ745288A (ja)
PH (1) PH12018501701A1 (ja)
RU (1) RU2746935C2 (ja)
SA (1) SA518392315B1 (ja)
SG (1) SG11201806737RA (ja)
WO (1) WO2017165375A1 (ja)

Families Citing this family (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3046321B1 (fr) * 2015-12-29 2018-01-26 B<>Com Procede de codage d'une image numerique, procede de decodage, dispositifs, terminal d'utilisateur et programmes d'ordinateurs associes
US10212444B2 (en) 2016-01-15 2019-02-19 Qualcomm Incorporated Multi-type-tree framework for video coding
US10567808B2 (en) * 2016-05-25 2020-02-18 Arris Enterprises Llc Binary ternary quad tree partitioning for JVET
US10880548B2 (en) * 2016-06-01 2020-12-29 Samsung Electronics Co., Ltd. Methods and apparatuses for encoding and decoding video according to coding order
US20190327476A1 (en) * 2016-06-24 2019-10-24 Industry Academy Cooperation Foundation Of Sejong University Video signal processing method and device
US10609423B2 (en) 2016-09-07 2020-03-31 Qualcomm Incorporated Tree-type coding for video coding
KR20230010060A (ko) 2016-10-04 2023-01-17 주식회사 비원영상기술연구소 영상 데이터 부호화/복호화 방법 및 장치
US20190238888A1 (en) * 2017-07-17 2019-08-01 Ki Baek Kim Image data encoding/decoding method and apparatus
EP4432670A2 (en) 2016-10-04 2024-09-18 B1 Institute of Image Technology, Inc. Image data encoding/decoding method and apparatus
US12035049B2 (en) 2016-10-06 2024-07-09 B1 Institute Of Image Technology, Inc. Image data encoding/decoding method and apparatus
WO2018092868A1 (ja) * 2016-11-21 2018-05-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 符号化装置、復号装置、符号化方法及び復号方法
CN116320415A (zh) 2016-11-21 2023-06-23 松下电器（美国）知识产权公司 图像编码装置及方法、图像解码装置及方法
KR20180110047A (ko) * 2016-12-26 2018-10-08 닛본 덴끼 가부시끼가이샤 영상 인코딩 방법, 영상 디코딩 방법, 영상 인코딩 장치, 영상 디코딩 장치, 및 프로그램
US10542293B2 (en) * 2016-12-26 2020-01-21 Nec Corporation Video encoding method, video decoding method, video encoding device, video decoding device, and program
US10848788B2 (en) 2017-01-06 2020-11-24 Qualcomm Incorporated Multi-type-tree framework for video coding
US10542280B2 (en) 2017-01-09 2020-01-21 QUALCOMM Incorpated Encoding optimization with illumination compensation and integer motion vector restriction
WO2019010267A1 (en) * 2017-07-05 2019-01-10 Arris Enterprises Llc POST-FILTERING FOR WEIGHTED ANGULAR PREDICTION
WO2019045391A1 (ko) * 2017-08-29 2019-03-07 주식회사 케이티 비디오 신호 처리 방법 및 장치
EP3598750A4 (en) 2017-09-28 2020-06-10 LG Electronics Inc. -1- IMAGE DECODING METHOD AND DEVICE IN ACCORDANCE WITH A BLOCK SPLIT STRUCTURE IN AN IMAGE CODING SYSTEM
CA3078240A1 (en) * 2017-10-02 2019-04-11 Arris Enterprises Llc System and method for reducing blocking artifacts and providing improved coding efficiency
WO2019093523A1 (ja) * 2017-11-13 2019-05-16 シャープ株式会社 動画像符号化装置および動画像復号装置
CN111699682A (zh) * 2017-12-07 2020-09-22 韩国电子通信研究院 用于使用通道之间的选择性信息共享进行编码和解码的方法和设备
KR102618692B1 (ko) * 2018-06-15 2024-01-02 삼성전자주식회사 노이즈 또는 디서의 영향을 감소시키기 위한 디스플레이 구동 회로 및 방법
US10904529B2 (en) 2018-01-19 2021-01-26 Qualcomm Incorporated Quantization group for video coding
US10652571B2 (en) 2018-01-25 2020-05-12 Qualcomm Incorporated Advanced motion vector prediction speedups for video coding
US20190238845A1 (en) * 2018-01-26 2019-08-01 Qualcomm Incorporated Adaptive loop filtering on deblocking filter results in video coding
US20190246122A1 (en) 2018-02-08 2019-08-08 Qualcomm Incorporated Palette coding for video coding
CA3092638A1 (en) * 2018-03-01 2019-09-06 Arris Enterprises Llc System and method of motion information storage for video coding and signaling
US10735730B2 (en) * 2018-03-07 2020-08-04 Tencent America LLC Flexible tree structure
WO2019190202A1 (ko) * 2018-03-27 2019-10-03 주식회사 케이티 비디오 신호 처리 방법 및 장치
US11470359B2 (en) * 2018-03-30 2022-10-11 Sharp Kabushiki Kaisha Systems and methods for partitioning video blocks at a boundary of a picture for video coding
WO2019199045A1 (ko) * 2018-04-11 2019-10-17 엘지전자 주식회사 제한된 참조 영역이 설정된 인터 예측을 이용한 영상 코딩 방법 및 그 장치
WO2019204234A1 (en) * 2018-04-15 2019-10-24 Arris Enterprises Llc Unequal weight planar motion vector derivation
US10609402B2 (en) 2018-05-02 2020-03-31 Tencent America LLC Method and apparatus for prediction and transform for small blocks
US10462486B1 (en) 2018-05-07 2019-10-29 Tencent America, Llc Fast method for implementing discrete sine transform type VII (DST 7)
WO2019229169A1 (en) * 2018-05-30 2019-12-05 Huawei Technologies Co., Ltd. Multi-type tree depth extension for picture boundary handling
US10645396B2 (en) 2018-06-04 2020-05-05 Tencent America LLC Method and apparatus for implicit transform splitting
JP7104186B2 (ja) 2018-06-05 2022-07-20 北京字節跳動網絡技術有限公司 Ｉｂｃとａｔｍｖｐとの間でのインタラクション
WO2019234605A1 (en) 2018-06-05 2019-12-12 Beijing Bytedance Network Technology Co., Ltd. Extended quad-tree with asymmetric sub-blocks and different tree for chroma
CN110636298B (zh) 2018-06-21 2022-09-13 北京字节跳动网络技术有限公司 对于Merge仿射模式和非Merge仿射模式的统一约束
TWI729422B (zh) 2018-06-21 2021-06-01 大陸商北京字節跳動網絡技術有限公司 色彩分量間的子區塊移動向量繼承
US10542260B1 (en) 2018-07-02 2020-01-21 Tencent America LLC Method and apparatus for video coding
US10609403B2 (en) * 2018-07-09 2020-03-31 Tencent America LLC Method and apparatus for block partition with non-uniform quad split
US10743029B2 (en) 2018-07-30 2020-08-11 Tencent America LLC Constraints on coding unit partition
CN117768651A (zh) 2018-09-24 2024-03-26 北京字节跳动网络技术有限公司 处理视频数据的方法、装置、介质、以及比特流存储方法
CN112997495B (zh) 2018-11-10 2024-02-20 北京字节跳动网络技术有限公司 当前图片参考中的取整
CA3119397C (en) * 2018-11-12 2023-10-03 Huawei Technologies Co., Ltd. Video encoder, video decoder and methods of encoding or decoding a picture
CN111294603B (zh) * 2018-12-06 2023-09-29 华为技术有限公司 视频编解码方法及装置
KR20240010542A (ko) * 2018-12-17 2024-01-23 삼성전자주식회사 예측 모드를 시그널링하는 비디오 신호 처리 방법 및 장치
EP3907988A4 (en) 2019-01-08 2022-06-29 Huawei Technologies Co., Ltd. Image prediction method, device, apparatus and system and storage medium
EP3941046A4 (en) * 2019-03-14 2022-12-21 LG Electronics Inc. IMAGE CODING/DECODING METHOD AND APPARATUS FOR PERFORMING INTRA PREDICTION, AND BITSTREAM TRANSMISSION METHOD
WO2020219733A1 (en) 2019-04-24 2020-10-29 Bytedance Inc. Quantized residual differential pulse code modulation representation of coded video
CN113796069B (zh) 2019-05-01 2024-03-08 字节跳动有限公司 使用量化残差差分脉冲编解码调制编解码的帧内编解码视频
EP3948663A4 (en) 2019-05-02 2022-06-08 ByteDance Inc. CODING MODE BASED ON A CODING TREE STRUCTURE TYPE
WO2020223612A1 (en) 2019-05-02 2020-11-05 Bytedance Inc. Signaling in transform skip mode
CN117241033A (zh) * 2019-08-06 2023-12-15 北京字节跳动网络技术有限公司 使用屏幕内容编码工具进行视频编码和解码
BR112022003732A2 (pt) 2019-09-02 2022-10-11 Beijing Bytedance Network Tech Co Ltd Método e aparelho para processamento de dados de vídeo, e, meios de armazenamento e de gravação legíveis por computador não transitórios
KR102649584B1 (ko) 2019-09-21 2024-03-21 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 크로마 인트라 모드에 기초한 크기 제한
JP7469904B2 (ja) * 2020-02-21 2024-04-17 シャープ株式会社 画像復号装置、画像符号化装置、画像復号方法及び画像符号化方法
WO2021201384A1 (ko) * 2020-04-03 2021-10-07 엘지전자 주식회사 포인트 클라우드 데이터 처리 장치 및 방법
EP3972272A1 (en) * 2020-09-17 2022-03-23 Lemon Inc. Chroma format and bit depth indication in coded video
CN117501693A (zh) * 2021-05-24 2024-02-02 北京达佳互联信息技术有限公司 用于帧间预测的重叠块运动补偿的方法和设备
WO2023274302A1 (en) * 2021-06-30 2023-01-05 Beijing Bytedance Network Technology Co., Ltd. Recursive prediction unit in video coding

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008123753A1 (en) 2007-04-09 2008-10-16 Lg Electronics Inc. A method and an apparatus for processing a video signal
BRPI0818649A2 (pt) 2007-10-16 2015-04-07 Thomson Licensing Métodos e aparelho para codificação e decodificação de vídeo em superblocos geometricamente particionados.
FR2926694B1 (fr) 2008-01-18 2010-04-16 Sagem Comm Decodeur de donnees video et procede de decodage de donnees video
KR101487686B1 (ko) * 2009-08-14 2015-01-30 삼성전자주식회사 비디오 부호화 방법 및 장치, 비디오 복호화 방법 및 장치
JP5672678B2 (ja) 2009-08-21 2015-02-18 Tdk株式会社 電子部品及びその製造方法
EA037919B1 (ru) 2009-10-20 2021-06-07 Шарп Кабусики Кайся Устройство кодирования движущихся изображений, устройство декодирования движущихся изображений, система кодирования/декодирования движущихся изображений, способ кодирования движущихся изображений и способ декодирования движущихся изображений
KR101452713B1 (ko) * 2009-10-30 2014-10-21 삼성전자주식회사 픽처 경계의 부호화 단위를 부호화, 복호화 하는 방법 및 장치
KR101457396B1 (ko) 2010-01-14 2014-11-03 삼성전자주식회사 디블로킹 필터링을 이용한 비디오 부호화 방법과 그 장치, 및 디블로킹 필터링을 이용한 비디오 복호화 방법 및 그 장치
HUE025960T2 (en) 2010-04-13 2016-04-28 Ge Video Compression Llc Video coding using multi-tree subdivisions of images
RU2528132C2 (ru) 2010-04-13 2014-09-10 Самсунг Электроникс Ко., Лтд. Способ кодирования видео и устройство кодирования видео с использованием блоков предсказания на основании блоков кодирования, определенных в соответствии с древовидной структурой, и способ декодирования видео и устройство декодирования видео с использованием блоков предсказания на основании блоков кодирования, определенных в соответствии с древовидной структурой
RS57973B1 (sr) 2010-08-17 2019-01-31 Samsung Electronics Co Ltd Aparat za dekodiranje video zapisa upotrebom jedinice za transformaciju promenljive strukture stabla
US20120170648A1 (en) * 2011-01-05 2012-07-05 Qualcomm Incorporated Frame splitting in video coding
US9071851B2 (en) 2011-01-10 2015-06-30 Qualcomm Incorporated Adaptively performing smoothing operations
US8548057B2 (en) * 2011-01-25 2013-10-01 Microsoft Corporation Video coding redundancy reduction
KR20120090740A (ko) 2011-02-07 2012-08-17 (주)휴맥스 정밀한 단위의 필터 선택을 적용한 영상 부호화/복호화 장치 및 방법
CN106878722B (zh) * 2011-06-24 2019-11-12 太阳专利托管公司 解码方法、解码装置、编码方法、编码装置
US9883203B2 (en) 2011-11-18 2018-01-30 Qualcomm Incorporated Adaptive overlapped block motion compensation
US20130188719A1 (en) 2012-01-20 2013-07-25 Qualcomm Incorporated Motion prediction in svc using motion vector for intra-coded block
US9462275B2 (en) 2012-01-30 2016-10-04 Qualcomm Incorporated Residual quad tree (RQT) coding for video coding
CN102724508A (zh) * 2012-06-07 2012-10-10 西安电子科技大学 Jpeg2000的分辨率自适应节点树编码方法
CN104885467B (zh) 2013-01-30 2018-08-17 英特尔公司 用于下一代视频编码的内容自适应参数变换
CN104065973B (zh) * 2013-03-20 2017-11-17 华为技术有限公司 一种高性能视频编码搜索的方法及装置
GB2513111A (en) 2013-04-08 2014-10-22 Sony Corp Data encoding and decoding
US9906813B2 (en) 2013-10-08 2018-02-27 Hfi Innovation Inc. Method of view synthesis prediction in 3D video coding
WO2015135169A1 (en) 2014-03-13 2015-09-17 Qualcomm Incorporated Constrained depth intra mode coding for 3d video coding
KR20170002460A (ko) 2014-06-11 2017-01-06 엘지전자 주식회사 임베디드 블록 파티셔닝을 이용하여 비디오 신호를 인코딩, 디코딩하는 방법 및 장치
US20160081020A1 (en) 2014-09-16 2016-03-17 Telefonaktiebolaget L M Ericsson (Publ) Drx cycle configuration in dual connectivity
FR3029333A1 (fr) 2014-11-27 2016-06-03 Orange Procede de codage et decodage d'images, dispositif de codage et decodage et programmes d'ordinateur correspondants
US10382795B2 (en) * 2014-12-10 2019-08-13 Mediatek Singapore Pte. Ltd. Method of video coding using binary tree block partitioning
WO2016090568A1 (en) 2014-12-10 2016-06-16 Mediatek Singapore Pte. Ltd. Binary tree block partitioning structure
WO2016154963A1 (en) 2015-04-01 2016-10-06 Mediatek Inc. Methods for chroma coding in video codec
WO2017008263A1 (en) * 2015-07-15 2017-01-19 Mediatek Singapore Pte. Ltd. Conditional binary tree block partitioning structure
US20170150156A1 (en) 2015-11-25 2017-05-25 Qualcomm Incorporated Illumination compensation with non-square predictive blocks in video coding
WO2017088810A1 (en) * 2015-11-27 2017-06-01 Mediatek Inc. Method and apparatus of entropy coding and context modelling for video and image coding
AU2015261734A1 (en) * 2015-11-30 2017-06-15 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding video data according to local luminance intensity
US10212444B2 (en) * 2016-01-15 2019-02-19 Qualcomm Incorporated Multi-type-tree framework for video coding

Also Published As

Publication number Publication date
MX2018011376A (es) 2019-02-13
SA518392315B1 (ar) 2023-10-18
KR20180122638A (ko) 2018-11-13
ES2901503T3 (es) 2022-03-22
HK1256749A1 (zh) 2019-10-04
AU2017238068A1 (en) 2018-08-30
CO2018009880A2 (es) 2018-09-28
CL2018002664A1 (es) 2019-01-25
NZ745288A (en) 2024-08-30
RU2746935C2 (ru) 2021-04-22
AU2017238068B2 (en) 2022-04-07
JP2019512963A (ja) 2019-05-16
SG11201806737RA (en) 2018-10-30
CN108781293A (zh) 2018-11-09
EP3434018A1 (en) 2019-01-30
HUE057252T2 (hu) 2022-04-28
PH12018501701A1 (en) 2019-06-10
KR102465214B1 (ko) 2022-11-10
EP3434018B1 (en) 2021-11-10
RU2018133028A (ru) 2020-04-22
US20170272782A1 (en) 2017-09-21
US11223852B2 (en) 2022-01-11
CA3014785A1 (en) 2017-09-28
CN108781293B9 (zh) 2023-10-13
CN108781293B (zh) 2022-05-27
WO2017165375A1 (en) 2017-09-28
BR112018068927A2 (pt) 2019-01-22
RU2018133028A3 (ja) 2020-07-14

Similar Documents

Publication Publication Date Title
JP6908618B2 (ja) ２レベルのマルチタイプツリーフレームワークを使用したビデオデータのデコーディング
JP6950004B2 (ja) ビデオコーディングにおいて変換処理とともに適用されるイントラフィルタ処理
EP3357247B1 (en) Improved video intra-prediction using position-dependent prediction combination for video coding
JP7044765B2 (ja) ビデオコーディングのための線形モデルクロマイントラ予測
TWI755394B (zh) 二值化二次轉換指數
KR102546382B1 (ko) 비디오 코딩을 위한 가변 수의 인트라 모드들
CA3007664C (en) Multi-type-tree framework for video coding
KR102334126B1 (ko) 인트라 블록 복사를 위한 레지듀얼 예측
KR102182441B1 (ko) 비디오 코딩에서 ｈｅｖｃ 확장들을 위한 다중 계층들의 저복잡도 지원
US20150071357A1 (en) Partial intra block copying for video coding
JP2020504506A (ja) ビデオコーディングのためのマルチタイプツリーフレームワーク
JP2018537908A (ja) ビデオデータの符号情報をコーディングすること
JP2018507616A (ja) 予測ユニットの柔軟な区分化
CA2838449A1 (en) Border pixel padding for intra prediction in video coding
KR20160135756A (ko) 레지듀 차분 펄스 코드 변조을 위한 양자화 프로세스들
WO2013078313A1 (en) Transforms in video coding
KR20210135245A (ko) 비디오 코딩에서의 암시적 변환 선택

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200304

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200304

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210330

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210607

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210701

R150 Certificate of patent or registration of utility model

Ref document number: 6908618

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150