(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-27
(45)【発行日】2024-10-07
(54)【発明の名称】イントラ・サブ・パーティション・コーディング・モードのための方法及び装置
(51)【国際特許分類】
H04N 19/119 20140101AFI20240930BHJP
H04N 19/70 20140101ALI20240930BHJP
【FI】
H04N19/119
H04N19/70
【外国語出願】
(21)【出願番号】P 2023170524
(22)【出願日】2023-09-29
(62)【分割の表示】P 2021552577の分割
【原出願日】2020-03-05
【審査請求日】2023-10-20
(32)【優先日】2019-03-05
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2019-04-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】HUAWEI TECHNOLOGIES CO.,LTD.
【住所又は居所原語表記】Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129, P.R. China
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】チェルニャーク,ローマン・イゴレヴィチ
(72)【発明者】
【氏名】ソロビヨフ,ティモフェイ・ミハイロヴィチ
(72)【発明者】
【氏名】ジャオ,イン
(72)【発明者】
【氏名】イコニン,セルゲイ ユリエヴィチ
(72)【発明者】
【氏名】チェン,ジェンレェ
【審査官】田中 純一
(56)【参考文献】
【文献】特表2021-513755(JP,A)
【文献】米国特許出願公開第2020/0260070(US,A1)
【文献】特開2011-109397(JP,A)
【文献】米国特許出願公開第2014/0092965(US,A1)
【文献】Benjamin Bross, et al.,Versatile Video Coding (Draft 4),Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 13th Meeting: Marrakech, MA, 9-18 Jan. 2019,JVET-M1001-v3,ITU-T インターネット<URL:https://jvet-experts.org/doc_end_user/documents/14_Geneva/wg11/JVET-M1001-v3.zip><JVET-M1001-v3.docx>,2019年02月19日,pp.14-16,33-48,71-73,108-113,170-182
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00 - 19/98
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
復号化装置によって実行されるコーディングの方法であって:
ビットストリームを受信するステップであって、前記ビットストリームはフラグを含み、前記フラグはモード・フラグ又は分割フラグのうちの少なくとも1つを含み、前記モード・フラグは、コーディング・ユニットが矩形の変換ブロック・サブパーティションにパーティション化されるかどうかを示し、前記分割フラグは、イントラ・サブ・パーティション(ISP)の分割タイプが水平であるか又は垂直であるかを示す、ステップと;
前記フラグに基づいてISPの情報を取得するステップであって、前記ISPの情報は、前記コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示す、ステップと;
少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいて前記コーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するステップであって、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数であり、前記クロマ・フォーマット情報は、前記コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、前記クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含み、及び前記第1条件は:1)前記コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)前記ISPの情報が、前記ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む、ステップと;
を含む方法。
【請求項2】
前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックのサイズにも依存する、請求項1に記載の方法。
【請求項3】
前記クロマ変換ブロックの前記サイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
を満たし、wCは前記クロマ変換ブロックの幅を表し、hCは前記クロマ変換ブロックの高さを表し、CbWidthは前記ルマ・コーディング・ブロックの幅を表し、CbHeightは前記ルマ・コーディング・ブロックの高さを表す、請求項2に記載の方法。
【請求項4】
前記モード・フラグはintra_subpartitions_mode_flagであり;
1に等しいintra_subpartitions_mode_flagは、現在のイントラ・コーディング・ユニットが、NumIntraSubPartitions個の矩形の変換ブロック・サブパーティションにパーティション化されることを示し;
0に等しいintra_subpartitions_mode_flagは、前記現在のイントラ・コーディング・ユニットが、矩形の変換ブロック・サブパーティションにパーティション化されないことを示し;
intra_subpartitions_mode_flagは、存在しない場合、0に等しいと推定される、請求項1に記載の方法。
【請求項5】
前記分割フラグはintra_subpartitions_split_flagであり;
intra_subpartitions_split_flagが存在しないならば:
cbHeightがMaxTbSizeYより大きい場合には、intra_subpartitions_split_flagは0に等しいと推定され;
それ以外の場合(cbWidthがMaxTbSizeYより大きい場合)には、intra_subpartitions_split_flagは1に等しいと推定される、請求項1に記載の方法。
【請求項6】
前記クロマ変換ブロックのサイズは、以下のルール:
前記クロマ・フォーマットが4:4:4に等しい場合には、前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックの前記サイズに等しく;
それ以外の場合には、前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックの前記サイズと前記クロマ・フォーマットの関数として決定されること;
に従って決定される、請求項2に記載の方法。
【請求項7】
前記ISPの情報は、IntraSubPartitionsSplitTypeにより示され;及び
IntraSubPartitionsSplitType != ISP_NO_SPLITである場合に、前記コーディング・ユニットの前記ルマ・コーディング・ブロックを分割するためにISPが使用される、請求項1に記載の方法。
【請求項8】
イントラ・サブ・パーティション(ISP)のための符号化装置であって:
1つ以上のプロセッサと;
前記1つ以上のプロセッサに結合され、命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体と;
を含み、前記命令は、前記1つ以上のプロセッサにより実行されると、前記1つ以上のプロセッサに:
少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するステップであって、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数であり、前記クロマ・フォーマット情報は、前記コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、前記クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含み、及び前記第1条件は:1)前記コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)前記コーディング・ユニットのルマ・コーディング・ブロックを分割するためにイントラ・サブ・パーティション(ISP)が使用されることを含む、ステップと;
ビットストリームを符号化するステップであって、前記ビットストリームはフラグの値を含み、前記フラグはモード・フラグ又は分割フラグのうちの少なくとも1つを含み、前記モード・フラグは、前記コーディング・ユニットが矩形の変換ブロック・サブパーティションにパーティション化されるかどうかを示し、前記分割フラグは、ISPの分割タイプが水平であるか又は垂直であるかを示す、ステップと;
を実行させる、装置。
【請求項9】
前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックのサイズにも依存する、請求項8に記載の装置。
【請求項10】
前記クロマ変換ブロックの前記サイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
に従って決定され、wCは前記クロマ変換ブロックの幅を表し、hCは前記クロマ変換ブロックの高さを表し、CbWidthは前記ルマ・コーディング・ブロックの幅を表し、CbHeightは前記ルマ・コーディング・ブロックの高さを表す、請求項8に記載の装置。
【請求項11】
前記モード・フラグはintra_subpartitions_mode_flagであり;
1に等しいintra_subpartitions_mode_flagは、現在のイントラ・コーディング・ユニットが、NumIntraSubPartitions個の矩形の変換ブロック・サブパーティションにパーティション化されることを示し;
0に等しいintra_subpartitions_mode_flagは、前記現在のイントラ・コーディング・ユニットが、矩形の変換ブロック・サブパーティションにパーティション化されないことを示し;
intra_subpartitions_mode_flagは、存在しない場合、0に等しいと推定される、請求項8に記載の装置。
【請求項12】
前記分割フラグはintra_subpartitions_split_flagであり;
intra_subpartitions_split_flagが存在しないならば:
cbHeightがMaxTbSizeYより大きい場合には、intra_subpartitions_split_flagは0に等しいと推定され;
それ以外の場合(cbWidthがMaxTbSizeYより大きい場合)には、intra_subpartitions_split_flagは1に等しいと推定される、請求項8に記載の装置。
【請求項13】
前記クロマ変換ブロックのサイズは、以下のルール:
前記クロマ・フォーマットが4:4:4に等しい場合には、前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックの前記サイズに等しく;
それ以外の場合には、前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックの前記サイズと前記クロマ・フォーマットの関数として決定されること;
に従って決定される、請求項9に記載の装置。
【請求項14】
前記ISPの情報は、IntraSubPartitionsSplitTypeにより示され;及び
IntraSubPartitionsSplitType != ISP_NO_SPLITである場合に、前記コーディング・ユニットの前記ルマ・コーディング・ブロックを分割するためにISPが使用される、請求項8に記載の装置。
【請求項15】
命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、処理回路により実行されると、前記処理回路に:
ビットストリーム内のフラグに基づいてイントラ・サブ・パーティション(ISP)の情報を取得するステップであって、前記フラグはモード・フラグ又は分割フラグのうちの少なくとも1つを含み、前記モード・フラグは、コーディング・ユニットが矩形の変換ブロック・サブパーティションにパーティション化されるかどうかを示し、前記分割フラグは、イントラ・サブ・パーティション(ISP)の分割タイプが水平であるか又は垂直であるかを示し、前記ISPの情報は、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示す、ステップと;
少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいて前記コーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するステップであって、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数であり、前記クロマ・フォーマット情報は、前記コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、前記クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含み、及び前記第1条件は:1)前記コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)前記ISPの情報が、前記ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む、ステップと;
を実行させる、記憶媒体。
【請求項16】
前記クロマ変換ブロックの前記サイズは前記ルマ・コーディング・ブロックのサイズにも依存する、請求項15に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項17】
前記クロマ変換ブロックの前記サイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
を満たし、wCは前記クロマ変換ブロックの幅を表し、hCは前記クロマ変換ブロックの高さを表し、CbWidthは前記ルマ・コーディング・ブロックの幅を表し、CbHeightは前記ルマ・コーディング・ブロックの高さを表す、請求項16に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項18】
前記モード・フラグはintra_subpartitions_mode_flagであり;
1に等しいintra_subpartitions_mode_flagは、現在のイントラ・コーディング・ユニットが、NumIntraSubPartitions個の矩形の変換ブロック・サブパーティションにパーティション化されることを示し;
0に等しいintra_subpartitions_mode_flagは、前記現在のイントラ・コーディング・ユニットが、矩形の変換ブロック・サブパーティションにパーティション化されないことを示し;
intra_subpartitions_mode_flagは、存在しない場合、0に等しいと推定される、請求項15に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項19】
前記分割フラグはintra_subpartitions_split_flagであり;
intra_subpartitions_split_flagが存在しないならば:
cbHeightがMaxTbSizeYより大きい場合には、intra_subpartitions_split_flagは0に等しいと推定され;
それ以外の場合(cbWidthがMaxTbSizeYより大きい場合)には、intra_subpartitions_split_flagは1に等しいと推定される、請求項15に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項20】
前記ISPの情報は、IntraSubPartitionsSplitTypeにより示され;及び
IntraSubPartitionsSplitType != ISP_NO_SPLITである場合に、前記コーディング・ユニットの前記ルマ・コーディング・ブロックを分割するためにISPが使用される、請求項15に記載の非一時的なコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
(削除)
【0002】
技術分野
本出願(開示)の実施態様は、一般に、ピクチャ処理の分野に関連し、より具体的にはサブ・パーティション(ISP)コーディング・モードに関連する。
【背景技術】
【0003】
ビデオ・コーディング(ビデオ符号化及び復号化)は、幅広いデジタル・ビデオ・アプリケーションにおいて、例えば放送用デジタルTV、インターネットやモバイル・ネットワークを介したビデオ伝送、ビデオ・チャットのようなリアルタイム会話アプリケーション、ビデオ会議、DVD及びブルーレイ・ディスク、ビデオ・コンテンツ捕捉編集システム、及びセキュリティ・アプリケーションのカムコーダにおいて使用される。
【0004】
比較的短いビデオでさえ描写するために必要とされるビデオ・データの量は、相当なものである可能性があり、データが、限られた帯域幅容量を有する通信ネットワークを介してストリーミングされるか又は別の方法で通信される場合には、困難を生じる可能性がある。従って、ビデオ・データは、一般に、今日の電気通信ネットワークを介して通信される前に圧縮される。また、ビデオがストレージ・デバイスに記憶される場合には、メモリ・リソースが制限される可能性があるので、ビデオのサイズも問題となる可能性がある。ビデオ圧縮デバイスは、しばしば、伝送又は記憶の前にビデオ・データをコーディング化するためにソースにおいてソフトウェア及び/又はハードウェアを使用し、それによってデジタル・ビデオ画像を表すのに必要なデータ量を減少させる。次いで、圧縮されたデータは、ビデオ・データを復号化するビデオ非圧縮デバイスによって宛先で受信される。限られたネットワーク・リソース及びより高いビデオ品質の絶え間なく増進する要請により、画像品質にほとんど犠牲を払わずに圧縮率を改善する改良された圧縮及び非圧縮技術が望まれる。
【0005】
イントラ・サブ・パーティション(ISP)コーディング・モードは、ライン・ベース・イントラ予測(LIP)コーディングのアップデートされたバージョンである。ISP技術はルマ・ブロックに対してのみサブ・パーティショニングを実行し、クロマ・ブロックに対しては、予測と更なる変換がパーティショニングなしにコーディング・ユニット全体に対して実行される。ISP用のコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するための正確で汎用的な方法を提供することが目的である。
【発明の概要】
【0006】
本願の実施形態は、独立請求項による符号化及び復号化のための装置及び方法を提供する。
【0007】
上記及び他の目的は、独立請求項の対象事項によって達成される。更なる実装形式は、従属請求項、明細書及び図面から明らかである。
【0008】
第1態様によれば、本発明は復号化装置によって実行される方法に関連する。方法は:イントラ・サブ・パーティション(ISP)の情報を取得するステップであって、ISPの情報は、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示す、ステップと;少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するステップとを含む。SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)ISPの情報が、ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む。
【0009】
第2態様によれば、本発明は符号化装置によって実行される方法に関連する。方法は:少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するステップを含む。SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを含む。方法は、ビットストリームを符号化するステップを更に含み、ビットストリームは、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを示す情報を含む。
【0010】
本発明の第1態様による方法は、本発明の第3態様による復号化装置によって実行することが可能である。装置1100は取得ユニット1101と決定ユニット1102を含む。取得ユニット1101は、ISPの情報を取得するように構成され、ISPの情報は、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示す。決定ユニット1102は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するように構成されており、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)ISPの情報が、ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む。本発明の第3態様による方法の更なる特徴及び実装形式は、本発明の第1態様による装置の特徴及び実装形式に対応する。
【0011】
本発明の第2態様による方法は、本発明の第4態様による符号化装置によって実行されることが可能である。装置1200は決定ユニット1201と符号化ユニット1202を含む。決定ユニット1201は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するように構成される。SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する2つの変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを含む。符号化ユニット1202は、ビットストリームを符号化するように構成されており、ビットストリームは、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを示す情報を含む。
【0012】
本発明の第4態様による方法の更なる特徴及び実装形式は、本発明の第2態様による装置の特徴及び実装形式に対応する。
【0013】
第5態様によれば、本発明は、ビデオ・ストリームを復号化する装置に関連し、プロセッサ及びメモリを含む。メモリは、第1態様による方法をプロセッサに実行させる命令を記憶している。
【0014】
第6態様によれば、本発明は、ビデオ・ストリームを符号化する装置に関連し、プロセッサ及びメモリを含む。メモリは、第2態様による方法をプロセッサに実行させる命令を記憶している。
【0015】
第7態様によれば、実行されると、ビデオ・データをコーディングするように1つ以上のプロセッサが構築されることを引き起こす命令を記憶したコンピュータ読み取り可能な記憶媒体が提案される。命令は、第1態様若しくは第2態様又は第1態様若しくは第2態様の任意の可能な実施形態による方法を、1つ以上のプロセッサに実行させる。
【0016】
第8態様によれば、本発明は、コンピュータ上で実行されると、第1若しくは第2態様又は第1若しくは第2態様の任意の可能な実施形態による方法を実行するためのプログラム・コードを含むコンピュータ・プログラムに関連する。本発明の実施形態は、全てのクロマ・フォーマットに適用される。クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。ISP用のクロマ変換ブロックのサイズを決定するための正確で汎用的な方法が達成される。以下、1つ以上の実施形態の詳細が添付図面及び明細書で説明される。他の特徴、目的、及び利点は、明細書、図面、及び特許請求の範囲から明らかであろう。
【図面の簡単な説明】
【0017】
以下、添付図面及び図を参照しながら本発明の実施形態をより詳細に説明する。
【
図1A】本発明の実施形態を実現するように構成されたビデオ・コーディング・システムの一例を示すブロック図である。
【
図1B】本発明の実施形態を実現するように構成されたビデオ・コーディング・システムの別の例を示すブロック図である。
【
図2】本発明の実施形態を実現するように構成されたビデオ・エンコーダの一例を示すブロック図である。
【
図3】本発明の実施形態を実現するように構成されたビデオ・デコーダの例示的な構造を示すブロック図である。
【
図4】符号化装置又は復号化装置の一例を示すブロック図である。
【
図5】符号化装置又は復号化装置の別の例を示すブロック図である。
【
図6】ピクチャにおける4:2:0ルマ及びクロマ・サンプルの名目上の垂直及び水平位置である。
【
図7】ピクチャにおける4:2:2ルマ及びクロマ・サンプルの名目上の垂直及び水平位置である。
【
図8】ピクチャにおける4:4:4ルマ及びクロマ・サンプルの名目上の垂直及び水平位置である。
【
図9】本発明による復号化装置によって実行されるISPコーディング方法の実施形態を示す。
【
図10】本発明による符号化装置によって実行されるISPコーディング方法の実施形態を示す。
【
図11】本発明による復号化装置の実施形態を例示する。
【
図12】本発明による符号化装置の実施形態を例示する。
【
図13】コンテンツ配信サービスを実現するコンテンツ供給システム3100の構成例を示すブロック図である。
【
図14】端末デバイスの一例の構成を示すブロック図である。
【0018】
以下において、明示的に別意に述べられていなければ、同一の参照符号は同一の又は少なくとも機能的に同等な特徴を指す。
【発明を実施するための形態】
【0019】
以下の説明において、本開示の一部を成し、例示として本発明の実施形態の特定の態様又は本発明の実施形態が使用される可能性のある特定の態様を示す添付図面が参照される。本発明の実施形態は、他の態様で使用される可能性があり、添付図面に示されていない構造的又は論理的な変更を含む可能性があることが理解される。従って、以下の詳細な説明は、限定する意味で解釈するべきではなく、本発明の範囲は、添付の特許請求の範囲によって定められる。
【0020】
例えば、説明される方法に関連する開示は、方法を実行するように構成された対応するデバイス又はシステムにも当てはまる可能性があり、その逆も可能であることが理解される。例えば、1つ以上の特定の方法ステップが説明される場合、対応するデバイスは、説明された1つ以上の方法ステップを実行するための機能ユニットのような1つ以上のユニット(例えば、1つ以上のステップを実行する1つのユニット、又は複数のステップのうちの1つ以上を各々が実行する複数のユニット)を、たとえそのような1つ以上のユニットが図面において明示的に図示も説明もされていなかったとしても、含む可能性がある。一方、例えば、機能ユニットのような1つ以上のユニットに基づいて、特定の装置が説明される場合、対応する方法は、1つ以上のユニットの機能を実行するための1つのステップ(例えば、1つ以上のユニットの機能を実行するための1つのステップ、又は複数のユニットのうちの1つ以上の機能を各々が実行する複数のステップ)を、たとえそのような1つ以上のステップが図面において明示的に図示も説明もされていなかったとしても、含む可能性がある。更に、本願で説明される様々な例示的な実施形態及び/又は態様の特徴は、別意に述べられていない限り、互いに組み合わせられる可能性があることは理解される。
【0021】
ビデオ・コーディングは、典型的には、ビデオ又はビデオ・シーケンスを形成する一連のピクチャの処理を示す。ビデオ・コーディングの分野では、用語「ピクチャ」の代わりに、用語「フレーム」又は「画像」が同義語として使用されてもよい。ビデオ・コーディング(又は、一般的にはコーディング)は、2つの部分、ビデオ符号化又はビデオ復号化を含む。ビデオ符号化は、ソース側で実行され、典型的には、ビデオ・ピクチャを表すのに必要なデータ量を減らすために(より効率的な記憶及び/又は伝送のために)オリジナル・ビデオ・ピクチャを(例えば、圧縮により)処理することを含む。ビデオ復号化は、宛先側で実行され、典型的には、ビデオ・ピクチャを再構成するために、エンコーダと比較して逆の処理を含む。ビデオ・ピクチャ(又は、一般的にはピクチャ)の「コーディング」に対する実施形態は、ビデオ・ピクチャ又は個々のビデオ・シーケンスの「符号化」又は「復号化」に関連するように理解されるものとする。符号化の部分及び復号化の部分の組み合わせはまた、CODEC(Coding and Decoding)と言及される。
【0022】
ロスレス・ビデオ・コーディングの場合、オリジナル・ビデオ・ピクチャを再構成することが可能であり、即ち、再構成されたビデオ・ピクチャはオリジナル・ビデオ・ピクチャと同じ質を有する(記憶及び伝送の間に、伝送ロス又は他のデータ・ロスは無いことを仮定している)。ロスレスでないビデオ・コーディングの場合、ビデオ・ピクチャを表現するデータ量を減らすために、例えば量子化によって更なる圧縮が実行され、ビデオ・ピクチャはデコーダ側で完全には再構成することができず、即ち、再構成されたビデオ・ピクチャの質は、オリジナル・ビデオ・ピクチャの質より低いか又は悪い。
【0023】
幾つかのビデオ・コーディング規格は、「ロスレスでないハイブリッド・ビデオ・コーデックス」のグループに属する(即ち、サンプル・ドメインにおける空間的及び時間的な予測と、変換ドメインにおいて量子化を適用するための2D変換コーディングとを組み合わせる)。ビデオ・シーケンスの各ピクチャは、典型的には、重複しないブロックのセットにパーティション化され、コーディングは、典型的には、ブロック・レベルで実行される。換言すれば、エンコーダ側において、ビデオは、例えば空間(イントラ・ピクチャ)予測及び時間(インター・ピクチャ)予測を用いて予測ブロックを生成すること、現在ブロック(現在の処理済み/処理されるべきブロック)から予測ブロックを減算して残差ブロックを取得すること、残差ブロックを変換すること、変換ドメインにおいて残差ブロックを量子化して、伝送されるべきデータ量を減少させること(圧縮)により、典型的にはブロック(ビデオ・ブロック)レベルで処理され、即ち符号化され、デコーダ側では、エンコーダと比較して逆の処理が、符号化又は圧縮されたブロックに部分的に適用され、表現のために現在ブロックを再構成する。更に、エンコーダは、デコーダの処理ループを繰り返し、その結果、両者は、以後のブロックを処理する、即ちコーディングするために、同じ予測(例えば、イントラ及びインター予測)及び/又は再構成を生じるであろう。
【0024】
以下、ビデオ・コーディング・システム10、ビデオ・エンコーダ20、及びビデオ・デコーダ30の実施形態を、
図1-3に基づいて説明する。
【0025】
図1Aは、例示的なコーディング・システム10、例えば本願の技術を使用することが可能なビデオ・コーディング・システム10(又は略してコーディング・システム10)を示す概略的なブロック図である。ビデオ・コーディング・システム10のビデオ・エンコーダ20(又は略してエンコーダ20)及びビデオ・デコーダ30(又は略してデコーダ30)は、本願で説明される種々の例による技術を実行するように構成される可能性があるデバイスの例を表す。
【0026】
図1Aに示すように、コーディング・システム10は、符号化されたピクチャ・データ21を、例えば符号化されたピクチャ・データ
21を復号化する宛先デバイス14へ提供するように構成されたソース・デバイス12を含む。
【0027】
ソース・デバイス12は、エンコーダ20を含み、追加的に、即ちオプションとして、ピクチャ・ソース16、例えばピクチャ前処理ユニット18のような前処理プロセッサ(又は前処理ユニット)18、及び、通信インターフェース又は通信ユニット22を含む可能性がある。
【0028】
ピクチャ・ソース16は、例えば実世界のピクチャを捕捉するカメラのような任意の種類のピクチャ捕捉デバイス、及び/又は、例えばコンピュータ・アニメーション・ピクチャを生成するコンピュータ・グラフィックス・プロセッサのような任意の種類のピクチャ生成デバイス、又は実世界のピクチャ、コンピュータ生成ピクチャ(例えば、スクリーン・コンテンツ又はバーチャル・リアリティ(VR)ピクチャ)、及び/又はそれらの任意の組み合わせ(例えば、拡張現実(AR)ピクチャ)を取得及び/又は提供する任意の種類の他のデバイスを含んでもよいし、又はそれらであってもよい。ピクチャ・ソースは、上記の任意のピクチャを記憶する任意の種類のメモリ又はストレージである可能性がある。
【0029】
前処理ユニット18及び前処理ユニット18により実行される処理と区別して、ピクチャ及びピクチャ・データ17はまた、未処理ピクチャ又は未処理ピクチャ・データ17と呼ばれてもよい。
【0030】
前処理ユニット18は、(未処理)ピクチャ・データ17を受信し、ピクチャ・データ17に関して前処理を実行して、前処理されたピクチャ19又は前処理されたピクチャ・データ19を取得するように構成されている。前処理ユニット18によって実行される前処理は、例えば、トリミング、カラー・フォーマット変換(例えば、RGBからYCbCrへ)、色補正、又はノイズ低減を含む可能性がある。前処理ユニット18はオプションの構成要素であってもよいことを理解することが可能である。
【0031】
ビデオ・エンコーダ20は、前処理されたピクチャ・データ19を受信し、符号化ピクチャ・データ21を提供するように構成される(更なる詳細は、例えば以下において
図2に基づいて説明されるであろう)。
ソース・デバイス12の通信インターフェース22は、符号化されたピクチャ・データ21を受信し、符号化されたピクチャ・データ21(又はそれを更に処理した任意のバージョン)を通信チャネル13を介して他のデバイスへ、例えば宛先デバイス14又は任意の他のデバイスへ、記憶又は直接的な再構成のために送信するように構成されることが可能である。
【0032】
宛先デバイス14は、デコーダ30(例えば、ビデオ・デコーダ30)を含み、追加的に、即ちオプションとして、通信インターフェース又は通信ユニット28、後処理プロセッサ32(又は後処理ユニット32)、及び表示デバイス34を含む可能性がある。
【0033】
宛先デバイス14の通信インターフェース28は、符号化されたピクチャ・データ21(又はそれらを更に処理した任意のバージョン)を、例えばソース・デバイス12から直接的に、又は任意の他のソースから、例えばソース・デバイスから、例えば符号化されたピクチャ・データのストレージ・デバイスから受信し、符号化されたピクチャ・データ21をデコーダ30に提供するように構成される。
【0034】
通信インターフェース22及び通信インターフェース28は、ソース・デバイス12と宛先デバイス14との間の直接的な通信リンク、例えば直接的な有線又は無線接続を介して、又は任意の種類のネットワーク、例えば有線若しくは無線ネットワーク又はそれらの任意の組み合わせ、又は任意の種類の私的な及び公的なネットワーク、又はそれらの任意の組み合わせを介して、符号化されたピクチャ・データ21又は符号化されたデータを送信又は受信するように構成されることが可能である。
【0035】
通信インターフェース22は、例えば、符号化されたピクチャ・データ21を、例えばパケットのような適切なフォーマットにパッケージ化し、及び/又は、通信リンク又は通信ネットワークを介する伝送のための任意の種類の伝送符号化又は処理を使用して、符号化されたピクチャ・データを処理するように構成されることが可能である。
【0036】
通信インターフェース22の対応部分を形成する通信インターフェース28は、例えば、送信されたデータを受信し、符号化されたピクチャ・データ21を取得するために任意の種類の対応する伝送復号化又は処理及び/又は非パッケージ化を使用して、送信データを処理するように構成されることが可能である。
【0037】
通信インターフェース22及び通信インターフェース28の両方は、
図1Aにおいてソース・デバイス12から宛先デバイス14へ向かう通信チャネル13に関する矢印により示される一方向通信インターフェース、又は双方向通信インターフェースとして構成されることが可能であり、例えばメッセージを送信及び受信するように、例えば接続をセットアップするように、通信リンク及び/又はデータ伝送、例えば符号化されたピクチャ・データ伝送に関連する他の任意の情報を確認及び交換するように、構成されることが可能である。
【0038】
デコーダ30は、符号化されたピクチャ・データ21を受信し、復号化されたピクチャ・データ31又は復号化されたピクチャ31を提供するように構成される(更なる詳細は、例えば
図3又は
図5に基づいて、以下において説明されるであろう)。
【0039】
宛先デバイス14の後処理プロセッサ32は、例えば復号化されたピクチャ31のような復号化されたピクチャ・データ31(再構成されたピクチャ・データとも呼ばれる)を後処理して、後処理されたピクチャ33のような後処理ピクチャ・データ33を取得するように構成される。後処理ユニット32によって実行される後処理は、例えばカラー・フォーマット変換(例えば、YCbCrからRGBへ)、色補正、トリミング、リサンプリング、又は他の任意の処理、例えば表示デバイス34による表示のための例えば復号化されたピクチャ・データ31を準備するためのもの等を含む可能性がある。
【0040】
宛先デバイス14の表示デバイス34は、後処理ピクチャ・データ33を受信して、ピクチャを、例えばユーザー又はビューアに表示するように構成されている。表示デバイス34は、再構成されたピクチャを表現する任意の種類のディスプレイ、例えば一体化された又は外部のディスプレイ又はモニタであってもよいし、又はそれらを含んでもよい。ディスプレイは、例えば、液晶ディスプレイ(LCD)、有機発光ダイオード(OLED)ディスプレイ、プラズマ・ディスプレイ、プロジェクタ、マイクロLEDディスプレイ、液晶オン・シリコン(LCoS)、デジタル光プロセッサ(DLP)、又は任意の他の種類のディスプレイを含む可能性がある。
【0041】
図1Aは、ソース・デバイス12と宛先デバイス14とを別々のデバイスとして描いているが、デバイスの実施形態はまた、双方又は双方の機能、ソース・デバイス12又は対応する機能と宛先デバイス14又は対応する機能とを含む可能性がある。そのような実施形態では、ソース・デバイス12又は対応する機能と宛先デバイス14又は対応する機能とは、同じハードウェア及び/又はソフトウェアを使用して、又は別個のハードウェア及び/又はソフトウェア、又はそれらの任意の組み合わせにより実現されてもよい。
【0042】
明細書に基づいて当業者には明らかであるように、
図1Aに示すソース・デバイス12及び/又は宛先デバイス14における機能又は様々なユニットの機能の存在及び(厳密な)分割は、実際のデバイス及び用途に応じて異なる可能性がある。
【0043】
エンコーダ20(例えば、ビデオ・エンコーダ20)又はデコーダ30(例えば、ビデオ・デコーダ30)又はエンコーダ20及びデコーダ30の双方は、
図1Bに示されるような処理回路により、例えば、1つ以上のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールド・プログラマブル・ゲート・アレイ(FPGA)、ディスクリート・ロジック、ハードウェア、ビデオ・コーディング専用又はそれらの任意の組み合わせにより、実現されることが可能である。エンコーダ20は、
図2のエンコーダ20及び/又は本願で説明される他の任意のエンコーダ・システム又はサブシステムに関して説明される様々なモジュールを具現化するために、処理回路46により実施されてもよい。デコーダ30は、
図3のデコーダ30及び/又は本願で説明される他の任意のデコーダ・システム又はサブシステムに関して説明される様々なモジュールを具現化するために、処理回路46により実施されてもよい。処理回路は、後述するように様々な動作を実行するように構成されることが可能である。
図5に示すように、技術が部分的にソフトウェアで実現される場合、デバイスは、適切な非一時的なコンピュータ読み取り可能な記憶媒体にソフトウェアの命令を記憶し、本開示の技術を実行するために1つ以上のプロセッサを使用するハードウェアで命令を実行することができる。ビデオ・エンコーダ20とビデオ・デコーダ30の何れかは、例えば
図1Bに示すように、単一のデバイス内の組み合わされたエンコーダ/デコーダ(CODEC)の一部として統合されてもよい。
【0044】
ソース・デバイス12及び宛先デバイス14は、任意の種類のハンドヘルド又はステーショナリ・デバイスを含む広範囲に及ぶ任意のデバイス、例えば、ノートブック又はラップトップ・コンピュータ、携帯電話、スマートフォン、タブレット又はタブレット・コンピュータ、カメラ、デスクトップ・コンピュータ、セット・トップ・ボックス、テレビ、表示デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイス(コンテンツ・サービス・サーバー又はコンテンツ配信サーバー等)、放送受信デバイス、放送送信デバイス等を含む可能性があり、任意の種類のオペレーティング・システムを使用してもよいし、又は使用しなくてもよい。場合によっては、ソース・デバイス12及び宛先デバイス14は無線通信用に装備されてもよい。従って、ソース・デバイス12及び宛先デバイス14は、無線通信デバイスであってもよい。
【0045】
場合によっては、
図1Aに示すビデオ・コーディング・システム10は単なる一例に過ぎず、本願の技術は、符号化デバイスと復号化デバイスとの間で何らかのデータ通信を必ずしも含む必要のないビデオ・コーディング設定(例えば、ビデオ符号化又はビデオ復号化)に適用される可能性がある。他の例において、データは、ローカル・メモリから検索され、ネットワークを介してストリーミング等される。ビデオ符号化デバイスは、データを符号化してメモリに格納することが可能であり、及び/又はビデオ復号化デバイスは、データをメモリから検索して復号化することが可能である。幾つかの例では、符号化及び復号化は、互いに通信しないが、メモリへのデータを符号化し及び/又はメモリからデータを検索して復号化するだけのデバイスによって実行される。
【0046】
説明の便宜上、本発明の実施形態は、例えば高効率ビデオ・コーディング(HEVC)又は汎用ビデオ・コーディング(VVC)、ITU-Tビデオ・コーディング・エキスパート・グループ(VCEG)及びISO/IEC動画エキスパート・グループ(MPEG)のビデオ・コーディングに関する共同研究チーム(JCT-VC)によって開発された次世代ビデオ・コーディング規格の参照ソフトウェアを参照することによって本願で説明される。当業者は、本発明の実施形態がHEVC又はVVCに限定されないことを理解するであろう。
【0047】
エンコーダ及び符号化方法
図2は、本願の技術を実現するように構成された例示的なビデオ・エンコーダ20の概略的なブロック図である。
図2の例では、ビデオ・エンコーダ20は、入力102(又は入力インターフェース201)と、残差計算ユニット204と、変換処理ユニット206と、量子化ユニット208と、逆量子化ユニット210と、逆変換処理ユニット212と、再構成ユニット214と、ループ・フィルタ・ユニット220と、復号化されたピクチャのバッファ(DPB)230と、モード選択ユニット260と、エントロピー符号化ユニット270と、出力272(又は出力インターフェース272)とを含む。モード選択ユニット260は、インター予測ユニット244と、イントラ予測ユニット254と、パーティショニング・ユニット262とを含むことが可能である。インター予測ユニット244は、動き推定ユニットと、動き補償ユニット(不図示)とを含むことが可能である。
図2に示すビデオ・エンコーダ20はまた、ハイブリッド・ビデオ・エンコーダ又はハイブリッド・ビデオ・コーデックによるビデオ・エンコーダと言及されてもよい。
【0048】
残差計算ユニット204、変換処理ユニット206、量子化ユニット208、モード選択ユニット260は、エンコーダ20の順方向信号経路を形成するように言及される場合があり、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、バッファ216、ループ・フィルタ220、復号化されたピクチャのバッファ(DPB)230、インター予測ユニット244、及びイントラ予測ユニット254は、ビデオ・エンコーダ20の逆方向信号経路を形成するように言及される場合があり、ビデオ・エンコーダ20の逆方向信号経路は、デコーダの信号経路に対応する(
図3のビデオ・デコーダ30を参照されたい)。また、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ220、復号化されたピクチャのバッファ(DPB)230、インター予測ユニット244、及びイントラ予測ユニット254は、ビデオ・エンコーダ20の「内蔵デコーダ」を形成しているようにも言及される。
【0049】
ピクチャ&ピクチャ・パーティショニング(ピクチャ&ブロック)
エンコーダ20は、例えば入力202を介して、ピクチャ17(又はピクチャ・データ17)、例えばビデオ又はビデオ・シーケンスを形成するピクチャのシーケンスのピクチャを受信するように構成されてもよい。受信されるピクチャ又はピクチャ・データはまた、前処理されたピクチャ19(又は前処理されたピクチャ・データ19)と言及される場合もある。簡略化のため、以下の説明はピクチャ17と言及する。ピクチャ17はまた、現在ピクチャ又はコーディングされるべきピクチャと言及される場合もある(特に、ビデオ・コーディングにおいて、現在のピクチャを他のピクチャから、例えば同じビデオ・シーケンス、即ち現在のピクチャも含むビデオ・シーケンスの以前に符号化された及び/又は復号化されたピクチャから区別する)。
【0050】
(デジタル)ピクチャは、強度値を有するサンプルの2次元アレイ又はマトリクスであるか、又はそのように考えることが可能である。アレイ中のサンプルはまた、ピクセル(ピクチャ要素の短縮形)又はペルと言及される場合がある。アレイ又はピクチャの水平及び垂直方向(又は軸)におけるサンプルの数は、ピクチャのサイズ及び/又は解像度を規定する。色の表現には、典型的には、3つの色成分が使用され、即ち、ピクチャは、3つのサンプル・アレイで表現されてもよいし、又はそれを含んでもよい。RGBフォーマット又は色空間において、ピクチャは対応する赤、緑、及び青のサンプル・アレイを含む。しかしながら、ビデオ・コーディングにおいては、各サンプルは、典型的には、ルミナンス/クロミナンス・フォーマット又は色空間、例えばYCbCrで表現され、YCbCrは、Yで示されるルミナンス成分(時にはそれに代えてLも使用される)とCb及びCrで示される2つのクロミナンス成分とを含む。ルミナンス(又は略称、ルマ)成分Yは、輝度又はグレー・レベル強度を(例えば、グレー・スケール・ピクチャでのように)表し、2つのクロミナンス(又は略称、クロマ)成分Cb及びCrはクロミナンス又は色情報成分を表す。従って、YCbCrフォーマットにおけるピクチャは、ルミナンス・サンプル値(Y)のルミナンス・サンプル・アレイと、クロミナンス値(Cb及びCr)の2つのクロミナンス・サンプル・アレイとを含む。RGBフォーマットのピクチャは、YCbCrフォーマットにコンバート又は変換されることが可能であり、その逆も可能であり、そのプロセスは色変換又はコンバージョンとしても知られている。ピクチャがモノクロである場合、ピクチャはルミナンス・サンプル・アレイのみを含む可能性がある。従って、ピクチャは、例えば、モノクロ・フォーマットにおけるルマ・サンプルのアレイ、又はルマ・サンプルのアレイとクロマ・サンプルの2つの対応するアレイとの4:2:0、4:2:2、及び4:4:4カラー・フォーマットにおけるものあってもよい。
【0051】
ビデオ・エンコーダ20の実施形態は、ピクチャ17を、複数の(典型的には重複しない)ピクチャ・ブロック203にパーティション化するように構成されたピクチャ・パーティショニング・ユニット(
図2には示されていない)を含むことが可能である。これらのブロックはまた、ルート・ブロック、マクロ・ブロック(H.264/AVC)又はコーディング・ツリー・ブロック(CTB)又はコーディング・ツリー・ユニット(CTU)(H.265/HEVC及びVVC)と言及される場合もある。ピクチャ・パーティショニング・ユニットは、ビデオ・シーケンスの全てのピクチャに対して同一のブロック・サイズとブロック・サイズを規定する対応するグリッドとを使用するように、又は、ピクチャ、サブセット、又はピクチャのグループ間でブロック・サイズを変更し、各ピクチャを対応するブロックにパーティション化するように構成されることが可能である。
【0052】
更なる実施形態では、ビデオ・エンコーダは、ピクチャ17のブロック203、例えばピクチャ17を形成する1つの、幾つかの、又は全てのブロックを直接的に受信するように構成されてもよい。また、ピクチャ・ブロック203は、現在のピクチャ・ブロック又はコーディングされるべきピクチャ・ブロックとも言及されてもよい。
【0053】
ピクチャ17と同様に、ブロック203は、再び、ピクチャ17よりも小さな寸法ではあるが、強度値(サンプル値)を有するサンプルの2次元アレイ又はマトリクスであるか、又はそれらとして考えることが可能である。換言すると、ブロック203は、例えば、1つのサンプル・アレイ(例えば、モノクロ・ピクチャ17の場合におけるルマ・アレイ、又はカラー・ピクチャの場合におけるルマ又はクロマ・アレイ)又は3つのサンプル・アレイ(例えば、カラー・ピクチャ17の場合におけるルマ及び2つのクロマ・アレイ)、又は適用されるカラー・フォーマットに依存する任意の他の数量及び/又は種類のアレイを含んでもよい。ブロック203の水平及び垂直方向(又は軸)のサンプルの数は、ブロック203のサイズを規定する。従って、ブロックは、例えば、サンプルのMxN(M列N行)アレイ、又は変換係数のMxNアレイであってもよい。
【0054】
図2に示すように、エンコーダ20は、ブロック毎にピクチャ17のブロックを符号化するように構成されており、例えば符号化及び予測はブロック203毎に実行される。
【0055】
図2に示すビデオ・エンコーダ20の実施形態は、更に、スライス(ビデオ・スライスとも呼ばれる)を使用することによってピクチャをパーティション化及び/又は符号化するように構成されることが可能であり、ピクチャは、1つ以上のスライス(典型的には、重複しない)にパーティション化され、又はそれらを使用して符号化されることが可能であり、各スライスは、1つ以上のブロック(例えば、CTU)を含むことが可能である。
【0056】
図2に示すビデオ・エンコーダ20の実施形態は、タイル・グループ(ビデオ・タイル・グループとも呼ばれる)及び/又はタイル(ビデオ・タイルとも呼ばれる)を使用することによって、ピクチャをパーティション化及び/又は符号化するように更に構成されることが可能であり、ピクチャは、1つ以上のタイル・グループ(典型的には、重複しない)にパーティション化され又はそれらを使用して符号化されることが可能であり、各タイル・グループは、例えば1つ以上のブロック(例えば、CTU)又は1つ以上のタイルを含むことが可能であり、各タイルは、例えば、矩形の形状であってもよく、1つ以上のブロック(例えば、CTU)、例えば完全な又は断片的なブロックを含む可能性がある。
【0057】
残差計算
残差計算ユニット204は、例えばピクチャ・ブロック203のサンプル値から、予測ブロック265のサンプル値をサンプル毎に(ピクセル毎に)減算することによって、ピクチャ・ブロック203及び予測ブロック265(予測ブロック265についての更なる詳細は後述される)に基づいて残差ブロック205(残差205とも呼ばれる)を算出して、サンプル・ドメインにおける残差ブロック205を取得するように構成されることが可能である。
【0058】
変換
変換処理ユニット206は、変換ドメインにおける変換係数207を得るために、残差ブロック205のサンプル値に関して変換、例えば離散コサイン変換(DCT)又は離散サイン変換(DST)を適用するように構成されることが可能である。変換係数207はまた、変換残差係数とも呼ばれ、変換ドメインにおける残差ブロック205を表すことが可能である。
【0059】
変換処理ユニット206は、HEVC/H.265用に指定された変換のような、DCT/DSTの整数近似を適用するように構成されてもよい。直交DCT変換と比較して、そのような整数近似は、典型的には、ある因子によってスケーリングされる。順及び逆変換によって処理される残差ブロックのノルムを確保するために、変換プロセスの一部として、付加的なスケーリング因子が適用される。スケーリング因子は、典型的には、シフト演算のために2の冪乗であるスケーリング因子、変換係数のビット深度、精度と実装コストとの間のトレードオフ等のような特定の制約に基づいて選択される。特定のスケーリング因子は、例えば逆変換処理ユニット212による逆変換(及び、例えばビデオ・デコーダ30における逆変換処理ユニット312による対応する逆変換)に関して指定され、エンコーダ20における例えば変換処理ユニット206による順変換のための対応するスケーリング因子は、それに応じて指定される可能性がある。
【0060】
ビデオ・エンコーダ20(個々の変換処理ユニット206)の実施形態は、変換パラメータ、例えばあるタイプの変換又は複数の変換を、直接的に又はエントロピー符号化ユニット270により符号化若しくは圧縮して出力するように構成されることが可能であり、その結果、ビデオ・デコーダ30は復号化のために変換パラメータを受信及び使用することが可能である。
【0061】
量子化
量子化ユニット208は、例えばスカラー量子化やベクトル量子化を適用することにより、変換係数207を量子化し、量子化された係数209を取得するように構成されることが可能である。量子化された係数209はまた、量子化された変換係数209又は量子化された残差係数209とも言及されてもよい。
【0062】
量子化プロセスは、変換係数207の全部又は一部に関連するビット深度を低減することができる。例えば、nビット変換係数は、量子化中にmビット変換係数に丸められる可能性があり、nはmより大きい。量子化の程度は、量子化パラメータ(QP)を調整することによって修正されることが可能である。例えば、スカラー量子化のために、異なるスケーリングが、より細かい又はより粗い量子化を達成するために適用されてもよい。より小さな量子化ステップはより細かい量子化に対応し、より大きな量子化ステップはより粗い量子化に対応する。適用可能な量子化ステップ・サイズは、量子化パラメータ(QP)により示されてもよい。例えば、量子化パラメータは、適用可能な量子化ステップ・サイズの所定のセットに対するインデックスであってもよい。例えば、小さな量子化パラメータは細かい量子化(小さな量子化ステップ・サイズ)に対応することが可能であり、大きな量子化パラメータは粗い量子化(大きな量子化ステップ・サイズ)に対応することが可能であり、その逆も可能である。量子化は、量子化ステップ・サイズによる除算を含む可能性があり、対応する及び/又は逆量子化、例えば逆量子化ユニット210によるものは、量子化ステップ・サイズの乗算を含む可能性がある。例えばHEVCのような幾つかの規格による実施形態は、量子化ステップ・サイズを決定するために量子化パラメータを使用するように構成されてもよい。一般に、量子化ステップ・サイズは、除算を含む式の固定小数点近似を使用して、量子化パラメータに基づいて計算されることが可能である。追加的なスケーリング因子が量子化及び逆量子化のために導入され、残差ブロックのノルムであって、量子化ステップ・サイズ及び量子化パラメータに関する式の固定小数点近似で使用されるスケーリングに起因して修正される可能性があるノルム、を復元することが可能である。1つの例示的な実装において、逆変換及び逆量子化のスケーリングが組み合わせられてもよい。代替的に、カスタマイズされた量子化テーブルが使用され、エンコーダからデコーダへ、例えばビットストリームでシグナリングされてもよい。量子化はロスレスでない演算であり、量子化ステップ・サイズが増えるとロスが増える。
【0063】
ビデオ・エンコーダ20の実施形態(それぞれの量子化ユニット208)は、量子化パラメータ(QP)を、例えば直接的に又はエントロピー符号化ユニット270により符号化して出力するように構成されることが可能であり、その結果、ビデオ・デコーダ30は復号化のために量子化パラメータを受信及び適用することが可能である。
【0064】
逆量子化
逆量子化ユニット210は、量子化ユニット208の逆量子化を量子化係数に適用して、例えば量子化ユニット208により適用される量子化方式の逆を、量子化ユニット208と同じ量子化ステップに基づいて又はそれを使用して適用することにより、逆量子化係数211を取得するように構成される。逆量子化係数211はまた、逆量子化残差係数211とも呼ばれる場合もあり、変換係数207に対応するが、量子化によるロスに起因して、典型的には変換係数に一致しない。
【0065】
逆変換
逆変換処理ユニット212は、変換処理ユニット206によって適用される変換の逆変換、例えば逆離散コサイン変換(DCT)又は逆離散サイン変換(DST)又は他の逆変換を適用して、サンプル・ドメインにおける再構成された残差ブロック213(対応する逆量子化係数213)を取得するように構成される。再構成された残差ブロック213はまた、変換ブロック213と言及される場合がある。
【0066】
再構成
再構成ユニット214(例えば、加算器又は合計部214)は、予測ブロック265に変換ブロック213(即ち、再構成された残差ブロック213)を加算して、例えば再構成された残差ブロック213のサンプル値と予測ブロック265のサンプル値とをサンプル毎に加算することによって、サンプル・ドメインにおける再構成されたブロック215を取得するように構成される。
【0067】
フィルタリング
ループ・フィルタ・ユニット220(又は略して「ループ・フィルタ」220)は、フィルタリングされたブロック221を取得するために、再構成されたブロック215をフィルタリングし、又は一般的には、フィルタリングされたサンプルを取得するために、再構成されたサンプルをフィルタリングするように構成される。ループ・フィルタ・ユニットは、例えばピクセル遷移を平滑化し、又は別の方法でビデオ品質を改善するように構成されている。ループ・フィルタ・ユニット220は、デブロッキング・フィルタ、サンプル・アダプティブ・オフセット(SAO)フィルタ、又は1つ以上の他のフィルタのような1つ以上のループ・フィルタ、例えばバイラテラル・フィルタ、アダプティブ・ループ・フィルタ(ALF)、鮮鋭化又は平滑化フィルタ、又は協調フィルタ、又はそれらの任意の組み合わせを含む可能性がある。ループ・フィルタ・ユニット220は、イン・ループ・フィルタであるとして
図2に示されているが、他の構成では、ループ・フィルタ・ユニット220は、ポスト・ループ・フィルタとして実装されてもよい。フィルタリングされたブロック221はまた、フィルタリング済みの再構成されたブロック221と言及される場合もある。
【0068】
ビデオ・エンコーダ20の実施形態(それぞれのループ・フィルタ・ユニット220)は、(サンプル・アダプティブ・オフセット情報のような)ループ・フィルタ・パラメータを、例えば直接的に又はエントロピー復号化ユニット270により符号化して出力するように構成されることが可能であり、その結果、例えばデコーダ30は同じループ・フィルタ・パラメータ又はそれぞれのループ・フィルタを復号化のために受信及び適用することが可能である。
【0069】
復号化されたピクチャのバッファ
復号化されたピクチャのバッファ(DPB)230は、ビデオ・エンコーダ20によってビデオ・データを符号化する際に使用する参照ピクチャ又は一般的には参照ピクチャ・データを格納するメモリであってもよい。DPB230は、同期DRAM(SDRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM)を含むダイナミック・ランダム・アクセス・メモリ(DRAM)、又は他のタイプのメモリ・デバイスのような種々のメモリ・デバイスのうちの何れかによって形成されてもよい。復号化されたピクチャのバッファ(DPB)1つ以上のフィルタリングされたブロック221を記憶するように構成されてもよい。復号化されたピクチャのバッファ230は、更に、同じ現在のピクチャ又は例えば以前に再構成されたピクチャのような異なるピクチャの、例えば以前に再構成されフィルタリングされたブロック221のような他の以前にフィルタリングされたブロックを記憶するように構成されることが可能であり、完全に以前に再構成された、即ち復号化されたピクチャ(及び対応する参照ブロック及び対応するサンプル)及び/又は例えばインター予測のために部分的に再構成された現在のピクチャ(及び対応する参照ブロック及び対応するサンプル)を提供することが可能である。
復号化されたピクチャのバッファ(DPB)230はまた、1つ以上のフィルタリングされていない再構成ブロック215、又は一般的には例えば再構成されたブロック215がループ・フィルタ・ユニット220によってフィルタリングされていない場合には、フィルタリングされていない再構成されたサンプル、又は再構成されたブロック又はサンプルの他の任意の更なる処理されたバージョンを記憶するように構成されることが可能である。
【0070】
モード選択(パーティショニング&予測)
モード選択ユニット260は、パーティショニング・ユニット262、インター予測ユニット244、及びイントラ予測ユニット254を含み、オリジナル・ピクチャ・データ、例えばオリジナル・ブロック203(現在のピクチャ17の現在のブロック203)、及び、再構成されたピクチャ・データ、例えば同じ(現在の)ピクチャの、及び/又は、1つ以上の以前に復号化されたピクチャからの、例えば復号化されたピクチャのバッファ230又は他のバッファ(例えば、不図示のライン・バッファ)からの、フィルタリングされた及び/又はフィルタリングされていないサンプル又はブロックを受信又は取得するように構成される。再構成されたピクチャ・データは、予測ブロック265又は予測子265を得るために、予測、例えばインター予測又はイントラ予測のための参照ピクチャ・データとして使用される。
【0071】
モード選択ユニット260は、現在ブロックの予測モード(パーティショニングを含まない)及び予測モード(例えば、イントラ又はインター予測モード)に対するパーティショニングを決定又は選択し、残差ブロック205の計算及び再構成ブロック215の再構成のために使用される対応する予測ブロック265を生成するように構成されることが可能である。
【0072】
モード選択ユニット260の実施形態は、最良の一致、又は言い換えれば、最小の残差(最小の残差は伝送又は記憶のためのより良い圧縮を意味する)、又は最小のシグナリング・オーバーヘッド(最小のシグナリング・オーバーヘッドは伝送又は記憶のためのより良い圧縮を意味する)を提供するか、又は両方を考慮若しくはバランスさせるパーティショニング及び予測モードを(例えば、モード選択ユニット260によってサポートされるもの又は利用可能なものから)選択するように構成されることが可能である。モード選択ユニット260は、レート歪最適化(RDO)に基づいて、パーティショニング及び予測モードを決定するように、即ち最小レート歪を提供する予測モードを選択するように構成されてもよい。この文脈における「最良」、「最低」、「最適」などの用語は、必ずしも全体的な「最良」、「最低」、「最適」などを指すとは限らず、ある値が閾値を上回ったり又は下回ったりするような終了又は選択の基準、又は「次善の選択」をもたらす可能性はあるが複雑性及び処理時間を減らす他の制約の達成を指す可能性もある。
【0073】
換言すれば、パーティショニング・ユニット262は、例えば四分木パーティショニング(QT)、バイナリ・パーティショニング(BT)又は三分木パーティショニング(TT)又はそれらの任意の組み合わせを反復的に使用して、ブロック203を、より小さなブロック・パーティション又はサブ・ブロックにパーティション化し(それらは再びブロックを形成し)、例えばブロック・パーティション又はサブ・ブロックのそれぞれについて予測を実行するように構成されることが可能であり、モード選択は、パーティション化されたブロック203のツリー構造の選択を含み、予測モードは、ブロック・パーティション又はサブ・ブロックのそれぞれに適用される。
【0074】
以下、例示的なビデオ・エンコーダ20によって実行されるパーティショニング(例えば、パーティショニング・ユニット260によるもの)及び予測処理(インター予測ユニット244及びイントラ予測ユニット254によるもの)をより詳細に説明する。
【0075】
パーティショニング
パーティショニング・ユニット262は、現在のブロック203を、より小さなパーティション、例えば正方形又は矩形サイズのより小さなブロックにパーティション化(又は分割)することが可能である。これらのより小さなブロック(サブ・ブロックと言及される場合がある)は、更に小さなパーティションに更にパーティション化される可能性がある。これは、ツリー・パーティショニング又は階層ツリー・パーティショニングとも呼ばれ、例えばルート・ツリー・レベル0(階層レベル0、深度0)におけるルート・ブロックは、再帰的にパーティション化けされ、例えば次の下位のツリー・レベルの2つ以上のブロックに、例えばツリー・レベル1(階層レベル1、深度1)におけるノードにパーティション化されることが可能であり、これらのブロックは、次の下位レベルの2つ以上のブロックに、例えばツリー・レベル2(階層レベル2、深度2)等へ、例えば終了基準が満たされること、例えば最大ツリー深度又は最小ブロック・サイズに到達したことに起因してパーティショニングが終了するまで、再度パーティション化されることが可能である。更にはパーティション化されないブロックは、ツリーのリーフ・ブロック又はリーフ・ノードとも呼ばれる。2つのパーティションへのパーティショニングを使用するツリーは二分木(BT)、3つのパーティションへのパーティショニングを使用するツリーは三分木(TT)、4つのパーティションへのパーティショニングを使用するツリーは四分木(QT)と呼ばれる。
【0076】
前述したように、本願で使用される「ブロック」という用語は、ピクチャの一部分、特に正方形又は長方形の部分である可能性がある。例えば、HEVC及びVVCを参照すると、ブロックは、コーディング・ツリー・ユニット(CTU)、コーディング・ユニット(CU)、予測ユニット(PU)、及び変換ユニット(TU)、及び/又は対応するブロック、例えば、コーディング・ツリー・ブロック(CTB)、コーディング・ブロック(CB)、変換ブロック(TB)、又は予測ブロック(PB)であってもよいし、又はこれらに対応していてもよい。
【0077】
例えば、コーディング・ツリー・ユニット(CTU)は、ルマ・サンプルのCTB、3つのサンプル・アレイを有するピクチャのクロマ・サンプルの2つの対応するCTB、又は、サンプルをコーディングするために使用される3つの別々のカラー・プレーン及びシンタックス構造を使用してコーディングされるピクチャ又はモノクロ・ピクチャのサンプルのCTBであってもよいし、又はこれらを含んでもよい。これに対応して、コーディング・ツリー・ブロック(CTB)は、成分のCTBへの分割がパーティショニングであるように、ある値Nに対するサンプルのNxNブロックであってもよい。コーディング・ユニット(CU)は、ルマ・サンプルのコーディング・ブロック、3つのサンプル・アレイを有するピクチャのクロマ・サンプルの2つの対応するコーディング・ブロック、又は、サンプルをコーディングするために使用される3つの別々のカラー・プレーン及びシンタックス構造を使用してコーディングされるピクチャ又はモノクロ・ピクチャのサンプルのコーディング・ブロックであってもよいし、又はこれらを含んでもよい。これに対応して、コーディング・ブロック(CB)は、CTBのコーディング・ブロックへの分割がパーティショニングであるように、M及びNのある値に対するサンプルのMxNブロックであってもよい。
【0078】
実施形態において、例えばHEVCによれば、コーディング・ツリー・ユニット(CTU)は、コーディング・ツリーとして示される四分木構造を使用することによって、CUに分割されることが可能である。インター・ピクチャ(時間的)又はイントラ・ピクチャ(空間的)予測を使用するピクチャ・エリアをコーディングするかどうかの決定は、リーフCUレベルで行われる。各リーフCUは、PU分割タイプに応じて、更に1つ、2つ、又は4つのPUに分割されることが可能である。1つのPU内では、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送られる。PU分割タイプに基づいて予測プロセスを適用することにより残差ブロックを取得した後に、CUは、CUのコーディング・ツリーに類似する別の四分木構造に従って変換ユニット(TU)にパーティション化されることが可能である。
【0079】
実施形態では、例えば、汎用ビデオ・コーディング(VVC)と呼ばれる現在発展中の最新のビデオ・コーディング規格に従って、例えば、組み合わせの四分木及び二分木(QTBT)パーティショニングが、コーディング・ブロックをパーティション化するために使用される。QTBTブロック構造では、CUは正方形又は矩形の何れかの形状を有することが可能である。例えば、コーディング・ツリー・ユニット(CTU)は先ず四分木構造によってパーティション化される。四分木リーフ・ノードは、二分木又は三分木(又はトリプル)構造によって更にパーティション化される。ツリー・リーフ・ノードをパーティション化することは、コーディング・ツリー・ユニット(CU)と呼ばれ、そのセグメンテーションは、それ以上の如何なるパーティショニングもなしに、予測及び変換処理に使用される。これは、CU、PU、TUがQTBTコーディング・ブロック構造において同じブロック・サイズを有することを意味する。並行して、複数のパーティション、例えばトリプル・ツリー・パーティションが、QTBTブロック構造と共に使用されてもよい。
【0080】
一例では、ビデオ・エンコーダ20のモード選択ユニット260は、本願で説明されるパーティショニング技術の任意の組み合わせを実行するように構成されてもよい。
【0081】
上述したように、ビデオ・エンコーダ20は、(例えば、予め決定された)予測モードのセットから、最良又は最適な予測モードを決定又は選択するように構成される。予測モードのセットは、例えば、イントラ予測モード及び/又はインター予測モードを含んでもよい。
【0082】
イントラ予測
イントラ予測モードのセットは、35個の異なるイントラ予測モード、例えばDC(又は平均)モード及び平面モードのような非方向モード、又は例えばHEVCで規定されているような方向モードを含むことが可能であり、又は、67個の異なるイントラ予測モード、例えばDC(又は平均)モード及び平面モードのような非方向モード、又は例えばVVCで規定されているような方向モードを含むことが可能である。
【0083】
イントラ予測ユニット254は、イントラ予測モードのセットのイントラ予測モードに従って、同一の現在のピクチャの隣接ブロックの再構成されたサンプルを使用して、イントラ予測ブロック265を生成するように構成される。
【0084】
イントラ予測ユニット254(又は、一般に、モード選択ユニット260)は、符号化されたピクチャ・データ21に含めるためのシンタックス要素266の形式で、エントロピー符号化ユニット270にイントラ予測パラメータ(又は、一般的には、ブロックに対する選択されたイントラ予測モードを示す情報)を出力するように更に構成され、その結果、例えばビデオ・デコーダ30は、復号化のために予測パラメータを受信して使用することができる。イントラ予測ユニット254は、イントラ・サブ・パーティション(ISP)コーディング・モードを含むことが可能であり、これは、コーディング・ユニットを幾つかの予測ブロックに更に分割し、それらを順に予測することができる。
【0085】
インター予測
(又は可能性のある)インター予測モードのセットは、利用可能な参照ピクチャ(即ち、少なくとも部分的に復号化された以前のピクチャ、例えばDPB230に格納されているもの)及び他のインター予測パラメータ、例えば参照ピクチャの全体又は一部のみ、例えば参照ピクチャの、現在ブロックのエリア周辺のサーチ・ウィンドウ・エリアが、最良に合致する参照ブロックを探索するために使用されるかどうか、及び/又は、例えばハーフ/セミ・ペル、クォーター・ペル補間が適用されるかどうか等に依存する。
【0086】
上記の予測モードに加えて、スキップ・モード及び/又はダイレクト・モードが適用されてもよい。
【0087】
インター予測ユニット244は、動き推定(ME)ユニット及び動き補償(MC)ユニット(双方とも
図2には示されていない)を含むことが可能である。動き推定ユニットは、動き推定のために、ピクチャ・ブロック203(現在のピクチャ17の現在のピクチャ・ブロック203)及び復号化されたピクチャ231、又は少なくとも1つの又は複数の以前に再構成されたブロック、例えば1つ又は複数の他の/異なる以前に復号化されたピクチャ231の再構成されたブロックを受信又は取得するように構成される。例えば、ビデオ・シーケンスは、現在のピクチャと以前に復号化されたピクチャ231とを含む可能性があり、又は換言すれば、現在のピクチャと以前に復号化されたピクチャ231とは、ビデオ・シーケンスを形成するピクチャの一部であってもよいし、又はピクチャのシーケンスを形成してもよい。
【0088】
エンコーダ20は、例えば、複数の他のピクチャの同じ又は異なるピクチャの複数の参照ブロックから参照ブロックを選択し、参照ピクチャ(又は参照ピクチャ・インデックス)及び/又は参照ブロックの位置(x,y座標)と現在ブロックの位置との間のオフセット(空間オフセット)とを、インター予測パラメータとして動き推定ユニット(
図2には示されていない)へ提供するように構成されてもよい。このオフセットも動きベクトル(MV)と呼ばれる。
【0089】
動き補償ユニットは、インター予測パラメータを取得して、例えば受信して、インター予測パラメータに基づいて又はそれを使用してインター予測を実行し、インター予測ブロック265を取得するように構成される。動き補償ユニットによって実行される動き補償は、動き推定によって決定される動き/ブロック・ベクトルに基づいて予測ブロックをフェッチ又は生成すること、可能性としてサブピクセル精度まで補間を実行することを包含することが可能である。補間フィルタリングは、既知のピクセル・サンプルから追加のピクセル・サンプルを生成することができ、従って潜在的に、ピクチャ・ブロックをコーディングするために使用されることが可能な候補予測ブロックの数を増加させる。現在のピクチャ・ブロックのPUに対する動きベクトルを受信すると、動き補償ユニットは、参照ピクチャ・リストのうちの1つにおいて動きベクトルが指し示す予測ブロックを突き止めることができる。
【0090】
動き補償ユニットはまた、ビデオ・スライスのピクチャ・ブロックを復号化する際にビデオ・デコーダ30による使用のためにブロック及びビデオ・スライスに関連するシンタックス要素を生成することも可能である。スライス及びそれぞれのシンタックス要素に加えて又は代替として、タイル・グループ及び/又はタイル、及びそれぞれのシンタックス要素が生成又は使用されてもよい。
【0091】
エントロピー・コーディング
エントロピー符号化ユニット270は、エントロピー符号化アルゴリズム又はスキーム(例えば、可変長コーディング(VLC)スキーム、コンテキスト適応VLCスキーム(CALVC)、算術コーディング・スキーム、バイナリゼーション、コンテキスト適応バイナリ算術コーディング(CABAC)、シンタックス・ベースのコンテキスト適応バイナリ算術コーディング(SBAC)、確率区間パーティショニング・エントロピー(PIPE)コーディング、又は他のエントロピー符号化方法又は技術)を、量子化残差係数209、インター予測パラメータ、イントラ予測パラメータ、ループ・フィルタ・パラメータ、及び/又は他のシンタックス要素に適用し、又はバイパスし(非圧縮)、出力272により出力されることが可能な符号化されたピクチャ・データ21を、例えば符号化されたビットストリーム21の形式で取得するように構成され、その結果、例えばビデオ・デコーダ30は復号化のためのパラメータを受信及び使用することができる。符号化されたビットストリーム21は、ビデオ・デコーダ30に送信されてもよいし、後の送信又はビデオ・デコーダ30による検索のためメモリに記憶されてもよい。
【0092】
ビデオ・エンコーダ20の他の構造的変形例が、ビデオ・ストリームを符号化するために使用されることが可能である。例えば、非変換ベースのエンコーダ20は、特定のブロック又はフレームについて、変換処理ユニット206なしに残差信号を直接的に量子化することが可能である。別の実装において、エンコーダ20は、量子化ユニット208と逆量子化ユニット210とを単一のユニットに結合させることが可能である。
【0093】
デコーダ及び復号化方法
図3は、本出願の技術を実現するように構成されたビデオ・デコーダ30の一例を示す。ビデオ・デコーダ30は、符号化されたピクチャ・データ21(例えば符号化されたビットストリーム21)、例えばエンコーダ20によって符号化されたものを受信して、復号化されたピクチャ131を得るように構成される。符号化されたピクチャ・データ又はビットストリームは、符号化されたピクチャ・データ、例えば符号化されたビデオ・スライスのピクチャ・ブロック(及び/又はタイル・グループ又はタイル)及び関連するシンタックス要素を表すデータを復号化するための情報を含む。
【0094】
図3の例では、デコーダ30は、エントロピー復号化ユニット304、逆量子化ユニット310、逆変換処理ユニット312、再構成ユニット314(例えば、加算器314)、ループ・フィルタ320、復号化されたピクチャのバッファ(
DPB)330、及びモード・アプリケーション・ユニット360、インター予測ユニット344、及びイントラ予測ユニット354を含む。インター予測ユニット344は、動き補償ユニットであってもよいし、又はそれを含んでもよい。ビデオ・デコーダ30は、幾つかの例では、
図2によりビデオ・エンコーダ100に関して説明した符号化パスと概ね逆の復号化パスを実行することが可能である。
【0095】
エンコーダ20に関して説明したように、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ220、復号化されたピクチャのバッファ(DPB)230、インター予測ユニット344、及びイントラ予測ユニット354も、ビデオ・エンコーダ20の「内蔵デコーダ」を形成するものとして言及される。従って、逆量子化ユニット310は、逆量子化ユニット110と機能的に同一であってもよく、逆変換処理ユニット312は、逆変換処理ユニット212と機能的に同一であってもよく、再構成ユニット314は、再構成ユニット214と機能的に同一であってもよく、ループ・フィルタ320は、ループ・フィルタ220と機能的に同一であってもよく、復号化されたピクチャのバッファ330は、復号化されたピクチャのバッファ230と機能的に同一であってもよい。従って、ビデオ・エンコーダ20の各ユニット及び機能に対して行われた説明は、ビデオ・デコーダ30の各ユニット及び機能に、対応して適用される。
【0096】
エントロピー復号化
エントロピー復号化ユニット304は、ビットストリーム21(又は一般的に符号化されたピクチャ・データ21)を分析し、例えば、符号化されたピクチャ・データ21に対するエントロピー復号化を実行して、例えば量子化係数309及び/又は復号化されたコーディング・パラメータ(
図3には示されていない)、例えばインター予測パラメータ(例えば、参照ピクチャ・インデックス及び動きベクトル)、イントラ予測パラメータ(例えば、イントラ予測モード又はインデックス)、変換パラメータ、量子化パラメータ、ループ・フィルタ・パラメータ、及び/又は他のシンタックス要素のうちの何れか又は全てを取得するように構成される。エントロピー復号化ユニット304は、エンコーダ20のエントロピー符号化ユニット270に関して説明したような符号化スキームに対応する復号化アルゴリズム又はスキームを適用するように構成されることが可能である。エントロピー復号化ユニット304は、更に、インター予測パラメータ、イントラ予測パラメータ及び/又は他のシンタックス要素をモード適用ユニット360に提供し、他のパラメータをデコーダ30の他のユニットに提供するように更に構成されてもよい。ビデオ・デコーダ30は、ビデオ・スライス・レベル及び/又はビデオ・ブロック・レベルでシンタックス要素を受信することができる。スライス及びそれぞれのシンタックス要素に追加的に又は代替として、タイル・グループ及び/又はタイル及びそれぞれのシンタックス要素が受信及び/又は使用されてもよい。
【0097】
逆量子化
逆量子化ユニット310は、量子化パラメータ(QP)(又は一般的には逆量子化に関する情報)及び量子化係数を、符号化されたピクチャ・データ21から(例えば、解析及び/又は復号化により、例えばエントロピー復号化ユニット304により)受信し、量子化パラメータに基づいて、復号化された量子化係数に関して逆量子化を適用して、変換係数311と呼ばれ場合もある非量子化係数311を得るように構成されることが可能である。逆量子化プロセスは、量子化の程度、及び同様に適用されるべき逆量子化の程度を決定するために、ビデオ・スライス(又はタイル又はタイル・グループ)内の各ビデオ・ブロックに対してビデオ・エンコーダ20によって決定される量子化パラメータを使用することを含んでもよい。
【0098】
逆変換
逆変換処理ユニット312は、変換係数311とも呼ばれる非量子化係数311を受信し、非量子化係数311に変換を適用して、サンプル・ドメインにおいて再構成された残差ブロック213を取得するように構成されることが可能である。再構成された残差ブロック213はまた、変換ブロック313と言及される場合もある。変換は、逆変換、例えば、逆DCT、逆DST、逆整数変換、又は概念的に類似する逆変換プロセスであってもよい。逆変換処理ユニット312は、更に、変換パラメータ又は対応する情報を、符号化されたピクチャ・データ21から(例えば、解析及び/又は復号化により、例えばエントロピー復号化ユニット304により)受信して、非量子化係数311に適用される変換を決定するように構成されてもよい。
【0099】
再構成
再構成ユニット314(例えば、加算器又は合計部314)は、再構成された残差ブロック313を予測ブロック365に追加して、サンプル・ドメインにおける再構成ブロック315を、例えば再構成された残差ブロック313のサンプル値と予測ブロック365のサンプル値とを追加することによって、取得するように構成されてもよい。
【0100】
フィルタリング
ループ・フィルタ・ユニット320(コーディング・ループ内又はコーディング・ループ後の何れか)は、再構成されたブロック315をフィルタリングして、フィルタリングされたブロック321を取得し、例えばピクセル遷移を平滑化し、又は別の方法でビデオ品質を改善するように構成される。ループ・フィルタ・ユニット320は、デブロッキング・フィルタ、サンプル・アダプティブ・オフセット(SAO)フィルタ、又は1つ以上の他のフィルタ、例えばバイラテラル・フィルタ、アダプティブ・ループ・フィルタ(ALF)、鮮鋭化又は平滑化フィルタ、又は協調フィルタ、又はそれらの任意の組み合わせを含む可能性がある。ループ・フィルタ・ユニット320は、
図3ではイン・ループ・フィルタとして示されているが、他の構成では、ループ・フィルタ・ユニット320は、ポスト・ループ・フィルタとして実現されてもよい。
【0101】
復号化されたピクチャのバッファ
ピクチャの復号化されたビデオ・ブロック321は、復号化されたピクチャのバッファ330に記憶され、これは、復号化されたピクチャ331を、他のピクチャ及び/又は出力表示それぞれのために以後の動き補償用の参照ピクチャとして記憶する。
【0102】
デコーダ30は、復号化されたピクチャ331を、ユーザーに提示又は表示するために、例えば出力332により出力するように構成される。
【0103】
予測
インター予測ユニット344は、インター予測ユニット244(特に、動き補償ユニット)と同一であってもよく、イントラ予測ユニット354は、機能的にはインター予測ユニット254と同一であってもよく、パーティショニング及び/又は予測パラメータ又は符号化されたピクチャ・データ21から受信したそれぞれの情報に基づいて(例えば解析及び/又は復号化により、例えばエントロピー復号化ユニット304により)、分割又はパーティショニング決定及び予測を実行する。モード適用ユニット360は、再構成されたピクチャ、ブロック又はそれぞれのサンプル(フィルタリングされた又はフィルタリングされていないもの)に基づいて、ブロックごとに予測(イントラ予測又はインター予測)を実行して、予測ブロック365を得るように構成されてもよい。
【0104】
ビデオ・スライスがイントラ・コーディングされた(I)スライスとしてコーディングされると、モード適用ユニット360のイントラ予測ユニット354は、現在のピクチャの以前の復号化されたブロックからのデータ及びシグナリングされたイントラ予測モードに基づいて、現在のビデオ・スライスのピクチャ・ブロックに対する予測ブロック365を生成するように構成される。ビデオ・ピクチャが、インター・コーディングされた(即ち、B又はP)スライスとしてコーディングされると、モード適用ユニット360のインター予測ユニット344(例えば、動き補償ユニット)は、エントロピー復号化ユニット304から受信した動きベクトル及び別のシンタックス要素に基づいて、現在のビデオ・スライスのビデオ・ブロックに対する予測ブロック365を生成するように構成される。インター予測に関し、予測ブロックは、1つの参照ピクチャ・リスト内の1つの参照ピクチャから生成されてもよい。ビデオ・デコーダ30は、DPB330に記憶された参照ピクチャに基づくデフォルトの構成技術を使用して、参照フレーム・リスト、List0及びList1を構成することができる。同じもの又は類似するものが、スライス(例えば、ビデオ・スライス)に対して追加的又は代替的に、タイル・グループ(例えば、ビデオ・タイル・グループ)及び/又はタイル(例えば、ビデオ・タイル)を使用する実施形態に又はそれにより適用されることが可能であり、例えば、ビデオはI、P又はBタイル・グループ及び/又はタイルを用いてコーディングされることが可能である。
【0105】
モード適用ユニット360は、動きベクトル又は関連情報及び他のシンタックス要素を解析することによって、現在のビデオ・スライスのビデオ・ブロックに対する予測情報を決定し、その予測情報を使用して、復号化される現在のビデオ・ブロックに対する予測ブロックを生成するように構成される。例えば、モード適用ユニット360は、受信されたシンタックス要素の幾つかを使用して、ビデオ・スライスのビデオ・ブロックをコーディングするために使用される予測モード(例えば、イントラ又はインター予測)、インター予測スライス・タイプ(例えば、Bスライス、Pスライス、又はGPBスライス)、スライスの参照ピクチャ・リストのうちの1つ以上に対する構成情報、スライスのインター符号化されたビデオ・ブロック各々に対する動きベクトル、スライスのインター・コーディングされるビデオ・ブロック各々に対するインター予測ステータス、及び現在のビデオ・スライス内のビデオ・ブロックを復号化するための他の情報を決定する。同じもの又は類似するものが、スライス(例えば、ビデオ・スライス)に対して追加的又は代替的に、タイル・グループ(例えば、ビデオ・タイル・グループ)及び/又はタイル(例えば、ビデオ・タイル)を使用する実施形態に又はそれにより適用されることが可能であり、例えば、ビデオはI、P又はBタイル・グループ及び/又はタイルを用いてコーディングされることが可能である。
【0106】
図3に示すビデオ・デコーダ30の実施形態は、スライス(ビデオ・スライスとも呼ばれる)を使用することによってピクチャをパーティション化及び/又は復号化するように構成されることが可能であり、ピクチャは、1つ以上のスライス(典型的には、重複しない)にパーティション化又は復号化されることが可能であり、各スライスは、1つ以上のブロック(例えば、CTU)を含むことが可能である。
【0107】
図3に示すビデオ・デコーダ30の実施形態は、タイル・グループ(ビデオ・タイル・グループとも呼ばれる)及び/又はタイル(ビデオ・タイルとも呼ばれる)を使用することにより、ピクチャをパーティション化及び/又は復号化するように構成されることが可能であり、ピクチャは、1つ以上のタイル・グループ(典型的には、重複しない)にパーティション化又は復号化されることが可能であり、各タイル・グループは、例えば1つ以上のブロック(例えば、CTU)又は1つ以上のタイルを含むことが可能であり、各タイルは、例えば矩形形状によるものであってもよく、1つ以上のブロック(例えば、CTU)、例えば完全な又は断片的なブロックを含む可能性がある。
【0108】
ビデオ・デコーダ30の他の変形は、符号化されたピクチャ・データ21を復号化するために使用されることが可能である。例えば、デコーダ30は、ループ・フィルタリング・ユニット320なしに出力ビデオ・ストリームを生成することができる。例えば、非変換ベースのデコーダ30は、特定のブロック又はフレームに対して、逆変換処理ユニット312なしに直接的に残差信号を逆量子化することができる。別の実装において、ビデオ・デコーダ30は、逆量子化ユニット310及び逆変換処理ユニット312を単一のユニットに結合させることができる。
【0109】
エンコーダ20及びデコーダ30では、現在のステップの処理結果が更に処理され、次いで次のステップに出力される可能性があることは理解されるべきである。例えば、補間フィルタリング、動きベクトル導出、又はループ・フィルタリングの後に、クリップ又はシフトのような更なる処理が、補間フィルタリング、動きベクトル導出、又はループ・フィルタリングの処理結果に対して実行されてもよい。
【0110】
図4は、本開示の実施形態によるビデオ・コーディング・デバイス400の概略図である。ビデオ・コーディング・デバイス400は、本願で説明されるように、開示される実施形態を実現することに適している。実施形態では、ビデオ・コーディング・デバイス400は、
図1Aのビデオ・デコーダ30のようなデコーダ、又は
図1Aのビデオ・エンコーダ20のようなエンコーダであってもよい。
【0111】
ビデオ・コーディング・デバイス400は、データを受信するための入口ポート410及び受信機ユニット(Rx)420;データを処理するためのプロセッサ、論理ユニット、又は中央処理ユニット430(CPU);データを送信するための送信機ユニット(Tx)440及び出口ポート450(又は出力ポート450);及びデータを記憶するためのメモリ460を含む。ビデオ・コーディング・デバイス400はまた、光又は電気信号の出入りのために、入口ポート410、受信機ユニット420、送信機ユニット440、及び出口ポート450に結合された光-電気(OE)コンポーネント及び電気-光(EO)コンポーネントを含んでもよい。
【0112】
プロセッサ430は、ハードウェア及びソフトウェアによって実現される。プロセッサ430は、1つ以上のCPUチップ、コア(例えば、マルチ・コア・プロセッサ)、FPGA、ASIC、及びDSPとして実現されてもよい。プロセッサ430は、入口ポート410、受信機ユニット420、送信機ユニット440、出口ポート450、及びメモリ460と通信する。プロセッサ430は、コーディング・モジュール470を含む。コーディング・モジュール470は、上述の開示される実施形態を実現する。例えば、コーディング・モジュール470は、種々のコーディング動作を実現、処理、準備、又は提供する。従って、コーディング・モジュール470を含むことは、ビデオ・コーディング・デバイス400の機能に対するかなりの改善を提供し、ビデオ・コーディング・デバイス400の異なる状態への変換に影響を及ぼす。代替的に、コーディング・モジュール470は、メモリ460に格納された命令として実現され、プロセッサ430によって実行される。
【0113】
メモリ460は、1つ以上のディスク、テープ・ドライブ、及びソリッド・ステート・ドライブを含み、オーバー・フロー・データ記憶デバイスとして使用され、このようなプログラムが実行のために選択された場合にプログラムを記憶し、プログラムの実行中に読み込まれた命令及びデータを記憶することができる。メモリ460は、揮発性及び/又は不揮発性であってもよく、リード・オンリ・メモリ(ROM)、ランダム・アクセス・メモリ(RAM)、三値連想メモリ(TCAM)、及び/又はスタティック・ランダム・アクセス・メモリ(SRAM)であってもよい。
【0114】
図5は、例示的な実施形態による、
図1のソース・デバイス120及び宛先デバイス14の何れか又は両方として使用することが可能な装置500の簡略化されたブロック図である。
【0115】
装置500内のプロセッサ502は、中央処理ユニットであるとすることが可能である。代替的に、プロセッサ502は、現在存在している又は今後開発される情報を操作又は処理することが可能な、任意の他のタイプのデバイス又は複数のデバイスであるとすることが可能である。開示される実装は、図示のように単一のプロセッサ、例えばプロセッサ502を用いて実施することが可能であるが、1つより多いプロセッサを用いて、速度及び効率における長所を獲得することができる。
【0116】
装置500内のメモリ504は、実装においてはリード・オンリ・メモリ(ROM)デバイス又はランダム・アクセス・メモリ(RAM)デバイスであるとすることが可能である。任意の他の適切なタイプのストレージ・デバイスがメモリ504として使用されることが可能である。メモリ504は、バス512を使用してプロセッサ502によってアクセスされるコード及びデータ506を含むことが可能である。メモリ504は、更に、オペレーティング・システム508及びアプリケーション・プログラム510を含むことが可能であり、アプリケーション・プログラム510は、本願で説明される方法をプロセッサ502が実行することを可能にする少なくとも1つのプログラムを含む。例えば、アプリケーション・プログラム510は、アプリケーション1ないしNを含むことが可能であり、これらは本願で説明される方法を実行するビデオ・コーディング・アプリケーションを更に含む。また、装置500は、ディスプレイ518のような1つ以上の出力デバイスを含むことが可能である。ディスプレイ518は、一例では、タッチ入力を感知するように動作することが可能なタッチ感知素子に、ディスプレイを組み合わせるタッチ感知ディスプレイであってもよい。ディスプレイ518は、バス512を介してプロセッサ502に結合することが可能である。
【0117】
本願では、単一のバスとして描かれているが、装置500のバス512は、複数のバスで構成されることが可能である。更に、セカンダリ・ストレージ514は、装置500の他の構成要素に直接的に結合されることが可能であり、又はネットワークを介してアクセスされることが可能であり、メモリ・カードのような単一の集積ユニット又は複数のメモリ・カードのような複数のユニットを含むことが可能である。従って、装置500は、広く様々な構成で実現されることが可能である。
【0118】
イントラ・サブ・パーティション(ISP)コーディング・モードは、ライン・ベース・イントラ予測(LIP)コーディングのアップデートされたバージョンである。従来のバージョンのイントラ・サブ・パーティション・コーディング・モードは、唯1つのクロマ・サブサンプリング(クロマ・フォーマット又はクロマ・カラー・フォーマットとも呼ばれる)-4:2:0をサポートし、他のクロマ・フォーマットのサポートのための如何なるパラメータも有しない。特に、従来のバージョンのイントラ・サブ・パーティション・コーディング・モードは、アプリケーションで広く使用されているクロマ・サブサンプリング4:4:4に関して動作することができない。本発明の実施形態は、全てのクロマ・サブサンプリングをカバーするために、イントラ・サブ・パーティション・コーディング・モードを拡張する。
本発明の実施形態は、クロマ・サブサンプリングをカバーするためにイントラ・サブ・パーティション・コーディング・モードを拡張する2つのソリューションを提案する:
1)水平及び垂直クロマ・サブサンプリングに対応する2つの入力パラメータSubWidthC及びSubHeightCを追加する。これらのパラメータは、クロマ変換ブロック・サイズの導出に使用される。
2)ノーマル・ケースの拡張。クロマ・サブサンプリング4:4:4に関し、クロマに関するISPパーティションは、ルマに関するISPパーティションに対応する。
【0119】
(デジタル)ピクチャは、強度値を有するサンプルの2次元アレイ又はマトリクスであるか、又はそのように考えることが可能である。アレイ中のサンプルはまた、ピクセル(ピクチャ要素の短縮形)又はペルと言及される場合がある。アレイ又はピクチャの水平及び垂直方向(又は軸)におけるサンプルの数は、ピクチャのサイズ及び/又は解像度を規定する。色の表現には、典型的には、3つの色成分が使用され、即ち、ピクチャは、3つのサンプル・アレイで表現されてもよいし、又はそれを含んでもよい。RGBフォーマット又は色空間において、ピクチャは対応する赤、緑、及び青のサンプル・アレイを含む。しかしながら、ビデオ・コーディングにおいて、各ピクセルは、典型的には、ルミナンス及びクロミナンス・フォーマット又は色空間、例えばYCbCrで表現され、YCbCrは、Yで示されるルミナンス成分(時にはそれに代えてLも使用される)とCb及びCrで示される2つのクロミナンス成分とを含む。
【0120】
ルマ及びクロマ成分は異なるサブサンプリングを有することが可能である。例えば、所謂4:2:0のクロマ・フォーマットでは、2つのクロマ・アレイの各々は、ルマ・アレイの半分の高さと半分の幅とを有する。
【0121】
VVC仕様はクロマ表現の5つの異なるフォーマットを記述している。これらのフォーマットは表1に提示されている。
表1.VVC仕様で記述されているクロマ・フォーマット1
【表1】
【0122】
この表の各欄は以下の意味を有する:
chroma_format_idcは、ルマ・サンプリングに対するクロマ・サンプリングを示す。chroma_format_idcの値は両端を含む0ないし3の範囲内にあるものとする。
【0123】
1に等しいseparate_colour_plane_flagは、4:4:4クロマ・フォーマットの3つの色成分が別々にコーディングされることを示す。0に等しいseparate_colour_plane_flagは、色成分が別々にはコーディングされないことを示す。separate_colour_plane_flagが存在しない場合、それは0に等しいと推定される。separate_colour_plane_flagが1に等しい場合、コーディングされたピクチャは3つの別個の成分から構成されており、それら各々は1つのカラー・プレーン(Y,Cb又はCr)のコーディングされたサンプルから構成され、モノクロ・コーディング・シンタックスを使用する。この場合、各カラー・プレーンは特定のcolour_plane_id値に関連付けられる。
注記1-異なるcolor_plane_id値を有するカラー・プレーンの間に復号化プロセスの依存性は存在しない。例えば、color_plane_idの1つの値を有するモノクロ・ピクチャの復号化処理は、インター予測に関し、color_plane_idの異なる値を有するモノクロ・ピクチャからの如何なるデータも使用しない。
【0124】
separate_color_plane_flagの値に応じて、変数ChromaArrayTypeの値は次のように割り当てられる:
- separate_colour_plane_flagが0に等しい場合、ChromaArrayTypeはchroma_format_idcに等しく設定される。
- それ以外の場合(separate_colour_plane_flagは1に等しい)、ChromaArrayTypeは0に等しく設定される。
【0125】
クロマ・フォーマットは、クロマ・アレイの優先性とサブサンプリングを決定する。
モノクロ・サンプリングでは、名目上、ルマ・アレイと考えられる唯1つのサンプル・アレイが存在する。
4:2:0サンプリングでは、2つのクロマ・アレイの各々はルマ・アレイの半分の高さと半分の幅を有する。
4:2:2サンプリングでは、2つのクロマ・アレイの各々はルマ・アレイと同じ高さと半分の幅を有する。
4:4:4サンプリングでは、separate_colour_plane_flagの値に応じて、以下を適用する:
- separate_color_plane_flagが0に等しい場合、2つのクロマ・アレイの各々はルマ・アレイと同じ高さと幅を有する。
- それ以外の場合(separate_color_plane_flagが1に等しい場合)、3つのカラー・プレーンは、モノクロのサンプリングされたピクチャとして別々に処理される。
【0126】
ビデオ・シーケンスにおけるルマ及びクロマ・アレイの各サンプルの表現に必要なビット数は、両端を含む8ないし16の範囲内にあり、ルマ・アレイで使用されるビット数は、クロマ・アレイで使用されるビット数と相違する可能性がある。
chroma_format_idcの値が1に等しい場合、ピクチャにおけるルマ及びクロマ・サンプルの名目上の垂直及び水平相対位置は
図6に示されている。代替的なクロマ・サンプル相対位置が、ビデオ・ユーザビリティ情報で示されてもよい。
chroma_format_idcの値が2に等しい場合、クロマ・サンプルは対応するルマ・サンプルと共存し、ピクチャにおける名目上の位置は
図7に示されている。
chroma_format_idcの値が3に等しい場合、全てのアレイ・サンプルは全てのケースのピクチャに関して共存し、ピクチャにおける名目上の位置は
図8に示されている。
【0127】
変数SubWidthC及びSubHeightCはクロマ・フォーマット・サンプリング構造に依存して表1に指定されており、これは次に、chroma_format_idc及びseparate_colour_plane_flagにより指定される。
代替的に、SubWidthC及びSubHeightCは次のようにして決定することが可能であり:
SubWidthC = (1 + log2(wluma / wchroma))
SubHeightC = (1 + log2(hluma / hchroma)),
wluma,hlumaはルマ・アレイの寸法であり、wchroma,hchromaは対応するクロマ・アレイの寸法である。従って、変数SubWidthC及びSubHeightCはルマ及びクロマ・サイズの間の比を表す。
【0128】
第1実施形態では、ISP技術は、ルマ・ブロックに対してのみサブ・パーティショニングを実行し、クロマ・ブロックに対しては、予測及び更なる変換がパーティショニングなしにCUブロック全体に対して実行される。変換ユニットの段階では、クロマ・ブロックのTUはビットストリームで指定するクロマ・フォーマットに従って、例えばSPSレベルで取り扱われるべきであることに留意すべきであり、ルマ及びクロマ・サイズの関係で記述される一般的な値、例えばSubWidthC及びSubHeightCが使用されるものとする。以下の表2は、第1実施形態に関するクロマTU位置及びサイズ決定の一例を示す。
【0129】
表2 - 第1実施形態のtransform_unitシンタックス・テーブルの例
【表2】
【0130】
表2において、座標x0,y0及びサイズtbWidth,tbHeightは現在のルマTUブロックの位置とサイズを表し;グローバル・アレイCbPosX,CbPosY,CbWidth,CbHeightはCUの位置とサイズを取得することを可能にする。従って、座標及びサイズxC,yC,wC,hCは、クロマCUブロックに等しいクロマTUブロックを表すように計算されている。使用するクロマ・カラー・フォーマットに依存して、クロマ・ブロック・サイズは、対応するルマ・ブロック・サイズと異なる可能性があり、従って全てのクロマ・フォーマットのケースを扱う際に、クロマ・ブロックの幅と高さはSubWidthC及びSubHeightCによって相応に正規化されることに留意すべきである。
【0131】
この実施形態では、ビットストリームは、イントラ・サブ・パーティション(ISP)を示す情報を含む。例えば、ISPを示す情報はフラグである。フラグはintra_subpartitions_split_flag及び/又はintra_subpartitions_mode_flagであってもよい。ビットストリームを受信した後、デコーダはフラグを得るためにビットストリームを解析する。次いで、デコーダは、ISPの情報、例えばIntraSubPartitionsSplitTypeをフラグに基づいて決定する。
【0132】
1に等しいintra_subpartitions_mode_flag[x0][y0]は、現在のイントラ・コーディング・ユニットが、NumIntraSubPartitions[x0][y0]の矩形の変換ブロック・サブパーティションにパーティション化されることを示す。0に等しいintra_subpartitions_mode_flag[x0][y0]は、現在のイントラ・コーディング・ユニットが、矩形の変換ブロック・サブパーティションにパーティション化されないことを示す。
【0133】
intra_subpartitions_mode_flag[x0][y0]が存在しない場合、それは0に等しいと推定される。intra_subpartitions_split_flag[x0][y0]は、イントラ・サブパーティション分割タイプが水平であるか又は垂直であるかを示す。intra_subpartitions_split_flag[x0][y0]が存在しない場合、それは次のように推定される:
- cbHeightがMaxTbSizeYより大きい場合、intra_subpartitions_split_flag[x0][y0]は0に等しいと推定される。
- それ以外の場合(cbHeightがMaxTbSizeYより大きい)、intra_subpartitions_split_flag[x0][y0]は1に等しいと推定される。
【0134】
変数IntraSubPartitionsSplitTypeは、表3に示されるように、現在のルマ・コーディング・ブロックに使用される分割のタイプを指定する。IntraSubPartitionsSplitTypeは次のようにして導出される:
- intra_subpartitions_mode_flag[x0][y0]が0に等しい場合、IntraSubPartitionsSplitTypeは0に等しく設定される。
- それ以外の場合、IntraSubPartitionsSplitTypeは、
1 + intra_subpartitions_split_flag[x0][y0]に等しく設定される。
表3 - IntraSubPartitionsSplitTypeに関連する名称
【表3】
【0135】
次いで、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示すISPの情報は、IntraSubPartitionsSplitTypeによって示される。IntraSubPartitionsSplitType != ISP_NO_SPLITである場合、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用される。
【0136】
第2実施形態では、ISP技術は、4:4:4サブサンプリングがビットストリームで使用される場合に、ルマ・ブロック・サブ・パーティショニングと整合するクロマ・ブロックに対するサブ・パーティショニングを実行する。他のサブサンプリングのケース、例えば、4:2:0と4:2:2に関し、ISPはクロマ・パーティショニングを実行せず、クロマ・ブロックはCU全体と一致する。以下の表は、第2実施形態に関するクロマTU位置及びサイズ決定の一例を示す。
【0137】
表4 - 第2実施形態のtransform_unitシンタックス・テーブルの例
【表4】
【0138】
表において、条件ChromaArrayType = = 3は、現在のクロマ・フォーマットが4:4:4であるかどうかをチェックする。肯定的な場合、2つのクロマcbfフラグは、ISPが使用される場合には(IntraSubPartitionsSplitType != ISP_NO_SPLIT)、シグナリングされるように強制され、そしてクロマ・ブロックに関する位置及びサイズは、else分岐に従って、現在のTUの位置とサイズに基づいて決定される。このケースでは、現在のクロマ・ブロックの位置とサイズは、TUの位置と座標から取得されている。
【0139】
第2実施形態では、ntraSubPartitionsSplitTypeの値は、第1実施形態で説明した方法と同様に決定することができる。
【0140】
図9は、本発明による復号化装置によって実現されるイントラ・サブ・パーティション(ISP)コーディングの方法の実施形態を示す。復号化装置は、
図1Aのビデオ・デコーダ30又は
図3のデコーダ30であってもよい。ISPコーディングの方法は、以下のステップを含む。ステップ901において、復号化装置はISPの情報を取得する。上述したように、復号化装置は、符号化装置から受信したビットストリームを解析することができる。ビットストリームは、ISPを示す情報、例えばintra_subpartitions_split_flag及び/又はintra_subpartitions_mode_flagを含む。次いで、復号化装置は、IPSの情報、例えばIntraSubPartitionsSplitTypeを、intra_subpartitions_split_flag及び/又はintra_subpartitions_mode_flagに基づいて取得する。
【0141】
ステップ902において、復号化装置は、第1条件が充足されるかどうかを決定し、
第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)ISPの情報が、ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む。“IntraSubPartitionsSplitType != ISP_NO_SPLIT”という表現は、ルマ・コーディング・ブロックを分割するためにISPが使用されることを、ISPの情報が示していることを意味する。“treeType = = SINGLE_TREE”という表現は、コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されることを意味する。
【0142】
ステップ903において、復号化装置は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定し、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数であり、クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。
【0143】
復号装置は、SubWidthC及びSubHeightCに基づいて、及びコーディング・ユニットのルマ・コーディング・ブロックのサイズにも基づいて、クロマTBのサイズを決定することができる。例えば、クロマ変換ブロックのサイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
を満たし、wCはクロマ変換ブロックの幅を表し、hCはクロマ変換ブロックの高さを表し、CbWidthはルマ・コーディング・ブロックの幅を表し、CbHeightはルマ・コーディング・ブロックの高さを表す。
【0144】
クロマ変換ブロックのサイズは、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズに等しく;
- それ以外の場合、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズとクロマ・フォーマットの関数として決定されること;
に従って決定される。
【0145】
復号化装置は、第1条件と第2条件が充足される場合に、クロマTBのサイズを決定することが可能であり、第2条件は、変数ChromaArrayTypeがデフォルト値、例えば3に等しくないことを含む。
【0146】
図10は、本発明による符号化装置によって実現されるイントラ・サブ・パーティション(ISP)コーディングの方法の実施形態を示す。符号化装置は、
図1Aのビデオ・エンコーダ20又は
図2のエンコーダ20であってもよい。ISPコーディングの方法は、以下のステップを含む。
ステップ1001において、符号化装置は、第1条件が充足されるかどうかを決定し、第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)ルマ・コーディング・ブロックを分割するためにISPが使用されることを含む。“IntraSubPartitionsSplitType != ISP_NO_SPLIT”という表現は、ルマ・コーディング・ブロックを分割するためにISPが使用されることを意味する。“treeType = = SINGLE_TREE”という表現は、コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されることを意味する。
【0147】
ステップ1002において、符号化装置は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定し、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数であり、クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。
【0148】
符号化装置は、SubWidthC及びSubHeightCに基づいて、及びコーディング・ユニットのルマ・コーディング・ブロックのサイズにも基づいて、クロマTBのサイズを決定することができる。例えば、クロマ変換ブロックのサイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
を満たし、wCはクロマ変換ブロックの幅を表し、hCはクロマ変換ブロックの高さを表し、CbWidthはルマ・コーディング・ブロックの幅を表し、CbHeightはルマ・コーディング・ブロックの高さを表す。
【0149】
クロマ変換ブロックのサイズは、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズに等しく;
- それ以外の場合、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズとクロマ・フォーマットの関数として決定されること;
に従って決定される。
【0150】
符号化装置は、第1条件と第2条件が充足される場合に、クロマTBのサイズを決定することが可能であり、第2条件は、変数ChromaArrayTypeがデフォルト値、例えば3に等しくないことを含む。
【0151】
ステップ1003において、符号化装置はビットストリームを符号化し、ビットストリームは、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを示す情報を含む。例えば、ビットストリームは、ISPを示す情報、例えばintra_subpartitions_split_flag及び/又はintra_subpartitions_mode_flagを含む。
【0152】
図11は、イントラ・サブ・パーティション(ISP)のための復号化装置1100の実施形態を示す。復号化装置1100は、
図1Aのビデオ・デコーダ30又は
図3のデコーダ30であってもよい。装置1100は取得ユニット1101と決定ユニット1102を含む。取得ユニット1101は、ISPの情報を取得するように構成されており、ISPの情報は、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されるかどうかを示す。決定ユニット1102は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するように構成され、SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は:1)コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及び2)ISPの情報が、ルマ・コーディング・ブロックを分割するためにISPが使用されることを示していることを含む。
【0153】
復号化装置は、
図9及び上記の他の実施形態で説明されたような方法を実行するように構成される。例えば、決定ユニット1102は、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合には、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズに等しく;
- それ以外の場合には、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズとクロマ・フォーマットの関数として決定されること;
に従ってクロマ変換ブロックのサイズを決定するように構成されている。
【0154】
決定ユニットは、第1条件及び第2条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するように構成されてもよく、第2条件は、変数ChromaArrayTypeがデフォルト値に等しくないことを含む。
【0155】
図12は、イントラ・サブ・パーティション(ISP)のための符号化装置1200の実施形態を示す。符号化装置1200は、
図1Aのビデオ・エンコーダ20又は
図2のエンコーダ20であってもよい。装置1200は決定ユニット1201と符号化ユニット1202を含む。決定ユニット1201は、少なくとも第1条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するように構成されている。SubWidthC及びSubHeightCはクロマ・フォーマット情報に依存する2つの変数である。クロマ・フォーマット情報は、コーディング・ユニットが所属するピクチャのクロマ・フォーマットを示し、クロマ・フォーマットは、4:2:0,又は4:2:2,又は4:4:4のうちの少なくとも1つを含む。第1条件は、コーディング・ユニットをパーティション化するためにシングル・ツリーが使用されること、及びコーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを含む。符号化ユニット1202は、ビットストリームを符号化するように構成されており、ビットストリームは、コーディング・ユニットのルマ・コーディング・ブロックを分割するためにISPが使用されることを示す情報を含む。
【0156】
符号化装置は、
図10及び上記の他の実施形態で説明されたような方法を実行するように構成される。例えば、決定ユニット1201は:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
に従ってクロマ変換ブロックのサイズを決定するように構成されており、wCはクロマ変換ブロックの幅を表し、hCはクロマ変換ブロックの高さを表し、CbWidthはルマ・コーディング・ブロックの幅を表し、CbHeightはルマ・コーディング・ブロックの高さを表す。
【0157】
決定ユニット1201は、
SubWidthC = (1 + log2(wluma / wchroma));
SubHeightC = (1 + log2(hluma / hchroma));
に従ってSubWidthC及びSubHeightCを決定するように構成されてもよく、wluma,hlumaはルマ・アレイに対応する寸法であり、wchroma,hchromaはクロマ・アレイに対応する寸法である。
【0158】
決定ユニット1201は、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合には、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズに等しく;
- それ以外の場合には、クロマ変換ブロックのサイズはルマ・コーディング・ブロックのサイズとクロマ・フォーマットの関数として決定されること;
に従ってクロマ変換ブロックのサイズを決定するようにも構成されている。
【0159】
決定ユニット1201は、第1条件及び第2条件が充足される場合に、SubWidthC及びSubHeightCに基づいてコーディング・ユニットのクロマ変換ブロックのサイズを決定するように構成され、第2条件は、変数ChromaArrayTypeがデフォルト値に等しくないことを含む。
【0160】
本願は以下の実施態様を更に提供する:
実施形態1.復号化デバイスにより実行されるコーディングの方法であって、方法は:
ビットストリームを解析するステップであって、ビットストリームはイントラ・サブ・パーティション(ISP)コーディング・モードの情報を含む、ステップ;
ISPコーディング・モードでコーディングされたブロックのクロマ変換ユニット(TU)を決定するステップであって、クロマ変換ユニットのサイズはクロマ・フォーマットに依存している、ステップを含む。
【0161】
実施形態2.実施形態1の方法であって、クロマ変換ユニットのサイズはルマ・コーディング・ブロックのサイズにも依存している。
【0162】
実施形態3.実施形態1又は2の方法であって、クロマ変換ユニットのサイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
に従って決定され、wCはクロマTUの幅を表し、wCはクロマTUの高さを表し、SubWidthC及びSubHeightCはクロマ・フォーマットに依存する変数であり、CbWidth及びCbHeightはグローバル・アレイである。
【0163】
実施形態4.実施形態3の方法であって、SubWidthC及びSubHeightCは:
SubWidthC = (1 + log2(w
luma
/ w
chroma
));
SubHeightC = (1 + log2(h
luma
/ h
chroma
));
に従って決定され、w
luma
,h
luma
はルマ・アレイに対応する寸法であり、w
chroma
,h
chroma
はクロマ・アレイに対応する寸法である。
【0164】
実施形態5.実施形態1の方法であって、クロマ変換ユニットのサイズは、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合には、クロマ変換ユニットのサイズは対応するルマ変換ユニットのサイズに等しく;
- それ以外の場合には、クロマ変換ユニットのサイズは対応するルマ・コーディング・ユニットのサイズに等しいこと;
に従って決定される。
【0165】
実施形態6.実施形態5の方法であって、クロマ変換ユニットのサイズは、以下の表に従って決定される:
【表5】
【0166】
実施形態7.実施形態1-6のうちの任意の1つの方法であって、方法は更に:
ISPコーディング・モードによりコーディングされたブロックのルマ変換ユニットを決定するステップを含む。
【0167】
実施形態8.符号化デバイスにより実行されるコーディングの方法であって:
イントラ・サブ・パーティション(ISP)コーディング・モードでコーディングされたブロックのクロマ変換ユニット(TU)を決定するステップであって、クロマ変換ユニットのサイズはクロマ・フォーマットに依存している、ステップ;及び
ビットストリームを符号化するステップであって、ビットストリームはISPコーディング・モードの情報を含む、ステップを含む。
【0168】
実施形態9.実施形態8の方法であって、クロマ変換ユニットのサイズはルマ・コーディング・ブロックのサイズにも依存している。
【0169】
実施形態10.実施形態8又は9の方法であって、クロマ変換ユニットのサイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
に従って決定され、wCはクロマTUの幅を表し、wCはクロマTUの高さを表し、SubWidthC及びSubHeightCはクロマ・フォーマットに依存する変数であり、CbWidth及びCbHeightはグローバル・アレイである。
【0170】
実施形態11.実施形態10の方法であって、SubWidthC及びSubHeightCは:
SubWidthC = (1 + log2(w
luma
/ w
chroma
));
SubHeightC = (1 + log2(h
luma
/ h
chroma
));
に従って決定され、w
luma
,h
luma
はルマ・アレイの寸法であり、w
chroma
,h
chroma
はクロマ・アレイに対応する寸法である。
【0171】
実施形態12.実施形態8の方法であって、クロマ変換ユニットのサイズは、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合には、クロマ変換ユニットのサイズは対応するルマ変換ユニットのサイズに等しく;
- それ以外の場合には、クロマ変換ユニットのサイズは対応するルマ・コーディング・ユニットのサイズに等しいこと;
に従って決定される。
【0172】
実施形態13.実施形態12の方法であって、クロマ変換ユニットのサイズは、以下の表に従って決定される:
【表6】
【0173】
実施形態14.実施形態8-13のうちの任意の1つの方法であって、方法は更に:
ISPコーディング・モードによりコーディングされたブロックのルマ変換ユニットを決定するステップを含む。
【0174】
実施形態15.復号化デバイスにより実行されるコーディングの方法であって、方法は:
ビットストリームを解析するステップであって、ビットストリームはクロマ・フォーマットの情報を含む、ステップ;
クロマ・フォーマットに基づいて、クロマ変換ユニット(TU)のサイズを決定するステップを含む。
【0175】
実施形態16.実施形態15の方法であって、クロマ変換ユニットのサイズは:
wC = CbWidth[x0][y0] / SubWidthC;及び
hC = CbHeight[x0][y0] / SubHeightC;
に従って決定され、wCはクロマTUの幅を表し、hCはクロマTUの高さを表し、SubWidthC及びSubHeightCはクロマ・フォーマットに依存する変数であり、CbWidth及びCbHeightはそれぞれコーディング・ブロックの幅及び高さである。
【0176】
実施形態17.実施形態16の方法であって、SubWidthC及びSubHeightCは:
SubWidthC = (1 + log2(w
luma
/ w
chroma
));
SubHeightC = (1 + log2(h
luma
/ h
chroma
));
に従って決定され、w
luma
,h
luma
はルマ・アレイに対応する寸法であり、w
chroma
,h
chroma
はクロマ・アレイに対応する寸法である。
【0177】
実施形態18.実施形態15-17のうちの何れか1つの方法であって、クロマ変換ユニットのサイズは、以下のルール:
- クロマ・フォーマットが4:4:4に等しい場合には、クロマ変換ユニットのサイズは対応するルマ変換ユニットのサイズに等しく;
- それ以外の場合には、クロマ変換ユニットのサイズは対応するコーディング・ユニットのサイズに等しいこと;
に従って決定される。
【0178】
実施形態19.実施形態15-18のうちの任意の1つの方法であって、クロマTUは、イントラ・サブ・パーティション(ISP)コーディング・モードによりコーディングされる。
【0179】
実施形態20.実施形態19の方法であって、クロマ変換ユニットのサイズは、以下の表に従って決定される:
【表7】
【0180】
以下、上記の実施形態で示される符号化方法及び復号化方法の適用例、並びにそれらを使用するシステムを説明する。
【0181】
本発明の実施形態は、全てのクロマ・サブサンプリングをカバーするために、イントラ・サブ・パーティション・コーディング・モードを拡張する。従って、ISPのためのコーディング・ユニットのクロマ変換ブロック(TB)のサイズを決定するための正確で汎用的な方法が達成される。
【0182】
図13は、コンテンツ配信サービスを実現するためのコンテンツ供給システム3100を示すブロック図である。このコンテンツ供給システム3100は、捕捉デバイス3102と、端末デバイス3106とを含み、オプションとしてディスプレイ3126を含む。捕捉デバイス3102は、通信リンク3104を介して端末デバイス3106と通信する。通信リンクは、上述の通信チャネル13を含んでもよい。通信リンク3104は、WIFI、イーサーネット、ケーブル、無線(3G/4G/5G)、USB、又はそれらの任意の種類の組み合わせ等を含むが、これらに限定されない。
【0183】
捕捉デバイス3102は、データを生成し、上記の実施形態に示されるように、符号化方法によってデータを符号化してもよい。代替的に、捕捉デバイス3102は、ストリーミング・サーバー(不図示)にデータを分配することが可能であり、サーバーは、データを符号化し、符号化されたデータを端末デバイス3106に送信する。捕捉デバイス3102は、カメラ、スマートフォン又はパッド、コンピュータ又はラップトップ、ビデオ会議システム、PDA、車載デバイス、又はそれら任意の組み合わせ等を含むが、これらに限定されない。例えば、捕捉デバイス3102は、上述のようにソース・デバイス12を含んでもよい。データがビデオを含む場合、捕捉デバイス3102に含まれるビデオ・エンコーダ20は、実際にビデオ符号化処理を実行してもよい。データがオーディオ(即ち、声)を含む場合、捕捉デバイス3102に含まれるオーディオ・エンコーダは、実際にオーディオ符号化処理を実行してもよい。幾つかの実際的なシナリオでは、捕捉デバイス3102は、符号化されたビデオ及びオーディオ・データを、それらを一緒に多重化することによって分配する。他の実際的なシナリオ、例えばビデオ会議システムにおいては、符号化されたオーディオ・データ及び符号化されたビデオ・データは多重化されない。捕捉デバイス3102は、符号化されたオーディオ・データ及び符号化されたビデオ・データを別々に端末デバイス3106に分配する。
【0184】
コンテンツ供給システム3100では、端末デバイス310は、符号化されたデータを受信及び再生する。端末デバイス3106は、スマートフォン又はパッド3108、コンピュータ又はラップトップ3110、ネットワーク・ビデオ・レコーダ(NVR)/デジタル・ビデオ・レコーダ(DVR)3112、TV3114、セット・トップ・ボックス(STB)3116、ビデオ会議システム3118、ビデオ監視システム3120、携帯デジタル・アシスタント(PDA)3122、車載デバイス3124、又はこれらの任意の組み合わせ、又は上述した符号化されたデータを復号化することが可能な同様なもののような、データ受信及び復元能力を有するデバイスであるとすることが可能である。例えば、端末デバイス3106は、上述したような宛先デバイス14を含む可能性がある。符号化されたデータがビデオを含む場合、端末デバイスに含まれるビデオ・デコーダ30は、ビデオ復号化を実行するように優先される。符号化されたデータがオーディオを含む場合、端末デバイスに含まれるオーディオ・デコーダは、オーディオ復号化処理を実行するように優先される。
【0185】
ディスプレイを有する端末デバイス、例えば、スマートフォン又はパッド3108、コンピュータ又はラップトップ3110、ネットワーク・ビデオ・レコーダ(NVR)/デジタル・ビデオ・レコーダ(DVR)3112、TV3114、パーソナル・デジタル・アシスタント(PDA)3122、又は車載デバイス3124の場合、端末デバイスは、復号化されたデータをそのディスプレイに供給することができる。例えば、STB3116、ビデオ会議システム3118、又はビデオ監視システム3120のようなディスプレイを備えていない端末デバイスについては、復号化されたデータを受信及び表示するために、外部ディスプレイ3126がそこに接続される。
このシステムにおける各デバイスが符号化又は復号化を実行する場合に、上記の実施形態に示されるように、ピクチャ符号化デバイス又はピクチャ復号化デバイスを使用することができる。
【0186】
図14は、端末デバイス3106の一例の構成を示す図である。端末デバイス3106が捕捉デバイス3102からストリームを受信した後に、プロトコル処理ユニット3202は、ストリームの伝送プロトコルを分析する。プロトコルは、リアル・タイム・ストリーミング・プロトコル(RTSP)、ハイパーテキスト転送プロトコル(HTTP)、HTTPライブ・ストリーミング・プロトコル(HLS)、MPEG-DASH、リアル・タイム転送プロトコル(RTP)、リアル・タイム・メッセージング・プロトコル(RTMP)、又はそれらの任意の種類の組み合わせ等を含むが、これらに限定されない。
プロトコル処理ユニット3202がストリームを処理した後に、ストリーム・ファイルが生成される。ファイルは、逆多重化ユニット3204に出力される。逆多重化ユニット3204は、多重化されたデータを、符号化されたオーディオ・データ及び符号化されたビデオ・データに分離することができる。上述したように、幾つかの実際的なシナリオに関し、例えばビデオ会議システムにおいて、符号化されたオーディオ・データ及び符号化されたビデオ・データは多重化されない。この状況では、符号化されたデータは、逆多重化ユニット3204を介することなく、ビデオ・デコーダ3206及びオーディオ・デコーダ3208に送信される。
【0187】
逆多重化処理により、ビデオ要素ストリーム(ES)、オーディオES、及びオプションとして字幕が生成される。上述の実施形態で説明したようなビデオ・デコーダ30を含むビデオ・デコーダ3206は、上述の実施形態で示されるような復号化方法によってビデオESを復号化してビデオ・フレームを生成し、このデータを同期ユニット3212へ供給する。オーディオ・デコーダ3208は、オーディオESを復号化してオーディオ・フレームを生成し、このデータを同期ユニット3212へ供給する。代替的に、ビデオ・フレームは、それを同期ユニット3212へ供給する前に、バッファ(図14では示されていない)に格納されてもよい。同様に、オーディオ・フレームは、それを同期ユニット3212へ供給する前に、バッファ(図14では示されていない)に格納されてもよい。
【0188】
同期ユニット3212は、ビデオ・フレーム及びオーディオ・フレームを同期させ、ビデオ/オーディオをビデオ/オーディオ・ディスプレイ3214に供給する。例えば、同期ユニット3212は、ビデオ及びオーディオ情報の提示を同期させる。情報は、コーディングされたオーディオ及びビジュアル・データの提示に関するタイムスタンプとデータ・ストリーム自体の配信に関するタイムスタンプとを使用してシンタックスでコーディングしてもよい。
【0189】
字幕がストリームに含まれる場合、字幕デコーダ3210は、字幕を復号化し、それをビデオ・フレーム及びオーディオ・フレームと同期させ、ビデオ/オーディオ/字幕をビデオ/オーディオ/字幕ディスプレイ3216に供給する。
【0190】
数学演算子
本願で使用される数学演算子は、Cプログラミング言語で使用されるものに類似している。しかしながら、整数除算及び算術シフト演算の結果は、より精密に定義され、指数化や実数値除算のような追加的な演算が規定される。番号付け及び数え方の慣例は一般に0から始まり、例えば、「第1」は0番目と同等であり、「第2」は1番目と同等、等々である。
【0191】
算術演算子
以下の算術演算子は次のように規定される:
【表8】
【0192】
論理演算子
以下の論理演算子は次のように規定される:
x&&y x及びyのブール論理“and”
x||y x及びyのブール論理“or”
! ブール論理“not”
x?y:z xがTRUEであるか又は0に等しくない場合に、yの値を評価し;そうでなければzの値を評価する。
【0193】
関係演算子
以下の関係演算子は次のように規定される:
> より大きい
>= より大きい又は等しい
< より小さい
<= より小さい又は等しい
== に等しい
!= に等しくない
【0194】
関係演算子が、値“na”(適用可能でない)が指定されているシンタックス要素又は変数に適用される場合、値“na”はそのシンタックス要素又は変数の別個の値として扱われる。値“na”は他の如何なる値にも等しくないと考えられる。
【0195】
ビット・ワイズ演算子
以下のビット・ワイズ演算子は次のように規定される:
& ビット・ワイズ“and”。整数引数に作用する場合、整数値の2の補数表現に関して作用する。二進引数に作用する場合に、その二進引数が他の引数より少ないビットを含む場合、より短い引数は、0に等しい更なる上位ビットを加えることによって拡張される。
| ビット・ワイズ“or”。整数引数に作用する場合、整数値の2の補数表現に関して作用する。二進引数に作用する場合に、その二進引数が他の引数より少ないビットを含む場合、より短い引数は、0に等しい更なる上位ビットを加えることによって拡張される。
^ ビット・ワイズ“排他的or”。整数引数に作用する場合、整数値の2の補数表現に関して作用する。二進引数に作用する場合に、その二進引数が他の引数より少ないビットを含む場合、より短い引数は、0に等しい更なる上位ビットを加えることによって拡張される。
x>>y xの2の補数整数表現をyという二進数だけ算術右シフトしたもの。この関数はyの非負の整数値についてのみ定義される。右シフトの結果として最上位ビット(MSB)にシフトされたビットは、シフト操作前のxのMSBに等しい。
x<<y xの2の補数整数表現をyという二進数だけ算術左シフトしたもの。この関数はyの非負の整数値についてのみ定義される。左シフトの結果として最下位ビット(LSB)にシフトされたビットは、0に等しい値を有する。
【0196】
代入演算子
以下の算術演算子は次のように規定される:
= 代入演算子
++ インクリメント。即ち、x++はx=x+1に等しい。配列インデックスで使用される場合、インクリメント演算前の変数の値を評価する。
-- デクリメント。即ち、x--はx=x-1に等しい。配列インデックスで使用される場合、デクリメント演算前の変数の値を評価する。
+= 指定された量によるインクリメント。即ち、x+=3はx=x+3に等しい。x+=(-3)はx=x+(-3)に等しい。
-= 指定された量によるデクリメント。即ち、x-=3はx=x-3に等しい。x-=(-3)はx=x-(-3)に等しい。
【0197】
レンジ表記
以下の表記が値のレンジを指定するために使用される:
x=y..z xはyから始まってzまでの両端を含む整数値をとり、x,y,及びzは整数であり、zはyより大きい。
【0198】
数学的関数
以下の数学的関数が定義される:
【表9】
【0199】
演算優先順序
括弧を利用することによって表式で優先順位が明示的に指定されていない場合、以下のルールを適用する:
- より高い優先順位の演算は、より低い優先順位の如何なる演算よりも前に評価される。
- 同じ優先順位の演算は、左から右へ順に評価される。
【0200】
以下の表は、最高から最低までの演算の優先順位を示し、表の中でより高い位置は、より高い優先順位を示す。
【0201】
Cプログラミング言語でも使用されている演算子に関し、本明細書で使用される優先順位は、Cプログラミング言語で使用されるものと同じである。
表:最高(表の中で上)から最低(表の中で下)までの演算優先順位
【表10】
【0202】
論理演算子のテキスト記述
テキストにおいて、以下の形式:
if( condition 0 )
statement 0
else if( condition 1 )
statement 1
...
else /* informative remark on remaining condition */
statement n
で数学的に記述され得るような論理演算子のステートメントは、以下の方式で記述することが可能である:
... as follows / ... the following applies:
- If condition 0, statement 0
- Otherwise, if condition 1, statement 1
- ...
- Otherwise (informative remark on remaining condition), statement n
【0203】
テキストにおける各々の“If ... Otherwise, if ... Otherwise, ...”というステートメントは、“If...”の直後に続く“... as follows”又は“... the following applies”とともに導入される。“If ... Otherwise, if ... Otherwise, ...”の最後の条件は、常に“Otherwise, ...”である。交互の“If ... Otherwise, if ... Otherwise, ...”ステートメントは、“... as follows”又は“... the following applies”を末尾の“Otherwise, ...”に一致させることによって識別することが可能である。
【0204】
テキストにおいて、以下の形式:
if( condition 0a && condition 0b )
statement 0
else if( condition 1a || condition 1b )
statement 1
...
else
statement n
で数学的に記述され得るような論理演算子のステートメントは、以下の方式で記述することが可能である:
... as follows / ... the following applies:
- 以下の全ての条件がtrueであるならば、statement 0:
- condition 0a
- condition 0b
- それ以外の場合に、以下の条件のうちの1つ以上がtrueであるならば、statement 1:
- condition 1a
- condition 1b
- ...
- それ以外の場合に、statement n
【0205】
テキストにおいて、以下の形式:
if( condition 0 )
statement 0
if( condition 1 )
statement 1
で数学的に記述され得るような論理演算子のステートメントは、以下の方式で記述することが可能である:
condition 0である場合には、statement 0
condition 1である場合には、statement 1
【0206】
本発明の実施形態は、主にビデオ・コーディングに基づいて説明されているが、コーディング・システム10、エンコーダ20及びデコーダ30(及び対応するシステム10)の実施形態、並びに本願で説明される他の実施形態は、静止ピクチャ処理又はコーディング、即ちビデオ・コーディングにおけるように、任意の先行する又は連続するピクチャから独立した個々のピクチャの処理又はコーディング用に構成されてもよいことに留意すべきである。一般に、ピクチャ処理コーディングが単一のピクチャ17に限定されるケースでは、インター予測ユニット244(エンコーダ)及び344(デコーダ)だけは利用可能でない可能性がある。ビデオ・エンコーダ20及びビデオ・デコーダ30の他の全ての機能(ツール又は技術とも呼ばれる)は、静止ピクチャ処理、例えば、残差計算204/304、変換206、量子化208、逆量子化210/310、(逆)変換212/312、パーティショニング262/362、イントラ予測254/354、及び/又はループ・フィルタリング220、320、及びエントロピー符号化270及びエントロピー復号化304に等しく使用することができる。
【0207】
例えば、エンコーダ20及びデコーダ30の実施形態、並びに、例えばエンコーダ20及びデコーダ30に関連して本願で説明される機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせで実施されてもよい。ソフトウェアで実施される場合、機能は、1つ以上の命令又はコードとしてコンピュータ読み取り可能な媒体に記憶されるか又は通信媒体を介して伝送され、ハードウェア・ベースの処理ユニットによって実行されてもよい。コンピュータ読み取り可能な媒体は、データ記憶媒体のような有形媒体に対応するコンピュータ読み取り可能な記憶媒体、又は、例えば通信プロトコルに従ってある場所から他の場所へのコンピュータ・プログラムの転送に役立つ任意の媒体を含む通信媒体を含んでもよい。このように、コンピュータ読み取り可能な媒体は、一般に、(1)非一時的である有形のコンピュータ読み取り可能な記憶媒体、又は(2)信号又は搬送波のような通信媒体に対応する可能性がある。データ記憶媒体は、本開示で説明される技術の実施のための命令、コード及び/又はデータ構造を検索するために、1つ以上のコンピュータ又は1つ以上のプロセッサによってアクセスすることが可能な任意の利用可能な媒体である可能性がある。コンピュータ・プログラム製品は、コンピュータ読み取り可能な媒体を含むことが可能である。
【0208】
一例として、限定ではなく、このようなコンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、CD-ROM又は他の光ディスク・ストレージ、磁気ディスク・ストレージ、又は他の磁気ストレージ・デバイス、フラッシュ・メモリ、又は他の任意の媒体であって、命令又はデータ構造の形式で所望のプログラム・コードを記憶するために使用することが可能であり且つコンピュータによってアクセスすることが可能な他の任意の媒体を含むことが可能である。また、任意の接続は、コンピュータ読み取り可能な媒体と適切に言及される。例えば、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、デジタル加入者回線(DSL)、又は赤外線、無線、及びマイクロ波のような無線技術を用いて、ウェブサイト、サーバー、又は他のリモート・ソースから命令が送信される場合、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、DSL、又は赤外線、無線、及びマイクロ波のような無線技術は、媒体の定義に包含される。しかしながら、コンピュータ読み取り可能な記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時的な媒体を含まず、むしろ非一時的な有形の記憶媒体に関連していることが理解されるべきである。ディスク及びディスクは、本願で使用される場合、コンパクト・ディスク(CD)、レーザー・ディスク、光ディスク、デジタル多用途ディスク(DVD)、フロッピー・ディスク及びブルーレイ・ディスクを含み、ディスクは通常、データを磁気的に再生し、ディスクはレーザーでデータを光学的に再生する。上記の組み合わせもまた、コンピュータ読み取り可能な媒体の範囲内に包含されるべきである。
【0209】
命令は、1つ以上のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールド・プログラマブル論理アレイ(FPGA)、又は他の同等な集積された又は個別的な論理回路のような1つ以上のプロセッサによって実行することができる。従って、本願で使用される用語「プロセッサ」は、前述の構造の何れか、又は本願で説明される技術の実施に適した他の任意の構造を指す可能性がある。更に、幾つかの態様において、本願で説明される機能は、符号化及び復号化のために構成される専用ハードウェア及び/又はソフトウェア・モジュール内で提供されてもよく、又は組み合わされるコーデックに組み込まれてもよい。また、技術は1つ以上の回路又は論理素子で完全に実現することも可能である。
【0210】
本開示の技術は、ワイヤレス・ハンドセット、集積回路(IC)、又は一組のIC(例えば、チップ・セット)を含む、広範な種類のデバイス又は装置で実施することが可能である。開示される技術を実施するように構成されるデバイスの機能的側面を強調するために、本開示では、種々のコンポーネント、モジュール、又はユニットが説明されているが、必ずしも異なるハードウェア・ユニットによる実現を必要としてはいない。むしろ、上述したように、種々のユニットは、適切なソフトウェア及び/又はファームウェアと共に、コーデック・ハードウェア・ユニット内で組み合わされてもよいし、又は上述したような1つ以上のプロセッサを含む相互運用ハードウェア・ユニットの集まりによって提供されてもよい。