特許7443398 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ ホアウェイ・テクノロジーズ・カンパニー・リミテッドの特許一覧

特許7443398漸次復号リフレッシュのための仮想参照デコーダ

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12

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

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

(11)【特許番号】

(24)【登録日】2024-02-26

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

(54)【発明の名称】漸次復号リフレッシュのための仮想参照デコーダ

(51)【国際特許分類】

H04N 19/70 20140101AFI20240227BHJP

【ＦＩ】

H04N19/70

【請求項の数】 22

(21)【出願番号】P 2021566076

(86)(22)【出願日】2020-04-30

(65)【公表番号】

(43)【公表日】2022-07-06

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

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

(87)【国際公開日】2020-11-12

【審査請求日】2021-12-15

(31)【優先権主張番号】62/843,999

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

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

(73)【特許権者】

【識別番号】504161984

【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】イェ－クイ・ワン

【審査官】鉢呂健

(56)【参考文献】

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

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

【文献】SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services - Coding of moving video，Recommendation ITU-T H.265 (02/2018) High efficiency video coding，ITU-T，2018年05月11日，p.290，＜URL:https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.265-201802-S!!PDF-E&type=items＞

【文献】Hendry et al.，AHG14/AHG17: GDR - Gradual decoding refresh，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 14th Meeting: Geneva, CH, 19-27 March 2019, [JVET-N0115-v1]，JVET-N0115 (version 1)，ITU-T，2019年03月12日，＜URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/14_Geneva/wg11/JVET-N0115-v1.zip＞: JVET-N0115-v1.docx: pp.1-5, JVET-N0115-v1_SpecText.docx: pp.35-38

【文献】WANG, Ye-Kui et al.，AHG17: HRD support for GRA and changing the term GRA to GDR，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 15th Meeting: Gothenburg, SE, 3-12 July 2019, [JVET-O0152-v1]，JVET-O0152 (version 1)，ITU-T，2019年06月20日，＜URL:https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0152-v1.zip＞: JVET-O0152-v1.docx: pp.1-4

【文献】WANG, Ye-Kui et al.，AHG17: On no_output_of_prior_pics_flag，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 15th Meeting: Gothenburg, SE, 3-12 July 2019, [JVET-O0151-v1]，JVET-O0151 (version 1)，ITU-T，2019年06月20日，＜URL:https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0151-v1.zip＞: JVET-O0151-v1.docx: pp.1-3

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

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

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

【請求項1】

デコーダにおいて実施される方法であって、
漸次復号リフレッシュ(GDR)アクセスユニット(AU)および前記GDR AUに関連するバッファリング期間(BP)補足拡張情報(SEI)メッセージを含むビットストリームを前記デコーダの受信機によって受信するステップと、
前記GDR AU内の符号化ピクチャおよび前記BP SEIメッセージを前記デコーダのプロセッサによって復号するステップとを含み、
前記ピクチャがGDRピクチャであるとき、前記GDR AU内の前記ピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグが設定される方法。

【請求項2】

前記BP SEIメッセージが、復号順で前記GDR AUの位置における仮想参照デコーダ(HRD)の初期化のための初期コーディングされたピクチャバッファ(CPB)削除遅延を提供する請求項1に記載の方法。

【請求項3】

前記ビットストリームが、前記ピクチャに関連するヘッダを含み、前記ヘッダが、ピクチャ順序カウント最下位ビット値およびリカバリピクチャ順序カウント値を含む請求項1または2に記載の方法。

【請求項4】

前記ピクチャ順序カウント最下位ビット値が、前記ピクチャに関連する前記ヘッダ内で前記リカバリピクチャ順序カウント値の前に配置される請求項3に記載の方法。

【請求項5】

前記BP SEIメッセージが、前記デコーダが前記ビットストリームを復号することができることを示すHRDパラメータを含む請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記ピクチャがインター予測によってコーディングされた領域およびイントラ予測によってコーディングされた領域を含むとき、前記ピクチャがGDRピクチャである請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記BP SEIメッセージに基づいて仮想参照デコーダ(HRD)を前記プロセッサによって初期化するステップと、
前記HRDを使用して前記ビットストリームに対して準拠のテストを前記プロセッサによって実行するステップとを含む請求項1から6のいずれか一項に記載の方法。

【請求項8】

エンコーダにおいて実施される方法であって、
漸次復号リフレッシュ(GDR)アクセスユニット(AU)および前記GDR AUに関連するバッファリング期間(BP)補足拡張情報(SEI)メッセージを前記エンコーダのプロセッサによってビットストリームに符号化するステップと、
ピクチャがGDRピクチャであるとき、前記GDR AU内の前記ピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグを設定するステップとを含む、方法。

【請求項9】

前記BP SEIメッセージに基づいて仮想参照デコーダ(HRD)を前記プロセッサによって初期化するステップと、
前記HRDを使用して前記ビットストリームに対して準拠のテストを前記プロセッサによって実行するステップとを含む請求項8に記載の方法。

【請求項10】

前記BP SEIメッセージが、復号順で前記GDR AUの位置における前記HRDの初期化のための初期コーディングされたピクチャバッファ(CPB)削除遅延を含む請求項9に記載の方法。

【請求項11】

前記ピクチャに関連するヘッダを前記ビットストリームに符号化するステップであって、前記ヘッダが、ピクチャ順序カウント最下位ビット値およびリカバリピクチャ順序カウント値を含む、ステップをさらに含む請求項8から10のいずれか一項に記載の方法。

【請求項12】

前記ピクチャ順序カウント最下位ビット値が、前記ピクチャに関連する前記ヘッダ内で前記リカバリピクチャ順序カウント値の前に配置される請求項11に記載の方法。

【請求項13】

前記BP SEIメッセージが、デコーダが前記ビットストリームを復号することができることを示すHRDパラメータを含む請求項8から12のいずれか一項に記載の方法。

【請求項14】

前記ピクチャがインター予測によってコーディングされた領域およびイントラ予測によってコーディングされた領域を含むとき、前記ピクチャがGDRピクチャである請求項8から13のいずれか一項に記載の方法。

【請求項15】

プロセッサと、前記プロセッサに結合された受信機と、前記プロセッサに結合されたメモリと、前記プロセッサに結合された送信機とを含み、前記プロセッサ、前記受信機、前記メモリ、および前記送信機は、請求項1から7のいずれか一項に記載の方法を実行するように構成されるビデオコーディングデバイス。

【請求項16】

プロセッサと、前記プロセッサに結合された受信機と、前記プロセッサに結合されたメモリと、前記プロセッサに結合された送信機とを含み、前記プロセッサ、前記受信機、前記メモリ、および前記送信機は、請求項8から14のいずれか一項に記載の方法を実行するように構成されるビデオコーディングデバイス。

【請求項17】

ビデオコーディングデバイスによって使用するためのコンピュータプログラムを含む非一時的コンピュータ可読媒体であって、前記コンピュータプログラムは、プロセッサによって実行されるときに前記ビデオコーディングデバイスに請求項1から7のいずれか一項に記載の方法を実行させる、前記非一時的コンピュータ可読媒体に記憶されたコンピュータが実行可能な命令を含む、非一時的コンピュータ可読媒体。

【請求項18】

ビデオコーディングデバイスによって使用するためのコンピュータプログラムを含む非一時的コンピュータ可読媒体であって、前記コンピュータプログラムは、プロセッサによって実行されるときに前記ビデオコーディングデバイスに請求項8から14のいずれか一項に記載の方法を実行させる、前記非一時的コンピュータ可読媒体に記憶されたコンピュータが実行可能な命令を含む、非一時的コンピュータ可読媒体。

【請求項19】

漸次復号リフレッシュ(GDR)アクセスユニット(AU)および前記GDR AUに関連するバッファリング期間(BP)補足拡張情報(SEI)メッセージを含むビットストリームを受信するための受信手段と、
前記GDR AU内のピクチャおよび前記BP SEIメッセージを復号するための復号手段と、
復号されたビデオシーケンスの一部として表示するために前記ピクチャを転送するための転送手段とを含み、
前記ピクチャがGDRピクチャであるとき、前記GDR AU内の前記ピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグが設定されるデコーダ。

【請求項20】

請求項1から7のいずれか一項に記載の方法を実行するようにさらに構成される請求項19に記載のデコーダ。

【請求項21】

漸次復号リフレッシュ(GDR)アクセスユニット(AU)および前記GDR AUに関連するバッファリング期間(BP)補足拡張情報(SEI)メッセージをビットストリームに符号化し、ピクチャがGDRピクチャであるとき、前記GDR AU内の前記ピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグを設定するための符号化手段と、
前記BP SEIメッセージに基づいて仮想参照デコーダ(HRD)を初期化するための初期化手段と、
前記HRDを使用して前記ビットストリームに対して準拠のテストを実行するためのHRD手段と、
デコーダに伝達するために前記ビットストリームを記憶するための記憶手段とを含むエンコーダ。

【請求項22】

請求項8から14のいずれか一項に記載の方法を実行するようにさらに構成される請求項21に記載のエンコーダ。

【発明の詳細な説明】

【技術分野】

【0002】

本開示は、概して、ビデオコーディングに関し、特に、ビデオコーディングにおいて仮想参照デコーダが漸次復号リフレッシュをサポートすることを可能にするための改良に関する。

【背景技術】

【0003】

比較的短いビデオでさえも描くために必要とされるビデオデータの量はかなり多くなり得、それが、データが限られた帯域幅の容量を有する通信ネットワークを介してストリーミングされるかまたはそれ以外の方法で伝達されるべきであるときに困難をもたらし得る。したがって、ビデオデータは、概して、現代の電気通信ネットワークを介して伝達される前に圧縮される。メモリリソースが限られている可能性があるので、ビデオがストレージデバイスに記憶されるとき、ビデオのサイズも問題となり得る。多くの場合、ビデオ圧縮デバイスは、送信元においてソフトウェアおよび/またはハードウェアを使用して送信または記憶の前にビデオデータをコーディングし、それによって、デジタルビデオ画像を表現するために必要とされるデータの量を削減する。次いで、圧縮されたデータが、ビデオデータを復号するビデオ解凍デバイスによって送信先において受信される。限られたネットワークリソースおよびより高いビデオ品質のますます増加する需要によって、画像品質をほとんどまたはまったく犠牲にせずに圧縮比を高める改善された圧縮および解凍技術が、望ましい。

【発明の概要】

【課題を解決するための手段】

【0004】

実施形態において、本開示は、デコーダにおいて実施される方法であって、漸次復号リフレッシュ(GDR)アクセスユニット(AU: access unit)およびGDR AUに関連するバッファリング期間(BP)補足拡張情報(SEI: supplemental enhancement information)メッセージを含むビットストリームをデコーダの受信機によって受信するステップと、GDR AU内のピクチャおよびBP SEIメッセージをデコーダのプロセッサによって復号するステップと、復号されたビデオシーケンスの一部として表示するためにピクチャをプロセッサによって転送するステップとを含む、方法を含む。

【0005】

仮想参照デコーダ(HRD)は、エンコーダ上で動作する構成要素である。HRDは、符号化されたビットストリームを規格への準拠に関して調べる。たとえば、HRDは、デコーダがビットストリームを復号することができるはずであることを検証するためにビットストリームを調べることができる。GDRは、ビットストリームをコーディングするためのメカニズムである。GDRピクチャは、イントラ予測コーディングされたビデオデータの垂直な領域およびインター予測コーディングされたビデオデータの1つ以上の垂直な領域を含む。イントラ予測コーディングされた領域の位置は、一連の関連するピクチャで移動し、クリーン(clean)領域を生成する。クリーン領域を含むピクチャは、イントラ予測データまたは別のピクチャのクリーン領域を参照するインター予測データのみを使用してそのようなクリーン領域をコーディングする。結果として、デコーダは、最初のGDRピクチャにおいてビットストリームの復号を開始し、各ピクチャを順序通りに復号することができる。リカバリポイント(recovery point)の前の最後のピクチャが到達されると、デコーダは、同期され、クリーンな使用可能なデータに基づいてインター予測を使用することによって任意のさらなるピクチャを復号することができる。エンコーダのHRDは、イントラ予測データのみを含むイントラランダムアクセスポイント(IRAP)ピクチャに基づいて、準拠に関してビットストリームを調べるように構成され得る。HRDは、インター予測データのみを含むインター予測されたピクチャに基づいて準拠に関してビットストリームを調べるようにも構成され得る。しかし、HRDは、GDRにおいて行われるようにイントラ予測とインター予測との両方が同じピクチャ内で使用されるときに準拠に関してビットストリームを調べるように構成されない可能性がある。この例は、ビットストリームがGDRを含むときに準拠に関してビットストリームを調べるようにHRDを構成するためのメカニズムを含む。GDRピクチャがビットストリームに含まれるとき、エンコーダは、HRDパラメータを含むBP SEIメッセージを含めることができる。HRDは、そのようなメッセージを使用して、準拠に関してビットストリームを調べることを開始することができる。さらに、デコーダが、ビットストリー
ムが準拠しており、したがって、復号可能であることを検証するためにそのようなメッセージを調べることができる。したがって、GDRピクチャに関してBP SEIメッセージを含めることは、エンコーダとデコーダとの両方において追加的な機能をサポートする。さらに、GDRは、ネットワーク通信中の帯域幅の瞬間的な上昇の削減をサポートし得る。したがって、ここで開示されているメカニズムは、エンコーダとデコーダとの両方においてプロセッサ、メモリ、および/またはネットワークリソースの使用を削減し得る。

【0006】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、BP SEIメッセージが、復号順でGDR AUの位置におけるHRDの初期化のための初期コーディングされたピクチャバッファ(CPB: coded picture buffer)削除遅延を提供すると規定する。

【0007】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ピクチャがGDRピクチャであるとき、GDR AU内のピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグ(no output of prior pictures flag)が設定されると規定する。

【0008】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ビットストリームがピクチャに関連するヘッダを含み、ヘッダがピクチャ順序カウント(picture order count)最下位ビット値およびリカバリピクチャ順序カウント値を含むと規定する。

【0009】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ピクチャ順序カウント最下位ビット値がピクチャに関連するヘッダ内でリカバリピクチャ順序カウント値の前に配置されると規定する。

【0010】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、BP SEIメッセージが、デコーダがビットストリームを復号することができることを示すHRDパラメータを含むと規定する。

【0011】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ピクチャがインター予測によってコーディングされた領域およびイントラ予測によってコーディングされた領域を含むとき、ピクチャがGDRピクチャであると規定する。

【0012】

実施形態において、本開示は、エンコーダにおいて実施される方法であって、GDR AUおよびGDR AUに関連するBP SEIメッセージをエンコーダのプロセッサによってビットストリームに符号化するステップと、BP SEIメッセージに基づいてHRDをプロセッサによって初期化するステップと、HRDを使用してビットストリームに対してHRDの準拠のテストをプロセッサによって実行するステップと、デコーダに伝達するためにビットストリームをプロセッサに結合されたメモリによって記憶するステップとを含む、方法を含む。

【0013】

仮想参照デコーダ(HRD)は、エンコーダ上で動作する構成要素である。HRDは、符号化されたビットストリームを規格への準拠に関して調べる。たとえば、HRDは、デコーダがビットストリームを復号することができるはずであることを検証するためにビットストリームを調べることができる。GDRは、ビットストリームをコーディングするためのメカニズムである。GDRピクチャは、イントラ予測コーディングされたビデオデータの垂直な領域およびインター予測コーディングされたビデオデータの1つ以上の垂直な領域を含む。イントラ予測コーディングされた領域の位置は、一連の関連するピクチャで移動し、クリーン領域を生成する。クリーン領域を含むピクチャは、イントラ予測データまたは別のピクチャのクリーン領域を参照するインター予測データのみを使用してそのようなクリーン領域をコーディングする。結果として、デコーダは、最初のGDRピクチャにおいてビットストリームの復号を開始し、各ピクチャを順序通りに復号することができる。リカバリポイントの前の最後のピクチャが到達されると、デコーダは、同期され、クリーンな使用可能なデータに基づいてインター予測を使用することによって任意のさらなるピクチャを復号することができる。エンコーダのHRDは、イントラ予測データのみを含むIRAPピクチャに基づいて、準拠に関してビットストリームを調べるように構成され得る。HRDは、インター予測データのみを含むインター予測されたピクチャに基づいて準拠に関してビットストリームを調べるようにも構成され得る。しかし、GDRにおいて行われるようにイントラ予測とインター予測との両方が同じピクチャ内で使用されるときに準拠に関してビットストリームを調べるように構成されない可能性がある。この例は、ビットストリームがGDRを含むときに準拠に関してビットストリームを調べるようにHRDを構成するためのメカニズムを含む。GDRピクチャがビットストリームに含まれるとき、エンコーダは、HRDパラメータを含むBP SEIメッセージを含めることができる。HRDは、そのようなメッセージを使用して、準拠に関してビットストリームを調べることを開始することができる。さらに、デコーダが、ビットストリームが準拠しており、したがって、復号可能であることを検証するためにそのようなメッセージを調べる
ことができる。したがって、GDRピクチャに関してBP SEIメッセージを含めることは、エンコーダとデコーダとの両方において追加的な機能をサポートする。さらに、GDRは、ネットワーク通信中の帯域幅の瞬間的な上昇の削減をサポートし得る。したがって、ここで開示されているメカニズムは、エンコーダとデコーダとの両方においてプロセッサ、メモリ、および/またはネットワークリソースの使用を削減し得る。

