特表 2022-511903 ネットワーク抽象化レイヤユニットヘッダ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-02-01

(54)【発明の名称】ネットワーク抽象化レイヤユニットヘッダ

(51)【国際特許分類】

   H04N 19/70 20140101AFI20220125BHJP

【ＦＩ】

H04N19/70

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021532467

(86)(22)【出願日】2020-03-04

(85)【翻訳文提出日】2021-06-08

(86)【国際出願番号】 US2020020955

(87)【国際公開番号】W WO2020180966

(87)【国際公開日】2020-09-10

(31)【優先権主張番号】62/814,661

(32)【優先日】2019-03-06

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/459,883

(32)【優先日】2019-07-02

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】ステファン・ヴェンガー

(72)【発明者】

【氏名】ビョンドゥ・チェ

(72)【発明者】

【氏名】シャン・リュウ

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159MA04

5C159MA05

5C159MA21

5C159MA33

5C159MC11

5C159ME01

5C159PP04

5C159RC11

(57)【要約】

少なくとも１つのプロセッサが実行する、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する方法は、ＮＡＬユニットヘッダに含まれる第１のシンタックス要素を復号するステップと、前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、ＮＡＬユニットヘッダに含まれる第２のシンタックス要素を復号するステップと、前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて、前記ＮＡＬユニットを再構築するステップと、前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記第２のシンタックス要素に基づいて、時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて、前記ＮＡＬユニットを再構築するステップと、を含む。

【特許請求の範囲】

【請求項1】

少なくとも１つのプロセッサが実行する、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する方法であって、
ＮＡＬユニットヘッダに含まれる、第１の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第１のシンタックス要素を復号するステップと、
前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、
前記ＮＡＬユニットヘッダに含まれる、第２の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第２のシンタックス要素を復号するステップと、
前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて、前記ＮＡＬユニットを再構築するステップと、
を含む方法。

【請求項2】

前記ＮＡＬユニットクラスが前記第１のＮＡＬユニットクラスであることに基づいて、時間的識別子（ＴＩＤ）がゼロであると決定される、請求項１に記載の方法。

【請求項3】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが複数の時間的レイヤに関連することを示す、請求項１に記載の方法。

【請求項4】

前記パラメータセットは、デコーダパラメータセット、ビデオパラメータセット、およびシーケンスパラメータセットのうちの少なくとも１つを含む、請求項３に記載の方法。

【請求項5】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが単一の符号化ピクチャに関連することを示す、請求項１に記載の方法。

【請求項6】

前記パラメータセットは、ピクチャパラメータセット、スライスパラメータセット、適応パラメータセット、およびヘッダパラメータセットのうちの少なくとも１つを含む、請求項５に記載の方法。

【請求項7】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットが非規範的データに関連することを示す、請求項１に記載の方法。

【請求項8】

前記非規範的データは、補助強化情報、フィラーデータ、およびピクチャデリミタデータを含む、請求項７に記載の方法。

【請求項9】

前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、
前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築するステップをさらに含む、請求項１に記載の方法。

【請求項10】

前記第１のシンタックス要素は、禁止されたゼロビットを含む、請求項１に記載の方法。

【請求項11】

ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する装置であって、
プログラムコードを記憶するように構成される少なくとも１つのメモリと、
前記プログラムコードを読み取り、前記プログラムコードによって指示されたとおりに動作するように構成される少なくとも１つのプロセッサであって、前記プログラムコードは、
前記少なくとも１つのプロセッサに、ＮＡＬユニットヘッダに含まれる、第１の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第１のシンタックス要素を復号させるように構成される第１の復号コードと、
前記少なくとも１つのプロセッサに、前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定させるように構成される第１の決定コードと、
前記少なくとも１つのプロセッサに、前記ＮＡＬユニットヘッダに含まれる、第２の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第２のシンタックス要素を復号させるように構成される第２の復号コードと、
前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて前記ＮＡＬユニットを再構築することを、少なくとも１つのプロセッサに実行させるように構成される第２の決定コードと、
前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築することを、前記少なくとも１つのプロセッサに実行させるように構成される第３の決定コードと、を含む、前記少なくとも１つのプロセッサと、
を備える装置。

【請求項12】

前記ＮＡＬユニットクラスが前記第１のＮＡＬユニットクラスであることに基づいて、時間的識別子（ＴＩＤ）がゼロであると決定される、請求項１１に記載の装置。

【請求項13】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが複数の時間的レイヤに関連することを示す、請求項１１に記載の装置。

【請求項14】

前記パラメータセットは、デコーダパラメータセット、ビデオパラメータセット、およびシーケンスパラメータセットのうちの少なくとも１つを含む、請求項１３に記載の装置。

【請求項15】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが単一の符号化ピクチャに関連することを示す、請求項１１に記載の装置。

【請求項16】

前記パラメータセットは、ピクチャパラメータセット、スライスパラメータセット、適応パラメータセット、およびヘッダパラメータセットのうちの少なくとも１つを含む、請求項１５に記載の装置。

【請求項17】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットが非規範的データに関連することを示す、請求項１１に記載の装置。

【請求項18】

前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記プログラムコードは、前記少なくとも１つのプロセッサに、前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定させ、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築させるように構成される第３の決定コードをさらに含む、請求項１１に記載の装置。

【請求項19】

前記第１のシンタックス要素は、禁止されたゼロビットを含む、請求項１１に記載の装置。

【請求項20】

命令を記憶する非一時的なコンピュータ読取可能な媒体であって、前記命令は、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する装置の１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、
ＮＡＬユニットヘッダに含まれる第１のシンタックス要素を復号するステップと、
前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、
前記ＮＡＬユニットヘッダに含まれる第２のシンタックス要素を復号するステップと、
前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて、前記ＮＡＬユニットを再構築するステップと、を実行させる１つまたは複数の命令を含む、非一時的なコンピュータ読取可能な媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、３５Ｕ．Ｓ．Ｃ．§１１９の下で、２０１９年３月６日に米国特許商標庁に出願された米国仮出願第６２／８１４，６６１号、および２０１９年７月２日に米国特許商標庁に出願された米国出願第１６／４５９，８８３号に基づく優先権を主張し、その内容を全て参照により本明細書に組み込むものとする。

【0002】

開示された主題は、ビデオ符号化および復号に関し、より具体的には、特定のビットが、時間的レイヤプロパティを持つネットワーク抽象化レイヤ（Network Abstraction Layer、ＮＡＬ－）ユニットについては時間的ＩＤに使用され、時間的レイヤプロパティを持たないＮＡＬユニットについては他の目的のために使用される、ＮＡＬユニットヘッダの符号化に関するものである。

【背景技術】

【0003】

動き補償を伴うイントラピクチャ予測を使用するビデオ符号化および復号の例は、何十年も前から知られている。非圧縮デジタルビデオは一連のピクチャを含むことができ、各ピクチャは、例えば、１９２０×１０８０輝度サンプルと関連する彩度サンプルの空間寸法を持っている。この一連のピクチャは、例えば毎秒６０ピクチャまたは６０Ｈｚの固定または可変ピクチャレート（非公式には「フレームレート」とも呼ばれる）を持つことができる。非圧縮ビデオには、顕著なビットレート要件がある。例えば、サンプルあたり８ビットでの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚフレームレートでの１９２０×１０８０輝度サンプル解像度）には、１．５Ｇｂｉｔ／ｓに近い帯域幅が必要となる。このようなビデオを１時間使用するには、６００ＧＢｙｔｅｓを超えた記憶空間が必要である。

