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

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

▶ 華為技術有限公司の特許一覧

特開2023-179582エンコーダ、デコーダ、及び対応する方法
<>
  • 特開-エンコーダ、デコーダ、及び対応する方法 図1
  • 特開-エンコーダ、デコーダ、及び対応する方法 図2
  • 特開-エンコーダ、デコーダ、及び対応する方法 図3
  • 特開-エンコーダ、デコーダ、及び対応する方法 図4
  • 特開-エンコーダ、デコーダ、及び対応する方法 図5
  • 特開-エンコーダ、デコーダ、及び対応する方法 図6
  • 特開-エンコーダ、デコーダ、及び対応する方法 図7
  • 特開-エンコーダ、デコーダ、及び対応する方法 図8
  • 特開-エンコーダ、デコーダ、及び対応する方法 図9
  • 特開-エンコーダ、デコーダ、及び対応する方法 図10
  • 特開-エンコーダ、デコーダ、及び対応する方法 図11
  • 特開-エンコーダ、デコーダ、及び対応する方法 図12
  • 特開-エンコーダ、デコーダ、及び対応する方法 図13
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023179582
(43)【公開日】2023-12-19
(54)【発明の名称】エンコーダ、デコーダ、及び対応する方法
(51)【国際特許分類】
   H04N 19/513 20140101AFI20231212BHJP
   H04N 19/70 20140101ALI20231212BHJP
