特許 7436482 最大変換サイズの制御

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-13

(45)【発行日】2024-02-21

(54)【発明の名称】最大変換サイズの制御

(51)【国際特許分類】

   H04N 19/70 20140101AFI20240214BHJP

   H04N 19/119 20140101ALI20240214BHJP

   H04N 19/136 20140101ALI20240214BHJP

   H04N 19/176 20140101ALI20240214BHJP

   H04N 19/122 20140101ALI20240214BHJP

【ＦＩ】

H04N19/70

H04N19/119

H04N19/136

H04N19/176

H04N19/122

【請求項の数】 10

(21)【出願番号】P 2021531981

(86)(22)【出願日】2020-03-02

(65)【公表番号】

(43)【公表日】2022-02-01

(86)【国際出願番号】 US2020020607

(87)【国際公開番号】W WO2020180769

(87)【国際公開日】2020-09-10

【審査請求日】2021-06-04

(31)【優先権主張番号】62/813,665

(32)【優先日】2019-03-04

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/804,547

(32)【優先日】2020-02-28

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャオ，シン

(72)【発明者】

【氏名】リ，シアン

(72)【発明者】

【氏名】リィウ，シャン

【審査官】間宮 嘉誉

(56)【参考文献】

【文献】米国特許出願公開第２０１４／０２１９３３６（ＵＳ，Ａ１）

【文献】ZHAO, Xin et al.，Non-CE6: Configurable Max Transform Size in VVC，JVET-O0545 (version 2)，ITU，2019年07月04日，pp.1-6，[online]，[retrieved on 2023-07-05]，Retrieved from the Internet: <URL: https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0545-v2.zip>，JVET-O0545-v2.docx

【文献】BROSS, Benjamin et al.，Versatile Video Coding (Draft 4)，JVET-M1001 (version 5)，ITU，2019年02月27日，pp.28-30, 43-46, 61-65，JVET-M1001-v5.docx

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１２

Ｈ０４Ｎ １９／００－１９／９８

(57)【特許請求の範囲】

【請求項1】

デコーダがビデオシーケンスの復号のための最大変換サイズの制御を実行する方法であって、
前記ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別するステップと、
前記ビデオシーケンスに関連する前記ハイレベルのシンタックスエレメントに基づいて、前記ビデオシーケンスに関連する最大変換サイズを決定するステップであって、前記最大変換サイズが32又は64である、ステップと、
前記ビデオシーケンスに関連する前記最大変換サイズを決定することに基づいて、前記最大変換サイズを使用して前記ビデオシーケンスを復号するステップと
を含み、
サブブロック変換(SBT)モードが有効である場合、前記SBTモードを許容する最大ブロックサイズは前記最大変換サイズによって制限され、
前記最大変換サイズが32であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである32と最大SBTサイズとのいずれか小さい方であり、前記最大変換サイズが64であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである64と前記最大SBTサイズとのいずれか小さい方である、方法。

【請求項2】

前記ハイレベルのシンタックスエレメントは、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)及びピクチャパラメータセット(PPS)のうち1つである、請求項１に記載の方法。

【請求項3】

前記ハイレベルのシンタックスエレメントは、スライスヘッダ、タイルヘッダ、タイルグループヘッダ及び符号化ツリーユニット(CTU)ヘッダのうち1つである、請求項１に記載の方法。

【請求項4】

前記最大変換サイズは、最大変換幅及び高さ又は最大変換ユニット領域に対応する、請求項１乃至３のうちいずれか１項に記載の方法。

【請求項5】

ビデオシーケンスの復号のための最大変換サイズの制御を実行するデバイスであって、
プログラムコードを記憶するように構成された少なくとも1つのメモリと、
前記プログラムコードを読み取って前記プログラムコードによって命令される通りに動作するように構成された少なくとも1つのプロセッサと
を含み、前記プログラムコードは、
前記少なくとも1つのプロセッサに対して、前記ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別させるように構成された識別コードと、
前記少なくとも1つのプロセッサに対して、前記ビデオシーケンスに関連する前記ハイレベルのシンタックスエレメントに基づいて、前記ビデオシーケンスに関連する最大変換サイズを決定させるように構成された決定コードであって、前記最大変換サイズが32又は64である、決定コードと、
前記少なくとも1つのプロセッサに対して、前記ビデオシーケンスに関連する前記最大変換サイズを決定することに基づいて、前記最大変換サイズを使用して前記ビデオシーケンスを復号させるように構成された復号コードと
を含み、
サブブロック変換(SBT)モードが有効である場合、前記SBTモードを許容する最大ブロックサイズは前記最大変換サイズによって制限され、
前記最大変換サイズが32であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである32と最大SBTサイズとのいずれか小さい方であり、前記最大変換サイズが64であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである64と前記最大SBTサイズとのいずれか小さい方である、デバイス。

【請求項6】

前記ハイレベルのシンタックスエレメントは、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)及びピクチャパラメータセット(PPS)のうち1つである、請求項５に記載のデバイス。

【請求項7】

前記ハイレベルのシンタックスエレメントは、スライスヘッダ、タイルヘッダ、タイルグループヘッダ及び符号化ツリーユニット(CTU)ヘッダのうち1つである、請求項５に記載のデバイス。

【請求項8】

前記最大変換サイズは、最大変換幅及び高さ又は最大変換ユニット領域に対応する、請求項５乃至７のうちいずれか１項に記載のデバイス。

【請求項9】

ビデオシーケンスの復号のための最大変換サイズの制御を実行するデバイスの1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに対して、
前記ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別させ、
前記ビデオシーケンスに関連する前記ハイレベルのシンタックスエレメントに基づいて、前記ビデオシーケンスに関連する最大変換サイズを決定させ、
前記ビデオシーケンスに関連する前記最大変換サイズを決定することに基づいて、前記最大変換サイズを使用して前記ビデオシーケンスを復号させ、
前記最大変換サイズが32又は64であり、
サブブロック変換(SBT)モードが有効である場合、前記SBTモードを許容する最大ブロックサイズは前記最大変換サイズによって制限され、
前記最大変換サイズが32であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである32と最大SBTサイズとのいずれか小さい方であり、前記最大変換サイズが64であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである64と前記最大SBTサイズとのいずれか小さい方である、コンピュータプログラム。

【請求項10】