【0004】

ビデオ符号化および復号の１つの目的は、圧縮によって入力ビデオ信号の冗長性を減らすことであり得る。圧縮は、前述の帯域幅または記憶空間の要件を、場合によっては２桁以上削減するのに役立つ。可逆圧縮と非可逆圧縮の両方、およびそれらの組み合わせを使用することができる。可逆圧縮とは、圧縮された元の信号から元の信号の正確なコピーを再構築できる技法を指す。非可逆圧縮を使用する場合、再構築された信号は元の信号と同一ではない可能性があるが、元の信号と再構築された信号の間の歪みは、再構築された信号を意図されたアプリケーションに役立てる程度に小さい。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量はアプリケーションによって異なる。例えば、特定のコンシューマストリーミングアプリケーションのユーザは、テレビ発行アプリケーションのユーザよりも高い歪みを許容できる。達成可能な圧縮率は、受け入れ可能／許容可能な歪みが大きいほど、圧縮率が高くなることを反映することができる。

【0005】

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

【0006】

ネットワーク抽象化レイヤの例は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６４に提出された。符号化ビデオビットストリームは、ネットワーク抽象化レイヤ（ＮＡＬ－）ユニットと呼ばれる個々のユニットに分割されることができる。各ＮＡＬユニットは、開始符号エミュレーション防止に順守することなく解釈できるヘッダを持つことができる（ＮＡＬユニットの他の部分で順守する必要があり、実施および計算に多大なコストがかかる可能性がある）。Ｈ．２６４（１０１）のＮＡＬユニットヘッダは、図１に示すように、固定長のコードワードのみを含むように設計された。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ（１０２）の特定の値については、ＮＡＬユニットヘッダ（１０３）に第２のオクテット、場合によっては第３のオクテットを追加することで、特定の拡張が可能であり、各オクテットに固定長のコードワードが含まれていた。メディアアウェアネットワーク要素（Ｍｅｄｉａ Ａｗａｒｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ、ＭＡＮＥ）、ＭＣＵ、ファイル書き換え装置などは、これらの固定長のコードワードを用いて、完全なトランスコードを行わずに、また、開始符号エミュレーション防止に制約されることなく、ビットストリームを効果的に調整することができる。

【0007】

Ｈ．２６５では、やや簡略化された設計が選択された。Ｈ．２６５のＮＡＬユニットヘッダ（１０４）は２オクテットの固定長であり、ＮＡＬユニットタイプ（１０５）、空間／ＳＮＲレイヤＩＤ（１０６）、時間的レイヤＩＤ（１０７）が含まれていた。拡張メカニズムは存在しなかった。Ｈ．２６４の設計と比較して、この設計は、ヘッダが常に２オクテットの長さであったのに対し、Ｈ．２６４の設計では可変長であるが、多くの場合１オクテットの長さであったため、一定の符号化効率の損失があった。一方、スケーラブルおよびマルチビューの拡張機能のサポートは大幅に簡素化され、スケーラブル／マルチビューと非スケーラブル／マルチビューのレガシーエンコードの間にある程度の後方互換性を可能にした。

【発明の概要】

【課題を解決するための手段】

【0008】

一実施形態では、少なくとも１つのプロセッサが実行する、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する方法が提供され、この方法は、ＮＡＬユニットヘッダに含まれる第１のシンタックス要素を復号するステップと、前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、前記ＮＡＬユニットヘッダに含まれる第２のシンタックス要素を復号するステップと、前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて、前記ＮＡＬユニットを再構築するステップと、前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築するステップと、を含む。

【0009】

一実施形態では、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する装置が提供され、この装置は、プログラムコードを記憶するように構成される少なくとも１つのメモリと、前記プログラムコードを読み取り、前記プログラムコードによって指示されたとおりに動作するように構成される少なくとも１つのプロセッサと、を備える。前記プログラムコードは、前記少なくとも１つのプロセッサに、ＮＡＬユニットヘッダに含まれる第１のシンタックス要素を復号させるように構成される第１の復号コードと、前記少なくとも１つのプロセッサに、前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定させるように構成される第１の決定コードと、前記少なくとも１つのプロセッサに、前記ＮＡＬユニットヘッダに含まれる第２のシンタックス要素を復号させるように構成される第２の復号コードと、前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて前記ＮＡＬユニットを再構築することを、少なくとも１つのプロセッサに実行させるように構成される第２の決定コードと、前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築することを、前記少なくとも１つのプロセッサに実行させるように構成される第３の決定コードと、を含む。

【0010】

一実施形態では、命令を記憶する非一時的なコンピュータ読取可能な媒体が提供され、前記命令は、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する装置の１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、ＮＡＬユニットヘッダに含まれる第１のシンタックス要素を復号するステップと、前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、前記ＮＡＬユニットヘッダに含まれる第２のシンタックス要素を復号するステップと、前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて前記ＮＡＬユニットを再構築するステップと、前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築するステップと、を実行させる１つまたは複数の命令を含む。

【0011】

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

【図面の簡単な説明】

【0012】

【図1】Ｈ．２６４とＨ．２６５に準拠するＮＡＬユニットヘッダの模式図である。

【図2】一実施形態による通信システムの概略ブロック図である。

【図3】一実施形態による通信システムの概略ブロック図である。

【図4】一実施形態によるデコーダの概略ブロック図である。

【図5】一実施形態によるエンコーダの概略ブロック図である。

【図6】一実施形態による、ＮＡＬユニットタイプクラスを使用するＮＡＬユニットヘッダの概略図である。

【図7】一実施形態による、ビデオ復号のためのネットワーク抽象化レイヤ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ、ＮＡＬ）ユニットを再構築するための処理の一例を示すフローチャートである。

【図8】一実施形態によるコンピュータシステムの概略図である。

【発明を実施するための形態】

【0013】

本開示は、ビデオ符号化および復号に関し、より具体的には、特定のビットが、時間的レイヤプロパティを持つネットワーク抽象化レイヤ（Network Abstraction Layer、ＮＡＬ－）ユニットについては時間的ＩＤに使用され、時間的レイヤプロパティを持たないＮＡＬユニットについては他の目的のために使用される、ＮＡＬユニットヘッダの符号化に関するものである。

【0014】

Ｈ．２６４ ＮＡＬユニットヘッダは多くの場合、コンパクトであるが、特定のアプリケーションに実用されているかもしれない時間的スケーラビリティを含む特定のアプリケーションには不十分である。Ｈ．２６５ ＮＡＬユニットヘッダは、時間的スケーラビリティを効果的にサポートするが、最低１６ビットが必要であり、将来の拡張のために未割り当てのコードポイントは、たとえあるとしてもごくわずかである。一方、Ｈ．２６５ ＮＡＬユニットヘッダのシンタックス要素には、暗黙的に拒否される特定の値の組み合わせがあり、不必要な低エントロピーにつながる。例えば、シーケンスパラメータセットなどの特定のパラメータセットは、定義上、すべての時間的レイヤに属するＮＡＬユニットから構成される符号化ビデオシーケンス全体に適用される。それでも、シーケンスパラメータセットのＨ．２６５ ＮＡＬユニットヘッダは、任意のコンプライアントビットストリームでゼロでなければならない時間的ＩＤフィールドのために３ビットが浪費される。これらのビットを再利用することで、符号化効率を高めることができる。