【FI】
H04N19/513
H04N19/70
【審査請求】有
【請求項の数】15
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2023167760
(22)【出願日】2023-09-28
(62)【分割の表示】P 2021568302の分割
【原出願日】2020-05-14
(31)【優先権主張番号】62/848,410
(32)【優先日】2019-05-15
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】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)【発明者】
【氏名】ワーン,イエ-クイ
(57)【要約】      (修正有)
【課題】デコーダ側動きベクトル精密化をサポートするための方法を提供する。
【解決手段】復号化方法は、復号化される現在のピクチャの解像度が、現在のピクチャに関連する参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかを、ビデオ・デコーダにより決定し、現在のピクチャの解像度が、参照ピクチャ各々の解像度と同じであると決定した場合に、現在のピクチャの現在のブロックについて、デコーダ側動きベクトル精密化(DMVR)をビデオ・デコーダによりイネーブルにし、現在のピクチャの解像度が参照ピクチャの何れの解像度とも異なると決定した場合に、現在のピクチャの現在のブロックについてDMVRをビデオ・デコーダによりディセーブルにし、DMVRフラグが現在のブロックについてイネーブルにされる場合に、DMVRを使用して、現在のブロックに対応する動きベクトルをビデオ・デコーダにより精密化する。
【選択図】図10
【特許請求の範囲】
【請求項1】
ビデオ・エンコーダにより実行されるビデオ・ビットストリームを符号化する方法であって:
デコーダ側動きベクトル精密化(DMVR)ベースの双方向インター予測はイネーブルにされるかどうかを決定するステップ;
前記DMVRベースの双方向インター予測はイネーブルにされることを決定し、符号化される現在のピクチャの解像度が前記現在のピクチャに関連する参照ピクチャ・リストにおいて識別される参照ピクチャの解像度と同じであるかどうかを決定した場合に、前記ビデオ・ビットストリームのシーケンス・パラメータ・セット(SPS)において第1値を有する第1フラグを符号化するステップ;
前記現在のピクチャの前記解像度が前記参照ピクチャ各々の前記解像度と同じであると決定された場合に、前記現在のピクチャの現在のブロックについて、前記DMVRをイネーブルにするステップ;
前記現在のピクチャの前記解像度が前記参照ピクチャの何れの前記解像度とも異なると決定された場合に、前記現在のピクチャの前記現在のブロックについて、前記DMVRをディセーブルにするステップ;及び
前記ビデオ・エンコーダにより、前記現在のブロックを符号化するステップ;
を含む方法。
【請求項2】
請求項1に記載の方法において、前記方法は、更に:
前記DMVRが前記現在のブロックについてイネーブルにされる場合に、前記DMVRを使用して、前記現在のブロックに対応する動きベクトルを精密化するステップ;
を含む方法。
【請求項3】
請求項1又は2に記載の方法において、前記第1フラグは、sps_dmvr_enabled_flagで指定される、方法。
【請求項4】
請求項1ないし3のうちの何れか一項に記載の方法において、前記第1値は1である、方法。
【請求項5】
請求項1ないし4のうちの何れか一項に記載の方法において、前記方法は、更に:
前記DMVRベースの双方向インター予測はディセーブルにされることを決定した場合に、前記ビデオ・ビットストリームの前記SPSにおいて第2値を有する前記第1フラグを符号化するステップ
を含む方法。
【請求項6】
請求項1ないし5のうちの何れか一項に記載の方法において、前記方法は、更に:
前記参照ピクチャに基づいて、前記現在のピクチャに対する前記動きベクトルを決定するステップ;
前記動きベクトルに基づいて、前記現在のピクチャを符号化するステップ;及び
仮説的リファレンス・デコーダを用いて、前記現在のピクチャを復号化するステップ;
を含む方法。
【請求項7】
請求項1ないし6のうちの何れか一項に記載の方法において、前記DMVRをイネーブルにするステップが、DMVRフラグを第1値に設定するステップを含み、前記DMVRをディセーブルにするステップが、前記DMVRフラグを第2値に設定するステップを含む、方法。
【請求項8】
請求項1ないし7のうちの何れか一項に記載の方法において、双方向インター予測モードに従って前記参照ピクチャ・リストに基づいて前記現在のピクチャについて前記参照ピクチャを生成するステップを更に含む、方法。
【請求項9】
請求項1ないし8のうちの何れか一項に記載の方法において、各々のピクチャの前記解像度が、前記ピクチャに関連する参照ピクチャの前記解像度と相違するか又は同じであるかに依存して、複数のピクチャ内のブロックについて前記DMVRをイネーブルに及びディセーブルに両方を選択的に行うステップを更に含む、方法。
【請求項10】
請求項1ないし9のうちの何れか一項に記載の方法において、前記DMVRがディセーブルにされる場合でさえ、前記現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)をイネーブルにするステップを更に含む、方法。
【請求項11】
請求項1ないし10のうちの何れか一項に記載の方法において、前記現在のブロックを含む前記ビデオ・ビットストリームをビデオ・デコーダへ伝送するステップを更に含む、方法。
【請求項12】
請求項1ないし11のうちの何れか一項に記載の方法を実行する処理回路を含むエンコーダ。
【請求項13】
コンピュータ又はプロセッサで実行された場合に、請求項1ないし11のうちの何れか一項に記載の方法を実行するプログラム・コードを含むコンピュータ・プログラム。
【請求項14】
コンピュータ・デバイスにより実行された場合に、請求項1ないし11のうちの何れか一項に記載の方法を前記コンピュータ・デバイスに実行させるプログラム・コードを記憶する非一時的なコンピュータ読み取り可能な記憶媒体。
【請求項15】
解像度情報と第1フラグを含むビットストリームを記憶する非一時的なコンピュータ読み取り可能な媒体であって、前記第1フラグは、デコーダ側動きベクトル精密化(DMVR)ベースの双方向インター予測はイネーブルにされるかどうかを示し;第1値に等しい前記第1フラグは、DMVRベースの双方向インター予測はイネーブルにされることを示し、第2値に等しい前記第1フラグは、DMVRベースの双方向インター予測はディセーブルにされることを示し;
前記解像度情報は、符号化される現在のピクチャの解像度が前記現在のピクチャに関連する参照ピクチャ・リストにおいて識別される参照ピクチャの解像度と同じであるかどうかを決定して、前記第1フラグが前記第1値に等しい場合に、前記現在のピクチャの現在のブロックについて前記DMVRをイネーブルにするかどうかを決定するために使用され;
デコーダのプロセッサは、前記ビットストリームを復号化して:
復号化される現在のピクチャの解像度が前記現在のピクチャに関連する参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかを決定し;
前記現在のピクチャの前記解像度は前記参照ピクチャ各々の前記解像度と同じであると決定された場合に、前記現在のピクチャの現在のブロックについてDMVRをイネーブルにし;
前記現在のピクチャの前記解像度は、前記参照ピクチャの何れの前記解像度とも異なると決定された場合に、前記現在のピクチャの前記現在のブロックについて前記DMVRをディセーブルにし;及び
前記DMVRが前記現在のブロックについてイネーブルにされる場合に、前記DMVRを使用して、前記現在のブロックに対応する動きベクトルを精密化する、記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
一般に、本開示は、ビデオ・コーディングにおけるデコーダ側動きベクトル精密化(DMVR)をサポートするための技術を説明している。
【0002】
より具体的には、本開示は、参照ピクチャ・リサンプリングのためのDMVRを可能にするが、現在の及び参照ピクチャの空間解像度が異なる場合に、ブロック又はサンプルについてDMVRがディセーブルにされることを許容する。
【背景技術】
【0003】
比較的短いビデオでさえ描写するのに必要なビデオ・データの量は相当多くなる可能性があり、このことは、限られた帯域幅容量の通信ネットワークを介してデータがストリーミングされるか又は別の方法で通信される場合に、困難を生じる可能性がある。従って、ビデオ・データは一般に現代の電気通信ネットワークを介して通信される前に圧縮される。また、メモリ・リソースが制限される可能性があるので、ビデオがストレージ・デバイスに記憶される場合に、ビデオのサイズが問題となる可能性もある。ビデオ圧縮デバイスは、しばしば、伝送又は記憶の前にビデオ・データをコーディングするためにソースにおいてソフトウェア及び/又はハードウェアを使用し、それによってデジタル・ビデオ画像を表現するのに必要なデータ量を減少させている。次いで、圧縮されたデータは、ビデオ・データを復号化するビデオ解凍デバイスによって宛先で受信される。限られたネットワーク・リソース、より高いビデオ品質の絶えず増加する要求により、画像品質にほとんど犠牲を払わずに圧縮比を改善する改良された圧縮及び解凍技術が望ましい。
【発明の概要】
【0004】
第1態様は、ビデオ・デコーダにより実行されるコーディングされたビデオ・ビットストリームを復号化する方法に関連する。方法は、復号化される現在のピクチャの解像度が現在のピクチャに関連する参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかをビデオ・デコーダにより決定するステップ;現在のピクチャの解像度が参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについて、デコーダ側動きベクトル精密化(DMVR)を、ビデオ・デコーダによりイネーブルにするステップ;現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なると決定された場合に、現在のピクチャの現在のブロックについてDMVRを、ビデオ・デコーダによりディセーブルにするステップ;及び DMVRが現在のブロックについてイネーブルにされる場合に、DMVRを使用して、現在のブロックに対応する動きベクトルをビデオ・デコーダにより精密化するステップを含む。
【0005】
方法は、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0006】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:DMVRをイネーブルにするステップが、DMVRフラグを第1値に設定するステップを含み、DMVRをディセーブルにするステップが、DMVRフラグを第2値に設定するステップを含む。
【0007】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、双-方向インター予測モードに従って参照ピクチャ・リストに基づいて現在のピクチャについて参照ピクチャを生成するステップを提供する
【0008】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、各々のピクチャの解像度が、ピクチャに関連する参照ピクチャの解像度と相違するか又は同じであるかに依存して、複数のピクチャ内のブロックについてDMVRをイネーブルに及びディセーブルに両方を選択的に行うステップを提供する。
【0009】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、DMVRがディセーブルにされる場合に、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)をイネーブルにするステップを提供する。
【0010】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:現在のピクチャの解像度は、コーディングされたビデオ・ビットストリームのパラメータ・セット内に配置され、現在のブロックは現在のピクチャのスライスから取得される。
【0011】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、現在のブロックを用いて生成される画像を、電子デバイスのディスプレイで表示するステップを提供する。
【0012】
第2態様は、ビデオ・エンコーダにより実行されるビデオ・ビットストリームを符号化する方法に関連する。方法は、符号化される現在のピクチャの解像度が、現在のピクチャに関連する参照ピクチャ・リストで識別される参照ピクチャの解像度と同じであるかどうかを、ビデオ・エンコーダにより決定するステップ;現在のピクチャの解像度が、参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについて、デコーダ側動きベクトル精密化(DMVR)を、ビデオ・エンコーダによりイネーブルにするステップ;現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なると決定された場合に、現在のピクチャの現在のブロックについてDMVRをビデオ・エンコーダによりディセーブルにするステップ;及びDMVRが現在のブロックについてイネーブルにされる場合に、DMVRを使用して、現在のブロックに対応する動きベクトルを、ビデオ・エンコーダにより精密化するステップを含む。
【0013】
方法は、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0014】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、参照ピクチャに基づいて、現在のピクチャに対する動きベクトルを、ビデオ・エンコーダにより決定するステップ;動きベクトルに基づいて、現在のピクチャをビデオ・エンコーダにより符号化するステップ;及び仮説的リファレンス・デコーダを用いて、現在のピクチャをビデオ・エンコーダにより復号化するステップを提供する。
【0015】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:DMVRをイネーブルにするステップが、DMVRフラグを第1値に設定するステップを含み、DMVRをディセーブルにするステップが、DMVRフラグを第2値に設定するステップを含む。
【0016】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、双-方向インター予測モードに従って参照ピクチャ・リストに基づいて現在のピクチャについて参照ピクチャを生成するステップを提供する。
【0017】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、各々のピクチャの解像度が、ピクチャに関連する参照ピクチャの解像度と相違するか又は同じであるかに依存して、複数のピクチャ内のブロックについてDMVRをイネーブルに及びディセーブルに両方を選択的に行うステップを提供する。
【0018】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、DMVRがディセーブルにされる場合でさえ、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)をイネーブルにするステップを提供する。
【0019】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、現在のブロックを含むビデオ・ビットストリームをビデオ・デコーダへ送信するステップを提供する。
【0020】
第3態様は復号化デバイスに関連する。復号化デバイスは、コーディングされたビデオ・ビットストリームを受信するように構成された受信機;受信機に結合されたメモリであって、命令を記憶しているメモリ;及びメモリに結合されたプロセッサを含み、プロセッサは、復号化デバイスに:復号化される現在のピクチャの解像度が現在のピクチャに関連する参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかを決定するステップ;現在のピクチャの解像度が参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについて、デコーダ側動きベクトル精密化(DMVR)をイネーブルにするステップ;現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なると決定された場合に、現在のピクチャの現在のブロックについてDMVRをディセーブルにするステップ;及びDMVRが現在のブロックについてイネーブルにされる場合に、DMVRを使用して、現在のブロックに対応する動きベクトルを精密化するステップを行わせる命令を実行するように構成されている。
【0021】
復号化デバイスは、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0022】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:DMVRがディセーブルにされる場合に、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる。
【0023】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は、現在のブロックに基づいて生成されるような画像を表示するように構成されたディスプレイを提供する。
【0024】
第4態様は符号化デバイスに関連する。符号化デバイスは、命令を含むメモリ;メモリに結合されたプロセッサを含み、プロセッサは、符号化デバイスに:符号化される現在のピクチャの解像度が現在のピクチャに関連する参照ピクチャ・リスト内で識別される参照ピクチャの解像度と同じであるかどうかを決定するステップ;現在のピクチャの解像度が、参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについて、デコーダ側動きベクトル精密化(DMVR)をイネーブルにするステップ;現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なると決定された場合に、現在のピクチャの現在のブロックについてDMVRをディセーブルにするステップ;DMVRが現在のブロックについてイネーブルにされる場合に、DMVRを使用して、現在のブロックに対応する動きベクトルを精密化するステップ;及びを行わせる命令を実行するように構成されており、符号化デバイスは、プロセッサに結合される送信機であって、現在のビデオ・ブロックを含むビデオ・ビットストリームをビデオ・デコーダへ送信するように構成された送信機を含む。
【0025】
符号化デバイスは、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0026】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:DMVRがディセーブルにされる場合でさえ、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる。
【0027】
オプションとして、上記の態様のうちの何れかにおいて、別の実装態様は以下を提供する:メモリは、送信機がビットストリームをビデオ・デコーダへ送信する前にビデオ・ビットストリームを記憶する。
【0028】
第5態様はコーディング装置に関連する。コーディング装置は、符号化するピクチャを受信するか又は復号化するビットストリームを受信するように構成された受信機;受信機に結合された送信機であって、ビットストリームをデコーダへ送信するか又は復号化された画像をディスプレイへ送信するように構成された送信機;受信機又は送信機のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成されたメモリ;及びメモリに結合されたプロセッサであって、本件で開示される何れかの方法を実行するためにメモリに記憶された命令を実行するように構成されたプロセッサを含む。
【0029】
コーディング装置は、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0030】
第6態様はシステムに関連する。システムは、エンコーダ;及びエンコーダと通信するデコーダを含み、エンコーダ又はデコーダは、本件で開示される復号化デバイス、符号化デバイス、又はコーディング装置を含む。
【0031】
システムは、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、参照ピクチャ・リサンプリング(RPR)がイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術を提供する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【図面の簡単な説明】
【0032】
本開示のより完全な理解のために、添付図面及び詳細な説明に関連する以下の簡単な説明を参照する。ここで、同様な参照番号は同様な部分を表現する。
【0033】
図1】ビデオ・コーディング技術を利用することが可能な例示的なコーディング・システムを示すブロック図である。
【0034】
図2】ビデオ・コーディング技術を実装することが可能な例示的なビデオ・エンコーダを示すブロック図である。
【0035】
図3】ビデオ・コーディング技術を実装することが可能なビデオ・デコーダの一例を示すブロック図である。
【0036】
図4】リーディング・ピクチャに対するIRAPピクチャとトレーリング・ピクチャとの間の関係を復号化順序とプレゼンテーション順序で表現したものである。
【0037】
図5】空間スケーラビリティのためのマルチ・レイヤ・コーディングの例を示す。
【0038】
図6】一方向インター予測の一例を示す概略図である。
【0039】
図7】双方向インター予測の一例を示す概略図である。
【0040】
図8】ビデオ・ビットストリームを示す。
【0041】
図9】ピクチャのパーティショニング技術を示す。
【0042】
図10】コーディングされたビデオ・ビットストリームを復号化する方法の実施形態である。
【0043】
図11】コーディングされたビデオ・ビットストリームを符号化する方法の実施形態である。
【0044】
図12】ビデオ・コーディング・デバイスの概略図である。
【0045】
図13】コーディング手段の実施形態の概略図である。
【発明を実施するための形態】
【0046】
1つ以上の実施形態のうちの例示的な実施形態が以下に提供されるが、開示されるシステム及び/又は方法は、現在知られているか又は存在するかどうかによらず、任意の数の技術を使用して実施されてもよいことが、最初に理解されるべきである。本開示は、本件で図示され且つ説明される例示的な設計及び実装を含む、以下に示される例示的な実装、図面、及び技術には決して限定されず、添付のクレームの範囲内で、それらの均等物の全範囲と共に修正されることが可能である。
【0047】
本件で使用されるように、解像度はビデオ・ファイルのピクセル数を表す。即ち、解像度は、ピクセル単位で測定された投影画像の幅及び高さである。例えば、ビデオは、1280(水平ピクセル)×720(垂直ピクセル)の解像度を有する可能性がある。これは通常、単に1280×720のように書かれ、又は720pと略記される。DMVRは、予測されるブロックに対する動き又は動きベクトルを精密化するために使用されるプロセス、アルゴリズム、又はコーディング・ツールである。DMVRは、バイラテラル・テンプレート・マッチング・プロセスを用いて、双-予測のために発見された2つの動きベクトルに基づいて、動きベクトルが発見されることを許容する。DMVRでは、2つの動きベクトルの各々で生成された予測コーディング・ユニットの重み付けされた組み合わせを発見することが可能であり、2つの動きベクトルは、それらを、結合された予測コーディング・ユニットを最適に指し示す新しい動きベクトルで置換することによって、精密化されることが可能である。RPR機能は、解像度・変更位置でのピクチャのイントラ・コーディングを必要とせずに、ビットストリームの途中にあるコーディングされたピクチャの空間解像度を変える能力である
【0048】
図1は、本件で説明されるようなビデオ・コーディング技術を利用することが可能な例示的なコーディング・システム10を示すブロック図である。図1に示すように、コーディング・システム10は、ソース・デバイス12であって後に宛先デバイス14によって復号化されるべき符号化されたビデオ・データを提供するものを含む。特に、ソース・デバイス12は、コンピュータ読み取り可能な媒体16を介して、ビデオ・データを宛先デバイス14へ提供することができる。ソース・デバイス12及び宛先デバイス14は、デスクトップ・コンピュータ、ノートブック(例えば、ラップトップ)コンピュータ、タブレット・コンピュータ、セット・トップ・ボックス、「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイ・デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・コンソール、ビデオ・ストリーミング・デバイスなどを含む、広範囲のデバイスのうちの何れかを含む可能性がある。幾つかのケースにおいて、ソース・デバイス12及び宛先デバイス14は、無線通信用に装備されていてもよい。
【0049】
宛先デバイス14は、コンピュータ読み取り可能な媒体16を介して、復号化されることになる符号化されたビデオ・データを受信することができる。コンピュータ読み取り可能な媒体16は、符号化されたビデオ・データを、ソース・デバイス12から宛先デバイス14へ移動させるすることが可能な任意のタイプの媒体又はデバイスを含むことが可能である。一例において、コンピュータ読み取り可能な媒体16は、ソース・デバイス12が、符号化されたビデオ・データを宛先デバイス14へリアル・タイムで直接的に伝送することを可能にする通信媒体を含む可能性がある。符号化されたビデオ・データは、無線通信プロトコルのような通信規格に従って変調され、宛先デバイス14へ伝送されることが可能である。通信媒体は、任意の無線又は有線の通信媒体、例えば、無線周波数(RF)スペクトル又は1つ以上の物理的な送信ラインを含む可能性がある。通信媒体は、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、又はインターネットのようなグローバル・ネットワークのようなパケット・ベースのネットワークの一部を構成することが可能である。通信媒体は、ルーター、スイッチ、基地局、又は他の任意の機器であって、ソース・デバイス12から宛先デバイス14への通信を促進するために役立つ可能性のあるものを含む可能性がある。
【0050】
幾つかの例では、符号化されたデータは出力インターフェース22からストレージ・デバイスへ出力されてもよい。同様に、符号化されたデータは、入力インターフェースを介してストレージ・デバイスからアクセスされる可能性がある。ストレージ・デバイスは、任意の様々な分散された又はローカルにアクセスされるデータ記憶媒体、例えば、ハード・ドライブ、ブルーレイ・ディスク、デジタル多用途ディスク(DVD)、コンパクト・ディスク・リード・オンリー・メモリ(CD-ROM)、フラッシュ・メモリ、揮発性又は不揮発性メモリ、又は符号化されたビデオ・データを記憶する適切な他の任意のデジタル記憶媒体を含む可能性がある。別の例において、ストレージ・デバイスは、ソース・デバイス12によって生成された符号化されたビデオを記憶することが可能なファイル・サーバー又は別の中間的なストレージ・デバイスに対応してもよい。宛先デバイス14は、ストリーミング又はダウンロードにより、ストレージ・デバイスからの記憶されたビデオ・データにアクセスすることが可能である。ファイル・サーバーは、符号化されたビデオ・データを記憶し、符号化されたビデオ・データを宛先デバイス14へ送信することが可能な任意のタイプのサーバーであるとすることが可能である。ファイル・サーバーの具体例は、ウェブ・サーバー(例えば、ウェブサイト)、ファイル転送プロトコル(FTP)サーバー、ネットワーク接続ストレージ(NAS)デバイス、又はローカル・ディスク・ドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準データ接続を介して、符号化されたビデオ・データにアクセスすることができる。これは、ファイル・サーバーに記憶された符号化されたビデオ・データにアクセスするのに適した無線チャネル(例えば、Wi-Fi)接続)、有線接続(例えば、デジタル加入者回線(DSL)、ケーブル・モデムなど)、又は双方の組み合わせを含む可能性がある。ストレージ・デバイスからの符号化されたビデオ・データの送信は、ストリーミング送信、ダウンロード送信、又はそれらの組み合わせであってもよい。
【0051】
本開示の技術は必ずしも無線のアプリケーションや設定に限定されない。技術は、任意の様々なマルチメディア・アプリケーション、例えば、オーバー・ザ・エアー・テレビジョン放送、ケーブル・テレビジョン伝送、衛星テレビジョン伝送、HTTPを介する動的適応ストリーミング(DASH)のようなインターネット・ストリーミングビデオ伝送、データ記憶媒体において符号化されているデジタル・ビデオ、データ記憶媒体に記憶されたデジタル・ビデオの復号化、又は他のアプリケーション、をサポートする際にビデオ・コーディングに適用されることが可能である。幾つかの例において、コーディング・システム10は、ビデオ・ストリーミング、ビデオ再生、ビデオ放送、及び/又はビデオ電話のようなアプリケーションをサポートするために、一方向又は双方向のビデオ伝送をサポートするように構成されてもよい。
【0052】
図1の例において、ソース・デバイス12は、ビデオ・ソース18、ビデオ・エンコーダ20、及び出力インターフェース22を含む。宛先デバイス14は、入力インターフェース28、ビデオ・デコーダ30、及びディスプレイ・デバイス32を含む。本開示によれば、ソース・デバイス12のビデオ・エンコーダ20及び/又は宛先デバイス14のビデオ・デコーダ30は、ビデオ・コーディングのための技術を適用するように構成することが可能である。他の例では、ソース・デバイス及び宛先デバイスは、他の構成要素又は配置を含んでもよい。例えば、ソース・デバイス12は、外部カメラのような外部ビデオ・ソースからビデオ・データを受信することができる。同様に、宛先デバイス14は、一体化された表示デバイスを含むのではなく、外部表示デバイスとのインターフェースがあってもよい。
【0053】
図1に示されるコーディング・システム10は、単なる一例に過ぎない。ビデオ・コーディングのための技術は、任意のデジタル・ビデオ符号化及び/又は復号化デバイスによって実行される可能性がある。本開示の技術は、一般に、ビデオ・コーディング・デバイスによって実行されるが、技術はまた、典型的には「CODEC」と呼ばれるビデオ・エンコーダ/デコーダによって実行されてもよい。更に、本開示の技術はまたビデオ・プロセッサにより実行されてもよい。ビデオ・エンコーダ及び/又はデコーダは、グラフィックス処理ユニット(GPU)又は類似のデバイスであってもよい。
【0054】
ソース・デバイス12及び宛先デバイス14は、ソース・デバイス12が、宛先デバイス14への伝送のために、符号化されたビデオ・データを生成するようなコーディング・デバイスの単なる例である。幾つかの例において、ソース・デバイス12及び宛先デバイス14は、ソース・デバイス12及び宛先デバイス14の各々がビデオ符号化及び復号化コンポーネントを含むように、実質的に対称的な方法で動作することができる。従って、コーディング・システム10は、例えばビデオ・ストリーミング、ビデオ再生、ビデオ放送、又はビデオ電話のために、ビデオ・デバイス12、14の間の一方向又は双方向ビデオ伝送をサポートすることができる。
【0055】
ソース・デバイス12のビデオ・ソース18は、ビデオ・カメラのようなビデオ・キャプチャ・デバイス、以前にキャプチャされたビデオを収容するビデオ・アーカイブ、及び/又はビデオ・コンテンツ・プロバイダからビデオを受け取るためのビデオ・フィード・インターフェースを含む可能性がある。更なる代替として、ビデオ・ソース18は、ソース・ビデオ、又はライブ・ビデオ、アーカイブに保管されたビデオ、及びコンピュータで生成されたビデオの組み合わせとして、コンピュータ・グラフィックス・ベースのデータを生成することができる。
【0056】
幾つかのケースにおいて、ビデオ・ソース18がビデオ・カメラである場合に、ソース・デバイス12及び宛先デバイス14は、いわゆるカメラ・フォン又はビデオ・フォンを形成する可能性がある。しかしながら、上述のように、本開示で説明される技術は、一般にビデオ・コーディングに適用可能であり、無線及び/又は有線アプリケーションに適用可能である。各々のケースにおいて、キャプチャされる、予めキャプチャされた、又はコンピュータで生成されたビデオは、ビデオ・エンコーダ20によって符号化されることが可能である。次いで、符号化されたビデオ情報は、出力インターフェース22によって、コンピュータ読み取り可能な媒体16に出力されることが可能である。
【0057】
コンピュータ読み取り可能な媒体16は、ワイヤレス・ブロードキャスト又は有線ネットワーク伝送のような一時的な媒体、又はハード・ディスク、フラッシュ・ドライブ、コンパクト・ディスク、デジタル・ビデオ・ディスク、ブルーレイ・ディスク、又は他のコンピュータ読み取り可能な媒体のような記憶媒体(即ち、非一時的な記憶媒体)を含む可能性がある。幾つかの例において、ネットワーク・サーバー(図示せず)は、符号化されたビデオ・データをソース・デバイス12から受信し、符号化されたビデオ・データを、例えばネットワーク伝送を介して宛先デバイス14へ提供することが可能である。同様に、ディスク・スタンピング装置のような媒体製造装置のコンピューティング・デバイスは、符号化されたビデオ・データをソース・デバイス12から受信し、符号化されたビデオ・データを含むディスクを生成することができる。従って、コンピュータ読み取り可能な媒体16は、種々の例において、種々の形態のうちの1つ以上のコンピュータ読み取り可能な媒体を含むように理解することができる。
【0058】
宛先デバイス14の入力インターフェース28は、コンピュータ読み取り可能な媒体16から情報を受信する。コンピュータ読み取り可能な媒体16の情報は、ビデオ・エンコーダ20によって規定されるシンタックス情報であって、ビデオ・デコーダ30によっても使用され、ブロック及び/又は他のコーディングされたユニット、例えばピクチャのグループ(GOP)の特徴及び/又は処理を記述するシンタックス要素を含む可能性がある。ディスプレイ・デバイス32は、復号化されたビデオ・データをユーザーに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマ・ディスプレイ、有機発光ダイオード(OLED)ディスプレイ、又は他のタイプのディスプレイ・デバイスのような様々なディスプレイ・デバイスのうちの何れかを含む可能性がある。
【0059】
ビデオ・エンコーダ20及びビデオ・デコーダ30は、現在開発中の高効率ビデオ・コーディング(HEVC)規格のようなビデオ・コーディング規格に従って動作することが可能であり、HEVCテスト・モデル(HM)に適合することが可能である。代替的に、ビデオ・エンコーダ20及びビデオ・デコーダ30は、国際電気通信連合・電気通信標準化部門(ITU-T)H.264規格のような他の専有又は産業規格、代替的に動画エキスパート・グループ(MPEG)-4,パート10,アドバンスト・ビデオ・コーディング(AVC),H.265/HEVCと言及されるもの、又はそのような規格の拡張に従って動作することができる。しかしながら、本開示の技術は、何らかの特定のコーディング規格に限定されない。ビデオ・コーディング規格の他の例は、MPEG-2及びITU-T H.263を含む。図1には示されていないが、幾つかの態様では、ビデオ・エンコーダ20及びビデオ・デコーダ30はそれぞれ、オーディオ・エンコーダ及びデコーダと一体化されてもよく、共通のデータ・ストリーム又は別個のデータ・ストリームにおけるオーディオ及びビデオの両方の符号化を処理するために、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット又は他のハードウェア及びソフトウェアを含んでもよい。該当する場合には、MUX-DEMUXユニットは、ITU H.223マルチプレクサ・プロトコル、又はユーザー・データグラム・プロトコル(UDP)のような他のプロトコルに準拠してもよい。
【0060】
ビデオ・エンコーダ20及びビデオ・デコーダ30はそれぞれ、1つ以上のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールド・プログラマブル・ゲート・アレイ(FPGA)、個別ロジック、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせのような、任意の種々の適切なエンコーダ回路として実現される可能性がある。技術が部分的にソフトウェアで実装される場合、デバイスは、ソフトウェアのための命令を、適切な非一時的なコンピュータ読み取り可能な媒体に記憶し、本開示の技術を実行するために1つ以上のプロセッサを使用するハードウェアで命令を実行することができる。ビデオ・エンコーダ20及びビデオ・デコーダ30の各々は、1つ以上のエンコーダ又はデコーダに含まれる可能性があり、これらのうちの何れも、各自のデバイス内で、組み合わされたエンコーダ/デコーダ(CODEC)の一部として統合されてもよい。ビデオ・エンコーダ20及び/又はビデオ・デコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、及び/又は、セルラ電話機のような無線通信デバイスを含むことができる。
【0061】
図2は、ビデオ・コーディング技術を実装することが可能なビデオ・エンコーダ20の例を示すブロック図である。ビデオ・エンコーダ20は、ビデオ・スライス内のビデオ・ブロックのイントラ及びインター・コーディングを実行することができる。イントラ・コーディングは、所与のビデオ・フレーム又はピクチャ内のビデオにおける空間的冗長性を低減又は除去するために空間的予測を当てにしている。インター・コーディングは、ビデオ・シーケンスの隣接するフレーム又はピクチャ内のビデオにおける時間的冗長性を低減又は除去するために、時間的予測を当てにしている。イントラ・モード(Iモード)は、幾つかの空間ベースの符号化モードのうちの何れかを参照することができる。一方向予測(片予測としても知られている)(P mode)又は双方向(双予測としても知られている)(B mode)のようなインターモードは、幾つかの時間ベースのコーディング・モードのうちの何れかを参照することができる。
【0062】
図2に示すように、ビデオ・エンコーダ20は、符号化されることになるビデオ・フレーム内の現在のビデオ・ブロックを受信する。図2の例では、ビデオ・エンコーダ20は、モード選択ユニット40、参照フレーム・メモリ64、加算器50、変換処理ユニット52、量子化ユニット54、エントロピー・コーディング・ユニット56を含む。モード選択ユニット40は、次に、動き補償ユニット44、動き推定ユニット42、イントラ予測(intra prediction)ユニット46、及びパーティション・ユニット48を含む。ビデオ・ブロック再構成のために、ビデオ・エンコーダ20はまた、逆量子化ユニット58、逆変換ユニット60、及び加算器62を含む。また、ブロック境界をフィルタリングして、ブロッキネス・アーチファクトを再構成されたビデオから除去するために、デブロッキング・フィルタ(図2には示されていない)が含められてもよい。所望であれば、デブロッキング・フィルタは、典型的には、加算器62の出力をフィルタリングする。また、デブロッキング・フィルタに加えて、追加のフィルタ(イン・ループ又はポスト・ループ)が使用されてもよい。このようなフィルタは、簡略化のために図示されてはいないが、望まれる場合には、(イン・ループ・フィルタとして)加算器50の出力をフィルタリングすることができる。
【0063】
符号化プロセスの間に、ビデオ・エンコーダ20は、コーディングされることとなるビデオ・フレーム又はスライスを受信する。フレーム又はスライスは、複数のビデオ・ブロックに分割されてもよい。動き推定ユニット42及び動き補償ユニット44は、時間的予測を提供するために、1つ以上の参照フレーム内の1つ以上のブロックに対して受信されたビデオ・ブロックのインター予測コーディングを実行する。また、イントラ予測ユニット46は、代替的に、空間予測を提供するために、コーディングされるべきブロックと同じフレーム又はスライス内の1つ以上の隣接するブロックに関連して、受信したビデオ・ブロックのイントラ予測コーディングを実行することができる。ビデオ・エンコーダ20は、例えばビデオ・データの各ブロックに対して適切なコーディング・モードを選択するために、複数のコーディング・パスを実行することができる。
【0064】
更に、パーティション・ユニット48は、以前のコーディング・パスにおける以前のパーティション化方式の評価に基づいて、ビデオ・データのブロックをサブ・ブロックにパーティション化することができる。例えば、パーティション・ユニット48は、最初に、フレーム又はスライスを、最大のコーディング・ユニット(LCU)にパーティション化し、各LCUを、レート歪解析(例えば、レート歪最適化)に基づいてサブ・コーディング・ユニットにパーティション化する。モード選択ユニット40は、更に、LCUをサブCUにパーティション化することを示す四分木データ構造を生成することができる。四分木のリーフ・ノードCUは、1つ以上の予測ユニット(PU)と1つ以上の変換ユニット(TU)を含むことができる。
【0065】
本開示は、「ブロック」という用語を使用して、HEVCの文脈におけるCU、PU又はTUのうちの何れか、又は他の規格の文脈における類似のデータ構造(例えば、H.264/AVCにおけるそのマクロブロック及びそのサブ・ブロック)に言及している。CUは、コーディング・ノード、PU、及び、コーディング・ノードに関連するTUを含む。CUのサイズはコーディング・ノードのサイズに対応し、正方形の形状である。CUのサイズは、8×8ピクセルから、最大の64×64ピクセル以上のツリーブロックのサイズまでの範囲に及ぶ可能性がある。各CUは、1つ以上のPU及び1つ以上のTUを含む可能性がある。CUに関連するシンタックス・データは、例えば、CUの1つ以上のPUへのパーティション化を述べている可能性がある。パーティション化モードは、CUがスキップされるか又はダイレクト・モード符号化、イントラ予測モード符号化、又はインター予測(inter prediction)モード符号化であるかどうかによって相違する可能性がある。PUは、非正方形の形状であるようにパーティション化されてもよい。また、CUに関連するシンタックス・データは、例えば、CUを、四分木に従う1つ以上のTUへパーティション化することを述べている可能性がある。TUは、正方形又は非正方形(例えば、長方形)の形状である可能性がある。
【0066】
モード選択ユニット40は、インター又はイントラのコーディング・モードのうちの1つを、例えばエラー結果に基づいて選択し、結果のイントラ又はインター・コーディングされたブロックを、加算器50に提供して残差ブロック・データを生成し、且つ符号化されたブロックを再構成する加算器62に提供して参照フレームとして使用する。モード選択ユニット40はまた、動きベクトル、イントラ・モード・インジケータ、パーティション情報、及び他のこのような構文情報のようなシンタックス要素を、エントロピー・コーディング・ユニット56に提供する。
【0067】
動き推定ユニット42及び動き補償ユニット44は、高度に統合されてもよいが、概念的な目的のために別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオ・ブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、現在のフレーム内でコーディングされている現在のブロック(又は他のコーディングされたユニット)に対する参照フレーム内の予測ブロックに対する、現在のビデオ・フレーム又はピクチャ内のビデオ・ブロックのPUの変位を示すことができる。予測ブロックは、絶対差分(SAD)、二乗差分和(SSD)、又は他の差分メトリックによって決定することが可能なピクセル差分の観点から、コーディングされることになるブロックに密接に一致することが発見されたブロックである。幾つかの例では、ビデオ・エンコーダ20は、参照フレーム・メモリ64に記憶された参照ピクチャのサブ整数ピクセル位置に対する値を計算することができる。例えば、ビデオ・エンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、又は他の小数ピクセル位置の値を補間することができる。よって、動き推定ユニット42は、完全ピクセル位置及び小数ピクセル位置に対する動きサーチを実行し、小数ピクセル精度の動きベクトルを出力することができる。
【0068】
動き推定ユニット42は、PUの位置を、参照ピクチャの予測ブロックの位置と比較することによって、インター・コーディングされたスライス内のビデオ・ブロックのPUに対する動きベクトルを計算する。参照ピクチャは、第1参照ピクチャ・リスト(List 0)又は第2参照ピクチャ・リスト(List 1)から選択することが可能であり、これらの各々は参照フレーム・メモリ64に記憶された1つ以上の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルを、エントロピー符号化ユニット56及び動き補償ユニット44へ送る。
【0069】
動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定される動きベクトルに基づいて、予測ブロックをフェッチ又は生成することを含む可能性がある。また、幾つかの例では、動き推定ユニット42及び動き補償ユニット44は機能的に統合されてもよい。現在のビデオ・ブロックのPUに対する動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャ・リストのうちの1つにおいて動きベクトルが指し示す予測ブロックの位置を特定することができる。加算器50は、後述するように、予測ブロックのピクセル値を、コーディングされる現在のビデオ・ブロックのピクセル値から減算することによって、残差ビデオ・ブロックを形成し、ピクセル差分値を形成する。一般に、動き推定ユニット42は、ルマ成分に対する動き推定を実行し、動き補償ユニット44は、クロマ成分とルマ成分の両方に対するルマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40は、ビデオ・スライスのビデオ・ブロックを復号化する際にビデオ・デコーダ30による使用のために、ビデオ・ブロック及びビデオ・スライスに関連するシンタックス要素を生成することも可能である。
【0070】
イントラ予測ユニット46は、上述したような動き推定ユニット42及び動き補償ユニット44により実行されるインター予測に代わるものとして、現在のブロックをイントラ予測することができる。特に、イントラ予測ユニット46は、現在のブロックを符号化するために使用するイントラ予測モードを決定することができる。幾つかの例において、イントラ予測ユニット46は、例えば別々の符号化パスの間に、種々のイントラ予測モードを使用して現在のブロックを符号化することが可能であり、イントラ予測ユニット46(又は、幾つかの例では、モード選択ユニット40)は、テストされたモードから、使用するのに適したイントラ予測モードを選択することができる。
【0071】
例えば、イントラ予測ユニット46は、テストされた様々なイントラ予測モードに対してレート歪解析を用いてレート歪値を計算し、テストされたモードの中で最適なレート歪特性を有するイントラ予測モードを選択することができる。レート歪解析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化されたオリジナルの符号化されていないブロックとの間の歪み(又はエラー)の量、並びに、符号化されたブロックを生成するために使用されるビットレート(即ち、ビット数)を決定する。イントラ予測ユニット46は、種々の符号化されたブロックに対する歪及びレートから比率を計算し、どのイントラ予測モードが、ブロックに対する最良のレート歪値を示すのかを決定することができる。
【0072】
更に、イントラ予測ユニット46は、深度モデリング・モード(DMM)を使用して深度マップの深度ブロックをコーディングするように構成されてもよい。モード選択ユニット40は、例えばレート歪最適化(RDO)を用いて、利用可能なDMMモードが、イントラ予測モード及び他のDMMモードよりも良好なコーディング結果をもたらすかどうかを決定することができる。深度マップに対応するテクスチャ画像のデータは、参照フレーム・メモリ64に記憶することができる。また、動き推定ユニット42及び動き補償ユニット44は、深度マップの深度ブロックをインター予測するように構成されてもよい。
【0073】
ブロックに対するイントラ予測モード(例えば、従来のイントラ予測モード又は複数のDMMモードのうちの1つのDMMモード)を選択した後に、イントラ予測ユニット46は、ブロックに対する選択されたイントラ予測モードを示す情報を、エントロピー・コーディング・ユニット56へ提供することができる。エントロピー・コーディング・ユニット56は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオ・エンコーダ20は、伝送されるビットストリーム・コンフィギュレーション・データであって、複数のイントラ予測モード・インデックス・テーブルと複数の修正されたイントラ予測モード・インデックス・テーブル(コードワード・マッピング・テーブルとも呼ばれる)とを含むことが可能なビットストリーム・コンフィギュレーション・データの中に、様々なブロックに対する符号化コンテキストの定義、及び最確イントラ予測モードの指示、イントラ予測モード・インデックス・テーブル、及び各コンテキストのために使用する修正されたイントラ予測モード・インデックス・テーブルを含めることが可能である。
【0074】
ビデオ・エンコーダ20は、モード選択ユニット40からの予測データを、コーディングされるオリジナル・ビデオ・ブロックから減算することによって、残差ビデオ・ブロックを形成する。加算器50は、この減算演算を実行する1つのコンポーネント又は複数のコンポーネントを表す。
【0075】
変換処理ユニット52は、離散コサイン変換(DCT)又は概念的に類似した変換のような変換を、残差ブロックに適用し、残差変換係数値を含むビデオ・ブロックを生成する。変換処理ユニット52は、DCTに概念的に類似する他の変換を実行してもよい。ウェーブレット変換、整数変換、サブ・バンド変換、又は他のタイプの変換も使用することも可能である。
【0076】
変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値ドメインから周波数ドメインのような変換ドメインへ変換することができる。変換処理ユニット52は、結果の変換係数を、量子化ユニット54へ送ることができる。量子化ユニット54は、変換係数を量子化して、ビットレートを更に低下させる。量子化プロセスは、係数のうちの一部又は全部に関連するビット深度を減らすことができる。量子化の程度は、量子化パラメータを調整することによって修正することができる。幾つかの例では、量子化ユニット54は、その後、量子化された変換係数を含む行列のスキャンを実行してもよい。代替的に、エントロピー符号化ユニット56がスキャンを実行してもよい。
【0077】
量子化の後、エントロピー・コーディング・ユニット56は、量子化された変換係数をエントロピー・コード化する。例えば、エントロピー・コーディング・ユニット56は、コンテキスト適応可変長コーディング(CAVLC)、コンテキスト適応バイナリ演算コーディング(CABAC)、シンタックス・ベースのコンテキスト適応バイナリ算術コーディング(SBAC)、確率インターバル・パーティショニング・エントロピー(PIPE)コーディング、又は他のエントロピー・コーディング技術を実行することが可能である。コンテキスト・ベースのエントロピー・コーディングの場合、コンテキストは隣接ブロックに基づくことができる。エントロピー・コーディング・ユニット56によるエントロピー・コーディングに続いて、符号化されたビットストリームは、別のデバイス(例えば、ビデオ・デコーダ30)へ伝送されることが可能であり、又は後の伝送又は検索のためにアーカイブに保管されてもよい。
【0078】
逆量子化ユニット58及び逆変換ユニット60はそれぞれ逆量子化及び逆変換を適用して、ピクセル・ドメインにおける残差ブロックを、例えば後に参照ブロックとして使用するために再構成する。動き補償ユニット44は、参照フレーム・メモリ64のフレームのうちの1つのフレームの予測ブロックに、残差ブロックを加えることによって参照ブロックを計算することができる。また、動き補償ユニット44は、1つ以上の補間フィルタを、再構成された残差ブロックに適用して、動き推定で使用するためのサブ整数ピクセル値を計算することもできる。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに追加し、参照フレーム・メモリ64に記憶するための再構成されたビデオ・ブロックを生成する。再構成されたビデオ・ブロックは、後続のビデオ・フレーム内でブロックをインター・コーディングするための参照ブロックとして、動き推定ユニット42及び動き補償ユニット44によって使用されることが可能である。
【0079】
図3は、ビデオ・コーディング技術を実装することが可能なビデオ・デコーダ30の例を示すブロック図である。図3の例では、ビデオ・デコーダ30は、エントロピー復号化ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレーム・メモリ82、及び加算器80を含む。ビデオ・デコーダ30は、幾つかの例において、ビデオ・エンコーダ20(図2)に関して説明した符号化パスと概ね逆数の復号化パスを実行することができる。動き補償ユニット72は、エントロピー復号化ユニット70から受け取った動きベクトルに基づいて予測データを生成することができる一方、イントラ予測ユニット74は、エントロピー復号化ユニット70から受け取ったイントラ予測モード・インジケータに基づいて予測データを生成することができる。
【0080】
復号化プロセスの間に、ビデオ・デコーダ30は、復号化されたビデオ・スライスのビデオ・ブロックと関連するシンタックス要素とを表す符号化されたビデオ・ビットストリームを、ビデオ・エンコーダ20から受信する。ビデオ・デコーダ30のエントロピー復号化ユニット70は、ビットストリームを復号化し、量子化された係数、動きベクトル又はイントラ予測モード・インジケータ、及びその他のシンタックス要素を生成する。エントロピー復号化ユニット70は、動きベクトル及び他のシンタックス要素を、動き補償ユニット72へ転送する。ビデオ・デコーダ30は、ビデオ・スライス・レベル及び/又はビデオ・ブロック・レベルでシンタックス要素を受信することができる。
【0081】
ビデオ・スライスがイントラ・コーディングされた(I)スライスとしてコーディングされると、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在のフレーム又はピクチャの以前に復号化されたブロックからのデータとに基づいて、現在のビデオ・スライスのビデオ・ブロックに関する予測データを生成することができる。ビデオ・フレームがインター・コーディングされた(例えば、B、P又はGPB)スライスとしてコーディングされると、動き補償ユニット72は、エントロピー復号化ユニット70から受け取った動きベクトルと他のシンタックス要素に基づいて、現在のビデオ・スライスのビデオ・ブロックに対する予測ブロックを生成する。予測ブロックは、参照ピクチャ・リストのうちの1つの中で参照ピクチャのうちの1つから生成されることが可能である。ビデオ・デコーダ30は、参照フレーム・メモリ82に記憶された参照ピクチャに基づくデフォルトの構築技術を使用して、参照フレーム・リスト、List 0及びList 1を構築することができる。
【0082】
動き補償ユニット72は、動きベクトル及び他のシンタックス要素を解析することによって、現在のビデオ・スライスのビデオ・ブロックの予測情報を決定し、その予測情報を用いて、復号化される現在のビデオ・ブロックの予測ブロックを生成する。例えば、動き補償ユニット72は、受信されたシンタックス要素の幾つかを用いて、ビデオ・スライスのビデオ・ブロックをコーディングするために使用される予測モード、インター予測スライス・タイプ(例えば、Bスライス、Pスライス、又はGPBスライス)、スライスの参照ピクチャ・リストのうちの1つ以上の構成情報、スライスの各インター・コーディングされたビデオ・ブロックのための動きベクトル、スライスの各インター・コーディングされたビデオ・ブロックのためのインター予測ステータス、及び現在のビデオ・スライス内のビデオ・ブロックを復号化するための他の情報を決定する。
【0083】
動き補償ユニット72はまた、補間フィルタに基づいて補間を実行することも可能である。動き補償ユニット72は、ビデオ・ブロックの符号化中にビデオ・エンコーダ20によって使用されたような補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間値を計算することができる。この場合、動き補償ユニット72は、ビデオ・エンコーダ20によって使用された補間フィルタを、受信したシンタックス要素から決定し、予測ブロックを生成するために補間フィルタを使用することができる。
【0084】
深度マップに対応するテクスチャ画像のデータは、参照フレーム・メモリ82に格納されることが可能である。また、動き補償ユニット72は、深度マップの深度ブロックをインター予測するように構成されることも可能である。
【0085】
実施形態では、ビデオ・デコーダ30はユーザー・インターフェース84を含む。ユーザー・インターフェース84は、ビデオ・デコーダ30のユーザー(例えば、ネットワーク・アドミニストレータ)からの入力を受信するように構成される。ユーザー・インターフェース84を介して、ユーザーは、ビデオ・デコーダ30における設定を管理又は変更することができる。例えば、ユーザーは、ユーザーの好みに応じてビデオ・デコーダ30の構成及び/又は動作を制御するために、パラメータ(例えば、フラグ)の値を入力するか又は他の方法で提供することができる。ユーザー・インターフェース84は、例えば、グラフィカル・アイコン、ドロップ・ダウン・メニュー、チェック・ボックスなどを介して、ユーザーがビデオ・デコーダ30と対話することを可能にするグラフィカル・ユーザー・インターフェース(GUI)であってもよい。ある場合には、ユーザー・インターフェース84は、キーボード、マウス、又は他の周辺デバイスを介してユーザーから情報を受け取ることができる。実施形態では、ユーザーは、スマート・フォン、タブレット・デバイス、ビデオ・デコーダ30から離れた位置にあるパーソナル・コンピュータなどを介して、ユーザー・インターフェース84にアクセスすることができる。本件で使用されるように、ユーザー・インターフェース84は外部入力又は外部手段と言及されてもよい。
【0086】
上記を念頭に置いて、ビデオ圧縮技術は、ビデオ・シーケンスに固有の冗長性を低減又は除去するために、空間(イントラ・ピクチャ)予測及び/又は時間(インター・ピクチャ)予測を実行する。ブロック・ベースのビデオ・コーディングの場合、ビデオ・スライス(即ち、ビデオ・ピクチャ又はビデオ・ピクチャの一部分)は、ビデオ・ブロックにパーティション化されることが可能であり、これは、ツリーブロック、コーディング・ツリー・ブロック(CTB)、コーディング・ツリー・ユニット(CTU)、コーディング・ユニット(CU)及び/又はコーディング・ノードと言及される場合がある。ピクチャのイントラ・コーディングされた(I)スライス内のビデオ・ブロックは、同じピクチャ内の隣接ブロック内の参照サンプルに関して空間的予測を用いて符号化される。ピクチャのインター・コーディングされた(P又はB)スライス内のビデオ・ブロックは、同じピクチャ内の隣接ブロック内の参照サンプルに関して空間的予測を使用することができ、又は他の参照ピクチャ内の参照サンプルに関して時間的予測を使用することができる。ピクチャはフレームと呼ばれる場合があり、参照ピクチャは参照フレームと呼ばれる場合がある。
【0087】
空間的又は時間的な予測は、コーディングされるべきブロックの予測ブロックとなる。残差データは、コーディングされるべきオリジナル・ブロックと予測ブロックとの間のピクセル差分を表す。インター・コーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトルに従って符号化され、残差データは、コーディングされたブロックと予測ブロックとの間の差分を示す。イントラ・コーディングされたブロックは、イントラ・コーディング・モードと残差データとに従って符号化される。更なる圧縮のために、残差データは、ピクセル・ドメインから変換ドメインへ変換されて、以後に量子化され得る残差変換係数をもたらす。量子化された変換係数は、当初は二次元アレイに配置されており、変換係数の一次元ベクトルを生成するためにスキャンされることが可能であり、更により多くの圧縮を達成するためにエントロピー・コーディングを適用することができる。
【0088】
画像及びビデオ圧縮は急速に発展しており、様々なコーディング規格に向かっている。このようなビデオ・コーディング規格は、ITU-T H.261、国際標準化機構/国際電気標準会議(ISO/IEC)MPEG-1 Part 2、ITU-T H.262又はISO/IEC MPEG-2 Part 2、ITU-T H.263、ISO/IEC MPEG-4 Part 2、ITU-T H.264又はISO/IEC MPEG-4 Part 10としても知られるアドバンスト・ビデオ・コーディング(AVC)、及びITU-T H.265又はMPEG-H Part 2としても知られる高効率ビデオ・コーディング(HEVC)を含む。AVCは、スケーラブル・ビデオ・コーディング(SVC)、マルチビュー・ビデオ・コーディング(MVC)及びマルチビュー・ビデオ・コーディング・プラス・デプス(MVC+D)、及び3D AVC(3D-AVC)のような拡張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、及び3D HEVC(3D-HEVC)のような拡張を含む。
【0089】
ITU-TとISO/IECの共同ビデオ・エキスパート・チーム(JVET)によって開発された、多用途ビデオ・コーディング(VVC)と名付けられる新しいビデオ・コーディング規格もある。VVC規格は幾つかのワーキング・ドラフトを含んでいるが、特に、VVCの1つのワーキング・ドラフト、B. Bross, J. Chen, and S. Liu, “Versatile Video Coding (Draft 5),” JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC Draft 5)は、参照により全体的に本件に援用される。
【0090】
本件で開示される技術の説明は、ITU-T及びISO/IECの共同ビデオ・エキスパート・チーム(JVET)による開発中のビデオ・コーディング規格・多用途ビデオ・コーディング(VVC)に基づいている。しかしながら技術は他のビデオ・コーデック規格にも適用される。
【0091】
図4は、リーディング・ピクチャ404に対するイントラ・ランダム・アクセス・ポイント(IRAP)ピクチャ402とトレーリング・ピクチャ406との間の関係を、復号化順序408とプレゼンテーション順序410で表現したもの400である。実施形態では、IRAPピクチャ402は、クリーン・ランダム・アクセス(CRA)ピクチャとして、又はランダム・アクセス復号可能(RADL)ピクチャを伴う瞬間デコーダ・リフレッシュ(IDR)ピクチャとして言及される。HEVCでは、IDRピクチャ、CRAピクチャ、及びブロークン・リンク・アクセス(BLA)ピクチャは全てIRAPピクチャ402とみなされる。VVCでは、2018年10月の第12回JVET会合において、IDR及びCRAピクチャの双方をIRAPピクチャとして有することが合意された。実施形態では、ブロークン・リンク・アクセス(BLA)と段階的デコーダ・リフレッシュ(GDR)ピクチャもまた、IRAPピクチャであるとみなすことができる。コーディングされたビデオ・シーケンスの復号化プロセスは、常にIRAPから始まる。
【0092】
図4に示すように、リーディング・ピクチャ404(例えば、ピクチャ2及び3)は、復号化順序408ではIRAPピクチャ402に続くが、プレゼンテーション順序410ではIRAPピクチャ402に先行している。トレーリング・ピクチャ406は、復号化順序408及びプレゼンテーション順序410の両方において、IRAPピクチャ402に続く。2つのリーディング・ピクチャ404と1つのトレーリング・ピクチャ406が図4に示されているが、当業者は、より多くの又はより少ないリーディング・ピクチャ404及び/又はトレーリング・ピクチャ406が、実際アプリケーションでにおける復号化順序408やトレーリング順序410で存在し得ることを認めるであろう。
【0093】
図4のリーディング・ピクチャ404は、2つのタイプ、即ちランダム・アクセス・スキップ・リーディング(RASL)とRADLに分割されている。復号化がIRAPピクチャ402(例えば、ピクチャ1)で始まる場合、RADLピクチャ(例えば、ピクチャ3)は、適切に復号化することができる;しかしながら、RASLピクチャ(例えば、ピクチャ2)は、適切に復号化することができない。従って、RASLピクチャは破棄される。RADLとRASLピクチャとの間の区別によれば、IRAPピクチャ402に関連するリーディング・ピクチャ404のタイプは、効率的かつ適切なコーディングのために、RADL又はRASLの何れかとして同定されるべきである。HEVCでは、RASL及びRADLピクチャが存在する場合、同じIRAPピクチャ402に関連付けられたRASL及びRADLピクチャに関し、RASLピクチャはプレゼンテーション順序410でRADLピクチャに先行するものとする、という制約がある。
【0094】
IRAPピクチャ402は、以下の2つの重要な機能/利点を提供する。第1に、IRAPピクチャ402の存在は、復号化プロセスがそのピクチャから開始可能であることを示す。この機能は、IRAPピクチャ402がその位置に存在する限り、復号化プロセスがビットストリーム内のその位置から始まり、必ずしもビットストリームの先頭ではないランダム・アクセス機能を可能にする。第2に、IRAPピクチャ402の存在は復号化プロセスをリフレッシュし、その結果、RASLピクチャを除くIRAPピクチャ402で始まるコーディングされたピクチャは、先行するピクチャをどれも参照することなくコーディングされる。ビットストリーム内にIRAPピクチャ402が存在すると、それ故に、IRAPピクチャ402に先行する、コーディングされたピクチャの復号化中に発生した可能性のある何らかのエラーが、IRAPピクチャ402と復号化順序408でIRAPピクチャ402に続くピクチャとに伝搬して行くことを止めるであろう。
【0095】
IRAPピクチャ402は、重要な機能を提供するが、圧縮効率に対するペナルティを招く。IRAPピクチャ402の存在は、ビットレートの急増を引き起こす。圧縮効率に対するこのペナルティは、2つの理由に起因する。第1に、IRAPピクチャ402は、イントラ予測されるピクチャであるので、インター予測されるピクチャである他のピクチャ(例えば、リーディング・ピクチャ404、トレーリング・ピクチャ406)と比較した場合に、ピクチャ自体が、表現のために比較的多くのビットを必要とする。第2に、IRAPピクチャ402の存在は時間的な予測を中断するので(これは、デコーダが復号化プロセスをリフレッシュするからであり、そのための復号化プロセスの動作のうちの1つは、復号化されたピクチャのバッファ(DPB)内の先行する参照ピクチャを除去することになる)、IRAPピクチャ402は、復号化順序408でIRAPピクチャ402に続くピクチャのコーディングを非効率化させ(即ち、表現するために、より多くのビットを必要とする)、なぜならそれらのインター予測コーディングのための参照ピクチャがより少ないからである。
【0096】
IRAPピクチャ402と考えられるピクチャ・タイプのうち、HEVCにおけるIDRピクチャは、他のピクチャ・タイプと比較した場合に、異なるシグナリング及び導出を有する。相違点のうちの幾つかは以下の通りである。
【0097】
IDRピクチャのピクチャ・オーダー・カウント(POC)値のシグナリング及び導出の場合、POCの最上位ビット(MSB)部分は、先行するキー・ピクチャからは導出されず、単に0に等しく設定される。
【0098】
参照ピクチャ管理に必要とされるシグナリング情報については、IDRピクチャのスライス・ヘッダは、参照ピクチャ管理を支援するためにシグナリングされることに必要とされる情報を含まない。他のピクチャ・タイプ(即ち、CRA、トレーリング、テンポラル・サブレイヤ・アクセス(TSA)等)については、以下に記載される参照ピクチャ・セット(RPS)又は他の形態の同様な情報(例えば、参照ピクチャ・リスト)のような情報が、参照ピクチャ・マーキング・プロセス(即ち、復号化されたピクチャのバッファ(DPB)内の参照ピクチャの状態、参照のために使用される及び参照のために使用されないの何れか、を決定するためのプロセス)のために必要とされる。しかしながら、IDRピクチャの場合、そのような情報はシグナリングされることを必要とせず、なぜなら、復号化プロセスは、単に、DPB内の全ての参照ピクチャを、参照のために使用されないものとしてマーキングするものとする、ということをIDRの存在が示すからである。
【0099】
HEVC及びVVCでは、IRAPピクチャ402とリーディング・ピクチャ404はそれぞれ、単一のネットワーク抽象化レイヤ(NAL)ユニット内に含まれてもよい。NALユニットのセットは、アクセス・ユニットと呼ばれることがある。IRAPピクチャ402とリーディング・ピクチャ404は、所与の異なるNALユニット・タイプであり、その結果、それらはシステム・レベルのアプリケーションによって容易に識別することができる。例えば、ビデオ・スプライサーは、コーディングされたビットストリーム内のシンタックス要素の過剰な詳細を理解する必要なしに、コーディングされたピクチャ・タイプを理解することを必要とし、特に、IRAPピクチャ402を非IRAPピクチャから識別し、リーディング・ピクチャ404をトレーリング・ピクチャ406から識別することを必要とし、それはRASL及びRADLピクチャを決定することを含む。トレーリング・ピクチャ406は、IRAPピクチャ402に関連付けられるピクチャであって、プレゼンテーション順序410でIRAPピクチャ402に続くものである。ピクチャは、復号化順序408で特定のIRAPピクチャ402に続き、復号化順序408で他の何らかのIRAPピクチャ402に先行する可能性がある。このため、IRAPピクチャ402とリーディング・ピクチャ404の下で、それら自身のNALユニット・タイプは、このようなアプリケーションに役立つ。
【0100】
HEVCでは、IRAPピクチャのNALユニット・タイプは以下を含む:
リーディング・ピクチャを伴うBLA(BLA_W_LP):ブロークン・リンク・アクセス(BLA)のNALユニットであり、復号化順で1つ以上のリーディング・ピクチャが後に続く場合がある。
RADLを伴うBLA(BLA_W_RADL):BLAピクチャのNALユニットであり、復号化順で1つ以上のRADLピクチャが後に続く場合はあるがRASLピクチャはそうではない。
リーディング・ピクチャを伴わないBLA(BLA_N_LP):BLAピクチャのNALユニットであり、復号化順でリーディング・ピクチャは後に続いていない。
RADLを伴うDLA(IDR_W_RADL):IDRピクチャのNALユニットであり、復号化順で1つ以上のRADLピクチャが後に続く場合はあるがRASLピクチャはそうではない。
リーディング・ピクチャを伴わないIDR(IDR_N_LP):IDRピクチャのNALユニットであり、復号化順でリーディング・ピクチャは後に続いていない。
CRA:クリーン・ランダム・アクセス(CRA)ピクチャのNALユニットであり、リーディング・ピクチャ(即ち、RASLピクチャ、RADLピクチャ、又はその両方)が後に続く場合がある。
RADL:RADLピクチャのNALユニット。
RASL:RASLピクチャのNALユニット。
【0101】
VVCでは、IRAPピクチャ402とリーディング・ピクチャ404に対するNALユニット・タイプは以下の通りである:
RADLを伴うIDR(IDR_W_RADL):IDRピクチャのNALユニットであり、復号化順で1つ以上のRADLピクチャが後に続く場合はあるがRASLピクチャはそうではない。
リーディング・ピクチャを伴わないIDR(IDR_N_LP):IDRピクチャのNALユニットであり、復号化順でリーディング・ピクチャは後に続いていない。
CRA:クリーン・ランダム・アクセス(CRA)ピクチャのNALユニットであり、リーディング・ピクチャ(即ち、RASLピクチャ、RADLピクチャ、又はその両方)が後に続く場合がある。
RADL:RADLピクチャのNALユニット。
RASL:RASLピクチャのNALユニット。
【0102】
参照ピクチャ・リサンプリング(RPR)機能は、解像度変更位置でのピクチャのイントラ・コーディングを必要とせずに、ビットストリームの途中で、コーディングされたピクチャの空間解像度を変更する能力である。これを可能にするために、ピクチャは、インター予測の目的のために、空間解像度が現在のピクチャのものとは異なる1つ以上の参照ピクチャを参照できることを必要とする。従って、このような参照ピクチャ又はその一部のリサンプリングが、現在のピクチャの符号化及び復号化のために必要とされる。従ってRPRと名付けられる。この機能は、適応解像度変更(ARC)又は他の名称で言及される場合がある。以下のようなものを含む、RPR機能の恩恵を受けるユース・ケース又はアプリケーション・シナリオが存在する。
【0103】
テレビ電話及び会議におけるレート・アダプテーション。これは、コーディングされたビデオを、変化するネットワーク条件に適合させるためのものである。ネットワーク状態が悪化し、その結果、利用可能な帯域幅が小さくなると、エンコーダは、より小さな解像度のピクチャを符号化することによって、それに適応することができる。
【0104】
マルチ・パーティ・テレビ会議におけるアクティブ話者変更。マルチ・パーティ・ビデオ会議では、アクティブ話者に対するビデオ・サイズは、残りの会議参加者に対するビデオ・サイズより大きい又は高いことが一般的である。アクティブ話者が変わると、各参加者のピクチャ解像度も調整されることを必要とする場合がある。ARC機能を有する必要性は、アクティブ話者の変更が頻繁に行われる場合に、より重要になる。
【0105】
ストリーミングにおける高速スタート。ストリーミング・アプリケーションでは、アプリケーションは、ピクチャを表示し始める前に、復号化されたピクチャのうちの所定の長さまでをバッファリングすることが一般的である。より小さな解像度でビットストリームを開始することは、アプリケーションが、より速く表示を開始するのに十分なピクチャをバッファ内に有することを可能にする。
【0106】
ストリーミングにおける適応ストリーム・スイッチング。HTTPにおける動的適応ストリーミング(DASH)規格は、@mediaStreamStructureIdと名付けられる特徴を含む。この機能は、例えばHEVCの関連RASLピクチャを有するCRAピクチャのような、復号化不能なリーディング・ピクチャを有するオープンGOPランダム・アクセス・ポイントでの異なる表現間のスイッチングを可能にする。同じビデオの2つの異なる表現が、ビットレートは異なるが同じ空間解像度を有する一方、それらが@mediaStreamStructureIdと同じ値を有する場合、RASLピクチャに関連するCRAピクチャにおける2つの表現の間でスイッチングを実行することが可能であり、CRAピクチャにおけるスイッチングに関連するRASLピクチャを、許容可能な品質で復号化することが可能であり、従ってシームレスなスイッチングを可能にする。ARCでは、@mediaStreamStructureId機能は、異なる空間分解能を有するDASH表現間のスイッチングにも使用可能である。
【0107】
様々な方法は、ピクチャ解像度のリスト、DPBにおける参照ピクチャのリサンプリングの何らかの制約のシグナリングのようなRPR/ARCをサポートするための基本的な技術を促進する。更に、ジュネーブにおける第14回JVET会合では、RPRを支援するためにVVCに適用されるべき制約を示唆する幾つかのインプット・コントリビューションがあった。提案された制約は以下を含む。
【0108】
幾つかのツールは、現在のピクチャと異なる解像度を有する参照ピクチャを参照する場合には、現在のピクチャ内のブロックのコーディングに対してディセーブルにされるものとする。このツールは以下を含む。
【0109】
時間的動きベクトル予測(TMVP)とアドバンストTMVP(ATMVP)。これはJVET-N0118によって提案された。
【0110】
デコーダ側の動きベクトル精密化(DMVR)。これはJVET-N0279によって提案された。
【0111】
双-方向オプティカル・フロー(BIO)。これはJVET-N0279によって提案された。
【0112】
現在のピクチャと解像度が異なる参照ピクチャからのブロックの双-予測は許容されない。これはJVET-N0118によって提案された。
【0113】
動き補償の場合、サンプル・フィルタリングは1回のみ適用されるものとし、即ち、より細かいペル解像度(例えば、1/4ペル解像度)を得るためにリサンプリングと補間が必要とされる場合、2つのフィルタは、組み合わされて適用されることを1度だけ必要とする。これはJVET-N0118によって提案された。
【0114】
ビデオ・コーディングにおけるスケーラビリティは、通常、マルチ・レイヤ・コーディング技術を用いることによってサポートされる。マルチ・レイヤ・ビットストリームは、ベース・レイヤ(BL)と1つ以上のエンハンスメント・レイヤ(EL)を含む。スケーラビリティの例は、空間スケーラビリティ、品質/信号-対-雑音(SNR)スケーラビリティ、マルチビュー・スケーラビリティなどを含む。マルチ・レイヤ・コーディング技術が使用される場合、ピクチャ又はその一部は、(1)参照ピクチャを使用せずに、即ち、イントラ予測を使用せずに、(2)同じレイヤ内にある参照ピクチャを参照することによって、即ち、インター予測を使用することによって、又は(3)他のレイヤにある参照ピクチャを参照することによって、即ち、インター・レイヤ予測を使用することによって、コーディングされることが可能である。現在のピクチャのインター・レイヤ予測に使用される参照ピクチャは、インター・レイヤ参照ピクチャ(ILRP)と呼ばれる。
【0115】
図5は、空間スケーラビリティ500のためのマルチ・レイヤ・コーディングの例を示す。レイヤN内のピクチャ502は、レイヤN+1内のピクチャ504とは異なる解像度(例えば、より低い解像度)を有する。実施形態では、上述のように、レイヤNはベース・レイヤであると考えられ、レイヤN+1はエンハンスメント・レイヤであると考えられる。レイヤN内のピクチャ502とレイヤN+1内のピクチャ504は、(実線の矢印によって示されるように)インター予測を用いてコーディングされてもよい。また、ピクチャ502は、(破線矢印によって示されるように)インター・レイヤ予測を用いてコーディングされてもよい。
【0116】
RPRの状況において、参照ピクチャは、下位層レイヤから参照ピクチャを選択することによって、又はインター・レイヤ予測を使用することによってリサンプリングされて、より高いレイヤの参照ピクチャを、より低いレイヤの参照ピクチャに基づいて生成することができる。
【0117】
以前のH.26xビデオ・コーディング・ファミリは、単一レイヤ・コーディングのためのプロファイル中の別々のプロファイルでスケーラビリティに対するサポートを提供している。スケーラブル・ビデオ・コーディング(SVC)は、空間的、時間的及び品質的なスケーラビリティのサポートを提供するAVC/H.264のスケーラブルな拡張である。SVCでは、ELピクチャ内の各マクロブロック(MB)でフラグがシグナリングされて、EL MBが、下位レイヤからのコロケーションされたブロックを使用して予測されるかどうかを指定する。コロケーションされたブロックからの予測は、テクスチャ、動きベクトル、及び/又はコーディング・モードを含んでもよい。SVCの実装は、修正されていないH.264/AVC実装をそれらの設計で直接的には再利用できない。SVC ELマクロブロック・シンタックスと復号化プロセスは、H.264/AVCシンタックスと復号化プロセスと相違する。
【0118】
スケーラブルHEVC(SHVC)は、空間的及び品質的なスケーラビリティをサポートするHEVC/H.265 規格の拡張であり、マルチビューHEVC(MV-HEVC)は、マルチビュー・スケーラビリティをサポートするHEVC/H.265の拡張であり、3D HEVC (3D-HEVC)は、3次元(3D)ビデオ・コーディングをサポートするHEVC/H.264 の拡張であって、MV-HEVCよりも高度であり且つより効率的なものである。時間的スケーラビリティは、シングル・レイヤHEVCコーデックの不可欠な部分として含まれることに留意されたい。HEVCのマルチ・レイヤ拡張の設計は、インター・レイヤ予測のために使用される復号化されたピクチャが、同一のアクセス・ユニット(AU)のみから到来し、長期参照ピクチャ(LTRP)として扱われ、現在のレイヤの他のテンポラル参照ピクチャと共に参照ピクチャ・リストにおいて参照インデックスを指定される、というアイデアを使用している。インター・レイヤ予測(ILP)は、参照ピクチャ・リスト内のインター・レイヤ参照ピクチャを参照するために、参照インデックスの値を設定することによって、予測ユニット(PU)レベルで達成される。
【0119】
特に、参照ピクチャ・リサンプリングと空間スケーラビリティ機能の両方は、参照ピクチャ又はその一部のリサンプリングを必要とする。参照ピクチャ・リサンプリングは、ピクチャ・レベル又はコーディング・ブロック・レベルの何れかで実現することができる。しかしながら、RPRがコーディング機能として言及される場合、それはシングル・レイヤ・コーディングのための機能である。たとえそうであったとしても、単一レイヤ・コーディングのRPR特徴及びマルチ・レイヤ・コーディングの空間スケーラビリティ特徴の両方に対して同じリサンプリング・フィルタを使用することは、コーデック設計の観点から可能であり、或いは望ましい。
【0120】
JVET-N0279は、RPRに対するDMVRをディセーブルにすることを提案した。より正確に言えば、RPRがイネーブルにされる場合に、コーディングされたビデオ・シーケンス(CVS)全体に対するDMVRの使用をディセーブルにすることが提案されている。RPR機能がイネーブルにされる場合でさえ、現在のピクチャは、多くのケースで異なる解像度を有する参照ピクチャを参照していない、ということが分かる。従って、CVS全体に対してDMVRをディセーブルにすることは、不必要に制限しており、コーディング効率を損なっている可能性がある。
【0121】
本件で開示されるものは、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、RPRがイネーブルにされる場合にはCVS全体に対してDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容する技術である。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、プロセッサ、メモリ、及び/又はネットワーク・リソースの使用を、エンコーダ及びデコーダの両方で減らすことができる。従って、ビデオ・コーディングにおけるコーダー/デコーダ(「コーデック」とも言及される)は、現在のコーデックと比較して改善される。実際問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送信、受信、及び/又は視聴される場合に、より良いユーザー体験をユーザーに提供する。
【0122】
図6は、一方向インター予測600の一例を示す概略図である。一方向インター予測600は、ピクチャをパーティショニングする場合に生成された符号化及び/又は復号化されたブロックの動きベクトルを決定するために使用することができる。
【0123】
一方向インター予測600は、現在のフレーム610内の現在のブロック611を予測するために、参照ブロック631を有する参照フレーム630を使用する。参照フレーム630は、図示されるように、(例えば、後続の参照フレームとして)時間的に現在のフレーム610の後に配置されてもよいが、幾つかの例では(例えば、先行する参照フレームとして)時間的に現在のフレーム610の前に配置されてもよい。現在のフレーム610は、特定の時間に符号化/復号化される例示的なフレーム/ピクチャである。現在のフレーム610は、参照フレーム630の参照ブロック631内のオブジェクトに一致する、現在のブロック611内のオブジェクトを含む。参照フレーム630は、現在のフレーム610を符号化するための参照として使用されるフレームであり、参照ブロック631は、現在のフレーム610の現在のブロック611にも含まれるオブジェクトを含む参照フレーム630内のブロックである。
【0124】
現在のブロック611は、コーディング・プロセスの特定の点で符号化/復号化されている任意のコーディング・ユニットである。現在のブロック611は、パーティション化されたブロック全体であってもよいし、又はアフィン・インター予測モードを使用する場合にはサブ・ブロックであってもよい。現在のフレーム610は、ある時間距離(TD)633だけ参照フレーム630から分離されている。TD 633は、ビデオ・シーケンスにおける現在のフレーム610と参照フレーム630との間の時間の量を示し、フレーム単位で測定することができる。現在のブロック611に対する予測情報は、フレーム間の方向と時間的な距離を示す参照インデックスによって、参照フレーム630及び/又は参照ブロック631を参照することができる。TD 633によって表現される期間にわたって、現在のブロック611内のオブジェクトは、現在のフレーム610内の位置から、参照フレーム630内の別の位置(例えば、参照ブロック631の位置)へ移動する。例えば、オブジェクトは、時間経過によるオブジェクトの運動の方向である運動軌跡613に沿って移動する可能性がある。動きベクトル635は、TD 633にわたる運動軌跡613に沿ったオブジェクトの運動の方向及び大きさを記述する。従って、符号化された動きベクトル635と、参照ブロック631と、現在ブロック611及び参照ブロック631の間の差分を含む残差とは、現在のブロック611を再構成し、現在のフレーム610内で現在のブロック611を位置決めするのに十分な情報を提供する。
【0125】
図7は、双方向インター予測700の一例を示す概略図である。双方向インター予測700は、ピクチャをパーティショニングする場合に生成された符号化及び/又は復号化されたブロックの動きベクトルを決定するために使用することができる。
【0126】
双方向インター予測700は、一方向インター予測600に類似しているが、現在のフレーム710内の現在のブロック711を予測するために一対の参照フレームを使用する。従って、現在のフレーム710及び現在のブロック711はそれぞれ現在のフレーム610及び現在のブロック611とかなり類似している。現在のフレーム710は、ビデオ・シーケンス内の現在のフレーム710の前に現れる先行する参照フレーム720と、ビデオ・シーケンスの現在のフレーム710の後に現れる後続の参照フレーム730との間に時間的に位置する。先行する参照フレーム720と後続の参照フレーム730は、他の点でも参照フレーム630とかなり類似している。
【0127】
現在のブロック711は、先行する参照フレーム720内の先行する参照ブロック721と、後続の参照フレーム730内の後続の参照ブロック731とに一致する。このような一致は、ビデオ・シーケンスの過程において、オブジェクトが、先行する参照ブロック721の位置から、運動軌跡713に沿って現在のブロック711を通って、後続の参照ブロック731の位置へ移動することを示す。現在のフレーム710は、ある先行する時間距離(TD0)7233だけ先行参照フレーム720から分離され、ある後続の時間距離(TD1)733だけ後続参照フレーム730から分離されている。TD0 723は、ビデオ・シーケンスにおける先行参照フレーム720と現在のフレーム710との間の時間の量をフレーム単位で示す。TD1 733は、ビデオ・シーケンスにおける現在のフレーム710と後続参照フレーム730との間の時間の量をフレーム単位で示す。従って、オブジェクトは、TD0 723によって示される期間にわたって、先行参照ブロック721から、運動軌跡713に沿って、現在のブロック711へ移動する。また、オブジェクトは、TD1 733によって示される期間にわたって、現在のブロック711から、運動軌跡713に沿って、後続参照ブロック731へ移動する。現在のブロック711の予測情報は、フレーム間の時間的な距離と方向を示す一対の参照インデックスによって、先行参照フレーム720及び/又は先行参照ブロック721と、後続参照フレーム730及び/又は後続参照ブロック731とを参照することができる。
【0128】
先行動きベクトル(MV0)725は、TD0 723にわたる運動軌跡713に沿うオブジェクトの運動の方向と大きさ(例えば、先行参照フレーム720と現在のフレーム710との間)を記述する。後続動きベクトル(MV1)735は、TD1 733にわたる運動軌跡713に沿うオブジェクトの運動の方向と大きさ(例えば、現在のフレーム710と後続参照フレーム730との間)を記述する。従って、双方向インター予測700において、現在のブロック711は、先行参照ブロック721及び/又は後続参照ブロック731、MV0 725、及びMV1 735を使用することによってコーディングされ且つ再構成されることが可能である。
【0129】
実施形態では、ブロック毎ではなく、サンプル毎(例えば、ピクセル毎)に、インター予測及び/又は双方インター予測を行うことができる。即ち、先行参照ブロック721及び/又は後続参照ブロック731内の各サンプルを指す動きベクトルは、現在のブロック711内の各サンプルに対して決定することが可能である。そのような実施形態では、図7に示される動きベクトル725及び動きベクトル735は、現在のブロック711、先行参照ブロック721、及び後続参照ブロック731内の複数のサンプルに対応する複数の動きベクトルを表す。
【0130】
マージ・モード及びアドバンスト動きベクトル予測(AMVP)モードの双方において、候補リストは、候補ベクトルを候補リストに、候補リスト決定パターンで定義される順序で追加することによって生成される。そのような候補動きベクトルは、一方向インター予測600、双方向インター予測700、又はそれらの組み合わせによる動きベクトルを含んでもよい。具体的には、そのようなブロックが符号化される場合に、動きベクトルが、隣接するブロックに対して生成される。このような動きベクトルは、現在のブロックに対する候補リストに追加され、現在のブロックに対する動きベクトルは、候補リストから選択される。次いで、動きベクトルは、候補リスト内の選択された動きベクトルのインデックスとしてシグナリングされることが可能である。デコーダは、エンコーダと同じプロセスを用いて候補リストを構築することが可能であり、シグナリングされたインデックスに基づいて、候補リストから選択された動きベクトルを決定することができる。従って、候補動きベクトルは、そのような隣接ブロックが符号化される場合にどのアプローチが使用されるかに依存して、一方向インター予測600及び/又は双方向インター予測700に従って生成される動きベクトルを含む。
【0131】
図8は、ビデオ・ビットストリーム800を示す。本件で使用されるように、ビデオ・ビットストリーム800は、コーディングされたビデオ・ビットストリーム、ビットストリーム、又はそれらの変形として言及される場合がある。図8に示すように、ビットストリーム800は、シーケンス・パラメータ・セット802、ピクチャ・パラメータ・セット804、スライス・ヘッダ806、及びピクチャ・データ808を含む。
【0132】
SPS 802は、ピクチャ(SOP)のシーケンス内の全てのピクチャに共通するデータを含む。これに対して、PPS 804は、ピクチャ全体に共通するデータを含む。スライス・ヘッダ806は、例えば、スライス・タイプ、どちらの参照ピクチャが使用されるか等のような、現在のスライスに関する情報を含む。SPS 802とPPS 804は、一般にパラメータ・セットと呼ばれてもよい。SPS 802と、PPS 804と、スライス・ヘッダ806とは、ネットワーク抽象化レイヤ(NAL)ユニットのタイプである。NALユニットは、従うデータのタイプ(例えば、コーディングされたビデオ・データ)の指示を含むシンタックス構造である。NALユニットは、ビデオ・コーディング・レイヤ(VCL)と非VCL NALユニットに分類される。VCL NALユニットは、ビデオ・ピクチャ内のサンプルの値を表すデータを含み、非VCL NALユニットは、パラメータ・セット(多数のVCL NALユニットに適用することが可能な重要なヘッダ・データ)及び補足エンハンスメント情報(タイミング情報及びその他の補足データであって、復号化されるビデオ信号の利用可能性を高める可能性があるが、ビデオ・ピクチャ内のサンプルの値を復号化するために必須ではないもの)のような、何らかの関連する追加情報を含む。当業者は、ビットストリーム800が実際のアプリケーションでは他のパラメータ及び情報を含む可能性があることを理解するであろう。
【0133】
図8の画像データ808は、符号化又は復号化される画像又はビデオに関連するデータを含む。画像データ808は、単に、ビットストリーム800内で搬送されるペイロード又はデータとして言及されてもよい。実施形態では、画像データ808は、複数のピクチャ810を含むCVS 814(又はCLVS)を含む。CVS 814は、ビデオ・ビットストリーム800内のコーディングされたレイヤ・ビデオ・シーケンス(CLVS)全体のためのコーディングされたビデオ・シーケンスである。注目すべきことに、ビデオ・ビットストリーム800が単一レイヤを含む場合、CVSとCLVSは同じである。CVSとCLVSは、ビデオ・ビットストリーム800が複数のレイヤを含む場合にのみ相違する。
【0134】
各ピクチャ810のスライスは、それ自身のVCL NALユニット812内に含まれてもよい。CVS 814内のVCL NALユニット812のセットは、アクセス・ユニットと言及されてもよい。
【0135】
図9は、ピクチャ910のパーティショニング技術900を示す。ピクチャ910は、図8における何れかのピクチャ810と同様であってもよい。図示されるように、ピクチャ910は、複数のスライス912にパーティション化されてもよい。スライスは、同一フレーム内の他の任意の領域から別々に符号化される、空間的に別個のフレーム領域(例えば、ピクチャ)である。3つのスライス912が図9に示されているが、より多くの又はより少ないスライスが実際のアプリケーションで使用されてもよい。各スライス912は、複数のブロック914にパーティション化されてもよい。図9のブロック914は、図7における現在のブロック711、先行参照ブロック721、及び後続参照ブロック731と同様であってもよい。ブロック914はCUを表現していてもよい。4つのブロック914が図9に示されているが、より多くの又はより少ないブロックが実際のアプリケーションで使用されてもよい。
【0136】
各ブロック914は、複数のサンプル916(例えば、ピクセル)にパーティション化されてもよい。実施形態では、各ブロック914のサイズはルマ・サンプルで測定される。16個のサンプル916が図9に示されているが、より多くの又はより少数のサンプルが実際のアプリケーションで使用されてもよい。
【0137】
図10は、ビデオ・デコーダ(例えば、ビデオ・デコーダ30)によって実現されるコーディングされたビデオ・ビットストリームを復号化する方法1000の実施形態である。方法1000は、復号化されたビットストリームがビデオ・エンコーダ(例えば、ビデオ・エンコーダ20)から直接的又は間接的に受信された後に実行されてもよい。方法1000は、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、RPRがイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容することによって、復号化プロセスを改善する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、実際問題として、コーデックのパフォーマンスは改善され、より良いユーザー体験をもたらす。
【0138】
ブロック1002において、ビデオ・デコーダは、復号化される現在のピクチャの解像度が参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかを決定する。実施形態では、ビデオ・デコーダは、コーディングされたビデオ・ビットストリーム(例えば、ビットストリーム800)を受信する。コーディングされたビデオ・ビットストリームは、参照ピクチャ・リストを含み、現在のピクチャの解像度を示し、双方向インター予測モードを示す。実施形態では、参照ピクチャ・リスト構造は参照ピクチャ・リストを含む。実施形態では、参照ピクチャ・リストは、双方向インター予測のために使用される。実施形態では、現在のピクチャの解像度は、コーディングされたビデオ・ビットストリームのパラメータ・セット内に配置される。実施形態では、参照ピクチャの解像度は、現在のピクチャに基づいて導出され、現在のピクチャの解像度に基づいて推測され、ビットストリームから解析され、又は他の方法で取得される。実施形態では、現在のピクチャの参照ピクチャは、双方向インター予測モードに従って参照ピクチャ・リストに基づいて生成される。
【0139】
ブロック1004において、ビデオ・デコーダは、現在のピクチャの解像度が参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについてDMVRをイネーブルにする。実施形態では、ビデオ・デコーダは、DMVRフラグを第1値(例えば、真、1等)に設定することによって、DMVRをイネーブルにする。実施形態では、DMVRは、DMVRがイネーブルである場合でさえ、オプションのプロセスである。即ち、DMVRがイネーブルである場合でさえ、DMVRは実行されることを必要としない。
【0140】
ブロック1006において、ビデオ・デコーダは、現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なる場合に、現在のピクチャの現在のブロックについてDMVRをディセーブルにする。実施形態では、ビデオ・デコーダは、DMVRフラグを第2値(例えば、偽、ゼロ)に設定することによって、DMVRをディセーブルにする。
【0141】
ブロック1008において、ビデオ・デコーダは、DMVRフラグが第1値に設定される場合に、現在のブロックに対応する動きベクトルを精密化する。実施形態では、方法1000は、現在のピクチャの解像度が参照ピクチャの解像度と異なるか又は同じであるかに応じて、現在のピクチャ内の他のブロックに対するDMVRを選択的にイネーブル及びディセーブルにするステップを更に含む。
【0142】
実施形態では、方法は、DMVRがディセーブルにされる場合に、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)をイネーブルにするステップを更に含む。
【0143】
実施形態では、現在のブロックは、現在のピクチャのスライスから取得される。実施形態では、現在のピクチャは複数のスライスを含み、現在のブロックは複数のスライスのうちのスライスから取得される。
【0144】
実施形態では、現在のピクチャに基づいて生成される画像は、電子デバイス(例えば、スマート・フォン、タブレット、ラップトップ、パーソナル・コンピュータなど)のユーザーに対して表示される。
【0145】
図11は、ビデオ・エンコーダ(例えば、ビデオ・エンコーダ20)によって実現されるビデオ・ビットストリームを符号化する方法1100の実施形態である。方法900は、(例えば、ビデオからの)ピクチャがビデオ・ビットストリームに符号化され、ビデオ・デコーダ(例えば、ビデオ・デコーダ30)へ送信される場合に実行されてもよい。方法1100は、現在のピクチャの空間解像度が参照ピクチャの空間解像度と異なる場合に、RPRがイネーブルにされる場合にはCVS全体についてDMVRをディセーブルにしなければならないとする代わりに、DMVRが選択的にディセーブルにされることを許容することによって、符号化プロセスを改善する。この方式でDMVRを選択的にディセーブルにする能力を持たせることによって、コーディング効率を改善することができる。従って、実際問題として、コーデックのパフォーマンスは改善され、より良いユーザー体験をもたらす。
【0146】
ブロック1102において、ビデオ・エンコーダは、符号化される現在のピクチャの解像度が、参照ピクチャ・リストによって識別される参照ピクチャの解像度と同じであるかどうかを決定する。実施形態では、参照ピクチャ・リスト構造は参照ピクチャ・リストを含む。実施形態では、参照ピクチャ・リストは、双方向インター予測のために使用される。実施形態では、現在のピクチャの解像度は、ビデオ・ビットストリームのパラメータ・セットにおいて符号化される。実施形態では、現在のピクチャの参照ピクチャは、双方向インター予測モードに従って参照ピクチャ・リストに基づいて生成される。
【0147】
ブロック1104において、ビデオ・エンコーダは、現在のピクチャの解像度が、参照ピクチャ各々の解像度と同じであると決定された場合に、現在のピクチャの現在のブロックについてDMVRをイネーブルにする。実施形態では、ビデオ・エンコーダは、DMVRフラグを第1値(例えば、真、1等)に設定することによって、DMVRをイネーブルにする。実施形態では、DMVRは、DMVRがイネーブルである場合でさえ、オプションのプロセスである。即ち、DMVRがイネーブルである場合でさえ、DMVRは実行されることを必要としない。
【0148】
実施形態では、方法は、参照ピクチャに基づいて現在のピクチャの動きベクトルを決定し、動きベクトルに基づいて現在のピクチャを符号化し、仮説的リファレンス・デコーダ(HRD)を用いて現在のピクチャを復号化するステップを含む。
【0149】
ブロック1106において、ビデオ・エンコーダは、現在のピクチャの解像度が、参照ピクチャの何れの解像度とも異なる場合に、現在のピクチャの現在のブロックについてDMVRをディセーブルにする。実施形態では、ビデオ・エンコーダは、DMVRフラグを第2値(例えば、偽、ゼロ)に設定することによって、DMVRをディセーブルにする。
【0150】
ブロック1108において、ビデオ・エンコーダは、DMVRフラグが第1値に設定されている場合に、現在のブロックに対応する動きベクトルを精密化する。実施形態では、方法1100は、現在のピクチャの解像度が参照ピクチャの解像度と異なるか又は同じであるかに応じて、現在のピクチャ内の他のブロックに対するDMVRを選択的にイネーブル及びディセーブルにするステップを更に含む。
【0151】
実施形態では、方法は、DMVRがディセーブルにされる場合でさえ、現在のピクチャを含むコーディングされたビデオ・シーケンス(CVS)全体について、参照ピクチャ・リサンプリング(RPR)をイネーブルにするステップを更に含む。
【0152】
実施形態では、現在のブロックは、現在のピクチャのスライスから取得される。実施形態では、現在のピクチャは複数のスライスを含み、現在のブロックは複数のスライスのうちのスライスから取得される。
【0153】
実施形態では、ビデオ・エンコーダは、現在のブロックを含むビデオ・ビットストリームを生成し、ビデオ・ビットストリームをビデオ・デコーダへ送信する。実施形態では、ビデオ・エンコーダは、ビデオ・デコーダへの伝送のためにビデオ・ビットストリームを記憶する。
【0154】
実施形態では、ビデオ・ビットストリームを復号化する方法が開示される。ビデオ・ビットストリームは少なくとも1つのピクチャを含む。各ピクチャは複数のスライスを含む。複数のスライスの各スライスは、複数のコーディング・ブロックと複数の参照ピクチャ・リストを含む。複数の参照ピクチャ・リストの各参照ピクチャ・リストは、スライス内のコーディング・ブロックのインター予測に使用されることが可能な複数の参照ピクチャを含む。
【0155】
方法は、現在のピクチャの解像度情報を得るために、パラメータ・セットを解析するステップ;現在のピクチャの現在のスライスの2つの参照ピクチャ・リストを取得するステップ;現在のスライスの現在のコーディング・ブロックを復号化するために参照ピクチャを決定するステップ;参照ピクチャの解像度を決定するステップ;現在のピクチャと参照ピクチャの解像度に基づいて、現在のコーディング・ブロックの復号化のために、デコーダ側動きベクトル精密化(DMVR)が使用されるか又はイネーブルにされるかどうかを決定するステップ;及び現在のコーディング・ブロックを復号化するステップを含む。
【0156】
実施形態では、現在のピクチャと参照ピクチャの解像度が異なる場合に、現在の子ディング・ブロックの復号化について、DMVRは使用されないか又はディセーブルにされる。
【0157】
実施形態では、ビデオ・ビットストリームを復号化する方法が開示される。ビデオ・ビットストリームは少なくとも1つのピクチャを含む。各ピクチャは複数のスライスを含む。複数のスライスの各スライスは、複数のシンタックス要素を含むヘッダに関連付けられる。複数のスライスの各スライスは、複数のコーディング・ブロックと複数の参照ピクチャ・リストを含む。複数の参照ピクチャ・リストの各参照ピクチャ・リストは、現在のスライス内のコーディング・ブロックのインター予測に使用される可能性のある複数の参照ピクチャを含む。
【0158】
方法は、デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンスにおけるピクチャの復号化に使用される可能性があるかどうかを指定するフラグを取得するために、パラメータ・セットを解析するステップ;現在のピクチャにおける現在のスライスを取得するステップ;及び
デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンスにおけるピクチャの復号化に使用される可能性があるかどうかを指定するフラグの値が、DMVRは使用される可能性があることを指定している場合に、DMVRコーディング・ツールが、現在のスライスにおけるコーディング・ブロックの復号化に使用される可能性があるかどうかを指定するフラグを取得するために、現在のスライスに関連するスライス・ヘッダを解析するステップを含む。
【0159】
実施形態では、DMVRコーディング・ツールが、現在のスライスにおけるコーディング・ブロックの復号化に使用される可能性があるかどうかを指定するフラグの値が、コーディング・ツールは現在のスライスの復号化に使用されない可能性があることを指定している場合に、DMVRコーディング・ツールは、現在のコーディング・ブロックの復号化に対して使用されないか又はディセーブルにされる。
【0160】
実施形態では、存在しない場合、DMVRコーディング・ツールが、現在のスライスにおけるコーディング・ブロックの復号化に使用される可能性があるかどうかを指定するフラグの値は、デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンスにおけるピクチャの復号化に使用される可能性があるかどうかを指定するフラグの値と同じであると推定される。
【0161】
実施形態では、ビデオ・ビットストリームを符号化する方法が開示される。ビデオ・ビットストリームは少なくとも1つのピクチャを含む。各ピクチャは複数のスライスを含む。複数のスライスの各スライスは、複数のシンタックス要素を含むヘッダに関連付けられる。複数のスライスの各スライスは、複数のコーディング・ブロックと複数の参照ピクチャ・リストを含む。複数の参照ピクチャ・リストの各参照ピクチャ・リストは、現在のコーディング・ブロックのインター予測のために使用される可能性のある複数の参照ピクチャにより構成される。
【0162】
方法は、デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンス内のピクチャの符号化に使用される可能性があるかどうかを決定するステップ;各ピクチャ・ビットストリームの解像度情報を取得するためのパラメータ・セットを解析するステップ;現在のピクチャ内の現在のスライスの2つの参照ピクチャ・リストを取得するステップ;現在のスライスのコーディング・ブロックの復号化に使用される可能性のあるアクティブ参照ピクチャを取得するために、現在のスライスの参照ピクチャ・リストを解析するステップ;DMVRコーディング・ツールが、以下の条件:DMVRコーディング・ツールは現在のコーディングされたビデオ・シーケンス内のピクチャの符号化に使用されなくてよいこと;及び現在のピクチャと少なくとも1つの参照ピクチャの解像度が相違すること、のうちの少なくとも1つが充足される場合に、DMVRコーディング・ツールは、現在のスライスにおけるコーディング・ブロックの符号化に使用されなくてよいという制約を課すステップを含む。
【0163】
ビデオ・ビットストリームを復号化する方法が開示される。ビデオ・ビットストリームは少なくとも1つのピクチャを含む。各ピクチャは複数のスライスを含む。複数のスライスの各スライスは、複数のシンタックス要素を含むヘッダに関連付けられる。複数のスライスの各スライスは、複数のコーディング・ブロックと複数の参照ピクチャ・リストを含む。複数の参照ピクチャ・リストの各参照ピクチャ・リストは、現在のスライス内のコーディング・ブロックのインター予測のために使用される可能性のある複数の参照ピクチャにより構成される。
【0164】
方法は、デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンス内のピクチャの復号化に使用される可能性があるかどうかを指定するフラグを取得するために、パラメータ・セットを解析するステップ;及びデコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、パラメータ・セットを参照するピクチャの復号化に使用される可能性があるかどうかを指定するフラグを取得するために、パラメータ・セットを解析するステップを含み、パラメータ・セットはピクチャ・パラメータ・セット(PPS)である。
【0165】
実施形態では、DMVRコーディング・ツールが、PPSを参照するピクチャの復号化に使用される可能性があるかどうかを指定するフラグの値が、コーディング・ツールは使用されない可能性があることを指定している場合に、DMVRコーディング・ツールは、現在のコーディング・ブロックの復号化に対して使用されないか又はディセーブルにされる。
【0166】
実施形態では、ビデオ・ビットストリームを符号化する方法が開示される。ビデオ・ビットストリームは少なくとも1つのピクチャを含む。各ピクチャは複数のスライスを含む。複数のスライスの各スライスは、複数のシンタックス要素を含むヘッダに関連付けられる。複数のスライスの各スライスは、複数のコーディング・ブロックと複数の参照ピクチャ・リストを含む。複数の参照ピクチャ・リストの各参照ピクチャ・リストは、現在のスライス内のコーディング・ブロックのインター予測のために使用される可能性のある複数の参照ピクチャにより構成される。
【0167】
方法は、デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のコーディングされたビデオ・シーケンス内のピクチャの符号化に使用される可能性があるかどうかを決定するステップ;デコーダ側動きベクトル精密化(DMVR)コーディング・ツール/技術が、現在のPPSを参照する場合において、ピクチャの符号化に使用される可能性があるかどうかを決定するステップ;及び現在のコーディングされたシーケンスにおけるピクチャの符号化に、DMVR符号化ツールが使用されない可能性がある場合に、DMVRコーディング・ツールは、現在のPPSを参照する場合において、ピクチャの符号化に使用されない可能性がある、という制約を課すステップを含む。
【0168】
以下のシンタックス及びセマンティクスが、本件で開示される実施形態を実装するために使用される可能性がある。以下の説明は、最新のVVCドラフト仕様である基本テキストに対するものである。言い換えれば、差分のみが説明されており、以下で言及されていない基本テキスト中のテキストが、しかるべく適用される。基本テキストに対して追加されるテキストはボールド体で示され、削除されるテキストはイタリック体で示される。
【0169】
リファレンス・ピクチャ・リスト作成プロセスを以下のように改訂する。
【0170】
【数1】
【0171】
DMVRが使用されるかどうかを決定するフラグの導出。
【0172】
インター予測モードでコーディングされるコーディング・ユニットの復号化プロセスは、以下のような順序ステップを含む。
【0173】
1. 変数dmvrFlagは0に等しく設定される。
【0174】
2. 現在のコーディング・ユニットの動きベクトル成分と参照インデックスは、以下のように導出される。
【0175】
【数2】
【0176】
【数3】
【0177】
以下の条件の全てが真である場合、dmvrFlagは1に等しく設定される:
【0178】
【数4】
【0179】
【数5】
【0180】
【数6】
【0181】
【数7】
【0182】
【数8】
【0183】
【数9】
【0184】
【数10】
【0185】
cbWidthは8以上である。
【0186】
cbHeightは8以上である。
【0187】
cbHeight*cbWidthは128以上である。
【0188】
【数11】
【0189】
【数12】
【0190】
【数13】
【0191】
【数14】
【0192】
【数15】
【0193】
【数16】
【0194】
DMVRが使用されるかどうかを決定するフラグの導出。
【0195】
インター予測モードでコーディングされるコーディング・ユニットの復号化プロセスは、以下のような順序ステップを含む。
【0196】
1. 変数dmvrFlagは0に等しく設定される。
【0197】
2. 現在のコーディング・ユニットの動きベクトル成分と参照インデックスは、以下のように導出される。
【0198】
【数17】
【0199】
【数18】
【0200】
以下の条件の全てが真である場合、dmvrFlagは1に等しく設定される:
【0201】
【数19】
【0202】
【数20】
【0203】
【数21】
【0204】
【数22】
【0205】
【数23】
【0206】
【数24】
【0207】
【数25】
【0208】
【数26】
【0209】
cbWidthは8以上である。
【0210】
cbHeightは8以上である。
【0211】
cbHeight*cbWidthは128以上である。
【0212】
【数27】
【0213】
【数28】
【0214】
【数29】
【0215】
【数30】
【0216】
【数31】
【0217】
DMVRが使用されるかどうかを決定するフラグの導出。
【0218】
インター予測モードでコーディングされるコーディング・ユニットの復号化プロセスは、以下のような順序ステップから構成される。
【0219】
変数dmvrFlagは0に等しく設定される。
【0220】
現在のコーディング・ユニットの動きベクトル成分と参照インデックスは、以下のように導出される:
【0221】
【数32】
【0222】
【数33】
【0223】
以下の条件の全てが真である場合、dmvrFlagは1に等しく設定される:
【0224】
【数34】
【0225】
【数35】
【0226】
【数36】
【0227】
【数37】
【0228】
【数38】
【0229】
【数39】
【0230】
【数40】
【0231】
【数41】
【0232】
cbWidthは8以上である。
【0233】
cbHeightは8以上である。
【0234】
cbHeight*cbWidthは128以上である。
【0235】
図12は、本開示の実施形態によるビデオ・コーディング・デバイス1200(例えば、ビデオ・エンコーダ20又はビデオ・デコーダ30)の概略図である。ビデオ・コーディング・デバイス1200は、本件で記載されるように開示される実施形態を実施するのに適している。ビデオ・コーディング・デバイス1200は、データを受信するための入口ポート1210及び受信機ユニット(Rx)1220と、データを処理するためのプロセッサ、論理ユニット、又は中央処理ユニット(CPU)1230と、データを送信するための送信機ユニット(Tx)1240及び出口ポート1250と、データを記憶するためのメモリ1260とを含む。また、ビデオ・コーディング・デバイス1200はまた、光又は電気信号の出口及び入口に関し、入口ポート1210、受信機ユニット1220、送信機ユニット1240、及び出口ポート1250に結合された光-電気(OE)コンポーネント及び電気-光(EO)コンポーネントを含んでもよい。
【0236】
プロセッサ1230は、ハードウェア及びソフトウェアによって実現される。プロセッサ1230は、1つ以上のCPUチップ、コア(例えば、マルチコア・プロセッサ)、フィールド・プログラマブル・ゲート・アレイ(FPGA)、特定用途向け集積回路(ASIC)、及びデジタル信号プロセッサ(DSP)として実現されてもよい。プロセッサ1230は、入口ポート1210、受信機ユニット1220、送信機ユニット1240、出口ポート1250、及びメモリ1260と通信する。プロセッサ1230は、コーディング・モジュール1270を含む。コーディング・モジュール1270は、上述の開示された実施形態を実現する。例えば、コーディング・モジュール1270は、種々のコーデック機能を実装し、処理し、準備し、又は提供する。従って、コーディング・モジュール1270を含めることは、ビデオ・コーディング・デバイス1200の機能に対するかなりの改善をもたらし、ビデオ・コーディング・デバイス1200の様々な状態への変化をもたらす。代替的に、コーディング・モジュール1270は、メモリ1260に記憶された命令として実装され、プロセッサ1230によって実行される。
【0237】
ビデオ・コーディング・デバイス1200はまた、ユーザーへの及びユーザーからのデータを通信するための入力及び/又は出力(I/O)デバイス1280を含んでもよい。I/Oデバイス1280は、ビデオ・データを表示するディスプレイ、オーディオ・データを出力するスピーカのような出力デバイスを含んでもよい。I/Oデバイス1280はまた、キーボード、マウス、トラックボールなどのような入力デバイス、及び/又はそのような出力デバイスとやり取りをするための対応するインターフェースを含んでもよい。
【0238】
メモリ1260は、1つ以上のディスク、テープ・ドライブ、及びソリッド・ステート・ドライブを含み、オーバー・フロー・データ記憶デバイスとして使用されてもよく、このようなプログラムが実行のために選択された場合のプログラムを記憶し、プログラムの実行中に読み込まれた命令やデータを記憶する。メモリ1260は、揮発性及び/又は不揮発性であってもよく、リード・オンリー・メモリ(ROM)、ランダム・アクセス・メモリ(RAM)、三値連想メモリ(TCAM)、及び/又はスタティック・ランダム・アクセス・メモリ(SRAM)であってもよい
【0239】
図13は、コーディングする手段1300の実施形態の概略図である。実施形態では、コーディングする手段1300は、ビデオ・コーディング・デバイス1302(例えば、ビデオ・エンコーダ20又はビデオ・デコーダ30)で実装される。ビデオ・コーディング・デバイス1302は受信手段1301を含む。受信手段1301は、符号化するピクチャを受信したり、又は復号化するビットストリームを受信したりするように構成される。ビデオ・コーディング・デバイス1302は、受信手段1301に結合された送信手段1307を含む。送信手段1307は、ビットストリームをデコーダへ伝送したり、又は復号化されたピクチャを表示手段(例えば、I/Oデバイス1280のうちの1つ)へ伝送したりするように構成される。
【0240】
ビデオ・コーディング・デバイス1302は記憶手段1303を含む。記憶手段1303は、受信手段1301又は送信手段1307のうちの少なくとも1つに結合される。記憶手段1303は、命令を記憶するように構成される。また、ビデオ・コーディング・デバイス1302はまた、処理手段1305を含む。処理手段1305は、記憶手段1303に結合される。処理手段1305は、本件で開示される方法を実行するために、記憶手段1303に記憶された命令を実行するように構成される。
【0241】
本件で説明される例示的な方法のステップは、必ずしも説明された順序で実行される必要はないことも理解されるべきであり、そのような方法のステップの順序は、単に例示的であると理解されるべきである。同様に、追加のステップが、このような方法に含まれる可能性があり、あるステップは、本開示の種々の実施形態と調和する方法において省略されてもよいし、又は組み合わせられてもよい。
【0242】
本開示において幾つかの実施形態が提供されているが、開示されたシステムや方法は、本開示の精神又は範囲から逸脱することなく、多くの他の特定の形態で実施されてもよいことが、理解されるはずである。本件実施例は、例示的なものであり且つ非限定的なものであると考えられ、その意図は本件で与えられた詳細に限定されるものではない。例えば、種々の要素又は構成要素は別のシステムに組み合わせられたり又は統合されたりしてもよく、或いはある特徴は省略されたり又は実装されなかったりしてもよい。
【0243】
更に、様々な実施形態において個別的又は別々に説明及び図示された技術、システム、サブシステム、及び方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、又は方法と組み合わせられたり又は統合されたりしてもよい。互いに結合され、又は直接的に結合され、又は通信するように図示又は説明される他のアイテムは、電気的な、機械的な、又は他の方法であるかどうかによらず、何らかのインターフェース、デバイス、又は中間構成要素を介して間接的に結合されたり又は通信したりする可能性がある。変更、置換、及び代替の他の例は、当業者によって確認可能であり、本件で開示される精神及び範囲から逸脱することなく行うことが可能である。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
【外国語明細書】