特表 2022-510325 符号化ビデオストリームを復号するための方法、システム、及びコンピュータプログラム

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

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

(11)【公表番号】

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

(54)【発明の名称】符号化ビデオストリームを復号するための方法、システム、及びコンピュータプログラム

(51)【国際特許分類】

   H04N 19/70 20140101AFI20220119BHJP

【ＦＩ】

H04N19/70

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021531271

(86)(22)【出願日】2020-01-21

(85)【翻訳文提出日】2021-05-31

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

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

(87)【国際公開日】2020-07-30

(31)【優先権主張番号】62/795,526

(32)【優先日】2019-01-22

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

(31)【優先権主張番号】16/745,824

(32)【優先日】2020-01-17

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

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

(72)【発明者】

【氏名】リィウ，シャン

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

5C159

【Ｆターム（参考）】

5C159MA04

5C159MA05

5C159MA21

5C159MC11

5C159ME01

5C159RB09

5C159RC12

5C159UA02

5C159UA05

5C159UA16

(57)【要約】

ビデオストリームを復号する方法及びシステムが提供され、当該方法は、複数のタイルグループへと分割されたピクチャを有する符号化ビデオストリームを受信するステップであり、前記複数のタイルグループの各々が、少なくとも１つのタイルを含み、前記符号化ビデオストリームは更に、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを指し示す第１のインジケータを含む、ステップと、前記第１のインジケータに基づいて、前記ピクチャの前記タイルグループが矩形形状を持つかを特定するステップと、前記タイルグループを再構築する、転送する、又は破棄するステップと、を有する。

【特許請求の範囲】

【請求項1】

少なくとも１つのプロセッサが実行する方法であって、
複数のタイルグループへと分割されたピクチャを有する符号化ビデオストリームを受信するステップであり、前記複数のタイルグループの各々が、少なくとも１つのタイルを含み、前記符号化ビデオストリームは更に、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを指し示す第１のインジケータを含む、ステップと、
前記第１のインジケータに基づいて、前記ピクチャの前記タイルグループが矩形形状を持つかを特定するステップと、
前記タイルグループを再構築する、転送する、又は破棄するステップと、
を有する方法。

【請求項2】

前記第１のインジケータはフラグである、請求項１に記載の方法。

【請求項3】

前記フラグは、前記符号化ビデオストリームのパラメータセット内で提供される、請求項２に記載の方法。

【請求項4】

前記パラメータセットはピクチャパラメータセット（“ＰＰＳ”）である、請求項３に記載の方法。

【請求項5】

受信される前記符号化ビデオストリームの前記第１のインジケータは、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを、前記ピクチャの前記複数のタイルグループのうちのいずれか他のタイルグループが矩形形状を持つかを指し示すことなく、指し示す、請求項１に記載の方法。

【請求項6】

受信される前記符号化ビデオストリームの前記第１のインジケータは、前記タイルグループが矩形形状を持つことを指し示し、
前記符号化ビデオストリームは更に、各々が前記タイルグループのそれぞれのコーナーを指し示す複数の構文要素を含み、
当該方法は更に、前記複数の構文要素に基づいて前記タイルグループのサイズ又は位置を特定するステップを有する、
請求項１に記載の方法。

【請求項7】

前記複数の構文要素は、前記符号化ビデオストリームのパラメータセット内で提供される、請求項６に記載の方法。

【請求項8】

前記パラメータセットはピクチャパラメータセット（“ＰＰＳ”）である、請求項７に記載の方法。

【請求項9】

受信される前記符号化ビデオストリームは更に、複数の構文要素を含み、該複数の構文要素の各々が、前記複数のタイルグループのうちのそれぞれのタイルグループのタイルグループ識別子（ＩＤ）を指し示す、請求項１に記載の方法。

【請求項10】

受信される前記符号化ビデオストリームは更に、パラメータセット又はタイルグループヘッダ内に、前記タイルグループに含まれるタイルの数を指し示す第２のインジケータを含み、
当該方法は更に、ラスタースキャン順にタイルの数をカウントすることに基づいて、前記ピクチャ内での前記タイルグループのコーナーの位置を特定するステップを有する、
請求項１に記載の方法。

【請求項11】

受信される前記符号化ビデオストリームは更に、前記タイルグループが動き制約タイルセットであるか、又は前記タイルグループが複数の動き制約タイルを含むか、を指し示す第２のインジケータを含み、
当該方法は更に、前記第２のインジケータに基づいて、前記符号化ビデオストリームの前記タイルグループが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを特定するステップを有する、
請求項１に記載の方法。

【請求項12】

複数のタイルグループへと分割されたピクチャを含む符号化ビデオストリームを復号するシステムであって、前記複数のタイルグループの各々が、少なくとも１つのタイルを含み、当該システムは、
コンピュータプログラムコードを格納するように構成されたメモリと、
前記符号化ビデオストリームを受信し、前記コンピュータプログラムコードにアクセスし、且つ前記コンピュータプログラムコードによって命令されるように動作するように構成される少なくとも１つのプロセッサと、
を有し、
前記コンピュータプログラムコードは、
前記少なくとも１つのプロセッサに、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを、前記符号化ビデオストリームに含められた、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを指し示す第１のインジケータに基づいて、特定させるように構成された第１の特定コードと、
前記少なくとも１つのプロセッサに前記タイルグループを再構築させ、転送させる、又は破棄させるように構成された実行コードと、
を含む、
システム。

【請求項13】

前記第１のインジケータはフラグである、請求項１２に記載のシステム。

【請求項14】

前記フラグは、前記符号化ビデオストリームのパラメータセット内で提供される、請求項１３に記載のシステム。

【請求項15】

前記符号化ビデオストリームの前記第１のインジケータは、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを、前記ピクチャの前記複数のタイルグループのうちのいずれか他のタイルグループが矩形形状を持つかを指し示すことなく、指し示す、請求項１２に記載のシステム。

【請求項16】

前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームにて受信される複数の構文要素に基づいて、前記タイルグループのサイズ又は位置を特定させるように第２の特定コードを含み、前記複数の構文要素の各々が、前記タイルグループのそれぞれのコーナーを指し示す、請求項１２に記載のシステム。

【請求項17】

前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記タイルグループのタイルグループ識別子（ＩＤ）を指し示す構文要素に基づいて、前記複数のタイルグループのうちの前記タイルグループを特定させるように構成された第２の特定コードを含む、請求項１２に記載のシステム。

【請求項18】

前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記タイルグループに含まれるタイルの数を指し示す第２のインジケータに基づいて、且つ更に、ラスタースキャン順に前記タイルグループに含まれるタイルの数をカウントすることに基づいて、前記ピクチャ内での前記タイルグループのコーナーの位置を特定させるように構成された第２の特定コードを含む、請求項１２に記載のシステム。

【請求項19】

前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記符号化ビデオストリームが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを指し示す第２のインジケータに基づいて、前記符号化ビデオストリームの前記タイルグループが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを特定させるように構成された第２の特定コードを含む、請求項１２に記載のシステム。

【請求項20】

コンピュータ命令を含むコンピュータプログラムであって、前記コンピュータ命令は、少なくとも１つのプロセッサによって実行されるときに、該少なくとも１つのプロセッサに、請求項１乃至１１のいずれか一項に記載の方法を実行させる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

この出願は、２０１９年１月２２日に出願された米国仮出願第６２／７９５，５２６号、及び２０２０年１月１７日に出願された米国出願第１６／７４５，８２４号からの優先権を主張するものであり、それらの開示をそれらの全体にてここに援用する。

【0002】

開示に係る事項は、映像の符号化及び復号に関し、より具体的には、符号化された映像のピクチャに関するタイル及びタイルグループ構造の信号伝達及び特定のための技術に関する。

【背景技術】

【0003】

動き補償を用いるインターピクチャ予測を使用した映像符号化及び復号が以前から使われている。圧縮されていないデジタル映像は一連のピクチャを含み、各ピクチャが、例えば、１９２０×１０８０の輝度（ルミナンス）サンプル及び関連する色（クロミナンス）サンプルの空間寸法を持つ。一連のピクチャは、固定又は可変のピクチャレート（非公式にはフレームレートとしても知られる）を持つことができ、例えば、毎秒６０ピクチャ、すなわち、６０Ｈｚのピクチャレートを持ち得る。圧縮されていない映像は、かなりのビットレート要求を持つ。例えば、サンプル当たり８ビットの１０８０ｐ６０ ４：２：０映像（６０Ｈｚのフレームレートで１９２０×１０８０のルミナンスサンプル解像度）は、１．５Ｇｂｉｔ／ｓに近い帯域幅を必要とする。１時間のこのような映像は、６００Ｇバイトを超えるストレージ空間を必要とする。

【0004】

映像の符号化及び復号の１つの目的は、圧縮を通じての入力映像信号の冗長性の低減であるとし得る。圧縮は、前述の帯域幅要求又はストレージ空間要求を、場合によって２桁以上の大きさで、低減させる助けとなることができる。可逆圧縮及び不可逆圧縮の双方、並びにこれらの組み合わせを使用することができる。可逆圧縮は、原信号の正確な複製を圧縮された原信号から再構成することができる技術を指す。不可逆圧縮を使用する場合、再構成された信号は、原信号と同じにならないことがあるが、原信号と再構成信号との間の歪みは、再構成信号を意図した用途に有用にするのに十分な小ささとなり得る。映像の場合、不可逆圧縮が広く用いられる。許容される歪みの量は用途に依存し、例えば、特定の消費者ストリーミングアプリケーションのユーザは、テレビジョン寄与アプリケーションのユーザよりも高い歪みを許容し得る。達成可能な圧縮比はそれを反映し、より高い許容／我慢できる歪みは、より高い圧縮比をもたらすことができる。

【0005】

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

【0006】

符号化ビデオビットストリームをパケットネットワーク上での輸送のための複数のパケットに分割するという概念は、以前から使用されている。早くには、映像符号化標準及び技術は、その大多数において、ビット指向の輸送及び境界が明確なビットストリームに合わせて最適化されていた。パケット化は、例えば、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットで規定されるシステム層インタフェースで行われていた。インターネット上での映像の大量使用に適したインターネット接続の出現により、映像符号化標準は、映像符号化層（video coding layer；ＶＣＬ）及びネットワーク抽象化層（network abstraction layer；ＮＡＬ）の概念的な区別を通して、その優れた使用事例を反映してきた。ＮＡＬユニットは、２００３年にＨ．２６４で導入され、それ以来、僅かな修正のみで、ある特定の映像符号化標準及び技術で維持されてきた。

【0007】

ＮＡＬユニットは、多くの場合、符号化映像シーケンスの全ての先行ＮＡＬユニットを必ずしも復号済みである必要なくデコーダが作用することができる最小エンティティとして見ることができる。ＮＡＬユニットは、ある特定のエラー回復技術及びある特定のビットストリーム操作技術が、例えば選択的転送ユニット（Selective Forwarding Unit；ＳＦＵ）又は多地点制御ユニット（Multipoint Control Unit；ＭＣＵ）などのメディアアウェアネットワーク要素（Media Aware Network Element；ＭＡＮＥ）により、ビットストリーム剪定を含むことを可能にする。