【0014】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、BP SEIメッセージが、復号順でGDR AUの位置におけるHRDの初期化のための初期CPB削除遅延を含むと規定する。

【0015】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ピクチャがGDRピクチャであるとき、GDR AU内のピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグを設定するステップをさらに含む。

【0016】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、ピクチャに関連するヘッダをビットストリームに符号化するステップであって、ヘッダが、ピクチャ順序カウント最下位ビット値およびリカバリピクチャ順序カウント値を含む、ステップをさらに含む。

【0017】

【0018】

【0019】

【0020】

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

【0021】

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

【0022】

実施形態において、本開示は、GDR AUおよびGDR AUに関連するBP SEIメッセージを含むビットストリームを受信するための受信手段と、GDR AU内のピクチャおよびBP SEIメッセージを復号するための復号手段と、復号されたビデオシーケンスの一部として表示するためにピクチャを転送するための転送手段とを含むデコーダを含む。

【0023】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、デコーダが上記態様のいずれかの方法を実行するようにさらに構成されると規定する。

【0024】

実施形態において、本開示は、GDR AUおよびGDR AUに関連するBP SEIメッセージをビットストリームに符号化するための符号化手段と、BP SEIメッセージに基づいてHRDを初期化するための初期化手段と、HRDを使用してビットストリームに対してHRDの準拠のテストを実行するためのHRD手段と、デコーダに伝達するためにビットストリームを記憶するための記憶手段とを含むエンコーダを含む。

【0025】

任意選択で、上記態様のうちのいずれかにおいて、態様の別の実装は、エンコーダが上記態様のいずれかの方法を実行するようにさらに構成されると規定する。

【0026】

明瞭にする目的で、上述の実施形態の任意の1つが、本開示の範囲内の新しい実施形態を生成するためにその他の上述の実施形態のうちの任意の1つ以上と組み合わされる可能性がある。

【0027】

これらのおよびその他の特徴は、以下の詳細な説明を添付の図面および請求項と併せて理解することによってより明瞭に理解されるであろう。

【0028】

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

【図面の簡単な説明】

【0029】

【図1】ビデオ信号をコーディングする例示的な方法の流れ図である。

【図2】ビデオコーディングのための例示的なコーディングおよびデコーディング(コーデック)システムの概略図である。

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

【図4】例示的なビデオデコーダを示す概略図である。

【図5】例示的な仮想参照デコーダ(HRD)を示す概略図である。

【図6】ビデオシーケンスに対して漸次復号リフレッシュ(GDR)を実行するための例示的なメカニズムを示す概略図である。

【図7】望ましくない動き探索を示す概略図である。

【図8】GDRが使用されるときにHRDを初期化する際に使用するための例示的なビットストリームを示す概略図である。

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

【図10】HRDを初期化しながら、GDRを使用するビデオシーケンスをビットストリームに符号化する例示的な方法の流れ図である。

【図11】HRDがビットストリームが準拠するビットストリームであることを示したときにビットストリームからGDRを使用するビデオシーケンスを復号する例示的な方法の流れ図である。

【図12】HRDを使用しながら、GDRを使用するビデオシーケンスをビットストリームにコーディングするための例示的なシステムの概略図である。

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

【0030】

1つ以上の実施形態の例示的な実装が以下で与えられるが、開示されるシステムおよび/または方法は、現在知られているのかまたは存在しているのかにかかわらず任意の数の技術を使用して実装される可能性があることを最初に理解されたい。本開示は、本明細書において例示され、説明される例示的な設計および実装を含む、以下で示される例示的な実装、図面、および技術にまったく限定されるべきでなく、添付の請求項の均等物の全範囲と併せたそれらの請求項の範囲内で修正され得る。

【0031】

本明細書において相容れない文脈で使用されない限り、以下の用語が、以下の通りに定義される。特に、以下の定義は、本開示をさらに明瞭にするように意図される。しかし、用語は、異なる文脈において異なるように説明される可能性がある。したがって、以下の定義は、補足と考えられるべきであり、本明細書においてそのような用語に関して与えられる説明のいかなるその他の定義も限定するものと考えられるべきでない。

【0032】

ビットストリームは、エンコーダとデコーダとの間の送信のために圧縮されるビデオデータを含むビットのシーケンスである。エンコーダは、符号化プロセスを使用してビデオデータをビットストリームへと圧縮するように構成されるデバイスである。デコーダは、復号プロセスを使用して表示のためにビットストリームからビデオデータを再構築するように構成されるデバイスである。ピクチャは、ビデオシーケンス内の対応する瞬間におけるユーザに対する完全なまたは部分的な表示を目的とする完全な画像である。ピクチャは、スライスに区分けされてもよく、スライスは、任意選択で、タイルに区分けされてもよく、スライスおよび/またはタイルは、コーディングツリーユニット(CTU: coding tree unit)および/またはコーディングツリーブロック(CTB: coding tree block)に区分けされてもよく、CTU/CTBは、予測メカニズムによってコーディングされ得るコーディングブロック(coding block)に区分けされてもよい。アクセスユニット(AU)は、単一のコーディングされたピクチャと、任意選択で、コーディングされたピクチャをコーディングするために使用されたコーディングメカニズムを示すパラメータを含む1つ以上のヘッダとを記憶するように構成されたコーディングユニット(coding unit)である。ヘッダは、コーディングされたビデオデータの対応する部分に当てはまるシンタックス要素を含むシンタックス構造である。ヘッダは、ピクチャヘッダおよびスライスヘッダを含み得る。ピクチャヘッダは、コーディングされたピクチャのすべてのスライスに当てはまるシンタックス要素を含むシンタックス構造である。スライスヘッダは、スライスに表されるすべてのタイルまたはタイル内のCTUの行に関連するデータ要素を含むコーディングされたスライスの部分である。インターコーディングとしても知られるインター予測は、現在のピクチャとは異なる参照ピクチャ内の参照ブロック内の対応するサンプルを参照することによって現在のピクチャ内の現在のブロックのサンプルをコーディングするメカニズムである。イントラコーディングとしても知られるイントラ予測は、現在のピクチャ内の参照ブロック内の対応するサンプルを参照することによって現在のピクチャ内の現在のブロックのサ
ンプルをコーディングするメカニズムである(つまり、現在のブロックおよび参照ブロックは同じピクチャ内にある)。GDRは、完全にイントラコーディングされる単一のピクチャによってコーディングされたビデオシーケンス(coded video sequence)を初期化することを避けるためにインターコーディングされる領域とイントラコーディングされる領域との両方をそれぞれが含むピクチャの系列をコーディングするメカニズムである。GDR AUは、GDRに関連するピクチャの系列の中の最初のGDRピクチャを含むAUである。リカバリポイントピクチャは、ピクチャが系列の最初のGDRピクチャに先立つピクチャからのデータを参照することなく完全に復号され得るような、GDRの系列の後に続くピクチャである。ピクチャ順序カウント(POC)は、各ピクチャに関連付けられ、コーディングされたビデオシーケンス内のすべてのピクチャの中の関連するピクチャを一意に特定する変数/値である。さらに、関連するピクチャが復号ピクチャバッファ(DPB)から出力されるべきであるとき、POCは、DPBからやはり出力されるべきである同じコーディングされたビデオシーケンス内のその他のピクチャの出力順の位置に対して相対的な出力順における関連するピクチャの位置を示す。リカバリPOCは、リカバリポイントピクチャのPOCである。POC最下位ビット(LSB)は、POC値の最も低い桁のビットのうちの1つ以上である。HRDは、指定された制約への準拠を検証するために符号化プロセスによって生成されたビットストリームの変動を調べるエンコーダ上で動作するデコーダモデルである。HRDの準拠のテストは、符号化されたビットストリームがVVCなどの規格に準拠するかどうかを判定するためのテストである。HRDパラメータは、HRDの動作条件を初期化および/または定義するシンタックス要素である。補足拡張情報(SEI)メッセージは、復号されるピクチャ内のサンプルの値を決定するために復号プロセスによって必要とされない情報を運ぶ指定されたセマンティクスを有するシンタックス構造である。バッファリング期間(BP)SEIメッセージは、コーディングされたピクチャバッファ(CPB)を管理するためにHRDを初期化するためのHRDパラメータを含むSEIメッセージである。CPBは、ビットストリ
ームの準拠の検証中に使用するためにコーディングされたピクチャを復号順で含むHRD内の先入れ先出しバッファである。復号順は、復号プロセスによってシンタックス要素が処理される順序である。CPB削除遅延は、現在のピクチャが削除前にCPB内にとどまることができる時間の期間である。先行ピクチャ出力なしフラグは、DPB内の前に復号されたピクチャが出力されるべきでないことを示すために使用されるフラグである。

【0033】

以下の頭字語、すなわち、コーディングツリーブロック(CTB)、コーディングツリーユニット(CTU)、コーディングユニット(CU)、クリーンランダムアクセス(CRA: Clean Random Access)、コーディングされたビデオシーケンス(CVS)、漸次復号リフレッシュ(GDR)、漸次ランダムアクセス(GRA: Gradual Random Access)、仮想参照デコーダ(HRD)、瞬時復号リフレッシュ(IDR: Instantaneous Decoding Refresh)、合同ビデオ専門家チーム(JVET: Joint Video Experts Team)、動き制約タイルセット(MCTS: Motion Constrained Tile Set)、最大転送単位(MTU)、ネットワーク抽象化レイヤ(NAL: Network Abstraction Layer)、プログレッシブイントラリフレッシュ(PIR: Progressive Intra Refresh)、ピクチャ順序カウント(POC)、生バイトシーケンスペイロード(RBSP: Raw Byte Sequence Payload)、補足拡張情報(SEI)、シーケンスパラメータセット(SPS)、多目的ビデオコーディング(VVC: Versatile Video Coding)が、本明細書において使用される。

【0034】

多くのビデオ圧縮技術が、データの最小限の損失でビデオファイルのサイズを削減するために使用され得る。たとえば、ビデオ圧縮技術は、ビデオシーケンスのデータの冗長性を減らすかまたは取り除くために空間(たとえば、イントラピクチャ)予測および/または時間(インターピクチャ)予測を実行することを含み得る。ブロックに基づくビデオコーディングのために、ビデオスライス(たとえば、ビデオピクチャまたはビデオピクチャの一部)が、ビデオブロックに区分けされる可能性があり、ビデオブロックは、ツリーブロック、コーディングツリーブロック(CTB)、コーディングツリーユニット(CTU)、コーディングユニット(CU: coding unit)、および/またはコーディングノード(coding node)とも呼ばれる可能性がある。ピクチャのイントラコーディングされる(I)スライス内のビデオブロックは、同じピクチャ内の近隣のブロック内の参照サンプルに関連する空間予測を使用してコーディングされる。ピクチャのインターコーディングされる片方向予測(P)または両方向予測(B)スライス内のビデオブロックは、同じピクチャ内の近隣のブロック内の参照サンプルに関連する空間予測またはその他の参照ピクチャ内の参照サンプルに関連する時間予測を使用することによってコーディングされ得る。ピクチャは、フレームおよび/または画像と呼ばれる可能性があり、参照ピクチャは、参照フレームおよび/または参照画像と呼ばれる可能性がある。空間または時間予測は、画像ブロックを表す予測ブロックをもたらす。残差データは、元の画像ブロックと予測ブロックとの間のピクセルの差を表す。したがって、インターコーディングされるブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コーディングされるブロックと予測ブロックとの間の差を示す残差データとによって符号化される。イントラコーディングされるブロックは、イントラコーディングモードおよび残差データによって符号化される。さらなる圧縮のために、残差データが、ピクセル領域(pixel domain)から変換領域(transform domain)に変換され得る。これらは、残差変換係数をもたらし、残差変換係数は、量子化され得る。最初に、量子化された変換係数は、二次元配列に配列され得る。量子化された変
換係数は、変換係数の一次元ベクトルを生成するためにスキャンされ得る。エントロピーコーディングが、より一層の圧縮を実現するために適用され得る。そのようなビデオ圧縮技術は、下でより詳細に検討される。

【0035】

符号化されたビデオが正確に復号され得ることを保証するために、ビデオは、対応するビデオコーディング規格に従って符号化され、復号される。ビデオコーディング規格は、国際電気通信連合(ITU)標準化セクター(ITU-T)H.261、国際標準化機構/国際電気標準会議(ISO/IEC)動画専門家グループ(MPEG)-1パート2、ITU-T H.262またはISO/IEC MPEG-2パート2、ITU-T H.263、ISO/IEC MPEG-4パート2、ITU-T H.264またはISO/IEC MPEG-4パート10としても知られる高度ビデオコーディング(AVC: Advanced Video Coding)、ITU-T H.265またはMPEG-Hパート2としても知られる高効率ビデオコーディング(HEVC: High Efficiency Video Coding)を含む。AVCは、拡張可能なビデオコーディング(SVC: Scalable Video Coding)、多視点ビデオコーディング(MVC: Multiview Video Coding)および多視点ビデオコーディングプラス深度(MVC+D: Multiview Video Coding plus Depth)、ならびに三次元(3D)AVC(3D-AVC)などの拡張を含む。HEVCは、拡張可能なHEVC(SHVC)、多視点HEVC(MV-HEVC)、および3D HEVC(3D-HEVC)などの拡張を含む。ITU-TおよびISO/IECの合同ビデオ専門家チーム(JVET)は、多目的ビデオコーディング(VVC)と呼ばれるビデオコーディング規格の開発を開始した。VVCは、JVET-N1001-v3を含む作業草案(WD)に含まれる。

【0036】

エンコーダは、HRDなどの多くの構成要素を使用する。エンコーダは、ビットストリームを符号化するための様々な構成要素を使用する。次いで、HRDは、符号化が規格に準拠することを保証するために符号化されたビットストリームを調べる。たとえば、HRDは、デコーダがビットストリームを復号することができるはずであることを検証するためにビットストリームを調べることができる。エンコーダは、ビットストリームを符号化するための多くのメカニズムも使用する。GDRは、ビットストリームをコーディングするためにエンコーダによって使用される例示的なコーディングメカニズムである。GDRピクチャは、イントラ予測コーディングされたビデオデータの上の垂直な領域およびインター予測コーディングされたビデオデータの1つ以上の垂直な領域を含む。イントラ予測コーディングされた領域の位置は、一連の関連するピクチャで移動し、クリーン領域を生成する。クリーン領域を含むピクチャは、イントラ予測データまたは別のピクチャのクリーン領域を参照するインター予測データのみを使用してそのようなクリーン領域をコーディングする。この結果、デコーダは、最初のGDRピクチャにおいてビットストリームの復号を開始し、各ピクチャを順序通りに復号することができる。リカバリポイントの前の最後のピクチャが到達されると、デコーダは、同期され、クリーンな使用可能なデータに基づいてインター予測を使用することによって任意のさらなるピクチャを復号することができる。エンコーダのHRDは、イントラ予測データのみを含むイントランダムアクセスポイント(IRAP)ピクチャに基づいて、準拠に関してビットストリームを調べるように構成され得る。しかし、一部のビデオコーディングシステムは、GDRが使用されるとき、準拠に関してビットストリームを調べるように構成されていないHRDを使用し得る。たとえば、一部のHRDは、IRAPピクチャから準拠に関してビットストリームを調べ始めるように構成され得るが、GDRに基づくランダムアクセスポイントを含むビットストリームシーケンスを調べない可能性がある。