【0015】

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

【0016】

図２は、例えば、ビデオ会議中に発生し得る符号化されたビデオデータの双方向送信をサポートするために提供される第２の対の端末（２３０，２４０）を示している。データの双方向送信の場合、各端末（２３０，２４０）は、ネットワーク（２５０）を介して他方の端末へ送信するために、ローカル位置でキャプチャされたビデオデータを符号化することができる。各端末（２３０，２４０）は、他方の端末から送信された符号化ビデオデータを受信し、符号化されたデータをデコードし、復元されたビデオデータをローカル表示装置に表示することもできる。

【0017】

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

【0018】

図３は、開示された主題の適用の例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示している。開示された主題は、例えば、ビデオ会議、デジタルＴＶ、および、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの記憶など、を含む他のビデオ対応アプリケーションに等しく適用可能である。

【0019】

ストリーミングシステムは、例えば非圧縮のビデオサンプルストリーム（３０２）を作成するデジタルカメラなどのビデオソース（３０１）を含むことができるキャプチャサブシステム（３１３）を含み得る。エンコードされたビデオビットストリームと比較して高データ量を強調するために太線で示されたサンプルストリーム（３０２）は、カメラ（３０１）に結合されたエンコーダ（３０３）によって処理されることができる。エンコーダ（３０３）は、以下でより詳細に説明されるように、開示された主題の態様を可能にするか或いは実施するためのハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプルストリームと比較してより低いデータ量を強調するために細い線で示された、エンコードされたビデオビットストリーム（３０４）は、将来使うためにストリーミングサーバ（３０５）に記憶されることができる。１つ又は複数のストリーミングクライアント（３０６，３０８）は、ストリーミングサーバ（３０５）にアクセスして、エンコードされたビデオビットストリーム（３０４）のコピー（３０７，３０９）を検索することができる。クライアント（３０６）は、エンコードされたビデオビットストリームの入り方向コピー（３０７）をデコードし、ディスプレイ（３１２）または他のレンダリングデバイス（図示せず）でレンダリングできる出方向ビデオサンプルストリームストリーム（３１１）を作成するビデオデコーダ（３１０）を含むことができる。一部のストリーミングシステムにおいて、ビデオビットストリーム（３０４，３０７，３０９）は、特定のビデオ符号化／圧縮規格に従ってエンコードされることができる。これらの規格の例は、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。非公式的にヴァーサトゥルビデオ符号化（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）またはＶＶＣとして知られるビデオ符号化規格は、発展中である。開示された主題は、ＶＶＣの文脈に使用され得る。

【0020】

図４は、本開示の一実施形態によるビデオデコーダ（３１０）の機能ブロック図であってもよい。

【0021】

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

【0022】

ビデオデコーダ（３１０）は、エントロピー符号化されたビデオシーケンスからシンボル（４２１）を再構築するパーサ（４２０）を含んでもよい。これらのシンボルのカテゴリは、デコーダ（３１０）の動作を管理するために使用される情報を含んで、デコーダの不可欠な部分ではないが、図３に示されるようにデコーダに結合され得るディスプレイ（３１２）などのレンダリングデバイスを制御する情報を潜在的に含む。レンダリングデバイスのための制御情報は、補助強化情報（ＳＥＩメッセージ）またはビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（図示せず）の形態であってよい。パーサ（４２０）は、受信された符号化ビデオシーケンスを構文解析／エントロピーデコードすることができる。符号化ビデオシーケンスの符号化は、可変長符号化、ハフマン符号化、文脈感受性を有するもしくは有さない算術符号化などを含む、ビデオ符号化技術または規格に合わせることができ、当業者によく知られている原理に従うことができる。パーサ（４２０）は、グループに対応する少なくとも１つのパラメータに基づいて、符号化ビデオシーケンスからビデオデコーダ内の画素の少なくとも１つのサブグループのためのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャ群（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）などを含むことができる。エントロピーデコーダ／パーサは、符号化ビデオシーケンスから変換係数、量子化パラメータ値、動きベクトルなどのような情報をも抽出することができる。

【0023】

パーサ（４２０）は、シンボル（４２１）を作成するために、バッファ（４１５）から受信されたビデオシーケンスに対してエントロピーデコード／構文解析動作を実行することができる。

【0024】

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

【0025】

すでに述べた機能ブロックに加え、デコーダ３１０は、以下で説明されるようにいくつかの機能ユニットに概念的に細分されることができる。商業的な制約の下で実際の実施操作にあたっては、これらのユニットの多くは互いに密接に相互作用し、少なくとも一部は互いに統合することができる。しかしながら、開示された主題の説明の目的で、以下の機能ユニットへの概念的な細分は、適切に行われる。

【0026】

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

【0027】

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

【0028】

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

【0029】

アグリゲータ（４５５）の出力サンプルは、ループフィルタユニット（４５６）において様々なループフィルタリング技法を受けられる。ビデオ圧縮技術は、符号化されたビデオビットストリームに含まれる、パーサ（４２０）からのシンボル（４２１）としてループフィルタユニット（４５６）に利用可能とされたパラメータによって制御されることができ、それに、符号化ピクチャまたは符号化ビデオシーケンスの（デコード順で）前の部分のデコード中に取得されたメタ情報に応じるとともに、予め再構築されループフィルタリングされたサンプル値に応じることもできるループ内フィルタ技術を含むことができる。

【0030】

ループフィルタユニット（４５６）の出力は、レンダリングデバイス（３１２）へ出力されることができるとともに、将来のインターピクチャ予測で使用するために参照ピクチャメモリに記憶されることができるサンプルストリームであり得る。

【0031】

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

【0032】

ビデオデコーダ３１０は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの規格で文書化され得る所定のビデオ圧縮技術に従ってデコード操作を実行することができる。符号化ビデオシーケンスは、ビデオ圧縮技術の文書または規格、具体的にはその中のプロファイル文書で指定されているように、ビデオ圧縮技術または規格のシンタックスに準拠しているという意味で、使用されているビデオ圧縮技術または規格によって指定されるシンタックスに準拠し得る。符号化ビデオシーケンスの複雑さがビデオ圧縮技術または規格のレベルで定義される範囲内にあることも、コンプライアンスに必要である。場合によっては、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート（例えば、１秒あたりのメガサンプルで測定される）、最大参照ピクチャサイズなどがレベルによって制限される。レベルによって設定された制限は、場合によっては、符号化ビデオシーケンスでシグナリングされたＨＲＤバッファ管理のための仮想参照デコーダ（ＨＲＤ）仕様およびメタデータによってさらに制限され得る。

【0033】

一実施形態では、受信機（４１０）は、エンコードされたビデオとともに追加の（冗長な）データを受信することができる。追加のデータは、符号化ビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードし、及び／又は、元のビデオデータをより正確に再構築するためにビデオデコーダ（３１０）によって使用され得る。追加のデータは、例えば、時間的、空間的、またはＳＮＲエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方向誤り訂正コードなどの形態にされることができる。

【0034】

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

【0035】

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

【0036】

