JP7704810B2

JP7704810B2 - エンコーダ、デコーダ、および対応する方法

Info

Publication number: JP7704810B2
Application number: JP2023101903A
Authority: JP
Inventors: フヌ・ヘンドリー; イェ－クイ・ワン; ジエンレ・チェン
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2019-03-11
Filing date: 2023-06-21
Publication date: 2025-07-08
Anticipated expiration: 2040-03-11
Also published as: US20210409690A1; KR102809616B1; WO2020185957A1; CN113615175A; WO2020185956A1; US12407868B2; JP2024008969A; EP4432649A2; US20210409689A1; MX2021011038A; US20260012651A1; KR20210134390A; JP2022524810A; MX2021011014A; US12375728B2; EP4529159A1; JP2023160851A; US20260039876A1; US12238336B2; CN113924781A

Description

一般に、本開示は、ビデオコーディングにおける漸進的復号リフレッシュをサポートす
る技法を説明する。より詳細には、本開示は、イントラランダムアクセスポイント(IRAP:
intra random access point)ピクチャを使用する必要なく順次イントラリフレッシュがラ
ンダムアクセスを有効化することを可能とする。

比較的短いビデオを描くのに必要とされるビデオデータの量でさえ相当であり得、その
ことは、帯域幅容量が限定された通信ネットワークを横断してデータがストリーミングま
たは別の方法で通信されることになるときに困難をもたらす場合がある。したがって、ビ
デオデータは、一般に、現代の電気通信ネットワークを横断して通信される前に圧縮され
る。メモリリソースが限定されることがあるので、ビデオが記憶デバイス上に記憶される
ときも、ビデオのサイズが問題であり得る。ビデオ圧縮デバイスは、しばしば、ソースに
おいてソフトウェアおよび/またはハードウェアを使用して、送信または記憶の前にビデ
オデータをコーディングし、それによって、デジタルビデオ画像を描写するために必要と
されるデータの量を減らす。圧縮されたデータは、次いで、ビデオデータを復号するビデ
オ復元デバイスによって宛先において受信される。ネットワークリソースが限定され、よ
り高いビデオ品質の需要が絶えず増大すると、画像品質における犠牲をほとんど伴わずに
圧縮率を改善する、改善された圧縮および復元技法が望ましい。

第1の態様は、ビデオデコーダによって実施される、コーディングされたビデオビット
ストリームを復号する方法に関する。方法は、第1のフラグに対する値が外部入力によっ
て提供されるかどうかをビデオデコーダによって決定するステップと、第1のフラグに対
する値が外部入力によって提供されるとき、コーディングされたビデオビットストリーム
の中の漸進的復号リフレッシュ(GDR:gradual decoding refresh)ピクチャが出力されるこ
とを防止するために、第1のフラグを、外部入力によって提供される値に等しく、かつ第2
のフラグを第1のフラグに等しく、ビデオデコーダによって設定するステップと、GDRピク
チャをビデオデコーダによって復号するステップと、ビデオデコーダによってGDRピクチ
ャを復号ピクチャバッファ(DPB:decoded picture buffer)の中に記憶するステップとを含
む。

本方法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次
イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する
。第1のフラグに対する値が外部入力によって提供されるとき、漸進的復号リフレッシュ(
GDR)ピクチャが出力されることを防止するために、第1のフラグは外部入力によって提供
される値に等しく設定され、第2のフラグは第1のフラグに等しく設定される。外部入力は
、たとえば、ビデオデコーダのグラフィックユーザインターフェース(GUI)を介してユー
ザ(たとえば、ネットワークアドミニストレータ)から受け取られる入力であってもよい。
このようにして第1および第2のフラグを設定することは、潜在的にダーティなデータがデ
ィスプレイに出力されることを防止する。すなわち、第1および第2のフラグの値は、GDR
ピクチャからの潜在的にダーティなデータが出力されるかどうか、またはビデオデコーダ
が完全な同期を待ってデータを表示し始めるかどうかを制御する。ダーティなデータが出
力されることを制限するための能力を有することによって、ビデオコーディングにおける
コーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善され
る。実際問題として、改善されたビデオコーディングプロセスは、ビデオが送られ、受け
取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与え
る。

第1の態様それ自体に係る方法の第1の実装形式では、第1のフラグに対する値が外部入
力によって提供されるとき、漸進的復号リフレッシュ(GDR)ピクチャおよび出力順序でGDR
ピクチャとリカバリポイントピクチャとの間の任意のトレーリングピクチャが出力される
ことを防止するために、第1のフラグは外部入力によって提供される値に等しく、かつ第2
のフラグは第1のフラグに等しく設定される。

第1の態様それ自体または第1の態様の先行する任意の実装形式に係る方法の第2の実装
形式では、外部入力は、ビデオデコーダのグラフィックユーザインターフェース(GUI)で
あり、第1のフラグの値は、外部入力を使用してビデオデコーダのユーザによって提供さ
れる。

第1の態様それ自体または第1の態様の先行する任意の実装形式に係る方法の第3の実装
形式では、第1のフラグはHandleGdrAsCvsStartFlagと指定される。

第1の態様それ自体または第1の態様の先行する任意の実装形式に係る方法の第4の実装
形式では、GDRピクチャおよび出力順序でGDRピクチャとリカバリポイントピクチャとの間
の任意のトレーリングピクチャが出力されることを防止するために、第1のフラグおよび
第2のフラグの値は1に設定される。

第1の態様それ自体または第1の態様の先行する任意の実装形式に係る方法の第5の実装
形式では、第1のフラグに対する値が外部入力によって提供されないとき、第1のフラグの
値は0に設定される。

第2の態様は、復号デバイスに関する。復号デバイスは、コーディングされたビデオビ
ットストリームを受信するように構成された受信機と、受信機に結合されたメモリであっ
て、命令を記憶する、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは
、復号デバイスに、第1のフラグに対する値が外部入力によって提供されるかどうかを決
定することと、第1のフラグに対する値が外部入力によって提供されるとき、漸進的復号
リフレッシュ(GDR)ピクチャが出力されることを防止するために、第1のフラグを、外部入
力によって提供される値に等しく、かつ第2のフラグを第1のフラグに等しく設定すること
と、GDRピクチャを復号することと、GDRピクチャを復号ピクチャバッファ(DPB)の中に記
憶することとをさせるために、命令を実行するように構成される。

復号デバイスは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要な
く順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提
供する。第1のフラグに対する値が外部入力によって提供されるとき、漸進的復号リフレ
ッシュ(GDR)ピクチャが出力されることを防止するために、第1のフラグは外部入力によっ
て提供される値に等しく設定され、第2のフラグは第1のフラグに等しく設定される。外部
入力は、たとえば、ビデオデコーダのグラフィックユーザインターフェース(GUI)を介し
てユーザ(たとえば、ネットワークアドミニストレータ)から受け取られる入力であっても
よい。このようにして第1および第2のフラグを設定することは、潜在的にダーティなデー
タがディスプレイに出力されることを防止する。すなわち、第1および第2のフラグの値は
、GDRピクチャからの潜在的にダーティなデータが出力されるかどうか、またはビデオデ
コーダが完全な同期を待ってデータを表示し始めるかどうかを制御する。ダーティなデー
タが出力されることを制限するための能力を有することによって、ビデオコーディングに
おけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改
善される。実際問題として、改善されたビデオコーディングプロセスは、ビデオが送られ
、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザ
に与える。

第2の態様それ自体に係る復号デバイスの第1の実装形式では、第1のフラグに対する値
が外部入力によって提供されるとき、漸進的復号リフレッシュ(GDR)ピクチャおよび出力
順序でGDRピクチャとリカバリポイントピクチャとの間の任意のトレーリングピクチャが
出力されることを防止するために、第1のフラグは外部入力によって提供される値に等し
く、かつ第2のフラグは第1のフラグに等しく設定される。

第2の態様それ自体に係る復号デバイスの第2の実装形式では、外部入力は、ビデオデコ
ーダのグラフィックユーザインターフェース(GUI)であり、第1のフラグの値は、外部入力
を使用してビデオデコーダのユーザによって提供される。

第2の態様それ自体に係る復号デバイスの第3の実装形式では、第1のフラグはHandleGdr
AsCvsStartFlagと指定される。

第2の態様それ自体に係る復号デバイスの第4の実装形式では、GDRピクチャおよび出力
順序でGDRピクチャとリカバリポイントピクチャとの間の任意のトレーリングピクチャが
出力されることを防止するために、第1のフラグおよび第2のフラグの値は1に設定される
。

第2の態様それ自体に係る復号デバイスの第5の実装形式では、第1のフラグに対する値
が外部入力によって提供されないとき、第1のフラグの値は0に設定される。

第3の態様は、コーディング装置に関する。コーディング装置は、符号化すべきピクチ
ャを受信するか、または復号すべきビットストリームを受信するように構成された、受信
機と、受信機に結合された送信機であって、ビットストリームをデコーダへ送信するか、
または復号画像をディスプレイへ送信するように構成された、送信機と、受信機または送
信機のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成さ
れた、メモリと、メモリに結合されたプロセッサであって、本明細書で開示する方法のう
ちのいずれかを実行するために、メモリの中に記憶された命令を実行するように構成され
た、プロセッサとを含む。

コーディング装置は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必
要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法
を提供する。第1のフラグに対する値が外部入力によって提供されるとき、漸進的復号リ
フレッシュ(GDR)ピクチャが出力されることを防止するために、第1のフラグは外部入力に
よって提供される値に等しく設定され、第2のフラグは第1のフラグに等しく設定される。
外部入力は、たとえば、ビデオデコーダのグラフィックユーザインターフェース(GUI)を
介してユーザ(たとえば、ネットワークアドミニストレータ)から受け取られる入力であっ
てもよい。このようにして第1および第2のフラグを設定することは、潜在的にダーティな
データがディスプレイに出力されることを防止する。すなわち、第1および第2のフラグの
値は、GDRピクチャからの潜在的にダーティなデータが出力されるかどうか、またはビデ
オデコーダが完全な同期を待ってデータを表示し始めるかどうかを制御する。ダーティな
データが出力されることを制限するための能力を有することによって、ビデオコーディン
グにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べ
て改善される。実際問題として、改善されたビデオコーディングプロセスは、ビデオが送
られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユ
ーザに与える。

第3の態様それ自体に係るコーディング装置の第1の実装形式では、画像を表示するよう
に構成されたディスプレイをさらに備える。

第4の態様は、システムに関する。システムは、エンコーダと、エンコーダと通信して
いるデコーダとを含み、エンコーダまたはデコーダは、本明細書で開示する復号デバイス
、符号化デバイス、またはコーディング装置を含む。

システムは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順
次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供す
る。第1のフラグに対する値が外部入力によって提供されるとき、漸進的復号リフレッシ
ュ(GDR)ピクチャが出力されることを防止するために、第1のフラグは外部入力によって提
供される値に等しく設定され、第2のフラグは第1のフラグに等しく設定される。外部入力
は、たとえば、ビデオデコーダのグラフィックユーザインターフェース(GUI)を介してユ
ーザ(たとえば、ネットワークアドミニストレータ)から受け取られる入力であってもよい
。このようにして第1および第2のフラグを設定することは、潜在的にダーティなデータが
ディスプレイに出力されることを防止する。すなわち、第1および第2のフラグの値は、GD
Rピクチャからの潜在的にダーティなデータが出力されるかどうか、またはビデオデコー
ダが完全な同期を待ってデータを表示し始めるかどうかを制御する。ダーティなデータが
出力されることを制限するための能力を有することによって、ビデオコーディングにおけ
るコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善さ
れる。実際問題として、改善されたビデオコーディングプロセスは、ビデオが送られ、受
け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与
える。

第5の態様は、コーディングするための手段に関する。コーディングするための手段は
、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するよ
うに構成された、受信手段と、受信手段に結合された送信手段であって、ビットストリー
ムを復号手段へ送信するか、または復号画像を表示手段へ送信するように構成された、送
信手段と、受信手段または送信手段のうちの少なくとも1つに結合された記憶手段であっ
て、命令を記憶するように構成された、記憶手段と、記憶手段に結合された処理手段であ
って、本明細書で開示する方法のうちのいずれかを実行するために、記憶手段の中に記憶
された命令を実行するように構成された、処理手段とを含む。

コーディングするための手段は、イントラランダムアクセスポイント(IRAP)ピクチャを
使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能
とする技法を提供する。第1のフラグに対する値が外部入力によって提供されるとき、漸
進的復号リフレッシュ(GDR)ピクチャが出力されることを防止するために、第1のフラグは
外部入力によって提供される値に等しく設定され、第2のフラグは第1のフラグに等しく設
定される。外部入力は、たとえば、ビデオデコーダのグラフィックユーザインターフェー
ス(GUI)を介してユーザ(たとえば、ネットワークアドミニストレータ)から受け取られる
入力であってもよい。このようにして第1および第2のフラグを設定することは、潜在的に
ダーティなデータがディスプレイに出力されることを防止する。すなわち、第1および第2
のフラグの値は、GDRピクチャからの潜在的にダーティなデータが出力されるかどうか、
またはビデオデコーダが完全な同期を待ってデータを表示し始めるかどうかを制御する。
ダーティなデータが出力されることを制限するための能力を有することによって、ビデオ
コーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデ
ックに比べて改善される。実際問題として、改善されたビデオコーディングプロセスは、
ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリ
エンスをユーザに与える。

本開示のより完全な理解のために、添付図面および発明を実施するための形態とともに
理解される、以下の簡潔な説明を次に参照し、同様の参照番号は同様の部分を表す。

GDR技法を利用してもよい例示的なコーディングシステムを示すブロック図である。 GDR技法を実施してもよい例示的なビデオエンコーダを示すブロック図である。 GDR技法を実施してもよいビデオデコーダの一例を示すブロック図である。復号順序および提示順序における、リーディングピクチャ(leading picture)に対するIRAPピクチャと、トレーリングピクチャとの間の関係の描写である。漸進的復号リフレッシュ技法を示す図である。望ましくない動き探索を示す概略図である。本開示の一実施形態に係る、漸進的復号リフレッシュ技法を実施するように構成されたビデオビットストリームを示す図である。コーディングされたビデオビットストリームを復号する方法の一実施形態を示す図である。ビデオコーディングデバイスの概略図である。コーディングするための手段の一実施形態の概略図である。

図1は、本明細書で説明するようなビデオコーディング技法を利用してもよい例示的な
コーディングシステム10を示すブロック図である。図1に示すように、コーディングシス
テム10は、後で宛先デバイス14によって復号されるべき符号化ビデオデータを提供するソ
ースデバイス12を含む。詳細には、ソースデバイス12は、コンピュータ可読媒体16を介し
て宛先デバイス14にビデオデータを提供してもよい。ソースデバイス12および宛先デバイ
ス14は、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュー
タ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなど
の電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバ
イス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなど
を含む、幅広いデバイスのうちのいずれかを備えてもよい。場合によっては、ソースデバ
イス12および宛先デバイス14は、ワイヤレス通信のために装備されてもよい。

宛先デバイス14は、コンピュータ可読媒体16を介して、復号されるべき符号化ビデオデ
ータを受信してもよい。コンピュータ可読媒体16は、符号化ビデオデータをソースデバイ
ス12から宛先デバイス14に移動させることが可能な任意のタイプの媒体またはデバイスを
備えてもよい。一例では、コンピュータ可読媒体16は、ソースデバイス12が符号化ビデオ
データを宛先デバイス14へリアルタイムで直接送信することを可能にするための通信媒体
を備えてもよい。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従
って変調されてもよく、宛先デバイス14へ送信されてもよい。通信媒体は、無線周波数(R
F)スペクトルまたは1つ以上の物理伝送線路などの、任意のワイヤレスまたは有線の通信
媒体を備えてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワ
ーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネッ
トワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、またはソー
スデバイス12から宛先デバイス14への通信を容易にするために有用であり得る任意の他の
機器を含んでもよい。

いくつかの例では、符号化データは、出力インターフェース22から記憶デバイスに出力
されてもよい。同様に、符号化データは、入力インターフェースによって記憶デバイスか
らアクセスされてもよい。記憶デバイスは、ハードドライブ、Blu-rayディスク、デジタ
ルビデオディスク(DVD)、コンパクトディスク読取り専用メモリ(CD-ROM)、フラッシュメ
モリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するため
の任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされ
る様々なデータ記憶媒体のうちのいずれかを含んでもよい。さらなる一例では、記憶デバ
イスは、ソースデバイス12によって生成された符号化ビデオを記憶してもよいファイルサ
ーバまたは別の中間記憶デバイスに相当してもよい。宛先デバイス14は、ストリーミング
またはダウンロードを介して記憶デバイスからの記憶済みのビデオデータにアクセスして
もよい。ファイルサーバは、符号化ビデオデータを記憶すること、およびその符号化ビデ
オデータを宛先デバイス14へ送信することが可能な、任意のタイプのサーバであってもよ
い。例示的なファイルサーバは、(たとえば、ウェブサイト用の)ウェブサーバ、ファイル
転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカ
ルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準デ
ータ接続を通じて符号化ビデオデータにアクセスしてもよい。このことは、ファイルサー
バ上に記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(
たとえば、Wi-Fi接続)、有線接続(たとえば、デジタル加入者回線(DSL)、ケーブルモデム
など)、またはその両方の組み合わせを含んでもよい。記憶デバイスからの符号化ビデオ
データの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組み合わせで
あってもよい。

