特表 2022-526007 フレキシブルな画像分割

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-05-20

(54)【発明の名称】フレキシブルな画像分割

(51)【国際特許分類】

   H04N 19/85 20140101AFI20220513BHJP

   H04N 19/46 20140101ALI20220513BHJP

【ＦＩ】

H04N19/85

H04N19/46

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021559114

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

(85)【翻訳文提出日】2021-10-01

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

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

(87)【国際公開日】2021-08-19

(31)【優先権主張番号】62/975,505

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

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

(31)【優先権主張番号】17/098,918

(32)【優先日】2020-11-16

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャオ，リアン

(72)【発明者】

【氏名】ジャオ，シン

(72)【発明者】

【氏名】ドゥ，イシン

(72)【発明者】

【氏名】リィウ，シャン

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159KK14

5C159LC10

5C159PP16

5C159RC11

5C159TA12

5C159TB08

5C159TC32

5C159UA02

5C159UA05

(57)【要約】

システム及び方法は、フレキシブルな画像分割を提供することができ、方法は、複数のコーディングツリーユニット（ＣＴＵ）に分割されるコード化された画像を受信するステップであって、コード化された画像の境界に隣接する、コード化された画像の複数のＣＴＵのうちのＣＴＵの少なくとも１つの行又は列は、コード化された画像のいずれの境界に隣接しない複数のＣＴＵのうちの各ＣＴＵの対応するサイズ寸法より小さいサイズ寸法を有する、ステップと；複数のＣＴＵに基づいてコード化された画像をデコードするステップであって、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の上境界又は左境界にそれぞれ隣接する、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列を含む、ステップとを含む。

【特許請求の範囲】

【請求項1】

少なくとも１つのプロセッサによって実行される方法であって、前記方法は：
複数のコーディングツリーユニット（ＣＴＵ）に分割されるコード化された画像を受信するステップであって、前記コード化された画像の前記複数のＣＴＵの中の前記コード化された画像の境界に隣接するＣＴＵの少なくとも１つの行又は列は、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵの対応するサイズ寸法より小さいサイズ寸法を有する、ステップと；
前記複数のＣＴＵに基づいて前記コード化された画像をデコードするステップと；を含み、
前記ＣＴＵの少なくとも１つの行又は列は、前記コード化された画像の上境界又は左境界にそれぞれ隣接する前記コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列を含む、
方法。

【請求項2】

前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵは、同じサイズを有する、
請求項１に記載の方法。

【請求項3】

前記ＣＴＵの少なくとも１つの行又は列は、前記コード化された画像の前記左境界に隣接する前記第１のＣＴＵ列と、前記コード化された画像の右境界に隣接する最後のＣＴＵ列とを含み、
前記第１のＣＴＵ列及び前記最後のＣＴＵ列は、各々、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵの幅より小さい幅を有する、
請求項２に記載の方法。

【請求項4】

前記ＣＴＵの少なくとも１つの行又は列は、前記コード化された画像の前記上境界に隣接する前記第１のＣＴＵ行と、前記コード化された画像の下境界に隣接する最後のＣＴＵ行とをさらに含み、
前記第１のＣＴＵ行及び前記最後のＣＴＵ行は、各々、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵの高さより小さい高さを有する、
請求項３に記載の方法。

【請求項5】

前記ＣＴＵの少なくとも１つの行又は列は、前記コード化された画像の前記上境界に隣接する前記第１のＣＴＵ行と、前記コード化された画像の下境界に隣接する最後のＣＴＵ行とを含み、
前記第１のＣＴＵ行及び前記最後のＣＴＵ行は、各々、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵの高さより小さい高さを有する、
請求項２に記載の方法。

【請求項6】

前記コード化された画像をデコードするステップは、前記ＣＴＵの少なくとも１つの行又は列の中から、前記コード化された画像の前記上境界又は前記左境界に隣接している、前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法を信号送信することを含む、
請求項１乃至５のいずれか１項に記載の方法。

【請求項7】

前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法は、２の累乗である正の整数である、
請求項１乃至６のいずれか１項に記載の方法。

【請求項8】

前記コード化された画像をデコードするステップは：
前記ＣＴＵの少なくとも１つの行又は列の中から、前記コード化された画像の前記左境界又は前記上境界に隣接する、前記第１のＣＴＵ行又は前記第１のＣＴＵ列のサイズ寸法が、最大許容ＣＴＵサイズに等しいかどうかを示す第１のフラグを信号送信することと；
前記第１のフラグに基づいて、前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法が、前記最大許容ＣＴＵサイズに等しくないことを決定することと；
前記決定することに基づいて、前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法を示す第２のフラグを信号送信することと；
を含む、
請求項１乃至５のいずれか１項に記載の方法。

【請求項9】

前記コード化された画像をデコードするステップは：
前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法が所定値以上であり、前記ＣＴＵの少なくとも１つの行又は列の中から前記第１のＣＴＵ行又は前記第１のＣＴＵ列の別のサイズ寸法が前記所定値未満であると決定することに基づいて、前記ＣＴＵの少なくとも１つの行又は列の中から、前記コード化された画像の前記第１のＣＴＵ行又は前記第１のＣＴＵ列のＣＴＵレベルで、水平又は垂直分割を禁止すること、を含み、
前記サイズ寸法は高さ及び幅のうちの一方であり、前記別のサイズ寸法は前記高さ及び前記幅のうちの他方であり、
前記所定値は６４より大きい２の累乗の値である、
請求項１乃至８のいずれか１項に記載の方法。

【請求項10】

前記コード化された画像をデコードするステップは：
前記ＣＴＵの少なくとも１つの行又は列の中から、前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法が所定値以上であり、前記ＣＴＵの少なくとも１つの行又は列の中からの前記第１のＣＴＵ行又は前記第１のＣＴＵ列の別のサイズ寸法が前記所定値未満であると決定することに基づいて、前記コード化された画像の前記第１のＣＴＵ行又は前記第１のＣＴＵ列のＣＴＵレベルでの水平方向トリプルツリー（ＴＴ）又は垂直ＴＴ分割を禁止させること、を含み、
前記サイズ寸法は高さ及び幅のうちの一方であり、前記別のサイズ寸法は前記高さ及び幅のうちの他方であり、
前記所定値は６４より大きい２の累乗の値である、
請求項１乃至８のいずれか１項に記載の方法。

【請求項11】

前記第１のＣＴＵ行又は最後のＣＴＵ行の高さが最大ＣＴＵサイズより小さく、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵ間の各ＣＴＵは、前記最大ＣＴＵサイズに等しい高さを有し、前記第１のＣＴＵ行又は前記最後のＣＴＵ行が他のＣＴＵより小さいかどうかの決定は、ビットストリーム内の１つの構文によって示される、又は
前記第１のＣＴＵ列又は最後のＣＴＵ列の幅が前記最大ＣＴＵサイズより小さく、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵ間の各ＣＴＵは、前記最大ＣＴＵサイズに等しい幅を有し、前記第１のＣＴＵ列又は前記最後のＣＴＵ列が他のＣＴＵ列より小さいかどうかの決定は、前記ビットストリーム内の１つの構文によって示される、
請求項１又は２に記載の方法。

【請求項12】

コンピュータプログラムコードを記憶するように構成された少なくとも１つのメモリと；
前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって指示されるように動作するように構成された少なくとも１つのプロセッサと；を有し、
前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、請求項１乃至１１のいずれか１項に記載の方法を実行させる、
システム。

【請求項13】

コンピュータ命令を含むコンピュータプログラムであって、前記コンピュータ命令は、少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに、請求項１乃至１１のいずれか１項に記載の方法を実行させる、
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本出願は、2020年2月12日に出願された米国仮出願第６2/975,505号、2020年11月16日に出願された米国特許出願第１7/098,918号からの優先権を主張し、これらの開示は、その全体が参照により本明細書に組み込まれる。

【0002】

本開示の実施形態は、一連の先進的なビデオコーディング技術に関する。より具体的には、本開示の実施形態は、フレキシブルな画像分割（flexible picture partitioning）を提供し得る。

【背景技術】

【0003】

AOMedia Video 1（ＡＶ１）は、インターネットを介したビデオ伝送用に設計されたオープンビデオコーディングフォーマットである。それは、半導体企業、ビデオオンデマンドプロバイダ、ビデオコンテンツプロデューサ、ソフトウェア開発企業、ウェブブラウザベンダーを含む2015年に設立されたコンソーシアムであるAlliance for Open Media（AOMedia）によって、ＶＰ９の後継として開発された。ＡＶ１プロジェクトのコンポーネントの多くは、アライアンスメンバーによるこれまでの研究活動から提供されたものである。個々の貢献者は、数年前に実験的な技術プラットフォームを開始した：Xiph/Mozillaの Daalaは2010年にコードを発表し、Googleの実験的なＶＰ９進化プロジェクトVP10は2014年9月12日に発表され、CiscoのThorは2015年8月11日に発表された。ＶＰ９のコードベースに基づいて、ＡＶ１には追加の技術が組み込まれており、そのいくつかはこれらの実験フォーマットで開発された。ＡＶ１リファレンスコーデックの最初のバージョン、バージョン0.1.0は、2016年4月7日に発表された。アライアンスは、2018年3月28日に、ＡＶ１ビットストリーム仕様のリリースを、リファレンス、ソフトウェアベースのエンコーダ及びデコーダと共に発表した。2018年6月25日に、検証済みのバージョン1.0.0の仕様がリリースされた。2019年1月8日に「ＡＶ１ビットストリーム＆デコーディングプロセス仕様」がリリースされ、これは、本仕様のErrata 1を伴う検証されたバージョン1.0.0である。ＡＶ１ビットストリーム仕様は、リファレンスビデオコーデックを含む。「ＡＶ１ビットストリーム＆デコーディングプロセス仕様」（Errata 1を伴うバージョン1.0.0）、The Alliance for Open Media（2019年1月8日）は、参照によりその全体が本明細書に組み込まれる。

【0004】

IＴＵ-T VCEG （Q6/16）及びISO/IEC MPEG （JTC 1/SC 29/WG 11）は、2013年にH.265/HEVC （High Efficiency Video Coding）規格のバージョン1、2014年にバージョン2、2015年にバージョン3、2016年にバージョン4を発行された。2015年には、これら２つの標準組織が共同でJoint Video Exploration Team（JVET）を結成し、HEVCを越えた次世代のビデオコーディング規格の開発の可能性を探った。2017年10月には、JVETはHEVC（CfP）を超える能力を持つ映像圧縮に関する提案を共同で募集した。2018年2月15日までに、スタンダードダイナミックレンジ（SDR）で合計22のCfP回答、高ダイナミックレンジ（HDR）で12のCfP回答、及び360ビデオカテゴリで12のCfP回答がそれぞれ提出された。2018年4月には、122 MPEG/第１0回JVET会議において、すべてのCfP回答が評価された。この会議の結果、JVETは、HEVCを超えた次世代ビデオコーディングの標準化プロセスを正式に開始した。この新しい標準はVersatile Video Coding（ＶＶＣ）と命名され、JVETはJoint Video Expert Teamに改名された。ＶＶＣ規格、「Versatile Video Coding（Draft 7）」、JVET-P2001-vE、Joint Video Experts Team（2019年10月）の仕様は、その全体が参照により本明細書に組み込まれる。