ビデオソース（３０１）は、エンコーダ（３０３）によって符号化されるソースビデオシーケンスを、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット、・・・）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、・・・）および任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であり得るデジタルビデオサンプルストリームの形態で提供し得る。メディア供給システムでは、ビデオソース（３０１）は、予め準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース（３０ｌ）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、順番に見られるときに動きが与えられる複数の個別のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間アレイとして編成されてもよく、各画素は、使用中のサンプリング構造、色空間などに応じて１つ又は複数のサンプルを含むことができる。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明ではサンプルを中心に説明する。

【0037】

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

【0038】

ビデオエンコーダには、当業者が「符号化ループ」として容易に認識できる方法で動作するものがある。過度に簡略化した説明として、符号化ループは、エンコーダのエンコード部分（５３０）（以下、「ソースコーダ」）（符号化対象となる入力ピクチャおよび参照ピクチャに基づくシンボルの作成を担当する）、および、シンボルを再構築して、（リモート）デコーダも作成するサンプルデータを作成する（シンボルと符号化されたビデオビットストリーム間の如何なる圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるためである）エンコーダ（３０３）に埋め込まれた（ローカル）デコーダ（５３３）を含むことができる。再構築されたサンプルストリームは参照ピクチャメモリ（５３４）に入力される。シンボルストリームのデコードにより、デコーダの位置（ローカルまたはリモート）に関係なくビット正確な結果が得られるため、参照ピクチャバッファのコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えれば、エンコーダの予測部分は、参照ピクチャサンプルとして、デコード中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を「見る」。参照ピクチャの同期性の該基本原理（および例えばチャネルエラーに起因して同期性を維持できない場合に生じるドリフト）は、当業者にはよく知られている。

【0039】

「ローカル」デコーダ（５３３）の動作は、前文で図４に関連して既に詳細に説明された、「リモート」デコーダ（３１０）の動作と同様であり得る。しかしながら、図４をも簡単に参照し、シンボルが使用可能であり、エントロピーコーダ（５４５）およびパーサ（４２０）による符号化ビデオシーケンスへのシンボルのエンコード／デコードは可逆であり得るので、チャネル（４１２）、受信機（４１０）、バッファ（４１５）、およびパーサ（４２０）を含むデコーダ（３１０）のエントロピーデコード部分は、ローカルデコーダ（５３３）では完全に実施されない場合がある。

【0040】

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

【0041】

ソースコーダ（５３０）は、その動作の一部として、「参照フレーム」として指定されたビデオシーケンスからの１つ又は複数の予め符号化されたフレームを参照して入力フレームを予測的に符号化する動き補償予測符号化を実行してもよい。このようにして、符号化エンジン（５３２）は、入力フレームの画素ブロックと、入力フレームへの予測基準として選択され得る参照フレームの画素ブロックとの差異を符号化する。

【0042】

ローカルビデオデコーダ（５３３）は、ソースコーダ（５３０）で作成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータをデコードすることができる。符号化エンジン（５３２）の動作は、有利にはロッシープロセスであり得る。符号化ビデオデータがビデオデコーダ（図５に図示せず）でデコードされ得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ（５３３）は、ビデオデコーダによって参照フレームに対して実行され得るデコードプロセスを再現し、再構築された参照フレームを参照ピクチャキャッシュ（５３４）に記憶させることができる。このようにして、エンコーダ（３０３）は、遠端ビデオデコーダによって取得される再構築された参照フレームと共通するコンテンツ（送信エラー無し）を有する再構築された参照ピクチャのコピーをローカルに記憶し得る。

【0043】

予測器（５３５）は、符号化エンジン（５３２）の予測検索を実行することができる。つまり、符号化対象となる新しいフレームについて、予測器（５３５）は、（候補の参照画素ブロックとしての）サンプルデータ、または、参照ピクチャの動きベクトル、ブロック形状など、新しいピクチャの適切な予測基準として機能し得る特定のメタデータを参照ピクチャメモリ（５３４）で検索することができる。予測器（５３５）は、適切な予測基準を見つけるために、サンプルブロック／画素ブロックごとに動作することができる。場合によっては、予測器（５３５）で取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（５３４）に記憶された複数の参照ピクチャから引き出された予測基準を有してもよい。

【0044】

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

【0045】

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

【0046】

送信機（５４０）は、エントロピーコーダ（５４５）によって作成された符号化ビデオシーケンスをバッファリングして、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル（５６０）を介した送信に備えることができる。送信機（５４０）は、ビデオコーダ（５３０）からの符号化ビデオデータを、送信されるべき他のデータ、例えば、符号化オーディオデータ及び／又は補助データストリーム（ソースは図示せず）とマージすることができる。

【0047】

コントローラ（５５０）は、エンコーダ（３０３）の動作を管理し得る。符号化中、コントローラ（５５０）は、各符号化ピクチャに特定の符号化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得る符号化技法に影響を及ぼす可能性がある。例えば、ピクチャは多くの場合、次のフレームタイプのいずれかとして割り当てられてもよい。

【0048】

イントラピクチャ（Ｉピクチャ）は、シーケンス内の他のいかなるフレームを予測源として使用することなく、符号化および復号されることができるピクチャのことである。ビデオコーデックの中には、例えば、インディペンデントデコーダリフレッシュピクチャ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ Ｐｉｃｔｕｒｅ）を含む、異なるタイプのイントラピクチャを許容するものがある。当業者であれば、それらのＩピクチャの変形およびそれぞれの用途および特徴を知っている。

【0049】

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

【0050】

双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために、最大２つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測により符号化および復号されることができるピクチャのことである。同様に、多重予測ピクチャは、単一のブロックの再構築のために、２つを超えた参照ピクチャおよび関連メタデータを使用することができる。

【0051】

ソースピクチャは、一般に、複数のサンプルブロック（例えば、それぞれ、４×４、８×８、４×８、または１６×１６サンプルのブロック）に空間的に細分され、ブロック単位で符号化され得る。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定された他の（既に符号化された）ブロックを参照して予測的に符号化され得る。例えば、Ｉピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい（空間予測またはイントラ予測）。Ｐピクチャの画素ブロックは、予め符号化された１つの参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的に符号化され得る。Ｂピクチャのブロックは、予め符号化された１つまたは２つの参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的に符号化され得る。

【0052】

ビデオコーダ（３０３）は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの予め設定されたビデオ符号化技術または規格に従って、符号化動作を行うことができる。動作中、ビデオコーダ（３０３）は、入力ビデオシーケンスの時間的および空間的冗長性を利用する予測符号化動作を含む、様々な圧縮動作を実行することができる。したがって、符号化ビデオデータは、使用されるビデオ符号化技術または規格によって指定されたシンタックスに準拠する場合がある。

【0053】

一実施形態では、送信機（５４０）は、エンコードされたビデオとともに追加のデータを送信することができる。ビデオコーダ（５３０）は、そのようなデータを符号化ビデオシーケンスの一部として含み得る。追加のデータは、時間的／空間的／ＳＮＲエンハンスメントレイヤ、冗長なピクチャやスライスなどの他の形態での冗長なデータ、補助強化情報（Ｓｕｐｐｌｅｍｅｎｔａｒｙ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ、ＳＥＩ）メッセージ、ビデオユーザビリティ情報（Ｖｉｓｕａｌ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ、ＶＵＩ）パラメータセットフラグメントなどを含み得る。

【0054】

以下では、ビデオコーデックの高レベルシンタックス、特にＮＡＬユニットヘッダ（ＮＵＨ）の設計に焦点を当てて説明する。

