JP7130853B2 - ポイントクラウド符号化における改善された属性サポート - Google Patents

Description

本開示は、一般的に、ビデオ符号化に関する。そして、特定的には、ポイントクラウド符号化（point cloud coding、PCC）ビデオフレームのためのビデオ属性の符号化に関する。

関連出願の相互参照
本特許出願は、2018年9月14日に出願された、Ye-Kui Wangら著、タイトルが「High-Level Syntax Designs for Point Cloud Coding」である、米国仮特許出願第62/731,693号について優先権の利益を主張するものであり、当該出願は、参照によりここにおいて組み込まれている

比較的に短いビデオでさえ描写するために必要とされるビデオデータの量は、相当な量であり、それは、データがストリーム化されるか、または、そうでなければ、制限された帯域幅容量を用いて通信ネットワークにわたり通信される場合には、結果として困難を生じ得る。従って、ビデオデータは、一般的に、現代の電気通信ネットワークにわたり通信される前に圧縮されている。ビデオがストレージ装置に保管される場合には、ビデオのサイズも、また、問題となり得る。メモリリソースが制限され得るからである。ビデオ圧縮装置は、しばしば、送信またはストレージの前にビデオデータを符号化（code）するために、ソースにおいてソフトウェア及び／又はハードウェアを使用し、それによって、デジタルビデオ画像を表現するために必要とされるデータ量を減少させている。圧縮されたデータは、次いで、ビデオデータを復号化（decode）するビデオ解凍装置によって宛先において受信される。ネットワークリソースが制限されており、かつ、より高いビデオ品質の要求がこれまで増加しているため、画像品質をほとんど犠牲にすることなく、圧縮比を改善する改良された圧縮（compression）および解凍（decompression）技術が望まれている。

一つの実施形態において、本開示は、ビデオデコーダによって実装される方法を含む。本方法は、受信器によって、複数のポイントクラウド符号化（PCC）フレームの符号化シーケンスを含むビットストリームを受信するステップを含み、ここで、前記複数のPCCフレームの符号化シーケンスは、ジオメトリ、テクスチャ、および、反射率、透明性、法線のうち１つ以上、を含む、複数のPCC属性を表しており、かつ、ここで、各符号化PCCフレームは、１つ以上のPCCネットワーク抽象化レイヤ（NAL）ユニットによって表される。本方法は、さらに、プロセッサによって、前記ビットストリームを解析するステップを含み、前記PCC NALユニットそれぞれが、前記PCC属性のうち対応する１つに属するか否か、および、前記PCC NALユニットが対応する前記PCC属性に属する場合に、どのPCC属性に前記PCC NALユニットが属しているかを示す指示を、前記PCC NALユニットそれぞれについて獲得する。本方法は、さらに、前記プロセッサによって、前記指示に基づいて、前記ビットストリームを復号化するステップを含む。いくつかのビデオ符号化システムにおいて、PCCビデオストリームは、ジオメトリ属性およびテクスチャ属性を含む。本実施形態は、反射率、透明性、および垂直を任意の属性として追加する。さらに、本実施形態は、属性の数を示し、かつ、実際にビットストリームに含まれる属性を示すデータを導入し、デコーダがPCCビデオストリームを復号化する方法を決定することを可能にする。追加のPCC属性を加えることによって、エンコーダは、より複雑なPCCフレームを記述することができ、そして、デコーダは、より複雑なPCCフレームを読み出すことができ、そして、従って、表示することができる。さらに、追加の属性を加えることは、他の属性を単純化し得る。従って、処理リソースの使用が低減され、かつ、符号化効率が増加され得る。符号化効率の向上は、エンコーダとデコーダとの間でビットストリームを送信する間に、メモリの使用、並びに、ネットワークリソースの使用を低減する。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、PCCフレームの各符号化シーケンスは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットと関連付けられており、ここで、前記シーケンスレベルデータユニットは、前記PCCフレームの符号化シーケンスにおいて搬送される多数のPCC属性を示す第１シンタックス要素、および、前記PCC属性それぞれを示す第２シンタックス要素を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記第２シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素である。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記第１シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素である。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれについて多数のストリームを示す第３シンタックス要素を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれに対するPCCネットワーク抽象化レイヤユニットが、対応するPCCアクセスユニットの中にストリーム順序で含まれていること、を示すために設定された属性第１順序付けフラグ（attribute first ordering flag）を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれに対するPCCネットワーク抽象化レイヤユニットが、対応するPCCアクセスユニットの中に属性順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む＼＼。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記PCCアクセスユニットそれぞれは、前記PCC属性それぞれについてゼロから４つの属性ストリームを含み、かつ、ここで、前記属性ストリームの少なくとも１つは、非定数フレームレートを含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、さらに、前記プロセッサによって、前記ビットストリームからのPCCフレームの復号化シーケンスを、提示のためにディスプレイへ向けて転送するステップを含む。

一つの実施形態において、本開示は、ビデオエンコーダによって実装される方法を含む。本方法は、プロセッサによって、PCCフレームのシーケンスをビットストリームへと符号化するステップを含み、ここで、前記PCCフレームのシーケンスは、ジオメトリ、テクスチャ、および、反射率、透明性、法線のうち１つ以上、を含む、複数のPCC属性を表しており、かつ、ここで、各PCCフレームは、多数のPCC NALユニット内で符号化される。本方法は、さらに、前記プロセッサによって、前記PCC NALユニットそれぞれについて指示を符号化するステップを含み、指示は、前記PCC NALユニットそれぞれが、前記PCC属性のうち対応する１つに属するか否か、および、前記PCC NALユニットが対応する前記PCC属性に属する場合に、どのPCC属性に前記PCC NALユニットが属しているかを示す。本方法は、さらに、送信器によって、前記ビットストリームをビデオデコーダへ向けて送信するステップを含む。いくつかのビデオ符号化システムにおいて、PCCビデオストリームは、ジオメトリ属性およびテクスチャ属性を含む。本実施形態は、反射率、透明性、および垂直を任意の属性として追加する。さらに、本実施形態は、属性の数を示し、かつ、実際にビットストリームに含まれる属性を示すデータを導入し、デコーダがPCCビデオストリームを復号化する方法を決定することを可能にする。追加のPCC属性を加えることによって、エンコーダは、より複雑なPCCフレームを記述することができ、そして、デコーダは、より複雑なPCCフレームを読み出すことができ、そして、従って、表示することができる。さらに、追加の属性を加えることは、他の属性を単純化し得る。従って、処理リソースの使用が低減され、かつ、符号化効率が増加され得る。符号化効率の向上は、エンコーダとデコーダとの間でビットストリームを送信する間に、メモリの使用、並びに、ネットワークリソースの使用を低減する。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリームは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットと関連付けられており、ここで、前記シーケンスレベルデータユニットは、前記ビットストリームにおいて搬送される多数のPCC属性を示す第１シンタックス要素、および、前記PCC属性それぞれを示す第２シンタックス要素を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記第２シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素である。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記第１シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素である。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれについて多数のストリームを示す第３シンタックス要素を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれに対するPCCネットワーク抽象化レイヤユニットが、対応するPCCアクセスユニットの中にストリーム順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記ビットストリーム内のフレームグループヘッダは、前記PCC属性それぞれに対するPCCネットワーク抽象化レイヤユニットが、対応するPCCアクセスユニットの中に属性順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記PCCアクセスユニットそれぞれは、前記PCC属性それぞれについてゼロから４つの属性ストリームを含み、かつ、ここで、前記属性ストリームの少なくとも１つは、非定数フレームレートを含む。

一つの実施形態において、本開示は、ビデオ符号化装置を含む。ビデオ符号化装置は、プロセッサと、前記プロセッサに結合された受信器と、前記プロセッサに結合された送信器と、を含み、そして、前記プロセッサ、受信器、および送信器は、前述の態様のいずれかの方法を実行するように構成されている。

一つの実施形態において、本開示は、ビデオ符号化装置によって使用されるコンピュータプログラム製品を含む、非一時的なコンピュータで読取り可能な媒体を含む。前記コンピュータプログラム製品は、前記非一時的なコンピュータで読取り可能な媒体に保管されたコンピュータ実行可能命令を含み、そうして、プロセッサによって実行されるとき、前記ビデオ符号化装置に、前述の態様のいずれかの方法を実行するようにさせる。

一つの実施形態において、本開示は、エンコーダを含む。エンコーダは、PCCフレームのシーケンスをビットストリームへと符号化するためのフレーム符号化手段を含み、ここで、前記PCCフレームのシーケンスは、ジオメトリ、テクスチャ、および、反射率、透明性、法線のうち１つ以上、を含む、複数のPCC属性を表しており、かつ、ここで、各PCCフレームは、多数のPCC NALユニットにおいて符号化される。本エンコーダは、さらに、前記PCC NALユニットそれぞれについて指示を符号化するためのパラメータ符号化手段を含み、指示は、前記PCC NALユニットそれぞれが、前記PCC属性のうち対応する１つに属するか否か、および、前記PCC NALユニットが対応する前記PCC属性に属する場合に、どのPCC属性に前記PCC NALユニットが属しているかを示す。本エンコーダは、さらに、前記ビットストリームをビデオデコーダへ向けて送信するための、送信手段を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記エンコーダは、さらに、前述の態様のいずれかの方法を実行するように構成されている。

一つの実施形態において、本開示は、デコーダを含む。デコーダは、複数のPCCフレームの符号化シーケンスを含むビットストリームを受信するための受信手段を含み、ここで、前記複数のPCCフレームの符号化シーケンスは、ジオメトリ、テクスチャ、および、反射率、透明性、法線のうち１つ以上、を含む、複数のPCC属性を表しており、かつ、ここで、各符号化PCCフレームは、１つ以上のPCC NALユニットによって表される。本デコーダは、さらに、前記PCC NALユニットそれぞれに対する指示を獲得するように、前記ビットストリームを解析するための解析手段を含む。指示は、前記PCC NALユニットそれぞれが、前記PCC属性のうち対応する１つに属するか否か、および、前記PCC NALユニットが対応する前記PCC属性に属する場合に、どのPCC属性に前記PCC NALユニットが属しているかを示す。本デコーダは、さらに、前記指示に基づいて、前記ビットストリームを復号化するための符号化手段を含む。

任意的に、前述の態様のいずれかにおいて、態様の別の実装が提供され、ここで、前記デコーダは、さらに、前述の態様のいずれかの方法を実行するように構成されている。

明確化の目的のために、前述の実施形態のうち任意の１つは、他の前述の実施形態のいずれか１つ以上と組み合わされて、本開示の範囲内にある新たな実施形態を作り出すことができる。

これら及び他の特徴は、添付の図面および請求項と合わせて行われる以下の詳細な説明から、より明確に理解されるだろう。

本開示をより完全に理解するために、添付の図面および詳細な説明に関連して行われる、以下の簡単な説明を参照する。ここで、同様の参照番号は同様の部分を表している。
図1は、ビデオ信号を符号化する一つの例示的な方法に係るフローチャートである。 図2は、ビデオ符号化のための一つの例示的な符号化および復号化（コーデック）システムに係る概略図である。 図3は、一つの例示的なビデオエンコーダを説明する概略図である。 図4は、一つの例示的なビデオデコーダを説明する概略図である。 図5は、PCCメカニズムに従って符号化することができるポイントクラウド媒体の一つの例である。 図6は、ポイントクラウド媒体フレームのデータ分割およびパッキングの一つの例である。 図7は、拡張属性セットを有する一つの例示的なPCCビデオストリームを説明する概略図である。 図8は、ストリームによってPCC属性を順序付けるメカニズムを説明する概略図である。 図9は、属性によってPCC属性を順序付けるメカニズムを説明する概略図である。 図10は、拡張属性セットを用いてPCCビデオシーケンスを符号化する一つの例示的な方法に係るフローチャートである。 図11は、拡張属性セットを用いてPCCビデオシーケンスを復号化する一つの例示的な方法に係るフローチャートである。 図12は、一つの例示的なビデオ符号化装置に係る概略図である。 図13は、拡張属性セットを用いてPCCビデオシーケンスを符号化するための一つの例示的なシステムに係る概略図である。 図14は、拡張属性セットを用いてPCCビデオシーケンスを符号化するための一つの別の例示的な方法に係るフローチャートである。 図15は、拡張属性セットを用いてPCCビデオシーケンスを復号化するための一つの例示的な方法である。

１つ以上の実施形態の例示的な実施が以下に提供されるが、開示されるシステム及び／又は方法は、現在公知であるか存在するかを問わず、任意の数の技術を使用して実施され得ることが、最初に理解されるべきである。本開示は、ここにおいて説明され、かつ、記載される例示的な設計および実装を含む、以下に示される例示的な実装、図面、および技術に限定されるべきではないが、添付の請求項の範囲内で、それらの均等物の全範囲と共に修正され得る。

多くのビデオ圧縮技術が、最小限のデータ損失を伴いビデオファイルのサイズを低減するために使用され得る。例えば、ビデオ圧縮技術は、ビデオシーケンスにおけるデータ冗長性を低減または除去するために、空間的（例えば、画像内（intra-picture））予測、及び／又は、時間的（例えば、画像間（inter-picture））予測を実行することを含み得る。ブロックベースのビデオ符号化のために、ビデオスライス（例えば、ビデオピクチャまたはビデオピクチャの一部）は、ビデオブロックへと分割され得る。これは、また、ツリーブロック、コーディングツリーブロック（CTB）、コーディングツリーユニット（CTU）、符号化ユニット（CU）、及び／又は、符号化ノードとしても参照され得る。画像のイントラ符号化（I）スライスにおけるビデオブロックは、同じ画像内の隣接ブロックにおける参照サンプルに関して空間的予測を使用して符号化される。ピクチャのインター符号化（PまたはB）スライスにおけるビデオブロックは、同じ画像内の隣接ブロックにおける参照サンプルに関して空間的予測を使用することによって、または、他の参照画像における参照サンプルに関して時間的予測を使用することによって、符号化することができる。画像はフレームとして参照され、そして、参照画像は参照フレームとして参照され得る。空間的または時間的予測は、画像ブロックを表す予測ブロックを結果として生じる。残差データ（residual data）は、元の画像ブロックと予測ブロックとの間のピクセル差（pixel difference）を表す。従って、インター符号化ブロックは、予測ブロック、および、符号化ブロックと予測ブロックとの間の差を示す残差データを形成する参照サンプルのブロックを指し示す動きベクトル（motion vector）に従って符号化される。イントラ符号化ブロックは、イントラ符号化モードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、ピクセルドメインから変換ドメインへ変換され得る。これらは、残差変換係数（residual transform coefficient）を結果として生じ、これは量子化され得る。量子化された変換係数は、最初に２次元アレイに配置され得る。量子化された変換係数は、変換係数の１次元ベクトルを生成するためにスキャンされ得る。エントロピー符号化が、より多くの圧縮を達成するために適用され得る。そうしたビデオ圧縮技術が、以下により詳細に説明される。

