[0038]概して、本開示は、3D−HEVC(高効率ビデオコーディング)コーデックを使用する、奥行きブロックに沿った1つまたは複数のビューのコーディングを含む、高度コーデックに基づく3Dビデオコーディングに関する技法について説明する。具体的には、本開示は、非対称動き分割技法を使用して分割された予測ユニット(PU)をより小さなサブブロックをさらに分割するための技法について説明する。本開示の技法は、非対称動き分割を使用して分割されたPUのサブブロックに関する動きベクトルおよび視差動きベクトルを導出ならびに/または継承するための技法を含む。
[0039]図1は、本開示の技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示すように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを提供するソースデバイス12を含む。具体的には、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを提供し得る。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲のデバイスのいずれかを備え得る。場合によっては、ソースデバイス12および宛先デバイス14はワイヤレス通信に対応する場合がある。
[0040]宛先デバイス14は、コンピュータ可読媒体16を介して、復号されるべき符号化ビデオデータを受信することができる。コンピュータ可読媒体16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することができる、任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が宛先デバイス14に直接的にリアルタイムで、符号化ビデオデータを送信することを可能にする通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信標準規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、ラジオ周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線など、任意のワイヤレス通信媒体あるいは有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースのネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を容易にするのに有用とすることのできる、ルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0041]いくつかの例では、符号化データは、出力インターフェース22からストレージデバイスに出力され得る。同様に、符号化データは、ストレージデバイスから入力インターフェースによってアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性もしくは不揮発性のメモリ、または符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれをも含み得る。さらなる例では、ストレージデバイスは、ソースデバイス12によって生成された符号化ビデオを記憶することができるファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスすることができる。ファイルサーバは、符号化ビデオデータを記憶でき、符号化ビデオデータを宛先デバイス14に送信できる、任意のタイプのサーバとすることができる。例示的なファイルサーバは、ウェブサーバ(たとえば、ウェブサイト用の)、FTPサーバ、ネットワークアタッチドストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む、任意の標準データ接続を介して、符号化ビデオデータにアクセスすることができる。これは、ファイルサーバ上に記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi−Fi(登録商標)接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、またはその両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはその組合せとすることができる。
[0042]本開示の技法は、ワイヤレス応用またはワイヤレス設定に必ずしも限定されない。本技法は、無線テレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、HTTP上の動的適応ストリーミング(DASH:dynamic adaptive streaming over HTTP)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の応用など、様々なマルチメディア応用のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオ放送、および/またはビデオ電話などの応用をサポートするために一方向もしくは両方向のビデオ送信をサポートするように構成され得る。
[0043]図1の例では、ソースデバイス12は、ビデオソース18と、奥行き推定ユニット19と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、奥行き画像ベースのレンダリング(DIBR:depth image based rendering)ユニット31と、ディスプレイデバイス32とを含む。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部のビデオソース18からビデオデータを受信することができる。同様に、宛先デバイス14は、統合されたディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースしてもよい。
[0044]図1の例示されたシステム10は、一例にすぎない。本開示の技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法はビデオプリプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が、宛先デバイス14に送信するためのコーディングされたビデオデータを生成するコーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化コンポーネントとビデオ復号コンポーネントとを含むように実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、もしくはビデオ電話のためのビデオデバイス12とビデオデバイス14の間の一方向または双方向のビデオ送信をサポートし得る。
[0045]ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含んでいるビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成することができる。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。しかしながら、上で言及されたように、本開示で説明する技法は、一般に、ビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の用途に適用され得る。各々の場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。次いで、符号化ビデオ情報は、出力インターフェース22によってコンピュータ可読媒体16に出力され得る。
[0046]ビデオソース18は、ビデオエンコーダ20にビデオデータの1つまたは複数のビューを提供し得る。たとえば、ビデオソース18は、各々が、撮影されている特定のシーンに対して一意の水平位置を有する、カメラのアレイに対応し得る。代替的に、ビデオソース18は、たとえばコンピュータグラフィックスを使用して、異なる水平カメラの視点からビデオデータを生成することができる。奥行き推定ユニット19は、テクスチャ画像内のピクセルに対応する奥行きピクセルに関する値を決定するように構成され得る。たとえば、奥行き推定ユニット19は、音響航法/測距(SONAR:Sound Navigation and Ranging)ユニット、光検出/測距(LIDAR:Light Detection and Ranging)ユニット、またはシーンのビデオデータを記録しながら実質的に同時に奥行き値を直接決定することが可能な他のユニットを表し得る。
[0047]追加または代替として、奥行き推定ユニット19は、異なる水平カメラ視点から実質的に同時にキャプチャされた2つ以上の画像を比較することによって、間接的に奥行き値を計算するように構成され得る。画像内の実質的に同様のピクセル値の間の水平視差を計算することによって、奥行き推定ユニット19は、シーン内の様々なオブジェクトの奥行きを概算することができる。奥行き推定ユニット19は、いくつかの例では、ビデオソース18と機能的に統合され得る。たとえば、ビデオソース18がコンピュータグラフィックス画像を生成するとき、奥行き推定ユニット19は、たとえば、ピクセルのz座標と、テクスチャ画像をレンダリングするために使用されたオブジェクトとを使用して、グラフィカルオブジェクトに関する実際の奥行きマップを提供することができる。
[0048]コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくはワイヤードネットワーク送信などの一時媒体、または、ハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu−ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)は、たとえば、ネットワーク送信を介して、ソースデバイス12から符号化ビデオデータを受信し、宛先デバイス14に符号化ビデオデータを提供することができる。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成することができる。したがって、様々な例では、コンピュータ可読媒体16は、様々な形態の1つまたは複数のコンピュータ可読媒体を含むと理解され得る。
[0049]宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、ブロックおよび他のコード化ユニット、たとえば、GOPの特性ならびに/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、ユーザに復号ビデオデータを表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。いくつかの例では、ディスプレイデバイス32は、たとえば、閲覧者のための3D視覚効果を生成するために、同時にまたは実質的に同時に2つ以上のビューを表示することが可能なデバイスを備え得る。
[0050]宛先デバイス14のDIBRユニット31は、ビデオデコーダ30から受信された復号ビューのテクスチャ情報および奥行き情報を使用して、合成されたビューをレンダリングすることができる。たとえば、DIBRユニット31は、対応する奥行きマップ中のピクセルの値に応じて、テクスチャ画像のピクセルデータに関する水平視差を決定することができる。DIBRユニット31は、次いで、決定された水平視差によって、テクスチャ画像中のピクセルを左または右にオフセットすることによって、合成された画像を生成することができる。このようにして、ディスプレイデバイス32は、1つもしくは複数のビューを表示することができ、1つもしくは複数のビューは、任意の組合せにおける、復号されたビューおよび/または合成されたビューに対応し得る。本開示の技法によれば、ビデオデコーダ30は、奥行き範囲およびカメラパラメータに関する元の精度値と更新された精度値とを、DIBRユニット31に提供することができ、DIBRユニット31は、ビューを適切に合成するために、奥行き範囲とカメラパラメータとを使用することができる。
[0051]図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、MUX−DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0052]ビデオエンコーダ20およびビデオデコーダ30は各々、1つもしくは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組合せなど、様々な好適なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアに対する命令を好適な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために、1つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行することができる。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つもしくは複数のエンコーダまたはデコーダに含まれ得、そのいずれかは、組み合わされたエンコーダ/デコーダ(コーデック)の一部として、それぞれのデバイスに統合され得る。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話機などのワイヤレス通信デバイスを備え得る。
[0053]ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディング(HEVC)規格などの、ビデオコーディング規格に従って動作し得、HEVCテストモデル(HM)に準拠し得る。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG−4、Part 10、アドバンストビデオコーディング(AVC)と呼ばれるITU−T H.264規格など、他のプロプライエタリ規格もしくは業界規格、またはITU−T H.264/AVCのMVC拡張など、そのような規格の拡張に従って動作し得る。MVCの最新のジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ITU−T勧告H.264、2010年3月に記載されている。具体的には、ビデオエンコーダ20およびビデオデコーダ30は、HEVC規格(たとえば、3D−HEVC)の3D拡張を含む、3Dおよび/またはマルチビューコーディング規格に従って動作し得る。
[0054]「HEVC Working Draft 10」または「WD10」と呼ばれるHEVC規格の一ドラフトは、文書JCTVC−L1003v34、Brossら、「(FDIS & Last Callに対して)High efficiency video coding(HEVC)text specification draft 10」、ITU−T SG16 WP3とISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT−VC:Joint Collaborative Team on Video Coding)、第12回会合:スイス、ジュネーブ、2013年1月14日〜23日に記載されており、この文書は、2014年8月22日現在、http://phenix.int−evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC−L1003−v34.zipからダウンロード可能である。
[0055]HEVC規格の別のドラフトは、本明細書で、Brossら、「Editors’ proposed corrections to HEVC version 1」、ITU−T SG16 WP3とISO/IEC JTC1/SC29/WG11とのビデオコーディング共同研究部会(JCT−VC)、第13回会合、韓国、仁川、2013年4月に記載された「WD10改訂版」と呼ばれ、この文書は2014年8月22日現在、http://phenix.int−evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC−M0432−v3.zipから入手可能である。また、HEVCに対するマルチビュー拡張、すなわちMV−HEVCがJCT−3Vによって開発されている。
[0056]現在、VCEGおよびMPEGの3Dビデオコーディング共同研究部会(JCT−3C:Joint Collaboration Team on 3D Video Coding)は、HEVCに基づく3DV規格を開発中であり、そのために、規格化作業の一部は、HEVCに基づくマルチビュービデオコーデック(MV−HEVC)と、HEVCに基づく3Dビデオコーディング(3D−HEVC)のための別の部分との規格化を含む。MV−HEVCでは、HEVCにおけるコーディングユニット/予測ユニットレベルにおけるモジュールが再設計される必要がなく、MV−HEVCに完全に再使用され得ないように、MV−HEVCにおいてハイレベルシンタックス(HLS)の変更しか存在しないことが保証されるべきである。3D−HEVCでは、コーディングユニット/予測ユニットレベルのコーディングツールを含む新たなコーディングツールが、テクスチャビューと奥行きビューの両方に関して含められ、サポートされ得る。
[0057]3D−HEVC用の1つのバージョンのソフトウェア3D−HTMが以下のリンクからダウンロードされ得る。[3D−HTMバージョン8.0]:https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM−8.0/。3D−HEVCの1つのワーキングドラフト(文書番号:E1001)は以下から利用可能である。http://phenix.it−sudparis.eu/jct2/doc_end_user/current_document.php?id=1361。最新のソフトウェア記述(文書番号E1005)は以下から利用可能である。http://phenix.it−sudparis.eu/jct2/doc_end_user/current_document.php?id=1360。
[0058]3D−HEVC用の最近のソフトウェア3D−HTMは、以下のリンクからダウンロード可能である。[3D−HTMバージョン12.0]:https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM−12.0/。3D−HEVC(文書番号I1001)の対応するワーキングドラフトは以下から利用可能である。http://phenix.int−evry.fr/jct3v/doc_end_user/current_document.php?id=2299。最新のソフトウェア記述(文書番号I1005)は以下から利用可能である。http://phenix.int−evry.fr/jct3v/doc_end_user/current_document.php?id=2301。
[0059]最初に、HEVCの例示的なコーディング技法について説明する。HEVC規格化の取組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づいていた。HMは、たとえば、ITU−T H.264/AVCに従う既存のデバイスに対して、ビデオコーディングデバイスのいくつかの追加の能力を仮定した。たとえば、H.264は9個のイントラ予測符号化モードを提供するが、HMは33個もの角度イントラ予測符号化モードプラスDCモードと平面モードとを提供することができる。
[0060]HEVCおよび他のビデオコーディング仕様では、ビデオシーケンスは、一般に、一連のピクチャを含む。ピクチャは「フレーム」と呼ばれることもある。ピクチャは、SL、SCbおよびSCrと示される3つのサンプルアレイを含み得る。SLは、ルーマサンプルの2次元アレイ(すなわち、ブロック)である。SCbは、Cbクロミナンスサンプルの2次元アレイである。SCrは、Crクロミナンスサンプルの2次元アレイである。クロミナンスサンプルは、本明細書では「クロマ」サンプルと呼ばれる場合もある。他の例では、ピクチャは、モノクロームであり得るし、ルーマサンプルのアレイのみを含む場合がある。
[0061]ピクチャの符号化表現を生成するために、ビデオエンコーダ20は、コーディングツリーユニット(CTU)のセットを生成することができる。CTUの各々は、ルーマサンプルのコーディングツリーブロックと、クロマサンプルの2つの対応するコーディングツリーブロックと、それらのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。3つの別個のカラープレーンを有する1つまたは複数のモノクロームピクチャでは、CTUは、単一のコーディングツリーブロックと、そのコーディングツリーブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。コーディングツリーブロックは、サンプルのN×Nブロックであり得る。CTUは、「ツリーブロック」または「最大コーディングユニット」(LCU)と呼ばれることもある。HEVCのCTUは、H.264/AVCのような、他の規格のマクロブロックに広い意味で類似し得る。しかしながら、CTUは、必ずしも特定のサイズには限定されず、1つまたは複数のコーディングユニット(CU)を含み得る。スライスは、ラスタ走査順序で連続的に順序付けられた整数個のCTUを含み得る。
[0062]コーディングされたCTUを生成するために、ビデオエンコーダ20は、コーディングツリーブロックをコーディングブロックに分割するように、CTUのコーディングツリーブロックに対して4分木分割を再帰的に実行することができ、したがって「コーディングツリーユニット」という名称である。コーディングブロックは、サンプルのN×Nブロックである。コーディングユニット(CU)は、ルーマサンプルアレイと、Cbサンプルアレイと、Crサンプルアレイとを有するピクチャの、ルーマサンプルのコーディングブロックと、クロマサンプルの2つの対応するコーディングブロックと、それらのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。3つの別個のカラープレーンを有する1つまたは複数のモノクロームピクチャでは、CUは、単一のコーディングブロックと、そのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備え得る。
[0063]ビデオエンコーダ20は、CUのコーディングブロックを1つまたは複数の予測ブロックに分割することができる。予測ブロックは、同じ予測が適用されるサンプルの方形(すなわち、正方形または非正方形)ブロックである。CUの予測ユニット(PU)は、ルーマサンプルの予測ブロックと、クロマサンプルの2つの対応する予測ブロックと、それらの予測ブロックを予測するために使用されるシンタックス構造とを備え得る。3つの別個のカラープレーンを有する1つまたは複数のモノクロームピクチャでは、PUは、単一の予測ブロックと、その予測ブロックを予測するために使用されるシンタックス構造とを備え得る。ビデオエンコーダ20は、CUの各PUのルーマ予測ブロック、Cb予測ブロック、およびCr予測ブロックに関する予測ルーマブロックと、予測Cbブロックと、予測Crブロックとを生成することができる。
[0064]ビデオエンコーダ20は、PUに関する予測ブロックを生成するためにイントラ予測またはインター予測を使用することができる。ビデオエンコーダ20がPUの予測ブロックを生成するためにイントラ予測を使用する場合、ビデオエンコーダ20は、PUに関連付けられたピクチャの復号されたサンプルに基づいて、PUの予測ブロックを生成することができる。各PUのルーマ成分に関するHEVCのいくつかのバージョンでは、(2から34までインデックス付けされた)33個の角度予測モードと、(1とインデックス付けされた)DCモードと、(0とインデックス付けされた)平面モードとを有するイントラ予測方法が利用される。
[0065]ビデオエンコーダ20がPUの予測ブロックを生成するためにインター予測を使用する場合、ビデオエンコーダ20は、PUに関連付けられたピクチャ以外の1つまたは複数のピクチャの復号されたサンプルに基づいて、PUの予測ブロックを生成することができる。インター予測は、単方向インター予測(すなわち、単予測もしくは単予測的予測(predictive prediction))または双方向インター予測(すなわち、双予測もしくは双予測的予測)であり得る。単予測または双予測を実行するために、ビデオエンコーダ20は、現在スライスに対して、第1の参照ピクチャリスト(RefPicList0)と第2の参照ピクチャリスト(RefPicList1)とを生成することができる。参照ピクチャリストの各々は、1つまたは複数の参照ピクチャを含み得る。単予測を使用するとき、ビデオエンコーダ20は、参照ピクチャ内の参照ロケーションを決定するために、RefPicList0とRefPicList1のいずれかまたは両方の中の参照ピクチャを探索することができる。さらに、単予測を使用するとき、ビデオエンコーダ20は、参照ロケーションに対応するサンプルに少なくとも部分的に基づいて、PUに関する予測サンプルブロックを生成することができる。さらに、単予測を使用するとき、ビデオエンコーダ20は、PUの予測ブロックと参照ロケーションとの間の空間変位を示す単一の動きベクトルを生成することができる。PUの予測ブロックと参照ロケーションとの間の空間変位を示すために、動きベクトルは、PUの予測ブロックと参照ロケーションとの間の水平変位を指定する水平成分を含み得、PUの予測ブロックと参照ロケーションとの間の垂直変位を指定する垂直成分を含み得る。
[0066]PUを符号化するために双予測を使用するとき、ビデオエンコーダ20は、RefPicList0中の参照ピクチャ中の第1の参照ロケーションと、RefPicList1中の参照ピクチャ中の第2の参照ロケーションとを決定することができる。ビデオエンコーダ20は、次いで、第1の参照ロケーションおよび第2の参照ロケーションに対応するサンプルに少なくとも部分的に基づいて、PUのための予測ブロックを生成することができる。さらに、PUを符号化するために双予測を使用するとき、ビデオエンコーダ20は、PUのサンプルブロックと第1の参照ロケーションとの間の空間変位を示す第1の動きベクトルと、PUの予測ブロックと第2の参照ロケーションとの間の空間変位を示す第2の動きベクトルとを生成することができる。
[0067]一般に、Bピクチャの第1の参照ピクチャリストまたは第2の参照ピクチャリスト(たとえば、RefPicList0またはRefPicList1)に関する参照ピクチャリスト構築は、2つのステップ、すなわち、参照ピクチャリスト初期化と、参照ピクチャリスト並べ替え(修正)とを含む。参照ピクチャリスト初期化は、参照ピクチャメモリ(復号ピクチャバッファとしても知られる)中の参照ピクチャを、POC(ピクチャの表示順で整列されるピクチャオーダーカウント)値の順序に基づいてリストに入れる明示的機構である。参照ピクチャリスト並べ替え機構は、参照ピクチャリスト初期化中にリスト中に置かれたピクチャの位置を任意の新しい位置に修正すること、または参照ピクチャメモリ中の任意の参照ピクチャが初期化リストに属していない場合でもそのピクチャを任意の位置に置くことができる。参照ピクチャリスト並べ替え(修正)後のいくつかのピクチャは、リスト中のはるかに離れた位置に入れられる場合がある。ただし、ピクチャの位置が、リストのアクティブ参照ピクチャの数を超える場合、ピクチャは、最終的な参照ピクチャリストのエントリーとは見なされない。アクティブ参照ピクチャの数は、リストごとにスライスヘッダにおいてシグナリングされ得る。
[0068]参照ピクチャリスト(すなわち、利用可能な場合、RefPicList0およびRefPicList1)が構築された後、参照ピクチャリストに対する参照インデックスは、参照ピクチャリスト中に含まれる任意の参照ピクチャを識別するために使用され得る。
[0069]ビデオエンコーダ20がCUの1つまたは複数のPUに関する、予測ルーマブロックと、予測Cbブロックと、予測Crブロックとを生成した後、ビデオエンコーダ20は、CUに関するルーマ残差ブロックを生成し得る。CUのルーマ残差ブロック中の各サンプルは、CUの予測ルーマブロックの1つの中のルーマサンプルとCUの元のルーマコーディングブロック中の対応するサンプルとの間の差分を示す。加えて、ビデオエンコーダ20は、CUに関するCb残差ブロックを生成することができる。CUのCb残差ブロック中の各サンプルは、CUの予測Cbブロックのうちの1つの中のCbサンプルと、CUの元のCbコーディングブロック中の対応するサンプルとの間の差分を示し得る。ビデオエンコーダ20は、CUに関するCr残差ブロックを生成することもできる。CUのCr残差ブロック中の各サンプルは、CUの予測Crブロックのうちの1つの中のCrサンプルと、CUの元のCrコーディングブロック中の対応するサンプルとの間の差分を示し得る。
[0070]さらに、ビデオエンコーダ20は、CUのルーマ残差ブロック、Cb残差ブロック、およびCr残差ブロックを、1つまたは複数のルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロックに分解するために、4分木分割を使用することができる。変換ブロックは、同じ変換が適用されるサンプルの矩形(たとえば、正方形または非正方形)ブロックである。CUの変換ユニット(TU)は、ルーマサンプルの変換ブロックと、クロマサンプルの2つの対応する変換ブロックと、それらの変換ブロックサンプルを変換するために使用されるシンタックス構造とを備え得る。したがって、CUの各TUは、ルーマ変換ブロック、Cb変換ブロック、およびCr変換ブロックに関連付けられ得る。TUに関連付けられたルーマ変換ブロックは、CUのルーマ残差ブロックのサブブロックであってよい。Cb変換ブロックは、CUのCb残差ブロックのサブブロックであってよい。Cr変換ブロックは、CUのCr残差ブロックのサブブロックであってよい。3つの別個のカラープレーンを有する1つまたは複数のモノクロームピクチャでは、TUは、単一の変換ブロックと、その変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備え得る。
[0071]ビデオエンコーダ20は、TUのルーマ係数ブロックを生成するために、TUのルーマ変換ブロックに1回または複数回の変換を適用することができる。係数ブロックは、変換係数の2次元アレイであり得る。変換係数は、スカラー量であってよい。ビデオエンコーダ20は、TUに関するCb係数ブロックを生成するために、TUのCb変換ブロックに1回または複数回の変換を適用することができる。ビデオエンコーダ20は、TUに関するCr係数ブロックを生成するために、TUのCr変換ブロックに1回または複数回の変換を適用することができる。
[0072]係数ブロック(たとえば、ルーマ係数ブロック、Cb係数ブロックまたはCr係数ブロック)を生成した後、ビデオエンコーダ20は、係数ブロックを量子化することができる。量子化は、一般に、変換係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を実現するプロセスを指す。ビデオエンコーダ20が係数ブロックを量子化した後、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素をエントロピー符号化することができる。たとえば、ビデオエンコーダ20は、量子化変換係数を示すシンタックス要素に対して、コンテキスト適応型バイナリ算術コーディング(CABAC:Context-Adaptive Binary Arithmetic Coding)を実施することができる。
[0073]ビデオエンコーダ20は、コード化ピクチャおよび関連付けられたデータの表現を形成するビットのシーケンスを含むビットストリームを出力し得る。ビットストリームは、一連のネットワークアブストラクションレイヤ(NAL:network abstraction layer)ユニットを備え得る。NALユニットは、NALユニット中のデータのタイプの指示と、必要に応じてエミュレーション防止ビット(emulation prevention bits)が点在するローバイトシーケンスペイロード(RBSP:raw byte sequence payload)の形態でそのデータを含んでいるバイトとを含んでいるシンタックス構造である。NALユニットの各々は、NALユニットヘッダを含み、RBSPをカプセル化する。NALユニットヘッダは、NALユニットタイプコードを含むシンタックス要素を含み得る。NALユニットのNALユニットヘッダによって指定されるNALユニットタイプコードは、NALユニットのタイプを示す。RBSPは、NALユニット内にカプセル化された整数個のバイトを含んでいるシンタックス構造であり得る。場合によっては、RBSPは0ビットを含む。
[0074]様々なタイプのNALユニットは、様々なタイプのRBSPをカプセル化することができる。たとえば、第1のタイプのNALユニットはピクチャパラメータセット(PPS)に関するRBSPをカプセル化することができ、第2のタイプのNALユニットはコード化スライスに関するRBSPをカプセル化することができ、第3のタイプのNALユニットはSEIに関するRBSPをカプセル化することができ、以下同様である。(パラメータセットおよびSEIメッセージのためのRBSPではなく)ビデオコーディングデータのためのRBSPをカプセル化するNALユニットは、ビデオコーディングレイヤ(VCL)NALユニットと呼ばれ得る。
[0075]ビデオデコーダ30は、ビデオエンコーダ20によって生成されたビットストリームを受信することができる。加えて、ビデオデコーダ30は、ビットストリームを解析して、ビットストリームからシンタックス要素を取得することができる。ビデオデコーダ30は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築することができる。ビデオデータを再構築するためのプロセスは、一般に、ビデオエンコーダ20によって実行されるプロセスの逆であり得る。たとえば、ビデオデコーダ30は、現在CUのPUに関する予測ブロックを決定するために、PUの動きベクトルを使用することができる。加えて、ビデオデコーダ30は、現在CUのTUに関連付けられた係数ブロックを逆量子化することができる。ビデオデコーダ30は、現在CUのTUに関連付けられた変換ブロックを再構築するために、係数ブロックに対して逆変換を実行することができる。ビデオデコーダ30は、現在CUのPUに関する予測ブロックのサンプルを現在CUのTUの変換ブロックの対応するサンプルに加算することによって、現在CUのコーディングブロックを再構築することができる。ピクチャの各CUに関するコーディングブロックを再構築することによって、ビデオデコーダ30はピクチャを再構築することができる。
[0076]いくつかの例では、ビデオエンコーダ20は、マージモードまたは高度動きベクトル予測(AMVP)モードを使用して、PUの動き情報をシグナリングすることができる。言い換えれば、HEVCでは、動きパラメータの予測のために2つのモードがあり、一方はマージモードであり、他方はAMVPである。動き予測は、1つまたは複数の他のビデオユニットの動き情報に基づく、ビデオユニット(たとえば、PU)の動き情報の決定を備え得る。PUの動き情報は、PUの動きベクトルと、PUの参照インデックスとを含み得る。
[0077]ビデオエンコーダ20がマージモードを使用して現在PUの動き情報をシグナリングするとき、ビデオエンコーダ20は、マージ候補リストを生成することができる。言い換えれば、ビデオエンコーダ20は、動きベクトル予測子リスト構築プロセスを実行することができる。マージ候補リストは、現在PUに空間的または時間的に隣接するPUの動き情報を示すマージ候補のセットを含む。すなわち、マージモードでは、動きパラメータ(たとえば、参照インデックス、動きベクトルなど)の候補リストが構築され、候補は、空間的隣接ブロックおよび時間的隣接ブロックからであり得る。いくつかの例では、これらの候補は人工的に生成された候補も含み得る。
[0078]さらに、マージモードでは、ビデオエンコーダ20は、マージ候補リストからマージ候補を選択することができ、現在PUの動き情報として、選択されたマージ候補によって示される動き情報を使用することができる。ビデオエンコーダ20は、選択されたマージ候補のマージ候補リスト中の位置をシグナリングすることができる。たとえば、ビデオエンコーダ20は、インデックスを候補リスト中に送信することによって、選択された動きベクトルパラメータをシグナリングすることができる。ビデオデコーダ30は、ビットストリームから、候補リストの中へのインデックス(すなわち、候補リストインデックス)を取得することができる。さらに、ビデオデコーダ30は、同じマージ候補リストを生成することができ、選択されたマージ候補の位置の指示に基づいて、選択されたマージ候補を決定することができる。ビデオデコーダ30は、次いで、現在PUに関する予測ブロックを生成するために、選択されたマージ候補の動き情報を使用することができる。すなわち、ビデオデコーダ30は、候補リストインデックスに少なくとも部分的に基づいて、候補リスト中の選択された候補を決定することができ、ここにおいて、選択された候補は、現在PUについての動きベクトルを指定する。このように、デコーダ側では、インデックスが復号されると、インデックスが指す対応するブロックのすべての動きパラメータは、現在PUによって継承され得る。
[0079]スキップモードはマージモードと同様である。スキップモードでは、ビデオエンコーダ20およびビデオデコーダ30は、マージモードにおいてビデオエンコーダ20およびビデオデコーダ30がマージ候補リストを使用するのと同じようにマージ候補リストを生成し、使うことができる。ただし、ビデオエンコーダ20がスキップモードを使用して現在PUの動き情報をシグナリングするとき、ビデオエンコーダ20は、現在PUに関するどの残差データもシグナリングしない。したがって、ビデオデコーダ30は、残差データを使用せずに、マージ候補リスト中の選択された候補の動き情報によって示される参照ブロックに基づいて、PUに関する予測ブロックを決定することができる。
[0080]AMVPモードは、ビデオエンコーダ20が候補リストを生成することができ、候補リストから候補を選択することができるという点で、マージモードと同様である。ただし、ビデオエンコーダ20がAMVPモードを使用して現在PUのRefPicListX動き情報をシグナリングするとき、ビデオエンコーダ20は、現在PUに関するRefPicListX MVPフラグをシグナリングするのに加え、現在PUに関するRefPicListX動きベクトル差分(MVD)と、現在PUに関するRefPicListX参照インデックスとをシグナリングすることができる。現在PUに関するRefPicListX MVPフラグは、AMVP候補リスト中の選択されたAMVP候補の位置を示し得る。現在PUに関するRefPicListX MVDは、現在PUのRefPicListX動きベクトルと選択されたAMVP候補の動きベクトルとの間の差分を示し得る。このようにして、ビデオエンコーダ20は、RefPicListX動きベクトル予測子(MVP)フラグと、RefPicListX参照インデックス値と、RefPicListX MVDとをシグナリングすることによって、現在PUのRefPicListX動き情報をシグナリングすることができる。言い換えれば、現在PUに関する動きベクトルを表す、ビットストリーム中のデータは、参照インデックスと、候補リストへのインデックスと、MVDとを表すデータを含み得る。
[0081]さらに、AMVPモードを使って現在PUの動き情報がシグナリングされるとき、ビデオデコーダ30は、ビットストリームから、現在PUに関するMVDと、MVPフラグとを取得することができる。ビデオデコーダ30は、同じAMVP候補リストを生成することができ、MVPフラグに基づいて、選択されたAMVP候補を決定することができる。ビデオデコーダ30は、MVDを選択されたAMVP候補によって示される動きベクトルに加算することによって、現在PUの動きベクトルを復元することができる。すなわち、ビデオデコーダ30は、選択されたAMVP候補によって示される動きベクトルおよびMVDに基づいて、現在PUの動きベクトルを決定することができる。ビデオデコーダ30は次いで、現在PU予測ブロックを生成するために、復元された動きベクトルまたは現在のPUの動きベクトルを使用することができる。
[0082]ビデオデコーダ30が現在PUに関するAMVP候補リストを生成するとき、ビデオデコーダ30は、現在PUに空間的に隣接するロケーションをカバーするPU(すなわち、空間的隣接PU)の動き情報に基づいて、1つまたは複数のAMVP候補を導出することができる。PUの予測ブロックがあるロケーションを含むとき、PUはそのロケーションをカバーし得る。
[0083]現在PUに時間的に隣接するPU(すなわち、現在PUとは異なる時間インスタンス中にあるPU)の動き情報に基づくマージ候補リストまたはAMVP候補リスト中の候補は、TMVPと呼ばれ得る。すなわち、TMVPは、HEVCのコーディング効率を向上させるために使用され得、他のコーディングツールとは異なり、TMVPは、復号ピクチャバッファ中、より具体的には、参照ピクチャリスト中のフレームの動きベクトルにアクセスする必要があり得る。
[0084]TMVPの使用は、CVS(コード化ビデオシーケンス)ごとに、スライスごとに、もしくは別の方式で、有効または無効にされ得る。SPS中のシンタックス要素(たとえば、sps_temporal_mvp_enable_flag)は、TMVPの使用がCVSに対して有効にされるかどうかを示し得る。さらに、TMVPの使用がCVSのために有効にされるとき、TMVPの使用は、CVS内の特定のスライスに対して有効または無効にされ得る。たとえば、スライスヘッダ中のシンタックス要素(たとえば、slice_temporal_mvp_enable_flag)は、TMVPの使用がスライスに対して有効にされるかどうかを示し得る。したがって、インター予測スライスでは、TMVPがCVS全体に対して有効にされる(たとえば、SPS中のsps_temporal_mvp_enable_flagが1に設定される)とき、TMVPが現在スライスに対して有効にされているかどうかを示すために、slice_temporal_mvp_enable_flagがスライスヘッダ中でシグナリングされる。
[0085]TMVPを決定するために、ビデオコーダは、現在PUとコロケートされるPUを含む参照ピクチャを最初に識別することができる。言い換えれば、ビデオコーダはコロケートピクチャを識別することができる。現在ピクチャの現在スライスがBスライス(すなわち、双方向インター予測されたPUを含むことが可能にされるスライス)である場合、ビデオエンコーダ20は、コロケートピクチャがRefPicList0からのものであるか、またはRefPicList1からのものであるかを示すシンタックス要素(たとえば、collocated_from_l0_flag)を、スライスヘッダ中でシグナリングすることができる。言い換えれば、TMVPの使用が現在スライスに対して有効にされ、現在スライスがBスライス(たとえば、双方向インター予測されたPUを含むことが可能にされるスライス)であるとき、ビデオエンコーダ20は、コロケートピクチャがRefPicList0の中にあるか、またはRefPicList1の中にあるかを示すために、シンタックス要素(たとえば、collocated_from_l0_flag)を、スライスヘッダ中でシグナリングすることができる。言い換えれば、TMVPを得るために、最初に、コロケートピクチャが識別されることになる。現在のピクチャがBスライスである場合、コロケートピクチャがRefPicList0からのものか、またはRefPicList1からのものかを示すために、collocated_from_l0_flagがスライスヘッダにおいてシグナリングされる。
[0086]ビデオデコーダ30がコロケートピクチャを含む参照ピクチャリストを識別した後、ビデオデコーダ30は、識別された参照ピクチャリスト中のピクチャ(すなわち、コロケートピクチャ)を識別するために、スライスヘッダ中でシグナリングされ得る別のシンタックス要素(たとえば、collocated_ref_idx)を使用することができる。すなわち、参照ピクチャリストが識別された後、スライスヘッダでシグナリングされるcollocated_ref_idxが、参照ピクチャリスト中のピクチャを識別するために使用される。
[0087]ビデオコーダは、コロケートピクチャを確認することによって、コロケートPUを識別することができる。TMVPは、コロケートPUを含むCUの右下のPUの動き情報、またはこのPUを含むCUの中心PU内の右下のPUの動き情報のいずれかを示し得る。したがって、このPUを含むCUの右下のPUの動き、またはこのPUを含むCUの中心PU内の右下のPUの動きのいずれかが使用される。コロケートPUを含むCUの右下のPUは、PUの予測ブロックの右下のサンプルのすぐ下および右のロケーションをカバーするPUであり得る。言い換えれば、TMVPは、参照ピクチャの中にあり現在PUの右下コーナーとコロケートされるロケーションをカバーするPUの動き情報を示すことができ、または、TMVPは、参照ピクチャの中にあり、現在PUの中心とコロケートされるロケーションをカバーするPUの動き情報を示すことができる。
[0088]マージモードまたはAMVPモードのための動き候補を生成するために、上記のプロセスによって識別された動きベクトル(すなわち、TMVPの動きベクトル)が使用されるとき、ビデオコーダは、(POC値によって反映される)時間的ロケーションに基づいて、動きベクトルをスケーリングすることができる。たとえば、現在のピクチャのPOC値と参照ピクチャとのPOC値との差分が小さいときよりも、現在のピクチャのPOC値と参照ピクチャのPOC値との差分が大きいときに、ビデオコーダは、動きベクトルの大きさをより大きな量だけ増大させることができる。
[0089]TMVPから導出される時間的マージ用候補(merging candidate)に対するすべてのあり得る参照ピクチャリストのターゲット参照インデックスは、常に0に設定され得る。しかしながら、AMVPでは、すべてのあり得る参照ピクチャのターゲット参照インデックスは、復号参照インデックスに等しく設定される。言い換えれば、TMVPから導出される時間マージ用候補に関するすべてのあり得る参照ピクチャリストのターゲット参照インデックスは常に0に設定されるが、AMVPでは、時間マージ用候補は、復号参照インデックスに等しく設定され得る。HEVCでは、SPSはフラグ(たとえば、sps_temporal_mvp_enable_flag)を含んでよく、sps_temporal_mvp_enable_flagが1に等しく設定されるとき、スライスヘッダはフラグ(たとえば、pic_temporal_mvp_enable_flag)を含んでよい。ある特定のピクチャに対してpic_temporal_mvp_enable_flagとtemporal_idの両方が0に等しいとき、復号順序においてその特定のピクチャの前にあるピクチャからの動きベクトルは、その特定のピクチャ、または復号順序でその特定のピクチャの後にあるピクチャの復号において、TMVPとして使用されない。
[0090]次のセクションでは、(たとえば、H.264/MVCにおけるような)マルチビューコーディング技法および(たとえば、3D−HEVCにおけるような)マルチビュープラス奥行きコーディング技法について論じる。最初に、MVC技法について論じる。上述されたように、MVCは、ITU−T H.264/AVCのマルチビューコーディング拡張である。MVCでは、複数のビューに関するデータが時間優先(time-first)順序でコーディングされ、したがって、復号順序構成は、時間優先コーディングと呼ばれる。具体的には、共通の時間インスタンスにおける複数のビューの各々に関するビューコンポーネント(すなわち、ピクチャ)がコーディングされ得、次いで、異なる時間インスタンスについての別のセットのビューコンポーネントがコーディングされ得、以下同様である。アクセスユニットは、1つの出力時間インスタンスについてのすべてのビューのコード化ピクチャを含み得る。アクセスユニットの復号順序は、必ずしも出力(または表示)順序と同一であるとは限らないことを理解されたい。
[0091]典型的なMVC復号順序(すなわち、ビットストリーム順序)を図2に示す。復号順序構成は時間優先コーディングと呼ばれる。アクセスユニットの復号順序は出力または表示の順序と同じでないことがあることに留意されたい。図2では、S0〜S7は各々、マルチビュービデオの異なるビューを指す。T0〜T8は各々、1つの出力時間インスタンスを表す。アクセスユニットは、1つの出力時間インスタンスについてのすべてのビューのコード化ピクチャを含む場合がある。たとえば、第1のアクセスユニットは時間インスタンスT0についてのビューS0〜S7のすべてを含み得、第2のアクセスユニットは時間インスタンスT1についてのビューS0〜S7のすべてを含み得、以下同様である。
[0092]簡潔のために、本開示では、以下の定義を使用し得る。
ビューコンポーネント:単一のアクセスユニット中のビューのコード化表現。ビューが、コード化テクスチャ表現とコード化奥行き表現の両方を含むとき、ビューコンポーネントは、テクスチャビューコンポーネントと奥行きビューコンポーネントからなる。
テクスチャビューコンポーネント:単一のアクセスユニット中のビューのテクスチャのコード化表現。
奥行きビューコンポーネント:単一のアクセスユニット中のビューの奥行きのコード化表現。
[0093]図2では、ビューの各々はピクチャのセットを含む。たとえば、ビューS0はピクチャ0、8、16、24、32、40、48、56、および64のセットを含み、ビューS1はピクチャ1、9、17、25、33、41、49、57、および65のセットを含み、以下同様である。3Dビデオコーディング、たとえば、3D−HEVCでは、各ピクチャは2つのコンポーネントピクチャを含む場合があり、一方のコンポーネントピクチャはテクスチャビューコンポーネントと呼ばれ、他方のピクチャは奥行きビューコンポーネントと呼ばれる。ビューのピクチャのセット内のテクスチャビューコンポーネントと奥行きビューコンポーネントとは、互いに対応すると見なされ得る。たとえば、ビューのピクチャのセット内のテクスチャビューコンポーネントは、そのビューのピクチャのセット内の奥行きビューコンポーネントに対応すると見なされ、その逆も同様である(すなわち、奥行きビューコンポーネントはセット中のそのテクスチャビューコンポーネントに対応し、その逆も同様である)。本開示で使用する、奥行きビューコンポーネントに対応するテクスチャビューコンポーネントは、単一のアクセスユニットの同じビューの一部であるテクスチャビューコンポーネントおよび奥行きビューコンポーネントと見なされる場合がある。
[0094]テクスチャビューコンポーネントは、表示される実際の画像コンテンツを含む。たとえば、テクスチャビューコンポーネントは、ルーマ(Y)成分と、クロマ(CbおよびCr)成分とを含み得る。奥行きビューコンポーネントは、その対応するテクスチャビューコンポーネント中のピクセルの相対奥行きを示し得る。一例として、奥行きビューコンポーネントは、ルーマ値のみを含むグレースケール画像である。言い換えれば、奥行きビューコンポーネントは、任意の画像コンテンツを伝達するのではなく、テクスチャビューコンポーネント中のピクセルの相対奥行きの測定値を提供することができる。
[0095]たとえば、奥行きビューコンポーネント中の純白のピクセルは、対応するテクスチャビューコンポーネント中のその対応する1つまたは複数のピクセルが閲覧者から見てより近いことを示し、奥行きビューコンポーネント中の純黒のピクセルは、対応するテクスチャビューコンポーネント中のその対応する1つまたは複数のピクセルが閲覧者から見てより遠いことを示す。黒と白との中間にあるグレーの様々な陰影は、異なる奥行きレベルを示す。たとえば、奥行きビューコンポーネント中の濃いグレーのピクセルは、テクスチャビューコンポーネント中のその対応するピクセルが、奥行きビューコンポーネント中のより薄いグレーのピクセルよりも遠いことを示す。ピクセルの奥行きを識別するためにグレースケールのみが必要とされるので、奥行きビューコンポーネント用の色値がいかなる目的も果たし得ないことから、奥行きビューコンポーネントはクロマ成分を含む必要がない。
[0096]奥行きを識別するためにルーマ値(たとえば、強度値)のみを使用する奥行きビューコンポーネントが説明のために提供され、限定するものと見なされるべきではない。他の例では、テクスチャビューコンポーネント中のピクセルの相対奥行きを示すために任意の技法が利用され得る。
[0097]マルチビュービデオコーディングのための(各ビュー内のピクチャ間予測とビュー間予測の両方を含む)典型的なMVC予測構造を図3に示す。予測方向は矢印によって示され、矢印の終点のオブジェクトは、予測参照として矢印の始点のオブジェクトを使用する。MVCでは、H.264/AVC動き補償のシンタックスを使用するが、異なるビュー中のピクチャが参照ピクチャとして使用されることを可能にする視差動き補償により、ビュー間予測がサポートされる。
[0098]図3の例では、(ビューID「S0」〜「S7」を有する)8つのビューが示され、12個の時間ロケーション(「T0」〜「T11」)がビューごとに示されている。すなわち、図3中の各行はビューに対応し、一方、各列は時間ロケーションを示す。
[0099]MVCがH.264/AVCデコーダによって復号可能である、いわゆるベースビューを有し、また、ステレオビューペアがMVCによってもサポートされ得るが、MVCの利点は、MVCが、3Dビデオ入力として3つ以上のビューを使用し、複数のビューによって表されるこの3Dビデオを復号する例をサポートできることである。MVCデコーダを有するクライアントのレンダラは、複数のビューを用いて3Dビデオコンテンツを予想し得る。
[0100]図3中のピクチャは、各行と各列の交点に示されている。H.264/AVC規格は、ビデオの一部分を表すためにフレームという用語を使用し得る。本開示では、ピクチャという用語とフレームという用語とを互換的に使用し得る。
[0101]図3のピクチャは、対応するピクチャがイントラコーディングされる(すなわち、Iピクチャである)か、または一方向に(すなわち、Pピクチャとして)もしくは複数の方向に(すなわち、Bピクチャとして)インターコーディングされるかを指定する、文字を含むブロックを使用して示される。概して、予測は矢印によって示され、ここで矢印の終点のピクチャは、予測参照のために矢印の始点のピクチャを使用する。たとえば、時間ロケーションT0にあるビューS2のPピクチャは、時間ロケーションT0にあるビューS0のIピクチャから予測される。
[0102]シングルビュービデオ符号化の場合と同様に、マルチビュービデオコーディングビデオシーケンスのピクチャは、異なる時間ロケーションにあるピクチャに対して予測符号化され得る。たとえば、時間ロケーションT1にあるビューS0のbピクチャは、時間ロケーションT0にあるビューS0のIピクチャからそのbピクチャに向けられた矢印を有し、その矢印は、bピクチャがIピクチャから予測されることを示す。しかしながら、加えて、マルチビュービデオの符号化のコンテキストにおいて、ピクチャはビュー間予測され得る。すなわち、ビューコンポーネントは、参照のために他のビュー中のビューコンポーネントを使用することができる。MVCでは、たとえば、別のビュー中のビューコンポーネントがインター予測参照であるかのように、ビュー間予測が実現される。潜在的なビュー間参照は、シーケンスパラメータセット(SPS:Sequence Parameter Set)MVC拡張においてシグナリングされ、インター予測またはビュー間予測参照のフレキシブルな順序付けを可能にする参照ピクチャリスト構築プロセスによって修正され得る。ビュー間予測は、3D−HEVC(マルチビュープラス奥行き)を含む、HEVCの提案されたマルチビュー拡張の機能でもある。
[0103]図3は、ビュー間予測の様々な例を提供する。図3の例では、ビューS1のピクチャは、ビューS1の異なる時間ロケーションにあるピクチャから予測されるものとして、ならびに同じ時間ロケーションにあるビューS0およびS2のピクチャからビュー間予測されるものとして示されている。たとえば、時間ロケーションT1にあるビューS1のbピクチャは、時間ロケーションT0およびT2にあるビューS1のBピクチャの各々、ならびに時間ロケーションT1にあるビューS0およびS2のbピクチャから予測される。
[0104]いくつかの例では、図3は、テクスチャビューコンポーネントを示すものとして見なされ得る。たとえば、図2に示すIピクチャ、Pピクチャ、Bピクチャ、およびbピクチャは、ビューの各々に関するテクスチャビューコンポーネントと見なされ得る。本開示で説明される技法によれば、図3に示すテクスチャビューコンポーネントの各々について、対応する奥行きビューコンポーネントが存在する。いくつかの例では、奥行きビューコンポーネントは、対応するテクスチャビューコンポーネントについて図3に示す方法と同様の方法で予測され得る。
[0105]2つのビューのコーディングもMVCにおいてサポートされ得る。MVCの利点のうちの1つは、MVCエンコーダが3Dビデオ入力として3つ以上のビューをとらえることができ、また、MVCデコーダがそのようなマルチビュー表現を復号することができることである。したがって、MVCデコーダをもつ任意のレンダラは、3つ以上のビューをもつ3Dビデオコンテンツを予想し得る。
[0106]MVCでは、同じアクセスユニット中の(すなわち、同じ時間インスタンスをもつ)ピクチャ間でビュー間予測が可能にされる。非ベースビューのうちの1つの中のピクチャをコーディングするとき、ピクチャが異なるビュー中にあるが同じ時間インスタンス内にある場合、そのピクチャは参照ピクチャリストに追加され得る。ビュー間参照ピクチャは、任意のインター予測参照ピクチャと同様に、参照ピクチャリストの任意の位置に置かれ得る。図3に示すように、ビューコンポーネントは、参照のために他のビュー中のビューコンポーネントを使用することができる。MVCでは、別のビュー中のビューコンポーネントがインター予測参照であるかのように、ビュー間予測が実現される。
[0107]マルチビュービデオコーディングのコンテキストでは、概して、2種類の動きベクトルが存在する。1つは、通常の動きベクトルと呼ばれる。通常の動きベクトルは時間参照ピクチャを指し、対応する時間インター予測は動き補償予測(MCP)である。もう1つの動きベクトルは視差動きベクトル(DMV)である。DMVは、異なるビュー中のピクチャ(すなわち、ビュー間参照ピクチャ)を指し、対応するインター予測は視差補償予測(DCP:disparity-compensated prediction)である。
[0108]別のタイプのマルチビュービデオコーディングフォーマットは、(たとえば、3D−HEVCにおけるような)奥行き値の使用を導入する。3Dテレビジョンおよび自由視点ビデオ(free viewpoint video)用に普及しているマルチビュービデオプラス奥行き(MVD)データフォーマットでは、マルチビューテクスチャピクチャを用いて、テクスチャ画像と奥行きマップとが独立してコーディングされ得る。図4は、テクスチャ画像およびその関連するサンプルごとの奥行きマップを有するMVDデータフォーマットを示す。奥行き範囲は、対応する3Dポイントに関してカメラからの最小距離Znearおよび最大距離Zfarの範囲内にあるように制限され得る。
[0109]カメラパラメータおよび奥行き範囲値は、3Dディスプレイ上でレンダリングするのに先立って復号されたビュー成分を処理するのに役立つ場合がある。したがって、特別な補足エンハンスメント情報(SEI)メッセージは、H.264/MVCの現行バージョン、すなわち、取得環境の様々なパラメータを指定する情報を含むマルチビュー取得情報SEIに関して定義される。しかしながら、奥行き範囲関連の情報を示すためにH.264/MVCにおいて指定されるシンタックスは存在しない。
[0110]次に、HEVCにおける非対称動き分割(AMP)および動き補償ブロックサイズについて論じる。HEVCでは、インターコード化コーディングブロックは、1つ、2つ、または4つのパーティションに分割され得る。様々な形のそのような分割が可能である。インター予測されたコーディングブロックに関する例示的な分割可能性を図5に示す。
[0111]図5の上の行の分割は、いわゆる対称分割を示す。N×N分割は、単に、分割されていないコーディングブロックである。N/2×N分割は、2つの垂直の矩形パーティションに分割されたコーディングブロックである。同様に、N×N/2分割は、2つの水平の矩形パーティションに分割されたコーディングブロックである。N/2×N/2分割は、4つの等しい正方形パーティションに分割されたコーディングブロックである。
[0112]図5の下の4つの分割タイプは、非対称分割と呼ばれ、インター予測のための非対称動き分割(AMP)内で使用され得る。AMPモードの一方のパーティションは、それぞれ、高さまたは幅N/4および幅または高さNを有し、もう一方のパーティションは、3N/4の高さまたは幅および幅または高さNを有することによって、CBの残りからなる。各インターコード化パーティションには、1つまたは複数の動きベクトルおよび参照ピクチャインデックス(すなわち、単方向予測については1つの動きベクトルおよび参照インデックス、ならびに、双方向予測については2つの動きベクトルおよび参照インデックス)が割り当てられる。いくつかの例では、最悪のメモリ帯域幅を最小限に抑えるために、サイズ4×4のパーティションはインター予測用に許可されず、サイズ4×8および8×4のパーティションは、予測データの1つのリストに基づいている単予測コーディングに制限される。
[0113]下でより詳細に論じるように、本開示は、後方ビュー合成予測(BVSP)を含む、3D−HEVCコーディング技法とともに使用されるときのAMPのための技法を説明する。
[0114]以下は、HEVC内のマージ候補リストについて説明する。たとえば、マージ候補リストは、以下のステップを用いて構築され得る。空間マージ用候補のために、ビデオエンコーダ20および/またはビデオデコーダ30は、図6に示すように、5つの空間的隣接ブロックから4つまでの空間動きベクトル候補を導出することができる。
[0115]ビデオエンコーダ20およびビデオデコーダ30が空間的隣接ブロックを評価し得る順序は、以下の通り、すなわち、図6に示すように、左(A1)、上(B1)、右上(B0)、左下(A0)、および左上(B2)である。いくつかの例では、同一動き情報(たとえば、動きベクトルおよび参照インデックス)を有する動きベクトル候補を除去するために剪定過程が適用され得る。たとえば、B1の動きベクトルおよび参照インデックスは、A1の動きベクトルおよび参照インデックスと比較され得、B0の動きベクトルおよび参照インデックスは、B1の動きベクトルおよび参照インデックスと比較され得、A0の動きベクトルおよび参照インデックスは、A1の動きベクトルおよび参照インデックスと比較され得、B2の動きベクトルおよび参照インデックスは、B1ならびにA1の動きベクトルおよび参照インデックスと比較され得る。次いで、同一動き情報を有する2つの候補のうちの1つが動きベクトル候補リストから除外され得る。剪定過程の後、4つの利用可能な候補がすでに存在する場合、候補B2はマージ候補リストに挿入されない。
[0116]参照ピクチャからのコロケート時間的動きベクトル予測子(TMVP)候補は、有効にされて、利用可能な場合、空間的動きベクトル候補の後に動きベクトル候補リストに追加される。
[0117]動きベクトル候補リストが完全でない(たとえば、所定の数未満のエントリーを有する)場合、1つまたは複数の人工的動きベクトル候補が生成されて、マージ候補リストの最後に挿入され得る。人工的動きベクトル候補の例示的なタイプは、Bスライスだけに関して導出された結合双予測マージ用候補と、所定の数の動きベクトル候補に関して提供するために十分な双予測マージ用候補(または、他のタイプの人工的動きベクトル候補)が存在しない場合、ゼロ動きベクトルマージ用候補とを含む。
[0118]現在スライスがBスライスであるとき、結合双予測マージ用候補の導出プロセスが呼び出される。候補リスト中にすでにあり、必要な動き情報を有する候補の各対に関して、(利用可能な場合)リスト0中のピクチャを指す(I0CandIdxに等しいマージ候補インデックスを有する)第1の候補の動きベクトルと(利用可能であり、参照ピクチャまたは動きベクトルのいずれかが第1の候補とは異なる場合)リスト1中のピクチャを指す(I1CandIdxに等しいマージ候補インデックスを有する)第2の候補の動きベクトルの組み合わせを使用して、(combIdxによって示されるインデックスを有する)結合双予測動きベクトル候補が導出される。
[0119]図7は、3D−HEVCにおけるI0CandIdxおよびI1CandIdxの例示的な仕様を示す表である。たとえば、図7は、combIdxに対応するI0CandIdxおよびI1CandIdxの定義を示す。
[0120]0...11であるcombIdxでは、以下の1つの条件が当てはまるとき、結合双予測動きベクトル候補の生成プロセスは終了する。すなわち、(1)combIdxが(numOrigMergeCand*(numOrigMergeCand−1))に等しいとき、ここにおいて、numOrigMergeCandは、このプロセスを呼び出す前のマージリスト内の候補の数を示す、(2)(新規に生成された結合双予測マージ用候補を含めて)マージリスト中の総候補数がMaxNumMergeCandに等しいとき、である。
[0121]このセクションは、ゼロ動きベクトルマージ用候補の導出について説明する。各候補に関して、ゼロ動きベクトルおよび参照ピクチャインデックスは、0から利用可能な参照ピクチャインデックスから1を指し引いた数に設定される。(たとえば、MaxNumMergeCandシンタックス要素によって示される)最大数のマージ動きベクトル候補よりも依然として少ない候補が存在する場合、候補の総数がMaxNumMergeCandに等しくなるまで、ゼロ参照インデックスおよび動きベクトルが挿入される。
[0122]以下は、HEVCにおける動き補償サイズの制約について説明する。最悪のメモリ帯域幅を最小限に抑えるために、サイズ4×4のパーティションはインター予測用に許可されず、サイズ4×8および8×4のパーティションは単予測コーディングに制限される。
[0123]上記に述べたそのような制約を満たすために、現在PUサイズが8×4または4×8に等しいとき、生成された空間的/時間的/結合双予測マージ用候補、それが双予測モードに関連する場合、現在PUは、予測方向をリスト0に修正し、RefPicList1に対応する参照ピクチャインデックスおよび動きベクトルを、それぞれ、−1および(0,0)に修正することによって、単予測を使用するようにリセットされるべきである。
[0124]上述のように、3D−HEVCは開発中である。3D−HEVCは、ビュー間動き予測とビュー間残差予測とを使用して、コーディング効率を改善することができる。言い換えれば、コーディング効率をさらに改善するために、2つの新規の技術、すなわち、「ビュー間動き予測」および「ビュー間残差予測」が、参照ソフトウェアに採用されてきている。ビュー間動き予測では、ビデオコーダ(たとえば、ビデオエンコーダ20またはビデオデコーダ30)は、現在PUとは異なるビュー中のPUの動き情報に基づいて、現在PUの動き情報を決定する(すなわち、予測する)ことができる。ビュー間残差予測では、ビデオコーダは、現在CUとは異なるビュー中の残差データに基づいて、現在CUの残差ブロックを決定することができる。
[0125]3D−HEVCにおける隣接ブロックベースの視差ベクトル(NBDV)導出について、次に説明する。3D−HEVCがすべてのビューに対してテクスチャ優先コーディング順序を使用することにより、NBDV導出は3D−HEVCにおける視差ベクトル導出技法として使用される。現在コーディングされているテクスチャピクチャに対して、対応する奥行きマップが利用可能でないため、視差ベクトルは隣接ブロックから導出される。3D−HEVC設計に関するいくつかの提案では、NBDV導出プロセスから導出された視差ベクトルは、参照テクスチャビューに対応する奥行きデータを取り出すことによって、さらに改良され得る。
[0126]3D−HEVCは、当初、JCT3V−A0097(3D−CE5.h:Disparity vector generation results、L.Zhang、Y.Chen、M.Karczewicz(Qualcomm))で提案されたNBDV導出技法を採用した。暗黙的視差ベクトル(implicit disparity vector)が、JCTVC−A0126(3D−CE5.h:Simplification of disparity vector derivation for HEVC−based 3D video coding、J.Sung、M.Koo、S.Yea(LG))において簡略化されたNBDVとともに含まれた。加えて、JCT3V−B0047(3D−CE5.h関連:Improvements for disparity vector derivation、J.Kang、Y.Chen、L.Zhang、M.Karczewicz(Qualcomm))では、NBDV導出技法は、復号ピクチャバッファ中に記憶された暗黙的視差ベクトルを除去することによって、さらに簡略化されたが、また、ランダムアクセスピクチャ(RAP)選択を用いてコーディング利得も改善した。NBDV導出に関する追加の技法は、JCT3V−D0181(CE2:CU based Disparity Vector Derivation in 3D−HEVC、J.Kang、Y.Chen、L.Zhang、M.Karczewicz(Qualcomm))で説明された。
[0127]視差ベクトル(DV)は、2つのビュー間の変位の推定量として使用される。隣接ブロックはビデオコーディングにおいてほとんど同じ動き/視差情報を共有するので、現在ブロックは、良好な予測子として、隣接ブロック中の動きベクトル情報を使用することができる。この考えに従って、NBDV導出プロセスは、異なるビュー中の視差ベクトルを推定するために、隣接する視差情報を使用する。
[0128]NBDVを改善するために、ビデオエンコーダ20は、最初に、いくつかの空間的隣接ブロックおよび時間的隣接ブロックを定義する。ビデオコーダ20は次いで、現在ブロックと候補ブロックとの間の相関付けの優先順位によって決定される、事前に定義された順序で隣接ブロックの各々を確認することができる。視差動きベクトル(すなわち、ビュー間参照ピクチャを指す動きベクトル)が候補中で発見されると、ビデオエンコーダ20は、視差動きベクトルを視差ベクトルに変換し、関連するビュー順序インデックスも返される。隣接ブロックの2つのセットが利用される。一方のセットは空間的隣接ブロックを含み、他方のセットは時間的隣接ブロックを含む。
[0129]3D−HEVCに関する最近の提案では、NBDV導出において2つの空間的隣接ブロックが使用される。空間的隣接ブロックは、図8で、それぞれ、A1およびB1によって示されるように、現在コーディングユニット(CU)90に対して左および上の隣接ブロックである。図8に示す隣接ブロックは、HEVCにおけるマージモードにおいて使用される隣接ブロックのうちのいくつかと同じロケーションにあることに留意されたい。したがって、追加のメモリアクセスは必要とされない。しかしながら、現在CU90に対して他のロケーションの隣接ブロックも使用され得ることを理解されたい。
[0130]時間的隣接ブロックを確認するために、ビデオエンコーダ20は、候補ピクチャリストに関する構築プロセスを最初に実行する。現在ビューから2つまでの参照ピクチャが、候補ピクチャとして扱われ得る。ビデオエンコーダ20は、最初に、コロケート参照ピクチャを候補ピクチャリストに追加し、続いて、候補ピクチャの残りを参照インデックスの昇順に追加する。両方の参照ピクチャリスト中で同じ参照インデックスを有する参照ピクチャが利用可能であるとき、コロケートピクチャと同じ参照ピクチャリスト中の参照ピクチャが、同じ参照インデックスを有する他の参照ピクチャに先行する。候補ピクチャリスト中の各候補ピクチャに関して、ビデオエンコーダ20は、中央位置をカバーするコロケート領域のブロックを時間的隣接ブロックであると決定する。
[0131]ブロックがビュー間動き予測でコーディングされるとき、異なるビュー中の対応するブロックを選択するために、視差ベクトルが導出され得る。ビュー間動き予測プロセスにおいて導出された視差ベクトルは、暗黙的視差ベクトル(IDV)、または、導出視差ベクトルと呼ばれる。ブロックが動き予測でコーディングされるとしても、導出された視差ベクトルは、後続のブロックをコーディングするために破棄されない。
[0132]HTMの一設計では、NBDV導出プロセスの間、ビデオコーダ(たとえば、ビデオエンコーダ20および/またはビデオデコーダ30)は時間的隣接ブロック中の視差動きベクトル、空間的隣接ブロック中の視差動きベクトル、次いで、IDVの順に確認するように構成される。視差動きベクトルまたはIDVが発見されると、プロセスは終了する。
[0133]奥行き情報にアクセスすることによるNBDV導出プロセスの改良(NBDV−R)について次に論じる。視差ベクトルがNBDV導出プロセスから導出されるとき、導出された視差ベクトルは、参照ビューの奥行きマップから奥行きデータを取り出すことによって、さらに改良される。改良プロセスは、次の技法を含み得る。
a)ベースビューなど、前にコーディングされた参照奥行きビュー中の導出された視差ベクトルによって、対応する奥行きブロックを位置特定し、対応する奥行きブロックのサイズは、現在PUのものと同じである。
b)対応する奥行きブロックの4つのコーナーピクセルから1つの奥行き値を選択し、その奥行き値を改良された視差ベクトルの水平成分に変換する。視差ベクトルの垂直成分は不変である。
[0134]いくつかの例では、改良された視差ベクトルはビュー間動き予測のために使用され得るが、改良されていない視差ベクトルはビュー間残差予測のために使用され得ることに留意されたい。加えて、あるPUが後方ビュー合成予測モードを用いてコーディングされている場合、改良された視差ベクトルは、そのPUの動きベクトルとして記憶され得る。3D−HEVCに関するいくつかの提案では、ベースビューの奥行きビューコンポーネントは、NBDV導出プロセスから導出されたビュー順序インデックスの値にかかわらずアクセスされ得る。
[0135]次に、3D−HEVCにおける後方ビュー合成予測(BVSP)技法について論じる。http://phenix.it−sudparis.eu/jct2/doc_end_user/current_document.php?id=594から入手可能な、D.Tianら、「CE1.h:Backward View Synthesis Prediction Using Neighboring Blocks」、JCT3V−C0152によって提案される、1つの例示的なBVSP手法が第3回JCT−3V会議で採用された。BVSPの基本的な考えは、3D−AVCにおけるブロックベースのビュー合成予測と同様である。これらの2つの技法は両方とも、動きベクトル差分を送信することを避け、より正確な動きベクトルを使用するために、後方ワーピングとブロックベースのビュー合成予測とを使用する。3D−HEVCおよび3D−AVCにおけるBVSPの実装詳細は、異なるプラットフォームにより異なる。
[0136]3D−HEVCでは、スキップモードまたはマージモードのいずれかでコーディングされるインターコード化ブロックに関して、BVSPモードがサポートされる。3D−HEVCに関する1つの例示的な提案では、高度動きベクトル予測(AMVP)モードでコーディングされるブロックに関して、BVSPモードは許可されない。BVSPモードの使用を示すためにフラグを送信する代わりに、ビデオエンコーダ20は、1つの追加のマージ用候補(すなわち、BVSPマージ用候補)をマージ候補リストに追加するように構成され得、各候補は1つのBVSPフラグに関連付けられる。復号マージインデックスがBVSPマージ用候補に対応するとき、復号マージインデックスは、現在予測ユニット(PU)がBVSPモードを使用することを示す。現在PU中の各サブブロックに関して、奥行き参照ビュー中の奥行き値を変換することによって、視差動きベクトルが導出され得る。
[0137]BVSPフラグの設定は次のように定義される。空間的マージ用候補を導出するために使用される空間的隣接ブロックがBVSPモードを用いてコーディングされるとき、従来のマージングモードにおけるように、空間的マージ用候補の関連する動き情報は現在ブロックによって継承される。加えて、この空間的マージ用候補は、(すなわち、空間的マージ用候補がBVSPモードを用いてコーディングされたことを示す)1に等しいBVSPフラグに関連付けられる。新規に導入されたBVSPマージ用候補に関して、BVSPフラグは1に設定される。すべての他のマージ用候補に関して、関連するBVSPフラグは0に設定される。
[0138]上記で論じたように、3D−HEVCでは、ビデオエンコーダ20は、BVSPマージ用候補という名称の新規の候補を導出して、マージ候補リストに挿入するように構成され得る。対応する参照ピクチャインデックスおよび動きベクトルは、次の方法によって設定される。
[0139]第1のビデオエンコーダ20は、NBDV導出プロセスから導出された視差ベクトルのビューインデックスシンタックス要素(たとえば、3D−HEVCのrefVIdxLX)によって示されるビューインデックスを取得するように構成され得る。ビデオエンコーダ20はまた、refVIdxLXに等しいビュー順序インデックスを有する参照ピクチャに関連付けられた参照ピクチャリスト(たとえば、RefPicListX(RefPicList0またはRefPicList1のいずれか))を取得するように構成され得る。ビデオエンコーダ20は、次いで、NBDV導出プロセスから取得された、対応する参照ピクチャインデックスと視差ベクトルとを、RefPicListX(すなわち、RefPicList0またはRefPicList1のいずれか)中のBVSPマージ用候補の動き情報として使用する。
[0140]現在スライスがBスライスである場合、ビデオエンコーダ20は、RefPicListX以外の参照ピクチャリスト、すなわち、Yが1−XであるRefPicListYの中のrefVIdLXに等しくないrefVIdxLYによって示されたビュー順序インデックスを有するビュー間参照ピクチャの可用性を確認する。そのような異なるビュー間参照ピクチャが発見された場合、ビデオエンコーダ20は双予測的ビュー合成予測を実行する。ビデオエンコーダ20は、異なるビュー間参照ピクチャの対応する参照ピクチャインデックスと、NBDV導出プロセスからスケーリングされた視差ベクトルとを、RefPicListY中のBVSPマージ用候補の動き情報として使用するようにさらに構成され得る。(テクスチャ優先コーディング順序の場合)refVIdxLXに等しいビュー順序インデックスを有するビューからの奥行きブロックが現在ブロックの奥行き情報として使用される。ビデオエンコーダ20は、後方ワーピングプロセスによって2つの異なるビュー間参照ピクチャ(各参照ピクチャリストから1つ)を合成し、最終的なBVSP予測子を達成するために、合成された参照ピクチャをさらに重み付けする。
[0141]Bスライス以外のスライスタイプ(たとえば、Pスライス)の場合、ビデオエンコーダ20は、RefPicListXを有する単予測的ビュー合成予測を予測のための参照ピクチャリストとして適用する。
[0142]3D−HTMでは、テクスチャ優先コーディングが共通テスト条件において適用される。ビューのテクスチャコンポーネントは奥行きコンポーネントの前にコーディングされるため、1つの非ベーステクスチャコンポーネントを復号するとき、対応する非ベース奥行きコンポーネントは利用可能でない。したがって、ビデオデコーダ30は、奥行き情報を推定し、次いで、BVSPを実行するために、推定された奥行き情報を使用するように構成され得る。ブロックに関する奥行き情報を推定するために、(たとえば、NBDV導出プロセスを使用して)隣接ブロックから視差ベクトルを最初に導出し、次いで参照ビューから奥行きブロックを取得するために、導出された視差ベクトルを使用することが提案される。
[0143]図9は、参照ビューから奥行きブロックを位置特定し、次いで、BVSP予測のためにその奥行きブロックを使用するための例示的な技法を示す。最初に、ビデオエンコーダ20および/またはビデオデコーダ30は、隣接ブロック102に関連付けられた視差ベクトル104を利用することができる。すなわち、ビデオエンコーダ20および/またはビデオデコーダ30は、(隣接ブロック102など)すでに符号化された隣接ブロックから視差ベクトル情報にアクセスし、現在ブロック100に関する何らかの関連付けられた視差ベクトル情報を再使用することができる。視差ベクトル104は、参照奥行きピクチャ中の奥行きブロック106を指す。視差ベクトル104が現在ブロック100に関して再使用されるとき、視差ベクトル104は、次に、参照奥行きピクチャ中の奥行きブロック108を指す。奥行きブロック108は現在ブロック100に対応する。ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、後方ワーピング技法を使用して、参照テクスチャピクチャ中のブロックを合成するために、参照奥行きピクチャ108中の奥行き情報を使用することができる。次いで、現在ブロック100を予測するために、合成されたテクスチャピクチャが参照ピクチャとして使用され得る。
[0144]本開示の一例では、NBDV導出プロセスでは、NBDV導出プロセスによって識別された視差ベクトル104を(dvx,dvy)で示し、現在ブロック100の位置を(blockx,blocky)として示す。単予測的BVSPの一例では、ビデオエンコーダ20および/またはビデオデコーダ30は、参照ビューの奥行きビューコンポーネント中に(blockx+dvx,blocky+dvy)の左上位置を有する奥行きブロック108をフェッチするように構成され得る。ビデオエンコーダ20および/またはビデオデコーダ30は、現在ブロック100(たとえば、PU)を、各々が(たとえば、W*Hに等しい)同じサイズを有する、いくつかのサブブロックに最初に分割するように構成され得る。W*Hに等しいサイズを有する各サブブロックに関して、ビデオエンコーダ20および/またはビデオデコーダ30は、たとえば、図10に示すように、フェッチされた奥行きビューコンポーネント内の対応する奥行きサブブロック108の4つのコーナーピクセルから最大奥行き値を識別する。図10は、8×8奥行きブロック110の4つのコーナーピクセルを示す概念図である。4つのコーナーピクセルは、左上(TL)ピクセル、右上(TR)ピクセル、左下(BL)ピクセル、および右下(BR)ピクセルとして標示され得る。ビデオエンコーダ20および/またはビデオデコーダ30は、最大奥行き値を視差動きベクトルに変換する。各サブブロックに関して導出された視差動きベクトルは、次いで、動き補償のために使用される。
[0145]このセクションは、双方向予測を実行するときのBVSPについて論じる。RefPicList0およびRefPicList1の中の異なるビューからの複数のビュー間参照ピクチャが存在するとき、ビデオエンコーダ20および/またはビデオエンコーダ30は、双予測的BVSPを適用する。双予測的BVSPでは、上で説明したように、各参照リストから、2つのビュー合成予測予測子(すなわち、2つの合成参照ブロック)が生成されることになる。これらの2つのビュー合成予測予測子は、次いで、最終的なビュー合成予測予測子を取得するために平均化される。
[0146]動き補償サイズ、すなわち、上で説明したW*Hは、8×4または4×8のどちらかであり得る。一例では、動き補償サイズを決定するために、次の規則が適用される。
各8×8ブロックに関して、対応する奥行き8×8ブロックの4つのコーナーが確認され、
[0147]以下は、3D−HEVCに関する1つの提案における、スキップ/マージモードに関するビュー間候補導出プロセスについて説明する。NBDV導出プロセスから導出された視差ベクトルに基づいて、ビュー間予測動きベクトル候補(IPMVC)と呼ばれる、新規の動きベクトル候補は、利用可能な場合、AMVPモードおよびスキップ/マージモードベクトル候補リストに追加され得る。ビュー間予測動きベクトルは、利用可能な場合、時間的動きベクトルである。スキップモードはマージモードと同じ動きベクトル導出プロセスを有するので、本文書で説明するすべての技法は、マージモードとスキップモードの両方に適用される。
[0148]図11は、マージ/スキップモードのためのビュー間予測動きベクトル候補の例示的な導出を示す概念図である。たとえば、図11は、ビュー間予測動きベクトル候補の導出プロセスの一例を示す。マージ/スキップモードでは、ビュー間予測動きベクトル候補は次のステップによって導出される。まず、ビデオエンコーダ20および/またはビデオデコーダ30は、視差ベクトルを使用して、同じアクセスユニットの参照ビュー中の現在PU/CU114の対応するブロック(たとえば、参照ブロック)112を位置特定する。図11の例では、現在ブロック(現在PU)114はビューV1中にあるが、対応する参照ブロック112はビューV0中にある。対応する参照ブロック112がイントラコード化予測およびインターコード化予測されず、(この例では、ビューV0および時間T1中の)その参照ピクチャが現在PU/CU114の同じ参照ピクチャリスト中の1つのエントリーの値に等しいPOC値を有する場合、参照ピクチャのPOCに基づいて、参照インデックスを変換した後、ビュー間予測動きベクトルになるように、対応する参照ブロック112の動き情報(すなわち、予測方向、参照ピクチャインデックス、および動きベクトル)が導出される。
[0149]対応する参照ブロック112は次のように定義され得る。現在ピクチャの左上ルーマサンプルに対する現在予測ユニットの左上ルーマサンプルのルーマロケーション(xP,yP)を最初に示す。変数nPSWおよびnPSHは、それぞれ、現在予測ユニットの幅と高さとを示す。参照ビュー順序インデックスはrefViewIdxと標示され、視差ベクトルはmvDispとして標示される。参照レイヤルーマロケーション(xRef,yRef)は以下によって導出される。
[0150]対応する参照ブロック112は、refViewIdxに等しいViewIdxを有するビューコンポーネント中のルーマロケーション(xRef,yRef)をカバーする予測ユニットに設定される。
[0151]加えて、視差ベクトルは、IPMVCとは異なる位置中のマージ候補リスト中に追加されるビュー間視差動きベクトル(IDMVC)に変換され得る。ビュー間視差動きベクトルはまた、利用可能なとき、IPMVCと同じ位置中のAMVP候補リスト中に追加され得る。IPMVCまたはIDMVCのいずれも、このコンテキストでは「ビュー間候補」と呼ばれることがある。
[0152]マージ/スキップモードに関する一例では、IPMVCは、利用可能な場合、すべての空間的マージ用候補および時間的マージ用候補の前に、マージ候補リストに挿入される。IDMVCは、A0から導出された空間的マージ用候補の前に挿入される。
[0153]以下のセクションでは、3D−HEVCにおけるテクスチャコーディングのためのマージ候補リスト構築について説明する。まず、ビデオエンコーダ20および/またはビデオデコーダ30は、たとえば、上記で説明したNBDV導出技法を使用して、視差ベクトルを導出する。視差ベクトルを導出した後、ビデオエンコーダ20および/またはビデオデコーダ30は、下記で説明するように、3D−HEVCにおけるマージ候補リスト構築を実行するように構成され得る。
[0154]ビデオエンコーダ20および/またはビデオデコーダ30は、上記で説明した手順を使用して、1つまたは複数のIPMVCを導出することができる。IPMVCが利用可能である場合、IPMVCはマージリストに挿入され得る。
[0155]次に、ビデオエンコーダ20および/またはビデオデコーダ30は、3D−HEVCにおける空間的マージ候補および1つまたは複数のIDMVC挿入を導出するように構成され得る。空間的マージ候補を導出するために、ビデオエンコーダ20および/またはビデオデコーダ30は、次の順序で空間的隣接PUの動き情報を確認するように構成され得る。すなわち、たとえば、図6に示すように、A1、B1、B0、A0、またはB2である。
[0156]ビデオエンコーダ20および/またはビデオデコーダ30は、制約された剪定を実行するようにさらに構成され得る。制約された剪定を実行するために、A1およびIPMVCが同じ動きベクトルと同じ参照インデックスとを有する場合、ビデオエンコーダ20および/またはビデオデコーダ30は、ロケーションA1における空間的マージ候補をマージ候補リストに挿入しないように構成され得る。そうでなければ、ロケーションA1における空間的マージ候補はマージ候補リストに挿入される。
[0157]ロケーションB1におけるマージ候補および(IPMVCの場合)マージロケーションA1におけるマージ候補が同じ動きベクトルと同じ参照インデックスとを有する場合、ロケーションB1におけるマージ候補はマージ候補リストに挿入されない。そうでなければ、ロケーションB1におけるマージ候補はマージ候補リストに挿入される。ロケーションB0におけるマージ候補が利用可能である(すなわち、コーディングされ、動き情報を有する)場合、ロケーションB0におけるマージ候補が候補リストに追加される。ビデオエンコーダ20および/またはビデオデコーダ30は、上記で説明した手順を使用してIDMVCを導出する。IDMVCが利用可能であり、IDMVCの動き情報がA1およびB1から導出された候補とは異なる場合、IDMVCは候補リストに挿入される。
[0158]BVSPがピクチャ全体(または、現在のスライスに関して)有効にされる場合、BVSPマージ用候補はマージ候補リストに挿入される。ロケーションA0におけるマージ候補が利用可能である場合、そのマージ候補が候補リストに追加される。ロケーションB2におけるマージ用候補が利用可能である場合、そのマージ用候補が候補リストに追加される。
[0159]次のセクションは、3D−HEVCにおける時間的マージ用候補に関する導出プロセスについて論じる。3D−HEVCにおける時間的マージ用候補導出は、コロケートPUの動き情報が利用される、HEVCにおける時間的マージ用候補導出プロセスと同様である。しかしながら、3D−HEVCでは、参照ピクチャインデックスを0に固定する代わりに、時間的マージ用候補のターゲット参照ピクチャインデックスは変更され得る。0に等しいターゲット参照インデックスが(同じビュー中の)時間的参照ピクチャに対応する一方で、コロケート予測ユニット(PU)の動きベクトルがビュー間参照ピクチャを指すとき、ターゲット参照インデックスは、参照ピクチャリスト中のビュー間参照ピクチャの第1のエントリーに対応する別のインデックスに変更される。反対に、0に等しいターゲット参照インデックスがビュー間参照ピクチャに対応する一方で、コロケート予測ユニット(PU)の動きベクトルが時間的参照ピクチャを指すとき、ターゲット参照ピクチャインデックスは、参照ピクチャリスト中の時間的参照ピクチャの第1のエントリーに対応する別のインデックスに変更される。
[0160]次に、3D−HEVCにおける結合双予測マージ用候補に関する導出プロセスについて論じる。上記の2つのステップ(すなわち、空間的マージ用候補の導出および時間的マージ用候補の導出)から導出された候補の総数が(あらかじめ画定された)候補の最大数未満である場合、上記で説明した、HEVCで定義されたのと同じプロセスが実行される。しかしながら、参照インデックスI0CandIdxおよびI1CandIdxの仕様は異なる。図12は、3D−HEVCにおけるI0CandIdxおよびI1CandIdxの例示的な仕様を示す別の表である。たとえば、combIdx、I0CandIdx、およびI1CandIdxの間の関係は、図12に示す表において定義されている。
[0161]3D−HEVにおけるゼロ動きベクトルマージ用候補に関する1つの例示的な導出プロセスは、HEVCにおいて定義されたのと同じ手順である。3D−HEVCに関する一例では、マージ候補リスト中の候補の総数は最大6であり、five_minus_max_num_merge_candシンタックス要素が、6から減算されるマージ候補の最大数をスライスヘッダ中で指定するために生成される。シンタックス要素five_minus_max_num_merge_candの値は、両端値を含む、0から5の範囲内にあることに留意されたい。
[0162]以下は、たとえば、3D−HEVCにおける奥行きコーディングのための動きベクトル継承(MVI)について説明する。MVI技法は、ピクチャのテクスチャコンポーネントとその関連付けられた奥行きビューコンポーネントとの間の動き特性の類似度を活用することを探索する。図13は、奥行きコーディングのための動きベクトル継承候補の例示的な導出を示す概念図である。たとえば、図13は、テクスチャピクチャ124中の現在PU122の中央の右下に対して位置特定される4×4ブロックとして、対応するテクスチャブロック120が選択される、MVI候補の導出プロセスの例を示す。奥行きピクチャ128中の現在PU126では、MVI候補は、そのような情報が利用可能である場合、対応するテクスチャピクチャ124中ですでにコーディングされている対応するテクスチャブロック120に関連付けられた動きベクトルおよび参照インデックスの使用を再使用する。
[0163]整数精度の動きベクトルが奥行きコーディングにおいて使用されるが、4分の1精度の動きベクトルがテクスチャコーディングのために利用されることに留意されたい。したがって、対応するテクスチャブロックの動きベクトルは、MVI候補として使用する前にスケーリングされ得る。
[0164]MVI候補生成により、奥行きビューに関するマージ候補リストが次のように構築される。MVI挿入では、上記で説明した技術を使用してMVIが導出され、利用可能である場合、マージ候補リストに挿入される。
[0165]奥行きコーディングのための3D−HEVCにおける空間的マージ用候補の導出プロセスおよびIDMVC挿入について下記で説明する。最初に、ビデオエンコーダ20および/またはビデオデコーダ30は、次の順序で空間的隣接PUの動き情報を確認するように構成され得る。すなわち、A1、B1、B0、A0、またはB2である。
[0166]ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、次のように制約された剪定を実行することができる。ロケーションA1における動きベクトル候補およびMVI候補が同じ動きベクトルと同じ参照インデックスとを有する場合、A1における動きベクトル候補はマージ候補リストに挿入されない。ロケーションB1における動きベクトル候補およびロケーションA1における動きベクトル候補/MVI候補が同じ動きベクトルと同じ参照インデックスとを有する場合、ロケーションB1における動きベクトル候補はマージ候補リストに挿入されない。ロケーションB0における動きベクトル候補が利用可能である場合、ロケーションB0における動きベクトル候補はマージ候補リストに追加される。ロケーションA0における動きベクトル候補が利用可能である場合、ロケーションA0における動きベクトル候補はマージ候補リストに追加される。ロケーションB2における動きベクトル候補が利用可能である場合、ロケーションB2における動きベクトル候補はマージ候補リストに追加される。
[0167]3D−HEVC奥行きコーディングにおける時間的マージ用候補に関する導出プロセスは、コロケートPUの動き情報が利用される、HEVCにおける時間的マージ用候補導出プロセスと同様である。しかしながら、3D−HEVC奥行きコーディングでは、0に固定する代わりに、上記で説明したように、時間的マージ用候補のターゲット参照ピクチャインデックスは変更され得る。
[0168]次に、3D−HEVC奥行きコーディングにおける結合双予測マージ用候補のための導出プロセスについて説明する。上記の2つのステップから導出された候補の総数が候補の最大の数未満である場合、l0CandIdxおよびl1CandIdxの仕様を除いて、HEVCにおいて定義されたものと同じプロセスが、実行される。combIdx、I0CandIdx、およびI1CandIdxの間の関係は、図12に示す表において定義されている。
[0169]3D−HEVC奥行きコーディングにおけるゼロ動きベクトルマージ用候補に関する導出プロセスは、HEVCにおいて定義された手順と同じである。
[0170]以下は、高度残差予測(ARP)のための例示的な技法を説明する。Part_2N×2N(たとえば、図5のN×N)に等しい分割モードを有するCUに適用されるARPが、JCT3V−D0177において提案されたように、第4回JCT3V会議において採用された。ZhangらによるJCT3V−D0177文書は、「CE4:Advanced residual prediction for multiview coding」と題する。JCT3V−D0177文書は、2014年8月22日現在、http://phenix.it−sudparis.eu/jct3v/doc_end_user/current_document.php?id=862から入手可能である。
[0171]図14はマルチビュービデオコーディングにおける高度残差予測(ARP)の予測構造を示す。図14に示すように、現在ブロック(「Curr」)140の予測において以下のブロックが呼び出される。視差ベクトル(DV)146によって導出される参照/ベースビュー144中の参照ブロック142は「Base」と標示される。現在ブロック140の(TMVと示される)(時間的)動きベクトル150によって導出される、現在ブロックCurr140と同じビュー(ビューVm)中のブロック148は、「CurrTRef」と標示される。現在ブロックの時間的動きベクトル(TMV)によって導出されるブロックBase142(ビューV0)と同じビュー中のブロック152は「BaseTRef」と標示される。参照ブロックBaseTRef152は、現在ブロックCurr140と比較して、TMV+DV154のベクトルを用いて識別される。
[0172]残差予測子はBaseTRef−Baseと示され、示されたピクセルアレイの各ピクセルに減算演算が適用される。重み付け係数「w」が残差予測子にさらに乗算され得る。したがって、現在ブロックCurrの最終的な予測子は、CurrTRef+w*(BaseTRef−Base)として示され得る。
[0173]上記の説明および図14では、単方向予測が適用されると仮定されることに留意されたい。ARPを双方向予測の事例に拡張するとき、上記のステップが各参照ピクチャリストに対して適用される。現在ブロックCurrが2つの参照ピクチャリストのうちの1つに関して(異なるビュー中の)ビュー間参照ピクチャを使用するとき、ARPプロセスは無効化される。
[0174]以下はARPにおける復号プロセスについて説明する。最初に、ビデオデコーダ30は、(たとえば、NBDV導出プロセスを使用して)ターゲット参照ビューを指す視差ベクトルを取得する。次いで、同じアクセスユニット内の参照ビューのピクチャ中で、ビデオデコーダ30は、視差ベクトルを使用して対応するブロックを位置特定する。
[0175]ビデオデコーダ30は、参照ブロックに関する動き情報を導出するために、現在ブロックの動き情報を再使用することができる。ビデオデコーダ30は、次いで、残差ブロックを導出するために、現在のブロックに対応するブロックベースの同じ動きベクトルと、導出された参照ピクチャとに関して動き補償を適用することができる。
[0176]図15は、現在ブロック160、参照ブロック162、ならびに動き補償ブロック164および166の間の例示的な関係を示す概念図である。現在ビュー(Vm)の参照ピクチャと同じPOC(ピクチャ順序カウント)値を有する参照ビュー(V0)中の参照ピクチャが、対応するブロック162の参照ピクチャとして選択される。ビデオエンコーダ20および/またはビデオデコーダ30は、重み付けされた残差ブロックを得るために、残差ブロックに重み係数を適用し、予測されたサンプルに重み付けされた残差ブロックの値を加算することができる。
[0177]以下は重み係数について説明する。3つの重み係数、すなわち、0、0.5、および1がARPにおいて使用される。現在CUに関する最小レートひずみコストをもたらす重み係数が最終重み係数として選択され、対応する重み係数インデックス(たとえば、それぞれ、重み係数0、1、ならびに0.5に対応する0、1、および2)がCUレベルで、ビットストリーム中で送信される。ARPの一例では、1つのCU中のすべてのPU予測は同じ重み係数を共有する。重み係数が0に等しいとき、現在CUのためにARPは使用されない。
[0178]以下は、ARPに関するいくつかのさらなる簡略化について説明する。第1に、動きベクトルスケーリングによる参照ピクチャ選択について説明する。第2に、補間フィルタについて説明する。
[0179]JCT3V−C0049における、動きベクトルスケーリングによる参照ピクチャ選択では、非ゼロ重み係数を用いてコーディングされた予測ユニットの参照ピクチャはブロックごとに異なり得る。ZhangらによるJCT3V−C0049文書は、「3D−CE4:Advanced residual prediction for multiview coding」と題する。JCT3V−C0049文書は、2013年9月23日現在、http://phenix.int−evry.fr/jct3v/doc_end_user/current_document.php?id=487から入手可能である。
[0180]したがって、参照ビューとは異なるピクチャが、対応するブロックの動き補償ブロック(たとえば、図14ではBaseTRef)を生成するためにアクセスされる必要があり得る。重み係数が0に等しくないとき、残差生成プロセスのために動き補償を実行する前に、固定ピクチャに対して現在PUの復号動きベクトルをスケーリングすることが提案されている。JCT3V−D0177で提案されるように、固定ピクチャは、それが同じビューからのものである場合、各参照ピクチャリストの第1の参照ピクチャとして定義される。復号動きベクトルが固定ピクチャを指さないとき、ビデオデコーダ30は、最初に、復号動きベクトルをスケーリングし、次いで、CurrTRefおよびBaseTRefを識別するために、スケーリングされた動きベクトルを使用することができる。ARPのために使用されるそのような参照ピクチャはターゲットARP参照ピクチャと呼ばれる。
[0181]JCT3V−C0049で説明するような補間フィルタでは、ビデオエンコーダ20および/またはビデオデコーダ30は、対応するブロックおよびその予測ブロックの補間プロセスの間、バイリニアフィルタ(bi-linear filter)を適用することができる。非ベースビュー中の現在PUの予測ブロックに関して、従来の8/4タップフィルタが適用され得る。JCT3V−D0177で提案されるような別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、ARPが適用されるとき、ブロックがベースビュー中にあるか、または非ベースビュー中にあるかにかかわらず、バイリニアフィルタリングを常に採用することができる。
[0182]本開示の1つまたは複数の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、NBDV導出プロセスから戻されたビュー順序インデックスを使用して、参照ビューを識別するように構成され得る。ARPのいくつかの例では、1つの参照ピクチャリスト中の1つのPUの参照ピクチャが現在ビューとは異なるビューからのものであるとき、ARPはこの参照ピクチャリストについて無効化される。
[0183]2013年6月27日に出願した米国仮出願第61/840,400号および2013年7月18日に出願した米国仮出願第61/847,942号に奥行きインターコーディングのためのいくつかの追加の技法が説明されている。これらの例では、奥行きピクチャをコーディングするとき、視差ベクトルは、現在ブロックの隣接サンプルから推定された奥行き値によって変換される。
[0184]ARPのための他の例では、たとえば、視差ベクトルによって識別されたベースビューの参照ブロックにアクセスすることによって、追加のマージ候補が導出され得る。
[0185]以下は、ビュー間動き予測のためにブロックを位置特定するための技法について説明する。3D−HEVCでは、2つの一般的なステップを使用して、参照4×4ブロックが識別される。第1のステップは、視差動きベクトルを用いて参照ビュー中のピクセルを識別することである。第2のステップは、(それぞれ、RefPicList0またはRefPicList1に対応する動き情報の一意のセットを有する)対応する4×4ブロックを取得し、マージ候補を作成するために、動き情報を利用することである。
[0186]参照ビュー中のピクセル(xRef,yRef)は次のように識別される。
式中、(xP,yP)は、現在PUの左上サンプルの座標であり、mvDispは視差ベクトルであり、nPSW×nPSHは現在PUのサイズであり、PicWidthInSamplesLおよびPicHeightInSamplesLは(現在ビューと同じ)参照ビュー中のピクチャの解像度を定義する。
[0187]以下は、サブPUレベルのビュー間動き予測について説明する。JCT3V−E0184では、IPMVCに関するサブPUレベルのビュー間動き予測方法、すなわち、参照ビュー中の参照ブロックから導出された候補を使用することが提案された。AnらによるJCT3V−E0184、「3D−CE3.h関連:Sub−PU level inter−view motion prediction」が、http://phenix.it−sudparis.eu/jct2/doc_end_user/current_document.php?id=1198から利用可能である。
[0188](たとえば、スキップ/マージモードに関するビュー間候補導出プロセスに対して)依存ビュー中の現在PUに関して、中央位置に関連付けられた参照ブロックの動き情報だけが使用されるビュー間動き予測の基本的な考えが上記で説明されている。しかしながら、現在PUは、参照ビュー中の(視差ベクトルによって識別された現在PUと同じサイズを有する)参照エリアに対応し得、参照エリアは豊富な(すなわち、動きベクトルに関するより多くの)動き情報を有し得る。
[0189]したがって、サブPUレベルのビュー間動き予測(SPIVMP)方法が提案される。図16は、サブ予測ユニット(PU)ビュー間動き予測を示す概念図である。図16に示すように、現在ビューV1中の現在PU170は、複数のサブPU(たとえば、4つのサブPU)に分割され得る。各サブPUに関する視差ベクトルは、参照ビューV0中の対応する参照ブロックを位置特定するために使用され得る。ビデオエンコーダ20および/またはビデオデコーダ30は、現在PU170の対応するサブPUとともに使用するために、参照ブロックの各々に関連付けられた動きベクトルを複写(すなわち、再使用)するように構成され得る。
[0190]一例では、時間的ビュー間マージ候補は次のように導出される。まず、割り当てられたサブPUサイズをN×Nによって示す。第1に、現在PUをより小さいサイズを有する複数のサブPUに分割する。現在PUのサイズをnPSW×nPSHによって示し、サブPUのサイズをnPSWsub×nPSHSubによって示す。
[0191]第2に、デフォルト動きベクトルtmvLXを(0,0)に設定し、各参照ピクチャリストに関して、参照インデックスrefLXを−1に設定する。ラスタ走査順序の各サブPUに関して、以下が適用される。以下によって、参照サンプルロケーション(xRefSub,yRefSub)を取得するために、DVを現在サブPUの中間位置に加算する。
現在サブPUに関する参照ブロックとして(xRefSub,yRefSub)をカバーする参照ビュー中のブロックが使用される。
[0192]識別された参照ブロックでは、その参照ブロックが時間的動きベクトルを使用してコーディングされる場合、以下が適用される。refL0とrefL1の両方が−1に等しく、現在サブPUがラスタ走査順序で第1のサブPUでない場合、参照ブロックの動き情報はすべての前のサブPUによって継承される。現在サブPUに関する候補動きパラメータとして、関連する動きパラメータが使用され得る。シンタックス要素tmvLXおよびrefLXが現在サブPUの動き情報に更新される。そうでなければ(たとえば、参照ブロックがイントラコード化される場合)、現在サブPUの動き情報はtmvLXおよびrefLXに設定される。異なるサブPUブロックサイズ、たとえば、4×4、8×8、および16×16が適用され得る。サブPUのサイズはVPS内でシグナリングされ得る。
[0193]以下は、奥行きコーディングのためのサブPUレベルの動きベクトル継承について説明する。1つのテクスチャビューから別のテクスチャビューへのサブPUレベルのビュー間動き予測に関する提案と同様に、2013年7月24日に出願した米国仮出願第61/858,089号は、1つのテクスチャビューから対応する奥行きビューにサブPUレベルの動き予測を適用する技法を提案した。すなわち、現在PUはいくつかのサブPUに分割され得、各サブPUは、動き補償のためにコロケートテクスチャブロックの動き情報を使用する。この場合、サブPUレベルのMVIがサポートされ、ビュー間動き予測によって使用される視差ベクトルは常にゼロになると見なされる。
[0194]3D−HEVCにおけるBVSPに関する現在の設計は、以下の問題を示す。AMPが使用され、現在PUサイズが4×16または16×4であり、PUが単方向予測されるとき、PU全体に関して1つの視差ベクトルを導出することによってBVSPが達成される。すなわち、PU中の各サブブロックは、参照ブロック合成および動き補償のために同じ視差ベクトルを使用する。したがって、すべてのサブブロックに関するブロック合成および動き補償のために同じ視差ベクトルを使用することの最適さはサブブロックのうちのいくつかに対してより低い可能性があるため、より大きいブロックサイズの場合、BVSPの効率はより低くなる可能性がある。
[0195]別の欠点として、現在PUが双方向予測されるとき、4×8および8×4に等しいブロックサイズでBVSPは有効にされる。しかしながら、HEVCでは、(16×4および4×16の動き補償は許可されるが)64ピクセルに満たないブロック(たとえば、4×8ブロックまたは8×4ブロック)に関する動き補償は許可されない。
[0196]これらの欠点に鑑みて、本開示は、BVSP動き補償サイズに重点を置いて、3D−HEVCにおけるビュー合成予測に関する技法を提案する。本開示の技法によれば、BVSPのために、各PUはサブブロックに分割され得、したがって、各サブブロックは、異なる視差動きベクトルに関連付けられ、別個に動き補償され得る。このようにして、AMPを用いて分割されたブロックに関するBVSPの精度は増大され得、コーディング効率が増大され得る。本開示の技法によれば、BVSPとともに使用するために利用可能なサブブロックのサイズは次のようにさらに定義され得る。
[0197]本開示の一例では、現在PUが16×4(または、4×16)であり、現在PUが単方向予測されるとき、ビデオエンコーダ20および/またはビデオデコーダ30は、現在PUの8×4(または、4×8)サブブロックにBVSP技法および動き補償技法を適用するように構成され得る。すなわち、BVSPサブ領域のサイズは8×4(または、4×8)である。サブブロックの各々に、奥行きブロックから変換された視差動きベクトルが割り当てられ得る。
[0198]図17は、AMPを使用するときの、本開示のBVSP技法および動き補償技法を示す概念図である。図17の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、現在PU250を4×16ブロックに非対称的に分割する。4×16分割は単なる一例であり、図17を参照して説明する本開示の技法は、16×4分割を含めて、他の非対称分割に適用され得ることに留意されたい。ビデオエンコーダ20および/またはビデオデコーダ30は、PU250を4×8サブブロック255および256に再分割するように構成され得る。
[0199]図17の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、BVSPを使用して、PU250を単方向予測するように構成される。この点について、ビデオエンコーダ20および/またはビデオデコーダ30は、たとえば、NBDV導出技法を使用して、PU250に関する視差ベクトルを導出するように構成され得る。たとえば、視差ベクトル261は隣接ブロック252から導出され得る。その場合、ビデオエンコーダ20および/またはビデオデコーダ30は、参照奥行きピクチャ中の対応する奥行きブロック260を位置特定するために、視差ベクトル261を再使用するように構成され得る。本開示の技法によれば、PU255に関して単一の視差動きベクトルを導出するために、奥行きブロック260全体を使用するのではなく、ビデオエンコーダ20および/またはビデオデコーダ30は、サブブロック255に関して奥行きブロック260の4×8サブブロック264から視差動きベクトルを導出し、サブブロック256に関して奥行きブロック26の4×8サブブロック262から視差動きベクトルを導出するように構成され得る。
[0200]その場合、ビデオエンコーダ20および/またはビデオデコーダ30は、refVIdxLXに等しいビュー順序を用いてビュー間参照ピクチャに対応する参照ピクチャで動き補償を実行するために、対応する導出された視差動きベクトルを使用して、サブブロック255および256の各々に関する参照ブロックを合成することができる。サブブロック255および256の各々に関して個々の視差動きベクトルを導出することによって、より正確な参照ビューが合成され得、対応する動き補償プロセスは増大されたコーディング利得を達成され得る。
[0201]本開示の別の例では、現在PUサイズが16×12(または、12×16)であり、現在PUが単一方向予測されているとき、ビデオエンコーダ20および/またはビデオデコーダ30は、現在PUを8×4(または、4×8)(BVSPサブ領域とも呼ばれる)サブブロックに分割し、BVSPを使用して、各サブブロックに関して視差動きベクトルを導出するように構成され得る。
[0202]別の例では、BVSサブ領域のサイズが16×12または12×16に割り当てられ得る。さらに別の例では、各16×12(または、12×16)サブブロックは、同じCU中の16×4(4×16)PUに隣接する1つの16×8(または、8×16)サブブロックおよび2つの8×4(または、4×8)サブブロックにさらに分割される。別の例では、16×8(または、8×16)サブブロックは、たとえば、対応する奥行きブロックの4つのコーナーに基づいて、2つの8×8サブ領域または4つの4×8(もしくは、8×4)サブ領域にさらに分割され得る。
[0203]本開示の別の例では、現在PUの高さと幅の両方が8以上であり、PUが双方向予測されるとき、ビデオエンコーダ20および/またはビデオデコーダ30は、BVSPサブ領域のサイズを、3D−HEVCに関する前の提案におけるように4×8または8×4の代わりに、8×8に設定するように構成される。別の例では、12×16または16×12に等しいサイズを有するPUに関して双予測的BVSPを使用する代わりに、単一予測的BVSPが適用され得る。この場合、動き補償サイズは、4×16または16×4にさらに設定され得る。別の例では、現在PUサイズが16×4または4×16であり、現在PUが双方向予測されるとき、BVSPサブ領域のサイズはPUサイズに等しく設定される。
[0204]サブPU動き予測は、以下の欠点を示す場合がある。このコンテキストで、サブPU動き予測は、上記で説明した、JCT3V−E0184で提案されたサブPU動き予測技法、ならびに、サブPU動き予測のテクスチャビューから奥行きビューへのMVIへの拡張を含み得る。
[0205]1つの欠点として、非対称動き分割(AMP)が有効にされ、現在PUサイズが、たとえば、4×16、16×4に等しく、VPS中でシグナリングされたサブPUブロックサイズが8×8に等しいとき、サブPU動き予測に関する前の提案に基づいて、そのようなPUは2つの4×8または8×4サブブロックに分割されることになる。各サブブロックに関して、参照ブロックからの動き情報が継承される。動き情報は、ビュー間動き予測のための参照テクスチャビュー中の視差ベクトルによって識別され得るか、または動きベクトル継承のための対応するテクスチャビュー中のコロケートテクスチャブロックから再使用され得る。この例では、HEVCによって許可されない、4×8または8×4ベースの双予測が呼び出される。
[0206]別の欠点として、AMPが有効にされ、PUサイズが、たとえば、12×16、16×12に等しく、VPS中でシグナリングされたサブPUブロックサイズ(すなわち、サブブロックサイズ)が8×8に等しいとき、サブPU動き予測に関する前の提案に基づいて、そのようなPUは2つの8×8サブブロックまたは2つの4×8/8×4サブブロックに分割されることになる。上述の事例と同様に、HEVCによって許可されない、4×8/8×4サブブロックは双予測を使用することができる。
[0207]ビュー間動き予測および(奥行きPUに関する)動きベクトル継承に関する技法が本開示で提案される。マージインデックスがビュー間動き予測またはMVIを示すコンテキストにおいて、本開示の技法が適用され得る。具体的には、本開示のビュー間動き予測技法および/またはMVI技法は、AMP PUをサブブロックにさらに分割し、サブブロックの各々に関して別個の動き情報を取得するための技法を含む。このようにして、サブブロックの各々に関して、ビュー間動き予測および/またはMVIの精度は改善され得、したがって、コーディング効率が増大され得る。
[0208]本開示の一例では、現在PUがビュー間動き予測および/またはMVIを使用してコーディングされ、現在PUサイズが4×16または16×4に等しいとき、ビデオエンコーダ20および/またはビデオデコーダ30は、PUを2つの4×8または8×4サブブロックに分割するように構成され得る。サブブロックの各々に関して、ビデオエンコーダ20および/またはビデオデコーダ30は、特定の参照ピクチャリスト(たとえば、RefPicList0)に対応する参照ブロックからの動き情報だけを取得するように構成され得る。4×8または8×4サブブロックに関して、RefPicList0中の参照ブロックに対応する動き情報が継承される。この場合、サブブロックは、RefPicList0中のピクチャから単方向予測される。
[0209]図18は、サイズ4×16および16×4に非対称的に分割されたPUに関する動きベクトル継承技法および動き補償技法を示す概念図である。たとえば、4×16PUでは、ビデオエンコーダ20および/またはビデオデコーダ30は、4×16PUを2つの4×8サブブロック300および302にさらに分割するように構成される。サブブロック300および302の各々に関する動き情報は、特定の参照ピクチャリスト(たとえば、RefPicList0)に属する参照ピクチャ中の参照ブロックから取得される。次いで、RefPicList0中の参照ブロックに対してサブブロック300および302の各々に関して動き補償が実行される。同様に、16×4PUの場合、ビデオエンコーダ20および/またはビデオデコーダ30は、16×4PUを2つの8×4サブブロック304および306にさらに分割するように構成される。サブブロック304および306の各々に関する動き情報は、特定の参照ピクチャリスト(たとえば、RefPicList0)に属する参照ピクチャ中の参照ブロックから取得される。次いで、RefPicList0中の参照ブロックに対してサブブロック304および306の各々に関して動き補償が実行される。
[0210]本開示の別の例では、現在PUサイズが16×12、12×16、4×16、または16×4のうちの1つであるとき、サブPUレベルのビュー間動き予測および/または(奥行きに関して)MVIが適用されるとき、ビデオエンコーダ20および/またはビデオデコーダ30は、8×4/4×8サブブロックに関して双予測を使用しないように構成される。すなわち、現在PUサイズが16×12、12×16、4×16、または16×4のうちの1つであるとき、サブPUレベルのビュー間動き予測および/または(奥行きに関して)MVIが適用されるとき、ビデオエンコーダ20および/またはビデオデコーダ30は、8×4/4×8サブブロックに関して単予測だけを使用するように構成される。
[0211]本開示の別の例では、サブPUレベルのビュー間動き予測またはMVIが適用され、現在PUサイズが4×16または16×4に等しいとき、PUはサブPUに分割されないことが提案される。
[0212]本開示の別の例では、サブPUレベルのビュー間動き予測またはMVIが適用され、現在PUサイズが12×16または16×12に等しいとき、PUは、4×16または16×4に等しいサイズを有する3つの等しくサイズ決定されたサブPUブロックに分割されることが提案される。各サブPUブロックに関して、対応する参照ブロックの動き情報が継承される。
[0213]本開示の別の例では、現在PUサイズが12×16または16×12に等しいとき、PUは2つの8×8サブPUブロックおよび1つの4×16または16×4サブPUブロックに分割され、ここにおいて、8×8サブPUは、このPUを含んでいるCUの左半分または上半分を形成する。この例の別の態様では、4×16および16×4サブブロックは、2つの4×8または8×4サブPUブロックにさらに分割される。各4×8または8×4サブPUに関して、参照ピクチャリスト(RefPicList0)に対応する参照ブロックの動き情報だけが取得され、4×8または8×4サブPUに関して再使用される。この場合、サブPUは、RefPicList0中のピクチャから単方向予測される。
[0214]本開示の別の例では、12×16または16×12に等しいサイズを有するPUに関してBVSPが使用されるとき、PUは、4×16または16×4に等しいサイズを有する3つの等しくサイズ決定されたサブPUに分割される。ビデオエンコーダ20および/またはビデオデコーダ30は、次いで、対応する奥行きブロックから各サブPUに関する一意の視差動きベクトルを導出することができる。
[0215]図19は、本開示の技法を実装し得る、ビデオエンコーダ20の例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス、たとえば、テクスチャ画像と奥行きマップの両方のスライス中のビデオブロックのイントラコーディングおよび(ビュー間コーディングを含む)インターコーディングを実行し得る。テクスチャ情報は、概して、ルミナンス(輝度または強度)情報とクロミナンス(色、たとえば、赤い色相および青い色相)情報とを含む。概して、ビデオエンコーダ20は、ルミナンススライスに対するコーディングモードを決定し、(たとえば、分割情報、イントラ予測モード選択、動きベクトルなどを再使用することによって)クロミナンス情報を符号化するために、ルミナンス情報をコーディングすることからの予測情報を再使用することができる。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接するフレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのいずれをも指すことができる。単一方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのいずれをも指すことができる。
[0216]図19に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム(たとえば、テクスチャ画像または奥行きマップ)内の現在ビデオブロック(すなわち、ルミナンスブロック、クロミナンスブロック、または奥行きブロックなどのビデオデータのブロック)を受信する。図19の例では、ビデオエンコーダ20は、ビデオデータメモリ40と、モード選択ユニット41と、復号ピクチャバッファ(DPB)64と、合計器50と、変換処理ユニット52と、量子化ユニット54と、ループフィルタユニット63と、エントロピー符号化ユニット56とを含む。モード選択ユニット41は、今度は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測処理ユニット46と、分割ユニット48とを含む。ビデオブロックの再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換処理ユニット60と、合計器62とを含む。ループフィルタユニット63は、再構築されたビデオからブロッキネスアーティファクト(blockiness artifacts)を除去する目的でブロック境界をフィルタリングするために、デブロッキングフィルタとSAOフィルタとを含み得る。追加のフィルタ(インループまたはポストループ)も、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔さのために図示されていないが、望まれる場合には、合計器50の出力を(インループフィルタとして)フィルタリングすることができる。
[0217]ビデオデータメモリ40は、ビデオエンコーダ20の構成要素によって符号化されるべきビデオデータを記憶することができる。ビデオデータメモリ40に記憶されるビデオデータは、たとえば、ビデオソース18から取得される場合がある。DPB64は、(たとえば、イントラ予測コーディングモードまたはインター予測コーディングモードとも呼ばれる、イントラコーディングモードまたはインターコーディングモードで)ビデオエンコーダ20によってビデオデータを符号化する際に使用する参照ビデオデータを記憶するバッファである。ビデオデータメモリ40およびDPB64は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗性RAM(RRAM(登録商標))、または他のタイプのメモリデバイスなど、様々なメモリデバイスのうちのいずれかによって形成され得る。ビデオデータメモリ40およびDPB64は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ40は、ビデオエンコーダ20の他の構成要素とともにオンチップであるか、またはそれらのような構成要素に対してオフチップであり得る。
[0218]符号化プロセス中に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間予測を行うために、ビュー間参照フレームを含む、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対して受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測処理ユニット46は、代替的に、空間的予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対して、受信されたビデオブロックのイントラ予測コーディングを実行することができる。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適当なコーディングモードを選択するために、複数のコーディングパスを実行することができる。
[0219]さらに、分割ユニット48は、前のコーディングパス内の前の分割方式の評価に基づいて、ビデオデータのブロックをサブブロックに分割することができる。たとえば、分割ユニット48は、最初に、フレームまたはスライスをLCUに分割し、レートひずみ分析(たとえば、レートひずみ最適化)に基づいて、LCUの各々をサブCUに分割することができる。モード選択ユニット41は、サブCUへのLCUの分割を示す四分木データ構造をさらに生成することができる。四分木の葉ノードCUは、1つまたは複数のPUと1つまたは複数のTUとを含み得る。
[0220]モード選択ユニット41は、たとえば誤差結果に基づいて、コーディングモードのうちの1つ、すなわち、イントラまたはインターを選択することができ、結果のイントラコーディングされたブロックまたはインターコーディングされたブロックを、残差ブロックデータを生成するために合計器50に、参照フレームとしての使用のために符号化されたブロックを再構成するために合計器62に供給する。モード選択ユニット41はまた、動きベクトル、イントラモードインジケータ、分割情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット56に提供する。
[0221]動き推定ユニット42および動き補償ユニット44は、高度に一体化され得るが、概念上の目的から別々に示されている。動き推定ユニット42によって実行される動き推定は、ビデオブロックに関する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム(または他のコーディングされたユニット)内でコーディングされている現在ブロックに対する参照フレーム(または他のコーディングされたユニット)内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示すことができる。
[0222]予測ブロックは、絶対差の合計(SAD:sum of absolute difference)、二乗差の合計(SSD:sum of square difference)、または他の差メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックとぴったりと一致することが見出されたブロックである。いくつかの例では、ビデオエンコーダ20は、DPB64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算することができる。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数のピクセル位置の値を補間することができる。したがって、動き推定ユニット42は、完全なピクセル位置および分数のピクセル位置に関して動き探索を実行し、分数のピクセル精度で動きベクトルを出力することができる。
[0223]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのPUに関する動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの参照ピクチャリストの各々は、DPB64に記憶された1つまたは複数の参照ピクチャを識別する。参照ピクチャリストは、本開示の技法を使用して構築され得る。動き推定ユニット42は、計算された動きベクトルを、エントロピー符号化ユニット56および動き補償ユニット44に送る。
[0224]動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて、予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット42と動き補償ユニット44とは機能的に統合され得る。現在のビデオブロックに関するPUの動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つの中で動きベクトルが指す予測ブロックを位置特定することができる。合計器50は、下で論じるように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット42は、ルーマ成分に対して相対的に動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分の両方に関して、ルーマ成分に基づいて計算された動きベクトルを使用する。このように、動き補償ユニット44は、動き推定ユニット42がクロマ成分に関する動き探索を実行する必要がないように、クロマ成分をコーディングするためにルーマ成分に関して決定された動き情報を再使用することができる。モード選択ユニット41はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連付けられたシンタックス要素を生成することができる。
[0225]イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実行されるインター予測の代替として、現在ブロックをイントラ予測することができる。特に、イントラ予測処理ユニット46は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化することができ、イントラ予測処理ユニット46(または、いくつかの例では、モード選択ユニット41)は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。
[0226]たとえば、イントラ予測処理ユニット46は、様々なテストされたイントラ予測モードにレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択することができる。レートひずみ分析は、一般に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または、誤差)の量、ならびに符号化されたブロックを生成するために使用されたビットレート(すなわち、ビットの個数)を決定する。イントラ予測処理ユニット46は、符号化された様々なブロックのひずみおよびレートから比を算出し、どのイントラ予測モードがブロックの最良のレートひずみ値を示すのかを決定し得る。
[0227]ブロックに関するイントラ予測モードを選択した後、イントラ予測処理ユニット46は、ブロックに関して選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供することができる。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび(符号語マッピングテーブルとも呼ばれる)複数の修正されたイントラ予測モードインデックステーブルと、様々なブロックに関する符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および修正されたイントラ予測モードインデックステーブルの指示とを含み得る構成データを、送信されるビットストリーム中に含め得る。
[0228]ビデオエンコーダ20は、モード選択ユニット41からの予測データを、コーディングされている元のビデオブロックから減算することによって、残差ビデオブロックを形成する。合計器50は、この減算演算を実行する、1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似する変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTに概念的に類似する他の変換を実行することができる。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も使用され得る。いずれの場合でも、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。
[0229]変換は、ピクセル値領域からの残差情報を、周波数領域のような変換領域に変換することができる。変換処理ユニット52は、得られた変換係数を量子化ユニット54へ送ることができる。量子化ユニット54は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数の一部またはすべてに関連付けられたビット奥行きを低減させることができる。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は、次いで、量子化された変換係数を含む行列の走査を実行することができる。代替的に、エントロピー符号化ユニット56が走査を実行することができる。
[0230]量子化の後、エントロピー符号化ユニット56は、量子化された変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応可変長コーディング(CAVLC)、コンテキスト適応2進算術コーディング(CABAC)、構文ベースコンテキスト適応2進算術コーディング(SBAC)、確率区間分割エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行することができる。コンテキストベースのエントロピーコーディングの場合、コンテキストは、隣接ブロックに基づくものとされ得る。エントロピー符号化ユニット56によるエントロピーコーディングの後、符号化されたビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、または後の送信もしくは取出のためにアーカイブされ得る。
[0231]逆量子化ユニット58および逆変換処理ユニット60は、たとえば、参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構築するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット44は、残差ブロックをDPB64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44は、動き推定での使用のためにサブ整数ピクセル値を計算するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用することもできる。合計器62は、DPB64に記憶するための再構成されたビデオブロックを生成するために、再構築された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算する。再構築されたビデオブロックは、後続ビデオフレーム中のブロックをインターコーディングするための参照ブロックとして、動き推定ユニット42と動き補償ユニット44とによって使用され得る。
[0232]ビデオエンコーダ20は、対応するクロミナンス成分がなくとも、ルミナンス成分をコーディングするためのコーディング技法に実質的に似るように奥行きマップを符号化することができる。たとえば、イントラ予測処理ユニット46は、奥行きマップのブロックをイントラ予測し得るが、動き推定ユニット42および動き補償ユニット44は、奥行きマップのブロックをインター予測し得る。しかしながら、上記で論じたように、奥行きマップのインター予測中、動き補償ユニット44は、奥行き範囲内の差分と、奥行き範囲に関する精度値とに基づいて、参照奥行きマップの値をスケーリング(すなわち、調整)することができる。たとえば、現在奥行きマップ中および参照奥行きマップ中の異なる最大奥行き値が同じ実世界奥行きに対応し得る場合、ビデオエンコーダ20は、予測のために、現在奥行きマップ中の最大奥行き値に等しいように、参照奥行きマップの最大奥行き値をスケーリングすることができる。追加または代替として、ビデオエンコーダ20は、たとえば、ビュー間予測に実質的に類似した技法を使用して、ビュー合成予測のためのビュー合成ピクチャを生成するために、更新された奥行き範囲値と精度値とを使用することができる。
[0233]図21〜図23を参照して下記でより詳細に説明するように、ビデオエンコーダ20は、上記で説明した本開示の技法を採用するように構成され得る。具体的には、ビデオエンコーダ20は、PUが非対称分割モードに従って分割されるとき、そのようなPUをサブブロックに分割するように構成され得る。ビデオエンコーダ20は、サブブロックの各々に関する動きベクトルもしくは視差動きベクトルを継承および/または導出するように構成され得る。
[0234]図20は、本開示の技法を実装し得るビデオデコーダ30の例を示すブロック図である。図20の例では、ビデオデコーダ30は、ビデオデータメモリ79と、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測処理ユニット74と、逆量子化ユニット76と、逆変換処理ユニット78と、復号ピクチャバッファ(DPB)82と、ループフィルタユニット83と、合計器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図19)に関して説明された符号化パスとは概して逆の復号パスを実行することができる。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得るのに対して、イントラ予測処理ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
[0235]ビデオデータメモリ79は、ビデオデコーダ30の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶することができる。ビデオデータメモリ79に記憶されたビデオデータは、カメラなどのローカルビデオソースから、ビデオデータのワイヤードもしくはワイヤレスのネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ79は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ(CPB)を形成し得る。DPB82は、(たとえば、イントラ予測コーディングモードまたはインター予測コーディングモードとも呼ばれる、イントラコーディングモードまたはインターコーディングモードで)ビデオデコーダ30によってビデオデータを復号する際に使用する参照ビデオデータを記憶するDPBの一例である。ビデオデータメモリ79およびDPB82は、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗性RAM(RRAM)、または他のタイプのメモリデバイスなど、様々なメモリデバイスのうちのいずれかによって形成され得る。ビデオデータメモリ79およびDPB82は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ79は、ビデオデコーダ30の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
[0236]復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと、関連付けられるシンタックス要素とを表す、符号化ビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット70は、動きベクトルと他のシンタックス要素とを動き補償ユニット72へ転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでのシンタックス要素を受信し得る。
[0237]ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測処理ユニット74は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックに関する予測データを生成することができる。ビデオフレームがインターコード化(すなわち、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在ビデオスライスのビデオブロックに関する予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、復号ピクチャバッファ82に記憶された参照ピクチャに基づいて、本開示の技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構築することができる。動き補償ユニット72は、動きベクトルと他のシンタックス要素とを解析することによって現在ビデオスライスのビデオブロックに関する予測情報を決定し、復号されている現在ビデオブロックに関する予測ブロックを生成するために、その予測情報を使用する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラまたはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスに関する参照ピクチャリストのうちの1つまたは複数に関する構成情報と、スライスの各インター符号化ビデオブロックに関する動きベクトルと、スライスの各インターコード化ビデオブロックに関するインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のうちのいくつかを使用する。
[0238]動き補償ユニット72はまた、補間フィルタに基づいて、補間を実行することができる。動き補償ユニット72は、参照ブロックのサブ整数ピクセルに関して補間された値を計算するために、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用することができる。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを決定し、予測ブロックを生成するために補間フィルタを使用することができる。
[0239]逆量子化ユニット76は、ビットストリーム中で提供され、エントロピー復号ユニット70によって復号された、量子化変換係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中の各ビデオブロックに関してビデオデコーダ30によって計算される量子化パラメータQPYの使用を含み得る。
[0240]逆変換処理ユニット78は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
[0241]動き補償ユニット72が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックに関する予測ブロックを生成した後、ビデオデコーダ30は、逆変換処理ユニット78からの残差ブロックを動き補償ユニット72によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。合計器90は、この加算演算を実行する1つまたは複数の構成要素を表す。ループフィルタユニット63は、再構築されたビデオからブロッキネスアーティファクトを除去する目的でブロック境界をフィルタリングするために、デブロッキングフィルタとSAOフィルタとを含み得る。追加のフィルタ(インループまたはポストループ)も、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔さのために示されていないが、望まれる場合には、合計器80の出力を(インループフィルタとして)フィルタリングすることができる。所与のフレームまたはピクチャ中の復号ビデオブロックは、次いで、後続の動き補償のために使用される参照ピクチャを記憶する復号ピクチャバッファ82に記憶される。復号ピクチャバッファ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上での後の表示のために、復号ビデオを記憶する。
[0242]図24〜図26を参照して下記でより詳細に説明するように、ビデオデコーダ30は、上記で説明した本開示の技法を採用するように構成され得る。具体的には、ビデオデコーダ30は、PUが非対称分割モードに従って分割されるとき、そのようなPUをサブブロックに分割するように構成され得る。その場合、ビデオデコーダ30は、サブブロックの各々に関する動きベクトルもしくは視差動きベクトルを継承および/または導出するように構成され得る。
[0243]図21は、本開示の例示的な符号化方法を示すフローチャートである。図21の技法は、モード選択ユニット41、分割ユニット48、および/または動き補償ユニット44によってなど、ビデオエンコーダ20の1つもしくは複数の構造ユニットによって実装され得る。
[0244]本開示の一例では、(たとえば、モード選択ユニット41と分割ユニット48とを使用して)ビデオエンコーダ20は、AMPを使用してビデオデータのブロックを生成すること、ここにおいて、ビデオデータのブロックが、BVSPを使用して単方向予測され、16×12、12×16、16×4、または4×16のサイズを有する、を行うように構成され得る(2100)。本開示の一例では、ビデオデータのブロックは予測ユニットである。
[0245]ビデオエンコーダ20は、分割ユニット48を使用して、ビデオデータのブロックを、各々が8×4または4×8のサイズを有するサブブロックに分割することと(2110)、(たとえば、動き補償ユニット44を使用して)、参照ピクチャに対応する奥行きピクチャ中の対応する奥行きブロックからサブブロックの各々に関するそれぞれの視差動きベクトルを導出することと(2120)を行うようにさらに構成され得る。(たとえば、動き補償ユニット44を使用して)ビデオエンコーダ20は、それぞれの導出された視差動きベクトルを使用して、サブブロックの各々に関するそれぞれの参照ブロックを合成することと(2130)、(たとえば、動き補償ユニット44を使用して)合成されたそれぞれの参照ブロックを使用して、サブブロックの各々に関して動き補償を実行することによって、ビデオデータのブロックを符号化することと(2140)を行うようにさらに構成され得る。
[0246]本開示の別の例では、ビデオエンコーダ20は、予測ユニットがAMPを使用して符号化されていることを示し、予測ユニットがBVSPを使用して単方向予測されていることを示す、1つまたは複数のシンタックス要素を生成することと、BVSP候補を指すマージ候補インデックスを生成することとを行うようにさらに構成され得る。
[0247]本開示の別の例では、(たとえば、動き補償ユニット44を使用して)ビデオエンコーダ20は、ビデオデータのブロックに関する視差ベクトルを導出し、導出された視差ベクトルを使用して、サブブロックの各々に関する、対応する奥行きブロックを位置特定し、サブブロックの各々に関する、対応する奥行きブロックの1つの選択された奥行き値をそれぞれの視差動きベクトルに変換することによって、サブブロックの各々に関するそれぞれの視差動きベクトルを導出するように構成され得る。
[0248]図22は、本開示の別の例示的な符号化方法を示すフローチャートである。図22の技法は、モード選択ユニット41、分割ユニット48、および/または動き補償ユニット44を含む、ビデオエンコーダ20の1つもしくは複数の構造ユニットによって実装され得る。
[0249]本開示の一例では、(たとえば、モード選択ユニット41と分割ユニット48とを使用して)ビデオエンコーダ20は、AMPを使用してビデオデータの第2のブロックを生成すること、ここにおいて、ビデオデータの第2のブロックが、ビュー間動き予測またはMVIのうちの少なくとも1つを使用して符号化され、16×4または4×16のサイズを有する(2200)、を行うように構成され得る。(たとえば、分割ユニット48を使用して)ビデオエンコーダ20は、ビデオデータの第2のブロックを、各々が8×4または4×8のサイズを有するサブブロックに分割することと(2210)、(たとえば、動き補償ユニット44を使用して)、1つのそれぞれの参照ブロックからサブブロックの各々に関する動き情報を導出することと(2220)を行うようにさらに構成され得る。ビデオエンコーダ20は、次いで、導出された動き情報と1つの参照ピクチャリストとを使用して、サブブロックの各々に関して動き補償を実行することによって、ビデオデータの第2のブロックを符号化することができる(2230)。
[0250]本開示の別の例では、(たとえば、動き補償ユニット44を使用して)ビデオエンコーダ20は、1つの参照ピクチャリスト中のピクチャに対して単方向動き補償を実行することによって、動き補償を実行するように構成され得る。
[0251]図23は、本開示の別の例示的な符号化方法を示すフローチャートである。図23の技法は、モード選択ユニット41、分割ユニット48、および/または動き補償ユニット44によってなど、ビデオエンコーダ20の1つもしくは複数の構造ユニットによって実装され得る。
[0252]本開示の一例では、ビデオエンコーダ20は、(たとえば、モード選択ユニット41と分割ユニット48とを使用して)AMPを使用してビデオデータの第2のブロックを生成することと、ここにおいて、ビデオデータの第2のブロックが、ビュー間動き予測または動きベクトル継承のうちの少なくとも1つを使用して符号化され、サイズ16×12または12×16を有する(2300)、(たとえば、分割ユニット48を使用して)ビデオデータの第2のブロックを複数のサブブロックに分割することと(2310)、(たとえば、動き補償ユニット44を使用して)単予測的予測を用いて複数のサブブロックの各々を符号化することと(2320)を行うように構成され得る。
[0253]図24は、本開示の例示的な復号方法を示すフローチャートである。図24の技法は、動き補償ユニット72によってなど、ビデオデコーダ30の1つまたは複数の構造ユニットによって実装され得る。
[0254]本開示の一例では、ビデオデコーダ30は、ビデオデータのブロックに対応する残差データを受信すること、ここにおいて、ビデオデータのブロックが、AMPを使用して符号化され、BVSPを使用して単方向予測され、16×12、12×16、16×4、または4×16のサイズを有する、を行うように構成され得る(2400)。本開示の一例では、ビデオデータのブロックは予測ユニットである。ビデオデコーダ30は、ビデオデータのブロックを、各々が8×4または4×8のサイズを有するサブブロックに分割することと(2410)、参照ピクチャに対応する奥行きピクチャ中の対応する奥行きブロックからサブブロックの各々に関するそれぞれの視差動きベクトルを導出することと(2420)を行うようにさらに構成され得る。
[0255]ビデオデコーダ30は、それぞれの導出された視差動きベクトルを使用して、サブブロックの各々に関するそれぞれの参照ブロックを合成することと(2430)、残差データと、合成されたそれぞれの参照ブロックとを使用して、サブブロックの各々に関して動き補償を実行することによって、ビデオデータのブロックを復号することと(2440)を行うようにさらに構成され得る。
[0256]本開示の別の例では、ビデオデコーダ30は、予測ユニットが非対称動き分割を使用して符号化されていることを示し、予測ユニットが後方ビュー合成予測を使用して単方向予測されていることを示す、1つまたは複数のシンタックス要素を受信することと、BVSP候補を指すマージ候補インデックスを受信することとを行うようにさらに構成され得る。
[0257]本開示の別の例では、ビデオデコーダ30は、ビデオデータのブロックに関する視差ベクトルを導出し、導出された視差ベクトルを使用して、サブブロックの各々に関する、対応する奥行きブロックを位置特定し、サブブロックの各々に関する、対応する奥行きブロックの1つの選択された奥行き値をそれぞれの視差動きベクトルに変換することによって、サブブロックの各々に関するそれぞれの視差動きベクトルを導出するようにさらに構成され得る。
[0258]図25は、本開示の例示的な復号方法を示すフローチャートである。図23の技法は、動き補償ユニット72によってなど、ビデオデコーダ30の1つまたは複数の構造ユニットによって実装され得る。
[0259]本開示の一例では、ビデオデコーダ30は、ビデオデータの第2のブロックに対応する残差データを受信することと、ここにおいて、ビデオデータの第2のブロックが、ビュー間動き予測またはMVIのうちの少なくとも1つを使用して符号化され、16×4または4×16のサイズを有する(2500)、ビデオデータの第2のブロックを、各々が8×4または4×8のサイズを有するサブブロックに分割することと(2510)、1つのそれぞれの参照ブロックからサブブロックの各々に関する動き情報を導出することと(2520)、残差データと、導出された動き情報と、1つの参照ピクチャリストとを使用して、サブブロックの各々に関して動き補償を実行することによって、ビデオデータの第2のブロックを復号することとを行うように構成され得る。
[0260]本開示の別の例では、ビデオデコーダ30は、1つの参照ピクチャリスト中のピクチャに対して単方向動き補償を実行することによって、動き補償を実行するようにさらに構成され得る。
[0261]図26は、本開示の例示的な復号方法を示すフローチャートである。図23の技法は、動き補償ユニット72を含む、ビデオデコーダ30の1つまたは複数の構造ユニットによって実装され得る。
[0262]本開示の一例では、ビデオデコーダ30は、ビデオデータの第2のブロックに対応する残差データを受信することと、ここにおいて、ビデオデータの第2のブロックが、ビュー間動き予測またはMVIのうちの少なくとも1つを使用して符号化され、16×12または12×16のサイズを有する(2600)、ビデオデータの第2のブロックを複数のサブブロックに分割することと(2610)、単予測的予測を用いて複数のサブブロックの各々を復号することとを行うようにさらに構成され得る。
[0263]上記で説明したように、本開示の技法は、ビデオデータのブロックに関してAMP、BVSP、ビュー間動き予測、および/またはMVIを適用するときのビデオの符号化技法ならびに復号技法を含む。具体的には、本開示の技法は、PUのサブブロックがAMPを用いて分割されるためのコーディング技法を導くことによって、より正確なコーディングを実現する。たとえば、AMPを用いて分割されたPUがBVSPを使用してコーディングされるとき、そのようなPUのサブブロックに関する別個の視差動きベクトルを取得することは、ビュー合成および動き予測の精度、ならびに、したがって、コーディング効率を増大し得る。別の例として、AMPを用いて分割されたPUがビュー間動き予測および/またはMVIを使用してコーディングされるとき、そのようなPUのサブブロックに関する別個の動き情報を取得することは、動き予測の精度、および、したがって、コーディング効率を増大し得る。
[0264]例によっては、本明細書で説明された技法のうちのいずれかの、いくつかの動作またはイベントは、異なる順序で実行され得、追加、統合、または完全に除外され得る(たとえば、すべての説明した動作またはイベントが、本技法の実施のために必要であるとは限らない)ことを認識されたい。さらに、いくつかの例では、動作またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。
[0265]1つまたは複数の例において、前述の機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実施される場合、機能は、コンピュータ可読媒体上の1つもしくは複数の命令またはコード上に記憶され、あるいはこれを介して伝送され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従う、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的である有形のコンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示で説明した技法の実施のために命令、コード、および/またはデータ構造を取り出すため、に1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の使用可能な媒体とされ得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0266]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、任意の接続が、コンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、ウェブサイト、サーバ、または他の遠隔ソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、マイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含むのではなく、非一時的な有形の記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびblu−ray(登録商標)ディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲の中に含まれるべきである。
[0267]命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPGA)、または他の同等の統合された、あるいは個別の論理回路など、1つもしくは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明した技法の実装に適切な任意の他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアモジュールならびに/またはソフトウェアモジュール内に提供されるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つもしくは複数の回路または論理要素で十分に実装され得る。
[0268]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)もしくはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置で実装され得る。様々なコンポーネント、モジュール、またはユニットは、開示されている技術を実行するように構成されたデバイスの機能的態様を強調するように本開示において説明されているが、異なるハードウェアユニットによる実現を必ずしも必要としない。そうではなく、上記で説明したように、様々なユニットは、コーデックハードウェアユニット中で組み合わせられるか、または上記で説明した1つもしくは複数のプロセッサを含む、適切なソフトウェアおよび/あるいはファームウェアとともに相互動作可能なハードウェアユニットの集合によって提供され得る。
[0269]様々な例が、説明された。これらおよび他の例は、以下の特許請求の範囲に含まれる。