特許7359871ビデオコーディングにおいて新たなコーディングされているビデオシーケンスを開始するピクチャのための前のピクチャの出力
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-02
(45)【発行日】2023-10-11
(54)【発明の名称】ビデオコーディングにおいて新たなコーディングされているビデオシーケンスを開始するピクチャのための前のピクチャの出力
(51)【国際特許分類】
H04N 19/70 20140101AFI20231003BHJP
H04N 19/503 20140101ALI20231003BHJP
H04N 19/593 20140101ALI20231003BHJP
【ＦＩ】
H04N19/70
H04N19/503
H04N19/593
【請求項の数】
8
(21)【出願番号】P 2021566093
(86)(22)【出願日】2020-05-01
(65)【公表番号】
(43)【公表日】2022-07-06
(86)【国際出願番号】 US2020030943
(87)【国際公開番号】W WO2020227060
(87)【国際公開日】2020-11-12
【審査請求日】2022-01-17
(31)【優先権主張番号】62/843,991
(32)【優先日】2019-05-06
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ワン，イエクォイ
【審査官】田中 純一
(56)【参考文献】
【文献】特表２０１７－５０７５４２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１５／０１９５５４５（ＵＳ，Ａ１）
【文献】Ye-Kui Wang, 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，2019年06月20日，pp.1-3
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ７／１２
Ｈ０４Ｎ １９／００ － １９／９８
(57)【特許請求の範囲】
【請求項1】
ビデオデコーダが実装する復号化の方法であって、コーディングされているビデオビットストリームを前記ビデオデコーダによって受信するステップであって、前記コーディングされているビデオビットストリームは、第1の値を有する第1のフラグ及びコーディングされているクリーンランダムアクセス(CRA)ピクチャを含み、前記コーディングされているCRAピクチャは、前記コーディングされているビデオビットストリームの最初のピクチャではなく、前記コーディングされているCRAピクチャは、新たなコーディングされているビデオシーケンス(CVS)を開始する、ステップと、
前記ビデオデコーダによって、前記第1のフラグの前記第1の値と等しくなるように第2のフラグの第2の値を設定するステップであって、前記第1のフラグは、no_output_of_prior_pics_flagとして指定され、前記第2のフラグは、NoOutputOfPriorPicsFlagとして指定される、ステップと、
前記ビデオデコーダによって、前記第2の値を有する前記第2のフラグに基づいて、復号化されているピクチャのバッファ(DPB)から、前記コーディングされているCRAピクチャに対応する以前に復号化されているあらゆるピクチャを空にするステップと、
前記ビデオデコーダによって、前記DPBが空になった後に現在のピクチャを復号化するステップと、
前記第1のフラグの値が、前記以前に復号化されているピクチャが出力されるということを示すときに、前記第1のフラグの前記値に基づいて、前記コーディングされているCRAピクチャに対応する前記以前に復号化されているピクチャを出力するステップと、を含む、
方法。
【請求項2】
前記第1のフラグが前記第1の値に設定されるときに、DPBフルネスパラメータを0に設定するステップをさらに含む、請求項1に記載の方法。
【請求項3】
前記DPBは、前記コーディングされているCRAピクチャが復号化された後に空にされる、請求項1又は2に記載の方法。
【請求項4】
前記第1のフラグの前記第1の値は、1である、請求項1乃至3のうちのいずれか1項に記載の方法。
【請求項5】
復号化デバイスであって、コーディングされているビデオビットストリームを受信するように構成される受信機と、
前記受信機に結合されるメモリであって、前記メモリは、命令を格納する、メモリと、
前記メモリに結合されるプロセッサと、を含み、前記プロセッサは、前記命令を実行して、当該復号化デバイスが、
前記コーディングされているビデオビットストリームを受信し、前記コーディングされているビデオビットストリームは、第1の値を有する第1のフラグ及びコーディングされているクリーンランダムアクセス(CRA)ピクチャを含み、前記コーディングされているCRAピクチャは、前記コーディングされているビデオビットストリームの最初のピクチャではなく、前記コーディングされているCRAピクチャは、新たなコーディングされているビデオシーケンス(CVS)を開始し、
前記第1のフラグの前記第1の値と等しくなるように第2のフラグの第2の値を設定し、前記第1のフラグは、no_output_of_prior_pics_flagとして指定され、前記第2のフラグは、NoOutputOfPriorPicsFlagとして指定され、
前記第2の値を有する前記第2のフラグに基づいて、復号化されているピクチャのバッファ(DPB)から、前記コーディングされているCRAピクチャに対応する以前に復号化されているあらゆるピクチャを空にし、
前記DPBが空になった後に現在のピクチャを復号化し、そして、
前記第1のフラグの値が、前記以前に復号化されているピクチャが出力されるということを示すときに、前記第1のフラグの前記値に基づいて、前記コーディングされているCRAピクチャに対応する前記以前に復号化されているピクチャを出力する、ようにさせる、ように構成される、
復号化デバイス。
【請求項6】
前記現在のピクチャに基づいて生成される画像を表示するように構成されるディスプレイをさらに含む、請求項5に記載の復号化デバイス。
【請求項7】
コンピュータ読み取り可能な記憶媒体であって、当該コンピュータ読み取り可能な記憶媒体は、プロセッサが実行することが可能であるコンピュータプログラムを格納し、前記コンピュータプログラムが前記プロセッサによって実行されるときに、前記プロセッサは、請求項1乃至4のうちのいずれか1項に記載の方法を実行する、コンピュータ読み取り可能な記憶媒体。
【請求項8】
コンピュータ又はプロセッサによって実行されるときに、請求項1乃至4のうちのいずれか1項に記載の方法を実行するためのプログラムコードを含むプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
[関連出願への相互参照]
この特許出願は、Ye-Kui Wangによって2019年5月6日付で出願された"ビデオコーディングにおいて新たなコーディングされているビデオシーケンスを開始するピクチャのための前のピクチャの出力"と題する米国仮特許出願第62/843,991号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。
この特許出願は、Ye-Kui Wangによって2019年5月6日付で出願された"ビデオコーディングにおいて新たなコーディングされているビデオシーケンスを開始するピクチャのための前のピクチャの出力"と題する米国仮特許出願第62/843,991号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。
【0002】
[技術分野]
一般的に、この開示は、ビデオコーディングの際に以前に復号化されているピクチャの出力をサポートする複数の技術を説明する。より具体的には、この開示は、コーディングされているビデオシーケンス(CVS)を開始するランダムアクセスポイントピクチャに対応する以前に復号化されているピクチャを復号化されているピクチャのバッファから出力することを可能とする。
一般的に、この開示は、ビデオコーディングの際に以前に復号化されているピクチャの出力をサポートする複数の技術を説明する。より具体的には、この開示は、コーディングされているビデオシーケンス(CVS)を開始するランダムアクセスポイントピクチャに対応する以前に復号化されているピクチャを復号化されているピクチャのバッファから出力することを可能とする。
【背景技術】
【0003】
比較的短いビデオを描写するのに必要となるビデオデータの量でさえ、かなりの量となる場合があり、そのビデオデータの量は、そのデータがストリーム化されるときに、又は、他の場合には、帯域幅容量が限定されている通信ネットワークを介して通信されるときに、困難を伴う場合がある。このようにして、ビデオデータは、一般的に、現代の通信ネットワークを介して通信される前に圧縮される。メモリリソースは制限される場合があるため、記憶デバイスにビデオを格納するときに、そのビデオのサイズもまた問題となる場合がある。ビデオ圧縮デバイスは、大抵の場合、伝送又は記憶の前に、発信元においてソフトウェア及び/又はハードウェアを使用して、そのビデオデータをコーディングし、それにより、ディジタルビデオ画像を表すのに必要となるデータの量を減少させる。圧縮されたデータは、その次に、ビデオデータを復号化するビデオ解凍デバイスによって宛先において受信される。ネットワークリソースが限られており、且つ、より高いビデオ品質の要求が絶えず増加しているため、画質をほとんど犠牲にすることなく圧縮比を改善する改良された圧縮及び解凍技術は望ましい。
【発明の概要】
【0004】
第1の態様は、ビデオデコーダが実装する復号化の方法に関している。その方法は、コーディングされているビデオビットストリームを前記ビデオデコーダによって受信するステップであって、前記コーディングされているビデオビットストリームは、第1の値を有する第1のフラグ及びクリーンランダムアクセス(CRA)ピクチャを含む、ステップと、前記ビデオデコーダによって、前記第1のフラグの前記第1の値と等しくなるように第2のフラグの第2の値を設定するステップと、前記ビデオデコーダによって、前記第2の値を有する前記第2のフラグに基づいて、復号化されているピクチャのバッファ(DPB)から、以前に復号化されているあらゆるピクチャを空にするステップと、前記ビデオデコーダによって、前記DPBが空になった後に現在のピクチャを復号化するステップと、を含む。
【0005】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、その方法は、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0006】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記CRAピクチャが、前記コーディングされているビデオビットストリームの最初のピクチャではないということを提供する。
【0007】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記第1のフラグが前記第1の値に設定されるときに、DPBフルネスパラメータを0に設定するステップを提供する。
【0008】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記第1のフラグが、no_output_of_prior_pics_flagとして指定され、前記第2のフラグが、NoOutputOfPriorPicsFlagとして指定されるということを提供する。
【0009】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記DPBが、前記CRAピクチャが復号化された後に空にされるということを提供する。
【0010】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記現在のピクチャに基づいて生成される画像を表示するステップを提供する。
【0011】
第2の態様は、ビデオエンコーダが実装する符号化の方法に関する。その方法は、前記ビデオエンコーダによって、ビデオシーケンスのためのランダムアクセスポイントを決定するステップと、前記ビデオエンコーダによって、クリーンランダムアクセス(CRA)ピクチャを符号化して、前記ランダムアクセスポイントにおける前記ビデオシーケンスにするステップと、前記ビデオエンコーダによって、フラグを第1の値に設定して、復号化されているピクチャのバッファ(DPB)から以前に復号化されているあらゆるピクチャを空にするようビデオデコーダに指示するステップと、前記ビデオエンコーダによって、前記ランダムアクセスポイントにおける前記CRAピクチャを有する前記ビデオシーケンス及び前記フラグを含むビデオビットストリームを生成するステップと、前記ビデオエンコーダによって、前記ビデオデコーダへの伝送のために、前記ビデオビットストリームを格納するステップと、を含む。
【0012】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、その方法は、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0013】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記CRAピクチャが、前記ビデオビットストリームの最初のピクチャではなく、前記ビデオデコーダが、前記CRAピクチャが復号化された後に、前記DPBを空にするように指示されるということを提供する。
【0014】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記フラグが前記第1の値に設定されるときに、DPBフルネスパラメータを0に設定するように前記ビデオデコーダに指示するステップを提供する。
【0015】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記フラグが、no_output_of_prior_pics_flagとして指定されるということを提供する。
【0016】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記フラグの前記第1の値が、1であるということを提供する。
【0017】
第3の態様は、復号化デバイスに関する。その復号化デバイスは、コーディングされているビデオビットストリームを受信するように構成される受信機と、前記受信機に結合されるメモリであって、前記メモリは、命令を格納する、メモリと、前記メモリに結合されるプロセッサと、を含み、前記プロセッサは、前記命令を実行して、当該復号化デバイスが、前記コーディングされているビデオビットストリームを受信し、前記コーディングされているビデオビットストリームは、第1の値を有する第1のフラグ及びクリーンランダムアクセス(CRA)ピクチャを含み、前記第1のフラグの前記第1の値と等しくなるように第2のフラグの第2の値を設定し、前記第2の値を有する前記第2のフラグに基づいて、復号化されているピクチャのバッファ(DPB)から、以前に復号化されているあらゆるピクチャを空にし、そして、前記DPBが空になった後に現在のピクチャを復号化する、ようにさせる、ように構成される。
【0018】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、その復号化デバイスは、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0019】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記CRAピクチャが、前記コーディングされているビデオビットストリームの最初のピクチャではないということを提供する。
【0020】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記第1のフラグが、no_output_of_prior_pics_flagとして指定され、前記第2のフラグが、NoOutputOfPriorPicsFlagとして指定されるということを提供する。
【0021】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記現在のピクチャに基づいて生成される画像を表示するように構成されるディスプレイを提供する。
【0022】
第4の態様は、符号化デバイスに関する。その符号化デバイスは、命令を収容するメモリと、前記メモリに結合されるプロセッサであって、前記プロセッサは、前記命令を実装して、当該符号化デバイスが、ビデオシーケンスのためのランダムアクセスポイントを決定し、クリーンランダムアクセス(CRA)ピクチャを符号化して、前記ランダムアクセスポイントにおける前記ビデオシーケンスにし、フラグを第1の値に設定して、復号化されているピクチャのバッファ(DPB)から以前に復号化されているあらゆるピクチャを空にするようビデオデコーダに指示し、そして、前記ランダムアクセスポイントにおける前記CRAピクチャを有する前記ビデオシーケンス及び前記フラグを含む前記ビデオビットストリームを生成する、ようにさせる、ように構成される、プロセッサと、前記プロセッサに結合される送信機であって、前記送信機は、ビデオデコーダに前記ビデオビットストリームを伝送するように構成される、送信機と、を含む。
【0023】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、その符号化デバイスは、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0024】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記CRAピクチャが、前記ビデオビットストリームの最初のピクチャではないということを提供する。
【0025】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記フラグが、no_output_of_prior_pics_flagとして指定されるということを提供する。
【0026】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、前記送信機が前記ビデオデコーダに前記ビットストリームを伝送する前に、前記メモリが、前記ビットストリームを格納するということを提供する。
【0027】
第5の態様は、コーディング装置に関する。そのコーディング装置は、符号化するためのピクチャを受信するか又は復号化するためのビットストリームを受信するように構成される受信機と、前記受信機に結合される送信機であって、前記送信機は、デコーダに前記ビットストリームを伝送するか又はディスプレイに復号化されている画像を伝送するように構成される、送信機と、前記受信機又は前記送信機のうちの少なくとも1つに結合されるメモリであって、前記メモリは、命令を格納するように構成される、メモリと、前記メモリに結合されるプロセッサであって、前記プロセッサは、前記メモリの中に格納されている命令を実行して、本明細書において開示されている方法のうちのいずれかを実行するように構成される、プロセッサと、を含む。
【0028】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、そのコーディング装置は、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0029】
随意的に、複数の先行する態様のうちのいずれかにおいて、その態様の他の実装は、画像を表示するように構成されるディスプレイを提供する。
【0030】
第6の態様は、システムに関する。そのシステムは、エンコーダと、前記エンコーダと通信するデコーダと、を含み、前記エンコーダ又は前記デコーダは、本明細書において開示されている復号化デバイス、符号化デバイス、又はコーディング装置を含む。
【0031】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、そのシステムは、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0032】
第7の態様は、コーディングするための手段に関する。そのコーディングするための手段は、符号化するためのピクチャを受信するか又は復号化するためのビットストリームを受信するように構成される受信手段と、前記受信手段に結合される送信手段であって、前記送信手段は、復号化手段に前記ビットストリームを伝送するか又はディスプレイ手段に復号化されている画像を伝送するように構成される、送信手段と、前記受信手段又は前記送信手段のうちの少なくとも1つに結合される記憶手段であって、前記記憶手段は、命令を格納するように構成される、記憶手段と、前記記憶手段に結合される処理手段と、を含み、前記処理手段は、前記記憶手段の中に格納されている前記命令を実行して、本明細書において開示されている方法のうちのいずれかを実行するように構成される。
【0033】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、そのコーディングするための手段は、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術を提供する。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、ビデオが送信され、受信され、及び/又は視聴されるときに、改善されているビデオコーディングプロセスは、より良好なユーザ体験をユーザに提供する。
【0034】
明確さのために、上記の複数の実施形態のうちのいずれか1つを上記の他の実施形態のうちのいずれか1つ又は複数と組み合わせて、この開示の範囲に属する新たな実施形態を作り出してもよい。
【0035】
これら及び他の特徴は、添付の図面及び特許請求の範囲に関連して行われる以下の詳細な説明から、より明確に理解されるであろう。
【図面の簡単な説明】
【0036】
この開示をより完全に理解するために、複数の添付の図面及び詳細な説明に関連して行われる以下の簡単な説明について述べ、それらの簡単な説明においては、同様の参照番号は、同様の部分を表す。
【0037】
【図1】GDR技術を利用することができるある1つの例示的なコーディングシステムを図示しているブロック図である。
【図2】GDR技術を実装することができるある1つの例示的なビデオエンコーダを図示しているブロック図である。
【図3】GDR技術を実装することができるビデオデコーダのある1つの例を図示しているブロック図である。
【図4】復号化順であらわしたリーディングピクチャ及び末尾のピクチャに対するIRAPピクチャと提示順であらわしたリーディングピクチャ及び末尾のピクチャに対するIRAPピクチャとの間の関係を表現したものである。
【図5】漸次的復号化リフレッシュ技術を図示している。
【図6】望ましくない動き探索を図示している概略的な図である。
【図7】クリーンランダムアクセス(CRA)技術を実装するように構成されるビデオビットストリームを図示している。
【図8】コーディングされているビデオビットストリームを復号化する方法のある1つの実施形態である。
【図9】コーディングされているビデオビットストリームを符号化する方法のある1つの実施形態である。
【図10】ビデオコーディングデバイスの概略的な図である。
【発明を実施するための形態】
【0038】
最初に、以下では、複数の実施形態のうちの1つ又は複数のある1つの例示的な実施を提供しているが、現在知られているか又は存在しているかにかかわらず、任意の数の技術を使用して、それらの開示されているシステム及び/又は方法を実装することが可能であるということを理解するべきである。この開示は、本明細書において解説されそして説明されている複数の例示的な設計及び実装を含む以下で解説されているそれらの例示的な実装、図面、及び技術には決して限定されるべきではないが、請求項に記載されている発明と同等の発明のすべての範囲とともに、添付の請求項に記載された発明の範囲の中で修正されてもよい。
【0039】
図1は、ある1つの例示的なコーディングシステム10を示すブロック図であり、その例示的なコーディングシステム10は、本明細書において説明されているビデオコーディング技術を利用することが可能である。図1に示されているように、そのコーディングシステム10は、発信元デバイス12を含み、その発信元デバイス12は、後の時点で宛先デバイス14が復号化する符号化されているビデオデータを提供する。特に、発信元デバイス12は、コンピュータ読み取り可能な媒体16を介して、宛先デバイス14にビデオデータを提供してもよい。発信元デバイス12及び宛先デバイス14は、広範囲のデバイスのうちのいずれかを含んでもよく、それらの広範囲のデバイスは、デスクトップコンピュータ、(例えば、ラップトップコンピュータ等の)ノートブックコンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる"スマート"フォン等の電話ハンドセット、いわゆる"スマート"パッド、テレビ、カメラ、ディスプレイデバイス、ディジタルメディアプレーヤー、ビデオゲームコンソール、又はビデオストリーミングデバイス等を含む。場合によっては、発信元デバイス12及び宛先デバイス14は、無線通信に対応することが可能であってもよい。
【0040】
宛先デバイス14は、コンピュータ読み取り可能な媒体16を介して復号化される符号化されているビデオデータを受信してもよい。コンピュータ読み取り可能な媒体16は、任意のタイプの媒体又はデバイスを含んでもよく、それらの媒体又はデバイスは、発信元デバイス12から宛先デバイス14へと、符号化されているビデオデータを移動させることが可能である。ある1つの例では、コンピュータ読み取り可能な媒体16は、通信媒体を含んでもよく、その通信媒体は、発信元デバイス12がリアルタイムで宛先デバイス14に符号化されているビデオデータを直接的に伝送することを可能とする。その符号化されているビデオデータは、無線通信プロトコル等の通信規格にしたがって変調され、そして、宛先デバイス14に伝送されてもよい。その通信媒体は、無線周波数(RF)スペクトラム或いは1つ又は複数の物理伝送線路等の任意の無線通信媒体又は有線通信媒体を含んでもよい。その通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、又はインターネット等のグローバルネットワーク等のパケットベースのネットワークの一部を形成してもよい。その通信媒体は、ルータ、スイッチ、基地局、又は発信元デバイス12から宛先デバイス14への通信を容易にするのに有用であることが可能である他の機器を含んでもよい。
【0041】
複数の例のうちのいくつかにおいて、出力インターフェイス22から記憶デバイスに符号化されているデータを出力してもよい。同様に、その記憶デバイスから、入力インターフェイスによって、符号化されているデータにアクセスすることが可能である。その記憶デバイスは、ハードドライブ、ブルーレイディスク、ディジタルビデオディスク(DVD)、コンパクトディスク読み取り専用メモリ(CD-ROM)、フラッシュメモリ、揮発性メモリ又は不揮発性メモリ、或いは、符号化されているビデオデータを格納するためのいずれかの他の適切なディジタル記憶媒体等のさまざまな分散型のデータ記憶媒体又は局所的にアクセスされるデータ記憶媒体のうちのいずれかを含んでもよい。さらなる例では、記憶デバイスは、ファイルサーバ又は他の中間記憶デバイスに対応してもよく、それらのファイルサーバ又は他の中間記憶デバイスは、発信元デバイス12が生成する符号化されているビデオを格納することが可能である。宛先デバイス14は、ストリーミング又はダウンロードによって、記憶デバイスから格納されているビデオデータにアクセスすることが可能である。ファイルサーバは、任意のタイプのサーバであってもよく、その任意のタイプのサーバは、符号化されているビデオデータを格納し、そして、宛先デバイス14にその符号化されているビデオデータを伝送することが可能である。例示的なファイルサーバは、(例えば、あるウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続記憶(NAS)デバイス、又はローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準的なデータ接続によってその符号化されているビデオデータにアクセスすることが可能である。この標準的なデータ接続は、(例えば、Wi-Fi接続等の)無線チャネル、(例えば、ディジタル加入者回線(DSL)、ケーブルモデム等の)有線接続、又はファイルサーバに格納されている符号化されているビデオデータにアクセスするのに適している無線チャネル又は有線接続の双方の組み合わせを含んでもよい。記憶デバイスからの符号化されているビデオデータの伝送は、ストリーミング伝送、ダウンロード伝送、又はそれらの組み合わせであってもよい。
【0042】
この開示の複数の技術は、必ずしも、無線アプリケーション又は設定には限定されない。無線テレビジョン放送、ケーブルテレビジョン伝送、衛星テレビジョン伝送、HTTPによる動的な適応ストリーミング(DASH)等のインターネットストリーミングビデオ伝送、データ記憶媒体において符号化されているディジタルビデオ、データ記憶媒体に格納されているディジタルビデオの復号化、又は他のアプリケーション等のさまざまなマルチメディアアプリケーションのうちのいずれかをサポートするビデオコーディングに、それらの複数の技術を適用することが可能である。複数の例のうちのいくつかにおいて、コーディングシステム10は、一方向のビデオ伝送又は双方向のビデオ伝送をサポートすることにより、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、及び/又はビデオ電話等のアプリケーションをサポートするように構成されてもよい。
【0043】
図1の例では、発信元デバイス12は、ビデオソース18、ビデオエンコーダ20、及び出力インターフェイス22を含む。宛先デバイス14は、入力インターフェイス28、ビデオデコーダ30、及びディスプレイデバイス32を含む。この開示によれば、発信元デバイス12のビデオエンコーダ20及び/又は宛先デバイス14のビデオデコーダ30は、ビデオコーディングのための複数の技術を適用するように構成されてもよい。他の例では、発信元デバイス及び宛先デバイスは、他の構成要素又は配置を含んでもよい。例えば、発信元デバイス12は、外部カメラ等の外部ビデオソースからビデオデータを受信してもよい。同様に、宛先デバイス14は、集積化されたディスプレイデバイスを含むのではなく、外部ディスプレイデバイスにインターフェイスを提供することが可能である。
【0044】
図1の図示されているコーディングシステム10は、ある1つの例であるにすぎない。ビデオコーディングのための技術は、任意のディジタルビデオ符号化デバイス及び/又は復号化デバイスによって実行されてもよい。この開示のそれらの複数の技術は、一般的に、ビデオコーディングデバイスによって実行されるが、それらの複数の技術は、また、典型的には"CODEC"と称されるビデオエンコーダ/デコーダによって実行されてもよい。さらに、この開示のそれらの複数の技術は、また、ビデオプロセッサによって実行されてもよい。ビデオエンコーダ及び/又はビデオデコーダは、グラフィックス処理ユニット又は同様のデバイスであってもよい。
【0045】
発信元デバイス12及び宛先デバイス14は、発信元デバイス12が宛先デバイス14への伝送のためにコーディングされているビデオデータを生成するそのような複数のコーディングデバイスの例であるにすぎない。複数の例のうちのいくつかにおいて、発信元デバイス12及び宛先デバイス14は、実質的に対称な方式で動作してもよく、それによって、発信元デバイス12及び宛先デバイス14の各々は、ビデオ符号化構成要素及びビデオ復号化構成要素を含む。したがって、コーディングシステム10は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、又はビデオ電話のために、複数のビデオデバイス12及び14の間の一方向のビデオ伝送又は双方向のビデオ伝送をサポートすることが可能である。
【0046】
発信元デバイス12のビデオソース18は、ビデオカメラ等のビデオ取り込みデバイス、以前に取り込まれたビデオを収容するビデオアーカイブ、及び/又はビデオコンテンツプロバイダからビデオを受信するためのビデオ供給インターフェイスを含んでもよい。さらなる代替として、ビデオソース18は、発信元ビデオとして、又は、ライブビデオ、アーカイブされているビデオ、及びコンピュータにより生成されるビデオの組み合わせとして、コンピュータグラフィックスベースのデータを生成してもよい。
【0047】
場合によっては、ビデオソース18がビデオカメラであるときに、発信元デバイス12及び宛先デバイス14は、いわゆるカメラフォン又はビデオフォンを形成してもよい。一方で、上記で言及されているように、この開示において説明されている技術は、一般的に、ビデオコーディングに適用可能であってもよく、無線アプリケーション及び/又は有線アプリケーションに適用されてもよい。各々の場合において、取り込まれるビデオ、あらかじめ取り込まれているビデオ、又はコンピュータにより生成されるビデオは、ビデオエンコーダ20によって符号化されてもよい。符号化されているビデオ情報は、その次に、出力インターフェイス22によって、コンピュータ読み取り可能な媒体16に出力されてもよい。
【0048】
コンピュータ読み取り可能な媒体16は、無線ブロードキャスト伝送又は有線ネットワーク伝送等の一時的な媒体、或いは、ハードディスク、フラッシュドライブ、コンパクトディスク、ディジタルビデオディスク、ブルーレイディスク、又は他のコンピュータ読み取り可能な媒体等の記憶媒体(すなわち、非一時的な媒体)を含んでもよい。複数の例のうちのいくつかにおいては、(示されていない)ネットワークサーバは、発信元デバイス12から符号化されているビデオデータを受信し、そして、例えば、ネットワーク伝送によって、宛先デバイス14にその符号化されているビデオデータを提供してもよい。同様に、ディスク刻印設備等の媒体製造設備のコンピューティングデバイスは、発信元デバイス12から符号化されているビデオデータを受信し、そして、その符号化されているビデオデータを含むディスクを製造してもよい。したがって、コンピュータ読み取り可能な媒体16は、さまざまな例において、さまざまな形態のコンピュータ読み取り可能な媒体のうちの1つ又は複数を含むものと理解されてもよい。
【0049】
宛先デバイス14の入力インターフェイス28は、コンピュータ読み取り可能な媒体16から情報を受信する。コンピュータ読み取り可能な媒体16のその情報は、ビデオエンコーダ20が規定する構文情報を含んでもよく、その構文情報は、また、ビデオデコーダ30によって使用され、その構文情報は、ブロック、及び、例えば、複数のピクチャグループ(GOP)等の他のコーディングされるユニットの特徴及び/又は処理を記述する構文要素を含む。ディスプレイデバイス32は、ユーザにその復号化されているビデオデータを表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、又は他のタイプのディスプレイデバイス等のさまざまなディスプレイデバイスのうちのいずれかを含んでもよい。
【0050】
ビデオエンコーダ20及びビデオデコーダ30は、現在開発中の高効率ビデオコーディング(HEVC)規格等のビデオコーディング規格にしたがって動作してもよく、HEVCテストモデル(HM)に適合してもよい。代替的に、ビデオエンコーダ20及びビデオデコーダ30は、代替的に、動画エキスパートグループ(MPEG)4、第10部、高度化されたビデオコーディング(AVC)、H.265/HEVC、又はそのような規格の拡張と称される国際通信連合通信標準化部門(ITU-T)のH.264規格等の他の所有権規格又は産業規格にしたがって動作してもよい。一方で、この開示の複数の技術は、いずれかの特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG-2及びITU-T H.263を含む。図1には示されてはいないが、複数の態様のうちのいくつかにおいては、ビデオエンコーダ20及びビデオデコーダ30は、各々、オーディオエンコーダ及びデコーダと一体化されてもよく、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット又は他のハードウェア及びソフトウェアを含んで、共通のデータストリーム又は個別のデータストリームにおけるオーディオ及びビデオの双方の符号化を処理してもよい。適用可能な場合には、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、又は、ユーザデータグラムプロトコル(UDP)等の他のプロトコルに準拠してもよい。
【0051】
ビデオエンコーダ20及びビデオデコーダ30は、各々、1つ又は複数のマイクロプロセッサ、ディジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、離散的なロジック、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせ等のさまざまな適切なエンコーダ回路のうちのいずれかとして実装されてもよい。それらの複数の技術が部分的にソフトウェアによって実装されるときに、デバイスは、適切な且つ非一時的なコンピュータ読み取り可能な媒体の中にソフトウェアのための複数の命令を格納し、そして、1つ又は複数のプロセッサを使用してハードウェアの中でそれらの複数の命令を実行して、この開示のそれらの複数の技術を実行してもよい。ビデオエンコーダ20及びビデオデコーダ30の各々は、1つ又は複数のエンコーダ又はデコーダに含まれていてもよく、これらのうちのいずれも、一体化されて、それぞれのデバイスの中で組み合わせられたエンコーダ/デコーダ(CODEC)の一部を形成してもよい。ビデオエンコーダ20及び/又はビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、及び/又はセルラ電話等の無線通信デバイスを含んでもよい。
【0052】
図2は、ビデオコーディング技術を実装することが可能であるビデオエンコーダ20のある1つの例を図示しているブロック図である。ビデオエンコーダ20は、ビデオスライスの中のビデオブロックのフレーム内コーディング及びフレーム間コーディングを実行してもよい。フレーム内コーディングは、ある与えられたビデオフレーム又はピクチャの中のビデオにおける空間的な冗長性を減少させるか又は除去するための空間的予測に依存する。フレーム間コーディングは、ビデオシーケンスの隣接するフレーム又はピクチャの中のビデオにおける時間的な冗長性を減少させるか又は除去するための時間的予測に依存する。フレーム内モード(I mode)は、いくつかの空間ベースのコーディングモードのうちのいずれかを指してもよい。(単予測としても知られている)一方向予測(P mode)又は(双予測としても知られている)双予測(B mode)等のフレーム間モードは、いくつかの時間ベースのコーディングモードのうちのいずれかを指してもよい。
【0053】
図2に示されているように、ビデオエンコーダ20は、符号化されるビデオフレームの中の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40、参照フレームメモリ64、総和をとる加算器50、変換処理ユニット52、量子化ユニット54、及びエントロピー符号化ユニット56を含む。モード選択ユニット40は、同様にして、動き補償ユニット44、動き推定ユニット42、(イントラ予測としても知られている)フレーム内予測ユニット46、及び区分化ユニット48を含む。ビデオブロックの再構成のために、ビデオエンコーダ20は、また、逆量子化ユニット58、逆変換ユニット60、及び総和をとる加算器62を含む。また、ブロック境界をフィルタリングして、再構成されているビデオからブロックノイズアーティファクトを除去するための(図2には示されていない)非ブロック化フィルタを含んでもよい。必要に応じて、非ブロック化フィルタは、典型的には、総和をとる加算器62の出力をフィルタリングするであろう。また、非ブロック化フィルタのほかに、(インループフィルタ又はポストループフィルタ等の)追加的なフィルタを使用してもよい。そのようなフィルタは、簡潔さのために示されていないが、必要に応じて、総和をとる加算器50の出力を(インループフィルタとして)フィルタリングしてもよい。
【0054】
符号化プロセスの際に、ビデオエンコーダ20は、コーディングされるビデオフレーム又はスライスを受信する。複数のビデオブロックへとそのフレーム又はスライスを分割することが可能である。動き推定ユニット42及び動き補償ユニット44は、1つ又は複数の参照フレームの中の1つ又は複数のブロックに対して、受信したビデオブロックのフレーム間予測コーディングを実行して、時間的な予測を提供する。フレーム内予測ユニット46は、代替的に、コーディングされるブロックと同じフレーム又はスライスの中の1つ又は複数の隣接するブロックに対して、受信したビデオブロックのフレーム内予測コーディングを実行して、空間的な予測を提供してもよい。ビデオエンコーダ20は、複数のコーディングパスを実行して、例えば、ビデオデータの各々のブロックについて適切なコーディングモードを選択してもよい。
【0055】
さらに、区分化ユニット48は、以前のコーディングパスにおける以前の区分化スキームの評価に基づいて、ビデオデータのブロックをサブブロックへと区分化してもよい。例えば、区分化ユニット48は、最初に、フレーム又はスライスを最も大きなコーディングユニット(LCU)へと区分化し、そして、(例えば、レート歪み最適化等の)レート歪み分析に基づいて、それらの複数のLCUの各々をサブコーディングユニット(sub-CU)へと区分化する。モード選択ユニット40は、さらに、LCUのsub-CUへの区分化を示す四分木データ構造を生成してもよい。四分木のリーフノードCUは、1つ又は複数の予測ユニット(PU)及び1つ又は複数の変換ユニット(TU)を含んでもよい。
【0056】
この開示は、"ブロック"の語を使用して、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がスキップモードで符号化されているか又は直接モードで符号化されているか、フレーム内予測モードで符号化されているか、或いは、(インター予測としても知られている)フレーム間予測モードで符号化されているかによって異なってもよい。PUは、非正方形の形状に区分化されてもよい。また、CUと関連する構文データは、例えば、四分木にしたがった1つ又は複数のTUへのCUの区分化を記述してもよい。TUは、正方形又は(例えば、矩形等の)非正方形の形状であってもよい。
【0057】
モード選択ユニット40は、例えば、誤差の結果に基づいて、フレーム内コーディングモード又はフレーム間コーディングモード等のコーディングモードのうちの1つを選択してもよく、総和をとる加算器50に、結果として生じるフレーム内コーディングされているブロック又はフレーム間コーディングされているブロックを提供して、残差ブロックデータを生成し、そして、総和をとる加算器62にその残差ブロックデータを提供して、参照フレームとして使用するために符号化されているブロックを再構成する。モード選択ユニット40は、また、エントロピーコーディングユニット56に、動きベクトル、フレーム内モードインジケータ、区分化情報、及び他のそのような構文情報等の構文要素を提供する。
【0058】
動き推定ユニット42及び動き補償ユニット44は、高度に集積化されていてもよいが、概念的な目的のために個別に図示されている。動き推定ユニット42が実行する動き推定は、動きベクトルを生成するプロセスであり、それらの動きベクトルは、ビデオブロックについての動きを推定する。動きベクトルは、例えば、現在のフレームの中でコーディングされている現在のブロック(又は、他のコーディングされているユニット)に関連する参照フレームの中の予測ブロック(又は、他のコーディングされているユニット)に対する現在のビデオフレーム又はピクチャの中のビデオブロックのPUの変位を示すことが可能である。予測ブロックは、ピクセル差に関してコーディングされるブロックに厳密に一致するように見つけ出されるブロックであり、その予測ブロックは、絶対差の総和(SAD)、2乗差の総和(SSD)、又は他の差分メトリックスによって決定されてもよい。複数の例のうちのいくつかにおいて、ビデオエンコーダ20は、参照フレームメモリ64の中に格納されている参照ピクチャのサブ整数ピクセル位置の値を計算することが可能である。例えば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、又は他の小数ピクセル位置の値を内挿補間してもよい。したがって、動き推定ユニット42は、フルピクセル位置及び小数ピクセル位置に関する動き探索を実行し、そして、小数ピクセル精度を有する動きベクトルを出力してもよい。
【0059】
動き推定ユニット42は、参照ピクチャの予測ブロックの位置とPUの位置を比較することによって、フレーム間コーディングされているスライスの中のビデオブロックのPUについての動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(List 0)又は第2の参照ピクチャリスト(List 1)から選択されてもよく、第1の参照ピクチャリスト及び第2の参照ピクチャリストの各々は、参照フレームメモリ64の中に格納されている1つ又は複数の参照ピクチャを識別する。動き推定ユニット42は、エントロピーコーディングユニット56及び動き補償ユニット44に、計算される動きベクトルを送信する。
【0060】
動き補償ユニット44が実行する動き補償は、動き推定ユニット42が決定する動きベクトルに基づいて、予測ブロックを取り出すこと又は生成することを伴ってもよい。繰り返しになるが、複数の例のうちのいくつかにおいて、動き推定ユニット42及び動き補償ユニット44を機能的に一体化してもよい。現在のビデオブロックのPUについての動きベクトルを受信すると、動き補償ユニット44は、動きベクトルがそれらの複数の参照ピクチャリストのうちの1つの中で指し示す予測ブロックの位置を特定することが可能である。総和をとる加算器50は、以下で説明されているように、コーディングされる現在のビデオブロックのピクセル値から、予測ブロックのピクセル値を減算することによって、残差ビデオブロックを形成し、その結果、ピクセル差値を形成する。一般的に、動き推定ユニット42は、輝度成分に関する動き推定を実行し、動き補償ユニット44は、彩度成分及び輝度成分の双方のために、輝度成分に基づいて計算される動きベクトルを使用する。モード選択ユニット40は、また、ビデオスライスのビデオブロックを復号化する際に、ビデオデコーダ30が使用するように、ビデオブロック及びビデオスライスと関連する構文要素を生成することが可能である。
【0061】
フレーム内予測ユニット46は、上記で説明されているように、動き推定ユニット42及び動き補償ユニット44が実行するフレーム間予測の代わりに、現在のブロックをフレーム内予測してもよい。特に、フレーム内予測ユニット46は、現在のブロックを符号化するのに使用するフレーム内予測モードを決定してもよい。複数の例のうちのいくつかにおいて、フレーム内予測ユニット46は、例えば、個別の符号化パスの際に、さまざまなフレーム内予測モードを使用して、現在のブロックを符号化してもよく、フレーム内予測ユニット46(又は、複数の例のうちのいくつかにおいては、モード選択ユニット40)は、テストされているモードから、使用するのに適切なフレーム内予測モードを選択することが可能である。
【0062】
例えば、フレーム内予測ユニット46は、さまざまなテストされているフレーム内予測モードについてのレート歪み分析を使用してレート歪み値を計算し、そして、それらのテストされているモードうちで最良のレート歪み特性を有するフレーム内予測モードを選択してもよい。レート歪み分析は、一般的に、符号化されたブロックを生成するために以前に符号化された元の符号化されていないブロックと符号化されているブロックとの間の歪み(又は、誤差)の量のみならず、符号化されているブロックを生成するのに使用されるビットレート(すなわち、ビットの数)を決定する。フレーム内予測ユニット46は、さまざまな符号化されているブロックについて、歪み及びレートから比を計算して、いずれのフレーム内予測モードがそのブロックについて最良のレート歪み値を示すかを決定してもよい。
【0063】
加えて、フレーム内予測ユニット46は、深度モデリングモード(DMM)を使用して、深度マップの深度ブロックをコーディングするように構成されてもよい。モード選択ユニット40は、例えば、レート歪み最適化(RDO)を使用して、利用可能なDMMモードが、フレーム内予測モード及び他のDMMモードよりもより良好なコーディング結果を生じるか否かを決定してもよい。深度マップに対応するテクスチャ画像のためのデータは、参照フレームメモリ64の中に格納されてもよい。動き推定ユニット42及び動き補償ユニット44は、また、深度マップの深度ブロックをフレーム間予測するように構成されてもよい。
【0064】
あるブロックについて(例えば、従来のフレーム内予測モード又は複数のDMMモードのうちの1つ等の)フレーム内予測モードを選択した後に、フレーム内予測ユニット46は、エントロピーコーディングユニット56に、そのブロックについての選択されたフレーム内予測モードを示す情報を提供してもよい。エントロピーコーディングユニット56は、その選択されたフレーム内予測モードを示す情報を符号化してもよい。ビデオエンコーダ20は、伝送されるビットストリームの中に構成データを含めてもよく、その構成データは、(また、コードワードマッピングテーブルと称される)複数の修正されているフレーム内予測モードインデックステーブル及び複数のフレーム内予測モードインデックステーブル、さまざまなブロックについての複数のコンテキストの符号化の定義、及びそれらの複数のコンテキストの各々のために使用する最も可能性の高いフレーム内予測モード、フレーム内予測モードインデックステーブル、及び修正されているフレーム内予測モードインデックステーブルを含んでもよい。
【0065】
ビデオエンコーダ20は、コーディングされる元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。総和をとる加算器50は、この減算演算を実行する1つ又は複数の構成要素を表す。
【0066】
変換処理ユニット52は、残差ブロックに離散コサイン変換(DCT)又は概念的に同様の変換等の変換を適用し、その結果、残留変換係数値を含むビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行してもよい。また、ウェーブレット変換、整数変換、サブバンド変換、又は他のタイプの変換を使用してもよい。
【0067】
変換処理ユニット52は、残差ブロックに変換を適用し、その結果、残差変換係数のブロックを生成する。その変換は、ピクセル値領域から、例えば、周波数領域等の変換領域へと、その残差情報を変換してもよい。変換処理ユニット52は、量子化ユニット54に、結果として生じる変換係数を送信してもよい。量子化ユニット54は、それらの変換係数を量子化して、さらに、ビットレートを減少させる。その量子化プロセスは、それらの複数の係数のうちの一部又はすべてと関連するビット深度を減少させることが可能である。量子化パラメータを調整することによって、量子化の程度を修正することが可能である。複数の例のうちのいくつかにおいて、量子化ユニット54は、その次に、量子化されている変換係数を含む行列の走査を実行してもよい。代替的に、エントロピーコーディングユニット56は、その走査を実行してもよい。
【0068】
量子化に続いて、エントロピーコーディングユニット56は、量子化されている変換係数をエントロピーコーディングする。例えば、エントロピーコーディングユニット56は、コンテキスト適応可変長コーディング(CAVLC)、コンテキスト適応2値算術コーディング(CABAC)、構文ベースのコンテキスト適応2値算術コーディング(SBAC)、確率間隔区分化エントロピー(PIPE)コーディング、又は他のエントロピーコーディング技術を実行してもよい。コンテキストベースのエントロピーコーディングの場合に、コンテキストは、複数の隣接ブロックに基づいていてもよい。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、符号化されているビットストリームは、(例えば、ビデオデコーダ30等の)他のデバイスに伝送されてもよく、又は、後の伝送又は検索のためにアーカイブされてもよい。
【0069】
逆量子化ユニット58及び逆変換ユニット60は、それぞれ、逆量子化及び逆変換を適用して、例えば、後に参照ブロックとして使用するために、ピクセル領域において残差ブロックを再構成する。動き補償ユニット44は、参照フレームメモリ64の複数のフレームのうちの1つの予測ブロックにその残差ブロックを加えることによって、参照ブロックを計算してもよい。動き補償ユニット44は、また、その再構成された残差ブロックに1つ又は複数の内挿補間フィルタを適用して、動き推定の際に使用するためのサブ整数ピクセル値を計算してもよい。総和をとる加算器62は、動き補償ユニット44が生成する動き補償されている予測ブロックに、その再構成された残差ブロックを加えて、参照フレームメモリ64の中に格納するための再構成されたビデオブロックを生成する。その再構成されたビデオブロックは、後続のビデオフレームの中でブロックをフレーム間コーディングするための参照ブロックとして、動き推定ユニット42及び動き補償ユニット44によって使用されてもよい。
【0070】
図3は、ビデオコーディング技術を実装することが可能であるビデオデコーダ30のある1つの例を図示しているブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号化ユニット70、動き補償ユニット72、フレーム内予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレームメモリ82、及び総和をとる加算器80を含む。ビデオデコーダ30は、複数の例のうちのいくつかにおいて、ビデオエンコーダ20(図2)に関して説明されている符号化パスと概ね逆の復号化パスを実行してもよい。動き補償ユニット72は、エントロピー復号化ユニット70から受信する動きベクトルに基づいて、予測データを生成してもよく、一方、フレーム内予測ユニット74は、エントロピー復号化ユニット70から受信するフレーム内予測モードインジケータに基づいて、予測データを生成してもよい。
【0071】
復号化プロセスの際に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化されているビデオスライスのビデオブロック及び関連する構文要素を表す符号化されているビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号化ユニット70は、ビットストリームをエントロピー復号化して、量子化されている係数、動きベクトル又はフレーム内予測モードインジケータ、及び他の構文要素を生成する。エントロピー復号化ユニット70は、動き補償ユニット72に動きベクトル及び他の構文要素を転送する。ビデオデコーダ30は、ビデオスライスレベル及び/又はビデオブロックレベルで構文エレメントを受信してもよい。
【0072】
ビデオスライスがフレーム内コーディングされている(I)スライスとしてコーディングされるときに、フレーム内予測ユニット74は、シグナリングによって送られるフレーム内予測モード及び現在のフレーム又はピクチャの以前に復号化されているブロックからのデータに基づいて、現在のビデオスライスのビデオブロックについての予測データを生成してもよい。ビデオフレームが、(例えば、B、P、又はGPB等の)フレーム間コーディングされているスライスとしてコーディングされるときに、動き補償ユニット72は、エントロピー復号化ユニット70から受信した動きベクトル及び他の構文要素に基づいて、現在のビデオスライスのビデオブロックについて予測ブロックを生成する。それらの予測ブロックは、複数の参照ピクチャリストのうちの1つの中の複数の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、参照フレームメモリ82の中に格納されている参照ピクチャに基づいて、デフォルトの構築技術を使用して、参照フレームリストList0及びList1を構築してもよい。
【0073】
動き補償ユニット72は、動きベクトル及び他の構文要素を解析することによって、現在のビデオスライスのビデオブロックについて予測情報を決定し、そして、その予測情報を使用して、復号化される現在のビデオブロックについて予測ブロックを生成する。例えば、動き補償ユニット72は、複数の受信した構文要素のうちのいくつかを使用して、そのビデオスライスのビデオブロックをコーディングするのに使用される(例えば、フレーム内予測又はフレーム間予測等の)予測モード、(例えば、Bスライス、Pスライス、又はGPBスライス等の)フレーム間予測スライスタイプ、そのスライスのための複数の参照ピクチャリストのうちの1つ又は複数のための構築情報、そのスライスの各々のフレーム間符号化されているビデオブロックのための動きベクトル、そのスライスの各々のフレーム間コーディングされているビデオブロックのためのフレーム間予測状態、及び現在のビデオスライスの中のビデオブロックを復号化するための他の情報を決定する。
【0074】
動き補償ユニット72は、また、内挿補間フィルタに基づいて内挿補間を実行してもよい。動き補償ユニット72は、ビデオエンコーダ20がビデオブロックの符号化の際に使用する補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための内挿補間された値を計算してもよい。この場合には、動き補償ユニット72は、受信した構文要素からビデオエンコーダ20が使用する内挿補間フィルタを決定し、そして、それらの内挿補間フィルタを使用して、予測ブロックを生成してもよい。
【0075】
深度マップに対応するテクスチャ画像のためのデータは、参照フレームメモリ82の中に格納されてもよい。動き補償ユニット72は、また、深度マップの深度ブロックをフレーム間予測するように構成されてもよい。
【0076】
ある1つの実施形態において、ビデオデコーダ30は、ユーザインターフェイス(UI)84を含む。そのユーザインターフェイス84は、(例えば、ネットワーク管理者等の)ビデオデコーダ30のユーザからの入力を受信するように構成される。そのユーザインターフェイス84を介して、ユーザは、ビデオデコーダ30における設定を管理し又は変更することが可能である。例えば、ユーザは、ユーザの嗜好にしたがってビデオデコーダ30の構成及び/又は動作を制御するために、(例えば、フラグ等の)パラメータのための値を入力するか又はその他の場合には提供することが可能である。ユーザインターフェイス84は、例えば、グラフィカルユーザインターフェイス(GUI)であってもよく、そのグラフィカルユーザインターフェイスは、グラフィカルアイコン、ドロップダウンメニュー、及びチェックボックス等によってユーザがビデオデコーダ30と対話することを可能とする。場合によっては、ユーザインターフェイス84は、キーボード、マウス、又は他の周辺デバイスによってユーザからの情報を受信してもよい。ある1つの実施形態において、ユーザは、スマートフォン、タブレットデバイス、及び、ビデオデコーダ30から遠隔に位置しているパーソナルコンピュータ等によってユーザインターフェイス84にアクセスすることが可能である。本明細書で使用されているように、ユーザインターフェイス84は、外部入力又は外部手段と称されてもよい。
【0077】
上記のことに留意して、ビデオ圧縮技術は、空間的な(ピクチャ内の)予測及び/又は時間的な(ピクチャ間の)予測を実行して、ビデオシーケンスに固有の冗長性を減少させ或いは除去する。ブロックベースのビデオコーディングのために、ビデオスライス(すなわち、ビデオピクチャ又はビデオピクチャの部分)は、複数のビデオブロックに区分化されてもよく、それらのビデオブロックは、また、ツリーブロック、コーディングツリーブロック(CTB)、コーディングツリーユニット(CTU)、コーディングユニット(CU)及び/又はコーディングノードと称されてもよい。ピクチャのフレーム内コーディングされている(I)スライスの中のビデオブロックは、同じピクチャの中の複数の隣接するブロックの中での複数の参照サンプルに関する空間的な予測を使用して符号化される。ピクチャのフレーム間コーディングされている(P又はB)スライスの中のビデオブロックは、同じピクチャの中の複数の隣接するブロックの中での複数の参照サンプルに関する空間的な予測又は他の参照ピクチャの中の複数の参照サンプルに関する時間的な予測を使用してもよい。ピクチャは、フレームと称されてもよく、参照ピクチャは、参照フレームと称されてもよい。
【0078】
空間的な予測又は時間的な予測は、コーディングされるブロックについての予測ブロックを生じさせる。残差データは、コーディングされる元のブロックと予測ブロックとの間のピクセル差を表す。フレーム間コーディングされているブロックは、動きベクトルにしたがって符号化され、動きベクトルは、予測ブロックを形成する参照サンプルのブロックを指し示し、残差データは、符号化されているブロックと予測ブロックとの間の差を示す。フレーム内コーディングされているブロックは、フレーム内コーディングモード及び残差データにしたがって符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域へと変換されてもよく、残留変換係数をもたらし、それらの残留変換係数は、その次に、量子化されてもよい。量子化されている変換係数は、最初は、2次元アレイに配列され、変換係数の1次元ベクトルを生成するために走査されてもよく、エントロピー符号化は、よりいっそう多くの圧縮を達成するために適用されてもよい。
【0079】
画像及びビデオ圧縮は、急速な成長を経験し続け、さまざまなコーディング規格をもたらしている。そのようなビデオコーディング規格は、ITU-T H.261, 国際標準化機構/国際電気委員会(ISO/IEC) MPEG-1 Part 2, ITU-T H.262又はISO/IEC MPEG-2 Part 2, ITU-T H.263, ISO/IEC MPEG-4 Part 2, ITU-T H.264又はISO/IEC MPEG-4 Part 10としても知られている高度ビデオコーディング(AVC)、及びITU-T H.265はMPEG-H Part 2としても知られている高効率ビデオコーディング(HEVC)を含む。AVCは、スケーラブルビデオコーディング(SVC)、マルチビュービデオコーディング(MVC)及びマルチビュービデオコーディングプラス深度(MVC＋D)、及び、3D AVC (3D-AVC)等の拡張規格を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、及び3D HEVC (3D-HEVC)等の拡張規格を含む。
【0080】
また、ITU-T及びISO/IECの合同ビデオ専門家チーム(JVET)によって開発されつつある多用途ビデオコーディング(VVC)と呼ばれる新たなビデオコーディング規格が存在する。VVC規格は、いくつかの作業原案を有しているが、本明細書においては、VVCの1つの作業原案(WD)、すなわち、特に、B. Bross, J. Chen及びS. Liu, "多用途ビデオコーディング(原案5)"、JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC 原案5)を参照する。
【0081】
本明細書の中で開示されている複数の技術の説明は、ITU-T及びISO/IECの合同ビデオ専門家チーム(JVET)による現在開発中のビデオコーディング規格である多用途ビデオコーディング(VVC)に基づいている。一方で、それらの技術は、また、他のビデオコーデック規格にも適用される。
【0082】
図4は、復号化順408であらわしたリーディングピクチャ404及び末尾のピクチャ406に対するフレーム内ランダムアクセスポイント(IRAP)ピクチャ402と提示順410であらわしたリーディングピクチャ404及び末尾のピクチャ406に対するIRAPピクチャ402との間の関係を表現したもの400である。ある1つの実施形態において、IRAPピクチャ402は、クリーンランダムアクセス(CRA)ピクチャと称されるか又はランダムアクセス復号化可能(RADL)ピクチャを有する瞬時デコーダリフレッシュ(IDR)ピクチャと称される。HEVCの場合には、IDRピクチャ、CRAピクチャ、及び破損リンクアクセス(BLA)ピクチャは、すべて、IRAPピクチャ402と考えられる。VVCについては、2018年10月の第12回JVET会合の際に、IRAPピクチャとしてIDRピクチャ及びCRAピクチャの双方を有することが合意されている。ある1つの実施形態において、破損リンクアクセス(BLA)ピクチャ及び漸次的デコーダリフレッシュ(GDR)ピクチャは、また、IRAPピクチャであると考えられてもよい。コーディングされているビデオシーケンスのための復号化プロセスは、常に、IRAPから開始する。
【0083】
CRAピクチャは、各々のビデオコーディング層(VCL)ネットワーク抽象層(NAL)ユニットが、C CRA_NUTに等しいnal_unit_typeを有するIRAPピクチャである。CRAピクチャは、その復号化プロセスにおけるフレーム間予測のためにそのCRAピクチャ自体以外のいかなるピクチャも参照せず、復号化順序であらわされているビットストリームにおける最初のピクチャであってもよく、又は、そのビットストリームにおいて後半に出現してもよい。CRAピクチャは、関連するRADL又はランダムアクセススキップトリーディング(RASL)ピクチャを有してもよい。CRAピクチャが、1に等しいNoOutputBeforeRecoveryFlagを有するときに、関連するRASLピクチャは、そのビットストリームの中に存在しないピクチャへの参照を含んでいる場合があることから、それらの関連するRASLピクチャは、復号化可能ではない場合があるため、それらの関連するRASLピクチャは、デコーダによって出力されない。
【0084】
図4に示されているように、(例えば、ピクチャ2及び3等の)リーディングピクチャ404は、復号化順408の場合には、IRAPピクチャ402の後に続くが、提示順410の場合には、IRAPピクチャ402の前に置かれる。末尾のピクチャ406は、復号化順408及び提示順410の双方の場合に、IRAPピクチャ402の後に続く。2つのリーディングピクチャ404及び1つの末尾のピクチャ406が図4に示されているが、当業者は、実際の適用においては、より多くリーディングピクチャ404及び/又は末尾のピクチャ406或いはより少ないリーディングピクチャ404及び/又は末尾のピクチャ406が、復号化順408及び提示順410の場合に存在してもよいということを理解するであろう。
【0085】
図4におけるリーディングピクチャ404は、ランダムアクセススキップトリーディング(RASL)及びRADLの2つのタイプに分割されている。復号化が(例えば、ピクチャ1等の)IRAPピクチャ402から開始するときに、(例えば、ピクチャ3等の)RADLピクチャを適切に復号化することは可能であるが、(例えば、ピクチャ2等の)RASLピクチャを適切に復号化することは不可能である。したがって、RASLピクチャは、破棄される。RADLピクチャとRASLピクチャとの間の判別を考慮して、IRAPピクチャ402と関連するリーディングピクチャ404のタイプは、効率的な且つ適切なコーディングのために、RADL又はRASLのうちのいずれかであると識別される必要がある。HEVCの場合は、RASL及びRADLピクチャが存在するときに、同じIRAPピクチャ402と関連するRASLピクチャ及びRADLピクチャについては、RASLピクチャが、提示順410の場合にRADLピクチャの前に置かれる必要があるということを抑制する。
【0086】
IRAPピクチャ402は、以下の2つの重要な機能/利点を提供する。第1に、IRAPピクチャ402の存在は、復号化プロセスがそのピクチャから開始することを可能とするということを示す。IRAPピクチャ402がその位置に存在する限り、この機能は、復号化プロセスが、必ずしも、そのビットストリームの始まりではなく、そのビットストリームの中のその位置において開始するランダムアクセス機能を可能とする。第2に、IRAPピクチャ402の存在は、復号化プロセスを更新し、それによって、IRAPピクチャ402において開始するコーディングされるピクチャは、RASLピクチャを除いて、前のピクチャを参照することなくコーディングされる。ビットストリームの中にIRAPピクチャ402が存在するようにさせると、IRAPピクチャ402の前にあるコーディングされているピクチャの復号化の際に生起する場合があるエラーが、復号化順408の場合に、IRAPピクチャ402及びそのIRAPピクチャ402の後に続くそれらのピクチャに伝搬するのを阻止するであろう。
【0087】
IRAPピクチャ402は、重要な機能を提供するが、一方で、それらのIRAPピクチャ402は、その圧縮効率に対して不利益をもたらす。IRAPピクチャ402の存在は、ビットレートの急増を引き起こす。圧縮効率に対するこの不利益は、2つの理由による。第1に、IRAPピクチャ402は、フレーム内予測されているピクチャであるため、そのIRAPピクチャ402それ自体は、フレーム間予測されているピクチャである(例えば、リーディングピクチャ404、末尾のピクチャ406等の)他のピクチャと比較するときに、提示するためには相対的により多くのビットを必要とするであろう。第2に、IRAPピクチャ402の存在は、時間的な予測を中断するので(この中断は、その復号化プロセスにおいては、このIRAPピクチャ402のためのその復号化プロセスの複数の動作のうちの1つが、復号化されているピクチャのバッファ(DPB)の中の前の参照ピクチャを除去することであり、そのデコーダが、その復号化プロセスを更新するであろうということによる)、そのIRAPピクチャ402は、それらの他のピクチャが、それらの他のピクチャのフレーム間予測コーディングのために、より少ない参照ピクチャを有するため、復号化順408の場合にIRAPピクチャ402の後に続くピクチャのコーディングをより効率的でないものにさせる(すなわち、提示のためにはより多くのビットを必要とする)。
【0088】
IRAPピクチャ402と考えられるピクチャタイプのうちで、HEVCにおけるIDRピクチャは、他のピクチャタイプと比較されるときに、異なるシグナリング及び導出を有する。複数の相違点のうちのいくつかは、以下ようになる。
【0089】
IDRピクチャのピクチャ順序カウント(POC)値のシグナリング及び導出のために、POCの最上位ビット(MSB)部分は、前のキーピクチャからは導出されず、単に、0に等しくなるように設定される。
【0090】
参照ピクチャの管理のために必要となるシグナリング情報について、IDRピクチャのスライスヘッダは、参照ピクチャの管理を支援するために、シグナリングによって送られる必要がある情報を含まない。他のピクチャタイプ(すなわち、CRAピクチャ、末尾のピクチャ、時間軸方向の部分層アクセス(TSA)ピクチャ等)については、参照ピクチャマーキングプロセス(すなわち、参照のために使用されるか及び参照のために使用されないかにかかわらず、復号化されているピクチャのバッファ(DPB)の中の参照ピクチャの状態を決定するプロセス)のために、以下で説明されている参照ピクチャセット(RPS)又は(例えば、参照ピクチャリスト等の)他の形態の同様の情報等の情報を必要とする。一方で、IDRピクチャについては、IDRの存在は、復号化プロセスが、単に、参照のために使用されていないとして、DPBの中の複数の参照ピクチャのすべてにマークを付す必要があるということを示すので、そのような情報をシグナリングにより送る必要はない。
【0091】
HEVC及びVVCの場合には、IRAPピクチャ402及びリーディングピクチャ404は、各々、単一のネットワーク抽象化層(NAL)ユニットの中に含まれてもよい。それらのNALユニットのセットは、アクセスユニットと称されてもよい。IRAPピクチャ402及びリーディングピクチャ404は、異なるNALユニットタイプを与えられ、それによって、システムレベルのアプリケーションによって、それらの異なるNALユニットタイプを容易に識別することが可能である。例えば、ビデオスプライサは、コーディングされているビットストリームの中の構文要素の過度に詳細な内容を理解する必要なく、特に、非IRAPピクチャからIRAPピクチャ402を識別し、そして、RASLピクチャ及びRADLピクチャを決定することによって、末尾のピクチャ406からリーディングピクチャ404を識別する必要なく、コーディングされているピクチャタイプを理解する必要がある。末尾のピクチャ406は、IRAPピクチャ402と関連するとともに、提示順410の場合にIRAPピクチャ402の後に続くピクチャである。ピクチャは、復号化順408の場合に、その特定のIRAPピクチャ402の後に続き、復号化順408の場合に、いずれかの他のIRAPピクチャ402の前に置かれてもよい。この理由により、IRAPピクチャ402及びリーディングピクチャ404にそれら自身のNALユニットタイプを与えると、そのようなアプリケーションに役立つ。
【0092】
HEVCの場合に、IRAPピクチャのためのNALユニットタイプは、以下のNALユニットタイプを含む。
【0093】
リーディングピクチャを有するBLA(BLA_W_LP): 復号化順の場合に1つ又は複数のリーディングピクチャが後に続く場合がある破損リンクアクセス(BLA)ピクチャのNALユニット。
【0094】
RADLを有するBLA (BLA_W_RADL): 復号化順序の場合に1つ又は複数のRADLピクチャが後に続く場合があるが、RASLピクチャは存在しないBLAピクチャのNALユニット。
【0095】
リーディングピクチャを有しないBLA(BLA_N_LP): 復号化順の場合にリーディングピクチャが後に続いていないBLAピクチャのNALユニット。
【0096】
RADLを有するIDR (IDR_W_RADL): 復号化順の場合に1つ又は複数のRADLピクチャが後に続く場合があるが、RASLピクチャが存在しないIDRピクチャのNALユニット。
【0097】
リーディングピクチャを有しないIDR (IDR_N_LP): 復号化順の場合にリーディングピクチャが後に続かないIDRピクチャのNALユニット。
【0098】
CRA: リーディングピクチャ(すなわち、RASLピクチャ又はRADLピクチャのいずれか、或いは、それらの双方)が後に続く場合があるクリーンランダムアクセス(CRA)ピクチャのNALユニット。
【0099】
RADL: RADLピクチャのNALユニット。
【0100】
RASL: RASLピクチャのNALユニット。
【0101】
VVCの場合に、IRAPピクチャ402及びリーディングピクチャ404のためのNALユニットタイプは、以下のNALユニットタイプである。
【0102】
RADLを有するIDR (IDR_W_RADL): 復号化順の場合に1つ又は複数のRADLピクチャが後に続く場合があるが、RASLピクチャは存在しないIDRピクチャのNALユニット。
【0103】
リーディングピクチャを有しないIDR (IDR_N_LP): 復号化順の場合にリーディングピクチャの後に続かないIDRピクチャのNALユニット。
【0104】
CRA: リーディングピクチャ(RASLピクチャ又はRADLピクチャのいずれか、或いは、それらの双方)が後に続く場合があるクリーンランダムアクセス(CRA)ピクチャのNALユニット。
【0105】
RADL: RADLピクチャのNALユニット。
【0106】
RASL: RASLピクチャのNALユニット。
【0107】
図5は、漸次的復号化リフレッシュ(GDR)技術500を実装するように構成されるビデオビットストリーム550を図示している。本明細書において使用されているように、ビデオビットストリーム550は、また、コーディングされているビデオビットストリーム、ビットストリーム、又はそれらの変形と称されてもよい。図5に示されているように、ビットストリーム550は、シーケンスパラメータセット(SPS)552、ピクチャパラメータセット(PPS)554、スライスヘッダ556、及び画像データ558を含む。
【0108】
SPS552は、ピクチャシーケンス(SOP)の中のピクチャのすべてに共通であるデータを含む。対照的に、PPS554は、ピクチャ全体に共通であるデータを含む。スライスヘッダ556は、例えば、スライスタイプ及び複数の参照ピクチャのうちのいずれが使用されるか等の現在のスライスに関する情報を含む。SPS552及びPPS554は、一般的に、パラメータセットと称されてもよい。SPS552、PPS554、及びスライスヘッダ556は、ネットワーク抽象化層(NAL)ユニットのタイプである。NALユニットは、(例えば、コーディングされているビデオデータ等の)後に続くデータのタイプの指標を含む構文構造である。NALユニットは、ビデオコーディング層(VCL)及び非VCL NALユニットに分類される。VCL NALユニットは、ビデオピクチャの中のサンプルの値を表すデータを含み、非VCL NALユニットは、パラメータセット(大きな数のVCL NALユニットに適用することが可能である重要なヘッダデータ)及び補足的な強化情報(タイミング情報及びビデオピクチャの中のサンプルの値を復号化するのに必要ではないが、復号化されているビデオ信号の有用性を高めることが可能であるその他の補足データ)等の任意の関連する追加的な情報を含む。当業者は、ビットストリーム550が、実際の適用において、他のパラメータ及び情報を含んでもよいということを理解するであろう。
【0109】
図5の画像データ558は、符号化又は復号化される画像又はビデオと関連するデータを含む。画像データ558は、単に、ビットストリーム550の中で搬送されるペイロード又はデータと称されてもよい。ある1つの実施形態において、画像データ558は、CVS508(又は、CLVS)を含み、そのCVS508は、GDRピクチャ502、1つ又は複数の末尾のピクチャ504、及び回復点ピクチャ506を含む。ある1つの実施形態において、GDRピクチャ502は、CVS開始(CVSS)ピクチャと称される。CVS508は、ビデオビットストリーム550の中のあらゆるコーディングされている層ビデオシーケンス(CLVS)のためのコーディングされているビデオシーケンスである。特に、ビデオビットストリーム550が単一の層を含むときに、CVS及びCLVSは、同じになる。CVS及びCLVSは、ビデオビットストリーム550が複数の層を含むときにのみ異なる。ある1つの実施形態において、末尾のピクチャ504は、GDR期間の中の回復点ピクチャ506の前に置かれるので、それらの末尾のピクチャ504は、GDRピクチャのある1つの形態と考えられてもよい。
【0110】
ある1つの実施形態において、GDRピクチャ502、末尾のピクチャ504、及び回復点ピクチャ506は、CVS508の中でGDR期間を定義してもよい。ある1つの実施形態において、復号化順序は、GDRピクチャ502から開始し、末尾のピクチャ504へと続き、そして、その次に、回復点ピクチャ506に進む。
【0111】
CVS508は、GDRピクチャ502から開始する一連のピクチャ(又は、その一部)であり、次のGDRピクチャまで又はビットストリームの終了までのすべてのピクチャ(又は、その一部)を含むが、次のGDRピクチャを含まない。GDR期間は、GDRピクチャ502から開始する一連のピクチャであり、回復点ピクチャ506を含めて回復点ピクチャ506までのすべてのピクチャを含む。CVS508の復号化プロセスは、常に、GDRピクチャ502において開始する。
【0112】
図5に示されているように、GDR技術500又は原理は、GDRピクチャ502から開始し回復点ピクチャ506で終了する一連のピクチャにわたって機能する。GDRピクチャ502は、すべてがフレーム内予測を使用してコーディングされているブロック(すなわち、フレーム内予測されているブロック)を含む更新されている/クリーンな領域510、及び、すべてがフレーム間予測を使用してコーディングされているブロック(すなわち、フレーム間予測されているブロック)を含む更新されていない/きたない領域512を含む。
【0113】
GDRピクチャ502のすぐ隣の末尾のピクチャ504は、フレーム内予測を使用してコーディングされている第1の部分510A及びフレーム間予測を使用してコーディングされている第2の部分510Bを有する更新されている/クリーンな領域510を含む。第2の部分510Bは、例えば、CVS508のGDR期間の中の先行するピクチャの更新されている/クリーンな領域510を参照することによってコーディングされる。示されているように、末尾のピクチャ504の更新されている/クリーンな領域510は、コーディングプロセスが(例えば、左から右へといったように)一貫した方向に移動し又は進行するのに伴って拡張し、それに対応して、更新されていない/きたない領域512を縮小させる。最終的に、そのコーディングプロセスから、更新されている/クリーンな領域510のみを含む回復点ピクチャ506を取得する。特に、以下でさらに説明されるように、フレーム間予測ブロックとしてコーディングされる更新されている/クリーンな領域510の第2の部分510Bは、参照ピクチャの中の更新されている/クリーンな領域510のみを参照してもよい。
【0114】
図5に示されているように、CVS508の中のGDRピクチャ502、末尾のピクチャ504、及び回復点ピクチャ506は、各々、それら自身のVCL NALユニット530の中に含まれる。CVS508の中のVCL NALユニット530のセットは、アクセスユニットと称されてもよい。
【0115】
ある1つの実施形態において、CVS508の中のGDRピクチャ502を含むVCL NALユニット530は、GDR NALユニットタイプ(GDR_NUT)を有する。すなわち、ある1つの実施形態において、CVS508の中のGDRピクチャ502を含むVCL NALユニット530は、末尾のピクチャ504及び回復点ピクチャ506に対して自身の一意のNALユニットタイプを有する。ある1つの実施形態において、GDR_NUTは、ビットストリーム550がIRAPピクチャから開始する必要があることの代わりに、ビットストリーム550がGDRピクチャ502から開始することを可能とする。GDRピクチャ502のVCL NALユニット530をGDR_NUTとして指定すると、例えば、CVS508の中の初期のVCL NALユニット530がGDRピクチャ502を含むということをデコーダに示すことを可能とする。ある1つの実施形態において、GDRピクチャ502は、CVS508の中の初期のピクチャである。ある1つの実施形態において、GDRピクチャ502は、GDR期間の中での初期のピクチャである。
【0116】
図6は、GDRをサポートするためにエンコーダの制約を使用するときの望ましくない動き探索600を図示している概略的な図である。示されているように、動き探索600は、現在のピクチャ602及び参照ピクチャ604を示している。現在のピクチャ602及び参照ピクチャ604は、各々、フレーム内予測を使用してコーディングされている更新されている領域606、フレーム間予測を使用してコーディングされている更新されている領域608、及び更新されていない領域608を含む。更新されている領域604、更新されている領域606、及び更新されていない領域608は、図5の更新されている/クリーンな領域510の第1の部分510A、更新されている/クリーンな領域510の第2の部分510B、及び更新されていない/きたない領域512と同様である。
【0117】
動き探索プロセスの際に、エンコーダが、更新されている領域606の外側に位置している参照ブロック612の複数のサンプルのうちのいくつかを生じるいずれかの動きベクトル610を選択するのを抑制するか又は防止する。このことは、参照ブロック612が、現在のピクチャ602の中の現在のブロック614を予測するときに、最良のレート歪みコスト基準を提供するときであっても生起する。このようにして、図6は、GDRをサポートするためにエンコーダの制約を使用するときの動き探索600における非最適性の理由を図示している。
【0118】
図7は、クリーンランダムアクセス(CRA)技術700を実装するように構成されるビデオビットストリーム750を図示している。本明細書において使用されているように、ビデオビットストリーム750は、また、コーディングされているビデオビットストリーム、ビットストリーム、又はそれらの変形と称されてもよい。図7に示されているように、ビットストリーム750は、シーケンスパラメータセット(SPS)752、ピクチャパラメータセット(PPS)754、スライスヘッダ756、及び画像データ758を含む。図7におけるビットストリーム750、SPS752、PPS754、及びスライスヘッダ756は、図5におけるビットストリーム550、SPS552、PPS554、及びスライスヘッダ556と同様である。したがって、簡潔さのために、これらの要素の説明は、反復されない。
【0119】
図7の画像データ758は、符号化され又は復号化される画像又はビデオと関連するデータを含む。画像データ758は、単に、ビットストリーム750の中で搬送されるペイロード又はデータと称されてもよい。ある1つの実施形態において、画像データ758は、CRAピクチャ702、1つ又は複数の末尾のピクチャ704、及びシーケンスピクチャ706の終端を含むCVS708(又は、CLVS)を含む。ある1つの実施形態において、CRAピクチャ702は、CVSSピクチャと称される。CVS 708の復号化プロセスは、常に、CRAピクチャ702から開始する。
【0120】
図7に示されているように、CVS 708の中のCRAピクチャ702、末尾のピクチャ704、及びシーケンスピクチャ706の終端は、各々、それら自身のVCL NALユニット730の中に含まれる。CVS 708の中のVCL NALユニット730のセットは、アクセスユニットと称されてもよい。
【0121】
VVCの最新の仕様の草稿において、IRAPピクチャの前のピクチャの出力は、以下のように規定されている。IRAPピクチャのための(例えば、以前に復号化されているピクチャ等の)前のピクチャは、(1) そのIRAPピクチャよりも早い時点で復号化され、(2) 出力のために示され、(3) そのIRAPピクチャの復号化の開始時に、復号化されているピクチャのバッファ(DPB)の中に存在し、そして、(4) そのIRAPピクチャの復号化の開始時には出力されていないそれらのピクチャを指す。本明細書において使用されているように、前のピクチャは、以前に復号化されているピクチャと称されてもよい。
【0122】
スライスヘッダ構文は、IDRピクチャ及びCRAピクチャのための構文要素no_output_of_prior_pics_flagを含む。その意味論は、以下のようになる。
【0123】
no_output_of_prior_pics_flagは、VVC草稿5の付録Cの中で指定されているように、ビットストリームの中の最初のピクチャではないIDRピクチャの復号化の後の復号化されているピクチャのバッファの中の以前に復号化されているピクチャの出力に影響を与える。
【0124】
VVC草稿5のC.3.2節(現在のピクチャの復号化の前のDPBからのピクチャの削除)は、以下の記載を含む。
【0125】
- 現在のピクチャが、ピクチャ0ではない1に等しいNoIncorrectPicOutputFlagを有するIRAPピクチャであるときに、以下の順序付けられたステップを適用する。
【0126】
1. 変数NoOutputOfPriorPicsFlagは、以下のように、テスト中のデコーダのために導出される。
【0127】
- 現在のピクチャがCRAピクチャである場合に、NoOutputOfPriorPicsFlagは(no_output_of_prior_pics_flagの値に関係なく)1に等しくなるように設定される。
【0128】
- それ以外のときは、アクティブな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に設定されてもよい(が、1に設定する必要はない)。
【0129】
注 - これらの条件の下では、no_output_of_prior_pics_flagに等しくなるようにNoOutputOfPriorPicsFlagを設定することは望ましいが、この場合には、テスト中のデコーダは、NoOutputOfPriorPicsFlagを1に設定することを許可される。
【0130】
- それ以外のときは、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagに等しくなるように設定される。
【0131】
2. テスト中のデコーダのために導出されるNoOutputOfPriorPicsFlagの値は、仮説に基づいた参照デコーダ(HRD)に適用され、それによって、NoOutputOfPriorPicsFlagの値が1に等しいときに、DPBの中のピクチャ記憶バッファのすべては、それらのピクチャ記憶バッファが収容しているピクチャの出力を使用することなく空にされ、DPBフルネスは、0に等しくなるように設定される。
【0132】
VVC草稿5のC.5.2.2節(DPBからのピクチャの出力及び削除)は、以下の記載を含む。
【0133】
- 現在のピクチャが、ピクチャ0ではない1に等しいNoIncorrectPicOutputFlagを有するIRAPピクチャである場合に、以下の順序付けられたステップを適用する。
【0134】
1. 変数NoOutputOfPriorPicsFlagは、以下のように、テスト中のデコーダのために導出される。
【0135】
- 現在のピクチャがCRAピクチャである場合に、NoOutputOfPriorPicsFlagは、(no_output_of_prior_pics_flagの値に関係なく)1に等しくなるように設定される。
【0136】
- それ以外のときは、アクティブな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に設定されてもよい(が、1に設定することは必要ではない)。
【0137】
注 - これらの条件の下では、no_output_of_prior_pics_flagに等しくなるようにNoOutputOfPriorPicsFlagを設定することが望ましいが、この場合には、テスト中のデコーダは、NoOutputOfPriorPicsFlagを1に設定することを許可される。
【0138】
- それ以外のときは、NoOutputOfPriorPicsFlagは、no_output_of_prior_pics_flagに等しくなるように設定される。
【0139】
2. テスト中のデコーダのために導出されるNoOutputOfPriorPicsFlagの値は、以下のようにHRDに適用される。
【0140】
- NoOutputOfPriorPicsFlagが1に等しい場合に、DPBの中のピクチャ記憶バッファのすべては、それらのピクチャ記憶バッファが収容しているピクチャの出力を使用することなく空にされ、DPBフルネスは、0に等しくなるように設定される。
【0141】
- それ以外のときに(NoOutputOfPriorPicsFlagが0に等しいときに)、"出力のために必要とされない"及び"参照のために使用されない"とマークを付されているピクチャを収容するピクチャ記憶バッファのすべては、(出力を使用することなく)空にされ、DPBの中の空でないピクチャ記憶バッファのすべては、C.5.2.4節において指定されている"バンピング"プロセスを繰り返して呼び出すことによって空にされ、DPBフルネスは、0に等しくなるように設定される。
【0142】
既存の設計の複数の問題点を説明してきた。
【0143】
VVCの最新の仕様の草稿において、NoIncorrectPicOutputFlagが1に等しいCRAピクチャ(すなわち、新たなCVSを開始するCRAピクチャ)の場合には、NoOutputOfPriorPicsFlagの値は、no_output_of_prior_pics_flagの値にかかわらず、1に等しくなるように設定されるため、no_output_of_prior_pics_flagの値は、使用されない。それは、CVSを開始する各々のCRAピクチャの前のピクチャが出力されないということを意味する。一方で、IDRピクチャの場合と同様に、前のピクチャの出力/表示は、より連続的な再生を提供することが可能であり、したがって、復号化順に、新たなCVSを開始するピクチャ及び以降のピクチャを復号化する際にDPBがオーバーフローしない限り、より良好なユーザ体験を提供することが可能である。
【0144】
上記で説明されている問題を解決するために、この開示は、以下の発明的側面を提供する。no_output_of_prior_pics_flagの値は、新たなCVSを開始するとともにそのビットストリームの最初のピクチャではない各々のCRAピクチャの前のピクチャの出力の仕様で使用される。これにより、より連続的な再生を可能とし、したがって、より良好なユーザーの体験を可能とする。
【0145】
この開示は、また、例えば、最新のVVCの仕様の草稿の中で現在指定されている漸次的ランダムアクセス(GRA)ピクチャ等の新たなCVSを開始する他のタイプのピクチャに適用される。ある1つの実施形態において、GRAピクチャは、GDRピクチャと称されてもよく、又は、GDRピクチャと同義である。
【0146】
例として、ビデオビットストリームを復号化するときに、クリーンランダムアクセス(CRA)ピクチャに対応するフラグは、そのビットストリームの中でシグナリングによって送られる。そのフラグは、CRAピクチャが新たなコーディングされているビデオシーケンを開始するときに、復号化されているピクチャのバッファの中にあるとともにそのCRAピクチャよりも早く復号化されている復号化されたピクチャが出力されるか否かを指定する。すなわち、(例えば、その値が0に等しいときといったように)そのフラグの値が、前のピクチャが出力されるということを示すときに、前のピクチャを出力する。ある1つの実施形態において、そのフラグは、no_output_of_prior_pics_flagとして指定される。
【0147】
他の例として、ビデオビットストリームを復号化するときに、漸次的ランダムアクセス(GRA)ピクチャに対応するフラグは、そのビットストリームの中でシグナリングによって送られる。そのフラグは、そのGRAピクチャが新たなコーディングされているビデオシーケンを開始するときに、復号化されているピクチャのバッファの中にあるとともにそのGRAピクチャよりも早く復号化されている復号化されているピクチャが出力されるか否かを指定する。すなわち、(例えば、その値が0に等しいときといったように)そのフラグの値が、前のピクチャが出力されるということを示すときに、前のピクチャを出力する。ある1つの実施形態において、そのフラグは、no_output_of_prior_pics_flagとして指定される。
【0148】
瞬時デコーダリフレッシュ(IDR)ピクチャ以外の(例えば、クリーンランダムアクセス(CRA)ピクチャ、漸次的ランダムアクセス(GRA)ピクチャ、又は漸次的復号化リフレッシュ(GDR)ピクチャ、CVSSピクチャ等の)ランダムアクセスポイントピクチャに復号化順に遭遇するときに、復号化されているピクチャのバッファ(DPB)の中の(例えば、以前に復号化されているピクチャ等の)前のピクチャの出力のための技術が、本明細書において開示されている。ランダムアクセスポイントピクチャに到達するときにDPBから以前に復号化されているピクチャを空にすることは、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、ビデオコーディングの際の(また、"コーデック"としても知られている)コーダ/デコーダは、現在のコーデックと比較して改善されている。実際の問題として、改善されたビデオコーディングプロセスは、ビデオが送信され、受信され、及び/又は視聴されるときに、ユーザにより良好なユーザ体験を提供する。
【0149】
図8は、(例えば、ビデオデコーダ30等の)ビデオデコーダが実装するコーディングされているビデオビットストリームを復号化する方法800のある1つの実施形態である。その方法800は、(例えば、ビデオエンコーダ20等の)ビデオエンコーダから直接的に又は間接的に、復号化されているビットストリームを受信した後に実行されてもよい。その方法800は、ランダムアクセスポイントピクチャに遭遇するときであって、現在のピクチャを復号化する前に、DPBを空にすることによって、復号化プロセスを改善する。その方法800は、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、実際の問題として、コーデックの性能が改善され、より良好なユーザ体験につながる。
【0150】
ブロック802において、ビデオデコーダは、(例えば、ビットストリーム750等の)コーディングされているビデオビットストリームを受信する。そのコーディングされているビデオビットストリームは、第1の値を有する第1のフラグ及びクリーンランダムアクセス(CRA)ピクチャを含む。ある1つの実施形態において、CRAピクチャは、符号化されているビデオビットストリームの最初のピクチャではない。ある1つの実施形態において、第1のフラグは、no_output_of_prior_pics_flagとして指定される。
【0151】
ブロック804において、ビデオデコーダは、第1のフラグの第1の値と等しくなるように第2のフラグの第2の値を設定する。ある1つの実施形態において、第2のフラグは、NoOutputOfPriorPicsFlagとして指定される。ある1つの実施形態において、第2のフラグは、デコーダの内部に存在する。
【0152】
ブロック806において、ビデオデコーダは、第2の値を有する第2のフラグに基づいて、復号化されているピクチャのバッファ(DPB)から、以前に復号化されているあらゆるピクチャを空にする。ある1つの実施形態において、CRAピクチャを復号化した後に、以前に復号化されているピクチャは、DPBから空にされる。すなわち、ビデオデコーダは、DPBの中のピクチャ記憶バッファから、以前に復号化されているピクチャを除去する。ある1つの実施形態において、以前に復号化されているピクチャがDPBから除去されるときには、その以前に復号化されているピクチャは、出力されないか又は表示されない。ある1つの実施形態において、第1のフラグが第1の値に設定されるときには、DPBフルネスパラメータは、0に設定される。DPBフルネスパラメータは、どれだけの数のピクチャがDPBの中に保存されているかを示す。DPBフルネスパラメータを0に設定すると、DPBが空であるということを示す。
【0153】
ブロック808において、ビデオデコーダは、DPBが空になった後に現在のピクチャを復号化する。ある1つの実施形態において、現在のピクチャは、CRAピクチャと同じCVSからのピクチャであり、復号化順の場合に、CRAの後に、その現在のピクチャを取得するか又はその現在のピクチャに遭遇する。ある1つの実施形態において、現在のピクチャに基づいて生成される画像が、(例えば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータ等の)電子デバイスのユーザのために表示される。
【0154】
図9は、(例えば、ビデオエンコーダ20等の)ビデオエンコーダが実装するビデオビットストリームを符号化する方法900のある1つの実施形態である。その方法900は、(例えば、ビデオからの)ピクチャがビデオビットストリームに符号化され、そして、その次に、(例えば、ビデオデコーダ30等の)ビデオデコーダに向かって伝送されるときに実行されてもよい。その方法900は、ランダムアクセスポイントピクチャに遭遇するときであって、現在のピクチャを復号化する前に、DPBを空にするようにビデオデコーダに指示することによって、符号化プロセスを改善する。その方法900は、DPBがオーバーフローを引き起こすのを防止し、より連続的な再生を促進する。したがって、実際の問題として、コーデックの性能が改善され、より良好なユーザ体験につながる。
【0155】
ブロック902において、ビデオエンコーダは、ビデオシーケンスのためのランダムアクセスポイントを決定する。ブロック904において、ビデオエンコーダは、クリーンランダムアクセス(CRA)ピクチャを符号化して、ランダムアクセスポイントにおけるビデオシーケンスにする。ある1つの実施形態において、CRAピクチャは、ビデオビットストリームの最初のピクチャではない。
【0156】
ブロック906において、ビデオエンコーダは、フラグを第1の値に設定して、復号化されているピクチャのバッファ(DPB)から以前に復号化されているあらゆるピクチャを空にするようビデオデコーダに指示する。ある1つの実施形態において、CRAピクチャを復号化した後に、DPBからの以前に復号化されているあらゆるピクチャを空にするようにビデオデコーダに指示する。ある1つの実施形態において、フラグは、no_output_of_prior_pics_flagとして指定される。ある1つの実施形態において、ビデオエンコーダは、フラグが第1の値に設定されるときに、DPBフルネスパラメータを0に設定するようにビデオデコーダに指示する。ある1つの実施形態において、フラグの第1の値は、1である。
【0157】
ブロック908において、ビデオエンコーダは、ランダムアクセスポイントにおけるCRAピクチャを有するビデオシーケンス及びフラグを含むビデオビットストリームを生成する。ブロック910において、ビデオエンコーダは、ビデオデコーダへの伝送のために、ビデオビットストリームを格納する。
【0158】
以下の構文及び意味論は、本明細書において開示されている複数の実施形態を実装するのに使用されてもよい。以下の説明は、VVCの最新の仕様の草稿である基本テキストに関連している。言い換えると、デルタのみが記載されているが、一方で、以下で言及されていない基本テキストの中のテキストは、そのまま適用される。その基本テキストと比較して追加されているテキストは、太字で示され、削除されているテキストは、斜体で示される。
【0159】
【表1】
【0160】
【数1】
【0161】
図10は、この開示のある1つの実施形態にしたがった(例えば、ビデオエンコーダ20又はビデオエンコーダ30等の)ビデオコーディングデバイス1000の概略的な図である。そのビデオコーディングデバイス1000は、本明細書において説明されているように、複数の開示されている実施形態を実装するのに適している。ビデオコーディングデバイス1000は、データを受信するための入口ポート1010及び受信機ユニット(Rx)1020、データを処理するためのプロセッサ、論理ユニット、又は中央処理ユニット(CPU)1030、データを伝送するための送信機ユニット(Tx)1040及び出口ポート1050、及び、データを格納するためのメモリ1060を含む。ビデオコーディングデバイス1000は、また、光信号又は電気信号の出口又は入口のために、入口ポート1010、受信機ユニット1020、送信機ユニット1040、及び出口ポート1050に結合されている光電気(OE)構成要素及び電気光(EO)構成要素を含んでもよい。
【0162】
プロセッサ1030は、ハードウェア及びソフトウェアによって実装される。プロセッサ1030は、1つ又は複数のCPUチップ、(例えば、マルチコアプロセッサ等の)コア、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、及びディジタル信号プロセッサ(DSP)として実装されてもよい。プロセッサ1030は、入口ポート1010、受信機ユニット1020、送信機ユニット1040、出口ポート1050、及びメモリ1060と通信する。プロセッサ1030は、コーディングモジュール1070を含む。コーディングモジュール1070は、上記で説明されている複数の開示されている実施形態を実装する。例えば、コーディングモジュール1070は、さまざまなコーデック機能を実装し、処理し、準備し、又は提供する。したがって、コーディングモジュール1070を含めることは、ビデオコーディングデバイス1000の機能に実質的な改善をもたらし、ビデオコーディングデバイス1000の異なる状態への変換をもたらす。代替的に、コーディングモジュール1070は、メモリ1060の中に格納されている命令として実装され、プロセッサ1030によって実行される。
【0163】
ビデオコーディングデバイス1000は、また、ユーザとの間でデータを通信するための入力及び/又は出力(I/O)デバイス1080を含んでもよい。そのI/Oデバイス1080は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカ等の出力デバイスを含んでもよい。そのI/Oデバイス1080は、また、キーボード、マウス、トラックボール等の入力デバイス、及び/又は、そのような出力デバイスと対話するための対応するインターフェイスを含んでもよい。
【0164】
メモリ1060は、1つ又は複数のディスク、テープドライブ、及びソリッドステートドライブを含んでもよく、オーバーフローデータ記憶デバイスとして使用されて、実行のためにプログラムを選択するときに、そのようなプログラムを格納し、そして、プログラムの実行の際に読み出される命令及びデータを格納してもよい。メモリ1060は、例えば、揮発性であってもよく及び/又は不揮発性であってもよく、読み取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、3値コンテンツアドレス指定可能メモリ(TCAM)、及び/又はスタティックランダムアクセスメモリ(SRAM)であってもよい。
【0165】
図11は、コーディングのための手段1100のある1つの実施形態の概略的な図である。ある1つの実施形態において、コーディングのための手段1100は、(例えば、ビデオエンコーダ20又はビデオデコーダ30等の)ビデオコーディングデバイス1102によって実装される。ビデオコーディングデバイス1102は、受信手段1101を含む。受信手段1101は、符号化するピクチャを受信するか、又は、復号化するビットストリームを受信するように構成される。ビデオコーディングデバイス1102は、受信手段1101に結合される送信手段1107を含む。送信手段1107は、デコーダにビットストリームを伝送するか、又は、(例えば、複数のI/Oデバイス1080のうちの1つ等の)表示手段に復号化されている画像を伝送するように構成される。
【0166】
ビデオコーディングデバイス1102は、記憶手段1103を含む。記憶手段1103は、受信手段1101又は伝送手段1107のうちの少なくとも1つに結合される。記憶手段1103は、命令を格納するように構成される。ビデオコーディングデバイス1102は、また、処理手段1105を含む。処理手段1105は、記憶手段1103に結合される。処理手段1105は、記憶手段1103の中に格納されている命令を実行して、本明細書において開示されている方法を実行するように構成される。
【0167】
また、本明細書に記載されている例示的な方法のステップは、必ずしも、説明されている順序にしたがって実行される必要はないということを理解すべきであり、そのような方法のステップの順序は、例示的なものであるにすぎないと理解されるべきである。同様に、追加的なステップは、そのような方法に含まれてもよく、あるステップは、この開示のさまざまな実施形態と一致する方法において省略されてもよく又は組み合わされてもよい。
【0168】
複数の実施形態のうちのいくつかがこの開示によって提供されているが、開示されているシステム及び方法は、この開示の趣旨又は範囲から離れることなく、多くの他の特定の形態で具体化されてもよいということを理解すべきである。これらの例は、例示的なものとして考えられ、限定的なものではなく、その意図は、本明細書において与えられている詳細に限定されるものではない。例えば、さまざまな要素又は構成要素を組み合わせ又は一体化して、他のシステムとしてもよく、或いは、複数のある特徴は、省略されてもよく又は実装されなくてもよい。
【0169】
加えて、この開示の範囲から離れることなく、さまざまな実施形態において別々に又は個別に説明され及び図示されている技術、システム、サブシステム、及び方法を、他のシステム、モジュール、技術、又は方法と組み合わせ又は一体化してもよい。互いに結合され又は直接的に結合され又は通信する他の品目は、電気的に、機械的に、又は他の方法で、いくつかのインターフェイス、デバイス、又は中間構成要素によって、間接的に結合され、又は通信してもよい。変更、置換、及び改変の他の例は、当業者によって確認可能であり、本明細書において開示されている趣旨及び範囲から離れることなく行うことが可能である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】