1つまたは複数の実施形態の説明のための実装形態が以下で与えられるが、開示されるシステムおよび/または方法は、現在知られているか、または存在しているかにかかわらず、任意の数の技法を使用して実装され得ることを始めに理解されたい。本開示は、いかなる場合でも、本明細書において例証され説明される例示的な設計および実装形態を含む、以下で例証される説明のための実装形態、図、および技法に限定されるべきではなく、それらの均等物の完全な範囲とともに添付の特許請求の範囲内で修正され得る。
以下の頭字語が本明細書において使用される。コーディングされたビデオシーケンス(CVS)、復号ピクチャバッファ(DPB)、瞬時復号リフレッシュ(IDR)、イントラランダムアクセスポイント(IRAP)、最下位ビット(LSB)、最上位ビット(MSB)、ネットワーク抽象化レイヤ(NAL)、ピクチャ順序カウント(POC)、ローバイトシーケンスペイロード(RBSP)、シーケンスパラメータセット(SPS)、およびワーキングドラフト(WD)。
データの喪失を最小限にしながらビデオファイルのサイズを減らすために、多くのビデオ圧縮技法を利用することができる。たとえば、ビデオ圧縮技法は、空間(たとえば、イントラピクチャ)予測および/または時間(たとえば、インターピクチャ)予測を実行して、ビデオシーケンスにおけるデータ冗長性を低減または除去することを含み得る。ブロックベースのビデオコーディングのために、ビデオスライス(たとえば、ビデオピクチャまたはビデオピクチャの一部)がビデオブロックへと区分されてもよく、これは、ツリーブロック、コーディングツリーブロック(CTB)、コーディングツリーユニット(CTU)、コーディングユニット(CU)、および/またはコーディングノードとも呼ばれ得る。ピクチャのイントラコーディングされた(I)スライスの中のビデオブロックは、同じピクチャの中の近隣ブロックの中の参照サンプルに関する空間予測を使用してコーディングされる。ピクチャのインターコーディングされた単方向予測(P)または双方向予測(B)スライスの中のビデオブロックは、同じピクチャの近隣ブロックの中の参照サンプルに関する空間予測、または他の参照ピクチャの中の参照サンプルに関する時間予測を利用することによってコーディングされ得る。ピクチャはフレームおよび/または画像と呼ばれることがあり、参照ピクチャは参照フレームおよび/または参照画像と呼ばれることがある。空間予測または時間予測は、画像ブロックを表す予測ブロックをもたらす。残差データは、元の画像ブロックと予測ブロックとの間のピクセル差分を表す。したがって、インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトルと、コーディングされたブロックと予測ブロックとの間の差を示す残差データとに従って符号化される。イントラコーディングされたブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データはピクセル領域から変換領域に転送され得る。これらは、量子化され得る残差変換係数をもたらす。量子化された変換係数は最初に、2次元アレイに配列され得る。量子化された変換係数が、変換係数の1次元ベクトルを生み出すために走査され得る。エントロピーコーディングは、さらなる圧縮を達成するために適用され得る。そのようなビデオ圧縮技法は、以下でより詳しく論じられる。
符号化されたビデオが確実に正しく復号され得ることを確実にするために、対応するビデオコーディング規格に従って、ビデオが符号化され復号される。ビデオコーディング規格は、国際電気通信連合(ITU)標準化部門(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)、ならびに3次元(3D)AVC(3D-AVC)などの拡張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、および3D HEVC(3D-HEVC)などの拡張を含む。ITU-TおよびISO/IECのジョイントビデオエキスパーツチーム(JVET)は、バーサタイルビデオコーディング(VVC)と呼ばれるビデオコーディング規格の開発を開始した。VVCはワーキングドラフト(WD)に含まれており、これは、アルゴリズムの記述、VVC WDのエンコーダ側の記述、および参照ソフトウェアを提供するJVET-M1001-v6を含む。
ビデオコーディングシステムは、IRAPピクチャおよび非IRAPピクチャを利用することによってビデオを符号化し得る。IRAPピクチャは、ビデオシーケンスのためのランダムアクセスポイントとしての役割を果たす、インター予測に従ってコーディングされるピクチャである。イントラ予測では、ピクチャのブロックは、同じピクチャの中の他のブロックへの参照によってコーディングされる。これは、インター予測を利用する非IRAPピクチャとは対照的である。インター予測では、現在のピクチャのブロックは、現在のピクチャと異なる参照ピクチャの中の他のブロックへの参照によってコーディングされる。IRAPピクチャは他のピクチャを参照せずにコーディングされるので、IRAPピクチャは、最初に他のピクチャを復号することなく復号され得る。したがって、デコーダは、任意のIRAPピクチャにおいてビデオシーケンスを復号することを始めることができる。対照的に、非IRAPピクチャは他のピクチャを参照してコーディングされるので、デコーダは一般に、非IRAPピクチャにおいてビデオシーケンスの復号を始めることができない。IRAPピクチャはまた、DPBをリフレッシュする。これは、IRAPピクチャがCVSの開始点であり、CVSの中のピクチャが前のCVSの中のピクチャを参照しないからである。したがって、IRAPピクチャは、インター予測関連のコーディングエラーを止めることもでき、それは、そのようなエラーはIRAPピクチャを通って広がることができないからである。しかしながら、IRAPピクチャは、データサイズの観点から、非IRAPピクチャよりはるかに大きい。したがって、ビデオシーケンスは一般に、コーディング効率と機能性のバランスをとるために、多数の非IRAPピクチャとともに、より少数の散在するIRAPピクチャを含む。たとえば、60フレームのCVSは、1つのIRAPピクチャおよび59個の非IRAPピクチャを含み得る。
いくつかの場合、ビデオコーディングシステムは、360度ビデオとも呼ばれ得る、仮想現実(VR)ビデオをコーディングするために利用されてもよい。VRビデオは、ユーザがその球の中心にいるかのように表示される、ビデオコンテンツの球を含み得る。ビューポートと呼ばれる球の一部分のみが、ユーザに表示される。たとえば、ユーザは、ユーザの頭の動きに基づいて球のビューポートを選択して表示する、ヘッドマウントディスプレイ(HMD)を利用し得る。これは、ビデオにより描写されるような仮想空間に物理的に存在するかような印象を与える。この結果を達成するために、ビデオシーケンスの各ピクチャは、対応する瞬間におけるビデオデータの完全な球を含む。しかしながら、ピクチャの小さい部分(たとえば、単一のビューポート)のみが、ユーザに表示される。ピクチャの残りは、レンダリングされることなく廃棄される。一般に、ユーザの頭の動きに応答して異なるビューポートが動的に選択され表示され得るように、ピクチャ全体が送信される。この手法では、ビデオファイルサイズが非常に大きくなり得る。
コーディング効率を高めるために、一部のシステムはピクチャをサブピクチャへと分割する。サブピクチャは、ピクチャの定められた空間領域である。各サブピクチャは、ピクチャの対応するビューポートを含む。ビデオは、2つ以上の解像度で符号化され得る。各解像度は、異なるサブビットストリームへと符号化される。ユーザがVRビデオをストリーミングするとき、コーディングシステムは、ユーザにより使用されている現在のビューポートに基づいて、サブビットストリームを送信のためにビットストリームへと統合することができる。具体的には、現在のビューポートは高解像度のサブビットストリームから取得され、見られていないビューポートは低解像度のビットストリームから取得される。このようにして、最高品質のビデオがユーザに表示され、より低品質のビデオが廃棄される。ユーザが新しいビューポートを選択する場合、より低解像度のビデオがユーザに提示される。デコーダは、新しいビューポートがより高解像度のビデオを受信することを要求することができる。エンコーダは次いで、それに従って統合プロセスを変更することができる。IRAPピクチャに達すると、デコーダは、新しいビューポートにおいてより高解像度のビデオシーケンスの復号を開始することができる。この手法は、ユーザの視聴体験に悪影響を及ぼすことなく、ビデオ圧縮を大きく向上させる。
上述の手法についての1つの問題は、解像度を変更するために必要とされる時間の長さが、IRAPピクチャに達するまでの時間の長さに基づくということである。これは、上で説明されたように、デコーダが非IRAPピクチャにおいて異なるビデオシーケンスの復号を開始することができないからである。そのようなレイテンシを減らすための1つの手法は、より多くのIRAPピクチャを含めることである。しかしながら、これはファイルサイズの増大をもたらす。機能性とコーディング効率のバランスをとるために、異なるビューポート/サブピクチャは、異なる頻度でIRAPピクチャを含み得る。たとえば、見られる可能性がより高いビューポートは、他のビューポートより多くのIRAPピクチャを有し得る。たとえば、バスケットボールの状況では、バスケットおよび/またはセンターコートに関するビューポートが、スタンドまたは天井を見せるビューポートよりも高い頻度でIRAPピクチャを含んでもよく、それは、そのようなビューポートはユーザにより見られる可能性がより低いからである。
この手法は他の問題につながる。具体的には、ビューポートを含むサブピクチャは、単一のピクチャの一部である。異なるサブピクチャが異なる頻度でIRAPピクチャを有するとき、ピクチャの一部は、IRAPサブピクチャと非IRAPサブピクチャの両方を含む。これは、NALユニットを利用することによってピクチャがビットストリームに記憶されるので問題である。NALユニットは、ピクチャのパラメータセットまたはスライスおよび対応するスライスヘッダを含む、ストレージユニットである。アクセスユニットは、ピクチャ全体を含むユニットである。したがって、アクセスユニットは、ピクチャに関するNALユニットのすべてを含む。NALユニットはまた、スライスを含むピクチャのタイプを示すタイプを含む。一部のビデオシステムでは、(たとえば、同じアクセスユニットに含まれる)単一のピクチャに関するすべてのNALユニットが、同じタイプを有することが必要とされる。したがって、NALユニットストレージ機構は、ピクチャがIRAPサブピクチャと非IRAPサブピクチャの両方を含むとき、正しく動作しなくなることがある。
本明細書で開示されるのは、IRAPサブピクチャと非IRAPサブピクチャの両方を含むピクチャをサポートするようにNALストレージ方式を調整するための機構である。これは転じて、異なるビューポートのための異なるIRAPサブピクチャ頻度を含むVRビデオを可能にする。第1の例では、ピクチャが混合されているかどうかを示すフラグが本明細書で開示される。たとえば、このフラグは、ピクチャがIRAPサブピクチャと非IRAPサブピクチャの両方を含むことを示し得る。このフラグに基づいて、デコーダは、ピクチャ/サブピクチャを適切に復号して表示するために、復号するときに異なるタイプのサブピクチャを異なるように扱うことができる。このフラグは、ピクチャパラメータセット(PPS)に記憶されてもよく、mixed_nalu_types_in_pic_flagと呼ばれ得る。
第2の例では、ピクチャが混合しているかどうかを示すフラグが本明細書で開示される。たとえば、このフラグは、ピクチャがIRAPサブピクチャと非IRAPサブピクチャの両方を含むことを示し得る。さらに、フラグは、混合ピクチャが1つのIRAPタイプおよび1つの非IRAPタイプを含む厳密に2つのNALユニットタイプを含むように、ピクチャを制約する。たとえば、ピクチャは、ランダムアクセス復号可能先行ピクチャを伴う瞬時復号リフレッシュ(IDR)(IDR_W_RADL)、先行ピクチャを伴わないIDR(IDR_N_LP)、またはクリーンランダムアクセス(CRA)NALユニットタイプ(CRA_NUT)のうちの1つだけを含む、IRAP NALユニットを含み得る。さらに、ピクチャは、後端ピクチャNALユニットタイプ(TRAIL_NUT)、ランダムアクセス復号可能先行ピクチャNALユニットタイプ(RADL_NUT)、またはランダムアクセススキップ先行ピクチャ(RASL)NALユニットタイプ(RASL_NUT)のうちの1つだけを含む、非IRAP NALユニットを含み得る。このフラグに基づいて、デコーダは、ピクチャ/サブピクチャを適切に復号して表示するために、復号するときに異なるサブピクチャを異なるように扱うことができる。このフラグは、PPSに記憶されてもよく、mixed_nalu_types_in_pic_flagと呼ばれ得る。
図1は、ビデオ信号をコーディングすることの例示的な動作方法100のフローチャートである。具体的には、ビデオ信号はエンコーダにおいて符号化される。符号化プロセスは、ビデオファイルサイズを減らすための様々な機構を利用することによってビデオ信号を圧縮する。より小さいファイルサイズは、圧縮されたビデオファイルがユーザへ送信されることを可能にしながら、関連する帯域幅オーバーヘッドを減らす。デコーダは次いで、圧縮されたビデオファイルを復号して、エンドユーザへの表示のために元のビデオ信号を再構築する。復号プロセスは一般に、デコーダがビデオ信号を安定して再構築することを可能にするために、符号化プロセスを鏡写しにしたものである。
ステップ101において、ビデオ信号がエンコーダに入力される。たとえば、ビデオ信号は、メモリに記憶された圧縮されていないビデオファイルであり得る。別の例として、ビデオファイルは、ビデオカメラなどのビデオキャプチャデバイスによって捉えられ、ビデオのライブストリーミングをサポートするために符号化され得る。ビデオファイルは、オーディオ成分とビデオ成分の両方を含み得る。ビデオ成分は、順番に見られると視覚的な動きの効果を与える一連の画像フレームを含む。フレームは、ルマ成分(またはルマサンプル)と本明細書で呼ばれる光に関して表されるピクセル、およびクロマ成分(またはカラーサンプル)と呼ばれる色に関して表現されるピクセルを含む。いくつかの例では、フレームは、3次元視聴をサポートするために深度値も含み得る。
ステップ103において、ビデオはブロックへと区分される。区分は、各フレームのピクセルを、圧縮のために正方形および/または長方形のブロックへと再分割することを含む。たとえば、高効率ビデオコーディング(HEVC)(H.265およびMPEG-H Part 2としても知られている)では、フレームをまずコーディングツリーユニット(CTU)へと分割することができ、CTUはあらかじめ定められたサイズ(たとえば、64ピクセル対64ピクセル)のブロックである。CTUはルマサンプルとクロマサンプルの両方を含む。コーディングツリーは、CTUをブロックへと分割し、次いで、さらなる符号化をサポートする構成が達成されるまでブロックを再帰的に再分割するために利用され得る。たとえば、フレームのルマ成分は、個々のブロックが比較的一様な照明値を含むまで再分割され得る。さらに、フレームのクロマ成分は、個々のブロックが比較的一様な色値を含むまで再分割され得る。したがって、区分機構はビデオフレームの内容に依存して変化する。
ステップ105において、ステップ103において区分された画像ブロックを圧縮するために様々な圧縮機構が利用される。たとえば、インター予測および/またはイントラ予測が利用され得る。インター予測は、共通のシーンにおける物体が連続するフレームに出現する傾向にあるという事実を利用するように設計される。したがって、参照フレームの中の物体を描写するブロックは、隣接フレームにおいて繰り返し記述される必要はない。具体的には、テーブルなどの物体は、複数のフレームにわたって一定の位置にとどまり得る。したがって、テーブルは一度記述され、隣接フレームは参照フレームを参照することができる。複数のフレームにわたって物体を照合するために、パターン照合機構が利用され得る。さらに、動いている物体は、たとえば物体の動きまたはカメラの動きにより、複数のフレームにまたがって表現されることがある。特定の例として、ビデオは、複数のフレームにわたって画面上を動き回る自動車を示すことがある。動きベクトルは、そのような動きを記述するために利用され得る。動きベクトルは、フレームにおける物体の座標から参照フレームにおける物体の座標までのオフセットを与える2次元ベクトルである。したがって、インター予測は、参照フレームの中の対応するブロックからのオフセットを示す動きベクトルのセットとして、現在のフレームの中の画像ブロックを符号化することができる。
イントラ予測は共通のフレームの中のブロックを符号化する。イントラ予測は、ルマ成分およびクロマ成分がフレームにおいて密集する傾向があるという事実を利用する。たとえば、木の一部における緑色の斑点は、同様の緑色の斑点の隣に位置決めされる傾向がある。イントラ予測は、複数の指向性予測モード(たとえば、HEVCでは33個)、平面モード、および直流(DC)モードを利用する。指向性モードは、現在のブロックが対応する方向における近隣ブロックのサンプルと類似する/同じであることを示す。平面モードは、行/列(たとえば、平面)に沿った一連のブロックが行の端にある近隣ブロックに基づいて補間され得ることを示す。平面モードは、実質的に、値を変化させることにより比較的一定の勾配を利用することによって、行/列にわたる光/色の滑らかな遷移を示す。DCモードは、境界平滑化のために利用され、指向性予測モードの角度方向と関連付けられるすべての近隣ブロックのサンプルと関連付けられる平均値とブロックが同様/同じであることを示す。したがって、イントラ予測ブロックは、実際の値の代わりに様々な関係予測モード値として画像ブロックを表すことができる。さらに、インター予測ブロックは、実際の値の代わりに動きベクトル値として画像ブロックを表すことができる。いずれの場合でも、予測ブロックは、いくつかの場合、画像ブロックを厳密に表現しないことがある。あらゆる差分が残差ブロックに蓄積される。ファイルをさらに圧縮するために、残差ブロックに変換が適用され得る。
ステップ107において、様々なフィルタリング技法が適用され得る。HEVCでは、フィルタはループ内フィルタリング方式に従って適用される。上で論じられたブロックベースの予測は、デコーダにおけるブロック状画像の作成をもたらし得る。さらに、ブロックベースの予測方式は、ブロックを符号化し、次いで、参照ブロックとして後で使用するために符号化されたブロックを再構築し得る。ループ内フィルタリング方式は、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ、およびサンプル適応オフセット(SAO)フィルタをブロック/フレームに反復的に適用する。これらのフィルタは、符号化されたファイルが正確に再構築され得るように、そのようなブロッキングアーティファクトを軽減する。さらに、これらのフィルタは再構築された参照ブロックにおけるアーティファクトを軽減するので、アーティファクトは、再構築された参照ブロックに基づいて符号化される後続のブロックにおいて追加のアーティファクトを生み出す可能性がより低くなる。
ビデオ信号が区分され、圧縮され、フィルタリングされると、ステップ109において、得られるデータがビットストリームにおいて符号化される。ビットストリームは、上で論じられたデータ、ならびにデコーダにおける適切なビデオ信号の再構築をサポートするために望まれるあらゆるシグナリングデータを含む。たとえば、そのようなデータは、区分データ、予測データ、残差ブロック、およびコーディング命令をデコーダに提供する様々なフラグを含み得る。ビットストリームは、要求に応じたデコーダへの送信のためにメモリに記憶され得る。ビットストリームは、複数のデコーダへのブロードキャストおよび/またはマルチキャストでもあり得る。ビットストリームの作成は反復的なプロセスである。したがって、ステップ101、103、105、107、および109は、多数のフレームおよびブロックにわたって連続的および/または同時に発生し得る。図1に示される順序は、明確にするために、かつ議論を簡単にするために提示されており、ビデオコーディングプロセスを特定の順序に制限することは意図されていない。
ステップ111において、デコーダが、ビットストリームを受信して復号プロセスを開始する。具体的には、デコーダは、エントロピー復号方式を利用して、ビットストリームを対応するシンタックスおよびビデオデータへと変換する。ステップ111において、デコーダが、ビットストリームからのシンタックスデータを利用して、フレームに対する区分を決定する。この区分は、ステップ103におけるブロック区分の結果と一致しなければならない。ステップ111において利用されるようなエントロピー符号化/復号がここで説明される。エンコーダは、入力画像における値の空間的な位置決めに基づいて、いくつかの可能な選択肢からブロック区分方式を選択することなどの、圧縮プロセスの間に多くの選択を行う。厳密な選択のシグナリングは、多数のビンを利用し得る。本明細書では、ビンは、変数として扱われる二進値(たとえば、状況に応じて変化し得るビット値)である。エントロピーコーディングは、特定の事例に対して明らかに実行可能ではないあらゆる選択肢をエンコーダが廃棄することを可能にし、許容可能な選択肢のセットを残す。次いで、各々の許容可能な選択肢がコードワードを割り当てられる。コードワードの長さは、許容可能な選択肢の数に基づく(たとえば、2つの選択肢に対しては1つのビン、3つから4つの選択肢に対しては2つのビンなど)。エンコーダは次いで、選択された選択肢に対するコードワードを符号化する。この方式はコードワードのサイズを減らし、それは、すべての可能な選択肢の大きい可能性のあるセットからの選択を一意に示すのではなく、許容可能な選択肢の小さいサブセットからの選択を一意に示すのに望まれる程度の大きさにコードワードがなるからである。デコーダは次いで、許容可能な選択肢のセットをエンコーダと同様の方式で決定することによって、選択を復号する。許容可能な選択肢のセットを決定することによって、デコーダは、コードワードを読み取り、エンコーダによって行われる選択を決定することができる。
ステップ113において、デコーダがブロック復号を実行する。具体的には、デコーダは、逆変換を利用して残差ブロックを生成する。次いで、デコーダは、残差ブロックおよび対応する予測ブロックを利用して、区分に従って画像ブロックを再構築する。予測ブロックは、ステップ105においてエンコーダで生成されたようなイントラ予測ブロックとインター予測ブロックの両方を含み得る。再構築された画像ブロックは次いで、ステップ111において決定された区分データに従って、再構築されたビデオ信号のフレームへと位置決めされる。ステップ113に対するシンタックスはまた、上で論じられたようにエントロピーコーディングを介してビットストリームにおいてシグナリングされ得る。
ステップ115において、エンコーダにおいて、ステップ107と同様の方式で、再構築されたビデオ信号のフレームに対してフィルタリングが実行される。たとえば、ノイズ抑制フィルタ、デブロッキングフィルタ、適応ループフィルタ、およびSAOフィルタが、ブロッキングアーティファクトを取り除くためにフレームに適用され得る。フレームがフィルタリングされると、ビデオ信号は、エンドユーザによる視聴のために、ステップ117においてディスプレイに出力され得る。
図2は、ビデオコーディングのための例示的なコーディングおよび復号(コーデック)システム200の概略図である。具体的には、コーデックシステム200は、動作方法100の実施をサポートするための機能を提供する。コーデックシステム200は、エンコーダとデコーダの両方において利用されるコンポーネントを描写するために一般化されている。コーデックシステム200は、動作方法100においてステップ101および103に関して論じられるようなビデオ信号を受信して区分し、これは区分されたビデオ信号201をもたらす。コーデックシステム200は次いで、方法100のステップ105、107、および109に関して論じられたようなエンコーダとして動作するとき、区分されたビデオ信号201をコーディングされたビットストリームへと圧縮する。デコーダとして動作するとき、コーデックシステム200は、動作方法100のステップ111、113、115、および117に関して論じられたようなビットストリームから出力ビデオ信号を生成する。コーデックシステム200は、汎用コーダ制御コンポーネント211、変換スケーリングおよび量子化コンポーネント213、イントラピクチャ推定コンポーネント215、イントラピクチャ予測コンポーネント217、動き補償コンポーネント219、動き推定コンポーネント221、スケーリングおよび逆変換コンポーネント229、フィルタ制御分析コンポーネント227、ループ内フィルタコンポーネント225、復号ピクチャバッファコンポーネント223、ならびにヘッダフォーマッティングおよびコンテキスト適応バイナリ算術コーディング(CABAC)コンポーネント231を含む。そのようなコンポーネントは示されるように結合される。図2では、黒い線は符号化/復号されるべきデータの動きを示し、破線は他のコンポーネントの動作を制御する制御データの動きを示す。コーデックシステム200のコンポーネントは、すべてエンコーダの中に存在し得る。デコーダは、コーデックシステム200のコンポーネントのサブセットを含み得る。たとえば、デコーダは、イントラピクチャ予測コンポーネント217、動き補償コンポーネント219、スケーリングおよび逆変換コンポーネント229、ループ内フィルタコンポーネント225、ならびに復号ピクチャバッファコンポーネント223を含み得る。これらのコンポーネントがここで説明される。
区分されたビデオ信号201は、コーディングツリーによってピクセルのブロックへと区分された、キャプチャされたビデオシーケンスである。コーディングツリーは、様々な分割モードを利用して、ピクセルのブロックをピクセルのより小さいブロックへと再分割する。これらのブロックは次いで、より小さいブロックへとさらに再分割され得る。ブロックは、コーディングツリー上のノードと呼ばれ得る。より大きい親ノードは、より小さい子ノードへと分割される。ノードが再分割される回数は、ノード/コーディングツリーの深度と呼ばれる。いくつかの場合、分割されたブロックはコーディングユニット(CU)に含まれ得る。たとえば、CUは、ルマブロック、赤差分クロマ(Cr)ブロック、および青差分クロマ(Cb)ブロックを、CUに対する対応するシンタックス命令とともに含む、CTUの下位部分であり得る。分割モードは、利用される分割モードに応じて形状が変化する2つ、3つ、または4つの子ノードへとそれぞれノードを区分するために利用される、二分木(BT)、三分木(TT)、および四分木(QT)を含み得る。区分されたビデオ信号201は、圧縮のために、汎用コーダ制御コンポーネント211、変換スケーリングおよび量子化コンポーネント213、イントラピクチャ推定コンポーネント215、フィルタ制御分析コンポーネント227、ならびに動き推定コンポーネント221に転送される。
汎用コーダ制御コンポーネント211は、適用形態の制約に従って、ビデオシーケンスの画像のビットストリームへのコーディングに関する決定を行うように構成される。たとえば、汎用コーダ制御コンポーネント211は、ビットレート/ビットストリームサイズ対再構築品質の最適化を管理する。そのような決定は、記憶空間/帯域幅の利用可能性および画像解像度の要求に基づいて行われ得る。汎用コーダ制御コンポーネント211はまた、バッファのアンダーランおよびオーバーランの問題を軽減するために、送信速度を考慮してバッファ利用率を管理する。これらの問題を管理するために、汎用コーダ制御コンポーネント211は、他のコンポーネントによる区分、予測、およびフィルタリングを管理する。たとえば、汎用コーダ制御コンポーネント211は、圧縮の複雑さを動的に上げて解像度を向上させて帯域幅使用率を向上させ、または、圧縮の複雑さを下げて解像度および帯域幅使用率を低下させ得る。したがって、汎用コーダ制御コンポーネント211は、コーデックシステム200の他のコンポーネントを制御して、ビデオ信号再構築の品質とビットレートの問題のバランスをとる。汎用コーダ制御コンポーネント211は、制御データを作成し、これは他のコンポーネントの動作を制御する。制御データは、ヘッダフォーマッティングおよびCABACコンポーネント231にも転送されて、デコーダにおける復号のためのパラメータをシグナリングするためにビットストリームにおいて符号化される。
区分されたビデオ信号201はまた、インター予測のために動き推定コンポーネント221および動き補償コンポーネント219に送信される。区分されたビデオ信号201のフレームまたはスライスは、複数のビデオブロックへと分割され得る。動き推定コンポーネント221および動き補償コンポーネント219は、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対して相対的な、受信されたビデオブロックのインター予測コーディングを実行して、時間予測を行う。コーデックシステム200は、複数のコーディングパスを実行して、たとえば、ビデオデータの各ブロックに対して適切なコーディングモードを選択し得る。
動き推定コンポーネント221および動き補償コンポーネント219は、高度に統合され得るが、概念上の目的で別々に示される。動き推定コンポーネント221によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、予測ブロックに対して相対的なコーディングされたオブジェクトのずれを示し得る。予測ブロックは、ピクセル差分に関して、コーディングされるべきブロックによく一致することが見いだされるブロックである。予測ブロックは参照ブロックとも呼ばれ得る。そのようなピクセル差分は、絶対値差分和(SAD)、平方差分和(SSD)、または他の差分尺度によって決定され得る。HEVCは、CTU、コーディングツリーブロック(CTB)、およびCUを含む、いくつかのコーディングされたオブジェクトを利用する。たとえば、CTUをCTBへと分割することができ、次いで、CUに含めるためにCTBをCBへと分割することができる。CUは、予測データを含む予測ユニット(PU)および/またはCUのための変換された残差データを含む変換ユニット(TU)として符号化され得る。動き推定コンポーネント221は、レート歪み最適化プロセスの一部としてレート歪み分析を使用することによって、動きベクトル、PU、およびTUを生成する。たとえば、動き推定コンポーネント221は、現在のブロック/フレームのための複数の参照ブロック、複数の動きベクトルなどを決定してもよく、最良のレート歪み特性を有する参照ブロック、動きベクトルなどを選択してもよい。最良のレート歪み特性は、ビデオ再構築の品質(たとえば、圧縮によるデータ喪失の量)とコーディング効率(たとえば、最終的な符号化のサイズ)のバランスをとる。
いくつかの例では、コーデックシステム200は、復号ピクチャバッファコンポーネント223に記憶されている参照ピクチャのサブ整数ピクセル位置に対する値を計算し得る。たとえば、ビデオコーデックシステム200は、4分の1ピクセル位置、8分の1ピクセル位置、または参照ピクチャの他の分数ピクセル位置の値を補間し得る。したがって、動き推定コンポーネント221は、整数ピクセル位置と分数ピクセル位置に対する動き探索を実行して、分数ピクセル精度の動きベクトルを出力し得る。動き推定コンポーネント221は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライスの中のビデオブロックのPUに対する動きベクトルを計算する。動き推定コンポーネント221は、計算された動きベクトルを符号化のために動きデータとしてヘッダフォーマッティングおよびCABACコンポーネント231に出力し、動きを動き補償コンポーネント219に出力する。
動き補償コンポーネント219によって実行される動き補償は、動き推定コンポーネント221によって決定される動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴い得る。再び、動き推定コンポーネント221および動き補償コンポーネント219は、いくつかの例では機能的に統合され得る。現在のビデオブロックのPUに対する動きベクトルを受信すると、動き補償コンポーネント219は、動きベクトルが指し示す予測ブロックを位置特定し得る。残差ビデオブロックは次いで、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を差し引き、ピクセル差分値を形成することによって形成される。一般に、動き推定コンポーネント221は、ルマ成分に対する動き推定を実行し、動き補償コンポーネント219は、クロマ成分とルマ成分の両方に対して、ルマ成分に基づいて計算される動きベクトルを使用する。予測ブロックおよび残差ブロックは、変換スケーリングおよび量子化コンポーネント213に転送される。
区分されたビデオ信号201は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217にも送信される。動き推定コンポーネント221および動き補償コンポーネント219のように、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は高度に統合され得るが、概念上の目的で別々に示されている。イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は、上で説明されたように、フレーム間で動き推定コンポーネント221と動き補償コンポーネント219によって実行されるインター予測に対する代替として、現在のフレームの中のブロックに対して現在のブロックをイントラ予測する。具体的には、イントラピクチャ推定コンポーネント215は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定する。いくつかの例では、イントラピクチャ推定コンポーネント215は、複数の試験されるイントラ予測モードから、現在のブロックを符号化するための適切なイントラ予測モードを選択する。選択されたイントラ予測モードは次いで、符号化のためにヘッダフォーマッティングおよびCABACコンポーネント231に転送される。
たとえば、イントラピクチャ推定コンポーネント215は、様々な試験されたイントラ予測モードに対するレート歪み分析を使用してレート歪み値を計算し、試験されたモードの中で最良のレート歪み特性を有するイントラ予測モードを選択する。レート歪み分析は一般に、符号化されたブロックと、符号化されたブロックを生み出すために符号化された元の符号化されていないブロックとの間の歪み(またはエラー)の量、ならびに、符号化されたブロックを生み出すために使用されるビットレート(たとえば、ビットの数)を決定する。イントラピクチャ推定コンポーネント215は、どのイントラ予測モードがブロックに対して最良のレート歪み値を示すかを決定するために、様々な符号化されたブロックに対する歪みおよびレートから比を計算する。加えて、イントラピクチャ推定コンポーネント215は、レート歪み最適化(RDO)に基づいて、深度モデリングモード(DMM)を使用して深度マップの深度ブロックをコーディングするように構成され得る。
イントラピクチャ予測コンポーネント217は、エンコーダ上で実装されるとき、イントラピクチャ推定コンポーネント215によって決定される選択されたイントラ予測モードに基づいて予測ブロックから残差ブロックを生成し、または、デコーダ上で実装されるとき、ビットストリームから残差ブロックを読み取り得る。残差ブロックは、行列として表される、予測ブロックと元のブロックとの間の値の差分を含む。残差ブロックは次いで、変換スケーリングおよび量子化コンポーネント213に転送される。イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217は、ルマ成分とクロマ成分の両方に対して動作し得る。
変換スケーリングおよび量子化コンポーネント213は、残差ブロックをさらに圧縮するように構成される。変換スケーリングおよび量子化コンポーネント213は、離散コサイン変換(DCT)、離散サイン変換(DST)、または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生み出す。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も使用され得る。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換スケーリングおよび量子化コンポーネント213はまた、たとえば周波数に基づいて、変換された残差情報をスケーリングするように構成される。そのようなスケーリングは、異なる周波数情報が異なる粒度で量子化されるように、スケール係数を残差情報に適用することを伴い、これは、再構築されたビデオの最終的な視覚的品質に影響し得る。変換スケーリングおよび量子化コンポーネント213はまた、ビットレートをさらに低減するために変換係数を量子化するように構成される。量子化プロセスは、係数の一部またはすべてと関連付けられるビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、変換スケーリングおよび量子化コンポーネント213は次いで、量子化された変換係数を含む行列の走査を実行し得る。量子化された変換係数は、ヘッダフォーマッティングおよびCABACコンポーネント231に転送されて、ビットストリームにおいて符号化される。
スケーリングおよび逆変換コンポーネント229は、動き推定をサポートするために、変換スケーリングおよび量子化コンポーネント213の逆の動作を適用する。スケーリングおよび逆変換コンポーネント229は、逆スケーリング、変換、および/または量子化を適用して、たとえば、別の現在のブロックに対する予測ブロックになり得る参照ブロックとして後で使用するために、ピクセル領域において残差ブロックを再構築する。動き推定コンポーネント221および/または動き補償コンポーネント219は、後のブロック/フレームの動き推定において使用するために残差ブロックを対応する予測ブロックに加算し戻すことによって参照ブロックを計算し得る。スケーリング、量子化、および変換の間に生み出されるアーティファクトを軽減するために、再構築された参照ブロックにフィルタが適用される。そのようなアーティファクトは、そうされなければ、後続のブロックが予測されるときに不正確な予測を引き起こす(およびさらなるアーティファクトを生み出す)ことがある。
フィルタ制御分析コンポーネント227およびループ内フィルタコンポーネント225は、フィルタを残差ブロックおよび/または再構築された画像ブロックに適用する。たとえば、スケーリングおよび逆変換コンポーネント229からの変換された残差ブロックは、元の画像ブロックを再構築するために、イントラピクチャ予測コンポーネント217および/または動き補償コンポーネント219からの対応する予測ブロックと組み合わせられ得る。フィルタは次いで、再構築された画像ブロックに適用され得る。いくつかの例では、フィルタは代わりに、残差ブロックに適用され得る。図2の他のコンポーネントのように、フィルタ制御分析コンポーネント227およびループ内フィルタコンポーネント225は高度に統合され、一緒に実装され得るが、概念上の目的で別々に図示されている。再構築された参照ブロックに適用されるフィルタは、特定の空間領域に適用され、そのようなフィルタがどのように適用されるかを調整するための複数のパラメータを含む。フィルタ制御分析コンポーネント227は、そのようなフィルタがどこで適用されるべきかを決定するために再構築された参照ブロックを分析し、対応するパラメータを設定する。そのようなデータは、符号化のためにフィルタ制御データとしてヘッダフォーマッティングおよびCABACコンポーネント231に転送される。ループ内フィルタコンポーネント225は、フィルタ制御データに基づいてそのようなフィルタを適用する。フィルタは、デブロッキングフィルタ、ノイズ抑制フィルタ、SAOフィルタ、および適応ループフィルタを含み得る。そのようなフィルタは、例に応じて、空間/ピクセル領域で(たとえば、再構築されたピクセルブロック上で)、または周波数領域で適用され得る。
エンコーダとして動作するとき、フィルタリングされた再構築された画像ブロック、残差ブロック、および/または予測ブロックは、上で論じられたような動き推定において後で使用するために、復号ピクチャバッファコンポーネント223に記憶される。デコーダとして動作するとき、復号ピクチャバッファコンポーネント223は、出力ビデオ信号の一部として、再構築されフィルタリングされたブロックを記憶してディスプレイに転送する。復号ピクチャバッファコンポーネント223は、予測ブロック、残差ブロック、および/または再構築された画像ブロックを記憶することが可能な任意のメモリデバイスであり得る。
ヘッダフォーマッティングおよびCABACコンポーネント231は、コーデックシステム200の様々なコンポーネントからデータを受信し、デコーダへの送信のためにそのようなデータをコーディングされたビットストリームへと符号化する。具体的には、ヘッダフォーマッティングおよびCABACコンポーネント231は、一般的な制御データおよびフィルタ制御データなどの制御データを符号化するために、様々なヘッダを生成する。さらに、イントラ予測および動きデータ、ならびに量子化された変換係数データの形態の残差データを含む予測データが、すべてビットストリームにおいて符号化される。最終的なビットストリームは、元の区分されたビデオ信号201を再構築するためにデコーダによって望まれるすべての情報を含む。そのような情報は、イントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)、様々なブロックに対する符号化コンテキストの定義、最も確率の高いイントラ予測モードの指示、区分情報の指示なども含み得る。そのようなデータは、エントロピーコーディングを利用することによって符号化され得る。たとえば、情報は、コンテキスト適応可変長コーディング(CAVLC)、CABAC、シンタックスベースコンテキスト適応バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を利用することによって符号化され得る。エントロピーコーディングに続いて、コーディングされたビットストリームは、別のデバイス(たとえば、ビデオデコーダ)に送信されてもよく、または、より後の送信もしくは取り出しのためにアーカイブされてもよい。
図3は、例示的なビデオエンコーダ300を示すブロック図である。ビデオエンコーダ300は、コーデックシステム200の符号化機能を実装するために、ならびに/または動作方法100のステップ101、103、105、107、および/もしくは109を実装するために利用され得る。エンコーダ300は、入力ビデオ信号を区分し、区分されたビデオ信号201と実質的に同様である区分されたビデオ信号301をもたらす。区分されたビデオ信号301は次いで圧縮されて、エンコーダ300のコンポーネントによりビットストリームへと符号化される。
具体的には、区分されたビデオ信号301は、イントラ予測のためにイントラピクチャ予測コンポーネント317に転送される。イントラピクチャ予測コンポーネント317は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217と実質的に同様であり得る。区分されたビデオ信号301はまた、復号ピクチャバッファコンポーネント323の中の参照ブロックに基づくインター予測のために動き補償コンポーネント321に転送される。動き補償コンポーネント321は、動き推定コンポーネント221および動き補償コンポーネント219と実質的に同様であり得る。イントラピクチャ予測コンポーネント317および動き補償コンポーネント321からの予測ブロックおよび残差ブロックは、残差ブロックの変換および量子化のために変換および量子化コンポーネント313に転送される。変換および量子化コンポーネント313は、変換スケーリングおよび量子化コンポーネント213と実質的に同様であり得る。変換され量子化された残差ブロックおよび対応する予測ブロックは(関連する制御データとともに)、ビットストリームへのコーディングのためにエントロピーコーディングコンポーネント331に転送される。エントロピーコーディングコンポーネント331は、ヘッダフォーマッティングおよびCABACコンポーネント231と実質的に同様であり得る。
変換され量子化された残差ブロックおよび/または対応する予測ブロックは、動き補償コンポーネント321により使用される参照ブロックへの再構築のために、変換および量子化コンポーネント313から逆変換および量子化コンポーネント329にも転送される。逆変換および量子化コンポーネント329は、スケーリングおよび逆変換コンポーネント229と実質的に同様であり得る。ループ内フィルタコンポーネント325の中のループ内フィルタは、例に応じて、残差ブロックおよび/または再構築された参照ブロックにも適用される。ループ内フィルタコンポーネント325は、フィルタ制御分析コンポーネント227およびループ内フィルタコンポーネント225と実質的に同様であり得る。ループ内フィルタコンポーネント325は、ループ内フィルタコンポーネント225に関して論じられたような複数のフィルタを含み得る。フィルタリングされたブロックは次いで、動き補償コンポーネント321により参照ブロックとして使用するために、復号ピクチャバッファコンポーネント323に記憶される。復号ピクチャバッファコンポーネント323は、復号ピクチャバッファコンポーネント223と実質的に同様であり得る。
図4は、例示的なビデオデコーダ400を示すブロック図である。ビデオデコーダ400は、コーデックシステム200の復号機能を実装するために、ならびに/または動作方法100のステップ111、113、115、および/もしくは117を実施するために利用され得る。デコーダ400は、たとえばエンコーダ300から、ビットストリームを受信し、エンドユーザに表示するために、再構築された出力ビデオ信号をビットストリームに基づいて生成する。
ビットストリームは、エントロピー復号コンポーネント433によって受信される。エントロピー復号コンポーネント433は、CAVLC、CABAC、SBAC、PIPEコーディング、または他のエントロピーコーディング技法などのエントロピー復号方式を実装するように構成される。たとえば、エントロピー復号コンポーネント433は、ビットストリームにおいてコードワードとして符号化される追加のデータを解釈するためのコンテキストを提供するために、ヘッダ情報を利用し得る。復号された情報は、一般的な制御データ、フィルタ制御データ、区分情報、動き情報、予測データ、および残差ブロックからの量子化された変換係数などの、ビデオ信号を復号するための任意の望まれる情報を含む。量子化された変換係数は、残差ブロックへの再構築のために逆変換および量子化コンポーネント429に転送される。逆変換および量子化コンポーネント429は、逆変換および量子化コンポーネント329と同様であり得る。
再構築された残差ブロックおよび/または予測ブロックは、イントラ予測動作に基づいて、画像ブロックへの再構築のためにイントラピクチャ予測コンポーネント417に転送される。イントラピクチャ予測コンポーネント417は、イントラピクチャ推定コンポーネント215およびイントラピクチャ予測コンポーネント217と同様であり得る。具体的には、イントラピクチャ予測コンポーネント417は、フレームの中で参照ブロックを位置特定するために予測モードを利用し、残差ブロックを結果に適用してイントラ予測された画像ブロックを再構築する。再構築されたイントラ予測された画像ブロックおよび/または残差ブロックならびに対応するインター予測データは、ループ内フィルタコンポーネント425を介して復号ピクチャバッファコンポーネント423に転送され、これらは、復号ピクチャバッファコンポーネント223およびループ内フィルタコンポーネント225とそれぞれ実質的に同様であり得る。ループ内フィルタコンポーネント425は、再構築された画像ブロック、残差ブロック、および/または予測ブロックをフィルタリングし、そのような情報は復号ピクチャバッファコンポーネント423に記憶される。復号ピクチャバッファコンポーネント423からの再構築された画像ブロックは、インター予測のために動き補償コンポーネント421に転送される。動き補償コンポーネント421は、動き推定コンポーネント221および/または動き補償コンポーネント219と実質的に同様であり得る。具体的には、動き補償コンポーネント421は、参照ブロックからの動きベクトルを利用して予測ブロックを生成し、残差ブロックを結果に適用して画像ブロックを再構築する。得られる再構築されたブロックはまた、ループ内フィルタコンポーネント425を介して復号ピクチャバッファコンポーネント423に転送され得る。復号ピクチャバッファコンポーネント423は、追加の再構築された画像ブロックを記憶し続け、これらは区分情報を介してフレームへと再構築され得る。そのようなフレームは、シーケンスにも配置され得る。シーケンスは、再構築された出力ビデオ信号としてディスプレイに出力される。
図5は、例示的なCVS500を示す概略図である。たとえば、CVS500は、方法100に従って、コーデックシステム200および/またはエンコーダ300などのエンコーダによって符号化され得る。さらに、CVS500は、コーデックシステム200および/またはデコーダ400などのデコーダによって復号され得る。CVS500は、復号順序508でコーディングされるピクチャを含む。復号順序508は、ピクチャがビットストリームにおいて位置決めされる順序である。CVS500のピクチャは次いで、提示順序510で出力される。提示順序510は、得られたビデオを適切に表示させるためにデコーダによってピクチャが表示されるべき順序である。たとえば、CVS500のピクチャは、一般に提示順序510で位置決めされ得る。しかしながら、たとえばインター予測をサポートするために類似したピクチャをより近くに配置することによって、コーディング効率を高めるために、いくつかのピクチャが異なる位置へと移動され得る。このようにそのようなピクチャを動かすと、復号順序508が得られる。示される例では、ピクチャは、0から4まで復号順序508でインデックスをつけられる。提示順序510において、インデックス2およびインデックス3におけるピクチャは、インデックス0におけるピクチャの前に移動されている。
CVS500はIRAPピクチャ502を含む。IRAPピクチャ502は、CVS500のためのランダムアクセスポイントとして役割を果たす、イントラ予測に従ってコーディングされるピクチャである。具体的には、IRAPピクチャ502のブロックは、IRAPピクチャ502の他のブロックへの参照によってコーディングされる。IRAPピクチャ502は他のピクチャを参照せずにコーディングされるので、いずれの他のピクチャも先に復号することなく、IRAPピクチャ502が復号され得る。したがって、デコーダは、IRAPピクチャ502においてCVS500の復号を開始することができる。さらに、IRAPピクチャ502により、DPBがリフレッシュされるようになり得る。たとえば、IRAPピクチャ502の後に提示されるピクチャは、インター予測のためにIRAPピクチャ502の前のピクチャ(たとえば、ピクチャインデックス0)に依存しなくてもよい。したがって、ピクチャバッファは、IRAPピクチャ502が復号されるとリフレッシュされ得る。これには、あらゆるインター予測関連のコーディングエラーを止める効果があり、それは、そのようなエラーはIRAPピクチャ502を通って広がることができないからである。IRAPピクチャ502は、様々なタイプのピクチャを含み得る。たとえば、IRAPピクチャは、IDRまたはCRAとしてコーディングされ得る。IDRは、新しいCVS500を開始してピクチャバッファをリフレッシュする、イントラコーディングされたピクチャである。CRAは、新しいCVS500を開始することなく、またはピクチャバッファをリフレッシュすることなく、ランダムアクセスポイントとして動作するイントラコーディングされたピクチャである。このようにして、CRAと関連付けられる先行ピクチャ504はCRAの前のピクチャを参照することがあるが、IDRと関連付けられる先行ピクチャ504はIDRの前のピクチャを参照しないことがある。
CVS500は様々な非IRAPピクチャも含む。これらは、先行ピクチャ504および後端ピクチャ506を含む。先行ピクチャ504は、復号順序508においてIRAPピクチャ502の後に位置決めされるが、提示順序510においてIRAPピクチャ502の前に位置決めされるピクチャである。後端ピクチャ506は、復号順序508と提示順序510の両方においてIRAPピクチャ502の後に位置決めされる。先行ピクチャ504および後端ピクチャ506はともに、インター予測に従ってコーディングされる。後端ピクチャ506は、IRAPピクチャ502またはIRAPピクチャ502の後に位置決めされるピクチャを参照してコーディングされる。したがって、後端ピクチャ506は、IRAPピクチャ502が復号されると常に復号されることが可能である。先行ピクチャ504は、ランダムアクセススキップ先行(RASL)ピクチャおよびランダムアクセス復号可能先行(RADL)ピクチャを含み得る。RASLピクチャは、IRAPピクチャ502の前のピクチャへの参照によってコーディングされるが、IRAPピクチャ502の後の位置においてコーディングされる。RASLピクチャは以前のピクチャに依存するので、IRAPピクチャ502においてデコーダが復号を開始するとき、RASLピクチャを復号することはできない。したがって、RASLピクチャは、IRAPピクチャ502がランダムアクセスポイントとして使用されるとき、スキップされ、復号されない。しかしながら、デコーダがランダムアクセスポイントとして前のIRAPピクチャ(インデックス0より前にあり示されていない)を使用するとき、RASLピクチャが復号されて表示される。RADLピクチャは、IRAPピクチャ502および/またはIRAPピクチャ502の後のピクチャを参照してコーディングされるが、提示順序510においてIRAPピクチャ502の前に位置決めされる。RADLピクチャはIRAPピクチャ502の前のピクチャに依存しないので、IRAPピクチャ502がランダムアクセスポイントであるとき、RADLピクチャを復号して表示することができる。
CVS500からのピクチャは各々、アクセスユニットに記憶され得る。さらに、ピクチャはスライスへと区分されてもよく、スライスはNALユニットに含まれてもよい。NALユニットは、ピクチャのパラメータセットまたはスライスおよび対応するスライスヘッダを含むストレージユニットである。NALユニットは、NALユニットに含まれるデータのタイプをデコーダに示すためのタイプを割り当てられる。たとえば、IRAPピクチャ502からのスライスは、RADLを伴うIDR(IDR_W_RADL)NALユニット、先行ピクチャを伴わないIDR(IDR_N_LP)NALユニット、CRA NALユニットなどに含まれ得る。IDR_W_RADL NALユニットは、IRAPピクチャ502がRADL先行ピクチャ504と関連付けられるIDRピクチャであることを示す。IDR_N_LP NALユニットは、IRAPピクチャ502がいずれの先行ピクチャ504とも関連付けられないIDRピクチャであることを示す。CRA NALユニットは、IRAPピクチャ502が先行ピクチャ504と関連付けられ得るCRAピクチャであることを示す。非IRAPピクチャのスライスも、NALユニットへと配置され得る。たとえば、後端ピクチャ506のスライスは、後端ピクチャNALユニットタイプ(TRAIL_NUT)に配置されてもよく、これは、後端ピクチャ506がインター予測コーディングされたピクチャであることを示す。先行ピクチャ504のスライスは、RASL NALユニットタイプ(RASL_NUT)および/またはRADL NALユニットタイプ(RADL_NUT)に含まれてもよく、これは、対応するピクチャが対応するタイプのインター予測コーディングされた先行ピクチャ504であることを示し得る。対応するNALユニットにおいてピクチャのスライスをシグナリングすることによって、デコーダは、各ピクチャ/スライスに適用すべき適切な復号機構を容易に決定することができる。
図6は、VRピクチャビデオストリーム600から分割された、複数のサブピクチャビデオストリーム601、602、および603を示す概略図である。たとえば、サブピクチャビデオストリーム601~603および/またはVRピクチャビデオストリーム600の各々が、CVS500においてコーディングされ得る。したがって、サブピクチャビデオストリーム601~603および/またはVRピクチャビデオストリーム600は、方法100に従って、コーデックシステム200および/またはエンコーダ300などのエンコーダによって符号化され得る。さらに、サブピクチャビデオストリーム601~603および/またはVRピクチャビデオストリーム600は、コーデックシステム200および/またはデコーダ400などのデコーダによって復号され得る。
VRピクチャビデオストリーム600は、時間をかけて提示される複数のピクチャを含む。具体的には、VRはビデオコンテンツの球をコーディングすることによって動作し、これは、球の中心にユーザがいるかのように表示され得る。各ピクチャは球全体を含む。一方、ビューポートとして知られているピクチャの一部分のみが、ユーザに表示される。たとえば、ユーザは、ユーザの頭の動きに基づいて球のビューポートを選択して表示する、ヘッドマウントディスプレイ(HMD)を利用し得る。これは、ビデオにより描写されるような仮想空間に物理的に存在するかような印象を与える。この結果を達成するために、ビデオシーケンスの各ピクチャが、対応する瞬間におけるビデオデータの完全な球を含む。しかしながら、ピクチャの小さい部分(たとえば、単一のビューポート)のみが、ユーザに表示される。ピクチャの残りは、レンダリングされることなく廃棄される。一般に、ユーザの頭の動きに応答して異なるビューポートが動的に選択され表示され得るように、ピクチャ全体が送信される。
示される例では、VRピクチャビデオストリーム600のピクチャは各々、利用可能なビューポートに基づいてサブピクチャへと再分割され得る。したがって、各ピクチャおよび対応するサブピクチャは、時間的な提示の一部としてある時間位置(たとえば、ピクチャ順序)を含む。再分割が経時的に一貫して適用されるとき、サブピクチャビデオストリーム601~603が作成される。そのような一貫した再分割はサブピクチャビデオストリーム601~603を生み出し、各ストリームは、VRピクチャビデオストリーム600の中の対応するピクチャに対して相対的なある所定のサイズ、形状、および空間位置をもつサブピクチャのセットを含む。さらに、サブピクチャビデオストリーム601~603の中のサブピクチャのセットは、提示時間にわたって時間位置が変化する。したがって、サブピクチャビデオストリーム601~603のサブピクチャは、時間位置に基づいて時間領域において揃えられ得る。次いで、各々の時間位置におけるサブピクチャビデオストリーム601~603からのサブピクチャは、表示のためにVRピクチャビデオストリーム600を再構築するために、あらかじめ定められた空間位置に基づいて空間領域において統合され得る。具体的には、サブピクチャビデオストリーム601~603は各々、別々のサブビットストリームへと符号化され得る。そのようなサブビットストリームが一緒に統合されるとき、それらは、経時的にピクチャの全体のセットを含むビットストリームをもたらす。得られたビットストリームは、ユーザの現在選択されているビューポートに基づく復号および表示のために、デコーダへと送信され得る。
VRビデオについての問題の1つは、サブピクチャビデオストリーム601~603のすべてが高品質(たとえば、高解像度)でユーザに送信され得るということである。これは、デコーダがユーザの現在のビューポートを動的に選択し、対応するサブピクチャビデオストリーム601~603からのサブピクチャをリアルタイムで表示することを可能にする。しかしながら、ユーザは、たとえばサブピクチャビデオストリーム601からの、単一のビューポートしか見ないことがあり、一方でサブピクチャビデオストリーム602~603は廃棄される。したがって、高品質でサブピクチャビデオストリーム602~603を送信することは、大量の帯域幅を無駄にすることがある。コーディング効率を高めるために、VRビデオは複数のビデオストリーム600へと符号化されてもよく、各ビデオストリーム600は異なる品質/解像度で符号化される。このようにして、デコーダは、現在のサブピクチャビデオストリーム601に対する要求を送信することができる。それに応答して、エンコーダ(または中間スライサまたは他のコンテンツサーバ)が、より高品質のビデオストリーム600からのより高品質のサブピクチャビデオストリーム601、およびより低品質のビデオストリーム600からのより低品質のサブピクチャビデオストリーム602~603を選択することができる。エンコーダは次いで、そのようなサブビットストリームを一緒に、デコーダへの送信のために完成した符号化されたビットストリームへと統合することができる。このようにして、デコーダは、現在のビューポートがより高品質であり他のビューポートがより低品質である、一連のピクチャを受信する。さらに、最高品質のサブピクチャは一般にユーザに表示され(頭の動きなし)、より低品質のサブピクチャは一般に廃棄され、これは機能性とコーディング効率のバランスをとる。
ユーザが振り返ってサブピクチャビデオストリーム601ではなくサブピクチャビデオストリーム602を見るようになる場合、デコーダは、新しい現在のサブピクチャビデオストリーム602がより高品質で送信されることを要求する。エンコーダは次いで、それに従って統合機構を変更することができる。上で述べられたように、デコーダは、IRAPピクチャ502においてのみ新しいCVS500の復号を開始することができる。したがって、サブピクチャビデオストリーム602は、IRAPピクチャ/サブピクチャに達するまで、より低品質で表示される。IRAPピクチャは次いで、サブピクチャビデオストリーム602のより高品質のバージョンの復号を開始するために、より高品質で復号され得る。この手法は、ユーザの視聴体験に悪影響を及ぼすことなく、ビデオ圧縮を大きく向上させる。
上述の手法についての1つの問題は、解像度を変更するために必要とされる時間の長さが、ビデオストリームにおいてIRAPピクチャに達するまでの時間の長さに基づくということである。これは、デコーダが非IRAPピクチャにおいてサブピクチャビデオストリーム602の異なるバージョンの復号を開始することができないからである。そのようなレイテンシを減らすための1つの手法は、より多くのIRAPピクチャを含めることである。しかしながら、これはファイルサイズの増大をもたらす。機能性とコーディング効率のバランスをとるために、異なるビューポート/サブピクチャビデオストリーム601~603は、異なる頻度でIRAPピクチャを含み得る。たとえば、見られる可能性がより高いビューポート/サブピクチャビデオストリーム601~603は、他のビューポート/サブピクチャビデオストリーム601~603より多くのIRAPピクチャを有し得る。たとえば、バスケットボールの状況では、バスケットおよび/またはセンターコートに関するビューポート/サブピクチャビデオストリーム601~603が、スタンドまたは天井を見せるビューポート/サブピクチャビデオストリーム601~603よりも高い頻度でIRAPピクチャを含んでもよく、それは、そのようなビューポート/サブピクチャビデオストリーム601~603はユーザにより見られる可能性がより低いからである。
この手法は追加の問題につながる。具体的には、POCを共有するサブピクチャビデオストリーム601~603からのサブピクチャは、単一のピクチャの一部である。上で述べられたように、ピクチャからのスライスは、ピクチャタイプに基づいてNALユニットに含められる。一部のビデオコーディングシステムでは、単一のピクチャに関するすべてのNALユニットは、同じNALユニットタイプを含むように制約される。異なるサブピクチャビデオストリーム601~603が異なる頻度でIRAPピクチャを有するとき、ピクチャの一部はIRAPサブピクチャと非IRAPサブピクチャの両方を含む。これは、各々の単一のピクチャが同じタイプのNALユニットのみを利用すべきであるという制約に違反する。
本開示は、ピクチャの中のスライスのためのすべてのNALユニットが同じNALユニットタイプを利用するという制約を取り除くことによって、この問題に対処する。たとえば、ピクチャはアクセスユニットに含まれる。この制約を取り除くことによって、アクセスユニットは、IRAP NALユニットタイプと非IRAP NALユニットタイプの両方を含み得る。さらに、ピクチャ/アクセスユニットがIRAP NALユニットタイプと非IRAP NALユニットタイプの混合を含むときを示すための、フラグが符号化され得る。いくつかの例では、このフラグは、ピクチャにおける混合NALユニットタイプフラグ(mixed_nalu_types_in_pic_flag)である。加えて、単一の混合ピクチャ/アクセスユニットが1つのタイプのIRAP NALユニットおよび1つのタイプの非IRAP NALユニットのみを含み得ることを要求するために、制約が適用され得る。これは、意図されていないNALユニットタイプの混合の発生を防ぐ。そのような混合が許容される場合、デコーダはそのような混合を管理するように設計されなければならない。これは、コーディングプロセスにさらなる利益をもたらすことなく、必要とされるハードウェアの複雑さを不必要に増大させる。たとえば、混合ピクチャは、IDR_W_RADL、IDR_N_LP、またはCRA_NUTから選択された1つのタイプのIRAP NALユニットを含み得る。さらに、混合ピクチャは、TRAIL_NUT、RADL_NUT、およびRASL_NUTから選択された1つのタイプの非IRAP NALユニットを含み得る。この方式の例示的な実装形態が、以下でより詳しく論じられる。
図7は、混合NALユニットタイプのピクチャを含む、例示的なビットストリーム700を示す概略図である。たとえば、ビットストリーム700は、方法100に従って、コーデックシステム200および/またはデコーダ400による復号のためにコーデックシステム200および/またはエンコーダ300によって生成され得る。さらに、ビットストリーム700は、複数のビデオ解像度の複数のサブピクチャビデオストリーム601~603から統合されたVRピクチャビデオストリーム600を含んでもよく、各サブピクチャビデオストリームは異なる空間位置においてCVS500を含む。
ビットストリーム700は、シーケンスパラメータセット(SPS)710、1つまたは複数のピクチャパラメータセット(PPS)711、複数のスライスヘッダ715、および画像データ720を含む。SPS710は、ビットストリーム700に含まれるビデオシーケンスの中のすべてのピクチャに共通のシーケンスデータを含む。そのようなデータは、ピクチャサイズ、ビット深度、コーディングツールパラメータ、ビットレート制限などを含み得る。PPS711は、ピクチャ全体に適用されるパラメータを含む。したがって、ビデオシーケンスの中の各ピクチャは、PPS711を参照し得る。各ピクチャはPPS711を参照するが、いくつかの例では、単一のPPS711は複数のピクチャのためのデータを含み得ることに留意されたい。たとえば、複数の類似するピクチャは、類似するパラメータに従ってコーディングされ得る。そのような場合、単一のPPS711はそのような類似するピクチャのためのデータを含み得る。PPS711は、対応するピクチャの中のスライスに利用可能なコーディングツール、量子化パラメータ、オフセットなどを示すことができる。スライスヘッダ715は、ピクチャの中の各スライスに固有のパラメータを含む。したがって、ビデオシーケンスの中のスライスごとに1つのスライスヘッダ715があり得る。スライスヘッダ715は、スライスタイプ情報、ピクチャ順序カウント(POC)、参照ピクチャリスト、予測重み、タイルエントリポイント、デブロッキングパラメータなどを含み得る。スライスヘッダ715はまた、いくつかの文脈ではタイルグループヘッダとも呼ばれ得ることに留意されたい。
画像データ720は、インター予測および/またはイントラ予測に従って符号化されるビデオデータ、ならびに対応する変換され量子化される残差データを含む。たとえば、ビデオシーケンスは、画像データ720としてコーディングされる複数のピクチャ721を含む。ピクチャ721は、ビデオシーケンスの単一のフレームであるので、一般に、ビデオシーケンスを表示するとき単一のユニットとして表示される。しかしながら、サブピクチャ723は、仮想現実などのいくつかの技術を実装するために表示され得る。ピクチャ721は各々、PPS711を参照する。ピクチャ721は、サブピクチャ723、タイル、および/またはスライスへと分割され得る。サブピクチャ723は、コーディングされたビデオシーケンスにわたって一貫して適用されるピクチャ721の空間領域である。したがって、サブピクチャ723は、VRの文脈ではHMDによって表示され得る。さらに、指定されたPOCを伴うサブピクチャ723は、対応する解像度のサブピクチャビデオストリーム601~603から取得され得る。サブピクチャ723はSPS710を参照し得る。いくつかのシステムでは、スライス725はタイルを含むタイルグループと呼ばれる。スライス725および/またはタイルのタイルグループはスライスヘッダ715を参照する。スライス725は、単一のNALユニットに排他的に含まれるピクチャ721のタイル内の、整数個の完全なタイルまたは整数個の連続する完全なCTU行として定義され得る。したがって、スライス725は、CTUおよび/またはCTBへとさらに分割される。CTU/CTBはさらに、コーディングツリーに基づいてコーディングブロックへと分割される。コーディングブロックは次いで、予測機構に従って符号化/復号され得る。
パラメータセットおよび/またはスライス725は、NALユニットにおいてコーディングされる。NALユニットは、後続のデータのタイプの指示を含むシンタックス構造、および必要に応じてエミュレーション防止バイトが散在するRBSPの形式のデータを含むバイトとして定義され得る。より具体的には、NALユニットは、ピクチャ721のパラメータセットまたはスライス725および対応するスライスヘッダ715を含む、ストレージユニットである。具体的には、VCL NALユニット740は、ピクチャ721のスライス725および対応するスライスヘッダ715を含むNALユニットである。さらに、非VCL NALユニット730は、SPS710およびPPS711などのパラメータセットを含む。NALユニットのいくつかのタイプが利用され得る。たとえば、SPS710およびPPS711はそれぞれ、両方とも非VCL NALユニット730である、SPS NALユニットタイプ(SPS_NUT)731およびPPS NALユニットタイプ(PPS_NUT)732に含まれ得る。
上で述べられたように、IRAPピクチャ502などのIRAPピクチャは、IRAP NALユニット745に含まれ得る。先行ピクチャ504および後端ピクチャ506などの非IRAPピクチャは、非IRAP NALユニット749に含まれ得る。具体的には、IRAP NALユニット745は、IRAPピクチャまたはサブピクチャから取られるスライス725を含む任意のNALユニットである。非IRAP NALユニット749は、IRAPピクチャまたはサブピクチャ(たとえば、先行ピクチャまたは後端ピクチャ)ではない任意のピクチャから取られるスライス725を含む任意のNALユニットである。IRAP NALユニット745および非IRAP NALユニット749はともにスライスデータを含むので、ともにVCL NALユニット740である。ある例示的な実施形態では、IRAP NALユニット745は、それぞれ、IDR_N_LP NALユニット741またはIDR_w_RADL NALユニット742の中の、先行ピクチャを伴わないIDRピクチャまたはRADLピクチャと関連付けられるIDRからスライス725を含み得る。さらに、IRAP NALユニット745は、CRA_NUT 743の中のCRAピクチャからスライス725を含み得る。ある例示的な実施形態では、非IRAP NALユニット749は、それぞれ、RASL_NUT 746、RADL_NUT 747、またはTRAIL_NUT 748の中の、RASLピクチャ、RADLピクチャ、または後端ピクチャからのスライス725を含み得る。ある例示的な実施形態では、あり得るNALユニットの完全なリストが、NALユニットタイプによって分類されるものとして以下で示される。
上で述べられたように、VRビデオストリームは、異なる頻度でIRAPピクチャを伴うサブピクチャ723を含み得る。これにより、ユーザが見る可能性の低い空間領域に対してより少数のIRAPピクチャが利用されること、および、ユーザが頻繁に見る可能性の高い空間領域に対してより多数のIRAPピクチャが利用されることが可能になる。このようにして、ユーザが定期的に切り替える可能性の高い空間領域は、より高い解像度へと迅速に調整され得る。この手法により、IRAP NALユニット745と非IRAP NALユニット749の両方を含むピクチャ721が得られるとき、ピクチャ721は混合ピクチャと呼ばれる。この条件は、ピクチャフラグ(mixed_nalu_types_in_pic_flag)727の中の混合NALユニットタイプによってシグナリングされ得る。mixed_nalu_types_in_pic_flag 727は、PPS711において設定され得る。さらに、mixed_nalu_types_in_pic_flag 727は、PPS711を参照する各ピクチャ721が1つより多くのVCL NALユニット740を有することと、VCL NALユニット740がNALユニットタイプ(nal_unit_type)の同じ値を有しないこととを指定するとき、1に等しく設定され得る。さらに、mixed_nalu_types_in_pic_flag 727は、PPS711を参照する各ピクチャ721が1つまたは複数のVCL NALユニット740を有し、PPS711を参照する各ピクチャ721のVCL NALユニット740がすべてnal_unit_typeの同じ値を有するとき、0に等しく設定され得る。
さらに、mixed_nalu_types_in_pic_flag 727が設定されるとき、ピクチャ721のサブピクチャ723のうちの1つまたは複数のVCL NALユニット740がすべてNALユニットタイプの第1の特定の値を有し、ピクチャ721の中の他のVCL NALユニット740がすべてNALユニットタイプの異なる第2の特定の値を有するような、制約が利用され得る。たとえば、その制約は、混合ピクチャ721が単一のタイプのIRAP NALユニット745および単一のタイプの非IRAP NALユニット749を含むことを要求し得る。たとえば、ピクチャ721は、1つもしくは複数のIDR_N_LP NALユニット741、1つもしくは複数のIDR_w_RADL NALユニット742、または1つもしくは複数のCRA_NUT 743を含み得るが、そのようなIRAP NALユニット745のどのような組合せも含むことができない。さらに、ピクチャ721は、1つもしくは複数のRASL_NUT 746、1つもしくは複数のRADL_NUT 747、または1つもしくは複数のTRAIL_NUT 748を含み得るが、そのようなIRAP NALユニット745のどのような組合せも含むことができない。
ある例示的な実装形態では、ピクチャタイプは、復号プロセスを定義するために利用される。そのようなプロセスは、たとえばピクチャ順序カウント(POC)、復号ピクチャバッファ(DPB)における参照ピクチャステータスのマーキング、DPBからのピクチャの出力などによる、ピクチャ識別情報の導出を含む。ピクチャは、コーディングされたピクチャすべてまたはその一部を含む、NALユニットタイプに基づくタイプによって識別され得る。一部のビデオコーディングシステムでは、ピクチャタイプは、瞬時復号リフレッシュ(IDR)ピクチャおよび非IDRピクチャを含み得る。他のビデオコーディングシステムでは、ピクチャタイプは、後端ピクチャ、時間サブレイヤアクセス(TSA)ピクチャ、ステップ毎時間サブレイヤアクセス(STSA)ピクチャ、ランダムアクセス復号可能先行(RADL)ピクチャ、ランダムアクセススキップ先行(RASL)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャ、瞬時ランダムアクセスピクチャ、およびクリーンランダムアクセスピクチャを含み得る。そのようなピクチャタイプはさらに、ピクチャがサブレイヤ参照ピクチャであるかサブレイヤ非参照ピクチャであるかに基づいて区別され得る。BLAピクチャはさらに、先行ピクチャを伴うBLA、RADLピクチャを伴うBLA、および先行ピクチャを伴わないBLAとして区別され得る。IDRピクチャはさらに、RADLピクチャを伴うIDRおよび先行ピクチャを伴わないIDRとして区別され得る。
そのようなピクチャタイプは、様々なビデオ関連の機能を実装するために利用され得る。たとえば、IDR、BLA、および/またはCRAピクチャは、IRAPピクチャを実装するために利用され得る。IRAPピクチャは、以下の機能/利点を提供し得る。IRAPピクチャの存在は、そのピクチャから復号プロセスを開始できることを示し得る。この機能は、IRAPピクチャがビットストリームの中のある指定された位置に存在する限り復号プロセスがその位置において開始するような、ランダムアクセス特徴の実装を可能にする。そのような位置は、必ずしもビットストリームの最初にはない。IRAPピクチャの存在はまた、RASLピクチャを除くIRAPピクチャにおいて開始するコーディングされたピクチャが、IRAPピクチャの前に位置決めされるピクチャを参照せずにコーディングされるように、復号プロセスをリフレッシュする。したがって、ビットストリームの中に位置決めされるIRAPピクチャは、復号エラーの広がりを止める。したがって、IRAPピクチャの前に位置決めされたコーディングされたピクチャの復号エラーは、IRAPピクチャを通り復号順序においてIRAPピクチャの後にあるピクチャへと広がることはできない。
IRAPピクチャは、様々な機能を提供するが、圧縮効率に対する不利益を生み出す。したがって、IRAPピクチャの存在は、ビットレートの急上昇を引き起こし得る。圧縮効率へのこの不利益には様々な原因がある。たとえば、IRAPピクチャは、非IRAPピクチャとして使用されるインター予測されたピクチャよりはるかに多数のビットにより表される、イントラ予測されたピクチャである。さらに、IRAPピクチャの存在は、インター予測において使用される時間予測を破壊する。具体的には、IRAPピクチャは、DPBから以前の参照ピクチャを取り除くことによって、復号プロセスをリフレッシュする。以前の参照ピクチャを取り除くことは、復号順序においてIRAPピクチャの後にあるピクチャのコーディングにおいて使用するための参照ピクチャの利用可能性を低下させるので、このプロセスの効率を下げる。
IDRピクチャは、他のIRAPピクチャタイプとは異なるシグナリングおよび導出プロセスを利用し得る。たとえば、IDR関連のシグナリングおよび導出プロセスは、以前のキーピクチャからMSBを導出するのではなく、POCの最上位ビット(MSB)部分を0に設定し得る。さらに、IDRピクチャのスライスヘッダは、参照ピクチャ管理を助けるために使用される情報を含まないことがある。一方、CRA、後端、TSAなどの他のピクチャタイプは、参照ピクチャセット(RPS)または参照ピクチャリストなどの参照ピクチャ情報を含むことがあり、これらは、参照ピクチャマーキングプロセスを実施するために利用され得る。参照ピクチャマーキングプロセスは、参照のために使用されるもの、または参照のために使用されないもののいずれかとして、DPBの中の参照ピクチャのステータスを決定するプロセスである。IDRピクチャでは、そのような情報はシグナリングされなくてもよく、それは、IDRの存在が、復号プロセスがDPBの中のすべての参照ピクチャを参照のために使用されないものとして単純にマークすべきであることを示すからである。
ピクチャタイプに加えて、POCによるピクチャ識別も、インター予測における参照ピクチャの使用の管理、DPBからのピクチャの出力、動きベクトルのスケーリング、重み付けられた予測などの、複数の目的で利用される。たとえば、一部のビデオコーディングシステムでは、DPBの中のピクチャは、短期参照のために使用される、長期参照のために使用される、または参照のために使用されないものとしてマークされ得る。ピクチャが参照のために使用されないものとしてマークされると、もはやそのピクチャを予測のために使用することはできない。そのようなピクチャが出力のためにもはや必要とされないとき、ピクチャはDPBから除去され得る。他のビデオコーディングシステムでは、参照ピクチャは短期および長期としてマークされ得る。参照ピクチャは、ピクチャが予測参照のためにもはや必要とされないとき、参照のために使用されないものとしてマークされ得る。これらのステータス間の変換は、復号参照ピクチャマーキングプロセスによって制御され得る。暗黙的スライディングウィンドウプロセスおよび/または明示的メモリ管理制御動作(MMCO)プロセスが、復号参照ピクチャマーキング機構として利用され得る。スライディングウィンドウプロセスは、参照フレームの数がSPSにおいてmax_num_ref_framesと表記される指定された最大の数に等しいとき、参照のために使用されないものとして短期参照ピクチャをマークする。短期参照ピクチャはfirst-in first-out方式で記憶され得るので、大半の最近復号された短期ピクチャはDPBに保持される。明示的MMCOプロセスは、複数のMMCO命令を含み得る。MMCO命令は、1つまたは複数の短期または長期参照ピクチャを参照のために使用されないものとしてマークし、すべてのピクチャを参照のために使用されないものとしてマークし、または、現在の参照ピクチャもしくは既存の短期参照ピクチャを長期参照ピクチャとしてマークし、長期ピクチャインデックスをその長期参照ピクチャに割り当て得る。
一部のビデオコーディングシステムでは、参照ピクチャマーキング動作ならびにDPBからのピクチャの出力および除去のためのプロセスは、ピクチャが復号された後に実行される。他のビデオコーディングシステムは、参照ピクチャ管理のためにRPSを利用する。RPS機構とMMCO/スライディングウィンドウプロセスとの最も基本的な違いは、各々の特定のスライスに対して、RPSが現在のピクチャまたは任意の後続のピクチャにより使用される参照ピクチャの完全なセットを提供するということである。したがって、現在のピクチャまたは未来のピクチャによる使用のためにDPBの中に保たれるべきすべてのピクチャの完全なセットが、RPSにおいてシグナリングされる。これは、DPBへの相対的な変更のみがシグナリングされる、MMCO/スライディングウィンドウ方式とは異なる。RPS機構があれば、DPBの中の参照ピクチャの正しいステータスを維持するために、復号順序においてより前のピクチャからの情報は必要とされない。RPSの利点を活用してエラー耐性を高めるために、ピクチャ復号およびDPB動作の順序は、一部のビデオコーディングシステムでは変更される。一部のビデオコーディングシステムでは、DPBからの復号されたピクチャの出力と除去の両方を含むピクチャマーキングおよびバッファ動作が、現在のピクチャが復号された後で適用され得る。他のビデオコーディングシステムでは、RPSはまず、現在のピクチャのスライスヘッダから復号され、次いで、ピクチャのマーキングおよびバッファ動作が、現在のピクチャを復号する前に適用され得る。
VVCにおいて、参照ピクチャ管理手法は次のように要約され得る。リスト0およびリスト1と表記される2つの参照ピクチャリストが、直接シグナリングされ導出される。それらは、上で論じられたような、RPSまたはスライディングウィンドウおよびMMCOプロセスに基づくものではない。参照ピクチャマーキングは、参照ピクチャリストの中のアクティブエントリと非アクティブエントリの両方を利用する参照ピクチャリスト0および1に直接基づくが、アクティブエントリのみがCTUのインター予測において参照インデックスとして使用され得る。2つの参照ピクチャリストの導出のための情報は、SPS、PPS、およびスライスヘッダの中の、シンタックス要素およびシンタックス構造によってシグナリングされる。あらかじめ定められたRPL構造は、スライスヘッダの中で参照することによって使用するために、SPSの中にシグナリングされる。2つの参照ピクチャリストは、双方向インター予測(B)スライス、単方向インター予測(P)スライス、およびイントラ予測(I)スライスを含む、すべてのタイプのスライスに対して生成される。2つの参照ピクチャリストは、参照ピクチャリスト初期化プロセスまたは参照ピクチャリスト修正プロセスを使用することなく構築され得る。長期参照ピクチャ(LTRP)はPOC LSBによって識別される。デルタPOC MSBサイクルは、ピクチャごとに決定されるようなLTRPのためにシグナリングされ得る。
ビデオ画像をコーディングするために、画像はまず区分され、区分はビットストリームへとコーディングされる。様々なピクチャ区分方式が利用可能である。たとえば、画像は、普通のスライス、従属スライス、タイルへと、および/または、波面並列処理(WPP)に従って区分され得る。簡潔にするために、ビデオコーディングのためにCTBのグループへとスライスを区分するときに、普通のスライス、従属スライス、タイル、WPP、およびそれらの組合せが使用され得るように、HEVCはエンコーダを制約する。そのような区分は、最大伝送単位(MTU)サイズの適合、並列処理、エンドツーエンド遅延の低減をサポートするために適用され得る。MTUは、単一のパケットにおいて送信され得るデータの最大の量を表記する。パケットペイロードがMTUを超える場合、そのペイロードは断片化と呼ばれる処理を通じて2つのパケットに分割される。
単にスライスとも呼ばれる普通のスライスは、ループフィルタリング操作によるある程度の相互依存性にもかかわらず、同じピクチャ内の他の普通のスライスとは独立に再構築され得る画像の区分された部分である。各々の普通のスライスは、送信のために固有のネットワーク抽象化レイヤ(NAL)ユニットにカプセル化される。さらに、ピクチャ内予測(イントラサンプル予測、動き情報予測、コーディングモード予測)およびスライス境界にまたがるエントロピーコーディング依存性は、独立した再構築をサポートするために無効にされ得る。そのような独立した再構築は並列化をサポートする。たとえば、普通のスライスベースの並列化は、最小限のプロセッサ間通信またはコア間通信を利用する。しかしながら、各々の普通のスライスは独立であるので、各スライスは別々のスライスヘッダと関連付けられる。普通のスライスの使用は、各スライスに対するスライスヘッダのビットコストにより、およびスライス境界にまたがる予測の欠如により、かなりのコーディングオーバーヘッドを招き得る。さらに、普通のスライスは、MTUサイズの要件との適合をサポートするために利用され得る。具体的には、普通のスライスは別個のNALユニットにカプセル化されており独立にコーディングされ得るので、各々の普通のスライスは、複数のパケットへとスライスを壊すのを避けるために、MTU方式におけるMTUより小さくなければならない。したがって、並列化の目標およびMTUサイズの適合の目標は、ピクチャにおけるスライスレイアウトに対して矛盾する要求を課すことがある。
従属スライスは普通のスライスと似ているが、短縮されたスライスヘッダを有し、ピクチャ内予測を壊すことなく画像ツリーブロック境界の区分を可能にする。したがって、従属スライスは、普通のスライスが複数のNALユニットへと断片化されることを可能にし、これは、普通のスライス全体の符号化が完了する前に普通のスライスの一部が送り出されることを可能にすることにより、エンドツーエンド遅延の低減をもたらす。
ピクチャは、タイルグループ/スライスおよびタイルへと分割され得る。タイルは、ピクチャの長方形領域をカバーするCTUのシーケンスである。タイルグループ/スライスは、ピクチャのある数のタイルを含む。ラスタースキャンタイルグループモードおよび長方形タイルグループモードが、タイルを作成するために利用され得る。ラスタースキャンタイルグループモードでは、タイルグループは、ピクチャのタイルラスタースキャンにおけるタイルのシーケンスを含む。長方形タイルグループモードでは、タイルグループは、ピクチャの長方形領域を集合的に形成するピクチャのある数のタイルを含む。長方形タイルグループ内のタイルは、タイルグループのタイルラスタースキャンの順序にある。たとえば、タイルは、タイルの列および行を作り出す水平境界および垂直境界により作り出される画像の区分された部分であり得る。タイルはラスター走査順序(右から左および上から下)でコーディングされ得る。CTBの走査順序はタイル内で局所的である。したがって、第1のタイルのCTBは、次のタイルのCTBに進む前に、ラスター走査順序でコーディングされる。普通のスライスと同様に、タイルは、ピクチャ内予測の依存性、ならびにエントロピー復号の依存性を壊す。しかしながら、タイルは個々のNALユニットに含まれないことがあるので、タイルはMTUサイズの適合のために使用されないことがある。各タイルを、1つのプロセッサ/コアによって処理することができ、近隣のタイルを復号する処理ユニット間のピクチャ内予測のために利用されるプロセッサ間/コア間通信は、共有されるスライスヘッダを搬送すること(隣接するタイルが同じスライスの中にあるとき)、および再構築されたサンプルとメタデータのループフィルタリング関連の共有を実行することに限定されてもよい。1つより多くのタイルがスライスに含まれるとき、スライスの中の第1のエントリポイントオフセット以外の各タイルに対するエントリポイントバイトオフセットが、スライスヘッダにおいてシグナリングされ得る。各スライスおよびタイルに対して、1)スライスの中のすべてのコーディングされたツリーブロックが同じスライスに属する、および2)タイルの中のすべてのコーディングされたブロックが同じスライスに属するという、条件のうちの少なくとも1つが満たされるべきである。
WPPでは、画像はCTBの単一の行へと区分される。エントロピー復号および予測機構は、他の行におけるCTBからのデータを使用し得る。並列処理は、CTB行の並列復号を通じて可能にされる。たとえば、現在の行は、先行する行と並列に復号され得る。しかしながら、現在の行の復号は、2つのCTBによる先行する行の復号プロセスより遅れる。この遅延により、現在の行における現在のCTBの上にあるCTBおよび右上にあるCTBに関するデータは、現在のCTBがコーディングされる前に利用可能になることが確実になる。この手法は、グラフィカルに表現されると波面として現れる。このずらされた開始は、最大で、画像が含むCTB行の数と同じ数のプロセッサ/コアを用いた、並列化を可能にする。ピクチャ内の近隣のツリーブロック行間のピクチャ内予測が許容されるので、ピクチャ内予測を可能にするためのプロセッサ間/コア間通信はかなり多くなり得る。WPPの区分はNALユニットサイズを考慮する。したがって、WPPはMTUサイズの適合をサポートしない。しかしながら、要求に応じてMTUサイズの適合を実施するために、ある程度のコーディングオーバーヘッドを伴って、WPPとともに普通のスライスが使用され得る。最終的に、波面セグメントは厳密に1つのCTB行を含み得る。さらに、WPPを利用するとき、およびスライスがCTB行内で開始するとき、スライスは同じCTB行において終了すべきである。
タイルは動き制約タイルセットも含み得る。動き制約タイルセット(MCTS)は、関連する動きベクトルが、MCTSの内部の整数サンプル位置と、補間のためのMCTSの内部の整数サンプル位置のみを必要とする分数サンプル位置とを指し示すように制約されるように設計された、タイルセットである。さらに、MCTSの外部のブロックから導かれる時間動きベクトル予測に対する動きベクトル候補の使用は許容されない。このようにして、各MCTSは、MCTSに含まれないタイルが存在することなく、独立に復号され得る。時間MCTS補足強化情報(SEI)メッセージは、ビットストリームにおけるMCTSの存在を示し、MCTSをシグナリングするために使用され得る。MCTS SEIメッセージは、MCTSセットに対する適合するビットストリームを生成するために、MCTSサブビットストリーム抽出(SEIメッセージのセマンティクスの一部として規定される)において使用され得る補足情報を提供する。情報は、いくつかの抽出情報セットを含み、その各々が、MTCSセットの数を定義し、MCTSサブビットストリーム抽出プロセスの間に使用されるべき置換ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)、およびピクチャパラメータセット(PPS)のローバイトシーケンスペイロード(RBSP)バイトを含む。MCTSサブビットストリーム抽出プロセスに従ってサブビットストリームを抽出するとき、パラメータセット(VPS、SPS、およびPPS)は、書き直され、または置き換えられてもよく、スライスヘッダは更新されてもよく、それは、スライスアドレス関連のシンタックス要素(first_slice_segment_in_pic_flagおよびslice_segment_addressを含む)のうちの1つまたはすべてが、抽出されたサブビットストリームにおいて異なる値を利用し得るからである。
360度ビデオアプリケーションとも呼ばれるVRアプリケーションは、完全な球の一部のみを、結果として、ピクチャ全体のサブセットのみを表示し得る。ハイパーテキストトランスファープロトコルを介した動的適応ストリーミング(DASH)機構を介したビューポート依存の360度配信が、ビットレートを下げてストリーミング機構を介した360度ビデオの配信をサポートするために利用され得る。この機構は、たとえばキューブマッププロジェクション(CMP)を利用することによって、球/投影されるピクチャを複数のMCTSへと分割する。異なる空間解像度または品質を伴う2つ以上のビットストリームが符号化され得る。データをデコーダに配信するとき、より高解像度/高品質のビットストリームからのMCTSが、表示されるべきビューポート(たとえば、前のビューポート)のために送信される。より低解像度/低品質のビットストリームからのMCTSが、他のビューポートのために送信される。これらのMCTSは、ある方法で詰め込まれて、次いで復号されるために受信機に送信される。ユーザにより見られるビューポートは、良い視聴体験を生み出すために高解像度/高品質のMCTSによって表現されることが期待される。ユーザの頭が別のビューポート(たとえば、左または右のビューポート)を見るように動くとき、表示されるコンテンツは、システムが新しいビューポートのための高解像度/高品質のMCTSをフェッチしている間の短い期間、より低解像度/低品質のビューポートから来る。ユーザの頭が別のビューポートを見るように動くとき、ユーザの頭の動きの時間と、ビューポートのより高解像度/高品質の表現が見られる時間との間に、遅延がある。この遅延は、システムがそのビューポートのためのより高解像度/高品質のMCTSをどれだけ速くフェッチできるかに依存し、これはIRAP期間に依存する。IRAP期間は、2つのIRAPの発生と発生の間の間隔である。この遅延はIRAP期間に関連し、それは、新しいビューポートのMCTSはIRAPピクチャからしか復号可能になり得ないからである。
たとえば、IRAP期間が1秒ごとにコーディングされる場合、以下のことが当てはまる。遅延の最良の場合のシナリオは、システムが新しいセグメント/IRAP期間のフェッチを開始する直前に、ユーザの頭が新しいビューポートを見るように動く場合の、ネットワークラウンドトリップ遅延と同じである。このシナリオでは、システムは、新しいビューポートのためのより高解像度/高品質のMCTSをすぐに要求することができるので、唯一の遅延はネットワークラウンドトリップ遅延であり、これは、最低のバッファ遅延をほぼ0に設定することができ、センサ遅延は小さく無視できると仮定すると、フェッチする要求と要求されたMCTSの送信時間を足した遅延である。ネットワークラウンドトリップ遅延は、たとえば200ミリ秒前後であり得る。遅延の最悪の場合のシナリオは、システムが次のセグメントのための要求をすでに行った直後にユーザの頭が新しいビューポートを見るように動く場合の、IRAP期間+ネットワークラウンドトリップ遅延である。上記の最悪の場合のシナリオを改善するためにIRAP期間がより短くなるように、より頻繁なIRAPピクチャを用いてビットストリームを符号化することができ、それは、このことが全体の遅延を減らすからである。しかしながら、この手法は、圧縮効率が下がるので帯域幅の要件を増大させる。
ある例示的な実装形態では、同じコーディングされたピクチャのサブピクチャは、異なるnal_unit_type値を含むことが許容される。この機構は次のように説明される。ピクチャはサブピクチャへと分割され得る。サブピクチャは、0に等しいtile_group_addressを有するタイルグループで開始する、タイルグループ/スライスの長方形セットである。各サブピクチャは、対応するPPSを参照し得るので、別々のタイル区分を有し得る。サブピクチャの存在はPPSにおいて示され得る。各サブピクチャは、復号プロセスにおいてピクチャのように扱われる。サブピクチャ境界にまたがるループ内フィルタリングは、常に無効にされ得る。サブピクチャの幅および高さは、ルマCTUサイズの単位で指定され得る。ピクチャにおけるサブピクチャの位置はシグナリングされなくてもよいが、以下の規則を使用して導出されてもよい。サブピクチャは、あるピクチャの境界内でそのサブピクチャを含むのに十分大きい、そのピクチャ内のCTUラスタースキャン順序において次の占有されていない位置を占める。各サブピクチャを復号するための参照ピクチャは、復号ピクチャバッファの中の参照ピクチャから、現在のサブピクチャと同じ位置にあるエリアを抽出することによって生成される。抽出されたエリアは復号されたサブピクチャであるので、インター予測は、同じサイズのサブピクチャとピクチャ内の同じ位置との間で行われる。そのような場合、コーディングされたピクチャ内で異なるnal_unit_type値を許容することは、ランダムアクセスピクチャから生じるサブピクチャと、非ランダムアクセスピクチャから生じるサブピクチャとが、実質的な困難を伴うことなく(たとえば、VCLレベルの修正なしで)同じコーディングされたピクチャへと統合されることを可能にする。そのような利益は、MCTSベースのコーディングに対しても当てはまる。
コーディングされたピクチャ内で異なるnal_unit_type値を許容することは、他のシナリオにおいて有益であり得る。たとえば、ユーザは、360度ビデオコンテンツのいくつかのエリアを、他のエリアよりも頻繁に見ることがある。MCTS/サブピクチャベースのビューポート依存360度ビデオ配信における、コーディング効率と平均の匹敵品質ビューポート切替レイテンシとのより良好なトレードオフを得るために、他のエリアよりもより一般的に見られるエリアに対して、より頻繁なIRAPピクチャをコーディングすることができる。匹敵品質ビューポート切替レイテンシは、第1のビューポートから第2のビューポートに切り替えるときに、第2のビューポートの提示品質が第1のビューポートに匹敵する提示品質に達するまでにユーザが体験するレイテンシである。
別の実装形態は、POC導出および参照ピクチャ管理を含むピクチャ内での混合NALユニットタイプのサポートのために、以下の解決策を利用する。混合IRAPおよび非IRAPサブピクチャを伴うピクチャがあり得るかどうかを指定するために、タイルグループにより直接または間接的に参照されるフラグ(sps_mixed_tile_groups_in_pic_flag)がパラメータセットの中に存在する。IDRタイルグループを含むNALユニットに対して、POC MSBがピクチャのためのPOC導出においてリセットされるかどうかを指定するために、フラグ(poc_msb_reset_flag)が対応するタイルグループヘッダの中に存在する。PicRefreshFlagと呼ばれる変数が定義され、ピクチャと関連付けられる。このフラグは、POC導出およびDPB状態がピクチャを復号するときにリフレッシュされるべきであるかどうかを指定する。PicRefreshFlagの値は次のように導出される。現在のタイルグループがビットストリームの中の最初のアクセスユニットに含まれる場合、PicRefreshFlagは1に等しく設定される。それ以外の場合、現在のタイルグループがIDRタイルグループである場合、PicRefreshFlagはsps_mixed_tile_groups_in_pic_flag?poc_msb_reset_flag:1に等しく設定される。そうではなく、現在のタイルグループがCRAタイルグループである場合、次のことが当てはまる。現在のアクセスユニットがコーディングされたシーケンスの最初のアクセスユニットである場合、PicRefreshFlagは1に等しく設定される。現在のアクセスユニットは、アクセスユニットがシーケンスNALユニットの最後の直後にあるとき、または関連する変数HandleCraAsFirstPicInCvsFlagが1に等しく設定されるとき、コーディングされたシーケンスの最初のアクセスユニットである。それ以外の場合(たとえば、現在のタイルグループは、ビットストリームの中の最初のアクセスユニットに属さず、IRAPタイルグループではない)、PicRefreshFlagは0に等しく設定される。
PicRefreshFlagが1に等しいとき、POC MSBの値(PicOrderCntMsb)は、ピクチャのためのPOCの導出の間に0に等しくなるようにリセットされる。参照ピクチャセット(RPS)または参照ピクチャリスト(RPL)などの参照ピクチャ管理のために利用される情報は、対応するNALユニットタイプとは無関係にタイルグループ/スライスヘッダにおいてシグナリングされる。参照ピクチャリストは、NALユニットタイプとは無関係に、各タイルグループの復号の最初において構築される。参照ピクチャリストは、RPL手法のためのRefPicList[0]およびRefPicList[1]、RPS手法のためのRefPicList0[]およびRefPicList1[]、またはピクチャのインター予測動作のための参照ピクチャを含む同様のリストを含み得る。PicRefreshFlagが1に等しいとき、参照ピクチャマーキングプロセスの間、DPBの中のすべての参照ピクチャが、参照のために使用されないものとしてマークされる。
そのような実装形態は、いくつかの問題と関連付けられる。たとえば、ピクチャ内でのnal_unit_type値の混合が許容されないとき、ならびに、ピクチャがIRAPピクチャであるかどうかの導出および変数NoRaslOutputFlagの導出がピクチャレベルで記述されるとき、デコーダは、任意のピクチャの最初のVCL NALユニットを受信した後でこれらの導出を実行することができる。しかしながら、ピクチャ内での混合NALユニットタイプのサポートにより、デコーダは、上記の導出を実行する前に、ピクチャの他のVCL NALユニットの到達を待たなければならない。最悪の場合、デコーダは、ピクチャの最後のVCL NALユニットの到達を待たなければならない。さらに、そのようなシステムは、POC MSBがピクチャのためのPOC導出においてリセットされるかどうかを指定するために、IDR NALユニットのタイルグループヘッダにおいてフラグをシグナリングし得る。この機構には次の問題がある。混合CRA NALユニットタイプおよび非IRAP NALユニットタイプの場合は、この機構によりサポートされない。さらに、VCL NALユニットのタイルグループ/スライスヘッダにおけるこの情報のシグナリングは、IRAP(IDRまたはCRA)NALユニットがピクチャの中の非IRAP NALユニットと混合されるかどうかのステータスへの変化とき、ビットストリーム抽出または統合の間に値の変更を必要とする。スライスヘッダのそのような書き換えが、ユーザがビデオを要求するときに常に発生するので、大量のハードウェアリソースを必要とする。さらに、特定のIRAP NALユニットタイプおよび特定の非IRAP NALユニットタイプの混合以外の、ピクチャ内での異なるNALユニットタイプの何らかの他の混合が許容される。そのような柔軟性は、コーデックの設計を複雑にする一方で現実の使用事例をサポートせず、これは、デコーダの複雑さを不必要に増大させ、したがって関連する実装コストを増大させる。
一般に、本開示は、ビデオコーディングにおけるサブピクチャまたはMCTSベースのランダムアクセスのサポートのための技法を説明する。より具体的には、本開示は、サブピクチャまたはMCTSベースのランダムアクセスをサポートするために利用される、ピクチャ内での混合NALユニットタイプのサポートのための改善された設計を説明する。技法の説明は、VVC規格に基づくが、他のビデオ/メディアコーデック仕様にも適用される。
上記の問題を解決するために、以下の例示的な実装形態が開示される。そのような実装形態は、個別に、または組合せで適用され得る。一例では、各ピクチャは、ピクチャが混合nal_unit_type値を含むかどうかの指示と関連付けられる。この指示はPPSにおいてシグナリングされる。この指示は、すべての参照ピクチャを参照のために使用されないものとしてマークすることによって、POC MSBをリセットするかどうか、および/またはDPBをリセットするかどうかの決定をサポートする。この指示がPPSにおいてシグナリングされるとき、PPSの値の変更が、統合または別個の抽出の間に行われ得る。しかしながら、PPSはそのようなビットストリーム抽出または統合の間に書き換えられて他の機構により置き換えられるので、これは許容可能である。
代替的に、この指示は、タイルグループヘッダにおいてシグナリングされるが、ピクチャのすべてのタイルグループに対して同じであることが必要とされ得る。しかしながら、この場合、値は、MCTS/サブピクチャシーケンスのサブビットストリーム抽出の間に変更される必要があり得る。代替的に、この指示は、NALユニットヘッダにおいてシグナリングされるが、ピクチャのすべてのタイルグループに対して同じであることが必要とされ得る。しかしながら、この場合、MCTS/サブピクチャシーケンスのサブビットストリーム抽出の間に、値が変更される必要があり得る。代替的に、この指示は、あるピクチャのために使用されるときに、そのピクチャのすべてのVCL NALユニットが同じNALユニットタイプ値を有するべきであるものとして、そのような追加のVCL NALユニットタイプを定義することによってシグナリングされ得る。しかしながら、この場合、VCL NALユニットのNALユニットタイプ値は、MCTS/サブピクチャシーケンスのサブビットストリーム抽出の間に変更される必要があり得る。代替的に、この指示は、あるピクチャのために使用されるときに、そのピクチャのすべてのVCL NALユニットが同じNALユニットタイプ値を有するべきであるものとして、そのような追加のIRAP VCL NALユニットタイプを定義することによってシグナリングされ得る。しかしながら、この場合、VCL NALユニットのNALユニットタイプ値は、MCTS/サブピクチャシーケンスのサブビットストリーム抽出の間に変更される必要があり得る。代替的に、IRAP NALユニットタイプのいずれかを伴う少なくとも1つのVCL NALユニットを有する各ピクチャは、混合NALユニットタイプ値をピクチャが含むかどうかの指示と関連付けられ得る。
さらに、混合したIRAP NALユニットタイプおよび非IRAP NALユニットタイプを許容することだけによって、ピクチャ内のnal_unit_type値の混合が限定的に許容されるように、制約が適用され得る。任意の特定のピクチャに対して、すべてのVCL NALユニットが同じNALユニットタイプを有するか、または一部のVCL NALユニットが特定のIRAP NALユニットタイプを有するかのいずれかであり、残りは特定の非IRAP VCL NALユニットタイプを有する。言い換えると、いずれの特定のピクチャのVCL NALユニットも、1つより多くのIRAP NALユニットタイプを有することができず、1つより多くの非IRAP NALユニットタイプを有することができない。ピクチャが混合nal_unit_type値を含まず、VCL NALユニットがIRAP NALユニットタイプを有する場合にのみ、ピクチャはIRAPピクチャであると見なされ得る。IRAPピクチャに属しない任意のIRAP NALユニット(IDRを含む)に対して、POC MSBはリセットされなくてもよい。IRAPピクチャに属しない任意のIRAP NALユニット(IDRを含む)に対して、DPBはリセットされないので、参照のために使用されないものとしてすべての参照ピクチャをマークすることは実行されない。TemporalIdは、ピクチャの少なくとも1つのVCL NALユニットがIRAP NALユニットである場合、ピクチャのために0に等しく設定され得る。
以下は、上で説明された態様のうちの1つまたは複数の特定の実装形態である。IRAPピクチャは、mixed_nalu_types_in_pic_flagの値が0に等しく各VCL NALユニットが両端を含めてIDR_W_RADLからRSV_IRAP_VCL13の範囲にあるnal_unit_typeを有する、コーディングされたピクチャとして定義され得る。例示的なPPSシンタックスおよびセマンティクスは次の通りである。
mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャが複数のVCL NALユニットを有することと、これらのNALユニットがnal_unit_typeの同じ値を有しないこととを指定するために、0に等しく設定される。mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャのVCL NALユニットがnal_unit_typeの同じ値を有することを指定するために、0に等しく設定される。
例示的なタイルグループ/スライスヘッダシンタックスは次の通りである。
例示的なNALユニットヘッダのセマンティクスは次の通りである。任意の特定のピクチャのVCL NALユニットに対して、次の2つの条件のいずれかが満たされるべきである。すべてのVCL NALユニットがnal_unit_typeの同じ値を有する。VCL NALユニットの一部が特定のIRAP NALユニットタイプ値(すなわち、両端を含めてIDR_W_RADLからRSV_IRAP_VCL13の範囲にあるnal_unit_typeの値)を有し、一方ですべての他のVCL NALユニットが特定の非IRAP VCL NALユニットタイプ(すなわち、両端を含めてTRAIL_NUTからRSV_VCL_7の範囲にある、または両端を含めてRSV_VCL14からRSV_VCL15の範囲にあるnal_unit_typeの値)を有する。nuh_temporal_id_plus1から1を引いたものは、NALユニットの時間識別子を指定する。nuh_temporal_id_plus1の値は0に等しくないものとする。
変数TemporalIdは次のように導出される。
TemporalId=nuh_temporal_id_plus1-1 (7-1)
nal_unit_typeが両端を含めてIDR_W_RADLからRSV_IRAP_VCL13の範囲にあるとき、ピクチャのVCL NALユニットに対して、ピクチャの他のVCL NALユニットのnal_unit_type値とは無関係に、TemporalIdはピクチャのすべてのVCL NALユニットに対して0に等しいものとする。TemporalIdの値は、アクセスユニットのすべてのVCL NALユニットに対して同じであるものとする。コーディングされたピクチャまたはアクセスユニットのTemporalIdの値は、コーディングされたピクチャまたはアクセスユニットのVCL NALユニットのTemporalIdの値である。
コーディングされたピクチャのための例示的な復号プロセスは次の通りである。復号プロセスは、現在のピクチャCurrPicについて次のように動作する。ここではNALユニットの復号が指定される。以下の復号プロセスは、タイルグループヘッダレイヤおよびその上におけるシンタックス要素を使用する。ピクチャ順序カウントに関する変数および関数が本明細書において規定されるように導出される。これは、ピクチャの最初のタイルグループ/スライスだけに対して呼び出される。各タイルグループ/スライスのための復号プロセスの最初において、参照ピクチャリスト構築のための復号プロセスが、参照ピクチャリスト0(RefPicList[0])および参照ピクチャリスト1(RefPicList[1])の導出のために呼び出される。現在のピクチャがIDRピクチャである場合、参照ピクチャリスト構築のための復号プロセスが、ビットストリーム適合確認の目的で呼び出され得るが、現在のピクチャまたは復号順序において現在のピクチャの後にあるピクチャの復号には必要ではないことがある。
参照ピクチャリスト構築のための復号プロセスは次の通りである。このプロセスは、各タイルグループのための復号プロセスの最初に呼び出される。参照ピクチャは参照インデックスを通じてアドレス指定される。参照インデックスは参照ピクチャリストへのインデックスである。Iタイルグループを復号するとき、タイルグループデータの復号において参照ピクチャリストは使用されない。Pタイルグループを復号するとき、タイルグループデータの復号において、参照ピクチャリスト0(RefPicList[0])のみが使用される。Bタイルグループを復号するとき、参照ピクチャリスト0と参照ピクチャリスト1(RefPicList[1])の両方が、タイルグループデータの復号において使用される。各タイルグループのための復号プロセスの最初において、参照ピクチャリストRefPicList[0]およびRefPicList[1]が導出される。参照ピクチャリストは、参照ピクチャのマーキングにおいて、またはタイルグループデータの復号において使用される。IDRピクチャの任意のタイルグループまたは非IDRピクチャのIタイルグループに対して、RefPicList[0]およびRefPicList[1]は、ビットストリーム適合確認の目的で導出され得るが、それらの導出は、現在のピクチャまたは復号順序において現在のピクチャの後にあるピクチャの復号に必要ではない。Pタイルグループに対して、RefPicList[1]は、ビットストリーム適合確認の目的で導出され得るが、現在のピクチャまたは復号順序において現在のピクチャの後にあるピクチャの復号のために導出は必要ではない。
図8は、例示的なビデオコーディングデバイス800の概略図である。ビデオコーディングデバイス800は、本明細書で説明されるような開示される例/実施形態を実装するのに適している。ビデオコーディングデバイス800は、ネットワークを介してデータアップストリームおよび/またはダウンストリームを通信するための送信機および/または受信機を含む、ダウンストリームポート820、アップストリームポート850、および/またはトランシーバユニット(Tx/Rx)810を備える。ビデオコーディングデバイス800はまた、データを処理するための論理ユニットおよび/または中央処理装置(CPU)を含むプロセッサ830と、データを記憶するためのメモリ832とを含む。ビデオコーディングデバイス800はまた、電気コンポーネント、光-電気(OE)コンポーネント、電気-光(EO)コンポーネント、ならびに/または、電気通信ネットワーク、光通信ネットワーク、もしくはワイヤレス通信ネットワークを介したデータの通信のためにアップストリームポート850および/もしくはダウンストリームポート820に結合されるワイヤレス通信コンポーネントを備え得る。ビデオコーディングデバイス800はまた、ユーザとの間でデータを通信するための入力および/または出力(I/O)デバイス860を含み得る。I/Oデバイス860は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカーなどの出力デバイスを含み得る。I/Oデバイス860はまた、キーボード、マウス、トラックボールなどの入力デバイス、および/または、そのような出力デバイスと対話するための対応するインターフェースを含み得る。
プロセッサ830はハードウェアおよびソフトウェアによって実装される。プロセッサ830は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタルシグナルプロセッサ(DSP)として実装され得る。プロセッサ830は、ダウンストリームポート820、Tx/Rx810、アップストリームポート850、およびメモリ832と通信している。プロセッサ830はコーディングモジュール814を備える。コーディングモジュール814は、方法100、900、および1000などの本明細書において説明される開示された実施形態を実施し、これらは、CVS500、VRピクチャビデオストリーム600、および/またはビットストリーム700を利用し得る。コーディングモジュール814は、本明細書において説明される任意の他の方法/機構も実装し得る。さらに、コーディングモジュール814は、コーデックシステム200、エンコーダ300、および/またはデコーダ400を実装し得る。たとえば、コーディングモジュール814は、IRAP NALユニットと非IRAP NALユニットの両方をピクチャが含むときを示すために、および、単一のタイプのIRAP NALユニットと単一のタイプの非IRAP NALユニットのみを含むようにそのようなピクチャを制約するために、PPSの中のフラグを設定することができる。したがって、コーディングモジュール814は、ビデオデータをコーディングするとき、追加の機能および/またはコーディング効率をビデオコーディングデバイス800がもたらすようにする。したがって、コーディングモジュール814は、ビデオコーディングデバイス800の機能を改善し、ならびにビデオコーディングの技術に特有の問題に対処する。さらに、コーディングモジュール814は、異なる状態へのビデオコーディングデバイス800の変換を実施する。代替的に、コーディングモジュール814は、メモリ832に記憶されプロセッサ830によって実行される命令として(たとえば、非一時的媒体に記憶されるコンピュータプログラム製品として)実装され得る。
メモリ832は、ディスク、テープドライブ、ソリッドステートドライブ、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、フラッシュメモリ、三値連想メモリ(TCAM)、スタティックランダムアクセスメモリ(SRAM)などの、1つまたは複数のメモリタイプを備える。メモリ832は、実行のためにプログラムが選択されるときにそのようなプログラムを記憶するために、およびプログラム実行の間に読み取られる命令とデータを記憶するために、オーバーフローデータストレージデバイスとして使用され得る。
図9は、複数のビデオ解像度における複数のサブピクチャビデオストリーム601~603から統合されたVRピクチャビデオストリーム600を含むビットストリーム700などのビットストリームへと、混合NALユニットタイプを伴うピクチャを含むCVS500などのビデオシーケンスを符号化する、例示的な方法900のフローチャートである。方法900は、方法100を実行するとき、コーデックシステム200、エンコーダ300、および/またはビデオコーディングデバイス800などのエンコーダによって利用され得る。
方法900は、エンコーダが、VRピクチャなどの複数のピクチャを含むビデオシーケンスを受信し、たとえばユーザ入力に基づいてそのビデオシーケンスをビットストリームへと符号化すると決定するときに開始し得る。ステップ901において、エンコーダは、ビデオシーケンスのピクチャが異なるタイプの複数のサブピクチャを含むと決定する。
ステップ903において、エンコーダが、ピクチャのサブピクチャをビットストリームの中の複数のVCL NALユニットへと符号化する。
ステップ905において、エンコーダがPPSをビットストリームへと符号化する。エンコーダはまた、フラグをPPSへと、したがってビットストリームへと符号化する。このフラグは、ピクチャのサブピクチャのうちの1つまたは複数のVCL NALユニットがすべてNALユニットタイプの第1の特定の値を有することと、ピクチャの中の他のVCL NALユニットがすべてNALユニットタイプの異なる第2の特定の値を有することとを示すように設定される。たとえば、NALユニットタイプの第1の特定の値は、ピクチャが単一のタイプのIRAPサブピクチャを含むことを示し得る。ある特定の例として、NALユニットタイプの第1の特定の値は、IDR_W_RADL、IDR_N_LP、またはCRA_NUTのうちの1つに等しくてもよい。したがって、ピクチャは、任意の数のIRAPサブピクチャを有し得るが、IRAPサブピクチャのすべてが同じタイプ(たとえば、IDR_W_RADL、IDR_N_LP、またはCRA_NUTのうちの1つだけ)でなければならない。さらに、NALユニットタイプの第2の特定の値は、ピクチャが単一のタイプの非IRAPサブピクチャを含むことを示し得る。ある特定の例として、NALユニットタイプの第2の特定の値は、TRAIL_NUT、RADL_NUT、またはRASL_NUTに等しくてもよい。したがって、ピクチャは、任意の数の非IRAPサブピクチャを有し得るが、非IRAPサブピクチャのすべてが同じタイプ(たとえば、TRAIL_NUT、RADL_NUT、またはRASL_NUTのうちの1つだけ)でなければならない。
ステップ907において、エンコーダが、デコーダへの通信のためのフラグを含むビットストリームを記憶する。いくつかの例では、フラグはmixed_nalu_types_in_pic_flagである。ある特定の例では、mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャが1つより多くのVCL NALユニットを有することと、VCL NALユニットがNALユニットタイプ(nal_unit_type)の同じ値を有しないこととを指定するとき、1に等しく設定され得る。さらに、mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャが1または複数のVCL NALユニットを有し、PPSを参照する各ピクチャのVCL NALユニットがnal_unit_typeの同じ値を有するとき、0に等しく設定され得る。
図10は、複数のビデオ解像度の複数のサブピクチャビデオストリーム601~603から統合されたVRピクチャビデオストリーム600を含むビットストリーム700などのビットストリームから、混合NALユニットタイプのピクチャを含むCVS500などのビデオシーケンスを復号する例示的な方法1000のフローチャートである。方法1000は、方法100を実行するとき、コーデックシステム200、デコーダ400、および/またはビデオコーディングデバイス800などのデコーダによって利用され得る。
方法1000は、たとえば方法900の結果として、ビデオシーケンスを表現するコーディングされたデータのビットストリームの受信をデコーダが開始すると、開始し得る。ステップ1001において、デコーダがビットストリームを受信する。ビットストリームは、ピクチャと関連付けられるフラグおよび複数のサブピクチャを備える。サブピクチャはスライスへと区分され、スライスはVCL NALユニットに含まれる。したがって、複数のサブピクチャの各々も、複数のVCL NALユニットに含まれる。ビットストリームはPPSも含み得る。いくつかの例では、PPSはフラグを含む。ある特定の例として、フラグはmixed_nalu_types_in_pic_flagであり得る。さらに、mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャが1つより多くのVCL NALユニットを有することと、VCL NALユニットがnal_unit_typeの同じ値を有しないこととを指定するとき、1に等しく設定され得る。加えて、mixed_nalu_types_in_pic_flagは、PPSを参照する各ピクチャが1つまたは複数のVCL NALユニットを有し、PPSを参照する各ピクチャのVCL NALユニットがnal_unit_typeの同じ値を有するとき、0に等しく設定され得る。
ステップ1003において、デコーダが、フラグの値に基づいて、ピクチャのサブピクチャのうちの1つまたは複数のVCL NALユニットがすべてNALユニットタイプの第1の特定の値を有することと、ピクチャの中の他の(たとえば、残りの)VCL NALユニットがすべてNALユニットタイプの異なる第2の特定の値を有することとを決定する。たとえば、NALユニットタイプの第1の特定の値は、ピクチャが単一のタイプのIRAPサブピクチャを含むことを示し得る。ある特定の例として、NALユニットタイプの第1の特定の値は、IDR_W_RADL、IDR_N_LP、またはCRA_NUTのうちの1つに等しくてもよい。したがって、ピクチャは、任意の数のIRAPサブピクチャを有し得るが、IRAPサブピクチャのすべてが同じタイプ(たとえば、IDR_W_RADL、IDR_N_LP、またはCRA_NUTのうちの1つだけ)でなければならない。さらに、NALユニットタイプの第2の特定の値は、ピクチャが単一のタイプの非IRAPサブピクチャを含むことを示し得る。ある特定の例として、NALユニットタイプの第2の特定の値は、TRAIL_NUT、RADL_NUT、またはRASL_NUTに等しくてもよい。したがって、ピクチャは、任意の数の非IRAPサブピクチャを有し得るが、非IRAPサブピクチャのすべてが同じタイプ(たとえば、TRAIL_NUT、RADL_NUT、またはRASL_NUTのうちの1つだけ)でなければならない。
ステップ1005において、デコーダが、NALユニットタイプの第1の特定の値およびNALユニットタイプの第2の特定の値に基づいて、サブピクチャのうちの1つまたは複数を復号する。
ステップ1007において、サブピクチャのうちの1つまたは複数が、復号されたビデオシーケンスの一部としての表示のために転送される。
図11は、複数のビデオ解像度の複数のサブピクチャビデオストリーム601~603から統合されたVRピクチャビデオストリーム600を含むビットストリーム700などのビットストリームへと、混合NALユニットタイプのピクチャを含むCVS500などのビデオシーケンスをコーディングするための例示的なシステム1100の概略図である。システム1100は、コーデックシステム200、エンコーダ300、デコーダ400、および/またはビデオコーディングデバイス800などのエンコーダとデコーダによって実装され得る。さらに、システム1100は、方法100、900、および/または1000を実施するときに利用され得る。
システム1100はビデオエンコーダ1102を含む。ビデオエンコーダ1102は、ピクチャが異なるタイプの複数のサブピクチャを含むと決定するための決定モジュール1101を備える。ビデオエンコーダ1102はさらに、ピクチャのサブピクチャをビットストリームの中の複数のVCL NALユニットへと符号化するための符号化モジュール1103を備える。符号化モジュール1103はさらに、ピクチャのサブピクチャのうちの1つまたは複数のVCL NALユニットがすべてNALユニットタイプの第1の特定の値を有することと、ピクチャの中の他のVCL NALユニットがすべてNALユニットタイプの異なる第2の特定の値を有することとを示すように設定されたフラグを、ビットストリームへと符号化するためのものである。ビデオエンコーダ1102はさらに、デコーダへの通信のためにビットストリームを記憶するための記憶モジュール1105を備える。ビデオエンコーダ1102はさらに、ビットストリームをビデオデコーダ1110に送信するための送信モジュール1107を備える。ビデオエンコーダ1102はさらに、方法900のステップのいずれをも実行するように構成され得る。
システム1100はビデオデコーダ1110も含む。ビデオデコーダ1110は、ピクチャと関連付けられるフラグおよび複数のサブピクチャを備えるビットストリームを受信するための受信モジュール1111を備え、複数のサブピクチャは複数のVCL NALユニットに含まれる。ビデオデコーダ1110はさらに、フラグの値に基づいて、ピクチャのサブピクチャのうちの1つまたは複数のVCL NALユニットがすべてNALユニットタイプの第1の特定の値を有することと、ピクチャの中の他のVCL NALユニットがすべてNALユニットタイプの異なる第2の特定の値を有することとを決定するための、決定モジュール1113を備える。ビデオデコーダ1110はさらに、NALユニットタイプの第1の特定の値およびNALユニットタイプの第2の特定の値に基づいてサブピクチャのうちの1つまたは複数を復号するための、復号モジュール1115を備える。ビデオデコーダ1110はさらに、復号されたビデオシーケンスの一部として表示するために、サブピクチャのうちの1つまたは複数を転送するための、転送モジュール1117を備える。ビデオデコーダ1110はさらに、方法1000のステップのいずれをも実行するように構成され得る。
第1のコンポーネントと第2のコンポーネントとの間の線、配線、または別の媒体を除き、介在するコンポーネントがないとき、第1のコンポーネントは第2のコンポーネントに直接結合される。第1のコンポーネントと第2のコンポーネントとの間に線、配線、または別の媒体以外の介在するコンポーネントがあるとき、第1のコンポーネントは第2のコンポーネントに間接的に結合される。「結合される」という用語およびその変形は、直接結合されることと間接的に結合されることの両方を含む。「約」という用語の使用は、別段述べられない限り、その後にある数字の±10%を含む範囲を意味する。
本明細書に記載される例示的な方法のステップは、必ずしも説明された順序で実行されることは必要とされず、そのような方法のステップの順序は単に例示的であると理解されるべきであることも理解されたい。同様に、追加のステップがそのような方法に含まれてもよく、本開示の様々な実施形態に適合する方法で、いくつかのステップが省略または結合されてもよい。
いくつかの実施形態が本開示において提供されたが、開示されたシステムおよび方法は、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形式で具現化され得ることが理解され得る。本実施例は、限定するためのものではなく説明のためのものであると見なされるべきであり、意図は本明細書で与えられる詳細に限定されないものとする。たとえば、別のシステムでは様々な要素またはコンポーネントが結合もしくは統合されてもよく、またはいくつかの特徴が省略され、もしくは実装されなくてもよい。
加えて、様々な実施形態において個別のもの、または別々のものとして説明され図示される技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、コンポーネント、技法、もしくは方法と合成または統合されてもよい。変化、置換、および変更の他の例が当業者により確認可能であり、本明細書で開示される趣旨および範囲から逸脱することなく行われ得る。