JP2018521554A - 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング - Google Patents

改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング Download PDF

Info

Publication number
JP2018521554A
JP2018521554A JP2017561313A JP2017561313A JP2018521554A JP 2018521554 A JP2018521554 A JP 2018521554A JP 2017561313 A JP2017561313 A JP 2017561313A JP 2017561313 A JP2017561313 A JP 2017561313A JP 2018521554 A JP2018521554 A JP 2018521554A
Authority
JP
Japan
Prior art keywords
context
transform
video
coding
bin
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.)
Granted
Application number
JP2017561313A
Other languages
English (en)
Other versions
JP2018521554A5 (ja
JP6873051B2 (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 JP2018521554A publication Critical patent/JP2018521554A/ja
Publication of JP2018521554A5 publication Critical patent/JP2018521554A5/ja
Application granted granted Critical
Publication of JP6873051B2 publication Critical patent/JP6873051B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H04N19/122—Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • 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/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
    • H04N19/126—Details of normalisation or weighting functions, e.g. normalisation matrices or variable uniform quantisers
    • 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/13—Adaptive entropy coding, e.g. adaptive variable length coding [AVLC] or context adaptive binary arithmetic coding [CABAC]
    • 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/136—Incoming video signal characteristics or properties
    • 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/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
    • 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/174—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 slice, e.g. a line of blocks or a group of 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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • 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/577—Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • 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/625—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using discrete cosine transform [DCT]
    • 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
    • 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
    • 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/172—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 picture, frame or field
    • 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/184—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 bits, e.g. of the compressed video stream

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Discrete Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Compression Of Band Width Or Redundancy In Fax (AREA)

Abstract

ビデオコーディングデバイスは、ビデオデータを記憶するように構成されるメモリと、記憶されているビデオデータの少なくとも一部分を処理するように構成されるプロセッサとを含む。プロセッサは、ビデオデータの現在の変換係数を含む係数グループ(CG)を特定するように構成され、CGは変換単位内の変換係数の部分集合を表す。プロセッサはさらに、変換サイズと、(i)変換単位と関連付けられるコーディングモード、または(ii)変換単位と関連付けられる変換行列の一方または両方との組合せに基づいて、CGのサイズを決定するように構成される。

Description

本出願は、その内容全体が参照により本明細書に組み込まれる、2015年5月29日に出願された米国仮出願第62/168,571号の利益を主張する。
本開示は、ビデオコーディングに関する。
デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレス放送システム、携帯情報端末(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)規格、およびそのような規格の拡張によって定義された規格に記載されるものなどの、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信し、受信し、符号化し、復号し、かつ/または記憶することができる。
ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間的(ピクチャ内)予測および/または時間的(ピクチャ間)予測を含む。ブロックベースのビデオコーディングのために、ビデオスライス(たとえば、ビデオフレーム、またはビデオフレームの一部分)は、ビデオブロックに区分されることがあり、ビデオブロックは、ツリーブロック、コーディング単位(CU)、および/またはコーディングノードと呼ばれることもある。ピクチャのイントラコーディングされた(I)スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコーディングされた(PまたはB)スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用することができる。ピクチャは、フレームと呼ばれることがあり、参照ピクチャは、参照フレームと呼ばれることがある。
空間的予測または時間的予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルに従って符号化され、残差データは、コーディングされたブロックと予測ブロックとの差分を示す。イントラコーディングされるブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、画素領域から変換領域に変換され、残差変換係数をもたらすことがあり、その残差変換係数は、次いで量子化され得る。最初に2次元アレイに配置される量子化された変換係数は、変換係数の1次元ベクトルを生成するために走査されることがあり、エントロピーコーディングが、さらなる圧縮を実現するために適用されることがある。
D. Marpe、H. Schwarz、およびT. Wiegand「Context-Based Adaptive Binary Arithmetic Coding in the H.264/AVC Video Compression Standard」、IEEE Trans. Circuits and Systems for Video Technology、vol. 13、no. 7、2003年7月 V. SzeおよびM. Budagavi、「High throughput CABAC entropy coding in HEVC」、IEEE Transactions on Circuits and Systems for Video Technology (TCSVT)、vol. 22、no. 12、pp. 1778-1791、2012年12月 T. Nguyen、D. Marpe、T. Wiegand、「Non-CE11: Proposed Cleanup for Transform Coefficient Coding」、JCTVC-H0228、第8回会合:サンノゼ、カリフォルニア州、米国、2012年2月1日〜10日
本開示は、ブロックベースのハイブリッドビデオコーディングにおけるエントロピーコーディングモジュールに関する、例示的な技法を説明する。これらの技法は、HEVC(High Efficiency Video Coding)などの任意の既存のビデオコーデックに適用されることが可能であり、またはこれらの技法は、任意の未来のビデオコーディング規格または他のプロプライエタリの、もしくはプロプライエタリではないコーディング技法における、効率的なコーディングツールになり得る。様々な態様が、バイナリ算術コーディング(BAC)ベースのコーディングデバイスのための、コンテキストモデリングおよびコンテキスト初期化の改善を対象とする。いくつかの技法が本明細書において説明され、本開示に従って、ビデオコーディングデバイスは技法を別々に、または様々な組合せで実施することができる。
一例では、本開示は、ビデオデータを復号するための方法を対象とし、この方法は、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前に復号された変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するステップを含み、コンテキストを決定するステップは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前に復号された変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するステップを備え、iが非負の整数を備え、以前に復号された変換係数のシンタックス要素の値の対応するi番目のビンを使用するステップは、以前に復号された変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前に復号された変換係数のシンタックス要素の値の他のビンを使用しないステップを備える。方法はさらに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをコンテキスト適応バイナリ算術コーディング(CABAC)復号するステップを含み得る。
別の例では、本開示は、ビデオデータを復号するための方法を対象とし、この方法は、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前に符号化された変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するステップを含み、コンテキストを決定するステップは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前に符号化された変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するステップを備え、iが非負の整数を備え、以前に符号化された変換係数のシンタックス要素の値の対応するi番目のビンを使用するステップは、以前に符号化された変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前に符号化された変換係数のシンタックス要素の値の他のビンを使用しないステップを備える。方法はさらに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABAC符号化するステップを含み得る。
別の例では、本開示はビデオデータをコーディングするためのデバイスを対象とし、このデバイスは、ビデオデータを記憶するように構成されるメモリと、1つまたは複数のプロセッサとを含む。1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前にコーディングされた変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するように構成され、コンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するように構成され、iが非負の整数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用するために、1つまたは複数のプロセッサは、以前にコーディングされた変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前にコーディングされた変換係数のシンタックス要素の値の他のビンを使用しないように構成される。プロセッサはさらに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディングするように構成され得る。
別の例では、本開示はビデオコーディング装置を対象とする。ビデオコーディング装置は、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前にコーディングされた変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するための手段を含むことがあり、コンテキストを決定するための手段は、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するための手段を備え、iが非負の整数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用するための手段は、以前にコーディングされた変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前にコーディングされた変換係数のシンタックス要素の値の他のビンを使用しないための手段を備える。ビデオコーディング装置はさらに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディングするための手段を含み得る。
別の例では、本開示は、命令が符号化されている非一時的コンピュータ可読記憶媒体を対象とする。この命令は、実行されると、ビデオコーディングデバイスの1つまたは複数のプロセッサに、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前にコーディングされた変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定させることができ、コンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するように構成され、iが非負の整数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用するために、1つまたは複数のプロセッサは、以前にコーディングされた変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前にコーディングされた変換係数のシンタックス要素の値の他のビンを使用しないように構成される。この命令はさらに、実行されると、ビデオコーディングデバイスの1つまたは複数のプロセッサに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディングさせ得る。
別の例では、本開示はビデオデータを復号する方法を対象とする。この方法は、以前に復号されたスライスの以前に復号されたブロックのためのコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するステップと、初期化されたコンテキスト情報を使用して現在のスライスのデータを復号するステップとを含み得る。
別の例では、本開示はビデオデータを符号化する方法を対象とする。この方法は、以前に符号化されたスライスの以前に符号化されたブロックのためのコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するステップと、初期化されたコンテキスト情報を使用して現在のスライスのデータを符号化するステップとを含み得る。
別の例では、本開示はビデオデータをコーディングするためのデバイスを対象とし、このデバイスは、ビデオデータを記憶するように構成されるメモリと、1つまたは複数のプロセッサとを含む。1つまたは複数のプロセッサは、記憶されているビデオデータの以前にコーディングされたスライスの以前にコーディングされたブロックをコーディングした後のコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化し、初期化されたコンテキスト情報を使用して現在のスライスのデータをコーディングするように構成され得る。
別の例では、本開示はビデオコーディング装置を対象とする。ビデオコーディング装置は、以前にコーディングされたスライスの以前にコーディングされたブロックをコーディングした後のコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するための手段と、初期化されたコンテキスト情報を使用して現在のスライスのデータをコーディングするための手段とを含み得る。
別の例では、本開示は、命令が符号化されている非一時的コンピュータ可読記憶媒体を対象とする。この命令は、実行されると、ビデオコーディングデバイスの1つまたは複数のプロセッサに、以前にコーディングされたスライスの以前にコーディングされたブロックをコーディングした後のコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化させ、初期化されたコンテキスト情報を使用して現在のスライスのデータをコーディングさせ得る。
別の例では、本開示はビデオデータを処理する方法を対象とする。この方法は、現在の変換係数を含む係数グループ(CG)を特定するステップを含むことがあり、CGは変換単位内の変換係数の部分集合を表す。この方法はさらに、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定するステップを含み得る。
別の例では、本開示はビデオデータをコーディングするためのデバイスを対象とし、このデバイスは、ビデオデータを記憶するように構成されるメモリと、1つまたは複数のプロセッサとを含む。1つまたは複数のプロセッサは、ビデオデータの現在の変換係数を含む係数グループ(CG)を特定するように構成されることがあり、CGは変換単位内の変換係数の部分集合を表す。1つまたは複数のプロセッサはさらに、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定するように構成され得る。
別の例では、本開示は、命令が符号化されている非一時的コンピュータ可読記憶媒体を対象とする。命令は、実行されると、ビデオコーディングデバイスの1つまたは複数のプロセッサに、ビデオデータの現在の変換係数を含む係数グループ(CG)を特定させ、ここでCGは変換単位内の変換係数の部分集合を表し、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定させ得る。
別の例では、本開示はビデオデータをコーディングするための装置を対象とする。この装置は、現在の変換係数を含む係数グループ(CG)を特定するための手段を含むことがあり、CGは変換単位内の変換係数の部分集合を表す。この装置はさらに、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定するための手段を含み得る。
別の例では、本開示は、符号化されたビデオビットストリームを記憶する非一時的コンピュータ可読記憶媒体を対象とする。このビットストリームは、ビデオ復号デバイスによって処理されると、ビデオ復号デバイスの1つまたは複数のプロセッサに、ビデオデータの現在の変換係数を含む係数グループ(CG)を特定させ、ここでCGは変換単位内の変換係数の部分集合を表し、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定させ得る。
別の例では、本開示は、符号化されたビデオビットストリームを記憶する非一時的コンピュータ可読記憶媒体を対象とする。このビットストリームは、ビデオ復号デバイスによって処理されると、ビデオ復号デバイスの1つまたは複数のプロセッサに、以前にコーディングされたスライスの以前にコーディングされたブロックをコーディングした後のコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化させ、初期化されたコンテキスト情報を使用して現在のスライスのデータをコーディングさせ得る。
別の例では、本開示は、符号化されたビデオビットストリームを記憶する非一時的コンピュータ可読記憶媒体を対象とする。このビットストリームは、ビデオ復号デバイスによって処理されると、ビデオ復号デバイスの1つまたは複数のプロセッサに、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前にコーディングされた変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定させることができ、コンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するように構成され、iが非負の整数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用するために、1つまたは複数のプロセッサは、以前にコーディングされた変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前にコーディングされた変換係数のシンタックス要素の値の他のビンを使用しないように構成される。このビットストリームは、ビデオ復号デバイスによって処理されると、ビデオ復号デバイスの1つまたは複数のプロセッサに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディングさせ得る。
本開示の1つまたは複数の態様の詳細が、添付の図面および以下の説明に記載される。本開示に記載される技法の他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。
改善されたコンテキスト適応バイナリ算術コーディング(CABAC)設計に従ってデータをコーディングするための技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図である。 バイナリ算術コーディング(BAC)に従ったrange更新技法を示す概念図である。 バイナリ算術コーディング(BAC)に従ったrange更新技法を示す概念図である。 rangeに依存するBAC出力の例を示す概念図である。 改善されたCABAC設計に従ってデータをコーディングするための技法を実施し得るビデオエンコーダの例を示すブロック図である。 本開示の技法に従ってCABACを実行するように構成され得る例示的なエントロピー符号化ユニットのブロック図である。 改善されたCABAC設計に従ってデータをコーディングするための技法を実施し得るビデオデコーダの例を示すブロック図である。 本開示の技法に従ってCABACを実行するように構成され得る例示的なエントロピー符号化ユニットのブロック図である。 テーブルベースのバイナリ算術コーディングの例示的なプロセスを示すフローチャートである。 残差4分木構造に基づく変換方式を示す概念図である。 本明細書において説明されるコンテキストモデリング技法に関してエントロピー復号ユニットおよび/またはエントロピー符号化ユニットが使用し得るテンプレートの一例を示す図である。 係数グループに基づく例示的な係数走査を示す概念図である。 ビン導出の例を示す概念図である。 異なるルーマビンに対する、TU内の異なる位置に対するコンテキストインデックスの範囲を示す概念図である。 ビデオコーディングデバイスまたはその様々な構成要素が、本開示のコンテキストモデリング技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセスを示すフローチャートである。 ビデオコーディングデバイスまたはその様々な構成要素が、本開示の継承ベースのコンテキスト初期化技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセスを示すフローチャートである。 ビデオコーディングデバイスまたはその様々な構成要素が、ビデオ復号プロセスの一部として本開示の技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセスを示すフローチャートである。 ビデオコーディングデバイスまたはその様々な構成要素が、本開示の1つまたは複数の係数グループ(CG)サイズ決定技法を実施するために実行し得る、例示的なプロセスを示すフローチャートである。
本開示の技法は全般に、ブロックベースのハイブリッドビデオコーディングにおけるエントロピーコーディングに関する。これらの技法は、HEVC(High Efficiency Video Coding)などの任意の既存のビデオコーデックに適用されることが可能であり、またはこれらの技法は、任意の未来のビデオコーディング規格または他のプロプライエタリの、もしくはプロプライエタリではないコーディング技法における、効率的なコーディングツールであり得る。例示および説明を目的に、本開示の技法は全般に、HEVC(またはITU-T H.265)および/またはITU-T H.264に関して説明される。
ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、および、そのスケーラブルビデオコーディング(SVC)拡張とマルチビュービデオコーディング(MVC)拡張とを含むITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)を含む。
加えて、その範囲拡張、マルチビュー拡張(MV-HEVC)、およびスケーラブル拡張(SHVC)を含む、新しいビデオコーディング規格、すなわちHigh Efficiency Video Coding(HEVC)またはITU-T H.265が、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 WDと呼ばれるHEVCの暫定仕様は、phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zipから入手可能である。
本開示の技法は、CABACコーディングと関連付けられる様々な問題を克服することができる。具体的には、これらの技法は、改善されたCABAC設計およびより効率的な変換係数コンテキストモデリング技法を含み、これらは単独で、または一緒に使用され得る。エントロピーコーディングでは、シンタックス要素の値はバイナリ形式で表され、各ビット(または「ビン」)は特定のコンテキストを使用してコーディングされる。本開示の様々な態様によれば、シンタックス要素の値のビンの集合のためのコンテキスト情報は、以前の変換係数のシンタックス要素の以前にコーディングされた値のそれぞれのビンを使用して決定され得る。追加の詳細が以下で論じられる。
図1は、改善されたCABAC設計に従ってデータをコーディングするための技法を利用し得る例示的なビデオ符号化および復号システム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は、改善されたCABAC設計に従ってビデオデータをコーディングするための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または配置を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信することがある。同様に、宛先デバイス14は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースすることがある。
図1の示されるシステム10は一例にすぎない。改善されたCABAC設計に従ってデータをコーディングするための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。一般に、本開示の技法はビデオ符号化デバイスによって実行されるが、この技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス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によっても使用される、シンタックス情報を含むことがあり、このシンタックス情報は、ブロックおよび他のコーディングされた単位、たとえばGOPの特性および/または処理を記述するシンタックス要素を含む。表示デバイス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つまたは複数のエンコーダまたはデコーダに含まれることがあり、これらのいずれもが、それぞれのデバイスの中で複合エンコーダ/デコーダ(コーデック)の一部として統合されることがある。
一般に、ITU-T H.265によれば、ビデオフレームまたはピクチャは、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディング単位(LCU)に分割され得る。ビットストリーム内のシンタックスデータは、ピクセル数の観点で最大のコーディング単位であるLCUのサイズを定義し得る。スライスは、コーディング順序においていくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木に従ってコーディング単位(CU)に分割され得る。一般に、4分木データ構造はCU当たり1つのノードを含み、ルートノードはツリーブロックに対応する。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規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、4つの子ノード(サブCUとも呼ばれる)に分割されることがあり、各子ノードは、今度は親ノードになり、別の4つの子ノードに分割されることがある。最後の、4分木のリーフノードと呼ばれる分割されていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コーディングされたビットストリームと関連付けられるシンタックスデータは、最大CU深度と呼ばれる、ツリーブロックが分割され得る最大の回数を定義することができ、コーディングノードの最小のサイズを定義することもできる。したがって、ビットストリームは、最小コーディング単位(SCU)を定義することもできる。本開示は、HEVCの文脈におけるCU、予測単位(PU)、もしくは変換単位(TU)のいずれか、または、他の規格の文脈における同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそのサブブロック)を指すために、「ブロック」という用語を使用する。
CUは、コーディングノードと、コーディングノードと関連付けられる予測単位(PU)および変換単位(TU)とを含む。CUのサイズはコーディングノードのサイズに対応し、一般に、形状が正方形である。CUのサイズは、8×8ピクセルから、たとえば64×64ピクセル以上の最大サイズを有するツリーブロックのサイズにまで、わたり得る。各CUは、1つまたは複数のPUと1つまたは複数のTUとを含み得る。CUと関連付けられるシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述し得る。区分モードは、CUがスキップモードもしくは直接モードで符号化されているか、イントラ予測モードで符号化されているか、またはインター予測モードで符号化されているかに応じて異なり得る。PUは、形状が非正方形であるように区分され得る。CUと関連付けられるシンタックスデータはまた、たとえば、4分木に従った1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形(たとえば、矩形)であることが可能である。
HEVC規格は、異なるCUに対しては異なり得る、TUに従った変換を可能にする。TUは通常、区分されたLCUのために定義された所与のCU内のPUのサイズに基づいてサイズが決められるが、これは、必ずしもそうでないことがある。TUは通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT)として知られる4分木構造を使用して、より小さい単位に細分され得る。RQTのリーフノードは、変換単位(TU)と呼ばれ得る。TUと関連付けられるピクセル差分値は、変換係数を生成するために変換されることがあり、変換係数は量子化されることがある。
リーフ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)を記述し得る。
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のサイズに対応し得る。
その上、リーフCUのTUはまた、残差4分木(RQT)と呼ばれるそれぞれの4分木データ構造と関連付けられ得る。すなわち、リーフCUがTUへとどのように区分されるかを示す4分木を、リーフCUは含み得る。TU4分木のルートノードは一般にリーフCUに対応し、一方、CU4分木のルートノードは一般にツリーブロック(またはLCU)に対応する。分割されないRQTのTUは、リーフTUと呼ばれる。一般に、本開示は、別段述べられていない限り、リーフCUを指すためにCUという用語を、リーフTUを指すためにTUという用語を使用する。
ビデオシーケンスは通常、一連のビデオフレームまたはピクチャを含む。ピクチャグループ(GOP)は一般に、一連の1つまたは複数のビデオピクチャを備える。GOPは、GOPに含まれるピクチャの数を記述するシンタックスデータを、GOPのヘッダ、ピクチャのうちの1つまたは複数のヘッダ、または他の箇所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、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を指す。
本開示では、「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は、たとえば、本開示において説明される改善されたコンテキスト適応バイナリ算術コーディング(CABAC)設計に従って、1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30により使用するための、符号化されたビデオデータと関連付けられるシンタックス要素をエントロピー符号化し得る。
一般に、ビデオデコーダ30は、ビデオエンコーダ20により実行されるものと実質的に同様の、しかし逆のプロセスを実行して、符号化されたデータを復号する。たとえば、ビデオデコーダ30は、受信されたTUの係数を逆量子化および逆変換して残差ブロックを再生する。ビデオデコーダ30は、シグナリングされた予測モード(イントラ予測またはインター予測)を使用して、予測されたブロックを形成する。次いで、ビデオデコーダ30は、予測されたブロックと残差ブロックを(ピクセルごとに)組み合わせて元のブロックを再生する。デブロッキングプロセスを実行してブロック境界に沿った視覚的なアーティファクトを減らすことなどの、追加の処理が実行され得る。さらに、ビデオデコーダ30は、ビデオエンコーダ20のCABAC符号化プロセスと実質的に同様の、しかし逆の方式で、CABACを使用してシンタックス要素を復号し得る。
本開示の技法によれば、ビデオエンコーダ20およびビデオデコーダ30は、改善されたCABAC設計に従ってデータをコーディングするように構成され得る。個別に、または任意の組合せで適用され得る、いくつかの技法が以下で論じられる。本開示は全般に、ビデオデコーダ30などの別のデバイスに特定の情報を「シグナリング」するビデオエンコーダ20に言及することがある。しかしながら、ビデオエンコーダ20は、特定のシンタックス要素をビデオデータの様々な符号化された部分と関連付けることによって情報をシグナリングし得ると理解されるべきである。すなわち、ビデオエンコーダ20は、ビデオデータの様々な符号化された部分のヘッダに特定のシンタックス要素を格納することにより、データを「シグナリング」し得る。場合によっては、そのようなシンタックス要素は、ビデオデコーダ30によって受信および復号される前に、符号化および記憶され得る。したがって、「シグナリング」という用語は一般に、そのような通信がリアルタイムもしくはほぼリアルタイムで生じるか、またはある時間の長さにわたって生じるかにかかわらず、符号化の時点で、媒体にシンタックス要素を記憶するときに生じ得るような、圧縮されたビデオデータを復号するためのシンタックスまたは他のデータの通信を指すことがあり、シンタックス要素は次いで、この媒体に記憶された後の任意の時間に、復号デバイスによって取り出されることがある。
以下の段落は、BAC技法およびCABAC技法をより詳細に説明する。BACは一般に、再帰的に間隔を細分する手順である。BACは、H.264/AVCおよびH.265/HEVCビデオコーディング規格のCABACプロセスにおいてビンを符号化するために使用される。BACコーダの出力は、最後のコーディングされる確率間隔内のある確率に対する値またはポインタを表す、バイナリストリームである。確率間隔は範囲および下端値によって指定される。範囲は確率間隔の長さである。「low」はコーディング間隔の下限である。
ビデオコーディングへの算術コーディングの適用は、D. Marpe、H. Schwarz、およびT. Wiegand「Context-Based Adaptive Binary Arithmetic Coding in the H.264/AVC Video Compression Standard」、IEEE Trans. Circuits and Systems for Video Technology、vol. 13、no. 7、2003年7月に記載されている。CABACは、3つの主要な機能、すなわち、バイナリ化、コンテキストモデリング、および算術コーディングを伴う。バイナリ化とは、バイナリシンボル(または「ビン」)へとシンタックス要素をマッピングする機能を指す。バイナリシンボルは「ビンストリング」とも呼ばれることがある。コンテキストモデリングとは、様々なビンの確率を推定する機能を指す。算術コーディングとは、推定される確率に基づいて、ビンをビットに圧縮する後続の機能を指す。バイナリ算術コーダなどの、様々なデバイスおよび/またはそれらのモジュールが、算術コーディングの機能を実行し得る。
単項(U)、切捨て単項(TU)、k次指数ゴロム(EGk)、および固定長(FL)を含む、いくつかの異なるバイナリ化プロセスがHEVCにおいて使用される。様々なバイナリ化プロセスの詳細が、V. SzeおよびM. Budagavi、「High throughput CABAC entropy coding in HEVC」、IEEE Transactions on Circuits and Systems for Video Technology(TCSVT)、vol. 22、no. 12、pp. 1778-1791、2012年12月に記載されている。
CABACにおける各コンテキスト(すなわち、確率モデル)は、状態および優勢シンボル(MPS)値によって表される。各状態(σ)は、特定のシンボル(たとえば、ビン)の確率(pσ)を、劣勢シンボル(LPS)であるものとして暗黙的に表す。シンボルは、LPSまたは優勢シンボル(MPS)であり得る。シンボルはバイナリであるので、MPSおよびLPSは0または1であり得る。確率は、対応するコンテキストに対して推定され、算術コーダを使用してシンボルをエントロピーコーディングするために(暗黙的に)使用される。
BACのプロセスは、コーディングすべきコンテキストおよびコーディングされているビンの値に応じて内部値「range」および「low」を変更する、状態機械によって扱われる。コンテキストの状態(すなわち、その確率)に応じて、rangeは、rangeMPSσ(状態σにおける優勢シンボルの範囲)およびrangeLPSσ(状態σにおける劣勢シンボルの範囲)へと分割される。理論的には、確率状態σのrangeLPSσ値は、
rangeLPSσ= range×pσ
という乗算によって導出され、pσはLPSを選択する確率である。当然、MPSの確率は1-pσである。等価的に、rangeMPSσはrangeからrangeLPSσを引いたものに等しい。BACは、コーディングすべきコンテキストビンの状態、現在のrange、およびコーディングされているビン(すなわち、LPSまたはMPSに等しいビンである)の値に応じて、rangeを繰り返し更新する。
ビデオエンコーダ20はさらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびGOPベースのシンタックスデータなどのシンタックスデータを、たとえばフレームヘッダ、ブロックヘッダ、スライスヘッダ、またはGOPヘッダの中でビデオデコーダ30に送信し得る。GOPシンタックスデータは、それぞれのGOPの中のフレーム数を記述することができ、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化/予測モードを示すことができる。
ビデオエンコーダ20およびビデオデコーダ30は各々、該当する場合、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な適切なエンコーダ回路またはデコーダの回路のうちのいずれかとして実装され得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれることがあり、これらのいずれもが、複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合されることがある。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/または携帯電話などのワイヤレス通信デバイスを備え得る。
図2Aおよび図2Bは、BACに従ったrange更新技法を示す概念図である。図2Aおよび図2Bは、ビンnにおけるこのプロセスの例を示す。図2Aの例100では、ビンnにおいて、ビン2におけるrangeは、あるコンテキスト状態(σ)を仮定すると、LPS(pσ)という確率によって与えられるRangeMPSおよびRangeLPSを含む。例100は、ビンnの値がMPSに等しいときの、ビンn+1におけるrangeの更新を示す。この例では、lowは同じままであるが、ビンn+1におけるrangeの値はビンnにおけるRangeMPSの値まで減らされる。図2Bの例102は、ビンnの値がMPSに等しくない(すなわち、LPSに等しい)ときの、ビンn+1におけるrangeの更新を示す。この例では、lowはビンnにおけるRangeLPSの下側のrange値に移される。加えて、ビンn+1におけるrangeの値は、ビンnにおけるRangeLPSの値まで減らされる。
HEVCでは、rangeは9ビットを用いて表現され、lowは10ビットを用いて表現される。rangeおよびlowの値を十分な精度に保つために、再正規化プロセスがある。再正規化は、rangeが256未満であるときには常に発生する。したがって、rangeは、再正規化の後には常に256以上である。rangeおよびlowの値に応じて、BACは「0」もしくは「1」をビットストリームに出力し、または、今後の出力のために取っておくべき内部変数(BO:bits-outstandingと呼ばれる)を更新する。
図3は、rangeに依存するBAC出力の例を示す概念図である。たとえば、「1」は、rangeおよびlowがある閾値(たとえば、512)を上回るとき、ビットストリームに出力される。「0」は、rangeおよびlowがある閾値(たとえば、512)を下回るとき、ビットストリームに出力される。rangeおよびlowがある閾値と閾値の間にあるとき、ビットストリームには何も出力されない。代わりに、BO値がインクリメントされ、次のビンが符号化される。
HEVCのCABACコンテキストモデルでは、128個の状態がある。0から63であり得る、64個の可能なLPS確率(状態σによって表記される)がある。各MPSは0または1であり得る。したがって、128個の状態は、64個の状態確率と、MPSに対する2つのあり得る値(0または1)を乗じたものである。したがって、確率モデルは7ビットのエントリとして記憶され得る。各々の7ビットのエントリにおいて、6ビットが確率状態を表現するために割り振られることがあり、1ビットが適用可能なコンテキストメモリにおいて優勢シンボル(MPS)のために割り振られることがある。
LPS範囲(rangeLPSσ)を導出する計算を減らすために、HEVCでは、すべての場合に対する結果が、事前に計算され参照テーブルに概算として記憶されている。したがって、LPS範囲は、単純なテーブル参照を使用することによって、乗算を伴わずに取得され得る。乗算を避けることは一部のデバイスまたはアプリケーションでは重要であることがあり、それは、この演算が多くのハードウェアアーキテクチャにおいて重大なレイテンシを引き起こし得るからである。
4列の事前に計算されたLPS範囲が、乗算の代わりに使用され得る。この範囲は4つのセグメントに分割される。セグメントインデックスは、質問(range>>6)&3によって導出され得る。実質的に、セグメントインデックスは、実際の範囲からビットをシフトして落とすことによって導出される。以下のTable 1(表1)は、可能な範囲とそれらの対応するインデックスとを示す。
そうすると、LPS範囲テーブルは、64個のエントリ(各確率状態に対して1個)に4(各範囲インデックスに対して1個)を乗じたものを有する。各エントリは、Range LPS、すなわち、範囲とLPS確率を乗じた値である。このテーブルの一部の例が、以下のTable 2(表2)に示されている。Table 2(表2)は確率状態9〜12を示す。HEVCに対する1つの提案では、確率状態は0〜63にわたり得る。
各セグメント(すなわち、範囲値)において、各確率状態σのLPS範囲が事前に定義される。言い換えると、確率状態σのLPS範囲は4つの値(すなわち、各範囲インデックスに対して1つの値)へと量子化される。所与の点において使用される特定のLPS範囲は、範囲がどのセグメントに属するかに依存する。テーブルにおいて使用される可能なLPS範囲の数は、テーブルの列の数(すなわち、可能なLPS範囲値の数)とLPS範囲の精度との間のトレードオフである。一般に、より列が多いと、LPS範囲値の量子化誤差がより小さくなるが、テーブルを記憶するためにより多くのメモリも必要になる。より列が少ないと量子化誤差が増えるが、テーブルを記憶するために必要とされるメモリは減る。
上で説明されたように、各LPS確率状態は対応する確率を有する。HEVCでは、64個の代表的な確率値pσ∈[0.01875, 0.5]は、再帰的な式である以下の式(1)に従って、LPS(劣勢シンボル)に対して導出される。
上の例では、選ばれたスケーリング係数α≒0.9492および確率の集合の個数N=64は、確率表現の精度と高速な適応に対する望みとの間の、良好な妥協点である。いくつかの例では、1により近いαの値は、より高い精度で遅い適応(「安定状態挙動」)をもたらし得るが、精度の低下という犠牲を払ってαの値を下げることで、非静的な場合に対してより高速な適応が実現され得る。スケーリング係数αは、現在の更新に対して重大な影響がある、以前に符号化されたビンの数を示すウィンドウサイズに対応し得る。MPS(優勢シンボル)の確率は、1からLPS(劣勢シンボル)の確率を引いたものである。言い換えると、MPSの確率は、式(1-LPS)によって表されることが可能であり、ここで「LPS」はLPSの確率を表す。したがって、HEVCにおいてCABACにより表され得る確率範囲は、[0.01875, 0.98125(=1-0.01875)]である。
CABACは、シンタックス要素の値のビット(または「ビン」)をコーディングするために使用されるコンテキストモデルの確率状態が、信号統計(すなわち、たとえばシンタックス要素のための以前にコーディングされたビンの値)に従うように更新されるので、適応的である。更新プロセスは次の通りである。所与の確率状態に対して、更新は、状態インデックスと、LPSまたはMPSのいずれかとして特定される符号化されたシンボルの値とに依存する。更新プロセスの結果として、新しい確率状態が導出され、これは、修正される可能性のあるLPS確率推定と、必要であれば修正されたMPS値とを含む。
各ビンのコーディングの後で、コンテキストの切替えが発生し得る。ビンの値がMPSに等しくなる場合、所与の状態インデックスは単純に1だけインクリメントされる。これは、LPS確率がすでに最小値である(または等価的に、最大のMPS確率に達している)、MPSが状態インデックス62において発生するときを除く、すべての状態にあてはまる。この場合、状態インデックスは、LPSが見えるまで、または最後のビン値が符号化される(最後のビン値という特別な場合に対して特別な終了状態が使用される)まで、固定されたままである。LPSが発生するとき、状態インデックスは、以下の式に示されるように、状態インデックスをある量だけデクリメントすることによって変更される。この規則は一般に、以下の例外とともに、LPSの各々の発生に対して適用される。確率が等しい場合に相当する、インデックスσ=0の状態においてLPSが符号化されたと仮定すると、状態インデックスは固定されたままであるが、MPS値は、LPSおよびMPSの値が交換されるように切り替えられる。すべての他の場合において、どのシンボルが符号化されたとしても、MPS値は変更されない。一般に、ビデオコーダは、以下の式(2)に従って新しい確率状態を導出することができ、この式は、所与のLPS確率poldとそれが更新されたものpnewとの関係を示す。
複雑さを下げるために、ビデオコーダは、いくつかのエントリを各々有する多くても2つのテーブルによりすべての遷移規則が実現され得るように、CABACを実装することができる。一例として、すべての遷移規則は、7ビットの無符号の整数値の128個のエントリを各々有する、多くても2つのテーブルによって実現され得る(たとえば、以下のTable 3(表3)およびTable 4(表4))。別の例として、すべての遷移規則は、6ビットの無符号の整数値の63個のエントリを各々有する、多くても2つのテーブルによって実現され得る(たとえば、HEVCのTable 9〜41)。状態インデックスiを仮定すると、更新の後で、ビデオコーダは、MPS値がコーディングされるときには新しい状態インデックスとしてTransIdxMPS[i]を、またはLPS値がコーディングされるときにはTransIdxLPS[i]を定義し得る。
いくつかの例では、ビデオコーダは、単一のテーブルTransIdxLPSを用いて状態遷移を決定することができ、このテーブルは、所与の状態インデックスσに対して、LPSが観測された場合に新しい更新された状態インデックスTransIdxLPS[σ]を決定する。MPSにより行われる遷移は、1という固定された値だけの、状態インデックスの単純な(飽和した)インクリメントによって得ることができ、更新された状態インデックスmin(σ+1, 62)をもたらす。
上で論じられたように、コンテキストモデリングは正確な確率推定を提供し、これはより高いコーディング効率を実現するのに寄与する要因である。したがって、コンテキストモデリングは適応的なプロセスである。異なるコンテキストモデルが異なるビンのために使用されることが可能であり、コンテキストモデルの確率は以前にコーディングされたビンの値に基づいて更新され得る。同様の分布を有するビンは、同じコンテキストモデルを共有する。各ビンに対するコンテキストモデルは、シンタックス要素のタイプ、シンタックス要素におけるビンの位置(binIdx)、ルーマ/クロマ情報、隣接情報などに基づいて選択され得る。
所与のスライスをコーディングする前に、確率モデルは1つまたは複数の事前に定義された値に基づいて初期化される。たとえば、qpと表記される入力量子化パラメータおよびinitValと表記される事前に定義された値を仮定すると、(状態およびMPSにより表記される)確率モデルの7ビットのエントリは、以下の式(3)に従って導出され得る。
qp = Clip3(0, 51, qp);
slope = ( initVal>>4)*5-45;
offset = ((initVal &15)<<3)-16;
initState= min(max(1, (((slope*qp)>>4)+offset)),126);
MPS = (initState>= 64 );
state index = ((mpState?(initState-64):(63-initState))<<1)+MPS;
導出される状態インデックスは、MPS情報を暗黙的に含む。より具体的には、状態インデックスが偶数値であるとき、MPS値は0に等しい。逆に、状態インデックスが奇数値であるとき、MPS値は1に等しい。「initVal」の値は、8ビットの精度で[0, 255]の範囲にある。事前に定義される値「initVal」はスライス依存である。言い換えると、確率モデルのためのコンテキスト初期化パラメータの3つの集合が使用され、3つの集合のうちの1つが各々、それぞれIスライス、PスライスおよびBスライスの中にある。このようにして、CABACを実行するように構成されるビデオ符号化デバイスは、様々なコーディング状況および/または様々なタイプのビデオコンテンツへのより良好な適合が実現され得るように、これらのスライスタイプのために3つの初期化テーブルの中から選ぶことが可能にされる。
HEVCによれば、1つのP(またはB)スライスがB(またはP)スライスを用いて初期化されることを可能にするために、別のツールが適用され得る。たとえば、このツールは、Bスライスのために記憶されたコンテキスト初期化パラメータの集合を用いて1つのPスライスが初期化されることを可能にするために、適用され得る。逆に、このツールは、Pスライスのために記憶されたコンテキスト初期化パラメータの集合を用いて1つのBスライスが初期化されることを可能にするために、適用され得る。関連するシンタックス要素が以下のTable 5(表5)(HEVCの7.3.6.1項に対応する)に記載されており、関連するセマンティクスおよび復号プロセスが下で、Table 5(表5)の後で説明される。
Table 5(表5)のシンタックス要素のセマンティクスは次のように定義され得る。
1に等しいcabac_init_present_flagは、PPSを参照するスライスヘッダの中にcabac_init_flagが存在することを指定する。0に等しいcabac_init_present_flagは、PPSを参照するスライスヘッダの中にcabac_init_flagが存在しないことを指定する。
cabac_init_flagは、以下で説明される復号プロセスにおいて定義されるように、コンテキスト変数のための初期化プロセスにおいて使用される初期化テーブルを決定するための方法を指定する。cabac_init_flagが存在しないとき、それは0に等しいと推測される。
記述子:
ae(v):コンテキスト適応算術エントロピーコーディングされたシンタックス要素
b(8):ビットストリング(8ビット)の任意のパターンを有するバイト
f(n):左のビットを最初に(左から右へ)書かれるnビットを使用した固定パターンのビットストリング
se(v):左のビットが最初の、符号付きの整数の0次指数ゴロムコーディングされたシンタックス要素
u(n):nビットを使用した符号なしの整数。nがシンタックステーブルにおいて「v」であるとき、ビットの数は、他のシンタックス要素の値に依存する方式で変化する。
ue(v):左のビットが最初の、符号なしの整数の0次指数ゴロムコーディングされたシンタックス要素
HEVCのTable 9-4は、3つの初期化タイプの各々に対して初期化が必要とされる、コンテキストインデックス(ctxIdx)を列挙する。各ctxIdxは、initType変数に対応する変数によって、HEVC Table 9-4において指定される。HEVC Table 9-4はまた、初期化のために必要とされるinitValueの値の各々を含むテーブル番号を列挙する。PスライスタイプおよびBスライスタイプに対して、initTypeの導出は、cabac_init_flagシンタックス要素の値に依存する。ビデオコーダは、以下の疑似コードによって記述される演算を使用して変数initTypeを導出し得る。
if( slice_type = = I )
initType = 0
else if( slice_type = = P )
initType = cabac_init_flag ? 2 : 1
else
initType = cabac_init_flag ? 1 : 2
HEVC準拠ビデオデコーダなどのビデオコーディングデバイスは、様々な段階においてコンテキストモデルの確率状態を更新し得る。所与の確率状態に対して、更新は、状態インデックスと、LPSまたはMPSのいずれかとして特定される符号化されたシンボルの値とに依存する。更新プロセスを実施することによって、ビデオコーディングデバイスは、対応するコンテキストモデルの新しい確率状態を導出する。新しい確率状態は、修正される可能性のあるLPS確率推定、および適用可能であれば、修正されたMPS値から構成され得る。LPS確率のための遷移規則の導出は、所与のLPS確率poldおよびLPS確率が更新されたものpnewとの以下の関係に基づく。
複雑さを下げるために、ビデオコーディングデバイスは、7ビットの無符号の整数値の128個のエントリを各々有する多くても2つのテーブルを使用してすべての遷移規則が実現され得るような方法で、CABACを実施し得る。状態インデックス「i」を仮定すると、ビデオコーディングデバイスは、MPS値がコーディングされるときには更新の後の新しい状態インデックスをTransIdxMPS[i]として、またはLPS値がコーディングされるときにはTransIdxLPS[i]として定義し得る。TransIdxMPSテーブルおよびTransIdxLPSテーブルが以下に示される。
TransIdxMPS[ 128 ] =
{
2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65,
66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81,
82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113,
114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 124, 125, 126, 127
};
TransIdxLPS[ 128 ] =
{
1, 0, 0, 1, 2, 3, 4, 5, 4, 5, 8, 9, 8, 9, 10, 11,
12, 13, 14, 15, 16, 17, 18, 19, 18, 19, 22, 23, 22, 23, 24, 25,
26, 27, 26, 27, 30, 31, 30, 31, 32, 33, 32, 33, 36, 37, 36, 37,
38, 39, 38, 39, 42, 43, 42, 43, 44, 45, 44, 45, 46, 47, 48, 49,
48, 49, 50, 51, 52, 53, 52, 53, 54, 55, 54, 55, 56, 57, 58, 59,
58, 59, 60, 61, 60, 61, 60, 61, 62, 63, 64, 65, 64, 65, 66, 67,
66, 67, 66, 67, 68, 69, 68, 69, 70, 71, 70, 71, 70, 71, 72, 73,
72, 73, 72, 73, 74, 75, 74, 75, 74, 75, 76, 77, 76, 77, 126, 127,
};
算術コーディングは再帰的な間隔の分割に基づく。従来の算術コーディングでは、0から1の初期値を有する範囲が、ビンの確率に基づいて2つの部分間隔へ分割される。符号化されるビットは、バイナリの断片へと変換されるときに2つの部分間隔のうちの1つの選択をもたらす、オフセットを提供する。選択された部分間隔は、復号されるビンの値を示す。それぞれの復号されたビンの後で、ビデオデコーダは、選択された部分間隔に等しくなるように範囲を更新し得る。今度は、ビデオデコーダが、再帰的な手順として間隔の分割を実施するために、間隔分割プロセスを繰り返し得る。範囲およびオフセットはビットの精度が限られているので、ビデオデコーダは、アンダーフローを防ぐために、範囲がある(たとえば、所定の)値を下回る事例において、再正規化を実施し得る。ビデオデコーダは、各ビンが復号された後で再正規化を実行し得る。
ビデオコーディングデバイスは、様々な方法で取得される確率情報に基づいて、算術コーディングを実行し得る。算術コーディングの「通常コーディングモード」によれば、ビデオコーディングデバイスは、推定される確率を使用し得る。通常コーディングモードに従った算術コーディングの場合、ビンストリングはコンテキストコーディングされると言われる。算術コーディングの「バイパスモード」によれば、ビデオコーディングデバイスは、0.5という仮定される等しい確率を使用し得る。バイパスモードに従った算術コーディングの場合、ビンストリングはバイパスコーディングされると言われる。バイパスコーディングされるビンに対して、ビデオコーディングデバイスは、シフトを使用して範囲を部分間隔へ分割し得る。対照的に、ビデオコーディングデバイスは、コンテキストコーディングされるビンの場合、参照テーブルを使用して範囲を分割し得る。HEVCに従った算術コーディングは、H.264/AVCに従った算術コーディングと同じである。HEVCおよびH.264/AVCによれば、ビデオコーディングデバイスは、テーブルベースのバイナリ算術コーディングを利用することができ、算術コーディングの通常コーディングモードのフローが、添付の図面に関して以下の段落においてさらに詳細に説明される。
ビデオエンコーダ20およびおビデオデコーダ30(これらのいずれかまたは両方が一般に、「ビデオコーダ」として本開示の様々な部分において呼ばれる)は、変換係数データのコンテキストモデリングのために、本開示の技法を用いて構成され得る。1つの変換係数がその大きさおよび符号フラグによって表されると仮定すると、バイナリ化の後の大きさは、0からM(Mは正の整数である)のビンインデックスを有するビンストリングによって表記される。本開示の様々なCABACの改善が、ビデオエンコーダ20、ビデオデコーダ30、および/またはそれらの1つまたは複数の構成要素に関して以下で説明される。本開示の様々な技法は、個々に、またはそれらの任意の組合せで、互いとともに、および/または本明細書において説明される任意の他の技法とともに実施され得ることを理解されたい。
本開示は、上で論じられた様々な既存のCABAC技法がいくつかの問題に遭遇し得ることを認識している。たとえば、HEVCにおけるコンテキストモデリング方法は特に、64×64より大きくないCTUに対して設計されている。より大きいCTU(たとえば、128×128、256×256、またはさらに大きいCTU)が使用されるとき、現在のコンテキストモデリング方法を直接再使用することは、非効率であることがあり、かつ/または構文解析の問題をもたらすことがある。別の例として、JCTVC-H0228において提案された変更(これは図12に関して以下でさらに詳細に論じられる)が潜在的にはより良好なコーディング性能を提供し得るが、マルチパスコーディングをシングルパスコーディングにより置き換えることは、並列化に対して有害であり、異なるコンテキストモデル集合の切替えはスループットを低下させる。別の例として、事前に定義された初期化値から導出される初期確率は、スライスタイプに依存する。しかしながら、1つのスライスタイプに対する固定された初期確率は、コーディングされた情報の統計に基づいて適応的ではないことがあり、これはCABACのコーディング性能を制限する。
図4は、改善されたCABAC設計に従ってデータをコーディングするための技法を実施し得るビデオエンコーダ20の例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのうちのいずれかを指し得る。単方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのうちのいずれかを指し得る。
図4に示されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図4の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照ピクチャメモリ64(復号ピクチャバッファ(DPB)とも呼ばれ得る)と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。モード選択ユニット40は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、区分ユニット48とを含む。ビデオブロック再構築のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。ブロック境界をフィルタリングしてブロッキネスアーティファクトを再構築されたビデオから除去するために、デブロッキングフィルタ(図4に示さず)も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器62の出力をフィルタリングする。追加のフィルタ(ループ内またはループ後)も、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために示されないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタリングし得る。
符号化プロセスの間に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間的予測を行うために、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対する受信されたビデオブロックのインター予測符号化を実行する。代替的に、イントラ予測ユニット46は、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の隣接ブロックに対する受信されたビデオブロックのイントラ予測符号化を実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータの各ブロックに対する適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
その上、区分ユニット48は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット48は、最初にフレームまたはスライスをLCUに区分し、レート歪み分析(たとえば、レート歪み最適化)に基づいて、LCUの各々をサブCUに区分し得る。モード選択ユニット40は、LCUをサブCUに区分することを示す4分木データ構造をさらに作成し得る。4分木のリーフノードCUは、1つまたは複数のPUと1つまたは複数のTUとを含み得る。
モード選択ユニット40は、たとえば誤差結果に基づいてイントラ予測モードまたはインター予測モードのうちの一方を選択することができ、得られた予測されたブロックを、残差データを生成するために加算器50に提供し、参照フレームとして使用するための符号化されたブロックを再構築するために加算器62に提供する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット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は、本開示の技法に従ってCABACおよび/または改善されたCABACを実行し得る。コンテキストベースのエントロピーコーディングの場合には、コンテキストは、隣接ブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)へ送信されるか、または、後の送信もしくは取出しのためにアーカイブされ得る。
逆量子化ユニット58および逆変換ユニット60は、ピクセル領域における残差ブロックを再構築するために、それぞれ、逆量子化および逆変換を適用する。具体的には、加算器62は、動き補償ユニット44またはイントラ予測ユニット46によって前に作成された動き補償された予測ブロックに再構築された残差ブロックを加算して、参照ピクチャメモリ64に記憶するための再構築されたビデオブロックを作成する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために、参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
エントロピー符号化ユニット56などのビデオエンコーダ20の様々な構成要素は、本開示の改善されたCABAC技法を実施してコンテキストモデリングを実行し得る。本開示の様々な態様によれば、エントロピー符号化ユニット56は、1つまたは複数の以前の符号化された変換係数のi番目のビンの値を使用して、変換係数のi番目のビンのためのコンテキストモデリングを実行し得る。別の言い方をすると、現在の変換係数のi番目のビンのコンテキストモデリングは、エントロピー符号化ユニット56がすでに符号化した1つまたは複数の変換係数の対応するi番目のビンの値に依存する。i番目のビンのコンテキストモデリングは、変換係数の値の複数のビンのためのコンテキストモデリングが並列に実行されることを可能にするために、以前に符号化された変換係数の値の他のビンの使用を除外し得る。
以前に符号化された変換のi番目のビンの値を使用して現在の変換係数のビンのためのコンテキストモデリングを実行することによって、エントロピー符号化ユニット56は、本開示の技法を実施して、既存のCABACコーダを超える1つまたは複数の潜在的な改善をもたらし得る。そのような利点の例として、エントロピー符号化ユニット56は、本開示の技法を実施することによって、コンテキストモデリング動作の並列化を改善し得る。より具体的には、エントロピー符号化ユニット56は、現在符号化されている変換係数の複数のビンに対して、コンテキストモデリングを並列に実行し得る。たとえば、複数のビンに対応するビン値が以前に符号化された変換係数から利用可能であるとエントロピー符号化ユニット56が決定する場合、エントロピー符号化ユニット56は、現在符号化されている変換係数のビンに対して、コンテキストモデリング動作を少なくとも部分的に並列化し得る。
エントロピー符号化ユニット56は、マルチパスコーディング方式に従って、本開示の並列化されたコンテキストモデリングを実行し得る。より具体的には、マルチパスコーディング方式は、エントロピー符号化ユニット56が別々のスレッドを各々の特定のビンに割り当てる(たとえば、第1のビンに対してスレッド1、第2のビンに対してスレッド2など)、コーディング技法を指す。したがって、マルチパスコーディングによれば、すべてのbin0のインスタンスが、順番にコーディングされるbin1のインスタンスとは無関係に、順番に符号化されることが可能であり、bin0とbin1の両方のインスタンスが、順番に符号化されるbin2のインスタンスとは無関係にコーディングされ、以下同様である。いくつかの例では、エントロピー符号化ユニット56は、単一のブロックの変換単位に関してマルチパスコーディングを実行し得る。その上、通常モードに従って符号化されるビンに対して、エントロピー符号化ユニット56は、いくつかの符号化パスを実行し得る。各パスは、すべての変換係数の単一の対応するビンに関し得る。言い換えると、各パスの間、エントロピー符号化ユニット56は、他のパスに関する情報を利用しない。たとえば、エントロピー符号化ユニット56は、第1のパスにおいて1つの変換単位/CG内のすべての変換係数の(必要であれば)第1のビンを符号化することができる。この例では、第2のパスにおいて、エントロピー符号化ユニット56は、必要であれば、1つの変換単位/CG内のすべての変換係数の第2のビンを符号化することができ、以下同様である。
1つの例示的な使用事例では、エントロピー符号化ユニット56は、以前にコーディングされた隣接する変換係数のbin0の値を使用して現在コーディングされている変換係数のbin0のためのコンテキストモデリングを実行し、以前にコーディングされた隣接する変換係数のbin1の値を使用して現在コーディングされている変換係数のbin1のためのコンテキストモデリングを実行し、以下同様であり得る。上で論じられたような並列化を可能にするために、エントロピー符号化ユニット56は、特定のビンのコンテキストモデリングを実行するときに異なるビンを使用するのを避けるように構成され得る。たとえば、エントロピー符号化ユニット56は、以前にコーディングされた変換係数のいずれのbin0の値も使用することなく、現在の変換係数のbin1をエントロピー符号化するためのコンテキストを決定し得る。ビンの集合が並列にエントロピー符号化される場合、ビンコンテキストを決定するために必要なそれぞれのビンが利用可能であるとき、エントロピー符号化ユニット56は、以前にコーディングされた変換係数のためにそれぞれの利用可能なビン値を使用することができ、エントロピー符号化ユニット56は、現在コーディングされている変換係数の複数のビンのためのコンテキストモデリングを並列に実行することができる。上で説明された使用事例の状況では、bin0とbin1がともに以前にコーディングされた隣接変換係数から入手可能である場合、エントロピー符号化ユニット56は、現在コーディングされている変換係数のためのbin0およびbin1のコンテキストモデリングを並列化することができる。このようにして、エントロピー符号化ユニット56は、本開示の技法を実施して、HEVCにおいて記述されるようなマルチパスコーディングの主義の範囲内でCABACを実行しながら、コンテキストモデリング動作の並列化を可能にして場合によっては利用することによって、現在の変換係数のビンに対するコンテキストの選択を改善することができる。
エントロピー符号化ユニット56は、必ずしもそうであるとは限らないが、すべてのそのようなビンの完全なコンテキストモデリングを並列に実行できることを理解されたい。より具体的には、エントロピー符号化ユニット56は、複数のビンのコンテキストモデリングのいくつかの部分を同時に実行することができる。このようにして、エントロピー符号化ユニット56は、本開示の技法を実施して、マルチコアプロセシング技術および/または複数のプロセッサを活用し、現在コーディングされている変換係数のためのコンテキストモデリング動作を改善することができる。
並列化が可能にされた状態で異なる変換係数の対応するビンを符号化することによって、エントロピー符号化ユニット56は、既存のマルチパスCABAC技法を超える1つまたは複数の利点を提供し得る。たとえば、単一のパスにおいて複数の変換係数の対応するビン(たとえば、それぞれのbin0)をコーディングすることによって、エントロピー符号化ユニット56は、ビンの遷移において、新しいコンテキストモデルを頻繁に記憶して取り出す必要をなくすことができる。代わりに、エントロピー符号化ユニット56は、所与のパスの全体で単一のコンテキストモデルを使用することができ、それは、そのパスが複数の変換係数にわたって、対応するビン(たとえば、それぞれのbin0)を対象とするからである。このようにして、エントロピー符号化ユニット56は、本開示の並列化されたコンテキスト選択技法を実施して、頻繁なコンテキスト切替えにより生じる時間遅延およびリソースの混乱を軽減し、または場合によってはなくすことができる。対照的に、既存のマルチパスコーディングは、第1の変換係数のためにbin0、bin1、bin2などを符号化し、次いで第2の変換係数のためにbin0、bin1、bin2などを符号化することなどが原因で、頻繁なコンテキストモデルの保存と取出しの動作が必要になる。
たとえば、エントロピー符号化ユニット56は、本明細書において説明されるi番目のビンコンテキストモデリング機能のために使用すべき、1つまたは複数の事前に定義されたテンプレートを生成し、またはそうでなければそれを入手し得る。エントロピー符号化ユニット56が現在コーディングされている変換係数のi番目のビンのコンテキストモデリングのために使用し得る、事前に定義されたテンプレートの1つの非限定的な例が、図10に示されている。図10のテンプレート140などの事前に定義されたテンプレートは、8×8の変換ブロックのための対角方向の走査順序を定義し、ここで「L」は最後の有意な走査位置を表し、「x」は現在の走査位置を表し、「xi」はローカルテンプレート140によってカバーされる近隣を表す。xiに関して、「i」という値は0から4の範囲にあり、範囲の制約はi・[0, 4]として表される。本開示の1つまたは複数の態様によれば、エントロピー符号化ユニット56は、現在符号化されている変換係数の対応するi番目のビンのコンテキストモデリングのために、ローカルテンプレート140の中に位置する変換係数のi番目のビンを使用し得る。いくつかの実装形態によれば、エントロピー符号化ユニット56は、複数のテンプレートを使用して、本開示の並列化されたビンコンテキストモデリングを実行し得る。一例では、テンプレートのサイズおよび/または形状は、(i)変換単位のサイズ、または(ii)モード、または(iii)現在の変換単位もしくは係数グループ(CG)内の現在の変換係数の位置、または(iv)ルーマ成分および/もしくはクロマ成分情報などの、色成分情報という基準のうちの1つまたは複数に依存する。
1つまたは複数の事前に定義されたテンプレートを使用してビン値のための以前にコーディングされたTUを横断することによって、エントロピー符号化ユニット56は、本開示の技法を実施して、既存のCABAC技法を超える1つまたは複数の改善をもたらし得る。たとえば、図10のローカルテンプレート140などのTU横断テンプレートを使用することによって、エントロピー符号化ユニット56は、異なるコーディングパスに関して横断方式を別々に決定する必要をなくすことができる。したがって、本開示のテンプレートベースの並列化されたコンテキスト選択技法を実施することによって、エントロピー符号化ユニット56は、コーディング精度を維持しながら、ビンのコーディングに関してスループットを向上させることができる。
別の例示的な実装形態によれば、エントロピー符号化ユニット56は、現在コーディングされている変換係数の最初の「K」個のビンだけに、本開示の並列化されたコンテキストモデリング技法を適用することがあり、ここで「K」はMより小さく、Mは利用可能なビンインデックスの上限を表し、Mは0から開始する。エントロピー符号化ユニット56は、別のコンテキストモデリング技法を使用して、またはバイパスモードに従って、残りの(M+1-K)個のビンを符号化し得る。
別の例示的な実装形態によれば、エントロピー符号化ユニット56は、現在符号化されている変換係数の前の、現在の変換単位またはCG内の符号化順序において連続する「N」個の変換係数として、以前にコーディングされた変換係数の世界を定義し得る。代替的に、エントロピー符号化ユニット56は、Nを可変であるものとして決定し得る。一例では、エントロピー符号化ユニット56は、現在の変換単位の中での現在符号化されている変換係数の相対的な位置に応じて、Nの値を決定し得る。別の例では、エントロピー符号化ユニット56は、変換単位のサイズに応じてNの値を決定し得る。
別の実装形態では、エントロピー符号化ユニット56は、現在の変換単位またはCG内で現在の位置の近隣に位置する変換係数として、以前に符号化された変換係数の世界を定義し得る。一例では、現在の位置の近隣は、現在の位置に直接隣り合う位置、または、現在の位置に直接隣り合うか現在の位置から離れているかのいずれかの位置に制約される。別の例では、近隣は、これらの位置を含み得るが、1つまたは複数の空間的に隣接する変換単位の中の位置を含むように拡大し得る。
本開示の様々な態様によれば、エントロピー符号化ユニット56は、1つまたは複数の以前にコーディングされた変換係数と関連付けられる値の関数として、ビンのコンテキストインデックスを定義し得る。たとえば、エントロピー符号化ユニット56は、以前にコーディングされた変換係数のすべてのi番目のビン値の合計を生む関数を使用し得る。より具体的には、この例では、エントロピー符号化ユニット56は、TU/CGのすべての以前に符号化された変換係数の利用可能なi番目のビン値の値の加算を実行し得る。そして、エントロピー符号化ユニット56は、現在コーディングされている変換係数のi番目のビンのためのコンテキストモデリングの間に、コンテキストインデックス(CtIdx)として得られた合計を使用し得る。別の例では、エントロピー符号化ユニット56はカットオフ値を定義し得る。この例では、関数の出力が事前に定義されたカットオフ値を超えるとき、エントロピー符号化ユニット56は、現在コーディングされているビンに関して同じコンテキストを使用し得る。いくつかの例では、エントロピー符号化ユニット56は、カットオフ値がビンインデックス/変換単位のサイズ/コーディングモード/1つの変換単位内での変換係数の位置に基づく(またはそれらに依存すべきである)ことを決定し得る。
いくつかの例では、エントロピー符号化ユニット56は、これらのビンが同じコンテキストモデルを共有するように、異なるパスにおいてコーディングされる対応するビンを符号化し得る。一例では、エントロピー符号化ユニット56は、異なるパスにおけるビンのためのコンテキストインデックス導出方法、たとえばコンテキストインデックスを計算するための関数が異なると、決定し得る。一例によれば、エントロピー符号化ユニット56は、異なるパスにおけるビンのためのコンテキストインデックス導出方法、たとえばコンテキストインデックスを計算するための関数が同じであり得ると、決定し得る。
本開示のいくつかの態様によれば、エントロピー符号化ユニット56は、異なるサイズの変換単位において、同じパスに対してはコンテキストインデックスの導出規則が変更されないままにすることができる。しかしながら、エントロピー符号化ユニット56は、オフセットをコンテキストインデックスに適用して、現在コーディングされているビンのためのコンテキストモデリングを実行することができる。たとえば、エントロピー符号化ユニット56は、2つの異なる変換サイズがコンテキストモデルの2つの集合を有すると決定し得る。そして、エントロピー符号化ユニット56は、1つのそのような集合の中のコンテキストモデルの数として、オフセットを定義し得る。たとえば、TUサイズが事前に定義された次元M×Mの正方形より小さいとエントロピー符号化ユニット56が決定する場合、エントロピー符号化ユニット56は、各々のそのようなTU(M×Mより小さい)のサイズがコンテキストモデルの固有のそれぞれの集合を有すると決定し得る。逆に、エントロピー符号化ユニット56は、M×M以上のサイズを有するすべてのTUがコンテキストモデルの同じ集合を共有すると決定し得る。
様々な使用事例の状況において、エントロピー符号化ユニット56は、Mの値を16に設定し得る。より具体的には、これらの例では、現在コーディングされているTUのサイズが16×16の正方形より小さいとエントロピー符号化ユニット56が決定する場合、エントロピー符号化ユニット56は、現在コーディングされているTUがTUの特定のサイズに対応するコンテキストモデルの集合と関連付けられると決定し得る。逆に、現在コーディングされているTUが16×16以上のサイズを有するとエントロピー符号化ユニットが決定する場合、エントロピー符号化ユニット56は、現在コーディングされているTUが、16×16以上のサイズを有するすべての他のTUとコンテキストモデルの同じ集合を共有すると決定し得る。いくつかの例では、エントロピー符号化ユニット56は、TUサイズベースのコンテキストの選択を、ルーマブロックにのみ適用し得る。
いくつかの例によれば、残りのビンをコーディングするために使用されるRiceパラメータは、変換サイズに依存する。代わりに、または加えて、Riceパラメータはコーディングモードに依存し得る。一例では、coeff_abs_level_remainingのためにゴロムライス符号を使用する代わりに、エントロピー符号化ユニット56は他のバイナリ化技法を使用し得る。代わりに、または加えて、2つ以上のバイナリ化方法が、coeff_abs_level_remainingシンタックス要素をコーディングするために適用され得る。一例では、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、コーディングモードに依存する。代替的に、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、1つのTU内での相対的な位置に依存し得る。代わりに、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、走査順序における最初のコーディング/復号される変換係数からの距離に依存し得る。いくつかの事例では、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、変換単位に対する相対的なコーディンググループの位置に依存する。
本開示のいくつかの態様によれば、エントロピー符号化ユニット56は、変換サイズに基づいて係数グループ(CG)サイズを決定し得る。言い換えると、これらの態様によれば、CGサイズは変換サイズに依存する。代わりに、または加えて、エントロピー符号化ユニット56は、コーディングモードに基づいてCGサイズを決定し得る。これらの例では、エントロピー符号化ユニット56は、変換サイズおよび/またはコーディングモードの一方または両方に依存するものとして、CGサイズを決定し得る。代わりに、または加えて、エントロピー符号化ユニット56は、変換行列に基づいてCGサイズを決定し得る。
本開示のいくつかの態様によれば、エントロピー符号化ユニット56は、変換バイパスモード(「変換スキップモード」とも呼ばれる)を使用して符号化されるブロックにも、並列化されたコンテキストモデリング技法を適用し得る。変換バイパスモードは、無損失のコーディング出力を与えるためにビデオエンコーダ20が符号化の変換と量子化の動作をスキップし得る、コーディングモードを指す。したがって、本開示のいくつかの態様によれば、エントロピー符号化ユニット56は、無損失のコーディングの事例において利益をもたらす可能性を与えるように、並列化されたコンテキスト選択技法を拡大し得る。
本開示の様々な変換係数コンテキストモデリング技法の例示的な詳細が、以下でさらに詳細に論じられる。マルチパスコーディングに従ったコンテキストモデリングの一例が以下で説明される。この例によれば、エントロピー符号化ユニット56は、HEVCにおいて設計されるようなコーディング要素およびコーディング順序(マルチパスコーディング、およびCGベース)を適用し得る。加えて、エントロピー符号化ユニット56は、変換係数の大きさが変わらないままであるように保ちながら、バイナリ化技法を適用し得る。しかしながら、エントロピー符号化ユニット56は、変換係数の大きさをコーディングするためのコンテキストインデックスおよびRiceパラメータの計算方法を修正し得る。
bin0(有意性フラグ)に対するコンテキストインデックスの計算は、テンプレートにおける0ではない係数(すなわち、係数の大きさが0より大きい)の数、現在のTU内での現在の係数の位置、ルーマ成分に対するTUサイズ、および色成分という情報に依存し得る。色成分の依存性に関して、ルーマとクロマは別々に考慮される。加えて、ルーマ成分に対するTUサイズを考慮する際、コンテキストインデックスの計算はルーマに対するTUサイズとは無関係である。ルーマ成分のTUサイズは、3つの集合、すなわち、4×4のTU、8×8のTU、16×16以上のTUを含み得る。
bin1およびbin2(Grt than 1、Grt than 2)に対して、コンテキストインデックスの計算は、(bin1に対して)1より大きいテンプレート中のabsLevelsの数および(bin2に対して)2より大きいテンプレート中のabsLevelsの数、現在のTU内での現在の係数の位置、ならびに色成分という情報に依存し得る。Riceパラメータの導出プロセスは、バイパスコーディング情報に、およびsum_absolute_levelMinus1シンタックス要素の値に依存する。
一例では、エントロピー符号化ユニット56は、係数の大きさがkより大きくなるように、テンプレートの中の係数の数を返すように関数sum_template(k)を定義し得る。sum_template(k)関数の例は次の通りである。
加えて、この例では、エントロピー符号化ユニット56は、以下のように、位置情報を扱うように関数function f(x, y, n, t)を定義し、成分情報を扱うように別の関数δk(u, v)を定義し得る。
図10は、本明細書において説明されるコンテキストモデリング技法に関してエントロピー復号ユニット70および/またはエントロピー符号化ユニット56が使用し得るテンプレート(ローカルテンプレート140)の一例を示す。現在の変換係数は「X」としてマークされ、5つの空間的な近隣は「Xi」としてマークされる(iは0から4の整数を表す)。以下の条件のいずれか1つが満たされる場合、エントロピー符号化ユニット56は、コンテキストインデックスの導出プロセスにおいて利用不可能であり使用されないものとしてXiをマークし得る。
・ Xiの位置および現在の変換係数Xは同じ変換単位の中に位置せず、または、
・ Xiの位置はピクチャの水平方向もしくは垂直方向の境界の外側に位置し、または、
・ 変換係数Xiはまだコーディングされていない。マルチパスコーディングの場合、同じコーディングパスにおけるビンがコーディングされるときはいつでも、それらのビンがコンテキストインデックスの導出プロセスにおいて使用され得る。したがって、復号の観点からは、1つの変換係数を完全に復号することは必要ではない。
代替的に、エントロピー符号化ユニット56は、隣接する変換単位からの情報を含み得る1つまたは複数の他のテンプレートを適用し得る。様々な例では、隣接するTUは空間的な近隣または時間的な近隣であり得る。本明細書において説明されるコンテキストモデリング技法の1つまたは複数によれば、コンテキストインデックスの計算は以下の段落において説明されるように定義され得る。
bin0に関して、エントロピー符号化ユニット56は、コンテキストインデックスを次のように導出し得る。
c0 = min(sum_template(0), 5)+f(x, y, 6, 2)+δk(f(x, y, 6, 5), cIdx) + offset(cIdx, width)
c0 = c0 + offset(cIdx, width)
ここで、
一例では、c0の範囲に基づいて、ルーマコンテキストの1つの集合は、NumberLumaCtxOnesetの値に等しい数のコンテキストモデルを含み得る。たとえば、ルーマコンテキストの集合は18個のコンテキストモデルを含み得る。ルーマbin0をコーディングするための異なる変換サイズ(変換の幅は「w」によって表記される)に関して、エントロピー符号化ユニット56は、各変換サイズに対して異なる集合を選択し得る。加えて、クロマコンテキストおよびルーマコンテキストは、コーディング性能をさらに改善するために分離される。YCbCr入力に対して、3つの色成分、すなわちY、Cb、およびCrはそれぞれ、0、1、および2に等しい成分インデックスvを用いて表される。
これらの例では、エントロピー符号化ユニット56は、bin1のためのコンテキストインデックスを次のように導出し得る。
c1 = min(sum_template(1), 4) + N
c1 = c1 +δk(f(x, y, 5, 3), cIdx) +δk(f(x, y, 5, 10), cIdx)
加えて、これらの例では、エントロピー符号化ユニット56は、bin2のためのコンテキストインデックスを次のように導出し得る。
c2 = min(sum_template(2), 4) + N
c2 = c2 +δk(f(x, y, 5, 3), cIdx) +δk(f(x, y, 5, 10), cIdx)
一例では、Nは0に等しい。別の例では、Nは1に等しい。代わりに、または加えて、Nが1に等しいとき、エントロピー符号化ユニット56は、0に等しいコンテキストインデックスc1またはc2を用いて第1のbin1またはbin2をコーディングし得る。この例では、エントロピー符号化ユニット56は、上の式に従ってbin1およびbin2の他のインスタンスをコーディングし得る。
一例では、エントロピー符号化ユニット56は、コンテキストモデルの同じ集合を有するが異なるインデックスを有する、bin1およびbin2を符号化し得る。代わりに、bin1およびbin2はコンテキストモデルの2つの集合を用いてコーディングされ、それらの間には依存性がない。残りのビンに対して、エントロピー符号化ユニット56は、HEVCにおいて展開される設計またはJCTVC-H0228における設計を適用し得る。様々な例において、エントロピー符号化ユニット56は、上で説明された様々な関数を構築する際に異なる定数値を使用し得る。
本開示の追加の態様は、コンテキスト初期化の改善を対象とする。本開示のコンテキスト初期化の改善は、上で説明された並列化されたコンテキスト選択技法とは独立に実施されることがあり、または、上で説明された並列化されたコンテキスト選択技法の任意の1つまたは複数と組み合わせて実施されることがある。本開示のコンテキスト初期化技法の1つまたは複数は、以前に符号化された情報からコンテキスト情報を再使用することを対象とする。たとえば、エントロピー符号化ユニット56は、現在のピクチャまたは以前に符号化されたピクチャに属し得る、以前に符号化されたスライスからのステータスをコピーすることによって、スライスのためのコンテキスト情報を継承し、またはそうでなければ導出することができる。本開示の継承ベースのコンテキスト初期化技法による様々な例では、「ステータス」という用語は、状態情報と優勢シンボル(MPS)値との組合せを指す。以下の説明では、「スライス」という用語は「タイル」という用語と交換可能に使用され得る。
以前に符号化されたスライスからコンテキスト初期化情報を継承することによって、エントロピー符号化ユニット56は、本開示の技法を実施して、既存のCABACコンテキスト初期化技法と比較して改善された精度を提供することができる。たとえば、既存のCABACコンテキスト初期化技法は、テーブルからコンテキストステータス情報を取得することに依存する。しかしながら、テーブルは静的な情報を使用して形成される。しかしながら、本開示の継承ベースのコンテキスト初期化技法によれば、エントロピー符号化ユニットは、同じスライスタイプである、かつ/または現在符号化されているスライスと同じ量子化パラメータ(QP)を有する、以前に符号化されたスライスからコンテキスト初期化情報を引き出すことができる。このようにして、エントロピー符号化ユニット56は、本開示の技法を実施して、現在のスライスための使用されるコンテキスト初期化情報の精度を改善することができる。
いくつかの実装形態によれば、エントロピー符号化ユニット56は、コンテキスト初期化情報をそこから継承すべきスライスとして、以前に符号化されたスライスの中心LCUを特定し得る。様々な例において、エントロピー符号化ユニット56は、複数の対応する以前に符号化されたスライスから、現在のピクチャの現在のスライスのためのコンテキスト初期化を継承し得る。一例では、エントロピー符号化ユニット56は、本開示のコンテキスト初期化技法に従って符号化される複数のスライスのすべてのためのコンテキスト初期化情報をそこから継承すべき、以前に符号化されたピクチャの同じブロック(すなわち、中心LCU)を使用し得る。別の例では、エントロピー符号化ユニット56は、以前に符号化されたピクチャの対応するスライスの各々からのそれぞれの中心LCUから、複数のスライスの各々のためのコンテキスト初期化情報を継承し得る。
たとえば、以前に符号化されたピクチャの中心LCUを符号化した後で、エントロピー符号化ユニット56は、スライスコンテキスト初期化に関してステータス情報のすべてを記憶し得る。次いで、エントロピー符号化ユニット56は、コピーされたステータス情報にアクセスしてそれを読み取り、現在符号化されているピクチャの1つまたは複数のスライスのためのコンテキストを初期化するためにそのステータス情報を使用し得る。以前に符号化されたピクチャからのステータス情報を使用して現在のピクチャのスライスのためのコンテキスト初期化を実行することによって、エントロピー符号化ユニット56は、コンテキスト初期化が目的の、静的な情報の固定されたテーブルへの依存を減らすことができる。たとえば、固定されたテーブルを使用して最初のピクチャのスライスならびに任意のイントラコーディングされたピクチャのためのコンテキストを初期化した後で、エントロピー符号化ユニット56は、続いて符号化されるインターコーディングされたピクチャのためのコンテキスト初期化を実行し得る。エントロピー符号化ユニット56は、Pスライスおよび/またはBスライスに関して、本開示の継承ベースのコンテキスト初期化技法を実施し得る。
本開示のコンテキスト初期化技法の追加の例示的な詳細が以下で説明される。エントロピー符号化ユニット56は、追加で、または代替的に、以下で論じられるような、コンテキスト初期化のための本開示による技法を実行するように構成され得る。エントロピー符号化ユニット56は、本開示のコンテキスト初期化技法を実施して、現在のスライスをコーディングするための初期化されたコンテキスト情報として以前に符号化されたピクチャの中に位置する1つのブロックを符号化した後のコンテキスト情報を継承し得る。エントロピー符号化ユニット56は、Pスライスおよび/またはBスライスに継承ベースのコンテキスト初期化技法を適用し得る。加えて、上で言及された「1つのブロック」の位置は、事前に定義されており、1つの全体のシーケンスに対して固定されている。たとえば、最大コーディング単位サイズ(LCU)は「N×N」によって表記され、ピクチャの幅は「W」によって表記され、ピクチャの高さは「H」によって表記される。この例では、「PicWidthInCtbsY」によって表記される、1つのLCU行の中のLCUの数は、天井関数、すなわちCeil(W÷N)の出力に等しい。加えて、この例では、「PicHeightInCtbsY」によって表記されるLCU行の数はCeil(H÷N)に等しく、ここで天井関数Ceil(x)はx以上の最小の整数を表す。
いくつかの例によれば、位置は、以前にコーディングされたピクチャの中の第1のスライスの中心LCUとして定義される。numLCUinSliceが第1のスライスの中のLCUの数を表すと仮定すると、位置はTargetCUAddr = numLCUinSlice/2として定義される。一例では、位置はTargetCUAddr = (PicWidthInCtbsY* PicHeightInCtbsY)/2 + PicWidthInCtbsY /2として定義される。さらに、TargetCUAddrが(PicWidthInCtbsY* PicHeightInCtbsY)以上である(たとえば、PicHeightInCtbsYが1に等しい)とき、TargetCUAddrは、(PicWidthInCtbsY* PicHeightInCtbsY - 1)にリセットされ、これは最後のLCUに対応する。一例では、位置は、以前にコーディングされたピクチャの最後のLCU、または1つのフレーム内の中心LCU(すなわち、PicWidthInCtbsY* PicHeightInCtbsY/2)、または中心のLCU行の最後のLCU(すなわち、PicWidthInCtbsY* (PicHeightInCtbsY/2) - 1)、またはk番目のLCU行の最後のLCU(たとえば、kは1に等しい)として定義される。1つの例によれば、位置は、以前に符号化されたピクチャの中の第1のスライスの最後のLCUとして定義される。本開示のコンテキスト初期化技法のいくつかの実装形態によれば、分解能が異なると、コーディングブロックの位置の定義が異なり得る。
いくつかの例では、「1つのブロック」の位置は、シーケンスパラメータセット(SPS)またはピクチャパラメータセット(PPS)などのパラメータセットにおいてシグナリングされる。SPSおよび/またはPPSなどのパラメータセットは、現在のピクチャのスライスに関して帯域外でシグナリングされ得る。いくつかの例では、「1つのブロック」の位置は、スライスヘッダにおいてシグナリングされ得る。スライスヘッダは、対応するスライスに関して帯域内でシグナリングされ得る。これらの例および他の例では、参照ピクチャインデックス、対応するピクチャ順序カウントの差分(またはデルタPOC)などの、以前に符号化されたピクチャの指示が、パラメータセットまたはスライスヘッダにおいてシグナリングされ得る。
いくつかの例では、「以前にコーディングされたピクチャ」は、現在のピクチャのすぐ前(直前)に符号化/復号されたピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、以前のピクチャの中の第1のスライスが現在のスライスと同じスライスタイプを有するように、現在のピクチャの前に符号化または復号された最後のピクチャであるピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、現在のピクチャの前の符号化/復号されたピクチャであるピクチャとして定義され、以前のピクチャの中の第1のスライスは、現在のスライスと同じ初期量子化パラメータを有する。いくつかの例によれば、「以前にコーディングされたピクチャ」は、現在のスライスおよび/または上記の同じ初期量子化パラメータと、同じスライスタイプを有する、または同じスライスタイプと量子化パラメータの両方を有する、または同じスライスタイプと時間レイヤの両方を有する、以前にコーディングされたスライスを含むピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、ピクチャバッファ(コーディングピクチャバッファまたは復号ピクチャバッファなど)の中に存在するピクチャとして定義され、参照ピクチャとして現在のピクチャのために使用され得る。これらの例によれば、HEVCベースのプラットフォームのように、以前のスライスは、参照ピクチャセット(RPS)の中のピクチャに、またはRefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetLtCurrという部分集合のうちの1つの中のピクチャに、属さなければならない。
本開示のコンテキスト初期化技法のいくつかの実装形態によれば、表示順序においてあるイントラコーディングされたピクチャの後でコーディングされるピクチャのすべてが同じスライスタイプおよび同じ初期量子化パラメータを有しない場合、コンテキスト情報の継承は無効にされ得る。この場合、従来の初期化方法が適用され、たとえば、エントロピー符号化ユニット56は固定されたテーブルを使用して、そのテーブルから初期ステータス情報を引き出し得る。いくつかの実装形態によれば、エントロピー符号化ユニット56は、本開示の継承ベースのコンテキスト初期化技法を特定のコンテキストモデルに適用し、他のコンテキストモデルには適用しないことがある。加えて、または代わりに、「1つのブロック」の位置は、異なるコンテキストモデルに対しては異なり得る。上に列挙された様々な実装の選択肢は、本開示のコンテキスト初期化技法に従って、個別に、または様々な組合せで実装され得ることを理解されたい。
本開示のコンテキスト初期化技法のいくつかの例では、cabac_init_present_flagが有効であるとエントロピー符号化ユニット56が決定する場合、エントロピー符号化ユニット56は、「以前に符号化されたピクチャ」に含まれるスライスが現在符号化されているスライスと同じタイプを有するべきであると決定し得る。別の言い方をすると、この例では、cabac_init_present_flagが有効である場合、以前に符号化されたピクチャの定義は一致するスライスタイプに依存する。加えて、復号の観点から、シグナリングされるcabac_init_present_flagは、この実装形態によれば考慮されない。いくつかの事例では、代わりに、エントロピー符号化ユニット56はまず、cabac_init_present_flagおよび「以前に符号化されたピクチャ」の選択に基づいて、現在のスライスのスライスタイプを修正し得る。
本開示のコンテキスト初期化技法の追加の例示的な詳細が以下で説明される。いくつかの実装形態によれば、エントロピー符号化ユニット56は、イントラランダムアクセスピクチャ(IRAP)に関して本開示の継承ベースのコンテキスト初期化技法を適用しないことがある。たとえば、エントロピー符号化ユニット56は、3つのタイプのIRAP、すなわち、瞬時復号リフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、およびブロークンリンクアクセス(BLA)ピクチャのいずれかに関して、継承ベースのコンテキスト初期化技法を実施しないことがある。
以前にコーディングされた情報に基づく継承ベースのコンテキスト初期化の一例では、エントロピー符号化ユニット56は、1つのスライスを有する1つのピクチャを符号化し得る。この例では、エントロピー符号化ユニット56は、以下の規則のうちの1つまたは複数を適用して、コンテキストモデルの初期状態を導出し得る。第1の規則は、以前に符号化されたピクチャのスライスが現在符号化されているスライスのスライスタイプと同じスライスタイプを有するというものである。代わりに、または加えて、初期スライス量子化パラメータ(QP)は、現在符号化されているスライスをコーディングするために使用されるスライスQPと同じである。
本開示のいくつかの態様によれば、エントロピー符号化ユニット56は、異なるQPが現在のスライスおよび予測子スライスのために使用されるとき、以前に符号化されたスライスからコンテキスト初期化情報を継承し得る。これらの例では、エントロピー符号化ユニット56は、現在のスライスを符号化するためのコンテキスト初期化情報を使用する前に、コンテキスト状態に関してマッピングプロセスを適用し得る。たとえば、エントロピー符号化ユニット56は、1つまたは複数の初期化関数(たとえば、HEVCにおいて指定される初期化関数)ならびに2つのQPおよびコンテキストを利用して、ある状態を別の状態に変換し得る。いくつかの事例では、エントロピー符号化ユニット56は、以前にコーディングされたピクチャの中の事前に定義されたアドレスを有する1つのブロックを符号化した後で状態情報(たとえば、状態)を記録し、現在符号化されているスライスのための初期状態情報としてその記録された状態情報を使用し得る。
一例では、「1つのブロック」は最大コーディング単位(LCU)を表す。たとえば、LCUサイズ(次元)は「N×N」によって、ピクチャの幅は「W」によって、ピクチャの高さは「H」によって表記され得る。1つのLCU行の中のLCUの数は、PicWInCtbsYによって表記されることが可能であり、天井関数Ceil(W÷N)の出力に等しい。PicHInCtbsYにより表記される、ピクチャの中のLCU行の数は、天井関数Ceil(H÷N)の出力に等しい。一般的に説明すると、関数Ceil(x)はx以上の最小の整数を返す。加えて、LCUの単位で測られるピクチャの幅、およびLCUの単位で測られるピクチャの高さは、それぞれ、上で説明された天井関数を使用して得られるPicWInCtbsYおよびPicHInCtbsYの値によって表される。一例では、LCUのアドレスは以下の式に従って定義される。
TargetCUAddr = (Pic WInCtbsY * PicHInCtbs Y)/2 + PicWInCtbs Y/2
さらに、TargetCUAddrが(PicWInCtbsY* PicHInCtbsY)の値以上であるとき、エントロピー符号化ユニット56は、TargetCUAddrを(PicWInCtbsY* PicHInCtbsY - 1)の値にリセットし得る。たとえば、TargetCUAddrは、PicHInCtbsYが1に等しい事例では、上記の値に等しいことがあり、またはそれを超えることがある。加えて、(PicWInCtbsY* PicHInCtbsY - 1)の値は、1つのピクチャの中の最後のLCUに対応する。
いくつかの事例では、さらに、エントロピー符号化ユニット56は、表示順序において新しいイントラコーディングされたピクチャの後の最初の1つまたは複数のピクチャに対して、上で説明された規則ベースのコンテキスト初期化技法を適用しないことがある。エントロピー符号化ユニット56が規則ベースのコンテキスト初期化を適用しない可能性がある例は、エントロピー符号化ユニット56が初めて新しいスライスタイプまたは新しいQPに遭遇した(たとえば、新しいスライスタイプまたは新しいQPが出現した)場合である。たとえば、エントロピー符号化ユニット56は、ランダムアクセスに関する問題を軽減し、または場合によっては回避し得る。本開示の例が図9に示されており、図9において、28から35のピクチャ順序カウント(POC)値を有するピクチャのコーディング順序(およびしたがって復号順序)は、32、28、…30、29、31、40、36、34、33、35である。
表示順序に関して、POC値が40に等しいピクチャは、POC値が32に等しいIピクチャの後で復号される最初のピクチャである。POC値が24であるピクチャはPOCが40に等しいピクチャと同じQPを有し、両方が同じスライスタイプを共有するが、エントロピー符号化ユニット56は、POCが24に等しいピクチャのコーディングされた情報を使用して、POC値が40に等しいピクチャを予測しないことがある。同様に、エントロピー符号化ユニット56は、POCが31に等しいピクチャのコーディングされた情報を使用して、POCが33に等しいピクチャを予測しないことがある。しかしながら、エントロピー符号化ユニット56は、POCが33に等しいピクチャのコーディングされた情報を使用して、POCが35に等しいピクチャを予測することがあり、それは、両方のピクチャがIピクチャよりも(表示順序において)後にあるからである。
以前にコーディングされたピクチャからの予測が許可されない、無効にされている、またはエントロピー符号化ユニット56に対して別様に利用可能ではない事例では、エントロピー符号化ユニット56は、HEVCにおいて定義されるようにコンテキスト初期化技法を適用し得る。上で説明されたように、図4のビデオエンコーダ20は、改善されたCABACのために本開示の様々な技法のいずれをも、単独で、または任意の組合せで実行するように構成され得るビデオエンコーダの例を表す。いくつかの例では、ビデオエンコーダ20は、変換単位を符号化するためのコーディングモードを選択するように構成される。いくつかの例では、ビデオエンコーダ20は、ビデオデータの少なくとも一部分を捕捉するように構成されるカメラを含む、デバイスを含むことがあり、デバイスであることがあり、またはデバイスの一部であることがある。いくつかの例では、ビデオエンコーダ20は、カメラから捕捉されたビデオデータを受け取るように構成されるメモリデバイスを含み得る。
図5は、本開示の技法に従ってCABACを実行するように構成され得る例示的なエントロピー符号化ユニット56のブロック図である。シンタックス要素118は、エントロピー符号化ユニット56に入力される。シンタックス要素がすでにバイナリ値のシンタックス要素(たとえば、0および1という値のみを有するフラグまたは他のシンタックス要素)である場合、バイナリ化のステップはスキップされ得る。シンタックス要素が非バイナリ値のシンタックス要素(たとえば、1または0以外の値を有し得るシンタックス要素)である場合、非バイナリ値のシンタックス要素はバイナライザ120によってバイナリ化される。バイナライザ120は、非バイナリ値のシンタックス要素の、バイナリの判断の列へのマッピングを実行する。これらのバイナリの判断は、しばしば「ビン」と呼ばれる。たとえば、変換係数レベルでは、レベルの値は連続的なビンへと分解されることがあり、各ビンは、係数レベルの絶対値が何らかの値より大きいかどうかを示す。たとえば、ビン0(有意性フラグと呼ばれることがある)は、変換係数レベルの絶対値が0より大きいかどうかを示す。ビン1は、変換係数レベルの絶対値が1より大きいかどうかを示し、以下同様である。各々の非バイナリ値のシンタックス要素に対して、固有のマッピングが開発され得る。
バイナライザ120によって作成される各ビンは、エントロピー符号化ユニット56のバイナリ算術コーディング側に与えられる。すなわち、非バイナリ値のシンタックス要素の所定の集合に対して、各ビンのタイプ(たとえば、ビン0)は、次のビンのタイプ(たとえば、ビン1)の前にコーディングされる。コーディングは、通常モードとバイパスモードのいずれかで実行され得る。バイパスモードでは、バイパスコーディングエンジン126は、固定された確率モデルを使用して、たとえばゴロムライスコーディングまたは指数ゴロムコーディングを使用して、算術コーディングを実行する。バイパスモードは一般に、より予測可能なシンタックス要素のために使用される。
通常モードにおけるコーディングは、CABACを実行することを伴う。通常モードのCABACは、以前に符号化されたビンの値を与えられるとビンの値の確率が予測可能である場合に、ビン値をコーディングするためのものである。ビンがLPSである確率は、コンテキストモデラ122によって決定される。コンテキストモデラ122は、ビン値およびコンテキストモデルの確率状態(たとえば、LPSの値およびLPSが発生する確率を含む、確率状態σ)を出力する。コンテキストモデルは、一連のビンに対する初期コンテキストモデルであることがあり、または、以前にコーディングされたビンのコーディングされた値に基づいて決定されることがある。上で説明されたように、コンテキストモデラ122は、受信されたビンがMPSまたはLPSであったかどうかに基づいて、状態を更新し得る。コンテキストモデルおよび確率状態σがコンテキストモデラ122によって決定された後で、通常コーディングエンジン124がビン値に対してBACを実行する。
コンテキストモデラ122は、本開示の技法を実施して、並列化された方式でコンテキストモデリングを実行し得る。本開示の様々な態様によれば、コンテキストモデラ122は、1つまたは複数の以前の符号化された変換係数のi番目のビンの値を使用して、変換係数のi番目のビンのためのコンテキストモデリングを実行し得る。このようにして、現在の変換係数のi番目のビンのコンテキストモデリングは、コンテキストモデラ122がすでにそれに対するコンテキストを選択した1つまたは複数の変換係数の対応するi番目のビンの値に依存する。
以前に符号化された変換のi番目のビンの値を使用して現在の変換係数のビンのためのコンテキストモデリングを実行することによって、コンテキストモデラ122は、本開示の技法を実施して、既存のCABACコーディングデバイスを超える1つまたは複数の潜在的な改善をもたらし得る。そのような利点の例として、コンテキストモデラ122は、本開示の技法を実施することによって、コンテキストモデリング動作の並列化を改善し得る。たとえば、コンテキストモデラ122は、現在符号化されている変換係数の複数のビンに対して、コンテキストモデリングを並列に実行し得る。一例として、複数のビンに対応するビン値が以前に符号化された変換係数から利用可能であるとコンテキストモデラ122が決定する場合、コンテキストモデラ122は、現在符号化されている変換係数のビンに対して、コンテキストモデリング動作を少なくとも部分的に並列化し得る。
コンテキストモデラ122は、マルチパスコーディング方式に従って、本開示の並列化されたコンテキストモデリングを実行し得る。より具体的には、マルチパスコーディング方式は、エントロピー符号化ユニット56が別々のスレッドを各々の特定のビンに割り当てる(たとえば、第1のビンに対してスレッド1、第2のビンに対してスレッド2など)、コーディング技法を指す。したがって、マルチパスコーディングによれば、すべてのbin0のインスタンスが、順番にコーディングされるbin1のインスタンスとは無関係に、順番に符号化されることが可能であり、bin0とbin1の両方のインスタンスが、順番に符号化されるbin2のインスタンスとは無関係にコーディングされ、以下同様である。いくつかの例では、コンテキストモデラ122は、単一のブロックの変換単位に関してマルチパスコーディングを実行し得る。その上、通常モードに従って符号化されるビンに対して、コンテキストモデラ122は、複数のパスにおいてコンテキスト選択を実行し得る。各パスは、すべての変換係数の単一の対応するビンに関し得る。言い換えると、各パスの間に、コンテキストモデラ122は、他のパスに関する情報を利用しない。たとえば、コンテキストモデラ122は、第1のパスにおいて1つの変換単位/CG内のすべての変換係数の第1のビンのためのコンテキストを選択することができる。この例では、第2のパスにおいて、コンテキストモデラ122は、必要であれば、1つの変換単位/CG内のすべての変換係数の第2のビンのためのコンテキストを選択することができ、以下同様である。
1つの例示的な使用事例では、コンテキストモデラ122は、以前にコーディングされた隣接する変換係数のbin0の値を使用して現在コーディングされている変換係数のbin0のためのコンテキストモデリングを実行し、以前にコーディングされた隣接する変換係数のbin1の値を使用して現在コーディングされている変換係数のbin1のためのコンテキストモデリングを実行し、以下同様であり得る。以前にコーディングされた変換係数に対して利用可能である任意のビン値を使用して、コンテキストモデラ122は、現在コーディングされている変換係数の複数のビンに対するコンテキストモデリングを並列に実行し得る。上で説明された使用事例の状況では、bin0とbin1がともに以前にコーディングされた隣接変換係数から入手可能である場合、コンテキストモデラ122は、現在コーディングされている変換係数のためのbin0およびbin1のコンテキストモデリングを並列化することができる。このようにして、コンテキストモデラ122は、本開示の技法を実施して、HEVCにおいて記述されるようなマルチパスコーディングの主義の範囲内でCABACを実行しながら、コンテキストモデリング動作の並列化を可能にして場合によっては利用することによって、現在の変換係数のビンに対するコンテキストの選択を改善することができる。
コンテキストモデラ122は、必ずしもそうであるとは限らないが、すべてのそのようなビンの完全なコンテキストモデリングを並列に実行できることを理解されたい。より具体的には、コンテキストモデラ122は、複数のビンのコンテキストモデリングのいくつかの部分を同時に実行することができる。このようにして、コンテキストモデラ122は、本開示の技法を実施して、マルチコアプロセシング技術および/または複数のプロセッサを活用し、現在コーディングされている変換係数のためのコンテキストモデリング動作を改善することができる。
単一のパスにおいて異なる変換係数の対応するビンを符号化することによって、コンテキストモデラ122は、既存のマルチパスCABAC技法を超える1つまたは複数の利点を提供し得る。たとえば、単一のパスにおいて複数の変換係数の対応するビン(たとえば、それぞれのbin0)をコーディングすることによって、コンテキストモデラ122は、ビンの遷移において、新しいコンテキストモデルを頻繁に記憶して取り出す必要をなくすことができる。代わりに、コンテキストモデラ122は、所与のパスの全体で単一のコンテキストモデルを使用することができ、それは、そのパスが複数の変換係数にわたって、対応するビン(たとえば、それぞれのbin0)を対象とするからである。このようにして、コンテキストモデラ122は、本開示の並列化されたコンテキスト選択技法を実施して、頻繁なコンテキスト切替えにより生じる時間遅延およびリソースの混乱を軽減し、または場合によってはなくすことができる。対照的に、既存のマルチパスコーディングは、第1の変換係数のためにbin0、bin1、bin2などを符号化し、次いで第2の変換係数のためにbin0、bin1、bin2などを符号化することなどが原因で、頻繁なコンテキストモデルの保存と取出しの動作が必要になる。
たとえば、コンテキストモデラ122は、本明細書において説明されるi番目のビンコンテキストモデリング機能のために使用すべき、1つまたは複数の事前に定義されたテンプレートを生成し、またはそうでなければそれを入手し得る。コンテキストモデラ122が現在コーディングされている変換係数のi番目のビンのコンテキストモデリングのために使用し得る、事前に定義されたテンプレートの1つの非限定的な例が、図10に示されている。図10のテンプレート140などの事前に定義されたテンプレートは、8×8の変換ブロックのための対角方向の走査順序を定義し、ここで「L」は最後の有意な走査位置を表し、「x」は現在の走査位置を表し、「xi」はローカルテンプレート140によってカバーされる近隣を表す。xiに関して、「i」という値は0から4の範囲にあり、範囲の制約はi・[0, 4]として表される。本開示の1つまたは複数の態様によれば、コンテキストモデラ122は、現在符号化されている変換係数の対応するi番目のビンのコンテキストモデリングのために、ローカルテンプレート140の中に位置する変換係数のi番目のビンを使用し得る。いくつかの実装形態によれば、コンテキストモデラ122は、複数のテンプレートを使用して、本開示の並列化されたビンコンテキストモデリングを実行し得る。一例では、テンプレートのサイズおよび/または形状は、(i)変換単位のサイズ、または(ii)モード、または(iii)現在の変換単位もしくは係数グループ(CG)内での現在の変換係数の位置という基準のうちの1つまたは複数に依存する。
1つまたは複数の事前に定義されたテンプレートを使用してビン値のための以前にコーディングされたTUを横断することによって、コンテキストモデラ122は、本開示の技法を実施して、既存のCABAC技法を超える1つまたは複数の改善をもたらし得る。たとえば、図10のローカルテンプレート140などのTU横断テンプレートを使用することによって、コンテキストモデラ122は、異なるコーディングパスに関して横断方式を別々に決定する必要をなくすことができる。したがって、本開示のテンプレートベースの並列化されたコンテキスト選択技法を実施することによって、コンテキストモデラ122は、コーディング精度を維持しながら、ビンのコーディングに関してスループットを向上させることができる。
別の例示的な実装形態によれば、コンテキストモデラ122は、現在コーディングされている変換係数の最初の「K」個のビンだけに、本開示の並列化されたコンテキストモデリング技法を適用することがあり、ここで「K」はMより小さく、Mは利用可能なビンインデックスの上限を表す。コンテキストモデラ122は、別のコンテキストモデリング技法を使用して、またはバイパスモードに従って、残りの(M+1-K)個のビンを符号化し得る。
別の例示的な実装形態によれば、コンテキストモデラ122は、現在符号化されている変換係数の前の、現在の変換単位またはCG内の符号化順序において連続する「N」個の変換係数として、以前にコーディングされた変換係数の世界を定義し得る。代替的に、コンテキストモデラ122は、Nを可変であるものとして決定し得る。一例では、コンテキストモデラ122は、現在の変換単位の中での現在符号化されている変換係数の相対的な位置に応じて、Nの値を決定し得る。別の例では、コンテキストモデラ122は、変換単位のサイズに応じてNの値を決定し得る。
別の実装形態では、コンテキストモデラ122は、現在の変換単位またはCG内で現在の位置の近隣に位置する変換係数として、以前に符号化された変換係数の世界を定義し得る。一例では、現在の位置の近隣は、現在の位置に直接隣り合う位置、または、現在の位置に直接隣り合うか現在の位置から離れているかのいずれかの位置に制約される。別の例では、近隣は、これらの位置を含み得るが、1つまたは複数の空間的に隣接する変換単位の中の位置を含むように拡大し得る。
本開示の様々な態様によれば、コンテキストモデラ122は、1つまたは複数の以前にコーディングされた変換係数と関連付けられる値の関数として、ビンのコンテキストインデックスを定義し得る。たとえば、コンテキストモデラ122は、以前にコーディングされた変換係数のすべてのi番目のビン値の合計を生む関数を使用し得る。より具体的には、この例では、コンテキストモデラ122は、TU/CUのすべての以前に符号化された変換係数の利用可能なi番目のビン値の値の加算を実行し得る。そして、コンテキストモデラ122は、現在コーディングされている変換係数のi番目のビンのためのコンテキストモデリングの間に、コンテキストインデックス(CtIdx)として得られた合計を使用し得る。
本開示のいくつかの態様によれば、コンテキストモデラ122は、異なるサイズの変換単位において、同じパスに対してはコンテキストインデックスの導出規則が変更されないままにすることができる。しかしながら、コンテキストモデラ122は、オフセットをコンテキストインデックスに適用して、現在コーディングされているビンのためのコンテキストモデリングを実行することができる。たとえば、コンテキストモデラ122は、2つの異なる変換サイズがコンテキストモデルの2つの集合を有すると決定し得る。そして、コンテキストモデラ122は、1つのそのような集合の中のコンテキストモデルの数として、オフセットを定義し得る。たとえば、TUサイズが事前に定義された次元M×Mの正方形より小さいとコンテキストモデラ122が決定する場合、コンテキストモデラ122は、各々のそのようなTU(M×Mより小さい)のサイズがコンテキストモデルの固有のそれぞれの集合を有すると決定し得る。逆に、エントロピー符号化ユニット56は、M×M以上のサイズを有するすべてのTUがコンテキストモデルの同じ集合を共有すると決定し得る。
様々な使用事例の状況において、コンテキストモデラ122は、Mの値を16に設定し得る。より具体的には、これらの例では、現在コーディングされているTUのサイズが16×16の正方形より小さいとコンテキストモデラ122が決定する場合、コンテキストモデラ122は、現在コーディングされているTUがTUの特定のサイズに対応するコンテキストモデルの集合と関連付けられると決定し得る。逆に、現在コーディングされているTUが16×16以上のサイズを有するとエントロピー符号化ユニットが決定する場合、コンテキストモデラ122は、現在コーディングされているTUが、16×16以上のサイズを有するすべての他のTUとコンテキストモデルの同じ集合を共有すると決定し得る。いくつかの例では、コンテキストモデラ122は、TUサイズベースのコンテキストの選択を、ルーマブロックにのみ適用し得る。
本開示のいくつかの態様によれば、コンテキストモデラ122は、変換サイズに基づいて係数グループ(CG)サイズを決定し得る。言い換えると、これらの態様によれば、CGサイズは変換サイズに依存する。代わりに、または加えて、コンテキストモデラ122は、コーディングモードに基づいてCGサイズを決定し得る。これらの例では、コンテキストモデラ122は、変換サイズおよび/またはコーディングモードの一方または両方に依存するものとして、CGサイズを決定し得る。代わりに、または加えて、コンテキストモデラ122は、変換行列に基づいてCGサイズを決定し得る。
本開示のいくつかの態様によれば、コンテキストモデラ122は、変換バイパスモード(「変換スキップモード」とも呼ばれる)を使用して符号化されるブロックにも、並列化されたコンテキストモデリング技法を適用し得る。変換バイパスモードは、無損失のコーディング出力を与えるためにビデオエンコーダ20が符号化の変換と量子化の動作をスキップし得る、コーディングモードを指す。したがって、本開示のいくつかの態様によれば、コンテキストモデラ122は、無損失のコーディングの事例において利益をもたらす可能性を与えるように、並列化されたコンテキスト選択技法を拡大し得る。
図4に戻ると、場合によっては、ビデオエンコーダ20のエントロピー符号化ユニット56または別のユニットは、エントロピーコーディングに加えて、他のコーディング機能を実行するように構成され得る。たとえば、エントロピー符号化ユニット56は、CUおよびPUのコーディングブロックパターン(CBP)値を決定するように構成され得る。また、場合によっては、エントロピー符号化ユニット56は、係数のランレングスコーディングを実行し得る。加えて、エントロピー符号化ユニット56、または他の処理ユニットは、量子化行列の値などの他のデータもコーディングし得る。
上で論じられたように、逆量子化ユニット58および逆変換処理ユニット60は、たとえば、参照ブロックとして後で使用するためのピクセル領域中の残差ブロックを再構築するために、それぞれ、逆量子化および逆変換を適用する。動き補償ユニット44は、参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、1つまたは複数の補間フィルタを再構築された残差ブロックに適用し得る。加算器62は、動き補償ユニット44によって生成された動き補償された予測ブロックに再構築された残差ブロックを加算して、参照ピクチャメモリ64内に記憶するための再構築されたビデオブロックを生成する。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために、参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
図6は、改善されたCABAC設計に従ってデータをコーディングするための技法を実施し得るビデオデコーダ30の例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図4)に関して説明された符号化パスと全体的に逆の復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成することができ、一方、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成することができる。
復号プロセスの間に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化されたビデオスライスのビデオブロックと関連するシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化された係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成する。いくつかの例では、エントロピー復号ユニット70は、本開示の技法に従ってCABACおよび/または改善されたCABACを実行し得る。エントロピー復号ユニット70は、動き補償ユニット72に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信し得る。
ビデオスライスがイントラコーディングされるスライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの以前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされる(すなわち、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの1つの中の参照ピクチャの1つから作成され得る。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づいて、デフォルトの構築技法を使用して、参照フレームリスト、リスト0およびリスト1を構築し得る。動き補償ユニット72は、動きベクトルと他のシンタックス要素とを構文解析することによって、現在のビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して、復号されている現在のビデオブロックの予測ブロックを生成する。たとえば、動き補償ユニット72は、受信されたシンタックス要素の一部を使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスのための参照ピクチャリストのうちの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などのディスプレイデバイス上で後に提示するための復号されたビデオを記憶する。
図6のビデオデコーダ30は、改善されたCABACのための本開示の様々な技法のいずれをも、単独で、または任意の組合せで実行するように構成され得るビデオデコーダの例を表す。したがって、上で説明された技法は、ビデオエンコーダ20(図1および図4)および/またはビデオデコーダ30(図1および図5)によって実行されることがあり、それらの両方が一般にビデオコーダと呼ばれることがある。同様に、ビデオコーディングは、適宜、ビデオ符号化またはビデオ復号を指し得る。エントロピー復号ユニット70などのビデオデコーダ30の様々な構成要素は、本開示の改善されたCABAC技法を実施してコンテキストモデリングを実行し得る。本開示の様々な態様によれば、エントロピー復号ユニット70は、1つまたは複数の以前の復号された変換係数のi番目のビンの値を使用して、変換係数のi番目のビンのためのコンテキストモデリングを実行し得る。別の言い方をすると、現在の変換係数のi番目のビンのコンテキストモデリングは、エントロピー復号ユニット70がすでに復号した1つまたは複数の変換係数の対応するi番目のビンの値に依存する。
以前に復号された変換のi番目のビンの値を使用して現在の変換係数のビンのためのコンテキストモデリングを実行することによって、エントロピー復号ユニット70は、本開示の技法を実施して、既存のCABACコーダを超える1つまたは複数の潜在的な改善をもたらし得る。そのような利点の例として、エントロピー復号ユニット70は、本開示の技法を実施することによって、コンテキストモデリング動作の並列化を改善し得る。より具体的には、エントロピー復号ユニット70は、現在復号されている変換係数の複数のビンに対して、コンテキストモデリングを並列に実行し得る。たとえば、複数のビンに対応するビン値が以前に復号された変換係数から利用可能であるとエントロピー復号ユニット70が決定する場合、エントロピー復号ユニット70は、現在復号されている変換係数のビンに対して、コンテキストモデリング動作を少なくとも部分的に並列化し得る。
エントロピー復号ユニット70は、マルチパスコーディング方式に従って、本開示の並列化されたコンテキストモデリングを実行し得る。より具体的には、マルチパスコーディング方式は、エントロピー復号ユニット70が別々のスレッドを各々の特定のビンに割り当てる(たとえば、第1のビンに対してスレッド1、第2のビンに対してスレッド2など)、コーディング技法を指す。したがって、マルチパスコーディングによれば、すべてのbin0のインスタンスが、順番に復号されるbin1のインスタンスとは無関係に、順番に復号されることが可能であり、bin0とbin1の両方のインスタンスが、順番に復号されるbin2のインスタンスとは無関係に復号され、以下同様である。いくつかの例では、エントロピー復号ユニット70は、単一のブロックの変換単位に関してマルチパスコーディングを実行し得る。その上、通常モードに従って復号されるビンに対して、エントロピー復号ユニット70は、いくつかの復号パスを実行し得る。各パスは、すべての変換係数の単一の対応するビンに関し得る。言い換えると、エントロピー復号ユニット70は、他のパスに関する情報を利用しない。たとえば、エントロピー復号ユニット70は、第1のパスにおいて1つの変換単位/CG内のすべての変換係数の(必要であれば)第1のビンを復号することができる。この例では、第2のパスにおいて、エントロピー復号ユニット70は、必要であれば、1つの変換単位/CG内のすべての変換係数の第2のビンを復号することができ、以下同様である。
1つの例示的な使用事例では、エントロピー復号ユニット70は、以前にコーディングされた隣接する変換係数のbin0の値を使用して現在コーディングされている変換係数のbin0のためのコンテキストモデリングを実行し、以前にコーディングされた隣接する変換係数のbin1の値を使用して現在コーディングされている変換係数のbin1のためのコンテキストモデリングを実行し得る。以前にコーディングされた変換係数に対して利用可能である任意のビン値を使用して、エントロピー復号ユニット70は、現在コーディングされている変換係数の複数のビンに対するコンテキストモデリングを並列に実行し得る。上で説明された使用事例の状況では、bin0とbin1がともに以前にコーディングされた隣接変換係数から入手可能である場合、エントロピー復号ユニット70は、現在コーディングされている変換係数のためのbin0およびbin1のコンテキストモデリングを並列化することができる。このようにして、エントロピー復号ユニット70は、本開示の技法を実施して、HEVCにおいて記述されるようなマルチパスコーディングの主義の範囲内でCABACを実行しながら、コンテキストモデリング動作の並列化を可能にして場合によっては利用することによって、現在の変換係数のビンに対するコンテキストの選択を改善することができる。
エントロピー復号ユニット70は、必ずしもそうであるとは限らないが、すべてのそのようなビンの完全なコンテキストモデリングを並列に実行できることを理解されたい。より具体的には、エントロピー復号ユニット70は、複数のビンのコンテキストモデリングのいくつかの部分を同時に実行することができる。このようにして、エントロピー復号ユニット70は、本開示の技法を実施して、マルチコアプロセシング技術および/または複数のプロセッサを活用し、現在コーディングされている変換係数のためのコンテキストモデリング動作を改善することができる。
単一のパスにおいて異なる変換係数の対応するビンを復号することによって、エントロピー復号ユニット70は、既存のマルチパスCABAC技法を超える1つまたは複数の利点を提供し得る。たとえば、単一のパスにおいて複数の変換係数の対応するビン(たとえば、それぞれのbin0)を復号することによって、エントロピー復号ユニット70は、ビンの遷移において、新しいコンテキストモデルを頻繁に記憶して取り出す必要をなくすことができる。代わりに、エントロピー復号ユニット70は、所与のパスの全体で単一のコンテキストモデルを使用することができ、それは、そのパスが複数の変換係数にわたって、対応するビン(たとえば、それぞれのbin0)を対象とするからである。このようにして、エントロピー復号ユニット70は、本開示の並列化されたコンテキスト選択技法を実施して、頻繁なコンテキスト切替えにより生じる時間遅延およびリソースの混乱を軽減し、または場合によってはなくすことができる。対照的に、既存のマルチパスコーディングは、第1の変換係数のためにbin0、bin1、bin2などを復号し、次いで第2の変換係数のためにbin0、bin1、bin2などを復号することなどが原因で、頻繁なコンテキストモデルの保存と取出しの動作が必要になる。
たとえば、エントロピー復号ユニット70は、本明細書において説明されるi番目のビンコンテキストモデリング機能のために使用すべき、1つまたは複数の事前に定義されたテンプレートを生成し、またはそうでなければそれを入手し得る。エントロピー復号ユニット70が現在コーディングされている変換係数のi番目のビンのコンテキストモデリングのために使用し得る、事前に定義されたテンプレートの1つの非限定的な例が、図10に示されている。図10のテンプレート140などの事前に定義されたテンプレートは、8×8の変換ブロックのための対角方向の走査順序を定義し、ここで「L」は最後の有意な走査位置を表し、「x」は現在の走査位置を表し、「xi」はローカルテンプレート140によってカバーされる近隣を表す。xiに関して、「i」という値は0から4の範囲にあり、範囲の制約はi・[0, 4]として表される。本開示の1つまたは複数の態様によれば、エントロピー復号ユニット70は、現在復号されている変換係数の対応するi番目のビンのコンテキストモデリングのために、ローカルテンプレート140の中に位置する変換係数のi番目のビンを使用し得る。いくつかの実装形態によれば、エントロピー復号ユニット70は、複数のテンプレートを使用して、本開示の並列化されたビンコンテキストモデリングを実行し得る。一例では、テンプレートのサイズおよび/または形状は、(i)変換単位のサイズ、または(ii)モード、または(iii)現在の変換単位もしくは係数グループ(CG)内での現在の変換係数の位置という基準のうちの1つまたは複数に依存する。
1つまたは複数の事前に定義されたテンプレートを使用してビン値のための以前にコーディングされたTUを横断することによって、エントロピー復号ユニット70は、本開示の技法を実施して、既存のCABAC技法を超える1つまたは複数の改善をもたらし得る。たとえば、図10のローカルテンプレート140などのTU横断テンプレートを使用することによって、エントロピー復号ユニット70は、異なるコーディングパスに関して横断方式を別々に決定する必要をなくすことができる。したがって、本開示のテンプレートベースの並列化されたコンテキスト選択技法を実施することによって、エントロピー復号ユニット70は、コーディング精度を維持しながら、ビンのコーディングに関してスループットを向上させることができる。
別の例示的な実装形態によれば、エントロピー復号ユニット70は、現在コーディングされている変換係数の最初の「K」個のビンだけに、本開示の並列化されたコンテキストモデリング技法を適用することがあり、ここで「K」はMより小さく、Mは利用可能なビンインデックスの上限を表す。エントロピー復号ユニット70は、別のコンテキストモデリング技法を使用して、またはバイパスモードに従って、残りの(M+1-K)個のビンを復号し得る。
別の例示的な実装形態によれば、エントロピー復号ユニット70は、現在復号されている変換係数の前の、現在の変換単位またはCG内の復号順序において連続する「N」個の変換係数として、以前にコーディングされた変換係数の世界を定義し得る。代替的に、エントロピー復号ユニット70は、Nを可変であるものとして決定し得る。一例では、エントロピー復号ユニット70は、現在の変換単位の中での現在復号されている変換係数の相対的な位置に応じて、Nの値を決定し得る。別の例では、エントロピー復号ユニット70は、Nが変換単位のサイズに応じたものになるように、Nの値を決定し得る。
別の実装形態では、エントロピー復号ユニット70は、現在の変換単位またはCG内の現在の位置の近隣に位置する変換係数として、以前に復号された変換係数の世界を定義し得る。一例では、現在の位置の近隣は、現在の位置に直接隣り合う位置、または、現在の位置に直接隣り合うか現在の位置から離れているかのいずれかの位置に制約される。別の例では、近隣は、これらの位置を含み得るが、1つまたは複数の空間的に隣接する変換単位の中の位置を含むように拡大し得る。
本開示の様々な態様によれば、エントロピー復号ユニット70は、1つまたは複数の以前にコーディングされた変換係数と関連付けられる値の関数として、ビンのコンテキストインデックスを定義し得る。たとえば、エントロピー復号ユニット70は、以前にコーディングされた変換係数のすべてのi番目のビン値の合計を生む関数を使用し得る。より具体的には、この例では、エントロピー復号ユニット70は、TU/CGのすべての以前に復号された変換係数の利用可能なi番目のビン値の値の加算を実行し得る。そして、エントロピー復号ユニット70は、現在コーディングされている変換係数のi番目のビンのためのコンテキストモデリングの間に、コンテキストインデックス(CtIdx)として得られた合計を使用し得る。別の例では、エントロピー復号ユニット70はカットオフ値を定義し得る。この例では、関数の出力が事前に定義されたカットオフ値を超えるとき、エントロピー復号ユニット70は、現在コーディングされているビンに関して同じコンテキストを使用し得る。いくつかの例では、エントロピー復号ユニット70は、カットオフ値がビンインデックス/変換単位のサイズ/コーディングモード/1つの変換単位内での変換係数の位置に基づく(またはそれらに依存すべきである)ことを決定し得る。
いくつかの例では、エントロピー復号ユニット70は、これらのビンが同じコンテキストモデルを共有するように、異なるパスにおいてコーディングされる対応するビンを復号し得る。一例では、エントロピー復号ユニット70は、異なるパスにおけるビンのためのコンテキストインデックス導出方法、たとえばコンテキストインデックスを計算するための関数が異なると、決定し得る。一例によれば、エントロピー復号ユニット70は、異なるパスにおけるビンのためのコンテキストインデックス導出方法、たとえばコンテキストインデックスを計算するための関数が同じであり得ると、決定し得る。
本開示のいくつかの態様によれば、エントロピー復号ユニット70は、異なるサイズの変換単位において、同じパスに対してはコンテキストインデックスの導出規則が変更されないままにすることができる。しかしながら、エントロピー復号ユニット70は、オフセットをコンテキストインデックスに適用して、現在コーディングされているビンのためのコンテキストモデリングを実行することができる。たとえば、エントロピー復号ユニット70は、2つの異なる変換サイズがコンテキストモデルの2つの集合を有すると決定し得る。そして、エントロピー復号ユニット70は、1つのそのような集合の中のコンテキストモデルの数として、オフセットを定義し得る。たとえば、TUサイズが事前に定義された次元M×Mの正方形より小さいとエントロピー復号ユニット70が決定する場合、エントロピー復号ユニット70は、各々のそのようなTU(M×Mより小さい)のサイズがコンテキストモデルの固有のそれぞれの集合を有すると決定し得る。逆に、エントロピー復号ユニット70は、M×M以上のサイズを有するすべてのTUがコンテキストモデルの同じ集合を有すると決定し得る。
様々な使用事例の状況において、エントロピー復号ユニット70は、Mの値を16に設定し得る。より具体的には、これらの例では、現在コーディングされているTUのサイズが16×16の正方形より小さいとエントロピー復号ユニット70が決定する場合、エントロピー復号ユニット70は、現在コーディングされているTUがTUの特定のサイズに対応するコンテキストモデルの集合と関連付けられると決定し得る。逆に、現在復号されているTUが16×16以上のサイズを有するとエントロピー復号ユニット70が決定する場合、エントロピー復号ユニット70は、現在コーディングされているTUが、16×16以上のサイズを有するすべての他のTUとコンテキストモデルの同じ集合を共有すると決定し得る。いくつかの例では、エントロピー復号ユニット70は、TUサイズベースのコンテキストの選択を、ルーマブロックにのみ適用し得る。
いくつかの例によれば、残りのビンをコーディングするために使用されるRiceパラメータは、変換サイズに依存する。代わりに、または加えて、Riceパラメータはコーディングモードに依存し得る。一例では、coeff_abs_level_remainingのためにゴロムライス符号を使用する代わりに、エントロピー復号ユニット70は他のバイナリ化技法を使用し得る。代わりに、または加えて、2つ以上のバイナリ化方法が、coeff_abs_level_remainingシンタックス要素をコーディングするために適用され得る。一例では、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、コーディングモードに依存する。代替的に、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、1つのTU内での相対的な位置に依存し得る。代わりに、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、走査順序における最初のコーディング/復号される変換係数からの距離に依存し得る。いくつかの事例では、coeff_abs_level_remainingをコーディングするために使用されるバイナリ化方法(たとえば、Riceパラメータ)は、変換単位に対する相対的なコーディンググループの位置に依存する。
本開示のいくつかの態様によれば、エントロピー復号ユニット70は、変換サイズに基づいて係数グループ(CG)サイズを決定し得る。言い換えると、これらの態様によれば、CGサイズは変換サイズに依存する。代わりに、または加えて、エントロピー復号ユニット70は、コーディングモードに基づいてCGサイズを決定し得る。これらの例では、エントロピー復号ユニット70は、変換サイズおよび/またはコーディングモードの一方または両方に依存するものとして、CGサイズを決定し得る。代わりに、または加えて、エントロピー復号ユニット70は、変換行列に基づいてCGサイズを決定し得る。
本開示のいくつかの態様によれば、エントロピー復号ユニット70は、変換バイパスモード(「変換スキップモード」とも呼ばれる)を使用して符号化されるブロックにも、並列化されたコンテキストモデリング技法を適用し得る。変換バイパスモードは、ビデオビットストリームの無損失で符号化された部分を処理するためにビデオデコーダ30が復号の逆変換と逆量子化の動作をスキップし得る、コーディングモードを指す。したがって、本開示のいくつかの態様によれば、エントロピー復号ユニット70は、受信された符号化されたビデオビットストリームが無損失で符号化される事例において利益をもたらす可能性を与えるように、並列化されたコンテキスト選択技法を拡大し得る。
本開示の様々な変換係数コンテキストモデリング技法の例示的な詳細が、以下でさらに詳細に論じられる。マルチパスコーディングに従ったコンテキストモデリングの一例が以下で説明される。この例によれば、エントロピー復号ユニット70は、HEVCにおいて設計されるようなコーディング要素およびコーディング順序(マルチパスコーディング、およびCGベース)を適用し得る。加えて、エントロピー復号ユニット70は、変換係数の大きさが変わらないままであるように保ちながら、バイナリ化技法を適用し得る。しかしながら、エントロピー復号ユニット70は、変換係数の大きさをコーディングするためのコンテキストインデックスおよびRiceパラメータの計算方法を修正し得る。
bin0(有意性フラグ)に対するコンテキストインデックスの計算は、テンプレートにおける0ではない係数(すなわち、係数の大きさが0より大きい)の数、現在のTU内での現在の係数の位置、ルーマ成分に対するTUサイズ、および色成分という情報に依存する。色成分の依存性に関して、ルーマとクロマは別々に考慮される。加えて、ルーマ成分に対するTUサイズを考慮する際、コンテキストインデックスの計算はルーマに対するTUサイズとは無関係である。ルーマ成分のTUサイズは、3つの集合、すなわち、4×4のTU、8×8のTU、16×16以上のTUを含み得る。
bin1およびbin2(Grt than 1、Grt than 2)に対して、コンテキストインデックスの計算は、(bin1に対して)1より大きいテンプレート中のabsLevelsの数および(bin2に対して)2より大きいテンプレート中のabsLevelsの数、現在のTU内での現在の係数の位置、ならびに色成分という情報に依存し得る。Riceパラメータの導出プロセスは、バイパスコーディング情報に、およびsum_absolute_levelMinus1シンタックス要素の値に依存する。
一例では、エントロピー復号ユニット70は、係数の大きさがkより大きくなるように、テンプレートの中の係数の数を返すように関数sum_template(k)を定義し得る。sum_template(k)関数の例は次の通りである。
加えて、この例では、エントロピー復号ユニット70は、以下のように、位置情報を扱うように関数function f(x, y, n, t)を定義し、成分情報を扱うように別の関数δk(u, v)を定義し得る。
図10は、本明細書において説明されるコンテキストモデリング技法に関してエントロピー復号ユニット70が使用し得るテンプレート(ローカルテンプレート140)の一例を示す。現在の変換係数は「X」としてマークされ、5つの空間的な近隣は「Xi」としてマークされる(iは0から4の整数を表す)。以下の条件のいずれか1つが満たされる場合、エントロピー復号ユニット70は、コンテキストインデックスの導出プロセスにおいて利用不可能であり使用されないものとしてXiをマークし得る。
・ Xiの位置および現在の変換係数Xは同じ変換単位の中に位置せず、または、
・ Xiの位置はピクチャの水平方向もしくは垂直方向の境界の外側に位置し、または、
・ 変換係数Xiはまだコーディングされていない。マルチパスコーディングの場合、同じコーディングパスにおけるビンがコーディングされるときはいつでも、それらのビンがコンテキストインデックスの導出プロセスにおいて使用され得る。したがって、復号の観点からは、1つの変換係数を完全に復号することは必要ではない。
代替的に、エントロピー復号ユニット70は、隣接する変換単位からの情報を含み得る1つまたは複数の他のテンプレートを適用し得る。様々な例では、隣接するTUは空間的な近隣または時間的な近隣であり得る。本明細書において説明されるコンテキストモデリング技法の1つまたは複数によれば、コンテキストインデックスの計算は以下の段落において説明されるように定義され得る。
bin0に関して、エントロピー復号ユニット70は、コンテキストインデックスを次のように導出し得る。
c0 = min(sum_template(0), 5)+f(x, y, 6, 2) +δk(f(x, y, 6, 5), cIdx) + offset(cIdx, width)
c0 = c0 + offset(cIdx, width)
ここで、
一例では、c0の範囲に基づいて、ルーマコンテキストの1つの集合は、NumberLumaCtxOnesetの値に等しい数のコンテキストモデルを含み得る。たとえば、ルーマコンテキストの集合は18個のコンテキストモデルを含み得る。ルーマbin0をコーディングするための異なる変換サイズ(変換の幅は「w」によって表記される)に関して、エントロピー復号ユニット70は、各変換サイズに対して異なる集合を選択し得る。加えて、クロマコンテキストおよびルーマコンテキストは、コーディング性能をさらに改善するために分離される。YCbCr入力に対して、3つの色成分、すなわちY、Cb、およびCrはそれぞれ、0、1、および2に等しい成分インデックスvを用いて表される。
これらの例では、エントロピー復号ユニット70は、bin1のためのコンテキストインデックスを次のように導出し得る。
c1 = min(sum_template(1), 4) + N
c1 = c1 +δk(f(x, y, 5, 3), cIdx) +δk(f(x, y, 5, 10), cIdx)
加えて、これらの例では、エントロピー復号ユニット70は、bin2のためのコンテキストインデックスを次のように導出し得る。
c2 = min(sum_template(2), 4) + N
c2 = c2 +δk(f(x, y, 5, 3), cIdx) +δk(f(x, y, 5, 10), cIdx)
一例では、Nは0に等しい。別の例では、Nは1に等しい。代わりに、または加えて、Nが1に等しいとき、エントロピー復号ユニット70は、0に等しいコンテキストインデックスc1またはc2を用いて第1のbin1またはbin2をコーディングし得る。この例では、エントロピー復号ユニット70は、上の式に従ってbin1およびbin2の他のインスタンスをコーディングし得る。
一例では、エントロピー復号ユニット70は、コンテキストモデルの同じ集合を有するが異なるインデックスを有する、bin1およびbin2を復号し得る。代わりに、bin1およびbin2はコンテキストモデルの2つの集合を用いてコーディングされ、それらの間には依存性がない。残りのビンに対して、エントロピー復号ユニット70は、HEVCにおいて展開される設計またはJCTVC-H0228における設計を適用し得る。様々な例において、エントロピー復号ユニット70は、上で説明された様々な関数を構築する際に異なる定数値を使用し得る。
本開示の追加の態様は、コンテキスト初期化の改善を対象とする。本開示のコンテキスト初期化の改善は、上で説明された並列化されたコンテキスト選択技法とは独立に実施されることがあり、または、上で説明された並列化されたコンテキスト選択技法の任意の1つまたは複数と組み合わせて実施されることがある。本開示のコンテキスト初期化技法の1つまたは複数は、以前に復号された情報からコンテキスト情報を再使用することを対象とする。たとえば、エントロピー復号ユニット70は、現在のピクチャまたは以前に復号されたピクチャに属し得る、以前に復号されたスライスからのステータスをコピーすることによって、スライスのためのコンテキスト情報を継承し、またはそうでなければ導出することができる。
以前に復号されたスライスからコンテキスト初期化情報を継承することによって、エントロピー復号ユニット70は、本開示の技法を実施して、既存のCABACコンテキスト初期化技法と比較して改善された精度を提供することができる。たとえば、既存のCABACコンテキスト初期化技法は、テーブルからコンテキストステータス情報を取得することに依存する。しかしながら、テーブルは静的な情報を使用して形成される。しかしながら、本開示の継承ベースのコンテキスト初期化技法によれば、エントロピー復号ユニット70は、同じスライスタイプである、かつ/または現在復号されているスライスと同じ量子化パラメータ(QP)を有する、以前に復号されたスライスからコンテキスト初期化情報を引き出すことができる。このようにして、エントロピー復号ユニット70は、本開示の技法を実施して、現在のスライスための使用されるコンテキスト初期化情報の精度を改善することができる。
いくつかの実装形態によれば、エントロピー復号ユニット70は、コンテキスト初期化情報をそこから継承すべきスライスとして、以前に復号されたスライスの中心LCUを特定し得る。様々な例において、エントロピー復号ユニット70は、複数の対応する以前に復号されたスライスから、現在のピクチャの現在のスライスのためのコンテキスト初期化を継承し得る。一例では、エントロピー復号ユニット70は、本開示のコンテキスト初期化技法に従って復号される複数のスライスのすべてのためのコンテキスト初期化情報をそこから継承すべき、以前に復号されたピクチャの同じブロック(すなわち、中心LCU)を使用し得る。別の例では、エントロピー復号ユニット70は、以前に復号されたピクチャの対応するスライスの各々からのそれぞれの中心LCUから、複数のスライスの各々のためのコンテキスト初期化情報を継承し得る。
たとえば、以前に復号されたピクチャの中心LCUを復号した後で、エントロピー復号ユニット70は、スライスコンテキスト初期化に関してステータス情報のすべてを記憶し得る。次いで、エントロピー復号ユニット70は、コピーされたステータス情報にアクセスしてそれを読み取り、現在復号されているピクチャの1つまたは複数のスライスのためのコンテキストを初期化するためにそのステータス情報を使用し得る。以前に復号されたピクチャからのステータス情報を使用して現在のピクチャのスライスのためのコンテキスト初期化を実行することによって、エントロピー復号ユニット70は、コンテキスト初期化が目的の、静的な情報の固定されたテーブルに対する依存を減らすことができる。たとえば、固定されたテーブルを使用して最初のピクチャのスライスならびに任意のイントラコーディングされたピクチャのためのコンテキストを初期化した後で、エントロピー復号ユニット70は、続いて復号されるインターコーディングされたピクチャのためのコンテキスト初期化を実行し得る。エントロピー復号ユニット70は、Pスライスおよび/またはBスライスに関して、本開示の継承ベースのコンテキスト初期化技法を実施し得る。
本開示のコンテキスト初期化技法の追加の例示的な詳細が以下で説明される。エントロピー復号ユニット70は、追加で、または代替的に、以下で論じられるような、コンテキスト初期化のための本開示による技法を実行するように構成され得る。エントロピー復号ユニット70は、本開示のコンテキスト初期化技法を実施して、現在のスライスをコーディングするための初期化されたコンテキスト情報として以前に復号されたピクチャの中に位置する1つのブロックを符号化した後で、コンテキスト情報を継承し得る。エントロピー復号ユニット70は、Pスライスおよび/またはBスライスに継承ベースのコンテキスト初期化技法を適用し得る。加えて、上で言及された「1つのブロック」の位置は、事前に定義されており、1つの全体のシーケンスに対して固定されている。たとえば、最大コーディング単位サイズ(LCU)は「N×N」によって表記され、ピクチャの幅は「W」によって表記され、ピクチャの高さは「H」によって表記される。この例では、「PicWidthInCtbsY」によって表記される、1つのLCU行の中のLCUの数は、天井関数、すなわちCeil(W÷N)の出力に等しい。加えて、この例では、「PicHeightInCtbsY」によって表記されるLCU行の数はCeil(H÷N)に等しく、ここで天井関数Ceil(x)はx以上の最小の整数を表す。
いくつかの例によれば、位置は、以前に復号されたピクチャの中の第1のスライスの中心LCUとして定義される。numLCUinSliceが第1のスライスの中のLCUの数を表すと仮定すると、位置はTargetCUAddr = numLCUinSlice/2として定義される。一例では、位置はTargetCUAddr = (PicWidthInCtbsY* PicHeightInCtbsY)/2 + PicWidthInCtbsY /2として定義される。さらに、TargetCUAddrが(PicWidthInCtbsY* PicHeightInCtbsY)以上である(たとえば、PicHeightInCtbsYが1に等しい)とき、TargetCUAddrは、(PicWidthInCtbsY* PicHeightInCtbsY - 1)にリセットされ、これは最後のLCUに対応する。一例では、位置は、以前にコーディングされたピクチャの最後のLCU、または1つのフレーム内の中心LCU(すなわち、PicWidthInCtbsY* PicHeightInCtbsY/2)、または中心のLCU行の最後のLCU(すなわち、PicWidthInCtbsY* (PicHeightInCtbsY/2) - 1)、またはk番目のLCU行の最後のLCU(たとえば、kは1に等しい)として定義される。1つの例によれば、位置は、以前に復号されたピクチャの中の第1のスライスの最後のLCUとして定義される。本開示のコンテキスト初期化技法のいくつかの実装形態によれば、分解能が異なると、コーディングブロックの位置の定義が異なり得る。
いくつかの例では、エントロピー復号ユニット70は、「1つのブロック」の位置を、符号化されたビデオビットストリームにおいてシグナリングされる、シーケンスパラメータセット(SPS)またはピクチャパラメータセット(PPS)などのパラメータセットから取得し得る。SPSおよび/またはPPSなどのパラメータセットは、現在のピクチャのスライスに関して帯域外でシグナリングされ得る。いくつかの例では、「1つのブロック」の位置は、スライスヘッダにおいてシグナリングされ得る。スライスヘッダは、対応するスライスに関して帯域内でシグナリングされ得る。これらの例および他の例では、参照ピクチャインデックス、対応するピクチャ順序カウントの差分(またはデルタPOC)などの、以前に復号されたピクチャの指示が、パラメータセットまたはスライスヘッダにおいてシグナリングされ得る。
いくつかの例では、「以前にコーディングされたピクチャ」は、現在のピクチャのすぐ前(直前)に復号されたピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、以前のピクチャの中の第1のスライスが現在のスライスと同じスライスタイプを有するように、現在のピクチャの前に復号された最後のピクチャであるピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、現在のピクチャの前の復号されたピクチャであるピクチャとして定義され、以前のピクチャの中の第1のスライスは、現在のスライスと同じ初期量子化パラメータを有する。いくつかの例によれば、「以前にコーディングされたピクチャ」は、現在のスライスおよび/または上記の同じ初期量子化パラメータと、同じスライスタイプを有する、または同じスライスタイプと量子化パラメータの両方を有する、または同じスライスタイプと時間レイヤの両方を有する、以前にコーディングされたスライスを含むピクチャとして定義される。いくつかの例では、「以前にコーディングされたピクチャ」は、ピクチャバッファ(復号ピクチャバッファなど)の中に存在するピクチャとして定義され、参照ピクチャとして現在のピクチャのために使用され得る。これらの例によれば、HEVCベースのプラットフォームのように、以前のスライスは、参照ピクチャセット(RPS)の中のピクチャに、またはRefPicSetStCurrBefore、RefPicSetStCurrAfter、およびRefPicSetLtCurrという部分集合のうちの1つの中のピクチャに、属さなければならない。
本開示のコンテキスト初期化技法のいくつかの実装形態によれば、表示順序においてあるイントラコーディングされたピクチャの後でコーディングされるピクチャのすべてが同じスライスタイプおよび同じ初期量子化パラメータを有しない場合、コンテキスト情報の継承は無効にされ得る。この場合、従来の初期化方法が適用され、たとえば、エントロピー復号ユニット70は固定されたテーブルを使用して、そのテーブルから初期ステータス情報を引き出し得る。いくつかの実装形態によれば、エントロピー復号ユニット70は、本開示の継承ベースのコンテキスト初期化技法を特定のコンテキストモデルに適用し、他のコンテキストモデルには適用しないことがある。加えて、または代わりに、「1つのブロック」の位置は、異なるコンテキストモデルに対しては異なり得る。上に列挙された様々な実装の選択肢は、本開示のコンテキスト初期化技法に従って、個別に、または様々な組合せで実装され得ることを理解されたい。
本開示のコンテキスト初期化技法のいくつかの例では、cabac_init_present_flagが有効であるとエントロピー復号ユニット70が決定する場合、エントロピー復号ユニット70は、「以前に復号されたピクチャ」に含まれるスライスが現在符号化されているスライスと同じタイプを有するべきであると決定し得る。別の言い方をすると、この例では、cabac_init_present_flagが有効である場合、以前に復号されたピクチャの定義は一致するスライスタイプに依存する。加えて、復号の観点から、シグナリングされるcabac_init_present_flagは、この実装形態によれば考慮されない。いくつかの事例では、代わりに、エントロピー復号ユニット70はまず、cabac_init_present_flagおよび「以前に復号されたピクチャ」の選択に基づいて、現在のスライスのスライスタイプを修正し得る。
本開示のコンテキスト初期化技法の追加の例示的な詳細が以下で説明される。いくつかの実装形態によれば、エントロピー復号ユニット70は、イントラランダムアクセスピクチャ(IRAP)に関して本開示の継承ベースのコンテキスト初期化技法を特定のコンテキストモデルに適用しないことがある。たとえば、エントロピー復号ユニット70は、3つのタイプのIRAP、すなわち、瞬時復号リフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、およびブロークンリンクアクセス(BLA)ピクチャのいずれかに関して、継承ベースのコンテキスト初期化技法を実施しないことがある。
以前にコーディングされた情報に基づく継承ベースのコンテキスト初期化の一例では、エントロピー復号ユニット70は、1つのスライスを有する1つのピクチャを復号し得る。この例では、エントロピー復号ユニット70は、以下の規則のうちの1つまたは複数を適用して、コンテキストモデルの初期状態を導出し得る。第1の規則は、以前に復号されたピクチャのスライスが現在復号されているスライスのスライスタイプと同じスライスタイプを有するというものである。代わりに、または加えて、初期スライス量子化パラメータ(QP)は、現在復号されているスライスをコーディングするために使用されるスライスQPと同じである。いくつかの事例では、エントロピー復号ユニット70は、以前に復号されたピクチャの中の事前に定義されたアドレスを有する1つのブロックを復号した後で状態情報(たとえば、状態)を記録し、現在復号されているスライスのための初期状態情報としてその記録された状態情報を使用し得る。
一例では、「1つのブロック」は最大コーディング単位(LCU)を表す。たとえば、LCUサイズ(次元)は「N×N」によって、ピクチャの幅は「W」によって、ピクチャの高さは「H」によって表記され得る。1つのLCU行の中のLCUの数は、PicWInCtbsYによって表記されることが可能であり、天井関数Ceil(W÷N)の出力に等しい。PicHInCtbsYにより表記される、ピクチャの中のLCU行の数は、天井関数Ceil(H÷N)の出力に等しい。一般的に説明すると、関数Ceil(x)はx以上の最小の整数を返す。加えて、LCUの単位で測られるピクチャの幅、およびLCUの単位で測られるピクチャの高さは、それぞれ、上で説明された天井関数を使用して得られるPicWInCtbsYおよびPicHInCtbsYの値によって表される。一例では、LCUのアドレスは以下の式に従って定義される。
TargetCUAddr = (Pic WInCtbsY * PicHInCtbs Y)/2 + PicWInCtbs Y/2
さらに、TargetCUAddrが(PicWInCtbsY* PicHInCtbsY)の値以上であるとき、エントロピー復号ユニット70は、TargetCUAddrを(PicWInCtbsY* PicHInCtbsY - 1)の値にリセットし得る。たとえば、TargetCUAddrは、PicHInCtbsYが1に等しい事例では、上記の値に等しいことがあり、またはそれを超えることがある。加えて、(PicWInCtbsY* PicHInCtbsY - 1)の値は、1つのピクチャの中の最後のLCUに対応する。
いくつかの事例では、さらに、エントロピー復号ユニット70は、表示順序において新しいイントラコーディングされたピクチャの後の最初の1つまたは複数のピクチャに対して、上で説明された規則ベースのコンテキスト初期化技法を適用しないことがある。エントロピー復号ユニット70が規則ベースのコンテキスト初期化を適用しない可能性がある例は、エントロピー復号ユニット70が初めて新しいスライスタイプまたは新しいQPに遭遇した(たとえば、新しいスライスタイプまたは新しいQPが出現した)場合である。たとえば、エントロピー復号ユニット70は、ランダムアクセスに関する問題を軽減し、または場合によっては回避し得る。本開示の例が図9に示されており、図9において、28から35のピクチャ順序カウント(POC)値を有するピクチャの復号順序は、32、28、…30、29、31、40、36、34、33、35である。
表示順序に関して、POC値が40に等しいピクチャは、POC値が32に等しいIピクチャの後で復号される最初のピクチャである。POC値が24に等しいピクチャはPOCが40に等しいピクチャと同じQPを有し、両方が同じスライスタイプを共有するが、エントロピー復号ユニット70は、POCが24に等しいピクチャのコーディングされた情報を使用して、POC値が40に等しいピクチャを予測しないことがある。同様に、エントロピー復号ユニット70は、POCが31に等しいピクチャに関して復号された情報を使用して、POCが33に等しいピクチャを再構築しないことがある。しかしながら、エントロピー復号ユニット70は、POCが33に等しいピクチャのコーディングされた情報を使用して、POCが35に等しいピクチャを再構築することがあり、それは、両方のピクチャがIピクチャよりも(表示順序において)後にあるからである。
以前に復号されたピクチャを使用した再構築が許可されない、無効にされている、またはエントロピー復号ユニット70に対して別様に利用可能ではない事例では、エントロピー復号ユニット70は、HEVCにおいて定義されたようにコンテキスト初期化技法を適用し得る。上で説明されたように、図6のビデオデコーダ30は、改善されたCABACのための本開示の様々な技法のいずれをも、単独で、または任意の組合せで実行するように構成されるビデオ復号デバイスの例を表す。
図7は、本開示の技法に従ってCABACを実行するように構成され得る例示的なエントロピー復号ユニット70のブロック図である。図7のエントロピー復号ユニット70は、図6のエントロピー復号ユニット70の1つの例示的な実装形態である。様々な例において、エントロピー復号ユニット70は、図5において説明されるエントロピー復号ユニット70の方式と逆の方式でCABACを実行する。ビットストリーム218からのコーディングされたビットは、エントロピー復号ユニット70に入力される。コーディングされるビットは、それらがバイパスモードまたは通常モードを使用してエントロピーコーディングされたかどうかに基づいて、コンテキストモデラ220とバイパスコーディングエンジン222のいずれかに与えられる。コーディングされるビットがバイパスモードでコーディングされた場合、バイパス復号エンジンは、たとえばゴロムライス復号または指数ゴロム復号を使用して、バイナリ値のシンタックス要素または非バイナリシンタックス要素のビンを取り出す。
コーディングされるビットが通常モードでコーディングされた場合、コンテキストモデラ220がコーディングされたビットのための確率モデルを決定することができ、通常復号エンジン224がコーディングされたビットを復号して非バイナリ値のシンタックス要素のビン(またはバイナリ値である場合シンタックス要素自体)を作成することができる。コンテキストモデルおよび確率状態σがコンテキストモデラ220によって決定された後で、通常復号エンジン224がビン値に対してBACを実行する。
図5は、本開示の技法に従ってCABACを実行するように構成され得る例示的なエントロピー復号ユニット70のブロック図である。シンタックス要素118は、エントロピー復号ユニット70に入力される。シンタックス要素がすでにバイナリ値のシンタックス要素(たとえば、0および1という値のみを有するフラグまたは他のシンタックス要素)である場合、バイナリ化のステップはスキップされ得る。シンタックス要素が非バイナリ値のシンタックス要素(たとえば、1または0以外の値を有し得るシンタックス要素)である場合、非バイナリ値のシンタックス要素はバイナライザ120によってバイナリ化される。バイナライザ120は、非バイナリ値のシンタックス要素の、バイナリの判断の列へのマッピングを実行する。これらのバイナリの判断は、しばしば「ビン」と呼ばれる。たとえば、変換係数レベルでは、レベルの値は連続的なビンへと分解されることがあり、各ビンは、係数レベルの絶対値が何らかの値より大きいかどうかを示す。たとえば、ビン0(有意性フラグと呼ばれることがある)は、変換係数レベルの絶対値が0より大きいかどうかを示す。ビン1は、変換係数レベルの絶対値が1より大きいかどうかを示し、以下同様である。各々の非バイナリ値のシンタックス要素に対して、固有のマッピングが開発され得る。
バイナライザ120によって作成される各ビンは、エントロピー符号化ユニット56のバイナリ算術コーディング側に与えられる。すなわち、非バイナリ値のシンタックス要素の所定の集合に対して、各ビンのタイプ(たとえば、ビン0)は、次のビンのタイプ(たとえば、ビン1)の前にコーディングされる。コーディングは、通常モードとバイパスモードのいずれかで実行され得る。バイパスモードでは、バイパスコーディングエンジン126は、固定された確率モデルを使用して、たとえばゴロムライスコーディングまたは指数ゴロムコーディングを使用して、算術コーディングを実行する。バイパスモードは一般に、より予測可能なシンタックス要素のために使用される。
通常モードにおけるコーディングは、CABACを実行することを伴う。通常モードのCABACは、以前に復号されたビンの値を与えられるとビンの値の確率が再構築されることが可能である場合に、ビン値をコーディングするためのものである。ビンがLPSである確率は、コンテキストモデラ220によって決定される。コンテキストモデラ220は、ビン値およびコンテキストモデルの確率状態(たとえば、LPSの値およびLPSが発生する確率を含む、確率状態σ)を出力する。コンテキストモデルは、一連のビンに対する初期コンテキストモデルであることがあり、または、以前に再構築されたビンの値に基づいて決定されることがある。上で説明されたように、コンテキストモデラ220は、受信されたビンがMPSまたはLPSであったかどうかに基づいて、状態を更新し得る。コンテキストモデルおよび確率状態σがコンテキストモデラ220によって決定された後で、通常復号エンジン224がビン値に対してBACを実行する。
コンテキストモデラ220は、本開示の技法を実施して、並列化された方式でコンテキストモデリングを実行し得る。本開示の様々な態様によれば、コンテキストモデラ220は、1つまたは複数の以前の復号された変換係数のi番目のビンの値を使用して、変換係数のi番目のビンのためのコンテキストモデリングを実行し得る。このようにして、現在の変換係数のi番目のビンのコンテキストモデリングは、コンテキストモデラ220がすでにそれに対するコンテキストを選択した1つまたは複数の変換係数の対応するi番目のビンの値に依存する。
以前に復号された変換のi番目のビンの値を使用して現在の変換係数のビンのためのコンテキストモデリングを実行することによって、コンテキストモデラ220は、本開示の技法を実施して、既存のCABACコーディングデバイスを超える1つまたは複数の潜在的な改善をもたらし得る。そのような利点の例として、コンテキストモデラ220は、本開示の技法を実施することによって、コンテキストモデリング動作の並列化を改善し得る。たとえば、コンテキストモデラ220は、現在復号されている変換係数の複数のビンに対して、コンテキストモデリングを並列に実行し得る。一例として、複数のビンに対応するビン値が以前に復号された変換係数から利用可能であるとコンテキストモデラ220が決定する場合、コンテキストモデラ220は、現在復号されている変換係数のビンに対して、コンテキストモデリング動作を少なくとも部分的に並列化し得る。
コンテキストモデラ220は、マルチパス復号方式に従って、本開示の並列化されたコンテキストモデリングを実行し得る。より具体的には、マルチパス復号方式は、エントロピー復号ユニット70が別々のスレッドを各々の特定のビンに割り当てる(たとえば、第1のビンに対してスレッド1、第2のビンに対してスレッド2など)、復号技法を指す。したがって、マルチパスコーディングによれば、すべてのbin0のインスタンスが、順番に復号されるbin1のインスタンスとは無関係に、順番に復号されることが可能であり、bin0とbin1の両方のインスタンスが、順番に復号されるbin2のインスタンスとは無関係に復号され、以下同様である。いくつかの例では、コンテキストモデラ220は、単一のブロックの変換単位に関してマルチパス復号を実行し得る。その上、通常モードに従って復号されるビンに対して、コンテキストモデラ220は、複数のパスにおいてコンテキスト選択を実行し得る。各パスは、すべての変換係数の単一の対応するビンに関し得る。言い換えると、各パスの間に、コンテキストモデラ220は、他のパスに関する情報を利用しない。たとえば、コンテキストモデラ220は、第1のパスにおいて1つの変換単位/CG内のすべての変換係数の第1のビンのためのコンテキストを選択することができる。この例では、第2のパスにおいて、コンテキストモデラ220は、必要であれば、1つの変換単位/CG内のすべての変換係数の第2のビンのためのコンテキストを選択することができ、以下同様である。
1つの例示的な使用事例では、コンテキストモデラ220は、以前にコーディングされた隣接する変換係数のbin0の値を使用して現在コーディングされている変換係数のbin0のためのコンテキストモデリングを実行し、以前にコーディングされた隣接する変換係数のbin1の値を使用して現在コーディングされている変換係数のbin1のためのコンテキストモデリングを実行し、以下同様であり得る。以前にコーディングされた変換係数に対して利用可能である任意のビン値を使用して、コンテキストモデラ220は、現在コーディングされている変換係数の複数のビンに対するコンテキストモデリングを並列に実行し得る。上で説明された使用事例の状況では、bin0とbin1がともに以前にコーディングされた隣接変換係数から入手可能である場合、コンテキストモデラ220は、現在コーディングされている変換係数のためのbin0およびbin1のコンテキストモデリングを並列化することができる。このようにして、コンテキストモデラ220は、本開示の技法を実施して、HEVCにおいて記述されるようなマルチパス復号の主義の範囲内でCABACを実行しながら、コンテキストモデリング動作の並列化を可能にして場合によっては利用することによって、現在の変換係数のビンに対するコンテキストの選択を改善することができる。
コンテキストモデラ220は、必ずしもそうであるとは限らないが、すべてのそのようなビンの完全なコンテキストモデリングを並列に実行できることを理解されたい。より具体的には、コンテキストモデラ220は、複数のビンのコンテキストモデリングのいくつかの部分を同時に実行することができる。このようにして、コンテキストモデラ220は、本開示の技法を実施して、マルチコアプロセシング技術および/または複数のプロセッサを活用し、現在コーディングされている変換係数のためのコンテキストモデリング動作を改善することができる。
単一のパスにおいて異なる変換係数の対応するビンを復号することによって、コンテキストモデラ220は、既存のマルチパスCABAC技法を超える1つまたは複数の利点を提供し得る。たとえば、単一のパスにおいて複数の変換係数の対応するビン(たとえば、それぞれのbin0)を復号することによって、コンテキストモデラ220は、ビンの遷移において、新しいコンテキストモデルを頻繁に記憶して取り出す必要をなくすことができる。代わりに、コンテキストモデラ220は、所与のパスの全体で単一のコンテキストモデルを使用することができ、それは、そのパスが複数の変換係数にわたって、対応するビン(たとえば、それぞれのbin0)を対象とするからである。このようにして、コンテキストモデラ220は、本開示の並列化されたコンテキスト選択技法を実施して、頻繁なコンテキスト切替えにより生じる時間遅延およびリソースの混乱を軽減し、または場合によってはなくすことができる。対照的に、既存のマルチパスコーディングは、第1の変換係数のためにbin0、bin1、bin2などを復号し、次いで第2の変換係数のためにbin0、bin1、bin2などを復号することなどが原因で、頻繁なコンテキストモデルの保存と取出しの動作が必要になる。
たとえば、コンテキストモデラ220は、本明細書において説明されるi番目のビンコンテキストモデリング機能のために使用すべき、1つまたは複数の事前に定義されたテンプレートを生成し、またはそうでなければそれを入手し得る。コンテキストモデラ220が現在コーディングされている変換係数のi番目のビンのコンテキストモデリングのために使用し得る、事前に定義されたテンプレートの1つの非限定的な例が、図10に示されている。図10のテンプレート140などの事前に定義されたテンプレートは、8×8の変換ブロックのための対角方向の走査順序を定義し、ここで「L」は最後の有意な走査位置を表し、「x」は現在の走査位置を表し、「xi」はローカルテンプレート140によってカバーされる近隣を表す。xiに関して、「i」という値は0から4の範囲にあり、範囲の制約はi・[0, 4]として表される。本開示の1つまたは複数の態様によれば、コンテキストモデラ220は、現在復号されている変換係数の対応するi番目のビンのコンテキストモデリングのために、ローカルテンプレート140の中に位置する変換係数のi番目のビンを使用し得る。いくつかの実装形態によれば、コンテキストモデラ220は、複数のテンプレートを使用して、本開示の並列化されたビンコンテキストモデリングを実行し得る。一例では、テンプレートのサイズおよび/または形状は、(i)変換単位のサイズ、または(ii)モード、または(iii)現在の変換単位もしくは係数グループ(CG)内での現在の変換係数の位置という基準のうちの1つまたは複数に依存する。
1つまたは複数の事前に定義されたテンプレートを使用してビン値のための以前にコーディングされたTUを横断することによって、コンテキストモデラ220は、本開示の技法を実施して、既存のCABAC技法を超える1つまたは複数の改善をもたらし得る。たとえば、図10のローカルテンプレート140などのTU横断テンプレートを使用することによって、コンテキストモデラ220は、異なる復号パスに関して横断方式を別々に決定する必要をなくすことができる。したがって、本開示のテンプレートベースの並列化されたコンテキスト選択技法を実施することによって、コンテキストモデラ220は、ピクチャの正確さを維持しながら、ビンの復号に関してスループットを向上させることができる。
別の例示的な実装形態によれば、コンテキストモデラ220は、現在コーディングされている変換係数の最初の「K」個のビンだけに、本開示の並列化されたコンテキストモデリング技法を適用することがあり、ここで「K」はMより小さく、Mは利用可能なビンインデックスの上限を表す。コンテキストモデラ220は、別のコンテキストモデリング技法を使用して、またはバイパスモードに従って、残りの(M+1-K)個のビンを復号し得る。
別の例示的な実装形態によれば、コンテキストモデラ220は、現在復号されている変換係数の前の、現在の変換単位またはCG内の復号順序において連続する「N」個の変換係数として、以前にコーディングされた変換係数の世界を定義し得る。代替的に、コンテキストモデラ220は、Nを可変であるものとして決定し得る。一例では、コンテキストモデラ220は、現在の変換単位の中での現在復号されている変換係数の相対的な位置に応じて、Nの値を決定し得る。別の例では、コンテキストモデラ220は、変換単位のサイズに応じてNの値を決定し得る。
別の実装形態では、コンテキストモデラ220は、現在の変換単位またはCG内の現在の位置の近隣に位置する変換係数として、以前に復号された変換係数の世界を定義し得る。一例では、現在の位置の近隣は、現在の位置に直接隣り合う位置、または、現在の位置に直接隣り合うか現在の位置から離れているかのいずれかの位置に制約される。別の例では、近隣は、これらの位置を含み得るが、1つまたは複数の空間的に隣接する変換単位の中の位置を含むように拡大し得る。
本開示の様々な態様によれば、コンテキストモデラ220は、1つまたは複数の以前にコーディングされた変換係数と関連付けられる値の関数として、ビンのコンテキストインデックスを定義し得る。たとえば、コンテキストモデラ220は、以前にコーディングされた変換係数のすべてのi番目のビン値の合計を生む関数を使用し得る。より具体的には、この例では、コンテキストモデラ220は、TU/CGのすべての以前に復号された変換係数の利用可能なi番目のビン値の値の加算を実行し得る。そして、コンテキストモデラ220は、現在コーディングされている変換係数のi番目のビンのためのコンテキストモデリングの間に、コンテキストインデックス(CtIdx)として得られた合計を使用し得る。
本開示のいくつかの態様によれば、コンテキストモデラ220は、異なるサイズの変換単位において、同じパスに対してはコンテキストインデックスの導出規則が変更されないままにすることができる。しかしながら、コンテキストモデラ220は、オフセットをコンテキストインデックスに適用して、現在コーディングされているビンのためのコンテキストモデリングを実行することができる。たとえば、コンテキストモデラ220は、2つの異なる変換サイズがコンテキストモデルの2つの集合を有すると決定し得る。そして、コンテキストモデラ220は、1つのそのような集合の中のコンテキストモデルの数として、オフセットを定義し得る。たとえば、TUサイズが事前に定義された次元M×Mの正方形より小さいとコンテキストモデラ220が決定する場合、コンテキストモデラ220は、各々のそのようなTU(M×Mより小さい)のサイズがコンテキストモデルの固有のそれぞれの集合を有すると決定し得る。逆に、エントロピー復号ユニット70は、M×M以上のサイズを有するすべてのTUがコンテキストモデルの同じ集合を有すると決定し得る。
様々な使用事例の状況において、コンテキストモデラ220は、Mの値を16に設定し得る。より具体的には、これらの例では、現在コーディングされているTUのサイズが16×16の正方形より小さいとコンテキストモデラ220が決定する場合、コンテキストモデラ220は、現在コーディングされているTUがTUの特定のサイズに対応するコンテキストモデルの集合と関連付けられると決定し得る。逆に、現在コーディングされているTUが16×16以上のサイズを有するとエントロピー復号ユニット70が決定する場合、コンテキストモデラ220は、現在コーディングされているTUが、16×16以上のサイズを有するすべての他のTUとコンテキストモデルの同じ集合を共有すると決定し得る。いくつかの例では、コンテキストモデラ220は、TUサイズベースのコンテキストの選択を、ルーマブロックにのみ適用し得る。
本開示のいくつかの態様によれば、コンテキストモデラ220は、変換サイズに基づいて係数グループ(CG)サイズを決定し得る。言い換えると、これらの態様によれば、CGサイズは変換サイズに依存する。代わりに、または加えて、コンテキストモデラ220は、コーディングモードに基づいてCGサイズを決定し得る。これらの例では、コンテキストモデラ220は、変換サイズおよび/またはコーディングモードの一方または両方に依存するものとして、CGサイズを決定し得る。代わりに、または加えて、コンテキストモデラ220は、変換行列に基づいてCGサイズを決定し得る。
本開示のいくつかの態様によれば、コンテキストモデラ220は、変換バイパスモード(「変換スキップモード」とも呼ばれる)を使用して復号されるブロックにも、並列化されたコンテキストモデリング技法を適用し得る。変換バイパスモードは、ビットストリーム218が無損失で復号される場合などにおいてビデオエンコーダ30が復号の逆変換と逆量子化の動作をスキップし得る、コーディングモードを指す。したがって、本開示のいくつかの態様によれば、コンテキストモデラ220は、ビットストリーム218が無損失で符号化される事例において利益をもたらす可能性を与えるように、並列化されたコンテキスト選択技法を拡大し得る。
図8は、テーブルベースのバイナリ算術コーディングの例示的なプロセス150を示すフローチャートである。すなわち、図8は、通常コーディングモードを使用した単一のビン値(binVal)のための確率推定の更新プロセス(ステップ158および160についての灰色の影付きのボックスの中の)を含む、バイナリ算術符号化プロセスを示す。具体的には、図8のプロセス150は、通常コーディングモードを使用した所与のビン値binValのための、バイナリ算術符号化プロセスを示す。算術符号化エンジンの内部状態は、現在の間隔範囲Rおよび現在のコード間隔の基部(下端)Lという、2つの量によって特徴付けられる。しかしながら、(通常モードとバイパスモードの両方において)CABACエンジンにこれらのレジスタを記憶するために必要な精度は、それぞれ9ビットおよび10ビットまで低減され得る。確率状態インデックスσおよびMPSの値(σ%2)を有するコンテキストにおいて観測される所与のバイナリ値binValの符号化は、次のように4つの基本的なステップの列において実行される。
プロセス150はステップ152において開始することができ、ステップ152において、ビデオコーディングデバイスは、所与の確率推定に従って現在の間隔を細分する。この間隔細分プロセスは、プロセス150のステップ152において示されるような3つの基本的な動作を伴う。まず、現在の間隔範囲Rは、4つのセルへの全体の範囲28≦R≦29の等分を使用して、量子化された値Q(R)によって近似される。しかし、対応する代表的な量子化された範囲値Q0、Q1、Q2、およびQ3をCABACエンジンにおいて明示的に使用する代わりに、Rは量子化器インデックスpによってアドレス指定されるだけであり、pはシフト演算とビットマスキング演算の組合せによって効率的に計算されることが可能であり、すなわち、
p = (R >> 6) & 3 (4.5)
次いで、このインデックスpおよび確率状態インデックスσは、図8に示されるように、2次元テーブルTabRangeLPSの中のエントリとして、(概略的な)LPS関連の部分間隔範囲RLPSを決定するために使用される。ここで、テーブルTabRangeLPSは、8ビット精度では、0≦(δ>> 1)≦63および0≦ρ≦3に対するpσ・Qρのすべての64×4個の事前に計算された積の値を含む。MPSの二重の部分間隔範囲を仮定すると、所与のビン値binValに対応する部分間隔は、プロセス150の判断ブロック94において選ばれる。binValがMPS値に等しい場合(判断ブロック154のNOの分岐)、ビデオコーディングデバイスは下側の部分間隔を選び得るので、Lは変更されない。そうではない場合(判断ブロック154のYESの分岐)、ビデオコーディングデバイスは、RLPSに等しい範囲を有する上側の部分間隔を選択し得る(156)。
ステップ158および160において、確率状態の更新は、ITU-T H.264、1.2.2.2項に記載されるように実行される(灰色の影付きのボックスを使用して示されている)。ステップ162は、レジスタLおよびRの再正規化(図1の「RenormE」ボックス)からなる。ステップ164は、プロセス150の終了を表す。
2次元テーブルTabRangeLPSは次のように定義される。
TabRangeLPS[64][4] =
{
{ 128, 176, 208, 240},
{ 128, 167, 197, 227},
{ 128, 158, 187, 216},
{ 123, 150, 178, 205},
{ 116, 142, 169, 195},
{ 111, 135, 160, 185},
{ 105, 128, 152, 175},
{ 100, 122, 144, 166},
{ 95, 116, 137, 158},
{ 90, 110, 130, 150},
{ 85, 104, 123, 142},
{ 81, 99, 117, 135},
{ 77, 94, 111, 128},
{ 73, 89, 105, 122},
{ 69, 85, 100, 116},
{ 66, 80, 95, 110},
{ 62, 76, 90, 104},
{ 59, 72, 86, 99},
{ 56, 69, 81, 94},
{ 53, 65, 77, 89},
{ 51, 62, 73, 85},
{ 48, 59, 69, 80},
{ 46, 56, 66, 76},
{ 43, 53, 63, 72},
{ 41, 50, 59, 69},
{ 39, 48, 56, 65},
{ 37, 45, 54, 62},
{ 35, 43, 51, 59},
{ 33, 41, 48, 56},
{ 32, 39, 46, 53},
{ 30, 37, 43, 50},
{ 29, 35, 41, 48},
{ 27, 33, 39, 45},
{ 26, 31, 37, 43},
{ 24, 30, 35, 41},
{ 23, 28, 33, 39},
{ 22, 27, 32, 37},
{ 21, 26, 30, 35},
{ 20, 24, 29, 33},
{ 19, 23, 27, 31},
{ 18, 22, 26, 30},
{ 17, 21, 25, 28},
{ 16, 20, 23, 27},
{ 15, 19, 22, 25},
{ 14, 18, 21, 24},
{ 14, 17, 20, 23},
{ 13, 16, 19, 22},
{ 12, 15, 18, 21},
{ 12, 14, 17, 20},
{ 11, 14, 16, 19},
{ 11, 13, 15, 18},
{ 10, 12, 15, 17},
{ 10, 12, 14, 16},
{ 9, 11, 13, 15},
{ 9, 11, 12, 14},
{ 8, 10, 12, 14},
{ 8, 9, 11, 13},
{ 7, 9, 11, 12},
{ 7, 9, 10, 12},
{ 7, 8, 10, 11},
{ 6, 8, 9, 11},
{ 6, 7, 9, 10},
{ 6, 7, 8, 9},
{ 2, 2, 2, 2}
};
復号プロセスは、HEVC規格のセクション9.3.4.3.2.2に記載されている。
図9は、残差4分木構造に基づく変換方式を示す概念図である。残差ブロックの様々な特性に適合するために、残差4分木(RQT)を使用する変換コーディング構造が、HEVCにおいて適用される。残差4分木構造は以下で説明される。追加の詳細は、www.hhi.fraunhofer.de/fields-of-competence/image-processing/researchgroups/image-video-coding/hevc-high-efficiency-video-coding/transform-coding-using-the-residual-quadtree-rqt.htmlに記載されており、そこで入手可能である。
図9に示される残差4分木構造によれば、各ピクチャはコーディングツリー単位(CTU)に分割される。ピクチャのCTUは、特定のタイルまたはスライスのためのラスター走査順序でコーディング(たとえば、符号化および/または復号)される。CTUは、正方形のブロックであり、4分木すなわちコーディングツリーのルートを表す。CTUサイズは8×8から64×64にわたることがあり、幅および長さはルーマサンプルの単位で表される。64×64の次元が、HEVC準拠のコーディングデバイスによって一般に使用される。各CTUは、コーディング単位(CU)と呼ばれるより小さい正方形のブロックにさらに分割され得る。CTUがCUに(場合によっては再帰的に)分割された後で、各CUは、予測単位(PU)および変換単位(TU)にさらに分割される。PUおよびCUも正方形のフォームファクタを有する。TUへのCUの区分は、4分木の手法に基づいて再帰的に行われる。したがって、各CUの残差信号は、木構造、すなわち残差4分木(RQT)を使用してコーディングされる。RQTは、4×4から32×32までのTUサイズ(ルーマサンプルの単位で正方形の次元として表される)を許容する。
図9は、CUが10個のTUを含む例を示す。TUは文字aからjによりラベリングされており、各TUラベルは対応するブロック区分の内側に示されている。RQTの各ノードは変換単位(TU)である。個々のTUは、深度第一の木横断順序で処理される。図9に関する深度第一の木横断の結果が、アルファベットの順序に従って図9に示されている。より具体的には、図9は、深度第一の横断を用いた再帰的なZ走査の例を示す。図9に示される4分木手法は、残差信号の変化する空間周波数特性に対する変換の適応を可能にする。
多くの例では、より大きい空間をサポートするより大きい変換ブロックサイズは、より良い周波数分解能を提供する。しかしながら、より小さい空間をサポートするより小さい変換ブロックサイズは、より良い空間分解能を提供する。これらの2つ(空間分解能および周波数分解能)のトレードオフは、エンコーダモードの決断として選択される。たとえば、エンコーダモードの決断は、レート歪み(RD)最適化技法に基づき得る。レート歪み最適化技法は、コーディングビットの加重和と再構築歪みとを計算する。たとえば、モード選択ユニット40は、モード選択の決断を、各コーディングモードに対するレート歪みコストに基づいたものにし得る。いくつかの例では、各々の利用可能なモードに対するレート歪みコストは、各コーディングモードと関連付けられる特定のRQT分割構造に相関し得る。RDコストベースの決断方式では、モード選択ユニットは、最良の利用可能なモードとして、最低の(または最小の)レート歪みコストを有するコーディングモードを選択し得る。
3つのパラメータが、RQT区分方式において定義される。パラメータは、木の最大深度、最小の許容される変換サイズ、および最大の許容される変換サイズである。HEVCのいくつかの態様によれば、最小変換サイズおよび最大変換サイズは、4×4のサンプルから32×32のサンプルまでの範囲内で変化することができる。4×4のサンプルから32×32のサンプルまでの範囲は、上で論じられたサポートされるブロック変換に対応する。RQTの最大の許容される深度は、RQT区分方式が生み出すことができるTUの数を制限または制約する。0と等しい最大深度は、各々の含まれるTUが最大の許容される変換サイズ、たとえば32×32に達した場合に、CTUがそれ以上分解され得ないことを意味する。
上で論じられたパラメータのすべてが相互作用し(たとえば、相乗的に使用され)、RQT構造に影響する。ルートCTUサイズが64×64であり、最大深度が0と等しく、最大変換サイズが32×32と等しい、使用事例の状況が以下で説明される。この場合、ビデオコーディングデバイスは、少なくとも一度CTUを区分する必要がある。CTUが区分されない場合、RQTは3つのパラメータごとに64×64のTUを生み出し、これは許容されない。ビデオエンコーダ20は、シーケンスパラメータセット(SPS)レベルで、ビットストリームにRQTパラメータ(最大RQT深度ならびに最小および最大の変換サイズに限定されないがそれらを含む)を含め得る。ビデオエンコーダ20は、イントラコーディングされたCUおよびインターコーディングされたCUに関して、RQT深度の異なる値を指定してシグナリングし得る。そして、ビデオデコーダ30は、受信されたビットストリームからRQTパラメータを復元し、シグナリングされたパラメータにおいて指定される制約を使用してRQT区分を実行し得る。
ビデオエンコーダ20および/またはビデオデコーダ30は、イントラ残差ブロックとインター残差ブロックの両方のために4分木変換を適用し得る。多くの例では、ビデオエンコーダ20および/またはビデオデコーダ30は、現在の残差4分木区分の同一のサイズのDCT-II変換を、残差ブロックのために適用し得る。しかしながら、現在の残差4分木ブロックが4×4であり、イントラ予測によって生成される場合、ビデオエンコーダ20および/またはビデオデコーダ30は、上で説明された4×4のDST-VII変換を適用し得る。HEVCにおいて、より大きいサイズの変換、たとえば64×64の変換は、主に利点が限られていることと、相対的により解像度が低いビデオに対して複雑さが相対的に大きいこととが原因で、採用されない。
図10は、本明細書において説明されるコンテキストモデリング技法に関してビデオコーディングデバイスが使用し得る例示的なテンプレート(ローカルテンプレート140)を示す概念図である。現在の変換係数は「X」としてマークされ、5つの空間的な近隣は「Xi」としてマークされる(iは0から4の整数を表す)。条件のセットのいずれか1つが満たされる場合、ビデオコーディングデバイスは、コンテキストインデックスの導出プロセスにおいて利用不可能であり使用されないものとしてXiをマークし得る。条件のセットの中の第1の条件は、Xiの位置および現在の変換係数Xが同じ変換単位の中に位置しないというものである。条件のセットの中の第2の条件は、Xiの位置がピクチャの水平方向または垂直方向の境界の外側に位置するというものである。条件のセットの中の第3の条件は、変換係数Xiがまだコーディングされていないということである。マルチパスコーディングの場合、同じコーディングパスにおけるビンがコーディングされるときはいつでも、それらのビンがコンテキストインデックスの導出プロセスにおいて使用され得る。したがって、復号の観点からは、1つの変換係数を完全に復号することは必要ではない。
図11は、係数グループに基づく例示的な係数走査を示す概念図である。TUサイズとは無関係に、変換単位の残差は、重複しない係数グループ(CG)を用いてコーディングされ、各々がTUの4×4ブロックの係数を含む。たとえば、32×32のTUは、合計で64個のCGを有し、16×16のTUは、合計16個のCGを有する。TUの内部のCGは、ある事前に定義された走査順序に従ってコーディングされ得る。各CGをコーディングするときに、現在のCGの内部の係数は、4×4のブロックのある事前に定義された走査順序に従って走査され、コーディングされる。図11は、4個のCGを含む8×8のTUのための係数走査を示す。
シンタックス要素テーブルは次のように定義される。
色成分ごとに、ビデオエンコーダ20はまず、現在のTUが少なくとも1つの0ではない係数を有するかどうかを示すために、1つのフラグをシグナリングし得る。現在のTUの中に少なくとも1つの0ではない係数がある場合、ビデオエンコーダ20は、変換単位の左上の角に対する相対的な座標を用いて、TUの中の係数走査順序において最後の有意な係数の位置を明示的に符号化し得る。座標の垂直成分または水平成分は、そのプレフィックスおよびサフィックスによって表され、ここで、プレフィックスは切捨てライス(TR:truncated rice)を用いてバイナリ化され、サフィックスは固定長を用いてバイナリ化される。
セマンティクス
last_sig_coeff_x_prefixは、変換ブロック内の走査順序において最後の有意な係数の列の位置のプレフィックスを指定する。last_sig_coeff_x_prefixの値は、両端を含めて0から(log2TrafoSize << 1) - 1までの範囲内にある必要がある。
last_sig_coeff_y_prefixは、変換ブロック内の走査順序において最後の有意な係数の行の位置のプレフィックスを指定する。last_sig_coeff_y_prefixの値は、両端を含めて0から(log2TrafoSize << 1) - 1までの範囲内にある必要がある。
last_sig_coeff_x_suffixは、変換ブロック内の走査順序において最後の有意な係数の列の位置のサフィックスを指定する。last_sig_coeff_x_suffixの値は、両端を含めて0から(1 << ((last_sig_coeff_x_prefix >> 1) - 1)) - 1までの範囲内にある必要がある。
変換ブロック内の走査順序において最後の有意な係数の列の位置LastSignificantCoeffXは、次のように導出される。
- last_sig_coeff_x_suffixが存在しない場合には、次があてはまる。
LastSignificantCoeffX = last_sig_coeff_x_prefix
- そうではない(last_sig_coeff_x_suffixが存在する)場合には、次があてはまる。
LastSignificantCoeffX = (1 << ((last_sig_coeff_x_prefix >> 1) - 1)) * (2 + (last_sig_coeff_x_prefix & 1)) + last_sig_coeff_x_suffix
last_sig_coeff_y_suffixは、変換ブロック内の走査順序において最後の有意な係数の行の位置のサフィックスを指定する。last_sig_coeff_y_suffixの値は、両端を含めて0から(1 << ((last_sig_coeff_y_prefix >> 1) - 1)) - 1までの範囲内にある必要がある。
変換ブロック内の走査順序において最後の有意な係数の行の位置LastSignificantCoeffYは、次のように導出される。
- last_sig_coeff_y_suffixが存在しない場合には、次があてはまる。
LastSignificantCoeffY = last_sig_coeff_y_prefix
- そうではない(last_sig_coeff_y_suffixが存在する)場合には、次があてはまる。
LastSignificantCoeffY = (1 << ((last_sig_coeff_y_prefix >> 1) - 1)) * (2 + (last_sig_coeff_y_prefix & 1)) + last_sig_coeff_y_suffix
scanIdxが2と等しいとき、座標は次のように交換される。
(LastSignificantCoeffX, LastSignificantCoeffY)=Swap(LastSignificantCoeffX, LastSignificantCoeffY)
コーディングされたそのような位置およびCGの係数走査順序も用いて、最後のCG (走査順序において)を除くCGが0ではない係数を含むかどうかを示す1つのフラグが、それらのCGのためにさらにシグナリングされる。
CGフラグのコンテキストモデリング。1つのCGが0ではない係数を有するかどうか、すなわちCGフラグ(HEVC規格におけるcoded_sub_block_flag)をコーディングするとき、隣接するCGの情報がコンテキストを構築するために利用される。より具体的には、CGフラグをコーディングするためのコンテキストの選択が次のように定義される。
(右CG利用可能&&右CGのフラグが1に等しい)||(下CG利用可能&&下CGのフラグが1に等しい)
ここで、右および下のCGは、現在のCGに近い2つの隣接するCGである。たとえば、図11では、左上の4×4のブロックを符号化するとき、ビデオエンコーダ20は、右のCGを右上の4×4のブロックとして定義することができ、下のCGが左下の4×4のブロックとして定義される。クロマおよびルーマは、コンテキストモデルの様々な集合を、ただし様々な集合のうちの1つを選択するための同じ規則とともに、使用する。コンテキストインデックスのインクリメントの導出の詳細は、HEVCの9.3.4.2.4において見出され得る。
1つのCG内での変換係数コーディング: 0ではない係数を含み得るCGに対して、ビデオエンコーダ20はさらに、事前に定義された4×4の係数走査順序に従って、各係数に対して、有意性フラグ(significant_flag)、係数の絶対値(coeff_abs_level_greater1_flag、coeff_abs_level_greater2_flag、およびcoeff_abs_level_remainingを含む)、および符号情報(coeff_sign_flag)を符号化する(かつビデオデコーダ30はそれらをさらに復号する)ことができる。変換係数レベルのコーディング(たとえば、符号化および/または復号)は、複数の走査パスに分離される。
第1のビンのコーディングの第1のパス:このパスにおいて、1つのCG内の各位置における変換係数のすべての第1のビン(またはビンインデックス0、bin0)が、特定の変換係数が0に等しいことが導かれ得ることを除き、コーディングされる。変数sigCtxは、現在のTUの左上の位置に対する現在の位置、色成分インデックスcIdx、変換ブロックサイズ、およびシンタックス要素coded_sub_block_flagの以前に復号されたビンに依存する。異なる規則がTUサイズに応じて適用される。コンテキストインデックスのインクリメントの選択の例示的な詳細がHEVCの9.3.4.2.5において定義される。
第2のビンのコーディングの第2のパス:coeff_abs_level_greater1_flagsのコーディングがこのパスにおいて適用される。コンテキストモデリングは、色成分インデックス、現在のサブブロック走査インデックス、および現在のサブブロック内の現在の係数走査インデックスに依存する。コンテキストインデックスのインクリメントの選択の例示的な詳細がHEVCの9.3.4.2.6において定義される。
第3のビンのコーディングの第3のパス:coeff_abs_level_greater2_flagsのコーディングがこのパスにおいて適用される。コンテキストモデリングは、coeff_abs_level_greater1_flagsによって使用されるものと同様である。コンテキストインデックスのインクリメントの選択の例示的な詳細がHEVCの9.3.4.2.7において定義される。スループットを改善するために、第2および第3のパスはCGの中のすべての係数を処理しないことがある。CGの中の最初の8個のcoeff_abs_level_greater1_flagsは、通常モードでコーディングされる。その後、値は、シンタックスcoeff_abs_level_remainingによって第5のパスにおいてバイパスモードでコーディングされるままにされる。同様に、1より大きい大きさを有するCGの中の第1の係数に対するcoeff_abs_level_greater2_flagsだけがコーディングされる。CGの1より大きい大きさを有する係数の残りは、coeff_abs_level_remainingを使用して値をコーディングする。この方法は、係数レベルに対する通常のビンの数を、CGごとに9個という最大値、すなわちcoeff_abs_level_greater1_flagsに対して8個およびcoeff_abs_level_greater2_flagsに対して1個に限定する。
符号情報の第4のパス:HEVCのいくつかの例では、各々の0ではない係数の符号は、バイパスモードで第4の走査パスにおいてコーディングされる。各CGに対して、基準に応じて、(逆方向の走査順序において)最後の0ではない係数の符号を符号化することは、符号データ隠匿(SDH:sign data hidding)を使用するときには単純に省略される。代わりに、符号の値は、事前に定義された取り決めを使用してCGのレベルの合計のパリティに埋め込まれ、すなわち偶数は「+」に対応し奇数は「-」に対応する。SDHを使用するための基準は、CGの最初の0ではない係数と最後の0ではない係数との間の走査順序における距離である。この距離が4以上である場合、SDHが使用される。4という値は、HEVCテストシーケンスに対して最大の利得をもたらすので、選ばれた。
残りのビンの最後のパス:残りのビンはさらなる走査パスにおいてコーディングされる。係数のbaseLevelが次のように定義されるようにする。
baseLevel = significant_flag + coeff_abs_level_greater1_flag+ coeff_abs_level_greater2_flag
ここで、フラグは0または1という値を有し、存在しない場合0であると推測される。次いで、係数の絶対値が次のように定義される。
absCoeffLevel = baseLevel + coeff_abs_level_remaining
Riceパラメータは、各CGの初めに0に設定され、パラメータの以前の値および現在の絶対的なレベルに応じて次のように条件的に更新される。
absCoeffLevel > 3×2mである場合、m= min(4,m + 1)
シンタックス要素coeff_abs_level_remainingは、バイパスモードでコーディングされ得る。加えて、HEVCのいくつかの例は、小さい値に対してゴロムライス符号を利用し、より大きい値に対しては指数ゴロム符号に切り替える。コード間の遷移点は通常、単項符号の長さが4に等しいときである。パラメータ更新プロセスは、大きい値が分布において観測されるときに係数の統計にバイナリ化が適合することを可能にする。
inter_pred_idcのコンテキストモデリング。inter_pred_idcは、list0、list1、または双予測が現在の予測単位のために使用されるかどうかを指定する。シンタックス要素は最大で2つのビンを有し、これらの両方がCABACコンテキストコーディングされる。バイナリ化されたビンストリングは次のように定義される。
ここで、nPbWおよびnPbHはそれぞれ、現在のルーマ予測ブロックの幅および高さを表す。
各々のインターコーディングされるスライス、たとえばPスライスまたはBスライスに対して、コンテキスト選択は次の規則に基づく。
合計(nPbW+nPbH)が12に等しくない場合、第1のビンは4つのコンテキストを使用してコーディングされ、第2のビンは1つのコンテキストを用いてコーディングされる。第1のビンのコンテキスト選択は、現在のCU深度に従う。HEVCでは、CU深度は両端を含めて0から3の範囲の中にある。両端を含む0から3の範囲は[0, 3]として表され得る。
JCTVC-H0228(T. Nguyen、D. Marpe、T. Wiegand、「Non-CE11: Proposed Cleanup for Transform Coefficient Coding」、JCTVC-H0228、第8回会合:サンノゼ、カリフォルニア州、米国、2012年2月1日〜10日)において、一走査パスのコーディングが提案された。提案された一走査パスによれば、変換係数レベルについてのすべての情報が、HEVCにおけるような複数パスのコーディングの代わりに、単一のステップにおいてコーディングされる。各走査位置に対して、HEVCの現在の設計においてbin0(ビンストリングの最初のビン、gnificant_coeff_flagまたはcoeff_abs_greater0_flagとも呼ばれる)に対して行われるように、ローカルテンプレートによってカバーされる近隣が評価される。この評価から、残りの絶対値の適応的なバイナリ化を制御するコンテキストモデルおよびRiceパラメータが導出される。より具体的には、bin0、bin1、bin2、およびRiceパラメータのためのコンテキストモデルはすべて、ローカルテンプレートに位置する変換係数の大きさに基づいて選択される(bin1およびbin2はcoeff_abs_greater1_flagおよびcoeff_abs_greater2_flagとも呼ばれる)。
ローカルテンプレート140の例は、対角方向の走査を用いて8×8の変換ブロックに対して図10において与えられ、Lは最後の有意な走査位置を表し、xは現在の走査位置を表し、i∈[0, 4]であるxiはローカルテンプレートによってカバーされる近隣を表す。
近隣の絶対値の合計を示すsum_absolute_level、および各レベルの絶対値の合計から1を引いたものを示すsum_absolute_levelMinus1が、bin0、bin1、bin2のためのコンテキストインデックスを導出するために、およびRiceパラメータrを決定するために使用される。
bin0に対して、ローカルテンプレートの評価から得られるsum_absolute_levelは、5というカットオフ値を有するコンテキストモデルインデックスに直接マッピングされる。同じ規則は、sum_absolute_levelMinus1および4というカットオフ値を使用することによって、bin1およびbin2のコンテキストモデルインデックスの計算に適用される。この導出規則は以下で要約されており、c0はbin0のためのコンテキストモデルインデックスを表し、c1はbin1のためのコンテキストモデルインデックスを表し、c2はbin2のためのコンテキストモデルインデックスを表し、
c0 = min(sum_absolute_level, 5)
c1 = min(sum_absolute_levelMinus1, 4) + 1 (6)
c2 = min(sum_absolute_levelMinus1, 4) + 1
図12は、ビン導出の例を示す概念図である。bin1およびbin2に対する導出規則は同じである。次に、ルーマ成分に対して、追加のオフセットが、ルーマ変換レベルのbin0、bin1、およびbin2に対して計算される。追加のコンテキストインデックス(すなわち、オフセット)は、現在の走査位置の場所に依存する。図12は、このプロセスの例を示す。具体的には、図12は、(a)ルーマbin0に対する、(b)ルーマbin1およびbin2(順方向の走査順序における最後の係数ではない)に対する、1つのTU内の異なる領域のコンテキストインデックス範囲を示す。
まとめると、全体の概念が以下の式に要約され、xは現在の走査位置の変換ブロックの内部の水平方向の空間的な場所を表し、yは垂直方向の空間的な場所を表し、cIdxは0を有する現在の平面タイプがルーマを表すことを表す。加えて、異なる位置に対するコンテキストインデックスの範囲が図13にマークされている。
上で示されたように、c1に対する式はc2に対する式と同じである。bin1およびbin2に対する同じコンテキストモデルインデックスに加えて、bin1およびbin2のコーディングのために同じコンテキストモデルが使用される。さらに、コーディング順序の最初の走査位置(すなわち、最後の有意な走査位置)に対して、bin1およびbin2のために別々のコンテキストモデルが使用される。最初のビンインデックス(bin0)が最後の有意な走査位置のために推測される。この別々のコンテキストモデルは、コンテキストモデル選択方式によって再び選択されることは決してなく、c1=0として割り当てられる。コンテキストモデルの総数は以下のテーブルにおいて集計される。
Riceパラメータrは次のように導出される。各走査位置に対して、このパラメータは0に設定される。次いで、sum_absolute_levelMinus1が閾値の集合tR = {3, 9, 21}と比較される。言い換えると、sum_absolute_levelMinus1が第1の間隔に入る場合、Riceパラメータは0であり、sum_absolute_levelMinus1が第2の間隔に入る場合、1であり、以下同様である。Riceパラメータrの導出は次のように要約される。
図13は、異なるルーマビンに対する、TU内の異なる位置のためのコンテキストインデックスの範囲を示す概念図である。図13の例では、左側のブロックは、ルーマbin0のためのTU内の異なる領域に対するコンテキストインデックス範囲を示す。右側のブロックは、ルーマbin1およびbin2のためのTU内の異なる領域に対するコンテキストインデックス範囲を示す。特定の位置は図13のルーマビン内の数字を使用して呼び出され、異なる領域は影付きを使用して区別される。
1つまたは複数の裏では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せとして実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信されることがあり、かつハードウェアに基づく処理ユニットによって実行されることがある。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は一般に、(1)非一時的である有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示において説明される技法の実施のための命令、コードおよび/もしくはデータ構造を取り出すために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
図14は、ビデオコーディングデバイスまたはその様々な構成要素が、本開示のコンテキストモデリング技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセス300を示す。プロセス300は様々なデバイスによって実行され得るが、本明細書では、プロセス300はビデオデコーダ30に関して説明される。プロセス300は、ビデオデコーダ30が第1のTUをコーディング(たとえば、復号)するときに開始し得る(302)。そして、ビデオデコーダ30は、第2のTUをコーディングする第1のパスを開始し得る(304)。したがって、第1のTUは、第2のTUに関して以前にコーディングされたブロックを表す。
ビデオデコーダ30は、コーディングの第1のパス内で、第1のTUのi番目のビンを使用して第2のTUのすべてのi番目のビンをコーディングし得る(306)。たとえば、ビデオデコーダ30は、第2のTUのためのマルチパス復号プロセスの第1のパスの間に、第1のTUのbin0を使用して、第2のTUのすべての変換係数のそれぞれのi番目のビンのためのコンテキストインデックスを選択し得る。このようにして、ビデオデコーダ30は、以前にコーディングされたブロックのビンを使用して現在コーディングされているTUのすべての変換係数のすべてのi番目のビンのためのコンテキスト選択を完了することによって、本開示のコンテキストモデリング技法を実施して並列化を改善し得る。
このようにして、ビデオデコーダ30は、ビデオデータを記憶するように構成されたメモリと、1つまたは複数のプロセッサとを含む、ビデオコーディングデバイスの例を表す。プロセッサは、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前にコーディングされた変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するように構成され得る。コンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値のi番目のビンのコンテキストを、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用して決定するように構成され、iが非負の整数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンを使用するために、1つまたは複数のプロセッサは、以前にコーディングされた変換係数のシンタックス要素の値のi番目のビンのみを使用し、以前にコーディングされた変換係数のシンタックス要素の値の他のビンを使用しないように構成される。プロセッサはさらに、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディング(たとえば、CABAC復号)するように構成される。
いくつかの例では、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数をCABAC復号するために使用されるべき1つまたは複数の隣接する変換係数を特定するテンプレートを使用して、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを決定するように構成される。いくつかの例では、1つまたは複数のプロセッサはさらに、現在の変換係数を含む変換単位のサイズ、変換単位を含むコーディング単位と関連付けられるコーディングモード、現在の変換係数を含む変換単位における現在の変換係数の位置、または、現在の変換係数を含む係数グループの中での現在の変換係数の位置のうちの少なくとも1つに基づいて、テンプレートのサイズまたは形状のうちの少なくとも1つを決定するように構成される。いくつかの例では、1つまたは複数のプロセッサはさらに、色成分情報に基づいてテンプレートのサイズまたは形状のうちの少なくとも1つを決定するように構成され、色成分情報はルーマ成分情報またはクロマ成分情報の一方または両方を含む。
いくつかの例では、現在の変換係数は変換単位に含まれ、ここで、変換単位の一部またはすべてのビンは通常モードに従ってCABAC符号化され、現在の変換係数のシンタックス要素の値のi番目のビンをCABACコーディングするために、1つまたは複数のプロセッサは、変換単位のすべての変換係数のすべての対応するi番目のビンがCABACコーディングされるi番目のコーディングパスの間に、現在の変換係数のシンタックス要素の値のi番目のビンをコーディングするように構成される。いくつかの例では、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを決定するために、1つまたは複数のプロセッサは、以前にコーディングされた変換係数の関数を使用して、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストインデックスを決定するように構成される。いくつかの例では、以前にコーディングされた変換係数はテンプレートの中に位置する。いくつかの例では、以前にコーディングされた変換係数の関数を使用するために、1つまたは複数のプロセッサは、最初の「M」個の以前にコーディングされた変換係数の関数を使用するように構成され、「M」は非負の値を表す。いくつかの例では、関数は加算関数を備え、以前にコーディングされた変換係数のシンタックス要素の値の対応するi番目のビンは、複数の以前にコーディングされた変換係数のシンタックス要素の値の複数の対応するi番目のビンに含まれる。
いくつかの例では、加算関数を使用して現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストインデックスを決定するために、1つまたは複数のプロセッサは、複数の以前にコーディングされた変換係数のシンタックス要素の値の複数の対応するi番目のビンのすべての合計として、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストインデックスを定義するように構成される。いくつかの例では、1つまたは複数のプロセッサはさらに、加算関数の結果を切り抜いて、事前に定義された範囲内にある切り抜かれた合計を形成するように構成される。別の言い方をすると、1つまたは複数のプロセッサは、加算関数の結果を切り抜くステップを含む方法を実行して、事前に定義された範囲内にある切り抜かれた合計を形成し得る。いくつかの例では、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを決定するために、1つまたは複数のプロセッサは、現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストインデックスを決定し、決定されたコンテキストインデックスにオフセットを加算するように構成される。いくつかの例では、1つまたは複数のプロセッサはさらに、現在の変換係数を含む変換単位のサイズに基づいてオフセットを決定するように構成される。
いくつかの例では、1つまたは複数のプロセッサはさらに、変換単位が閾値のサイズ内であるかどうかを決定し、変換単位が閾値のサイズ内である場合、閾値のサイズ内であるすべての変換単位に共通のコンテキストモデルの集合と変換単位が関連付けられると決定するように構成される。いくつかの例では、閾値のサイズは、16×16という次元と関連付けられる。いくつかの例では、記憶されているビデオデータは符号化されたビデオデータを備え、1つまたは複数のプロセッサはさらに、符号化されたビデオデータの少なくとも一部分を復号して再構築されたビデオデータを形成するように構成され、ビデオデコーダ30は、再構築されたビデオデータの少なくとも一部分を表示するように構成される表示デバイスを含むデバイスを含むことがあり、デバイスであることがあり、またはデバイスの一部であることがある。いくつかの例では、1つまたは複数のプロセッサはさらに、記憶されているビデオデータの少なくとも一部分を符号化するように構成され、以前にコーディングされた変換係数は以前に符号化された変換係数を備える。
図15は、ビデオコーディングデバイスまたはその様々な構成要素が、本開示の継承ベースのコンテキスト初期化技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセス320を示すフローチャートである。プロセス320は様々なデバイスによって実行され得るが、本明細書では、プロセス320はビデオデコーダ30に関して説明される。プロセス320は、ビデオデコーダ30が第1のピクチャをコーディング(たとえば、復号)するときに開始し得る(322)。したがって、第1のピクチャは、ビデオデコーダ30が続いて再構築し得るピクチャに関して、以前にコーディングされた(たとえば、以前に復号された)ピクチャを表す。そして、ビデオデコーダ30は、第2のピクチャの現在のスライスのためのコンテキスト情報をそこから継承すべき、ファーストのブロックを特定し得る(324)。したがって、第2のピクチャは、ビデオデコーダ30が第2のピクチャを現在復号しているという点で「現在のピクチャ」を表すことができ、現在のスライスは、ビデオデコーダ30が復号している第2のピクチャの特定のスライスを表すことができる。
ビデオデコーダ30は、第1のピクチャから継承されたコンテキスト情報を使用して、現在のスライスのためのコンテキスト情報を初期化し得る(326)。たとえば、ビデオデコーダ30は、継承されたコンテキスト情報の1つまたは複数のステータスを記憶し、記憶されたステータスを取り出して現在のスライスのためのコンテキストを初期化し得る。そして、ビデオデコーダ30は、初期化されたコンテキスト情報を使用して現在のスライスをコーディングし得る(328)。
このようにして、ビデオデコーダ30は、ビデオデータを記憶するように構成されたメモリと、1つまたは複数のプロセッサとを含む、ビデオコーディングデバイスの例を表す。プロセッサは、記憶されているビデオデータの以前にコーディングされたスライスの以前にコーディングされたブロックをコーディングした後のコンテキスト情報を現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として継承することによって、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化し、初期化されたコンテキスト情報を使用して現在のスライスのデータをコーディングするように構成される。いくつかの例では、以前にコーディングされたブロックは、以前にコーディングされたスライス内の中心の位置、または以前にコーディングされたスライスと関連付けられる以前にコーディングされたピクチャ内の中心の位置にある、最大コーディング単位(LCU)を含む。いくつかの例では、現在のスライスは単方向予測されたスライス(P-slice)を含み、以前にコーディングされたスライスは双方向予測されたスライス(B-slice)を含む。いくつかの例では、現在のスライスは双方向予測されたスライス(B-slice)を含み、以前にコーディングされたスライスは単方向予測されたスライス(P-slice)を含む。
いくつかの例では、現在のスライスは、コンテキスト情報が以前にコーディングされたピクチャから継承される現在のピクチャの中の複数のスライスに含まれ、プロセッサはさらに、以前にコーディングされたスライス内の中心の位置にあるLCUをコーディングした後のコンテキスト情報を継承することによって、複数のスライスのすべてのためのそれぞれのコンテキスト情報を初期化するように構成される。いくつかの例では、プロセッサはさらに、現在のスライスがインターコーディングされるかどうかを決定し、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するように構成され、プロセッサは、現在のスライスがインターコーディングされるという決定に基づいて、現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として以前にコーディングされたブロックをコーディングした後で、コンテキスト情報を継承するように構成される。
いくつかの例では、プロセッサは、以前にコーディングされたスライスがインターコーディングされるかどうかを決定するように構成される。いくつかの例では、プロセッサはさらに、現在のスライスおよび以前にコーディングされたブロックが同じ量子化パラメータ(QP)を共有するかどうかを決定し、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するように構成され、プロセッサは、現在のスライスおよび以前にコーディングされたスライスが同じQPを共有するという決定に基づいて、現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として、以前にコーディングされたブロックをコーディングした後のコンテキスト情報を継承するように構成される。いくつかの例では、プロセッサはさらに、イントラランダムアクセスピクチャ(IRAP)が、出力順序において、現在のピクチャと、以前にコーディングされたスライスと関連付けられる以前にコーディングされたピクチャとの間に位置するかどうかを決定するように構成される。
いくつかの例では、現在のピクチャの現在のスライスのためのコンテキスト情報を初期化するために、プロセッサは、出力順序において現在のピクチャと以前にコーディングされたピクチャとの間にIRAPが位置しないという決定に基づいて、現在のピクチャの現在のスライスのための初期化されたコンテキスト情報として、以前にコーディングされたピクチャの以前にコーディングされたブロックのコンテキスト情報を継承するように構成される。いくつかの例では、プロセッサはさらに、TargetCUAddr = (PicWidthInCtbsY* PicHeightInCtbsY)/2 + PicWidthInCtbsY/2という式に従って以前にコーディングされたブロックの位置を定義するように構成され、ここで「PicWidthInCtbsY」は以前にコーディングされたブロックの単一の行に含まれる最大コーディング単位(LCU)の数を表し、「PicHeightInCtbsY」は以前にコーディングされたブロックに含まれるLCU行の総数を表す。いくつかの例では、コンテキスト情報は、現在のスライスと関連付けられる1つまたは複数のコンテキスト状態を含む。
いくつかの例では、コンテキスト情報はさらに、最確状態(MPS)情報と関連付けられる値を含む。いくつかの例では、以前にコーディングされたブロックをコーディングした後のコンテキスト情報を継承することによって、現在のスライスのためのコンテキスト情報を初期化するために、プロセッサは、以前にコーディングされたブロックをコーディングした後のコンテキスト情報を継承することによって、現在のスライスのためのコンテキスト情報のすべてではないが一部を初期化するように構成される。いくつかの例では、以前にコーディングされたスライスは、(i)以前にコーディングされたスライスが現在のスライスとは異なる場合、現在のピクチャの中のスライス、または(ii)以前にコーディングされたピクチャの中のスライスのうちの1つを含む。いくつかの例では、プロセッサはさらに、現在のピクチャと同じ量子化パラメータ(QP)およびスライスタイプを共有する以前にコーディングされたピクチャを、出力順序において現在のピクチャの前の最後のピクチャとして特定することによって、以前にコーディングされたピクチャを選択するように構成される。いくつかの例では、記憶されているビデオデータは符号化されたビデオデータを含み、プロセッサはさらに、符号化されたビデオデータの少なくとも一部分を復号して再構築されたビデオデータを形成するように構成され、ビデオコーディングデバイスはさらに、再構築されたビデオデータの少なくとも一部分を表示するように構成される表示デバイスを含む。
図16は、ビデオコーディングデバイスまたはその様々な構成要素が、ビデオ復号プロセスの一部として本開示の技法のうちの1つまたは複数を実施するために実行し得る、例示的なプロセス330を示すフローチャートである。プロセス330は様々なデバイスによって実行され得るが、本明細書では、プロセス330はビデオデコーダ30に関して説明される。プロセス330は、ビデオデコーダ30が現在のブロックのためのエントロピー符号化されたデータを受信するときに開始し得る(332)。加えて、ビデオデコーダ30は、現在のブロックの変換係数のためのエントロピー符号化されたデータを取り出し得る(334)。
そして、ビデオデコーダ30は、現在のブロックの変換係数のための符号化されたデータをエントロピー復号し得る(336)。たとえば、変換係数をエントロピー復号するために、ビデオデコーダ30は、以前に復号された変換係数のビンを使用して、現在の変換係数の対応する現在のビンのためのコンテキスト情報を決定し得る(336)。ビデオデコーダ30は(たとえば、逆変換ユニット78を呼び出すことによって)、逆変換を変換係数に適用して残差ブロックを形成し得る(338)。そして、ビデオデコーダ30は、現在のブロックを予測して予測されたブロックを形成し得る(340)。ビデオデコーダ30は、予測されたブロックを残差ブロックと組み合わせて、現在のブロックを復号し得る(342)。
図17は、ビデオコーディングデバイスまたはその様々な構成要素が、本開示の1つまたは複数の係数グループ(CG)サイズ決定技法を実施するために実行し得る、例示的なプロセス350を示すフローチャートである。プロセス320は様々なデバイスによって実行され得るが、本明細書では、プロセス350はビデオデコーダ30に関して説明される。プロセス350は、ビデオデコーダ30が変換単位(TU)を特定するときに開始し得る(352)。たとえば、ビデオデコーダ30は、現在復号されているTUなどの、現在のTUを特定し得る。加えて、ビデオデコーダ30は、現在のTUを含む係数グループを特定することができ、ここで係数グループは現在のTUの変換係数の部分集合を表す(354)。ビデオデコーダ30は、変換単位と関連付けられる変換サイズと、(i)変換単位と関連付けられるコーディングモード、または(ii)変換単位と関連付けられる変換行列の一方または両方との組合せに基づいて、CGのサイズを決定し得る(356)。
このようにして、ビデオデコーダ30は、ビデオデータを記憶するように構成されたメモリデバイスと、1つまたは複数のプロセッサとを含む、ビデオコーディングデバイスの例を表す。プロセッサは、ビデオデータの現在の変換係数を含む係数グループ(CG)を特定し、ここでCGは変換単位内の変換係数の部分集合を表し、変換単位と関連付けられる変換サイズに基づいてCGのサイズを決定するように構成される。いくつかの例では、プロセッサは、変換単位と関連付けられる変換サイズと、(i)変換単位と関連付けられるコーディングモード、または(ii)変換単位と関連付けられる変換行列の一方または両方との組合せに基づいて、CGのサイズを決定し得る。いくつかの例では、記憶されているビデオデータは符号化されたビデオデータを備え、1つまたは複数のプロセッサは、符号化されたビデオデータの少なくとも一部分を復号して復号されたビデオデータを形成するように構成される。いくつかの例では、記憶されているビデオデータは符号化されたビデオデータを備え、1つまたは複数のプロセッサは、符号化されたビデオデータの少なくとも一部分を復号して復号されたビデオデータを形成するように構成される。
いくつかの例では、変換単位は符号化された変換単位を備え、変換単位と関連付けられるコーディングモードは、符号化された変換単位を形成するために使用されるコーディングモードを備える。いくつかの例では、ビデオデコーダ30は、復号されたビデオデータの少なくとも一部分を表示するように構成されるディスプレイを備える、デバイスを含むことがあり、デバイスであることがあり、またはデバイスの一部であることがある。いくつかの例では、1つまたは複数のプロセッサはさらに、現在の変換係数のシンタックス要素の値の複数のビンの各々に対して、1つまたは複数の以前に復号された変換係数のシンタックス要素の値のそれぞれの対応するビンを使用してコンテキストを決定するように構成され得る。いくつかの例では、コンテキストを決定するために、1つまたは複数のプロセッサは、以前に復号された変換係数のシンタックス要素の値の対応するi番目のビンを使用して現在の変換係数のシンタックス要素の値のi番目のビンのためのコンテキストを決定するように構成され、iは非負の整数を備える。いくつかの例では、以前に復号された変換係数のシンタックス要素の値の対応するi番目のビンを使用するために、プロセッサは、以前に復号された変換係数のシンタックス要素の値のi番目のビンだけを使用し、以前に復号された変換係数のシンタックス要素の値の他のビンを使用しない。いくつかのそのような例では、プロセッサは、決定されたコンテキストを使用して、現在の変換係数のシンタックス要素の値のi番目のビンをコンテキスト適応バイナリ算術コーディング(CABAC)復号し得る。いくつかの例では、CGはブロックの正方形の領域を備え、CGのサイズはブロックの単位で表すと4×4である。
いくつかの例では、コーディングモードは、CGベースのコーディングモードを備える。いくつかの例では、ビデオデコーダ30は、1つまたは複数の集積回路、1つまたは複数のデジタル信号プロセッサ(DSP)、1つまたは複数のフィールドプログラマブルゲートアレイ(FPGA)、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、電話、テレビジョン、カメラ、表示デバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオゲームデバイス、ビデオストリーミングデバイス、またはワイヤレス通信デバイスのうちの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 例
102 例
118 シンタックス要素
120 バイナライザ
122 コンテキストモデラ
124 通常符号化エンジン
126 バイパス符号化エンジン
140 テンプレート
150 プロセス
218 ビットストリーム
220 コンテキストモデラ
222 バイパス復号エンジン
224 通常復号エンジン
230 逆バイナライザ
300 プロセス
320 プロセス
330 プロセス
350 プロセス

Claims (20)

  1. ビデオデータを処理する方法であって、
    現在の変換係数を含む係数グループ(CG)を特定するステップであって、前記CGが変換単位内の変換係数の部分集合を表す、ステップと、
    前記変換単位と関連付けられる変換サイズに基づいて前記CGのサイズを決定するステップとを備える、方法。
  2. 前記変換サイズに基づいて前記CGの前記サイズを決定するステップが、前記変換単位と関連付けられる前記変換サイズと、(i)前記変換単位と関連付けられるコーディングモード、または(ii)前記変換単位と関連付けられる変換行列の一方または両方との組合せに基づいて、前記CGの前記サイズを決定するステップを備える、請求項1に記載の方法。
  3. 前記ビデオデータを処理するステップが、前記ビデオデータの少なくとも一部分を復号するステップを備える、請求項1に記載の方法。
  4. 前記ビデオデータが符号化されたビデオデータを備え、前記変換単位が符号化された変換単位を備え、前記変換単位と関連付けられる前記コーディングモードが、前記符号化された変換単位を形成するために使用されるコーディングモードを備える、請求項3に記載の方法。
  5. 前記ビデオデータを処理するステップが、前記ビデオデータの少なくとも一部分を符号化するステップを備える、請求項1に記載の方法。
  6. 前記コーディングモードが、前記変換単位を符号化するために選択されるコーディングモードを備える、請求項5に記載の方法。
  7. 前記CGがブロックの正方形の領域を備え、前記CGの前記サイズがブロックの単位で表すと4×4である、請求項1に記載の方法。
  8. 前記コーディングモードがCGベースのコーディングモードを備える、請求項1に記載の方法。
  9. ビデオコーディングデバイスであって、
    ビデオデータを記憶するように構成されるメモリデバイスと、
    1つまたは複数のプロセッサとを備え、前記1つまたは複数のプロセッサが、
    前記ビデオデータの現在の変換係数を含む係数グループ(CG)を特定し、前記CGが変換単位内の変換係数の部分集合を表し、
    前記変換単位と関連付けられる変換サイズに基づいて前記CGのサイズを決定する
    ように構成される、ビデオコーディングデバイス。
  10. 前記変換単位と関連付けられる前記変換サイズに基づいて前記CGの前記サイズを決定するために、前記1つまたは複数のプロセッサが、前記変換単位と関連付けられる前記変換サイズと、(i)前記変換単位と関連付けられるコーディングモード、または(ii)前記変換単位と関連付けられる変換行列の一方または両方との組合せに基づいて、前記CGの前記サイズを決定するように構成される、請求項9に記載のビデオコーディングデバイス。
  11. 前記記憶されたビデオデータが符号化されたビデオデータを備え、
    前記1つまたは複数のプロセッサが、前記符号化されたビデオデータの少なくとも一部分を復号して復号されたビデオデータを形成するように構成される、請求項9に記載のビデオコーディングデバイス。
  12. 前記変換単位が符号化された変換単位を備え、前記変換単位と関連付けられる前記コーディングモードが、前記符号化された変換単位を形成するために使用されるコーディングモードを備える、請求項11に記載のビデオコーディングデバイス。
  13. 前記復号されたビデオデータの少なくとも一部分を表示するように構成されるディスプレイをさらに備える、請求項10に記載のビデオコーディングデバイス。
  14. 前記1つまたは複数のプロセッサが、前記記憶されているビデオデータの少なくとも一部分を符号化するように構成される、請求項9に記載のビデオコーディングデバイス。
  15. 前記1つまたは複数のプロセッサが、前記変換単位を符号化するための前記コーディングモードを選択するように構成される、請求項14に記載のビデオコーディングデバイス。
  16. 前記ビデオデータの少なくとも一部分を捕捉するように構成されるカメラをさらに備え、前記ビデオデータを記憶するために、前記メモリデバイスが、前記カメラから前記捕捉されたビデオデータを受け取るように構成される、請求項14に記載のビデオコーディングデバイス。
  17. 前記CGがブロックの正方形の領域を備え、前記CGの前記サイズがブロックの単位で表すと4×4である、請求項9に記載のビデオコーディングデバイス。
  18. 前記コーディングモードがCGベースのコーディングモードを備える、請求項9に記載のビデオコーディングデバイス。
  19. 1つまたは複数の集積回路、
    1つまたは複数のデジタル信号プロセッサ(DSP)、
    1つまたは複数のフィールドプログラマブルゲートアレイ(FPGA)、
    デスクトップコンピュータ、
    ラップトップコンピュータ、
    タブレットコンピュータ、
    電話、
    テレビジョン、
    カメラ、
    表示デバイス、
    デジタルメディアプレーヤ、
    ビデオゲームコンソール、
    ビデオゲームデバイス、
    ビデオストリーミングデバイス、または
    ワイヤレス通信デバイス
    のうちの少なくとも1つをさらに備える、請求項9に記載のビデオコーディングデバイス。
  20. 命令が符号化された非一時的コンピュータ可読記憶媒体であって、前記命令が、実行されると、ビデオコーディングデバイスの1つまたは複数のプロセッサに、
    前記ビデオデータの現在の変換係数を含む係数グループ(CG)を特定させ、前記CGが変換単位内の変換係数の部分集合を表し、
    前記変換単位と関連付けられる変換サイズに基づいて前記CGのサイズを決定させる、非一時的コンピュータ可読記憶媒体。
JP2017561313A 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング Active JP6873051B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562168571P 2015-05-29 2015-05-29
US62/168,571 2015-05-29
US15/166,144 US11233998B2 (en) 2015-05-29 2016-05-26 Coding data using an enhanced context-adaptive binary arithmetic coding (CABAC) design
US15/166,144 2016-05-26
PCT/US2016/034850 WO2016196379A1 (en) 2015-05-29 2016-05-27 Coding data using an enhanced context-adaptive binary arithmetic coding (cabac) design

Publications (3)

Publication Number Publication Date
JP2018521554A true JP2018521554A (ja) 2018-08-02
JP2018521554A5 JP2018521554A5 (ja) 2019-06-13
JP6873051B2 JP6873051B2 (ja) 2021-05-19

Family

ID=57397705

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2017561313A Active JP6873051B2 (ja) 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング
JP2017561310A Ceased JP2018521553A (ja) 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング
JP2017561300A Active JP6619028B2 (ja) 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2017561310A Ceased JP2018521553A (ja) 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング
JP2017561300A Active JP6619028B2 (ja) 2015-05-29 2016-05-27 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング

Country Status (10)

Country Link
US (3) US10334248B2 (ja)
EP (3) EP3304916B1 (ja)
JP (3) JP6873051B2 (ja)
KR (3) KR20180013909A (ja)
CN (3) CN107667531B (ja)
AU (3) AU2016271140B2 (ja)
BR (3) BR112017025521A2 (ja)
ES (1) ES2905415T3 (ja)
TW (3) TW201711467A (ja)
WO (3) WO2016196369A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11647196B2 (en) 2018-06-27 2023-05-09 Zte Corporation Method and apparatus for encoding image, method and apparatus for decoding image, electronic device, and system

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9369723B2 (en) * 2011-07-14 2016-06-14 Comcast Cable Communications, Llc Preserving image quality in temporally compressed video streams
US10334248B2 (en) 2015-05-29 2019-06-25 Qualcomm Incorporated Coding data using an enhanced context-adaptive binary arithmetic coding (CABAC) design
CN107710759B (zh) * 2015-06-23 2020-11-03 联发科技（新加坡）私人有限公司 转换系数编解码的方法及装置
CN109076223B (zh) * 2016-05-13 2021-07-09 夏普株式会社 图像解码装置以及图像编码装置
US10616582B2 (en) 2016-09-30 2020-04-07 Qualcomm Incorporated Memory and bandwidth reduction of stored data in image/video coding
KR20190086453A (ko) 2016-11-21 2019-07-22 파나소닉 인텔렉츄얼 프로퍼티 코포레이션 오브 아메리카 부호화 장치, 복호 장치, 부호화 방법 및 복호 방법
WO2018092868A1 (ja) * 2016-11-21 2018-05-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 符号化装置、復号装置、符号化方法及び復号方法
US10757412B2 (en) * 2017-01-03 2020-08-25 Avago Technologies International Sales Pte. Limited Architecture flexible binary arithmetic coding system
US11265561B2 (en) * 2017-01-06 2022-03-01 Mediatek Inc. Method and apparatus for range derivation in context adaptive binary arithmetic coding
KR102389869B1 (ko) 2017-07-04 2022-04-22 삼성전자주식회사 다중 코어 변환에 의한 비디오 복호화 방법 및 장치, 다중 코어 변환에 의한 비디오 부호화 방법 및 장치
US10127913B1 (en) * 2017-07-07 2018-11-13 Sif Codec Llc Method of encoding of data stream, method of decoding of data stream, and devices for implementation of said methods
US10506258B2 (en) * 2017-07-13 2019-12-10 Google Llc Coding video syntax elements using a context tree
WO2019011292A1 (en) 2017-07-14 2019-01-17 Mediatek Inc. METHOD AND APPARATUS FOR RANGE CALCULATION IN CONTEXT-ADAPTIVE BITARY ARITHMETIC ENCODING SYSTEM
US11039143B2 (en) 2017-11-20 2021-06-15 Qualcomm Incorporated Memory reduction for context initialization with temporal prediction
EP3490253A1 (en) * 2017-11-23 2019-05-29 Thomson Licensing Encoding and decoding methods and corresponding devices
CN116132673A (zh) * 2017-12-13 2023-05-16 三星电子株式会社 视频解码方法及其装置以及视频编码方法及其装置
US10869062B2 (en) * 2017-12-21 2020-12-15 Qualcomm Incorporated Probability initialization and signaling for adaptive arithmetic coding in video coding
EP3503557A1 (en) * 2017-12-22 2019-06-26 Thomson Licensing Method and apparatus for video encoding and decoding based on context switching
US10863199B2 (en) * 2018-03-26 2020-12-08 Qualcomm Incorporated Minimization of transform memory and latency via parallel factorizations
KR102543505B1 (ko) 2018-03-29 2023-06-14 프라운호퍼-게젤샤프트 추르 푀르데룽 데어 안제반텐 포르슝 에 파우 종속 양자화
JP7187572B2 (ja) * 2018-03-29 2022-12-12 フラウンホーファー－ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 並列符号化機能の強化概念
CN117119195A (zh) * 2018-03-29 2023-11-24 弗劳恩霍夫应用研究促进协会 变换系数块编码
US20190313108A1 (en) 2018-04-05 2019-10-10 Qualcomm Incorporated Non-square blocks in video coding
EP3562156A1 (en) * 2018-04-27 2019-10-30 InterDigital VC Holdings, Inc. Method and apparatus for adaptive context modeling in video encoding and decoding
KR20210018254A (ko) * 2018-06-06 2021-02-17 파나소닉 인텔렉츄얼 프로퍼티 코포레이션 오브 아메리카 삼차원 데이터 부호화 방법, 삼차원 데이터 복호 방법, 삼차원 데이터 부호화 장치, 및 삼차원 데이터 복호 장치
US10992937B2 (en) * 2018-06-18 2021-04-27 Qualcomm Incorporated Coefficient coding with grouped bypass bins
WO2020004277A1 (ja) * 2018-06-28 2020-01-02 シャープ株式会社 画像復号装置、および画像符号化装置
US10687081B2 (en) * 2018-06-29 2020-06-16 Tencent America LLC Method, apparatus and medium for decoding or encoding
US10666981B2 (en) 2018-06-29 2020-05-26 Tencent America LLC Method, apparatus and medium for decoding or encoding
CN112369025A (zh) * 2018-07-02 2021-02-12 交互数字Vc控股公司 基于上下文的二进制算术编码和解码
EP3815363A1 (en) * 2018-08-16 2021-05-05 Beijing Bytedance Network Technology Co. Ltd. Coefficient dependent coding of transform matrix selection
US11483575B2 (en) * 2018-08-24 2022-10-25 Hfi Innovation Inc. Coding transform coefficients with throughput constraints
TWI734178B (zh) * 2018-08-24 2021-07-21 聯發科技股份有限公司 具有產出限制的編碼轉換係數
US11336918B2 (en) * 2018-09-05 2022-05-17 Qualcomm Incorporated Regular coded bin reduction for coefficient coding
CN117201786A (zh) 2018-09-11 2023-12-08 Lg电子株式会社 图像解码方法、图像编码方法和数据发送方法
CN117729332A (zh) * 2018-09-24 2024-03-19 弗劳恩霍夫应用研究促进协会 使用或适用于与依赖标量量化的组合的变换系数的有效编码
WO2020067440A1 (ja) * 2018-09-27 2020-04-02 シャープ株式会社 動画像符号化装置および動画像復号装置
CN118075467A (zh) 2018-09-28 2024-05-24 松下电器（美国）知识产权公司 编码装置、解码装置、以及非暂时性的计算机可读取的记录介质
US11979608B2 (en) 2018-10-11 2024-05-07 Lg Electronics Inc. Transform coefficient coding method and device
WO2020096877A1 (en) * 2018-11-05 2020-05-14 Interdigital Vc Holdings, Inc. Simplifications of coding modes based on neighboring samples dependent parametric models
KR102349456B1 (ko) * 2018-11-12 2022-01-12 삼성전자주식회사 계수 레벨의 엔트로피 부호화 방법 및 장치, 엔트로피 복호화 방법 및 장치
WO2020135371A1 (zh) * 2018-12-24 2020-07-02 华为技术有限公司 一种标志位的上下文建模方法及装置
WO2020141856A1 (ko) * 2019-01-02 2020-07-09 엘지전자 주식회사 영상 코딩 시스템에서 레지듀얼 정보를 사용하는 영상 디코딩 방법 및 그 장치
US11523136B2 (en) * 2019-01-28 2022-12-06 Hfi Innovation Inc. Methods and apparatuses for coding transform blocks
US11134273B2 (en) * 2019-02-14 2021-09-28 Qualcomm Incorporated Regular coded bin reduction for coefficient coding
AU2019201653A1 (en) 2019-03-11 2020-10-01 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding a tree of blocks of video samples
US11202100B2 (en) * 2019-03-11 2021-12-14 Qualcomm Incorporated Coefficient coding for transform skip mode
AU2020234409B2 (en) 2019-03-12 2023-11-02 Lg Electronics Inc. Transform-based image coding method and device therefor
US11178399B2 (en) 2019-03-12 2021-11-16 Qualcomm Incorporated Probability initialization for video coding
US11218735B2 (en) * 2019-04-02 2022-01-04 Qualcomm Incorporated Context derivation for last position coding for video coding
TW202046730A (zh) * 2019-04-24 2020-12-16 美商松下電器（美國）知識產權公司 編碼裝置、解碼裝置、編碼方法、及解碼方法
US10818083B1 (en) * 2019-04-30 2020-10-27 International Business Machines Corporation Pyramid generation via depth-first walk
WO2020228762A1 (en) 2019-05-14 2020-11-19 Beijing Bytedance Network Technology Co., Ltd. Context modeling for residual coding
KR20220013938A (ko) 2019-05-31 2022-02-04 바이트댄스 아이엔씨 인트라 블록 복사 예측을 갖는 팔레트 모드
WO2020244661A1 (en) 2019-06-06 2020-12-10 Beijing Bytedance Network Technology Co., Ltd. Implicit selection of transform candidates
US11368511B2 (en) * 2019-06-20 2022-06-21 Tencent America LLC Unification of rice parameter lookup table
CN112118456B (zh) 2019-06-20 2022-03-25 腾讯美国有限责任公司 莱斯参数选择方法、装置、计算机设备及存储介质
CN113994679B (zh) 2019-06-21 2024-07-12 北京字节跳动网络技术有限公司 关于上下文编解码二进制位的数量的限制
KR102612765B1 (ko) * 2019-06-28 2023-12-13 바이트댄스 아이엔씨 변환 스킵 모드에서 양자화 파라미터를 수정하는 기술
CN117714698A (zh) 2019-06-28 2024-03-15 字节跳动有限公司 屏幕内容编解码中的色度帧内模式推导
CN114402605A (zh) * 2019-07-10 2022-04-26 Lg电子株式会社 图像编码系统中使用残差编码方法的标志的图像解码方法以及用于其的装置
WO2021040410A1 (ko) * 2019-08-31 2021-03-04 엘지전자 주식회사 레지듀얼 코딩에 대한 영상 디코딩 방법 및 그 장치
WO2021055138A1 (en) * 2019-09-20 2021-03-25 Alibaba Group Holding Limited Quantization parameter signaling in video processing
BR112022002916A2 (pt) 2019-09-25 2022-05-10 Panasonic Ip Corp America Codificador, decodificador, método de codificação e método de decodificação
AU2019284053A1 (en) * 2019-12-23 2021-07-08 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding a block of video samples
US11863789B2 (en) * 2020-03-31 2024-01-02 Tencent America LLC Method for signaling rectangular slice partitioning in coded video stream
US11785219B2 (en) 2020-04-13 2023-10-10 Qualcomm Incorporated Coefficient coding for support of different color formats in video coding
EP4325852A1 (en) * 2021-04-15 2024-02-21 LG Electronics Inc. Point cloud data transmission method, point cloud data transmission device, point cloud data reception method, and point cloud data reception device
US11765370B2 (en) * 2021-07-27 2023-09-19 Mediatek Inc. Video residual decoding apparatus using neighbor storage device with smaller storage size to store neighbor data for context selection and associated method
WO2023172706A1 (en) * 2022-03-09 2023-09-14 Innopeak Technology, Inc. Attribute level coding for geometry point cloud coding
WO2023182673A1 (ko) * 2022-03-21 2023-09-28 현대자동차주식회사 컨텍스트 모델 초기화를 사용하는 비디오 코딩을 위한 방법 및 장치
WO2023193724A1 (en) * 2022-04-05 2023-10-12 Beijing Bytedance Network Technology Co., Ltd. Method, apparatus, and medium for video processing
CN114928747B (zh) * 2022-07-20 2022-12-16 阿里巴巴（中国）有限公司 基于av1熵编码的上下文概率处理电路、方法及相关装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013150326A (ja) * 2012-01-20 2013-08-01 Sony Corp Ｈｅｖｃにおける係数符号化の調和
JP2014090326A (ja) * 2012-10-30 2014-05-15 Mitsubishi Electric Corp 動画像符号化装置、動画像復号装置、動画像符号化方法及び動画像復号方法
JP2015507884A (ja) * 2012-01-19 2015-03-12 キヤノン株式会社 変換ユニットの残差係数に対する有意度マップを符号化および復号化する方法、装置、およびシステム
JP2015513291A (ja) * 2012-04-16 2015-04-30 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ 係数走査のための係数グループおよび係数コーディング

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040122693A1 (en) 2002-12-23 2004-06-24 Michael Hatscher Community builder
KR100703773B1 (ko) 2005-04-13 2007-04-06 삼성전자주식회사 향상된 코딩 효율을 갖는 엔트로피 코딩 및 디코딩 방법과이를 위한 장치, 이를 포함하는 비디오 코딩 및 디코딩방법과 이를 위한 장치
KR100703776B1 (ko) 2005-04-19 2007-04-06 삼성전자주식회사 향상된 코딩 효율을 갖는 컨텍스트 기반 적응적 산술 코딩및 디코딩 방법과 이를 위한 장치, 이를 포함하는 비디오코딩 및 디코딩 방법과 이를 위한 장치
US7983343B2 (en) 2006-01-12 2011-07-19 Lsi Corporation Context adaptive binary arithmetic decoding for high definition video
JP4660433B2 (ja) 2006-06-29 2011-03-30 株式会社東芝 符号化回路、復号回路、エンコーダ回路、デコーダ回路、ｃａｂａｃ処理方法
CA2629482A1 (en) 2007-04-21 2008-10-21 Avid Technology, Inc. Using user context information to select media files for a user in a distributed multi-user digital media system
US8516505B2 (en) 2008-03-14 2013-08-20 Microsoft Corporation Cross-platform compatibility framework for computer applications
CA2871252C (en) * 2008-07-11 2015-11-03 Nikolaus Rettelbach Audio encoder, audio decoder, methods for encoding and decoding an audio signal, audio stream and computer program
US8168200B2 (en) 2008-10-24 2012-05-01 Merial Limited Vaccine against african horse sickness virus
US8873626B2 (en) 2009-07-02 2014-10-28 Qualcomm Incorporated Template matching for video coding
TWI403170B (zh) 2010-05-21 2013-07-21 Univ Nat Chiao Tung 背景調適性二進制算術解碼裝置及其解碼方法
US8344917B2 (en) 2010-09-30 2013-01-01 Sharp Laboratories Of America, Inc. Methods and systems for context initialization in video coding and decoding
US9497472B2 (en) * 2010-11-16 2016-11-15 Qualcomm Incorporated Parallel context calculation in video coding
CN102231830B (zh) 2010-11-23 2013-04-17 浙江大学 用于上下文算术编解码的运算单元
US9215473B2 (en) 2011-01-26 2015-12-15 Qualcomm Incorporated Sub-slices in video coding
US9338449B2 (en) 2011-03-08 2016-05-10 Qualcomm Incorporated Harmonized scan order for coding transform coefficients in video coding
WO2012134246A2 (ko) 2011-04-01 2012-10-04 엘지전자 주식회사 엔트로피 디코딩 방법 및 이를 이용하는 디코딩 장치
FR2977111A1 (fr) 2011-06-24 2012-12-28 France Telecom Procede de codage et decodage d'images, dispositif de codage et decodage et programmes d'ordinateur correspondants
US20130003837A1 (en) 2011-06-29 2013-01-03 General Instrument Corporation Methods and system for using a scan coding pattern during intra coding
US20130083856A1 (en) * 2011-06-29 2013-04-04 Qualcomm Incorporated Contexts for coefficient level coding in video compression
US9060173B2 (en) 2011-06-30 2015-06-16 Sharp Kabushiki Kaisha Context initialization based on decoder picture buffer
US8693401B2 (en) 2011-07-20 2014-04-08 Connectem Inc. Method and system for optimized handling of context using hierarchical grouping (for machine type communications)
ES2868087T3 (es) * 2011-10-31 2021-10-21 Samsung Electronics Co Ltd Procedimiento y aparato para determinar un modelo de contexto para codificación por entropía de nivel de coeficiente de transformación
US20130114691A1 (en) 2011-11-03 2013-05-09 Qualcomm Incorporated Adaptive initialization for context adaptive entropy coding
IN2014CN02865A (ja) 2011-11-15 2015-07-03 Intel Corp
US9743098B2 (en) 2011-11-19 2017-08-22 Blackberry Limited Multi-level significance map scanning
KR101802334B1 (ko) * 2011-12-02 2017-12-29 삼성전자주식회사 적응적 탬플릿을 이용한 이진 영상의 부호화 방법 및 장치, 그 복호화 방법 및 장치
WO2013106987A1 (en) * 2012-01-16 2013-07-25 Mediatek Singapore Pte. Ltd. Methods and apparatuses of bypass coding and reducing contexts for some syntax elements
CN103931188B (zh) 2012-01-16 2017-05-10 寰发股份有限公司 语法元素的基于上下文的自适应二进制算术编码装置及方法
US9191670B2 (en) 2012-01-17 2015-11-17 Qualcomm Incorporated Throughput improvement for CABAC coefficient level coding
US9332259B2 (en) 2012-01-18 2016-05-03 Qualcomm Incorporated Indication of use of wavefront parallel processing in video coding
US9654772B2 (en) 2012-01-19 2017-05-16 Qualcomm Incorporated Context adaptive entropy coding with a reduced initialization value set
AU2012200345B2 (en) 2012-01-20 2014-05-01 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding the significance map residual coefficients of a transform unit
US9866829B2 (en) * 2012-01-22 2018-01-09 Qualcomm Incorporated Coding of syntax elements that correspond to coefficients of a coefficient block in video coding
US9363510B2 (en) * 2012-03-02 2016-06-07 Qualcomm Incorporated Scan-based sliding window in context derivation for transform coefficient coding
US9036710B2 (en) * 2012-03-08 2015-05-19 Blackberry Limited Unified transform coefficient encoding and decoding
US9237344B2 (en) 2012-03-22 2016-01-12 Qualcomm Incorporated Deriving context for last position coding for video coding
CN103327316B (zh) 2012-03-22 2016-08-10 上海算芯微电子有限公司 视频宏块的上下文信息存取方法和系统
US9264706B2 (en) * 2012-04-11 2016-02-16 Qualcomm Incorporated Bypass bins for reference index coding in video coding
DK3481068T3 (da) 2012-04-13 2020-11-16 Ge Video Compression Llc Billedkodning med lav forsinkelse
US9491463B2 (en) * 2012-04-14 2016-11-08 Qualcomm Incorporated Group flag in transform coefficient coding for video coding
CA2807382A1 (en) * 2012-04-16 2013-10-16 Research In Motion Limited Modified contexts for level coding of video data
US9294779B2 (en) * 2012-06-15 2016-03-22 Blackberry Limited Multi-bit information hiding using overlapping subsets
US9088769B2 (en) 2012-06-28 2015-07-21 Blackberry Limited Reduced worst-case context-coded bins in video compression with parity hiding
SG11201500846TA (en) 2012-09-26 2015-05-28 Panasonic Ip Corp America Image coding method, image decoding method, image coding apparatus, image decoding apparatus, and image coding and decoding apparatus
PL2986005T3 (pl) 2013-01-04 2019-08-30 Samsung Electronics Co., Ltd. Urządzenie do dekodowania entropijnego segmentów wycinka
KR102218196B1 (ko) * 2013-10-28 2021-02-23 삼성전자주식회사 인코더, 이의 동작 방법과, 상기 인코더를 포함하는 장치들
US20150334425A1 (en) 2014-05-14 2015-11-19 Blackberry Limited Adaptive context initialization
US9425822B2 (en) * 2014-08-05 2016-08-23 Broadcom Corporation Simplified range and context update for multimedia context-adaptive binary arithmetic coding design
KR102464337B1 (ko) * 2014-09-25 2022-11-07 오라클 인터내셔날 코포레이션 멀티테넌트 어플리케이션 서버 환경에서 파티션 식별자들의 결정을 위한 시스템 및 방법
US10334248B2 (en) 2015-05-29 2019-06-25 Qualcomm Incorporated Coding data using an enhanced context-adaptive binary arithmetic coding (CABAC) design

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015507884A (ja) * 2012-01-19 2015-03-12 キヤノン株式会社 変換ユニットの残差係数に対する有意度マップを符号化および復号化する方法、装置、およびシステム
JP2013150326A (ja) * 2012-01-20 2013-08-01 Sony Corp Ｈｅｖｃにおける係数符号化の調和
JP2015513291A (ja) * 2012-04-16 2015-04-30 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ 係数走査のための係数グループおよび係数コーディング
JP2014090326A (ja) * 2012-10-30 2014-05-15 Mitsubishi Electric Corp 動画像符号化装置、動画像復号装置、動画像符号化方法及び動画像復号方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11647196B2 (en) 2018-06-27 2023-05-09 Zte Corporation Method and apparatus for encoding image, method and apparatus for decoding image, electronic device, and system

Also Published As

Publication number Publication date
CN107660339A (zh) 2018-02-02
KR102706023B1 (ko) 2024-09-11
EP3304901A1 (en) 2018-04-11
KR20180013910A (ko) 2018-02-07
CN107690807B (zh) 2020-09-15
US20160353113A1 (en) 2016-12-01
BR112017025484A2 (pt) 2018-08-07
CN107667531B (zh) 2020-07-28
JP2018521552A (ja) 2018-08-02
ES2905415T3 (es) 2022-04-08
CN107660339B (zh) 2020-03-24
AU2016271137A1 (en) 2017-11-16
US20160353111A1 (en) 2016-12-01
BR112017025521A2 (pt) 2018-08-07
EP3304916B1 (en) 2022-01-05
WO2016196376A1 (en) 2016-12-08
WO2016196379A1 (en) 2016-12-08
KR102600724B1 (ko) 2023-11-09
TW201711467A (zh) 2017-03-16
US20160353112A1 (en) 2016-12-01
EP3304915A1 (en) 2018-04-11
JP6619028B2 (ja) 2019-12-11
TW201711464A (zh) 2017-03-16
AU2016271130B2 (en) 2020-11-26
AU2016271130A1 (en) 2017-11-09
TW201711468A (zh) 2017-03-16
KR20180013911A (ko) 2018-02-07
JP6873051B2 (ja) 2021-05-19
KR20180013909A (ko) 2018-02-07
AU2016271137B2 (en) 2020-09-03
JP2018521553A (ja) 2018-08-02
US10334248B2 (en) 2019-06-25
US11233998B2 (en) 2022-01-25
CN107667531A (zh) 2018-02-06
BR112017025484B1 (pt) 2023-10-31
BR112017025556A2 (pt) 2018-08-07
WO2016196369A1 (en) 2016-12-08
US10574993B2 (en) 2020-02-25
CN107690807A (zh) 2018-02-13
TWI699110B (zh) 2020-07-11
AU2016271140A1 (en) 2017-11-16
AU2016271140B2 (en) 2020-12-03
EP3304916A1 (en) 2018-04-11

Similar Documents

Publication Publication Date Title
JP6619028B2 (ja) 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング
CN111357287B (zh) 针对通过时间预测进行的上下文初始化的存储器减小
JP6728240B2 (ja) 高度算術コーダ
CN109644275B (zh) 用于视频译码的树型译码

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171130

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190513

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190513

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200309

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200508

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20200914

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210114

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20210114

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20210125

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20210201

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: 20210322

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210420

R150 Certificate of patent or registration of utility model

Ref document number: 6873051

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250