JP7209832B2

JP7209832B2 - ビデオシーケンスを復号するための方法、装置、コンピュータプログラム、およびビデオ符号化方法

Info

Publication number: JP7209832B2
Application number: JP2021527050A
Authority: JP
Inventors: ビョンドゥ・チェ; ステファン・ヴェンガー; シャン・リュウ
Original assignee: テンセント・アメリカ・エルエルシー
Priority date: 2018-12-14
Filing date: 2019-12-11
Publication date: 2023-01-20
Anticipated expiration: 2039-12-11
Also published as: CN112868184A; US10812818B2; EP3895322A1; KR102592985B1; EP3895322B1; WO2020123598A1; CN112868184B; US20200195946A1; EP3895322A4; KR20210069716A; JP2022507673A

Description

関連出願の相互参照
本出願は、米国特許商標庁に2018年12月14日に出願された米国仮特許出願第62／780，148号、2018年12月14日に出願された米国仮特許出願第62／780，154号、2019年1月2日に出願された米国仮特許出願第62／704，039号および2019年5月6日に提出された米国特許出願第16／403，786号に対して米国特許法第119条に基づく優先権を主張するもので、参照によりその全体が本明細書に組み込まれる。

開示された主題は、ビデオコーディングおよび復号に関し、より具体的には、NALUタイプクラスを含むネットワーク抽象化層（NAL）ユニット（NALU）ヘッダのコーディングに関する。

動き補償を伴うピクチャ間予測を使用したビデオコーディングおよび復号は、何十年もの間知られている。非圧縮デジタルビデオは、一連のピクチャで構成でき、各ピクチャは、例えば、1920 x 1080の輝度サンプルおよび関連するクロミナンスサンプルの空間次元を有している。一連のピクチャは、例えば毎秒60枚または60 Hzの固定または可変のピクチャレート（非公式にはフレームレートとしても知られている）を有し得る。非圧縮ビデオは、かなりのビットレート要件を有している。例えば、サンプルあたり8ビットの1080p60 4：2：0ビデオ（60 Hzフレームレートで1920x1080の輝度サンプル解像度）は、1．5 Gビット／秒に近い帯域幅を必要とする。1時間のこのようなビデオは、600Gバイトを超えるストレージスペースを必要とする。

ビデオコーディングおよび復号の目的の1つは、圧縮を通して入力ビデオ信号の冗長性を削減し得ることである。圧縮は、前述の帯域幅またはストレージスペースの要件を、場合によっては2桁以上削減するのに役立ち得る。可逆と非可逆圧縮の両方、ならびにそれらの組み合わせが採用され得る。可逆圧縮とは、圧縮された元の信号から元の信号の正確なコピーが再構築し得る技術を指す。非可逆圧縮を使用するとき、再構築された信号は元の信号と同一ではない場合があるが、元と再構成された信号との歪みは十分に小さいため、再構築された信号は目的のアプリケーションで役立つようになる。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量は、アプリケーションによって異なり、例えば、特定の消費者向けストリーミングアプリケーションのユーザは、テレビ配信アプリケーションのユーザよりも高い歪みを許容し得る。達成可能な圧縮比は、許容できる／許容可能な歪みが大きいほど、圧縮比が高くなる場合があることを反映できる。

ビデオエンコーダおよびデコーダは、例えば、動き補償、変換、量子化、およびエントロピーコーディングを含むいくつかの広いカテゴリからの技術を利用することができ、それらのいくつかが以下に紹介されている。

ネットワーク抽象化層の概念は、ITU－TRec．H．264で導入された。コード化されたビデオビットストリームは、ネットワーク抽象化層（NAL－）ユニットと呼ばれる個々のユニットに分割され得る。各NALユニットは、コードエミュレーション防止を開始するために順守せずに解釈できるヘッダを持つことができる（そうではない場合、NALユニットの他の部分で、潜在的にかなりの実装および計算コストで順守する必要がある）。H．264（101）のNALユニットヘッダは、図1に示すように、固定長コードワードのみが含まれるように設計されている。nal＿unit＿type（102）の特定の値については、NALユニットヘッダ（103）の特定の拡張機能が、第2、場合によっては第3のオクテットを追加することによって利用でき、各オクテットは固定長コードワードも含んでいた。メディア対応ネットワーク要素（MANE）、MCU、ファイルリライターなどは、これらの固定長コードワードを利用して、完全なトランスコーディングなしで、および開始コードエミュレーションの防止による制約を受けることなく、ビットストリームを効果的に調整できる。

H．265では、やや簡略化された設計が選択された。H．265 NALユニットヘッダ（104）は、2オクテットで固定長であり、NALユニットタイプ（105）、空間／SNR層ID（106）、および時間層ID（107）が含まれていた。拡張メカニズムは存在しなかった。H．264設計と比較すると、この設計は一定のコーディング効率のペナルティを有していた。なぜならば、可変長であるが多くの場合1オクテット長であるH．264設計と比較して、ヘッダは常に2オクテットの長さであったためである。他方、スケーラブルおよびマルチビュー拡張のサポートは大幅に簡素化され、スケーラブル／マルチビューと非スケーラブル／マルチビューのレガシー符号化との特定の下位互換性が可能になった。

さらに、コード化されたビデオビットストリームをパケットに分割してパケットネットワーク上で転送するという概念は、何十年にもわたって使用されてきた。初期の頃、ビデオコーディングの規格と技術は、ほとんどがビット指向のトランスポート用に最適化されており、ビットストリームが定義されていた。パケット化は、例えばリアルタイムトランスポートプロトコル（RTP－）ペイロード形式で指定されたシステム層インターフェースで発生した。インターネットを介したビデオの大量使用に適したインターネット接続の出現により、ビデオコーディング規格は、ビデオコーディング層（VCL）とネットワーク抽象化層（NAL）の概念的な差別化を通じて、その卓越したユースケースを反映した。NALユニットは2003年にH．264で導入され、それ以降、わずかな変更を加えるだけで、特定のビデオコーディング規格および技術で保持されている。

NALユニットは、多くの場合、コード化されたビデオシーケンスの先行するすべてのNALユニットを必ずしも復号しなくても、デコーダが作用できる最小のエンティティと見なされ得る。これまでのところ、NALユニットは、選択的転送ユニット（SFU）またはマルチポイント制御ユニット（MCU）などのメディア対応ネットワーク要素（MANE）による、ビットストリームプルーニングを含む、特定のエラー回復技術ならびに特定のビットストリーム操作技術を可能にする。

図1は、H．264（101）およびH．265（104）による、それぞれの拡張がいずれもない、NALユニットヘッダの構文図の該当部分を図示している。どちらの場合も、forbidden＿zero＿bit（108、109）は、特定のシステム層環境での開始コードエミュレーション防止に使用されるゼロビットである。nal＿unit＿type（102、105）構文要素は、NALユニットが搬送するデータのタイプを参照し、これは、例えば、特定のスライスタイプ、パラメータ集合タイプ、補足拡張情報（SEI－）メッセージなどのいずれかであり得る。H．265 NALユニットヘッダはnuh＿layer＿id（106）とnuh＿temporal＿id＿plus1（107）でさらに構成され、NALユニットが属するコード化されたピクチャの空間／SNRおよび時間層を示す。

NALユニットヘッダは、簡単に解析できる固定長コードワードのみを含み、それは例えば、他のNALユニットヘッダやパラメータ集合など、ビットストリームの他のデータへの解析依存関係を有していないことが確認され得る。NALユニットヘッダはNALユニットの最初のオクテットであるため、MANEはそれらを簡単に抽出、解析、および操作できる。対照的に、例えば、スライスヘッダまたはタイルヘッダなどの他の高レベルの構文要素は、パラメータ集合のコンテキストの保持、および／または可変長または算術的にコード化されたコードポイントの処理を必要とし得るので、MANEに簡単にはアクセスできない。

さらに、図1に示されるNALユニットヘッダは、NALユニットを、複数のNALユニット（例えば、複数のタイルまたはスライスを含み、少なくともその一部は個々のNALユニットでパケット化されている）から構成されるコード化されたピクチャに関連付けることができる情報を含まないことが確認され得る。

RTP（RFC 3550）、MPEGシステム規格、ISOファイル形式などの特定の転送技術は、特定の情報を含む場合があり、多くの場合、プレゼンテーション時間（MPEGおよびISOファイル形式の場合）、またはMANEによって簡単にアクセスされ得、それぞれのトランスポートユニットをコード化されたピクチャに関連付けるのに役立ち得るキャプチャ時間（RTPの場合）などのタイミング情報の形式である。しかしながら、これらの情報のセマンティクスは、トランスポート／ストレージ技術ごとに異なる可能性があり、ビデオコーディングで使用される画像構造と直接の関係がない場合がある。したがって、これらの情報は、せいぜいヒューリスティックであり得、また、NALユニットストリームのNALユニットが同じコード化されたピクチャに属するかどうかを識別するのに特には適していない場合がある。

さらに、画像またはビデオのコーディングでは、コンポーネントは、xおよびy次元で特定の解像度の2次元マトリックスに通常配置されたサンプル値のコレクションを参照できる。より古い画像およびビデオコーディング技術では、コンポーネントは多くの場合、原色に関連付けられていた。例えば、H．261またはJPEGなどの、より古いビデオまたは画像圧縮規格のいくつかでは、YCrCbカラーモデルが使用され、Y、CR、およびCbは、集合的に3つのコンポーネントを構成する正確に3つの原色であった。4：2：0として知られるサンプリング構造を使用すると、輝度Yコンポーネントの解像度は、色CrおよびCbコンポーネントの解像度のxおよびy次元のそれぞれで2倍であった。これらの関係は、前述のより古い規格および技術にハードコードされている。これらのより古い規格および技術でも、特定のコンポーネントは他のものがなくても役立つ場合がある。例えば、Yコンポーネントは、復号されて分離して表示されるとき、白黒写真、映画、およびTVから知られるタイプの画像とビデオを表す。

