全般に、本開示は、シングルレイヤコーディングに、さらには、HEVC(High Efficiency Vide Coding)のような高度なビデオコーデックの状況におけるスケーラブルビデオコーディングのためのレイヤ間予測に関する。より具体的には、本開示は、SHVCと呼ばれることがある、HEVCのスケーラブルビデオコーディング拡張におけるレイヤ間予測の性能の改善のためのシステムおよび方法に関する。
以下の説明では、いくつかの実施形態に関するH.264/Advanced Video Coding(AVC)技法が説明され、HEVC規格および関連する技法も説明される。いくつかの実施形態が、本明細書でHEVC規格および/またはH.264規格の文脈において説明されるが、当業者は、本明細書で開示されるシステムおよび方法が、任意の適切なビデオコーディング規格に適用可能であり得ることを了解し得る。たとえば、本明細書で開示される実施形態は、以下の規格、すなわち、国際電気通信連合(ITU) Telecommunication Standardization Sector(ITU-T) H.261、国際標準化機構(ISO)および国際電気標準会議(IEC)(ISO/IEC) Moving Picture Experts Group(MPEG)1 (MPEG-1) Visual、ITU-T H.262、またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびそのスケーラブルビデオコーディング(SVC)拡張とマルチビュービデオコーディング(MVC)拡張とを含む、(ISO/IEC MPEG-4 AVCとしても知られる)ITU-T H.264の1つまたは複数に適用可能であり得る。
HEVCは全般に、多くの点で、前のビデオコーディング規格のフレームワークに従う。HEVCにおける予測のユニットは、いくつかの前のビデオコーディング規格における予測のユニット(たとえば、マクロブロック)とは異なる。実際、いくつかの前のビデオコーディング規格において理解されているようなマクロブロックの概念は、HEVCに存在しない。マクロブロックは、4分木方式に基づく階層構造と置き換えられ、このことは、あり得る利点の中でもとりわけ、高い柔軟性を実現し得る。たとえば、HEVC方式では、コーディングユニット(CU)、予測ユニット(PU)、および変換ユニット(TU)という3つのタイプのブロックが定義される。CUは、領域分割の基本単位を指し得る。CUはマクロブロックの概念に類似すると見なされることがあるが、HEVCは、CUの最大サイズを制限せず、コンテンツ適応性を改善するために4つの等しいサイズのCUへの再帰的分割を許容し得る。PUはインター/イントラ予測の基本単位と見なされることがあり、単一のPUは、不規則な画像パターンを効果的にコーディングするために、複数の任意の形状区分を含むことがある。TUは、変換の基本単位と見なされることがある。TUは、PUとは無関係に定義され得るが、TUのサイズは、TUが属するCUのサイズに制限され得る。3つの異なる概念へのブロック構造のこの分離により、各ユニットをユニットのそれぞれの役割に従って最適化することが可能になり、このことはコーディング効率の改善をもたらし得る。
単に説明の目的で、本明細書で開示されるいくつかの実施形態は、ビデオデータの2つのレイヤ(たとえば、ベースレイヤのなどの下位レイヤおよびエンハンスメントレイヤなどの上位レイヤ)のみを含む例とともに説明される。ビデオデータの「レイヤ」は、一般に、ビュー、フレームレート、解像度などの、少なくとも1つの共通の特性を有するピクチャのシーケンスを指し得る。たとえば、レイヤは、マルチビュービデオデータの特定のビュー(たとえば、視点)と関連付けられたビデオデータを含み得る。別の例として、レイヤは、スケーラブルビデオデータの特定のレイヤと関連付けられたビデオデータを含み得る。したがって、本開示は、ビデオデータのレイヤおよびビューに交換可能に言及することがある。すなわち、ビデオデータのビューはビデオデータのレイヤと呼ばれることがあり、ビデオデータのレイヤはビデオデータのビューと呼ばれることがある。加えて、マルチレイヤコーデック(マルチレイヤビデオコーダまたはマルチレイヤエンコーダデコーダとも呼ばれる)は、マルチビューコーデックまたはスケーラブルコーデック(たとえば、MV-HEVC、3D-HEVC、SHVC、または別のマルチレイヤコーディング技法を使用してビデオデータを符号化および/または復号するように構成されるコーデック)を一緒に指すことがある。ビデオ符号化およびビデオ復号は、一般に、両方ともビデオコーディングと呼ばれることがある。そのような例は、複数のベースレイヤおよび/またはエンハンスメントレイヤを含む構成に適用可能であり得ることを理解されたい。加えて、説明を簡単にするために、以下の開示は、いくつかの実施形態に関して「フレーム」または「ブロック」という用語を含む。しかしながら、これらの用語は限定的なものではない。たとえば、下で説明される技法は、ブロック(たとえば、CU、PU、TU、マクロブロックなど)、スライス、フレームなどの、任意の適切なビデオユニットとともに使用され得る。
ビデオコーディング規格
ビデオ画像、TV画像、静止画像、またはビデオレコーダもしくはコンピュータによって生成された画像のようなデジタル画像は、水平な線および垂直な線に並べられたピクセルまたはサンプルからなり得る。単一の画像中のピクセルの数は、一般に数万個である。各ピクセルは、一般に、ルミナンス情報とクロミナンス情報とを含む。圧縮がなければ、画像エンコーダから画像デコーダに搬送されるべき著しい量の情報により、リアルタイムの画像送信は不可能になるであろう。送信されるべき情報の量を減らすために、JPEG、MPEG、およびH.263規格のような、いくつかの異なる圧縮方法が開発された。
ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、および、そのSVCおよびMVC拡張を含む(ISO/IEC MPEG-4 AVCとしても知られる)ITU-T H.264を含む。
加えて、新しいビデオコーディング規格、すなわち、High Efficiency Video Coding(HEVC)が、ITU-T Video Coding Experts Group(VCEG)およびISO/IEC Motion Picture Experts Group(MPEG)のJoint Collaboration Team on Video Coding(JCT-VC)によって開発されている。HEVC Draft 10の完全な引用は、文書JCTVC-L1003、Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のJoint Collaborative Team on Video Coding(JCT-VC)、第12回会合:ジュネーブ、スイス、2013年1月14日〜2013年1月23日である。HEVCのマルチビュー拡張すなわちMV-HEVC、およびSHVCという名称であるHEVCのスケーラブル拡張も、それぞれ、JCT-3V(ITU-T/ISO/IEC Joint Collaborative Team on 3D Video Coding Extension Development)およびJCT-VCによって開発されている。
概説
イントラランダムアクセスポイント(IRAP)ピクチャは、ビットストリームを復号するためのランダムアクセスポイントを与えることができる。デコーダは、IRAPピクチャに先行するピクチャを復号する必要なく、IRAPピクチャを復号することによってビットストリームを復号することを開始し得る。IRAPピクチャを復号する時点で、復号ピクチャバッファ(DPB)は、バッファ中にいくつかの復号されたピクチャを有し得る。DPB中の既存のピクチャを出力することが、デコーダの性能に影響を与える(たとえば、デコーダが出力すべきあまりに多くのピクチャがDPB中に存在する、すべてのピクチャを出力するとフレームレートが不均等になり得る、など)場合、そのような既存のピクチャを、それらを出力することなく除去する(たとえば、既存のピクチャをフラッシュする)のが望ましいことがある。
SHVCおよびMV-HEVC(たとえば、MV-HEVCのワーキングドラフト7、およびワーキングドラフト5に続くSHVCのワーキングドラフトに反映されることにもなる)のより前のバージョンの開発および/または議論では、複数のレイヤまたは複数のビューがビットストリーム中に存在するとき、フラッシング処理が各レイヤに対して呼び出される。この処理の間、ピクチャは、それぞれのレイヤに対して導出されたNoOutputOfPriorPicsFlagの値に基づいて出力され得る。変数NoOutputOfPriorPicsFlagは、IRAPピクチャを復号するとき、DPB中のピクチャが、DPBから除去されるより前に出力されるべきであるかどうかを示し得る。復号されるべきレイヤのリスト中のレイヤに属するピクチャをアクセスユニット(AU)が有しない場合、復号順序においてアクセスユニットに先行するピクチャは、それらが「参照のために使用されない」ものとして標識されているとしても、フラッシュされない。これらの残り続けるピクチャは、DPBメモリを使用することになり、後続のピクチャを復号するときにバッファのオーバーフローをもたらし得る。
これらおよび他の課題に対処するために、いくつかの態様による技法は、AUが特定のレイヤ中のピクチャを含まない可能性があるときであっても、異なるレイヤのDPB中のピクチャを適切にフラッシュするためのいくつかの方法および/または実施形態を提供することができる。たとえば、すべてのレイヤに対するDPBのフラッシングは、ベースレイヤがいくつかの条件を満たすかどうかに基づいてトリガされ得る。ベースレイヤピクチャに基づいてすべてのレイヤのフラッシングをトリガすることによって、本技法は、あるAU中の特定のレイヤがピクチャを有しない場合であっても、そのAU中のすべてのレイヤに対するフラッシングを呼び出すことができる。
加えて、SHVCおよびMV-HEVCのより前のバージョン(たとえば、SHVCのワーキングドラフト5およびMV-HEVCのワーキングドラフト7)では、任意のHEVCビットストリームまたは任意のSHVC/MV-HEVCビットストリームが、Annex Aにおける1つまたは複数のプロファイルおよびAnnex GまたはHにおける1つまたは複数のプロファイルに準拠する。たとえば、HEVCビットストリームはAnnex Aにおけるプロファイルに準拠する。SHVC/MV-HEVCビットストリームは、Annex GまたはHにおけるプロファイルに準拠し、SHVC/MV-HEVCビットストリーム中のベースレイヤは一般に、後方互換性のためにAnnex Aにも準拠する。加えて、SHVC/MV-HEVCビットストリーム自体も、Annex Aにおけるプロファイルに準拠し得る。したがって、ビットストリームが規格においてこれらのAnnexを使用して復号されるとき、使用されるべきDPBパラメータは、曖昧であるかまたは利用不可能であるかのいずれかである。その上、VPS拡張においてシグナリングされるDPBパラメータは、0番目の出力レイヤセットに対してシグナリングも推測もされず、このレイヤセットはベースレイヤだけを備え、ベースレイヤピクチャだけが出力される。
これらおよび他の課題に対処するために、いくつかの態様による技法は、ベースレイヤの有効SPS中の様々な属性を、それらの様々な属性に対して許可される対応する最大値と等しく設定することができる。たとえば、SPSは、MaxLayerDecPicBuffMinus1、MaxNumReorderPics、MaxLatencyIncreasePlus1、MaxLatencyPictures、およびMaxDecPicBufferingMinus1のような、様々なDPBパラメータを含み得る。または、様々な属性の最大値は、有効SPSの様々な属性の値に等しく設定される。有効SPSの様々な属性の値を、それらの様々な属性に対して許可される最大値に等しく設定することによって、本技法は、適用されることになるDPBパラメータの曖昧さまたは利用不可能性を低減し、またはなくすことができる。
ビデオコーディングシステム
添付の図面を参照して、新規のシステム、装置、および方法の様々な態様が以下でより十分に説明される。しかしながら、本開示は、多くの異なる形態で具現化されてよく、本開示全体を通じて示される任意の特定の構造または機能に限定されるものと解釈されるべきでない。そうではなく、これらの態様は、本開示が十分なものであり、完全であるように、また本開示の範囲を当業者に十分伝えるように提供される。本明細書の教示に基づいて、本開示の範囲は、本開示の他の態様と無関係に実装されるか、または本開示の他の態様と組み合わせて実装されるかにかかわらず、本明細書で開示される新規のシステム、装置、および方法の任意の態様を包含することを、当業者は了解されたい。たとえば、本明細書に記載される任意の数の態様を使用して、装置が実装されてよく、または方法が実践されてよい。さらに、本開示の範囲は、本明細書に記載される本開示の様々な態様に加えて、またはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実践されるような装置または方法を包含するものとする。本明細書で開示される任意の態様は、特許請求の範囲の1つまたは複数の要素により具現化され得ることを理解されたい。
特定の態様が本明細書で説明されるが、これらの態様の多数の変形および置換が、本開示の範囲内にある。好ましい態様のいくつかの利益および利点が説明されるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、その一部が例として図面および好ましい態様の以下の説明において示される、異なるワイヤレス技術と、システム構成と、ネットワークと、伝送プロトコルとに幅広く適用可能であることが意図されている。詳細な説明および図面は、限定的ではなく本開示の例示にすぎず、本開示の範囲は、添付の特許請求の範囲およびその均等物によって定義される。
添付の図面は例を示している。添付の図面中の参照番号によって示される要素は、以下の説明における同様の参照番号によって示される要素に対応する。本開示では、序数語(たとえば、「第1の」、「第2の」、「第3の」など)で始まる名前を有する要素は、必ずしもそれらの要素が特定の順序を有することを暗示するとは限らない。むしろ、そのような序数語は、同じまたは同様のタイプの、異なる要素を指すために使用されるにすぎない。
図1Aは、本開示で説明される態様による技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用され説明される場合、「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化とビデオ復号とを総称的に指し得る。ビデオエンコーダおよびビデオデコーダに加えて、本出願で説明される態様は、トランスコーダ(たとえば、ビットストリームを復号し、別のビットストリームを再符号化することができるデバイス)およびミドルボックス(たとえば、ビットストリームを修正し、変換し、かつ/または別様に操作することができるデバイス)のような、他の関連するデバイスに拡張され得る。
図1Aに示されるように、ビデオコーディングシステム10は、宛先デバイス14によって後で復号されるべき符号化されたビデオデータを生成するソースデバイス12を含む。図1Aの例では、ソースデバイス12および宛先デバイス14は、別個のデバイスを構成する。しかしながら、ソースデバイス12および宛先デバイス14は、図1Bの例に示されるように、同じデバイス上にあるかまたは同じデバイスの一部であり得ることに留意されたい。
もう一度図1Aを参照すると、ソースデバイス12および宛先デバイス14は、それぞれ、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。いくつかの場合、ソースデバイス12および宛先デバイス14は、ワイヤレス通信に対応し得る。
宛先デバイス14は、復号されるべき符号化されたビデオデータを、リンク16を介して受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化されたビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。図1Aの例では、リンク16は、ソースデバイス12が符号化されたビデオデータをリアルタイムで宛先デバイス14に送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、高周波(RF)スペクトルまたは1つもしくは複数の物理伝送線路のような、任意のワイヤレスまたは有線の通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワークのようなパケットベースネットワーク、またはインターネットのようなグローバルネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を支援するのに有用であり得る任意の他の機器を含み得る。
代替的に、符号化されたデータは、出力インターフェース22から任意選択の記憶デバイス31に出力され得る。同様に、符号化されたデータは、たとえば、宛先デバイス14の入力インターフェース28によって記憶デバイス31からアクセスされ得る。記憶デバイス31は、ハードドライブ、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる例では、記憶デバイス31は、ソースデバイス12によって生成された符号化されたビデオを保持し得るファイルサーバまたは別の中間記憶デバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して記憶デバイス31から記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、(たとえば、ウェブサイトのための)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を通じて符号化されたビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、ワイヤレスローカルエリアネットワーク(WLAN)接続)、有線接続(たとえば、デジタル加入者線(DSL)、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイス31からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはその両方の組合せであり得る。
本開示の技法は、ワイヤレスの適用例または設定に限定されない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信(たとえば、ハイパーテキスト転送プロトコル(HTTP)上での動的適応ストリーミングなど)、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例のような、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、ビデオコーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話のような用途をサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。
図1Aの例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。いくつかの場合、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえばビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、あるいはそのようなソースの組合せを含み得る。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、図1Bの例に示されているように、いわゆる「カメラ電話」または「ビデオ電話」を形成し得る。しかしながら、本開示で説明される技法は、ビデオコーディング全般に適用可能であってよく、ワイヤレスおよび/または有線の適用例に適用され得る。
キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータにより生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化されたビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に送信され得る。符号化されたビデオデータはさらに(または代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのために記憶デバイス31に記憶され得る。図1Aおよび図1Bに示されるビデオエンコーダ20は、図2Aに示されるビデオエンコーダ20、図2Bに示されるビデオエンコーダ23、または本明細書で説明される任意の他のビデオエンコーダを備え得る。
図1Aの例では、宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。いくつかの場合、入力インターフェース28は、受信機および/またはモデムを含み得る。宛先デバイス14の入力インターフェース28は、リンク16を通じて、および/または記憶デバイス31から、符号化されたビデオデータを受信し得る。リンク16を通じて通信され、または記憶デバイス31上に与えられた、符号化されたビデオデータは、ビデオデータを復号する際に、ビデオデコーダ30のようなビデオデコーダが使用するためのビデオエンコーダ20によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体に記憶されるか、またはファイルサーバに記憶される、符号化されたビデオデータとともに含まれ得る。図1Aおよび図1Bに示されるビデオデコーダ30は、図3Aに示されるビデオデコーダ30、図3Bに示されるビデオデコーダ33、または本明細書で説明される任意の他のビデオデコーダを備えてよい。
ディスプレイデバイス32は、宛先デバイス14と一体化されるか、またはその外部にあり得る。いくつかの例では、宛先デバイス14は、一体型のディスプレイデバイスを含むことがあり、外部ディスプレイデバイスとインターフェースするように構成されることもある。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのいずれかを備え得る。
関連する態様では、図1Bは例示的なビデオ符号化および復号システム10'を示し、ソースデバイス12および宛先デバイス14はデバイス11上にあるかまたはデバイス11の一部である。デバイス11は、「スマート」フォンなどのような電話ハンドセットであり得る。デバイス11は、ソースデバイス12および宛先デバイス14と動作可能に通信している任意選択のコントローラ/プロセッサデバイス13を含み得る。図1Bのシステム10'は、ビデオエンコーダ20と出力インターフェース22との間にビデオ処理ユニット21をさらに含み得る。いくつかの実装形態では、図1Bに示されているように、ビデオ処理ユニット21は別個のユニットであるが、他の実装形態では、ビデオ処理ユニット21は、ビデオエンコーダ20および/またはプロセッサ/コントローラデバイス13の一部分として実装され得る。システム10'はまた、ビデオシーケンス中の対象オブジェクトを追跡することができる任意選択のトラッカー29を含み得る。追跡されるべき対象オブジェクトは、本開示の1つまたは複数の態様に関して説明される技法によって区切られ得る。関係する態様では、追跡は、単独でまたはトラッカー29とともに、ディスプレイデバイス32によって実行され得る。図1Bのシステム10'およびそのコンポーネントは、その他の点では図1Aのシステム10およびそのコンポーネントと同様である。
ビデオエンコーダ20およびビデオデコーダ30は、HEVCのようなビデオ圧縮規格に従って動作することができ、HEVCテストモデル(HM)に準拠することができる。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、AVCと呼ばれるITU-T H.264規格のような、他のプロプライエタリ規格もしくは業界規格、またはそのような規格の拡張に従って動作し得る。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例には、MPEG-2およびITU-T H.263がある。
図1Aおよび図1Bの例には示されていないが、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアのような、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれもが、それぞれのデバイスにおいて複合エンコーダ/デコーダ(コーデック)の一部として統合されてよい。
ビデオコーディング処理
上で簡単に述べられたように、ビデオエンコーダ20はビデオデータを符号化する。ビデオデータは、1つまたは複数のピクチャを備え得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。いくつかの事例では、ピクチャはビデオ「フレーム」と呼ばれ得る。ビデオエンコーダ20がビデオデータを符号化するとき、ビデオエンコーダ20はビットストリームを生成し得る。ビットストリームは、ビデオデータのコーディングされた表現を形成するビットのシーケンスを含み得る。ビットストリームは、コーディングされたピクチャと関連データとを含み得る。コーディングされたピクチャは、ピクチャのコーディングされた表現である。
ビットストリームを生成するために、ビデオエンコーダ20は、ビデオデータ中の各ピクチャに対して符号化動作を実行し得る。ビデオエンコーダ20がピクチャに対して符号化動作を実行するとき、ビデオエンコーダ20は、一連のコーディングされたピクチャと関連データとを生成し得る。関連データは、ビデオパラメータセット(VPS)と、シーケンスパラメータセット(SPS)と、ピクチャパラメータセット(PPS)と、適応パラメータセット(APS)と、他のシンタックス構造とを含み得る。SPSは、0個以上のピクチャのシーケンスに適用可能なパラメータを含み得る。PPSは、0個以上のピクチャに適用可能なパラメータを含み得る。APSは、0個以上のピクチャに適用可能なパラメータを含み得る。APS中のパラメータは、PPS中のパラメータよりも変化する可能性が高いパラメータであり得る。
コーディングされたピクチャを生成するために、ビデオエンコーダ20は、ピクチャを等しいサイズのビデオブロックに区分し得る。ビデオブロックは、サンプルの2次元アレイであり得る。ビデオブロックの各々は、ツリーブロックと関連付けられる。いくつかの事例では、ツリーブロックは、最大コーディングユニット(LCU)と呼ばれ得る。HEVCのツリーブロックは、H.264/AVCのような、以前の規格のマクロブロックに広い意味で類似し得る。しかしながら、ツリーブロックは、特定のサイズに必ずしも限定されず、1つまたは複数のコーディングユニット(CU)を含み得る。ビデオエンコーダ20は、4分木区分を使用して、ツリーブロックのビデオブロックを、CUと関連付けられたビデオブロックに区分することができ、したがって「ツリーブロック」という名前がある。
いくつかの例では、ビデオエンコーダ20はピクチャを複数のスライスに区分し得る。スライスの各々は、整数個のCUを含み得る。いくつかの事例では、スライスは整数個のツリーブロックを備える。他の事例では、スライスの境界はツリーブロック内にあり得る。
ピクチャに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実行し得る。ビデオエンコーダ20がスライスに対して符号化動作を実行するとき、ビデオエンコーダ20は、スライスと関連付けられた符号化されたデータを生成し得る。スライスと関連付けられた符号化されたデータは「コーディングされたスライス」と呼ばれ得る。
コーディングされたスライスを生成するために、ビデオエンコーダ20は、スライス中の各ツリーブロックに対して符号化動作を実行し得る。ビデオエンコーダ20がツリーブロックに対して符号化動作を実行するとき、ビデオエンコーダ20はコーディングされたツリーブロックを生成し得る。コーディングされたツリーブロックは、ツリーブロックの符号化されたバージョンを表すデータを備え得る。
ビデオエンコーダ20がコーディングされたスライスを生成するとき、ビデオエンコーダ20は、ラスター走査順序に従って、スライス中のツリーブロックに対して符号化動作を実行し得る(たとえば、そのツリーブロックを符号化し得る)。たとえば、ビデオエンコーダ20は、スライス中のツリーブロックの一番上の行にわたって左から右に進み、次いでツリーブロックの次の下の行にわたって左から右に進み、以下同様に進む順序で、ビデオエンコーダ20がスライス中のツリーブロックの各々を符号化するまで、スライスのツリーブロックを符号化し得る。
ラスター走査順序に従ってツリーブロックを符号化した結果として、所与のツリーブロックの上および左のツリーブロックは符号化されていることがあるが、所与のツリーブロックの下および右のツリーブロックはまだ符号化されていない。したがって、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの上および左のツリーブロックを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの下および右のツリーブロックを符号化することによって生成された情報にアクセスすることが不可能であり得る。
コーディングされたツリーブロックを生成するために、ビデオエンコーダ20は、ツリーブロックのビデオブロックに対して4分木区分を再帰的に実行して、ビデオブロックを徐々により小さくなるビデオブロックに分割し得る。より小さなビデオブロックの各々は、異なるCUと関連付けられ得る。たとえば、ビデオエンコーダ20は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し、サブブロックの1つまたは複数を、4つの等しいサイズのサブサブブロックに区分することができ、以下同様である。区分されたCUは、そのビデオブロックが他のCUと関連付けられるビデオブロックに区分された、CUであり得る。区分されていないCUは、そのビデオブロックが他のCUと関連付けられたビデオブロックに区分されていない、CUであり得る。
ビットストリーム中の1つまたは複数のシンタックス要素は、ビデオエンコーダ20がツリーブロックのビデオブロックを区分し得る最大の回数を示し得る。CUのビデオブロックは、形状が正方形であり得る。CUのビデオブロックのサイズ(たとえば、CUのサイズ)は、8×8のピクセルから、最大で64×64以上のピクセルをもつツリーブロックのビデオブロックのサイズ(たとえば、ツリーブロックのサイズ)にまで及び得る。
ビデオエンコーダ20は、z走査順序に従って、ツリーブロックの各CUに対して符号化動作を実行し得る(たとえば、各CUを符号化し得る)。言い換えれば、ビデオエンコーダ20は、左上のCUと、右上のCUと、左下のCUと、次いで右下のCUとを、その順序で符号化し得る。ビデオエンコーダ20が、区分されたCUに対して符号化動作を実行するとき、ビデオエンコーダ20は、z走査順序に従って、区分されたCUのビデオブロックのサブブロックと関連付けられたCUを符号化し得る。言い換えれば、ビデオエンコーダ20は、左上のサブブロックと関連付けられたCUと、右上のサブブロックと関連付けられたCUと、左下のサブブロックと関連付けられたCUと、次いで右下のサブブロックと関連付けられたCUとを、その順序で符号化し得る。
z走査順序に従ってツリーブロックのCUを符号化した結果として、所与のCUの上、左上、右上、左、および左下のCUは符号化されていることがある。所与のCUの下および右のCUはまだ符号化されていない。したがって、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接するいくつかのCUを符号化することによって生成された情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接する他のCUを符号化することによって生成された情報にアクセスすることが不可能であり得る。
ビデオエンコーダ20が区分されていないCUを符号化するとき、ビデオエンコーダ20は、CUのために1つまたは複数の予測ユニット(PU)を生成し得る。CUのPUの各々は、CUのビデオブロック内の異なるビデオブロックと関連付けられ得る。ビデオエンコーダ20は、CUの各PUのための予測されたビデオブロックを生成し得る。PUの予測されたビデオブロックは、サンプルのブロックであり得る。ビデオエンコーダ20は、イントラ予測またはインター予測を使用して、PUのための予測されたビデオブロックを生成し得る。
ビデオエンコーダ20がイントラ予測を使用してPUの予測されたビデオブロックを生成するとき、ビデオエンコーダ20は、PUと関連付けられたピクチャの復号されたサンプルに基づいて、PUの予測されたビデオブロックを生成し得る。ビデオエンコーダ20がイントラ予測を使用してCUのPUの予測されたビデオブロックを生成する場合、CUはイントラ予測されたCUである。ビデオエンコーダ20がインター予測を使用してPUの予測されたビデオブロックを生成するとき、ビデオエンコーダ20は、PUと関連付けられたピクチャ以外の1つまたは複数のピクチャの復号されたサンプルに基づいて、PUの予測されたビデオブロックを生成し得る。ビデオエンコーダ20がインター予測を使用してCUのPUの予測されたビデオブロックを生成する場合、CUはインター予測されたCUである。
さらに、ビデオエンコーダ20がインター予測を使用してPUのための予測されたビデオブロックを生成するとき、ビデオエンコーダ20はPUの動き情報を生成し得る。PUの動き情報は、PUの1つまたは複数の参照ブロックを示し得る。PUの各参照ブロックは、参照ピクチャ内のビデオブロックであり得る。参照ピクチャは、PUと関連付けられたピクチャ以外のピクチャであり得る。いくつかの事例では、PUの参照ブロックは、PUの「参照サンプル」と呼ばれることもある。ビデオエンコーダ20は、PUの参照ブロックに基づいて、PUのための予測されたビデオブロックを生成し得る。
ビデオエンコーダ20がCUの1つまたは複数のPUのための予測されたビデオブロックを生成した後、ビデオエンコーダ20は、CUのPUのための予測されたビデオブロックに基づいて、CUの残差データを生成し得る。CUの残差データは、CUのPUのための予測されたビデオブロック中のサンプルと、CUの元のビデオブロック中のサンプルとの間の差を示し得る。
さらに、区分されていないCUに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、CUの残差データに対して再帰的な4分木区分を実行して、CUの残差データを、CUの変換ユニット(TU)と関連付けられた残差データの1つまたは複数のブロック(たとえば、残差ビデオブロック)に区分し得る。CUの各TUは、異なる残差ビデオブロックと関連付けられ得る。
ビデオエンコーダ20は、TUと関連付けられた変換係数ブロック(たとえば、変換係数のブロック)を生成するために、TUと関連付けられた残差ビデオブロックに1つまたは複数の変換を適用し得る。概念的に、変換係数ブロックは変換係数の2次元(2D)行列であり得る。
変換係数ブロックを生成した後、ビデオエンコーダ20は、変換係数ブロックに対して量子化処理を実行し得る。量子化は、一般に、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を実現する処理を指す。量子化処理は、変換係数の一部またはすべてと関連付けられるビット深度を低減することができる。たとえば、量子化中にnビットの変換係数がmビットの変換係数へと切り捨てられることがあり、ただしnはmよりも大きい。
ビデオエンコーダ20は、各CUを量子化パラメータ(QP)値と関連付け得る。CUと関連付けられたQP値は、ビデオエンコーダ20が、CUと関連付けられた変換係数ブロックをどのように量子化するかを決定し得る。ビデオエンコーダ20は、CUと関連付けられたQP値を調整することによって、CUと関連付けられた変換係数ブロックに適用される量子化の程度を調整し得る。
ビデオエンコーダ20が変換係数ブロックを量子化した後、ビデオエンコーダ20は、量子化された変換係数ブロック中で変換係数を表すシンタックス要素のセットを生成し得る。ビデオエンコーダ20は、これらのシンタックス要素のうちのいくつかに、コンテキスト適応型バイナリ算術コーディング(CABAC)動作のようなエントロピー符号化動作を適用し得る。コンテンツ適応型可変長コーディング(CALVC)、確率間隔区分エントロピー(PIPE)コーディング、または他のバイナリ算術コーディングのような、他のエントロピーコーディング技法も使用され得る。
ビデオエンコーダ20によって生成されるビットストリームは、一連のネットワーク抽象化レイヤ(NAL)ユニットを含み得る。NALユニットの各々は、NALユニット中のデータのタイプの指示と、データを含むバイトとを含む、シンタックス構造であり得る。たとえば、NALユニットは、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、コーディングされたスライス、補足エンハンスメント情報(SEI)、アクセスユニットデリミタ、フィラーデータ、または別のタイプのデータを表すデータを含み得る。NALユニット中のデータは、様々なシンタックス構造を含み得る。
ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信し得る。ビットストリームは、ビデオエンコーダ20によって符号化されたビデオデータのコーディングされた表現を含み得る。ビデオデコーダ30がビットストリームを受信するとき、ビデオデコーダ30は、ビットストリームに対して解析動作を実行し得る。ビデオデコーダ30が解析動作を実行するとき、ビデオデコーダ30は、ビットストリームからシンタックス要素を抽出し得る。ビデオデコーダ30は、ビットストリームから抽出されたシンタックス要素に基づいて、ビデオデータのピクチャを再構築し得る。シンタックス要素に基づいてビデオデータを再構築するための処理は、一般に、シンタックス要素を生成するためにビデオエンコーダ20によって実行される処理とは逆であり得る。
ビデオデコーダ30がCUと関連付けられたシンタックス要素を抽出した後、ビデオデコーダ30は、シンタックス要素に基づいて、CUのPUのための予測されたビデオブロックを生成し得る。加えて、ビデオデコーダ30は、CUのTUと関連付けられた変換係数ブロックを逆量子化し得る。ビデオデコーダ30は、変換係数ブロックに対して逆変換を実行して、CUのTUと関連付けられた残差ビデオブロックを再構築し得る。予測されたビデオブロックを生成し、残差ビデオブロックを再構築した後、ビデオデコーダ30は、予測されたビデオブロックと残差ビデオブロックとに基づいてCUのビデオブロックを再構築し得る。このようにして、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて、CUのビデオブロックを再構築し得る。
ビデオエンコーダ
図2Aは、本開示で説明される態様による技法を実装し得るビデオエンコーダ20の例を示すブロック図である。ビデオデコーダ20は、HEVCの場合のように、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオエンコーダ20は、限定はされないが、図4および図5に関して上および下でより詳細に説明されるNoOutputOfPriorPicsFlagを推測する方法および関連する処理を含む、本開示の技法のいずれかまたはすべてを実行するように構成され得る。一例として、予測処理ユニット100は、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。別の実施形態では、ビデオエンコーダ20は、本開示で説明される技法のいずれかまたはすべてを実行するように構成される任意選択のレイヤ間予測ユニット128を含む。他の実施形態では、レイヤ間予測は、予測処理ユニット100(たとえば、インター予測ユニット121および/またはイントラ予測ユニット126)によって実行されてよく、その場合、レイヤ間予測ユニット128は省略されてよい。しかしながら、本開示の態様はそのように限定されない。いくつかの例では、本開示で説明される技法は、ビデオエンコーダ20の様々なコンポーネント間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示されず)が、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。
説明の目的で、本開示は、HEVCコーディングの状況においてビデオエンコーダ20を説明する。しかしながら、本開示の技法は他のコーディング規格または方法に適用可能であり得る。図2Aに示される例は、シングルレイヤコーデックのためのものである。しかしながら、図2Bに関してさらに説明されるように、ビデオエンコーダ20の一部またはすべてが、マルチレイヤコーデックの処理のために複製され得る。
ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間冗長性を低減または除去する。インターコーディングは、時間的予測を利用して、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)のようなインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
図2Aの例では、ビデオエンコーダ20は複数の機能コンポーネントを含む。ビデオエンコーダ20の機能コンポーネントは、予測処理ユニット100と、残差生成ユニット102と、変換処理ユニット104と、量子化ユニット106と、逆量子化ユニット108と、逆変換ユニット110と、再構築ユニット112と、フィルタユニット113と、復号ピクチャバッファ114と、エントロピー符号化ユニット116とを含む。予測処理ユニット100は、インター予測ユニット121と、動き推定ユニット122と、動き補償ユニット124と、イントラ予測ユニット126と、レイヤ間予測ユニット128とを含む。他の例では、ビデオエンコーダ20は、より多数の、より少数の、または異なる機能コンポーネントを含み得る。さらに、動き推定ユニット122および動き補償ユニット124は、高度に統合され得るが、図2Aの例では、説明の目的で別々に表されている。
ビデオエンコーダ20は、ビデオデータを受信し得る。ビデオエンコーダ20は、様々なソースからビデオデータを受信し得る。たとえば、ビデオエンコーダ20は、(たとえば、図1Aまたは図1Bに示された)ビデオソース18、または別のソースからビデオデータを受信し得る。ビデオデータは、一連のピクチャを表し得る。ビデオデータを符号化するために、ビデオエンコーダ20は、ピクチャの各々に対して符号化動作を実行し得る。ピクチャに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実行し得る。スライスに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、スライス中のツリーブロックに対して符号化動作を実行し得る。
ツリーブロックに対して符号化動作を実行することの一部として、予測処理ユニット100は、ツリーブロックのビデオブロックに対して4分木区分を実行して、ビデオブロックを徐々により小さくなるビデオブロックに分割し得る。より小さなビデオブロックの各々は、異なるCUと関連付けられ得る。たとえば、予測処理ユニット100は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し、サブブロックの1つまたは複数を、4つの等しいサイズのサブサブブロックに区分することができ、以下同様である。
CUと関連付けられたビデオブロックのサイズは、8×8のサンプルから、最大で64×64以上のサンプルをもつツリーブロックのサイズにまで及び得る。本開示では、「N×N(NxN)」および「N×N(N by N)」は、垂直方向の寸法および水平方向の寸法に関するビデオブロックのサンプルの寸法、たとえば、16×16(16x16)のサンプルまたは16×16(16 by 16)のサンプルを指すために交換可能に使用され得る。一般に、16×16のビデオブロックは、垂直方向に16個のサンプルを有し(y=16)、水平方向に16個のサンプルを有する(x=16)。同様に、N×Nのブロックは、一般に、垂直方向にN個のサンプルを有し、水平方向にN個のサンプルを有し、ここで、Nは非負の整数値を表す。
さらに、ツリーブロックに対して符号化動作を実行することの一部として、予測処理ユニット100は、ツリーブロックのための階層的な4分木データ構造を生成し得る。たとえば、ツリーブロックは、4分木データ構造のルートノードに対応し得る。予測処理ユニット100がツリーブロックのビデオブロックを4つのサブブロックに区分する場合、ルートノードは、4分木データ構造中に4つの子ノードを有する。子ノードの各々は、サブブロックの1つと関連付けられたCUに対応する。予測処理ユニット100がサブブロックの1つを4つのサブサブブロックに区分する場合、サブブロックと関連付けられたCUに対応するノードは、サブサブブロックの1つと関連付けられたCUに各々が対応する、4つの子ノードを有し得る。
4分木データ構造の各ノードは、対応するツリーブロックまたはCUのシンタックスデータ(たとえば、シンタックス要素)を含み得る。たとえば、4分木の中のノードは、そのノードに対応するCUのビデオブロックが4つのサブブロックに区分(たとえば、分割)されているかどうかを示す分割フラグを含み得る。CUのためのシンタックス要素は、再帰的に定義されてよく、CUのビデオブロックがサブブロックに分割されているかどうかに依存し得る。ビデオブロックが区分されていないCUは、4分木データ構造におけるリーフノードに対応し得る。コーディングされたツリーブロックは、対応するツリーブロックのための4分木データ構造に基づくデータを含み得る。
ビデオエンコーダ20は、ツリーブロックの区分されていない各々のCUに対して符号化動作を実行し得る。ビデオエンコーダ20が、区分されていないCUに対して符号化動作を実行するとき、ビデオエンコーダ20は、区分されていないCUの符号化された表現を表すデータを生成する。
CUに対して符号化動作を実行することの一部として、予測処理ユニット100は、CUの1つまたは複数のPUの中で、CUのビデオブロックを区分し得る。ビデオエンコーダ20およびビデオデコーダ30は、様々なPUサイズをサポートし得る。特定のCUのサイズが2N×2Nであると仮定すると、ビデオエンコーダ20およびビデオデコーダ30は、2N×2NまたはN×NというPUサイズと、2N×2N、2N×N、N×2N、N×N、2N×nU、nL×2N、nR×2N、または同様の対称なPUサイズでのインター予測とをサポートし得る。ビデオエンコーダ20およびビデオデコーダ30は、2N×nU、2N×nD、nL×2N、およびnR×2NというPUサイズに対する非対称区分もサポートし得る。いくつかの例では、予測処理ユニット100は、CUのビデオブロックの辺と直角に交わらない境界に沿ってCUのPUの間でCUのビデオブロックを区分するように、幾何学的な区分を実行し得る。
インター予測ユニット121は、CUの各PUに対してインター予測を実行し得る。インター予測は、時間圧縮を実現し得る。PUに対してインター予測を実行するために、動き推定ユニット122は、PUのための動き情報を生成し得る。動き補償ユニット124は、PUベースの動き情報およびCUと関連付けられたピクチャ以外のピクチャ(たとえば、参照ピクチャ)の復号されたサンプルのための、予測されたビデオブロックを生成し得る。本開示では、動き補償ユニット124によって生成される予測されたビデオブロックは、インター予測されたビデオブロックと呼ばれることがある。
スライスは、Iスライス、Pスライス、またはBスライスであり得る。動き推定ユニット122および動き補償ユニット124は、PUがIスライス中にあるか、Pスライス中にあるか、またはBスライス中にあるかに応じて、CUのPUのために異なる動作を実行し得る。Iスライス中では、すべてのPUがイントラ予測される。したがって、PUがIスライス中にある場合、動き推定ユニット122および動き補償ユニット124は、PUに対してインター予測を実行しない。
PUがPスライス中にある場合、PUを含むピクチャは、「リスト0」と呼ばれる参照ピクチャのリストと関連付けられる。リスト0中の参照ピクチャの各々は、他のピクチャのインター予測に使用され得るサンプルを含む。動き推定ユニット122が、Pスライス中のPUに関して動き推定動作を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索し得る。PUの参照ブロックは、PUのビデオブロック中のサンプルに最も密接に対応するサンプルのセット、たとえば、サンプルのブロックであり得る。動き推定ユニット122は、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定するために、様々な尺度を使用し得る。たとえば、動き推定ユニット122は、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分尺度によって、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定し得る。
Pスライス中のPUの参照ブロックを識別した後、動き推定ユニット122は、参照ブロックを含むリスト0中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。様々な例において、動き推定ユニット122は、動きベクトルを変化する精度で生成し得る。たとえば、動き推定ユニット122は、1/4サンプル精度、1/8サンプル精度、または他の分数のサンプル精度で動きベクトルを生成し得る。分数のサンプル精度の場合、参照ブロック値は、参照ピクチャ中の整数位置のサンプル値から補間され得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって識別された参照ブロックに基づいて、PUの予測されるビデオブロックを生成し得る。
PUがBスライス中にある場合、PUを含むピクチャは、「リスト0」および「リスト1」と呼ばれる参照ピクチャの2つのリストと関連付けられ得る。いくつかの例では、Bスライスを含むピクチャは、リスト0およびリスト1の組合せである、リストの組合せと関連付けられ得る。
さらに、PUがBスライス中にある場合、動き推定ユニット122は、PUのための単方向予測または双方向予測を実行し得る。動き推定ユニット122がPUのための単方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0またはリスト1の参照ピクチャを探索し得る。動き推定ユニット122は次いで、参照ブロックを含む、リスト0またはリスト1中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと、予測方向インジケータと、動きベクトルとを出力し得る。予測方向インジケータは、参照インデックスがリスト0中の参照ピクチャを示すのかまたはリスト1中の参照ピクチャを示すのかを示し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測されたビデオブロックを生成し得る。
動き推定ユニット122がPUのための双方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索することができ、また、PUのための別の参照ブロックについて、リスト1中の参照ピクチャを探索することができる。動き推定ユニット122は次いで、参照ブロックを含む、リスト0およびリスト1中の参照ピクチャを示す参照インデックスと、参照ブロックとPUとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、PUの参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測されるビデオブロックを生成し得る。
いくつかの事例では、動き推定ユニット122は、PUのための動き情報の完全なセットをエントロピー符号化ユニット116に出力しない。そうではなく、動き推定ユニット122は、別のPUの動き情報を参照して、PUの動き情報をシグナリングし得る。たとえば、動き推定ユニット122は、PUの動き情報が、隣接PUの動き情報と十分に類似していると決定し得る。この例では、動き推定ユニット122は、PUと関連付けられたシンタックス構造において、PUが隣接PUと同じ動き情報を有することをビデオデコーダ30に示す値を示し得る。別の例では、動き推定ユニット122は、PUと関連付けられたシンタックス構造において、隣接PUと動きベクトル差分(MVD)とを識別し得る。動きベクトル差分は、PUの動きベクトルと、示される隣接PUの動きベクトルとの差分を示す。ビデオデコーダ30は、示される隣接PUの動きベクトルと、動きベクトルの差分とを使用して、PUの動きベクトルを決定し得る。第2のPUの動き情報をシグナリングするときに第1のPUの動き情報を参照することによって、ビデオエンコーダ20は、より少数のビットを使用して、第2のPUの動き情報をシグナリングすることが可能であり得る。
図5に関して以下でさらに論じられるように、予測処理ユニット100は、図5に示される方法を実行することによってPU(または他の参照レイヤブロックおよび/またはエンハンスメントレイヤブロックまたはビデオユニット)をコーディング(たとえば、符号化または復号)するように構成され得る。たとえば、(たとえば、動き推定ユニット122および/または動き補償ユニット124を介した)インター予測ユニット121、イントラ予測ユニット126、またはレイヤ間予測ユニット128は、一緒にまたは別々に、図5に示される方法を実行するように構成され得る。
CUに対して符号化動作を実行することの一部として、イントラ予測ユニット126は、CUのPUに対してイントラ予測を実行し得る。イントラ予測は、空間圧縮を実現し得る。イントラ予測ユニット126がPUに対してイントラ予測を実行するとき、イントラ予測ユニット126は、同じピクチャ中の他のPUの復号されたサンプルに基づいて、PUのための予測データを生成し得る。PUのための予測データは、予測されるビデオブロックと様々なシンタックス要素とを含み得る。イントラ予測ユニット126は、Iスライス、Pスライス、およびBスライス中のPUに対してイントラ予測を実行し得る。
PUに対してイントラ予測を実行するために、イントラ予測ユニット126は、PUのための予測データの複数のセットを生成するために、複数のイントラ予測モードを使用し得る。イントラ予測ユニット126がイントラ予測モードを使用してPUのための予測データのセットを生成するとき、イントラ予測ユニット126は、イントラ予測モードと関連付けられる方向および/または勾配で、隣接PUのビデオブロックからPUのビデオブロックにわたってサンプルを延ばし得る。PU、CU、およびツリーブロックについて左から右、上から下の符号化順序を仮定すると、隣接PUは、PUの上、右上、左上、または左にあり得る。イントラ予測ユニット126は、PUのサイズに応じて、様々な数のイントラ予測モード、たとえば、33個の方向性イントラ予測モードを使用し得る。
予測処理ユニット100は、PUについて動き補償ユニット124によって生成された予測データ、またはPUについてイントラ予測ユニット126によって生成された予測データの中から、PUのための予測データを選択し得る。いくつかの例では、予測処理ユニット100は、予測データのセットのレート/ひずみの尺度に基づいて、PUのための予測データを選択する。
予測処理ユニット100が、イントラ予測ユニット126によって生成された予測データを選択する場合、予測処理ユニット100は、PUの予測データを生成するために使用されたイントラ予測モード、たとえば、選択されたイントラ予測モードをシグナリングし得る。予測処理ユニット100は、選択されたイントラ予測モードを様々な方法でシグナリングし得る。たとえば、選択されたイントラ予測モードは、隣接PUのイントラ予測モードと同じである可能性があり得る。言い換えれば、隣接PUのイントラ予測モードは、現在のPUに対して最も可能性のあるモードであり得る。したがって、予測処理ユニット100は、選択されたイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示すための、シンタックス要素を生成し得る。
上で説明されたように、ビデオエンコーダ20は、レイヤ間予測ユニット128を含み得る。レイヤ間予測ユニット128は、スケーラブルビデオコーディングにおいて利用可能である1つまたは複数の異なるレイヤ(たとえば、ベースレイヤまたは参照レイヤ)を使用して、現在のブロック(たとえば、EL中の現在のブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット128は、レイヤ間の冗長性を低減するための予測方法を利用し、それによって、コーディング効率を改善し、計算リソースの要件を下げる。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するために、ベースレイヤの中で併置されているブロックの再構築を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動作を予測するために、ベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するために、ベースレイヤの残差を使用する。レイヤ間予測方式の各々が、以下でより詳細に説明される。
予測処理ユニット100がCUのPUのための予測データを選択した後、残差生成ユニット102は、CUのビデオブロックからCUのPUの予測されたビデオブロックを差し引くこと(たとえば、マイナス符号によって示される)によって、CUの残差データを生成し得る。CUの残差データは、CUのビデオブロック中のサンプルの異なるサンプル成分に対応する、2D残差ビデオブロックを含み得る。たとえば、残差データは、CUのPUの予測されるビデオブロック中のサンプルのルミナンス成分と、CUの元のビデオブロック中のサンプルのルミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。加えて、CUの残差データは、CUのPUの予測されるビデオブロック中のサンプルのクロミナンス成分と、CUの元のビデオブロック中のサンプルのクロミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。
予測処理ユニット100は、4分木区分を実行して、CUの残差ビデオブロックをサブブロックに区分し得る。分割されていない各残差ビデオブロックは、CUの異なるTUと関連付けられ得る。CUのTUと関連付けられる残差ビデオブロックのサイズおよび位置は、CUのPUと関連付けられたビデオブロックのサイズおよび位置に基づいてよく、または基づかなくてよい。「残差4分木」(RQT)と呼ばれる4分木構造は、残差ビデオブロックの各々と関連付けられたノードを含み得る。CUのTUは、RQTのリーフノードに対応し得る。
変換処理ユニット104は、TUと関連付けられた残差ビデオブロックに1つまたは複数の変換を適用することによって、CUの各TUのための1つまたは複数の変換係数ブロックを生成し得る。変換係数ブロックの各々は、変換係数の2D行列であり得る。変換処理ユニット104は、TUと関連付けられた残差ビデオブロックに様々な変換を適用し得る。たとえば、変換処理ユニット104は、離散コサイン変換(DCT)、方向性変換、または概念的に同様の変換を、TUと関連付けられた残差ビデオブロックに適用し得る。
変換処理ユニット104が、TUと関連付けられた変換係数ブロックを生成した後、量子化ユニット106は、変換係数ブロック中の変換係数を量子化し得る。量子化ユニット106は、CUと関連付けられたQP値に基づいて、CUのTUと関連付けられた変換係数ブロックを量子化し得る。
ビデオエンコーダ20は、様々な方法でQP値をCUと関連付け得る。たとえば、ビデオエンコーダ20は、CUと関連付けられたツリーブロックに対してレートひずみ分析を実行し得る。レートひずみ分析では、ビデオエンコーダ20は、ツリーブロックに対して符号化動作を複数回実行することによって、ツリーブロックの複数のコーディングされた表現を生成し得る。ビデオエンコーダ20がツリーブロックの異なる符号化された表現を生成するとき、ビデオエンコーダ20は、異なるQP値をCUと関連付け得る。ビデオエンコーダ20は、最小のビットレートおよびひずみの尺度を有するツリーブロックのコーディングされた表現において所与のQP値がCUと関連付けられるとき、所与のQP値がCUと関連付けられることをシグナリングし得る。
逆量子化ユニット108および逆変換ユニット110は、変換係数ブロックから残差ビデオブロックを再構築するために、それぞれ、逆量子化と逆変換とを変換係数ブロックに適用し得る。再構築ユニット112は、TUと関連付けられる再構築されたビデオブロックを生成するために、再構築された残差ビデオブロックを、予測処理ユニット100によって生成された1つまたは複数の予測されたビデオブロックからの対応するサンプルに追加し得る。このようにCUの各TUのためのビデオブロックを再構築することによって、ビデオエンコーダ20は、CUのビデオブロックを再構築し得る。
再構築ユニット112がCUのビデオブロックを再構築した後、フィルタユニット113は、CUと関連付けられたビデオブロックにおけるブロッキングアーティファクトを低減するために、デブロッキング動作を実行し得る。1つまたは複数のデブロッキング動作を実行した後、フィルタユニット113は、CUの再構築されたビデオブロックを復号ピクチャバッファ114に記憶し得る。動き推定ユニット122および動き補償ユニット124は、再構築されたビデオブロックを含む参照ピクチャを使用して、後続のピクチャのPUに対してインター予測を実行し得る。加えて、イントラ予測ユニット126は、復号ピクチャバッファ114の中の再構築されたビデオブロックを使用して、CUと同じピクチャ中の他のPUに対してイントラ予測を実行し得る。
エントロピー符号化ユニット116は、ビデオエンコーダ20の他の機能コンポーネントからデータを受信し得る。たとえば、エントロピー符号化ユニット116は、量子化ユニット106から変換係数ブロックを受け取ることができ、予測処理ユニット100からシンタックス要素を受け取ることができる。エントロピー符号化ユニット116がデータを受信するとき、エントロピー符号化ユニット116は、1つまたは複数のエントロピー符号化動作を実行して、エントロピー符号化されたデータを生成し得る。たとえば、ビデオエンコーダ20は、コンテキスト適応型可変長コーディング(CALVC)動作、CABAC動作、変数間(V2V)レングスコーディング動作、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)動作、確率間隔区分エントロピー(PIPE)コーディング動作、または別のタイプのエントロピー符号化動作をデータに対して実行し得る。エントロピー符号化ユニット116は、エントロピー符号化されたデータを含むビットストリームを出力し得る。
データに対してエントロピー符号化動作を実行することの一部として、エントロピー符号化ユニット116は、コンテキストモデルを選択し得る。エントロピー符号化ユニット116がCABAC動作を実行している場合、コンテキストモデルは、特定の値を有する特定のビンの確率の推定値を示し得る。CABACの状況では、「ビン」という用語は、シンタックス要素の2値化されたバージョンのビットを指すために使用される。
マルチレイヤビデオエンコーダ
図2Bは、本開示で説明される態様による技法を実装し得る(単にビデオエンコーダ23とも呼ばれる)マルチレイヤビデオエンコーダ23の例を示すブロック図である。ビデオエンコーダ23は、SHVCおよびマルチビューコーディングの場合のように、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオエンコーダ23は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。
ビデオエンコーダ23はビデオエンコーダ20Aとビデオエンコーダ20Bとを含み、それらの各々はビデオエンコーダ20として構成されてよく、ビデオエンコーダ20に関して上で説明された機能を実行し得る。さらに、参照番号の再使用によって示されるように、ビデオエンコーダ20Aおよび20Bは、ビデオエンコーダ20としてのシステムおよびサブシステムの少なくともいくつかを含み得る。ビデオエンコーダ23は、2つのビデオエンコーダ20Aおよび20Bを含むように示されるが、ビデオエンコーダ23は、そのように限定されず、任意の数のビデオエンコーダ20のレイヤを含み得る。いくつかの実施形態では、ビデオエンコーダ23は、アクセスユニット中の各ピクチャまたは各フレームに対してビデオエンコーダ20を含み得る。たとえば、5つのピクチャを含むアクセスユニットは、5つのエンコーダレイヤを含むビデオエンコーダによって処理または符号化され得る。いくつかの実施形態では、ビデオエンコーダ23は、アクセスユニット中のフレームよりも多くのエンコーダレイヤを含み得る。いくつかのそのような場合では、ビデオエンコーダのレイヤのいくつかは、いくつかのアクセスユニットを処理するときに無効であり得る。
ビデオエンコーダ20Aおよび20Bに加えて、ビデオエンコーダ23は、リサンプリングユニット90を含み得る。いくつかの場合、リサンプリングユニット90は、たとえば、エンハンスメントレイヤを作成するために、受信されたビデオフレームのベースレイヤをアップサンプリングし得る。リサンプリングユニット90は、フレームの受信されたベースレイヤと関連付けられた特定の情報をアップサンプリングし得るが、他の情報をアップサンプリングしないことがある。たとえば、リサンプリングユニット90は、ベースレイヤの空間サイズまたはピクセルの数をアップサンプリングし得るが、スライスの数またはピクチャ順序カウントは一定のままであり得る。いくつかの場合、リサンプリングユニット90は、受信されたビデオを処理しないことがあり、および/または任意選択であり得る。たとえば、いくつかの場合、予測処理ユニット100は、アップサンプリングを実行し得る。いくつかの実施形態では、リサンプリングユニット90は、レイヤをアップサンプリングし、スライス境界の規則および/またはラスター走査の規則のセットに適合するように1つまたは複数のスライスを再編成し、再定義し、修正し、または調整するように構成される。アクセスユニット中のベースレイヤまたは下位レイヤをアップサンプリングするものとして主に説明されたが、いくつかの場合、リサンプリングユニット90は、レイヤをダウンサンプリングし得る。たとえば、ビデオのストリーミングの間に帯域幅が減少した場合、フレームは、アップサンプリングされるのではなく、ダウンサンプリングされ得る。
リサンプリングユニット90は、下位レイヤエンコーダ(たとえば、ビデオエンコーダ20A)の復号ピクチャバッファ114からピクチャまたはフレーム(またはピクチャと関連付けられたピクチャ情報)を受信し、ピクチャ(または受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤエンコーダと同じアクセスユニット中のピクチャを符号化するように構成された、上位レイヤエンコーダ(たとえば、ビデオエンコーダ20B)の予測処理ユニット100に提供され得る。いくつかの場合、上位レイヤエンコーダは、下位レイヤエンコーダから除去された1つのレイヤである。他の場合には、図2Bのレイヤ0ビデオエンコーダとレイヤ1エンコーダとの間に、1つまたは複数の上位レイヤエンコーダがあり得る。
いくつかの場合、リサンプリングユニット90は、省略またはバイパスされ得る。そのような場合、ビデオエンコーダ20Aの復号ピクチャバッファ114からのピクチャは、直接、または少なくともリサンプリングユニット90に提供されずに、ビデオエンコーダ20Bの予測処理ユニット100に提供され得る。たとえば、ビデオエンコーダ20Bに提供されたビデオデータ、およびビデオエンコーダ20Aの復号ピクチャバッファ114からの参照ピクチャが、同じサイズまたは解像度である場合、参照ピクチャは、いかなるリサンプリングも伴わずにビデオエンコーダ20Bに提供され得る。
いくつかの実施形態では、ビデオエンコーダ23は、ビデオエンコーダ20Aにビデオデータを提供する前に、ダウンサンプリングユニット94を使用して下位レイヤエンコーダに供給されるべきビデオデータをダウンサンプリングする。代替的に、ダウンサンプリングユニット94は、ビデオデータをアップサンプリングまたはダウンサンプリングすることが可能なリサンプリングユニット90であり得る。さらに他の実施形態では、ダウンサンプリングユニット94は省略され得る。
図2Bに示されるように、ビデオエンコーダ23はさらに、マルチプレクサ98、すなわちmuxを含み得る。mux98は、ビデオエンコーダ23から合成されたビットストリームを出力することができる。合成されたビットストリームは、ビデオエンコーダ20Aおよび20Bの各々からビットストリームを取り、所与の時間においてどちらのビットストリームが出力されるかを切り替えることによって作成され得る。いくつかの場合には、2つの(または、3つ以上のビデオエンコーダレイヤの場合には、より多くの)ビットストリームからのビットが一度に1ビット切り替えられ得るが、多くの場合、ビットストリームは異なるように合成され得る。たとえば、出力ビットストリームは、選択されたビットストリームを一度に1ブロック切り替えることによって作成され得る。別の例では、出力ビットストリームは、ビデオエンコーダ20Aおよび20Bの各々から1:1ではない比のブロックを出力することによって作成され得る。たとえば、ビデオエンコーダ20Aから出力された各ブロックについて、2つのブロックがビデオエンコーダ20Bから出力され得る。いくつかの実施形態では、mux98からの出力ストリームは事前にプログラムされ得る。他の実施形態では、mux98は、ビデオエンコーダ23の外部のシステムから、たとえばソースデバイス12を含むソースデバイス上のプロセッサから受信された制御信号に基づいて、ビデオエンコーダ20A、20Bからのビットストリームを合成し得る。制御信号は、ビデオソース18からのビデオの解像度またはビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザと関連付けられるサブスクリプション(たとえば、有料サブスクリプション対無料サブスクリプション)に基づいて、またはビデオエンコーダ23から望まれる解像度出力を決定するための任意の他の要因に基づいて生成され得る。
ビデオデコーダ
図3Aは、本開示で説明される態様による技法を実装し得るビデオデコーダ30の例を示すブロック図である。ビデオデコーダ30は、HEVCの場合のように、ビデオフレームの単一のレイヤを処理するように構成され得る。さらに、ビデオデコーダ30は、限定はされないが、図4および図5に関して上および下でより詳細に説明されるNoOutputOfPriorPicsFlagを推測する方法および関連する処理を含む、本開示の技法のいずれかまたはすべてを実行するように構成され得る。一例として、動き補償ユニット162および/またはイントラ予測ユニット164は、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。一実施形態では、ビデオデコーダ30は、任意選択で、本開示で説明される技法のいずれかまたはすべてを実行するように構成されたレイヤ間予測ユニット166を含み得る。他の実施形態では、レイヤ間予測は、予測処理ユニット152(たとえば、動き補償ユニット162および/またはイントラ予測ユニット164)によって実行されてよく、その場合、レイヤ間予測ユニット166は省略されてよい。しかしながら、本開示の態様はそのように限定されない。いくつかの例では、本開示で説明される技法は、ビデオデコーダ30の様々なコンポーネント間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示されず)が、本開示で説明される技法のいずれかまたはすべてを実行するように構成され得る。
説明の目的で、本開示は、HEVCコーディングの状況においてビデオデコーダ30を説明する。しかしながら、本開示の技法は他のコーディング規格または方法に適用可能であり得る。図3Aに示される例は、シングルレイヤコーデックのためのものである。しかしながら、図3Bに関してさらに説明されるように、ビデオデコーダ30の一部またはすべてが、マルチレイヤコーデックの処理のために複製され得る。
図3Aの例では、ビデオデコーダ30は複数の機能コンポーネントを含む。ビデオデコーダ30の機能コンポーネントは、エントロピー復号ユニット150と、予測処理ユニット152と、逆量子化ユニット154と、逆変換ユニット156と、再構築ユニット158と、フィルタユニット159と、復号ピクチャバッファ160とを含む。予測処理ユニット152は、動き補償ユニット162と、イントラ予測ユニット164と、レイヤ間予測ユニット166とを含む。いくつかの例では、ビデオデコーダ30は、図2Aのビデオエンコーダ20に関して説明された符号化経路とは全般に逆の復号経路を実行し得る。他の例では、ビデオデコーダ30は、より多数の、より少数の、または異なる機能コンポーネントを含み得る。
ビデオデコーダ30は、符号化されたビデオデータを備えるビットストリームを受信し得る。ビットストリームは、複数のシンタックス要素を含み得る。ビデオデコーダ30がビットストリームを受信するとき、エントロピー復号ユニット150は、ビットストリームに対して解析動作を実行し得る。ビットストリームに対して解析動作を実行した結果として、エントロピー復号ユニット150は、ビットストリームからシンタックス要素を抽出し得る。解析動作を実行することの一部として、エントロピー復号ユニット150は、ビットストリーム中のエントロピー符号化されたシンタックス要素をエントロピー復号し得る。予測処理ユニット152、逆量子化ユニット154、逆変換ユニット156、再構築ユニット158、およびフィルタユニット159は、ビットストリームから抽出されたシンタックス要素に基づいて復号されたビデオデータを生成する、再構築動作を実行し得る。
上で論じられたように、ビットストリームは、一連のNALユニットを備え得る。ビットストリームのNALユニットは、ビデオパラメータセットNALユニット、シーケンスパラメータセットNALユニット、ピクチャパラメータセットNALユニット、SEI NALユニットなどを含み得る。ビットストリームに対して解析動作を実行することの一部として、エントロピー復号ユニット150は、シーケンスパラメータセットNALユニットからのシーケンスパラメータセット、ピクチャパラメータセットNALユニットからのピクチャパラメータセット、SEI NALユニットからのSEIデータなどを抽出しエントロピー復号する、解析動作を実行し得る。
さらに、ビットストリームのNALユニットは、コーディングされたスライスNALユニットを含み得る。ビットストリームに対して解析動作を実行することの一部として、エントロピー復号ユニット150は、コーディングされたスライスNALユニットからコーディングされたスライスを抽出しエントロピー復号する、解析動作を実行し得る。コーディングされたスライスの各々は、スライスヘッダと、スライスデータとを含み得る。スライスヘッダは、スライスに関するシンタックス要素を含み得る。スライスヘッダ中のシンタックス要素は、スライスを含むピクチャと関連付けられたピクチャパラメータセットを識別するシンタックス要素を含み得る。エントロピー復号ユニット150は、コーディングされたスライスヘッダ中のシンタックス要素に対してCABAC復号動作のようなエントロピー復号演算を実行して、スライスヘッダを復元し得る。
コーディングされたスライスNALユニットからスライスデータを抽出することの一部として、エントロピー復号ユニット150は、スライスデータ中のコーディングされたCUからシンタックス要素を抽出する解析動作を実行し得る。抽出されたシンタックス要素は、変換係数ブロックと関連付けられるシンタックス要素を含み得る。エントロピー復号ユニット150は次いで、シンタックス要素のいくつかに対してCABAC復号動作を実行し得る。
エントロピー復号ユニット150が区分されていないCUに対して解析動作を実行した後、ビデオデコーダ30は、区分されていないCUに対して再構築動作を実行し得る。区分されていないCUに対して再構築動作を実行するために、ビデオデコーダ30はCUの各TUに対して再構築動作を実行し得る。CUの各TUについて再構築動作を実行することによって、ビデオデコーダ30は、CUと関連付けられた残差ビデオブロックを再構築し得る。
TUに対して再構築動作を実行することの一部として、逆量子化ユニット154は、TUと関連付けられた変換係数ブロックを逆量子化(inverse quantize)、たとえば、逆量子化(de-quantize)し得る。逆量子化ユニット154は、HEVCのために提案された、またはH.264復号規格によって定義された逆量子化処理と同様の方式で、変換係数ブロックを逆量子化し得る。逆量子化ユニット154は、変換係数ブロックのCUのためにビデオエンコーダ20によって計算される量子化パラメータQPを使用して、量子化の程度を決定し、同様に、逆量子化ユニット154が適用すべき逆量子化の程度を決定し得る。
逆量子化ユニット154が変換係数ブロックを逆量子化した後、逆変換ユニット156は、変換係数ブロックと関連付けられたTUのための残差ビデオブロックを生成し得る。逆変換ユニット156は、変換係数ブロックに逆変換を適用して、TUのための残差ビデオブロックを生成し得る。たとえば、逆変換ユニット156は、変換係数ブロックに、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT)、逆回転変換、逆方向変換、または別の逆変換を適用し得る。いくつかの例では、逆変換ユニット156は、ビデオエンコーダ20からのシグナリングに基づいて、変換係数ブロックに適用すべき逆変換を決定し得る。そのような例では、逆変換ユニット156は、変換係数ブロックと関連付けられたツリーブロックの4分木のルートノードにおけるシグナリングされた変換に基づいて、逆変換を決定し得る。他の例では、逆変換ユニット156は、ブロックサイズ、コーディングモードなどのような、1つまたは複数のコーディング特性から逆変換を推測し得る。いくつかの例では、逆変換ユニット156はカスケード逆変換を適用し得る。
いくつかの例では、動き補償ユニット162は、補間フィルタに基づく補間を実行することによって、PUの予測されるビデオブロックを改良し得る。サブサンプル精度を有する動き補償のために使用されるべき補間フィルタのための識別子は、シンタックス要素に含まれ得る。動き補償ユニット162は、PUの予測されたビデオブロックの生成の間にビデオエンコーダ20によって使用されたのと同じ補間フィルタを使用して、参照ブロックのサブ整数サンプルのための補間された値を計算し得る。動き補償ユニット162は、受信されたシンタックス情報に従って、ビデオエンコーダ20によって使用された補間フィルタを決定し、その補間フィルタを使用して予測されたビデオブロックを生成し得る。
図5に関して下でさらに論じられるように、予測処理ユニット152は、図5に示されている方法を実行することによってPU(または他の参照レイヤブロックおよび/またはエンハンスメントレイヤブロックまたはビデオユニット)をコーディング(たとえば、符号化または復号)し得る。たとえば、動き補償ユニット162、イントラ予測ユニット164、またはレイヤ間予測ユニット166は、一緒にまたは別々に、図5に示されている方法を実行するように構成され得る。
PUが、イントラ予測を使用して符号化される場合、イントラ予測ユニット164は、イントラ予測を実行して、PUのための予測されたビデオブロックを生成し得る。たとえば、イントラ予測ユニット164は、ビットストリーム中のシンタックス要素に基づいて、PUのためのイントラ予測モードを決定し得る。ビットストリームは、PUのイントラ予測モードを決定するためにイントラ予測ユニット164が使用し得るシンタックス要素を含み得る。
いくつかの事例では、シンタックス要素は、イントラ予測ユニット164が現在のPUのイントラ予測モードを決定するために別のPUのイントラ予測モードを使用すべきであることを、示し得る。たとえば、現在のPUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることが起こり得る。言い換えれば、隣接PUのイントラ予測モードは、現在のPUに対して最も可能性のあるモードであり得る。したがって、この例では、ビットストリームは、PUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示す、小さいシンタックス要素を含み得る。イントラ予測ユニット164は次いで、イントラ予測モードを使用して、空間的に隣接するPUのビデオブロックに基づいてPUのための予測データ(たとえば、予測されるサンプル)を生成し得る。
上で説明されたように、ビデオデコーダ30もレイヤ間予測ユニット166を含み得る。レイヤ間予測ユニット166は、スケーラブルビデオコーディングにおいて利用可能である1つまたは複数の異なるレイヤ(たとえば、ベースレイヤまたは参照レイヤ)を使用して、現在のブロック(たとえば、EL中の現在のブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット166は、レイヤ間の冗長性を低減するための予測方法を利用し、それによって、コーディング効率を改善し、計算リソースの要件を下げる。レイヤ間予測のいくつかの例は、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測を含む。レイヤ間イントラ予測は、エンハンスメントレイヤ中の現在のブロックを予測するために、ベースレイヤの中で併置されているブロックの再構築を使用する。レイヤ間動き予測は、エンハンスメントレイヤ中の動作を予測するために、ベースレイヤの動き情報を使用する。レイヤ間残差予測は、エンハンスメントレイヤの残差を予測するために、ベースレイヤの残差を使用する。レイヤ間予測方式の各々が、以下でより詳細に説明される。
再構築ユニット158は、適用可能なとき、CUのTUと関連付けられた残差ビデオブロックとCUのPUの予測されたビデオブロックとを使用して、たとえば、イントラ予測データまたはインター予測データのいずれかを使用して、CUのビデオブロックを再構築し得る。したがって、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて、予測されたビデオブロックと残差ビデオブロックとを生成することができ、予測されたビデオブロックと残差ビデオブロックとに基づいて、ビデオブロックを生成することができる。
再構築ユニット158がCUのビデオブロックを再構築した後、フィルタユニット159は、デブロッキング動作を実行して、CUと関連付けられるブロッキングアーティファクトを低減し得る。フィルタユニット159が、デブロッキング動作を実行してCUと関連付けられたブロッキングアーティファクトを低減した後、ビデオデコーダ30はCUのビデオブロックを復号ピクチャバッファ160に記憶し得る。復号ピクチャバッファ160は、後続の動き補償、イントラ予測、および図1Aまたは図1Bのディスプレイデバイス32のようなディスプレイデバイス上での提示のために、参照ピクチャを提供し得る。たとえば、ビデオデコーダ30は、復号ピクチャバッファ160中のビデオブロックに基づいて、他のCUのPUに対してイントラ予測動作またはインター予測動作を実行し得る。
マルチレイヤデコーダ
図3Bは、本開示で説明される態様による技法を実装し得る(単にビデオデコーダ33とも呼ばれる)マルチレイヤビデオデコーダ33の例を示すブロック図である。ビデオデコーダ33は、SHVCおよびマルチビューコーディングの場合のように、マルチレイヤビデオフレームを処理するように構成され得る。さらに、ビデオデコーダ33は、本開示の技法のいずれかまたはすべてを実行するように構成され得る。
ビデオデコーダ33はビデオデコーダ30Aとビデオデコーダ30Bとを含み、それらの各々はビデオデコーダ30として構成されてよく、ビデオデコーダ30に関して上で説明された機能を実行し得る。さらに、参照番号の再使用によって示されるように、ビデオデコーダ30Aおよび30Bは、ビデオデコーダ30としてのシステムおよびサブシステムのうちの少なくともいくつかを含み得る。ビデオデコーダ33は、2つのビデオデコーダ30Aおよび30Bを含むように示されるが、ビデオデコーダ33は、そのように限定されず、任意の数のビデオデコーダ30のレイヤを含み得る。いくつかの実施形態では、ビデオデコーダ33は、アクセスユニット中の各ピクチャまたは各フレームに対してビデオデコーダ30を含み得る。たとえば、5つのピクチャを含むアクセスユニットは、5つのデコーダレイヤを含むビデオデコーダによって処理または復号され得る。いくつかの実施形態では、ビデオデコーダ33は、アクセスユニット中のフレームよりも多くのデコーダレイヤを含み得る。いくつかのそのような場合には、ビデオデコーダのレイヤのいくつかは、いくつかのアクセスユニットを処理するときに無効であり得る。
ビデオデコーダ30Aおよび30Bに加えて、ビデオデコーダ33は、アップサンプリングユニット92を含み得る。いくつかの実施形態では、アップサンプリングユニット92は、受信されたビデオフレームのベースレイヤをアップサンプリングして、フレームまたはアクセスユニットのための参照ピクチャリストに追加されるべきエンハンストレイヤを作成し得る。このエンハンストレイヤは、復号ピクチャバッファ160に記憶され得る。いくつかの実施形態では、アップサンプリングユニット92は、図2Aのリサンプリングユニット90に関して説明された実施形態の一部またはすべてを含み得る。いくつかの実施形態では、アップサンプリングユニット92は、レイヤをアップサンプリングし、スライス境界の規則および/またはラスター走査の規則のセットに準拠するように、1つまたは複数のスライスを再編成し、再定義し、修正し、または調整するように構成される。いくつかの場合は、アップサンプリングユニット92は、受信されたビデオフレームのレイヤをアップサンプリングおよび/またはダウンサンプリングするように構成されたリサンプリングユニットであり得る。
アップサンプリングユニット92は、下位レイヤデコーダ(たとえば、ビデオデコーダ30A)の復号ピクチャバッファ160からピクチャまたはフレーム(またはピクチャと関連付けられたピクチャ情報)を受信し、ピクチャ(または受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは次いで、下位レイヤデコーダと同じアクセスユニット中のピクチャを復号するように構成された上位レイヤデコーダ(たとえば、ビデオデコーダ30B)の予測処理ユニット152に与えられ得る。いくつかの場合、上位レイヤデコーダは、下位レイヤデコーダから除去された1つのレイヤである。他の場合には、図3Bのレイヤ0デコーダとレイヤ1デコーダとの間に1つまたは複数の上位レイヤデコーダがあり得る。
いくつかの場合は、アップサンプリングユニット92は、省略またはバイパスされ得る。そのような場合、ビデオデコーダ30Aの復号ピクチャバッファ160からのピクチャは、直接、または少なくともアップサンプリングユニット92に提供されずに、ビデオデコーダ30Bの予測処理ユニット152に提供され得る。たとえば、ビデオデコーダ30Bに提供されたビデオデータ、およびビデオデコーダ30Aの復号ピクチャバッファ160からの参照ピクチャが、同じサイズまたは解像度である場合、参照ピクチャは、アップサンプリングを伴わずにビデオデコーダ30Bに提供され得る。さらに、いくつかの実施形態では、アップサンプリングユニット92は、ビデオデコーダ30Aの復号ピクチャバッファ160から受信された参照ピクチャをアップサンプリングまたはダウンサンプリングするように構成された、リサンプリングユニット90であり得る。
図3Bに示されるように、ビデオデコーダ33はさらに、デマルチプレクサ99、すなわちdemuxを含み得る。demux99は、符号化されたビデオビットストリームを複数のビットストリームに分割することができ、demux99によって出力された各ビットストリームは、異なるビデオデコーダ30Aおよび30Bに提供される。複数のビットストリームはビットストリームを受信することによって作成されてよく、ビデオデコーダ30Aおよび30Bの各々は所与の時間においてビットストリームの一部分を受信する。いくつかの場合、demux99において受信されるビットストリームからのビットは、ビデオデコーダの各々(たとえば、図3Bの例ではビデオデコーダ30Aおよび30B)の間で、一度に1ビット切り替えられ得るが、多くの場合、ビットストリームは異なるように分割される。たとえば、ビットストリームは、どのビデオデコーダがビットストリームを受信するかを一度に1ブロック切り替えることによって分割され得る。別の例では、ビットストリームは、1:1ではない比のブロックによって、ビデオデコーダ30Aおよび30Bの各々に分割され得る。たとえば、2つのブロックは、ビデオデコーダ30Aに提供される各ブロックについてビデオデコーダ30Bに提供され得る。いくつかの実施形態では、demux99によるビットストリームの分割は、事前にプログラムされ得る。他の実施形態では、demux99は、ビデオデコーダ33の外部のシステムから、たとえば宛先モジュール14を含む宛先デバイス上のプロセッサから受信された制御信号に基づいて、ビットストリームを分割し得る。制御信号は、入力インターフェース28からのビデオの解像度またはビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザと関連付けられたサブスクリプション(たとえば、有料サブスクリプション対無料サブスクリプション)に基づいて、またはビデオデコーダ33によって取得可能な解像度を決定するための任意の他の要因に基づいて生成され得る。
イントラランダムアクセスポイント(IRAP)ピクチャ
いくつかのビデオコーディング方式は、様々なランダムアクセスポイントを、ビットストリームの中でそれらのランダムアクセスポイントに先行するいかなるピクチャも復号する必要なく、それらのランダムアクセスポイントのいずれかからビットストリームの復号が開始され得るように、ビットストリーム全体にわたって提供し得る。たとえば、これは、ビットストリームが単一のレイヤを含むとき、またはランダムアクセスポイントがすべてのレイヤにおけるIRAPピクチャを有するときに、当てはまり得る。そのようなビデオコーディング方式では、(たとえば、ランダムアクセスポイントを提供するピクチャと同じアクセスユニット中にあるピクチャを含む)出力順序においてランダムアクセスポイントに後続するすべてのピクチャが、ランダムアクセスポイントに先行するいかなるピクチャも使用することなく正しく復号され得る。たとえば、ビットストリームの一部分が送信の間または復号の間に失われても、デコーダは、次のランダムアクセスポイントからビットストリームの復号を再開することができる。いくつかのビデオ方式は、ランダムアクセスポイントを、ベースレイヤピクチャの復号、およびそれに加えてビットストリーム中の0個以上の他のレイヤに属するピクチャの復号が、それらのランダムアクセスポイントに先行するいずれのピクチャも復号することなくそれらのランダムアクセスポイントのいずれかから開始され得るように、提供することができるが、それらのランダムアクセスポイントにおいて復号が開始するときに、すべてのレイヤが正しく復号可能であるとは限らない。すべてのレイヤの正しい復号は、後続のアクセスユニットにおいて起こり得る。ランダムアクセスのサポートは、たとえば、動的なストリーミングサービス、検索動作、チャネル切替えなどを容易にし得る。
いくつかのコーディング方式では、そのようなランダムアクセスポイントは、IRAPピクチャと呼ばれるピクチャによって提供され得る。たとえば、アクセスユニット(「auA」)に含まれるエンハンスメントレイヤ(「layerA」)中の(たとえば、エンハンスメントレイヤIRAPピクチャによって提供される)ランダムアクセスポイントは、各参照レイヤ(「layerB」)中にあり復号順序においてauAに先行するアクセスユニット(「auB」)に含まれるランダムアクセスポイント(または、auAに含まれるランダムアクセスポイント)を有するlayerAの各layerB(たとえば、layerAを予測するために使用されるレイヤである参照レイヤ)について、出力順序においてauAに後続する(auAの中に位置するピクチャを含む)layerA中のピクチャが、復号がアクセスユニットauBにおいて、または復号順序でauBに先行するアクセスユニットにおいて開始するとき、auAに先行するlayerA中のいかなるピクチャも復号する必要なく正しく復号可能であるように、レイヤ特有のランダムアクセスを提供し得る。
IRAPピクチャは、イントラ予測を使用してコーディングされてよく(たとえば、他のピクチャを参照することなくコーディングされてよく)、たとえば、瞬時復号リフレッシュ(IDR)ピクチャと、クリーンランダムアクセス(CRA)ピクチャと、ブロークンリンクアクセス(BLA)ピクチャとを含み得る。ビットストリーム中にIDRピクチャがあるとき、復号順序においてIDRピクチャに先行するすべてのピクチャは、復号順序においてIDRピクチャに後続するピクチャによる予測のために使用されない。ビットストリーム中にCRAピクチャがあるとき、CRAピクチャに後続するピクチャは、復号順序においてCRAピクチャに先行するピクチャを予測のために使用することがあり、または使用しないことがある。復号順序においてCRAピクチャに後続するが、復号順序においてCRAピクチャに先行するピクチャを使用するピクチャは、ランダムアクセススキップ先頭(RASL)ピクチャと呼ばれ得る。復号順序においてIRAPピクチャに後続し、出力順序においてIRAPピクチャに先行する別のタイプのピクチャは、復号順序においてIRAPピクチャに先行するいかなるピクチャへの参照も含まないことがあるランダムアクセス復号可能先頭(RADL)ピクチャである。CRAピクチャに先行するピクチャが利用可能でない場合、RASLピクチャはデコーダによって廃棄され得る。BLAピクチャは、(たとえば、2つのビットストリームが互いに接合され、BLAピクチャが復号順序において第2のビットストリームの最初のピクチャであるので)BLAピクチャに先行するピクチャがデコーダにとって利用可能でないことがあることを、デコーダに示す。IRAPピクチャであるベースレイヤピクチャ(たとえば、0というレイヤID値を有するピクチャ)を含むアクセスユニット(たとえば、複数のレイヤにわたって同じ出力時間と関連付けられたすべてのコーディングされたピクチャからなるピクチャのグループ)は、IRAPアクセスユニットと呼ばれ得る。
IRAPピクチャのクロスレイヤ整合
スケーラブルビデオコーディングでは、IRAPピクチャは、異なるレイヤにわたって整合される(たとえば、同じアクセスユニットに含まれる)ことを要求されないことがある。たとえば、IRAPピクチャが整合されることを要求される場合、少なくとも1つのIRAPピクチャを含むいかなるアクセスユニットも、IRAPピクチャしか含まないであろう。一方、IRAPピクチャが、単一のアクセスユニット中で、整合されることを要求されない場合、(たとえば、第1のレイヤ中の)あるピクチャはIRAPピクチャであることがあり、(たとえば、第2のレイヤ中の)別のピクチャは非IRAPピクチャであることがある。ビットストリーム中にそのような整合されていないIRAPピクチャがあることは、いくつかの利点をもたらし得る。たとえば、2レイヤのビットストリーム中で、エンハンスメントレイヤ中よりも多くのIRAPピクチャがベースレイヤ中にある場合、ブロードキャストおよびマルチキャストの適用例において、小さい同調遅延および高いコーディング効率が達成され得る。
いくつかのビデオコーディング方式では、ピクチャ順序カウント(POC)が、復号ピクチャが表示される相対的な順序を追跡するために使用され得る。そのようなコーディング方式のうちのいくつかは、あるタイプのピクチャがビットストリーム中に出現するときはいつでも、POC値をリセットさせ得る(たとえば、0に設定されるか、またはビットストリーム中でシグナリングされた何らかの値に設定される)。たとえば、あるIRAPピクチャのPOC値がリセットされてよく、それにより、復号順序においてそれらのIRAPピクチャに先行する他のピクチャのPOC値もリセットされる。IRAPピクチャが異なるレイヤにわたって整合されることを要求されないとき、このことが問題となり得る。たとえば、あるピクチャ(「picA」)がIRAPピクチャであり、同じアクセスユニット中の別のピクチャ(「picB」)がIRAPピクチャではないとき、picAがIRAPピクチャであることが原因でリセットされる、picAを含むレイヤ中のピクチャ(「picC」)のPOC値は、picBを含むレイヤ中のリセットされないピクチャ(「picD」)のPOC値と異なることがあり、ここで、picCおよびpicDは同じアクセスユニット中にある。これにより、picCおよびpicDが同じアクセスユニット(たとえば、同じ出力時間)に属していても、picCおよびpicDが異なるPOC値を有するようになる。したがって、この例では、POC値を導出するための導出処理は、POC値およびアクセスユニットの定義と一致するPOC値を生成するように修正され得る。
レイヤ初期化ピクチャ(LIP)
いくつかのコーディング方式では、レイヤ初期化ピクチャ(「LIPピクチャ」)は、1に設定されたNoRaslOutputFlagフラグ(たとえば、1に設定される場合はRASLピクチャが出力されるべきではないことを示し、0に設定される場合はRASLピクチャが出力されるべきであることを示すフラグ)を有するIRAPピクチャであるピクチャ、または、ベースレイヤピクチャ(たとえば、0というレイヤIDまたはビットストリーム中で定義される最小のレイヤIDを有するピクチャ)が1に設定されたNoRaslOutputFlagを有するIRAPアクセスユニットである初期IRAPアクセスユニットに含まれるピクチャとして定義され得る。
いくつかの実施形態では、SPSは、各LIPピクチャにおいて有効にされ得る。たとえば、各IRAPピクチャが1に設定されたNoRaslOutputFlagフラグを有し、または各ピクチャが初期IRAPアクセスユニット中に含まれ、新しいSPSが(たとえば、異なるピクチャ解像度を指定するなど)前に有効にされたSPSとは異なり得る。しかしながら、LIPピクチャがIRAPピクチャ(たとえば、初期IRAPアクセスユニット中に含まれる任意のピクチャ)ではなく、初期IRAPアクセスユニット中のベースレイヤピクチャが、0に設定されたフラグNoClrasOutputFlagフラグ(たとえば、1に設定される場合はクロスレイヤランダムアクセススキップピクチャが出力されるべきではないことを示し、0に設定される場合はクロスレイヤランダムアクセススキップピクチャが出力されるべきであることを示すフラグ)をもつIDRピクチャである場合、LIPピクチャは新しいSPSを有効にすることを許容されるべきでない。そのような事例においてそのようなLIPピクチャにおいて新しいSPSが有効にされる場合、具体的には、新しいSPSのSPS RBSPのコンテンツが初期IRAPアクセスユニットの前にかつて有効であったSPSのコンテンツとは異なるとき、異なるピクチャ解像度および誤り耐性において問題があることがある。たとえば、新しいSPSは、解像度を更新し、時間予測を使用して異なるサイズのピクチャを参照することがある。
ピクチャのバンピングおよびフラッシング
復号されたピクチャは、(たとえば、それらが表示され、または他のピクチャを予測するために使用され得るように)DPBに記憶される。出力されるべきピクチャは、「出力のために必要とされる」ものとして標識されてよく、他のピクチャを予測するために使用されるべきピクチャは、「参照のために使用される」ものとして標識されてよい。「出力のために必要とされる」とも「参照のために使用される」とも標識されない復号されたピクチャ(たとえば、最初に「参照のために使用される」または「出力のために必要とされる」ものとして標識されたが、その後、「参照のために使用されない」または「出力のために必要とされない」ものとして標識されたピクチャ)は、それらが復号処理によって除去されるまでDPBに存在し得る。出力順序に従うデコーダでは、ピクチャをDPBから除去する処理が、しばしば、「出力のために必要とされる」ものと標識されたピクチャの出力の直後にくる。出力およびその後の除去というこの処理は、「バンピング」と呼ばれることがある。
DPB中のピクチャが「出力のために必要とされる」ものとして標識され得るとしても、デコーダがそれらのピクチャを出力することなく削除し得る状況もある。本明細書での説明を簡単にするために、IRAPピクチャを復号するときにDPB中に存在する復号されたピクチャは、(復号されたピクチャが「出力のために必要とされる」ものとして標識されるかまたは「参照のために使用される」ものとして標識されるかにかかわらず)IRAPピクチャと関連付けられた「遅れたDPBピクチャ」、またはIRAPピクチャの「関連する遅れたDPBピクチャ」と呼ばれる。そのような状況のいくつかの例が、HEVCの状況において以下に説明される。
一例では、「1」の値に等しいNoRaslOutputFlagを有するCRAピクチャがビットストリームの中間に存在する(たとえば、ビットストリーム中の最初のピクチャではない)とき、CRAピクチャと関連付けられた遅れたDPBピクチャは、出力されず、DPBから削除される。2つのビットストリームが互いに結合され、後者のビットストリームの最初のピクチャが「1」の値に等しいNoRaslOutputFlagをもつCRAピクチャである場合、そのような状況が、接合点において発生する可能性が高い。別の例では、「1」の値に等しいNoRaslOutputFlagを有するとともにCRAピクチャでないIRAPピクチャpicA(たとえば、IDRピクチャ)がビットストリームの中間に存在し、ピクチャの解像度が(たとえば、新しいSPSの有効にとともに)picAにおいて変化するとき、picAの関連する遅れたDPBピクチャは、関連する遅れたDPBピクチャがDPBを占有し続ける場合、picAから始まるピクチャの復号が、たとえばバッファオーバーフローが原因で問題となり得るので、出力され得る前にDPBから除去され得る。この場合、picAと関連付けられたno_output_of_prior_pics_flag(たとえば、1に設定される場合は前に復号されDPBに記憶されたピクチャが出力されることなくDPBから削除されるべきであることを示し、0に設定される場合は前に復号されDPBに記憶されたピクチャが出力されることなくDPBから削除されるべきでないことを示すフラグ)の値は、エンコーダまたはスプライサによって「1」の値に等しく設定されるべきであり、または、NoOutputOfPriorPicsFlag(たとえば、ビットストリーム中に含まれる情報に基づいて決定され得る導出値)は、遅れたピクチャをDPBの外へ出力することなくフラッシングするように、デコーダによって「1」の値に等しいものとして導出され得る。接合動作が、図4に関して以下でさらに説明される。
関連する遅れたDPBピクチャを出力することなくDPBから除去するこの処理は、「フラッシング」と呼ばれることがある。上で説明されない状況においても、デコーダがIRAPピクチャの関連するDPBの遅れたピクチャをフラッシングするように、IRAPピクチャは、no_output_of_prior_pics_flagの値を「1」の値に等しく指定し得る。
接合点を含むビットストリーム
図4を参照すると、接合点を有する例示的なビットストリームが説明される。図4は、接合するビットストリーム410および420によって作り出されたマルチレイヤビットストリーム400を示す。ビットストリーム410は、エンハンスメントレイヤ(EL)410Aとベースレイヤ(BL)410Bとを含み、ビットストリーム420は、EL420AとBL420Bとを含む。EL410AはELピクチャ412Aを含み、BL410BはBLピクチャ412Bを含む。EL420Aは、ELピクチャ422A、424A、および426Aを含み、BL420Bは、BLピクチャ422B、424B、および426Bを含む。マルチレイヤビットストリーム400は、アクセスユニット(AU)430〜460をさらに含む。AU430は、ELピクチャ412AとBLピクチャ412Bとを含み、AU440は、ELピクチャ422AとBLピクチャ422Bとを含み、AU450は、ELピクチャ424AとBLピクチャ424Bとを含み、AU460は、ELピクチャ426AとBLピクチャ426Bとを含む。図4の例では、BLピクチャ422BはIRAPピクチャであり、AU440の中の対応するELピクチャ422Aは、末尾のピクチャ(たとえば、非IRAPピクチャ)であり、したがって、AU440は整合されていないIRAP AUである。また、AU440が接合点470の直後のアクセスユニットであることに留意されたい。
図4の例は2つの異なるビットストリームが互いに結合される場合を示すが、いくつかの実施形態では、ビットストリームの一部分が除去されるときに接合点が存在することがある。たとえば、ビットストリームは、部分A、B、およびCを有してよく、部分Bは部分AとCの間にある。部分Bがビットストリームから除去される場合、残りの部分AおよびCは互いに結合されてよく、それらが互いに結合される点が接合点と呼ばれ得る。より一般的には、本出願で論じられるような接合点は、1つまたは複数のシグナリングまたは導出されたパラメータまたはフラグが所定の値を有するとき、存在すると見なされ得る。たとえば、接合点が特定の位置において存在するという具体的な指示を受信しなければ、デコーダは、フラグ(たとえば、NoClrasOutputFlag)の値を決定し、フラグの値に基づいて本出願で説明される1つまたは複数の技法を実行し得る。
マルチレイヤの状況におけるピクチャのフラッシング
ピクチャをフラッシングする処理は、マルチレイヤビットストリームにおいても関連がある。より具体的には、それは初期IRAPアクセスユニットに属するすべてのピクチャと関連があり、初期IRAPアクセスユニット中にないIRAPピクチャとも関連がある。上で説明されたように、SHVCおよびMV-HEVCのようないくつかの既存の実装形態では、IRAPアクセスユニットは、(アクセスユニット中の他のピクチャがIRAPピクチャであるかどうかにかかわらず)「0」の値に等しいnuh_layer_idを有するIRAPピクチャを含むアクセスユニットとして定義されることがあり、初期IRAPアクセスユニットは、(この場合も、アクセスユニット中の他のピクチャがIRAPピクチャであるかどうかにかかわらず)「0」の値に等しいnuh_layer_idを有し「1」の値に等しいNoRaslOutputFlagを有するIRAPピクチャを含むアクセスユニットとして定義されることがある。
SHVCおよびMV-HEVCにおいて、整合されていないIRAPピクチャをアクセスユニット中に有する可能性がある(たとえば、アクセスユニットがIRAPピクチャと非IRAPピクチャの両方を含み得る)場合、HEVCの状況において前のセクションで説明された状態は、SHVC/MV-HEVCビットストリームの異なるレイヤにおいて起こり得る。たとえば、「1」の値に等しいNoRaslOutputFlagを有するCRAピクチャpicAは、エンハンスメントレイヤにおいてpicAと同じレイヤ中にCRAピクチャを有しない初期IRAPアクセスユニットとともに開始するビットストリームの中間に存在し得る(たとえば、ビットストリームの第1のアクセスユニットの中に存在しない)。また、ベースレイヤの解像度が変化しない場合に、ピクチャの解像度の変化がアクセスユニットにおけるエンハンスメントレイヤ中でIRAPピクチャにおいて発生することがあり、またはその逆も同様である。類似の状態が、異なるDPBサイズに対して起こり得る。
SVCおよびMVCにおけるピクチャのフラッシング
SVCの単一ループコーディング設計が原因で、いわゆる中粒度スケーラビリティ(MGS)が使用される場合を除いて、アクセスユニットごとに1つの再構築されたピクチャのみがDPBに挿入される(その場合、DPBに記憶されるいわゆるキーピクチャアクセスユニットからの2つの復号されたピクチャがあり得る)。しかしながら、各アクセスユニット中で、最上位レイヤの復号ピクチャのみが出力され得る。したがって、ピクチャのフラッシングを含むDPBを管理するための動作は、主に、ベースレイヤの復号されたピクチャはエンハンスメントレイヤを予測するためにDPBに存在することが必要とされないので、最上位レイヤ中のピクチャのみに関係する。
MVCでは、2つ以上のビューがターゲット出力ビューであってよく、復号されたビュー成分は、それらが同じレイヤ中のビュー成分を予測するために必要とされなくても、他のレイヤ中のビュー成分を予測するために維持される必要がある。したがって、2つ以上のビューからのビュー成分がDPBに存在し得る。フラグno_output_of_prior_pics_flagが、各IDRビュー成分についてシグナリングされ(たとえば、非ベースビューのIDRビュー成分は「0」の値に等しいnon_idr_flagによりシグナリングされる)、ビュー成分のフラッシングはレイヤ特有(またはビュー特有)である。MVCでは、簡単のために、MVCにおけるアクセスユニット中のIDRビュー成分は整合される。たとえば、アクセスユニット中のあるビュー成分がIDRビュー成分である場合、そのアクセスユニット中のすべてのビュー成分もIDRビュー成分である。したがって、フラッシング動作はまた、動作がビュー/レイヤ特有であり得るとしても、ビットストリーム中のすべてのビューにわたって実行される。
出力タイミングの適合
MV-HEVCワーキングドラフト(WD)7のようないくつかの実装形態(たとえば、SHVC、MV-HEVCなど)では、出力タイミングの適合のための、DPBからのピクチャの出力および除去が、以下に説明されるように実行される。同様または同一の概念がSHVCに適用されることが可能であり、ワーキングドラフト5に続くSHVCのワーキングドラフトにおいて反映されており、または反映されることになる。
出力順序の適合
いくつかの実装形態(たとえば、SHVC、MV-HEVCなど)では、出力順序の適合のために、DPBからのピクチャの出力および除去が、以下に説明されるように実行される。以下の例では、ピクチャの削除は、呼び出されたとき、レイヤ固有である。
前のピクチャの出力を示すフラグのシグナリング
いくつかの実施形態では、変数NoOutputOfPriorPicsFlag(たとえば、IRAPピクチャを復号するとき、DPBがフラッシングされる前にDPB中のピクチャを出力すべきかどうかを決定するためにデコーダによって導出される値)は、no_output_of_prior_pics_flagおよび他の条件に基づいて導出される。たとえば、no_output_of_prior_pics_flagは、ビットストリーム中でシグナリングされる値であってよく、NoOutputOfPriorPicsFlagは、ビットストリーム中に含まれる情報に基づいてエンコーダによって導出される値であってよい。デコーダは、no_output_of_prior_pics_flagの値および他の条件に基づいてNoOutputOfPriorPicsFlagの値を導出し、次いで、NoOutputOfPriorPicsFlagの導出された値を使用してピクチャを出力すべきかどうかを決定し得る。いくつかの実施形態では、フラグNoOutputOfPriorPicsFlagは、現在のアクセスユニットが、2つの異なるビットストリームが互いに縫合される接合点を備えるかどうかを示し得る。
いくつかの実施形態では、NoClRasOutputFlagおよびNoRaslOutputFlagは、ビットストリーム中に含まれる情報に基づいて導出される変数であり得る。たとえば、NoRaslOutputFlagは、(たとえば、BLおよび/またはEL中の)あらゆるIRAPピクチャに対して導出されてよく、NoClRasOutputFlagは、最下位レイヤピクチャ(たとえば、BLピクチャ)のみに対して導出されてよい。NoClRasOutputFlagおよびNoRaslOutputFlagの各々の値は、ビットストリーム中のいくつかのピクチャが、いくつかの参照ピクチャを利用できないことが原因で正しく復号可能でないことがあることを示し得る。参照ピクチャをそのように利用できないことは、ランダムアクセスポイントにおいて発生し得る。クロスレイヤランダムアクセススキップ(CL-RAS)ピクチャは、いくつかの点で、RASLピクチャのマルチレイヤ等価物である。デコーダがランダムアクセスポイント(たとえば、BL IRAPピクチャを有するアクセスユニット)においてビットストリームを復号することを開始し、アクセスユニット中のELピクチャがIRAPピクチャではない場合、そのELピクチャはCL-RASピクチャである。EL中のすべてのピクチャが、IRAPピクチャがELの中で発生するまで(たとえば、復号可能であるが、正しく復号可能ではない)CL-RASピクチャであり得る。そのようなEL IRAPピクチャがビットストリーム中で与えられるとき、ELは初期化されたと言われることがある。
たとえば、図4の例では、ELピクチャ422AはIRAPピクチャではないLIPピクチャであってよく、BLピクチャ422Bはそれと関連付けられたフラグNoClRasOutputFlagを有するIRAPピクチャであってよい。この例では、ELピクチャ422Aと関連付けられたNoOutputOfPriorPicsFlagの値は、BLピクチャ422Bと関連付けられたNoClRasOutputFlagの値に基づいて推測され得る。たとえば、NoClRasOutputFlagが「1」という値に等しい場合、ELピクチャ422Aに対するNoOutputOfPriorPicsFlagも、「1」という値に設定されてよく、これにより、DPBの中のピクチャは、DPBから除去される前に出力されないようになる。一方、NoClRasOutputFlagが「0」という値に等しい場合、ELピクチャ422Aに対するNoOutputOfPriorPicsFlagも、「0」という値に設定されてよく、これにより、DPBの中のピクチャは、出力の後でDPBから除去されるようになる。
マルチレイヤビットストリームのための改善されたピクチャのフラッシングおよびDPBパラメータの推測
IRAPピクチャは、ビットストリームを復号するためのランダムアクセスポイントを提供し得る。デコーダは、IRAPピクチャに先行するピクチャを復号する必要なく、IRAPピクチャを復号することによってビットストリームを復号することを開始し得る。IRAPピクチャを復号する時点で、DPBは、バッファ中にいくつかの復号されたピクチャを有し得る。DPB中の既存のピクチャを出力することが、デコーダの性能に影響を与える(たとえば、デコーダが出力すべきあまりに多くのピクチャがDPB中に存在する、すべてのピクチャを出力するとフレームレートが不均等になり得る、など)場合、そのような既存のピクチャを、それらを出力することなく除去する(たとえば、既存のピクチャをフラッシュする)のが望ましいことがある。
変数NoOutputOfPriorPicsFlagは、IRAPピクチャを復号するとき、DPB中のピクチャが、DPBから除去されるより前に出力されるべきであるかどうかを示し得る。たとえば、IRAPピクチャを復号するとき、NoOutputOfPriorPicsFlagの値は、DPB中のピクチャが削除される前に出力されるべきではないとき、1に設定され得る。NoOutputOfPriorPicsFlagの値は、対応するシンタックス要素ならびに/または様々な条件および情報に基づいて決定され得る。たとえば、NoOutputOfPriorPicsFlagの値は、少なくとも変数NoRaslOutputFlagおよび/または変数NoClrasOutputFlagに基づいて決定され得る。変数NoRaslOutputFlagは、現在のアクセスユニットにおいて新たなコーディングされたビデオシーケンス(CVS)が開始するかどうかを示し得る。変数NoClrasOutputFlagは、現在のアクセスユニットにおいて、たとえばすべてのレイヤにわたって予測境界が存在するかどうかを示し得る。
SHVCおよびMV-HEVC(たとえば、MV-HEVCのワーキングドラフト7、およびワーキングドラフト5に続くSHVCのワーキングドラフトに反映されることにもなる)のより前のバージョンの開発および/または議論では、複数のレイヤまたは複数のビューがビットストリーム中に存在するとき、フラッシング処理が各レイヤに対して呼び出される。たとえば、ビットストリーム中のアクセスユニットauAが、1に等しいNoRaslOutputFlagを有するIRAPピクチャであるベースレイヤピクチャを有し、1に等しいNoClRasOutputFlagを有するとき、ベースレイヤ中のIRAPピクチャ、およびエンハンスメントレイヤのピクチャのための、NoOutputOfPriorPicsFlagのそれぞれの値が導出される。復号順序でアクセスユニットauAに先行するピクチャが次いで、フラッシュされる。この処理の間、ピクチャは、それぞれのレイヤに対して導出されたNoOutputOfPriorPicsFlagの値に基づいて出力され得る。復号されるべきレイヤのリスト(たとえば、TargetDecLayerIdList)中のレイヤに属するピクチャをアクセスユニットauAが有しない場合、復号順序においてアクセスユニットauAに先行するピクチャは、それらが「参照のために使用されない」ものとして標識されているとしても、フラッシュされない。これは、特定のレイヤのためのピクチャが現在のAU中にあるときにだけ、フラッシュがトリガされ得るからである。これらの残り続けるピクチャは、DPBメモリを使用することになり、後続のピクチャを復号するときにバッファのオーバーフローをもたらし得る。
これらおよび他の課題に対処するために、いくつかの態様による技法は、AUが特定のレイヤ中のピクチャを含まない可能性があるときであっても、異なるレイヤのDPB中のピクチャを適切にフラッシュするためのいくつかの方法および/または実施形態を提供することができる。たとえば、すべてのレイヤに対するDPBのフラッシングは、ベースレイヤがいくつかの条件を満たすかどうかに基づいてトリガされ得る。一例では、すべてのレイヤのためのDPBのフラッシングは、ベースレイヤピクチャが、新たなCVSを開始し(たとえば、NoRaslOutputFlag = 1)、新たなVPSを有効にし、または予測境界を画定する(たとえば、NoClRasOutputFlag = 1)、IRAPピクチャであるときに、トリガされ得る。ベースレイヤピクチャに基づいてすべてのレイヤのフラッシングをトリガすることによって、本技法は、あるAU中の特定のレイヤがピクチャを有しない場合であっても、そのAU中のすべてのレイヤに対するフラッシングを呼び出すことができる。
加えて、SHVCおよびMV-HEVCのより前のバージョン(たとえば、SHVCのワーキングドラフト5およびMV-HEVCのワーキングドラフト7)では、任意のHEVCビットストリームまたは任意のSHVC/MV-HEVCビットストリームが、Annex Aにおける1つまたは複数のプロファイルおよびAnnex GまたはHにおける1つまたは複数のプロファイルに準拠する。たとえば、HEVCビットストリームはAnnex Aにおけるプロファイルに準拠する。SHVC/MV-HEVCビットストリームは、Annex GまたはHにおけるプロファイルに準拠し、SHVC/MV-HEVCビットストリーム中のベースレイヤは一般に、後方互換性のためにAnnex Aにも準拠する。加えて、SHVC/MV-HEVCビットストリーム自体も、Annex Aにおけるプロファイルに準拠し得る。したがって、ビットストリームが規格においてこれらのAnnexを使用して復号されるとき、使用されるべきDPBパラメータは、曖昧であるかまたは利用不可能であるかのいずれかである。その上、VPS拡張においてシグナリングされるDPBパラメータは、0番目の出力レイヤセットに対してシグナリングも推測もされず、このレイヤセットはベースレイヤだけを備え、ベースレイヤピクチャだけが出力される。
これらおよび他の課題に対処するために、いくつかの態様による技法は、ベースレイヤの有効SPS中の様々な属性を、それらの様々な属性に対して許可される対応する最大値と等しく設定することができる。たとえば、SPSは、MaxLayerDecPicBuffMinus1、MaxNumReorderPics、MaxLatencyIncreasePlus1、MaxLatencyPictures、およびMaxDecPicBufferingMinus1のような、様々なDPBパラメータを含み得る。または、様々な属性の最大値は、有効SPSの様々な属性の値に等しく設定される。有効SPSの様々な属性の値を、それらの様々な属性に対して許可される最大値に等しく設定することによって、本技法は、適用されることになるDPBパラメータの曖昧さまたは利用不可能性を低減し、またはなくすことができる。
マルチレイヤビットストリームのためのピクチャのフラッシングおよびDPBパラメータの推測に関するいくつかの詳細が、以下でさらに説明される。本開示全体にわたって使用される様々な用語は、それらの通常の意味を有する広義の用語である。加えて、いくつかの実施形態では、いくつかの用語は以下のビデオの概念に関する。コーディングされたビデオシーケンスは、復号順序で、初期IRAPアクセスユニットとそれに続く初期IRAPアクセスユニットではない0個以上のアクセスユニットとを含む、アクセスユニットのシーケンスを指すことがあり、この0個以上のアクセスユニットは、初期IRAPアクセスユニットである任意の後続のアクセスユニットまでの、しかしそれを含まないすべての後続のアクセスユニットを含む。予測境界は、復号順序でピクチャ(picA)以降にある任意のピクチャが復号順序でピクチャ(picA)よりも前にあるいずれのピクチャも参照しないようなピクチャ(picA)、または、復号順序でピクチャ(picA)よりも前にあるピクチャが利用不可能であるピクチャ(picA)を指し得る。いくつかの態様によれば、現在のAUにおいて予測境界を画定することは、現在のAUの中のすべてのレイヤにわたって予測境界を画定することを指し得る。たとえば、参照レイヤ中のIRAPピクチャが現在のAUにおいて予測境界を画定する場合、参照レイヤIRAPピクチャは、AUの中のすべてのレイヤにわたって予測境界を画定し、現在のAUの中のピクチャは現在のAUの前のいずれのピクチャも参照しなくてよい。いくつかの場合、接合点は予測境界の例であり得る。外部とは、エンコーダまたはデコーダの一部ではないが、たとえばアプリケーションプログラミングインターフェース(API)を通じてエンコーダまたはデコーダと対話する、任意の装置またはエンティティを指し得る。いくつかの実施形態では、外部とは外部の装置とも呼ばれ得る。
マルチレイヤビットストリームのためのピクチャのフラッシング
いくつかの態様による技法は、説明されるようなIRAPピクチャのためのピクチャのフラッシングのいくつかの実施形態を提供することができる。本開示において説明されるすべての実施形態は、別々に、または互いに組み合わせて実装され得る。追加のシグナリングが、限定はされないがビデオVPS、SPS、およびPPSを含むビットストリーム中の様々なパラメータセットに含まれてよく、スライスヘッダまたはSEIメッセージにも含まれてよく、また外部の手段によって規定されてもよい。
実施形態1
1に等しいNoRaslOutputFlagを有するベースレイヤIRAPピクチャが新たなVPSを有効にする場合、または1に等しいNoClrasOutputFlagを有する場合、フラッシング動作の間のピクチャ除去の処理はすべてのレイヤに適用される。第1の値(たとえば、0または1)に等しいNoRaslOutputFlagを有するベースレイヤIRAPピクチャが新たなVPSを有効にせず、0に等しいNoClrasOutputFlagを有する場合、フラッシング動作の間のピクチャ除去の処理はベースレイヤピクチャだけに適用される。
この実施形態では、新たなCVSを開始するベースレイヤIRAPピクチャが新たなVPSを有効にするとき、または現在のAUにおいて予測境界を画定するとき、フラッシング動作の間のピクチャ除去の処理はすべてのレイヤに適用される。新たなCVSを開始するベースレイヤIRAPピクチャが新たなVPSを有効にせず、現在のAUにおいて予測境界を画定しないとき、フラッシング動作の間のピクチャ除去の処理はベースレイヤピクチャだけに適用される。
このようにして、DPBのフラッシングは、各レイヤに対して別々にトリガされる代わりに、ベースレイヤIRAPピクチャと、NoRaslOutputFlagおよびNoClrasOutputFlagのようなベースレイヤIRAPピクチャと関連付けられる変数の値とに基づいて、すべてのレイヤに対してトリガされる。以前の手法では、フラッシングは特定のレイヤにおけるピクチャの存在に基づいてトリガされていた。ピクチャの除去とピクチャの出力を別々に扱うことができ、これによりフラッシング処理を簡単にできる。
実施形態2
NoOutputOfPriorPicsFlagに関する処理が、ビットストリーム中の最下位レイヤのために定義され、NoOutputOfPriorPicsFlagの値が、デコーダへと外部的に提供され、または導出され得る。
- たとえば、実施形態1は、「1に等しいNoRaslOutputFlagを有する最下位レイヤIRAPピクチャが新たなVPSを有効にする場合、または1に等しいNoClrasOutputFlagを有する場合、フラッシング動作の間のピクチャ除去の処理はすべてのレイヤに適用される。」ことを示すように変更され得る。第1の値(たとえば、0または1)に等しいNoRaslOutputFlagを有する最下位レイヤIRAPピクチャが新たなVPSを有効にせず、0に等しいNoClrasOutputFlagを有する場合、フラッシング動作の間のピクチャ除去の処理は最下位レイヤピクチャだけに適用される。
この実施形態は、上の実施形態1と組み合わせて実装され得る。実施形態1は、ベースレイヤIRAPピクチャを参照して上で説明されるが、実施形態2は、ベースレイヤではない可能性のある最下位レイヤへと実施形態1の技法を拡張することができる。最下位レイヤは、現在のAUの中で最小のレイヤIDを有するレイヤを指し得る。変数nuh_layer_idは、レイヤのレイヤIDを指し得る。たとえば、ベースレイヤのレイヤIDは0である。ベースレイヤピクチャ(レイヤ0)を有しないが、レイヤ1ピクチャおよびレイヤ2ピクチャを有するビットストリームでは、ピクチャのフラッシング処理は、ピクチャが0ではない最小のレイヤIDを有し最下位レイヤであるので、レイヤ1に基づいてトリガされる。
この実施形態は、現在のAUがベースレイヤピクチャを有しないが他のレイヤ中のピクチャを有する状況に対応できる。そのような事例は、ベースレイヤの復号されたピクチャが外部に提供されるとき、ベースレイヤが異なるコーデックもしくは規格を使用して復号され得るとき、またはビットストリーム中の最下位レイヤが独立に復号可能なレイヤであるときに発生し得る。したがって、フラッシング処理は、より柔軟になり、様々なタイプのビットストリームおよび接合シナリオをサポートし得る。いくつかの実施形態では、NoOutputOfPriorPicsFlagの値が外部の手段または外部の装置によって提供される。たとえば、外部の手段または外部の装置は、ベースレイヤを復号し、NoOutputOfPriorPicsFlagの値を決定することができる。
実施形態3
NoOutputOfPriorPicsFlagは、0よりも大きなnuh_layer_idを有するピクチャに対して導出されない。
- 代替的に、NoOutputOfPriorPicsFlagは、任意の従属レイヤに属するピクチャに対しては導出されず、NoOutputOfPriorPicsFlagは、独立レイヤに属するピクチャに対して導出される。
この実施形態では、NoOutputOfPriorPicsFlagの値は、0(たとえば、ベースレイヤ)よりも大きなレイヤIDを有するピクチャに対しては導出されない。たとえば、NoOutputOfPriorPicsFlagの値は、ベースレイヤ中のピクチャだけに対して導出される。多くの場合、ベースレイヤ(たとえば、0に等しいnuh_layer_idを有するレイヤ)は、すべての他のレイヤが従属するレイヤである。そのような場合、0よりも大きなnuh_layer_idを有するレイヤのためにNoOutputOfPriorPicsFlagの値を導出するという決定は、NoOutputOfPriorPicsFlagがベースレイヤのために導出されたときにそのアクセスユニットと関連付けられる出力動作または非出力動作が実行されたであろうから、有用ではないことがある。0よりも大きなnuh_layer__idを有するレイヤのためにNoOutputOfPriorPicsFlagの値を導出しないことで、デコーダの動作を減らすことができる。
または、NoOutputOfPriorPicsFlagは、従属レイヤからのピクチャに対しては導出されない。NoOutputOfPriorPicsFlagは、独立レイヤからのピクチャに対して導出される。従属レイヤは、参照のために別のレイヤからのピクチャを使用し得るピクチャを含むレイヤを指し得る。いくつかの場合、従属レイヤは、VPSにおいてシグナリングされるレイヤの従属性情報に基づいて示されるレイヤであり得る。独立レイヤは、参照のために別のレイヤからのピクチャを使用しないことがあるレイヤを指し得る。
実施形態4
アクセスユニットauAが、1に等しいNoRaslOutputFlagおよび1に等しいNoClrasOutputFlagを有するIRAPであるベースレイヤピクチャを含むとき、復号順序でこのauAに先行するDPB中のすべてのピクチャが、auA中のベースレイヤピクチャのNoOutputOfPriorPicsFlagの値に依存して出力され、次いでDPBからフラッシュされる。
この実施形態では、現在のAU中のベースレイヤIRAPピクチャが新たなCVSを開始し、現在のAUにおいて予測境界を画定するとき、復号順序で現在のAUに先行するDPB中のすべてのピクチャがベースレイヤIRAPピクチャのNoOutputOfPriorPicsFlagの値に基づいて出力され、次いでDPBからフラッシュされる。現在のAUが新たなCVSを開始し、現在のAUにおいて予測境界を画定するときに、ベースレイヤIRAPピクチャにおけるNoOutputOfPriorPicsFlagの値に基づいて任意のレイヤの出力の決定を行うことによって、すべてのレイヤの中の現在のAUに先行するピクチャは、現在のAUが特定のレイヤにおけるピクチャを有しない場合でも処理されることがある(たとえば、出力されることがある、または出力されないことがある)。
実施形態5
1に等しいNoRaslOutputFlagを有するベースレイヤ中のIRAPピクチャに先行する、「出力のために必要とされる」ものとして標識されるすべてのピクチャが、NoOutputOfPriorPicsFlagの値が出力順序に従うデコーダにおいて0に等しい場合に出力される。
この実施形態では、ベースレイヤIRAPピクチャが現在のAUにおいて予測境界を画定するとき、ベースレイヤIRAPピクチャに先行する「出力のために必要とされる」ものとして標識されるすべてのピクチャが、NoOutputOfPriorPicsFlagの値が0に等しい場合に出力される(たとえば、前のピクチャが出力されるべきである)。この実施形態は、出力順序に従うデコーダに適用されるが、出力時間に従うデコーダのような他のタイプのデコーダにも拡張され得る。この実施形態の利点は、上の実施形態の利点と同様であり得る。
実施形態6
アクセスユニットauAが、1に等しいNoRaslOutputFlagおよび1に等しいNoClrasOutputFlagを有するIRAPであるベースレイヤピクチャを含むとき、復号順序でこのauAに先行するDPB中のすべてのピクチャが、出力されることなくフラッシュされる。
この実施形態では、現在のAU中のベースレイヤIRAPピクチャが新たなCVSを開始し、予測境界を画定するとき、現在のAUに先行するDPB中のすべてのピクチャが、出力されることなくフラッシュされる。この実施形態の利点は、上の実施形態の利点と同様であり得る。
実施形態7
アクセスユニット(AU)が1に等しいNoRaslOutputFlagおよび1に等しいNoClrasOutputFlagを有するIRAPであるベースレイヤピクチャを含むとき、復号順序でこのAUに先行するDPB中のエンハンスメントレイヤ中のすべてのピクチャが、出力されることなくフラッシュされ、復号順序でアクセスユニットに先行するベースレイヤ中のピクチャが、ベースレイヤピクチャのNoOutputOfPriorPicsFlagの値に依存して最初に出力され、次いでフラッシュされる。
この実施形態では、現在のAU中のベースレイヤIRAPピクチャが新たなCVSを開始し、予測境界を画定するとき、復号順序で現在のAUに先行するDPBの中のエンハンスメントレイヤ中のすべてのピクチャが、出力されることなく除去され、復号順序で現在のAUに先行するベースレイヤ中のピクチャが、NoOutputOfPriorPicsFlagの値に基づいて出力され、次いで除去される。
実施形態8
アクセスユニット(AU)auAが1に等しいNoRaslOutputFlagおよび1に等しいNoClrasOutputFlagを有するIRAPであるベースレイヤピクチャを含むとき、復号順序でこのAUに先行し、アクセスユニットauA中のピクチャを有しないエンハンスメントレイヤに含まれるすべてのピクチャが、出力されることなくフラッシュされ、復号順序でアクセスユニットauAに先行し、アクセスユニットauA中のピクチャを有するレイヤに属するピクチャが、対応するレイヤのNoOutputOfPriorPicsFlagの値に依存して最初に出力され、次いでフラッシュされる。
この実施形態では、現在のAU中のベースレイヤIRAPピクチャが新たなCVSを開始し、予測境界を画定するとき、復号順序で現在のAUに先行し、現在のAU中のピクチャを有しないエンハンスメントレイヤに属するすべてのピクチャが、出力されることなく除去され、復号順序で現在のAUに先行し、現在のAU中のピクチャを有するレイヤに属するピクチャが、NoOutputOfPriorPicsFlagの値に基づいて出力され、次いで除去される。
実施形態9
シンタックス要素no_output_of_prior_pics_flagは、0よりも大きなnuh_layer_idを有するピクチャに対してシグナリングされない。
この実施形態では、シンタックス要素no_output_of_prior_pics_flagは、ベースレイヤ中にないピクチャに対してはシグナリングされない。シンタックス要素no_output_of_prior_pics_flagは、変数NoOutputOfPriorPicsFlagの値を示し得る。実施形態に応じて、NoOutputOfPriorPicsFlagの値は、シンタックス要素no_output_of_prior_pics_flagの値に等しく設定され、または、様々な条件および/またはアルゴリズムに基づいて、導出もしくは推測され得る。ピクチャを送信するために使用されるビットの数は、ベースレイヤに属しないピクチャのためにシンタックス要素no_output_of_prior_pics_flagをシグナリングしないことによって、減らされ得る。
実施形態10
シンタックス要素no_output_of_prior_pics_flagは、従属レイヤに属するピクチャに対してはシグナリングされない。
この実施形態では、シンタックス要素no_output_of_prior_pics_flagは、従属レイヤ、たとえば他のレイヤを参照するレイヤに属するピクチャに対してはシグナリングされない。ピクチャを送信するために使用されるビットの数は、従属レイヤに属するピクチャのためにシンタックス要素no_output_of_prior_pics_flagをシグナリングしないことによって、減らされ得る。
実施形態11
シンタックス要素no_output_of_prior_pics_flagは、直接の参照レイヤを有しないエンハンスメントレイヤピクチャのみにおいてシグナリングされる。
- 別の代替形態では、シンタックス要素no_output_of_prior_pics_flagはすべてのIRAPピクチャにおいてシグナリングされ、no_output_of_prior_pics_flagの値はアクセスユニット中のすべてのIRAPピクチャにわたって同じであるように制限される。
- 別の代替形態では、NoOutputOfPriorPicsFlagの値は、導出され、推測され、または外部的に提供されるとき、アクセスユニット中のすべてのピクチャにわたって同じであるように制限される。
この実施形態では、シンタックス要素no_output_of_prior_pics_flagは、直接の参照レイヤを有しないエンハンスメントレイヤピクチャのみにおいてシグナリングされる。または、シンタックス要素no_output_of_prior_pics_flagはすべてのIRAPピクチャにおいてシグナリングされ、no_output_of_prior_pics_flagの値はAU中のすべてのIRAPピクチャにわたって同じであるように制限される。または、NoOutputOfPriorPicsFlagの値が、導出され、推測され、または外部的に提供されるとき、NoOutputOfPriorPicsFlagの値は、AU中のすべてのピクチャにわたって同じであるように制限される。ピクチャを送信するために使用されるビットの数は、NoOutputOfPriorPicsFlagの値が導出されないレイヤに属するピクチャのためにシンタックス要素no_output_of_prior_pics_flagをシグナリングしないことによって、減らされ得る。
IRAPピクチャのためのピクチャのフラッシングの追加の実施形態が以下で与えられる。以下の実施形態は各々、上で説明された実施形態の詳細な実装であり得る。例示的な実施形態は、SHVCおよびMV-HEVC(たとえば、SHVC WD5および/またはMV-HEVC WD7)の以前のバージョンの状況において与えられる。SHVCおよびMV-HEVCの以前のバージョンへの追加は、斜体で示されており、MV-HEVCの以前のバージョンからの削除は、取消線で示されている。セクションC.3.2は、MV-HEVC WD7におけるピクチャ除去に対する出力タイミングDPB動作を説明する。セクションC.5.2.2は、MV-HEVC WD7におけるピクチャ除去に対する出力順序DPB動作を説明する。同様または同一の概念および/またはテキストがSHVCに適用可能であり、WD 5に続くSHVCのワーキングドラフトにおいて反映されており、または反映されることになる。したがって、例示的な実施形態はSHVCにも適用可能である。
例示的な実施形態A
例示的な実施形態Aは、上の実施形態1に関し、実施形態1の詳細の実装であり得る。この実施形態では、ピクチャのフラッシングは、ベースレイヤIRAPピクチャだけに対して呼び出される。出力順序に従うデコーダでは、NoOutputOfPriorPicsFlagが0に等しいとき、すべてのサブDPB中のすべてのピクチャが出力される。サブDPBは、個々のレイヤと関連付けられるDPBを指し得る。サブDPBは、個々のレイヤと関連付けられるDPBのピクチャ記憶バッファを含み得る。たとえば、ベースレイヤはDPB内にサブDPBを有することがあり、対応するエンハンスメントレイヤもDPB内にサブDPBを有することがある。出力順序に従うデコーダと出力タイミングに従うデコーダの両方において、ベースレイヤピクチャが1に等しいNoClrasOutputFlagを有し、または新たなVPSを有効にするとき、すべてのサブDPBからのすべてのピクチャが、NoOutputOfPriorPicsFlagに基づいて出力の挙動を決定した後に除去される。出力順序に従うデコーダと出力タイミングに従うデコーダの両方において、ベースレイヤピクチャが0に等しいNoClrasOutputFlagを有し、新たなVPSを有効にしないとき、0に等しいnuh_layer_idを有するすべてのピクチャが、NoOutputOfPriorPicsFlagに基づいて出力の挙動を決定した後に除去される。
代替的に、上の実施形態2に関して説明されたように、出力順序に従うデコーダと出力タイミングに従うデコーダの両方に対して、実施形態Aにおいて説明されたNoOutputOfPriorPicsFlagに関する処理は、ベースレイヤ中のピクチャではなく、ビットストリーム中の最下位レイヤ(たとえば、最小のnuh_layer_idを有するビットストリーム中のレイヤ)中のピクチャに適用され、NoOutputOfPriorPicsFlagの値はデコーダへと外部的に提供され得る。
例示的な実施形態B
この実施形態では、NoOutputOfPriorPicsFlagの値が、1に等しいNoClrasOutputFlagを有するベースレイヤIRAPピクチャを復号した後で各レイヤにおいて復号されるべき最初のピクチャであるエンハンスメント非IRAPピクチャのために導出されるように、SHVCおよびMV-HEVCの前のバージョンが変更される。この実施形態は、SHVC/MV-HEVCの既存の設計を保つことができ、ベースレイヤIRAPピクチャを有しないアクセスユニットにおけるピクチャを含まないエンハンスメントレイヤからのピクチャの除去の問題について、エンハンスメントレイヤ中の次のピクチャが存在するときにその除去を呼び出すことによって、対処することができる。
例示的な実施形態C
例示的な実施形態Cは、上の実施形態6に関し、実施形態6の詳細の実装であり得る。この実施形態では、ベースレイヤIRAPピクチャが新たなCVSを開始し、予測境界を画定するとき、DPB中のすべてのピクチャが、出力されることなくフラッシュされる。
例示的な実施形態D
この実施形態では、フラッシング動作はレイヤにまたがって実行され、ベースレイヤピクチャが新たなCVSを開始するときに発生する。出力かまたは非出力かの決定も、ベースレイヤピクチャにおいて行われる。
マルチレイヤビットストリームのためのピクチャのフラッシングの方法
図5は、本開示の一実施形態による、ビデオ情報をコーディングする方法を示すフローチャートである。方法は、マルチレイヤビットストリームのためのピクチャのバッファリングに関する。実施形態に応じて、処理500は、エンコーダ(たとえば、図2A、図2Bなどに示されるようなエンコーダ)、デコーダ(たとえば、図3A、図3Bなどに示されるようなデコーダ)、または任意の他のコンポーネントによって実行され得る。処理500のブロックが、図3Bのデコーダ33に関して説明されるが、処理500は、上で言及されたように、エンコーダのような他のコンポーネントによって実行され得る。実施形態に応じて、デコーダ33のレイヤ1ビデオデコーダ30Bおよび/またはデコーダ33のレイヤ0デコーダ30Aが、処理500を実行し得る。図5に関して説明されるすべての実施形態は、別々に、または互いに組み合わせて実装され得る。処理500に関するいくつかの詳細が、たとえば、図4に関して上で説明されている。
処理500はブロック501において開始する。デコーダ33は、参照レイヤを含む複数のレイヤと関連付けられるビデオ情報を記憶するためのメモリ(たとえば、復号ピクチャバッファ160)を含み得る。メモリは、各レイヤと関連付けられるDPBを含み得る。いくつかの実施形態では、各レイヤと関連付けられるDPBはサブDPBと呼ばれることがあり、DPBの一部として含まれることがある。
ブロック502において、デコーダ33は、参照レイヤから、コーディングされるべき現在のアクセスユニット(AU)中のIRAPピクチャを取得する。いくつかの実施形態では、参照レイヤはベースレイヤである。他の実施形態では、参照レイヤは、ベースレイヤ以外の、複数のレイヤのうちの最下位レイヤであり、現在のAUはその最下位レイヤからのピクチャを含む。現在のAUは、ベースレイヤ中のピクチャを含まないことがある。
ブロック503において、参照レイヤIRAPピクチャが新たなCVSを開始すると決定したことに応答して、ブロック504において、デコーダ33は、参照レイヤIRAPピクチャが新たなビデオパラメータセット(VPS)を有効にするかどうか、または現在のAUにおいて予測境界を画定するかどうかを決定する。ブロック505において、参照レイヤIRAPピクチャが新たなビデオパラメータセット(VPS)を有効にすると決定したこと、または、参照レイヤIRAPピクチャが現在のAUにおいて予測境界を画定すると決定したことに応答して、ブロック506において、デコーダ33は、複数のレイヤの各々と関連付けられるDPB中のピクチャを除去する。ブロック505において、参照レイヤIRAPピクチャが新たなVPSを有効にしないと決定したこと、および、参照レイヤIRAPピクチャが現在のAUにおいて予測境界を画定しないと決定したことに応答して、ブロック507において、デコーダ33は、参照レイヤと関連付けられるDPB中のピクチャだけを除去する。ブロック503において参照レイヤIRAPピクチャが新たなCVSを開始しない場合、処理500はブロック508において終わる。
いくつかの実施形態では、デコーダ33は、DPB中のピクチャを出力するかどうかを示す第1のフラグの値を決定し、この決定は、ベースレイヤである参照レイヤ中のピクチャだけのために実行される。第1のフラグは、NoOutputOfPriorPicsFlagであり得る。いくつかの実施形態では、デコーダ33は、DPB中のピクチャを出力するかどうかを示す第1のフラグの値を決定し、この決定は、複数のレイヤのうちの独立レイヤ中のピクチャに対して実行されるが、複数のレイヤのうちの従属レイヤ中のピクチャに対しては実行されない。他の実施形態では、参照レイヤIRAPピクチャが新たなCVSを開始し、現在のAUにおいて予測境界を画定すると決定したことに応答して、デコーダ33は、DPB中のピクチャを出力するかどうかを示す、参照IRAPピクチャと関連付けられる第1のフラグの値を決定し、DPB中のピクチャが出力されるべきであることを第1のフラグの値が示すと決定したことに応答して、複数のレイヤと関連付けられる、DPBにおいて復号順序で現在のAUに先行するピクチャを出力し、複数のレイヤと関連付けられる、DPBにおいて復号順序で現在のAUに先行するピクチャを除去する。
一実施形態では、デコーダ33は、DPB中のピクチャを出力するかどうかを示す、参照IRAPピクチャと関連付けられる第1のフラグの値を決定し、DPB中のピクチャが出力されるべきであることと、参照レイヤIRAPピクチャが新たなCVSを開始することとを第1のフラグの値が示すと決定したことに応答して、参照レイヤIRAPピクチャに先行するピクチャを出力する。この実施形態では、デコーダ33は出力順序に従うデコーダであり得る。
いくつかの実施形態では、デコーダ33は、DPB中のピクチャを出力するかどうかを示す、参照レイヤIRAPピクチャと関連付けられる第1のフラグの値に基づいて、複数のレイヤと関連付けられるDPBにおいて除去されるべきピクチャを出力する。たとえば、DPB中のピクチャが出力されるべきであることを第1のフラグの値が示すと決定したことに応答して、デコーダ33は、除去されるべきピクチャを除去する前に、複数のレイヤと関連付けられるDPB中の除去されるべきピクチャを出力する。上で言及されたように、異なる実施形態では第1のフラグはNoOutputOfPriorPicsFlagを指し得る。
処理は、ブロック508において終了する。実施形態に応じて、ブロックが処理500において追加および/または省略されてよく、実施形態に応じて、処理500のブロックは異なる順序で実行されてよい。
本開示におけるマルチレイヤビットストリームのためのピクチャのフラッシングに関して説明された任意の特徴および/または実施形態が、別々に、またはそれらの任意の組合せで実装され得る。たとえば、図1〜図4に関して説明された任意の特徴および/または実施形態、ならびに本開示の他の部分が、図5に関して説明された任意の特徴および/または実施形態との任意の組合せで実装されてよく、その逆も同様である。
マルチレイヤビットストリームのためのDPBパラメータの推測
SHVCまたはMV-HEVCビットストリームのようなマルチレイヤビットストリームは、Annex Aにおける1つまたは複数のプロファイル、さらにはAnnex GまたはHにおける1つまたは複数のプロファイルに準拠する。SHVC規格および/またはMV-HEVC規格におけるいくつかのDPBパラメータは、ビットストリームを復号するために使用されるプロファイルをどのAnnexが含むかに基づいて、導出または推測され得る。MV-HEVC規格(たとえば、ワーキングドラフト5に続くSHVCのワーキングドラフトにおいても反映される、または反映されることになる、MV-HEVCのワーキングドラフト7)のAnnex Cにおける以下の段落を考える。以下の段落は、MaxLayerDecPicBuffMinus1、MaxNumReorderPics、MaxLatencyIncreasePlus1、MaxLatencyPictures、およびMaxDecPicBufferingMinus1のような、様々な変数を記述する。
以下の段落はC.1項からのものである。
以下の段落はC.5.2.1項からのものである。
任意のHEVCビットストリームまたは任意のSHVC/MV-HEVCビットストリームが、Annex Aにおける1つまたは複数のプロファイルおよびAnnex GまたはHにおける1つまたは複数のプロファイルに準拠する。上の項が適用されるとき、DPBパラメータの値は曖昧であるかまたは利用不可能である。その上、VPS拡張においてシグナリングされるDPBパラメータは、0番目の出力レイヤセットに対してシグナリングも推測もされず、このレイヤセットはベースレイヤだけを備え、ベースレイヤピクチャだけが出力される。
例示的な実施形態E
いくつかの態様によれば、0番目の出力レイヤセットのためのMaxLayerDecPicBuffMinus1、MaxNumReorderPics、MaxLatencyIncreasePlus1、MaxLatencyPicturesおよびMaxDecPicBufferingMinus1の値を、ベースレイヤの有効SPSのためにシグナリングされる値と等しいものとして推測することで十分である。Annex Cにおいてこれらの推測される値を参照するだけで、曖昧さをなくすことができる。
例示的な実施形態Eにおいて、Annex C、C.1項において0番目の出力レイヤセットのDPBパラメータと関連付けられる変数の値(たとえば、max_vps_dec_pic_buffering_minus1、max_vps_layer_dec_pic_buffering_minus1、およびmax_vps_latency_increase_plus1)は、有効SPSにおける対応する属性の値に等しく設定される。例示的な実施形態は、SHVCおよびMV-HEVC(たとえば、SHVC WD5およびMV-HEVC WD7)の以前のバージョンの状況において与えられる。SHVCおよびMV-HEVCの以前のバージョンへの追加は、斜体で示されており、SHVCおよびMV-HEVCの以前のバージョンからの削除は、取消線で示されている。同様または同一の概念および/またはテキストがSHVCに適用可能であり、WD 5に続くSHVCのワーキングドラフトにおいて反映されており、または反映されることになる。したがって、例示的な実施形態はSHVCにも適用可能である。例示的な実施形態Eでは、Annex C、C.1項において規定される変数の値は、有効SPSにおける対応する属性の値に等しく設定され、他の実施形態では、有効SPSにおける対応する属性の値は、Annex C、C.1項において規定される変数の値に等しく設定され得る。
本明細書で開示される情報および信号は、多種多様な技術および技法のいずれかを使用して表され得る。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。
本明細書で開示された実施形態に関して説明された様々な例示的な論理ブロック、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、全般にそれらの機能に関して上で説明された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、具体的な適用例およびシステム全体に課されるおよび設計上の制約に依存する。当業者は、説明された機能を具体的な適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じさせるものと解釈されるべきではない。
本明細書で説明された技術は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスのような、様々なデバイスのいずれかにおいて実装され得る。モジュールまたはコンポーネントとして説明された任意の特徴が、集積論理デバイス内で一緒に、または個別であるが相互動作可能な論理デバイスとして別々に実装され得る。ソフトウェアで実装された場合、本技法は、実行されると上で説明された方法の1つまたは複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含み得るコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリ、磁気または光学データ記憶媒体などのような、メモリまたはデータ記憶媒体を備え得る。本技法は、追加または代替として、伝搬される信号または波のような、命令またはデータ構造の形態でプログラムコードを搬送または伝達し、コンピュータによってアクセスされ、読み取られ、かつ/または実行され得る、コンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
プログラムコードは、1つまたは複数のデジタル信号プロセッサ(DSP)などの1つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPGA)、または他の等価の集積回路もしくはディスクリート論理回路を含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明された技法のいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替的に、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。したがって、本明細書で使用される「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明される技法の実装に適した他の構造もしくは装置のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用のソフトウェアモジュールもしくはハードウェアモジュール内で提供されてよく、または複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれてよい。また、本技法は、1つまたは複数の回路または論理要素において完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。様々なコンポーネント、モジュール、またはユニットは、開示された技法を実行するように構成されたデバイスの機能的態様を強調するように本開示において説明されているが、様々なハードウェアユニットによる実現を必ずしも必要としない。むしろ、上で説明されたように、様々なユニットが、適切なソフトウェアおよび/またはファームウェアとともに、上で説明された1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられ、または相互動作可能なハードウェアユニットの集合によって与えられ得る。
本開示の様々な実施形態が説明されてきた。これらおよび他の実施形態は、以下の特許請求の範囲内に入る。