【発明の概要】

【0005】

H.264/AVC、HEVC、ＶＶＣ、及びＡＶ１のような現代のビデオコーディング規格では、画像はラスタスキャン順序でＣＴＵのシーケンスに分割され、ＣＴＵのサイズは、画像の右側又は下側の境界に位置するものを除き、互いに同じである。しかし、オブジェクト境界がこの固定ピクチャ分割と整列しない場合、オブジェクトの境界及び動きを信号送信する（signal）ために、より多くのビットが必要となる。

【0006】

本開示のいくつかの実施形態は、上記の問題及び他の問題に対処する。

【0007】

１つ又は複数の実施形態によれば、少なくとも１つのプロセッサによって実行される方法が提供される。本方法は：複数のコーディングツリーユニット（ＣＴＵ）に分割されるコード化された画像を受信するステップであって、前記コード化された画像の複数のＣＴＵの中の前記コード化された画像の境界に隣接するＣＴＵの少なくとも１つの行又は列は、前記コード化された画像のいずれの境界にも隣接しない前記複数のＣＴＵの中の各ＣＴＵの対応するサイズ寸法より小さいサイズ寸法を有する、ステップと；前記複数のＣＴＵに基づいて前記コード化された画像をデコードするステップであって、前記ＣＴＵの少なくとも１つの行又は列は、前記コード化された画像の上境界又は左境界にそれぞれ隣接する前記コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列を含む、ステップと；を含み得る。

【0008】

一実施形態によれば、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵは、同じサイズを有する。

【0009】

一実施形態によれば、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の左境界に隣接する第１のＣＴＵ列と、コード化された画像の右境界に隣接する最後のＣＴＵ列とを含み、第１のＣＴＵ列及び最後のＣＴＵ列は、各々、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの幅よりも小さい幅を有する。

【0010】

一実施形態によれば、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の上境界に隣接する第１のＣＴＵ行と、コード化された画像の下境界に隣接する最後のＣＴＵ行とを含み、第１のＣＴＵ行及び最後のＣＴＵ行は、各々、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの高さよりも小さい高さを有する。

【0011】

一実施形態によれば、コード化された画像をデコードするステップは、ＣＴＵの少なくとも１つの行又は列の中から、コード化された画像の上境界又は左境界に隣接する、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法を信号送信する（signaling）ステップを含む。

【0012】

一実施形態によれば、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法は、２の累乗である正の整数である。

【0013】

一実施形態によれば、コード化された画像をデコードするステップは：ＣＴＵの少なくとも１つの行又は列の中から、コード化された画像の左境界又は上境界に隣接する、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が、最大許容ＣＴＵサイズに等しいかどうかを示す第１のフラグを信号送信するステップと；第１のフラグに基づいて、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が、最大許容ＣＴＵサイズに等しくないことを決定するステップと；決定に基づいて、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法を示す第２のフラグを信号送信するステップと；を含む。

【0014】

一実施形態によれば、コード化された画像をデコードするステップは：ＣＴＵの少なくとも１つの行又は列の中から、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が所定値以上であり、ＣＴＵの少なくとも１つの行又は列の中から第１のＣＴＵ行又は第１のＣＴＵ列の別のサイズ寸法が所定値未満であると決定することに基づいて、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列のＣＴＵレベルでの水平方向又は垂直方向の分割を禁止するステップを含み、前記サイズ寸法は、高さ及び幅のうちの一方であり、前記別のサイズ寸法は、高さ及び幅のうちの他方であり、前記所定値は６４より大きい２の累乗の値である。

【0015】

一実施形態によれば、コード化された画像をデコードするステップは：ＣＴＵの少なくとも１つの行又は列の中から、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が所定値以上でありＣＴＵの少なくとも１つの行又は列の中から第１のＣＴＵ行又は第１のＣＴＵ列の別のサイズ寸法が所定値未満であると決定することに基づいて、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列のＣＴＵレベルで、水平トリプルツリー（ＴＴ）又は垂直ＴＴ分割を禁止するステップを含み、前記サイズ寸法は高さ及び幅のうちの一方であり、前記別のサイズ寸法は高さ及び幅のうちの他方であり、前記所定値は６４より大きい２の累乗の値である。

【0016】

実施形態によれば、第１のＣＴＵ行又は最後のＣＴＵ行の高さは、最大ＣＴＵサイズより小さく、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵ間の各ＣＴＵは、最大ＣＴＵサイズに等しい高さを有し、第１のＣＴＵ行又は最後のＣＴＵ行が他のＣＴＵより小さいかどうかの決定は、ビットストリーム内の１つの構文によって示される、又は、第１のＣＴＵ列又は最後のＣＴＵ列の幅は、最大ＣＴＵサイズより小さく、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵ間の各ＣＴＵは、最大ＣＴＵサイズに等しい幅を有し、第１のＣＴＵ列又は最後のＣＴＵ列が他のＣＴＵより小さいかどうかの決定は、ビットストリーム内の１つの構文によって示される。

【0017】

１つ又は複数の実施形態によれば、システムが提供される。システムは：コンピュータプログラムコードを記憶するように構成された少なくとも１つのメモリと；前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって指示されるように動作するように構成された少なくとも１つのプロセッサと；を含み、前記コンピュータプログラムコードは：前記少なくとも１つのプロセッサに、複数のコーディングツリーユニット（ＣＴＵ）に分割されるコード化された画像をデコードさせるように構成されたデコーディングコードを含む。コード化された画像の複数のＣＴＵの中の、コード化された画像の境界に隣接するＣＴＵの少なくとも１つの行又は列は、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの対応するサイズ寸法よりも小さいサイズ寸法を有し得、デコーディングコードは、少なくとも１つのプロセッサに、複数のＣＴＵに基づいてコード化された画像をデコードさせるように構成され得、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の上境界又は左境界にそれぞれ隣接する、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列を含み得る。

【0018】

一実施形態によれば、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵは、同じサイズを有する。

【0019】

一実施形態によれば、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の左境界に隣接する第１のＣＴＵ列と、コード化された画像の右境界に隣接する最後のＣＴＵ列とを含み、第１のＣＴＵ列及び最後のＣＴＵ列は、各々、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの幅より小さい幅を有する。

【0020】

一実施形態によれば、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の上境界に隣接する第１のＣＴＵ行と、コード化された画像の下境界に隣接する最後のＣＴＵ行とを含む又はさらに含み、第１のＣＴＵ行及び最後のＣＴＵ行は、各々、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの高さより小さい高さを有する。

【0021】

一実施形態によれば、デコーディングコードは、少なくとも１つのプロセッサに、ＣＴＵの少なくとも１つの行又は列の中から、コード化された画像の上境界又は左境界に隣接している、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法を信号送信させるようにさらに構成される。

【0022】

一実施形態によれば、デコーディングコードは、少なくとも１つのプロセッサに：ＣＴＵの少なくとも１つの行又は列の中から、コード化された画像の左境界又は上境界に隣接する、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が、最大許容ＣＴＵサイズに等しいかどうかを示す第１のフラグを信号送信させ；第１のフラグに基づいて、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が、最大許容ＣＴＵサイズに等しくないことを決定させ；前記決定に基づいて、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法を示す第２のフラグを信号送信させる；ようにさらに構成される。

【0023】

一実施形態によれば、デコーディングコードは、前記少なくとも１つのプロセッサに：前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法が所定値以上であり、ＣＴＵの少なくとも１つの行又は列の中から前記第１のＣＴＵ行又は前記第１のＣＴＵ列の別のサイズ寸法が前記所定値未満であると決定することに基づいて、前記ＣＴＵの少なくとも１つの行又は列の中から、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列のＣＴＵレベルで、水平又は垂直分割を禁止させるようにさらに構成され、前記サイズ寸法は高さ及び幅のうちの一方であり、前記別のサイズ寸法は前記高さ及び前記幅のうちの他方であり、前記所定値は６４より大きい２の累乗の値である。

【0024】

一実施形態によれば、デコーディングコードは、前記少なくとも１つのプロセッサに：前記第１のＣＴＵ行又は前記第１のＣＴＵ列の前記サイズ寸法が所定値以上であり、前記ＣＴＵの少なくとも１つの行又は列の中からの前記第１のＣＴＵ行又は前記第１のＣＴＵ列の別のサイズ寸法が前記所定値未満であると決定することに基づいて、ＣＴＵの少なくとも１つの行又は列の中から、前記コード化された画像の前記第１のＣＴＵ行又は前記第１のＣＴＵ列のＣＴＵレベルでの水平トリプルツリー（ＴＴ）又は垂直ＴＴ分割を禁止させるようにさらに構成され、前記サイズ寸法は高さ及び幅のうちの一方であり、前記別のサイズ寸法は前記高さ及び幅のうちの他方であり、前記所定値は６４より大きい２の累乗の値である。

【0025】

１つ又は複数の実施形態によれば、コンピュータ命令を記憶する非一時的なコンピュータ読取可能媒体が提供される。コンピュータ命令は、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに：複数のコーディングツリーユニット（ＣＴＵ）に分割されるコード化された画像をデコードさせるように構成され得、コード化された画像の境界に隣接する、コード化された画像の複数のＣＴＵの中のＣＴＵの少なくとも１つの行又は列は、コード化された画像のいずれの境界にも隣接しない複数のＣＴＵの中の各ＣＴＵの対応するサイズ寸法より小さいサイズ寸法を有し、コンピュータ命令は、少なくとも１つのプロセッサに、複数のＣＴＵに基づいてコード化された画像をデコードさせるように構成され、ＣＴＵの少なくとも１つの行又は列は、コード化された画像の上境界又は左境界にそれぞれ隣接する、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列を含む。

【図面の簡単な説明】

【0026】

開示された主題のさらなる特徴、性質、及び種々の利点は、以下の詳細な説明及び添付の図面からより明らかになるであろう。

【0027】

【図1】一実施形態による通信システムの簡略ブロック図の概略図である。

【0028】

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

【0029】

【図3】一実施形態によるデコーダの簡略ブロック図の概略図である。

【0030】

【図4】一実施形態によるエンコーダの簡略ブロック図の概略図である。

【0031】

【図5】ＣＴＵに分割された画像の例示的な図である。

【0032】

【図6A】ＶＴＭにおけるパーティション制限の第１の例を説明するためのブロックの例示的な図である。

【0033】

【図6B】ＶＴＭにおけるパーティション制限の第２の例を説明するためのブロックの例示的な図である。

【0034】

【図6C】ＶＴＭにおけるパーティション制限の第３の例を説明するためのブロックの例示的な図である。

【0035】

【図6D】ＶＴＭにおけるパーティション制限の第４の例を説明するためのブロックの例示的な図である。