【0037】

第1の例において、本明細書に開示されるのは、ビットストリームがGDRピクチャをランダムアクセスポイントとして使用するときにビットストリームの準拠の検査を実行するようにHRDを構成するためのメカニズムである。エンコーダは、GDRピクチャがビットストリームに含まれるとき、HRDパラメータを含むBP SEIメッセージを含めることができる。HRDは、BP SEIメッセージを読んで初期化パラメータを取得することができ、BP SEIメッセージに関連するGDPピクチャから準拠に関してビットストリームを調べ始めてよい。さらに、デコーダは、ビットストリームが準拠していることを検証するためにBP SEIメッセージを調べ、したがって、ビットストリームが復号可能であると判定することができる。したがって、GDRピクチャに関してBP SEIメッセージを含めることは、エンコーダとデコーダとの両方において追加的な機能をサポートする。さらに、GDRは、ネットワーク通信中の帯域幅の瞬間的な上昇の削減をサポートし得る。したがって、ここで開示されているメカニズムは、エンコーダとデコーダとの両方においてプロセッサ、メモリ、および/またはネットワークリソースの使用を削減し得る。

【0038】

さらに、ビデオコーディングシステムは、ヘッダ内で関連するピクチャのピクチャ順序カウント(POC)をシグナリングし得る。そのようなヘッダは、例に依存して、ピクチャヘッダおよび/またはスライスヘッダを含み得る。場合によっては、シグナリングは、GDRピクチャのPOCとリカバリポイントピクチャのPOCとの間の差を示すリカバリPOC差分値を含み得る。しかし、リカバリポイントピクチャの実際のPOC値を決定するために、デコーダは、まず、GDRピクチャのPOCを決定すべきである。したがって、デコーダは、リカバリPOC差分値をメモリに記憶する。次いで、デコーダは、GDRピクチャのPOCが受信され、決定されると、リカバリポイントピクチャのPOC値を決定することができる。

【0039】

第2の例において、本明細書に開示されるのは、GRDが使用されるときにコーディングプロセスの効率を高めるためのメカニズムである。例においては、GDRピクチャに関するPOC LSB値が、スライス/ピクチャヘッダ内でシグナリングされる。POC LSB値は、リカバリピクチャ順序カウント値と一緒にヘッダに含められる。さらに、POC LSB値は、リカバリピクチャ順序カウントよりも前の位置でヘッダにコーディングされる。このようにして、デコーダは、リカバリピクチャ順序カウントを解析する前にPOC LSB値を解析することができる。したがって、リカバリピクチャ順序カウントは、GDRピクチャに関するPOCが決定されると解決されるようにメモリに入れられるのではなく、直ちに決定され得る。したがって、本開示は、エンコーダとデコーダとの両方において追加的な機能をサポートする。さらに、本開示は、エンコーダおよび/またはデコーダにおいてプロセッサ、メモリ、および/またはネットワーク通信リソースの使用を削減する。

【0040】

図1は、ビデオ信号をコーディングする例示的な動作方法100の流れ図である。特に、ビデオ信号は、エンコーダにおいて符号化される。符号化プロセスは、様々なメカニズムを使用してビデオファイルサイズを削減することによってビデオ信号を圧縮する。より小さなファイルサイズは、関連する帯域幅のオーバーヘッドを削減しながら、圧縮されたビデオファイルがユーザに送信されることを可能にする。次いで、デコーダは、圧縮されたビデオファイルを復号して、エンドユーザに対して表示するために元のビデオ信号を再構築する。概して、復号プロセスは、デコーダがビデオ信号を矛盾なく再構築することを可能にするために符号化プロセスを忠実にまねる。

【0041】

ステップ101において、ビデオ信号が、エンコーダに入力される。たとえば、ビデオ信号は、メモリに記憶された未圧縮のビデオファイルである可能性がある。別の例として、ビデオファイルは、ビデオカメラなどのビデオキャプチャデバイスによってキャプチャされ、ビデオのライブストリーミングをサポートするために符号化され得る。ビデオファイルは、オーディオコンポーネントとビデオコンポーネントとの両方を含み得る。ビデオコンポーネントは、順番に見られるときに動きの視覚的な印象を与える一連の画像フレームを含む。フレームは、本明細書においてルマ成分(またはルマサンプル)と呼ばれる光と、クロマ(chroma)成分(またはカラーサンプル)と呼ばれる色とによって表されるピクセルを含む。一部の例において、フレームは、三次元の視聴をサポートするための深度値も含み得る。

【0042】

ステップ103において、ビデオが、ブロックに区分けされる。区分けは、各フレームのピクセルを圧縮のために正方形および/または長方形のブロックに下位分割することを含む。たとえば、高効率ビデオコーディング(HEVC)(H.265およびMPEG-Hパート2としても知られる)において、フレームは、まず、予め定義されたサイズ(たとえば、64ピクセル×64ピクセル)のブロックであるコーディングツリーユニット(CTU)に分割され得る。CTUは、ルマサンプルとクロマサンプルとの両方を含む。CTUをブロックに分割し、次いで、さらなる符号化をサポートする構成が実現されるまでブロックを繰り返し下位分割するためにコーディングツリーが使用され得る。たとえば、フレームのルマ成分は、個々のブロックが比較的均一なライティングの値を含むまで下位分割される可能性がある。たとえば、フレームのクロマ成分は、個々のブロックが比較的均一な色の値を含むまで下位分割される可能性がある。したがって、区分けのメカニズムは、ビデオフレームの内容に応じて変わる。

【0043】

ステップ105においては、ステップ103において区分けされた画像ブロックを圧縮するために様々な圧縮メカニズムが使用される。たとえば、インター予測および/またはイントラ予測が、使用され得る。インター予測は、普通のシーン内の物体が連続したフレームに現れる傾向があるという事実を利用するように設計される。したがって、参照フレームにおいて物体を描くブロックは、近隣のフレームにおいて繰り返し示される必要がない。特に、テーブルなどの物体は、複数のフレームにわたって一定の位置にとどまる可能性がある。したがって、テーブルは、一回示され、隣接するフレームは、参照フレームを振り返って参照することができる。パターンマッチングメカニズムが、複数のフレームにわたって物体をマッチングするために使用され得る。さらに、移動する物体が、たとえば、物体の移動またはカメラの移動が原因で複数のフレームにまたがって表される可能性がある。特定の例として、ビデオは、複数のフレームにわたって画面を横切って移動する自動車を示す可能性がある。動きベクトルが、そのような移動を示すために使用され得る。動きベクトルは、フレーム内の物体の座標から参照フレーム内の物体の座標までのオフセットを与える二次元ベクトルである。したがって、インター予測は、現在のフレーム内の画像ブロックを、参照フレーム内の対応するブロックからのオフセットを示す動きベクトルのセットとして符号化し得る。

【0044】

イントラ予測は、共通のフレーム内のブロックを符号化する。イントラ予測は、ルマ成分およびクロマ成分がフレーム内で塊になる傾向があるという事実を利用する。たとえば、木の一部分の緑の区域は、同様の緑の区域の近隣の位置にある傾向がある。イントラ予測は、複数の方向性予測モード(たとえば、HEVCにおいては33個)、平面モード、および直流(DC)モードを使用する。方向性モードは、現在のブロックが対応する方向の近隣のブロックのサンプルと同様/同じであることを示す。平面モードは、行/列に沿った一連のブロック(たとえば、平面)が、行の端の近隣のブロックに基づいて補間され得ることを示す。実際に、平面モードは、変化する値の比較的一定の勾配を使用することによって行/列間の光/色の滑らかな遷移を示す。DCモードは、境界の平滑化のために使用され、ブロックが方向性予測モードの角度方向に関連するすべての近隣のブロックのサンプルに関連する平均値と同様/同じであることを示す。したがって、イントラ予測ブロックは、画像ブロックを実際の値の代わりに様々な関係予測モードの値として表し得る。さらに、インター予測ブロックは、画像ブロックを実際の値の代わりに動きベクトルの値として表し得る。どちらにせよ、予測ブロックは、場合によっては画像ブロックを正確に表さない可能性がある。すべての差が、残差ブロックに記憶される。ファイルをさらに圧縮するために、残差ブロックに変換が適用され得る。

【0045】

ステップ107において、様々なフィルタリング技術が、適用され得る。HEVCにおいては、フィルタが、ループ内フィルタリング方式によって適用される。上で検討されたブロックに基づく予測は、デコーダにおいてブロックノイズのある画像の生成をもたらす可能性がある。さらに、ブロックに基づく予測方式は、ブロックを符号化し、次いで、符号化されたブロックを参照ブロックとして後で使用するために再構築し得る。ループ内フィルタリング方式は、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ(adaptive loop filter)、およびサンプル適応オフセット(SAO: sample adaptive offset)フィルタをブロック/フレームに反復的に適用する。これらのフィルタは、符号化されたファイルが正確に再構築され得るようにそのようなブロッキングアーティファクトを軽減する。さらに、これらのフィルタは、アーティファクトが再構築された参照ブロックに基づいて符号化される後続のブロックにおいてさらなるアーティファクトを生じる可能性がより低くなるように、再構築された参照ブロック内のアーティファクトを軽減する。

【0046】

ビデオ信号が区分けされ、圧縮され、フィルタリングされると、結果として得られるデータが、ステップ109においてビットストリームに符号化される。ビットストリームは、上で検討されたデータと、デコーダにおいて適切なビデオ信号の再構築をサポートするために望ましい任意のシグナリングデータとを含む。たとえば、そのようなデータは、区分けデータ、予測データ、残差ブロック、およびデコーダにコーディングの命令を与える様々なフラグを含み得る。ビットストリームは、要求に応じてデコーダに送信するためにメモリに記憶される可能性がある。ビットストリームは、複数のデコーダにブロードキャストおよび/またはマルチキャストされる可能性もある。ビットストリームの生成は、反復的なプロセスである。したがって、ステップ101、103、105、107、および109は、多くのフレームおよびブロックにわたって連続的におよび/または同時に行われる可能性がある。図1に示された順序は、検討の明瞭さおよび容易さのために提示されており、ビデオコーディングプロセスを特定の順序に限定するように意図されていない。

【0047】

デコーダは、ステップ111においてビットストリームを受信し、復号プロセスを開始する。特に、デコーダは、エントロピー復号方式を使用して、ビットストリームを対応するシンタックス(syntax)およびビデオデータに変換する。デコーダは、ステップ111において、ビットストリームからのシンタックスデータを使用してフレームに関する区画を決定する。区分けは、ステップ103におけるブロックの区分けの結果と一致するべきである。ステップ111において使用されるエントロピー符号化/復号が、以降で説明される。エンコーダは、入力画像内の値の空間的な位置取りに基づいていくつかの可能な選択肢からブロック区分け方式を選択するなど、圧縮プロセス中に多くの選択を行う。厳密にそのままの選択をシグナリングすることは、多数のビン(bin)を使用し得る。本明細書において使用されるとき、ビンは、変数として扱われる2進値(たとえば、状況に応じて変わる可能性があるビット値)である。エントロピーコーディングは、エンコーダが特定の場合に明らかにうまくいかないすべての選択肢を破棄し、許容可能な選択肢のセットを残すことを可能にする。次いで、それぞれの許容可能な選択肢は、コードワードを割り当てられる。コードワードの長さは、許容可能な選択肢の数に基づく(たとえば、2つの選択肢のために1つのビン、3つから4つまでの選択肢のために2つのビンなど)。次いで、エンコーダは、選択された選択肢に関するコードワードを符号化する。この方式は、コードワードが、すべての可能な選択肢の潜在的に大きなセットからの選択を一意に示すのとは対照的に許容可能な選択肢の小さなサブセットからの選択を一意に示すために望ましいだけの大きさであるので、コードワードのサイズを削減する。次いで、デコーダは、エンコーダと同様にして許容可能な選択肢のセットを決定することによって選択を復号する。許容可能な選択肢のセットを決定することによって、デコーダは、コードワードを読み、エンコーダによってなされた選択を決定することができる。

【0048】

ステップ113において、デコーダが、ブロックの復号を実行する。特に、デコーダは、逆変換を使用して残差ブロックを生成する。次いで、デコーダは、残差ブロックおよび対応する予測ブロックを使用して、区分けに従って画像ブロックを再構築する。予測ブロックは、ステップ105においてエンコーダで生成されたイントラ予測ブロックとインター予測ブロックとの両方を含み得る。次いで、再構築された画像ブロックは、ステップ111において決定された区分けデータに従って再構築されたビデオ信号のフレーム内に位置付けられる。ステップ113のためのシンタックスも、上で検討されたエントロピーコーディングによってビットストリーム内でシグナリングされ得る。

【0049】

ステップ115において、エンコーダのステップ107と同様にして、再構築されたビデオ信号のフレームに対してフィルタリングが実行される。たとえば、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ、およびSAOフィルタが、ブロッキングアーティファクトを取り除くためにフレームに適用され得る。フレームがフィルタリングされると、ビデオ信号が、エンドユーザによる視聴のためにステップ117においてディスプレイに出力され得る。

【0050】

図2は、ビデオコーディングのための例示的なコーディングおよびデコーディング(コーデック)システム200の概略図である。特に、コーデックシステム200は、動作方法100の実装をサポートするための機能を提供する。コーデックシステム200は、エンコーダとデコーダとの両方において使用される構成要素を描くように一般化される。コーデックシステム200は、動作方法100のステップ101および103に関連して検討されたようにビデオ信号を受信し、区分けし、その結果、区分けされたビデオ信号201を生じる。次いで、コーデックシステム200は、方法100のステップ105、107、および109に関連して検討されたように、エンコーダとして働くとき、区分けされたビデオ信号201をコーディングされたビットストリームへと圧縮する。デコーダとして働くとき、コーデックシステム200は、動作方法100のステップ111、113、115、および117に関連して検討されたように、ビットストリームから出力ビデオ信号を生成する。コーデックシステム200は、全般的コーダ制御構成要素211、変換・スケーリングおよび量子化構成要素213、イントラピクチャ推定構成要素215、イントラピクチャ予測構成要素217、動き補償構成要素219、動き推定構成要素221、スケーリングおよび逆変換構成要素229、フィルタ制御分析構成要素227、ループ内フィルタ構成要素225、復号ピクチャバッファ構成要素223、ならびにヘッダフォーマットおよびコンテキスト適応2値算術コーディング(CABAC: context adaptive binary arithmetic coding)構成要素231を含む。そのような構成要素が、示されるように結合される。図2において、黒い線は、符号化される/復号されるデータの動きを示し、一方、破線は、その他の構成要素の動作を制御する制御データの動きを示す。コーデックシステム200の構成要素は、エンコーダにすべて存在する可能性がある。デコーダは、コーデックシステム200の構成要素のサブセットを含む可能性がある。たとえば、デコーダは、イントラピクチャ予測構成要素217、動き補償構成要素219、スケーリングおよび逆変換構成要素229、ループ内フィルタ構成要素225、ならびに復号ピクチャバッファ構成要素223を含む可能性がある。これらの構成要素が、以降で説明される。

【0051】

区分けされたビデオ信号201は、コーディングツリーによってピクセルのブロックに区分けされたキャプチャされたビデオシーケンスである。コーディングツリーは、様々な分割モードを使用してピクセルのブロックをピクセルのより小さなブロックに下位分割する。次いで、これらのブロックは、より小さなブロックにさらに下位分割され得る。ブロックは、コーディングツリーのノードと呼ばれる可能性がある。より大きな親ノードが、より小さな子ノードに分割される。ノードが下位分割される回数は、ノード/コーディングツリーの深さと呼ばれる。分割されたブロックは、場合によってはコーディングユニット(CU)に含まれ得る。たとえば、CUは、ルマブロック、赤色差(Cr)ブロック、および青色差(Cb)ブロックをCUに関する対応するシンタックス命令とともに含むCTUの下位部分であり得る。分割モードは、使用される分割モードに応じて変化する形状の2つ、3つ、または4つの子ノードにノードをそれぞれ区分けするために使用される二分木(BT)、三分木(TT)、および四分木(QT)を含む可能性がある。区分けされたビデオ信号201は、圧縮のために全般的コーダ制御構成要素211、変換・スケーリングおよび量子化構成要素213、イントラピクチャ推定構成要素215、フィルタ制御分析構成要素227、ならびに動き推定構成要素221に転送される。