【0055】

ＮＵＨは、複雑なシンタックスを扱うことが期待できるデコーダによって解釈されるだけでなく、ＭＡＮＥ、ファイル書き換え装置など（以下、ＭＡＮＥ）によっても解釈され得るため、その設計は、可変長符号（ＶＬＣ）や算術符号化などの複雑なエントロピー符号化スキームを避けなければならないことがある。一方、シンタックス要素の条件付き存在または条件付き解釈を含むある程度の複雑さは、特にそれらのシンタックス要素で伝達される情報をＮＵＨの外に移動してＮＡＬユニットペイロードに移動する必要がある場合、またはＮＵＨを不必要に大きくする必要がある場合は、許容可能である。

【0056】

ＭＡＮＥによる処理のしやすさなど、様々な理由から、ＮＵＨはオクテット整列されており（これは、ビット単位の長さは８で割り切れることを意味する）、そうしないと、（レート歪み性能および計算の複雑さの点で）不要で高価なパディングが必要になる場合がある。また、ＭＰＥＧ－２トランスポートストリームチャンネルでビデオを伝送する際には、開始符号エミュレーション防止のために、最低でも１ビット（Ｈ．２６４およびＨ．２６５ ＮＵＨの両方でｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔと呼ばれる）が必要になる場合がある。この仮定の下で、ＮＡＬユニットヘッダの理論上の最小長は８ビットとなる。最も一般的なＮＡＬユニットタイプ（ＮＵＴ）については、これらの８ビット内に収まるように設計すべきであるが、よりエキゾチックで頻度の低いＮＵＴ、または、例えばＩピクチャとその派生ピクチャ或いは基本的に非圧縮形式で符号化されたピクチャなど、符号化されたピクチャタイプに対する割合としてのヘッダのオーバーヘッドが無視できるＮＵＴについては、より多くのビットを必要とする場合がある。そのため、ＮＡＬユニットヘッダのフィールドに必要なビット数を最小限に抑えることが重要になる場合がある。個々のフィールドの長さを短くすることができれば、それは有利になる場合がある。しかし、フィールドの長さが短くなると、フィールドで表現できる使用可能なコードポイントの数が少なくなることを意味する。

【0057】

Ｈ．２６５の発展中に、Ｈ．２６４のものと比較して多数の追加のＮＵＴが確認された。さらに、Ｈ．２６５では、ＮＡＬユニットヘッダの時間的スケーラビリティシグナリングが、Ｈ．２６５のメインプロフィールと呼ばれるベースラインプロフィールに提出され、現在、一般的に使用されることができる。ＶＶＣなどの将来のビデオ符号化規格では、ＮＵＴの数も時間的スケーラビリティの必要性もなくなることはないと予想できる。ＮＵＴに６ビット、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔに１ビット、時間的レイヤリング情報に３ビットを使用すると、１つは１０ビットになるため、オクテット整列により、Ｈ．２６５では１６ビットのＮＵＨになる。同様の計算が、執筆時点でのＶＶＣワーキングドラフトにも適用される。

【0058】

それでも、符号化効率の観点から、少なくとも、Ｐピクチャ／スライス／タイルグループ、Ｂピクチャ／スライス／タイルグループなどを含み得る後端のピクチャなどの最も一般的なＮＵＴについては、時間的スケーラビリティシグナリングのオプションを維持しつつ、単一のオクテットのみのＮＵＨを使用することが望ましいであろう。時間的ＩＤに３ビット、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔに１ビットが必要であるとすると、ＮＵＴフィールドには４ビットしか利用できず、結果的に合計１６個のＮＵＴが可能となる。Ｈ．２６５も、ＶＶＣなどの将来のビデオ符号化規格も、１６個以下のＮＵＴを使用する可能性はない。

【0059】

開示された主題の実施形態は、設計により、すべての時間的レイヤに適用され得るか、または時間的レイヤリングとは概念的に独立しているそれらのＮＡＬユニットタイプのために、ＮＵＴの追加のデマルチプレックスポイントとして、時間的ＩＤのために留保されたビットを条件付きで使用することによって、この要望を実現する。

【0060】

特定のＮＡＬユニットタイプは、時間的レイヤリングから独立していてもよい。多くの場合、Ｈ．２６５などの関連技術では、これらのＮＡＬユニットについて、時間的ＩＤをゼロに設定することがビットストリーム・コンプライアンスの要件になっている。その他の場合、Ｈ．２６５などの関連技術は、デコーダに対して時間的ＩＤの値を無視するように指示したり、このフィールドで許容される値について沈黙したりするが、これは同じ効果をもたらす可能性がある。

【0061】

それらの時間的ＩＤにとらわれないＮＡＬユニットタイプの例は次の通りである。

【0062】

（１）おそらく過度に広範な特性として、多くのＮＡＬ ＮＵＴは時間的レイヤプロパティを持たないかもしれない。対照的に、多くのＶＣＬ ＮＵＴは時間的レイヤプロパティを持つかもしれない。

【0063】

（２）例えばデコーダパラメータセット、ビデオパラメータセット、およびシーケンスパラメータセットを含む特定のパラメータセットは、少なくとも符号化ビデオシーケンス（ＣＶＳ）をその範囲として有し得る。ＣＶＳは、定義上、複数の時間的レイヤに属するＮＡＬユニットを含むことができる。したがって、そのようなパラメータセットは、時間的ＩＤにとらわれない場合がある。

【0064】

（３）例えばピクチャパラメータセット、スライスパラメータセット、適応パラメータセット、ヘッダパラメータセットなどの「下位」パラメータセットは、単一の符号化ピクチャまたはその一部をその範囲として有してもよい。所与の符号化ピクチャは、定義された時間的レイヤを有してもよい。そのため、場合によっては、これらのパラメータセットのパラメータセットＮＡＬユニット内の時間的ＩＤを使用して、タイプおよびパラメータセットＩＤは同じであるが、時間的レイヤが異なるパラメータセットを区別することが賢明であり得る。例えば、使用中の複数の時間的レイヤをカバーする、ピクチャパラメータセットＩＤが０である複数のピクチャパラメータセットを持つことが賢明であり得る。このような設計上の選択が賢明である理由は、パラメータセットＩＤの符号化が、場合によっては、（Ｈ．２６５で確立された規則に従って文書化された場合、ｕｅ（ｖ）の記述子を持つ）スライス／タイル／タイルグループヘッダの可変長符号化フィールドであるためである。ｕｅ（ｖ）のシンタックス要素は、値が大きくなるとサイズが急速に大きくなるが、ＮＡＬユニットヘッダの時間的ＩＤフィールドは３ビットに固定されている。また、所与のビットストリームには、ｕｅ（ｖ）符号化されたパラメータセットＩＤを備えるスライス／タイル／タイルグループヘッダを含むＮＡＬユニットが、同じビットストリーム内のパラメータセットＮＡＬユニットよりも多く存在する可能性がある。

【0065】