【0036】

【図6E】ＶＴＭにおけるパーティション制限の第５の例を説明するためのブロックの例示的な図である。

【0037】

【図6F】ＶＴＭにおけるパーティション制限の第６の例を説明するためのブロックの例示的な図である。

【0038】

【図6G】ＶＴＭにおけるパーティション制限の第７の例を説明するためのブロックの例示的な図である。

【0039】

【図6H】ＶＴＭにおけるパーティション制限の第８の例を説明するためのブロックの例示的な図である。

【0040】

【図7A】マルチタイプツリー構造における垂直二分割タイプを示すための図である。

【0041】

【図7B】マルチタイプツリー構造における水平二分割タイプを示すための図である。

【0042】

【図7C】マルチタイプツリー構造における垂直三分割タイプを示すための図である。

【0043】

【図7D】マルチタイプツリー構造における水平三分割タイプを示すための図である。

【0044】

【図8】ネストされたマルチタイプツリーコーディングツリー構造を持つクワッドツリー内のパーティション分割情報のシグナリングメカニズムを示す図である。

【0045】

【図9】クワッドツリー及びネストされたマルチタイプツリーコーディングブロック構造を持つ複数のＣＵに分割されたＣＴＵを示す例示的な図である。

【0046】

【図10A】ＶＰ９の第１の例示的なパーティション構造を示す図である。

【0047】

【図10B】ＶＰ９の第２の例示的なパーティション構造を示す図である。

【0048】

【図10C】ＶＰ９の第３の例示的なパーティション構造を示す図である。

【0049】

【図10D】ＶＰ９の第４の例示的なパーティション構造を示す図である。

【0050】

【図11A】ＡＶ１の第１の例示的なパーティション構造を示す図である。

【0051】

【図11B】ＡＶ１の第２の例示的なパーティション構造を示す図である。

【0052】

【図11C】ＡＶ１の第３の例示的なパーティション構造を示す図である。

【0053】

【図11D】ＡＶ１の第４の例示的なパーティション構造を示す図である。

【0054】

【図11E】ＡＶ１の第５の例示的なパーティション構造を示す図である。

【0055】

【図11F】ＡＶ１の第６の例示的なパーティション構造を示す図である。

【0056】

【図11G】ＡＶ１の第７の例示的なパーティション構造を示す図である。

【0057】

【図11H】ＡＶ１の第８の例示的なパーティション構造を示す図である。

【0058】

【図11I】ＡＶ１の第９の例示的なパーティション構造を示す図である。

【0059】

【図11J】ＡＶ１の第１０の例示的なパーティション構造を示す図である。

【0060】

【図12】本開示の一実施形態による複数のＣＴＵに分割された画像を示す図である。

【0061】

【図13】本開示の一実施形態による複数のＣＴＵに分割された画像を示す図である。

【0062】

【図14】本開示の一実施形態による複数のＣＴＵに分割された画像を示す図である。

【0063】

【図15】本開示の一実施形態による複数のＣＴＵに分割された画像を示す図である。

【0064】

【図16】本開示の一実施形態によるデコーダの概略図である。

【0065】

【図17】本開示の実施形態を実装するのに適したコンピュータシステムの図である。

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

【0066】

［画像のＣＴＵへの分割］

【0067】

画像は、コーディングツリーユニット（ＣＴＵ）のシーケンスに分割され得、スーパーブロック（ＳＢ）とも呼ばれ得る。ＨＥＶＣ及びＶＶＣにおけるＣＴＵ概念は、ＡＶ１におけるＳＢ概念と類似している。３つのサンプルアレイを持つ画像の場合、ＣＴＵは、クロマ（彩度）（chroma）サンプルの２つの対応するブロックとともにルマ（輝度）（luma）サンプルのＮ×Ｎブロックから構成され得る又はそれらからなり得る。図５は、ＣＴＵ（５１０）に分割された画像（５００）の一例を示す。

【0068】

ＣＴＵのルマブロックの最大許容サイズは１２８×１２８である（ただし、ルマ変換ブロックの最大サイズは６４×６４である）。

【0069】

仮想パイプラインデータユニット（ＶＰＤＵ）は、画像内の重複しないユニットとして定義され得る。ハードウェアデコーダでは、連続するＶＰＤＵは、同時に複数のパイプラインステージによって処理され得る。ＶＰＤＵサイズはほとんどのパイプラインステージのバッファサイズにほぼ比例するので、ＶＰＤＵサイズを小さく保つことが重要であり得る。ほとんどのハードウェアデコーダでは、ＶＰＤＵサイズは最大変換ブロック（ＴＢ）サイズに設定することができる。

【0070】

ＶＰＤＵサイズを６４×６４ルマサンプルとして維持するために、以下の基準となるパーティション制限（構文シグナリング修正を伴う）が、１２８×１２８のサイズを有するＣＴＵのブロック（５２０）を示す、図６Ａ～Ｈに示すような、ＶＶＣテストモデル（ＶＴＭ）に適用され得、ブロック（５２０）は細線で示される４つのＶＰＤＵに分割され、ＣＵに対する許可されない分割はパーティション線（５２７）で示される:
・ ＣＵの幅又は高さの一方又は両方が１２８に等しい場合、ＣＵに対してトリプルツリー（ＴＴ）分割は許可されない。例えば、ＴＴ分割は、図６Ａ-Ｂ及び６Ｅ-Ｈに示されるように、ＣＵに対して許可されないことがある。
・ Ｎ≦６４（すなわち、幅が１２８で高さが１２８以下）の１２８×ＮのＣＵに対して、水平二分木（ＢＴ）は許可されない。例えば、水平ＢＴ分割は、図６Ｄに示されるように、ＣＵに対して許可されないことがある。
・ Ｎ≦６４（すなわち、高さが１２８で幅が６４以下）のＮ×１２８のＣＵに対して、垂直ＢＴは許可されない。例えば、垂直ＢＴ分割は、図６Ｃに示されるように、ＣＵに対して許可されないことがある。

【0071】

ＨＥＶＣ及びＶＶＣでは、ツリーノードブロックの一部が下又は右画像境界を超える場合、ツリーノードブロックは、すべてのコード化されたＣＵのすべてのサンプルが画像境界内に配置されるまで、強制的に分割される可能性がある。

【0072】

［ＶＶＣにおけるネストされたマルチタイプツリーコーディングブロック構造を持つクワッドツリー（四分ツリー）（Quadtree）］

【0073】

ＨＥＶＣにおいて、ＣＴＵは、様々な局所特性に適応するために、コーディングツリーとして示されるクワッドツリー（ＱＴ）構造を使用することによってＣＵに分割され得る。画像間（時間的）又は画像内（空間的）予測を使用して画像領域をコード化するかどうかの決定は、ＣＵレベルで行われ得る。各ＣＵは、さらに、ＰＵ分割タイプに応じて、１、２、又は４つの予測ユニット（ＰＵ）に分割することができる。１つのＰＵの内部では、同じ予測プロセスが適用され、関連情報がＰＵベースでデコーダに送信される。ＰＵ分割タイプに基づく予測プロセスを適用することによって残余ブロックを得た後、ＣＵを、ＣＵに対するコーディングツリーのような別のクワッドツリー構造に従って変換ユニット（ＴＵ）に分割することができる。ＨＥＶＣ構造の重要な特徴の一つは、ＣＵ、ＰＵ、及びＴＵを含む複数のパーティション概念を有することである。

【0074】

ＶＶＣでは、二及び三分割セグメンテーション構造を用いるネストされたマルチタイプツリーを持つクワッドツリーが、複数のパーティションユニットタイプの概念を置き換えている。つまり、ＶＶＳは、最大変換長に対して大きすぎるサイズを有するＣＵについて必要な場合を除いて、ＣＵ、ＰＵ、及びＴＵの概念の分離を含まないが、ＣＵパーティション形状に対してより大きい柔軟性をサポートする。コーディングツリー構造では、ＣＵは正方形又は長方形のいずれかを有することができる。コーディングツリーユニット（ＣＴＵ）は、四分ツリー（別名、クワッドツリー）構造によって最初に分割される。次に、四分ツリーリーフノードは、マルチタイプツリー構造によってさらに分割されることができる。図７Ａ～Ｄの（５５０）～（５８０）に示すように、マルチタイプツリー構造において、４つの分割タイプがある：図７Ａに示すような垂直二分割（SPLIT_BT_VER）、図７Ｂに示すような水平二分割（SPLIT_BT_HOR）、図７Ｃに示すような垂直三分割（SPLIT_TT_VER）、図７Ｄに示すような水平三分割（SPLIT_TT_HOR）。マルチタイプツリーリーフノードは、コーディングユニット（ＣＵ）と呼ばれることがあり、ＣＵが最大変換長に対して大きすぎない限り、このセグメンテーションは、さらなる分割なしに、予測及び変換処理に使用され得る。これは、ほとんどの場合、ＣＵ、ＰＵ、及びＴＵは、ネストされたマルチタイプツリーコーディングブロック構造を持つクワッドツリーにおいて同じブロックサイズを持つことを意味する。例外は、サポートされる変換長の最大値がＣＵの色成分の幅又は高さよりも小さい場合に発生する。

【0075】

図８は、ネストされたマルチタイプツリーコーディングツリー構造を有するクワッドツリーにおけるパーティション分割情報の信号送信（signalling）メカニズムを示す。コーディングツリーユニット（ＣＴＵ）（６０５）は、四分ツリーのルートとして扱われ得、信号送信される（signalled）フラグ（６１２）（qt_split_flag）に基づく四分ツリー構造によって最初に分割され得る。例えば、第１のフラグ（６１２）の値が「１」である場合には、QT_node（６１０）が存在するようにクワッドツリー分割は行われないことがある。第１のフラグ（６１２）の値が「０」である場合には、四分ツリーリーフノード（６１５）（QT-leaf_node/MTT_node）の１つ又は複数が存在するようにクワッドツリー分割が行われ得る。次に、各四分ツリーリーフノード（６１５）（それを可能にするのに十分大きい場合）は、マルチタイプツリー構造によってさらに分割される。マルチタイプツリー構造では、フラグ（６１７）（mtt_split_cu_flag又はmtt_split_flag）は、四分ツリーリーフノード（６１５）がさらに分割されるかどうかを示すために、信号送信される。例えば、フラグ６１７の値が「１」である場合、四分ツリーリーフノード（６１５）は、さらに分割される（参照文字６２０で示される）。フラグ（６１７）の値が「０」である場合、四分ツリーリーフノード（６１５）は、さらに分割されない（参照文字６２５で示される）。四分ツリーリーフノード（６１５）がさらに分割される場合、フラグ（６２２）（mtt_split_cu_vertical_flag又はmtt_split_vertical_flag）は、分割方向を示すために信号送信される。例えば、フラグ（６２２）の値が「１」である場合、四分ツリーリーフノード（６１５）は、垂直分割であり得（参照文字６３０で示される）、フラグ（６２２）の値が「０」である場合、四分ツリーリーフノード（６１５）は、水平分割され得る（参照文字６３５で示される）。フラグ（６３２）（mtt_split_cu_binary_flag又はmtt_split_binary_flag）は、分割が二分割であるか三分割であるかを示すように信号送信され得る。例えば、フラグ（６３２）の値が「１」である場合、四分ツリーリーフノード（６１５）は、二分割であり得（参照文字６４０及び６５０によって示される）、フラグ（６３２）の値が「０」である場合、四分ツリーリーフノード（６１５）は、三分割であり得る（参照文字６４５及び６５５によって示される）。フラグ（６２２）及びフラグ（６３２）の値に基づいて、ＣＵのマルチタイプツリー分割モード（MttSplitMode）は、表１に以下に示されるように導出され得る。
表１ － マルチタイプツリー構文要素に基づくMttSplitMode導出

