特許 7177270 ネットワーク抽象化ユニットヘッダからのタイルの識別化

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-14

(45)【発行日】2022-11-22

(54)【発明の名称】ネットワーク抽象化ユニットヘッダからのタイルの識別化

(51)【国際特許分類】

   H04N 19/70 20140101AFI20221115BHJP

【ＦＩ】

H04N19/70

【請求項の数】 19

(21)【出願番号】P 2021529820

(86)(22)【出願日】2019-12-19

(65)【公表番号】

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

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

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

(87)【国際公開日】2020-06-25

【審査請求日】2021-05-26

(31)【優先権主張番号】62/783,152

(32)【優先日】2018-12-20

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

(31)【優先権主張番号】16/403,799

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

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】チョイ，ビョンドゥ

(72)【発明者】

【氏名】ウェンジャー，ステファン

(72)【発明者】

【氏名】リィウ，シャン

【審査官】岩井 健二

(56)【参考文献】

【文献】国際公開第２０１８／０１１０４２（ＷＯ，Ａ１）

【文献】国際公開第２０１４／１１１５４７（ＷＯ，Ａ１）

【文献】国際公開第２０１４／００１５７３（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１４／００９２９９４（ＵＳ，Ａ１）

【文献】Alexandre Gabriel, and Emmanuel Thomas，AHG12: On picture-level tile and sequence-level tile for VVC，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-M0536，13th Meeting: Marrakesh, MO，2019年01月，pp.1-8

【文献】Alexandre Gabriel, and Emmanuel Thomas，AHG17: On signaling of tile group set with MCTS properties (NAL unit header and new parameter set) ，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-M0537，13th Meeting: Marrakesh, MO，2019年01月，pp.1-6

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ １９／００ － １９／９８

(57)【特許請求の範囲】

【請求項1】

ビデオ復号化のための方法であって、
固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化するステップと、
前記ピクチャセグメントを再構成するステップと、
を含み、
前記シンタックス要素のサイズは、パラメータセット内の少なくとも１つのシンタックス要素を通して決定される、
方法。

【請求項2】

前記ピクチャセグメントは、タイル、タイル群、または、サブピクチャ、のうちの１つである、
請求項１に記載の方法。

【請求項3】

前記シンタックス要素は、前記ピクチャセグメントにおける、それぞれ、マクロブロックアドレス、第１マクロブロックまたは符号化ユニットの符号化ユニットアドレス、もしくは、第１符号化ユニットのタイルアドレス、のうちの１つである、
請求項２に記載の方法。

【請求項4】

前記シンタックス要素は、タイル識別子である、
請求項２に記載の方法。

【請求項5】

所与のタイルレイアウトについて、前記タイルレイアウトにおける各タイルは、固有のタイル識別子を有し、かつ、前記固有のタイル識別子は、前記タイルレイアウトにおける前記ピクチャセグメントのスキャン順序に従って、割り当てられている、
請求項４に記載の方法。

【請求項6】

前記スキャン順序は、前記タイルレイアウトの左上隅のタイルに関連付けられており、かつ、上から下へ、右から左への順序に従って、１つずつ増加される、
請求項５に記載の方法。

【請求項7】

前記シンタックス要素は、前記ハイレベルシンタックス構造において固定位置にある、
請求項１に記載の方法。

【請求項8】

前記パラメータセットは、前記ハイレベルシンタックス構造が属するピクチャについてアクティブである、
請求項１に記載の方法。

【請求項9】

前記方法は、さらに、
前記バイナリ符号化シンタックス要素の復号化に基づいて、前記バイナリ符号化シンタックス要素に関連付けられたタイル識別子が、復号化されるタイルのリストに含まれていることを決定する、ステップと、
前記タイル識別子が、復号化されるタイルの前記リストに含まれていることの決定に基づいて、前記ピクチャセグメントを再構成するステップと、
を含む、請求項１に記載の方法。

【請求項10】

ビデオシーケンスを復号化するための装置であって、
プログラムコードを保管する、ように構成された少なくとも１つのメモリと、
前記プログラムコードを読み出し、かつ、前記プログラムコードによって指示されるように動作する、ように構成された少なくとも１つのプロセッサと、を含み、
前記プログラムコードは、
前記少なくとも１つのプロセッサに、固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化させる、ように構成された復号化コードと、
前記少なくとも１つのプロセッサに、前記ピクチャセグメントを再構成させる、ように構成された再構成コードと、
を含み、
前記シンタックス要素のサイズは、パラメータセット内の少なくとも１つのシンタックス要素を通して決定される、
装置。

【請求項11】

前記ピクチャセグメントは、タイル、タイル群、または、サブピクチャ、のうちの１つである、
請求項１０に記載の装置。

【請求項12】

前記シンタックス要素は、前記ピクチャセグメントにおける、それぞれ、マクロブロックアドレス、第１マクロブロックまたは符号化ユニットの符号化ユニットアドレス、もしくは、第１符号化ユニットのタイルアドレス、のうちの１つである、
請求項１１に記載の装置。

【請求項13】

前記シンタックス要素は、タイル識別子である、
請求項１１に記載の装置。

【請求項14】

所与のタイルレイアウトについて、前記タイルレイアウトにおける各タイルは、固有のタイル識別子を有し、かつ、前記固有のタイル識別子は、前記タイルレイアウトにおける前記ピクチャセグメントのスキャン順序に従って、割り当てられている、
請求項１３に記載の装置。

【請求項15】

前記スキャン順序は、前記タイルレイアウトの左上隅のタイルに関連付けられており、かつ、上から下へ、右から左への順序に従って、１つずつ増加される、
請求項１４に記載の装置。

【請求項16】

前記シンタックス要素は、前記ハイレベルシンタックス構造において固定位置にある、
請求項１０に記載の装置。

【請求項17】

前記パラメータセットは、前記ハイレベルシンタックス構造が属するピクチャについてアクティブである、
請求項１０に記載の装置。

【請求項18】

１つ以上のコンピュータで実行可能な命令を含むコンピュータプログラムであって、装置の１つ以上のプロセッサによって実行されると、
前記１つ以上のプロセッサに、
固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化させ、
前記ピクチャセグメントを再構成させ、
前記シンタックス要素のサイズは、パラメータセット内の少なくとも１つのシンタックス要素を通して決定される、
コンピュータプログラム。

【請求項19】

ビデオ符号化のための方法であって、
ビデオシーケンスを符号化するステップと、
固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化するステップと、
前記ピクチャセグメントを再構成するステップと、
を含み、
前記シンタックス要素のサイズは、パラメータセット内の少なくとも１つのシンタックス要素を通して決定される、
方法。

【発明の詳細な説明】

【技術分野】

【0001】

開示される技術的事項は、ビデオ符号化および復号化に関する。そして、より特定的には、固定長コードポイント、ネットワーク抽象化層ユニットヘッダといったハイレベルシンタックス構造にタイルを識別する情報を含めることに関する。

【0002】

関連出願の相互参照
本出願は、米国特許商標庁において2018年12月20日に出願された米国仮特許出願第62/783,152号および2019年5月6日に米国特許商標庁において出願された米国仮特許出願第16/403,799号に対する米国特許法第119条の優先権を主張するものであり、これらの開示は、その全体が参照により本明細書に組み込まれている。

【背景技術】

【0003】

動き補償（motion compensation）を用いた画像間（inter-picture）予測を使用するビデオ符号化および復号化は、数十年にわたり知られている。非圧縮デジタルビデオは、一連の画像から構成することができ、各画像は、例えば、1920×1080の輝度（luminance）サンプルおよび関連する色度（chrominance）サンプルの空間次元（spatial dimension）を有している。一連の画像は、例えば、60ピクチャ／秒または60Hzの、固定または可変の画像レート（picture rate）（非公式にはフレームレート（frame rate）としても知られている）を有し得る。非圧縮ビデオは、著しいビットレート要件を有している。例えば、8ビット／サンプルの1080p60 4:2:0ビデオ(60Hzのフレームレートにおいて1920×1080の輝度サンプル解像度)は、1.5ギガビット／秒（Gbit/s）に近い帯域幅を必要とする。そうしたビデオの1時間は、600Gバイトを超える記憶領域を必要とする。