エンコーダがビデオシーケンスの符号化のための最大変換サイズの制御を実行する方法であって、
前記ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別するステップと、
前記ビデオシーケンスに関連する前記ハイレベルのシンタックスエレメントに基づいて、前記ビデオシーケンスに関連する最大変換サイズを決定するステップであって、前記最大変換サイズが32又は64である、ステップと、
前記ビデオシーケンスに関連する前記最大変換サイズを決定することに基づいて、前記最大変換サイズを使用して前記ビデオシーケンスを復号するステップと、
前記最大変換サイズを使用して前記ビデオシーケンスを復号することに基づいて、前記ビデオシーケンスを送信するステップと
を含み、
サブブロック変換(SBT)モードが有効である場合、前記SBTモードを許容する最大ブロックサイズは前記最大変換サイズによって制限され、
前記最大変換サイズが32であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである32と最大SBTサイズとのいずれか小さい方であり、前記最大変換サイズが64であることを前記ハイレベルのシンタックスエレメントが示す場合、前記SBTモードを許容する前記最大ブロックサイズは、前記最大変換サイズである64と前記最大SBTサイズとのいずれか小さい方である、方法。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願への相互参照］
本出願は、2020年2月28日に出願された米国特許出願第16/804,547号「MAXIMUM TRANSFORM SIZE CONTROL」に対する優先権の利益を主張し、当該出願は、2019年3月4日に出願された米国特許出願第62/813,665号「Max transform size control」に対する優先権の利益を主張する。これらの先の出願の開示の全内容を参照により援用する。

【0002】

［技術分野］
本開示は、HEVC(High Efficiency Video Coding)を超える次世代ビデオ符号化技術、例えば、VVC(Versatile Video Coding)について提案されている。より具体的には、最大変換サイズを制御するための方式が提案され、さらに、最大変換サイズと変換分割方式(例えば、サブブロック変換(SBT, sub-block transform)及びイントラサブパーティション(ISP, Intra sub-partitioning))との間の相互作用が提案される。

【背景技術】

【0003】

ITU-T VCEG(Q6/16)及びISO/IEC MPEG(JTC 1/SC 29/WG 11)は、2013年(バージョン1)、2014年(バージョン2)、2015年(バージョン3)及び2016年(バージョン4)にH.265/HEVC(High Efficiency Video Coding)標準を公表した。その後、HEVC標準(その拡張機能を含む)を大幅に上回る圧縮能力を有する将来のビデオ符号化技術の標準化についての潜在的なニーズを研究している。2017年10月に、HEVCを超える能力を有するビデオ圧縮に関する提案の共同募集(CfP, Joint Call for Proposals on Video Compression with Capability beyond HEVC)を発行した。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)を正式に開始した。VTM(VVC Test Model)の現在のバージョンはVTM4である。

【発明の概要】

【0004】

本開示の態様によれば、ビデオシーケンスの復号のための最大変換サイズの制御を実行する方法は、デコーダによって、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別するステップと、デコーダによって、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別することに基づいて、ビデオシーケンスに関連する最大変換サイズを決定するステップと、デコーダによって、ビデオシーケンスに関連する最大変換サイズを決定することに基づいて、最大変換サイズを使用してビデオシーケンスを復号するステップと、デコーダによって、最大変換サイズを使用してビデオシーケンスを復号することに基づいて、ビデオシーケンスを送信するステップとを含む。

【0005】

本開示の一態様によれば、ビデオシーケンスの復号のための最大変換サイズの制御を実行するデバイスは、プログラムコードを記憶するように構成された少なくとも1つのメモリと、プログラムコードを読み取ってプログラムコードによって命令される通りに動作するように構成された少なくとも1つのプロセッサとを含み、プログラムコードは、少なくとも1つのプロセッサに対して、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別させるように構成された識別コードと、少なくとも1つのプロセッサに対して、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別することに基づいて、ビデオシーケンスに関連する最大変換サイズを決定させるように構成された決定コードと、少なくとも1つのプロセッサに対して、ビデオシーケンスに関連する最大変換サイズを決定することに基づいて、最大変換サイズを使用してビデオシーケンスを復号させるように構成された復号コードと、少なくとも1つのプロセッサに対して、最大変換サイズを使用してビデオシーケンスを復号することに基づいて、ビデオシーケンスを送信させるように構成された送信コードとを含む。

【0006】

本開示の一態様によれば、非一時的なコンピュータ読み取り可能媒体は命令を記憶し、命令は、ビデオシーケンスの復号のための最大変換サイズの制御を実行するデバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに対して、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別させ、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別することに基づいて、ビデオシーケンスに関連する最大変換サイズを決定させ、ビデオシーケンスに関連する最大変換サイズを決定することに基づいて、最大変換サイズを使用してビデオシーケンスを復号させ、最大変換サイズを使用してビデオシーケンスを復号することに基づいて、ビデオシーケンスを送信させる。

【図面の簡単な説明】

【0007】

開示の対象物の更なる特徴、特性及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。

【図1】ビデオシーケンスを符号化又は復号するための最大変換サイズの制御を実行するための例示的な処理のフローチャートである。

【図2】本開示の一実施形態による通信システムの簡略化したブロック図である。

【図3】ストリーミング環境におけるビデオエンコーダ及びデコーダの配置の図である。

【図4】本開示の一実施形態によるビデオデコーダの機能ブロック図である。

【図5】本開示の一実施形態によるビデオエンコーダの機能ブロック図である。

【図6】一実施形態によるコンピュータシステムの図である。

【発明を実施するための形態】

【0008】

［解決すべき課題］
最新のVVCドラフトでは、最大TUサイズは64の固定数であり、これは最大TUサイズに関する制御を実行する能力が存在しないことを意味する。しかし、最大TUサイズはエンコーダ実装についてのハードウェアの複雑さ(例えば、パイプライン中間バッファサイズ、乗算器の数等)に影響を与えるので、VVCにおいて最大TUサイズを制御する必要が存在し得る。

【0009】

最新のVVCドラフトにはSBT及びISPが含まれており、SBTとISPと最大TUサイズとの間の相互作用が扱われる必要がある。例えば、SBTでは、SPSフラグsps_sbt_max_size_64_flagは、最大SBTサイズが32の長さであるか64の長さであるかを示すために伝達され、sps_sbt_max_size_64_flagが真であり、最大TUサイズが32ポイントである場合、現在のVVCドラフトは対処できず、エンコーダのクラッシュがトリガされる可能性がある。

【0010】

現在、ISPモードは全てのCUサイズに対して許容されているが、最大変換サイズが64よりも小さく設定された場合、暗示的な変換分割を実行するか、信号伝達によってISPを使用して明示的に変換分割を実行するかの競合が存在する。例えば、最大変換サイズが16であり、64×16のTUについてISPがない場合、暗示的に4つの16×16のTUに分割されるべきであるが、ISPがある場合、垂直ISP分割を使用して分割される可能性があり、これは、同じ4つの16×16のTUを生じるが、信号伝達を使用する。

【0011】

［詳細な説明］
HEVCでは、CTUは、様々な局所特性に適応するために符号化ツリーとして示される四分木構造を使用することにより、CUに分割される。インターピクチャ(時間的)又はイントラピクチャ(空間的)予測を使用してピクチャ領域を符号化するか否かの決定は、CUレベルで行われる。各CUは、PU分割タイプに従って、1つ、2つ又は4つのPUに更に分割できる。1つのPUの内部では、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づく予測プロセスを適用することによって残差ブロックを取得した後に、CUは、CUについての符号化ツリーのような他の四分木構造に従って変換ユニット(TU, transform unit)に分割できる。HEVC構造の主要な特徴の1つは、CU、PU及びTUを含む複数の分割概念を有することである。

