JP7262602B2 - 一般化されたｔｒｉｓｏｕｐジオメトリ符号化のための技術 - Google Patents

Description

本出願は、2019年9月3日に出願された米国仮特許出願第62/895,339号および2020年8月27日に出願された米国特許出願第17/004,616号の優先権を主張し、それらの全体が本明細書に組み込まれる。

本開示は、ポイントクラウド符号化技術に関し、より具体的には、MPEG/G-PCCのTrisoup非可逆圧縮を一般化することを含み、かつ高速RDO方式を含むポイントクラウドジオメトリ圧縮に関する。

世界の高度な3D表現は、より没入型のインタラクションおよびコミュニケーションを可能にしている。それらはまた、機械が我々の世界を理解し、解釈し、ナビゲートすることも可能にする。ポイントクラウドは、世界の3D表現として広く使用されている。ポイントクラウドデータに関連するいくつかの使用ケースが特定されており、ポイントクラウド表現および圧縮のための対応する要件が開発されている。

ポイントクラウドは、3D空間における点のセットであり、各点は、例えば色、材料特性などの関連する属性を有する。ポイントクラウドを使用して、オブジェクトまたはシーンをそのような点の構成物として再構成することができる。それらは、様々な設定で複数のカメラおよび深度センサを使用して取り込むことができ、再構築されたシーンを現実的に表現するために数千から最大数十億の点で構成される場合がある。

圧縮技術は、ポイントクラウドを表すのに必要なデータ量を低減するために必要とされる。したがって、リアルタイム通信および6自由度（6DoF）の仮想現実で使用するためのポイントクラウドの非可逆圧縮のための技術が必要とされている。さらに、自動運転および文化遺産用途などのための動的マッピングのコンテキストにおいて、可逆ポイントクラウド圧縮のための技術も求められている。MPEGは、ジオメトリ、ならびに色および反射率、スケーラブル／プログレッシブ符号化、経時的に取り込まれたポイントクラウドのシーケンスの符号化、およびポイントクラウドのサブセットへのランダムアクセスなどの属性の圧縮に対処するために、特定の規格で機能し始めた。

非可逆G-PCC Trisoupジオメトリ符号化では、例えば、多面性が複雑すぎて、限られた数の自由パラメータを使用してモデル化することができないことが起こり得る。

したがって、このような問題に対する技術的解決策が望まれている。

1つまたは複数の異なる技術的問題に対処するために、本開示は、この問題に対処するためにMPEG/G-PCCで採用されるTrisoup技術を一般化し、提案された一般化されたTrisoupに対してレート歪み最適化（RDO）方式も予想される。

コンピュータプログラムコードを記憶するように構成されたメモリと、コンピュータプログラムコードにアクセスし、コンピュータプログラムコードによって命令されるように動作するように構成された1つまたは複数のプロセッサとを備える方法および装置が含まれている。コンピュータプログラムコードは、少なくとも1つのプロセッサに、ジオメトリを基にしたポイントクラウド圧縮（G-PCC）データに基づいてジオメトリのリーフノードを取得させるように構成された取得コードと、少なくとも1つのプロセッサに、リーフノードを複数の直方体に分割させるように構成された分割コードと、少なくとも1つのプロセッサに、直方体の各々について別々の三角形スープを導出させるように構成された導出コードと、少なくとも1つのプロセッサに、直方体の各々のエッジの各々について複数のフラグをそれぞれ符号化させるように構成された符号化コードとを含み、複数のフラグは、別々の三角形スープの頂点が前記エッジのうちのエッジに存在するかどうかを示す。

例示的な実施形態によれば、符号化コードは、少なくとも1つのプロセッサに、リーフノードの分割パターンのシグナリングを2ビットでエントロピー符号化させるようにさらに構成されており、2ビットは、リーフノードがx軸、y軸、およびz軸のうちの1つに沿って直方体に半分に分割されるかどうかを示す。

例示的な実施形態によれば、リーフノードが分割され、かつx軸およびy軸の少なくとも一方に沿った位置が、各直方体についてシグナリングされる。

例示的な実施形態によれば、導出コードは、少なくとも1つのプロセッサに、G-PCCデータの複数のリードノードのうちのリーフノードで三角形スープを再帰的に導出させるようにさらに構成される。

例示的な実施形態によれば、符号化コードは、少なくとも1つのプロセッサに、リーフノードの分割パターンのシグナリングを3ビットでエントロピー符号化させるようにさらに構成され、3ビットは、リーフノードがx軸、y軸、z軸、x軸とy軸の組み合わせ、x軸とz軸の組み合わせ、y軸とz軸の組み合わせ、ならびにx軸、y軸、およびz軸の組み合わせのうちの1つに沿って直方体に半分に分割されるかどうかを示す。

例示的な実施形態によれば、リーフノードが分割され、かつx軸、y軸、およびz軸のうちの少なくとも1つに沿った位置が、各直方体についてシグナリングされる。

例示的な実施形態によれば、コンピュータプログラムコードは、少なくとも1つのプロセッサに、リーフノードが分割されることが可能でない少なくとも1つの方向を制限するフラグがリーフノードに設定されているかどうかを判定させるように構成された判定コードをさらに含む。

例示的な実施形態によれば、コンピュータプログラムコードは、少なくとも1つのプロセッサに、レート歪み最適化（RDO）方式に従って分割パターンを判定させるように構成された判定コードをさらに含む。

例示的な実施形態によれば、リーフノードを複数の直方体に分割することは、リーフノードを半分に分割することを含む。

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

実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による線図の概略図である。 実施形態による簡略化されたブロック図である。 実施形態による簡略化されたブロック図である。 実施形態による簡略化された図である。 実施形態による簡略化されたフロー図である。 実施形態による線図の概略図である。

以下で考察する提案された特徴は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、実施形態は、処理回路（例えば、1つまたは複数のプロセッサあるいは1つまたは複数の集積回路）によって実施されてよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。

図1は、本開示の一実施形態による通信システム100の簡略化されたブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102、103を含んでよい。データの一方向送信のために、第1の端末103は、ネットワーク105を介して他の端末102に送信するためにローカル位置でビデオデータを符号化してよい。第2の端末102は、ネットワーク105から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、復元されたビデオデータを表示してよい。一方向データ送信は、メディア供給用途などでは一般的であり得る。

図1は、例えばビデオ会議中に発生する可能性がある符号化されたビデオの双方向送信をサポートするために提供される端末101と104の第2のペアを示す。データの双方向送信のために、各端末101および104は、ネットワーク105を介して他の端末に送信するためにローカル位置で、取り込んだビデオデータを符号化してよい。各端末101および104はまた、他方の端末によって送信された符号化されたビデオデータを受信する場合もあり、符号化されたデータを復号してよく、復元されたビデオデータをローカルディスプレイデバイスに表示してよい。

図1では、端末101、102、103および104は、サーバ、パーソナルコンピュータおよびスマートフォンとして示されてよいが、本開示の原理はそのように限定されるものではない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、および／または専用のビデオ会議機器を伴う用途を見い出す。ネットワーク105は、例えば有線および／または無線通信ネットワークを含む、端末101、102、103および104間で、符号化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回路交換および／またはパケット交換チャネルにおいてデータを交換してよい。代表的なネットワークには、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットが含まれる。本考察の目的のために、ネットワーク105のアーキテクチャおよびトポロジは、本明細書で以下に説明されない限り、本開示の動作にとって重要ではない場合がある。

図2は、開示される主題のための用途の一例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示す。開示される主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタルメディア上での圧縮ビデオの格納などを含む、その他のビデオ対応の用途に等しく適用可能であり得る。

