JP2018534835A - 短距離イントラ予測（ｓｄｉｐ）ベースのビデオコーディング - Google Patents

短距離イントラ予測（ｓｄｉｐ）ベースのビデオコーディング Download PDF

Info

Publication number
JP2018534835A
JP2018534835A JP2018515827A JP2018515827A JP2018534835A JP 2018534835 A JP2018534835 A JP 2018534835A JP 2018515827 A JP2018515827 A JP 2018515827A JP 2018515827 A JP2018515827 A JP 2018515827A JP 2018534835 A JP2018534835 A JP 2018534835A
Authority
JP
Japan
Prior art keywords
block
sub
sdip
value
video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018515827A
Other languages
English (en)
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 JP2018534835A publication Critical patent/JP2018534835A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/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/103—Selection of coding mode or of prediction mode
    • H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/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
    • 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/129—Scanning of coding units, e.g. zig-zag scan of transform coefficients or flexible macroblock ordering [FMO]
    • 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
    • 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/43—Hardware specially adapted for motion estimation or compensation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H04N19/463—Embedding additional information in the video signal during the compression process by compressing encoding parameters before transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding

Landscapes

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

Abstract

ある例では、デバイスは、符号化されたビデオデータを記憶するように構成されるメモリデバイスと、メモリデバイスに結合された処理回路とを含む。処理回路は、記憶されているビデオデータの長方形変換単位(TU)が第1の整数値「K」により表記される画素の行の数および第2の整数値「L」により表記される画素の列の数を含むと決定することであって、Kが、1だけ左シフトされた整数値「m」に等しい値を有し、Lが。1だけ左シフトされた整数値「n」に等しい値を有する、決定することと、nとmの和が奇数であると決定することと、nとmの和が奇数であることに基づいて、デルタ量子化パラメータ値を長方形TUのための量子化パラメータ(QP)値に加算して長方形TUのための修正されたQP値を取得することとを行うように構成される。

Description