【0004】

ビデオ符号化および復号化の１つの目的は、圧縮を通じた、入力ビデオ信号における冗長性の低減であり得る。圧縮は、前述の帯域幅または記憶領域の要件を、場合によっては２桁以上、低減するのに役立つ。可逆（lossless）圧縮および不可逆（lossy）圧縮の両方、並びに、それらの組み合わせが利用され得る。可逆圧縮とは、オリジナル信号の正確なコピーを圧縮されたオリジナル信号から再構成することができる技術をいう。不可逆圧縮を使用する場合に、再構成された信号はオリジナル信号と同一ではないかもしれないが、オリジナル信号と再構成された信号との間の歪み（distortion）は、意図されたアプリケーションについて再構成された信号を有用にするために十分なほど小さい。ビデオの場合には、不可逆圧縮が広く利用されている。許容される歪みの量は、アプリケーションに依存しており、例えば、所定の消費者（consumer）ストリーミングアプリケーションのユーザは、テレビジョン寄与アプリケーションのユーザよりも大きい歪みを許容し得る。達成可能な圧縮率は、より大きい許容可能な（allowable／tolerable）歪みが、より高い圧縮率をもたらし得るということを、反映することができる。

【0005】

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

【0006】

パケットネットワークを介した転送のために、符号化ビデオビットストリームをパケットへと分割するコンセプトが、数十年にわたり使用されている。初期には、ビデオ符号化（video coding）の標準および技術は、その大部分がビット指向（bit-oriented）のトランスポートについて最適化されており、そして、ビットストリームが定義されていた。パケット化（packetization）は、例えば、リアルタイムトランスポートプロトコル(Real-Time Transport Protocol、RTP)ペイロードフォーマットで指定されたシステムレイヤインターフェイスにおいて発生した。インターネット上でのビデオの大量使用に適したインターネット接続性の出現により、ビデオ符号化標準は、ビデオ符号化層(video coding layer、VCL)とネットワーク抽象化層(network abstraction layer、NAL)の概念的な差別化を通して、その顕著なユースケースを反映した。NALユニットは2003年にH.264で導入され、そして、わずかな修正だけを伴い、それ以来、所定のビデオ符号化標準および技術において維持されてきた。

【0007】

NALユニットは、多くの場合、符号化ビデオシーケンスの全ての先行（preceding）NALユニットを必ずしも復号することなく、デコーダが動作することができる最小のエンティティとして見なされ得る。NALユニットは、所定のエラー回復技術、並びに、所定のビットストリーム操作技術が、選択転送ユニット(Selective Forwarding Units、SFU)または多点制御ユニット(Multipoint Control Units、MCU)といったメディア・アウェア・ネットワーク要素(Media Aware Network elements、MANE)による、ビットストリーム・プルーニング（pruning）を含むことを可能にする。

【0008】

図1は、H.264(101)およびH.265(102)に従ったNALユニットヘッダのシンタックスダイヤグラム（syntax diagram）の関連部分を示しており、どちらの場合も、それぞれの拡張を伴わない。どちらの場合においても、“forbidden_zero_bit”は、所定のシステムレイヤ環境において開始コードエミュレーション防止のために使用されるゼロビットである。“nal_unit_type”のシンタックス要素は、NALユニットが運搬するデータのタイプを指し、例えば、所定のスライスタイプ、パラメータセットタイプ、補足拡張情報(Supplementary Enhancement Information、SEI)メッセージ、等のうち１つであり得る。H.265 NALユニットヘッダは、さらに、“nuh_layer_id”および“nuh_temporal_id_plus1”を含み、これは、空間的／SNRおよびNALユニットが属する符号化画像の時間的レイヤを示している。

【0009】

NALユニットヘッダは、例えば、他のNALユニットヘッダ、パラメータセット、等といった、ビットストリーム中の他のデータに対して如何なる解析依存性（parsing dependency）も持たない、容易に解析可能な（parseable）な固定長コードワードだけを含むことが分かる。NALユニットヘッダがNALユニットにおける最初のオクテット（octet）であるので、MANEは、容易にそれらを抽出し、解析し、そして、それらに基づいて行動することができる。他のハイレベルシンタックス要素、例えば、スライスまたはタイルヘッダは、対照的に、それらがパラメータセットコンテキストを維持すること、及び／又は、可変長または算術的に符号化コードポイントの処理を必要とし得るので、MANEにアクセスしにくい。
しかしながら、タイル群ヘッダ（tile group header）といった構造でさえ、MANEに容易にアクセスできるようにさせる特性を有するように設計することができる。ただし、既存のビデオ圧縮技術および標準は、そのようにしていないことがある。

【0010】

NALユニットヘッダは、さらに、図1に示されるように、符号化画像の空間領域（spatial area）を表すビットストリームのスライス、タイル、または同様の部分といった、符号化画像のセグメントにNALユニットを関連付けることができる情報を含まないことが観察され得る。関連技術において、そうした情報は、スライスヘッダ内に、所定の場合には、マクロブロックまたはCUアドレスの形態で存在する。このアドレスは、場合によっては、画像の左上からカウントダウンするときに、スキャン順序でn番目のマクロブロック（macroblock）／CUで始まるセグメント、スライス、タイルを示す整数nである。従って、nは、画像およびマクロブロック／CUサイズの両方に依存し得るものであり、そして、小さい画像サイズについては小さく（例えば、バイナリコードで8ビットに適合する）、または、大きく（例えば、32400、バイナリコードで16ビットを必要とする)あり得る。両方の場合に、マクロブロック／CUサイズが16×16のサンプルであると仮定されている。

【0011】

歴史的に、タイルまたはスライスといったピクチャセグメントは、大部分が、最大転送ユニットサイズ制約に一致するビットストリームの分割、および並列化を容易にするために使用されていた。両方の場合に、MANE、SFU、または同様な装置におけるタイルまたはスライスの識別は通常必要とされていなかった。デコーダは、パラメータセットの復号化から獲得される状態（state）と共に、比較的複雑な、スライスヘッダ及び／又は類似の情報から関連情報を獲得することができる。

【0012】

しかしながら、より最近では、ピクチャセグメント、および、特にはタイル(および、スキャン順序、矩形の順序（rectangular order）、または他の適当な順序におけるタイルのコレクションである、タイル群（tile groups）)が、数あるアプリケーションの中でも、構成された360投影（projection）において所定のビューを表すCUのコレクションといった目的のために使用されている。これらのアプリケーションのいくつかにおいて、MANEおよびSFUは、アプリケーションについて必要とされない場合に、符号化されたピクチャから所定のタイルまたは他のセグメントを有利に取り除くことができる。例えば、立方体投影（cube projection）が使用されている場合、外部の視点からシーンをレンダリングすることは、６つの立方体表面のうち最大で３つを必要とする。エンドポイントに、残りの最小で３つの面を表すCUおよびセグメントを送信することは、リソースの無駄であり得る。しかしながら、送信者がMANEへ完全な表現(立方体投影の全ての６つの表面を含んでいる)を送信し、かつ、必要とされるサブセットだけをMANEが複数の受信者へ転送する場合であり、そして、その必要とされるサブセットが受信者間で異なる場合であるシナリオにおいて、MANEは、各受信者について潜在的に異なる立方体表面を含む、潜在的に異なるビットストリームを調整するだろう。そうするために、現在、MANEは、複素数可変長（complex variable length）符号化スライスヘッダを処理すると共に、スライスヘッダを復号化するために必要とされるように、パラメータセット、等の形態で状態を保持することを要求する。

【発明の概要】

【0013】

シンタックス構造に基づいてタイルの改善された識別を可能にするために、ビデオコーデック（video codec）で固定長コードワード（codeword）を含むシンタックス構造においてタイル識別子を含める技術が開示されている。

【0014】