一方、このような「下位」パラメータセットの時間的ＩＤフィールドをデマルチプレックスポイントとして使用しない場合、ＮＡＬユニットヘッダを８ビットから１６ビットに拡張する必要があり、これは、わずかに長いｕｅ（ｖ）で符号化されたパラメータセットＩＤのシンタックス要素よりもかなりコストがかかる可能性がある。そのため、「下位」パラメータセットであっても、時間的ＩＤをデマルチプレックスポイントとして使用し、時間的レイヤに関連付けられた「下位」タイプの複数のパラメータセットを表すためにパラメータセットＩＤのより大きなナンバリングスペースに依存することが理にかなっていることがある。本稿執筆時点でのＶＶＣドラフトはそれを認識し、ピクチャパラメータセット又は適応パラメータセットに時間的ＩＤフィールドを使用していない。その結果、それらのパラメータセットのタイプは、時間的ＩＤフィールドに使用されるビットによってデマルチプレクスされることもできる。

【0066】

（４）特定のＮＡＬユニットタイプは、特定のクラスのＳＥＩメッセージや、フィラーデータ、ピクチャデリミタなどの他の非規範的データ、およびエンド・オブ・ストリーム・マーカなどの特定のマーカのために留保されることがある。それらのＮＡＬユニットが時間的ＩＤを監視しない限り、これらのＮＡＬユニットはすべて単一のＮＡＬユニットタイプを共有し、時間的ＩＤの値によって区別され得る。

【0067】

図６は、Ｈ．２６４のものとサイズが似ている、すなわち８ビットである一実施形態によるＮＵＨ（６０１）の例を示している。ＮＵＨ（６０１）の例は、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ（６０２）、４ビットのＮＡＬＵクラスのシンタックス要素（６０３）、および３ビットのＴＩＤタイプのシンタックス要素（６０４）を含む。ＴＩＤタイプのシンタックス要素は、一実施形態によれば、特定のＮＡＬＵクラスに対して、そのクラスのＮＡＬユニットタイプを区別するための追加のデマルチプレックスポイントとして、再利用することができる。例えば、以下でより詳細に説明されるように、例示的なＮＵＨ（６０５）においてＮＡＬクラスがＩＲＡＰクラス（６０６）に設定されている場合、ＮＡＬユニットタイプをＩＤＲ＿Ｎ＿ＬＰとして識別するためにＴＩＤタイプビット（ここでは１であり、ＩＤＲ－Ｎ－ＬＰ ＮＡＬユニットを識別する）（６０７）の値の使用をトリガすることができる。

【0068】

多用途ビデオ符号化（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ、ＶＶＣ）は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６６としても公開される。ＪＶＥＴ－Ｍ１００１－ｖ５として公開されているＶＶＣ Ｄｒａｆｔ ４ ｖｅｒｓｉｏｎ ５のワーキングドラフトを参照すると、ＶＶＣ ＮＡＬユニットヘッダが１６ビットを占めていることが分かる（ＪＶＥＴ－Ｍ１００１－ｖ５の２７ページを参照）。具体的には、ＶＶＣ ＮＵＨは、禁止されたゼロビット（ｆｏｒｂｉｄｄｅｎ ｚｅｒｏ ｂｉｔ）として１ビット、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅのために５ビット、時間的ＩＤのために３ビットを使用し、７ビットを留保している。

【0069】

以下の表１および表２は、ＪＶＥＴ－Ｍ１００１－ｖ５の表７－１に対応している。

【0070】

【表1】

【0071】

【表2】

【0072】

しかし、未指定／留保済みのビット／コードポイントおよび暗黙的拡張性を無視すると、この１６ビットヘッダの全機能は、本開示事項に従って、以下の実施形態と同じまたは別の実施形態において、８ビットのＮＵＨを使用して実施されることができる。

【0073】

示されているように、８ビットのＮＵＨを使用すると、ＶＶＣにおいて現在定義されているＮＡＬユニットタイプの全機能（将来の拡張に関して完全な柔軟性である必要はない）を実施するために、８クラスのみが必要とされる。

【0074】

同じまたは別の実施形態では、他の割り当ても可能である。例えば、上記の「ＭＡＲＫＥＲ＿Ｃｌａｓｓ」および「ＳＥＩ＿Ｃｌａｓｓ」としてリストされているものを、例えば以下の表３に示すように、１つのクラスに適切に組み合わせることができる。

【0075】

【表3】

【0076】

表３の例では、４ビットのＮＡＬユニットクラスフィールドを介して有効化された使用可能な１６個のコードポイントのうち、７個のみが使用される。

【0077】

特定の場合において、同じまたは別の実施形態において、「ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ」を追加のデマルチプレクスポイントとして使用することができる。「ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ」は、主にビットストリームがＭＰＥＧ－２システム上で伝送される場合に、特定の限られた環境での開始符号エミュレーションを防ぐために、歴史的にＮＡＬユニットヘッダに含まれていた。おそらく、標準化団体がＭＰＥＧ－２システム上で伝送される必要性を想定していないＶＶＣ技術やビットストリームが存在する可能性がある。これらの技術に関連するＮＡＬユニットは、１に設定されたｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔをデマルチプレクスポイントとして使用している可能性がある。

【0078】

開始符号エミュレーション防止のために、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔが１に設定されている場合、ＮＡＬユニットヘッダの８ビットの２５６個の可能な値のうち１２８個が、ＮＡＬユニットタイプ、時間的ＩＤなどの情報を示すために使用できることが理解されるだろう。特定の環境では、これらの１２８ビットの組み合わせ（１に等しいｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔを持つ）のすべてではなく一部が、特定の開始符号のエミュレーションを防ぐために留保されることがある。例えば、「付録Ｂ」と呼ばれる開始符号エミュレーションを防ぐためには、ＮＡＬユニットヘッダの第１のオクテットの値が０になることだけを避ける必要がある。ＭＰＥＧ－２パッケタイズドエレメンタリーストリーム（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ、「ＰＥＳ－」）チャンネルの開始符号エミュレーションを防ぐためには、１８８から２５５までの値のみを避ける必要がある。他のシステム規格では、異なるが概念的に同等の制約がある。ＮＡＬユニットクラスとＴＩＤタイプの許容値を設定する際には、これらの制約を念頭に置くことで、開始符号エミュレーションが必要な場合でも、禁止されたゼロビットをデマルチプレクスポイントとして使用することができる。

【0079】

同じまたは別の実施形態では、所与のＮＡＬユニットクラスの値は、ＮＡＬユニットヘッダ内の１つまたは複数の追加のオクテットの存在を示すものとして使用されることができる。そのような追加のオクテットは、あまり一般的に使用されないＮＡＬユニットの符号化オプションをさらに拡張するために使用されてもよい。

【0080】

図７は、中間候補を用いてマージ候補リストを生成するための処理７００の一例のフローチャートである。いくつかの実施において、図７の１つまたは複数の処理ブロックは、デコーダ３１０によって実行されてもよい。いくつかの実施において、図７の１つまたは複数の処理ブロックは、エンコーダ３０３など、デコーダ３１０とは別の、またはデコーダ３１０を含む他のデバイスまたはデバイス群によって実行されてもよい。

【0081】

図７に示されるように、処理７００は、ＮＡＬユニットヘッダに含まれる第１のシンタックス要素および第２のシンタックス要素を復号するステップ（ブロック７１０）を含んでもよい。

【0082】

図７にさらに示されるように、処理７００は、第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップ（ブロック７２０）を含んでもよい。

【0083】

図７にさらに示されるように、処理７００は、ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであるか否かを決定するステップ（ブロック７３０）を含んでもよい。ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであれば、処理７００はブロック７４０に進んでもよい。ＮＡＬユニットクラスが第１のＮＡＬユニットクラスではなければ、処理７００は、ブロック７５０に進んでもよい。