【0052】

全般的コーダ制御構成要素211は、応用の制約に従ってビットストリームへのビデオシーケンスの画像のコーディングに関連する判断を行うように構成される。たとえば、全般的コーダ制御構成要素211は、ビットレート/ビットストリームサイズ対再構築の品質の最適化を管理する。そのような判断は、ストレージ空間/帯域幅の可用性および画像解像度の要求に基づいてなされ得る。また、全般的コーダ制御構成要素211は、バッファアンダーランおよびオーバーランの問題を軽減するために、送信速度を踏まえてバッファの利用を管理する。これらの問題を管理するために、全般的コーダ制御構成要素211は、その他の構成要素による区分け、予測、およびフィルタリングを管理する。たとえば、全般的コーダ制御構成要素211は、解像度を上げ、帯域幅の使用を増やすために圧縮の複雑さを動的に高くするか、または解像度を下げ、帯域幅の使用を減らすために圧縮の複雑さを動的に低くし得る。したがって、全般的コーダ制御構成要素211は、ビデオ信号の再構築の品質とビットレートの懸念との釣り合いを取るためにコーデックシステム200のその他の構成要素を制御する。全般的コーダ制御構成要素211は、その他の構成要素の動作を制御する制御データを生成する。制御データも、デコーダにおける復号のためのパラメータをシグナリングするためにビットストリームに符号化されるようにヘッダフォーマットおよびCABAC構成要素231に転送される。

【0053】

区分けされたビデオ信号201は、インター予測のために動き推定構成要素221および動き補償構成要素219にも送信される。区分けされたビデオ信号201のフレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定構成要素221および動き補償構成要素219は、時間予測を提供するために1つ以上の参照フレーム内の1つ以上のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。コーデックシステム200は、たとえば、ビデオデータの各ブロックに関する適切なコーディングモードを選択するために複数のコーディングパス(coding pass)を実行し得る。

【0054】

動き推定構成要素221および動き補償構成要素219は、高度に一体化される可能性があるが、概念的な目的のために別々に示される。動き推定構成要素221によって実行される動き推定は、ビデオブロックに関する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、予測ブロックに対するコーディングされるオブジェクトの変位を示し得る。予測ブロックは、ピクセルの差の観点でコーディングされるブロックによく一致することが分かっているブロックである。予測ブロックは、参照ブロックとも呼ばれる可能性がある。そのようなピクセルの差は、差分絶対値和(SAD)、差分二乗和(SSD)、またはその他の差の測定基準によって決定され得る。HEVCは、CTU、コーディングツリーブロック(CTB)、およびCUを含むいくつかのコーディングされるオブジェクトを使用する。たとえば、CTUが、CTBに分割されることが可能であり、次いで、CTBが、CUに含めるためにCBに分割されることが可能である。CUは、CUのための予測データを含む予測ユニット(PU)および/または変換された残差データを含む変換ユニット(TU)として符号化され得る。動き推定構成要素221は、レート歪み最適化プロセスの一部としてレート歪み分析を使用することによって動きベクトル、PU、およびTUを生成する。たとえば、動き推定構成要素221は、現在のブロック/フレームに関する複数の参照ブロック、複数の動きベクトルなどを決定する可能性があり、最良のレート歪みの特徴を有する参照ブロック、動きベクトルなどを選択する可能性がある。最良のレート歪みの特徴は、ビデオの再構築の品質(たとえば、圧縮によるデータ損失の量)とコーディングの効率(たとえば、最終的な符号化のサイズ)との両方の釣り合いを取る。

【0055】

一部の例において、コーデックシステム200は、復号ピクチャバッファ構成要素223に記憶された参照ピクチャの整数よりも細かいピクセル位置の値を計算し得る。たとえば、ビデオコーデックシステム200は、参照ピクチャの4分の1ピクセル位置、8分の1ピクセル位置、またはその他の分数ピクセル(fractional pixel)位置の値を補間し得る。したがって、動き推定構成要素221は、フルピクセル(full pixel)位置および分数ピクセル位置に関連する動き探索を実行し、分数ピクセルの精度で動きベクトルを出力し得る。動き推定構成要素221は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによってインターコーディングされるスライス内のビデオブロックのPUに関する動きベクトルを計算する。動き推定構成要素221は、計算された動きベクトルを符号化のためにヘッダフォーマットおよびCABAC構成要素231に動きデータとして出力し、動きを動き補償構成要素219に出力する。

【0056】

動き補償構成要素219によって実行される動き補償は、動き推定構成要素221によって決定された動きベクトルに基づいて予測ブロックを取り出すことまたは生成することを含み得る。やはり、動き推定構成要素221および動き補償構成要素219は、一部の例において、機能的に統合される可能性がある。現在のビデオブロックのPUに関する動きベクトルを受信すると、動き補償構成要素219は、動きベクトルが指す予測ブロックを特定し得る。次いで、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を引き、ピクセル差分値を形成することによって残差ビデオブロックが形成される。概して、動き推定構成要素221は、ルマ成分に関連する動き推定を実行し、動き補償構成要素219は、クロマ成分とルマ成分との両方のためにルマ成分に基づいて計算された動きベクトルを使用する。予測ブロックおよび残差ブロックは、変換・スケーリングおよび量子化構成要素213に転送される。

【0057】

区分けされたビデオ信号201は、イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217にも送信される。動き推定構成要素221および動き補償構成要素219と同様に、イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217は、高度に一体化される可能性があるが、概念的な目的のために別々に示される。イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217は、上述のようにフレーム間で動き推定構成要素221および動き補償構成要素219によって実行されるインター予測の代替として現在のフレーム内のブロックに対して現在のブロックをイントラ予測する。特に、イントラピクチャ推定構成要素215は、現在のブロックを符号化するために使用するイントラ予測モードを決定する。一部の例において、イントラピクチャ推定構成要素215は、複数のテストされたイントラ予測モードから現在のブロックを符号化するための適切なイントラ予測モードを選択する。次いで、選択されたイントラ予測モードは、符号化のためにヘッダフォーマットおよびCABAC構成要素231に転送される。

【0058】

たとえば、イントラピクチャ推定構成要素215は、様々なテストされたイントラ予測モードに関するレート歪み分析を使用してレート歪み値を計算し、テストされたモードの中で最良のレート歪みの特徴を有するイントラ予測モードを選択する。レート歪み分析は、概して、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間の歪み(または誤差)の量と、符号化されたブロックを生成するために使用されたビットレート(たとえば、ビット数)とを決定する。イントラピクチャ推定構成要素215は、どのイントラ予測モードがブロックに関して最良のレート歪み値を示すかを判定するために、様々な符号化されたブロックに関する歪みおよびレートから比率を計算する。さらに、イントラピクチャ推定構成要素215は、レート歪み最適化(RDO)に基づいて深度モデリングモード(DMM: depth modeling mode)を使用して深度マップの深度ブロックをコーディングするように構成される可能性がある。

【0059】

イントラピクチャ予測構成要素217は、エンコーダに実装されるとき、イントラピクチャ推定構成要素215によって決定された選択されたイントラ予測モードに基づいて予測ブロックから残差ブロックを生成し得るか、またはデコーダに実装されるとき、ビットストリームから残差ブロックを読み得る。残差ブロックは、行列として表された、予測ブロックと元のブロックとの間の値の差を含む。次いで、残差ブロックは、変換・スケーリングおよび量子化構成要素213に転送される。イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217は、ルマ成分とクロマ成分との両方に対して動作し得る。

【0060】

変換・スケーリングおよび量子化構成要素213は、残差ブロックをさらに圧縮するように構成される。変換・スケーリングおよび量子化構成要素213は、残差ブロックに離散コサイン変換(DCT)、離散サイン変換(DST)、または似た概念の変換などの変換を適用し、残差変換係数値を含むビデオブロックを生成する。ウェーブレット変換、整数変換、サブバンド変換、またはその他の種類の変換も、使用される可能性がある。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換・スケーリングおよび量子化構成要素213は、たとえば、周波数に基づいて変換された残差情報をスケーリングするようにさらに構成される。そのようなスケーリングは、異なる周波数情報が異なる粒度で量子化されるように残差情報にスケール因子を適用することを含み、これは、再構築されたビデオの最終的な視覚的品質に影響を与える可能性がある。変換・スケーリングおよび量子化構成要素213は、ビットレートをさらに下げるために変換係数を量子化するようにさらに構成される。量子化プロセスは、係数の一部またはすべてに関連するビット深度を削減し得る。量子化の度合いは、量子化パラメータを調整することによって修正され得る。一部の例において、変換・スケーリングおよび量子化構成要素213は、次いで、量子化された変換係数を含む行列のスキャンを実行し得る。量子化された変換係数は、ビットストリームに符号化されるためにヘッダフォーマットおよびCABAC構成要素231に転送される。

【0061】

スケーリングおよび逆変換構成要素229は、動き推定をサポートするために変換・スケーリングおよび量子化構成要素213の逆演算を適用する。スケーリングおよび逆変換構成要素229は、たとえば、別の現在のブロックに関する予測ブロックになる可能性がある参照ブロックとして後で使用するために、ピクセル領域の残差ブロックを再構築するために逆スケーリング、逆変換、および/または逆量子化を適用する。動き推定構成要素221および/または動き補償構成要素219は、後のブロック/フレームの動き推定において使用するために対応する予測ブロックに残差ブロックを足して戻すことによって参照ブロックを計算し得る。スケーリング、量子化、および変換中に生じたアーティファクトを軽減するために、再構築された参照ブロックにフィルタが適用される。そうでなければ、そのようなアーティファクトは、後続のブロックが予測されるときに不正確な予測をもたらす(およびさらなるアーティファクトを生じる)。

【0062】

フィルタ制御分析構成要素227およびループ内フィルタ構成要素225は、残差ブロックおよび/または再構築された画像ブロックにフィルタを適用する。たとえば、スケーリングおよび逆変換構成要素229からの変換された残差ブロックが、元の画像ブロックを再構築するためにイントラピクチャ予測構成要素217および/または動き補償構成要素219からの対応する予測ブロックと組み合わされ得る。次いで、再構築された画像ブロックにフィルタが適用され得る。一部の例において、フィルタは、その代わりに残差ブロックに適用され得る。図2のその他の構成要素と同様に、フィルタ制御分析構成要素227およびループ内フィルタ構成要素225は、高度に一体化され、一緒に実装される可能性があるが、概念的な目的のために別々に示される。再構築された参照ブロックに適用されるフィルタは、特定の空間的な領域に適用され、そのようなフィルタがどのように適用されるかを調整するための複数のパラメータを含む。フィルタ制御分析構成要素227は、そのようなフィルタがどこに適用されるべきかを決定するために再構築された参照ブロックを分析し、対応するパラメータを設定する。そのようなデータは、符号化のためにフィルタ制御データとしてヘッダフォーマットおよびCABAC構成要素231に転送される。ループ内フィルタ構成要素225は、フィルタ制御データに基づいてそのようなフィルタを適用する。フィルタは、デブロッキングフィルタ、ノイズ抑制フィルタ、SAOフィルタ、および適応ループフィルタを含み得る。そのようなフィルタは、例に依存して、(たとえば、再構築されたピクセルブロックに対して)空間/ピクセル領域において、または周波数領域において適用され得る。

【0063】

エンコーダとして動作するとき、フィルタリングされた再構築された画像ブロック、残差ブロック、および/または予測ブロックは、上で検討されたように、動き推定において後で使用するために復号ピクチャバッファ構成要素223に記憶される。デコーダとして動作するとき、復号ピクチャバッファ構成要素223は、再構築され、フィルタリングされたブロックを記憶し、出力ビデオ信号の一部としてディスプレイに転送する。復号ピクチャバッファ構成要素223は、予測ブロック、残差ブロック、および/または再構築された画像ブロックを記憶することができる任意のメモリデバイスであってよい。

【0064】

ヘッダフォーマットおよびCABAC構成要素231は、コーデックシステム200の様々な構成要素からデータを受信し、そのようなデータをデコーダに送信するためにコーディングされたビットストリームに符号化する。特に、ヘッダフォーマットおよびCABAC構成要素231は、全般的な制御データおよびフィルタ制御データなどの制御データを符号化するための様々なヘッダを生成する。さらに、イントラ予測および動きデータを含む予測データならびに量子化された変換係数データの形態の残差データは、すべてビットストリームに符号化される。最終的なビットストリームは、元の区分けされたビデオ信号201を再構築するためにデコーダによって望まれるすべての情報を含む。そのような情報は、イントラ予測モードのインデックステーブル(コードワードマッピングテーブルとも呼ばれる)、様々なブロックに関する符号化コンテキストの定義、最も可能性が高いイントラ予測モードのインジケーション、区分け情報のインジケーションなども含み得る。そのようなデータは、エントロピーコーディングを使用することによって符号化され得る。たとえば、情報は、コンテキスト適応可変長コーディング(CAVLC: context adaptive variable length coding)、CABAC、シンタックスに基づくコンテキスト適応2値算術コーディング(SBAC: syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE: probability interval partitioning entropy)コーディング、または別のエントロピーコーディング技術を使用して符号化される可能性がある。エントロピーコーディングの後、コーディングされたビットストリームが、別のデバイス(たとえば、ビデオデコーダ)に送信されるか、または後で送信するかもしくは取り出すためにアーカイブされ得る。

【0065】

図3は、例示的なビデオエンコーダ300を示すブロック図である。ビデオエンコーダ300は、コーデックシステム200の符号化機能を実施する、ならびに/または動作方法100のステップ101、103、105、107、および/もしくは109を実施するために使用され得る。エンコーダ300は、入力ビデオ信号を区分けし、区分けされたビデオ信号201と実質的に同様である区分けされたビデオ信号301を生じる。次いで、区分けされたビデオ信号301は、エンコーダ300の構成要素によって圧縮され、ビットストリームに符号化される。

【0066】

特に、区分けされたビデオ信号301は、イントラ予測のためにイントラピクチャ予測構成要素317に転送される。イントラピクチャ予測構成要素317は、イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217と実質的に同様である可能性がある。区分けされたビデオ信号301は、復号ピクチャバッファ構成要素323内の参照ブロックに基づくインター予測のために動き補償構成要素321にも転送される。動き補償構成要素321は、動き推定構成要素221および動き補償構成要素219と実質的に同様である可能性がある。イントラピクチャ予測構成要素317および動き補償構成要素321からの予測ブロックおよび残差ブロックは、残差ブロックの変換および量子化のために変換および量子化構成要素313に転送される。変換および量子化構成要素313は、変換・スケーリングおよび量子化構成要素213と実質的に同様である可能性がある。変換され、量子化された残差ブロックおよび対応する予測ブロックは、ビットストリームにコーディングするためにエントロピーコーディング構成要素331に(関連する制御データと一緒に)転送される。エントロピーコーディング構成要素331は、ヘッダフォーマットおよびCABAC構成要素231と実質的に同様である可能性がある。

【0067】

また、変換され、量子化された残差ブロックおよび/または対応する予測ブロックは、動き補償構成要素321による使用のために参照ブロックへと再構築するために変換および量子化構成要素313から逆変換および量子化構成要素329に転送される。逆変換および量子化構成要素329は、スケーリングおよび逆変換構成要素229と実質的に同様である可能性がある。ループ内フィルタ構成要素325のループ内フィルタが、例に依存して残差ブロックおよび/または再構築された参照ブロックにやはり適用される。ループ内フィルタ構成要素325は、フィルタ制御分析構成要素227およびループ内フィルタ構成要素225と実質的に同様である可能性がある。ループ内フィルタ構成要素325は、ループ内フィルタ構成要素225に関連して検討されたように複数のフィルタを含み得る。次いで、フィルタリングされたブロックが、動き補償構成要素321によって参照ブロックとして使用するために復号ピクチャバッファ構成要素323に記憶される。復号ピクチャバッファ構成要素323は、復号ピクチャバッファ構成要素223と実質的に同様である可能性がある。

