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

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

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

(11)【特許番号】

(24)【登録日】2023-11-02

(45)【発行日】2023-11-13

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

(51)【国際特許分類】

   H04N 19/503 20140101AFI20231106BHJP

   H04N 19/169 20140101ALI20231106BHJP

   H04N 19/174 20140101ALI20231106BHJP

   H04N 19/177 20140101ALI20231106BHJP

【ＦＩ】

H04N19/503

H04N19/169 200

H04N19/174

H04N19/177

【請求項の数】 22

(21)【出願番号】P 2021539073

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

(65)【公表番号】

(43)【公表日】2022-03-15

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

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

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

【審査請求日】2021-08-27

(31)【優先権主張番号】62/788,634

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

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

【前置審査】

(73)【特許権者】

【識別番号】503433420

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

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

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

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

(72)【発明者】

【氏名】ワン，イエクォイ

【審査官】久保 光宏

(56)【参考文献】

【文献】特表２０２２－５０１９１５（ＪＰ，Ａ）

【文献】大久保 榮 監修，「インプレス標準教科書シリーズ H.265/HEVC教科書」，初版，日本，株式会社インプレスジャパン，2013年10月21日，第１９２～２１４頁，ISBN: 978-4-8443-3468-2.

【文献】亀山 渉（外１名）監修，「インプレス標準教科書シリーズ ＩＰＴＶ時代のデジタル放送教科書」，初版，日本，株式会社インプレスＲ＆Ｄ，2010年04月01日，第１４７～１５１頁，ISBN: 978-4-8443-2853-7.