ビデオ復号化のための方法は、固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化するステップと、ピクチャセグメントを再構成するステップと、を含む。

【0015】

ビデオシーケンスを復号化するための装置は、プログラムコードを保管するように構成された少なくとも１つのメモリと、プログラムコードを読み出し、かつ、プログラムコードによって指示されるように動作するように構成された少なくとも１つのプロセッサと、を含む。プログラムコードは、少なくとも１つのプロセッサに、固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化させるように構成されたコードを復号化するステップと、少なくとも１つのプロセッサに、ピクチャセグメントを再構成させるように構成されたコードを再構成するステップと、を含む。

【0016】

１つ以上の命令を保管している非一時的なコンピュータで読取り可能な媒体は、装置の１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、固定長コードワードを含むハイレベルシンタックス構造におけるピクチャセグメントの識別子を搬送するバイナリ符号化シンタックス要素を復号化させ、かつ、ピクチャセグメントを再構成させる。

【図面の簡単な説明】

【0017】

開示される技術的事項（subject matter）のさらなる特徴、性質、および様々な利点が、以下の詳細な説明および添付の図面からより明らかになるだろう。

【図1】図1は、H.264およびH.265に従ったNALユニットヘッダの概略図である。

【図2】図2は、一つの実施形態に従った、通信システムの簡略化されたブロックダイヤグラムの概略図である。

【図3】図3は、一つの実施形態に従った、通信システムの簡略化されたブロックダイヤグラムの概略図である。

【図4】図4は、一つの実施形態に従った、デコーダの簡略化されたブロックダイヤグラムの概略図である。

【図5】図5は、一つの実施形態に従った、エンコーダの簡略化されたブロックダイヤグラムの概略図である。

【図6】図6は、一つの実施形態に従った、CUアドレスまたはタイルIDシンタックス要素を含むNALユニットヘッダの概略図である。

【図7】図7は、一つの実施形態に従った、タイルレイアウトの概略図である。

【図8】図8は、一つの実施形態に従った、NALユニット復号化／転送の概略図である。

【図9】図9は、一つの実施形態に従った、コンピュータシステムの概略図である。

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

【0018】

解決すべき問題
ビデオ符号化シンタックスは、NALユニットヘッダといったハイレベルシンタックス構造におけるタイルまたは他の画像を識別する、容易に識別可能／解析可能なシンタックス要素を欠いている。

【0019】

図2は、一つの実施形態に従った、通信システム(200)の簡略化されたブロックダイヤグラムを示している。システム(200)は、ネットワーク(250)を介して相互接続された少なくとも２つの端末(210－220)を含み得る。データの一方向（unidirectional）伝送について、第１端末(210)は、ネットワーク(250)を介した他方の端末(220)に対する送信のために、ローカル位置でビデオデータを符号化し得る。第２端末(220)は、ネットワーク(250)から他方の端末の符号化ビデオデータを受信し、符号化データを復号し、そして、回復されたビデオデータを表示することができる。一方向データ伝送は、媒体提供アプリケーション、等において一般的であり得る。

【0020】

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

【0021】

図2においては、端末(210－240)が、サーバ、パーソナルコンピュータ、およびスマートフォンとして示され得るが、本開示の原理は、そのように限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は、専用のビデオ会議装置を用いたアプリケーションを見出す。ネットワーク(250)は、例えば、有線、及び／又は、無線通信ネットワークを含む、端末(210－240)間で符号化ビデオデータを伝達する任意の数のネットワークを表している。通信ネットワーク(250)は、回線交換（circuit-switched）及び／又はパケット交換（packet-switched）チャネルにおいてデータを交換することができる。代表的なネットワークは、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又は、インターネットを含んでいる。本説明の目的のために、ネットワーク(250)のアーキテクチャおよびトポロジーは、以下に説明されなければ、本開示のオペレーションにとって重要ではない。

【0022】

図3は、開示される技術的事項のためのアプリケーションの一つの例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示している。開示される技術的事項は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタルメディアにおける圧縮ビデオのストレージ、等を含む、他のビデオ可能化アプリケーションに対して同様に適用可能である。

【0023】

ストリーミングシステムは、キャプチャサブシステム(313)を含んでよく、例えば非圧縮ビデオサンプルストリーム(302)を生成する、ビデオソース(301)、例えばデジタルカメラ、を含み得る。このサンプルストリーム(302)は、符号化ビデオビットストリームと比較したときに、大きなデータボリュームを強調するように太い線として示されており、カメラ(301)に結合されたエンコーダ(303)によって処理され得る。エンコーダ(303)は、以下により詳細に説明されるように、開示される技術的事項の態様を可能にし、または、実装するために、ハードウェア、ソフトウェア、または、それらの組み合わせを含むことができる。符号化ビデオビットストリーム(304)は、サンプルストリームと比較したときに、より小さいデータボリュームを強調するように細い線として示されており、将来の使用のためにストリーミングサーバ(305)において保管され得る。１つ以上のストリーミングクライアント(306、308)は、符号化ビデオビットストリーム(304)のコピー(307、309)を取り出す（retrieve）ために、ストリーミングサーバ(305)にアクセスすることができる。クライアント(306)は、符号化ビデオビットストリーム(307)の入力コピーをデコードし、そして、ディスプレイ(312)または他のレンダリング装置(図示なし)上でレンダリング可能な出力ビデオサンプルストリーム(311)を生成する、ビデオデコーダ(310)を含み得る。いくつかのストリーミングシステムにおいて、ビデオビットストリーム(304、307、309)は、所定のビデオ符号化／圧縮標準に従って、符号化され得る。これらの標準の例は、ITU-T Recommendation H.265を含んでいる。開発中のビデオ符号化標準は、汎用ビデオ符号化(Versatile Video Coding)、またはVVCとして非公式に知られている。開示される技術的事項は、VVCのコンテキストにおいて使用され得る。

【0024】

図4は、本発明の一つの実施形態に従った、ビデオデコーダ(310)の機能ブロックダイヤグラムであり得る。

【0025】

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

【0026】

ビデオデコーダ(310)は、エントロピー符号化ビデオシーケンスからシンボル(421)を再構成するためのパーサ(420)を含み得る。これらのシンボルのカテゴリは、デコーダ(310)のオペレーションを管理するために使用される情報、および、図3に示されるように、デコーダの不可欠な部分ではないが、デコーダに接続され得るディスプレイ(312)といったレンダリング装置を制御する潜在的な情報を含む。レンダリング装置に対する制御情報は、補足拡張情報(SEI messages)またはビデオユーザビリティ情報(Video Usability Information、VUI)パラメータセットフラグメント(図示なし)の形式であり得る。パーサ(420)は、受信した符号化ビデオシーケンスを解析／エントロピー復号（entropy-decode）し得る。符号化ビデオシーケンスの符号化は、ビデオ符号化技術または標準に従うことができ、そして、可変長符号化、ハフマン（Huffman）符号化、コンテキスト感度を伴う又は伴わない算術符号化、等を含む、当業者にとってよく知られた原理に従うことができる。パーサ(420)は、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうち少なくとも１つに対するサブグループパラメータのセットを、符号化ビデオシーケンスから抽出し得る。サブグループは、画像グループ(Groups of Pictures、GOP)、画像、タイル、スライス、マクロブロック、符号化ユニット(Coding Unit、CU)、ブロック、変換ユニット(Transform Unit、TU)、予測ユニット(Prediction Unit、PU)、等を含み得る。エントロピーデコーダ／パーサは、また、変換係数、量子化パラメータ値、動きベクトル（motion vector）、等といった符号化ビデオシーケンス情報から抽出することができる。

【0027】

パーサ(420)は、シンボル(421)を生成するために、バッファ(415)から受信したビデオシーケンスについてエントロピー復号／解析オペレーションを実行することができる。

【0028】