【0068】

図4は、例示的なビデオデコーダ400を示すブロック図である。ビデオデコーダ400は、コーデックシステム200の復号機能を実施する、ならびに/または動作方法100のステップ111、113、115、および/もしくは117を実施するために使用される可能性がある。デコーダ400は、たとえば、エンコーダ300からビットストリームを受信し、エンドユーザに対して表示するためにビットストリームに基づいて再構築された出力ビデオ信号を生成する。

【0069】

ビットストリームは、エントロピー復号構成要素433によって受信される。エントロピー復号構成要素433は、CAVLC、CABAC、SBAC、PIPEコーディング、またはその他のエントロピーコーディング技術などのエントロピー復号方式を実施するように構成される。たとえば、エントロピー復号構成要素433は、ビットストリームにコードワードとして符号化されたさらなるデータを解釈するためのコンテキストを与えるためにヘッダ情報を使用し得る。復号された情報は、全般的な制御データ、フィルタ制御データ、区分け情報、動きデータ、予測データ、および残差ブロックからの量子化された変換係数などの、ビデオ信号を復号するための任意の所望の情報を含む。量子化された変換係数は、残差ブロックへの再構築のために逆変換および量子化構成要素429に転送される。逆変換および量子化構成要素429は、逆変換および量子化構成要素329と同様である可能性がある。

【0070】

再構築された残差ブロックおよび/または予測ブロックは、イントラ予測動作に基づいて画像ブロックへと再構築するためにイントラピクチャ予測構成要素417に転送される。イントラピクチャ予測構成要素417は、イントラピクチャ推定構成要素215およびイントラピクチャ予測構成要素217と同様である可能性がある。特に、イントラピクチャ予測構成要素417は、予測モードを使用してフレーム内の参照ブロックを特定し、イントラ予測された画像ブロックを再構築するために結果に残差ブロックを適用する。再構築されたイントラ予測された画像ブロックおよび/または残差ブロックならびに対応するインター予測データは、ループ内フィルタ構成要素425を介して復号ピクチャバッファ構成要素423に転送され、これらの構成要素は、それぞれ、復号ピクチャバッファ構成要素223およびループ内フィルタ構成要素225と実質的に同様である可能性がある。ループ内フィルタ構成要素425は、再構築された画像ブロック、残差ブロック、および/または予測ブロックをフィルタリングし、そのような情報は、復号ピクチャバッファ構成要素423に記憶される。復号ピクチャバッファ構成要素423からの再構築された画像ブロックは、インター予測のために動き補償構成要素421に転送される。動き補償構成要素421は、動き推定構成要素221および/または動き補償構成要素219と実質的に同様である可能性がある。特に、動き補償構成要素421は、参照ブロックからの動きベクトルを使用して予測ブロックを生成し、画像ブロックを再構築するために結果に残差ブロックを適用する。結果として得られる再構築されたブロックは、ループ内フィルタ構成要素425を介して復号ピクチャバッファ構成要素423にやはり転送され得る。復号ピクチャバッファ構成要素423は、さらなる再構築された画像ブロックの記憶を続け、それらの再構築された画像ブロックは、区分け情報によってフレームに再構築され得る。また、そのようなフレームは、シーケンスに配置され得る。シーケンスは、再構築された出力ビデオ信号としてディスプレイに出力される。

【0071】

図5は、例示的なHRD 500を示す概略図である。HRD 500は、コーデックシステム200および/またはエンコーダ300などのエンコーダにおいて使用され得る。HRD 500は、ビットストリームがデコーダ400などのデコーダに転送される前に方法100のステップ109において生成されたビットストリームを調べてよい。一部の例において、ビットストリームは、ビットストリームが符号化されるとき、HRD 500を通じて連続的に転送され得る。ビットストリームの一部が関連する制約に準拠することができない場合、HRD 500は、エンコーダに異なるメカニズムによってビットストリームの対応するセクションを再符号化させるためにエンコーダにそのような失敗を示すことができる。

【0072】

HRD 500は、仮想ストリームスケジューラ(HSS: hypothetical stream scheduler) 541を含む。HSS 541は、仮想的な配信メカニズムを実行するように構成された構成要素である。仮想的な配信メカニズムは、HRD 500に入力されたビットストリーム551のタイミングおよびデータフローに関してビットストリームまたはデコーダの準拠を調べるために使用される。たとえば、HSS 541は、エンコーダから出力されるビットストリーム551を受け取り、ビットストリーム551に対する準拠テストプロセスを管理し得る。特定の例において、HSS 541は、コーディングされたピクチャがHRD 500を通過するレートを制御し、ビットストリーム551が準拠しないデータを含まないことを検証することができる。

【0073】

HSS 541は、予め定義されたレートでCPB 543にビットストリーム551を転送し得る。HRD 500の目的のために、AUおよび/またはNALユニットなどのビットストリーム551内のコーディングされたピクチャを含む任意の単位が、復号可能ユニット(DU: decodable unit) 553と呼ばれ得る。CPB 543は、HRD 500内の先入れ先出しバッファである。CPB 543は、コーディングされたピクチャまたはその下位部分(たとえば、スライス)を含むDU 553を復号順で含む。CPB 543は、ビットストリームの準拠の検証中に使用するためにそのようなピクチャを記憶する。

【0074】

CPB 543は、DU 553を復号プロセス構成要素545に転送する。復号プロセス構成要素545は、VVC規格に準拠する構成要素である。たとえば、復号プロセス構成要素545は、エンドユーザによって使用されるデコーダ400をエミュレートし得る。復号プロセス構成要素545は、例示的なエンドユーザのデコーダによって達成され得るレートでDU 553を復号する。復号プロセス構成要素545がCPB 543のオーバーフローを防ぐのに十分なだけ速くDU 553を復号することができない場合、次いで、ビットストリーム551は、規格に準拠せず、再符号化されるべきである。

【0075】

復号プロセス構成要素545は、DU 553を復号し、それにより復号されたDU 555を生成する。復号されたDU 555は、復号されたピクチャを含む。復号されたDU 555は、DPB 547に転送される。DPB 547は、復号ピクチャバッファ構成要素223、323、および/または423と実質的に同様であってよい。インター予測をサポートするために、復号されたDU 555から取得される参照ピクチャ556として使用するためにマーキングされるピクチャが、さらなる復号をサポートするために復号プロセス構成要素545に戻される。DPB 547は、復号されたビデオシーケンスをピクチャ557の系列として出力する。ピクチャ557は、概してエンコーダによってビットストリーム551に符号化されたピクチャを模倣する再構築されたピクチャである。

【0076】

ピクチャ557は、出力クロッピング構成要素549に転送される。出力クロッピング構成要素549は、ピクチャ557に準拠クロッピングウィンドウ(conformance cropping window)を適用するように構成される。これは、出力クロッピング済みピクチャ559をもたらす。出力クロッピング済みピクチャ559は、完全に再構築されたピクチャである。したがって、出力クロッピング済みピクチャ559は、ビットストリーム551を復号したときにエンドユーザが見るものを模倣する。したがって、エンコーダは、符号化が満足のいくものであることを保証するために出力クロッピング済みピクチャ559を見直すことができる。

【0077】

図6は、ビデオシーケンスに対してGDR 600を実行するための例示的なメカニズムを示す概略図である。GDR 600は、コーデックシステム200および/またはエンコーダ300などのエンコーダによって符号化され、コーデックシステム200および/またはデコーダ400などのデコーダによって復号されるビットストリームに対して使用され得る。さらに、本明細書において説明される技術を使用することによって、エンコーダのHRD 500が、GDR 600を使用するビットストリームに対してビットストリームの準拠の検査を実行することができる。

【0078】

実施形態において、GDR 600は、CVS 608などのCVS内にランダムアクセスポイントを作るために使用され得る。GDR 600は、IRAPピクチャなどの完全にイントラコーディングされる単一のピクチャによってコーディングされたビデオシーケンス608を初期化することを避けるためにインターコーディングされる領域とイントラコーディングされる領域との両方をそれぞれが含むピクチャの系列をコーディングするメカニズムである。特に、ビデオシーケンス内のほとんどのピクチャは、インター予測によってコーディングされ、したがって、その他のピクチャを参照することによって復号される。デコーダは、参照ピクチャが利用可能でない場合、インターコーディングされたピクチャを復号することができない可能性がある。GDR 600は、リカバリポイントを作成するメカニズムを提供し、リカバリポイントを超えると、すべてのピクチャが、正しく復号され得る。

【0079】

実施形態において、CVS 608は、GDRピクチャ602、1つ以上のトレーリングピクチャ(trailing picture)604、およびリカバリポイントピクチャ606を含む。実施形態において、GDRピクチャ602は、CVS開始(CVSS)ピクチャと呼ばれる。さらに、GDRピクチャ602は、GDRに関連するピクチャの系列の中の最初のGDRピクチャを含むAUであるGDR AUに含まれ得る。CVS 608は、ビデオビットストリーム内のあらゆるコーディングされたレイヤ毎ビデオシーケンス(CLVS: coded layer-wise video sequence)に関するコーディングされたビデオシーケンスであってよい。特に、ビデオビットストリームが単一のレイヤを含むとき、CVSおよびCLVSは同じである。CVSおよびCLVSは、ビデオビットストリームが複数の層を含むときにのみ異なる。実施形態において、トレーリングピクチャ604は、それらのトレーリングピクチャ604がGDR期間内でリカバリポイントピクチャ606よりも前にあるのでGDRピクチャの形態であると考えられ得る。

【0080】

実施形態において、GDRピクチャ602、トレーリングピクチャ604、およびリカバリポイントピクチャ606は、CVS 608内でGDR期間を定義し得る。実施形態において、復号順は、GDRピクチャ602から始まり、トレーリングピクチャ604に続き、次いで、リカバリピクチャ606に続く。CVS 608は、GDRピクチャ602から始まり、次のGDRピクチャを含まずに次のGDRピクチャまでまたはビットストリームの終わりまでのすべてのピクチャ(またはその一部)を含むピクチャ(またはその一部)の系列である。GDR期間は、GDRピクチャ602から始まり、リカバリポイントピクチャ606を含んでリカバリポイントピクチャ606までのすべてのピクチャを含むピクチャの系列である。CVS 608に関する復号プロセスは、GDRピクチャ602がビデオのランダムアクセスポイントとして使用されるとき、GDRピクチャ602において始まる。ランダムアクセスポイントは、デコーダが使用可能なビデオデータを取得するために復号を開始することができるビットストリーム内の任意の位置である。

【0081】

図6に示されるように、GDR 600は、GDRピクチャ602から始まり、リカバリポイントピクチャ606で終わるピクチャの系列上で動作する。GDRピクチャ602は、すべてイントラ予測を使用してコーディングされたブロック(すなわち、イントラ予測されたブロック)を含むリフレッシュ済み/クリーン領域610と、すべてインター予測を使用してコーディングされたブロック(すなわち、インター予測されたブロック)を含む未リフレッシュ/ダーティ(dirty)領域612とを含む。イントラ予測されたブロックは、その他のピクチャを参照することなく復号され得る。しかし、ダーティ領域内のインター予測されたブロックは、GDRピクチャ602に先立つピクチャを参照することによってのみ復号されることが可能であり、したがって、GDRピクチャ602がランダムアクセスポイントとして使用されないときにのみ復号されることが可能である。

【0082】

GDRピクチャ602に直接隣接するトレーリングピクチャ604は、イントラ予測を使用してコーディングされた第1の領域610Aおよびインター予測を使用してコーディングされた第2の領域610Bを有するリフレッシュ済み/クリーン領域610を含む。第2の領域610Bは、たとえば、CVS 608のGDR期間内の前のピクチャのリフレッシュ済み/クリーン領域610を参照することによってコーディングされる。示されるように、トレーリングピクチャ604のリフレッシュ済み/クリーン領域610は、コーディングプロセスが一貫した方向に(たとえば、左から右に)移動するまたは進行するにつれて広がり、これは、それに対応して、未リフレッシュ/ダーティ領612を縮小させる。結局、リフレッシュ済み/クリーン領域610のみを含むリカバリポイントピクチャ606が、コーディングプロセスによって到達される。特に、インター予測されたブロックとしてコーディングされるリフレッシュ済み/クリーン領域610の第2の領域610Bは、参照ピクチャ内のリフレッシュ済み/クリーン領域610のみを参照し得る。この制限は、ダーティなデータがリフレッシュ済み/クリーン領域610に持ち込まれないことを保証する。

【0083】

したがって、リカバリポイントピクチャ606は、リカバリポイントピクチャ606が系列の最初のGDRピクチャ602に先立つピクチャからのデータを参照することなく完全に復号され得るような、GDRの系列の後に続くピクチャである。リカバリポイントピクチャ606は、先行ピクチャ内の任意のクリーン領域610を参照することによってインター予測によりコーディングされ得る。図6から分かるように、デコーダがリカバリポイントピクチャ606が到達されるとピクチャの表示を開始したい可能性があるので、デコーダは、どのピクチャがリカバリポイントピクチャ606であるかを迅速に判定したい可能性がある。たとえば、先行ピクチャ出力なしフラグが、GDRピクチャ602に関連するピクチャまたはスライスヘッダなどのヘッダ内で設定され得る。このフラグが設定されるとき、ピクチャは、リカバリポイントピクチャ606が到達されるまでユーザに対して出力されない。これは、表示するために適切に復号され得ない未リフレッシュ/ダーティ領域612を含むGDRピクチャ602およびトレーリングピクチャ604の表示を防止し得る。

【0084】

このプロセスは、POC値を使用することによって管理され得る。POCは、各ピクチャに関連付けられ、CVS 608内のすべてのピクチャの中の関連するピクチャを一意に特定する変数/値である。さらに、関連するピクチャがDPBから出力されるべきであるとき、POCは、DPBからやはり出力されるべきである同じCVS 608内のその他のピクチャの出力順の位置に対して相対的な出力順における関連するピクチャの位置を示す。したがって、GDRピクチャ602は、GDR POC 621を有し、トレーリングピクチャ604は、POC 623を有し、リカバリポイントピクチャ606は、リカバリPOC 622を有する。したがって、GDR POC 621は、GDRピクチャ602のPOCであり、リカバリPOC 622は、リカバリポイントピクチャ606のPOCである。デコーダは、POC値を使用して、GDRピクチャに関連する復号の詳細を決定することができる。たとえば、ヘッダが、GDRピクチャ602に関連するPOC LSBを示すために使用され得る。POC LSBは、POC値の最も低い桁のビットのうちの1つ以上である。デコーダは、GDR POC 621を決定するためにGDRピクチャ602のPOC LSBをその他のシンタックス要素と一緒に使用し得る。この手法は、GDR POC 621を表すために使用されるビット数を削減し得る。リカバリPOC 622は、GDR POC 621とリカバリPOC 622との間の差として表され得る。したがって、デコーダは、ヘッダからのPOC LSB値に基づいてGDRピクチャ602に関するPOCを決定し得る。次いで、デコーダは、ヘッダからリカバリPOC 622を取得し、GDRピクチャ602に関するGDR POC 621に基づいてリカバリPOC 622値を解決し得る。リカバリPOC 622値は、解決される/決定されると、リカバリポイントピクチャ606に関するPOCを示す。次いで、デコーダは、再構築されたピクチャの表示をリカバリポイントピクチャ606から開始し得る。

【0085】

図7は、GDR 600をサポートするためにエンコーダの制限を使用するときの望ましくない動き探索700を示す概略図である。示されるように、動き探索700は、現在のピクチャ702および参照ピクチャ704を示す。現在のピクチャ702および参照ピクチャ704は、イントラ予測によってコーディングされたリフレッシュ済み領域706、インター予測によってコーディングされたリフレッシュ済み領域705、および未リフレッシュ領域708をそれぞれ含む。リフレッシュ済み領域705、リフレッシュ済み領域706、および未リフレッシュ領域708は、それぞれ、図6のリフレッシュ済み/クリーン領域610の第1の領域610A、リフレッシュ済み/クリーン領域610の第2の領域610B、および未リフレッシュ/ダーティ領域612と同様である。

【0086】

