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

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

▶ ベイジン バイトダンス ネットワーク テクノロジー カンパニー リミテッドの特許一覧 ▶ バイトダンス インコーポレイテッドの特許一覧

特許7479456ビデオ・データ処理方法及び装置並びに記憶媒体及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-25
(45)【発行日】2024-05-08
(54)【発明の名称】ビデオ・データ処理方法及び装置並びに記憶媒体及び方法
(51)【国際特許分類】
   H04N 19/119 20140101AFI20240426BHJP
   H04N 19/136 20140101ALI20240426BHJP
   H04N 19/176 20140101ALI20240426BHJP
【FI】
H04N19/119
H04N19/136
H04N19/176
【請求項の数】 9
(21)【出願番号】P 2022517726
(86)(22)【出願日】2020-09-21
(65)【公表番号】
(43)【公表日】2022-11-28
(86)【国際出願番号】 CN2020116471
(87)【国際公開番号】W WO2021052493
(87)【国際公開日】2021-03-25
【審査請求日】2022-03-31
(31)【優先権主張番号】PCT/CN2019/106925
(32)【優先日】2019-09-20
(33)【優先権主張国・地域又は機関】CN
【前置審査】
(73)【特許権者】
【識別番号】520476341
【氏名又は名称】北京字節跳動網絡技術有限公司
【氏名又は名称原語表記】Beijing Bytedance Network Technology Co., Ltd.
【住所又は居所原語表記】Room B-0035, 2/F, No.3 Building, No.30, Shixing Road, Shijingshan District Beijing 100041 China
(73)【特許権者】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】BYTEDANCE INC.
【住所又は居所原語表記】12655 West Jefferson Boulevard, Sixth Floor, Suite No. 137 Los Angeles, California 90066 United States of America
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ファン,クォイ
(72)【発明者】
【氏名】ザン,リー
(72)【発明者】
【氏名】ザン,カイ
(72)【発明者】
【氏名】ワン,ユエ
【審査官】岩井 健二
(56)【参考文献】
【文献】国際公開第2020/197996(WO,A1)
【文献】国際公開第2020/018267(WO,A1)
【文献】国際公開第2019/194463(WO,A1)
【文献】Benjamin Bross, Jianle Chen, and Shan Liu,Versatile Video Coding (Draft 6),Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-O2001 (version 14),15th Meeting: Gothenburg, SE,2019年07月31日,pp.25-28,93
【文献】Chih-Wei Hsu, et al.,CE1-related: Constraint for binary and ternary partitions,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-K0556-v1,11th Meeting: Ljubljana, SI,2018年07月16日,pp.1-3
【文献】Jianle Chen, Yan Ye, and Seung Hwan Kim,Algorithm description for Versatile Video Coding and Test Model 6 (VTM 6),Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-O2002-v1,15th Meeting: Gothenburg, SE,2019年08月,pp.1,12-17
(58)【調査した分野】(Int.Cl.,DB名)
H04N 19/00 - 19/98
(57)【特許請求の範囲】
【請求項1】
ビデオ・データを処理する方法であって:
ビデオの第1ブロックと前記ビデオのビットストリームとの間の変換に関し、前記第1ブロックを水平方向又は垂直方向において2つのサブ・ブロックに分ける第1パーティショニング・プロセスが、前記第1ブロックに許容されているかどうかを、前記第1ブロックのサイズと64との間の関係に基づいて決定するステップ;
前記ビデオの第2ブロックに関し、前記第2ブロックを水平方向又は垂直方向において3つのサブ・ブロックに分ける第2パーティショニング・プロセス前記第2ブロックに対してディセーブルにされていることを、前記第2ブロックの幅又は高さが、64及び最大三分木サイズのうちの小さい方の値より大きいことにより決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を含む、方法。
【請求項2】
前記垂直方向における前記第1パーティショニング・プロセスは、(i)前記第1ブロックの幅が64以下であり、及び(ii)前記第1ブロックの高さが64より大きい場合にはディセーブルにされる、請求項1に記載の方法。
【請求項3】
前記水平方向における前記第1パーティショニング・プロセスは、(i)前記第1ブロックの高さが64以下であり、及び(ii)前記第1ブロックの幅が64より大きい場合にはディセーブルにされる、請求項1又は2に記載の方法。
【請求項4】
前記第1パーティショニング・プロセスは、二分木(BT)パーティションを含む、請求項1-3のうちの何れか1項に記載の方法。
【請求項5】
前記変換は、前記ビデオを前記ビットストリームに符号化することを含む、請求項1-4のうちの何れか1項に記載の方法。
【請求項6】
前記変換は、前記ビデオを前記ビットストリームから復号化することを含む、請求項1-4のうちの何れか1項に記載の方法。
【請求項7】
プロセッサと命令を有する非一時的なメモリとを含むビデオ・データを処理する装置であって、前記命令は、前記プロセッサにより実行されると、前記プロセッサに:
ビデオの第1ブロックと前記ビデオのビットストリームとの間の変換に関し、前記第1ブロックを水平方向又は垂直方向において2つのサブ・ブロックに分ける第1パーティショニング・プロセスが、前記第1ブロックに許容されているかどうかを、前記第1ブロックのサイズと64との間の関係に基づいて決定するステップ;
前記ビデオの第2ブロックに関し、前記第2ブロックを水平方向又は垂直方向において3つのサブ・ブロックに分ける第2パーティショニング・プロセス前記第2ブロックに対してディセーブルにされていることを、前記第2ブロックの幅又は高さが、64及び最大三分木サイズのうちの小さい方の値より大きいことにより決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を行わせる、装置。
【請求項8】
命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、プロセッサに:
ビデオの第1ブロックと前記ビデオのビットストリームとの間の変換に関し、前記第1ブロックを水平方向又は垂直方向において2つのサブ・ブロックに分ける第1パーティショニング・プロセスが、前記第1ブロックに許容されているかどうかを、前記第1ブロックのサイズと64との間の関係に基づいて決定するステップ;
前記ビデオの第2ブロックに関し、前記第2ブロックを水平方向又は垂直方向において3つのサブ・ブロックに分ける第2パーティショニング・プロセス前記第2ブロックに対してディセーブルにされていることを、前記第2ブロックの幅又は高さが、64及び最大三分木サイズのうちの小さい方の値より大きいことにより決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を行わせる、記憶媒体。
【請求項9】
ビデオのビットストリームを記憶する方法であって:
ビデオの第1ブロックに関し、前記第1ブロックを水平方向又は垂直方向において2つのサブ・ブロックに分ける第1パーティショニング・プロセスが、前記第1ブロックに許容されているかどうかを、前記第1ブロックのサイズと64との間の関係に基づいて決定するステップ;
前記ビデオの第2ブロックに関し、前記第2ブロックを水平方向又は垂直方向において3つのサブ・ブロックに分ける第2パーティショニング・プロセス前記第2ブロックに対してディセーブルにされていることを、前記第2ブロックの幅又は高さが、64及び最大三分木サイズのうちの小さい方の値より大きいことにより決定するステップ;
前記決定に基づいてビットストリームを生成するステップ;及び
前記ビットストリームを非一時的なコンピュータ読み取り可能な記憶媒体に記憶するステップ;
を含、記憶方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
[0001] 本願は2020年9月21日付で出願された国際特許出願第PCT/CN2020/116471号に基づいており、同出願は2019年9月20日付で出願された国際特許出願第PCT/CN2019/106925号の優先権及び利益を主張するものである上記の全ての特許出願は全体的に参照により参照により本件に援用される。
【0002】
技術分野
[0002] 本件明細書はビデオ符号化及び復号化に関連する。
【背景技術】
【0003】
[0003] ビデオ圧縮の進歩にもかかわらず、デジタル・ビデオはインターネット及びその他のデジタル通信ネットワークにおいて利用する最大の帯域幅を占めている。ビデオの受信及び表示が可能な接続ユーザー・デバイスの数が増加するにつれて、デジタル・ビデオの利用に対する帯域幅需要は増加し続けることが予想される。
【発明の概要】
【0004】
[0004] デバイス、システム及び方法は、デジタル・ビデオ・コーディング、具体的にはルマ・マッピング及びクロマ・スケーリングが使用されるビデオ及び画像の符号化及び復号化に関連する。
【0005】
[0005] 一例の態様では、ビデオ処理方法が開示される。方法は、ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの前記現在の領域と前記ビデオのビットストリーム表現との間の変換を、ルール(復号化の間に前記第1クロマ・ブロックと前記第2クロマ・ブロックとが前記ルマ・ブロックのマッピングされた値に基づいて処理される順序を規定するルール)に従って実行するステップを含む。
【0006】
[0006] 別の例の態様では、ビデオ処理方法が開示される。方法は、ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの前記現在の領域と前記ビデオのビットストリーム表現との間の変換を実行するステップを含み、前記変換はクロマ残差のジョイント・コーディング(JCCR)処理を含み、前記第1クロマ・ブロックと前記第2クロマ・ブロックはそれぞれ前記ビデオの第1クロマ・カラー成分と前記ビデオの第2クロマ・カラー成分に対応し、前記JCCR処理は、前記第1クロマ・カラー成分の値に対応する入力と前記第2クロマ・カラー成分の導出された値に対応する出力とによるシフト演算を使用する、残差又は係数のスケーリング・プロセスを含む。
【0007】
[0007] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、垂直二分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップを含む。
【0008】
[0008] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、水平二分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップを含む。
【0009】
[0009] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、垂直三分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、前記現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップを含む。
【0010】
[0010] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、水平三分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、前記現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップ;及び前記決定に基づいて前記変換を実行するステップを含む。
【0011】
[0011] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、ビデオのクロマ・ブロックと前記ビデオのビットストリーム表現との間の変換を実行するステップを含み、前記クロマ・ブロックの残差は、スケーリング因子は特定のルマ領域の情報にアクセスすることなく決定されることを規定しているルールに従って決定されるスケーリング因子によってスケーリングされる。
【0012】
[0012] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの前記現在のブロックと前記ビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、前記ルールは、前記クロマCUの複数のクロマ・サンプルの残差に適用される複数のスケーリング因子の導出方法を規定しており、前記導出方法は、前記変換に関して前記クロマCUが複数の変換ユニット(TU)に更に分割されるかどうかに依存していない。
【0013】
[0013] 更に別の例の態様では、ビデオ処理方法が開示される。方法は、クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの前記現在のブロックと前記ビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、前記ルールは、前記クロマCUが複数の変換ユニット(TU)に分割される場合に、クロマ残差スケーリング処理がイネーブルにされるかどうかを規定している。
【0014】
[0014] 更に別の例の態様では、上述の方法は、プロセッサ実行可能コードの形態で具体化され、コンピュータ読み取り可能なプログラム媒体に記憶される。
【0015】
[0015] 更に別の例の態様では、上述の方法を実行するように構成された又は動作することが可能なデバイスが開示される。デバイスは、この方法を実装するようにプログラムされたプロセッサを含むことが可能である。
【0016】
[0016] 更に別の例の態様では、ビデオ・デコーダ装置は、本件で説明される方法を実装することができる。
【0017】
[0017] 開示された技術の上記及びその他の態様及び特徴は、図面、明細書及び特許請求の範囲において、より詳細に説明されている。
【図面の簡単な説明】
【0018】
[0018]
図1】エンコーダ・ブロック図の一例を示す。 [0019]
図2】マルチ・タイプ・ツリー分割モードの一例を示す。 [0020]
図3】ネスト化されたマルチ・タイプ・ツリー・コーディングのツリー構造による四分木でシグナリングする分割フラグの例を示す [0021]
図4】ネスト化されたマルチ・タイプ・ツリー・コーディングのブロック構造による四分木の例を示す。 [0022]
図5】128×128コーディング・ブロックに対するTT分割を行わない例を示す。 [0023]
図6】VTM6における許容されないTT及びBTパーティショニングの例を示す。 [0024]
図7】クロマ・スケーリング・アーキテクチャによるルマ・マッピングの一例を示す。 [0025]
図8】JEMにおける二次変換の例を示す。 [0026]
図9】提案された縮小二次変換(RST)の例を示す。 [0027]
図10】ビデオ処理のための復号化フローを示す。 [0028]
図11】LMCSが2つのクロマ・ブロックに対して1回適用される復号化フローの例を示す(JCCRは第1カラー成分ブロックの最終残差に適用される)。 [0029]
図12】JCCRが第1カラー成分の係数に適用される復号化フローの例を示す。 [0030]
図13】ビデオ・システムのブロック図である [0031]
図14】ビデオ処理装置の一例のブロック図である。 [0032]
図15】ビデオ処理の方法例のフローチャートである。
図16】ビデオ処理の方法例のフローチャートである。
図17】ビデオ処理の方法例のフローチャートである。
図18】ビデオ処理の方法例のフローチャートである。
図19】ビデオ処理の方法例のフローチャートである。
図20】ビデオ処理の方法例のフローチャートである。
図21】ビデオ処理の方法例のフローチャートである。
図22】ビデオ処理の方法例のフローチャートである。
図23】ビデオ処理の方法例のフローチャートである。 [0033]
図24】例示的なビデオ・コーディング・システムを示すブロック図である。 [0034]
図25】本開示の幾つかの実施形態によるエンコーダを示すブロック図である。 [0035]
図26】本開示の幾つかの実施形態によるデコーダを示すブロック図である。
【発明を実施するための形態】
【0019】
[0036] 開示される技術の実施形態は、圧縮パフォーマンスを改善するための既存のビデオ・コーディング規格(例えば、HEVC、H.265)及び将来の規格に適用される可能性がある。セクション見出しは、本件明細書においては説明の読みやすさを向上させるために使用されており、如何なる方法においても説明又は実施形態(及び/又は実装)を各セクションのみに限定するものではない。
【0020】
1. 概要
[0037] 本明細書はビデオ・コーディング技術に関連する。具体的には、ビデオ・コーディングにおけるクロマ・スケーリングに関連している。これは、HEVCのような既存のビデオ・コーディング規格、又はファイナライズされる予定の規格(汎用ビデオ・コーディング)に適用される可能性がある。
【0021】
2. 背景
[0038] ビデオ・コーディング規格は、主に、周知のITU-T及びISO/IEC規格の開発を通じて発展してきた。ITU-TはH.261とH.263を作成し、ISO/IECはMPEG-1とMPEG-4 Visualを作成し、2つの組織は共同してH.262/MPEG-2ビデオとH.264/MPEG-4アドバンスト・ビデオ・コーディング(AVC)とH.265/HEVC規格とを作成した。H.262以来、ビデオ・コーディング規格はハイブリッド・ビデオ・コーディング構造に基づいており、そこでは時間的予測と変換コーディングが使用される。HEVCを越える将来のビデオ・コーディング技術を探求するため、2015年に共同ビデオ探査チーム(Joint Video Exploration Team,JVET)がVCEGとMPEGにより共同で設立された。それ以来、多くの新しい方法がJVETによって採用されており、共同探索モデル(Joint Exploration Model,JEM)と名付けられる参照ソフトウェアに組み込まれている。2018年4月には、VCEG(Q6/16)とISO/IEC JTC1 SC29/WG11(MPEG)の間で共同ビデオ・エキスパート・チーム(JVET)が発足され、HEVCと比較して50%のビットレート低減を目指すVVC規格に取り組んでいる。
【0022】
[0039] VVCドラフトの最新バージョン、即ち多用途ビデオ・コーディング(ドラフト6)については以下を参照されたい:
[0040]http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/15_Gothenburg/wg11/JVET-O2001-v14.zip
[0041] VVCの最新リファレンス・ソフトウェア、即ちVTMについては以下を参照されたい:
[0042]https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-2.1