符号化されたビデオが正確に復号化されることを確実にするために、ビデオは、対応するビデオ符号化標準に従って符号化され、そして、復号化される。ビデオ符号化規格は、国際電気通信連合（ITU）標準化部門（ITU-T）H.261、国際標準化機構／国際電気標準委員会（ISO/IEC）動画専門家委員会（MPEG）-1 Part2、ITU-T H.262またはISO/IEC MPEG-2 Part2、ITU-T H.263、ISO/IEC MPEG-4 Part2、ITU-T H.264またはISO/IEC MPEG-4 Part10としても呼ばれる高度ビデオ符号化（AVC）、および、ITU-T H.265またはMPEG-H Part2としても呼ばれる高効率ビデオ符号化（HEVC）、を含んでいる。AVCは、スケーラブルビデオ符号化（SVC）、マルチビュービデオ符号化（MVC）とマルチビュービデオ符号化プラス深さ（MVC+D）、および３次元（3D）AVC（3D‐AVC）といった拡張を含んでいる。HEVCは、スケーラブルHEVC（SHVC）、マルチビューHEVC（MV-HEVC）、３次元HEVC（3D-HEVC）といった、拡張を含んでいる。ITU-TとISO/IECの合同動画専門家委員会（JVET）は、Versatile Video Coding（VVC）と呼ばれるビデオ符号化規格の開発を始めた。VVCは、JVET-K1001-v4およびJVET-K1002-v1を含むWorking Draft（WD）に含まれている。

PCCは、3Dオブジェクトのビデオを符号化（encoding）するためのメカニズムである。ポイントクラウドは、3Dスペースにおけるデータポイントのセットである。そうしたデータポイントは、例えば、空間における位置および色を決定するパラメータを含んでいる。ポイントクラウドは、リアルタイム3Dイマーシブテレプレゼンス（immersive telepresence）、インタラクティブパララックスによるコンテンツバーチャルリアリティ（VR）ビューイング、3Dフリービューポイントスポーツリレー放送、地理情報システム、文化遺産、大規模な3Dダイナミックマップに基づく自律ナビゲーション、および自動車アプリケーションといった、様々なアプリケーションにおいて使用され得る。PCCのためのISO/IEC MPEGコーデックは、実質的な符号化効率およびネットワーク環境に対する堅牢性（robustness）を伴い可逆（lossless）及び／又は不可逆（lossy）な圧縮ポイントクラウドデータ上で動作し得る。このコーデックの使用により、ポイントクラウドが、コンピュータデータの形式として操作され、種々の記憶媒体において保管され、ネットワークにわたり送受信され、そして、放送チャネル上で配信され得る。PCCコーディング環境は、PCCカテゴリ1、PCCカテゴリ2、PCCカテゴリ3に分類される。本開示は、MPEG出力文書N17534およびN17533に関連する、PCCカテゴリ2に向けられている。PCCカテゴリ2コーデックの設計は、異なるビデオシーケンスのセットとしてポイントクラウドデータを圧縮することによって、ダイナミックポイントクラウドのジオメトリ（geometry）およびテクスチャ情報を圧縮するために、他のビデオコーデックを利用しようと図る。例えば、一方はポイントクラウドデータのジオメトリ情報を表し、かつ、他方はテクスチャ情報を表している、２つのビデオシーケンスは、１つ以上のビデオコーデックを使用することによって生成され、かつ、圧縮され得る。ビデオシーケンスの解釈をサポートするための追加のメタデータ（例えば、占有マップおよび補助パッチ情報）も、また、別々に生成され、かつ、圧縮され得る。

PCCシステムは、位置データを含むジオメトリPCC属性、および、カラーデータを含むテクスチャPCC属性をサポートし得る。しかしながら、いくつかのビデオアプリケーションは、反射率、透明性（transparency）、および法線ベクトル（normal vector）といった、他のタイプのデータを含み得る。さらに、PCCシステムは、ビットストリーム内のPCCビデオデータを符号化し、そして、ビットストリームの中の属性ストリーム内で属性データを分離し得る。２つの属性のみがサポートされるので、PCCシステムは、２つのジオメトリストリームおよび単一のテクスチャストリームに制限され得る。しかしながら、特に拡張属性セットが利用可能な場合には、より大きな柔軟性が望ましいことがある。加えて、PCCシステムは、PCCアクセスユニット（AU）内のデータを符号化する。PCC AUは、単一のPCCフレームを再構成するために十分なデータを含んでいる。PCCシステムは、ストリームによりPCCの中でデータユニットを順序付け（ordering）することに制限され得る。具体的に、PCCシステムは、第１ジオメトリストリームのためのデータユニット、次いで、第２ジオメトリストリームのためのデータユニット、そして、次いで、テクスチャストリームのためのデータユニットの符号化（coding）に制限され得る。しかしながら、所定のユースケースにおけるビデオ符号化の最適化をサポートするために、より柔軟な順序付けスキームが望ましいことがある。また、PCCシステムは、各PCC AUにおける各PCC属性ストリームについてデータユニットが存在することを必要とし得る。従って、PCCビットストリームが一定のフレームレートで設定される場合には、各属性ストリームのフレームレートも、また、一定であろう。このことは、いくつかのインスタンス、例えば、拡張属性セットを使用する場合には、望ましくないことがある。本開示は、そうしたPCCシステムに伴うこれら及び他の問題を取り扱う。

ここに開示されているのは、PCCを改善するためのメカニズムである。一つの実施形態においては、より堅牢なPCC機能を可能にするために、属性の拡張セット（expanded set）を利用可能にする。PCC属性の拡張セットは、ジオメトリおよびテクスチャを含んでいる。PCC属性の拡張セットは、また、反射率、透明性、および法線ベクトル（ここにおいては、法線としても参照される）も含んでいる。反射率属性は、第１データポイントから、第１データポイントの近傍で隣接するデータポイント上に投影される光（例えば、テクスチャ属性に基づくカラー光）の量を示している。透明性属性は、（例えば、第１データポイントの近傍で隣接するデータポイントから反射されて）第１データポイントを通過できる光の量を示している。法線属性は、（例えば、ジオメトリ属性に基づいて）対応するデータポイントによって作成された表面に対して垂直なベクトルを示している。反射率、透明性、および法線属性は、PCC AU内のデータポイントの一部または全部を記述するデータを含み得る。さらに、反射率、透明性、および法線属性は任意的であり、そして、従って、いくつかのPCC AUについては個別に又は組み合わせて発生し得るが、同じビットストリーム内の他のPCC AUについてはそうではない。本開示は、さらに、拡張属性セットの符号化をサポートするための属性タイプおよび関連情報のシグナリング（signaling）のためのメカニズムを含んでいる。別の実施形態において、本開示は、フレキシブルな数の属性ストリームをサポートするためのメカニズムを含んでいる。例えば、各属性は、ゼロから４つのストリームを含むことができ、これにより、符号化されるPCCフレームに依存して、属性の複雑な使用、または、そうした属性の完全な省略を可能にする。具体的な例として、多数の光沢のあるオブジェクト（shiny object）を含むPCCビデオストリームは、異なるオブジェクトに対する異なる専用ストリーム、偶数フレームおよび奇数フレームに対する異なるストリーム、といった、多くの反射ストリームを含み得る。さらに、マットなオブジェクト（matte object）だけを含んでいるPCCビデオストリームは、反射ストリームを省略することができる。別の実施形態においては、PCC属性のためのフレキシブルな順序付けスキームが開示される。具体的には、属性がストリームにより順序付けられてよく、そうして、各利用可能な属性の第１ストリームが最初に含まれ、次いで、各属性の第２ストリームが含まれる、等。属性は、また、属性の順序で順序付けられてよく、そうして、第１属性の全てのストリームが、次に、第２属性の全てのストリームに含まれる、等。異なる順序が、異なるユースケースにおいては、より最適であり得る。使用する順序は、順序付けフラグにより指定され得る。上記の実施形態は、単独で、または、組み合わせて使用され得る。加えて、拡張された属性のセットは、任意的な属性を含んでいる。かくして、各AU内の各PCC属性ストリームについてデータユニットが存在しないことがある。その結果、たとえPCCビットストリーム全体が一定のフレームレートであっても、根底にある（underlying）PCC属性ストリームは、場合によっては、一定のフレームレートを含まなくてよい。さらに、そうした実施形態の使用を記述するシンタックス（syntax）構文は、ビットストリーム内のシーケンスレベルデータ、例えば、各対応するPCC AU内に配置されたフレーム・ネットワーク抽象化レイヤ（NAL）ユニットのグループに含まれ得る。これら及び他の実施例が、以下で詳細に説明される。

図1は、ビデオ信号を符号化する一つの例示的な動作方法100のフローチャートである。具体的に、ビデオ信号は、エンコーダで符号化される。符号化プロセスは、ビデオファイルサイズを低減するための種々のメカニズムを使用することによってビデオ信号を圧縮する。より小さいファイルサイズにより、圧縮されたビデオファイルがユーザへ向けて送信されることを可能にし、一方で、関連する帯域幅オーバーヘッドを低減している。デコーダは、次いで、圧縮されたビデオファイルを復号化（decode）して、エンドユーザに表示するために元のビデオ信号を再構成する。復号化プロセスは、一般的に、符号化プロセスをミラー（mirror）しており、デコーダが一貫性をもってビデオ信号を再構成するのを可能にする。

ステップ101においては、ビデオ信号がエンコーダへと入力される。例えば、ビデオ信号は、メモリ内に保管されている非圧縮ビデオファイルであってよい。別の例として、ビデオファイルは、ビデオカメラといった、ビデオキャプチャ装置によってキャプチャされてよく、そして、ビデオのライブストリーミングをサポートするために符号化されてよい。ビデオファイルは、オーディオコンポーネントおよびビデオコンポーネントの両方を含み得る。ビデオコンポーネントは、シーケンスで視聴される（viewed）ときに、視覚的な動きの印象を与える一連の画像フレームを含んでいる。フレームは、ここにおいてルマ（luma）コンポーネント（または、ルマサンプル）として参照される、光（light）、および、クロマ（chroma）コンポーネント（または、カラーサンプル）として参照される、カラーの観点で表現されるピクセルを含んでいる。いくつかの例において、フレームは、また、３次元ビューイング（viewing）をサポートするための深度値（depth value）も含み得る。

ステップ103において、ビデオはブロックへと分割される。分割は、圧縮のために、各フレーム内のピクセルを正方形及び／又は長方形のブロックへと細分化することを含む。例えば、High Efficiency Video Coding（HEVC）（H.265およびMPEG-H Part2としても知られている）において、フレームは、最初に、既定のサイズ（例えば、64ピクセル×64ピクセル）のブロックである、コーディングツリーユニット（CTU）へと分割され得る。CTUは、ルマサンプルおよびクロマサンプルの両方を含んでいる。コーディングツリーは、CTUをブロックへと分割し、そして、次いで、さらなる符号化をサポートするコンフィグレーションが達成されるまで、ブロックを再帰的に細分化するために使用され得る。例えば、フレームのルマコンポーネントは、個々のブロックが比較的に均一な照明値（lighting value）を含むまで細分化され得る。さらに、フレームのクロマコンポーネントは、個々のブロックが比較的に均一な色値（color value）を含むまで細分化することができる。従って、分割メカニズムは、ビデオフレームの内容に依存して変化する。

ステップ105においては、ステップ103で分割された画像ブロックを圧縮するために、様々な圧縮メカニズムが使用される。例えば、インター予測及び／又はイントラ予測が使用され得る。インター予測は、共通のシーン内のオブジェクトは連続したフレームに現れる傾向があるという事実を利用するように設計されている。従って、参照フレーム内のオブジェクトを描くブロックは、隣接するフレームにおいて繰り返し記述される必要はない。具体的には、テーブルといった、オブジェクトは、複数のフレームにわたり一定の位置に留まることができる。従って、テーブルは、一度記述され、そして、隣接するフレームは参照フレームに戻って参照することができる。パターン・マッチング・メカニズムを使用して、複数フレームにわたりオブジェクトをマッチングすることができる。さらに、移動しているオブジェクトは、例えば、オブジェクトの移動またはカメラの移動のせいで、複数のフレームにわたり表現され得る。特定の例として、ビデオは、複数のフレームにわたりスクリーンを横切って移動する自動車を表示することができる。そうした動きを記述するために、動きベクトルが使用され得る。動きベクトルは、フレーム内のオブジェクトの座標から参照フレーム内のオブジェクトの座標へのオフセットを提供する２次元ベクトルである。かくして、インター予測は、参照フレーム内の対応するブロックからのオフセットを示している動きベクトルのセットとして、現在フレーム内の画像ブロックを符号化することができる。

イントラ予測は、共通フレーム内のブロックを符号化する。イントラ予測は、ルナコンポーネントおよびクロマコンポーネントがフレーム内に密集する傾向があるという事実を利用する。たとえば、樹木の一部分における緑色のパッチは、同様な緑色のパッチに隣接して位置する傾向がある。イントラ予測は、多数の方向予測モード（例えば、HEVCにおいては33）、平面モード（planar mode）、および直流（direct current、DC）モードを使用する。方向モードは、現在ブロックが、対応する方向における隣接ブロックのサンプルと類似／同一であることを示す。平面モードは、行（row）／列（column）に沿った一連のブロック（例えば、平面）が、行のエッジにおける隣接ブロックに基づいて補間され得ることを示す。平面モードは、事実上、値の変化において比較的に一定の傾きを使用することによって、行／列を横切る光／色の滑らかな移行（transition）を示す。DCモードは、境界平滑化のために使用され、そして、ブロックが、方向予測モードの角度方向と関連する全ての隣接ブロックのサンプルに関連する平均値と類似／同一であることを示す。従って、イントラ予測ブロックは、実際の値の代わりに、様々な関係のある予測モード値として画像ブロックを表現することができる。さらに、インター予測ブロックは、実際の値の代わりに、動きベクトル値として画像ブロックを表現することができる。いずれの場合も、予測ブロックは、場合によっては、画像ブロックを正確に表現しないことがある。あらゆる差異は、残差ブロック内に保管される。変換が、ファイルをさらに圧縮するために、残差ブロックに対して適用され得る。

ステップ107においては、種々のフィルタリング技術が適用され得る。HEVCにおいて、フィルタは、ループ内（in-loop）フィルタリングスキームに従って適用される。上述のブロックベースの予測は、デコーダにおいてブロック状（blocky）画像の生成を結果として生じ得る。さらに、ブロックベースの予測スキームは、ブロックを符号化し、そして、次いで、後で参照ブロックとして使用するために、符号化されたブロックを再構成し得る。ループ内フィルタリングスキームは、ノイズ抑制フィルタ、ブロック解除（de-blocking）フィルタ、適応ループフィルタ、および、サンプル適応オフセット（SAO）フィルタを、ブロック／フレームに対して反復的に適用する。これらのフィルタは、符号化されたファイルが正確に再構成され得るように、そうしたブロッキングアーチファクトを軽減する。さらに、これらのフィルタは、再構成された参照ブロックにおけるアーチファクトを軽減し、そうして、アーチファクトは、再構成された参照ブロックに基づいて符号化される後続ブロックにおいて追加のアーチファクトを生成する可能性が低くなる。

一旦、ビデオ信号が分割され、圧縮され、そして、フィルタリングされると、結果として生じるデータは、ステップ109において、ビットストリームに符号化される。ビットストリームは、上述のデータ、並びに、デコーダにおける適切なビデオ信号再構成をサポートするのに望ましい任意の信号データ（signaling data）を含んでいる。例えば、そうしたデータは、分割データ、予測データ、残差ブロック、および、デコーダに対して符号化命令を提供する種々のフラグ、を含み得る。ビットストリームは、要求に応じて、デコーダへ向けて送信するために、メモリ内に保管され得る。ビットストリームは、また、複数のデコーダへ向けてブロードキャスト及び／又はマルチキャストされてもよい。ビットストリームの生成は反復プロセスである。従って、ステップ101、103、105、107、および109は、多くのフレームおよびブロックにわたり、連続的に、かつ／あるいは、同時に発生し得る。図1に示された順序は、議論の明確さ及び容易さのために示されており、そして、ビデオ符号化プロセスを特定の順序に限定するように意図されたものではない。