動き探索プロセス中、エンコーダは、リフレッシュ済み領域705～706の外にあるサンプルを含む参照ブロック712を指すいかなる動きベクトル710も選択することを制約されるまたは防止される。これは、参照ブロック712が現在のピクチャ702内の現在のブロック714を予測するときに最良のレート歪みコストの尺度をもたらすときでさえも起こる。しかし、この制約を使用することは、リフレッシュ済み領域705～706がいかなるダーティなデータも参照せず、したがって、関連するGDRピクチャがランダムアクセスポイントとして使用されるときに復号不可能にならないことを保証する。

【0087】

図8は、GDR 600などのGDRが使用されるときにHRD 500などのHRDを初期化する際に使用するための例示的なビットストリーム800を示す概略図である。たとえば、ビットストリーム800は、方法100に係るコーデックシステム200および/またはデコーダ400による復号のためにコーデックシステム200および/またはエンコーダ300によって生成され得る。

【0088】

ビットストリーム800は、SPS 810、複数のピクチャパラメータセット(PPS)811、複数のスライスヘッダ815、および画像データ820を含む。SPS 810は、ビットストリーム800に含まれるコーディングされたビデオシーケンス内のすべてのピクチャに共通のシーケンスデータを含む。そのようなデータは、ピクチャのサイズ設定、ビット深度、コーディングツールのパラメータ、ビットレートの制約などを含み得る。PPS 811は、ピクチャ全体に適用されるパラメータを含む。したがって、ビデオシーケンス内の各ピクチャは、PPS 811を参照し得る。各ピクチャはPPS 811を参照するが、一部の例においては、単一のPPS 811が複数のピクチャに関するデータを含み得ることに留意されたい。たとえば、複数の同様のピクチャは、同様のパラメータによってコーディングされる可能性がある。そのような場合、単一のPPS 811が、そのような同様のピクチャに関するデータを含み得る。PPS 811は、対応するピクチャ内のスライスのために利用可能なコーディングツール、量子化パラメータ、オフセットなどを示し得る。スライスヘッダ815は、ピクチャ内の各スライスに固有のパラメータを含む。したがって、ビデオシーケンス内のスライス毎に1つのスライスヘッダ815があってもよい。スライスヘッダ815は、スライスタイプ情報、POC、参照ピクチャリスト、予測の重み、タイルエントリポイント、デブロッキングパラメータなどを含み得る。スライスヘッダ815は、文脈によってはタイルグループヘッダとも呼ばれる可能性があることに留意されたい。一部の例において、ビットストリーム800は、単一のピクチャ内のすべてのスライスに当てはまるパラメータを含むシンタックス構造であるピクチャヘッダも含む可能性があることに留意されたい。この理由で、ピクチャヘッダおよびスライスヘッダ815が、文脈によっては交換可能なように使用され得る。たとえば、特定のパラメータが、そのようなパラメータがピクチャ内のすべてのスライスに共通であるかどうかに応じてスライスヘッダ815とピクチャヘッダとの間で移動される可能性がある。

【0089】

画像データ820は、インター予測および/またはイントラ予測によって符号化されたビデオデータならびに対応する変換され、量子化された残差データを含む。たとえば、ビデオシーケンスは、複数のピクチャ823を含む。ピクチャ823は、ビデオシーケンス内の対応する瞬間におけるユーザに対する完全なまたは部分的な表示を目的とする完全な画像である。ピクチャ823は、単一のAU 821に含まれ得る。AU 821は、単一のコーディングされたピクチャ823と、任意選択で、コーディングされたピクチャ823をコーディングするために使用されたコーディングメカニズムを示すパラメータを含むスライスヘッダ815などの1つ以上のヘッダとを記憶するように構成されたコーディングユニットである。ピクチャ823は、1つ以上のスライス825を含む。スライス825は、単一のNALユニットに排他的に含まれるピクチャ823の整数個の完全なタイルまたは(たとえば、タイル内の)整数個の連続する完全なCTUの行として定義され得る。スライス825は、CTUおよび/またはコーディングツリーブロック(CTB)にさらに分割される。CTUは、コーディングツリーによって区分けされ得る予め定義されたサイズのサンプルのグループである。CTBは、CTUのサブセットであり、CTUのルマ成分またはクロマ成分を含む。CTU/CTBは、コーディングツリーに基づいてコーディングブロックにさらに分割される。次いで、コーディングブロックが、予測メカニズムによって符号化/復号され得る。

【0090】

上述のように、一部のビデオコーディングシステムは、ビットストリーム800がGDR 600によってコーディングされたピクチャ823を含むときにHRD 500を実行するように構成されない可能性がある。これは、HRD 500がIRAPピクチャにおいて準拠のテストを実行し始めるように構成され得るからである。BP SEIメッセージ817が、この問題に対処するために使用され得る。BP SEIメッセージ817は、GDR AUに関連付けられ得る。たとえば、BP SEIメッセージ817は、GDRピクチャ(たとえば、GDR期間内の最初のピクチャ)を含む各AU 821に関してビットストリーム800に含まれ得る。SEIメッセージは、復号されるピクチャ内のサンプルの値を決定するために復号プロセスによって必要とされない情報を運ぶ指定されたセマンティクスを有するシンタックス構造である。したがって、SEIメッセージは、ビットストリーム800の復号に直接関連しないパラメータをシグナリングするために使用される。BP SEIメッセージ817は、CPB 543などのCPBを管理するためにHRDを初期化するためのHRDパラメータ836を含むSEIメッセージである。CPBは、指定された期間、ピクチャを保持/バッファリングし得る。したがって、BP SEIメッセージ817は、CPBにおけるバッファリング期間を指定するように構成され得る。HRDパラメータ836は、HRDの初期化をサポートする任意のパラメータを含む。たとえば、HRDパラメータ836は、初期CPB削除遅延を含み得る。CPB削除遅延は、現在のピクチャが削除前にCPB内にとどまることができる時間の期間である。CPB削除遅延は、復号順でのGDR AUの位置におけるHRDの初期化のために使用され得る。したがって、BP SEIメッセージ817は、GDRピクチャにおいてHRDを初期化するために使用されてよく、したがって、ビットストリームがGDRピクチャを含むときにビットストリームの準拠のテストの適用をサポートする。さらに、BP SEIメッセージ817内のHRDパラメータ836は、ビットストリーム800が準拠のテストにかけられたことをデコーダに示し得る。したがって、BP SEIメッセージ817内のHRDパラメータ836は、デコーダがビットストリーム800を復号することができることをデコーダに示し得る。

【0091】

ビットストリーム800は、GDRの使用をサポートするためのその他のメカニズムも含み得る。たとえば、スライスヘッダ815または対応するピクチャヘッダは、先行ピクチャ出力なしフラグ831を含み得る。先行ピクチャ出力なしフラグ831は、GDR AUに含まれる、GDRピクチャに関するヘッダ内で設定され得る。先行ピクチャ出力なしフラグ831は、リカバリピクチャが到達されるまでGDR期間内のピクチャが出力されるべきでないことをデコーダに示すために設定され得る。次いで、リカバリピクチャは、ダーティなデータに基づいて再構築される部分的に再構築される部分的に復号されたピクチャを表示することなく表示され得る。

【0092】

さらに、ビットストリーム800は、たとえば、スライスヘッダ815または対応するピクチャヘッダにPOC LSB値833およびリカバリPOC値835を含み得る。POC LSB値833は、POC値の最も低い桁のビットのうちの1つ以上を含む。POC LSB値833は、GDRピクチャに関連付けられてよく、したがって、GDRピクチャに関するPOCのLSBを示し得る。例において、POC LSB値833は、ph_pic_order_cnt_lsbの値としてヘッダに含まれ得る。ph_pic_order_cnt_lsbの値は、現在のピクチャがGDRピクチャであるとき、現在のピクチャに関するPOCモジュロ最大POC LSBを指定し得る。リカバリPOC値835は、GDRピクチャに関連するリカバリポイントピクチャのPOCを示す。たとえば、リカバリPOC値835は、POC LSB値833と同じヘッダに含まれ得る。さらに、リカバリPOC値835は、リカバリPOCカウント(recovery_poc_cnt)の値としてシグナリングされ得る。recovery_poc_cntの値は、出力順における復号されたピクチャのリカバリポイントを、GDR POCとリカバリポイントピクチャPOCとの間のPOCカウントの差として指定する。さらに、POC LSB値833は、ヘッダ内でリカバリPOC値835よりも前に載せられ得る。このようにして、デコーダは、ヘッダを解析してPOC LSB値833を取得し、GDR POCを決定することができる。デコーダは、ヘッダを解析してリカバリPOC値835を取得することができる。GDR POCがPOC LSB値833に基づいて既に決定されているので、リカバリPOC値835は、リカバリポイントピクチャPOCが決定され得るように直ちに解決されることが可能である。これは、GDRピクチャに関するPOC LSB値833が解析され、解決され得るまでメモリに未解決のリカバリPOC値835を記憶することをデコーダが避けることを可能にする。したがって、ビットストリーム800は、たとえば、HRDに関連しておよび/またはデコーダに関連して高められたGDR機能をサポートする様々なメカニズムを含む。したがって、ビットストリーム800に関連して説明されるメカニズムは、エンコーダおよび/またはデコーダの機能を高め得る。さらに、ビットストリーム800に関連して説明されるメカニズムは、高められたコーディングの効率をサポートし得る、ならびに/またはエンコーダおよび/もしくはデコーダにおけるプロセッサ、メモリ、および/もしくはネットワーク通信リソースの削減をサポートし得る。

【0093】

以降で、上述の情報が、本明細書において下でより詳細に説明される。高効率ビデオコーディング(HEVC)を実装するビデオコーディングシステムは、複数のIRAPピクチャを使用し得る。特に、HEVCにおいては、IDR、ブロークンリンクアクセス(BLA: broken link access)、およびCRAピクチャが、まとめてIRAPピクチャとみなされる。VVCを使用するビデオコーディングシステムは、IDRおよびCRAピクチャをIRAPピクチャとして使用し得る。IRAPピクチャは、以下の機能/利点を提供し得る。IRAPピクチャの存在は、復号プロセスがそのピクチャから開始し得ることを示す。この機能は、IRAPピクチャがその位置に存在する限り、必ずしもビットストリームの始めではないビットストリーム内の位置で復号プロセスが開始し得るランダムアクセスの特徴をサポートする。また、IRAPピクチャの存在は、ランダムアクセススキップリーディング(RASL: random access skipped leading)ピクチャを除く、復号順でIRAPピクチャの後にコーディングされるピクチャがIRAPピクチャよりも前のピクチャを一切参照せずにコーディングされるように復号プロセスをリフレッシュし得る。したがって、IRAPピクチャよりも前のピクチャを復号するときに発生し得る任意のコーディングエラーが、IRAPピクチャを通じて、復号順でIRAPピクチャの後に続くピクチャに伝搬しない可能性がある。

【0094】

IRAPピクチャは、圧縮効率に対する不利益と引き換えに様々な機能を提供する。たとえば、IRAPピクチャの存在は、ビットレートの急上昇を引き起こす。圧縮効率に対するこの不利益は、2つの原因がある。第1に、IRAPピクチャは、イントラ予測されたピクチャである。したがって、IRAPを表現するためにはその他のインター予測されたピクチャよりも多くのビットが使用され得る。第2に、IRAPピクチャの存在は、時間予測を損ない得る。これは、IRAPピクチャが復号プロセスをリフレッシュし、DPBから以前の参照ピクチャを削除し得るからである。したがって、復号順でIRAPピクチャの後に続くピクチャのコーディングの効率は、インター予測コーディングを実行するときにそのようなピクチャがその中から選択を行う参照ピクチャがより少なくなるので低下させられ得る。

【0095】

IRAPピクチャとみなされるピクチャの種類の中で、IDRピクチャは、その他のピクチャの種類と比べたときに異なるシグナリングおよび導出を使用し得る。違いの一部は、以下の通りである。IDRピクチャのPOC値のシグナリングおよび導出に関して、POCの最上位ビット(MSB)部分は、前のキーピクチャから導出されない可能性があり、その代わりに、ゼロに等しいように設定されてよい。参照ピクチャ管理のために使用される情報のシグナリングに関して、IDRピクチャのスライスヘッダは、参照ピクチャ管理を支援するための情報を含まない可能性がある。CRAおよびトレーリングピクチャなどのその他のピクチャの種類は、参照ピクチャのマーキングプロセスをサポートするために参照ピクチャセット(RPS: reference picture set)または参照ピクチャリスト情報などの情報を含み得る。参照ピクチャのマーキングプロセスは、DPB内の参照ピクチャのステータスが参照のために使用されるのかまたは参照のために使用されないのかどちらなのかを決定するためのプロセスである。しかし、IDRの存在は復号プロセスがDPB内のすべての参照ピクチャを参照のために使用されないものとしてマーキングすべきであることを示すので、IDRピクチャに関して、そのような情報はシグナリングされない可能性がある。

【0096】

リーディングピクチャ(leading picture)は、存在するとき、IRAPピクチャに関連付けられる。リーディングピクチャは、復号順で関連するIRAPピクチャの後であるが、提示/出力順ではIRAPピクチャよりも前のピクチャである。コーディングの構成およびピクチャの参照構造に応じて、リーディングピクチャは、さらに、2つの種類に分類される。第1の種類は、復号プロセスが関連するIRAPピクチャにおいて開始するときに正しく復号されない可能性があるリーディングピクチャである。そのようなピクチャは、ランダムアクセススキップリーディング(RASL)ピクチャとして知られる。RASLピクチャは、復号順でIRAPピクチャよりも前のピクチャを参照してコーディングされるので、この場合、復号可能でない可能性がある。第2の種類は、復号プロセスが関連するIRAPピクチャにおいて開始するときでさえも正しく復号され得るリーディングピクチャである。これらのピクチャは、ランダムアクセス復号可能リーディング(RADL: random access decodable leading)ピクチャとして知られる。RADLピクチャは、復号順でIRAPピクチャよりも前のピクチャを直接的または間接的に参照することなくコーディングされるので復号され得る。一部のビデオコーディングシステムは、RASLピクチャおよびRADLピクチャが同じIRAPピクチャに関連付けられるとき、RASLピクチャが出力順でRADLピクチャよりも前にあるべきであるような制約を使用する。

【0097】

IRAPピクチャおよびリーディングピクチャは、システムレベルのアプリケーションによる特定をサポートするために異なるNALユニットタイプを割り当てられる。たとえば、ビデオスプライサ(video splicer)は、コーディングされたビットストリーム内の詳細なシンタックス要素を精査することなくコーディングされたピクチャの種類を決定するように構成され得る。たとえば、ビデオスプライサは、非IRAPピクチャからIRAPピクチャを特定し、RASLピクチャおよびRADLピクチャを決定することを含め、トレーリングピクチャからリーディングピクチャを特定し得る。トレーリングピクチャは、IRAPピクチャに関連付けられ、出力順でIRAPピクチャの後に続くピクチャである。ピクチャは、ピクチャが復号順で特定のIRAPピクチャの後に続き、復号順でいかなるその他のIRAPピクチャよりも前にあるとき、特定のIRAPピクチャに関連付けられる。したがって、IRAPピクチャおよびリーディングピクチャに異なるNALユニットタイプを割り当てることは、そのようなアプリケーションをサポートする。

【0098】

ピクチャの種類のためのいくつかの例示的なNALユニットタイプは、以下の通りである。リーディングピクチャを有するBLA(BLA_W_LP)は、復号順で1つ以上のリーディングピクチャが後に続いてもよいブロークンリンクアクセス(BLA)ピクチャのNALユニットである。RADLを有するBLA(BLA_W_RADL)は、復号順で1つ以上のRADLピクチャが後に続くが、RASLピクチャは後に続かなくてもよいBLAピクチャのNALユニットである。リーディングピクチャを持たないBLA(BLA_N_LP)は、復号順でリーディングピクチャが後に続かないBLAピクチャのNALユニットである。RADLを有するIDR(IDR_W_RADL)は、復号順で1つ以上のRADLピクチャが後に続くが、RASLピクチャは後に続かなくてもよいIDRピクチャのNALユニットである。リーディングピクチャを持たないIDR(IDR_N_LP)は、復号順でリーディングピクチャが後に続かないIDRピクチャのNALユニットである。CRAは、RASLピクチャ、RADLピクチャ、またはそれら両方などのリーディングピクチャが後に続いてもよいCRAピクチャのNALユニットである。RADLは、RADLピクチャのNALユニットである。RASLは、RASLピクチャのNALユニットである。