【表1】

【0076】

図９は、クワッドツリー及びネストされたマルチタイプツリーコーディングブロック構造を有する複数のＣＵに分割されたＣＴＵ（６６０）を示し、太線のエッジはクワッドツリー分割を表し、破線のエッジはマルチタイプツリー分割を表す。ネストされたマルチタイプツリーパーティションを持つクワッドツリーは、ＣＵから構成されるコンテンツ適応コーディングツリー構造を提供する。ＣＵ（複数可）のサイズは、ＣＴＵと同じ大きさか、ルマサンプルのユニット（単位）で４×４と小さいことがある。４：２：０クロマフォーマットの場合、最大クロマＣＢサイズは６４×６４、最小クロマＣＢサイズは２×２である。

【0077】

ＶＶＣでは、最大のサポートされるルマ変換サイズは６４×６４であり、最大のサポートされるクロマ変換サイズは３２×３２である。ＣＢの幅又は高さが最大変換幅又は高さより大きい場合、ＣＢは、その方向の変換サイズ制限を満たすように、自動的に水平方向及び／又は垂直方向に分割される。

【0078】

ＶＴＭ７では、コーディングツリー方式はルマ及びクロマが別々のブロックツリー構造を持つ能力をサポートする。Ｐスライス及びＢスライスについて、１つのＣＴＵのルマＣＴＢ及びクロマＣＴＢは同じコーディングツリー構造を共有しなければならない。しかし、Ｉスライスについて、ルマ及びクロマは別々のブロックツリー構造を持つことができる。別々のブロックツリーモードが適用されるとき、ルマＣＴＢは１つのコーディングツリー構造によってＣＵに分割され、クロマＣＴＢは別のコーディングツリー構造によってクロマＣＵに分割される。これは、Ｉスライス内のＣＵがルマ成分のコーディングブロック又は２つのクロマ成分のコーディングブロックからなり得、Ｐ又はＢスライス内のＣＵが、ビデオがモノクロでない限り、３つのカラー成分すべてのコーディングブロックからなり得ることを意味する。

【0079】

[ＶＰ９とＡＶ１のコーディングブロックパーティション]

【0080】

図１０Ａ～Ｄのパーティション構造（６７０）～（６７３）を参照すると、ＶＰ９は、６４×６４レベルから４×４レベルまでの４ウェイパーティションツリーを使用し、ブロック８×８にはいくつかの追加の制限がある。図１０ＤにおいてＲとして示されたパーティションは、同じパーティションツリーが、最低の４×４レベルに達するまで、より低いスケールで繰り返されるという点で再帰を指すことに留意されたい。

【0081】

図１１Ａ～Ｊのパーティション構造（６８０）～（６８９）を参照すると、ＡＶ１は、パーティションツリーを１０ウェイ構造に拡張するだけでなく、１２８×１２８から開始するように最大サイズ（ＶＰ９／ＡＶ１用語ではスーパーブロックと呼ばれる）を増加させる。これには、ＶＰ９に存在しなかった４：１／１：４の長方形パーティションが含まれていることに留意されたい。長方形パーティションは、さらに細分化することはできない。コーディングブロックサイズに加えて、ルートノードからの分割深さを示すために、コーディングツリー深さが定義される。具体的には、ルートノードのコーディングツリー深さ、例えば１２８×１２８、を０に設定し、ツリーブロックをさらに一度分割した後、コーディングツリー深さを１増やす。

【0082】

ＶＰ９のように固定変換ユニットサイズを強制する代わりに、ＡＶ１はルマコーディングブロックが複数のサイズの変換ユニットに分割されることを可能にし、これは、２つのレベルまで下がる再帰的なパーティションによって表すことができる。ＡＶ１の拡張コーディングブロックパーティションを組み込むために、４×４から６４×６４までの正方形、２：１／１：２、及び４：１／１：４変換サイズがサポートされ得る。クロマブロックについて、可能な最大の変換ユニットのみが許容され得る。

【0083】

本開示の実施形態は、以下に詳細に説明される。本開示において以下に使用される用語「ＣＴＵ」は、コーディング規格の最大のコーディングユニット（ＬＣＵ）を指し得る。例えば、用語「ＣＴＵ」は、ＨＥＶＣ及びＶＶＣにおいて定義されるＣＴＵ、及び／又はＡＶ１において定義されるＳＢを指し得る。

【0084】

図１は、本開示の一実施形態による通信システム（１００）の簡略化されたブロック図を示す。システム（１００）は、ネットワーク（１５０）を介して相互接続された少なくとも２つの端末（１１０、１２０）を含み得る。データの一方向伝送のために、第１の端末（１１０）は、ネットワーク（１５０）を介した他方の端末（１２０）への伝送のために、ローカル位置でビデオデータをコード化し得る。第２の端末（１２０）は、ネットワーク（１５０）から他方の端末のコード化されたビデオデータを受信し、コード化されたデータをデコードし、回復されたビデオデータを表示し得る。一方向データ伝送は、メディア提供アプリケーション等において一般的である。

【0085】

図１は、例えば、テレビ会議中に発生し得るコード化されたビデオの双方向伝送をサポートするように提供される第２の端末のペア（１３０、１４０）を示している。データの双方向伝送のために、各端末（１３０、１４０）は、ネットワーク（１５０）を介した他方の端末への伝送のために、ローカル位置でキャプチャされたビデオデータをコード化し得る。各端末（１３０、１４０）はまた、他方の端末によって送信されたコード化されたビデオデータを受信し、コード化されたデータをデコードし、回復されたビデオデータをローカルディスプレイデバイスに表示し得る。

【0086】

図１において、端末（１１０～１４０）は、サーバ、パーソナルコンピュータ、及びスマートフォン、及び／又は任意の他のタイプの端末として示され得る。例えば、端末（１１０～１４０）は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は専用のテレビ会議装置であり得る。ネットワーク（１５０）は、例えば、有線及び／又は無線通信ネットワークを含む、端末（１１０～１４０）間でコード化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク（１５０）は、回線交換及び／又はパケット交換チャネルでデータを交換し得る。代表的なネットワークには、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又はインターネットが含まれる。本説明の目的のために、ネットワーク（１５０）のアーキテクチャ及びトポロジーは、以下に説明しない限り、本開示の動作には重要でない可能性がある。

【0087】

図２は、開示された主題のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルＴＶ、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタルメディア上の圧縮ビデオの記憶などを含む、他のビデオ対応アプリケーションにも同様に適用可能であり得る。

【0088】

図２に示すように、ストリーミングシステム（２００）は、ビデオソース（２０１）及びエンコーダ（２０３）を含むことができるキャプチャサブシステム（２１３）を含み得る。ビデオソース（２０１）は、例えば、デジタルカメラであり得、非圧縮ビデオサンプルストリーム（２０２）を生成するように構成され得る。非圧縮ビデオサンプルストリーム（２０２）は、エンコードされたビデオビットストリームと比較した場合に、高いデータボリュームを提供し得、カメラ（２０１）に結合されたエンコーダ（２０３）によって処理されることができる。エンコーダ（２０３）は、以下により詳細に説明されるように、開示された主題の態様を可能にする又は実装するように、ハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。エンコードされたビデオビットストリーム（２０４）は、サンプルストリームと比較した場合、より低いデータボリュームを含み得、将来の使用のためにストリーミングサーバ（２０５）に格納することができる。１つ又は複数のストリーミングクライアント（２０６）は、ストリーミングサーバ（２０５）にアクセスして、エンコードされたビデオビットストリーム（２０４）のコピーであり得るビデオビットストリーム（２０９）を取得することができる。

【0089】

実施形態では、ストリーミングサーバ（２０５）はまた、メディアアウェアネットワーク要素（ＭＡＮＥ）として機能し得る。例えば、ストリーミングサーバ（２０５）は、潜在的に異なるビットストリームをストリーミングクライアント（２０６）の１つ又は複数に合わせて調整するために、エンコードされたビデオビットストリーム（２０４）を切り詰める（prune）ように構成され得る。実施形態では、ＭＡＮＥは、ストリーミングシステム（２００）のストリーミングサーバ（２０５）から別々に提供され得る。

【0090】

ストリーミングクライアント（２０６）は、ビデオデコーダ（２１０）及びディスプレイ（２１２）を含むことができる。ビデオデコーダ（２１０）は、例えば、エンコードされたビデオビットストリーム（２０４）の受信コピーであるビデオビットストリーム（２０９）をデコードし、ディスプレイ（２１２）又は他のレンダリング装置（図示せず）でレンダリングされることができる送信ビデオサンプルストリーム（２１１）を生成することができる。いくつかのストリーミングシステムでは、ビデオビットストリーム（２０４、２０９）は、特定のビデオ符号化／圧縮規格に従ってエンコードされることができる。このような規格の例としては、IＴＵ－Ｔ勧告Ｈ．２６５が挙げられるが、これに限定されるものではない。開発中のものは、Versatile Video Coding（ＶＶＣ）として知られるビデオコーディング規格である。本開示の実施形態は、ＶＶＣのコンテキストで使用され得る。

【0091】

図３は、本開示の一実施形態による、ディスプレイ（２１２）に取り付けられるビデオデコーダ（２１０）の例示的な機能ブロック図を示す。

【0092】

ビデオデコーダ（２１０）は、チャネル（３１２）、受信器（３１０）、バッファメモリ（３１５）、エントロピーデコーダ/パーサ（３２０）、スケーラ／逆変換ユニット（３５１）、イントラ予測ユニット（３５２）、動き補償予測ユニット（３５３）、アグリゲータ（３５５）、ループフィルタユニット（３５６）、参照画像メモリ（３５７）、及び現在の画像メモリ（３５８）を含み得る。少なくとも１つの実施形態では、ビデオデコーダ（２１０）は、集積回路、一連の集積回路、及び／又は他の電子回路を含み得る。また、ビデオデコーダ（２１０）は、部分的又は全体的に、関連するメモリを備えた１つ又は複数のＣＰＵで実行されるソフトウェアで具体化され得る。

【0093】