ストリーミングシステムは、例えば圧縮されていないビデオサンプルストリーム213を作成する、例えばデジタルカメラなどのビデオソース201を含むことができるキャプチャサブシステム203を含んでよい。そのサンプルストリーム213は、エンコードされたビデオビットストリームと比較して高いデータ量として強調されてよく、カメラ201に結合されたエンコーダ202によって処理することができる。エンコーダ202は、以下でより詳細に説明するように、開示される主題の態様を可能にするか、または実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。エンコードされたビデオビットストリーム204は、サンプルストリームと比較してより低いデータ量として強調されてよく、将来の使用のためにストリーミングサーバ205に格納することができる。1つまたは複数のストリーミングクライアント212および207は、ストリーミングサーバ205にアクセスして、エンコードされたビデオビットストリーム204のコピー208および206を取得することができる。クライアント212は、エンコードされたビデオビットストリームの着信コピー208を復号し、ディスプレイ209または他のレンダリングデバイス（図示せず）上にレンダリングすることができる発信ビデオサンプルストリーム210を形成するビデオデコーダ211を含むことができる。一部のストリーミングシステムでは、ビデオビットストリーム204、206および208は、特定のビデオ符号化／圧縮規格に従ってエンコードすることができる。これらの規格の例は、上記で言及されており、本明細書でさらに説明される。

図3は、本発明の一実施形態によるビデオデコーダ300の機能ブロック図であり得る。

受信器302は、デコーダ300によって復号されるべき1つまたは複数のコーデックビデオシーケンスを受信してよく、同じまたは別の実施形態では、一度に1つの符号化されたビデオシーケンスを受信してよく、この場合、各符号化されたビデオシーケンスの復号は、他の符号化されたビデオシーケンスから独立している。符号化されたビデオシーケンスは、チャネル301から受信されてよく、チャネルは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信器302は、それぞれの使用エンティティ（描かれていない）に転送され得る他のデータ、例えば符号化されたオーディオデータおよび／または補助データストリームとともに、エンコードされたビデオデータを受信してもよい。受信器302は、符号化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ303が、受信器302とエントロピーデコーダ／パーサー304（以降、「パーサー」）との間に結合されてよい。受信器302が十分な帯域幅と制御性を持つ記憶／転送装置から、またはアイソクロナスネットワークからデータを受信している場合、バッファ303は必要なくてもよい、または小さい場合もある。インターネットなどのベストエフォートパケットネットワークで使用する場合、バッファ303が必要とされる場合があり、比較的大きくすることができ、有利には適応サイズとすることができる。

ビデオデコーダ300は、エントロピー符号化されたビデオシーケンスからシンボル313を再構築するためのパーサー304を含み得る。これらのシンボルのカテゴリには、デコーダ300の動作を管理するために使用される情報、および場合によっては、デコーダの不可欠な部分ではないが、それに結合することができるディスプレイ312などのレンダリングデバイスを制御するための情報が含まれる。レンダリングデバイスの制御情報は、補足拡張情報（SEIメッセージ）またはビデオユーザビリティ情報パラメータセットの小部分（描かれていない）の形式であり得る。パーサー304は、受信した符号化されたビデオシーケンスを解析／エントロピー復号してよい。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術または規格に従うことができ、可変長符号化、ハフマン符号化、文脈依存性を伴う、または伴わない算術符号化などを含む、当業者によく知られた様々な原理に従うことができる。パーサー304は、符号化されたビデオシーケンスから、そのグループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャのグループ（GOP）、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことができる。エントロピーデコーダ／パーサーはまた、変換係数、量子化器パラメータ値、動きベクトルなどのような符号化されたビデオシーケンス情報を抽出してもよい。

パーサー304は、シンボル313を作成するために、バッファ303から受信したビデオシーケンスに対してエントロピー復号／解析動作を実行することができる。パーサー304は、エンコードされたデータを受信し、特定のシンボル313を選択的に復号してよい。さらに、パーサー304は、特定のシンボル313が、動き補償予測ユニット306、スケーラ／逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311に提供されるべきかどうかを判定してよい。

シンボル313の再構築には、符号化されたビデオピクチャまたはその一部のタイプ（インターピクチャおよびイントラピクチャ、インターブロックおよびイントラブロックなど）、ならびにその他の要因に応じて、複数の異なるユニットを関与させることができる。どのユニットがどのように関与しているかは、パーサー304によって、符号化されたビデオシーケンスから解析されたサブグループ制御情報によって管理することができる。パーサー304と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。

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

最初のユニットは、スケーラ／逆変換ユニット305である。スケーラ／逆変換ユニット305は、量子化された変換係数、ならびに使用する変換、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報をパーサー304からシンボル313として受け取る。それは、アグリゲータ310に入力することができるサンプル値を含むブロックを出力することができる。

一部のケースでは、スケーラ／逆変換305の出力サンプルは、イントラ符号化されたブロックに関係する場合があり、つまり、以前に再構築されたピクチャからの予測情報は使用していないが、現在のピクチャの以前に再構築された部分からの予測情報を使用できるブロックに関係する場合がある。そのような予測情報は、イントラピクチャ予測ユニット307によって提供することができる。一部のケースでは、イントラピクチャ予測ユニット307は、現在の（部分的に再構築された）ピクチャ309からフェッチされた周囲のすでに再構築された情報を使用して、再構築中のブロックの同一サイズおよび同一形状のブロックを生成する。アグリゲータ310は、一部のケースでは、サンプルごとに、イントラ予測ユニット307が生成した予測情報をスケーラ／逆変換ユニット305によって提供されるような出力サンプル情報に追加する。

他のケースでは、スケーラ／逆変換ユニット305の出力サンプルは、インター符号化された、および場合によっては動き補償されたブロックに関係する場合もある。そのようなケースでは、動き補償予測ユニット306は、参照ピクチャメモリ308にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルをブロックに関連するシンボル313に従って動き補償した後、これらのサンプル（この場合、残差サンプルまたは残差信号と呼ばれる）は、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ／逆変換ユニットの出力に追加することができる。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、動きベクトルによって制御することができ、例えば、X、Y、および参照ピクチャ成分を有し得るシンボル313の形態で動き補償ユニットが利用できるようにすることができる。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされたサンプル値の補間、動きベクトル予測メカニズムなどを含む場合もある。

アグリゲータ310の出力サンプルは、ループフィルタユニット311における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、符号化されたビデオビットストリームに含まれるパラメータによって制御され、パーサー304からのシンボル313としてループフィルタユニット311が利用できるようになっているループ内フィルタ技術を含むことができるが、これはまた、符号化されたピクチャまたは符号化されたビデオシーケンスのこれまでの（復号順で）部分の復号中に取得されたメタ情報に応答し、また以前に再構築されループフィルタリングされたサンプル値に応答したりする場合もある。

ループフィルタユニット311の出力は、レンダリングデバイス312に出力され得るだけでなく、将来のインターピクチャ予測で使用するために参照ピクチャメモリ557に格納されるサンプルストリームにすることもできる。

特定の符号化されたピクチャは、完全に再構築されると、将来の予測のための参照ピクチャとして使用することができる。符号化されたピクチャが完全に再構築され、符号化されたピクチャが（例えば、パーサー304によって）参照ピクチャとして識別されると、現在の参照ピクチャ309は、参照ピクチャバッファ308の一部になることができ、次の符号化されたピクチャの再構築を開始する前に、新しい現在のピクチャメモリを再割り当てすることができる。