MPEG－2およびH．264などのより最新の画像およびビデオコーディング技術ならびに規格は、より多くの他の原色と追加のサンプリング構造をサポートできるため、どのコンポーネントとサンプリング構造が使用中であるかを記述するシーケンスヘッダやパラメータ集合などの高レベルの構文構造にコードポイントを必要とする。

さらに最近では、Versatile Video Coding（VVC）、ポイントクラウドコーディング（PCC）、（表面）ライトフィールドなどの特定の技術が登場し始めている。これらの今後の規格および技術では、色成分以外の成分が関連するようになる。それらの他の成分の例は、透明度、反射率、吸収、3Dジオメトリ情報（XYZ）、占有マップ、表面法線ベクトル、補助情報、深度マップを含み、特定の3D形式では、色成分は観察者の視点に応じて3D空間内の与えられたサンプルに対して異なる場合がある。

本開示の一態様によれば、ビデオシーケンスを復号するための方法は、ネットワーク抽象化層ユニット(NALU)ヘッダに含まれる固定長バイナリコード化されたNALUクラスタイプを復号すること、NALUヘッダのNALUタイプを復号すること、およびピクチャを再構成することを含むものであって、ピクチャのタイプは、NALUクラスタイプとNALUタイプの組み合わせによって識別される。

本開示の一態様によれば、ビデオシーケンスを復号するための装置は、プログラムコードを格納するように構成された少なくとも1つのメモリ、およびプログラムコードを読み取り、プログラムコードによって指示されるように動作するよう構成された少なくとも1つのプロセッサを含み、プログラムコードは、少なくとも1つのプロセッサに、NALUヘッダに含まれる固定長バイナリコード化ネットワーク抽象化層ユニット（NALU）クラスタイプを復号させ、NALUヘッダのNALUタイプを復号させるように構成された復号コード、ならびに少なくとも1つのプロセッサにピクチャを再構築させるように構成された再構築コードを含み、ピクチャのタイプは、NALUクラスタイプとNALUタイプの組み合わせによって識別される。

本開示の一態様によれば、命令を格納する非一時的なコンピュータ可読媒体であって、命令は、装置の1つまたは複数のプロセッサによって実行されると、1つまたは複数のプロセッサに、NALUヘッダに含まれる固定長バイナリコード化ネットワーク抽象化層ユニット（NALU）クラスタイプを復号させ、NALUヘッダのNALUタイプを復号させ、ピクチャを再構成させる1つまたは複数の命令を含み、ピクチャのタイプは、NALUクラスタイプとNALUタイプの組み合わせによって識別される。

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

H．264およびH．265によるNALUヘッダの概略図である。一実施形態による通信システムの簡略化されたブロック図の概略図である。一実施形態による通信システムの簡略化されたブロック図の概略図である。一実施形態によるデコーダの簡略化されたブロック図の概略図である。一実施形態によるエンコーダの簡略化されたブロック図の概略図である。一実施形態による、NALUタイプクラスを使用するNALUヘッダの概略図である。一実施形態による例示的なプロセスのフローチャートである。一実施形態によるpicture＿id構文要素を含むNALユニットヘッダの概略図である。一実施形態による例示的なプロセスのフローチャートである。一実施形態による、様々なコンポーネントまたはコンポーネントグループを搬送するNALユニットの概略図である。一実施形態による、様々なコンポーネントまたはコンポーネントグループを搬送するNALユニットの概略図である。一実施形態による、異なるコンポーネントタイプを有するNALユニットを選択的に転送するシステムの概略図である。一実施形態による、様々なコンポーネントまたはコンポーネントグループを搬送するNALユニットの概略図の構文図である。一実施形態によるコンピュータシステムの概略図である。

解決しようとする課題
H．264 NALユニットヘッダは多くの場合、コンパクトであるが、特定のアプリケーションには不十分である。H．265 NALユニットヘッダは、スケーラビリティとマルチビューを効果的にサポートするが、360ビデオコーディングなどの他の特定の技術はサポートされておらず、長さが2オクテットであるため、他の特定のアプリケーションでは不必要に長くなる。したがって、H．264 NALユニットヘッダのコンパクトさを維持しながら、最新のアプリケーションの効率的なサポートを提供する設計が必要とされる。

図2は、本開示の一実施形態による通信システム（200）の簡略化されたブロック図を示している。システム（200）は、ネットワーク（250）を介して相互接続された少なくとも2つの端末（210～220）を含み得る。データの単方向伝送の場合、第1の端末（210）は、ネットワーク（250）を介して他の端末（220）に伝送するために、ローカルロケーションでビデオデータをコーディングすることができる。第2の端末（220）は、ネットワーク（250）から他の端末のコード化されたビデオデータを受信し、コード化されたデータを復号し、復元されたビデオデータを表示し得る。単方向データ伝送は、メディアサービングアプリケーションなどで一般的であり得る。

図2は、例えば、ビデオ会議中に発生し得るコード化されたビデオの双方向伝送をサポートするために提供される第2のペアの端末（230、240）を示している。データの双方向伝送の場合、各端末（230、240）は、ネットワーク（250）を介して他の端末に伝送するために、ローカルロケーションでキャプチャされたビデオデータをコーディングすることができる。各端末（230、240）はまた、他の端末によって送信されたコード化されたビデオデータを受信し、コード化されたデータを復号し、復元されたビデオデータをローカルディスプレイ装置に表示し得る。

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

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

ストリーミングシステムは、ビデオソース（301）、例えばデジタルカメラを含み得、例えば非圧縮ビデオサンプルストリーム（302）を作成するキャプチャサブシステム（313）を含み得る。そのサンプルストリーム（302）は、符号化されたビデオビットストリームと比較したときに大量のデータを強調するために太線として図示され、カメラ（301）に結合されたエンコーダ（303）によって処理され得る。エンコーダ（303）は、ハードウェア、ソフトウェア、またはそれらの組み合わせを含み、以下により詳細に説明されるように、開示された主題の態様を可能に、または実装し得る。サンプルストリームと比較するとき、より少ないデータ量を強調するために細い線として図示されている符号化されたビデオビットストリーム（304）は、将来の使用のためにストリーミングサーバ（305）に格納され得る。1つまたは複数のストリーミングクライアント（306、308）は、ストリーミングサーバ（305）にアクセスして、符号化されたビデオビットストリーム（304）のコピー（307、309）を取得できる。クライアント（306）は、符号化されたビデオビットストリーム（307）の入ってくるコピーを復号し、ディスプレイ（312）または他のレンダリング装置（図示せず）上でレンダリングされ得る出ていくビデオサンプルストリーム（311）を作成するビデオデコーダ（310）を含み得る。いくつかのストリーミングシステムでは、ビデオビットストリーム（304、307、309）は特定のビデオコーディング／圧縮規格により符号化され得る。それらの規格の例には、ITU－T勧告H．265を含む。開発中のビデオコーディング規格は、非公式にVersatile Video CodingまたはVVCとして知られている。開示された主題は、VVCのコンテキストで使用され得る。

図4は、本開示の一実施形態によるビデオデコーダ（310）の機能ブロック図であり得る。

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

ビデオデコーダ（310）は、エントロピーコード化されたビデオシーケンスからシンボル（421）を再構築するためのパーサー（420）を含み得る。図3に示したように、それらのシンボルのカテゴリは、デコーダ（310）の動作を管理するために使用される情報、およびデコーダの不可欠な部分ではないが、デコーダに結合することができるディスプレイ（312）などのレンダリング装置を制御するための潜在的な情報を含む。レンダリング装置の制御情報は、補足拡張情報（SEIメッセージ）またはビデオユーザビリティ情報（VUI）パラメータ集合フラグメント（図示せず）の形式であり得る。パーサー（420）は、受信したコード化されたビデオシーケンスを解析／エントロピー復号することができる。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術または規格に従うことができ、可変長コーディング、ハフマンコーディング、コンテキスト依存の有無にかかわらず算術コーディングなどを含む当業者によく知られた原則に従うことができる。パーサー（420）は、グループに対応する少なくとも1つのパラメータに基づいて、コード化されたビデオシーケンスから、ビデオデコーダのピクセルのサブグループの少なくとも1つのサブグループパラメータの集合を抽出することができる。サブグループは、Groups of Pictures（GOP）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含み得る。エントロピーデコーダ／パーサーはまた、変換係数、量子化パラメータ値、動きベクトルなどのようなコード化ビデオシーケンス情報から抽出することができる。

パーサー（420）は、バッファ（415）から受信したビデオシーケンスに対してエントロピー復号／構文解析動作を行って、シンボル（421）を作成することができる。

シンボル（421）の再構成は、コード化されたビデオピクチャまたはその一部のタイプ（例えば、ピクチャ間およびピクチャ内、ブロック間およびブロック内）、および他の要因に応じて、複数の異なるユニットを含み得る。どのユニットが、どのように関与するかは、パーサー（420）によってコード化されたビデオシーケンスから解析されたサブグループ制御情報によって制御され得る。パーサー（420）と以下の複数のユニットとのそのようなサブグループ制御情報の流れは、明確性のため、図示しない。

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

第1のユニットはスケーラー／逆変換ユニット（451）である。スケーラー／逆変換ユニット（451）は、量子化された変換係数、ならびに使用する変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報を、パーサー（420）からシンボル（421）として受信する。アグリゲータ（455）に入力できるサンプル値を含むブロックを出力できる。

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

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

アグリゲータ（455）の出力サンプルは、ループフィルタユニット（456）において様々なループフィルタリング技術を受けうる。ビデオ圧縮技術は、コード化されたビデオビットストリームに含まれるパラメータによって制御され、パーサー（420）からのシンボル（421）としてループフィルタユニット（456）に利用可能になるインループフィルタ技術を含むことができるが、コード化されたピクチャまたはコード化されたビデオシーケンスの前の（復号順序の）部分の復号中に取得されたメタ情報に応答することもできるほか、以前に再構築およびループフィルタリングされたサンプル値に応答することもできる。

ループフィルタユニット（456）の出力は、レンダリング装置（312）に出力され得るほか、将来のピクチャ間予測で使用するために参照ピクチャメモリ（456）にも格納され得るサンプルストリームであり得る。

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

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