【0084】

図７にさらに示されるように、処理７００は、ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、ＮＡＬユニットクラスと第２のシンタックス要素との組み合わせを用いて、ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定されたＮＡＬユニットタイプに基づいてＮＡＬユニットを再構築するステップ（ブロック７５０）を含んでもよい。

【0085】

図７にさらに示されるように、処理７００は、ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであるか否かを決定するステップ（ブロック７５０）を含んでもよい。ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであれば、処理７００は、ブロック７６０に進んでもよい。

【0086】

図７にさらに示されるように、処理７００は、ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定されたＴＩＤに基づいてＮＡＬユニットを再構築するステップ（ブロック７６０）を含んでもよい。

【0087】

一実施形態において、ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、ＴＩＤがゼロであると決定される。

【0088】

一実施形態において、第１のＮＡＬユニットクラスは、ＮＡＬユニットに対応するパラメータセットが複数の時間的レイヤに関連することを示してもよい。

【0089】

一実施形態において、パラメータセットは、デコーダパラメータセット、ビデオパラメータセット、およびシーケンスパラメータセットのうちの少なくとも１つを含んでもよい。

【0090】

一実施形態において、第１のＮＡＬユニットクラスは、ＮＡＬユニットに対応するパラメータセットが単一の符号化ピクチャに関連することを示してもよい。

【0091】

一実施形態において、パラメータセットは、ピクチャパラメータセット、スライスパラメータセット、適応パラメータセット、およびヘッダパラメータセットのうちの少なくとも１つを含んでもよい。

【0092】

一実施形態において、第１のＮＡＬユニットクラスは、ＮＡＬユニットが非規範的データに関連することを示してもよい。

【0093】

一実施形態において、非規範的データは、補助強化情報、フィラーデータ、およびピクチャデリミタデータを含んでもよい。

【0094】

一実施形態において、第１のシンタックス要素は、第１の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含んでもよく、第２のシンタックス要素は、第２の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含んでもよい。

【0095】

一実施形態では、第１のシンタックス要素は、禁止されたゼロビットを含んでもよい。

【0096】

図７は処理７００の例示的なブロックを示しているが、いくつかの実施では、処理７００は、図７に描かれているものよりも追加のブロック、少ないブロック、異なるブロック、または異なる配置のブロックを含んでもよい。さらに、または代わりに、処理７００のブロックのうちの２つまたはそれより多くのブロックを並行して実行してもよい。

【0097】

さらに、提案された方法は、処理回路（例えば、１つまたは複数のプロセッサまたは１つまたは複数の集積回路）によって実施されてもよい。一例では、１つまたは複数のプロセッサは、非一時的なコンピュータ読取可能な媒体に記憶されているプログラムを実行して、提案された方法のうちの１つまたは複数を実行する。

【0098】

以上で説明されたネットワーク抽象化ユニットヘッダのための技法は、コンピュータ読取可能な命令を使用するコンピュータソフトウェアとして実施され、１つまたは複数のコンピュータ読取可能な媒体に物理的に記憶されることができる。例えば、図８は、開示された主題のいくつかの実施形態を実施することに適したコンピュータシステム８００を示す。

【0099】

コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、またはそのようなメカニズムを施されて、コンピュータ中央処理装置（ＣＰＵ）、グラフィックスプロセッシングユニット（ＧＰＵ）などによって直接、または解釈、マイクロコード実行などによって実行されることができる命令を含むコードを作成する任意の適切な機械コードまたはコンピュータ言語を用いて符号化されることができる。

【0100】

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

【0101】

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

【0102】

コンピュータシステム８００は、いくつかのヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（音声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（図示せず）によって、１人以上のユーザによる入力に応答することができる。ヒューマンインターフェースデバイスは、オーディオ（音声、音楽、環境音など）、画像（走査画像、静止画像カメラから取得される写真画像など）、ビデオ（２次元ビデオ、立体ビデオを含む３次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係しない特定のメディアをキャプチャすることにも使用できる。

【0103】

入力ヒューマンインターフェースデバイスは、キーボード８０１、マウス８０２、トラックパッド８０３、タッチスクリーン８１０、データグローブ１２０４、ジョイスティック８０５、マイクフォン８０６、スキャナ８０７、カメラ８０８（それぞれ１つのみ示されている）のうちの１つまたは複数を含み得る。

【0104】

コンピュータシステム８００は、特定のヒューマンインターフェース出力デバイスをも含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音声、光、および嗅覚／味覚を介して１人以上のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン８１０、データグローブ１２０４、またはジョイスティック８０５による触覚フィードバックがあるが、入力デバイスとして機能しない触覚フィードバックデバイスであってもよい）、オーディオ出力デバイス（スピーカ８０９、ヘッドホン（図示せず）など）、視覚出力デバイス（陰極線管（ＣＲＴ）スクリーン、液晶ディスプレイ（ＬＣＤ）スクリーン、プラズマスクリーン、有機発光ダイオード（ＯＬＥＤ）スクリーンを含むスクリーン８１０（それぞれタッチスクリーン入力能力を有するかもしくは有せず、それぞれ触覚フィードバック能力を有するかもしくは有しない。それらの一部は、ステレオグラフィック出力などの手段を介して、２次元の視覚出力または３次元以上の出力を出力することができる）、仮想現実眼鏡（図示せず）、ホログラフィックディスプレおよびスモークタンク（図示せず）など）、およびプリンタ（図示せず）を含み得る。

【0105】

コンピュータシステム８００は、人間がアクセス可能な記憶装置およびそれらの関連する媒体、例えば、ＣＤ／ＤＶＤなどの媒体８２１付きのＣＤ／ＤＶＤ ＲＯＭ／ＲＷ８２０を含む光学媒体、サムドライブ８２２、リムーバブルハードドライブまたはソリッドステートドライブ８２３、テープやフロッピーディスクなどの従来の磁気媒体（図示せず）、セキュリティドングルなどの専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイス（図示せず）などをも含むことができる。

【0106】

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

【0107】

コンピュータシステム８００は、１つまたは複数の通信ネットワークへのインターフェースをさらに含むことができる。ネットワークは、例えば、無線、有線、光学的であり得る。ネットワークは、さらに、ローカル、広域、大都市圏、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネット、無線ＬＡＮなどのローカルエリアネットワーク、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）、第３世代（３Ｇ）、第４世代（４Ｇ）、第５世代（５Ｇ）、長期進化（ＬＴＥ）などを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、および地上放送ＴＶを含むＴＶ有線または無線広域デジタルネットワーク、ＣＡＮＢｕｓを含む車両用や産業用などを含む。特定のネットワークは、一般に、特定の汎用データポートまたは周辺バス８４９（例えば、コンピュータシステム８００のユニバーサル・シリアル・バス（ＵＳＢ）ポートなど）に接続された外部ネットワークインターフェースアダプターを必要とする。他のものは一般に、以下で説明するようにシステムバスに接続することにより、コンピュータシステム８００のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。一例として、ネットワーク８５５は、ネットワークインターフェース８５４を用いて周辺バス８４９に接続されてもよい。これらのネットワークのいずれかを用いて、コンピュータシステム８００は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ（例えば、放送ＴＶ）、単方向の送信のみ（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、または双方向、例えばローカルまたはワイドエリアデジタルネットワークを用いる他のコンピュータシステムへの送信であり得る。特定のプロトコルおよびプロトコルスタックを上述したこれらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。