【0099】

低遅延のアプリケーションに関して、IRAPピクチャを避けることは、非IRAPピクチャのコーディングと比較してIRAPピクチャのコーディングのビットレートの要件が比較的高いために有益である可能性があり、それは、そのようなより高いビットレートの要件が、レイテンシーおよび/または遅延の増加を引き起こすからである。しかし、ランダムアクセスポイントの使用を完全に避けることは、すべての低遅延のアプリケーションにおいて可能というわけではない可能性がある。たとえば、複数の参加者がいる遠隔会議などの会話アプリケーションは、新しいユーザが遠隔会議に加わることができる定期的な時点(regular point)を提供する必要がある可能性がある。

【0100】

プログレッシブイントラリフレッシュ(PIR)は、IRAPピクチャを使用することなくランダムアクセスポイントをビットストリームに提供するために使用され得る例示的なメカニズムである。この手法は、IRAPに関連するビットレートのピークの高まりを防止しながら、新しいユーザが複数の参加者がいる遠隔会議アプリケーションに加わることを可能にし得る。PIRは、漸次復号リフレッシュ(GDR)および/または漸次ランダムアクセス(GRA)と呼ばれることもある。図6は、GDRを実行するための例示的なメカニズムを示す。GDR技術は、GDRピクチャから始まる複数のピクチャ上で動作する。GDRピクチャは、領域内のすべてのコーディングされるブロックがイントラ予測されたブロックとしてコーディングされる1つの領域を含む。この領域は、リフレッシュ済み/クリーン領域と呼ばれることがある。GDRピクチャの残りの部分の中のブロックは、インター予測されたブロックとしてコーディングされ得る。この領域は、未リフレッシュ/ダーティ領域と呼ばれることがある。GDRピクチャの後に続く後続のピクチャにおいて、イントラ予測されたブロックによってコーディングされた領域は、一貫した方向に(たとえば、左から右に)移動する。このメカニズムは、インター予測されたブロックを含むダーティ領域を縮小させる。それぞれの後続のピクチャに関して、前のピクチャのクリーン領域と同じ位置にある領域は、インター予測によってコーディングされることが可能であり、これは、クリーン/リフレッシュ済み領域のサイズを大きくする。現在のピクチャのクリーン領域は、参照ピクチャ内のクリーン領域からの参照ブロックにのみインター予測を使用し得る。

【0101】

HEVCを使用するビデオシステムは、リカバリポイントSEIメッセージおよび領域リフレッシュ情報SEIメッセージを使用することによって非標準的にGDRをサポートし得る。そのようなSEIメッセージは、GDRがどのようにして実行されるかを定義しない可能性があるが、(たとえば、リカバリポイントSEIメッセージ内で)GDR期間内の最初のピクチャおよび最後のピクチャを示し、(領域リフレッシュ情報SEIメッセージ内で)リフレッシュされる領域を示すためのメカニズムを提供し得る。GDRは、制約イントラ予測(CIP: constraint intra-prediction)および動きベクトルに関するエンコーダの制約を使用することによって実行され得る。CIPは、イントラコーディングされる領域が未リフレッシュ領域からのサンプルを参照しないことを保証するので、イントラコーディングされる領域をコーディングするために使用され得る。CIPは、関連する制約がリフレッシュ済み領域内のイントラコーディングされるブロックとピクチャ内のすべてのイントラコーディングされるブロックとの両方に適用されるので、コーディングの性能の低下を引き起こし得る。動きベクトルに関するエンコーダの制約は、エンコーダに対してリフレッシュ済み領域の外にある参照ピクチャ内のいかなるサンプルの使用も制限することによって適用され得る。そのような制約は、最適でない動き探索をもたらし得る。図7は、GDRをサポートするためにエンコーダの制限をした結果として生じる例示的な最適でない動き探索を示す。動き探索プロセス中、エンコーダは、リフレッシュ済み領域の外にある参照ブロックのいずれかのサンプルを参照するいかなる動きベクトルも選択することを防止される。この条件は、たとえ参照ブロックがレート歪みコストの基準に従って最良の参照ブロックであるときでも維持される。

【0102】

CIPおよびエンコーダの制約の手法を使用することに基づくGDRの例示的な実装は、以下のようにまとめられ得る。イントラ予測モードが、列に基づいてコーディングユニットに対して強制される。制約されたイントラ予測が、イントラ予測されたコーディングユニットの再構築を保証するために有効化される。動きベクトルは、フィルタエラーの広がりを防止するために6ピクセルなどの追加的な余裕を考慮に入れながら、リフレッシュされたエリア内を指すように制約される。前の参照ピクチャは、イントラ予測された列を再ループするときに削除され得る。GDRの別の例示的な実装は、GDR期間内の最初のピクチャおよび最後のピクチャとして使用されるピクチャを示すために使用され得る。この例は、以下のようにまとめられ得る。NALユニットタイプがリカバリポイントインジケーションであるNALユニットが、非ビデオコーディングレイヤ(VCL)NALユニットとして使用され得る。NALユニットのペイロードは、GDR期間内の最後のピクチャのPOC値を導出するために使用され得る情報を指定するためのシンタックス要素を含む。タイプがリカバリポイントインジケーションである非VCL NALユニットを含むアクセスユニットは、リカバリポイント開始(Recovery Point Begin)(RBP)アクセスユニットと呼ばれることがある。RBPアクセスユニット内のピクチャは、RBPピクチャと呼ばれる。復号プロセスは、RBP AUから開始し得る。復号がRBP AUから始まるとき、最後のピクチャ以外のGDR期間内のピクチャは、表示のために出力されない。

【0103】

例示的な実装において、GRAを実装するためにVVCを使用するビデオコーディングシステムは、コーディングされたビデオシーケンス(CVS)が完全にイントラコーディングされるわけではないGRAピクチャから開始することを可能にするために以下の要素を使用し得る。SPS内のgra_enabled_flagが、GRAピクチャが存在し得るか否かを指定してもよい。GRA_NUTは、GRAピクチャを示すNALユニットタイプである。スライスヘッダ内のrecovery_poc_cntが、対応するピクチャがリカバリピクチャであり、したがって、ピクチャが新しいCVSを開始し、リカバリピクチャおよび後続のピクチャがGRA期間内のピクチャに基づいて正しく復号され得ることを指定してもよい。CVSは、CRAピクチャの後にCVSを開始するのと同様にしてGRAピクチャから開始し得る。

【0104】

上述の態様は、特定の問題を含む。たとえば、GRAピクチャを使用するVVCの実装は、HRDパラメータを指定すること、およびGRAピクチャを含むビットストリームに関するHRD準拠動作を定義することをサポートしない可能性がある。結果として、そのようなビットストリームに関する復号能力の要件は、たとえば、GRAピクチャから始まるビットストリームに関してはっきりしない可能性がある。

【0105】

概して、本開示は、GDRピクチャを含むビデオビットストリームのためのビットストリーム準拠メカニズムの指定をサポートするための方法を説明する。たとえば、そのようなサポートは、そのようなビットストリームのためにHRDを管理するためのメカニズムの定義によって実現され得る。本明細書において使用される技術の説明は、VVCの実装に基づくが、その他のビデオコーデック仕様にも当てはまり得る。

【0106】

上述の問題のうちの1つ以上は、以下のように解決され得る。たとえば、本開示は、HRDパラメータを指定し、GRAピクチャを含むビットストリームに関して実行され得るHRD準拠動作を定義することを可能にする手法を含む。たとえば、いつHRDパラメータがCVSに関して存在するかを示すために、NalHrdBpPresentFlagが1に等しいように設定され得るかまたはVclHrdBpPresentFlagが1に等しいように設定され得る。そのような場合、バッファリング期間SEIメッセージが、各GRAアクセスユニットに関連付けられ得る。さらに、バッファリング期間SEIメッセージは、HRDパラメータを含み得る。したがって、HRDパラメータが、GRAアクセスユニットのために利用可能にされ、HRD動作が、いずれのGRAアクセスユニットにおいても初期化し得る。たとえば、複数のGRAアクセスユニットを含むビデオビットストリームが、GRAピクチャをそれぞれ含み得る。ビットストリームは、デコーダによって復号され得る。GRAアクセスユニットの各々は、バッファリング期間SEIメッセージに関連付けられ得る。デコーダは、少なくとも、GRAアクセスユニットに関連するバッファリング期間SEIメッセージに基づいてGRAアクセスユニットのうちの1つからビデオビットストリームを復号し得る。別の例においては、エンコーダが、ビデオビットストリームを符号化し得る。たとえば、エンコーダは、各GRAピクチャをビットストリーム内の1つのアクセスユニットに符号化することによって複数のGRAピクチャを符号化し得る。GRAピクチャの各々に関して、エンコーダは、関連するバッファリング期間SEIメッセージを符号化し得る。1つ以上の例示的な実装が、以下に含まれる。

【0107】

例示的な全般的なスライスヘッダのシンタックスは、以下の通りである。

【表1】

【0108】

例示的なシーケンスの終わりのRBSPのセマンティクスは、以下の通りである。存在するとき、シーケンスの終わりのRBSPは、現在のアクセスユニットが復号順でコーディングされたビデオシーケンス内の最後のアクセスユニットであり、復号順でビットストリーム内の次の後続のアクセスユニット(もしあれば)がIRAPまたはGRAアクセスユニットであることを指定する。シーケンスの終わりのRBSPに関するデータビット列(SODB: string of data bits)およびRBSPのシンタックスの内容は、空である。

【0109】

例示的な全般的なスライスヘッダのセマンティクスは、以下の通りである。存在するとき、スライスヘッダのシンタックス要素slice_pic_parameter_set_id、slice_pic_order_cnt_lsb、no_output_of_prior_pics_flag、およびslice_temporal_mvp_enabled_flagの各々の値は、コーディングされたピクチャのすべてのスライスヘッダにおいて同じであってよい。no_output_of_prior_pics_flagは、ビットストリーム内の最初のピクチャではないコーディングされたビデオシーケンス開始(CVSS: coded video sequence start)ピクチャの復号後の復号ピクチャバッファ内の既に復号されたピクチャの出力に影響を与え得る。

【0110】

現在のピクチャの復号前のDPBからのピクチャの削除のための例示的なメカニズムは、以下の通りである。現在のピクチャがピクチャ0ではないCVSSピクチャであるとき、以下の順序付けられたステップが適用され得る。変数NoOutputOfPriorPicsFlagが、以下のようにテスト対象のデコーダに関して導出され得る。アクティブなSPSから導出されたpic_width_in_luma_samples、pic_height_in_luma_samples、chroma_format_idc、separate_colour_plane_flag、bit_depth_luma_minus8、bit_depth_chroma_minus8、またはsps_max_dec_pic_buffering_minus1[ HighestTid ]の値が前のピクチャに関してアクティブなSPSからそれぞれ導出されたpic_width_in_luma_samples、pic_height_in_luma_samples、chroma_format_idc、separate_colour_plane_flag、bit_depth_luma_minus8、bit_depth_chroma_minus8、またはsps_max_dec_pic_buffering_minus1[ HighestTid ]の値と異なる場合、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagの値とは無関係にテスト対象のデコーダによって1に設定され得る(しかし、設定されるべきでない)。no_output_of_prior_pics_flagに等しいようにNoOutputOfPriorPicsFlagを設定することがこれらの条件下では好ましい可能性があるが、テスト対象のデコーダは、この場合、NoOutputOfPriorPicsFlagを1に設定することを可能にされる。そうでない場合、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagに等しいように設定され得る。NoOutputOfPriorPicsFlagの値が1に等しいときに、DPB内のすべてのピクチャ記憶バッファがそれらが含むピクチャの出力なしに空にされ、DPB満杯(DPB fullness)が0に等しいように設定されるように、テスト対象のデコーダに関して導出されたNoOutputOfPriorPicsFlagの値が、HRDのために適用される。

【0111】

例示的なビットストリームの準拠は、以下の通りである。ビットストリーム内の最初のコーディングされたピクチャは、IRAPピクチャ(たとえば、IDRピクチャもしくはCRAピクチャ)またはGRAピクチャであるべきである。

【0112】

DPBからのピクチャの例示的な出力および削除は、以下の通りである。現在のピクチャがピクチャ0ではないCVSSピクチャである場合、以下の順序付けられたステップが適用され得る。変数NoOutputOfPriorPicsFlagが、以下のようにテスト対象のデコーダに関して導出され得る。アクティブなSPSから導出されたpic_width_in_luma_samples、pic_height_in_luma_samples、chroma_format_idc、separate_colour_plane_flag、bit_depth_luma_minus8、bit_depth_chroma_minus8、またはsps_max_dec_pic_buffering_minus1[ HighestTid ]の値が前のピクチャに関してアクティブなSPSからそれぞれ導出されたpic_width_in_luma_samples、pic_height_in_luma_samples、chroma_format_idc、separate_colour_plane_flag、bit_depth_luma_minus8、bit_depth_chroma_minus8、またはsps_max_dec_pic_buffering_minus1[ HighestTid ]の値と異なる場合、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagの値とは無関係にテスト対象のデコーダによって1に設定され得る(しかし、設定されるべきでない)。no_output_of_prior_pics_flagに等しいようにNoOutputOfPriorPicsFlagを設定することがこれらの条件下では好ましいが、テスト対象のデコーダは、この場合、NoOutputOfPriorPicsFlagを1に設定することを可能にされる。そうでない場合、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagに等しいように設定され得る。

【0113】

テスト対象のデコーダに関して導出されたNoOutputOfPriorPicsFlagの値が、以下のようにHRDのために適用され得る。NoOutputOfPriorPicsFlagが1に等しい場合、DPB内のすべてのピクチャ記憶バッファが、それらが含むピクチャの出力なしに空にされてよく、DPB満杯が、0に等しいように設定されてよい。そうでない場合(NoOutputOfPriorPicsFlagが0に等しい)、出力のために必要とされないおよび参照のために使用されないものとしてマーキングされるピクチャを含むすべてのピクチャ記憶バッファが、(出力なしに)空にされてよく、DPB内のすべての空でないピクチャ記憶バッファが、バンピング(bumping)プロセスを繰り返し呼び出すことによって空にされてよく、DPB満杯が、0に等しいように設定されてよい。

【0114】

例示的なバッファリング期間SEIメッセージのセマンティクスは、以下の通りである。バッファリング期間SEIメッセージの存在は、以下のように指定され得る。NalHrdBpPresentFlagが1に等しいかまたはVclHrdBpPresentFlagが1に等しい場合、CVS内の各アクセスユニットに関して以下が適用され得る。アクセスユニットがIRAPまたはGRAアクセスユニットである場合、動作点(operation point)に適用可能なバッファリング期間SEIメッセージが、アクセスユニットに関連付けられ得る。そうではなく、アクセスユニットがnotDiscardablePicを含む場合、動作点に適用可能なバッファリング期間SEIメッセージが、アクセスユニットに関連付けられる可能性がありまたは関連付けられない可能性がある。それ以外の場合、アクセスユニットは、動作点に適用可能なバッファリング期間SEIメッセージに関連付けられない可能性がある。そうでない場合(NalHrdBpPresentFlagとVclHrdBpPresentFlagとが両方とも0に等しい)、CVS内のアクセスユニットは、バッファリング期間SEIメッセージに関連付けられない可能性がある。現在のピクチャがバッファリング期間SEIメッセージを含み、concatenation_flagが1に等しいとき、現在のピクチャに関するcpb_removal_delay_minus1は、使用されない可能性がある。上述の制約は、状況によっては、接合点のIRAPまたはGRAピクチャに関するバッファリング期間SEIメッセージ内でconcatenation_flagの値を0から1に変更することによって(参照構造を使用する)ビットストリームを接合することを可能にし得る。concatenation_flagが0に等しいとき、上述の制約は、ピクチャprevNonDiscardablePicの喪失を検出する方法として、制約が満たされるかどうかをデコーダが調べることを可能にする。

【0115】