【0012】

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のみを含む。

【0013】

QTBT分割方式について以下のパラメータが定義されている。

【0014】

CTUサイズ:HEVCと同じ概念の四分木のルートノードサイズ

【0015】

MinQTSize:許容される最小の四分木リーフノードサイズ

【0016】

MaxBTSize:許容される最大の二分木ルートノードサイズ

【0017】

MaxBTDepth:許容される最大の二分木の深度

【0018】

MinBTSize:許容される最小の二分木リーフノードサイズ

【0019】

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の輝度サンプルである。

【0020】

QTBTを使用することによるブロック分割において、二分木の分割(すなわち、非リーフ)ノードに関して、どの分割タイプ(すなわち、水平又は垂直)が使用されるかを示すために、1つのフラグが信号伝達され、0は水平分割を示し、1は垂直分割を示す。四分木分割では、四分木分割は、等しいサイズを有する4つのサブブロックを生成するために、常にブロックを水平と垂直との双方に分割するので、分割タイプを示す必要はない。

【0021】

さらに、QTBT方式は、輝度及び色差が別個のQTBT構造を有するような柔軟性をサポートする。現在、P及びBスライスについて、1つのCTU内の輝度及び色差CTBは同じQTBT構造を共有する。しかし、Iスライスについては、輝度CTBはQTBT構造によってCUに分割され、色差CTBは他のQTBT構造によって色差CUに分割される。これは、Iスライス内のCUが輝度成分の符号化ブロック、又は2つの色差成分の符号化ブロックで構成され、P又はBスライス内のCUが全ての3つの色成分の符号化ブロックで構成されることを意味する。

【0022】

HEVCでは、動き補償のメモリアクセスを低減するために、小さいブロックについてのインター予測が制限され、双方向予測が4×8及び8×4のブロックでサポートされず、インター予測が4×4のブロックでサポートされない。JEM-7.0で実装されているQTBT方式では、これらの制限が除去される。

【0023】

マルチタイプツリー(MTT, Multi-type-tree)構造が提案されている。MTTはQTBTよりも柔軟なツリー構造である。MTTでは、四分木及び二分木以外に、水平及び垂直の中央側の三分木が導入されている。三分木分割の主な利点は、以下の通りである。四分木及び二分木分割に対する補足がある。三分木分割は、四分木及び二分木が常にブロック中心で分割される一方で、ブロック中心に位置するオブジェクトをキャプチャすることができる。提案の三分木の分割の幅及び高さは常に2のべき乗になるので、更なる変換は必要ない。

【0024】

2レベルツリーの設計は、主に複雑性の低減によって動機づけられる。理論的には、ツリーのトラバースの複雑さはT^Dであり、Tは分割タイプの数であり、Dはツリーの深度である。

【0025】

HEVCでは、一次変換は4ポイント、8ポイント、16ポイント及び32ポイントのDCT-2であり、変換コア行列は、8ビットの整数(すなわち、8ビットの変換コア)を使用して表される。より小さいDCT-2の変換コア行列は、より大きいDCT-2の変換コア行列の一部である。

【0026】

DCT-2コア行列は対称的/反対称的な特性を示し、したがって、「部分的バタフライ(partial butterfly)」実装が、演算のカウント数(例えば、乗算、加算/減算、シフト)を低減するためにサポートされ、行列乗算の同じ結果が部分的バタフライを使用して取得できる。

【0027】

現在のVVCでは、HEVCと同じ4ポイント、8ポイント、16ポイント及び32ポイントのDCT-2変換の他に、更なる2ポイント及び64ポイントのDCT-2も含まれる。

【0028】

HEVCで使用されているDCT-2及び4×4のDST-7に加えて、適応多重変換(AMT, Adaptive Multiple Transform)(拡張多重変換(EMT, Enhanced Multiple Transform)又は多重変換選択(MTS, Multiple Transform Selection)としても知られる)方式が、インター及びイントラ符号化ブロックの双方の残差符号化のためにVVCで使用されている。AMT方式は、HEVCにおける現在の変換以外のDCT/DSTファミリーからの複数の選択された変換を使用する。新たに導入された変換行列はDST-7、DCT-8である。

【0029】

VCCにおける全ての一次変換行列は、8ビット表現で使用される。AMTは、幅及び高さの双方が32以下のCUに適用し、AMTを適用するか否かは、例えば、mts_flagと呼ばれるフラグによって制御される。mts_flagが0に等しい場合、DCT-2のみが残差を符号化するために適用される。mts_flagが1に等しい場合、水平及び垂直変換を指定するために2つのビンを使用して、インデックスmts_idxが更に伝達される。

【0030】

イントラサブパーティション(ISP, Intra Sub-Partitions)符号化モードは、ブロックサイズの大きさに依存して、輝度イントラ予測ブロックを垂直又は水平に2つ又は4つのサブパーティションに分割する。

【0031】

これらのサブパーティションのそれぞれについて、エンコーダによって送信された係数をエントロピー復号し、次いでこれらを逆量子化及び逆変換することによって、残差信号が生成される。次いで、サブパーティションがイントラ予測され、最終的に、残差信号を予測信号に追加することによって対応する復元サンプルが取得される。したがって、各サブパーティションの復元値は、次のサブパーティションの予測を生成するために利用可能であり、これによって処理等が繰り返される。全てのサブパーティションは同じイントラモードを共有する。

【0032】

ISPアルゴリズムは、MPMリストの一部であるイントラモードでのみテストされる。この理由で、ブロックがISPを使用する場合、MPMフラグは1であると推定される。さらに、ISPが特定のブロックに使用される場合、MPMリストは、DCモードを除外し、ISP水平分割のための水平イントラモードと垂直分割のための垂直イントラモードとを優先させるように変更される。

【0033】

ISPでは、変換及び復元は各サブパーティションについて個別に実行されるので、各サブパーティションはサブTUとして見なされることができる。

【表1】

【0034】

JVET-J0024、JVET-K0139及びJVET-L0358において、空間変化変換(SVT, spatially varying transform)方式が提案されている。SVTによって、インター予測残差について、符号化ブロックに残差ブロックのみが存在するが、残差ブロックは符号化ブロックよりも小さいので、SVTにおける変換サイズは符号化ブロックサイズよりも小さくなる。残差ブロック又は変換でカバーされていない領域については、ゼロの残差が仮定される。

【0035】

以下に示すVVCに対して提案されたSBTを使用して、追加されたテキストが灰色で強調表示されるる。SBT方法は、サブブロックタイプ(水平又は垂直)、サイズ(半分又は4分の1)及び位置(左又は右、上又は下)を示すために、更なるオーバーヘッドビット(cu_sbt_flag、cu_sbt_quad_flag、cu_sbt_horizontal_flag、cu_sbt_pos_flag)が伝達されることを必要とすることが分かる。

【表2】

【表3】

【表4】

【0036】