【文献】Ye-Kui Wang, et al.，"AHG17: On mixed NAL unit types within a picture"，Document: JVET-P0124-v1, [online]，JVET-P0124 (version 1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2019年09月25日，Pages 1-3，[令和4年9月15日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=7913> and <URL: https://jvet-experts.org/doc_end_user/documents/16_Geneva/wg11/JVET-P0124-v1.zip>.

【文献】Ye-Kui Wang, et al.，"AHG17: On header parameter set (HPS)"，Document: JVET-M0132-v1, [online]，JVET-M0132 (version 1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2019年01月02日，Pages 1-4，[令和4年9月15日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=4937> and <URL: https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M0132-v1.zip>.

【文献】Rickard Sjoberg, et al.，"HLS: Error robust POC alignment"，Document: JCTVC-O0176v3, [online]，JCTVC-O0176 (version 3)，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2013年10月28日，Pages 1-8，[令和4年9月15日検索], インターネット, <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=8291> and <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/documents/15_Geneva/wg11/JCTVC-O0176-v3.zip>.

【文献】Ye-Kui Wang, et al.，"AHG17: On NAL unit types for IRAP pictures and leading pictures"，Document: JVET-M0131-v1, [online]，JVET-M0131 (version 1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2019年01月02日，Pages 1-3，[令和4年9月15日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=4936> and <URL: https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M0131-v1.zip>.

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

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

ＣＳＤＢ（日本国特許庁）

学術文献等データベース（日本国特許庁）

ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）

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

【請求項1】

ビデオデコーダによって実施されるコーディングしたビデオビットストリームを復号化する方法であって、当該方法は、
前記ビデオデコーダの受信機が、第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャのコーディングしたデータを含む前記コーディングしたビデオビットストリームを受信するステップであって、前記第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰピクチャである、受信するステップと、
前記受信機が、前記コーディングしたデータから前記第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）を取得するステップと、
前記ビデオデコーダのプロセッサが、前記ＲＰＬを使用して前記第２のサブピクチャを復号化するステップと、
前記プロセッサが、復号化した前記第２のサブピクチャに基づいて前記混合ＩＲＡＰピクチャを生成するステップと、を含む、
方法。

【請求項2】

前記混合ＩＲＡＰピクチャの前記コーディングしたデータは、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームで受信される、請求項１に記載の方法。

【請求項3】

前記第１のサブピクチャは、第１のサブビットストリームに配置され、前記第２のサブピクチャは、第２のサブビットストリームに配置される、請求項１に記載の方法。

【請求項4】

前記ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである、請求項１乃至３のいずれか一項に記載の方法。

【請求項5】

前記第１のサブピクチャは、第１のネットワーク抽象化レイヤ（ＮＡＬ）ユニットのセット内に含まれるＩＲＡＰピクチャであり、前記第２のサブピクチャは、第２のＮＡＬユニットのセット内に含まれる非ＩＲＡＰサブピクチャである、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記ビットストリームにフラグがあり、該フラグは、前記ビットストリームに任意の混合ＩＲＡＰピクチャが含まれるかどうかを示す、請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記フラグは、前記ビットストリームのピクチャパラメータセット（ＰＰＳ）内にある、請求項６に記載の方法。

【請求項8】

前記ＩＲＡＰピクチャは、クリーンランダムアクセス（ＣＲＡ）ピクチャである、請求項１乃至３或いは５乃至７のいずれか一項に記載の方法。

【請求項9】

ビデオエンコーダによって実施されるビデオビットストリームを符号化する方法であって、当該方法は、
混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャの第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）を取得するステップであって、前記混合ＩＲＡＰピクチャは第１のサブピクチャをさらに含み、該第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰサブピクチャである、取得するステップと、
前記ビデオエンコーダのプロセッサが、前記混合ＩＲＡＰピクチャをコーディングした前記ビデオビットストリーム内に符号化するステップと、
プロセッサが、前記ＲＰＬを前記コーディングしたビデオビットストリーム内に符号化するステップと、を含む、
方法。

【請求項10】

ビデオデコーダに向けて送信するための前記ビットストリームを前記ビデオエンコーダのメモリに格納するステップをさらに含む、請求項９に記載の方法。

【請求項11】

復号化装置であって、当該復号化装置は、
受信機と、
該受信機に結合されるメモリと、
該メモリに結合されるプロセッサと、を含み、
前記受信機は、
第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャのコーディングしたデータと、
前記第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）のコーディングしたデータと、を含むコーディングしたビデオビットストリームを受信するように構成され、前記第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰピクチャであり、
前記メモリは命令を格納し、
前記プロセッサは、前記命令を実行して当該復号化装置に、
前記ＲＰＬを使用して前記第２のサブピクチャを復号化すること、及び
復号化した前記第２のサブピクチャに基づいて前記混合ＩＲＡＰピクチャを生成すること、を行わせるように構成される、
復号化装置。

【請求項12】

画像を表示するように構成されるディスプレイをさらに含む、請求項１１に記載の復号化装置。

【請求項13】

符号化装置であって、当該符号化装置は、
命令を含むメモリと、
該メモリに結合されるプロセッサと、を含み、
該プロセッサは、前記命令を実行して当該符号化装置に、
混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャの第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）を取得することであって、前記混合ＩＲＡＰピクチャは第１のサブピクチャをさらに含み、該第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰサブピクチャである、取得すること、
前記混合ＩＲＡＰピクチャをコーディングしたビデオビットストリーム内に符号化することと、
前記ＲＰＬを前記コーディングしたビデオビットストリーム内に符号化すること、を行わせるように構成される、
符号化装置。

【請求項14】

前記プロセッサは、前記命令を実行して当該符号化装置に、ビデオデコーダに向けて送信するための前記ビットストリームを前記メモリに格納すること、を行わせるようにさらに構成される、請求項１３に記載の符号化装置。

【請求項15】

前記プロセッサに結合される送信機をさらに含み、該送信機は、前記ビットストリームをビデオデコーダに向けて送信するように構成される、請求項１３に記載の符号化装置。

【請求項16】

コーディング機器であって、当該コーディング機器は、
符号化すべきピクチャを受信する、又は復号化すべきビットストリームを受信するように構成される受信機と、
該受信機に結合される送信機であって、前記ビットストリームをデコーダに送信する、又は復号化した画像をディスプレイに送信するように構成される送信機と、
前記受信機又は前記送信機の少なくとも一方に結合されるメモリであって、命令を格納するように構成されるメモリと、
該メモリに結合されるプロセッサであって、前記メモリに格納された前記命令を実行して、請求項１乃至８のいずれか一項に記載の前記方法或いは請求項９又は１０に記載の前記方法を実行するように構成されるプロセッサと、を含む、
コーディング機器。

【請求項17】

システムであって、当該システムは、
エンコーダと、
該エンコーダと通信するデコーダと、を含み、
前記エンコーダ又は前記デコーダは、請求項１１又は１２に記載の前記復号化装置、請求項１３乃至１５のいずれか一項に記載の前記符号化装置、又は請求項１６に記載の前記コーディング機器を含む、
システム。

【請求項18】

デコーダであって、当該デコーダは、
第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャのコーディングしたデータを含むコーディングしたビデオビットストリームを受信するように構成された受信ユニットであって、前記第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰピクチャである、受信ユニットと、
前記コーディングしたデータから前記第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）を取得するように構成された取得ユニットと、
前記ＲＰＬを使用して前記第２のサブピクチャを復号化するように構成された復号化ユニットと、
復号化した前記第２のサブピクチャに基づいて前記混合ＩＲＡＰピクチャを生成するように構成された生成ユニットと、を含む、
デコーダ。

【請求項19】

エンコーダであって、当該エンコーダは、
混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャの第２のサブピクチャの参照ピクチャリスト（ＲＰＬ）を取得するように構成された取得ユニットであって、前記混合ＩＲＡＰピクチャは第１のサブピクチャをさらに含み、該第１のサブピクチャはＩＲＡＰピクチャであり、前記第２のサブピクチャは非ＩＲＡＰサブピクチャである、取得ユニットと、
前記混合ＩＲＡＰピクチャ及び前記ＲＰＬをコーディングしたビデオビットストリーム内に符号化するように構成された符号化ユニットと、を含む、
エンコーダ。

【請求項20】

請求項１乃至１０のいずれか一項に記載の前記方法を実行するための処理回路を含むコーダ。

【請求項21】

コンピュータ又はプロセッサ上で実行されたときに、請求項１乃至１０のいずれか一項に記載の前記方法を実行するためのプログラムコードを含むコンピュータプログラム。

【請求項22】

コンピュータ装置によって実行されると、該コンピュータ装置に請求項１乃至１０のいずれか一項に記載の前記方法を実行させるプログラムコードを保持する非一時的なコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

概して、本開示は、ビデオコーディングにおけるサブピクチャベースのランダムアクセスをサポートするための技術を説明する。より具体的には、本開示は、ピクチャが、イントラ・ランダムアクセスポイントとして識別される１つ又は複数の領域と、同時に、非イントラ・ランダムアクセスポイントとして識別される残りの領域とを含むことを可能にするための技術を説明する。

【背景技術】

【0002】

比較的短いビデオでさえ描写するのに必要なビデオデータの量はかなりの量になる可能性があり、これは、帯域幅容量が限られた状況の通信ネットワークを介してデータをストリーミング又は他に通信するときに困難性を生じさせる可能性がある。こうして、ビデオデータは、現代の電気通信ネットワークを介して通信される前に通常圧縮される。ビデオを記憶装置に格納する場合に、メモリリソースが制限され得るため、ビデオのサイズも問題になる可能性がある。ビデオ圧縮装置は、大抵の場合、送信又は格納の前にビデオデータをコーディングするために送信元（source：ソース）でソフトウェア及び／又はハードウェアを使用し、それによりデジタルビデオ画像を表すために必要なデータの量を減らす。次に、圧縮したデータは、宛先（destination：送信先）でビデオデータを復号化するビデオ解凍装置によって受信される。ネットワークリソースが限られており、より高いビデオ品質に対する要求が益々高まっているため、画質を殆ど又は全く犠牲にすることなく圧縮率を高める改善した圧縮及び解凍技術が望まれている。

【発明の概要】

【0003】

第１の態様は、ビデオデコーダによって実施されるコーディングしたビデオビットストリームを復号化する方法に関する。この方法は、ビデオデコーダの受信機が、第１のサブピクチャ（sub-picture）及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャを受信するステップであって、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャである、受信するステップと；受信機が、混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）を受信するステップと；ビデオデコーダのプロセッサが、ＲＰＬを使用して第２のサブピクチャを復号化するステップと；プロセッサが、復号化した第２のサブピクチャに基づいて画像（image）を生成するステップと；を含む。

【0004】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示する技術は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0005】

第１の態様自体による方法の第１の実施態様では、混合ＩＲＡＰピクチャは、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームで受信される。

【0006】

第１の態様自体による方法の第２の実施態様、又は第１の態様の任意の先行する実施態様では、第１のサブピクチャは、第１のサブビットストリームに配置され、第２のサブピクチャは、第２のサブビットストリームに配置される。

【0007】

第１の態様自体による方法の第３の実施態様、又は第１の態様の任意の先行する実施態様では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。

【0008】

第１の態様自体による方法の第４の実施態様、又は第１の態様の任意の先行する実施態様では、第１のサブピクチャは、第１のネットワーク抽象化レイヤ（ＮＡＬ）ユニット内に含まれるＩＲＡＰピクチャであり、第２のサブピクチャは、第２のＮＡＬユニット内に含まれる非ＩＲＡＰサブピクチャである。

【0009】

第１の態様自体による方法の第５の実施態様、又は第１の態様の任意の先行する実施態様では、方法は、ビットストリーム内のフラグを受信するステップをさらに含み、フラグは、ビットストリームに任意の混合ＩＲＡＰピクチャが含まれるかどうかを示す。

【0010】

第１の態様自体による方法の第６の実施態様、又は第１の態様の任意の先行する実施態様では、フラグは、ビットストリームのシーケンスパラメータセット（ＳＰＳ）内にある。

【0011】

第１の態様自体による方法の第７の実施態様、又は第１の態様の任意の先行する実施態様では、フラグは、sps_mixed_tile_groups_in_pic_flagと指定される。

【0012】

第２の態様は、ビデオエンコーダによって実施されるビデオビットストリームを符号化する方法に関する。この方法は、ビデオエンコーダのプロセッサが、第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャを符号化するステップであって、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャである、符号化するステップと；プロセッサが、混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）を符号化するステップと；プロセッサが、混合ＩＲＡＰピクチャ及び混合ＩＲＡＰピクチャに対応するＲＰＬを含むビットストリームを生成するステップと；ビデオデコーダに向けて送信するためのビットストリームをビデオエンコーダのメモリに格納するステップと；を含む。

【0013】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示する技術は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0014】

第２の態様自体による方法の第１の実施態様では、混合ＩＲＡＰピクチャは、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームに符号化される。

【0015】

第２の態様自体による方法の第２の実施態様、又は第２の態様の任意の先行する実施態様では、第１のサブピクチャは、第１のサブビットストリームに符号化され、第２のサブピクチャは、第２のサブビットストリームに符号化される。

【0016】

第２の態様自体による方法の第３の実施態様、又は第２の態様の任意の先行する実施態様では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。

【0017】

第２の態様自体による方法の第４の実施態様、又は第２の態様の任意の先行する実施態様では、第１のサブピクチャは、第１のネットワーク抽象化レイヤ（ＮＡＬ）ユニット内に含まれるＩＲＡＰピクチャであり、第２のサブピクチャは、第２のＮＡＬユニット内に含まれる非ＩＲＡＰサブピクチャである。

【0018】

第２の態様自体による方法の第５の実施態様、又は第２の態様の任意の先行する実施態様では、方法は、ビットストリーム内でフラグを符号化するステップをさらに含み、フラグは、ビットストリームに任意の混合ＩＲＡＰピクチャが含まれるかどうかを示す。

【0019】

第２の態様自体による方法の第６の実施態様、又は第２の態様の任意の先行する実施態様では、フラグは、ビットストリームのシーケンスパラメータセット（ＳＰＳ）内にある。

【0020】

第２の態様自体による方法の第７の実施形態、又は第２の態様の任意の先行する実施態様では、フラグは、sps_mixed_tile_groups_in_pic_flagと指定される。

【0021】

第３の態様は、復号化装置に関する。復号化装置は、受信機と；受信機に結合されるメモリと；メモリに結合されるプロセッサと；を含み、受信機は、第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャと、混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）とを含むコーディングしたビデオビットストリームを受信するように構成され、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャであり、メモリは命令を格納し、プロセッサは、命令を実行して復号化装置に、ＲＰＬを使用して第２のサブピクチャを復号化すること、及び復号化した第２のサブピクチャに基づいて画像を生成すること、を行わせるように構成される。

【0022】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示する復号化装置は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0023】

第３の態様自体による復号化装置の第１の実施態様では、復号化装置は、画像を表示するように構成されるディスプレイをさらに含む。

【0024】

第３の態様自体による復号化装置の第２の実施態様、又は第３の態様の任意の先行する実施態様では、受信機は、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームで混合ＩＲＡＰピクチャを受信するように構成される。

【0025】

第３の態様自体による復号化装置の第３の実施態様、又は第３の態様の任意の先行する実施態様では、第１のサブピクチャは、第１のサブビットストリームに配置され、第２のサブピクチャは、第２のサブビットストリームに配置される。

【0026】

第３の態様自体による復号化装置の第４の実施態様、又は第３の態様の任意の先行する実施態様では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。

【0027】

第４の態様は、符号化装置に関する。符号化装置は、命令を含むメモリと、メモリに結合されるプロセッサとを含み、プロセッサは、命令を実行して符号化装置に、第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャを符号化することであって、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャである、符号化すること；混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）を符号化すること；混合ＩＲＡＰピクチャ及び混合ＩＲＡＰピクチャに対応するＲＰＬを含むビットストリームを生成すること；及びビデオデコーダに向けて送信するためのビットストリームをメモリに格納すること：を行わせるように構成される。

【0028】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示する符号化装置は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0029】

第４の態様自体による符号化装置の第１の実施態様では、符号化装置は、プロセッサに結合される送信機をさらに含み、送信機は、ビットストリームをビデオデコーダに向けて送信するように構成される。

【0030】

第４の態様自体による符号化装置の第２の実施態様では、混合ＩＲＡＰピクチャは、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームに符号化される。

【0031】

第４の態様自体による符号化装置の第３の実施態様では、第１のサブピクチャは、第１のサブビットストリームで符号化され、第２のサブピクチャは、第２のサブビットストリームで符号化される。

【0032】

第４の態様自体による符号化装置の第４の実施態様では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。

【0033】

第５の態様は、コーディング機器に関する。コーディング機器は、符号化すべきピクチャを受信する、又は復号化すべきビットストリームを受信するように構成される受信機と；受信機に結合される送信機であって、ビットストリームをデコーダに送信する、又は復号化した画像をディスプレイに送信するように構成される送信機と；受信機又は送信機の少なくとも一方に結合されるメモリであって、命令を格納するように構成されるメモリと；メモリに結合されるプロセッサであって、メモリに格納された命令を実行して、本明細書に記載の方法を実行するように構成されるプロセッサと；を含む。

【0034】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示するコーディング機器は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0035】

第６の態様は、システムに関する。システムは、エンコーダと、エンコーダと通信するデコーダと、を含み、エンコーダ又はデコーダは、本明細書で開示する復号化装置、符号化装置、又はコーディング機器を含む。

【0036】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書で開示するシステムは、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0037】

第７の態様は、コーディングのための手段に関する。コーディングのための手段は、復号化すべきビットストリームを受信するように構成される受信手段と；受信手段に結合される送信手段であって、復号化した画像を表示手段に送信するように構成される送信手段と；受信手段又は送信手段の少なくとも一方に結合される記憶手段であって、命令を記憶するように構成される記憶手段と；記憶手段に結合される処理手段であって、記憶手段に記憶された命令を実行して、本明細書で開示する方法を実行するように構成された処理手段と；を含む。

【0038】

従来のコーディング技術は、ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容しないが、本明細書に開示するコーディングのための手段は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容する。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これは、ＶＲコーディングアプリケーションで特に有益である。そのため、ビデオコーディングのコーダ／デコーダ（別名「コーデック」）は、現在のコーデックに比べて改善される。実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【0039】

第８の態様は、復号化装置に関する。復号化装置は、コーディングしたビデオビットストリームを受信するように構成される受信機と；受信機に結合されるプロセッサと；を含み、プロセッサは、コーディングしたビデオビットストリーム内のフラグを解析することであって、フラグの値は、コーディングしたビデオビットストリーム内のピクチャが混合ネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプを含むことを示す、解析すること；フラグの値に基づいて、ピクチャを非イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャとして復号化すること；及び復号化したピクチャに基づいて画像を生成すること；を行うように構成される。

【0040】

本明細書で開示する復号化装置によって、復号化装置が、コーディングしたビデオビットストリーム内のどのピクチャに混合ネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプが含まれるかを識別するのを可能にする。つまり、復号化装置は、コーディングしたビデオビットストリーム内のフラグを解析して、ピクチャに混合ＮＡＬユニットタイプが含まれていることを特定するように構成される。ピクチャがＩＲＡＰ ＮＡＬユニットタイプを含む場合でも、ピクチャは、フラグの値に基づいて非ＩＲＡＰピクチャとして復号化される。

【0041】

第８の態様自体による符号化装置の第１の実施態様では、ピクチャがＩＲＡＰ ＮＡＬユニットタイプを含む場合に、ピクチャは非ＩＲＡＰピクチャとして復号化される。

【0042】

第８の態様自体による符号化装置の第２の実施態様では、フラグの値は１である。

【0043】

実際には、改善したビデオコーディングプロセスは、ビデオを送信、受信、及び／又は表示するときにより良いユーザ体験をユーザに提供する。

【図面の簡単な説明】

【0044】

本開示のより完全な理解のために、ここで、添付の図面及び詳細な説明に関連して解釈される以下の簡単な説明が参照され、同様の参照番号は同様の部分を表す。

【図1】双方向予測技術を利用することができる例示的なコーディングシステムを示すブロック図である。

【図2】双方向予測技術を実施することができる例示的なビデオエンコーダを示すブロック図である。

【図3】双方向予測技術を実施することができるビデオデコーダの一例を示すブロック図である。

【図4】エントリがＲＰＳの全てのサブセットにある現在のピクチャを有する参照ピクチャセット（ＲＰＳ）を示す概略図である。

【図5】ＶＲコーディングアプリケーションでの使用に適したピクチャの一実施形態の概略図である。

【図6】図５のピクチャに対応するビデオビットストリームの一実施形態の概略図である。

【図7】コーディングしたビデオビットストリームを復号化する方法の一実施形態である。

【図8】ビデオビットストリームを符号化する方法の一実施形態である。

【図9】ビデオコーディング装置の概略図である。

【図10】コーディングするための手段の一実施形態の概略図である。

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

【0045】

以下は、本明細書で使用する様々な略語：コーディングしたビデオシーケンス（ＣＶＳ）、復号化したピクチャバッファ（ＤＰＢ）、瞬時復号化リフレッシュ（ＩＤＲ）、イントラ・ランダムアクセスポイント（ＩＲＡＰ）、最下位ビット（ＬＳＢ）、最上位ビット（ＭＳＢ）、ネットワーク抽象化レイヤ（ＮＡＬ）、ピクチャ順序カウント（ＰＯＣ）、ＲＢＳＰ（Raw Byte Sequence Payload）、シーケンスパラメータセット（ＳＰＳ）、及び作業文書（ＷＤ）である。

【0046】

図１は、本明細書で説明するようなビデオコーディング技術を利用することができる例示的なコーディングシステム１０を示すブロック図である。図１に示されるように、コーディングシステム１０は、送信元装置１２を含み、送信元装置１２は、宛先装置１４によって後で復号化される符号化ビデオデータを提供する。特に、送信元装置１２は、コンピュータ可読媒体１６を介してビデオデータを宛先装置１４に提供することができる。送信元装置１２及び宛先装置１４は、デスクトップコンピュータ、ノートブック（例えば、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォン等の電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、表示装置、デジタルメディアプレイヤ、ビデオゲームコンソール、ビデオストリーミング装置等を含む広範囲の装置のいずれかを含み得る。場合によっては、送信元装置１２及び宛先装置１４は、無線通信のために装備され得る。

【0047】

宛先装置１４は、コンピュータ可読媒体１６を介して復号化すべき符号化ビデオデータを受信することができる。コンピュータ可読媒体１６は、符号化ビデオデータを送信元装置１２から宛先装置１４に移動させることができる任意のタイプの媒体又は装置を含み得る。一例では、コンピュータ可読媒体１６は、送信元装置１２が符号化ビデオデータを宛先装置１４にリアルタイムで直接送信するのを可能にする通信媒体を含み得る。符号化ビデオデータは、無線通信プロトコル等の通信規格に従って変調され、宛先装置１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトル或いは１つ又は複数の物理的な伝送ライン等の、任意の無線又は有線通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネットのようなグローバルネットワーク等のパケットベースのネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、又は送信元装置１２から宛先装置１４への通信を容易にするのに役立ち得る任意の他の機器を含み得る。

【0048】

いくつかの例では、符号化データは、出力インターフェイス２２から記憶装置に出力され得る。同様に、符号化データは、入力インターフェイスによって記憶装置からアクセスされ得る。記憶装置には、ハードドライブ、Ｂｌｕ－ｒａｙディスク、デジタルビデオディスク（ＤＶＤ）、コンパクトディスク読取り専用メモリ（ＣＤ－ＲＯＭ）、フラッシュメモリ、揮発性又は不揮発性メモリ、又は符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体等、様々な分散型又はローカルアクセス型のデータ記憶媒体のいずれかが含まれ得る。更なる例では、記憶装置は、送信元装置１２によって生成された符号化したビデオを記憶し得るファイルサーバ又は別の中間記憶装置に対応し得る。宛先装置１４は、ストリーミング又はダウンロードを介して記憶装置から記憶したビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを格納し、その符号化ビデオデータを宛先装置１４に送信することができる任意のタイプのサーバであり得る。ファイルサーバの例には、（例えば、ウェブサイトのための）ウェブサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、ネットワーク接続ストレージ（ＮＡＳ）装置、又はローカルディスクドライブが含まれる。宛先装置１４は、インターネット接続を含む任意の標準データ接続を介して、符号化ビデオデータにアクセスすることができる。これには、無線チャネル（例えば、Ｗｉ－Ｆｉ接続）、有線接続（例えば、デジタル加入者線（ＤＳＬ）、ケーブルモデム等）、又はファイルサーバに格納した符号化ビデオデータへのアクセスに適した両方の組合せが含まれ得る。記憶装置からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、又はこれらの組合せであり得る。

【0049】

本開示の技術は、必ずしも無線アプリケーション又は設定に限定されない。この技術は、地上波テレビ放送、ケーブルテレビ送信、衛星テレビ送信、ＨＴＴＰを介した動的適応ストリーミング（ＤＡＳＨ）等のインターネットストリーミングビデオ送信、データ記憶媒体上に符号化したデジタルビデオ、データ記憶媒体に記憶したデジタルビデオの復号化、又は他のアプリケーション等、様々なマルチメディアアプリケーションのいずれかをサポートするビデオコーディングに適用できる。いくつかの例では、コーディングシステム１０は、ビデオストリーミング、ビデオ再生、ビデオ放送、及び／又はテレビ電話等のアプリケーションをサポートするために、一方向又は双方向のビデオ送信をサポートするように構成され得る。

【0050】

図１の例では、送信元装置１２は、ビデオソース１８、ビデオエンコーダ２０、及び出力インターフェイス２２を含む。宛先装置１４は、入力インターフェイス２８、ビデオデコーダ３０、及び表示装置３２を含む。本開示によれば、送信元装置１２のビデオエンコーダ２０及び／又は宛先装置１４のビデオデコーダ３０は、ビデオコーディングのための技術を適用するように構成され得る。他の例では、送信元装置及び宛先装置は、他のコンポーネント又は構成を含み得る。例えば、送信元装置１２は、外部カメラ等の外部ビデオソースからビデオデータを受信することができる。同様に、宛先装置１４は、統合した表示装置を含むのではなく、外部表示装置とインターフェイスすることができる。

【0051】

図１の図示するコーディングシステム１０は、単なる一例である。ビデオコーディングの技術は、任意のデジタルビデオ符号化及び／又は復号化装置によって実行することができる。本開示の技術は、概して、ビデオコーディング装置によって実行されるが、この技術は、典型的には「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。さらに、本開示の技術は、ビデオ・プリプロセッサによっても実行され得る。ビデオエンコーダ及び／又はデコーダは、グラフィックス処理装置（ＧＰＵ）又は同様の装置であり得る。

【0052】

送信元装置１２及び宛先装置１４は、送信元装置１２がコーディングしたビデオデータを生成して宛先装置１４に送信する、そのようなコーディング装置の単なる例である。いくつかの例では、送信元装置１２及び宛先装置１４は、送信元装置及び宛先装置１２、１４のそれぞれがビデオ符号化及び復号化コンポーネントを含むように、実質的に対称に動作し得る。このため、コーディングシステム１０は、例えば、ビデオストリーミング、ビデオ再生、ビデオ放送、又はテレビ電話のために、ビデオ装置１２、１４の間の一方向又は双方向のビデオ送信をサポートすることができる。

【0053】

送信元装置１２のビデオソース１８は、ビデオカメラ等のビデオ取込み装置、以前に取り込んだビデオを含むビデオアーカイブ、及び／又はビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェイスを含み得る。更なる代替として、ビデオソース１８は、ソースビデオとして、又はライブビデオ、アーカイブ化したビデオ、及びコンピュータで生成したビデオの組合せとして、コンピュータグラフィックスベースのデータを生成することができる。

【0054】

場合によっては、ビデオソース１８がビデオカメラである場合に、送信元装置１２及び宛先装置１４は、いわゆるカメラ付き携帯電話又はビデオ電話を形成し得る。しかしながら、上述したように、本開示で説明する技術は、概して、ビデオコーディングに適用可能であり得、そして無線及び／又は有線アプリケーションに適用され得る。いずれの場合にも、取り込んだ、予め取り込んだ、又はコンピュータで生成したビデオは、ビデオエンコーダ２０によって符号化され得る。次に、符号化したビデオ情報は、出力インターフェイス２２によってコンピュータ可読媒体１６に出力され得る。

【0055】

コンピュータ可読媒体１６は、無線放送又は有線ネットワーク送信等の一時的な媒体、又はハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Ｂｌｕ－ｒａｙディスク、又は他のコンピュータ可読媒体等の記憶媒体（すなわち、非一時的な記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、送信元装置１２から符号化ビデオデータを受信し、符号化ビデオデータを例えばネットワーク送信を介して宛先装置１４に提供することができる。同様に、ディスクスタンピング設備等の媒体生産設備のコンピューティング装置は、送信元装置１２から符号化ビデオデータを受信し、符号化ビデオデータを含むディスクを生成することができる。従って、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つ又は複数のコンピュータ可読媒体を含むと理解され得る。

【0056】

宛先装置１４の入力インターフェイス２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ブロック及び他のコーディングしたユニット、例えばピクチャ（picture）のグループ（ＧＯＰ）の特性及び／又は処理を記述する構文要素を含む、ビデオエンコーダ２０によって規定される構文情報を含み得、この構文情報はビデオデコーダ３０によっても使用される。表示装置３２は、復号化ビデオデータをユーザに表示し、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＤＣ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、又は別のタイプの表示装置等の様々な表示装置のいずれかを含み得る。

【0057】

ビデオエンコーダ２０及びビデオデコーダ３０は、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格等のビデオコーディング規格に従って動作することができ、ＨＥＶＣテストモデル（ＨＭ）に準拠することができる。あるいはまた、ビデオエンコーダ２０及びビデオデコーダ３０は、国際電気通信連合電気通信標準化セクタ（ＩＴＵ－Ｔ）Ｈ．２６４規格、あるいはまたＭＰＥＧ（Moving Picture Expert Group）４、パート１０、ＡＶＣ（Advanced
Video Coding）、Ｈ．２６５／ＨＥＶＣと呼ばれる他の独占技術（proprietary）又は工業規格、又はそのような規格等の拡張に従って動作することができる。しかしながら、本開示の技術は、任意の特定のコーディング規格に限定されない。ビデオコーディング規格の他の例には、ＭＰＥＧ－２及びＩＴＵ－Ｔ Ｈ．２６３が含まれる。図１には示されないが、いくつかの態様では、ビデオエンコーダ２０及びビデオデコーダ３０はそれぞれオーディオエンコーダ及びデコーダと統合され得、共通のデータストリーム又は個別のデータストリームにおいてオーディオとビデオと両方の符号化を処理するために、適切なマルチプレクサ－デマルチプレクサ（ＭＵＸ－ＤＥＭＵＸ）ユニット、又は他のハードウェア及びソフトウェアを含み得る。該当する場合に、ＭＵＸ－ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、又はユーザデータグラムプロトコル（ＵＤＰ）等の他のプロトコルに準拠し得る。

【0058】

ビデオエンコーダ２０及びビデオデコーダ３０はそれぞれ、１つ又は複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組合せ等の様々な適切なエンコーダ回路のいずれかとして実装され得る。技術がソフトウェアで部分的に実装される場合に、装置は、ソフトウェアの命令を適切な非一時的なコンピュータ可読媒体に格納し、１つ又は複数のプロセッサを使用して命令をハードウェアで実行して、本開示の技術を実行することができる。ビデオエンコーダ２０及びビデオデコーダ３０のそれぞれは、１つ又は複数のエンコーダ又はデコーダに含まれ得、それらエンコーダ又はデコーダのいずれかは、それぞれの装置で組み合わされたエンコーダ／デコーダ（コーデック）の一部として統合され得る。ビデオエンコーダ２０及び／又はビデオデコーダ３０を含む装置は、集積回路、マイクロプロセッサ、及び／又は携帯電話等の無線通信装置を含み得る。

【0059】

図２は、ビデオコーディング技術を実施することができるビデオエンコーダ２０の一例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラ（intra）コーディング及びインター（inter）コーディングを実行することができる。イントラコーディングは、空間的予測に依拠して、所与のビデオフレーム又はピクチャ内のビデオの空間的冗長性を低減又は除去する。インターコーディングは、時間予測に依拠して、ビデオシーケンスの隣接するフレーム又はピクチャ内のビデオの時間的冗長性を低減又は除去する。イントラモード（Ｉモード）は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向（別名、ユニ予測）予測（Ｐモード）又は双方向予測（別名、バイ予測）（Ｂモード）等のインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。

【0060】

図２に示されるように、ビデオエンコーダ２０は、符号化すべきビデオフレーム内の現在のビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０、参照フレームメモリ６４、加算器（summer）５０、変換処理ユニット５２、量子化ユニット５４、及びエントロピーコーディングユニット５６を含む。次に、モード選択ユニット４０は、動き補償ユニット４４、動き推定ユニット４２、イントラ予測（別名、イントラ予測）ユニット４６、及びパーティションユニット４８を含む。ビデオブロック再構成のために、ビデオエンコーダ２０は、逆量子化ユニット５８、逆変換ユニット６０、及び加算器６２も含む。デブロッキングフィルタ（図２に示されない）を含めて、ブロック境界をフィルタ処理して、再構成したビデオからブロック性アーチファクトを除去することもできる。必要に応じて、デブロッキングフィルタは、典型的に、加算器６２の出力をフィルタ処理するだろう。デブロッキングフィルタに加えて、追加のフィルタ（インループ（in loop）又はポストループ（post loop））を使用してもよい。このようなフィルタは簡潔にするために示してないが、必要に応じて、加算器５０の出力を（インループフィルタとして）フィルタ処理することができる。

【0061】

符号化プロセス中に、ビデオエンコーダ２０は、符号化すべきビデオフレーム又はスライスを受信する。フレーム又はスライスは、複数のビデオブロックに分割され得る。動き推定ユニット４２及び動き補償ユニット４４は、１つ又は複数の参照フレーム内の１つ又は複数のブロックに対して受信したビデオブロックのインター予測コーディングを実行して、時間的予測を提供する。あるいはまた、イントラ予測ユニット４６は、コーディングすべきブロックと同じフレーム又はスライス内の１つ又は複数の隣接するブロックに対して受信したビデオブロックのイントラ予測コーディングを実行して、空間的予測を提供することができる。ビデオエンコーダ２０は、例えば、ビデオデータの各ブロックに対して適切なコーディングモードを選択するために、複数のコーディングパスを実行することができる。

【0062】

さらに、パーティションユニット４８は、以前のコーディングパスにおける以前のパーティション分割スキームの評価に基づいて、ビデオデータのブロックをサブブロックにパーティション分割することができる。例えば、パーティションユニット４８は、最初にフレーム又はスライスを最大のコーディングユニット（ＬＣＵ）にパーティション分割し、レート歪み解析（例えば、レート歪み最適化）に基づいて、ＬＣＵのそれぞれをサブコーディングユニット（サブＣＵ）にパーティション分割することができる。モード選択ユニット４０は、ＬＣＵのサブＣＵへのパーティション分割を示す四分木データ構造をさらに生成することができる。四分木のリーフノードＣＵには、１つ又は複数の予測ユニット（ＰＵ）及び１つ又は複数の変換ユニット（ＴＵ）が含まれ得る。

【0063】

本開示は、「ブロック」という用語を使用して、ＨＥＶＣの文脈におけるＣＵ、ＰＵ、又はＴＵのいずれか、又は他の規格の文脈における同様のデータ構造（例えば、Ｈ．２６４／ＡＶＣにおけるそのマクロブロック及びサブブロック）を指す。ＣＵには、コーディングノード、ＰＵ、及びコーディングノードに関連するＴＵが含まれる。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が正方形である。ＣＵのサイズは、８×８ピクセルから、最大６４×６４ピクセル以上のツリーブロックのサイズまでの範囲になり得る。各ＣＵには、１つ又は複数のＰＵ及び１つ又は複数のＴＵが含まれ得る。ＣＵに関連する構文データは、例えば、ＣＵを１つ又は複数のＰＵにパーティション分割することを記述し得る。パーティション分割モードは、ＣＵがスキップ又は直接モードで符号化されているか、イントラ予測モードで符号化されているか、又はインター予測（別名、インター予測）モードで符号化されているかによって異なる場合がある。ＰＵは、形状が非正方形になるようにパーティション分割され得る。ＣＵに関連する構文データは、例えば、四分木に従ってＣＵを１つ又は複数のＴＵにパーティション分割することも記述し得る。ＴＵは、形状が正方形又は非正方形（例えば、長方形）であり得る。

【0064】

モード選択ユニット４０は、例えば、エラー結果に基づいて、イントラ又はインターコーディングモードの１つを選択して、結果として生じるイントラ又はインターコーディングしたブロックを加算器５０に提供して残余ブロックデータを生成し、及び結果として生じるイントラ又はインターコーディングしたブロックを加算器６２に提供して符号化したブロックを再構成して参照フレームとして使用することができる。モード選択ユニット４０は、動きベクトル、イントラモードインジケータ、パーティション情報、及び他のそのような構文情報等の構文要素を、エントロピー符号化ユニット５６にも提供する。

【0065】

動き推定ユニット４２及び動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、現在のビデオフレーム又はピクチャ内のビデオブロックのＰＵの、現在のフレーム（又は他のコーディングされるユニット）内でコーディングされている現在のブロックに対する参照フレーム（又は他のコーディングされるユニット）内の予測ブロックに対する変位を示し得る。予測ブロックは、ピクセルの差に関して、コーディングすべきブロックと厳密に一致すると見出されたブロックであり、これは、絶対差の合計（ＳＡＤ）、二乗差の合計（ＳＳＤ）、又は他の差メトリックによって決定され得る。いくつかの例では、ビデオエンコーダ２０は、参照フレームメモリ６４に格納された参照ピクチャのサブ整数ピクセル位置の値を計算することができる。例えば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、又は他の分数のピクセル位置値を補間することができる。従って、動き推定ユニット４２は、全ピクセル位置及び分数（fractional）ピクセル位置に対して動き検索を実行し、分数ピクセル精度で動きベクトルを出力することができる。

【0066】

動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングしたスライス内のビデオブロックのＰＵの動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）又は第２の参照ピクチャリスト（リスト１）から選択することができ、それぞれのリストによって参照フレームメモリ６４に格納された１つ又は複数の参照ピクチャを識別する。動き推定ユニット４２が、計算した運動ベクトルをエントロピー符号化ユニット５６及び動き補償ユニット４４に送信する。

【0067】

動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチ又は生成することを含み得る。いくつかの例では、再び、動き推定ユニット４２及び動き補償ユニット４４は、機能的に統合され得る。現在のビデオブロックのＰＵの動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つのリストで指し示す予測ブロックの位置を特定する（locate）ことができる。加算器５０は、以下で議論するように、コーディングしている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を差し引くことによって残余ビデオブロックを形成し、ピクセル差の値を形成する。一般に、動き推定ユニット４２は、ルマ（luma：輝度）成分に対する動き推定を実行し、動き補償ユニット４４は、前記ルマ成分に基づいてクロマ（chroma：色差）成分とルマ成分との両方について計算した動きベクトルを使用する。モード選択ユニット４０は、ビデオスライスのビデオブロックを復号化する際にビデオデコーダ３０によって使用される、ビデオブロック及びビデオスライスに関連する構文要素を生成することもできる。

【0068】

イントラ予測ユニット４６は、上記のように、動き推定ユニット４２及び動き補償ユニット４４によって実行されるインター予測の代替として、現在のブロックをイントラ予測することができる。特に、イントラ予測ユニット４６は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定することができる。いくつかの例では、イントラ予測ユニット４６は、例えば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在のブロックを符号化することができ、イントラ予測ユニット４６（又は、いくつかの例では、モード選択ユニット４０）は、テストしたモードから使用すべき適切なイントラ予測モードを選択することができる。

【0069】

例えば、イントラ予測ユニット４６は、テストした様々なイントラ予測モードのレート歪み解析を使用してレート歪み値を計算し、テストしたモードの中で最良のレート歪み特性を有するイントラ予測モードを選択することができる。レート歪み解析は、一般に、符号化したブロックと、この符号化したブロックを生成するために符号化した元の符号化していないブロックとの間の歪み（又はエラー）の量、及び符号化したブロックを生成するために使用されるビットレート（つまり、ビット数）を決定する。イントラ予測ユニット４６は、様々な符号化したブロックの歪み及びレートから比率を計算して、どのイントラ予測モードがブロックに対して最良のレート歪み値を示すかを決定することができる。

【0070】

さらに、イントラ予測ユニット４６は、深度モデリングモード（ＤＭＭ）を使用して深度マップの深度ブロックをコーディングするように構成され得る。モード選択ユニット４０は、例えば、レート歪み最適化（ＲＤＯ）を使用して、利用可能なＤＭＭモードがイントラ予測モード及び他のＤＭＭモードよりも良好なコーディング結果を生成するかどうかを判定することができる。深度マップに対応するテクスチャ画像のデータは、参照フレームメモリ６４に格納され得る。動き推定ユニット４２及び動き補償ユニット４４は、深度マップの深度ブロックをインター予測するようにも構成され得る。

【0071】

ブロックのイントラ予測モード（例えば、従来のイントラ予測モード又はＤＭＭモードのうちの１つ）を選択した後に、イントラ予測ユニット４６は、ブロックに関して選択したイントラ予測モードを示す情報をエントロピーコーディングユニット５６に提供することができる。エントロピーコーディングユニット５６は、選択したイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ２０は、送信したビットストリーム構成データに含まれ得、この構成データには、複数のイントラ予測モードインデックステーブル及び複数の修正したイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）、様々なブロックの符号化コンテキストの規定、及び各コンテキストに使用する最も可能性の高いイントラ予測モード、イントラ予測モードインデックステーブル、及び修正したイントラ予測モードインデックステーブルの指標を含み得る。

【0072】

ビデオエンコーダ２０は、モード選択ユニット４０からの予測データをコーディングしている元のビデオブロックから差し引くことによって、残余ビデオブロックを形成する。加算器５０は、この減算操作を行う１つ又は複数のコンポーネントを表す。

【0073】

変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）又は概念的に類似した変換等の変換を残余ブロックに適用し、残余変換係数値を含むビデオブロックを生成する。変換処理ユニット５２は、概念的にＤＣＴと同様の他の変換を行うことができる。ウェーブレット変換、整数変換、サブバンド変換、又は他のタイプの変換も使用できる。

【0074】

変換処理ユニット５２は、変換を残余ブロックに適用し、残余変換係数のブロックを生成する。変換は、残余情報をピクセル値ドメインから周波数ドメイン等の変換ドメインに変換することができる。変換処理ユニット５２は、結果として得られた変換係数を量子化ユニット５４に送信することができる。量子化ユニット５４は、変換係数を量子化して、ビットレートをさらに低減する。量子化プロセスは、係数の一部又は全てに関連するビット深度を減らし得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、次に、量子化ユニット５４は、量子化した変換係数を含むマトリックスのスキャンを実行してもよい。あるいはまた、エントロピー符号化ユニット５６がスキャンを実行してもよい。

【0075】

量子化に続いて、エントロピーコーディングユニット５６は、量子化した変換係数をエントロピーコーディングする。例えば、エントロピーコーディングユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、構文ベースのコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率間隔パーティション分割エントロピー（ＰＩＰＥ）コーディング、又は別のエントロピーコーディング技術を実行することができる。コンテキストベースのエントロピーコーディングの場合に、コンテキストは隣接するブロックに基づき得る。エントロピーコーディングユニット５６によるエントロピーコーディングに続いて、符号化したビットストリームは、別の装置（例えば、ビデオデコーダ３０）に送信され得るか、又は後の送信又は検索のためにアーカイブされ得る。

【0076】

逆量子化ユニット５８及び逆変換ユニット６０は、それぞれ、逆量子化及び逆変換を適用して、例えば、後で参照ブロックとして使用するために、残余ブロックをピクセルドメインに再構成する。動き補償ユニット４４は、参照フレームメモリ６４のフレームのうちの１つのフレームの予測ブロックに残余ブロックを追加することによって参照ブロックを計算することができる。動き補償ユニット４４は、１つ又は複数の補間フィルタを再構成した残余ブロックに適用して、動き推定で使用するためのサブ整数ピクセル値を計算することもできる。加算器６２は、再構成した残余ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに追加して、参照フレームメモリ６４に格納するための再構成したビデオブロックを生成する。再構成したビデオブロックは、動き推定ユニット４２及び動き補償ユニット４４によって、後続のビデオフレームでブロックをインターコーディングするための参照ブロックとして使用され得る。

【0077】

図３は、ビデオコーディング技術を実施し得るビデオデコーダ３０の一例を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号化ユニット７０、動き補償ユニット７２、イントラ予測ユニット７４、逆量子化ユニット７６、逆変換ユニット７８、参照フレームメモリ８２、及び加算器８０を含む。いくつかの例では、ビデオデコーダ３０は、ビデオエンコーダ２０（図２）に関して説明した符号化パスと概ね逆の復号化パスを実行する。動き補償ユニット７２は、エントロピー復号化ユニット７０から受信した動きベクトルに基づいて予測データを生成することができる一方、イントラ予測ユニット７４は、エントロピー復号化ユニット７０から受信したイントラ予測モードインジケータに基づいて予測データを生成することができる。

【0078】

復号化プロセス中に、ビデオデコーダ３０は、符号化したビデオスライスのビデオブロック及び関連する構文要素を表す符号化したビデオビットストリームをビデオエンコーダ２０から受信する。ビデオデコーダ３０のエントロピー復号化ユニット７０は、ビットストリームをエントロピー復号化して、量子化した係数、動きベクトル又はイントラ予測モードインジケータ、及び他の構文要素を生成する。エントロピー復号化ユニット７０は、動きベクトル及び他の構文要素を動き補償ユニット７２に転送する。ビデオデコーダ３０は、構文要素をビデオスライスレベル及び／又はビデオブロックレベルで受信することができる。

【0079】

ビデオスライスがイントラコーディングした（Ｉ）スライスとしてコーディングされる場合に、イントラ予測ユニット７４は、信号通知されたイントラ予測モードと、現在のフレーム又はピクチャの以前に復号化したブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックの予測データを生成し得る。ビデオフレームがインターコーディングした（例えば、Ｂ、Ｐ、又はＧＰＢ）スライスとしてコーディングされる場合に、動き補償ユニット７２は、動きベクトルと、エントロピー復号化ユニット７０から受信した他の構文要素とに基づいて、現在のビデオスライスのビデオブロックの予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つのリスト内の参照ピクチャのうちの１つのピクチャから生成され得る。ビデオデコーダ３０は、参照フレームメモリ８２に格納された参照ピクチャに基づくデフォルトの構成技術を使用して、参照フレームリスト、リスト０及びリスト１を構成することができる。

【0080】

動き補償ユニット７２は、動きベクトル及び他の構文要素を解析することによって現在のビデオスライスのビデオブロックの予測情報を決定し、予測情報を使用して、復号化している現在のビデオブロックの予測ブロックを生成する。例えば、動き補償ユニット７２は、受信した構文要素のいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（例えば、イントラ予測又はインター予測）、インター予測スライスタイプ（例えば、Ｂスライス、Ｐスライス、又はＧＰＢスライス）、スライスの１つ又は複数の参照ピクチャリストの構成情報、スライスの各インターコーディングしたビデオブロックの動きベクトル、スライスの各インターコーディングしたビデオブロックのインター予測ステータス、及びビデオブロックを現在のビデオスライスで復号化するための他の情報を決定する。

【0081】

動き補償ユニット７２は、補間フィルタに基づいて補間を行うこともできる。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用される補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算することができる。この場合に、動き補償ユニット７２は、受信した構文要素からビデオエンコーダ２０によって使用される補間フィルタを決定し、補間フィルタを使用して予測ブロックを生成することができる。

【0082】

深度マップに対応するテクスチャ画像のデータは、参照フレームメモリ８２に格納され得る。動き補償ユニット７２は、深度マップの深度ブロックをインター予測するようにも構成され得る。

【0083】

画像及びビデオ圧縮は、急速な成長を経ており、様々なコーディング規格につながっている。このようなビデオコーディング規格には、ＩＴＵ－Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ－１ Ｐａｒｔ２、ＩＴＵ－Ｔ Ｈ．２６２又はＩＳＯ／ＩＥＣ ＭＰＥＧ－２ Ｐａｒｔ２、ＩＴＵ－Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ－４ Ｐａｒｔ２、ＩＴＵ－Ｔ Ｈ．２６４又はＩＳＯ／ＩＥＣ ＭＰＥＧ－４ Ｐａｒｔ１０としても知られるＡＶＣ（Advanced Video Coding）、及びＩＴＵ－Ｔ Ｈ．２６５又はＭＰＥＧ－Ｈ Ｐａｒｔ２としても知られる高効率ビデオコーディング（ＨＥＶＣ）が含まれる。ＡＶＣには、スケーラブルビデオコーディング（ＳＶＣ）、ＭＶＣ（Multiview Video Coding：多視点ビデオコーディング）及びＭＶＣ＋Ｄ（Multiview
Video Coding plus Depth）、及び３Ｄ ＡＶＣ（３Ｄ－ＡＶＣ）等の拡張機能が含まれる。ＨＥＶＣには、スケーラブルＨＥＶＣ（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ－ＨＥＶＣ）、３Ｄ ＨＥＶＣ（３Ｄ－ＨＥＶＣ）等の拡張機能が含まれる。

【0084】

ＩＴＵ－Ｔ及びＩＳＯ／ＩＥＣのＪＶＥＴ（joint video experts team）によって開発されている、多用途ビデオコーディング（ＶＶＣ）と名付けられた新しいビデオコーディング規格もある。ＶＶＣの最新のワーキングドラフト（ＷＤ）がＪＶＥＴ－Ｌ１００１－ｖ１に含められ、これは、http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L1001-v11.zip.で公開されている。本明細書で開示する技術は、ＩＴＵ－Ｔ及びＩＳＯ／ＩＥＣのＪＶＥＴ（joint video experts team）によるＶＶＣの開発不足に基づいている。ただし、この技術は他のビデオ／メディアコーデック仕様にも適用される。

【0085】

ビデオコーディングの基本について議論する。

【0086】

ビデオ圧縮技術は、空間的（イントラピクチャ）予測及び／又は時間的（インターピクチャ）予測を実行して、ビデオシーケンスに固有の冗長性を低減又は除去する。ブロックベースのビデオコーディングの場合に、ビデオスライス（すなわち、ビデオピクチャ又はビデオピクチャの一部）は、ビデオブロックにパーティション分割され得、これは、ツリーブロック、コーディングツリーブロック（ＣＴＢ）、コーディングツリーユニット（ＣＴＵ）、コーディングユニット（ＣＵ）及び／又はコーディングノードとも呼ばれ得る。ピクチャのイントラコーディングした（Ｉ）スライスにおけるビデオブロックは、同じピクチャの隣接するブロック内の参照サンプルに関する空間的予測を使用して符号化される。ピクチャのインターコーディングした（Ｐ又はＢ）スライスにおけるビデオブロックは、同じピクチャの隣接するブロック内の参照サンプルに関する空間的予測、又は他の参照ピクチャ内の参照サンプルに関する時間予測を使用することができる。ピクチャはフレームと呼ばれ得、参照ピクチャは参照フレームと呼ばれ得る。

【0087】

空間的又は時間的予測は、コーディングすべきブロックの予測ブロックをもたらす。残余データは、コーディングすべき元のブロックと予測ブロックの間のピクセル差を表す。インターコーディングしたブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトル、及びコーディングしたブロックと予測ブロックの差を示す残余データに従って符号化される。イントラコーディングされるブロックは、イントラコーディングモード及び残余データに従って符号化される。さらに圧縮するために、残余データをピクセルドメインから変換ドメインに変換して、残余変換係数を生成し、次に、この残余変換係数を量子化することができる。最初に２次元アレイに配置された量子化した変換係数は、変換係数の１次元ベクトルを生成するためにスキャンされ得、エントロピーコーディングが、さらに多くの圧縮を達成するために適用され得る。

【0088】

ビデオコーディングにおけるピクチャタイプについて議論する。

【0089】

ビデオコーデック仕様では、ピクチャ識別（例えば、ＰＯＣ）の導出、ＤＰＢにおける参照ピクチャステータスのマーキング、ＤＰＢからのピクチャの出力等を含む、復号化プロセスを規定するために、ピクチャタイプを識別する必要がある。

【0090】

ＡＶＣ及びＨＥＶＣでは、ピクチャタイプは、コーディングしたピクチャを含むＮＡＬユニットタイプから識別することができる。ＡＶＣのピクチャタイプには、ＩＤＲピクチャ及び非ＩＤＲピクチャが含まれる。一方、ＨＥＶＣの主要なピクチャタイプには、トレイリング（trailing：末尾）ピクチャ、時間的サブレイヤアクセスピクチャ（ＴＳＡ）、段階的時間サブレイヤアクセスピクチャ（ＳＴＳＡ）、ランダムアクセス復号化可能リーディング（leading：先頭）ピクチャ（ＲＡＤＬ）、ランダムアクセススキップリーディングピクチャ（ＲＡＳＬ）、リンク切れ（broken link）アクセスピクチャ（ＢＬＡ）、瞬時ランダムアクセス、及びクリーンランダムアクセスが含まれる。ＨＥＶＣのこれらの主要なピクチャタイプのそれぞれについて、ピクチャは、サブレイヤ参照ピクチャ又はサブレイヤ非参照ピクチャのいずれかとしてさらに区別することができる。ＢＬＡピクチャは、リーディングピクチャを含むＢＬＡ、ＲＡＤＬピクチャを含むＢＬＡ、又はリーディングピクチャなしのＢＬＡのいずれかとしてさらに区別される。ＩＤＲピクチャは、ＲＡＤＬピクチャを含むＩＤＲ又はリーディングピクチャなしのＩＤＲとしてさらに区別される。

【0091】

イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャについて議論する。

【0092】

ＨＥＶＣでは、ＩＤＲ、ＢＬＡ、及びクリーンランダムアクセス（ＣＲＡ）ピクチャはまとめて、イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャと見なされる。ＶＶＣについては、２０１８年１０月の第１２回ＪＶＥＴミーティングで、ＩＤＲピクチャとＣＲＡピクチャとの両方がＩＲＡＰピクチャに含まれることが合意された。

【0093】

ＩＲＡＰピクチャは、以下の２つの重要な機能又は利点を提供する。第１に、ＩＲＡＰピクチャの存在は、復号化プロセスがそのピクチャから開始できることを示す。この機能により、ランダムアクセス機能が可能になり、このランダムアクセス機能では、ＩＲＡＰピクチャがその位置に存在する限り、復号化プロセスは、ビットストリーム内の位置で開始し、必ずしもビットストリームの先頭である必要はない。第２に、ＩＲＡＰピクチャの存在は、ＲＡＳＬピクチャを除いて、ＩＲＡＰピクチャで始まるコーディングしたピクチャが以前のピクチャを何ら参照せずにコーディングされるように、復号化プロセスをリフレッシュする。ＩＲＡＰピクチャをビットストリームに存在させることで、ＩＲＡＰピクチャの前にコーディングしたピクチャの復号化中に発生した可能性のある任意のエラーが、ＩＲＡＰピクチャ及び復号化順にＩＲＡＰピクチャに続くそれらピクチャに伝播するのを防ぐ。

【0094】

ＩＲＡＰピクチャは重要な機能を提供するが、ＩＲＡＰピクチャは圧縮効率にペナルティ（penalty：不利益）を伴う可能性がある。例えば、ＩＲＡＰピクチャが存在すると、ビットレートを急上昇させる可能性がある。圧縮効率のペナルティには２つの原因がある。第１に、ＩＲＡＰピクチャがイントラ予測したピクチャであるため、ピクチャ自体は、他のインター予測したピクチャと比較して、表現するためにより多くのビットを必要とする。第２に、ＩＲＡＰピクチャは時間的予測を狂わせる（break）。例えば、復号化プロセス中にＩＲＡＰピクチャに直面する（encountered）と、ＤＰＢがリフレッシュされ、以前の参照ピクチャが削除される。さらに、ＩＲＡＰピクチャは、復号化順でＩＲＡＰピクチャに続くピクチャのコーディングの効率を低下させる。例えば、復号化順でＩＲＡＰピクチャに続くピクチャは、それらピクチャにはそれらインター予測コーディングのための参照ピクチャが少ないため、表現するためにより多くのビットを必要とする。

【0095】

ＩＲＡＰピクチャと見なされるピクチャタイプの中で、ＨＥＶＣのＩＤＲピクチャは、他のピクチャタイプと比較した場合に、異なるシグナリング及び導出を有する。いくつかの差異は次の通りである。

【0096】

ＩＤＲピクチャのＰＯＣ値のシグナリング及び導出について、ＰＯＣの最上位ビット（ＭＳＢ）は、以前のキー（key）ピクチャから導出されない。むしろ、ＭＳＢは、単に０に等しくなるように設定される。

【0097】

ＩＤＲピクチャのスライスヘッダは、参照ピクチャ管理を支援するために信号通知する必要がある情報を含まない。他のピクチャタイプ（例えば、ＣＲＡ、トレイリング（Trailing）、ＴＳＡ等）の場合に、以下で説明する参照ピクチャセット（ＲＰＳ）等の情報、又はいくつかの他の形式の同様の情報（例えば、参照ピクチャリスト）が参照ピクチャのマーキングプロセス（例えば、参照のために使用されるか、又は参照のために使用されない、ＤＰＢ内の参照ピクチャのステータスを決定するプロセス）に必要である。ただし、ＩＤＲピクチャの場合に、ＩＤＲの存在は、復号化プロセスがＤＰＢ内の全ての参照ピクチャを参照に使用されないとしてマークするだけであることを示しているため、このような情報を信号通知する必要はない。

【0098】

ビデオコーディングにおける参照ピクチャ管理について議論する。

【0099】

ピクチャタイプに加えて、ピクチャ識別が、インター予測における参照ピクチャとしての使用、復号化したピクチャバッファ（ＤＰＢ）からのピクチャの出力、動きベクトルのスケーリング、重み付け予測等を含む複数の目的のためにも必要とされる。ＡＶＣ及びＨＥＶＣでは、ピクチャはピクチャ順序カウント（ＰＯＣ）で識別できる。

【0100】

ＡＶＣ及びＨＥＶＣでは、ＤＰＢ内のピクチャは、「短期間の参照に使用される」、「長期間の参照に使用される」、又は「参照に使用されない」としてマークされ得る。ピクチャが「参照に使用されない」とマークされると、そのピクチャはもはや予測に使用できなくなる。そのピクチャがもはや出力する必要がなくなった場合に、そのピクチャをＤＰＢから削除できる。

【0101】

ＡＶＣでは、短期及び長期の２つのタイプの参照ピクチャが存在する。参照ピクチャは、そのピクチャがもはや予測参照のために不要になったときに、「参照に使用されない」とマークされ得る。これらの３つのステータス（短期、長期、及び参照用に使用されない）間の変換は、復号化した参照ピクチャのマーキングプロセスによって制御される。取り得る（alternative）２つの復号化した参照ピクチャのマーキングメカニズム、暗黙的なスライディングウィンドウプロセス、及び明示的なメモリ管理制御操作（ＭＭＣＯ）プロセスがある。スライディングウィンドウプロセスは、参照フレームの数が指定した最大数（例えば、ＳＰＳ内のｍａｘ＿ｎｕｍ＿ｒｅｆ＿ｆｒａｍｅｓ）に等しい場合に、短期参照ピクチャを「参照に使用されない」としてマークする。短期参照ピクチャは先入れ先出し方式で格納されるため、直近に復号化した短期ピクチャはＤＰＢに保持される。

【0102】

明示的なＭＭＣＯプロセスは、複数のＭＭＣＯコマンドを含み得る。ＭＭＣＯコマンドは、１つ又は複数の短期又は長期の参照ピクチャを「参照に使用されない」としてマークするか、全てのピクチャを「参照に使用されない」としてマークするか、現在の参照ピクチャ又は既存の短期参照ピクチャを長期としてマークすることができ、その長期参照ピクチャに長期ピクチャインデックスを割り当てることができる。

【0103】

ＡＶＣでは、参照ピクチャマーキング操作、並びにＤＰＢからのピクチャの出力及び削除のためのプロセスは、ピクチャを復号化した後に実行される。

【0104】

ＨＥＶＣは、参照ピクチャセット（ＲＰＳ）と呼ばれる、参照ピクチャ管理について異なるアプローチを導入する。ＡＶＣのＭＭＣＯ／スライディングウィンドウと比較したＲＰＳの概念との最も基本的な差異は、特定のスライス毎に、現在のピクチャ又は任意の後続のピクチャで使用される参照ピクチャの完全なセットが提供されることである。こうして、現在又は将来のピクチャで使用するためにＤＰＢに保持されている全てのピクチャの完全なセットが信号通知される。これは、ＤＰＢへの相対的な変更のみが信号通知されるＡＶＣスキームとは異なる。ＲＰＳの概念では、ＤＰＢ内の参照ピクチャの正しいステータスを維持するために、復号化順に前のピクチャからの情報は必要ない。

【0105】

ＨＶＣにおけるピクチャ復号化及びＤＰＢ操作の順序は、ＲＰＳの利点を活用し、エラー回復力を高めるために、ＡＶＣと比較して変更される。ＡＶＣでは、ピクチャのマーキング及びバッファ操作（ＤＰＢからの復号化したピクチャの出力と削除との両方）は、通常、現在のピクチャが復号化された後に適用される。ＨＥＶＣでは、ＲＰＳは最初に現在のピクチャのスライスヘッダから復号化され、次に、ピクチャのマーキング及びバッファ操作が通常、現在のピクチャを復号化する前に適用される。

【0106】

ＨＥＶＣにおけるＲＰＳのシグナリングについて議論する。

【0107】

ＨＥＶＣの各スライスヘッダは、スライスを含むピクチャに関してＲＰＳのシグナリングのためのパラメータを含む。唯一の例外は、ＩＤＲスライスに対してＲＰＳが信号通知されないことである。代わりに、ＲＰＳは空であると推測される。ＩＤＲピクチャに属さないＩスライスの場合に、ＩスライスがＩピクチャに属していても、ＲＰＳが提供される場合がある。これは、復号化順でＩピクチャに先行するピクチャに基づいてインター予測を使用する、復号化順でＩピクチャに続くピクチャが存在する可能性があるためである。ＲＰＳ内のピクチャの数は、ＳＰＳ内のsps_max_dec_pic_buffering構文要素で指定されるＤＰＢサイズ制限を超えてはならない。

【0108】

各ピクチャは、出力順序を表すＰＯＣ値に関連付けられる。スライスヘッダには、固定長のコードワードpic_order_cnt_lsbが含まれており、これは、ＰＯＣ ＬＳＢとしても知られている完全なＰＯＣ値の最下位ビットを表す。コードワードの長さは、ＳＰＳで信号通知され、４～１６ビットの間にすることができる。ＲＰＳの概念では、ＰＯＣを使用して参照ピクチャを識別する。スライスヘッダ自体のＰＯＣ値に加えて、各スライスヘッダは、ＲＰＳ内の各ピクチャのＰＯＣ値（又はＬＳＢ）のコーディングした表現をＳＰＳに直接含むか、ＳＰＳから継承する。

【0109】

各ピクチャのＲＰＳは、５つのＲＰＳサブセットとも呼ばれる、参照ピクチャの５つの異なるリストから構成される。RefPicSetStCurrBeforeは、復号化順と出力順との両方で現在のピクチャより前にあり、且つ現在のピクチャのインター予測に使用できる全ての短期参照ピクチャで構成される。RefPicSetStCurrAfterは、復号化順で現在のピクチャより前にあり、出力順で現在のピクチャに続き、且つ現在のピクチャのインター予測に使用できる全ての短期参照ピクチャで構成される。RefPicSetStFollは、復号化順に現在のピクチャに続く１つ又は複数のピクチャのインター予測に使用でき、且つ現在のピクチャのインター予測には使用されない全ての短期参照ピクチャで構成される。RefPicSetLtCurrは、現在のピクチャのインター予測に使用できる全ての長期参照ピクチャで構成される。RefPicSetLtFollは、復号化順で現在のピクチャに続く１つ又は複数のピクチャのインター予測に使用でき、且つ現在のピクチャのインター予測には使用されない全ての長期参照ピクチャで構成される。

【0110】

ＲＰＳは、異なるタイプの参照ピクチャ（現在のピクチャよりもＰＯＣ値が低い短期参照ピクチャ、現在のピクチャよりもＰＯＣ値が高い短期参照ピクチャ、及び長期参照ピクチャ）を反復する最大３つのループを使用して信号通知される。さらに、参照ピクチャが、現在のピクチャ（リストRefPicSetStCurrBefore、RefPicSetStCurrAfter、又はRefPicSetLtCurrのいずれかに含まれる）による参照のために使用されるか、又は現在のピクチャ（リストRefPicSetStFoll又はRefPicSetLtFollのいずれかに含まれる）による参照のために使用されないどうかを示すフラグ（used_by_curr_pic_X_flag）が各参照ピクチャに送信される。

【0111】

図４は、ＲＰＳ４００の全てのサブセット４０２にエントリ（例えば、ピクチャ）を含む状態の現在のピクチャＢ１４を有するＲＰＳ４００を示す。図４の例では、現在のピクチャＢ１４は、５つのサブセット４０２（別名、ＲＰＳサブセット）のそれぞれに正確に１つのピクチャを含む。Ｐ８は、ピクチャが出力順で前にあり且つＢ１４によって使用されるため、RefPicSetStCurrBeforeと呼ばれるサブセット４０２内のピクチャである。Ｐ１２は、ピクチャが出力順で後ろにあり且つＢ１４によって使用されるため、RefPicSetStCurrAfterと呼ばれるサブセット４０２内のピクチャである。Ｐ１３は、ピクチャがＢ１４で使用されない短期参照ピクチャであるため（ただし、そのピクチャはＢ１５で使用されるためＤＰＢに保持する必要がある）、RefPicSetStFollと呼ばれるサブセット４０２内のピクチャである。Ｐ４は、ピクチャがＢ１４によって使用される長期参照ピクチャであるため、RefPicSetLtCurrと呼ばれるサブセット４０２内のピクチャである。Ｉ０は、ピクチャが現在のピクチャでは使用されない長期参照ピクチャであるため（ただし、そのピクチャがＢ１５で使用されるためＤＰＢに保持する必要がある）、RefPicSetLtFollと呼ばれるサブセット４０２内のピクチャである。

【0112】

ＲＰＳ４００の短期部分は、スライスヘッダに直接含まれ得る。あるいはまた、スライスヘッダには、アクティブなＳＰＳで送信されるＲＰＳの予め規定したリストを参照する、インデックスを表す構文要素のみが含まれ得る。ＲＰＳ４０２の短期部分は、２つの異なるスキーム：以下で説明するインターＲＰＳ、又はここで説明するイントラＲＰＳのいずれかを使用して信号通知することができる。イントラＲＰＳを使用すると、参照ピクチャの２つの異なるリストの長さを表すnum_negative_pics及びnum_positive_picsが信号通知される。これらのリストには、現在のピクチャと比較して、それぞれ負のＰＯＣ差及び正のＰＯＣ差がある参照ピクチャが含まれる。これらのリストの各要素は、リストの前の要素から１を引いたものと比較したＰＯＣ値の差を表す可変長コードで符号化される。各リストの第１のピクチャの場合に、シグナリングは現在のピクチャのＰＯＣ値から１を引いた値に関連している。

【0113】

シーケンスパラメータセットで循環するＲＰＳを符号化する場合に、シーケンスパラメータセットで既に符号化した別のＲＰＳを参照して、１つのＲＰＳ（例えば、ＲＰＳ４００）の要素を符号化することが可能である。これは、インターＲＰＳと呼ばれる。シーケンスパラメータセットの全てのＲＰＳが同じネットワーク抽象化レイヤ（ＮＡＬ）ユニットにあるため、この方法に関連するエラーの堅牢性の問題はない。インターＲＰＳ構文は、現在のピクチャのＲＰＳが以前に復号化したピクチャのＲＰＳから予測できるという事実を利用している。これは、現在のピクチャの全ての参照ピクチャが、以前のピクチャの参照ピクチャ又は以前に復号化したピクチャ自体のいずれかである必要があるためである。これらのピクチャのどれが参照ピクチャであり、現在のピクチャの予測に使用すべきかを示す必要があるだけである。従って、構文は、以下のもの：予測子として使用するＲＰＳを指し示すインデックス、現在のＲＰＳのデルタＰＯＣを取得するために予測子のdelta_POCに追加されるdelta_POC、及びどのピクチャが参照ピクチャであり、それらピクチャが将来のピクチャの予測にのみ使用されるかどうかを示すインジケータのセットで構成される。一実施形態では、デルタＰＯＣは、現在の参照ピクチャと別の（例えば、以前の）参照ピクチャとの間のＰＯＣ値の差を指す。

【0114】

長期参照ピクチャの使用を利用したいエンコーダは、ＳＰＳ構文要素long_term_ref_pic_present_flagを１に設定しなければならない。次に、長期参照ピクチャは、固定長コードワードpoc_lsb_ltによってスライスヘッダで信号通知され、このコードワードは、各長期ピクチャの完全なＰＯＣ値の最下位ビットを表す。各poc_lsb_ltは、特定の長期ピクチャに対して信号通知されたpic_order_cnt_lsbコードワードのコピーである。また、ＳＰＳ内の長期ピクチャのセットをＰＯＣ ＬＳＢ値のリストとして信号通知することもできる。次に、長期ピクチャのＰＯＣ ＬＳＢは、このリストへのインデックスとしてスライスヘッダで信号通知できる。

【0115】

delta_POC_msb_cycle_lt_minus1構文要素は、現在のピクチャに対する長期参照ピクチャの完全なＰＯＣ距離の計算を可能にするためにさらに信号通知することができる。コードワードdelta_POC_msb_cycle_lt_minus1は、ＲＰＳ内の任意の他の参照ピクチャと同じＰＯＣ ＬＳＢ値を有する長期参照ピクチャ毎に信号通知する必要がある。

【0116】

ＨＥＶＣにおける参照ピクチャマーキングについて議論する。

【0117】

ピクチャ復号化の前に、典型的に、ＤＰＢに多数のピクチャが存在するであろう。いくつかのピクチャは予測に利用できるため、「参照に使用される」とマークされ得る。他のピクチャは予測に利用できないが出力を待っているため、「参照に使用されない」とマークされ得る。スライスヘッダが解析されると、スライスデータを復号化する前にピクチャマーキングプロセスが実行される。ＤＰＢに存在し、「参照に使用される」とマークされるがＲＰＳに含まれないピクチャは、「参照に使用されない」とマークされる。used_by_curr_pic_X_flagがゼロに等しい場合に、ＤＰＢには存在しないが、参照ピクチャセットに含まれるピクチャは無視される。ただし、代わりに、used_by_curr_pic_X_flagが１に等しい場合に、この参照ピクチャは、現在のピクチャでの予測に使用することを意図していたが、欠落している。次に、意図しないピクチャの損失が推測され、デコーダは適切なアクションを講じる必要がある。

【0118】

現在のピクチャを復号化した後に、その復号化したピクチャは「短期間の参照に使用される」とマークされる。

【0119】

ＨＥＶＣにおける参照ピクチャリストの構成について議論する。

【0120】

ＨＥＶＣでは、用語インター予測は、現在の復号化したピクチャ以外の参照ピクチャのデータ要素（例えば、サンプル値又は動きベクトル）から導出した予測を示すために使用される。ＡＶＣと同様に、ピクチャは複数の参照ピクチャから予測できる。インター予測に使用される参照ピクチャは、１つ又は複数の参照ピクチャリストに編成される。参照インデックスは、リスト内のどの参照ピクチャを予測信号の作成に使用すべきかを特定する。

【0121】

単一の参照ピクチャリスト、リスト０がＰスライスに使用され、２つの参照ピクチャリスト、リスト０及びリスト１がＢスライスに使用される。ＡＶＣと同様に、ＨＥＶＣでの参照ピクチャリストの構成には、参照ピクチャリストの初期化及び参照ピクチャリストの修正が含まれる。

【0122】

ＡＶＣでは、リスト０の初期化プロセスは、Ｐスライス（復号化順序が使用される）とＢスライス（出力順序が使用される）とで異なる。ＨＥＶＣでは、どちらの場合にも出力順序が使用される。

【0123】

参照ピクチャリストの初期化は、３つのＲＰＳサブセット：RefPicSetStCurrBefore、RefPicSetStCurrAfter、及びRefPicSetLtCurrに基づいて、デフォルトのリスト０及びリスト１（スライスがＢスライスである場合に）を作成する。出力順序が早い（遅い）短期ピクチャは、最初に現在のピクチャまでのＰＯＣ距離の昇順でリスト０（リスト１）に挿入され、次に出力順序が遅い（早い）短期ピクチャは、現在のピクチャまでのＰＯＣ距離の昇順でリスト０（リスト１）に挿入され、最終的に、長期ピクチャが最後に挿入される。ＲＰＳに関しては、リスト０の場合に、RefPicSetStCurrBeforeのエントリが最初のリストに挿入され、その後にRefPicSetStCurrAfterのエントリが続く。その後、利用可能な場合に、RefPicSetLtCurrのエントリが追加される。

【0124】

ＨＥＶＣでは、リスト内のエントリの数がアクティブな参照ピクチャの目標数（ピクチャパラメータセット又はスライスヘッダで信号通知される）よりも少ない場合に、上記のプロセスが繰り返される（参照ピクチャリストに既に追加されている参照ピクチャが再び追加される）。エントリ数が目標数よりも多い場合に、リストは切り捨てられる。

【0125】

参照ピクチャリストが初期化された後に、参照ピクチャは、現在のピクチャの参照ピクチャが任意の順序で配置され得るように修正され得、これは、１つの特定の参照ピクチャが、参照ピクチャリスト修正コマンドに基づいて、リスト内の複数の位置に現れ得るケースを含む。リスト修正の有無を示すフラグが１に設定されている場合に、コマンドの固定数（参照ピクチャリスト内のエントリの目標数に等しい）が信号通知され、各コマンドは参照ピクチャリストに１つのエントリを挿入する。参照ピクチャは、ＲＰＳシグナリングから導出した現在のピクチャの参照ピクチャのリストへのインデックスによってコマンドで識別される。これは、ピクチャがピクチャ番号（frame_num構文要素から導出される）又は長期参照ピクチャインデックスのいずれかによって識別される、Ｈ．２６４／ＡＶＣの参照ピクチャリストの修正とは異なり、例えば、初期リストの最初の２つのエントリを交換し、又は初期リストの先頭に１つのエントリを挿入して、他のエントリをシフトするために、必要なコマンドが少なくなる可能性がある。

【0126】

参照ピクチャリストは、現在のピクチャよりも大きいTemporalIDを有する任意の参照ピクチャを含むことは許可されない。ＨＥＶＣビットストリームは、いくつかの一時的なサブレイヤで構成される場合がある。各ＮＡＬユニットは、TemporalID（temporal_id_plus1-1に等しい）で示される特定のサブレイヤに属する。

【0127】

参照ピクチャリストに直接基づく参照ピクチャ管理について議論する。

【0128】

ＪＣＴ－ＶＣ文書ＪＣＴＶＣ－Ｇ６４３は、http://phenix.int-evry.fr/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G643-v3.zipで公開されており、参照ピクチャリスト０、参照ピクチャリスト１、及びＤＰＢ内の参照ピクチャの管理のためのアイドル状態の参照ピクチャリストの３つの参照ピクチャリストを直接使用するアプローチを含む。このアプローチにより、１）スライディングウィンドウ及びＭＭＣＯプロセス、並びにＡＶＣでの参照ピクチャリストの初期化及び修正プロセス、又は２）参照ピクチャセット、並びにＨＥＶＣでの参照ピクチャリストの初期化及び修正プロセスのいずれかを利用する必要がなくなり、これは、シグナリング及び復号化を簡素化する。

【0129】

ＪＶＥＴ文書ＪＶＥＴ－Ｌ０１１２は、http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L0112-v4.zipで公開されており、参照ピクチャリストに直接基づく参照ピクチャ管理のための別のアプローチを説明している。ＪＣＴＶＣ－Ｇ６４３で提案されるような３つの参照ピクチャリストを使用する代わりに、ＪＶＥＴ－Ｌ０１１２で提案されるアプローチでは、２つの参照ピクチャリスト：参照ピクチャリスト０及び参照ピクチャリスト１のみを使用する。各参照ピクチャリストには、関連する最終参照ピクチャリストを構成するための参照ピクチャに関連する情報が含まれる（例えば、参照ピクチャリスト０の参照ピクチャは、最終参照ピクチャリスト０を構成するためのものであり、参照ピクチャリスト１の参照ピクチャは、最終参照ピクチャリスト１を構成するためのものである）。各参照ピクチャリストには、アクティブではない参照ピクチャ（例えば、現在のピクチャには必要ないが、将来のピクチャには必要になり得る）が含まれ得る。

【0130】

ＨＥＶＣにおけるピクチャパーティション分割スキームについて議論する。

【0131】

ＨＥＶＣは、４つの異なるピクチャパーティション分割スキーム、すなわち、通常のスライス、依存（dependent）スライス、タイル、及び波面並列処理（ＷＰＰ）を含み、これらは、最大転送単位（ＭＴＵ）サイズマッチング、並列処理、及び低減したエンドツーエンド遅延に適用され得る。

【0132】

通常のスライスは、Ｈ．２６４／ＡＶＣの場合と同様である。各通常のスライスはそれ自体のＮＡＬユニットにカプセル化され、インピクチャ（in-picture）予測（イントラサンプル予測、動き情報予測、コーディングモード予測）及びスライス境界を越えたエントロピーコーディングの依存関係が無効になる。こうして、通常のスライスは、同じピクチャ内の他の通常のスライスから独立して再構成することができる（ただし、ループフィルタリング操作のために依然として相互依存性が残っている場合がある）。

【0133】

通常のスライスは、並列化に使用できる唯一のツールであり、実質的に同一の形式で、Ｈ．２６４／ＡＶＣでも利用可能である。通常のスライスベースの並列化は、プロセッサ間（inter-processor）又はコア間（inter-core）通信をあまり必要としない（予測的にコーディングしたピクチャを復号化するときの動き補償のためのプロセッサ間又はコア間データ共有を除く。これは、典型的に、インピクチャ予測によってプロセッサ間又はコア間データ共有よりもはるかに重い）。ただし、同じ理由で、通常のスライスを使用すると、スライスヘッダのビットコストによって及びスライス境界を越えた予測の欠如によって、かなりのコーディングオーバーヘッドが発生する可能性がある。さらに、通常のスライスは（以下で述べる他のツールとは対照的に）、通常のスライスとは独立したインピクチャによって、及び各通常のスライスがそれ自体のＮＡＬユニットにカプセル化されているため、ＭＴＵサイズの要件にマッチングするビットストリームパーティション分割の主要なメカニズムとしても機能する。多くの場合、並列化の目標及びＭＴＵサイズのマッチングの目標は、矛盾する要求をピクチャのスライスレイアウトに突きつける。この状況の実現は、以下に述べる並列化ツールの開発につながった。

【0134】

依存スライスは、短いスライスヘッダを有し、任意のインピクチャ予測を狂わすことなく、ツリーブロック境界でビットストリームのパーティション分割を可能にする。基本的に、依存スライスは、通常のスライスを複数のＮＡＬユニットに断片化し、通常のスライス全体の符号化が完了する前に通常のスライスの一部を送信できるようにすることで、エンドツーエンドの遅延を減らす。

【0135】

ＷＰＰでは、ピクチャは、コーディングツリーブロック（ＣＴＢ）の単一の行にパーティション分割される。エントロピー復号化及び予測では、他のパーティションのＣＴＢからのデータを使用できる。並列処理は、ＣＴＢ行の復号化の開始が２つのＣＴＢだけ遅れる、ＣＴＢ行の並列復号化によって可能であり、これにより、対象ＣＴＢの右上のＣＴＢに関連するデータが対象ＣＴＢを復号化している前に利用可能になる。この千鳥状（staggered：互い違いの）開始（グラフィカルに表現すると波面のように見える）を使用すると、ピクチャに含まれるＣＴＢ行と同じ数のプロセッサ／コアまで並列化が可能である。ピクチャの内の隣接するツリーブロック行同士の間のインピクチャ予測が許容されるため、インピクチャ予測を可能にするために必要なプロセッサ間／コア間通信はかなりの量になる可能性がある。ＷＰＰパーティション分割では、適用されない場合と比較して、追加のＮＡＬユニットが生成されることはない。こうして、ＷＰＰは、ＭＴＵサイズのマッチングのためのツールではない。ただし、ＭＴＵサイズのマッチングが必要な場合には、通常のスライスを、特定のコーディングオーバーヘッド伴うＷＰＰで使用できる。

【0136】

タイルは、ピクチャをタイルの列及び行にパーティション分割する水平方向及び垂直方向の境界を規定する。ＣＴＢのスキャン順序は、ピクチャのタイルラスタースキャンの順序で次のタイルの左上のＣＴＢを復号化する前に、（タイルのＣＴＢラスタースキャンの順序で）タイル内でローカルになるように変更される。通常のスライスと同様に、タイルは、インピクチャ予測の依存関係及びエントロピー復号化の依存関係を狂わす。ただし、タイルを個々のＮＡＬユニットに含める必要はない（この点ではＷＰＰと同じである）。このため、タイルをＭＴＵサイズのマッチングに使用することはできない。各タイルは１つのプロセッサ／コアで処理でき、隣接するタイルを復号化する処理ユニット同士の間のインピクチャ予測に必要なプロセッサ間／コア間通信は、スライスが複数のタイルにまたがっている場合に、共有スライスヘッダの伝達、及び再構成したサンプル及びメタデータの共有に関連するループフィルタ処理に制限される。複数のタイル又はＷＰＰセグメントがスライスに含まれる場合に、スライスの最初のタイル又はＷＰＰセグメント以外の各タイル又はＷＰＰセグメントのエントリポイントバイトオフセットは、スライスヘッダで信号通知される。

【0137】

簡潔にするために、４つの異なるピクチャパーティション分割スキームの適用のための制限がＨＥＶＣで指定されている。所与のコーディングしたビデオシーケンスには、ＨＥＶＣで指定した殆どのプロファイルについてタイルと波面との両方を含めることはできない。スライス及びタイル毎に、次の条件のいずれか又は両方を満たす必要がある：１）スライス内の全てのコーディングしたツリーブロックが同じタイルに属する；２）タイル内の全てのコーディングしたツリーブロックは、同じスライスに属する。最後に、波面セグメントには正確に１つのＣＴＢ行が含まれ、ＷＰＰが使用されている場合であって、スライスがＣＴＢ行内で開始する場合に、そのスライスは、同じＣＴＢ行で終了する必要がある。

【0138】

動き制約付きタイルセット（ＭＣＴＳ）について議論する。

【0139】

ＨＥＶＣに対する最近の改訂は、ＪＣＴ－ＶＣ出力文書ＪＣＴＶＣ－ＡＣ１００５、J Boyce, A. Ramasubramonian, R. Skupin, G. J. Sullivan, A. Tourapis,
Y.-K. Wang (editors), “HEVC Additional Supplemental Enhancement Information
(Draft 4),” Oct. 24, 2017に明示され、http://phenix.int-evry.fr/jct/doc_end_user/documents/29_Macau/wg11/JCTVC
-AC1005-v2.zipで公開されている。この改訂を含めると、ＨＥＶＣは、３つのＭＣＴＳ関連の補足強化情報（SEI）メッセージ、つまり、一時的なＭＣＴＳ ＳＥＩメッセージ、ＭＣＴＳ抽出情報セットＳＥＩメッセージ、及びＭＣＴＳ抽出情報ネスト化ＳＥＩメッセージを指定する。

【0140】

一時的なＭＣＴＳ ＳＥＩメッセージは、ビットストリーム内のＭＣＴＳの存在を示し、ＭＣＴＳに信号通知する。各ＭＣＴＳについて、動きベクトルは、ＭＣＴＳ内のフルサンプル位置と、補間のためにＭＣＴＳ内のフルサンプル位置のみを必要とする分数（fractional）サンプル位置とを指し示すように制限され、ＭＣＴＳの外側のブロックから導出された一時的な動きベクトル予測のための動きベクトル候補の使用は許可されない。このようにして、ＭＣＴＳに含まれていないタイルが存在しなくても、各ＭＣＴＳを独立して復号化できる。

【0141】

ＭＣＴＳ抽出情報セットＳＥＩメッセージは、ＭＣＴＳサブビットストリーム抽出（ＳＥＩメッセージのセマンティクスの一部として指定される）で使用されて、ＭＣＴＳセットの適合ビットストリームを生成することができる補足情報を提供する。この情報には、いくつかの抽出情報セットが含まれ、各抽出情報セットが、いくつかのＭＣＴＳセットを規定し、ＭＣＴＳサブビットストリーム抽出プロセス中に使用すべき置換ＶＰＳ、ＳＰＳ、及びＰＰＳのＲＢＳＰバイトを含む。ＭＣＴＳサブビットストリーム抽出プロセスに従ってサブビットストリームを抽出するときに、パラメータセット（ＶＰＳ、ＳＰＳ、及びＰＰＳ）を書き換える、又は置き換える必要があり、スライスアドレスに関連する構文要素（first_slice_segment_in_pic_flag及びslice_segment_addressを含む）の１つ又は全てが、典型的に、異なる値を有する必要があるため、スライスヘッダを僅かに更新する必要がある。

【0142】

タイルグループについて議論する。

【0143】

２０１８年１０月にマカオで開催された第１２回ＪＶＥＴ会議の後に、スライスの概念をタイルグループに置き換えることが合意された。ただし、本開示の時点では、ＶＶＣの最新のドラフトには、合意したタイルグループの概念が未だ含まれていなかった。寄稿ＪＶＥＴ－Ｌ０６８６は、http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L0686-v2.zipで公開されており、合意したタイルグループのテキストを含む。第１２回ＪＶＥＴ会議で合意したタイルグループでは、１つ又は複数のタイルをタイルグループにグループ化できる。タイルグループに属するタイルは、ピクチャのラスタースキャン順序で連続している。本開示の残りの部分では、ＪＶＥＴ－Ｌ０６８６で説明しているタイルグループは、ラスタースキャンタイルグループと呼ばれる。

【0144】

寄稿ＪＶＥＴ-L０１１４は、http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/12_Macao/wg11/JVET-L0114-v１.zipで公開されており、タイルグループの別のアプローチを説明している。本明細書で説明するタイルグループは、タイルグループに一緒にグループ化されるタイルがピクチャ内の長方形状の領域を形成するものとして制約される。本開示の残りの部分では、ＪＶＥＴ－Ｌ０１１４で説明しているタイルグループは、長方形タイルグループと呼ばれる。

【0145】

３６０°ビデオアプリケーションにおけるビューポート依存のユースケースについて議論する。

【0146】

３６０度（３６０°）のビデオアプリケーションは、球全体の一部のみを表示する（結果として、ピクチャ全体のサブセットのみを表示する）。ビットレートを下げるために、ビューポートに依存するＤＡＳＨを介した３６０°配信と呼ばれるユースケースのシナリオを使用して、ＤＡＳＨを介して３６０°ビデオを配信する。ユースケースのシナリオは次の通りである。

【0147】

球／投影した画像全体を（例えば、キューブマップ投影（ＣＭＰ）を使用して）複数のＭＣＴＳに分割する。

【0148】

異なる空間解像度又は品質で２つ以上のビットストリームを符号化する。

【0149】

デコーダに配信するときに、より高い解像度／品質のビットストリームからのＭＣＴＳがビューポート（例えば、フロントビューポート）を表示するために使用され、より低い解像度／品質のビットストリームからのＭＣＴＳが残りを表示するために使用される。これらのＭＣＴＳは特定の方法でパックされ、次に、復号化するために受信機に送信される。

【0150】

良好な視聴体験を提供するために、ユーザによって見られるビューポートが高い解像度／品質のＭＣＴＳによって表されることが期待される。ユーザが別のビューポート（例えば、左又は右のビューポート）を見るために自分の頭を向けるときに、システムがそのビューポートの高い解像度／品質のＭＣＴＳをフェッチしている間に、表示されるコンテンツはより低い解像度／品質のビューポートから短期間に亘って取得される（come from）だろう。

【0151】

ユーザが別のビューポートを見るために自分の頭を向けるときに、ユーザが自分の頭を向ける時と、ビューポートのより高い解像度／品質の表現が見られる時との間に遅延がある。この遅延は、システムがそのビューポートのより高い解像度／品質のＭＣＴＳをどれ位速くフェッチできるかに依存し、次に、これは、新しいビューポートのＭＣＴＳがＩＲＡＰピクチャから開始してのみ復号化可能であるため、ＩＲＡＰ期間（例えば、２つのＩＲＡＰの間の発生間隔）に依存する。ＩＲＡＰ期間が１秒毎にコーディングされている場合に、以下が適用される。

【0152】

遅延の最良ケースのシナリオは、システムが新しいセグメント／ＩＲＡＰ期間のフェッチを開始する直前にユーザが新しいビューポートを見るために自分の頭を向ける場合のネットワークラウンドトリップ遅延と同じである。このシナリオでは、システムは、新しいビューポートに対してより高解像度／品質のＭＣＴＳを直ぐに要求できるだろう。そのため、唯一の遅延はネットワークラウンドトリップ遅延である（フェッチ要求の遅延と要求したＭＣＴＳの送信時間の合計であり、最小バッファリング遅延をゼロに設定できると仮定する（が、通常はストリーミングシステムでは最小バッファリング遅延を０に設定できない）と、センサの遅延は、小さく、無視できる）。ネットワークラウンドトリップ遅延は、例えば、約２００ミリ秒（ｍｓ）になる可能性がある。

【0153】

遅延の最悪ケースのシナリオは、システムが既に次のセグメントの要求を行った直後にユーザが新しいビューポートを見るために自分の頭を向ける場合のＩＲＡＰ期間＋ネットワークラウンドトリップ遅延である。

【0154】

上記の最悪ケースのシナリオを改善するために、より頻繁なＩＲＡＰピクチャを用いてビットストリームを符号化して、ＩＲＡＰ期間をより短くし、こうして全体的な遅延を低減することができる。ただし、これにより、圧縮効率が低下するため、結果的に帯域幅の要件が増大する。

【0155】

既存のＩＲＡＰ概念の問題について議論する。

【0156】

ＨＥＶＣ及びＶＶＣの最新の開発まで、ＩＲＡＰ概念はピクチャレベルの概念である。それは、イントラ・ランダムアクセスポイントに関連付けられたコーディングしたビデオビットストリーム内の最小のオブジェクトがピクチャであることを意味する。それは、ＩＲＡＰの概念がサブピクチャレベルで適用可能であれば有益となろう。サブピクチャレベルでＩＲＡＰを使用すると、上記のように、ＤＡＳＨを介した３６０°の配信で最悪ケースのシナリオを減らすのに役立つだろう。しかしながら、以下の問題のために、既存のビデオコーディング仕様（例えば、ＨＥＶＣ、ＶＶＣ等）でこのようにＩＲＡＰの概念を改善することは困難である。

【0157】

一般に、ＩＲＡＰピクチャのシグナリング、導出プロセス、及び復号化プロセスは、非ＩＲＡＰピクチャのそれらとは異なる。さらに、多くの態様がピクチャレベルで規定される。いくつかの差異は次の通りである。

【0158】

ＰＯＣ導出に関して、ＰＯＣ ＭＳＢは、ＩＤＲピクチャについては常に０に設定される一方、ＰＯＣ ＭＳＢは、他のピクチャタイプについては以前のキーピクチャから導出される。

【0159】

参照ピクチャ管理に関して、ＩＤＲピクチャを受信したときに、ＩＤＲピクチャについて情報を通知する必要はない。デコーダは、ＤＰＢ内の全ての参照ピクチャを「参照に使用されない」とマークするだけである。一方、他のピクチャタイプについては、参照ピクチャの管理を支援するための情報（例えば、ＲＰＳ、ＲＰＬ等）を通知する必要がある。

【0160】

サブピクチャが、元のビットストリームから抽出されて、サブビットストリーム抽出プロセスを介して新しいビットストリームを形成することができる。サブビットストリーム抽出プロセスの前後の同じサブピクチャのシグナリング、導出、及び復号化プロセスが変化せず、同じ復号化／再構成結果を生成することが望ましい。

【0161】

現在のコーディング技術の欠点の１つは、ＩＲＡＰピクチャを含むことである。ＩＲＡＰピクチャはイントラコーディングされる。そのため、コーダ／デコーダ（別名、コーデック）は、参照ピクチャリスト（ＲＰＬ）を利用せずにＩＲＡＰピクチャをコーディングする。その結果、現在のコーディング技術で使用されている構文は、ＩＲＡＰピクチャに直面した（encountered）ときはいつでもＲＰＬを検索しないようにコーデックに命令する。

【0162】

仮想現実（ＶＲ）コーディングでは、ピクチャをサブピクチャに分割することが望ましい場合があり、この場合、一方のサブピクチャはＩＲＡＰサブピクチャであり、他方のサブピクチャは非ＩＲＡＰサブピクチャである。ピクチャがこのように分割されている場合に、そのピクチャは混合ＩＲＡＰピクチャと呼ばれ得る。ただし、混合ＩＲＡＰピクチャは、現在のコーディング技術では問題を提示する。実際に、現在の構文では、ＩＲＡＰサブピクチャが存在するため、コーデックが混合ＩＲＡＰピクチャ全体の任意のＲＰＬを無視する必要がある。ＲＰＬが無視されるため、コーデックは、インターコーディングしたピクチャとして、適切なコーディングためにＲＰＬに依存する非ＩＲＡＰサブピクチャをコーディングできない。

【0163】

本明細書に開示するのは、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容するビデオコーディング技術である。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャを含む場合でも、コーデックは、ＲＰＬを参照及び利用して、非ＩＲＡＰサブピクチャをコーディングすることが許容される。これはＶＲコーディングアプリケーションで特に有益であるが、この概念は他の分野にも同様に適用することができる。

【0164】

図５は、ＶＲコーディングアプリケーションでの使用に適したピクチャ５００の一実施形態の概略図である。示されるように、ピクチャ５００は、第１のサブピクチャ５０２及び第２のサブピクチャ５０４に分割されている。一実施形態では、第１のサブピクチャ５０２は、ＶＲアプリケーションで使用されるビューポートに対応する。ビューポートは、ＶＲアプリケーション又はプログラムのユーザが現在見ているピクチャの一部である。一実施形態では、第２のサブピクチャ５０４は、ピクチャ５００の残りの部分を含む。すなわち、第２のサブピクチャ５０４は、ビューポートの外側のピクチャ５００の部分である。一実施形態では、第１のサブピクチャ５０２はＩＲＡＰピクチャであり、第２のサブピクチャ５０４は、ビットストリーム内の特定の時点ｔにおける非ＩＲＡＰピクチャである。そのため、ピクチャ５００は、時間ｔにおける混合ＩＲＡＰピクチャと呼ばれ得る。

【0165】

図６は、図５のピクチャ５００に対応するビデオビットストリーム６００の一実施形態の概略図である。本明細書で使用する場合に、ビデオビットストリーム６００は、コーディングしたビデオビットストリーム、ビットストリーム、又はそれらの変形とも呼ばれ得る。図６のピクチャ５００は、単一のＮＡＬユニット（太字の黒い長方形で表される）内に含まれる場合、又はいくつかのＮＡＬユニット内に含まれる場合がある。

【0166】

図６に示されるように、ビットストリーム６００は、第１のサブビットストリーム６０２及び第２のサブビットストリーム６０４に分割されている。第１のサブビットストリーム６０２は第１のサブピクチャ５０２に対応し、第２のサブビットストリーム６０４は第２のサブピクチャ５０４に対応する。第１のサブビットストリーム６０２が、この例ではビューポートである第１のサブピクチャ５０２に対応するので、第１のサブビットストリーム６０２は、第２のサブビットストリーム６０４よりも多くのＩＲＡＰサブピクチャを含む。ＩＲＡＰピクチャは、コーデックがビットストリーム６００内のその位置で復号化を開始するのを許容する。第１のサブストリーム６０２がいくつかのＩＲＡＰピクチャを含むので、デコーダは、様々な異なる位置で第１のサブピクチャ５０２の復号化を開始することができる。ＩＲＡＰピクチャの例には、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャ、クリーンランダムアクセス（ＣＲＡ）ピクチャ、及びリンク切れアクセス（ＢＬＡ）ピクチャが含まれる。

【0167】

本明細書で開示する実施形態によれば、デコーダ（例えば、ビデオデコーダ３０）が、復号化プロセス中にビットストリーム６００内のピクチャ５００に直面する（encounter）と、デコーダは、ＩＲＡＰサブピクチャ（例えば、第１のサブピクチャ５０２）の存在によって、混合ＩＲＡＰピクチャ（例えば、ピクチャ５００）全体の任意のＲＰＬを無視するようにもはや命令されない。従って、混合ＩＲＡＰピクチャがＩＲＡＰサブピクチャ含む場合でも、デコーダは、非ＩＲＡＰサブピクチャ（例えば、第２のサブピクチャ５０４）を復号化するために、ＲＰＬを参照及び利用することが許容される。つまり、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャは、ＲＰＬを参照及び利用することが許容される。このため、ＶＲアプリケーションで有益な混合ＩＲＡＰピクチャが可能である。

【0168】

一実施形態では、ビットストリーム（例えば、ビットストリーム６００）が混合ＩＲＡＰピクチャ（例えば、ピクチャ５００）のいずれかを含むかどうかをデコーダ（例えば、ビデオデコーダ３０）に示すために、エンコーダ（例えば、ビデオエンコーダ２０）によってフラグは信号通知され得る。フラグは、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、又はビットストリームの別のパラメータセットで信号通知され得る。一実施形態では、フラグは、sps_mixed_tile_groups_in_pic_flagと指定される。

【0169】

一実施形態では、第１のサブピクチャ５０２及び第２のサブピクチャ５０４は、タイルグループと呼ばれ得る。一実施形態では、ＲＰＬは、そのタイルグループのＮＡＬユニットタイプに関係なく、各タイルグループの復号化の開始時に構成される。ＲＰＬは、例えば、ＲＰＬアプローチの場合にはRefPicList[0]及びRefPicList[1]、又は参照ピクチャセット（ＲＰＳ）アプローチの場合にはRefPicList0[]及びRefPicList1[]を含み得る。インター予測動作のための参照ピクチャを含む同様のリストも利用することができる。

【0170】

図７は、ビデオデコーダ（例えば、ビデオデコーダ３０）によって実装されるコーディングしたビデオビットストリーム（例えば、ビットストリーム６００）を復号化する方法７００の一実施形態である。方法７００は、復号化したビットストリームをビデオエンコーダ（例えば、ビデオエンコーダ２０）から直接的又は間接的に受信した後に実行され得る。方法７００は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容されるので、復号化プロセスを改善する（例えば、従来の復号化プロセスよりも復号化プロセスをより効率的、高速等にする）。このため、ＶＲアプリケーションで有益な混合ＩＲＡＰピクチャが可能である。従って、実際に、コーデックの性能が向上し、より良いユーザ体験につながる。

【0171】

ブロック７０２において、ビデオデコーダは、第１のサブピクチャ（例えば、サブピクチャ５０２）及び第２のサブピクチャ（例えば、サブピクチャ５０４）を含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャ（例えば、ピクチャ５００）を受信する。一実施形態では、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャである。一実施形態では、混合ＩＲＡＰピクチャは、第１のサブビットストリーム（例えば、第１のサブビットストリーム６０２）及び第２のサブビットストリーム（例えば、第２のサブビットストリーム６０４）を含む分割ビットストリームで受信される。一実施形態では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。一実施形態では、混合ＩＲＡＰピクチャは、単一のネットワークアクセスレイヤ（ＮＡＬ）ユニットに含まれる。

【0172】

ブロック７０４において、ビデオデコーダは、混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）を受信する。少なくとも１つのＩＲＡＰピクチャを含む混合ＩＲＡＰピクチャにもかかわらず、ＲＰＬはビデオデコーダによって受信又は別の方法で取得される。

【0173】

ブロック７０６において、ビデオデコーダは、ＲＰＬを使用して第２のサブピクチャを復号化する。ブロック７０８において、ビデオデコーダは、復号化した第２のサブピクチャに基づいて画像を生成する。一実施形態では、画像は、電子装置（例えば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータ等）のディスプレイ又は画面上でユーザに表示され得る。

【0174】

一実施形態では、方法７００は、ビットストリームでフラグを受信することをさらに含む。このフラグは、ビットストリームに混合ＩＲＡＰピクチャが含まれているかどうかを示す。一実施形態では、フラグは、ＳＰＳ、ＰＰＳ、又はビットストリームの別の部分で信号通知される。

【0175】

図８は、ビデオエンコーダ（例えば、ビデオエンコーダ２０）によって実装されるビデオビットストリーム（例えば、ビットストリーム５００）を符号化する方法８００の一実施形態である。方法８００は、（例えば、ビデオからの）ピクチャがビデオビットストリームに符号化され、次にビデオデコーダ（例えば、ビデオデコーダ３０）に向けて送信されるときに実行され得る。方法８００は、ＩＲＡＰピクチャ、特に混合ＩＲＡＰピクチャがＲＰＬを参照及び利用するのを許容されるので、符号化プロセスを改善する（例えば、符号化プロセスを従来の符号化プロセスよりも効率的、高速等にする）。このため、ＶＲアプリケーションで有益な混合ＩＲＡＰピクチャが可能である。従って、実際に、コーデックの性能が向上し、より良いユーザ体験につながる。

【0176】

ブロック８０２において、ビデオエンコーダは、第１のサブピクチャ及び第２のサブピクチャを含む混合イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャを符号化し、第１のサブピクチャはＩＲＡＰピクチャであり、第２のサブピクチャは非ＩＲＡＰサブピクチャである。一実施形態では、混合ＩＲＡＰピクチャは、第１のサブビットストリーム及び第２のサブビットストリームを含む分割ビットストリームに符号化される。一実施形態では、第１のサブピクチャは第１のサブビットストリームに符号化され、第２のサブピクチャは第２のサブビットストリームに符号化される。一実施形態では、ＩＲＡＰピクチャは、瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャである。一実施形態では、混合ＩＲＡＰピクチャは、単一のネットワークアクセスレイヤ（ＮＡＬ）ユニットに符号化される。

【0177】

ブロック８０４において、ビデオエンコーダは、混合ＩＲＡＰピクチャの参照ピクチャリスト（ＲＰＬ）を符号化する。

【0178】

ブロック８０６において、ビデオエンコーダは、混合ＩＲＡＰピクチャ及び混合ＩＲＡＰピクチャに対応するＲＰＬを含むビットストリームを生成する。ビデオエンコーダは、少なくとも１つのＩＲＡＰピクチャを含む混合ＩＲＡＰピクチャにもかかわらず、ビットストリームでＲＰＬを符号化する。

【0179】

ブロック８０８において、ビデオエンコーダは、ビデオデコーダに向けて送信するためのビットストリームを格納する。ビットストリームは、ビデオエンコーダがビデオビットストリーム（例えば、ビットストリーム６００）をビデオデコーダに向けて送信するまで、少なくとも一時的にメモリに格納され得る。ビデオデコーダによって受信されると、符号化したビデオビットストリームは、（例えば、上で説明したように）復号化され、電子装置（例えば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータ等）のディスプレイ又は画面でユーザに表示するための画像を生成又は作成する。

【0180】

一実施形態では、方法８００は、ビットストリーム内でフラグを符号化することをさらに含む。このフラグは、ビットストリームに混合ＩＲＡＰピクチャが含まれているかどうかを示す。一実施形態では、フラグは、ＳＰＳ、ＰＰＳ、又はビットストリームの別の部分で信号通知される。

【0181】

本明細書で開示する技術の説明は、ＪＶＥＴ－Ｌ０６８６－ｖ２及びＪＶＥＴ－Ｌ０１１２－ｖ２における最新のアプローチに関連して提供される。ＪＶＥＴ－Ｌ０６８６－ｖ２及びＪＶＥＴ－Ｌ０１１２－ｖ２のアプローチに関連する変更部分は斜体で表示され（以下では斜体の代わりに｛｝で示す（｛ ｝の中身が斜体に相当する））、削除については太字で示される（以下では太字の代わりに［］で示す（［ ］の中身が太字に相当する））一方、以下で言及しないＪＶＥＴ－Ｌ０６８６－ｖ２及びＪＶＥＴ－Ｌ０１１２－ｖ２のアプローチのテキストは、そのまま適用する。

【0182】

以下の規定が提供される。

【0183】

｛瞬時復号化リフレッシュ（ＩＤＲ）タイルグループ：IDR_NUTに等しいnal_unit_typeを有するＶＣＬ ＮＡＬユニットに含まれるタイルグループ。｝

【0184】

｛イントラ・ランダムアクセスポイント（ＩＲＡＰ）タイルグループ：IDR_NUT又はCRA_NUTに等しいnal_unit_typeを有するＶＣＬ ＮＡＬユニットに含まれるタイルグループ。｝

【0185】

｛イントラ・ランダムアクセスポイント（ＩＲＡＰ）ピクチャ：各ＶＣＬ ＮＡＬユニットがIDR_NUT又はCRA_NUTのnal_unit_typeを有するコーディングしたピクチャ。｝

【0186】

｛注－FirstIrapPictureFlagの値は、復号化順序でＣＶＳの最初のアクセスユニットである各ＩＤＲ又はＣＲＡアクセスユニットについて１に等しい。FirstIrapPictureFlagの値が１に等しい場合に、NoRaslOutputFlagの値は１に等しくなるように設定される。ＩＤＲピクチャは常にＣＶＳの最初のアクセスユニットである。ＣＲＡアクセスユニットは、そのアクセスユニットが、ビットストリームの最初のピクチャである場合に、シーケンスの終わりのＮＡＬユニットの直後に続く場合に、又は関連する変数HandleCraAsFirstPicInCvsFlagが１に等しい場合に、ＣＶＳの最初のアクセスユニットである。変数HandleCraAsFirstPicInCvsFlagは、外部手段によって設定できる。｝

【0187】

｛非ＩＲＡＰタイルグループ：nal_unit_typeがIDR_NUTにもCRA_NUTにも等しくないＶＣＬ ＮＡＬユニットに含まれるタイルグループ。｝

【0188】

ＮＡＬユニットヘッダセマンティクスが提供される。
表７１－ＮＡＬユニットタイプコード及びＮＡＬユニットタイプクラス

【表1】

【0189】

｛ピクチャの各タイルグループがIDR_NUT又はCRA_NUTに等しいnal_unit_typeを有する場合に、つまり、現在のタイルグループがＩＲＡＰピクチャに属する場合に、TemporalIDは０に等しくしなければならない。｝

【0190】

｛同じピクチャの少なくとも１つの他のＶＣＬ ＮＡＬユニットが、IDR_NUT又はCRA_NUTに等しいnal_unit_typeを有する一方で、ＶＣＬ ＮＡＬユニットのnal_unit_typeがIDR_NUTにもCRA_NUTにも等しくもない場合に、TemporalIDは０に等しくなければならない。｝

【0191】

シーケンスパラメータセットの構文及びセマンティクスが提供される。

【表2】

【0192】

｛１に等しいsps_mixed_tile_groups_in_pic_flagは、ＩＲＡＰタイルグループと非ＩＲＡＰタイルグループとの両方を有するピクチャがＣＶＳに存在し得ることを指定する。０に等しいsps_mixed_tile_groups_in_pic_flagは、ＣＶＳ内の各ピクチャにＩＲＡＰタイルグループのみ又は非ＩＲＡＰタイルグループのみがあることを指定する。｝

【0193】

ピクチャパラメータセット構文について議論する。

【表3】

【0194】

タイルグループ構文について議論する。

【表4】

【0195】

poc_msb_reset_flagは、以下のように変数PicRefreshFlagを指定するために使用される。

【0196】

－ 現在のタイルグループが復号化順序でビットストリームの最初のアクセスユニットに属する場合に、PicRefreshFlagは１に等しく設定される。

【0197】

－ それ以外の場合に、現在のタイルグループがＩＤＲタイルグループである場合に、PicRefreshFlagは、sps_mixed_tile_groups_in_pic_flag？poc_msb_reset_flag：１に等しく設定される。

【0198】

－ それ以外の場合に、現在のタイルグループがＣＲＡタイルグループである場合に、以下が適用される。

【0199】

－ 現在のアクセスユニットがシーケンスの終わりのＮＡＬユニットの直後に続く場合に、又は関連する変数HandleCraAsFirstPicInCvsFlagが１に等しい場合に、PicRefreshFlagは１に等しく設定される。

【0200】

－ それ以外の場合に、PicRefreshFlagは０に等しく設定される。

【0201】

－ それ以外の場合に（現在のタイルグループは、復号化順序でビットストリームの最初のアクセスユニットに属しておらず、そのグループはＩＲＡＰタイルグループではない）、PicRefreshFlagは０に等しく設定される。

【0202】

sps_mixed_tile_groups_in_pic_flagが０に等しい場合に、poc_msb_reset_flagの値は無視されることに注意されたい。

【0203】

sps_mixed_tile_groups_in_pic_flagが１に等しい場合に、以下の制約が適用されることがビットストリーム適合性の要件である。

【0204】

－ 現在のピクチャの全てのタイルグループがＩＤＲタイルグループである場合に、poc_msb_reset_flagの値は、現在のピクチャの全てのＩＤＲタイルグループに対して１に等しくしなければならない。

【0205】

－ 現在のピクチャにＩＤＲタイルグループとＩＤＲタイルグループではない少なくとも１つのタイルグループとが含まれている場合に、poc_msb_reset_flagの値は０に等しくしなければならない。

【0206】

注－ １に等しいpoc_msb_reset_flagの値は、現在のピクチャに複数のタイルグループがある場合に、全てのタイルグループがＩＤＲタイルグループであることを示す。

【0207】

注－ ＭＣＴＳが、sps_mixed_tile_groups_in_pic_flagｈが１に等しい元のビットストリームからサブビットストリームになるように抽出される場合に、抽出したサブビットストリームのアクティブＳＰＳにおけるsps_mixed_tile_groups_in_pic_flagの値は、０に等しく設定されなければならず、つまり、抽出したサブビットストリームでは、各ピクチャは、ＩＲＡＰタイルグループのみ又は非ＩＲＡＰタイルグループのみを含む必要がある。換言すると、１つのピクチャに属し、且つ１つのＭＣＴＳに属するタイルグループは、同じＮＡＬユニットタイプを含む必要がある。

【0208】

タイルグループ復号化プロセスについて議論する。

【0209】

復号化プロセスは、現在のピクチャCurrPicに対して以下のように動作する。

【0210】

１． ＮＡＬユニットの復号化は、以下のＮＡＬユニット復号化プロセスの節（clause）で指定される。

【0211】

２． タイルグループ復号化プロセスに関する節のプロセスは、タイルグループヘッダレイヤ以上の構文要素を使用して、以下の復号化プロセスを指定する。

【0212】

以下のピクチャ順序カウントの復号化プロセスに関する節で指定されるように、ピクチャ順序カウントに関連する変数及び関数が導出される。これは、ピクチャの最初のタイルグループに対してのみ呼び出す必要がある。

【0213】

［非ＩＤＲピクチャの］各タイルグループの復号化プロセスの開始時に、参照ピクチャリスト構成のための復号化プロセスが、参照ピクチャリスト０（RefPicList[0]）及び参照ピクチャリスト１（RefPicList[1]）の導出のために呼び出される。

【0214】

－ 参照ピクチャマーキングのための復号化プロセスが呼び出され、参照ピクチャは、「参照のために使用されない」又は「長期参照のために使用される」としてマークされ得る。これは、ピクチャの最初のタイルグループに対してのみ呼び出す必要がある。

【0215】

３． ツリーユニットのコーディング、スケーリング、変換、インループフィルタ処理等のための復号化プロセスを呼び出す。

【0216】

４．現在のピクチャの全てのスライスが復号化された後に、復号化した現在のピクチャは、「短期間の参照に使用される」としてマークされる。

【0217】

ＮＡＬユニット復号化プロセスについて議論する。

【0218】

このプロセスへの入力は、現在のピクチャのＮＡＬユニット及びそれらユニットに関連する非ＶＣＬ ＮＡＬユニットである。

【0219】

このプロセスの出力は、ＮＡＬユニット内にカプセル化された解析したＲＢＳＰ構文構造である。

【0220】

各ＮＡＬユニットのための復号化プロセスは、ＮＡＬユニットからＲＢＳＰ構文構造を抽出し、次に、ＲＢＳＰ構文構造を解析する。

【0221】

タイルグループ復号化プロセスについて議論する。

【0222】

ピクチャ順序カウントのための復号化プロセスが提供される。

【0223】

このプロセスの出力は、現在のピクチャのピクチャ順序カウント、PicOrderCntValである。

【0224】

ピクチャ順序カウントは、ピクチャを識別するため、マージモード及び動きベクトル予測における動きパラメータを導出するため、及びデコーダ適合性チェックのために使用される。

【0225】

コーディングした各ピクチャは、PicOrderCntValとして示されるピクチャ順序カウント変数に関連付けられる。

【0226】

｛PicRefreshFlagが０に等しい｝場合に、［現在のピクチャはＩＲＡＰピクチャではなく］、変数prevPicOrderCntLsb及びprevPicOrderCntMsbは次のように導出される。
－ prevTid0Picを、TemporalIDを０に等しくした、復号化順で以前のピクチャとする。
－ 変数prevPicOrderCntLsbは、prevTid0Picのslice_pic_order_cnt_lsbと等しく設定される。
－ 変数prevPicOrderCntMsbは、prevTid0PicのPicOrderCntMsbと等しく設定される。
現在のピクチャの変数PicOrderCntMsbは、次のように導出される。
－ ｛PicRefreshFlagが１に等しい｝場合に、［現在のピクチャはＩＲＡＰピクチャであり］、PicOrderCntMsbは０に等しく設定される。
－ それ以外の場合に、PicOrderCntMsbは次のように導出される。
if（（slice_pic_order_cnt_lsb < prevPicOrderCntLsb）&&
（（prevPicOrderCntLsb － slice_pic_order_cnt_lsb）> =（MaxPicOrderCntLsb/2）））
PicOrderCntMsb
= prevPicOrderCntMsb + MaxPicOrderCntLsb（8 1）
else
if（（slice_pic_order_cnt_lsb > prevPicOrderCntLsb）&& （（slice_pic_order_cnt_lsb － prevPicOrderCntLsb） > （MaxPicOrderCntLsb/2）））
PicOrderCntMsb
= prevPicOrderCntMsb － MaxPicOrderCntLsb

【0227】

そうでなければ、
PicOrderCntMsb
= prevPicOrderCntMsb
PicOrderCntValは次のように導出される。
PicOrderCntVal
= PicOrderCntMsb + slice_pic_order_cnt_lsb（8-2）

【0228】

［注１－ ＩＲＡＰピクチャのslice_pic_order_cnt_lsbが０であると推測され、prevPicOrderCntLsbとprevPicOrderCntMsbとが両方とも０に設定されているため、全てのＩＲＡＰピクチャのPicOrderCntValは０に等しくされるだろう。］

【0229】

PicOrderCntValの値は、－２^３１～２^３１－１の範囲（境界を含む：inclusive）でなければならない。１つのＣＶＳでは、任意の２つのコーディングしたピクチャのPicOrderCntVal値は同じであってはならない。

【0230】

復号化プロセス中の任意の時点で、ＤＰＢ内の任意の２つの参照ピクチャのPicOrderCntVal & （MaxLtPicOrderCntLsb -1）の値は同じであってはならない。

【0231】

関数PicOrderCnt（picX）は次のように指定される。

【0232】

PicOrderCnt（picX）= ピクチャpicXのPicOrderCntVal（8-3）

【0233】

関数DiffPicOrderCnt（picA, picB）は次のように指定される。

【0234】

DiffPicOrderCnt（picA, picB） = PicOrderCnt（picA） － PicOrderCnt（picB）（8-4）

【0235】

ビットストリームは、－２^１５～２^１５－１の範囲（境界を含む）ではない復号化プロセスで使用されるDiffPicOrderCnt（picA, picB）の値をもたらすデータを含んではならない。

【0236】

注２－ Ｘを現在のピクチャとし、Ｙ及びＺを同じＣＶＳ内の他の２つのピクチャとすると、DiffPicOrderCnt（X, Y）とDiffPicOrderCnt（X, Z）との両方が正、又は両方が負である場合に、Ｙ及びＺは、Ｘから同じ出力順序の方向にあると見なされる。

【0237】

参照ピクチャリスト構成のための復号化プロセスが提供される。

【0238】

このプロセスは、［非ＩＲＡＰピクチャの］各タイルグループの復号化プロセスの開始時に呼び出される。

【0239】

参照ピクチャは、参照インデックスを介してアドレス指定される。参照インデックスは、参照ピクチャリストへのインデックスである。Ｉタイルグループを復号化する場合に、タイルグループデータの復号化に参照ピクチャリストは使用されない。Ｐタイルグループを復号化する場合に、参照ピクチャリスト０（つまり、RefPicList[0]）のみがタイルグループデータの復号化に使用される。Ｂタイルグループを復号化する場合に、参照ピクチャリスト０と参照ピクチャリスト１（すなわち、RefPicList[1]）との両方が、タイルグループデータの復号化に使用される。

【0240】

非ＩＲＡＰピクチャの（左記は取消線で示される）各タイルグループの復号化プロセスの開始時に、参照ピクチャリストRefPicList[0]及びRefPicList[1]が導出される。参照ピクチャリストは、参照ピクチャのマーキング又はタイルグループデータの復号化に使用される。

【0241】

注１－ ［非ＩＲＡＰタイルグループである］Ｉタイルグループの場合に、RefPicList[0]及びRefPicList[1]は、ビットストリーム適合性チェックの目的で導出できるが、それらの導出は、現在のピクチャ、又は復号化順で現在のピクチャに続くピクチャを復号化するためには必要ない。Ｐタイルグループの場合に、ビットストリーム適合性チェックの目的でRefPicList[1]を導出できるが、その導出は、現在のピクチャ又は復号化順で現在のピクチャに続くピクチャを復号化するためには必要ない。

【0242】

参照ピクチャリストRefPicList[0]及びRefPicList[1]は、以下のように構成される。
for(
i = 0; i < 2; i++ ) {
if(
ref_pic_list_sps_flag[ i ] )
RplsIdx[
i ] = ref_pic_list_idx[ i ]
else
RplsIdx[
i ] = num_ref_pic_lists_in_sps[ i ]
for(
j = 0, pocBase = PicOrderCntVal; j < NumEntriesInList[ i ][ RplsIdx[ i ] ];
j++) { (8-5)
if(
!lt_ref_pic_flag[ i ][ RplsIdx[ i ] ][ j ] ) {
RefPicPocList[
i ][ j ] = pocBase － DeltaPocSt[ i ][ RplsIdx[ i ] ][ j ]
if(
there is a reference picture picA in the DPB with PicOrderCntVal equal to
RefPicPocList[ i ][ j ] )
RefPicList[
i ][ j ] = picA
else
RefPicList[
i ][ j ] = “no reference picture”
pocBase
= RefPicPocList[ i ][ j ]
}
else {
if(
there is a reference picA in the DPB with PicOrderCntVal & (
MaxLtPicOrderCntLsb － 1 )
equal
to poc_lsb_lt[ i ][ RplsIdx[ i ] ][ j ] )
RefPicList[
i ][ j ] = picA
else
RefPicList[
i ][ j ] = “no reference picture”
}
}
}

【0243】

各ｉが０又は１に等しい場合に、以下が適用される。
－ RefPicList[i]の最初のNumRefIdxActive[i]エントリは、RefPicList[i]のアクティブなエントリと呼ばれ、RefPicList[i]の他のエントリは、RefPicList[i]の非アクティブなエントリと呼ばれる。
－ ０～NumEntriesInList[i] [RplsIdx[i]] －1までの範囲（境界を含む）のjのRefPicList[i] [j]の各エントリは、lt_ref_pic_flag[i] [RplsIdx[i]] [j]が０に等しい場合に、ＳＴＲＰエントリと呼ばれ、それ以外の場合にはＬＴＲＰエントリと呼ばれる。

【0244】

注２－ 特定のピクチャがRefPicList[0]のエントリとRefPicList[1]のエントリとの両方によって参照される可能性がある。特定のピクチャがRefPicList[0]の複数のエントリ又はRefPicList[1]の複数のエントリによって参照される可能性もある。

【0245】

注３－ RefPicList[0]のアクティブなエントリとRefPicList[1]のアクティブなエントリは、現在のピクチャと復号化順で現在のピクチャに続く１つ又は複数のピクチャとのインター予測に使用できる全ての参照ピクチャをまとめて参照する。RefPicList[0]の非アクティブなエントリとRefPicList[1]の非アクティブなエントリは、現在のピクチャのインター予測には使用されないが、復号化順で現在のピクチャに続く１つ又は複数のピクチャのインター予測に使用され得る全ての参照ピクチャをまとめて参照する。

【0246】

注４－ 対応するピクチャがＤＰＢに存在しないため、「参照ピクチャなし」に等しいRefPicList[0]又はRefPicList[1]に１つ又は複数のエントリが存在する可能性がある。「参照ピクチャなし」に等しいRefPicList[0]又はRefPicList[0]の各非アクティブなエントリは無視する必要がある。「参照ピクチャなし」に等しいRefPicList[0]又はRefPicList[1]のアクティブなエントリ毎に、意図しないピクチャの損失を推測する必要がある。

【0247】

以下の制約が適用されることは、ビットストリーム適合性の要件である。

【0248】

各ｉが０又は１に等しい場合に、NumEntriesInList[i] [RplsIdx[i]]は、NumRefIdxActive[i]以上でなければならない。

【0249】

－ RefPicList[0]又はRefPicList[1]の各アクティブなエントリによって参照されるピクチャは、ＤＰＢに存在し、現在のピクチャのTemporalID以下であるTemporalIDを有しなければならない。

【0250】

－ ピクチャのスライスのRefPicList[0]又はRefPicList[1]のＳＴＲＰエントリ、及び同じスライスの又は同じピクチャの異なるスライスのRefPicList[0]又はRefPicList[1]のＬＴＲＰエントリは同じピクチャを参照してはならない。

【0251】

－ 現在のピクチャのPicOrderCntValとエントリによって参照されるピクチャのPicOrderCntValとの間の差が２^２４以上であるＬＴＲＰエントリがRefPicList[0]又はRefPicList[1]に存在してはならない。

【0252】

setOfRefPicsを、RefPicList[0]の全てのエントリ及びRefPicList[1]の全てのエントリによって参照される一意のピクチャのセットとする。setOfRefPics内のピクチャの数は、sps_max_dec_pic_buffering_minus1以下にしなければならず、setOfRefPicsは、ピクチャの全てのスライスで同じにしなければならない。

【0253】

参照ピクチャマーキングのための復号化プロセスが提供される。

【0254】

このプロセスは、タイルグループヘッダの復号化及びタイルグループの参照ピクチャリスト構成のための復号化プロセスの後であるが、タイルグループデータの復号化の前に、ピクチャ毎に１回呼び出される。このプロセスにより、ＤＰＢ内の１つ又は複数の参照ピクチャが、「参照に使用されない」又は「長期参照に使用される」とマークされ得る。

【0255】

ＤＰＢ内の復号化したピクチャは、「参照に使用されない」、「短期参照に使用される」、又は「長期参照に使用される」としてマークすることができるが、これら３つの中の１つのみが復号化プロセスの動作中に任意の所与の時点においてマークされ得る。これらのマーキングのうちの１つをピクチャに割り当てると、該当する場合に、これらのマーキングのうちの別のマーキングが暗黙的に削除される。ピクチャが「参照に使用される」とマークされていると参照される場合に、これは、まとめて「短期参照に使用される」又は「長期参照に使用される」とマークされているピクチャを指す（しかし、両方ではない）。

【0256】

［現在のピクチャがＩＲＡＰピクチャである場合に、現在ＤＰＢにある全ての参照ピクチャ（もしあれば）は、「参照に使用されない」としてマークされる。］

【0257】

ＳＴＲＰは、それらのPicOrderCntVal値によって識別される。ＬＴＲＰは、それらPicOrderCntVal値のＬｏｇ２（MaxLtPicOrderCntLsb）ＬＳＢによって識別される。

【0258】

以下が適用される。

【0259】

－ ｛PicRefreshFlagが１に等しい場合に、ＤＰＢ内の全ての参照ピクチャは、「参照に使用されない」としてマークされる。｝

【0260】

－ ｛それ以外の場合に（sps_mixed_tile_groups_in_pic_flagが１に等しいか、又は現在のタイルグループがＩＤＲタイルグループではない）、以下が適用される。｝

【0261】

｛「短期参照に使用される」とマークされたＤＰＢ内の各参照ピクチャについて、そのピクチャがRefPicList[0]又はRefPicList[1]のＬＴＲＰエントリによって参照される場合に、参照ピクチャは「長期参照に使用される。」としてマークされる。｝

【0262】

RefPicList[0]又はRefPicList[1]のどのエントリによっても参照されないＤＰＢ内の各参照ピクチャは、「参照に使用されない」としてマークされる。

【0263】

本開示の概念についてさらに議論する。

【0264】

上記の問題を解決するために、以下の態様を開示し、それら態様のそれぞれを個別に適用することができ、それら態様のいくつかを組み合わせて適用することができる。

【0265】

１）ピクチャが複数のサブピクチャを有する場合に、そのピクチャにＩＲＡＰサブピクチャと非ＩＲＡＰサブピクチャとの両方が含まれることが可能にされる。

【0266】

ａ． ピクチャ内のサブピクチャは、スライス、タイルグループ、ＭＣＴＳ、又はピクチャの任意の他のサブセットにすることができる。

【0267】

ｂ． サブピクチャは、通常、それ自体のＮＡＬユニットで排他的に伝送されるが、必ずしも常にそうであるとは限らない。

【0268】

２）ＭＣＴＳ記述のための情報は、パラメータセット、タイルグループヘッダ、又は補足強化情報（ＳＥＩ）メッセージに存在する／それらで信号通知され得る。

【0269】

３）あるいはまた、項目１）は、コーディングしたピクチャが複数のＮＡＬユニットで伝送される場合に、それらのＮＡＬユニットの１つ又は複数がＩＲＡＰ ＮＡＬユニットタイプであり、それらのＮＡＬユニットの１つ又は複数が非ＩＲＡＰ ＮＡＬユニットタイプ（トレイリングＮＡＬユニットタイプ）であり得るように表すことができる。

【0270】

４）ピクチャが複数のサブピクチャを有しており、サブピクチャがＩＲＡＰサブピクチャと非ＩＲＡＰサブピクチャとの混合である場合に、ピクチャは、０に等しいTemporalIDを有する必要がある。

【0271】

５）ピクチャが複数のサブピクチャを有しており、サブピクチャがＩＲＡＰサブピクチャと非ＩＲＡＰサブピクチャとの混合である場合に、ＩＲＡＰサブピクチャは、ＭＣＴＳの一部である必要があり得る。

【0272】

６）ピクチャが複数のサブピクチャを有しており、サブピクチャがＩＲＡＰサブピクチャと非ＩＲＡＰサブピクチャとの混合である場合に、アクセスユニット区切り文字が、ビットストリームに存在し、システム／アプリケーションがアクセスユニットを容易に識別できるように支援するために、ピクチャに関連付けられる必要がある。

【0273】

７）混合ＩＲＡＰ及び非ＩＲＡＰサブピクチャを含むピクチャが存在し得るかどうかを指定するために、タイルグループによって直接的又は間接的に参照されるパラメータセットにフラグが存在する。

【0274】

ａ． フラグは、シーケンスパラメータセット、ピクチャパラメータセット、又はタイルグループによって直接又は間接的に参照される別のタイプのパラメータセット等のパラメータセットで信号通知できる。特に、シーケンスパラメータセット内のフラグのシグナリングが好ましい場合がある。

【0275】

ｂ． フラグはsps_mixed_tile_groups_in_pic_flagと呼ばれ得る。

【0276】

８）ＩＤＲタイルグループを含むＮＡＬユニットの場合に、ピクチャのＰＯＣ導出においてＰＯＣ ＭＳＢがリセットされるかどうかを指定するために、そのタイルグループヘッダにフラグが存在する。

【0277】

９）PicRefreshFlagと呼ばれる変数が、規定され、ピクチャに関連付けられる。このフラグは、ピクチャを復号化するときにＰＯＣの導出及びＤＰＢの状態をリフレッシュする必要があるかどうかを指定する。

【0278】

１０）PicRefreshFlagの値は、以下のように導出される。

【0279】

ａ． 現在のタイルグループがビットストリームの最初のアクセスユニットに属する場合に、PicRefreshFlagは１に等しく設定される。

【0280】

ｂ． それ以外の場合に、現在のタイルグループがＩＤＲタイルグループである場合に、PicRefreshFlagは、sps_mixed_tile_groups_in_pic_flag
? poc_msb_reset_flag：１に等しく設定される。

【0281】

ｃ． それ以外の場合に、現在のタイルグループがＣＲＡタイルグループである場合に、以下が適用される。

【0282】

ｉ． 現在のアクセスユニットがコーディングしたシーケンスの最初のアクセスユニットである場合に（つまり、そのアクセスユニットがシーケンスの終わりのＮＡＬユニットの直後に続く場合に、又は関連する変数HandleCraAsFirstPicInCvsFlagが１に等しい場合に）、PicRefreshFlagは１に等しく設定される。

【0283】

ｉｉ． それ以外の場合に、PicRefreshFlagは０に等しく設定される。

【0284】

ｄ． それ以外の場合に（現在のタイルグループはビットストリームの最初のアクセスユニットに属しておらず、ＩＲＡＰタイルグループではない）、PicRefreshFlagは０に等しく設定される。

【0285】

１１）PicRefreshFlagが１に等しい場合に、ピクチャのＰＯＣの導出中に、ＰＯＣ ＭＳＢの値（つまり、PicOrderCntMsb）がリセットされる（つまり、０に等しく設定される）。

【0286】

１２）sps_mixed_tile_group_in_pic_flagが１に等しい場合に、以下の制約が適用される。

【0287】

ａ． 現在のピクチャの全てのタイルグループがＩＤＲタイルグループである場合に、poc_msb_reset_flagの値は、現在のピクチャの全てのＩＤＲタイルグループについて１に等しくしなければならない。

【0288】

ｂ． 現在のピクチャにＩＤＲタイルグループとＩＤＲタイルグループではない少なくとも１つのタイルグループとが含まれている場合に、poc_msb_reset_flagの値は０に等しくしなければならない。

【0289】

１３）ＭＣＴＳが、sps_mixed_tile_groups_in_pic_flagが１に等しい元のビットストリームからサブビットストリームになるように抽出される場合に、抽出したサブビットストリームのアクティブなＳＰＳのsps_mixed_tile_groups_in_pic_flagの値を０に等しく設定する必要があり、つまり、抽出したサブビットストリームでは、各ピクチャは、ＩＲＡＰタイルグループのみ又は非ＩＲＡＰタイルグループのみを含む必要がある。換言すると、１つのピクチャに属し、且つ１つのＭＣＴＳに属するタイルグループは、同じＮＡＬユニットタイプを含まなければならないという必要がある。

【0290】

１４）参照ピクチャセット（ＲＰＳ）又は参照ピクチャリスト（ＲＰＬ）等の参照ピクチャ管理に必要な情報は、そのＮＡＬユニットタイプに関係なく、タイルグループヘッダで信号通知される。あるいはまた、そのような情報は、ピクチャヘッダでのみ通知される場合がある（ピクチャヘッダが存在する場合に）。

【0291】

１５）参照ピクチャリスト（例えば、ＲＰＬアプローチの場合にはRefPicList[0]及びRefPicList[1]、又はＲＰＳアプローチの場合にはRefPicList0[]及びRefPicList1[]、又はピクチャのインター予測動作のための参照ピクチャを含む同様のリスト）は、そのＮＡＬユニットタイプに関係なく、各タイルグループの復号化の開始時に構成される。

【0292】

１６）参照ピクチャマーキングプロセスは、ＤＰＢ内の各参照ピクチャが、信号通知された参照ピクチャ管理情報（例えば、ＲＰＬアプローチの場合にはRefPicList[0]及びRefPicList[1]）、又はＲＰＳアプローチの場合にはＲＰＳサブセット）のエントリによって参照されているかどうかをチェックすることによって行われる。

【0293】

１７）PicRefreshFlagが１に等しい場合に、参照ピクチャマーキングプロセス中に、ＤＰＢ内の全ての参照ピクチャは「参照に使用されない」としてマークされる。

【0294】

１８）ＲＰＬアプローチのための参照ピクチャマーキングプロセスの詳細は以下の通りである。

【0295】

ａ． PicRefreshFlagが１に等しい場合に、ＤＰＢ内の全ての参照ピクチャは「参照に使用されない」としてマークされる。

【0296】

ｂ． それ以外の場合には、以下が適用される。

【0297】

ｉ． 「短期参照に使用される」とマークされたＤＰＢの各参照ピクチャについて、それ（参照ピクチャ）がRefPicList[0]又はRefPicList[1]のＬＴＲＰエントリによって参照されると、参照ピクチャは「長期参照に使用される」とマークされる。

【0298】

ｉｉ．RefPicList[0]又はRefPicList[1]のどのエントリによっても参照されない、ＤＰＢ内の各参照ピクチャは、「参照に使用されない」としてマークされる。

【0299】

図９は、本開示の一実施形態による、ビデオコーディング装置９００（例えば、ビデオエンコーダ２０又はビデオデコーダ３０）の概略図である。ビデオコーディング装置９００は、本明細書で説明した開示される実施形態を実施するのに適している。ビデオコーディング装置９００は、データを受信するための入力ポート９１０及び受信機ユニット（Ｒｘ）９２０と；データを処理するためのプロセッサ、論理ユニット、又は中央処理装置（ＣＰＵ）９３０と；データを送信するための送信機ユニット（Ｔｘ）９４０及び出力ポート９５０と；データを格納するためのメモリ９６０と；を含む。ビデオコーディング装置９００は、光信号又は電気信号の出力又は入力のための入力ポート９１０、受信機ユニット９２０、送信機ユニット９４０、及び出力ポート９５０に結合した光／電気（ＯＥ：optical-to-electrical）コンポーネント及び電気／光（ＥＯ：electrical-to-optical）コンポーネントも含み得る。

【0300】

プロセッサ９３０は、ハードウェア及びソフトウェアによって実装される。プロセッサ９３０は、１つ又は複数のＣＰＵチップ、コア（例えば、マルチコアプロセッサとして）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、及びデジタル信号プロセッサ（ＤＳＰ）として実装され得る。プロセッサ９３０は、入力ポート９１０、受信機ユニット９２０、送信機ユニット９４０、出力ポート９５０、及びメモリ９６０と通信している。プロセッサ９３０は、コーディングモジュール９７０を含む。コーディングモジュール９７０は、上記の開示した実施形態を実施する。例えば、コーディングモジュール９７０は、様々なネットワーキング機能を実装、処理、準備、又は提供する。従って、コーディングモジュール９７０を含めることは、ビデオコーディング装置９００の機能に実質的な改善を与え、ビデオコーディング装置９００の異なる状態への変換をもたらす。あるいはまた、コーディングモジュール９７０は、メモリ９６０に格納され、プロセッサ９３０によって実行される命令として実装される。

【0301】

ビデオコーディング装置９００は、ユーザとの間でデータを通信するための入力及び／又は出力（Ｉ／Ｏ）装置９８０も含み得る。Ｉ／Ｏ装置９８０は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカ等の出力装置を含み得る。Ｉ／Ｏ装置９８０は、キーボード、マウス、トラックボール等の入力装置、及び／又はそのような出力装置と相互作用するための対応するインターフェイスを含み得る。

【0302】

メモリ９６０は、１つ又は複数のディスク、テープドライブ、及びソリッドステートドライブを含み、オーバーフローデータ記憶装置として使用され、そのようなプログラムが実行のために選択されたときにプログラムを格納し、プログラムの実行中に読み出される命令及びデータを格納することができる。メモリ９６０は、揮発性及び／又は不揮発性であってもよく、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、三元連想メモリ（ＴＣＡＭ）、及び／又はスタティックランダムアクセスメモリ（ＳＲＡＭ）であってもよい。

【0303】

図１０は、コーディングするための手段１０００の一実施形態の概略図である。実施形態では、コーディングするための手段１０００は、ビデオコーディング装置１００２（例えば、ビデオエンコーダ２０又はビデオデコーダ３０）に実装される。ビデオコーディング装置１００２は、受信手段１００１を含む。受信手段１００１は、符号化すべきピクチャを受信する、又は復号化すべきビットストリームを受信するように構成される。ビデオコーディング装置１００２は、受信手段１００１に結合した送信手段１００７を含む。送信手段１００７は、ビットストリームをデコーダに送信するか、又は復号化した画像を表示手段（例えば、Ｉ／Ｏ装置９８０のうちの１つ）に送信するように構成される。

【0304】

ビデオコーディング装置１００２は、記憶手段１００３を含む。記憶手段１００３は、受信手段１００１又は送信手段１００７の少なくとも一方に結合される。記憶手段１００３は、命令を記憶するように構成される。ビデオコーディング装置１００２は、処理手段１００５も含む。処理手段１００５は、記憶手段１００３に結合される。処理手段１００５は、記憶手段１００３に記憶された命令を実行して、本明細書で開示する方法を実行するように構成される。

【0305】

本明細書に記載の例示的な方法のステップは、必ずしも説明した順序で実行する必要はなく、そのような方法のステップの順序は、単に例示的なものであると理解すべきであることも理解されたい。同様に、本開示の様々な実施形態と一致する方法において、追加のステップをそのような方法に含めてもよく、特定のステップを省略又は組み合わせてもよい。

【0306】

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

【0307】

さらに、様々な実施形態で離散的又は別個として説明及び図示した技術、システム、サブシステム、及び方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、又は方法と組み合わせ又は統合することができる。互いに結合又は直接結合又は通信するものとして示し又は議論した他のアイテムは、電気的、機械的、又は他の方法で、何らかのインターフェイス、装置、又は中間コンポーネントを介して間接的に結合又は通信することができる。変更、置換、及び交替の他の例は、当業者によって確認可能であり、本明細書に開示する精神及び範囲から逸脱することなく行うことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】