JP7477687B2 - ビデオコーディングのための変換ユニット区分方法 - Google Patents

ビデオコーディングのための変換ユニット区分方法 Download PDF

Info

Publication number
JP7477687B2
JP7477687B2 JP2023078106A JP2023078106A JP7477687B2 JP 7477687 B2 JP7477687 B2 JP 7477687B2 JP 2023078106 A JP2023078106 A JP 2023078106A JP 2023078106 A JP2023078106 A JP 2023078106A JP 7477687 B2 JP7477687 B2 JP 7477687B2
Authority
JP
Japan
Prior art keywords
ttn
video
child
transform
dimension
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2023078106A
Other languages
English (en)
Other versions
JP2023104953A (ja
Inventor
ジアンレ・チェン
イン・ジャオ
Original Assignee
ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ホアウェイ・テクノロジーズ・カンパニー・リミテッド filed Critical ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Publication of JP2023104953A publication Critical patent/JP2023104953A/ja
Application granted granted Critical
Publication of JP7477687B2 publication Critical patent/JP7477687B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/40—Tree coding, e.g. quadtree, octree
    • 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/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/14—Coding unit complexity, e.g. amount of activity or edge presence estimation
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

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

Description

関連出願への相互参照
この特許出願は、Jianle Chen他によって2019年3月22日に出願された、発明の名称を「Transform Unit Partitioning for Video Coding」とする米国仮特許出願第62/822,533号の利益を主張する。
一般に、この開示は、ビデオコーディングにおけるビデオ圧縮のための技法を説明する。より具体的には、この開示は、パイプラインブロック構造に違反せずに変換ユニット区分を可能にする技法を説明する。
比較的短いビデオでさえ描画するために必要とされるビデオデータの量は、かなりであることがあり、これは、限定された帯域幅容量を有する通信ネットワークを渡ってデータがストリーミングされ、またはそうでなければ伝達されるべきとき、困難をもたらし得る。したがって、ビデオデータは、一般に、現代の遠隔通信ネットワークを渡って伝達される前に圧縮される。ビデオが記憶デバイスに記憶されるとき、メモリリソースが限定され得るので、ビデオのサイズも問題であることがある。ビデオ圧縮デバイスは、しばしば、ソースにおいてソフトウェアおよび／またはハードウェアを使用して、送信または記憶の前にビデオデータをコーディングし、それにより、デジタルビデオ画像を表現するために必要とされるデータの量を減らす。圧縮されたデータは次いで、ビデオデータを復号するビデオ解凍デバイスによってデスティネーションにおいて受信される。限定されたネットワークリソースおよびより高いビデオ品質のますます増える需要により、画像品質においてほとんどまたはまったく犠牲なしで圧縮比を改善する、改善された圧縮および解凍技法が望ましい。
第1の態様は、ビデオデコーダによって実行される、コーディングされたビデオビットストリームを復号する方法に関する。方法は、ビデオデコーダによって、第1の変換木ノード(TTN)寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用してTTNを区分するステップと、ビデオデコーダによって、変換ユニット(TU)を変換係数に適用して、TTNが区分された後の残差を生成するステップと、ビデオデコーダによって、残差に基づいて再構築されたブロックを生成するステップとを含む。
方法は、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの区分が第2の子TTN寸法に等しい第1の子TTN寸法を有する生成子TTNを生成することを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、ビデオデコーダによって、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、四分木分割を使用して子TTNを区分してTUを生成するステップと、ビデオデコーダによって、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズ以下であるとき、子TTNがTUであると決定するステップとを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1のTTN寸法および第2のTTN寸法がルマサンプルの数で測られることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1の子TTN寸法および第2の子TTN寸法がルマサンプルの数で測られることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの中のすべてのTUのTTN深度が1に設定されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの中のすべてのTUのTTN深度がTUを取得するために必要とされる分割の数に従って設定されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、垂直二分木分割が、次のシンタックス、すなわち、verSplitFirst = (tbWidth>MaxTbSizeY&&tbWidth>tbHeight) ? 1 : 0に従って実行されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1のTTN寸法が2N個のルマサンプルであり、第2のTTN寸法がN個のルマサンプルであり、かつ最大TUサイズがN/2個のルマサンプルであるとき、TTNは垂直二分木分割を使用して区分されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、N=64個のルマサンプルであることを提供する。
第2の態様は、ビデオエンコーダによって実行される符号化の方法に関する。方法は、ビデオエンコーダによって、第1の変換木ノード(TTN)寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用してTTNを区分するステップと、ビデオエンコーダによって、変換ユニット(TU)を残差に適用して、TTNが区分された後の変換係数を生成するステップと、ビデオエンコーダによって、変換係数をビットストリームへと符号化し、ビデオエンコーダによって、ビデオデコーダに向けた送信のためにビットストリームを記憶するステップとを含む。
方法は、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの区分が第2の子TTN寸法に等しい第1の子TTN寸法を有する生成子TTNを生成することを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、ビデオデコーダによって、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、四分木分割を使用して子TTNを区分してTUを生成するステップと、ビデオデコーダによって、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズ以下であるとき、子TTNがTUであると決定するステップとを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1のTTN寸法および第2のTTN寸法がルマサンプルの数で測られることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1の子TTN寸法および第2の子TTN寸法がルマサンプルの数で測られることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの中のすべてのTUのTTN深度が1に設定されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、TTNの中のすべてのTUのTTN深度がTUを取得するために必要とされる分割の数に従って設定されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、垂直二分木分割が、次のシンタックス、すなわち、verSplitFirst = (tbWidth>MaxTbSizeY&&tbWidth>tbHeight) ? 1 : 0に従って実行されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、第1のTTN寸法が2N個のルマサンプルであり、第2のTTN寸法がN個のルマサンプルであり、かつ最大TUサイズがN/2個のルマサンプルであるとき、TTNは垂直二分木分割を使用して区分されることを提供する。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、N=64個のルマサンプルであることを提供する。
第3の態様は復号デバイスに関する。復号デバイスは、コーディングされたビデオビットストリームを受信するように構成された受信機と、受信機に結合されたメモリであって、メモリが命令を記憶する、メモリと、メモリに結合されたプロセッサであって、プロセッサが、命令を実行して、復号デバイスに、第1の変換木ノード(TTN)寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用してTTNを区分させ、変換ユニット(TU)を変換係数に適用させて、TTNが区分された後の残差を生成させ、残差に基づいて再構築されたブロックを生成させるように構成された、プロセッサとを含む。
復号デバイスは、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、復号デバイスが、再構築されたブロックを使用して生成された画像を表示するように構成されたディスプレイをさらに備えることを提供する。
第4の態様は符号化デバイスに関する。符号化デバイスは、命令を含むメモリと、メモリに結合されたプロセッサであって、プロセッサが、命令を実行して、符号化デバイスに、第1の変換木ノード(TTN)寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用してTTNを区分させ、ビデオエンコーダによって、変換ユニット(TU)を残差に適用させて、TTNが区分された後の変換係数を生成させ、変換係数をビットストリームへと符号化させるように構成された、プロセッサと、プロセッサに結合された送信機であって、送信機が、ビデオデコーダに向けてビットストリームを送信するように構成された、送信機とを含む。
符号化デバイスは、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
任意選択で、先行する態様のいずれかにおいて、態様の別の実装は、送信機がビデオデコーダに向けてビットストリームを送信する前にメモリがビットストリームを記憶することを提供する。
第5の態様はコーディング装置に関する。コーディング装置は、符号化すべきピクチャを受信し、または復号すべきビットストリームを受信するように構成された受信機と、受信機に結合された送信機であって、送信機が、ビットストリームをデコーダに送信し、または復号された画像をディスプレイに送信するように構成された、送信機と、受信機または送信機のうちの少なくとも1つに結合されたメモリであって、メモリが命令を記憶するように構成された、メモリと、メモリに結合されたプロセッサであって、プロセッサが、メモリに記憶された命令を実行して、ここで開示される方法のいずれかを実行するように構成された、プロセッサとを含む。
コーディング装置は、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
第6の態様はシステムに関する。システムは、エンコーダと、エンコーダと通信するデコーダとを含み、エンコーダまたはデコーダは、ここで開示される復号デバイス、符号化デバイス、またはコーディング装置を含む。
システムは、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
第7の態様はコーディングするための手段に関する。コーディングするための手段は、符号化すべきピクチャを受信し、または復号すべきビットストリームを受信するように構成された受信手段と、受信手段に結合された送信手段であって、送信手段が、ビットストリームを復号手段に送信し、または復号された画像を表示手段に送信するように構成された、送信手段と、受信手段または送信手段のうちの少なくとも1つに結合された記憶手段であって、記憶手段が命令を記憶するように構成された、記憶手段と、記憶手段に結合された処理手段であって、処理手段が、記憶手段に記憶された命令を実行して、ここで開示される方法のいずれかを実行するように構成された、処理手段とを含む。
コーディングするための手段は、第2の変換木ノード(TTN)寸法(たとえば、長方形TTN)と異なる第1のTTN寸法を有するTTNが、TTNの最大変換ユニット(TU)サイズが第1のTTN寸法より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分され、これが第2の子TTN寸法(たとえば、正方形の子TTN)に等しい第1の子TTN寸法を有する子TTNを生成する技法を提供する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、子TTNは、最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
この開示のより完全な理解のために、同様の参照番号は同様の部分を表現する、添付の図面および詳細な説明に関連して用いられる、次の簡単な説明への参照がここで行われる。
区分技法を利用し得る一例のコーディングシステムを例示するブロック図である。 区分技法を実行し得る一例のビデオエンコーダを例示するブロック図である。 区分技法を実行し得るビデオデコーダの例を例示するブロック図である。 A～Eは様々な区分タイプのうちの1つに従うブロックをまとめて例示する。 S×Sパイプライン構造に違反する変換ユニット区分技法の例を例示する。 S×Sパイプライン構造の完全性を維持する変換ユニット区分技法の実施形態を例示する。 S×Sパイプライン構造の完全性を維持する変換ユニット区分技法の実施形態を例示する。 コーディングされたビデオビットストリームを復号する方法の実施形態である。 ビデオビットストリームを符号化する方法の実施形態である。 ビデオコーディングデバイスの概略図である。 コーディングするための手段の実施形態の概略図である。
1つまたは複数の実施形態の例示的な実装が以下で提供されるが、開示されるシステムおよび／または方法は、現在知られているかまたは存在しているかにかかわらず、任意の数の技法を使用して実現され得ることが、最初に理解されるべきである。開示は、ここで例示され説明される、例示の設計および実装を含む、例示的な実装、図面、および以下で例示される技法に決して限定されるべきではなく、等価物の全範囲とともに添付の請求項の範囲内で修正され得る。
図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)、ケーブルモデムなど)、または両方の組み合わせを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはこれらの組み合わせであり得る。
この開示の技法は、ワイヤレスの応用または設定に必ずしも限定されない。技法は、地上波テレビ放送、ケーブルテレビ送信、衛星テレビ送信、HTTP上の動的適応ストリーミング(dynamic adaptive streaming over HTTP, DASH)のようなインターネットストリーミングビデオ送信、データ記憶媒体に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の応用のような、任意の様々なマルチメディア応用をサポートする、ビデオコーディングに適用され得る。いくつかの例では、コーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオ放送、および／またはビデオ電話のような応用をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。デスティネーションデバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。この開示によれば、ソースデバイス12のビデオエンコーダ20および／またはデスティネーションデバイス14のビデオデコーダ30は、ビデオコーディングのための技法を適用するように構成され得る。他の例では、ソースデバイスおよびデスティネーションデバイスは、他の構成要素または配置を含み得る。たとえば、ソースデバイス12は、外部カメラのような外部ビデオソースからビデオデータを受信し得る。同様に、デスティネーションデバイス14は、統合されたディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
図1の例示されたコーディングシステム10は単に一例である。ビデオコーディングのための技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。この開示の技法は一般にビデオコーディングデバイスによって実行されるが、この技法は典型的に「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、この開示の技法は、ビデオプリプロセッサによっても実行され得る。ビデオエンコーダおよび／またはデコーダは、グラフィクス処理ユニット(GPU)または類似のデバイスであり得る。
ソースデバイス12およびデスティネーションデバイス14は、単に、ソースデバイス12がデスティネーションデバイス14への送信のためにコーディングされたビデオデータを生成するようなコーディングデバイスの例である。いくつかの例では、ソースデバイス12およびデスティネーションデバイス14は、ソースおよびデスティネーションデバイス12、14の各々がビデオ符号化および復号構成要素を含むような、実質的に対称的なやり方で動作し得る。したがって、コーディングシステム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のために、ビデオデバイス12、14の間の一方向または双方向のビデオ送信をサポートし得る。
ソースデバイス12のビデオソース18は、ビデオカメラのようなビデオキャプチャデバイス、以前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータで生成されたビデオの組み合わせとして、コンピュータグラフィクスを基にしたデータを生成し得る。
いくつかの場合、ビデオソース18がビデオカメラであるとき、ソースデバイス12およびデスティネーションデバイス14は、いわゆるカメラ電話またはビデオ電話を形成し得る。しかしながら、上述のように、この開示において説明される技法は、一般にビデオコーディングに適用可能であってもよく、ワイヤレスおよび／または有線の応用に適用されてもよい。各々の場合において、キャプチャされた、プリキャプチャされた、またはコンピュータで生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオ情報は次いで、コンピュータ可読媒体16へと出力インターフェース22によって出力され得る。
コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくは有線ネットワーク送信のような一時的媒体、または、ハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、または他のコンピュータ可読媒体のような記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(表されていない)は、ソースデバイス12から符号化されたビデオデータを受信し、たとえばネットワーク送信を介して、符号化されたビデオデータをデスティネーションデバイス14に提供し得る。同様に、ディスクスタンピング設備のような、媒体製造設備のコンピューティングデバイスが、ソースデバイス12から符号化されたビデオデータを受信し、符号化されたビデオデータを含むディスクを作り出し得る。したがって、様々な例において、コンピュータ可読媒体16は、様々な形式の1つまたは複数のコンピュータ可読媒体を含むように理解され得る。
デスティネーションデバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロックおよび他のコーディングされるユニット、たとえばグループオブピクチャ(GOP)の特性および／または処理を記述するシンタックス要素を含む、ビデオデコーダ30によっても使用される、ビデオエンコーダ20によって定義されるシンタックス情報を含み得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスのような、種々のディスプレイデバイスのいずれかを備え得る。
ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディング(High Efficiency Video Coding, HEVC)規格のようなビデオコーディング規格に従って動作してもよく、HEVCテストモデル(HEVC Test Model, HM)に準拠してもよい。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、動画専門家集団(Moving Picture Expert Group, MPEG)-4、パート10、アドバンスド・ビデオ・コーディング(Advanced Video Coding, AVC)と代替的に呼ばれる、国際電気通信連合電気通信標準化セクタ(International Telecommunications Union Telecommunication Standardization Sector, ITU-T) H.264規格、H.265/HEVC、またはそのような規格の拡張のような、他の専有または業界の規格に従って動作し得る。しかしながら、この開示の技法は、いずれかの特定のコーディング規格に限定されない。ビデオコーディング規格の他の例は、MPEG-2およびITU-T H.263を含む。図1には表されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと統合されてもよく、共通のデータストリームまたは別個のデータストリームにおけるオーディオとビデオの両方の符号化を扱うために、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット、または他のハードウェアとソフトウェアを含んでもよい。適用可能な場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせのような、種々の適切なエンコーダ回路のいずれかとして実現され得る。技法がソフトウェアにおいて部分的に実現されるとき、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、1つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行してこの開示の技法を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、それらのいずれかが、それぞれのデバイスにおいて組み合わせられたエンコーダ／デコーダ(コーデック)の一部として統合されてもよい。ビデオエンコーダ20および／またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および／または携帯電話のようなワイヤレス通信デバイスを備え得る。
図2は、ビデオコーディング技法を実行し得るビデオエンコーダ20の例を例示するブロック図である。ビデオエンコーダ20は、ビデオスライス内でビデオブロックのイントラおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオにおける空間冗長性を減らし、または除去するために、空間予測に依存する。インターコーディングは、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオにおける時間冗長性を減らし、または除去するために、時間予測に依存する。イントラモード(Iモード)は、いくつかの空間を基にしたコーディングモードのいずれかを指し得る。単方向(単予測としても知られる)予測(Pモード)または双予測(bi-prediction)(双予測(bi prediction)としても知られる)(Bモード)のようなインターモードは、いくつかの時間を基にしたコーディングモードのいずれかを指し得る。
図2に表されるように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内で現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40、参照フレームメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピーコーディングユニット56を含む。そして、モード選択ユニット40は、動き補償ユニット44、動き推定ユニット42、イントラ予測(intra-prediction)(イントラ予測(intra prediction)としても知られる)ユニット46、および区分ユニット48を含む。ビデオブロック再構築のために、ビデオエンコーダ20は、逆量子化ユニット58、逆変換ユニット60、および加算器62も含む。ブロック境界をフィルタリングして再構築されたビデオからブロック状アーティファクトを除去するために、デブロッキングフィルタ(図2に表されていない)も含まれ得る。望まれる場合、デブロッキングフィルタは典型的に、加算器62の出力をフィルタリングする。追加のフィルタ(ループ内またはループ後)も、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは簡潔さのために表されていないが、望まれる場合、加算器50の出力を(ループ内フィルタとして)フィルタリングし得る。
符号化プロセスの間に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックへと分割され得る。動き推定ユニット42および動き補償ユニット44は、時間予測を提供するために、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対して、受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は代替的に、空間予測を提供するために、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の隣接ブロックに対して、受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータの各ブロックのための適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
その上、区分ユニット48は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックへと区分し得る。たとえば、区分ユニット48は最初に、フレームまたはスライスを最大コーディングユニット(LCU)へと区分し、レート歪み分析(たとえば、レート歪み最適化)に基づいて、LCUの各々をサブコーディングユニット(sub-CU)へと区分し得る。モード選択ユニット40はさらに、LCUのサブCUへの区分を示す四分木データ構造を作り出し得る。四分木のリーフノードCUは、1つまたは複数の予測ユニット(PU)および1つまたは複数の変換ユニット(TU)を含み得る。TUは、空間ブロック変換および量子化のための係数を含む。すなわち、TUは、残差値を変換係数へと変換し、または変換係数を残差値へと変換し戻すために適用されることが可能である空間変換である。
本開示は、HEVCの文脈におけるCU、PU、またはTUのいずれか、または他の規格の文脈における類似のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそのサブブロック)を指すために、用語「ブロック」を使用する。CUは、コーディングノード、PU、およびコーディングノードと関連付けられたTUを含む。CUのサイズは、コーディングノードのサイズに対応し、形状において正方形である。CUのサイズは、8×8ピクセルから、最大64×64ピクセル以上を有するツリーブロックのサイズにまで及び得る。各CUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。CUと関連付けられるシンタックスデータは、たとえば、CUの1つまたは複数のPUへの区分を記述し得る。区分モードは、CUがスキップまたはダイレクトモードで符号化されるか、イントラ予測モードで符号化されるか、またはインター予測(inter-prediction)(インター予測(inter prediction)としても知られる)モードで符号化されるかの間で異なり得る。PUは、形状において非正方形となるように区分され得る。CUと関連付けられるシンタックスデータはまた、たとえば、四分木に従ったCUの1つまたは複数のTUへの区分を記述し得る。TUは、形状において正方形または非正方形(たとえば、長方形)であることが可能である。
モード選択ユニット40は、たとえばエラー結果に基づいて、コーディングモードのうちの1つ、イントラまたはインターを選択することが可能であり、結果としてのイントラまたはインターコーディングされたブロックを、残差ブロックデータを生成するために加算器50に、参照フレームとしての使用のために符号化されたブロックを再構築するために加算器62に、提供する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報のようなシンタックス要素を、エントロピーコーディングユニット56に提供する。
動き推定ユニット42および動き補償ユニット44は、高度に統合され得るが、概念的な目的で別々に例示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム(または他のコーディングされたユニット)内でコーディングされている現在のブロックに対する参照フレーム(または他のコーディングされたユニット)内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUのずれを示し得る。予測ブロックは、ピクセル差分に関して、コーディングされるべきブロックと密接に一致することが見いだされるブロックであり、これは、絶対値差分和(SAD)、二乗差分和(SSD)、または他の差分尺度によって決定され得る。いくつかの例では、ビデオエンコーダ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は、深度モデリングモード(DMM)を使用して、深度マップの深度ブロックをコーディングするように構成され得る。モード選択ユニット40は、たとえばレート歪み最適化(RDO)を使用して、利用可能なDMMモードがイントラ予測モードおよび他のDMMモードより良いコーディング結果を作り出すかどうかを決定し得る。深度マップに対応するテクスチャ画像についてのデータは、参照フレームメモリ64に記憶され得る。動き推定ユニット42および動き補償ユニット44は、また、深度マップの深度ブロックをインター予測するように構成され得る。
ブロックのためのイントラ予測モード(たとえば、従来のイントラ予測モードまたはDMMモードのうちの1つ)を選択した後、イントラ予測ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供し得る。エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブル(符号語マッピングテーブルとも呼ばれる)を含み得る、送信されるビットストリーム構成データに、様々なブロックのための符号化コンテキストの定義、最も可能性の高いイントラ予測モード、イントラ予測モードインデックステーブル、およびコンテキストの各々について使用すべき修正されたイントラ予測モードインデックステーブルの指示を含め得る。
ビデオエンコーダ20は、コーディングされる元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表現する。
変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似の変換のような変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを作り出す。変換処理ユニット52は、DCTに概念的に類似する他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も使用されることが可能である。
変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを作り出す。変換は、ピクセル値領域から周波数領域のような変換領域に残差情報を変換し得る。変換処理ユニット52は、結果としての変換係数を量子化ユニット54に送信し得る。量子化ユニット54は、変換係数を量子化してビットレートをさらに減らす。量子化プロセスは、係数のいくつかまたはすべてと関連付けられるビット深度を減らし得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は次いで、量子化された変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56は走査を実行し得る。
量子化に続いて、エントロピーコーディングユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキスト適応可変長コーディング(CALVC)、コンテキスト適応バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストを基にしたエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、符号化されたビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信され、または後の送信または取り出しのためにアーカイブされ得る。
逆量子化ユニット58および逆変換ユニット60は、逆量子化および逆変換をそれぞれ適用し、たとえば参照ブロックとしての後の使用のために、ピクセル領域において残差ブロックを再構築する。動き補償ユニット44は、参照フレームメモリ64のフレームのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、1つまたは複数の補間フィルタを再構築された残差ブロックに適用して、動き推定における使用のために整数より下のピクセル値を計算し得る。加算器62は、再構築された残差ブロックを、動き補償ユニット44によって作り出される動き補償された予測ブロックに加算して、参照フレームメモリ64における記憶のために再構築されたビデオブロックを作り出す。再構築されたビデオブロックは、後続のビデオフレームの中のブロックをインターコーディングするために、参照ブロックとして動き推定ユニット42および動き補償ユニット44によって使用され得る。
図3は、ビデオコーディング技法を実行し得るビデオデコーダ30の例を例示するブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレームメモリ82、および加算器80を含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明された符号化パスと全般的に逆の復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得るが、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
復号プロセスの間、ビデオデコーダ30は、符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表現する符号化されたビデオビットストリームをビデオエンコーダ20から受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化された係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成する。エントロピー復号ユニット70は、動きベクトルおよび他のシンタックス要素を動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。
ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードおよび現在のフレームまたはピクチャの以前に復号されたブロックからのデータに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた(たとえば、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、動きベクトルおよびエントロピー復号ユニット70から受信された他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを作り出す。予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから作り出され得る。ビデオデコーダ30は、参照フレームメモリ82に記憶された参照ピクチャに基づいて、デフォルト構築技法を使用して、参照フレームリスト、リスト0およびリスト1を構築し得る。
動き補償ユニット72は、動きベクトルおよび他のシンタックス要素を解析することによって現在のビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して復号されている現在のビデオブロックのための予測ブロックを作り出す。たとえば、動き補償ユニット72は、受信されたシンタックス要素のいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライスのための参照ピクチャリストのうちの1つまたは複数のための構築情報、スライスの各々のインター符号化されたビデオブロックのための動きベクトル、スライスの各々のインターコーディングされたビデオブロックのためのインター予測ステータス、および現在のビデオスライスの中のビデオブロックを復号するための他の情報を決定する。
動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、ビデオブロックの符号化の間にビデオエンコーダ20によって使用されるような補間フィルタを使用して、参照ブロックの整数より下のピクセルのための補間された値を計算し得る。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用される補間フィルタを決定し、その補間フィルタを使用して予測ブロックを作り出し得る。
深度マップに対応するテクスチャ画像のためのデータは、参照フレームメモリ82に記憶され得る。動き補償ユニット72は、また、深度マップの深度ブロックをインター予測するように構成され得る。
画像およびビデオ圧縮は急速な成長を経験しており、様々なコーディング規格に導いている。そのようなビデオコーディング規格は、ITU-T H.261、国際標準化機構／国際電気標準会議(International Organization for Standardization/International Electrotechnical Commission, ISO/IEC) MPEG-1 Part 2、ITU-T H.262またはISO/IEC MPEG-2 Part 2、ITU-T H.263、ISO/IEC MPEG-4 Part 2、ITU-T H.264またはISO/IEC MPEG-4 Part 10としても知られるアドバンスド・ビデオ・コーディング(Advanced Video Coding, AVC)、およびITU-T H.265またはMPEG-H Part 2としても知られる高効率ビデオコーディング(High Efficiency Video Coding, HEVC)を含む。AVCは、Scalable Video Coding(SVC)、Multiview Video Coding(MVC)およびMultiview Video Coding plus Depth(MVC+D)、ならびに3D AVC(3D-AVC)のような拡張を含む。HEVCは、Scalable HEVC(SHVC)、Multiview HEVC(MV-HEVC)、および3D HEVC(3D-HEVC)のような拡張を含む。ITU-TおよびISO/IECのjoint video experts team(JVET)により開発されている、Versatile Video Coding(VVC)と名付けられた新しいビデオコーディング規格もある。VVC規格はいくつかのワーキングドラフトを有するが、特にVVCの1つのワーキングドラフト(WD)、すなわち、B. Bross、J. Chen、およびS. Liu、「Versatile Video Coding (Draft 4)」、JVET-M1001、第13回JVET会合、2019年1月(VVC Draft 4)がここで参照される。
ビデオコーディングを実行するとき、ビデオはフレームへと分離される。フレームはピクセルのブロックへと区分される。コーディング木ユニット(CTU)または画像ブロックと呼ばれ得る各ピクセルブロックは次いで、イントラ予測および／またはインター予測によって圧縮される。イントラ予測は、各画像ブロックをフレームの中の1つまたは複数の参照サンプルと照合する。イントラ予測モードは次いで、画像ブロックと参照サンプルの間の関係を示すために符号化される。符号化されたイントラ予測モードは、画像ピクセルより少ない空間を占める。インター予測は、フレーム間で照合される画像ブロックについて類似のやり方で動作する。
区分システムは、画像ブロックをサブブロックへと分割するように構成される。たとえば、様々な分割モードを利用する木構造が、ノード(たとえば、ブロック)を子ノード(たとえば、サブブロック)へと分割するために利用されることが可能である。異なる分割モードが、異なる区分を取得するために利用されることが可能である。さらに、分割モードはまた、ノードをさらに細分するために再帰的に適用されることが可能である。
図4A～Eは、様々な区分タイプのうちの1つに従うブロック400(たとえば、CTU)をまとめて例示する。図4Aのブロック400は、4つのサブブロック402へと四分木(QT)区分された(分割された、としても知られる)。図4B～Cのブロック400は、2つのサブブロック402へと二分木(BT)区分された。二分木分割について、2つの分割タイプがある。図4Bは垂直二分木区分を例示し、図4Cは水平二分木区分を例示する。四分木および二分木以外の木タイプがサポートされる。たとえば、垂直中心側三分木(TT)区分が図4Dに表され、水平中心側TT区分が図4Eに表される。TT区分は、三分木区分または中心側TT区分とも呼ばれ得る。図4D～4Eにおいて、ブロック400は3つのサブブロック402へと分割される。最小の許容される四分木リーフノードサイズが到達されるまで、ブロック400を分割するために、区分プロセスが繰り返され得る。
上で説明されたQT-BTTTコーディング構造(四分木プラス多分木(QT-MTT)としても知られる)が、ルートノードを複数のリーフノードへと区分するために使用され得る。まず、ルートノードは、1つまたは複数の四分木リーフノードへと四分木区分することのみによって再帰的に区分されてもよく、四分木リーフノードはさらに、コーディング木のリーフノードへと二分木区分することまたは三分木区分することのいずれかを使用して分割されてもよい。このコーディング木構造は、X. Li、H.-C. Chuang、J. Chen、M. Karczewicz、L. Zhang、X. Zhao、A. Said、「Multi-Type-Tree」、JVET-D0117、第4回JVET会合(中国、成都)、2016年10月において説明されている。
コーディング木ノード(たとえば、CTU)は、四分木区分(図4A内のような)、垂直二分木区分(図4B内のような)、水平二分木区分(図4C内のような)、垂直三分木区分(図4D内のような)、および水平三分木区分(図4E内のような)によって分割されることが可能である。コーディング木のリーフノードはしばしば、コーディングユニット(CU)と呼ばれる。コーディング木ノードは、変換木ノード(TTN)と関連付けられ得る。TTNは、コーディング木によってCTUから区分された領域である。変換木ノードの幅または高さが最大TUサイズより大きいとき、変換木ノードは、より小さい子変換木ノードへと黙示的に区分される。最大TUは、TUがビデオシーケンスにおいて利用することができる最大の寸法である。変換木のリーフノードはしばしば、変換ユニット(TU)と呼ばれる。
VVCドラフト4において、最大コーディング木ユニット(CTU)サイズは128×128であり、最大TUサイズ(maxTrSizeと表記される)は64×64として固定される。最大TUサイズより大きい幅(tbWidth)または高さ(tbHeight)を有する変換木ノードは、min(tbWidth, maxTrSize)に等しい幅およびmin(tbHeight, maxTrSize)に等しい高さを有する複数のTUへと区分され、min(a, b)はaとbの間の最小値である。VVCドラフト4におけるTU区分は次の通りである。
変換木ノードの幅および高さ(tbWidthおよびtbHeightと表記される)の両方がmaxTrSizeより大きいとき、幅がtbWidth/2に等しく高さがtbHeight/2に等しい4つの等しいサイズの子変換木ノードへと変換木ノードを区分するために、四分木分割が使用される。
変換ノードの幅がmaxTrSizeより大きいが、変換木ノードの高さがmaxTrSizeより大きくないとき、tbWidth/2に等しい幅およびtbHeightに等しい高さを有する2つの等しいサイズの子木ノードへと変換木ノードを区分するために、垂直二分木分割が使用される。
変換ノードの高さがmaxTrSizeより大きいが、変換木ノードの幅がmaxTrSizeより大きくないとき、tbWidthに等しい幅およびtbHeight/2に等しい高さを有する2つの等しいサイズの子木ノードへと変換木ノードを区分するために、水平二分木分割が使用される。
maxTrSizeの値は、64の固定された値であるのではなく、シーケンスパラメータセット(SPS)においてシグナリングされてもよい。たとえば、HEVCでは、maxTrSizeは、2つのシンタックス要素、すなわち、log2_min_transform_block_size_minus2およびlog2_diff_max_min_transform_block_sizeを介してSPSにおいてシグナリングされる。可能なmaxTrSizeの値は、64、32、および16であり得る。
ハードウェアのビデオコーデックパイプライン設計では、ブロックはしばしばS×Sブロックを基にしたパイプライン構造に配置され、S=64である。コーディング木ユニットは、1つまたは複数のS×Sの非重複領域に対応し、各領域がパイプラインブロックと名付けられる。TU処理順序は、S×Sパイプライン構造に違反すべきではない。すなわち、1つのS×Sパイプラインブロックの中のすべてのTUが、次のS×Sパイプラインブロックの中のTUが処理される前に処理されるべきである。
128×64の変換木ノードおよび32のmaxTrSizeの場合、128×64の変換木ノードは、2つの64×64のパイプラインブロックに対応する。VVCドラフト4におけるTU区分方法を使用して、128×64の変換木ノードはまず、四分木分割によって4つの64×32の変換木ノードへと分割され、各々の64×32の変換木ノードはさらに、垂直二分木分割によって32×32の変換木ノードへと分割される。
図5は、S×Sパイプライン構造に違反する一例の変換ユニット区分技法500を例示する。図5の例は、幅W=128および高さH=64を有するTTN502を描写する。幅および高さは、ルマサンプルの数で測られる。TTN502は、第1の64×64パイプラインブロック504および第2の64×64パイプラインブロック506へと区分または分割されており、これらは、TTN502の子TTN508、510、512、514と呼ばれ得る。子TTN508、510、512、514は、64×32のサイズを有する。第1および第2の64×64パイプラインブロック504、506の各々は、0から7とラベル付けされた32×32のTUへと区分または分割されている。図5の例はある寸法を提供するが、実際の応用では他の寸法が直面され得ることをこの技術分野の当業者は認識するだろう。
図5に表されるように、128×64のTTNにおけるTU処理順序が(矢印により)例示され、TUNはTUN-1の後で処理される(N=1,...,7)。図5では、TU0、TU1、TU4、およびTU5は第1の64×64パイプラインブロック504の中にあり、TU2、TU3、TU6、およびTU7は第2の64×64パイプラインブロック506の中にある。表されるように、第2の64×64パイプラインブロック506の中のTU2は、第1の64×64パイプラインブロック504の中のTU1の直後に処理される。しかしながら、第2の64×64パイプラインブロック506の中のTU2が処理されるとき、第1のパイプラインブロック504の中のTUのすべてが処理されているとは限らない。すなわち、第2の64×64のパイプラインブロック506の中のTU2が処理されるとき、第1の64×64のパイプラインブロック504の中のTU4およびTU5はまだ処理されていない。これは、TU2が適切に処理されるためにTU4およびTU5を参照する必要があり得るので、問題である。したがって、VVCドラフト4におけるTU区分技法500は、64×64パイプライン構造に違反する。
S×Sパイプライン構造の完全性を維持する改善されたTU区分方法が、ここで開示される。以下でより十分に説明されるように、方法は、長方形の変換木ノード(TTN)が、そのTTNの最大TUサイズが第1のTTN寸法と第2のTTN寸法の両方より小さいとき、垂直二分木分割または水平二分木分割のいずれかを使用して最初に区分される技法を提供する。これは、子TTN(たとえば、正方形の子TTN)を生成する。第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、子TTNは、変換ユニット(TU)を生成するために、四分木分割を使用して区分される。そうでなければ、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズと同じであるとき、子TTNは最初に分割されたTUである。このやり方でTTNを区分することによって(たとえば、任意の四分木分割の前のTTNの垂直または水平二分木分割)、多用途ビデオコーディング(versatile video coding, VVC)規格において使用されるパイプラインブロック構造は、違反されない。したがって、ビデオコーディングにおけるコーダ／デコーダ(「コーデック」としても知られる)が、現在のコーデックに対して改善される(たとえば、S×Sパイプライン構造またはプロセスの完全性が維持される)。現実的な事項として、改善されたビデオコーディングプロセスは、コーデックにおけるエラーまたは障害をなくすことが可能であり、これは、ビデオが送信され、受信され、および／または見られるとき、ユーザにより良いユーザ体験をもたらす。
図6は、S×Sパイプライン構造の完全性を維持するTTN602のための変換ユニット区分技法600の実施形態を例示する。図6の実施形態では、VVCドラフト4のQT-MTTコーディング木構造(図4を参照されたい)が利用され、CTUサイズは128×128であり、最大TUサイズはTTN602の幅と高さの両方(たとえば、辺)より小さい。ある実施形態では、最大TUサイズはビットストリームにおいて(たとえば、SPSにおいて)シグナリングされる。
TTN602が幅W=128および高さH=64を有し、最大TUサイズが64より小さい(たとえば、32)とき、TTN602は最初に、各々64×64のサイズを有する2つの子TTN608、610を生成するために、垂直BT分割を使用して区分される。これは、VVCドラフト4において指定されるように64×32のサイズを有する4つの子TTN508、510、512、514を生成するQT分割を使用してTTN502が最初に区分される図5の変換ユニット区分技法500とは対照的である。
図6に表される最初の垂直BT分割の後、各子TTN608、610はさらに、子TTN608および子TTN610が最大TUサイズより大きいとき、TU(たとえば、0から7とラベル付けされたTU)を生成するために、QT分割を使用して区分される。最大TUサイズに対する子TTN608、610のサイズに依存して、最大TUサイズが到達される前に1回より多くのQT分割が実行され得る。子TTN608および子TTN610が最大TUサイズ以下であるとき、子TTN608、610はTUに対応する。すなわち、子TTN608、610はTUであると決定される。図6では、32×32のTUが0から7とラベル付けされる。
図6の変換ユニット区分技法600を使用して、S×Sパイプライン構造の完全性が(矢印によって表されるように)維持される。すなわち、第2の64×64のパイプラインブロック606の中のTUのいずれよりも前に、第1の64×64のパイプラインブロック604の中のTUのすべてが処理される。
特に、図6の変換ユニット区分技法600は、第2のTTN寸法(たとえば、64)とは異なる第1のTTN寸法(たとえば、128)を有する長方形TTN(たとえば、TTN602)の区分のためによく適している。表されるように、変換ユニット区分技法600は、TUの最大TUサイズ(たとえば、32)が第1のTTN寸法および第2のTTN寸法より小さいとき、第2の子TTN寸法(たとえば、64)に等しい第1の子TTN寸法(たとえば、64)を有する子TTN(たとえば、子TTN608、610)を生成することが可能である。
実際の応用では、TTN602および子TTN608、610は、図6に表されるもの以外の寸法を有し得る。加えて、実際の応用では、最大TUサイズは32とは異なり得る。ある実施形態では、TTN602、子TTN608、610、および最大TUサイズは、ルマサンプル単位で測られる。
ある実施形態では、第1のTTN寸法が2N個のルマサンプルであり、第2のTTN寸法がN個のルマサンプルであり、かつ最大TUサイズがN/2個のルマサンプルであるとき、TTN602は図6に表される垂直BT分割を使用して区分される。ある実施形態では、N=64である。しかしながら、実際の応用では、他の寸法またはサイズが使用され得る。
ある実施形態では、TTN(たとえば、TTN602)の中のすべてのTU(たとえば、0～7とラベル付けされたTU)のTTN深度は1に設定される。ある実施形態では、TTNの中のすべてのTUのTTN深度は、TUを取得するために必要とされる分割の数に従って設定される。
VVCドラフト4におけるtransform_tree()シンタックステーブルに基づく、修正されたtransform_tree()シンタックステーブルが、以下で表1において提供される。このテーブルにおいて、改善されたTU区分方法は、斜体の部分(すなわち、4行から21行)に対応する。表1において、tbWidthおよびtbHeightは変換木ノード(たとえば、TTN602)の幅および高さを表記し、MaxTbSizeYは最大TUサイズを表記する。VVCドラフト4における黙示のTU区分方法が8から20行に見いだされる。
128×64の変換木ノード(たとえば、TTN602)および64より小さいmaxTbSizeY(たとえば、32)について、条件「tbWidth>64&&tbHeight == 64&&MaxTbSizeY<64」は真である。したがって、変換木ノードはさらに、垂直二分木分割によって、2つの64×64の変換木ノードへと分割される。2つの64×64の子変換木ノードの各々がさらに、四分木分割を用いて変換ユニットへと分割される。
条件「tbWidth>64&&tbHeight == 64&&MaxTbSizeY<64」が変換木ノードについて偽であるとき、VVCドラフト4におけるTU区分方法が使用される。
図7は、S×Sパイプライン構造の完全性を維持するTTN702のための変換ユニット区分技法700の実施形態を例示する。図7の実施形態では、VVCドラフト4のQT-MTTコーディング木構造(図4を参照されたい)が利用され、CTUサイズは128×128であり、最大TUサイズはTTN702の両方の寸法(たとえば、辺)より小さい。ある実施形態では、最大TUサイズはビットストリームにおいて(たとえば、SPSにおいて)シグナリングされる。
TTN702が幅W=64および高さH=128を有し、最大TUサイズが64(たとえば、32)より小さいとき、TTN702は最初に、各々64×64のサイズを有する2つの子TTN708、710を生成するために、水平BT分割を使用して区分される。これは、VVCドラフト4において指定されるように64×32のサイズを有する4つの子TTN508、510、512、514を生成するQT分割を使用してTTN502が最初に区分される図5の変換ユニット区分技法500とは対照的である。
図7に表される最初の水平BT分割の後、各子TTN708、710はさらに、子TTN708および子TTN710が最大TUサイズより大きいとき、TU(たとえば、0から7とラベル付けされたTU)を生成するために、QT分割を使用して区分される。最大TUサイズに対する子TTN708、710のサイズに依存して、最大TUサイズが到達される前に1回より多くのQT分割が実行され得る。子TTN708および子TTN710が最大TUサイズ以下であるとき、子TTN708、710はTUに対応する。すなわち、子TTN708、710はTUであると決定される。図7では、32×32のTUが0から7とラベル付けされる。
図7の変換ユニット区分技法700を使用して、S×Sパイプライン構造の完全性が(矢印によって表されるように)維持される。すなわち、第2の64×64のパイプラインブロック706の中のTUのいずれよりも前に、第1の64×64のパイプラインブロック704の中のTUのすべてが処理される。
VVCドラフト4におけるtransform_tree()シンタックステーブルに基づく、修正されたtransform_tree()シンタックステーブルが、以下で表2において提供される。このテーブルにおいて、改善されたTU区分方法は、斜体の部分(すなわち、4行から24行)に対応する。表2において、tbWidthおよびtbHeightは変換木ノード(たとえば、TTN702)の幅および高さを表記し、MaxTbSizeYは最大TUサイズを表記する。
64×128の変換木ノード(たとえば、TTN702)および64より小さいmaxTbSizeY(たとえば、32)について、条件「tbWidth == 64&&tbHeight>64&&MaxTbSizeY<64」は真である。したがって、変換木ノードはさらに、水平二分木分割によって、2つの64×64の変換木ノードへと分割される。VVCドラフト4と同じように、2つの64×64の子変換木ノードの各々がさらに、四分木分割を用いて変換ユニットへと分割される。
VVCドラフト4におけるtransform_tree()シンタックステーブルに基づく、修正されたtransform_tree()シンタックステーブルが、表3において提供される。このテーブルは、表2のシンタックステーブルを使用するのと等価なTU区分の結果を与える。これは、MaxTrSizeが64であるとき、VVCにおけるTU区分方法が、また、128×64の変換木ノードまたは64×128の変換木ノードを64×64の子ノードに分割するからである。したがって、計算の複雑さを減らすために、表2の条件チェック「MaxTbSizeY<64」が除去される。
同様に、表1の条件チェック「MaxTbSize<64」も除去されることが可能であり、表1を使用するのと同じTUの結果を与える。
VVCドラフト4におけるtransform_tree()シンタックステーブルに基づいて修正されるtransform_tree()シンタックステーブルが表4において提供され、これは表2のシンタックステーブルを使用するのと等価なTU区分の結果を与える。
図8は、ビデオデコーダ(たとえば、ビデオデコーダ30)によって実行されるコーディングされたビデオビットストリームを復号する方法800の実施形態である。方法800は、復号されたビットストリームがビデオエンコーダ(たとえば、ビデオエンコーダ20)から直接または間接に受信された後で実行され得る。S×Sパイプライン構造またはプロセスの完全性が維持されるので、方法800は復号プロセスを改善する。したがって、現実的な事項として、コーデックの性能が改善され、これはより良いユーザ体験に導く。
ブロック802において、変換木ノード(たとえば、TTN602)は、第1のTTN寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用して区分される。ある実施形態では、TTNの区分は、第2の子TTN寸法に等しい第1の子TTN寸法を有する生成子TTNを生成する。ある実施形態では、方法はさらに、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、四分木分割を使用して子TTNを区分してTUを生成するステップと、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズ以下であるとき、子TTNがTUであると決定するステップとを備える。
ある実施形態では、垂直二分木分割は、次のシンタックス、すなわち、verSplitFirst = (tbWidth>MaxTbSizeY&&tbWidth>tbHeight) ? 1 : 0に従って実行される。
ある実施形態では、第1のTTN寸法が2N個のルマサンプルであり、第2のTTN寸法がN個のルマサンプルであり、かつ最大TUサイズがN/2個のルマサンプルであるとき、TTNは垂直二分木分割を使用して区分される。ある実施形態では、N=64個のルマサンプルである。
ある実施形態では、第1のTTN寸法、第2のTTN寸法、第1の子TTN寸法、および第2の子TTN寸法は、ルマサンプルの数で測られる。
ブロック804において、TTNが区分された後の残差を生成するために、変換係数に変換ユニット(TU)。ある実施形態では、TTNの中のすべてのTUのTTN深度は1に設定される。ある実施形態では、TTNの中のすべてのTUのTTN深度は、TUを取得するために必要とされる分割の数に従って設定される。
ブロック806において、再構築されたブロックが残差に基づいて生成される。
図9は、ビデオエンコーダ(たとえば、ビデオエンコーダ20)によって実行されるビデオビットストリームを符号化する方法900の実施形態である。方法900は、ピクチャ(たとえば、ビデオからの)がビデオビットストリームへと符号化され、次いでビデオデコーダ(たとえば、ビデオデコーダ30)に向けて送信されるべきであるときに実行され得る。S×Sパイプライン構造またはプロセスの完全性が維持されるので、方法900は符号化プロセスを改善する。したがって、現実的な事項として、コーデックの性能が改善され、これはより良いユーザ体験に導く。
ブロック902において、変換木ノード(たとえば、TTN602)は、第1のTTN寸法がTTNの最大変換ユニット(TU)サイズより大きいとき、かつ第1のTTN寸法が第2のTTN寸法より大きいとき、垂直二分木分割を使用して区分される。ある実施形態では、TTNの区分は、第2の子TTN寸法に等しい第1の子TTN寸法を有する生成子TTNを生成する。ある実施形態では、方法はさらに、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズより大きいとき、四分木分割を使用して子TTNを区分してTUを生成するステップと、第1の子TTN寸法および第2の子TTN寸法が最大TUサイズ以下であるとき、子TTNがTUであると決定するステップとを備える。
ある実施形態では、垂直二分木分割は、次のシンタックス、すなわち、verSplitFirst = (tbWidth>MaxTbSizeY&&tbWidth>tbHeight) ? 1 : 0に従って実行される。
ある実施形態では、第1のTTN寸法が2N個のルマサンプルであり、第2のTTN寸法がN個のルマサンプルであり、かつ最大TUサイズがN/2個のルマサンプルであるとき、TTNは垂直二分木分割を使用して区分される。ある実施形態では、N=64個のルマサンプルである。
ある実施形態では、第1のTTN寸法、第2のTTN寸法、第1の子TTN寸法、および第2の子TTN寸法は、ルマサンプルの数で測られる。
ブロック904において、TTNが区分された後の変換係数を生成するために、残差に変換ユニット(TU)が適用される。ある実施形態では、TTNの中のすべてのTUのTTN深度は1に設定される。ある実施形態では、TTNの中のすべてのTUのTTN深度は、TUを取得するために必要とされる分割の数に従って設定される。
ブロック906において、変換係数がビットストリームへと符号化される。ブロック908において、ビットストリームがビデオデコーダに向けた送信のために記憶される。ビデオビットストリームは、コーディングされたビデオビットストリームまたは符号化されたビデオビットストリームとも呼ばれ得る。ビデオデコーダによっていったん受信されると、符号化されたビデオビットストリームは、電子デバイス(たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のディスプレイまたはスクリーン上でのユーザへの表示のための画像を生成し、または作り出すために、復号され得る(たとえば、上で説明されたように)。
図10は、開示のある実施形態によるビデオコーディングデバイス1000(たとえば、ビデオエンコーダ20またはビデオデコーダ30)の概略図である。ビデオコーディングデバイス1000は、ここで説明されるような開示される実施形態を実現するために適している。ビデオコーディングデバイス1000は、データを受信するための入口ポート1010および受信機ユニット(Rx)1020、データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット(CPU)1030、データを送信するための送信機ユニット(Tx)1040および出口ポート1050、およびデータを記憶するためのメモリ1060を備える。ビデオコーディングデバイス1000はまた、光または電気信号の出口または入口のための、入口ポート1010、受信機ユニット1020、送信機ユニット1040、および出口ポート1050に結合された光・電気(OE)構成要素および電気・光(EO)構成要素を備え得る。
プロセッサ1030は、ハードウェアおよびソフトウェアによって実現される。プロセッサ1030は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサのような)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号プロセッサ(DSP)として実現され得る。プロセッサ1030は、入口ポート1010、受信機ユニット1020、送信機ユニット1040、出口ポート1050、およびメモリ1060と通信する。プロセッサ1030はコーディングモジュール1070を備える。コーディングモジュール1070は、上で説明された開示された実施形態を実現する。たとえば、コーディングモジュール1070は、様々なコーデック機能を実行し、処理し、準備し、または提供する。したがって、コーディングモジュール1070を含むことは、ビデオコーディングデバイス1000の機能へのかなりの改善を提供し、異なる状態へのビデオコーディングデバイス1000の変換をもたらす。代替的に、コーディングモジュール1070は、メモリ1060に記憶されている命令として実現され、プロセッサ1030によって実行される。
ビデオコーディングデバイス1000はまた、ユーザへのおよびユーザからのデータを通信するために入力および／または出力(I/O)デバイス1080を含み得る。I/Oデバイス1080は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカーなどのような出力デバイスを含み得る。I/Oデバイス1080はまた、キーボード、マウス、トラックボールなどのような入力デバイス、および／またはそのような出力デバイスと相互作用するための対応するインターフェースを含み得る。
メモリ1060は、1つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを備え、プログラムが実行のために選択されるときにそのようなプログラムを記憶するために、およびプログラム実行の間に読み取られる命令とデータを記憶するために、オーバーフローデータ記憶デバイスとして使用され得る。メモリ1060は、揮発性および／または不揮発性であってもよく、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、三値連想メモリ(TCAM)、および／またはスタティック・ランダムアクセスメモリ(SRAM)であり得る。
図11は、コーディングのための手段1100の実施形態の概略図である。実施形態では、コーディングのための手段1100は、ビデオコーディングデバイス1102(たとえば、ビデオエンコーダ20またはビデオデコーダ30)において実現される。ビデオコーディングデバイス1102は受信手段1101を含む。受信手段1101は、符号化すべきピクチャを受信し、または復号すべきビットストリームを受信するように構成される。ビデオコーディングデバイス1102は、受信手段1101に結合された送信手段1107を含む。送信手段1107は、ビットストリームをデコーダに送信し、または、復号された画像を表示手段(たとえば、I/Oデバイス1080のうちの1つ)に送信するように構成される。
ビデオコーディングデバイス1102は記憶手段1103を含む。記憶手段1103は、受信手段1101または送信手段1107のうちの少なくとも1つに結合される。記憶手段1103は命令を記憶するように構成される。ビデオコーディングデバイス1102は処理手段1105も含む。処理手段1105は記憶手段1103に結合される。処理手段1105は、ここで開示される方法を実行するために、記憶手段1103に記憶されている命令を実行するように構成される。
ここに記載される例示の方法のステップは、必ずしも説明される順序で実行されることは要求されないことも理解されるべきであり、そのような方法のステップの順序は、単に例示であると理解されるべきである。同様に、追加のステップがそのような方法に含まれてもよく、本開示の様々な実施形態と一貫する方法において、あるステップが省略され、または組み合わせられてもよい。
本開示においていくつかの実施形態が提供されたが、開示されるシステムおよび方法は、本開示の精神または範囲から逸脱することなく多くの他の具体的な形式で具現化され得ることが理解されるべきである。本例示は、例示的であって限定的でないとして考えられるべきであり、意図はここで与えられる詳細に限定されるべきでない。たとえば、別のシステムでは様々な要素または構成要素が組み合わせられ、または統合されてもよく、または、ある特徴が省略されてもよく、または実現されなくてもよい。
加えて、個別または別個として様々な実施形態において説明され例示される技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わせられ、または統合されてもよい。結合され、または直接に結合され、または互いに通信しているとして表されまたは論じられる他の項目は、電気的にでも、機械的にでも、またはそうでなくても、あるインターフェース、デバイス、または中間構成要素を通じて、間接に結合され、または通信してもよい。変更、置換、および変形の他の例がこの技術分野の当業者によって確認可能であり、ここで開示される精神および範囲から逸脱することなく行われることが可能である。
12 ソースデバイス
14 デスティネーションデバイス
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 参照フレームメモリ
400 ブロック
402 サブブロック
502 TTN
504 第1の64×64パイプラインブロック
506 第2の64×64パイプラインブロック
508 子TTN
510 子TTN
512 子TTN
514 子TTN
602 TTN
604 第1の64×64パイプラインブロック
606 第2の64×64パイプラインブロック
608 子TTN
610 子TTN
702 TTN
704 第1の64×64パイプラインブロック
706 第2の64×64パイプラインブロック
708 子TTN
710 子TTN
1010 入口ポート
1020 受信機ユニット
1030 プロセッサ
1040 送信機ユニット
1050 出口ポート
1060 メモリ
1070 コーディングモジュール
1080 I/Oデバイス
1101 受信手段
1102 ビデオコーディングデバイス
1103 記憶手段
1105 処理手段
1107 送信手段

Claims (14)

  1. ビデオデコーダによって実行される、コーディングされたビデオビットストリームを復号する方法であって、
    前記ビデオデコーダによって、変換木ノード(TTN)のサイズが64×128であり、かつ前記TTNの最大変換ユニット(TU)サイズが64よりも小さいとき、条件「tbWidth == 64 && tbHeight > 64 && MaxTbSizeY < 64」が真であると判定するステップと、
    前記ビデオデコーダによって、前記条件「tbWidth == 64 && tbHeight > 64 && MaxTbSizeY < 64」が真であるとき、水平二分木分割を使用して前記TTNを、サイズが64×64である2つの子TTNに区分するステップと、
    前記ビデオデコーダによって、TUを変換係数に適用して、前記TTNが区分された後の残差を生成するステップと、
    前記ビデオデコーダによって、前記残差に基づいて再構築されたブロックを生成するステップとを備える方法。
  2. 前記ビデオデコーダによって、四分木分割を使用して前記子TTNを区分して前記TUを生成するステップをさらに備える、請求項1に記載の方法。
  3. 前記TTNの中のすべてのTUのTTN深度が1に設定される、請求項1または2に記載の方法。
  4. 前記TTNの中のすべてのTUのTTN深度が、前記TUを取得するために必要とされる分割の数に従って設定される、請求項1または2に記載の方法。
  5. ビデオエンコーダによって実行される、ビデオビットストリームを符号化する方法であって、
    前記ビデオエンコーダによって、変換木ノード(TTN)のサイズが64×128であり、かつ前記TTNの最大変換ユニット(TU)サイズが64よりも小さいとき、条件「tbWidth == 64 && tbHeight > 64 && MaxTbSizeY < 64」が真であると判定するステップと、
    前記ビデオエンコーダによって、前記条件「tbWidth == 64 && tbHeight > 64 && MaxTbSizeY < 64」が真であるとき、水平二分木分割を使用して前記TTNを、サイズが64×64である2つの子TTNに区分するステップと、
    前記ビデオエンコーダによって、TUを残差に適用して、前記TTNが区分された後の変換係数を生成するステップと、
    前記ビデオエンコーダによって、前記変換係数をビットストリームへと符号化するステップと、
    前記ビデオエンコーダによって、ビデオデコーダに向けた送信のために前記ビットストリームを記憶するステップとを備える、方法。
  6. 前記ビデオデコーダによって、四分木分割を使用して前記子TTNを区分して前記TUを生成するステップをさらに備える、請求項5に記載の方法。
  7. 前記TTNの中のすべてのTUのTTN深度が1に設定される、請求項5または6に記載の方法。
  8. 前記TTNの中のすべてのTUのTTN深度が、前記TUを取得するために必要とされる分割の数に従って設定される、請求項5または6に記載の方法。
  9. 復号デバイスであって、
    コーディングされたビデオビットストリームを受信するように構成された受信機と、
    前記受信機に結合されたメモリであって、前記メモリが命令を記憶する、メモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、前記命令を実行して、前記復号デバイスに、請求項1から4のいずれか一項に記載の方法を実行させるように構成された、プロセッサとを備える復号デバイス。
  10. 符号化デバイスであって、
    命令を含むメモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、前記命令を実行して、前記符号化デバイスに、請求項5から8のいずれか一項に記載の方法を実行させるように構成された、プロセッサとを備える符号化デバイス。
  11. 符号化すべきピクチャを受信し、または復号すべきビットストリームを受信するように構成された受信機と、
    前記受信機に結合された送信機であって、前記送信機が、前記ビットストリームをデコーダに送信し、または復号された画像をディスプレイに送信するように構成された、送信機と、
    前記受信機または前記送信機のうちの少なくとも1つに結合されたメモリであって、前記メモリが命令を記憶するように構成された、メモリと、
    前記メモリに結合されたプロセッサであって、前記プロセッサが、前記メモリに記憶された前記命令を実行して、請求項1から4のいずれか一項および請求項5から8のいずれか一項に記載の方法を実行するように構成された、プロセッサとを備える、コーディング装置。
  12. 符号化すべきピクチャを受信し、または復号すべきビットストリームを受信するように構成された受信手段と、
    前記受信手段に結合された送信手段であって、前記送信手段が、前記ビットストリームを復号手段に送信し、または復号された画像を表示手段に送信するように構成された、送信手段と、
    前記受信手段または前記送信手段のうちの少なくとも1つに結合された記憶手段であって、前記記憶手段が命令を記憶するように構成された、記憶手段と、
    前記記憶手段に結合された処理手段であって、前記処理手段が、前記記憶手段に記憶された前記命令を実行して、請求項1から4のいずれか一項および請求項5から8のいずれか一項に記載の方法を実行するように構成された、処理手段とを備える、コーディング装置。
  13. コンピュータに、請求項1から8のいずれか一項に記載の方法を実行させるように構成された、コンピュータプログラム。
  14. プログラムを記憶したコンピュータ可読記憶媒体であって、前記プログラムが、コンピュータに、請求項1から8のいずれか一項に記載の方法を実行させる、コンピュータ可読記憶媒体。
JP2023078106A 2019-03-22 2023-05-10 ビデオコーディングのための変換ユニット区分方法 Active JP7477687B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962822533P 2019-03-22 2019-03-22
US62/822,533 2019-03-22
JP2021556814A JP7279189B2 (ja) 2019-03-22 2020-03-20 ビデオコーディングのための変換ユニット区分方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021556814A Division JP7279189B2 (ja) 2019-03-22 2020-03-20 ビデオコーディングのための変換ユニット区分方法

Publications (2)

Publication Number Publication Date
JP2023104953A JP2023104953A (ja) 2023-07-28
JP7477687B2 true JP7477687B2 (ja) 2024-05-01

Family

ID=72611743

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021556814A Active JP7279189B2 (ja) 2019-03-22 2020-03-20 ビデオコーディングのための変換ユニット区分方法
JP2023078106A Active JP7477687B2 (ja) 2019-03-22 2023-05-10 ビデオコーディングのための変換ユニット区分方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2021556814A Active JP7279189B2 (ja) 2019-03-22 2020-03-20 ビデオコーディングのための変換ユニット区分方法

Country Status (7)

Country Link
US (1) US20220014796A1 (ja)
EP (1) EP3915267A4 (ja)
JP (2) JP7279189B2 (ja)
KR (1) KR20210125085A (ja)
CN (7) CN117834869A (ja)
MX (1) MX2021011417A (ja)
WO (1) WO2020198061A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114938453B (zh) * 2022-07-19 2022-09-30 深流微智能科技(深圳)有限公司 视频编码方法、芯片、存储介质及计算机设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020197957A1 (en) 2019-03-22 2020-10-01 Tencent America LLC Method and apparatus for video coding

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9788019B2 (en) * 2011-03-09 2017-10-10 Hfi Innovation Inc. Method and apparatus of transform unit partition with reduced complexity
US8750634B2 (en) * 2011-05-05 2014-06-10 Mitsubishi Electric Research Laboratories, Inc. Method for coding pictures using hierarchical transform units
US8494290B2 (en) * 2011-05-05 2013-07-23 Mitsubishi Electric Research Laboratories, Inc. Method for coding pictures using hierarchical transform units
US20130136180A1 (en) * 2011-11-29 2013-05-30 Futurewei Technologies, Inc. Unified Partitioning Structures and Signaling Methods for High Efficiency Video Coding
US9088770B2 (en) * 2012-08-15 2015-07-21 Intel Corporation Size based transform unit context derivation
AU2012232992A1 (en) * 2012-09-28 2014-04-17 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding the transform units of a coding unit
EP2918078A4 (en) * 2012-11-08 2016-10-19 Canon Kk METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING TRANSFORMER UNITS OF AN ENCODER UNIT
JP2014204311A (ja) * 2013-04-05 2014-10-27 三菱電機株式会社 カラー画像符号化装置、カラー画像復号装置、カラー画像符号化方法及びカラー画像復号方法
WO2015135169A1 (en) * 2014-03-13 2015-09-17 Qualcomm Incorporated Constrained depth intra mode coding for 3d video coding
US10200719B2 (en) * 2015-11-25 2019-02-05 Qualcomm Incorporated Modification of transform coefficients for non-square transform units in video coding
US10212444B2 (en) * 2016-01-15 2019-02-19 Qualcomm Incorporated Multi-type-tree framework for video coding
CN108713320B (zh) * 2016-03-16 2022-05-17 寰发股份有限公司 视频编码中限制块尺寸的视频数据处理方法与装置
US10609423B2 (en) * 2016-09-07 2020-03-31 Qualcomm Incorporated Tree-type coding for video coding
CN113196780A (zh) * 2019-01-12 2021-07-30 韦勒斯标准与技术协会公司 使用多变换核处理视频信号的方法和设备

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020197957A1 (en) 2019-03-22 2020-10-01 Tencent America LLC Method and apparatus for video coding

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
Benjamin Bross, Jianle Chen, and Shan Liu，Versatile Video Coding (Draft 4)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-M1001 (version 7)，13th Meeting: Marrakech, MA，2019年03月17日，pp.49
Benjamin Bross, Jianle Chen, and Shan Liu，Versatile Video Coding (Draft 6)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-O2001 (version 14)，15th Meeting: Gothenburg, SE，2019年07月31日，p.73
Krit Panusopone, Limin Wang, and Xue Fang，Implicit Transform Unit Partitioning in HEVC，PCS 2013，IEEE，2013年，pp.213-216，javascript:void(0)
Ling Li, et al.，Maximum transform size signaling in HLS，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-N0227-v1，14th Meeting: Geneva, CH，2019年03月19日，pp.1-3
Xin Zhao, Xiang Li, and Shan Liu，CE6-related: Configurable max transform size in VVC，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-N0362，14th Meeting: Geneva, CH，2019年03月13日，pp.1-8

Also Published As

Publication number Publication date
CN113632494B (zh) 2023-12-08
CN114727104A (zh) 2022-07-08
CN117692640A (zh) 2024-03-12
KR20210125085A (ko) 2021-10-15
CN114727105A (zh) 2022-07-08
CN117834869A (zh) 2024-04-05
JP2023104953A (ja) 2023-07-28
CN117896535A (zh) 2024-04-16
CN114727104B (zh) 2023-03-24
US20220014796A1 (en) 2022-01-13
WO2020198061A1 (en) 2020-10-01
EP3915267A4 (en) 2022-08-03
CN113632494A (zh) 2021-11-09
MX2021011417A (es) 2021-10-13
JP7279189B2 (ja) 2023-05-22
EP3915267A1 (en) 2021-12-01
CN117793345A (zh) 2024-03-29
CN114727105B (zh) 2023-03-24
JP2022526770A (ja) 2022-05-26

Similar Documents

Publication Publication Date Title
US11019339B2 (en) Fractional quantization parameter offset in video compression
KR102288109B1 (ko) 비디오 압축에서의 양방향 예측
US10728548B2 (en) Processing reference samples used for intra-prediction of a picture block
JP2021530917A (ja) ビデオ符号器、ビデオ復号器、並びに対応する符号化及び復号化方法
KR102562209B1 (ko) 포인트 클라우드 코딩에서의 효율적인 패치 회전
US20190110052A1 (en) Bidirectional intra prediction
US11889079B2 (en) Constrained prediction mode for video coding
AU2019300691B2 (en) Luma intra mode signaling
JP7477687B2 (ja) ビデオコーディングのための変換ユニット区分方法
AU2023202658B2 (en) Boundary block partitioning in video coding
KR20220003101A (ko) 비디오 코딩에서 새로운 코딩된 비디오 시퀀스를 시작하는 픽처에 대한 이전 픽처의 출력

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230608

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240401

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240418

R150 Certificate of patent or registration of utility model

Ref document number: 7477687

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150