シンボル(421)の再構成は、符号化ビデオ画像またはその部分のタイプ(画像間および画像内、ブロック間およびブロック内、といったもの)および他の要因に応じて、複数の異なるユニットを含むことができる。どのユニットが、どのように関与するかは、パーサ(420)によって符号化ビデオシーケンスからシンタックス解析されたサブグループ制御情報によって制御され得る。パーサ(420)と以下の複数ユニットとの間におけるそうしたサブグループ制御情報のフローは、明確化のために図示されていない。

【0029】

上述の機能ブロックの他に、デコーダ310は、概念的には、以下に説明されるように、いくつかの機能ユニットへと細分（subdivided）され得る。商業的制約の下で動作する実用的な実装では、これらのユニットの多くは、相互に密接に相互作用し、かつ、少なくとも部分的に相互に統合され得る。しかしながら、開示される技術的事項を説明する目的のために、以下の機能ユニットへと概念的に細分化することが適切である。

【0030】

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

【0031】

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

【0032】

他の場合に、スケーラ／逆変換ユニット(451)の出力サンプルは、インター（inter）符号化され、かつ、潜在的に動き補償（motion compensated）されたブロックに属することができる。そうした場合、動き補償予測ユニット(453)は、予測のために使用されるサンプルをフェッチするために参照画像（reference picture）メモリ(457)にアクセスすることができる。ブロックに属しているシンボル(421)に従ってフェッチされたサンプルを動き補償した後で、これらのサンプルは、アグリゲータ(455)によって、スケーラ／逆変換ユニットの出力に加えられて(この場合には、残留サンプルまたは残留信号と呼ばれる)、出力サンプル情報を生成することができる。動き補償ユニットが予測サンプルをフェッチする参照画像メモリ形態の中のアドレスは、例えば、X、Y、および参照画像コンポーネントを有し得るシンボル(421)の形態で、動き補償ユニットに利用可能な、動きベクトルによって制御され得る。動き補償は、また、サブサンプルの正確な動きベクトルが使用されているときに参照画像メモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズム、等も含み得る。

【0033】

アグリゲータ(455)の出力サンプルは、ループフィルタユニット(456)内の種々のループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、ループ内（in-loop）フィルタ技術を含み得る。ループ内フィルタ技術は、符号化ビデオビットストリーム内に含まれるパラメータによって制御され、かつ、パーサ(420)からのシンボル(421)としてループフィルタユニット(456)に利用可能にされるが、また、符号化画像または符号化ビデオシーケンスの(復号化順で)以前の部分の復号化の最中に獲得されたメタ情報にも応答することができ、並びに、以前に再構成され、かつ、ループフィルタされたサンプル値にも応答することができる。

【0034】

ループフィルタユニット(456)の出力は、レンダリング装置(312)に出力され、並びに、将来の画像間予測に使用するために参照画像メモリ(456)内に保管され得るサンプルストリームであり得る。

【0035】

所定の符号化画像は、一旦、完全に再構成されると、将来予測のための参照画像として使用され得る。一旦、符号化画像が完全に再構成され、かつ、(例えば、パーサ(420)によって)符号化画像が参照画像として識別されると、現在の参照画像(456)は、参照画像バッファ(457)の一部となり、そして、新たな（fresh）現在の画像メモリが、次の符号化画像の再構成を開始する前に再割当てされ得る。

【0036】

ビデオデコーダ420は、ITU-T Rec. H.265といった、標準において文書化され得る既定のビデオ圧縮技術に従って、復号化オペレーションを実行することができる。符号化ビデオシーケンスは、ビデオ圧縮技術文書または標準において、そして、特には、その中のプロファイル文書において規定されるように、ビデオ圧縮技術または標準のシンタックスに従うという意味で、使用されているビデオ圧縮技術または標準によって規定されるシンタックスに準拠し得る。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑性が、ビデオ圧縮技術または標準のレベルによって定義される範囲内にあることである。場合によって、レベルは、最大画像サイズ、最大フレームレート、最大再構成サンプルレート(例えば、メガサンプル毎秒で測定される)、最大参照画像サイズ、等を制限する。レベルによって設定された制限は、場合によっては仮想基準デコーダ（Hypothetical Reference Decoder、HRD）仕様、および、符号化ビデオシーケンスで信号化されたHRDバッファのメタデータを通して、さらに制限され得る。

【0037】

一つの実施形態において、受信器(410)は、符号化ビデオと共に追加の(冗長な)データを受信し得る。追加データは、符号化ビデオシーケンスの一部として含まれ得る。追加データは、データを適切に復号化するため、かつ／あるいは、オリジナルのビデオデータをより正確に再構成するために、ビデオデコーダ(420)によって使用され得る。追加データは、例えば、時間的、空間的、またはSNR強化層、冗長スライス、冗長画像、前方誤り訂正（forward error correction）コード、等の形態であり得る。

【0038】

図5は、本開示の一つの実施形態に従った、ビデオエンコーダ(303)の機能ブロック図であり得る。

【0039】

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

【0040】

ビデオソース(301)は、デジタルビデオサンプルストリームの形態で、エンコーダ(303)によって符号化されるソースビデオシーケンスを提供することができ、形態は、任意の適切なビット深さ(例えば、8ビット、10ビット、12ビット、...)、任意の色空間(例えば、BT.601 Y CrCB、RGB、等)、および任意の適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)であり得る。メディア配信（media serving）システムにおいて、ビデオソース(301)は、以前に準備されたビデオを保管しているストレージ装置であり得る。ビデオ会議システムにおいて、ビデオソース(303)は、ビデオシーケンスとしてローカル画像情報をキャプチャするカメラであり得る。ビデオデータは、シーケンスで見たときに、動きを伝える複数の個々の画像として提供されてよい。画像自体は、ピクセルの空間的アレイとして構成されてよく、ここで、各ピクセルは、使用中のサンプリング構造、色空間、等に応じて、１つ以上のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。

【0041】

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

【0042】

いくつかのビデオエンコーダは、「符号化ループ（“coding loop”）」として当業者が容易に認識できるものにおいて動作する。過度に単純化された説明として、符号化ループは、エンコーダ(530)の符号化部分(以下、「ソースコーダ（“source coder”）」)(符号化されるべき入力ピクチャ、および参照画像に基づいてシンボルを生成する責任を負う)、および、サンプルデータを生成するためにシンボルを再構成するエンコーダ(303)内に埋め込まれた(ローカル)デコーダ(533)で構成され、(リモート)デコーダも、また、(開示される技術的事項において考慮されたビデオ圧縮技術において、シンボルと符号化ビデオビットストリームとの間の任意の圧縮が可逆（lossless）なように)生成するだろう。再構成されたサンプルストリームは、参照画像メモリ(534)に対する入力である。シンボルストリームの復号化は、デコーダ位置(ローカルまたはリモート)に依存しないビットパーフェクト（bit-exact）な結果をもたらすので、参照画像バッファのコンテンツも、また、ローカルエンコーダとリモートエンコーダの間でビットパーフェクトである。別の言葉で言えば、エンコーダの予測部分は、デコーダが、復号化の最中に予測を使用するときに「見る（”see”）」のと全く同一のサンプル値を参照画像サンプルとして「見る」。参照画像同期性に係るこの基本原理(および、例えば、チャンネルエラーのために、同期性を維持することができない場合に結果として生じるドリフト)は、当業者にとって周知である。

【0043】

「ローカル（“local”）」デコーダ(533)のオペレーションは、「リモート（“remote”）」デコーダ(310)と同じであり得る。これは、図4と関連して既に上記に詳述されている。しかしながら、図4を、また、簡単に参照すると、シンボルが利用可能であり、かつ、エントロピー符号化器(545)およびパーサ(420)による符号化ビデオシーケンスに対するシンボルの符号化／復号化が可逆であり得るので、チャネル(412)、受信器(410)、バッファ(415)、およびパーサ(420)を含む、デコーダ(310)のエントロピー復号化部分は、ローカルデコーダ(533)内に完全には実装されないことがある。

【0044】