ビデオデコーダ300は、ITU-T Rec.H.265などの規格で文書化され得る所定のビデオ圧縮技術に従って復号化動作を実行することができる。符号化されたビデオシーケンスは、ビデオ圧縮技術文書または規格において指定されるように、および具体的にはそこで文書化されたプロファイルにおいて指定されるように、ビデオ圧縮技術または規格の構文に準拠しているという意味において、使用されているビデオ圧縮技術または規格によって指定された構文に従ってよい。また、符号化されたビデオシーケンスの複雑さが、ビデオ圧縮技術または規格のレベルで定義されている範囲内にあることもコンプライアンスには必須である。一部のケースでは、レベルによって、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート（例えば、メガサンプル／秒で測定された）、最大参照ピクチャサイズなどが制限される。レベルによって設定された制限は、一部のケースでは、仮想参照デコーダ（HRD）の仕様、および符号化されたビデオシーケンスで通知されるHRDバッファ管理のメタデータによってさらに制限される場合がある。

一実施形態では、受信器302は、エンコードされたビデオとともに追加の（冗長な）データを受信する場合がある。追加のデータは、符号化されたビデオシーケンスの一部として含まれる場合がある。追加のデータは、データを適切に復号する、および／または元のビデオデータをより正確に再構築するためにビデオデコーダ300によって使用されてよい。追加のデータは、例えば、時間的、空間的、または信号ノイズ比（SNR）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、フォワードエラー訂正コードなどの形式にすることができる。

図4は、本開示の一実施形態によるビデオエンコーダ400の機能ブロック図であってよい。

エンコーダ400は、エンコーダ400によって符号化すべきビデオ画像を取り込むことができる（エンコーダの一部ではない）ビデオソース401からビデオサンプルを受信してよい。

ビデオソース401は、任意の適切なビット深度（例えば8ビット、10ビット、12ビット…）、任意の色空間（例えば、BT.601 Y CrCB、RGB、…）、および任意の適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタルビデオサンプルストリームの形態で、エンコーダ（303）によって符号化すべきソースビデオシーケンスを提供してよい。メディア供給システムでは、ビデオソース401は、これまでに準備されたビデオを格納する記憶装置であり得る。ビデオ会議システムでは、ビデオソース401は、ローカル画像情報をビデオシーケンスとして取り込むカメラである場合もある。ビデオデータは、順番に見たときに動きを与える複数の個別のピクチャとして提供され得る。ピクチャ自体は、ピクセルの空間アレイとして編成することができ、この場合、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明では、サンプルを中心に説明する。

一実施形態によれば、エンコーダ400は、用途によって要求されるように、リアルタイムで、または任意の他の時間制約の下で、ソースビデオシーケンスのピクチャを符号化し、符号化されたビデオシーケンス410に圧縮することができる。適切な符号化速度を施行することは、コントローラ402の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、結合は描かれていない。コントローラによって設定されるパラメータには、レート制御関連パラメータ（ピクチャスキップ、量子化、レート歪み最適化手法のラムダ値など）、ピクチャサイズ、ピクチャグループ（GOP）レイアウト、最大動きベクトル検索範囲などを含めることができる。当業者であれば、コントローラ402の他の機能は、それらが特定のシステム設計のために最適化されたビデオエンコーダ400に関連し得るため、容易に特定することができる。

いくつかのビデオエンコーダは、当業者が「符号化ループ」として容易に認識するものにおいて動作する。過度に簡略化された説明として、符号化ループは、エンコーダ402（以後は「ソースコーダ」）（符号化すべき入力ピクチャおよび参照ピクチャに基づいてシンボルを作成する役割を担う）の符号化部分と、（リモート）デコーダも同様に作成するであろう（開示された主題で考慮されるビデオ圧縮技術では、シンボルと符号化されたビデオビットストリームとの間の任意の圧縮が可逆的であるため）サンプルデータを作成するためにシンボルを再構築する、エンコーダ400に埋め込まれた（ローカル）デコーダ406とで構成することができる。再構築されたサンプルストリームは、参照ピクチャメモリ405に入力される。シンボルストリームの復号は、デコーダの場所（ローカルまたはリモート）に関係なくビットイグザクト結果をもたらすため、参照ピクチャバッファコンテンツもまた、ローカルエンコーダとリモートエンコーダとの間でビットイグザクトである。言い換えると、エンコーダの予測部分は、参照ピクチャのサンプルとして、デコーダが復号中に予測を使用する際に「見る」のとまったく同じサンプル値を「見る」。参照ピクチャの同期性（および、例えばチャネルエラーのために同期性を維持できない場合に結果として生じるドリフト）のこのような基本原理は、当業者によく知られている。

「ローカル」デコーダ406の動作は、「リモート」デコーダ300の動作と同じであってよく、これは、図3に関連して上記で詳細にすでに説明されている。しかしながら、図4も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ408およびパーサー304による符号化されたビデオシーケンスへのシンボルの符号化／復号化は可逆であり得るため、チャネル301、受信器302、バッファ303およびパーサー304を含むデコーダ300のエントロピー復号化部分は、ローカルデコーダ406に完全には実装されない場合がある。

この時点で行うことができる観察は、デコーダに存在する解析／エントロピー復号化以外のいかなるデコーダ技術も、対応するエンコーダにも実質的に同一の機能形式で必ず存在する必要があることである。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略することができる。特定の部分でのみ、より詳細な説明が必要であり、以下に提供される。

その動作の一部として、ソースコーダ403は、動き補償予測符号化を実行してよく、これは、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前に符号化されたフレームを参照して入力フレームを予測的に符号化する。この方法において、符号化エンジン407は、入力フレームのピクセルブロックと、入力フレームへの予測参照として選択され得る参照フレームのピクセルブロックとの差を符号化する。

ローカルビデオデコーダ406は、ソースコーダ403によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータを復号してよい。符号化エンジン407の動作は、非可逆プロセスであることが有利であり得る。符号化されたビデオデータがビデオデコーダ（図4には示されていない）で復号され得るとき、再構築されたビデオシーケンスは通常、いくつかのエラーを伴うソースビデオシーケンスの複製であり得る。ローカルビデオデコーダ406は、参照フレームに対してビデオデコーダによって実行され得る復号化プロセスを複製し、再構築された参照フレームを参照ピクチャキャッシュ405に記憶させてよい。この方法において、エンコーダ400は、（送信エラーがない限り）遠端のビデオデコーダによって取得されるであろう再構築された参照フレームとして共通のコンテンツを有する再構築された参照フレームのコピーをローカルに格納してよい。

予測器404は、符号化エンジン407の予測検索を実行してよい。すなわち、符号化すべき新しいフレームについて、予測器404は、サンプルデータ（候補参照ピクセルブロックとしての）、または新しいピクチャの適切な予測参照として機能し得る、参照ピクチャの動きベクトル、ブロック形状などの特定のメタデータについて参照ピクチャメモリ405を検索してよい。予測器404は、適切な予測参照を見つけるために、ピクセルブロックごとのサンプルブロックに基づいて動作してよい。一部のケースでは、予測器404によって得られた検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ405に格納された複数の参照ピクチャから引き出された予測参照を有してよい。

コントローラ402は、例えば、ビデオデータをエンコードするために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ403の符号化動作を管理してよい。

すべての前述の機能ユニットの出力は、エントロピーコーダ408でエントロピー符号化を受ける場合がある。エントロピーコーダは、例えばハフマン符号化、可変長符号化、算術符号化などの、当業者に既知の技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットによって生成されたシンボルを符号化されたビデオシーケンスに変換する。