デコーダは、ビットストリームを受信し、そして、ステップ111において、復号化処理（decoding process）を開始する。具体的に、デコーダは、ビットストリームを対応するシンタックスおよびビデオデータへと変換するためのエントロピー復号化スキームを使用する。デコーダは、ビットストリームからのシンタックスデータを使用して、ステップ111において、フレームに対する分割を決定する。パーティション分割（partitioning）は、ステップ103におけるブロックのパーティション分割の結果と一致すべきである。ステップ111で使用されるエントロピー符号化／復号化が、これから説明される。エンコーダは、圧縮プロセスの最中に多くの選択を行う。入力画像における値の空間的位置決めに基づいて、いくつかの可能な選択からブロックのパーティション分割スキームを選択すること、といったものである。正確な選択のシグナリングは、多数のビン（bins）を使用し得る。ここにおいて使用される際に、ビンは、変数として扱われるバイナリ値（例えば、コンテキストに応じて変化し得るビット値）である。エントロピー符号化により、エンコーダは、許容可能なオプションのセットを残して、特定の場合に明らかに実行可能ではない任意のオプションを捨てることができる。各許容可能なオプションには、次いで、コードワードが割り当てられる。コードワードの長さは、許容可能なオプションの数に基づいており（例えば、２つのオプションに対して１つのビン、３つから４つのオプションに対して２つのビン、等）、エンコーダは、次いで、選択されたオプションについてコードワードを符号化する。このスキームは、許容可能なオプションの小さなサブセットからの選択を一意に示すために望まれるほどコードワードが大きいので、コードワードのサイズを低減する。これは、全ての可能なオプションの潜在的に大きなセットからの選択を一意に示すのとは対照的である。デコーダは、次いで、エンコーダに対するものと同様な方法で許容可能なオプションのセットを決定することによって、選択を復号化する。許容可能なオプションのセットを決定することによって、デコーダは、コードワードを読み取り、そして、エンコーダによって行われる選択を決定することができる。

ステップ113において、デコーダは、ブロックの復号化を実行する。具体的に、デコーダは、残差ブロックを生成するために逆変換（reverse transforms）を使用する。次いで、デコーダは、パーティション分割に従って画像ブロックを再構成するために、残差ブロックおよび対応する予測ブロックを使用する。予測ブロックは、ステップ105においてエンコーダで生成される、イントラ予測ブロックおよびインター予測ブロックの両方を含み得る。再構成された画像ブロックは、次いで、ステップ111において決定されたパーティション分割データに従って、再構成されたビデオ信号のフレームの中へ位置決めされる。ステップ113のシンタックスは、また、上述のように、エントロピー符号化を介してビットストリーム内で信号化されてもよい。

ステップ115において、エンコーダにおけるステップ107と同様な方法で、再構成されたビデオ信号のフレームについてフィルタリングが実行される。例えば、ブロッキングアーチファクトを除去するために、ノイズ抑制フィルタ、ブロック解除フィルタ、適応ループフィルタ、および、SAOフィルタがフレームに対して適用され得る。一旦、フレームがフィルタリングされると、ビデオ信号は、エンドユーザによる視聴のために、ステップ117において、ディスプレイに対して出力される。

図2は、一つの例示的な符号化および復号化（コーデック）システム200に係る概略図である。具体的に、コーデックシステム200は、動作方法100の実施をサポートするための機能性を提供する。コーデックシステム200は、エンコーダおよびデコーダの両方で使用されるコンポーネントを示すために一般化されている。コーデックシステム200は、動作方法100におけるステップ101およびステップ103に関して説明したように、ビデオ信号を受信し、そして、パーティション分割する。これは、分割されたビデオ信号201を結果として生じる。コーデックシステム200は、次いで、方法100におけるステップ105、ステップ107、およびステップ109に関して説明したように、エンコーダとして動作するときに、分割されたビデオ信号201を符号化ビットストリームへと圧縮する。デコーダとして動作するとき、コーデックシステム200は、動作方法100におけるステップ111、ステップ113、ステップ115、およびステップ117に関して説明したように、ビットストリームから出力ビデオ信号を生成する。コーデックシステム200は、一般コーダ制御コンポーネント211、変換スケーリング及び量子化コンポーネント213、イントラ画像評価（estimation）コンポーネント215、イントラ画像予測（prediction）コンポーネント217、動き補償コンポーネント219、動き評価コンポーネント221、スケーリング及び逆変換コンポーネント229、フィルタ制御解析コンポーネント227、ループ内フィルタコンポーネント225、復号化画像バッファコンポーネント223、そして、ヘッダフォーマッティング及びコンテキスト・アダプティブ・バイナリ・アリスメティック・コンポーネント（CABAC）231、を含んでいる。そうしたコンポーネントは、示されるように結合されている。図2において、黒線は、符号化／復号化されるべきデータの移動を示しており、一方で、破線は、他のコンポーネントの動作をコントロールする制御データの移動を示している。コーデックシステム200のコンポーネントは、全てがエンコーダ内に存在してよい。デコーダは、コーデックシステム200のコンポーネントのサブセットを含んでよい。例えば、デコーダは、イントラ画像予測コンポーネント217、動き補償コンポーネント219、スケーリング及び逆変換コンポーネント229、ループ内フィルタコンポーネント225、および、復号化画像バッファコンポーネント223、を含み得る。これらのコンポーネントが、これから説明される。

分割されたビデオ信号201は、コーディングツリーによってピクセルのブロックへと分割されている、キャプチャされたビデオシーケンスである。コーディングツリーは、ピクセルのブロックをピクセルのより小さいブロックへと細分化するために、種々の分割モード（split mode）を使用する。次いで、これらのブロックは、さらに、より小さいブロックへと細分化され得る。ブロックは、コーディングツリーにおけるノードとして参照され得る。大きな親ノード（parent node）は、より小さい子ノード（child node）へと分割される。ノードが細分化される回数は、ノード／コーディングツリーの深度（depth）として参照される。分割されたブロックは、場合によって、符号化ユニット（CU）の中に含まれ得る。例えば、CUは、CUについて対応するシンタックス命令と共に、ルマブロック、赤色差異クロマ（Cr）ブロック、および青色差異クロマ（Cb）ブロックを含む、CTUのサブ部分であり得る。分割モードは、使用される分割モードに依存して、ノードを、それぞれに、異なる形状の２つ、３つ、または４つの子ノードへと分割するために使用される、バイナリツリー（BT）、トリプルツリー（TT）、およびクワッドツリー（QT）を含み得る。分割されたビデオ信号201は、圧縮のために、一般コーダ制御コンポーネント211、変換スケーリング及び量子化コンポーネント213、イントラ画像評価コンポーネント215、フィルタ制御解析コンポーネント227、および動き評価コンポーネント221に対して転送される。

一般コーダ制御コンポーネント211は、アプリケーションの制約に従って、ビデオシーケンスの画像をビットストリームへと符号化することに関する決定を行うように構成されている。例えば、一般コーダ制御コンポーネント211は、ビットレート／ビットストリームサイズに対する再構成品質の最適化を管理する。そうした決定は、記憶領域／帯域幅の利用可能性および画像解像度要求に基づいて行われ得る。一般コーダ制御コンポーネント211は、また、バッファのアンダーランおよびオーバーランの問題を軽減するために、送信速度に照らしてバッファの利用を管理する。これらの問題を管理するために、一般コーダ制御コンポーネント211は、他のコンポーネントによるパーティション分割、予測、およびフィルタリングを管理する。例えば、一般コーダ制御コンポーネント211は、解像度を増加させ、かつ、帯域幅の使用を増加させるために圧縮の複雑性を動的に増加させることができ、もしくは、解像度および帯域幅の使用を減少させるために圧縮の複雑性を減少させることができる。従って、一般コーダ制御コンポーネント211は、ビデオ信号再構成の品質とビットレートの問題（concern）とのバランスを取るために、コーデックシステム200の他のコンポーネントを制御する。一般コーダ制御コンポーネント211は、他のコンポーネントの動作を制御する、制御データを生成する。制御データは、また、ヘッダフォーマット及びCABACコンポーネント231に対しても転送されて、デコーダにおいて復号化するための信号パラメータへ、ビットストリームにおいて、符号化される。

分割されたビデオ信号201は、また、インター予測のために、動き評価コンポーネント221および動き補償コンポーネント219に対しても送付される。分割されたビデオ信号201のフレームまたはスライスは、複数のビデオブロックへと分割され得る。動き評価コンポーネント221および動き補償コンポーネント219は、時間的予測を提供するために、１つ以上の参照フレームにおける１つ以上のブロックに関する受信されたビデオブロックのインター予測コーディングを実行する。コーデックシステム200は、例えば、ビデオデータの各ブロックについて適切な符号化モードを選択するために、複数の符号化パス（coding passes）を実行し得る。

動き評価コンポーネント221および動き補償コンポーネント219は、高度に統合され得るが、概念的な目的のために別個に図示されている。動き評価コンポーネント221によって実行される、動き評価は、動きベクトルを生成するプロセスであり、それは、ビデオブロックの動きを評価する。動きベクトルは、例えば、予測ブロックに対する符号化オブジェクトの変位を示し得る。予測ブロックは、ピクセル差（pixel difference）に関して、符号化されるブロックに密接に一致することが見出されるブロックである。予測ブロックは、参照ブロックとしても参照される。そうしたピクセル差は、絶対差の合計（SAD）、二乗差の合計（SSD）、または他の差分メトリックによって決定され得る。HEVCは、CTU、コーディングツリーブロック（CTB）、およびCUを含む、いくつかの符号化オブジェクトを使用する。例えば、CTUはCTBへと分割され、CTBは、次いで、CUに含めるためにCBへと分割される。CUは、予測データを含む予測ユニット（PU）、及び／又は、CUについて変換された残差データを含む変換ユニット（TU）として符号化され得る。動き評価コンポーネント221は、レート歪み（rate distortion）最適化プロセスの一部としてレート歪み解析を使用することによって、動きベクトル、PU、およびTUを生成する。例えば、動き評価コンポーネント221は、現在のブロック/フレームについて、複数の参照ブロック、複数の動きベクトル、等を決定し、そして、最善のレート歪み特性を有する、参照ブロック、動きベクトル、等を選択することができる。最善のレート歪み特性は、ビデオ再構成の品質（例えば、圧縮によるデータ損失量）と符号化効率（例えば、最終符号化のサイズ）の両方をバランスさせる。

いくつかの例において、コーデックシステム200は、復号化画像バッファコンポーネント223に保管された参照画像のサブ整数（sub-integer）ピクセル位置の値を計算することができる。例えば、ビデオコーデックシステム200は、参照画像の１／４ピクセル位置、１／８ピクセル位置、または他の端数の（fractional）ピクセル位置の値を補間することができる。従って、動き評価コンポーネント221は、全てのピクセル位置および端数のピクセル位置に関して動き検索を実行し、そして、端数のピクセル精度を有する動きベクトルを出力することができる。動き評価コンポーネント221は、PUの位置を参照画像の予測ブロックの位置と比較することによって、インター符号化スライスにおけるビデオブロックのPUについて動きベクトルを計算する。動き評価コンポーネント221は、計算された動きベクトルを、符号化のためのヘッダフォーマッティング及びCABACコンポーネント231への動きデータ、および、動き補償コンポーネント219への動き、として出力する。

動き補償コンポーネント219によって実行される、動き補償は、動き評価コンポーネント221によって決定された動きベクトルに基づいて、予測ブロックをフェッチすること（fetching）または生成することを含み得る。再び、いくつかの例において、動き評価コンポーネント221および動き補償コンポーネント219は、機能的に統合され得る。現在のビデオブロックのPUについて動きベクトルを受信すると、動き補償コンポーネント219は、動きベクトルが指し示す予測ブロックの位置を突き止めることができる。次いで、符号化されている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって、残差ビデオブロックが形成され、ピクセル差値を形成している。一般的に、クロマコンポーネントおよびルマコンポーネントの両方について、動き評価コンポーネント221は、ルマコンポーネントに関して動き評価を実行し、そして、動き補償コンポーネント219は、ルマコンポーネントに基づいて計算された動きベクトルを使用する。予測ブロックおよび残差ブロックは、変換スケーリング及び量子化コンポーネント213へ転送される。

パーティション分割されたビデオ信号201は、また、イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217へ送付される。動き評価コンポーネント221および動き補償コンポーネント219と同様に、イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217は、高度に統合され得るが、概念的な目的のために別個に図示されている。イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217は、上述のように、フレーム間で動き評価コンポーネント221および動き補償コンポーネント219によって実行されるインター予測の代わりとして、現在フレーム内のブロックに対する現在ブロックをイントラ予測する。特に、イントラ画像評価コンポーネント215は、現在ブロックを符号化するために使用するイントラ予測モードを決定する。いくつかの例において、イントラ画像評価コンポーネント215は、複数の試験されたイントラ画像予測モードから、現在ブロックを符号化するために適切なイントラ予測モードを選択する。選択されたイントラ予測モードは、次いで、符号化のために、ヘッダフォーマッティング及びCABACコンポーネント231に対して転送される。

例えば、イントラ画像評価コンポーネント215は、様々な試験されたイントラ画像予測モードについてレート歪み解析を使用してレート歪み値を計算し、そして、試験されたモードの中で最善のレート歪み特性を有するイントラ予測モードを選択する。レート歪み解析は、一般的に、符号化ブロックと、その符号化ブロックを生成するために符号化された元の非符号化ブロック、並びに、その符号化ブロックを生成するために使用されるビットレート（例えば、ビット数）との間の歪み（または、エラー）の量を決定する。イントラ画像評価コンポーネント215は、種々の符号化ブロックに対する歪みおよびレートから比率（ratio）を計算し、どのイントラ予測モードが、ブロックに対して最善のレート歪み値を示すかを決定する。加えて、イントラ画像評価コンポーネント215は、レート歪み最適化（RDO）に基づく深度モデリングモード（DMM）を使用して、深度マップの深度ブロックを符号化するように構成され得る。

イントラ画像予測コンポーネント217は、エンコーダに実装された場合には、イントラ画像評価コンポーネント215によって決定された、選択されたイントラ予測モードに基づいて、予測ブロックから残差ブロックを生成し、もしくは、デコーダに実装された場合には、ビットストリームから残差ブロックを読み出すことができる。残差ブロックは、マトリックスとして表される、予測ブロックと元のブロックとの間での値における差異を含んでいる。残差ブロックは、次いで、変換スケーリング及び量子化コンポーネント213へ転送される。イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217は、ルマコンポーネントおよびクロマコンポーネントの両方において動作し得る。

変換スケーリング及び量子化コンポーネント213は、さらに、残差ブロックを圧縮するように構成されている。変換スケーリング及び量子化コンポーネント213は、離散コサイン変換（DCT）、離散サイン変換（DST）、または概念的に類似した変換、といった変換を残差ブロックに対して適用し、残差変換係数値を含むビデオブロックを生成している。ウェーブレット（wavelet）変換、整数変換、サブバンド変換、または他のタイプの変換も、また、使用され得る。変換は、残差情報を、ピクセル値ドメインから、周波数ドメインといった、変換ドメインへ変換することができる。変換スケーリング及び量子化コンポーネント213は、また、例えば周波数に基づいて、変換された残差情報をスケーリングするように構成されている。そうしたスケーリングは、異なる周波数情報が異なる粒度（granularity）で量子化されるように、スケールファクタを残差情報に適用することを含み、これは、再構成されたビデオの最終的な見栄え（visual quality）に影響を及ぼし得る。変換スケーリング及び量子化コンポーネント213は、また、さらにビットレートを低下させるために、変換係数を量子化するようにも構成されている。量子化プロセスは、係数のいくつか又は全てに関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例において、変換スケーリング及び量子化コンポーネント213は、次いで、量子化された変換係数を含むマトリックスのスキャンを実行し得る。量子化された変換係数は、ヘッダフォーマッティング及びCABACコンポーネント231へ転送され、ビットストリームに符号化される。