この時点で行うことができる観察は、デコーダ内に存在する解析／エントロピー復号化を除く任意のデコーダ技術も、また、対応するエンコーダ内に、実質的に同一な機能的形態で存在する必要があることである。この理由のために、開示される技術的事項はデコーダのオペレーションに焦点を当てる。エンコーダ技術の説明は、包括的に記述されたデコーダ技術の逆であるため、省略することができる。所定の分野においてだけ、より詳細な説明が必要であり、そして、以下に提供されている。

【0045】

そのオペレーションの一部として、ソースコーダ(530)は、動き補償予測符号化（motion compensated predictive coding）を実行することができ、それは、「参照フレーム（“reference frame”）」として指定されたビデオシーケンスからの１つ以上の以前に符号化されたフレーム（previously coded-frames）に関して入力フレームを予測的に符号化するものである。このようにして、符号化エンジン(532)は、入力フレームのピクセルブロックと、入力フレームに対する予測リファレンス（prediction reference）として選択され得る参照フレームのピクセルブロックとの間の差異を符号化する。

【0046】

ローカルビデオデコーダ(533)は、ソースコーダ(530)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータを復号化することができる。符号化エンジン(532)のオペレーションは、有利なことに、不可逆プロセスであり得る。符号化ビデオデータがビデオデコーダ(図5に図示なし)で復号化され得る場合、再構成されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ(533)は、ビデオデコーダによって参照フレーム上で実行され、かつ、再構成された参照フレームを参照画像キャッシュ(534)に保管させ得る、復号化プロセスを複製する。このようにして、エンコーダ(303)は、遠端（far-end）ビデオデコーダによって獲得される再構成された参照フレームとして共通のコンテンツを有する再構成された参照フレームのコピーを、ローカルに保管することができる（伝送エラーなく）。

【0047】

予測器(535)は、符号化エンジン(532)のために予測サーチを実行することができる。すなわち、符号化されるべき新しいフレームについて、予測器(535)は、新しいピクチャに対する適切な予測リファレンスとして役立ち得る、(候補参照ピクセルブロックとしての)サンプルデータ、または、参照画像動画ベクトル、ブロック形状、等といった、所定のメタデータについて、参照画像メモリ(534)を検索することができる。予測器(535)は、適切な予測リファレンスを見出すために、サンプルブロック－ピクセルブロック毎に動作し得る。場合によっては、予測器(535)によって獲得される検索結果によって決定されるように、入力ピクチャは、参照画像メモリ(534)に保管された複数の参照画像から引き出された予測リファレンスを有することができる。

【0048】

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

【0049】

全ての前述した機能ユニットの出力は、エントロピー符号化器(545)においてエントロピー符号化を受け得る。エントロピー符号化器は、例えば、ハフマン符号化、可変長符号化、算術符号化、等として、当業者に知られた技術に従って、シンボルを可逆に圧縮することによって、種々の機能ユニットにより生成されたシンボルを符号化ビデオシーケンスへと変換する。

【0050】

送信器(540)は、エントロピー符号化器(545)によって生成されると、符号化ビデオシーケンスをバッファし、通信チャネル(560)を介した送信のために準備することができる。通信チャネルは、符号化ビデオデータを保管するストレージ装置に対するハードウェア／ソフトウェアリンクであってよい。送信器(540)は、ビデオコーダ(530)からの符号化ビデオデータを、送信される他のデータ、例えば、符号化オーディオデータ及び／又は補助的なデータストリーム(ソースは示されない)とマージすることができる。

【0051】

コントローラ(550)は、エンコーダ(303)のオペレーションを管理することができる。符号化の最中に、コントローラ(550)は、各符号化画像に対して、所定の符号化画像タイプを割り当てることができ、これは、それぞれの画像に適用され得る符号化技術に影響を及ぼし得る。例えば、ピクチャは、しばしば、次のフレームタイプの１つとして割り当てられ得る。

【0052】

イントラピクチャ(Ｉピクチャ)は、予測のソースとしてシーケンス内のあらゆる他のフレームを使用しないで、符号化され、かつ、復号化され得るものであり得る。いくつかのビデオコーデック（codec）は、例えば、独立デコーダ・リフレッシュ・ピクチャ（Independent Decoder Refresh Pictures）を含む、異なるタイプのイントラピクチャを許容する。当業者であれば、Ｉピクチャのこれらの変形例、並びに、それらのそれぞれのアプリケーションおよび機能を知っている。

【0053】

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

【0054】

双方向予測ピクチャ（Bi-directionally Predictive Picture）(Ｂピクチャ)は、各ブロックのサンプル値を予測するために、最大で２つの動きベクトルおよび参照インデックスを使用して、イントラ予測またはインター予測を用いて符号化および復号化され得るものであり得る。同様に、複数の予測画像は、単一のブロックの再構成のために、２つ以上の参照画像および関連するメタデータを使用することができる。

【0055】

ソース画像は、一般に、複数のサンプルブロック(例えば、4×4、8×8、4×8、または16×16のサンプルそれぞれのブロック)へと空間的に細分され、そして、ブロック毎に符号化される。ブロックは、ブロックそれぞれの画像に適用される符号化割り当てによって決定されるように、(既に符号化された)他のブロックを参照して予測的に符号化され得る。例えば、Ｉピクチャのブロックは、非予測的に符号化されてよく、または、それらは、同じ画像の既に符号化されたブロックを参照して予測的に符号化され得る(空間予測またはイントラ予測)。Ｐピクチャのピクセルブロックは、１つの以前に符号化された参照画像を参照して、非予測的に、空間的予測を介して、または、時間的予測を介して、符号化され得る。Ｂピクチャのブロックは、１つ又は２つの以前に符号化された参照画像を参照して、非予測的に、空間的予測を介して、または、時間的予測を介して符号化され得る。

【0056】

ビデオコーダ(303)は、ITU-T Rec. H.265といった、既定のビデオ符号化技術または標準に従って、符号化オペレーションを実行することができる。そのオペレーションにおいて、ビデオコーダ(303)は、入力ビデオシーケンスにおける時間的および空間的冗長性を利用する予測符号化オペレーションを含む、種々の圧縮オペレーションを実行することができる。符号化ビデオデータは、従って、使用されているビデオ符号化技術または標準によって指定されたシンタックスに適合し得る。

【0057】

一つの実施形態において、送信器(540)は、符号化ビデオと共に追加データを送信することができる。ビデオコーダ(530)は、符号化ビデオシーケンスの一部として、そうしたデータを含み得る。追加データは、時間的／空間的／SNR強化層、冗長画ピクチャおよびスライスといった他の形式の冗長データ、補足拡張情報（SEI）メッセージ、ビデオユーザビリティ情報（VUI）パラメータセットフラグメント、等を含み得る。

【0058】

一つの実施形態に従って、タイル、タイル群、スライス、ブロック群（Group Of Blocks、GOB）、等(以下、タイル)といったピクチャセグメントを識別する情報は、NALユニットヘッダ(NUH)といった容易にアクセス可能なハイレベルシンタックス構造、または、固定長コードワードを含み、かつ、MANEによる容易な処理のために設計された類似の構造において配置される(以下、NUH)。

【0059】

タイルを識別する情報は、異なる形式をとることができる。この情報を設計することにおいては、いくつかの設計上の考慮事項を念頭に置くべきである。これらの設計上の考慮事項のいくつかが、以下に列挙される。

【0060】

所与のピクチャ内の可能なタイルの数は、例えば、従来のビデオコーディング技術または標準における可能なスライスの数と比較すると、小さくすることができる。例えば、H.264において、(所定のピクチャサイズについて)単一のマクロブロックをカバーするスライスを持つことが可能であり、マクロブロックが存在するのと同じ数のスライスが可能である。対照的に、タイル化（tiled）キューブマップを表現する場合には、画像の解像度とは関係なく、６つのタイルで十分であり得る。多くの実際の事例においては、64、128、または256のタイルの最大数が安全に仮定され得る。

【0061】