送信器409は、エントロピーコーダ408によって作成された符号化されたビデオシーケンスをバッファリングして、通信チャネル411を介した送信のためにそれを準備することができ、この通信チャネルは、エンコードされたビデオデータを格納する記憶装置へのハードウェア／ソフトウェアリンクであってよい。送信器409は、ビデオコーダ403からの符号化されたビデオデータを、送信すべき他のデータ、例えば符号化されたオーディオデータおよび／または補助データストリーム（ソースは図示せず）と合体させてもよい。

コントローラ402は、エンコーダ400の動作を管理してよい。符号化中に、コントローラ405は、各符号化されたピクチャに特定の符号化ピクチャタイプを割り当ててよく、これは、それぞれのピクチャに適用され得る符号化技術に影響を及ぼす可能性がある。例えば、多くの場合、ピクチャは次のフレームタイプのうちの1つとして割り当てられてよい。

イントラピクチャ（Iピクチャ）は、シーケンス内の任意の他のフレームを予測のソースとして使用せずに符号化および復号され得るものであってよい。一部のビデオコーデックは、例えば、独立デコーダリフレッシュピクチャを含めた、様々なタイプのイントラピクチャを可能にする。当業者は、Iピクチャのそれらの変形形態、およびそのそれぞれの用途および特徴を認識している。

予測ピクチャ（Pピクチャ）は、各ブロックのサンプル値を予測するために最大で1つの動きベクトルと、参照インデックスとを使用するイントラ予測またはインター予測を使用して符号化および復号され得るものであってよい。

双方向予測ピクチャ（Bピクチャ）は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトルと、参照インデックスとを使用するイントラ予測またはインター予測とを使用して符号化および復号化され得るものであってよい。同様に、複数の予測ピクチャは、単一のブロックの再構築に3つ以上の参照ピクチャと関連メタデータを使用できる。

ソースピクチャは、通常、複数のサンプルブロック（例えば、4×4、8×8、4×8、または16×16サンプルそれぞれのブロック）に空間的に再分割され、ブロックごとに符号化されてよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定されるように、他の（すでに符号化された）ブロックを参照して予測的に符号化されてよい。例えば、Iピクチャのブロックは非予測的に符号化されてもよく、またはそれらは同じピクチャのすでに符号化されたブロックを参照して非予測的に（空間的予測またはイントラ予測）符号化されてもよい。Pピクチャのピクセルブロックは、空間的予測を介して、または以前に符号化された1つの参照ピクチャを参照して時間的予測を介して、非予測的に符号化され得る。Bピクチャのブロックは、空間的予測を介して、または1つまたは2つの以前に符号化された参照ピクチャを参照して時間的予測を介して、非予測的に符号化され得る。

ビデオエンコーダ400は、ITU-T Rec.H.265などの所定のビデオの符号化技術または規格に従って符号化動作を実行することができる。その動作において、ビデオエンコーダ400は、入力ビデオシーケンスの時間的および空間的冗長性を活用する予測符号化動作を含む、様々な圧縮動作を実行することができる。したがって、符号化されたビデオデータは、使用されているビデオの符号化技術または規格で指定された構文に準拠してよい。

一実施形態では、送信器409は、エンコードされたビデオとともに追加のデータを送信してもよい。ソースコーダ403は、そのようなデータを、符号化されたビデオシーケンスの一部として含む場合がある。追加のデータには、時間／空間／SNR強化レイヤ、冗長ピクチャおよびスライスなどの他の形態の冗長データ、補足強化情報（SEI）メッセージ、視覚的有用性情報（VUI）パラメータセットの小部分などが含まれてよい。

図5は、HEVCおよびJEMで使用されるイントラ予測モードを示している。未加工のビデオに提示される任意のエッジ方向を捕らえるために、指向性イントラモードの数は、HEVCで使用される33から65に拡張される。HEVCの上部のJEMにおける追加の指向性モードは、図1（b）において点線矢印として示されており、平面モードおよびDCモードは同じままである。これらのより高密度の指向性イントラ予測モードは、すべてのブロックサイズに、および輝度および彩度イントラ予測の両方に適用される。図5に示すように、奇数イントラ予測モードインデックスに関連付けられた、点線の矢印によって識別される指向性イントラ予測モードは、奇数イントラ予測モードと呼ばれる。実線矢印で識別される、偶数イントラ予測モードインデックスに関連付けられた指向性イントラ予測モードは、偶数イントラ予測モードと呼ばれる。本明細書では、図5の実線または点線の矢印で示されるように、指向性イントラ予測モードは角度モードとも呼ばれる。

JEMでは、輝度イントラ予測に合計67個のイントラ予測モードが用いられる。イントラモードを符号化するために、サイズ6の最確モード（MPM）リストが、隣接ブロックのイントラモードに基づいて構築される。イントラモードがMPMリストからのものでない場合、イントラモードが選択されたモードに属するかどうかを示すフラグがシグナリングされる。JEM-3.0では、16個の選択されたモードがあり、これらは4つ目の角度モードごとに一様に選択される。JVET-D0114およびJVET-G0060では、一様に選択されたモードを置き換えるために16個の二次MPMが導出される。

図6は、イントラ指向性モードのために利用されるN個の参照階層を示す。ブロックユニット611、セグメントA 601、セグメントB 602、セグメントC 603、セグメントD 604、セグメントE 605、セグメントF 606、第1の参照階層610、第2の参照階層609、第3の参照階層608および第4の参照階層607が存在する。

HEVCおよびJEMの両方、ならびにH.264／AVCなどの他のいくつかの規格では、現在のブロックを予測するために使用される参照サンプルは、最も近い参照ライン（行または列）に制限される。複数の参照ラインイントラ予測の方法では、候補参照ライン（行または列）の数は、イントラ指向性モードに対して1（すなわち、最も近い）からNに増加され、この場合Nは1以上の整数である。図2は、複数ラインのイントラ方向予測方法の概念を示すために、例として4×4予測ユニット（PU）を引用する。イントラ指向性モードは、予測子を生成するためにN個の参照階層のうちの1つを任意に選択することができる。言い換えれば、予測子p（x，y）は、参照サンプルS1、S2、...、およびSNのうちの1つから生成される。どの参照階層がイントラ指向性モードのために選択されるかを示すためにフラグがシグナリングされる。Nが1に設定される場合、イントラ指向性予測方法は、JEM 2.0の従来の方法と同じである。図6では、参照ライン610、609、608および607は、左上参照サンプルとともに6つのセグメント601、602、603、604、605および606から構成される。本明細書では、参照階層は参照ラインとも呼ばれる。現在のブロックユニット内の左上ピクセルの座標は（0，0）であり、第1の参照ライン内の左上ピクセルは（－1，－1）である。

JEMでは、輝度成分について、イントラ予測サンプル生成に使用される隣接するサンプルは、生成プロセスの前にフィルタリングされる。フィルタリングは、所与のイントラ予測モードおよび変換ブロックサイズによって制御される。イントラ予測モードがDCであるか、または変換ブロックサイズが4×4に等しい場合、隣接するサンプルはフィルタリングされない。所与のイントラ予測モードと垂直モード（または水平モード）との間の距離が所定の閾値よりも大きい場合、フィルタプロセスは有効にされる。隣接するサンプルフィルタリングには、［1，2，1］フィルタおよびバイリニアフィルタが使用される。