本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されるとは限らない。
本技法は、オーバージエアテレビ放送、ケーブルテレビ送信、衛星テレビ送信、動的適応
ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、デ
ータ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタル
ビデオの復号、または他の適用例などの、様々なマルチメディア適用例のうちのいずれか
をサポートするビデオコーディングに適用されてもよい。いくつかの例では、コーディン
グシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、
および/またはビデオ電話などの適用例をサポートするために、一方向または二方向のビ
デオ送信をサポートするように構成されてもよい。

図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出
力インターフェース22を含む。宛先デバイス14は、入力インターフェース28、ビデオデコ
ーダ30、およびディスプレイデバイス32を含む。本開示によれば、ソースデバイス12のビ
デオエンコーダ20および/または宛先デバイス14のビデオデコーダ30は、ビデオコーディ
ングのための技法を適用するように構成されてもよい。他の例では、ソースデバイスおよ
び宛先デバイスは、他の構成要素または構成を含んでもよい。たとえば、ソースデバイス
12は、外部カメラなどの外部のビデオソースからビデオデータを受信してもよい。同様に
、宛先デバイス14は、統合型ディスプレイデバイスを含むのではなく、外部のディスプレ
イデバイスとインターフェースしてもよい。

図1の図示したコーディングシステム10は一例にすぎない。ビデオコーディングのため
の技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行されて
もよい。本開示の技法は一般にビデオコーディングデバイスによって実行されるが、技法
はまた、通常、「コーデック」と呼ばれる、ビデオエンコーダ/デコーダによって実行さ
れてもよい。その上、本開示の技法はまた、ビデオプリプロセッサによって実行されても
よい。ビデオエンコーダおよび/またはデコーダは、グラフィックス処理ユニット(GPU)ま
たは類似のデバイスであってもよい。

ソースデバイス12および宛先デバイス14は、宛先デバイス14への送信のために、コーデ
ィングされたビデオデータをソースデバイス12が生成する、そのようなコーディングデバ
イスの例にすぎない。いくつかの例では、ソースデバイス12および宛先デバイス14は、ソ
ースデバイス12および宛先デバイス14の各々がビデオ符号化および復号構成要素を含むよ
うに、実質的に対称的に動作してもよい。したがって、コーディングシステム10は、たと
えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデ
オ電話のために、ビデオデバイス12、14の間での一方向または二方向のビデオ送信をサポ
ートしてもよい。

ソースデバイス12のビデオソース18は、ビデオカメラ、前にキャプチャされたビデオを
含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信す
るためのビデオフィードインターフェースなどの、ビデオキャプチャデバイスを含んでも
よい。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラ
フィックスベースのデータ、またはライブビデオと、アーカイブされたビデオと、コンピ
ュータ生成されたビデオとの組み合わせを生成してもよい。

場合によっては、ビデオソース18がビデオカメラであるとき、ソースデバイス12および
宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成してもよい。しかし
ながら、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能
であってもよく、ワイヤレスおよび/または有線の適用例に適用されてもよい。各場合に
おいて、キャプチャ、プリキャプチャ、またはコンピュータ生成されたビデオが、ビデオ
エンコーダ20によって符号化されてもよい。符号化されたビデオ情報は、次いで、出力イ
ンターフェース22によってコンピュータ可読媒体16上に出力されてもよい。

コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくは有線ネットワーク送
信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク
、デジタルビデオディスク、Blu-rayディスク、もしくは他のコンピュータ可読媒体など
の、記憶媒体(すなわち、非一時的記憶媒体)を含んでもよい。いくつかの例では、ネット
ワークサーバ(図示せず)が、たとえば、ネットワーク送信を介して、ソースデバイス12か
ら符号化ビデオデータを受信してもよく、宛先デバイス14に符号化ビデオデータを提供し
てもよい。同様に、ディスクスタンピング設備などの媒体製造設備のコンピューティング
デバイスが、ソースデバイス12から符号化ビデオデータを受信してもよく、符号化ビデオ
データを含むディスクを製造してもよい。したがって、様々な例では、コンピュータ可読
媒体16は、様々な形態の1つ以上のコンピュータ可読媒体を含むものと理解されてもよい
。

宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信
する。コンピュータ可読媒体16の情報は、ブロックおよび他のコーディングされたユニッ
ト、たとえば、グループオブピクチャ(GOP:group of pictures)の特性および/または処理
を記述するシンタックス要素を含む、ビデオエンコーダ20によって規定されるシンタック
ス情報を含んでもよく、シンタックス情報はまた、ビデオデコーダ30によって使用される
。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT
)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプ
レイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスの
うちのいずれかを備えてもよい。

ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディン
グ(HEVC)規格などのビデオコーディング規格に従って動作してもよく、HEVCテストモデル
(HM)に適合してもよい。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替
として、ムービングピクチャエキスパートグループ(MPEG)-4パート10と呼ばれる、国際電
気通信連合電気通信規格セクタ(ITU-T)H.264規格、アドバンストビデオコーディング(AVC
)、H.265/HEVC、またはそのような規格の拡張などの、他のプロプライエタリ規格または
業界規格に従って動作してもよい。しかしながら、本開示の技法は、いかなる特定のコー
ディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG-2およびITU-
T H.263を含む。図1に示さないが、いくつかの態様では、ビデオエンコーダ20およびビデ
オデコーダ30は各々、オーディオエンコーダおよびデコーダと統合されてもよく、共通の
データストリームまたは別個のデータストリームの中のオーディオとビデオの両方の符号
化を処理するための、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット、ま
たは他のハードウェアおよびソフトウェアを含んでもよい。適用可能な場合、MUX-DEMUX
ユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコ
ル(UDP)などの他のプロトコルに適合してもよい。

ビデオエンコーダ20およびビデオデコーダ30は各々、1つ以上のマイクロプロセッサ、
デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブ
ルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、また
はそれらの任意の組み合わせなどの、様々な好適なエンコーダ回路構成のうちのいずれか
として実装されてもよい。本技法が部分的にソフトウェアで実装されるとき、デバイスは
、好適な非一時的コンピュータ可読媒体の中にソフトウェアのための命令を記憶してもよ
く、本開示の技法を実行するために、1つ以上のプロセッサを使用してハードウェアで命
令を実行してもよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つ以上の
エンコーダまたはデコーダの中に含められてもよく、それらのいずれも、組み合わせられ
たエンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中で統合されて
もよい。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回
路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを
備えてもよい。

図2は、ビデオコーディング技法を実施してもよいビデオエンコーダ20の一例を示すブ
ロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラ
およびインターコーディングを実行してもよい。イントラコーディングは、所与のビデオ
フレーム内またはピクチャ内のビデオにおける空間的な冗長性を低減または除去するため
に、空間予測に依拠する。インターコーディングは、ビデオシーケンスの隣接するフレー
ム内またはピクチャ内のビデオにおける時間的な冗長性を低減または除去するために、時
間予測に依拠する。イントラモード(Iモード)とは、いくつかの空間ベースのコーディン
グモードのうちのいずれかを指してもよい。単方向予測(単予測とも呼ばれる)(Pモード)
または双予測(bi-prediction)(双予測(bi prediction)とも呼ばれる)(Bモード)などのイ
ンターモードとは、いくつかの時間ベースのコーディングモードのうちのいずれかを指し
てもよい。

図2に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在
ビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット4
0、参照フレームメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、および
エントロピーコーディングユニット56を含む。次に、モード選択ユニット40は、動き補償
ユニット44、動き推定ユニット42、イントラ予測(intra-prediction)(イントラ予測(intr
a prediction)とも呼ばれる)ユニット46、および区分ユニット48を含む。ビデオブロック
再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58、逆変換ユニット60、
および加算器62を含む。ブロック境界をフィルタ処理して再構成ビデオからブロッキネス
アーティファクトを除去するために、デブロッキングフィルタ(図2に示さず)も含まれて
もよい。所望される場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタ
処理することになる。デブロッキングフィルタに加えて、(ループ内またはループ後の)追
加のフィルタも使用されてもよい。そのようなフィルタは、簡潔のために図示されないが
、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理してもよい
。

符号化プロセス中、ビデオエンコーダ20は、コーディングされるべきビデオフレームま
たはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され
てもよい。動き推定ユニット42および動き補償ユニット44は、1つ以上の参照フレームの
中の1つ以上のブロックに対する受信ビデオブロックのインター予測コーディングを実行
して、時間予測を行う。イントラ予測ユニット46は、代替的に、コーディングされるべき
ブロックと同じフレームまたはスライスの中の1つ以上の隣接ブロックに対する受信ビデ
オブロックのイントラ予測コーディングを実行して、空間予測を行ってよい。ビデオエン
コーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択
するために、複数のコーディングパスを実行してもよい。

その上、区分ユニット48は、前のコーディングパスにおける、前の区分方式の評価に基
づいて、ビデオデータのブロックをサブブロックに区分してもよい。たとえば、区分ユニ
ット48は、最初にフレームまたはスライスを最大コーディングユニット(LCU:largest cod
ing unit)に区分してもよく、レートひずみ分析(たとえば、レートひずみ最適化)に基づ
いてLCUの各々をサブコーディングユニット(サブCU)に区分してもよい。モード選択ユニ
ット40は、サブCUへのLCUの区分を示す4分木データ構造をさらに生成してもよい。4分木
のリーフノードCUは、1つ以上の予測ユニット(PU:prediction unit)および1つ以上の変換
ユニット(TU:transform unit)を含んでもよい。

本開示は、HEVCのコンテキストにおけるCU、PU、もしくはTU、または他の規格のコンテ
キストにおける類似のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそ
れらのサブブロック)のうちのいずれかを指すために、「ブロック」という用語を使用す
る。CUは、コーディングノード、PU、およびコーディングノードに関連するTUを含む。CU
のサイズは、コーディングノードのサイズに対応し、形状が正方形である。CUのサイズは
、8×8ピクセルから、最大値が64×64ピクセル以上のツリーブロックのサイズまでにわた
ってもよい。各CUは、1つ以上のPUおよび1つ以上のTUを含んでもよい。CUに関連するシン
タックスデータは、たとえば、1つ以上のPUへのCUの区分を記述してもよい。CUが、スキ
ップモードまたはダイレクトモードで符号化されるのか、イントラ予測モードで符号化さ
れるのか、それともインター予測(inter-prediction)(インター予測(inter prediction)
とも呼ばれる)モードで符号化されるのかの間で、区分モードは異なってもよい。PUは、
形状が非正方形となるように区分されてもよい。CUに関連するシンタックスデータはまた
、たとえば、4分木による1つ以上のTUへのCUの区分を記述してもよい。TUは、形状が正方
形または非正方形(たとえば、長方形)であり得る。

モード選択ユニット40は、たとえば、誤差結果に基づいて、コーディングモード、すな
わち、イントラモードまたはインターモードのうちの1つを選択してもよく、残差ブロッ
クデータを生成するために加算器50に、また参照フレームとして使用するための符号化ブ
ロックを再構成するために加算器62に、得られたイントラコーディングまたはインターコ
ーディングされたブロックを提供する。モード選択ユニット40はまた、動きベクトル、イ
ントラモードインジケータ、区分情報などのシンタックス要素、および他のそのようなシ
ンタックス情報を、エントロピーコーディングユニット56に提供する。

動き推定ユニット42および動き補償ユニット44は、高度に統合されてもよいが、概念的
な目的のために別個に図示される。動き推定ユニット42によって実行される動き推定とは
、ビデオブロックに対する動きを推定する、動きベクトルを生成するプロセスである。動
きベクトルは、たとえば、現在フレーム(または、他のコーディングされたユニット)内で
コーディング中の現在ブロックに対して、参照フレーム(または、他のコーディングされ
たユニット)内の予測ブロックと比べて、現在ビデオフレーム内または現在ピクチャ内で
のビデオブロックのPUの変位を示してもよい。予測ブロックとは、ピクセル差分の観点か
ら、コーディングされるべきブロックに密に整合するものと見出されるブロックであり、
ピクセル差分は、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of
square difference)、または他の差分メトリックによって決定されてもよい。いくつか
の例では、ビデオエンコーダ20は、参照フレームメモリ64の中に記憶された参照ピクチャ
のサブ整数ピクセル位置に対する値を計算してもよい。たとえば、ビデオエンコーダ20は
、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値
を補間してもよい。したがって、動き推定ユニット42は、フルピクセル位置および分数ピ
クセル位置に対して動き探索を実行してもよく、分数ピクセル精度を有する動きベクトル
を出力してもよい。

動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較すること
によって、インターコーディングされたスライスの中のビデオブロックのPUのための動き
ベクトルを計算する。参照ピクチャは、参照フレームメモリ64の中に記憶された1つ以上
の参照ピクチャをその各々が識別する、第1の参照ピクチャリスト(リスト0)または第2の
参照ピクチャリスト(リスト1)から選択されてもよい。動き推定ユニット42は、計算され
た動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44へ送る。

動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定
された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴ってもよ
い。再び、動き推定ユニット42および動き補償ユニット44は、いくつかの例では機能的に
統合されてもよい。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補
償ユニット44は、参照ピクチャリストのうちの1つの中で、動きベクトルが指し示す先の
予測ブロックの位置を特定してもよい。加算器50は、コーディング中の現在ビデオブロッ
クのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロッ
クを形成して、以下で説明するようにピクセル差分値を形成する。一般に、動き推定ユニ
ット42は、ルーマ成分に対して動き推定を実行し、動き補償ユニット44は、ルーマ成分に
基づいて計算された動きベクトルを、クロマ成分とルーマ成分の両方のために使用する。
モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデ
コーダ30によって使用するための、ビデオブロックおよびビデオスライスに関連するシン
タックス要素を生成してもよい。

イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42および動き補
償ユニット44によって実行されるインター予測の代替として、現在ブロックをイントラ予
測してもよい。詳細には、イントラ予測ユニット46は、現在ブロックを符号化するために
使用すべきイントラ予測モードを決定してもよい。いくつかの例では、イントラ予測ユニ
ット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在
ブロックを符号化してもよく、イントラ予測ユニット46(または、いくつかの例ではモー
ド選択ユニット40)は、使用すべき適切なイントラ予測モードを、テストされたモードか
ら選択してもよい。

たとえば、イントラ予測ユニット46は、テストされた様々なイントラ予測モードに対し
て、レートひずみ分析を使用してレートひずみ値を計算してもよく、テストされたモード
の中から、レートひずみ特性が最良のイントラ予測モードを選択してもよい。レートひず
み分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された、
符号化されていない元のブロックとの間のひずみ(すなわち、誤差)の量、ならびに符号化
ブロックを生成するために使用されるビットレート(すなわち、ビットの数)を決定する。
イントラ予測ユニット46は、様々な符号化ブロックに対して、ひずみおよびレートから比
率を計算して、ブロックに対してどのイントラ予測モードが最良のレートひずみ値を呈示
するのかを決定してもよい。

加えて、イントラ予測ユニット46は、深度モデリングモード(DMM:depth modeling mode
)を使用して深度マップの深度ブロックをコーディングするように構成されてもよい。モ
ード選択ユニット40は、利用可能なDMMモードが、たとえば、レートひずみ最適化(RDO:ra
te-distortion optimization)を使用して、イントラ予測モードおよび他のDMMモードより
も良好なコーディング結果を生成するかどうかを決定してもよい。深度マップに対応する
テクスチャ画像に対するデータが、参照フレームメモリ64の中に記憶されてもよい。動き
推定ユニット42および動き補償ユニット44はまた、深度マップの深度ブロックをインター
予測するように構成されてもよい。

ブロック用のイントラ予測モード(たとえば、従来のイントラ予測モード、またはDMMモ
ードのうちの1つ)を選択した後、イントラ予測ユニット46は、ブロック用の選択されたイ
ントラ予測モードを示す情報をエントロピーコーディングユニット56に提供してもよい。
エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報を符
号化してもよい。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブ
ルおよび複数の修正済みのイントラ予測モードインデックステーブル(コードワードマッ
ピングテーブルとも呼ばれる)、様々なブロックに対する符号化コンテキストの定義、な
らびにコンテキストの各々に対して使用すべき最確のイントラ予測モード、イントラ予測
モードインデックステーブル、および修正済みのイントラ予測モードインデックステーブ
ルの表示を含んでもよい構成データを、送信されるビットストリームの中に含めてもよい
。

ビデオエンコーダ20は、コーディング中の元のビデオブロックから、モード選択ユニッ
ト40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器
50は、この減算演算を実行する1つ以上の構成要素を表す。