一実施形態では、受信器（410）は、符号化されたビデオを伴う追加の（冗長な）データを受信しうる。追加のデータは、コード化されたビデオシーケンスの一部として含まれ得る。追加のデータは、データを適切に復号するため、および／または元のビデオデータをより正確に再構築するために、ビデオデコーダ（420）によって使用され得る。追加のデータは、例えば、時間的、空間的、またはSNRエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正コードなどの形式であり得る。

図5は、本開示の一実施形態によるビデオエンコーダ（303）の機能ブロック図であり得る。

エンコーダ（303）は、エンコーダ（303）によってコード化されるビデオ画像をキャプチャすることができるビデオソース（301）（エンコーダの一部ではない）からビデオサンプルを受信することができる。

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

一実施形態によれば、エンコーダ（303）は、リアルタイムで、またはアプリケーションによって必要とされる他の任意の時間制約の下で、ソースビデオシーケンスのピクチャをコーディングしてコード化されたビデオシーケンス（543）に圧縮することができる。適切なコーディング速度を実施することは、コントローラ（550）の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。明確にするために、カップリングは図示していない。コントローラによって設定されるパラメータは、レート制御関連のパラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値など）、画像サイズ、Group of Pictures（GOP）レイアウト、最大動きベクトル探索範囲などを含み得る。当業者は、特定のシステム設計用に最適化されたビデオエンコーダ（303）に関係し得るので、コントローラ（550）の他の機能を容易に識別することができる。

いくつかのビデオエンコーダは、当業者が「コーディング・ループ」として容易に認識するように動作する。非常に単純化された説明として、コーディング・ループは、エンコーダ（530）（以下、「ソースコーダ」）の符号化部分（コード化される入力ピクチャ、および参照ピクチャに基づいてシンボルを作成する役割）、およびシンボルを再構築して、（リモート）デコーダも作成する（シンボルとコード化されたビデオビットストリームとの圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるため）、サンプルデータを作成するエンコーダ（303）に埋め込まれた（ローカル）デコーダ（533）からなり得る。その再構成されたサンプルストリームは、参照ピクチャメモリ（534）に入力される。シンボルストリームの復号により、デコーダのロケーション（ローカルまたはリモート）に関係なくビットが正確な結果が得られるため、参照ピクチャバッファのコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確な結果となる。言い換えると、エンコーダの予測部分は、復号中に予測を使用するときにデコーダが「見る」のとまったく同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期性（および、例えばチャネルエラーのために同期性を維持できない場合に生じるドリフト）のこの基本原理は、当業者によく知られている。

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

現時点で行うことができる観察は、デコーダに存在する解析／エントロピー復号以外のデコーダ技術も、対応するエンコーダに実質的に同一の機能形式で必ず存在する必要があるということである。このため、開示された主題は、デコーダ動作に焦点を合わせている。エンコーダ技術の説明は、包括的に説明されているデコーダ技術の逆であるため、省略され得る。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。

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

ローカルビデオデコーダ（533）は、ソースコーダ（530）によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコード化されたビデオデータを復号することができる。コーディングエンジン（532）の動作は、有利には、非可逆プロセスであり得る。コード化されたビデオデータがビデオデコーダ（図5には示されていない）で復号され得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ（533）は、参照フレーム上でビデオデコーダによって実行され得る復号プロセスを複製し、再構成された参照フレームを参照ピクチャキャッシュ（534）に格納させ得る。このようにして、エンコーダ（303）は、遠端ビデオデコーダによって取得される（伝送エラーがない）再構成された参照フレームとして共通のコンテンツを有する再構成された参照フレームのコピーをローカルに格納することができる。

予測器（535）は、コーディングエンジン（532）の予測検索を実行することができる。すなわち、コード化される新しいフレームについて、予測器（535）は、参照ピクチャメモリ（534）を検索して、サンプルデータ（候補参照ピクセルブロックとして）または参照ピクチャ動きベクトル、ブロック形状などの特定のメタデータを探すことができ、それは新しい画像の適切な予測参照として機能し得る。予測器（535）は、適切な予測参照を見つけるために、サンプルブロックのピクセルブロック（sample block-by-pixel block）ごとに動作することができる。場合によっては、予測器（535）によって取得された検索結果によって決定されるように、入力画像は、参照ピクチャメモリ（534）に格納された複数の参照ピクチャから引き出された予測参照を有することができる。

コントローラ（550）は、例えば、ビデオデータを符号化するために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ（530）のコーディング動作を管理することができる。

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

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

コントローラ（550）は、エンコーダ（303）の動作を管理することができる。コーディング中に、コントローラ（550）は、各コード化されたピクチャに或るコード化されたピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、ピクチャは多くの場合、以下のフレームタイプのいずれかとして割り当てられ得る。

イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンスの他のフレームを使用せずにコード化および復号され得るものであり得る。いくつかのビデオコーデックでは、例えば独立デコーダリフレッシュ画像など、様々なタイプのイントラピクチャを使用できる。当業者は、Ｉピクチャのそれらの変形およびそれらのそれぞれの用途および特徴を知っている。

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

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

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

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

一実施形態では、送信器（540）は、符号化されたビデオを伴う追加のデータを送信することができる。ビデオコーダ（530）は、コード化されたビデオシーケンスの一部としてそのようなデータを含み得る。追加データは、時間的／空間的／SNRエンハンスメントレイヤ、冗長なピクチャおよびスライスなどの他の形式の冗長なデータ、付加拡張情報（SEI）メッセージ、視覚的ユーザビリティ情報（VUI）パラメータ集合フラグメントなどを含み得る。

以下では、ビデオコーデックの高レベルの構文、特にNALユニットヘッダ（NUH）の設計に焦点を当てて説明する。

NUHは、複雑な構文を処理することが期待できるデコーダだけでなく、MANE、ファイルリライターなど（以下、MANE）によっても解釈され得るため、その設計は、可変長コード（VLC）または算術コーディングなどの複雑なエントロピーコーディングスキームを回避する必要がある。他方、構文要素の条件付きの存在を含む、ある程度の複雑さは、特にそれらの構文要素で伝達される情報が、さもなければNUHの外へ、そしてNALユニットペイロードに移動する必要がある場合は、許容される。その理由は、NALユニットのペイロードは開始コードエミュレーション防止で保護されており、開始コードエミュレーション防止を戻すことは、実装と計算の複雑さの両方の観点から面倒な作業になり得ることでありうる。

MANEによる容易な処理のため、NUHはオクテットに揃えられており、これは、ビット単位の長さが8で割り切れることを意味する。ビデオがMPEG－2トランスポートストリームチャネルを介して転送されるときの開始コードエミュレーション防止のために、少なくとも1ビット（H．264とH．265 NUHの両方でforbidden＿zero＿bitと呼ばれる）が最低限必要であり得るため、最小長のNALユニットヘッダは8ビットである。理想的には、最も一般的なNALユニットタイプ（NUT）に対して設計はこれらの8ビット内にとどまる必要があるが、よりエキゾチックで頻度の低いNUT、またはヘッダオーバーヘッドが、コード化されたピクチャタイプのパーセンテージとして無視できるNUTに対して、より多くのビットが必要になる場合がある（例えば、Ｉピクチャとその派生物、または本質的に非圧縮形式でコード化されたピクチャなど）。

H．265の開発中に、（H．264のそれらと比較して）多数の追加のNUTが指定された。さらに、H．265では、NALユニットヘッダの時間スケーラビリティシグナリングがベースラインプロファイル（H．265ではメインプロファイルと呼ばれる）に導入され、今日一般的に使用されている場合がある。VVCなどの将来のビデオコーディング規格では、NUTの数も、時間的スケーラビリティの必要性もなくなることはないと予想され得る。NUTに6ビット、forbidden＿zero＿bitに1ビット、および時間レイヤリング情報に3ビットを使用すると、1つで10ビットに到達し、オクテットアライメントにより、H．265では16ビットNUHになる。

それでも、コーディング効率の観点から、後続のピクチャ（Pピクチャ／スライス／タイルグループ、Bピクチャ／スライス／タイルグループなどを含み得る）などの最も一般的なNUTでは、単一のオクテットのみのNUHを使用することが望ましい。一般的にあまり使用されないNUTまたは特定のアプリケーション用に設計されたNUTは、より大きなヘッダを使用する場合がある。開示された主題では、この所望のことは、NALユニットタイプクラスを示す1つまたは複数の専用NUTによって示されるように、NALユニットヘッダの第1のオクテットを超えた構文要素の条件付き存在を通じて、および／または拡張メカニズムを使用する第1のNALユニットが復号される前に利用可能かつ復号可能な高レベル構文構造の情報を通じて、実装される。

図6を参照すると、開示された主題によるNUH（601）が示されている。NUH（601）は、MPEG－2トランスポートストリームベースのシステムでの開始コードエミュレーション防止に必要でありうるforbidden＿zero＿bit（602）を含む場合がある。NUH（601）は、NALユニットタイプクラス構文要素（603）をさらに含み得、ここでは、NALUクラスとして図示され、長さは4ビットである。図示されているNUH（601）のような特定の場合、および特定のタイプのNALユニット、特にPおよびBピクチャ／タイルグループ／タイル／スライス／ＧＯＰ／…（以下、P／Bセグメント）では、その値は、P／Bセグメントタイプを直接示すNALユニットタイプとして解釈され得る。時間層情報（604）は、例えば、H．265から知られているものと同様の場合があり、この例では、3ビットを占め得る。

図6は、第2のNUH（605）、さらに前述のように、forbidden＿zero＿bit（606）および時間層情報（608）も含む。しかしながら、ランダムアクセスセグメントタイプ、先行画像セグメントタイプ、スイッチング画像セグメントタイプ、パラメータ集合タイプ、様々なビットストリームマーカーなど、特定の他のタイプのNALユニット（例えば、P／Bセグメントを搬送しない）の場合、NALユニットタイプクラス構文要素（607）は、ランダムアクセスセグメントクラス、先行画像タイプクラス、パラメータ集合タイプクラス、マーカークラスなどのセグメントタイプのクラスを示す（609）ことができる。副次的な情報として、例えば、ランダムアクセスセグメントクラスの値は、そのような情報を搬送するNUHの1つまたは複数の追加のオクテットの存在をトリガーできる。この例では、1つのオクテット（610）が追加され（太字の破線のアウトラインとして図示されている）、クラス内のランダムアクセス画像のNUT（611）（ここでは、3ビットで示される）と将来の拡張のため、およびオクテットアライメントを維持するために予約済み（612）のいくつかのビットを含む。