位置依存イントラ予測合成（PDPC）方法は、フィルタリングされていない境界参照サンプルと、フィルタリングされた境界参照サンプルを有するHEVCスタイルのイントラ予測との組み合わせを引き起こすイントラ予測方法である。（x，y）に位置する各予測サンプルpred［x］［y］は、以下のように計算される。
pred［x］［y］＝（wL＊R_－1，y＋wT＊R_x，－1＋wTL＊R_－1，－1＋（64－wL－wT－wTL）＊pred［x］［y］＋32）＞＞6（式2－1）
式中、R_x，－1、R_－1，yは、それぞれ現在のサンプル（x，y）の上部および左に位置するフィルタリングされていない参照サンプルを表し、R_－1，－1は、現在のブロックの左上隅に位置するフィルタリングされていない参照サンプルを表す。重み付けは以下のように計算される。
wT＝32＞＞（（y＜＜1）＞＞shift）（式2－2）
wL＝32＞＞（（x＜＜1）＞＞shift）（式2－3）
wTL＝－（wL＞＞4）－（wT＞＞4）（式2－4）
shift＝（log 2（幅）＋log 2（高さ）＋2）＞＞2（式2－5）。

図7は、1つの4×4ブロック内の（0，0）および（1，0）位置に対してDCモードPDPCが（wL，wT，wTL）重み付けする図700を示す。PDPCがDC、平面、水平、および垂直イントラモードに適用される場合、HEVC DCモード境界フィルタまたは水平／垂直モードエッジフィルタなどの追加の境界フィルタは必要とされない。図7は、右上対角モードに適用されたPDPCの参照サンプルRx，－1、R－1，yおよびR－1，－1の定義を示す。予測サンプルpred（x’，y’）は、予測ブロック内の（x’，y’）に位置する。参照サンプルRx，－1の座標xは、x＝x’＋y’＋1によって与えられ、参照サンプルR－1，yの座標yも同様に、y＝x’＋y’＋1によって与えられる。

図8は、局所照明補償（LIC）線図800を示し、換算係数aおよびオフセットbを使用した、照明変化の線形モデルに基づいている。それは、各モード間の符号化された符号化ユニット（CU）に適応させて有効または無効にされる。

LICがCUに適用する場合、最小二乗誤差法を使用して、現在のCUの隣接するサンプルおよびそれらの対応する参照サンプルを使用してパラメータaおよびbを導出する。より具体的には、図8に例示されるように、CUのサブサンプリング（2：1サブサンプリング）された隣接するサンプル、および参照ピクチャ内の（現在のCUまたはサブCUの動き情報によって識別される）対応するサンプルが使用される。ICパラメータは、各予測方向に対して別々に導出され適用される。

CUがマージモードで符号化される場合、LICフラグは、マージモードにおける動き情報コピーと同様の方法で、隣接ブロックからコピーされ、そうでない場合、LICフラグがCUのためにシグナリングされ、LICが適用されるか否かを指示する。

図9Aは、HEVCで使用されるイントラ予測モード900を示す。HEVCには合計35のイントラ予測モードがあり、その中でモード10は水平モードであり、モード26は垂直モードであり、モード2、モード18およびモード34は対角モードである。イントラ予測モードは、3つの最確モード（MPM）と残りの32個のモードとによってシグナリングされる。

図9Bは、VVCの実施形態において、モード18が水平モードであり、モード50が垂直モードであり、モード2、モード34およびモード66が対角モードである合計87個のイントラ予測モードがあることを示す。モード－1～－10およびモード67～76は、広角イントラ予測（WAIP）モードと呼ばれる。

位置（x、y）に位置する予測サンプルpred（x，y）は、イントラ予測モード（DC、平面、角度）およびPDPC表現による参照サンプルの線形結合を使用して予測され、
pred（x，y）＝（wL×R－1，y＋wT×Rx，－1－wTL×R－1，－1＋（64－wL－wT＋wTL）×pred（x，y）＋32）＞＞6であり、
式中、Rx，－1、R－1，yは、それぞれ現在のサンプル（x，y）の上部および左に位置する参照サンプルを表し、R－1，－1は、現在のブロックの左上隅に位置する参照サンプルを表す。

DCモードの場合、重みは、幅および高さの寸法を有するブロックについて以下のように計算され、
wT＝32＞＞（（y＜＜1）＞＞nScale），wL＝32＞＞（（x＜＜1）＞＞nScale），wTL＝（wL＞＞4）＋（wT＞＞4）、
ここで、nScale＝（log2（幅）－2＋log 2（高さ）－2＋2）＞＞2であり、式中、wTは、同じ水平座標を有する上記の参照ラインに位置する参照サンプルの重み係数を表し、wLは、同じ垂直座標を有する左の参照ラインに位置する参照サンプルの重み係数を表し、wTLは、現在のブロックの左上の参照サンプルの重み係数を表し、nScaleは、軸に沿って重み付け係数がどれだけ速く減少する（wLは左から右に減少する、またはwTは上から下に減少する）かを指定する、すなわち重み付け係数減少率を指定し、それは、現在の設計におけるx軸（左から右へ）およびy軸（上から下へ）に沿って同じである。また、32は隣接するサンプルの初期の重み付け係数を表し、初期の重み付け係数はまた、現在のCBにおいて左上のサンプルに割り当てられた上（左または左上）の重み付けであり、PDPCプロセスにおける隣接するサンプルの重み付け係数は、この初期の重み付け係数以下でなければならない。

平面モードの場合、wTL＝0であり、一方、水平モードの場合、wTL＝wTであり、垂直モードの場合、wTL＝wLである。PDPC重みは、加算およびシフトのみで計算することができる。pred（x，y）の値は、式1を使用して1つのステップで算出することができる。

図10および図11はそれぞれ、実施形態による簡略化されたブロック図1000および1100であり、ジオメトリを基にしたポイントクラウド圧縮（G-PCC）エンコーダおよびデコーダの異なる概要を提供する。エンコーダおよびデコーダの両方において、ポイントクラウド位置が最初に符号化される。属性符号化は、復号されたジオメトリに依存する。図10および図11では、領域適応階層変換（RAHT）および表面近似モジュールは、カテゴリ1のデータに通常使用されるオプションである。詳細レベル（LOD）を生成するモジュールおよびリフティングモジュールは、カテゴリ3のデータに通常使用されるオプションである。他のすべてのモジュールは、カテゴリ1と3との間で共通である。

カテゴリ3のデータの場合、圧縮されたジオメトリは、個々のボクセルのルートからリーフレベルまでずっと八分木として表されてよい。カテゴリ1のデータの場合、圧縮されたジオメトリは、プルーニングされた八分木（すなわち、ボクセルよりも大きいブロックのルートからリーフレベルまでの八分木）と、プルーニングされた八分木の各リーフ内の表面に近似するモデルとによって表されてよい。このようにして、カテゴリ1および3の両方のデータは八分木符号化メカニズムを共有し、カテゴリ1のデータはさらに、各リーフ内のボクセルを表面モデルで近似してよい。使用される表面モデルは、ブロック当たり1～10個の三角形を含む三角測量であり、結果として三角形スープが得られる。したがって、カテゴリ1のジオメトリコーデックは、Trisoupジオメトリコーデックとして知られており、カテゴリ3のジオメトリコーデックは、八分木ジオメトリコーデックとして知られている。

G-PCCには、RAHT符号化、補間を基にした階層的最近傍予測（予測変換）、および更新／リフティングステップを伴う補間を基にした階層的最近傍予測（リフティング変換）の3つの属性符号化方法がある。RAHTおよびリフティングは、通常、カテゴリ1のデータに使用され、予測は、通常、カテゴリ3のデータに使用される。しかしながら、いずれの方法も任意のデータに使用されてよく、G-PCCのジオメトリコーデックと同様に、ユーザは3つの属性コーデックのうちどれを使用したいかを選択するオプションを有する。