この実施形態及び他の実施形態では、受信器（３１０）は、一度に１つのコード化されたビデオシーケンスにデコーダ（２１０）によってデコードされることになる１つ又は複数のコード化されたビデオシーケンスを受信し得、各コード化されたビデオシーケンスのデコードは、他のコード化されたビデオシーケンスから独立している。コード化されたビデオシーケンスは、チャネル（３１２）から受信され得、このチャネルは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信器（３１０）は、エンコードされたビデオデータを、他のデータ、例えば、コード化されたオーディオデータ及び／又は補助データストリームと共に受信し得、これらのデータは、それぞれの使用エンティティ（図示せず）に転送され得る。受信器（３１０）は、コード化されたビデオシーケンスを他のデータから分離し得る。ネットワークジッタと闘うために、バッファメモリ（３１５）が、受信器（３１０）とエントロピーデコーダ／パーサ（３２０）（以下、「パーサ」）との間に結合され得る。受信器（３１０）が、十分な帯域幅及び可制御性を有するストア／フォワードデバイスから、又は等同期（isosynchronous）ネットワークからデータを受信しているとき、バッファ（３１５）は使用されないか、又は小さくすることができる。インターネットのようなベストエフォート型パケットネットワークで使用するためには、バッファ（３１５）が必要とされ、比較的大きくすることができ、適応サイズであることができる。

【0094】

ビデオデコーダ（２１０）は、エントロピーコード化ビデオシーケンスからシンボル（３２１）を再構成するためのパーサ（３２０）を含み得る。これらのシンボルのカテゴリには、例えば、デコーダ（２１０）の動作を管理するために使用される情報、及び図２に示すようにデコーダに結合され得るディスプレイ（２１２）のようなレンダリング装置を制御するために使用される可能性のある情報が含まれる。レンダリング装置（複数可）の制御情報は、例えば、補足拡張情報（ＳＥＩ）メッセージ又はビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（図示せず）の形態であり得る。パーサ（３２０）は、受信したコード化されたビデオシーケンスを解析／エントロピーデコードし得る。コード化されたビデオシーケンスのコード化は、ビデオコーディング技術又は規格に従うことができ、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わない算術コーディングなどを含む、当業者に良く知られた原理に従うことができる。パーサ（３２０）は、コード化されたビデオシーケンスから、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも１つに対するサブグループパラメータのセットを抽出し得る。サブグループは、画像のグループ（ＧＯＰ）、画像、タイル、スライス、マクロブロック、コーディングユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）などを含むことができる。パーサ（３２０）はまた、変換係数などのコード化されたビデオシーケンス情報から、量子化パラメータ値、モーションベクトル等を抽出し得る。

【0095】

パーサ（３２０）は、シンボル（３２１）を作成するために、バッファ（３１５）から受信されたビデオシーケンスにエントロピーデコーディング／解析操作を実行し得る。

【0096】

シンボル（３２１）の再構成は、コード化されたビデオ画像又はその部分（例えば、インター及びイントラ画像、インター及びイントラブロック）のタイプ及び他の要因に応じて、複数の異なるユニットを含むことができる。どのユニットが関与し、どのように関与するかは、パーサ（３２０）によってコード化されたビデオシーケンスから解析されたサブグループ制御情報によって制御することができる。パーサ（３２０）と以下の複数ユニットとの間のこのようなサブグループ制御情報のフローは、明確にするために図示されていない。

【0097】

既に述べた機能ブロックの他に、デコーダ（２１０）は、概念的に、以下に説明するように、いくつかの機能ユニットに分割することができる。商業的制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合することができる。しかしながら、開示された主題を説明するためには、以下の機能ユニットに概念的に細分化することが適切である。

【0098】

１つのユニットは、スケーラ／逆変換ユニット（３５１）であり得る。スケーラ／逆変換ユニット（３５１）は、パーサ（３２０）からシンボル（複数可）（３２１）として、使用するための変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報とともに、量子化された変換係数を受信し得る。スケーラ／逆変換ユニット（３５１）は、アグリゲータ（３５５）に入力することができるサンプル値を含むブロックを出力することができる。

【0099】

場合によっては、スケーラ／逆変換（３５１）の出力サンプルは、イントラコード化ブロック、すなわち、以前に再構成された画像からの予測情報を使用していないが、現在の画像の以前に再構成された部分からの予測情報を使用することができるブロックに関連付けることができる。このような予測情報は、イントラ画像予測ユニット（３５２）によって提供されることができる。場合によっては、イントラ画像予測ユニット（３５２）は、現在の画像メモリ（３５８）からの現在の（部分的に再構成された）画像から取り出された既に再構成された周囲の情報を使用して、再構成中のブロックの同じサイズ及び形状のブロックを生成する。アグリゲータ（３５５）は、場合によっては、サンプル毎に、イントラ予測ユニット（３５２）が生成した予測情報を、スケーラ／逆変換ユニット（３５１）によって提供されるように、出力サンプル情報に追加する。

【0100】

他の場合では、スケーラ／逆変換ユニット（３５１）の出力サンプルは、インターコード化された、潜在的な動き補償ブロックに関連することができる。このような場合、動き補償予測ユニット（３５３）は、参照画像メモリ（３５７）にアクセスして、予測に使用されるサンプルを取り出すことができる。ブロックに関連するシンボル（３２１）に従って、取り出されたサンプルを動き補償した後、これらのサンプルは、アグリゲータ（３５５）によって、スケーラ／逆変換ユニット（３５１）の出力（この場合、残留サンプル又は残留信号と呼ぶ）に加えられ、出力サンプル情報を生成することができる。動き補償予測ユニット（３５３）が予測サンプルを取り出す参照画像メモリ（３５７）内のアドレスは、モーションベクトルによって制御することができる。モーションベクトルは、例えば、Ｘ、Ｙ、及び参照画像成分を有することができるシンボル（３２１）の形態で、動き補償予測ユニット（３５３）に利用可能であり得る。また、動き補償は、サブサンプルの正確なモーションベクトルが使用されているときに参照画像メモリ（３５７）から取り出されるサンプル値の補間、モーションベクトル予測メカニズムなどを含むことができる。

【0101】

アグリゲータ（３５５）の出力サンプルは、ループフィルタユニット（３５６）内の種々のループフィルタリング技術の対象であることができる。ビデオ圧縮技術は、コード化されたビデオビットストリームに含まれるパラメータによって制御され、パーサ（３２０）からのシンボル（３２１）としてループフィルタユニット（３５６）に利用可能にされるが、コード化された画像又はコード化されたビデオシーケンスの前の（デコーディング順で）部分のデコーディング中に得られたメタ情報に応答することができ、また、以前に再構成されループフィルタリングされたサンプル値に応答することもできる、インループフィルタ技術を含むことができる。

【0102】

ループフィルタユニット（３５６）の出力は、ディスプレイ（２１２）のようなレンダリング装置に出力することができ、また、将来のインター画像予測に使用するために参照画像メモリ（３５７）に記憶することができるサンプルストリームであることができる。

【0103】

特定のコード化された画像は、いったん完全に再構成されると、将来の予測のための参照画像として使用することができる。コード化された画像が完全に再構成され、コード化された画像が（例えば、パーサ（３２０）によって）参照画像として識別されると、現在の参照画像は、参照画像メモリ（３５７）の一部となることができ、次のコード化された画像の再構成を開始する前に、新しい現在の画像メモリを再割当てすることができる。

【0104】

ビデオデコーダ（２１０）は、IＴＵ－Ｔ Ｒｅｃ． Ｈ．２６５のような規格で文書化され得る所定のビデオ圧縮技術に従ってデコーディング動作を実行し得る。コード化されたビデオシーケンスは、ビデオ圧縮技術文書又は規格の中で、特にその中のプロファイル文書の中で規定されているように、ビデオ圧縮技術又は規格の構文に準拠しているという意味で、使用されているビデオ圧縮技術又は規格によって規定された構文に適合し得る。また、いくつかのビデオ圧縮技術又は規格に準拠するために、コード化されたビデオシーケンスの複雑さは、ビデオ圧縮技術又は規格のレベルによって定義される範囲内にあり得る。ある場合には、レベルは、最大画像サイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒メガサンプルで測定される）、最大参照画像サイズなどを制限する。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（ＨＲＤ）仕様と、コード化されたビデオシーケンスで信号送信されるＨＲＤバッファ管理のためのメタデータとを通してさらに制限されることができる。

【0105】

一実施形態では、受信器（３１０）は、エンコードされたビデオと共に追加の（冗長な）データを受信し得る。追加データは、コード化されたビデオシーケンス（複数可）の一部として含まれ得る。追加のデータは、データを適切にデコードするため、及び／又は元のビデオデータをより正確に再構成するために、ビデオデコーダ（２１０）によって使用され得る。追加のデータは、例えば、時間的、空間的、又はＳＮＲ強調層、冗長スライス、冗長画像、前方誤り訂正コードなどの形態であることができる。

【0106】

図４は、本開示の一実施形態による、ビデオソース（２０１）に関連付けられるビデオエンコーダ（２０３）の例示の機能ブロック図を示す。

【0107】

ビデオエンコーダ（２０３）は、例えば、ソースコーダ（４３０）であるエンコーダ、コーディングエンジン（４３２）、（ローカル）デコーダ（４３３）、参照画像メモリ（４３４）、予測器（４３５）、送信器（４４０）、エントロピーコーダ（４４５）、コントローラ（４５０）、及びチャネル（４６０）を含み得る。

【0108】

エンコーダ（２０３）は、エンコーダ（２０３）によってコード化されることになるビデオ画像（複数可）をキャプチャし得るビデオソース（２０１）（エンコーダの一部ではない）からビデオサンプルを受信し得る。

【0109】

ビデオソース（２０１）は、任意の適切なビット深さ（例えば、８ビット、１０ビット、１２ビット、...）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、...）及び任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であることができるデジタルビデオサンプルストリームの形態で、エンコーダ（２０３）によってコード化されることになるソースビデオシーケンスを提供し得る。メディア供給システムでは、ビデオソース（２０１）は、事前に準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース（２０３）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、シーケンスで見たときに動きを伝える複数の個々の画像として提供され得る。画像自体は、ピクセルの空間アレイとして編成され得、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、１つ又は複数のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。

【0110】

一実施形態によれば、エンコーダ（２０３）は、ソースビデオシーケンスの画像を、リアルタイムで、又はアプリケーションによって要求される任意の他の時間制約下で、コード化されたビデオシーケンス（４４３）にコード化及び圧縮し得る。適切なコーディング速度を強制することは、コントローラ（４５０）の一つの機能である。コントローラ（４５０）はまた、以下に記載されるように他の機能ユニットを制御し得、これらのユニットに機能的に結合され得る。結合は、明確にするために示されていない。コントローラ（４５０）によって設定されるパラメータは、レート制御関連パラメータ（画像スキップ、量子化器、レート歪み最適化技術のラムダ値、...）、画像サイズ、画像グループ（ＧＯＰ）レイアウト、最大モーションベクトル探索範囲などを含むことができる。当業者は、特定のシステム設計のために最適化されたビデオエンコーダ（２０３）に関連し得るので、コントローラ（４５０）の他の機能を容易に識別することができる。