0に等しいsps_sbt_enabled_flagは、インター予測CUについてのサブブロック変換が無効であることを指定する。1に等しいsps_sbt_enabled_flagは、インター予測CUについてのサブブロック変換が有効であることを指定する。

【0037】

0に等しいslice_sbt_max_size_64_flagは、サブブロック変換を許容する最大CU幅及び高さが32であることを指定する。1に等しいslice_sbt_max_size_64_flagは、サブブロック変換を許容する最大CU幅及び高さが64であることを指定する。

【0038】

maxSbtSize=slice_sbt_max_size_64_flag?64:32

【0039】

1に等しいcu_sbt_flag[x0][y0]は、カレント符号化ユニットについてサブブロック変換が使用されることを指定する。0に等しいcu_sbt_flag[x0][y0]は、カレント符号化ユニットについてサブブロック変換が使用されないことを指定する。

【0040】

cu_sbt_flag[x0][y0]が存在しない場合、その値は0に等しいと推定される。

【0041】

サブブロック変換が使用される場合、符号化ユニットは2つの変換ユニットにタイル設定され、一方の変換ユニットは残差を有し、他方は残差を有さない。

【0042】

1に等しいcu_sbt_quad_flag[x0][y0]は、カレント符号化ユニットについて、サブブロック変換がカレント符号化ユニットの1/4のサイズの変換ユニットを含むことを指定する。0に等しいcu_sbt_quad_flag[x0][y0]は、カレント符号化ユニットについて、サブブロック変換がカレント符号化ユニットの1/2のサイズの変換ユニットを含むことを指定する。

【0043】

cu_sbt_quad_flag[x0][y0]が存在しない場合、その値は0に等しいと推定される。

【0044】

1に等しいcu_sbt_horizontal_flag[x0][y0]は、カレント符号化ユニットが水平分割を使用することによって2つの変換ユニットにタイル設定されることを指定する。0に等しいcu_sbt_horizontal_flag[x0][y0]は、カレント符号化ユニットが垂直分割を使用することによって2つの変換ユニットにタイル設定されることを指定する。

【0045】

cu_sbt_horizontal_flag[x0][y0]が存在しない場合、その値は以下のように導出される。

【0046】

cu_sbt_quad_flag[x0][y0]が1に等しい場合、cu_sbt_horizontal_flag[x0][y0]はallowSbtHoriQuadに等しく設定される。

【0047】

そうでない場合(cu_sbt_quad_flag[x0][y0]が0に等しい場合)、cu_sbt_horizontal_flag[x0][y0]はallowSbtHoriHalfに等しく設定される。

【0048】

1に等しいcu_sbt_pos_flag[x0][y0]は、カレント符号化ユニット内の第1の変換ユニットのtu_cbf_luma、tu_cbf_cb及びtu_cbf_crがビットストリームに存在しないことを指定する。0に等しいcu_sbt_pos_flag[x0][y0]は、カレント符号化ユニット内の第2の変換ユニットのtu_cbf_luma、tu_cbf_cb及びtu_cbf_crがビットストリームに存在しないことを指定する。

【0049】

この処理への入力は以下の通りである。

【0050】

カレントピクチャの左上の輝度サンプルに対するカレント輝度変換ブロックの左上のサンプルを指定する輝度位置(xTbY,yTbY)

【0051】

カレント変換ブロックの幅を指定する変数nTbW

【0052】

カレント変換ブロックの高さを指定する変数nTbH

【0053】

カレントブロックの色成分を指定する変数cIdx

【0054】

スケーリングされた変換係数の(nTbW)×(nTbH)の配列d[x][y](x=0..nTbW-1、y=0..nTbH-1)

【0055】

この処理の出力は、残差サンプルの(nTbW)×(nTbH)の配列r[x][y](x=0..nTbW-1、y=0..nTbH-1)である。

【0056】

cu_sbt_flag[xTbY][yTbY]が1に等しい場合、水平変換カーネルを指定する変数trTypeHor及び垂直変換カーネルを指定する変数trTypeVerは、表8-Xにおいてcu_sbt_horizontal_flag[xTbY][yTbY]及びcu_sbt_pos_flag[xTbY][yTbY]に依存して導出される。

【0057】

そうでない場合(cu_sbt_flag[xTbY][yTbY]が0に等しい場合)、水平変換カーネルを指定する変数trTypeHor及び垂直変換カーネルを指定する変数trTypeVerは、表8-9においてmts_idx[xTbY][yTbY]及びCuPredMode[xTbY][yTbY]に依存して導出される。

【0058】

残差サンプルの(nTbW)×(nTbH)の配列rは以下のように導出される。

【0059】

スケーリングされた変換係数d[x][y](x=0..nTbW-1、y=0..nTbH-1)の各(垂直)列は、変換ブロックの高さnTbH、リストd[x][y](y=0..nTbH-1)及びtrTypeVerに等しく設定された変換タイプ変数trTypeを入力として、各列x=0..nTbW-1について一次元変換処理を呼び出すことにより、e[x][y](x=0..nTbW-1、y=0..nTbH-1)に変換され、出力はリストe[x][y](y=0..nTbH-1)である。

【0060】

中間サンプル値g[x][y](x=0..nTbW-1,y=0..nTbH-1)は、以下のように導出される。

【0061】

g[x][y]=Clip3(CoeffMin,CoeffMax,(e[x][y]+256)>>9)

【0062】

結果の配列g[x][y](x=0..nTbW-1、y=0..nTbH-1)の各(水平)列は、変換ブロックの幅nTbH、リストg[x][y](x=0..nTbW-1)及びtrTypeHorに等しく設定された変換タイプ変数trTypeを入力として、各行y=0..nTbH-1について一次元変換処理を呼び出すことにより、r[x][y](x=0..nTbW-1、y=0..nTbH-1)に変換され、出力はリストr[x][y](x=0..nTbW-1)である。

【表5】

【0063】

異なるYUVフォーマットが存在する。4:2:0フォーマットでは、LM予測は6タップ補間フィルタを適用して、図６に示すように色差サンプルに対応するダウンサンプリングされた輝度サンプルを取得する。正式には、ダウンサンプリングされた輝度サンプルRec’L[x,y]は、復元された輝度サンプルから以下のように計算される。

【0064】

Rec’_L[x.y]=(2×Rec_L[2x,2y]+2×Rec_L[2x,2y+1]+Rec_L[2x-1,2y]+Rec_L[2x+1,2y]+Rec_L[2x-1,2y+1]+Rec_L[2x+1,2y+1]+4)>>3

【0065】

図１は、ビデオシーケンスの符号化又は復号を行うための最大変換サイズの制御を実行する方法についての例示的な処理100のフローチャートである。いくつかの実装では、図１の1つ以上の処理ブロックは、デコーダによって実行されてもよい。いくつかの実装では、図１の1つ以上の処理ブロックは、エンコーダのような、デコーダから分離しているか或いはデコーダを含む他のデバイス又はデバイスのグループによって実行されてもよい。
図１に示すように、処理100は、デコーダによって、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別するステップ(ブロック110)を含んでもよい。