スケーリング及び逆変換コンポーネント229は、動き評価（motion estimation）をサポートするために、変換スケーリング及び量子化コンポーネント213の逆演算を適用する。スケーリング及び逆変換コンポーネント229は、ピクセルドメイン内の残差ブロックを再構成するために、逆スケーリング、変換、及び／又は、量子化を適用する。例えば、別の現在ブロックの予測ブロックとなり得る参照ブロックとして、後に使用するためである。動き評価コンポーネント221及び／又は動き補償コンポーネント219は、後のブロック/フレームの動き評価における使用のために、残差ブロックを対応する予測ブロックに戻して加算することによって、参照ブロックを計算し得る。フィルタは、スケーリング、量子化、および変換の最中に生成されるアーチファクトを軽減するために、再構成された参照ブロックに対して適用される。そうしたアーチファクトは、そうでなければ、後続のブロックが予測されるときに、不正確な予測を引き起こし得る（そして、追加のアーチファクトを生成し得る）。

フィルタ制御解析コンポーネント227およびループ内フィルタコンポーネント225は、残差ブロック、及び／又は、再構成された画像ブロックに対してフィルタを適用する。例えば、スケーリング及び逆変換コンポーネント229からの変換された残差ブロックは、元の画像ブロックを再構成するために、イントラ画像予測コンポーネント217及び／又は動き補償コンポーネント219からの対応する予測ブロックと組み合わされてよい。フィルタは、次いで、再構成された画像ブロックに対して適用され得る。いくつかの例において、フィルタは、代わりに、残差ブロックに対して適用されてよい。図2における他のコンポーネントと同様に、フィルタ制御解析コンポーネント227およびループ内フィルタコンポーネント225は、高度に統合されており、そして、一緒に実装されてよいが、概念的な目的のために別個に図示されている。再構成された参照ブロックに適用されるフィルタは、特定の空間領域に対して適用され、そして、そうしたフィルタが適用される方法を調整するための複数のパラメータを含んでいる。フィルタ制御解析コンポーネント227は、そうしたフィルタを適用すべき場所を決定するために、再構成された参照ブロックを解析し、そして、対応するパラメータをセットする。そうしたデータは、符号化のためのフィルタ制御データとして、ヘッダフォーマット及びCABACコンポーネント231へ転送される。ループ内フィルタコンポーネント225は、フィルタ制御データに基づいて、そうしたフィルタを適用する。フィルタは、ブロック解除フィルタ、ノイズ抑制フィルタ、SAOフィルタ、および適応ループフィルタを含み得る。そうしたフィルタは、例に応じて、空間／ピクセルドメイン（例えば、再構成されたピクセルブロック）または周波数ドメインにおいて適用され得る。

エンコーダとして動作する場合、フィルタリングされ、再構成された、画像ブロック、残差ブロック、及び／又は、予測ブロックは、上述のように、後で動き評価に使用するために、復号化画像バッファコンポーネント223に保管される。デコーダとして動作する場合に、復号化画像バッファコンポーネント223は、再構成されフィルタリングされたブロックを、保管し、そして、出力ビデオ信号の一部としてディスプレイへ向けて転送する。復号化画像バッファコンポーネント223は、予測ブロック、残差ブロック、及び／又は、再構成された画像ブロックを保管することができる任意のメモリデバイスであってよい。

ヘッダフォーマット及びCABACコンポーネント231は、コーデックシステム200の様々なコンポーネントからデータを受信し、そして、デコーダへ向けて送信するために、そうしたデータを符号化ビットストリームへと符号化する。具体的に、ヘッダフォーマッティング及びCABACコンポーネント231は、一般的制御データおよびフィルタ制御データといった、制御データを符号化するために種々のヘッダを生成する。さらに、イントラ予測および動きデータを含む、予測データ、並びに、量子化変換係数データの形態における残差データは、全てビットストリームに符号化される。最終的なビットストリームは、元の分割されたビデオ信号201を再構成するためにデコーダによって望まれる全ての情報を含んでいる。そうした情報は、また、イントラ予測モードインデックステーブル（コードワードマッピングテーブルとしても参照される）、様々なブロックに対する符号化コンテキストの定義、最も可能性の高いイントラ予測モードの表示（indication）、分割情報の表示、等を含み得る。そうしたデータは、エントロピー符号化を使用することによって符号化され得る。例えば、情報は、コンテキスト適応可変長符号化（CAVLC）、CABAC、シンタックスベースのコンテキスト適応バイナリ演算符号化（SBAC）、確率区間分割エントロピー（PIPE）符号化、または、別のエントロピー符号化技術を使用することによって、符号化され得る。エントロピー符号化に続いて、符号化されたビットストリームは、別の装置（例えば、ビデオデコーダ）へ送信されてよく、もしくは、後の送信または検索のためにアーカイブされてよい。

図3は、一つの例示的なビデオエンコーダ300を説明するブロック図である。ビデオエンコーダ300は、コーデックシステム200の符号化機能を実装するため、かつ／あるいは、動作方法100のステップ101、103、105、107、及び／又は109を実装するために使用され得る。エンコーダ300は、入力ビデオ信号をパーティション分割し、結果として分割されたビデオ信号301を生じ、これは、分割されたビデオ信号201と実質的に同様である。分割されたビデオ信号301は、次いで、エンコーダ300のコンポーネントによって圧縮され、そして、ビットストリームへと符号化される。

具体的に、分割されたビデオ信号301は、イントラ予測のために、イントラ画像予測コンポーネント317へ転送される。イントラ画像予測コンポーネント317は、イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217と実質的に同様であり得る。分割されたビデオ信号301は、また、復号化画像バッファコンポーネント323内の参照ブロックに基づくインター予測のために、動き補償コンポーネント321へも転送される。動き補償コンポーネント321は、動き評価コンポーネント221および動き補償コンポーネント219と実質的に同様であり得る。イントラ画像予測コンポーネント317および動き補償コンポーネント321からの、予測ブロックおよび残差ブロックは、残差ブロックの変換および量子化のために、変換及び量子化コンポーネント313へ転送される。変換及び量子化コンポーネント313は、変換スケーリング及び量子化コンポーネント213と実質的に同様であり得る。変換され、かつ、量子化された残差ブロックおよび対応する予測ブロックは（関連する制御データと一緒に）、ビットストリームへの符号化のために、エントロピー符号化コンポーネント331へ転送される。エントロピー符号化コンポーネント331は、ヘッダフォーマット及びCABACコンポーネント231と実質的に同様であり得る。

変換され、かつ、量子化された残差ブロック及び／又は対応する予測ブロックは、また、動き補償コンポーネント321による使用のため、参照ブロックへと再構成するために、変換及び量子化コンポーネント313から逆変換及び量子化コンポーネント329へも転送される。逆変換及び量子化コンポーネント329は、スケーリング及び逆変換コンポーネント229と実質的に同様であり得る。ループ内フィルタコンポーネント325におけるループ内フィルタは、また、例に応じて、残差ブロック及び／又は再構成された参照ブロックにも適用される。ループ内フィルタコンポーネント325は、フィルタ制御解析コンポーネント227およびループ内フィルタコンポーネント225と実質的に同様であり得る。ループ内フィルタコンポーネント325は、ループ内フィルタコンポーネント225に関して説明したように、複数のフィルタを含み得る。フィルタリングされたブロックは、次いで、動き補償コンポーネント321による参照ブロックとしての使用のために、復号化画像バッファコンポーネント323において保管される。復号化画像バッファコンポーネント323は、復号化画像バッファコンポーネント223と実質的に同様であり得る。

図4は、一つの例示的なビデオデコーダ400を説明するブロック図である。ビデオデコーダ400は、コーデックシステム200の復号化機能を実施するため、かつ／あるいは、動作方法100のステップ111、113、115、及び／又は117を実施するために使用され得る。デコーダ400は、例えば、エンコーダ300から、ビットストリームを受信し、そして、エンドユーザに対して表示するために、ビットストリームに基づいて、再構成された出力ビデオ信号を生成する。

ビットストリームは、エントロピー復号化コンポーネント433によって受信される。エントロピー復号化コンポーネント433は、CAVLC、CABAC、SBAC、PIPE符号化、または他のエントロピー符号化技術、等といった、エントロピー復号化スキームを実装するように構成されている。例えば、エントロピー復号化コンポーネント433は、ビットストリーム内のコードワードとして、追加の符号化されたデータを解釈するためのコンテキストを提供するように、ヘッダ情報を使用することができる。デコードされた情報は、一般的な制御データ、フィルタ制御データ、分割情報（partition information）、動きデータ、予測データ、および残差ブロックからの量子化変換係数といった、ビデオ信号を復号化するための任意の必要とされる情報を含んでいる。量子化された変換係数は、残差ブロックへと再構成するために、逆変換及び量子化コンポーネント429へ転送される。逆変換及び量子化コンポーネント429は、逆変換及び量子化コンポーネント329と同様であり得る。

再構成された残差ブロック及び／又は予測ブロックは、イントラ予測動作に基づいて、画像ブロックへと再構成するために、イントラ画像予測コンポーネント417へ転送される。イントラ画像予測コンポーネント417は、イントラ画像評価コンポーネント215およびイントラ画像予測コンポーネント217と同様であり得る。具体的に、イントラ画像予測コンポーネント417は、フレーム内の参照ブロックを突き止める（locate）ために予測モードを採用し、そして、イントラ予測画像ブロックを再構成するために、残差ブロックを結果に適用する。再構成されたイントラ予測画像ブロック及び／又は残差ブロック、および対応するインター予測データは、ループ内フィルタコンポーネント425を介して、復号化画像バッファコンポーネント423へ転送される。これらは、復号化画像バッファコンポーネント223およびループ内フィルタコンポーネント225と、それぞれ、実質的に同様であり得る。ループ内フィルタコンポーネント425は、再構成された画像ブロック、残差ブロック及び／又は予測ブロックをフィルタリングし、そして、そうした情報が復号化画像バッファコンポーネント423に保管される。復号化画像バッファコンポーネント423からの再構成された画像ブロックは、インター予測のために動き補償コンポーネント421へ転送される。動き補償コンポーネント421は、動き評価コンポーネント221及び／又は動き補償コンポーネント219と実質的に同様であり得る。具体的に、動き補償コンポーネント421は、予測ブロックを生成するために、参照ブロックからの動きベクトルを使用し、そして、画像ブロックを再構成するために、残差ブロックを結果に適用する。結果として生じる再構成されたブロックは、また、ループ内フィルタコンポーネント425を介して、復号化画像バッファコンポーネント423へ転送され得る。復号化画像バッファコンポーネント423は、分割情報を介してフレームへと再構成され得る、追加の再構成画像ブロックを保管し続ける。そうしたフレームは、また、シーケンス内にも配置され得る。シーケンスは、再構成された出力ビデオ信号としてディスプレイへ向けて出力される。

図5は、PCCメカニズムに従って符号化することができるポイントクラウド媒体500の一つの例である。ポイントクラウドとは、空間におけるデータポイントのセット（set）である。ポイントクラウドは、オブジェクトの周囲でオブジェクトの外部表面上の多数のポイントを測定する、3Dスキャナによって生成され得る。ポイントクラウドは、ジオメトリ属性、テクスチャ属性、反射率属性、透明性属性、法線属性、等の観点から記述され得る。各属性は、方法100の一部として、ビデオコーデックシステム200、エンコーダ300、及び／又は、デコーダ400等といった、コーデックによって符号化され得る。具体的に、PCCフレームの各属性は、エンコーダで別々に符号化され、かつ、デコーダでデコードされ、そして、PCCフレームを再作成するために再結合され得る。

ポイントクラウド媒体500は、３つの境界ボックス502、504、および506を含んでいる。境界ボックス502、504、および506それぞれは、現在フレームからの3D画像の一部またはセグメントを表す。境界ボックス502、504、および506は、人物の3D画像を含んでいるが、実際のアプリケーションでは、他のオブジェクトが境界ボックス内に含まれてよい。各境界ボックス502、504、および506は、それぞれに、x、y、およびz方向において3D画像によって占有されるピクセル数を示す、x軸、y軸、およびz軸を含む。例えば、x軸およびy軸は、約400ピクセル（例えば、約0－400ピクセル）を示し、一方、z軸は、約1000ピクセル（例えば、約0－1000ピクセル）を示している。

境界ボックス502、504、および506それぞれは、図5においてキューブまたはボックスによって表現されている、１つ以上のパッチ508を含んでいる。各パッチ508は、境界ボックス502、504、または506のうち１つの中のオブジェクト全体のうち一部を含み、そして、パッチ情報によって記述され、または、表現され得る。パッチ情報は、例えば、境界ボックス502、504、または506の中のパッチ508の位置を記述する２次元（2D）座標及び／又は３次元（3D）座標を含み得る。パッチ情報は、また、他のパラメータも含み得る。例えば、パッチ情報は、基準パッチ情報から現在のパッチ情報に対して継承される、法線軸（normalAxis）といったパラメータを含み得る。すなわち、基準フレームのパッチ情報からの１つ以上のパラメータが、現在フレームのパッチ情報に対して継承され得る。加えて、参照フレームからの１つ以上のメタデータ部分（例えば、パッチ回転、スケールパラメータ、材料識別子、等）が、現在フレームによって継承され得る。パッチ508は、ここにおいては、3Dパッチまたはパッチデータユニットとして互換的に参照され得る。各境界ボックス502、504、または506におけるパッチ508のリストが生成され、そして、、最大パッチから最小パッチまで降順で（in descending order）パッチバッファに保管され得る。パッチは、次いで、エンコーダによって符号化され、かつ／あるいは、デコーダによって復号化され得る。

パッチ508は、ポイントクラウド媒体500の様々な属性を記述することができる。具体的には、x軸、y軸、およびz軸上の各ピクセルの位置は、そのピクセルのジオメトリ形状である。現在フレーム内の全てのピクセルの位置を含んでいるパッチ508は、ポイントクラウド媒体500の現在フレームに対するジオメトリ属性をキャプチャするように符号化され得る。さらに、各ピクセルは、赤、青、および緑（RGB）、及び／又は、ルミナンスおよびクロミナンス（YUV）スペクトルにおける色値を含み得る。現在フレーム内の全てのピクセルの色を含むパッチ508は、ポイントクラウド媒体500の現在フレームに対するテクスチャ属性をキャプチャするように符号化され得る。

加えて、各ピクセルは、いくらかの反射率（reflectance）を含んでよい（または、含まなくてもよい）。反射率は、ピクセルから隣接するピクセルに対して投影する光（例えば、着色光）の量である。輝くオブジェクトは高い反射率を有し、そして、従って、対応するピクセルの光／色を他の近くのピクセルに広げる。一方で、マットなオブジェクトは、反射率がほとんど又は全くなく、そして、隣接するピクセルの色／光レベルに影響しなくてよい。現在フレーム内の全てのピクセルの反射率を含むパッチ508は、ポイントクラウド媒体500の現在フレームに対する反射率属性をキャプチャするように符号化され得る。いくつかのピクセルは、また、部分的に、完全に透明であってよい（例えば、ガラス、透明プラスチック、等）。透明性は、現在のピクセルを通過することができる隣接するピクセルの光／色の量である。現在フレーム内の全てのピクセルの透明性のレベルを含んでいるパッチ508は、ポイントクラウド媒体500の現在フレームの透明性属性をキャプチャするように符号化され得る。さらに、ポイントクラウド媒体のポイントは、表面を作成し得る。表面は、表面に対して垂直なベクトルである、法線ベクトルと関連付けされ得る。法線ベクトルは、オブジェクトの動き及び／又は相互作用を記述するときに、役に立ち得る。従って、場合によって、ユーザは、追加的な機能性をサポートするために、表面に対する法線ベクトルを符号化するように望み得る。現在フレーム内の表面に対する法線ベクトルを含んでいるパッチ508は、ポイントクラウド媒体500の現在フレームに対する法線属性をキャプチャするように符号化され得る。