2.1 典型的なビデオ・コーデックのコーディング・フロー
[0043] 図1は、3つのループ内フィルタリング・ブロック:デブロッキング・フィルタ(DF)、サンプル適応オフセット(SAO)、及びALFを含むVVCのエンコーダ・ブロック図の例を示す。予め定義されたフィルタを使用するDFとは異なり、オフセットとフィルタ係数をシグナリングするコーディングされたサイド情報を用いて、SAO及びALFはそれぞれ、オフセットを追加することにより、及び有限インパルス応答(FIR)フィルタを適用することにより、元のサンプルと再構成されたサンプルとの間の平均二乗誤差を減少させるために、現在の画像の元のサンプルを使用する。ALFは、各ピクチャの最終処理ステージに位置し、前のステージで生成されたアーチファクトを捕捉して修復しようとするツールと見なすことができる。
【0023】
2.2 色空間及びクロマ・サブサンプリング
[0044] 色空間は、カラー・モデル(又はカラー・システム)としても知られており、これは単に色の範囲を数字のタプルとして、典型的には3つ又は4つの値又は色成分(例えば、RGB)としてシンプルに記述する抽象的な数学モデルである。基本的には、色空間は座標系とサブ空間の精緻化である。
【0024】
[0045] ビデオ圧縮で最も頻繁に使用される色空間は、YCbCrとRGBである。
【0025】
[0046] YCbCr、Y’CbCr、又はY Pb/Cb Pr/Crは、YCBCR又はY’CBCRのようにも書かれ、ビデオ及びデジタル写真システムにおけるカラー画像パイプラインの一部として使用される色空間のファミリーである。Y’はルマ成分であり、CBとCRは青色差と赤色差クロマ成分である。Y’(プライムあり)は輝度であるYと区別され、これは、光強度がガンマ補正RGB原色に基づいて非線形に符号化されることを意味する。
【0026】
[0047] クロマ・サブサンプリングは、人間の視覚系の知覚力は輝度よりも色差に対して低いことを活用して、クロマ情報についてはルマ情報よりも低い解像度を実装することによって、画像を符号化するプラクティスである。
【0027】
2.2.1. 4:4:4
[0048] 3つのY’CbCr成分はそれぞれ同じサンプル・レートを有するので、クロマ・サブサンプリングは行わない。この方式は、ハイ・エンドのフィルム・スキャナや映画ポスト・プロダクションでしばしば使用される。
【0028】
2.2.2. 4:2:2
[0049] 2つのクロマ成分はルマのサンプル・レートの半分でサンプリングされる:水平クロマ分解能は半分になる。これは、圧縮されていないビデオ信号の帯域幅を3分の1減らし、視覚的な差異はほとんどないか、全くない。
【0029】
2.2.3. 4:2:0
[0050] 4:2:0では、水平サンプリングは4:1:1と比較して2倍にされるが、この方式ではCbとCrチャネルは各々交互のラインでサンプリングされるのみであり、垂直解像度は半分になる。従って、データ・レートは同じである。CbとCrは、それぞれ水平方向と垂直方向の両方の2の因子でサブサンプリングされる。4:2:0方式の3つのバリエーションがあり、異なる水平及び垂直位置を有する。
・ MPEG-2では、CbとCrは水平方向に同じ場所に配置される。CbとCrは垂直方向のピクセル間に位置する(格子状に位置する)。
・ JPEG/JFIF、H.261、MPEG-1では、CbとCrは交互のルマ・サンプルの間で格子状に半分ずつ配置される。
・ 4:2:0 DVでは、CbとCrが水平方向に同じ場所に配置される。垂直方向では、それらは交互のライン上で同じ場所に配置される。
【0030】
2.3. パーティショニング
2.3.1. ツリー構造を用いるCTUのパーティショニング
[0051] HEVCでは、様々な局所特性に適応するために、コーディング・ツリーとして示される四分木構造を使用することによって、CTUはCUに分割される。インター・ピクチャ(時間的)又はイントラ・ピクチャ(空間的)予測を使用してピクチャ・エリアをコーディングするかどうかの決定は、リーフCUレベルで行われる。各リーフCUは、PU分割タイプに応じて、1つ、2つ、又は4つのPUに更に分割されることが可能である。1つのPU内では、同じ予測プロセスが適用され、関連情報はPUベースでデコーダへ伝送される。PU分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後に、リーフCUは、CUのコーディング・ツリーに類似する別の四分木構造に従って、変換ユニット(TU)にパーティション化されることが可能である。HEVC構造の重要な特徴の1つは、CU、PU、及びTUを含む複数のパーティション概念を有することである。
【0031】
[0052] VVCでは、バイナリ及びターナリ分割セグメンテーション構造を使用する入れ子型マルチ・タイプ・ツリーを有する四分木が、複数のパーティション・ユニット・タイプの概念に置き換わり、即ち、CU、PU及びTUの概念の分離を除去するが、ただし、最大変換長に対して大きすぎるサイズを有するCUについては必要とされ、CUパーティション形状に対して、より豊富な柔軟性をサポートする必要がある。コーディング・ツリー構造では、CUは正方形又は長方形の何れかの形状形をとることができる。コーディング・ツリー・ユニット(CTU)は、先ずクゥアターナリー・ツリー(四分木として知られている)構造によってパーティション化される。次いで、四分木リーフ・ノードは、マルチ・タイプ・ツリー構造によって更にパーティション化されることが可能である。図2に示すように、マルチ・タイプ・ツリー構造には、4つの分割タイプがあり、垂直二分割(SPLIT_BT_VER)、水平二分割(SPLIT_BT_HOR)、垂直三分割(SPLIT_TT_VER)、及び水平三分割(SPLIT_TT_HOR)である。マルチ・タイプ・ツリー・リーフ・ノードは、コーディング・ユニット(CU)と呼ばれ、CUが最大変換長に対して大き過ぎない限り、このセグメンテーションは、更なる如何なるパーティション化もなしに予測及び変換処理に使用される。これは、ほとんどの場合、CU、PU、及びTUは、ネスト化されたマルチ・タイプ・ツリー・コーディングのコーディング・ブロック構造を有する四分木において同じブロック・サイズを持つことを意味する。例外は、サポートされる変換長の最大値が、CUのカラー成分の幅又は高さよりも小さい場合に生じる。
【0032】
[0053] 図3は、ネストされたマルチ・タイプ・ツリー・コーディングのツリー構造を有する四分木におけるパーティション分割情報のシグナリングの仕組みを示す。コーディング・ツリー・ユニット(CTU)は四分木の根として扱われ、先ず、四分木構造によってパーティション化される。各々の四分木リーフ・ノードは(許容できる程度に十分に大きい場合は)、マルチ・タイプ・ツリー構造によって更にパーティション化される。マルチ・タイプ・ツリー構造では、第1フラグ(mtt_split_cu_flag)は、ノードが更にパーティション化されるかどうかを示すためにシグナリングされ;ノードが更にパーティション化される場合には、第2フラグ(mtt_split_cu_vertical_flag)が、分割方向を示すためにシグナリングされ、そして第3フラグ(mtt_split_cu_binary_flag)が、分割は二分割であるか又は三分割であるかを示すためにシグナリングされる。mtt_split_cu_vertical_flagとmtt_split_cu_binary_flagの値に基づいて、CUのマルチ・タイプ・ツリー分割モード(MttSplitMode)は、表2-1に示すように導出される。
【0033】
[0054] 図3は、ネスト化マルチ・タイプ・ツリー・コーディングのツリー構造を有する四分木における分割フラグ・シグナリングの例を示す。
【0034】
表2-1:マルチ・タイプ・ツリーシンタックス要素に基づくMttSplitModeの導出
【0035】
【数1】
[0055] 図4は、四分木とネスト化されたマルチ・タイプ・ツリー・コーディング・ブロック構造でCTUを複数のCUに分割している様子を示し、太いブロック・エッジは四分木パーティション化を表し、残りのエッジはマルチ・タイプ・ツリー・パーティション化を表す。ネスト化されたマルチ・タイプ・ツリー・パーティションを利用する四分木は、CUから構成されるコンテンツ適応コーディング・ツリー構造を提供する。CUのサイズは、CTUと同程度に大きくてもよいし、或いはルマ・サンプル単位で4×4と同程度に小さくてもよい。4:2:0クロマ・フォーマットの場合、最大クロマCBサイズは64×64であり、最小クロマCBサイズは2×2である。
【0036】
[0056] VVCでは、サポートされる最大ルマ変換サイズは64×64であり、サポートされる最大クロマ変換サイズは32×32である。CBの幅又は高さが、最大変換幅又は高さよりも大きい場合、CBは、その方向の変換サイズの制約を満たすように、自動的に水平方向及び/又は垂直方向に分割される。
【0037】
[0057] 以下のパラメータは、ネスト化されたマルチ・タイプ・ツリー・コーディング・ツリー方式を利用する四分木に対して、SPSシンタックス要素によって定義され指定される。
- CTU size:四分木のルート・ノード・サイズ
- MinQTSize:最小許容四分木リーフ・ノード・サイズ
- MaxBtSize:最大許容二分木ルート・ノード・サイズ
- MaxTtSize:最大許容三分木ルート・ノード・サイズ
- MaxMttDepth:四分木リーフから分割するマルチ・タイプ・ツリーの最大許容階層深度
- MinBtSize:最小許容二分木リーフ・ノード・サイズ
- MinTtSize:最小許容三分木リーフ・ノード・サイズ
[0058] ネスト化されたマルチ・タイプ・ツリー・コーディングのツリー構造を利用する四分木の一例において、CTUサイズは128×128ルマ・サンプルに設定され、4:2:0のクロマ・サンプルの2つの対応する64×64ブロックを伴い、MinQTSizeは16×16に設定され、MaxBtSizeは128×128に設定され、MaxTtSizeは64×64に設定され、MinBtSizeとMinTtSize(幅と高さの両方に対して)は4×4に設定され、MaxMttDepthは4に設定される。四分木パーティション化が最初にCTUに適用され、四分木リーフ・ノードを生成する。四分木リーフ・ノードは、16×16(即ち、MinQTSize)から128×128(即ち、CTUサイズ)までのサイズを有する可能性がある。リーフQTノードが128×128である場合、サイズがMaxBtSizeとMaxTtSize(即ち、64×64)を超えるので、二分木によって更には分割されない。そうでない場合、リーフ四分木ノードは、マルチ・タイプ・ツリーによって更に分割されることが可能である。従って、四分木リーフ・ノードはマルチ・タイプ・ツリーのルート・ノードでもあり、マルチ・タイプ・ツリー深度(mttDepth)を0として有している。マルチ・タイプ・ツリー深度がMaxMttDepth(即ち、4)に到達した場合、それ以上の分割は考慮されない。マルチ・タイプ・ツリー・ノードが、MinBtSizeに等しく、2*MinTtSize以下の幅を有する場合、更なる水平分割は考慮されない。同様に、マルチ・タイプ・ツリー・ノードが、MinBtSizeに等しく、2*MinTtSize以下の高さを有する場合、更なる垂直分割は考慮されない。
【0038】
[0059] VVCハードウェア・デコーダにおいて64×64ルマ・ブロックと32×32クロマ・パイプライン設計を可能にするために、図5に示すように、ルマ・コーディング・ブロックの幅又は高さの何れかが64より大きい場合、TT分割は禁止される。クロマ・コーディング・ブロックの幅又は高さの何れかが32を超える場合も、TT分割は禁止される。
【0039】
[0060] VTM6では、コーディング・ツリー方式は、ルマとクロマが別々のブロック・ツリー構造を有する能力をサポートする。現在、P及びBスライスの場合、1つのCTU中のルマ及びクロマCTBは、同一のコーディング・ツリー構造を共有しなければならない。しかしながら、Iスライスの場合、ルマとクロマは別々のブロック・ツリー構造を有することが可能である。個別のブロック・ツリー・モードが適用される場合、ルマCTBは或るコーディング・ツリー構造によってCUにパーティション化され、クロマCTBは別のコーディング・ツリー構造によってクロマCUにパーティション化される。これは、Iスライス内のCUがルマ成分のコーディング・ブロック、又は2つのクロマ成分のコーディング・ブロックで構成されている可能性があり、Pスライス又はBスライスのCUは、ビデオがモノクロでない限り、常に3つのカラー成分全てのコーディング・ブロックで構成されることを意味する。
【0040】
2.3.2. 仮想パイプライン・データ・ユニット(VPDU)
[0061] 仮想パイプライン・データ・ユニット(VPDU)は、ピクチャ内の重複しないユニットとして定義される。ハードウェア・デコーダでは、連続するVPDUは複数のパイプライン・ステージよって同時に処理される。VPDUサイズはほとんどのパイプライン・ステージにおいてバッファ・サイズに概ね比例するので、VPDUサイズを小さく保つことは重要である。ほとんどのハードウェア・デコーダでは、VPDUサイズは最大変換ブロック(TB)サイズに設定することができる。しかしながら、VVCでは、三分木(TT)と二分木 (BT)パーティションが、VPDUサイズを増やすことにつながる可能性がある。
【0041】
[0062] VPDUサイズを64×64ルマ・サンプルとして維持するために、図6に示すように、以下の標準的なパーティション制限(シンタックス・シグナリングの修正を伴う)がVTM6で適用される:
- 幅又は高さの何れか、又は幅と高さの両方が128に等しいCUに対してTT分割は許可されない。
- N≦64である128×NのCUでは(即ち、幅が128であり、高さが128未満である)、水平BTは許可されない。
- N≦64であるN×128のCUでは(即ち、高さが128であり、幅が128未満である)、垂直BTは許可されない。
【0042】
[0063] VPDUサイズはmin(64, CTUサイズ)に設定され、CTUサイズはルマCTBの幅/高さである。
【0043】
2.4. クロマ・スケーリングを行うルマ・マッピング(LMCS)
[0064] VTM6では、クロマ・スケーリングによるルマ・マッピング(LMCS)と呼ばれるコーディング・ツールが、ループ・フィルタの前に新しい処理ブロックとして追加される。LMCSは、1)適応区分線型モデルに基づくルマ成分のループ内マッピング;2)クロマ成分に対して、ルマ依存クロマ残差スケーリングが適用される、という2つの主要な構成要素を有する。
【0044】
[0065] 図7は、デコーダの視点からのLMCSアーキテクチャを示す。図7の明るい青色の影が付されたブロックは、マッピングされたドメインで処理が適用される場所を示し、これらは、逆量子化、逆変換、ルマ・イントラ予測、及びルマ残差を伴うルマ予測の追加を含む。図7で影が付されていないブロックは、元の(即ち、マッピングされていない)ドメインで処理が適用される場所を示し;これらは、デブロッキング、ALF、及びSAOのようなループ・フィルタ、動き補償された予測、クロマ・イントラ予測、クロマ残差を伴うクロマ予測の追加、及びデコードされたピクチャの参照ピクチャとしての格納を含む。図7で淡黄色の影が付されたブロックは、ルマ信号の順方向及び逆方向マッピング、並びにルマ依存クロマ・スケーリング・プロセスを含む、新しいLMCS機能ブロックである。VVCにおける他のツールと同様に、LMCSはSPSフラグを使用してシーケンス・レベルでイネーブル/ディセーブルにされることが可能である。
【0045】
2.4.1. 区分線型モデルを用いたルマ・マッピング
[0066] ルマ成分のループ内マッピングは、圧縮効率を改善するために、ダイナミック・レンジにわたってコードワードを再配分することによって、入力信号のダイナミック・レンジを調整する。ルマ・マッピングは、フォワード・マッピング関数FwdMapと、対応する逆マッピング関数InvMapとを利用する。FwdMap関数は、16個の等しい区間を用いる区分線型モデルを使用してシグナリングされる。InvMap関数は、シグナリングされることを必要とせず、その代わりにFwdMap関数から導出される。
【0046】
[0067] ルマ・マッピング・モデルは、スライス・レベルでシグナリングされる。先ず、プレゼンス・フラグがシグナリングされる。ルマ・マッピング・モデルが現在のスライスに存在する場合、対応する区分線型モデル・パラメータがシグナリングされる。区分線型モデルは、入力信号のダイナミック・レンジを16個の等しい部分に分割し、各部分に関し、その線型マッピング・パラメータは、その部分に割り当てられたコードワードの数を使用して表現される。10ビット入力を例にとると、16個の部分の各々は、それにデフォルトで割り当てられた64個のコードワードを有する。コードワードのシグナリングされた番号を使用して、スケーリング因子を計算し、それに応じてその部分に対してマッピング関数を調整する。スライス・レベルでは、LMCSプロセスが現在のスライスに適用されるかどうかを示すために、別のLMCSイネーブル・フラグがシグナリングされる。
【0047】
[0068] FwdMap区分線型モデルの各々のi番目の部分、i = 0...15は、2つの入力ピボット点InputPivot[]と2つの出力(マッピングされた)ピボット点MappedPivot[]によって定義される。InputPivot[]及びMappedPivot[]は、次のように計算される(10ビット・ビデオを仮定している):
【0048】
【数2】
ここで、SignalledCW[ i ]は、i番目の部分に対するコードワードのシグナリングされた番号である。
【0049】
[0069] 図7に示すように、インター・コーディングされたブロックに対して、動き補償予測が、マッピングされたドメインで実行される。言い換えると、DPBの参照信号に基づいて、動き補償予測ブロックYpredが計算された後に、FwdMap関数を適用して、元のドメインのルマ予測ブロックを、マッピングされたドメインにマッピングする:Y’pred=FwdMap(Ypred)。イントラ・コーディングされたブロックの場合、イントラ予測はマッピングされたドメインで実行されるので、FwdMap関数は適用されない。再構成されたブロックYrが計算された後、InvMap関数は、マッピングされたドメイン内の再構成されたルマ値を、元のドメイン(^Yi=InvMap(Yr))内の再構成されたルマ値に変換して戻すために適用される。InvMap関数は、イントラ及びインター・コーディングされたルマ・ブロックの両方に適用される。
【0050】
[0070] ルマ・マッピング・プロセス(順方向及び/又は逆方向マッピング)は、ルック・アップ・テーブル(LUT)又はオン・ザ・フライ演算の何れかを使用して実装することができる。LUTが使用される場合には、FwdMapLUTとInvMapLUTはスライス・レベルで使用するために予め計算され且つ予め記憶されることが可能であり、順方向及び逆方向のマッピングはそれぞれ
FwdMap(Ypred)=FwdMapLUT[Ypred] 及び
InvMapLUT(Yr)=InvMapLUT[Yr]
のようにシンプルに実装することができる。あるいは、オン・ザ・フライ演算が使用されてもよい。順方向マッピング関数FwdMapを例にとると、ルマ・サンプルが所属する部分を解明するために、サンプル値は6ビットだけ右にシフトされる(これは、16等分に相当する)。次いで、その部分の線型モデル・パラメータが検索され、オン・ザ・フライで適用されて、マッピングされたルマ値を演算する。iをピース・インデックスとし、a1,a2をそれぞれInputPivot[i]及びInputPivot[i+1]とし、b1,b2をそれぞれMappedPivot[i]及び MappedPivot[i+1]とする。FwdMap関数は次のように評価される:
FwdMap(Ypred) = ((b2 - b1)/(a2 - a1))*(Ypred - a1) + b1
[0071] InvMap関数は同様の方法でオン・ザ・フライで計算することが可能であるが、ただし、サンプル値が所属する部分を解明する場合に、単純な右ビット・シフトではなく、条件付きチェックが適用されることを必要とし、なぜならマッピングされたドメインにおけるピースは等しいサイズではないからである。
【0051】
2.4.2. ルマ依存クロマ残差スケーリング
[0072] クロマ残差スケーリングは、ルマ信号と対応するクロマ信号との間の相互作用を補償するように設計される。クロマ残差スケーリングがイネーブルにされるかどうかは、スライス・レベルでもシグナリングされる。ルマ・マッピングがイネーブルにされ、デュアル・ツリー・パーティション(セパレート・クロマ・ツリーとしても知られている)が現在のスライスに適用されていない場合には、ルマ依存のクロマ残差スケーリングがイネーブルにされているかどうかを示すために、追加のフラグがシグナリングされる。ルマ・マッピングが使用されない場合、又は現在のスライスでデュアル・ツリー・パーティションが使用される場合、ルマ依存クロマ残差スケーリングはディセーブルにされる。更に、ルマ依存クロマ残差スケーリングは、面積が4以下のクロマ・ブロックについては常にディセーブルにされる。
【0052】
[0073] クロマ残差スケーリングは、対応するルマ予測ブロックの平均値(イントラ・コーディングされたブロックとインター・コーディングされたブロックの両方)に依存する。ルマ予測ブロックの平均を、avgY’とする。CscaleInvの値は以下のステップで計算される:
1) avgY’が所属する区分線型モデルのインデックスYIdxを、InvMap関数に基づいて見出す。
【0053】
2) CscaleInv = cScaleInv[YIdx], ここで、cScaleInv[]は予め計算された16ピースLUTである。
【0054】
[0074] 現在のブロックが、イントラ、CIIP、又はイントラ・ブロック・コピー(IBC、現在ピクチャ参照、又はCPRとしても知られている)モードとしてコーディングされている場合、avgY’は、イントラ-、CIIP-、又はIBC-予測されたルマ値の平均として計算され;そうでない場合、avgY’は(2.4.1.におけるY’predのような)順方向マッピングされたインター予測されたルマ値の平均として計算される。サンプル・ベースで実行されるルマ・マッピングとは異なり、CScaleInvはクロマ・ブロック全体の定数値である。CScaleInvを用いて、クロマ残差スケーリングは次のように適用される:
【0055】
【数3】
2.5. クロマ残差のジョイント・コーディング(JCCR)
[0075] VVCドラフト6は、クロマ残差が一緒にコーディングされるモードをサポートする。ジョイント・クロマ・コーディング・モードの使用(アクティベーション)はTUレベルのフラグtu_joint_cbcr_residual_flagによって指定され、選択されるモードはクロマCBFにより暗黙に指定される。TUに対するクロマCBFの何れか又は双方が1に等しい場合に、フラグtu_joint_cbcr_residual_flagが存在する。正規のクロマ残差コーディング・モードに対してシグナリングされる通常のクロマQPオフセット値と区別するために、PPS及びスライス・ヘッダにおいて、クロマQPオフセット値が、ジョイント・クロマ残差コーディング・モードのためにシグナリングされる。これらのクロマQPオフセット値は、ジョイント・クロマ残差コーディング・モードを用いてコーディングされるこれらのブロックについて、クロマQP値を導出するために使用される。対応するジョイント・クロマ・コーディング・モード(表3のモード2)がTU内でアクティブである場合、このクロマQPオフセットは、そのTUの量子化及び復号化の間に、適用されるルマ導出クロマQPに追加される。他のモードでは(表3表2-2におけるモード1及び3:クロマ残差の再構成.値CSignはスライス・ヘッダで指定される符号値(+1又は-1)であり、resJointC[][]は送信された残差である)、クロマQPは従来のCb又はCrブロックに対するものと同様な方法で導出される。送信された変換ブロックからのクロマ残差(resCb及びresCr)の再構成プロセスは表3に示されている。このモードが起動されると、1つの単独のジョイント・クロマ残差ブロック(表3におけるresJointC[x][y])がシグナリングされ、Cb(resCb)の残差ブロック及びCr(resCr)の残差ブロックは、tu_cbf_cb, tu_cbf_cr,及びCSignのような、スライス・ヘッダで指定される符号値である情報を考慮して導出される。
【0056】
[0076] エンコーダ側では、以下で説明されるように、ジョイント・クロマ成分が導出される。モード(上記の表にリストされている)に応じて、resJointCはエンコーダによって次のようにして生成される:
- モードが2に等しい場合(再構成を利用する単一残差 Cb = C, Cr = CSign * C)、ジョイント残差は、以下に従って決定される:
resJointC[ x ][ y ] = ( resCb[ x ][ y ] + CSign * resCr[ x ][ y ] ) / 2.
- それ以外の場合、モードが1に等しい場合(再構成を利用する単一残差 Cb = C, Cr = (CSign * C) / 2)、ジョイント残差は、以下に従って決定される:
resJointC[ x ][ y ] = ( 4 * resCb[ x ][ y ] + 2 * CSign * resCr[ x ][ y ] ) / 5.
- それ以外の場合(モードは3に等しい。即ち、単独の残差、再構成 Cr = C, Cb = (CSign * C) / 2)、ジョイント残差は、以下に従って決定される:
resJointC[ x ][ y ] = ( 4 * resCr[ x ][ y ] + 2 * CSign * resCb[ x ][ y ] ) / 5.