【0066】

図１に更に示すように、処理100は、デコーダによって、ビデオシーケンスに関連するハイレベルのシンタックスエレメントを識別することに基づいて、ビデオシーケンスに関連する最大変換サイズを決定するステップ(ブロック120)を含んでもよい。

【0067】

図１に更に示すように、処理100は、デコーダによって、ビデオシーケンスに関連する最大変換サイズを決定することに基づいて、最大変換サイズを使用してビデオシーケンスを復号するステップ(ブロック130)を含んでもよい。

【0068】

図１に更に示すように、処理100は、デコーダによって、最大変換サイズを使用してビデオシーケンスを復号することに基づいて、ビデオシーケンスを送信するステップ(ブロック140)を含んでもよい。

【0069】

本明細書において使用されるハイレベルのシンタックスエレメントは、ビデオパラメータセット(VPS, Video Parameter Set)、シーケンスパラメータセット(SPS, Sequence Parameter Set)、ピクチャパラメータセット(PPS, Picture Parameter Set)、スライスヘッダ、タイルヘッダ、タイルグループヘッダ等のうちいずれかを示してもよい。さらに、符号化ツリーユニット(CTU, coding tree unit)(最大CUサイズ)ヘッダは、例えばヘッダ情報として、各CTUについて伝達されたシンタックスエレメントを参照してもよい。さらに、「変換サイズ」は、最大変換幅及び高さ、又は最大変換ユニット領域サイズを示してもよい。

【0070】

一実施形態によれば、最大変換サイズは、ハイレベルのシンタックスエレメント又はCTUヘッダで伝達される。最小変換サイズは伝達されず、デフォルト値として設定される。最小変換サイズの値の例は、4の長さ、8の長さ及び16の長さを含む。一実施形態では、最大変換サイズは、いくつかの所定の値の中の値でなければならないことが制限される。所定の値の例は、16の長さ、32の長さ及び64の長さを含む。

【0071】

一実施形態では、最大変換サイズから定数を引いた対数値が伝達される。例えば、最小のサポートされる最大変換サイズは16として設定され、最大変換サイズはlog2_max_transform_size_minus_4として伝達される。すなわち、最大変換サイズが64である場合には値2が伝達され、最大変換サイズ32である場合には値1が伝達される。他の例では、最小の可能な最大変換サイズが32として設定され、最大変換サイズ32及び64についてそれぞれ値0及び1が伝達される。

【0072】

一実施形態によれば、最大変換ユニット領域サイズのみが、ハイレベルのシンタックスエレメント又はCTUヘッダで伝達される。最小変換ユニット領域サイズは伝達されず、デフォルト値として設定され、値の例は、16個のサンプル、32個のサンプル及び64個のサンプルを含む。一実施形態では、最大変換ユニット領域サイズは、少なくともデフォルト値とすべきことが制限される。デフォルト値の例は、64個のサンプル、128個のサンプル、256個のサンプル、512個のサンプル、1024個のサンプル、2048個のサンプル又は4096個のサンプルを含む。一実施形態では、最大変換ユニット領域サイズを最小の考えられる最大変換ユニット領域サイズで除算した対数値が伝達される。例えば、最小の可能な最大変換ユニット領域サイズは256として設定され、最大変換サイズを256で除算した対数値が伝達される。すなわち、最大変換ユニット領域サイズがそれぞれ256、512、1024、2048及び4096である場合、0、1、2、3、4が伝達される。

【0073】

一実施形態によれば、最大SBTサイズは、伝達された最大変換サイズ又は変換ユニットサイズに従って制限される。

【表6】

【0074】

一実施形態では、sps_sbt_max_size_64_flagは、最大変換サイズが64未満である場合には伝達されないが、SBTを許容する最大CU幅及び高さを示すデフォルト値として導出されるのは32個の輝度サンプルである。

【0075】

他の実施形態では、SBTを許容する実際の最大CU幅及び高さは、最大変換サイズを示すハイレベルのシンタックスエレメントによって更に調整され、SBTを許容する実際の最大CU幅及び高さは、最大変換サイズと、ハイレベルのシンタックスで伝達されたSBTを許容する最大CU幅及び高さとの間の最小値として導出される。例えば、最大変換サイズが16である場合、slice_max_sbt_size_64_flagが0(SBTを許容する最大CU幅及び高さが32である)として伝達されるか1(SBTを許容する最大CU幅及び高さは64である)として伝達されるかにかかわらず、SBTを許容する最大CU幅及び高さは16である。VVC仕様テキストに対する提案の変更は、以下の通りである。

【0076】

0に等しいslice_sbt_max_size_64_flagは、サブブロック変換を許容する最大CU幅及び高さが32であることを指定する。1に等しいslice_sbt_max_size_64_flagは、サブブロック変換を許容する最大CU幅及び高さが64であることを指定する。

【0077】

maxSbtSize=min(max_transform_size,slice_sbt_max_size_64_flag?64:32)
ここで、max_transform_sizeは最大変換サイズを定義する。

【0078】

CU幅及び高さの双方が最大TUサイズ以下である場合にのみSBTを適用することが提案される。

【0079】

SBTで行われるように、どの変換ユニットが非ゼロ係数を有するかを示す代わりに、まず、符号化ユニットのどのサブ部分(SBTパーティション、すなわち、左半分、右半分、上半分、下半分、左四半分、右四半分、上四半分又は下半分を使用するもの等)が少なくとも1つの非ゼロ係数を有するかを伝達することが提案され、符号化ユニットの各部分は1つ又は複数のTUを含んでもよい。

【0080】

一実施形態では、サブ部分サイズが最大TUサイズよりも大きい場合、サブ部分サイズは複数のTUに分割され、各TUは最大TUサイズよりも大きくない。例えば、最大TUサイズが16の長さであり、64×32のCUが非ゼロ係数に関連する右半分(32×32)のサブ部分のみを有すると決定され、左半分(32×32)のサブ部分がゼロ係数のみに関連する場合、この場合、右半分は4つの16×16のTUに更に分割され、それぞれの16×16のTUは非ゼロ係数を有してもよい。64×32のCUは、非ゼロ係数に関連する右半分(テクスチャサブ部分)のみを含み、右半分の32×32のサブ部分は、4つの16×16のTUに更に分割される。

【0081】

一実施形態では、サブ部分サイズが最大TUサイズよりも大きい場合、サブ部分サイズは複数のTUに分割され、各TUは最大TUサイズよりも大きくなく、符号化順序で最後のTUを除くサブ部分の全てのTUがゼロCBFで符号化される場合、このサブ部分の最後のTUのCBFは伝達されず、非ゼロCBF値で導出される。

【0082】