例示的なピクチャタイミングSEIメッセージのセマンティクスは、以下の通りである。1に等しいno_output_of_prior_pics_flagを有するかまたは1に等しいと推測されるCVSSピクチャよりも復号順で前にあるためにバンピングプロセスによって出力されないピクチャに関して、dpb_output_delayから導出される出力時間は、同じCVS内のすべてのピクチャに関連してPicOrderCntValの値が増加するにつれて増加していてもよい。

【0116】

図9は、例示的なビデオコーディングデバイス900の概略図である。ビデオコーディングデバイス900は、本明細書において説明されるように開示された例/実施形態を実装するのに好適である。ビデオコーディングデバイス900は、ダウンストリームポート920、アップストリームポート950、ならびに/またはネットワークを介して上流におよび/もしくは下流にデータを伝達するための送信機および/もしくは受信機を含むトランシーバユニット(Tx/Rx)910を含む。ビデオコーディングデバイス900は、データを処理するための論理ユニットおよび/または中央演算処理装置(CPU)を含むプロセッサ930と、データを記憶するためのメモリ932とをさらに含む。ビデオコーディングデバイス900は、電気、光、またはワイヤレス通信ネットワークを介したデータの通信のためにアップストリームポート950および/またはダウンストリームポート920に結合された電気、光-電気(OE)構成要素、電気-光(EO)構成要素、および/またはワイヤレス通信構成要素も含み得る。ビデオコーディングデバイス900は、ユーザにおよびユーザからデータを伝達するための入力および/または出力(I/O)デバイス960も含み得る。I/Oデバイス960は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカなどの出力デバイスを含み得る。I/Oデバイス960は、キーボード、マウス、トラックボールなどの入力デバイス、および/またはそのような出力デバイスとインタラクションするための対応するインターフェースも含み得る。

【0117】

プロセッサ930は、ハードウェアおよびソフトウェアによって実装される。プロセッサ930は、1つ以上のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号プロセッサ(DSP)として実装され得る。プロセッサ930は、ダウンストリームポート920、Tx/Rx 910、アップストリームポート950、およびメモリ932と通信する。プロセッサ930は、コーディングモジュール914を含む。コーディングモジュール914は、GDR 600および/またはビットストリーム800を使用し得る、方法100、1000、および1100などの本明細書において説明される開示される実施形態を実装する。コーディングモジュール914は、本明細書において説明される任意のその他の方法/メカニズムも実装し得る。さらに、コーディングモジュール914は、コーデックシステム200、エンコーダ300、デコーダ400、および/またはHRD 500を実装し得る。たとえば、コーディングモジュール914は、GDRピクチャによってBP SEIメッセージに関連付けられ得る。さらに、コーディングモジュール914は、ピクチャに関連するヘッダ内でPOC LSB値をリカバリピクチャ順序カウント値よりも前に配置し得る。したがって、コーディングモジュール914は、ビデオデータをコーディングするときにビデオコーディングデバイス900に追加的な機能および/またはコーディングの効率を提供させる。したがって、コーディングモジュール914は、ビデオコーディングデバイス900の機能性を高め、ビデオコーディング技術に固有の問題に対処する。さらに、コーディングモジュール914は、異なる状態へのビデオコーディングデバイス900の転換をもたらす。代替的に、コーディングモジュール914は、メモリ932に記憶され、プロセッサ930によって実行される命令として(たとえば、非一時的媒体に記憶されたコンピュータプログラム製品)として実装され得る。

【0118】

メモリ932は、ディスク、テープドライブ、ソリッドステートドライブ、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、フラッシュメモリ、3値連想メモリ(TCAM: ternary content-addressable memory)、スタティックランダムアクセスメモリ(SRAM)などの1つ以上のメモリの種類を含む。メモリ932は、プログラムが実行するために選択されるときにそのようなプログラムを記憶するためならびにプログラムの実行中に読まれる命令およびデータを記憶するためのオーバーフローデータストレージデバイス(over-flow data storage device)として使用され得る。

【0119】

図10は、HRD 500などのHRDを初期化しながら、GDR 600などのGDRを使用するビデオシーケンスをビットストリーム800などのビットストリームに符号化する例示的な方法1000の流れ図である。方法1000は、方法100を実行するときにコーデックシステム200、エンコーダ300、および/またはビデオコーディングデバイス900などのエンコーダによって使用され得る。

【0120】

方法1000は、エンコーダが複数のピクチャを含むビデオシーケンスを受信し、たとえば、ユーザ入力に基づいてそのビデオシーケンスをビットストリームに符号化すると決定するときに開始し得る。ステップ1001において、エンコーダが、ピクチャを含むGDR AUおよびGDR AUに関連するBP SEIメッセージをビットストリームに符号化し得る。たとえば、GDR AU内のピクチャは、GDRピクチャであってよい。さらに、GDRピクチャは、インター予測によってコーディングされた領域およびイントラ予測によってコーディングされた領域を含み得る。特定の例として、インター予測によってコーディングされた領域は、ダーティ領域である可能性があり、イントラ予測によってコーディングされた領域は、クリーン領域である可能性がある。BP SEIメッセージは、HRDパラメータを含み得る。HRDパラメータと、したがって、BP SEIメッセージとは、復号順でビットストリーム内のGDR AUの位置におけるHRDの初期化のために使用され得る初期CPB削除遅延を含んでよい。また、HRDパラメータは、デコーダがビットストリームを復号することができることを示す効果を持ち得る。

【0121】

ステップ1003において、エンコーダが、GDRピクチャに関連するヘッダをビットストリームに符号化し得る。ヘッダは、スライスヘッダ、ピクチャヘッダ、またはこれらの組み合わせを含み得る。エンコーダは、ピクチャがGDRピクチャであるとき、GDR AU内のピクチャに関するヘッダにおいて先行ピクチャ出力なしフラグを設定し得る。先行ピクチャ出力なしフラグは、リカバリポイントピクチャよりも前にあるGDR期間内のピクチャがデコーダにおいて出力されることを防止し得る。エンコーダは、ヘッダ内のPOC LSB値およびリカバリPOC値を設定することもできる。POC LSB値がデコーダにおいてリカバリPOC値よりも前に解析され得るように、POC LSB値は、ピクチャに関連するヘッダ内でリカバリPOC値の前に配置され得る。

【0122】

ステップ1005において、エンコーダが、BP SEIメッセージに基づいてHRDを初期化し得る。たとえば、HRDは、HRDにおける動作を定義するためにHRDパラメータを使用し得る。さらに、HRDは、GDRピクチャとBP SEIメッセージとの間の関連付けのおかげで、GDRピクチャに到達すると初期化され得る。ステップ1007において、エンコーダが、たとえば、HRDパラメータに基づいてHRDを使用してビットストリームに対して1つ以上のHRDの準拠のテストを実行し得る。次いで、エンコーダは、ステップ1009において、デコーダに伝達するためにビットストリームを記憶し得る。

【0123】

図11は、HRD 500などのHRDがビットストリームが準拠するビットストリームであることを示したときにビットストリーム800などのビットストリームからGDR 600などのGDRを使用するビデオシーケンスを復号する例示的な方法1100の流れ図である。方法1100は、方法100を実行しているときにコーデックシステム200、デコーダ400、および/またはビデオコーディングデバイス900などのデコーダによって使用され得る。

【0124】

方法1100は、たとえば、方法1000の結果としてビデオシーケンスを表すコーディングされたデータのビットストリームをデコーダが受信し始めるときに開始し得る。ステップ1101において、デコーダが、ビットストリームを受信し得る。ビットストリームは、GDR AU、GDR AUに関連するヘッダ、およびGDR AUに関連するBP SEIメッセージを含み得る。ヘッダは、スライスヘッダおよび/またはピクチャヘッダであってよい。たとえば、GDR AU内のピクチャは、GDRピクチャであってよい。さらに、GDRピクチャは、インター予測によってコーディングされた領域およびイントラ予測によってコーディングされた領域を含み得る。特定の例として、インター予測によってコーディングされた領域は、ダーティ領域である可能性があり、イントラ予測によってコーディングされた領域は、クリーン領域である可能性がある。BP SEIメッセージは、HRDパラメータを含み得る。HRDパラメータと、したがって、BP SEIメッセージとは、復号順でビットストリーム内のGDR AUの位置におけるエンコーダでのHRDの初期化のために使用され得る初期CPB削除遅延を含んでよい。HRDパラメータは、デコーダがビットストリームを復号することができることをデコーダに示し得る。ヘッダは、先行ピクチャ出力なしフラグを含み得る。先行ピクチャ出力なしフラグは、GDR AU内のGDRピクチャに関するヘッダにおいて設定され得る。先行ピクチャ出力なしフラグが設定されるとき、デコーダは、部分的にダーティなデータに基づいて再構築される不完全なピクチャを表示することを防止するために、表示するためにリカバリポイントピクチャの前にあるGDR期間内のピクチャを出力することを避ける。ヘッダは、GDRピクチャに関するPOC LSB値およびリカバリPOC値も含み得る。POC LSB値がリカバリPOC値よりも前に解析され得るように、POC LSB値は、ピクチャに関連するヘッダ内でリカバリPOC値の前に配置され得る。したがって、デコーダは、GDRピクチャに関するPOC LSB値と、関連するリカバリポイントピクチャに関するリカバリPOC値との両方を解析し、解決することができる。

【0125】

ステップ1103において、デコーダが、GDR AU内のピクチャ、リカバリポイントピクチャ、SEIメッセージ、および/または対応するビデオシーケンスを復号し得る。また、デコーダは、ステップ1105において、復号されたビデオシーケンスの一部として表示するためにピクチャを転送し得る。

【0126】

図12は、HRD 500などのHRDを使用しながら、GDR 600などのGDRを使用するビデオシーケンスをビットストリーム800などのビットストリームにコーディングするための例示的なシステム1200の概略図である。システム1200は、コーデックシステム200、エンコーダ300、デコーダ400、および/またはビデオコーディングデバイス900などのエンコーダおよびデコーダによって実装され得る。さらに、システム1200は、方法100、1000、および/または1100を実施するときに使用され得る。

【0127】

システム1200は、ビデオエンコーダ1202を含む。ビデオエンコーダ1202は、GDR AUおよびGDR AUに関連するBP SEIメッセージをビットストリームに符号化するための符号化モジュール1203を含む。ビデオエンコーダ1202は、BP SEIメッセージに基づいて仮想参照デコーダ(HRD)を初期化するための初期化モジュール1204をさらに含む。ビデオエンコーダ1202は、HRDを使用してビットストリームに対してHRDの準拠のテストを実行するためのHRDモジュール1205をさらに含む。ビデオエンコーダ1202は、デコーダに伝達するためのビットストリームを記憶するための記憶モジュール1206をさらに含む。ビデオエンコーダ1202は、ビットストリームをビデオデコーダ1210に送信するための送信モジュール1207をさらに含む。ビデオエンコーダ1202は、方法1000のステップのいずれかを実行するようにさらに構成され得る。

【0128】

システム1200は、ビデオデコーダ1210も含む。ビデオデコーダ1210は、GDR AUおよびGDR AUに関連するBP SEIメッセージを含むビットストリームを受信するための受信モジュール1211を含む。ビデオデコーダ1210は、GDR AU内のピクチャおよびSEIメッセージを復号するための復号モジュール1213をさらに含む。ビデオデコーダ1210は、復号されたビデオシーケンスの一部として表示するためのピクチャを転送するための転送モジュール1215をさらに含む。ビデオデコーダ1210は、方法1100のステップのいずれかを実行するようにさらに構成され得る。

【0129】

第1の構成要素は、第1の構成要素と第2の構成要素との間の回線、トレース、または別の媒体を除いて仲介構成要素がないとき、第2の構成要素に直接結合される。第1の構成要素は、第1の構成要素と第2の構成要素との間の回線、トレース、または別の媒体以外の仲介構成要素があるとき、第2の構成要素に間接的に結合される。用語「結合される」およびその変化形は、直接的に結合されると間接的に結合されるとの両方を含む。用語「約」の使用は、そうでないことが述べられない限り、後ろの数の±10%を含む範囲を意味する。

【0130】

本明細書において説明された例示的な方法のステップは、必ずしも説明された順序で実行されることを求められず、そのような方法のステップの順序は、例示的であるに過ぎないと理解されるべきであることも理解されたい。同様に、さらなるステップが、そのような方法に含まれる可能性があり、特定のステップが、本開示の様々な実施形態に一致する方法においては省略されるかまたは組み合わされる可能性がある。

【0131】

いくつかの実施形態が本開示において与えられたが、開示されたシステムおよび方法は、本開示の精神または範囲を逸脱することなく多くのその他の特定の形態で具現化される可能性があることが理解されるであろう。これらの例は、例示的であって限定的でないと考えられるべきであり、意図は、本明細書において与えられた詳細に限定されるべきでない。たとえば、様々な要素もしくは構成要素が、組み合わされるかもしくは別のシステムに統合される可能性があり、または特定の特徴が、省略されるかもしくは実装されない可能性がある。

【0132】

加えて、様々な実施形態において分離しているまたは別々であるものとして説明され、図示された技術、システム、サブシステム、および方法は、本開示の範囲を逸脱することなくその他のシステム、構成要素、技術、または方法と組み合わされるかまたは統合される可能性がある。変更、置き換え、および改変のその他の例が、当業者によって突き止められる可能性があり、本明細書において開示された精神および範囲を逸脱することなくなされる可能性がある。

【符号の説明】

【0133】

100 動作方法、方法
200 コーディングおよびデコーディング(コーデック)システム
201 区分けされたビデオ信号
211 全般的コーダ制御構成要素
213 変換・スケーリングおよび量子化構成要素
215 イントラピクチャ推定構成要素
217 イントラピクチャ予測構成要素
219 動き補償構成要素
221 動き推定構成要素
223 復号ピクチャバッファ構成要素
225 ループ内フィルタ構成要素
227 フィルタ制御分析構成要素
229 スケーリングおよび逆変換構成要素
231 ヘッダフォーマットおよびコンテキスト適応2値算術コーディング(CABAC)構成要素
300 ビデオエンコーダ
301 区分けされたビデオ信号
313 変換および量子化構成要素
317 イントラピクチャ予測構成要素
321 動き補償構成要素
323 復号ピクチャバッファ構成要素
325 ループ内フィルタ構成要素
329 逆変換および量子化構成要素
331 エントロピーコーディング構成要素
400 ビデオデコーダ、デコーダ
417 イントラピクチャ予測構成要素
421 動き補償構成要素
423 復号ピクチャバッファ構成要素
425 ループ内フィルタ構成要素
429 逆変換および量子化構成要素
433 エントロピー復号構成要素
500 HRD
541 仮想ストリームスケジューラ(HSS)
543 CPB
545 復号プロセス構成要素
547 DPB
549 出力クロッピング構成要素
551 ビットストリーム
553 復号可能ユニット(DU)
555 復号されたDU
556 参照ピクチャ
557 ピクチャ
559 出力クロッピング済みピクチャ
600 GDR
602 GDRピクチャ
604 トレーリングピクチャ
606 リカバリポイントピクチャ
608 CVS
610 リフレッシュ済み/クリーン領域
610A 第1の領域
610B 第2の領域
611 PPS
612 未リフレッシュ/ダーティ領域
621 GDR POC
622 リカバリPOC
623 POC
700 動き探索
702 現在のピクチャ
704 参照ピクチャ
705 リフレッシュ済み領域
706 リフレッシュ済み領域
708 未リフレッシュ領域
710 動きベクトル
712 参照ブロック
800 ビットストリーム
810 SPS
811 ピクチャパラメータセット(PPS)
815 スライスヘッダ
817 BP SEIメッセージ
820 画像データ
821 AU
823 ピクチャ、コーディングされたピクチャ
825 スライス
831 先行ピクチャ出力なしフラグ
833 POC LSB値
835 リカバリPOC値
836 HRDパラメータ
900 ビデオコーディングデバイス
910 トランシーバユニット(Tx/Rx)
914 コーディングモジュール
920 ダウンストリームポート
930 プロセッサ
932 メモリ
950 アップストリームポート
960 入力および/または出力(I/O)デバイス
1000 方法
1100 方法
1200 システム
1202 ビデオエンコーダ
1203 符号化モジュール
1204 初期化モジュール
1205 HRDモジュール
1206 記憶モジュール
1207 送信モジュール
1210 ビデオデコーダ
1211 受信モジュール
1213 復号モジュール
1215 転送モジュール

【図1】