ジオメトリ、テクスチャ、反射率、透明性、および法線属性は、例に応じて、ポイントクラウド媒体500内のいくつか又は全てのデータポイントを記述するデータを含み得る。例えば、反射率、透明性、および垂直属性は任意的であり、そして、従って、いくつかのポイントクラウド媒体500の例について、かつ、同一のビットストリームにおいてさえ、他のものについてではなく、個別に、または、組み合わせで発生し得る。かくして、パッチ508の数、そして、さらには属性の数は、フィルム化（filmed）された技術的事項（subject matter）、ビデオ設定、等に基づいて、フレームごと、そして、ビデオごとに変動し得る。

図6は、ポイントクラウド媒体フレーム600のためのデータ分割およびパッキングの一つの例である。具体的に、図6の例は、ポイントクラウド媒体500のパッチ508の2D表現を示している。ポイントクラウド媒体フレーム600は、ビデオシーケンスからの現在フレームに対応する境界ボックス602を含んでいる。境界ボックス602は、3Dである図5の境界ボックス502、504、および506とは対照的に2Dである。示されるように、境界ボックス602は、多数のパッチ604を含んでいる。パッチ604は、ここにおいては、2Dパッチまたはパッチデータユニットとして互換的に参照され得る。まとめると、図6のパッチ604は、図5からの境界ボックス504内の画像の表現である。かくして、図5の境界ボックス504内の3D画像は、パッチ604を介して境界ボックス602上に投影される。パッチ604のうち１つを含まない境界ボックス602の部分は、空スペース（empty space）606として参照される。空スペース606は、空隙（void space）、空サンプル（empty samples）、等としても参照される。

上記を念頭におくと、ビデオベースのポイントクラウド圧縮（PCC）コーデック・ソリューションは、3Dポイントクラウドデータ（例えば、図5のパッチ508）の2D投影パッチ（例えば、図6のパッチ604）へのセグメント化に基づいていることが留意されるべきである。実際に、上述の符号化方法またはプロセスは、例えば、イマーシブな6自由度（6 DoF）、ダイナミック拡張現実／仮想現実（AR/VR）オブジェクト、文化遺産、グラフィック情報システム（GIS）、コンピュータ支援設計（CAD）、自律ナビゲーション、等といった、種々のタイプの技術に対して有益に実装され得る。

境界ボックス（例えば、境界ボックス602）内の各パッチ（例えば、図6のパッチ604のうちの１つ）の位置は、パッチのサイズのみによって決定され得る。例えば、図6のパッチ604のうち最大のものは、最初に左上隅（0,0）から始まる境界ボックス602上に投影される。パッチ604のうち最大のものが境界ボックス602上に投影された後で、次に最大なパッチ604が、境界ボックス602上に投影され（別名、中へ充填され）、そして、パッチ604のうち最小のものが境界ボックス602上に投影されるまで続く。再び、このプロセスでは、各パッチ604のサイズのみが考慮される。場合によって、より小さいサイズを有するパッチ604は、より大きなパッチ間の空間を占め、そして、より大きなパッチ604よりも境界ボックス602の左上隅により近い位置を有することになり得る。符号化の最中に、このプロセスは、フレーム内の各属性に対するパッチが１つ以上の対応する属性ストリームへと符号化されるまで、各関連の属性について繰り返され得る。単一フレームを再作成するために使用される属性ストリーム内のデータユニットのグループは、次いで、PCC AU内のビットストリームに保管され得る。デコーダにおいて、これらの属性ストリームは、PCC AUから取得され、そして、パッチ604を生成するように復号化される。そうしたパッチ604は、次いで、PCC媒体を再作成するように組み合わされ得る。かくして、ポイントクラウド媒体フレーム600は、送信のためにポイントクラウド媒体500を圧縮する方法100の一部として、ビデオコーデックシステム200、エンコーダ300、及び／又はデコーダ400といった、コーデックによって符号化され得る。

図7は、拡張属性セット（expanded attribute set）を有する一つの例示的なPCCビデオストリーム700を説明する概略図である。例えば、PCCビデオストリーム700は、ポイントクラウド媒体500からのポイントクラウド媒体フレーム600が方法100に従って符号化されるときに、例えば、ビデオコーデックシステム200、エンコーダ300、及び／又はデコーダ400を使用することによって、生成され得る。

PCCビデオストリーム700は、PCC AU710のシーケンスを含んでいる。PCC AU710は、単一のPCCフレームを再構成するために十分なデータを含んでいる。データは、NALユニット720においてPCC AU710の中に置かれている。NALユニット720は、パケットサイズのデータコンテナである。例えば、単一のNALユニット720は、一般的に、単純なネットワーク送信を可能にするサイズである。NALユニット720は、NALユニット720のタイプを示すヘッダ、および、関連するビデオデータを含むペイロードを含み得る。PCCビデオストリーム700は、拡張属性セットのために設計されており、そして、従って、いくつかの属性特定NALユニット720を含んでいる。

PCCビデオストリーム700は、フレームグループ（group of frames、GOF）ヘッダ721、補助情報フレーム722、占有マップフレーム723、ジオメトリNALユニット724、テクスチャNALユニット725、反射NALユニット726、透明性NALユニット727、および、法線NALユニット728を含み、それぞれはNALユニット720のタイプである。GOFヘッダ721は、対応するPCC AU710、対応するPCC AU710に関連するフレーム、及び／又は、PCC AU710内の他のNALユニット720を記述する様々なシンタックス要素を含んでいる。PCC AU710は、例に応じて、単一のGOFヘッダ721を含んでよく、または、GOFヘッダ721を含まなくてもよい。補助情報フレーム722は、属性を符号化するために使用されるパッチに関連する情報といった、フレームに関連するメタデータを含み得る。占有マップフレーム723は、さらに、空であるフレームの領域に対するデータで占有されているフレームの領域を示す占有マップといった、フレームに関連するメタデータを含み得る。残りのNALユニット720は、PCC AU710に対する属性データを含む。具体的に、ジオメトリNALユニット724、テクスチャNALユニット725、反射NALユニット726、透明性NALユニット727、および法線NALユニット728は、それぞれに、ジオメトリ属性、テクスチャ属性、反射率属性、透明性属性、および法線属性を含んでいる。

上述のように、属性は、ストリームへと編成され得る。例えば、各属性に対してゼロから４つのストリームが存在し得る。ストリームは、PCCビデオデータの論理的に分離した部分を含み得る。例えば、異なるオブジェクトのための属性は、同じタイプの複数の属性ストリーム（例えば、第１の3Dバウンドボックスのための第１ジオメトリストリーム、第２の3Dバウンドボックスのための第２属性ストリーム、等）へと符号化され得る。別の例において、異なるフレームと関連する属性は、複数の属性ストリーム（例えば、偶数フレームのための透明性属性ストリーム、および、奇数フレームのための透明性属性ストリーム）へと符号化され得る。さらに別の例において、パッチは、3Dオブジェクトを表現するように、層状に配置され得る。従って、別々の層は、別々のストリームに含まれ得る（例えば、上部層に対して第1テクスチャ属性ストリーム、第２層に対して第２テクスチャ属性ストリーム、等）。例にかかわらず、PCC AU710は、対応する属性について、ゼロ、1、または複数のNALユニットを含み得る。

属性の拡張セットは、任意の属性を含み、かつ、いくつかのPCC AU710においてゼロストリームを含み得ることも、また、留意されるべきである。かくして、リストされたNALユニット720のいくつかは、いくつかのPCC AU710内でいくつかのPCC属性ストリームについて存在しなくてよく、そして、他のPCC AU710内でいくつかのストリームに存在してよい。従って、PCCビデオストリーム700全体が一定のフレームレートを有する場合であっても、根底にあるPCC属性ストリームは、非定数の（non-constant）フレームレートを含み得る。

以下は、上述の態様を実施するための一つの定時的なメカニズムである。定義：ビデオNALユニットは、GMTRY_NALU、TEXTURE_NALU、REFLECT_NALU、TRANSP_NALU、またはNORMAL_NALUに等しいPCC NALUnitTypeを有するPCC NALユニットである。

ビットストリームフォーマット：この句は、NALユニットストリームとバイトストリームとの間の関係性を指定するものであり、いずれかがビットストリームとして参照される。ビットストリームは、２つのフォーマット：NALユニットストリームフォーマットまたはバイトストリームフォーマット、のうち１つであり得る。NALユニットストリームフォーマットは、概念的には、より基本的なタイプであり、そして、PCC NALユニットと呼ばれる一連のシンタックス構造を含んでいる。このシーケンスは、復号化順序で整理される。NALユニットストリーム内のPCC NALユニットの復号化順序（および、コンテンツ）に課される制約が存在している。バイトストリームフォーマットは、NALユニットを符号化順序で並べること、および、バイトストリームを形成するように、各NALユニットに開始コードプレフィックスおよびゼロ以上のゼロ値バイトをプレフィックスすること（prefixing）によって、NALユニットストリームフォーマットから構築され得る。NALユニットストリームフォーマットは、このバイトのストリーム内のユニークな開始コードプレフィックスパターンの位置を検索することによって、バイトストリームフォーマットから抽出され得る。バイトストリームフォーマットは、HEVCおよびAVCにおいて採用されているフォーマットと類似している。

PCC NALユニットヘッダシンタックスは、以下の表1に記述されるように実装され得る。

表１ PCC NALユニットヘッダシンタックス

フレームグループヘッダ・ローバイトシーケンスペイロード（RBSP）シンタックスは、以下の表2に記述されるように実装され得る。

表２ フレームグループヘッダRBSPシンタックス

PCCプロファイルおよびレベルシンタックスは、以下の表３に記載されるように実装され得る。

表３ PCCプロファイルシンタックス

PCC NALユニットヘッダのセマンティクスは、以下のように実装され得る。forbidden_zero_bitがゼロに等しく設定され得る。pcc_nal_unit_type_plus1マイナス１は、変数PCC NALUnitTypeの値を指定し、以下の表４で指定されるように、PCC NALユニットに含まれるRBSPデータ構造のタイプを指定する。変数NalUnitTypeは次のように指定される。
PCC NALUnitType=pcc_nal_unit_type_plus1－1 （７－１）
UNSPEC25..UNSPEC30の範囲内のnal_unit_typeを有するPCC NALユニットは、セマンティクスが明記されていないもの、を含めて、ここにおいて指定される復号化処理に影響を与えない。UNSPEC25..UNSPEC30の範囲内のPCC NALユニットタイプは、アプリケーションによって決定されたとおりに使用され得ることが留意されるべきである。PCC NALUnitTypeのこれらの値に対する復号化プロセスは、本開示では規定されていない。異なるアプリケーションが異なる目的のためにこれらのPCC NALユニットタイプを使用し得るので、これらのPCC NALUnitType値を持つPCC NALユニットを生成するエンコーダの設計、および、これらのPCC NALUnitType値を持つPCC NALユニットのコンテンツを解釈するデコーダの設計においては、特別な注意が払われるべきである。本開示では、これらの値について如何なる管理も定義していない。これらのPCC NALUnitType値は、使用の衝突（例えば、同じPCC NALUnitType値に対するPCC NALユニットコンテンツの意味の異なる定義）は重要でなく、可能ではなく、管理されるコンテキストにおける使用にだけ好適であり得る。－例えば、制御アプリケーションまたはトランスポート仕様で定義され、または管理されるか、もしくは、ビットストリームが配布される環境を制御することによる。

ビットストリームのPCC AU内のデータ量を決定する以外の目的のために、デコーダは、PCC NALUnitTypeの予約値を使用する全てのPCC NALユニットのコンテンツを無視し得る（ビットストリームから削除し、かつ、廃棄する）。この要件は、この開示に対する互換性のある拡張の将来の定義を可能にし得る。

表４ PCC NAL ユニットタイプ・コード

識別されたビデオコーデック（例えば、HEVCまたはAVC）は、各クラウドポイントストリーム（CPS）の第１のPCC AUに存在するフレームグループヘッダNALユニットに示されている。pcc_stream_idは、PCC NALユニットについてPCCストリーム識別子（ID）を指定する。PCC NALUnitTypeがGOF_HEADER、AUX_INFO、またはOCP_MAPに等しい場合に、pcc_stream_idの値はゼロに等しく設定される。PCCプロファイルおよびレベルの１つ以上のセットの定義において、pcc_stream_idの値は、４未満に制限され得る。

PCC NALユニットの順序およびPCC AUに対する関連が以下に説明される。PCC AUは、フレームヘッダNALユニット、１つの補助情報フレームNALユニット、１つの占有マップフレームNALユニット、および、ジオメトリ、テクスチャ、反射、透明性、または法線といった、PCC属性のデータユニットを搬送する１つ以上のビデオAU、に係るゼロまたは１つのグループを含む。video_au（i,j）は、PCC属性IDがattribute_type[i]に等しく、PCC属性についてpcc_stream_idがjに等しいビデオAUを示している。PCC AUに存在するビデオAUは、以下のように順序付けされ得る。attributes_first_ordering_flagが１に等しい場合、PCC AUに存在する任意の２つのビデオAUであるvideo_au（i1,j1）およびvideo_au（i2,j2）に対して、以下が適用される。i1がi2より小さい場合には、j1およびj2の値にかかわらず、video_au（i1,j1）は、video_au（i2,j2）に先行する。そうでなければ、i1がi2に等しく、かつ、j1がj2より大きい場合に、video_au（i1,j1）は、video_au（i2,j2）の後に続く。

さもなければ（例えば、attributes_first_ordering_flagがゼロに等しい）、PCC AUに存在する２つのビデオAUであるvideo_au（i1,j1）およびvideo_au（i2,j2）に対して、以下が適用される。j1がj2より小さい場合には、i1およびi2の値にかかわらず、video_au（i1,j1）は、video_au（i2,j2）に先行する。そうでなければ、j1がj2に等しく、かつ、i1がi2より大きい場合に、video_au（i1,j1）は、video_au（i2,j2）の後に続く。ビデオAUの上記の順序は、以下を結果として生じる。attributes_first_ordering_flagが１に等しい場合、PCC AU内に存在するビデオAUの順序は、存在する場合には、（リストされる順序において）以下の通りである。ここで、PCC AU内では、各特定のPCC属性の全てのPCC NALユニットは、存在する場合には、他のPCC属性のPCC NALユニットとインターリーブされることなく、復号化順序において隣接している。
video_au（0,0）、video_au（0,1）、...、video_au（0,num_streams_for_attribute[0]）、
video_au（1,0）、video_au（1,1）、...、video_au（1,num_streams_for_attribute[1]）、
...
video_au（num_attributes－1,0）、video_au（num_attributes－1,1）、...、video_au（num_attributes－1,num_streams_for_attribute[1]）.
そうでなければ（attributes_first_ordering_flagはゼロに等しい）、PCC AU内に存在するビデオAUの順序は、存在する場合には、（リストされる順序において）以下の通りである。ここで、PCC AU内では、各特定のpcc_stream_id値の全てのPCC NALユニットは、存在する場合には、他のpcc_stream_id値のPCC NALユニットとインターリーブされることなく、復号化順序において隣接している。
video_au（0,0）、video_au（1,0）、...、video_au（num_attributes－1,0）、
video_au（0,1）、video_au（1,1）、...、video_au（num_attributes－1,1）、
...
video_au（0,num_streams_for_attribute[1]）、video_au（1,num_streams_for_attribute[1]）、...、video_au（num_attributes－1,num_streams_for_attribute[1]）.