一例として、H．265のNUTを使用すると、次の分類が使用され得る。

クラスには含まれていないが、汎用ビットストリームでは非常に一般的であり得るため、直接通知されるのは
TRAIL＿N、TRAIL＿R、PREFIX＿SEI＿NUTおよびSUFFIX＿SEI＿NUTであり、それらを示すには、4つのクラスNUTが必要である。加えて、5つのクラスがあり得、合計9つの未予約または未指定のコードポイントが存在し得る。

クラス1：先行ピクチャ
・RADL＿N，RADL＿R，

クラス2：スイッチングピクチャ
・TSA＿N，TSA＿R，STSA＿N，STSA＿R

クラス3：ランダムアクセスピクチャ
・BLA＿W＿LP，BLA＿W＿RADL，BLA＿N＿LP，IDR＿W＿RADL，IDR＿N＿LP，CRA＿NUT

クラス4：パラメータ集合
・（DPS＿NUT），VPS＿NUT，SPS＿NUT，PPS＿NUT

クラス5：マーカー
・AUD＿NUT，EOS＿NUT，EOB＿NUT，FD＿NUT．

上記または同様の形式で開示されたクラスベースのNUTシグナリングを導入すると、あまり一般的ではないNALユニットタイプまたは一般的に大きなピクチャに関連付けられたNALユニットタイプの追加のシグナリングオーバーヘッドを犠牲にして（コード化されたピクチャサイズに関連して、追加のオーバーヘッドは、それほど重要ではない場合がある）、NUHのNUTフィールドを4ビットに減らし、それでも外部使用または将来の拡張のためにいくつかの番号付けスペースを留保する。

ある環境では、クラスはまたNALユニットヘッダの外部のメカニズムによって確立され得る。例えば、MANEでパラメータ集合のアクティブ化シーケンスに従うのが負担にならない環境および業界では、クラスの確立（より正確には、ここでは追加のオクテットとその構文の存在）はパラメータ集合情報によってトリガーされ得る。これは、ビデオビットストリームにおいて常にアクティブであるパラメータ集合（デコーダパラメータ集合として知られる概念）に関して特に関連し得る。プロファイルまたはプロファイルの世代（H．265では「プロファイルスペース」として知られている概念）への解析および／またはコンテキスト依存関係も許容され得る。エラーからの回復力が問題にならないさらに他の環境では、NAL間ユニットヘッダ予測でさえ可能であり得る。その場合、第1のNUHのクラスIDは、第1のNUHに続く第2のNUHへの解析依存関係として使用され得る。

同じまたは別の実施形態では、特定のNALユニットタイプクラスは、追加のオクテット内のNALユニットタイプの存在だけでなく、同じまたはさらに別のオクテット内の他の情報も示すために使用され得る。例えば、あるアプリケーションでは、NALユニットタイプの空間／SNR層ID、マルチビュー層ID、タイルid（例えば、ピクチャ内の、復号順で、n番目のタイルを示す整数など）、コンポーネントタイプid（例えば、カラープレーンのインジケータ、ポイントクラウドコーディングの属性など）、ピクチャID（例えば、8ビットを示すなど）ピクチャ順序カウント最下位ビット（POC LSD）などを含めることが役立つ場合がある。

NUH（613）を考慮する。含まれているのは、NALユニットタイプクラス構文要素（614）であり、提示された例では、追加情報を伴う後続の画像を示し得る。これにより、NALユニット構文要素のタイプを含む第1の追加オクテットの存在をトリガー（615）できる。この例では、このNALユニットタイプの構文要素のサイズは5ビットとして選択され、それぞれが文字「A」から「E」で識別され、第1のビット「A」は、NALユニットがTRAL＿NまたはTRAIL＿Rのいずれかを示し得、残りの4ビットは、フラグとして、それぞれ、層id「B」、コンポーネントid「C」、タイルid「D」、およびピクチャID「E」を搬送する追加の構文要素の存在を示す。それらの追加の例示的な構文要素はすべて、所与の固定長のバイナリコード化整数であり、ビット集合によって示されるように、追加のオクテットに組み立てられ得る。この例では、第2のオクテット（616）の残りの部分は、1に設定された層idプレゼンスビットによって示される（618）ようにlayer＿idの最上位3ビットを含み、第3のオクテットの第1の3ビットはlayer＿idの残りの3ビットを含む（617）。コンポーネントid「C」およびタイルid「D」に関連するビットがゼロに設定されているため、これらのフィールドが存在しないことを示していると想定する。最後に、ビット「E」は、この例では1に設定され得、それは4ビットピクチャID（620）を示し得（619）、第3のオクテット（621）の残りは、パディングのためにゼロに設定され得る。

追加のオクテットのレイアウトは、クラスごとに異なる場合がある。例えば、いくつかのクラスでは、追加のオクテットのNUTの番号付けスペースは、32より大きくまたは小さく選択され得る（5より多いまたは少ないビットが必要である）。特定のクラスでは、インジケータビットがないかより多いかより少ないことが、NUH（613）のそれらと比較したとき、必要とされ得る。NALユニット構文要素のタイプを超えた特定の追加フィールドが常に存在する場合がある。

このアーキテクチャを使用すると、3オクテットを超えるNUHが設計され得、開始コードエミュレーションの問題が発生する。それらを抑制するために、第nのオクテットごと、例えば第3のオクテットから始まる第4のオクテットごとに、特定のビットを設定またはクリアし、それに応じて他のNUHフィールドは後方にシフトされると、開始コードのエミュレーションを防ぐことができる。

クラスベースのNUHの他のアーキテクチャも可能である。例えば、特定のフィールドは固定位置とすることが必要とされ得る。それは、ビデオコーディング技術または規格がその他の場合は非常に柔軟なNUHを可能にするとき、欠点を有し得るが、MANEの実装を簡素化し得る。

図7は、一実施形態による例示的なプロセスを図示するフローチャートである。図7に示されるように、プロセスは、NALUヘッダに含まれる固定長バイナリコード化ネットワーク抽象化層ユニット（NALU）クラスタイプを復号すること（ブロック710）、NALUヘッダのNALUタイプを復号すること（ブロック720）、およびピクチャを再構成することを含み得るものであって、ピクチャのタイプは、NALUクラスタイプとNALUタイプの組み合わせによって識別される（ブロック730）。

図8を参照すると、NUH（613）と同様の例示的な一NALユニットヘッダの構文図（801）が示されている。開示された主題は、他の構造のNALユニットヘッダ、例えば、H．264、H．265、VVCのNALユニットヘッダ、または例示的なNUH（605）と共に等しく採用され得る。NALユニットヘッダには、構文要素picture＿id（802）が含まれ得る。包含は、ビット「E」（803）の値を条件とすることができ、その存在は、次に、あるNALユニットクラス（805）を条件とする（804）ことができる。そのpicture＿idは、ビデオエンコーダとデコーダだけでなく、MANEによっても簡単に処理できる形式にすることができる。限定としてではなく例として、構文要素picture＿id（802）は5ビットの符号なし整数で表される。5ビット値は32値の番号付けスペースを提供し、32の画像から1つを一意に識別できるようにする。例えば、picture＿idの値が符号化されるピクチャごとに1ずつ増加し、32に達したときにゼロにラップアラウンドするならば、NALユニットのピクチャへの関連付けがエラーの発生しやすい環境で中断する前に、少なくとも32のピクチャに属するNALユニットが失われる必要がある。

同じまたは別の実施形態では、構文要素picture＿id（802）のサイズは5ビットより大きくても小さくてもよい。ほとんどの場合、構文要素が大きいほど、NALユニットの画像への関連付けのエラー耐性が高くなるが、コーディング効率が犠牲になり得る。

同じまたは別の実施形態では、picture＿id（802）のサイズは、NALユニットヘッダの他の構文要素に依存し得る。例えば、ビデオコーディング技術または規格では、前述のように、picture＿idのサイズをNALユニットタイプまたはNALユニットタイプクラスに依存させ得る。例えば、あるNALユニットタイプ、例えば、1に等しいNALユニットタイプは、8ビットのpicture＿idサイズのコード化されたタイルグループ、タイル、またはスライスを識別できるが、2に等しいNALユニットタイプは、5ビットのpicture＿idサイズのタイルグループ、タイル、またはスライスを識別できる。

同じまたは別の実施形態では、picture＿id構文要素のサイズは、他の高レベルの構文要素、例えばパラメータ集合によって決定され得る。例えば、シーケンスパラメータ集合は、NALユニットが属するコード化されたビデオシーケンスに属するNALユニットヘッダのpicture＿id（802）構文要素のサイズを示す構文要素を含むことができる。このようなメカニズムは、コード化されたビデオシーケンスのNALユニットとパラメータ集合との解析依存関係を作成し得、あるシナリオでは望ましくない場合がある。さらに、MANEは、問題のパラメータ集合を解析するだけでなく、状態の形式で、そのコンテンツの少なくとも一部を保持する必要があり得る。それは多くのアプリケーションにとって望ましくない場合があるが、コーディング効率およびコードポイントの使用の観点から利点を有し得、MANEがパラメータ集合だけでなく、タイルグループ、タイル、またはスライスヘッダなどの複雑な可変長構文構造も解析および解釈する必要があり得る現在の状況よりもさらに好ましい。