一実施形態によれば、CUを3:1又は1:3のサブ部分に水平又は垂直に分割する、SBTで使用される四半分の分割の代わりに、CU幅(W)が高さ(H)より大きい場合、垂直分割を使用した3:1又は1:3の代わりに、CUが1つの左側H×H及び1つの右側(W-H)×H、又は1つの右側H×H及び1つの左側(W-H)×Hのサブ部分に分割されることが提案される。Wが4×Hよりも大きい場合、提案の分割は3:1及び1:3の分割とは異なる。同様に、CU幅(W)が高さ(H)よりも小さい場合、水平分割を使用した3:1又は1:3の代わりに、CUは1つの上側H×H及び1つの下側(W-H)×H、又は1つの下側H×H及び1つの上側(W-H)×Hのサブ部分に分割される。提案の分割は、Hが4×Wよりも大きい場合、3:1及び1:3の分割とは異なる。

【0083】

一例では、128×16のCUについて、1つの96×16のゼロTUと1つの32×16の非ゼロTUとに分割する代わりに、1つの112×16のゼロTUと1つの16×16の非ゼロTUとに分割することが提案される。他の例では、128×8のCUについて、1つの96×8のゼロTUと1つの32×8の非ゼロTUとに分割する代わりに、1つの120×8のゼロTUと1つの8×8の非ゼロTUとに分割することが提案される。

【0084】

一実施形態では、CUサイズがW×Hである場合、且つ、水平の1:3又は3:1の分割によって、0.25Wが最大TUサイズ(max_transform_size)よりも大きい場合、CUを1つの0.25W×HのTUと1つの0.75W×HのTUとに分割する代わりに、CUは1つのmax_transform_size×HのTUと1つの(W-max_transform_size)×HのTUとに分割される。

【0085】

一例では、128×8のCUについて、最大TUサイズが16である場合、1つの96×8のゼロTUと1つの32×8の非ゼロTUとに分割する代わりに、1つの112×8のゼロTUと1つの16×8の非ゼロTUとに分割することが提案される。

【0086】

一実施形態では、CUサイズがW×Hである場合、且つ、垂直の1:3又は3:1の分割によって、0.25Hが最大TUサイズ(max_transform_size)よりも大きい場合、CUを1つのW×0.25HのTUと1つのW×0.75HのTUとに分割する代わりに、CUは1つのmax_transform_size×HのTUと1つの(W-max_transform_size)×HのTUとに分割される。

【0087】

現在のSBT設計におけるハイレベルのシンタックスslice_max_sbt_size_64_flagで行われているように、SBTを許容する最大CU幅及び高さを伝達する代わりに、SBTを許容する最大変換サイズは伝達されない。

【0088】

一実施形態では、カレントCUの幅又は高さが、SBTを許容する最大CU幅及び高さよりも大きい場合であっても、結果の非ゼロのサブTUが、最大TU幅及び高さよりも大きくない幅及び高さを有する限り、SBT分割は許容され、伝達されてもよい。例えば、最大TUサイズ(幅及び高さ)が32ポイントであり、カレントCUが64×32である場合、カレントCUを2つの32×32のTU、又は1つの非ゼロの16×32のTU及び1つのゼロの48×32のTUに垂直に分割することが許容されるが、結果の変換幅は最大変換サイズを超える64になるので、カレントCUを水平に分割することは許容されない。

【0089】

SBT分割及び方向の利用可能性は、結果の非ゼロのサブTUが最大TUの制約を満たすか否かに基づいてもよい。利用可能でない場合、関連するフラグは伝達されず推定される。一例では、CUは64×16であり、最大変換サイズは16である。この場合、半分のSBT分割は利用可能でなく、それにより、cu_sbt_quad_flagは伝達されず、真として推定される。さらに、水平分割SBTも利用可能でなく、それにより、cu_sbt_horizontal_flagは伝達されず、偽として推定される。

【0090】

最大TUサイズよりも大きい高さ又は幅を有する非ゼロのTUを生じるSBT分割を許容せず、伝達しないことが提案される。

【0091】

現在、ISPモードは全てのCUサイズに対して許容されているが、最大変換サイズが64よりも小さく設定された場合、この問題を解決するために、暗示的な変換分割を実行するか、信号伝達によってISPを使用して明示的に変換分割を実行するかの競合が存在する。ISPが暗示的な変換分割のないCUのみに適用される場合のように、ISPを許容する最大CUサイズを制限することが提案される。

【0092】

一実施形態では、シンタックステーブルの修正された変更が以下に記載される。

【表7】

【0093】

CUサイズが最大TUサイズよりも大きい場合、CUが暗示的な変換分割を使用して複数のTUに分割された後に、TUが複数の0.5w×h、w×0.5h又は0.25w×h又はw×0.25hのより小さいTUに更に分割されるか否かを示すために、ISPが各TU(サイズw×h)に更に適用されてもよい。

【0094】

一例では、CUサイズが64×16であり、最大のTUサイズが16である場合、CUは、まず、暗示的に4つの16×16のTUとして分割され、16×16のTU毎に、4つの4×16又は4つの16×4のより小さいTUに更に分割されるか否かを伝達するために、ISPが適用される。

【0095】

異なる色成分について別々に最大変換サイズを伝達することが提案される。

【0096】

一実施形態では、輝度成分について1つの最大変換サイズが伝達され、色差成分について1つの最大変換サイズが伝達される。

【0097】

1つの色成分についての最大変換サイズのみを伝達し、他の色成分に適用される最大変換サイズが暗示的に導出されることが提案される。

【0098】

一実施形態では、第1の成分について1つの最大変換サイズが伝達され、他の成分については、第1の成分に応じたダウンサンプリング比に従って、最大水平変換及び/又は垂直変換サイズは、それに従って調整される。

【0099】

一例では、現在の色成分のサンプルが水平(及び/又は垂直)において第1の色成分対してNでダウンサンプリングされる場合、すなわち、第1の色成分が水平(及び/又は垂直方向)軸に沿った現在のサンプルに対してN倍のサンプルを有する場合、現在の色成分について適用される最大水平(及び/又は垂直)変換サイズは、最大変換サイズをNで除算したものである。

【0100】

一実施形態では、輝度成分について1つの最大変換サイズが伝達され、これがYUV 444フォーマットである場合、色差成分につて適用される最大変換サイズは、輝度成分について適用される最大変換サイズと同じに設定される。

【0101】

一実施形態では、輝度成分について1つの最大変換サイズが伝達され、これがYUV 422フォーマットである場合、色差成分につて適用される最大水平変換サイズは、輝度成分について適用される最大変換サイズの半分に設定され、色差成分につて適用される最大垂直変換サイズは、輝度成分について適用される最大変換サイズと同じに設定される。

【0102】

異なる色成分について異なる変換ゼロアウト方式を適用することが提案される。

【0103】

異なる色成分の間のダウンサンプリング比が異なる場合にのみ、異なる色成分について異なる変換ゼロアウト方式を適用することが提案される。

【0104】

図１は、処理100の例示的なブロックを示しているが、いくつかの実装では、処理100は、図１に示すものよりも多いブロック、少ないブロック、異なるブロック又は異なって配置されたブロックを含んでもよい。さらに或いは代替として、処理100のブロックのうち2つ以上は並列に実行されてもよい。