【0008】

図５Ａ－５Ｂは、どちらの場合もそれぞれの拡張なしでのＨ．２６４（５０１）及びＨ．２６５（５０２）に従ったＮＡＬユニットヘッダの構文の一部の構文図を示している。どちらの場合も、forbidden_zero_bitは、特定のシステム層環境で開始コードエミュレーション防止のために使用されるゼロビットである。nal_unit_type構文要素は、ＮＡＬユニットが運ぶデータのタイプを指し、それは例えば、特定のスライスタイプ、パラメータセットタイプ、補足強化情報（Supplementary Enhancement Information；ＳＥＩ）メッセージなどのうちの１つである。Ｈ．２６５のＮＡＬユニットヘッダは更に、nuh_layer_id及びnuh_temporal_id_plus1を含み、これらは、ＮＡＬユニットが属する符号化ピクチャの空間／ＳＮＲ及び時間層を指し示す。

【0009】

気付き得ることには、ＮＡＬユニットヘッダは、例えば他のＮＡＬユニットヘッダやパラメータセットなどの、ビットストリーム内の他のデータへの構文解析依存性を持たない、容易に構文解析可能な固定長のコードワードのみを含む。ＮＡＬユニットヘッダはＮＡＬユニットの最初のオクテットであるので、ＭＡＮＥは容易にそれらを抽出し、それらを構文解析し、そして、それらに作用することができる。例えばスライス又はタイルヘッダといった、他のハイレベル構文要素は、対照的に、さほど容易にＭＡＮＥにアクセス可能でない。何故なら、それらは、パラメータセットコンテキスト及び／又は可変長若しくは算術符号化コードポイントの処理を維持することを必要とし得るからである。

【0010】

更に気付き得ることには、図５Ａ－Ｂに示すＮＡＬユニットヘッダは、符号化ピクチャの空間領域を表すビットストリームの、例えばスライス、タイル、又は同様の部分などの、符号化ピクチャのセグメントにＮＡＬユニットを関連付けることができる情報を含んでいない。関連技術において、そのような情報は、マクロブロック又はＣＵアドレスの形態で特定のケースにおいて、スライスヘッダ内に存在する。そのアドレスは、一部のケースにおいて、ピクチャの左上から数えるときにスキャン順でｎ番目のマクロブロック／ＣＵで、セグメント、スライス、タイルが始まることを示す整数ｎである。従って、ｎは、ピクチャサイズ及びマクロブロック／ＣＵサイズの双方に依存することができ、そちらの場合にも１６×１６サンプルのマクロブロック／ＣＵサイズを仮定すると、小さいピクチャサイズで小さくなることもあれば（バイナリコードで８ビットに収められる）、大きくなることもある（例えば、３２４００であり、バイナリコードで１６ビットを要する）。

【0011】

以前は、最大転送ユニット（Maximum Transfer Unit）サイズ制約に合致するビットストリーム分割、及び並列化を容易にするために、大抵は例えばタイル又はスライスなどのピクチャセグメントが使用されていた。どちらの場合も、メディアアウェアネットワーク要素（ＭＡＮＥ）、選択的転送ユニット（ＳＦＵ）又は類似の装置におけるタイル又はスライスの特定は、通常、必要なく、デコーダは、パラメータセットの復号から得られる状態と共に、比較的複雑なスライスヘッダ及び／又は類似の情報から関連情報を得ることができる。

【0012】

しかしながら、より最近になって、例えば、数あるアプリケーションの中でもとりわけ、合成された３６０投影において特定のビューを表すＣＵを集めるなどの目的で、ピクチャセグメント及び特にタイル（及びスキャン順、碁盤目の順序、又は他の好適順序でのタイルの集合であるタイルグループ）が使用されている。これらのアプリケーションの一部において、ＭＡＮＥ及びＳＦＵは、アプリケーションに必要とされない場合に、符号化されたピクチャから特定のタイル又は他のセグメントを有利に除去することができる。例えば、立方体投影が使用されるとき、外側の視点からのシーンをレンダリングすることは、６つの立方体表面のうち最大で３つを必要とする。残りの最小３つの表面を表すＣＵ及びセグメントをエンドポイントに伝送することは、リソースの無駄となり得る。しかしながら、送信者がＭＡＮＥに完全な表現（立方体投影の６つ全ての表面を含む）を送信し、ＭＡＮＥが必要なサブセットのみを潜在的な複数の受信者に転送し得るシナリオであって、必要なサブセットが受信者間で異なり得るシナリオでは、ＭＡＮＥは、受信者ごとに、異なり得る立方体表面を含む異なり得るビットストリームを仕立てることになる。そうすることは、現時においては、ＭＡＮＥが、複合的な可変長の符号化スライスヘッダを処理するとともに、スライスヘッダを復号するために必要とされるように、パラメータセットなどの形式で状態を保持することを必要とする。

【0013】

以上のことを考えると、従来の映像符号化構文は、タイルグループ又はハイレベル構文構造における他のピクチャセグメントを特定する容易に特定可能且つ構文解析可能な構文要素を欠いている。

【発明の概要】

【0014】

本開示の一部の実施形態は、前述の問題及び他の問題に対処する。

【0015】

一部の実施形態において、少なくとも１つのプロセッサによって実行される方法が提供される。当該方法は、複数のタイルグループへと分割されたピクチャを有する符号化ビデオストリームを受信するステップであり、前記複数のタイルグループの各々が、少なくとも１つのタイルを含み、前記符号化ビデオストリームは更に、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを指し示す第１のインジケータを含む、ステップと、前記第１のインジケータに基づいて、前記ピクチャの前記タイルグループが矩形形状を持つかを特定するステップと、前記タイルグループを再構築する、転送する、又は破棄するステップと、を有する。

【0016】

一実施形態において、前記第１のインジケータはフラグである。一実施形態において、該フラグは、前記符号化ビデオストリームのパラメータセット内で提供される。一実施形態において、該パラメータセットはピクチャパラメータセット（“ＰＰＳ”）である。

【0017】

一実施形態において、受信される前記符号化ビデオストリームの前記第１のインジケータは、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを、前記ピクチャの前記複数のタイルグループのうちのいずれか他のタイルグループが矩形形状を持つかを指し示すことなく、指し示す。

【0018】

一実施形態において、受信される前記符号化ビデオストリームの前記第１のインジケータは、前記タイルグループが矩形形状を持つことを指し示し、前記符号化ビデオストリームは更に、各々が前記タイルグループのそれぞれのコーナーを指し示す複数の構文要素を含み、当該方法は更に、前記複数の構文要素に基づいて前記タイルグループのサイズ又は位置を特定するステップを有する。一実施形態において、前記複数の構文要素は、前記符号化ビデオストリームのパラメータセット内で提供される。一実施形態において、該パラメータセットはピクチャパラメータセット（“ＰＰＳ”）である。

【0019】

一実施形態において、受信される前記符号化ビデオストリームは更に、複数の構文要素を含み、該複数の構文要素の各々が、前記複数のタイルグループのうちのそれぞれのタイルグループのタイルグループ識別子（ＩＤ）を指し示す。

【0020】

一実施形態において、受信される前記符号化ビデオストリームは更に、パラメータセット又はタイルグループヘッダ内に、前記タイルグループに含まれるタイルの数を指し示す第２のインジケータを含み、当該方法は更に、ラスタースキャン順にタイルの数をカウントすることに基づいて、前記ピクチャ内での前記タイルグループのコーナーの位置を特定するステップを有する。

【0021】

一実施形態において、受信される前記符号化ビデオストリームは更に、前記タイルグループが動き制約タイルセットであるか、又は前記タイルグループが複数の動き制約タイルを含むか、を指し示す第２のインジケータを含み、当該方法は更に、前記第２のインジケータに基づいて、前記符号化ビデオストリームの前記タイルグループが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを特定するステップを有する。

【0022】

一部の実施形態において、システムが提供される。当該システムは、複数のタイルグループへと分割されたピクチャを含む符号化ビデオストリームを復号するためのものであり、前記複数のタイルグループの各々が、少なくとも１つのタイルを含む。当該システムは、コンピュータプログラムコードを格納するように構成されたメモリと、前記符号化ビデオストリームを受信し、前記コンピュータプログラムコードにアクセスし、且つ前記コンピュータプログラムコードによって命令されるように動作するように構成される少なくとも１つのプロセッサと、を有し、前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを、前記符号化ビデオストリームに含められた、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを指し示す第１のインジケータに基づいて、特定させるように構成された第１の特定コードと、前記少なくとも１つのプロセッサに前記タイルグループを再構築させ、転送させる、又は破棄させるように構成された実行コードと、を含む。

【0023】

一実施形態において、前記第１のインジケータはフラグである。一実施形態において、該フラグは、前記符号化ビデオストリームのパラメータセット内で提供される。

【0024】

一実施形態において、前記符号化ビデオストリームの前記第１のインジケータは、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを、前記ピクチャの前記複数のタイルグループのうちのいずれか他のタイルグループが矩形形状を持つかを指し示すことなく、指し示す。

【0025】

一実施形態において、前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームにて受信される複数の構文要素に基づいて、前記タイルグループのサイズ又は位置を特定させるように第２の特定コードを含み、前記複数の構文要素の各々が、前記タイルグループのそれぞれのコーナーを指し示す。

【0026】

一実施形態において、前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記タイルグループのタイルグループ識別子（ＩＤ）を指し示す構文要素に基づいて、前記複数のタイルグループのうちの前記タイルグループを特定させるように構成された第２の特定コードを含む。

【0027】

一実施形態において、前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記タイルグループに含まれるタイルの数を指し示す第２のインジケータに基づいて、且つ更に、ラスタースキャン順に前記タイルグループに含まれるタイルの数をカウントすることに基づいて、前記ピクチャ内での前記タイルグループのコーナーの位置を特定させるように構成された第２の特定コードを含む。

【0028】

一実施形態において、前記コンピュータプログラムコードは更に、前記少なくとも１つのプロセッサに、前記符号化ビデオストリームに含められた、前記符号化ビデオストリームが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを指し示す第２のインジケータに基づいて、前記符号化ビデオストリームの前記タイルグループが動き制約タイルセットであるか又は複数の動き制約タイルを含むかを特定させるように構成された第２の特定コードを含む。

【0029】