上記では、picture＿id（802）の値を設定するための1つのオプションは、コード化されたピクチャのラウンドロビンカウンターとして説明されていた。値を設定するより高度な形式が有利な場合がある。例えば、同じまたは別の実施形態では、picture＿id（802）構文要素は、エンコーダおよびデコーダによって維持されるように、ピクチャ順序カウント（POC）値の最下位nビットによって入力され得る。その場合、Nは、picture＿id（802）構文要素のサイズを決定するための上述のメカニズムのいずれか、またはその他の適切なメカニズムによって決定され得る。POCの最下位ビットを使用すると、特定の利点を有し得る。例えば、固定フレームレートフラグによって示されるように、ピクチャ／フレームレートが固定され、エンコーダがピクチャをスキップしないことが知られており、および、例えば、コーディング構造のSEIメッセージまたは帯域外手段の受信を通してコーディング構造が知られているシナリオでは、POCを使用すると、復号順序情報に加えて、暗黙的なタイミング情報を提供できる。

例として、制限としてではなく、H．265でPOCがどのように使用されているかを以下に要約する。ビデオコーディング技術によって作成され、参照ピクチャの選択や参照ピクチャリストの管理などの内部目的でそれらのビデオコーディング技術で使用されるピクチャ順序カウントに基づいて一意のpicture＿idを作成または使用する他の形式も同様に使用され得、picture＿idとしてPOCの使用に含まれることが意図されている。

H．265では、コード化された各ピクチャは、PicOrderCntValとして図示されるピクチャ順序カウント変数に関連付けられている。ピクチャ順序カウントは、マージモードおよび動きベクトル予測での動きパラメータの導出のため、ならびにデコーダの適合性チェックのため、ピクチャを識別するために使用され得る。所与のコード化されたビデオシーケンス（CVS）では、すべてのコード化されたピクチャのPicOrderCntVal値は一意である。さらに、ピクチャ順序カウントは、CVSに含まれる（すなわち、例えば、表示のために、復号されたピクチャバッファから）ピクチャの相対的な出力順序を提供する（すなわち、ピクチャ順序カウントが低いピクチャは、ピクチャ順序カウントが高いピクチャの前に出力される）。ITU－T H．265では、PicOrderCntValの値は－2³¹から2^31－1までの範囲である。シーケンスパラメータ集合の構文は、次のようにピクチャ順序カウントの復号プロセスで使用される変数MaxPicOrderCntLsbの値を指定する構文要素log2＿max＿pic＿order＿cnt＿lsb＿minus4が含まれ、すなわち、
MaxPicOrderCntLsb＝2^{（log2＿max＿pic＿order＿cnt＿lsb＿minus4＋4）}
であり、ここで、log2＿max＿pic＿order＿cnt＿lsb＿minus4の値は、0から12までの範囲である。

ITU－T H．265は、PicOrderCntValがPicOrderCntMsb＋slice＿pic＿order＿cnt＿lsbに等しいところを提供する。slice＿pic＿order＿cnt＿lsbは、その規格のセクション8．3．1により導出される。

例えば、H．265を含む特定のビデオコーディング規格および技術では、POCの値は、スライスヘッダなどの特定の構文要素に含まれるか、特定の構文要素から導出されうる。同じまたは別の実施形態では、POCまたはその派生物（POCの最下位ビットなど）がNALユニットヘッダに含まれるとき、同じ情報が同じNALユニットに2回存在し得るので、特定の冗長性があり得る。ビデオコーディング技術または規格は、次のオプションの少なくとも1つによってこの冗長性に対処できる、すなわち、開示された主題によりスライスヘッダとNALユニットヘッダの両方への変更の量を最小限に抑えるために、追加された冗長性を通じてコーディングペナルティを受け入れる、またはスライスヘッダから冗長な情報を削除する。

picture＿idの値を設定する他の例は、例えば、ハッシュ関数の使用が含まれ、ハッシュは、サンプル値やPOC値などの、ピクチャごとに変化する可能性のある値と組み合わせて、アクティブなパラメータ集合の特定の要素などのピクチャ識別情報に対して計算される。このようなメカニズムは、NALユニットをコード化されたピクチャに関連付ける機能を超えて、独立して有用な副次情報を搬送しない場合があるが、POCの増加に比べてハッシュ関数が使用されているとき、統計的に多くのビットが変化するため、ビットエラーに対する回復力が向上するという利点を有し得る。

エンコーダは、当業者に知られている既存のNALユニットヘッダ構文を書き込むのと同様の方法で、上述のように入力された構文要素picture＿idを含むNALユニットヘッダを書き込むことができる。

デコーダまたはMANEはまた、コード化されたビデオビットストリームから、picture＿idの存在または非存在に関係なく、当業者に知られている方法で、NALユニットヘッダ、より正確には、NALユニットヘッダを構成する構文要素を解析することができる。しかしながら、ピクチャIDは、場合によって、状態情報を必要とせずに、アクセス可能なエントロピーコード化形式、例えば、固定長のバイナリコードでコード化されることに注意されたい。これまでのところ、開示された主題によりNALユニットヘッダを解析することは、構文要素picture＿id自体の実際の存在を超えて、デコーダまたはMANEへの追加の煩わしい動作を含まないものであり得る。

しかしながら、開示された主題により、デコーダまたはMANEは、開示された主題がない場合に必要とされる動作と比較したとき、わずかな労力でNALユニットをコード化されたピクチャに関連付けることができる。図9を参照すると、一例として、デコーダまたはMANE（以下、デコーダ）は、第1の構文要素picture＿idを含む第1のNALユニットヘッダを解析および復号（901）することができる。この第1のNALユニットヘッダは、不変条件として、次に第1のコード化されたピクチャに属する第1のNALユニットに属する。

デコーダはさらに、第2の構文要素picture＿idを含む第2のNALユニットヘッダ（902）を解析および復号することができ、第2のNALユニットヘッダは、第2のNALユニットに属する。

デコーダは、第1のpicture＿idの値を第2のpicture＿idの値（図示せず）と照合することができる。それらの値が同じである場合、2つのNALユニットが同じコード化されたピクチャに属している可能性が高い。その可能性は、主にエンコーダがpicture＿idの値を入力するために使用しているメカニズム、および構文要素のサイズによって影響される。両方の要因はすでに上記において説明されている。

デコーダは、第3の構文要素picture＿idを含む第3のNALユニットヘッダ（903）をさらに解析および復号することができ、第3のNALユニットヘッダは、第3のNALユニットに属する。

もう一度、デコーダは、例えば、第1のpicture＿idの値を第3のpicture＿idに対して照合（904）することができる。それらの値が同じである場合（905）には、3つのNALユニットが第1のNALユニットと同じコード化されたピクチャに属している可能性が高い。しかしながら、2つの値が同じでない場合（906）、第3のNALユニットが第1のNALユニットと同じピクチャに属していないことは確かである。

デコーダまたはMANEは、開示された主題により取得された情報、具体的には、picture＿id、およびNALユニットが別の先行するNALユニットと同じピクチャに属するかどうかを任意の適切な方法で利用することができる。例えば、MANEは、picture＿idのPOCの最下位ビット値を追跡し、コーディング構造について有する事前の知識と照合することができる。MANEが、例えば出ていくリンクの輻輳が原因で、コード化されたビデオシーケンスのNALユニットを廃棄する必要がある場合、picture＿id値をコーディング構造の位置と照合することができる。廃棄に適したピクチャが識別されると、その単一のピクチャのすべてのNALユニットが削除され得る（しかし、NALユニットヘッダの他のフィールドで同じ情報を搬送し得る、他の廃棄可能なピクチャのNALユニットである必要は必ずしもない）。同様に、CPUサイクルの枯渇を観察するデコーダも同様のステップを実行できる。いずれの場合も、単一の廃棄可能なピクチャのみが削除されているため、ユーザエクスペリエンスへの悪影響は最小限に抑えられ得、動作が軽量であるため、MANEまたはデコーダのCPU負荷も最小限に抑えられ得、NALユニットヘッダでは固定長のコードワードのみが関与する。

一実施形態によれば、特定の環境では、コード化されたビデオビットストリームは、特定のコンポーネントまたは特定のコンポーネントの集合（以下、「コンポーネント」）が特定のNALユニットで分離され得るように調整され得る。図10を参照すると、従来のピクチャおよびビデオコーディング規格では、Y（1002）、Cr（1003）、Cb（1004）コンポーネントなどのコンポーネントの集合に関連する情報は、NALユニットヘッダ（1005）やその他のヘッダ情報（1006）など、すべてのコンポーネントに関連する情報と共に同じNALユニット（1001）でコード化される。特定の技術および予測メカニズムは、コンポーネント信号の可能な類似性を活用して、圧縮効率を得るために使用され得る。例えば、Y Cr Cb信号がスライスやタイルなどをカバーする同じNALユニットでコード化されているとき、3つのコンポーネントが含まれている場合でも、「ロケーション」情報（例えば、再構成されたピクチャのスライス／タイルの第1のCUのロケーションなど）を複数回コード化する必要はない。場合によっては、クロミナンス動きベクトル、ブロック構造などの特定のクロミナンス関連情報が輝度情報から予測される、より洗練された予測メカニズムが多数存在する可能性もある。

しかしながら、特定の環境では、特定のコンポーネントと特定のタイルまたはスライス、あるいは特定のタイルまたはスライスの特定のコンポーネントの集合に関連する情報を、それが、単一のNALユニットでタイルまたはスライスのすべてのコンポーネントをコーディングする場合と比較すると、予測が不足しているため、コーディング効率が低下する可能性があることを意味し得る場合でも、自身のNALユニットでコーディングすると有益な場合がある。

そのようなNALユニットは、同じまたは別の実施形態では、適切にマーク付けされ得る。NALユニットにマークを付けるには、関連するマーキング情報をNALユニットヘッダ、スライスヘッダ、タイルヘッダ、タイルグループヘッダ、NALユニットに関連付けられた、先行する、または後続のSEIメッセージ、あるいはその他の適切なヘッダまたはNALユニットに関連付けられた非ヘッダ情報に配置するなど多くのオプションがある。有利なことに、マーキングは、固定長のバイナリコードを使用してNALユニットヘッダでコード化されるなど、簡単にアクセスされ得る形式にすることができる。限定ではなく一例として、このようなNALユニットヘッダベースのマーキングが今後想定される。

