[0020]一般に、本開示は、高効率ビデオコード化(HEVC)などの高度ビデオコーデックのコンテキストにおける、マルチレイヤビデオコード化のためのピクチャ順序カウント(POC)管理に関する。より具体的には、本開示は、SHVCと呼ばれる、HEVCのスケーラブルビデオコード化拡張におけるレイヤ間予測の実行を改善するためのシステム及び方法に関する。
[0021]スケーラブルビデオコード化は、参照レイヤ(RL:reference layer)と呼ばれることがあるベースレイヤ(BL:base layer)と、1つ又は複数のスケーラブル拡張レイヤ(EL:enhancement layer)とが使用されるビデオコード化を指す。スケーラブルビデオコード化では、BLは、ベースレベルの品質でビデオデータを搬送することができる。1つ又は複数のELは、例えば、より高い空間レベル、時間レベル、及び/又は信号対雑音比(SNR:signal-to-noise)レベルをサポートするために、追加のビデオデータを搬送することができる。ELは、前に符号化されたレイヤに対して定義され得る。例えば、最下位レイヤはBLとして働き得、最上位レイヤはELとして働き得る。中間レイヤは、EL又はRLのいずれか、若しくはその両方として働き得る。例えば、中間レイヤ(例えば、最下位レイヤでもなく最上位レイヤでもないレイヤ)は、BL又は介在ELなどの中間レイヤの下のレイヤのためのELであり得、同時に、中間レイヤの上の1つ又は複数のELのためのRLとして働き得る。同様に、HEVC規格のマルチビュー又は3D拡張では、複数のビューがあり得、1つのビューの情報は、別のビューの情報(例えば、動き推定、動きベクトル予測及び/又は他の冗長)をコード化(例えば、符号化又は復号)するために利用され得る。
[0022]幾つかの実装形態では、単一レイヤビットストリーム(例えば、ビデオ情報の1つのレイヤだけを含むビットストリーム)がマルチレイヤデコーダ(例えば、単一レイヤビットストリームを処理するように構成されるとともにマルチレイヤビットストリームを処理するように構成されるデコーダ)によって処理されるとき、マルチレイヤデコーダは、マルチレイヤデコーダが予想していることがある(即ち、マルチレイヤデコーダが受信及び処理するように構成される)幾つかの情報がビットストリームの中にないことに基づいて、単一レイヤビットストリームが非適合ビットストリーム(例えば、1つ又は複数の適用可能な規格に従って生成されていないビットストリーム)であると誤って決定する場合がある。例えば、マルチレイヤビットストリームは、同じアクセス単位の中にあるが、異なる最下位ビット(LSB)を有するピクチャ順序カウント(POC)値に関連したピクチャを含むことがある。通常、POC LSBのそのような非アライメントは、マルチレイヤビットストリームの中で提供されるフラグ(例えば、vps_poc_lsb_aligned_flag)によって示され得る。マルチレイヤデコーダは、マルチレイヤビットストリームが非整合POC LSBを含むと決定すると、マルチレイヤビットストリームの中で提供されるPOC値の1つ又は複数の最上位ビット(MSB)を処理するように構成され得る。マルチレイヤデコーダがマルチレイヤビットストリームの中(例えば、そのようなピクチャに関連したスライスセグメントヘッダ拡張の中)の予想される又は所定の位置においてPOC値のいかなるMSBも見つけない場合、マルチレイヤデコーダは、マルチレイヤビットストリームが適用可能なビデオコード化規格(例えば、スケーラブル高効率ビデオコード化(SHVC))に適合しないと正しく結論づけ得る。
[0023]一方、単一レイヤビットストリーム(例えば、1つのビデオレイヤだけを含むHEVC符号化ビットストリーム)は、ビットストリームが非整合POC LSBを含み得るかどうかを示す前述のフラグを通常は含むことになるビデオパラメータセット(VPS)拡張などの、HEVCへのスケーラビリティ拡張に関連するいかなる情報も含まないことがある。従って、そのような単一レイヤビットストリームを処理するとき、マルチレイヤデコーダは、ビットストリームが非整合POC LSBを含み得るかどうかを示すそのようなフラグがないことに基づいて、単一レイヤビットストリームが非整合POC LSBを含むことを仮定(即ち、決定)し得る。上記で説明したように、この決定に基づいて、マルチレイヤデコーダは、ビットストリームに含まれるPOC値の1つ又は複数のMSBを受信することを予想し得る。マルチレイヤデコーダが見つけようと求める(例えば、単一レイヤビットストリームに通常は含まれないスライスセグメントヘッダ拡張の中で提供され得る)POC値の1つ又は複数のMSBを単一レイヤビットストリームが含まないとマルチレイヤデコーダが決定するとき、たとえ単一レイヤビットストリームが実際は適合ビットストリーム(例えば、1つ又は複数の適用可能な規格に適合するビットストリーム)であり得ても、非整合POC LSBを含まずそのようにPOC値のMSBがその中で信号伝達されることを必要としない単一レイヤビットストリームが非適合ビットストリームであると、マルチレイヤデコーダは決定し得る。
[0024]従って、POC MSBがビットストリームの中に存在することを決定するための改善された方法が望まれる。
[0025]本開示では、POC MSBがビットストリームの中で信号伝達されているかどうかを決定(又は、推定)するための様々な技法が説明される。本開示の幾つかの実施例では、コーダは、スライスセグメントヘッダ拡張がビットストリームの中に存在することに基づいて、ピクチャに関連したPOC MSBがビットストリームの中で信号伝達されているかどうかを決定する。ピクチャに関連したPOC MSBがビットストリームの中で信号伝達されているかどうかという決定を、ピクチャに関連したスライスセグメントヘッダ拡張の存在に基づかせることによって、コーダは、単一レイヤビットストリームを処理するとき、POC MSBがビットストリームの中で信号伝達されているという誤った予想を回避することができる。
[0026]以下の説明では、幾つかの実施形態に関係するH.264/AVC技法が記載され、HEVC規格及び関係する技法も説明される。HEVC規格及び/又はH.264規格のコンテキストにおいて、幾つかの実施形態が本明細書に記載されるが、本明細書で開示されるシステム及び方法が任意の適切なビデオコード化規格に適用可能であり得ることを、当業者なら諒解されよう。例えば、本明細書で開示する実施形態は、(例えば、国際電気通信連合電気通信標準化部門[ITU−T]ビデオコード化エキスパートグループ[VCEG]又は国際標準化機構/国際電気標準会議[ISO/IEC]ムービングピクチャエキスパートグループ[MPEG]によって開発された規格を含む)次の規格、即ち、ITU−T H.261、ISO/IEC MPEG−1ビジュアル、ITU−T H.262若しくはISO/IEC MPEG−2ビジュアル、ITU−T H.263、ISO/IEC MPEG−4ビジュアル、及びそのスケーラブルビデオコード化(SVC)及びマルチビュービデオコード化(MVC)拡張を含むITU−T H.264(ISO/IEC MPEG−4 AVCとも呼ばれる)のうちの、1つ又は複数に適用可能であり得る。
[0027]HEVCは、概して、多くの点で、前のビデオコード化規格のフレームワークに従う。HEVCにおける予測の単位は、幾つかの前のビデオコード化規格における予測の単位(例えば、マクロブロック)とは異なる。事実上、マクロブロックの概念は、幾つかの前のビデオコード化規格において理解されているように、HEVC中に存在しない。マクロブロックは、他の考えられる利益の中でも高いフレキシビリティを与え得る、4分木方式に基づく階層構造と置き換えられる。例えば、HEVC方式内で、コード化単位(CU)、予測単位(PU:Prediction Unit)、及び変換単位(TU:Transform Unit)という3つのタイプのブロックが定義される。CUは領域分割の基本単位を指すことがある。CUはマクロブロックの概念に類似するとみなされてよいが、HEVCは、CUの最大サイズを制限せず、コンテンツ適応性を改善するために4つの等しいサイズのCUへの再帰的分割を可能にし得る。PUは、インター/イントラ予測の基本単位とみなされてよく、単一のPUは、不規則なイメージパターンを効率的にコード化するために、複数の任意形状区分を含み得る。TUは、変換の基本単位とみなされてよい。TUはPUとは無関係に定義され得るが、TUのサイズはTUが属するCUのサイズに限定されることがある。3つの異なる概念へのブロック構造のこの分離は、各単位がその単位のそれぞれの役割に従って最適化されることを可能にし得、このことはコード化効率の改善をもたらし得る。
[0028]単に説明の目的で、本明細書で開示する幾つかの実施形態は、ビデオデータの2つのレイヤ(例えば、BLのなどの下位レイヤ及びELなどの上位レイヤ)のみを含む例を用いて説明する。ビデオデータの「レイヤ」は、概して、ビュー、フレームレート、解像度などの、少なくとも1つの共通の特性を有するピクチャのシーケンスを指すことがある。例えば、レイヤは、マルチビュービデオデータの特定のビュー(例えば、視点)に関連したビデオデータを含み得る。別の例として、レイヤは、スケーラブルビデオデータの特定のレイヤに関連したビデオデータを含み得る。従って、本開示は、ビデオデータのレイヤ及びビューを互換的に指すことがある。例えば、ビデオデータのビューは、ビデオデータのレイヤと呼ばれることがあり、ビデオデータのレイヤは、ビデオデータのビューと呼ばれることがある。加えて、マルチレイヤコーデック(マルチレイヤビデオコーダ又はマルチレイヤエンコーダデコーダとも呼ばれる)は、マルチビューコーデック又はスケーラブルコーデック(例えば、MV−HEVC、3D−HEVC、SHVC、又は別のマルチレイヤコード化技法を使用してビデオデータを符号化及び/又は復号するように構成されるコーデック)を一緒に指すことがある。ビデオ符号化及びビデオ復号は、概して、両方ともビデオコード化と呼ばれることがある。そのような例が複数のBL、RL及び/又はELを含む構成に適用可能であり得ることを理解されたい。更に、説明を簡単にするために、以下の開示は、幾つかの実施形態に関して「フレーム」又は「ブロック」という用語を含む。しかしながら、これらの用語は、限定的であることを意味しない。例えば、以下で説明する技法は、ブロック(例えば、CU、PU、TU、マクロブロックなど)、スライス、フレームなどの、任意の適切なビデオ単位とともに使用され得る。
ビデオコード化規格
[0029]ビデオ画像、TV画像、静止画像、又はビデオレコーダ若しくはコンピュータによって生成された画像などの、デジタル画像は、水平ライン及び垂直ラインで構成された画素又はサンプルからなり得る。単一の画像中の画素の数は一般に数万個である。各画素は、一般に、ルミナンス情報とクロミナンス情報とを含んでいる。圧縮がなければ、画像エンコーダから画像デコーダに搬送されるべき情報の純粋な量は、リアルタイム画像伝送を不可能にすることになる。送信されるべき情報の量を低減するために、JPEG、MPEG及びH.263規格など、幾つかの異なる圧縮方法が開発された。
[0030]ビデオコード化規格は、ITU−T H.261と、ISO/IEC MPEG−1ビジュアルと、ITU−T H.262又はISO/IEC MPEG−2ビジュアルと、ITU−T H.263と、ISO/IEC MPEG−4ビジュアルと、それのスケーラブルビデオコード化(SVC)及びマルチビュービデオコード化(MVC)拡張を含む(ISO/IEC MPEG−4 AVCとも呼ばれる)ITU−T H.264とを含む。
[0031]更に、ビデオコード化規格、即ち、HEVCが、ITU−T VCEGとISO/IEC MPEGとのジョイントコラボレーションチームオンビデオコーディング(JCT−VC:Joint Collaboration Team on Video Coding)によって開発されている。HEVCドラフト10についての完全引用は、文書JCTVC−L1003、Brossら、「High Efficiency Video Coding(HEVC)Text Specification Draft 10」、ITU−T SG16 WP3及びISO/IEC JTC1/SC29/WG11のジョイントコラボレーティブチームオンビデオコーディング(JCT−VC)、第12回会合:ジュネーブ、スイス、2013年1月14日〜2013年1月23日である。HEVCへのマルチビュー拡張、即ち、MV−HEVC、及びSHVCと名付けられたHEVCへのスケーラブル拡張も、JCT−3V(ITU−T/ISO/IECジョイントコラボレーティブチームオン3Dビデオコード化拡張開発)及びJCT−VCによって、それぞれ開発されている。
ビデオコード化システム
[0032]新規のシステム、装置、及び方法の様々な態様は、これ以降、添付図面を参照しながら、より十分に説明される。しかしながら、本開示は、多くの異なる形態で実施可能であり、本開示の全体を通して示される任意の特定の構造又は機能に限定されるものと解釈されるべきでない。むしろ、本開示が、入念で完全であり、本開示の範囲を当業者に十分に伝達するように、これらの態様が提供される。本明細書の教示に基づいて、本開示の範囲は、本開示の他の態様と無関係に実装されるにせよ、本開示の他の態様と組み合わせて実装されるにせよ、本明細書で開示する新規のシステム、装置、及び方法のいかなる態様をもカバーするものであることを、当業者なら十分理解するであろう。例えば、本明細書に記載される任意の数の態様を使用して装置が実装されてよく、又は方法が実施されてもよい。更に、本開示の範囲は、本明細書に記載する本開示の様々な態様に加えて又はそれらの態様以外に、他の構造、機能、又は構造及び機能を使用して実施されるそのような装置又は方法をカバーするものとする。本明細書で開示する任意の態様は、特許請求の範囲の1つ又は複数の要素により実施されてもよいことを理解されたい。
[0033]特定の態様について本明細書で説明するが、これらの態様の多くの変形及び置換は本開示の範囲内に入る。好ましい態様の幾つかの利益及び利点が述べられるが、本開示の範囲は、特定の利益、使用、又は目的に限定されることを意図しない。むしろ、本開示の態様は、異なるワイヤレス技術、システム構成、ネットワーク、及び伝送プロトコルに広く適用可能なものであり、そのうちの幾つかが図面及び好ましい態様の以下の説明において例として示される。詳細な説明及び図面は、限定的ではなく、本開示の例示にすぎず、本開示の範囲は、添付の特許請求の範囲及びその均等物によって定義される。
[0034]添付の図面は、例を示す。添付の図面内で参照番号によって指示される要素は、以下の説明において同様の参照番号で指示される要素に対応する。本開示では、序数語(例えば、「第1の」、「第2の」、「第3の」など)で始まる名前を有する要素は、必ずしもそれらの要素が特定の順序を有することを暗示するとは限らない。むしろ、そのような序数語は、同じ又は同様のタイプの、異なる要素を指すために使用されるにすぎない。
[0035]図1Aは、本開示で説明する態様による技法を利用し得る例示的なビデオコード化システム10を示すブロック図である。本明細書で使用し説明する「ビデオコーダ」という用語は、総称的にビデオエンコーダとビデオデコーダの両方を指す。本開示では、「ビデオコード化」又は「コード化」という用語は、ビデオ符号化とビデオ復号とを総称的に指すことがある。ビデオエンコーダ及びビデオデコーダに加えて、本出願に記載される態様は、トランスコーダ(例えば、ビットストリームを復号し別のビットストリームを再符号化することができる機器)及びミドルボックス(例えば、ビットストリームを修正、変換、及び/又は別のやり方で操作することができる機器)などの、他の関係する機器に拡張され得る。
[0036]図1Aに示すように、ビデオコード化システム10は、宛先機器14によって後で復号されるべき符号化ビデオデータを生成する発信源機器12を含む。図1Aの例では、発信源機器12及び宛先機器14は別個の機器上にある− 詳細には、発信源機器12は発信源機器の部分であり、宛先機器14は宛先機器の部分である。しかしながら、発信源及び宛先機器12、14が、図1Bの例に示すように、同じ機器上にあってもよく、又は同じ機器の部分であってもよいことに留意されたい。
[0037]もう一度図1Aを参照すると、発信源機器12及び宛先機器14はそれぞれ、デスクトップコンピュータ、ノートブック(例えば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、所謂「スマート」フォンなどの電話ハンドセット、所謂「スマート」パッド、テレビジョン、カメラ、表示装置、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミング機器などを含む、広範囲の機器のいずれかを備え得る。様々な実施形態では、発信源機器12及び宛先機器14はワイヤレス通信のために装備され得る。
[0038]宛先機器14は、リンク16を介して、復号されるべき符号化ビデオデータを受信し得る。リンク16は、発信源機器12から宛先機器14に符号化ビデオデータを動かすことが可能な任意のタイプの媒体又は機器を備え得る。図1Aの例では、リンク16は、発信源機器12が、符号化ビデオデータをリアルタイムで宛先機器14に直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され得、宛先機器14に送信され得る。通信媒体は、無線周波数(RF)スペクトル又は1つ以上の物理伝送線路などの、任意のワイヤレス通信媒体又は有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワークなどのパケットベースのネットワーク、又はインターネットなどのグローバルネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、又は発信源機器12から宛先機器14への通信を容易にするために有用であり得る、任意の他の機器を含み得る。
[0039]代替的に、符号化データは出力インターフェース22から、随意の記憶機器31に出力され得る。同様に、符号化データは、例えば、宛先機器14の入力インターフェース28によって、記憶機器31からアクセスされ得る。記憶機器31は、ハードドライブ、フラッシュメモリ、揮発性若しくは不揮発性のメモリ、又は符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの、様々な分散された又は局所的にアクセスされるデータ記憶媒体のいずれかを含み得る。更なる例では、記憶機器31は、発信源機器12によって生成された符号化ビデオを保持し得るファイルサーバ又は別の中間記憶機器に相当し得る。宛先機器14は、記憶されているビデオデータに、記憶機器31からストリーミング又はダウンロードを介してアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することができ、その符号化ビデオデータを宛先機器14に送信することができる、任意のタイプのサーバであり得る。例示的なファイルサーバは、ウェブサーバ(例えば、ウェブサイト用の)、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続記憶(NAS)機器、又はローカルディスクドライブを含む。宛先機器14は、インターネット接続を含む任意の標準的なデータ接続を通じて、符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(例えば、ワイヤレスローカルエリアネットワーク[WLAN]接続)、ワイヤード接続(例えば、デジタル加入者回線(DSL)、ケーブルモデムなど)、又はその両方の組合せを含み得る。記憶機器31からの符号化ビデオデータの伝送は、ストリーミング伝送、ダウンロード伝送、又はその両方の組合せであり得る。
[0040]本開示の技法は、ワイヤレスの用途又は設定に限定されない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、例えばインターネットを介したストリーミングビデオ送信(例えば、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(HTTP)など)、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、又は他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコード化に適用され得る。幾つかの例では、ビデオコード化システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、及び/又はビデオ電話などの用途をサポートするために、単方向又は双方向のビデオ送信をサポートするように構成され得る。
[0041]図1Aの例では、発信源機器12は、ビデオ発信源18と、ビデオエンコーダ20と、出力インターフェース22とを含む。場合によっては、出力インターフェース22は変調器/復調器(モデム)及び/又は送信機を含み得る。発信源機器12において、ビデオ発信源18は、撮像装置、例えばビデオカメラ、以前に撮られたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、及び/又は発信源ビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどの発信源、若しくはそのような発信源の組合せを含み得る。一例として、図1Bの例に示すように、ビデオ発信源18がビデオカメラである場合、発信源機器12及び宛先機器14は、所謂カメラ付き電話又はビデオ電話を形成し得る。しかしながら、本開示に記載される技法は、概してビデオコード化に適用可能であり得、ワイヤレスアプリケーション及び/又は有線アプリケーションに適用され得る。
[0042]撮られたビデオ、以前に撮られたビデオ、又はコンピュータで生成されたビデオは、ビデオエンコーダ20によって符号化され得る。符号化ビデオデータは、発信源機器12の出力インターフェース22を介して、宛先機器14に直接送信され得る。符号化ビデオデータは、更に(又は代替的に)、復号及び/又は再生のための宛先機器14又は他の機器による後のアクセスのために、記憶機器31に記憶され得る。図1A及び図1Bに示すビデオエンコーダ20は、図2Aに示すビデオエンコーダ20、図2Bに示すビデオエンコーダ23、又は本明細書に記載される任意の他のビデオエンコーダを備えてよい。
[0043]図1Aの例では、宛先機器14は、入力インターフェース28と、ビデオデコーダ30と、表示装置32とを含む。場合によっては、入力インターフェース28は、受信機及び/又はモデムを含み得る。宛先機器14の入力インターフェース28は、符号化ビデオデータを、リンク16を介して及び/又は記憶機器31から受信し得る。リンク16を介して通信され、又は記憶機器31上に提供された符号化ビデオデータは、ビデオデータを復号する際のビデオデコーダ30などのビデオデコーダによる使用のために、ビデオエンコーダ20によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体に記憶されるか、又はファイルサーバに記憶される符号化ビデオデータに含まれ得る。図1A及び図1Bに示すビデオデコーダ30は、図3Aに示すビデオデコーダ30、図3Bに示すビデオデコーダ33、又は本明細書に記載される任意の他のビデオデコーダを備えてよい。
[0044]表示装置32は、宛先機器14と一体化されるか、又はその外部にあり得る。幾つかの例では、宛先機器14は、一体型表示装置を含み得、また、外部表示装置とインターフェースするように構成され得る。他の例では、宛先機器14は表示装置であり得る。概して、表示装置32は、復号ビデオデータをユーザに対して表示し、液晶表示器(LCD)、プラズマ表示器、有機発光ダイオード(OLED)表示器、又は別のタイプの表示装置など、様々な表示装置のいずれかを備え得る。
[0045]関係する態様では、図1Bは、例示的なビデオ符号化及び復号システム10’を示し、ここにおいて、発信源及び宛先機器12、14は、機器11上にあり、又はその部分である。機器11は、「スマート」フォンなどの電話ハンドセットであり得る。機器11は、発信源及び宛先機器12、14と動作可能に通信している随意のプロセッサ/コントローラ機器13を含み得る。図1Bのシステム10’は、ビデオエンコーダ20と出力インターフェース22との間にビデオ処理ユニット21を更に含み得る。幾つかの実装形態では、ビデオ処理ユニット21は、図1Bに示すように別個のユニットであるが、他の実施態様では、ビデオ処理ユニット21は、ビデオエンコーダ20及び/又はプロセッサ/コントローラ機器13の部分として実装され得る。システム10’は、また、ビデオシーケンスの中で対象のオブジェクトを追跡することができる随意のトラッカー29を含み得る。追跡されるべき対象のオブジェクトは、本開示の1つ又は複数の態様に関して説明する技法によって、セグメント化され得る。関係する態様では、追跡することは、表示装置32によって単独で、又はトラッカー29と一緒に実行され得る。図1Bのシステム10’及びその構成要素は、図1Aのシステム10及びその構成要素と場合によっては類似である。
[0046]ビデオエンコーダ20及びビデオデコーダ30は、HEVC規格など、ビデオ圧縮規格に従って動作し得、HEVCテストモデル(HM)に準拠し得る。代替的に、ビデオエンコーダ20及びビデオデコーダ30は、代替的にMPEG−4,Part10,AVCと呼ばれるITU−T H.264規格など、他の独自の規格又は業界規格、若しくはそのような規格の拡張に従って動作し得る。但し、本開示の技法は、いかなる特定のコード化規格にも限定されない。ビデオ圧縮規格の他の例は、MPEG−2及びITU−T H.263を含む。
[0047]図1A及び図1Bの例に示されないが、ビデオエンコーダ20及びビデオデコーダ30は各々、オーディオエンコーダ及びオーディオデコーダと統合されてよく、共通のデータストリーム又は別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するための適切なMUX−DEMUXユニット、又は他のハードウェア及びソフトウェアを含み得る。適用可能な場合、幾つかの例では、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、又はユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0048]ビデオエンコーダ20及びビデオデコーダ30は各々、1つ又は複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組合せなどの様々な適切なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、機器は、適切な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し得、本開示の技法を実行するために、1つ又は複数のプロセッサを使用して、命令をハードウェアで実行し得る。ビデオエンコーダ20及びビデオデコーダ30の各々は、1つ又は複数のエンコーダ又はデコーダに含まれ得、そのいずれも、それぞれの機器において複合エンコーダ/デコーダ(例えば、コーデック)の一部として統合され得る。
ビデオコード化プロセス
[0049]上記で簡略に述べられたように、ビデオエンコーダ20はビデオデータを符号化する。ビデオデータは、1つ又は複数のピクチャを備え得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。幾つかの事例では、ピクチャは、ビデオ「フレーム」と呼ばれることがある。ビデオエンコーダ20がビデオデータを符号化するとき、ビデオエンコーダ20は、ビットストリームを生成し得る。ビットストリームは、ビデオデータのコード化された表現を形成するビットのシーケンスを含み得る。ビットストリームは、コード化ピクチャと、関連するデータとを含み得る。コード化ピクチャは、ピクチャのコード化された表現である。
[0050]ビットストリームを生成するために、ビデオエンコーダ20は、ビデオデータ中の各ピクチャに対して符号化演算を実行し得る。ビデオエンコーダ20がピクチャに対して符号化演算を実行するとき、ビデオエンコーダ20は、一連のコード化ピクチャと、関連するデータとを生成し得る。関連するデータは、ビデオパラメータセット(VPS:video parameter set)と、シーケンスパラメータセット(SPS)と、ピクチャパラメータセット(PPS)と、適応パラメータセット(APS)と、他のシンタックス構造とを含み得る。SPSは、ピクチャの0個以上のシーケンスに適用可能なパラメータを含み得る。PPSは、0個以上のピクチャに適用可能なパラメータを含み得る。APSは、0個以上のピクチャに適用可能なパラメータを含み得る。APS中のパラメータは、PPS中のパラメータよりも変化する可能性が高いパラメータであり得る。
[0051]コード化ピクチャを生成するために、ビデオエンコーダ20は、ピクチャを等しいサイズのビデオブロックに区分し得る。ビデオブロックはサンプルの2次元アレイであり得る。ビデオブロックの各々は、ツリーブロックに関連付けられる。幾つかの事例では、ツリーブロックは、最大コード化単位(LCU:largest coding unit)と呼ばれることがある。HEVCのツリーブロックは、H.264/AVCのような従来の規格のマクロブロックに、広い意味で類似し得る。しかしながら、ツリーブロックは、特定のサイズに必ずしも限定されず、1つ又は複数のコード化単位(CU)を含み得る。ビデオエンコーダ20は、ツリーブロックのビデオブロックを、CUに関連付けられたビデオブロックに区分するために、4分木区分を使用し得、従って、「ツリーブロック」という名前である。
[0052]幾つかの例では、ビデオエンコーダ20は、ピクチャを複数のスライスに区分し得る。スライスの各々は、整数個のCUを含み得る。幾つかの事例では、スライスは、整数個のツリーブロックを備える。他の事例では、スライスの境界は、ツリーブロック内にあり得る。
[0053]ピクチャに対して符号化演算を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化演算を実行し得る。ビデオエンコーダ20がスライスに対して符号化演算を実行するとき、ビデオエンコーダ20は、スライスに関連付けられた符号化データを生成し得る。スライスに関連付けられた符号化データは、「コード化スライス」と呼ばれることがある。
[0054]コード化スライスを生成するために、ビデオエンコーダ20は、スライス中の各ツリーブロックに対して符号化演算を実行し得る。ビデオエンコーダ20がツリーブロックに対して符号化演算を実行するとき、ビデオエンコーダ20は、コード化されたツリーブロックを生成し得る。コード化されたツリーブロックは、ツリーブロックの符号化されたバージョンを表すデータを備え得る。
[0055]ビデオエンコーダ20がコード化スライスを生成するとき、ビデオエンコーダ20は、ラスタ走査順序に従って、スライス中のツリーブロックに対して符号化演算を実行(例えば、符号化)し得る。例えば、ビデオエンコーダ20は、スライス中のツリーブロックの一番上の行にわたって左から右に進み、次いでツリーブロックの次の下の行にわたって左から右に進み、以下同様に進む順序で、ビデオエンコーダ20がスライス中のツリーブロックの各々を符号化するまで、スライスのツリーブロックを符号化し得る。
[0056]ラスタ走査順序に従ってツリーブロックを符号化した結果として、所与のツリーブロックの上及び左のツリーブロックは符号化されていることがあるが、所与のツリーブロックの下及び右のツリーブロックはまだ符号化されていない。従って、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの上及び左のツリーブロックを符号化することによって生成される情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のツリーブロックを符号化するとき、所与のツリーブロックの下及び右のツリーブロックを符号化することによって生成される情報にアクセスできないことがある。
[0057]コード化されたツリーブロックを生成するために、ビデオエンコーダ20は、ビデオブロックを徐々により小さいビデオブロックに分割するために、ツリーブロックのビデオブロック上で4分木区分を再帰的に実行し得る。より小さいビデオブロックの各々は、異なるCUに関連付けられ得る。例えば、ビデオエンコーダ20は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し得、サブブロックのうちの1つ又は複数を4つの等しいサイズのサブサブブロックに区分し得、以下同様である。区分されたCUは、そのビデオブロックが他のCUに関連付けられたビデオブロックに区分されているCUであり得る。区分されていないCUは、そのビデオブロックが他のCUに関連付けられたビデオブロックに区分されていないCUであり得る。
[0058]ビットストリーム中の1つ又は複数のシンタックス要素は、ビデオエンコーダ20がツリーブロックのビデオブロックを区分し得る最大の回数を示し得る。CUのビデオブロックは形状が正方形であり得る。CUのビデオブロックのサイズ(例えば、CUのサイズ)は、8×8の画素から、最大で64×64以上の画素を有するツリーブロックのビデオブロックのサイズ(例えば、ツリーブロックのサイズ)までわたり得る。
[0059]ビデオエンコーダ20は、z走査順序に従って、ツリーブロックの各CUに対して符号化演算を実行(例えば、符号化)し得る。言い換えれば、ビデオエンコーダ20は、左上のCUと、右上のCUと、左下のCUと、次いで右下のCUとを、その順序で符号化し得る。ビデオエンコーダ20が、区分されているCUに対して符号化演算を実行するとき、ビデオエンコーダ20は、z走査順序に従って、区分されているCUのビデオブロックのサブブロックに関連付けられたCUを符号化し得る。言い換えれば、ビデオエンコーダ20は、左上のサブブロックに関連付けられたCUと、右上のサブブロックに関連付けられたCUと、左下のサブブロックに関連付けられたCUと、次いで右下のサブブロックに関連付けられたCUとを、その順序で符号化し得る。
[0060]z走査順序に従ってツリーブロックのCUを符号化した結果として、所与のCUの上、左上、右上、左、及び左下のCUは符号化されていることがある。所与のCUの下又は右のCUはまだ符号化されていない。従って、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接する幾つかのCUを符号化することによって生成される情報にアクセスすることが可能であり得る。しかしながら、ビデオエンコーダ20は、所与のCUを符号化するとき、所与のCUに隣接する他のCUを符号化することによって生成される情報にアクセスできないことがある。
[0061]ビデオエンコーダ20が、区分されていないCUを符号化するとき、ビデオエンコーダ20は、CUに対する1つ又は複数の予測単位(PU)を生成し得る。CUのPUの各々は、CUのビデオブロック内の異なるビデオブロックに関連付けられ得る。ビデオエンコーダ20は、CUの各PUに対して予測ビデオブロックを生成し得る。PUの予測ビデオブロックは、サンプルのブロックであり得る。ビデオエンコーダ20は、PUのための予測ビデオブロックを生成するために、イントラ予測又はインター予測を使用し得る。
[0062]ビデオエンコーダ20がPUの予測ビデオブロックを生成するためにイントラ予測を使用するとき、ビデオエンコーダ20は、PUに関連付けられたピクチャの復号サンプルに基づいて、PUの予測ビデオブロックを生成し得る。ビデオエンコーダ20がCUのPUの予測ビデオブロックを生成するためにイントラ予測を使用する場合、CUはイントラ予測されたCUである。ビデオエンコーダ20がPUの予測ビデオブロックを生成するためにインター予測を使用するとき、ビデオエンコーダ20は、PUに関連付けられたピクチャ以外の1つ又は複数のピクチャの復号サンプルに基づいて、PUの予測ビデオブロックを生成し得る。ビデオエンコーダ20がCUのPUの予測ビデオブロックを生成するためにインター予測を使用する場合、CUはインター予測されたCUである。
[0063]更に、ビデオエンコーダ20がPUのための予測ビデオブロックを生成するためにインター予測を使用するとき、ビデオエンコーダ20は、PUのための動き情報を生成し得る。PUのための動き情報は、PUの1つ又は複数の参照ブロックを示し得る。PUの各参照ブロックは、参照ピクチャ内のビデオブロックであり得る。参照ピクチャは、PUに関連付けられたピクチャ以外のピクチャであり得る。幾つかの事例では、PUの参照ブロックは、PUの「参照サンプル」と呼ばれることもある。ビデオエンコーダ20は、PUの参照ブロックに基づいて、PUのための予測ビデオブロックを生成し得る。
[0064]ビデオエンコーダ20がCUの1つ又は複数のPUのための予測ビデオブロックを生成した後、ビデオエンコーダ20は、CUのPUのための予測ビデオブロックに基づいて、CUに対する残差データを生成し得る。CUの残差データは、CUのPUのための予測ビデオブロック中のサンプルと、CUの元のビデオブロック中のサンプルとの差分を示し得る。
[0065]更に、区分されていないCUに対して符号化演算を実行することの一部として、ビデオエンコーダ20は、CUの残差データを、CUの変換単位(TU)に関連付けられた残差データの1つ又は複数のブロック(例えば、残差ビデオブロック)に区分するために、CUの残差データに対して再帰的な4分木区分を実行し得る。CUの各TUは、異なる残差ビデオブロックに関連付けられ得る。
[0066]ビデオエンコーダ20は、TUに関連付けられた変換係数ブロック(例えば、変換係数のブロック)を生成するために、TUに関連付けられた残差ビデオブロックに1つ又は複数の変換を適用し得る。概念的に、変換係数ブロックは変換係数の2次元(2D)行列であり得る。
[0067]変換係数ブロックを生成した後、ビデオエンコーダ20は、変換係数ブロックに対して量子化プロセスを実行し得る。量子化は、概して、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、更なる圧縮を実現するプロセスを指す。量子化プロセスは、変換係数の一部又は全部に関連するビット深度を低減し得る。例えば、量子化中に、nビット変換係数はmビット変換係数に切り捨てられ得、ここで、nはmよりも大きい。
[0068]ビデオエンコーダ20は、各CUを、量子化パラメータ(QP)値に関連付け得る。CUに関連付けられたQP値は、ビデオエンコーダ20が、CUに関連付けられた変換係数ブロックをどのように量子化するかを決定し得る。ビデオエンコーダ20は、CUに関連付けられたQP値を調整することによって、CUに関連付けられた変換係数ブロックに適用される量子化の程度を調整し得る。
[0069]ビデオエンコーダ20が変換係数ブロックを量子化した後、ビデオエンコーダ20は、量子化された変換係数ブロックの中で変換係数を表すシンタックス要素のセットを生成し得る。ビデオエンコーダ20は、これらのシンタックス要素のうちの幾つかに、コンテキスト適応型バイナリ算術コード化(CABAC:Context Adaptive Binary Arithmetic Coding)演算などのエントロピー符号化演算を適用し得る。コンテンツ適応型可変長コード化(CAVLC:content adaptive variable length coding)、確率間隔区分エントロピー(PIPE:probability interval partitioning entropy)コード化、又は他のバイナリ算術コード化など、他のエントロピーコード化技法も使用され得る。
[0070]ビデオエンコーダ20によって生成されるビットストリームは、一連のネットワーク抽象化レイヤ(NAL:Network Abstraction Layer)単位を含み得る。NAL単位の各々は、NAL単位中のデータのタイプの指示と、データを含むバイトとを含む、シンタックス構造であり得る。例えば、NAL単位は、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、コード化スライス、補足拡張情報(SEI:supplemental enhancement information)、アクセス単位デリミタ、フィラーデータ、又は別のタイプのデータを表すデータを含み得る。NAL単位中のデータは、様々なシンタックス構造を含み得る。
[0071]ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信し得る。ビットストリームは、ビデオエンコーダ20によって符号化されたビデオデータのコード化された表現を含み得る。ビデオデコーダ30がビットストリームを受信すると、ビデオデコーダ30は、ビットストリームに対して構文解析動作を実行し得る。ビデオデコーダ30が構文解析動作を実行するとき、ビデオデコーダ30は、ビットストリームからシンタックス要素を抽出し得る。ビデオデコーダ30は、ビットストリームから抽出されたシンタックス要素に基づいて、ビデオデータのピクチャを再構成し得る。シンタックス要素に基づいてビデオデータを再構成するためのプロセスは、一般に、シンタックス要素を生成するためにビデオエンコーダ20によって実行されるプロセスの逆であり得る。
[0072]ビデオデコーダ30がCUに関連付けられたシンタックス要素を抽出した後、ビデオデコーダ30は、シンタックス要素に基づいて、CUのPUのための予測ビデオブロックを生成し得る。更に、ビデオデコーダ30は、CUのTUに関連付けられた変換係数ブロックを逆量子化し得る。ビデオデコーダ30は、CUのTUに関連付けられた残差ビデオブロックを再構成するために、変換係数ブロックに対して逆変換を実行し得る。予測ビデオブロックを生成し、残差ビデオブロックを再構成した後、ビデオデコーダ30は、予測ビデオブロック及び残差ビデオブロックに基づいて、CUのビデオブロックを再構成し得る。このようにして、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて、CUのビデオブロックを再構成し得る。
ビデオエンコーダ
[0073]図2Aは、本開示で説明する態様による技法を実装し得るビデオエンコーダの一例を示すブロック図である。ビデオエンコーダ20は、HEVCの場合など、ビデオフレームの単一のレイヤを処理するように構成され得る。更に、ビデオエンコーダ20は、本開示の技法のいずれか又は全てを実行するように構成され得る。一例として、予測処理ユニット100は、本開示で説明する技法のいずれか又は全てを実行するように構成され得る。別の実施形態では、ビデオエンコーダ20は、本開示で説明する技法のいずれか又は全てを実行するように構成された随意のレイヤ間予測ユニット128を含む。他の実施形態では、レイヤ間予測は、予測処理ユニット100(例えば、インター予測ユニット121及び/又はイントラ予測ユニット126)によって実行され得、その場合、レイヤ間予測ユニット128は省略され得る。しかしながら、本開示の態様はそのように限定されない。幾つかの例では、本開示で説明する技法は、ビデオエンコーダ20の様々な構成要素間で共有され得る。幾つかの例では、追加又は代替として、プロセッサ(図示せず)が、本開示で説明する技法のいずれか又は全てを実行するように構成され得る。
[0074]説明の目的で、本開示は、HEVCコード化のコンテキストにおいてビデオエンコーダ20を説明する。しかしながら、本開示の技法は、他のコード化規格又は方法に適用可能であり得る。図2Aに示す例は、シングルレイヤコーデックのためのものである。しかしながら、図2Bに関して更に説明するように、ビデオエンコーダ20の一部又は全部は、マルチレイヤコーデックの処理のために複製され得る。
[0075]ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコード化とインターコード化とを実行し得る。イントラコード化は、所与のビデオフレーム又はピクチャ内のビデオの空間的冗長性を低減又は除去するために、空間予測に依拠する。インターコード化は、ビデオシーケンスの隣接するフレーム内又はピクチャ内のビデオの時間的冗長性を低減又は除去するために時間予測に依拠する。イントラモード(Iモード)は、幾つかの空間ベースのコード化モードのいずれかを参照し得る。単方向予測(Pモード)又は双方向予測(Bモード)などのインターモードは、幾つかの時間ベースのコード化モードのいずれかを参照し得る。
[0076]図2Aの例では、ビデオエンコーダ20は複数の機能構成要素を含む。ビデオエンコーダ20の機能構成要素は、予測処理ユニット100と、残差生成ユニット102と、変換処理ユニット104と、量子化ユニット106と、逆量子化ユニット108と、逆変換ユニット110と、再構成ユニット112と、フィルタユニット113と、復号ピクチャバッファ114と、エントロピー符号化ユニット116とを含む。予測処理ユニット100は、インター予測ユニット121と、動き推定ユニット122と、動き補償ユニット124と、イントラ予測ユニット126と、レイヤ間予測ユニット128とを含む。他の例では、ビデオエンコーダ20は、より多いか、より少ないか、又は異なる機能構成要素を含み得る。更に、動き推定ユニット122及び動き補償ユニット124は、高度に統合され得るが、図2Aの例では、説明の目的で別々に表されている。
[0077]ビデオエンコーダ20は、ビデオデータを受信し得る。ビデオエンコーダ20は、様々な発信源からビデオデータを受信し得る。例えば、ビデオエンコーダ20は、ビデオ発信源18(例えば、図1A又は図1Bに示す)又は別の発信源からビデオデータを受信し得る。ビデオデータは、一連のピクチャを表し得る。ビデオデータを符号化するために、ビデオエンコーダ20は、ピクチャの各々に対して符号化演算を実行し得る。ピクチャに対して符号化演算を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化演算を実行し得る。スライスに対して符号化演算を実行することの一部として、ビデオエンコーダ20は、スライス中のツリーブロックに対して符号化演算を実行し得る。
[0078]ツリーブロックに対して符号化演算を実行することの一部として、予測処理ユニット100は、ビデオブロックを徐々により小さいビデオブロックに分割するために、ツリーブロックのビデオブロックに対して4分木区分を実行し得る。より小さいビデオブロックの各々は、異なるCUに関連付けられ得る。例えば、予測処理ユニット100は、ツリーブロックのビデオブロックを4つの等しいサイズのサブブロックに区分し得、サブブロックのうちの1つ又は複数を4つの等しいサイズのサブサブブロックに区分し得、以下同様である。
[0079]CUに関連付けられたビデオブロックのサイズは、8×8サンプルから、最大で64×64サンプル以上のツリーブロックのサイズにまでわたり得る。本開示では、「N×N」及び「N by N」は、垂直方向の寸法及び水平方向の寸法に関するビデオブロックのサンプルの寸法、例えば、16×16サンプル又は16 by 16サンプルを指すために、互換的に使用され得る。一般に、16×16のビデオブロックは、垂直方向に16個のサンプルを有し(y=16)、水平方向に16個のサンプルを有する(x=16)。同様に、N×Nのブロックは、一般に、垂直方向にN個のサンプルを有し、水平方向にN個のサンプルを有し、ここで、Nは非負整数値を表す。
[0080]更に、ツリーブロックに対して符号化演算を実行することの一部として、予測処理ユニット100は、ツリーブロック用の階層的な4分木データ構造を生成し得る。例えば、ツリーブロックは、4分木データ構造のルートノードに対応し得る。予測処理ユニット100がツリーブロックのビデオブロックを4つのサブブロックに区分する場合、ルートノードは、4分木データ構造中に4つの子ノードを有する。子ノードの各々は、サブブロックのうちの1つに関連付けられたCUに対応する。予測処理ユニット100がサブブロックのうちの1つを4つのサブサブブロックに区分する場合、サブブロックに関連付けられたCUに対応するノードは、サブサブブロックのうちの1つに関連付けられたCUに各々が対応する、4つの子ノードを有し得る。
[0081]4分木データ構造の各ノードは、対応するツリーブロック又はCUのシンタックスデータ(例えば、シンタックス要素)を含み得る。例えば、4分木の中のノードは、そのノードに対応するCUのビデオブロックが4つのサブブロックに区分(例えば、分割)されているかどうかを示すスプリットフラグを含み得る。CUのためのシンタックス要素は、再帰的に定義され得、CUのビデオブロックがサブブロックに分割されているかどうかに依存し得る。ビデオブロックが区分されていないCUは、4分木データ構造におけるリーフノードに対応し得る。コード化されたツリーブロックは、対応するツリーブロック用の4分木データ構造に基づくデータを含み得る。
[0082]ビデオエンコーダ20は、ツリーブロックの区分されていない各CUに対して符号化演算を実行し得る。ビデオエンコーダ20が、区分されていないCUに対して符号化演算を実行するとき、ビデオエンコーダ20は、区分されていないCUの符号化された表現を表すデータを生成する。
[0083]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のビデオブロックを区分するように、幾何学的な区分を実行し得る。
[0084]インター予測ユニット121は、CUの各PUに対してインター予測を実行し得る。インター予測は、時間圧縮を実現し得る。PUに対してインター予測を実行するために、動き推定ユニット122は、PUのための動き情報を生成し得る。動き補償ユニット124は、PUベースの動き情報及びCUに関連付けられたピクチャ以外のピクチャ(例えば、参照ピクチャ)の復号サンプルのための、予測ビデオブロックを生成し得る。本開示では、動き補償ユニット124によって生成される予測ビデオブロックは、インター予測ビデオブロックと呼ばれることがある。
[0085]スライスは、Iスライス、Pスライス、又はBスライスであり得る。動き推定ユニット122及び動き補償ユニット124は、PUがIスライス中にあるのか、Pスライス中にあるのか、それともBスライス中にあるのかに応じて、CUのPUのための異なる演算を実行し得る。Iスライス中では、全てのPUがイントラ予測される。従って、PUがIスライス中にある場合、動き推定ユニット122及び動き補償ユニット124は、PUに対してインター予測を実行しない。
[0086]PUがPスライス中にある場合、PUを含むピクチャは、「リスト0」と呼ばれる参照ピクチャのリストに関連付けられる。リスト0中の参照ピクチャの各々は、他のピクチャのインター予測のために使用され得るサンプルを含む。動き推定ユニット122がPスライス中のPUに関して動き推定演算を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索し得る。PUの参照ブロックは、PUのビデオブロック中のサンプルに最も密接に対応するサンプルのセット、例えば、サンプルのブロックであり得る。動き推定ユニット122は、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定するために、様々なメトリックを使用し得る。例えば、動き推定ユニット122は、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、又は他の差分メトリックによって、参照ピクチャ中のサンプルのセットがどの程度密接にPUのビデオブロック中のサンプルに対応するかを決定し得る。
[0087]Pスライス中のPUの参照ブロックを識別した後、動き推定ユニット122は、参照ブロックを含んでいる、リスト0中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。様々な例において、動き推定ユニット122は、動きベクトルを異なる精度に生成し得る。例えば、動き推定ユニット122は、1/4サンプル精度、1/8サンプル精度、又は他の分数のサンプル精度で動きベクトルを生成し得る。分数のサンプル精度の場合、参照ブロック値は、参照ピクチャ中の整数位置のサンプル値から補間され得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって識別された参照ブロックに基づいて、PUの予測ビデオブロックを生成し得る。
[0088]PUがBスライス中にある場合、PUを含むピクチャは、「リスト0」及び「リスト1」と呼ばれる参照ピクチャの2つのリストに関連付けられ得る。幾つかの例では、Bスライスを含むピクチャは、リスト0とリスト1の組合せである、リストの組合せと関連付けられ得る。
[0089]更に、PUがBスライス中にある場合、動き推定ユニット122は、PUのための単方向予測又は双方向予測を実行し得る。動き推定ユニット122がPUのための単方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0又はリスト1の参照ピクチャを探索し得る。動き推定ユニット122は、次いで、参照ブロックを含む、リスト0又はリスト1中の参照ピクチャを示す参照インデックスと、PUと参照ブロックとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、参照インデックスと、予測方向インジケータと、動きベクトルとを出力し得る。予測方向インジケータは、参照インデックスが、リスト0中の参照ピクチャを示すのか、それともリスト1中の参照ピクチャを示すのかを示し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測ビデオブロックを生成し得る。
[0090]動き推定ユニット122がPUのための双方向予測を実行するとき、動き推定ユニット122は、PUのための参照ブロックについて、リスト0中の参照ピクチャを探索し得、また、PUのための別の参照ブロックについて、リスト1中の参照ピクチャを探索し得る。動き推定ユニット122は、次いで、参照ブロックを含む、リスト0及びリスト1中の参照ピクチャを示す参照インデックスと、参照ブロックとPUとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット122は、PUの動き情報として、PUの参照インデックスと動きベクトルとを出力し得る。動き補償ユニット124は、PUの動き情報によって示された参照ブロックに基づいて、PUの予測ビデオブロックを生成し得る。
[0091]幾つかの事例では、動き推定ユニット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の動き情報を信号伝達することが可能であり得る。
[0092]図4に関して以下で更に説明するように、予測処理ユニット100は、図4に示される方法を実行することによってPU(又は他のRLブロック及び/又はELブロック又はビデオ単位)をコード化(例えば、符号化又は復号)するように構成され得る。例えば、(例えば、動き推定ユニット122及び/又は動き補償ユニット124を介した)インター予測ユニット121、イントラ予測ユニット126、又はレイヤ間予測ユニット128は、一緒に又は別々に、図4に示される方法を実行するように構成され得る。
[0093]CUに対して符号化演算を実行することの一部として、イントラ予測ユニット126は、CUのPUに対してイントラ予測を実行し得る。イントラ予測は、空間圧縮を実現し得る。イントラ予測ユニット126がPUに対してイントラ予測を実行するとき、イントラ予測ユニット126は、同じピクチャ中の他のPUの復号サンプルに基づいて、PUのための予測データを生成し得る。PUのための予測データは、予測ビデオブロックと様々なシンタックス要素とを含み得る。イントラ予測ユニット126は、Iスライス、Pスライス、及びBスライス中のPUに対してイントラ予測を実行し得る。
[0094]PUに対してイントラ予測を実行するために、イントラ予測ユニット126は、PUのための予測データの複数のセットを生成するために、複数のイントラ予測モードを使用し得る。イントラ予測ユニット126がPUのための予測データのセットを生成するためにイントラ予測モードを使用するとき、イントラ予測ユニット126は、イントラ予測モードと関連する方向及び/又は勾配で、隣接PUのビデオブロックからPUのビデオブロックにわたってサンプルを延ばし得る。PU、CU、及びツリーブロックについて左から右、上から下の符号化順序を仮定すると、隣接PUは、PUの上、右上、左上、又は左にあり得る。イントラ予測ユニット126は、PUのサイズに応じて、様々な数のイントラ予測モード、例えば、33個の方向性イントラ予測モードを使用し得る。
[0095]予測処理ユニット100は、動き補償ユニット124によってPUのために生成された予測データ、又はイントラ予測ユニット126によってPUのために生成された予測データの中から、PUのための予測データを選択し得る。幾つかの例では、予測処理ユニット100は、予測データのセットのレート/歪みメトリックに基づいて、PUのための予測データを選択する。
[0096]予測処理ユニット100がイントラ予測ユニット126によって生成された予測データを選択する場合、予測処理ユニット100は、PUのための予測データを生成するために使用されたイントラ予測モード、例えば、選択されたイントラ予測モードを信号伝達し得る。予測処理ユニット100は、選択されたイントラ予測モードを様々な方法で信号伝達し得る。例えば、選択されたイントラ予測モードは、隣接PUのイントラ予測モードと同じであることが起こり得る。言い換えれば、隣接PUのイントラ予測モードは、現在PUに対して最確モードであり得る。従って、予測処理ユニット100は、選択されたイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示すためのシンタックス要素を生成し得る。
[0097]上記で説明したように、ビデオエンコーダ20は、レイヤ間予測ユニット128を含み得る。レイヤ間予測ユニット128は、スケーラブルビデオコード化において利用可能である1つ又は複数の異なるレイヤ(例えば、BL又はRL)を使用して、現在ブロック(例えば、EL中の現在ブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット128は、レイヤ間冗長性を低減するための予測方法を利用し、それによって、コード化効率を改善し、計算リ発信源要件を低減する。レイヤ間予測の幾つかの例は、レイヤ間イントラ予測と、レイヤ間動き予測と、レイヤ間残差予測とを含む。レイヤ間イントラ予測は、EL中の現在ブロックを予測するために、BLの中でコロケートされているブロック(co-located blocks)の再構成を使用する。レイヤ間動き予測は、EL中の動作を予測するために、BLの動き情報を使用する。レイヤ間残差予測は、ELの残差を予測するために、BLの残差を使用する。レイヤ間予測方式の各々について、以下でより詳細に説明する。
[0098]予測処理ユニット100がCUのPUのための予測データを選択した後、残差生成ユニット102は、CUのビデオブロックからCUのPUの予測ビデオブロックを差し引くこと(例えば、マイナス符号によって示される)によって、CUの残差データを生成し得る。CUの残差データは、CUのビデオブロック中のサンプルの異なるサンプル成分に対応する2D残差ビデオブロックを含み得る。例えば、残差データは、CUのPUの予測ビデオブロック中のサンプルのルミナンス成分と、CUの元のビデオブロック中のサンプルのルミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。更に、CUの残差データは、CUのPUの予測ビデオブロック中のサンプルのクロミナンス成分と、CUの元のビデオブロック中のサンプルのクロミナンス成分との間の差分に対応する、残差ビデオブロックを含み得る。
[0099]予測処理ユニット100は、CUの残差ビデオブロックをサブブロックに区分するために、4分木区分を実行し得る。分割されていない各残差ビデオブロックは、CUの異なるTUに関連付けられ得る。CUのTUに関連付けられる残差ビデオブロックのサイズ及び位置は、CUのPUに関連付けられたビデオブロックのサイズ及び位置に基づいてもよく、又は基づかなくてもよい。「残差4分木」(RQT)と呼ばれる4分木構造は、残差ビデオブロックの各々に関連付けられたノードを含み得る。CUのTUは、RQTのリーフノードに対応し得る。
[0100]変換処理ユニット104は、TUに関連付けられた残差ビデオブロックに1つ又は複数の変換を適用することによって、CUの各TUのための1つ又は複数の変換係数ブロックを生成し得る。変換係数ブロックの各々は、変換係数の2D行列であり得る。変換処理ユニット104は、TUに関連付けられた残差ビデオブロックに様々な変換を適用し得る。例えば、変換処理ユニット104は、離散コサイン変換(DCT)、方向変換、又は概念的に類似の変換を、TUに関連付けられた残差ビデオブロックに適用し得る。
[0101]変換処理ユニット104が、TUに関連付けられた変換係数ブロックを生成した後、量子化ユニット106は、変換係数ブロック中の変換係数を量子化し得る。量子化ユニット106は、CUに関連付けられたQP値に基づいて、CUのTUに関連付けられた変換係数ブロックを量子化し得る。
[0102]ビデオエンコーダ20は、様々な方法でQP値をCUに関連付け得る。例えば、ビデオエンコーダ20は、CUに関連付けられたツリーブロックに対して、レート歪み分析を実行し得る。レート歪み分析では、ビデオエンコーダ20は、ツリーブロックに対して符号化演算を複数回実行することによって、ツリーブロックの複数のコード化された表現を生成し得る。ビデオエンコーダ20が、ツリーブロックの異なる符号化表現を生成するとき、ビデオエンコーダ20は、異なるQP値をCUに関連付け得る。最小のビットレート及び歪みメトリックを有するツリーブロックのコード化された表現で所与のQP値がCUに関連付けられるとき、ビデオエンコーダ20は、所与のQP値がCUに関連付けられることを信号伝達し得る。
[0103]逆量子化ユニット108及び逆変換ユニット110は、変換係数ブロックから残差ビデオブロックを再構成するために、それぞれ、逆量子化と逆変換とを変換係数ブロックに適用し得る。再構成ユニット112は、TUに関連付けられた再構成されたビデオブロックを生成するために、再構成された残差ビデオブロックを、予測処理ユニット100によって生成された1つ又は複数の予測ビデオブロックからの対応するサンプルに追加し得る。このようにCUの各TUについてビデオブロックを再構成することによって、ビデオエンコーダ20は、CUのビデオブロックを再構成し得る。
[0104]再構成ユニット112がCUのビデオブロックを再構成した後、フィルタユニット113は、CUに関連付けられたビデオブロックにおけるブロック歪み(blocking artifacts)を低減するために、デブロッキング演算を実行し得る。1つ又は複数のデブロッキング演算を実行した後、フィルタユニット113は、CUの再構成されたビデオブロックを復号ピクチャバッファ114に記憶し得る。動き推定ユニット122及び動き補償ユニット124は、後続のピクチャのPUに対してインター予測を実行するために、再構成されたビデオブロックを含む参照ピクチャを使用し得る。更に、イントラ予測ユニット126は、CUと同じピクチャ中の他のPUに対してイントラ予測を実行するために、復号ピクチャバッファ114の中の再構成されたビデオブロックを使用し得る。
[0105]エントロピー符号化ユニット116は、ビデオエンコーダ20の他の機能構成要素からデータを受信し得る。例えば、エントロピー符号化ユニット116は、量子化ユニット106から変換係数ブロックを受信し得、予測処理ユニット100からシンタックス要素を受信し得る。エントロピー符号化ユニット116がデータを受信すると、エントロピー符号化ユニット116は、エントロピー符号化データを生成するために、1つ又は複数のエントロピー符号化演算を実行し得る。例えば、ビデオエンコーダ20は、CAVLC演算、CABAC演算、変数間(V2V:variable-to-variable)レングスコード化演算、シンタックスベースコンテキスト適応型バイナリ算術コード化(SBAC:syntax-based context-adaptive binary arithmetic coding)演算、確率間隔区分エントロピー(PIPE)コード化演算、又は別のタイプのエントロピー符号化演算をデータに対して実行し得る。エントロピー符号化ユニット116は、エントロピー符号化データを含むビットストリームを出力し得る。
[0106]データに対してエントロピー符号化演算を実行することの一部として、エントロピー符号化ユニット116は、コンテキストモデルを選択し得る。エントロピー符号化ユニット116がCABAC演算を実行している場合、コンテキストモデルは、特定の値を有する特定のビンの確率の推定値を示し得る。CABACのコンテキストでは、「ビン」という用語は、シンタックス要素の2値化されたバージョンのビットを指すために使用される。
マルチレイヤビデオエンコーダ
[0107]図2Bは、本開示で説明する態様による技法を実装し得るマルチレイヤビデオエンコーダ23(単にビデオエンコーダ23とも呼ばれる)の一例を示すブロック図である。ビデオエンコーダ23は、SHVC及びマルチビューコード化の場合など、マルチレイヤビデオフレームを処理するように構成され得る。更に、ビデオエンコーダ23は、本開示の技法のいずれか又は全てを実行するように構成され得る。
[0108]ビデオエンコーダ23はビデオエンコーダ20Aとビデオエンコーダ20Bとを含み、それらの各々はビデオエンコーダ20として構成され得、ビデオエンコーダ20に関して上記で説明した機能を実行し得る。更に、参照番号の再利用によって示されるように、ビデオエンコーダ20A及び20Bは、ビデオエンコーダ20としてのシステム及びサブシステムのうちの少なくとも幾つかを含み得る。ビデオエンコーダ23は、2つのビデオエンコーダ20A及び20Bを含むように示されるが、ビデオエンコーダ23は、そのように限定されず、任意の数のビデオエンコーダ20のレイヤを含み得る。幾つかの実施形態では、ビデオエンコーダ23は、アクセス単位中の各ピクチャ又は各フレームに対してビデオエンコーダ20を含み得る。例えば、5つのピクチャを含むアクセス単位は、5つのエンコーダレイヤを含むビデオエンコーダによって処理又は符号化され得る。幾つかの実施形態では、ビデオエンコーダ23は、アクセス単位中のフレームよりも多くのエンコーダレイヤを含み得る。幾つかのそのような場合では、ビデオエンコーダのレイヤのうちの幾つかは、幾つかのアクセス単位を処理するときに非アクティブであり得る。
[0109]ビデオエンコーダ20A及び20Bに加えて、ビデオエンコーダ23は、リサンプリングユニット90を含み得る。リサンプリングユニット90は、場合によっては、例えば、ELを作成するために、受信されたビデオフレームのBLをアップサンプリングし得る。リサンプリングユニット90は、フレームの受信されたBLに関連付けられた特定の情報をアップサンプリングし得るが、他の情報をアップサンプリングしないことがある。例えば、リサンプリングユニット90は、BLの空間サイズ又は画素の数をアップサンプリングし得るが、スライスの数又はピクチャ順序カウントは一定のままであり得る。場合によっては、リサンプリングユニット90は、受信されたビデオを処理しないことがあり、及び/又は随意であり得る。例えば、場合によっては、予測処理ユニット100は、アップサンプリングを実行し得る。幾つかの実施形態では、リサンプリングユニット90は、レイヤをアップサンプリングし、スライス境界ルール及び/又はラスタ走査ルールのセットに準拠するように、1つ又は複数のスライスを再編成、再定義、修正、又は調整するように構成される。アクセス単位中のBL又は下位レイヤをアップサンプリングするものとして主に説明したが、場合によっては、リサンプリングユニット90は、レイヤをダウンサンプリングし得る。例えば、ビデオのストリーミング中に帯域幅が低減した場合、フレームは、アップサンプリングされるのではなく、ダウンサンプリングされ得る。
[0110]リサンプリングユニット90は、下位レイヤエンコーダ(例えば、ビデオエンコーダ20A)の復号ピクチャバッファ114からピクチャ又はフレーム(又はピクチャに関連付けられたピクチャ情報)を受信し、ピクチャ(又は受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤエンコーダと同じアクセス単位中のピクチャを符号化するように構成された、上位レイヤエンコーダ(例えば、ビデオエンコーダ20B)の予測処理ユニット100に供給され得る。場合によっては、上位レイヤエンコーダは、下位レイヤエンコーダから除去された1つのレイヤである。他の場合には、図2Bのレイヤ0ビデオエンコーダとレイヤ1エンコーダとの間に、1つ又は複数の上位レイヤエンコーダがあり得る。
[0111]場合によっては、リサンプリングユニット90は、省略又はバイパスされ得る。そのような場合、ビデオエンコーダ20Aの復号ピクチャバッファ114からのピクチャは、直接、又は少なくともリサンプリングユニット90に供給されずに、ビデオエンコーダ20Bの予測処理ユニット100に供給され得る。例えば、ビデオエンコーダ20Bに供給されたビデオデータ、及びビデオエンコーダ20Aの復号ピクチャバッファ114からの参照ピクチャが、同じサイズ又は解像度である場合、参照ピクチャは、いかなるリサンプリングも伴わずにビデオエンコーダ20Bに供給され得る。
[0112]幾つかの実施形態では、ビデオエンコーダ23は、ビデオエンコーダ20Aにビデオデータを供給する前に、ダウンサンプリングユニット94を使用して下位レイヤエンコーダに供給されるべきビデオデータをダウンサンプリングする。代替的に、ダウンサンプリングユニット94は、ビデオデータをアップサンプリング又はダウンサンプリングすることが可能なリサンプリングユニット90であり得る。また他の実施形態では、ダウンサンプリングユニット94は省略され得る。
[0113]図2Bに示すように、ビデオエンコーダ23は、マルチプレクサ98、即ちmuxを更に含み得る。mux98は、ビデオエンコーダ23から合成ビットストリームを出力することができる。合成ビットストリームは、ビデオエンコーダ20A及び20Bの各々からビットストリームを取ることと、所与の時間において出力されるビットストリームを交替することとによって、作成され得る。場合によっては、2つの(又は、3つ以上のビデオエンコーダレイヤの場合には、より多くの)ビットストリームからのビットが一度に1ビットずつ交替され得るが、多くの場合、ビットストリームは別様に合成される。例えば、出力ビットストリームは、選択されたビットストリームを一度に1ブロックずつ交替することによって作成され得る。別の例では、出力ビットストリームは、ビデオエンコーダ20A及び20Bの各々から非1:1比のブロックを出力することによって作成され得る。例えば、2つのブロックは、ビデオエンコーダ20Aから出力された各ブロックについてビデオエンコーダ20Bから出力され得る。幾つかの実施形態では、mux98からの出力ストリームはプリプログラムされ得る。他の実施形態では、mux98は、発信源機器12を含む発信源機器上のプロセッサからなど、ビデオエンコーダ23の外部のシステムから受信された制御信号に基づいて、ビデオエンコーダ20A、20Bからのビットストリームを合成し得る。制御信号は、ビデオ発信源18からのビデオの解像度又はビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザに関連するサブスクリプション(例えば、有料サブスクリプション対無料サブスクリプション)に基づいて、又はビデオエンコーダ23から望まれる解像度出力を決定するための他のファクタに基づいて生成され得る。
ビデオデコーダ
[0114]図3Aは、本開示で説明する態様による技法を実装し得るビデオデコーダの一例を示すブロック図である。ビデオデコーダ30は、HEVCの場合など、ビデオフレームの単一のレイヤを処理するように構成され得る。更に、ビデオデコーダ30は、本開示の技法のいずれか又は全てを実行するように構成され得る。一例として、動き補償ユニット162及び/又はイントラ予測ユニット164は、本開示で説明する技法のうちのいずれか又は全てを実行するように構成され得る。一実施形態では、ビデオデコーダ30は、本開示で説明する技法のいずれか又は全てを実行するように構成されたレイヤ間予測ユニット166を随意に含み得る。他の実施形態では、レイヤ間予測は、予測処理ユニット152(例えば、動き補償ユニット162及び/又はイントラ予測ユニット164)によって実行され得、その場合、レイヤ間予測ユニット166は省略され得る。しかしながら、本開示の態様はそのように限定されない。幾つかの例では、本開示で説明する技法は、ビデオデコーダ30の様々な構成要素の間で共有され得る。幾つかの例では、追加又は代替として、プロセッサ(図示せず)が、本開示で説明する技法のいずれか又は全てを実行するように構成され得る。
[0115]説明の目的で、本開示は、HEVCコード化のコンテキストにおいてビデオデコーダ30を説明する。しかしながら、本開示の技法は他のコード化規格又は方法に適用可能であり得る。図3Aに示す例は、シングルレイヤコーデックのためのものである。しかしながら、図3Bに関して更に説明するように、ビデオデコーダ30の一部又は全部は、マルチレイヤコーデックの処理のために複製され得る。
[0116]図3Aの例では、ビデオデコーダ30は複数の機能構成要素を含む。ビデオデコーダ30の機能構成要素は、エントロピー復号ユニット150と、予測処理ユニット152と、逆量子化ユニット154と、逆変換ユニット156と、再構成ユニット158と、フィルタユニット159と、復号ピクチャバッファ160とを含む。予測処理ユニット152は、動き補償ユニット162と、イントラ予測ユニット164と、レイヤ間予測ユニット166とを含む。幾つかの例では、ビデオデコーダ30は、図2Aのビデオエンコーダ20に関して説明された符号化経路とは全般に逆の復号経路を実行し得る。他の例では、ビデオデコーダ30は、より多いか、より少ないか、又は異なる機能構成要素を含み得る。
[0117]ビデオデコーダ30は、符号化ビデオデータを備えるビットストリームを受信し得る。ビットストリームは、複数のシンタックス要素を含み得る。ビデオデコーダ30がビットストリームを受信すると、エントロピー復号ユニット150は、ビットストリームに対して構文解析動作を実行し得る。ビットストリームに対して構文解析動作を実行した結果として、エントロピー復号ユニット150は、ビットストリームからシンタックス要素を抽出し得る。構文解析動作を実行することの一部として、エントロピー復号ユニット150は、ビットストリーム中のエントロピー符号化シンタックス要素をエントロピー復号し得る。予測処理ユニット152、逆量子化ユニット154、逆変換ユニット156、再構成ユニット158、及びフィルタユニット159は、ビットストリームから抽出されたシンタックス要素に基づいて、復号ビデオデータを生成する再構成演算を実行し得る。
[0118]上記で説明したように、ビットストリームは、一連のNAL単位を備え得る。ビットストリームのNAL単位は、ビデオパラメータセットNAL単位、シーケンスパラメータセットNAL単位、ピクチャパラメータセットNAL単位、SEI NAL単位などを含み得る。ビットストリームに対して構文解析動作を実行することの一部として、エントロピー復号ユニット150は、シーケンスパラメータセットNAL単位からのシーケンスパラメータセット、ピクチャパラメータセットNAL単位からのピクチャパラメータセット、SEI NAL単位からのSEIデータなどを抽出しエントロピー復号する、構文解析動作を実行し得る。
[0119]更に、ビットストリームのNAL単位は、コード化スライスNAL単位を含み得る。ビットストリームに対して構文解析動作を実行することの一部として、エントロピー復号ユニット150は、コード化スライスNAL単位からコード化スライスを抽出しエントロピー復号する、構文解析動作を実行し得る。コード化スライスの各々は、スライスヘッダとスライスデータとを含み得る。スライスヘッダは、スライスに関するシンタックス要素を含み得る。スライスヘッダ中のシンタックス要素は、スライスを含むピクチャに関連付けられたピクチャパラメータセットを識別するシンタックス要素を含み得る。エントロピー復号ユニット150は、スライスヘッダを復元するために、コード化スライスヘッダ中のシンタックス要素に対してCABAC復号演算などのエントロピー復号演算を実行し得る。
[0120]コード化スライスNAL単位からスライスデータを抽出することの一部として、エントロピー復号ユニット150は、スライスデータ中のコード化されたCUからシンタックス要素を抽出する構文解析動作を実行し得る。抽出されたシンタックス要素は、変換係数ブロックに関連付けられたシンタックス要素を含み得る。エントロピー復号ユニット150は、次いで、シンタックス要素のうちの幾つかに対してCABAC復号演算を実行し得る。
[0121]エントロピー復号ユニット150が、区分されていないCUに対して構文解析動作を実行した後、ビデオデコーダ30は、区分されていないCUに対して再構成演算を実行し得る。区分されていないCUに対して再構成演算を実行するために、ビデオデコーダ30は、CUの各TUに対して再構成演算を実行し得る。CUの各TUについて再構成演算を実行することによって、ビデオデコーダ30は、CUに関連付けられた残差ビデオブロックを再構成し得る。
[0122]TUに対して再構成演算を実行することの一部として、逆量子化ユニット154は、TUに関連付けられた変換係数ブロックを逆量子化(inverse quantize)、例えば、逆量子化(de-quantize)し得る。逆量子化ユニット154は、HEVCのために提案された、又はH.264復号規格によって定義された逆量子化処理と同様の方法で、変換係数ブロックを逆量子化し得る。逆量子化ユニット154は、量子化の程度を決定し、同様に、逆量子化ユニット154が適用すべき逆量子化の程度を決定するために、変換係数ブロックのCUに関してビデオエンコーダ20によって計算される量子化パラメータQPを使用し得る。
[0123]逆量子化ユニット154が変換係数ブロックを逆量子化した後、逆変換ユニット156は、変換係数ブロックに関連付けられたTUのための残差ビデオブロックを生成し得る。逆変換ユニット156は、TUのための残差ビデオブロックを生成するために、変換係数ブロックに逆変換を適用し得る。例えば、逆変換ユニット156は、変換係数ブロックに、逆DCT、逆整数変換、逆カルーネンレーベ変換(KLT:Karhunen-Loeve transform)、逆回転変換、逆方向変換、又は別の逆変換を適用し得る。幾つかの例では、逆変換ユニット156は、ビデオエンコーダ20からの信号伝達に基づいて、変換係数ブロックに適用すべき逆変換を決定し得る。そのような例では、逆変換ユニット156は、変換係数ブロックに関連付けられたツリーブロックの4分木のルートノードにおいて信号伝達された変換に基づいて、逆変換を決定し得る。他の例では、逆変換ユニット156は、ブロックサイズ、コード化モードなど、1つ又は複数のコード化特性から逆変換を推定し得る。幾つかの例では、逆変換ユニット156はカスケード逆変換を適用し得る。
[0124]幾つかの例では、動き補償ユニット162は、補間フィルタに基づく補間を実行することによって、PUの予測ビデオブロックを改良し得る。サブサンプル精度を有する動き補償のために使用されるべき補間フィルタ用の識別子は、シンタックス要素に含まれ得る。動き補償ユニット162は、参照ブロックのサブ整数サンプルについての補間値を計算するために、PUの予測ビデオブロックの生成中にビデオエンコーダ20によって使用された同じ補間フィルタを使用し得る。動き補償ユニット162は、受信されたシンタックス情報に従って、ビデオエンコーダ20によって使用された補間フィルタを決定し得、予測ビデオブロックを生成するためにその補間フィルタを使用し得る。
[0125]図4に関して以下で更に説明するように、予測処理ユニット152は、図4に示される方法を実行することによってPU(又は他のRLブロック及び/又はELブロック又はビデオ単位)をコード化(例えば、符号化又は復号)し得る。例えば、動き補償ユニット162、イントラ予測ユニット164、又はレイヤ間予測ユニット166は、一緒に又は別々に、図4に示される方法を実行するように構成され得る。
[0126]PUが、イントラ予測を使用して符号化される場合、イントラ予測ユニット164は、PUのための予測ビデオブロックを生成するためにイントラ予測を実行し得る。例えば、イントラ予測ユニット164は、ビットストリーム中のシンタックス要素に基づいて、PUのためのイントラ予測モードを決定し得る。ビットストリームは、PUのイントラ予測モードを決定するためにイントラ予測ユニット164が使用し得るシンタックス要素を含み得る。
[0127]幾つかの事例では、イントラ予測ユニット164が現在PUのイントラ予測モードを決定するために別のPUのイントラ予測モードを使用するべきであることを、シンタックス要素が示し得る。例えば、現在PUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることが起こり得る。言い換えれば、隣接PUのイントラ予測モードは、現在PUに対して最確モード(most probable mode)であり得る。従って、この例では、ビットストリームは、PUのイントラ予測モードが隣接PUのイントラ予測モードと同じであることを示す、小さいシンタックス要素を含み得る。イントラ予測ユニット164は、次いで、空間的に隣接するPUのビデオブロックに基づいてPUのための予測データ(例えば、予測サンプル)を生成するために、イントラ予測モードを使用し得る。
[0128]上記で説明したように、ビデオデコーダ30もレイヤ間予測ユニット166を含み得る。レイヤ間予測ユニット166は、スケーラブルビデオコード化において利用可能である1つ又は複数の異なるレイヤ(例えば、BL又はRL)を使用して、現在ブロック(例えば、EL中の現在ブロック)を予測するように構成される。そのような予測は、レイヤ間予測と呼ばれることがある。レイヤ間予測ユニット166は、レイヤ間冗長性を低減するための予測方法を利用し、それによって、コード化効率を改善し、計算リ発信源要件を低減する。レイヤ間予測の幾つかの例は、レイヤ間イントラ予測と、レイヤ間動き予測と、レイヤ間残差予測とを含む。レイヤ間イントラ予測は、EL中の現在ブロックを予測するために、BLの中でコロケートされているブロックの再構成を使用する。レイヤ間動き予測は、EL中の動作を予測するために、BLの動き情報を使用する。レイヤ間残差予測は、ELの残差を予測するために、BLの残差を使用する。レイヤ間予測方式の各々について、以下でより詳細に説明する。
[0129]再構成ユニット158は、CUのビデオブロックを再構成するために、CUのTUに関連付けられた残差ビデオブロック及びCUのPUの予測ビデオブロック、例えば、適用可能なとき、イントラ予測データ又はインター予測データのいずれかを使用し得る。従って、ビデオデコーダ30は、ビットストリーム中のシンタックス要素に基づいて予測ビデオブロックと残差ビデオブロックとを生成し得、予測ビデオブロックと残差ビデオブロックとに基づいてビデオブロックを生成し得る。
[0130]再構成ユニット158がCUのビデオブロックを再構成した後、フィルタユニット159は、CUに関連したブロック歪みを低減するためにデブロッキング演算を実行し得る。フィルタユニット159が、CUに関連したブロック歪みを低減するためにデブロッキング演算を実行した後、ビデオデコーダ30は、CUのビデオブロックを復号ピクチャバッファ160に記憶し得る。復号ピクチャバッファ160は、次の動き補償、イントラ予測、及び図1A又は図1Bの表示装置32などの表示装置上での提示のために、参照ピクチャを提供し得る。例えば、ビデオデコーダ30は、復号ピクチャバッファ160の中のビデオブロックに基づいて、他のCUのPUに対して、イントラ予測演算又はインター予測演算を実行し得る。
マルチレイヤデコーダ
[0131]図3Bは、本開示で説明する態様による技法を実装し得るマルチレイヤビデオデコーダ33(単にビデオデコーダ33とも呼ばれる)の一例を示すブロック図である。ビデオデコーダ33は、SHVC及びマルチビューコード化の場合など、マルチレイヤビデオフレームを処理するように構成され得る。更に、ビデオデコーダ33は、本開示の技法のいずれか又は全てを実行するように構成され得る。
[0132]ビデオデコーダ33は、ビデオデコーダ30Aとビデオデコーダ30Bとを含み、それらの各々はビデオデコーダ30として構成され得、ビデオデコーダ30に関して上記で説明した機能を実行し得る。更に、参照番号の再利用によって示されるように、ビデオデコーダ30A及び30Bは、ビデオデコーダ30としてのシステム及びサブシステムのうちの少なくとも幾つかを含み得る。ビデオデコーダ33は、2つのビデオデコーダ30A及び30Bを含むように示されるが、ビデオデコーダ33は、そのように限定されず、任意の数のビデオデコーダ30のレイヤを含み得る。幾つかの実施形態では、ビデオデコーダ33はアクセス単位中の各ピクチャ又は各フレームに対してビデオデコーダ30を含み得る。例えば、5つのピクチャを含むアクセス単位は、5つのデコーダレイヤを含むビデオデコーダによって処理又は復号され得る。幾つかの実施形態では、ビデオデコーダ33は、アクセス単位中のフレームよりも多くのデコーダレイヤを含み得る。幾つかのそのような場合では、ビデオデコーダのレイヤのうちの幾つかは、幾つかのアクセス単位を処理するときに非アクティブであり得る。
[0133]ビデオデコーダ30A及び30Bに加えて、ビデオデコーダ33は、アップサンプリングユニット92を含み得る。幾つかの実施形態では、アップサンプリングユニット92は、フレーム又はアクセス単位のための参照ピクチャリストに追加されるべき拡張レイヤを作成するために、受信されたビデオフレームのBLをアップサンプリングし得る。この拡張レイヤは、復号ピクチャバッファ160に記憶され得る。幾つかの実施形態では、アップサンプリングユニット92は、図2Aのリサンプリングユニット90に関して説明した実施形態の一部又は全部を含むことができる。幾つかの実施形態では、アップサンプリングユニット92は、レイヤをアップサンプリングし、スライス境界ルール及び/又はラスタ走査ルールのセットに準拠するように、1つ又は複数のスライスを再編成、再定義、修正、又は調整するように構成される。場合によっては、アップサンプリングユニット92は、受信されたビデオフレームのレイヤをアップサンプリング及び/又はダウンサンプリングするように構成されたリサンプリングユニットであり得る。
[0134]アップサンプリングユニット92は、下位レイヤデコーダ(例えば、ビデオデコーダ30A)の復号ピクチャバッファ160からピクチャ又はフレーム(又はピクチャに関連付けられたピクチャ情報)を受信し、ピクチャ(又は受信されたピクチャ情報)をアップサンプリングするように構成され得る。このアップサンプリングされたピクチャは、次いで、下位レイヤデコーダと同じアクセス単位中のピクチャを復号するように構成された、上位レイヤデコーダ(例えば、ビデオデコーダ30B)の予測処理ユニット152に供給され得る。場合によっては、上位レイヤデコーダは、下位レイヤデコーダから除去された1つのレイヤである。他の場合には、図3Bのレイヤ0デコーダとレイヤ1デコーダとの間に、1つ又は複数の上位レイヤデコーダがあり得る。
[0135]場合によっては、アップサンプリングユニット92は、省略又はバイパスされ得る。そのような場合、ビデオデコーダ30Aの復号ピクチャバッファ160からのピクチャは、直接、又は少なくともアップサンプリングユニット92に供給されずに、ビデオデコーダ30Bの予測処理ユニット152に供給され得る。例えば、ビデオデコーダ30Bに供給されたビデオデータ、及びビデオデコーダ30Aの復号ピクチャバッファ160からの参照ピクチャが、同じサイズ又は解像度である場合、参照ピクチャは、アップサンプリングを伴わずにビデオデコーダ30Bに供給され得る。更に、幾つかの実施形態では、アップサンプリングユニット92は、ビデオデコーダ30Aの復号ピクチャバッファ160から受信された参照ピクチャを、アップサンプリング又はダウンサンプリングするように構成されたリサンプリングユニット90であり得る。
[0136]図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は、宛先機器14を含む宛先機器上のプロセッサからなど、ビデオデコーダ33の外部のシステムから受信された制御信号に基づいてビットストリームを分割し得る。制御信号は、入力インターフェース28からのビデオの解像度又はビットレートに基づいて、リンク16の帯域幅に基づいて、ユーザに関連付けられたサブスクリプション(例えば、有料サブスクリプション対無料サブスクリプション)に基づいて、又はビデオデコーダ33によって取得可能な解像度を決定するための他のファクタに基づいて生成され得る。
POC MSBの存在
[0137]上記で説明したように、ビデオコード化拡張(例えば、単一レイヤ規格のスケーラビリティ拡張に関する情報を含むVPS拡張、スライスセグメントヘッダ拡張など)に関する情報がない場合がある単一レイヤビットストリーム(例えば、HEVC符号化ビットストリーム)を復号するとき、マルチレイヤデコーダは問題に遭遇することがある。より詳細には、マルチレイヤデコーダは、ビットストリームの中のアクセス単位が、位置合わせされたそれらのPOC LSBを有する(例えば、アクセス単位の中の全てのピクチャが同じPOC LSBを有する)という表示(例えば、vps_poc_lsb_aligned_flag)がビットストリームの中にないことに基づいて、ビットストリームの中で信号伝達されるべきPOC値のMSBを誤って予想することがある(例えば、マルチレイヤデコーダはPOC値のMSBを受信することを誤って予想することがある)。幾つかの既存の実装形態では、vps_poc_lsb_aligned_flagのセマンティクスは次のように提供され得る。
[0138]0に等しいvps_poc_lsb_aligned_flagは、slice_pic_order_cnt_lsbの値がアクセス単位の異なるピクチャにおいて同じであってもよく同じでなくてもよいことを規定する。1に等しいvps_poc_lsb_aligned_flagは、slice_pic_order_cnt_lsbの値がアクセス単位の全てのピクチャにおいて同じであることを規定する。更に、vps_poc_lsb_aligned_flagの値は、幾つかの既存の実装形態において、ピクチャ順序カウントのための復号プロセスに影響を及ぼすことがある。存在しないとき、vps_poc_lsb_aligned_flagは0に等しいものと推定される。
[0139]フラグがビットストリームの中に存在しないときにvps_poc_lsb_aligned_flagの値又はPOC LSBアライメントの他の表示の値が0であるものと推定することによって、ビットストリームがHEVCビットストリーム(例えば、1つのビデオレイヤだけを有する)である場合、マルチレイヤデコーダが誤った仮定を行う場合がある。HEVCビットストリームでは、通常はPOC LSBアライメントのそのような表示を含むことになるVPS拡張が存在しない場合がある。従って、POC LSBアライメントのそのような表示がないことに基づいて、デコーダは、POC LSBが位置合わせされていない(例えば、同じアクセス単位の中のピクチャが異なるPOC LSBを有し得る)と推定することがあり、そのことは誤っている場合がある。幾つかの実装形態では、そのような推定に基づいて、デコーダは、POC MSB値がビットストリームの中で信号伝達される必要があるかどうかを決定する。例えば、デコーダは、vps_poc_lsb_aligned_flagの0として推定された値に基づいて、POC LSBが位置合わせされていないと最初に決定し、次いで、POC MSB値がビットストリームの中で信号伝達されることを必要とされるかどうかを示すように設計されたパラメータ(例えば、PocMsbValRequiredFlag)を1としての値に設定することによって、そのような決定を行う場合がある。幾つかの実施形態では、POC LSBが位置合わせされていないと決定することに加えて、デコーダは、PocMsbValRequiredFlagを1としての値に設定する前に、デコーダによって処理されている現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであると更に決定する。POC MSB値がビットストリームの中で信号伝達されることを必要とされるかどうかというそのような決定に基づいて、デコーダは、POC MSB値が実際にビットストリームの中に存在するか(例えば、エンコーダによって信号伝達されているか)どうかを決定する。幾つかの実施形態では、デコーダは、次のように提供されるセマンティクスを有するフラグを処理する。
1に等しいpoc_msb_val_present_flagは、poc_msb_valが存在することを規定する。poc_msb_val_present_flagが0に等しくPocMsbValRequiredFlagが0に等しいとき、poc_msb_valが存在しない。存在しないとき、poc_msb_val_present_flagの値は、次のように推定される。
− PocMsbValRequiredFlagが1に等しい場合、poc_msb_val_present_flagの値は1に等しいものと推定される。
− そうでない場合、poc_msb_val_present_flagの値は0に等しいものと推定される。
[0140]従って、上記で説明したように、マルチレイヤデコーダが単一レイヤビットストリームを処理するとき、デコーダは、POC LSBが位置合わせされているという表示がビットストリームの中にないことに基づいて、単一レイヤビットストリームが非整合POC LSBを含むと誤って推定することがあり、誤った推定は、POC MSB値がビットストリームの中で信号伝達される必要があるとデコーダに誤って決定させる。この誤った決定は、POC MSB値がビットストリームの中に実際に存在するとデコーダに誤って推定させる。
[0141]本開示の幾つかの実施例では、誤った決定のこの連鎖を回避するために、POC LSBアライメントの表示がビットストリームの中で提供されないときはいつでも、デコーダはPOC LSBが位置合わせされていると推定し得る。しかしながら、デコーダは、poc_msb_val_present_flagの値が1に等しいものと推定することによって、依然としてPocMsbRequiredFlagの値が1に等しいという決定に基づいてPOC MSB値がビットストリームの中で信号伝達されていると推定し得るので、そのような解決策が問題に完全に対処し得るとは限らない。コーダは、CRAピクチャ又はBLAピクチャをコード化するとき、PocMsbRequiredFlagの値が1に等しいと決定し得る。
[0142]本開示の幾つかの実施例では、デコーダは、スライスセグメントヘッダ拡張がビットストリームの中に存在することに基づいて、poc_msb_val_present_flagの値を決定し得る。デコーダはまた、スライスセグメントヘッダ拡張長の長さを示すフラグの値に基づいて、poc_msb_val_present_flagの値を決定し得る。例えば、以下に示すように、slice_segment_header_extension_lengthが0に等しくないときのみシンタックス要素にとっての1としての値がpoc_msb_valが存在することを規定するように、poc_msb_val_present_flagのセマンティクスが改変されてよい。追加はイタリック体で示され、削除は[[二重括弧]]で示される。
1に等しいpoc_msb_val_present_flagは、poc_msb_valが存在することを規定する。poc_msb_val_present_flagが0に等し[[くPocMsbValRequiredFlagが0に等し]]いとき、poc_msb_valは存在しない。存在しないとき、poc_msb_val_present_flagの値は、次のように推定される。
− slice_segment_header_extension_lengthが0に等しい場合、poc_msb_val_present_flagの値は0に等しいものと推定される。
− そうでなく、PocMsbValRequiredFlagが1に等しい場合、poc_msb_val_present_flagの値は1に等しいものと推定される。
− そうでない場合、poc_msb_val_present_flagの値は0に等しいものと推定される。
[0143]図4は、本開示の一実施形態によるビデオ情報をコード化するための方法400を示すフローチャートである。図4に示すステップは、エンコーダ(例えば、図2A又は図2Bに示すようなビデオエンコーダ)、デコーダ(例えば、図3A又は図3Bに示すようなビデオデコーダ)、又は任意の他の構成要素によって実行され得る。便宜上、方法400は、エンコーダ、デコーダ、又は別の構成要素であり得るコーダによって実行されるように説明される。
[0144]方法400は、ブロック401において開始する。ブロック405において、コーダが、スライスセグメントヘッダ拡張が存在するかどうかを決定する。コーダは、ある長さのスライスセグメントヘッダ拡張を示しビットストリームの中で提供されるフラグに基づいて、スライスセグメントヘッダ拡張(例えば、コーダによって処理されている現在ピクチャ又は現在スライスに関連したもの)がビットストリームの中に存在するかどうかを決定し得る。コーダはまた、スライスセグメントヘッダ拡張がビットストリームの中に存在するかどうかを示しビットストリームの中で提供されるフラグに基づいて、スライスセグメントヘッダ拡張がビットストリームの中に存在するかどうかを決定し得る。そのようなフラグは、スライスセグメントヘッダ、VPS、PPS、SPSなどの中などの、ビットストリームの他の部分において提供されてよい。スライスセグメントヘッダ拡張がビットストリームの中に存在しないとコーダが決定する場合、方法400はブロック410に進む。一方、スライスセグメントヘッダ拡張がビットストリームの中に存在するとコーダが決定する場合、方法400はブロック415に進む。
[0145]ブロック410において、コーダは、POC MSB値(例えば、コーダによって処理されている現在ピクチャ又は現在スライスに関連したもの)がビットストリームの中に存在しないと決定する。POC MSB値がビットストリームの中に存在しないと決定することの結果として、コーダは、POC MSB値がビットストリームの中に存在するかどうかを示すように構成されたフラグを0としての値に設定し得る。本開示の幾つかの実施例では、コーダは、コーダが場合によっては処理するように構成されるビットストリームの中のPOC MSB値を処理することを控える場合がある。
[0146]ブロック415において、コーダは、ビットストリームの中のPOC MSB値を処理する。例えば、コーダは、ビットストリームを復号していることがあり、ブロック405においてスライスセグメントヘッダ拡張がビットストリームの中に存在すると決定した後、コーダは、ビットストリームの中で提供されるPOC MSB値を処理(又は、予想)し得る。コーダによって処理されている現在ピクチャに関連したPOC値を計算するために、及び/又はビットストリームの中で提供されるピクチャに関連したPOC値をリセット若しくは位置合わせするために、コーダは処理されたPOC MSB値を更に使用し得る。方法400は、420において終了する。
[0147]上記で説明したように、図2Aのビデオエンコーダ20、図2Bのビデオエンコーダ23、図3Aのビデオデコーダ30、又は図3Bのビデオデコーダ33の1つ又は複数の構成要素(例えば、レイヤ間予測ユニット128及び/又はレイヤ間予測ユニット166)は、スライスセグメントヘッダ拡張がビットストリームの中に存在するかどうかを決定すること、POC MSB値がビットストリームの中に存在しないと決定すること、及びビットストリームの中で提供されるPOC MSBを処理することなどの、本開示で説明する技法のいずれかを実施するために使用され得る。
[0148]方法400において、図4に示すブロックのうちの1つ又は複数は、削除される(例えば、実行されない)ことがあり、修正されることがあり、及び/又は方法400が実行される順序は入れ替えられることがある。例えば、405における決定を行う前に、コーダは、POC LSBが位置合わせされているかどうかを最初に決定してよく(例えば、ビットストリームの中で提供されるフラグを検査することによって)、POC LSBが位置合わせされていないという決定の後のみ、ブロック405に進んでよい。別の実施形態では、POC LSBが位置合わせされていると決定することに加えて、又はその代わりに、コーダは、ブロック405に進む前に、コーダによって処理されている現在ピクチャがCRAピクチャ又はBLAピクチャであると決定してよい。例えば、コーダは、POC LSBが位置合わせされておらず現在ピクチャがCRAピクチャ又はBLAピクチャであると決定した後、ブロック405に進んでよい。別の実施形態では、ブロック405において、コーダは、POC MSB値が信号伝達されることが必要とされると決定してよいが(例えば、PocMsbValRequiredFlagの値を1としての値に設定することによって)、そのような決定にかかわらず、スライスセグメントヘッダ拡張が存在しないという決定に基づいてブロック410に進んでよい。別の実施形態では、ブロック410が削除されてよく、スライスセグメントヘッダ拡張が存在しないとコーダが決定する場合、方法400はいかなる追加の動作も実行することなく終了してよい。また別の実施形態では、ブロック415が削除されてよく、たとえスライスセグメントヘッダ拡張が存在するとコーダが決定しても、POC MSBがビットストリームの中で提供されないとコーダが決定する場合、いかなる追加の動作も実行することなく方法400は終了してよい。従って、本開示の実施形態は、図4に示す例に限定されず、又は図4に示す例によって限定されず、他の変形が本開示の趣旨から逸脱することなく実施され得る。
イントラランダムアクセスポイント(IRAP)ピクチャ
[0149]幾つかのビデオコード化方式は、ビットストリームが、そのようなランダムアクセスポイントに先行するいかなるピクチャも復号する必要なく、そのようなランダムアクセスポイントのいずれかから始めて復号され得るような、ランダムアクセスポイントをビットストリーム全体にわたって提供し得る。そのようなビデオコード化方式では、出力順序においてランダムアクセスポイントに追従する全てのピクチャ(例えば、ランダムアクセスポイントを提供するピクチャと同じアクセス単位の中にあるピクチャを含む)は、ランダムアクセスポイントに先行するいかなるピクチャも使用することなく正しく復号され得る。例えば、ビットストリームの一部分が送信の間又は復号の間に失われても、デコーダは、次のランダムアクセスポイントから始めてビットストリームの復号を再開することができる。ランダムアクセスのサポートは、例えば、動的なストリーミングサービス、シーク動作、チャネル切替えなどを容易にし得る。
[0150]幾つかのコード化方式では、そのようなランダムアクセスポイントは、イントラランダムアクセスポイント(IRAP)ピクチャと呼ばれるピクチャによって提供され得る。例えば、layerBの中にあり復号順序においてauAに先行するアクセス単位(「auB」)の中に含まれるランダムアクセスポイント(又は、auAの中に含まれるランダムアクセスポイント)を有するlayerAの各参照レイヤ(「layerB」)(例えば、layerAを予測するために使用されるレイヤである参照レイヤ)に関して出力順序においてauBに追従するlayerAの中のピクチャ(auBの中に位置するそれらのピクチャを含む)が、auBに先行するlayerAの中のいかなるピクチャも復号する必要なく正しく復号可能であるように、アクセス単位(「auA」)の中に含まれる拡張レイヤ(「layerA」)の中のランダムアクセスポイント(例えば、拡張レイヤIRAPピクチャによって提供される)は、レイヤ特有のランダムアクセスを提供し得る。
[0151]IRAPピクチャは、イントラ予測(例えば、他のピクチャを参照することなくコード化される)を使用してコード化され得、例えば、瞬時デコーダリフレッシュ(IDR)ピクチャと、CRAピクチャと、BLAピクチャとを含み得る。ビットストリームの中にIDRピクチャがあるとき、復号順序においてIDRピクチャに先行する全てのピクチャは、復号順序においてIDRピクチャに追従するピクチャによる予測のために使用されない。ビットストリームの中にCRAピクチャがあるとき、CRAピクチャに追従するピクチャは、復号順序においてCRAピクチャに先行するピクチャを予測のために使用してよく、又は使用しなくてもよい。復号順序においてCRAピクチャに追従するが、復号順序においてCRAピクチャに先行するピクチャを使用するピクチャは、ランダムアクセススキップド進み(RASL:random access skipped leading)ピクチャと呼ばれることがある。復号順序においてIRAPピクチャに追従するとともに出力順序においてIRAPピクチャに先行する別のタイプのピクチャは、復号順序においてIRAPピクチャに先行するいかなるピクチャへの参照も含まないことがあるランダムアクセス復号可能進み(RADL:random access decodable leading)ピクチャである。CRAピクチャに先行するピクチャが利用可能でない場合、RASLピクチャはデコーダによって廃棄されてよい。BLAピクチャは、(例えば、2つのビットストリームが互いに接合され、BLAピクチャが復号順序において第2のビットストリームの最初のピクチャであるので)BLAピクチャに先行するピクチャがデコーダにとって利用可能でない場合があることを、デコーダに示す。IRAPピクチャであるベースレイヤのピクチャ(例えば、0としてのレイヤID値を有するピクチャ)を含むアクセス単位(例えば、複数のレイヤにわたって同じ出力時間に関連付けられた全てのコード化ピクチャからなるピクチャのグループ)は、IRAPアクセス単位と呼ばれることがある。
IRAPピクチャの交差レイヤ配列(Cross-Layer Alignment)
[0152]幾つかの既存のコード化方式では、IRAPピクチャは、異なるレイヤにわたる位置合わせ(例えば、同じアクセス単位に含まれる)を必要とされなくてよい。例えば、IRAPピクチャが位置合わせを必要とされるのであれば、少なくとも1つのIRAPピクチャを含むいかなるアクセス単位もIRAPピクチャのみを含むはずである。一方、IRAPピクチャが位置合わせを必要とされないのであれば、単一のアクセス単位の中で、1つのピクチャ(例えば、第1のレイヤの中の)がIRAPピクチャであってよく、別のピクチャ(例えば、第2のレイヤの中の)が非IRAPピクチャであってよい。ビットストリームの中にそのような非整合IRAPピクチャを有することは、幾つかの利点をもたらすことがある。例えば、2レイヤビットストリームの中で、拡張レイヤの中よりも多くのIRAPピクチャがベースレイヤの中にある場合、ブロードキャスト及びマルチキャストの適用例において、小さい同調遅延及び高いコード化効率が達成され得る。
[0153]幾つかのビデオコード化方式では、POCが、復号ピクチャが表示される相対的な順序を追跡するために使用され得る。そのようなコード化方式のうちの幾つかは、幾つかのタイプのピクチャがビットストリームの中で処理されるときはいつでも、POC値をリセット(例えば、0に設定、又はビットストリームの中で信号伝達された幾つかの値に設定)させ得る。そのようなピクチャは、POCリセッティングピクチャと呼ばれることがある。例えば、ある種のIRAPピクチャのPOC値がリセットされてよく、復号順序においてそれらのIRAPピクチャに先行する他のピクチャのPOC値もリセットさせる。IRAPピクチャが異なるレイヤにわたる位置合わせを必要とされないとき、このことが問題となり得る。例えば、あるピクチャ(「picA」)がIRAPピクチャであり同じアクセス単位の中の別のピクチャ(「picB」)がIRAPピクチャでないとき、picAがIRAPピクチャであることに起因してリセットされる、picAを含むレイヤの中のピクチャ(「picC」)のPOC値は、picBを含むレイヤの中のリセットされないピクチャ(「picD」)のPOC値と異なることがあり、ここで、picC及びpicDは同じアクセス単位の中にある。このことは、それらが同じアクセス単位(例えば、同じ出力時間)に属していても、picC及びpicDが異なるPOC値を有することを引き起こす。従って、この例では、picC及びpicDのPOC値を導出するための導出プロセスは、POC値及びアクセス単位の定義と一致するPOC値を生成するように修正され得る。
POCリセッティング期間にわたる長期参照ピクチャ
[0154]特定のELのCRAピクチャ及び/又はそのようなCRAピクチャに関連したRASLピクチャが予測のために長期参照ピクチャ(LTRP)を利用し、復号順序においてLTRPに後続するとともに復号順序においてCRAピクチャに先行する1つ又は複数のPOCリセッティングピクチャが同じレイヤの中に存在するとき、復号順序においてCRAピクチャに先行する1つ又は複数のPOCリセッティングピクチャを除去することによって取得される幾つかのビットストリームは、予測のためにCRAピクチャ及び/又はRASLピクチャに間違ったピクチャを参照させる場合があり、又はそれらの参照ピクチャのうちの幾つかを予測のために利用不可能とさせる場合がある。
[0155]図5は、EL510とBL520とを含むマルチレイヤビットストリーム500を示す。EL510はELピクチャ511〜518を含み、BLはBLピクチャ521〜528を含む。マルチレイヤビットストリーム500は、アクセス単位(AU)530〜537を更に含む。図5に示すように、AU530はELピクチャ511とBLピクチャ521とを含み、AU531はELピクチャ512とBLピクチャ522とを含み、AU532はELピクチャ513とBLピクチャ523とを含み、AU533はELピクチャ514とBLピクチャ524とを含み、AU534はELピクチャ515とBLピクチャ525とを含み、AU535はELピクチャ516とBLピクチャ526とを含み、AU536はELピクチャ517とBLピクチャ527とを含み、AU537はELピクチャ518とBLピクチャ528とを含む。図5の例では、BLピクチャ522〜524はIDRピクチャであり、ELピクチャ515はCRAピクチャであり、ELピクチャ516はCRAピクチャ515に関連したRASLピクチャである。ELピクチャ511は、RASLピクチャ516のLTRPである(例えば、RASLピクチャ516はLTRP511に基づいてコード化される)。ELピクチャ512〜514は、POCリセッティングピクチャである。従って、ビットストリーム500は、クロスレイヤ位置合わせされていないIRAPピクチャ(例えば、IDRピクチャ522〜524)を含む。
[0156]図5の例では、LTRP511だけがRASLピクチャ516が使用する参照ピクチャである場合、RASLピクチャ516がLTRP511を参照用に使用するので、CRAピクチャ515の参照ピクチャセット(RPS)サブセットRefPicSetLtFoll(例えば、復号順序においてCRAピクチャ515に後続するピクチャによる参照のために使用される1組のLTRP)は、LTRP511を含み得る。同様に、POCリセッティングピクチャ512〜514はまた、それらのそれぞれのRPSの中にLTRP511を有し得る。本開示の幾つかの実施例では、ミドルボックスは、(例えば、幾つかの帯域幅条件を満たすために、又はより小さい利用可能な帯域幅に適用させるために)ダウンスイッチとその後に続くアップスイッチにビットストリームを従属させ得る。そのような実施形態では、ミドルボックスは、図6に示されるビットストリーム600を生成し得る。図6のマルチレイヤビットストリーム600は、EL610とBL620とを含む。EL610はELピクチャ611及び615〜618を含み、BLはBLピクチャ621〜628を含む。マルチレイヤビットストリーム600は、AU630〜637を更に含む。図6に示すように、AU630はELピクチャ611とBLピクチャ621とを含み、AU631はBLピクチャ622を含み、AU632はBLピクチャ623を含み、AU633はBLピクチャ624を含み、AU634はELピクチャ615とBLピクチャ625とを含み、AU635はELピクチャ616とBLピクチャ626とを含み、AU636はELピクチャ617とBLピクチャ627とを含み、AU637はELピクチャ618とBLピクチャ628とを含む。図6の例では、BLピクチャ622〜624はIDRピクチャであり、ELピクチャ615はCRAピクチャであり、ELピクチャ616はCRAピクチャ615に関連したRASLピクチャである。ELピクチャ611は、RASLピクチャ616のLTRPである(例えば、RASLピクチャ616はLTRP611に基づいてコード化される)。図6に示すように、図5のPOCリセッティングピクチャ512〜514に対応するELピクチャは、ビットストリーム600から除去されている。
[0157]図6の例では、LTRP611は、EL610に対応するサブ復号ピクチャバッファ(DPB)の中で利用可能であり得る。しかしながら、ダウンスイッチ及びアップスイッチの結果として、復号順序においてLTRP611に後続するがCRAピクチャ615に先行するPOCリセッティングピクチャに関連して実行されるPOCリセットによってデクリメントされているはずの(但し、ダウンスイッチ及びアップスイッチに対して)LTRP611のPOCは、デクリメントされない。ダウンスイッチ及びアップスイッチの間にPOCリセッティングピクチャが除去されたので、そのようなPOCリセッティングピクチャに先行するピクチャ(LTRP611を含む)のPOCがデクリメントされるべき量が失われる(又は、ビットストリーム600を処理しているデコーダによって決定可能でない)。例えば、ビットストリーム600に対して使用されるPOC LSB長が8ビットであり、CRAピクチャ615に関連したRPSが元のビットストリーム500の中のLTRP611のPOC LSB(例えば、100)を使用してLTRP611を参照する場合、ダウンスイッチ及びアップスイッチの後、LTRP611を参照するためにCRAピクチャ615のRPSによって使用されるPOC LSBはもはや有効でない。CRAピクチャ615のNAL単位タイプがBLAピクチャのNAL単位タイプのうちの1つへと変化せず、又はCRAピクチャ615に対応するHandleCraAsBlaFlagが1としての値に設定されない場合、得られたビットストリーム600は、非適合ビットストリームとみなされることになる。この例では、RASLピクチャ616だけがLTRP611を参照用に使用するとき、RASLピクチャ616が正しく復号可能であるので、CRAピクチャ615をBLAピクチャとしてマークし、又はそのフラグHandleCraAsBlaFlagの値を1としての値に変更する必要がない。
[0158]本開示の幾つかの実施例では、RASLピクチャ616がLTRP611の代わりに短期参照ピクチャ(STRP)を参照しており、STRPがビットストリームから除去される場合、STRPを除去するミドルボックスは、RASLピクチャ616に関連したCRAピクチャ(例えば、図6の例におけるCRAピクチャ615)のNAL単位タイプを変更すること、又はCRAピクチャがBLAピクチャとして処理され得るように、そのようなCRAピクチャに対応するHandleCraAsBlaFlagの値を1に等しく設定することが義務付けられ得る。
[0159]本開示の幾つかの実施例では、RASLピクチャの関連するIRAPピクチャに復号順序において先行する同じレイヤの中のPOCリセッティングピクチャに先行するLTRPをRASLピクチャが使用できないことを、ビットストリーム適合制約は規定し得る。そのような実施形態では、コーダは、そのようなビットストリーム制約が適用可能であることを決定し得、コード化ビットストリームがビットストリーム制約に適合するようなビットストリーム制約に忠実に従い得る。図5の例では、RASLピクチャ516は、LTRP511を参照用に使用できないことになる。本開示の幾つかの実施例では、CRAと同じレイヤの中にありCRAピクチャに復号順序において先行する任意のPOCリセッティングピクチャに復号順序において先行するいかなるLTRPもCRAピクチャがそのRPSの中に含めることができないことを、ビットストリーム適合制約は規定し得る。本開示の幾つかの実施例では、CRAと同じレイヤの中にありCRAピクチャに復号順序において先行する任意のPOCリセッティングピクチャに復号順序において先行するいかなるピクチャもCRAピクチャがそのRPSの中に含めることができないことを、ビットストリーム適合制約は規定し得る。本開示の幾つかの実施例では、本明細書で説明するビットストリーム適合制約は、0よりも大きいnuh_layer_idを有するレイヤ(例えば、ベースレイヤ以外のレイヤ)に適用され得る。
[0160]例えば、ビットストリーム適合制約は、RPSへの以下の制約、即ち、「存在するとき、CRAピクチャのRefPicSetLtFollの中のいかなるピクチャも、CRAピクチャに復号順序において先行し、CRAピクチャと同じnuh_layer_idを有するPOCリセッティングピクチャに先行してはならないことがビットストリーム適合の要件である」ことを含むことによって実施され得る。代替的に、以下の制約、即ち、「0よりも大きいnuh_layer_idを有するCRAピクチャのRPSの中のいかなるピクチャも、CRAピクチャに復号順序において先行し、CRAピクチャと同じnuh_layer_idを有する任意のPOCリセッティングピクチャに復号順序において先行してはならないことがビットストリーム適合の要件である」ことが使用され得る。
POCリセッティング期間の中にピクチャがないこと
[0161]特定のレイヤにおいてPOCリセッティング期間全体(例えば、POCリセットとともに開始し次のPOCリセットの直前に終了する期間)にわたってビットストリームがいかなるピクチャも含まない場合、エンコーダは、幾つかのユースケースにおいて適合ビットストリームを生成できないことがある。例えば、各レイヤの中のピクチャに関連したPOC値は、そのレイヤに属しておりPOCリセッティング期間に含まれる最初のピクチャ(例えば、POCリセッティングピクチャ)において利用可能な情報に基づいてデクリメントされる。特定のレイヤがいかなるピクチャも所与のPOCリセッティング期間に含まないとき、特定のレイヤの中のピクチャに関連したPOC値がデクリメントされるべき量は、利用可能又は決定可能でない場合がある。この問題が図7に示される。
[0162]図7は、EL710とBL720とを含むマルチレイヤビットストリーム700を示す。EL710はELピクチャ711、712、及び715〜718を含み、BLはBLピクチャ721〜728を含む。マルチレイヤビットストリーム700は、AU730〜737を更に含む。図7に示すように、AU730はELピクチャ711とBLピクチャ721とを含み、AU731はELピクチャ712とBLピクチャ722とを含み、AU732はBLピクチャ723を含み、AU733はBLピクチャ724を含み、AU734はELピクチャ715とBLピクチャ725とを含み、AU735はELピクチャ716とBLピクチャ726とを含み、AU736はELピクチャ717とBLピクチャ727とを含み、AU737はELピクチャ718とBLピクチャ728とを含む。図7の例では、BLピクチャ723はIDRピクチャであり、BLピクチャ725はCRAピクチャである。IDRピクチャ723、CRAピクチャ725、及びELピクチャ715は、1又は2に等しいpoc_reset_idc値(例えば、完全なPOCリセット又はPOC MSBリセットを示す)を有するPOCリセッティングピクチャである。
[0163]図7に示すように、ビットストリーム700は、AU732からAU733までいかなるELピクチャも含まない。従って、IDRピクチャ723に関連したPOCリセット(例えば、AU732の中のピクチャの完全なPOCリセット)をコーダが実行するとき、コーダは、AU732に先行するELピクチャがデクリメントされるべき量を知らないことがある。ELピクチャ715に関連したpoc_reset_idcが、POC MSBリセットがAU734において実行されるべきであることを示す場合、コーダは、AU732において実行されなかったが実行されているべきELピクチャのPOCデクリメントに気付いていない場合がある。
[0164]本開示の幾つかの実施例では、POCデクリメント情報がスライスセグメントヘッダ拡張の中で更に信号伝達され、この追加の情報は、現在ピクチャと同じレイヤの中にあり前に復号されたピクチャのPOC値がデクリメントされるべき値を導出するために使用され得る。他の実施形態では、ピクチャがPOC MSBリセット(例えば、完全なリセットでない)に関連付けられたPOCリセッティングピクチャであるときのみ、追加のPOCデクリメント情報が送られてよい。これらの特徴は以下に示すように実施され得る。
スライスセグメントヘッダシンタックスへの変更
[0165]3としての値に等しいpoc_reset_idcに関連した機能が削除され別個のフラグとして提供される場合、エンコーダは、図7に示すビットストリームを符号化できる場合がある。この変更は、3としての値に等しいpoc_reset_idcに関連した機能が、この変更の前に1又は2としてのpoc_reset_idc値に関連付けられていたピクチャのために使用され得ることを可能にし得る。シンタックス、セマンティクス、及び復号プロセスへの変更が以下に強調され、追加はイタリック体で示され、削除は[[二重括弧]]で示される。表1は、slice_segment_header()シンタックスへの変更を示す。
スライスセグメントヘッダセマンティクスへの変更
[0166]スライスセグメントヘッダセマンティクスは以下に示すように修正されてよく、ここで、追加はイタリック体で示され、削除は[[二重括弧]]で示される。
0に等しいpoc_reset_idcは、現在ピクチャに対するピクチャ順序カウント値の最上位ビットも最下位ビットもリセットされないことを規定する。1に等しいpoc_reset_idcは、現在ピクチャに対するピクチャ順序カウント値の最上位ビットだけがリセットされ得ることを規定する。2に等しいpoc_reset_idcは、現在ピクチャに対するピクチャ順序カウント値の最上位ビットと最下位ビットの両方がリセットされ得ることを規定する。[[3に等しいpoc_reset_idcは、現在ピクチャに対するピクチャ順序カウント値の最上位ビットのみ、又は最上位ビットと最下位ビットの両方がリセットされ得、追加のピクチャ順序カウント情報が信号伝達されることを規定する。]]存在しないとき、poc_reset_idcの値は0に等しいものと推定される。
次の制約が適用されることは、ビットストリーム適合の要件である。
− RASLピクチャ、RADLピクチャ、サブレイヤ非参照ピクチャ、又は0よりも大きいTemporalIdを有するピクチャ、又は1に等しいdiscardable_flagを有するピクチャに対して、poc_reset_idcの値は1又は2に等しくてはならない。
− アクセス単位の中の全てのピクチャのpoc_reset_idcの値は、同じでなければならない。
− アクセス単位の中の0に等しいnuh_layer_idを有するピクチャが、nal_unit_typeとしての特定の値を有するIRAPピクチャであり、同じアクセス単位の中のnal_unit_typeとしての異なる値を有する少なくとも1つの他のピクチャが存在するとき、そのアクセス単位の中の全てのピクチャに対して、poc_reset_idcの値は1又は2に等しくなければならない。
− 0よりも大きいnuh_layer_idを有するとともにアクセス単位の中のnal_unit_typeとしての特定の値を有するIDRピクチャである少なくとも1つのピクチャが存在し、同じアクセス単位の中のnal_unit_typeとしての異なる値を有する少なくとも1つの他のピクチャが存在するとき、そのアクセス単位の中の全てのピクチャに対して、poc_reset_idcの値は1又は2に等しくなければならない。
− CRAピクチャ又はBLAピクチャのpoc_reset_idcの値は、3よりも小さくなければならない。
− アクセス単位の中の0に等しいnuh_layer_idを有するピクチャがIDRピクチャであり、同じアクセス単位の中の少なくとも1つの非IDRピクチャが存在するとき、そのアクセス単位の中の全てのピクチャに対して、poc_reset_idcの値は2に等しくなければならない。
− アクセス単位の中の0に等しいnuh_layer_idを有するピクチャがIDRピクチャでないとき、そのアクセス単位の中のいかなるピクチャに対しても、poc_reset_idcの値は2に等しくてはならない。
アクセス単位のpoc_reset_idcの値は、そのアクセス単位の中のピクチャのpoc_reset_idcの値である。
poc_reset_period_idは、POCリセッティング期間を識別する。poc_reset_period_idとしての同じ値と1又は2に等しいpoc_reset_idcとを有する同じレイヤの中に、復号順序において連続する2つのピクチャがあってはならない。存在しないとき、poc_reset_period_idの値は、次のように推定される。
− 現在ピクチャとビットストリームの同じレイヤの中の現時点においてスライスセグメントヘッダの中に存在するpoc_reset_period_idを有する前のピクチャpicAの場合、poc_reset_period_idの値はpicAのpoc_reset_period_idの値に等しいものと推定される。
− そうでない場合、poc_reset_period_idの値は0に等しいものと推定される。
注− レイヤの中の複数のピクチャがpoc_reset_period_idとしての同じ値を有するとともに1又は2に等しいpoc_reset_idcを有することは、そのようなピクチャが復号順序において連続した2つのアクセス単位の中に出現しない限り禁止されていない。そのような2つのピクチャがピクチャ喪失、ビットストリーム抽出、シーキング、又は接合動作に起因してビットストリームの中に現れる可能性を最小限に抑えるために、エンコーダは、poc_reset_period_idの値を各POCリセッティング期間に対してランダムな値となるように設定するべきである(上記で規定される制約を条件として)。
次の制約が適用されることは、ビットストリーム適合の要件である。
− 1つのPOCリセッティング期間は、1又は2に等しいpoc_reset_idcを有する1つよりも多いアクセス単位を含んではならない。
− 1又は2に等しいpoc_reset_idcを有するアクセス単位は、POCリセッティング期間の中の最初のアクセス単位でなければならない。
− POCリセッティング期間の全てのレイヤの中で復号順序における最初のPOCリセッティングピクチャに復号順序において後続するピクチャは、復号順序における最初のPOCリセッティングピクチャに先行するいかなるレイヤの中の別のピクチャにも出力順序において先行してはならない。
1に等しいpoc_decrement_info_present_flagは、シンタックス要素full_poc_reset_flag及びpoc_lsb_valがスライスヘッダ拡張の中で信号伝達されることを規定する。0に等しいpoc_decrement_info_present_flagは、シンタックス要素full_poc_reset_flag及びpoc_lsb_valがスライスヘッダ拡張の中で信号伝達されないことを規定する。
1に等しいfull_poc_reset_flagは、同じレイヤの中の復号順序における前のピクチャが同じPOCリセッティング期間に属さないとき、現在ピクチャに対するピクチャ順序カウント値の最上位ビットと最下位ビットの両方がリセットされることを規定する。0に等しいfull_poc_reset_flagは、同じレイヤの中の復号順序における前のピクチャが同じPOCリセッティング期間に属さないとき、現在ピクチャに対するピクチャ順序カウント値の最上位ビットだけがリセットされることを規定する。
poc_lsb_valは、現在ピクチャのピクチャ順序カウントを導出するために使用され得る値を規定する。poc_lsb_valシンタックス要素の長さは、log2_max_pic_order_cnt_lsb_minus4+4ビットである。
poc_decrement_info_present_flagが1に等しく[[poc_reset_idcが3に等しく]]、また、現在ピクチャと同じレイヤの中にあり、1又は2に等しいpoc_reset_idcを有し、同じPOCリセッティング期間に属する復号順序における前のピクチャpicAがビットストリームの中に存在するとき、picAが、現在ピクチャと同じレイヤの中にあり、RASLピクチャ、RADLピクチャ、又はサブレイヤ非参照ピクチャでなく、0に等しいTemporalIdと0に等しいdiscardable_flagを有する、復号順序における前のピクチャと同じピクチャでなければならないことと、現在ピクチャのpoc_lsb_valの値がpicAのslice_pic_order_cnt_lsbの値に等しくなければならないこととは、ビットストリーム適合の要件である。
変数PocMsbValRequiredFlagは次のように導出される。
[0167]代替的に、以下の制約がビットストリーム適合制約として追加される。
次の制約が適用されることは、ビットストリーム適合の要件である。
− poc_decrement_info_present_flagが1に等しいとき、poc_reset_idcは0又は2に等しくてはならない。
[0168]代替的に、以下の制約がビットストリーム適合制約として追加される。
次の制約が適用されることは、ビットストリーム適合の要件である。
− poc_decrement_info_present_flagが1に等しいとき、poc_reset_idcは2に等しくてはならない。
POCの復号プロセスへの変更
[0169]HEVC規格に記載される既存の復号プロセスが以下に示すように修正されてよく、ここで、追加はイタリック体で示され、削除は[[二重括弧]]で示される。
F.8.3.1 ピクチャ順序カウントのための復号プロセス
このプロセスの出力は、PicOrderCntVal、現在ピクチャのピクチャ順序カウントである。
ピクチャ順序カウントは、マージモードにおける動きパラメータ、及び動きベクトル予測を導出するために、並びにデコーダ適合検査のために、ピクチャを識別するために使用される(サブクローズC.5参照)。
各コード化ピクチャは、PicOrderCntValとして示されるピクチャ順序カウント変数に関連付けられる。
現在ピクチャがPOCリセッティング期間の全てのレイヤの中で最初のピクチャであるとき、両端値を含む0〜62としての範囲の中のiの各値に対して、変数PocDecrementedInDPBFlag[i]は0に等しく設定される。
変数pocResettingFlagは次のように導出される。
− 現在ピクチャがPOCリセッティングピクチャである場合、次のことが適用される。
− vps_poc_lsb_aligned_flagが0に等しい場合、pocResettingFlagは1に等しく設定される。
− そうでない場合、PocDecrementedInDPBFlag[nuh_layer_id]が1に等しい場合、pocResettingFlagは0に等しく設定される。
− そうでない場合、pocResettingFlagは1に等しく設定される。
− そうでない場合、pocResettingFlagは0に等しく設定される。
リストaffectedLayerListは次のように導出される。
− vps_poc_lsb_aligned_flagが0に等しい場合、affectedLayerListは現在ピクチャのnuh_layer_idからなる。
− そうでない場合、affectedLayerListは、現在ピクチャのnuh_layer_id、及び両端値を含む0〜NumPredictedLayers[currNuhLayerId]−1としての範囲の中のjの全ての値に対してPredictedLayerId[currNuhLayerId][j]に等しいnuh_layer_id値からなり、ここで、currNuhLayerIdは現在ピクチャのnuh_layer_id値である。
pocResettingFlagが1に等しい場合、次のことが適用される。
− FirstPicInLayerDecodedFlag[nuh_layer_id]が1に等しいとき、次のことが適用される。
− 変数pocMsbDelta、pocLsbDelta、及びDeltaPocValは次のように導出される。
− DPBの中にあり、それに対してPocDecrementedInDPBFlag[nuhLayerId]が0に等しくaffectedLayerListの中の任意の値に等しいnuh_layer_id値nuhLayerIdを有する各ピクチャのPicOrderCntValは、DeltaPocValだけデクリメントされる。
− affectedLayerListに含まれるnuhLayerIdの各値に対して、PocDecrementedInDPBFlag[nuhLayerId]は1に等しく設定される。
− 現在ピクチャのPicOrderCntValは次のように導出される。
そうでない場合、次のことが適用される。
− 現在ピクチャのPicOrderCntValは次のように導出される。
affectedLayerListに含まれるlId値の各々に対するPrevPicOrderCnt[lId]の値は、次のように導出される。
− 現在ピクチャがRASLピクチャ、RADLピクチャ、又はサブレイヤ非参照ピクチャでなく、現在ピクチャが0に等しいTemporalIdと0に等しいdiscardable_flagとを有する場合、PrevPicOrderCnt[lId]はPicOrderCntValに等しく設定される。
− そうでない場合、poc_decrement_info_present_flagが1に等しく[[poc_reset_idcが3に等しく]]以下の条件のうちの1つが真であるとき、PrevPicOrderCnt[lId]は(full_poc_reset_flag?0:poc_lsb_val)に等しく設定される。
− FirstPicInLayerDecodedFlag[nuh_layer_id]が0に等しい。
− FirstPicInLayerDecodedFlag[nuh_layer_id]が1に等しく現在ピクチャがPOCリセッティングピクチャである。
PicOrderCntValの値は、両端値を含む−231〜231−1としての範囲の中になければならない。1つのCVSの中で、同じレイヤの中の任意の2つのコード化ピクチャに対するPicOrderCntVal値は同じであってはならない。
関数PicOrderCnt(picX)は、次のように規定される。
関数DiffPicOrderCnt(picA,picB)は、次のように規定される。
ビットストリームは、両端値を含む−215〜215−1としての範囲の中にない、復号プロセスにおいて使用されるDiffPicOrderCnt(picA,picB)の値をもたらすデータを含んではならない。
注− Xを現在ピクチャとし、Y及びZを同じシーケンスの中の2つの他のピクチャとすると、DiffPicOrderCnt(X,Y)とDiffPicOrderCnt(X,Z)の両方が正であるか、又は両方が負であるとき、Y及びZは、Xからの同じ出力順序方向にあるものとみなされる。
[0170]代替的に、CRAは、3に等しいpoc_reset_idcを有することが許容される場合があり、poc_msb_valの値が、現在ピクチャのピクチャ順序カウントの最上位ビットの値と、[[同じレイヤの中の]]前のPOCリセッティングピクチャ又は[[同じレイヤの中の]]前のIDRピクチャの、どちらか復号順序において現在ピクチャに近い方との差分に等しくなければならないように、poc_msb_valのセマンティクスが修正される。
スライスセグメントヘッダ拡張シンタックス要素のセマンティクス
[0171]現在、シンタックス要素slice_segment_header_extension_length及びslice_segment_header_extension_data_bitのセマンティクスは規定されていない。以下のセマンティクスが、HEVC規格に追加されてよい。
slice_segment_header_extension_lengthは、このシンタックス要素に後続するスライスヘッダ拡張データの長さをバイト単位で規定する。slice_segment_header_extension_lengthの値は、両端値を含む0〜4096としての範囲の中になければならない。存在しないとき、slice_segment_header_extension_lengthの値は0に等しいものと推定される。
slice_segment_header_extension_data_bitは、任意の値を有してよい。デコーダは、slice_segment_header_extension_data_bitの値を無視しなければならない。その値は、本仕様の本バージョンで規定されるプロファイルへのデコーダ適合に影響を及ぼさない。
poc_reset_info_present_flagのセマンティクス
[0172]シンタックス要素poc_reset_info_present_flagはPPSの中で信号伝達され、フラグpps_extension_type_flag[0]の値を条件とする。poc_reset_info_present_flagのシンタックス及びセマンティクスが以下に転載される。表2は、pic_parameter_set_rbsp()の例示的なシンタックスを示す。
pps_extension_type_flag[i]は、本仕様の本バージョンに適合するビットストリームの中で、両端値を含む1〜6としての範囲の中のiに対して0に等しくなければならない。1に等しいpps_extension_type_flag[0]は、PPS RBSPシンタックス構造の中にpoc_reset_info_present_flagが存在することを規定する。0に等しいpps_extension_type_flag[0]は、PPS RBSPシンタックス構造の中にpoc_reset_info_present_flagが存在しないことを規定する。両端値を含む1〜7としての範囲の中のiに対して、pps_extension_type_flag[i]について1としての値は、将来の使用のためにITU−T|ISO/IECによって予約される。0に等しいpps_extension_type_flag[7]は、PPS RBSPシンタックス構造の中にpps_extension_data_flagシンタックス要素が存在しないことを規定する。デコーダは、PPS NAL単位中でpps_extension_type_flag[7]にとっての値1に後続する全てのpps_extension_data_flagシンタックス要素を無視しなければならない。
0に等しいpoc_reset_info_present_flagは、PPSを参照するスライスのスライスセグメントヘッダの中に、シンタックス要素poc_reset_idcが存在しないことを規定する。1に等しいpoc_reset_info_present_flagは、PPSを参照するスライスのスライスセグメントヘッダの中に、シンタックス要素poc_reset_idcが存在することを規定する。
[0173]幾つかの実装形態では、poc_reset_info_present_flagの値が0に等しいときでさえ、現在のシンタックスは、pps_extension_type_flag[0]が1としての値に設定されpoc_reset_info_present_flagが信号伝達されることを義務付け得る。しかしながら、poc_reset_info_present_flagを信号伝達せず、代わりにシンタックス要素が存在しないときにその値が0に等しいものと推定することが、より効率的な場合がある。そのような変更は以下に示すようにセマンティクスを修正することによって実施されてよく、ここで、追加された言葉はイタリック体で示される。
0に等しいpoc_reset_info_present_flagは、PPSを参照するスライスのスライスセグメントヘッダの中にシンタックス要素poc_reset_idcが存在しないことを規定する。1に等しいpoc_reset_info_present_flagは、PPSを参照するスライスのスライスセグメントヘッダの中にシンタックス要素poc_reset_idcが存在することを規定する。存在しないとき、poc_reset_info_present_flagの値は0に等しいものと推定される。
[0174]本開示に記載される技法は独立に適用されてよく、それらの一部又は全部が組み合わせて適用されてもよい。本明細書で説明する表示、フラグ、及び/又はシンタックス要素は、限定はしないが、VPS、SPS、PPS、スライスヘッダ、SEIメッセージなどを含むビットストリームの様々な部分において提供されてよく、外部の手段によって規定されてさえよい。
他の考慮事項
[0175]本明細書で開示された情報及び信号は、多種多様な技術及び技法のいずれかを使用して表され得る。例えば、上記の説明全体にわたって参照され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁場若しくは磁性粒子、光場若しくは光学粒子、又はそれらの任意の組合せによって表され得る。
[0176]本明細書で開示された実施形態に関して記載された様々な例示的な論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、又は両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、及びステップが、概してそれらの機能に関して上記で説明されている。そのような機能性が、ハードウェア又はソフトウェアのどちらとして実施されるのかは、特定の応用例と、システム全体に課せられる設計制約とに依存する。当業者は、特定の適用例ごとに様々な方法で記載された機能を実装し得るが、そのような実装の決定が、本発明の範囲からの逸脱を引き起こすと解釈されるべきではない。
[0177]本明細書に記載された技術は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せに実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信機器ハンドセット、又はワイヤレス通信機器ハンドセット及び他の機器における適用例を含む複数の用途を有する集積回路機器などの、様々な機器のいずれかにおいて実装され得る。モジュール又は構成要素として記載された任意の特徴は、集積論理機器内で一緒に、又は個別であるが相互運用可能な論理機器として別々に実装され得る。ソフトウェアに実装された場合、本技法は、実行されたとき、上記で説明された方法のうちの1つ又は複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含むことがあるコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM(登録商標))、フラッシュメモリ、磁気又は光学データ記憶媒体などの、メモリ又はデータ記憶媒体を備え得る。本技法は、追加又は代替として、伝搬信号又は電波などの、命令又はデータ構造の形態でプログラムコードを搬送又は伝達し、コンピュータによってアクセスされ、読み取られ、及び/又は実行され得るコンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
[0178]プログラムコードは、1つ又は複数のDSPなどの1つ又は複数のプロセッサ、汎用マイクロプロセッサ、ASIC、FPGA、又は他の等価の集積回路若しくはディスクリート論理回路を含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示に記載された技法のいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械であり得る。プロセッサはまた、コンピューティング機器の組合せ、例えば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つ又は複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。従って、本明細書で使用する「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、又は本明細書に記載された技法の実装に適した任意の他の構造若しくは装置のいずれかを指し得る。更に、幾つかの態様では、本明細書に記載された機能は、符号化及び復号のために構成された専用のソフトウェアモジュール又はハードウェアモジュール内に提供され得るか、若しくは複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれ得る。また、本技法は、1つ又は複数の回路又は論理要素で十分に実装され得る。
[0179]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)又はICのセット(例えば、チップセット)を含む、多種多様な機器又は装置で実装され得る。様々なコンポーネント、モジュール、又はユニットは、開示されている技術を実行するように構成された機器の機能的態様を強調するように本開示において説明されているが、異なるハードウェアユニットによる実現を必ずしも必要としない。むしろ、上記で説明したように、様々なユニットが、適切なソフトウェア及び/又はファームウェアとともに、上記で説明した1つ又は複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、又は相互動作可能なハードウェアユニットの集合によって与えられ得る。
[0180]本発明の様々な実施形態について説明した。これら及び他の実施形態は、以下の特許請求の範囲内に入る。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ビットストリームの中のビデオ情報をコード化するための装置であって、
現在ピクチャを有するビデオレイヤに関連したビデオ情報を記憶するように構成されたメモリと、
前記メモリと通信しており、
前記現在ピクチャに関連したスライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定し、
前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという決定に応答して、前記現在ピクチャに関連したピクチャ順序カウント(POC)値の1つ以上の最上位ビット(MSB)が前記ビットストリームの中に存在しないと決定するように構成された
プロセッサとを備える装置。
[C2]
前記プロセッサが、ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するように更に構成される、C1に記載の装置。
[C3]
前記プロセッサが、前記ビットストリームが単一レイヤビットストリームであるかどうかに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するように更に構成される、C1に記載の装置。
[C4]
前記プロセッサが、前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかに少なくとも部分的に基づいて、前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定するように更に構成される、C1に記載の装置。
[C5]
前記プロセッサが、
前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかを決定し、
前記現在ピクチャがCRAピクチャ又はBLAピクチャであるという決定に応答して、前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされるという表示を処理し、
前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされるという前記表示にかかわらず、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという前記決定に基づいて、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定する
ように更に構成される、C1に記載の装置。
[C6]
前記プロセッサが、ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するように更に構成される、C5に記載の装置。
[C7]
前記プロセッサが、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないことを示すためのパラメータを0に設定するように更に構成される、C1に記載の装置。
[C8]
前記プロセッサが、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するという決定に応答して、前記POC値の前記1つ以上のMSBに少なくとも部分的に基づいて、前記ビデオレイヤに関連した前記ビデオ情報をコード化するように更に構成される、C1に記載の装置。
[C9]
前記POC値の前記1つ以上のMSBが、前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張の中で提供される、C1に記載の装置。
[C10]
前記プロセッサが、
前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するという決定に応答して、前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが、前記ビットストリームの中に存在することを必要とされるかどうかを決定し、
前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされるという決定に応答して、前記ビットストリームの中で提供される前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBを処理する
ように更に構成される、C1に記載の装置。
[C11]
前記プロセッサが、関連する前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされないという決定に応答して、前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定するように更に構成される、C10に記載の装置。
[C12]
ビットストリームの中のビデオ情報をコード化する方法であって、
ビデオレイヤの中の現在ピクチャに関連したスライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定することと、
前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという決定に応答して、前記現在ピクチャに関連したピクチャ順序カウント(POC)値の1つ以上の最上位ビット(MSB)が前記ビットストリームの中に存在しないと決定すること、又は、
前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するという決定に応答して、前記現在ピクチャに関連したPOC値の1つ以上のMSBが、前記ビットストリームの中に存在することを必要とされるかどうかを決定することと
を備える方法。
[C13]
ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定することを更に備えるC12に記載の方法。
[C14]
前記ビットストリームが単一レイヤビットストリームであるかどうかに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定することを更に備えるC12に記載の方法。
[C15]
前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかに少なくとも部分的に基づいて、前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定することを更に備えるC12に記載の方法。
[C16]
前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかを決定することと、
前記現在ピクチャがCRAピクチャ又はBLAピクチャであるという決定に応答して、前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされると決定することと、
前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされるという前記決定にかかわらず、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという前記決定に基づいて、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定することと
を更に備えるC12に記載の方法。
[C17]
ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定することを更に備えるC16に記載の方法。
[C18]
前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないことを示すためのパラメータを0に設定することを更に備えるC12に記載の方法。
[C19]
前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するという決定に応答して、前記POC値の前記1つ以上のMSBに少なくとも部分的に基づいて、前記ビデオレイヤに関連した前記ビデオ情報をコード化することを更に備えるC12に記載の方法。
[C20]
前記POC値の前記1つ以上のMSBが、前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張の中で提供される、C12に記載の方法。
[C21]
前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされるかどうかを決定することに応答して、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされるという決定に応答して、前記ビットストリームの中で提供される前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBを処理することを更に備えるC12に記載の方法。
[C22]
前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされるかどうかを決定することに応答して、関連する前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在することを必要とされないという決定に応答して、前記現在ピクチャに関連した前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定することを更に備えるC21に記載の方法。
[C23]
実行されたとき、装置に、
現在ピクチャを有するビデオレイヤに関連したビデオ情報を記憶させ、
前記現在ピクチャに関連したスライスセグメントヘッダ拡張がビットストリームの中に存在するかどうかを決定させ、
前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという決定に応答して、前記現在ピクチャに関連したピクチャ順序カウント(POC)値の1つ以上の最上位ビット(MSB)が前記ビットストリームの中に存在しないと決定させる
コードを備える非一時的コンピュータ可読媒体。
[C24]
前記コードが、更に前記装置に、ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定させる、C23に記載のコンピュータ可読媒体。
[C25]
前記コードが、更に前記装置に、前記ビットストリームが単一レイヤビットストリームであるかどうかに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定させる、C23に記載のコンピュータ可読媒体。
[C26]
前記コードが、更に前記装置に、
前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかを決定させ、
前記現在ピクチャがCRAピクチャ又はBLAピクチャであるという決定に応答して、前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされると決定させ、
前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされるという前記決定にかかわらず、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという前記決定に基づいて、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定させる、
C23に記載のコンピュータ可読媒体。
[C27]
ビットストリームの中のビデオ情報をコード化するように構成されたビデオコード化機器であって、
現在ピクチャを有するビデオレイヤに関連したビデオ情報を記憶するための手段と、
前記現在ピクチャに関連したスライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するための手段と、
前記現在ピクチャに関連した前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという決定に応答して、前記現在ピクチャに関連したピクチャ順序カウント(POC)値の1つ以上の最上位ビット(MSB)が前記ビットストリームの中に存在しないと決定するための手段と
を備えるビデオコード化機器。
[C28]
ある長さの前記スライスセグメントヘッダ拡張を示し前記ビットストリームの中で提供されるフラグに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するための手段を更に備えるC27に記載のビデオコード化機器。
[C29]
前記ビットストリームが単一レイヤビットストリームであるかどうかに基づいて、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在するかどうかを決定するための手段を更に備えるC27に記載のビデオコード化機器。
[C30]
前記現在ピクチャがクリーンランダムアクセス(CRA)ピクチャ又はブロークンリンクアクセス(BLA)ピクチャであるかどうかを決定するための手段と、
前記現在ピクチャがCRAピクチャ又はBLAピクチャであるという決定に応答して、前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされると決定するための手段と、
前記POC値の前記1つ以上のMSBが前記ビットストリームの中で提供されることを必要とされるという前記決定にかかわらず、前記スライスセグメントヘッダ拡張が前記ビットストリームの中に存在しないという前記決定に基づいて、前記POC値の前記1つ以上のMSBが前記ビットストリームの中に存在しないと決定するための手段と
を更に備えるC27に記載のビデオコード化機器。