【0105】

図２は、本開示の一実施形態による通信システム(200)の簡略化したブロック図を示す。通信システム(200)は、通信システム(200)は、ネットワーク(250)を介して相互接続された少なくとも2つの端末(210-220)を含む。データの一方向伝送のために。第1の端末(210)は、ネットワーク(250)を介して他の端末(220)に送信するために、ローカル位置においてビデオデータを符号化してもよい。第2の端末(220)は、ネットワーク(250)から他の端末の符号化ビデオデータを受信し、符号化データを復号して、復元されたビデオデータを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。

【0106】

図２は、例えば、テレビ会議中に発生し得る符号化ビデオの双方向伝送をサポートするために提供された第2の対の端末デバイス(230,240)を示す。データの双方向伝送のために、各端末(230,240)は、ネットワーク(250)を介して他方の端末に送信するために、ローカル位置においてキャプチャされたビデオデータを符号化してもよい。また、各端末(230,240)は、他方の端末デバイスによって送信された符号化ビデオデータを受信してもよく、符号化データを復号してもよく、ローカル表示デバイスにおいて復元されたビデオデータを表示してもよい。

【0107】

図２において、端末(210-240)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(250)は、例えば、有線及び/又は無線通信ネットワークを含む、端末(210-240)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(250)は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(250)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。

【0108】

図３は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。

【0109】

ストリーミングシステムはキャプチャサブシステム(313)を含んでもよく、当該キャプチャサブシステム(313)は、例えば、非圧縮のビデオサンプルストリーム(302)を生成するビデオソース(301)(例えば、デジタルカメラ)を含んでもよい。符号化ビデオビットストリームと比較したときに高いデータ量であることを強調するために太線として描かれる当該サンプルストリーム(302)は、カメラ(301)に結合されたエンコーダ(303)によって処理されてもよい。エンコーダ(303)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。サンプルストリームと比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオビットストリーム(304)は、将来の使用のためにストリーミングサーバ(305)に記憶されてもよい。1つ以上のストリーミングクライアント(306,308)は、ストリーミングサーバ(305)にアクセスして符号化ビデオビットストリーム(304)のコピー(307,309)を取得してもよい。クライアント(306)は、ビデオデコーダ(310)を含んでもよく、ビデオデコーダ(310)は、符号化ビデオビットストリームの入力コピー(307)を復号し、ディスプレイ(312)又は他のレンダリングデバイス(図示せず)上にレンダリングできる出力ビデオサンプルストリーム(311)を生成する。いくつかのストリーミングシステムでは、ビデオビットストリーム(304,307,309)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、ITU-T勧告H.265を含む。開発中のものは、VVC(Versatile Video Coding)として非公式に知られているビデオ符号化標準である。開示の対象物は、VVCの背景において使用されてもよい。

【0110】

図４は、本開示の一実施形態によるビデオデコーダ(310)の機能ブロック図である。

【0111】

受信機(410)は、デコーダ(310)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(412)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(410)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(410)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(415)は、受信機(410)とエントロピーデコーダ/パーサ(420)(以下、「パーサ」という)との間に結合されてもよい。受信機(410)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファ(415)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファ(415)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができる。

【0112】

ビデオデコーダ(310)は、エントロピー符号化ビデオシーケンスからシンボル(421)を復元するためのパーサ(420)を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ(310)の動作を管理するために使用される情報を含み、ディスプレイ(312)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該レンダリングデバイス(312)は、図４に示されているように、デコーダの一体的な部分ではないが、デコーダに結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplementary Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(420)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む、当業者に周知の原理に従ってもよい。パーサ(420)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、エントロピーデコーダ/パーサは、符号化ビデオシーケンスから、変換係数、量子化パラメータ(QP, quantizer parameter)値、動きベクトル等のような情報を抽出してもよい。

【0113】

パーサ(420)は、シンボル(421)を生成するために、バッファ(415)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。パーサ(420)は、符号化データを受信し、特定のシンボル(421)を選択的に復号してもよい。さらに、パーサ(420)は、特定のシンボル(421)が動き補償予測ユニット(453)、スケーラ/逆変換ユニット(451)、イントラ予測ユニット(452)又はループフィルタ(456)に提供されるべきであるか否かを決定してもよい。

【0114】

シンボル(421)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(420)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(420)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。

【0115】

上記の機能ブロックの他に、デコーダ(310)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。

【0116】

第1のユニットは、スケーラ/逆変換ユニット(451)である。スケーラ/逆変換ユニット(451)は、パーサ(420)からシンボル(621)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(451)は、アグリゲータ(455)に入力できるサンプル値を含むブロックを出力してもよい。

【0117】

場合によっては、スケーラ/逆変換(451)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(452)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(452)は、カレントピクチャ(部分的に復元されたピクチャ)(454)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。場合によっては、アグリゲータ(455)は、サンプル毎に、イントラ予測ユニット(452)が生成した予測情報を、スケーラ/逆変換ユニット(451)によって提供された出力サンプル情報に追加する。

【0118】

他の場合には、スケーラ/逆変換ユニット(451)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(453)は、参照ピクチャメモリ(457)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(421)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(455)によってスケーラ/逆変換ユニットの出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償ユニットに利用可能な、動き補償ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(421)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリから取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。

【0119】

アグリゲータ(455)の出力サンプルは、ループフィルタユニット(456)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオビットストリームに含まれるパラメータによって制御され、パーサ(420)からシンボル(421)としてループフィルタユニット(456)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。

【0120】

ループフィルタユニット(456)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(312)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(456)に記憶されてもよい。

【0121】

特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(420)によって)参照ピクチャとして識別されると、カレント参照ピクチャ(656)は参照ピクチャバッファ(457)の一部となってもよく、新たなカレントピクチャメモリが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。

【0122】

ビデオデコーダ(310)は、ITU-T Rec. H.265のような標準において文書化され得る所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術又は標準のシンタックス及びビデオ圧縮技術文書又は標準に指定されており、特にその文書のプロファイルに指定されているようにビデオ圧縮技術又は標準のシンタックスに従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。

【0123】