第1の例では、白黒信号を生成するために、輝度コンポーネントYからカラーコンポーネント（CrおよびCb）をプルーニングできるようにすることが望まれる、Y Cr Cbカラーモデルによる従来のコンポーネントコーディングについて考慮する。H．264やH．265などのビデオコーディングスキームでは、Y、Cr、およびCb情報が相互に予測され得、マクロブロック／CUレベルでのインターリーブ方式でコード化されるため、そうするには完全なトランスコーディングステップが必要になる。しかしながら、同じまたは別の実施形態では、ビットストリームは、場合によっては、空間領域でのスライスまたはタイルまたはタイルグループまたは他のサブ画像分割が2つのNALユニットに分割されるように構成されている。引き続き図10を参照すると、これら2つのNALユニット（1010）の第1のものは、Y情報、他のヘッダ情報（1012）、および輝度（Y）情報（1013）の存在を示すNALユニットヘッダ（1011）を含み得る。第2のNALユニット（1020）は、輝度コンポーネントとは異なり、色コンポーネントが個別に使用されない場合があるという理解に基づいて、クロミナンスコンポーネント（Cr（1023）およびCb（1024））の両方に関する情報を含み得る。それらの2つのコンポーネントは、コンポーネントグループを形成し得、これは、非常に近接したセマンティックなつながりを伴うコンポーネントのコレクションであり得るため、それぞれのアプリケーションの観点から、それらを分離することは望ましくない。NALユニット（1020）はまた、CRおよびCB情報の両方の存在を示すNALユニットヘッダ（1021）、および他のヘッダ情報（1022）を含み得る。第1および第2のNALユニットは、確立された慣行により、ほぼ独立して復号可能である必要があり、相互の解析依存関係を含まないようにする必要があるため、YおよびCr Cb情報を2つのNALユニットに分割すると、ある程度のコーディングの非効率性が予想され得る。具体的には、輝度からクロミナンスコンポーネント情報への予測（例えば、動きベクトル予測、ブロック形状予測、方向内予測など）が禁止され得、CrおよびCb情報に必要なビットレートが高くなる可能性がある。さらに、他のヘッダ情報（1012）および（1022）は、それぞれ、重複する情報を含み得る。最後に、各NALユニットはそれぞれ自身のNALユニットヘッダ（1011）と（1021）を必要としており、それら2つのヘッダは組み合わせられたNALユニット（1001）の単一ヘッダ（1005）よりも多くのビットを取ることも予想され得る。それでも、特定のアプリケーションでは、十分なトランスコーディングなしで、簡単にビットストリームから特定のコンポーネントまたはコンポーネントグループを削除したり、コンポーネントまたはコンポーネントグループに関連するデータ（デコーダで受信した場合）の復号を回避したりできるという利点が、それらのコーディング効率のペナルティより重要であり得る。

第2の例では、明るさと色を超えたピクセル属性をサポートする画像またはビデオのコーディング技術が想定されている。画像またはビデオのコーディング技術は広く解釈する必要があり、立体視、マルチビュー、ポイントクラウド、ライトフィールドなどの技術を含めることができる。初期の例として、YCrCb、RGB、または同様のカラー形式でコード化されたサンプルデータに加えて、特定の画像およびビデオコーデックがサポートされ、アルファチャネルとして知られる透明度情報もサポートされていた。アルファチャネルは、サンプルまたはサンプルのグループについて、ビットストリームにコード化された透明度値（アルファ）を有することによって表され得る。デコーダは、通常のサンプルデータのようにアルファマップを再構築できる。レンダラーは、アルファマップを使用して、再構築されたサンプルデータおよび背景情報、存在する場合、を適切に重み付けして、透明度の錯覚を作成できる。

透明度は、色と明るさを超えたサンプルの多くの可能な属性の1つにすぎない。例えば、特定のコーディング技術、特に特定の360度およびポイントクラウドコーディング技術では、サンプル（またはポイントクラウドコーディングではポイント）に、明るさ／色およびおそらく透明度に加えて反射性属性を含めることを考えている。さらに、ポイントクラウドコーディングでは、所与のポイントが、表示方向（スペース内の視点）に応じて、異なる属性値（明るさ、色、透明度、反射率、表面法線、曲率など）を関連付ける場合がある。例えば、ポイントクラウドが一方のビュー方向で透明で、もう一方では不透明で反射するマジックミラーを表すときには、透明度と反射率の両方の属性は、視点に応じて根本的に異なり得る。マジックミラーも多少色が付いている場合があり、ミラーの表面にあるポイントからの方向と距離の両方に基づいて異なる色の値になり得る。別の例として、ビューに依存する色は、様々な視点から3Dシーン／オブジェクトの写実的なレンダリングを可能にするために使用され得、これは、仮想現実や拡張現実などの新しいアプリケーションに役立ち得る。さらなる属性には、人間の目には見えないが特定のアプリケーションに関連する波長を含み得る。例えば、特定の顔認識センサーは、低可視光条件で赤外線信号を使用する。さらに高度な属性は、分極化に関連している場合がある。

上記の属性の長いリストを念頭に置いて、アプリケーションで必要とされない、視野角、光の状態など、または本明細書に列挙されていないその他の理由のために適用できない高度な信号のビットストリームをプルーニングするための要件が存在する。

図11を参照すると、YおよびY情報（1103）を示すNALユニットヘッダ（1102）を含む第1のNALユニット（1101）が示されている。さらに、クロミナンス（Cr Cb）情報を示すNALユニットヘッダ（1111）を含む第2のNALユニット（1110）がある。第3のNALユニット（1120）は、透明度情報（アルファチャネル）、および関連する透明度情報（1122）を示すヘッダ（1121）を含む。最後に、反射性情報を示すそのNALユニットヘッダ（1131）、および反射性情報（1132）を含む第4のNAL（1130）ユニットもある。4つのNALユニットは、スライス、タイル、タイルグループなどによって表され得る画像の同じ空間領域、または異なる領域に関係し得る。しかしながら、後者の場合、サンプルに関連付けられたYCrCb、透明度、および反射率の情報が4つのそれぞれのNALユニット（1101、1110、1120、1130）に含まれている少なくとも1つのサンプルが存在すると想定する。その場合、コーディングせずに特定の動作が可能になり得る。

図12を簡単に参照して、3つすべてのNALユニット、およびおそらくより多くの同様のタイプ、すなわち、YCrCb NALユニット、透明性NALユニット、および反射性NALユニットを含むビットストリームを含むデータソース（1201）を含むシステムを考慮する。それらのNALユニットは、サーバ／メディア対応ネットワーク要素（以下、MANE）（1203）に転送（1202）される。矢印（1202）は、3つの情報タイプすべてに必要な高いビットレートを強調するために、特に太い線で図示されている。3つのクライアントが同じメディアビットストリームを要求したが、異なる復号および／またはレンダリング機能ならびに／あるいは異なる接続性を有している。洗練されたクライアント（1205）は、YCrCb、透過性、反射性の3つの情報タイプすべてを適切に受信、復号、およびレンダリングすることが可能でありうる。したがって、MANE（1203）は、3つすべてのNALユニットをクライアント（1205）に転送することができ、ソース（1201）とMANE（1203）との接続と実質的に同様のネットワーク容量（1204）を必要とする。さらに、ここではラップトップで表される第2のクライアント（1207）が存在し得る。そのクライアントは、反射性情報の復号または伝送を許可しない復号機能および／または接続性をいくらか少なく有し得るか、あるいはユーザが、例えば反射性情報に興味がないことを選択した場合がある。制限要因が何であれ、反射性情報をそのクライアントに転送（1206）することは無意味である。したがって、MANEは、反射率に関連するNALユニットをビットストリームから削除し、ビットレートの低いビットストリームをもたらす場合がある。最後に、ここではスマートフォンで表される第3のクライアント（1209）が存在し得る。そのクライアントは、透明性と反射性の両方の情報の復号機能および／または接続性を欠いている場合があり、および／または使用はそれらの一方または両方に興味がないことを示している場合がある。したがって、MANE（1203）は、YCrCb情報を搬送するNALユニットのみを第3のクライアント（1209）に転送（1208）することを決定し得る。

すべての属性の情報が同じNALユニットで符号化される従来のコーディング技術を想定すると、MANE（1203）は、各クライアント（1205、1207、1209）に関連する情報を抽出するために十分なトランスコーディングステップを必要とする場合がある。そのようにすると、計算コストが高くなり、MANE（1203）のコストが高くなり得る。しかしながら、NALユニットのフィルタリングは、パラメータ集合、SEIメッセージ、スライス／タイル／タイルグループなどの高レベルの構文で、排他的に、または他の簡単に解析可能で簡単にアクセスできる情報と組み合わせて、NALユニットヘッダに基づくことができるため、軽量プロセスになり得る。

MANEの観点からの最善の解決策は、ビットストリームプルーニングに必要なすべての関連情報をNALユニットヘッダで利用できるようにすることであり得、それはこれまで想定されていた。ややより面倒なのは、NALユニット自体によって搬送される情報の固定長または可変長のコードワードの復号を要求することであり得、NALユニットヘッダの直後のNALユニットの最初に有利である（「他のヘッダ情報、例えば図10の（1002）または（1003））。2つのシナリオが考えられ得る。もう1つの有利なシナリオでは、「他のヘッダ情報」は、NALユニットによって搬送される情報のタイプを決定するために必要な範囲で、パラメータ集合NALユニットなどの他のNALユニットから取得されたコンテキストなしで解釈できる場合がある。その場合、MANEの追加の複雑さは、可変長コードなどを含み得る他のヘッダ情報の情報の解析に制限され得、したがって、固定長NALユニットヘッダコードポイントよりも計算コストが高くなり得る。さらにより問題となるのは、NALユニットによって搬送される情報のタイプの決定が、パラメータ集合などのコンテキストで他のヘッダ情報（1002、1003）の解釈を必要とすることであり得る。その場合、MANEは、パラメータ集合のアクティブ化のほか、実際には実質的にすべての高層構文の復号に相当し得る他の特定のタスクも追跡する必要がある。十分なトランスコーディングステップよりもさらに簡単であるが、パラメータ集合ベースのコンテキスト依存復号は、ほとんどのMANEアーキテクチャにとって非常に面倒な場合がある。