タイルレイアウトは固定することができ、そして、ビデオコーディング技術自身がピクチャ間でタイルレイアウトの柔軟性を可能にし得る一方で、システム標準または技術は、その柔軟性を、セッション全体を通してタイルレイアウトが同じままであるポイントに制限することができる。これにより、タイルレイアウトを、セッションセットアップの最中といった、非ビデオ・ビットストリーム特有の手段を介してMANEに利用可能にすることができる。ビデオ符号化およびMANE演算におけるパラメータセット間の望ましくないコンテキスト依存性が、これによって、妨げられ得る。

【0062】

少なくとも上記の仮定の下で、NALユニットがMANEによって取り除かれるのを可能にするように、NALユニットによって搬送されるタイルを識別するためのメカニズムは、H.264およびH.265といった、関連技術と比較すると、著しく単純化され得る。例えば、H.264とH.265において、MANEは、スライスヘッダ内のスライス／タイル・アドレス・コードワードの長さについて知るために、正しいシーケンスパラメータセットを識別する必要があるだろう。そうした長さ情報は、シーケンスパラメータセット内の可変長コードワードとして符号化される。従って、MANEは、最低限、現在のアクティブなシーケンスパラメータセットを識別するために、パラメータセットの動作化シーケンスに従う必要があり、そして、(パラメータセットは解析依存ではない（parsing-independent）ので、おそらく、この順序ではなく)スライスヘッダ内で搬送されるバイナリ符号化スライス／タイルアドレスの長さを識別するために、可変長コードワードを復号化する必要があるだろう。次いで、MANEは、開始マクロブロック／CUアドレスを獲得するために、スライスヘッダ内の可変長コードワードを復号化する必要があるだろう。この情報は、タイルを識別するために、パラメータセットから復号化されるタイルレイアウトに対して照合され得る。

【0063】

同一または別の実施形態において、タイルの識別情報は、タイルの第１マクロブロック／CUのアドレスであり得る。事実上、そうしたメカニズムは、開始アドレスをスライスヘッダからNUHへ移動させる。そうすることは、コーデック設計に対する最小限の変更アプローチであり得るが、NUHを著しく増加させる欠点を有している。しかしながら、NUHのサイズの増加は、符号化効率の観点からでさえ許容可能であり得る。なぜなら、同じ量のビットが、スライス／タイルヘッダから取り除かれたであろうからである。

【0064】

上記で指摘したように、マクロブロック／CUアドレスは、小さな画像サイズおよび大きなマクロブロック／CUサイズについて、適度に小さく、もしくは、小さなCUサイズおよび大きな画像サイズについて、かなり大きいことがある。この理由から、H.265のSPSは、スライスヘッダにおいて搬送されるマクロブロック／CUアドレスの長さの指示を含んでいる。同一または別の実施形態において、このメカニズムは、NALユニットヘッダについて保持され得る。しかしながら、そうすることは２つの欠点を有し得る。第一に、パラメータセット値を通してNALユニットヘッダにおけるシンタックス要素のサイズを決定することによって確立されるコンテキスト依存性は、パラメータ設定の動作化を追跡するようにMANEに要求し得る、それは冗長であり得る。第二に、NALユニットヘッダは、少なくとも今まで、MANEにおける処理を簡単にするためにオクテット整列（octet aligned）されている。そのオクテット整列を維持することは、パディング－ビットを浪費すること－を必要とし得る。そうした場合に、パラメータセットによって示されるマクロブロック／CUアドレスのサイズは、残りのNALユニットヘッダ・シンタックス要素と共に、8で割れるビットの数まで加算されない。

【0065】

同一または別の実施形態において、マクロブロック／CUアドレス－またはNALユニットヘッダ内の任意の他のシンタックス要素のサイズ－は、NALユニットヘッダ内の他のフィールドによって決定され得る。このメカニズムは、パラメータセットとNALユニットヘッダとの間のコンテンツ依存性を避け、そして、多くの場合に、望ましいものであり得る。欠点は、NALユニットヘッダの他のフィールドにおける、ビットまたはコードポイントの使用であり得る。詳細が以下で提供される。

【0066】

しかしながら、従来の意味においてスライスを考慮しない場合に、タイルまたはタイル群だけ、もしくは、ビットストリームエンティティに対するCUの類似の割り当てメカニズム、より高度なオプションが、利用可能である。これらのオプションを説明するために、スライスおよびタイルという用語が簡潔に再検討される。スライスは、通常はスキャン順序における、CUまたはマクロブロックのコレクションであり、そして、２つの要因によって識別される。すなわち、通常はスライスヘッダ内に符号化された開始マクロブロック／CUアドレス、および、しばしば新しいスライスの開始によって識別される(同様に、次のスライスヘッダの存在によって示される)、スライスの終端（end）である。所定のビデオ圧縮技術および標準は、スライスの数およびレイアウトについて所定の比較的小さな制限を課すが、ほとんどの場合、スライスのレイアウトは、符号化画像から符号化画像へと変更することができ、そして、しばしば、レート制御およびMTUサイズマッチングといったメカニズムによって決定される。

【0067】

タイルは、一方で、典型的には、CUの長方形配置（rectangular arrangement）を参照することができ、そして、長方形のサイズおよび形状(その長方形タイルおよび他の長方形タイルが、組み合わされてピクチャを構成する)は、パラメータセット内で符号化される。別の言葉で言えば、タイルレイアウトは、１つのタイルレイアウトから別のタイルレイアウトへの変更が異なるパラメータセットの動作化を必要とするという点で、いくらか静的（static）である。さらに、効率的なハードウェア実装を可能にするように、タイルの数が有利に制限され得る。その結果、多くのビデオ圧縮技術および標準において、例えば、8ビットの比較的に短い固定長バイナリコードワードは、実際に使用される全ての画像サイズについてタイルの最大数を扱うことを可能にする。従って、タイルIDに対する固定長コードワードは、NALユニットヘッダ内のタイルを識別するために使用され、それによって、タイル識別NALユニットヘッダコードワードとパラメータセットとの間の解析およびコンテキスト依存性を回避することができる。同様に、タイル群を識別するために、タイル群IDに対する固定長コードワードが使用され得る。もちろん、NALユニットヘッダ内のマクロブロック／CUアドレスに対する可変長コードワードをサポートするメカニズムは、そのように所望であれば、同様なアーキテクチャ上の欠点を犠牲にして、タイルIDコードワードについて同様に適用され得る。

【0068】

図6を参照すると、NALユニットヘッダ設計のためのいくつかの実装オプションが紹介されている。

【0069】

NALユニット(601)は、符号化ビデオビットストリームの一部であり得る。場合によって、NALユニットは、オクテット整列され、そして、データネットワークの共通最大転送ユニット（Maximum Transfer Unit、MTU）サイズより小さいか又は等しい。そうした共通のMTUサイズの１つは、概ね1500オクテットであり、これは初期のイーサネット技術に係る所定の限界に由来する。NALユニットは、最初に、NALユニットヘッダ(602)を含み得る。符号化ビデオビットストリームの中のNALユニットのフレーム化（framing）は、開始コード（start code）を通じたもの、根底にあるパケット指向トランスポートネットワークのパケット構造との整合を通じたもの、等である。

【0070】

図6を再び参照すると、例示的なNALユニットヘッダのシンタックスダイヤグラム(603)も、また、示されており、これは、H.265で使用されるものと同様である。開示される技術的事項は、同様に、類似の構造のNALユニットヘッダと共に使用され得る。例えば、H.264のNALユニットヘッダ、または、VVC、もしくは、固定長コードワードを含む任意の他のハイレベルシンタックス構造である。NALユニットヘッダ(603)には、シンタックス要素CUアドレスまたはタイルID(604)が含まれ得る。そのシンタックス要素の長さは固定されてよく、そして、NALユニットヘッダがオクテット整列され続けるように選択され得る。シンタックス要素(604)は、ビデオエンコーダおよびデコーダだけでなく、MANEによっても、また、容易に処理可能なフォーマットであり得る。例示として、かつ、限定ではなく、CUアドレスまたはタイルID(604)は、記述子（Descriptor）u(6)によって表されるような、6ビット符号なし整数（6 bit unsigned integer）によって表現され得る。提示される例において、CUアドレスまたはタイルIDは、H.265において、layer_idに使われているのと同じビットを占有する。同様な技術的事項の異なる提示が、NALユニットヘッダ(605)、および、CUアドレスまたはタイルID(606)を用いて示されている。