NALユニットのビデオAUへの関連（association）およびビデオAUの中のNALユニットの順序は、識別されたビデオコーデック、例えば、HEVCまたはAVC、の仕様において規定される。識別されたビデオコーデックは、各CPSの第１のPCC AUに存在するフレームヘッダNALユニットに示されている。

各CPSの第１のPCC AUは、フレームヘッダNALユニットのグループで開始し、そして、フレームヘッダNALユニットの各グループは、新しいPCC AUの開始を指定する。

他のPCC AUは、補助情報フレームNALユニットで開始する。別の言葉で言えば、補助情報フレームNALユニットは、フレームヘッダNALユニットのグループによって先行されない場合に、新しいPCC AUを開始する。

フレームグループヘッダRBSPセマンティクスは、次のとおりである。num_attributesは、CPSで搬送され得るPCC属性（ジオメトリ、テクスチャ、等といったもの）の最大数を指定する。PCCプロファイルおよびレベルのうち１つ以上のセットの定義において、num_attributesの値は、５以下に制限され得ることに留意する。attributes_first_ordering_flagは、ゼロに等しく設定された場合に、PCC AU内で、各PCC属性の全てのPCC NALユニットが、存在する場合には、他のPCC属性のPCC NALユニットとインターリーブされることなく、復号化順序において隣接することを指定する。attributes_first_ordering_flagは、ゼロに等しく設定された場合に、PCC AU内で、各特定のpcc_stream_id値の全てのPCC NALユニットが、存在する場合には、他のpcc_stream_id値のPCC NALユニットとインターリーブされることなく、復号化順序において隣接することを指定する。attribute_type[i]は、i番目のPCC属性のPCC属性タイプを指定する。異なるPCC属性タイプの解釈は、以下の表5に規定されている。PCCプロファイルおよびレベルのうち１つ以上のセットの定義において、attribute_type[0]およびattribute_type[1]の値は、それぞれに、ゼロおよび１に等しくなるように制約され得る。

表５ attribute_type[i]の仕様

identified_codec_for_attribute[i]は、以下の表6に示されるように、i番目のPCC属性の符号化のために使用される識別されたビデオコーデックを指定する。

表６ identified_codec_for_attribute[i]の仕様

num_streams_for_attribute[i]は、i番目のPCC属性についてPCCストリームの最大数を指定する。PCCプロファイルおよびレベルのうち１つ以上のセットの定義において、num_streams_for_attribute[i]の値は、４以下に制限され得ることに留意する。num_layers_for_attribute[i]は、i番目のPCC属性について属性レイヤの数を指定する。PCCプロファイルおよびレベルのうち１つ以上のセットの定義において、num_layer_for_attribute[i]の値は、４以下に制限され得ることに留意する。max_attribute_layer_idx[i][j]は、i番目のPCC属性について、pcc_stream_idがjに等しい、PCCストリームの属性レイヤインデックスの最大値を指定する。max_attribute_layer_idx[i][j]の値は、num_layer_for_attribute[i]より小さい。attribution_layers_combination_mode[i][j]は、i番目のPCC属性について、pcc_stream_idがjに等しい、PCCストリーム内で搬送される属性レイヤに対して、属性レイヤコンビネーションモードを指定する。attribution_layers_combination_mode[i][j]の異なる値の解釈は、以下の表7に規定されている。

表７ attribution_layers_combination_mode[i][j]の仕様

attribution_layers_combination_mode[i][j]が存在しており、かつ、ゼロに等しい場合に、変数attrLayerIdx[i][j]は、i番目のPCC属性について、pcc_stream_idがjに等しい、PCCストリームの属性レイヤに対する属性レイヤインデックスを示しており、識別されたビデオコーデックの仕様で指定されるようにピクチャオーダカウント値がPicOrderCntValに等しい、ビデオAUで搬送されている属性レイヤのPCC NALユニットは、以下のように導出される。
tmpVal=PicOrderCntVal%num_streams_for_attribute[i]
if（j==0）
attrLayerId[i][j]=tmpVal
else
attrLayerId[i][j][k]=max_attribute_layer_id[i][j－1]+1+tmpVal
（７－２）

regular_points_flag[i][j]は、１に等しい場合に、i番目のPCC属性について、レイヤインデックスがjに等しい、属性レイヤが、ポイントクラウド信号の正則点（regular point）を搬送することを指定する。regular_points_flag[i][j]は、ゼロに等しい場合に、i番目のPCC属性について、レイヤインデックスがjに等しい、属性レイヤが、ポイントクラウド信号の非正則点（irregular point）を搬送することを指定する。PCCプロファイルおよびレベルのうち１つ以上のセットの定義において、regular_points_flag[i][j]の値はゼロであるように制限され得ることに留意する。frame_widthは、ジオメトリおよびテクスチャビデオのフレーム幅を、ピクセルで、示している。フレーム幅は、occupancyResolutionの倍数である。frame_heightは、ジオメトリビデオおよびテクスチャビデオのフレーム高さを、ピクセルで、示している。フレーム高さは、occupancyResolutionの倍数である。occupancyResolutionは、パッチがジオメトリおよびテクスチャビデオにパックされる、水平および垂直解像度を、ピクセルで、示している。occupancy_resolutionは、occupancyPrecisionの偶数値の倍数である。radius_to_smoothingは、スムージングのために近隣を検出する半径を示している。radius_to_smootingの値は、0から255までを含む範囲である。

neighbor_count_smootingは、スムージングのために使用される近隣（neighbors）の最大数を示している。neighbor_count_smootingの値は、０から２５５までを含む範囲である。radius2_boundary_detectionは、境界点検出のための半径を示している。radius2_boundary_detectionの値は、ゼロから２５５までを含む範囲である。threshold_smootingは、スムージング閾値を示している。threshold_smootingの値は、０から２５５までを含む範囲である。lossless_geometryは、可逆な（lossless）ジオメトリ符号化を示している。lossless_geometryの値は、１に等しい場合に、ポイントクラウドジオメトリ情報が可逆的に符号化されることを示す。lossless_geometryの値は、ゼロに等しい場合に、ポイントクラウドジオメトリ情報が非可逆的な方法で符号化されることを示す。lossless_textureは、可逆なテクスチャ符号化を示している。lossless_textureの値は、１に等しい場合に、ポイントクラウドテクスチャ情報が可逆的に符号化されることを示す。lossless_textureの値は、ゼロに等しい場合に、ポイントクラウドテクスチャ情報が非可逆的な方法で符号化されることを示す。lossless_geometry_444は、ジオメトリフレームについて、4:2:0または4:4:4ビデオ形式のいずれを使用するかを示している。lossless_geometry_444の値は、１に等しい場合に、ジオメトリビデオが4:4:4フォーマットで符号化されことを示す。lossless_geometry_444の値は、ゼロに等しい場合に、ジオメトリビデオが4:2:0フォーマットで符号化されることを示す。

absolute_d1_codingは、投影面に最も近いレイヤ以外のジオメトリレイヤがどのように符号化されるかを示している。absolute_d1_codingは、１に等しい場合に、実際のジオメトリ値が投影面に最も近いレイヤ以外のジオメトリレイヤに対して符号化されていることを示す。absolute_d1_codingは、ゼロに等しい場合に、投影面に最も近いレイヤ以外のジオメトリレイヤが差動的に（differentially）符号化されることを示す。bin_agithmetic_codingは、バイナリ算術符号化（arithmetic coding）が使用されるか否かを示している。bin_agithmetic_codingの値は、１に等しい場合に、全てのシンタックス要素についてバイナリ算術符号化が使用されることを示す。bin_agithmetic_codingの値は、ゼロに等しい場合に、いくつかのシンタックス要素について非バイナリ算術符号化が使用されることを示す。gof_header_extension_flagは、ゼロに等しい場合に、gof_header_extension_data_flagシンタックス要素がフレームヘッダRBSPシンタックス構造のグループに存在しないことを指定する。gof_header_extension_flagは、1と等しい場合に、gof_header_extension_data_flagシンタックス要素がフレームヘッダRBSPシンタックス構造のグループに存在することを指定する。デコーダは、フレームグループヘッダNALユニット内のgof_header_extension_flagの値に続く全てのデータを無視し得る。gof_header_extension_data_flagは、任意の値を有してよく、そして、フラグの存在および値は、デコーダの適合性に影響しない。デコーダは、全てのgof_header_extension_data_flagシンタックス要素を無視し得る。

PCCプロファイルおよびレベルセマンティクスは、以下の通りである。pcc_profile_idcは、CPSが準拠するプロファイルを示している。pcc_pl_reserved_zero_19bitsは、本開示のこのバージョンに準拠するビットストリームにおいてゼロに等しい。pcc_pl_reserved_zero_19bitsに対する他の値は、ISO/IECによる将来の使用のために予約されている。デコーダはpcc_pl_reserved_zero_19bitsの値を無視し得る。pcc_level_idcは、CPSが準拠するレベルを示している。hevc_ptl_12bytes_attribute[i]は、サブビットストリーム抽出プロセスによって指定されるように抽出されたattribute_type[i]に等しいPCC属性タイプに対するHEVCビットストリームが、準拠するHEVCデコーダによって復号化される場合に、アクティブシーケンスパラメータセット（SPS）において、general_profile_idcからgeneral_level_idcまで、を含む、12バイトの値に等しくてよい。
サブビットストリーム抽出プロセスによって指定されるように抽出されたattribute_type[i]に等しいPCC属性タイプのAVCビットストリームが、準拠するAVCデコーダによって復号化された場合に、avc_pl_3ytes_attribute[i]は、アクティブSPSにおいて、profile_idcからlevel_idcまで、を含む、３バイトの値に等しくてよい。

サブビットストリーム抽出プロセスは、以下の通りである。このプロセスに対する入力は、PCCビットストリーム inBitstream、ターゲットPCC属性タイプ targetAttrType、および、ターゲットPCCストリームID値 targetStreamIdである。このプロセスの出力は、サブビットストリームである。適合しているPCCビットストリーム inBitstream、inBitstream内に存在する任意のタイプのPCC属性を示すtargetAttrType、および、属性タイプ targetAttrTypeに対するinBitstream内に存在するPCCストリームの最大PCCストリームID値以下のtargetStreamIdを用いて、この節において規定されたプロセスの出力である任意の出力サブビットストリームが、属性タイプ targetAttrTypeについて識別されたビデオコーデック仕様ごとに適合しているビデオビットストリームであるべきことは、入力ビットストリームに対するビットストリーム適合性の要件であり得る。

出力サブビットストリームは、以下の順序付けられたステップによって導出される。targetAttrTypeの値に応じて、以下が適用される。targetAttrTypeがATTR_GEOMETRYに等しい場合には、PCC NALUnitTypeがGMTRY_NALUに等しくないか、または、pcc_stream_idがtargetStreamIdに等しくない、全てのPCC NALユニットが削除される。そうでなければ、targetAttrTypeがATTR_TEXTUREに等しい場合には、PCC NALUnitTypeがTEXTURE_NALUに等しくないか、または、pcc_stream_idがtargetStreamIdに等しくない、全てのPCC NALユニットが削除される。さもなければ、targetAttrTypeがATTR_REFLECTに等しい場合には、PCC NALUnitTypeがREFLECT_NALUに等しくないか、または、pcc_stream_idがtargetStreamIdに等しくない、全てのPCC NALユニットが削除される。そうでなければ、targetAttrTypeがATTR_TRANSPに等しい場合には、PCC NALUnitTypeが
TRANSP_NALUに等しくないか、または、pcc_stream_idがtargetStreamIdに等しくない、全てのPCC NALユニットが削除される。さもなければ、targetAttrTypeがATTR_NORMALに等しい場合には、PCC NALUnitTypeがNORMAL_NALUに等しくないか、または、pcc_stream_idがtargetStreamIdに等しくない、全てのPCC NALユニットが削除される。各PCC NALユニットについて、第1のバイトも、また、削除される。

上記で要約された方法の第１セットに係る代替的な実施形態において、PCC NALユニットヘッダは、pcc_stream_idについて、より多くのビットを使用し、かつ、各属性について、４つ以上のストリームを許容するように設計されている。その場合には、PCC NALユニットのヘッダに対して、さらに１つのタイプを追加する。

図8は、ストリームによってPCC属性を順序付けるメカニズム800を説明する概略図である。例えば、メカニズム800は、PCCビデオストリーム700のNALユニットを組織化（organize）するために使用され得る。従って、メカニズム800は、ポイントクラウド媒体500に基づいて、符号化ポイントクラウド媒体フレーム600から属性を組織化するために使用され得る。かくして、メカニズム800は、ビットストリームを生成するためにエンコーダ300によって、および、ビットストリームを読み出すときにデコーダ400によって使用され得る。従って、メカニズム800は、コーデックシステム200によって使用され、そして、方法100をサポートするために、さらに使用され得る。

メカニズム800は、ここにおいてストリーム順序として示される、PCCフレームに関連付けられた属性ストリームの順序に基づいて、PCC属性が組織化されるようにし得る。さらに、メカニズム800の使用は、attributes_first_ordering_flagをゼロに設定することによって、例えば、GOFヘッダ821において、シグナリングされ得る。

メカニズム800は、GOFヘッダ821、補助情報フレーム822、および占有マップフレーム823を、PCC AUの始まりに配置し得る。そうしたNALユニットは、GOFヘッダ721、補助情報フレーム722、および占有マップフレーム723と、それぞれに、実質的に同様であり得る。メカニズム800は、次いで、各ストリームからの属性を順番に配置し得る。各属性は、ゼロから４つのストリームを有し得る。最も複雑なケースを示すために、各属性について４つのストリームが図8に示されている。具体的に、各属性の第1のストリームは、最初に符号化される。従って、第１ストリームジオメトリNALユニット824、第１ストリームテクスチャNALユニット825、第１ストリーム反射NALユニット826、第１ストリーム透明性NALユニット827、および第１ストリーム法線NALユニット828が、最初に符号化される。そうしたNALユニットは、それぞれに、ジオメトリNALユニット724、テクスチャNALユニット725、反射NALユニット726、透明性NALユニット727、および法線NALユニット728と実質的に同様であり、そして、対応する属性タイプにつて第１のストリームの一部として指定された属性データを含んでいる。

次に、属性ストリームの第２のセットに関連する属性が符号化される。具体的に、第２ストリームジオメトリNALユニット834、第２ストリームテクスチャNALユニット835、第２ストリーム反射NALユニット836、第２ストリーム透明性NALユニット837、および第２ストリーム法線NALユニット838が、第１のストリームの後で符号化される。そうしたアイテムは、第１のストリームからの対応するNALユニットと同様の方法で属性を含んでいるが、第２のストリームの一部として指定されたデータを含んでいる。

次に、属性ストリームの第３のセットに関連する属性が符号化される。具体的に、第３ストリーム形状NALユニット844、第３ストリームテクスチャNALユニット845、第３ストリーム反射NALユニット846、第３ストリーム透明性NALユニット847、および第３ストリーム法線NALユニット848が、第２のストリームの後で符号化される。そうしたアイテムは、第１および第２のストリームからの対応するNALユニットと同様の方法で属性を含んでいるが、第３のストリームの一部として指定されたデータを含んでいる。