一部の実施形態において、コンピュータ命令を格納した非一時的なコンピュータ読み取り可能媒体が提供される。前記コンピュータ命令は、少なくとも１つのプロセッサによって実行されるときに、該少なくとも１つのプロセッサに、各タイルグループが少なくとも１つのタイルを含んだ複数のタイルグループへと分割されたピクチャを含む符号化ビデオストリームを受信した後に、前記複数のタイルグループのうちのあるタイルグループが矩形形状を持つかを、前記符号化ビデオストリームに含められた、前記複数のタイルグループのうちの前記タイルグループが矩形形状を持つかを指し示す第１のインジケータに基づいて特定させ、且つ前記タイルグループを再構築させ、転送させる、又は破棄させる。

【図面の簡単な説明】

【0030】

開示に係る事項の更なる特徴、性質、及び様々な利点が、以下の詳細な説明及び添付の図面から、よりいっそう明らかになる。

【図1】一実施形態に従った通信システムの簡略ブロック図を概略的に例示している。

【図2】一実施形態に従ったストリーミングシステムの簡略ブロック図を概略的に例示している。

【図3】一実施形態に従ったビデオデコーダ及びディスプレイの簡略ブロック図を概略的に例示している。

【図4】一実施形態に従ったビデオエンコーダ及びビデオソースの簡略ブロック図を概略的に例示している。

【図5A】Ｈ．２６４に従ったＮＡＬユニットヘッダを概略的に例示している。

【図5B】Ｈ．２６５に従ったＮＡＬユニットヘッダを概略的に例示している。

【図6A】一実施形態のＮＡＬユニットを概略的に例示している。

【図6B】一実施形態のＮＡＬユニットヘッダを概略的に例示している。

【図6C】一実施形態のＮＡＬユニットヘッダを概略的に例示している。

【図6D】一実施形態のＮＡＬユニットヘッダを概略的に例示している。

【図7】一実施形態に従ったタイルグループ及びタイルを含むピクチャの一例を示している。

【図8】一実施形態に従った復号のプロセスを例示している。

【図9】一実施形態のシステムを例示している。

【図10】処理のためのピクチャの一例を示している。

【図11】一実施形態に従った復号のプロセスを例示している。

【図12】実施形態を実装するのに適したコンピュータシステムの図である。

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

【0031】

図１は、本開示の一実施形態に従った通信システム１００の簡略ブロック図を例示している。システム１００は、ネットワーク１５０を介して相互接続された少なくとも２つの端末１１０、１２０を含み得る。データの一方向伝送では、第１の端末１１０は、ネットワーク１５０を介した他方の端末１２０への伝送のために、ローカル位置で映像データを符号化し得る。第２の端末１２０は、他方の端末の符号化された映像データをネットワーク１５０から受信し、符号化されたデータを復号し、そして、復元された映像データを表示し得る。一方向データ伝送は、メディアサービス提供アプリケーション及びそれに類するものにおいて一般的であり得る。

【0032】

図１は、例えばテレビ会議中に発生し得る符号化された映像の双方向伝送をサポートするように設けられた第２対の端末１３０、１４０を例示している。データの双方向伝送では、各端末１３０、１４０が、ローカル位置でキャプチャされた映像データを、ネットワーク１５０を介した他方の端末への伝送のために符号化し得る。各端末１３０、１４０はまた、他方の端末によって送信された符号化された映像データを受信することができ、符号化データを復号し、そして、復元された映像データをローカルのディスプレイ装置に表示し得る。

【0033】

図１において、端末１１０－１４０は、例えば、サーバ、パーソナルコンピュータ、及びスマートフォン、及び／又は任意の他のタイプの端末とし得る。例えば、端末１１０－１４０は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は専用のテレビ会議機器とし得る。ネットワーク１５０は、例えば、有線通信ネットワーク及び／又は無線通信ネットワークを含め、端末１１０－１４０間で符号化された映像データを伝達するあらゆる数のネットワークを表す。通信ネットワーク１５０は、回線交換チャネル及び／又はパケット交換チャネルにてデータを交換し得る。代表的なネットワークは、遠距離通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又はインターネットを含む。本説明の目的上、ネットワーク１５０のアーキテクチャ及びトポロジーは、以下にて説明しない限り、本開示の動作にとって重要ではないとし得る。

【0034】

図２は、開示に係る事項に関するアプリケーションの一例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を例示している。開示に係る事項は、例えば、テレビ会議や、デジタルＴＶや、ＣＤ、ＤＶＤ、メモリスティック及びこれらに類するものを含むデジタル媒体上での圧縮映像の格納などを含め、映像を使用可能な他の用途で使用されることもできる。

【0035】

図２に例示するように、ストリーミングシステム２００は、映像ソース２０１及びエンコーダ２０３を含むキャプチャサブシステム２１３を含み得る。ストリーミングシステム２００は更に、少なくとも１つのストリーミングサーバ２０５及び／又は少なくとも１つのストリーミングクライアント２０６を含み得る。

【0036】

映像ソース２０１は、例えば未圧縮の映像サンプルストリーム２０２を作り出すことができる。映像ソース２０１は、例えば、デジタルカメラとし得る。サンプルストリーム２０２は、符号化されたビデオビットストリームと比較して高いデータボリュームであることを強調するために太線として描かれており、カメラ２０１に結合されたエンコーダ２０３によって処理され得る。エンコーダ２０３は、更に詳細に後述される開示に係る事項の態様を使用可能にする又は実装するための、ハードウェア、ソフトウェア、又はこれらの組み合わせを含むことができる。エンコーダ２０３はまた、符号化されたビデオビットストリーム２０４を生成し得る。符号化されたビデオビットストリーム２０４は、未圧縮の映像サンプルストリーム２０２と比較して低いデータボリュームであることを強調するために細線として描かれており、後の使用のためにストリーミングサーバ２０５に格納されることができる。１つ以上のストリーミングクライアント２０６が、符号化されたビデオビットストリーム２０４のコピーとし得るビデオビットストリーム２０９を取り出すためにストリーミングサーバ２０５にアクセスすることができる。

【0037】

実施形態において、ストリーミングサーバ２０５はまた、メディアアウェアネットワーク要素（ＭＡＮＥ）として機能し得る。例えば、ストリーミングサーバ２０５は、複数のストリーミングクライアント２０６のうちの１つ以上に対して異なり得るビットストリームを仕立てるように、符号化ビデオビットストリーム２０４を剪定するように構成され得る。実施形態において、ＭＡＮＥは、ストリーミングシステム２００内のストリーミングサーバ２０５とは別個に設けられてもよい。

【0038】

ストリーミングクライアント２０６は、ビデオデコーダ２１０及びディスプレイ２１２を含むことができる。ビデオデコーダ２１０は、例えば、入ってくる符号化ビデオビットストリーム２０４のコピーであるビデオストリーム２０９を復号し、出ていく映像サンプルストリーム２１１を作り出すことができ、出ていく映像サンプルストリーム２１１が、ディスプレイ２１２又は他のレンダリング装置（図示せず）上でレンダリングされ得る。一部のストリーミングシステムにおいて、ビデオビットストリーム２０４、２０９は、特定の映像符号化／圧縮標準に従って符号化されることができる。そのような標準の例は、これに限られないが、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。非公式にバーサタイルビデオコーディング（Versatile Video Coding；ＶＶＣ）として知られる映像符号化標準が開発中である。本開示の実施形態は、ＶＶＣの文脈で使用されてもよい。

【0039】

図３は、本開示の一実施形態に従った、ディスプレイ２１２に取り付けられたビデオデコーダ２１０の機能ブロック図の一例を示している。

【0040】

ビデオデコーダ２１０は、チャネル３１２、受信器３１０、バッファメモリ３１５、エントロピーデコーダ／パーサ３２０、スケーラ／逆変換ユニット３５１、イントラ予測ユニット３５２、動き補償予測ユニット３５３、アグリゲータ３５５、ループフィルタユニット３５６、参照ピクチャメモリ３５７、及び現在ピクチャメモリ３５８を含み得る。少なくとも１つの実施形態において、ビデオデコーダ２１０は、集積回路、一連の集積回路、及び／又は他の電子回路を含み得る。ビデオデコーダ２１０はまた、部分的又は全体的に、関連するメモリを備えた１つ以上のＣＰＵ上で走るソフトウェアで具現化されてもよい。

【0041】

この実施形態及び他の実施形態において、受信器３１０が、一度に１つの符号化映像シーケンスで、デコーダ２１０によって復号される１つ以上の符号化映像シーケンスを受信することができ、各符号化映像シーケンスの復号は、他の符号化映像シーケンスとは独立である。符号化映像シーケンスは、符号化された映像データを格納するストレージ装置へのハードウェア／ソフトウェアリンクとし得るものであるチャネル３１２から受信され得る。受信器３１０は、符号化映像データを、例えば符号化された音声データ及び／又は補助データストリームといった他のデータと共に受信してもよく、それらのデータは、それらそれぞれの使用エンティティ（図示せず）に転送され得る。受信器３１０は、符号化映像シーケンスを他のデータから分離し得る。ネットワークジッタに対抗するために、受信器３１０とエントロピーデコーダ／パーサ３２０（以下、“パーサ”）との間にバッファメモリ３１５が結合され得る。受信器３１０が、十分な帯域幅及び可制御性の格納／転送装置から又は等同期ネットワークからデータを受信しているとき、バッファ３１５は、使用されなくてもよく、又は小さくされることができる。例えばインターネットなどのベストエフォート型パケットネットワーク上での使用では、バッファ３１５が必要とされ得るとともに、比較的大きくされ、そして、適応可能なサイズのものにされ得る。

【0042】

ビデオデコーダ２１０は、エントロピー符号化された映像シーケンスからシンボル３２１を再構成するためのパーサ３２０を含み得る。それらシンボルのカテゴリは、例えば、デコーダ２１０の動作を管理するために使用される情報を含むとともに、可能性として、図２に示したようにデコーダに結合され得る例えばディスプレイ２１２などのレンダリング装置を制御する情報を含み得る。（１つ以上の）レンダリング装置用の制御情報は、例えば、補足強化情報（Supplementary Enhancement Information；ＳＥＩ）メッセージ又はビデオユーザビリティ情報（Video Usability Information；ＶＵＩ）パラメータセットフラグメント（図示せず）の形態とし得る。パーサ３２０は、受け取った符号化映像シーケンスを構文解析／エントロピー復号し得る。符号化映像シーケンスの符号化は、映像符号化技術又は標準によることができ、可変長符号化、ハフマン符号化、文脈依存性を持つ又は持たない算術符号化などを含め、当業者に周知の原理に従うことができる。パーサ３２０は、符号化映像シーケンスから、グループに対応する少なくとも１つのパラメータに基づいて、ビデオデコーダにおけるピクセルのサブグループのうちの少なくとも１つに関する一組のサブグループパラメータを抽出することができる。サブグループは、グループ・オブ・ピクチャ（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、符号化単位（ＣＵ）、ブロック、変換単位（ＴＵ）、予測単位（ＰＵ）などを含むことができる。パーサ３２０はまた、符号化映像シーケンス情報から、例えば変換係数、量子化パラメータ値、動きベクトルなどの情報を抽出し得る。

【0043】