ここで、制限としてではなく例として、NALユニットヘッダでコンポーネントまたはコンポーネントグループタイプを表すオプションについて説明する。提示されたオプションは、H．265のNALユニットヘッダ設計の基本的な構文レイアウトとアーキテクチャを反映している。他のコーディング技術および規格で使用され得る所与のNALユニットヘッダアーキテクチャにより適し得る他のオプションが存在し得る。

図13を参照すると、コンポーネントまたはコンポーネントグループは、例えば、NALユニット（1301）のNALユニットヘッダ（1302）において以下のように示され得る。

同じまたは別の実施形態では、第1のオプションで、コンポーネントまたはコンポーネントグループは、NALユニットタイプ（1304）の番号付けスペースを使用して、NALユニットヘッダ（1303）で示され得る。具体的には、NALユニットタイプは、コード化されたスライス、タイル、タイルグループなどを示すコードワードを含み得、特定のコンポーネントまたはコンポーネントグループのみを搬送する。暗黙的に、そのようなシグナリングのサブセットはH．265に存在し、コンポーネントグループY Cr Cbのそれには、NALユニットタイプの所与の値によって示されるスライスタイプが存在する。しかしながら、他のコンポーネントまたはコンポーネントタイプの固定番号付けスペース（NALユニットタイプの固定長コードワードのため）に割り当てられていないコードポイントによって可能な範囲で、より多くのコードワードが割り当てられ得る。ビデオコーディング規格または技術は、規格の存続期間中にビットストリームプルーニングおよびその他のアプリケーションに関連するようになり得るコンポーネントまたはコンポーネントグループの規格を作成する時点での規格設定委員会の理解に基づいて、コンポーネントタイプに使用可能な1つまたは複数を割り当てることができる。このオプションを使用すると、NALユニットヘッダの構文を変更する必要はない。

第2のオプションでは、特定のプロファイルでのみ意味のあるH．265スタイルのNALユニットヘッダ（1305）の特定の既存のフィールドは、コンポーネントタイプを示すために再割り当てされ得る。図9では、以前に層IDフィールド（1306）によって使用されたビットがコンポーネントタイプフィールドとして使用されているが、NALユニットヘッダの他のフィールドも同様に再割り当てされ得る。そうすることで、技術的には、プロファイルへの望ましくない解析およびコンテキスト依存関係が作成される場合があり、パラメータ集合にコード化され得る。しかしながら、他のほとんどのパラメータ集合値とは対照的に、プロファイルIDは、機能交換などのメカニズムを通じてMANEに対して先験的に利用可能であると広く理解されており、したがって、このようなプロファイルの依存関係は、パラメータ集合の他のフィールドへの解析およびコンテキストの依存関係ほど問題にはならない場合がある。しかしながら、第2のオプションでは、例えば、階層化またはマルチビューコーディングと、NALユニットヘッダのコード化されたコンポーネントタイプに基づくビットストリームプルーニングを同時に使用できない場合がある。

第3のオプションでは、NALユニットヘッダ（1307）にビットを追加することを犠牲にして、前述のすべての欠点が回避され得る。具体的には、フィールドコンポーネントタイプ（908）は、NALユニットヘッダの固定位置、例えば、最後に含まれ得る。このオプションは最も柔軟性があるが、コーディング効率の観点からもあまり望ましくない。しかしながら、コンポーネントタイプ（1308）の存在は、特定のプロファイルの使用に条件付けられる場合があり（したがって、破線で図示されている）、コンポーネントタイプベースの処理に関心のないプロファイルのコーディング効率への影響を軽減することに注意されたい。あるいは、または加えて、コンポーネントタイプの存在は、NALユニットタイプフィールドの特定の値に制限される場合もある。例えば、従来のY Cr Cbスライス／タイル／タイルグループ用のNALユニットタイプのほか、追加のコンポーネントタイプシグナリングを伴うスライス／タイル／タイルグループ用の異なるNALユニットタイプも存在し得ると考えられる。このようなオプションのNALユニットヘッダ情報フィールドは、知られているビデオコーディング規格または技術にはまだ含まれていないが、エンコーダ、デコーダ、またはMANEに実装する際の障害は、パラメータ集合値へのコンテキスト依存関係を有することよりも低いために、好ましい。もちろん、そのメカニズムは、NALユニットタイプの番号付けスペースから番号付けスペースを取り除くものであり得る。

第4のオプションでは、コンポーネント情報をNALユニットヘッダまたは同等の構文要素に含めるために使用される構文は、例えば、前述の拡張可能なNALユニットヘッダの設計原則に従うことができる。特に、ピクチャIDおよび図8のコンテキストで説明されたものと同様のメカニズムが使用され得る。具体的には、コンポーネントIDでピクチャID（802）を置き換えることができる。その他のオプションについては、以下で説明される。上記で想定されていたH．265のNALユニットヘッダ設計に従わないNALユニットヘッダ設計には、他のオプションが適切な場合がある。

コンポーネントタイプ（1306、1308）が（NALユニットタイプに未使用のコードポイントを入力する代わりに）自身のフィールドにコード化されている場合、コンポーネントタイプのコーディングのための特定のオプションが使用可能になる。

引き続き図13を参照すると、同じまたは別の実施形態では、コンポーネントタイプ（1320）はビットマスクとして解釈され得る。提示された例では、4ビットのコンポーネントタイプにそれぞれ1ビットが入力されている
・輝度データ（Y）（921）
・クロミナンスデータ（Cr、Cb）（922）
・透明度（アルファ）（923）、および
・反射性（924）。

このようなビットマスクベースの設計は、コンポーネントの数が適度に少ない場合（4～8など）に有利であり得、それによってビットマスクのサイズが適切な量に制限される。また、NALユニットコンテンツの非常に柔軟なレイアウトが可能になり、例えば、（同じビデオビットストリーム内に）Y Cr Cb、または透明度のあるY、または透明度と反射率のあるY Cr CbをカバーするNALユニットを含めることが可能になる。アプリケーションの観点からそのような柔軟性が望ましいかどうかは疑わしい場合があるけれども、柔軟なNALユニットのペイロードレイアウトは確かに歓迎され得るが、エンコーダによる柔軟性を過度に実行すると、MANEが望ましくないコンポーネントを削除できないシナリオにつながる場合がある。

代替として、コンポーネントタイプは、事前定義されたコンポーネントまたはコンポーネントグループのリストへの列挙子として解釈される場合もある。

例えば、コンポーネントタイプ（1330）は、4ビットの符号なし整数であり得る。そのビットフィールドの他の長さが可能であり得、プロファイルまたは上述のようなNALユニットタイプの情報を含む、他の容易に入手可能な情報に依存し得る。

4ビットの符号なし整数値では、16の異なるコンポーネントまたはコンポーネントグループが可能である。図13は、以下のいくつかの可能なオプションを列挙している（1331）すなわち、
・0：Y Cr Cb
・1：Y
・2：Y Cr CBプラス透明度
・3；Y Cr Cbプラス反射性
・4：Y Cr Cbプラス透明性と反射性
・5：3Dジオメトリ情報（XYZ）
・6：深度マップ
・7：占有マップ
・8：表面法線ベクトル
・9．．15：未割り当て。

コンポーネントタイプの値4は、このようなシナリオでは、NALユニットにY、Cr、Cb、透明度、および反射率に関する情報を含む場合があることを示し得る（1332）。

同じまたは別の実施形態では、特定のコンポーネントタイプが上記のメカニズムのいずれかによって示される場合、NALユニットが特定のコンポーネントタイプに関する情報を含むことは必要条件であるが十分条件ではない場合がある。これは、例えばスライスタイプに似ている場合がある。例えば、Bスライスは、二重に予測されたコーディングユニットを含む場合があるが、イントラコード化されたコーディングユニットのみで構成されている場合もある。

同じまたは別の実施形態では、NALユニットは、特定のコンポーネントタイプおよび特定の視野角に関する情報を含み得る。視野角は、ビュー識別子（左または右のビューなど）または外因性／内因性のカメラパラメータ集合によって識別され得る。例えば、コンポーネントタイプ（1330）は、4ビットの符号なし整数であり、次のいずれかのオプションを有し得る、すなわち
・0：Y Cr Cbプラス左カメラに対応する深度マップ
・1：Y Cr Cbプラス右カメラに対応する深度マップ
・2：XYZジオメトリ情報プラス占有マップ
・3．．15：未割り当て。

上述のネットワーク抽象化層ユニットヘッダのネットワーク抽象化ユニット層タイプクラスの技法、および／または上述のネットワーク抽象化ユニットヘッダの画像参照の技術は、コンピュータ可読命令を使用してコンピュータソフトウェアとして実装され、1つまたは複数のコンピュータ可読媒体に物理的に格納され得る。例えば、図14は、開示された主題の特定の実施形態を実装するのに適したコンピュータシステム1400を示している。

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

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

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

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

入力ヒューマンインターフェース装置は、キーボード1401、マウス1402、トラックパッド1403、タッチスクリーン1410、データグローブ1404、ジョイスティック1405、マイク1406、スキャナ1407、カメラ1408の1つまたは複数（それぞれの1つのみを図示）を含み得る。

コンピュータシステム1400は、特定のヒューマンインターフェース出力装置も含み得る。そのようなヒューマンインターフェース出力装置は、例えば、触覚出力、音、光、および嗅覚／味覚を通して、1人または複数の人間のユーザの感覚を刺激し得る。そのようなヒューマンインターフェース出力装置は、触覚出力装置（例えば、タッチスクリーン1410、データグローブ1404、またはジョイスティック1405による触覚フィードバックであるが、入力装置として機能しない触覚フィードバック装置もあり得る）、音声出力装置（スピーカ1409、ヘッドホン（図示せず）など）、視覚出力装置（CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン1410など、それぞれタッチスクリーン入力機能の有無にかかわらず、それぞれ触覚フィードバック機能の有無にかかわらず、そのいくつかはステレオグラフィック出力などの手段を通して、2次元視覚出力または3次元を超える出力を出力できるものもある、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ、およびスモークタンク（図示せず））、およびプリンタ（図示せず）を含み得る。