例示的な実施形態によれば、ジオメトリは最初に、八分木符号化を使用してユーザが指定したレベルまで可逆的に符号化されてよい。次いで、三角形のセット（別名、スープ）を使用して、より細かいジオメトリ細部が不可逆的に近似されてよい。対応する立方体を通過する表面（多面性）を集合的に近似する八分木の各リーフノードにおいて、別々の三角形のセットが導出されてよい。スープを作成するために、立方体の各エッジに対して単一の頂点が導出されてよく、これは、表面を近似するために最大12個の頂点を自由に使用できることを意味する。平滑な表面は、12個の利用可能な自由パラメータを使用して十分に良好にモデル化することができるが、しかしながら、多面性が複雑すぎて、この限られた数の自由パラメータを使用してモデル化することができないことが起こる場合がある。したがって、例示的な実施形態は、この問題に対処するためにMPEG/G-PCCで採用されるTrisoup技術を一般化し、提案された一般化Trisoupに対してレート歪み最適化（RDO）方式も予想される。

提案された方法は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、方法（または実施形態）、エンコーダおよびデコーダの各々は、処理回路（例えば、1つまたは複数のプロセッサあるいは1つまたは複数の集積回路）によって実施されてよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。

図12は、実施形態による簡略された図1200であり、作成されたTrisoupのリーフでの例1201を示す。例1201の中で示される、とりわけ例示的なエッジ1202などの各固有のエッジについて、とりわけ例示的な頂点1203などの頂点を有するか否かを示すフラグが符号化されてよい。エッジが頂点を有する場合、そのエッジに沿った頂点の位置も符号化されてよい。例示的な実施形態によれば、各エッジは最大で1つの頂点を有することが許可されてよい。

図13は、実施形態による簡略化されたフロー図1300であり、特徴のうちの1つまたは複数は、図示された順序で、および／または図示されたものとは異なる順序で、1つまたは複数の他の特徴とは別個に使用され得ることが理解されよう。

例示的な実施形態によれば、S1301として、1つまたは複数のリーフノードが取得され、S1302において、各リーフノードに2つ以上の三角形スープが作成される。これは、三角形の1つのスープのみを使用してモデル化するには複雑すぎる多面性をより良好にモデル化するのに役立つ。この目的のために、S1302において最初に、各リーフノードを2つ以上のより小さい長方形／正方形の直方体に分割する。次いで、S1303において、生成された各直方体について別々の三角形スープが導出されてよい。リーフノードをより小さい直方体に分割すると、新たな角地点のセットならびに新たなエッジのセットが導入される。例えば、リーフノードのエッジは半分に分割することができ、その結果、そのエッジの端点の間に1つの新たな角地点が生成され、例示的な実施形態によれば、エッジを2つのより短い新しいものに置き換えることになり、また固定された分割パターンをすべてのリーフに使用することができ、および／または、以下でさらに説明するように、分割パターンを各リーフノードに適応させて導出し、それに応じてシグナリングすることができる。

例示的な実施形態によれば、図13に例示されるように、S1302は、ステップS1304～S1310のうちの1つまたは複数を含んでよい。例えば、S1306において、各リーフノードの分割パターンの信号が存在してよく、実施形態によれば、戦略は、分割パターンを示すためにリーフノードごとに2ビットのみをシグナリングすることであってよい。
00⇒分割なし（1 Trisoup）
01⇒リーフノードをx軸に沿って半分に分割する（2つのTrisoup）
10⇒リーフノードをy軸に沿って半分に分割する（2つのTrisoup）
11⇒リーフノードをz軸に沿って半分に分割する（2つのTrisoup）

そのような分割パターンは、エントロピー符号化され、S1321において最終ビットストリームに書き込まれてよい。様々な分割パターンを設計および採用することができる。採用された分割パターンの数がNである場合、リーフノードごとのパターンをシグナリングするために［log₂N］ビットが必要である。

また、1つまたは複数の例示的な実施形態によれば、三角形スープは、各リーフノードにおいてS1309で再帰的に導出されてもよい。各直方体について、xyzによって示される3つのビットが各分割レベルでシグナリングされてよい。例えば、分割レベル0では、リーフノードは、以下の8つの方法で分割され得る。
xyz＝000⇒分割なし（1つのTrisoup）
xyz＝001⇒リーフノードをx軸に沿って半分に分割する（2つのTrisoup）
xyz＝010⇒ノードをy軸に沿って半分に分割する（2つのTrisoup）
xyz＝011⇒ノードをz軸に沿って半分に分割する（2つのTrisoup）
xyz＝100⇒ノードをx軸およびy軸に沿って半分に分割する（4つのTrisoup）
xyz＝101⇒リーフノードをx軸およびz軸に沿って半分に分割する（4つのTrisoup）
xyz＝110⇒リーフノードをy軸およびz軸に沿って半分に分割する（4つのTrisoup）
xyz＝111⇒リーフノードをx、y、およびz軸に沿って半分に分割する（8つのTrisoup）

同様に、分割レベル1では、レベル0で生成された各直方体で分割パターンをシグナリングするために3つの追加のビットが必要とされ得る。これらのビットはエントロピー符号化され、S1321でビットストリームに書き込まれてよい。

また、1つまたは複数の例示的な実施形態によれば、S1306およびS1309に関する実施形態における分割は、特定の軸に沿った任意の位置で行われてよい。そのようなケースでは、各直方体について、軸ごとに分割位置のための信号が存在してもよい。任意の分割レベルにおいて、特定の軸に沿ったボクセルの数がLである場合、その軸に沿った分割位置をシグナリングするために［log₂L］ビットが必要である。これらのビットはエントロピー符号化され、S1321でビットストリームに書き込まれる。

また、1つまたは複数の例示的な実施形態によれば、固有のセグメントのセットに対応する分割フラグのセットは、S1304においてシグナリングされてよい。例えば、各リーフノード、またはその1つもしくは複数は、1つの方向（すなわち、x、y、またはz）にのみに沿って分割されることが許可されてよい、またはフラグに従ってまったく分割されなくてもよい。そのような例は、任意の数の軸に沿って、任意の位置で、再帰的なやり方で、任意の分割パターンに容易に一般化されてよい。例えば、分割がセグメントの中央のみで許可される場合、そのセグメントが分割されているか否かを示すために、各固有のセグメントに対してフラグがシグナリングされる。フラグがオフである場合、最大で1つの頂点がその固有のセグメントに対してシグナリングされる。フラグがオンである場合、2つの頂点がその固有のセグメントについてシグナリングされる。リーフノードの分割されたセグメントと、分割されていないセグメントのセットを知ることにより、デコーダは、S1331などにおいて、そのリーフノードがそれに沿って分割される軸を容易に導出し、1つまたは2つまたは0のいずれかのTrisoupを生成することができる。

また、1つまたは複数の例示的な実施形態によれば、S1321において、最適な分割パターンを判定するためにエンコーダでRDO（レート歪み最適化）方式が使用されてもよい。そのようなエンコーダは、最適な分割の選択を見つけるために複数の戦略のいずれかを採用してよい。例示的な実施形態は、例えば、エンコーダによってチェックされる分割オプションのセットをΩで示す。各オプションω∈Ωに対して、エンコーダは、Τ（ω）によって示されるその分割オプションによって生成されるすべての三角形Trisoupの結合である表面を導出する。T（ω）が与えられると、エンコーダは、符号化されていない点と再構築された点との間の歪みD（ω）を算出することができる（再構築された点は、T（ω）および三角測量ステップ、それに続くアップサンプリングステップを使用して生成される）。次いで、最適な分割オプションは、以下の

