特許7524387ビデオ符号化又は復号の方法及び装置並びにコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-19
(45)【発行日】2024-07-29
(54)【発明の名称】ビデオ符号化又は復号の方法及び装置並びにコンピュータプログラム
(51)【国際特許分類】
H04N 19/513 20140101AFI20240722BHJP
H04N 19/186 20140101ALI20240722BHJP
H04N 19/105 20140101ALI20240722BHJP
H04N 19/159 20140101ALI20240722BHJP
H04N 19/122 20140101ALI20240722BHJP
【ＦＩ】
H04N19/513
H04N19/186
H04N19/105
H04N19/159
H04N19/122
【請求項の数】
10
【外国語出願】
(21)【出願番号】P 2023036984
(22)【出願日】2023-03-09
(62)【分割の表示】P 2021532208の分割
【原出願日】2020-03-11
(65)【公開番号】P2023071987
(43)【公開日】2023-05-23
【審査請求日】2023-03-09
(31)【優先権主張番号】62/817,517
(32)【優先日】2019-03-12
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジャオ，シン
(72)【発明者】
【氏名】シュイ，シアオジョォン
(72)【発明者】
【氏名】リ，シアン
(72)【発明者】
【氏名】リィウ，シャン
【審査官】久保 光宏
(56)【参考文献】
【文献】特表２０１５－５３７４４８（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１８／０３０２６３１（ＵＳ，Ａ１）
【文献】情報規格調査会，「情報技術の国際標準化と日本の対応 - 2008年度のISO/IEC JTC 1および情報規格調査会の活動 -」，情報処理，日本，情報処理学会，2009年08月15日，Vol.50, No.8，第802-809頁，[令和5年12月25日検索], インターネット, <URL: http://id.nii.ac.jp/1001/00060845/>.
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ１９／００－１９／９８
ＣＳＤＢ（日本国特許庁）
学術文献等データベース（日本国特許庁）
ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）
(57)【特許請求の範囲】
【請求項1】
デコーダがビデオシーケンスを復号する方法であって、4:4:4色差フォーマット及び4:2:2色差フォーマットのうち1つを使用して前記ビデオシーケンスを復号するステップと、
前記4:4:4色差フォーマットを使用して前記ビデオシーケンスを復号する場合、1つの4×4の輝度ブロックのアフィン動きベクトルを、同一位置の4×4の色差ブロックに関連付けるステップと、
前記4:2:2色差フォーマットを使用して前記ビデオシーケンスを復号する場合、1つの4×4の色差ブロックのアフィン動きベクトルが、前記1つの4×4の色差ブロックに対応する2つの4×4の輝度ブロックの動きベクトルの平均になるように、前記2つの4×4の輝度ブロックを前記1つの4×4の色差ブロックに関連付けるステップと
を含み、
前記4:2:2色差フォーマットを使用して前記ビデオシーケンスを復号する場合、最大垂直変換サイズは、異なる色成分の間で同じであり、色差成分についての最大水平変換サイズは、輝度成分についての最大水平変換サイズの半分である、方法。
【請求項2】
色差フォーマットにかかわらず、現在の4×4の色差ブロックを4つの2×2のサブブロックに分割するステップと、左上の2×2の色差サブブロックについて同一位置の輝度ブロックの第1のアフィン動きベクトルを導出するステップと、
右下の2×2の色差ブロックについて同一位置の輝度ブロックの第2のアフィン動きベクトルを導出するステップと、
前記第1のアフィン動きベクトル及び前記第2のアフィン動きベクトルの平均を使用して前記現在の4×4の色差ブロックのアフィン動きベクトルを導出するステップと
を更に含む、請求項１に記載の方法。
【請求項3】
成分Y、Cb及びCrを3つの別個のツリーとして復号するステップを更に含み、前記3つの別個のツリーの各ツリーは、前記成分Y、Cb及びCrのうち1つの成分を復号する、請求項１又は２に記載の方法。
【請求項4】
3つの別個のツリーとして復号する前記ステップは、Iスライス又はIタイルグループについて実行される、請求項３に記載の方法。
【請求項5】
前記4:4:4色差フォーマットを使用して前記ビデオシーケンスを復号する場合、許容される最大変換サイズは、異なる色成分について同じである、請求項１乃至４のうちいずれか１項に記載の方法。
【請求項6】
PDPC(Position-Dependent Predictor combination)、MTS(Multiple Transform Selection)、NSST(Non-Separable Secondary Transform)、ISP(Intra-Sub Partitioning)及びMRL(Multiple reference line)イントラ予測のうち少なくとも1つが、輝度成分及び色差成分の双方に適用される、請求項１乃至５のうちいずれか１項に記載の方法。
【請求項7】
前記MRLイントラ予測が前記輝度成分及び前記色差成分の双方に適用され、前記ビデオシーケンスを復号するステップが前記4:4:4色差フォーマットを使用して実行される場合、イントラ予測のために第Nの参照を選択し、色差成分について明示的な信号伝達なしに同じ参照ラインを使用するステップと、前記ISPが前記輝度成分及び前記色差成分の双方に適用される場合、成分Y、Cb及びCrについてカレントブロックのブロックレベルで前記ISPを適用するステップと、
異なるツリーが異なる色成分に使用される場合、信号伝達なしに、同一位置のY成分からU及びV成分についての符号化パラメータを暗示的に導出するステップと
を更に含む、請求項６に記載の方法。
【請求項8】
ビデオシーケンスを復号するデバイスであって、プログラムコードを記憶するように構成された少なくとも1つのメモリと、
前記プログラムコードを読み取り、請求項１乃至７のうちいずれか１項に記載の方法を実行するように構成された少なくとも1つのプロセッサと
を含むデバイス。
【請求項9】
1つ以上のプロセッサに対して、請求項１乃至７のうちいずれか１項に記載の方法を実行させるコンピュータプログラム。
【請求項10】
エンコーダがビデオシーケンスを符号化する方法であって、4:4:4色差フォーマット及び4:2:2色差フォーマットのうち1つを使用して前記ビデオシーケンスを符号化するステップと、
前記4:4:4色差フォーマットを使用して前記ビデオシーケンスを符号化する場合、1つの4×4の輝度ブロックのアフィン動きベクトルを、同一位置の4×4の色差ブロックに関連付けるステップと、
前記4:2:2色差フォーマットを使用して前記ビデオシーケンスを符号化する場合、1つの4×4の色差ブロックのアフィン動きベクトルが、前記1つの4×4の色差ブロックに対応する2つの4×4の輝度ブロックの動きベクトルの平均になるように、前記2つの4×4の輝度ブロックを前記1つの4×4の色差ブロックに関連付けるステップと
を含み、
前記4:2:2色差フォーマットを使用して前記ビデオシーケンスを符号化する場合、最大垂直変換サイズは、異なる色成分の間で同じであり、色差成分についての最大水平変換サイズは、輝度成分についての最大水平変換サイズの半分である、方法。
【発明の詳細な説明】
【技術分野】
【0001】
［関連出願への相互参照］
本出願は、2019年3月12日に米国特許商標庁に出願された米国仮出願第62/817,517号に基づく35U.S.C.§119に基づく優先権を主張するものであり、当該開示の全内容を参照により援用する。
本出願は、2019年3月12日に米国特許商標庁に出願された米国仮出願第62/817,517号に基づく35U.S.C.§119に基づく優先権を主張するものであり、当該開示の全内容を参照により援用する。
【0002】
［技術分野］
実施形態による方法及び装置は、ビデオ処理に関し、より詳細には、VCC(Versatile Video Coding)における異なる色差フォーマット(例えば、4:4:4、4:2:2)をサポートできるビデオシーケンスを符号化又は復号することに関する。
実施形態による方法及び装置は、ビデオ処理に関し、より詳細には、VCC(Versatile Video Coding)における異なる色差フォーマット(例えば、4:4:4、4:2:2)をサポートできるビデオシーケンスを符号化又は復号することに関する。
【背景技術】
【0003】
最近、ITU(International Telecommunication Union)の部門であるITU-T(ITU Telecommunication Standardization Sector)のVCEG(Video Coding Experts Group)と、ISO(International Organization for Standardization)及びIEC(International Electrotechnical Commission)のJoint Technical Committee ISO/IEC JTC 1の標準化分科会であるISO/IEC MPEG (JTC 1/SC 29/WG 11)は、2013年にH.265/HEVC(High Efficiency Video Coding)標準(バージョン1)を公開した。この標準は、2014年にバージョン2に更新され、2015年にバージョン3に更新され、2016年にバージョン4に更新された。
【0004】
その後、HEVC標準(その拡張を含む)をかなり上回る圧縮能力を有する将来のビデオ符号化技術の標準化の潜在的なニーズを研究している。2017年10月に、HEVCを超える能力を有するビデオ圧縮に関する提案の共同募集(CfP)を発行した。2018年2月15日までに、標準ダイナミックレンジ(SDR, standard dynamic range)に関する合計で22個のCfP回答、高ダイナミックレンジ(HDR, high dynamic range)に関する12個のCfP回答、及び360個のビデオカテゴリに関する12個のCfP回答がそれぞれ提出された。2018年4月に、122 MPEG/10th JVET(Joint Video Exploration Team - Joint Video Expert Team)の会合において、全ての受け取ったCfP回答が評価された。慎重な評価によって、JVETは、HEVCを越える次世代ビデオ符号化の標準化、すなわち、いわゆるVVC(Versatile Video Coding)を正式に開始した。
【0005】
ここで、HEVCブロック分割構造について説明する。HEVCでは、符号化ツリーユニット(CTU, coding tree unit)は、様々な局所特性に適応するために符号化ツリーとして示される四分木構造を使用することにより、符号化ユニット(CU, coding unit)に分割されてもよい。インターピクチャ(時間的)又はイントラピクチャ(空間的)予測を使用してピクチャ領域を符号化するか否かの決定は、CUレベルで行われてもよい。各CUは、PU分割タイプに従って、1つ、2つ又は4つの予測ユニット(PU, prediction unit)に更に分割できる。1つのPUの内部では、同じ予測プロセスが適用されてもよく、関連情報がPUベースでデコーダに送信されてもよい。PU分割タイプに基づく予測プロセスを適用することによって残差ブロックを取得した後に、CUは、CUについての符号化ツリーのような他の四分木構造に従って変換ユニット(TU, transform unit)に分割できる。HEVC構造の特徴は、CU、PU及びTUを含む複数の分割概念を含んでもよいことである。HEVCでは、CU又はTUは、一般的には正方形の形状のみとすることができるが、PUは、インター予測ブロックについて正方形又は長方形の形状でもよい。HEVCでは、1つの符号化ブロックは4つの正方形サブブロックに更に分割されてもよく、変換は各サブブロック、すなわち、TUに対して実行されてもよい。各TUは、より小さいTUに再帰的に(四分木分割を使用して)更に分割できる。これは残差四分木(RQT, Residual Quad-Tree)と呼ばれる。
【0006】
ピクチャ境界では、HEVCは、サイズがピクチャ境界に合うまでブロックが四分木分割を保持するように、暗黙の四分木分割を使用する。
【0007】
ここで、四分木(QT, quad-tree)+二分木(BT, binary tree)を使用したブロック分割構造について説明する。HEVCでは、CTUは、様々な局所特性に適応するために符号化ツリーとして示される四分木構造を使用することにより、CUに分割されてもよい。インターピクチャ(時間的)又はイントラピクチャ(空間的)予測を使用してピクチャ領域を符号化するか否かの決定は、CUレベルで行われてもよい。各CUは、PU分割タイプに従って、1つ、2つ又は4つのPUに更に分割できる。1つのPUの内部では、同じ予測プロセスが適用されてもよく、関連情報がPUベースでデコーダに送信されてもよい。PU分割タイプに基づく予測プロセスを適用することによって残差ブロックを取得した後に、CUは、CUについての符号化ツリーのような他の四分木構造に従って変換ユニット(TU, transform unit)に分割できる。HEVC構造の特徴は、CU、PU及びTUを含む複数の分割概念を含んでもよいことである。
【0008】
QTBT構造は、複数の分割タイプの概念を除去し、すなわち、CU、PU及びTUの概念の分離を除去し、CU分割の形状に対してより高い柔軟性をサポートする。QTBTブロック構造では、CUは正方形又は長方形のいずれかの形状を有することができる。図１Ａに示すように、符号化ツリーユニット(CTU, coding tree unit)は、まず、四分木構造によって分割される。次いで、四分木リーフノードは、二分木構造によって更に分割されてもよい。二分木分割には、対称的水平分割及び対称的垂直分割の2つの分割タイプが存在し得る。二分木リーフノードは、符号化ユニット(CU, coding unit)と呼ばれ、そのセグメント分けは、更なる分割なしに予測及び変換処理に使用されてもよい。これは、CU、PU及びTUがQTBT符号化ブロック構造において同じブロックサイズを有することを意味する。JEMでは、CUは、場合によっては、異なる色成分の符号化ブロック(CB, coding block)で構成されてもよい。例えば、1つのCUは、4:2:0色差フォーマットのPスライス及びBスライスの場合に1つの輝度CB及び2つの色差CBを含んでもよく、単一成分のCBを含んでもよい。例えば、1つのCUは、Iスライスの場合に1つの輝度CBのみ又は2つの色差CBのみを含んでもよい。
【0009】
QTBT分割方式について以下のパラメータが定義されている。
CTUサイズ:HEVCと同じ概念の四分木のルートノードサイズ
MinQTSize:許容される最小の四分木リーフノードサイズ
MaxBTSize:許容される最大の二分木ルートノードサイズ
MaxBTDepth:許容される最大の二分木の深度
MinBTSize:許容される最小の二分木リーフノードサイズ
CTUサイズ:HEVCと同じ概念の四分木のルートノードサイズ
MinQTSize:許容される最小の四分木リーフノードサイズ
MaxBTSize:許容される最大の二分木ルートノードサイズ
MaxBTDepth:許容される最大の二分木の深度
MinBTSize:許容される最小の二分木リーフノードサイズ
【0010】
QTBT分割構造の一例では、CTUサイズは、2つの対応する64×64のブロックの色差サンプルを有する128×128の輝度サンプルとして設定されてもよく、MinQTSizeは16×16として設定されてもよく、MaxBTSizeは64×64として設定されてもよく、MinBTSize(幅及び高さの双方)は4×4として設定されてもよく、MaxBTDepthは4として設定されてもよい。四分木分割は、まず、四分木リーフノードを生成するためにCTUに適用されてもよい。四分木リーフノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを有してもよい。リーフ四分木ノードが128×128である場合、サイズがMaxBTSize(すなわち、64×64)を超えるので、二分木によって更に分割されない。そうでない場合、リーフ四分木ノードは、二分木によって更に分割されてもよい。したがって、四分木リーフノードは、二分木のルートノードでもあり、0としての二分木深度を有してもよい。二分木深度がMaxBTDepth(すなわち、4)に達した場合、更なる分割は考慮されない。二分木ノードがMinBTSize(すなわち、4)に等しい幅を有する場合、更なる水平分割は考慮されない。同様に、二分木ノードがMinBTSizeに等しい高さを有する場合、更なる垂直分割は考慮されない。二分木のリーフノードは、更なる分割なしに予測及び変換処理によって更に処理されてもよい。JEMでは、最大CTUサイズは256×256の輝度サンプルでもよい。
【0011】
図１Ａは、QTBTを使用することによるブロック分割の例を示し、図１Ｂは、対応するツリー表現を示す。実線は四分木分割を示し、点線は二分木分割を示す。二分木の各分割(すなわち、非リーフ)ノードにおいて、どの分割タイプ(すなわち、水平又は垂直)が使用され得るかを示すために、1つのフラグが伝達されてもよく、0は水平分割を示し、1は垂直分割を示す。四分木分割では、四分木分割は、等しいサイズを有する4つのサブブロックを生成するために、ブロックを水平と垂直との双方に分割するので、分割タイプを示す必要はない。
【0012】
さらに、QTBT方式は、輝度及び色差が別個のQTBT構造を有するような柔軟性をサポートする。現在、P及びBスライスについて、1つのCTU内の輝度及び色差CTBは同じQTBT構造を共有する。しかし、Iスライスについては、輝度CTBはQTBT構造によってCUに分割されてもよく、色差CTBは他のQTBT構造、すなわち、DualTree(DT)構造によって色差CUに分割されてもよい。これは、Iスライス内のCUが輝度成分の符号化ブロック、又は2つの色差成分の符号化ブロックで構成され、P又はBスライス内のCUが全ての3つの色成分の符号化ブロックで構成されることを意味する。
【0013】
HEVCでは、動き補償のメモリアクセスを低減するために、小さいブロックについてのインター予測が制限されてもよく、双方向予測が4×8及び8×4のブロックでサポートされず、インター予測が4×4のブロックでサポートされない。JEM-7.0で実装されているQTBT方式では、これらの制限が除去される可能性がある。
【0014】
ここで、三値ツリー(TT, ternary tree)を使用したブロック分割について説明する。マルチタイプツリー(MTT, Multi-type-tree)構造が提案されている。MTTはQTBTよりも柔軟なツリー構造である。MTTでは、図２Ａ及び２Ｂに示すように、四分木及び二分木以外に、水平及び垂直の中央側の三分木が導入されている。
【0015】
三分木分割のいくつかの利点は、以下のものを含む。四分木及び二分木分割に対する補足を提供する。三分木分割は、四分木及び二分木がブロック中心で分割され得る一方で、ブロック中心に位置するオブジェクトをキャプチャすることができる。三分木の分割の幅及び高さは2のべき乗になり得るので、更なる変換は必要ない。2レベルツリーの設計は、主に複雑性の低減によって動機づけられる。理論的には、ツリーのトラバースの複雑さはT^Dであり、Tは分割タイプの数であり、Dはツリーの深度である。
【0016】
ここで、YUVフォーマットについて説明する。異なるYUVフォーマット、すなわち、色差フォーマットが図３に示されている。異なる色差フォーマットは、異なる色成分の異なるダウンサンプリンググリッドを定義する。
【0017】
ここで、クロスコンポーネント線形モデリング(CCLM, cross-component linear modeling)について説明する。VTMでは、イントラPUの色差成分について、エンコーダは、プラナー(planar)、DC、水平、垂直、輝度成分からのイントラ予測モードの直接コピー(DM)、左上クロスコンポーネント線形モード(LT_CCLM, Left and Top Cross-component Linear Mode)、左側クロスコンポーネント線形モード(L_CCLM, Left Cross-component Linear Mode)、及び上側クロスコンポーネント線形モード(T_CCLM, Top Cross-component Linear Mode)を含む8つのモードの中から最良の色差予測モードを選択する。これらのモードのうち、LT_CCLM、L_CCLM及びT_CCLMは、クロスコンポーネント線形モード(CCLM, Cross-component Linear Mode)として分類できる。これら3つのモードの違いは、パラメータα及びβを導出するために隣接サンプルの異なる領域が使用され得ることである。LT_CCLMでは、左側及び上側の隣接サンプルの双方がパラメータα及びβを導出するために使用されてもよい。L_CCLMでは、左側の隣接サンプルのみがパラメータα及びβを導出するために使用される。T_CCLMでは、上側の隣接サンプルのみがパラメータα及びβを導出するために使用される。
【0018】
クロコンポーネント線形モデル(CCLM)予測モードは、色差成分の冗長性を低減するために使用されてもよく、色差サンプルは、以下の線形モデルを使用することによって、同じCUの復元された輝度サンプルに基づいて予測されてもよい。
predc(i,j)=αrecL’(i,j)+β (式1)
predc(i,j)=αrecL’(i,j)+β (式1)
【0019】
ここで、predc(i,j)は、CU内の予測される色差サンプルを表し、recL’(i,j)は、同じCUのダウンサンプリングされた復元された輝度サンプルを表す。パラメータα及びβは、直線的な式、例えば、max-min法によって導出されてもよい。この計算プロセスは、エンコーダ探索動作としてだけではなく、復号プロセスの一部として実行されてもよく、そのため、α及びβの値を伝達するためにシンタックスは使用されない。
【0020】
色差4:2:0フォーマットについて、CCLM予測は、図３に示すように、色差サンプルに対応するダウンサンプリングされた輝度サンプルを取得するために、6タップ補間フィルタを適用する。ここで、復元された輝度サンプルからダウンサンプリングされた輝度サンプルRec’L[x,y]が計算されてもよい。
【0021】
ダウンサンプリングされた輝度サンプルは、最大及び最小のサンプル点を見つけるために使用されてもよい。2つの点(輝度及び色差の結合)(A,B)は、図４に示すように、隣接する輝度サンプルの集合内の最小値及び最大値でもよい。ここで、線形モデルパラメータα及びβは、以下の式に従って取得されてもよい。
【数1】
【0022】
ここで、除算が回避され、乗算及びシフトによって置き換えられてもよい。ルックアップテーブル(LUT, Look-up Table)が予め計算された値を記憶するために使用されてもよく、最大輝度サンプルと最小輝度サンプルとの間の絶対差値がLUTのエントリインデックスを指定するために使用されてもよく、LUTのサイズは512でもよい。
【0023】
T_CCLMモードでは、図５Ａ及び５Ｂに示す隣接サンプル(2*Wのサンプルを含む)のみが線形モデル係数を計算するために使用されてもよい。
【0024】
L_CCLMモードでは、図６Ａ及び６Ｂに示すように、左側隣接サンプル(2*Hのサンプルを含む)のみが線形モデル係数を計算するために使用されてもよい。
【0025】
また、CCLM予測モードは、2つの色差成分の間の予測を含む。すなわち、Cr成分はCb成分から予測されてもよい。復元されたサンプル信号を使用する代わりに、CCLM Cb-to-Cr予測が残差領域に適用されてもよい。これは、最終的なCr予測を形成するために、元のCrイントラ予測に重み付けされた復元後のCb残差を加えることによって実施されてもよい。
predcr*(i,j)=predcr(i,j)+αresicb’(i,j) (式4)
predcr*(i,j)=predcr(i,j)+αresicb’(i,j) (式4)
【0026】
CCLM luma-to-chroma予測モードは、1つの更なる色差イントラ予測モードとして追加されてもよい。エンコーダ側では、色差イントラ予測モードを選択するために、色差成分について1つの更なるRDコスト検査が追加されてもよい。CCLM luma-to-chroma予測モード以外のcbイントラ予測モードがCUの色差成分に使用され得る場合、CCLM Cb-to-Cr予測はCr成分の予測に使用されてもよい。
【0027】
多重モデルCCLM(MMLM, Multiple Model CCLM)は、CCLMの他の拡張である。名称によって示されるように、MMLMには1つより多くのモデルが存在してもよく、例えば、2つのモデルが使用されてもよい。MMLMでは、カレントブロックの隣接輝度サンプル及び隣接色差サンプルは2つのグループに分類されてもよく、各グループは線形モデルを導出するためのトレーニングセットとして使用されてもよい(すなわち、特定のα及びβは特定のグループについて導出されてもよい)。さらに、カレント輝度ブロックのサンプルは、隣接輝度サンプルの分類のための同じルールに基づいて分類されてもよい。
【0028】
図８は、隣接サンプルを2つのグループに分類する例を示す。閾値は、隣接する復元された輝度サンプルの平均値として計算されてもよい。Rec’L[x,y]<=Thresholdを有する隣接サンプルはグループ1に分類されてもよく、Rec’L[x,y]>Thresholdを有する隣接サンプルはグループ2に分類されてもよい。
【数2】
【0029】
ここで、アフィン動き補償予測について説明する。HEVCでは、並進動きモデルが動き補償予測(MCP, motion compensation prediction)に適用されてもよい。しかし、ズームイン/アウト、回転、斜視の動き及び他の不規則な動きのように、多くの種類の動きが存在し得る。VTM4では、ブロックベースのアフィン変換動き補償予測が適用されてもよい。図９に示すように、ブロックのアフィンモーションフィールド(affine motion field)は、2つの制御点動きベクトル(4パラメータ)又は3つの制御点動きベクトル(6パラメータ)の動き情報によって記述されてもよい。
【0030】
4パラメータのアフィン動きモデルについて、ブロック内のサンプル位置(x,y)における動きベクトルは以下のように導出されてもよい。
【数3】
【0031】
6パラメータのアフィン動きモデルについて、ブロック内のサンプル位置(x,y)における動きベクトルは以下のように導出されてもよい。
【数4】
【0032】
ここで、mv0x,mv0yは左上角の制御点の動きベクトルであり、mv1x,mv1yは右上角の制御点の動きベクトルであり、mv2x,mv2yは左下角の制御点の動きベクトルである。
【0033】
動き補償予測を簡略化するために、ブロックベースのアフィン変換予測が適用されてもよい。それぞれの4×4の輝度サブブロックの動きベクトルを導出するために、図１０に示すように、各サブブロックの中心サンプルの動きベクトルは、上記の式に従って計算され、1/16の分数精度に丸められてもよい。次いで、動き補償補間フィルタが、導出された動きベクトルを有する各サブブロックの予測を生成するために適用されてもよい。色差成分のサブブロックサイズも4×4に設定されてもよい。4×4の色差サブブロックのMVは、4つの対応する4×4の輝度サブブロックのMVの平均として計算されてもよい。並進動きインター予測について行われるように、アフィンマージモード及びアフィンAMVPモードの2つのアフィン動きインター予測モードが存在してもよい。
【0034】
ここで、アフィンマージ予測について説明する。AF_MERGEモードは8以上の幅及び高さを有するCUに適用されてもよい。このモードでは、カレントCUのCPMVは、空間的に隣接するCUの動き情報に基づいて生成されてもよい。5つまでのCPMVP候補が存在してもよく、カレントCUに使用されるものを示すために1つのインデックスが伝達されてもよい。以下の3つのタイプのCPVM候補が、アフィンマージ候補リストを形成するために使用されてもよい。
(1)隣接CUのCPMVから外挿された継承アフィンマージ候補(inherited affine merge candidate)
(2)隣接CUの並進MVを使用して導出され得る構築アフィンマージ候補CPMVP(constructed affine merge candidate)
(3)ゼロのMV。
(1)隣接CUのCPMVから外挿された継承アフィンマージ候補(inherited affine merge candidate)
(2)隣接CUの並進MVを使用して導出され得る構築アフィンマージ候補CPMVP(constructed affine merge candidate)
(3)ゼロのMV。
【0035】
VTM4では、左側隣接CUから1つ及び上側隣接CUから1つの、最大で2つの継承アフィン候補が存在してもよく、これらは、隣接ブロックのアフィン動きモデルから導出されてもよい。候補ブロックが図１１に示されている。左側予測子については、走査順序はA0->A1でもよく、上側予測子については、走査順序はB0->B1->B2でもよい。各辺から最初に継承した候補が選択されてもよい。2つの継承した候補の間でプルーニング(pruning)検査が実行される必要はない。隣接するアフィンCUが識別された場合、その制御点動きベクトルは、カレントCUのアフィンマージリストにおけるCPMVP候補を導出するために使用されてもよい。図１２に示すように、隣接する左下ブロックAがアフィンモードで符号化される場合、ブロックAを含むCUの左上角、右上角及び左下角の動きベクトルv2、v3及びv4が得られてもよい。ブロックAが4パラメータのアフィンモデルで符号化される場合、カレントCUの2つのCPMVはv2及びv3に従って計算されてもよい。ブロックAが6パラメータのアフィンモデルで符号化され得る場合、カレントCUの3つのCPMVは、v2、v3及びv4に従って計算されてもよい。
【0036】
構築アフィン候補は、候補が各制御点の隣接並進動き情報を組み合わせることによって構築されてもよいことを意味する。制御点の動き情報は、図１３に示す指定の空間隣接及び時間隣接から導出されてもよい。CPMVk(k=1,2,3,4)は、第kの制御点を表す。CPMV1については、B2->B3->A2のブロックが検査されてもよく、最初に利用可能なブロックのMVが使用されてもよい。CPMV2については、B1->B0のブロックが検査されてもよく、CPMV3については、A1->A0のブロックが検査されてもよい。TMVPが利用可能な場合は、CPMV4として使用される。
【0037】
4つの制御点のMVが得られた後に、アフィンマージ候補がその動き情報に基づいて構築されてもよい。制御点MVの組み合わせ{CPMV1,CPMV2,CPMV3}、{CPMV1,CPMV2,CPMV4}、{CPMV1,CPMV3,CPMV4}、{CPMV2,CPMV3,CPMV4}、{CPMV1,CPMV2}及び{CPMV1,CPMV3}が順に構築するために使用されてもよい。
【0038】
3つのCPMVの組み合わせは6パラメータのアフィンマージ候補を構築し、2つのCPMVの組み合わせは4パラメータのアフィンマージ候補を構築する。動きスケーリングプロセスを回避するために、制御点の参照インデックスが異なる場合、制御点MVの関連する組み合わせが破棄されてもよい。
【0039】
継承アフィンマージ候補及び構築アフィンマージ候補が検査された後に、リストがまだ満たされていない場合、ゼロのMVがリストの最後に挿入されてもよい。
【0040】
ここで、アフィンAMVP予測について説明する。アフィンAMVPモードは、16以上の幅及び高さの双方を有するCUに適用できる。CUレベルのアフィンフラグは、アフィンAMVPモードが使用されるべきか否かを示すためにビットストリームで伝達されてもよく、他のフラグは、4パラメータのアフィンが使用されるべきか6パラメータのアフィンが使用されるべきかを示すために伝達されてもよい。このモードでは、カレントCUのCPMVとこれらの予測子CPMVPとの差はビットストリームで伝達されてもよい。アフィンAVMP候補リストのサイズは2でもよく、以下の4つのタイプのCPVM候補を順に使用することによって生成されてもよい。
(1)隣接CUのCPMVから外挿され得る継承アフィンAMVP候補
(2)隣接CUの並進MVを使用して導出され得る構築アフィンAMVP候補CPMVP
(3)隣接CUからの並進MV
(4)ゼロのMV
(1)隣接CUのCPMVから外挿され得る継承アフィンAMVP候補
(2)隣接CUの並進MVを使用して導出され得る構築アフィンAMVP候補CPMVP
(3)隣接CUからの並進MV
(4)ゼロのMV
【0041】
継承アフィンAMVP候補の検査順序は、継承アフィンマージ候補の検査順序と同じでもよい。相違点は、AVMP候補について、カレントブロックと同じ参照ピクチャを有するアフィンCUが考慮されてもよいことである。継承アフィンモーション予測子を候補リストに挿入する場合、プルーニング処理は適用される必要はない。
【0042】
構築AMVP候補は、図１３に示す指定の空間隣接から導出されてもよい。アフィンマージ候補構築において実行される順序と同じ検査順序が使用されてもよい。さらに、隣接ブロックの参照ピクチャインデックスも検査されてもよい。検査順序における、カレントCUと同じ参照ピクチャを有し、インター符号化されてもよい最初のブロックが使用されてもよい。カレントCUが4パラメータのアフィンモードで符号化され、mv0及びmv1の双方が利用可能になり得る場合、これらはアフィンAMVPリストにおける1つの候補として追加されてもよい。カレントCUが6パラメータのアフィンモードで符号化され、全ての3つのCPMVが利用可能な場合、これらはアフィンAMVPリストにおける1つの候補として追加されてもよい。そうでない場合、構築AMVP候補は利用不可能として設定される。
【0043】
アフィンAMVPリスト候補が、継承アフィンAMVP候補及び構築AMVP候補が検査された後に依然として2未満である場合、利用可能である場合にはカレントCUの全ての制御点MVを予測するための並進MVとして、mv0、mv1及びmv2が順に追加される。最後に、アフィンAMVPリストが依然として満たされていない場合、ゼロのMVがアフィンAMVPリストを充填するために使用されてもよい。
【0044】
ここで、アフィン動き情報の記憶について説明する。VTM4では、アフィンCUのCPMVは別のバッファに記憶されてもよい。記憶されたCPMVは、最後に符号化されたCUについてのアフィンマージモード及びアフィンAMVPモードにおいて、継承CPMVPを生成するために使用されてもよい。CPMVから導出されたサブブロックMVは、動き補償、並進MVのマージ/AMVPリストのMV導出、及びデブロッキングに使用されてもよい。
【0045】
更なるCPMVについてのピクチャラインバッファを回避するために、上側CTUからのCUからのアフィン動きデータ継承は、通常の隣接CUからの継承とは異なって扱われてもよい。アフィン動きデータ継承についての候補CUが上側CTUラインにある場合、CPMVの代わりにラインバッファ内の左下及び右下のサブブロックMVがアフィンMVP導出に使用されてもよい。このように、CPMVはローカルバッファに記憶されてもよい。候補CUが6パラメータアフィン符号化されている場合、アフィンモデルは4パラメータモデルに低下してもよい。図１４に示すように、上側CTU境界に沿って、CUの左下及び右下サブブロックの動きベクトルが、下側CTUにおけるCUのアフィン継承に使用されてもよい。
【0046】
上述の進展にもかかわらず、VTM-4.0では、アフィン符号化された符号化ブロックにおける4×4の色差サブブロックのMVは、4つの対応する4×4の輝度サブブロックのMVの平均として計算される。しかし、色差4:4:4及び4:2:2のフォーマットについて、それぞれの4×4の色差サブブロックは、1つ又は2つの4×4の輝度サブブロックに関連付けられており、4×4の色差成分についてのMV導出の現在の方式は、色差4:4:4及び4:2:2フォーマットの場合に対応するために改善の余地がある。
【発明の概要】
【0047】
本開示の態様によれば、ビデオシーケンスを符号化又は復号する方法は、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号するステップ、又は4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号するステップを含んでもよく、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号する場合、当該方法は、平均演算以外の演算を使用して、1つの4×4の色差ブロックのアフィン動きベクトルをコピーするステップを更に含んでもよく、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号する場合、当該方法は、それぞれの4×4の色差ブロックを2つの4×4の同一位置の色差ブロックに関連付けることにより、1つの4×4の色差ブロックのアフィン動きベクトルが、2つの同一位置の色差ブロックの動きベクトルの平均になるようにするステップを更に含んでもよい。
【0048】
本開示の態様によれば、当該方法は、色差フォーマットにかかわらず、現在の4×4の色差ブロックを4つの2×2のサブブロックに分割するステップと、左上の2×2の色差サブブロックについて同一位置の輝度ブロックの第1のアフィン動きベクトルを導出するステップと、右下の2×2の色差ブロックについて同一位置の輝度ブロックの第2のアフィン動きベクトルを導出するステップと、第1のアフィン動きベクトル及び第2のアフィン動きベクトルの平均を使用して現在の4×4の色差ブロックのアフィン動きベクトルを導出するステップとを更に含んでもよい。
【0049】
本開示の態様によれば、当該方法は、輝度成分と色差成分との間の動き補償に使用される補間フィルタを調整するステップを含んでもよい。
【0050】
本開示のこの態様によれば、ビデオシーケンスが4:2:0色差フォーマットを使用して入力される場合、当該方法は、輝度成分及び色差成分に8タップ補間フィルタを適用するステップを更に含んでもよい。
【0051】
本開示の態様によれば、当該方法は、成分Y、Cb及びCrを3つの別個のツリーとして符号化するステップを更に含んでもよく、3つの別個のツリーの各ツリーは、成分Y、Cb及びCrのうち1つの成分を符号化する。
【0052】
本開示のこの態様によれば、3つの別個のツリーとしての符号化は、Iスライス又はIタイルグループについて実行されてもよい。
【0053】
本開示の態様によれば、許容される最大変換サイズは、異なる色成分について同じでもよい。
【0054】
本開示のこの態様によれば、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号する場合、最大垂直サイズは、異なる色成分の間で同じでもよく、色差成分についての最大水平変換サイズは、輝度成分についての最大水平変換サイズの半分でもよい。
【0055】
本開示の態様によれば、位置依存予測子組み合わせ(PDPC, Position-Dependent Predictor combination)、多重変換選択(MTS, Multiple Transform Selection)、分離不可能二次変換(NSST, Non-Separable Secondary Transform)、イントラ部分分割(ISP, Intra-Sub Partitioning)及び多重参照ライン(MRL, Multiple reference line)イントラ予測のうち少なくとも1つが、輝度成分及び色差成分の双方に適用されてもよい。
【0056】
本開示のこの態様によれば、多重参照ライン(MRL)イントラ予測が輝度成分及び色差成分の双方に適用され、ビデオシーケンスを符号化又は復号するステップが4:4:4色差フォーマットを使用して実行される場合、当該方法は、イントラ予測のために第Nの参照を選択し、色差成分について明示的な信号伝達なしに同じ参照ラインを使用するステップを更に含んでもよく、イントラ部分分割(ISP)が輝度成分及び色差成分の双方に適用される場合、当該方法は、成分Y、Cb及びCrについてカレントブロックのブロックレベルでイントラ部分分割(ISP)を適用するステップを更に含んでもよく、異なるツリーが異なる色成分に使用される場合、当該方法は、信号伝達なしに、同一位置のY成分からU及びV成分についての符号化パラメータを暗示的に導出するステップを更に含んでもよい。
【0057】
本開示の態様によれば、ビデオシーケンスを符号化又は復号するデバイスは、プログラムコードを記憶するように構成された少なくとも1つのメモリと、プログラムコードを読み取り、プログラムコードによって命令された通りに動作するように構成された少なくとも1つのプロセッサとを含んでもよく、プログラムコードは、少なくとも1つのプロセッサに対して、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように、或いは、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように構成された第1の符号化又は復号コードを含み、第1の符号化又は復号コードが、少なくとも1つのプロセッサに対して、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように構成される場合、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、平均演算以外の演算を使用して、1つの4×4の色差ブロックのアフィン動きベクトルをコピーさせるように構成されたコードを更に含んでもよく、第1の符号化又は復号コードが、少なくとも1つのプロセッサに対して、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように構成される場合、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、それぞれの4×4の色差ブロックを2つの4×4の同一位置の色差ブロックに関連付けることにより、1つの4×4の色差ブロックのアフィン動きベクトルが、2つの同一位置の色差ブロックの動きベクトルの平均になるようにさせるように構成されたコードを更に含んでもよい。
【0058】
本開示の態様によれば、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、現在の4×4の色差ブロックを4つの2×2のサブブロックに分割させ、左上の2×2の色差サブブロックについて同一位置の輝度ブロックの第1のアフィン動きベクトルを導出させ、右下の2×2の色差ブロックについて同一位置の輝度ブロックの第2のアフィン動きベクトルを導出させ、第1のアフィン動きベクトル及び第2のアフィン動きベクトルの平均を使用して現在の4×4の色差ブロックのアフィン動きベクトルを導出させるように構成されたコードを更に含んでもよい。
【0059】
本開示の態様によれば、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、輝度成分と色差成分との間の動き補償に使用される補間フィルタを調整させるように構成されたコードを更に含んでもよい。
【0060】
本開示のこの態様によれば、第1の符号化又は復号コードが、少なくとも1つのプロセッサに対して、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように構成される場合、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、輝度成分及び色差成分に8タップ補間フィルタを適用させるように構成されたコードを更に含んでもよい。
【0061】
本開示の態様によれば、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、成分Y、Cb及びCrを3つの別個のツリーとして符号化させるように構成されたコードを更に含んでもよく、3つの別個のツリーの各ツリーは、成分Y、Cb及びCrのうち1つの成分を符号化する。
【0062】
本開示のこの態様によれば、3つの別個のツリーとして符号化する構成は、Iスライス又はIタイルグループについて実行されるように構成されてもよい。
【0063】
本開示の態様によれば、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、異なる色成分について最大変換サイズが同じになることを許容するようにさせるように構成されたコードを更に含んでもよい。
【0064】
本開示のこの態様によれば、第1の符号化又は復号コードが、少なくとも1つのプロセッサに対して、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させるように構成される場合、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、最大垂直サイズが異なる色成分の間で同じになるように設定させ、色差成分についての最大水平変換サイズが輝度成分についての最大水平変換サイズの半分になるように設定させるように構成されたコードを更に含んでもよい。
【0065】
本開示の態様によれば、第1の符号化又は復号コードは、少なくとも1つのプロセッサに対して、位置依存予測子組み合わせ(PDPC, Position-Dependent Predictor combination)、多重変換選択(MTS, Multiple Transform Selection)、分離不可能二次変換(NSST, Non-Separable Secondary Transform)、イントラ部分分割(ISP, Intra-Sub Partitioning)及び多重参照ライン(MRL, Multiple reference line)イントラ予測のうち少なくとも1つを、輝度成分及び色差成分の双方に適用させるように構成されたコードを更に含んでもよい。
【0066】
本開示の態様によれば、命令を記憶した非一時的なコンピュータ読み取り可能媒体が提供されてもよく、命令は、デバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに対して、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号させ、或いは、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させる1つ以上の命令を含み、命令が、デバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに対して、4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号させる場合、命令は、デバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに対して、更に、平均演算以外の演算を使用して、1つの4×4の色差ブロックのアフィン動きベクトルをコピーさせ、命令が、デバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに対して、4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号させる場合、命令は、デバイスの1つ以上のプロセッサによって実行されると、少なくとも1つのプロセッサに対して、更に、それぞれの4×4の色差ブロックを2つの4×4の同一位置の色差ブロックに関連付けることにより、1つの4×4の色差ブロックのアフィン動きベクトルが、2つの同一位置の色差ブロックの動きベクトルの平均になるようにさせる。
【0067】
上記の方法、デバイス及び非一時的なコンピュータ読み取り可能媒体は、別個に記載されているが、これらの記載は、その使用又は機能の範囲に関して如何なる限定も示唆することを意図するものではない。実際に、これらの方法、デバイス及び非一時的なコンピュータ読み取り可能媒体は、本開示の他の態様において組み合わされてもよい。
【図面の簡単な説明】
【0068】
開示の対象物の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
【図1A】一実施形態による、分割された符号化ツリーユニットの図である。
【図1B】一実施形態による符号化ツリーユニットの図である。
【図2A】一実施形態による符号化ツリーユニットの図である。
【図2B】一実施形態による符号化ツリーユニットの図である。
【図3】一実施形態による異なるYUVフォーマットの図である。
【図4】一実施形態による異なる輝度値の図である。
【図5A】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図5B】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図6A】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図6B】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図7A】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図7B】一実施形態によるクロスコンポーネント線形モデリングで使用されるサンプルの図である。
【図8】一実施形態による多重モデルCCLMを使用した分類の例である。
【図9A】一実施形態によるブロックのアフィンモーションフィールドの例である。
【図9B】一実施形態によるブロックのアフィンモーションフィールドの例である。
【図10】一実施形態によるアフィン動きベクトル場の例である。
【図11】一実施形態による予測のための候補ブロックの例である。
【図12】一実施形態による予測のための候補ブロックの例である。
【図13】一実施形態による予測のための候補ブロックの例である。
【図14】一実施形態による動きベクトルの使用例である。
【図15】一実施形態による通信システムの簡略化したブロック図である。
【図16】一実施形態によるストリーミング環境の図である。
【図17】一実施形態によるビデオデコーダのブロック図である。
【図18】一実施形態によるビデオエンコーダのブロック図である。
【図19】一実施形態による、ビデオシーケンスを符号化又は復号する例示的なプロセスのフローチャートである。
【図20】一実施形態によるコンピュータシステムの図である。
【発明を実施するための形態】
【0069】
図１５は、本開示の一実施形態による通信システム(400)の簡略化したブロック図を示す。通信システム(400)は、ネットワーク(450)を介して相互接続された少なくとも2つの端末(410-420)を含んでもよい。データの一方向伝送のために、第1の端末(410)は、ネットワーク(450)を介して他方の端末(420)に送信するために、ローカル位置においてビデオデータを符号化してもよい。第2の端末(420)は、ネットワーク(450)から他方の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、復元したビデオデータを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
【0070】
図１５は、例えば、テレビ会議中に発生し得る符号化ビデオの双方向伝送をサポートするために提供される第2の対の端末(430,440)を示している。データの双方向伝送のために、各端末(430,440)は、ネットワーク(450)を介して他方の端末デバイスに送信するために、ローカル位置においてキャプチャされたビデオデータを符号化してもよい。また、各端末(430,440)は、他方の端末によって送信された符号化ビデオデータを受信してもよく、符号化データを復号してもよく、ローカルの表示デバイスに復元されたビデオデータを表示してもよい。
【0071】
図１５において、端末(410-440)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(450)は、例えば、有線及び/又は無線通信ネットワークを含む、端末(410-440)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(450)は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(450)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
【0072】
図１６は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
【0073】
ストリーミングシステムはキャプチャサブシステム(513)を含んでもよく、当該キャプチャサブシステム(513)は、例えば、非圧縮のビデオサンプルストリーム(502)を生成するビデオソース(501)(例えば、デジタルカメラ)を含んでもよい。符号化ビデオビットストリームと比較したときに高いデータ量であることを強調するために太線として描かれるサンプルストリーム(502)は、カメラ(501)に結合されたエンコーダ(503)によって処理されてもよい。エンコーダ(503)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。サンプルストリームと比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオビットストリーム(504)は、将来の使用のためにストリーミングサーバ(505)に記憶されてもよい。1つ以上のストリーミングクライアント(506,508は、ストリーミングサーバ(505)にアクセスして符号化ビデオビットストリーム(504)のコピー(507,509)を取得してもよい。クライアント(506)はビデオデコーダ(510)を含んでもよい。ビデオデコーダ(510)は、符号化ビデオビットストリームの入力コピー(507)を復号し、ディスプレイ(512)又は他のレンダリングデバイス(図示せず)上にレンダリングできる出力ビデオサンプルストリーム(511)を生成する。いくつかのストリーミングシステムでは、ビデオビットストリーム(504,507,509)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、H.265 HEVCを含む。開発中のビデオ符号化標準は、VVC(Versatile Video Coding)として非公式に知られている。開示の対象物は、VVCの背景において使用されてもよい。
【0074】
図１７は、本開示の一実施形態によるビデオデコーダ(510)の機能ブロック図でもよい。
【0075】
受信機(610)は、デコーダ(610)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(612)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(610)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(610)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(615)は、受信機(610)とエントロピーデコーダ/パーサ(620)(以下、「パーサ(520)」という)との間に結合されてもよい。受信機(610)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファ(515)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファ(615)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができる。
【0076】
ビデオデコーダ(510)は、エントロピー符号化されたビデオシーケンスからシンボル(621)を復元するためのパーサ(620)を含んでもよい。これらのシンボルのカテゴリは、デコーダ(610)の動作を管理するために使用される情報を含み、ディスプレイ(512)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該レンダリングデバイス(512)は、図１７に示すように、デコーダの一体的な部分ではないが、デコーダに結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplemental Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(620)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む、当業者に周知の原理に従ってもよい。パーサ(620)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、エントロピーデコーダ/パーサは、符号化ビデオシーケンスから、変換係数、量子化パラメータ(QP, quantizer parameter)値、動きベクトル等のような情報を抽出してもよい。
【0077】
パーサ(620)は、シンボル(621)を生成するために、バッファ(615)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。パーサ(620)は、符号化データを受信し、特定のシンボル(621)を選択的に復号してもよい。さらに、パーサ(620)は、特定のシンボル(621)が動き補償予測ユニット(653)、スケーラ/逆変換ユニット(651)、イントラ予測ユニット(652)又はループフィルタ(656)に提供されるべきかを決定してもよい。
【0078】
シンボル(621)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(620)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(620)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
【0079】
上記の機能ブロックの他に、デコーダ(510)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
【0080】
第1のユニットは、スケーラ/逆変換ユニット(651)である。スケーラ/逆変換ユニット(651)は、パーサ(620)からシンボル(621)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(651)は、アグリゲータ(655)に入力できるサンプル値を含むブロックを出力してもよい。
【0081】
場合によっては、スケーラ/逆変換(651)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(652)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(652)は、(部分的に復元された)カレントピクチャ(656)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。場合によっては、アグリゲータ(655)は、サンプル毎に、イントラ予測ユニット(652)が生成した予測情報を、スケーラ/逆変換ユニット(651)によって提供された出力サンプル情報に追加する。
【0082】
他の場合には、スケーラ/逆変換ユニット(651)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(653)は、参照ピクチャメモリ(657)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(621)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(655)によってスケーラ/逆変換ユニットの出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償ユニットに利用可能な、動き補償ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(621)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリから取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
【0083】
アグリゲータ(655)の出力サンプルは、ループフィルタユニット(656)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオビットストリームに含まれるパラメータによって制御され、パーサ(620)からシンボル(621)としてループフィルタユニット(656)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
【0084】
ループフィルタユニット(556)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(512)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(656)に記憶されてもよい。
【0085】
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。例えば、符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(620)によって)参照ピクチャとして識別されると、カレント参照ピクチャ(656)は参照ピクチャバッファ(657)の一部となってもよく、新たなカレントピクチャメモリが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
【0086】
ビデオデコーダ(510)は、H.265 HEVCのような標準に文書化され得る所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術文書又は標準において指定されており、特にこれらのプロファイル文書において指定されているビデオ圧縮技術又は標準のシンタックスに従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
【0087】
一実施形態では、受信機(610)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(510)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号雑音比(SNR, signal noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
【0088】
図１８は、本開示の一実施形態によるビデオエンコーダ(503)の機能ブロック図でもよい。
【0089】
エンコーダ(503)は、ビデオソース(501)(エンコーダの一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(501)は、エンコーダ(503)によって符号化されるべきビデオ画像をキャプチャしてもよい。
【0090】
ビデオソース(501)は、デジタルビデオサンプルストリームの形式でエンコーダ(503)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(501)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(503)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。
【0091】
一実施形態によれば、エンコーダ(503)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(743)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(750)の1つの機能である。コントローラ(750)は、以下に説明するように、他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。当業者は、特定のシステム設計のために最適化されたビデオエンコーダ(703)に関連し得るコントローラ(750)の他の機能を容易に認識できる。
【0092】
いくつかのビデオエンコーダは、当業者が「符号化ループ(coding loop」として容易に認識するもので動作する。非常に簡略化した説明として、符号化ループは、エンコーダ(730)の符号化部分(以下、「ソースコーダ」という)(符号化されるべき入力ピクチャ及び参照ピクチャに基づいてシンボルを生成することを担う)と、エンコーダ(503)に埋め込まれた(ローカル)デコーダ(733)とで構成されてもよい。デコーダ(733)は、(リモート)デコーダが生成するのと同様に(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、サンプルデータを生成するようにシンボルを復元する。その復元されたサンプルストリームは、参照ピクチャメモリ(734)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャバッファの内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、当業者に周知である。
【0093】
「ローカル」デコーダ(733)の動作は、「リモート」デコーダ(510)と同じでもよく、これは、図１６に関連して上記において既に詳細に説明した。しかし、図１６を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(745)及びパーサ(620)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、チャネル(612)、受信機(610)、バッファメモリ(615)及びパーサ(620)を含むデコーダ(510)のエントロピー復号部分は、ローカルデコーダ(733)に完全には実装されなくてもよい。
【0094】
この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
【0095】
動作の一部として、ソースコーダ(730)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照フレーム」として指定されたビデオシーケンスからの1つ以上の前に符号化されたフレームを参照して入力フレームを予測的に符号化する。このように、符号化エンジン(732)は、入力フレームの画素ブロックと、入力フレームに対する予測参照として選択され得る参照フレームの画素ブロックとの間の差を符号化する。
【0096】
ローカルビデオデコーダ(733)は、ソースコーダ(730)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータを復号してもよい。符号化エンジン(732)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図１７に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(733)は、参照フレームに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照フレームを参照ピクチャキャッシュ(734)に記憶させてもよい。このように、エンコーダ(503)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照フレームとして、共通の内容を有する復元された参照フレームのコピーをローカルに記憶してもよい。
【0097】
予測器(735)は、符号化エンジン(732)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなフレームについて、予測器(735)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(734)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(735)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block-by-pixel block)に動作してもよい。場合によっては、予測器(735)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(734)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
【0098】
コントローラ(750)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ(730)の符号化動作を管理してもよい。
【0099】
全ての上記の機能ユニットの出力は、エントロピーコーダ(745)におけるエントロピー符号化を受けてもよい。エントロピーコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化等のような当業者に既知の技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
【0100】
送信機(740)は、エントロピーコーダ(745)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(760)を介した送信の準備をしてもよく、当該通信チャネル(760)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(740)は、ビデオコーダ(730)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
【0101】
コントローラ(750)は、エンコーダ(503)の動作を管理してもよい。符号化中に、コントローラ(750)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のフレームタイプのうち1つとして割り当てられてもよい。
【0102】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(IDR, Independent Decoder Refresh)ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。
【0103】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。
【0104】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。
【0105】
一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。
【0106】
ビデオコーダ(503)は、H.265 HEVCのような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオコーダ(503)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
【0107】
一実施形態では、送信機(740)は、符号化ビデオと共に更なるデータを送信してもよい。ビデオコーダ(730)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、補足エンハンスメント情報(SEI, Supplementary Enhancement Information)メッセージ、ビジュアルユーザビリティ情報(VUI, Visual Usability Information)パラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。
【0108】
本開示は、ビデオ符号化についてのツリー分割の間に動き情報が考慮されるいくつかのブロック分割方法を対象とする。より具体的には、本開示の技術は、モーションフィールド情報に基づく柔軟なツリー構造のためのツリー分割方法に関する。本開示において提案された技術は、均一の導出されたモーションフィールド及び不均一の導出されたモーションフィールドの双方に適用できる。
【0109】
ブロックの導出されたモーションフィールドは、導出されたモーションフィールドがブロック内の全てのサブブロックについて利用可能であり、導出されたモーションフィールド内の全ての動きベクトルが同様である場合(例えば、動きベクトルが同じ参照フレームを共有し、動きベクトルの間の絶対差が全て特定の閾値未満である場合)、均一として定義される。閾値は、ビットストリームで伝達されてもよく或いは予め定義されてもよい。
【0110】
ブロックの導出されたモーションフィールドは、導出されたモーションフィールドがブロック内の全てサブブロックについて利用可能であり、導出されたモーションフィールド内の動きベクトルが類似していない場合(例えば、少なくとも1つの動きベクトルが、他の動きベクトルによって参照されない参照フレームを参照する場合、又はフィールド内の2つの動きベクトルの間の少なくとも1つの絶対差が、伝達された閾値又は所定の閾値よりも大きい場合)、不均一として定義される。
【0111】
図１９は、ビデオシーケンスを符号化又は復号する例示的なプロセス(800)のフローチャートである。いくつかの実装では、図１９の1つ以上の処理ブロックは、デコーダ(510)によって実行されてもよい。いくつかの実装では、図１９の1つ以上の処理ブロックは、エンコーダ(503)のような、デコーダ(510)から分離しているか或いはデコーダ(510)を含む、他のデバイス又はデバイスのグループによって実行されてもよい。
【0112】
図１９に示すように、プロセス(800)は、4:4:4色差フォーマット又は4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号するステップ(810)を含んでもよい。
【0113】
プロセス(800)が4:4:4色差フォーマットを使用してビデオシーケンスを符号化又は復号するステップを含む場合、プロセス(800)は、平均演算以外の演算を使用して、1つの4×4の色差ブロックのアフィン動きベクトルをコピーするステップ(820)を更に含んでもよい。
【0114】
プロセス(800)が4:2:2色差フォーマットを使用してビデオシーケンスを符号化又は復号するステップを含む場合、プロセス(800)は、それぞれの4×4の色差ブロックを2つの4×4の同一位置の色差ブロックに関連付けることにより、1つの4×4の色差ブロックのアフィン動きベクトルが、2つの同一位置の色差ブロックの動きベクトルの平均になるようにするステップ(830)を更に含んでもよい。
【0115】
図１９は、プロセス(800)の例示的なブロックを示しているが、いくつかの実装では、プロセス(800)は、図１９に示すものよりも多いブロック、少ないブロック、異なるブロック、又は異なる配置のブロックを含んでもよい。さらに或いは代替として、プロセス(800)のブロックのうちの2つ以上は並列に実行されてもよい。
【0116】
さらに、提案された方法は、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では、1つ以上のプロセッサは、提案された方法のうち1つ以上を実行するために、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。
【0117】
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図２０は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム(900)を示す。
【0118】
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、1つ以上のコンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
【0119】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
【0120】
コンピュータシステム(900)について図２０に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム(900)の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
【0121】
コンピュータシステム(900)は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
【0122】
入力ヒューマンインタフェースデバイスは、キーボード(901)、マウス(902)、トラックパッド(903)、タッチ画面(910)、データグローブ(904)、ジョイスティック(905)、マイクロフォン(906)、スキャナ(907)、カメラ(908)のうち1つ以上を含んでもよい。
【0123】
また、コンピュータシステム(900)は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面(910)、データグローブ(904)又はジョイスティック(905)による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ(909)、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよい陰極線管(CRT, cathode ray tube)画面、液晶ディスプレイ(LCD, liquid-crystal display)画面、プラズマ画面又は有機発光ダイオード(OLED, organic light-emitting diode)画面を含む画面(910)、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。
【0124】
また、コンピュータシステム(900)は、CD/DVD又は同様の媒体(921)を有するCD/DVD ROM/RW(920)を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ(922)、取り外し可能ハードドライブ又はソリッドステートドライブ(923)、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。
【0125】
また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。
【0126】
また、コンピュータシステム(900)は、1つ以上の通信ネットワークへのインタフェースを含んでもよい。ネットワークは、例えば、無線、有線、光でもよい。ネットワークは、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。ネットワークの例は、イーサネット、無線LAN、セルラネットワーク(GSM(global systems for mobile communications)、3G(third generation)、4G(fourth generation)、5G(fifth generation)、LTE(Long-Term Evolution)等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワークは、一般的に、特定の汎用データポート又は周辺バス(949)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム(900)のUSB(universal serial bus)ポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム(900)のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム(900)は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
【0127】
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム(900)のコア(940)に取り付けられてもよい。
【0128】
コア(940)は、1つ以上の中央処理装置(CPU)(941)、グラフィックス処理ユニット(GPU)(942)、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)(943)の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ(944)等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)(945)、ランダムアクセスメモリ(RAM)(946)、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、ソリッドステートドライブ(SSD)等)(947)と共に、システムバス(948)を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス(948)は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス(948)に直接取り付けられてもよく、或いは、周辺バス(949)を通じて取り付けられてもよい。周辺バスのアーキテクチャは、PCI(peripheral component interconnect)、USB等を含む。
【0129】
CPU(941)、GPU(942)、FPGA(943)及びアクセラレータ(944)は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM(945)又はRAM(946)に記憶されてもよい。また、一時的なデータは、RAM(946)に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置(947)に記憶されてもよい。1つ以上のCPU(941)、GPU(942)、大容量記憶装置(947)、ROM(945)、RAM(946)等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。
【0130】
コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。
【0131】
限定ではなく一例として、アーキテクチャ(900)、具体的には、コア(940)を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供できる。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置(947)又はROM(945)のような非一時的な性質のコア(940)の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア(940)によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア(940)、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM(946)に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ(944))内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。
【0132】
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。
【図1A】
【図1B】
【図2A】
【図2B】
【図3】
【図4】
【図5A】
【図5B】
【図6A】
【図6B】
【図7A】
【図7B】
【図8】
【図9A】
【図9B】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