一実施形態では、受信機(410)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(310)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号対雑音比(SNR, signal-to-noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。

【0124】

図５は、本開示の一実施形態によるビデオエンコーダ(303)の機能ブロック図でもよい。

【0125】

エンコーダ(303)は、ビデオソース(301)(エンコーダの一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(301)は、エンコーダ(303)によって符号化されるべきビデオ画像をキャプチャしてもよい。

【0126】

ビデオソース(301)は、デジタルビデオサンプルストリームの形式でビデオエンコーダ(303)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(301)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(303)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。

【0127】

一実施形態によれば、エンコーダ(303)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(543)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(550)の1つの機能である。コントローラは、以下に説明するように、他の機能ユニットを制御し、これらのユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。当業者は、特定のシステム設計のために最適化されたビデオエンコーダ(303)に関連し得る他の機能を容易に識別できる。

【0128】

いくつかのビデオエンコーダは、当業者が「符号化ループ(coding loop)として容易に認識するもので動作する。非常に簡略化した説明として、符号化ループは、エンコーダ(530)(以下、「ソースコーダ」と言う)の符号化部(例えば、符号化されるべき入力ピクチャ及び参照ピクチャに基づいてシンボルを生成することを担う)と、エンコーダ(303)に埋め込まれた(ローカル)デコーダ(533)で構成されてもよい。デコーダ(533)は、(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、(リモート)デコーダが生成するサンプルデータを生成するようにシンボルを復元する。復元されたサンプルストリームは、参照ピクチャメモリ(534)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャバッファの内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、当業者に周知である。

【0129】

「ローカル」デコーダ(533)の動作は、「リモート」デコーダ(310)と同じでもよく、これは、図４に関連して上記において既に詳細に説明した。しかし、図５を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(545)及びパーサ(420)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、チャネル(412)、受信機(410)、バッファメモリ(415)及びパーサ(420)を含むデコーダ(310)のエントロピー復号部分は、ローカルデコーダ(533)に完全には実装されなくてもよい。

【0130】

この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。

【0131】

その動作の一部として、ソースコーダ(530)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照フレーム」として指定されたビデオシーケンスからの1つ以上の前に符号化されたフレームを参照して入力フレームを予測的に符号化する。このように、符号化エンジン(532)は、入力フレームの画素ブロックと、入力フレームに対する予測参照として選択され得る参照フレームの画素ブロックとの間の差を符号化する。

【0132】

ローカルビデオデコーダ(533)は、ソースコーダ(530)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータを復号してもよい。符号化エンジン(532)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図５に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(533)は、参照フレームに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照フレームを参照ピクチャキャッシュ(534)に記憶させてもよい。このように、エンコーダ(303)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照フレームとして、共通の内容を有する復元された参照フレームのコピーをローカルに記憶してもよい。

【0133】

予測器(535)は、符号化エンジン(532)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなフレームについて、予測器(535)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(534)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(535)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block-by-pixel block)に動作してもよい。場合によっては、予測器(535)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(534)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。

【0134】

コントローラ(550)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ(530)の符号化動作を管理してもよい。

【0135】

全ての上記の機能ユニットの出力は、エントロピーコーダ(545)におけるエントロピー符号化を受けてもよい。エントロピーコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化等のような、当業者に既知の技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。

【0136】

送信機(540)は、エントロピーコーダ(545)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(560)を介した送信のために準備をしてもよく、当該通信チャネル(560)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(540)は、ビデオコーダ(530)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。

【0137】

コントローラ(550)は、エンコーダ(303)の動作を管理してもよい。符号化中に、コントローラ(550)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のフレームタイプのうち1つとして割り当てられてもよい。

【0138】

イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のフレームを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。

【0139】

予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。

【0140】

双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。

【0141】

一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。

【0142】

ビデオコーダ(303)は、ITU-T Rec. H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオコーダ(303)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。

【0143】

一実施形態では、送信機(540)は、符号化ビデオと共に更なるデータを送信してもよい。ビデオコーダ(530)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、補足エンハンスメント情報(SEI, Supplementary Enhancement Information)メッセージ、ビジュアルユーザビリティ情報(Visual Usability Information, VUI)パラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。

【0144】

さらに、提案される方法は、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では、1つ以上のプロセッサは、提案される方法のうち1つ以上を実行するように非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。

【0145】

上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図６は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム(600)を示す。

【0146】

コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、コンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。

【0147】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。

【0148】

コンピュータシステム(600)について図６に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム(600)の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。

【0149】

コンピュータシステム(600)は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。

【0150】

入力ヒューマンインタフェースデバイスは、キーボード(601)、マウス(602)、トラックパッド(603)、タッチ画面(610)、データグローブ(1204)、ジョイスティック(605)、マイクロフォン(606)、スキャナ(607)、カメラ(608)のうち1つ以上を含んでもよい。

【0151】

また、コンピュータシステム(600)は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面(610)、データグローブ(1204)又はジョイスティック(605)による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ(609)、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよい陰極線管(CRT, cathode ray tube)画面、液晶ディスプレイ(LCD, liquid-crystal display)画面、プラズマ画面、有機発光ダイオード(OLED, organic light-emitting diode)画面を含む画面(610)、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。

【0152】

また、コンピュータシステム(600)は、CD/DVD又は同様の媒体(621)を有するCD/DVD ROM/RW(620)を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ(622)、取り外し可能ハードドライブ又はソリッドステートドライブ(623)、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。

【0153】

また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。

【0154】

また、コンピュータシステム(600)は、1つ以上の通信ネットワークへのインタフェースを含んでもよい。ネットワークは、例えば、無線、有線、光でもよい。ネットワークは、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。ネットワークの例は、イーサネット、無線LAN、セルラネットワーク(GSM(global system for mobile communications)、3G(third generation)、4G(fourth generation)、5G(fifth generation)、LTE(long term evolution)等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワークは、一般的に、特定の汎用データポート又は周辺バス(649)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム(600)のUSB(universal serial bus)ポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム(600)のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム(600)は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。

【0155】

上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム(600)のコア(640)に取り付けられてもよい。

【0156】

コア(640)は、1つ以上の中央処理装置(CPU)(641)、グラフィックス処理ユニット(GPU)(642)、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)(643)の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ(644)等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)(645)、ランダムアクセスメモリ(RAM)(646)、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、ソリッドステートドライブ(SSD, solid-state drive)等)(647)と共に、システムバス(648)を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス(648)は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス(648)に直接取り付けられてもよく、或いは、周辺バス(649)を通じて取り付けられてもよい。周辺バスのアーキテクチャは、PCI(peripheral component interconnect)、USB等を含む。

【0157】

CPU(641)、GPU(642)、FPGA(643)及びアクセラレータ(644)は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM(645)又はRAM(646)に記憶されてもよい。また、一時的なデータは、RAM(646)に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置(647)に記憶されてもよい。1つ以上のCPU(641)、GPU(642)、大容量記憶装置(647)、ROM(645)、RAM(646)等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。

【0158】

コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。

【0159】

限定ではなく一例として、アーキテクチャ(600)、具体的には、コア(640)を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供できる。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置(647)又はROM(645)のような非一時的な性質のコア(640)の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア(640)によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア(640)、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM(646)に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ(644))内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。

【0160】

本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。

【0161】

［略語］
HEVC: High Efficiency Video Coding
HDR: high dynamic range
SDR: standard dynamic range
VVC: Versatile Video Coding
JVET: Joint Video Exploration Team
MPM: most probable mode
WAIP: Wide-Angle Intra Prediction
CU: Coding Unit
PU: Prediction Unit
ISP: Intra Sub-Partitions
SBT: Sub-block transform
CBF: Coded block flag

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】