【0111】

いくつかのビデオエンコーダは、当業者が「コーディングループ」として容易に認識できるもので動作する。過度に単純化された説明として、コーディングループは、ソースコーダ（４３０）のエンコーディング部分（コード化されることになる入力画像及び参照画像（複数可）に基づいてシンボルを生成することを担当する）と、（リモート）デコーダがまた特定のビデオ圧縮技術においてシンボルとコード化されたビデオビットストリームとの間の圧縮がロスレスであるときに生成するであろうサンプルデータを生成するためにシンボルを再構成する、エンコーダ（２０３）に埋め込まれた（ローカル）デコーダ（４３３）とからなることができる。その再構成されたサンプルストリームは、参照画像メモリ（４３４）に入力され得る。シンボルストリームのデコーディングは、デコーダ位置（ローカル又はリモート）に依存しないビット正確な結果（bit-exact results）をもたらすので、参照画像メモリ内容もまた、ローカルエンコーダとリモートエンコーダとの間でビット正確である。言い換えると、エンコーダの予測部分は、デコーダがデコーディング中に予測を使用するときに「見る」のとまったく同じサンプル値を参照画像サンプルとして「見る」。参照画像の同期性のこの基本原理（及び、例えば、チャンネルエラーのために同期性を維持できない場合の結果として生じるドリフト）は、当業者には知られている。

【0112】

「ローカル」デコーダ（４３３）の動作は、「リモート」デコーダ（２１０）と同じであることができ、これは、図３と関連して既に上述されている。しかしながら、シンボルが利用可能であり、エントロピーコーダ（４４５）及びパーサ（３２０）によるコード化されたビデオシーケンスへのシンボルのエンコーディング／デコーディングがロスレスであることができるので、チャネル（３１２）、受信器（３１０）、バッファ（３１５）及びパーサ（３２０）を含むデコーダ（２１０）のエントロピーデコーディング部分は、ローカルデコーダ（４３３）に完全には実装されなくてもよい。

【0113】

この時点で行うことができる観察は、デコーダ内に存在する解析／エントロピーデコーディングを除き、任意のデコーダ技術が、対応するエンコーダ内に実質的に同一の機能形態で存在する必要があり得るということである。この理由のために、開示された主題はデコーダ動作に焦点を当てる。エンコーダ技術の記述は、包括的に記述されたデコーダ技術の逆であり得るので、省略することができる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。

【0114】

その動作の一部として、ソースコーダ（４３０）は、「参照フレーム」として指定されたビデオシーケンスからの１つ又は複数の予めコードされたフレームを参照して入力フレームを予測的にコード化する動き補償予測コーディングを実行し得る。このようにして、コーディングエンジン（４３２）は、入力フレームのピクセルブロックと、入力フレームに対する予測参照（複数可）として選択され得る参照フレーム（複数可）のピクセルブロックとの間の差分をコード化する。

【0115】

ローカルビデオデコーダ（４３３）は、ソースコーダ（４３０）によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコード化されたビデオデータをデコードし得る。コーディングエンジン（４３２）の動作は、有利には、損失のある（lossy）プロセスであり得る。コード化されたビデオデータがビデオデコーダ（図４には示されていない）でデコードされ得る場合、再構成されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ（４３３）は、参照フレーム上でビデオデコーダによって実行され得、再構成された参照フレームを参照画像メモリ（４３４）に格納させ得るデコーディングプロセスを複製する。このようにして、エンコーダ（２０３）は、遠端ビデオデコーダによって得られる再構成された参照フレームとして共通の内容を有する再構成された参照フレームのコピーを、ローカルに記憶し得る（送信エラーがない）。

【0116】

予測器（４３５）は、コーディングエンジン（４３２）のための予測探索を実行し得る。すなわち、コード化されることになる新しいフレームに対して、予測器（４３５）は、新しい画像に対する適切な予測参照として役立ち得る参照画像モーションベクトル、ブロック形状などの特定のメタデータ又はサンプルデータ（候補参照ピクセルブロックとして）について参照画像メモリ（４３４）を検索し得る。予測器（４３５）は、適切な予測参照を見出すために、サンプルのブロックごとのピクセルのブロックベース（sample block-by-pixel block basis）で動作し得る。場合によっては、予測器（４３５）によって得られた検索結果によって決定されるように、入力画像は、参照画像メモリ（４３４）に記憶された複数の参照画像から引き出された予測参照を有し得る。

【0117】

コントローラ（４５０）は、例えば、ビデオデータをエンコードするために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ（４３０）のコーディング動作を管理し得る。

【0118】

全ての前述の機能ユニットの出力は、エントロピーコーダ（４４５）におけるエントロピーコーディングの対象となり得る。エントロピーコーダは、例えば、ハフマンコーディング、可変長コーディング、算術コーディングなど、当業者に知られた技術に従って、シンボルをロスレス圧縮することによって、種々の機能ユニットによって生成されるシンボルをコード化されたビデオシーケンスに変換する。

【0119】

送信機（４４０）は、エントロピーエンコーダ（４４５）によって生成されるようにコード化されたビデオシーケンス（複数可）をバッファに入れて、通信チャネル（４６０）を介した送信の準備をし得、この通信チャネルは、エンコードされたビデオデータを格納する記憶装置へのハードウェア/ソフトウェアリンクであり得る。送信機（４４０）は、ビデオコーダ（４３０）からのコード化されたビデオデータを送信されることになる他のデータと、例えばコード化されたオーディオデータ及び／又は補助データストリーム（ソースは図示せず）などとマージし得る。

【0120】

コントローラ（４５０）は、エンコーダ（２０３）の動作を管理し得る。コーディングの間、コントローラ（４５０）は、各コード化された画像に特定のコード化された画像タイプを割り当て得、これは、各画像に適用され得るコーディング技術に影響を及ぼし得る。例えば、画像は、多くの場合、イントラ画像（Ｉ画像）、予測画像（Ｐ画像）、又は双方向予測画像（Ｂ画像）として割り当てられ得る。

【0121】

イントラ画像（Ｉ画像）は、予測のソースとしてシーケンス内の他のフレームを使用せずに、コード化され得る及びデコードされ得るものであり得る。いくつかのビデオコーデックは、例えば、独立したデコーダリフレッシュ（ＩＤＲ）画像を含む、異なるタイプのイントラ画像を許容する。当業者は、Ｉ画像のこれらの変形例、並びにそれらのそれぞれの用途及び特徴を知っている。

【0122】

予測画像（Ｐ画像）は、各ブロックのサンプル値を予測するために、最大で１つのモーションベクトル及び参照インデックスを用いるイントラ予測又はインター予測を用いてコード化され得る及びデコードされ得るものであり得る。

【0123】

双方向予測画像（Ｂ画像）は、各ブロックのサンプル値を予測するために、最大で２つのモーションベクトル及び参照インデックスを用いるイントラ予測又はインター予測を用いてコード化され得る及びデコードされ得るものであり得る。同様に、複数の予測画像が、１つのブロックの再構成のために、２より多い参照画像及び関連するメタデータを使用することができる。

【0124】

ソース画像は、通常、空間的に複数のサンプルブロック（例えば、それぞれ４×４、８×８、４×８、又は１６×１６サンプルのブロック）に分割され、ブロック毎にコード化される。ブロックは、ブロックのそれぞれの画像に適用されるコーディング割り当てによって決定されるように、他の（既にコード化された）ブロックを参照して予測的にコード化され得る。例えば、Ｉ画像のブロックは、非予測的にコード化され得る、又は、それらは、同じ画像の既に符号化されたブロックを参照して予測的にコード化され得る（空間予測又はイントラ予測）。Ｐ画像のピクセルブロックは、以前にコード化された１つの参照画像を参照して、非予測的に、空間予測を介して又は時間予測を介してコード化され得る。Ｂ画像のブロックは、１つ又は２つの以前にコード化された参照画像を参照して、非予測的に、空間予測を介して又は時間予測を介してコード化され得る。

【0125】

ビデオコーダ（２０３）は、IＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５．などの所定のビデオコーディング技術又は規格に従ってコーディング動作を実行し得る。その動作において、ビデオコーダ（２０３）は、入力ビデオシーケンスにおける時間的及び空間的冗長性を活用する予測コーディング動作を含む種々の圧縮動作を実行し得る。従って、コード化されたビデオデータは、使用されているビデオコーディング技術又は規格によって指定された構文に適合し得る。

【0126】

一実施形態では、送信器（４４０）は、コード化されたビデオと共に追加データを送信し得る。ビデオコーダ（４３０）は、コード化されたビデオシーケンスの一部としてそのようなデータを含み得る。追加のデータは、時間的／空間的／ＳＮＲ強調層、冗長画像及びスライスのような他の形式の冗長データ、補足強調情報（ＳＥＩ）メッセージ、視覚的ユーザビリティ情報（ＶＵＩ）パラメータセットフラグメントなどを含み得る。

【0127】

本開示の実施形態の特定の態様をより詳細に説明する前に、本説明の残りの部分で参照されているいくつかの用語を以下に紹介する。

【0128】

以下、「サブ画像」とは、場合によっては、サンプル、ブロック、マクロブロック、コーディングユニット、又は意味的にグループ化され、変更された解像度で独立にコード化され得る類似のエンティティの長方形配置を指す。１つ又は複数のサブ画像が画像を形成し得る。１つ又は複数のコード化されたサブ画像は、コード化された画像を形成し得る。１つ又は複数のサブ画像は１つの画像に組み立てられ得、１つ又は複数のサブ画像は１つのピクチャから抽出され得る。特定の環境では、１つ又は複数のコード化されたサブ画像は、サンプルレベルをコード化された画像にトランスコーディングすることなく、圧縮されたドメイン内に組み立てられ得、同じ又は特定の他の場合には、１つ又は複数のコード化されたサブ画像は、圧縮されたドメイン内のコード化された画像から抽出され得る。

【0129】

「適応解像度変化」（ＡＲＣ）は、以下、例えば参照画像の再サンプリングによって、コード化されたビデオシーケンス内の画像又はサブ画像の解像度の変化を可能にするメカニズムを指す。「ＡＲＣパラメータ」は、以下、適応解像度変化を実行するために必要とされる制御情報を指し、これには、例えば、フィルタパラメータ、スケーリングファクタ、出力及び／又は参照画像の解像度、種々の制御フラグなどが含まれ得る。

【0130】

本開示の実施形態によれば、画像の第１の行（及び／又は列）に位置するＣＴＵのサイズは、画像の第２の行（及び／又は列）に位置するＣＴＵのサイズよりも小さくすることができ、ＣＴＵのサイズは、上、下、左、及び／又は右の画像境界に位置するものを除いて、同じであり得る。

【0131】