表2-2:クロマ残差の再構成。値CSignはスライス・ヘッダで指定される符号値(+1又は-1)であり、resJointC[][]は送信された残差である。
【0057】
【数4】
この復号化プロセスの対応する仕様は以下の通りである:
tu_joint_cbcr_residual_flag[ x0 ][ y0 ]は、クロマ成分Cb とCr双方の残差サンプルが、単一の変換ブロックとしてコーディングされるかどうかを指定する。配列インデックスx0,y0は、ピクチャの左上ルマ・サンプルに対する、考察対象の変換ブロックの左上ルマ・サンプルの位置(x0,y0)を指定する。
【0058】
1に等しいtu_joint_cbcr_residual_flag[ x0 ][ y0 ]は、変換ユニット・シンタックスが、CbとCr双方の残差サンプルが単一変換ブロックから導出される場合のその単一変換ブロックの変換係数レベルを含むことを指定する。
【0059】
0に等しいtu_joint_cbcr_residual_flag[ x0 ][ y0 ]は、クロマ成分の変換係数レベルが、シンタックス要素tu_cbf_cb[x0][y0] とtu_cbf_cr[x0][y0]で示されるようにコーディングされることを指定する。
【0060】
tu_joint_cbcr_residual_flag[ x0 ][ y0 ]が存在しない場合、それは0に等しいと推定される。
【0061】
tu_joint_cbcr_residual_flag[ x0 ][ y0 ], tu_cbf_cb[ x0 ][ y0 ], 及びtu_cbf_cr[ x0 ][ y0 ]に応じて、変数TuCResMode[ x0 ][ y0 ]は次のように導出される:
- tu_joint_cbcr_residual_flag[ x0 ][ y0 ]が0に等しい場合、変数TuCResMode[ x0 ][ y0 ]は0に等しく設定される;
- それ以外の場合、tu_cbf_cb[ x0 ][ y0 ]が1に等しく、tu_cbf_cr[ x0 ][ y0 ]が0に等しいならば、変数TuCResMode[ x0 ][ y0 ]は1に等しく設定される;
- それ以外の場合、tu_cbf_cb[ x0 ][ y0 ]が1に等しいならば、変数TuCResMode[ x0 ][ y0 ]は2に等しく設定される;
- それ以外の場合、変数TuCResMode[ x0 ][ y0 ]は3に等しく設定される。