によって算出され、ここで、R（ω）は符号化率であり、λはラグランジュ乗数である。
さらに、共通の幾何学的測定学を使用して（分割オプションごとに）歪みを算出することは、計算コストが高くなる可能性がある。符号化利得の低減を犠牲にして、より複雑でない方法がエンコーダによって使用されてもよい。例は、例示的な実施形態によれば、歪みD（ω）を表面T（ω）からの符号化されない点の平均距離として算出し、直方体に含まれる点の数が特定の閾値を下回る場合に早期終了を使用して分割を停止する、および／またはより大きな点密度を有する直方体を生成する分割を優先してもよい。

例示的な実施形態によれば、利用可能な分割パターンのセットの中で特定の分割パターン（再帰的または非再帰的に導出される）が各リーフノードに対してシグナリングされてもよく、この場合、各分割は直方体のエッジを常に半分に分割するが、以下の表4.3.1では、表4.3.2のように任意の位置で分割が行われてもよい。

上記の表を考慮した例示的な実施形態によれば、意味的に、
generalized_trisoup_present_flagは、一般化されたTrisoupを使用するか否かを示し、
split_pattern［i］は、リーフノードiの分割パターンを判定するビットパターンを示し、分割が再帰的に行われる場合、split_pattern［i］は、x軸、y軸、およびz軸に対応する3の倍数であり、および／または、split_location［i］は、分割位置を示す。split_pattern［i］の各1つに対応して、サイズ

ビットの分割位置がシグナリングされ、この場合Lはボクセルの数を表す。

さらに、S1331において、リードノードレベルでのシグナリングを含む復号プロセスが存在してもよく、そこでは、このプロセスへの入力は、リーフノードに対応する分割パターン、および／または分割パターンごとの分割位置（エッジが任意の位置で分割されることが許可される場合）であってよい。

これにより、エッジが半分に分割されることのみが許可されている場合、デコーダは各リーフノードの分割パターンを復号し、復号された頂点を使用して各直方体について別々のTrisoupを作成し、またエッジが任意の位置で分割されることが許可されている場合、分割パターンおよび分割位置が各リーフノードに対して復号される。分割パターンおよび分割位置が与えられると、デコーダはそれによって三角形のスープのセットを作成する。

さらに、S1331において、例示的な実施形態によれば、S1304の固有のセグメントフラグの特徴に関して、固有のセグメントごとの分割フラグのストリームおよび／または頂点のストリームとして、1つまたは複数の固有のセグメントレベルでのシグナリングのプロセスへの入力が存在し得る。

これにより、固有のセグメントごとに、デコーダは分割フラグを復号してよく、分割フラグが1である場合、デコーダはこのとき、頂点のストリームから2つの頂点を復号してよく、またリーフノードに関して、分割セグメントと非分割セグメントのセットが決定されると、デコーダはリーフノードがそれに沿って分割される軸を導出してよい。次いで、デコーダは、そのノードに対して1つまたは2つのTrisoupを作成してもよく、またはTrisoupをまったく生成しない場合もある。

したがって、本明細書に記載の例示的な実施形態によって、上記で指摘した技術的問題は、これらの技術的解決策の1つまたは複数によって有利に改善され得る。

上述した技術は、コンピュータ可読命令を使用し、1つまたは複数のコンピュータ可読媒体に物理的に記憶されたコンピュータソフトウェアとして、または特別に構成された1つまたは複数のハードウェアプロセッサによって実施することができる。例えば、図14は、開示される主題の特定の実施形態を実施するのに適したコンピュータシステム1400を示している。

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

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはそのコンポーネント上で実行することができる。

コンピュータシステム1400について図14に示されるコンポーネントは、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関していかなる制限も示唆することは意図されていない。また、コンポーネントの構成は、コンピュータシステム1400の例示的な実施形態に示されているコンポーネントのいずれか1つ、またはそれらの組み合わせに関する何らかの依存性または要件を有するものとして解釈するべきではない。

コンピュータシステム1400は、特定のヒューマンインターフェース入力デバイスを含み得る。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（描かれていない）を通して、1人または複数の人間のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスは、音声（発話、音楽、環境音など）、画像（スキャンした画像、静止画像カメラから取得した写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）などの、人間による意識的な入力に必ずしも直接関係しない特定の媒体を取り込むのに使用することもできる。

入力ヒューマンインターフェースデバイスには、キーボード1401、マウス1402、トラックパッド1403、タッチスクリーン1410、ジョイスティック1405、マイク1406、スキャナー1408、カメラ1407のうちの1つまたは複数（各々の1つのみが描かれる）が含まれてよい。

コンピュータシステム1400はまた、特定のヒューマンインターフェース出力デバイスを含む場合もある。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚を通じて、1人または複数の人間のユーザの感覚を刺激し得る。そのようなヒューマンインターフェース出力デバイスには、触覚出力デバイス（例えば、タッチスクリーン1410、またはジョイスティック1405による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスが存在する可能性もある）、音声出力デバイス（スピーカー1409、ヘッドホン（描かれていない）など）、視覚的出力デバイス（CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含めるスクリーン1410であり、それぞれにタッチスクリーン入力機能を備えたものと、備えていないものがあり、それぞれに触覚フィードバック機能の備えたものと、備えていないものがあり、その一部は、ステレオグラフィック出力、仮想現実の眼鏡（描かれていない）、ホログラフィックディスプレイおよびスモークタンク（描かれていない）などの手段を介して二次元の視覚的出力、または三次元を超える出力を出力することが可能であり得る）、ならびにプリンタ（描かれていない）が含まれてよい。

コンピュータシステム1400はまた、人間がアクセス可能な記憶装置と、それらに関連付けられた媒体、例えば、CD／DVD1411または同様の媒体を備えたCD／DVD ROM／RW1420、サムドライブ1422、取り外し可能なハードドライブまたはソリッドステートドライブ1423、テープおよびフロッピーディスク（描かれていない）などのレガシー磁気媒体、セキュリティドングル（描かれていない）などの専用のROM／ASIC／PLDを基にしたデバイスを含めた光学媒体などを含むこともできる。

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

コンピュータシステム1400は、1つまたは複数の通信ネットワーク1498へのインターフェース1499も含むことができる。ネットワーク1498は、例えば、無線、有線、光であり得る。さらに、ネットワーク1498は、ローカル、広域、大都市圏、車両および産業、リアルタイム、遅延耐性などである場合がある。ネットワーク1498の例としては、イーサネットなどのローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルテレビ、衛星テレビおよび地上波放送を含むTV有線または無線広域デジタルネットワーク、CANBusなどを含む車両用および産業用などが含まれる。特定のネットワーク1498は一般に、特定の汎用目的のデータポートまたは周辺バス（1450および1451）（例えば、コンピュータシステム1400のUSBポートなど）に結合された外部のネットワークインターフェースアダプタを必要とし、その他のものは一般に、以下に説明するようにシステムバスへの結合によってコンピュータシステム1400のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。
これらのネットワーク1498のいずれかを使用して、コンピュータシステム1400は他のエンティティと通信することができる。そのような通信は、単方向の受信のみ（例えば、放送TV）、単方向送信のみ（例えば、CANbusから特定のCANbusデバイスへ）、または双方向、例えばローカルエリアまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。上記のように、特定のプロトコルおよびプロトコルスタックを、これらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。

前述のヒューマンインターフェースデバイス、人がアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム1400のコア1440に結合することができる。

コア1440には、1つまたは複数の中央処理装置（CPU）1441、グラフィックス処理装置（GPU）1442、グラフィックスアダプタ1417、フィールドプログラマブルゲート領域（FPGA）1443の形態の専用のプログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ1444などを含めることができる。これらのデバイスは、読み取り専用メモリ（ROM）1445、ランダムアクセスメモリ1446、ユーザがアクセスすることができない内部ハードドライブ、SSDなどの内部大容量記憶装置1447とともに、システムバス1448を介して接続されてよい。一部のコンピュータシステムでは、システムバス1448に、1つまたは複数の物理的プラグの形態でアクセスして、追加のCPU、GPUなどによる拡張を可能にすることもできる。周辺機器は、コアのシステムバス1448に直接、または周辺バス1451を介して結合することができる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。