変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似の変換などの変換
を残差ブロックに適用して、残差変換係数値を備えるビデオブロックを生成する。変換処
理ユニット52は、DCTと概念的に類似の他の変換を実行してもよい。ウェーブレット変換
、整数変換、サブバンド変換、または他のタイプの変換も使用され得る。

変換処理ユニット52は、残差ブロックに変換を適用して、残差変換係数のブロックを生
成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換しても
よい。変換処理ユニット52は、得られた変換係数を量子化ユニット54へ送ってもよい。量
子化ユニット54は、変換係数を量子化してビットレートをさらに低減する。量子化プロセ
スは、係数の一部または全部に関連するビット深度を低減してもよい。量子化の程度は、
量子化パラメータを調整することによって修正されてもよい。いくつかの例では、量子化
ユニット54は、次いで、量子化変換係数を含む行列の走査を実行してもよい。代替的に、
エントロピー符号化ユニット56が走査を実行してもよい。

量子化に続いて、エントロピーコーディングユニット56は、量子化変換係数をエントロ
ピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキス
ト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CA
BAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率区
間区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実
行してもよい。コンテキストベースのエントロピーコーディングの場合には、コンテキス
トは隣接ブロックに基づいてもよい。エントロピーコーディングユニット56によるエント
ロピーコーディングに続いて、符号化ビットストリームが、別のデバイス(たとえば、ビ
デオデコーダ30)へ送信されてもよく、または後で送信するかもしくは取り出すためにア
ーカイブされてもよい。

逆量子化ユニット58および逆変換ユニット60は、それぞれ、逆量子化および逆変換を適
用して、たとえば、後で参照ブロックとして使用するために、ピクセル領域における残差
ブロックを再構成する。動き補償ユニット44は、参照フレームメモリ64のフレームのうち
の1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算して
もよい。動き補償ユニット44はまた、再構成された残差ブロックに1つ以上の補間フィル
タを適用して、動き推定における使用のためのサブ整数ピクセル値を計算してもよい。加
算器62は、動き補償ユニット44によって生成された、動き補償された予測ブロックに、再
構成された残差ブロックを加算して、参照フレームメモリ64の中に記憶するための再構成
ビデオブロックを生成する。再構成ビデオブロックは、後続のビデオフレームの中のブロ
ックをインターコーディングするための参照ブロックとして、動き推定ユニット42および
動き補償ユニット44によって使用されてもよい。

図3は、ビデオコーディング技法を実施してもよいビデオデコーダ30の一例を示すブロ
ック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70、動き
補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参
照フレームメモリ82、および加算器80を含む。ビデオデコーダ30は、いくつかの例では、
ビデオエンコーダ20(図2)に関して説明した符号化パスとは概して相反の、復号パスを実
行してもよい。動き補償ユニット72は、エントロピー復号ユニット70から受信された動き
ベクトルに基づいて予測データを生成してもよいが、イントラ予測ユニット74は、エント
ロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測デ
ータを生成してもよい。

復号プロセス中、ビデオデコーダ30は、符号化ビデオスライスのビデオブロックおよび
関連するシンタックス要素を表す符号化ビデオビットストリームを、ビデオエンコーダ20
から受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームを
エントロピー復号して、量子化係数、動きベクトルまたはイントラ予測モードインジケー
タ、および他のシンタックス要素を生成する。エントロピー復号ユニット70は、動きベク
トルおよび他のシンタックス要素を動き補償ユニット72に転送する。ビデオデコーダ30は
、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信
してもよい。

ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされる
とき、イントラ予測ユニット74は、シグナリングされたイントラ予測モード、および現在
フレームまたは現在ピクチャの、前に復号されたブロックからのデータに基づいて、現在
ビデオスライスのビデオブロックのための予測データを生成してもよい。ビデオフレーム
がインターコーディングされた(たとえば、B、P、またはGPB)スライスとしてコーディン
グされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動き
ベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロック
のための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの
中の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、参照フレー
ムメモリ82の中に記憶された参照ピクチャに基づいてデフォルトの構成技法を使用して、
参照フレームリスト、すなわち、リスト0およびリスト1を構成してもよい。

動き補償ユニット72は、動きベクトルおよび他のシンタックス要素を構文解析すること
によって、現在ビデオスライスのビデオブロックのための予測情報を決定し、予測情報を
使用して、復号中の現在ビデオブロックのための予測ブロックを生成する。たとえば、動
き補償ユニット72は、受信されたシンタックス要素のうちのいくつかを使用して、ビデオ
スライスのビデオブロックをコーディングするために使用された予測モード(たとえば、
イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス
、Pスライス、またはGPBスライス)、スライス用の参照ピクチャリストのうちの1つ以上に
対する構成情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライ
スのインターコーディングされたビデオブロックごとのインター予測ステータス、および
現在ビデオスライスの中のビデオブロックを復号するための他の情報を決定する。

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

深度マップに対応するテクスチャ画像に対するデータが、参照フレームメモリ82の中に
記憶されてもよい。動き補償ユニット72はまた、深度マップの深度ブロックをインター予
測するように構成されてもよい。

一実施形態では、ビデオデコーダ30はユーザインターフェース(UI)84を含む。ユーザイ
ンターフェース84は、ビデオデコーダ30のユーザ(たとえば、ネットワークアドミニスト
レータ)から入力を受け取るように構成される。ユーザインターフェース84を通じて、ユ
ーザは、ビデオデコーダ30上の設定を管理または変更することができる。たとえば、ユー
ザは、ユーザの選好に従ってビデオデコーダ30の構成および/または動作を制御するため
に、パラメータ(たとえば、フラグ)に対する値を入力または別の方法で提供することがで
きる。ユーザインターフェース84は、たとえば、ユーザがグラフィカルアイコン、ドロッ
プダウンメニュー、チェックボックスなどを通じてビデオデコーダ30と対話することを可
能にする、グラフィカルユーザインターフェース(GUI)であってもよい。場合によっては
、ユーザインターフェース84は、キーボード、マウス、または他の周辺デバイスを介して
ユーザから情報を受け取ってもよい。一実施形態では、ユーザは、ビデオデコーダ30から
遠く離れて配置されたスマートフォン、タブレットデバイス、パーソナルコンピュータな
どを介して、ユーザインターフェース84にアクセスすることができる。本明細書で使用す
るユーザインターフェース84は、外部入力または外部手段と呼ばれてもよい。

上記のことを念頭に置いて、ビデオ圧縮技法は、空間(イントラピクチャ)予測および/
または時間(インターピクチャ)予測を実行して、ビデオシーケンスに固有の冗長性を低減
または除去する。ブロックベースのビデオコーディングの場合、ビデオスライス(すなわ
ち、ビデオピクチャ、またはビデオピクチャの一部分)は、ツリーブロック、コーディン
グツリーブロック(CTB:coding tree block)、コーディングツリーユニット(CTU:coding t
ree unit)、コーディングユニット(CU:coding unit)、および/またはコーディングノード
とも呼ばれてもよい、ビデオブロックに区分されてもよい。ピクチャのイントラコーディ
ングされた(I)スライスの中のビデオブロックは、同じピクチャの中の隣接ブロックの中
の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコーディ
ングされた(PまたはB)スライスの中のビデオブロックは、同じピクチャの中の隣接ブロッ
クの中の参照サンプルに対する空間予測、または他の参照ピクチャの中の参照サンプルに
対する時間予測を使用してもよい。ピクチャはフレームと呼ばれてもよく、参照ピクチャ
は参照フレームと呼ばれてもよい。

空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックを
もたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間の
ピクセル差分を表す。インターコーディングされたブロックは、予測ブロックを形成する
参照サンプルのブロックを指し示す動きベクトル、およびコーディングされたブロックと
予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコーディン
グされたブロックは、イントラコーディングモードおよび残差データに従って符号化され
る。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されてもよ
く、結果として残差変換係数になり、残差変換係数は、次いで、量子化されてもよい。当
初は二次元アレイをなして配置された量子化変換係数は、変換係数の一次元ベクトルを生
成するために走査されてもよく、なお一層の圧縮を達成するためにエントロピーコーディ
ングが適用されてもよい。

画像およびビデオ圧縮は急成長を経ており、様々なコーディング規格に至る。そのよう
なビデオコーディング規格は、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またはIS
O/IEC MPEG-4パート10とも呼ばれるアドバンストビデオコーディング(AVC)、およびITU-T
H.265またはMPEG-Hパート2とも呼ばれる高効率ビデオコーディング(HEVC)を含む。AVCは
、スケーラブルビデオコーディング(SVC)、マルチビュービデオコーディング(MVC)および
マルチビュービデオコーディングプラス深度(MVC+D)、ならびに3D AVC(3D-AVC)などの拡
張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、および3D HE
VC(3D-HEVC)などの拡張を含む。

ITU-TとISO/IECとの共同ビデオエキスパートチーム(JVET)によって開発中の多用途ビデ
オコーディング(VVC)と称する新たなビデオコーディング規格もある。VVC規格はいくつか
のワーキングドラフトを有するが、特にVVCの1つのワーキングドラフト(WD)、すなわち、
B.Bross、J.Chen、およびS.Liu、「Versatile Video Coding (Draft 4)」、JVET-M1001-v
5、第13回JVET会合、2019年1月(VVCドラフト4)が、本明細書で参照される。

本明細書で開示する技法の説明は、開発中のビデオコーディング規格、すなわち、ITU-
TとISO/IECとの共同ビデオエキスパートチーム(JVET)による多用途ビデオコーディング(V
VC)に基づく。しかしながら、本技法は、他のビデオコーデック仕様にも適用される。

図4は、復号順序408および提示順序410における、リーディングピクチャ404に対するIR
APピクチャ402と、トレーリングピクチャ406との間の関係の描写400である。一実施形態
では、IRAPピクチャ402は、クリーンランダムアクセス(CRA:clean random access)ピクチ
ャ、またはランダムアクセス復号可能(RADL:random access decodable)ピクチャを伴う瞬
時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャと呼ばれる。HEV
Cでは、IDRピクチャ、CRAピクチャ、およびブロークンリンクアクセス(BLA:Broken Link
Access)ピクチャは、すべてIRAPピクチャ402と見なされる。VVCの場合、2018年10月にお
ける第12回JVET会合の間に、IRAPピクチャとしてIDRピクチャとCRAピクチャの両方を有す
ることが合意された。

図4に示すように、リーディングピクチャ404(たとえば、ピクチャ2および3)は、復号順
序408でIRAPピクチャ402に後続するが、提示順序410でIRAPピクチャ402に先行する。トレ
ーリングピクチャ406は、復号順序408と提示順序410の両方でIRAPピクチャ402に後続する
。2つのリーディングピクチャ404および1つのトレーリングピクチャ406が図4に示される
が、実際の適用例では、より多数またはより少数のリーディングピクチャ404および/また
はトレーリングピクチャ406が復号順序408および提示順序410で存在してもよいことを、
当業者は諒解されよう。

図4の中のリーディングピクチャ404は、2つのタイプ、すなわち、ランダムアクセスス
キップドリーディング(RASL:random access skipped leading)およびRADLに分割されてい
る。IRAPピクチャ402(たとえば、ピクチャ1)で復号が開始するとき、RADLピクチャ(たと
えば、ピクチャ3)は正しく復号され得るが、RASLピクチャ(たとえば、ピクチャ2)は正し
く復号され得ない。したがって、RASLピクチャは廃棄される。RADLピクチャとRASLピクチ
ャとの間の相違に照らして、IRAPピクチャに関連するリーディングピクチャのタイプは、
効率的かつ適切なコーディングのためにRADLまたはRASLのいずれかとして識別されるべき
である。HEVCでは、RASLピクチャおよびRADLピクチャが存在するとき、同じIRAPピクチャ
に関連するRASLピクチャおよびRADLピクチャに対して、RASLピクチャが提示順序410でRAD
Lピクチャに先行しなければならないことが制約される。

IRAPピクチャ402は、以下の2つの重要な機能/利点をもたらす。第一に、IRAPピクチャ4
02の存在は、そのピクチャから復号プロセスが開始できることを示す。この機能により、
IRAPピクチャ402がその位置に存在する限り、必ずしもビットストリームの冒頭とは限ら
ずビットストリームの中のその位置において復号プロセスが開始する、ランダムアクセス
特徴が可能になる。第二に、IRAPピクチャ402の存在は、IRAPピクチャ402において開始し
RASLピクチャを除外するコーディングされたピクチャが、前のピクチャへのいかなる参照
も伴わずにコーディングされるように、復号プロセスをリフレッシュする。それ故に、ビ
ットストリームの中に存在するIRAPピクチャ402を有することは、IRAPピクチャ402および
復号順序408においてIRAPピクチャ402に後続するピクチャにIRAPピクチャ402が伝搬する
前に、コーディングされたピクチャの復号中に起こる可能性がある、いかなるエラーも止
めることになる。

IRAPピクチャ402は、重要な機能を提供するが、圧縮効率への不利益が付いてくる。IRA
Pピクチャ402の存在は、ビットレートの急上昇を引き起こす。圧縮効率へのこの不利益は
、2つの理由に起因する。第一に、IRAPピクチャ402がイントラ予測されるピクチャである
とき、インター予測されるピクチャである他のピクチャ(たとえば、リーディングピクチ
ャ404、トレーリングピクチャ406)と比較すると、ピクチャ自体が、描写するために比較
的多くのビットを必要とすることになる。第二に、IRAPピクチャ402の存在が時間予測を
破壊するので(なぜなら、デコーダが復号プロセスをリフレッシュすることになり、この
ことに対する復号プロセスのアクションのうちの1つが、復号ピクチャバッファ(DPB)の中
の、前の参照ピクチャを除去することであるからである)、IRAPピクチャ402は、それらの
インター予測コーディング用のより少ない参照ピクチャしか有しないので、復号順序408
でIRAPピクチャ402に後続するピクチャのコーディングをさほど効率的にさせない(すなわ
ち、描写するためにより多くのビットを必要とする)。

IRAPピクチャ402と見なされるピクチャタイプのうち、HEVCにおけるIDRピクチャは、他
のピクチャタイプと比較したとき、異なるシグナリングおよび導出を有する。差異のうち
のいくつかは次の通りである。

IDRピクチャのピクチャ順序カウント(POC:picture order count)値のシグナリングおよ
び導出のために、POCの最上位ビット(MSB)部分は前のキーピクチャ(key picture)から導
出されず、単に0に等しくなるように設定される。

参照ピクチャ管理のために必要とされるシグナリング情報の場合、IDRピクチャのスラ
イスヘッダは、参照ピクチャ管理を支援するためにシグナリングされることを必要とされ
る情報を含まない。他のピクチャタイプ(すなわち、CRA、トレーリング、時間サブレイヤ
アクセス(TSA:temporal sub-layer access)など)の場合、以下で説明する参照ピクチャセ
ット(RPS:reference picture set)などの情報、または他の形式の類似の情報(たとえば、
参照ピクチャリスト)は、参照ピクチャマーキングプロセス(すなわち、復号ピクチャバッ
ファ(DPB)の中の参照ピクチャのステータス、すなわち、参照のために使用済みおよび参
照のために未使用のいずれかを、決定するためのプロセス)のために必要とされる。しか
しながら、IDRピクチャの場合、復号プロセスが、参照のために未使用としてDPBの中のす
べての参照ピクチャに単にマークしなければならないことを、IDRの存在が示すので、そ
のような情報はシグナリングされる必要がない。

HEVCおよびVVCでは、IRAPピクチャ402およびリーディングピクチャ404は各々、単一の
ネットワークアブストラクションレイヤ(NAL)ユニット内に含まれてもよい。NALユニット
のセットは、アクセスユニットと呼ばれてもよい。IRAPピクチャ402およびリーディング
ピクチャ404は、システムレベルアプリケーションによって容易に識別され得るように、
異なるNALユニットタイプが与えられる。たとえば、ビデオスプライサは、詳細には、ト
レーリングピクチャ406からRASLピクチャおよびRADLピクチャを決定することを含めて、
非IRAPピクチャからIRAPピクチャ402を識別するために、またリーディングピクチャ404を
識別するために、コーディングされたビットストリームの中のシンタックス要素のあまり
にも多くの詳細を理解する必要なく、コーディングされたピクチャタイプを理解する必要
がある。トレーリングピクチャ406は、IRAPピクチャ402に関連するピクチャであり、提示
順序410でIRAPピクチャ402に後続する。ピクチャは、復号順序408で特定のIRAPピクチャ4
02に後続してもよく、復号順序408で任意の他のIRAPピクチャ402に先行してもよい。この
ことのために、IRAPピクチャ402およびリーディングピクチャ404にそれら自体のNALユニ
ットタイプを与えることは、そのようなアプリケーションの助けとなる。

HEVCの場合、IRAPピクチャのためのNALユニットタイプは以下を含む。
リーディングピクチャを伴うBLA(BLA_W_LP): 復号順序で1つ以上のリーディングピクチ
ャが後続してもよいブロークンリンクアクセス(BLA)ピクチャのNALユニット。
RADLを伴うBLA(BLA_W_RADL): 復号順序で1つ以上のRADLピクチャが後続してもよいがRA
SLピクチャが後続し得ないBLAピクチャのNALユニット。
リーディングピクチャを伴わないBLA(BLA_N_LP): 復号順序でリーディングピクチャが
後続しないBLAピクチャのNALユニット。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つ以上のRADLピクチャが後続してもよいがRA
SLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが
後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続してもよいクリーンランダムアクセス(CRA)ピクチャ
のNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両
方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。