8.7.2. スケーリング&変換プロセス
4. 変換サンプルresSamples[ x ][ y ], x = 0..nTbW - 1, y = 0..nTbH - 1は、次のようにして導出される:
- cIdxがcodedCIdxに等しい場合、以下が適用される:
resSamples[ x ][ y ] = res[ x ][ y ] (8-947)
- それ以外の場合、TuCResMode[ xTbY ][ yTbY ]が2に等しいならば、以下が適用される:
resSamples[ x ][ y ] = cSign * res[ x ][ y ] (8-948)
- それ以外の場合、以下が適用される:
resSamples[ x ][ y ] = ( cSign * res[ x ][ y ] ) >> 1 (8-949)
2.6. 変換
[0077] 一次変換及び二次変換を含む2レベル変換が、1つの変換ブロックに適用される可能性がある。
【0062】
[0078] 一次変換については、DCT-IIが利用される。また、MTSがSPSに対してイネーブルにされている場合、コーディングされた情報/シグナリングされた情報に依存して、他の種類の変換行列が適用されてもよい。変換スキップ・モードは、変換行列が恒等変換である一次変換を適用するだけの特殊な場合として扱うことができる。
【0063】
[0079] 二次変換については、非セパラブル変換行列が利用される。
【0064】
[0080] 変換の関連する部分の詳細は以下に説明される。
【0065】
2.6.1. VVCにおける多重変換セット(MTS)
2.6.1.1 明示的な多重変換セット(MTS)
[0081] VTM4では、64×64までのサイズの大きなブロック・サイズの変換が可能にされており、これは主に高解像度ビデオ、例えば1080p及び4Kシーケンスに有用である。高周波変換係数は、サイズ(幅又は高さ、或いは幅及び高さの両方)が64に等しい変換ブロックに対してゼロ出力化され、その結果、低周波係数のみが維持される。例えば、M×N変換ブロックの場合、Mをブロック幅、Nをブロック高さとして、Mが64に等しい場合、変換係数の左32列のみが維持される。同様に、Nが64に等しい場合、変換係数の上位32行のみが維持される。大きなブロックに対して変換スキップ・モードが使用される場合、如何なる値もゼロ出力化されることなく、ブロック全体が使用される。
【0066】
[0082] HEVCで使用されてきたDCT-IIに加えて、多重変換選択(MTS)方式が、インター・コーディングされたブロックとイントラ・コーディングされたブロック双方を残差コーディングするために使用される。それはDCT8/DST7からの複数の選択された変換を使用する。新しく導入された変換行列はDST-VIIとDCT-VIIIである。以下の表2-3は、選択されたDST/DCTの基底関数を示す。
【0067】
表2-3 VVCで使用される変換行列の基底関数
【0068】
【数5】
[0083] 変換行列の直交性を維持するために、変換行列は、HEVCにおける変換行列よりも正確に量子化される。変換される係数の中間値を16ビットのレンジ内に、水平変換の後及び垂直変換の後に維持するために、全ての係数は10ビットを有するものとする。
【0069】
[0084] MTS方式を制御するために、別々のイネーブル・フラグが、イントラとインターそれぞれに対してSPSレベルで指定される。MTSがSPSでイネーブルにされると、CUレベル・フラグは、MTSが適用されるか否かを示すためにシグナリングされる。ここで、MTSはルマに対してのみ適用される。MTS CUレベル・フラグは、以下の条件が満たされる場合にシグナリングされる。
【0070】
- 幅と高さの両方が32以下であること
- CBFフラグが1に等しいこと
[0085] MTS CUフラグがゼロに等しい場合、DCT2が両方向に適用される。しかしながら、MTS CUフラグが1に等しいならば、2つの他のフラグが水平方向と垂直方向のそれぞれについて変換タイプを示すために追加的にシグナリングされる。変換及びシグナリング・マッピング・テーブルは、表2-4に示されるようなものである。変換行列の精度については、8ビットの一次変換コアが使用される。従って、4点DCT-2及びDST-7、8点DCT-2、16点DCT-2、32点DCT-2を含むHEVCで使用される全ての変換コアは同じに保たれる。また、64点DCT-2、4点DCT-8、8点DCT-8、16点DST-7、32点DCT-8を含む他の変換コアは、8ビット一次変換コアを使用する。
【0071】
表2-4:水平方向及び垂直方向のtu_mts_idxのデコードされた値と対応する変換行列の対応関係
【0072】
【数6】
[0086] 大きなサイズのDST-7及びDCT-8の複雑さを低減するために、サイズ(幅又は高さ、或いは幅及び高さの両方)が32に等しいDST-7及びDCT-8ブロックに関し、高周波変換係数はゼロ出力化される。16×16の低周波領域内の係数のみが維持される。
【0073】
[0087] 異なる変換が適用される場合に加えて、VVCは、HEVCにおけるTSの概念に似た変換スキップ(TS)と呼ばれるモードもサポートする。TSはMTSの特殊なケースとして扱われる。
【0074】
2.6.2. LFNST(RST/NSSTとしても知られている)
[0088] JEMでは、二次変換は、(エンコーダでは)フォワード一次変換と量子化の間、及び(デコーダでは)量子化解除と逆一次変換の間で適用される。図8に示すように、4×4(又は8×8)の二次変換は、ブロック・サイズに依存して実行される。例えば、4×4二次変換は、小さなブロック(i.e., min (width, height) < 8)に適用され、より大きなブロック(i.e., min (width, height) > 4)については、8×8二次変換が8×8ブロック毎に適用される(widthは幅であり、heightは高さである)。
【0075】
[0089] 二次変換に対して、非セパラブル変換が適用され、従って、それは非セパラブル二次変換(Non-Separable Secondary Transform,NSST)とも命名される。全部で35個の変換セットがあり、変換セット当たり3個の非セパラブル変換行列(カーネル、各々が16×16行列を伴う)が使用される。
【0076】
[0090] 縮小二次変換(Reduced Secondary Transform, RST)は、低周波非セパラブル変換(low frequency non-separable transform, LFNST)としても知られ、JVET-K0099で導入されたものであり、(35個の変換セットの代わりに)4つの変換セットのマッピングがイントラ予測方向に従ってJVET-L0133で導入されている。この寄稿では、16×48及び16×16行列がそれぞれ8×8及び4×4ブロックに対して採用されている。表記上の便宜上、16×48変換はRST8×8と表記され、16×16変換はRST4×4と表記される。このような方法はVVCによって最近採用された。
【0077】
[0091] 図9は提案された縮小二次変換(RST)を示す。
【0078】
[0092] 二次フォワード変換とインバース変換は、一次変換のものとは別の処理ステップである。
【0079】
[0093] エンコーダでは、一次フォワード変換が先ず実行され、次いで二次フォワード変換と量子化、及びCABACビット符号化が続く。デコーダでは、CABACビット復号化及び逆量子化、次いで、二次逆変換が先ず実行され、一次逆変換が続く。RSTは、イントラ・コーディングされたTUにのみ適用される。
【0080】
2.7. コーディング・ツール間の相互作用
[0094] 現行のVVCにおける復号化の順序は図10に示されている。
【0081】
3. 本件で説明される技術的解決策によって解決される技術的課題
[0095] 現在の設計は次のような問題を含む:
1. 現在の復号順序は2つの欠点を含む:
a. 1つには、クロマ残差スケーリング・プロセスが、2つのクロマ・ブロックの各々に、たとえそれがJCCRコーディングされている場合でさえ適用され、それは演算量の無駄である。
【0082】
b. 別の問題は、中間値についてより高い精度が意図される場合に、逆量子化/変換後の残差ではなく、復号化された係数にJCCRが直接的に適用されるであろう。
【0083】
2. JCCRモード1及び3における残差の丸めは、それが残差の符号情報を考慮しないので、準最適である。
【0084】
3. ルマ・サンプルの最大変換サイズが32に等しい場合、BT又はTTから生じたパーティションはVPDU制限に違反する可能性がある。
【0085】
4. BT及びTTパーティションは最適化される可能性がある。
【0086】
5. ルマ・サンプルの最大変換サイズが32に等しい場合、LMCSは正しく動作しない可能性がある。
【0087】
6. ルマ及びクロマ再構成プロセス間の依存性は、エンコーダとデコーダ両方の待ち時間を増加させる。
【0088】
4. 技術例及び実施形態
[0096] 以下の詳細な発明は、一般的な概念を説明するための例示として考察されるべきである。これらの発明は狭義に解釈されるべきではない。更に、これらの発明は任意の方法で組み合わせることができる。
【0089】
[0097] 以下の説明では、CUは、単一のツリー・コーディング構造を有する全ての3色成分に関連する情報を含むことが可能である。あるいは、CUは、モノカラー・コーディングのルマ・カラー成分に関連付けられているだけの情報を含んでいてもよい。あるいは、CUは、デュアル・ツリー・コーディングのルマ・カラー成分(例えば、YCbCrフォーマットにおけるY成分又はGBRフォーマットにおけるG成分)に関連付けられているだけの情報を含んでいてもよい。あるいは、CUは、デュアル・ツリー・コーディングの2つのクロマ成分(例えば、YCbCrフォーマットにおけるCb及びCr成分、又はGBRフォーマットにおけるB及びR成分)に関連付けられているだけの情報を含んでいてもよい。
【0090】
[0098] 以下の説明において、“ブロック”は、コーディング・ユニット(CU)、変換ユニット(TU)、又はビデオ・データの任意の四角形領域を指してもよい。“現在のブロック”は、現在復号化/符号化されているコーディング・ユニット(CU)、又は現在復号化/符号化されている変換ユニット(TU)、又はビデオ・データの任意の復号化/符号化されている四角形領域を指してもよい。“CU”又は“TU”は、“コーディング・ブロック”及び“変換ブロック”としても知られている。
【0091】
[0099] 以下の説明において、“現在のブロック”は、現在、復号化/符号化されているコーディング・ユニット(CU)、又は現在、復号化/符号化されている変換ユニット(TU)を指す可能性がある。
【0092】
[0100] 以下の説明では、コーディング情報は、予測モード(例えば、イントラ/インター/IBCモード)、動きベクトル、参照ピクチャ、インター予測方向、イントラ予測モード、CIIP(combined intra inter prediction)モード、ISPモード、アフィン・イントラ・モード、使用される変換コア、変換スキップ・フラグ等、即ちブロックを符号化する場合に必要とされる情報を含む可能性がある。
【0093】
Shift(x, s)は次のように定義される:
Shift(x, s) = (x + off) >> s, ここで、変数offは0には等しくない整数であり、例えば、1<<(s-1)に設定される。
【0094】
SignShift(x, s)は次のように定義される:
【0095】
【数7】
ここで、変数offは、0又は1<<(s-1)のような整数である。
【0096】
1. 復号化プロセスは、次の順序で呼び出されるように変更される:
a. 一例では、LMCSにおけるクロマ残差スケーリング・プロセスは、同じ変換ユニット内の2つのクロマ・カラー成分に対応する2つのクロマ・ブロックのうちの1つに適用されるだけである。
【0097】
i. 一例では、クロマ残差スケーリング・プロセスは、第1カラー成分に適用されて、第1カラー成分のスケーリングされたクロマ残差(例えば、第1カラー成分の最終残差)を導出する。また、第1カラー成分のスケーリングされたクロマ残差(例えば、LMCSがクロマ・ブロックに適用されているもの)を利用して、第2カラー成分のスケーリングされたクロマ残差(例えば、第1カラー成分の最終残差)を導出することができる。
【0098】
1) 代替的に、更に、第2カラー成分のスケーリングされたクロマ残差をどのように導出するかは、復号化された情報、例えばJCCRに関連するサイド情報に依存する可能性がある。
【0099】
2) 一例では、JCCRは第1カラー成分のスケーリングされたクロマ残差に適用され、表2-2に対する入力(即ちresJointC)は第1カラー成分のスケーリングされたクロマ残差である。
ii. 代替的に、更に、必要に応じて、逆量子化及び逆変換が最初に第1カラー成分に適用され;次いで、必要に応じて、クロマ残差スケーリングを第1カラー成分に適用して、第1カラー成分の最終残差を導出し;最後に、JCCRを第1カラー成分の最終残差に適用して、第2カラー成分の残差を導出する。
【0100】
1) 代替的に、更に、上記処理の後に、クリッピングが、更に、第2カラー成分の残差に適用されてもよい。
【0101】
a. 一例では、残差は、第2カラー成分/クロマ成分のビット深度に依存する可能性がある範囲にクリップされてもよい。
【0102】
i. 一例では、範囲は、[ -( 1 << BitDepthC ), ( 1 << BitDepthC ) - 1]として定義されてもよい。
【0103】
iii. 復号化フローの一例は図11に示されている。特定のプロセス(例えば、逆変換)に対しては、復号化された情報に従ってスキップされてもよいことに留意されたい。
【0104】
b. 一例において、LMCSにおけるクロマ残差スケーリング・プロセスは、2つのステップに分割される:第1ステップは、入力値(Aで示される)又は絶対入力値(abs(A)で示される)とスケーリング因子(Sで示される)との乗算を計算することであり;第2ステップは、シフト演算(例えば、Shift(A, S)又はSignShift(A, S))を行うことである。
【0105】
i. 第1ステップは、同じ変換ユニット中の2つのクロマ・カラー成分に対応する2つのクロマ・ブロックのうちの1つのみに適用されることを提案する。
【0106】
1) 代替的に、更に、第1カラー成分について、逆量子化、逆変換の後、必要に応じて、第1ステップが、第1カラー成分の一時的なクロマ残差ブロックを生成するために以後に適用される。
【0107】
a. 代替的に、更に、第1カラー成分の一時的なクロマ残差ブロックを利用して、例えば、Shift(A, S)又はSignShift(A, S)のようなクロマ残差スケーリング・プロセスの第2ステップを呼び出すことによって、第1カラー成分の最終残差ブロックを生成してもよい。
【0108】
b. 代替的に、更に、第1カラー成分の一時的なクロマ残差ブロックを利用して、第2カラー成分の最終的な残差ブロックを生成してもよい。例えば、JCCRサイド情報に従って、JCCRモードが2に等しくない場合、cSign*Shift(A, S+1)又はcSign*SignShift(A, S+1)を使用し、ここで、cSignは、JCCRコーディングされたブロックに反転符号(invert sign)が適用されるかどうかの指標である。
【0109】
c. 一例では、第1カラー成分の復号化された係数(例えば、ビットストリームから分析されたもの)を利用して、第2カラー成分の係数を導出してもよい。
【0110】
i. 代替的に、更に、第2カラー成分の係数をどのように導出するかは、復号化された情報、例えばJCCRに関連するサイド情報に依存してもよい。
【0111】
1) 一例では、JCCRは第1カラー成分のスケーリングされたクロマ残差に適用され、表2-2に対する入力(即ち、resJointC)は第1カラー成分の復号化された係数である。
【0112】
ii. 一例では、JCCRは、第2カラー成分の係数を導出するために、第1カラー成分に関連する復号化された係数に最初に適用されてもよい。
【0113】
1) 代替的に、更に、JCCRの後に、逆量子化及び逆変換が必要に応じてそれぞれ2つのカラー成分に適用されてもよく;最後に、クロマ残差スケーリングが、2つのカラー成分のそれぞれに適用される。
【0114】
iii. 復号化フローの一例は図12に示されている。特定のプロセス(例えば、逆変換)に対しては、復号化された情報に従ってスキップされてもよいことに留意されたい。
【0115】
d. 一例において、‘第1カラー成分’は、Cbカラー成分のコーディングされたブロック・フラグ(CBF)(例えば、tu_cbf_cb)が1に等しいか、又は2つのカラー成分の双方のCBF(例えば、tu_cbf_cb及びtu_cbf_cr)が真である場合に、Cb(又はB)カラー成分として定義されてもよい。
【0116】
i. 代替的に、‘第2カラー成分’は、Cr(又はR)カラー成分として定義されてもよい。
【0117】
e. 一例において、‘第1カラー成分’は、Crカラー成分のコーディングされたブロック・フラグ(CBF)(例えば、tu_cbf_cr)が1に等しい場合に、Cr(又はR)カラー成分として定義されてもよい。
【0118】
i. 代替的に、‘第2カラー成分’は、Cb(又はB)カラー成分として定義されてもよい。
【0119】
2. JCCRにおける残差/係数スケーリング・プロセス(例えば、モード1及び/又は3)は、(x>>s)からShift(x, s)へ修正され、ここで、変数xは第1カラー成分の値であり、関数の出力は、第2カラー成分の対応する導出値である。
【0120】
a. 代替的に、プロセスはSignShift(x, s)に修正される。
【0121】
3. JCCRは、ゼロでない係数を有する全てのブロックに適用される代わりに、あるコード化モードに適用されてもよい。
【0122】
a. 一例では、これは、異なるカラー成分からの復号化された情報を利用するクロス・コンポーネント線型予測法でコーディングされたクロマ・ブロックに適用されてもよい。
【0123】
b. 一例では、これは、ルマ・ブロックから、クロマ・ブロックのイントラ予測モードを導出するダイレクト・モードでコーディングされたクロマ・ブロックに適用されてもよい。
【0124】
c. 代替的に、更に、JCCRサイド情報のシグナリング(例えば、tu_joint_cbcr_residual_flagで示される、JCCRがブロックに適用されるか否か)もスキップされる。
【0125】
4. JCCRは、シグナリングされずに、特定のブロック寸法に適用されてもよい。ブロック寸法をW*Hで表し、WとHはクロマ・サンプルの幅と高さである。
【0126】
d. 一例において、W<=T1及び/又はH<=T2である場合、JCCRが直接的に適用されてもよい。
【0127】
e. 一例において、W<T1及び/又はH<T2である場合、JCCRが直接的に適用されてもよい。
【0128】
f. 一例において、W*H<=T3である場合、JCCRが直接的に適用されてもよい。
【0129】
g. 一例において、W>=T1及び/又はH>=T2である場合、JCCRが直接的に適用されてもよい。
【0130】
h. 一例において、W>T1及び/又はH>T2である場合、JCCRが直接的に適用されてもよい。
【0131】
i. 一例において、W*H<=T3である場合、JCCRが直接的に適用されてもよい。
【0132】
j. 上記の実施例において、T1及び/又はT2及び/又はT3は、予め定義されていてもよいし、或いはシグナリングされてもよいし、或いは(例えば、ピクチャ/スライス量子化パラメータに従って)オン・ザ・フライで導出されてもよい整数である。
【0133】
i. 上記の例において、T1及び/又はT2及び/又はT3は、4、8、32、16、128に設定される可能性がある。
【0134】
k. 代替的に、更に、W及びHは、現在のクロマ・ブロックに対応するルマ・ブロック内のルマ・サンプルの幅及び高さを表す可能性がある。
【0135】
5. SPLIT_BT_VERが許可されるかどうか(allowSplitBtVer)は、現在のブロックのサイズ、VPDUサイズ(VpduSize)、及び最大変換ブロック・サイズ(MaxTbSize)に依存する可能性がある。
【0136】
l. 一例では、ブロック幅がVpduSize以下であり、且つブロック高さがVpduSizeより大きい場合に、allowSplitBtVerはFALSEに等しく設定されてもよい。
【0137】
i. 一例において、VpduSizeは64に設定される。
【0138】
m. 一例では、ブロック幅がMax(VpduSize, MaxTbSize)以下であり、且つブロック高さがMax(VpduSize, MaxTbSize)より大きい場合に、allowSplitBtVerはFALSEに等しく設定されてもよい。
【0139】
i. 一例では、VpduSizeは64に設定され、MaxTbSizeは64に設定される。
【0140】
ii. 一例では、VpduSizeは64に設定され、MaxTbSizeは32に設定される。
【0141】
6. SPLIT_BT_HORが許可されるかどうか(allowSplitBtHor)は、現在のブロックのサイズ、VPDUサイズ(VpduSize)、最大変換ブロック・サイズ(MaxTbSize)に依存する可能性がある。
【0142】
n. 一例では、ブロックの高さがVpduSize以下であり、且つブロックの幅がVpduSizeより大きい場合に、allowSplitBtHorはFALSEに等しく設定されてもよい。
【0143】
i. 一例では、VpduSizeは64に設定される。
【0144】
o. 一例では、ブロックの高さがMax(VpduSize, MaxTbSize)以下であり、且つブロックの幅がMax(VpduSize, MaxTbSize)より大きい場合に、allowSplitBtHorはFALSEに等しく設定されてもよい。
【0145】
i. 一例では、VpduSizeは64に設定され、MaxTbSizeは64に設定される。
【0146】
ii. 一例では、VpduSizeは64に設定され、MaxTbSizeは32に設定される。
【0147】
7. SPLIT_TT_VERが許可されるかどうか(allowSplitTtVer)は、現在のブロックのサイズ、VPDUサイズ(VpduSize)、最大変換ブロック・サイズ(MaxTbSize)、最大三分木サイズ(maxTtSize)に依存する可能性がある。
【0148】
p. 一例では、ブロック幅又はブロック高さがMin(VpduSize, maxTtSize)より大きい場合に、allowSplitTtVerはFALSEに等しく設定されてもよい。
【0149】
i. 一例では、VpduSizeは64に設定される。
【0150】
q. 一例では、ブロック幅又はブロック高さがMin(Max(VpduSize, MaxTbSize), maxTtSize)より大きい場合に、allowSplitTtVerはFALSEに等しく設定されてもよい。
【0151】
i. 一例では、VpduSizeは64に設定され、MaxTbSizeは64に設定される。
【0152】
ii. 一例では、VpduSizeは64に設定され、MaxTbSizeは32に設定される。
【0153】
8. SPLIT_TT_HORが許可されるかどうか(allowSplitTtHor)は、現在のブロックのサイズ、VPDUサイズ(VpduSize)、最大変換ブロック・サイズ(MaxTbSize)、最大三分木サイズ(maxTtSize)に依存する可能性がある。
【0154】
r. 一例では、ブロック幅又はブロック高さがMin(VpduSize, maxTtSize)より大きい場合に、allowSplitTtHorはFALSEに等しく設定されてもよい。
【0155】
i. 一例では、VpduSizeは64に設定される。
【0156】
s. 一例では、ブロック幅又はブロック高さがMin(Max(VpduSize, MaxTbSize), maxTtSize)より大きい場合に、allowSplitTtHorはFALSEに等しく設定されてもよい。
【0157】
i. 一例では、VpduSizeは64に設定され、MaxTbSizeは64に設定される。
【0158】
ii. 一例では、VpduSizeは64に設定され、MaxTbSizeは32に設定される。
【0159】
9. LMCSプロセスにおいてルマ・ブロックからクロマ・スケーリング因子を導出する場合に、ルマ・コーディング・ユニット(CU)から情報を取得することは許容されない。ルマCUは対応するものである。
【0160】
10. LMCSプロセスにおいてルマ・ブロックからクロマ・スケーリング因子を導出する場合に、ルマ・コーディング・ユニット(CU)から情報を取得することは許容されない。ルマCUは、現在のクロマ・ブロック中の代表クロマ・サンプルのうちの対応するルマ・サンプルをカバーする、対応するルマCUである。
【0161】
a. 代替的に、ルマCUは、現在のクロマ・ブロック中の任意のクロマ・サンプルの対応するルマ・サンプルをカバーする、対応するルマCUである。
【0162】
11. クロマCUが複数のTUに分割されるかどうかにかかわらず、1つのクロマCU内の全てのクロマ・サンプルに対して同じスケーリング因子を使用することを提案する。
【0163】
a. 代替的に、更に、クロマCUが複数のTUに分割されるかどうかにかかわらず、1つのクロマCU内の全てのクロマ・サンプルについてスケーリング因子を導出するために、同じルマ再構成済みサンプルがアクセスされてもよい。
【0164】
b. 代替的に、更に、全てのクロマ・サンプルのスケーリング因子を導出するために、同じルマ再構成済みサンプルがアクセスされてもよく、これらのルマ再構成済みサンプルは、現在のクロマCUの対応するルマCU外のものである。
【0165】
c. 代替的に、1つのクロマCUが複数のTUに分割される場合に、クロマ残差スケーリングは、TUの一部のみ、例えば、CUの上部境界におけるTUに適用されてもよい。
【0166】
d. 代替的に、1つのクロマCUが複数のTUに分割される場合に、クロマ残差スケーリングは、ディセーブルにされてもよい。
【0167】
e. 一例では、上記の方法は、現在のCUサイズが最大TBサイズより大きい場合に呼び出されてもよい。
【0168】
12. 提案された方法及び/又はどの条項が適用されるのかについての指示は、ビデオ・ユニット・レベルでシグナリングされてもよい。
【0169】
a. 一例では、ビデオ・ユニットは、タイル/ブリック/スライス/ピクチャ/サブ・ピクチャ/シーケンス/ビュー等であってもよい。
【0170】
b. 一例では、提案された方法をイネーブルにするかどうか、及び/又は提案された方法をどのようにイネーブルにするかは、シーケンス・パラメータ・セット/ビュー・パラメータ・セット/適応パラメータ・セット/ピクチャ・パラメータ・セット/ピクチャ・ヘッダ/スライス・ヘッダにおいてシグナリングされてもよい。
【0171】
c. 代替的に、提案された方法をイネーブルにするかどうか、及び/又は提案された方法をどのようにイネーブルにするかは、他のシンタックス要素によって制御されてもよい。
【0172】
i. 一例では、それはJCCRがイネーブルにされるかどうか(例えば、sps_joint_cbcr_enabled_flag)によって制御されてもよい。
【0173】
ii. 一例では、それは、両方のクロマ成分のコロケーテッド残差サンプル(co-located residual samples)が、反転した逆符号を有するかどうか(e.g., slice_joint_cbcr_sign_flag)によって制御されてもよい。
【0174】
iii. 一例において、それは、現在のブロックがインター・モードでコーディングされるか否かによって制御されてもよい。
【0175】
d. 提案された方法をイネーブルにするかどうか、及び/又は提案された方法をどのようにイネーブルにするかは、ブロック寸法、スライス・タイプ/ピクチャ・タイプ/時間レイヤ・インデックス/ビデオ・コンテンツ/カラー成分/パーティショニング・ツリー・タイプ/コーディングされるモード/変換情報などのような、現在のブロック及び/又は近くの(隣接する又は隣接していない)ブロックのコーディング情報に依存してもよい。
【0176】
i. 一例では、幅がT1より大きくはなく、且つ高さがT2より大きくはないブロックに対して、提案された方法が適用されてもよい。
【0177】
ii. 一例では、幅がT1より大きくはなく、又は高さがT2より大きくはないブロックに対して、提案された方法が適用されてもよい。
【0178】
iii. 一例では、幅×高さがT3より大きくないブロックに対して、提案された方法が適用されてもよい。
【0179】
iv. 一例では、それは、現在のブロックが、Kに等しいか又は等しくないJCCRモードでコーディングされるかどうかによって、制御されてもよい(例えば、K=2)。
【0180】
[0101] 図13は、本願で開示される種々の技術が実装され得る例示的なビデオ処理システム1300を示すブロック図である。種々の実装は、システム1300の構成要素の一部又は全部を含んでもよい。システム1300は、ビデオ・コンテンツを受信するための入力1302を含んでもよい。ビデオ・コンテンツは、生の又は非圧縮のフォーマット、例えば、8又は10ビットの多重成分ピクセル値で受信されてもよいし、又は圧縮された又は符号化されたフォーマットで受信されてもよい。入力1302は、ネットワーク・インターフェース、周辺バス・インターフェース、又は記憶インターフェースを表現している可能性がある。ネットワーク・インターフェースの例は、イーサーネット、光受動ネットワーク(PON)などのような有線インターフェースや、Wi-Fi又はセルラー・インターフェースのような無線インターフェースを含む。
【0181】
[0102] システム1300は、本件明細書で説明される種々のコーディング又は符号化方法を実装することが可能なコーディング構成要素1304を含んでもよい。コーディング構成要素1304は、入力1302からコーディング構成要素1304の出力までのビデオの平均ビットレートを低減して、ビデオのコーディングされた表現を生成することができる。従って、コーディング技術は、ビデオ圧縮又はビデオ・トランスコーディング技術と呼ばれることが間々ある。コーディング構成要素1304の出力は、記憶されてもよいし、あるいは構成要素1306によって表現されているように、接続された通信を介して伝送されてもよい。入力1302で受信されたビデオの記憶又は通信されるビットストリーム(又はコーディングされた)表現は、ディスプレイ・インターフェース1310に送信されるピクセル値又は表示可能なビデオを生成するために、構成要素1308によって使用されてもよい。ビットストリーム表現から、ユーザーが視聴可能なビデオを生成するプロセスは、ビデオ解凍と呼ばれることが間々ある。更に、特定のビデオ処理操作は、“コーディングする”操作又はツールと称されるが、コーディング・ツール又は操作はエンコーダで使用され、コーディングの結果を逆向きに処理する対応する復号化ツール又は操作はデコーダで実行されるであろう、ということは理解されるであろう。
【0182】
[0103] 周辺バス・インターフェース又はディスプレイ・インターフェースの例は、ユニバーサル・シリアル・バス(USB)又は高解像度マルチメディア・インターフェース(HDMI(登録商標))、ディスプレイポート(Displayport)などを含む可能性がある。ストレージ・インターフェースの例は、シリアル・アドバンスト・テクノロジ・アタッチメント(serial advanced technology attachment,SATA)、PCI、IDEインターフェースなどを含む。本件明細書で説明される技術は、携帯電話、ラップトップ、スマートフォン、又はその他のデバイスであってデジタル・データ処理及び/又はビデオ表示を実行することが可能なデバイス、のような種々の電子デバイスで具体化されることが可能である。
【0183】
[0104] 図14は、ビデオ処理装置1400のブロック図である。装置1400は、本願で説明される1つ以上の方法を実装するために使用されてもよい。装置1400は、スマートフォン、タブレット、コンピュータ、モノのインターネット(Internet of Things,IoT)受信機などで具体化されてもよい。装置1400は、1つ以上のプロセッサ1402、1つ以上のメモリ1404、及びビデオ処理ハードウェア1406を含んでもよい。プロセッサ1402は、本件明細書で説明される1つ以上の方法を実装するように構成されてもよい。メモリ(memories)1404は、本願で説明される方法及び技術を実装するために使用されるデータ及びコードを記憶するために使用されてもよい。ビデオ処理ハードウェア1406は、ハードウェア回路において、本件明細書で説明される幾つかの技術を実装するために使用されてもよい。幾つかの実装において、ハードウェア1406は、部分的に又は完全に、例えばグラフィックス・コプロセッサのようなプロセッサ1402の一部分であってもよい。
【0184】
[0105] 図15は、ビデオ処理の方法例1500のフローチャートである。方法1500は、オペレーション1510において、ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの現在の領域とビデオのビットストリーム表現との間の変換を、ルール(復号化の間に第1クロマ・ブロックと第2クロマ・ブロックとがルマ・ブロックのマッピングされた値に基づいて処理される順序を規定するルール)に従って実行するステップを含む。
【0185】
[0106] 図16は、ビデオ処理の方法例1600のフローチャートである。方法1600は、オペレーション1610において、ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの現在の領域とビデオのビットストリーム表現との間の変換を実行するステップを含み、そのため、変換は、クロマ残差のジョイント・コーディング処理を含み、その処理は、第1クロマ・カラー成分の値に対応する入力と第2クロマ・カラー成分の導出された値に対応する出力とによるシフト演算を使用する、残差又は係数のスケーリング・プロセスを含む。
【0186】
[0107] 図17は、ビデオ処理の方法例1700のフローチャートである。方法1700は、オペレーション1710において、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換に関し、垂直二分木パーティショニングが現在のブロックに適用可能であるかどうかを、現在のブロックのサイズと、現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップを含む。
【0187】
[0108] 方法1700は、オペレーション1720において、決定に基づいて変換を実行するステップを含む。
【0188】
[0109] 図18は、ビデオ処理の方法例1800のフローチャートである。方法1800は、オペレーション1810において、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換に関し、水平二分木パーティショニングが現在のブロックに適用可能であるかどうかを、現在のブロックのサイズと、現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップを含む。
【0189】
[0110] 方法1800は、オペレーション1820において、決定に基づいて変換を実行するステップを含む。
【0190】
[0111] 図19は、ビデオ処理の方法例1900のフローチャートである。方法1900は、オペレーション1910において、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換に関し、垂直三分木パーティショニングが現在のブロックに適用可能であるかどうかを、現在のブロックのサイズと、現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップを含む。
【0191】
[0112] 方法1900は、オペレーション1920において、決定に基づいて変換を実行するステップを含む。
【0192】
[0113] 図20は、ビデオ処理の方法例2000のフローチャートである。方法2000は、オペレーション2010において、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換に関し、水平三分木パーティショニングが現在のブロックに適用可能であるかどうかを、現在のブロックのサイズと、現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップを含む。
【0193】
[0114] 方法2000は、オペレーション2020において、決定に基づいて変換を実行するステップを含む。
【0194】
[0115] 図21は、ビデオ処理の方法例2100のフローチャートである。方法2100は、オペレーション2110において、ビデオのクロマ・ブロックとビデオのビットストリーム表現との間の変換を実行するステップを含み、その結果、クロマ・ブロックの残差は、スケーリング因子は特定のルマ領域の情報にアクセスすることなく決定されることを規定しているルールに従って決定されるスケーリング因子によってスケーリングされる。
【0195】
[0116] 図22は、ビデオ処理の方法例2200のフローチャートである。方法2200は、オペレーション2210において、クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、ルールは、クロマCUの複数のクロマ・サンプルの残差に適用される複数のスケーリング因子の導出方法を規定しており、導出方法は、変換に関してクロマCUが複数の変換ユニット(TU)に更に分割されるかどうかに依存していない。
【0196】
[0117] 図23は、ビデオ処理の方法例2300のフローチャートである。方法2300は、オペレーション2310において、クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの現在のブロックとビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、ルールは、クロマCUが複数の変換ユニット(TU)に分割される場合に、クロマ残差スケーリング処理がイネーブルにされるかどうかを規定している。
【0197】
[0118] 図24は、本開示の技術を利用することが可能な例示的なビデオ・コーディング・システム100を示すブロック図である。
【0198】
[0119] 図24に示すように、ビデオ・コーディング・システム100は、送信元デバイス110及び送信先デバイス120を含む可能性がある。送信元デバイス110は、符号化されたビデオ・データを生成することが可能であり、ビデオ符号化デバイスと言及されてもよい。送信先デバイス120は、送信元デバイス110によって生成された符号化されたビデオ・データを復号化することが可能であり、ビデオ復号化デバイスと言及されてもよい。
【0199】
[0120] 送信元デバイス110は、ビデオ・ソース112、ビデオ・エンコーダ114、及び入力/出力(I/O)インターフェース116を含むことが可能である。
【0200】
[0121] ビデオ・ソース112は、ビデオ・キャプチャ・デバイスのようなソース、ビデオ・コンテンツ・プロバイダーからビデオ・データを受信するためのインターフェース、及び/又はビデオ・データを生成するためのコンピュータ・グラフィックス・システム、又はそのようなソースの組み合わせを含んでもよい。ビデオ・データは、1つ以上のピクチャを含む可能性がある。ビデオ・エンコーダ114は、ビデオ・ソース112からのビデオ・データを符号化してビットストリームを生成する。ビットストリームは、ビデオ・データのコーディングされた表現を形成するビットのシーケンスを含む可能性がある。ビットストリームは、コーディングされたピクチャ及び関連するデータを含んでもよい。コーディングされたピクチャは、ピクチャのコーディングされた表現である。関連するデータは、シーケンス・パラメータ・セット、ピクチャ・パラメータ・セット、及びその他のシンタックス構造を含んでもよい。I/Oインターフェース116は、変調器/復調器(モデム)及び/又は送信機を含んでもよい。符号化されたビデオ・データは、ネットワーク130aを通じてI/Oインターフェース116を介して送信先デバイス120へ直接的に送信されてもよい。符号化されたビデオ・データはまた、送信先デバイス120によるアクセスのために記憶媒体/サーバー130b上に格納されてもよい。
【0201】
[0122] 送信先デバイス120は、I/Oインターフェース126、ビデオ・デコーダ124、及びディスプレイ・デバイス122を含んでもよい。
【0202】
[0123] I/Oインターフェース126は、受信機及び/又はモデムを含んでもよい。I/Oインターフェース126は、送信元デバイス110又は記憶媒体/サーバー130bから、符号化されたビデオ・データを取得することができる。ビデオ・デコーダ124は、符号化されたビデオ・データを復号化することができる。ディスプレイ・デバイス122は、復号化されたビデオ・データをユーザーに表示することができる。ディスプレイ・デバイス122は、送信先デバイス120と一体化されてもよいし、又は送信先デバイス120の外部にあってもよく、その場合の送信先デバイスは外部ディスプレイ・デバイスとのインターフェースとなるように構成される。
【0203】
[0124] ビデオ・エンコーダ114及びビデオ・デコーダ124は、高効率ビデオ・コーディング(High Efficiency Video Coding,HEVC)規格、汎用ビデオ・コーディング(Versatile Video Coding,VVC)規格、及びその他の現行及び/又は将来の規格のようなビデオ圧縮規格に従って動作することができる。
【0204】
[0125] 図25はビデオ・エンコーダ200の一例を示すブロック図であり、これは図24に示すシステム100内のビデオ・エンコーダ114であってもよい。
【0205】
[0126] ビデオ・エンコーダ200は、本開示の技術の何れか又は全てを実行するように構成することができる。図25の例では、ビデオ・エンコーダ200は、複数の機能的な構成要素を含む。本開示で説明される技術は、ビデオ・エンコーダ200の種々の構成要素の間で共有されてもよい。幾つかの例において、プロセッサは、本開示で説明される技術の何れか又は全てを実行するように構成することができる。
【0206】
[0127] ビデオ・エンコーダ200の機能的な構成要素は、パーティション・ユニット201と、モード選択ユニット203、動き推定ユニット204、動き補償ユニット205、及びイントラ予測ユニット206を含むことが可能な予測ユニット202と、残差生成ユニット207と、変換ユニット208と、量子化ユニット209と、逆量子化ユニット210と、逆変換ユニット211と、再構成ユニット212と、バッファ213と、エントロピー符号化ユニット214とを含むことが可能である。
【0207】
[0128] 他の例では、ビデオ・エンコーダ200は、より多い、より少ない、又は異なる機能的な構成要素を含む可能性がある。一例では、予測ユニット202は、イントラ・ブロック・コピー(IBC)ユニットを含む可能性がある。IBCユニットはIBCモードで予測を実行することが可能であり、そのモードでは、少なくとも1つの参照ピクチャは現在のビデオ・ブロックが配置されているピクチャである。
【0208】
[0129] 更に、動き推定ユニット204や動き補償ユニット205のような幾つかの構成要素は、高度に統合されていてもよいが、説明のために図5の例では別々に表現されている。
【0209】
[0130] パーティション・ユニット201は、ピクチャを1つ以上のビデオ・ブロックにパーティション化することができる。ビデオ・エンコーダ200及びビデオ・デコーダ300は、様々なビデオ・ブロック・サイズをサポートすることができる。
【0210】
[0131] モード選択ユニット203は、コーディング・モードのうちの一方、インター又はイントラを、例えば誤り結果に基づいて選択し、その結果のイントラ・コーディング又はインター・コーディングされたブロックを、残差ブロック・データ生成のために残差生成ユニット207へ、及び参照ピクチャとして使用する符号化済みブロックの再構成のために再構成ユニット212へ提供する。幾つかの例では、モード選択ユニット203は、予測がインター予測信号及びイントラ予測信号に基づいているイントラ&インター予測コンビネーション(CIIP)モードを選択することができる。モード選択ユニット203はまた、インター予測の場合に、ブロックに対する動きベクトルの解像度(例えば、サブ・ピクセル又は整数ピクセル精度)を選択することができる。
【0211】
[0132] 現在のビデオ・ブロックに関してインター予測を実行するために、動き推定ユニット204は、バッファ213からの1つ以上の参照フレームを現在のビデオ・ブロックと比較することによって、現在のビデオ・ブロックの動き情報を生成することができる。動き補償ユニット205は、現在のビデオ・ブロックに関連するピクチャ以外のバッファ213からのピクチャの動き情報及び復号化されたサンプルに基づいて、現在のビデオ・ブロックについて予測されるビデオ・ブロックを決定することができる。
【0212】
[0133] 動き推定ユニット204と動き補償ユニット205は、例えば、現在のビデオ・ブロックがIスライスであるか、Pスライスであるか、又はBスライスであるかどうかに依存して、現在のビデオ・ブロックに対して様々な処理を実行することができる。
【0213】
[0134] 幾つかの例では、動き推定ユニット204は、現在のビデオ・ブロックに対して片-方向予測を実行することができ、動き推定ユニット204は、現在のビデオ・ブロックに対する参照ピクチャ・ブロックについて、リスト0又はリスト1の参照ピクチャを検索することができる。次いで、動き推定ユニット204は、参照ビデオ・ブロックを含むリスト0又はリスト1内の参照ピクチャを示す参照インデックスと、現在のビデオ・ブロック及び参照ビデオ・ブロックの間の空間的変位を示す動きベクトルとを生成することができる。動き推定ユニット204は、参照インデックス、予測方向インジケータ、及び動きベクトルを、現在のビデオ・ブロックの動き情報として出力することができる。動き補償ユニット205は、現在のビデオ・ブロックの動き情報によって示される参照ビデオ・ブロックに基づいて、現在のブロックの予測されたビデオ・ブロックを生成することができる。
【0214】
[0135] 他の例では、動き推定ユニット204は、現在のビデオ・ブロックに対して双-方向予測を実行することができ、動き推定ユニット204は、現在のビデオ・ブロックに対する参照ビデオ・ブロックについて、リスト0内の参照ピクチャを検索することができ、また、現在のビデオ・ブロックに対する別の参照ビデオ・ブロックについて、リスト1内の参照ピクチャを検索することができる。次いで、動き推定ユニット204は、参照ビデオ・ブロックを含むリスト0及びリスト1内の参照ピクチャを示す参照インデックスと、参照ビデオ・ブロック及び現在のビデオ・ブロックの間の空間的変位を示す動きベクトルとを生成することができる。動き推定ユニット204は、現在のビデオ・ブロックの動き情報として、現在のビデオ・ブロックの参照インデックスと動きベクトルを出力することができる。動き補償ユニット205は、現在のビデオ・ブロックの動き情報によって示される参照ビデオ・ブロックに基づいて、現在のビデオ・ブロックの予測されたビデオ・ブロックを生成することができる。
[0136] 幾つかの例では、動き推定ユニット204は、デコーダの復号化処理のための動き情報の完全なセットを出力することができる。
【0215】
[0137] 幾つかの例では、動き推定ユニット204は、現在のビデオに対する動き情報の完全なセットを出力しない可能性がある。むしろ、動き推定ユニット204は、他のビデオ・ブロックの動き情報を参照して、現在のビデオ・ブロックの動き情報をシグナリングすることができる。例えば、動き推定ユニット204は、現在のビデオ・ブロックの動き情報が、隣接するビデオ・ブロックの動き情報と十分に類似していることを判断することができる。
【0216】
[0138] 一例では、動き推定ユニット204は、現在のビデオ・ブロックに関連するシンタックス構造において、現在のビデオ・ブロックが別のビデオ・ブロックと同じ動き情報を有することをビデオ・デコーダ300に指示する値を指定することができる。
【0217】
[0139] 別の例では、動き推定ユニット204は、現在のビデオ・ブロックに関連するシンタックス構造において、別のビデオ・ブロック及び動きベクトル差分(MVD)を識別することができる。動きベクトル差分は、現在のビデオ・ブロックの動きベクトルと指定されたビデオ・ブロックの動きベクトルとの間の差分を示す。ビデオ・デコーダ300は、指定されたビデオ・ブロックの動きベクトルと動きベクトル差分とを使用して、現在のビデオ・ブロックの動きベクトルを決定することができる。
【0218】
[0140] 上述したように、ビデオ・エンコーダ200は、動きベクトルを予測的にシグナリングすることができる。ビデオ・エンコーダ200によって実現され得る予測シグナリング技術の2つの例は、アドバンスト動きベクトル予測(advanced motion vector predication,AMVP)及びマージ・モード・シグナリングを含む。
【0219】
[0141] イントラ予測ユニット206は、現在のビデオ・ブロックに対してイントラ予測を実行することができる。イントラ予測ユニット206が現在のビデオ・ブロックに対してイントラ予測を実行する場合、イントラ予測ユニット206は、同じピクチャ内の他のビデオ・ブロックの復号化されたサンプルに基づいて、現在のビデオ・ブロックに対する予測データを生成することができる。現在のビデオ・ブロックに対する予測データは、予測されるビデオ・ブロックと種々のシンタックス要素を含んでもよい。
【0220】
[0142] 残差生成ユニット207は、現在のビデオ・ブロックから、現在のビデオ・ブロックの予測されたビデオ・ブロックを減算することによって(例えば、マイナス符号で示される)、現在のビデオ・ブロックに対する残差データを生成することができる。現在のビデオ・ブロックの残差データは、現在のビデオ・ブロック内のサンプルの異なるサンプル成分に対応する残差ビデオ・ブロックを含んでもよい。
【0221】
[0143] 他の例では、例えばスキップ・モードでは、現在のビデオ・ブロックに関し、現在のビデオ・ブロックに対する残差データが存在しない場合があり、残差生成ユニット207は減算処理を実行しない可能性がある。
【0222】
[0144] 変換処理ユニット208は、現在のビデオ・ブロックに関連する残差ビデオ・ブロックに、1つ以上の変換を適用することによって、現在のビデオ・ブロックに対する1つ以上の変換係数ビデオ・ブロックを生成することができる。
【0223】
[0145] 変換処理ユニット208が現在のビデオ・ブロックに関連する変換係数ビデオ・ブロックを生成した後、量子化ユニット209は、現在のビデオ・ブロックに関連する1つ以上の量子化パラメータ(QP)値に基づいて、現在のビデオ・ブロックに関連する変換係数ビデオ・ブロックを量子化することができる。
【0224】
[0146] 逆量子化ユニット210及び逆変換ユニット211はそれぞれ逆量子化及び逆変換を変換係数ビデオ・ブロックに適用し、変換係数ビデオ・ブロックから残差ビデオ・ブロックを再構成することができる。再構成ユニット212は、再構成された残差ビデオ・ブロックを、予測ユニット202によって生成された1つ以上の予測されたビデオ・ブロックからの対応するサンプルに追加し、現在のブロックに関連する再構成されたビデオ・ブロックを生成して、バッファ213に記憶することができる。
【0225】
[0147] 再構成ユニット212がビデオ・ブロックを再構成した後、ループ・フィルタリング動作を実行し、ビデオ・ブロック内のビデオ・ブロッキング・アーチファクトを低減することができる。
【0226】
[0148] エントロピー符号化ユニット214は、ビデオ・エンコーダ200の他の機能的な構成要素からデータを受信することができる。エントロピー符号化ユニット214がデータを受信すると、エントロピー符号化ユニット214は、1つ以上のエントロピー符号化動作を実行して、エントロピー符号化されたデータを生成し、エントロピー符号化されたデータを含むビットストリームを出力することができる。
【0227】
[0149] 図26は、ビデオ・デコーダ300の一例を示すブロック図であり、これは図24に示すシステム100内のビデオ・デコーダ114であってもよい。
【0228】
[0150] ビデオ・デコーダ300は、本開示の技術の何れか又は全てを実行するように構成することができる。図26の例では、ビデオ・デコーダ300は、複数の機能的構成要素を含む。本開示で説明される技術は、ビデオ・デコーダ300の種々の構成要素の間で共有されてもよい。幾つかの例において、プロセッサは、本開示で説明される技術の何れか又は全てを実行するように構成することができる。
【0229】
[0151] 図26の例では、ビデオ・デコーダ300は、エントロピー復号化ユニット301と、動き補償ユニット302と、イントラ予測ユニット303と、逆量子化ユニット304と、逆変換ユニット305と、再構成ユニット306と、バッファ307とを含む。ビデオ・デコーダ300は、幾つかの例において、ビデオ・エンコーダ200(図25)に関して説明した符号化経路と概ね逆の復号化経路を実行することができる。
【0230】
[0152] エントロピー復号化ユニット301は、符号化されたビットストリームを取り出すことができる。符号化されたビットストリームは、エントロピー符号化されたビデオ・データ(例えば、ビデオ・データの符号化されたブロック)を含むことができる。エントロピー復号化ユニット301は、エントロピー符号化されたビデオ・データを復号化することができ、エントロピー復号化されたビデオ・データから、動き補償ユニット302は、動きベクトル、動きベクトル精度、参照ピクチャ・リスト・インデックス、及びその他の動き情報を含む動き情報を決定することができる。動き補償ユニット302は、例えば、AMVP及びマージ・モードを実行することによって、そのような情報を決定することができる。
【0231】
[0153] 動き補償ユニット302は、おそらくは補間フィルタに基づいて補間を実行することによって、動き補償されたブロックを生成することができる。サブ・ピクセル精度で使用される補間フィルタのための識別子が、シンタックス要素に含まれてもよい。
【0232】
[0154] 動き補償ユニット302は、ビデオ・ブロックの符号化中にビデオ・エンコーダ20によって使用されるような補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間された値を計算してもよい。動き補償ユニット302は、受信したシンタックス情報に従ってビデオ・エンコーダ200によって使用される補間フィルタを決定し、補間フィルタを使用して予測ブロックを生成することができる。
【0233】
[0155] 動き補償ユニット302は、シンタックス情報の一部を使用して、符号化されたビデオ・シーケンスのフレーム及び/又はスライスを符号化するために使用されるブロックのサイズ、符号化されたビデオ・シーケンスのピクチャの各マクロブロックがどのようにパーティション化されるかを記述するパーティション情報、各パーティションがどのように符号化されるかを示すモード、インター符号化されたブロック各々に対する1つ以上の参照フレーム(及び参照フレーム・リスト)、及び符号化されたビデオ・シーケンスを復号化するための他の情報を決定することができる。
【0234】
[0156] イントラ予測ユニット303は、例えば、ビットストリームで受信したイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成することができる。逆量子化ユニット303は、ビットストリーム内で提供される、エントロピー復号化ユニット301によって復号化される量子化されたビデオ・ブロック係数を、逆量子化する、即ち、量子化解除する。逆変換ユニット303は、逆変換を適用する。
【0235】
[0157] 再構成ユニット306は、残差ブロックを、動き補償ユニット202又はイントラ予測ユニット303によって生成された対応する予測ブロックと合算して、復号化されたブロックを形成することができる。所望であれば、復号化されたブロックをフィルタリングしてブロック性アーチファクトを除去するために、デブロッキング・フィルタが適用されてもよい。次いで、復号化されたビデオ・ブロックはバッファ307に格納され、バッファ307は、後続の動き補償のための参照ブロックを提供する。
【0236】
[0158] 以下の解決策は何らかの実施形態における好ましい技術的解決策として実装されてもよい。
【0237】
[0159] A1. ビデオ処理方法であって、
ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの前記現在の領域と前記ビデオのビットストリーム表現との間の変換を、復号化の間に前記第1クロマ・ブロックと前記第2クロマ・ブロックとが前記ルマ・ブロックのマッピングされた値に基づいて処理される順序を規定するルールに従って実行するステップを含む方法。
【0238】
[0160] A2. 解決策A1に記載の方法において、前記第1クロマ・ブロックと前記第2クロマ・ブロックはそれぞれ前記ビデオの第1クロマ・カラー成分と前記ビデオの第2クロマ・カラー成分に対応し、前記第1クロマ・カラー成分と前記第2クロマ・カラー成分は同じ変換ユニットにおけるものであり、前記第1クロマ・ブロックと前記第2クロマ・ブロックを処理することに関連するクロマ残差スケーリング・プロセスは、前記第1クロマ・ブロック又は前記第2クロマ・ブロックの何れかに適用されることを、前記ルールは規定している。
【0239】
[0161] A3. 解決策A2に記載の方法において、前記第1クロマ・ブロックと前記第2クロマ・ブロックを処理することに関連するクロマ残差スケーリング・プロセスは、前記第1クロマ・カラー成分のスケーリングされたクロマ残差を導出するために、前記第1クロマ・カラー成分に適用されることを、前記ルールは規定している。
【0240】
[0162] A4. 解決策A3に記載の方法において、前記第1クロマ・カラー成分の前記スケーリングされたクロマ残差は、前記第2クロマ・カラー成分のスケーリングされたクロマ残差を導出するために使用されることを、前記ルールは更に規定している。
【0241】
[0163] A5. 解決策A3に記載の方法において、前記第2クロマ・カラー成分のスケーリングされたクロマ残差は、クロマ残差のジョイント・コーディング(JCCR)処理に関連するサイド情報に基づいて導出されることを、前記ルールは更に規定している。
【0242】
[0164] A6. 解決策A3に記載の方法において、クロマ残差のジョイント・コーディング(JCCR)処理は、前記第1クロマ・カラー・コンポーネントの前記スケーリングされたクロマ残差に関連することを、前記ルールは更に規定している。
【0243】
[0165] A7. 解決策A5に記載の方法において、逆量子化処理と逆変換は、前記クロマ残差スケーリング・プロセスを適用するのに先立って前記第1クロマ・カラー成分に適用されることを、前記ルールは更に規定している。
【0244】
[0166] A8. 解決策A7に記載の方法において、前記ルールは、前記第2クロマ・カラー成分の前記スケーリングされたクロマ残差に、クリッピング処理を適用することを更に規定している。
【0245】
[0167] A9. 解決策A8に記載の方法において、前記クリッピング処理の出力範囲は、前記第2クロマ・カラー成分のビット深度に基づいている。
【0246】
[0168] A10. 解決策A9に記載の方法において、前記出力範囲は、
[ -( 1 << BitDepthC ), ( 1 << BitDepthC ) - 1 ]
のように決定されており、BitDepthCは前記第2クロマ・カラー成分の前記ビット深度である。
【0247】
[0169] A11. 解決策A1に記載の方法において、前記第1クロマ・ブロックと前記第2クロマ・ブロックはそれぞれ前記ビデオの第1クロマ・カラー成分と前記ビデオの第2クロマ・カラー成分に対応し、前記ルールは、前記第1クロマ・ブロックと前記第2クロマ・ブロックを処理することに関連するクロマ残差スケーリング・プロセスは、入力とスケーリング因子との積を決定する第1ステップであって、前記入力は入力値又は前記入力値の絶対値を有する、第1ステップと、前記入力にシフト演算を適用する第2ステップであって、前記シフト演算は前記スケーリング因子を使用する、第2ステップとを含むことを規定している。
【0248】
[0170] A12. 解決策A11に記載の方法において、前記シフト演算は、
Shift(x, t) = (x + off) >> s
のように規定され、xは入力であり、sはスケーリング因子であり、offはゼロでない整数である。
【0249】
[0171] A13. 解決策A12に記載の方法において、off = ( 1 << (s-1) ) である。
【0250】
[0172] A14. 解決策A11に記載の方法において、前記シフト演算は、
【0251】
【数8】
のように規定され、xは前記入力であり、sは前記スケーリング因子であり、offは整数である。
【0252】
[0173] A15. 解決策A14に記載の方法において、off = 0又はoff = ( 1 << (s-1) )である。
【0253】
[0174] A16. 解決策A11乃至A15のうちの何れかの方法において、前記第1クロマ・カラー成分と前記第2クロマ・カラー成分は同じ変換ユニットにおけるものであり、前記ルールは、前記第1ステップが、前記第1クロマ・ブロック又は前記第2クロマ・ブロックの何れかに適用されることを規定している。
【0254】
[0175] A17. 解決策A16に記載の方法において、逆量子化処理と逆変換は、前記第1クロマ・カラー成分の一時クロマ残差ブロックを生成するために、前記第1ステップに先立って前記第1クロマ・カラー成分に適用されることを、前記ルールは更に規定している。
【0255】
[0176] A18. 解決策A17に記載の方法において、前記第1クロマ・カラー成分の最終クロマ残差ブロックは、前記第1クロマ・カラー成分の前記一時クロマ残差ブロックに基づいて、前記第2ステップを利用して生成されることを、前記ルールは更に規定している。。
【0256】
[0177] A19. 解決策A17に記載の方法において、前記第2クロマ・カラー成分の最終残差ブロックは、前記第1クロマ・カラー成分の前記一時クロマ残差ブロックに基づいて生成されることを、前記ルールは更に規定している。。
【0257】
[0178] A20. 解決策A19に記載の方法において、前記第2クロマ・カラー成分の前記最終残差ブロックは、クロマ残差のジョイント・コーディング(JCCR)処理に関連するサイド情報に更に基づいて生成される。
【0258】
[0179] A21. 解決策A20に記載の方法において、前記サイド情報は、前記JCCR処理でコーディングされるビデオ・ブロックに反転符号が適用されるかどうかの指標を含む。
【0259】
[0180] A22. 解決策A1に記載の方法において、前記第1クロマ・ブロックと前記第2クロマ・ブロックはそれぞれ前記ビデオの第1クロマ・カラー成分と前記ビデオの第2クロマ・カラー成分に対応し、前記ルールは、前記第2クロマ・カラー成分の係数を導出することは、前記第1クロマ・カラー成分の復号化された係数に基づくことを規定している。
【0260】
[0181] A23. 解決策A22に記載の方法において、前記第2クロマ・カラー成分の前記係数を導出することは、クロマ残差のジョイント・コーディング(JCCR)処理に関連するサイド情報に更に基づいている。
【0261】
[0182] A24. 解決策A22に記載の方法において、前記第2クロマ・カラー成分の前記係数は、クロマ残差のジョイント・コーディング(JCCR)処理を、前記第1クロマ・カラー成分の前記復号化された係数に適用した後に導出される。
【0262】
[0183] A25. 解決策A1乃至A24のうちの何れかの方法において、前記第1クロマ・カラー成分はCbカラー成分であり、前記第2クロマ・カラー成分はCrカラー成分である。
【0263】
[0184] A26. 解決策A1乃至A24のうちの何れかの方法において、前記第1クロマ・カラー成分はCrカラー成分であり、前記第2クロマ・カラー成分はCbカラー成分である。
【0264】
[0185] A27. ビデオ処理方法であって、
ルマ・ブロックと、第1クロマ・ブロックと、第2クロマ・ブロックとを含む現在の領域に関し、ビデオの前記現在の領域と前記ビデオのビットストリーム表現との間の変換を実行するステップを含み、前記変換はクロマ残差のジョイント・コーディング(JCCR)処理を含み、前記第1クロマ・ブロックと前記第2クロマ・ブロックはそれぞれ前記ビデオの第1クロマ・カラー成分と前記ビデオの第2クロマ・カラー成分に対応し、前記JCCR処理は、前記第1クロマ・カラー成分の値に対応する入力と前記第2クロマ・カラー成分の導出された値に対応する出力とによるシフト演算を使用する、残差又は係数のスケーリング・プロセスを含む。
【0265】
[0186] A28. 解決策A27に記載の方法において、前記シフト演算は、
Shift(x, t) = (x + off) >> s
のように規定され、xは前記入力であり、sは前記スケーリング因子であり、offはゼロでない整数である。
【0266】
[0187] A29. 解決策A27に記載の方法において、前記シフト演算は、
【0267】
【数9】
のように規定され、xは前記入力であり、sはスケーリング因子であり、offは整数である。
【0268】
[0188] A30. 解決策A27に記載の方法において、前記ルールは、前記JCCR処理は所定のモードでコーディングされたクロマ・ブロックに適用されることを更に規定している。
【0269】
[0189] A31. 解決策A30に記載の方法において、前記所定のモードは、クロス・コンポーネント線型モデル(CCLM)予測モードである。
【0270】
[0190] A32. 解決策A30に記載の方法において、前記所定のモードは、前記クロマ・ブロックのイントラ予測モードを、対応するルマ・ブロックに基づいて導出するダイレクト・モードである。
【0271】
[0191] A33. 解決策A30に記載の方法において、前記JCCR処理のためのサイド情報のシグナリングは、前記ビット表現から除外されている。
【0272】
[0192] A34. 解決策A27に記載の方法において、前記ビットストリーム表現から除外されている前記JCCRの適用の指示によらず、前記JCCR処理は、前記クロマ・サンプルにおける高さ(H)及び幅(W)を利用してビデオ・ブロックに適用される。
【0273】
[0193] A35. 解決策A34に記載の方法において、W≦T1及びH≦T2であり、T1及びT2は整数閾値である。
【0274】
[0194] A36. 解決策A34に記載の方法において、W×H≦T3であり、T3は整数閾値である。
【0275】
[0195] A37. 解決策A34に記載の方法において、W≧T1及びH≧T2であり、T1及びT2は整数閾値である。
【0276】
[0196] A38. 解決策A34に記載の方法において、W×H≧T3であり、T3は整数閾値である。
【0277】
[0197] A39. 解決策A35又はA37に記載の方法において、T1及びT2は、予め定められているか、前記ビットストリーム表現でシグナリングされるか、又はオン・ザ・フライで決定される。
【0278】
[0198] A40. 解決策A35又はA37に記載の方法において、T1=4,8,16,32,又は128であり、T2=4,8,16,32,128である。
【0279】
[0199] A41. 解決策A36又はA38に記載の方法において、T3=4,8,16,32,又は128である。
【0280】
[0200] A42. ビデオ処理方法であって、
ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、垂直二分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を含む方法。
【0281】
[0201] A43. 解決策A42に記載の方法において、前記現在のブロックの幅がVpduSize以下であり、前記現在のブロックの高さがVpduSizeより大きい場合には、前記垂直二分木パーティショニングは前記現在のブロックに適用されない。
【0282】
[0202] A44. 解決策A43に記載の方法において、VpduSize = 64である。
【0283】
[0203] A45. 解決策A42に記載の方法において、前記現在のブロックの幅がmax(VpduSize, MaxTbSize)以下であり、前記現在のブロックの高さがmax(VpduSize, MaxTbSize)より大きい場合には、前記垂直二分木パーティショニングは前記現在のブロックに適用されない。
【0284】
[0204] A46. 解決策A45に記載の方法において、VpduSize = 64及びMaxTbSize = 64である。
【0285】
[0205] A47. 解決策A45に記載の方法において、VpduSize = 64及びMaxTbSize = 32である。
【0286】
[0206] A48. ビデオ処理方法であって、
ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、水平二分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を含む方法。
【0287】
[0207] A49. 解決策A48に記載の方法において、前記現在のブロックの高さがVpduSize以下であり、前記現在のブロックの幅がVpduSizeより大きい場合には、前記水平二分木パーティショニングは前記現在のブロックに適用されない。
【0288】
[0208] A50. 解決策A49に記載の方法において、VpduSize = 64である。
【0289】
[0209] A51. 解決策A48に記載の方法において、前記現在のブロックの高さがmax(VpduSize, MaxTbSize)以下であり、前記現在のブロックの幅がmax(VpduSize, MaxTbSize)より大きい場合には、前記水平二分木パーティショニングは前記現在のブロックに適用されない。
【0290】
[0210] A52. 解決策A51に記載の方法において、VpduSize = 64及びMaxTbSize = 64である。
【0291】
[0211] A53. 解決策A51に記載の方法において、VpduSize = 64及びMaxTbSize = 32である。
【0292】
[0212] A54. ビデオ処理方法であって、
ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、垂直三分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、前記現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を含む方法。
【0293】
[0213] A55. 解決策A54に記載の方法において、前記現在のブロックの幅又は前記現在のブロックの高さがmin(VpduSize, maxTtSize)より大きい場合には、前記垂直三分木パーティショニングは前記現在のブロックに適用されない。
【0294】
[0214] A56. 解決策A55に記載の方法において、VpduSize = 64である。
【0295】
[0215] A57. 解決策A54に記載の方法において、前記現在のブロックの幅又は前記現在のブロックの高さがmin( max(VpduSize, MaxTbSize), maxTtSize)より大きい場合には、前記垂直三分木パーティショニングは前記現在のブロックに適用されない。
【0296】
[0216] A58. 解決策A57に記載の方法において、VpduSize = 64及びMaxTbSize = 64である。
【0297】
[0217] A59. 解決策A57に記載の方法において、VpduSize = 64及びMaxTbSize = 32である。
【0298】
[0218] A60. ビデオ処理方法であって、
ビデオの現在のブロックと前記ビデオのビットストリーム表現との間の変換に関し、水平三分木パーティショニングが前記現在のブロックに適用可能であるかどうかを、前記現在のブロックのサイズと、前記現在のブロックに設定された仮想パイプライン・データ・ユニット(VPDU)のサイズ(VpduSizeと記す)と、前記現在のブロックに設定された変換ブロックの最大サイズ(MaxTbSizeと記す)と、前記現在のブロックに設定された最大三分木サイズ(maxTtSizeと記す)とに基づいて決定するステップ;及び
前記決定に基づいて前記変換を実行するステップ;
を含む方法。
【0299】
[0219] A61. 解決策A60に記載の方法において、前記現在のブロックの幅又は前記現在のブロックの高さがmin(VpduSize, maxTtSize)より大きい場合には、前記水平三分木パーティショニングは前記現在のブロックに適用されない。
【0300】
[0220] A62. 解決策A61に記載の方法において、VpduSize = 64である。
【0301】
[0221] A63. 解決策A60に記載の方法において、前記現在のブロックの幅又は前記現在のブロックの高さがmin( max(VpduSize, MaxTbSize), maxTtSize)より大きい場合には、前記水平三分木パーティショニングは前記現在のブロックに適用されない。
【0302】
[0222] A64. 解決策A63に記載の方法において、VpduSize = 64及びMaxTbSize = 64である。
【0303】
[0223] A65. 解決策A63に記載の方法において、VpduSize = 64及びMaxTbSize = 32である。
【0304】
[0224] A66. ビデオ処理方法であって、
ビデオのクロマ・ブロックと前記ビデオのビットストリーム表現との間の変換を実行するステップを含み、前記クロマ・ブロックの残差は、スケーリング因子は特定のルマ領域の情報にアクセスすることなく決定されることを規定しているルールに従って決定されるスケーリング因子によってスケーリングされる、方法。
【0305】
[0225] A67. 解決策A66に記載の方法において、前記特定のルマ領域は、前記クロマ・ブロックの代表クロマ・サンプルの対応するルマ・サンプルをカバーするルマ・コーディング・ユニットに対応している。
【0306】
[0226] A68. 解決策A66に記載の方法において、前記特定のルマ領域は、前記クロマ・ブロックの全てのクロマ・サンプルに対応するルマ・サンプルをカバーするルマ・コーディング・ユニットに対応している。
【0307】
[0227] A69. 解決策A1乃至A68のうちの何れかの方法において、前記変換を実行するステップは、前記ビットストリーム表現を、前記現在のブロック又は前記現在の領域から生成するステップを含む。
【0308】
[0228] A70. 解決策A1乃至A68のうちの何れかの方法において、前記変換を実行するステップは、前記現在のブロック又は前記現在の領域を、前記ビットストリーム表現から生成するステップを含む。
【0309】
[0229] A71. プロセッサと命令を有する非一時的なメモリとを含むビデオ・システムにおける装置であって、前記命令は、前記プロセッサにより実行されると、解決策A1乃至A70のうちの1つ以上に記載されている方法を前記プロセッサに実行させる。
【0310】
[0230] A72. 非一時的なコンピュータ読み取り可能な媒体に記憶されたコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、解決策A1乃至A70のうちの1つ以上に記載されている方法を実行するためのプログラム・コードを含む。
【0311】
[0231] A73. 解決策A1乃至A70のうちの1つ以上に記載されている方法に従って生成されたビットストリーム表現を記憶するコンピュータ読み取り可能な媒体。
【0312】
[0232] 以下の追加的な解決策は何らかの実施形態における好ましい技術的解決策として実装されてもよい。
【0313】
[0233] B1. ビデオ処理方法であって、
クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの前記現在のブロックと前記ビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、前記ルールは、前記クロマCUの複数のクロマ・サンプルの残差に適用される複数のスケーリング因子の導出方法を規定しており、前記導出方法は、前記変換に関して前記クロマCUが複数の変換ユニット(TU)に更に分割されるかどうかに依存していない。
【0314】
[0234] B2. 解決策B1に記載の方法において、前記複数のスケーリング因子は、前記クロマCUが複数の変換ユニット(TU)に分割されるかどうかによらず同じであることを、前記ルールは規定している。
【0315】
[0235] B3. 解決策B1に記載の方法において、前記複数のスケーリング因子各々の導出方法は、前記クロマCUが複数の変換ユニット(TU)に分割されるかどうかによらず、ルマの再構築されたサンプルの同じセットに基づいていることを、前記ルールは規定している。
【0316】
[0236] B4. 解決策B1に記載の方法において、前記複数のスケーリング因子各々の導出方法は、前記クロマCUに対応するルマCUの部分ではないルマの再構築されたサンプルの同じセットに基づいていることを、前記ルールは規定している。
【0317】
[0237] B5. ビデオ処理方法であって、
クロマ・コーディング・ユニット(CU)を含む現在のブロックに関し、ビデオの前記現在のブロックと前記ビデオのビットストリーム表現との間の変換をルールに従って実行するステップを含み、前記ルールは、前記クロマCUが複数の変換ユニット(TU)に分割される場合に、クロマ残差スケーリング処理がイネーブルにされるかどうかを規定している。
【0318】
[0238] B6. 解決策B5に記載の方法において、前記ルールは、前記クロマ残差スケーリング処理が、複数のTUのサブセットに適用されることを規定している。
【0319】
[0239] B7. 解決策B6に記載の方法において、前記複数のTUのサブセットは、前記クロマCUのトップ・バウンダリにあるTUを含む。
【0320】
[0240] B8. 解決策B5に記載の方法において、前記ルールは、前記クロマ残差スケーリング処理がディセーブルにされることを規定している。
【0321】
[0241] B9. 解決策B1乃至B8のうちの何れかの方法において、前記ルールは、前記クロマCUのサイズは、最大変換ブロック(TB)のサイズより大きいことを更に規定している。
【0322】
[0242] B10. 解決策B1乃至B9のうちの何れかの方法において、前記ルールの適法の指示は、前記ビットストリーム表現でシグナリングされる。
【0323】
[0243] B11. 解決策B10に記載の方法において、前記指示は、タイル・レベル、ブリック・レベル、スライス・レベル、ピクチャ・レベル、サブ・ピクチャ・レベル、シーケンス・レベル、又はビュー・レベルでシグナリングされる。
【0324】
[0244] B12. 解決策B10に記載の方法において、前記指示は、シーケンス・パラメータ・セット(SPS)、ビュー・パラメータ・セット、適応パラメータ・セット(APS)、ピクチャ・パラメータ・セット(PPS)、ピクチャ・ヘッダ、又はスライス・ヘッダでシグナリングされる。
【0325】
[0245] B13. 解決策B1乃至B9のうちの何れかの方法において、前記ルールの適用は、前記ビットストリーム表現における1つ以上のシンタックス要素に基づいている。
【0326】
[0246] B14. 解決策B13に記載の方法において、前記ルールの適用は、クロマ残差のジョイント・コーディング(JCCR)処理がイネーブルにされるかどうかに基づいており、前記1つ以上のシンタックス要素はsps_joint_cbcr_enabled_flagを含む。
【0327】
[0247] B15. 解決策B13に記載の方法において、前記ルールの適用は、前記ビデオの双方のクロマ成分の同等位置の残差サンプルが、反転した符号を有するかどうかに基づいており、前記1つ以上のシンタックス要素はslice_joint_cbcr_sign_flagを含む。
【0328】
[0248] B16. 解決策B13に記載の方法において、前記ルールの適用は、前記現在のブロックがインター・モードでコーディングされるかどうかに基づいている。
【0329】
[0249] B17. 解決策B1乃至B9のうちの何れかの方法において、前記ルールの適用は、前記現在のブロック又は隣接するブロックのコーディング情報に基づいている。
【0330】
[0250] B18. 解決策B17に記載の方法において、前記コーディング情報は、ブロック寸法、スライス・タイプ、ピクチャ・タイプ、テンポラル・レイヤ・インデックス、ビデオの内容、ビデオのカラー成分、現在のブロックのパーティショニング・ツリー・タイプ、コーディング・モード、又は変換情報のうちの少なくとも1つを含む。
【0331】
[0251] B19. 解決策B17又はB18に記載の方法において、前記ルールは、前記現在のブロックの幅がT1以下であるか、又は前記現在のブロックの高さがT2以下である場合に適用され、T1及びT2は整数閾値である。
【0332】
[0252] B20. 解決策B17又はB18に記載の方法において、前記ルールは、前記現在のブロックの幅と前記現在のブロックの高さの積がT3以下である場合に適用され、T3は整数閾値である。
【0333】
[0253] B21. 解決策B17又はB18に記載の方法において、前記ルールの適用は、前記現在のブロックが、Kに等しいクロマ残差のジョイント・コーディング(JCCR)モードでコーディングされるかどうかに基づいており、Kは整数である。
【0334】
[0254] B22. 解決策B21に記載の方法において、K=2である。
【0335】
[0255] B23. 解決策B21に記載の方法において、K≠2である。
【0336】
[0256] B24. 解決策B1乃至B23のうちの何れかの方法において、前記変換を実行するステップは、前記ビットストリーム表現を、前記現在のブロックから生成するステップを含む。
【0337】
[0257] B25. 解決策B1乃至B23のうちの何れかの方法において、前記変換を実行するステップは、前記現在のブロックを、前記ビットストリーム表現から生成するステップを含む。
【0338】
[0258] B26. プロセッサと命令を有する非一時的なメモリとを含むビデオ・システムにおける装置であって、前記命令は、前記プロセッサにより実行されると、解決策B1乃至B25のうちの1つ以上に記載されている方法を前記プロセッサに実行させる。
【0339】
[0259] B27. 非一時的なコンピュータ読み取り可能な媒体に記憶されたコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、解決策B1乃至B25のうちの1つ以上に記載されている方法を実行するためのプログラム・コードを含む。
【0340】
[0260] B28. 解決策B1乃至B25のうちの1つ以上に記載されている方法に従って生成されるビットストリーム表現を記憶するコンピュータ読み取り可能な媒体。
【0341】
[0261] 上記の技術的解決策において、変換を実行するステップは、変換結果に到達するために、(例えば、特定の符号化又は復号化ステップを使用して、又は使用せずに)符号化又は復号化の間に先行する決定ステップの結果を使用することを含む。上述の解決策では、ビデオ処理は、ビデオ・コーディング、符号化、圧縮、トランスコーディング(あるフォーマット又はビットレートから別のフォーマット又はビットレートへの変更)、復号化又は解凍を含むことが可能である。更に、これらの解決策は、画像のような他の視覚的データに適用されてもよい。
【0342】
[0262] 本明細書で説明された、開示された及びその他の解決策、具体例、実施形態、モジュール、及び機能的動作は、本件明細書で開示される構造及びそれらの構造的均等物を含む、デジタル電子回路、又はコンピュータ・ソフトウェア、ファームウェア、又はハードウェア、又はそれらの1つ以上の組み合わせにおいて実現することができる。開示された及びその他の実施形態は、1つ以上のコンピュータ・プログラム製品として、即ち、データ処理装置による実行のための、又はその動作を制御するための、コンピュータ読み取り可能な媒体上でエンコードされているコンピュータ・プログラム命令の1つ以上のモジュールとして、実装することができる。コンピュータ読み取り可能な媒体は、機械読み取り可能なストレージ・デバイス、機械読み取り可能なストレージ基板、メモリ・デバイス、機械読み取り可能な伝搬信号に影響を及ぼす物質の組成、又はそれらの1つ以上の組み合わせであるとすることが可能である。用語“データ処理装置”は、例えば、プログラマブル・プロセッサ、コンピュータ、又は複数のプロセッサ又はコンピュータを含む、データを処理するための全ての装置、デバイス、及び機械を包含する。装置は、ハードウェアに加えて、問題としているコンピュータ・プログラムの実行環境を生成するコード、例えば、プロセッサ・ファームウェア、プロトコル・スタック、データベース管理システム、オペレーティング・システム、又はそれらの1つ以上の組み合わせを構成するコードを含むことができる。伝搬する信号は、人工的に生成された信号、例えば、適切な受信装置への送信のために情報を符号化するために生成される、マシンにより生成された電気信号、光学信号、又は電磁信号である。
【0343】
[0263] コンピュータ・プログラム(プログラム、ソフトウェア、ソフトウェア・アプリケーション、スクリプト、コードとしても知られている)は、コンパイル又は解釈された言語を含む、任意の形式のプログラミング言語で書くことが可能であり、それは、スタンド・アロン・プログラムとして、又はモジュール、コンポーネント、サブルーチン、又はコンピューティング環境での使用に適したその他のユニットとして、任意の形式で配備することができる。コンピュータ・プログラムは、必ずしもファイル・システム内のファイルに対応するとは限らない。プログラムは、他のプログラム又はデータを保持するファイルの一部分(例えば、マークアップ言語文書に記憶される1つ以上のスクリプト)内に、問題としているプログラム専用の単一ファイル内に、又は複数の調整されたファイル(例えば、1つ以上のモジュール、サブ・プログラム、又はコードの一部分を記憶するファイル)内に、保存されることが可能である。コンピュータ・プログラムは、1つのコンピュータ上で又は複数のコンピュータ上で実行されるように配備することが可能であり、複数のコンピュータは、1つのサイトに配置されるか、又は複数のサイトにわたって分散されて通信ネットワークによって相互接続されている。
【0344】
[0264] 本件明細書で説明されるプロセス及びロジックの流れは、1つ以上のコンピュータ・プログラムを実行する1つ以上のプログラマブル・プロセッサによって実行され、入力データに作用して出力を生成することによって機能を実行することができる。プロセス及びロジックの流れはまた、例えばFPGA(フィールド・プログラマブル・ゲート・アレイ)又はASIC(特定用途向け集積回路)のような特殊目的論理回路によって実行されることが可能であり、また、それらとして装置を実装することも可能である。
【0345】
[0265] コンピュータ・プログラムの実行に適したプロセッサは、例えば、汎用及び専用双方のマイクロプロセッサ、及び任意の種類のデジタル・コンピュータの任意の1つ以上のプロセッサを含む。一般に、プロセッサは、リード・オンリ・メモリ又はランダム・アクセス・メモリ又は双方から命令及びデータを受信するであろう。コンピュータの本質的な要素は、命令を実行するためのプロセッサと、命令及びデータを記憶するための1つ以上のメモリ・デバイスである。一般に、コンピュータはまた、データを記憶するための1つ以上の大容量ストレージ・デバイス、例えば磁気的なもの、磁気光ディスク、又は光ディスクを含み、あるいはそれらからデータを受信したり、それらへデータを転送したり、若しくは双方のために動作可能に結合される。しかしながら、コンピュータがそのようなデバイスを有することは必須ではない。コンピュータ・プログラム命令及びデータを記憶するのに適したコンピュータ読み取り可能な媒体は、例えば、EPROM、EEPROM、及びフラッシュ・メモリ・デバイスのような半導体メモリ・デバイス;磁気ディスク、例えば内部ハード・ディスク又はリムーバブル・ディスク;光磁気ディスク;並びにCD ROM及びDVD-ROMディスク;を含む、あらゆる形態の不揮発性メモリ、媒体及びメモリ・デバイスを含む。プロセッサ及びメモリは、特殊目的論理回路によって補足されるか、又はそこに内蔵されることが可能である。
【0346】
[0266] 本件明細書は多くの詳細を含んでいるが、これらは、何れかの対象事項やクレームされ得るものの範囲に関する限定として解釈されるべきではなく、むしろ特定の技術の特定の実施形態に特有である可能性がある特徴の説明として解釈されるべきである。別々の実施形態の文脈で本件明細書で説明される特定の特徴は、組み合わせて単一の実施形態で実施することも可能である。逆に、単一の実施形態の文脈で説明されている種々の特徴は、複数の実施形態において別々に、又は任意の適切なサブコンビネーションで実施することも可能である。更に、特徴が、特定の組み合わせにおいて作用するものとして上述されていたり、当初にそのようにクレームされていたりさえするかもしれないが、クレームされた組み合わせからの1つ以上の特徴は、場合によっては、組み合わせから切り出されることが可能であり、クレームされた組み合わせは、サブコンビネーション又はサブコンビネーションの変形例に仕向けられる可能性がある。
【0347】
[0267] 同様に、図中、動作は特定の順序で記述されているが、これは、所望の結果を達成するために、このような動作が図示の特定の順序で又は順番通りに実行されること、又は、例示された全ての動作が実行されること、を要求するものとして理解されるべきではない。更に、この特許文献で説明される実施形態における種々のシステム構成要素の分け方は、全ての実施形態でこのような分け方を要求とするものとして理解されるべきではない。
【0348】
[0268] 僅かな実装例及び実施例のみが記述されているに過ぎず、本件明細書で説明され図示されているものに基づいて他の実装、拡張及び変更を行うことができる。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26