(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-10
(45)【発行日】2023-10-18
(54)【発明の名称】エンコーダ、デコーダおよび対応する方法
(51)【国際特許分類】
H04N 19/70 20140101AFI20231011BHJP
H04N 19/593 20140101ALI20231011BHJP
【ＦＩ】
H04N19/70
H04N19/593
【請求項の数】
20
(21)【出願番号】P 2021554681
(86)(22)【出願日】2020-03-11
(65)【公表番号】
(43)【公表日】2022-05-10
(86)【国際出願番号】 US2020022179
(87)【国際公開番号】W WO2020185956
(87)【国際公開日】2020-09-17
【審査請求日】2021-11-10
(31)【優先権主張番号】62/816,722
(32)【優先日】2019-03-11
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/871,020
(32)【優先日】2019-07-05
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ワーン，イエ－クイ
(72)【発明者】
【氏名】ヘンドリー，フヌ
(72)【発明者】
【氏名】チェン，ジエンローァ
【審査官】田部井 和彦
(56)【参考文献】
【文献】Lulin Chen, Chih-Wei Hsu, Yu-Wen Huang, Shaw-Min Lei ，AHG17: Signalling random access properties in the NAL unit header [online]， JVET-M JVET-M0161-v2，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/13_Marrakech/wg11/JVET-M0161-v2.zip＞，2019年01月09日，pp.1-5
【文献】Benjamin Bross Jianle Chen Shan Liu，Versatile Video Coding (Draft 4) [online]， JVET-N JVET-M1001-v5，ITU-T インターネット＜URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/14_Geneva/wg11/JVET-N0115-v1.zip＞，2019年03月12日，pp.1, 3, 58
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ １９／７０
Ｈ０４Ｎ １９／５９３
(57)【特許請求の範囲】
【請求項1】
ビデオ・デコーダによって実装される、コーディングされたビデオ・ビットストリームをデコードする方法であって：前記ビデオ・デコーダによって、前記コーディングされたビデオ・ビットストリームを受領する段階であって、前記コーディングされたビデオ・ビットストリームは複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位を含むコーディングされたビデオ・シーケンス（CVS）を含み、各VCL NAL単位は漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有し、前記GDR_NUTを有する前記複数のVCL NAL単位はコーディングされたGDRピクチャーを含み、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；
前記ビデオ・デコーダによって、前記コーディングされたGDRピクチャーから前記CVSのデコードを開始する段階とを含む、
方法。
【請求項2】
前記GDRピクチャーは前記CVSにおける最初のピクチャーである、請求項１に記載の方法。
【請求項3】
前記GDRピクチャーは、GDR期間における最初のピクチャーである、請求項１に記載の方法。
【請求項4】
前記GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する、請求項１ないし３のうちいずれか一項に記載の方法。
【請求項5】
前記GDR_NUTは、前記GDR_NUTを有する前記複数のVCL NAL単位が前記コーディングされたGDRピクチャーを含むことを前記ビデオ・デコーダに示す、請求項１ないし４のうちいずれか一項に記載の方法。
【請求項6】
ビデオ・エンコーダによって実装される、ビデオ・ビットストリームをエンコードする方法であって：前記ビデオ・エンコーダによって、ビデオ・シーケンスについて漸進的デコード・リフレッシュ（GDR）ピクチャーを取得する段階と；
前記ビデオ・エンコーダによって、前記GDRピクチャーを、前記ビデオ・シーケンスについての漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位にエンコードする段階であって、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；
前記ビデオ・エンコーダによって、前記GDR_NUTを有する前記複数のVCL NAL単位を有する前記ビデオ・シーケンスを含むビットストリームを生成する段階とを含む、
方法。
【請求項7】
前記GDRピクチャーは前記CVSにおける最初のピクチャーである、請求項６に記載の方法。
【請求項8】
前記GDRピクチャーは、GDR期間における最初のピクチャーである、請求項６に記載の方法。
【請求項9】
前記GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する、請求項６ないし８のうちいずれか一項に記載の方法。
【請求項10】
前記GDR_NUTは、前記GDR_NUTを有する前記VCL NAL単位が前記コーディングされたGDRピクチャーを含むことを前記ビデオ・デコーダに示す、請求項６ないし９のうちいずれか一項に記載の方法。
【請求項11】
コーディングされたビデオ・ビットストリームを受領するように構成された受領器と；命令を記憶している、前記受領器に結合されたメモリと；
前記メモリに結合されたプロセッサとを有するデコード装置であって、前記プロセッサは、前記命令を実行して、当該デコード装置に：
前記コーディングされたビデオ・ビットストリームを受領する段階であって、前記コーディングされたビデオ・ビットストリームは複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位を含むコーディングされたビデオ・シーケンス（CDS）を含み、各VCL NAL単位は漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有し、前記GDR_NUTを有する前記複数のVCL NAL単位はコーディングされたGDRピクチャーを含み、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；
前記コーディングされたGDRピクチャーから前記CVSのデコードを開始する段階とを実行させるように構成されている、
デコード装置。
【請求項12】
デコードされた前記CVSに従って生成された画像を表示するように構成されたディスプレイをさらに有する、請求項１１に記載のデコード装置。
【請求項13】
エンコード装置であって：命令を記憶しているメモリと；
前記メモリに結合されたプロセッサであって、前記プロセッサは、前記命令を実行して、当該エンコード装置に：
ビデオ・シーケンスについて漸進的デコード・リフレッシュ（GDR）ピクチャーを取得する段階と；
前記GDRピクチャーを、前記ビデオ・シーケンスについての漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位にエンコードする段階であって、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；
前記GDR_NUTを有する前記複数のVCL NAL単位を有する前記ビデオ・シーケンスを含むビットストリームを生成する段階とを実行させるように構成されているプロセッサとを有する、
エンコード装置。
【請求項14】
前記メモリは、前記ビットストリームを前記ビデオ・デコーダに向けて送信する前に、前記ビットストリームを記憶する、請求項１３に記載のエンコード装置。
【請求項15】
請求項１ないし５のうちいずれか一項に記載の方法を実行するための処理回路を有するデコーダ。
【請求項16】
請求項６ないし１０のうちいずれか一項に記載の方法を実行するための処理回路を有するエンコーダ。
【請求項17】
コンピュータまたはプロセッサに請求項１ないし１０のうちいずれか一項に記載の方法を実行させるためのコンピュータ・プログラム。
【請求項18】
コンピュータ装置によって実行されたときに請求項１ないし１０のうちいずれか一項に記載の方法を該コンピュータ装置に実行させるプログラム・コードを担持している非一時的なコンピュータ読み取り可能媒体。
【請求項19】
コーディングされたビデオ・ビットストリームを受領するように構成された受領ユニットであって、前記コーディングされたビデオ・ビットストリームは複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位を含むコーディングされたビデオ・シーケンス（CVS）を含み、各VCL NAL単位は漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有し、前記GDR_NUTを有する前記複数のVCL NAL単位はコーディングされたGDRピクチャーを含み、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；前記コーディングされたGDRピクチャーから前記CVSのデコードを開始するように構成されたデコード・ユニットとを有する、
デコーダ。
【請求項20】
ビデオ・シーケンスについて漸進的デコード・リフレッシュ（GDR）ピクチャーを取得するように構成された取得ユニットと；前記GDRピクチャーを、前記ビデオ・シーケンスについての漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する複数のビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位にエンコードする段階であって、前記GDR_NUTを有する前記複数のVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される、段階と；
前記GDR_NUTを有する前記複数のVCL NAL単位を有する前記ビデオ・シーケンスを含むビットストリームを生成する段階とを実行するように構成されたエンコード・ユニットとを有する、
エンコーダ。
【発明の詳細な説明】
【技術分野】
【0002】
技術分野
一般に、本開示は、ビデオ・コーディングにおける漸進的デコード・リフレッシュ（gradual decoding refresh）をサポートする技術を記載する。より具体的には、本開示は、イントラ・ランダム・アクセス・ポイント（intra random access point、IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュ（progressive intra refresh）を許容する。
一般に、本開示は、ビデオ・コーディングにおける漸進的デコード・リフレッシュ（gradual decoding refresh）をサポートする技術を記載する。より具体的には、本開示は、イントラ・ランダム・アクセス・ポイント（intra random access point、IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュ（progressive intra refresh）を許容する。
【背景技術】
【0003】
比較的短いビデオを描写するために必要とされるビデオ・データの量でさえ、かなりになることがあり、そのことは、限られた帯域幅容量をもつ通信ネットワークを通じてデータがストリーミングされるかまたは他の仕方で通信される場合に、困難を生じる可能性がある。よって、ビデオ・データは、一般に、現代の遠隔通信ネットワークを通じて通信される前に圧縮される。メモリ資源が制限される可能性があるため、ビデオが記憶装置に記憶される場合にも、ビデオのサイズが問題となる可能性がある。ビデオ圧縮装置は、しばしば、伝送または記憶の前にビデオ・データをコーディングするために源においてソフトウェアおよび／またはハードウェアを使用し、それによりデジタルビデオ画像を表わすのに必要とされるデータの量を減少させる。次いで、圧縮されたデータは、ビデオ・データをデコードするビデオ圧縮解除装置によって宛先で受領される。限られたネットワーク資源およびますます増大する、より高いビデオ品質の要求のため、画像品質の犠牲がほとんどまたは全くない、圧縮比を改善する改良された圧縮および圧縮解除技術が望ましい。
【発明の概要】
【0004】
第1の側面は、ビデオ・デコーダによって実装される、コーディングされたビデオ・ビットストリームをデコードする方法に関する。この方法は、ビデオ・デコーダによって、コーディングされたビデオ・ビットストリームのコーディングされたビデオ・シーケンス（coded video sequence、CVS）が、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位を含むことを判別する段階であって、前記GDR_NUTを有する前記VCL NAL単位はGDRピクチャーを含む、段階と；前記ビデオ・デコーダによって、前記GDRピクチャーにおいて前記CVSのデコードを開始する段階と；前記ビデオ・デコーダによって、デコードされた前記CVSに従って画像を生成する段階とを含む。
【0005】
本方法は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0006】
第1の側面そのものによる方法の第1の実装形態では、GDRピクチャーはCVSにおける最初のピクチャーである。
【0007】
第1の側面そのものまたは第1の側面の任意の先行する実装形態による方法の第2の実装形態では、GDRピクチャーは、GDR期間における最初のピクチャーである。
【0008】
第1の側面そのものまたは第1の側面の任意の先行する実装形態による方法の第3の実装形態では、GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する。
【0009】
第1の側面そのものまたは第1の側面の任意の先行する実装形態による方法の第4の実装形態では、GDR_NUTを有するVCL NAL単位を含むアクセス単位は、GDRアクセス単位と称される。
【0010】
第1の側面そのものまたは第1の側面の任意の先行する実装形態による方法の第5の実装形態では、GDR_NUTは、GDR_NUTを有するVCL NAL単位がGDRピクチャーを含むことをビデオ・デコーダに示す。
【0011】
第2の側面は、ビデオ・エンコーダによって実装される、ビデオ・ビットストリームをエンコードする方法に関する。この方法は、前記ビデオ・エンコーダによって、ビデオ・シーケンスについてランダム・アクセス・ポイントを決定する段階と；前記ビデオ・エンコーダによって、漸進的デコード・リフレッシュ（GDR）ピクチャーを、前記ビデオ・シーケンスについての前記ランダム・アクセス・ポイントにおいて、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位にエンコードする段階と；前記ビデオ・エンコーダによって、前記ランダム・アクセス・ポイントにおいて前記GDR_NUTを有する前記VCL NAL単位において前記GDRピクチャーを有する前記ビデオ・シーケンスを含むビットストリームを生成する段階と；前記ビデオ・エンコーダによって、前記ビットストリームを、ビデオ・デコーダに向けた送信のために記憶する段階とを含む。
【0012】
本方法は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0013】
第2の側面そのものによる方法の第1の実装形態では、GDRピクチャーはCVSにおける最初のピクチャーである。
【0014】
第2の側面そのものまたは第2の側面の任意の先行する実装形態による方法の第2の実装形態では、GDRピクチャーは、GDR期間における最初のピクチャーである。
【0015】
第2の側面そのものまたは第2の側面の任意の先行する実装形態による方法の第3の実装形態では、GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する。
【0016】
第2の側面そのものまたは第2の側面の任意の先行する実装形態による方法の第4の実装形態では、GDR_NUTを有するVCL NAL単位は、GDRアクセス単位と称される。
【0017】
第2の側面そのものまたは第2の側面の任意の先行する実装形態による方法の第5の実装形態では、GDR_NUTは、GDR_NUTを有するVCL NAL単位がGDRピクチャーを含むことをビデオ・デコーダに示す。
【0018】
第3の側面は、デコード装置に関する。デコード装置は、コーディングされたビデオ・ビットストリームを受領するように構成された受領器と；命令を記憶している、前記受領器に結合されたメモリと；前記メモリに結合されたプロセッサとを含み、前記プロセッサは、前記命令を実行して、当該デコード装置に：前記コーディングされたビデオ・ビットストリームのコーディングされたビデオ・シーケンス（coded video sequence、CDS）が、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位を含むことを判別する段階であって、前記GDR_NUTを有する前記VCL NAL単位はGDRピクチャーを含む、段階と；前記GDRピクチャーにおいて前記CVSのデコードを開始する段階と；デコードされた前記CVSに従って画像を生成する段階とを実行させるように構成されている。
【0019】
デコード装置は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0020】
第3の側面そのものによるデコード装置の第1の実装形態では、デコード装置はさらに、生成された画像を表示するように構成されたディスプレイを有する。
【0021】
第4の側面は、エンコード装置に関する。エンコード装置は、命令を記憶しているメモリと；前記メモリに結合されたプロセッサであって、前記プロセッサは、前記命令を実行して、当該エンコード装置に：ビデオ・シーケンスについてランダム・アクセス・ポイントを決定する段階と；漸進的デコード・リフレッシュ（GDR）ピクチャーを、前記ビデオ・シーケンスについての前記ランダム・アクセス・ポイントにおいて、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位にエンコードする段階と；前記ランダム・アクセス・ポイントにおいて前記GDR_NUTを有する前記VCL NAL単位において前記GDRピクチャーを有する前記ビデオ・シーケンスを含むビットストリームを生成する段階とを実行させるように構成されているプロセッサと；前記ビットストリームを、ビデオ・デコーダに向けて送信するように構成された、前記プロセッサに結合された送信器とを含む。
【0022】
エンコード装置は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0023】
第4の側面そのものによるエンコード装置の第1の実装形態では、前記メモリは、前記送信器が前記ビットストリームを前記ビデオ・デコーダに向けて送信する前に、前記ビットストリームを記憶する。
【0024】
第5の側面は、コーディング装置に関する。コーディング装置は、エンコードすべきピクチャーを受領する、またはデコードすべきビットストリームを受領するように構成された受信器と；前記受信器に結合された送信器であって、前記送信器は、前記ビットストリームをデコーダに送信するか、デコードされた画像をディスプレイに送信するように構成されている、送信器と；前記受信器または前記送信器のうちの少なくとも1つに結合されたメモリであって、前記メモリは、命令を記憶するように構成されている、メモリと；前記メモリに結合されたプロセッサであって、前記プロセッサは、前記メモリに記憶された命令を実行して、本明細書に開示される方法のいずれかを実行するように構成されている、プロセッサとを含む。
【0025】
コーディング装置は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0026】
第6の側面は、システムに関する。システムは、エンコーダと；前記エンコーダと通信するデコーダとを含み、前記エンコーダまたは前記デコーダは、本願に開示されるデコード装置、エンコード装置、またはコーディング装置を含む。
【0027】
システムは、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【0028】
第7の側面は、コーディング手段に関する。コーディング手段は、エンコードすべきピクチャーを受領する、またはデコードすべきビットストリームを受領するように構成された受信手段と；前記受信手段に結合された送信手段であって、前記送信手段は、前記ビットストリームをデコード手段に送信するか、デコードされた画像を表示手段に送信するように構成されている、送信手段と；前記受信手段または前記送信手段のうちの少なくとも1つに結合された記憶手段であって、前記記憶手段は、命令を記憶するように構成されている、記憶手段と；前記記憶手段に結合された処理手段であって、前記処理手段は、前記記憶手段に記憶された命令を実行して、本明細書に開示される方法のいずれかを実行するように構成されている、処理手段とを含む。
【0029】
コーディング手段は、イントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーを使用する必要なくランダム・アクセスを可能にするプログレッシブ・イントラ・リフレッシュを許容する技術を提供する。ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックに比して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーにより良いユーザー体験を提供する。
【図面の簡単な説明】
【0030】
本開示のより完全な理解のために、添付の図面および詳細な説明との関連で参酌される、以下の簡単な説明を参照しておく。ここで、同様の参照符号は同様の部分を表す。
【0031】
【図1】GDR技術を利用しうる例示的なコーディング・システムを示すブロック図である。
【0032】
【図2】GDR技術を実装することができる例示的なビデオ・エンコーダを示すブロック図である。
【0033】
【図3】GDR技術を実装することができるビデオ・デコーダの一例を示すブロック図である。
【0034】
【図4】デコード順および呈示順における、先頭ピクチャーおよび後続ピクチャーに対するイントラ・ランダム・アクセス・ポイント（IRAP）ピクチャーの間の関係の表現である。
【0035】
【図5】漸進的デコード・リフレッシュ技術を示す。
【0036】
【図6】望ましくない動き探索を示す概略図である。
【0037】
【図7】本開示のある実施形態による、漸進的デコード・リフレッシュ技術を示すビットストリームを示す。
【0038】
【図8】コーディング・ビデオ・ビットストリームをデコードする方法の実施形態である。
【0039】
【図9】ビデオ・ビットストリームをエンコードする方法の実施形態である。
【0040】
【図10】ビデオ・コーディング装置の概略図である。
【0041】
【図11】コーディング手段の実施形態の概略図である。
【発明を実施するための形態】
【0042】
図1は、本明細書に記載されるビデオ・コーディング技術を利用することができる例示的なコーディング・システム10を示すブロック図である。図1に示されるように、コーディング・システム10は、後刻、宛先装置14によってデコードされるべきエンコードされたビデオ・データを提供する源装置12を含む。具体的には、源装置12は、コンピュータ読み取り可能媒体16を介して、ビデオ・データを宛先装置14に提供してもよい。源装置12および宛先装置14は、デスクトップコンピュータ、ノートブック（たとえばラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話端末、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイ装置、デジタルメディアプレーヤー、ビデオゲーム機、ビデオストリーミング装置等を含む、広範囲の装置の任意のものを含みうる。いくつかの場合には、源装置12および宛先装置14は、無線通信のために装備されてもよい。
【0043】
宛先装置14は、デコードされるべきエンコードされたビデオ・データを、コンピュータ読み取り可能媒体16を介して受領してもよい。コンピュータ読み取り可能媒体16は、エンコードされたビデオ・データを源装置12から宛先装置14へ移動させることができる任意の型の媒体または装置を含みうる。一例では、コンピュータ読み取り可能媒体16は、源装置12がエンコードされたビデオ・データを宛先装置14にリアルタイムで直接送信できるようにする通信媒体を含んでいてもよい。エンコードされたビデオ・データは、無線通信プロトコルのような通信標準に従って変調され、宛先装置14に送信されてもよい。通信媒体は、無線周波数（RF）スペクトルまたは一つまたは複数の物理的な伝送線のような任意の無線または有線の通信媒体を含みうる。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークのようなパケットベースのネットワークの一部を形成してもよい。通信媒体は、ルーター、スイッチ、基地局、または源装置12から宛先装置14への通信を容易にするために有用でありうる他の設備を含みうる。
【0044】
いくつかの例では、エンコードされたデータは、出力インターフェース22から記憶装置に出力されうる。同様に、エンコードされたデータは、入力インターフェースによって記憶装置からアクセスされてもよい。記憶装置は、ハードドライブ、ブルーレイディスク、デジタルビデオディスク（DVD）、コンパクトディスク読み出し専用メモリ（CD-ROM）、フラッシュメモリ、揮発性または不揮発性メモリ、またはエンコードされたビデオ・データを記憶するための任意の他の好適なデジタル記憶媒体のような、多様な分散されたまたは局所的にアクセスされるデータ記憶媒体の任意のものを含みうる。あるさらなる例では、記憶装置は、源装置12によって生成されたエンコードされたビデオを記憶することができるファイル・サーバーまたは別の中間記憶装置に対応してもよい。宛先装置14は、ストリーミングまたはダウンロードを介して、記憶装置からの記憶されたビデオ・データにアクセスすることができる。ファイル・サーバーは、エンコードされたビデオ・データを記憶し、そのエンコードされたビデオ・データを宛先装置14に送信することができる任意の型のサーバーでありうる。例示的なファイル・サーバーは、ウェブサーバー（たとえばウェブサイト用）、ファイル転送プロトコル（FTP）サーバー、ネットワークアタッチト記憶（NAS）装置、またはローカルディスクドライブを含む。宛先装置14は、インターネット接続を含む任意の標準的なデータ接続を通じて、エンコードされたビデオ・データにアクセスすることができる。これは、無線チャネル（たとえば、Wi-Fi接続）、有線接続（たとえば、デジタル加入者線（DSL）、ケーブルモデム等）、またはファイル・サーバーに記憶されたエンコードされたビデオ・データにアクセスするのに好適な両方の組み合わせを含むことができる。記憶装置からのエンコードされたビデオ・データの伝送は、ストリーミング伝送、ダウンロード伝送、またはそれらの組み合わせであってもよい。
【0045】
本開示の技術は、無線アプリケーションまたは設定に必ずしも限定されない。この技術は、無線テレビジョン放送、ケーブルテレビジョン伝送、衛星テレビジョン伝送、インターネットストリーミングビデオ伝送、たとえばHTTP上での動的適応ストリーミング（DASH）、データ記憶媒体上にエンコードされたデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオのデコード、または他のアプリケーションのような、多様なマルチメディア・アプリケーションの任意のものをサポートするビデオ・コーディングに適用されうる。いくつかの例では、コーディング・システム10は、ビデオストリーミング、ビデオ再生、ビデオ放送、および／またはビデオ電話などのアプリケーションをサポートするために、一方向または双方向のビデオ伝送をサポートするように構成されてもよい。
【0046】
図1の例では、源装置12は、ビデオ源18、ビデオ・エンコーダ20、および出力インターフェース22を含む。宛先装置14は、入力インターフェース28、ビデオ・デコーダ30、および表示装置32を含む。本開示によれば、源装置12のビデオ・エンコーダ20および／または宛先装置14のビデオ・デコーダ30は、ビデオ・コーディングのための技術を適用するように構成されてもよい。他の例では、源装置および宛先装置は、他の構成要素または配置を含んでいてもよい。たとえば、源装置12は、外部カメラなどの外部ビデオ源からビデオ・データを受領してもよい。同様に、宛先装置14は、統合された表示装置を含むのではなく、外部表示装置とインターフェースをもってもよい。
【0047】
図1の示されたコーディング・システム10は、単に一例である。ビデオ・コーディングのための技術は、任意のデジタルビデオ・エンコードおよび／またはデコード装置によって実行されうる。本開示の技術は、一般に、ビデオ・コーディング装置によって実行されるが、技術は、典型的には「コーデック」と呼ばれるビデオ・エンコーダ／デコーダによって実行されてもよい。さらに、本開示の技術は、ビデオ・プリプロセッサによって実行されてもよい。ビデオ・エンコーダおよび／またはデコーダは、グラフィックス処理ユニット（GPU）または類似の装置であってもよい。
【0048】
源装置12および宛先装置14は、単にそのようなコーディング装置の例であり、ここで、源装置12が宛先装置14への伝送のためのコーディング・ビデオ・データを生成する。いくつかの例では、源装置12および宛先装置14は、実質的に対称的な仕方で動作することができ、そのため、源装置12および宛先装置14のそれぞれがビデオ・エンコードおよびデコード・コンポーネントを含む。よって、コーディング・システム10は、たとえばビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のために、ビデオ装置12、14間の一方向または双方向ビデオ伝送をサポートすることができる。
【0049】
源装置12のビデオ源18は、ビデオカメラのようなビデオ捕捉装置、以前に捕捉されたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダーからビデオを受け取るためのビデオフィードインターフェースを含むことができる。さらなる代替として、ビデオ源18は、源ビデオとしてのコンピュータグラフィックスベースのデータを、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組み合わせを生成してもよい。
【0050】
いくつかの場合には、ビデオ源18がビデオカメラであるとき、源装置12および宛先装置14は、いわゆるカメラ電話またはビデオ電話を形成することができる。しかしながら、上述のように、本開示において記載される技術は、ビデオ・コーディング一般に適用可能であってもよく、無線および／または有線アプリケーションに適用されてもよい。それぞれの場合において、捕捉された、あらかじめ捕捉された、またはコンピュータ生成されたビデオは、ビデオ・エンコーダ20によってエンコードされてもよい。次いで、エンコードされたビデオ情報は、出力インターフェース22によって、コンピュータ読み取り可能媒体16に出力されてもよい。
【0051】
コンピュータ読み取り可能媒体16は、無線ブロードキャストまたは有線ネットワーク伝送のような一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ読み取り可能媒体のような記憶媒体を含むことができる。いくつかの例では、ネットワークサーバー（図示せず）は、源装置12からエンコードされたビデオ・データを受領し、エンコードされたビデオ・データを、たとえば、ネットワーク伝送を介して宛先装置14に提供することができる。同様に、ディスクスタンピング施設のような媒体製造施設の計算装置は、源装置12からのエンコードされたビデオ・データを受領し、エンコードされたビデオ・データを含むディスクを生産することができる。よって、コンピュータ読み取り可能媒体16は、さまざまな例において、さまざまな形の一つまたは複数のコンピュータ読み取り可能媒体を含むものと理解されうる。
【0052】
宛先装置14の入力インターフェース28は、コンピュータ読み取り可能媒体16から情報を受領する。コンピュータ読み取り可能媒体16の情報は、ビデオ・エンコーダ20によって定義された構文情報を含んでいてもよく、この構文情報は、ビデオ・デコーダ30によっても使用され、ブロックおよび／または他のコーディング単位、たとえば、グループオブピクチャ（group of pictures、GOP）の特徴および／または処理を記述する構文要素を含む。表示装置32は、デコードされたビデオ・データをユーザーに表示し、陰極線管（CRT）、液晶ディスプレイ（LCD）、プラズマディスプレイ、有機発光ダイオード（OLED）ディスプレイ、または他の型の表示装置のような多様な表示装置の任意のものを含んでいてもよい。
【0053】
ビデオ・エンコーダ20およびビデオ・デコーダ30は、現在開発中の高効率ビデオ・コーディング（HEVC）規格のようなビデオ・コーディング規格に従って動作してもよく、HEVC試験モデル（HM）に準拠してもよい。あるいはまた、ビデオ・エンコーダ20およびビデオ・デコーダ30は、他の独自規格または業界標準、たとえば動画像専門家グループ（MPEG）-4、第10部、先進ビデオ・コーディング（AVC）とも称される国際電気通信連合電気通信標準化部門（ITU-T）のH.264規格またはそのような規格の拡張に従って動作してもよい。しかしながら、本開示の技術は、いずれの特定のコーディング規格にも限定されない。ビデオ・コーディング規格の他の例は、MPEG-2およびITU-T H.263を含む。図1には示されていないが、いくつかの側面では、ビデオ・エンコーダ20およびビデオ・デコーダ30は、それぞれ、オーディオ・エンコーダおよびデコーダと統合されてもよく、共通のデータストリームまたは別個のデータストリームにおいてオーディオおよびビデオの両方のエンコードを扱うために、適切なマルチプレクサ‐デマルチプレクサ（MUX-DEMUX）ユニットまたは他のハードウェアおよびソフトウェアを含んでいてもよい。適用可能であれば、MUX-DEMUXユニットは、ITU H.223マルチプレクサ・プロトコル、またはユーザーデータグラムプロトコル（UDP）のような他のプロトコルに準拠してもよい。
【0054】
ビデオ・エンコーダ20およびビデオ・デコーダ30は、それぞれ、一つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）、離散論理、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせのような、多様な好適なエンコーダ回路のいずれかとして実装されうる。技術が部分的にソフトウェアに実装される場合、装置は、好適な非一時的なコンピュータ読み取り可能媒体にソフトウェアのための命令を記憶し、本開示の技術を実行するために一つまたは複数のプロセッサを使用してハードウェアで該命令を実行することができる。ビデオ・エンコーダ20およびビデオ・デコーダ30のそれぞれは、一つまたは複数のエンコーダまたはデコーダに含まれてもよく、これらのいずれも、それぞれの装置内の組み合わされたエンコーダ／デコーダ（コーデック）の一部として統合されてもよい。ビデオ・エンコーダ20および／またはビデオ・デコーダ30を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラー電話機のような無線通信装置を含みうる。
【0055】
図2は、ビデオ・コーディング技術を実装することができるビデオ・エンコーダ20の一例を示すブロック図である。ビデオ・エンコーダ20は、ビデオ・スライス内のビデオ・ブロックのイントラコーディングおよびインターコーディングを実行することができる。イントラコーディングは、所与のビデオ・フレームまたはピクチャー内のビデオにおける空間的冗長性を低減または除去するために、空間的予測に頼る。インターコーディングは、ビデオ・シーケンスの隣接するフレームまたはピクチャー内のビデオにおける時間的冗長性を低減または除去するために、時間的予測に頼る。イントラモード（Iモード）は、いくつかの空間ベースのコーディングモードのうちの任意のものを指しうる。一方向（単予測としても知られる）予測（P mode）または双予測（双予測としても知られる）（Bモード）のようなインターモードは、いくつかの時間ベースのコーディングモードのうちの任意のものを指しうる。
【0056】
図2に示されるように、ビデオ・エンコーダ20は、エンコードされるべきビデオ・フレーム内の現在ビデオ・ブロックを受領する。図2の例では、ビデオ・エンコーダ20は、モード選択ユニット40、参照フレーム・メモリ64、加算器50、変換処理ユニット52、量子化ユニット54、エントロピーコーディングユニット56を含む。モード選択ユニット40は、さらに、動き補償ユニット44、動き推定ユニット42、イントラ予測（内部予測としても知られる）ユニット46、および分割ユニット48を含む。ビデオ・ブロック再構成のために、ビデオ・エンコーダ20は、逆量子化ユニット58、逆変換ユニット60、および加算器62をも含む。再構成されたビデオからブロック性アーチファクトを除去するよう、ブロック境界をフィルタリングするために、ブロッキング解除フィルタ（図2には示されていない）も含まれてもよい。所望であれば、ブロッキング解除フィルタは、典型的には、加算器62の出力をフィルタリングする。ブロッキング解除フィルタに加えて、追加的なフィルタ（ループ内またはループ後）も使用されてもよい。そのようなフィルタは、簡潔のため示されていないが、所望であれば、（ループ内フィルタとして）加算器50の出力をフィルタリングしてもよい。
【0057】
エンコード・プロセスの間、ビデオ・エンコーダ20は、コーディングされるべきビデオ・フレームまたはスライスを受領する。フレームまたはスライスは、複数のビデオ・ブロックに分割されてもよい。動き推定ユニット42および動き補償ユニット44は、時間的予測を提供するために、一つまたは複数の参照フレーム内の一つまたは複数のブロックに対して、受領されたビデオ・ブロックのインター予測コーディングを実行する。イントラ予測ユニット46は、代替的に、空間的予測を提供するために、コーディングされるべきブロックと同じフレームまたはスライス内の一つまたは複数の近傍ブロックに対して、受領されたビデオ・ブロックのイントラ予測コーディングを実行してもよい。ビデオ・エンコーダ20は、たとえばビデオ・データの各ブロックについて適切なコーディングモードを選択するために、複数回のコーディング・パス（pass）を実行してもよい。
【0058】
さらに、分割ユニット48は、以前のコーディングパスにおける以前の分割方式の評価に基づいて、ビデオ・データのブロックをサブブロックに分割してもよい。たとえば、分割ユニット48は、最初に、フレームまたはスライスを最大のコーディング単位（largest coding unit、LCU）に分割し、各LCUをレート‐歪み解析（たとえば、レート‐歪み最適化）に基づいてサブコーディング単位（サブCU）に分割してもよい。モード選択ユニット40は、さらに、LCUのサブCUへの分割を示す四分木データ構造を生成することができる。四分木のリーフノードCUは、一つまたは複数の予測単位（PU）および一つまたは複数の変換単位（TU）を含んでいてもよい。
【0059】
本開示は、「ブロック」という用語を使用して、HEVCの文脈におけるCU、PU、またはTU、または他の標準（たとえば、H.264/AVCにおけるマクロブロックおよびそのサブブロック）の文脈における類似のデータ構造の任意のものを指す。CUは、コーディングノード、PU、および、コーディングノードに関連付けられたTUを含む。CUのサイズはコーディングノードのサイズに対応し、正方形である。CUのサイズは、8×8ピクセルから、最大64×64ピクセル以上のツリーブロックのサイズまでの範囲である。各CUは、一つまたは複数のPUおよび一つまたは複数のTUを含むことができる。CUに関連付けられた構文データは、たとえば、該CUの一つまたは複数のPUへの分割を記述してもよい。分割モードは、CUがスキップまたは直接モード・エンコードされるか、イントラ予測モード・エンコードされるか、またはインター予測（相互予測としても知られる）モード・エンコードされるかで異なってもよい。PUは、非正方形の形状に分割されてもよい。CUに関連付けられた構文データは、たとえば、四分木に従った該CUの一つまたは複数のTUへの分割を記述してもよい。TUは、正方形または非正方形（たとえば、長方形）の形状であってもよい。
【0060】
モード選択ユニット40は、コーディングモードの一つ、たとえばイントラまたはインターを、エラー結果に基づいて選択してもよく、結果として得られたイントラまたはインターコーディングされたブロックを、残差ブロックデータを生成する加算器50に提供し、エンコードされたブロックを参照フレームとしての使用のために再構成する加算器62に提供する。モード選択ユニット40はまた、動きベクトル、イントラモード・インジケータ、分割情報、および他のそのような構文情報といった構文要素をエントロピーコーディングユニット56に提供する。
【0061】
動き推定ユニット42および動き補償ユニット44は、高度に統合されてもよいが、概念的な目的のために別個に示されている。動き推定ユニット42によって実行される動き推定は、動きベクトルを生成するプロセスであり、ビデオ・ブロックについての動きを推定する。動きベクトルは、たとえば、現在のフレーム内のコーディングされている現在のブロック（または他のコーディング単位）に対する参照フレーム内の予測ブロック（または他の符号単位）に対する、現在のビデオ・フレームまたはピクチャー内のビデオ・ブロックのPUの変位を示してもよい。予測ブロックは、ピクセル差に関して、コーディングされるブロックに密接に一致することが見出されるブロックであり、一致は、差分絶対値和（SAD）、差分平方和（SSD）、または他の差分メトリックによって決定されうる。いくつかの例では、ビデオ・エンコーダ20は、参照フレーム・メモリ64に記憶された参照ピクチャーの整数より細かいピクセル位置の値を計算することができる。たとえば、ビデオ・エンコーダ20は、参照ピクチャーの1/4ピクセル位置、1/8ピクチャー位置、または他の小数ピクチャー位置の値を補間することができる。よって、動き推定ユニット42は、全ピクセル位置および小数ピクセル位置に対する動き探索を実行し、小数ピクセル精度で動きベクトルを出力することができる。
【0062】
動き推定ユニット42は、インターコーディングされたスライス内のビデオ・ブロックのPUについての動きベクトルを、該PUの位置を参照ピクチャーの予測ブロックの位置と比較することにより算出する。参照ピクチャーは、第1の参照ピクチャー・リスト（リスト0）または第2の参照ピクチャー・リスト（リスト1）から選択されてもよく、そのそれぞれは参照フレーム・メモリ64に記憶された一つまたは複数の参照ピクチャーを識別する。動き推定部42は、計算された動きベクトルをエントロピーコーディングユニット56および動き補償ユニット44に送る。
【0063】
動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを含んでいてもよい。ここでもまた、動き推定ユニット42および動き補償ユニット44は、いくつかの例では機能的に統合されてもよい。現在のビデオ・ブロックのPUについての動きベクトルを受領すると、動き補償ユニット44は、動きベクトルが指し示す予測ブロックを、参照ピクチャー・リストのうちの1つにおいて位置特定することができる。加算器50は、後述するように、コーディングされる現在のビデオ・ブロックのピクセル値から予測ブロックのピクセル値を減算してピクセル差値を形成することによって残差ビデオ・ブロックを形成する。一般に、動き推定ユニット42は、ルーマ成分に対する動き推定を実行し、動き補償ユニット44は、ルーマ成分に基づいて計算された動きベクトルを、クロマ成分とルーマ成分の両方について使用する。モード選択ユニット40は、ビデオ・ブロックおよびビデオ・スライスに関連する構文要素を、ビデオ・スライスのビデオ・ブロックをデコードする際にビデオ・デコーダ30が使用するために、生成することもできる。
【0064】
イントラ予測ユニット46は、上述した、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測に対する代替として、現在ブロックをイントラ予測してもよい。具体的には、イントラ予測ユニット46は、現在ブロックをエンコードするために使用するイントラ予測モードを決定してもよい。いくつかの例では、イントラ予測ユニット46は、たとえば、別々の諸エンコード・パスの間に、さまざまなイントラ予測モードを使用して現在ブロックをエンコードしてもよく、イントラ予測ユニット46（または、いくつかの例では、モード選択ユニット40）は、試験された諸モードから、使用するための適切なイントラ予測モードを選択することができる。
【0065】
たとえば、イントラ予測ユニット46は、さまざまな試験されたイントラ予測モードについてレート‐歪み解析を用いてレート‐歪み値を計算し、試験されたモードの中で最良のレート‐歪み特性を有するイントラ予測モードを選択することができる。レート‐歪み解析は、一般に、エンコードされたブロックと、該エンコードされたブロックを生成するためにエンコードされた、もとのエンコードされていないブロックとの間の歪み（または誤差）の量、ならびに、該エンコードされたブロックを生成するために使用されたビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット46は、さまざまなエンコードされたブロックについての歪みおよびレートから比を計算して、そのブロックについて最良のレート‐歪み値を示すイントラ予測モードを決定することができる。
【0066】
加えて、イントラ予測ユニット46は、奥行きモデリングモード（depth modeling mode、DMM）を用いて奥行きマップの奥行きブロックをコーディングするように構成されてもよい。モード選択ユニット40は、たとえばレート‐歪み最適化（rate-distortion optimization、RDO）を用いて、利用可能なDMMモードが、イントラ予測モードおよび他のDMMモードよりも良好なコーディング結果をもたらすかどうかを決定することができる。奥行きマップに対応するテクスチャー画像についてのデータは、参照フレーム・メモリ64に記憶されてもよい。動き推定ユニット42および動き補償ユニット44は、奥行きマップの奥行きブロックをインター予測するように構成されてもよい。
【0067】
ブロックについてイントラ予測モード（たとえば、従来のイントラ予測モードまたはDMMモードの1つ）を選択した後、イントラ予測ユニット46は、そのブロックについての選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供することができる。エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報をエンコードすることができる。ビデオ・エンコーダ20は、送信ビットストリームに、構成データを含めてもよい。構成データは、複数のイントラ予測モード・インデックス・テーブルおよび複数の修正イントラ予測モード・インデックス・テーブル（符号語マッピング・テーブルとも呼ばれる）と、さまざまなブロックについてのエンコードするコンテキスト（encoding context）の定義と、各コンテキストについて使うべき、最も確からしいイントラ予測モード、イントラ予測モード・インデックス・テーブル、および修正イントラ予測モード・インデックス・テーブルの指示を含みうる。
【0068】
ビデオ・エンコーダ20は、モード選択ユニット40からの予測データをコーディングされるもとのビデオ・ブロックから減算することによって残差ビデオ・ブロックを形成する。加算器50は、この減算演算を実行するコンポーネント（単数または複数）を表す。
【0069】
変換処理ユニット52は、離散コサイン変換（DCT）または概念的に類似した変換などの変換を残差ブロックに適用し、残差変換係数値を含むビデオ・ブロックを生成する。変換処理ユニット52は、概念的にDCTに類似した他の変換を実行してもよい。ウェーブレット変換、整数変換、サブバンド変換、または他の型の変換も使用できる。
【0070】
変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から変換領域、たとえば周波数領域に変換してもよい。変換処理ユニット52は、結果として得られる変換係数を量子化ユニット54に送ってもよい。量子化ユニット54は、変換係数を量子化し、ビットレートをさらに低下させる。量子化プロセスは、係数のいくつかまたは全部に関連するビット深さを低減してもよい。量子化の程度は、量子化パラメータを調整することによって修正されてもよい。いくつかの例では、量子化ユニット54は、その後、量子化された変換係数を含む行列の走査を実行してもよい。あるいはまた、エントロピーコーディングユニット56が走査を実行してもよい。
【0071】
量子化の後、エントロピーコーディングユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキスト適応可変長コーディング（CAVLC）、コンテキスト適応二進算術演算コーディング（CABAC）、構文ベースのコンテキスト適応二進算術演算コーディング（SBAC）、確率区間分割エントロピー（PIPE）コーディング、または他のエントロピーコーディング技術を実行しうる。コンテキストベースのエントロピーコーディングの場合、コンテキストは近傍ブロックに基づいてもよい。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、エンコードされたビットストリームは、別の装置（たとえば、ビデオ・デコーダ30）に送信されてもよく、または後の送信または取得のためにアーカイブされてもよい。
【0072】
逆量子化ユニット58および逆変換ユニット60は、それぞれ、逆量子化および逆変換を適用して、ピクセル領域での残差ブロックを再構成する。たとえば参照ブロックとして後に使用するためである。動き補償ユニット44は、参照フレーム・メモリ64のフレームのうちの1つのフレームの予測ブロックに残差ブロックを加算することによって参照ブロックを計算することができる。動き補償ユニット44はまた、一つまたは複数の補間フィルタを再構成された残差ブロックに適用して、動き推定において使用するための整数より細かいピクセル値を計算してもよい。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された、動き補償された予測ブロックに加算し、参照フレーム・メモリ64に記憶するための再構成されたビデオ・ブロックを生成する。再構成されたビデオ・ブロックは、後続のビデオ・フレーム内のブロックをインターコーディングするための参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用されてもよい。
【0073】
図3は、ビデオ・コーディング技術を実装することができるビデオ・デコーダ30の一例を示すブロック図である。図3の例では、ビデオ・デコーダ30は、エントロピー復号ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレーム・メモリ82、および加算器80を含む。ビデオ・デコーダ30は、いくつかの例において、ビデオ・エンコーダ20（図2）に関して説明したエンコード・パスと概ね逆のデコード・パスを実行することができる。動き補償ユニット72は、エントロピー復号ユニット70から受領された動きベクトルに基づいて予測データを生成してもよく、一方、イントラ予測ユニット74は、エントロピー復号ユニット70から受領されたイントラ予測モード・インジケータに基づいて予測データを生成してもよい。
【0074】
デコード・プロセスの間、ビデオ・デコーダ30は、ビデオ・エンコーダ20から、エンコードされたビデオ・スライスのビデオ・ブロックおよび関連する構文要素を表すエンコードされたビデオ・ビットストリームを受信する。ビデオ・デコーダ30のエントロピー復号ユニット70は、ビットストリームをデコードし、量子化された係数、動きベクトルまたはイントラ予測モード・インジケータ、および他の構文要素を生成する。エントロピー復号ユニット70は、動きベクトルおよび他の構文要素を動き補償ユニット72に転送する。ビデオ・デコーダ30は、ビデオ・スライスレベルおよび／またはビデオ・ブロックレベルで構文要素を受信しうる。
【0075】
ビデオ・スライスがイントラコーディングされた（I）スライスとしてコーディングされているとき、イントラ予測ユニット74は、信号伝達されたイントラ予測モードと、現在のフレームまたはピクチャーの前にデコードされたブロックからのデータとに基づいて、現在のビデオ・スライスのビデオ・ブロックについての予測データを生成してもよい。ビデオ・フレームがインターコーディングされた（たとえばB、PまたはGPB）スライスとしてコーディングされているとき、動き補償ユニット72は、エントロピー復号ユニット70から受領された動きベクトルおよび他の構文要素に基づいて、現在のビデオ・スライスのビデオ・ブロックについての予測ブロックを生成する。予測ブロックは、参照ピクチャー・リストの1つの中の参照ピクチャーの1つから生成されうる。ビデオ・デコーダ30は、参照フレーム・メモリ82に記憶された参照ピクチャーに基づくデフォルトの構築技術を使用して、参照フレームリスト、リスト0およびリスト1を構築することができる。
【0076】
動き補償ユニット72は、動きベクトルおよび他の構文要素をパースすることによって、現在のビデオ・スライスのビデオ・ブロックの予測情報を決定し、該予測情報を使用して、デコードされている現在のビデオ・ブロックについての予測ブロックを生成する。たとえば、動き補償ユニット72は、受領された構文要素のいくつかを用いて、ビデオ・スライスのビデオ・ブロックをコーディングするために使用された予測モード（たとえばイントラ予測またはインター予測）、インター予測スライス型（たとえば、Bスライス、Pスライス、またはGPBスライス）、スライスについての参照ピクチャー・リストのうちの一つまたは複数のための構築情報、スライスの各インターエンコードされたビデオ・ブロックのための動きベクトル、スライスの各インターコーディングされたビデオ・ブロックについてのインター予測ステータス、および現在のビデオ・スライスにおけるビデオ・ブロックをデコードするための他の情報を決定する。
【0077】
動き補償ユニット72はまた、補間フィルタに基づいて補間を実行してもよい。動き補償ユニット72は、ビデオ・ブロックのエンコード中にビデオ・エンコーダ20によって使用される補間フィルタを使用して、参照ブロックの整数より細かいピクセルについての補間された値を計算することができる。この場合、動き補償ユニット72は、受領された構文要素からビデオ・エンコーダ20によって使用される補間フィルタを決定し、該補間フィルタを、予測ブロックを生成するために使用してもよい。
【0078】
奥行きマップに対応するテクスチャー画像についてのデータが、参照フレーム・メモリ82に記憶されていてもよい。動き補償ユニット72は、奥行きマップの奥行きブロックをインター予測するように構成されてもよい。
【0079】
上記に留意して、ビデオ圧縮技術は、ビデオ・シーケンスに内在する冗長性を低減または除去するために、空間的（ピクチャー内）予測および／または時間的（ピクチャー間）予測を実行する。ブロックベースのビデオ・コーディングのために、ビデオ・スライス（すなわち、ビデオ・ピクチャーまたはビデオ・ピクチャーの一部）は、ビデオ・ブロックに分割されてもよく、かかるビデオ・ブロックは、ツリーブロック、コーディングツリーブロック（CTB）、コーディングツリー単位（CTU）、コーディング単位（CU）および／またはコーディングノードとも称されうる。ピクチャーのイントラコーディングされた（I）スライス内のビデオ・ブロックは、同じピクチャー内の近傍ブロック内の参照サンプルに関する空間的予測を用いてエンコードされる。ピクチャーのインターコーディングされた（PまたはB）スライス内のビデオ・ブロックは、同じピクチャー内の近傍ブロック内の参照サンプルに関する空間的予測、または他の参照ピクチャー内の参照サンプルに関する時間的予測を使用することができる。ピクチャーはフレームと称されてもよく、参照ピクチャーは参照フレームと称されてもよい。
【0080】
空間的または時間的予測は、コーディングされるべきブロックについての予測ブロックを与える。残差データは、コーディングされるべきもとのブロックと予測ブロックとの間のピクセル差を表す。インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コーディングされるブロックと予測ブロックとの間の差を示す残差データとに従ってコーディングされる。イントラコーディングされるブロックは、イントラコーディングモードおよび残差データに従ってコーディングされる。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて、残差変換係数を与えてもよく、それが次いで、量子化されてもよい。量子化された変換係数は、最初は二次元アレイに配置され、変換係数の一次元ベクトルを生成するために走査されてもよく、一層の圧縮を達成するためにエントロピーコーディングが適用されてもよい。
【0081】
画像およびビデオ圧縮は急速な成長を経験し、さまざまなコーディング標準をもたらした。そのようなビデオ・コーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Part 2、ITU-T H.262またはISO/IEC MPEG-2 Part 2、ITU-T H.263、ISO/IEC MPEG-4 Part 2、ITU-T H.264またはISO/IEC MPEG-4 Part 10としても知られる先進ビデオ・コーディング（AVC）、およびITU-T H.265またはMPEG-H Part 2としても知られる高効率ビデオ・コーディング（HEVC）を含む。AVCは、スケーラブルビデオ・コーディング（SVC）、マルチビュービデオ・コーディング（MVC）およびマルチビュービデオ・コーディング＋奥行き（MVC+D）、および3D AVC（3D-AVC）などの拡張を含む。HEVCは、スケーラブルHEVC（SHVC）、マルチビューHEVC（MV-HEVC）、および3D HEVC（3D-HEVC）などの拡張を含む。
【0082】
ITU-TとISO/IECの合同ビデオ専門家チーム（JVET）によって開発されている多用途ビデオ・コーディング（VVC）と命名された新しいビデオ・コーディング規格もある。VVC規格にはいくつかの作業原案があるが、ここでは、特にVVCのある作業原案（Working Draft、WD）、すなわち、B. Bross, J. Chen, and S. Liu, "Versatile Video Coding (Draft 4)," JVET-M1001-v5, 13th JVET Meeting, January 2019 （VVC Draft 4）が参照される。
【0083】
本明細書に開示されている技術の説明は、ITU-TおよびISO/IECの合同ビデオ専門家チーム（JVET）による開発中のビデオ・コーディング規格である多用途ビデオ・コーディング（Versatile Video Coding、VVC）に基づいている。しかしながら、この技術は、他のビデオコーデック仕様にも適用される。
【0084】
図4は、デコード順408および呈示順410における、先頭ピクチャー404および後続ピクチャー406に対するIRAPピクチャー402の間の関係の表現400である。ある実施形態では、IRAPピクチャー402は、クリーン・ランダム・アクセス（clean random access、CRA）ピクチャー、またはランダム・アクセス・デコード可能な先頭（random access decodable leading、RADL）ピクチャーを有する瞬時デコーダ・リフレッシュ（instantaneous decoder refresh、IDR）ピクチャーと呼ばれる。HEVCでは、IDRピクチャー、CRAピクチャー、および分断リンク・アクセス（Broken Link Access、BLA）ピクチャーはすべて、IRAPピクチャー402とみなされる。VVCについては、2018年10月の第12回JVET会合において、IRAPピクチャーとしてIDRピクチャーおよびCRAピクチャーの両方をもつことが合意された。
【0085】
図4に示されるように、先頭ピクチャー404（たとえば、ピクチャー2および3）は、デコード順408ではIRAPピクチャー402の後にくるが、呈示順410ではIRAPピクチャー402に先行する。後続ピクチャー406は、デコード順408および呈示順410の両方において、IRAPピクチャー402の後にくる。2つの先頭ピクチャー404および1つの後続ピクチャー406が図4に描かれているが、当業者は、実際の応用において、より多数またはより少数の先頭ピクチャー404および／または後続ピクチャー406が、デコード順408および呈示順410において存在しうることを理解するであろう。
【0086】
図4における先頭ピクチャー404は、2つの型、すなわち、ランダム・アクセス・スキップ先頭（random access skipped lading、RASL）とRADLに分割されている。デコードがIRAPピクチャー402（たとえば、ピクチャー1）で始まる場合、RADLピクチャー（たとえば、ピクチャー3）は、適正にデコードできるが、RASLピクチャー（たとえば、ピクチャー2）は、適正にデコードできない。よって、RASLピクチャーは破棄される。RADLピクチャーとRASLピクチャーの間の区別に照らして、IRAPピクチャーに関連する先頭ピクチャーの型は、効率的で適切なコーディングのために、RADLまたはRASLのいずれかとして識別されるべきである。HEVCでは、RASLおよびRADLピクチャーが存在する場合、同じIRAPピクチャーに関連付けられたRASLおよびRADLピクチャーについては、RASLピクチャーが呈示順410でRADLピクチャーに先行すると制約される。
【0087】
IRAPピクチャー402は、以下の2つの重要な機能／利点を提供する。第1に、IRAPピクチャー402の存在は、デコード・プロセスがそのピクチャーから開始可能であることを示す。この機能は、IRAPピクチャー402がその位置に存在する限り、デコード・プロセスが、必ずしもビットストリームの先頭ではなく、ビットストリームのその位置において始まるランダム・アクセス機能を許容する。第2に、IRAPピクチャー402の存在は、デコード・プロセスをリフレッシュし、それにより、RASLピクチャーを除くIRAPピクチャー402で始まるコーディングされたピクチャーが、前のピクチャーを参照することなくコーディングされる。その結果、ビットストリーム内にIRAPピクチャー402が存在すると、IRAPピクチャー402の前でコーディングされたピクチャーのデコード中に発生する可能性のある誤りがあっても、それが、IRAPピクチャー402およびデコード順408でIRAPピクチャー402の後にくるピクチャーに伝搬するのを止めることになる。
【0088】
IRAPピクチャー402は重要な機能を提供するが、圧縮効率に対するペネルティを伴う。IRAPピクチャー402の存在は、ビットレートにおけるサージを引き起こす。圧縮効率に対するこのペナルティは、2つの理由による。第1に、IRAPピクチャー402はイントラ予測されるピクチャーなので、ピクチャー自体が、インター予測されるピクチャーである他のピクチャー（たとえば、先頭ピクチャー404、後続ピクチャー406）と比較されると、表現するために相対的により多くのビットを必要とする。第2に、IRAPピクチャー402の存在は時間的予測を分断する（これは、デコーダがデコード・プロセスをリフレッシュするためである。そのためのデコード・プロセスのアクションの1つはデコードピクチャーバッファ（DPB）内の前の参照ピクチャーを除去することである）。このため、IRAPピクチャー402により、デコード順408でIRAPピクチャー402に続くピクチャーのコーディングは、インター予測コーディングのための参照ピクチャーがより少ないため、より効率的でない（すなわち、表現するためにより多くのビットを必要とする）ことになる。
【0089】
IRAPピクチャー402と考えられるピクチャー型のうち、HEVCにおけるIDRピクチャーは、他のピクチャー型と比較した場合、異なる信号伝達および導出をもつ。相違点のいくつかは以下の通りである。
【0090】
IDRピクチャーのピクチャー順カウント（POC）値の信号伝達および導出のために、POCの最上位ビット（MSB）部分は、以前のキー・ピクチャーから導出されず、単に0に等しく設定される。
【0091】
参照ピクチャー管理に必要な信号伝達情報について、IDRピクチャーのスライス・ヘッダは、参照ピクチャー管理を支援するために信号伝達される必要のある情報を含まない。他のピクチャー型（すなわち、CRA、後続（Trailing）、時間的下位層アクセス（temporal sub-layer access、TSA）など）については、参照ピクチャー・マーキング・プロセス（すなわち、参照のために使用されるか参照のために使用されないかにかかわらず、デコードピクチャーバッファ（DPB）内の参照ピクチャーの状態を決定するプロセス）のために、以下に記載される参照ピクチャーセット（reference picture set、RPS）または他の形の同様の情報（たとえば、参照ピクチャー・リスト）のような情報が必要とされる。しかしながら、IDRピクチャーについては、そのような情報は信号伝達される必要はない。IDRの存在が、デコード・プロセスが単にDPB内のすべての参照ピクチャーを参照のために使用されないものとしてマークすべきであることを示すからである。
【0092】
HEVCおよびVVCでは、IRAPピクチャー402および先頭ピクチャー404はそれぞれ、単一のネットワーク抽象化層（NAL）単位内に含まれてもよい。NAL単位の集合は、アクセス単位と呼ばれることがある。IRAPピクチャー402および先頭ピクチャー404は、異なるNAL単位型を与えられ、よって、システムレベルのアプリケーションによって容易に識別できる。たとえば、ビデオ・スプライサーは、コーディングされたビットストリーム内の構文要素の過剰な詳細を理解する必要なく、コーディングされたピクチャー型を理解する必要があり、特に、IRAPピクチャー402を非IRAPピクチャーから識別し、RASLおよびRADLピクチャーを判別することを含め先頭ピクチャー404を後続ピクチャー406から識別する必要がある。後続ピクチャー406は、IRAPピクチャー402に関連付けられ、呈示順410でIRAPピクチャー402の後にくるピクチャーである。ピクチャーは、デコード順408で特定のIRAPピクチャー402の後になり、デコード順408で他の任意のIRAPピクチャー402に先行することがある。このためには、IRAPピクチャー402および先頭ピクチャー404にそれ自身のNAL単位型を与えることが、そのようなアプリケーションを助ける。
【0093】
HEVCについては、IRAPピクチャーのNAL単位型は下記を含む：
先頭ピクチャーを伴うBLA（BLA_W_LP）：デコード順で一つまたは複数の先頭ピクチャーが後に続いてもよい分断リンク・アクセス（Broken Link Access、BLA）ピクチャーのNAL単位
RADLを伴うBLA（BLA_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないBLAピクチャーのNAL単位
先頭ピクチャーがないBLA（BLA_N_LP）：デコード順で先頭ピクチャーが後に続かないBLAピクチャーのNAL単位
RADLを伴うIDR（IDR_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないIDRピクチャーのNAL単位
先頭ピクチャーのないIDR（IDR_N_LP）：デコード順で先頭ピクチャーが後に続かないIDRピクチャーのNAL単位
CRA：先頭ピクチャー（すなわち、RASLピクチャーまたはRADLピクチャーまたはその両方）が後に続いてもよいクリーン・ランダム・アクセス（CRA）ピクチャーのNAL単位
RADL：RADLピクチャーのNAL単位
RASL：RASLピクチャーのNAL単位。
先頭ピクチャーを伴うBLA（BLA_W_LP）：デコード順で一つまたは複数の先頭ピクチャーが後に続いてもよい分断リンク・アクセス（Broken Link Access、BLA）ピクチャーのNAL単位
RADLを伴うBLA（BLA_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないBLAピクチャーのNAL単位
先頭ピクチャーがないBLA（BLA_N_LP）：デコード順で先頭ピクチャーが後に続かないBLAピクチャーのNAL単位
RADLを伴うIDR（IDR_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないIDRピクチャーのNAL単位
先頭ピクチャーのないIDR（IDR_N_LP）：デコード順で先頭ピクチャーが後に続かないIDRピクチャーのNAL単位
CRA：先頭ピクチャー（すなわち、RASLピクチャーまたはRADLピクチャーまたはその両方）が後に続いてもよいクリーン・ランダム・アクセス（CRA）ピクチャーのNAL単位
RADL：RADLピクチャーのNAL単位
RASL：RASLピクチャーのNAL単位。
【0094】
VVCについては、IRAPピクチャー402および先頭ピクチャー404のNAL単位型は下記の通り：
RADLを伴うIDR（IDR_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないIDRピクチャーのNAL単位
先頭ピクチャーのないIDR（IDR_N_LP）：デコード順で先頭ピクチャーが後に続かないIDRピクチャーのNAL単位
CRA：先頭ピクチャー（すなわち、RASLピクチャーまたはRADLピクチャー、またはその両方）が後に続いてもよいクリーン・ランダム・アクセス（CRA）ピクチャーのNAL単位
RADL：RADLピクチャーのNAL単位
RASL：RASLピクチャーのNAL単位。
RADLを伴うIDR（IDR_W_RADL）：デコード順で一つまたは複数のRADLピクチャーが後に続いてもよいがRASLピクチャーは後に続かないIDRピクチャーのNAL単位
先頭ピクチャーのないIDR（IDR_N_LP）：デコード順で先頭ピクチャーが後に続かないIDRピクチャーのNAL単位
CRA：先頭ピクチャー（すなわち、RASLピクチャーまたはRADLピクチャー、またはその両方）が後に続いてもよいクリーン・ランダム・アクセス（CRA）ピクチャーのNAL単位
RADL：RADLピクチャーのNAL単位
RASL：RASLピクチャーのNAL単位。
【0095】
プログレッシブ・イントラ・リフレッシュ／漸進的デコード・リフレッシュが、以下で議論される。
【0096】
低遅延アプリケーションについては、ピクチャーをIRAPピクチャー（たとえば、IRAPピクチャー402）としてコーディングすることを避けることが望ましい。非IRAP（すなわち、P/B）ピクチャーと比較してそのビットレート要件が比較的大きく、結果的に、より大きなレイテンシー／遅延を引き起こすからである。しかしながら、IRAPの使用を完全に回避することは、すべての低遅延アプリケーションで可能ではないことがありうる。たとえば、マルチパーティー遠隔会議のような会話型アプリケーションについては、新しいユーザーが遠隔会議に参加することができる定期的なポイントを提供する必要がある。
【0097】
新しいユーザーがマルチパーティー遠隔会議アプリケーションに参加することを許容するビットストリームへのアクセスを提供するために、1つの可能な戦略は、ビットレートにピークができるのを避けるために、IRAPピクチャーを使用する代わりに、プログレッシブ・イントラ・リフレッシュ（Progressive Intra Refresh）技術（PIR）を使用することである。PIRは、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）とも呼ばれることもある。PIRおよびGDRという用語は、本開示では交換可能に使用されうる。
【0098】
図5は、漸進的デコード・リフレッシュ（GDR）技術500を示す。図示のように、GDR技術500は、ビットストリームのコーディングされたビデオ・シーケンス508内のGDRピクチャー502、一つまたは複数の後続ピクチャー504、および回復点ピクチャー506を使用して描かれている。ある実施形態では、GDRピクチャー502、後続ピクチャー504、および回復点ピクチャー506は、CVS 508内のGDR期間（period）を画定することができる。CVS 508は、GDRピクチャー502で始まる一連のピクチャー（またはその一部）であり、次のGDRピクチャーまでの（ただし該次のGDRピクチャーは含まない）、またはビットストリームの終了までのすべてのピクチャー（またはその一部）を含む。GDR期間は、GDRピクチャー502で始まる一連のピクチャーであり、回復点ピクチャー506までの、回復点ピクチャー506を含むすべてのピクチャーを含む。
【0099】
図5に示されるように、GDR技術500または原理は、GDRピクチャー502で始まり回復点ピクチャー506で終わる一連のピクチャー上で機能する。GDRピクチャー502は、みなイントラ予測を用いてコーディングされたブロック（すなわち、イントラ予測ブロック）を含むリフレッシュ／クリーン領域510と、みなインター予測を用いてコーディングされたブロック（すなわち、インター予測ブロック）を含む未リフレッシュ／ダーティー領域512とを含む。
【0100】
GDRピクチャー502にすぐ隣接する後続ピクチャー504は、イントラ予測を用いてコーディングされた第1の部分510Aと、インター予測を用いてコーディングされた第2の部分510Bとを有するリフレッシュ／クリーン領域510を含む。第2の部分510Bは、たとえば、CVS 508のGDR期間内の先行するピクチャーのリフレッシュ／クリーン領域510を参照することによってコーディングされる。図のように、後続ピクチャー504のリフレッシュ／クリーン領域510は、コーディング・プロセスが一貫した方向に（たとえば、左から右へ）移動または進行するにつれて拡大し、これに対応して、未リフレッシュ／ダーティー領域512を収縮させる。最終的に、リフレッシュ／クリーン領域510のみを含む回復点ピクチャー506が、コーディング・プロセスから得られる。注目すべきことに、以下でさらに論じられるように、インター予測ブロックとしてコーディングされるリフレッシュ／クリーン領域510の第2の部分510Bは、参照ピクチャーにおけるリフレッシュ領域／クリーン領域510を参照するだけでもよい。
【0101】
HEVCでは、図5のGDR技術500は、回復点補足向上情報（SEI）メッセージおよび領域リフレッシュ情報SEIメッセージを使用して、非規範的にサポートされた。これら2つのSEIメッセージは、どのようにGDRが実行されるかは定義しない。むしろ、これら2つのSEIメッセージは、単に、GDR期間における最初と最後のピクチャー（すなわち、回復点SEIメッセージによって提供される）とリフレッシュされる領域（すなわち、領域リフレッシュ情報SEIメッセージによって提供される）とを示す機構を提供する。
【0102】
実際上は、GDR技術500は、2つの技術を一緒に使用することによって実行される。それらの2つの技法は、制約イントラ予測（constraint intra prediction、CIP）と動きベクトルについてのエンコーダ制約条件である。CIPは、特に、イントラ予測ブロック（たとえば、リフレッシュ／クリーン領域510の第1の部分510A）としてのみコーディングされる領域をコーディングするために、GDRの目的で使用できる。なぜなら、CIPは、リフレッシュされていない領域（たとえば、前記未リフレッシュ／ダーティー領域512）からのサンプルを使用しない領域が、参照のために使用されることを許容するからである。しかしながら、CIPの使用は、イントラブロックに対する制約条件が、リフレッシュされた領域におけるイントラブロックについてだけでなく、ピクチャー内のすべてのイントラブロックにも適用されなければならないので、厳しいコーディング・パフォーマンス劣化を引き起こす。動きベクトルについてのエンコーダ制約条件は、エンコーダが、リフレッシュ領域の外側に位置する参照ピクチャー内の任意のサンプルを使用することを制約する。そのような制約条件は、最適でない動き探索を引き起こす。
【0103】
図6は、GDRをサポートするためにエンコーダ制約を使用する場合の、望ましくない動き探索600を示す概略図である。図のように、動き探索600は、現在のピクチャー602および参照ピクチャー604を描いている。現在のピクチャー602および参照ピクチャー604は、それぞれ、イントラ予測でコーディングされたリフレッシュ領域606、インター予測でコーディングされたリフレッシュ領域608、および未リフレッシュ領域608を含む。リフレッシュ領域604、リフレッシュ領域606、および未リフレッシュ領域608は、図5における、リフレッシュ／クリーン領域510の第1の部分510A、リフレッシュ／クリーン領域510の第2の部分510B、および未リフレッシュ／ダーティー領域512と同様である。
【0104】
動き探索プロセスの間、エンコーダは、リフレッシュ領域606の外側に位置する参照ブロック612のサンプルのいずれかにつながる何らかの動きベクトル610を選択することを、制約されるか、または防止される。これは、参照ブロック612が、現在のピクチャー602内の現在のブロック614を予測するときの最良のレート‐歪みコスト基準を提供する場合であっても発生する。このように、図6は、GDRをサポートするためにエンコーダ制約を使用する場合の、動き探索600における非最適性の理由を示している。
【0105】
JVETの寄稿JVET-K0212およびJVET-L0160は、CIPの使用とエンコーダ制約アプローチとに基づくGDRの実装を記述する。該実装は、以下のように要約することができる：列ベースでコーディング単位に対してイントラ予測モードが強制され、イントラCUの再構成を確実にするために、制約されたイントラ予測が有効にされ、フィルタについての誤差拡散を回避するための追加的なマージン（たとえば、6ピクセル）を考慮に入れつつ、リフレッシュ領域内を指し示すように動きベクトルが制約され、イントラ列を再ループする際に以前の参照ピクチャーを除去する。
【0106】
JVETの寄稿JVET-M0529は、規範的にピクチャーがGDR期間における最初と最後であることを示す方法を提案した。提案されたアイデアは以下のように機能する。
【0107】
非ビデオ・コーディング層（VCL）NAL単位として、NAL単位型回復点指示をもつ新しいNAL単位を定義する。NAL単位のペイロードは、GDR期間の最後のピクチャーのPOC値を導出するために使用できる情報を指定するための構文要素を含む。型回復点指示をもつ非VCL NAL単位を含むアクセス単位は、回復点開始（recovery point begin、RBP）アクセス単位（access unit、AU）と呼ばれ、RBPアクセス単位内のピクチャーは、RBPピクチャーと呼ばれる。デコード・プロセスは、RBP AUから開始できる。RBP AUからデコードが開始されるとき、GDR期間内の、最後のピクチャーを除くすべてのピクチャーは出力されない。
【0108】
既存のGDR設計の問題のいくつかが論じられる。
【0109】
GDRをサポートするための既存の設計／アプローチには、少なくとも以下の問題がある。
【0110】
JVET-M0529において規範的にGDRを定義する方法には、次のような問題がある。提案された方法は、GDRがどのように実行されるかを記述しない。その代わりに、提案された方法は、GDR期間における最初と最後のピクチャーを示すために、何らかの信号伝達を提供するだけである。GDR期間における最初と最後のピクチャーを示すために、新しい非VCL NAL単位が必要とされる。これは、回復点指示（recovery point indication、RPI）NAL単位に含まれる情報が、単純に、GDR期間における最初のピクチャーのタイル・グループ・ヘッダに単純に含まれることができるため、冗長である。また、提案された方法は、GDR期間中のピクチャー中のどの領域がリフレッシュ領域および未リフレッシュ領域であるかを記述することができない。
【0111】
JVET-K0212およびJVET-L0160に記載されているGDRアプローチには、以下の問題がある。第一に、CIPの使用がある。未リフレッシュ領域からのいかなるサンプルも空間的参照のために使用されることを防止するために、イントラ予測によるリフレッシュ領域を、いくつかの制約条件をもってコーディングすることが必要である。CIPが使用される場合、コーディングはピクチャーベースであり、これは、ピクチャー内のすべてのイントラブロックもCIPイントラブロックとしてコーディングされなければならないことを意味する。これは結果として、パフォーマンス劣化を引き起こす。さらに、動きベクトルに関連する参照ブロックのサンプルが参照ピクチャー内のリフレッシュ領域内に完全にはない場合、動き探索を制限するエンコーダ制約条件を使用することにより、エンコーダが最良の動きベクトルを選択することが妨げられる。また、イントラ予測のみでコーディングされるリフレッシュ領域はCTUサイズではない。その代わりに、リフレッシュ領域は、CTUサイズより小さくすることができ、最小CUサイズでもよい。これは、ブロックレベルでの指示を必要とする可能性があるので、実装を不必要に複雑にする。
【0112】
本明細書に開示されているのは、ビデオ・コーディングにおける漸進的デコード・リフレッシュ（GDR）をサポートするための技術である。開示される技術は、イントラ・ランダム・アクセス・ポイント（intra random access point）ピクチャーを使用する必要なく、ランダム・アクセスを可能にするために、プログレッシブ・イントラ・リフレッシュを許容する。以下にさらに詳しく説明されるように、ビデオ・コーディング層（VCL）ネットワーク抽象化層（NAL）単位は、該VCL NAL単位がGDRピクチャーを含むことを示すために、漸進的デコード・リフレッシュ（GDR）ネットワーク抽象化層（NAL）単位型（GDR_NUT）を有する。すなわち、GDR_NUTは、該GDR_NUTをもつVCL NAL単位がGDRピクチャーを含むことを、ビデオ・デコーダに対して直接示す。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえばIRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されうる。これは、エンドツーエンドの遅延（すなわち、レイテンシー）を低減することを許容する。よって、ビデオ・コーディングにおけるコーダ／デコーダ（「コーデック」としても知られる）は、現在のコーデックと比較して改善される。実際的な問題として、改善されたビデオ・コーディング・プロセスは、ビデオが送られ、受信され、および／または閲覧されるときに、ユーザーに、より良いユーザー体験を提供する。
【0113】
上記で論じた問題の一つまたは複数を解決するために、本開示は以下の諸側面を開示する。各側面は個々に適用されることができ、それらのいくつかは組み合わせて適用されることができる。
【0114】
1）型GDR_NUTをもつVCL NAL単位が定義される。
【0115】
a. NAL単位型GDR_NUTをもつピクチャーは、GDRピクチャー、すなわちGDR期間における最初のピクチャーと称される。
【0116】
b. GDRピクチャーは、0に等しいtemporalID〔時間的ID〕をもつ。
【0117】
c. GDRピクチャーを含むアクセス単位は、GDRアクセス単位と称される。前述のように、アクセス単位は、NAL単位の集合である。各NAL単位は単一のピクチャーを含むことができる。
【0118】
2）コーディング・ビデオ・シーケンス（coded video sequence、CVS）は、GDRアクセス単位で始まってもよい。
【0119】
3）GDRアクセス単位は、以下のいずれかが真である場合、CVSにおける最初のアクセス単位である。
【0120】
a. GDRアクセス単位が、ビットストリームにおける最初のアクセス単位である。
【0121】
b. GDRアクセス単位が、シーケンス終了（end-of-sequence、EOS）アクセス単位の直後にくる。
【0122】
c. GDRアクセス単位が、ビットストリーム終了（end-of-bitstream、EOB）アクセス単位の直後にくる。
【0123】
d. NoIncorrectPicOutputFlagと呼ばれるデコーダフラグが、GDRピクチャーに関連付けられており、該フラグの値は、デコーダの外部のエンティティによって1（すなわち、真）に設定される。
【0124】
4）GDRピクチャーがCVSにおける最初のアクセス単位である場合、以下が当てはまる。
【0125】
a. DPBにおけるすべての参照ピクチャーは「参照のために不使用」とマークされる。
【0126】
b. ピクチャーのPOC MSBが0に等しく設定される。
【0127】
c. GDRピクチャーおよび出力順でGDRピクチャーの後に続くすべてのピクチャーは、GDR期間における最後のピクチャーまで（GDR期間における最後のピクチャーを除く）出力されない（すなわち、「出力のために不要」とマークされる）。
【0128】
5）GDRが有効にされるかどうかを指定するフラグが、シーケンスレベルのパラメータセットにおいて（たとえば、SPSにおいて）で信号伝達される。
【0129】
a. フラグはgdr_enabled_flagと指定されてもよい。
【0130】
b. フラグが1に等しい場合、GDRピクチャーはCVSに存在していてもよい。そうでなく、フラグが0に等しい場合、GDRは有効にされず、GDRピクチャーはCVSに存在しない。
【0131】
6）GDR期間における最後のピクチャーのPOC値を導出するために使用できる情報は、GDRピクチャーのタイル・グループ・ヘッダにおいて信号伝達される。
【0132】
a. 該情報は、GDR期間における最後のピクチャーとGDRピクチャーとの間のデルタPOCとして信号伝達される。該情報は、recovery_point_cntと指定される構文要素を使用して信号伝達されることができる。
【0133】
b. タイル・グループ・ヘッダ内の構文要素recovery_point_cntの存在は、gdr_enabledフラグの値とピクチャーのNAL単位型とに基づいて条件付けされてもよい。すなわち、gdr_enabled_flagが1に等しく、タイル・グループを含むNAL単位のnal_unit_typeがGDR_NUTである場合にのみ、そのフラグが存在する。
【0134】
7）タイル・グループがリフレッシュ領域の一部であるか否かを指定するフラグが、タイル・グループ・ヘッダにおいて信号伝達される。
【0135】
a. フラグはrefreshed_region_flagと指定されてもよい。
【0136】
b. フラグの存在は、gdr_enabled_flagの値とタイル・グループを含むピクチャーがGDR期間内であるかどうかに基づいて条件付けられてもよい。よって、フラグは、以下のすべてが真である場合にのみ存在する。
【0137】
i. gdr_enabled_flagの値が1に等しい。
【0138】
ii. 現在のピクチャーのPOCが、最後のGDRピクチャーのPOC値以上であり（現在のピクチャーがGDRピクチャーである場合、最後のGDRピクチャーが現在のピクチャーである）、GDR期間における最後のピクチャーのPOCよりも小さい。
【0139】
c. フラグがタイル・グループ・ヘッダに存在しない場合、フラグの値は1に等しいと推定される。
【0140】
8）refreshed_region_flagが1に等しいすべてのタイル・グループは、連結領域をカバーする。同様に、refreshed_region_flagが0に等しいすべてのタイル・グループも、連結領域をカバーする。
【0141】
9）refreshed_region_flagをもつタイル・グループは、型I（すなわち、イントラ・タイル・グループ）またはBもしくはP（すなわち、インター・タイル・グループ）であることができる。
【0142】
10）GDRピクチャーから始まりGDR期間における最後のピクチャーまでの各ピクチャーは、refreshed_region_flagが1に等しい少なくとも1つのタイル・グループを含む。
【0143】
11）GDRピクチャーは、refreshed_region_flagが1に等しく、tile_group_typeがIに等しい（すなわち、イントラ・タイル・グループ）少なくとも1つのタイル・グループを含む。
【0144】
12）gdr_enabled_flagが1に等しい場合、長方形タイル・グループの情報、すなわちタイル・グループの数とそれらのアドレスは、ピクチャーパラメータセット（PPS）またはタイル・グループ・ヘッダのいずれかにおいて信号伝達されることが許容される。これを行うために、長方形タイル・グループ情報がPPSに存在するか否かを指定するためのフラグがPPSにおいて信号伝達される。このフラグはrect_tile_group_in_pps_flagと呼ばれてもよい。このフラグは、gdr_enabled_flagが1に等しいときは1に等しくなるように制約されてもよい。
【0145】
a. ある代替では、長方形タイル・グループ情報がPPSに存在するか否かを信号伝達する代わりに、タイル・グループ情報（すなわち、長方形タイル・グループ、ラスタスキャン・タイル・グループなどの任意の型のタイル・グループ）がPPSに存在するか否かを指定する、より一般的なフラグが、PPSにおいて信号伝達されることができる。
【0146】
13）タイル・グループ情報がPPSに存在しない場合、明示的なタイル・グループ識別子（ID）情報の信号伝達が存在しないとさらに制約されてもよい。明示的なタイル・グループID情報は、signaled_tile_group_id_flag、signaled_tile_group_id_length_minus1、およびtile_group_id[i]を含む。
【0147】
14）ピクチャー内のリフレッシュ領域と未リフレッシュ領域との間の境界をまたぐループフィルタリング動作が許容されるかどうかを指定するフラグが信号伝達される。
【0148】
a. このフラグは、PPSにおいて信号伝達され、loop_filter_across_refreshd_region_enabled_flagと呼ばれる。
【0149】
b. loop_filter_across_refreshed_region_enabled_flagの存在は、loop_filter_across_tile_enabled_flagの値で条件付けされてもよい。loop_filter_across_tile_enabled_flagが0に等しい場合、loop_filter_across_refreshed_region_enabled_flagは存在しなくてもよく、その値は0に等しいと推定される。
【0150】
c. ある代替では、フラグはタイル・グループ・ヘッダにおいて信号伝達されてもよく、その存在はrefreshed_region_flagの値に基づいて条件付けされてもよい。すなわち、フラグは、refreshed_region_flagの値が1に等しいときにのみ存在する。
【0151】
15）タイル・グループがリフレッシュ領域であることが示され、かつ、リフレッシュ領域を横切るループ・フィルタが許容されないことが示される場合、以下が適用される。
【0152】
a. タイル・グループの境界におけるエッジのブロッキング解除は、エッジを共有する近傍タイル・グループがリフレッシュされていないタイル・グループである場合、実行されない。
【0153】
b. タイル・グループの境界におけるブロックのためのサンプル適応オフセット（SAO）プロセスは、リフレッシュ領域境界の外側からのいかなるサンプルも使用しない。
【0154】
c. タイル・グループの境界におけるブロックについての適応ループフィルタリング（ALF）プロセスは、リフレッシュ領域境界の外側からのいかなるサンプルも使用しない。
【0155】
16）gdr_enabled_flagが1に等しい場合、各ピクチャーは、ピクチャー内のリフレッシュ領域の境界を決定するための変数に関連付けられる。これらの変数は次のように呼ばれてもよい。
【0156】
a. ピクチャー内のリフレッシュ領域の左境界位置について、PicRefreshedLeftBoundaryPos。
【0157】
b. ピクチャー内のリフレッシュ領域の右境界位置について、PicRefreshedRightBoundaryPos。
【0158】
c. ピクチャー内のリフレッシュ領域の上境界位置について、PicRefreshedTopBoundaryPos。
【0159】
d. ピクチャー内のリフレッシュ領域の下境界位置について、PicRefreshedBotBoundaryPos。
【0160】
17）ピクチャー内のリフレッシュ領域の境界が導出されてもよい。ピクチャーのリフレッシュ領域の境界は、タイル・グループ・ヘッダがパースされ、タイル・グループのrefreshd_region_flagの値が1に等しくなった後、デコーダによって更新される。
【0161】
18）解決策17に対するある代替では、ピクチャー内のリフレッシュされた領域の境界が、ピクチャーの各タイル・グループにおいて明示的に信号伝達される。
【0162】
a. タイル・グループが属するピクチャーが未リフレッシュ領域を含むかどうかを示すフラグが信号伝達されてもよい。ピクチャーが未リフレッシュ領域を含まないことが指定される場合、リフレッシュされた境界情報は信号伝達されず、単にピクチャー境界に等しいと推定されることができる。
【0163】
19）現在のピクチャーについては、リフレッシュ領域の境界は、ループ内フィルタ・プロセスにおいて、以下のように使用される。
【0164】
a. ブロッキング解除プロセスについては、エッジがブロッキング解除される必要があるかどうかを決定するために、リフレッシュ領域のエッジを決定するために。
【0165】
b. SAOプロセスについては、リフレッシュ領域を横切るループ・フィルタが許容されないときに、未リフレッシュ領域からのサンプルを使用するのを避けるよう、クリッピング・プロセスが適用できるように、リフレッシュ領域の境界を決定するために。
【0166】
c. ALFプロセスについては、リフレッシュ領域を横切るループ・フィルタが許容されない場合に、未リフレッシュ領域からのサンプルを使用するのを避けるよう、クリッピング・プロセスが適用できるように、リフレッシュ領域の境界を決定するために。
【0167】
20）動き補償プロセスについては、リフレッシュ領域の境界、特に参照ピクチャーにおけるリフレッシュ領域の境界に関する情報は、以下のように使用される。現在のピクチャーにおける現在のブロックが1に等しいrefreshed_region_flagをもつタイル・グループにあり、参照ブロックが未リフレッシュ領域を含む参照ピクチャーにある場合、以下が当てはまる。
【0168】
a. 現在のブロックからその参照ピクチャーへの動きベクトルは、その参照ピクチャー内のリフレッシュ領域の境界によってクリッピングされる。
【0169】
b.その参照ピクチャー内のサンプルについての小数補間フィルタについて、それは、その参照ピクチャー内のリフレッシュ領域の境界によってクリッピングされる。
【0170】
本開示の実施形態の詳細な説明が提供される。この説明は、JVETの寄稿JVET-M1001-v5である基礎テキストに対するものである。すなわち、差分のみが記述され、下記において言及されない基礎テキスト中のテキストは、そのまま適用される。基礎テキストに対する修正されたテキストはイタリックにされる〔本文中では下線で表す〕。
【0171】
定義が与えられる。
【0172】
3.1 クリーン・ランダム・アクセス（CRA）ピクチャー：各VCL NAL単位がCRA_NUTに等しいnal_unit_typeをもつIRAPピクチャー。
【0173】
注－CRAピクチャーは、そのデコード・プロセスにおけるインター予測のために自分自身以外のどのピクチャーも参照せず、デコード順でビットストリームにおける最初のピクチャーであってもよく、あるいはビットストリームにおいてそれより後に現れてもよい。CRAピクチャーは、関連付けられたRADLまたはRASLピクチャーを有してもよい。CRAピクチャーが1に等しいNoIncorrectPicOutputFlagをもつ場合、関連付けられたRASLピクチャーは、デコーダによって出力されない。RASLピクチャーは、ビットストリーム内に存在しないピクチャーへの参照を含む可能性があるため、デコード可能でない可能性があるからである。
【0174】
3.2 コーディング・ビデオ・シーケンス（CVS）：デコード順で、1に等しいNoIncorrectPicOutputFlagをもつIRAPアクセス単位または1に等しいNoIncorrectPicOutputFlagをもつGDRアクセス単位と、それに続く、1に等しいNoIncorrectPicOutputFlagをもつIRAPアクセス単位または1に等しいNoIncorrectPicOutputFlagをもつGDRアクセス単位ではないゼロ個以上のアクセス単位とで構成され、1に等しいNoIncorrectPicOutputFlagをもつIRAPアクセス単位または1に等しいNoIncorrectPicOutputFlagをもつGDRアクセス単位である任意のその後のアクセス単位までだが該任意のその後のアクセス単位は含まないすべてのその後のアクセス単位を含む、コーディング・ビデオ・シーケンス（CVS）。
【0175】
注1－IRAPアクセス単位は、IDRアクセス単位またはCRAアクセス単位でありうる。NoIncorrectPicOutputFlagの値は、デコード順でビットストリームにおける最初のアクセス単位である、デコード順でシーケンスNAL単位の末尾に続く最初のアクセス単位である、または1に等しいHandleCraAsCvsStartFlagをもつ各IDRアクセス単位と各CRAアクセス単位について、1に等しい。
【0176】
注2－NoIncorrectPicOutputFlagは、デコード順でビットストリームにおける最初のアクセス単位である、デコード順でシーケンスNAL単位の末尾に続く最初のアクセス単位である、または1に等しいHandleGdrAsCvsStartFlagをもつ各GDRアクセス単位について、1に等しい。
【0177】
3.3 漸進的デコード・リフレッシュ（GDR）アクセス単位：コーディング・ピクチャーがGDRピクチャーであるアクセス単位。
【0178】
3.4 漸進的デコード・リフレッシュ（GDR）ピクチャー：各VCL NAL単位がGDR_NUTSに等しいnal_unit_typeをもつピクチャー。
【0179】
3.5 ランダム・アクセス・スキップ先頭（RASL）ピクチャー：各VCL NAL単位がRASL_NUTに等しいnal_unit_typeをもつコーディングされたピクチャー。
【0180】
注－すべてのRASLピクチャーは、関連付けられたCRAピクチャーの先頭ピクチャーである。関連付けられたCRAピクチャーが1に等しいNoIncorrectPicOutputFlagをもつ場合、RASLピクチャーは出力されず、正しくデコード可能でない可能性がある。RASLピクチャーは、ビットストリームにおいて存在しないピクチャーへの参照を含む可能性があるからである。RASLピクチャーは、非RASLピクチャーのデコード・プロセスのための参照ピクチャーとしては使用されない。存在する場合、すべてのRASLピクチャーは、デコード順で、同じ関連付けられたCRAピクチャーのすべての後続ピクチャーより前にくる。
【0181】
シーケンスパラメータセットの生バイトシーケンスペイロード（raw byte sequence payload、RBSP）構文と意味内容
【表1】
【0182】
gdr_enabled_flagが1に等しいことは、GDRピクチャーがコーディングされたビデオ・シーケンスに存在しうることを指定する。gdr_enabled_flagが0に等しいことは、GDRピクチャーがコーディングされたビデオ・シーケンスに存在しないことを指定する。
【0183】
ピクチャーパラメータセットのRBSP構文および意味内容
【表2】
【0184】
rect_tile_group_info_in_pps_flagが1に等しいことは、長方形タイル・グループ情報がPPSにおいて信号伝達されることを指定する。rect_tile_group_info_in_pps_flagが0に等しいことは、長方形のタイル・グループ情報がPPSにおいて信号伝達されないことを指定する。
【0185】
アクティブSPSにおけるgdr_enabled_flagの値が0に等しい場合にrect_tile_group_info_in_pps_flagの値が0に等しいことは、ビットストリーム適合性の要件である。
【0186】
loop_filter_across_refreshed_region_enabled_flagが1に等しいことは、PPSを参照するピクチャーにおいて1に等しいrefreshed_region_flagをもつタイル・グループの境界を横断してループ内フィルタリング動作が実行されてもよいことを指定する。loop_filter_across_refreshed_region_enabled_flagが0に等しいことは、PPSを参照するピクチャーにおいて1に等しいrefreshed_region_flagをもつタイル・グループの境界を横断してループ内フィルタリング動作が実行されないことを指定する。ループ内フィルタリング動作は、ブロッキング解除フィルタ、サンプル適応オフセットフィルタ、および適応ループ・フィルタ動作を含む。存在しない場合、loop_filter_across_refreshed_region_enabled_flagの値は0に等しいと推定される。
【0187】
signalled_tile_group_id_flagが1に等しいことは、各タイル・グループについてのタイル・グループIDが信号伝達されることを指定する。signalled_tile_group_index_flagが0に等しいことは、タイル・グループIDが信号伝達されないことを指定する。存在しない場合、signalled_tile_group_index_flagの値は0に等しいと推定される。
【0188】
signalled_tile_group_length_minus1に1を加えたものは、タイル・グループ・ヘッダにおける、存在する場合の構文要素tile_group_id[i]と、構文要素tile_group_addressとを表すために使用されるビット数とを指定する。signalled_tile_group_index_length_minus1の値は、0～15の範囲である（両端含む）。存在しない場合、signalled_tile_group_index_length_minus1の値は以下のように推定される。
【0189】
rect_tile_group_info_in_pps_flagが1に等しい場合は、Ceil（Log2（num_tile_groups_in_pic_minus1＋1））－1。
【0190】
それ以外の場合は、Ceil（Log2（NumTilesInPic））－1。
【0191】
一般タイル・グループ・ヘッダ構文および意味内容
【表3】
【0192】
tile_group_addressは、タイル・グループの最初のタイルのタイル・アドレスを指定する。存在しない場合、tile_group_addressの値は0に等しいと推定される。
【0193】
rect_tile_group_flagが0に等しい場合、以下が適用される：
tile_group_addressは、式6-7によって指定されるタイルIDである。
tile_group_addressの長さはCeil（Log2（NumTilesInPic））ビットである。
tile_group_addressの値は、0からNumTilesInPic－1の範囲とする（両端含む）。
tile_group_addressは、式6-7によって指定されるタイルIDである。
tile_group_addressの長さはCeil（Log2（NumTilesInPic））ビットである。
tile_group_addressの値は、0からNumTilesInPic－1の範囲とする（両端含む）。
【0194】
そうでない場合、rect_tile_group_flagが1に等しく、rect_tile_group_info_in_ppsが0に等しい場合、以下が適用される：
tile_group_addressは、i番目のタイル・グループの左上隅に位置するタイルのタイル・インデックスである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1＋1ビットである。
signelled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は0からNumTilesInPic－1までの範囲とする（両端含む）。そうでない場合、tile_group_addressの値は、0から2 (signalled_tile_group_index_length_minus1+1) －1の範囲とする（両端含む）。
tile_group_addressは、i番目のタイル・グループの左上隅に位置するタイルのタイル・インデックスである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1＋1ビットである。
signelled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は0からNumTilesInPic－1までの範囲とする（両端含む）。そうでない場合、tile_group_addressの値は、0から2 (signalled_tile_group_index_length_minus1+1) －1の範囲とする（両端含む）。
【0195】
そうでない場合（rect_tile_group_flagが1に等しく、rect_tile_group_in_ppsが1に等しい）は、以下が適用される。
tile_group_addressは、タイル・グループのタイル・グループIDである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1＋1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、0からnum_tile_groups_in_pic_minus1の範囲とする（両端含む）。そうでない場合、tile_group_addressの値は0から2(signalled_tile_group_index_length_minus1+1)－1の範囲とする（両端含む）。
tile_group_addressは、タイル・グループのタイル・グループIDである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1＋1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、0からnum_tile_groups_in_pic_minus1の範囲とする（両端含む）。そうでない場合、tile_group_addressの値は0から2(signalled_tile_group_index_length_minus1+1)－1の範囲とする（両端含む）。
【0196】
bottom_right_tile_idは、タイル・グループの右下隅に位置するタイルのタイル・インデックスを指定する。single_tile_per_tile_group_flagが1に等しい場合、bottom_right_tile_idはtile_group_addressに等しいと推定される。bottom_right_tile_id構文要素の長さはCeil（Log2（NumTilesInPic））ビットである。
【0197】
現在のタイル・グループにおけるタイル数を指定する変数NumTilesInCurrTileGroup、タイル・グループの左上タイルのタイル・インデックスを指定するTopLeftTileIdx、タイル・グループの右下タイルのタイル・インデックスを指定するBottomRightTileIdx、および現在のタイル・グループのi番目タイルのタイル・インデックスを指定するTgTileIdx[i]は次のように導出される。
【表4】
【0198】
recovery_poc_cntは、デコードされたピクチャーの回復点を出力順で指定する。CVSにおいてデコード順で現在のピクチャー（すなわち、GDRピクチャー）に続くピクチャーpicAであって、現在のピクチャーのPicOrderCntValにrecovery_poc_cntの値を加えたものに等しいPicOrderCntValをもつものがある場合、ピクチャーpicAは、回復点ピクチャーと称される。そうでない場合、現在のピクチャーのPicOrderCntValにrecovery_poc_cntの値を加えたものよりも大きいPicOrderCntValをもつ出力順で最初のピクチャーが、回復点ピクチャーと称される。回復点ピクチャーは、デコード順で現在のピクチャーに先行しない。出力順でのすべてのデコードされたピクチャーは、回復点ピクチャーの出力順位置で始まるコンテンツにおいて、正しいまたはほぼ正しいと示される。recovery_poc_cntの値は、－MaxPicOrderCntLsb/2からMaxPicOrderCntLsb/2－1の範囲とする（両端含む）。
【0199】
RecoveryPointPocValの値は、次のように導出される。
【0200】
RecoveryPointPocVal＝PicOrderCntVal＋recovery_poc_cnt。
【0201】
refreshed_region_flagが1に等しいことは、タイル・グループのデコードが、関連付けられたGDRのNoIncorrectPicOutputFlagの値にかかわらず、正しい再構成されたサンプル値を生成することを指定する。refreshed_region_flagが0に等しいことは、タイル・グループのデコードが、1に等しいNoIncorrectPicOutputFlagをもつ関連付けられたGDRから始まる場合に、正しくない再構成されたサンプル値を生成する可能性があることを指定する。存在しない場合、refreshed_region_flagの値は1に等しいと推定される。
【0202】
注x－現在のピクチャー自身は、1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーであることができる。
【0203】
タイル・グループ・リフレッシュされた境界は、次のように導出される：
【表5】
【0204】
NAL単位ヘッダの意味内容
【表6】
【0205】
…
【0206】
nal_unit_typeがGDR_NUTに等しい場合、コーディングされたタイル・グループはGDRピクチャーに属し、TemporalIdは0に等しい。
【0207】
アクセス単位の順序およびCVSへの関連付けが論じられる。
【0208】
この仕様に準拠するビットストリーム（すなわち、JVETの寄稿JVET-M1001-v5）は、一つまたは複数のCVSを含む。
【0209】
CVSは、一つまたは複数のアクセス単位を含む。NAL単位とコーディングされたピクチャーの順序およびアクセス単位へのそれらの関連付けは、節7.4.2.4.4の中で記述される。
【0210】
CVSの最初のアクセス単位は、以下のいずれかである。
【0211】
・1に等しいNoBrokenPictureOutputFlagをもつIRAPアクセス単位。
【0212】
・1に等しいNoIncorrectPicOutputFlagをもつGDRアクセス単位。
【0213】
ビットストリーム適合性の要件は、存在する場合、シーケンスNAL単位の末尾またはビットストリームNAL単位の末尾を含むアクセス単位の後の次のアクセス単位が以下のいずれかであることである。
【0214】
・IRAPアクセス単位。これはIDRアクセス単位またはCRAアクセス単位でありうる。
【0215】
・GDRアクセス単位。
【0216】
8.1.1 コーディングされたピクチャーのデコード・プロセスが論じられる。
【0217】
…
【0218】
現在のピクチャーがIRAPピクチャーである場合、以下が適用される。
【0219】
・現在のピクチャーがIDRピクチャー、デコード順でビットストリームにおける最初のピクチャー、またはデコード順でシーケンスNAL単位の末尾に続く最初のピクチャーである場合、変数NoIncorrectPicOutputFlagは1に等しく設定される。
【0220】
・それ以外の場合で、本仕様に規定されていない何らかの外部手段（たとえば、ユーザー入力）が、変数HandleCraAsCvsStartFlagを現在のピクチャーの値に設定するために利用可能である場合、変数HandleCraAsCvsStartFlagは外部手段によって提供される値に等しく設定され、変数NoIncorrectPicOutputFlagはHandleCraAsCvsStartFlagに等しく設定される。
【0221】
・それ以外の場合、変数HandleCraAsCvsStartFlagは0に等しく設定され、変数NoIncorrectPicOutputFlagは0に等しく設定される。
【0222】
現在のピクチャーがGDRピクチャーである場合、以下が適用される。
【0223】
・現在のピクチャーがGDRピクチャー、デコード順でビットストリームにおける最初のピクチャー、またはデコード順でシーケンスNAL単位の末尾に続く最初のピクチャーである場合、変数NoIncorrectPicOutputFlagは1に等しく設定される。
【0224】
・そうでない場合で、本仕様において規定されていない何らかの外部手段が変数HandleGdrAsCvsStartFlagを現在のピクチャーについての値に設定するために利用可能である場合、変数HandleGdrAsCvsStartFlagは外部手段によって提供する値に等しく設定され、変数NoIncorrectPicOutputFlagはHandleGdrAsCvsStartFlagに等しく設定される。
【0225】
・そうでない場合、変数HandleGdrAsCvsStartFlagは0に等しく設定され、変数NoIncorrectPicOutputFlagは0に等しく設定される。
【0226】
…
【0227】
デコード・プロセスは、現在のピクチャーCurrPicについて次のように動作する。
【0228】
1. NAL単位のデコードは節8.2において規定される。
【0229】
2. 節8.3におけるプロセスは、タイル・グループ・ヘッダ層およびそれより上における構文要素を使用して、以下のデコード・プロセスを規定する。
【0230】
・ピクチャー順カウントに関する変数および関数は、節8.3.1に規定されているように導出される。これは、ピクチャーの最初のタイル・グループについてのみ呼び出される必要がある。
【0231】
・非IDRピクチャーの各タイル・グループについてのデコード・プロセスの開始時に、参照ピクチャー・リスト0（RefPicList[0]）および参照ピクチャー・リスト1（RefPicList[1]）の導出のために、節8.3.2に規定されている参照ピクチャー・リスト構築のためのデコード・プロセスが呼び出される。
【0232】
・節8.3.3における参照ピクチャー・マーキングのためのデコード・プロセスが呼び出される。ここで、参照ピクチャーが「参照のために不使用」または「長期参照のために使用」とマークされうる。これは、ピクチャーの最初のタイル・グループについてのみ呼び出される。
【0233】
・PicOutputFlagは以下のように設定される。
【0234】
・以下の条件のいずれかが真である場合、PictureOutputFlagは0に設定される：
【0235】
・現在のピクチャーがRASLピクチャーであり、関連付けられたIRAPピクチャーのNoIncorrectPicOutputFlagが1に等しい。
【0236】
・gdr_enabled_flagが1に等しく、現在のピクチャーは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーである。
【0237】
・gdr_enabled_flagが1に等しく、現在のピクチャーは、0に等しいrefreshed_region_flagをもつ一つまたは複数のタイル・グループを含み、関連付けられたGDRピクチャーのNoBrokenPictureOutputFlagが1に等しい。
【0238】
・それ以外の場合、PicOutputFlagは1に等しく設定される。
【0239】
3. 諸デコード・プロセスが、ツリー単位、スケーリング、変換、ループ内フィルタリングなどをコーディングするために呼び出される。
【0240】
4. 現在のピクチャーのすべてのタイル・グループがデコードされた後、現在のデコードされたピクチャーが「短期参照のために使用」とマークされる。
【0241】
ピクチャー順カウントのためのデコード・プロセスが論じられる。
【0242】
このプロセスの出力は、現在のピクチャーのピクチャー順カウントであるPicOrderCntValである。
【0243】
各コーディングされたピクチャーは、PicOrderCntValとして示されるピクチャー順カウント変数に関連付けられる。
【0244】
現在のピクチャーが、1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーまたは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーでない場合、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは以下のように導出される。
【0245】
・prevTid0Picを、0に等しいTemporalIdをもち、RASLまたはRADLピクチャーではない、デコード順で直前のピクチャーであるとする。
【0246】
・変数prevPicOrderCntLsbが、prevTid0Picのtile_group_pic_order_cnt_lsbに等しく設定される。
【0247】
・変数prevPicOrderCntMsbが、prevTid0PicのPicOrderCntMsbに等しく設定される。
【0248】
現在のピクチャーの変数PicOrderCntMsbは以下のように導出される。
【0249】
・現在のピクチャーが、1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーまたは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーである場合、PicOrderCntMsbは0に等しく設定される。
【0250】
・それ以外の場合、PicOrderCntMsbは以下のように導出される。
PicOrderCntValは以下のように導出される。
PicOrderCntVal＝PicOrderCntMsb＋tile_group_pic_order_cnt_lsb (8-2)
【表7】
PicOrderCntValは以下のように導出される。
PicOrderCntVal＝PicOrderCntMsb＋tile_group_pic_order_cnt_lsb (8-2)
【0251】
注1－ 1に等しいNoIncorrectPicOutputFlagをもつすべてのIRAPピクチャーは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValをもつ。1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーについては、PicOrderCntMsbは0に等しく設定されるからである。
【0252】
注1－ 1に等しいNoIncorrectPicOutputFlagをもつすべてのGDRピクチャーは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValをもつ。1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーについては、PicOrderCntMsbは0に等しく設定されるからである。
【0253】
PicOrderCntValの値は、－231から231－1の範囲とする（両端含む）。
【0254】
現在のピクチャーがGDRピクチャーである場合、LastGDRPocValの値はPicOrderCntValに等しく設定される。
【0255】
ピクチャーのリフレッシュ境界位置についてのデコード・プロセスが論じられる。
【0256】
このプロセスは、gdr_enabled_flagが1に等しい場合にのみ呼び出される。
【0257】
このプロセスは、タイル・グループ・ヘッダのパースが完了した後に呼び出される。
【0258】
このプロセスの出力は、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosという、現在のピクチャーのリフレッシュ領域の境界位置である。
【0259】
各コーディングされたピクチャーは、PicOrderCntValとして示されるリフレッシュ領域境界位置変数の集合に関連付けられる。
【0260】
PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosは、以下のように導出される。
【0261】
タイル・グループが、1に等しいrefreshed_region_flagをもつ現在のピクチャーの最初に受領されたタイル・グループである場合、下記が適用される：
PicRefreshedLeftBoundaryPos＝TGRefreshedLeftBoundary
PicRefreshedRightBoundaryPos＝TGRefreshedRightBoundary
PicRefreshedTopBoundaryPos＝TGRefreshedTopBoundary
PicRefreshedBotBoundaryPos＝TileGroupBotBoundary
そうでない場合で、refreshed_region_flagが1に等しい場合、下記が適用される。
PicRefreshedLeftBoundaryPos＝TGRefreshedLeftBoundary < PicRefreshedLeftBoundaryPos ?
TGRefreshedLeftBoundary : PicRefreshedLeftBoundaryPos
PicRefreshedRightBoundaryPos＝TGRefreshedRightBoundary > PicRefreshedRightBoundaryPos ?
TGRefreshedRightBoundary : PicRefreshedRightBoundaryPos
PicRefreshedTopBoundaryPos＝TGRefreshedTopBoundary < PicRefreshedTopBoundaryPos ?
TGRefreshedTopBoundary : RefreshedRegionTopBoundaryPos
PicRefreshedBotBoundaryPos＝TileGroupBotBoundary > PicRefreshedBotBoundaryPos ?
TileGroupBotBoundary : PicRefreshedBotBoundaryPos
PicRefreshedLeftBoundaryPos＝TGRefreshedLeftBoundary
PicRefreshedRightBoundaryPos＝TGRefreshedRightBoundary
PicRefreshedTopBoundaryPos＝TGRefreshedTopBoundary
PicRefreshedBotBoundaryPos＝TileGroupBotBoundary
そうでない場合で、refreshed_region_flagが1に等しい場合、下記が適用される。
PicRefreshedLeftBoundaryPos＝TGRefreshedLeftBoundary < PicRefreshedLeftBoundaryPos ?
TGRefreshedLeftBoundary : PicRefreshedLeftBoundaryPos
PicRefreshedRightBoundaryPos＝TGRefreshedRightBoundary > PicRefreshedRightBoundaryPos ?
TGRefreshedRightBoundary : PicRefreshedRightBoundaryPos
PicRefreshedTopBoundaryPos＝TGRefreshedTopBoundary < PicRefreshedTopBoundaryPos ?
TGRefreshedTopBoundary : RefreshedRegionTopBoundaryPos
PicRefreshedBotBoundaryPos＝TileGroupBotBoundary > PicRefreshedBotBoundaryPos ?
TileGroupBotBoundary : PicRefreshedBotBoundaryPos
【0262】
参照ピクチャー・リスト構築のためのデコード・プロセスが論じられる。
…
…
【0263】
1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーまたは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーでない各現在のピクチャーについて、maxPicOrderCnt－minPicOrderCntの値がMaxPicOrderCntLsb/2より小さいことは、ビットストリーム適合性の要件である。
…
…
【0264】
参照ピクチャー・マーキングについてのデコード・プロセス
…
現在のピクチャーが、1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーまたは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーである場合、現在、DPBにあるすべての参照ピクチャー（もしあれば）は、「参照のために不使用」としてマークされる。
…
…
現在のピクチャーが、1に等しいNoIncorrectPicOutputFlagをもつIRAPピクチャーまたは1に等しいNoIncorrectPicOutputFlagをもつGDRピクチャーである場合、現在、DPBにあるすべての参照ピクチャー（もしあれば）は、「参照のために不使用」としてマークされる。
…
【0265】
時間的ルーマ動きベクトル予測のための導出プロセスが論じられる。
…
変数currCbは、ルーマ位置(xCb,yCb)における現在のルーマコーディング・ブロックを指定する。
…
変数currCbは、ルーマ位置(xCb,yCb)における現在のルーマコーディング・ブロックを指定する。
【0266】
変数mvLXColおよびavailableFlagLXColは、以下のように導出される：
・tile_group_temporal_mvp_enabled_flagが0に等しい場合、mvLXColの両方のコンポーネントが0に等しく設定され、availableFlagLXColが0に等しく設定される。
・そうでない場合（tile_group_temporal_mvp_enabled_flagが1に等しい）、以下の順序付けられたステップが適用される：
1. 右下の共位置の動きベクトルは以下のように導出される：
・tile_group_temporal_mvp_enabled_flagが0に等しい場合、mvLXColの両方のコンポーネントが0に等しく設定され、availableFlagLXColが0に等しく設定される。
・そうでない場合（tile_group_temporal_mvp_enabled_flagが1に等しい）、以下の順序付けられたステップが適用される：
1. 右下の共位置の動きベクトルは以下のように導出される：
【表8】
【0267】
・yCb>>CtbLog2SizeYがyColBr>>CtbLog2Sizeに等しく、yColBrがtopBoundaryPosからbotBoundaryPosまでの範囲（両端含む）にあり、xColBrがleftBoundaryPosからrightBoundaryPosまでの範囲（両端含む）にある場合、下記が適用される。
【0268】
・変数colCbは、ColPicによって指定される共位置のピクチャー内の、（(xColBr>>3)<<3,(yColBr>>3)<<3）によって与えられる修正された位置をカバーするルーマコーディング・ブロックを指定する。
【0269】
・ルーマ位置(xColCb,yColCb)は、ColPicによって指定された共位置のピクチャーの左上のルーマ・サンプルに対する、colCbによって指定された共位置のルーマコーディング・ブロックの左上のサンプルに等しく設定される。
【0270】
・節8.5.2.12において指定されている共位置の動きベクトルについての導出プロセスは、currCb、colCb、(xColCb,yColCb)、refIdxLX、sbFlag（0に設定されている）を入力として呼び出され、出力はmvLXColとavailableFlagLXColに割り当てられる。
【0271】
・それ以外の場合、mvLXColの両方の成分は0に等しく設定され、availableFlagLXColは0に等しく設定される。
【0272】
2. …
ルーマ・サンプル双線形補間プロセスが論じられる。
ルーマ・サンプル双線形補間プロセスが論じられる。
【0273】
このプロセスへの入力は以下の通り：
・完全サンプル単位のルーマ位置(xIntL,yIntL)
・小数サンプル単位のルーマ位置(xFracL,yFracL)
・ルーマ参照サンプル配列refPicLXL
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
・完全サンプル単位のルーマ位置(xIntL,yIntL)
・小数サンプル単位のルーマ位置(xFracL,yFracL)
・ルーマ参照サンプル配列refPicLXL
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
【0274】
完全サンプル単位のルーマ位置(xInti,yInti)は、i＝0..1について、以下のように導出される：
…
【表9】
…
【0275】
ルーマ・サンプル8タップ補間フィルタリング・プロセスが論じられる。
【0276】
このプロセスへの入力は以下の通り：
・完全サンプル単位のルーマ位置(xIntL,yIntL)
・小数サンプル単位のルーマ位置(xFracL,yFracL)
・ルーマ参照サンプル配列refPicLXL、
・参照サンプル・パディング方向および量を指定する、dir＝0、1のリストpadVal[dir]
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
・完全サンプル単位のルーマ位置(xIntL,yIntL)
・小数サンプル単位のルーマ位置(xFracL,yFracL)
・ルーマ参照サンプル配列refPicLXL、
・参照サンプル・パディング方向および量を指定する、dir＝0、1のリストpadVal[dir]
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
【0277】
完全サンプル単位のルーマ位置(xInti,yInti)は、i＝0..7について以下のように導出される。
…
【表10】
…
【0278】
クロマ・サンプル補間プロセスが論じられる。
【0279】
このプロセスへの入力は以下の通り：
・完全サンプル単位のクロマ位置(xIntC,yIntC)
・1/32の小数サンプル単位のクロマ位置(xFracC,yFracC)
・クロマ参照サンプル配列refPicLXC
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
・完全サンプル単位のクロマ位置(xIntC,yIntC)
・1/32の小数サンプル単位のクロマ位置(xFracC,yFracC)
・クロマ参照サンプル配列refPicLXC
・参照ピクチャーのリフレッシュ領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos
…
【0280】
変数xOffsetは、（sps_ref_wraparound_offset_minus1＋1）*MinCbSizeY）/SubWidthCに等しく設定される。
【0281】
完全サンプル単位のクロマ位置(xInti,yInti)は、i＝0..3について以下のように導出される：
【表11】
【0282】
ブロッキング解除フィルタ・プロセスが論じられる。
【0283】
一般的なプロセス
…
…
【0284】
ブロッキング解除フィルタ・プロセスは、以下の型のエッジを除き、ピクチャーのすべてのコーディングサブブロック・エッジおよび変換ブロック・エッジに適用される：
・ピクチャーの境界にあるエッジ
・下記のすべてが満たされる場合、タイル・グループtgAの上の境界と一致するエッジ
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・当該エッジがタイル・グループtgBの下の境界と一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値と異なる
・下記のすべてが満たされる場合、タイル・グループtgAの左の境界と一致するエッジ
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・当該エッジがタイル・グループtgBの右の境界と一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値と異なる
・loop_filter_cross_tiles_enabled_flagが0に等しい場合、タイル境界と一致するエッジ
・0に等しいtile_group_loop_filter_across_tile_groups_enabled_flagまたは1に等しいtile_group_deblocking_filter_disabled_flagをもつタイル・グループの上または左の境界と一致するエッジ。
・1に等しいtile_group_deblocking_filter_disabled_flagをもつ諸タイル・グループ内のエッジ
・考えられている成分の8×8のサンプル・グリッド境界に対応しないエッジ
・エッジの両側がインター予測を使用する、クロマ成分内のエッジ
・クロマ変換ブロックのエッジであって、関連付けられた変換単位のエッジではないもの
・ISP_NO_SPLITと等しくないIntraSubPartitionsSplit値をもつコーディング単位のルーマ変換ブロックをまたぐエッジ。
・ピクチャーの境界にあるエッジ
・下記のすべてが満たされる場合、タイル・グループtgAの上の境界と一致するエッジ
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・当該エッジがタイル・グループtgBの下の境界と一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値と異なる
・下記のすべてが満たされる場合、タイル・グループtgAの左の境界と一致するエッジ
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・当該エッジがタイル・グループtgBの右の境界と一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値と異なる
・loop_filter_cross_tiles_enabled_flagが0に等しい場合、タイル境界と一致するエッジ
・0に等しいtile_group_loop_filter_across_tile_groups_enabled_flagまたは1に等しいtile_group_deblocking_filter_disabled_flagをもつタイル・グループの上または左の境界と一致するエッジ。
・1に等しいtile_group_deblocking_filter_disabled_flagをもつ諸タイル・グループ内のエッジ
・考えられている成分の8×8のサンプル・グリッド境界に対応しないエッジ
・エッジの両側がインター予測を使用する、クロマ成分内のエッジ
・クロマ変換ブロックのエッジであって、関連付けられた変換単位のエッジではないもの
・ISP_NO_SPLITと等しくないIntraSubPartitionsSplit値をもつコーディング単位のルーマ変換ブロックをまたぐエッジ。
【0285】
ある方向についてのブロッキング解除フィルタ・プロセスが論じられる。
…
コーディング・ブロック幅log2CbW、コーディング・ブロック高さlog2CbH、およびコーディング・ブロックの左上サンプルの位置(xCb,yCb)をもつ各コーディング単位について、edgeTypeがEDGE_VERに等しく、xCb % 8が0に等しい場合、またはedgeTypeがEDGE_HORに等しく、yCb % 8が0に等しい場合、エッジは以下の順序付けられたステップによってフィルタリングされる。
…
コーディング・ブロック幅log2CbW、コーディング・ブロック高さlog2CbH、およびコーディング・ブロックの左上サンプルの位置(xCb,yCb)をもつ各コーディング単位について、edgeTypeがEDGE_VERに等しく、xCb % 8が0に等しい場合、またはedgeTypeがEDGE_HORに等しく、yCb % 8が0に等しい場合、エッジは以下の順序付けられたステップによってフィルタリングされる。
【0286】
1. コーディング・ブロック幅nCbWが1<<log2CbWに設定され、コーディング・ブロック高さnCbHが1<<log2CbHに設定される。
【0287】
2. 変数filterEdgeFlagは以下のように導出される。
・edgeTypeがEDGE_VERに等しく、以下の条件のうちの一つまたは複数が真である場合、filterEdgeFlagは0に設定される：
・現在のコーディング・ブロックの左境界がピクチャーの左境界である。
・現在のコーディング・ブロックの左境界はタイルの左境界であり、loop_filter_across_tiles_enabled_flagは0に等しい。
・現在のコーディング・ブロックの左境界がタイル・グループの左境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・現在のコーディング・ブロックの左境界は、現在のタイル・グループの左境界であり、以下のすべての条件が満たされる：
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・現在のタイル・グループの左境界と境界を共有するタイル・グループが存在し、そのrefreshed_region_flagの値が現在のタイル・グループのrefreshed_region_flagの値と異なる。
・edgeTypeがEDGE_VERに等しく、以下の条件のうちの一つまたは複数が真である場合、filterEdgeFlagは0に設定される：
・現在のコーディング・ブロックの左境界がピクチャーの左境界である。
・現在のコーディング・ブロックの左境界はタイルの左境界であり、loop_filter_across_tiles_enabled_flagは0に等しい。
・現在のコーディング・ブロックの左境界がタイル・グループの左境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・現在のコーディング・ブロックの左境界は、現在のタイル・グループの左境界であり、以下のすべての条件が満たされる：
・gdr_enabled_flagが1に等しい
・loop_filter_across_refreshed_region_enabled_flagが0に等しい
・現在のタイル・グループの左境界と境界を共有するタイル・グループが存在し、そのrefreshed_region_flagの値が現在のタイル・グループのrefreshed_region_flagの値と異なる。
【0288】
・それ以外の場合、edgeTypeがEDGE_HORに等しく、以下の条件のうちの一つまたは複数が真である場合、変数filterEdgeFlagは0に等しく設定される：
・現在のルーマコーディング・ブロックの上の境界がピクチャーの上の境界である。
・現在のコーディング・ブロックの上の境界はタイルの上の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
・現在のコーディング・ブロックの上の境界は、タイル・グループの上の境界であり、tile_group_loop_filter_cross_tile_groups_enabled_flagが0に等しい。
・現在コーディング・ブロックの上の境界が現在のタイル・グループの上の境界であり、以下のすべての条件が満たされる：
・gdr_enabled_flagが1に等しい。
・loop_filter_across_refreshed_region_enabled_flagが0に等しい。
・現在のタイル・グループの上の境界と境界を共有するタイル・グループが存在し、そのrefreshed_region_flagの値が現在のタイル・グループのrefreshed_region_flagの値と異なる。
・現在のルーマコーディング・ブロックの上の境界がピクチャーの上の境界である。
・現在のコーディング・ブロックの上の境界はタイルの上の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
・現在のコーディング・ブロックの上の境界は、タイル・グループの上の境界であり、tile_group_loop_filter_cross_tile_groups_enabled_flagが0に等しい。
・現在コーディング・ブロックの上の境界が現在のタイル・グループの上の境界であり、以下のすべての条件が満たされる：
・gdr_enabled_flagが1に等しい。
・loop_filter_across_refreshed_region_enabled_flagが0に等しい。
・現在のタイル・グループの上の境界と境界を共有するタイル・グループが存在し、そのrefreshed_region_flagの値が現在のタイル・グループのrefreshed_region_flagの値と異なる。
【0289】
それ以外の場合、filterEdgeFlagは1に設定される。
【0290】
ひとたびタイルが統合されたら、構文を適応させる。
【0291】
3. 二次元の(nCbW)×(nCbH)配列edgeFlagsのすべての要素は、ゼロに等しいように初期化される。
【0292】
SAOのためのCTB修正プロセスが論じられる。
…
…
【0293】
i＝0..nCtbSw－1およびj＝0..nCtbSh－1のすべてのサンプル位置(xSi,ySj)および(xYi,yYj)について、recPicture[xSi][ySj]をカバーするコーディング・ブロックを含むコーディング単位のpcm_loop_filter_disabled_flag、pcm_flag[xYi][yYj]およびcu_transquant_bypass_flagの値に依存して、下記が適用される：
・…
・…
【0294】
将来の決定変換／量子化バイパスに依存して、ハイライトされたセクションを修正する。
・それ以外の場合、SaoTypeIdx[cIdx][rx][ry]が2に等しい場合、以下の順序付けられたステップが適用される：
1. k＝0..1についてのhPos[k]およびvPos[k]の値は、SaoEoClass[cIdx][rx][ry]に基づいてテーブル8-18において規定されている。
2. 変数edgeIdxは以下のように導出される：
・修正されたサンプル位置(xSik',ySjk'）および（xYik',yYjk')は以下のように導出される：
（xSik',ySjk'）＝（xSi＋hPos[k],ySj＋vPos[k]） （8-1128）
（xYik',yYjk'）＝（cIdx==0） ? （xSik',ySjk'） : （xSik'*SubWidthC,ySjk'*SubHeightC） （8-1129）
・k＝0..1のすべてのサンプル位置(xSik',ySjk')および(xYik',yYjk')について以下の条件の一つまたは複数が真である場合、edgeIdxは0に等しく設定される。
・位置(xSik',ySjk')のサンプルがピクチャー境界の外側にある。
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、現在のタイル・グループのrefreshed_region_flagが1に等しく、位置(xS ik' ,yS jk' )におけるサンプルを含むタイル・グループのrefreshed_region_flagが0に等しい。
・位置(xSik',ySjk')のサンプルが異なるタイル・グループに属し、次の2つの条件のいずれかが真である：
・MinTbAddrZs[xYik'>>MinTbLog2SizeY][yYjk'>>MinTbLog2SizeY]がMinTbAddrZs[xYi>>MinTbLog2SizeY][yYj>>MinTbLog2SizeY]より小さく、サンプルrecPicture[xSi][ySj]が属するタイル・グループにおけるtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・MinTbAddrZs[xYi>>MinTbLog2SizeY][yYj>>MinTbLog2SizeY]がMinTbAddrZs[xYik'>>MinTbLog2SizeY][yYjk'>>MinTbLog2SizeY]より小さく、サンプルrecPicture[xSik'][ySjk']が属するタイル・グループにおけるtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・loop_filter_across_tiles_enabled_flagが0に等しく、位置(xSik',ySjk')のサンプルが別のタイルに属する。
・それ以外の場合、SaoTypeIdx[cIdx][rx][ry]が2に等しい場合、以下の順序付けられたステップが適用される：
1. k＝0..1についてのhPos[k]およびvPos[k]の値は、SaoEoClass[cIdx][rx][ry]に基づいてテーブル8-18において規定されている。
2. 変数edgeIdxは以下のように導出される：
・修正されたサンプル位置(xSik',ySjk'）および（xYik',yYjk')は以下のように導出される：
（xSik',ySjk'）＝（xSi＋hPos[k],ySj＋vPos[k]） （8-1128）
（xYik',yYjk'）＝（cIdx==0） ? （xSik',ySjk'） : （xSik'*SubWidthC,ySjk'*SubHeightC） （8-1129）
・k＝0..1のすべてのサンプル位置(xSik',ySjk')および(xYik',yYjk')について以下の条件の一つまたは複数が真である場合、edgeIdxは0に等しく設定される。
・位置(xSik',ySjk')のサンプルがピクチャー境界の外側にある。
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、現在のタイル・グループのrefreshed_region_flagが1に等しく、位置(xS ik' ,yS jk' )におけるサンプルを含むタイル・グループのrefreshed_region_flagが0に等しい。
・位置(xSik',ySjk')のサンプルが異なるタイル・グループに属し、次の2つの条件のいずれかが真である：
・MinTbAddrZs[xYik'>>MinTbLog2SizeY][yYjk'>>MinTbLog2SizeY]がMinTbAddrZs[xYi>>MinTbLog2SizeY][yYj>>MinTbLog2SizeY]より小さく、サンプルrecPicture[xSi][ySj]が属するタイル・グループにおけるtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・MinTbAddrZs[xYi>>MinTbLog2SizeY][yYj>>MinTbLog2SizeY]がMinTbAddrZs[xYik'>>MinTbLog2SizeY][yYjk'>>MinTbLog2SizeY]より小さく、サンプルrecPicture[xSik'][ySjk']が属するタイル・グループにおけるtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
・loop_filter_across_tiles_enabled_flagが0に等しく、位置(xSik',ySjk')のサンプルが別のタイルに属する。
【0295】
タイル・グループのないタイルが組み込まれる場合は、ハイライトされたセクションを修正する。
・それ以外の場合、edgeIdxは以下のように導出される：
・以下が適用される：
edgeIdx＝2＋Sign（recPicture[xSi][ySj]－recPicture[xSi＋hPos[0]][ySj＋vPos[0]]）＋
Sign（recPicture[xSi][ySj]－recPicture[xSi＋hPos[1]][ySj＋vPos[1]]） （8-1130）
・edgeIdxが0、1、または2に等しい場合、edgeIdxは以下のように修正される：
edgeIdx＝(edgeIdx==2)? 0 : (edgeIdx＋1) （8-1131）
・それ以外の場合、edgeIdxは以下のように導出される：
・以下が適用される：
edgeIdx＝2＋Sign（recPicture[xSi][ySj]－recPicture[xSi＋hPos[0]][ySj＋vPos[0]]）＋
Sign（recPicture[xSi][ySj]－recPicture[xSi＋hPos[1]][ySj＋vPos[1]]） （8-1130）
・edgeIdxが0、1、または2に等しい場合、edgeIdxは以下のように修正される：
edgeIdx＝(edgeIdx==2)? 0 : (edgeIdx＋1) （8-1131）
【0296】
3. 修正されたピクチャー・サンプル配列saoPicture[xSi][ySj]は、以下のように導出される。
【0297】
saoPicture[xSi][ySj]＝Clip3（0,(1<<bitDepth)－1,recPicture[xSi][ySj]＋
SaoOffsetVal[cIdx][rx][ry][edgeIdx]） （8-1132）
SaoOffsetVal[cIdx][rx][ry][edgeIdx]） （8-1132）
【0298】
ALFのためのルーマ・サンプルについてのコーディングツリー・ブロック・フィルタリング・プロセスが論じられる。
…
…
【0299】
フィルタリングされた再構成されたルーマ・サンプルalfPictureL[x][y]の導出のために、現在のルーマコーディングツリーブロックrecPictureL[x][y]内のそれぞれの再構成されたルーマ・サンプルは、x,y＝0..CtbSizeY－1として、以下のようにフィルタリングされる：
・…
・ルーマ・サンプルの所与の配列recPicture内の対応するルーマ・サンプル(x,y)のそれぞれについての位置(hx,vy)は以下のように導出される：
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary,rightBoundary,xCtb＋x） （8-1140）
v y ＝Clip3（topBoundary,botBoundary,yCtb＋y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples－1,xCtb＋x） （8-1140）
vy＝Clip3（0,pic_height_in_luma_samples－1,yCtb＋y） （8-1141）
・…
・…
・ルーマ・サンプルの所与の配列recPicture内の対応するルーマ・サンプル(x,y)のそれぞれについての位置(hx,vy)は以下のように導出される：
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary,rightBoundary,xCtb＋x） （8-1140）
v y ＝Clip3（topBoundary,botBoundary,yCtb＋y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples－1,xCtb＋x） （8-1140）
vy＝Clip3（0,pic_height_in_luma_samples－1,yCtb＋y） （8-1141）
・…
【0300】
ルーマ・サンプルについてのALF転置およびフィルタ・インデックスについての導出プロセスが論じられる。
…
…
【0301】
ルーマ・サンプルの所与の配列recPicture内の対応するルーマ・サンプル(x,y)のそれぞれについての位置(hx,vy)は以下のように導出される：
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary,rightBoundary,x） （8-1140）
v y ＝Clip3（topBoundary,botBoundary,y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples－1,x） （8-1145）
vy＝Clip3（0,pic_height_in_luma_samples－1,y） （8-1146）
クロマ・サンプルについてのコーディングツリー・ブロック・フィルタリング・プロセスが論じられる。
…
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary,rightBoundary,x） （8-1140）
v y ＝Clip3（topBoundary,botBoundary,y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples－1,x） （8-1145）
vy＝Clip3（0,pic_height_in_luma_samples－1,y） （8-1146）
クロマ・サンプルについてのコーディングツリー・ブロック・フィルタリング・プロセスが論じられる。
…
【0302】
フィルタリングされた再構成されたクロマ・サンプルalfPicture[x][y]の導出のために、現在のクロマコーディングツリーブロックrecPicture[x][y]内のそれぞれの再構成されたクロマ・サンプルは、x,y＝0..ctbSizeC－1として、以下のようにフィルタリングされる：
・クロマ・サンプルの所与の配列recPicture内の対応するクロマ・サンプル(x,y)のそれぞれについての位置(hx,vy)は以下のように導出される：
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary/SubWidthC,rightBoundary/SubWidthC,xCtbC＋x） （8-1140）
v y ＝Clip3（topBoundary/SubWidthC,botBoundary/SubWidthC,yCtbC＋y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples/SubWidthC－1,xCtb＋x） （8-1177）
vy＝Clip3（0,pic_height_in_luma_samples/SubHeightC－1,yCtb＋y） （8-1178）
・クロマ・サンプルの所与の配列recPicture内の対応するクロマ・サンプル(x,y)のそれぞれについての位置(hx,vy)は以下のように導出される：
・gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、位置(x,y)のルーマ・サンプルを含むタイル・グループtgAのrefreshed_region_flagが1に等しい場合、以下が適用される：
・位置(h x ,h y )が別のタイル・グループtgBに位置しており、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれTGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
・それ以外の場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれPicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
h x ＝Clip3（leftBoundary/SubWidthC,rightBoundary/SubWidthC,xCtbC＋x） （8-1140）
v y ＝Clip3（topBoundary/SubWidthC,botBoundary/SubWidthC,yCtbC＋y） （8-1141）
・それ以外の場合、以下が適用される：
hx＝Clip3（0,pic_width_in_luma_samples/SubWidthC－1,xCtb＋x） （8-1177）
vy＝Clip3（0,pic_height_in_luma_samples/SubHeightC－1,yCtb＋y） （8-1178）
【0303】
図7は、本開示のある実施形態による、漸進的デコード・リフレッシュ（GDR）技術700を実装するように構成されたビデオ・ビットストリーム750を示す。GDR技術700は、図5のGDR技術500と同様であってもよい。本明細書で使用されるところでは、ビデオ・ビットストリーム750は、コーディングされたビデオ・ビットストリーム、ビットストリーム、またはそれらの変形と称されてもよい。図7に示されるように、ビットストリーム750は、シーケンスパラメータセット（SPS）752、ピクチャーパラメータセット（PPS）754、スライス・ヘッダ756、および画像データ758を含む。
【0304】
SPS 752は、ピクチャーのシーケンス（sequence of pictures、SOP）におけるすべてのピクチャーに共通であるデータを含む。対照的に、PPS 754は、ピクチャー全体に共通するデータを含む。スライス・ヘッダ756は、たとえば、スライス型、参照ピクチャーのうちどれが使用されるかなど、現在のスライスに関する情報を含む。SPS 752およびPPS 754は、一般的に、パラメータセットと称されてもよい。SPS 752、PPS 754、およびスライス・ヘッダ756は、ネットワーク抽象化層（NAL）単位の型である。NAL単位は、従うべきデータの型（たとえば、コーディングされたビデオ・データ）の指示を含む構文構造である。NAL単位は、ビデオ・コーディング層（VCL）および非VCL NAL単位に分類される。VCL NAL単位は、ビデオ・ピクチャー内のサンプルの値を表すデータを含み、非VCL NAL単位は、パラメータセット（多数のVCL NAL単位に適用可能な重要なヘッダ・データ）および補足向上情報（デコードされたビデオ信号の有用性を高める可能性があるが、タイミング情報およびビデオ・ピクチャー内のサンプルの値をデコードするために必要ではないその他の補足データ）のような、任意の関連する追加的な情報を含む。当業者は、ビットストリーム750は、実際の応用では他のパラメータおよび情報を含んでいてもよいことを理解するであろう。
【0305】
図7の画像データ758は、エンコードまたはデコードされる画像またはビデオに関連するデータを含む。画像データ758は、単に、ビットストリーム750内で搬送されるペイロードまたはデータと称されてもよい。ある実施形態では、画像データ758は、GDRピクチャー702、一つまたは複数の後続ピクチャー704、および回復点ピクチャー706を含むCVS 708を含む。ある実施形態では、GDRピクチャー702、後続ピクチャー704、および回復点ピクチャー706は、CVS 708内のGDR期間を画定してもよい。
【0306】
図7に示されるように、GDR技術700または原理は、GDRピクチャー702で始まり回復点ピクチャー706で終わる一連のピクチャーに対して動作する。GDRピクチャー702は、すべてイントラ予測を使用してコーディングされたブロック（すなわち、イントラ予測されたブロック）を含むリフレッシュ／クリーン領域710と、すべてインター予測を使用してコーディングされたブロック（すなわち、インター予測されたブロック）を含む未リフレッシュ／ダーティー領域712とを含む。
【0307】
GDRピクチャー702にすぐ隣接する後続ピクチャー704は、イントラ予測を用いてコーディングされた第1の部分710Aと、インター予測を用いてコーディングされた第2の部分710Bとを有するリフレッシュ／クリーン領域710を含む。第2の部分710Bは、たとえば、CVS 708のGDR期間内の先行するピクチャーのリフレッシュ／クリーン領域710を参照することによってコーディングされる。図のように、後続ピクチャー704のリフレッシュ／クリーン領域710は、コーディング・プロセスが一貫した方向に（たとえば、左から右へ）移動または進行するにつれて拡大し、これに対応して、未リフレッシュ／ダーティー領域712を収縮させる。最終的に、リフレッシュ／クリーン領域710のみを含む回復点ピクチャー706が、コーディング・プロセスから得られる。インター予測ブロックとしてコーディングされるリフレッシュ／クリーン領域710の第2の部分710Bは、参照ピクチャーにおけるリフレッシュ領域／クリーン領域710を参照するだけでもよい。
【0308】
図7に示されるように、CVS 708内のGDRピクチャー702、後続ピクチャー704、および回復点ピクチャー706は、それぞれ、自分自身のVCL NAL単位730内に含まれる。CVS 708内のVCL NAL単位730の集合は、アクセス単位と称されてもよい。
【0309】
CVS 708内のGDRピクチャー702を含むNAL単位730は、GDR NAL単位型（GDR_NUT）を有する。すなわち、ある実施形態では、CVS 708内のGDRピクチャー702を含むNAL単位730は、後続ピクチャー704および回復点ピクチャー706に対して自分自身の独特なNAL単位型を有する。ある実施形態では、GDR_NUTは、ビットストリームがIRAPピクチャーで始まる必要があるのではなく、ビットストリームがGDRピクチャー702で始まることを許容する。GDRピクチャー702のVCL NAL単位730をGDR_NUTとして指定することは、CVS 708における最初のVCL NAL単位730がGDRピクチャー702を含むことを、たとえばデコーダに示すことができる。
【0310】
ある実施形態では、GDRピクチャー702は、CVS 708における最初のピクチャーである。ある実施形態では、GDRピクチャー702は、GDR期間における最初のピクチャーである。ある実施形態では、GDRピクチャー702は、ゼロに等しい時間的識別子（ID）を有する。時間的IDは、他のピクチャーに対するピクチャーの位置または順序を識別する値または番号である。ある実施形態では、GDR_NUTを有するVCL NAL単位730を含むアクセス単位は、GDRアクセス単位と指定される。ある実施形態では、GDRピクチャー702は、別の（たとえば、より大きな）GDRピクチャーのコード・スライスである。すなわち、GDRピクチャー702は、より大きなGDRピクチャーの一部であってもよい。
【0311】
図8は、ビデオ・デコーダ（たとえば、ビデオ・デコーダ30）によって実装される、コーディングされたビデオ・ビットストリームをデコードする方法800の実施形態である。方法800は、デコードされたビットストリームがビデオ・エンコーダ（たとえば、ビデオ・エンコーダ20）から直接的または間接的に受領された後に実行されてもよい。この方法はIRAPピクチャーを使用する必要なくランダム・アクセスを可能にするために、漸進的なイントラリフレッシュを許容するので、方法800はデコード・プロセスを改善する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、従って、実用的な問題として、コーデックのパフォーマンスが改善され、それはより良いユーザー体験につながる。
【0312】
ブロック802では、ビデオ・デコーダは、コーディングされたビデオ・ビットストリームのコーディングされたビデオ・シーケンス（coded video sequence、CVS）が、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位を含むことを判別する。前記GDR_NUTを有する前記VCL NAL単位はGDRピクチャーを含む。
【0313】
ある実施形態では、GDRピクチャーは、CVSにおける最初のピクチャーである。ある実施形態では、GDRピクチャーは、GDR期間における最初のピクチャーである。ある実施形態では、GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する。ゼロの時間的IDは、GDRピクチャーが、たとえばCVSまたはGDR期間における最初のピクチャーであることを示しうる。ある実施形態では、GDR_NUTを有するVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される。ある実施形態では、GDRピクチャーは、別のGDRピクチャーのコーディングされたスライスである。
【0314】
ブロック804では、ビデオ・デコーダは、GDRピクチャーにおいてCVSのデコードを開始する。
【0315】
ブロック806では、ビデオ・デコーダは、デコードされたCVSに従って画像を生成する。該画像は、次いで、電子装置（たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど）のユーザーのために表示されてもよい。
【0316】
図9は、ビデオ・エンコーダ（たとえば、ビデオ・エンコーダ20）によって実装される、ビデオ・ビットストリームをエンコードする方法900のある実施形態である。方法900は、ピクチャー（たとえば、ビデオからの）がビデオ・ビットストリームにエンコードされ、次いでビデオ・デコーダ（たとえば、ビデオ・デコーダ30）に向けて伝送されるときに実行されてもよい。方法900は、IRAPピクチャーを使用する必要なくランダム・アクセスを可能にするために、プログレッシブ・イントラ・リフレッシュを許容するので、エンコード・プロセスを改善する。IRAPピクチャーの代わりにGDRピクチャーを使用することによって、たとえば、IRAPピクチャーのサイズに比したGDRピクチャーのサイズのため、よりなめらかで、より一貫性のあるビットレートが達成されてもよく、これは、短縮されたエンドツーエンドの遅延（すなわち、レイテンシー）を許容する。よって、従って、実用的な問題として、コーデックのパフォーマンスが改善され、それはより良いユーザー体験につながる。
【0317】
ブロック902では、ビデオ・エンコーダは、ビデオ・シーケンスについてのランダム・アクセス・ポイントを決定する。ブロック904では、ビデオ・エンコーダは、ビデオ・シーケンスについての前記ランダム・アクセス・ポイントにおいて、漸進的デコード・リフレッシュ（GDR）ピクチャーを、漸進的デコード・リフレッシュ（gradual decoding refresh、GDR）ネットワーク抽象化層（network abstraction layer、NAL）単位型（GDR_NUT）を有するビデオ・コーディング層（video coding layer、VCL）ネットワーク抽象化層（NAL）単位にエンコードする。
【0318】
ある実施形態では、GDRピクチャーは、CVSにおける最初のピクチャーである。ある実施形態では、GDRピクチャーは、GDR期間における最初のピクチャーである。ある実施形態では、GDRピクチャーは、ゼロに等しい時間的識別子（ID）を有する。ゼロの時間的IDは、GDRピクチャーが、たとえばCVSまたはGDR期間における最初のピクチャーであることを示しうる。ある実施形態では、GDR_NUTを有するVCL NAL単位を含むアクセス単位は、GDRアクセス単位と指定される。ある実施形態では、GDRピクチャーは、別のGDRピクチャーのコーディングされたスライスである。
【0319】
ブロック906では、ビデオ・エンコーダは、前記ランダム・アクセス・ポイントにおいて前記GDR_NUTをもつ前記VCL NAL単位において前記GDRピクチャーを有する前記ビデオ・シーケンスを含むビットストリームを生成する。
【0320】
ブロック908では、ビットストリームはビデオ・デコーダに向けた伝送のために記憶される。ビデオ・ビットストリームは、コーディングされたビデオ・ビットストリームまたはエンコードされたビデオ・ビットストリームとも呼ばれる。ビデオ・エンコーダは、ビットストリームをビデオ・デコーダに向けて伝送することができる。ひとたびビデオ・デコーダによって受信されると、エンコードされたビデオ・ビットストリームは、（たとえば上述したように）デコードされて、電子装置（たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど）のディスプレイまたは画面上でユーザーに対して表示するための画像を生成するまたは発生させることができる。
【0321】
図10は、本開示のある実施形態によるビデオ・コーディング装置1000（たとえば、ビデオ・エンコーダ20またはビデオ・デコーダ30）の概略図である。ビデオ・コーディング装置1000は、本明細書に記載されるような開示される実施形態を実装するのに好適である。ビデオ・コーディング装置1000は、データを受信するための入口ポート1010および受信器ユニット（Rx）1020と、該データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット（CPU）1030と、該データを送信するための送信器ユニット（Tx）1040および出口ポート1050と、該データを記憶するためのメモリ1060とを有する。ビデオ・コーディング装置1000は、光信号または電気信号の出入りのために、入口ポート1010、受信器ユニット1020、送信器ユニット1040、および出口ポート1050に結合された光対電気（optical-to-electrical、OE）コンポーネントおよび電気対光（electrical-to-optical、EO）コンポーネントをも有していてもよい。
【0322】
プロセッサ1030は、ハードウェアおよびソフトウェアによって実装される。プロセッサ1030は、一つまたは複数のCPUチップ、コア（たとえばマルチコアプロセッサ）、フィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）、およびデジタル信号プロセッサ（DSP）として実装されてもよい。プロセッサ1030は、入口ポート1010、受信器ユニット1020、送信器ユニット1040、出口ポート1050、およびメモリ1060と通信する。プロセッサ1030は、コーディングモジュール1070を有する。コーディングモジュール1070は、上述の開示された実施形態を実装する。たとえば、コーディングモジュール1070は、さまざまなコーデック機能を実装し、処理し、準備し、または提供する。よって、コーディングモジュール1070を含めることにより、ビデオ・コーディング装置1000の機能が実質的に改善され、ビデオ・コーディング装置1000が異なる状態への変換が実施される。あるいはまた、コーディングモジュール1070は、メモリ1060に格納された記憶され、プロセッサ1030によって実行される命令として実装される。
【0323】
ビデオ・コーディング装置1000はまた、ユーザーとの間でデータを通信するための入力および／または出力（I/O）装置1080を含んでいてもよい。I/O装置1080は、ビデオ・データを表示するためのディスプレイ、オーディオ・データを出力するためのスピーカーなどの出力装置を含んでいてもよい。I/O装置1080はまた、キーボード、マウス、トラックボールなどの入力装置、および／またはそのような出力装置と対話するための対応するインターフェースを含んでいてもよい。
【0324】
メモリ1060は、一つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを含み、オーバーフローデータ記憶装置として、プログラムが実行のために選択されたときにプログラムを記憶するため、そしてプログラムの実行中に読み出された命令およびデータを記憶するために使用されてもよい。メモリ1060は、揮発性および／または不揮発性であってもよく、リードオンリーメモリ（ROM）、ランダム・アクセス・メモリ（RAM）、三値連想記憶メモリ（TCAM）、および／または静的ランダム・アクセス・メモリ（SRAM）であってもよい。
【0325】
図11は、コーディング手段1100のある実施形態の概略図である。ある実施形態では、コーディング手段1100は、ビデオ・コーディング装置1102（たとえば、ビデオ・エンコーダ20またはビデオ・デコーダ30）において実装される。ビデオ・コーディング装置1102は、受信手段1101を含む。受信手段1101は、エンコードするピクチャーを受信するか、またはデコードするビットストリームを受信するように構成される。ビデオ・コーディング装置1102は、受信手段1101に結合された送信手段1107を含む。送信手段1107は、ビットストリームをデコーダに送信するか、またはデコードされたピクチャーを表示手段（たとえば、I/O装置1080のうちの1つ）に送信するように構成される。
【0326】
ビデオ・コーディング装置1102は、記憶手段1103を含む。記憶手段1103は、受信手段1101または送信手段1107のうちの少なくとも1つに結合される。記憶手段1103は、命令を記憶するように構成される。また、ビデオ・コーディング装置1102は、処理手段1105をも含む。処理手段1105は、記憶手段1103に結合される。処理手段1105は、本明細書に開示される方法を実行するために、記憶手段1103に記憶された命令を実行するように構成される。また、本明細書に記載された例示的な方法のステップは、必ずしも記載された順序で実行される必要はなく、そのような方法のステップの順序は、単に例示的なものであると理解されるべきである。同様に、追加的なステップが、そのような方法に含まれてもよく、ある種のステップは、本開示のさまざまな実施形態と整合する方法において省略されたり、または組み合わされたりしてもよい。
【0327】
本開示においていくつかの実施形態が提供されたが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の特定の形で具現されうることが理解されるべきである。本願の例は、制約するものではなく、例解するものと考えられるべきであり、その意図は、本明細書に与えられた詳細に限定されるものではない。たとえば、さまざまな要素またはコンポーネントが別のシステムに組み合わされ、または統合されてもよく、あるいはある種の特徴が省略されたり、または実装されなかったりしてもよい。
【0328】
さらに、さまざまな実施形態において離散的なまたは別個なものとして記載および図示された技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされたり、あるいは統合されたりしてもよい。互いに結合される、または直接結合される、または互いと通信するものとして示されるまたは論じられる他の項目が、電気的に、機械的に、または他の仕方で、何らかのインターフェース、装置、または中間コンポーネントを通じて間接的に結合され、または通信してもよい。変更、置換、および改変の他の例は、当業者には見きわめることができ、本明細書に開示された精神および範囲から逸脱することなく行うことができる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】