VVCの場合、IRAPピクチャ402およびリーディングピクチャ404のためのNALユニットタイ
プは次の通りである。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つ以上のRADLピクチャが後続してもよいがRA
SLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが
後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続してもよいクリーンランダムアクセス(CRA)ピクチャ
のNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両
方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。

順次イントラリフレッシュ/漸進的復号リフレッシュが以下で説明される。

低遅延適用例に対して、非IRAPピクチャ(すなわち、Pピクチャ/Bピクチャ)と比較して
、比較的大きく、それ故に、より大きいレイテンシ/遅延を引き起こす、そのビットレー
ト要件に起因して、IRAPピクチャ(たとえば、IRAPピクチャ402)としてピクチャをコーデ
ィングすることを回避することが望ましい。しかしながら、IRAPの使用を完全に回避する
ことは、すべての低遅延適用例において可能であるとは限らない場合がある。たとえば、
マルチパーティ遠隔会議などの会話型の適用例の場合、新たなユーザが遠隔会議に参加で
きる定期的なポイントを提供することが必要である。

新たなユーザがマルチパーティ遠隔会議適用例に参加することを可能にする、ビットス
トリームへのアクセスを提供するために、1つの可能な方策は、ビットレートにおけるピ
ークを有することを回避するために、IRAPピクチャを使用するのではなく順次イントラリ
フレッシュ技法(PIR:progressive intra refresh)を使用することである。PIRは、漸進的
復号リフレッシュ(GDR)とも呼ばれてもよい。PIRおよびGDRという用語は、本開示におい
て互換的に使用されてもよい。

図5は、漸進的復号リフレッシュ(GDR)技法500を示す。図示のように、GDR技法500は、
ビットストリームのコーディングされたビデオシーケンス508内で、GDRピクチャ502、1つ
以上のトレーリングピクチャ504、およびリカバリポイントピクチャ506を使用して示され
る。一実施形態では、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイ
ントピクチャ506は、CVS508の中のGDR期間を規定してもよい。CVS508は、GDRピクチャ502
で開始する一連のピクチャ(または、それらの部分)であり、次のGDRピクチャまでの(ただ
し、それを含まない)、またはビットストリームの終端までの、すべてのピクチャ(または
、それらの部分)を含む。GDR期間は、GDRピクチャ502で開始する一連のピクチャであり、
リカバリポイントピクチャ506までの(それを含む)すべてのピクチャを含む。

図5に示すように、GDR技法500または原理は、GDRピクチャ502で開始しリカバリポイン
トピクチャ506で終了する一連のピクチャにわたって機能する。GDRピクチャ502は、すべ
てがイントラ予測を使用してコーディングされているブロック(すなわち、イントラ予測
ブロック)を含むリフレッシュ済みの/クリーンな領域510、およびすべてがインター予測
を使用してコーディングされているブロック(すなわち、インター予測ブロック)を含むリ
フレッシュされていない/ダーティな領域512を含む。

GDRピクチャ502に直接隣接するトレーリングピクチャ504は、イントラ予測を使用して
コーディングされる第1の部分510Aおよびインター予測を使用してコーディングされる第2
の部分510Bを有する、リフレッシュ済みの/クリーンな領域510を含む。第2の部分510Bは
、たとえば、CVS508のGDR期間内の先行するピクチャの、リフレッシュ済みの/クリーンな
領域510を参照することによってコーディングされる。図示のように、トレーリングピク
チャ504のリフレッシュ済みの/クリーンな領域510は、一貫した方向で(たとえば、左から
右に)コーディングプロセスが移動または進行するにつれて拡大し、それに対応して、そ
のことはリフレッシュされていない/ダーティな領域512を縮小する。最終的に、リフレッ
シュ済みの/クリーンな領域510しか含まないリカバリポイントピクチャ506が、コーディ
ングプロセスから取得される。特に、さらに以下で説明するように、インター予測ブロッ
クとしてコーディングされる、リフレッシュ済みの/クリーンな領域510の第2の部分510B
は、参照ピクチャの中のリフレッシュ済みの領域/クリーンな領域510を参照するだけでよ
い。

HEVCでは、図5のGDR技法500が、リカバリポイント補足エンハンスメント情報(SEI:Supp
lemental Enhancement Information)メッセージおよび領域リフレッシュ情報SEIメッセー
ジを使用して非規範的にサポートされた。これらの2つのSEIメッセージは、GDRがどのよ
うに実行されるのかを規定しない。むしろ、その2つのSEIメッセージは、(すなわち、リ
カバリポイントSEIメッセージによって提供される)GDR期間の中の最初のピクチャおよび
最後のピクチャならびに(すなわち、領域リフレッシュ情報SEIメッセージによって提供さ
れる)リフレッシュされている領域を示すためのメカニズムを単に提供する。

実際には、GDR技法500は、2つの技法を一緒に使用することによって実行される。それ
らの2つの技法とは、制約イントラ予測(CIP:constraint intra prediction)、および動き
ベクトルに対するエンコーダ制約である。CIPは、リフレッシュされていない領域(たとえ
ば、リフレッシュされていない/ダーティな領域512)からのサンプルを使用しない領域が
、参照のために使用されることを可能にするので、CIPは、特にイントラ予測ブロック(た
とえば、リフレッシュ済みの/クリーンな領域510の第1の部分510A)としてのみコーディン
グされる領域をコーディングするための、GDR目的のために使用され得る。しかしながら
、イントラブロックへの制約が、リフレッシュ済みの領域の中のイントラブロックに対し
てだけでなくピクチャの中のすべてのイントラブロックにも適用されなければならないの
で、CIPの使用は深刻なコーディング性能劣化を引き起こす。動きベクトルに対するエン
コーダ制約は、リフレッシュ済みの領域の外側に位置する参照ピクチャの中の任意のサン
プルをエンコーダが使用することを制限する。そのような制約は、最適でない動き探索を
引き起こす。

図6は、GDRをサポートするためにエンコーダ制約を使用するときの、望ましくない動き
探索600を示す概略図である。図示のように、動き探索600は、現在ピクチャ602および参
照ピクチャ604を示す。現在ピクチャ602および参照ピクチャ604は各々、イントラ予測を
用いてコーディングされたリフレッシュ済みの領域606、インター予測を用いてコーディ
ングされたリフレッシュ済みの領域608、およびリフレッシュされていない領域608を含む
。リフレッシュ済みの領域604、リフレッシュ済みの領域606、およびリフレッシュされて
いない領域608は、図5の中のリフレッシュ済みの/クリーンな領域510の第1の部分510A、
リフレッシュ済みの/クリーンな領域510の第2の部分510B、およびリフレッシュされてい
ない/ダーティな領域512と類似である。

動き探索プロセス中、エンコーダは、リフレッシュ済みの領域606の外側に位置してい
る参照ブロック612のサンプルのうちのいくつかをもたらす、いかなる動きベクトル610を
選択することも制約または防止される。このことは、現在ピクチャ602の中の現在ブロッ
ク614を予測するときに参照ブロック612が最良のレートひずみコスト基準を与えるときに
さえ行われる。したがって、図6は、GDRをサポートするためのエンコーダ制約を使用する
ときの、動き探索600における非最適性に対する理由を示す。

JVET寄稿JVET-K0212およびJVET-L0160は、CIPおよびエンコーダ制約手法の使用に基づ
くGDRの実装形態を記載している。実装形態は、次のように要約され得る。すなわち、列
ごとにコーディングユニットに対してイントラ予測モードが強制され、イントラCUの再構
成を確実なものにするために、制約付きイントラ予測が有効化され、動きベクトルは、フ
ィルタが原因で広がる誤差(たとえば、6ピクセル)を回避するための追加のマージンを考
慮に入れるとともに、イントラ列を再ループさせるときに過去の参照ピクチャを除去しな
がら、リフレッシュ済みのエリア内を指し示すように制約される。

JVET寄稿JVET-M0529は、ピクチャがGDR期間の中で最初のピクチャおよび最後のピクチ
ャであることを規範的に示すための方法を提案した。提案された着想は次のように機能す
る。

NALユニットタイプリカバリポイント表示を有する新たなNALユニットを、非ビデオコー
ディングレイヤ(VCL)NALユニットとして規定する。NALユニットのペイロードは、GDR期間
の中の最後のピクチャのPOC値を導出するために使用され得る情報を指定するためのシン
タックス要素を含む。タイプリカバリポイント表示を有する非VCL NALユニットを含むア
クセスユニットは、リカバリポイント開始(RBP:recovery point begin)アクセスユニット
(AU:access unit)と呼ばれ、RBPアクセスユニットの中のピクチャは、RBPピクチャと呼ば
れる。復号プロセスは、RBP AUから開始することができる。復号がRBP AUから開始すると
き、最後のピクチャを除いてGDR期間の中のすべてのピクチャは出力されない。

既存のGDR設計を伴う問題のうちのいくつかが説明される。

GDRをサポートするための既存の設計/手法は、少なくとも以下の問題を有する。

JVET-M0529におけるGDRを規範的に規定するための方法は、以下の問題を有する。提案
された方法は、GDRがどのように実行されるのかを説明していない。代わりに、提案され
た方法は、GDR期間の中の最初のピクチャおよび最後のピクチャを示すためのいくつかの
シグナリングを提供するにすぎない。GDR期間の中の最初のピクチャおよび最後のピクチ
ャを示すために、新たな非VCL NALユニットが必要とされる。リカバリポイント表示(RPI:
recovery point indication)NALユニットの中に含まれる情報が、GDR期間の中の最初のピ
クチャのタイルグループヘッダの中に単に含められ得るので、このことは冗長性である。
また、提案された方法は、GDR期間の中のピクチャの中のどの領域がリフレッシュ済みの
領域およびリフレッシュされていない領域であるのかを表すことができない。

JVET-K0212およびJVET-L0160に記載されるGDR手法は、以下の問題を有する。第一に、C
IPの使用。リフレッシュされていない領域からの任意のサンプルが空間的な参照のために
使用されることを防止するために、リフレッシュ済みの領域を、いくつかの制約を伴うイ
ントラ予測を用いてコーディングすることが必要である。CIPが使用されるとき、コーデ
ィングはピクチャベースであり、そのことは、ピクチャの中のすべてのイントラブロック
もCIPイントラブロックとしてコーディングされなければならないことを意味する。それ
故に、このことは性能劣化を引き起こす。さらに、動きベクトルに関連する参照ブロック
のサンプルが、完全に参照ピクチャの中のリフレッシュ済みの領域内にあるとは限らない
とき、動き探索を限定するためのエンコーダ制約の使用は、最良の動きベクトルをエンコ
ーダが選ぶことを妨げる。また、イントラ予測のみを用いてコーディングされるリフレッ
シュ済みの領域はCTUサイズでない。代わりに、リフレッシュ済みの領域は、最小CUサイ
ズまで下に、CTUサイズよりも小さくなることができる。このことは、ブロックレベルで
の表示を必要としてもよいので、実装を不必要に複雑にさせる。

ビデオコーディングにおける漸進的復号リフレッシュ(GDR)をサポートするための技法
が、本明細書で開示される。開示する技法は、イントラランダムアクセスポイント(IRAP)
ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化する
ことを可能とする。第1のフラグに対する値が外部入力によって提供されるとき、漸進的
復号リフレッシュ(GDR)ピクチャおよび出力順序でGDRピクチャとリカバリポイントピクチ
ャとの間の任意のトレーリングピクチャが出力されることを防止するために、第1のフラ
グは外部入力によって提供される値に等しく設定され、第2のフラグは第1のフラグに等し
く設定される。外部入力は、たとえば、ビデオデコーダ30のグラフィックユーザインター
フェース(GUI)を介してユーザ(たとえば、ネットワークアドミニストレータ)から受け取
られる入力であってもよい。このようにして第1および第2のフラグを設定することは、潜
在的にダーティなデータがディスプレイに出力されることを防止する。すなわち、第1お
よび第2のフラグの値は、GDRピクチャからの潜在的にダーティなデータが出力されるかど
うか、またはビデオデコーダが完全な同期を待ってデータを表示し始めるかどうかを制御
する。ダーティなデータが出力されることを制限するための能力を有することによって、
ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在の
コーデックに比べて改善される。実際問題として、改善されたビデオコーディングプロセ
スは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエク
スペリエンスをユーザに与える。

上記で説明した問題のうちの1つ以上を解決するために、本開示は以下の態様を開示す
る。態様の各々は個別に適用され得、それらのうちのいくつかは組み合わせで適用され得
る。

1) タイプGDR_NUTを有するVCL NALユニットが規定される。

a. NALユニットタイプGDR_NUTを有するピクチャは、GDRピクチャ、すなわち、GDR期間
の中の最初のピクチャと呼ばれる。

b. GDRピクチャは、temporalIDが0に等しい。

c. GDRピクチャを含むアクセスユニットは、GDRアクセスユニットと呼ばれる。上述の
ように、アクセスユニットはNALユニットのセットである。各NALユニットは、単一のピク
チャを含んでもよい。

2) コーディングされたビデオシーケンス(CVS)は、GDRアクセスユニットで開始しても
よい。

3) 次のことのうちの1つが真であるとき、GDRアクセスユニットはCVSの中の最初のアク
セスユニットである。

a. GDRアクセスユニットがビットストリームの中の最初のアクセスユニットである。

b. GDRアクセスユニットがエンドオブシーケンス(EOS)アクセスユニットの直後にくる
。

c. GDRアクセスユニットがエンドオブビットストリーム(EOB:end-of-bitstream)アクセ
スユニットの直後にくる。

d. デコーダフラグ、いわゆる、NoIncorrectPicOutputFlagがGDRピクチャに関連付けら
れ、デコーダの外側のエンティティによってフラグの値が1(すなわち、真)に等しく設定
される。

4) GDRピクチャがCVSの中の最初のアクセスユニットであるとき、以下のことが適用さ
れる。

a. DPBの中のすべての参照ピクチャが「参照のために未使用」としてマークされる。

b. ピクチャのPOC MSBが0に等しくなるように設定される。

c. GDRピクチャ、およびGDR期間の中の最後のピクチャを除外してGDR期間の中の最後の
ピクチャまで出力順序でGDRピクチャに後続するすべてのピクチャは、出力されない(すな
わち、「出力のために不必要」としてマークされる)。

5) GDRが有効化されているかどうかを指定するためのフラグが、シーケンスレベルパラ
メータセットの中で(たとえば、SPSの中で)シグナリングされる。

a. そのフラグはgdr_enabled_flagと指定されてもよい。

b. フラグが1に等しいとき、GDRピクチャがCVSの中に存在してもよい。そうではなく、
フラグが0に等しいとき、GDRピクチャがCVSの中に存在しないようにGDRは有効化されてい
ない。

6) GDR期間の中の最後のピクチャのPOC値を導出するために使用され得る情報が、GDRピ
クチャのタイルグループヘッダの中でシグナリングされる。

a. GDR期間の中の最後のピクチャとGDRピクチャとの間の差分(delta)POCとして、情報
がシグナリングされる。その情報は、recovery_point_cntと指定されたシンタックス要素
を使用してシグナリングされ得る。

b. タイルグループヘッダの中のシンタックス要素recovery_point_cntの存在は、gdr_e
nabledフラグの値、およびピクチャのNALユニットタイプが条件とされてもよく、すなわ
ち、gdr_enabled_flagが1に等しく、かつタイルグループを含むNALユニットのnal_unit_t
ypeがGDR_NUTであるときのみ、フラグが存在する。

7) タイルグループが、リフレッシュ済みの領域の一部であるか否かを指定するための
フラグが、タイルグループヘッダの中でシグナリングされる。

a. そのフラグは、refreshed_region_flagと指定されてもよい。

b. そのフラグの存在は、gdr_enabled_flagの値、およびタイルグループを含むピクチ
ャがGDR期間内にあるかどうかが、条件とされてもよい。したがって、次のことのすべて
が真であるときのみ、フラグが存在する。

i. gdr_enabled_flagの値が1に等しい。

ii. 現在ピクチャのPOCが、最後のGDRピクチャのPOC値以上であり(現在ピクチャがGDR
ピクチャであるとき、最後のGDRピクチャが現在ピクチャである)、GDR期間の中の最後の
ピクチャのPOCよりも小さい。

c. フラグがタイルグループヘッダの中に存在しないとき、フラグの値は1に等しいもの
と推測される。

8) refreshed_region_flagが1に等しいすべてのタイルグループは、連結している領域
をカバーする。同様に、refreshed_region_flagが0に等しいすべてのタイルグループも、
連結している領域をカバーする。

9) refreshed_region_flagを有するタイルグループは、タイプI(すなわち、イントラタ
イルグループ)またはBもしくはP(すなわち、インタータイルグループ)のものであり得る
。