例えば、図１２～１５を参照すると、画像（７００）、（７１０）、（７２０）、及び（７３０）は、本開示の実施形態に従って複数のＣＴＵに分割され得る。図１２において、画像（７００）の第１のＣＴＵ列（７０２）及び最後のＣＴＵ列（７０６）に位置するＣＴＵは、画像（７００）の他の列に位置するＣＴＵよりも小さいサイズを有し得、他の列に位置するＣＴＵは、互いに同じサイズを有し得る。図１３において、画像（７１０）の第１のＣＴＵ行（７０４）及び最後のＣＴＵ行（７０８）に位置するＣＴＵは、画像（７１０）の他の行に位置するＣＴＵよりも小さいサイズを有し得、他の行に位置するＣＴＵは、互いに同じサイズを有し得る。図１４において、画像（７２０）の第１のＣＴＵ行（７０４）、第１のＣＴＵ列（７０２）、最後のＣＴＵ行（７０８）、及び最後のＣＴＵ列（７０６）に位置するＣＴＵは、画像（７２０）の他の行／列に位置するＣＴＵよりも小さいサイズを有し得、他の行／列に位置するＣＴＵは、互いに同じサイズを有し得る。図１５において、第１のＣＴＵ行（７０４）及び第１のＣＴＵ列（７０２）に位置するＣＴＵは、画像（７３０）の他の行／列に位置するＣＴＵよりも小さいサイズを有し得、他の行／列に位置するＣＴＵは、互いに同じサイズを有し得る。

【0132】

１つ又は複数の実施形態において、第１のＣＴＵ行及び／又は列の幅及び／又は高さは、シーケンスパラメータセット（ＳＰＳ）、画像パラメータセット（ＰＰＳ）、又はスライスヘッダなど、ビットストリーム内のハイレベル構文（ＨＬＳ）で、信号送信される。

【0133】

一実施形態では、第１のＣＴＵ行及び／又は列の幅及び／又は高さは、固定長コーディング、又は切り詰められたバイナリ（truncated binary）若しくは切り詰められた単項（truncated unary）コーディングを使用することによって信号送信され得る。

【0134】

別の実施形態では、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）が最大許容ＣＴＵサイズに等しいか否かを示すために、１つのフラグが最初に信号送信される。１つのフラグが、幅（及び／又は高さ）が最大許容ＣＴＵサイズと等しくないことを示す場合、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）を示すために、第２のフラグがさらに信号送信され得る。一例では、固定長コーディングは、第２のフラグの信号送信のために使用され得る。

【0135】

一実施形態では、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）は、２の累乗に制限され、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）は、Ｋ１以上であり得、Ｋ１は、２、４、６、８などの正の整数であり得る、又は２の累乗であり得る。例えば、第１のＣＴＵ列の高さは制限され得る、及び／又は第１のＣＴＵ列の幅は制限され得る。

【0136】

別の実施形態では、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）は、Ｋ２の整数倍に制限され得、ここで、Ｋ２は、２、４、６、８、１０、１２、１４、１６などの偶数の整数である。例えば、第１のＣＴＵ列の高さは制限され得る、及び／又は第１のＣＴＵ列の幅は制限され得る。一実施形態では、Ｋ２は、２の累乗であるようにさらに制限され得る。一実施形態では、各コード化されたブロックの幅及び高さが２の累乗であることを確実にするために、最後のＣＴＵ行に対する同一の境界処理ルールが第１のＣＴＵ行に適用され得、最後のＣＴＵ列に対する同一の境界処理ルールが第１のＣＴＵ列に適用され得る。

【0137】

１つ又は複数の実施形態では、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）がＫ３以上であり、第１のＣＴＵ行（及び／又は列）の高さ（及び／又は幅）がＫ３未満である場合、水平（及び／又は垂直）分割は、第１のＣＴＵ行（及び／又は列）のＣＴＵレベルにおいて許可されない。Ｋ３は２の累乗の値であり得、Ｋ３は、１２８又は２５６など、６４より大きく成り得る。例えば、一実施形態によれば、第１のＣＴＵ行（７０４）の幅がＫ３以上であり、第１のＣＴＵ行（７０４）の高さがＫ３未満である場合、水平分割は、第１のＣＴＵ行（７０４）のＣＴＵレベルにおいて禁止され得る。代替的又は追加的に、第１のＣＴＵ列（７０２）の高さがＫ３以上であり、第１のＣＴＵ列（７０２）の幅がＫ３未満である場合、垂直分割は、第１のＣＴＵ列（７０２）のＣＴＵレベルにおいて禁止されないことがある。第１のＣＴＵ行（７０４）及び第１のＣＴＵ列（７０２）についての上述の条件がそれぞれ真である場合には、コーナーＣＴＵ（７０９）の水平及び垂直分割（図１５参照）は禁止され得る。同様に、他のコーナーＣＴＵが設けられているＣＴＵ行及び列が上記の条件を満たす場合、他のコーナーＣＴＵの水平方向及び垂直方向の分割は禁止され得る。

【0138】

１つ又は複数の実施形態では、第１のＣＴＵ行（及び／又は列）の幅（及び／又は高さ）がＫ３以上であり、第１のＣＴＵ行（及び／又は列）の高さ（及び／又は幅）がＫ３未満である場合、垂直ＴＴ（及び／又は水平ＴＴ）分割は、第１のＣＴＵ行（及び／又は列）のＣＴＵレベルにおいて許可されないことがある。Ｋ３は２の累乗の値であり得、Ｋ３は、１２８又は２５６など、６４より大きく成り得る。例えば、一実施形態によれば、第１のＣＴＵ行（７０４）の幅がＫ３以上であり、第１のＣＴＵ行（７０４）の高さがＫ３未満である場合、水平のＴＴ分割は、第１のＣＴＵ行（７０４）のＣＴＵレベルにおいて禁止され得る。代替的又は追加的に、第１のＣＴＵ列（７０２）の高さがＫ３以上であり、第１のＣＴＵ列（７０２）の幅がＫ３未満の場合、垂直ＴＴ分割は、第１のＣＴＵ列（７０２）のＣＴＵレベルにおいて禁止され得る。第１のＣＴＵ行（７０４）及び第１のＣＴＵ列（７０２）に対する上記の条件がそれぞれ真である場合、コーナーＣＴＵ（７０９）（図１５参照）の水平及び垂直ＴＴ分割は禁止され得る。同様に、他のコーナーＣＴＵが設けられているＣＴＵ行及び列が上記の条件を満たす場合は、他のコーナーＣＴＵの水平及び垂直ＴＴ分割は禁止され得る。

【0139】

１つ又は複数の実施形態では、画像の第１又は最後のＣＴＵ行（及び／又は列）の高さ（及び／又は幅）のみが、最大ＣＴＵサイズ未満であり得、画像の他のＣＴＵ行（及び／又は列）のサイズは、最大ＣＴＵサイズと同じであり得る。例えば、図１４に示すように、画像（７４０）の第１のＣＴＵ行（７０４）の高さ及び第１のＣＴＵ列（７０２）の幅は、最大ＣＴＵサイズ未満であり得、画像（７２０）の他の行／列は、最大ＣＴＵサイズに等しくなり得る。

【0140】

一実施形態では、第１及び／又は最後のＣＴＵ行（及び／又は列）が他のＣＴＵ行（及び／又は列）よりも小さいサイズを有するかどうかを示すために、シーケンスパラメータセット（ＳＰＳ）、画像パラメータセット（ＰＰＳ）、又はスライスヘッダなどのビットストリーム内の高レベル構文（ＨＬＳ）で１つのフラグが信号送信される。

【0141】

上述の本開示の実施形態は、特定の色成分のみに適用され得る（例えば、ルマのみ、クロマのみ）、又は異なる色成分に異なるように適用され得る（例えば、異なるサイズの第１のＣＴＵ行又はＣＴＵ列が、異なる色成分に適用されることができる）。

【0142】

実施形態によれば、第１のＣＴＵ列の幅は、他の残りのＣＴＵからデコーダによって導出され得る。実施形態によれば、エンコーダが、デコーダに対する第１のＣＴＵ列（及び／又は行）及び／又は中間の列（複数可）（及び／又は行（複数可））のサイズを指定し得、デコーダは、指定されたサイズ（複数可）に基づいて最後のＣＴＵ列（及び／又は行）のサイズを導出し得る。

【0143】

本開示の実施形態は、少なくとも１つのプロセッサ及びコンピュータ命令を記憶するメモリを含み得る。コンピュータ命令は、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに本開示の実施形態の機能を実行させるように構成され得る。

【0144】

例えば、図１６を参照すると、本開示のデコーダ（８００）は、１つのプロセッサ及びコンピュータ命令を記憶する少なくともメモリを含み得る。コンピュータ命令は、デコーディングコード（８１０）を含み得る。デコーダ（８００）は、図２～３に示すビデオデコーダ（２１０）を実装し得る。

【0145】

デコーディングコード（８１０）は、少なくとも１つのプロセッサに、複数のＣＴＵに分割されるコード化された画像をデコードさせるように構成され得、デコーディングコード（８１０）は、少なくとも１つのプロセッサに、複数のＣＴＵに基づいてコード化された画像をデコードさせるように構成され得る。

【0146】

ＣＴＵは、例えば、図１２～１５に関して、本開示において説明した実施形態のＣＴＵ構成のいずれかを有し得る。例えば、コード化された画像の複数のＣＴＵの中の、コード化された画像の境界に隣接するＣＴＵの少なくとも１つの行又は列は、コード化された画像の任意の境界に隣接しない複数のＣＴＵの中の各ＣＴＵの対応するサイズ寸法より小さいサイズ寸法を有し得る。

【0147】

デコーディングコード（８１０）は、少なくとも１つのプロセッサに、本開示の実施形態に従ってフラグを信号送信させるようにさらに構成され得る。例えば、デコーディングコード（８１０）は、少なくとも１つのプロセッサに、ＣＴＵの少なくとも１つの行又は列のうちの、コード化された画像の上境界又は左境界に隣接する第１の行及び／又は列のサイズ寸法を信号送信させるように構成され得る。代替的には、デコーディングコード（８１０）は、少なくとも１つのプロセッサに：コード化された画像の左境界又は上境界に隣接するＣＴＵの少なくとも１つの行又は列のうちからの第１の行及び／又は列のサイズ寸法が、最大許容ＣＴＵサイズに等しいかどうかを示す第１のフラグを信号送信させ；第１のフラグに基づいて、ＣＴＵの第１の行及び／又は列のサイズ寸法が、最大許容ＣＴＵサイズに等しくないことを決定させ；決定に基づいて、ＣＴＵの第１の行及び／又は列のサイズ寸法を示す第２のフラグを信号送信させる；ように構成され得る。

【0148】