パーサ３２０は、シンボル３２１を生み出すよう、バッファ３１５から受け取った映像シーケンスにエントロピー復号／構文解析処理を実行し得る。

【0044】

シンボル３２１の再構成には、符号化された映像ピクチャ又はその部分のタイプ及び他の要因（例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロックなど）に応じて、複数の異なるユニットが関与し得る。どのユニットが関与するか、及びそれらがどのように関与するかは、パーサ３２０によって符号化映像シーケンスから構文解析されたサブグループ制御情報によって制御されることができる。パーサ３２０と後述する複数ユニットとの間でのこのようなサブグループ制御情報の流れは、明瞭さのために図示していない。

【0045】

既述の機能ブロックを超えて、デコーダ２１０は概念的に、後述のような多数の機能ユニットに細分化されることができる。商業上の制約の下で稼働する実用的な実装において、これらのユニットのうちの多くが互いに密接にインタラクトし、少なくとも部分的に互いに統合され得る。しかしながら、開示に係る事項を説明するという目的のためには、以下の機能ユニットへの概念的な細分化が適切である。

【0046】

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

【0047】

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

【0048】

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

【0049】

アグリゲータ３５５の出力サンプルは、ループフィルタユニット３５６にて様々なループフィルタリング技術に掛けられ得る。映像圧縮技術は、インループ（in-loop）フィルタ技術を含むことができ、これは、符号化ビデオビットストリームに含められてパーサ３２０からのシンボル３２１としてループフィルタユニット３５６に利用可能にされるパラメータによって制御されるが、符号化ピクチャ又は符号化映像シーケンスのうちの（復号順で）先行部分の復号中に得られたメタ情報にも応答することができるとともに、先行して再構成されてループフィルタリングされたサンプル値にも応答することができる。

【0050】

ループフィルタユニット３５６の出力は、例えばディスプレイ２１２などのレンダリング装置に出力されることが可能なサンプルストリームとすることができ、これはまた、将来のインターピクチャ予測での使用のために参照ピクチャメモリ３５７に格納されることができる。

【0051】

ある特定の符号化ピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用されることができる。ある符号化ピクチャが完全に再構成され、その符号化ピクチャが参照ピクチャとして（例えば、パーサ３２０によって）特定されると、現在ピクチャメモリ３５８に格納されている現在の参照ピクチャが参照ピクチャメモリ３５７の一部となり得るとともに、次の符号化ピクチャの再構成を開始する前に新しい現在ピクチャメモリが再割り当てされ得る。

【0052】

ビデオデコーダ２１０は、例えばＩＴＵ－Ｔ勧告Ｈ．２６５などの標準にて文書化され得る所定の映像圧縮技術に従って復号処理を実行し得る。符号化映像シーケンスは、映像圧縮技術文書又は標準、特にその中のプロファイル文書の中で規定されるように映像圧縮技術又は標準の構文を忠実に守るという意味で、使用される映像圧縮技術又は標準によって規定される構文に従い得る。また、一部の映像圧縮技術又は標準との準拠のために、符号化映像シーケンスの複雑さが、映像圧縮技術又は標準のレベルによって定められる限度内にされ得る。場合により、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒メガサンプルで測定される）、最大参照ピクチャサイズなどを制約する。レベルによって設定される制限は、場合により、仮説的リファレンスデコーダ（Hypothetical Reference Decoder；ＨＲＤ）仕様、及び符号化映像シーケンスにて信号伝達されるＨＲＤバッファ管理用のメタデータを通して更に制約され得る。

【0053】

一実施形態において、受信器３１０は、符号化された映像と共に追加（冗長）データを受信し得る。追加データは、（１つ以上の）符号化映像シーケンスの一部として含められ得る。追加データは、データを適切に復号するため、及び／又は元の映像データをいっそう正確に再構成するために、ビデオデコーダ２１０によって使用され得る。追加データは、例えば、時間的、空間的、又はＳＮＲエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、順方向誤り訂正符号などの形態とし得る。

【0054】

図４は、本開示の一実施形態に従った、映像ソース２０１に結合されるビデオエンコーダ２０３の機能ブロック図の一例を示している。

【0055】

ビデオエンコーダ２０３は、例えば、ソースコーダ４３０であるエンコーダ、符号化エンジン４３２、（ローカル）デコーダ４３３、参照ピクチャメモリ４３４、予測器４３５、送信器４４０、エントロピーエンコーダ４４５、コントローラ４５０、及びチャネル４６０を含み得る。

【0056】

エンコーダ２０３は、エンコーダ２０３によって符号化される（１つ以上の）映像画像をキャプチャし得る映像ソース２０１（エンコーダの一部ではない）から映像サンプルを受信し得る。

【0057】

映像ソース２０１は、エンコーダ２０３によって符号化されるソース映像シーケンスを、任意の好適なビット深さ（例えば、ｘビット、１０ビット、１２ビット、…）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、…）、及び任意の好適なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）のものとし得るデジタル映像サンプルストリームの形態で提供し得る。メディアサービス提供システムにおいて、映像ソース２０１は、事前に準備された映像を格納したストレージ装置とし得る。テレビ会議システムでは、映像ソース２０１は、ローカルな画像情報を映像シーケンスとしてキャプチャするカメラとし得る。映像データは、順に見たときに動きを伝える複数の個々のピクチャとして提供され得る。それらピクチャ自体は、ピクセルの空間アレイとして編成されることができ、各ピクセルが、使用されるサンプリング構造、色空間などに応じて、１つ以上のサンプルを有することができる。当業者は、ピクセルとサンプルとの関係を直ちに理解することができる。以下の説明は、サンプルに焦点を当てている。

【0058】

一実施形態によれば、エンコーダ２０３は、ソース映像シーケンスのピクチャを、リアルタイムで、又はアプリケーションによって要求される他の時間制約下で、符号化映像シーケンス４４３へと符号化及び圧縮し得る。適切な符号化速度を強制することが、コントローラ４５０の１つの機能であるとし得る。コントローラ４５０はまた、後述するような他の機能ユニットを制御し得るとともに、それらのユニットに機能的に結合され得る。その結合は、明瞭さのために図示されていない。コントローラ４５０によって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値、…）、ピクチャサイズ、グループ・オブ・ピクチャ（ＧＯＰ）レイアウト、最大動きベクトル探索範囲などを含み得る。当業者は、特定のシステム設計に合わせて最適化されるビデオエンコーダ２０３に関連し得るものとして、コントローラ４５０の他の機能を直ちに特定することができる。

【0059】

一部のビデオエンコーダは、当業者が“符号化ループ”として直ちに認識するものにて動作する。単純化した説明として、符号化ループは、ソースコーダ４３０（符号化される入力ピクチャ及び（１つ以上の）参照ピクチャに基づいてシンボルを作成することを担う）と、エンコーダ２０３に埋め込まれた（ローカル）デコーダ４３３とで構成されることができ、特定の映像圧縮技術においてシンボルと符号化ビデオビットストリームとの間の圧縮が可逆であるとき、（ローカル）デコーダ４３３は、シンボルを再構成して、（リモート）デコーダも作成し得るものであるサンプルデータを生成する。その再構成されたサンプルストリームが、参照ピクチャメモリ４３４に入力され得る。シンボルストリームの復号は、デコーダ位置（ローカル又はリモート）に依存しないビット正確な結果をもたらすので、参照ピクチャメモリのコンテンツもローカルエンコーダとリモートエンコーダとの間でビット正確である。換言すれば、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに“見る”のとまったく同じサンプル値を参照ピクチャサンプルとして“見る”。この参照ピクチャ同期性の基本原理（及び、例えばチャネルエラーのために、同期性を維持することができない場合に結果として生じるドリフト）は、当業者に知られている。

【0060】

“ローカル”デコーダ４３３の動作は、“リモート”デコーダ２１０のものと実質的に同じであるとすることができ、それは、図３に関連して既に詳細に上述されている。しかし、シンボルが利用可能であり、且つエントロピーコーダ４４５及びパーサ３２０によるシンボルの符号化映像シーケンスへの符号化／復号は可逆であるとし得るので、チャネル３１２、受信器３１０、バッファ３１５、及びパーサ３２０を含むデコーダ２１０のエントロピー復号部分は、ローカルデコーダ４３３に完全に実装されなくてよい。

【0061】

この時点で気付くことができることには、デコーダ内に存在する構文解析／エントロピー復号を除く如何なるデコーダ技術も、対応するエンコーダ内で、実質的に同じ機能的形態で存在する必要がるとし得る。エンコーダ技術の説明は、徹底して説明したデコーダ技術の逆であるとし得るので、省略することができる。特定の分野においてのみ、より詳細な説明が必要とされ、以下に提供される。

【0062】

その動作の一部として、ソースコーダ４３０は、入力フレームを、映像シーケンスからの、“参照フレーム”として指定された１つ以上の先に符号化されたフレームに対して予測的に符号化するものである動き補償予測符号化を実行し得る。斯くして、符号化エンジン４３２は、入力フレームのピクセルブロックと、入力フレームに対する（１つ以上の）予測基準として選択され得る（１つ以上の）参照フレームのピクセルブロックとの間の差分を符号化する。

【0063】

ローカル映像デコーダ４３３は、参照フレームとして指定され得るフレームの符号化映像データを、ソースコーダ４３０によって作成されたシンボルに基づいて復号し得る。符号化エンジン４３２の動作は、有利には、不可逆プロセスとし得る。符号化映像データが映像デコーダ（図４には示されていない）で復号されるとき、再構成された映像シーケンスは典型的に、幾分の誤差を伴うソース映像シーケンスのレプリカであり得る。ローカル映像デコーダ４３３は、参照フレーム上で映像デコーダによって実行され得る復号プロセスを複製し、再構成された参照フレームを参照ピクチャメモリ４３４に格納させるようにし得る。斯くして、エンコーダ２０３は、ファーエンドの映像デコーダによって得られることになる再構成参照フレームと共通のコンテンツを持つ再構成参照フレームのコピーをローカルに格納し得る。

【0064】

予測器４３５は、符号化エンジン４３２のために予測探索を実行し得る。すなわち、符号化すべき新たなフレームに関して、予測器４３５は、新たなピクチャ用の適切な予測基準としての役割を果たし得るサンプルデータ（候補参照ピクセルブロックとして）又は例えば参照ピクチャ動画ベクトルやブロック形状などの特定のメタデータについて、参照ピクチャメモリ４３４を検索し得る。予測器４３５は、適切な予測参照を見出すために、ピクセルブロック毎に動作し得る。場合により、予測器４３５によって得られた検索結果により決定されるように、入力ピクチャは、参照ピクチャメモリ４３４に格納された複数の参照ピクチャから引き出された予測基準を有し得る。

【0065】

コントローラ４５０は、例えば、映像データを符号化するのに使用されるパラメータ及びサブグループパラメータの設定を含め、映像コーダ４３０の符号化処理を管理し得る。