10) GDRピクチャから開始しGDR期間の中の最後のピクチャまでの各ピクチャは、refres
hed_region_flagが1に等しい少なくとも1つのタイルグループを含む。

11) GDRピクチャは、refreshed_region_flagが1に等しく、かつtile_group_typeがI(す
なわち、イントラタイルグループ)に等しい、少なくとも1つのタイルグループを含む。

12) gdr_enabled_flagが1に等しいとき、長方形タイルグループの情報、すなわち、タ
イルグループの数およびそれらのアドレスが、ピクチャパラメータセット(PPS:picture p
arameter set)またはタイルグループヘッダのいずれかの中でシグナリングされることを
許容される。これを行うために、長方形タイルグループ情報がPPSの中に存在するか否か
を指定するために、PPSの中でフラグがシグナリングされる。このフラグは、rect_tile_g
roup_info_in_pps_flagと呼ばれてもよい。このフラグは、gdr_enabled_flagが1に等しい
とき、1に等しくなるように制約されてもよい。

a. 一代替形態では、長方形タイルグループ情報がPPSの中に存在するか否かをシグナリ
ングするのではなく、タイルグループ情報(すなわち、長方形タイルグループ、ラスタ走
査タイルグループなどの、任意のタイプのタイルグループ)がPPSの中に存在するかどうか
を指定するために、より全般的なフラグがPPSの中でシグナリングされ得る。

13) タイルグループ情報がPPSの中に存在しないとき、明示的なタイルグループ識別子(
ID)情報のシグナリングが存在しないことが、さらに制約されてもよい。明示的なタイル
グループID情報は、signaled_tile_group_id_flag、signaled_tile_group_id_length_min
us1、およびtile_group_id[ i ]を含む。

14) ピクチャの中のリフレッシュ済みの領域とリフレッシュされていない領域との間の
境界を横断するループフィルタ処理演算が許容されるかどうかを指定するために、フラグ
がシグナリングされる。

a. このフラグはPPSの中でシグナリングされてもよく、loop_filter_across_refreshed
_region_enabled_flagと呼ばれてもよい。

b. loop_filter_across_refreshed_region_enabled_flagの存在は、loop_filter_acros
s_tile_enabled_flagの値が条件とされてもよい。loop_filter_across_tile_enabled_fla
gが0に等しいとき、loop_filter_across_refreshed_region_enabled_flagは存在しなくて
もよく、その値は0に等しいものと推測される。

c. 一代替形態では、タイルグループヘッダの中でそのフラグがシグナリングされても
よく、その存在は、refreshed_region_flagの値が条件とされてもよく、すなわち、refre
shed_region_flagの値が1に等しいときのみ、そのフラグが存在する。

15) タイルグループがリフレッシュ済みの領域であることが示され、かつリフレッシュ
済みの領域を横断するループフィルタが許容されないことが示されるとき、以下のことが
適用される。

a. エッジを共有する隣接タイルグループが、リフレッシュされていないタイルグルー
プであるとき、タイルグループの境界におけるエッジのデブロッキングが実行されない。

b. タイルグループの境界におけるブロックに対するサンプル適応オフセット(SAO:samp
le adaptive offset)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサン
プルも使用しない。

c. タイルグループの境界におけるブロックに対する適応ループフィルタ処理(ALF:adap
tive loop filtering)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサン
プルも使用しない。

16) gdr_enabled_flagが1に等しいとき、各ピクチャは、ピクチャの中のリフレッシュ
済みの領域の境界を決定するための変数に関連付けられる。これらの変数は、次のように
呼ばれてもよい。

a. ピクチャの中のリフレッシュ済みの領域の左の境界位置に対する、PicRefreshedLef
tBoundaryPos。

b. ピクチャの中のリフレッシュ済みの領域の右の境界位置に対する、PicRefreshedRig
htBoundaryPos。

c. ピクチャの中のリフレッシュ済みの領域の上の境界位置に対する、PicRefreshedTop
BoundaryPos。

d. ピクチャの中のリフレッシュ済みの領域の下の境界位置に対する、PicRefreshedBot
BoundaryPos。

17) ピクチャの中のリフレッシュ済みの領域の境界が導出されてもよい。ピクチャのリ
フレッシュ済みの領域の境界は、タイルグループヘッダが構文解析された後にデコーダに
よって更新され、タイルグループのrefreshed_region_flagの値は1に等しい。

18) 解決策17)の一代替形態では、ピクチャの中のリフレッシュ済みの領域の境界は、
ピクチャの各タイルグループの中で明示的にシグナリングされる。

a. タイルグループが属するピクチャが、リフレッシュされていない領域を含むかどう
かを示すために、フラグがシグナリングされてもよい。リフレッシュされていない領域を
ピクチャが含まないことが指定されるとき、リフレッシュ済み境界情報はシグナリングさ
れず、ピクチャ境界に等しいものと単に推測され得ない。

19) 現在ピクチャに対して、次のように、ループ内フィルタプロセスにおいてリフレッ
シュ済みの領域の境界が使用される。

a. デブロッキングプロセスの場合、エッジがデブロッキングされる必要があるか否か
を決めるために、リフレッシュ済みの領域のエッジを決定する。

b. SAOプロセスの場合、リフレッシュ領域を横断するループフィルタが許容されないと
き、リフレッシュされていない領域からのサンプルを使用することを回避するためにクリ
ッピングプロセスが適用され得るように、リフレッシュ済みの領域の境界を決定する。

c. ALFプロセスの場合、リフレッシュ済みの領域を横断するループフィルタが許容され
ないとき、リフレッシュされていない領域からのサンプルを使用することを回避するため
にクリッピングプロセスが適用され得るように、リフレッシュ領域の境界を決定する。

20) 動き補償プロセスに対して、リフレッシュ済みの領域の境界、特に参照ピクチャの
中のリフレッシュ済みの領域の境界についての情報が、次のように使用される。すなわち
、現在ピクチャの中の現在ブロックが、refreshed_region_flagが1に等しいタイルグルー
プの中にあり、かつ参照ブロックが、リフレッシュされていない領域を含む参照ピクチャ
の中にあるとき、以下のことが適用される。

a. 現在ブロックからその参照ピクチャへの動きベクトルは、その参照ピクチャの中の
リフレッシュ済みの領域の境界によってクリッピングされる。

b. その参照ピクチャの中のサンプルのための分数補間フィルタに対して、そうした動
きベクトルはその参照ピクチャの中のリフレッシュ済みの領域の境界によってクリッピン
グされる。

本開示の実施形態の詳細な説明が提供される。説明はベーステキストに関連し、ベース
テキストはJVET寄稿JVET-M1001-v5である。すなわち、差分だけが記載されるが、以下で
述べられないベーステキストの中のテキストは、現状のままで適用される。ベーステキス
トに比べて修正されるテキストは、イタリック体が使用される。

定義が与えられる。

3.1 クリーンランダムアクセス(CRA)ピクチャ: CRA_NUTに等しいnal_unit_typeを各VCL
NALユニットが有するIRAPピクチャ。

注 - CRAピクチャは、その復号プロセスにおけるインター予測のために、それ自体以外
のいかなるピクチャも参照せず、復号順序でビットストリームの中の最初のピクチャであ
ってもよく、または後でビットストリームの中に出現してもよい。CRAピクチャは、関連
するRADLピクチャまたはRASLピクチャを有してもよい。1に等しいNoIncorrectPicOutputF
lagをCRAピクチャが有するとき、RASLピクチャは、ビットストリームの中に存在しないピ
クチャへの参照を含んでもよいときに復号可能でない場合があるので、関連するRASLピク
チャはデコーダによって出力されない。

3.2 コーディングされたビデオシーケンス(CVS): NoIncorrectPicOutputFlagが1に等し
いIRAPアクセスユニットまたはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニッ
トである後続の任意のアクセスユニットまでの(ただし、それを含まない)すべての後続の
アクセスユニットを含む、NoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニット
またはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットと、それに後続する0
、またはNoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットもしくはNoIncorre
ctPicOutputFlagが1に等しいGDRアクセスユニットでない、より多くのアクセスユニット
とを復号順序で備える、アクセスユニットのシーケンス。

注1 - IRAPアクセスユニットは、IDRアクセスユニットまたはCRAアクセスユニットであ
ってもよい。各IDRアクセスユニットに対してNoIncorrectPicOutputFlagの値は1に等しく
、復号順序でビットストリームの中の最初のアクセスユニットである各CRAアクセスユニ
ットは、復号順序でエンドオブシーケンスNALユニットに後続するか、または1に等しいHa
ndleCraAsCvsStartFlagを有する、最初のアクセスユニットである。

注2 - 復号順序でビットストリームの中の最初のアクセスユニットである各GDRアクセ
スユニットに対して、NoIncorrectPicOutputFlagの値が1に等しいことは、復号順序でエ
ンドオブシーケンスNALユニットに後続するか、または1に等しいHandleGdrAsCvsStartFla
gを有する、最初のアクセスユニットである。

3.3 漸進的復号リフレッシュ(GDR)アクセスユニット: コーディングされたピクチャがG
DRピクチャであるアクセスユニット。

3.4 漸進的復号リフレッシュ(GDR)ピクチャ: GDR_NUTに等しいnal_unit_typeを各VCL N
ALユニットが有するピクチャ。

3.5 ランダムアクセススキップドリーディング(RASL)ピクチャ: RASL_NUTに等しいnal_
unit_typeを各VCL NALユニットが有するコーディングされたピクチャ。

注 - すべてのRASLピクチャは、関連するCRAピクチャのリーディングピクチャである。
関連するCRAピクチャが、1に等しいNoIncorrectPicOutputFlagを有するとき、ビットスト
リームの中に存在しないピクチャへの参照をRASLピクチャが含んでもよいので、RASLピク
チャは出力されず、正しく復号可能でない場合がある。RASLピクチャは、非RASLピクチャ
の復号プロセスのための参照ピクチャとして使用されない。存在するとき、すべてのRASL
ピクチャは、関連する同じCRAピクチャのすべてのトレーリングピクチャに復号順序で先
行する。

シーケンス・パラメータ・セット・ロー・バイト・シーケンス・ペイロード(RBSP:raw
byte sequence payload)のシンタックスおよびセマンティック。

1に等しいgdr_enabled_flagは、コーディングされたビデオシーケンスの中にGDRピクチ
ャが存在してもよいことを指定する。0に等しいgdr_enabled_flagは、コーディングされ
たビデオシーケンスの中にGDRピクチャが存在しないことを指定する。

ピクチャパラメータセットRBSPのシンタックスおよびセマンティック。

1に等しいrect_tile_group_info_in_pps_flagは、長方形タイルグループ情報がPPSの中
でシグナリングされることを指定する。0に等しいrect_tile_group_info_in_pps_flagは
、長方形タイルグループ情報がPPSの中でシグナリングされないことを指定する。

アクティブなSPSの中のgdr_enabled_flagの値が0に等しいとき、rect_tile_group_info
_in_pps_flagの値が0に等しくなければならないことが、ビットストリーム適合の要件で
ある。

1に等しいloop_filter_across_refreshed_region_enabled_flagは、PPSを参照するピク
チャの中で、refreshed_region_flagが1に等しいタイルグループの境界を横断してループ
内フィルタ処理演算が実行されてもよいことを指定する。0に等しいloop_filter_across_
refreshed_region_enabled_flagは、PPSを参照するピクチャの中で、refreshed_region_f
lagが1に等しいタイルグループの境界を横断してループ内フィルタ処理演算が実行されな
いことを指定する。ループ内フィルタ処理演算は、デブロッキングフィルタ、サンプル適
応オフセットフィルタ、および適応ループフィルタ演算を含む。存在しないとき、loop_f
ilter_across_refreshed_region_enabled_flagの値は0に等しいものと推測される。

1に等しいsignalled_tile_group_id_flagは、タイルグループごとのタイルグループID
がシグナリングされることを指定する。0に等しいsignalled_tile_group_index_flagは、
タイルグループIDがシグナリングされないことを指定する。存在しないとき、signalled_
tile_group_index_flagの値は0に等しいものと推測される。

signalled_tile_group_id_length_minus1+1は、存在するときシンタックス要素tile_gr
oup_id[ i ]を、かつタイルグループヘッダの中のシンタックス要素tile_group_address
を表すために使用される、ビットの数を指定する。signalled_tile_group_index_length_
minus1の値は、両端値を含む0～15という範囲の中になければならない。存在しないとき
、signalled_tile_group_index_length_minus1の値は次のように推測される。

rect_tile_group_info_in_pps_flagが1に等しい場合、Ceil( Log2( num_tile_groups_i
n_pic_minus1 + 1 ) ) - 1。

そうでない場合、Ceil( Log2( NumTilesInPic ) ) - 1。

全般的なタイルグループヘッダのシンタックスおよびセマンティック。

tile_group_addressは、タイルグループの中の最初のタイルのタイルアドレスを指定す
る。存在しないとき、tile_group_addressの値は、0に等しいものと推測される。

rect_tile_group_flagが0に等しい場合、以下のことが適用される。
tile_group_addressは、式6-7によって指定されるタイルIDである。
tile_group_addressの長さは、Ceil( Log2 ( NumTilesInPic ) )ビットである。
tile_group_addressの値は、両端値を含む0～NumTilesInPic - 1という範囲の中にな
ければならない。

そうではなく、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ビッ
トである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、両端
値を含む0～NumTilesInPic - 1という範囲の中になければならない。そうでない場合、ti
le_group_addressの値は、両端値を含む0～2^{( signalled_tile_group_index_length_minu}
^{s1 + 1 )} - 1という範囲の中になければならない。