デコーディングコード（８１０）は、本開示に記載される実施形態の不許可条件に基づいて、少なくとも１つのプロセッサに、ＣＴＵレベルでの水平又は垂直分割を禁止させる及び／又は水平トリプルツリー（ＴＴ）分割又は垂直ＴＴ分割を禁止させるようにさらに構成され得る。例えば、デコーディングコード（８１０）は、少なくとも１つのプロセッサに、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が所定値以上であり、ＣＴＵの少なくとも１つの行又は列の間からの第１のＣＴＵ行又は第１のＣＴＵ列の他のサイズ寸法が所定値未満であると決定することに基づいて、ＣＴＵの少なくとも１つの行又は列の間から、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列のＣＴＵレベルにおける水平又は垂直分割を禁止させるように構成され得、サイズ寸法は、高さ及び幅のうちの一方であり、別のサイズ寸法は高さ及び幅のうちの他方であり、所定値は６４より大きい２の累乗の値である。代替的又は追加的に、デコーディングコード（８１０）は、少なくとも１つのプロセッサに、第１のＣＴＵ行又は第１のＣＴＵ列のサイズ寸法が所定値以上であり、ＣＴＵの少なくとも１つの行又は列の間からの第１のＣＴＵ行又は第１のＣＴＵ列の別のサイズ寸法が所定値未満であると決定することに基づいて、ＣＴＵの少なくとも１つの行又は列の間から、コード化された画像の第１のＣＴＵ行又は第１のＣＴＵ列のＣＴＵレベルにおける水平トリプルツリー（ＴＴ）又は垂直ＴＴ分割を禁止させるように構成され得、サイズ寸法は高さ及び幅のうちの一方であり、別のサイズ寸法は高さ及び幅のうちの他方であり、所定値は６４より大きい２の累乗の値である。

【0149】

実施形態によれば、デコーディングコード（８１０）はまた、少なくとも１つのプロセッサに、コード化された画像を複数のＣＴＵに分割させるように構成され得る。

【0150】

実施形態によれば、上記の処理に対応するエンコーダ側の処理は、上記の説明に基づいて、当業者に理解されるように、画像をエンコードするためにコードをエンコードすることによって実現され得る。

【0151】

上述の本開示の実施形態の技術は、コンピュータ読取可能な命令を使用し、１つ又は複数のコンピュータ読取可能な媒体に物理的に記憶されるコンピュータソフトウェアとして実装されることができる。例えば、図１７は、開示された主題の実施形態を実装するのに適したコンピュータシステム（９００）を示す。

【0152】

コンピュータソフトウェアは、コンピュータ中央処理ユニット（ＣＰＵ）、グラフィックス処理ユニット（ＧＰＵ）などによって、直接的に、又は解釈を通じて、マイクロコード実行などを通して実行することができる命令を含むコードを作成するために、アセンブリ、コンパイル、リンク、又は同様のメカニズムの対象となり得る任意の適切な機械コード又はコンピュータ言語を用いてコード化されることができる。

【0153】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーミングデバイス、物のインターネット等を含む種々のタイプのコンピュータ又はそのコンポーネント上で実行されることができる。

【0154】

コンピュータシステム（９００）のための図１７に示されるコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する限定を示唆することを意図するものではない。また、コンポーネントの構成は、コンピュータシステム（９００）の例示的な実施形態に示されたコンポーネントの任意の１つ又は組み合わせに関するいかなる従属性又は要件を有するものとしても解釈されてはならない。

【0155】

コンピュータシステム（９００）は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スワイプ、データグローブの動き）、音声入力（例えば、音声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を通じて、一人又は複数の人間ユーザによる入力に応答し得る。また、ヒューマンインターフェースデバイスは、オーディオ（例えば、スピーチ、音楽、周囲の音声）、画像（例えば、スキャンされた画像、静止画カメラから得られる写真画像）、ビデオ（例えば、２次元ビデオ、立体画像を含む３次元ビデオ）のような、人間による意識的入力に必ずしも直接関係しない特定の媒体をキャプチャするために使用することができる。

【0156】

入力ヒューマンインターフェースデバイスは、キーボード（９０１）、マウス（９０２）、トラックパッド（９０３）、タッチスクリーン（９１０）、データグローブ、ジョイスティック（９０５）、マイクロホン（９０６）、スキャナ（９０７）、及びカメラ（９０８）の１つ又は複数を含み得る。

【0157】

コンピュータシステム（９００）はまた、特定のヒューマンインターフェース出力デバイスを含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、及びにおい／味を通して、1人又は複数の人間ユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイスを含み得る（例えば、タッチスクリーン（９１０）、データグローブ、又はジョイスティック（９０５）による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）。例えば、そのようなデバイスは、オーディオ出力デバイス（例えば、スピーカー（９０９）、ヘッドフォン（図示せず））、視覚出力デバイス（例えば、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン（９１０）であって、各々はタッチスクリーン入力機能が有っても無くてもよく、各々は触覚フィードバック機能が有っても無くてもよい－それらのいくつかは、二次元視覚出力又は立体画像出力のような手段を介して三次元出力以上を出力することができるもの；仮想現実メガネ（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず））、及びプリンタ（図示せず）であり得る。

【0158】

コンピュータシステム（９００）はまた、人間がアクセス可能な記憶装置、及び、CD/DVD又は類似の媒体（９２１）を有するCD/DVD ROM/RW（９２０）を含む光媒体、サムドライブ（９２２）、取り外し可能なハードドライブ又はソリッドステートドライブ（９２３）、テープ及びフロッピー（登録商標）ディスク（図示せず）のようなレガシー磁気媒体、セキュリティドングル（図示せず）のような特殊化されたROM/ASIC/PLDベースのデバイスなどの関連媒体を含むことができる。

【0159】

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

【0160】

コンピュータシステム（９００）はまた、１つ又は複数の通信ネットワークへのインターフェースを含むことができる。ネットワークは、例えば、無線、有線、光であることができる。ネットワークは、さらに、ローカル、ワイドエリア、メトロポリタン、車両及び工業、リアルタイム、遅延耐性などであることができる。ネットワークの例は、イーサネット（登録商標）、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、及び地上波TVを含むTV有線又はワイドエリアデジタルネットワーク、CANバスを含む車両及び産業用などが含む。特定のネットワークは、一般に、特定の汎用データポート又は周辺バス（９４９）に取り付けられる外部ネットワークインターフェースアダプタを必要とする（例えば、コンピュータシステム（９００）のUSBポート；他は、一般に、以下に説明するシステムバスに取り付けることによって、コンピュータシステム９００のコアに組み込まれる（例えば、PCコンピュータシステムへのイーサネットインターフェース又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース））。これらのネットワークのいずれかを使用して、コンピュータシステム（９００）は、他のエンティティと通信することができる。このような通信は、単指向性、受信のみ（例えば、放送テレビ）、単指向性送信専用（例えば、特定のCANバスデバイスへのCANバス）、又は、例えば、ローカル又はワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの双指向性であることができる。このような通信は、クラウドコンピューティング環境（９５５）への通信を含むことができる。特定のプロトコル及びプロトコルスタックは、上述のように、それらのネットワーク及びネットワークインターフェースの各々で使用することができる。

【0161】

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、及びネットワークインターフェース（９５４）は、コンピュータシステム（９００）のコア（９４０）に取り付けることができる。

【0162】

コア（９４０）は、１つ又は複数の中央処理ユニット（ＣＰＵ）（９４１）、グラフィックス処理ユニット（ＧＰＵ）（９４２）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）（９４３）の形の特殊なプログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ（９４４）などを含むことができる。これらのデバイスは、読出し専用メモリ（ＲＯＭ）（９４５）、ランダムアクセスメモリ（９４６）、内部非ユーザアクセス可能ハードドライブなどの内部大容量記憶装置、ＳＳＤ等（９４７）と共に、システムバス（９４８）を介して接続され得る。いくつかのコンピュータシステムでは、システムバス（９４８）は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするために、１つ又は複数の物理プラグの形態でアクセス可能であり得る。周辺装置は、コアのシステムバス（９４８）に直接取り付けることも、周辺バス（９４９）を介して取り付けることもできる。周辺バスのアーキテクチャは、PCI、USBなどを含む。グラフィックスアダプタ（９５０）は、コア（９４０）に含まれ得る。

【0163】

ＣＰＵ（９４１）、ＧＰＵ（９４２）、ＦＰＧＡ（９４３）、及びアクセラレータ（９４４）は、組み合わせて、上述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ（９４５）又はＲＡＭ（９４６）に記憶することができる。過渡的なデータはＲＡＭ（９４６）に記憶することもできるが、永久データは例えば内部大容量記憶装置（９４７）に記憶することができる。１つ又は複数のＣＰＵ（９４１）、ＧＰＵ（９４２）、大容量記憶装置（９４７）、ＲＯＭ（９４５）、ＲＡＭ（９４６）などと密接に関連付けることができるキャッシュメモリの使用を通じて、メモリデバイスのいずれかへの高速記憶及び検索を可能にすることができる。

【0164】

コンピュータ読取可能媒体は、種々のコンピュータ実装された動作を実行するためのコンピュータコードをその上に有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構築されたものであることができる、又はそれらは、コンピュータソフトウェア技術に熟練した者に良く知られかつ入手可能な種類のものであることができる。

【0165】

一例として、限定するものではなく、アーキテクチャ（９００）、具体的にはコア（９４０）を有するコンピュータシステムは、１つ又は複数の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行するプロセッサ（複数可）（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ等を含む）の結果として機能を提供することができる。そのようなコンピュータ読取可能媒体は、コア内部大容量記憶装置（９４７）又はＲＯＭ（９４５）のような非一時的な性質のものであるコア（９４０）の特定の記憶装置と同様に、上述のようなユーザがアクセス可能な大容量記憶装置に関連する媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に記憶され、コア（９４０）によって実行されることができる。コンピュータ読取可能媒体は、特定のニーズに応じて、１つ又は複数のメモリデバイス又はチップを含むことができる。ソフトウェアは、ＲＡＭ（９４６）に記憶されたデータ構造を定義し、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を修正することを含む、本明細書に記載された特定のプロセス又は特定のプロセスの特定の部分を、コア（９４０）及び具体的にその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に実行させることができる。加えて又は代替的に、コンピュータシステムは、回路（例えば、アクセラレータ（９４４））内に配線された又は他の方法で具現化された論理の結果として機能を提供することができ、これは、本明細書に記載される特定のプロセス又は特定のプロセスの特定の部分を実行するためのソフトウェアの代わりに、又はそれと共に動作することができる。ソフトウェアへの言及は、論理を含み、また、必要に応じて、その逆も可能である。コンピュータ読取可能媒体への参照は、実行のためのソフトウェアを記憶する回路（集積回路（ＩＣ）など）、実行のためのロジックを具体化する回路、又は適切な場合にはその両方を含むことができる。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

【0166】

本開示は、いくつかの非限定的な例示的実施形態を記載してきたが、本開示の範囲内にある変更、置換、及び種々の代替均等物がある。したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本開示の原理を具体化し、従って、本開示の精神及び範囲内にある多くのシステム及び方法を考案することができることが理解されるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図6F】

【図6G】

【図6H】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【図10A】

【図10B】

【図10C】

【図10D】

【図11A】

【図11B】

【図11C】

【図11D】

【図11E】

【図11F】

【図11G】

【図11H】

【図11I】

【図11J】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【国際調査報告】