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

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

▶ ベイジン・ダジア・インターネット・インフォメーション・テクノロジー・カンパニー,リミテッドの特許一覧

特許7202444履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置
<>
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図1
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図2
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図3
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図4A
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図4B
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図4C
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図4D
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図5A
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図5B
  • 特許-履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置 図6
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-27
(45)【発行日】2023-01-11
(54)【発明の名称】履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置
(51)【国際特許分類】
   H04N 19/52 20140101AFI20221228BHJP
   H04N 19/436 20140101ALI20221228BHJP
   H04N 19/513 20140101ALI20221228BHJP
【FI】
H04N19/52
H04N19/436
H04N19/513
【請求項の数】 18
(21)【出願番号】P 2021504164
(86)(22)【出願日】2019-07-16
(65)【公表番号】
(43)【公表日】2021-09-13
(86)【国際出願番号】 US2019041923
(87)【国際公開番号】W WO2020018486
(87)【国際公開日】2020-01-23
【審査請求日】2021-01-22
【審判番号】
【審判請求日】2022-03-04
(31)【優先権主張番号】62/700,106
(32)【優先日】2018-07-18
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】521024075
【氏名又は名称】ベイジン・ダジア・インターネット・インフォメーション・テクノロジー・カンパニー,リミテッド
(74)【代理人】
【識別番号】100118902
【弁理士】
【氏名又は名称】山本 修
(74)【代理人】
【識別番号】100106208
【弁理士】
【氏名又は名称】宮前 徹
(74)【代理人】
【識別番号】100196508
【弁理士】
【氏名又は名称】松尾 淳一
(74)【代理人】
【識別番号】100147991
【弁理士】
【氏名又は名称】鳥居 健一
(74)【代理人】
【識別番号】100201743
【弁理士】
【氏名又は名称】井上 和真
(72)【発明者】
【氏名】ワーン,シアーンリン
(72)【発明者】
【氏名】チェン,イー-ウエン
【合議体】
【審判長】國分 直樹
【審判官】畑中 高行
【審判官】田中 啓介
(56)【参考文献】
【文献】ZHANG,Li et al., CE4-related: History-based Motion Vector Prediction, Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 11th Meeting: Ljubljana, SI, 10-18 July 2018, [JVET-K0104-v4], JVET-K0104(version4), ITU-T, 2018年07月14日, JVET-K0104_r3.docx: pp.1-6
【文献】CLARE, Gordon et al., Wavefront Parallel Processing for HEVC Encoding and Decoding, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 6th Meeting: Torino, IT, 14-22 July, 2011, [JCTVC-F274], JCTVC-F274(version 2), ITU-T, 2011年07月16日, JCTVC-F274.doc: pp.1-16
(58)【調査した分野】(Int.Cl.,DB名)
H04N19/00-19/98
(57)【特許請求の範囲】
【請求項1】
ビデオデータの復号方法であって、
複数の符号化ピクチャに関連したデータを含むビデオビットストリームを取得するステップであって、前記各符号化ピクチャが符号化ツリーユニット(CTU)行を複数含み、前記各CTUが1つ以上の符号化ユニット(CU)を含むステップと、
復号される現在のピクチャ内の現在のCTU行における先頭のCUを復号する前に、履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットするステップと
を備え、
前記現在のCTU行を復号する間に、
前記HMVPテーブル内の複数の動きベクトル予測子を整備するステップであって、前記HMVPテーブル内の前記各動きベクトル予測子が前記現在のCTU行の少なくとも1つのCUを復号するために使用されていたものであステップと、
復号対象となる前記現在のCTU行の現在のCUについて、
前記ビデオビットストリームの中から予測モードを抽出し、
前記予測モードに従い、前記HMVPテーブル内の前記複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成し、
前記動きベクトル候補リストから動きベクトル予測子を選択し、
前記現在のCUを復号するために、前記予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、
当該決定された動きベクトルに基づいて前記HMVPテーブルを更新するステップとを備える方法。
【請求項2】
請求項1に記載の方法であって、
当該決定された動きベクトルに基づいて前記HMVPテーブルを更新するステップは、
前記HMVPテーブル内の前記複数の動きベクトル予測子を、当該決定された動きベクトルと比較するステップと、
前記HMVPテーブル内の前記複数の動きベクトル予測子のいずれもが、当該決定された動きベクトルと同一ではないとの判定に応じて、
前記HMVPテーブルが限度一杯であるときは前記HMVPテーブルから最先の動きベクトル予測子を削除し、
当該決定された動きベクトルを最新の動きベクトルとして前記HMVPテーブルに追加するステップと、
前記HMVPテーブル内の前記複数の動きベクトル予測子のうちの1つが、当該決定された動きベクトルと同一であるとの判定に応じて、
前記同一である1つの動きベクトル予測子を前記HMVPテーブルから削除し、
当該削除された動きベクトル予測子の後の当該動きベクトル予測子の各々を、前記HMVPテーブル内で前方に移動させ、
当該決定された動きベクトルを最新の動きベクトルとして前記HMVPテーブルに追加するステップと
をさらに含む方法。
【請求項3】
請求項1に記載の方法であって、前記HMVPテーブルをリセットするステップは、前記HMVPテーブル内の利用可能な動きベクトル予測子の個数をゼロに設定するステップを含む、方法。
【請求項4】
請求項1に記載の方法であって、前記予測モードは、インターモード,マージモード,及びスキップモードからなる群から選択されたものである、方法。
【請求項5】
請求項4に記載の方法であって、
前記予測モードは、前記インターモードであり、
前記現在のCUを復号するステップは、
前記現在のCUについて、前記ビデオビットストリームから動きベクトル差分を再生するステップと、
記動きベクトル差分当該選択された動きベクトル予測子加算して、当該決定された動きベクトルを得るステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するCUとを用いて前記現在のCUを復号するステップと
をさらに含む、方法。
【請求項6】
請求項4に記載の方法であって、
前記予測モードは、前記インターモードであり、
前記動きベクトル候補リストを構成するステップは、
前記現在のCUに対して時間的に近隣のCU及び/又は時間的に連結するCUに由来するゼロ個以上の動きベクトル予測子を、前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの現在の長さが第1の所定しきい値に到達するまで、前記HMVPテーブルに由来するゼロ個以上の履歴ベースの動きベクトル予測子を前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの当該現在の長さが前記第1の所定しきい値と等しくなるまで、ゼロ個以上のゼロ値の動きベクトル予測子を前記動きベクトル候補リストに追加するステップと
をさらに含む、方法。
【請求項7】
請求項4に記載の方法であって、
前記予測モードは、前記マージモード及び前記スキップモードのうちの1つであり、
前記現在のCUを復号するステップは、
当該決定された動きベクトルとして、当該選択された動きベクトル予測子を使用するステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するCUとを用いて前記現在のCUを復号するステップと
をさらに含む、方法。
【請求項8】
請求項1に記載の方法であって、復号される前記現在のピクチャ内の2つ以上のCTU行が並列に復号され、前記各CTU行は、対応するCTU行を復号するために使用された複数の履歴ベースの動きベクトル予測子を格納するように関連付けられたHMVPテーブルを有する、方法。
【請求項9】
請求項1に記載の方法であって、復号される前記現在のピクチャ内の複数の異なるCTU行が複数の異なる関連スレッドを有するように、復号される前記現在のピクチャ内の当該現在のCTU行を復号することにスレッドを割り当てるステップをさらに備える方法。
【請求項10】
演算装置であって、
1つ以上のプロセッサと、
前記1つ以上のプロセッサに接続されたメモリと、
前記メモリに格納された複数のプログラムと
を備え、
前記複数のプログラムは、前記1つ以上のプロセッサにより実行されると、
複数の符号化ピクチャに関連したデータを含むビデオビットストリームを取得するステップであって、前記各符号化ピクチャが符号化ツリーユニット(CTU)行を複数含み、前記各CTUが1つ以上の符号化ユニット(CU)を含むステップと、
復号される現在のピクチャ内の現在のCTU行における先頭のCUを復号する前に、履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットするステップと
を含み、
前記現在のCTU行を復号する間に、
前記HMVPテーブル内の複数の動きベクトル予測子を整備するステップであって、前記HMVPテーブル内の前記各動きベクトル予測子が前記現在のCTU行の少なくとも1つのCUを復号するために使用されていたものであステップと、
復号対象となる前記現在のCTU行の現在のCUについて、
前記ビデオビットストリームの中から予測モードを抽出し、
前記予測モードに従い、前記HMVPテーブル内の前記複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成し、
前記動きベクトル候補リストから動きベクトル予測子を選択し、
前記現在のCUを復号するために、前記予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、
当該決定された動きベクトルに基づいて前記HMVPテーブルを更新するステップと
を含む処理を前記演算装置に実行させる、演算装置。
【請求項11】
請求項10に記載の演算装置であって、
当該決定された動きベクトルに基づいて前記HMVPテーブルを更新するステップは、
前記HMVPテーブル内の前記複数の動きベクトル予測子を、当該決定された動きベクトルと比較するステップと、
前記HMVPテーブル内の前記複数の動きベクトル予測子のいずれもが、当該決定された動きベクトルと同一ではないとの判定に応じて、
前記HMVPテーブルが限度一杯であるときは前記HMVPテーブルから最先の動きベクトル予測子を削除し、
当該決定された動きベクトルを最新の動きベクトルとして前記HMVPテーブルに追加するステップと、
前記HMVPテーブル内の前記複数の動きベクトル予測子のうちの1つが、当該決定された動きベクトルと同一であるとの判定に応じて、
前記同一である1つの動きベクトル予測子を前記HMVPテーブルから削除し、
当該削除された動きベクトル予測子の後の当該動きベクトル予測子の各々を、前記HMVPテーブル内で前方に移動させ、
当該決定された動きベクトルを最新の動きベクトルとして前記HMVPテーブルに追加するステップと
をさらに含む、演算装置。
【請求項12】
請求項10に記載の演算装置であって、前記予測モードは、インターモード,マージモード,及びスキップモードからなる群から選択されたものである、演算装置。
【請求項13】
請求項12に記載の演算装置であって、
前記予測モードは、前記インターモードであり、
前記現在のCUを復号するステップは、
前記現在のCUについて、前記ビデオビットストリームから動きベクトル差分を再生するステップと、
記動きベクトル差分当該選択された動きベクトル予測子加算して、当該決定された動きベクトルを得るステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するCUとを用いて前記現在のCUを復号するステップと
をさらに含む、演算装置。
【請求項14】
請求項12に記載の演算装置であって、
前記予測モードは、前記インターモードであり、
前記動きベクトル候補リストを構成するステップは、
前記現在のCUに対して時間的に近隣のCU及び/又は時間的に連結するCUに由来するゼロ個以上の動きベクトル予測子を、前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの現在の長さが第1の所定しきい値に到達するまで、前記HMVPテーブルに由来するゼロ個以上の履歴ベースの動きベクトル予測子を前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの当該現在の長さが前記第1の所定しきい値と等しくなるまで、ゼロ個以上のゼロ値の動きベクトル予測子を前記動きベクトル候補リストに追加するステップと
をさらに含む、演算装置。
【請求項15】
請求項12に記載の演算装置であって、
前記予測モードは、前記マージモード及び前記スキップモードのうちの1つであり、
前記現在のCUを復号するステップは、
当該決定された動きベクトルとして、当該選択された動きベクトル予測子を使用するステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するCUとを用いて前記現在のCUを復号するステップと
をさらに含む、演算装置。
【請求項16】
請求項10に記載の演算装置であって、復号される前記現在のピクチャ内の2つ以上のCTU行が並列に復号され、前記各CTU行は、対応するCTU行を復号するために使用された複数の履歴ベースの動きベクトル予測子を格納するように関連付けられたHMVPテーブルを有する、演算装置。
【請求項17】
1つ以上のプロセッサを有する演算装置による実行のために複数のプログラムを格納する非一時的なコンピュータ読み取り可能な記録媒体であって、
前記複数のプログラムは、前記1つ以上のプロセッサにより実行されると、
複数の符号化ピクチャに関連したデータを含むビデオビットストリームを取得するステップであって、前記各符号化ピクチャが符号化ツリーユニット(CTU)行を複数含み、前記各CTUが1つ以上の符号化ユニット(CU)を含むステップと、
復号される現在のピクチャ内の現在のCTU行における先頭のCUを復号する前に、履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットするステップと
を含み、
前記現在のCTU行を復号する間に、
前記HMVPテーブル内の複数の動きベクトル予測子を整備するステップであって、前記HMVPテーブル内の前記各動きベクトル予測子が前記現在のCTU行の少なくとも1つのCUを復号するために使用されていたものであステップと、
復号対象となる前記現在のCTU行の現在のCUについて、
前記ビデオビットストリームの中から予測モードを抽出し、
前記予測モードに従い、前記HMVPテーブル内の前記複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成し、
前記動きベクトル候補リストから動きベクトル予測子を選択し、
前記現在のCUを復号するために、前記予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、
当該決定された動きベクトルに基づいて前記HMVPテーブルを更新するステップとを含む処理を前記演算装置に実行させる、非一時的なコンピュータ読み取り可能な記録媒体。
【請求項18】
1つ以上のプロセッサを有する演算装置による実行のためコンピュータプログラムであって、前記コンピュータプログラムは、前記1つ以上のプロセッサにより実行されると、請求項1からのうちのいずれか1項に記載の方法のステップを前記演算装置に実行させる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]本出願は、概してビデオデータの符号化及び復号に関し、特に、履歴ベースの動きベクトル予測を用いるビデオコーディング方法及びシステムに関するものである。
【背景技術】
【0002】
[0002]デジタルビデオは、デジタルテレビ、ラップトップ型又はデスクトップ型のコンピュータ、タブレット型コンピュータ、デジタルカメラ、デジタル記録装置、デジタルメディア再生装置、ビデオゲーム端末、スマートフォン、ビデオ会議装置、ビデオストリーミング装置といった種々の電子デバイスによってサポートされている。そのような電子デバイスは、MPEG-4、ITU-TH.263、ITU-T H.264/MPEG-4Part 10 AVC(Advanced Video Coding)、HEVC(高能率映像符号化:High Efficiency Video Coding)、VVC(Versatile Video Coding)規格などで定められたビデオ圧縮伸張規格を実装することにより、デジタルビデオデータの送信、受信、符号化、復号、及び/又は格納を行う。一般にビデオ圧縮は、空間(フレーム内)予測及び/又は時間(フレーム間)予測を実行してビデオデータに内在する冗長性を低減又は除去する手順を含む。ブロックベースのビデオコーディングでは、ビデオフレームは1つ以上のスライスに分割され、各スライスは複数のビデオブロックを有し、ビデオブロックは符号化ツリーユニット(CTU:coding tree unit)とも呼ばれうる。各CTUは、1つの符号化ユニット(CU:coding unit)を含むものでもよいし、あるいは、予め定められた最小のCUサイズに到達するまで、より小さな複数のCUに再帰的に分割されてもよい。各CU(リーフCUとも呼ばれる。)は単数又は複数の変換ユニット(TU:transform unit)を含み、また各CUは単数又は複数の予測ユニット(PU:prediction unit)を含む。各CUは、イントラモード、インターモード又はIBCモードのいずれかで符号化されうる。ビデオフレームにおけるイントラ符号化(I)スライス内の複数のビデオブロックは、同じビデオフレーム内の近隣ブロックの参照サンプルに対して空間予測を用いて符号化される。ビデオフレームにおけるインター符号化(P又はB)スライス内の複数のビデオブロックは、同じビデオフレーム内の近隣ブロックの参照サンプルに対して空間予測を用いたものでもよいし、あるいは、過去及び/又は未来における別の参照ビデオフレームの参照サンプルに対して時間予測を用いたものでもよい。
【0003】
[0003]過去に符号化された参照ブロック(たとえば近隣ブロック)に基づく空間予測又は時間予測を実行すれば、符号化対象の現在のビデオブロックに対する予測ブロックが得られる。当該参照ブロックを探し出す処理は、ブロックマッチングアルゴリズムにより実行されればよい。符号化対象の現在のブロックと予測ブロックとの間の画素の差分を示す残差データを残差ブロック又は予測誤差と呼ぶ。インター符号化ブロックは、当該予測ブロックを形成する参照フレームを指す動きベクトルと残差ブロックとに従って符号化されたものである。動きベクトルを決定する処理は、一般に、動き推定と呼ばれている。イントラ符号化ブロックは、イントラ予測モードと残差ブロックとに従って符号化されたものである。さらなる圧縮のために、残差ブロックを画素領域から変換領域(たとえば周波数領域)へ変換することで残差変換係数が得られ、次にこれらは量子化される。量子化変換係数は、先ずは2次元配置で配列されており、これを走査して複数の変換係数からなる1次元ベクトルを生成し、次いで、さらなる圧縮を実現するためにエントロピー符号化を実行してビデオストリームを得てもよい。
【0004】
[0004]次に、その符号化ビデオストリームは、デジタルビデオ機能をもつ他の電子デバイスによりアクセスされるコンピュータ読み取り可能な記録媒体(たとえばフラッシュメモリ)に記録されるか、あるいは、有線又は無線でその電子デバイスに直接送信される。当該電子デバイスは、次いで、たとえば当該符号化ビットストリームを解析してそのビットストリームからシンタックス要素を取得し、そのビットストリームから得た当該シンタックス要素の少なくとも一部に基づいて、当該符号化ビットストリームから元のフォーマットへデジタルビデオデータを再構成することにより(上記ビデオ圧縮とは逆の処理である)ビデオ伸張を実行し、そして、当該再構成されたデジタルビデオデータを当該電子デバイスのディスプレイに描画する。
【0005】
[0005]デジタルビデオ品質がハイビジョン(High Definition)から4K×2K又は8K×4Kに移行するにつれて、符号化/復号対象のビデオデータ量が指数関数的に増大する。復号ビデオデータの画質を維持しつつ、いかにしてビデオデータがより効率的に符号化/復号できるかという点での絶え間ない努力がある。
【発明の概要】
【0006】
[0006]本出願は、ビデオデータの符号化及び復号に関し、特に、履歴ベースの動きベクトル予測を用いたビデオ符号化及び復号の際におけるビデオデータの並列処理のシステム及び方法に関する実施形態について説明するものである。
【0007】
[0007]本出願の第1の態様によるビデオデータの復号方法は、1つ以上のプロセッサと、当該1つ以上のプロセッサにより実行される複数のプログラムを格納するメモリとを有する演算装置で実施される。ビデオビットストリームを取得した後、演算装置は、そのビデオビットストリームから複数の符号化ピクチャに関連したデータを抽出することから始める。各ピクチャは、符号化ツリーユニット(CTU)行を複数含み、各CTUは、1つ以上の符号化ユニット(CU)を含む。復号される現在のCTU行の先頭のCUを復号することを開始する前に、演算装置は、履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットする。次いで、現在のCTU行を復号する間は、演算装置は、HMVPテーブル内の複数の動きベクトル予測子を整備する。各動きベクトル予測子は、少なくとも1つのCUを復号するために使用されたものである。復号対象となる現在のCTU行の現在のCUについて、演算装置は、ビデオビットストリームから予測モードを抽出し、当該予測モードに従い、HMVPテーブル内の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成する。動きベクトル候補リストから動きベクトル予測子を選択した後は、演算装置は、当該予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、当該決定された動きベクトルを用いて現在のCUを復号し、当該決定された動きベクトルに基づいてHMVPテーブルを更新する。
【0008】
[0008]本出願の第2の態様による演算装置は、1つ以上のプロセッサと、メモリと、当該メモリに格納された複数のプログラムとを含む。そのプログラムは、1つ以上のプロセッサにより実行されると、上記した処理を演算装置に実行させる。
【0009】
[0009]本出願の第3の態様による非一時的なコンピュータ読み取り可能な記録媒体は、1つ以上のプロセッサを有する演算装置による実行のための複数のプログラムを格納する。そのプログラムは、1つ以上のプロセッサにより実行されると、上記した処理を演算装置に実行させる。
【0010】
[0010]添付図面は、実施形態のさらなる理解を与えるべく含められ、かつ本願に組み入れられたものであり、本明細書の一部を構成し、説明される実施形態を図示し、その説明とともにその基礎をなす原理を説明する役目を果たすものである。対応する構成要素には、同じ参照符号が付されている。
【図面の簡単な説明】
【0011】
図1】[0011]図1は、本開示のいくつかの実施形態に係るビデオ符号化・復号システムの例を示すブロック図である。
図2】[0012]図2は、本開示のいくつかの実施形態に係るビデオ符号化器の例を示すブロック図である。
図3】[0013]図3は、本開示のいくつかの実施形態に係るビデオ復号器の例を示すブロック図である。
図4A】[0014]図4A図4Dは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。
図4B】[0014]図4A図4Dは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。
図4C】[0014]図4A図4Dは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。
図4D】[0014]図4A図4Dは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。
図5A】[0015]図5Aは、本開示のいくつかの実施形態に従って、符号化対象である現在のCUに対して空間的に近隣でかつ時間的に連結するブロック位置を示すブロック図である。
図5B】[0016]図5Bは、本開示のいくつかの実施形態に従って、波面並列処理を用いてピクチャ内の複数のCTU行をマルチスレッド符号化することを示すブロック図である。
図6】[0017]図6は、本開示のいくつかの実施形態に従って、動きベクトル予測子の候補リストを構成する技術を実現するビデオコーダによる処理例を示すフローチャートである。
【発明を実施するための形態】
【0012】
[0018]具体的な実施形態について以下に詳細に言及し、当該実施の形態の例を添付図面に示す。以下の詳細な説明においては、本明細書で示される主題を理解する助けとなるように、限定されない多くの具体的に詳細な内容が示されている。ただし、請求項の範囲から逸脱せずに種々の変形例が使用されうること、並びに、それら具体的に詳細な内容がなくとも主題が実施されうることは、当業者であれば明らかであろう。たとえば、本明細書に示される主題が、デジタルビデオ機能をもつ種々の電子デバイスにて実現可能であることは、当業者であれば明らかであろう。
【0013】
[0019]図1は、本開示のいくつかの実施形態に従い、ビデオブロックを並列に符号化し復号するための例示的なシステム10を示すブロック図である。図1に示されるようにシステム10は、後の時点で送信先(デスティネーション)装置14で復号されることとなるビデオデータを生成し符号化する情報源(ソース)装置12を備えている。情報源装置12及び送信先装置14は、デスクトップ型もしくはラップトップ型のコンピュータ,タブレット型コンピュータ,スマートフォン,セットトップボックス,デジタルテレビジョン,カメラ,表示装置,デジタルメディア再生装置,ビデオゲーム端末,又はビデオストリーミング装置などを含む幅広い種類の任意の電子デバイスを備えてよい。いくつかの実施形態では、情報源装置12及び送信先装置14は無線通信機能を搭載している。
【0014】
[0020]いくつかの実施形態では、送信先装置14は、復号されることとなる符号化ビデオデータをリンク16を介して受信してよい。リンク16は、情報源装置12から送信先装置14に符号化ビデオデータを転送する任意の種類の通信媒体又はデバイスを備えてよい。1つの例として、リンク16は、情報源装置12がリアルタイムに符号化ビデオデータを送信先装置14に直接送信することを可能とする通信媒体を備えてよい。符号化ビデオデータは、無線通信プロトコルなどの通信規格に従って変調されて送信先装置14に送信されてもよい。当該通信媒体は、無線周波数(RF)又は1つ以上の物理的な送信ラインといった任意の無線又は有線の通信媒体を備えてよい。当該通信媒体は、ローカルエリアネットワーク,広域ネットワーク,又はインターネットなどのグルーバルネットワークといった、パケットベースのネットワークの一部を構成するものでもよい。当該通信媒体は、情報源装置12から送信先装置14への通信を実現するために使用される、ルータ,スイッチ,基地局又はその他の機器を含んでもよい。
【0015】
[0021]他のいくつかの実施形態では、符号化ビデオデータは、出力インタフェース22から記録装置32に送信されてもよい。その後、記録装置32内の当該符号化ビデオデータは、入力インタフェース28を介して送信先装置14によりアクセスされてよい。記録装置32は、符号化ビデオデータを記録するために、ハードドライブ(hard drive),ブルーレイディスク,DVD,CD-ROM,フラッシュメモリ,揮発性もしくは不揮発性のメモリ,又はその他任意の適当なデジタル記録媒体などの、分散化された又はローカルにアクセスされた任意の種々のデータ記録媒体を含んでよい。さらに他の例としては、記録装置32は、情報源装置12で生成された符号化ビデオデータを保持しうるファイルサーバ又は他の中間記録装置に相当するものでもよい。送信先装置14は、記録装置32からのストリーミング又はダウンロードを通じて記録済みビデオデータにアクセスしてもよい。ファイルサーバは、符号化ビデオデータを格納して当該符号化ビデオデータを送信先装置14に送信する機能をもつ任意の種類のコンピュータであってよい。ファイルサーバの例には、(たとえばウェブサイト用の)ウェブサーバ,FTPサーバ,ネットワーク接続ストレージ(NAS:network attached storage)装置,又はローカルディスクドライブが含まれる。送信先装置14は、無線チャネル(たとえばWi-Fi接続),有線接続(たとえばDSLやケーブル媒体など),又はこれら両方の組合せを含むような、ファイルサーバに記録された符号化ビデオデータへのアクセスに適した任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスしうる。記録装置32からの符号化ビデオデータの送信は、ストリーミング送信,ダウンロード送信,又はこれら両方の組合せであってよい。
【0016】
[0022]図1に示されるように情報源装置12は、ビデオ源18,ビデオ符号化器20及び出力インタフェース22を含む。ビデオ源18は、たとえば、ビデオカメラ,過去に取得されたビデオを格納するビデオアーカイブ,ビデオコンテンツプロバイダからビデオを受信するビデオ供給インタフェース,及び/又は,情報源のビデオとしてコンピュータグラフィックスを生成するコンピュータグラフィックスシステムといったビデオキャプチャ装置などの情報源(ソース)を含んでいればよい。一例として、ビデオ源18が安全監視システムのビデオカメラであるとき、情報源装置12及び送信先装置14は、カメラ電話機又はビデオ電話機を構成してもよい。ただし、本出願で説明される実施形態は、一般にビデオコーディングに適用可能なものであればよく、無線及び/又は有線の用途に適用されればよい。
【0017】
[0023]そのように取得もしくは以前に取得され、又はコンピュータで生成されたビデオは、ビデオ符号化器20により符号化されうる。その符号化ビデオデータは、情報源装置12の出力インタフェース22を通じて送信先装置14に直接送信されればよい。また(又はその代わりに)その符号化ビデオデータは、送信先装置14又はその他の装置からの後のアクセスのため、復号及び/又は再生のために記録装置32に記録されればよい。さらに出力インタフェース22は、モデム及び/又は送信器を含んでもよい。
【0018】
[0024]送信先装置14は、入力インタフェース28,ビデオ復号器30及び表示装置34を含む。入力インタフェース28は、受信器及び/又はモデムを含んでリンク16を介して符号化ビデオデータを受信してもよい。リンク16を介して通信された符号化ビデオデータ、又は、記録装置32で供給された符号化ビデオデータは、ビデオ符号化器20により生成された各種のシンタックス要素を、ビデオ復号器30でのビデオデータの復号に使用するために含んでいてもよい。そのようなシンタックス要素は、通信媒体で送信された符号化ビデオデータ内に組み込まれ、記録媒体に記録され、あるいはファイルサーバに記録されればよい。
【0019】
[0025]いくつかの実施形態では、送信先装置14は表示装置34を含んでもよく、この表示装置34は、統合型の表示装置や、送信先装置14と通信するように構成された外部表示装置とすることができる。表示装置34は、復号されたビデオデータをユーザに表示するものであり、液晶表示ディスプレイ(LCD:liquid crystal display),プラズマディスプレイ,有機発光ダイオード(OLED)ディスプレイ,又は他タイプの表示装置など、種々の任意の表示装置を備えたものであればよい。
【0020】
[0026]ビデオ符号化器20及びビデオ復号器30は、VVC,HEVC,MPEG-4 Part10 AVC(Advanced Video Coding),又はこれらの規格の拡張版など、知的所有物又は業界規格に基づいて動作すればよい。本出願は、特定のビデオ符号化/復号規格に限定されるものではなく、他のビデオ符号化/復号規格に適用可能であってよいことを理解すべきである。情報源装置12のビデオ符号化器20が現在又は将来の規格のいずれかに従ってビデオデータを符号化するように構成されてよいことが、通常考えられることである。同様に、送信先装置14のビデオ復号器30が現在又は将来の規格のいずれかに従ってビデオデータを復号するように構成されてよいことも、通常考えられることである。
【0021】
[0027]ビデオ符号化器20及びビデオ復号器30は、それぞれ、1つ以上のマイクロプロセッサ,デジタル信号プロセッサ(DSP:digital signal processor),特定用途向け集積回路(ASIC:application specific integrated circuit),フィールドプログラマブルゲートアレイ(FPGA:field programmable gate array),ディスクリートロジック(個別論理回路:discrete logic),ソフトウェア,ハードウェア,ファームウェア,又はこれらの組合せといった種々の任意の適切な符号化回路として実現されればよい。ソフトウェアで部分的に実現される場合には、電子デバイスは、適切な非一時型のコンピュータ読み取り可能な媒体に当該ソフトウェア用の命令を格納し、1つ以上のプロセッサを用いたハードウェアで当該命令を実行して本開示に開示されたビデオ符号化/復号処理を実行すればよい。ビデオ符号化器20及びビデオ復号器30の各々は、1つ以上の符号化器又は復号器に組み込まれたものでよく、当該符号化器又は復号器のどちらかが複合型の符号化器/復号器(CODEC)の一部として各装置に統合されていればよい。
【0022】
[0028]図2は、本出願で説明されるいくつかの実施形態に係る例示的なビデオ符号化器20を示すブロック図である。ビデオ符号化器20は、ビデオフレーム内におけるビデオブロックのイントラ予測符号化及びインター予測符号化を実行しうる。イントラ予測符号化は、所与のビデオフレーム又はピクチャ内のビデオデータの空間的な冗長度を低減又は除去するために空間予測に依存する。インター予測符号化は、ビデオシーケンスの隣接するビデオフレーム又はピクチャ内のビデオデータの時間的な冗長度を低減又は除去するために時間予測に依存する。
【0023】
[0029]図2に示されるようにビデオ符号化器20は、ビデオデータメモリ40,予測処理部41,復号ピクチャバッファ(DPB:decoded picture buffer)64,加算器50,変換処理部52,量子化部54及びエントロピー符号化部56を含む。予測処理部41は、動き推定部42,動き補償部44,分割部45,イントラ予測処理部46及びイントラブロックコピー(BC)部48を含む。いくつかの実施形態では、ビデオ符号化器20は、さらにビデオブロックの再構成のために、逆量子化部58,逆変換処理部60及び加算器62を含む。再構成されたビデオからブロック歪を除去するために加算器62とDPB64との間にデブロッキングフィルタ(図示せず)が配置されればよい。デブロッキングフィルタに加えて、加算器62の出力をフィルタリングするためにループ内フィルタ(図示せず)が使用されてもよい。ビデオ符号化器20は、変更不能な又はプログラマブルなハードウェアユニットの形態を有していてよいし、あるいは、図示されるような1つ以上の変更不能な又はプログラマブルなハードウェアユニットのうちに分割されていてもよい。
【0024】
[0030]ビデオデータメモリ40は、ビデオ符号化器20の構成要素で符号化されるべきビデオデータを格納すればよい。ビデオデータメモリ40内のビデオデータは、たとえばビデオ源18から取得されればよい。DPB64は、ビデオ符号化器20でビデオデータを符号化する際に使用される参照ビデオデータを格納するバッファである。ビデオデータメモリ40及びDPB64は、任意の種々のメモリデバイスで構成されていればよい。種々の例において、ビデオデータメモリ40は、ビデオ符号化器20の他の構成要素とともにチップに実装されてよいし、あるいは、他の構成要素に対してチップ外に実装されてよい。
【0025】
[0031]図2に示されるように、ビデオデータの受信後、予測処理部41内の分割部45は、当該ビデオデータを複数のビデオブロックに分割する。この分割には、当該ビデオデータに関連付けられた四分木構造などの所定の分割構造に従って、ビデオフレームを複数のスライス又はより大きな複数の符号化ユニット(CU)に分割することが含まれてもよい。ビデオフレームは、複数のビデオブロック(又は、タイルと称されるビデオブロックの複数組)に分割されればよい。予測処理部41は、エラー結果(たとえば、符号化レート及び歪みレベル)に基づいて、現在のビデオブロックに対し、複数のイントラ予測符号化モードのうちの1つ又は複数のインター予測符号化モードのうちの1つなどの、選択可能な複数の予測符号化モードのうちの1つを選択すればよい。予測処理部41は、得られたイントラ予測符号化ブロック又はインター予測符号化ブロックを加算器50に供給して残差ブロックを生成させるとともに、加算器62にも供給して後に参照フレームの一部として使用される符号化ブロックを再構成させればよい。また予測処理部41は、動きベクトル,イントラモード予測子,分割情報及びその他のシンタックス情報といったシンタックス要素をエントロピー符号化部56に供給する。
【0026】
[0032]現在のビデオブロックについて適切なイントラ予測符号化モードを選択するために、予測処理部41内のイントラ予測処理部46は、符号化対象となる現在のブロックと同じフレーム内の1つ以上の近隣ブロックに対して現在のビデオブロックのイントラ予測符号化を実行して空間予測を提供すればよい。予測処理部41内の動き推定部42及び動き補償部44は、1つ以上の参照フレーム内の1つ以上の予測ブロックに対して現在のビデオブロックのインター予測符号化を実行して時間予測を提供する。ビデオ符号化器20は、たとえばビデオデータの各ブロックについて適切な符号化モードを選択するために、複数の符号化手順を実行してよい。
【0027】
[0033]いくつかの実施形態では、動き推定部42は、ビデオフレームのシーケンス内の所定パターンに従って、参照フレーム内の予測ブロックに対する現在のビデオフレーム内のビデオブロックの予測ユニット(PU)の位置ずれを示す動きベクトルを生成することにより、現在のビデオフレームについてのインター予測符号化モードを決定する。動き推定は、動き推定部42によって実行されるものであり、ビデオブロックについての動きを推定する動きベクトルを生成する処理である。動きベクトルは、たとえば、現在のフレーム内(又は他の符号化ユニット内)の符号化される現在のブロックに対して、参照フレーム内(又は他の符号化ユニット内)の予測ブロックに対する現在のビデオフレーム又はピクチャ内のビデオブロックのPUの位置ずれを示すものでよい。上記所定パターンは、当該シーケンス内の複数のビデオフレームをPフレーム又はBフレームとして指定するものであればよい。イントラBC部48は、インター予測についての動き推定部42による動きベクトルの決定と同様に、イントラBC符号化について、たとえばブロックベクトルなどのベクトルを決定すればよく、あるいは、動き推定部42を用いて当該ブロックベクトルを決定すればよい。
【0028】
[0034]予測ブロックは、画素差分の観点から、符号化対象となるビデオブロックのPUと密接に対応するものとみなされる参照フレームのブロックであり、差分絶対値和(SAD:sum of absolute difference),差分二乗和(SSD:sum of square difference)又はその他の差分基準量により決定されるものでよい。いくつかの実施形態では、ビデオ符号化器20は、DPB64に格納されている参照フレームのサブ整数型画素位置についての値を計算すればよい。たとえば、ビデオ符号化器20は、参照フレームの1/4画素位置,1/8画素位置又はその他の分数画素位置の値を補間すればよい。したがって、動き推定部42は、全体の画素位置及び分数画素位置に対する動き検索を実行して、分数画素精度の動きベクトルを出力すればよい。
【0029】
[0035]動き推定部42は、インター予測符号化フレーム内のビデオブロックのPUについて、第1の参照フレームリスト(リスト0)又は第2の参照フレームリスト(リスト1)から選択された参照フレームの予測ブロックの位置と当該PUの位置とを比較することにより動きベクトルを算出する。ここで、第1の参照フレームリスト又は第2の参照フレームリストはそれぞれDPB64に格納されている1つ以上の参照フレームを特定するものである。動き推定部42は、当該算出された動きベクトルを動き補償部44に転送し、次いでエントロピー符号化部56に転送する。
【0030】
[0036]動き補償は、動き補償部44により実行されるものであり、動き推定部42で決定された動きベクトルに基づいて予測ブロックを取り込む(フェッチ)又は生成することを含みうる。現在のビデオブロックのPUについての動きベクトルを受け取ると、動き補償部44は、複数の参照フレームリストのうちの1つのリストで当該動きベクトルが指し示す予測ブロックを見つけ出し、当該予測ブロックを取得し、そして当該予測ブロックを加算器50に送る。次いで加算器50は、符号化される現在のビデオブロックの画素値から、動き補償部44から供給された予測ブロックの画素値を減算することにより画素差分値からなる残差ビデオブロックを構成する。残差ビデオブロックを構成する画素差分値は、輝度(luma)差分成分もしくは色差(chroma)差分成分,又はこれらの両方を含むものでよい。また動き補償部44は、ビデオ復号器30でビデオフレームのビデオブロックを復号する際に使用するために、ビデオフレームのビデオブロックに関連付けられたシンタックス要素を生成すればよい。シンタックス要素は、たとえば、予測ブロックを特定するために使用された予測ベクトル,当該予測モードを示す何らかのフラグ,又は本明細書で説明される何らかの他のシンタックス情報を定めたシンタックス要素を含んでいればよい。動き推定部42及び動き補償部44は高度に統合されてよいが、概念目的のために分離されて図示されている点に留意すべきである。
【0031】
[0037]いくつかの実施形態では、イントラBC部48は、動き推定部42及び動き補償部44に関して上述した場合と同様の方法でベクトルの生成と予測ブロックの取り込み(フェッチ)とを行ってよいが、ここで、当該予測ブロックは、符号化される現在のブロックと同じフレーム内に存在し、当該ベクトルは、動きベクトルとは逆向きのブロックベクトルとみなされる。特に、イントラBC部48は、現在のブロックを符号化するように使用するためのイントラ予測モードを決定してよい。いくつかの例では、イントラBC部48は、たとえば別々の符号化手順で、種々のイントラ予測モードを用いて現在のブロックを符号化すればよく、レート歪み解析によりそれらの性能を評価すればよい。次に、イントラBC部48は、種々の評価済みのイントラ予測モードの中から、使用するイントラモード予測子を生成するために適切なイントラ予測モードを選択すればよい。たとえば、イントラBC部48は、当該種々の評価済みのイントラ予測モードに対するレート歪み解析を用いてレート歪み値を算出してよく、当該評価済みのモードの中から、使用する適切なイントラ予測モードとして最高のレート歪み特性を有するイントラ予測モードを選択すればよい。レート歪み解析は、一般に、符号化ブロックと、当該符号化ブロックを生成するために符号化された符号化前の元のブロックとの間の歪み(又は誤差)量とともに、これら符号化ブロックを生成するために使用されたビットレート(すなわち、多数のビット)を決定する。イントラBC部48は、どのイントラ予測モードが当該ブロックについて最高のレート歪み値を示すのかを決定するために、当該歪みから割合を算出し、当該種々の符号化ブロックについてのレートを算出する。
【0032】
[0038]他の例では、イントラBC部48は、本明細書で説明される実施形態に従ってイントラBC予測用のそのような機能を実行するために、動き推定部42及び動き補償部44の全部又は一部を使用してよい。いずれのケースでも、イントラブロックコピーについて予測ブロックは、画素差分の観点から、符号化対象となるブロックと密接に対応するものとみなされるブロックであればよく、差分絶対値和(SAD),差分二乗和(SSD)又はその他の差分基準量により決定されるものでよい。そして予測ブロックの特定には、サブ整数型の画素位置に関する値の算出が含まれればよい。
【0033】
[0039]予測ブロックがイントラ予測に従って同一フレームから得られたか、あるいはインター予測に従って異なるフレームから得られたかどうか、ビデオ符号化器20は、符号化される現在のビデオブロックの画素値から予測ブロックの画素値を減算して画素差分値を構成することにより、残差ビデオブロックを構成すればよい。残差ビデオブロックを構成する画素差分値は、輝度(luma)成分の差分及び色差(chroma)成分の差分を含むものでよい。
【0034】
[0040]イントラ予測処理部46は、上記したような動き推定部42及び動き補償部44により実行されるインター予測、又はイントラBC部48により実行されるイントラブロックコピー予測に代わるものとして、現在のビデオブロックのイントラ予測を行ってもよい。特に、イントラ予測処理部46は、現在のブロックを符号化するために使用するイントラ予測モードを決定すればよい。このようにするために、イントラ予測処理部46は、たとえば別々の符号化手順で、種々のイントラ予測モードを用いて現在のブロックを符号化すればよく、イントラ予測処理部46(又は、いくつかの例ではモード選択部)は、評価済みのイントラ予測モードの中から、使用する適切なイントラ予測モードを選択すればよい。イントラ予測処理部46は、当該ブロックについて選択されたイントラ予測モードを示す情報をエントロピー符号化部56に供給すればよい。エントロピー符号化部56は、当該選択されたイントラ予測モードを示す情報をビットストリーム内に符号化すればよい。
【0035】
[0041]予測処理部41が現在のビデオブロックについてインター予測又はイントラ予測のいずれかで予測ブロックを決定した後、加算器50は、当該現在のビデオブロックから当該予測ブロックを減算することで残差ビデオブロックを構成する。その残差ブロック内の残差ビデオデータは、1つ以上の変換ユニット(TU)内に組み込まれてよく、変換処理部52に供給される。変換処理部52は、離散コサイン変換(DCT:discrete cosine transform)又は概念的に同様の変換などの変換を用いて、残差ビデオデータを残差変換係数に変換する。
【0036】
[0042]変換処理部52は、残差変換係数を量子化部54に転送する。量子化部54は、さらにビットレートを低減するために変換係数を量子化する。その量子化処理では、当該係数の一部又は全部に関するビット深さが削減されてもよい。その量子化度は、量子化パラメータを調整することで変更されてよい。いくつかの例では、次に量子化部54は、量子化変換係数を含むマトリクスに対する走査を実行すればよい。あるいは、エントロピー符号化部56がその走査を実行してもよい。
【0037】
[0043]量子化に続いて、エントロピー符号化部56は、たとえば、コンテキスト適応型可変長符号化(CAVLC:context adaptive variable length coding),コンテキスト適応型2値算術符号化(CABAC:context adaptive binary arithmetic coding),シンタックスベースコンテクスト適応型2値算術符号化(SBAC:syntax-based context-adaptive binary arithmetic coding),確率区間区分エントロピー符号化(PIPE:probability interval partitioning entropy coding)、もしくはその他のエントロピー符号化の方法論又は技術を用いて、量子化変換係数にエントロピー符号化を施してビデオビットストリームを得る。その後、符号化ビットストリームは、ビデオ復号器30に送信されるか、あるいは、後にビデオ復号器30に送信または取得されるように記録装置32に記録されればよい。エントロピー符号化部56は、動きベクトルと、符号化される現在のビデオフレームに関する他のシンタックス要素とにエントロピー符号化を施してもよい。
【0038】
[0044]逆量子化部58及び逆変換処理部60は、それぞれ逆量子化及び逆変換を適用して、他のビデオブロックの予測用の参照ブロックを生成するために画素領域で残差ビデオブロックを再構成する。上記のとおり、動き補償部44は、DPB64に格納されているフレームの1つ以上の参照ブロックから、動き補償された予測ブロックを生成すればよい。動き補償部44は、動き補償に使用されるサブ整数型の画素値を算出するために、1つ以上の補間フィルタを予測ブロックに適用してもよい。
【0039】
[0045]加算器62は、再構成された残差ブロックを、動き補償部44で生成された動き補償された予測ブロックに加算して参照ブロックを生成しこれをDPB64に格納する。次に、その参照ブロックは、後続のビデオフレーム内の他のビデオブロックにインター予測を行うための予測ブロックとして、イントラBC部48,動き推定部42及び動き補償部44で使用されればよい。
【0040】
[0046]図3は、本出願のいくつかの実施形態に係るビデオ復号器30を例示するブロック図である。ビデオ復号器30は、ビデオデータメモリ79,エントロピー復号部80,予測処理部81,逆量子化部86,逆変換処理部88,加算器90及びDPB92を含む。さらに予測処理部81は、動き補償部82,イントラ予測処理部84及びイントラBC部85を含む。ビデオ復号器30は、図2関連のビデオ符号化器20に関して上述した符号化処理に対して一般に逆の復号処理を実行すればよい。たとえば、動き補償部82は、エントロピー復号部80から取得された動きベクトルに基づいて予測データを生成すればよく、その一方でイントラ予測処理部84は、エントロピー復号部80から取得されたイントラ予測モードインジケータに基づいて予測データを生成すればよい。
【0041】
[0047]いくつかの例では、ビデオ復号器30内の1つのユニットが、本出願の実施形態を実施するためのタスクの割り当てを受けてよい。いくつかの例では、本開示の実施形態は、ビデオ復号器30内の1つ以上のユニットに分割されてもよい。たとえば、イントラBC部85は、単独で、又は、動き補償部82,イントラ予測処理部84及びエントロピー復号部80などの他のユニットと協働して本出願の実施形態を実施してよい。いくつかの例では、ビデオ復号器30はイントラBC部85を有しなくてよく、イントラBC部85の機能性は、予測処理部81内の動き補償部82などの他の構成要素によって遂行されてもよい。
【0042】
[0048]ビデオデータメモリ79は、ビデオ復号器30の他の構成要素で復号されるべき符号化ビデオビットストリームなどのビデオデータを格納すればよい。ビデオデータメモリ79に格納されるビデオデータは、たとえば、記録装置32から,あるいはビデオデータの有線ネットワーク通信又は無線ネットワーク通信によりカメラなどのローカルなビデオ源から,あるいは物理的なデータ記録媒体(たとえば、フラッシュドライブ又はハードディスク)から取得されればよい。ビデオデータメモリ79は、符号化ビデオビットストリームからの符号化ビデオデータを格納する符号化ピクチャバッファ(CPB:coded picture buffer)を含んでよい。ビデオ復号器30内の復号ピクチャバッファ(DPB)92は、(たとえば、イントラ予測符号化モード又はインター予測符号化モードで)ビデオ復号器30でビデオデータを復号する際に使用される参照ビデオデータを格納する。ビデオデータメモリ79及びDPB92は、ダイナミック・ランダム・アクセス・メモリ(DRAM:dynamic random access memory)など、同期型DRAM(SDRAM:synchronous DRAM),磁気抵抗型RAM(MRAM:magneto-resistive RAM),抵抗変化型RAM(RRAM(登録商標):resistive RAM)又は他タイプのメモリデバイスといった多種多様な任意のメモリデバイスで構成されればよい。図示するために、ビデオデータメモリ79及びDPB92は、ビデオ復号器30内で2つの異なる構成要素として示されている。しかしながら、ビデオデータメモリ79及びDPB92が同一のメモリデバイス又は別々のメモリデバイスで与えられてよいことは、当業者であれば明らかであろう。いくつかの例では、ビデオデータメモリ79は、ビデオ復号器30内の他の構成要素とともにチップに実装されてもよいし、あるいは、他の構成要素に対してチップ外に実装されてもよい。
【0043】
[0049]復号処理の間、ビデオ復号器30は、符号化ビデオフレームの複数のビデオブロックとこれに関連したシンタックス要素とを示す符号化ビットストリームを受信する。ビデオ復号器30は、ビデオフレームのレベル及び/又はビデオブロックのレベルでシンタックス要素を受信すればよい。ビデオ復号器30内のエントロピー復号部80は、当該ビットストリームにエントロピー復号を施して、量子化係数,動きベクトル又はイントラ予測モードインジケータ,及び他のシンタックス要素を生成する。次いでエントロピー復号部80は、動きベクトル及び他のシンタックス要素を予測処理部81に送る。
【0044】
[0050]イントラ予測符号化(I)フレームとして、又は他タイプのフレーム内のイントラ符号化予測ブロックについてビデオフレームが符号化されるときは、予測処理部81内のイントラ予測処理部84は、現在のフレーム内の過去の復号ブロックから、信号伝達されたイントラ予測モード及び参照データに基づき、現在のビデオフレーム内のビデオブロックについて予測データを生成してよい。
【0045】
[0051]インター予測符号化(たとえばB又はP)フレームとしてビデオフレームが符号化されるときは、予測処理部81内の動き補償部82は、エントロピー復号部80から取得された動きベクトル及び他のシンタックス要素に基づき、現在のビデオフレーム内のビデオブロックについて1つ以上の予測ブロックを生成する。予測ブロックの各々は、複数の参照フレームリストのうちの1つのリスト内の参照フレームから生成されればよい。ビデオ復号器30は、DPB92に格納されている参照フレームに基づき、初期設定の構成技術を用いて、リスト0及びリスト1という参照フレームリストを構成すればよい。
【0046】
[0052]いくつかの例では、本明細書に説明されるイントラBCモードに従ってビデオブロックが符号化されるときは、予測処理部81内のイントラBC部85は、エントロピー復号部80から取得されたブロックベクトル及び他のシンタックス要素に基づき、現在のビデオブロックについて予測ブロックを生成する。予測ブロックは、ビデオ符号化器20で定められた現在のビデオブロックと同じピクチャ内の再構成領域内に存在すればよい。
【0047】
[0053]動き補償部82及び/又はイントラBC部85は、当該動きベクトル及び他のシンタックス要素を解析することにより現在のビデオフレーム内のビデオブロックについての予測情報を決定し、次いで、その予測情報を用いて、復号される現在のビデオブロックに対する予測ブロックを生成する。たとえば、動き補償部82は、現在のビデオフレームにおけるビデオブロックを復号するために、当該取得されたシンタックス要素のいくつかを使用して、当該ビデオフレーム内のビデオブロックの符号化に使用された予測モード(たとえば、イントラ予測又はインター予測)、インター予測フレームの種類(たとえば、B又はP)、当該フレームに対する1つ以上の参照フレームリストについての構成情報、当該フレーム内のインター予測符号化ビデオブロックの各々についての動きベクトル、当該フレーム内のインター予測符号化ビデオブロックの各々についてのインター予測状態、及びその他の情報を決定する。
【0048】
[0054]同様に、イントラBC部85は、現在のビデオフレームにおけるビデオブロックを復号するために、当該取得されたシンタックス要素のいくつか(たとえば、フラグ)を使用して、現在のビデオブロックがイントラBCモードを用いて予測されたこと,当該フレーム内のどのビデオブロックが再構成領域内に存在しかつDPB92に格納されるべきであるかを示す構成情報、当該フレーム内のイントラBC予測ビデオブロックの各々についてのブロックベクトル,当該フレーム内のイントラBC予測ビデオブロックの各々についてのイントラBC予測状態,及びその他の情報を決定すればよい。
【0049】
[0055]動き補償部82は、参照ブロックのサブ整数型画素に関する補間値を算出するために、ビデオブロックの符号化の際にビデオ符号化器20で使用されたような補間フィルタを用いて補間を実行してもよい。この場合、動き補償部82は、当該取得されたシンタックス要素から、ビデオ符号化器20で使用された補間フィルタを決定すればよく、予測ブロックを生成するために当該補間フィルタを使用すればよい。
【0050】
[0056]逆量子化部86は、ビットストリームで与えられてエントロピー復号部80によりエントロピー復号された量子化変換係数に対して、量子化度を決めるためにビデオフレーム内の各ビデオブロックについてビデオ符号化器20で算出された量子化パラメータと同じものを用いた逆量子化を実行する。逆変換処理部88は、画素領域の残差ブロックを再構成するために、変換係数に対して、たとえば、逆DCT,逆整数変換又は概念的に同様の逆変換処理といった逆変換を適用する。
【0051】
[0057]動き補償部82又はイントラBC部85が、当該ベクトル及び他のシンタックス要素に基づき、現在のビデオブロックについて予測ブロックを生成した後、加算器90は、逆変換処理部88からの残差ブロックと、動き補償部82及びイントラBC部85により生成された対応する予測ブロックとを加算することにより、現在のビデオブロックについて復号ビデオブロックを再構成する。復号ビデオブロックをさらに処理するために加算器90とDPB92との間にループ内フィルタ(図示せず)が配置されてもよい。次に、特定のフレーム内の復号ビデオブロックがDPB92内に格納される。DPB92は、次のビデオブロックのその後の動き補償のために使用される参照フレームを格納するものである。図1の表示装置34のような表示装置での表示をその後行うために、DPB92又はDPB92とは別のメモリデバイスが復号ビデオを格納してもよい。
【0052】
[0058]一般的なビデオ復号処理では、ビデオシーケンスは、一般に、配列された複数フレーム又は複数ピクチャの組を含む。各フレームは、SL,SCb及びScrで示される3つのサンプル配列を含んでよい。SLは、複数の輝度(luma)サンプルからなる2次元配列である。SCbは、複数のCb色差(chroma)サンプルからなる2次元配列である。SCrは、複数のCr色差(chroma)サンプルからなる2次元配列である。他の例では、フレームは単色でもよく、これにより複数の輝度(luma)サンプルからなる単一の2次元配列のみを有する。
【0053】
[0059]図4Aに示されるように、ビデオ符号化器20(又は、より具体的には分割部45)は、フレームを複数の符号化ツリーユニット(CTU)の集合に最初に分割することによりフレームの符号化表現を生成する。ビデオフレームは、上端から下端へかつ左側から右側へ向かうラスタ走査順で連続的に順序付けされた整数個のCTUを含んでいればよい。各CTETは、最大の論理符号化ユニットであり、CTUの幅及び高さは、シーケンスパラメータセットでビデオ符号化器20により信号伝達されて、ビデオシーケンス内の全てのCTUが128×128,64×64,32×32及び16×16のうちの1つと同じサイズを有するようにされる。ただし、本出願は必ずしも特定のサイズに限定されるものではない点に注意すべきである。図4Bに示されるように、各CTUは、複数の輝度サンプルからなる1つの符号化ツリーブロック(CTB)及びこれに対応した複数の色差サンプルからなる2つの符号化ツリーブロックと、それら符号化ツリーブロックのサンプルを符号化するために使用されるシンタックス要素とを有してよい。シンタックス要素は、符号化画素ブロックの異なるタイプのユニットの特性と、ビデオシーケンスをビデオ復号器30で再構成できる方法とを記述するものであり、インター予測もしくはイントラ予測,イントラ予測モード,動きベクトル及びその他のパラメータを含む。モノクロのピクチャ又は3つの異なる色プレーンをもつピクチャでは、CTUは、単一の符号化ツリーブロックと当該符号化ツリーブロックのサンプルを符号化するために使用されるシンタックス要素とを有していればよい。符号化ツリーブロックは、複数サンプルからなるN×Nのブロックであればよい。
【0054】
[0060]より良好な性能を達成するために、ビデオ符号化器20は、CTUの符号化ツリーブロックに対して、二分木(binary-tree)分割,四分木(quad-tree)分割,又はこれらの両方の組合せといった木分割を再帰的に実行して、当該CTUをより小さな複数の符号化ユニット(CU)に分割すればよい。図4Cに示されるように、64×64のCTU400は、最初に、より小さな4つのCUに分割され、各CUは、32×32のブロックサイズを有している。これらの小さな4つのCUのうち、CU410及びCU420の各々は、16×16のブロックサイズの4つのCUに分割される。2つの16×16のCU430,440は、各々、さらに8×8のブロックサイズの4つのCUに分割される。図4Dは、図4Cに示したCTU400に分割処理を施して得られた最終結果を表す四分木データ構造の図であり、四分木の各リーフノード(葉ノード)は、32×32から8×8までの範囲内の各サイズを有する1つのCUに相当する。図4Bに示したCTUのように、各CUは、同一サイズのフレームにおける複数の輝度サンプルからなる符号化ブロック(CB)及びこれに対応した複数の色差サンプルからなる2つの符号化ブロックと、これら符号化ブロックのサンプルを符号化するために使用されるシンタックス要素とを有する。モノクロのピクチャ又は3つの異なる色プレーンをもつピクチャでは、CUは、単一の符号化ブロックと、当該符号化ブロックのサンプルを符号化するために使用されるシンタックス構造とを有してよい。
【0055】
[0061]いくつかの実施形態では、ビデオ符号化器20は、さらに、CUの符号化ブロックを1つ以上のN×Nの予測ブロック(PB)に分割してよい。予測ブロックは、同一の予測すなわちインター又はイントラが適用される複数サンプルからなる矩形状(正方形又は非正方形)のブロックである。CUの予測ユニット(PU)は、複数の輝度サンプルからなる予測ブロックと、これに対応した複数の色差サンプルからなる2つの予測ブロックと、それら予測ブロックを予測するために使用されるシンタックス要素とを有してよい。モノクロのピクチャ又は3つの異なる色プレーンをもつピクチャでは、PUは、単一の予測ブロックと、当該予測ブロックを予測するために使用されるシンタックス構造とを有してよい。ビデオ符号化器20は、CUの各PUにおける輝度予測ブロック,Cb予測ブロック及びCr予測ブロックについて、予測輝度ブロック,予測Cbブロック及び予測Crブロックを生成すればよい。
【0056】
[0062]ビデオ符号化器20は、イントラ予測又はインター予測を使用してPUについてそれら予測ブロックを生成すればよい。ビデオ符号化器20がイントラ予測を使用してPUの予測ブロックを生成するときは、ビデオ符号化器20は、当該PUに関するフレームの復号サンプルに基づいて、当該PUの予測ブロックを生成すればよい。ビデオ符号化器20がインター予測を使用してPUの予測ブロックを生成するときは、ビデオ符号化器20は、当該PUに関するフレーム以外の1つ以上のフレームの復号サンプルに基づいて、当該PUの予測ブロックを生成すればよい。
【0057】
[0063]ビデオ符号化器20がCUの1つ以上のPUについて予測輝度ブロック,予測Cbブロック及び予測Crブロックを生成した後は、ビデオ符号化器20は、CUの予測輝度ブロックをその元の輝度符号化ブロックから減算することにより、CUについて輝度残差ブロックを生成すればよく、当該CUの輝度残差ブロックの各サンプルが、当該CUの複数の予測輝度ブロックのうちの1つのブロックの輝度サンプルと、当該CUの元の輝度符号化ブロックの対応するサンプルとの間の差分を示すものとする。同様に、ビデオ符号化器20は、それぞれ、Cb残差ブロック及びCr残差ブロックを生成すればよく、当該CUのCb残差ブロックの各サンプルが、当該CUの複数の予測Cbブロックのうちの1つのブロックのCbサンプルと、当該CUの元のCb符号化ブロックの対応するサンプルとの間の差分を示すものとし、当該CUのCr残差ブロックの各サンプルが、当該CUの複数の予測Crブロックのうちの1つのブロックのCrサンプルと、当該CUの元のCr符号化ブロックの対応するサンプルとの間の差分を示してよいものとする。
【0058】
[0064]さらに、図4Cに示されるように、ビデオ符号化器20は、CUにおける輝度残差ブロック,Cb残差ブロック及びCr残差ブロックを、1つ以上の輝度変換ブロック,Cb変換ブロック及びCr変換ブロックに分解するために四分木分割を使用すればよい。変換ブロックは、同一の変換が適用される複数サンプルからなる矩形状(正方形又は非正方形)のブロックである。CUの変換ユニット(TU)は、複数の輝度サンプルからなる変換ブロックと、これに対応した複数の輝度サンプルからなる2つの変換ブロックと、それら変換ブロックのサンプルを変換するために使用されるシンタックス要素とを有してよい。よって、CUの各TUは、輝度変換ブロック,Cb変換ブロック及びCr変換ブロックと関連付けられうる。いくつかの例では、TUに関連付けられた輝度変換ブロックは、CUの輝度残差ブロックのサブブロックであればよい。Cb変換ブロックは、CUのCb残差ブロックのサブブロックであればよい。Cr変換ブロックは、CUのCr残差ブロックのサブブロックであればよい。モノクロのピクチャ又は3つの異なる色プレーンをもつピクチャでは、TUは、単一の変換ブロックと、当該変換ブロックのサンプルを変換するために使用されるシンタックス構造とを有してよい。
【0059】
[0065]ビデオ符号化器20は、TUの輝度変換ブロックに1つ以上の変換を適用して当該TUについて輝度係数ブロックを生成すればよい。係数ブロックは、複数の変換係数の2次元配列であればよい。変換係数は、スカラー量であればよい。ビデオ符号化器20は、TUのCb変換ブロックに1つ以上の変換を適用して当該TUについてCb係数ブロックを生成すればよい。ビデオ符号化器20は、TUのCr変換ブロックに1つ以上の変換を適用して当該TUについてCr係数ブロックを生成すればよい。
【0060】
[0066]係数ブロック(たとえば、輝度係数ブロック,Cb係数ブロック又はCr係数ブロック)を生成した後、ビデオ符号化器20は、当該係数ブロックを量子化すればよい。通常、量子化は、変換係数を示すために使用されたデータの総量を削減しうるように変換係数を量子化する処理をいい、さらなる圧縮を与えるものである。ビデオ符号化器20が係数ブロックを量子化した後、ビデオ符号化器20は、その量子化変換係数を示すシンタックス要素をエントロピー符号化すればよい。たとえば、ビデオ符号化器20は、量子化変換係数を示すシンタックス要素に対してコンテキスト適応型2値算術符号化(CABAC:Context-Adaptive Binary Arithmetic Coding)を実行すればよい。最終的に、ビデオ符号化器20は、符号化フレーム及び関連データの表現を構成するビットシーケンスを示すビットストリームを出力すればよく、それは記録装置32に保存されるか、あるいは、送信先装置14に送信される。
【0061】
[0067]ビデオ符号化器20により生成されたビットストリームを受信した後、ビデオ復号器30は、当該ビットストリームを解析して当該ビットストリームからシンタックス要素を取得すればよい。ビデオ復号器30は、ビットストリームから取得されたシンタックス要素の少なくとも一部に基づいてビデオデータのフレームを再構成すればよい。ビデオデータを再構成する処理は、通常、ビデオ符号化器20により実行された符号化処理とは逆の処理である。たとえば、ビデオ復号器30は、現在のCUのTUに関連する係数ブロックに逆変換を施して、当該現在のCUのTUに関連する残差ブロックを再構成すればよい。ビデオ復号器30は、当該現在のCUにおけるPUについての予測ブロックのサンプルを、当該現在のCUにおけるTUの変換ブロックの対応サンプルに加算することにより、当該現在のCUの符号化ブロックを再構成してもよい。フレームの各CUについて符号化ブロックを再構成した後、ビデオ復号器30は、当該フレームを再構成すればよい。
【0062】
[0068]上記のとおり、ビデオ符号化は、主要な2つのモード、すなわち、イントラフレーム予測(又はイントラ予測)とインターフレーム予測(又はインター予測)とを用いてビデオ圧縮を実現するものである。IBCは、イントラフレーム予測又は第3のモードのいずれかとみなされうることに注意すべきである。当該2つのモードのうち、インターフレーム予測は、参照ビデオブロックから現在のビデオブロックを予測するために動きベクトルを使用することから、イントラフレーム予測よりも符号化効率に寄与する。
【0063】
[0069]ただし、ビデオデータのキャプチャ技術が絶え間なく向上していること、及びビデオデータの詳細情報を保持するためにビデオブロックサイズがより細かくなっていることに伴い、現在のフレームについて動きベクトルを表すために必要とされるデータ量も実質的に増大している。この課題を克服するための1つの方法は、空間領域及び時間領域の双方で近隣のCUからなる集合が予測のために類似のビデオデータを有していることだけでなく、これら近隣のCU間の動きベクトルも類似しているという事実から利益を得ることである。したがって、空間的及び時間的な相関を探し出すことにより、空間的に近隣のCU及び/又は時間的に連結するCUの動き情報を、現在のCUのおおよその動き情報(たとえば動きベクトル)として使用することが可能である。これは、現在のCUの「動きベクトル予測子(MVP:motion vector predictor)」とも呼ばれる。
【0064】
[0070]図2に関して上記したように動き推定部42により決定された現在のCUの実際の動きベクトルをビデオビットストリーム内に符号化する代わりに、現在のCUについて動きベクトル差分(MVD:motion vector difference)を生成するために、現在のCUの動きベクトル予測子は当該現在のCUの実際の動きベクトルから減算される。そのようにすることにより、フレームの各CUについて動き推定部42により決定された動きベクトルをビデオビットストリーム内に符号化する必要がなく、ビデオビットストリーム内の動き情報を表現するために使用されるデータ量を大幅に削減することができる。
【0065】
[0071]符号ブロックのインターフレーム予測の際に参照フレーム内の予測ブロックを選択する処理のように、現在のCUに対して空間的に近隣のCU及び/又は時間的に連結するCUに関連して生成されうる候補動きベクトルを用いて現在のCU用の動きベクトル候補リストを構成し、次いで当該現在のCUについて動きベクトル予測子としてその動きベクトル候補リストの中から一要素を選択するために、一組のルールがビデオ符号化器20及びビデオ復号器30の双方で適用される必要がある。そのようにすることにより、ビデオ符号化器20とビデオ復号器30との間で動きベクトル候補リスト自体を送信する必要がなく、動きベクトル候補リスト内の当該選択された動きベクトル予測子のインデックスは、現在のCUを符号化及び復号するためにビデオ符号化器20及びビデオ復号器30が動きベクトル候補リスト内の同じ動きベクトル予測子を使用するために十分なものである。
【0066】
[0072]いくつかの実施形態では、各インター予測CUは、動きベクトル候補リスト構成するために、インター(以下「高度動きベクトル予測(AMVP:advanced motion vector prediction)」とも称する。),スキップ及びマージを含む3つの動きベクトル予測モードを有する。各モードの下では、以下に説明するアルゴリズムに従って1つ以上の動きベクトル候補が動きベクトル候補リストに追加されうる。その候補リストの中から最終的に1つの候補が、ビデオ符号化器20によりビデオビットストリーム内に符号化されるべき又はビデオ復号器30によりビデオビットストリームから復号されるべきインター予測CUの最良の動きベクトル予測子として使用される。その候補リストの中から最良の動きベクトル予測子を見つけ出すために、与えられた複数の動きベクトルからなる候補セット、すなわち、空間的及び時間的な動きベクトル候補を含む動きベクトル候補リストの中から動きベクトルを選択するという動きベクトル競合(MVC:motion vector competition)方式が導入される。
【0067】
[0073]空間的に近隣の又は時間的に連結するCUの中から動きベクトル予測子の候補を抽出することに加えて、当該動きベクトル予測子の候補を、いわゆる「履歴ベースの動きベクトル予測(HMVP:history-based motion vector prediction)」テーブルから抽出することもできる。HMVPテーブルは、所定数の動きベクトル予測子を格納し、各動きベクトル予測子は、同一のCTU行(又は、ときには同一のCTU)のうちの特定のCUを符号化/復号するために使用される。これらCUの空間的/時間的な近接度のために、HMVPテーブル中の1つの動きベクトル予測子が、同一のCTU行内の互いに異なるCUを符号化/復号するために再利用されるであろうという高い確からしさが存在する。したがって、動きベクトル候補リストを構成する処理にHMVPテーブルを組み込むことにより、より高い符号効率を実現することができる。
【0068】
[0074]いくつかの実施形態では、HMVPテーブルは、固定長(たとえば、5)を有し、準先入れ先出し(quasi-FIFO:quasi-First-In-First-Out)方式で管理される。たとえば、動きベクトルは、CUについて、当該CUの1つのインター符号化ブロックを復号する際に再構成される。HMVPテーブルは、再構成された動きベクトルでオンザフライで更新される。なぜならば、そのような動きベクトルは、次のCUの動きベクトル予測子となり得るからである。HMVPテーブルを更新するとき、下記(i),(ii)の2つのシナリオがある。(i)再構成された動きベクトルがHMVPテーブル内の他の既存の動きベクトルと異なること、又は、(ii)再構成された動きベクトルがHMVPテーブル内の既存の動きベクトルの1つと同じであることである。前記第1のシナリオに対しては、HMVPテーブルが限度一杯でなければ、再構成された動きベクトルは最新の動きベクトルとしてHMVPテーブルに追加される。HMVPテーブルが既に限度一杯であれば、再構成された動きベクトルが最新の動きベクトルとして追加される前に、HMVPテーブル内の最も古い動きベクトルがHMVPテーブルから削除される。言い換えれば、この場合のHMVPテーブルは、FIFOバッファと類似しており、このFIFOバッファの先頭に位置しかつ他の過去のインター符号化ブロックに関連する動きベクトル情報が、そのバッファの外にシフトさせられるので、再構成された動きベクトルがHMVPテーブル内の最新の要素としてFIFOバッファの後部に追加されるというようなものである。上記第2のシナリオに対しては、再構成された動きベクトルが最新の動きベクトルとして追加される前に、再構成された動きベクトルと実質的に同一であるHMVPテーブル内の既存の動きベクトルがHMVPテーブルから削除される。またHMVPテーブルがFIFOバッファの形で整備されているのであれば、HMVPテーブル内の当該同一の動きベクトルの後の動きベクトル予測子は、削除された動きベクトルの後に残ったスペースを占めるように1要素だけ前方にシフトさせられ、次いで、再構成された動きベクトルが、HMVPテーブル内の最新の要素としてFIFOバッファの後部に追加される。
【0069】
[0075]HMVPテーブル内の動きベクトルは、AMVP,マージ,スキップなどの複数の異なる予測モードの下で動きベクトル候補リストに追加されうる。HMVPテーブルに格納されており、現在のブロックと隣接すらしない過去のインター符号化ブロックの動き情報が、より効率的な動きベクトル予測について使用可能であることが見出された。
【0070】
[0076]複数の動きベクトルからなる所与の候補セットのうち1つのMVP候補が現在のCUについて選択された後は、ビデオ符号化器20は、1つ以上のシンタックス要素をこれに対応するMVP候補について生成し、これらをビデオビットストリーム内に符号化して、ビデオ復号器30が当該シンタックス要素を用いてビデオビットストリームから当該MVP候補を取得できるようにすればよい。動きベクトル候補セットを構成するために使用された特定のモードに応じて、複数の異なるモード(たとえば,AMVP,マージ,スキップなど)は、シンタックス要素からなる複数の異なるセットを有している。AMVPモードについては、シンタックス要素には、インター予測インジケータ(リスト0,リスト1,又は双方向予測)と、参照インデックス,動きベクトル候補インデックス,動きベクトル予測残差信号などが含まれている。スキップモード及びマージモードについては、マージインデックスのみがビットストリーム内に符号化されている。なぜならば、現在のCUは、インター予測インジケータ,参照インデックス及び動きベクトルを含む他のシンタックス要素を、符号化マージインデックスにより参照された近隣のCUから引き継いでいるからである。スキップ符号化CUの場合は、動きベクトル予測残差信号も無視される。
【0071】
[0077]図5Aは、本開示のいくつかの実施形態に従って、符号化/復号対象である現在のCUに対して空間的に近隣でかつ時間的に連結するブロック位置を示すブロック図である。所与のモードに対して、先ずは、空間的に左方及び上方に近隣のブロック位置に関連付けられた動きベクトルの利用可能性と、時間的に連結するブロック位置に関連付けられた動きベクトルの利用可能性とをチェックし、次いでFDMVPテーブル内の動きベクトルをチェックすることにより、動きベクトル予測(MVP)候補リストが構成される。そのMVP候補リストを構成する処理の際、いくつかの重複するMVP候補が候補リストから除去され、必要に応じて、固定長をもつために候補リストを作成するようにゼロ値の動きベクトルが追加される(複数の異なるモードが異なる固定長を有してよい点に注意する。)。MVP候補リストの構成後、ビデオ符号化器20は、その候補リストの中から最良の動きベクトル予測子を選択して、当該選択された候補を示す対応インデックスをビデオビットストリーム内に符号化することができる。
【0072】
[0078]図5Aを例として用い、その候補リストが固定長2を有すると仮定すると、動きベクトル予測子(MVP)候補リストは、現在のCUについて、AMVPモードの下で以下のステップを順次実行することにより構成されればよい。
1)空間的に近隣の複数のCUからのMVP候補の選択
a)A0を起点としA1で終わる、左方で空間的に近隣の2つのCUのうちの1つから、1つの非スケール化MVP候補を抽出するステップ、
b)前回のステップにて左方からは利用可能な非スケール化MVP候補が存在しないときは、A0を起点としA1で終わる、左方で空間的に近隣の2つのCUのうちの1つから、1つのスケール化MVP候補を抽出するステップ、
c)B0を起点としB1を経てB2で終わる、上方で空間的に近隣の3つのCUのうちの1つから、1つの非スケール化MVP候補を抽出するステップ、
d)A0,A1のいずれも利用可能ではないとき、あるいは、これらがイントラモードで符号化されているときは、B0を起点としB1を経てB2で終わる、上方で空間的に近隣の3つのCUのうちの1つから、1つのスケール化MVP候補を抽出するステップ、
2)以前のステップにて2つのMVP候補が見つけ出され、これらが同一であるときは、MVP候補リストの中から当該2つの候補のうちの1つを削除するステップ、
3)時間的に連結する複数のCUからのMVP候補の選択
a)以前のステップの後のMVP候補リストが2つのMVP候補を含まないときは、当該時間的に連結するCUの中から1つのMVP候補を抽出するステップ
4)HMVPテーブルからのMVP候補の選択
a)以前のステップの後のMVP候補リストが2つのMVP候補を含まないときは、HMVPテーブルから2つの履歴ベースのMVPを抽出するステップ、
5)以前のステップの後のMVP候補リストが2つのMVP候補を含まないときは、2つのゼロ値MVPをMVP候補リストに追加するステップ。
【0073】
[0079]上記のとおりに構成されたAMVPモードMVP候補リストの中には2つの候補しか存在しないので、その候補リスト内の2つのMVP候補のうちどちらが現在のCUの復号に使用されるのかを示すために、2値フラグのような関連シンタックス要素がビットストリーム内に符号化される。
【0074】
[0080]いくつかの実施形態では、スキップモード又はマージモードにて、MVP候補リストは、現在のCUについて、上記のような類似のステップ群を順次実行することにより構成されればよい。スキップモード又はマージモードについては、「ペアワイズ・マージ候補(pair-wise merge candidate)」と呼ばれる特別な種類のマージ候補もMVP候補リストに組み込まれる点に注意すべきである。ペアワイズ・マージ候補は、過去に抽出された2つのマージモード動きベクトル候補における複数のMVを平均化することで生成される。そのマージMVP候補リストのサイズ(たとえば、1~6)は、現在のCUのスライスヘッダにて信号伝達される。マージモードでは、各CUについて、トランケーテッド・ユーナリー・バイナリゼーション(TU:truncated unary binarization)を用いて最良のマージ候補のインデックスが符号化される。マージインデックスの最初のビンはコンテキストで符号化され、他のビンについてはバイパス符号化が使用される。
【0075】
[0081]上記のとおり、履歴ベースのMVPは、空間的なMVP又は時間的なMVPの後に、AMVPモードMVP候補リスト又はマージMVP候補リストのいずれかに追加されうる。過去のインター符号化CUの動き情報はHMVPテーブルに格納され、現在のCUについてMVP候補として使用される。HMVPテーブルは、符号化/復号処理の間に整備される。非サブブロック・インター符号化CUがあるときはいつでも、(HMVPテーブルが既に限度一杯であり、その関連する動きベクトル情報の同じものの重複が存在しないときは)その関連する動きベクトル情報が新しい候補としてHMVPテーブルの最後の項目に追加される一方で、HMVPテーブルの最初の項目に格納されている動きベクトル情報は、そこから削除される。あるいは、その関連する動きベクトル情報がHMVPテーブルの最後の項目に追加される前に、その関連する動きベクトル情報の同じものの重複がそのテーブルから取り除かれる。
【0076】
[0082]上記のとおり、イントラブロックコピー(IBC)は、表示コンテンツ素材の符号化効率を大幅に向上させることができる。IBCモードは、ブロックレベルの符号化モードとして実現されるので、各CUについて最適なブロックベクトルを見つけ出すためにブロックマッチング(BM)がビデオ符号化器20で実行される。ここで、ブロックベクトルは、現在のブロックから参照ブロックへの位置ずれを示すために使用され、現在のピクチャ内で既に再構成されているものである。IBC符号化CUは、イントラ予測モードやインター予測モード以外の第3の予測モードとして扱われる。
【0077】
[0083]CUレベルでは、IBCモードは、以下のIBC・AMVPモード又はIBC・スキップ/マージモードとして信号伝達されうる。
- IBC・AMVPモード:上記のAMVPモードで動きベクトル差分を符号化する場合と同じ方法で、CUの実際のブロックベクトルと、当該CUのブロックベクトル候補から選択された当該CUのブロックベクトル予測子との間のブロックベクトル差分(BVD:block vector difference)が符号化される。ブロックベクトル予測法は、2つのブロックベクトル候補を予測子として使用し、その一方を左方近隣から、その他方を上方近隣から得る。いずれの近隣も利用できないときは、初期設定のブロックベクトルがブロックベクトル予測子として使用されることとなる。2値フラグは、ブロックベクトル予測子のインデックスを示すために信号伝達される。IBC・AMVP候補リストは、空間的なHMVP候補で構成されている。
- IBC・スキップ/マージモード:近隣のIBC符号化ブロックからのマージ候補リスト内のブロックベクトル候補のうちのどれが、現在のブロックについてブロックベクトルの予測のために使われるのかを示すためにマージ候補インデックスが使用される。IBCマージ候補リストは、空間的、HMVPかつペアワイズな候補で構成される。
【0078】
[0084]従来の符号化規格に適応する符号化効率を向上させる別のアプローチは、たとえばマルチコアプロセッサを用いて、ビデオ符号化/復号処理に並列処理を導入することである。たとえば、波面並列処理(WPP:wavefront parallel processing)は、マルチスレッドを使用して複数のCTU行の符号化又は復号を並列に行う機能としてHEVCに既に導入されてきた。
【0079】
[0085]図5Bは、本開示のいくつかの実施形態に従って、波面並列処理(WPP)を用いてピクチャ内の複数のCTU行をマルチスレッド符号化することを示すブロック図である。WPPが有効であるとき、波面法で複数のCTU行を並列に処理することが可能である。ここで、2つの近隣の波面の先頭間に2つのCTU行の遅延がありうる。たとえば、WPPを使用してピクチャ500を符号化するために、ビデオ符号化器20及びビデオ復号器30などのビデオコーダは、ピクチャ500の符号化ツリーユニット(CTU)を複数の波面に分割し、各波面は当該ピクチャ内の各CTU行に相当する。ビデオコーダは、たとえば第1のコーダコア又はスレッドを用いて、先頭の波面のコーディングを開始すればよい。ビデオコーダが先頭の波面の2つ以上のCTUをコーディングした後は、ビデオコーダは、たとえば2番目の並列なコーダコア又はスレッドを用いて、先頭の波面のコーディングと並行して、先頭から2番目の波面のコーディングを開始すればよい。ビデオコーダが先頭から2番目の波面の2つ以上のCTUをコーディングした後は、ビデオコーダは、たとえば3番目の並列なコーダコア又はスレッドを用いて、より高次の波面のコーディングと並行して、先頭から3番目の波面のコーディングを開始すればよい。このパターンは、ピクチャ500内の複数の波面について続行されればよい。本開示では、ビデオコーダが同時並行にコーディングを行うCTUの集合を「CTU群」と称する。よって、ビデオコーダがWPPを使用してピクチャのコーディングを行うとき、CTU群の各CTUは、ピクチャ内の唯1つの波面に属してよく、当該CTUは、それぞれ1つ上の波面内のCTUから、ピクチャ内の少なくとも2つのCTU列だけオフセットされていればよい。
【0080】
[0086]ビデオコーダは、現在の波面についてコンテクストを初期化して、上の波面の先頭2つのブロックのデータと、当該現在の波面の先頭符号ブロックを含むスライスについてのスライスヘッダ内の1つ以上の要素とに基づいて、当該現在の波面のコンテキスト適応型2値算術符号化(CABAC:context adaptive binary arithmetic coding)を実行すればよい。ビデオコーダは、次のCTU行の上のCTU行における2つのCTUをコーディングした後のコンテキスト状態を用いて、次の波面(又はCTU行)のCABAC初期化を実行すればよい。言い換えれば、現在の波面のコーディングを開始する前に、ビデオコーダ(又は、より具体的には、そのビデオコーダのスレッド)は、当該現在の波面がピクチャ内の先頭のCTU行ではないと仮定して、当該現在の波面の上の波面における少なくとも2つのブロックのコーディングを実行すればよい。次いでビデオコーダは、現在の波面の上の波面における少なくとも2つのブロックのコーディング後に、現在の波面についてCABACコンテキストを初期化すればよい。この例では、ピクチャ500の各CTU行は、分離区画であり、ピクチャ内の複数のCTU行が並列に符号化されるように関連したスレッド(WPPスレッド1,WPPスレッド2,…)を有している。
【0081】
[0087]HMVPテーブルの現在の実施形態は、グローバルな動きベクトル(MV)バッファを用いて、過去に再構成された動きベクトルを格納しているので、このHMVPテーブルは、図5Bに関して上述したWPP有効型の並列符号化方式では実現できない。特に、グローバルなMVバッファがビデオコーダの符号化/復号処理の全てのスレッドで共有されているという事実は、先頭のWPPスレッド(たとえば、WPPスレッド1)の後に続くWPPスレッドが開始されることを妨げる。なぜならば、これらのWPPスレッドは、先頭のWPPスレッド(たとえば先頭のCTU行)の最後のCTU(たとえば右端のCTU)からHMVPテーブルの更新が完了するまで待たなければならないからである。
【0082】
[0088]このような課題を克服するために、WPPスレッドで共有されるグローバルなMVバッファをマルチCTU行専用のバッファに置き換えて、ビデオコーダのWPPが有効なときに、CTU行の各波面が、対応するWPPスレッドで処理されるCTU行に対応するHMVPテーブルを格納するために自らのバッファを有するようにすることを提案する。自らのHMVPテーブルを有する各CTU行は、当該CTU行の先頭のCUをコーディングする前にHMVPテーブルをリセットすることと同等である点に注意すべきである。HMVPテーブルのリセットとは、他のCTU行のコーディングから得られたHMVPテーブル内の全ての動きベクトルを消し去ることである。1つの実施形態では、そのリセット処理は、HMVPテーブル内の利用可能な動きベクトル予測子のサイズをゼロに設定することである。他の実施形態では、そのリセット処理は、HMVPテーブル内の全ての項目の参照インデックスを-1のような無効値に設定することもありうる。そのようにすることにより、特定の波面内の現在のCTUに対するMVP候補リストは、AMVP,マージ及びスキップという3つのモードのうちのいずれのモードであろうとも、その特定の波面を処理するWPPスレッドに関連したHMVPテーブルに応じて構成される。上記した2つのCTUの遅延以外には異なる波面間の相互依存がなく、複数の異なる波面に関連した複数の動きベクトル候補リストを構成することを、図5Bに示したWPP処理のように並列に進行させることができる。言い換えれば、特定の波面を処理することを開始する際に、他のWPPスレッドによって他のCTU波面のコーディングが影響を受けずに、HMVPテーブルは空状態となるようにリセットされる。いくつか場合には、各CTUそれぞれのコーディングを行う前に、HMVPテーブルは空状態となるようにリセットできる。この場合には、HMVPテーブル内の動きベクトルは特定のCTUに限定され、おそらく、当該HMVPテーブル内の動きベクトルが、当該特定のCTU内の現在のCUの動きベクトルとして選択される可能性がより高くなる。
【0083】
[0089]図6は、本開示のいくつかの実施形態に従って、少なくともHMVPテーブルを用いて動きベクトル予測子の候補リストを構成する技術を実現するビデオ符号化器20又はビデオ復号器30などのビデオコーダによる処理例を示すフローチャートである。図で示すために、フローチャートはビデオ復号処理を示している。先ず、ビデオ復号器30は、複数の符号化ピクチャに関連したデータを含む符号化ビデオビットストリームを取得する(610)。図4A及び図4Cに示されるように、各ピクチャは、符号化ツリーユニット(CTU)行を複数含み、各CTUは、1つ以上の符号化ユニット(CU)を含む。ビデオ復号器30は、シンタックス要素及び画素値などの複数の異なる情報をビデオビットストリームから抽出して、行単位でピクチャを再構成する。
【0084】
[0090]現在のCTU行を復号する前に、ビデオ復号器30は、先ず、当該現在のCTU行について履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットする(620)。上記のとおり、HMVPテーブルのリセットは、ビデオ復号器30が、たとえばマルチスレッド処理を用いて現在のピクチャ内の複数のCTU行を並列に復号できることを保証し、1つのスレッドがCTU行ごと又はマルチコアプロセッサごとに自らのHMVPテーブルを有すること、もしくは、1つのコアがCTU行ごとに自らのHMVPテーブルを有すること、又はこれらの両方を保証するものである。さらにいくつかの他の実施形態では、現在のCTUを復号する前に、ビデオ復号器30は、先ず、当該現在のCTUについて履歴ベースの動きベクトル予測子(HMVP)テーブルをリセットする(620)。上記のとおり、HMVPテーブルのリセットは、たとえばマルチスレッド処理を用いて現在のピクチャ内の複数のCTUを並列に復号できることを保証し、1つのスレッドがCTUごと又はマルチコアプロセッサごとに自らのHMVPテーブルを有すること、もしくは、1つのコアがCTUごとに自らのHMVPテーブルを有すること、又はこれらの両方を保証するものである。
【0085】
[0091]現在のCTU行を復号する間に(630)、ビデオ復号器30は、HMVPテーブル内の複数の動きベクトル予測子を整備する(630-1)。上記のとおり、HMVPテーブルに格納されている各動きベクトル予測子は、現在のCTU行内の少なくとも他のCUを復号するために使用されていた。実際、HMVPテーブルに動きベクトル予測子が存在するのは、HMVPテーブルが上記のように動きベクトル候補リストを構成する処理に関与するときに、当該動きベクトル予測子が現在のCTU行内の他のCUを予測するために再度利用されるかもしれないからである。
【0086】
[0092]
[0093]現在のCTU行内の現在のCUについて、ビデオ復号器30は、ビデオビットストリームから予測モードを抽出する(630-3)。上記のとおり、CUは、高度動きベクトル予測(AMVP:advanced motion vector prediction)モード,マージモード,スキップモード,IBC・AMVPモード,及びIBCマージモードを含む複数種の予測モードを有してよい。ビデオ符号化器20がCUについて適切な予測モードを選択したら、当該選択された予測モードがビットストリームで信号伝達される。上記のとおり、動きベクトル候補リストを構成するために、様々な順序で実行される様々なステップ群が存在する。ここで、ビデオ復号器30は、当該予想モードに従って、HMVPテーブル内の複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成する(630-5)。他の情報源、これから動きベクトル候補リストは、現在のCUに対して空間的に近隣のCU及び/又は時間的に連結するCUに由来する動きベクトル予測子(予測モードが、AMVPモード,IBC・AMVPモード及びIBCマージモードのうちの1つである場合)を含み、オプションとしてペアワイズな動きベクトル予測子(予測モードが、マージモード及びスキップモードのうちの1つである場合)を含む。オプションとして、動きベクトル候補リストが所定長とならないときは、動きベクトル候補リストに1つ以上のゼロ値の動きベクトル予測子が追加されればよい。
【0087】
[0094]次に、ビデオ復号器30は、動きベクトル候補リストの中から、現在のCUについて動きベクトル予測子を選択し(630-7)、当該選択された動きベクトル予測子と予測モードとの少なくとも一部に基づいて、動きベクトルを決定する(630-9)。上記のとおり、当該予測モードがAMVPモードであるか否かに応じて、当該選択された動きベクトル予測子は、現在のCUについての推定動きベクトルであるか否かであってよい。たとえば、当該予測モードがAMVPモードであれば、推定動きベクトルは、ビットストリームから再生された動きベクトル差分を、当該選択された動きベクトル予測子に加算することによって決定され、次いで、その推定動きベクトルと参照ピクチャ内の対応するCUとを少なくとも部分的に用いて現在のCUが復号される。しかしながら、予測モードがマージモード又はスキップモードであれば、当該選択された動きベクトル予測子は既に推定動きベクトルであり、現在のCUを、参照ピクチャ内の対応するCUとともに復号する際に使用できるものである。最終的に、ビデオ復号器30は、当該決定された動きベクトルに基づいてHMVPテーブルを更新する(630-11)。上記のとおり、HMVPテーブル内のすべての要素は、以前に少なくとも他のCUを復号するために使用されており、現在のCTU行内における次の他のCUを復号するために使用される動きベクトルの挿入により又はテーブルリセットによりHMVPテーブルから削除されるまで、動きベクトル候補リストを構成するためにHMVPテーブル内に保持される。
【0088】
[0095]いくつかの実施形態では、HMVPテーブルへの動きベクトルの挿入には、現在のCUについて決定された動きベクトルと、HMVPテーブル内の複数の動きベクトル予測子との比較結果に基づいて2つのシナリオの可能性がある。HMVPテーブル内の複数の動きベクトル予測子のいずれもが当該決定された動きベクトルと同一ではないときは、HMVPテーブルが限度一杯であれば、HMVPテーブルから最先又は最古の動きベクトル予測子が削除されて、当該動きベクトルが最新のものとしてそのテーブルに追加される。HMVPテーブル内の複数の動きベクトル予測子のうちの1つが当該動きベクトルと同一であるときは、当該同一の1つの動きベクトル予測子がHMVPテーブルから削除され、その削除された動きベクトル予測子の後の他の動きベクトル予測子は全てHMVPテーブル内で前方に移動させられて、当該動きベクトルが最新のものとしてHMVPテーブルの後部に追加されるようになる。
【0089】
[0096]上記のとおり、複数のCTU行のうちの2つ以上が、たとえばWPPを用いて並列に符号化/復号されてよく、各CTU行は、対応するCTU行を符号化/復号するために使用される履歴ベースの動きベクトル予測子を複数格納するために関連したHMVPテーブルを有している。たとえば、復号される現在のピクチャ内における特定のCTU行の復号に対してスレッドが割り当てられて、図5Bに関して上述したように複数の異なるCTU行が複数の異なる関連スレッドを有して復号できるようにされる。いくつかの例では、ビデオ復号器30は、動きベクトル候補リスト内の1つ以上の動きベクトル予測子を冗長なものとして特定し、それを動きベクトル候補リストから削除して符号化効率をさらに向上させる。
【0090】
[0097]1つ以上の例では、上記の機能は、ハードウェア,ソフトウェア,またはこれらの組合せで実現されてよい。上記の機能は、ソフトウェアで実現されているときは、1つ以上の命令又は符号としてコンピュータ読み取り可能な媒体に格納又は送信されて、ハードウェアベースの処理ユニットで実行されればよい。コンピュータ読み取り可能な媒体は、記録媒体などの有形媒体に相当するコンピュータ読み取り可能な記録媒体、又は、たとえば通信プロトコルに従って1つの場所から他の場所へコンピュータプログラムを転送することを実現しやすくする任意の媒体を有する通信媒体を含んでよい。このようにコンピュータ読み取り可能な媒体は、一般に、(1)有形の非一時的なコンピュータ読み取り可能な記録媒体、又は(2)信号又はキャリア波などの通信媒体、に相当するものであればよい。データ記録媒体は、本出願に説明される実施形態を実現する命令,符号及び/又はデータ構造を取得するために1つ以上のコンピュータ又は1つ以上のプロセッサによりアクセス可能な何らかの利用可能な媒体であればよい。コンピュータプログラム製品は、コンピュータ読み取り可能な媒体を含んでもよい。
【0091】
[0098]本明細書の実施形態の説明で使用された用語は、特定の実施形態を説明する目的だけのものであり、特許請求の範囲を限定することを意図したものではない。実施の形態の説明及び添付の特許請求の範囲で使用される「a」,「an」,「the」の単数形は、その文脈が明確に否定している場合を除き、複数形も含むことを意図したものである。また本明細書で使用される「及び/又は」との表現は、リスト化される関連項目のうちの1つ以上の任意かつ全てのありうる組合せを意味しかつ包含していることが理解されるであろう。さらに、「備える」("comprises")及び/又は「備えている」("comprising")との表現は、この明細書で使用される際には、定められた特徴,成分,及び/又は要素の存在を特定するものであるが、1つ以上の他の特徴,要素,部品,及び/又はこれらの組合せの存在又は追加を除外するものではないことが理解されるであろう。
【0092】
[0099]「第1の(先頭の)」及び「第2の」などの用語は、多種多様な要素を説明するために本明細書で使用されているが、これらの要素は、当該用語によって限定されるべきではないことも理解されるであろう。これらの用語は、要素同士を区別するためにのみ使用されている。たとえば、実施形態の範囲から逸脱しないように、第1の電極が第2の電極と呼ばれることがありうるし、同様に、第2の電極が第1の電極と呼ばれることもありうる。第1の電極と第2の電極とはともに電極であるが、同じ電極ではない。
【0093】
[00100]本出願の記述は、図示と説明のためになされたものであり、網羅的であること又は本発明に対する開示形態への限定を意図するものではない。上記説明及びその関連図面に示される教示の利益を受ける当業者であれば、多くの改良,変形及び代替的な実施形態は明らかであろう。本発明の原理や実際の適用例を最大限説明するために、また、当業者が種々の実施形態について本発明を理解して、その基礎をなす原理と、意図する特定の用途に適する種々の変形例とともに多種多様な実施形態とを最大限利用できるように、上記実施形態が選択され説明されている。したがって、特許請求の範囲は、開示された実施形態の特定例に限定されるべきではなく、変形例及び他の実施形態は添付の特許請求の範囲に包含されることを意図している点が理解されるべきである。
図1
図2
図3
図4A
図4B
図4C
図4D
図5A
図5B
図6