それ以外の(rect_tile_group_flagが1に等しく、かつrect_tile_group_info_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という範囲の中になければならない。

bottom_right_tile_idは、タイルグループの右下隅角に位置するタイルのタイルインデ
ックスを指定する。single_tile_per_tile_group_flagが1に等しいとき、bottom_right_t
ile_idは、tile_group_addressに等しいものと推測される。bottom_right_tile_idシンタ
ックス要素の長さは、Ceil( Log2( NumTilesInPic) )ビットである。

現在タイルグループの中のタイルの数を指定する変数NumTilesInCurrTileGroup、タイ
ルグループの左上のタイルのタイルインデックスを指定するTopLeftTileIdx、タイルグル
ープの右下のタイルのタイルインデックスを指定するBottomRightTileIdx、および現在タ
イルグループの中の第iのタイルのタイルインデックスを指定するTgTileIdx[ i ]が、次
のように導出される。
if( rect_tile_group_flag ) {
if ( tile_group_info_in_pps ) {
tileGroupIdx = 0
while( tile_group_address != rect_tile_group_id[ tileGroupIdx ] )
tileGroupIdx++
tileIdx = top_left_tile_idx[ tileGroupIdx ]
BottomRightTileIdx = bottom_right_tile_idx[ tileGroupIdx ]
} else {
tileIdx = tile_group_address
BottomRightTileIdx = bottom_right_tile_id
}
TopLeftTileIdx = tileIdx
deltaTileIdx = BottomRightTileIdx - TopLeftTileIdx
NumTileRowsInTileGroupMinus1 = deltaTileIdx / ( num_tile_columns_minus1 +
1 ) (7-35)
NumTileColumnsInTileGroupMinus1 = deltaTileIdx % ( num_tile_columns_minus1
+ 1 )
NumTilesInCurrTileGroup = ( NumTileRowsInTileGroupMinus1 + 1 ) * ( NumTile
ColumnsInTileGroupMinus1 + 1 )
for( j = 0, tIdx = 0; j < NumTileRowsInTileGroupMinus1 + 1; j++, tileIdx +
= num_tile_columns_minus1 + 1 )
for( i = 0, currTileIdx = tileIdx; i < NumTileColumnsInTileGroupMinus1 + 1
; i++, currTileIdx++, tIdx++ )
TgTileIdx[ tIdx ] = currTileIdx
} else {
NumTilesInCurrTileGroup = num_tiles_in_tile_group_minus1 + 1
TgTileIdx[ 0 ] = tile_group_address
for( i = 1; i < NumTilesInCurrTileGroup; i++ )
TgTileIdx[ i ] = TgTileIdx[ i - 1 ] + 1
}

recovery_poc_cntは、出力順序での復号ピクチャのリカバリポイントを指定する。CVS
の中で復号順序で現在ピクチャ(すなわち、GDRピクチャ)に後続し、かつ現在ピクチャのP
icOrderCntVal+recovery_poc_cntの値に等しいPicOrderCntValを有する、ピクチャpicAが
ある場合、ピクチャpicAは、リカバリポイントピクチャと呼ばれる。そうでない場合、現
在ピクチャのPicOrderCntVal+recovery_poc_cntの値よりも大きいPicOrderCntValを有す
る、出力順序で最初のピクチャが、リカバリポイントピクチャと呼ばれる。リカバリポイ
ントピクチャは、復号順序で現在ピクチャに先行してはならない。出力順序でのすべての
復号ピクチャは、リカバリポイントピクチャの出力順序位置において開始する内容の中で
正確またはほぼ正確であるものと示される。recovery_poc_cntの値は、両端値を含む-Max
PicOrderCntLsb / 2～MaxPicOrderCntLsb / 2 - 1という範囲の中になければならない。

RecoveryPointPocValの値は、次のように導出される。

RecoveryPointPocVal = PicOrderCntVal + recovery_poc_cnt

1に等しいrefreshed_region_flagは、タイルグループの復号が、関連するGDRのNoIncor
rectPicOutputFlagの値にかかわらず正確な再構成サンプル値を生成することを指定する
。0に等しいrefreshed_region_flagは、タイルグループの復号が、NoIncorrectPicOutput
Flagが1に等しい関連するGDRから開始するとき、不正確な再構成サンプル値を生成しても
よいことを指定する。存在しないとき、refreshed_region_flagの値は、1に等しいものと
推測される。

注x - 現在ピクチャ自体が、NoIncorrectPicOutputFlagが1に等しいGDRピクチャであり
得る。

タイルグループがリフレッシュされる境界は、次のように導出される。
tileColIdx = TopLeftTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = TopLeftTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedLeftBoundary = ColBd[ tileColIdx ] << CtbLog2SizeY
TGRefreshedTopBoundary = RowBd[ tileRowIdx ] << CtbLog2SizeY
tileColIdx = BottomRightTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = BottomRightTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedRightBoundary = ( ( ColBd[ tileColIdx ] + ColWidth[ tileColIdx ]
) << CtbLog2SizeY ) - 1
TGRefreshedRightBoundary = TGRefreshedRightBoundary > pic_width_in_luma_samp
les ? pic_width_in_luma_samples : TGRefreshedRightBoundary
TGRefreshedBotBoundary = ( ( RowBd[ tileRowIdx ] + RowHeight[ tileRowIdx ] )
<< CtbLog2SizeY ) - 1
TGRefreshedBotBoundary = TGRefreshedBotBoundary > pic_height_in_luma_samples
? pic_height_in_luma_samples : TGRefreshedBotBoundary

NALユニットヘッダのセマンティック。

...

nal_unit_typeがGDR_NUTに等しく、コーディングされたタイルグループがGDRピクチャ
に属するとき、TemporalIdは0に等しくなければならない。

アクセスユニットの順序およびCVSへの関連付けが説明される。

この仕様(すなわち、JVET寄稿JVET-M1001-v5)に適合するビットストリームは、1つ以上
のCVSを含む。

CVSは、1つ以上のアクセスユニットを含む。NALユニットおよびコーディングされたピ
クチャの順序、ならびにアクセスユニットへのそれらの関連付けが、第7.4.2.4.4節に記
載される。

CVSの最初のアクセスユニットは、以下のうちの1つである。

- NoBrokenPictureOutputFlagが1に等しいIRAPアクセスユニット。

- NoIncorrectPicOutputFlagが1に等しいGDRアクセスユニット。

存在するとき、エンドオブシーケンスNALユニットまたはエンドオブビットストリームN
ALユニットを含むアクセスユニットの後の次のアクセスユニットが、以下のうちの1つで
なければならないことが、ビットストリーム適合の要件である。

- IDRアクセスユニットまたはCRAアクセスユニットであってもよいIRAPアクセスユニッ
ト。

- GDRアクセスユニット。

8.1.1 コーディングされたピクチャのための復号プロセスが説明される。

...

現在ピクチャがIRAPピクチャであるとき、以下のことが適用される。

- 現在ピクチャが、IDRピクチャ、復号順序でビットストリームの中の最初のピクチャ
、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャである
とき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。

- そうではなく、この仕様で指定されないいくつかの外部手段(たとえば、ユーザ入力)
が、変数HandleCraAsCvsStartFlagを現在ピクチャに対する値に設定するために利用可能
であるとき、変数HandleCraAsCvsStartFlagは、外部手段によって提供される値に等しく
設定され、変数NoIncorrectPicOutputFlagは、HandleCraAsCvsStartFlagに等しく設定さ
れる。

- そうでない場合、変数HandleCraAsCvsStartFlagは、0に等しく設定され、変数NoInco
rrectPicOutputFlagは、0に等しく設定される。

現在ピクチャがGDRピクチャであるとき、以下のことが適用される。

- 現在ピクチャが、GDRピクチャ、復号順序でビットストリームの中の最初のピクチャ
、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャである
とき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。

- そうではなく、この仕様で指定されないいくつかの外部手段が、変数HandleGdrAsCvs
StartFlagを現在ピクチャに対する値に設定するために利用可能であるとき、変数HandleG
drAsCvsStartFlagは、外部手段によって提供される値に等しく設定され、変数NoIncorrec
tPicOutputFlagは、HandleGdrAsCvsStartFlagに等しく設定される。

- そうでない場合、変数HandleGdrAsCvsStartFlagは、0に等しく設定され、変数NoInco
rrectPicOutputFlagは、0に等しく設定される。

...

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

1. NALユニットの復号が第8.2節で指定される。

2. 第8.3節におけるプロセスは、タイルグループヘッダレイヤの中のシンタックス要素
を使用する以下の復号プロセス、および上記のことを指定する。

- ピクチャ順序カウントに関係する変数および関数が、第8.3.1節で指定されるように
導出される。これは、ピクチャの最初のタイルグループに対してのみ呼び出される必要が
ある。

- 非IDRピクチャのタイルグループごとの復号プロセスの開始において、参照ピクチャ
リスト0(RefPicList[ 0 ])および参照ピクチャリスト1(RefPicList[ 1 ])の導出のために
、第8.3.2節で指定される参照ピクチャリスト構成のための復号プロセスが呼び出される
。

- 第8.3.3節における参照ピクチャマーキングのための復号プロセスが呼び出され、参
照ピクチャは、「参照のために未使用」または「長期の参照のために使用済み」としてマ
ークされてもよい。これは、ピクチャの最初のタイルグループに対してのみ呼び出される
。

- PicOutputFlagは次のように設定される。

- 次の条件のうちの1つが真であるとき、PictureOutputFlagは、0に等しく設定される
。

- 現在ピクチャがRASLピクチャであり、関連するIRAPピクチャのNoIncorrectPicOutput
Flagが1に等しい。

- gdr_enabled_flagが1に等しく、現在ピクチャが、NoIncorrectPicOutputFlagが1に等
しいGDRピクチャである。

- gdr_enabled_flagが1に等しく、現在ピクチャが、refreshed_region_flagが0に等し
い1つ以上のタイルグループを含み、関連するGDRピクチャのNoBrokenPictureOutputFlag
が1に等しい。

- そうでない場合、PicOutputFlagは、1に等しく設定される。

3. 復号プロセスは、ツリーユニットをコーディングすること、スケーリング、変換、
ループ内フィルタ処理などのために呼び出される。

4. 現在ピクチャのすべてのタイルグループが復号された後、現在の復号ピクチャが「
短期の参照のために使用済み」としてマークされる。

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

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

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

現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoIncor
rectPicOutputFlagが1に等しいGDRピクチャでないとき、変数prevPicOrderCntLsbおよびp
revPicOrderCntMsbは、次のように導出される。

- 0に等しいTemporalIdを有するとともにRASLまたはRADLピクチャでない、復号順序で
前のピクチャを、prevTid0Picとする。

- 変数prevPicOrderCntLsbは、prevTid0Picのtile_group_pic_order_cnt_lsbに等しく
設定される。

- 変数prevPicOrderCntMsbは、prevTid0PicのPicOrderCntMsbに等しく設定される。

現在ピクチャの変数PicOrderCntMsbは、次のように導出される。

- 現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoInc
orrectPicOutputFlagが1に等しいGDRピクチャであるとき、PicOrderCntMsbは、0に等しく
設定される。

- そうでない場合、PicOrderCntMsbは、次のように導出される。
if( ( tile_group_pic_order_cnt_lsb < prevPicOrderCntLsb ) && ( ( prevPicOrde
rCntLsb - tile_group_pic_order_cnt_lsb ) >= ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb + MaxPicOrderCntLsb (8-1)
else if( (tile_group_pic_order_cnt_lsb > prevPicOrderCntLsb ) && ( ( tile_gr
oup_pic_order_cnt_lsb - prevPicOrderCntLsb ) > ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb - MaxPicOrderCntLsb
else
PicOrderCntMsb = prevPicOrderCntMsb
PicOrderCntValは、次のように導出される。
PicOrderCntVal = PicOrderCntMsb + tile_group_pic_order_cnt_lsb (8-2)

注1 - NoIncorrectPicOutputFlagが1に等しいIRAPピクチャに対してPicOrderCntMsbが0
に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのIRAPピクチャ
は、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。

注1 - NoIncorrectPicOutputFlagが1に等しいGDRピクチャに対してPicOrderCntMsbが0
に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのGDRピクチャは
、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。

PicOrderCntValの値は、両端値を含む-2³¹～2³¹ - 1という範囲の中になければならな
い。

現在ピクチャがGDRピクチャであるとき、LastGDRPocValの値は、PicOrderCntValに等し
くなるように設定される。

ピクチャがリフレッシュされた境界位置のための復号プロセスが説明される。

このプロセスは、gdr_enabled_flagが1に等しいときにしか呼び出されない。

このプロセスは、タイルグループヘッダ構文解析が完了した後に呼び出される。

このプロセスの出力は、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPo
s、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPos、すなわち、現在
ピクチャのリフレッシュ済みの領域の境界位置である。

コーディングされた各ピクチャは、PicOrderCntValとして示されるリフレッシュ済み領
域境界位置変数のセットに関連する。

PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoun
daryPos、およびPicRefreshedBotBoundaryPosは、次のように導出される。

タイルグループが、refreshed_region_flagが1に等しい現在ピクチャの最初の受信タイ
ルグループである場合、以下のことが適用される。

PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary

PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary

PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary

PicRefreshedBotBoundaryPos = TileGroupBotBoundary

そうではなく、refreshed_region_flagが1に等しい場合、以下のことが適用される。

PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary < PicRefreshedLeftBounda
ryPos ?

TGRefreshedLeftBoundary : PicRefreshedLeftBoundaryPos

PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary > PicRefreshedRightBou
ndaryPos ?

TGRefreshedRightBoundary : PicRefreshedRightBoundaryPos

PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary < PicRefreshedTopBoundaryP
os ?

TGRefreshedTopBoundary : RefreshedRegionTopBoundaryPos

PicRefreshedBotBoundaryPos = TileGroupBotBoundary > PicRefreshedBotBoundaryPos
?

TileGroupBotBoundary : PicRefreshedBotBoundaryPos

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

...

NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorrectPicOutputFlag
が1に等しいGDRピクチャでない、各現在ピクチャに対して、maxPicOrderCnt - minPicOrd
erCntの値がMaxPicOrderCntLsb / 2よりも小さくなければならないことが、ビットストリ
ーム適合の要件である。

...

参照ピクチャマーキングのための復号プロセス。

...

現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorre
ctPicOutputFlagが1に等しいGDRピクチャである場合、(もしあれば)現在、DPBの中の、す
べての参照ピクチャは、「参照のために未使用」としてマークされる。

...

時間ルーマ動きベクトル予測のための導出プロセスが説明される。

...

変数currCbは、ルーマロケーション( xCb, yCb )における現在ルーマコーディングブロ
ックを指定する。

変数mvLXColおよびavailableFlagLXColは、次のように導出される。

- tile_group_temporal_mvp_enabled_flagが0に等しい場合、mvLXColの両方の成分は、
0に等しく設定され、availableFlagLXColは、0に等しく設定される。

- そうでない(tile_group_temporal_mvp_enabled_flagが1に等しい)場合、以下の順序
付きステップが適用される。

1. 右下のコロケート動きベクトルが、次のように導出される。

xColBr = xCb + cbWidth (8-414)

yColBr = yCb + cbHeight (8-415)

leftBoundaryPos = gdr_enabled_flag ?

RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedLeftBoundar
yPos :

0 (8-415)

topBoundaryPos = gdr_enabled_flag ?

RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedTopBoundary
Pos :

0 (8-415)

rightBoundaryPos = gdr_enabled_flag ?

RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedRightBounda
ryPos :

pic_width_in_luma_samples (8-415)

botBoundaryPos = gdr_enabled_flag ?

RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedBotBoundary
Pos :

pic_height_in_luma_samples (8-415)

- yCb >> CtbLog2SizeYがyColBr >> CtbLog2SizeYに等しく、yColBrが、両端値を含むt
opBoundaryPosからbotBoundaryPosまでの範囲の中にあり、かつxColBrが、両端値を含むl
eftBoundaryPosからrightBoundaryPosまでの範囲の中にある場合、以下のことが適用され
る。

- 変数colCbは、ColPicによって指定されるコロケートピクチャの内側の、( ( xColBr
>> 3 ) << 3, ( yColBr >> 3 ) << 3 )によって与えられる修正済みのロケーションをカ
バーするルーマコーディングブロックを指定する。

- ルーマロケーション( xColCb, yColCb )は、ColPicによって指定されるコロケートピ
クチャの左上のルーマサンプルに対してcolCbによって指定されるコロケートルーマコー
ディングブロックの左上のサンプルに等しく設定される。

- 第8.5.2.12節で指定されるようなコロケート動きベクトルのための導出プロセスは、
入力としてcurrCb、colCb、( xColCb, yColCb )、refIdxLX、および0に等しく設定された
sbFlagとともに呼び出され、出力がmvLXColおよびavailableFlagLXColに割り当てられる
。

- そうでない場合、mvLXColの両方の成分は、0に等しく設定され、availableFlagLXCol
は、0に等しく設定される。

2. ...

ルーマサンプル双線形補間プロセスが説明される。

このプロセスの入力は、以下の通りである。

- フルサンプル単位でのルーマロケーション( xInt_L, yInt_L )、

- 分数サンプル単位でのルーマロケーション( xFrac_L, yFrac_L )、

- ルーマ参照サンプルアレイrefPicLX_L、

- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefres
hedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPo
s。

...

フルサンプル単位でのルーマロケーション( xInt_i, yInt_i )は、i = 0..1に対して次の
ように導出される。

- gdr_enabled_flagが1に等しい場合、以下のことが適用される。

xInt_i = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xInt
_L + i ) (8-458)

yInt_i = Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yInt_L +
i ) (8-458)

- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。

xInt_i = sps_ref_wraparound_enabled_flag ?

ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, ( xInt_L +
i ) ) : (8-459)

Clip3( 0, picW - 1, xInt_L + i )

yInti = Clip3( 0, picH - 1, yInt_L + i ) (8-460)

...

ルーマサンプル8タップ補間フィルタ処理プロセスが説明される。

このプロセスの入力は、以下の通りである。

- ルーマ参照サンプルアレイrefPicLX_L、

- 参照サンプルパディングの方向および量を指定する、dir = 0,1を伴うリストpadVal[
dir ]。

...

フルサンプル単位でのルーマロケーション( xInt_i, yInt_i )は、i = 0..7に対して次の
ように導出される。

- gdr_enabled_flagが1に等しい場合、以下のことが適用される。

xInt_i = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xInt
_L + i - 3 ) (8-830)

yInti= Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yInt_L +
i - 3 ) (8-830)

xInt_i = sps_ref_wraparound_enabled_flag ?

ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, xInt_L + i
- 3 ) : (8-831)

Clip3( 0, picW - 1, xInt_L + i - 3 )

yInt_i = Clip3( 0, picH - 1, yInt_L + i - 3 ) (8-832)

クロマサンプル補間プロセスが説明される。

このプロセスの入力は、以下の通りである。

- フルサンプル単位でのクロマロケーション( xInt_C, yInt_C )、

- 1/32分数サンプル単位でのクロマロケーション( xFrac_C, yFrac_C )、

- クロマ参照サンプルアレイrefPicLX_C。

...

変数xOffsetは、( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY ) / SubWi
dthCに等しく設定される。

フルサンプル単位でのクロマロケーション( xInt_i, yInt_i )は、i = 0..3に対して次の
ように導出される。

- gdr_enabled_flagが1に等しい場合、以下のことが適用される。

xInt_i = Clip3( PicRefreshedLeftBoundaryPos / SubWidthC,

PicRefreshedRightBoundaryPos / SubWidthC, xInt_L + i ) (8-844)

yInti = Clip3( PicRefreshedTopBoundaryPos / SubHeightC,

PicRefreshedBotBoundaryPos / SubHeightC, yInt_L + i ) (8-844)

xInt_i = sps_ref_wraparound_enabled_flag ? ClipH( xOffset, picW_C, xInt_C + i - 1
) : (8-845)

Clip3( 0, picW_C - 1, xInt_C + i - 1 )

yInt_i = Clip3( 0, picH_C - 1, yInt_C + i - 1 ) (8-846)

デブロッキングフィルタプロセスが説明される。

全般的なプロセス。

...

デブロッキングフィルタプロセスは、以下のタイプのエッジを除いて、ピクチャのすべ
てのコーディングサブブロックエッジおよび変換ブロックエッジに適用される。

- ピクチャの境界にあるエッジ。