【0066】

前述の全ての機能ユニットの出力が、エントロピーコーダ４４５におけるエントロピー符号化に掛けられ得る。エントロピーコーダは、例えばハフマン符号化、可変長符号化、算術符号化などといった当業者に知られた技術に従ってシンボルを無損失圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化映像シーケンスへと変換する。

【0067】

送信器４４０が、エントロピーコーダ４４５によって生成された符号化映像シーケンスをバッファリングし、それを、通信チャネル４６０を介した伝送のために準備し得る。通信チャネル４６０は、符号化された映像データを格納するストレージ装置へのハードウェア／ソフトウェアリンクとし得る。送信器４４０は、映像コーダ４３０からの符号化映像データを、例えば符号化オーディオデータ及び／又は補助データストリーム（ソースは図示していない）といった、送信される他のデータとマージし得る。

【0068】

コントローラ４５０）は、エンコーダ２０３の動作を管理し得る。符号化において、コントローラ４５０は、各符号化ピクチャに、それぞれのピクチャに適用され得る符号化技術に影響を及ぼし得るものである特定の符号化ピクチャタイプを割り当て得る。例えば、ピクチャはしばしば、イントラピクチャ（Ｉピクチャ）、予測ピクチャ（Ｐピクチャ）、又は双方向予測ピクチャ（Ｂピクチャ）として割り当てられ得る。

【0069】

イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内の他のフレームを使用することなく、符号化コード化及び復号され得るものとし得る。一部の映像コーデックは、例えば独立デコーダリフレッシュ（Independent Decoder Refresh；ＩＤＲ）ピクチャを含め、異なるタイプのイントラピクチャを許している。当業者は、Ｉピクチャのそれら異形、並びにそれらそれぞれの用途及び特徴を知っている。

【0070】

予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために、多くて１つの動きベクトルと参照インデックスとを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものとし得る。

【0071】

双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために、多くて２つの動きベクトルと参照インデックスとを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものとし得る。同様に、多重予測画像は、単一のブロックの再構成のために３つ以上の参照ピクチャと関連メタデータとを使用することができる。

【0072】

ソースピクチャは、一般に、空間的に複数のサンプルブロック（例えば、各々４×４、８×８、４×８、又は１６×１６サンプルのブロック）に細分化され、ブロック毎に符号化され得る。ブロックは、それらブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される他の（既に符号化された）ブロックを参照して予測的に符号化され得る。例えば、Ｉピクチャのブロックは非予測的に符号化されることができ、あるいは、それらは同じピクチャの既に符号化されたブロックを参照して予測的に符号化されることができる（空間予測又はイントラ予測）。Ｐピクチャのピクセルブロックは、非予測的に、あるいは、１つの先に符号化された参照ピクチャを参照して空間予測又は時間予測を介して、符号化されることができる。Ｂピクチャのブロックは、非予測的に、あるいは、１つ又は２つの先に符号化された参照ピクチャを参照して空間予測又は時間予測を介して、符号化されることができる。

【0073】

ビデオエンコーダ２０３は、例えばＩＴＵ－Ｔ勧告Ｈ．２６５などの所定の映像符号化技術又は標準に従って符号化処理を実行し得る。その動作において、ビデオエンコーダ２０３は、入力映像シーケンスにおける時間的及び空間的な冗長性を活用する予測的な符号化処理を含め、様々な圧縮処理を実行し得る。符号化された映像データは、それ故に、使用されている映像符号化技術又は標準によって規定される構文に従い得る。

【0074】

一実施形態において、送信器４４０は、符号化された映像と共に追加データを送信し得る。映像コーダ４３０が、そのようなデータを、符号化映像シーケンスの一部として含め得る。追加データは、時間的／空間的／ＳＮＲエンハンスメントレイヤ、例えば冗長ピクチャ及びスライスなどの他の形態の冗長データ、補足強化情報（ＳＥＩ）メッセージ、ビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメントなどを有し得る。

【0075】

本開示の実施形態によれば、例えば、タイル、タイルグループ、スライス、グループ・オブ・ブロック（ＧＯＢ）など（以下、“タイル”）などのピクチャセグメントを特定する情報が、例えば、ＮＡＬユニットヘッダ、又はＭＡＮＥによる容易な処理に合わせて設計された、固定長のコードワードを有する類似の構造などの、容易にアクセス可能なハイレベル構文構造（以下、“ＮＵＨ”）内に配置され得る。

【0076】

実施形態において、タイルを特定する情報は、複数の異なる形態をとることができる。この情報を設計する際に、幾つかの設計検討を念頭に置くことができる。それら設計検討の一部を以下に挙げる。

【0077】

第１の設計検討に関して、所与のピクチャ内で可能なタイルの数を、例えばレガシー映像符号化技術又は標準において可能なスライスの数と比較して小さくすることができる。例えば、Ｈ．２６４では、（特定のピクチャサイズに対して）単一のマクロブロックをカバーするスライスを持つことが可能であり、存在するマクロブロックと同じ多さのスライスを可能にする。対照的に、タイル化したキューブマップを表現するとき、ピクチャの解像度に関係なく、６つのタイルで十分であり得る。多くの実際のケースで、６４、１２８、又は２５６というタイルの最大数を安全に仮定することができる。

【0078】

第２の設計検討に関して、タイルレイアウトを固定することができ、その一方で、映像符号化技術それ自体はピクチャごとのタイルレイアウトの柔軟性を可能にすることができ、システム標準又は技術は、その柔軟性を、タイルレイアウトがセッションを通して同じままである点に制限することができる。従って、本開示の一部の実施形態において、タイルレイアウトが、例えばセッションセットアップ中などに、非ビデオビットストリーム特有の手段を介してＭＡＮＥに利用可能にされることを可能にすることができる。映像符号化におけるパラメータセットとＭＡＮＥ処理との間の望ましくないコンテキスト依存性を禁止することができる。

【0079】

本開示の実施形態は、上述の第１及び第２の設計検討を実装し得る。第１及び第２の設計検討を実装する本開示の実施形態に関して、ＮＡＬユニットによって運ばれるタイルを特定し、そうして、ＮＡＬユニットがＭＡＮＥによって除去されることを可能にするメカニズムが、例えばＨ．２６４及びＨ．２６５などの関連技術と比較して大幅に簡略化され得る。

【0080】

例えば、Ｈ．２６４及びＨ．２６５では、ＭＡＮＥは、スライスヘッダ内のスライス／タイルアドレスコードワードの長さについて知るために、正しいシーケンスパラメータセットを特定しなければならない。そのような長さ情報はシーケンスパラメータセット内に可変長コードワードとして符号化され、従って、最低限、ＭＡＮＥは、パラメータセットの起動シーケンスを辿って現在アクティブなシーケンスパラメータセットを特定し、そして、（パラメータセットは構文解析に依存しないので、場合によりこの順序ではなく）可変長コードワードを復号して、スライスヘッダにて運ばれたバイナリ符号化スライス／タイルアドレスの長さを特定する必要がある。次いで、ＭＡＮＥは、開始マクロブロック／ＣＵアドレスを得るために、スライスヘッダ内の（１つ以上の）可変長コードワードを復号する必要がある。その情報が、タイルを特定するために、パラメータセットから復号されたタイルレイアウトとマッチングされ得る。

【0081】

本開示の一部の実施形態において、タイルに関する特定情報は、タイルの最初のマクロブロック／ＣＵのアドレスとすることができる。事実上、このようなメカニズムは、開始アドレスをスライスヘッダからＮＵＨに移動させることになる。そうすることは、コーデック設計に対する最小変更アプローチであり得るが、ＮＵＨをかなり大きいものにし得る。しかしながら、ＮＵＨのサイズの増加は、符号化効率の観点からさえ許容可能であることがある。何故なら、同量のビットがスライス／タイルヘッダから除去され得るからである。

【0082】

上述のように、マクロブロック／ＣＵアドレスは、小さいピクチャサイズ及び大きいマクロブロック／ＣＵサイズでは合理的に小さくなることができ、小さいＣＵサイズ及び大きいピクチャサイズではかなり大きくなり得る。この理由から、Ｈ．２６５のＳＰＳは、スライスヘッダ内で運ばれるマクロブロック／ＣＵアドレスの長さを指し示すインジケーションを含んでいる。

【0083】

本開示の実施形態では、ＮＡＬユニットヘッダに対して、マクロブロック／ＣＵアドレスの長さを指し示すメカニズムを保持することができる。しかしながら、そうすることは２つの欠点を有し得る。第一に、パラメータセット値を通してＮＡＬユニットヘッダ内の構文要素のサイズを決定することによって設立されるコンテキスト依存性は、ＭＡＮＥがパラメータセットのアクティブ化を追跡することを必要とし得るものであり、それは面倒であり得る。第二に、ＮＡＬユニットヘッダは、少なくともこれまで、ＭＡＮＥにおける処理を簡単にするためにアライメントされるオクテットである。そのオクテットアライメントを維持することは、パラメータセットによって信号伝達されるマクロブロック／ＣＵアドレスのサイズが、残りのＮＡＬユニットヘッダ構文要素と足し合わさって、８で割り切れるビット数にならない場合に、パディングを必要とし、それによりビットを浪費し得る。

【0084】

本開示の実施形態（上述の実施形態を含む）においては、マクロブロック／ＣＵアドレス又はＮＡＬユニットヘッダ内の他の構文要素のサイズを、ＮＡＬユニットヘッダ内の他のフィールドによって割り出すことができる。このメカニズムは有利なことに、パラメータセットとＮＡＬユニットヘッダとの間のコンテキスト依存性を回避する。１つの潜在的な欠点は、ＮＡＬユニットヘッダの他のフィールドにおけるビット又はコードポイントの使用である。

【0085】

しかしながら、伝統的な意味でのスライスを考慮せず、タイル若しくはタイルグループ、又はビットストリームエンティティへのＣＵの類似の割り当てメカニズムのみを考慮するとき、更に後述するように、本開示の実施形態において、より進んだオプションを実装することができる。

【0086】

それらの実施形態の一部を説明するために、用語“スライス”及び“タイル”を簡単に見直しておく。

【0087】

スライスは、通常はスキャン順での、ＣＵ又はマクロブロックの集合であり、スライスヘッダ内で符号化され得るものである開始マクロブロック／ＣＵアドレスと、新たなスライスの開始（代わって、これは、次のスライスヘッダの存在を通じて指し示され得る）によって特定され得るものであるスライスの終わりと、の２つのファクタによって特定され得る。ある特定のビデオ圧縮技術及び標準はスライスの数及びレイアウトに一定の比較的小さい制約を課すが、大抵の場合、スライスレイアウトは、符号化ピクチャごとに変わることができ、例えばレート制御及びＭＴＵサイズマッチングなどのメカニズムによって決定されることが多い。

【0088】