コンピュータシステム1400は、人間がアクセス可能なストレージ装置およびそれらに関連するメディア、例えば、CD／DVDなどのメディア1421を伴うCD／DVD ROM／RW 1420を含む光学メディア、サムドライブ1422、リムーバブルハードドライブまたはソリッドステートドライブ1423、テープやフロッピーディスク（図示せず）などのレガシー磁気メディア、セキュリティドングル（図示せず）などの特殊なROM／ASIC／PLDベースの装置などを含み得る。

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

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

前述のヒューマンインターフェース装置、ヒューマンアクセス可能なストレージ装置、およびネットワークインターフェースは、コンピュータシステム1400のコア1440に接続され得る。

コア1440は、1つまたは複数の中央処理ユニット（CPU）1441、グラフィックス処理ユニット（GPU）1442、フィールドプログラマブルゲートエリア（FPGA）1443の形式の特殊なプログラム可能な処理ユニット、特定のタスクのためのハードウェアアクセラレータ1444などを含み得る。これらの装置は、読み取り専用メモリ（ROM）1445、ランダムアクセスメモリ1446、ユーザがアクセスできない内部ハードドライブ、SSDなどの内部大容量ストレージ1447と共に、システムバス1448を通して接続され得る。いくつかのコンピュータシステムでは、システムバス1448は、1つまたは複数の物理プラグの形でアクセス可能であり、追加のCPU、GPUなどによる拡張を可能にする。周辺装置は、コアのシステムバス1448に直接接続されることも、周辺バス1449を介して接続されることもできる。周辺バスのアーキテクチャは、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を有するコンピュータシステムは、1つまたは複数の有形のコンピュータ可読媒体で具体化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供することができる。そのようなコンピュータ可読媒体は、上記において紹介したようにユーザがアクセス可能な大容量ストレージのほか、コア内部大容量ストレージ1447またはROM 1445などの非一時的性質のコア1440の特定のストレージにも関連する媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に格納され、コア1440によって実行され得る。コンピュータ可読媒体は、特定の必要性に応じて、1つまたは複数のメモリ装置またはチップを含み得る。ソフトウェアは、コア1440、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM 1446に格納されたデータ構造の定義およびソフトウェアによって定義されたプロセスによる、そのようなデータ構造の変更を含む、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりにまたは一緒に動作することができる回路（例えば、アクセラレータ1444）に配線されたまたはそうでなければ具体化されたロジックの結果として機能を提供することができる。ソフトウェアへの参照にはロジックを含めることができ、必要に応じてその逆も可能である。コンピュータ可読媒体への参照は、必要に応じて、実行のためのソフトウェアを格納する回路（集積回路（IC）など）、実行のためのロジックを具体化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。

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

210 第1の端末
220 他の、第2の端末
230、240 端末
250 ネットワーク
300 ストリーミングシステム
301 ビデオソース
302 非圧縮ビデオサンプルストリーム
303 エンコーダ
304 符号化されたビデオビットストリーム
305 ストリーミングサーバ
306、308 ストリーミングクライアント
307、309 符号化されたビデオビットストリームのコピー
310 ビデオデコーダ
311 ビデオサンプルストリーム
312 ディスプレイ
313 キャプチャサブシステム
410 受信器
412 チャネル
415 バッファメモリ
420 パーサー
421 シンボル
451 スケーラー／逆変換ユニット
452 イントラ予測ユニット
453 動き補償予測ユニット
455 アグリゲータ
456 現在のピクチャ、ループフィルタユニット
457 参照ピクチャバッファ
530 ソースコーダ
532 コーディングエンジン
533 デコーダ
534 参照ピクチャメモリ
535 予測器
543 コード化されたビデオシーケンス
545 エントロピーコーダ
540 送信器
550 コントローラ
560 チャネル
601、605、613 NUH
602、606 forbidden＿zero＿bit
603、607、614 NALUクラス
604、608 時間ID
610 1つのオクテット
611 NUT
612 予約済み
616 第2のオクテット
617 layer＿idの残りの3ビット
620 ピクチャID
621 第3のオクテット
801 例示的な一NALユニットヘッダの構文図
802 picture＿id
805 NALUクラス
1001 NALユニット
1002 Y
1003 Cr
1004 Cb
1005、1011、1021 NALユニットヘッダ
1006 その他の共有ヘッダ情報
1012、1023 その他のヘッダ情報
1013 輝度（Y）情報
1020 第2のNALユニット
1022 他のヘッダ情報
1023 クロミナンスコンポーネント（Cr）
1024 クロミナンスコンポーネント（Cb）
1101 第1のNALユニット
1102、1111、1131 NALユニットヘッダ
1103 Y情報
1110 第2のNALユニット
1120 第3のNALユニット
1121 ヘッダ
1122 透明度情報
1130 第4のNALユニット
1132 反射性情報
1201 データソース
1203 MANE
1205、1207、1209 クライアント
1301 NALユニット
1302、1303、1305、1307 NALユニットヘッダ
1304 NALユニットタイプ
1306、1308 コンポーネントタイプ
1320、1330 コンポーネントタイプ
1400 コンピュータシステム
1401 キーボード
1402 マウス
1403 トラックパッド
1404 データグローブ
1405 ジョイスティック
1406 マイク
1407 スキャナ
1408 カメラ
1409 スピーカ
1410 タッチスクリーン
1420 CD／DVD ROM／RW
1421 CD／DVDなどの媒体
1422 サムドライブ
1423 ソリッドステートドライブ
1440 コア
1441 中央処理ユニット（CPU）
1442 グラフィックス処理ユニット（GPU）
1443 フィールドプログラマブルゲートエリア（FPGA）
1444 アクセラレータ
1445 読み取り専用メモリ（ROM）
1446 ランダムアクセスメモリ
1447 内部大容量ストレージ
1448 システムバス
1449 周辺バス

Claims

デコーダによって、ビデオシーケンスを復号するための方法であって、
ネットワーク抽象化層ユニット(NALU)ヘッダに含まれる固定長バイナリコード化されたNALUクラスタイプを復号するステップと、
前記NALUヘッダの中のNALUタイプを復号するステップであって、前記NALUタイプは、前記NALUタイプの中の第1の固定位置に第1のビットを含み、前記NALUタイプの中の第2の固定位置に第2のビットを含み、前記第1のビットは、前記NALUヘッダの中に第1の固定長コードワードが存在することを示し、前記第2のビットは、前記NALUヘッダの中に第2の固定長コードワードが存在することを示す、ステップと、
ピクチャを再構成するステップであって、前記ピクチャのタイプは、前記NALUクラスタイプと前記NALUタイプの組み合わせによって識別される、ステップと、
第1の構文要素ピクチャ識別子を含む第1のNALUヘッダを復号するステップであって、前記第1のNALUヘッダは、第1のコード化されたピクチャに属する第1のNALUに属する、ステップと、
第2の構文要素ピクチャ識別子を含む第2のNALUヘッダを復号するステップであって、前記第2のNALUヘッダは、前記第1のコード化されたピクチャに属する第2のNALUに属する、ステップと、
第3の構文要素ピクチャ識別子を含む第3のNALUヘッダを復号するステップであって、前記第3のNALUヘッダは、第2のコード化されたピクチャに属する第3のNALUに属する、ステップとを含み、
前記第1の構文要素ピクチャ識別子の値は、前記第2の構文要素ピクチャ識別子の値と等しく、および
前記第3の構文要素ピクチャ識別子の値は、前記第1の構文要素ピクチャ識別子の前記値と等しくない、方法。
前記第2の固定長コードワードは、前記第1の固定長コードワードの後に続く、請求項1に記載の方法。
開始コードエミュレーション防止ビットは、前記第1の固定長コードワードの後に続き、および
前記開始コードエミュレーション防止ビットの後には、前記第2の固定長コードワードが続く、請求項1に記載の方法。
前記第1の固定長コードワードは、空間／信号対雑音比層識別子、マルチビュー層識別子、タイル識別子、コンポーネントタイプ識別子、およびピクチャ識別子の少なくとも1つである、請求項1に記載の方法。
前記第1の構文要素ピクチャ識別子は、固定長のバイナリコード化されたコードワードとしてコード化される、請求項4に記載の方法。
前記第1の構文要素ピクチャ識別子にコード化された前記値は、ピクチャ順序カウント（POC）から導出される、請求項4に記載の方法。
第1のNALUの第1のNALUヘッダを復号するステップであって、前記第1のNALUは、少なくとも1つの第1のコンポーネントを復号する、前記第1のNALUの前記第1のNALUヘッダを復号する前記ステップに必要な少なくとも1つの構文要素を含む、ステップと、
第2のNALUの第2のNALUヘッダを復号するステップであって、前記第2のNALUは、少なくとも1つの第2のコンポーネントを復号する、前記第2のNALUの前記第2のNALUヘッダを復号する前記ステップに必要な少なくとも1つの構文要素を含み、
前記少なくとも1つの第2のコンポーネントは前記少なくとも1つの第1のコンポーネントとは異なる、ステップとをさらに含み、
前記第1および第2のNALUヘッダは、前記少なくとも1つの第2のコンポーネントが前記少なくとも1つの第1のコンポーネントとは異なることを示す少なくとも1つの構文要素を含む、請求項1に記載の方法。
前記第1および第2のNALUヘッダは、それぞれ第1および第2の構文要素コンポーネントタイプを含み、前記少なくとも1つの第2のコンポーネントが前記少なくとも1つの第1のコンポーネントと異なることを示すことは、前記第2の構文要素コンポーネントタイプの値が前記第1の構文要素コンポーネントタイプの値とは異なることである、請求項7に記載の方法。
請求項１～８のうちいずれか一項に記載の方法を行うように構成された、ビデオシーケンスを復号するための装置。
ビデオ復号のための装置のコンピュータに、請求項１～８のうちいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
請求項１から８のうちいずれか一項に記載の方法で復号されるデータを生成するための、エンコーダにおけるビデオ符号化方法。