- 以下のことのすべてが満たされるとき、タイルグループ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_across_tiles_enabled_flagが0に等しいとき、タイル境界に一致するエ
ッジ。

- tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しいかまたはtil
e_group_deblocking_filter_disabled_flagが1に等しいタイルグループの、上または左の
境界に一致するエッジ。

- tile_group_deblocking_filter_disabled_flagが1に等しいタイルグループ内のエッ
ジ。

- 考慮される成分の8×8サンプルグリッド境界に対応しないエッジ。

- エッジの両側がインター予測を使用するクロマ成分内のエッジ。

- 関連する変換ユニットのエッジでないクロマ変換ブロックのエッジ。

- IntraSubPartitionsSplit値がISP_NO_SPLITに等しくないコーディングユニットのル
ーマ変換ブロックを横断するエッジ。

一方向のためのデブロッキングフィルタプロセスが説明される。

...

コーディングブロック幅log2CbW、コーディングブロック高さlog2CbH、およびコーディ
ングブロックの左上のサンプルのロケーション( xCb, yCb )を有するコーディングユニッ
トごとに、edgeTypeがEDGE_VERに等しくxCb % 8が0に等しいとき、またはedgeTypeがEDGE
_HORに等しくyCb % 8が0に等しいとき、以下の順序付きステップによってエッジがフィル
タ処理される。

1. コーディングブロック幅nCbWが、1 << log2CbWに等しく設定され、コーディングブ
ロック高さnCbHが、1 << log2CbHに等しく設定される。

2. 変数filterEdgeFlagが、次のように導出される。

- edgeTypeがEDGE_VERに等しく、かつ次の条件のうちの1つ以上が真である場合、filt
erEdgeFlagは、0に等しく設定される。

- 現在コーディングブロックの左の境界がピクチャの左の境界である。

- 現在コーディングブロックの左の境界がタイルの左の境界であり、loop_filter_acr
oss_tiles_enabled_flagが0に等しい。

- 現在コーディングブロックの左の境界がタイルグループの左の境界であり、tile_gr
oup_loop_filter_across_tile_groups_enabled_flagが0に等しい。

- 現在コーディングブロックの左の境界が現在タイルグループの左の境界であり、次
のすべての条件が満たされる。

- gdr_enabled_flagが1に等しい。

- loop_filter_across_refreshed_region_enabled_flagが0に等しい。

- 現在タイルグループの左の境界と境界を共有したタイルグループが存在し、そのref
reshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる
。

- そうではなく、edgeTypeがEDGE_HORに等しく、かつ次の条件のうちの1つ以上が真で
ある場合、変数filterEdgeFlagは、0に等しく設定される。

- 現在ルーマコーディングブロックの上の境界がピクチャの上の境界である。

- 現在コーディングブロックの上の境界がタイルの上の境界であり、loop_filter_acr
oss_tiles_enabled_flagが0に等しい。

- 現在コーディングブロックの上の境界がタイルグループの上の境界であり、tile_gr
oup_loop_filter_across_tile_groups_enabled_flagが0に等しい。

- 現在コーディングブロックの上の境界が現在タイルグループの上の境界であり、次
のすべての条件が満たされる。

- gdr_enabled_flagが1に等しい。

- loop_filter_across_refreshed_region_enabled_flagが0に等しい。

- 現在タイルグループの上の境界と境界を共有したタイルグループが存在し、そのref
reshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる
。

- そうでない場合、filterEdgeFlagは、1に等しく設定される。

タイルが統合されると、シンタックスを適合させる。

3. 二次元(nCbW)×(nCbH)アレイedgeFlagsのすべての要素は、0に等しくなるように初
期化される。

SAOのためのCTB修正プロセスが説明される。

...

i = 0..nCtbSw - 1かつj = 0..nCtbSh - 1を伴うすべてのサンプルロケーション( xS_i,
yS_j )および( xY_i, yY_j )に対して、recPicture[ xSi ][ ySj ]をカバーするコーディン
グブロックを含むコーディングユニットのpcm_loop_filter_disabled_flag、pcm_flag[ x
Y_i ][ yY_j ]、およびcu_transquant_bypass_flagの値に応じて、以下のことが適用される
。

- ....

将来決定変換/量子化バイパスにおいて保留中の強調されたセクションを修正する。

- そうではなく、SaoTypeIdx[ cIdx ][ rx ][ ry ]が2に等しい場合、以下の順序付き
ステップが適用される。

1. k = 0..1に対するhPos[ k ]およびvPos[ k ]の値が、SaoEoClass[ cIdx ][ rx ][ r
y ]に基づいて表8-18の中で指定される。

2. 変数edgeIdxが、次のように導出される。

- 修正済みのサンプルロケーション( xS_ik', yS_jk' )および( xY_ik', yY_ik' )が、次
のように導出される。

( xS_ik', yS_jk' ) = ( xS_i + hPos[ k ], yS_j + vPos[ k ] ) (8-1128)