本出願は、その内容全体が参照により本明細書に組み込まれる、2015年9月29日に出願された米国仮特許出願第62/234,589号の利益を主張する。
本開示はビデオコーディングに関し、より詳細には、ビデオデータをコーディングするときにイントラ予測を実行するための技法に関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(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)規格、およびそのような規格の拡張によって定義される規格に記載されているものなどの、ビデオ圧縮技法を実装して、デジタルビデオ情報をより効率的に送信し、受信し、記憶する。
ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間的予測および/または時間的予測を含む。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがブロックに区分され得る。各ブロックはさらに区分され得る。イントラコーディングされる(I)フレームまたはスライスの中のブロックは、同じフレームまたはスライスの中の近隣のブロックの中の参照サンプルに関する空間的予測を使用して符号化される。インターコーディングされる(PまたはB)フレームまたはスライスの中のブロックは、同じフレームもしくはスライスの中の近隣のブロックの中の参照サンプルに関する空間的予測、または他の参照フレームの中の参照サンプルに関する時間的予測を使用し得る。空間的予測または時間的予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの画素差分を表す。
インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コーディングされたブロックと予測ブロックとの差分を示す残差データとに従って符号化される。イントラコーディングされるブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、画素領域から変換領域に変換されて、残差変換係数をもたらすことがあり、その残差変換係数は、次いで量子化され得る。最初に2次元アレイに配置される量子化された変換係数は、エントロピーコーディングのための変換係数の1次元ベクトルを生成するために、特定の順序で走査され得る。
X. Cao他、「CE6.c Report on Simplification of Short Distance Intra Prediction (SDIP) Method」、JCTVC-G556、2011年11月 X. Cao他、「Short Distance Intra Coding Scheme for High Efficiency Video Coding」、IEEE Transactions on Image Processing、Vol. 22、No. 2、2013年2月 X. Cao他、「Short Distance Intra Coding Scheme for HEVC」、2012 Picture Coding Symposium、2010年5月7〜9日 X. Cao他、「CE6.c Report on Simplification of Short Distance Intra Prediction (SDIP) Method」、JCTVC-G556、2011年11月
全般に、本開示は、短距離イントラ予測(SDIP)を使用してデータをイントラコーディングするための技法を説明する。本開示の態様は、イントラモード依存の処理順序、コーディング済ブロックフラグ(CBF:coded block flag)予測、最終有意係数(LSC:last significant coefficient)の決定、およびデルタ量子化パラメータ(デルタQPまたはdQP)による変換精度操作に関する。本開示の様々な技法は、SDIPベースのビデオコーディングに関して説明されるが、本技法は他のモードに従ったビデオコーディングにも適用可能であり得ることが理解されるだろう。
一例では、符号化されたビデオデータを復号する方法は、長方形変換単位(TU)が第1の整数値「K」により表記される数の画素の行および第2の整数値「L」により表記される数の画素の列を備えると決定するステップであって、Kが(1<<n)に等しく、Lが(1<<m)に等しい、ステップと、nとmの和が奇数であると決定するステップと、nとmの和が奇数であることに基づいて、デルタ量子化パラメータ(デルタQP)値を長方形TUの量子化パラメータ(QP)値に加算して長方形TUの修正されたQP値を取得するステップとを含む。
別の例では、ビデオ復号デバイスは、符号化されたビデオデータを記憶するように構成されるメモリデバイスと、メモリデバイスに結合された処理回路とを含む。処理回路は、メモリデバイスに記憶されている符号化されたビデオデータの長方形変換単位(TU)が第1の整数値「K」により表記される数の画素の行および第2の整数値「L」により表記される数の画素の列を備えると決定することであって、Kが(1<<n)に等しく、Lが(1<<m)に等しい、決定することと、nとmの和が奇数であると決定することと、nとmの和が奇数であることに基づいて、デルタ量子化パラメータ(デルタQP)値を長方形TUの量子化パラメータ(QP)値に加算して長方形TUの修正されたQP値を取得することとを行うように構成される。
別の例では、ビデオ復号デバイスは、符号化されたビデオデータを記憶するように構成されるメモリデバイスと、メモリデバイスに結合された処理回路とを含む。処理回路は、メモリデバイスに記憶されている符号化されたビデオデータのサブブロックが短距離イントラ予測(SDIP)に従って復号されるべきであると決定し、メモリデバイスに記憶されている符号化されたビデオデータのサブブロックと関連付けられるイントラ予測方向を決定し、イントラ予測方向が左下方向を備えるという決定に応答して、サブブロックのSDIPベースの復号の処理順序が下から上への処理順序を備えると決定し、イントラ予測方向が右上方向を備えるという決定に応答して、サブブロックのSDIPベースの復号の処理順序が右から左への処理順序を備えると決定するように構成される。
別の例では、ビデオデータを符号化する方法は、ビデオデータのサブブロックが短距離イントラ予測(SDIP)に従って符号化されるべきであると決定するステップと、ビデオデータのサブブロックと関連付けられるイントラ予測方向を決定するステップと、イントラ予測方向が左下方向を備えるとの決定に応答して、サブブロックのSDIPベースの符号化の処理順序が下から上への処理順序を備えると決定すること、または、イントラ予測方向が右上方向を備えるとの決定に応答して、サブブロックのSDIPベースの符号化の処理順序が右から左への処理順序を備えると決定することのうちの1つを実行するステップとを含む。
本開示の様々な態様の詳細が、添付の図面および下記の説明において記載される。本開示において説明される技法の他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。
本開示の技法を実装し得る例示的なビデオ符号化および復号システムを示すブロック図である。 本開示の技法を実装し得る例示的なビデオエンコーダを示すブロック図である。 本開示の技法を実装し得る例示的なビデオデコーダを示すブロック図である。 例示的な四分木および対応する最大コーディング単位(LCU)を示す概念図である。 例示的な四分木および対応する最大コーディング単位(LCU)を示す概念図である。 例示的なイントラ予測モード方向を示す概念図である。 ビデオデータを予測するための例示的な区分モードを示す概念図である。 短距離イントラ予測(SDIP)に従って線または非正方形(たとえば、長方形)のブロックへと区分されるコーディング単位(CU)を示す概念図である。 短距離イントラ予測(SDIP)予測されたCUを含む例示的な最大コーディング単位(LCU)を示す概念図である。 SDIPの非対称区分モードを使用して区分されるブロックの様々な例を示す概念図である。 非正方形の四分木区分のための例示的な区分構造を示す概念図である。 本開示の様々な態様による、ビデオコーディングデバイスがSDIPベースのコーディングを修正するために実施し得る適応的な処理順序の変更を示す概念図である。 本開示の様々な態様による、ビデオコーディングデバイスがSDIPベースのコーディングを修正するために実施し得る適応的な処理順序の変更を示す概念図である。 ビデオ復号デバイスがそれにより本開示の技法を実施し得る例示的なプロセスを示すフローチャートである。 ビデオ符号化デバイスがそれにより本開示の技法を実施し得る例示的なプロセスを示すフローチャートである。 ビデオコーディングデバイスが本開示の1つまたは複数の変換操作技法を実施し得る例示的なプロセスを示すフローチャートである。
ビデオコーディングデバイスは、ビデオデータを効率的に符号化および復号するためにビデオ圧縮技法を実装する。ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間的(フレーム内)予測技法および/または時間的(フレーム間)予測技法を適用することを含み得る。ビデオエンコーダは通常、(以下でより詳細に説明されるように)ビデオブロックまたはコーディングユニットと呼ばれる矩形の領域に、元のビデオシーケンスの各ピクチャを区分する。これらのビデオブロックは、イントラモード(Iモード)を使用して、またはインターモード(PモードまたはBモード)を使用して符号化され得る。
PモードまたはBモードでは、ビデオエンコーダはまず、参照フレームと呼ばれFrefと表記される別の時間的位置にあるフレームの中に符号化されているブロックに類似するブロックを探す。ビデオエンコーダは、この探索の範囲を、符号化されるべきブロックからのある空間的変位に制限し得る。2次元(2D)動きベクトル(Δx, Δy)を使用して最良の一致を特定することができ、ここでΔxは水平方向の変位であり、Δyは垂直方向の変位である。したがって、ビデオエンコーダは、動きベクトルと、最良の一致が属する参照ピクチャとを使用して、以下の式に従い予測されるブロックFpredを構築することができる。
Fpred(x, y) = Fref(x+Δx, y+Δy)
ここで、ピクチャ内の画素の位置は(x, y)により表記される。
Iモードで符号化されるブロックに対して、ビデオエンコーダは、同じピクチャ内の以前に符号化された近隣のブロックからのデータに基づいて、空間予測技法を使用して予測されたブロックを形成することができる。
いずれの場合でも、IモードとPまたはBモードの両方に対して、予測誤差、すなわち符号化されているブロックの中の画素値と予測されるブロックとの差は、離散コサイン変換(DCT)などの離散的な変換の加重基底関数のセットとして表され得る。変換は、4×4、8×8、または16×16以上などの異なるサイズのブロックを使用して実行され得る。変換ブロックの形状は、常に正方形である必要はない。たとえば、長方形の変換ブロック、たとえば16×4、32×8などの変換ブロックサイズの変換ブロックも使用され得る。
変換の後、重み(すなわち、変換係数)が続いて量子化される。量子化は情報の喪失をもたらすので、量子化された係数は、元の変換係数より精度が低い。圧縮率、すなわち、元のシーケンスおよび圧縮されたシーケンスを表すために使用されるビット数の比が、変換係数を量子化するときに使用される量子化パラメータ(QP)の値を調整することによって制御され得る。
量子化された変換係数および動きベクトルは、シンタックス要素の例であり、制御情報とともに、ビデオシーケンスのコーディングされた表現を形成する。いくつかの事例では、ビデオエンコーダは、シンタックス要素をエントロピーコーディングすることができ、それによりそれらの表現に必要なビットの数をさらに減らす。エントロピーコーディングは、シンタックス要素の分布の性質を利用すること(たとえば、あるシンボルが他のシンボルより頻繁に現れることを認識すること)によって、送信または記憶されるシンボル(たとえば、シンタックス要素)を表すのに必要なビットの数を最小限にすることを狙った、無損失演算である。
ビデオデコーダは、上で論じられたシンタックス要素と制御情報とを使用して、現在のフレームを復号するための予測データ(たとえば、予測ブロック)を構築することができる。たとえば、ビデオデコーダは、予測ブロックと圧縮された予測誤差とを加算することができる。ビデオデコーダは、量子化された係数を使用して変換基底関数を重み付けることによって、圧縮された予測誤差を決定することができる。再構築されたフレームと元のフレームとの差分は、再構築誤差と呼ばれる。
Joint Cooperative Team for Video Coding(JCT-VC)は、high efficiency video coding(HEVC)と呼ばれる新しいコーディング規格を開発した。HEVCでは、ピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディング単位(LCU)に区分され得る。ビットストリーム内のシンタックスデータは、画素の数の観点で最大のコーディング単位であるLCUのサイズを定義することができる。スライスは、コーディング順にいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、四分木に従ってコーディング単位(CU)に分割され得る。一般に、四分木データ構造はCU当たり1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割される場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。コーディング単位(CU)は、一般に、様々なコーディングツールがビデオ圧縮のために適用される基本単位として働く画像領域を指す。CUは普通、Yと表記される輝度成分と、UおよびVと表記される2つの色度成分とを有する。
CUは一般に、CUに対するデータがどのように予測されるかを記述する1つまたは複数の予測単位(PU)を含む。CUは、CUのPUの予測モードを示す情報を含み得る。たとえば、CUに対する情報は、CUの1つまたは複数の部分の予測モードを示し得る。いくつかの例では、CUは、予測の目的で2つ以上の部分へと分割または区分され得る。
本開示において説明されるように、予測区分モード(prediction partition mode)(または予測区分モード(prediction partitioning mode))は一般に、ブロック(CUなどの、たとえばリーフノードCU)が予測の目的で分割される方式を指す。たとえば、特定のCUのサイズが2N×2Nであると仮定すると、CUは、2N×2NのPUを使用して全体として予測され得る(2N×2N区分モードと呼ばれる)。別の例では、CUは、サイズがN×Nである4つの等しいサイズのPUを使用して予測され得る(N×N区分モードと呼ばれる)。
いくつかの例では、短距離イントラ予測(SDIP)モードは、イントラ予測されたブロックをコーディングするために使用され得る。SDIPは、X. Cao他による、「CE6.c Report on Simplification of Short Distance Intra Prediction (SDIP) Method」、JCTVC-G556、2011年11月、X. Cao他による、「Short Distance Intra Coding Scheme for High Efficiency Video Coding」、IEEE Transactions on Image Processing、Vol. 22、No. 2、2013年2月、およびX. Cao他による、「Short Distance Intra Coding Scheme for HEVC」、2012 Picture Coding Symposium、2010年5月7〜9日などの様々な参考文献に記載された。SDIPはHEVCの標準化においても研究された。SDIPの技法は、予測される画素とその参照画素の距離を短くすることによって予測残差のエネルギーを低減するように、N×Nのブロックを線(たとえば、単一の画素の行または単一の画素の列)または非正方形のブロックに分割することである。SDIPモードでは、64×64の次元より小さい1つのCUは、図7Aおよび図7Bに示されるように、線または長方形の非正方形ブロックとして区分され得る。図7Aは、HMに基づく、および/またはX. Cao他による、「CE6.c Report on Simplification of Short Distance Intra Prediction (SDIP) Method」、JCTVC-G556、2011年11月に基づくSDIPブロック区分を示す。SDIPによれば、1つの32×32のCUは、4つの8×32のPUまたは4つの32×8のPUに区分され得る。加えて、16×16のCUは、(HEVC Test Model「HM」に記載されるように)4つの8×8のPUへと分割されることが可能であり、または、4つの4×16のPUへと、もしくは4つの16×4のPUへと分割され得る。加えて、SDIPによれば、4×16のPUまたは16×4のPUはさらに、4つの1×16の区分へと、または4つの16×1の区分へと分割され得る。同様に、1つの8×8のCUは、4つの2×8のPUへと、または4つの8×2のPUへと分割され得る。そして、それぞれの4×4のPUはさらに、4つの1×4の区分へと、または4つの4×1の区分へと分割され得る。したがって、SDIPでは2つのタイプのPUがサポートされる。PUの第1のサポートされるタイプは、本明細書ではhN×2Nの次元または2N×hNの次元のいずれかを有するものとして言及される、長方形PUである。上の説明では、「h」は半分(1/2)を示す。PUの第2のサポートされるタイプは、本明細書では1×Nの次元またはN×1の次元のいずれかを有するものとして言及される、線ベースのPUである。32×32のCUでは、長方形のSDIP PUのみが使用される。16×16または8×8のCUでは、長方形PUと線ベースのPUの両方がサポートされる。たとえば、SDIPによれば長方形PUと線ベースのPUの両方を16×16のCUおよび8×8のCUに対してサポートすることができ、それは、これらの種類のCUにはテクスチャがより多いからである。
例示的なSDIP技法によれば、ビデオエンコーダおよび/またはビデオデコーダは、CUを並列な非正方形のPUに分割し得る。たとえば、SDIP技法は、サイズが2N×hNまたはhN×2Nである複数の並列なPUへとCUを分割するために使用されることがあり、ここで「h」は2分の1を表す。言い換えると、「hN」はN/2と等価である。説明を目的とする例では、8×8のCUは4つの8×2のPUへと分割されることがあり、この例では、「N×M」は垂直方向のN個の画素および水平方向のM個の画素を指す。この例では、第1のPUはCUに対する近隣の画素から予測されることがあり、第2のPUは第1のPUの画素を含む近隣の画素から予測されることがあり、第3のPUは第2のPUの画素を含む近隣の画素から予測されることがあり、第4のPUは第3のPUの画素を含む近隣の画素から予測されることがある。このようにして、CUに対する近隣の以前にコーディングされたブロックの画素からCUのすべての画素を予測するのではなく、SDIPを使用すると、CU内の画素が同じCU内の他の画素を予測するために使用され得る。
区分モードに関する情報は様々な方法で提供され得る。たとえば、区分情報、たとえば、CUがイントラコーディングされたブロックに対する2N×2NおよびN×NのサイズのPUを使用して予測されるか、またはインターコーディングされたブロックに対する2N×2N、2N×N、N×2N、N×NのサイズのPUを使用して予測されるかが、区分モードテーブルを使用して提供され得る。区分モードテーブルは、モードの各々をシンタックス要素にマッピングし得る。いくつかの例では、シンタックス要素は、エントロピーコーダによってコーディングされ得るビンストリング(ビットのバイナリストリング)であり得る。いずれの場合でも、テーブルはエンコーダとデコーダの両方において維持され得る。したがって、特定のCUに対する区分情報は、区分モードテーブルのエントリに従って特定され得る。
他の例では、区分情報は1つまたは複数の他のシンタックス要素(モードテーブルと関連付けられない)を使用してシグナリングされ得る。たとえば、ビデオエンコーダは、SDIPが特定のCUを予測するために使用されることの指示を、符号化されたビットストリームにおいて提供し得る。したがって、ビデオデコーダは、そのようなシグナリングを復号すると、特定のCUがSDIPを使用してイントラ予測されたと決定し得る。いくつかの例では、SDIPモードに対するシンタックスは次の要素を含み得る。
1. SDIP_Flag: CUが正方形の区分(2N×2N、N×N)またはSDIPタイプ(2N×hNおよびhN×2N)として符号化されることをシグナリングするためのフラグ。たとえば、SDIP_Flagが0に等しい場合、CUは正方形予測ユニットとして符号化される。しかしながら、SDIP_Flagが1に等しい場合、CUはSDIP区分を使用して符号化される。
2. SDIP_direction_Flag: SDIPモードが使用されるシグナリングに対するフラグ。たとえば、SDIP_direction__Flagが0に等しい場合、hN×2Nモードが使用され得る。しかしながら、SDIP_direction__Flagが1に等しい場合、2N×hNモードが使用され得る。
上の例では、SDIP_FlagとSDIP_direction_Flagの両方が、CABAC(コンテキスト適応型バイナリ算術コーディング)を使用してコーディングされ得る。
上の例では、SDIP_Flagシンタックス要素およびSDIP_direction_Flagシンタックス要素は、(上で説明された)区分モードテーブルにより定義されるシンタックス要素に加えて提供される。その上、上で述べられたように、SDIP_FlagおよびSDIP_direction_Flagは、追加のCABACコンテキストが定義され維持されることを必要とし得る。したがって、SDIPフラグのシグナリングは、比較的計算の負荷が高いことがあり、かつ/またはビットの面でコストが高いことがある。
図1は、本開示のSDIPコーディング技法および/または変換操作技法のうちの1つまたは複数を実行するための技法を利用し得る例示的なビデオ符号化および復号システム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は、SDIPベースのコーディングを実行するための技法および/または変換サイズ操作のための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、統合されたディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
図1の示されるシステム10は一例にすぎない。SDIPベースのコーディングを実行するための、および/または変換サイズ操作のための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。一般に、本開示の技法はビデオ符号化デバイスによって実行されるが、技法はまた、通常は「コーデック」と呼ばれるビデオエンコーダ/デコーダによって実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス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つまたは複数のコンピュータ可読媒体を含むと理解され得る。
本開示は一般に、ビデオデコーダ30などの別のデバイスに特定の情報を「シグナリング」するビデオエンコーダ20に言及することがある。しかしながら、ビデオエンコーダ20は、特定のシンタックス要素をビデオデータの様々な符号化された部分と関連付けることにより、情報をシグナリングできることが理解されるべきである。すなわち、ビデオエンコーダ20は、ビデオデータの様々な符号化された部分のヘッダに特定のシンタックス要素を格納することにより、データを「シグナリング」することができる。場合によっては、そのようなシンタックス要素は、ビデオデコーダ30によって受信および復号される前に、符号化および記憶(たとえば、コンピュータ可読媒体16に記憶)されることがある。したがって、「シグナリング」という用語は、一般に、そのような通信がリアルタイムもしくはほぼリアルタイムで生じるか、ある時間の期間にわたって生じるかにかかわらず、符号化の時点で、媒体にシンタックス要素を記憶するときに生じ得るような、圧縮されたビデオデータを復号するためのシンタックスまたは他のデータの通信を指すことがあり、シンタックス要素は次いで、この媒体に記憶された後の任意の時間に、復号デバイスによって取り出されることがある。
宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって規定され、ビデオデコーダ30によっても使用される、シンタックス情報を含むことがあり、シンタックス情報は、ブロックおよび他のコーディングされたユニット、たとえばGOPの特性および/または処理を記述するシンタックス要素を含む。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプの表示デバイスなどの、様々な表示デバイスのうちのいずれかを備え得る。
ビデオエンコーダ20およびビデオデコーダ30は、各々、該当する場合、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な適切なエンコーダ回路またはデコーダの回路のうちのいずれかとして実装され得る。ビデオエンコーダ20および/またはビデオデコーダ30がそれにより実装され得るエンコーダ回路および/または復号回路の例は処理回路を含み、処理回路は、機能固定回路、プログラマブル回路、または機能固定回路とプログラマブル回路の組合せを備え得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、本開示の技法を実行するために処理回路(たとえば、1つまたは複数のプロセッサ)を使用してハードウェアで命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、これらのいずれもが、複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合されてもよい。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、処理回路、マイクロプロセッサ、および/または、携帯電話などのワイヤレス通信デバイスを備えることがある。
図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびオーディオデコーダと一体であることがあり、共通のデータストリームまたは別個のデータストリームの中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含むことがある。該当する場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、または、ユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、Advanced Video Coding(AVC)と呼ばれるITU-T H.264規格、またはそのような規格の拡張などの、ビデオ圧縮規格に従って動作し得る。ITU-T H.264/MPEG-4(AVC)規格は、Joint Video Team(JVT)として知られている共同パートナーシップの成果として、ISO/IEC Moving Picture Experts Group(MPEG)とともにITU-T Video Coding Experts Group(VCEG)によって策定された。いくつかの態様では、本開示において説明される技法は一般に、H.264規格に準拠するデバイスに適用され得る。H.264規格は、本明細書においてH.264規格もしくはH.264仕様、またはH.264/AVC規格もしくは仕様と呼ばれることがある、ITU-T Study Groupによる2005年3月付のITU-T Recommendation H.264、Advanced Video Coding for generic audiovisual servicesに記載されている。ビデオ圧縮規格の他の例は、MPEG-2およびITU-T H.263を含む。
本開示の技法は、いかなる特定のコーディング規格にも限定されないが、技法は、HEVC規格に関連することがある。HEVC規格化の取り組みは、HEVC Test Model(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づいた。HMは、たとえば、ITU-T H.264/AVCによる既存のデバイスに対して、ビデオコーディングデバイスのいくつかの追加の機能を仮定する。たとえば、H.264は、9個のイントラ予測符号化モードを提供するが、HMは、35個ものイントラ予測符号化モードを提供し得る。
一般に、HMのワーキングモデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディング単位(LCU)に分割され得ることを記載している。ビットストリーム内のシンタックスデータは、画素の数の観点で最大のコーディング単位であるLCUのサイズを定義することができる。スライスは、コーディング順にいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、四分木に従ってコーディング単位(CU)に分割され得る。一般に、四分木データ構造はCU当たり1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割される場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
四分木データ構造の各ノードは、対応するCUのためのシンタックスデータを提供することができる。たとえば、四分木内のノードは、ノードに対応するCUがサブCUに分割されているかどうかを示す分割フラグを含み得る。CUのためのシンタックス要素は再帰的に定義されることがあり、CUがサブCUに分割されているかどうかに依存することがある。CUがそれ以上分割されない場合、それはリーフCUと呼ばれる。本開示では、リーフCUの4つのサブCUはまた、元のリーフCUの明示的な分割が存在しない場合でも、リーフCUと呼ばれる。たとえば、16×16サイズのCUがそれ以上分割されない場合、4つの8×8のサブCUもリーフCUと呼ばれるが、16×16のCUは決して分割されない。
CUは、CUがサイズの区別を持たないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、4つの子ノード(サブCUとも呼ばれる)に分割されてもよく、各子ノードは、今度は親ノードになり、別の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と関連付けられたシンタックスデータはまた、たとえば、四分木に従った1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形(たとえば、長方形)であり得る。
HEVC規格は、CUによって異なり得る、TUに従った変換を可能にする。TUは、典型的には、区分されたLCUのために定義された所与のCU内のPUのサイズに基づいてサイズが決められるが、これは、必ずしもそうでないことがある。TUは通常、PUと同じサイズであるか、またはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差四分木」(RQT)として知られる四分木構造を使用して、より小さい単位に再分割され得る。RQTのリーフノードは、変換単位(TU)と呼ばれ得る。TUと関連付けられた画素差分値は、変換係数を生成するために変換されることがあり、変換係数は量子化されることがある。
リーフCUは、1つまたは複数の予測単位(PU)を含み得る。一般に、PUは、対応するCUのすべてまたは一部に対応する空間エリアを表し、PUのための参照サンプルを取り出すためのデータを含み得る。その上、PUは、予測に関連するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUのためのデータは、PUに対応するTUのイントラ予測モードを記述するデータを含み得る、残差四分木(RQT)に含まれ得る。別の例として、PUがインターモード符号化されるとき、PUは、PUのための1つまたは複数の動きベクトルを定義するデータを含み得る。PUのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの分解能(たとえば、4分の1画素精度もしくは8分の1画素精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルのための参照ピクチャリスト(たとえば、リスト0、リスト1、もしくはリストC)を記述し得る。
1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換単位(TU)を含み得る。変換単位は、上で論じられたように、RQT(TU四分木構造とも呼ばれる)を使用して指定され得る。たとえば、分割フラグは、リーフCUが4つの変換単位に分割されるかどうかを示し得る。次いで、各変換単位は、さらなるサブTUにさらに分割され得る。TUは、それ以上分割されないとき、リーフTUと呼ばれ得る。一般に、イントラコーディングでは、1つのリーフCUに属するすべてのリーフTUは、同じイントラ予測モードを共有する。すなわち、同じイントラ予測モードは、一般に、リーフCUのすべてのTUに対する予測される値を計算するために適用される。イントラコーディングでは、ビデオエンコーダは、各リーフTUに対する残差値を、TUに対応するCUの部分と元のブロックとの間の差としてイントラ予測モードを使用して計算し得る。TUは、必ずしもPUのサイズに限定されるとは限らない。したがって、TUは、PUより大きくても小さくてもよい。イントラコーディングでは、PUは、同じCUのための対応するリーフTUと併置され得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに相当し得る。
その上、リーフCUのTUはまた、残差四分木(RQT)と呼ばれるそれぞれの四分木データ構造と関連付けられ得る。すなわち、リーフCUがTUへとどのように区分されているかを示す四分木を、リーフCUは含み得る。TU四分木のルートノードは一般に、リーフCUに対応し、一方、CU四分木のルートノードは一般に、ツリーブロック(またはLCU)に対応する。分割されないRQTのTUは、リーフTUと呼ばれる。一般に、本開示は、別段に記載されていない限り、リーフCUを指すためにCUという用語を、リーフTUを指すためにTUという用語を使用する。
HMは、区分モードとも呼ばれる、様々なPUサイズにおける予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズにおけるイントラ予測と、2N×2N、2N×N、N×2N、またはN×Nの対称PUサイズにおけるインター予測とをサポートする。
HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズにおけるインター予測のための非対称区分をサポートする。非対称区分では、CUの一方の方向は区分されないが、他方の方向は25%と75%に区分される。25%区分に対応するCUの部分は、「n」とその後に続く「Up」、「Down」、「Left」、または「Right」の指示によって示される。したがって、たとえば、「2N×nU」は、上の2N×0.5NのPUおよび下の2N×1.5NのPUへと水平方向に区分された2N×2NのCUを指す。
いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は、並列なPUを使用してCUを予測するためにSDIPモードを実装し得る。そのような例では、CUはhN×2Nの構成の4つのSDIP PUを用いて予測されることがあり、「h」は2分の1を表す。他の例では、CUは2N×hNの構成の4つのSDIP PUを用いて予測されることがある。以下で説明されるような、様々な非対称のSDIPモードと関連付けられるものなどの、他の区分構成も可能である。
変換係数を生成するための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、一般に、係数を表すために使用されるデータの量をできる限り低減するために変換係数が量子化され、さらなる圧縮が行われるプロセスを指す。量子化プロセスは、係数の一部またはすべてと関連付けられたビット深度を低減し得る。たとえば、nビット値は、量子化の間にmビット値に切り捨てられることがあり、ここでnは、mよりも大きい。
量子化に続いて、ビデオエンコーダは、変換係数を走査し、量子化された変換係数を含む2次元行列から1次元ベクトルを生成し得る。走査は、より高いエネルギー(それゆえより低い周波数)の係数をアレイの前方に置き、より低いエネルギー(それゆえより高い周波数)の係数をアレイの後方に置くように設計され得る。いくつかの例では、ビデオエンコーダ20は、エントロピー符号化されることが可能なシリアル化されたベクトルを生成するために、事前に定義された走査順を利用して量子化された変換係数を走査し得る。他の例では、ビデオエンコーダ20は、適応走査を実行し得る。
1次元ベクトルを形成するために量子化された変換係数を走査した後、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC:context adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法に従って、1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30によって使用するための符号化されたビデオデータと関連付けられたシンタックス要素をエントロピー符号化し得る。
ビデオエンコーダ20は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびピクチャのグループ(GOP)ベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはGOPヘッダの中で、ビデオデコーダ30に送ることができる。GOPシンタックスデータは、それぞれのGOPにおけるいくつかのフレームを記述することができ、フレームシンタックスデータは、対応するフレームを符号化するのに使用される符号化/予測モードを示すことができる。
ビデオデコーダ30は、コーディングされたビデオデータを受信すると、ビデオエンコーダ20に関して説明された符号化パスと全体的に逆の復号パスを実行し得る。本開示の様々な技法が以下で説明される。
いくつかの態様では、本開示の技法は、イントラモード依存の処理順序を対象とする。例示的なSDIPの技法によれば、サブブロックの処理順序は上から下および左から右である。SDIPの1つの潜在的な利点は、再構築された近隣の画素が、普通のイントラ予測のシナリオよりも、予測される画素にはるかに近くなる傾向があるということである。SDIPによれば、現在の画素がそれから予測される再構築された近隣の画素が現在の画素により近く位置しているので、SDIPは、現在の画素の予測の精度を改善することができる。しかしながら、SDIP予測順序が常に上から下および左から右である場合、以前にコーディングされたサブブロックの中の再構築された画素は、ビデオデコーダ30により完全には利用されないことがある。たとえば、イントラ予測方向が左下からである場合、イントラ予測は常に左下の画素から来る(たとえば、それに常に基づく)。
したがって、処理順序の上から下の態様は、現在の画素の予測精度を上げないことがあり、または別様に改善しないことがある。たとえば、SDIP処理順序の上から下への性質によれば、現在の画素が予測されるときに、左下の近隣の画素がまだ再構築されていないことがあるので、イントラ予測参照画素が利用可能ではない。同様に、イントラ予測が右上からである事例では、イントラ予測は常に右上の画素から来る(たとえば、それに常に基づく)。これらのシナリオでは、SDIP処理順序の左から右への性質は、予測精度を上げないことがあり、または別様に改善しないことがある。
本開示の態様によれば、ビデオエンコーダ20および/またはビデオデコーダ30は、様々な状況のもとで、左下のイントラ予測および右上のイントラ予測に対する処理順序を、それぞれ下から上および右から左に変更し得る。一般的に述べると、ビデオエンコーダ20およびビデオデコーダ30は、現在のCUのイントラ予測角度に基づいて処理順序を変更し得る。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、処理順序を変更するための本開示の技法を実施して、既存のSDIP処理順序では再構築された画素が利用不可能である状況に対処し得る。
イントラ予測方向が左下である場合に下から上の処理順序を実施することによって、ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施して、イントラ予測方向が左下である事例において予測精度を向上または改善することができる。たとえば、既存のSDIP技術の上から下への処理順序が左下のイントラ予測方向と組み合わされる場合、左下のブロックまたは行からの再構築された画素は、まだ利用可能ではないことがある(たとえば、再構築された画素がまだコーディングされていないことがある)。たとえば、左下のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ再構築されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、ビデオエンコーダ20およびビデオデコーダ30は、現在のCUに隣り合って位置しているCUなどの、別のCUにおいてすでに再構築されている画素を使用する必要があり得る。SDIP関連の技法の説明に関して本明細書において使用される場合、ブロックまたは行を記述するために使用されるときの「左下」という用語は、現在のCUの下および現在のCUの左に位置するブロックまたは行を記述する。たとえば、「左下の近隣のブロック」または「左下の近隣の画素」は、現在のCUまたは画素のすぐ下およびすぐ左に位置し得る。
同様に、イントラ予測方向が右上である場合に右から左の処理順序を実施することによって、ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施して、イントラ予測方向が右上である事例において予測精度を向上または改善することができる。たとえば、既存のSDIP技術の左から右への処理順序が右上のイントラ予測方向と組み合わされる場合、右上のブロックまたは行からの再構築された画素は、まだ利用可能ではないことがある。たとえば、右上のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ再構築されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、ビデオエンコーダ20およびビデオデコーダ30は、現在のCUに隣り合って位置しているCUなどの、別のCUにおいてすでに再構築されている画素を使用する必要があり得る。SDIP関連の技法の説明に関して本明細書において使用される場合、ブロックまたは行を記述するために使用されるときの「右上」という用語は、現在のCUの上および現在のCUの右に位置するブロックまたは行を記述する。
既存のSDIP技術が、ビデオエンコーダ20および/またはビデオデコーダ30に、現在のCUのSDIPベースのコーディングのために異なるCUの中に位置する画素を使用させる事例では、コーディング精度が損なわれ得る。たとえば、SDIPのために使用されている画素は、SDIP処理順序がイントラ予測方向/角度によればすでに再構築されている画素を提供するときに一般に使用される画素よりも、現在のCUの現在コーディングされている画素から遠くに位置している。現在のCUの現在コーディングされている画素とSDIPのために使用されている画素との間の距離の増大により、現在のCUに関する予測精度は低下することがあり、それは、予測に使用される画素間のより大きな距離が画素間のより低い相関をもたらし得るからである。
ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施し、SDIPベースのコーディングの精度を改善することができる。より具体的には、ビデオエンコーダ20およびビデオデコーダ30は、この技法を実施して、上で説明されたものなどのあるイントラ予測方向/角度が原因で再構築されていない画素に遭遇することにより必然的に生じる画素間の距離の増大を、軽減しまたは場合によってはなくすことができる。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、あるビデオコーディング特性に応答して、SDIPベースのコーディングを実行するときに下から上および/または右から左の処理順序に切り替えることができる。たとえば、ビデオエンコーダ20およびビデオデコーダ30は、特定のイントラ予測方向/角度の使用に基づいて、SDIPベースのコーディングの処理順序を適応させることができる。
その上、本開示の技法は、イントラ予測方向が左下または右上の場合にのみ処理順序を変更することを対象とするので、ビデオエンコーダ20およびビデオデコーダ30は、残りのイントラ予測方向に関してSDIPによりもたらされる利点を維持しながら、イントラ予測方向が左下と右上のいずれかである場合にSDIPベースのコーディングの精度を改善するために変更された処理順序を活用することができる。言い換えると、ビデオエンコーダ20およびビデオデコーダ30は、本開示のSDIP処理順序の適応がSDIPベースのコーディングによりもたらされるコーディング精度を潜在的に改善するシナリオではその適応を実施しながら、適応が潜在的な精度の向上を生まない可能性があるシナリオでは既存のSDIP処理順序を守ることができる。このようにして、本明細書において説明される技法は、ビデオエンコーダ20およびビデオデコーダ30が、残りのシナリオにおいてSDIPの利点に悪影響を及ぼすことなく、あるシナリオにおいてSDIPベースのコーディングの予測精度を改善することを可能にし得る。
本開示の他の態様は、SDIPコーディングに従ってコーディング済ブロックフラグ(CBF)予測を対象とする。CBFシンタックス要素は、変換係数のブロックまたはブロック(「変換係数レベル」とも呼ばれる)が何らかの0ではない変換係数またはレベルを含むかどうかを示す。しばしば、残差が連続するサブブロックに位置する。したがって、連続するサブブロックのCBF値は、多くのシナリオでは同じであり得る。多くの事例では、CBF値は、連続するサブブロックの比較的長いランに対して同じであり得る。たとえば、いくつかの連続するサブブロックは各々、少なくとも1つの0ではない変換係数を含み得る。したがって、サブブロックのランは、ビデオエンコーダ20に、「1」という中断されない一連のCBF値を符号化させてビデオデコーダ30へシグナリングさせ得る。
たとえば、現在のブロックの各行または線は、別個のCBFと関連付けられ得る。各CBFは、それぞれの関連する線が少なくとも1つの0ではない変換係数または変換係数レベルを含むか否かを示し得る。多くの事例では、ブロックのいくつかの連続する線は、0ではない変換係数の存在を確認されるときに同じ結果を生み出すことによって、同じCBF値を生成し得る。ビデオエンコーダ20は、本開示の技法を実施して、線と線の間でのCBFの遷移に基づいてCBFマスクを符号化し、ブロックの再構築のためにマスクをビデオデコーダ30にシグナリングすることができる。CBFはフラグであり、したがって所与の線に関して「0」と「1」のいずれかの値を有するので、CBF値のあらゆる変化を「トグリング」動作と表現することができる。
本開示のCBFマスキング技法によれば、ビデオエンコーダ20は、現在コーディングされている線のCBF値とSDIPコーディングされたブロックの直前の(たとえば、上の)線のCBF値との差を符号化およびシグナリングすることによって、SDIPコーディングされたブロックの現在コーディングされている線のCBFを示すことができる。たとえば、現在の線のCBF値が現在の線のすぐ上に位置する線のCBF値と異なることをビデオエンコーダ20が決定する場合、ビデオエンコーダ20は1という値を有するCBFマスクを符号化することができる。言い換えると、本開示のCBFマスキング技法によれば、1というCBFマスク値は、直前にコーディングされたSDIPサブブロック(この例では線)からのCBF値の遷移を示す。
CBFマスキング技法は、1つの特定の限定しない例に関して以下で説明される。この例では、ビデオエンコーダ20は、ブロックの一番上の線のCBF値が1という値を有し、上から2番目の線のCBF値が0であり、上から3番目の線のCBF値が1であり、上から4番目の線のCBF値が0であることを決定し得る。したがって、この例では、ビデオエンコーダ20は、SDIPコーディングされたブロックの上の4本の線に関して、1010という一連のCBF値を特定することができる。本開示のCBFマスキング技法によれば、ビデオエンコーダ20は、上から2番目以降の線のCBF値に関して、遷移を示す値を符号化およびシグナリングすることができる。
たとえば、SDIPコーディングされるブロックの一番上の線は、CBF予測をそこから実行する直前の線を有しないので、ビデオエンコーダ20は、一番上の線のCBF値をCBFマスクとして直接符号化することができる。上で論じられた例では、ビデオエンコーダ20は、ブロックの一番上の線のCBFマスクとして、1というCBF値を符号化することができる。そして、ビデオエンコーダ20は、1番目の線のCBFに関する遷移インジケータとして2番目の線のCBFマスクをコーディングすることができ、2番目の線のCBFに関する遷移インジケータとして3番目の線のCBFマスクをコーディングすることができ、以下同様である。この例では、ブロックの上から2番目の線は0の値を伴うCBFを有するので、ビデオエンコーダ20は、一番上の線のCBF値から2番目の線のCBF値への遷移を検出することができる。したがって、ビデオエンコーダ20は、2番目の線に関して「1」というCBFマスクを符号化することができる。
そして、ビデオエンコーダ20は、上から3番目の線に対する「0」というCBF値が2番目の線のCBF値からの遷移を示すと決定することができ、検出された遷移に基づいて、3番目の線に対して「1」というCBFマスクを符号化することができる。加えて、ビデオエンコーダ20は、上から4番目の線に対する「1」というCBF値が3番目の線のCBF値からの遷移を示すと決定することができ、検出された遷移に基づいて、4番目の線に対して「1」というCBFマスクを符号化することができる。したがって、上で説明された例では、ビデオエンコーダ20は、SDIPコーディングされたブロックの最初の4本の線に対して「1111」という一連のCBFマスク値を符号化することができる。
「1010」という生の一連のCBF値の直接の符号化と比較して、「1111」という一連のCBFマスクは、ビデオエンコーダ20によるより効率的な符号化と、ビデオデコーダ30によるより効率的な復号とを可能にし得る。上で説明されたシナリオは、本開示のCBFマスキング技法が、一連の線のCBFが交互の値をとる状況においてビデオエンコーダ20およびビデオデコーダ30がコーディング効率を改善することを可能にする、例を表す。本開示のCBFマスキング技法はまた、SDIPコーディングされたブロックの線が連続する同一のCBF値のランをもたらすシナリオにおいてビデオエンコーダ20およびビデオデコーダ30がコーディング効率を改善して帯域幅を節約することも可能にし得ることが理解されるだろう。たとえば、ブロックの最初の10本の線の各々が少なくとも1つの0ではない変換係数を含む場合、最初の10本の線はすべて1というCBF値を生み出す。
この例では、ブロックの最初の一連のCBF値は「1111111111」である。本開示のCBFマスキング技法を使用すると、ビデオエンコーダ20は、最初の線に対して「1」というCBF値を符号化し、次いで、次の9本の線にわたり遷移がないことを示すために「000000000」という9ビットの列をコーディングすることができる。CBFマスキング技法の逆の態様を実行する際、ビデオデコーダ30は、「1」という最初の値を復号して最初の線に対する生のCBF値を得ることができる。そして、ビデオデコーダ30は、最初のCBFから10番目のCBFまで値の遷移がないことに基づいて、「0」の連続するマスク値を使用して「1」という9個の連続するCBF値を再構築することができる。このようにして、本開示のCBFマスキング技法は、ビデオエンコーダ20およびビデオデコーダ30が、SDIPコーディングされたブロックの各線をバイナリベクトルとして使用し、それにより、既存のSDIPベースのコーディング技術と比較してより効率的に各線のCBF値を推測することを可能にする。
その上、ビデオエンコーダ20およびビデオデコーダ30は、SDIPコーディングされたブロックのCBF値のCABACコーディングまたはエントロピーコーディングに対するコンテキストを導出することができる。最初の4つのCBF値が「1010」である上で説明された例では、ビデオエンコーダ20は、ある特定の線のCABACコンテキストを、その特定の線の直前の線のCABACコンテキストに基づいて適応させることができる。たとえば、ビデオエンコーダ20は、ある線のCBFフラグの最も可能性の高いCABACコンテキストを、先行する線のCBFフラグのために使用されるCABACコンテキストに基づいて予測することができる。先行する線のCBFをコーディングするために使用されるCABACコンテキストから現在の線のCBFのCABACコンテキストを予測することによって、ビデオエンコーダ20は、コンテキストシグナリングによって消費されるビットレートを節約することができる。いくつかの事例では、ビデオエンコーダ20は、最も可能性の高いコンテキストを予測することによって、コンテキストシグナリングに必要なビットの数を2.3ビットから0.3ビットに減らすことができる。このようにして、本開示のCBFマスキング技法は、ビデオエンコーダ20がシグナリングに関して大きなビットレートの低減を実施することを可能にでき、ビデオエンコーダ20およびビデオデコーダ30がCABACコンテキストを導出することに関するコンピューティングリソースを節約し、複雑さを下げることを可能にし得る。
本明細書において説明される技法によれば、ビデオエンコーダ20は、1つまたは複数の以前にコーディングされたサブブロックからある特定のサブブロックのCBFを予測することができる。一例として、ビデオエンコーダ20は、最新のコーディングされたサブブロックのCBF値から現在のサブブロックのCBFを予測することができる。いくつかの例示的な実装形態によれば、ビデオエンコーダ20は、現在のサブブロックのCBFと、1つまたは複数の以前にコーディングされたサブブロック(または、たとえば単なる最新のコーディングされたサブブロック)から生成される予測されるCBFとの差を、シグナリングすることができる。現在のサブブロックのCBFと予測されるCBFとの差をシグナリングすることによって、ビデオエンコーダ20は、コンピューティングリソースおよび帯域幅を節約しながら、ビデオデコーダ30が現在のサブブロックのCBF値を正確に導出することを可能にできる。別の例示的な実装形態では、ビデオエンコーダ20および/またはビデオデコーダ30は、以前にコーディングされたサブブロックに基づいてエントロピーコーディングのための異なるコンテキストを設計することができる。
本明細書において説明される様々な例は、サブブロックに相当するものとして線を使用する(たとえば、「線」は単一の画素の行または単一の画素の列を表す)が、本開示の技法は異なるサブブロックの形状および構成にも適用可能であることが理解されるだろう。たとえば、サブブロックは、線の不完全な部分を形成することがあり、線を形成することがあり、または場合によっては複数の線の部分にわたることがある。
加えて、ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施して、サブブロックに対する最終有意係数(last_pos)の場所をCABACコーディングまたはエントロピーコーディングするためのコンテキストを選択することができる。last_pos情報は、TU内の最終有意係数の水平方向および垂直方向(xおよびy)座標を示し得る。ビデオデコーダ30は、最終有意係数の場所を使用して、ビットストリームのデータが後続のシンタックス要素、すなわち再生成されているブロックのデータを表さないシンタックス要素をいつ表すかを決定することができる。サブブロックのCBF以外に、サブブロックの最終有意係数の場所は、以前にコーディングされたサブブロックのlast_posにも依存する。本明細書において説明される技法によれば、ビデオエンコーダ20および/またはビデオデコーダ30は、1つまたは複数の以前にコーディングされた(たとえば、以前に符号化または以前に復号された)サブブロックに対するlast_pos情報の振幅に基づいて、最終有意係数の場所のエントロピーコーディングのためのコンテキスト設計を計算することができる。
1つの例示的な使用事例では、ビデオエンコーダ20および/またはビデオデコーダ30は、最終有意係数をエントロピーコーディングするための「コンテキストセット1」と「コンテキストセット2」の中から選択することができる。この例では、以前にコーディングされたサブブロック(たとえば、直前にコーディングされたサブブロック)に対するlast_pos値が0より大きい場合、ビデオエンコーダ20および/またはビデオデコーダ30は、現在のサブブロックの最終有意係数をCABACコーディングまたはエントロピーコーディングするためにコンテキスト1を使用することができる。それ以外の場合(たとえば、以前にコーディングされたサブブロックのlast_posが0以下である場合)、ビデオエンコーダ20および/またはビデオデコーダ30は、現在のサブブロックの最終有意係数をエントロピーコーディングするためにコンテキストセット2を使用することができる。このようにして、本開示の技法は、ビデオエンコーダ20およびビデオデコーダ30が、現在のサブブロックに対するlast_pos情報をコーディングする際に用いるコンテキストを導出するために、以前にコーディングされたサブブロックからのlast_pos情報を活用することを可能にする。
いくつかの態様では、本開示は、量子化パラメータの差分/デルタ(本明細書では「デルタQP」と呼ばれる)を使用することによる変換精度操作を対象とする。SDIPコーディングされたブロックに関して本明細書において説明されるが、本開示の変換精度操作技法は、他のタイプのコーディング(たとえば、イントラコーディングおよび/またはインター予測)にも適用可能であることが理解されるだろう。
いくつかの使用事例のシナリオでは、長方形ブロックの使用は、正方形ブロックを使用するときには生じないコンピューティング上および/または計算上の検討事項に関する1つまたは複数の潜在的な問題を引き起こし得る。TUのQPサイズは√(w*h)として計算され、ここで「√」は平方根関数を表し、「w」はTUの幅を表し、「h」はTUの高さを表す。正方形ブロックの場合、QPサイズは、上で説明されたように計算されると、常に整数値である。より具体的には、wとhの値が正方形ブロックでは等しいので、(w*h)の積の平方根は常にwに等しくhに等しい値である。より具体的には、64対64などの一般的に使用される正方形ブロックサイズでは、QPサイズは2の整数倍になる傾向がある。したがって、正方形ブロックにわたる量子化の分布は、行列計算および他の要因が原因で、2のべき乗を伴い得る。
しかしながら、ビデオコーディングにおいて一般に使用される大半の長方形ブロックのフォームファクタでは、√(w*h)演算の結果は2の平方根の整数倍であり、これは約1.414に等しく本明細書では√2と表記される。たとえば、一般に使用される長方形ブロックのサイズの1つが4×8である。4×8のブロックの場合、QPサイズの計算は√(4*8)演算を要求し、これは√32という値をもたらす。√32は√2の倍数であり、具体的には4*√2に等しい。同様に、8×16の次元の長方形ブロックは8*√2というQPサイズを生み出し、16×32の次元の長方形ブロックは16*√2というQPサイズを生み出し、以下同様である。
したがって、長方形ブロックのためのQPサイズ計算の非整数の結果は、本明細書では「√2問題」と呼ばれる。√2問題は、QPサイズについて浮動小数点の値を生み出し、これらの値の浮動小数点の性質をなくすためのあらゆる丸め演算が、コーディング精度の損失をもたらす。変換サイズの増大とともに、√2問題の浮動小数点の結果に起因するコーディング精度の問題はより厳しくなる。HEVCは、0から51の範囲に入り得るスケーリングパラメータQPを使用した、均一な再構築量子化を記載する。HEVC量子化技法によれば、QP値の1の増大が、対応する量子化ステップサイズ(「Qstep」)の約12パーセント(12%)の増大をもたらし得る。たとえば、Qstepの12%の増大は、生のQstep値の2と6分の1(21/6)の増大を表し得る。QP値の対応する増大により引き起こされる増分的なQstepの増大に基づいて、QstepはQPが6増大するたびに2倍になる。Qstepが4というQPに対して1に等しい事例では、直交変換に対するQP値と対応するQstepとの関係は次の式により与えられる。
Qstep(QP) = 2(QP-4)/6
多くの一般に使用される長方形TUのサイズの量子化と関連付けられる√2問題に対処するために、ビデオエンコーダ20および/またはビデオデコーダ30は、本開示の変換精度操作技法のうちの1つまたは複数を実施することができる。
変換単位(TU)サイズが式2 n x2 mまたは2 n-by-2 m(「2 n」は行の数を表し「2 m」は列の数を表す)により表記される場合、順方向の変換は次の式により表される。
Y = T2 n . X2 n x2 m . T2 m
上の式において使用される表記によれば、X2 n x2 mは行の数「n」および列の数「m」を伴う残差ブロックを表す。したがって、上の式において使用される項X2 n x2 mは、「2n」に等しい行の数および「2m」に等しい列の数を伴う残差ブロックを表す。TvおよびThは、列および行の変換のための対応する2n×2n(2n対2n)および2m×2m(2m対2m)の行列であり、Yは係数行列を表す。いくつかの例では、nまたはmの1つが0に等しい。
本明細書において説明される変換精度操作技法の1つまたは複数によれば、演算(n+m)が奇数をもたらすとき、ビデオエンコーダ20および/またはビデオデコーダ30は、対応するTUデータの量子化または逆量子化のために、デルタQP値を現在の変換単位と関連付けられる導出されたQP値に加算することができる。デルタQPを導出されたQP値に加算することによって、ビデオエンコーダ20およびビデオデコーダ30は、正方形の変換のために定義された元のスケーリング係数を使用することができる。たとえば、元のスケーリング係数が定義された対象の正方形の変換は、K対Kの次元を有するものとして表現され得る。正方形の変換の一辺の大きさを表す「K」の値は、いくつかの例では((n+m)>>1)として、または他の例では((n+m+1)>>1)として定義され得る。演算子「>>」は算術的な右シフト演算を表し、上で説明されたように、「n」は残差ブロックの行の数を表し、「m」は残差ブロックの列の数を表す。
ある例として、4×8の変換に対して、ビデオエンコーダ20およびビデオデコーダ30は、4×4の変換または8×8の変換のために定義されたスケーリング係数を継承することができる。この例では、より小さな変換サイズ(たとえば、上で説明された例では4×4)に対するスケーリング係数に従って量子化または逆量子化を実施する前に、ビデオエンコーダ20およびビデオデコーダ30は、変換係数のエネルギーを(1/√2)倍に減らすことができ、これは約30%の低減になる。そして、低減されたエネルギーを相殺するために、ビデオエンコーダ20およびビデオデコーダ30は、対応するQstepを√2だけ減らすことができる。
上で説明されたように、QPの1の増大は、対応するQstepに約12%の増大をもたらし得る。したがって、QPの1の減少は、対応するQstepに約12%の下落または減少をもたらし得る。加えて、エネルギーがおよそ30%低減された変換係数に対して、ビデオエンコーダ20およびビデオデコーダ30は、対応するQPを3だけ減らすことによってエネルギー低減を相殺することができる。3というQPの低減は、式ceiling(30%/12%)に従って導出され、ここでceiling()演算はオペランドの最大の可能な値を返す。したがって、この例では、デルタQP値は-3(マイナス3(negative three)またはマイナス3(minus three))に常に設定される。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、現在の変換単位と関連付けられる導出されたQP値に基づいて、デルタQP値を適応的に変更することができる。
図2は、本開示において説明されるようなイントラ予測コーディングのための技法を使用することができるビデオエンコーダ20の例を示すブロック図である。例示のために、ただし、変換係数の走査を必要とし得る他のコーディング規格または方法に関して本開示を限定することなく、ビデオエンコーダ20がHEVCコーディングの文脈で説明される。
ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベース圧縮モードのうちのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのうちのいずれかを指し得る。
図2に示されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照ピクチャメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピー符号化ユニット56とを含む。モード選択ユニット40は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、区分ユニット48とを含む。ビデオブロック再構築のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。再構築されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングするための、(図2に示されていない)デブロッキングフィルタも含まれ得る。所望される場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタリングする。追加のフィルタ(ループ内またはループ後)もデブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタリングし得る。
符号化プロセスの間に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間圧縮を提供するために、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対して受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は代替的に、空間的圧縮を行うために、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の近隣のブロックに対する受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータの各ブロックに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
その上、区分ユニット48は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット48は、最初にフレームまたはスライスをLCUに区分し、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブCUに区分し得る。モード選択ユニット40は、さらに、LCUをサブCUに区分することを示す四分木データ構造を生成し得る。四分木のリーフノードCUは、1つまたは複数のPUと1つまたは複数のTUとを含み得る。
モード選択ユニット40は、たとえば、誤差結果に基づいて、コーディングモード、イントラまたはインターのうちの1つを選択し、残差ブロックデータを生成するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器50に提供し、参照フレームとして使用するための符号化されたブロックを再構築するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器62に提供し得る。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット56に提供する。
動き推定ユニット42および動き補償ユニット44は、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(または他のコーディングされたユニット)内でコーディングされている現在のブロックに対する相対的な、参照フレーム(または他のコーディングされたユニット)内の予測ブロックに対する相対的な現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。予測ブロックは、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分尺度によって決定され得る画素差分に関して、コーディングされるべきブロックとよく一致することが判明しているブロックである。いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数画素位置のための値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの4分の1画素位置の値、8分の1画素位置の値、または他の分数画素位置の値を補間し得る。したがって、動き推定ユニット42は、フル画素位置および分数画素位置に対する動き探索を実行し、分数画素精度で動きベクトルを出力し得る。
動き推定ユニット42は、PUの場所を参照ピクチャの予測ブロックの場所と比較することによって、インターコーディングされたスライスの中のビデオブロックのPUの動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されることがあり、それらの各々が、参照ピクチャメモリ64に記憶された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は、ビデオデータのブロックを予測するときにSDIPモードを選択し得る。たとえば、上で述べられたように、イントラ予測ユニット46は、レートひずみ分析を実行して最良のレートひずみ特性を有するイントラ予測モードを決定し得る。加えて、イントラ予測ユニット46は、レートひずみ分析を実行して、イントラ予測のための1つまたは複数のPUへのCUの区分を決定し得る。すなわち、特定のCUのサイズが2N×2Nであると仮定すると、イントラ予測ユニット46は、2N×2NのPUを使用してCUを全体として予測するか、4つの等しいサイズのN×NのPUを使用してCUを予測するか、またはいくつかの並列なPUを使用して(たとえば、SDIPモード2N×hNまたはnN×2Nを使用して)CUを予測するかを、決定し得る。イントラ予測ユニット46に関して説明されるが、CUの区分は(または代替的に)区分ユニット48によって決定されることがある。
いずれの場合でも、本開示の態様によれば、イントラ予測ユニット46は、区分モードとは無関係に、1つまたは複数の区分モードテーブルを使用してある特定の区分モードを示し得る。たとえば、イントラ予測ユニット46は、SDIPモードの場合も含めて、CUを1つまたは複数のPUへと区分するための予測区分モードを、区分モードテーブルを使用して示し得る。
いくつかの事例では、イントラ予測ユニット46は、コーディングの間にあるイントラ予測モードを使用することを制限され得る。たとえば、イントラ予測ユニット46は、所定の基準が満たされていない限り、1つまたは複数のイントラ予測モードを使用するのを制限され得る。説明を目的とする例では、イントラ予測ユニット46は、CUが所定のサイズ(たとえば、64×64、32×32など)より大きくない限り、SDIPモードを使用しないことがある。いくつかのそのような例では、区分モードテーブルは、その基準に基づく別々のマッピングを含み得る。すなわち、たとえば、ある特定の区分モードは、64×64以上のCUに対する第1のビンストリングおよび64×64未満のCUに対する第2の異なるビンストリングにマッピングし得る。
いくつかの事例では、イントラモード予測ユニット46は、2つ以上の区分モードテーブルを維持し得る。たとえば、イントラ予測ユニット46は、すべてのスライス(たとえば、Iスライス、Pスライス、およびBスライス)に対する単一の区分モードテーブルを維持し得る。しかしながら、別の例では、イントラ予測ユニット46は、異なるスライスタイプに対して別々の区分モードテーブルを維持し得る。すなわち、イントラ予測ユニット46は、Pスライスおよび/またはBスライスのために使用されるものとは別個の、Iスライスのためのテーブルを維持し得る。
イントラ予測ユニット46が2つ以上の区分モードテーブルを維持する事例では、イントラ予測ユニット46は、様々な要因に基づいて区分モードテーブルを選択し得る。たとえば、イントラ予測ユニット46が異なるスライスタイプ(たとえば、I/P/Bスライス)に対して別々のテーブルを維持する事例では、イントラ予測ユニット46は、コーディングされているブロックのスライスタイプに基づいて区分モードテーブルを選択し得る。他の例では、イントラ予測ユニット46は、ピクチャサイズ、フレームレート、量子化パラメータ(QP)、CU深度などに基づいて区分モードテーブルを選択し得る。そのような情報は一般に、ビデオエンコーダ20とビデオデコーダ30の両方に知られている。したがって、選択基準がビットストリームに含まれる必要はない。しかしながら、他の例では、区分モードテーブルの選択のためのデータは、1つまたは複数のシンタックス要素を使用してビットストリームにおいてシグナリングされることがあり、そのような1つまたは複数の高水準シンタックス要素はパラメータセットに含まれる。
イントラ予測ユニット46は、本開示の様々な技法を実施して、1つまたは複数の条件を検出したことに基づいてSDIP符号化されたブロックのサブブロックの処理順序を適応させ得る。上で論じられたように、SDIPによれば、サブブロックの処理順序は上から下および左から右である。SDIPは、再構築された近隣の画素が予測された画素にはるかに近い傾向があるという、他のイントラ予測モードを上回る潜在的な利点をもたらす。再構築された近隣の画素が現在の画素に比較的近いので、SDIP技術は現在の画素の予測の精度を向上させる傾向がある。
しかしながら、既存のSDIP技術の予測順序は常に上から下および左から右なので、イントラ予測ユニット46は、現在の画素を符号化するときに以前にコーディングされたサブブロックの中の符号化された画素を完全に活用することが常には可能ではないことがある。たとえば、イントラ予測方向が左下からである場合、現在の画素は常に、現在の画素の下および左に位置する1つまたは複数の画素から(すなわち、現在の画素に関して1つまたは複数の「左下の」画素から)イントラ予測される。同様に、イントラ予測方向が右上からである場合、現在の画素は常に、現在の画素の上および右に位置する1つまたは複数の画素から(すなわち、現在の画素に関して1つまたは複数の「右上の」画素から)イントラ予測される。
しかしながら、上から下および左から右の処理順序は、いくつかのシナリオでは現在の画素の予測精度を改善しないことがあり、場合によっては予測精度を下げ、または妨げることがある。たとえば、SDIP処理順序の上から下への性質によれば、イントラ予測ユニット46が現在の画素を予測するのを開始する準備ができているときに、左下の近隣の画素がまだ再構築されていないことがある。同様に、SDIP処理順序の左から右への性質によれば、イントラ予測ユニット46が現在の画素を予測するのを開始する準備ができているときに、右上の近隣の画素がまだ再構築されていないことがある。したがって、いくつかのシナリオでは、イントラ予測ユニット46は、イントラ予測ユニット46がSDIP処理順序に従って現在の画素を予測する準備ができている時間に、イントラ予測参照画素を入手できないことがある。
イントラ予測ユニット46は、本開示の技法を実施して、現在の画素の符号化に関して特定のイントラ予測方向が当てはまることを検出したことに基づいて、左下イントラ予測および右上イントラ予測のための処理順序を、それぞれ下から上および右から左に変更することができる。言い換えると、イントラ予測ユニット46は、現在のCUのイントラ予測角度に基づいて処理順序を変更することができる。たとえば、イントラ予測ユニット46は、本開示の技法を実施して、ある条件の下で処理順序を変更し、既存のSDIP処理順序では現在の画素をイントラ予測する際に符号化された参照画素が利用不可能であるシナリオに対処することができる。
本明細書において説明される技法によれば、イントラ予測ユニット46は、イントラ予測角度が左下である場合、SDIP符号化されたサブブロックに関して下から上の処理順序を実施し得る。イントラ予測ユニット46が下から上となるように処理順序を変更する場合、イントラ予測ユニット46は既存のSDIPベースのコーディング技術の左から右への態様を維持し得ることが理解されるだろう。対応するイントラ予測角度が左下である場合に、SDIPコーディングされたブロックの処理順序を(左から右への態様を保ったまま)下から上に変更することによって、イントラ予測ユニット46は、本開示の技法を実施して現在のブロックの予測の精度を向上させることができる。たとえば、既存のSDIP技術の上から下の処理順序が左下のイントラ予測角度と組み合わされる場合、イントラ予測ユニット46が、現在の画素をイントラ予測するのに必要であり得る左下のブロックまたは行からの符号化された画素を入手できないことがある。このシナリオでは、左下のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ符号化されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、イントラ予測ユニット46は、近隣のブロックなどの別のブロックにおいてすでに符号化されている画素を使用する必要があり得る。
しかしながら、イントラ予測方向が左下である場合にSDIPコーディングされたブロックの処理順序を下から上に切り替えることによって、イントラ予測ユニット46は、現在のサブブロックのSDIPベースの符号化を実施するために、現在の画素に近接して位置する参照画素を活用し続けることができる。SDIPコーディングされたブロックに関して下から上への処理順序を使用することによって、イントラ予測ユニット46は、現在の画素をイントラ予測するための参照画素として符号化された左下の近隣の画素が利用可能であるような方式で、SDIPベースのイントラ予測を実施することができる。たとえば、イントラ予測ユニット46が下から上の順序でSDIPコーディングされたサブブロックの画素を処理するので、下側の近隣の画素、およびそれらの下側の近隣の画素は、定義上、現在の画素の処理をイントラ予測ユニット46が開始する前にすでに符号化されている。したがって、イントラ予測ユニット46は、イントラ予測角度が左下である場合、本開示の様々な態様に従って予測精度を向上させるために、下から上および左から右となるようにSDIP処理順序を適合させることができる。
加えて、本明細書において説明される技法によれば、イントラ予測ユニット46は、イントラ予測角度が右上である場合、SDIP符号化されたサブブロックに関して右から左の処理順序を実施し得る。イントラ予測ユニット46が右から左となるように処理順序を変更する場合、イントラ予測ユニット46は既存のSDIPベースのコーディング技術の上から下への態様を維持し得ることが理解されるだろう。対応するイントラ予測角度が右上である場合に、SDIPコーディングされたブロックの処理順序を(上から下への態様を保ったまま)右から左に変更することによって、イントラ予測ユニット46は、本開示の技法を実施して現在のブロックの予測の精度を向上させることができる。たとえば、既存のSDIP技術の左から右の処理順序が右上のイントラ予測角度と組み合わされる場合、イントラ予測ユニット46が、現在の画素をイントラ予測するのに必要であり得る右上のブロックまたは行からの符号化された画素を入手できないことがある。このシナリオでは、右上(top-right)(代替的に、「右上(above-right)」)のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ符号化されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、イントラ予測ユニット46は、近隣のブロックなどの別のブロックにおいてすでに符号化されている画素を使用する必要があり得る。
しかしながら、イントラ予測方向が右上である場合にSDIPコーディングされたブロックの処理順序を右から左に切り替えることによって、イントラ予測ユニット46は、現在のサブブロックのSDIPベースの符号化を実施するために、現在の画素に近接して位置する参照画素を活用し続けることができる。SDIPコーディングされたブロックに関して右から左への処理順序を使用することによって、イントラ予測ユニット46は、現在の画素をイントラ予測するための参照画素として符号化された右上の近隣の画素が利用可能であるような方式で、SDIPベースのイントラ予測を実施することができる。たとえば、イントラ予測ユニット46が右から左の順序でSDIPコーディングされたサブブロックの画素を処理するので、右側の近隣の画素、およびそれらの右側の近隣の画素は、定義上、現在の画素の処理をイントラ予測ユニット46が開始する前にすでに符号化されている。したがって、イントラ予測ユニット46は、イントラ予測角度が右上である場合、本開示の様々な態様に従って予測精度を向上させるために、右から左および上から下となるようにSDIP処理順序を適合させることができる。
イントラ予測ユニット46は、上で説明された技法を実施してイントラ予測角度が左下または右上の場合にのみ処理順序を変えることができるので、イントラ予測ユニット46は、残りのイントラ予測方向に関してSDIPによりもたらされる利点を維持しながら、イントラ予測方向が左下と右上のいずれかである場合にSDIPベースのコーディングの精度を改善するために変更された処理順序を活用することができる。言い換えると、イントラ予測ユニット46は、本開示のSDIP処理順序の適応がSDIPベースのコーディングによりもたらされるコーディング精度を潜在的に改善するシナリオでのみその適応を実施しながら、適応が潜在的な精度の向上を生まない可能性があるシナリオでは既存のSDIP処理順序を守ることができる。このようにして、イントラ予測ユニット46は、本明細書において説明される技法を実施して、残りのシナリオにおいてSDIPの利点に悪影響を及ぼすことなく、あるシナリオにおいてSDIPベースのコーディングの予測精度を向上させることができる。
SDIPベースのコーディングならびに他のコーディングモードの場合、イントラ予測ユニット46は、本開示の様々な技法を実施して、CBF値のサブブロックごとの遷移に基づいてCBFマスクを符号化することができる。議論を簡単にするためだけに、CBFマスキング技法はSDIPコーディングされたブロックに関して本明細書において論じられるが、イントラ予測ユニット46はまた、SDIP関連ではない技術を使用してコーディングされたブロックに関しても本開示のCBFマスキング技法を実施できることが理解されるだろう。
CBFはフラグであるので、所与のCBFは所与のサブブロックに関して「0」または「1」のいずれかの値を有する。したがって、CBF値のあらゆる遷移がトグリング動作を表す。本開示のCBFマスキング技法によれば、イントラ予測ユニット46は、現在コーディングされているサブブロックのCBF値とSDIPコーディングされたブロックの直前のサブブロックのCBF値との差を符号化することによって、現在コーディングされているサブブロックのCBF値の指示を与えることができる。たとえば、現在のサブブロックのCBF値が現在のサブブロックの直前(たとえば、上から下の処理順序では上、または下から上の処理順序では下)に位置するサブブロックのCBF値と異なることをイントラ予測ユニット46が決定する場合、イントラ予測ユニット46は1という値を有するCBFマスクを符号化することができる。言い換えると、本開示のCBFマスキング技法によれば、1というCBFマスク値は、直前に符号化されたSDIPサブブロックからのCBF値の遷移を示す。
たとえば、SDIPコーディングされたブロックの10個の最初の符号化されたサブブロックの各々が少なくとも1つの0ではない変換係数を含む場合、イントラ予測ユニット46は、最初の10個の符号化されたサブブロックの各々が1というCBF値を生み出すと決定することができる。この例では、SDIPコーディングされたブロックの最初(たとえば、上から下の処理順序では一番上の、または下から上の処理順序では一番下)にある一連のCBF値は、「1111111111」である。本開示のCBFマスキング技法を使用すると、イントラ予測ユニット46は、最初のサブブロックに対して「1」という生のCBF値を符号化し、次いで、次の9個のサブブロックにわたり遷移がないことを示すために「000000000」という9ビットの列を符号化することができる。このようにして、イントラ予測ユニット46は、本開示のCBFマスキング技法を実施して、SDIPコーディングされたブロックの各々の個別のサブブロックをバイナリベクトルとして使用し、それにより、CBFマスクを使用して各線のCBF値を示唆することができる。本開示のCBFマスキング技法を実施することによって、イントラ予測ユニット46は、既存のCBFコーディング技法と比較して、リソース消費を減らし符号化の複雑さを下げながら、CBF精度を維持することができる。
いくつかの例では、イントラ予測ユニット46は、SDIPコーディングされたブロックのCBF値のCABACコーディングまたはエントロピーコーディングに対するコンテキストを導出することができる。最初の10個のCBF値が「1111111111」である上で説明された例では、イントラ予測ユニット46は、ある特定のサブブロックのCABACコンテキストを、直前に符号化されたサブブロックのCABACコンテキストに基づいて適応させることができる。たとえば、イントラ予測ユニット46は、あるサブブロックに対するCBFフラグの最も可能性の高いCABACコンテキストを、先行するサブブロック(たとえば、左から右の処理順序では左側の近隣のサブブロック、または右から左への処理順序では右側の近隣のサブブロック)に対するCBFフラグのために使用されるCABACコンテキストに基づいて予測することができる。
直前に符号化されたサブブロックのCBFをコーディングするために使用されるCABACコンテキストから現在のサブブロックに対するCBFのCABACコンテキストを予測することによって、イントラ予測ユニット46は、コンテキストシグナリングによって消費されるビットレートを節約することができる。いくつかの事例では、イントラ予測ユニット46は、先行するサブブロックのCABACコーディングのために使用されるコンテキストからサブブロックの最も可能性の高いコンテキストを予測することによって、コンテキストシグナリングに必要なビットの数を2.3ビットから0.3ビットに減らすことができる。このようにして、本開示のCBFマスキング技法は、ビデオエンコーダ20がシグナリングに関して大きなビットレートの低減を実施することを可能にでき、ビデオエンコーダ20がCABACコンテキストを導出することに関するコンピューティングリソースを節約し、複雑さを下げることを可能にし得る。
いくつかの例では、イントラ予測ユニット46は、本開示の技法を実施して、SDIPコーディングされたブロックのサブブロックに対する最終有意係数(last_pos)の場所をCABACベース符号化またはエントロピー符号化するためのコンテキストを選択することができる。サブブロックのCBF以外に、サブブロックの最終有意係数の場所は、1つまたは複数の以前に符号化されたサブブロックのlast_posにも依存する。本明細書において説明された技法によれば、イントラ予測ユニット46は、1つまたは複数の以前に符号化されたサブブロックに対するlast_pos情報の大きさに基づいて、サブブロックに対するlast_posのCABACベースの符号化またはエントロピー符号化のためのコンテキストを計算することができる。
1つの例示的な使用事例では、イントラ予測ユニット46は、最終有意係数のCABAC符号化またはエントロピー符号化のための「コンテキスト1」と「コンテキスト2」の中から選択することができる。この例では、以前にコーディングされたサブブロック(たとえば、直前にコーディングされたサブブロック)に対するlast_pos値が0より大きい場合、イントラ予測ユニット46は、現在のサブブロックのlast_pos情報をCABAC符号化またはエントロピー符号化するためにコンテキスト1を使用することができる。それ以外の場合(たとえば、以前にコーディングされたサブブロックのlast_posが0以下である場合)、イントラ予測ユニット46は、現在のサブブロックの最終有意係数をエントロピーコーディングするためにコンテキスト2を使用することができる。このようにして、イントラ予測ユニット46は、本開示の1つまたは複数の技法を実施して、以前にコーディングされたサブブロックからのlast_pos情報を活用し、CABAC符号化またはエントロピー符号化に従って現在のサブブロックに対するlast_pos情報を符号化する際に用いるコンテキストを導出することができる。
いずれの場合も、変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部またはすべてと関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は次いで、量子化された変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
量子化ユニット54は、本開示の1つまたは複数の変換精度操作技法を実施して、ビデオコーディングにおいて一般に使用される様々な長方形TUのアスペクト比などの、様々なブロックのアスペクト比に関してコーディング精度を改善することができる。たとえば、量子化ユニット54は、量子化パラメータに関する差分、または「デルタ」(本明細書では「デルタQP」と呼ばれる)を使用することができる。SDIPコーディングされたブロックに関して本明細書において説明されるが、本開示の変換精度操作技法は、他のタイプのコーディング(たとえば、イントラコーディングおよび/またはインター予測)にも適用可能であることが理解されるだろう。
上で説明されたように、長方形ブロックの使用は、正方形ブロックを使用するときには生じないコンピューティング上および/または計算上の検討事項に関する1つまたは複数の潜在的な問題を引き起こし得る。TUのQPサイズは√(w*h)として計算され、ここで「√」は平方根関数を表し、「w」はTUの幅を表し、「h」はTUの高さを表す。正方形ブロックの場合、QPサイズは、上で説明されたように計算されると、常に整数値である。より具体的には、wとhの値が正方形ブロックでは等しいので、(w*h)の積の平方根は常にwに等しくhに等しい値である。より具体的には、64対64などの一般的に使用される正方形ブロックサイズでは、QPサイズは2の整数倍になる傾向がある。したがって、正方形ブロックにわたる量子化の分布は、行列計算および他の要因が原因で、2のべき乗を伴い得る。
しかしながら、ビデオコーディングにおいて一般に使用される大半の長方形ブロックのフォームファクタでは、√(w*h)演算の結果は2の平方根の整数倍であり、これは約1.414に等しく本明細書では√2と表記される。たとえば、一般に使用される長方形ブロックのサイズの1つが4×8である。4×8のブロックの場合、QPサイズの計算は√(4*8)演算を要求し、これは√32という値をもたらす。√32は√2の倍数であり、具体的には4*√2に等しい。同様に、8×16の次元の長方形ブロックは8*√2というQPサイズを生み出し、16×32の次元の長方形ブロックは16*√2というQPサイズを生み出し、以下同様である。
したがって、長方形ブロックのためのQPサイズ計算の非整数の結果は、本明細書では「√2問題」と呼ばれる。√2問題は、QPサイズについて浮動小数点の値を生み出し、これらの値の浮動小数点の性質をなくすためのあらゆる丸め演算が、コーディング精度の損失をもたらす。変換サイズの増大とともに、√2問題の浮動小数点の結果に起因するコーディング精度の問題はより厳しくなる。HEVCは、0から51の範囲に入り得るスケーリングパラメータQPを使用した、均一な再構築量子化を記載する。HEVC量子化技法によれば、QP値の1の増大が、対応する量子化ステップサイズ(「Qstep」)の約12パーセント(12%)の増大をもたらし得る。たとえば、Qstepの12%の増大は、生のQstep値の2と6分の1(21/6)の増大を表し得る。QP値の対応する増大により引き起こされる増分的なQstepの増大に基づいて、QstepはQPが6増大するたびに2倍になる。Qstepが4というQPに対して1に等しい事例では、直交変換に対するQP値と対応するQstepとの関係は次の式により与えられる。
Qstep(QP) = 2(QP-4)/6
多くの一般に使用される長方形TUのサイズの量子化と関連付けられる√2問題に対処するために、量子化ユニット54は、本開示の変換精度操作技法のうちの1つまたは複数を実施することができる。変換単位(TU)サイズが式2 n x2 mまたは2 n-by-2 m(「2 n」は行の数を表し「2 m」は列の数を表す)により表記される場合、順方向の変換は次の式により表される。
Y = T2 n . X2 n x2 m . T2 m
上の式において使用される表記によれば、X2 n x2 mは行の数「n」および列の数「m」を伴う残差ブロックを表す。したがって、上の式において使用される項X2 n x2 mは、「2n」に等しい行の数および「2m」に等しい列の数を伴う残差ブロックを表す。TvおよびThは、列および行の変換のための対応する2n×2n(2n対2m)および2m×2m(2m対2m)の行列である。いくつかの例では、nまたはmの1つが0に等しい。
本明細書において説明される変換精度操作技法の1つまたは複数によれば、演算(n+m)が奇数をもたらす場合、量子化ユニット54は、対応するTUデータを量子化するために、デルタQP値を現在の変換単位と関連付けられる導出されたQP値に加算することができる。デルタQPを導出されたQP値に加算することによって、量子化ユニット54は、正方形の変換のために定義された元のスケーリング係数を使用することができる。たとえば、元のスケーリング係数が定義された対象の正方形の変換は、K対Kの次元を有するものとして表現され得る。正方形の変換の一辺の大きさを表す「K」の値は、いくつかの例では((n+m)>>1)として、または他の例では((n+m+1)>>1)として定義され得る。演算子「>>」は算術的な右シフト演算を表し、上で説明されたように、「n」は残差ブロックの行の数を表し、「m」は残差ブロックの列の数を表す。
ある例として、4×8の変換に対して、量子化ユニット54は、4×4の変換または8×8の変換のために定義されたスケーリング係数を継承することができる。この例では、より小さな変換サイズ(たとえば、上で説明された例では4×4)に対するスケーリング係数に従ってTUを量子化する前に、量子化ユニット54は、変換係数のエネルギーを(1/√2)倍に減らすことができ、これは約30%の低減になる。そして、低減されたエネルギーを相殺するために、量子化ユニット54は、対応するQstepを√2だけ減らすことができる。
上で説明されたように、QPの1の増大は、対応するQstepの約12%の増大をもたらし得る。その上、QPの1の減少は、対応するQstepに約12%の下落または減少をもたらし得る。加えて、エネルギーがおよそ30%低減された変換係数に対して、量子化ユニット54は、対応するQPを3だけ減らすことによってエネルギー低減を相殺することができる。3というQPの低減は、式ceiling(30%/12%)に従って導出され、ここでceiling()演算はオペランドの最大の可能な値を返す。したがって、この例では、デルタQP値は-3(マイナス3(negative three)またはマイナス3(minus three))に常に設定される。代替的に、量子化ユニット54は、現在の変換単位と関連付けられる導出されたQP値に基づいて、デルタQP値を適応的に変更することができる。
量子化の後に、エントロピー符号化ユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは近隣のブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、または後の送信もしくは取り出しのためにアーカイブされ得る。
本開示の態様によれば、エントロピー符号化ユニット56、またはコーディングを担う別のユニット(たとえば、固定長コーダなど)が、区分モードテーブルを使用して、ビデオデータのブロックがSDIPモードを使用してコーディングされることの指示を符号化することができる。たとえば、上で述べられたように、ビデオエンコーダ20は、区分モードを表すバイナリ化された値などのシンタックス要素に区分モードをマッピングする、1つまたは複数の区分モードテーブル(符号語マッピングテーブルとも呼ばれる)を維持し得る。したがって、エントロピーコーディングユニット56は、区分モードテーブルの中のあるエントリに対応する1つまたは複数のビンストリングをエントロピー符号化し得る。
逆量子化ユニット58および逆変換ユニット60は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、画素領域中で残差ブロックを再構築する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに加えることによって参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するためのサブ整数画素値を計算するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用し得る。加算器62は、参照ピクチャメモリ64に記憶するための再構築されたビデオブロックを生成するために、動き補償ユニット44によって生成された動き補償予測ブロックに、再構築された残差ブロックを加える。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
図3は、本開示において説明されるようなイントラ予測コーディングのための技法を実施することができるビデオデコーダ30の例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。
復号プロセスの間に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化されたビデオスライスのビデオブロックと関連するシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化された係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成する。エントロピー復号ユニット70は、動き補償ユニット72に動きベクトルと他のシンタックス要素とを転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信し得る。
たとえば、背景として、ビデオデコーダ30は、いわゆる「ネットワーク抽象化層ユニット」またはNALユニットへとネットワークを介した送信のためにカプセル化された、圧縮されたビデオデータを受信し得る。各NALユニットは、NALユニットに記憶されるデータのタイプを特定するヘッダを含み得る。NALユニットに一般に記憶されるデータには2つのタイプがある。NALユニットに記憶される第1のタイプのデータは、圧縮されたビデオデータを含むビデオコーディング層(VCL)データである。NALユニットに記憶される第2のタイプのデータは非VCLデータと呼ばれ、非VCLデータは、最大の数のNALユニットおよび補足強化情報(SEI)に共通のヘッダデータを定義するパラメータセットなどの追加の情報を含む。たとえば、パラメータセットは、(たとえば、シーケンスパラメータセット(SPS)の中に)シーケンスレベルヘッダ情報を格納し、(たとえば、ピクチャパラメータセット(PPS)の中に)頻繁には変化しないピクチャレベルヘッダ情報を格納し得る。パラメータセットに格納される頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要はなく、これによりコーディング効率を改善する。加えて、パラメータセットの使用が、ヘッダ情報の帯域外送信を可能にし、これにより、エラー回復のための冗長な送信の必要がなくなる。
ビデオフレームが、インターコーディングされた(すなわち、B、PまたはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックの予測ブロックを生成する。予測ブロックは、参照ピクチャリストの1つの中の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照ピクチャメモリ82に記憶された参照ピクチャに基づくデフォルトの構築技法を使用して、参照フレームリスト、リスト0およびリスト1を構築し得る。
動き補償ユニット72は、動きベクトルと他のシンタックス要素とを構文解析することによって現在のビデオスライスのビデオブロックの予測情報を決定し、この予測情報を使用して、復号されている現在のビデオブロックの予測ブロックを生成する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラ予測またはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスのための参照ピクチャリストのうちの1つまたは複数に対する構築情報と、スライスの各々のインター符号化されたビデオブロックの動きベクトルと、スライスの各々のインターコーディングされたビデオブロックのインター予測ステータスと、現在のビデオスライスの中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。
動き補償ユニット72は、補間フィルタに基づいて補間を実行することもできる。動き補償ユニット72は、参照ブロックのサブ整数画素の補間された値を計算するために、ビデオブロックの符号化の間にビデオエンコーダ20によって使用された補間フィルタを使用することができる。この場合に、動き補償ユニット72は、受け取られたシンタックス要素から、ビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するためにその補間フィルタを使用することができる。
イントラ予測ユニット74は、上で説明されたように、動き補償ユニット72によって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測ユニット74は、現在のブロックを復号および再構築するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット74は、たとえば、別個の復号パスの間に、様々なイントラ予測モードを使用して、現在のブロックを復号することができる。イントラ予測ユニット74は、ビデオエンコーダ20および/またはその構成要素によって使用されるイントラ予測モードのそれぞれの指示に基づいて、適切なイントラ予測モードを選択することができる。
たとえば、イントラ予測ユニット74は、ビデオエンコーダ20から受信される符号化されたビデオビットストリームに含まれる指示に基づいて、ブロックに対するイントラ予測モードを選択することができる。いくつかの例では、イントラ予測ユニット74は、1つまたは複数の利用可能なSDIPベースのコーディングモードのうちのあるSDIPコーディングモードを使用してブロックが符号化されたことを示すためのビデオエンコーダ20によりシグナリングされる指示(たとえば、フラグ)に基づいて、ブロックに対するSDIPモードを選択することができる。
イントラ予測ユニット74は、本開示の様々な技法を実施して、1つまたは複数の条件を検出したことに基づいてSDIP符号化されたブロックのサブブロックの処理順序を適応させ得る。上で論じられたように、SDIPによれば、サブブロックの処理順序は上から下および左から右である。SDIPは、再構築された近隣の画素が予測された画素にはるかに近い傾向があるという、他のイントラ予測モードを上回る潜在的な利点をもたらす。再構築された近隣の画素が現在の画素に比較的近いので、SDIP技術は現在の画素の予測の精度を向上させる傾向がある。
しかしながら、既存のSDIP技術の処理順序は常に上から下および左から右なので、イントラ予測ユニット74は、現在の画素を復号するときに以前に復号されたサブブロックの中の再構築された画素を完全に活用することが常には可能ではないことがある。たとえば、イントラ予測方向が左下からである場合、現在の画素は常に、現在の画素の下および左に位置する1つまたは複数の画素から(すなわち、現在の画素に関して1つまたは複数の「左下の」画素から)イントラ予測される。同様に、イントラ予測方向が右上からである場合、現在の画素は常に、現在の画素の上および右に位置する1つまたは複数の画素から(すなわち、現在の画素に関して1つまたは複数の「右上の」画素から)イントラ予測される。
しかしながら、上から下および左から右の処理順序は、いくつかのシナリオでは現在の画素の予測精度を改善しないことがあり、場合によっては予測精度を妨げ、または下げることがある。たとえば、SDIP処理順序の上から下への性質によれば、イントラ予測ユニット74が現在の画素を予測するのを開始する準備ができているときに、左下の近隣の画素がまだ再構築されていないことがある。同様に、SDIP処理順序の左から右への性質によれば、イントラ予測ユニット74が現在の画素を予測するのを開始する準備ができているときに、右上の近隣の画素がまだ再構築されていないことがある。したがって、いくつかのシナリオでは、イントラ予測ユニット74は、イントラ予測ユニット74がSDIP処理順序に従って現在の画素を予測する準備ができている時間に、イントラ予測参照画素を入手できないことがある。
イントラ予測ユニット74は、本開示の技法を実施して、現在の画素の再構築に関して特定のイントラ予測方向が当てはまることを検出したことに基づいて、左下イントラ予測および右上イントラ予測のための処理順序を、それぞれ下から上および右から左に変更することができる。言い換えると、イントラ予測ユニット74は、現在のCUのイントラ予測角度に基づいて処理順序を変更することができる。たとえば、イントラ予測ユニット74は、本開示の技法を実施して、ある条件の下で処理順序を変更し、既存のSDIP処理順序では現在の画素をイントラ予測する際に再構築された参照画素が利用不可能であるシナリオに対処することができる。
本明細書において説明される技法によれば、イントラ予測ユニット74は、イントラ予測角度が左下である場合、SDIP符号化されたサブブロックに関して下から上の処理順序を実施し得る。イントラ予測ユニット74が下から上となるように処理順序を変更する場合、イントラ予測ユニット74は既存のSDIPベースのコーディング技術の左から右への態様を維持し得ることが理解されるだろう。対応するイントラ予測角度が左下である場合に、SDIPコーディングされたブロックの処理順序を(左から右への態様を保ったまま)下から上に変更することによって、イントラ予測ユニット74は、本開示の技法を実施して現在のブロックの予測の精度を向上させることができる。
たとえば、既存のSDIP技術の上から下の処理順序が左下のイントラ予測角度と組み合わされ、次いでイントラ予測ユニット74が、現在の画素をイントラ予測するのに必要であり得る左下のブロックまたは行からの再構築された画素を入手できないことがある。このシナリオでは、左下のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ再構築されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、イントラ予測ユニット74は、近隣のブロックなどの別のブロックにおいてすでに再構築されている画素を使用する必要があり得る。
しかしながら、本開示の技法に従って、イントラ予測方向が左下である場合にSDIPコーディングされたブロックの処理順序を下から上に切り替えることによって、イントラ予測ユニット74は、現在のサブブロックのSDIPベースの符号化を実施するために、現在の画素に近接して位置する参照画素を活用し続けることができる。SDIPコーディングされたブロックに関して下から上への処理順序を使用することによって、イントラ予測ユニット74は、現在の画素をイントラ予測するための参照画素として再構築された左下の近隣の画素が利用可能であるような方式で、SDIPベースのイントラ予測を実施することができる。たとえば、イントラ予測ユニット74が下から上の順序でSDIPコーディングされたサブブロックの画素を処理するので、下側の近隣の画素、およびそれらの下側の近隣の画素は、定義上、現在の画素の処理をイントラ予測ユニット74が開始する前にすでに再構築されている。したがって、イントラ予測ユニット74は、イントラ予測角度が左下である場合、本開示の様々な態様に従って予測精度を向上させるために、下から上および左から右となるようにSDIP処理順序を適合させることができる。
加えて、本明細書において説明される技法によれば、イントラ予測ユニット74は、イントラ予測角度が右上である場合、SDIP符号化されたサブブロックを再構築することに関して右から左の処理順序を実施し得る。イントラ予測ユニット74が右から左となるように処理順序を変更する場合、イントラ予測ユニット74は既存のSDIPベースのコーディング技術の上から下への態様を維持し得ることが理解されるだろう。対応するイントラ予測角度が右上である場合に、SDIPコーディングされたブロックの処理順序を(上から下への態様を保ったまま)右から左に変更することによって、イントラ予測ユニット74は、本開示の技法を実施して現在のブロックの予測の精度を向上させることができる。
たとえば、既存のSDIP技術の左から右の処理順序が右上のイントラ予測角度と組み合わされ、次いでイントラ予測ユニット74が、現在の画素をイントラ予測するのに必要であり得る右上のブロックまたは行からの再構築された画素を入手できないことがある。このシナリオでは、右上(top-right)(代替的に、「右上(above-right)」)のブロックまたは行からの画素は、既存のSDIP技術により提供される処理順序が原因で、まだ再構築されていないことがある。結果として、既存の技術に従ってSDIPを実行するために、イントラ予測ユニット74は、近隣のブロックなどの別のブロックにおいてすでに再構築されている画素を使用する必要があり得る。
しかしながら、イントラ予測方向が右上である場合にSDIPコーディングされたブロックの処理順序を右から左に切り替えることによって、イントラ予測ユニット74は、現在のサブブロックのSDIPベースの復号を実施するために、現在の画素に近接して位置する参照画素を活用し続けることができる。SDIPコーディングされたブロックに関して右から左への処理順序を使用することによって、イントラ予測ユニット74は、現在の画素をイントラ予測するための参照画素として再構築された右上の近隣の画素が利用可能であるような方式で、SDIPベースのイントラ予測を実施することができる。たとえば、イントラ予測ユニット74が右から左の順序でSDIPコーディングされたサブブロックの画素を処理するので、右側の近隣の画素、およびそれらの右側の近隣の画素は、定義上、現在の画素の処理をイントラ予測ユニット74が開始する前にすでに再構築されている。したがって、イントラ予測ユニット74は、イントラ予測角度が右上である場合、本開示の様々な態様に従って予測精度を向上させるために、右から左および上から下となるようにSDIP処理順序を適合させることができる。
イントラ予測ユニット74は、上で説明された技法を実施してイントラ予測角度が左下または右上の場合にのみ処理順序を変えることができるので、イントラ予測ユニット74は、残りのイントラ予測方向に関してSDIPによりもたらされる利点を維持しながら、イントラ予測方向が左下と右上のいずれかである場合にSDIPベースのコーディングの精度を改善するために変更された処理順序を活用することができる。言い換えると、イントラ予測ユニット74は、本開示のSDIP処理順序の適応がSDIPベースのコーディングによりもたらされるコーディング精度を潜在的に改善するシナリオでのみその適応を実施しながら、適応が潜在的な精度の向上を生まない可能性があるシナリオでは既存のSDIP処理順序を守ることができる。このようにして、イントラ予測ユニット74は、本明細書において説明される技法を実施して、残りのシナリオにおいてSDIP技術の利点に悪影響を及ぼすことなく、あるシナリオにおいてSDIPベースのコーディングの予測精度を向上させることができる。
SDIPベースの復号ならびに他のコーディングモードに従った復号の場合、イントラ予測ユニット74は、本開示の様々な技法を実施して、CBF値のサブブロックごとの遷移に基づいてCBFマスクを復号することができる。議論を簡単にするためだけに、マスクベースのCBF再構築技法はSDIP符号化されたブロックに関して本明細書において論じられるが、イントラ予測ユニット74はまた、SDIP関連ではない技術を使用して符号化されたブロックを再構築することに関しても本開示のマスクベースのCBF再構築技法を実施できることが理解されるだろう。
CBFはフラグであるので、所与のCBFは所与のサブブロックに関して「0」または「1」のいずれかの値を有する。したがって、CBF値のあらゆる遷移がトグリング動作を表す。本開示のマスクベースのCBF再構築技法によれば、イントラ予測ユニット74は、現在復号されているサブブロックのCBF値とSDIPコーディングされたブロックの直前のサブブロックのCBF値との差を復号することによって、現在復号されているサブブロックのCBF値を推測または外挿することができる。たとえば、イントラ予測ユニット74が現在のサブブロックに関して1というシグナリングされたCBFマスク値を復号する場合、イントラ予測ユニット74は、現在のサブブロックのCBF値が現在のサブブロックの直前に(たとえば、上から下の処理順序では上に、または下から上の処理順序では下に)位置するサブブロックのCBF値と異なると決定することができる。言い換えると、本開示のマスクベースのCBF再構築技法によれば、1というCBFマスク値は、直前に復号されたSDIPサブブロックからのCBF値の遷移を示す。
たとえば、イントラ予測ユニット74が「1000000000」を示すCBFマスクの10ビットの文字列を受信する場合、イントラ予測ユニット74は、SDIP符号化されたブロックの最初の10個のサブブロックのすべてが「1」という値を伴うCBFを有すると決定することができる。たとえば、イントラ予測ユニット74は、SDIPコーディングされたブロックのために受信された最初のCBFマスクがサブブロックの生のCBF値を表すと決定することができる。言い換えると、イントラ予測ユニット74は、SDIP符号化されたブロックのためにシグナリングされる最初のCBFマスクが、別のサブブロックからの遷移に関して定義されず、代わりに、関連するサブブロックのCBF値を直接表現するものであると、決定することができる。本開示のマスクベースのCBF再構築技法を使用して、イントラ予測ユニット74は、最初のサブブロックに対して「1」という生のCBF値を復号し、次いで、次の9個の連続する「0」の値に基づいて、次9個のCBF値のいずれもがそれぞれの前にあるCBF値から変化しないと推測することができる。この特定の例では、イントラ予測ユニット74は、(処理順序において)2番目から10番目のサブブロックが「1」という値を有するCBFとすべて関連付けられると決定し、それは、CBFマスクが最初に処理されたサブブロックの1という生のCBF値からの変更を直接的または間接的に示さないからである。
このようにして、イントラ予測ユニット74は、本開示のCBFマスキング技法を実施して、SDIPコーディングされたブロックの各々の個別のサブブロックをバイナリベクトルとして使用し、それにより、CBFマスクを使用して各線のCBF値を推測または外挿することができる。本開示のマスクベースのCBF再構築技法を実施することによって、イントラ予測ユニット74は、既存のCBF再構築技法と比較して、リソース消費を減らし復号の複雑さを下げながら、CBF精度を維持することができる。イントラ予測ユニット74はまた、本開示のマスクベースのCBF再構築技法を実施することによって、帯域幅消費の要件を軽減することができる。
いくつかの例では、イントラ予測ユニット74は、SDIP符号化されたブロックのCBF値のCABACベースの復号またはエントロピー復号に対するコンテキストを導出することができる。最初の10個のCBF値が「1111111111」である上で説明された例では、イントラ予測ユニット74は、ある特定のサブブロックのCABACコンテキストを、直前に再構築されたサブブロックのCABACコンテキストに基づいて適応させることができる。たとえば、イントラ予測ユニット74は、あるサブブロックに対するCBFフラグの最も可能性の高いCABACコンテキストを、先行するサブブロック(たとえば、左から右の処理順序では左側の近隣のサブブロック、または右から左への処理順序では右側の近隣のサブブロック)に対するCBFフラグのために使用されるCABACコンテキストに基づいて予測することができる。
直前に再構築されたサブブロックのCBFをコーディングするために使用されるCABACコンテキストから現在のサブブロックに対するCBFのCABACコンテキストを予測することによって、イントラ予測ユニット74は、コンテキストシグナリングによって消費されるビットレートの一部分の必要性をなくすことができる。いくつかの事例では、イントラ予測ユニット74は、先行するサブブロックのCABACコーディングのために使用されるコンテキストからサブブロックの最も可能性の高いコンテキストを予測することによって、コンテキストシグナリングに必要なビットの数を2.3ビットから0.3ビットに減らすことができる。このようにして、本開示のマスクベースのCBF再構築技法は、ビデオデコーダ30がビデオエンコーダ20からのシグナリング要件に関して大きなビットレートの低減を実施することを可能にでき、ビデオデコーダ30が復号のためにCABACコンテキストを導出することに関するコンピューティングリソースを節約し、複雑さを下げることを可能にし得る。
いくつかの例では、イントラ予測ユニット74は、本開示の技法を実施して、SDIP符号化されたブロックのサブブロックに対する最終有意係数(last_pos)の場所をCABACベース復号またはエントロピー復号するためのコンテキストを選択することができる。サブブロックのCBF以外に、サブブロックの最終有意係数の場所は、1つまたは複数の以前に符号化されたサブブロックのlast_posにも依存する。本明細書において説明された技法によれば、イントラ予測ユニット74は、1つまたは複数の以前に再構築されたサブブロックに対するlast_pos情報の大きさに基づいて、サブブロックに対するlast_posのCABACベースの復号またはエントロピー復号のためのコンテキストを計算することができる。
1つの例示的な使用事例では、イントラ予測ユニット74は、最終有意係数のCABACベースの復号またはエントロピー復号のための「コンテキスト1」と「コンテキスト2」の中から選択することができる。この例では、以前に再構築されたサブブロック(たとえば、直前に再構築されたサブブロック)のlast_pos値が0より大きい場合、イントラ予測ユニット74は、現在のサブブロックのlast_pos情報をCABACベース復号またはエントロピー復号するためにコンテキスト1を使用することができる。それ以外の場合(たとえば、以前にコーディングされたサブブロックのlast_posが0以下である場合)、イントラ予測ユニット74は、現在のサブブロックの最終有意係数を復号するためにコンテキスト2を使用することができる。このようにして、イントラ予測ユニット74は、本開示の1つまたは複数の技法を実施して、以前に再構築されたサブブロックからのlast_pos情報を活用し、CABACベースの復号またはエントロピー復号に従って現在のサブブロックに対するlast_pos情報を復号する際に用いるコンテキストを導出することができる。
逆量子化ユニット76は、ビットストリームの中で与えられエントロピー復号ユニット70によって復号された、量子化された変換係数を逆量子化(inverse quantize)、すなわち逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオデコーダ30によって計算された量子化パラメータQPYをビデオスライスの中の各ビデオブロックのために使用することを含み得る。
逆量子化ユニット76は、本開示の1つまたは複数の変換精度操作技法を実施して、ビデオコーディングにおいて一般に使用される様々な長方形TUのアスペクト比などの、様々なブロックのアスペクト比に関して復号精度を改善することができる。たとえば、逆量子化ユニット76は、量子化パラメータに関する差分、「デルタ」(本明細書では「デルタQP」と呼ばれる)を使用することができる。SDIPコーディングされたブロックに関して本明細書において説明されるが、本開示の変換精度操作技法は、他のタイプのコーディング(たとえば、イントラコーディングおよび/またはインター予測)にも適用可能であることが理解されるだろう。
上で説明されたように、長方形ブロックの使用は、正方形ブロックを処理するときには生じないコンピューティング上および/または計算上の検討事項に関する1つまたは複数の潜在的な問題を引き起こし得る。TUのQPサイズは√(w*h)として計算され、ここで「√」は平方根関数を表し、「w」はTUの幅を表し、「h」はTUの高さを表す。正方形ブロックの場合、QPサイズは、上で説明されたように計算されると、常に整数値である。より具体的には、wとhの値が所与の正方形ブロックでは等しいので、(w*h)の積の平方根は常にwに等しくhに等しい値である。より具体的には、64対64などの一般的に使用される正方形ブロックサイズでは、QPサイズは2の整数倍になる傾向がある。したがって、正方形ブロックにわたる量子化の分布は、行列計算および他の要因が原因で、2のべき乗を伴い得る。
しかしながら、ビデオコーディングにおいて一般に使用される大半の長方形ブロックのフォームファクタでは、√(w*h)演算の結果は2の平方根の整数倍であり、これは約1.414に等しく本明細書では√2と表記される。たとえば、一般に使用される長方形ブロックのサイズの1つが4×8である。4×8のブロックの場合、QPサイズの計算は√(4*8)演算を要求し、これは√32という値をもたらす。√32は√2の倍数であり、具体的には4*√2に等しい。同様に、8×16の次元の長方形ブロックは8*√2というQPサイズを生み出し、16×32の次元の長方形ブロックは16*√2というQPサイズを生み出し、以下同様である。
したがって、長方形ブロックのためのQPサイズ計算の非整数の結果は、本明細書では「√2問題」と呼ばれる。√2問題は、QPサイズについて浮動小数点の値を生み出し、これらの値の浮動小数点の性質をなくすためのあらゆる丸め演算が、コーディング精度の損失をもたらす。変換サイズの増大とともに、√2問題の浮動小数点の結果に起因するコーディング精度の問題はより厳しくなる。HEVCは、両端を含めて0から51の範囲に入り得るスケーリングパラメータQPを使用した、均一な再構築量子化を記載する。HEVC逆量子化技法によれば、QP値の1の増大が、対応する量子化ステップサイズ(「Qstep」)の約12パーセント(12%)の増大をもたらし得る。たとえば、Qstepの12%の増大は、生のQstep値の2と6分の1(21/6)の増大を表し得る。QP値の対応する増大により引き起こされる増分的なQstepに基づいて、QstepはQPが6増大するたびに2倍になる。Qstepが4というQPに対して1に等しい事例では、直交変換に対するQP値と対応するQstepとの関係は次の式により与えられる。
Qstep(QP) = 2(QP-4)/6
多くの一般に使用される長方形TUのサイズの逆量子化と関連付けられる√2問題に対処するために、逆量子化ユニット76は、本開示の変換精度操作技法のうちの1つまたは複数を実施することができる。変換単位(TU)サイズが式2 n x2 mまたは2 n-by-2 m(「2 n」は行の数を表し「2 m」は列の数を表す)により表記される場合、順方向の変換は次の式により表される。
Y = T2 n . X2 n x2 m . T2 m
上の式において使用される表記によれば、X2 n x2 mは行の数「n」および列の数「m」を伴う残差ブロックを表す。したがって、上の式において使用される項X2 n x2 mは、「2n」に等しい行の数および「2m」に等しい列の数を伴う残差ブロックを表す。TvおよびThは、列および行の変換のための対応する2n×2n(2n対2m)および2m×2m(2m対2m)の行列である。いくつかの例では、nまたはmの1つが0に等しい。
本明細書において説明される変換精度操作技法の1つまたは複数によれば、演算(n+m)が奇数をもたらす場合、逆量子化ユニット76は、対応するTUデータを量子化するために、デルタQP値を現在の変換単位と関連付けられる導出されたQP値に加算することができる。デルタQPを導出されたQP値に加算することによって、逆量子化ユニット76は、正方形の変換のために定義された元のスケーリング係数を使用することができる。たとえば、元のスケーリング係数が定義された対象の正方形の変換は、K対Kの次元を有するものとして表現され得る。正方形の変換の一辺の大きさを表す「K」の値は、いくつかの例では((n+m)>>1)として、または他の例では((n+m+1)>>1)として定義され得る。演算子「>>」は算術的な右シフト演算を表し、上で説明されたように、「n」は残差ブロックの行の数を表し、「m」は残差ブロックの列の数を表す。
ある例として、4×8の変換に対して、逆量子化ユニット76は、4×4の変換または8×8の変換のために定義されたスケーリング係数を継承することができる。この例では、より小さな変換サイズ(たとえば、上で説明された例では4×4)に対するスケーリング係数に従ってTUを量子化する前に、逆量子化ユニット76は、変換係数のエネルギーを(1/√2)倍に減らすことができ、これは約30%の低減になる。そして、低減されたエネルギーを相殺するために、逆量子化ユニット76は、対応するQstepを√2だけ減らすことができる。
上で説明されたように、QPの1の増大は、対応するQstepの約12%の増大をもたらし得る。その上、QPの1の減少は、対応するQstepに約12%の下落または減少をもたらし得る。加えて、エネルギーがおよそ30%低減された変換係数に対して、逆量子化ユニット76は、対応するQPを3だけ減らすことによってエネルギー低減を相殺することができる。3というQPの低減は、式ceiling(30%/12%)に従って導出され、ここでceiling()演算はオペランドの最大の可能な値を返す。したがって、この例では、デルタQP値は-3(マイナス3(negative three)またはマイナス3(minus three))に常に設定される。代替的に、逆量子化ユニット76は、現在の変換単位と関連付けられる導出されたQP値に基づいて、デルタQP値を適応的に変更することができる。
逆変換ユニット78は、画素領域において残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
動き補償ユニット72が、動きベクトルおよび他のシンタックス要素に基づいて現在のビデオブロックの予測ブロックを生成した後に、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために復号されたブロックをフィルタリングする、デブロッキングフィルタも適用され得る。他のループフィルタ(コーディングループの中、またはコーディングループの後のいずれかにおける)も、画素の遷移を平滑化し、または場合によってはビデオ品質を改善するために使用され得る。所与のフレームまたはピクチャの中の復号されたビデオブロックは次いで、参照ピクチャメモリ82に記憶され、参照ピクチャメモリ82は、後続の動き補償のために使用される参照ピクチャを記憶する。参照ピクチャメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上で後で提示するための、復号されたビデオを記憶する。
図4Aおよび図4Bは、例示的な四分木98および対応する最大コーディング単位(LCU)を示す概念図である。図4Aは、階層的に並べられたノードを含む例示的な四分木98を示す。四分木98は、たとえば、提案されるHEVC規格に従ってツリーブロックと関連付けられ得る。四分木98などの四分木の中の各ノードは、子を持たないリーフノードであることあり、または4つの子ノードを持つことがある。図4Aの例では、四分木98はルートノード100を含む。ルートノード100は、リーフノード106A〜106C(リーフノード106)およびノード102を含む、4つの子ノードを持つ。ノード102はリーフノードではないので、ノード102は、この例ではリーフノード108A〜108D(リーフノード108)である4つの子ノードを含む。
四分木98は、この例ではLCU120などの、対応する最大コーディング単位(LCU)の特性を記述するデータを含み得る。たとえば、四分木98は、その構造によって、サブCUへのLCUの分割を記述し得る。LCU120が2N×2Nのサイズを有すると仮定する。この例では、LCU120は、各々がN×Nのサイズである4つのサブCU124A〜124C(サブCU124)および122を有する。サブCU122はさらに、各々がN/2×N/2のサイズである4つのサブCU126A〜126D(サブCU126)に分割される。四分木98の構造は、この例ではLCU120の分割に対応する。すなわち、ルートノード100はLCU120に対応し、リーフノード106はサブCU124に対応し、ノード102はサブCU122に対応し、リーフノード108はサブCU126に対応する。
四分木98のノードのためのデータは、ノードに対応するCUが分割されるかどうかを記述し得る。CUが分割される場合、4つの追加のノードが四分木98の中に存在し得る。いくつかの例では、四分木のノードは、次の疑似コードと同様に実装され得る。
quadtree_node {
boolean split_flag(1);
// signaling data
if (split_flag) {
quadtree_node child1;
quadtree_node child2;
quadtree_node child3;
quadtree_node child4;
}
}
split_flag値は、現在のノードに対応するCUが分割されるかどうかを表す1ビットの値であり得る。CUが分割されない場合、split_flag値は「0」であり得るが、CUが分割される場合は、split_flag値は「1」であり得る。四分木98の例に関して、分割フラグ値のアレイは101000000であり得る。
上で述べられたように、CU深度は、LCU120などのLCUが分割された程度を指し得る。たとえば、ルートノード100はCU深度0に対応し得るが、ノード102およびリーフノード106はCU深度1に対応し得る。加えて、リーフノード108はCU深度2に対応し得る。本開示の態様によれば、CUおよび/またはTU深度は、いくつかのシンタックス要素をエントロピーコーディングするためのコンテキストとして使用され得る。説明を目的とする例では、リーフノード106Aと関連付けられる1つまたは複数のシンタックス要素は、リーフノード108Aとは異なるコンテキストモデルを使用してエントロピーコーディングされることがあり、それは、リーフノード106Aが深度1に位置する一方で、リーフノード108Aが深度2に位置するからである。
図4AはCU四分木の例を示すが、同様の四分木はリーフノードCUのTUに適用され得ることを理解されたい。すなわち、リーフノードCUは、CUのためのTUの区分を記述するTU四分木(残差四分木(RQT)と呼ばれる)を含み得る。TU四分木は、CUのTUのためのイントラ予測モードを個々にシグナリングし得ることを除き、CU四分木と全般に似ていることがある。
図5は、方向性イントラ予測モードと関連付けられる予測方向を全般に示す概念図である。たとえば、上で述べられたように、新興のHEVC規格は、平面モード(モード0)、DCモード(モード1)、および33個の方向性予測モード(モード2〜34)を含む、35個のイントラ予測モードを含み得る。平面モードでは、予測はいわゆる「平面」関数を使用して実行される。DCモードでは、予測はブロック内の画素値の平均化に基づいて実行される。方向性予測モードでは、予測は、特定の方向(モードによって示されるような)に沿った近隣のブロックの再構築された画素に基づいて実行される。
いくつかの事例では、ビデオ符号化デバイス(ビデオエンコーダ20など)は、最確モード(MPM)プロセスを使用してブロックのためのイントラモードをシグナリングすることができる。たとえば、ビデオエンコーダ20は、現在コーディングされているブロックに隣接するブロック(たとえば、現在符号化されているブロックの上に位置するブロックまたは現在符号化されているブロックの左に位置するブロック)と関連付けられる最大で2つのMPM候補を特定することができる。2つのMPM候補を見いだせない(たとえば、ブロックがイントラコーディングされない、ブロックが異なるスライスの中またはピクチャの境界の外側にある、ブロックが同じイントラモードを有する)場合、ビデオエンコーダ20はDCモードを代わりに使うことができる。
現在符号化されているブロックのイントラモードがそれらのMPM候補のいずれかに等しい場合、ビデオエンコーダ20はprev_intra_luma_pred_flagを設定することができる。加えて、ビデオエンコーダ20は、一致するMPM候補を特定するためにmpm_idxフラグを設定することができる。しかしながら、現在符号化されているブロックのイントラモードがMPM候補のいずれにも等しくない場合、ビデオエンコーダ20は、残りのイントラモードのいずれが現在符号化されているブロックのイントラモードに等しいかを示すために、rem_intra_luma_pred_modeシンボルを設定することができる。
本開示の態様によれば、図5の例に関して示され説明されるイントラモードは、SDIPモードおよび/または非対称SDIPモードを含む、図6および図8に示される区分モードのうちの1つまたは複数とともに使用され得る。
図6は全般に、予測単位と関連付けられ得る区分モード(これはPUサイズを定義し得る)を示す。たとえば、特定のCUのサイズが2N×2Nであると仮定すると、CUは、区分モード2N×2N(140)、N×N(142)、hN×2N(144)、2N×hN(146)、N×2N(148)、2N×N(150)、nL×2N(152)、nR×2N(154)、2N×nU(156)、および2N×nD(158)を使用して予測され得る。図5の例に示される区分モードは、例示のみを目的に提示されており、ビデオデータが予測される方式を示すために他の区分モードが使用され得る。
いくつかの事例では、ビデオコーダ(たとえば、ビデオエンコーダ20および/またはビデオデコーダ30など)が、区分モード140および142を使用してイントラ予測またはインター予測を実行することができる。たとえば、ビデオコーダは、2N×2NのPUを使用してCUを全体として予測することができる(区分モード140)。別の例では、ビデオコーダは、4つのN×NのサイズのPUを使用してCUを予測することができ(区分モード142)、4つのセクションの各々が、場合によっては異なる予測技法を適用される。
加えて、イントラコーディングに関して、ビデオコーダは、短距離イントラ予測(SDIP)と呼ばれる技法を実行することができる。SDIPが利用可能である場合、CUは、並列のPUを使用して予測され得る(区分モード144および146)。すなわち、SDIPは一般に、CUが並列のPUへと分割されることを可能にする。コーディング単位(CU)を非正方形の予測単位(PU)に分割することによって、予測される画素と参照画素との間の距離は短縮され得る。したがって、いくつかの事例では、図5に示される方向性予測モード2〜34などの方向性予測方法を適用するとき、イントラ予測の精度が改善され得る。
ある例として、8×8のCUは4つの8×2のPUへと分割されることがあり、この例では、「N×M」は垂直方向のN個の画素および水平方向のM個の画素を指す。第1のPUはCUに対する近隣の画素から予測されることがあり、第2のPUは第1のPUの画素を含む近隣の画素から予測されることがあり、第3のPUは第2のPUの画素を含む近隣の画素から予測されることがあり、第4のPUは第3のPUの画素を含む近隣の画素から予測されることがある。このようにして、CUに対する近隣の以前にコーディングされたブロックの画素からCUのすべての画素を予測するのではなく、SDIPを使用すると、CU内の画素が同じCU内の他の画素を予測するために使用され得る。
図6に示される例では、CUはhN×2Nの構成の4つのSDIP PUを用いて予測されることがあり(区分モード144)、「h」は2分の1を表す。別の例では、CUは2N×hNの構成の4つのSDIP PUを用いて予測されることがある(区分モード146)。SDIP PUへのCUの区分は、SDIP区分モードを実施することとして言及されることがある。他の例では、追加の予測タイプも可能であり得る。
インターコーディングに関して、対称的な区分モード140および142に加えて、ビデオコーダは、PUの隣り合った構成(区分モード148および150)、または様々なAMP(非対称の動き区分)モードを実施することができる。AMPモードに関して、ビデオコーダは、区分モードnL×2N(152)、nR×2N(154)、2N×nU(156)、および2N×nD(158)を使用してCUを非対称に区分することができる。非対称区分では、CUの一方の方向は区分されないが、他方の方向は25%と75%に区分される。25%区分に対応するCUの部分は、「n」とその後に続く「Up」、「Down」、「Left」、または「Right」の指示によって示される。
図7Aは、短距離イントラ予測(SDIP)に従って線または非正方形(たとえば、長方形)のブロックへと区分されるコーディング単位(CU)160を示す概念図である。CU160の各サブブロックの次元が図7Aにおいて特定されている。ビデオエンコーダ20および/またはビデオデコーダ30は、上で説明された適応的なSDIP処理順序技法などの本明細書において説明される技法の1つまたは複数を、CU160を符号化または復号するときに実施することができる。
図7Bは、SDIP予測されたCUを含む例示的なLCU180を示す概念図である。具体的には、この例では、LCU180は、サブCU182、184、186、188、190、192、および194を含む。サブCU182、184、186、188、190、192、および194の各々は、リーフノードCUに対応する。非リーフノードCUは、この例では、サブCU184、186、188、および190も含む。リーフノードサブCUの各々は、ある特定の予測モードに従って予測され得る。この例では、サブCU188はSDIPを使用して予測される。したがって、サブCU188は4つのPU196A〜196D(PU196)を含む。この例において示されるように、PU196はサブCU188の水平方向のPUである。
図8は、SDIPの非対称区分モードを使用して区分されるブロック220〜226の様々な例を示す概念図である。たとえば、図6は2つの対称的なSDIPモード144および146を含む。図8の例では、各ブロック220〜226は2つの長方形へと区分され、ブロック220〜226の各々は最初は2N×2Nのブロックである。一方の長方形はある次元(すなわち、長さまたは幅)がN/2個の画素であり、別の長方形は同じ次元が3N/2個の画素である。
この例では、ブロック220、222、224、および226の各々は64×64ピクセルのブロックであるが、他のサイズのブロック(たとえば、32×32、16×16、128×128など)も同様の方式で区分され得る。ブロック220は、垂直方向の辺230Aによって、1つの(1/2N)*2NのPU232Aおよび1つの(3/2N)*2NのPU234Aという2つのPUへと水平方向に分割される。ブロック222は、垂直方向の辺230Bによって、1つの(3/2N)*2NのPU234Bおよび1つの(1/2N)*2NのPU232Bという2つのPUへと水平方向に分割される。ブロック224は、水平方向の辺230Cによって、1つの2N*(3/2N)のPU234Cおよび1つの2N*(1/2N)のPU232Cという2つのPUへと垂直方向に分割される。ブロック226は、水平方向の辺230Dによって、1つの2N*(1/2N)のPU232Dおよび1つの2N*(3/2N)のPU234Dという2つのPUへと垂直方向に分割される。このようにして、図8のSDIP PU232、234は、非対称のSDIP PUと呼ばれ得る。
従来のSDIPのように、非対称のSDIP PUの画素の各々は、同じイントラ予測方向を共有し得る。さらに、非対称のSDIP PUは、必ずしも同じイントラ予測方向を有する必要はない。たとえば、PU232Aは垂直なイントラ予測モード(たとえば、図5のモード1)を使用して予測され得るが、PU234Aは対角方向のイントラ予測モード(たとえば、図5のモード26)を使用して予測され得る。
いくつかの例では、あるイントラ予測モードは、ある非対称のPUに限定され得る。たとえば、ビデオコーディングデバイス(ビデオエンコーダ20およびビデオデコーダ30など)は、PU232A、232B、234A、および234Bなどの比較的垂直な非対称のSDIP PUが比較的水平なイントラ予測モード(たとえば、図5の上から下に延びるモード27〜10)を使用して予測されないと、推測するように構成され得る。同様に、別の例では、ビデオコーディングデバイスは、PU232C、232C、234D、および234Dなどの比較的水平な非対称のSDIP PUが比較的垂直なイントラ予測モード(たとえば、図5の左から右に延びるモード4〜7)を使用して予測されないと、推測するように構成され得る。
いくつかの例では、変換単位サイズは対応するPUサイズと同じであり得る。したがって、ブロック220〜226のための変換単位は、PU232、234のうちの対応する1つと同じサイズを有し得る。たとえば、ブロック220では、(1/2N)*2Nの変換がPU232Aのために使用されることがあり、(3/2N)*2Nの変換がPU234Aのために使用されることがある。代替的に、他の例では、同じサイズの変換が非対称のSDIPにおいて2つのPUのために使用されることがある。たとえば、ブロック220では、(1/2N)*2Nの変換がPU232Aのために使用されることがあり、3つの(1/2N)*2Nの変換がPU234Aのために使用されることがある。
図9は、非正方形の四分木区分のための例示的な区分構造を示す概念図である。図9に示されるように、ブロック240は非正方形四分木変換(NSQT:non-square quadtree transforms)を使用して区分され得る。一般に、NSQTは、CUのTUなどのブロックが4つの第1のレベルの非正方形の長方形へと区分されることを可能にし、これらの長方形のいずれかまたはすべてがさらに、4つの追加のレベルのより小さな等しいサイズの非正方形の長方形へと区分され得る。図9の例では、ブロック240はサイズ2N×2Nを有する。ブロックは、4つの2N×(N/2)または(N/2)×2Nの長方形242A〜242Dへと区分され得る。これらの第1レベルのブロック242のいずれかまたはすべてはさらに、サイズがN×(N/4)である第2のレベルの4つのより小さな等しいサイズの非正方形ブロック、たとえばブロック244A〜244D(ブロック244、縮尺通りに描かれていない)へと区分され得る。
ブロック240は2つのレベルのサブブロック(242、244)へと区分されるものとして図9では示されているが、ブロック240などのブロックは、さらに区分されない1つのレベルのブロックへと区分され得る。NSQTは、ブロックの変換単位(TU)を区分するために一般に使用され、ここでTUは残差データと関連付けられる変換係数を含む。
いくつかの例では、図9に示されるものなどのRQTツリー構造は、非対称SDIP区分されたCUに使用され得る。たとえば、ブロック220(図8)では、PU232Aのための変換は、(1/2N)*2NのTU(ブロック242など)などのレベル1のTU、または、4つの(1/4N)*NのTU、たとえば4つのレベル2のTU(ブロック244など)のいずれかであり得る。RQTは、TUがサブTUへとさらに分割されるかどうかを各TUについて示す、分割フラグシンタックス要素を含み得る。このようにして、分割または非分割の判定が分割フラグによって示され得る。
図10Aおよび図10Bは、本開示の様々な態様による、ビデオエンコーダ20およびビデオデコーダ30がSDIPベースのコーディングを修正するために実施し得る適応的な処理順序の変更を示す概念図である。図10Aは、SDIPコーディングされたCU262を示す。イントラ予測角度264が実線の矢印で示されており、SDIPコーディングされたCU262の具体的な例では、イントラ予測角度264は左下のイントラ予測角度である。イントラ予測角度264が左下であることを検出したことに基づいて、ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施することによって、修正された処理順序266を形成するためにSDIPコーディングされたLCU262のサブブロックの処理順序を適応させることができる。修正された処理順序266は2つの別々の破線の矢印を使用して示されており、一方の矢印は修正された処理順序266の垂直方向の態様を示し、他方の矢印は修正された処理順序266の水平方向の態様を示す。SDIPコーディングされたLCU262の場合、イントラ予測角度264が左下であることに基づいて、ビデオエンコーダ20およびビデオデコーダ30は、サブブロックの修正された処理順序266を下から上および左から右となるように形成することができる。より具体的には、本開示の技法によれば、イントラ予測角度264が左下であることを検出したことに応答して、ビデオエンコーダ20およびビデオデコーダ30は、既存のSDIPベースのコーディング技術の上から下、左から右の処理順序から離れることができ、代わりに、SDIPコーディングされたCU262のために修正された処理順序266の下から上、左から右の態様を使用することができる。
図10Bは、SDIPコーディングされたCU272を示す。イントラ予測角度274が実線の矢印で示されており、SDIPコーディングされたCU272の具体的な例では、イントラ予測角度274は右上のイントラ予測角度である。イントラ予測角度274が右上であることを検出したことに基づいて、ビデオエンコーダ20およびビデオデコーダ30は、本開示の技法を実施することによって、修正された処理順序276を形成するためにSDIPコーディングされたLCU272のサブブロックの処理順序を適応させることができる。修正された処理順序276は2つの別々の破線の矢印を使用して示されており、一方の矢印は修正された処理順序276の垂直方向の態様を示し、他方の矢印は修正された処理順序276の水平方向の態様を示す。SDIPコーディングされたLCU272の場合、イントラ予測角度274が右上であることに基づいて、ビデオエンコーダ20およびビデオデコーダ30は、サブブロックの修正された処理順序266を上から下および右から左となるように形成することができる。より具体的には、本開示の技法によれば、イントラ予測角度274が右上であることを検出したことに応答して、ビデオエンコーダ20およびビデオデコーダ30は、既存のSDIPベースのコーディング技術の上から下、左から右の処理順序から離れることができ、代わりに、SDIPコーディングされたCU272のために修正された処理順序276の上から下、右から左の態様を使用することができる。
図11は、ビデオデコーダ30が本開示の1つまたは複数の技法を実行するために実施し得る例示的なプロセス300を示すフローチャートである。ビデオデコーダ30は、ビデオデータの符号化されたサブブロックがSDIPを使用して復号されるべきであると決定することができる(302)。そして、ビデオデコーダ30は、SDIPに従って復号されるべきサブブロックのためのイントラ予測方向を決定することができる(304)。
ビデオデコーダ30は、イントラ予測方向が左下の方向であるかどうかを決定することができる(判定ブロック306)。イントラ予測方向が左下の方向であるという決定に基づいて(判定ブロック306のYESの分岐)、ビデオデコーダ30は、サブブロックのSDIPベースの復号のために下から上、左から右の処理順序を実施することができる(308)。一方、イントラ予測方向が左下の方向ではないという決定に基づいて(判定ブロック306のNOの分岐)、ビデオデコーダ30は、イントラ予測方向が右上の方向であるかどうかを決定することができる(判定ブロック310)。
イントラ予測方向が右上の方向であるという決定に基づいて(判定ブロック310のYESの分岐)、ビデオデコーダ30は、サブブロックのSDIPベースの復号のために上から下、右から左の処理順序を実施することができる(312)。一方、イントラ予測方向が右上の方向ではないという決定に基づいて(判定ブロック310のNOの分岐)、ビデオデコーダ30は、サブブロックのSDIPベースの復号のために上から下、左から右の処理順序を実施することができる(314)。したがって、本開示の技法によれば、ビデオデコーダ30は、SDIPモードのためのイントラ予測角度が左下でも右上でもない場合、サブブロックのSDIPベースの復号のために上から下、左からの右の処理順序を実施することができる。
図12は、ビデオエンコーダ20が本開示の1つまたは複数の技法を実行するために実施し得る例示的なプロセス320を示すフローチャートである。ビデオエンコーダ20は、ビデオデータのサブブロックがSDIPを使用して符号化されるべきであると決定することができる(322)。そして、ビデオエンコーダ20は、SDIPに従って符号化されるべきサブブロックのためのイントラ予測方向を決定することができる(324)。
ビデオエンコーダ20は、イントラ予測方向が左下の方向であるかどうかを決定することができる(判定ブロック326)。イントラ予測方向が左下の方向であるという決定に基づいて(判定ブロック326のYESの分岐)、ビデオエンコーダ20は、サブブロックのSDIPベースの符号化のために下から上、左から右の処理順序を実施することができる(328)。一方、イントラ予測方向が左下の方向ではないという決定に基づいて(判定ブロック326のNOの分岐)、ビデオエンコーダ20は、イントラ予測方向が右上の方向であるかどうかを決定することができる(判定ブロック330)。
イントラ予測方向が右上の方向であるという決定に基づいて(判定ブロック330のYESの分岐)、ビデオエンコーダ20は、サブブロックのSDIPベースの符号化のために上から下、右から左の処理順序を実施することができる(332)。一方、イントラ予測方向が右上の方向ではないという決定に基づいて(判定ブロック330のNOの分岐)、ビデオエンコーダ20は、サブブロックのSDIPベースの符号化のために上から下、左から右の処理順序を実施することができる(334)。
図13は、ビデオコーディングデバイスが本開示の変換操作の態様の1つまたは複数を実行するために実施し得る例示的なプロセス350を示すフローチャートである。プロセス350は、本明細書ではビデオデコーダ30に関して説明される。ビデオデコーダ30は、復号のための長方形変換単位(TU)を特定することができる(352)。そして、ビデオデコーダ30は、長方形TUがK対Lの次元を有すると決定することができる(354)。KはTUの中の画素の行の数を表し、式(1<<n)を使用して得られる整数値であり、ここで「n」は整数値を表す。LはTUの中の画素の列の数を表し、式(1<<m)を使用して得られる整数値であり、ここで「m」は整数値を表す。言い換えると、Kは、1だけ左シフトされた整数値「m」に等しい値を有し、Lは、1だけ左シフトされた整数値「n」に等しい値を有する。
ビデオデコーダ30は、nとmの和が奇数になるかどうかを決定することができる(判定ブロック356)。nとmの和が奇数にならないという決定に基づいて(判定ブロック356のNOの分岐)、ビデオデコーダ30は、TUを逆量子化するための修正されていない量子化パラメータ(QP)値を使用することができる(358)。一方、nとmの和が奇数になるとビデオデコーダ30が決定する場合(判定ブロック356のYESの分岐)、ビデオデコーダ30は、デルタQPを加算することによって、長方形PUを逆量子化するためのQP値を修正することができる(362)。様々な例では、ビデオデコーダ30は、所定のデルタQP値(たとえば、マイナス3)を使用することができ、または、正方形TUのためのQP値を使用してデルタQP値を適応的に導出することができる。そして、ビデオデコーダ30は、修正されたQP値を使用してTUを逆量子化することができる(364)。
本開示のいくつかの態様は、説明を目的にHEVC規格および/または1つまたは複数のHEVC拡張に関して説明されている。しかしながら、本開示において説明される技法は、H.264またはまだ開発されていない他の規格もしくはプロプライエタリなビデオコーディングプロセスに従って定義されたものなどの、他のビデオコーディングプロセスに有用であり得る。
ビデオコーダは、本開示において説明されるように、ビデオエンコーダまたはビデオデコーダを指し得る。同様に、ビデオコーディングユニットは、ビデオエンコーダまたはビデオデコーダを指し得る。同じく、ビデオコーディングは、ビデオ符号化またはビデオ復号を指し得る。
例によっては、本明細書において説明された技法のうちのいずれかのいくつかの行為またはイベントが、異なるシーケンスで実行されてよく、追加され、統合され、または完全に除外されてよい(たとえば、説明したすべての行為またはイベントが技法の実践にとって必要であるとは限らない)ことを認識されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて並行して実行されてよい。
1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され、またはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に相当するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的である有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に相当し得る。データ記憶媒体は、本開示において説明される技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書において使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標)レイディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生するが、ディスク(disc)は、レーザを用いて光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の等価な集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書において使用される「プロセッサ」という用語は、上記の構造、または本明細書において説明される技法の実装に適した任意の他の構造のいずれかを指すことがある。加えて、いくつかの態様では、本明細書において説明される機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内で与えられることがあり、あるいは複合コーデックに組み込まれることがある。また、技法は、1つまたは複数の回路または論理要素において完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示される技法を実施するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて結合されることがあり、または適切なソフトウェアおよび/もしくはファームウェアとともに、上で説明されたような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されることがある。
様々な例が説明されてきた。これらおよび他の例は、以下の特許請求の範囲内に入る。
10 システム
12 ソースデバイス
14 宛先デバイス
16 コンピュータ可読媒体
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
32 ディスプレイデバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 区分ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピー符号化ユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 参照ピクチャメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 参照ピクチャメモリ
98 四分木
100 ルートノード
102 ノード
106 リーフノード
108 リーフノード
120 最大コーディング単位
122 サブCU
124 サブCU
126 サブCU
140 区分モード
142 区分モード
144 区分モード
146 区分モード
148 区分モード
150 区分モード
152 区分モード
154 区分モード
156 区分モード
158 区分モード
160 コーディング単位
180 LCU
182 サブCU
184 サブCU
186 サブCU
188 サブCU
190 サブCU
192 サブCU
194 サブCU
196 PU
220 ブロック
222 ブロック
224 ブロック
226 ブロック
230 垂直方向の辺
232 PU
234 PU
240 ブロック
242 長方形
244 ブロック
262 SDIPコーディングされたCU
264 イントラ予測角度
266 修正された処理順序
272 SDIPコーディングされたLCU
274 イントラ予測角度
276 修正された処理順序
300 プロセス
320 プロセス
350 プロセス

Claims (30)

  1. 符号化されたビデオデータを復号する方法であって、
    長方形変換単位(TU)が第1の整数値「K」により表記される画素の行の数と第2の整数値「L」により表記される画素の列の数とを備えると決定するステップであって、Kが、1だけ左シフトされた整数値「m」に等しい値を有し、Lが、1だけ左シフトされた整数値「n」に等しい値を有する、ステップと、
    nとmの和が奇数であると決定するステップと、
    nとmの前記和が奇数であることに基づいて、デルタ量子化パラメータ(デルタQP)値を前記長方形TUのための量子化パラメータ(QP)値に加算して、前記長方形TUのための修正されたQP値を取得するステップとを備える、方法。
  2. スケーリング係数を前記長方形TUの画素に適用するステップをさらに備え、前記スケーリング係数が正方形の変換サイズと関連付けられる、請求項1に記載の方法。
  3. 前記正方形の変換サイズが((n+m)>>1)対((n+m)>>1)の次元と関連付けられ、
    「>>」が算術的な右シフト演算を表す、請求項2に記載の方法。
  4. 前記正方形の変換サイズが((n+m+1)>>1)対((n+m+1)>>1)の次元と関連付けられ、
    「>>」が算術的な右シフト演算を表す、請求項2に記載の方法。
  5. K対Kの次元を伴う正方形の変換のQP値に基づいて前記デルタQP値を決定するステップをさらに備える、請求項1に記載の方法。
  6. 前記デルタQP値が-3(マイナス3)の値であると決定するステップをさらに備える、請求項1に記載の方法。
  7. 符号化されたビデオデータを記憶するように構成されるメモリデバイスと、
    前記メモリデバイスに結合された処理回路とを備え、前記処理回路が、
    前記メモリデバイスに記憶されている前記符号化されたビデオデータの長方形変換単位(TU)が第1の整数値「K」により表記される画素の行の数と第2の整数値「L」により表記される画素の列の数とを備えると決定することであって、Kが1だけ左シフトされた整数値「m」に等しい値を有し、Lが1だけ左シフトされた整数値「n」に等しい値を有する、決定することと、
    nとmの和が奇数であると決定することと、
    nとmの前記和が奇数であることに基づいて、デルタ量子化パラメータ(デルタQP)値を前記長方形TUのための量子化パラメータ(QP)値に加算して、前記長方形TUのための修正されたQP値を取得することと
    を行うように構成される、ビデオ復号デバイス。
  8. 前記処理回路がさらに、スケーリング係数を前記長方形TUの画素に適用するように構成され、前記スケーリング係数が正方形の変換サイズと関連付けられる、請求項7に記載のビデオ復号デバイス。
  9. 前記正方形の変換サイズが((n+m)>>1)対((n+m)>>1)の次元と関連付けられ、
    「>>」が算術的な右シフト演算を表す、請求項8に記載のビデオ復号デバイス。
  10. 前記正方形の変換サイズが((n+m+1)>>1)対((n+m+1)>>1)の次元と関連付けられ、
    「>>」が算術的な右シフト演算を表す、請求項8に記載のビデオ復号デバイス。
  11. 前記QP値に基づいて前記デルタQP値を決定するステップをさらに備える、請求項7に記載のビデオ復号デバイス。
  12. 前記デルタQP値が-3(マイナス3)の値であると決定するステップをさらに備える、請求項7に記載のビデオ復号デバイス。
  13. 前記修正されたQP値および前記長方形TUを使用して再構築される1つまたは複数のピクチャを表示するように構成されるディスプレイをさらに備える、請求項7に記載のビデオ復号デバイス。
  14. 符号化されたビデオデータを記憶するように構成されるメモリデバイスと、
    前記メモリデバイスに結合された処理回路とを備え、前記処理回路が、
    前記メモリデバイスに記憶されている前記符号化されたビデオデータのサブブロックが短距離イントラ予測(SDIP)に従って復号されるべきであると決定し、
    前記メモリデバイスに記憶されている前記符号化されたビデオデータの前記サブブロックと関連付けられるイントラ予測方向を決定し、
    前記イントラ予測方向が左下の方向を備えるという決定に応答して、前記サブブロックのSDIPベースの復号のための処理順序が下から上の処理順序を備えると決定し、
    前記イントラ予測方向が右上の方向を備えるという決定に応答して、前記サブブロックの前記SDIPベースの復号のための前記処理順序が右から左の処理順序を備えると決定する
    ように構成される、ビデオ復号デバイス。
  15. 前記処理回路がさらに、
    前記イントラ予測方向が前記左下の方向も前記右上の方向も備えないという決定に応答して、前記サブブロックの前記SDIPベースの復号のための前記処理順序が上から下の処理順序と左から右の処理順序の両方を備えると決定するように構成される、請求項14に記載のビデオ復号デバイス。
  16. 前記左下の方向が、前記サブブロックの現在の画素を前記現在の画素の左下の近隣の画素に基づいて予測することと関連付けられ、
    前記右上の方向が、前記サブブロックの前記現在の画素を前記現在の画素の右上の近隣の画素に基づいて予測することと関連付けられる、請求項14に記載のビデオ復号デバイス。
  17. 前記処理回路がさらに、
    前記サブブロックのコーディング済ブロックフラグ(CBF)値と、前記処理順序において前記サブブロックに先行する以前に復号されたサブブロックのCBF値との差を決定し、
    前記決定された差を使用して前記サブブロックの前記CBF値を再構築するように構成される、請求項14に記載のビデオ復号デバイス。
  18. 前記以前に復号されたサブブロックが、前記サブブロックに隣接して位置する近隣のサブブロックである、請求項17に記載のビデオ復号デバイス。
  19. 前記処理回路がさらに、
    前記以前に復号されたサブブロックの前記CBFをエントロピー復号するために使用されるコンテキストに基づいて、前記サブブロックの前記CBFのエントロピー復号のためのコンテキストを予測するように構成される、請求項17に記載のビデオ復号デバイス。
  20. 前記処理回路がさらに、
    前記処理順序において前記サブブロックに先行する以前に復号されたサブブロックの最終有意係数の場所の大きさを決定し、
    前記以前に復号されたサブブロックの前記最終有意係数の前記場所の前記決定された大きさに基づいて、SDIPに従って復号されるべき前記サブブロックの最終有意係数の場所を復号するためのコンテキストを選択するように構成される、請求項14に記載のビデオ復号デバイス。
  21. 前記サブブロックの前記最終有意係数の前記場所を復号するための前記コンテキストを選択するために、前記処理回路が、
    前記以前に復号されたサブブロックの前記最終有意係数の前記場所が0より大きい場合、前記サブブロックの前記最終有意係数の前記場所を復号するための第1のコンテキストセットを選択し、または、
    前記以前に復号されたサブブロックの前記最終有意係数の前記場所が0以下である場合、前記サブブロックの前記最終有意係数の前記場所を復号するための第2のコンテキストセットを選択するように構成され、
    前記第1のコンテキストセットが前記第2のコンテキストセットと異なる、請求項20に記載のビデオ復号デバイス。
  22. カメラ、コンピュータ、モバイルデバイス、放送受信機デバイス、またはセットトップボックスのうちの1つまたは複数をさらに備える、請求項14に記載のビデオ復号デバイス。
  23. ビデオデータを符号化する方法であって、
    前記ビデオデータのサブブロックが短距離イントラ予測(SDIP)に従って符号化されるべきであると決定するステップと、
    前記ビデオデータの前記サブブロックと関連付けられるイントラ予測方向を決定するステップと、
    前記イントラ予測方向が左下の方向を備えるとの決定に応答して、前記サブブロックのSDIPベースの符号化のための処理順序が下から上の処理順序を備えると決定すること、または、
    前記イントラ予測方向が右上の方向を備えるとの決定に応答して、前記サブブロックの前記SDIPベースの符号化のための前記処理順序が右から左の処理順序を備えると決定すること
    のうちの1つを実行するステップとを備える、方法。
  24. 前記イントラ予測方向が前記左下の方向も前記右上の方向も備えないとの決定に応答して、前記サブブロックの前記SDIPベースの符号化のための前記処理順序が上から下の処理順序と左から右の処理順序の両方を備えると決定するステップをさらに備える、請求項23に記載の方法。
  25. 前記左下の方向が、前記サブブロックの現在の画素を前記現在の画素の左下の近隣の画素に基づいて予測することと関連付けられ、
    前記右上の方向が、前記サブブロックの前記現在の画素を前記現在の画素の右上の近隣の画素に基づいて予測することと関連付けられる、請求項23に記載の方法。
  26. 前記サブブロックのコーディング済ブロックフラグ(CBF)値と、前記処理順序において前記サブブロックに先行する以前に符号化されたサブブロックのCBF値との差を決定するステップと、
    前記サブブロックと関連付けられるCBFマスクとして前記差をシグナリングするステップとをさらに備える、請求項23に記載の方法。
  27. 前記以前に符号化されたサブブロックが、前記サブブロックに隣接して位置する近隣のサブブロックである、請求項26に記載の方法。
  28. 前記以前に符号化されたサブブロックの前記CBFをエントロピー符号化するために使用されるコンテキストに基づいて、前記サブブロックの前記CBFのエントロピー符号化のためのコンテキストを予測するステップをさらに備える、請求項26に記載の方法。
  29. 前記処理順序において前記サブブロックに先行する以前に符号化されたサブブロックの最終有意係数の場所の大きさを決定するステップと、
    前記以前に符号化されたサブブロックの前記最終有意係数の前記場所の前記決定された大きさに基づいて、SDIPに従って符号化されるべき前記サブブロックの最終有意係数の場所を符号化するためのコンテキストを選択するステップとをさらに備える、請求項23に記載の方法。
  30. 前記サブブロックの前記最終有意係数の前記場所を符号化するための前記コンテキストを選択するステップが、
    前記以前に符号化されたサブブロックの前記最終有意係数の前記場所が0より大きい場合、前記サブブロックの前記最終有意係数の前記場所を符号化するための第1のコンテキストセットを選択するステップ、または、
    前記以前に符号化されたサブブロックの前記最終有意係数の前記場所が0以下である場合、前記サブブロックの前記最終有意係数の前記場所を符号化するための第2のコンテキストセットを選択するステップ
    のうちの1つを実行するステップを備え、
    前記第1のコンテキストセットが前記第2のコンテキストセットと異なる、請求項29に記載の方法。
JP2018515827A 2015-09-29 2016-09-29 短距離イントラ予測（ｓｄｉｐ）ベースのビデオコーディング Pending JP2018534835A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562234589P 2015-09-29 2015-09-29
US62/234,589 2015-09-29
US15/278,855 US10218975B2 (en) 2015-09-29 2016-09-28 Transform precision manipulation in video coding
US15/278,855 2016-09-28
PCT/US2016/054397 WO2017059044A1 (en) 2015-09-29 2016-09-29 Delta qp for quantization of rectangular transform units, short distance intra prediction (sdip) based video coding

Publications (1)

Publication Number Publication Date
JP2018534835A true JP2018534835A (ja) 2018-11-22

Family

ID=58407621

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018515827A Pending JP2018534835A (ja) 2015-09-29 2016-09-29 短距離イントラ予測（ｓｄｉｐ）ベースのビデオコーディング

Country Status (7)

Country Link
US (1) US10218975B2 (ja)
EP (1) EP3357240A1 (ja)
JP (1) JP2018534835A (ja)
KR (1) KR20180059893A (ja)
CN (1) CN108141590A (ja)
BR (1) BR112018006412A2 (ja)
WO (1) WO2017059044A1 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9112526B2 (en) * 2011-06-15 2015-08-18 Sony Corporation Binarization of DQP using separate absolute value and sign (SAVS) in CABAC
WO2017131233A1 (ja) * 2016-01-28 2017-08-03 日本放送協会 符号化装置、復号装置及びプログラム
CN113810706A (zh) * 2016-04-29 2021-12-17 世宗大学校产学协力团 用于对图像信号进行编码和解码的方法和装置
CN116506607A (zh) * 2016-08-01 2023-07-28 韩国电子通信研究院 图像编码/解码方法和设备以及存储比特流的记录介质
US10715818B2 (en) * 2016-08-04 2020-07-14 Intel Corporation Techniques for hardware video encoding
US10602174B2 (en) 2016-08-04 2020-03-24 Intel Corporation Lossless pixel compression for random video memory access
CN115802036A (zh) * 2016-10-10 2023-03-14 三星电子株式会社 用于对图像进行编码/解码的方法和设备
CN116437109A (zh) * 2017-01-31 2023-07-14 夏普株式会社 用于执行平面帧内预测视频编码的***和方法
US10630974B2 (en) * 2017-05-30 2020-04-21 Google Llc Coding of intra-prediction modes
KR20230030054A (ko) 2018-02-09 2023-03-03 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 파티션 기반 인트라 코딩 개념
US10771781B2 (en) * 2018-03-12 2020-09-08 Electronics And Telecommunications Research Institute Method and apparatus for deriving intra prediction mode
US20210136406A1 (en) * 2018-03-30 2021-05-06 Nikon Corporation Video compression apparatus, decompression apparatus and recording medium
AU2019269346B2 (en) * 2018-05-14 2023-07-27 Interdigital Vc Holdings, Inc. Block shape adaptive intra prediction directions for quadtree-binary tree
CN112369025A (zh) * 2018-07-02 2021-02-12 交互数字Vc控股公司 基于上下文的二进制算术编码和解码
US10284844B1 (en) * 2018-07-02 2019-05-07 Tencent America LLC Method and apparatus for video coding
EP3821605A1 (en) 2018-07-13 2021-05-19 FRAUNHOFER-GESELLSCHAFT zur Förderung der angewandten Forschung e.V. Partitioned intra coding concept
WO2020054784A1 (ja) * 2018-09-11 2020-03-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 符号化装置、復号装置、符号化方法および復号方法
FR3086486A1 (fr) * 2018-09-21 2020-03-27 Orange Procedes et dispositifs de codage et de decodage d'un flux de donnees representatif d'au moins une image.
US11381825B2 (en) * 2018-11-27 2022-07-05 Advanced Micro Devices, Inc. Variable rate rendering based on motion estimation
CN109685718B (zh) * 2018-12-17 2020-11-10 中国科学院自动化研究所 图片方形化缩放方法、***及装置
CN111405279B (zh) * 2019-01-03 2021-06-29 华为技术有限公司 量化、反量化方法及装置
US11356699B2 (en) * 2019-01-11 2022-06-07 Hfi Innovation Inc. Method and apparatus of sub-block deblocking in video coding
CN117793346A (zh) 2019-01-31 2024-03-29 北京字节跳动网络技术有限公司 视频编解码中的细化量化步骤
US20220132109A1 (en) * 2019-02-21 2022-04-28 Lg Electronics Inc. Image decoding method and apparatus using intra prediction in image coding system
US11025913B2 (en) 2019-03-01 2021-06-01 Intel Corporation Encoding video using palette prediction and intra-block copy
CN117579818A (zh) * 2019-03-11 2024-02-20 北京达佳互联信息技术有限公司 视频编解码中变换系数的编解码
CN109982075B (zh) * 2019-03-21 2022-11-08 南京威翔科技有限公司 一种基于fpga的帧内预测通用角度方法
EP3963883A4 (en) 2019-06-04 2023-06-14 Beijing Bytedance Network Technology Co., Ltd. GEOMETRIC PARTITION MODE CODING MOVEMENT CANDIDATES LIST
EP3963890A4 (en) 2019-06-04 2022-11-02 Beijing Bytedance Network Technology Co., Ltd. BUILDING A LIST OF MOVEMENT CANDIDATES USING NEIGHBOR BLOCK INFORMATION
WO2020248954A1 (en) * 2019-06-09 2020-12-17 Beijing Bytedance Network Technology Co., Ltd. Significant coefficient signaling in video coding
US10855983B2 (en) 2019-06-13 2020-12-01 Intel Corporation Encoding video using two-stage intra search
CN114073091A (zh) * 2019-06-21 2022-02-18 三星电子株式会社 视频编码方法和装置以及视频解码方法和装置
WO2021008513A1 (en) 2019-07-14 2021-01-21 Beijing Bytedance Network Technology Co., Ltd. Transform block size restriction in video coding
EP3796654A1 (en) * 2019-09-20 2021-03-24 Axis AB Privacy masks where intra coefficients are set to zero
CN117596389A (zh) 2019-09-28 2024-02-23 北京字节跳动网络技术有限公司 视频编解码中的几何分割模式
US20230024223A1 (en) * 2019-12-05 2023-01-26 Interdigital Vc Holdings France, Sas Intra sub partitions for video encoding and decoding combined with multiple transform selection, matrix weighted intra prediction or multi-reference-line intra prediction
US20220400275A1 (en) * 2021-06-10 2022-12-15 Tencent America LLC Zero Residual Flag Coding

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101457418B1 (ko) * 2009-10-23 2014-11-04 삼성전자주식회사 계층적 부호화 단위의 크기에 따른 비디오 부호화 방법과 그 장치, 및 비디오 복호화 방법과 그 장치
US10298939B2 (en) * 2011-06-22 2019-05-21 Qualcomm Incorporated Quantization in video coding
US8958472B2 (en) 2011-09-08 2015-02-17 Google Technology Holdings LLC Methods and apparatus for quantization and dequantization of a rectangular block of coefficients
GB2508339A (en) * 2012-11-22 2014-06-04 Sony Corp Manipulation of transform coefficient blocks in high-efficiency video coding (HEVC)
US20140198855A1 (en) 2013-01-14 2014-07-17 Qualcomm Incorporated Square block prediction
US9445132B2 (en) 2013-09-09 2016-09-13 Qualcomm Incorporated Two level last significant coefficient (LSC) position coding
GB2521117B (en) 2013-10-25 2017-02-15 Canon Kk Method of encoding or decoding a video frame

Also Published As

Publication number Publication date
US20170094274A1 (en) 2017-03-30
KR20180059893A (ko) 2018-06-05
WO2017059044A1 (en) 2017-04-06
US10218975B2 (en) 2019-02-26
CN108141590A (zh) 2018-06-08
BR112018006412A2 (pt) 2018-10-09
EP3357240A1 (en) 2018-08-08

Similar Documents

Publication Publication Date Title
US10218975B2 (en) Transform precision manipulation in video coding
TWI699110B (zh) 使用一全文自適應二進位算術寫碼設計來寫碼資料
CN108141608B (zh) 针对视频译码使用与位置相关的预测组合的改进视频帧内预测
JP6543716B2 (ja) 適応型成分間残差予測
US9883203B2 (en) Adaptive overlapped block motion compensation
JP6165798B2 (ja) イントラ予測を使用したビデオ符号化
US9838718B2 (en) Secondary boundary filtering for video coding
US9008175B2 (en) Intra smoothing filter for video coding
US9912944B2 (en) Simplified non-square quadtree transforms for video coding
US20130163664A1 (en) Unified partition mode table for intra-mode coding
KR102182441B1 (ko) 비디오 코딩에서 ｈｅｖｃ 확장들을 위한 다중 계층들의 저복잡도 지원
JP2014535225A (ja) イントラモードビデオコーディング
JP6199371B2 (ja) ビデオ・コーディングのためのインタ・レイヤ・テクスチャ予測
KR20140016983A (ko) 비디오 코딩을 위한 런-모드 기반 계수 코딩
CN111149361B (zh) 具有在用于视频译码的随机存取配置中的未来参考帧的自适应图片群组结构
CN113612997B (zh) 针对视频译码使用与位置相关的预测组合的改进视频帧内预测

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180330