一方、タイルは、典型的にＣＵの矩形配置を指し、矩形（及び、一緒になってピクチャを構成する他の矩形）のサイズ及び形状がパラメータセット内に符号化される。換言すれば、タイルレイアウトは、１つのタイルレイアウトから別のタイルレイアウトへの変化が、異なるパラメータセットのアクティブ化を必要とし得るという点で、いくぶん静的であり得る。また、効率的なハードウェア実装を可能にするために、タイルの数は有利に制約されることができる。その結果、多くの映像圧縮技術及び標準において、例えば８ビットという、比較的短い固定長バイナリコードワードが、実用的に使用される全てのピクチャサイズに対してタイルの最大数をアドレス指定することを可能にする。従って、タイルＩＤのための固定長コードワードを使用して、ＮＡＬユニットヘッダ内のタイルを特定することができ、それにより、タイル特定用のＮＡＬユニットヘッダコードワードとパラメータセットとの間の構文解析依存性及びコンテキスト依存性が回避される。あるいは、そう望まれる場合には、ＮＡＬユニットヘッダ内のマクロブロック／ＣＵアドレス用の可変長コードワードをサポートするメカニズムを、同様のアーキテクチャ上の欠点という犠牲の下で、タイルＩＤコードワードに等しく適用してもよい。

【0089】

図６Ａ－６Ｄを参照するに、本開示の実施形態のＮＡＬユニットヘッダ設計の例が示されている。

【0090】

図６Ａに示すように、符号化ビデオビットストリームの一部であるＮＡＬユニット６０１が提供され得る。符号化ビデオビットストリームは、複数のＮＡＬユニット６０１を含み得る。一部のケースで、ＮＡＬユニット６０１は、オクテットアライメントされ、データネットワークの共通の最大転送ユニット（ＭＴＵ）サイズ以下にされ得る。１つのそのような共通のＭＴＵサイズは１５００オクテットであり、これは初期のイーサネット（登録商標）技術の一定の限界に由来するものである。ＮＡＬユニット６０１は、ＮＡＬユニット６０１の先頭にＮＡＬユニットヘッダ６０２を含み得る。符号化ビデオビットストリームの中での、（１つ以上の）ＮＡＬユニットを含むＮＡＬユニットのフレーム化は、開始コードを通じて、基礎となるパケット指向輸送ネットワークのパケット構造とのアライメントを通じて、などとすることができる。

【0091】

図６Ｂを参照するに、本開示のＮＡＬユニット６０１についてのＮＡＬユニットヘッダ６０３の一例の構文図が示されており、これは、図５Ｂに示したＨ．２６５で使用されるＮＡＬユニットヘッダに対していくらかの類似点を共有している。本開示の実施形態は、それに代えて、あるいは加えて、例えばＨ．２６４又はＶＶＣのＮＡＬユニットヘッダなどに対していくらかの類似点を共有する構造を持つＮＡＬユニットヘッダを実装してもよい。

【0092】

ＮＡＬユニットヘッダ６０３に、ＣＵアドレス又はタイルＩＤの構文要素６０４を含めることができる。実施形態において、その構文要素６０４の長さは、固定とすることができるとともに、ＮＡＬユニットヘッダ６０３がオクテットアライメントされ続けるように選択されることができる。実施形態において、構文要素６０４は、ビデオエンコーダ及びデコーダによってだけでなくＭＡＮＥによっても容易に処理可能なフォーマットにすることができる。実施形態において、非限定的な一例として、ＣＵアドレス又はタイルＩＤを含む構文要素６０４は、記述子ｕ（６）によって表されるように、６ビットの符号なし整数によって表され得る。この非限定的な例において、ＣＵアドレス又はタイルＩＤ用の構文要素６０４は、layer_id用にＨ．２６５で使用されるのと同じビットを占有する。

【0093】

図６Ｃは、ＮＡＬユニット６０１で実装され得る本開示のＮＡＬユニットヘッダ６０５を例示している。ＮＡＬユニットヘッダ６０５は、ＮＡＬユニットヘッダ６０３と類似点を共有するが、図６Ｃでは異なる提示形式で示されている。図６Ｃに示すように、ＮＡＬユニットヘッダ６０５は、ＣＵアドレス又はタイルＩＤ用の構文要素６０６を含み得る。

【0094】

図６Ｄは、Ｈ．２６５ＮＡＬユニットヘッダのフィールドを保存するものであるＮＡＬユニットヘッダ６０７を例示している。非限定的な実施形態例において、構文要素６０８は、例えば、ＮＡＬユニットヘッダ６０７の末尾に追加され得る。非限定的な実施形態例において、構文要素６０８は代わりに、ＮＡＬユニットヘッダ６０７の他の構文要素の中間のどこかに挿入されてもよい。構文要素６０８は、固定の又は可変のサイズのものとすることができ、可変サイズのものである場合、そのサイズは、上述のメカニズムのいずれか（例えば、パラメータセット構文要素を通じて又はＮＡＬユニットタイプを通じて）、又は任意の他の適切なメカニズムによって決定されることができる。

【0095】

以下、図７を参照して、本開示の実施形態のタイル及びタイルグループ分割設計の非限定的な構造例を説明する。実施形態において、複数のピクチャ７００を含む符号化ビデオストリームがエンコーダから本開示のデコーダ及びＭＡＮＥに送られ得る。各ピクチャ７００が、１つ以上のタイル７３０を含み得る。図７に示すように、非限定的な一例として、ピクチャ７００は６３個のタイル（Tile）を持つように示されている。タイル７３０の数、サイズ、及び形状は、図７によって限定されず、任意の数、サイズ、及び形状とし得る。例えば、タイル７３０は矩形であってもよいし矩形でなくてもよい。これらのタイル７３０は、１つ以上のタイルグループ７１０へと分割され得る。図７に示すように、非限定的な一例として、ピクチャ７００は、各タイルグループ７１０が複数のタイル７３０を含む５つのタイルグループを持つように示されている。タイルグループ７１０の数、サイズ、及び形状は、図７によって限定されず、任意の数、サイズ、及び形状とすることができる。例えば、タイル７３０は矩形であってもよいし矩形でなくてもよい。

【0096】

本開示の実施形態は、その中にタイルグループ７１０及びタイル７３０が画成されて分割されるビデオストリームを復号及び符号化し得る。

【0097】

例えば、図８を参照するに、本開示のデコーダ及びＭＡＮＥは、ビデオストリームを復号するプロセス８００を実行し得る。

【0098】

図８に示すように、デコーダ又はＭＡＮＥは、１つ以上の識別子を受信し得る（８０１）。該１つ以上の識別子は、エンコーダによってデコーダ又はＭＡＮＥに送られるビデオストリーム内で提供されることができ、あるいは、エンコーダ又は他の装置によってビデオストリーム外で代わりの手段によって提供されてもよい。該１つ以上の識別子は、タイルグループ７１０及びタイル７３０の特徴をデコーダ又はＭＡＮＥに明示的に信号伝達することができ、それに代えて、あるいは加えて、タイルグループ７１０及びタイル７３０の特徴を暗示的に信号伝達してもよい。該１つ以上の識別子は、例えば、フラグ又は他の要素とし得る。

【0099】

（１つ以上の）識別子を受信したことに続いて、デコーダ又はＭＡＮＥは、識別子に基づいて、１つ以上のタイルグループ７１０及びタイル７３０の１つ以上の特徴を特定し得る（８０２）。タイルグループ７１０の特徴を特定した後、デコーダ又はＭＡＮＥは、特定した特徴を用いて、適宜に、タイルグループ７１０を再構築し、タイルグループ７１０を転送し、又はタイルグループ７１０をビデオストリームから除去し得る。例えば、プロセス８００がデコーダによって実行される場合、デコーダは適宜に、そのようなタイルグループ７１０及びそのタイル７３０を再構築し（例えば、そのタイル７３０を担持するＮＡＬユニットを再構築し）、又はそのタイルグループ７１０及びそのタイル７３０を廃棄し得る。プロセス８００がＭＡＮＥによって実行される場合、ＭＡＮＥは適宜に、そのタイルグループ７１０及びそのタイル７３０を転送し、又はそのタイルグループ７１０及びそのタイル７３０を廃棄し得る。

【0100】

図９に示すように、本開示のシステム８１０は、コンピュータプログラムコードを格納するメモリ８１１と、符号化ビデオストリームを受信し、コンピュータプログラムコードにアクセスし、コンピュータプログラムコードによって命令されるように動作するように構成された少なくとも１つのプロセッサ８１２とを含み得る。コンピュータプログラムコードは、図８に示したステップ８０２を少なくとも１つのプロセッサ８１２に実行させるように構成された特定コード８２２を含み得るとともに、図８に示したステップ８０３を少なくとも１つのプロセッサ８１２に実行させるように構成された実行コード８２４を更に含み得る。

【0101】

以下、本開示のデコーダ及びＭＡＮＥによって受信され得る識別子の一部と、識別子に基づいて特定され得るタイルグループ７１０及びタイル７３０の態様との例を説明する。

【0102】

一部の実施形態において、タイルグループ７１０が矩形のサブピクチャであるか否かをフラグが指し示し得る。実施形態において、エンコーダが、該フラグを、符号化ビデオストリーム内で、本開示のデコーダ又はＭＡＮＥに送信し、該デコーダ又はＭＡＮＥが、該フラグに基づいて、タイルグループ７１０が矩形サブピクチャであるか否かを割り出し得る。あるいは、該フラグは、符号化ビデオストリーム外で他の手段によって送られてもよい。

【0103】

それに代えて、あるいは加えて、一部の実施形態において、本開示のデコーダ、ＭＡＮＥ、及びエンコーダは、ピクチャ７００が単一のタイルグループ７１０のみを含むのか、それとも複数のタイルグループ７１０を含むのか、を指し示すフラグを信号伝達することを含んだ、タイルグループ構造を信号伝達する方法を実行し得る。一例として、該フラグは、エンコーダによってデコーダ又はＭＡＮＥに信号伝達され得る。あるいは、該フラグは、符号化ビデオストリーム外で他の手段によって送られてもよい。該フラグは、パラメータセット（例えば、ピクチャパラメータセット）内に存在し得る。ピクチャ７００が単一のタイルグループ７１０のみを含む場合、タイルグループ７１０は矩形形状を持ち得る。ピクチャ７００が複数のタイルグループ７１０を含む場合、各タイルグループ７１０は、矩形の形状又は非矩形の形状を持ち得る。

【0104】

それに代えて、あるいは加えて、一部の実施形態において、本開示のデコーダ、ＭＡＮＥ、及びエンコーダは、現在ピクチャ７００に属する各タイルグループ７１０が矩形形状を持ち得るか否かを指し示すフラグを信号伝達することを含んだ、タイルグループ構造を信号伝達する方法を実行し得る。該フラグの値が１に等しい場合、現在ピクチャ７００に属する全てのタイルグループ７１０が矩形形状を有つとし得る。一例として、該フラグは、エンコーダによってデコーダ又はＭＡＮＥに信号伝達され得る。あるいは、該フラグは、符号化ビデオストリーム外で他の手段によって送られてもよい。該フラグは、パラメータセット（例えば、ピクチャパラメータセット）内に存在し得る。