【0071】

また、H.265 NALユニットヘッダのフィールドを保存するNALユニット(607)も示されている。シンタックス要素(608)が、例えば、NALユニットヘッダの終端に追加されている。そのシンタックス要素の位置は例示的なものに過ぎず、それは、また、NALユニットヘッダの他のシンタックス要素の中央のどこかに挿入されてもよい。そのシンタックス要素は固定または可変サイズであり得る。そして、可変サイズの場合に、そのサイズは、上述のメカニズムのいずれか(例えば、パラメータセットシンタックス要素を通じて、NALユニットタイプを通じて、等)、または、任意の他の適切なメカニズムによって決定され得る。

【0072】

シンタックス要素(608)は、ピクチャセグメント識別情報の任意の形式を搬送することができる。例えば、タイル番号といったマクロブロック／CUアドレスまたはタイル識別子、または、タイル群を示す番号、である。シンタックス要素の番号付け（numbering）範囲は、あらかじめ決定され得る。マクロブロック／CUアドレスの場合に、番号付け範囲は、０からピクチャ内のマクロブロック／CUの最大数であり得る。タイルIDについて、番号付け範囲は、タイルの最大数に依存し、例えば、プロファイル、レベル、階層（tiers）、パラメータセットで符号化される最大または実際の画像サイズ、等、といった、当業者に知られたメカニズムによって定義され得る。シンタックス要素が非タイル／スライス（non-tile/slice）NALユニット(パラメータセットNALユニット、SEI NALユニット、等、といったもの)について存在する場合に、シンタックス要素の値は、所定の数、例えば０に制限され得る。代替的に、シンタックス要素の存在は、NALユニットタイプにおいてゲートすることができ、そして、それによって、シンタックス要素は、所定のNALユニットタイプに存在しなくてよい。代替的に、上述のもの以外のオーバライド（overriding）セマンティックが、所定の非タイル／スライスNALユニットタイプの場合に、シンタックス要素に対して割り当てられ得る。

【0073】

同一または別の実施形態において、タイルIDは、例えば、以下のように識別され得る。図7は、太字の線を通じて示された例示的なタイルレイアウト(702)によって細分された、空間領域（spatial domain）におけるピクチャ(701)を示している。提示されるタイルレイアウトは、例えばH.265で利用可能なシンタックスによって、または、タイルレイアウト(702)を表現するために必要とされるであろう、より高度なシンタックスによって、表現可能であり得る。タイルレイアウト内の各タイルは、任意の適切な番号付けメカニズムを通して、しかし、好ましくは、タイルのスキャン順序番号付けを通して、割り当てられたタイルIDを有し得る。図7においては、スキャン順序タイル番号付けが、タイルID １から８を通して示されており、例えば、スキャン順序における第２タイルは、割り当てられたタイルID 2(703)を有する。

【0074】

エンコーダは、タイルIDをカバーするシンタックス要素、または、上述のように配置されたマクロブロック／CUアドレスを含むNALユニットのヘッダを、当業者に知られている、既存のNALユニットのヘッダシンタックスを記述するのと同様の方法で、書くことができる。

【0075】

デコーダまたはMANEは、符号化ビデオビットストリームから、NALユニットヘッダ－より正確には－NALユニットヘッダを構成するシンタックス要素を、マクロブロック／CUアドレス、または、タイルID、もしくは、タイル識別情報の他の形式を搬送するシンタックス要素の存在または不存在にかかわらず、当業者に知られた方法で、解析することができる。しかしながら、シンタックス要素は、上述のように場合によっては、状態情報を要求することなく符号化されてよく、そして、アクセス可能なエントロピー符号化フォーマット、例えば、固定長、バイナリコード、であり得ることが留意されるべきである。これまでのところ、開示される技術的事項に従ってNALユニットヘッダを解析することは、シンタックス要素tile_id自体の実際の存在を超えて、デコーダまたはMANEに対する追加的な負担を含まないものであり得る。

【0076】

開示される技術的事項に従って、デコーダまたはMANEは、しかしながら、開示される技術的事項がない場合に必要とされるオペレーションと比較して、ほとんど努力せずに符号化画像におけるタイルを識別することができる。一つの例として、デコーダまたはMANEが、外部の、非ビデオ符号化手段によって、所定のアプリケーションについて所定のタイルが再構成される必要がないことを知らされたものと仮定する。例えば、図7に示されているようなシーンを考える。すなわち、村の道路である。道路が監視カメラによってキャプチャされているものと仮定する。タイルID 2(703)を有するタイルを考えてみる。そのタイルは、ほとんど壁面をカバーしており、監視システムのコンフィギュレータ（configurator）は、その領域が監視について関係しないと考えているものと仮定する。従って、カメラは全てのタイルを符号化することができるが、ID 2を有するタイルは、アプリケーションに必要とされないものであり得る。従って、カメラによって生成されたビットストリームが１つ以上のMANEを通して最終的な宛先へルーティングされ、そして、１つのMANEが帯域幅不足を観察し、かつ、ビットストリームから何かを取り除かなければならない場合、そのタイルはアプリケーションのために必要とされないので、有利にそのタイルを除去することができる。開示される技術的事項がない場合には、タイル内の最初のマクロブロックのマクロブロック／CUアドレスを抽出するために、最低限、NALユニット(スライスまたはタイル)のペイロードが、必要とされる範囲で、解析されることを要求し、次いで、タイルレイアウト(タイルが使用されている場合)に対してそのマクロブロック／CUアドレスをマッピングするであろう。使用されているビデオ符号化技術または標準に依存して、かつ、上述のように、可変長コードワードの処理およびMANEにおけるパラメータセットコンテキストの保持の両方が必要とされ得るが、実装と計算の複雑さの観点では、両方が望ましくない。その代わりに、同一または別の実施形態において、MANEは、バイナリ符号化コードワードのNALユニットヘッダ処理を通して、NALユニットによってどのタイルが搬送されるかを識別するために必要な全ての情報を獲得し得る。

【0077】

図8を参照すると、デコーダまたはMANEは、開示される技術的事項を、例えば以下のように使用することができる。

【0078】

デコーダは、ビデオビットストリームから、マクロブロック／CUアドレスまたはタイルIDをカバーしているシンタックス要素を含むNALユニットヘッダを解析し得る(801)。その情報を使用して、デコーダまたはMANEは、タイルIDを識別することができる(802)。タイルIDは、直接的に符号化されてよく、または、例えば、パラメータセットおよび次に続く動作化シーケンスを復号化することによって確立される、タイルレイアウトに関する先験的（priori）情報を、NALユニットヘッダ内の符号化されたマクロブロック／CUアドレスとマッチングすることができる。デコーダは、デコーダまたはMANEによって、それぞれに、再構成または転送を必要とするタイルのリストに対してタイルIDをマッチングすることができる(803)。マッチングが存在する場合に(803)、タイルを搬送しているNALユニットを、デコーダが再構成することができ、または、MANEが転送することができる。しかしながら、マッチングが存在しない場合に(804)、デコーダまたはMANEは、おそらく黙って、NALユニットを破棄することができる。

【0079】

上述のネットワーク抽象化ユニットヘッダにおける画像参照のための技術は、コンピュータで読取り可能な命令を使用してコンピュータソフトウェアとして実装され、そして、１つ以上のコンピュータで読取り可能な媒体に物理的に保管され得る。例えば、図9は、開示される技術的事項のうち所定の実施形態を実施するために適したコンピュータシステム900を示している。

【0080】

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

【0081】

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

【0082】

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

【0083】