【0108】

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム８００のコア８４０に接続されることができる。

【0109】

コア８４０は、１つまたは複数の中央処理装置（ＣＰＵ）８４１、グラフィックスプロセッシングユニット（ＧＰＵ）８４２、フィールドプログラマブルゲートエリア（ＦＰＧＡ）８４３の形態での専用プログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ８４４などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）８４５、ランダムアクセスメモリ８４６、非ユーザアクセス可能な内部ハードドライブ、ソリッドステートドライブ（ＳＳＤ）などの内部大容量記憶装置８４７とともに、システムバス１２４８を介して接続されてもよい。一部のコンピュータシステムでは、システムバス１２４８は、１つまたは複数の物理プラグの形態でアクセスでき、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にする。周辺機器は、コアのシステムバス１２４８に直接、または周辺バス８４９を介して接続されることができる。周辺バスのアーキテクチャは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）、ＵＳＢなどを含む。

【0110】

ＣＰＵ８４１、ＧＰＵ８４２、ＦＰＧＡ８４３、およびアクセラレータ８４４は、組み合わせて、前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ８４５またはＲＡＭ８４６に記憶されることができる。推移データはＲＡＭ８４６にも記憶できるが、永続データは、例えば、内部大容量ストレージ８４７に記憶されることができる。１つまたは複数のＣＰＵ８４１、ＧＰＵ８４２、大容量ストレージ８４７、ＲＯＭ８４５、ＲＡＭ８４６などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリデバイスへの高速保存および検索が可能になる。

【0111】

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

【0112】

限定ではなく、一例として、アーキテクチャを有するコンピュータシステム８００、特にコア８４０は、１つまたは複数の有形のコンピュータ読取可能な媒体に組み込まれたソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）の結果としての機能性を提供することができる。このようなコンピュータ読取可能な媒体は、以上で紹介したようにユーザがアクセス可能な大容量ストレージ、および、コア内部大容量ストレージ８４７またはＲＯＭ８４５などの非一時的な性質を持つコア８４０の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実施するソフトウェアは、このようなデバイスに記憶され、コア８４０によって実行されることができる。コンピュータ読取可能な媒体は、特定の必要に応じて、１つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア８４０、具体的にはその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ８４６に記憶されたデータ構造を定義すること、および、ソフトウェアで定義されたプロセスに従ってこのようなデータ構造を変更する言を含む、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または、代替として、コンピュータシステムは、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりにまたは一緒に動作することができる回路（例えば、アクセラレータ８４４）に有線接続されたまたは組み込まれたロジックの結果としての機能性を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを含むことができ、その逆も同様である。コンピュータ読取可能な媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（ＩＣ）など）、実行のためのロジックを具現化する回路、またはその両方を含むことができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを含む。

【0113】

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

【符号の説明】

【0114】

２１０～２４０ 端末
２５０ ネットワーク
３０１ ビデオソース
３０２ ビデオサンプルストリーム
３０３ エンコーダ
３０４ ビデオビットストリーム
３０５ ストリーミングサーバ
３０６，３０８ ストリーミングクライアント
３０７，３０９ コピー
３１０ ビデオデコーダ
３１１ 出方向ビデオサンプルストリームストリーム
３１２ ディスプレイ
３１３ キャプチャサブシステム
４１０ 受信機
４１２ チャネル
４１５ バッファメモリ
４２０ エントロピーデコーダ／パーサ
４２１ シンボル
４５１ スケーラ／逆変換ユニット
４５２ イントラピクチャ予測ユニット
４５３ 動き補償予測ユニット
４５５ アグリゲータ
４５６ ループフィルタユニット
４５７ 参照ピクチャメモリ、参照ピクチャバッファ
４５８ 現在のピクチャ
５３０ ソースコーダ
５３２ 符号化エンジン
５３３ デコーダ
５３４ 参照ピクチャメモリ
５３５ 予測器
５４０ 送信機
５４３ 符号化ビデオシーケンス
５４５ エントロピーコーダ
５５０ コントローラ
５６０ 通信チャネル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【手続補正書】

【提出日】2021-06-08

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも１つのプロセッサが実行する、ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する方法であって、
ＮＡＬユニットヘッダに含まれる、第１の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第１のシンタックス要素を復号するステップと、
前記第１のシンタックス要素に基づいて、複数のＮＡＬユニットタイプを含むＮＡＬユニットクラスを決定するステップと、
前記ＮＡＬユニットヘッダに含まれる、第２の固定長の２値符号化されたＮＡＬユニットシンタックス要素を含む第２のシンタックス要素を復号するステップと、
前記ＮＡＬユニットクラスが第１のＮＡＬユニットクラスであることに基づいて、前記ＮＡＬユニットクラスと前記第２のシンタックス要素との組み合わせを用いて、前記ＮＡＬユニットタイプの中からＮＡＬユニットタイプを決定し、決定された前記ＮＡＬユニットタイプに基づいて、前記ＮＡＬユニットを再構築するステップと、
を含む方法。

【請求項2】

前記ＮＡＬユニットクラスが前記第１のＮＡＬユニットクラスであることに基づいて、時間的識別子（ＴＩＤ）がゼロであると決定される、請求項１に記載の方法。

【請求項3】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが複数の時間的レイヤに関連することを示す、請求項１に記載の方法。

【請求項4】

前記パラメータセットは、デコーダパラメータセット、ビデオパラメータセット、およびシーケンスパラメータセットのうちの少なくとも１つを含む、請求項３に記載の方法。

【請求項5】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットに対応するパラメータセットが単一の符号化ピクチャに関連することを示す、請求項１に記載の方法。

【請求項6】

前記パラメータセットは、ピクチャパラメータセット、スライスパラメータセット、適応パラメータセット、およびヘッダパラメータセットのうちの少なくとも１つを含む、請求項５に記載の方法。

【請求項7】

前記第１のＮＡＬユニットクラスは、前記ＮＡＬユニットが非規範的データに関連することを示す、請求項１に記載の方法。

【請求項8】

前記非規範的データは、補助強化情報、フィラーデータ、およびピクチャデリミタデータを含む、請求項７に記載の方法。

【請求項9】

前記ＮＡＬユニットクラスが第２のＮＡＬユニットクラスであることに基づいて、
前記第２のシンタックス要素に基づいて時間的識別子（ＴＩＤ）を決定し、決定された前記ＴＩＤに基づいて前記ＮＡＬユニットを再構築するステップをさらに含む、請求項１に記載の方法。

【請求項10】

前記第１のシンタックス要素は、禁止されたゼロビットを含む、請求項１に記載の方法。

【請求項11】

ビデオ復号のためのネットワーク抽象化レイヤ（ＮＡＬ）ユニットを再構築する装置であって、
プログラムコードを記憶するように構成される少なくとも１つのメモリと、
前記プログラムコードを読み取り、前記プログラムコードによって指示されたとおりに請求項１～１０のいずれか１項に記載の方法を実行するように構成される少なくとも１つのプロセッサと、
を備える装置。

【請求項12】

１つまたは複数のプロセッサに、請求項１～１０のいずれか１項に記載の方法を実行させるコンピュータプログラム。

【手続補正2】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正の内容】

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】