特許 7577786 ビデオエンコーダ、ビデオデコーダ及び対応する方法

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

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

(11)【特許番号】

(24)【登録日】2024-10-25

(45)【発行日】2024-11-05

(54)【発明の名称】ビデオエンコーダ、ビデオデコーダ及び対応する方法

(51)【国際特許分類】

   H04N 19/70 20140101AFI20241028BHJP

【ＦＩ】

H04N19/70

【請求項の数】 20

【外国語出願】

(21)【出願番号】P 2023075906

(22)【出願日】2023-05-02

(62)【分割の表示】P 2021538323の分割

【原出願日】2019-12-31

(65)【公開番号】P2023095946

(43)【公開日】2023-07-06

【審査請求日】2023-05-18

(31)【優先権主張番号】62/787,110

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

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

(31)【優先権主張番号】62/883,537

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

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

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ヘンドリー，フヌ

(72)【発明者】

【氏名】ワン，イェ‐クイ

【審査官】田中 純一

(56)【参考文献】

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

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

【文献】Jill Boyce, Adarsh Ramasubramanian, Robert Skupin, Gary J. Sullivan, Alexis Tourapis, Ye-Kui Wang，HEVC Additional Supplemental Enhancement Information (Draft 4) [online]， JCTVC-AC JCTVC-AC1005-v2，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/29_Macau/wg11/JCTVC-AC1005-v2.zip＞＜JCTVC-AC1005-v2.docx＞，2017年10月25日，pp.1-43

【文献】R. Skupin, Y. Sanchez，MCTS extraction with optional slice reordering [online]， JCTVC-AB JCTVC-AB0028，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/28_Torino/wg11/JCTVC-AB0028-v1.zip＞＜JCTVC-AB0028.doc＞，2017年07月05日，pp.1-4

【文献】Sachin Deshpande，On Motion-Constrained Tile Sets Extraction Information Set SEI [online]， JCTVC-Z JCTVC-Z0037，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/26_Geneva/wg11/JCTVC-Z0037-v1.zip＞＜JCTVC-Z0037-MCTS.doc＞，2017年01月06日，pp.1-5

【文献】Hyun-Mook Oh, Soojin Hwang, Sejin Oh，MCTS extraction with implicit slice reordering [online]， JCTVC-AC JCTVC-AC0033，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/29_Macau/wg11/JCTVC-AC0033-v1.zip＞＜JCTVC-AC0033.docx＞，2017年10月11日，pp.1-3

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

Ｈ０４Ｎ ７／１２

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