最後に、属性ストリームの第４のセットに関連する属性が符号化される。具体的に、第４ストリーム形状NALユニット854、第４ストリームテクスチャNALユニット855、第４ストリーム反射NALユニット856、第４ストリーム透明性NALユニット857、および第４ストリーム法線NALユニット858が、第３のストリームの後で符号化される。そうしたアイテムは、第１、第２、および第３のストリームからの対応するNALユニットと同様の方法で属性を含んでいるが、第４のストリームの一部として指定されたデータを含んでいる。上述のように、属性は４つ未満のストリームを含み得るので、メカニズム800は、最も複雑なケースを示している。従って、指定された属性のストリームは、必要に応じて省略され得る。

図9は、属性によってPCC属性を順序付けるメカニズム900を説明する概略図である。例えば、メカニズム900は、PCCビデオストリーム700のNALユニットを組織化するために使用され得る。従って、メカニズム900は、ポイントクラウド媒体500に基づいて、符号化ポイントクラウド媒体フレーム600からの属性を組織化するために使用され得る。かくして、メカニズム900は、ビットストリームを生成するためにエンコーダ300によって、および、ビットストリームを読み出すときにデコーダ400によって使用され得る。従って、メカニズム900は、コーデックシステム200によって使用され、そして、方法100をサポートするために、さらに使用され得る。

メカニズム900は、ここにおいて属性順序として示される、PCCフレームに関連付けられた属性の順序に基づいて、PCC属性が組織化されるようにし得る。さらに、メカニズム900の使用は、attributes_first_ordering_flagを１に設定することによって、例えば、GOFヘッダ921において、シグナリングされ得る。

メカニズム900は、GOFヘッダ921、補助情報フレーム922、および占有マップフレーム923をPCC AUの始まりに配置し得る。そうしたNALユニットは、GOFヘッダ721、補助情報フレーム722、および占有マップフレーム723と、それぞれに、実質的に同様であり得る。メカニズム900は、次いで、共通の属性を属性内で一緒にグループ化することができる。各属性は、ゼロから４つのストリームを有し得る。最も複雑なケースを示すために、各属性について４つのストリームが図9に示されている。具体的に、ジオメトリ属性の全てのストリームが、最初に符号化される。従って、第１ストリームジオメトリNALユニット924、第２ストリームジオメトリNALユニット934、第３ストリームジオメトリNALユニット944、および第４ストリームジオメトリNALユニット954が、符号化される。そうしたNALユニットは、ジオメトリNALユニット724と実質的に同様であり、そして、対応するストリームによって指定されたジオメトリ属性を含んでいる。

次に、第１ストリームテクスチャNALユニット925、第２ストリームテクスチャNALユニット935、第３ストリームテクスチャNALユニット945、および第４ストリームテクスチャNALユニット955が符号化される。そうしたNALユニットは、テクスチャNALユニット725と実質的に同様であり、そして、対応するストリームによって指定されたテクスチャ属性を含んでいる。次いで、第１ストリーム反射NALユニット926、第２ストリーム反射NALユニット936、第３ストリーム反射NALユニット946、および第４ストリーム反射NALユニット956が、符号化される。そうしたNALユニットは、反射NALユニット726と実質的に同様であり、そして、対応するストリームによって指定された反射率属性を含んでいる。次いで、第１ストリーム透明性NALユニット927、第２ストリーム透明性NALユニット937、第３ストリーム透明性NALユニット947、および第４のストリーム透明性NALユニット957が、符号化される。そうしたNALユニットは、透明性NALユニット727と実質的に同様であり、そして、対応するストリームによって指定された透明性属性を含んでいる。最後に、第１ストリーム法線NALユニット928、第２ストリーム法線NALユニット938、第３ストリーム法線NALユニット948、および第４ストリーム法線NALユニット958が、符号化される。そうしたNALユニットは、法線NALユニット728と実質的に同様であり、そして、対応するストリームによって指定された法線属性を含んでいる。上述のように、属性は４つ未満のストリームを含み得るので、メカニズム900は、最も複雑なケースを示している。従って、指定された属性のストリームは、必要に応じて省略され得る。

図10は、拡張属性セットを用いてPCCビデオシーケンスを符号化する例示的な方法1000に係るフローチャートである。例えば、方法1000は、メカニズム800及び／又は900に従ってデータをビットストリームへと組織化し、そして、GOFヘッダにおいてそうしたメカニズムを指定することができる。さらに、方法1000は、ポイントクラウド媒体500に基づいて、ポイントクラウド媒体フレーム600を符号化することによって、PCCビデオストリーム700を生成し得る。さらに、方法1000は、方法100の符号化ステップを実行しながら、コーデックシステム200及び／又はエンコーダ300によって使用され得る。

方法1000は、ポイントクラウド媒体を含むPCCフレームのシーケンスをエンコーダが受信したときに、開始し得る。エンコーダは、例えば、ユーザコマンドの受信に応答して、そうしたフレームを符号化することを決定し得る。ステップ1001において、エンコーダは、多数のPCCアクセスユニットとして、PCCフレームのシーケンスをビットストリームへと符号化する。

ステップ1003において、エンコーダは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットを、ビットストリームへと符号化する。シーケンスレベルデータユニットは、符号化ビットストリームに含まれるデータを解釈するためにデコーダが使用できるパラメータを含んでいる。シーケンスレベルデータユニットは、根底にあるビデオデータを搬送する任意のデータユニットである（例えば、NALユニット）。シーケンスレベルデータユニットは、ビデオパラメータヘッダ（シーケンスパラメータセット、画像パラメータセット、スライスヘッダ、等といったもの）と区別される。そうしたデータは、シーケンスレベルデータユニットによって搬送される根底にあるビデオの一部だからである。特定の例として、シーケンスレベルデータユニットはGOFヘッダNALユニットであり得る。シーケンスレベルデータユニットは、対応するPCC属性を記述するいくつかのシンタックス要素を含み得る。例えば、シーケンスレベルデータユニットは、ビットストリームで搬送される多数のPCC属性を示す第１シンタックス要素を含み得る。そうしたPCC属性は、ジオメトリ、テクスチャ、および、反射率、透明性、および法線のうち１つ以上、を含み得る。第1シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素として実装され得る。

シーケンスレベルデータユニットは、また、ビットストリーム内で各PCC属性を示す第２シンタックス要素を含み得る。例えば、第２シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素であり得る。さらに、PCCアクセスユニットそれぞれは、PCC属性それぞれについてゼロから４つの属性ストリームを含み得る。シーケンスレベルデータユニットは、また、PCC属性それぞれについて多数のストリームを示す第３シンタックス要素を含み得る。例えば、第３シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる属性要素のための多数のストリームであり得る。シーケンスレベルデータユニットは、また、PCC AU内の属性順序を示す第４シンタックス要素を含み得る。例えば、第４シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる第１の順序付けフラグの属性（attributes first ordering flag）であり得る。第１の順序付けフラグは、対応するPCC AUの中でメカニズム800に従ったストリーム順序で含まれているPCC属性それぞれについてPCC NALユニットを示すように設定され得る。第１の順序付けフラグは、また、対応するPCC AUの中でメカニズム900に従った属性順序で含まれているPCC属性それぞれについてPCC NALユニットを示すようにも設定され得る。加えて、PCCアクセスユニットそれぞれは、PCC属性それぞれについてゼロから４つの属性ストリームを含むので、属性ストリームのうち１つ以上は、非定数のフレームレートを含み得る（例えば、PCCフレームのシーケンスのフレームレートが一定である場合でさえも）。

シーケンスレベルデータユニット内のデータ（GOFヘッダ）は、対応するNALユニットを識別し、かつ、符号化する方法を決定するために、デコーダによって使用され得る。従って、デコーダは、符号化されたPCCフレームのシーケンスおよびシーケンスレベルデータユニット内のシーケンスレベルパラメータに基づいて、PCCフレームの復号化シーケンスの生成をサポートするために、ステップ1005において、ビットストリームを送信し得る。

図11は、拡張属性セットを用いてPCCビデオシーケンスを復号化する例示的な方法1100に係るフローチャートである。例えば、方法1100は、GOFヘッダ内といったシーケンスレベルデータにおけるパラメータを読み出すことによって、符号化順序を決定する際に、メカニズム800及び／又は900に従って、ビットストリームからデータを読み出すことができる。さらに、方法1100は、PCCビデオストリーム700からポイントクラウド媒体フレーム600を復号化することによって、ポイントクラウド媒体500を再構成し得る。さらに、方法1100は、方法100の復号化ステップを実行しながら、コーデックシステム200及び／又はデコーダ400によって使用され得る。

方法1100は、デコーダがPCCビデオデータを含むビットストリームを受信したときに開始され得る。従って、デコーダは、ステップ1101において、多数のPCCアクセスユニットへと組織化されたPCCフレームの符号化シーケンスを含むビットストリームを受信することができる。

ステップ1103で、デコーダは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットを獲得するために、ビットストリームを解析することができる。シーケンスレベルデータユニットは、符号化ビットストリームに含まれるデータを解釈する方法についてデコーダに指示するパラメータを含んでいる。具体的な例として、シーケンスレベルデータユニットは、GOFヘッダNALユニットであり得る。シーケンスレベルデータユニットは、対応するPCC属性を記述するいくつかのシンタックス要素を含み得る。例えば、シーケンスレベルデータユニットは、ビットストリームで搬送される多数のPCC属性を示す第１のシンタックス要素を含み得る。そうしたPCC属性は、ジオメトリ、テクスチャ、および、反射率、透明性、および法線のうち１つ以上を含み得る。第１のシンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素として実装され得る。

シーケンスレベルデータユニットは、また、ビットストリーム中のPCC属性それぞれを示す第２シンタックス要素も含み得る。例えば、第２シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素であり得る。さらに、PCCアクセスユニットそれぞれは、PCC属性それぞれについてゼロから４つの属性ストリームを含み得る。シーケンスレベルデータユニットは、また、PCC属性それぞれについて多数のストリームを示す第３シンタックス要素を含み得る。例えば、第３シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる属性要素に対する多数のストリームであり得る。シーケンスレベルデータユニットは、また、PCC AU内の属性順序を示す第４シンタックス要素を含み得る。例えば、第４シンタックス要素は、ビットストリーム内のフレームグループヘッダに含まれる第１の順序付けフラグの属性であり得る。第１の順序付けフラグは、対応するPCC AUの中でメカニズム800に従ったストリーム順序で含まれているPCC属性それぞれについてPCC NALユニットを示すように設定され得る。第１の順序付けフラグは、また、対応するPCC AUの中でメカニズム900に従った属性順序で含まれているPCC属性それぞれについてPCC NALユニットを示すようにも設定され得る。加えて、PCCアクセスユニットそれぞれは、PCC属性それぞれについてゼロから４つの属性ストリームを含むので、属性ストリームのうち１つ以上は、非定数のフレームレートを含み得る（例えば、PCCフレームのシーケンスのフレームレートが一定である場合でさえも）。

デコーダは、どのデータがどのNALユニットに含まれるかを決定するために、シーケンスレベルデータユニットのシンタックス要素を読み出すことができる。従って、デコーダは、ステップ1105において、PCCフレームの復号化シーケンスを生成するために、シーケンスレベルデータユニット内のシーケンスレベルパラメータに基づいて、PCCフレームの符号化シーケンスを復号化することができる。

図12は、例示的なビデオ符号化装置1200の概略図である。ビデオ符号化装置1200は、ここにおいて説明されるように、開示される実施例／実施形態を実装するのに適している。ビデオ符号化装置1200は、下流ポート1220、上流ポート1250、及び／又は、ネットワークにわたり上流及び／又は下流でデータを通信するための送信器及び／又は受信器を含む、トランシーバユニット（Tx/Rx）1210を含んでいる。ビデオ符号化装置1200は、また、データを処理するための論理演算装置及び／又は中央処理装置（CPU）を含むプロセッサ1230、および、データを保管するためのメモリ1232を含んでいる。ビデオ符号化装置1200は、また、光または無線通信ネットワークを介したデータ通信のために、上流ポート1250及び／又は下流ポート1220に結合された、光－電気（OE）コンポーネント、電気－光（EO）コンポーネント、及び／又は、無線通信コンポーネントを含み得る。ビデオ符号化装置1200は、また、ユーザに対して、および、ユーザからデータを通信するための入力及び／又は出力（I/O）デバイス1260も含み得る。I/Oデバイス1260は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカ、等といった、出力装置を含み得る。I/Oデバイス1260は、また、キーボード、マウス、トラックボール、等といった入力装置、及び／又は、そうした出力装置とインタラクションするための対応するインターフェイスを含み得る。

プロセッサ1230は、ハードウェアおよびソフトウェアによって実装されている。プロセッサ1230は、１つ以上のCPUチップ、コア（例えば、マルチコアプロセッサとして）、フィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）、およびデジタル信号プロセッサ（DSP）として実装され得る。プロセッサ1230は、下流ポート1220、Tx/Rx1210、上流ポート1250、およびメモリ1232と通信する。プロセッサ1230は、符号化モジュール1214を含んでいる。符号化モジュール1214は、方法100、1000、1100、1400、および1500、並びに、メカニズム800および900といった、上述の開示された実施形態を実施する。これらは、ポイントクラウド媒体500、ポイントクラウド媒体フレーム600、及び／又は、PCCビデオストリーム700及び／又はここにおいて記載される任意の他の方法／メカニズムを使用し得る。さらに、符号化モジュール1214は、コーデックシステム200、エンコーダ300、及び／又は、デコーダ400を実装し得る。例えば、符号化モジュール1214は、PCCのための拡張属性セットを使用することができ、そして、シーケンスレベルデータにおける対応するストリーム使用と共に、そうした属性セットの使用をシグナリングすることができる。従って、符号化モジュール1214は、PCCビデオデータを符号化するときに、追加的な機能性及び／又は柔軟性を、ビデオ符号化装置1200に提供させる。かくして、符号化モジュール1214は、ビデオ符号化装置1200の機能性を改善し、並びに、ビデオ符号化技術に特有の問題に対処する。さらに、符号化モジュール1214は、ビデオ符号化装置1200の異なる状態への変換をもたらす。代替的に、符号化モジュール1214は、メモリ1232に保管された命令として実装され、そして、プロセッサ1230によって実行され得る（例えば、非一時的な媒体上に保管されたコンピュータプログラム製品として）。

メモリ1232は、ディスク、テープドライブ、ソリッドステートドライブ、リードオンリーメモリ（ROM）、ランダムアクセスメモリ（RAM）、フラッシュメモリ、三値連想メモリ（Ternary Content Addressable Memory、TCAM）、スタティックランダムアクセスメモリ（SRAM）、等といった、１つ以上のメモリタイプを含んでいる。メモリ1232は、オーバーフローデータ記憶装置として使用されてよく、そうしたプログラムが実行のために選択されたときにプログラムを保管し、そして、プログラム実行中に読み出された命令およびデータを保管する。