【0105】

それに代えて、あるいは加えて、一部の実施形態において、ピクチャが１つ以上の矩形タイルグループ７１０を含むとき、本開示のエンコーダは、デコーダ又はＭＡＮＥに、ピクチャ７００を分割するタイルグループ列の数を示す構文要素と、ピクチャ７００を分割するタイルグループ行の数を示す構文要素とを提供し得る。この場合、各矩形タイルグループ７１０が一様な空間を持つことができ、該構文要素は、エンコーダによってデコーダ又はＭＡＮＥに送信されるパラメータセット（例えば、ピクチャパラメータセット）内に存在し得る。あるいは、該構文要素は、符号化ビデオストリーム外で他の手段によってデコーダ又はＭＡＮＥに送られてもよい。

【0106】

それに代えて、あるいは加えて、実施形態において、ピクチャ７００が１つ以上の矩形タイルグループ７１０を含むとき、本開示のエンコーダは、ピクチャ７００内のタイルグループ７１０の数を示す構文要素をデコーダ又はＭＡＮＥに提供し得る。エンコーダはまた、デコーダ又はＭＡＮＥに、対応するタイルグループ７１０の左上隅を指し示すインデックスを示す構文要素と、対応するタイルグループ７１０の右下隅を指し示すインデックスを示す構文要素とを提供し得る。これらの構文要素は、エンコーダによってデコーダ又はＭＡＮＥに送信されるパラメータセット（例えば、ピクチャパラメータセット）内に存在し得る。あるいは、これらの構文要素は、符号化ビデオストリーム外で他の手段によってデコーダ又はＭＡＮＥに送られてもよい。

【0107】

それに代えて、あるいは加えて、実施形態において、各タイルグループ７１０についてタイルグループＩＤが信号伝達され得る。タイルグループＩＤは、各タイルグループ７１０を識別するために使用され得る。タイルグループＩＤの明示的な信号伝達が存在するか否かを、フラグがパラメータセット（例えば、ピクチャパラメータセット）内で指し示し得る。パラメータセットは、エンコーダによってデコーダ又はＭＡＮＥに送信され得る。タイルグループＩＤが明示的に信号伝達されることを該フラグが指し示す場合、タイルグループＩＤの長さも信号伝達され得る。各タイルグループ７１０に対して、特定のタイルグループＩＤが割り当てられ得る。同一ピクチャ７００内で各タイルグループＩＤは同じ値を持たないとし得る。実施形態において、該フラグ、タイルグループＩＤ、及びタイルグループＩＤの長さは、エンコーダによって、本開示のデコーダ又はＭＡＮＥに信号伝達され得る。

【0108】

それに代えて、あるいは加えて、実施形態において、２つの異なるタイルグループ７１０がタイル７３０のうち１つ以上を共有してもよい。２つの異なるタイルグループ７１０が重なり合って同じタイル７３０を含み得るか否かを指し示すフラグがパラメータセット内に設けられ得る。重なり合いが許されることを該フラグが指し示す場合、タイルグループ７１０のうちの１つ以上に同一タイル７３０が存在し得る。実施形態において、該フラグを含むパラメータセットは、エンコーダによって本開示のデコーダ又はＭＡＮＥに送信され得る。

【0109】

それに代えて、あるいは加えて、実施形態において、ピクチャ７００が複数の矩形又は非矩形のタイルグループ７１０を含む場合、各タイルグループ７１０についてのタイル７３０の数が、パラメータセット内又はタイルグループヘッダ内で信号伝達され得る。そして、ラスタースキャン順にタイルの数をカウントすることによって、各タイルグループ７１０の左上及び右下の位置が推定され得る。実施形態において、パラメータセット及びタイルグループヘッダ、並びにその中の信号は、エンコーダによって本開示のデコーダ又はＭＡＮＥに送信されることができ、デコーダ又はＭＡＮＥがこの推定を実行し得る。

【0110】

それに代えて、あるいは加えて、実施形態において、各タイルグループ７１０は、動き制約タイルセットであることができ、あるいは、各タイルグループ７１０は、複数の動き制約タイルを含むことができる。タイルグループ７１０が動き制約タイルセット又は複数の動き制約タイルを有するかをフラグが指し示し得る。実施形態において、該フラグは、エンコーダによって本開示のデコーダ又はＭＡＮＥに送信されることができ、デコーダ又はＭＡＮＥは、該フラグに基づいて、タイルグループ７１０が動き制約タイルセット又は複数の動き制約タイルを有するかを割り出すことができる。あるいは、該フラグは、符号化ビデオストリーム外で他の手段によってデコーダ又はＭＡＮＥに送られてもよい。

【0111】

それに代えて、あるいは加えて、実施形態において、タイルグループ７１０に属するタイル７３０はラスタースキャン順とし得る。タイルグループ７１０のアドレスは、増加していく順序とし得る。従って、（ｎ＋１）番目のタイルグループ７１０の左上のインデックスは、ｎ番目のタイルグループ７１０の左上のインデックスよりも大きいとし得る。実施形態において、タイルグループ７１０のアドレスは、エンコーダによって本開示のデコーダ又はＭＡＮＥに送信され得る。あるいは、該アドレスは、符号化ビデオストリーム外で他の手段によってデコーダ又はＭＡＮＥに送られてもよい。

【0112】

それに代えて、あるいは加えて、実施形態において、タイルグループ７１０がデコーダによって復号されるときに、各タイル７３０が持つ左境界及び上境界の全体がピクチャ境界又は先行して復号されたタイル７３０からなるように、ピクチャ７００内のタイルグループ７１０の形状が、エンコーダによって設定され、デコーダによって割り出され得る。

【0113】

実施形態において、エンコーダは、既存のＮＡＬユニットヘッダ（又はタイルグループヘッダ）構文を書き込むのと同様にして、タイルグループＩＤをカバーする構文要素を含むようにＮＡＬユニットヘッダ（又はタイルグループヘッダ）を書き込むことができ、これは当業者によって理解されることである。

【0114】

実施形態において、デコーダ又はＭＡＮＥは、タイルグループＩＤ又は他の形態のタイル特定情報を運ぶ構文要素の有無にかかわらず、当業者によって理解されるようにして、符号化ビデオビットストリームから、ＮＡＬユニットヘッダ（より正確には、ＮＡＬユニットヘッダ（又はタイルグループヘッダ）を構成する構文要素）を構文解析し得る。しかしながら、留意すべきことには、構文要素は、上述の一部のケースにおいて、状態情報を必要とせずに、例えば固定長のバイナリコードといったアクセス可能なエントロピー符号化フォーマットで符号化される。

【0115】

本開示の一部の実施形態によれば、それにもかかわらず、デコーダ又はＭＡＮＥは、開示に係る事項が存在しない場合に必要とされる処理と比較して少ない労力で、符号化されたピクチャ７００内のタイルグループ７１０を特定することができる。

【0116】

以下、そのような利益の一例を、図１０を参照して説明する。図１０は、それぞれのタイルグループＩＤ １乃至８を有する第１乃至第８のタイルグループ８４１乃至８４８を含んだ、村内の街路のピクチャ８４０を示している。このような例において、ピクチャ８４０は、監視カメラによってキャプチャされると仮定される。

【0117】

場合により、デコーダ又はＭＡＮＥは、外部の非映像符号化手段によって、ピクチャ８４０の特定のタイルグループが特定のアプリケーションのために再構成される必要がないことを通知され得る。例えば、図１０に示すように、タイルグループ８４２は、ほとんど壁に広がっている。従って、監視システムの設定者は、その領域を監視にとって意味がないと考え得る。従って、監視カメラはタイルグループ８４１－８４８の全てを符号化し得るが、ＩＤ ２を有するタイルグループ８４２はアプリケーションに必要ないとされ得る。これに関し、監視カメラによって作成されたビットストリームが１つ以上のＭＡＮＥを介してその最終的な宛先に送られるとした場合、タイルグループ８４２は、ＭＡＮＥのうちの１つ以上によって除去されることができる。

【0118】

本開示の実施形態の開示に係る事項がないと、タイルグループ８４２の除去は、最低限、ＮＡＬユニット（スライス又はタイル）のペイロードが、タイル内の最初のマクロブロックのマクロブロック／ＣＵアドレスを抽出するために、必要な範囲まで構文解析されることを要することになる。使用される映像符号化技術又は標準に応じて、また、上述のように、これは、可変長コードワードの処理と、ＭＡＮＥにおけるパラメータセットコンテキストの保持との両方を必要とし得る。これらはどちらも、実装及び計算の複雑さの観点から望ましくないものである。

【0119】

対照的に、本開示の実施形態において、ＭＡＮＥは、バイナリ符号化されたコードワードのＮＡＬユニットヘッダ処理を通じて、ＮＡＬユニットによってどのタイルが運ばれているのかを特定するのに必要な全ての情報を得ることができる。従って、本開示の実施形態は、関連技術の問題を回避しながら、タイルグループ又はハイレベル構文構造における他のピクチャセグメントを特定する容易に特定可能且つ構文解析可能な構文要素を提供することもできる。

【0120】

図１１を参照するに、デコーダ又はＭＡＮＥは、後述するプロセス８５０を実行することによって、本開示の実施形態を実施することができる。

【0121】

デコーダ又はＭＡＮＥは、ビデオビットストリームから、マクロブロック／ＣＵアドレス又はタイルグループＩＤをカバーする構文要素を含むＮＡＬユニットヘッダを構文解析し得る（８５１）。その情報を用いて、デコーダ又はＭＡＮＥはタイルグループＩＤを特定することができる（８５２）。タイルグループＩＤは、直接符号化されてもよいし、あるいは、デコーダ／ＭＡＮＥが、例えばパラメータセットを復号し且つ起動シーケンスを辿ることによって確立される、タイルレイアウトに関する先験的情報を、ＮＡＬユニットヘッダ内に符号化されたマクロブロック／ＣＵアドレスとマッチングしてもよい。デコーダ又はＭＡＮＥは、タイルＩＤを、それぞれデコーダ又はＭＡＮＥによる再構成又は転送を要するタイルのリストと比較することができる（８５３）。一致が存在する場合、タイルを運ぶＮＡＬユニットを、デコーダが再構築する又はＭＡＮＥが転送することができる（８５４）。一方、一致が存在しない場合、デコーダ又はＭＡＮＥはそのＮＡＬユニットを破棄することができる（８５５）。一実施形態において、デコーダ又はＭＡＮＥは、そのＮＡＬユニットを黙って破棄する。

【0122】

