IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ テンセント・アメリカ・エルエルシーの特許一覧

特表2023-546963ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム
<>
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図1A
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図1B
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図2
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図3
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図4
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図5
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図6
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図7
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図8
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図9
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図10
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図11
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図12
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図13
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図14
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図15
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図16
  • 特表-ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム 図17
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-11-08
(54)【発明の名称】ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム
(51)【国際特許分類】
   H04N 19/132 20140101AFI20231031BHJP
   H04N 19/136 20140101ALI20231031BHJP
【FI】
H04N19/132
H04N19/136
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023525098
(86)(22)【出願日】2022-01-28
(85)【翻訳文提出日】2023-04-25
(86)【国際出願番号】 US2022014240
(87)【国際公開番号】W WO2023003596
(87)【国際公開日】2023-01-26
(31)【優先権主張番号】17/575,075
(32)【優先日】2022-01-13
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/224,046
(32)【優先日】2021-07-21
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】シン・ジャオ
(72)【発明者】
【氏名】マドゥー・ペリンガーサリー・クリシュナン
(72)【発明者】
【氏名】シャン・リュウ
【テーマコード(参考)】
5C159
【Fターム(参考)】
5C159MC33
5C159MC35
5C159TA50
5C159TB08
5C159TC04
(57)【要約】
本開示は、ビデオデコーディングにおける逆量子化の前または後にデコーディングされた変換係数を改良するためのクロスコンポーネント方法に関する。例えば、ビデオデコーディングのための方法が開示される。本方法は、コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出するステップと、コーディングされたビデオのビットストリームから第2の色成分の第2の変換係数を抽出するステップと、第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出するステップと、第2の色成分の修正された第2の変換係数を生成するために、第2の変換係数の大きさにオフセット値を加算するステップと、少なくとも第1の色成分の第1の変換係数および第2の色成分の修正された第2の変換係数に基づいてコーディングされたビデオを再構築するステップと、を含み得る。
【特許請求の範囲】
【請求項1】
ビデオデコーディングのための方法であって、
コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出するステップと、
前記コーディングされたビデオの前記ビットストリームから第2の色成分の第2の変換係数を抽出するステップと、
前記第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出するステップと、
前記第2の色成分の修正された第2の変換係数を生成するために、前記第2の変換係数の大きさに前記オフセット値を加算するステップと、
少なくとも前記第1の色成分の前記第1の変換係数および前記第2の色成分の前記修正された第2の変換係数に基づいて前記コーディングされたビデオを再構築するステップと
を含む、方法。
【請求項2】
前記第1の変換係数および前記第2の変換係数が並置される、請求項1に記載の方法。
【請求項3】
前記第1の色成分が1つのクロマ成分を含み、前記第2の色成分が別のクロマ成分を含む、請求項1に記載の方法。
【請求項4】
前記第1の色成分がルマ成分を含み、前記第2の色成分が1つのクロマ成分を含む、請求項1に記載の方法。
【請求項5】
前記第1の色成分が1つのクロマ成分を含み、前記第2の色成分がルマ成分を含む、請求項1に記載の方法。
【請求項6】
前記第1の変換係数が、前記ビットストリームから量子化されたときに非ゼロであり、
前記第2の変換係数が、前記ビットストリームから量子化されたときにゼロである、
請求項1に記載の方法。
【請求項7】
前記第1の変換係数が、符号値および大きさ値を含み、
前記オフセット値を導出するステップが、前記第1の変換係数の前記符号値に基づいて前記オフセット値を導出するステップを含む、
請求項1に記載の方法。
【請求項8】
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化後に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化の前に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、請求項1から7のいずれか一項に記載の方法。
【請求項10】
前記オフセット値が、前記第1の変換係数の符号と反対の符号を有し、
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化後に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、
請求項1から7のいずれか一項に記載の方法。
【請求項11】
前記第1の変換係数の符号値と前記オフセット値の符号とが反対であるかどうかが、
ビデオパラメータセット(VPS)、
シーケンスパラメータセット(SPS)、
ピクチャパラメータセット(PPS)、
適応パラメータセット(APS)、
フレームヘッダ、
スライスヘッダ、
コーディングツリーユニットヘッダ、または
タイルヘッダ
のうちの1つでシグナリングされる、請求項1から7のいずれか一項に記載の方法。
【請求項12】
前記オフセット値が、前記第1の変換係数の符号および大きさの両方に依存する、請求項1から7のいずれか一項に記載の方法。
【請求項13】
前記オフセット値の大きさが、前記第1の変換係数の前記大きさに依存する、請求項12に記載の方法。
【請求項14】
前記オフセット値の大きさが、オフセット値の大きさと前記第1の色成分の変換係数の大きさとの間の所定の対応関係を介して事前定義される、請求項12に記載の方法。
【請求項15】
前記オフセット値が、前記第1の変換係数に対応する周波数位置に応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項16】
前記オフセット値が、前記第1の変換係数および前記第2の変換係数が属する変換ブロックのブロックサイズに応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項17】
前記オフセット値が、前記第2の色成分がルマ成分であるかクロマ成分であるかに応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項18】
コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出し、
前記コーディングされたビデオの前記ビットストリームから第2の色成分の第2の変換係数を抽出し、
前記第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出し、
前記第2の色成分の修正された第2の変換係数を生成するために、前記第2の変換係数の大きさに前記オフセット値を加算し、
少なくとも前記第1の色成分の前記第1の変換係数および前記第2の色成分の前記修正された第2の変換係数に基づいて前記コーディングされたビデオを再構築する
ように構成された回路を備える、ビデオデコーディングのためのデバイス。
【請求項19】
前記第1の変換係数の量子化係数が非ゼロであり、
前記第2の変換係数の量子化係数がゼロである、
請求項18に記載のデバイス。
【請求項20】
コンピュータ命令を格納するための非一時的コンピュータ可読媒体であって、前記コンピュータ命令は、プロセッサによって実行されると、前記プロセッサに、
コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出させ、
前記コーディングされたビデオの前記ビットストリームから第2の色成分の第2の変換係数を抽出させ、
前記第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出させ、
前記第2の色成分の修正された第2の変換係数を生成するために、前記第2の変換係数の大きさに前記オフセット値を加算させ、
少なくとも前記第1の色成分の前記第1の変換係数および前記第2の色成分の前記修正された第2の変換係数に基づいて前記コーディングされたビデオを再構築させる、
非一時的コンピュータ可読媒体。
【請求項21】
請求項2から5および7のいずれか一項を実行するように構成された回路を備える、ビデオデコーディングのためのデバイス。
【請求項22】
コンピュータ命令を格納するための非一時的コンピュータ可読媒体であって、前記コンピュータ命令は、プロセッサによって実行されると、請求項2から7のいずれか一項を前記プロセッサに実行させる、非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2021年7月21日に出願された「CROSS-COMPONENT TRANSFORM COEFFICIENT LEVEL RECONSTRUCTION」と題する米国仮特許出願第63/224,046号の優先権を主張する、2022年1月13日に出願された米国非仮特許出願第17/575,075号の優先権の利益に基づき、その利益を主張する。両出願とも、その全体が参照により本明細書に組み込まれる。
【0002】
本開示は、一般に、高度なビデオコーディング/デコーディング技術のセットに関し、より具体的には、逆量子化の前または後にデコーディングされた変換係数を改良するためのクロスコンポーネント方法に関する。
【背景技術】
【0003】
本明細書で提供される背景技術の説明は、本開示の文脈を一般的に提示することを目的としている。本発明者らの研究は、その研究がこの背景技術の項に記載されている限りにおいて、またそれ以外の本出願の出願時に先行技術として認められない可能性のある説明の態様と共に、本開示に対する先行技術としては明示的にも暗示的にも認められない。
【0004】
ビデオコーディングおよびデコーディングは、動き補償を伴うインターピクチャ予測を使用して実行され得る。非圧縮デジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば1920×1080の輝度サンプルおよび関連するフルサンプリングまたはサブサンプリングされた色差サンプルの空間次元を有する。一連のピクチャは、例えば毎秒60ピクチャまたは毎秒60フレームの固定または可変のピクチャレート(あるいはフレームレートとも呼ばれる)を有することができる。非圧縮ビデオは、ストリーミングまたはデータ処理のための特定のビットレート要件を有する。例えば、1920×1080のピクセル解像度、60フレーム/秒のフレームレート、および色チャネルあたりピクセルあたり8ビットで4:2:0のクロマサブサンプリングを有するビデオは、1.5Gbit/sに近い帯域幅を必要とする。そのようなビデオの1時間は、600ギガバイトを超える記憶空間を必要とする。
【0005】
ビデオコーディングおよびビデオデコーディングの1つの目的は、圧縮による非圧縮入力ビデオ信号の冗長性の低減であり得る。圧縮は、前述の帯域幅および/または記憶空間要件を、場合によっては2桁以上低減させるのに役立ち得る。可逆圧縮と非可逆圧縮の両方、ならびにそれらの組み合わせを採用することができる。可逆圧縮とは、原信号の正確なコピーをデコーディングプロセスによって圧縮された原信号から再構築することができる技術を指す。非可逆圧縮とは、元のビデオ情報がコーディング時に完全に保持されず、デコーディング時に完全に回復できないコーディング/デコーディングプロセスを指す。非可逆圧縮を使用する場合、再構築された信号は原信号と同一ではない可能性があるが、原信号と再構築された信号との間の歪みは、多少の情報損失はあっても、再構築された信号を意図された用途に役立てるのに十分なほど小さくなる。ビデオの場合、非可逆圧縮が多くの用途で広く採用されている。耐容できる歪みの量は用途に依存する。例えば、特定の消費者ビデオストリーミング用途のユーザは、映画やテレビ放送用途のユーザよりも高い歪みを容認し得る。特定のコーディングアルゴリズムによって達成可能な圧縮比が、様々な歪み耐性を反映するように選択または調整され得る。すなわち、一般に、歪み耐性が高いほど、高い損失および高い圧縮比をもたらすコーディングアルゴリズムが可能になる。
【0006】
ビデオエンコーダおよびビデオデコーダは、例えば、動き補償、フーリエ変換、量子化、およびエントロピーコーディングを含む、いくつかの広範なカテゴリおよびステップからの技術を利用することができる。
【0007】
ビデオコーデック技術は、イントラコーディングとして知られる技術を含むことができる。イントラコーディングでは、サンプル値は、以前に再構築された参照ピクチャからのサンプルまたは他のデータを参照することなく表される。一部のビデオコーデックでは、ピクチャがサンプルのブロックに、空間的に細分される。サンプルのすべてのブロックがイントラモードでコーディングされる場合、そのピクチャをイントラピクチャと呼ぶことができる。イントラピクチャおよび独立したデコーダリフレッシュピクチャなどのそれらの派生ピクチャは、デコーダ状態をリセットするために使用され得、したがって、コーディングされたビデオビットストリームおよびビデオセッション内の最初のピクチャとして、または静止画像として使用され得る。次いで、イントラ予測後のブロックのサンプルに周波数領域への変換を施すことができ、そのように生成された変換係数をエントロピーコーディングの前に量子化することができる。イントラ予測は、変換前領域におけるサンプル値を最小化する技術を表す。場合によっては、変換後のDC値が小さいほど、かつAC係数が小さいほど、エントロピーコーディング後のブロックを表すために所与の量子化ステップのサイズにおいて必要とされるビットは少なくなる。
【0008】
例えば、MPEG-2生成コーディング技術から知られているような従来のイントラコーディングは、イントラ予測を使用しない。しかしながら、いくつかのより新しいビデオ圧縮技術は、例えば、空間的隣接のエンコーディングおよび/またはデコーディング時に取得される、イントラコーディングまたはイントラデコーディングされているデータのブロックにデコーディング順序で先行する、周囲のサンプルデータおよび/またはメタデータに基づいて、ブロックのコーディング/デコーディングを試みる技術を含む。このような技術は、以後「イントラ予測」技術と呼ばれる。少なくともいくつかの場合において、イントラ予測は、再構築中の現在のピクチャのみからの参照データを使用し、他の参照ピクチャからの参照データは使用しないことに留意されたい。
【0009】
イントラ予測には多くの異なる形式があり得る。そのような技術のうちの2つ以上が所与のビデオコーディング技術において利用可能である場合、使用される技術を、イントラ予測モードと呼ぶことができる。1つまたは複数のイントラ予測モードが特定のコーデックで提供され得る。特定の場合には、モードは、サブモードを有することができ、かつ/または様々なパラメータと関連付けられていてもよく、モード/サブモード情報およびビデオのブロックのイントラコーディングパラメータは、個別にコーディングされるか、またはまとめてモードのコードワードに含めることができる。所与のモード、サブモード、および/またはパラメータの組み合わせに、どのコードワードを使用するかは、イントラ予測を介したコーディング効率向上に影響を与える可能性があり、そのため、コードワードをビットストリームに変換するために使用されるエントロピーコーディング技術も影響を与える可能性がある。
【0010】
イントラ予測の特定のモードは、H.264で導入され、H.265において改良され、共同探索モデル(JEM:joint exploration model)、多用途ビデオコーディング(VVC:versatile video coding)、およびベンチマークセット(BMS:benchmark set)などのより新しいコーディング技術においてさらに改良された。一般に、イントラ予測では、利用可能になった隣接サンプル値を使用して予測子ブロックを形成することができる。例えば、特定の方向および/または線に沿った特定の隣接サンプルセットの利用可能な値が、予測子ブロックにコピーされ得る。使用中の方向への参照は、ビットストリーム内でコーディングされ得るか、またはそれ自体が予測されてもよい。
【0011】
図1Aを参照すると、右下に示されているのは、(H.265で指定される35のイントラモードのうちの33の角度モードに対応する)H.265の33の可能なイントラ予測子方向で指定される9つの予測子方向のサブセットである。矢印が収束する点(101)は、予測されているサンプルを表す。矢印は、隣接サンプルがそこから101のサンプルを予測するために使用される方向を表す。例えば、矢印(102)は、サンプル(101)が、1つまたは複数の隣接サンプルから右上へ、水平方向から45度の角度で予測されることを示している。同様に、矢印(103)は、サンプル(101)が、1つまたは複数の隣接サンプルからサンプル(101)の左下へ、水平方向から22.5度の角度で予測されることを示している。
【0012】
さらに図1Aを参照すると、左上には、(太い破線によって示された)4×4サンプルの正方形ブロック(104)が示されている。正方形ブロック(104)は16個のサンプルを含み、各々、「S」、Y次元のその位置(例えば、行インデックス)、およびX次元のその位置(例えば、列インデックス)でラベル付けされている。例えば、サンプルS21は、Y次元の(上から)2番目のサンプルであり、X次元の(左から)1番目のサンプルである。同様に、サンプルS44は、ブロック(104)内のY次元およびX次元の両方の4番目のサンプルである。ブロックはサイズが4×4サンプルなので、S44は右下にある。同様の番号付け方式に従う参照サンプルの例がさらに示されている。参照サンプルは、ブロック(104)に対してR、そのY位置(例えば、行インデックス)、およびX位置(列インデックス)でラベル付けされている。H.264とH.265の両方で、再構築中のブロックに隣接する予測サンプルが使用される。
【0013】
ブロック104のイントラピクチャ予測は、シグナリングされた予測方向に従って隣接サンプルから参照サンプル値をコピーすることから開始し得る。例えば、コーディングされたビデオビットストリームは、このブロック104について、矢印(102)の予測方向を示すシグナリングを含む、すなわち、サンプルは1つまたは複数の予測サンプルから右上へ、水平方向から45度の角度で予測されると仮定する。そのような場合、サンプルS41、S32、S23、S14が、同じ参照サンプルR05から予測される。次いで、参照サンプルR08からサンプルS44が予測される。
【0014】
特定の場合には、参照サンプルを計算するために、特に方向が45度によって均等に割り切れないときは、複数の参照サンプルの値は、例えば補間によって組み合わされてもよい。
【0015】
可能な方向の数は、ビデオコーディング技術が発展し続けるにつれて増加してきた。H.264(2003年)では、例えば、9つの異なる方向がイントラ予測に利用可能である。これは、H.265(2013年)では33まで増加し、JEM/VVC/BMSは、本開示の時点で、最大65の方向をサポートすることができる。最も適切なイントラ予測方向を特定するのに役立つ実験研究が行われており、エントロピーコーディングの特定の技術を使用して、方向についての特定のビットペナルティを受け入れて、それらの最も適切な方向が少数のビットでエンコーディングされ得る。さらに、方向自体を、デコーディングされた隣接ブロックのイントラ予測で使用された隣接する方向から予測できる場合もある。
【0016】
図1Bは、時間の経過と共に発展した様々なエンコーディング技術における増加する予測方向の数を例示するために、JEMによる65のイントラ予測方向を示す概略図(180)を示す。
【0017】
コーディングされたビデオビットストリームにおけるイントラ予測方向を表すビットの予測方向へのマッピングのための方法は、ビデオコーディング技術によって異なる可能性があり、例えば、予測方向対イントラ予測モードの単純な直接マッピングから、コードワード、最確モードを含む複雑な適応方式、および同様の技術に及ぶことができる。ただし、すべての場合において、他の特定の方向よりもビデオコンテンツで発生する可能性が統計的に低いイントラ予測の特定の方向が存在し得る。ビデオ圧縮の目的は冗長性の低減であるため、うまく設計されたビデオコーディング技術においては、それらのより可能性の低い方向はより可能性の高い方向よりも多くのビット数で表され得る。
【0018】
インターピクチャ予測、またはインター予測は、動き補償に基づいていてもよい。動き補償では、以前に再構築されたピクチャまたはその一部(参照ピクチャ)からのサンプルデータが、動きベクトル(これ以降はMV)によって示される方向に空間的にシフトされた後、新たに再構築されたピクチャまたはピクチャ部分(例えば、ブロック)の予測に使用され得る。場合によっては、参照ピクチャは、現在再構築中のピクチャと同じであり得る。MVは、2つの次元XおよびY、または3つの次元を有していてもよく、第3の次元は、(時間次元と類似した)使用中の参照ピクチャの指示である。
【0019】
いくつかのビデオ圧縮技術では、サンプルデータの特定のエリアに適用可能な現在のMVが、他のMVから、例えば再構築中のエリアに空間的に隣接し、デコーディング順序で現在のMVに先行する、サンプルデータの他のエリアに関連する他のMVから予測され得る。そうすることにより、相関するMVの冗長性の除去に依拠することによってMVをコーディングするのに必要とされる全体のデータ量を大幅に削減することができ、それによって圧縮効率が高まる。MV予測が効果的に機能することができるのは、例えば、(自然なビデオとして知られている)カメラから導出された入力ビデオ信号をコーディングするときに、単一のMVが適用可能なエリアよりも大きいエリアは、ビデオシーケンスにおいて同様の方向に移動する統計的尤度があり、したがって、場合によっては、隣接するエリアのMVから導出された同様の動きベクトルを使用して予測することができるからである。その結果として、所与のエリアの実際のMVが周囲のMVから予測されたMVと同様または同一になる。そのようなMVはさらに、エントロピーコーディング後に、MVが(1つまたは複数の)隣接するMVから予測されるのではなく直接コーディングされた場合に使用されることになるビット数よりも少ないビット数で表され得る。場合によっては、MV予測は、原信号(すなわち、サンプルストリーム)から導出された信号(すなわち、MV)の可逆圧縮の一例であり得る。他の場合には、例えば、いくつかの周囲のMVから予測子を計算するときの丸め誤差のために、MV予測自体は非可逆であり得る。
【0020】
様々なMV予測メカニズムが、H.265/HEVC(ITU-T勧告H.265、「High Efficiency Video Coding」、2016年12月)に記載されている。H.265が指定する多くのMV予測メカニズムのうち、以下で説明するのは、これ以降「空間マージ」と呼ぶ技術である。
【0021】
具体的には、図2を参照すると、現在のブロック(201)は、動き検索プロセス中にエンコーダによって、空間的にシフトされた同じサイズの前のブロックから予測可能であると検出されたサンプルを含む。直接そのMVをコーディングする代わりに、MVは、A0、A1、およびB0、B1、B2(それぞれ、202~206)と表記された5つの周囲サンプルのいずれか1つに関連付けられたMVを使用して、1つまたは複数の参照ピクチャに関連付けられたメタデータから、例えば、(デコーディング順序で)最新の参照ピクチャから導出され得る。H.265では、MV予測は、隣接ブロックが使用しているのと同じ参照ピクチャからの予測子を使用することができる。
【発明の概要】
【課題を解決するための手段】
【0022】
本開示の態様は、ビデオデコーディングにおける逆量子化の前または後に、デコーディングされた変換係数を改良するためのクロスコンポーネント方法および装置を提供する。いくつかの例示的な実装形態では、ビデオデコーディングのための方法が開示される。本方法は、コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出するステップと、コーディングされたビデオのビットストリームから第2の色成分の第2の変換係数を抽出するステップと、第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出するステップと、第2の色成分の修正された第2の変換係数を生成するために、第2の変換係数の大きさにオフセット値を加算するステップと、少なくとも第1の色成分の第1の変換係数および第2の色成分の修正された第2の変換係数に基づいてコーディングされたビデオを再構築するステップと、を含み得る。
【0023】
上記の実装形態では、第1の変換係数および第2の変換係数は並置される。
【0024】
上記の実装形態のいずれかにおいて、第1の色成分は1つのクロマ成分を含み、第2の色成分は別のクロマ成分を含み得る。
【0025】
上記の実装形態のいくつかでは、第1の色成分はルマ成分を含み、第2の色成分は1つのクロマ成分を含み得る。
【0026】
上記の実装形態のいくつかでは、第1の色成分は1つのクロマ成分を含み、第2の色成分はルマ成分を含み得る。
【0027】
上記の実装形態のいずれかにおいて、第1の変換係数は、ビットストリームから量子化されたときに非ゼロであり、第2の変換係数は、ビットストリームから量子化されたときにゼロである。
【0028】
上記の実装形態のいずれかにおいて、第1の変換係数は、符号値および大きさ値を含み、オフセット値を導出するステップは、第1の変換係数の符号値に基づいてオフセット値を導出するステップを含む。いくつかの実装形態では、第2の変換係数の大きさにオフセット値を加算するステップは、逆量子化後に第2の変換係数の大きさにオフセット値を加算するステップを含み得る。いくつかの他の実装形態では、第2の変換係数の大きさにオフセット値を加算するステップは、逆量子化前に第2の変換係数の大きさにオフセット値を加算するステップを含み得る。
【0029】
上記の実装形態のいずれかにおいて、オフセット値は、第1の変換係数の符号と反対の符号を有し、第2の変換係数の大きさにオフセット値を加算するステップは、逆量子化後に第2の変換係数の大きさにオフセット値を加算するステップを含み得る。
【0030】
上記の実装形態のいずれかにおいて、第1の変換係数の符号値とオフセット値の符号とが反対であるかどうかが、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)、適応パラメータセット(APS)、フレームヘッダ、スライスヘッダ、コーディングツリーユニットヘッダ、またはタイルヘッダのうちの1つでシグナリングされる。
【0031】
上記の実装形態のいずれかにおいて、オフセット値は、第1の変換係数の符号および大きさの両方に依存する。いくつかの実装形態では、オフセット値の大きさは、第1の変換係数の大きさに依存する。
【0032】
上記の実装形態のいくつかでは、オフセット値の大きさは、オフセット値の大きさと第1の色成分の変換係数の大きさとの間の所定の対応関係を介して事前定義される。
【0033】
上記の実装形態のいずれかにおいて、オフセット値は、第1の変換係数に対応する周波数位置に応じて決定される。
【0034】
上記の実装形態のいずれかにおいて、オフセット値は、第1の変換係数および第2の変換係数が属する変換ブロックのブロックサイズに応じて決定される。
【0035】
上記の実装形態のいずれかにおいて、オフセット値は、第2の色成分がルマ成分であるかクロマ成分であるかに応じて決定される。
【0036】
本開示の態様はまた、上記の方法の実装形態のいずれかを実行するように構成された回路を含むビデオエンコーディングまたはデコーディングデバイスまたは装置を提供する。
【0037】
本開示の態様はまた、ビデオデコーディングおよび/またはビデオエンコーディングのためにコンピュータによって実行されると、コンピュータにビデオデコーディングおよび/またはビデオエンコーディングのための方法を実行させる命令を格納する非一時的コンピュータ可読媒体も提供する。
【0038】
開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになる。
【図面の簡単な説明】
【0039】
図1A】イントラ予測方向性モードの例示的なサブセットの概略図である。
図1B】例示的なイントラ予測方向を示す図である。
図2】一例における現在のブロックおよび動きベクトル予測のためのその周囲の空間マージ候補を示す概略図である。
図3】一例示的実施形態による通信システム(300)の簡略化されたブロック図を示す概略図である。
図4】一例示的実施形態による通信システム(400)の簡略化されたブロック図を示す概略図である。
図5】一例示的実施形態によるビデオデコーダの簡略化されたブロック図を示す概略図である。
図6】一例示的実施形態によるビデオエンコーダの簡略化されたブロック図を示す概略図である。
図7】別の例示的実施形態によるビデオエンコーダを示すブロック図である。
図8】別の例示的実施形態によるビデオデコーダを示すブロック図である。
図9】本開示の例示的実施形態によるコーディングブロック分割の方式を示す図である。
図10】本開示の例示的実施形態によるコーディングブロック分割の別の方式を示す図である。
図11】本開示の例示的実施形態によるコーディングブロック分割の別の方式を示す図である。
図12】本開示の例示的実施形態によるコーディングブロック分割の別の方式を示す図である。
図13】本開示の例示的実施形態による、コーディングブロックを複数の変換ブロックに分割する方式および変換ブロックのコーディング順序を示す図である。
図14】本開示の例示的実施形態による、コーディングブロックを複数の変換ブロックに分割する別の方式および変換ブロックのコーディング順序を示す図である。
図15】本開示の例示的実施形態による、コーディングブロックを複数の変換ブロックに分割する別の方式を示す図である。
図16】本開示の例示的実施形態による方法のフローチャートを示す図である。
図17】本開示の例示的実施形態によるコンピュータシステムを示す概略図である。
【発明を実施するための形態】
【0040】
図3は、本開示の一実施形態による、通信システム(300)の簡略化されたブロック図を示す。通信システム(300)は、例えば、ネットワーク(350)を介して互いに通信することができる複数の端末デバイスを含む。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された端末デバイス(310)および(320)の第1のペアを含む。図3の例では、端末デバイス(310)および(320)の第1のペアは、データの単方向送信を実行し得る。例えば、端末デバイス(310)は、ネットワーク(350)を介して他方の端末デバイス(320)に送信するための(例えば、端末デバイス(310)によって取り込まれたビデオピクチャのストリームの)ビデオデータをコーディングし得る。エンコーディングされたビデオデータは、1つまたは複数のコーディングされたビデオビットストリームの形式で送信され得る。端末デバイス(320)は、ネットワーク(350)からコーディングされたビデオデータを受信し、コーディングされたビデオデータをデコーディングしてビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャを表示し得る。単方向データ送信は、メディアサービング用途などで実施され得る。
【0041】
別の例では、通信システム(300)は、例えばビデオ会議用途の間に実施され得るコーディングされたビデオデータの双方向送信を実行する端末デバイス(330)および(340)の第2のペアを含む。データの双方向送信のために、一例では、端末デバイス(330)および(340)の各端末デバイスは、ネットワーク(350)を介して端末デバイス(330)および(340)の他方の端末デバイスに送信するための(例えば、その端末デバイスによって取り込まれたビデオピクチャのストリームの)ビデオデータをコーディングし得る。端末デバイス(330)および(340)の各端末デバイスはまた、端末デバイス(330)および(340)の他方の端末デバイスによって送信されたコーディングされたビデオデータを受信し、コーディングされたビデオデータをデコーディングしてビデオピクチャを復元し、復元されたビデオデータに従ってアクセス可能な表示デバイスでビデオピクチャを表示し得る。
【0042】
図3の例では、端末デバイス(310)、(320)、(330)、および(340)は、サーバ、パーソナルコンピュータ、およびスマートフォンとして実施され得るが、本開示の基礎となる原理の適用性はそのように限定されない。本開示の実施形態は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、ウェアラブルコンピュータ、専用のビデオ会議機器などにおいて実装され得る。ネットワーク(350)は、例えば配線(有線)および/または無線通信ネットワークを含む、端末デバイス(310)、(320)、(330)および(340)間で、コーディングされたビデオデータを伝達する任意の数またはタイプのネットワークを表す。通信ネットワーク(350)9は回線交換チャネル、パケット交換チャネルおよび/または他のタイプのチャネルでデータを交換してもよい。代表的なネットワークには、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、および/またはインターネットが含まれる。本考察の目的にとって、ネットワーク(350)のアーキテクチャおよびトポロジーは、本明細書で明示的に説明されない限り、本開示の動作にとって重要ではない場合がある。
【0043】
図4に、開示の主題の用途の一例として、ビデオストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示す。開示の主題は、例えば、ビデオ会議、デジタルテレビ放送、ゲーム、仮想現実、CD、DVD、メモリスティックなどを含むデジタルメディア上の圧縮ビデオの格納などを含む、他のビデオ対応用途に等しく適用可能であってもよい。
【0044】
ビデオストリーミングシステムは、圧縮されていないビデオピクチャまたは画像のストリーム(402)を作成するためのビデオソース(401)、例えばデジタルカメラを含むことができるビデオキャプチャサブシステム(413)を含み得る。一例では、ビデオピクチャのストリーム(402)は、ビデオソース401のデジタルカメラによって記録されたサンプルを含む。エンコーディングされたビデオデータ(404)(またはコーディングされたビデオビットストリーム)と比較したときに多いデータ量を強調するために太い線として示されたビデオピクチャのストリーム(402)は、ビデオソース(401)に結合されたビデオエンコーダ(403)を含む電子デバイス(420)によって処理され得る。ビデオエンコーダ(403)は、以下でより詳細に記載されるように、開示された主題の態様を可能にするかまたは実装するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。エンコーディングされたビデオデータ(404)(またはエンコーディングされたビデオビットストリーム(404))は、非圧縮ビデオピクチャのストリーム(402)と比較した場合の低データ量を強調するために細線で示されており、将来の使用のためにストリーミングサーバ(405)に、または下流のビデオデバイス(図示せず)に直接格納され得る。図4のクライアントサブシステム(406)および(408)などの1つまたは複数のストリーミングクライアントサブシステムは、ストリーミングサーバ(405)にアクセスして、エンコーディングされたビデオデータ(404)のコピー(407)および(409)を取り出すことができる。クライアントサブシステム(406)は、例えば、電子デバイス(430)内のビデオデコーダ(410)を含むことができる。ビデオデコーダ(410)は、エンコーディングされたビデオデータの入力コピー(407)をデコーディングし、圧縮されていない、ディスプレイ(412)(例えば、表示画面)または他のレンダリングデバイス(図示せず)上にレンダリングすることができるビデオピクチャの出力ストリーム(411)を作成する。ビデオデコーダ410は、本開示に記載される様々な機能の一部または全部を実行するように構成され得る。いくつかのストリーミングシステムでは、エンコーディングされたビデオデータ(404)、(407)、および(409)(例えば、ビデオビットストリーム)は、特定のビデオコーディング/圧縮規格に従ってエンコーディングされ得る。それらの規格の例には、ITU-T勧告H.265が含まれる。一例では、開発中のビデオコーディング規格は、非公式に多用途ビデオコーディング(VVC:Versatile Video Coding)として知られている。開示の主題は、VVC、および他のビデオコーディング規格の文脈で使用され得る。
【0045】
電子デバイス(420)および(430)は、他の構成要素(図示せず)を含むことができることに留意されたい。例えば、電子デバイス(420)はビデオデコーダ(図示せず)を含むことができ、電子デバイス(430)もビデオエンコーダ(図示せず)を含むことができる。
【0046】
図5は、以下の本開示の任意の実施形態によるビデオデコーダ(510)のブロック図を示す。ビデオデコーダ(510)は、電子デバイス(530)に含まれ得る。電子デバイス(530)は、受信機(531)(例えば、受信回路)を含むことができる。ビデオデコーダ(510)を、図4の例のビデオデコーダ(410)の代わりに使用することができる。
【0047】
受信機(531)は、ビデオデコーダ(510)によってデコーディングされるべき1つまたは複数のコーディングされたビデオシーケンスを受信し得る。同じまたは別の実施形態では、一度に1つのコーディングされたビデオシーケンスがデコーディングされ得、各コーディングされたビデオシーケンスのデコーディングは、他のコーディングされたビデオシーケンスから独立している。各ビデオシーケンスは、複数のビデオフレームまたはビデオ画像と関連付けられ得る。コーディングされたビデオシーケンスはチャネル(501)から受信され得、チャネル(501)は、エンコーディングされたビデオデータを格納するストレージデバイスへのハードウェア/ソフトウェアリンク、またはエンコーディングされたビデオデータを送信するストリーミングソースであり得る。受信機(531)は、エンコーディングされたビデオデータを、それぞれの処理回路(図示せず)に転送され得る、コーディングされたオーディオデータおよび/または補助データストリームなどの他のデータと共に受信し得る。受信機(531)は、コーディングされたビデオシーケンスを他のデータから分離し得る。ネットワークジッタに対抗するために、バッファメモリ(515)が、受信機(531)とエントロピーデコーダ/パーサ(520)(これ以降は「パーサ(520)」)との間に配置されてもよい。特定の用途では、バッファメモリ(515)は、ビデオデコーダ(510)の一部として実装され得る。他の用途では、バッファメモリ(515)は、ビデオデコーダ(510)から分離されて外部にあり得る(図示せず)。さらに他の用途では、例えばネットワークジッタに対抗するためにビデオデコーダ(510)の外部にバッファメモリ(図示せず)があってもよく、例えば再生タイミングを処理するためにビデオデコーダ(510)の内部に別の追加のバッファメモリ(515)があり得る。受信機(531)が十分な帯域幅および制御可能性のストア/フォワードデバイスから、またはアイソシンクロナス(isosynchronous)ネットワークからデータを受信しているとき、バッファメモリ(515)は必要とされない場合があるか、または小さい可能性がある。インターネットなどのベストエフォートパケットネットワークで使用するために、十分なサイズのバッファメモリ(515)が必要とされる場合があり、そのサイズは比較的大きくなり得る。そのようなバッファメモリは、適応サイズで実装されてもよく、ビデオデコーダ(510)の外部のオペレーティングシステムまたは同様の要素(図示せず)に少なくとも部分的に実装されてもよい。
【0048】
ビデオデコーダ(510)は、コーディングされたビデオシーケンスからシンボル(521)を再構築するためにパーサ(520)を含んでもよい。それらのシンボルのカテゴリは、ビデオデコーダ(510)の動作を管理するために使用される情報と、潜在的に、図5に示すように、電子デバイス(530)の不可欠な部分である場合もそうでない場合もあるが、電子デバイス(530)に結合することができるディスプレイ(512)(例えば、表示画面)などのレンダリングデバイスを制御するための情報とを含む。(1つまたは複数の)レンダリングデバイスのための制御情報は、補足拡張情報(SEIメッセージ)またはビデオユーザビリティ情報(VUI)のパラメータセットフラグメント(図示せず)の形式であってもよい。パーサ(520)は、パーサ(520)によって受け取られるコーディングされたビデオシーケンスを構文解析/エントロピーデコーディングし得る。コーディングされたビデオシーケンスのエントロピーコーディングは、ビデオコーディング技術または規格に従ったものとすることができ、可変長コーディング、ハフマンコーディング、文脈依存性ありまたはなしの算術コーディングなどを含む様々な原理に従うことができる。パーサ(520)は、コーディングされたビデオシーケンスから、サブグループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのサブグループパラメータのセットを抽出し得る。サブグループには、ピクチャグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)などを含めることができる。パーサ(520)はまた、コーディングされたビデオシーケンスから、変換係数(例えば、フーリエ変換係数)、量子化パラメータ値、動きベクトルなどの情報も抽出し得る。
【0049】
パーサ(520)は、シンボル(521)を作成するために、バッファメモリ(515)から受け取ったビデオシーケンスに対してエントロピーデコーディング/構文解析動作を実行し得る。
【0050】
シンボル(521)の再構築は、コーディングされたビデオピクチャまたはその部分のタイプ(インターピクチャおよびイントラピクチャ、インターブロックおよびイントラブロックなど)、ならびに他の要因に応じて、複数の異なる処理ユニットまたは機能ユニットを含むことができる。含まれるユニットおよびユニットがどのように含まれるかは、パーサ(520)によってコーディングされたビデオシーケンスから構文解析されたサブグループ制御情報によって制御され得る。パーサ(520)と以下の複数の処理ユニットまたは機能ユニットとの間のそのようなサブグループ制御情報の流れは、簡潔にするために図示されていない。
【0051】
既に述べられた機能ブロック以外に、ビデオデコーダ(510)は、以下に記載されるように、概念的にいくつかの機能ユニットに細分化され得る。商業的制約の下で動作する実際の実装形態では、これらの機能ユニットの多くは互いに密接に相互作用し、少なくとも部分的に、互いに統合され得る。しかしながら、開示の主題の様々な機能を明確に説明するために、以下の開示においては機能ユニットへの概念的細分を採用する。
【0052】
第1のユニットはスケーラ/逆変換ユニット(551)を含み得る。スケーラ/逆変換ユニット(551)は、量子化変換係数、ならびにどのタイプの逆変換を使用するかを示す情報、ブロックサイズ、量子化係数/パラメータ、量子化スケーリング行列などを含む制御情報を、パーサ(520)から(1つまたは複数の)シンボル(521)として受信し得る。スケーラ/逆変換ユニット(551)は、アグリゲータ(555)に入力することができるサンプル値を含むブロックを出力することができる。
【0053】
場合によっては、スケーラ/逆変換(551)の出力サンプルは、イントラコーディングされたブロック、すなわち、以前に再構築されたピクチャからの予測情報を使用しないが、現在のピクチャの以前に再構築された部分からの予測情報を使用することができるブロックに関係する場合がある。そのような予測情報は、イントラピクチャ予測ユニット(552)によって提供され得る。場合によっては、イントラピクチャ予測ユニット(552)は、既に再構築され、現在のピクチャバッファ(558)に格納されている周囲のブロックの情報を使用して、再構築中のブロックと同じサイズおよび形状のブロックを生成してもよい。現在のピクチャバッファ(558)は、例えば、部分的に再構築された現在のピクチャおよび/または完全に再構築された現在のピクチャをバッファリングする。アグリゲータ(555)は、いくつかの実装形態では、サンプルごとに、イントラ予測ユニット(552)が生成した予測情報を、スケーラ/逆変換ユニット(551)によって提供される出力サンプル情報に追加してもよい。
【0054】
他の場合には、スケーラ/逆変換ユニット(551)の出力サンプルは、インターコーディングされ、潜在的に動き補償されたブロックに関連する可能性がある。そのような場合、動き補償予測ユニット(553)は、参照ピクチャメモリ(557)にアクセスして、インターピクチャ予測に使用されるサンプルをフェッチすることができる。ブロックに関連するシンボル(521)に従ってフェッチされたサンプルを動き補償した後、これらのサンプルを、出力サンプル情報を生成するために、アグリゲータ(555)によってスケーラ/逆変換ユニット(551)の出力に追加することができる(ユニット551の出力は、残差サンプルまたは残差信号と呼ばれ得る)。動き補償予測ユニット(553)がそこから予測サンプルをフェッチする参照ピクチャメモリ(557)内のアドレスは、例えば、X成分、Y成分(シフト)、および参照ピクチャ成分(時間)を有することができるシンボル(521)の形で動き補償予測ユニット(553)に利用可能な、動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ(557)からフェッチされたサンプル値の補間も含んでいてもよく、動きベクトル予測メカニズムなどと関連付けられてもよい。
【0055】
アグリゲータ(555)の出力サンプルは、ループフィルタユニット(556)において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、(コーディングされたビデオビットストリームとも呼ばれる)コーディングされたビデオシーケンスに含まれるパラメータによって制御され、パーサ(520)からのシンボル(521)としてループフィルタユニット(556)に利用可能にされるインループフィルタ技術を含むことができるが、コーディングされたピクチャまたはコーディングされたビデオシーケンスの(デコーディング順序で)前の部分のデコーディング中に取得されたメタ情報に応答するだけでなく、以前に再構築およびループフィルタリングされたサンプル値に応答することもできる。以下でさらに詳細に説明するように、いくつかのタイプのループフィルタが、様々な順序でループフィルタユニット556の一部として含まれ得る。
【0056】
ループフィルタユニット(556)の出力は、レンダリングデバイス(512)に出力することができると共に、将来のインターピクチャ予測で使用するために参照ピクチャメモリ(557)に格納することもできるサンプルストリームであり得る。
【0057】
特定のコーディングされたピクチャは、完全に再構築されると、将来のインターピクチャ予測のための参照ピクチャとして使用され得る。例えば、現在のピクチャに対応するコーディングされたピクチャが完全に再構築され、コーディングされたピクチャが参照ピクチャとして(例えば、パーサ(520)によって)識別されると、現在のピクチャバッファ(558)は、参照ピクチャメモリ(557)の一部になることができ、未使用の現在のピクチャバッファは、次のコーディングされたピクチャの再構築を開始する前に再割り当てされ得る。
【0058】
ビデオデコーダ(510)は、例えばITU-T勧告H.265などの規格で採用された所定のビデオ圧縮技術に従ってデコーディング動作を実行し得る。コーディングされたビデオシーケンスがビデオ圧縮技術または規格の構文とビデオ圧縮技術または規格において文書化されたプロファイルの両方を順守するという意味で、コーディングされたビデオシーケンスは、使用されているビデオ圧縮技術または規格によって指定された構文に準拠し得る。具体的には、プロファイルは、ビデオ圧縮技術または規格において使用可能なすべてのツールから、そのプロファイルの下で使用できる唯一のツールとして特定のツールを選択できる。規格に準拠するために、コーディングされたビデオシーケンスの複雑さが、ビデオ圧縮技術または規格のレベルによって定義される範囲内にあり得る。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート(例えば毎秒メガサンプルで測定される)、最大参照ピクチャサイズなどを制限する。レベルによって設定される制限は、場合によっては、仮想参照デコーダ(HRD)の仕様、およびコーディングされたビデオシーケンス内でシグナリングされるHRDバッファ管理用のメタデータによってさらに制限され得る。
【0059】
いくつかの例示的実施形態では、受信機(531)は、エンコーディングされたビデオと共に追加の(冗長な)データを受信し得る。追加のデータは、コーディングされたビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコーディングするために、かつ/または元のビデオデータをより正確に再構築するために、ビデオデコーダ(510)によって使用されてもよい。追加のデータは、例えば、時間、空間、または信号雑音比(SNR:signal noise ratio)拡張レイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正コードなどの形式であり得る。
【0060】
図6は、本開示の一例示的実施形態によるビデオエンコーダ(603)のブロック図を示す。ビデオエンコーダ(603)は、電子デバイス(620)に含まれ得る。電子デバイス(620)は、送信機(640)(例えば、送信回路)をさらに含み得る。ビデオエンコーダ(603)を、図4の例のビデオエンコーダ(403)の代わりに使用することができる。
【0061】
ビデオエンコーダ(603)は、ビデオエンコーダ(603)によってコーディングされるべき(1つまたは複数の)ビデオ画像を取り込み得るビデオソース(601)(図6の例では電子デバイス(620)の一部ではない)からビデオサンプルを受信し得る。別の例では、ビデオソース(601)は電子デバイス(620)の一部分として実装され得る。
【0062】
ビデオソース(601)は、ビデオエンコーダ(603)によってコーディングされるべきソースビデオシーケンスを、任意の適切なビット深度(例えば、8ビット、10ビット、12ビット、…)、任意の色空間(例えば、BT.601 YCrCb、RGB、XYZ…)、および任意の適切なサンプリング構造(例えば、YCrCb 4:2:0、YCrCb 4:4:4)のものとすることができるデジタルビデオサンプルストリームの形で提供し得る。メディアサービングシステムでは、ビデオソース(601)は、以前に準備されたビデオを格納することができるストレージデバイスであり得る。ビデオ会議システムでは、ビデオソース(601)は、ビデオシーケンスとしてローカル画像情報を取り込むカメラであってもよい。ビデオデータは、順番に見たときに動きを与える複数の個別のピクチャまたは画像として提供され得る。ピクチャ自体は、ピクセルの空間配列として編成されてもよく、各ピクセルは、使用されているサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの関係を容易に理解することができる。以下、サンプルに着目して説明する。
【0063】
いくつかの例示的実施形態によれば、ビデオエンコーダ(603)は、リアルタイムで、または用途によって必要とされる他の任意の時間制約の下で、ソースビデオシーケンスのピクチャをコーディングされたビデオシーケンス(643)にコーディングおよび圧縮し得る。適切なコーディング速度を強制することが、コントローラ(650)の1つの機能を構成する。いくつかの実施形態では、コントローラ(650)は、以下で説明されるように、他の機能ユニットに機能的に結合され、他の機能ユニットを制御し得る。簡潔にするために、結合は図示されていない。コントローラ(650)によって設定されるパラメータには、レート制御関連のパラメータ(ピクチャスキップ、量子化器、レート歪み最適化手法のラムダ値など)、ピクチャサイズ、ピクチャグループ(GOP)レイアウト、最大動きベクトル検索範囲などが含まれ得る。コントローラ(650)は、特定のシステム設計のために最適化されたビデオエンコーダ(603)に関連する他の適切な機能を有するように構成され得る。
【0064】
いくつかの例示的実施形態では、ビデオエンコーダ(603)は、コーディングループで動作するように構成され得る。過度に簡略化した説明として、一例では、コーディングループは、ソースコーダ(630)(例えば、コーディングされるべき入力ピクチャと参照ピクチャとに基づいて、シンボルストリームなどのシンボルを生成することに関与する)と、ビデオエンコーダ(603)に組み込まれた(ローカル)デコーダ(633)と、を含み得る。デコーダ(633)は、組み込まれたデコーダ633がエントロピーコーディングなしでソースコーダ630によってコーディングされたビデオストリームを処理するとしても、シンボルを再構築して、(リモート)デコーダが作成することになるのと同様の方法でサンプルデータを作成する(開示の主題で考慮されるビデオ圧縮技術では、シンボルとコーディングされたビデオビットストリームとの間の任意の圧縮が可逆であり得るため)。再構築されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームのデコーディングは、デコーダの位置(ローカルまたはリモート)に関係なくビット正確な結果につながるので、参照ピクチャメモリ(634)内のコンテンツも、ローカルエンコーダとリモートエンコーダとの間でビット正確である。言い換えると、エンコーダの予測部分は、デコーディング中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期性(および、例えばチャネル誤差が原因で同期性を維持することができない場合には、結果として生じるドリフト)のこの基本原理はコーディング品質を向上させるために使用される。
【0065】
「ローカル」デコーダ(633)の動作は、図5と共に上記で詳細に既に記載されている、ビデオデコーダ(510)などの「リモート」デコーダの動作と同じであり得る。図5も簡単に参照すると、しかしながら、シンボルが利用可能であり、エントロピーコーダ(645)およびパーサ(520)によるコーディングされたビデオシーケンスへのシンボルのエンコーディング/デコーディングが可逆であり得るため、バッファメモリ(515)およびパーサ(520)を含むビデオデコーダ(510)のエントロピーデコーディング部分は、エンコーダ内のローカルデコーダ(633)においては完全に実装されない場合がある。
【0066】
この時点で言えることは、デコーダ内にのみ存在し得る構文解析/エントロピーデコーディングを除く任意のデコーダ技術もまた必然的に、対応するエンコーダにおいて、実質的に同一の機能形態で存在する必要があり得るということである。このため、開示の主題はデコーダ動作に焦点を当てる場合があり、この動作はエンコーダのデコーディング部分と同様である。よって、エンコーダ技術の説明は、包括的に説明されるデコーダ技術の逆であるので、省略され得る。特定の領域または態様においてのみ、エンコーダのより詳細な説明を以下に示す。
【0067】
動作中、いくつかの例示的実装形態では、ソースコーダ(630)は、「参照ピクチャ」として指定されたビデオシーケンスからの1つまたは複数の以前にコーディングされたピクチャを参照して入力ピクチャを予測的にコーディングする、動き補償予測コーディングを実行する場合がある。このようにして、コーディングエンジン(632)は、入力ピクチャのピクセルブロックと、入力ピクチャへの(1つまたは複数の)予測参照として選択され得る(1つまたは複数の)参照ピクチャのピクセルブロックとの間の色チャネルの差分(または残差)をコーディングする。用語「残差(residue)」およびその形容詞形「残差の(residual)」は、互換的に使用され得る。
【0068】
ローカルビデオデコーダ(633)は、ソースコーダ(630)によって作成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコーディングされたビデオデータをデコーディングし得る。コーディングエンジン(632)の動作は、有利なことに、非可逆プロセスであってもよい。コーディングされたビデオデータが(図6には示されていない)ビデオデコーダでデコーディングされ得るとき、再構築されたビデオシーケンスは、通常、いくつかの誤差を伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ(633)は、参照ピクチャに対してビデオデコーダによって実行され得るデコーディングプロセスを複製し、再構築された参照ピクチャが参照ピクチャキャッシュ(634)に格納されるようにし得る。このようにして、ビデオエンコーダ(603)は、遠端(リモート)ビデオデコーダによって取得される再構築された参照ピクチャと共通の内容を有する再構築された参照ピクチャのコピーをローカルに格納し得る(送信誤差なしで)。
【0069】
予測器(635)は、コーディングエンジン(632)のための予測検索を実行し得る。すなわち、コーディングされる新しいピクチャの場合、予測器(635)は、新しいピクチャのための適切な予測参照として役立ち得る、(候補参照ピクセルブロックとしての)サンプルデータまたは参照ピクチャ動きベクトル、ブロック形状などの特定のメタデータを求めて、参照ピクチャメモリ(634)を検索し得る。予測器(635)は、適切な予測参照を見つけるために、ピクセルブロックごとにサンプルブロックに対して動作し得る。場合によっては、予測器(635)によって取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(634)に格納された複数の参照ピクチャから引き出された予測参照を有してもよい。
【0070】
コントローラ(650)は、例えば、ビデオデータをエンコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ソースコーダ(630)のコーディング動作を管理し得る。
【0071】
すべての前述の機能ユニットの出力は、エントロピーコーダ(645)内でエントロピーコーディングを受けてもよい。エントロピーコーダ(645)は、ハフマンコーディング、可変長コーディング、算術コーディングなどといった技術に従ったシンボルの可逆圧縮により、様々な機能ユニットによって生成されたシンボルをコーディングされたビデオシーケンスに変換する。
【0072】
送信機(640)は、エントロピーコーダ(645)によって作成されたコーディングされたビデオシーケンスをバッファリングして、通信チャネル(660)を介した送信の準備をすることができ、通信チャネル(660)は、エンコーディングされたビデオデータを格納するストレージデバイスへのハードウェア/ソフトウェアリンクであってもよい。送信機(640)は、ビデオコーダ(603)からのコーディングされたビデオデータを、送信される他のデータ、例えば、コーディングされたオーディオデータおよび/または補助データストリーム(ソースは図示されていない)とマージし得る。
【0073】
コントローラ(650)は、ビデオエンコーダ(603)の動作を管理し得る。コーディング中に、コントローラ(650)は、各コーディングされたピクチャに特定のコーディングされたピクチャタイプを割り当てることができ、それは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼす場合がある。例えば、ピクチャは多くの場合、次のピクチャタイプのいずれかとして割り当てられ得る。
【0074】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずにコーディングおよびデコーディングされ得るものであり得る。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(「IDR」)ピクチャを含む、様々なタイプのイントラピクチャを可能にする。当業者であれば、Iピクチャのそれらの変形ならびにそれらそれぞれの用途および特徴を認識している。
【0075】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るピクチャであり得る。
【0076】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用して、コーディングおよびデコーディングされ得るピクチャであり得る。同様に、複数予測ピクチャは、単一ブロックの再構築のために3つ以上の参照ピクチャおよび関連するメタデータを使用することができる。
【0077】
ソースピクチャは、一般に、複数のサンプルコーディングブロック(例えば、各々4×4、8×8、4×8、または16×16サンプルのブロック)に空間的に細分され、ブロックごとにコーディングされ得る。ブロックは、ブロックそれぞれのピクチャに適用されたコーディング割り当てによって決定されるように他の(既にコーディングされた)ブロックを参照して予測的にコーディングされ得る。例えば、Iピクチャのブロックは、非予測的にコーディングされてもよく、またはそれらは、同じピクチャの既にコーディングされたブロックを参照して予測的にコーディングされてもよい(空間予測もしくはイントラ予測)。Pピクチャのピクセルブロックは、1つの以前にコーディングされた参照ピクチャを参照して、空間予測を介して、または時間予測を介して、予測的にコーディングされてもよい。Bピクチャのブロックは、1つまたは2つの以前にコーディングされた参照ピクチャを参照して、空間予測を介して、または時間予測を介して、予測的にコーディングされ得る。ソースピクチャまたは中間処理されたピクチャは、他の目的で他のタイプのブロックに細分されてもよい。コーディングブロックおよびその他のタイプのブロックの分割は、以下でさらに詳細に説明するように、同じ方法に従う場合もそうでない場合もある。
【0078】
ビデオエンコーダ(603)は、ITU-T勧告H.265などの所定のビデオコーディング技術または規格に従ってコーディング動作を実行し得る。その動作において、ビデオエンコーダ(603)は、入力ビデオシーケンスにおける時間および空間の冗長性を利用する予測コーディング動作を含む、様々な圧縮動作を実行し得る。したがって、コーディングされたビデオデータは、使用されているビデオコーディング技術または規格によって指定された構文に準拠し得る。
【0079】
いくつかの例示的実施形態では、送信機(640)は、エンコーディングされたビデオと共に追加のデータを送信し得る。ソースコーダ(630)は、コーディングされたビデオシーケンスの一部としてそのようなデータを含んでもよい。追加のデータは、時間/空間/SNR拡張レイヤ、冗長なピクチャやスライスなどの他の形の冗長データ、SEIメッセージ、VUIパラメータセットフラグメントなどを含み得る。
【0080】
ビデオは、時系列で複数のソースピクチャ(ビデオピクチャ)として取り込まれてもよい。イントラピクチャ予測(しばしばイントラ予測と略される)は、所与のピクチャにおける空間相関を利用し、インターピクチャ予測は、ピクチャ間の時間またはその他の相関を利用する。例えば、現在のピクチャと呼ばれる、エンコーディング/デコーディング中の特定のピクチャがブロックに分割され得る。現在のピクチャ内のブロックは、ビデオ内の以前にコーディングされたまだバッファリングされている参照ピクチャ内の参照ブロックに類似している場合、動きベクトルと呼ばれるベクトルによってコーディングされ得る。動きベクトルは、参照ピクチャ内の参照ブロックを指し、複数の参照ピクチャが使用されている場合、参照ピクチャを識別する第3の次元を有することができる。
【0081】
いくつかの例示的実施形態では、インターピクチャ予測に双予測技術を使用することができる。そのような双予測技術によれば、第1の参照ピクチャおよび第2の参照ピクチャなどの2つの参照ピクチャが使用され、これらは両方ともビデオ内の現在のピクチャをデコーディング順序で進める(ただし、表示順序では、それぞれ過去または未来にあり得る)。現在のピクチャ内のブロックは、第1の参照ピクチャ内の第1の参照ブロックを指す第1の動きベクトル、および第2の参照ピクチャ内の第2の参照ブロックを指す第2の動きベクトルによってコーディングされ得る。ブロックを、第1の参照ブロックと第2の参照ブロックの組み合わせによって協調して予測することができる。
【0082】
さらに、マージモード技術が、インターピクチャ予測においてコーディング効率を改善するために使用されてもよい。
【0083】
本開示のいくつかの例示的実施形態によれば、インターピクチャ予測およびイントラピクチャ予測などの予測は、ブロック単位で実行される。例えば、ビデオピクチャのシーケンス内のピクチャは、圧縮のためにコーディングツリーユニット(CTU)に分割され、ピクチャ内のCTUは、64×64ピクセル、32×32ピクセル、または16×16ピクセルなどの同じサイズを有し得る。一般に、CTUは、3つの並列のコーディングツリーブロック(CTB)、すなわち、1つのルマCTBおよび2つのクロマCTBを含み得る。各CTUは、1つまたは複数のコーディングユニット(CU)に再帰的に四分木分割され得る。例えば、64×64ピクセルのCTUを、64×64ピクセルの1つのCU、または32×32ピクセルの4つのCUに分割することができる。32×32ブロックのうちの1つまたは複数の各々は、16×16ピクセルの4つのCUにさらに分割され得る。いくつかの例示的実施形態では、各CUは、インター予測タイプやイントラ予測タイプなどの様々な予測タイプの中からそのCUの予測タイプを決定するためにエンコーディング中に分析され得る。CUは、時間的および/または空間的予測可能性に応じて、1つまたは複数の予測ユニット(PU)に分割され得る。一般に、各PUは、1つのルマ予測ブロック(PB)および2つのクロマPBを含む。一実施形態では、コーディング(エンコーディング/デコーディング)における予測動作は、予測ブロックの単位で実行される。CUのPU(または異なる色チャネルのPB)への分割は、様々な空間パターンで実行され得る。ルマPBまたはクロマPBは、例えば、8×8ピクセル、16×16ピクセル、8×16ピクセル、16×8ピクセルなどといった、サンプルの値(例えば、ルマ値)の行列を含み得る。
【0084】
図7は、本開示の別の例示的実施形態によるビデオエンコーダ(703)の図を示す。ビデオエンコーダ(703)は、ビデオピクチャのシーケンス内の現在ビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックをコーディングされたビデオシーケンスの一部であるコーディングされたピクチャにエンコーディングするように構成される。例示的なビデオエンコーダ(703)は、図4の例のビデオエンコーダ(403)の代わりに使用され得る。
【0085】
例えば、ビデオエンコーダ(703)は、8×8サンプルの予測ブロックなどの処理ブロックのサンプル値の行列を受け取る。次いでビデオエンコーダ(703)は、例えばレート歪み最適化(RDO)を使用して、処理ブロックがそれを使用して最良にコーディングされるのは、イントラモードか、インターモードか、それとも双予測モードかを決定する。処理ブロックがイントラモードでコーディングされると決定された場合、ビデオエンコーダ(703)は、イントラ予測技術を使用して処理ブロックをコーディングされたピクチャにエンコーディングし、処理ブロックがインターモードまたは双予測モードでコーディングされると決定された場合、ビデオエンコーダ(703)は、それぞれインター予測技術または双予測技術を使用して、処理ブロックをコーディングされたピクチャにエンコーディングし得る。いくつかの例示的実施形態では、インターピクチャ予測のサブモードとして、動きベクトルが予測子の外側のコーディングされた動きベクトル成分の恩恵を受けずに1つまたは複数の動きベクトル予測子から導出されるマージモードが使用され得る。いくつかの他の例示的実施形態では、対象ブロックに適用可能な動きベクトル成分が存在し得る。したがって、ビデオエンコーダ(703)は、処理ブロックの予測モードを決定するために、モード決定モジュールなどの、図7に明示的に示されていない構成要素を含み得る。
【0086】
図7の例では、ビデオエンコーダ(703)は、図7の例示的な構成に示されるように互いに結合されたインターエンコーダ(730)、イントラエンコーダ(722)、残差計算器(723)、スイッチ(726)、残差エンコーダ(724)、汎用コントローラ(721)、およびエントロピーエンコーダ(725)を含む。
【0087】
インターエンコーダ(730)は、現在のブロック(例えば、処理ブロック)のサンプルを受け取り、そのブロックを参照ピクチャ内の1つまたは複数の参照ブロック(例えば、表示順序で前のピクチャ内および後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インターエンコーディング技術による冗長情報、動きベクトル、マージモード情報の記述)を生成し、任意の適切な技術を使用してインター予測情報に基づいてインター予測結果(例えば、予測されたブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、(以下でさらに詳細に説明するように、図7の残差デコーダ728として示されている)図6の例示的なエンコーダ620に組み込まれたデコーディングユニット633を使用してエンコーディングされたビデオ情報に基づいてデコーディングされたデコーディング参照ピクチャである。
【0088】
イントラエンコーダ(722)は、現在のブロック(例えば、処理ブロック)のサンプルを受け取り、ブロックを同じピクチャ内の既にコーディングされたブロックと比較し、変換後の量子化係数を生成し、場合によってはイントラ予測情報(例えば、1つまたは複数のイントラエンコーディング技術によるイントラ予測方向情報)も生成するように構成される。イントラエンコーダ(722)は、イントラ予測情報と、同じピクチャ内の参照ブロックとに基づいて、イントラ予測結果(例えば、予測されたブロック)を計算し得る。
【0089】
汎用コントローラ(721)は、汎用制御データを決定し、汎用制御データに基づいてビデオエンコーダ(703)の他の構成要素を制御するように構成され得る。一例では、汎用コントローラ(721)は、ブロックの予測モードを決定し、予測モードに基づいてスイッチ(726)に制御信号を提供する。例えば、予測モードがイントラモードである場合、汎用コントローラ(721)は、スイッチ(726)を制御して、残差計算器(723)が使用するためのイントラモード結果を選択させ、エントロピーエンコーダ(725)を制御して、イントラ予測情報を選択させてそのイントラ予測情報をビットストリームに含めさせ、ブロックの予測モードがインターモードである場合、汎用コントローラ(721)は、スイッチ(726)を制御して、残差計算器(723)が使用するためのインター予測結果を選択させて、エントロピーエンコーダ(725)を制御して、インター予測情報を選択させてそのインター予測情報をビットストリームに含めさせる。
【0090】
残差計算器(723)は、受け取ったブロックと、イントラエンコーダ(722)またはインターエンコーダ(730)から選択されたブロックについての予測結果との差分(残差データ)を計算するように構成され得る。残差エンコーダ(724)は、残差データをエンコーディングして変換係数を生成するように構成され得る。例えば、残差エンコーダ(724)は、残差データを空間領域から周波数領域に変換して変換係数を生成するように構成され得る。次いで、変換係数は、量子化変換係数を取得するために量子化処理を受ける。様々な例示的実施形態において、ビデオエンコーダ(703)は残差デコーダ(728)も含む。残差デコーダ(728)は逆変換を実行し、デコーディングされた残差データを生成するように構成される。デコーディングされた残差データは、イントラエンコーダ(722)およびインターエンコーダ(730)によって適切に使用され得る。例えば、インターエンコーダ(730)は、デコーディングされた残差データおよびインター予測情報に基づいてデコーディングされたブロックを生成することができ、イントラエンコーダ(722)は、デコーディングされた残差データおよびイントラ予測情報に基づいてデコーディングされたブロックを生成することができる。デコーディングされたブロックは、デコーディングされたピクチャを生成するために適切に処理され、デコーディングされたピクチャは、メモリ回路(図示せず)にバッファリングされ、参照ピクチャとして使用され得る。
【0091】
エントロピーエンコーダ(725)は、ビットストリームをエンコーディングされたブロックを含むようにフォーマットし、エントロピーコーディングを実行するように構成され得る。エントロピーエンコーダ(725)は、ビットストリームに様々な情報を含めるように構成される。例えば、エントロピーエンコーダ(725)は、汎用制御データ、選択された予測情報(例えば、イントラ予測情報やインター予測情報)、残差情報、および他の適切な情報をビットストリームに含めるように構成され得る。インターモードまたは双予測モードのどちらかのマージサブモードでブロックをコーディングするときには、残差情報が存在しない場合がある。
【0092】
図8は、本開示の別の実施形態による例示的なビデオデコーダ(810)の図を示す。ビデオデコーダ(810)は、コーディングされたビデオシーケンスの一部であるコーディングされたピクチャを受信し、コーディングされたピクチャをデコーディングして再構築されたピクチャを生成するように構成される。一例では、ビデオデコーダ(810)は、図4の例のビデオデコーダ(410)の代わりに使用され得る。
【0093】
図8の例では、ビデオデコーダ(810)は、図8の例示的な構成に示されるように、互いに結合されたエントロピーデコーダ(871)、インターデコーダ(880)、残差デコーダ(873)、再構築モジュール(874)、およびイントラデコーダ(872)を含む。
【0094】
エントロピーデコーダ(871)は、コーディングされたピクチャから、コーディングされたピクチャが構成される構文要素を表す特定のシンボルを再構築するように構成され得る。そのようなシンボルは、例えば、ブロックがコーディングされているモード(例えば、イントラモード、インターモード、双予測モード、マージサブモードまたは別のサブモード)、イントラデコーダ(872)またはインターデコーダ(880)によって予測に使用される特定のサンプルまたはメタデータを識別することができる予測情報(例えば、イントラ予測情報やインター予測情報)、例えば量子化変換係数の形の残差情報などを含むことができる。一例では、予測モードがインター予測モードまたは双予測モードである場合、インター予測情報がインターデコーダ(880)に提供され、予測タイプがイントラ予測タイプである場合、イントラ予測情報がイントラデコーダ(872)に提供される。残差情報は、逆量子化を受けることができ、残差デコーダ(873)に提供される。
【0095】
インターデコーダ(880)は、インター予測情報を受け取り、インター予測情報に基づいてインター予測結果を生成するように構成され得る。
【0096】
イントラデコーダ(872)は、イントラ予測情報を受け取り、イントラ予測情報に基づいて予測結果を生成するように構成され得る。
【0097】
残差デコーダ(873)は逆量子化を実行して逆量子化変換係数を抽出し、逆量子化変換係数を処理して残差を周波数領域から空間領域に変換するように構成され得る。残差デコーダ(873)はまた(量子化パラメータ(QP)を含めるために)特定の制御情報を利用する場合もあり、その情報はエントロピーデコーダ(871)によって提供され得る(これは少量の制御情報のみであり得るためデータパスは図示しない)。
【0098】
再構築モジュール(874)は、空間領域において、残差デコーダ(873)による出力としての残差と、(場合によって、インター予測モジュールまたはイントラ予測モジュールによる出力としての)予測結果とを組み合わせて、再構築されたビデオの一部としての再構築されたピクチャの一部を形成する再構築されたブロックを形成するように構成され得る。視覚的品質を改善するために、デブロッキング動作などの他の適切な動作が実行されてもよいことに留意されたい。
【0099】
ビデオエンコーダ(403)、(603)、および(703)、ならびにビデオデコーダ(410)、(510)、および(810)は、任意の適切な技術を使用して実装することができることに留意されたい。いくつかの例示的実施形態では、ビデオエンコーダ(403)、(603)、および(703)、ならびにビデオデコーダ(410)、(510)、および(810)を、1つまたは複数の集積回路を使用して実装することができる。別の実施形態では、ビデオエンコーダ(403)、(603)、および(603)、ならびにビデオデコーダ(410)、(510)、および(810)は、ソフトウェア命令を実行する1つまたは複数のプロセッサを使用して実装され得る。
【0100】
コーディングブロック分割を見ると、いくつかの例示的実装形態では、所定のパターンが適用され得る。図9に示すように、第1の所定のレベル(例えば、64×64ブロックレベル)から開始して第2の所定のレベル(例えば、4×4レベル)に至る例示的な4ウェイ分割ツリーが用いられ得る。例えば、ベースブロックは、902、904、906および908で示される4つの分割オプションに従うことができ、Rで表されたパーティションは、図9に示される同じ分割ツリーが最下位レベル(例えば、4×4レベル)まで下位スケールで繰り返され得るという点で、再帰分割が可能である。いくつかの実装形態では、図9の分割方式に追加の制限が適用され得る。図9の実装形態では、長方形パーティション(例えば、1:2/2:1の長方形パーティション)は、可能であるが繰り返して用いることはできず、一方、正方形分割は繰り返して用いることができる。必要に応じて、再帰による図9の後に続く分割により、コーディングブロックの最終セットが生成される。そのような方式が、色チャネルのうちの1つまたは複数に適用され得る。
【0101】
図10は、再帰分割により分割ツリーを形成することを可能にする別の例示的な所定の分割パターンを示す。図10に示すように、例示的な10ウェイ分割構造またはパターンが事前定義され得る。ルートブロックは、所定のレベルから(例えば、128×128レベルまたは64×64レベルから)開始し得る。図10の例示的な分割構造は、様々な2:1/1:2および4:1/1:4の長方形パーティションを含む。図10の2列目の1002、1004、1006、および1008で示される3つのサブパーティションを有するパーティションタイプは、「T型」パーティションと呼ばれ得る。「T型」パーティション1002、1004、1006、および1008は、左T型、上T型、右T型、および下T型と呼ばれてもよい。いくつかの実装形態では、図10の長方形パーティションのいずれもさらに細分されることができない。ルートノードまたはルートブロックからの分割深度を示すために、コーディングツリー深度がさらに定義され得る。例えば、128×128ブロックのルートノードまたはルートブラックのコーディングツリー深度は0に設定されてもよく、ルートブロックが図10の後に続いてさらに1回分割された後、コーディングツリー深度は1増加する。いくつかの実装形態では、1010のすべて正方形のパーティションのみが、図10のパターンの後に続く分割ツリーの次のレベルへの再帰分割を可能とし得る。言い換えると、再帰分割は、パターン1002、1004、1006、および1006の正方形パーティションでは不可能である。必要に応じて、再帰による図10の後に続く分割により、コーディングブロックの最終セットが生成される。そのような方式が、色チャネルのうちの1つまたは複数に適用され得る。
【0102】
上記の分割手順または他の手順のいずれかに従ってベースブロックを区分または分割した後にやはり、パーティションまたはコーディングブロックの最終セットが取得され得る。これらのパーティションの各々は、様々な分割レベルのうちの1つにあり得る。各パーティションは、コーディングブロック(CB)と呼ばれ得る。上記の様々な例示的な分割実装形態では、結果として得られる各CBは、許容されるサイズおよび分割レベルのいずれかのものであり得る。それらは、そのためのいくつかの基本的なコーディング/デコーディング決定が行われ得、コーディング/デコーディングパラメータが、最適化され、決定され、エンコーディングされたビデオビットストリームにおいてシグナリングされ得るユニットを形成し得るので、コーディングブロックと呼ばれる。最終パーティションにおける最高レベルは、コーディングブロック分割ツリーの深度を表す。コーディングブロックは、ルマコーディングブロックまたはクロマコーディングブロックであり得る。
【0103】
いくつかの他の例示的実装形態では、ベースルマブロックおよびベースクロマブロックを再帰的にコーディングユニットに分割するために四分木構造が使用され得る。そのような分割構造はコーディングツリーユニット(CTU)と呼ばれる場合があり、CTUは、四分木構造を使用して分割をベースCTUの様々なローカル特性に適合させることによってコーディングユニット(CU)に分割される。そのような実装形態では、サイズがピクチャ境界に収まるまでブロックが四分木分割を続けるように、ピクチャ境界で暗黙的な四分木分割が実行され得る。CUという用語は、ルマコーディングブロック(CB)およびクロマコーディングブロック(CB)のユニットを集合的に指すために使用される。
【0104】
いくつかの実装形態では、CBがさらに分割され得る。例えば、CBは、コーディングプロセスおよびデコーディングプロセス中のイントラフレーム予測またはインターフレーム予測を目的として、複数の予測ブロック(PB)にさらに分割され得る。言い換えると、CBは異なるサブパーティションにさらに区分されてもよく、そこで個々の予測決定/構成が行われ得る。並行して、CBは、ビデオデータの変換または逆変換が実行されるレベルを記述する目的で、複数の変換ブロック(TB)にさらに分割され得る。CBのPBおよびTBへの分割方式は、同じである場合もそうでない場合もある。例えば、各分割方式は、例えば、ビデオデータの様々な特性に基づいて独自の手順を使用して実行され得る。PBおよびTBの分割方式は、いくつかの例示的実装形態では独立していてもよい。PBおよびTBの分割方式および境界は、いくつかの他の例示的実装形態では相関していてもよい。いくつかの実装形態では、例えば、TBは、PB分割後に分割されてもよく、特に、各PBは、コーディングブロックの分割の後に続いて決定された後、次いで1つまたは複数のTBにさらに分割されてもよい。例えば、いくつかの実装形態では、PBは、1つ、2つ、4つ、または他の数のTBに分割され得る。
【0105】
いくつかの実装形態では、ベースブロックをコーディングブロックに分割し、さらに予測ブロックおよび/または変換ブロックに分割するために、ルマチャネルおよびクロマチャネルは異なって処理され得る。例えば、いくつかの実装形態では、ルマチャネルに対してはコーディングブロックの予測ブロックおよび/または変換ブロックへの分割が許容され得るが、(1つまたは複数の)クロマチャネルに対してはコーディングブロックの予測ブロックおよび/または変換ブロックへのそのような分割が許容されない場合がある。そのような実装形態では、よって、ルマブロックの変換および/または予測は、コーディングブロックレベルでのみ実行され得る。別の例では、ルマチャネルおよび(1つまたは複数の)クロマチャネルの最小変換ブロックサイズが異なっていてもよく、例えば、ルマチャネルのコーディングブロックは、クロマチャネルよりも小さい変換ブロックおよび/または予測ブロックに分割されることが許容され得る。さらに別の例では、コーディングブロックの変換ブロックおよび/または予測ブロックへの分割の最大深度がルマチャネルとクロマチャネルとの間で異なっていてもよく、例えば、ルマチャネルのコーディングブロックは、(1つまたは複数の)クロマチャネルよりも深い変換ブロックおよび/または予測ブロックに分割されることが許容され得る。具体例として、ルマコーディングブロックは、最大2レベルだけ下がる再帰分割によって表すことができる複数のサイズの変換ブロックに分割されてもよく、正方形、2:1/1:2、4:1/1:4などの変換ブロック形状、および4×4から64×64の変換ブロックサイズが許容され得る。しかしながら、クロマブロックについては、ルマブロックに指定された可能な最大の変換ブロックのみが許容され得る。
【0106】
コーディングブロックをPBに分割するためのいくつかの例示的実装形態では、PB分割の深度、形状、および/または他の特性は、PBがイントラコーディングされるかそれともインターコーディングされるかに依存し得る。
【0107】
コーディングブロック(または予測ブロック)の変換ブロックへの分割は、四分木分割および所定のパターン分割を含むがこれらに限定されない様々な例示的な方式で、再帰的または非再帰的に、コーディングブロックまたは予測ブロックの境界の変換ブロックをさらに考慮して実施され得る。一般に、結果として得られる変換ブロックは、異なる分割レベルにあってもよく、同じサイズでない場合もあり、形状が正方形でなくてもよい(例えば、それらのブロックは、いくつかの許容されるサイズおよびアスペクト比を有する長方形とすることができる)。
【0108】
いくつかの実装形態では、コーディング分割ツリー方式または構造が使用され得る。ルマチャネルとクロマチャネルとに使用されるコーディング分割ツリー方式は、同じでなくてもよい場合がある。言い換えると、ルマチャネルとクロマチャネルとは、別個のコーディングツリー構造を有し得る。さらに、ルマチャネルとクロマチャネルとが同じコーディング分割ツリー構造を使用するか、それとも異なるコーディング分割ツリー構造を使用するかどうか、および使用されるべき実際のコーディング分割ツリー構造は、コーディングされているスライスがPスライスか、Bスライスか、それともIスライスかに依存し得る。例えば、Iスライスの場合、クロマチャネルとルマチャネルとは、別個のコーディング分割ツリー構造またはコーディング分割ツリー構造モードを有し得るが、PスライスまたはBスライスの場合、ルマチャネルとクロマチャネルとは、同じコーディング分割ツリー方式を共有し得る。別個のコーディング分割ツリー構造またはモードが適用される場合、ルマチャネルは、あるコーディング分割ツリー構造によってCBに分割され得、クロマチャネルは、別のコーディング分割ツリー構造によってクロマCBに分割され得る。
【0109】
コーディングブロックおよび変換ブロックの分割の具体的な例示的実装形態を以下で説明する。そのような一例示的実装形態では、ベースコーディングブロックが、上述した再帰的四分木分割を使用してコーディングブロックに分割され得る。各レベルで、特定のパーティションのさらなる四分木分割を続行すべきかどうかが、ローカルビデオデータ特性によって決定され得る。結果として得られるCBは、様々なサイズの様々な四分木分割レベルにあり得る。ピクチャエリアをインターピクチャ(時間的)予測を使用してコーディングするか、それともイントラピクチャ(空間的)予測を使用してコーディングするかの判断は、CBレベル(または、3色チャネルの場合にはCUレベル)で行われ得る。各CBは、PB分割タイプに従って、1つ、2つ、4つ、または他の数のPBにさらに分割され得る。1つのPB内で、同じ予測プロセスが適用されてもよく、関連情報はPBベースでデコーダに送られる。PB分割タイプに基づく予測プロセスを適用することによって残差ブロックを取得した後、CBを、CBのコーディングツリーと同様の別の四分木構造に従ってTBに分割することができる。この特定の実装形態では、CBまたはTBは、正方形状に限定されなくてもよい。さらにこの特定の例では、PBは、インター予測では正方形または長方形の形状であってもよく、イントラ予測では正方形のみであってもよい。コーディングブロックは、例えば4つの正方形形状のTBにさらに分割され得る。各TBは、(四分木分割を使用して)再帰的に、残差四分木(Residual Quad-Tree(RQT))と呼ばれるよりも小さいTBにさらに分割され得る。
【0110】
ベースコーディングブロックをCBおよび他のPBおよびまたはTBに分割するための別の具体例を以下で説明する。例えば、図10に示されるような複数のパーティションユニットタイプ使用するのではなく、二分割および三分割のセグメント化構造を使用するネストされたマルチタイプツリーを有する四分木が使用されてもよい。CB、PB、およびTBの概念の分離(すなわち、CBのPBおよび/またはTBへの分割、ならびにPBのTBへの分割)は、CBがさらなる分割を必要とし得る、最大変換長には大きすぎるサイズを有するCBに必要な場合を除いて、断念されてもよい。この例示的な分割方式は、予測と変換の両方をさらなる分割なしにCBレベルで実行できるように、CB分割形状のより高い柔軟性をサポートするように設計され得る。このようなコーディングツリー構造では、CBは正方形または長方形のどちらかの形状を有し得る。具体的には、コーディングツリーブロック(CTB)が、まず四分木構造によって分割され得る。次いで、四分木のリーフノードは、マルチタイプツリー構造によってさらに分割され得る。図11にマルチタイプツリー構造の一例を示す。具体的には、図11の例示的なマルチタイプツリー構造は、垂直二分割(SPLIT_BT_VER)(1102)、水平二分割(SPLIT_BT_HOR)(1104)、垂直三分割(SPLIT_TT_VER)(1106)、および水平三分割(SPLIT_TT_HOR)(1108)の4つの分割タイプを含む。CBはその場合、マルチタイプツリーのリーフに対応する。この例示的実装形態では、CBが最大変換長に対して大きすぎない限り、このセグメント化は、さらなる分割なしで予測と変換両方の処理に使用される。これは、ほとんどの場合、CB、PB、およびTBが、ネストされたマルチタイプツリーコーディングブロック構造を有する四分木において同じブロックサイズを有することを意味する。例外が発生するのは、サポートされる最大変換長がCBの色成分の幅または高さよりも小さい場合である。
【0111】
1つのCTBのブロック分割のネストされたマルチタイプツリーコーディングブロック構造を有する四分木の一例が図12に示されている。より詳細には、図12は、CTB1200が4つの正方形パーティション1202、1204、1206、および1208に四分木分割されることを示している。分割のために図11のマルチタイプツリー構造をさらに使用する決定は、四分木分割されたパーティションの各々について行われる。図12の例では、パーティション1204はこれ以上分割されない。パーティション1202およびパーティション1208は、別の四分木分割を各々採用する。パーティション1202では、第2レベルの四分木分割された左上パーティション、右上パーティション、左下パーティション、および右下パーティションは、四分木、図11の1104、非分割、および図11の1108の第3レベルの分割をそれぞれ採用する。パーティション1208は別の四分木分割を採用し、第2レベルの四分木分割された左上パーティション、右上パーティション、左下パーティション、および右下パーティションは、図11の1106、非分割、非分割、および図11の1104の第3レベルの分割をそれぞれ採用する。1208の第3レベルの左上パーティションのサブパーティションのうちの2つは、1104および1108に従ってさらに分割される。パーティション1206は、2つのパーティションへの図11の1102による第2レベルの分割パターンを採用し、2つのパーティションは図11の1108および1102に従って第3レベルでさらに分割される。第4レベルの分割が、図11の1104に従ってそれらのうちの1つにさらに適用される。
【0112】
上記の具体例では、最大ルマ変換サイズは64×64であってもよく、サポートされる最大クロマ変換サイズを、ルマとは異なる、例えば32×32とすることもできる。ルマコーディングブロックまたはクロマコーディングブロックの幅または高さが最大変換幅または最大変換高さよりも大きい場合、ルマコーディングブロックまたはクロマコーディングブロックは、水平方向および/または垂直方向の変換サイズ制限を満たすように水平方向および/または垂直方向に自動的に分割され得る。
【0113】
上記のベースコーディングブロックをCBに分割するための具体例では、コーディングツリー方式は、ルマとクロマとが別個のブロックツリー構造を有する能力をサポートし得る。例えば、PスライスおよびBスライスの場合、1つのCTU内のルマCTBとクロマCTBは同じコーディングツリー構造を共有し得る。Iスライスの場合、例えば、ルマとクロマとは別個のコーディングブロックツリー構造を有し得る。別個のブロックツリーモードが適用される場合、ルマCTBは1つのコーディングツリー構造によってルマCBに分割されてもよく、クロマCTBは別のコーディングツリー構造によってクロマCBに分割される。これは、Iスライス内のCUはルマ成分のコーディングブロックまたは2つのクロマ成分のコーディングブロックからなり得、PスライスまたはBスライス内のCUは常に、ビデオがモノクロでない限り3つの色成分すべてのコーディングブロックからなることを意味する。
【0114】
コーディングブロックまたは予測ブロックを変換ブロックに分割するための例示的実装形態、および変換ブロックのコーディング順序を、以下でさらに詳細に説明する。いくつかの例示的実装形態では、変換分割は、例えば4×4から64×64までの範囲の変換ブロックサイズを有する、複数の形状、例えば1:1(正方形)、1:2/2:1、および1:4/4:1の変換ブロックをサポートし得る。いくつかの実装形態では、コーディングブロックが64×64以下の場合、変換ブロック分割は、クロマブロックについては、変換ブロックサイズがコーディングブロックサイズと同一であるように、ルマ成分にのみ適用され得る。そうではなく、コーディングブロックの幅または高さが64よりも大きい場合には、ルマコーディングブロックとクロマコーディングブロックの両方が、それぞれ、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)の変換ブロックの倍数に暗黙的に分割され得る。
【0115】
いくつかの例示的実装形態では、イントラコーディングされたブロックとインターコーディングされたブロックの両方について、コーディングブロックが、所定の数のレベル(例えば、2レベル)までの分割深度を有する複数の変換ブロックにさらに分割され得る。変換ブロックの分割深度およびサイズは、関連し得る。現在の深度の変換サイズから次の深度の変換サイズへの例示的なマッピングを以下で表1に示す。
【0116】
【表1】
【0117】
表1の例示的なマッピングによれば、1:1正方形ブロックの場合、次のレベルの変換分割は、4つの1:1正方形サブ変換ブロックを作成し得る。変換分割は、例えば、4×4で停止し得る。したがって、4×4の現在の深度の変換サイズは、次の深度の4×4の同じサイズに対応する。表1の例では、1:2/2:1の非正方形ブロックの場合、次のレベルの変換分割は2つの1:1の正方形サブ変換ブロックを作成し、1:4/4:1の非正方形ブロックの場合、次のレベルの変換分割は2つの1:2/2:1サブ変換ブロックを作成する。
【0118】
いくつかの例示的実装形態では、イントラコーディングされたブロックのルマ成分に対して、さらなる制限が適用され得る。例えば、変換分割のレベルごとに、すべてのサブ変換ブロックは、等しいサイズを有するように制限され得る。例えば、32×16のコーディングブロックの場合、レベル1の変換分割は、2つの16×16のサブ変換ブロックを作成し、レベル2の変換分割は、8つの8×8のサブ変換ブロックを作成する。言い換えると、変換ユニットを等しいサイズに保つために、第2レベルの分割がすべての第1レベルのサブブロックに適用されなければならない。表1に従ったイントラコーディングされた正方形ブロックのための変換ブロック分割の一例を、矢印で示されたコーディング順序と共に図13に示す。具体的には、1302は正方形コーディングブロックを示している。表1による4つの等しいサイズの変換ブロックへの第1レベルの分割が、矢印で示されたコーディング順序と共に1304に示されている。表1によるすべての第1レベルの等しいサイズのブロックの16個の等しいサイズの変換ブロックへの第2レベルの分割が、矢印で示されたコーディング順序と共に1306に示されている。
【0119】
いくつかの例示的実装形態では、インターコーディングされたブロックのルマ成分に対して、イントラコーディングに対する上記の制限が適用されない場合がある。例えば、第1レベルの変換分割の後に、サブ変換ブロックのいずれか1つが、もう1つのレベルでさらに独立して分割され得る。よって、結果として得られる変換ブロックは、同じサイズのものである場合もそうでない場合もある。インターコーディングされたブロックのコーディング順序を有する変換ブロックへの例示的分割を図14に示す。図14の例では、インターコーディングされたブロック1402は、表1に従って2つのレベルで変換ブロックに分割される。第1レベルで、インターコーディングされたブロックは、等しいサイズの4つの変換ブロックに分割される。次いで、4つの変換ブロックのうちの(それらのすべてではなく)1つのみが4つのサブ変換ブロックにさらに分割され、1404で示されるように、2つの異なるサイズを有する合計7つの変換ブロックが得られる。これらの7つの変換ブロックの例示的なコーディング順序が、図14の1404に矢印で示されている。
【0120】
いくつかの例示的実装形態では、(1つまたは複数の)クロマ成分に対して、変換ブロックについての何らかの追加の制限が適用され得る。例えば、(1つまたは複数の)クロマ成分について、変換ブロックサイズは、コーディングブロックサイズと同じ大きさとすることができるが、所定のサイズ、例えば8×8より小さくすることはできない。
【0121】
いくつかの他の例示的実装形態では、幅(W)または高さ(H)が64よりも大きいコーディングブロックについて、ルマコーディングブロックとクロマコーディングブロックの両方が、それぞれ、min(W,64)×min(H,64)およびmin(W,32)×min(H,32)の変換ユニットの倍数に暗黙的に分割され得る。
【0122】
図15は、コーディングブロックまたは予測ブロックを変換ブロックに分割するための別の代替的な例示的方式をさらに示す。図15に示すように、再帰変換分割を使用する代わりに、コーディングブロックの変換タイプに従って所定の分割タイプのセットがコーディングブロックに適用され得る。図15に示す特定の例では、6つの例示的な分割タイプのうちの1つが、コーディングブロックを様々な数の変換ブロックに分割するために適用され得る。このような方式が、コーディングブロックまたは予測ブロックのどちらかに適用され得る。
【0123】
より詳細には、図15の分割方式は、図15に示すように、任意の所与の変換タイプに対して最大6つの分割タイプを提供する。この方式では、すべてのコーディングブロックまたは予測ブロックに、例えばレート歪みコストに基づいて変換タイプが割り当てられ得る。一例では、コーディングブロックまたは予測ブロックに割り当てられる分割タイプは、コーディングブロックまたは予測ブロックの変換分割タイプに基づいて決定され得る。図15に例示される4つの分割タイプによって示されるように、特定の分割タイプが、変換ブロックの分割サイズおよびパターン(または分割タイプ)に対応し得る。様々な変換タイプと様々な分割タイプとの間の対応関係が、事前定義され得る。例示的な対応関係を、レート歪みコストに基づいてコーディングブロックまたは予測ブロックに割り当てられ得る変換タイプを示す大文字のラベルと共に以下に示す。
【0124】
・PARTITION_NONE:ブロックサイズに等しい変換サイズを割り当てる。
【0125】
・PARTITION_SPLIT:ブロックサイズの1/2の幅、ブロックサイズの1/2の高さの変換サイズを割り当てる。
【0126】
・PARTITION_HORZ:ブロックサイズと同じ幅、ブロックサイズの1/2の高さの変換サイズを割り当てる。
【0127】
・PARTITION_VERT:ブロックサイズの1/2の幅、ブロックサイズと同じ高さの変換サイズを割り当てる。
【0128】
・PARTITION_HORZ4:ブロックサイズと同じ幅、ブロックサイズの1/4の高さの変換サイズを割り当てる。
【0129】
・PARTITION_VERT4:ブロックサイズの1/4の幅、ブロックサイズと同じ高さの変換サイズを割り当てる。
【0130】
上記の例では、図15に示される分割タイプはすべて、分割された変換ブロックについての均一な変換サイズを含む。これは限定ではなく単なる例である。いくつかの他の実装形態では、混合変換ブロックサイズが、特定の分割タイプ(またはパターン)における分割された変換ブロックについて使用され得る。
【0131】
コーディングブロック/ユニットの特定のタイプのシグナリングのいくつかの例示的実装形態を参照すると、各イントラおよびインターコーディングユニットについて、フラグ、すなわちskip_txfmフラグは、表2の例示的な構文に示され、ビットストリームからこれらのフラグを取り出すためのread_skip()関数によって表されるように、コーディングされたビットストリーム内でシグナリングされ得る。このフラグは、変換係数が現在のコーディングユニットにおいてすべてゼロであるかどうかを示し得る。いくつかの例示的実装形態では、このフラグが例えば値1でシグナリングされる場合、別の変換係数関連構文、例えばEOB(End of Block)は、コーディングユニット内のカラーコーディングブロックのいずれに対してもシグナリングされる必要はなく、ゼロ変換係数ブロックに対して事前定義され、それに関連付けられた値またはデータ構造として導出されることができる。インターコーディングブロックの場合、表2の例によって示されるように、このフラグは、様々な理由でコーディングユニットがスキップされ得ることを示すスキップモードフラグの後にシグナリングされ得る。skip_modeが真の場合、コーディングユニットはスキップされるべきであり、skip_txfmフラグをシグナリングする必要はなく、skip_texfmフラグは1と推測される。そうではなく、skip_modeが偽である場合、コーディングブユニットに関するさらなる情報がビットストリームに含まれ、skip_txfmフラグは、コーディングユニットがすべてゼロであるか否かを示すために追加的にシグナリングされる。
【0132】
【表2】
【0133】
【表3】
【0134】
【表4】
【0135】
以下の例示的な実装形態では、クロマチャネルという用語は、一般に、CbおよびCr色成分(またはチャネル)の両方、またはUおよびV色成分(またはチャネル)の両方を指すことができる。ルマチャネルという用語は、ルマ成分またはY成分を含み得る。ルマ成分またはチャネルは、ルマ色成分またはチャネルと呼ばれることがある。以下、Y、U、Vを用いて3つの色成分を表す。さらに、「コーディングされたブロック」および「コーディング」ブロックという用語は、コーディングされるべきブロックまたは既にコーディングされているブロックのいずれかを意味するために交換可能に使用される。これらは、3つの色成分のいずれかのブロックであってもよい。3つの対応するカラーコーディングされた/コーディングブロックは、コーディングされた/コーディングユニットのためのものであってもよい。
【0136】
各色成分における残差の変換係数のコーディングおよびデコーディング(エントロピーコーディング)を参照すると、変換ブロック毎に、変換係数コーディングは、スキップ符号のシグナリングから開始し、スキップ符号がゼロである(非ゼロ係数が存在することを示す)場合、変換カーネルタイプおよびブロック終了(EOB)位置が続く。次に、各係数値は、複数のレベルマップ(振幅マップ)および符号にマッピングされる。
【0137】
EOB位置がコーディングされた後、下位レベルマップおよび中位レベルマップは逆の走査順でコーディングされてもよく、前者は係数の大きさが下位レベル(例えば、0から2の間)内にあるかどうかを示し、後者は範囲が中位レベル(例えば、3から14の間)内にあるかどうかを示す。次のステップは、例えばExp-Golombコードにより、係数の符号と、ハイレベル(例えば、14)より大きい係数の残差値とを順方向走査順でコーディングする。
【0138】
コンテキストモデリングの使用に関して、下位レベルのマップコーディングは、変換サイズおよび方向、ならびに最大5つの隣接係数情報を組み込んでもよい。一方、中位レベルのマップコーディングは、隣接する係数の数がより小さい数(例えば、2)に減少することを除いて、低レベルの振幅コーディングと同様の手法に従うことができる。残差レベルおよびAC係数の符号の例示的なExp-Golombコードは、コンテキストモデルなしでコーディングされ、DC係数の符号は、その隣接する変換ブロックのdc符号を使用してコーディングされる。
【0139】
いくつかの例示的な実装形態において、クロマ残差は、一緒にコーディングされてもよい。そのようなコーディング方式は、クロマチャネル間の何らかの統計的相関に基づいていてもよい。例えば、多くの場合、CrおよびCbクロマ係数は、振幅が類似し、符号が反対であってもよく、したがって、例えば、変換係数がシグナリングされる変換ブロックレベルは、小さな色歪みを導入するだけでコーディング効率を改善するために一緒にエンコーディングされてもよい。共同クロマコーディングモードの使用(起動)は、例えば、共同クロマコーディングフラグ(例えば、TUレベルフラグtu_joint_cbcr_residual_flag)によって示されてもよく、選択された共同モードは、クロマCBFによって暗黙的に示されてもよい。
【0140】
具体的には、TU(変換ブロック)のクロマCBFのいずれかまたは両方が1に等しい場合、フラグtu_joint_cbcr_residual_flagが存在し得る。PPSおよびスライスヘッダにおいて、クロマ量子化パラメータ(QP)オフセット値は、通常のクロマ残差コーディングモードについてシグナリングされるクロマQPオフセット値と区別するために、共同クロマ残差コーディングモードについてシグナリングされ得る。これらのクロマQPオフセット値は、共同クロマ残差コーディングモードを使用してコーディングされたそれらのブロックのクロマQP値を導出するために使用され得る。対応する共同クロマコーディングモード(表3のモード2)がTUにおいてアクティブであるとき、このクロマQPオフセットは、そのTUの量子化およびデコーディング中に適用されたルマ導出のクロマQPに加算され得る。他のモード(表3のモード1および3)の場合、クロマQPは、従来のCbまたはCrブロックの場合と同じ方法で導出され得る。送信された変換ブロックからのクロマ残差(resCbおよびresCr)の再構築プロセスを表3に示す。このモードが起動されると(モード2)、1つの単一の共同クロマ残差ブロック(表3のresJointC[x][y])がシグナリングされ得、変換ブロックレベルではなく、例えばスライスヘッダで指定された符号値であるtu_cbf_cb、tu_cbf_cr、およびCSignなどの情報を考慮して、Cbの残差ブロック(resCb)およびCrの残差ブロック(resCr)が導出され得る。いくつかの実装形態では、CSignはほとんどの時間において-1であり得る。
【0141】
上述した3つの例示的な共同クロマコーディングモードは、イントラコーディングされたCUにおいてのみサポートされ得る。インターコーディングされたCUでは、モード2のみがサポートされ得る。したがって、インターコーディングされたCUの場合、構文要素tu_joint_cbcr_residual_flagは、両方のクロマCBFが1である場合にのみ存在する。
【0142】
【表5】
【0143】
上記の共同クロマコーディング方式は、並置されたCr変換ブロックとCb変換ブロックとの間の変換係数間の何らかの相関を仮定する。これらの仮定は通常統計的であり、したがって、いくつかの状況では歪みをもたらす可能性がある。特に、変換ブロック内の色係数のうちの1つが非ゼロである一方で、別の色成分がゼロの係数を有する場合、共同クロマコーディング方式で行われた仮定の一部は確かにオフになり、そのようなコーディングは、(クロマ係数のうちの1つはいずれにせよゼロであるため)いずれのコーディングされたビットも保存しない。
【0144】
以下の様々な例示的な実装形態では、色成分の並置された変換係数(周波数領域で並置された)間の何らかの相関を利用する係数レベルの(すなわち、変換係数ごとの)クロスコンポーネントコーディング方式が説明される。このような方式は、1つの色成分の係数がゼロであり、別の色成分の対応する変換係数が非ゼロである変換ブロック(またはユニット)に特に有用である。逆量子化の前または後のいずれかの、ゼロおよび非ゼロの色係数のこれらの対について、非ゼロの色係数は、他の色成分のゼロコーディングされた係数の元の小さい値(コーディングプロセスにおける量子化の前には小さい値であるが、元々は非ゼロであり得る)を推定するために使用され得、それによって、場合によっては、例えば、エンコーディング中の量子化プロセスにおいて失われたいくつかの情報を復元する。統計的に存在する色間相関のために、ゼロへの量子化中のいくつかの失われた情報が復元され得る。このようなクロスコンポーネントコーディングは、(ゼロ係数の)著しいコーディングコストなしに、失われた情報をある程度回復する。
【0145】
特に、第1の色成分の係数符号値を利用して第2の色成分の係数符号をコーディングするクロスコンポーネント係数符号コーディング方法が実施され得る。より具体的な一例では、Cb変換係数の符号値は、他のCr変換係数をコーディングするためのコンテキストとして使用されてもよい。そのようなクロスコンポーネントコーディングは、係数ごとに、色成分の変換係数対に対して実施され得る。以下でさらに詳細に説明するそのような実装形態および他の実装形態の根底にある原理は、CrおよびCb成分に限定されない。これらは、3つの色成分のうちの任意の2つの間に適用可能である。この点において、ルマチャネルは色成分の1つと考えられる。
【0146】
以下の例示的実装形態は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。ブロックサイズという用語は、ブロックの幅もしくは高さ、または幅および高さの最大値、または幅および高さの最小値、または領域のサイズ(幅*高さ)、またはアスペクト比(幅:高さ、または高さ:幅)を指すことができる。「レベル値」または「レベル」という用語は、変換係数値の大きさを指すことができる。
【0147】
いくつかの例示的な実装形態において、第1の色成分の変換係数のレベル値および/または符号値は、第2の色成分の変換係数レベル値に加えられるオフセット値を導出するために使用されてもよい。
【0148】
いくつかのさらなる実装形態では、オフセットを生成するために使用される第1の色成分の変換係数および第2の色成分は、並置される(周波数領域における同じ座標、例えば、推定値は非交差周波数である)。
【0149】
上述した第1の色成分および第2の色成分は特定の色成分に限定されなくてもよいが、いくつかの例示的な実装形態では、第1の色成分はCb(またはCr)であってもよく、第2の色成分はCr(またはCb)である。
【0150】
いくつかの特定の例示的な実装形態において、第1の色成分はルマであってもよく、第2の色成分はCbおよびCrのうちの一方であってもよい。
【0151】
いくつかの特定の例示的な実装形態において、第1の色成分はCbおよびCrのうちの一方であってもよく、第2の色成分はルマであってもよい。
【0152】
いくつかの例示的な実装形態では、第1の色成分の量子化変換係数は非ゼロであってもよく、前記第2の色成分の量子化変換係数はゼロであってもよい。したがって、第2の成分の元の変換係数の元の比較的小さい非ゼロ情報は、エンコーディングプロセス中の量子化によって失われる可能性があり、本明細書に記載の例示的な実装形態は、ゼロ係数色成分と統計的に相関され得る対応する非ゼロ色成分を使用していくつかの失われた情報を回復するのに役立つ。
【0153】
いくつかの例示的な実装形態では、第1の色成分の変換係数の符号値を使用して、第2の色成分の逆量子化された変換係数レベル値に加算されるオフセット値を導出し得る。
【0154】
いくつかの例示的な実装形態では、第1の色成分の変換係数の符号値を使用して、逆量子化の前に第2の色成分の変換係数レベル値に加算されるオフセット値を導出する。
【0155】
いくつかの例示的な実装形態では、第1の色成分の変換係数の符号値が正(または負)である場合、第2の色成分の変換係数値を再構築するために、第2の色成分の逆量子化された変換係数レベル値に負の(または正の)オフセット値が加算される。言い換えると、第1の色成分の変換係数の符号値と、第2の色成分の変換係数レベル値に加算されるオフセット値の符号値とは、異なる符号値を有する。そのような実装形態は、2つのクロマ成分が典型的には変換係数について反対の符号を有するという統計的観測と一致し得る。
【0156】
いくつかの例示的な実装形態では、第1の色成分の変換係数の符号値および第2の色成分の変換係数レベル値に加算されるオフセット値の符号値が反対の符号値を有するかどうかは、SPS、VPS、PPS、APS、ピクチャヘッダ、フレームヘッダ、スライスヘッダ、タイルヘッダ、CTUヘッダを含むが、これらに限定されない高レベル構文でシグナリングされる。これは、共同クロマコーディング方式について上述したシグナリング方式と同様である。
【0157】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値は、第1の色成分の変換係数の符号とレベルの両方に依存し得る。
【0158】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値の大きさは、第1の色成分の変換係数に依存し得る。
【0159】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値の大きさは、第1の色成分の変換係数の係数レベルの各入力値に対して予め定義されてもよい。
【0160】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値は、変換係数が位置する周波数に依存し得る。例えば、オフセット値は、より高い周波数係数に対してより小さくてもよい。
【0161】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値は、変換係数が属するブロックのブロックサイズに依存し得る。例えば、オフセット値は、一般に、ブロックサイズが大きいほど小さくてもよい。
【0162】
いくつかの例示的な実装形態では、第2の色成分の変換係数レベル値に加算されるオフセット値は、第2の成分がルマ(Y)成分であるかまたはクロマ(CbもしくはCr)成分であるかに依存し得る。例えば、第2の色成分がルマである場合、オフセット値はより小さくてもよい。
【0163】
図16は、クロスコンポーネントデコーディングのための上記の実装形態の基礎となる原理に従う一例の方法のフローチャート1600を示す。一例の方法フローは1601で開始する。S1610において、コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数が抽出される。S1620において、コーディングされたビデオのビットストリームから第2の色成分の第2の変換係数が抽出される。S1630において、第1の変換係数の大きさまたは符号値に基づいてオフセット値が導出される。S1640において、オフセット値は、第2の色成分のための修正された第2の変換係数を生成するために第2の変換係数の大きさに加算される。S1650において、コーディングされたビデオは、少なくとも第1の色成分の第1の変換係数および第2の色成分の修正された第2の変換係数に基づいて再構築される。一例の方法フローはS1699で終了する。
【0164】
本開示の実施形態は、別々に使用されてもよく、任意の順序で組み合わされてもよい。さらに、方法(または実施形態)の各々、エンコーダ、およびデコーダは、処理回路(例えば、1つもしくは複数のプロセッサまたは1つもしくは複数の集積回路)によって実装されてもよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に格納されたプログラムを実行する。本開示の実施形態は、ルマブロックまたはクロマブロックに適用されてもよい。
【0165】
上記で説明した技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つまたは複数のコンピュータ可読媒体に物理的に格納され得る。例えば、図17は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム(1700)を示す。
【0166】
コンピュータソフトウェアは、1つまたは複数のコンピュータ中央処理装置(CPU:central processing unit)およびグラフィックス処理装置(GPU:Graphics Processing Unit)などによって直接的に、または解釈およびマイクロコードの実行などを介して実行され得る命令を含むコードを生成するために、アセンブリ、コンパイル、リンキング、または同様のメカニズムを受け得る任意の適切なマシンコードまたはコンピュータ言語を使用してコーディングされ得る。
【0167】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはその構成要素上で実行され得る。
【0168】
コンピュータシステム(1700)に関して図17に示されている構成要素は、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関する限定を示唆することを意図されていない。構成要素の構成は、コンピュータシステム(1700)の例示的実施形態に示されている構成要素のいずれかまたは組み合わせに関する依存関係または要件を有すると解釈されるべきではない。
【0169】
コンピュータシステム(1700)は、特定のヒューマンインターフェース入力デバイスを含んでもよい。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力(例えば、キーストローク、スワイプ、データグローブの動き)、音声入力(例えば、声、拍手)、視覚入力(例えば、ジェスチャ)、嗅覚入力(図示せず)を介した、1人または複数の人間のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスを用いて、音声(発話、音楽、周囲音など)、画像(スキャン画像、静止画像カメラから取得される写真画像など)、ビデオ(二次元ビデオ、立体ビデオを含む三次元ビデオなど)など、人間による意識的な入力に必ずしも直接関係ない特定の媒体を取り込むことができる。
【0170】
入力ヒューマンインターフェースデバイスは、キーボード(1701)、マウス(1702)、トラックパッド(1703)、タッチスクリーン(1710)、データグローブ(図示せず)、ジョイスティック(1705)、マイクロフォン(1706)、スキャナ(1707)、カメラ(1708)のうちの1つまたは複数(各々のうちのただ1つ)を含んでもよい。
【0171】
コンピュータシステム(1700)はまた、特定のヒューマンインターフェース出力デバイスを含んでもよい。このようなヒューマンインターフェース出力デバイスは、例えば触覚出力、音、光、および匂い/味によって1人または複数の人間のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス(例えば、タッチスクリーン(1710)、データグローブ(図示せず)、またはジョイスティック(1705)による触覚フィードバックが含まれることがあるが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る)、オーディオ出力デバイス(スピーカ(1709)、ヘッドホン(図示せず)など)、視覚出力デバイス(それぞれがタッチスクリーン入力機能の有無にかかわらず、それぞれが触覚フィードバック機能の有無にかかわらず、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン(1710)などであり、それらの一部は、ステレオグラフィック出力、仮想現実ガラス(図示せず)、ホログラフィックディスプレイおよびスモークタンク(図示せず)などの手段を介して二次元視覚出力または三次元以上の出力が可能であり得る)、およびプリンタ(図示せず)を含んでもよい。
【0172】
コンピュータシステム(1700)はまた、CD/DVDなどの媒体(1721)を伴うCD/DVD ROM/RW(1720)を含む光媒体、サムドライブ(1722)、リムーバブルハードドライブまたはソリッドステートドライブ(1723)、テープやフロッピーディスクなどのレガシー磁気媒体(図示せず)、ならびにセキュリティドングル(図示せず)などの専用のROM/ASIC/PLDベースのデバイスなど、人間がアクセス可能なストレージデバイスおよびこれに関連する媒体含むこともできる。
【0173】
当業者はまた、現在開示されている主題に関連して使用される「コンピュータ可読媒体」という用語が、送信媒体、搬送波、または他の一時的な信号を包含しないことを理解するはずである。
【0174】
コンピュータシステム(1700)はまた、1つまたは複数の通信ネットワーク(1755)へのインターフェース(1754)を含むことができる。ネットワークは、例えば、無線、有線、光であり得る。ネットワークはさらに、ローカル、広域、メトロポリタン、車両および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例には、イーサネット、無線LANなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、および地上波放送テレビを含むテレビ有線または無線広域デジタルネットワーク、CAN busを含む車両および産業用などが含まれる。特定のネットワークは、通常、(例えば、コンピュータシステム(1700)のUSBポートなどの)特定の汎用データポートまたは周辺バス(1749)に取り付けられた外部ネットワークインターフェースアダプタを必要とし、他のネットワークは、通常、以下に記載されるシステムバスに取り付けることによってコンピュータシステム(1700)のコアに統合される(例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース)。これらのネットワークのいずれかを使用して、コンピュータシステム(1700)は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ(例えば、放送TV)、単方向送信のみ(例えば、特定のCANbusデバイスへのCANbus)、または例えばローカルもしくはワイドエリアデジタルネットワークを使用した他のコンピュータシステムに対する双方向のものであり得る。特定のプロトコルおよびプロトコルスタックは、上記で説明したように、それらのネットワークおよびネットワークインターフェースのそれぞれで使用され得る。
【0175】
前述のヒューマンインターフェースデバイス、人間がアクセス可能なストレージデバイス、およびネットワークインターフェースを、コンピュータシステム(1700)のコア(1740)に取り付けることができる。
【0176】
コア(1740)は、1つまたは複数の中央処理装置(CPU)(1741)、グラフィックス処理装置(GPU)(1742)、フィールドプログラマブルゲートエリア(FPGA)(1743)の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ(1744)、グラフィックスアダプタ(1750)などを含むことができる。これらのデバイスは、読み取り専用メモリ(ROM)(1745)、ランダムアクセスメモリ(1746)、ユーザがアクセスすることができない内部ハードドライブ、SSDなどの内部大容量記憶装置(1747)と共に、システムバス(1748)を介して接続され得る。いくつかのコンピュータシステムでは、システムバス(1748)は、追加のCPU、GPUなどによる拡張を可能にするために、1つまたは複数の物理プラグの形態でアクセス可能であり得る。周辺機器を、コアのシステムバス(1748)に直接取り付けることも、周辺バス(1749)を介して取り付けることもできる。一例では、スクリーン(1710)をグラフィックスアダプタ(1750)に接続することができる。周辺バスのアーキテクチャは、PCI、USBなどを含む。
【0177】
CPU(1741)、GPU(1742)、FPGA(1743)、およびアクセラレータ(1744)は、組み合わさって上記のコンピュータコードを形成することができる特定の命令を実行することができる。そのコンピュータコードを、ROM(1745)またはRAM(1746)に格納することができる。また、移行データをRAM(1746)に格納することもでき、永続データを、例えば内部大容量記憶装置(1747)に格納することができる。1つまたは複数のCPU(1741)、GPU(1742)、大容量記憶装置(1747)、ROM(1745)、RAM(1746)などと密接に関連付けることができるキャッシュメモリの使用によって、メモリデバイスのいずれかへの高速記憶および取得を可能にすることができる。
【0178】
コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、またはそれらは、コンピュータソフトウェア技術のスキルを有する人々に周知かつ利用可能な種類であり得る。
【0179】
非限定的な例として、アーキテクチャを有するコンピュータシステム(1700)、特にコア(1740)は、(CPU、GPU、FPGA、アクセラレータなどを含む)(1つまたは複数の)プロセッサが、1つまたは複数の有形のコンピュータ可読媒体において具現化されたソフトウェアを実行した結果として機能を提供することができる。そのようなコンピュータ可読媒体は、上記で紹介したようにユーザがアクセス可能な大容量記憶装置のほか、コア内部大容量記憶装置(1747)またはROM(1745)などの非一時的性質のコア(1740)の特定の記憶装置にも関連する媒体であり得る。本開示の様々な実施形態を実装するソフトウェアを、そのようなデバイスに格納し、コア(2640)によって実行することができる。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア(2640)、具体的にはその中の(CPU、GPU、FPGAなどを含む)プロセッサに、RAM(2646)に格納されたデータ構造を定義すること、およびソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することを含む、本明細書に記載される特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、ソフトウェアの代わりに、またはソフトウェアと共に動作して、本明細書に記載される特定のプロセスまたは特定のプロセスの特定の部分を実行することができる、回路(例えば、アクセラレータ(2644))におけるハードワイヤードの、または他の方法で具現化された論理の結果として機能を提供することもできる。必要に応じて、ソフトウェアへの言及はロジックを包含することができ、その逆も同様である。必要に応じて、コンピュータ可読媒体への言及は、実行のためのソフトウェアを格納する回路(集積回路(IC:integrated circuit)など)、実行のためのロジックを具体化する回路、またはこれらの両方を包含し得る。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。
【0180】
本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある修正例、置換例、および様々な代替均等例がある。上述した実装形態および実施形態では、プロセスの任意の動作が、必要に応じて、任意の量または順序で組み合わされてもよく、または構成されてもよい。また、上述したプロセスの動作の2つ以上が並行して実行されてもよい。したがって、当業者は、本明細書では明示的に示されていないか、または説明されていないが、本開示の原理を具現化し、したがってその趣旨および範囲内にある多数のシステムおよび方法を考案できることが理解されよう。
【0181】
付記A:頭字語
JEM:共同検索モデル
VVC:多用途ビデオコーディング
BMS:ベンチマークセット
MV:動きベクトル
HEVC:高効率ビデオコーディング
SEI:補足拡張情報
VUI:ビデオユーザビリティ情報
GOPs:ピクチャグループ
TUs:変換ユニット
PUs:予測ユニット
CTUs:コーディングツリーユニット
CTBs:コーディングツリーブロック
PBs:予測ブロック
HRD:仮想参照デコーダ
SNR:信号ノイズ比
CPUs:中央処理装置
GPUs:グラフィックス処理装置
CRT:ブラウン管
LCD:液晶ディスプレイ
OLED:有機発光ダイオード
CD:コンパクトディスク
DVD:デジタルビデオディスク
ROM:読み取り専用メモリ
RAM:ランダムアクセスメモリ
ASIC:特定用途向け集積回路
PLD:プログラマブルロジックデバイス
LAN:ローカルエリアネットワーク
GSM:グローバル移動体通信システム
LTE:ロングタームエボリューション
CANBus:コントローラエリアネットワークバス
USB:ユニバーサルシリアルバス
PCI:周辺構成要素相互接続
FPGA:フィールドプログラマブルゲートエリア
SSD:ソリッドステートドライブ
IC:集積回路
HDR:ハイダイナミックレンジ
SDR:標準ダイナミックレンジ
JVET:共同ビデオ検索チーム
MPM:最確モード
WAIP:広角イントラ予測
CU:コーディングユニット
PU:予測ユニット
TU:変換ユニット
CTU:コーディングツリーユニット
PDPC:位置依存予測組み合わせ
ISP:イントラサブパーティション
SPS:シーケンスパラメータ設定
PPS:ピクチャパラメータセット
APS:適応パラメータセット
VPS:ビデオパラメータセット
DPS:デコーディングパラメータセット
ALF:適応ループフィルタ
SAO:サンプル適応オフセット
CC-ALF:クロスコンポーネント適応ループフィルタ
CDEF:コンストレインドディレクショナル・エンハンスメントフィルタ
CCSO:クロスコンポーネントサンプルオフセット
LSO:ローカルサンプルオフセット
LR:ループ復元フィルタ
AV1:AOMedia Video 1
AV2:AOMedia Video 2
【符号の説明】
【0182】
101 サンプル
102 矢印
103 矢印
104 ブロック
180 イントラ予測方向を示す概略図
201 ブロック
202 周囲サンプル
203 周囲サンプル
204 周囲サンプル
205 周囲サンプル
206 周囲サンプル
300 通信システム
310 端末デバイス
320 端末デバイス
330 端末デバイス
340 端末デバイス
350 通信ネットワーク
400 通信システム
401 ビデオソース
402 ビデオピクチャのストリーム
403 ビデオエンコーダ
404 ビデオデータ、ビデオビットストリーム
405 ストリーミングサーバ
406 クライアントサブシステム
407 入力コピー
408 クライアントサブシステム
409 ビデオデータ、コピー
410 ビデオデコーダ
411 出力ストリーム
412 ディスプレイ
413 ビデオキャプチャサブシステム
420 電子デバイス
430 電子デバイス
501 チャネル
510 ビデオデコーダ
512 レンダリングデバイス,ディスプレイ
515 バッファメモリ
520 エントロピーデコーダ/パーサ
521 シンボル
530 電子デバイス
531 受信機
551 スケーラ/逆変換ユニット
552 イントラ予測ユニット、イントラピクチャ予測ユニット
553 動き補償予測ユニット
555 アグリゲータ
556 ループフィルタユニット
557 参照ピクチャメモリ
558 ピクチャバッファ
601 ビデオソース
603 ビデオエンコーダ
620 電子デバイス、エンコーダ
630 ソースコーダ
632 コーディングエンジン
633 デコーダ、デコーディングユニット、ローカルデコーダ
634 参照ピクチャメモリ
635 予測器
640 送信機
643 ビデオシーケンス
645 エントロピーコーダ
650 コントローラ
660 通信チャネル
703 ビデオエンコーダ
721 汎用コントローラ
722 イントラエンコーダ
723 残差計算器
724 残差エンコーダ
725 エントロピーエンコーダ
726 スイッチ
728 残差デコーダ
730 インターエンコーダ
810 ビデオデコーダ
871 エントロピーデコーダ
872 イントラデコーダ
873 残差デコーダ
874 再構築モジュール
880 インターデコーダ
902 ベースブロック
904 ベースブロック
906 ベースブロック
908 ベースブロック
1002 「T型」パーティション、パターン
1004 「T型」パーティション、パターン
1006 「T型」パーティション、パターン
1008 「T型」パーティション、パターン
1102 垂直二分割(SPLIT_BT_VER)
1104 水平二分割(SPLIT_BT_HOR)
1106 垂直三分割(SPLIT_TT_VER)
1108 水平三分割(SPLIT_TT_HOR)
1200 CTB
1202 正方形パーティション
1204 正方形パーティション
1206 正方形パーティション
1208 正方形パーティション
1302 正方形コーディングブロック
1304 第1レベルの分割
1306 第2レベルの分割
1402 インターコーディングされたブロック
1404 7つの変換ブロック
1600 フローチャート
1700 コンピュータシステム
1701 キーボード
1702 マウス
1703 トラックパッド
1705 ジョイスティック
1706 マイクロフォン
1707 スキャナ
1708 カメラ
1709 オーディオ出力デバイススピーカ
1710 タッチスクリーン
1720 CD/DVD ROM/RW
1721 CD/DVDなどの媒体
1722 サムドライブ
1723 リムーバブルハードドライブまたはソリッドステートドライブ
1740 コア
1741 中央処理装置(CPU)
1742 グラフィックス処理装置(GPU)
1743 フィールドプログラマブルゲートエリア(FPGA)
1744 ハードウェアアクセラレータ
1745 読み取り専用メモリ(ROM)
1746 ランダムアクセスメモリ(RAM)
1747 コア内部大容量記憶装置
1748 システムバス
1749 周辺バス
1750 グラフィックスアダプタ
1754 インターフェース
1755 通信ネットワーク
2640 コア
2644 アクセラレータ
図1A
図1B
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
【手続補正書】
【提出日】2023-04-25
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオデコーディングのための方法であって、
コーディングされたビデオのビットストリームから第1の色成分の第1の変換係数を抽出するステップと、
前記コーディングされたビデオの前記ビットストリームから第2の色成分の第2の変換係数を抽出するステップと、
前記第1の変換係数の大きさまたは符号値に基づいてオフセット値を導出するステップと、
前記第2の色成分の修正された第2の変換係数を生成するために、前記第2の変換係数の大きさに前記オフセット値を加算するステップと、
少なくとも前記第1の色成分の前記第1の変換係数および前記第2の色成分の前記修正された第2の変換係数に基づいて前記コーディングされたビデオを再構築するステップと
を含む、方法。
【請求項2】
前記第1の変換係数および前記第2の変換係数が並置される、請求項1に記載の方法。
【請求項3】
前記第1の色成分が1つのクロマ成分を含み、前記第2の色成分が別のクロマ成分を含む、請求項1に記載の方法。
【請求項4】
前記第1の色成分がルマ成分を含み、前記第2の色成分が1つのクロマ成分を含む、請求項1に記載の方法。
【請求項5】
前記第1の色成分が1つのクロマ成分を含み、前記第2の色成分がルマ成分を含む、請求項1に記載の方法。
【請求項6】
前記第1の変換係数が、前記ビットストリームから量子化されたときに非ゼロであり、
前記第2の変換係数が、前記ビットストリームから量子化されたときにゼロである、
請求項1に記載の方法。
【請求項7】
前記第1の変換係数が、符号値および大きさ値を含み、
前記オフセット値を導出するステップが、前記第1の変換係数の前記符号値に基づいて前記オフセット値を導出するステップを含む、
請求項1に記載の方法。
【請求項8】
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化後に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化の前に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、請求項1から7のいずれか一項に記載の方法。
【請求項10】
前記オフセット値が、前記第1の変換係数の符号と反対の符号を有し、
前記第2の変換係数の前記大きさに前記オフセット値を加算するステップが、逆量子化後に前記第2の変換係数の前記大きさに前記オフセット値を加算するステップを含む、
請求項1から7のいずれか一項に記載の方法。
【請求項11】
前記第1の変換係数の符号値と前記オフセット値の符号とが反対であるかどうかが、
ビデオパラメータセット(VPS)、
シーケンスパラメータセット(SPS)、
ピクチャパラメータセット(PPS)、
適応パラメータセット(APS)、
フレームヘッダ、
スライスヘッダ、
コーディングツリーユニットヘッダ、または
タイルヘッダ
のうちの1つでシグナリングされる、請求項1から7のいずれか一項に記載の方法。
【請求項12】
前記オフセット値が、前記第1の変換係数の符号および大きさの両方に依存する、請求項1から7のいずれか一項に記載の方法。
【請求項13】
前記オフセット値の大きさが、前記第1の変換係数の前記大きさに依存する、請求項12に記載の方法。
【請求項14】
前記オフセット値の大きさが、オフセット値の大きさと前記第1の色成分の変換係数の大きさとの間の所定の対応関係を介して事前定義される、請求項12に記載の方法。
【請求項15】
前記オフセット値が、前記第1の変換係数に対応する周波数位置に応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項16】
前記オフセット値が、前記第1の変換係数および前記第2の変換係数が属する変換ブロックのブロックサイズに応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項17】
前記オフセット値が、前記第2の色成分がルマ成分であるかクロマ成分であるかに応じて決定される、請求項1から7のいずれか一項に記載の方法。
【請求項18】
請求項1から17のいずれか一項に記載の方法を行うように構成された、ビデオデコーディングのためのデバイス。
【請求項19】
前記第1の変換係数の量子化係数が非ゼロであり、
前記第2の変換係数の量子化係数がゼロである、
請求項18に記載のデバイス。
【請求項20】
コンピュータに、請求項1から17のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
【国際調査報告】