(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】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、第１スライスのスライスアドレスを決定することが、プロセッサによって、スライスヘッダからスライスアドレスを解釈するためのビット境界を決定するようパラメータセットから長さを用いることと、プロセッサによって、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするよう識別子及びスライスアドレスを用いることとを有する、ことを提供する。

【0007】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、プロセッサによって、識別子（ＩＤ）フラグを得るようパラメータセットをパースすることを更に有し、ＩＤフラグが、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするためにマッピングが利用可能であることを示す、ことを提供する。

【0008】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、ピクチャに基づいた位置とサブピクチャに基づいた位置との間のマッピングが、スライスヘッダが書き直される必要なしに、スライスヘッダをサブピクチャにアライメントする、ことを提供する。

【0009】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、スライスアドレスが、定義された値を有し、インデックスを有さない、ことを提供する。

【0010】

実施形態において、本開示は、エンコーダで実施される方法であって、エンコーダのプロセッサによって、ピクチャをビットストリームの中にエンコーディングすることであり、ピクチャは、第１スライスを含む複数のスライスを有する、ことと、プロセッサによって、ビットストリームの中に、第１スライスのスライスアドレスを含むスライスヘッダをエンコーディングすることと、プロセッサによって、ビットストリームの中に、第１スライスの識別子及びスライスアドレスの長さを含むパラメータセットをエンコーディングすることと、プロセッサによって、スライスヘッダを書き直さずに、第１スライスのスライスアドレスと、スライスアドレスの長さと、識別子とに基づいて第１スライスを抽出することによって、ビットストリームのサブビットストリームを抽出することと、エンコーダのメモリに、デコーダへの通信のためにサブビットストリームを記憶することとを有する方法を含む。いくつかのビデオコーディングシステムで、スライス（タイルグループとしても知られる）は、インデックスの組に基づいてアドレッシングされ得る。そのようなインデックスは、ピクチャの左上隅でインデックスゼロから始まり、ピクチャの右下隅でインデックスＮで終わるラスタスキャン順序において増えてよく、ここで、Ｎは、１を引いたインデックスの数である。そのようなシステムは、ほとんどのアプリケーションに対して上手く働く。しかし、仮想現実（ＶＲ）などの特定のアプリケーションは、ピクチャのサブピクチャしかレンダリングしない。サブビットストリームが、レンダリングされるべきサブピクチャを含む場合に、いくつかのシステムは、ビットストリームのサブビットストリームしかデコーダへ伝送しないことによって、ＶＲコンテンツをストリーミングするときのコーディング効率を向上させ得る。そのような場合に、インデックスに基づいたアドレッシングスキームは、デコーダによって受信されるサブピクチャの左上隅が一般的にゼロ以外の何らかのインデックスであるために、正確に動作しなくなる可能性がある。そのような懸念に対処するために、エンコーダ（又は関連したスライサ）は、左上のインデックスがゼロから始まり、残りのサブピクチャスライスがそれに応じて調整されるように、サブピクチャのインデックスを変更するよう各スライスヘッダを書き直すことを求められることがある。スライスヘッダを（例えば、ユーザ要求ごとに）動的に書き直すことは、プロセッサ負荷が非常に大きいことがある。開示されているシステムは、スライスヘッダが書き直される必要なしに、サブピクチャを含むサブビットストリームを抽出することを可能にするアドレッシングスキームを採用する。各スライスは、インデックス以外の識別子（ＩＤ）（例えば、サブピクチャＩＤ）に基づいてアドレッシングされる。このようにして、デコーダは、どのサブピクチャが受信されるかにかかわらず、かつ、完全なピクチャの左上隅に対する受信されたサブピクチャの位置にかかわらず、全ての関係アドレスを一貫して決定することができる。ＩＤが適宜定義される（例えば、エンコーダによって選択される）ということで、ＩＤは、可変長フィールドの中にエンコーディングされる。従って、スライスアドレスの長さもシグナリングされる。サブピクチャに関連したＩＤもシグナリングされる。長さは、スライスアドレスを解釈するために用いられ、サブピクチャＩＤは、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするために用いられる。これらのメカニズムを採用することによって、エンコーダ、デコーダ、及び／又は関連するスライスは、改善され得る。例えば、サブビットストリームが、ビットストリーム全体の代わりに抽出され伝送されてよく、これは、ネットワーク資源、メモリ資源、及び／又はプロセッシング資源の利用を減らす。更に、そのようなサブビットストリームの抽出は、ユーザ要求ごとに各スライスヘッダを書き直さずに実行可能であり、これは、ネットワーク資源、メモリ資源、及び／又はプロセッシング資源の利用を更に減らす。

【0011】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、識別子がサブピクチャと関連付けられる、ことを提供する。

【0012】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、スライスアドレスの長さが、スライスアドレスに含まれているビットの数を示す、ことを提供する。

【0013】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、パラメータセット内の長さが、スライスヘッダからスライスアドレスを解釈するのに十分なデータを含み、識別子が、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするのに十分なデータを含む、ことを提供する。

【0014】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、プロセッサによって、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするためにマッピングが利用可能であることを示す識別子（ＩＤ）フラグをパラメータセットの中にエンコーディングすることを更に有する、ことを提供する。

【0015】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、スライスアドレスが、定義された値を有し、インデックスを有さない、ことを提供する。

【0016】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、ビットストリームのサブビットストリームを抽出することが、ピクチャのサブピクチャを抽出することを含み、サブピクチャが第１スライスを含み、サブビットストリームが、サブピクチャと、スライスヘッダと、パラメータセットとを有する、ことを提供する。

【0017】

実施形態において、本開示は、プロセッサと、メモリと、プロセッサへ結合されている受信器と、プロセッサへ結合されている送信器とを有し、プロセッサ、メモリ、受信器、及び送信器が、上記の態様のいずれかの方法を実行するよう構成される、ビデオコーディングデバイスを含む。

【0018】

実施形態において、本開示は、ビデオコーディングデバイスによって使用されるコンピュータプログラム製品を有する非一時的なコンピュータ可読媒体であって、コンピュータプログラム製品が、プロセッサによって実行される場合に、ビデオコーディングデバイスに、上記の態様のいずれかの方法を実行させるように、非一時的なコンピュータ可読媒体に記憶されているコンピュータ実行可能命令を有する、非一時的なコンピュータ可読媒体を含む。

【0019】

実施形態において、本開示は、第１スライスを含む複数のスライスにパーティション化されたピクチャのサブピクチャと、ピクチャ及びサブピクチャに関連したパラメータセットと、第１スライスに関連したスライスヘッダとを含むサブビットストリームを受信する受信手段と、第１スライスの識別子及びスライスアドレスの長さを得るようパラメータセットをパースするパージング手段と、識別子及びスライスアドレスの長さに基づいてスライスヘッダから第１スライスのスライスアドレスを決定する決定手段と、第１スライスを含むサブピクチャのビデオシーケンスを生成するようサブビットストリームをデコーディングするデコーディング手段と、表示のためにサブピクチャのビデオシーケンスを転送する転送手段とを有するデコーダを含む。

【0020】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、デコーダが、上記の態様のいずれかの方法を実行するよう更に構成される、ことを提供する。

【0021】

実施形態において、本開示は、ピクチャをビットストリームの中にエンコーディングし、ピクチャは、第１スライスを含む複数のスライスを有し、ビットストリームの中に、第１スライスのスライスアドレスを含むスライスヘッダをエンコーディングし、ビットストリームの中に、第１スライスの識別子及びスライスアドレスの長さを含むパラメータセットをエンコーディングするエンコーディング手段と、スライスヘッダを書き直さずに、第１スライスのスライスアドレスと、スライスアドレスの長さと、識別子とに基づいて第１スライスを抽出することによって、ビットストリームのサブビットストリームを抽出する抽出手段と、デコーダへの通信のためにサブビットストリームを記憶する記憶手段とを有するエンコーダを含む。

【0022】

任意に、上記の態様のいずれかにおいて、態様の他の実施は、エンコーダが、上記の態様のいずれかの方法を実行するよう更に構成される、ことを提供する。

【0023】

明りょうさのために、上記の実施形態のいずれか１つは、本開示の範囲内で新しい実施形態をもたらすよう、他の上記の実施形態のいずれか１つ以上と組み合わされてよい。

【0024】

これら及び他の特徴は、添付の図面及び特許請求の範囲と併せて読まれる以下の詳細な説明から、より明りょうに理解されるだろう。

【0025】

本開示のより完全な理解のために、これより、添付の図面及び詳細な説明と併せて読まれる、次の簡単な説明が参照される。同じ参照番号は同じ部分を表す。

【図面の簡単な説明】

【0026】

【図1】ビデオ信号をコーディングする方法の例のフローチャートである。

【図2】ビデオコーディングのためのコーディング及びデコーディング（コーデック）システムの例の概略図である。

【図3】ビデオエンコーダの例を表す概略図である。

【図4】ビデオデコーダの例を表す概略図である。

【図5】ビットストリームから抽出されたサブビットストリームの例を表す概略図である。

【図6】コーディングのためにパーティション化されたピクチャの例を表す概略図である。

【図7】ピクチャから抽出されたサブピクチャの例を表す概略図である。

【図8】例となるビデオコーディングデバイスの概略図である。

【図9】明示的アドレスシグナリングを採用することによって、スライスヘッダを書き直さずに、サブピクチャのサブビットストリームの抽出を支援するようピクチャのビットストリームをエンコーディングする方法の例のフローチャートである。

【図10】明示的アドレスシグナリングを採用することによってサブピクチャのサブビットストリームをデコーディングする方法の例のフローチャートである。

【図11】明示的アドレスシグナリングを採用することによってサブピクチャのサブビットストリームを伝送するシステムの例の概略図である。

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

【0027】

１つ以上の実施形態の例示的な実施が以下で与えられるが、開示されるシステム及び／又は方法は、現在知られているか又は存在しているかどうかに関わらず、任意の数の技術を用いて実施されてよい、ことがまず理解されるべきである。開示は、ここで図示及び記載されている例となる設計及び実施を含む、以下で説明される例示的な実施、図面、及び技術に決して限定されるべきではなく、添付の特許請求の範囲及びその均等の全範囲内で変更されてもよい。

【0028】

coding tree block（ＣＴＢ）、coding tree unit（ＣＴＵ）、coding unit（ＣＵ）、coded video sequence（ＣＶＳ）、Joint Video Experts Team（ＪＶＥＴ）、motion constrained tile set（ＭＣＴＳ）、maximum transfer unit（ＭＴＵ）、network abstraction layer（ＮＡＬ）、picture order count（ＰＯＣ）、raw byte sequence payload（ＲＢＳＰ）、sequence parameter set（ＳＰＳ）、versatile video coding（ＶＶＣ）、及びworking draft（ＷＤ）などの様々な頭字語が、ここでは用いられている。

【0029】

多くのビデオ圧縮技術は、最小限のデータ損失でビデオファイルのサイズを低減するために用いられ得る。例えば、ビデオ圧縮技術は、ビデオシーケンス内のデータ冗長性を低減又は排除するよう空間（例えば、イントラピクチャ）予測及び／又は時間（例えば、インターピクチャ）予測を実行することを含むことができる。ブロックベースのビデオコーディングについては、ビデオスライス（例えば、ビデオピクチャ又はビデオピクチャの部分）は、ツリーブロック、コーディングツリーブロック（ＣＴＢ）、コーディングツリーユニット（ＣＴＵ）、コーディングユニット（ＣＵ）、及び／又はコーディングノードとも呼ばれ得るビデオブロックにパーティション化されてよい。ピクチャのイントラコーディング（Ｉ）されたスライス内のビデオブロックは、同じピクチャ内の隣接ブロック内の参照サンプルに関して空間予測を用いてコーディングされる。ピクチャのインターコーディングされた一方向予測（Ｐ）又は双方向予測（Ｂ）スライス内のビデオブロックは、同じピクチャ内の隣接ブロック内の参照ピクチャに関して空間予測を、又は他の参照ピクチャ内の参照サンプルに関して時間予測を用いることによって、コーディングされてよい。ピクチャは、フレーム及び／又は画像と呼ばれることがあり、参照ピクチャは、参照フレーム及び／又は参照画像と呼ばれることがある。空間又は時間予測は、画像ブロックを表す予測ブロックをもたらす。残差データは、原画像ブロックと予測ブロックとの間のピクセル差分を表す。従って、インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトルと、コーディングされたブロックと予測ブロックとの間の差分を示す残差データとに従って、エンコーディングされる。イントラコーディングされたブロックは、イントラコーディングモード及び残差データに従ってエンコーディングされる。更なる圧縮のために、残差データは、ピクセル領域から変換領域へ変換されてよい。これらは残差変換係数をもたらし、これは量子化されてよい。量子化された変換係数は、最初に２次元配列で配置されてよい。量子化された変換係数は、変換係数の１次元ベクトルを生成するためにスキャンされてよい。エントロピコーディングが、より一層の圧縮を達成するよう適用されてもよい。このようなビデオ圧縮技術については、以下で更に詳細に説明される。

【0030】

エンコーディングされたビデオが正確にデコーディングされ得ることを確かにするために、ビデオは、対応するビデオコーディング規格に従ってエンコーディング及びデコーディングされる。ビデオコーディング規格は、国際電気通信連合（ＩＴＵ）標準化部門（ＩＴＵ－Ｔ）Ｈ．２６１、国際標準化機構／国際電気標準会議（ＩＳＯ／ＩＥＣ）動画専門家集団（ＭＰＥＧ）－１ Ｐａｒｔ ２、ＩＴＵ－Ｔ Ｈ．２６２又はＩＳＯ／ＩＥＣ ＭＰＥＧ－２ Ｐａｒｔ２、ＩＴＵ－Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ Ｐａｒｔ ２、ＩＴＵ－Ｔ Ｈ．２６４又はＩＳＯ／ＩＥＣ ＭＰＥＧ－４ Ｐａｒｔ １０としても知られているアドバンスド・ビデオ・コーディング（ＡＶＣ）、及びＩＴＵ－Ｔ Ｈ．２６５又はＭＰＥＧ－Ｈ Ｐａｒｔ ２としても知られている高効率ビデオコーディング（ＨＥＶＣ）を含む。ＡＶＣは、スケーラブル・ビデオ・コーディング（ＳＶＣ）、マルチビュー・ビデオ・コーディング（ＭＶＣ）及びマルチビュー・ビデオ・コーディング・プラス・デプス（ＭＶＣ＋Ｄ）、並びに３次元（３Ｄ）ＡＶＣ（３Ｄ－ＡＶＣ）などの拡張を含む。ＨＥＶＣは、スケーラブルＨＥＶＣ（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ－ＨＥＶＣ）、及び３Ｄ ＨＥＶＣ（３Ｄ－ＨＥＶＣ）などの拡張を含む。ＩＴＵ－ＴとＩＳＯ／ＩＥＣとの共同ビデオ専門家部会（ＪＶＥＴ）は、バーサタイル・ビデオ・コーディング（ＶＶＣ）と呼ばれるビデオコーディング規格を開発することを開始している。ＶＶＣは、ＪＶＥＴ－Ｌ１００１を含むワーキング・ドラフト（ＷＤ）に含まれている。

【0031】

ビデオ画像をコーディングするために、画像は最初にパーティション化され、パーティションがビットストリーム内にコーディングされる。様々なピクチャパーティション化スキームが利用可能である。例えば、画像は、規則的なスライス、従属的なスライス、タイルへと、及び／又は波面並列処理（ＷＰＰ）に従ってパーティション化され得る。簡単のために、ＨＥＶＣは、規則的なスライス、従属的なスライス、タイル、ＷＰＰ、及びこれらの組み合わせしか、ビデオコーディングのためのＣＴＢのグループにスライスをパーティション化するときに使用され得ないように、エンコーダを制限する。このようなパーティション化は、最大変換ユニット（ＭＴＵ）サイズの一致、並列処理、及び低減されたエンド間遅延をサポートするよう適用され得る。ＭＴＵは、単一パケットで伝送され得るデータの最大量を表す。パケットペイロードがＭＴＵを超える場合に、そのペイロードは、断片化と呼ばれるプロセスを通じて２つのパケットに分裂される。

【0032】

単にスライスとも呼ばれる規則的なスライスは、ループフィルタリング動作によるいくらかの相互依存性にも関わらず、同じピクチャ内の他の規則的なスライスから独立して再構成され得る画像のパーティション化された部分である。夫々の規則的なスライスは、伝送のためにそれ自体のネットワーク抽象化レイヤ（ＮＡＬ）ユニットにおいてカプセル化される。更に、ピクチャ内予測（イントラサンプル予測、動き情報予測、コーディングモード予測）及びスライス境界にわたるエントロピコーディング依存性は、独立した再構成をサポートするよう無効にされてよい。このような独立した再構成は並列化をサポートする。例えば、規則的なスライスに基づく並列化は、最低限のプロセッサ間又はコア間通信を用いる。しかし、夫々の規則的なスライスは独立しているということで、各スライスは別個のスライスヘッダと関連付けられる。規則的なスライスの使用は、各スライスのためのスライスヘッダのビットコストにより、且つ、スライス境界にわたる予測の欠如により、相当なコーディングオーバーヘッドを招く可能性がある。更に、規則的なスライスは、ＭＴＵサイズの一致の要件をサポートするために用いられることがある。具体的には、規則的なスライスは別個のＮＡＬユニットにおいてカプセル化され、独立してコーディングされ得るということで、夫々の規則的なスライスは、そのスライスを複数のパケットに分けることを回避するために、ＭＴＵスキームにおけるＭＴＵよりも小さくなければならない。そのようなものとして、並列化の目標及びＭＴＵサイズの一致の目標は、矛盾した要求をピクチャ内のスライスレイアウトに突きつける可能性がある。

【0033】

従属的なスライスは、規則的なスライスと類似しているが、短くされたスライスヘッダを有し、ピクチャ内予測を中断せずに画像ツリーブロック境界のパーティション化を可能にする。従って、従属的なスライスは、規則的なスライスが複数のＮＡＬユニットに断片化されることを可能にし、これは、規則的なスライス全体のエンコーディングが完了する前に規則的なスライスの一部が送出されることを可能にすることによって、低減されたエンド間遅延をもたらす。

【0034】

タイルは、タイルの列及び行を作る水平及び垂直境界によって作られた画像のパーティション化された部分である。タイルは、ラスタスキャン順序（右から左及び上から下）でコーディングされてよい。ＣＴＢのスキャン順序はタイル内で局所的である。従って、第１タイル内のＣＴＢは、次のタイル内のＣＴＢに対する処理の前に、ラスタスキャン順序でコーディングされる。規則的なスライスと同様に、タイルは、エントロピデコーディング従属性に加えてピクチャ内予測従属性も崩す。しかし、タイルは、個々のＮＡＬユニットに含まれなくてもよく、従って、タイルは、ＭＴＵサイズの一致のために使用されなくてもよい。各タイルは、１つのプロセッサ／コアによって処理可能であり、隣接するタイルをデコーディングする処理ユニット間でピクチャ内予測のために用いられるプロセッサ間／コア間通信は、（隣接するタイルが同じスライス内にある場合に）共有スライスヘッダを運ぶことと、再構成されたサンプル及びメタデータのループフィルタリングに関連した共有を実行することとに制限されてよい。１つよりも多いタイルがスライスに含まれる場合に、スライス内の最初のエントリポイントオフセット以外の各タイルのためのエントリポイントバイトオフセットは、スライスヘッダでシグナリングされてよい。夫々のスライス及びタイルについて、次の条件：１）スライス内の全てのコーディングされたツリーブロックは同じタイルに属すること、及び２）タイル内の全てのコーディングされたツリーブロックは同じスライスに属すること、のうちの少なくとも１つが満たされるべきである。

【0035】

ＷＰＰでは、画像は、ＣＴＢの単一の行にパーティション化される。エントロピデコーディング及び予測メカニズムは、他の行内のＣＴＢからのデータを使用してよい。並列処理は、ＣＴＢ行の並列デコーディングを通じて可能にされる。例えば、現在の行は、先行する行と並行してデコーディングされてよい。しかし、現在の行のデコーディングは、２つのＣＴＢだけ、先行する行のデコーディングプロセスから遅延する。この遅延は、現在の行内の現在のＣＴＢの上のＣＴＢ及び右上のＣＴＢに関するデータが、現在のＣＴＢがコーディングされる前に利用可能であることを確かにする。このアプローチは、グラフィカルに表現される場合に波面として現れる。この時差スタートは、画像に含まれるＣＴＢ行と同じ数以下のプロセッサ／コアによる並列化を可能にする。ピクチャ内の隣接するツリーブロック行間のピクチャ内予測が許可されるので、ピクチャ内予測を可能にするためのプロセッサ間／コア間通信はかなりの量になる可能性がある。ＷＰＰパーティション化はＮＡＬユニットサイズを考慮しない。従って、ＷＰＰは、ＭＴＵサイズ一致をサポートしない。しかし、規則的なスライスは、望まれるようにＭＴＵサイズ一致を実装するために、特定のコーディングオーバーヘッドを伴って、ＷＰＰとともに使用され得る。

【0036】

タイルはまた、動きを制約されたタイルセットを含んでもよい。動きを制約されたタイルセット（motion constrained tile set，ＭＣＴＳ）は、関連した動きベクトルが、ＭＣＴＳ内の完全サンプル位置と、補間のためにＭＣＴＳ内の完全サンプル位置しか必要としない分数サンプル位置とを指し示すよう制限されるように設計されたタイルセットである。更に、ＭＣＴＳの外にあるブロックから導出された時間動きベクトル予測のための動きベクトル候補の利用は、認められない。このようにして、各ＭＣＴＳは、ＭＣＴＳに含まれていないタイルの存在なしで、独立してデコーディングされ得る。時間ＭＣＴＳ捕足エンハンスメント情報（supplemental enhancement information，ＳＥＩ）メッセージが、ビットストリーム内のＭＣＴＳの存在を示し、ＭＣＴＳをシグナリングするために、使用されてもよい。ＭＣＴＳ ＳＥＩメッセージは、ＭＣＴＳセットのための適合ビットストリームを生成するためにＭＣＴＳサブビットストリーム抽出（ＳＥＩメッセージのセマンティクスの部分として指定される）において使用され得る補足情報を提供する。情報は、夫々が多数のＭＣＴＳセットを定義し、かつ、ＭＣＴＳサブビットストリーム抽出プロセス中に使用される置換ビデオパラメータセット（video parameter set，ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、及びピクチャパラメータセット（ＰＰＳ）のローバイトシーケンスペイロード（raw bytes sequence payload，ＲＢＳＰ）バイトを含む多数の抽出情報セットを含む。ＭＣＴＳサブビットストリーム抽出プロセスに従ってサブビットストリームを抽出するとき、パラメータセット（ＶＰＳ、ＳＰＳ、及びＰＰＳ）は、書き直されるか又は置換されてよく、スライスヘッダは、スライスアドレスに関連したシンタックス要素（ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｉｎ＿ｐｉｃ＿ｆｌａｇ及びｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ａｄｄｒｅｓｓを含む）の１つ又は全てが、抽出されたサブビットストリーム内の異なる値を用い得るので、更新されてよい。

【0037】

上記のスキームは、ある問題を含むことがある。いくつかのシステムで、ピクチャに１つよりも多いタイル／スライスがあるとき、タイルグループのアドレスは、ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓなどのシンタックス要素を使用することによってタイルグループヘッダでインデックスとしてシグナリングされてよい。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓは、タイルグループ内の最初のタイルのタイルアドレスを特定する。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの長さは、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＴｉｌｅｓＩｎＰｉｃ））ビットと決定されてよく、ＮｕｍＴｉｌｅｓＩｎＰｉｃは、ピクチャ内のタイルの数を含む。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値は、ゼロ以上ＮｕｍＴｉｌｅｓＩｎＰｉｃ－１以下の範囲内にあってよく、ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値は、同じコーディングされたピクチャのいずれかの他のコーディングされたタイルグループＮＡＬユニットのｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値と等しくなくてもよい。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓは、ビットストリームに存在しないときは、ゼロであると推測され得る。上述されたタイルアドレスは、タイルインデックスを含む。しかし、タイルグループごとにアドレスとしてタイルインデックスを使用することは、いくらかのコーディング効率の悪さを招くことがある。

【0038】

例えば、ある使用ケースは、ビットストリームをデコーダへ渡す直前にクライアント側で、あるいは、何らかのネットワークベースのメディア処理エンティティで、エンコーディングとデコーディングとの間でＡＶＣ又はＨＥＶＣスライスセグメントヘッダの変更を必要とすることがある。そのような使用ケースの一例は、タイル化ストリーミングである。タイルストリーミングでは、パノラマビデオがＨＥＶＣタイルを用いてエンコーディングされるが、デコーダはこれらのタイルの一部しかデコーディングしない。ＳＰＳ／ＰＰＳとともにＨＥＶＣスライスセグメントヘッダ（slice segment header，ＳＳＨ）を書き直すことによって、ビットストリームは、デコーディングされるタイルのサブセット及びデコーディングされたビデオフレーム内のそれらの空間配置を変更するために、操作され得る。このＣＰＵ処理コストの１つの理由は、ＡＶＣ及びＨＥＶＣスライスセグメントヘッダが可変長フィールドを使用し、最後にバイトアライメントフィールドを有するという事実である。このことは、ＳＳＨ内のあるフィールドがいつ変更されようとも、このことがＳＳＨの終わりにあるバイトアライメントフィールドに影響を及ぼす可能性があり、それもその場合に書き直されることを意味する。そして、全てのフィールドが可変長でエンコーディングされるので、バイトアライメントフィールドの位置を知る唯一の方法は、先行する全てのフィールドをパースすることである。このことは、特に、タイルが使用され、１秒に相当するビデオが数百のＮＡＬを含む可能性がある場合に、相当な処理オーバーヘッドを招く。いくつかのシステムは、明示的にタイル識別子（ＩＤ）をシグナリングすることをサポートする。しかし、いくつかのシンタックス要素は、最適化されないことがあり、シグナリング時に不必要な及び／又は冗長なビットを含む可能性がある。更に、明示的なタイルＩＤシグナリングに関連付けられているいくつかの制約は特定されない。

【0039】

例えば、上記のメカニズムは、ピクチャがパーティション化及び圧縮されることを可能にする。例えば、ピクチャは、スライス、タイル、及び／又はタイルグループにパーティション化され得る。いくつかの例において、タイルグループは、スライスと同義的に使用されてよい。そのようなスライス及び／又はタイルグループは、インデックスの組に基づいてアドレッシングされてよい。そのようなインデックスは、ピクチャの左上隅でインデックスゼロから始まり、ピクチャの右下隅でインデックスＮで終わるラスタスキャン順序において増えてよい。この場合に、Ｎは、１を引いたインデックスの数である。そのようなシステムは、ほとんどのアプリケーションに対して上手く働く。しかし、仮想現実（ＶＲ）などの特定のアプリケーションは、ピクチャのサブピクチャしかレンダリングしない。そのようなサブピクチャは、いくつかの状況で関心領域と呼ばれることがある。サブビットストリームが、レンダリングされるべきサブピクチャを含む場合に、いくつかのシステムは、ビットストリームのサブビットストリームしかデコーダへ伝送しないことによって、ＶＲコンテンツをストリーミングするときのコーディング効率を向上させ得る。そのような場合に、インデックスに基づいたアドレッシングスキームは、デコーダによって受信されるサブピクチャの左上隅が一般的にゼロ以外の何らかのインデックスであるために、正確に動作しなくなる可能性がある。そのような懸念に対処するために、エンコーダ（又は関連したスライサ）は、左上のインデックスがゼロから始まり、残りのサブピクチャスライスがそれに応じて調整されるように、サブピクチャのインデックスを変更するよう各スライスヘッダを書き直すことを求められることがある。スライスヘッダを（例えば、ユーザ要求ごとに）動的に書き直すことは、プロセッサ負荷が非常に大きいことがある。

【0040】

ここでは、ピクチャを含むエンコーディングされたビットストリームからサブピクチャを含むサブビットストリームを抽出するときに、コーディング効率を向上させかつ処理オーバーヘッドを減らすための様々なメカニズムが、開示されている。開示されているシステムは、スライスヘッダが書き直される必要なしに、サブピクチャを含むサブビットストリームを抽出することを可能にするアドレッシングスキームを採用する。各スライス／タイルグループは、インデックス以外のＩＤに基づいてアドレッシングされる。例えば、スライスは、インデックスにマッピングされてスライスヘッダに格納され得る値によって、アドレッシングされ得る。このことは、デコーダが、スライスヘッダからスライスアドレスを読み出し、アドレスを、ピクチャに基づいた位置からサブピクチャに基づいた位置へマッピングすることを可能にする。スライスアドレスが予め定義されたインデックスではないということで、スライスアドレスは、可変長フィールドの中にエンコーディングされる。従って、スライスアドレスの長さもシグナリングされる。サブピクチャに関連したＩＤもシグナリングされる。サブピクチャＩＤ及び長さは、ＰＰＳでシグナリングされてよい。フラグも、明示的アドレッシングスキームが採用されていることを示すために、ＰＰＳでシグナリングされてよい。フラグを読むことで、デコーダは、長さ及びサブピクチャＩＤを取得することができる。長さは、スライスヘッダからスライスアドレスを解釈するために用いられる。サブピクチャＩＤは、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするために用いられる。このようにして、デコーダは、どのサブピクチャが受信されるかにかかわらず、かつ、完全なピクチャの左上隅に対する受信されたサブピクチャの位置にかかわらず、全ての関係アドレスを一貫して決定することができる。更に、このメカニズムは、そのような決定が、スライスアドレス値を変更するようスライスヘッダを書き直さずに、かつ／あるいは、スライスアドレスに関連したバイトアライメントフィールドを変更せずに、行われることを可能にする。上記のメカニズムを採用することによって、エンコーダ、デコーダ、及び／又は関連するスライスは、改善され得る。例えば、サブビットストリームが、ビットストリーム全体の代わりに抽出され伝送されてよく、これは、ネットワーク資源、メモリ資源、及び／又はプロセッシング資源の利用を減らす。更に、そのようなサブビットストリームの抽出は、ユーザ要求ごとに各スライスヘッダを書き直さずに実行可能であり、これは、ネットワーク資源、メモリ資源、及び／又はプロセッシング資源の利用を更に減らす。

【0041】

図１は、ビデオ信号をコーディングする、例となる動作方法１００のフローチャートである。具体的に、ビデオ信号はエンコーダでエンコーディングされる。エンコーディングプロセスは、ビデオファイルサイズを低減するために様々なメカニズムを用いることによってビデオ信号を圧縮する。より小さいファイルサイズは、関連した帯域幅オーバーヘッドを低減しながら、圧縮されたビデオファイルがユーザに向けて伝送されることを可能にする。次いで、デコーダは、圧縮されたビデオファイルをデコーディングして、エンドユーザへの表示のための元のビデオ信号を再構成する。デコーディングプロセスは、一般的に、デコーダが一貫してビデオ信号を再構成することを可能にするよう、エンコーディングプロセスを反映する。

【0042】

ステップ１０１で、ビデオ信号がエンコーダに入力される。例えば、ビデオ信号は、メモリに記憶されている未圧縮ビデオファイルであってよい。他の例として、ビデオファイルは、ビデオカメラなどのビデオ捕捉デバイスによって捕捉され、ビデオのライブストリーミングをサポートするようエンコーディングされてよい。ビデオファイルは、オーディオ成分及びビデオ成分の両方を含んでよい。ビデオ成分は、連続して見られる場合に、動きの視覚的印象を与える一連の画像フレームを含む。フレームは、ここでルーマ成分（又はルーマサンプル）と呼ばれる光と、クロマ成分（又は色サンプル）と呼ばれる色とに関して表現されるピクセルを含む。いくつかの例では、フレームはまた、３次元表示をサポートするためのデプス値も含んでもよい。

【0043】

ステップ１０３で、ビデオはブロックにパーティション化される。パーティション化は、各フレーム内のピクセルを圧縮のために正方形及び／又は長方形ブロックに細分することを含む。例えば、高効率ビデオコーディング（ＨＥＶＣ）（Ｈ．２６５及びＭＰＥＧ－Ｈ Ｐａｒｔ２として知られる）では、フレームは最初に、予め定義されたサイズ（例えば、６４×６４ピクセル）のブロックであるコーディングツリーユニット（ＣＴＵ）に分割され得る。ＣＴＵは、ルーマ及びクロマサンプルの両方を含む。コーディングツリーは、ＣＴＵをブロックに分割し、次いで、更なるエンコーディングをサポートする構成が達成されるまで、ブロックを再帰的に細分するために用いられてよい。例えば、フレームのルーマ成分は、個々のブロックが比較的に一様な明暗値を含むまで細分されてよい。更に、フレームのクロマ成分は、個々のブロックが比較的に一様な色値を含むまで細分されてよい。従って、パーティション化メカニズムは、ビデオフレームの内容に応じて変化する。

【0044】

ステップ１０５で、ステップ１０３でパーティション化された画像ブロックを圧縮するよう様々な圧縮メカニズムが用いられる。例えば、インター予測及び／又はイントラ予測が用いられてよい。インター予測は、共通のシーン内の対象物が連続したフレームで現れる傾向がある、という事実を利用するよう設計される。従って、参照フレーム内の対象物を表すブロックは、隣接するフレームで繰り返し記述される必要がない。具体的に、テーブルなどの対象物は、複数のフレームにわたって定位置のままであることがある。従って、テーブルは一度記述され、隣接するフレームは参照フレームを参照し直すことができる。パターンマッチングメカニズムが、複数のフレームにわたって対象物を照合するために用いられてもよい。更に、動いている対象物が、例えば、対象物の運動又はカメラの運動により、複数のフレームにわたって表現されることがある。具体例として、ビデオは、複数のフレームにわたって画面を横切って動く自動車を示すことがある。動きベクトルは、そのような運動を記述するために用いられ得る。動きベクトルは、あるフレーム内の対象物の座標から参照フレーム内の対象物の座標へのオフセットを提供する２次元ベクトルである。そのようなものとして、インター予測は、現在のフレーム内の画像ブロックを、参照フレーム内の対応するブロックからのオフセットを示す動きベクトルの組としてエンコーディングすることができる。

【0045】

イントラ予測は、共通のフレーム内のブロックをエンコーディングする。イントラ予測は、ルーマ及びクロマ成分がフレーム内で群がる傾向がある、という事実を利用する。例えば、木の一部分にある緑色のパッチは、緑色の同様のパッチに隣接して位置している傾向がある。イントラ予測は、複数の指向性予測モード（例えば、ＨＥＶＣでは３３個）、プレーナーモード、及び直流（ＤＣ）モードを用いる。指向性モードは、現在のブロックが、対応する方向にある隣接ブロックのサンプルと類似している／同じであることを示す。プレーナーモードは、行／列（例えば、平面）に沿った一連のブロックが行の端にある隣接ブロックに基づいて補間され得ることを示す。プレーナーモードは、事実上、変化する値の比較的に一定の傾きを用いることによって、行／列にわたる光／色の滑らかな遷移を示す。ＤＣモードは、境界平滑化のために用いられ、ブロックが、指向性予測モードの角度方向に関連した全ての隣接ブロックのサンプルに関連した平均値と類似している／同じであることを示す。従って、イントラ予測ブロックは、実際の値の代わりに、様々な関連した予測モード値として画像ブロックを表すことができる。更に、インター予測ブロックは、実際の値の代わりに動きベクトルとして画像ブロックを表すことができる。いずれの場合にも、予測ブロックは、いくつかの場合に正確に画像ブロックを表さないことがある。如何なる差分も残差ブロックで保存される。変換は、ファイルを更に圧縮するよう残差ブロックに適用されてよい。

【0046】

ステップ１０７で、様々なフィルタリング技術が適用されてよい。ＨＥＶＣでは、フィルタは、インループフィルタリングスキームに従って適用される。上述されたブロックに基づく予測は、デコーダで、ブロックノイズのある画像の生成を引き起こす可能性がある。更に、ブロックに基づく予測スキームは、ブロックをエンコーディングし、それから、エンコーディングされた画像を参照ブロックとしての後の使用のために再構成してよい。インループフィルタリングスキームは、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ、及びサンプル適応オフセット（ＳＡＯ）フィルタをブロック／フレームに繰り返し適用する。これらのフィルタは、エンコーディングされたファイルが正確に再構成され得るように、そのようなブロッキングアーチファクトを軽減する。更に、これらのフィルタは、アーチファクトが、再構成された参照ブロックに基づいてエンコーディングされるその後のブロックで更なるアーチファクトを引き起こす可能性が低くなるように、再構成された参照ブロックでのアーチファクトを軽減する。

【0047】

ビデオ信号がパーティション化、圧縮、及びフィルタ処理されると、結果として得られるデータは、ステップ１０９で、ビットストリームの中にエンコーディングされる。ビットストリームは、デコーダでの適切なビデオ信号再構成をサポートするために望ましいあらゆるシグナリングデータに加えて、上記のデータも含む。例えば、このようなデータは、パーティションデータ、予測データ、残差ブロック、及びデコーダへコーディング命令を与える様々なフラグを含んでよい。ビットストリームは、要求時のデコーダに向けた伝送のために、メモリに記憶されてよい。ビットストリームはまた、複数のデコーダに向けたブロードキャスト及び／又はマルチキャストであってもよい。ビットストリームの生成は、反復プロセスである。従って、ステップ１０１、１０３、１０５、１０７、及び１０９は、多数のフレーム及びブロックにわたって連続して及び／又は同時に行われてよい。図１に示されている順序は、議論の明りょうさ及び容易さのために提示されており、ビデオコーディングプロセスを特定の順序に限定する意図はない。

【0048】

デコーダは、ビットストリームを受け取り、ステップ１１１でデコーディングプロセスを開始する。具体的に、デコーダは、ビットストリームを対応するシンタックス及びビデオデータに変換するためにエントロピデコーディングスキームを用いる。デコーダは、ステップ１１１でフレームのパーティションを決定するためにビットストリームからのシンタックスデータを用いる。パーティション化は、ステップ１０３でのブロックパーティション化の結果と一致すべきである。ステップ１１１で用いられるエントロピエンコーディング／デコーディングがこれより説明される。エンコーダは、入力画像内の値の空間位置付けに基づいていくつかの可能な選択からブロックパーティション化スキームを選択することといった多くの選択を圧縮プロセス中に行う。正確な選択をシグナリングすることは、多数のビンを用いる可能性がある。ここで使用されるように、ビンは、変数（例えば、状況に応じて変化し得るビット値）として扱われるバイナリ値である。エントロピコーディングは、エンコーダが、許容可能な選択肢の組を残しながら、特定の場合について明らかに実行可能でない如何なる選択肢も捨てることを可能にする。夫々の許容可能な選択肢は、次いで、コードワードを割り当てられる。コードワードの長さは、許容可能な選択肢の数に依存する（例えば、２つの選択肢については１つのビン、３つ乃至４つの選択肢については２つのビン、など）。エンコーダは、次いで、選択された選択肢についてのコードワードをエンコーディングする。このスキームは、コードワードが、全ての可能な選択肢の潜在的に大きい集合からの選択を一意に示すこととは対照的に、許容可能な選択肢の小さい部分集合からの選択を一意に示すために望まれる大きさであるということで、コードワードのサイズを低減する。デコーダは、次いで、エンコーダと同様の方法で、許容可能な選択肢の組を決定することによって選択をデコーディングする。許容可能な選択肢の組を決定することによって、デコーダは、コードワードを読み出し、エンコーダによって行われた選択を決定することができる。

【0049】

ステップ１１３で、デコーダは、ブロックデコーディングを実行する。具体的に、デコーダは、残差ブロックを生成するために逆変換を用いる。次いで、デコーダは、パーティション化に従って画像ブロックを再構成するために残差ブロック及び対応する予測ブロックを用いる。予測ブロックは、ステップ１０５でエンコーダで生成されたイントラ予測ブロック及びインター予測ブロックの両方を含んでよい。再構成された画像ブロックは、次いで、ステップ１１１で決定されたパーティション化データに従って、再構成されたビデオ信号のフレーム内に位置付けられる。ステップ１１３のためのシンタックスも、上述されたように、エントロピコーディングを介してビットストリームでシグナリングされてよい。

【0050】

ステップ１１５で、フィルタリングが、エンコーダでのステップ１０７に類似した方法で、再構成されたビデオ信号のフレームに対して実行される。例えば、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ、及びＳＡＯフィルタが、ブロッキングアーチファクトを除くようフレームに適用されてよい。フレームがフィルタ処理されると、ビデオ信号は、エンドユーザによる視聴のために、ステップ１１７でディスプレイへ出力され得る。

【0051】

図２は、ビデオコーディングのための、例となるコーディング及びデコーディング（コーデック）システム２００の概略図である。具体的に、コーデックシステム２００は、動作方法１００の実施をサポートするための機能性を提供する。コーデックシステム２００は、エンコーダ及びデコーダの両方で用いられるコンポーネントを表すよう一般化されている。コーデックシステム２００は、動作方法１００のステップ１０１及び１０３に関して説明されたように、ビデオ信号を受信しパーティション化し、これにより、パーティション化されたビデオ信号２０１が得られる。コーデックシステム２００は、次いで、方法１００のステップ１０５、１０７、及び１０９に関して説明されたようにエンコーダとして動作する場合には、パーティション化されたビデオ信号２０１を、コーディングされたビットストリームへと圧縮する。デコーダとして動作する場合には、コーデックシステム２００は、動作方法１００のステップ１１１、１１３、１１５、及び１１７に関して説明されたように、ビットストリームから出力ビデオ信号を生成する。コーデックシステム２００は、汎用コーダ制御コンポーネント２１１、変換スケーリング及び量子化コンポーネント２１３、イントラピクチャ推定コンポーネント２１５、イントラピクチャ予測コンポーネント２１７、動き補償コンポーネント２１９、動き推定コンポーネント２２１、スケーリング及び逆変換コンポーネント２２９、フィルタ制御解析コンポーネント２２７、インループフィルタコンポーネント２２５、デコーディングピクチャバッファコンポーネント２２３、並びにヘッダフォーマッティング及びコンテキスト適応バイナリ算術コーディング（context adaptive binary arithmetic coding，ＣＡＢＡＣ）コンポーネント２３１を含む。このようなコンポーネントは、示されているように結合される。図２では、黒線は、エンコーディング／デコーディングされるべきデータの移動を示し、一方、破線は、他のコンポーネントの動作を制御する制御データの移動を示す。エンコーダには、コーデックシステム２００のコンポーネントが全て存在してよい。デコーダは、コーデックシステム２００のコンポーネントのサブセットを含んでよい。例えば、デコーダは、イントラピクチャ予測コンポーネント２１７、動き補償コンポーネント２１９、スケーリング及び逆変換コンポーネント２２９、インループフィルタコンポーネント２２５、及びデコーディングピクチャバッファコンポーネント２２３を含んでよい。これらのコンポーネントがこれより説明される。

【0052】

パーティション化されたビデオ信号２０１は、コーディングツリーによってピクセルのブロックにパーティション化されている捕捉されたビデオシーケンスである。コーディングツリーは、ピクセルのブロックをピクセルのより小さいブロックに細分するために様々な分裂モードを用いる。これらのブロックは、次いで、より小さいブロックに更に細分され得る。ブロックは、コーディングツリー上のノードと呼ばれることがある。より大きい親ノードは、より小さい子ノードに分裂される。ノードが細分される回数は、ノード／コーディングツリーのデプスと呼ばれる。分割されたブロックは、いくつかの場合にコーディングユニット（ＣＵ）に含まれ得る。例えば、ＣＵは、ルーマブロック、赤色差分クロマ（Ｃｒ）ブロック及び青色差分クロマ（Ｃｂ）ブロックを、ＣＵの対応するシンタックス命令とともに含むＣＴＵのサブ部分であることができる。分裂モードは、ノードを、用いられている分裂モードに応じて形状が変化する２つ、３つ、又は４つの子ノードに夫々パーティション化するために用いられる二分木（ＢＴ）、三分木（ＴＴ）、及び四分木（ＱＴ）を含んでよい。パーティション化されたビデオ信号２０１は、汎用コーダ制御コンポーネント２１１、変換スケーリング及び量子化コンポーネント２１３、イントラピクチャ推定コンポーネント２１５、フィルタ制御解析コンポーネント２２７、及び動き推定コンポーネント２２１へ圧縮のために転送される。

【0053】

汎用コーダ制御コンポーネント２１１は、適用制約に従って、ビットストリーム内へのビデオシーケンスの画像のコーディングに関する決定を行うよう構成される。例えば、汎用コーダ制御コンポーネント２１１は、再構成品質に対するビットレート／ビットストリームサイズの最適化を管理する。このような決定は、記憶空間／帯域幅の利用可能性及び画像解像度の要求に基づいて行われてよい。汎用コーダ制御コンポーネント２１１はまた、バッファアンダーラン及びオーバーラン問題を軽減するよう伝送速度に照らしてバッファ利用も管理する。これらの問題を管理するために、汎用コーダ制御コンポーネント２１１は、他のコンポーネントによるパーティション化、予測、及びフィルタリングを管理する。例えば、汎用コーダ制御コンポーネント２１１は動的に、解像度を増大させ且つバンド幅利用を増大させるよう圧縮複雑性を増大させるか、あるいは、解像度及びバンド幅利用を低減させるよう圧縮複雑性を低減させ得る。従って、汎用コーダ制御コンポーネント２１１は、ビデオ信号再構成品質とビットレート懸案事項とのバランスをとるようコーデックシステム２００の他のコンポーネントを制御する。汎用コーダ制御コンポーネント２１１は、他のコンポーネントの動作を制御する制御データを生成する。制御データはまた、デコーダでのデコーディングのためのパラメータをシグナリングするためにビットストリームの中にエンコーディングされるようヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１へも転送される。

【0054】

パーティション化されたビデオ信号２０１は、動き推定コンポーネント２２１及び動き補償コンポーネント２１９へもインター予測のために送られる。パーティション化されたビデオ信号２０１のフレーム又はスライスは、複数のビデオブロックに分割されてよい。動き推定コンポーネント２２１及び動き補償コンポーネント２１９は、時間予測を提供するよう１つ以上の参照フレーム内の１つ以上のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。コーデックシステム２００は、例えば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、多数のコーディングパスを実行してよい。

【0055】

動き推定コンポーネント２２１及び動き補償コンポーネント２１９は、高集積されてよいが、概念上の目的のために別々に表されている。動き推定コンポーネント２２１によって実行される動き推定は、動きベクトルを生成するプロセスであり、これにより、ビデオブロックの動きを推定する。動きベクトルは、例えば、予測ブロックに対するコーディングされたオブジェクトの変位を示し得る。予測ブロックは、ピクセル差分に関して、コーディングされるべきブロックと厳密に一致すると認められるブロックである。予測ブロックは、参照ブロックと呼ばれることもある。このようなピクセル差分は、差分絶対和（sum of absolute difference，ＳＡＤ）、差分平方和（sum of square difference，ＳＳＤ）、又は他の差分メトリックによって決定されてよい。ＨＥＶＣは、ＣＴＵ、コーディングツリーブロック（ＣＴＢ）、及びＣＵを含むいくつかのコーディングされたオブジェクトを用いる。例えば、ＣＴＵはＣＴＢに分割され得、ＣＴＢは、次いで、ＣＵでの包含のためにＣＢに分割され得る。ＣＵは、ＣＵについての、予測データを含む予測ユニット（ＰＵ）、及び／又は変換された残差データを含む変換ユニット（ＴＵ）として、エンコーディングされ得る。動き推定コンポーネント２２１は、レートひずみ解析をレートひずみ最適化プロセスの部分として使用することによって、動きベクトル、ＰＵ、及びＴＵを生成する。例えば、動き推定コンポーネント２２１は、現在のブロック／フレームについて、多数の参照ブロック、多数の動きベクトル、などを決定してよく、最良のレートひずみ特性を有している参照ブロック、動きベクトル、などを選択してよい。最良のレートひずみ特性は、ビデオ再構成の品質（例えば、圧縮によるデータ損失の量）とコーディング効率（例えば、最終的なエンコーディングのサイズ）との両方のバランスをとる。

【0056】

いくつかの例では、コーデックシステム２００は、デコーディングピクチャバッファコンポーネント２２３に記憶されている参照ピクチャのサブ整数ピクセル位置についての値を計算してよい。例えば、ビデオコーデックシステム２００は、参照ピクチャの４分の１ピクセル位置、８分の１ピクセル位置、又は他の分数ピクセル位置の値を補間してよい。従って、動き推定コンポーネント２２１は、完全ピクセル位置及び分数ピクセル位置に対して動き探索を実行し、分数ピクセル精度で動きベクトルを出力してよい。動き推定コンポーネント２２１は、ＰＵの位置を参照ピクセルの予測ブロックの位置と比較することによって、インターコーディングされたスライス内のビデオブロックのＰＵについての動きベクトルを計算する。動き推定コンポーネント２２１は、計算された動きベクトルを、エンコーディングのためにヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１へ動きデータとして、及び動き補償コンポーネント２１９へ動きデータとして、出力する。

【0057】

動き補償コンポーネント２１９によって実行される動き補償は、動き推定コンポーネント２２１によって決定された動きベクトルに基づいて予測ブロックをフェッチ又は生成することを含んでよい。先と同じく、動き推定コンポーネント２２１及び動き補償コンポーネント２１９は、いくつかの例では、機能的に集積されてよい。現在のビデオブロックのＰＵについての動きベクトルを受け取ると、動き補償コンポーネント２１９は、動きベクトルが指し示す予測ブロックの位置を見つけてよい。次いで、残差ビデオブロックは、コーディング中の現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減じてピクセル差分値を形成することによって、形成される。一般に、動き推定コンポーネント２２１は、ルーマ成分に対して動き推定を実行し、動き補償コンポーネント２１９は、クロマ成分及びルーマ成分の両方に対して、ルーマ成分に基づいて計算された動きベクトルを使用する。予測ブロック及び残差ブロックは、変換スケーリング及び量子化コンポーネント２１３へ転送される。

【0058】

パーティション化されたビデオ信号２０１は、イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７へも送られる。動き推定コンポーネント２２１及び動き補償コンポーネント２１９と同様に、イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７は高集積されてよいが、概念上の目的のために別々に表されている。イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７は、上述されたようにフレーム間で動き推定コンポーネント２２１及び動き補償コンポーネント２１９によって実行されたインター予測に対する代替案として、現在のフレーム内のブロックに対して現在のブロックをイントラ予測する。特に、イントラピクチャ推定コンポーネント２１５は、現在のブロックをエンコーディングするために使用すべきイントラ予測モードを決定する。いくつかの例では、イントラピクチャ推定コンポーネント２１５は、複数の試験されたイントラ予測モードから、現在のブロックをエンコーディングするための適切なイントラ予測モードを選択する。選択されたイントラ予測モードは、次いで、エンコーディングのためにヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１へ転送される。

【0059】

例えば、イントラピクチャ推定コンポーネント２１５は、様々な試験されたイントラ予測モードについてレートひずみ解析を用いてレートひずみ値を計算し、試験されたモードの中で最良のレートひずみ特性を有しているイントラ予測モードを選択する。レートひずみ解析は、一般に、エンコーディングされたブロックを生成するために使用されたビットレート（例えば、ビットの数）に加えて、エンコーディングされたブロックと、エンコーディングされたブロックを生成するようエンコーディングされた元のエンコーディングされていないブロックとの間のひずみ（又はエラー）の量も決定する。イントラピクチャ推定コンポーネント２１５は、どのイントラ予測モードがそのブロックについて最良のレートひずみ値を示すかを決定するよう、様々なエンコーディングされたブロックについてのひずみ及びレートから比を計算する。その上、イントラピクチャ推定コンポーネント２１５は、レートひずみ最適化（rate-distortion optimization，ＲＤＯ）に基づいてデプスモデリングモード（depth modeling mode，ＤＭＭ）を用いてデプスマップのデプスブロックをコーディングするよう構成されてよい。

【0060】

イントラピクチャ予測コンポーネント２１７は、エンコーダで実装される場合には、イントラピクチャ推定コンポーネント２１５によって決定された選択されたイントラ予測モードに基づいて予測ブロックから残差ブロックを生成し、あるいは、デコーダで実装される場合には、ビットストリームから残差ブロックを読み出してよい。残差ブロックは、行列として表される、予測ブロックと元のブロックとの間の値の差を含む。残差ブロックは、次いで、変換スケーリング及び量子化コンポーネント２１３へ転送される。イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７は、ルーマ及びクロマ成分の両方に作用してよい。

【0061】

変換スケーリング及び量子化コンポーネント２１３は、残差ブロックを更に圧縮するよう構成される。変換スケーリング及び量子化コンポーネント２１３は、離散コサイン変換（discrete cosine transform，ＤＣＴ）、離散サイン変換（discrete sine transform，ＤＳＴ）、又は概念上類似した変換などの変換を残差ブロックに適用して、残差変換係数値を有するビデオブロックを生成する。ウェーブレット変換、整数変換、サブバンド変換、又は他のタイプの変換も使用されてよい。変換は、残差情報をピクセル値領域から周波数領域などの変換領域へ変換してよい。変換スケーリング及び量子化コンポーネント２１３はまた、例えば、周波数に基づいて、変換された残差情報をスケーリングするよう構成される。このようなスケーリングは、異なる周波数情報が異なる粒度で量子化されるように、スケール係数を残差情報に適用することを含み、これは、再構成されたビデオの最終的な視覚品質に影響を及ぼし得る。変換スケーリング及び量子化コンポーネント２１３はまた、ビットレートを更に低減するように変換係数を量子化するよう構成される。量子化プロセスは、一部又は全ての係数に関連したビットデプスを低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、変換スケーリング及び量子化コンポーネント２１３は、次いで、量子化された変換係数を含む行列のスキャンを実行してよい。量子化された変換係数は、ビットストリームの中にエンコーディングされるようヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１へ転送される。

【0062】

スケーリング及び逆変換コンポーネント２２９は、動き推定をサポートするよう変換スケーリング及び量子化コンポーネント２１３の逆の動作を適用する。スケーリング及び逆変換コンポーネント２２９は、例えば、他の現在のブロックのための予測ブロックになり得る参照ブロックとしての後の使用のために、ピクセル領域で残差ブロックを再構成するよう逆のスケーリング、変換、及び／又は量子化を適用する。動き推定コンポーネント２２１及び／又は動き補償コンポーネント２１９は、後のブロック／フレームの動き推定における使用のために、対応する予測ブロックに残差ブロックを加え直すことによって、参照ブロックを計算してよい。フィルタは、スケーリング、量子化、及び変換中に生じたアーチファクトを軽減するために、再構成された参照ブロックに適用される。このようなアーチファクトは、さもなければ、後続のブロックが予測される場合に誤った予測を引き起こす（そして、更なるアーチファクトを引き起こす）可能性がある。

【0063】

フィルタ制御解析コンポーネント２２７及びインループフィルタコンポーネント２２５は、残差ブロックに及び／又は再構成された画像ブロックにフィルタを適用する。例えば、スケーリング及び逆変換コンポーネント２２９からの変換された残差ブロックは、元の画像ブロックを再構成するよう、イントラピクチャ予測コンポーネント２１７及び／又は動き補償コンポーネント２１９からの対応する予測ブロックと結合されてよい。フィルタは、次いで、再構成された画像ブロックに適用されてよい。いくつかの例では、フィルタは、代わりに、残差ブロックに適用されてもよい。図２の他のコンポーネントと同様に、フィルタ制御解析コンポーネント２２７及びインループフィルタコンポーネント２２５は高集積され、一緒に実装されてよいが、概念上の目的のために別々に表されている。再構成された参照ブロックに適用されたフィルタは、特定の空間領域に適用され、このようなフィルタがどのように適用されるかを調整するための複数のパラメータを含む。フィルタ制御解析コンポーネント２２７は、このようなフィルタがどこで適用されるべきかを決定するために、再構成された参照ブロックを解析し、対応するパラメータをセットする。このようなデータは、エンコーディングのためにフィルタ制御データとしてヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１へ転送される。インループフィルタコンポーネント２２５は、フィルタ制御データに基づいてそのようなフィルタを適用する。フィルタは、デブロッキングフィルタ、ノイズ抑制フィルタ、ＳＡＯフィルタ、及び適応ループフィルタを含んでよい。このようなフィルタは、例に応じて、空間／ピクセル領域で（例えば、再構成されたピクセルブロックに対して）、あるいは、周波数領域で適用されてよい。

【0064】

エンコーダとして動作する場合に、フィルタ処理された再構成された画像ブロック、残差ブロック、及び／又は予測ブロックは、上述されたように動き推定での後の使用のためにデコーディングピクチャバッファコンポーネント２２３に記憶される。デコーダとして動作する場合に、デコーディングピクチャバッファコンポーネント２２３は、再構成され且つフィルタ処理されたブロックを記憶し、出力ビデオ信号の部分としてディスプレイに向けて転送する。デコーディングピクチャバッファコンポーネント２２３は、予測ブロック、残差ブロック、及び／又は再構成された画像ブロックを記憶することができる如何なるメモリデバイスであってもよい。

【0065】

ヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１は、コーデックシステム２００の様々なコンポーネントからデータを受け取り、そのようなデータを、デコーダに向けた伝送のために、コーディングされたビットストリーム内にエンコーディングする。具体的に、ヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１は、汎用制御データ及びフィルタ制御データなどの制御データをエンコーディングするための様々なヘッダを生成する。更に、量子化された変換係数データの形での残差データに加えて、イントラ予測及び動きデータを含む予測データも、全て、ビットストリームの中にエンコーディングされる。最終的なビットストリームは、元のパーティション化されたビデオ信号２０１を再構成するためにデコーダによって望まれる全ての情報を含む。このような情報はまた、イントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）、様々なブロックのエンコーディングコンテキストの定義、最も確からしいイントラ予測モードの指示、パーティション情報の指示、などを含んでもよい。このようなデータは、エントロピコーディングを用いることによってエンコーディングされてよい。例えば、情報は、コンテキスト適応可変長コーディング（context adaptive variable length coding，ＣＡＶＬＣ）、ＣＡＢＡＣ、シンタックスに基づくコンテキスト適応バイナリ算術コーディング（syntax-based context-adaptive binary arithmetic coding，ＳＢＡＣ）、確率間隔パーティション化エントロピ（probability interval partitioning entropy，ＰＩＰＥ）コーディング、又は他のエントロピコーディング技術を用いることによってエンコーディングされてよい。エントロピコーディングに続いて、コーディングされたビットストリームは、他のデバイス（例えば、ビデオデコーダ）へ伝送されても、あるいは、後の伝送又は読み出しのためにアーカイブ保管されてもよい。

【0066】

図３は、例となるビデオエンコーダ３００を表すブロック図である。ビデオエンコーダ３００は、コーデックシステム２００のエンコーディング機能を実装し、且つ／あるいは、動作方法１００のステップ１０１、１０３、１０５、１０７、及び／又は１０９を実装するために、用いられてよい。エンコーダ３００は、入力ビデオ信号をパーティション化して、パーティション化されたビデオ信号２０１と実質的に類似しているパーティション化されたビデオ信号３０１をもたらす。パーティション化されたビデオ信号３０１は、次いで、エンコーダ３００のコンポーネントによってビットストリーム内に圧縮及びエンコーディングされる。

【0067】

具体的に、パーティション化されたビデオ信号３０１は、イントラ予測のためにイントラピクチャ予測コンポーネント３１７へ転送される。イントラピクチャ予測コンポーネント３１７は、イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７と実質的に類似し得る。パーティション化されたビデオ信号３０１は、デコーディングピクチャバッファコンポーネント３２３内の参照ブロックに基づいたインター予測のために、動き補償コンポーネント３２１へも転送される。動き補償コンポーネント３２１は、動き推定コンポーネント２２１及び動き補償コンポーネント２１９と実質的に類似し得る。イントラピクチャ予測コンポーネント３１７及び動き補償コンポーネント３２１からの予測ブロック及び残差ブロックは、残差ブロックの変換及び量子化のために、変換及び量子化コンポーネント３１３へ転送される。変換及び量子化コンポーネント３１３は、変換スケーリング及び量子化コンポーネント２１３と実質的に類似し得る。変換及び量子化された残差ブロック並びに対応する予測ブロックが（関連した制御データとともに）ビットストリーム内へのコーディングのためにエントロピコーディングコンポーネント３３１へ転送される。エントロピコーディングコンポーネント３３１は、ヘッダフォーマッティング及びＣＡＢＡＣコンポーネント２３１と実質的に類似し得る。

【0068】

変換及び量子化された残差ブロック並びに／又は対応する予測ブロックは、変換及び量子化コンポーネント３１３から逆変換及び量子化コンポーネント３２９へも、動き補償コンポーネント３２１によって使用される参照ブロックへの再構成のために転送される。逆変換及び量子化コンポーネント３２９は、スケーリング及び逆変換コンポーネント２２９と実質的に類似し得る。インループフィルタコンポーネント３２５におけるインループフィルタも、例に応じて、残差ブロック及び／又は再構成された参照ブロックに適用される。インループフィルタコンポーネント３２５は、フィルタ制御解析コンポーネント２２７及びインループフィルタコンポーネント２２５と実質的に類似し得る。インループフィルタコンポーネント３２５は、インループフィルタコンポーネント２２５に関して説明されたように複数のフィルタを含んでよい。フィルタ処理されたブロックは、次いで、動き補償コンポーネント３２１による参照ブロックとしての使用のために、デコーディングピクチャバッファコンポーネント３２３に記憶される。デコーディングピクチャバッファコンポーネント３２３は、デコーディングピクチャバッファコンポーネント２２３と実質的に類似し得る。

【0069】

図４は、例となるビデオデコーダ４００を表すブロック図である。ビデオデコーダ４００は、コーデックシステム２００のデコーディング機能を実装し、且つ／あるいは、動作方法１００のステップ１１１、１１３、１１５、及び／又は１１７を実装するために、用いられてよい。デコーダ４００は、例えば、エンコーダ３００から、ビットストリームを受け取り、ビットストリームに基づいて、エンドユーザへの表示のために、再構成された出力ビデオ信号を生成する。

【0070】

ビットストリームは、エントロピデコーディングコンポーネント４３３によって受け取られる。エントロピデコーディングコンポーネント４３３は、ＣＡＶＬＣ、ＣＡＢＡＣ、ＳＢＡＣ、ＰＩＰＥコーディング、又は他のエントロピコーディング技術などのエントロピデコーディングスキームを実装するよう構成される。例えば、エントロピデコーディングコンポーネント４３３は、ビットストリームの中にコードワードとしてエンコーディングされた追加データを解釈するためにコンテキストを供給するようヘッダ情報を用いてよい。デコーディングされた情報は、汎用制御データ、フィルタ制御データ、パーティション情報、動きデータ、予測データ、及び量子化された変換係数などのビデオ信号を残差ブロックからデコーディングするための如何なる望ましい情報も含む。量子化された変換係数は、逆変換及び量子化コンポーネント４２９へ、残差ブロックへの再構成のために転送される。逆変換及び量子化コンポーネント４２９は、逆変換及び量子化コンポーネント３２９と類似し得る。

【0071】

再構成された残差ブロック及び／又は予測ブロックは、イントラ予測動作に基づく画像ブロックへの再構成のために、イントラピクチャ予測コンポーネント４１７へ転送される。イントラピクチャ予測コンポーネント４１７は、イントラピクチャ推定コンポーネント２１５及びイントラピクチャ予測コンポーネント２１７と類似し得る。具体的に、イントラピクチャ予測コンポーネント４１７は、フレーム内の参照ブロックの位置を見つけるために予測モードを用い、残差ブロックをその結果に適用して、イントラ予測された画像ブロックを再構成する。再構成されたイントラ予測された画像ブロック及び／又は残差ブロック並びに対応するインター予測データは、インループフィルタコンポーネント４２５を介してデコーディングピクチャバッファコンポーネント４２３へ転送される。これらは、夫々、デコーディングピクチャバッファコンポーネント２２３及びインループフィルタコンポーネント２２５と実質的に類似し得る。インループフィルタコンポーネント４２５は、再構成された画像ブロック、残差ブロック及び／又は予測ブロックをフィルタ処理し、このような情報は、デコーディングピクチャバッファコンポーネント４２３に記憶される。デコーディングピクチャバッファコンポーネント４２３からの再構成された画像ブロックは、インター予測のために動き補償コンポーネント４２１へ転送される。動き補償コンポーネント４２１は、動き推定コンポーネント２２１及び／又は動き補償コンポーネント２１９と実質的に類似し得る。具体的に、動き補償コンポーネント４２１は、予測ブロックを生成するために参照ブロックからの動きベクトルを用い、残差ブロックをその結果に適用して、画像ブロックを再構成する。結果として得られる再構成されたブロックも、インループフィルタコンポーネント４２５を介してデコーディングピクチャバッファコンポーネント４２３へ転送されてよい。デコーディングピクチャバッファコンポーネント４２３は、パーティション情報によりフレーム内に再構成され得る更なる再構成された画像ブロックを引き続き記憶する。このようなフレームはシーケンスでも配置されてよい。シーケンスは、再構成された出力ビデオ信号としてディスプレイに向けて出力される。

【0072】

図５は、エンコーディングされたビデオシーケンスをＨＰＳ５１３とともに含む、例となるビットストリーム５００を表す概略図である。例えば、ビットストリーム５００は、コーデックシステム２００及び／又はデコーダ４００によるデコーディングのためにコーデックシステム２００及び／又はエンコーダ３００によって生成され得る。他の例として、ビットストリーム５００は、ステップ１１１でのデコーダによる使用のために、方法１００のステップ１０９でエンコーダによって生成されてもよい。

【0073】

ビットストリーム５００は、シーケンスパラメータセット（ＳＰＳ）５１０、複数のピクチャパラメータセット（ＰＰＳ）５１２、複数のスライスヘッダ５１４、及び画像データ５２０を含む。ＳＰＳ５１０は、ビットストリーム５００に含まれているビデオシーケンス内の全てのピクチャに共通するシーケンスデータを含む。このようなデータは、ピクチャサイジング、ビットデプス、コーディングツールパラメータ、ビットレート制限、などを含むことができる。ＰＰＳ５１２は、１つ以上の対応するピクチャに特有であるパラメータを含む。従って、ビデオシーケンス内の各ピクチャは、１つのＰＰＳ５１２を参照し得る。ＰＰＳ５１２は、対応するピクチャ内のタイルに利用可能なコーディングツール、量子化パラメータ、オフセット、ピクチャ特有のコーディングツールパラメータ（例えば、フィルタ制御）などを示すことができる。スライスヘッダ５１４は、ピクチャ内の１つ以上の対応するスライスに特有であるパラメータを含む。従って、ビデオシーケンス内の各スライスは、スライスヘッダ５１４を参照し得る。スライスヘッダ５１４は、スライスタイプ情報、ピクチャ順序カウント（ＰＯＣ）、参照ピクチャリスト、予測重み、タイルエントリポイント、デブロッキングパラメータ、などを含んでよい。いくつかの例では、スライスは、タイルグループと呼ばれることがある。そのような場合に、スライスヘッダ５１４は、タイルグループヘッダと呼ばれることがある。

【0074】

画像データ５２０は、インター予測及び／又はイントラ予測に従ってエンコーディングされたビデオデータを、対応する変換及び量子化された残差データとともに含む。そのような画像データ５２０は、エンコーディングの前に画像をパーティション化するために使用されるパーティション化に従ってソートされる。例えば、ビデオシーケンスは、ピクチャ５２１に分割される。ピクチャ５２１は、スライス５２３に分割される。スライス５２３は、タイル及び／又はＣＴＵに更に分割されてよい。ＣＴＵは、コーディングツリーに基づいてコーディングブロックに更に分割される。コーディングブロックは、次いで、予測メカニズムに従ってエンコーディング／デコーディングされ得る。例えば、ピクチャ５２１は、１つ以上のスライス５２３を含むことができる。ピクチャ５２１は、ＰＰＳ５１２を参照し、スライス５２３は、スライスヘッダ５１４を参照する。各スライス５２３は、１つ以上のタイルを含んでよい。各スライス５２３及び／又はピクチャ５２１は、その場合に、複数のＣＵＵを含むことができる。

【0075】

各ピクチャ５２１は、対応する時点のビデオシーケンスに関連した視覚データの全体の組を含んでよい。ＶＲシステムは、ピクチャ５２１のユーザにより選択された領域を表示してよく、これは、ピクチャ５２１で表されているシーンに存在しているという感覚を作り出す。ユーザが見たいと望む可能性がある領域は、ビットストリーム５００がエンコーディングされるときに知られていない。従って、ピクチャ５２１は、ユーザが潜在的に見るかもしれない夫々の可能性がある領域を含んでよい。しかし、ＶＲコンテキストでは、対応するコーデックは、ユーザがピクチャ５２１の選択された領域のみを見て、ピクチャ５２１の残りの部分は捨てられるという推定に基づいて、設計されることがある。

【0076】

各スライス５２３は、左上隅にあるＣＴＵ及び右下隅にあるＣＴＵによって定義された長方形であってよい。いくつかの例では、スライス５２３は、左から右及び上から下に進むラスタスキャン順序においてタイル及び／又はＣＴＵの連続を含む。他の例では、スライス５２３は長方形スライスである。長方形スライスは、ラスタスキャン順序に従ってピクチャの全体の幅をトラバースしてなくもよい。代わりに、長方形スライスは、ＣＴＵ及び／又はタイル行並びにＣＴＵ及び／又はタイル列に関して定義されたピクチャ５２１の長方形及び／又は正方形領域を含んでよい。スライス５２３は、デコーダによって別個に表示され得る最小単位である。従って、ピクチャ５２１からのスライス５２３は、ピクチャ５２１の所望の領域を別々に表すよう異なるサブ領域５２２に割り当てられてよい。例えば、ＶＲコンテキストでは、ピクチャ５２１は、データの全体の視認可能な球を含んでよいが、ユーザは、ヘッドマウントディスプレイで１つ以上のスライス５２３を含むサブピクチャ５２２しか見なくてよい。

【0077】

上述されたように、ビデオコーデックは、ピクチャ５２１の非選択領域がデコーダで捨てられるべきであると仮定してよい。従って、サブビットストリーム５０１がビットストリーム５００から抽出されてよい。抽出されたサブビットストリーム５０１は、選択されたサブピクチャ５２２及び関連したシンタックスを含んでよい。ピクチャ５２１の非選択領域は、コーディング効率を向上させるよう、より低い解像度で伝送されるか、あるいは、省略されてもよい。サブピクチャ５２２は、ピクチャ５２１の選択された領域であり、１つ以上の関連したスライス５２４を含んでよい。スライス５２４は、サブピクチャ５２２に関連したピクチャ５２１の選択された領域を表すスライス５２３のサブセットである。サブビットストリーム５０１は、サブピクチャ５２２及びスライス５２４に関係があるＳＰＳ５１０、ＰＰＳ５１２、スライスヘッダ５１４、及び／又はそれらのサブ部分も含む。

【0078】

サブビットストリーム５０１は、ビットストリーム５００から抽出され得る。例えば、デコーダを用いているユーザは、ビデオのセグメントを見ることがある。ユーザは、ピクチャ５２１の対応する領域を選択してよい。デコーダは、ユーザが現在見ている領域に関連した後続のサブピクチャ５２２を要求することができる。エンコーダは、次いで、選択された領域に関連したサブピクチャ５２２を、より高い解像度で、及びピクチャ５２１の残りの領域を、より低い解像度で転送することができる。このような機能性を可能にするために、デコーダは、ビットストリーム５００から１つ以上のサブビットストリーム５０１を抽出５２９することができる。抽出５２９は、スライス５２４をサブピクチャ５２２に含めながら、サブピクチャ５２２をサブビットストリーム５０１内に置くことを含む。抽出５２９は、サブピクチャ５２２及びスライス５２４をデコーディングすることを支援するために望まれるように、関連するＳＰＳ５１０、ＰＰＳ５１２、及びスライスヘッダ５１４をサブビットストリーム内に置くことも含む。

【0079】

サブビットストリーム５０１の抽出５２９に伴う１つの問題は、ピクチャ５２１に関連したアドレッシングが、サブピクチャ５２２に関連したアドレッシングとは異なる可能性があることである。アドレッシング問題は、以下で更に詳細に論じられる。いくつかのシステムでは、スライスヘッダ５１４は、そのようなアドレッシング不一致に対して調整するよう書き直され得る。しかし、サブビットストリーム５０１は、多数のスライスヘッダ５１４を（例えば、ピクチャ５２１ごとに１つ又は２つほどで）含む可能性があり、そのようなスライスヘッダ５１４は、各ユーザに対して動的に書き直される。そのようなものとして、このようにしてスライスヘッダ５１４を書き直すことは、プロセッサ負荷が非常に大きい可能性がある。本開示は、スライスヘッダ５１４が、スライスヘッダ５１４を書き直さずにサブビットストリーム５０１内に抽出５２９されることを可能にするメカニズムを含む。

【0080】

スライスヘッダ５１４を書き直すシステムでは、スライス５２３及び５２４は、スライスインデックス、タイルインデックス、ＣＴＵインデックス、などのようなインデックス値に基づいてアドレッシングされる。そのようなインデックスは、ラスタスキャン順序において値が増大する。アドレッシング不一致を正すために、開示されている実施形態は、スライス、タイル、及び／又はＣＴＵごとに、定義されたＩＤ値を用いる。そのような定義されたＩＤは、デフォルト値であってよく、かつ／あるいは、エンコーダによって選択されてもよい。定義されたＩＤは、一貫した方法でラスタスキャン順序において増加してよいが、そのような定義されたＩＤは、単調増加していなくてもよい。従って、定義されたＩＤは、アドレス管理を可能にするよう値の間にギャップを残してよい。例えば、インデックスは単調増加してよく（例えば、０、１、２、３など）、一方、定義されたＩＤは何らかの定義された倍数によって増加してよい（例えば、０、１０、２０、３０、など）。エンコーダは、ビットストリーム５００及びサブビットストリーム５０１にマッピング５３５を含めることができ、これは、デコーダが、定義されたＩＤから、デコーダが解釈することができるインデックスへマッピングすることを可能にする。

【0081】

ＳＰＳ５１０及び／又はＰＰＳ５１２などのパラメータセットは、ＩＤフラグ５３１を含んでよい。ＩＤフラグ５３１は、ピクチャ５２１に基づいた位置からサブピクチャ５２２に基づいた位置へスライスアドレスをマッピングするためにマッピング５３５が利用可能であることを示すようセットされてよい。従って、ＩＤフラグ５３１は、開示されているメカニズムがビットストリーム５００及びサブビットストリーム５０１で用いられていることをデコーダに示すようセットされてよい。例えば、ＩＤフラグ５３１は、明示的なタイルＩＤフラグ、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、又は他のシンタックス要素としてコーディングされてよい。ＩＤフラグ５３１は、ビットストリーム５００内にエンコーディングされ、サブビットストリーム５０１内に抽出５２９されてよい。

【0082】

ＳＰＳ５１０及び／又はＰＰＳ５１２などのパラメータセットは、ＩＤ５３２のシンタックス要素を含んでもよい。ＩＤ５３２は、ピクチャ５２１内のサブピクチャ５２２を示してよい。例えば、ＩＤ５３２のアレイは、ビットストリーム５００のＰＰＳ５１２に含まれ得る。サブビットストリーム５０１が抽出５２９されるとき、デコーダへ送られるべきサブピクチャ５２２に関連したＩＤ５３２は、サブビットストリーム５０１のＰＰＳ５１２に含まれ得る。他の例では、関連したＩＤ５３２への指示が、デコーダが正しいＩＤ５３２を決定することを可能にするために、サブビットストリーム５０１内のＰＰＳ５１２に挿入され得る。例えば、ＩＤ５３２は、サブピクチャ５２２の境界を示すＳｕｂＰｉｃＩｄｘ、Ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｉ］、又は他のシンタックス要素としてコーディングされてよい。

【0083】

ＳＰＳ５１０及び／又はＰＰＳ５１２などのパラメータセットは、スライスアドレスの長さ５３３のシンタックス要素を含んでもよい。更には、スライスヘッダ５１４は、スライス５２３のスライスアドレス５３４を含んでよい。スライスアドレス５３４は、定義されたＩＤ値として含まれる。スライスアドレス５３４は、スライスヘッダ５１４を書き直すことを回避するよう、変更なしで、サブビットストリーム５０１内のスライスヘッダ５１４内に直接に抽出５２９され得る。例えば、スライスアドレス５３４は、スライス５２３及び５２４の境界を示すｓｌｉｃｅ＿ａｄｄｒｅｓｓ、ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓ、又は他のシンタックス要素としてコーディングされてよい。スライスアドレスの長さ５３３は、次いで、スライスアドレス５３４を解釈するために用いられ得る。例えば、スライスアドレス５３４は、エンコーダにより定義された値を含む、従って、バイトアライメントフィールドが後に続く可変な長さ値としてコーディングされる。スライスアドレスの長さ５３３は、対応するスライスアドレス５３４に含まれているビットの数を示してよく、従って、スライスアドレス５３４の境界をデコーダに示し得る。そのようなものとして、デコーダは、スライスアドレス５３４を解釈するために（例えば、ＰＰＳ５１２から）スライスアドレスの長さ５３３を用いることができる。そのようなものとして、スライスヘッダ５１４は、スライスアドレス５３４に続くバイトアライメントフィールドを調整するよう書き直される必要がない。例えば、スライスアドレスの長さ５３３は、スライスアドレスの長さ５３３を示すｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１、又は他のシンタックス要素としてコーディングされてよい。スライスアドレスの長さ５３３は、ビットストリーム５００のＰＰＳ５１２に含まれ、次いで、サブビットストリーム５０１のＰＰＳ５１２内に抽出５２９されてよい。

【0084】

マッピング５３５も、ＳＰＳ５１０、ＰＰＳ５１２、及び／又はスライスヘッダ５１４などのパラメータセットで伝送されてもよい。マッピング５３５は、ピクチャ５２１に基づいた位置からサブピクチャ５２２に基づいた位置へスライスアドレスをマッピングするためのメカニズムを示す。マッピング５３５は、ビットストリーム５００内にエンコーディングされ、サブビットストリーム５０１内の対応するパラメータセット内に抽出５２９されてよい。例えば、マッピング５３５は、ピクチャ５２１に基づいた位置からサブピクチャ５２２に基づいた位置へスライスアドレスをマッピングするためのメカニズムを示すＳｌｉｃｅＳｕｂｐｉｃＴｏＰｉｃＩｄｘ［ＳｕｂＰｉｃＩｄｘ］［ｓｌｉｃｅ＿ａｄｄｒｅｓｓ］シンタックス要素、ｔｉｌｅＩＤＴｏＩｄｘ［Ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓ］シンタックス要素、又は他のシンタックス要素としてコーディングされてよい。

【0085】

従って、デコーダは、サブビットストリーム５０１を読み出し、スライス５２４が、インデックスの代わりに、定義されたアドレスによってアドレッシングされることを決定するようＩＤフラグ５３１を取得することができる。デコーダは、サブビットストリーム５０１に含まれているサブピクチャ５２２を決定するようＩＤ５３２を取得することができる。デコーダはまた、スライスアドレス５３４を解釈するようスライスアドレス５３４及びスライスアドレスの長さ５３３を取得することもできる。デコーダは、次いで、デコーダが解釈することができるフォーマットへスライスアドレス５３４をマッピングするようマッピング５３５を取得することができる。デコーダは、次いで、サブピクチャ５２２及び対応するスライス５２４をデコーディングし表示するときにスライスアドレス５３４を用いることができる。

【0086】

図６は、コーディングのためにパーティション化された例示的なピクチャ６００を表す概略図である。例えば、ピクチャ６００は、例えば、コーデックシステム２００、エンコーダ３００、及び／又はデコーダ４００によって、ビットストリーム５００の中にエンコーディングされ、ビットストリーム５００からデコーディングされ得る。更に、ピクチャ６００は、方法１００に従うエンコーディング及びデコーディングをサポートするよう、サブビットストリーム５０１内のサブピクチャにパーティション化及び／又は包含され得る。

【0087】

ピクチャ６００は、スライス５２３と実質的に同様であってよいスライス６２３にパーティション化され得る。スライス６２３は、タイル６２５及びＣＴＵ６２７に更にパーティション化されてよい。図６では、スライス６２３は、スライス６２３どうしをグラフィカルに区別するために白色背景と陰付きとを交互にして太線で表されている。タイル６２５は破線で示されている。スライス６２３の境界上に位置しているタイル６２５の境界は、太い破線として表されており、スライス６２３の境界上に位置していないタイル６２５の境界は、太くない破線として表されている。ＣＴＵ６２７の境界は、ＣＴＵ６２７の境界がタイル６２５又はスライス６２３の境界によってカバーされている位置を除いて、太くない実線として表されている。この例では、ピクチャ６００は、９つのスライス６２３と、２４個のタイル６２５と、２１６個のＣＴＵ６２７とを含む。

【0088】

示されるように、スライス６２３は、含まれているタイル６２５及び／又はＣＴＵ６２７によって定義され得る境界を持った長方形である。スライス６２３は、ピクチャ６００の全体の幅にわたって延在しなくてもよい。タイル６２５は、行及び列に従ってスライス６２３において生成され得る。ＣＴＵ６２７は、インター予測及び／又はイントラ予測に従うコーディングのためのコーディングブロックに細分されるのに適したピクチャ６００のパーティションを生成するよう、タイル６２５及び／又はスライス６２３からパーティション化され得る。ピクチャ６００は、ビットストリーム５００などのビットストリーム内にエンコーディングされてよい。ピクチャ６００の領域は、夫々サブピクチャ５２２及びサブビットストリーム５０１などの、サブピクチャに含まれ、サブビットストリーム内に抽出されてよい。

【0089】

図７は、ピクチャ７００から抽出された例示的なサブピクチャ７２２を表す概略図である。例えば、ピクチャ７００は、ピクチャ６００と実質的に同様であってよい。更に、ピクチャ７００は、例えば、コーデックシステム２００、及び／又はエンコーダ３００によって、ビットストリーム５００内にエンコーディングされ得る。サブピクチャ７２２は、例えば、コーデックシステム２００、エンコーダ３００、及び／又はデコーダ４００によって、サブビットストリーム５０１内に抽出され、それからデコーディングされ得る。更に、ピクチャ７００は、方法１００に従うエンコーディング及びデコーディングをサポートするために用いられ得る。

【0090】

示されるように、ピクチャ７００は、左上隅７０２及び右下隅７０４を含む。サブピクチャ７２２は、ピクチャ７００からの１つ以上のスライス７２３を含む。インデックスを使用する場合に、左上隅７０２及び右下隅７０４は、夫々、最初及び最後のインデックスと関連付けられる。しかし、デコーダは、サブピクチャ７２２のみを表示して、全体のピクチャ７００を表示しないことがある。更に、第１スライス７２３ａのスライスアドレス７３４は、左上隅７０２とアライメントしない可能性があり、第３スライス７２３ｃのスライスアドレス７３４は、右下隅７０４とアライメントしない可能性がある。そのようなものとして、サブピクチャ７２２に対するスライスアドレス７３４は、ピクチャ７００に対するスライスアドレス７３４とアライメントしない。本開示は、インデックスの代わりに、スライスアドレス７３４に対して、定義されたＩＤを用いる。デコーダは、ピクチャ７００に基づいた位置からサブピクチャ７２２に基づいた位置へスライスアドレス７３４をマッピングするためにマッピングを用いることができる。デコーダは、次いで、デコーダ表示の左上隅７０２に第１スライス７２３ａを置くよう、デコーダ表示の右下隅７０４に第３スライス７２３ｃを置くよう、かつ、第１スライス７２３ａと第３スライス７２３ｃとの間に第２スライス７２３ｂを置くよう、マッピングされたスライスアドレス７３４を用いることができる。

【0091】

ここで記載されるように、本開示は、タイルがピクチャパーティション化のために使用されるビデオコーディングにおける明示的なタイルＩＤシグナリングのための改善について記載する。当該技術の記載は、ＩＴＵ－Ｔ及びＩＳＯ／ＩＥＣのＪＶＥＴによるＶＶＣに基づく。しかし、当該技術はまた、他のビデオコーデック規格にも適用される。以下は、ここで記載される例示的な実施形態である。

【0092】

タイルインデックス及びタイルＩＤの概念は区別され得る。タイルのタイルＩＤは、タイルのタイルインデックスと等しくても等しくなくてもよい。タイルＩＤがタイルインデックスとは異なる場合に、タイルＩＤとタイルインデックスとの間のマッピングがＰＰＳでシグナリングされてよい。タイルＩＤは、タイルインデックスを使用する代わりに、タイルグループヘッダ内のタイルグループアドレスのシグナリングのために使用されてよい。このように、タイルＩＤの値は、タイルグループが元のビットストリームから抽出される場合に、同じままであることができる。これは、タイルグループによって参照されるＰＰＳにおいてタイルＩＤとタイルインデックスとの間のマッピングを更新することによって達成され得る。このアプローチは、抽出されるべきサブピクチャに応じてタイルインデックスの値が変化する可能性がある場合に対処する。留意されるべきは、他のパラメータセット（例えば、スライスヘッダ以外）は、ＭＣＴＳに基づいたサブビットストリーム抽出を実行する場合に、依然として書き直され得ることである。

【0093】

上記は、タイル情報がシグナリングされるパラメータセット内のフラグを用いることによって、達成され得る。例えば、ＰＰＳがパラメータセットとして用いられ得る。例えば、ｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇがこの目的のために用いられてよい。ｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇは、ピクチャ内のタイルの数にかかわらずシグナリングされてよく、明示的なタイルシグナリングが使用されていることを示し得る。シンタックス要素も、タイルＩＤ値（例えば、タイルインデックスとタイルＩＤとの間のマッピング）のシグナリングのためのビットの数を特定するために用いられてよい。そのようなシンタックス要素は、タイルグループヘッダでタイルＩＤ／アドレスをシグナリングするためにも用いられてよい。例えば、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１シンタックス要素がこの目的のために用いられてよい。ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１は、ｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇがゼロに等しい場合（例えば、タイルＩＤがタイルインデックスに等しくセットされる場合）に、存在しなくてもよい。ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１が存在しない場合に、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＴｉｌｅｓＩｎＰｉｃ））の値に等しいと推測されてよい。更なる制約は、ＭＣＴＳサブビットストリーム抽出の結果であるビットストリームが、サブビットストリームが元のビットストリーム内の左上隅のタイルを含まない限りは、アクティブなＰＰＳについて１に等しくセットされたｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇを含んでよいことを必要とし得る。

【0094】

例となる実施形態において、ビデオコーディングシンタックスは、ここで記載されている機能性を達成するよう後述されるように変更されてよい。例となるＣＴＢラスタ及びタイルスキャンプロセスは、次のように説明され得る。タイルスキャン内のＣＴＢアドレスからタイルＩＤへの変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｃｔｂＡｄｄｒＴｓのリストＴｉｌｅＩｄ［ＣｔｂＡｄｄｒＴｓ］と、タイルインデックスからタイル内のＣＴＵの数への変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｔｉｌｅＩｄｘのリストＮｕｍＣｔｕｓＩｎＴｉｌｅ［ｔｉｌｅＩｄｘ］とは、次のように導出される：

【数1】

【0095】

タイルインデックスからタイル内のＣＴＵの数への変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｔｉｌｅＩｄｘのリストＮｕｍＣｔｕｓＩｎＴｉｌｅ［ｔｉｌｅＩｄｘ］は、次のように導出され得る：

【数2】

【0096】

タイルＩＤからタイルインデックスへの変換を特定するＮｕｍＴｉｌｅｓＩｎＰｉｃ ｔｉｌｅＩｄ値の組のセットＴｉｌｅＩｄＴｏＩｄｘ［ｔｉｌｅＩｄ］は、次のように導出され得る：

【数3】

【0097】

例となるピクチャパラメータセットＲＢＳＰシンタックスは、次のように記載され得る：

【表1】

【0098】

例となるタイルグループヘッダシンタックスは、次のように記載され得る：

【表2】

【0099】

例となるタイルグループデータシンタックスは、次のように記載され得る：

【表3】

【0100】

例となるピクチャパラメータセットＲＢＳＰセマンティクスは、次のように記載され得る。１に等しくセットされたｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇは、各タイルのタイルＩＤが明示的にシグナリングされることを特定する。ゼロに等しくセットされたｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇは、タイルＩＤが明示的にシグナリングされないことを特定する。ＭＴＣＳサブビットストリーム抽出の結果であるビットストリームについては、ｅｘｐｌｉｃｉｔ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇの値は、結果として得られるビットストリームが元のビットストリーム内の左上隅のタイルを含まない限りは、アクティブなＰＰＳについて１に等しくセットされてよい。ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１ ｐｌｕｓ１は、ＰＰＳを参照するタイルグループヘッダにおいてシンタックス要素ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｉ］及びシンタックス要素ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓを表すために使用されるビットの数を特定する。ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＴｉｌｅｓＩｎＰｉｃ））以上１５以下の範囲内にあってよい。存在しない場合に、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＴｉｌｅｓＩｎＰｉｃ））に等しいと推測されてよい。留意されるべきは、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、いくつかの場合に、Ｃｅｉｌ（Ｌｏｇ２（ＮｕｍＴｉｌｅｓＩｎＰｉｃ））よりも大きくてもよいことである。これは、現在のビットストリームがＭＣＴＳサブビットストリーム抽出の結果であり得るからである。その場合に、元のビットストリーム内のタイルインデックスであることができるタイルＩＤは、ＯｒｇＮｕｍＴｉｌｅｓＩｎＰｉｃが元のビットストリームのＮｕｍＴｉｌｅｓＩｎＰｉｃであるとして、Ｃｅｉｌ（Ｌｏｇ２（ＯｒｇＮｕｍＴｉｌｅｓＩｎＰｉｃ））個のビットによって表現されてよく、現在のビットストリームのＮｕｍＴｉｌｅｓＩｎＰｉｃよりも大きい。ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｉ］は、ＰＰＳを参照するピクチャのｉ番目のタイルのタイルＩＤを特定する。ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｉ］の長さは、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１ビットである。０以上ＮｕｍＴｉｌｅｓＩｎＰｉｃ－１以下の範囲内のいずれかの整数ｍ及びｎについて、ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｍ］は、ｍがｎに等しくない場合に、ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｎ］に等しくなくてもよく、ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｍ］は、ｍがｎよりも小さい場合に、ｔｉｌｅ＿ｉｄ＿ｖａｌ［ｎ］よりも小さくてよい。

【0101】

次の変数：ＣＴＢのユニット内のｉ番目のタイル列の幅を特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１以下の範囲に及ぶｉについてのリストＣｏｌＷｉｄｔｈ［ｉ］；ＣＴＢのユニット内のｊ番目のタイル行の高さを特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１以下の範囲に及ぶｊについてのリストＲｏｗＨｅｉｇｈｔ［ｊ］；ＣＴＢのユニット内のｉ番目のタイル列境界の位置を特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１＋１以下の範囲に及ぶｉについてのリストＣｏｌＢｄ［ｉ］；ＣＴＢのユニット内のｊ番目のタイル行境界の位置を特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１＋１以下の範囲に及ぶｊについてのリストＲｏｗＢｄ［ｊ］；ピクチャのＣＴＢラスタスキャンでのＣＴＢアドレスからタイルスキャンでのＣＴＢアドレスへの変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｃｔｂＡｄｄｒＲｓのリストＣｔｂＡｄｄｒＲｓＴｏＴｓ［ｃｔｂＡｄｄｒＲｓ］；タイルスキャンでのＣＴＢアドレスからピクチャのＣＴＢラスタスキャンでのＣＴＢアドレスへの変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｃｔｂＡｄｄｒＴｓのリストＣｔｂＡｄｄｒＴｓＴｏＲｓ［ｃｔｂＡｄｄｒＴｓ］；タイルスキャンでのＣＴＢアドレスからタイルＩＤへの変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｃｔｂＡｄｄｒＴｓのリストＴｉｌｅＩｄ［ｃｔｂＡｄｄｒＴｓ］；タイルインデックスからタイル内のＣＴＵの数への変換を特定する、０以上ＰｉｃＳｉｚｅＩｎＣｔｂｓＹ－１以下の範囲に及ぶｔｉｌｅＩｄｘのリストＮｕｍＣｔｕｓＩｎＴｉｌｅ［ｔｉｌｅＩｄｘ］；タイルＩＤからタイル内の最初のＣＴＢのタイルスキャンでのＣＴＢアドレスへの変換を特定する、０以上ＮｕｍＴｉｌｅｓＩｎＰｉｃ－１以下の範囲に及ぶｔｉｌｅＩｄｘのリストＦｉｒｓｔＣｔｂＡｄｄｒＴｓ［ｔｉｌｅＩｄｘ］；タイルＩＤからタイルインデックスへの変換を特定するＮｕｍＴｉｌｅｓＩｎＰｉｃ ｔｉｌｅＩｄ値の組のセットＴｉｌｅＩｄＴｏＩｄｘ［ｔｉｌｅＩＤ］、及びタイルＩＤからタイル内の最初のＣＴＢのタイルスキャンでのＣＴＢアドレスへの変換を特定する、０以上ＮｕｍＴｉｌｅｓＩｎＰｉｃ－１以下の範囲に及ぶｔｉｌｅＩｄｘのリストＦｉｒｓｔＣｔｂＡｄｄｒＴｓ［ｔｉｌｅＩｄｘ］；ルーマサンプルのユニット内のｉ番目のタイル列の幅を特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１以下の範囲に及ぶｉについてのリストＣｏｌｕｍｎＷｉｄｔｈＩｎＬｕｍａＳａｍｐｌｅｓ［ｉ］；並びにルーマサンプルのユニット内のｊ番目のタイル行の高さを特定する、０以上ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１以下の範囲に及ぶｊについてのリストＲｏｗＨｅｉｇｈｔＩｎＬｕｍａＳａｍｐｌｅｓ［ｊ］が、ＣＴＢラスタ及びタイルスキャン変換を呼び出すことによって導出され得る。

【0102】

ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓは、タイルグループ内の最初のタイルのタイルＩＤを特定する。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの長さは、ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１ビットである。ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値は、０以上２ｔｉｌｅ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１－１以下の範囲内にあってよく、ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値は、同じコーディングされたピクチャのいずれかの他のコーディングされたタイルグループＮＡＬユニットのｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓの値に等しくなくてもよい。

【0103】

図８は、例となるビデオコーディングデバイス８００の概略図である。ビデオコーディングデバイス８００は、ここで記載されている開示された例／実施形態を実装するのに適している。ビデオコーディングデバイス８００は、下流ポート８２０、上流ポート８５０、及び／又は、ネットワーク上で上流及び／又は下流へデータを通信する送信器及び／又は受信器を含むトランシーバユニット（Ｔｘ／Ｒｘ）８１０を有する。ビデオコーディングデバイス８００はまた、データを処理するための論理ユニット及び／又は中央演算処理装置（ＣＰＵ）を含むプロセッサ８３０と、データを記憶するメモリ８３２とを含む。ビデオコーディングデバイス８００はまた、電気、光、又は無線通信ネットワークを介したデータの通信のために上流ポート８５０及び／又は下流ポート８２０へ結合された電気的な光電気（ＯＥ）コンポーネント、電気光（ＥＯ）コンポーネント、及び／又は無線通信コンポーネントを有してもよい。ビデオコーディングデバイス８００はまた、ユーザへ及びユーザからデータを通信する入力及び／又は出力（Ｉ／Ｏ）デバイス８６０を含んでもよい。Ｉ／Ｏデバイス８６０は、ビデオデータを表示するディスプレイ、オーディオデータを出力するスピーカなどのような出力デバイスを含んでもよい。Ｉ／Ｏデバイス８６０はまた、キーボード、マウス、トラックボールなどの入力デバイス、及び／又はそのような出力デバイスと相互作用する対応するインターフェースを含んでもよい。

【0104】

プロセッサ８３０は、ハードウェア及びソフトウェアによって実装される。プロセッサ８３０は、１つ以上のＣＰＵチップ、コア（例えば、マルチコアプロセッサとして）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、及びデジタル信号プロセッサ（ＤＳＰ）として実装されてよい。プロセッサ８３０は、下流ポート８２０、Ｔｘ／Ｒｘ８１０、上流ポート８５０、及びメモリ８３２と通信する。プロセッサ８３０は、コーディングモジュール８１４を有する。コーディングモジュール８１４は、ビットストリーム５００、ピクチャ６００、及び／又はピクチャ７００を用い得る方法１００、９００、及び１０００などの、上述された開示されている実施形態を実装する。コーディングモジュール８１４はまた、ここで記載されている如何なる他の方法／メカニズムも実装してよい。更に、コーディングモジュール８１４は、コーデックシステム２００、エンコーダ３００、及び／又はデコーダ４００を実装してよい。例えば、エンコーダとして動作する場合に、コーディングモジュール８１４は、ＰＰＳでフラグ、サブピクチャＩＤ、及び長さを特定することができる。コーディングモジュール８１４は、スライスヘッダの中にスライスアドレスをエンコーディングすることもできる。次いで、コーディングモジュール８１４は、スライスヘッダを書き直さずに、ピクチャのビットストリームからサブピクチャのサブビットストリームを抽出することができる。デコーダとして動作する場合に、コーディングモジュール８１４は、明示的なスライスアドレスがインデックスの代わりに使用されているかどうかを決定するようフラグを呼び出すことができる。コーディングモジュール８１４は、ＰＰＳから長さ及びサブピクチャＩＤを、並びにスライスヘッダからスライスアドレスを読み出すこともできる。コーディングモジュール８１４は、次いで、長さを用いてスライスアドレスを解釈し、サブピクチャＩＤを用いて、ピクチャに基づいたアドレスからサブピクチャに基づいたアドレスへスライスアドレスをマッピングすることができる。そのようなものとして、コーディングモジュール８１４は、選択されたサブピクチャにかかわらず、かつ、サブピクチャに基づいたアドレス変更に適応するようスライスヘッダが書き直される必要なしに、スライスの所望の位置を決定することができる。そのようなものとして、コーディングモジュール８１４は、ビデオコーディングデバイス８００に、ビデオデータをパーティション化及びコーディングする場合に、更なる機能性を提供させ、処理オーバーヘッドを低減するよう特定の処理を回避させ、かつ／あるいは、コーディング効率を向上させる。従って、コーディングモジュール８１４は、ビデオコーディング技術に特有である問題に対処することに加えて、ビデオコーディングデバイス８００の機能性も改善する。更に、コーディングモジュール８１４は、異なる状態へのビデオコーディングデバイス８００の変形を達成する。代替的に、コーディングモジュール８１４は、メモリ８３２に記憶されておりプロセッサ８３０によって実行される命令として（例えば、非一時的な媒体に記憶されているコンピュータプログラム製品として）実装され得る。

【0105】

メモリ８３２は、ディスク、テープドライブ、ソリッドステートドライブ、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、フラッシュメモリ、三値連想メモリ（ＴＣＡＭ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）などのような１つ以上のメモリタイプを有する。メモリ８３２は、プログラムが実行のために選択される場合にそのようなプログラムを記憶するために、且つ、プログラム実行中に読み出される命令及びデータを記憶するために、オーバーフローデータ記憶デバイスとして使用されてよい。

【0106】

図９は、明示的アドレスシグナリングを用いることによって、スライスヘッダを書き直さずに、夫々サブビットストリーム５０１及びサブピクチャ５２２などのサブピクチャのサブビットストリームの抽出を支援するよう、夫々ビットストリーム５００及びピクチャ６００などのピクチャのビットストリームをエンコーディングする例示的な方法９００のフローチャートである。方法９００は、方法１００を実行する場合に、コーデックシステム２００、エンコーダ３００、及び／又はビデオコーディングデバイス８００などのエンコーダによって用いられてよい。

【0107】

方法９００は、エンコーダが複数のピクチャを含むビデオシーケンスを受信し、例えば、ユーザ入力に基づいて、そのビデオシーケンスをビットストリーム内にエンコーディングすると決定する場合に、開始してよい。ビデオシーケンスは、エンコーディングの前に更なるパーティション化のためにピクチャ／画像／フレームにパーティション化される。ステップ９０１で、ビデオシーケンスのピクチャがビットストリームの中にエンコーディングされる。ピクチャは、第１スライスを含む複数のスライスを含んでよい。第１スライスは、ピクチャ内のいずれのスライスであってもよいが、議論の明りょうさのために第１スライスと記載される。例として、第１スライスの左上隅は、ピクチャの左上隅とアライメントしなくてもよい。

【0108】

ステップ９０３で、スライスに関連したスライスヘッダがビットストリーム内にエンコーディングされる。スライスヘッダは、第１スライスのスライスアドレスを含む。スライスアドレスは、エンコーダによって選択された数値などの、定義された値を有してよい。そのような値は任意であってよいが、一貫したコーディング機能性をサポートするために、ラスタスキャン順序（例えば、左から右及び上から下）において増加してよい。スライスアドレスはインデックスを有さなくてもよい。いくつかの例では、スライスアドレスは、ｓｌｉｃｅ＿ａｄｄｒｅｓｓシンタックス要素であってよい。

【0109】

ステップ９０５で、ＰＰＳがビットストリームの中にエンコーディングされる。第１スライスの識別子及びスライスアドレスの長さが、ビットストリーム内のＰＰＳの中にエンコーディングされてよい。識別子は、サブピクチャ識別子であってよい。スライスアドレスの長さは、スライスアドレスに含まれているビットの数を示してよい。例えば、ＰＰＳ内のスライスアドレスの長さは、ステップ９０３でコーディングされたスライスヘッダからスライスアドレスを解釈するのに十分なデータを含んでよい。いくつかの例では、長さは、ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１シンタックス要素であってよい。更に、識別子は、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするのに十分なデータを含んでよい。いくつかの例では、識別子は、ｓｕｂＰｉｃＩｄｘシンタックス要素であってよい。例えば、複数のサブピクチャに基づいた識別子がＰＰＳに含まれてよい。サブピクチャが抽出される場合に、対応するサブピクチャＩＤは、例えば、フラグ／ポインタを用いること及び／又は未使用のサブピクチャＩＤを除くことによって、ＰＰＳにおいて示されてよい。いくつかの例では、明示的なＩＤフラグもパラメータセット内にコーディングされてよい。フラグは、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするためにマッピングが利用可能であることをデコーダに示してよい。いくつかの例では、マッピングは、ＳｌｉｃｅＳｕｂｐｉｃＴｏＰｉｃＩｄｘ［ＳｕｂＰｉｃＩｄｘ］［ｓｌｉｃｅ＿ａｄｄｒｅｓｓ］シンタックス要素であってよい。従って、フラグは、スライスアドレスがインデックスではないことを示し得る。いくつかの例では、フラグは、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇであってよい。

【0110】

ステップ９０７で、ビットストリームのサブビットストリームが抽出される。例えば、これは、スライスヘッダを書き直さずに、第１スライスのスライスアドレス、スライスアドレスの長さ、及び識別子に基づいて第１スライスを抽出することを含んでよい。特定の例として、そのような抽出は、ピクチャのサブピクチャの抽出も含んでよい。この場合に、サブピクチャが第１スライスを含む。パラメータセットも、サブビットストリーム内に含められてよい。例えば、サブビットストリームは、サブピクチャ、スライスヘッダ、ＰＰＳ、ＳＰＳ、などを有してよい。

【0111】

ステップ９０９で、サブビットストリームは、デコーダへ向けた通信のために記憶される。サブビットストリームは、次いで、望まれるように、デコーダへ向けて伝送されてよい。

【0112】

図１０は、明示的アドレスシグナリングを用いることによって、ビットストリーム５００及びピクチャ６００などのピクチャのビットストリームから抽出された、サブビットストリーム５０１及びサブピクチャ５２２などのサブピクチャのサブビットストリームをデコーディングする例示的な方法１０００のフローチャートである。方法１０００は、方法１００を実行する場合に、コーデックシステム２００、デコーダ４００、及び／又はビデオコーディングデバイス８００などのデコーダによって用いられてよい。

【0113】

方法１０００は、デコーダが、例えば、方法９００の結果として、ビットストリームから抽出されたサブビットストリームを受信し始める場合に開始してよい。ステップ１００１で、サブビットストリームが受信される。サブビットストリームは、ピクチャのサブピクチャを含む。例えば、エンコーダでエンコーディングされたビットストリームは、ピクチャを含んでよく、サブビットストリームは、エンコーダ及び／又はスライサでビットストリームから抽出され、サブビットストリームは、ビットストリーム内のピクチャからの１つ以上の領域を含むサブピクチャを含む。受信されたサブピクチャは、複数のスライスにパーティション化されてよい。複数のスライスは、第１スライスとして指定されたスライスを含んでよい。第１スライスは、ピクチャ内のいずれのスライスであってもよいが、議論の明りょうさのために第１スライスとして記載される。例として、第１スライスの左上隅は、ピクチャの左上隅とアライメントしなくてもよい。サブピクチャは、ピクチャに関連したシンタックスを記述し、従って、サブピクチャに関連したシンタックスも記述するＰＰＳも含む。サブビットストリームは、第１スライスに関連したシンタックスを記述するスライスヘッダも含む。

【0114】

ステップ１００３で、ＰＰＳ及び／又はＳＰＳなどのパラメータセットは、明示的なＩＤフラグを取得するようパースされてよい。ＩＤフラグは、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするためにマッピングが利用可能であることを示してよい。従って、フラグは、対応するスライスアドレスが定義された値を有し、インデックスを有さないことを示し得る。いくつかの例では、フラグは、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇであってよい。ＩＤフラグの値に基づいて、ＰＰＳは、第１スライスの識別子及びスライスアドレスの長さを取得するようパースされ得る。識別子は、サブピクチャ識別子であってよい。スライスアドレスの長さは、対応するスライスアドレスに含まれているビットの数を示してよい。例えば、ＰＰＳ内のスライスアドレスの長さは、スライスヘッダからスライスアドレスを解釈するのに十分なデータを含んでよい。いくつかの例では、長さは、ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１シンタックス要素であってよい。更に、識別子は、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするのに十分なデータを含んでよい。いくつかの例では、識別子は、ｓｕｂＰｉｃＩｄｘシンタックス要素であってよい。例えば、複数のサブピクチャに基づいた識別子がＰＰＳに含まれてよい。サブピクチャが抽出される場合に、対応するサブピクチャＩＤは、例えば、フラグ／ポインタを用いること及び／又は未使用のサブピクチャＩＤを除くことによって、ＰＰＳにおいて示されてよい。

【0115】

ステップ１００５で、第１スライスのスライスアドレスは、識別子及びスライスアドレスの長さに基づいてスライスヘッダから決定される。例えば、ＰＰＳからの長さは、スライスヘッダからスライスアドレスを解釈するためのビット境界を決定するために用いられ得る。識別子及びスライスアドレスは、次いで、ピクチャに基づいた位置からサブピクチャに基づいた位置へスライスアドレスをマッピングするために用いられ得る。例として、ピクチャに基づいた位置とサブピクチャに基づいた位置との間のマッピングは、スライスヘッダをサブピクチャにアライメントするために使用されてよい。これは、デコーダが、エンコーダ及び／又はスライサでスライスヘッダが書き直される必要なしに、サブビットストリーム抽出によって引き起こされたスライスヘッダとピクチャアドレッシングスキームとの間のアドレス不一致を補償することを可能にする。いくつかの例では、マッピングは、ＳｌｉｃｅＳｕｂｐｉｃＴｏＰｉｃＩｄｘ［ＳｕｂＰｉｃＩｄｘ］［ｓｌｉｃｅ＿ａｄｄｒｅｓｓ］シンタックス要素であってよい。

【0116】

ステップ１００７で、サブビットストリームは、サブピクチャのビデオシーケンスを生成するようデコーディングされ得る。サブピクチャは第１スライスを含んでよい。従って、第１スライスもデコーディングされる。デコーディングされた第１スライスを含むサブピクチャのビデオシーケンスは、次いで、例えば、ヘッドマウントディスプレイ又は他の表示デバイスによる表示のために、転送され得る。

【0117】

図１１は、明示的アドレスシグナリングを用いることによって、ビットストリーム５００及びピクチャ６００などのピクチャのビットストリームから抽出された、サブビットストリーム５０１及びサブピクチャ５２２などのサブピクチャのサブビットストリームを伝送する例示的なシステム１１００の概略図である。システム１１００は、コーデックシステム２００、エンコーダ３００、デコーダ４００、及び／又はビデオコーディングデバイス８００などのエンコーダ及びデコーダによって実装されてよい。更に、システム１１００は、方法１００、９００、及び／又は１０００を実装する場合に用いられてもよい。

【0118】

システム１１００は、ビデオエンコーダ１１０２を含む。ビデオエンコーダ１１０２は、第１スライスを含む複数のスライスを有するピクチャをビットストリームの中にエンコーディングし、第１スライスのスライスアドレスを含むスライスヘッダをビットストリームの中にエンコーディングし、第１スライスの識別子及びスライスアドレスの長さを含むＰＰＳをビットストリームの中にエンコーディングするエンコーディングモジュール１１０１を有する。ビデオエンコーダ１１０２は、スライスヘッダを書き直さずに、第１スライスのスライスアドレス、スライスアドレスの長さ、及び識別子に基づいて第１スライスを抽出することによって、ビットストリームのサブビットストリームを抽出する抽出モジュール１１０３を更に有する。ビデオエンコーダ１１０２は、デコーダへ向けた通信のためにサブビットストリームを記憶する記憶モジュール１１０５を更に有する。ビデオエンコーダ１１０２は、スライスヘッダ、ＰＰＳ、第１スライス、及び／又は対応するサブピクチャを含むサブビットストリームをデコーダに向けで伝送する伝送モジュール１１０７を更に有する。ビデオエンコーダ１１０２は、方法９００のステップのいずれかを実行するよう更に構成されてもよい。

【0119】

システム１１００はまた、ビデオデコーダ１１１０も含む。ビデオデコーダ１１１０は、第１スライスを含む複数のスライスにパーティション化されたピクチャのサブピクチャと、ピクチャ及びサブピクチャに関連したＰＰＳと、第１スライスに関連したスライスヘッダとを含むサブビットストリームを受信する受信モジュール１１１１を有する。ビデオデコーダ１１１０は、第１スライスの識別子及びスライスアドレスの長さを取得するようＰＰＳをパースするパージングモジュール１１１３を更に有する。ビデオデコーダ１１１０は、識別子及びスライスアドレスの長さに基づいてスライスヘッダから第１スライスのスライスアドレスを決定する決定モジュール１１１５を更に有する。ビデオデコーダ１１１０は、第１スライスを含むサブピクチャのビデオシーケンスを生成するようサブビットストリームをデコーディングするデコーディングモジュール１１１７を更に有する。ビデオデコーダ１１１０は、表示のためにサブピクチャのビデオシーケンスを転送する転送モジュール１１１９を更に有する。ビデオデコーダ１１１０は、方法１０００のステップのいずれかを実行するよう更に構成されてもよい。

【0120】

第１コンポーネントと第２コンポーネントとの間のライン、トレース、又は他の媒体を除いて、介在するコンポーネントがない場合に、第１コンポーネントは第２コンポーネントへ直接に結合される。第１コンポーネントと第２コンポーネントとの間にライン、トレース、又は他の媒体以外の他の介在するコンポーネントがある場合に、第１コンポーネントは第２コンポーネントへ間接的に結合される。「結合される」との用語及びその変形は、直接に結合されること及び間接的に結合されることの両方を含む。「約」との用語の使用は、別なふうに述べられない限りは、それに続く数の±１０％を含む範囲を意味する。

【0121】

ここで説明されている例示的な方法のステップは、必ずしも、記載されている順序で実行される必要はないことが理解されるべきであり、そのような方法のステップの順序は、単なる例示にすぎないと理解されるべきである。同様に、そのような方法には追加のステップが含まれてもよく、特定のステップは、本開示の様々な実施形態に従う方法において、削除又は結合されてもよい。

【0122】

いくつかの実施形態が本開示で提供されているが、開示されているシステム及び方法は、本開示の精神又は範囲から逸脱せずに、多数の他の具体的な形態で具現されてよいことが理解され得る。本例は、限定としてではなく実例として見なされるべきであり、意図は、ここで与えられている詳細に限定されるべきではない。例えば、様々な要素又はコンポーネントは、他のシステムに結合又は統合されてよく、あるいは、特定の特徴は省略されても又は実施されなくてもよい。

【0123】

更に、別個又は別々なものとして様々な実施形態で記載及び例示されている技術、システム、サブシステム、及び方法は、本開示の範囲から外れずに、他のシステム、コンポーネント、技術、又は方法と結合又は統合されてもよい。変更、置換、及び代替の他の例は、当業者によって確かめられ、ここで開示されている精神及び範囲から逸脱せずに行われ得る。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】