本開示の実施形態において、少なくとも１つのプロセッサが、本開示のタイルグループ及びタイル分割設計に従ってピクチャを符号化し、１つ以上の符号化されたタイルグループ及びタイルを含む符号化ビデオビットストリームを、本開示のタイルグループ及びタイル分割設計に従った復号のために１つ以上のデコーダ及びＭＡＮＥに送信し得る。

【0123】

上述のタイル及びタイルグループ特定を含む符号化及び復号のための技術は、１つ以上のコンピュータ読み取り可能媒体に物理的に格納された、コンピュータ読み取り可能命令を用いたコンピュータソフトウェアとして、実装されることができる。例えば、図１２は、開示に係る事項の実施形態を実装するのに好適なコンピュータシステム９００を示している。

【0124】

上述の技術は、１つ以上のコンピュータ読み取り可能媒体に物理的に格納された、コンピュータ読み取り可能命令を用いたコンピュータソフトウェアとして、実装されることができる。例えば、図１２は、開示の特定の実施形態を実装するのに好適なコンピュータシステム９００を示している。

【0125】

コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、又は同様の機構に掛けられることで、直接的に又はインタープリット、マイクロコード実行及びこれらに類するものを介してコンピュータ中央演算処理ユニット（ＣＰＵ）、グラフィックス処理ユニット（ＧＰＵ）、及びこれらに類するものによって実行されることが可能な命令を有するコードを作り出し得るような、任意の好適な機械コード又はコンピュータ言語を用いてコード化され得る。

【0126】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット装置、及びこれらに類するものを含め、様々なタイプのコンピュータ又はそのコンポーネント上で実行され得る。

【0127】

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

【0128】

コンピュータシステム９００は、特定のヒューマンインタフェース入力装置を含んでもよい。そのようなヒューマンインタフェース入力装置は、例えば、触覚入力（例えば、キーストローク、スワイプ、データグローブを動かすことなど）、オーディオ入力（例えば、音声、拍手など）、視覚入力（例えば、ジェスチャなど）、嗅覚入力（図示せず）を介した、一人以上の人間ユーザによる入力に応答し得る。ヒューマンインタフェース装置はまた、例えばオーディオ（例えば、会話、音楽、周囲の音など）、画像（例えば、走査画像、静止画カメラから得られる写真画像など）、映像（例えば、２次元映像、立体視映像を含む３次元映像など）などの、人間による意識的な入力には必ずしも直接関係しない特定の媒体を捕捉するために使用されてもよい。

【0129】

入力ヒューマンインタフェース装置は、キーボード９０１、マウス９０２、トラックパッド９０３、タッチスクリーン９１０、データグローブ、ジョイスティック９０５、マイクロフォン９０６、スキャナ９０７、カメラ９０８（各々１つのみ図示している）のうちの１つ以上を含み得る。

【0130】

コンピュータシステム９００はまた、特定のヒューマンインタフェース出力装置を含み得る。そのようなヒューマンインタフェース出力装置は、例えば、触覚出力、音、光、及び臭い／味を通して、一人以上の人間ユーザの感覚を刺激し得る。そのようなヒューマンインタフェース出力装置は、触覚出力装置（例えば、タッチスクリーン９１０、データグローブ、又はジョイスティック９０５による触覚フィードバックであるが、入力装置として機能しない触覚フィードバック装置もあってもよい）を含み得る。例えば、そのような装置は、オーディオ出力装置（例えば、スピーカー９０９、ヘッドフォン（図示せず）など）、視覚出力装置（例えば、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン９１０（各々がタッチスクリーン入力機能を有する又は有さない。各々が触覚フィードバック機能を有する又は有さない。これらの一部は、二次元の視覚出力、又は例えば立体視出力などの手段を通じて四次元以上の出力を出力することができるとし得る。）、仮想現実グラス（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）など）、及びプリンタ（図示せず）であってもよい。

【0131】

コンピュータシステム９００はまた、例えば、ＣＤ／ＤＶＤ若しくは類似の媒体９２１を有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ９２０を含む光媒体、サムドライブ９２２、取り外し可能なハードドライブ若しくは又はソリッドステートドライブ９２３、例えばテープ及びフロッピーディスク（登録商標、図示せず）などのレガシー磁気媒体、例えばセキュリティドングルなどの特殊化されたＲＯＭ／ＡＳＩＣ／ＰＬＤベースの装置（図示せず）、及びこれらに類するものなどの、人間アクセス可能なストレージ装置及びそれらの関連媒体を含み得る。

【0132】

当業者がこれまた理解するはずのことには、ここでの開示に係る事項に関連して使用される用語“コンピュータ読み取り可能媒体”は、伝送媒体、搬送波、又は他の一時的な信号を含まない。

【0133】

コンピュータシステム９００はまた、１つ以上の通信ネットワークへのインタフェースを含み得る。ネットワークは、例えば、無線、有線、光とし得る。ネットワークは更に、ローカル、広域、大都市、車両及び産業、リアルタイム、耐遅延などとし得る。ネットワークの例は、例えばイーサネット（登録商標）などのローカルエリアネットワークや、無線ＬＡＮや、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥ及びこれらに類するものを含むセルラネットワークや、ケーブルＴＶ、衛星ＴＶ、及び地上波放送ＴＶを含むＴＶ有線又は無線広域デジタルネットワークや、ＣＡＮＢｕｓを含む車両及び産業などを含む。特定のネットワークは一般に、特定の汎用データポート又はペリフェラルバス９４９（例えば、コンピュータシステム９００のＵＳＢポートなど）に取り付けられる外付けネットワークインタフェースアダプタを必要とし、他のものは一般に、後述のシステムバスへの取り付けによってコンピュータシステム９００のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネットインタフェース、又はスマートフォンコンピュータシステムへのセルラネットワークインタフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム９００は、他のエンティティと通信することができる。そのような通信は、単方向の受信のみ（例えば、放送ＴＶ）であってもよいし、単方向の送信のみ（例えば、特定のＣＡＮｂｕｓ装置に対するＣＡＮｂｕｓ）であってもよいし、あるいは、例えばローカル又は広域デジタルネットワークを用いた他のコンピュータシステムに対しての、双方向であってもよい。そのような通信は、クラウドコンピューティング環境９５５への通信を含むことができる。特定のプロトコル及びプロトコルスタックが、上述のようにネットワーク及びネットワークインタフェースの各々上で使用され得る。

【0134】

前述のヒューマンインタフェース装置、人間アクセス可能なストレージ装置、及びネットワークインタフェース９５４は、コンピュータシステム９００のコア９４０に取り付けられることができる。

【0135】

コア９４０は、１つ以上の中央演算処理ユニット（ＣＰＵ）９４１、グラフィックス処理ユニット（ＧＰＵ）９４２、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）９４３の形態の特殊なプログラム可能なプロセッシングユニット、特定のタスク用のハードウェアアクセラレータ９４４などを含み得る。これらのデバイスは、読み出し専用メモリ（ＲＯＭ）９４５、ランダムアクセスメモリ９４６、例えば内部のユーザアクセス可能でないハードドライブ、ＳＳＤなどの内部大容量ストレージ９４７、及びこれらに類するもの９４７と共に、システムバス９４８を介して接続され得る。一部のコンピュータシステムにおいて、システムバス９４８は、追加のＣＰＵ、ＧＰＵ、及びこれらに類するものによる拡張を可能にするために、１つ以上の物理プラグの形態でアクセス可能にされ得る。周辺装置は、コアのシステムバス９４８に直接的に、又はペリフェラルバス９４９を介して、のいずれで取り付けられてもよい。ペリフェラルバスのアーキテクチャは、ＰＣＩ、ＵＳＢ、及びこれらに類するものを含む。グラフィックスアダプタ９５０がコア９４０に含められてもよい。

【0136】

ＣＰＵ９４１、ＧＰＵ９４２、ＦＰＧＡ９４３、及びアクセラレータ９４４は、組み合わさって前述のコンピュータコードを構成することができる特定の命令を実行し得る。そのコンピュータコードは、ＲＯＭ９４５又はＲＡＭ９４６に格納され得る。ＲＡＭ９４６には過渡的なデータも格納されることができ、永久的なデータは、例えば内部大容量ストレージ９４７に格納されることができる。メモリデバイスのいずれかへの高速な記憶及び取り出しが、１つ以上のＣＰＵ９４１、ＧＰＵ９４２、大容量ストレージ９４７、ＲＯＭ９４５、ＲＡＭ９４６、及びこれらに類するものの近くに付随し得るキャッシュメモリの使用によって可能にされ得る。

【0137】

コンピュータ読み取り可能媒体はその上に、様々なコンピュータ実装処理を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的に合わせて特別に設計及び構築されたものであってもよいし、あるいは、それらは、コンピュータソフトウェア技術の当業者にとって周知且つ利用可能な種類のものであってもよい。

【0138】

一例として、限定ではなく、アーキテクチャ９００、特にコア９４０、を有するコンピュータシステムは、１つ以上の有形のコンピュータ読み取り可能媒体に具現化されたソフトウェアを（１つ以上の）プロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ、及びこれらに類するものを含む）が実行することの結果として機能を提供することができる。そのようなコンピュータ読み取り可能媒体は、例えばコア内部の大容量ストレージ９４７又はＲＯＭ９４５などの、非一時的性質のものであるコア９４０の特定のストレージ、及び上で紹介したようなユーザアクセス可能な大容量ストレージに関連する媒体とすることができる。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に格納され、コア９４０によって実行されることができる。コンピュータ読み取り可能媒体は、具体的なニーズに従って、１つ以上のメモリデバイス又はチップを含み得る。ソフトウェアは、コア９４０及び特にその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、及びこれらに類するものを含む）に、ＲＡＭ９４６に格納されるデータ構造を規定すること、及びそのようなデータ構造を、ソフトウェアによって規定されたプロセスに従って変更することを含めて、ここに記載された特定のプロセスを又は特定のプロセスの特定の部分を実行させることができる。加えて、又は代替として、コンピュータシステムは、ここに記載された特定のプロセスを又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はソフトウェアと共に動作することができる回路（例えば、アクセラレータ９４４）にて配線された又はその他の方法で具体化されたロジックの結果として、機能を提供してもよい。ソフトウェアへの言及はロジックを含み、また、適当な場合にその逆もまた然りである。コンピュータ読み取り可能媒体への言及は、実行のためのソフトウェアを格納した回路（例えば、集積回路（ＩＣ）など）、実行のためのロジックを具体化した回路、又は適当な場合にこれら双方を含み得る。本開示は、ハードウェア及びソフトウェアの好適な組み合わせを含む。

【0139】

この開示は幾つかの非限定的な実施形態を記述しているが、開示の範囲に入る変更、置換、及び様々な均等な代替が存在する。従って、理解されることには、当業者は、ここでは明示的に図示されたり説明されたりしていないものの、開示の原理を具体化し、それ故に、その精神及び範囲の中にあるような、数多くのシステム及び方法を考案することができるであろう。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6A】

【図6B】

【図6C】

【図6D】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【国際調査報告】