図13は、拡張属性セットを用いてPCCビデオシーケンスを符号化するための一つの例示的なシステム1300に係る概略図である。システム1300は、一連のPCCフレームを、多数のPCCアクセスユニットとして、ビットストリームへと符号化するためのフレーム符号化モジュール1301を有する、ビデオエンコーダ1302を含んでいる。ビデオエンコーダ1302は、さらに、シーケンスレベルパラメータを含むシーケンスレベルデータユニットを、ビットストリームへと符号化するためのパラメータ符号化モジュール1303を含む。ここで、シーケンスレベルデータユニットは、ビットストリームで搬送される多数のPCC属性を示す第１シンタックス要素、および、PCC属性それぞれを示す第２シンタックス要素を含んでいる。ビデオエンコーダ1302は、さらに、ビットストリームを送信するための送信モジュール1305を含み、符号化PCCフレームのシーケンスおよびシーケンスレベルデータユニット内のシーケンスレベルパラメータに基づいて、PCCフレームの復号化シーケンスの生成をサポートする。ビデオエンコーダ1302のモジュールは、また、方法1000及び／又は1400に関して上述したステップ／アイテムのいずれかを実行するためにも、使用され得る。

システム1300は、また、多数のPCCアクセスユニットへと組織化されたPCCフレームの符号化シーケンスを含むビットストリームを受信するための受信モジュール1311を有する、ビデオデコーダ1310も含んでいる。ビデオデコーダ1310は、また、シーケンスレベルパラメータを含むシーケンスレベルデータユニットを獲得するようにビットストリームを解析するための解析モジュール1313を含み、ここで、シーケンスレベルデータユニットは、ビットストリームで搬送される多数のPCC属性を示す第１シンタックス要素、および、PCC属性それぞれを示す第２シンタックス要素を含む。ビデオデコーダ1310は、また、PCCフレームの復号化シーケンスを生成するために、シーケンスレベルデータユニット内のシーケンスレベルパラメータに基づいて、PCCフレームの符号化シーケンスを復号化するための復号化モジュール1315も含んでいる。ビデオデコーダ1310のモジュールは、また、方法1100及び／又は1500に関して上述したステップ／アイテムのいずれかを実行するためにも、使用され得る。

図14は、拡張属性セットを用いてPCCビデオシーケンスを符号化する別の例示的な方法1400に係るフローチャートである。例えば、方法1400は、メカニズム800及び／又は900に従って、データをビットストリームへと組織化し、そして、GOFヘッダ内でそうしたメカニズムを指定することができる。さらに、方法1400は、ポイントクラウド媒体500に基づいてポイントクラウド媒体フレーム600を符号化することによって、PCCビデオストリーム700を生成し得る。さらに、方法1400は、方法100の符号化ステップを実行しながら、コーデックシステム200及び／又はエンコーダ300によって使用され得る。

ステップ1401においては、PCCフレームのシーケンスがビットストリームへと符号化される。PCCフレームのシーケンスは、複数のPCC属性を表している。PCC属性は、ジオメトリおよびテクスチャを含んでいる。PCC属性は、また、反射率、透明性、および法線のうち１つ以上を含んでいる。各PCCフレームは、多数のPCC NALユニットにおいて符号化される。ステップ1403においては、PCC NALユニットそれぞれに対する指示が符号化される。この指示は、PCC NALユニットそれぞれが、対応するPCC属性のうち１つに属するか否かを示している。さらに、PCC NALユニットがPCC属性に属している場合に、この指示は、どのPCC属性にPCC NALユニットが属しているかを示している。ステップ1405においては、ビットストリームが、ビデオデコーダへ向けて送信される。

図15は、拡張属性セットを用いてPCCビデオシーケンスを復号化する一つの例示的な方法1500である。例えば、方法1500は、符号化順序を決定する際に、GOFヘッダ内といったシーケンスレベルデータにおけるパラメータを読み出すことによって、メカニズム800及び／又は900に従って、ビットストリームからデータを読み出すことができる。さらに、方法1500は、PCCビデオストリーム700からポイントクラウド媒体フレーム600を復号化することによって、ポイントクラウド媒体500を再構成することができる。さらに、方法1500は、方法100の復号化ステップを実行しながら、コーデックシステム200及び／又はデコーダ400によって使用され得る。

ステップ1501においては、ビットストリームが受信される。ビットストリームは、複数のPCCフレームの符号化シーケンスを含んでいる。複数のPCCフレームの符号化シーケンスは、複数のPCC属性を表している。PCC属性は、ジオメトリおよびテクスチャを含んでいる。PCC属性は、また、反射率、透明性、および法線のうち１つ以上を含んでいる。各符号化PCCフレームは、１つ以上のPCC NALユニットによって表される。ステップ1503においては、PCC NALユニットそれぞれについて指示を獲得するために、ビットストリームが解析される。この指示は、PCC NALユニットそれぞれが、対応するPCC属性のうち１つに属するか否かを示している。さらに、PCC NALユニットがPCC属性に属している場合に、この指示は、どのPCC属性にPCC NALユニットが属しているかを示している。ステップ1505においては、ビットストリームが、指示に基づいて復号化される。

第１コンポーネントは、第１コンポーネントと第２コンポーネントとの間のライン、トレース、または別の媒体を除いて、介在するコンポーネントが存在しない場合に、第２コンポーネントに対して直接的に結合されている。第１コンポーネントは、第１コンポーネントと第２コンポーネントとの間にライン、トレース、または別の媒体以外の介在するコンポーネントが存在する場合に、第２コンポーネントに対して間接的に結合されている。用語「結合された（“coupled”）」およびその変形は、直接的な結合および間接的な結合の両方を含んでいる。用語「約（“about”）」の使用は、特に明記されない限り、後に続く数の±10%を含む範囲を意味するものである。

本開示において、いくつかの実施形態が提供されてきたが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の特定の形態において実施され得ることが理解されるだろう。本実施例は、説明的なものであり、かつ、限定的なものではないものと考えられる。そして、その意図は、ここにおいて与えられた詳細に限定されるものではない。例えば、種々の要素またはコンポーネントが、別のシステムにおいて組み合わされ又は統合され得る。もしくは、所定の特徴が省略され、または、実装されなくてよい。

加えて、様々な実施形態において、個別または分離して記載および図示された技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、コンポーネント、技術、または方法と組み合わされ、または、統合され得る。変更、置換、および改変の他の例は、当業者によって確認可能であり、かつ、ここにおいて開示された精神および範囲から逸脱することなく行うことができる。

Claims (27)

1. デコーダによって実装される方法であって、前記方法は、
   前記デコーダによって、複数のポイントクラウド符号化（ＰＣＣ）フレームの符号化シーケンスを含むビットストリームを受信するステップであり、
   前記複数のＰＣＣフレームの符号化シーケンスは、ジオメトリ、テクスチャ、および、反射率、透明度、法線のうち１つ以上、を含む、複数のＰＣＣ属性を表しており、かつ、
   各符号化ＰＣＣフレームは、１つ以上のＰＣＣネットワーク抽象化レイヤ（ＮＡＬ）ユニットによって表される、ステップと、
   前記デコーダによって、前記ビットストリームを解析するステップであり、
   前記ＰＣＣ ＮＡＬユニットそれぞれが、前記ＰＣＣ属性のうち対応する１つに属するか否か、および、
   前記ＰＣＣ ＮＡＬユニットが対応する前記ＰＣＣ属性に属する場合に、どのＰＣＣ属性に前記ＰＣＣ ＮＡＬユニットが属しているか、
   を示す指示を、前記ＰＣＣ ＮＡＬユニットそれぞれについて獲得する、ステップと、
   前記デコーダによって、前記指示に基づいて、前記ビットストリームを復号化するステップと、
   を含む、方法。
2. ＰＣＣフレームの各符号化シーケンスは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットと関連付けられており、かつ、
   前記シーケンスレベルデータユニットは、前記ＰＣＣフレームの符号化シーケンスにおいて搬送される多数のＰＣＣ属性を示す第１シンタックス要素、および、前記ＰＣＣ属性それぞれを示す第２シンタックス要素を含む、
   請求項１に記載の方法。
3. 前記第２シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素である、
   請求項２に記載の方法。
4. 前記第１シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素である、
   請求項２または３に記載の方法。
5. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれについて多数のストリームを示す第３シンタックス要素を含む、
   請求項２乃至４いずれか一項に記載の方法。
6. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれに対するＰＣＣネットワーク抽象化レイヤユニットが、対応するＰＣＣアクセスユニットの中にストリーム順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む、
   請求項２乃至５いずれか一項に記載の方法。
7. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれに対するＰＣＣネットワーク抽象化レイヤユニットが、対応するＰＣＣアクセスユニットの中に属性順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む、
   請求項２乃至６いずれか一項に記載の方法。
8. 前記ＰＣＣアクセスユニットそれぞれは、前記ＰＣＣ属性それぞれについてゼロから４つの属性ストリームを含み、かつ、
   前記属性ストリームの少なくとも１つは、非定数フレームレートを含む、
   請求項６または７に記載の方法。
9. 前記方法は、さらに、
   前記デコーダによって、前記ビットストリームからのＰＣＣフレームの復号化シーケンスを、提示のためにディスプレイへ向けて転送するステップ、を含む、
   請求項２乃至８いずれか一項に記載の方法。
10. エンコーダによって実装される方法であって、前記方法は、
    前記エンコーダによって、複数のポイントクラウド符号化（ＰＣＣ）フレームの符号化シーケンスをビットストリームへと符号化するステップであり、
    前記ＰＣＣフレームの符号化シーケンスは、ジオメトリ、テクスチャ、および、反射率、透明度、法線のうち１つ以上、を含む、複数のＰＣＣ属性を表しており、かつ、
    各ＰＣＣフレームは、数多くのＰＣＣネットワーク抽象化レイヤ（ＮＡＬ）ユニット内で符号化される、ステップと、
    前記エンコーダによって、前記ＰＣＣ ＮＡＬユニットそれぞれについて指示を符号化するステップであり、前記指示は、
    前記ＰＣＣ ＮＡＬユニットそれぞれが、前記ＰＣＣ属性のうち対応する１つに属するか否か、および、
    前記ＰＣＣ ＮＡＬユニットが対応する前記ＰＣＣ属性に属する場合に、どのＰＣＣ属性に前記ＰＣＣ ＮＡＬユニットが属しているか、
    を示す、ステップと、
    前記エンコーダによって、前記ビットストリームをデコーダへ向けて送信する、ステップと、
    を含む、方法。
11. 前記ビットストリームは、シーケンスレベルパラメータを含むシーケンスレベルデータユニットと関連付けられており、かつ、
    前記シーケンスレベルデータユニットは、前記ビットストリームにおいて搬送される多数のＰＣＣ属性を示す第１シンタックス要素、および、前記ＰＣＣ属性それぞれを示す第２シンタックス要素を含む、
    請求項１０に記載の方法。
12. 前記第２シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる属性タイプ要素である、
    請求項１１に記載の方法。
13. 前記第１シンタックス要素は、前記ビットストリーム内のフレームグループヘッダに含まれる多数の属性要素である、
    請求項１１または１２に記載の方法。
14. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれについて多数のストリームを示す第３シンタックス要素を含む、
    請求項１１乃至１３いずれか一項に記載の方法。
15. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれに対するＰＣＣネットワーク抽象化レイヤユニットが、対応するＰＣＣアクセスユニットの中にストリーム順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む、
    請求項１１乃至１４いずれか一項に記載の方法。
16. 前記ビットストリーム内のフレームグループヘッダは、前記ＰＣＣ属性それぞれに対するＰＣＣネットワーク抽象化レイヤユニットが、対応するＰＣＣアクセスユニットの中に属性順序で含まれていること、を示すために設定された属性第１順序付けフラグを含む、
    請求項１１乃至１５いずれか一項に記載の方法。
17. 前記ＰＣＣアクセスユニットそれぞれは、前記ＰＣＣ属性それぞれについてゼロから４つの属性ストリームを含み、かつ、
    前記属性ストリームの少なくとも１つは、非定数フレームレートを含む、
    請求項１５または１６に記載の方法。
18. ビットストリームの形式でビデオデータを保管するように構成された、非一時なメモリストレージと、
    請求項１乃至９いずれか一項に記載の方法を実行するように構成された、デコーダと、
    を含む、ビデオデータ復号化装置。
19. ビットストリームの形式でビデオデータを保管するように構成された、非一時なメモリストレージと、
    請求項１０乃至１７いずれか一項に記載の方法を実行するように構成された、エンコーダと、
    を含む、ビデオデータ符号化装置。
20. コンピュータプログラムであって、
    非一時的なコンピュータで読取り可能な媒体に保管されたコンピュータ実行可能命令を含み、
    前記コンピュータの１つ以上のプロセッサによって実行されるとき、前記１つ以上のプロセッサに、請求項１乃至１７いずれか一項に記載の方法を実行するようにさせる、
    コンピュータプログラム。
21. 請求項１乃至９いずれか一項に記載の方法を実行するための処理回路を備える、デコーダ。
22. 請求項１０乃至１７いずれか一項に記載の方法を実行するための処理回路を備える、エンコーダ。
23. 複数のコンピュータ実行可能命令を保管する非一時的なコンピュータで読取り可能な記憶媒体であって、
    前記コンピュータ実行可能命令が、前記コンピュータの１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、請求項１乃至１７いずれか一項に記載の方法を実行させる、
    非一時的なコンピュータで読取り可能な記憶媒体。
24. エンコーダであって、
    ポイントクラウド符号化（ＰＣＣ）フレームのシーケンスをビットストリームへと符号化するためのフレーム符号化手段であり、
    前記ＰＣＣフレームのシーケンスは、ジオメトリ、テクスチャ、および、反射率、透明度、法線のうち１つ以上、を含む、複数のＰＣＣ属性を表しており、かつ、
    各ＰＣＣフレームは、数多くのＰＣＣネットワーク抽象化レイヤ（ＮＡＬ）ユニットにおいて符号化される、フレーム符号化手段と、
    前記ＰＣＣ ＮＡＬユニットそれぞれについて指示を符号化するためのパラメータ符号化手段であり、前記指示は、
    前記ＰＣＣ ＮＡＬユニットそれぞれが、前記ＰＣＣ属性のうち対応する１つに属するか否か、および、
    前記ＰＣＣ ＮＡＬユニットが対応する前記ＰＣＣ属性に属する場合に、どのＰＣＣ属性に前記ＰＣＣ ＮＡＬユニットが属しているか、
    を示す、パラメータ符号化手段と、
    前記ビットストリームをデコーダへ向けて送信するための、送信手段と、
    を含む、エンコーダ。
25. 前記エンコーダは、さらに、
    請求項１０乃至１７いずれか一項に記載の方法を実行するように構成されている、
    請求項２４に記載のエンコーダ。
26. デコーダであって、
    複数のポイントクラウド符号化（ＰＣＣ）フレームの符号化シーケンスを含むビットストリームを受信するための受信手段であり、
    前記複数のＰＣＣフレームの符号化シーケンスは、ジオメトリ、テクスチャ、および、反射率、透明度、法線のうち１つ以上、を含む、複数のＰＣＣ属性を表しており、かつ、
    各符号化ＰＣＣフレームは、１つ以上のＰＣＣネットワーク抽象化レイヤ（ＮＡＬ）ユニットによって表される、受信手段と、
    前記ＰＣＣ ＮＡＬユニットそれぞれに対する指示を獲得するように、前記ビットストリームを解析するための解析手段であり、前記指示は、
    前記ＰＣＣ ＮＡＬユニットそれぞれが、前記ＰＣＣ属性のうち対応する１つに属するか否か、および、
    前記ＰＣＣ ＮＡＬユニットが対応する前記ＰＣＣ属性に属する場合に、どのＰＣＣ属性に前記ＰＣＣ ＮＡＬユニットが属しているか、
    を示す、解析手段と、
    前記指示に基づいて、前記ビットストリームを復号化するための符号化手段と、
    を含む、デコーダ。
27. 前記デコーダは、さらに、
    請求項１乃至９いずれか一項に記載の方法を実行するように構成されている、
    請求項２６に記載のデコーダ。

Images