( xY_ik', yY_jk' ) = ( cIdx = = 0 ) ? ( xS_ik', yS_jk' ) : ( xS_ik' * SubWidthC, yS
_jk' * SubHeightC ) (8-1129)

- k = 0..1を伴うすべてのサンプルロケーション( xS_ik', yS_jk' )および( xY_ik', yY
_jk' )に対して次の条件のうちの1つ以上が真である場合、edgeIdxは、0に等しく設定され
る。

- ロケーション( xS_ik', yS_jk' )におけるサンプルが、ピクチャ境界の外側にある。

- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_fla
gが0に等しく、現在タイルグループのrefreshed_region_flagが1に等しく、かつロケーシ
ョン( xS_ik', yS_jk' )におけるサンプルを含むタイルグループのrefreshed_region_flag
が0に等しい。

- ロケーション( xS_ik', yS_jk' )におけるサンプルが、異なるタイルグループに属し
、次の2つの条件のうちの1つが真である。

- MinTbAddrZs[ xY_ik' >> MinTbLog2SizeY ][ yY_jk' >> MinTbLog2SizeY ]がMinTbAdd
rZs[ xY_i >> MinTbLog2SizeY ][ yY_j >> MinTbLog2SizeY ]よりも小さく、サンプルrecPi
cture[ xS_i ][ yS_j ]が属するタイルグループの中のtile_group_loop_filter_across_til
e_groups_enabled_flagが0に等しい。

- MinTbAddrZs[ xY_i >> MinTbLog2SizeY ][ yY_j >> MinTbLog2SizeY ]がMinTbAddrZs[
xY_ik' >> MinTbLog2SizeY ][ yY_jk' >> MinTbLog2SizeY ]よりも小さく、サンプルrecPic
ture[ xS_ik' ][ yS_jk' ]が属するタイルグループの中のtile_group_loop_filter_across_
tile_groups_enabled_flagが0に等しい。

- loop_filter_across_tiles_enabled_flagが0に等しく、ロケーション( xS_ik', yS_jk
_' )におけるサンプルが、異なるタイルに属する。

タイルグループを有しないタイルが組み込まれるとき、強調されたセクションを修正す
る。

- そうでない場合、edgeIdxは、次のように導出される。

- 以下のことが適用される。

edgeIdx = 2 + Sign( recPicture[ xS_i ][ yS_j ] - recPicture[ xS_i + hPos[ 0 ] ][
yS_j + vPos[ 0 ] ] ) +

Sign( recPicture[ xS_i ][ yS_j ] - recPicture[ xS_i + hPos[ 1 ] ][ yS_j + vPos[
1 ] ] ) (8-1130)

- edgeIdxが0、1、または2に等しいとき、edgeIdxは次のように修正される。

edgeIdx = ( edgeIdx = = 2 ) ? 0 : ( edgeIdx + 1 ) (8-1131)

3. 修正済みのピクチャサンプルアレイsaoPicture[ xS_i ][ yS_j ]が、次のように導出
される。

saoPicture[ xS_i ][ yS_j ] = Clip3( 0, ( 1 << bitDepth ) - 1, recPicture[ xS_i ][
yS_j ] +

SaoOffsetVal[ cIdx ][ rx ][ ry ][ edgeIdx ] ) (8-1132)

ALFのためのルーマサンプルに対するコーディングツリーブロックフィルタ処理プロセ
スが説明される。

...

フィルタ処理済みの再構成ルーマサンプルalfPictureL[ x ][ y ]の導出のために、現
在のルーマコーディングツリーブロックの内側の各再構成ルーマサンプルrecPictureL[ x
][ y ]が、x, y = 0..CtbSizeY - 1を伴って次のようにフィルタ処理される。

- ...

- ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y
)の各々に対するロケーション( h_x, v_y )は、次のように導出される。

- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_fl
agが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgA
のrefreshed_region_flagが1に等しい場合、以下のことが適用される。

- ロケーション( h_x, v_y )が別のタイルグループtgBの中に位置し、かつtgBのrefresh
ed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、お
よびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、
TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。

- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoun
daryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、Pic
RefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。

h_x = Clip3( leftBoundary, rightBoundary, xCtb + x ) (8-1140)

v_y = Clip3( topBoundary, botBoundary, yCtb + y ) (8-1141)

- そうでない場合、以下のことが適用される。

h_x = Clip3( 0, pic_width_in_luma_samples - 1, xCtb + x ) (8-1140)

v_y = Clip3( 0, pic_height_in_luma_samples - 1, yCtb + y ) (8-1141)

- ...

ルーマサンプルに対するALF転置およびフィルタインデックスのための導出プロセスが
説明される。

...

ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y )の
各々に対するロケーション( h_x, v_y )が、次のように導出される。

h_x = Clip3( leftBoundary, rightBoundary, x ) (8-1140)

v_y = Clip3( topBoundary, botBoundary, y ) (8-1141)

- そうでない場合、以下のことが適用される。

h_x = Clip3( 0, pic_width_in_luma_samples - 1, x ) (8-1145)

v_y = Clip3( 0, pic_height_in_luma_samples - 1, y ) (8-1146)

クロマサンプルのためのコーディングツリーブロックフィルタ処理プロセスが説明され
る。

...

フィルタ処理済みの再構成クロマサンプルalfPicture[ x ][ y ]の導出のために、現在
のクロマコーディングツリーブロックの内側の各再構成クロマサンプルrecPicture[ x ][
y ]が、x, y = 0..ctbSizeC - 1を伴って次のようにフィルタ処理される。

- クロマサンプルの所与のアレイrecPictureの内側の対応するクロマサンプル( x, y
)の各々に対するロケーション( h_x, v_y )が、次のように導出される。

h_x = Clip3( leftBoundary / SubWidthC, rightBoundary / SubWidthC, xCtbC + x ) (
8-1140)

v_y = Clip3( topBoundary / SubWidthC, botBoundary / SubWidthC, yCtbC + y ) (8-1
141)

- そうでない場合、以下のことが適用される。

h_x = Clip3( 0, pic_width_in_luma_samples / SubWidthC - 1, xCtbC + x ) (8-1177)

v_y = Clip3( 0, pic_height_in_luma_samples / SubHeightC - 1, yCtbC + y ) (8-117
8)

図7は、本開示の一実施形態に係る、漸進的復号リフレッシュ(GDR)技法700を実施する
ように構成されたビデオビットストリーム750を示す。GDR技法700は、図5のGDR技法500と
類似であってもよい。本明細書で使用するビデオビットストリーム750は、コーディング
されたビデオビットストリーム、ビットストリーム、またはそれらの変形とも呼ばれても
よい。図7に示すように、ビットストリーム750は、シーケンスパラメータセット(SPS:seq
uence parameter set)752、ピクチャパラメータセット(PPS:picture parameter set)754
、スライスヘッダ756、および画像データ758を備える。

SPS752は、ピクチャのシーケンス(SOP:sequence of pictures)の中のすべてのピクチャ
に共通のデータを含む。対照的に、PPS754は、ピクチャ全体に共通のデータを含む。スラ
イスヘッダ756は、たとえば、スライスタイプ、参照ピクチャのうちのどれが使用される
のかなどの、現在スライスについての情報を含む。SPS752およびPPS754は、パラメータセ
ットと総称されてもよい。SPS752、PPS754、およびスライスヘッダ756は、ネットワーク
アブストラクションレイヤ(NAL)ユニットのタイプである。NALユニットは、後続すべきデ
ータ(たとえば、コーディングされたビデオデータ)のタイプの表示を含むシンタックス構
造である。NALユニットは、ビデオコーディングレイヤ(VCL)NALユニットおよび非VCL NAL
ユニットに分類される。VCL NALユニットは、ビデオピクチャの中のサンプルの値を表す
データを含み、非VCL NALユニットは、パラメータセット(多数のVCL NALユニットに適用
され得る重要なヘッダデータ)などの関連する任意の追加情報、および補足エンハンスメ
ント情報(タイミング情報、および復号ビデオ信号の有用性を向上させ得るが、ビデオピ
クチャの中のサンプルの値を復号するために必要でない、他の追加データ)を含む。ビッ
トストリーム750が、実際の適用例では他のパラメータおよび情報を含んでもよいことを
、当業者は諒解されよう。

図7の画像データ758は、符号化中または復号中の画像またはビデオに関連するデータを
備える。画像データ758は、単に、ペイロード、またはビットストリーム750の中で搬送中
のデータと呼ばれてもよい。一実施形態では、画像データ758は、GDRピクチャ702、1つ以
上のトレーリングピクチャ704、およびリカバリポイントピクチャ706を含む、CVS708(ま
たは、CLVS)を備える。一実施形態では、トレーリングピクチャ704は、GDR期間の中でリ
カバリポイントピクチャ706に先行するので、GDRピクチャの形式と見なされてもよい。

一実施形態では、GDRピクチャ702、トレーリングピクチャ704、およびリカバリポイン
トピクチャ706は、CVS708の中のGDR期間を規定してもよい。一実施形態では、復号順序は
、GDRピクチャ702で始まり、トレーリングピクチャ704に続き、次いで、リカバリピクチ
ャ706に進む。

ユーザインターフェース84を介してビデオデコーダ30によって値(たとえば、1)が受け
取られると、GDRピクチャ702および出力順序(たとえば、提示順序410)でGDRピクチャ702
とリカバリポイントピクチャ706との間の任意のトレーリングピクチャ704が出力されるこ
とを防止するために、第1のフラグはユーザインターフェース(たとえば、外部入力)によ
って提供される値に等しく設定され、第2のフラグは第1のフラグに等しく設定される。そ
うではなく、ユーザインターフェース84を介してビデオコーダ30によって値が受け取られ
ないとき、第1のフラグおよび第2のフラグは異なる値(たとえば、0)に等しく設定される
。一実施形態では、第1のフラグが、ユーザインターフェースによって提供される値に等
しく設定されるとき、GDRピクチャ702だけが出力されることを防止される。

CVS708は、ビデオビットストリーム750の中のすべてのコーディングされたレイヤビデ
オシーケンス(CLVS)に対するコーディングされたビデオシーケンスである。特に、ビデオ
ビットストリーム750が単一のレイヤを含むとき、CVSとCLVSとは同じである。ビデオビッ
トストリーム750が複数のレイヤを含むときのみ、CVSとCLVSとは異なる。

図7に示すように、GDR技法700または原理は、GDRピクチャ702で開始しリカバリポイン
トピクチャ706で終了する一連のピクチャにわたって機能する。GDR技法700、GDRピクチャ
702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は、図5のGDR技法5
00、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイントピクチャ506と
類似である。したがって、簡潔のために、GDR技法700が実施される方式は、図7に関して
繰り返さない。

図7に示すように、CVS708の中のGDRピクチャ702、トレーリングピクチャ704、およびリ
カバリポイントピクチャ706は各々、それら自体のVCL NALユニット730内に含まれる。CVS
708の中のVCL NALユニット730のセットは、アクセスユニットと呼ばれてもよい。

CVS708の中のGDRピクチャ702を含むNALユニット730は、GDR NALユニットタイプ(GDR_NU
T)を有する。すなわち、一実施形態では、CVS708の中のGDRピクチャ702を含むNALユニッ
ト730は、トレーリングピクチャ704およびリカバリポイントピクチャ706に対してそれ自
体の固有のNALユニットタイプを有する。一実施形態では、GDR_NUTは、ビットストリーム
750がIRAPピクチャで始まる必要があるのではなく、ビットストリーム750がGDRピクチャ7
02で始まることを可能にする。GDRピクチャ702のVCL NALユニット730をGDR_NUTとして指
定することは、CVS708の中の初期VCL NALユニット730がGDRピクチャ702を含むことを、た
とえば、デコーダに示してもよい。

一実施形態では、GDRピクチャ702はCVS708の中の初期ピクチャである。一実施形態では
、GDRピクチャ702はGDR期間の中の初期ピクチャである。一実施形態では、GDRピクチャ70
2は0に等しい時間識別子(ID)を有する。時間IDは、他のピクチャに対するピクチャの位置
または順序を識別する値または数である。一実施形態では、GDR_NUTを有するVCL NALユニ
ット730を含むアクセスユニットは、GDRアクセスユニットと指定される。一実施形態では
、GDRピクチャ702は、別の(たとえば、より大きい)GDRピクチャのコーディングされたス
ライスである。すなわち、GDRピクチャ702は、より大きいGDRピクチャの一部分であって
もよい。

図8は、ビデオデコーダ(たとえば、ビデオデコーダ30)によって実施される、コーディ
ングされたビデオビットストリームを復号する方法800の一実施形態である。方法800は、
ビデオエンコーダ(たとえば、ビデオエンコーダ20)から復号ビットストリームが直接また
は間接的に受信された後に実行されてもよい。方法800は、IRAPピクチャを使用する必要
なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とするので、
本方法は復号プロセスを改善する。GDRピクチャが出力されることを防止するために、フ
ラグの値はユーザインターフェース(たとえば、図3の中のユーザインターフェース84、ま
たはいくつかの他の外部手段)を介してビデオデコーダのユーザによって設定される。一
実施形態では、GDRピクチャおよび出力順序でGDRピクチャとリカバリポイントピクチャと
の間の任意のトレーリングピクチャが出力されることを防止するために、フラグの値はユ
ーザインターフェース(たとえば、図3の中のユーザインターフェース84、またはいくつか
の他の外部手段)を介してビデオデコーダのユーザによって設定される。このようにして
フラグを設定することは、潜在的にダーティなデータがディスプレイに出力されることを
防止し、ビデオデコーダがユーザの選好に従って動作することを可能にする。したがって
、実際問題として、コーデックの性能が改善され、そのことはより良好なユーザエクスペ
リエンスにつながる。

ブロック802において、ビデオデコーダは、第1のフラグに対する値が外部入力(たとえ
ば、図3の中のユーザインターフェース84、またはいくつかの他の外部手段)によって提供
されるかどうかを決定する。一実施形態では、外部入力は、ビデオデコーダのグラフィッ
クユーザインターフェース(GUI)である。一実施形態では、ビデオデコーダのユーザが、
外部入力を使用して第1のフラグの値を提供する。一実施形態では、第1のフラグはHandle
GdrAsCvsStartFlagと指定される。

ブロック804において、ビデオデコーダは、第1のフラグに対する値が外部入力によって
提供されるとき、漸進的復号リフレッシュ(GDR)ピクチャ(たとえば、GDRピクチャ702)お
よび出力順序でGDRピクチャ702とリカバリポイントピクチャ706との間の任意のトレーリ
ングピクチャ704が出力されることを防止するために、第1のフラグを、外部入力によって
提供される値に等しく、かつ第2のフラグを第1のフラグに等しく設定する。一実施形態で
は、GDRピクチャおよび出力順序でGDRピクチャとリカバリポイントピクチャとの間の任意
のトレーリングピクチャが出力されることを防止するために、第1のフラグの値は1に設定
される。一実施形態では、第1のフラグに対する値が外部入力によって提供されないとき
、第1のフラグの値は0に設定される。

一実施形態では、GDRピクチャは、コーディングされたビデオビットストリームのCVSの
中の初期ピクチャである。一実施形態では、GDRピクチャは、コーディングされたビデオ
ビットストリームのレイヤの中の初期ピクチャである。一実施形態では、レイヤは、コー
ディングされたビデオビットストリームのCVSのCLVSである。

ブロック806において、ビデオデコーダは、GDRピクチャを復号する。トレーリングピク
チャおよびリカバリポイントピクチャが、次いで、順に復号される。ブロック808におい
て、ビデオデコーダは、GDRピクチャを復号ピクチャバッファ(DPB)の中に記憶する。一実
施形態では、第1および第2のフラグの設定によって、GDRピクチャが出力されることを制
限されていないとき、GDRピクチャに基づいて生成された画像が、電子デバイス(たとえば
、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のユーザ
のために表示されてもよい。

図9は、本開示の一実施形態に係るビデオコーディングデバイス900(たとえば、ビデオ
エンコーダ20またはビデオデコーダ30)の概略図である。ビデオコーディングデバイス900
は、本明細書で説明するような、開示する実施形態を実施するのに適している。ビデオコ
ーディングデバイス900は、データを受信するための入口ポート910および受信機ユニット
(Rx)920、データを処理するためのプロセッサ、論理ユニット、または中央演算処理装置(
CPU)930、データを送信するための送信機ユニット(Tx)940および出口ポート950、ならび
にデータを記憶するためのメモリ960を備える。ビデオコーディングデバイス900はまた、
光信号または電気信号の出口または入口のために、入口ポート910、受信機ユニット920、
送信機ユニット940、および出口ポート950に結合された、光電気(OE:optical-to-electri
cal)構成要素および電気光(EO:electrical-to-optical)構成要素を備えてもよい。

プロセッサ930は、ハードウェアおよびソフトウェアによって実装される。プロセッサ9
30は、1つ以上のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールド
プログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号
プロセッサ(DSP)として実装されてもよい。プロセッサ930は、入口ポート910、受信機ユ
ニット920、送信機ユニット940、出口ポート950、およびメモリ960と通信している。プロ
セッサ930はコーディングモジュール970を備える。コーディングモジュール970は、上記
で説明した開示する実施形態を実施する。たとえば、コーディングモジュール970は、様
々なコーデック機能を実施、処理、準備、または提供する。したがって、コーディングモ
ジュール970を含むことは、ビデオコーディングデバイス900の機能への大幅な改善をもた
らし、異なる状態へのビデオコーディングデバイス900の変換に影響を及ぼす。代替的に
、コーディングモジュール970は、メモリ960の中に記憶されプロセッサ930によって実行
される命令として実装される。

ビデオコーディングデバイス900はまた、ユーザとの間でデータを通信するための入力
および/または出力(I/O)デバイス980を含んでもよい。I/Oデバイス980は、ビデオデータ
を表示するためのディスプレイ、オーディオデータを出力するためのスピーカーなどの、
出力デバイスを含んでもよい。I/Oデバイス980はまた、キーボード、マウス、トラックボ
ールなどの入力デバイス、および/またはそのような出力デバイスと相互作用するための
対応するインターフェースを含んでもよい。一実施形態では、I/Oデバイス980は、第1の
フラグの値を入力するためにビデオコーディングデバイス900のユーザによって利用され
る外部手段である。

メモリ960は、プログラムが実行のために選択されるときにそのようなプログラムを記
憶するために、またプログラム実行中に読み取られる命令およびデータを記憶するために
、1つ以上のディスク、テープドライブ、およびソリッドステートドライブを備え、オー
バーフローデータ記憶デバイスとして使用されてもよい。メモリ960は、揮発性および/ま
たは不揮発性であってもよく、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、
3元連想メモリ(TCAM:ternary content-addressable memory)、および/またはスタティッ
クランダムアクセスメモリ(SRAM)であってもよい。

図10は、コーディングするための手段1000の一実施形態の概略図である。一実施形態で
は、コーディングするための手段1000は、ビデオコーディングデバイス1002(たとえば、
ビデオエンコーダ20またはビデオデコーダ30)の中に実装される。ビデオコーディングデ
バイス1002は受信手段1001を含む。受信手段1001は、符号化すべきピクチャを受信するか
、または復号すべきビットストリームを受信するように構成される。ビデオコーディング
デバイス1002は、受信手段1001に結合された送信手段1007を含む。送信手段1007は、ビッ
トストリームをデコーダへ送信するか、または復号画像を表示手段(たとえば、I/Oデバイ
ス1080のうちの1つ)へ送信するように構成される。

ビデオコーディングデバイス1002は記憶手段1003を含む。記憶手段1003は、受信手段10
01または送信手段1007のうちの少なくとも1つに結合される。記憶手段1003は、命令を記
憶するように構成される。ビデオコーディングデバイス1002はまた、処理手段1005を含む
。処理手段1005は、記憶手段1003に結合される。処理手段1005は、本明細書で開示する方
法を実行するために、記憶手段1003の中に記憶された命令を実行するように構成される。

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

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

加えて、様々な実施形態において個別または別個として説明および図示される技法、シ
ステム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステ
ム、モジュール、技法、または方法と組み合わせられても、または統合されてもよい。結
合されるかもしくは直接結合されるか、または互いに通信するものとして、図示または説
明される他の項目は、電気的か、機械的か、または別の方法であるかにかかわらず、いく
つかのインターフェース、デバイス、または中間構成要素を通じて、間接的に結合されて
も、または通信していてもよい。変更、置換、および改変の他の例は、当業者によって確
認可能であり、本明細書で開示する趣旨および範囲から逸脱することなく行うことができ
る。

10 コーディングシステム
12 ソースデバイス、ビデオデバイス
14 宛先デバイス
16 コンピュータ可読媒体
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
32 ディスプレイデバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 区分ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピーコーディングユニット、エントロピー符号化ユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 参照フレームメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 参照フレームメモリ
84 ユーザインターフェース(UI)
402 IRAPピクチャ
404 リーディングピクチャ
406 トレーリングピクチャ
408 復号順序
410 提示順序
502 GDRピクチャ
504 トレーリングピクチャ
506 リカバリポイントピクチャ
508 コーディングされたビデオシーケンス
510 リフレッシュ済みの/クリーンな領域
512 リフレッシュされていない/ダーティな領域
602 現在ピクチャ
604 参照ピクチャ、リフレッシュ済みの領域
606 リフレッシュ済みの領域
608 リフレッシュされていない領域、リフレッシュ済みの領域
610 動きベクトル
612 参照ブロック
614 現在ブロック
702 GDRピクチャ
704 トレーリングピクチャ
706 リカバリポイントピクチャ
708 CVS
730 NALユニット
750 ビデオビットストリーム
752 シーケンスパラメータセット(SPS)
754 ピクチャパラメータセット(PPS)
756 スライスヘッダ
758 画像データ
900 ビデオコーディングデバイス
910 入口ポート
920 受信機ユニット(Rx)
930 プロセッサ、論理ユニット、中央演算処理装置(CPU)
940 送信機ユニット(Tx)
950 出口ポート
960 メモリ
970 コーディングモジュール
980 入力および/または出力(I/O)デバイス
1000 コーディングするための手段
1001 受信手段
1002 ビデオコーディングデバイス
1003 記憶手段
1005 処理手段
1007 送信手段

Claims

ビデオエンコーダによって実施される方法であって、
第1のフラグに対する値が外部手段によって提供されるかどうかを決定するステップと、
前記第1のフラグに対する前記値が前記外部手段によって提供されるとき、コーディングされた漸進的復号リフレッシュ(GDR)ピクチャが出力されることを防止するために、前記第1のフラグの値を、前記外部手段によって提供される前記値に等しく、かつ第2のフラグの値を前記第1のフラグの前記値に等しく、設定するステップと、
前記コーディングされたGDRピクチャを符号化するステップと
を含む、方法。
前記第1のフラグに対する前記値が前記外部手段によって提供されるとき、出力順序で前記コーディングされたGDRピクチャとリカバリポイントピクチャとの間の任意のトレーリングピクチャが出力されることをさらに防止するために、前記第2のフラグの前記値が前記第1のフラグの前記値に等しく設定される、請求項1に記載の方法。
前記外部手段は、前記ビデオエンコーダのグラフィックユーザインターフェース(GUI)であり、前記第1のフラグの前記値は、前記外部手段を使用して前記ビデオエンコーダのユーザによって提供される、請求項1に記載の方法。
前記第1のフラグはHandleGdrAsCvsStartFlagと指定される、請求項1に記載の方法。
前記コーディングされたGDRピクチャおよび出力順序で前記コーディングされたGDRピクチャと前記リカバリポイントピクチャとの間の任意のトレーリングピクチャが出力されることを防止するために、前記第2のフラグの前記値は1に設定される、請求項2に記載の方法。
前記第1のフラグに対する前記値が前記外部手段によって提供されないとき、前記第1のフラグの前記値は0に設定される、請求項1に記載の方法。
符号化デバイスであって、
符号化すべきピクチャを受信するように構成された受信機と、
前記受信機に結合されたメモリであって、命令を記憶する、メモリと、
前記メモリに結合されたプロセッサとを備え、前記プロセッサは、前記符号化デバイスに、
第1のフラグに対する値が外部手段によって提供されるかどうかを決定することと、
前記第1のフラグに対する前記値が前記外部手段によって提供されるとき、コーディングされた漸進的復号リフレッシュ(GDR)ピクチャが出力されることを防止するために、前記第1のフラグの値を、前記外部手段によって提供される前記値に等しく、かつ第2のフラグの値を前記第1のフラグの前記値に等しく設定することと、
前記コーディングされたGDRピクチャを符号化することと
をさせるために、前記命令を実行するように構成される、
符号化デバイス。
前記第1のフラグに対する前記値が前記外部手段によって提供されるとき、コーディングされた漸進的復号リフレッシュ(GDR)ピクチャおよび出力順序で前記コーディングされたGDRピクチャとリカバリポイントピクチャとの間の任意のトレーリングピクチャが出力されることをさらに防止するために、前記第2のフラグの前記値は前記第1のフラグの前記値に等しく設定される、請求項7に記載の符号化デバイス。
前記外部手段は、ビデオエンコーダのグラフィックユーザインターフェース(GUI)であり、前記第1のフラグの前記値は、前記外部手段を使用して前記ビデオエンコーダのユーザによって提供される、請求項7に記載の符号化デバイス。
前記第1のフラグはHandleGdrAsCvsStartFlagと指定される、請求項7に記載の符号化デバイス。
前記コーディングされたGDRピクチャおよび出力順序で前記コーディングされたGDRピクチャと前記リカバリポイントピクチャとの間の任意のトレーリングピクチャが出力されることを防止するために、前記第2のフラグの前記値は1に設定される、請求項8に記載の符号化デバイス。
前記第1のフラグに対する前記値が前記外部手段によって提供されないとき、前記第1のフラグの前記値は0に設定される、請求項7に記載の符号化デバイス。
符号化すべきピクチャを受信するように構成された受信機と、
前記受信機に結合された送信機であって、ビットストリームをデコーダへ送信するように構成された、送信機と、
前記受信機または前記送信機のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成された、メモリと、
前記メモリに結合されたプロセッサであって、請求項1から6のいずれか一項に記載の方法を実行するために、前記メモリの中に記憶された前記命令を実行するように構成された、プロセッサと
を備える、コーディング装置。
デコーダと、
前記デコーダと通信しているエンコーダであって、請求項7から13のいずれか一項に記載の符号化デバイスまたはコーディング装置を含む、エンコーダと、
を備える、システム。
符号化すべきピクチャを受信するように構成された、受信手段と、
前記受信手段に結合された送信手段であって、ビットストリームを復号手段へ送信するように構成された、送信手段と、
前記受信手段または前記送信手段のうちの少なくとも1つに結合された記憶手段であって、命令を記憶するように構成された、記憶手段と、
前記記憶手段に結合された処理手段であって、請求項1から6のいずれか一項に記載の方法を実行するために、前記記憶手段の中に記憶された前記命令を実行するように構成された、処理手段と
を備える、コーディングするための手段。
第1のフラグに対する値が外部手段によって提供されるかどうかを決定することと、前記第1のフラグに対する前記値が前記外部手段によって提供されるとき、コーディングされた漸進的復号リフレッシュ(GDR)ピクチャが出力されることを防止するために、前記第1のフラグの値を、前記外部手段によって提供される前記値に等しく、かつ第2のフラグの値を前記第1のフラグの前記値に等しく設定することとを行うように構成された、決定ユニットと、
前記コーディングされたGDRピクチャを符号化するように構成された符号化ユニットと
を備える、エンコーダ。
ビデオコーディングデバイスによる使用のためのコンピュータプログラムを含む、非一時的コンピュータ可読媒体であって、前記コンピュータプログラムは前記非一時的コンピュータ可読媒体に記憶されたコンピュータによって実行可能な命令であって、プロセッサによって実行されたときに、前記ビデオコーディングデバイスに請求項１から６のいずれか一項に記載の方法を行わせるような命令を含むコンピュータプログラムを含む、非一時的コンピュータ可読媒体。
複数のシンタックス要素を含むビデオ信号のための符号化されたビットストリームを記憶および送信するための装置であって、
符号化すべきピクチャを受信するように構成された受信機と、
命令を記憶したメモリと、
前記ビデオ信号のための符号化されたビットストリームを送信するように構成された送信機と、
前記受信機、前記メモリおよび前記送信機に結合されたプロセッサとを備え、
前記プロセッサによって実行されたときに、前記命令が前記プロセッサに、
第1のフラグに対する値が外部手段によって提供されるかどうかを決定することと、
前記第1のフラグに対する値が外部手段によって提供されるとき、コーディングされた漸進的復号リフレッシュ(GDR)ピクチャが出力されることを防止するために、前記第1のフラグの値を、前記外部手段によって提供される前記値に等しく、かつ第2のフラグの値を前記第1のフラグの値に等しく設定することと、
GDRピクチャをコーディングすることと、
前記コーディングされたGDRと、前記第1のフラグおよび前記第2のフラグを含んだ前記複数のシンタックス要素とを含む、前記ビデオ信号のための符号化されたビットストリームを前記メモリに記憶することと、
を実行させる、装置。