コンピュータシステム900は、所定のヒューマンインターフェイス入力装置を含み得る。そうしたヒューマンインターフェイス入力装置は、例えば、触覚入力(例えば、キーストローク、スワイプ、データグローブの動き)、オーディオ入力(例えば、音声、拍手)、視覚入力(例えば、ジェスチャ)、嗅覚入力(図示なし)を通じて、一人以上の人間ユーザによる入力に対して応答し得る。ヒューマンインターフェイス装置は、また、オーディオ(例えば、音声、音楽、雰囲気の音)、画像(例えば、スキャン画像、静止画像カメラから獲得する写真画像)、ビデオ(例えば、２次元ビデオ、立体画像を含む３次元ビデオ)といった、人間による意識的な入力に必ずしも直接的に関係しない所定の媒体をキャプチャするためにも使用され得る。

【0084】

入力ヒューマンインターフェイス装置は、キーボード901、マウス902、トラックパッド903、タッチスクリーン910、データグローブ904、ジョイスティック905、マイクロホン906、スキャナ907、カメラ908のうちの１つ以上（それぞれ１つだけが描かれている）を含み得る。

【0085】

コンピュータシステム900は、また、所定のヒューマンインターフェイス出力装置を含み得る。そうしたヒューマンインターフェイス出力装置は、例えば、触覚出力、音、光、および、嗅覚／味覚を通して、一人以上の人間ユーザの感覚を刺激することができる。そうしたヒューマンインターフェイス出力装置は、触覚出力装置(例えば、タッチスクリーン910、データグローブ904、または、ジョイスティック905による触覚フィードバック、しかし、入力装置として機能しない触覚フィードバック装置も、また、存在し得る)、オーディオ出力装置(例えば、スピーカー909、ヘッドフォン(図示なし))、視覚出力装置(CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン910であり、各々がタッチスクリーン入力機能を有するか又は有さない、各々が触覚フィードバック機能を有するか又は有さず、－これらのいくつかは、立体画像出力といった手段を介して、２次元の視覚出力または３次元以上の出力をアウトプットすることができ、仮想現実メガネ(図示なし)、ホログラフィックディスプレイおよびスモークタンク(図示なし)、といったもの)、および、プリンタ(図示なし)を含み得る。

【0086】

コンピュータシステム900は、また、人間がアクセス可能なストレージ装置、および、それらの関連媒体を含み得る。CD／DVD等の媒体921を用いるCD／DVD ROM／RW 920を含む光媒体、サムドライブ(thumb drive)922、リムーバブルハードドライブまたはソリッドステートドライブ923、テープおよびフロッピー（登録商標）ディスクといったレガシー磁気媒体、セキュリティドングル（図示なし）といった特殊化されたROM／ASIC／PLDベースの装置、等といったものである。

【0087】

当業者であれば、また、ここで開示されている技術的事項に関連して使用される用語「コンピュータで読取り可能な媒体（“computer readable media”）」は、伝送媒体、搬送波、または、他の一時的な信号を包含しないことも理解すべきである。

【0088】

コンピュータシステム900は、また、１つ以上の通信ネットワークに対するインターフェイスを含み得る。ネットワークは、例えば、無線、有線、光であり得る。ネットワークは、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性（delay-tolerant）、等であり得る。ネットワークの例は、イーサネット、GSM、3G、4G、5G、LTE、等を含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、および、地上波放送テレビを含む、有線または無線のワイドエリアデジタルネットワーク、CANBusを含む車両および工業、等を含み得る。所定のネットワークは、一般に、所定の汎用データポートまたはペリフェラルバス(949)に取り付けられる外部ネットワーク・インターフェイスアダプタを必要とする。例えば、コンピュータシステム900のUSBポート、といったものであり、他のものは、一般に、以下に説明されるシステムバスに取り付けることによって、コンピュータシステム900のコアに組み込まれる(例えば、PCコンピュータシステムへのイーサネット・インターフェイス、または、スマートフォン・コンピュータシステムへのセルラーネットワーク・インターフェイス)。これらのネットワークのいずれかを使用して、コンピュータシステム900は、他のエンティティと通信することができる。そうした通信は、一方向性(uni-directional)、受信専用(例えば、放送テレビ)、一方向性送信専用(例えば、所定のCANバス装置へのCANバス)、もしくは、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの、双方向性(bi-directional)であり得る。所定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェイスの各々で使用され得る。

【0089】

上述のヒューマンインターフェイス装置、人間がアクセス可能なストレージ装置、および、ネットワークインターフェイスは、コンピュータシステム900のコア940に取り付けられ得る。

【0090】

コア940は、１つ以上の中央処理装置(CPU)941、グラフィックス処理装置(GPU)942、フィールドプログラマブルゲートアレイ(FPGA)943の形態で特殊化されたプログラマブル処理装置、所定のタスクのためのハードウェアアクセラレータ1044、等を含み得る。これらの装置は、リードオンリーメモリ(ROM)945、ランダムアクセスメモリ946、内部非ユーザアクセス可能ハードドライブ、SSD、等といった内部大容量ストレージ装置947と共に、システムバス948を通じて接続され得る。いくつかのコンピュータシステムにおいて、システムバス948は、追加のCPU、GPU、等による拡張を可能にするために、１つ以上の物理的プラグの形態でアクセス可能であり得る。ペリフェラル装置は、コアのシステムバス948に直接的に取り付けられても、または、ペリフェラルバス949を通じて取り付けられてもよい。ペリフェラルバスのアーキテクチャは、PCI、USB、等を含む。

【0091】

CPU 941、GPU 942、FPGA 943、およびアクセラレータ944は、組み合わせて、上述のコンピュータコードを構成することができる所定の命令を実行することができる。そのコンピュータコードは、ROM 945またはRAM 946に保管することができる。過渡的データは、また、RAM 946に保管することができ、一方で、永久的データは、例えば、内部大容量ストレージ装置947に保管することができる。メモリデバイスのいずれかへの高速保管および検索が、１つ以上のCPU 941、GPU 942、大容量ストレージ装置947、ROM 945、RAM 946、等と密接に関連付けされ得る、キャッシュメモリの使用を通じて、可能にされ得る。

【0092】

コンピュータで読取り可能な媒体は、種々のコンピュータ実装オペレーションを実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築され得るか、または、それらは、コンピュータソフトウェア技術の当業者にとって周知かつ入手可能な種類のものであり得る。

【0093】

一つの例として、そして、限定するものではなく、アーキテクチャ900を有するコンピュータシステム、および、具体的にはコア940は、１つ以上の有形なコンピュータで読取り可能な媒体において具現化されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ、等を含む)の結果として機能性を提供することができる。そうしたコンピュータで読取り可能な媒体は、上述のようにユーザがアクセス可能な大容量ストレージ装置、並びに、コア内部大容量ストレージ装置947またはROM 945といった、非一時的な性質のコア940に係る所定のストレージ装置であり得る。本開示の様々な実施形態を実装するソフトウェアは、そうした装置において保管され、そして、コア940によって実行され得る。コンピュータで読取り可能な媒体は、特定的なニーズに応じて、１つ以上のメモリデバイスまたはチップを含み得る。ソフトウェアは、コア940、および、具体的には、その中のプロセッサ(CPU、GPU、FPG、等を含む)に、ここにおいて説明された特定のプロセスまたは特定のプロセスに係る特定の部分を実行させ得る。RAM 946に保管されたデータ構造を定義すること、および、ソフトウェアによって定義されたプロセスに従ってそうしたデータ構造を修正することを含むものである。追加して、または代替として、コンピュータシステムは、回路(例えば、アクセラレータ944)において配線された、または、他の方法で具現化されたロジックの結果として機能性を提供することができる。回路は、ここにおいて説明される特定のプロセスまたは特定のプロセスの特定的な部分を実行するために、ソフトウェアの代わりに、または、一緒に動作することができる。ソフトウェアへの参照は、ロジックを含み、そして、適切な場合には、その逆もまた同様である。コンピュータで読取り可能な媒体への参照は、実行のためのソフトウェアを保管する回路（集積回路（IC）といったもの）、実行のためのロジックを具体化する回路、または、適切な場合には、その両方を含むことができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含するものである。

【0094】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】