CPU 1441、GPU 1442、FPGA 1443、およびアクセラレータ1444は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行することができる。そのコンピュータコードは、ROM 1445またはRAM 1446に記憶することができる。移行データもまたRAM 1446に記憶することができるが、永続的データは、例えば内部大容量記憶装置1447に記憶することができる。1つまたは複数のCPU 1441、GPU 1442、大容量記憶装置1447、ROM 1445、RAM 1446などと密接に関連付けることができるキャッシュメモリを使用することにより、メモリデバイスのいずれかへの高速記憶および高速取り出しを可能にすることできる。

コンピュータ可読媒体は、様々なコンピュータにより実施される動作を実行するためのコンピュータコードをそこに有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計され、構築されたものであり得るか、またはそれらはコンピュータソフトウェア技術の当業者に周知であり、当業者が利用可能な種類のものであり得る。

限定ではなく一例として、アーキテクチャ1400、特にコア1440を有するコンピュータシステムは、プロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）が、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行する結果として機能性を提供することができる。そのようなコンピュータ可読媒体は、上記で紹介したユーザがアクセス可能な大容量記憶装置、ならびにコア内部大容量記憶装置1447またはROM 1445などの非一時的な性質を持つ、コア1440の特定の記憶装置に関連付けられた媒体であり得る。本開示の様々な実施形態を実施するソフトウェアは、そのようなデバイスに格納され、コア1440によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリデバイスまたはメモリチップを含むことができる。ソフトウェアは、コア1440、および特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM 1446に格納されたデータ構造を定義すること、およびソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を修正することを含め、本明細書で説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、本明細書で説明した特定のプロセス、または特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアと一緒に動作することができる回路（例えばアクセラレータ1444）にハードワイヤードされた、または別の方法で組み込まれたロジックの結果として機能性を提供する場合もある。ソフトウェアへの言及はロジックを包含することができ、必要に応じてその逆も可能である。コンピュータ可読媒体への言及は、実行のためのソフトウェアを格納する回路（集積回路（IC）など）、実行のためのロジックを具体化する回路、または必要に応じてその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。

本開示をいくつかの例示的な実施形態を説明してきたが、変更、置換、および様々な代替の均等物が存在し、これらは、本開示の範囲内にある。したがって、当業者は、本明細書では明示的に示されていない、または記載されていないが、本開示の原理を具現化し、したがってその精神および範囲内にある多数のシステムおよび方法を考案することが可能であることが理解されよう。

100 通信システム
101 端末
102 端末
103 端末
104 端末
105 ネットワーク
201 ビデオソース
202 エンコーダ
203 キャプチャサブシステム
204 ビデオビットストリーム
205 ストリーミングサーバ
206 ビデオビットストリーム
208 コピー／ビデオビットストリーム
209 ディスプレイ
210 発信ビデオサンプルストリーム
211 ビデオデコーダ
212 クライアント
213 サンプルストリーム
300 デコーダ
301 チャネル
302 受信器
303 バッファメモリ
304 パーサー
305 スケーラ／逆変換ユニット
306 動作補償予測ユニット
307 イントラピクチャ予測ユニット
308 参照ピクチャバッファ
309 現在のピクチャ
310 アグリゲータ
311 ループフィルタユニット
312 ディスプレイ
313 シンボル
400 エンコーダ
401 ビデオソース
402 コントローラ
403 ビデオコーダ／ソースコーダ
404 予測器
405 参照ピクチャメモリ
406 ローカルビデオデコーダ
407 符号化エンジン
408 エントロピーコーダ
409 送信器
410 符号化されたビデオシーケンス
411 通信チャネル
601 セグメントA
602 セグメントB
603 セグメントC
604 セグメントD
605 セグメントE
606 セグメントF
610 第1の参照階層（参照ライン）
609 第2の参照階層（参照ライン）
608 第3の参照階層（参照ライン）
607 第4の参照階層（参照ライン）
611 ブロックユニット
900 イントラ予測モード
1202 エッジ
1203 頂点
1400 コンピュータシステム
1401 キーボード
1402 マウス
1403 トラックパッド
1405 ジョイスティック
1406 マイク
1407 カメラ
1408 スキャナー
1409 スピーカー
1410 タッチスクリーン
1417 グラフィックアダプタ
1422 サムドライブ
1423 ソリッドステートドライブ
1440 コア
1443 フィールドプログラマブルゲート領域（FPGA）
1444 特定のタスク用のハードウェアアクセラレータ
1445 ROM
1446 ランダムアクセスメモリ
1447 内部大容量記憶装置
1448 システムバス
1451 周辺バス
1498 ネットワーク
1499 インターフェース

Claims (11)

1. 少なくとも1つのプロセッサによって実行されるビデオ符号化のための方法であって、
   ジオメトリを基にしたポイントクラウド圧縮（G-PCC）データのリーフノードを取得するステップと、
   前記リーフノードを複数の直方体に分割するステップと、
   前記直方体の各々について別々の三角形スープを導出するステップと、
   前記直方体の各々のエッジの各々についてフラグをそれぞれ符号化するステップとを含み、
   前記フラグが、前記別々の三角形スープの頂点が前記エッジのうちのエッジに存在するかどうかを示す、方法。
2. 前記リーフノードの分割パターンのシグナリングを2ビットでエントロピー符号化するステップをさらに含み、
   前記2ビットは、前記リーフノードがx軸、y軸、およびz軸のうちの1つに沿って前記直方体に半分に分割されるかどうかを示す、請求項1に記載の方法。
3. 前記リーフノードが半分でない任意の位置で分割される場合、前記x軸および前記y軸の少なくとも一方に沿った前記位置が、前記直方体の各々についてシグナリングされる、請求項2に記載の方法。
4. 前記G-PCCデータの複数のリーフノードのうちの前記リーフノードにおいて前記三角形スープを再帰的に導出するステップをさらに含む、請求項1から3のいずれか一項に記載の方法。
5. 前記リーフノードの分割パターンのシグナリングを3ビットでエントロピー符号化するステップをさらに含み、
   前記3ビットは、前記リーフノードがx軸、y軸、z軸、前記x軸と前記y軸の組み合わせ、前記x軸と前記z軸の組み合わせ、前記y軸と前記z軸の組み合わせ、ならびに前記x軸、前記y軸、および前記z軸の組み合わせのうちの1つに沿って前記直方体に半分に分割されるかどうかを示す、請求項4に記載の方法。
6. 前記リーフノードが半分でない任意の位置で分割される場合、前記x軸、前記y軸、および前記z軸のうちの少なくとも1つに沿った前記位置が、前記直方体の各々についてシグナリングされる、請求項5に記載の方法。
7. レート歪み最適化（RDO）方式に従って分割パターンを判定するステップをさらに含む、請求項1から6のいずれか一項に記載の方法。
8. 前記リーフノードを前記複数の直方体に分割するステップは、前記リーフノードを半分に分割するステップを含む、請求項1から7のいずれか一項に記載の方法。
9. 前記リーフノードを前記複数の直方体に分割するステップは、前記リーフノードを等しくないサイズの部分に分割するステップを含む、請求項1から7のいずれか一項に記載の方法。
10. 請求項1から8のいずれか一項に記載の方法を実行するように構成された装置。
11. コンピュータに、請求項1から8のいずれか一項に記載の方法を実行させるためのプログラム。

Images