JP2019534600A - 適応型イントラ最確モードを用いた全方位映像符号化のための方法および装置 - Google Patents

Abstract

全方位映像において、いくつかのイントラ予測方向のみがイントラ予測に関係し得る。たとえば、エクイレクタングラーマッピングから生成された映像の場合、水平方向のみが、極周囲のイントラ予測に関係し得る。圧縮効率を高めるために、フレーム内の符号化または復号されるブロックの位置に基づいて、可能な方向の数を低減することが提案される。様々な実施形態において、ジオメトリ歪みに依存するイントラ方向の減少を考慮に入れるために、ＭＰＭの導出が適合され得る。符号化方法は、全方位映像におけるブロックを見積もるためのモードの数を低減するためにも適合され得る。また、イントラ方向を表すシンタックス要素の符号化も改善され得る。【選択図】図１９Ａ−１９Ｂ−１９Ｃ−１９Ｄ

Description

本発明の実施形態は、一般に、映像符号化および復号のための方法および装置に関し、より具体的には、適応型イントラ最確モードによる映像符号化および復号のための方法および装置に関する。

昨今、利用可能な大視野コンテンツ（最大３６０°）は増加している。そのようなコンテンツは、たとえば頭部搭載型ディスプレイ（ＨＭＤ）、スマートグラス、ＰＣスクリーン、タブレット、スマートフォンなどの没入型表示デバイスにおいてコンテンツを視聴するユーザによって完全に可視ではない可能性がある。すなわち、所与の瞬間に、ユーザはコンテンツの一部しか見ていないことがある。しかし、ユーザは一般に、たとえば頭部運動、マウス運動、タッチスクリーン、音声などの様々な手段によってコンテンツ内で操縦することができる。一般に、このコンテンツを符号化および復号することが望ましい。

本原理の一般態様によると、映像データを符号化する方法は、ピクチャのブロックにアクセスすることと、ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定することであって、セット内の利用可能なイントラ予測モードの数は、ブロックの位置に基づくことと、決定されたイントラ予測モードを用いて、ブロックを符号化することとを備える。

本原理の他の態様によると、映像データを復号する方法は、ピクチャのブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定することであって、セット内の利用可能なイントラ予測モードの数は、ブロックの位置に基づくことと、決定されたイントラ予測モードを用いて、ブロックを復号することとを備える。

本原理の他の態様によると、映像データを符号化するための装置は、少なくとも１つのメモリと、１または複数のプロセッサとを備え、１または複数のプロセッサは、ピクチャのブロックにアクセスし、ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定し、ここで、セット内の利用可能なイントラ予測モードの数はブロックの位置に基づき、決定されたイントラ予測モードを用いて、ブロックを符号化するように構成される。

本原理の他の態様によると、映像データを復号するための装置は、少なくとも１つのメモリと、１または複数のプロセッサとを備え、１または複数のプロセッサは、ピクチャのブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定し、ここで、セット内の利用可能なイントラ予測モードの数はブロックの位置に基づき、決定されたイントラ予測モードを用いて、ブロックを復号するように構成される。

本原理の他の態様によると、ビットストリームは、ピクチャのブロックを表現する符号化データと、ブロックに関する利用可能なイントラ予測モードのセットのうちのイントラ予測モードを表現する符号化データとを含むようにフォーマット化され、セット内の利用可能なイントラ予測モードの数は、ブロックの位置に基づき、ブロックは、イントラ予測モードを用いて符号化される。

セット内の利用可能なイントラ予測モードの数は、ブロックの垂直位置に依存してよい。１つの実施形態において、ブロックが第２のブロックよりもピクチャの中心から垂直方向に離れている場合、そのブロックに関する利用可能なイントラ予測モードの数は、第２のブロックに関する利用可能なイントラ予測モードの数よりも小さい。

利用可能なイントラ予測モードにおける２つの隣接するイントラ予測モード間の角度差は、ブロックの位置に基づいてよい。

実施形態によると、ブロックに関する第１の最確モードは、隣接ブロックのイントラ予測モードに基づいて導出され得る。ブロックに関する第２の最確モードは、第１の最確モードに基づいて導出されてよく、第１の最確モードと第２の最確モードとの間の角度差は、ブロックの位置に基づく。ブロックに関するイントラ予測モードは、第１の最確モードおよび第２の最確モードの１つであるように選択され得る。

ブロックのイントラ予測モードが最確モードの１つである場合、ブロックに関してＭＰＭインデックスが符号化される。そうでない場合、ブロックのイントラ予測モードは、固定長コードを用いて符号化されてよく、固定長コードの長さは、セット内の利用可能なイントラ予測モードの数に基づく。セット内の利用可能なイントラ予測モードの数がブロックの垂直位置に基づく場合、固定長コードの長さは、ブロックの垂直位置に依存する。ブロックの垂直位置は、たとえばブロックの中心または角など、ブロック上の点の位置として決定され得る。

ピクチャ内に第１のブロックおよび第２のブロックがあり、第１のブロックに関する利用可能なイントラ予測モードの第１のセットが、第２のブロックに関する利用可能なイントラ予測モードの第２のセットとは異なる場合、利用可能なイントラ予測モードの第１のセットにおける２つの隣接するイントラ予測モード間の第１の角度差は、利用可能なイントラ予測モードの第２のセットにおける２つの隣接するイントラ予測モード間の第２の角度差と同じであってよい。

ピクチャ内に第１のブロックおよび第２のブロックがあり、第１のブロックに関する利用可能なイントラ予測モードの第１のセットが、利用可能なイントラ予測モードの第２のセットとは異なる場合、第１のブロックに関する利用可能なイントラ予測モードの第１のセットは、連続したイントラ予測モードインデックスの第１のセットによって表されてよく、第２のブロックに関する利用可能なイントラ予測モードの第２のセットもまた、連続したイントラ予測モードインデックスの第２のセットによって表され得る。１つの実施形態において、利用可能なイントラ予測モードの第１のセットおよび利用可能なイントラ予測モードの第２のセットにおける同じイントラ予測モードインデックスは、同じイントラ予測モードに対応する。

ブロックに関するセット内の利用可能なイントラ予測モードの数をブロックの位置に関連付けるためにルックアップテーブルが用いられ得る。ルックアップテーブルの使用は、上記プロセスを簡略化および迅速化させ得る。

ブロックに関するセット内の利用可能なイントラ予測モードの数は、ビットストリームにおいて示され得る。したがって、デコーダは、ブロックに関するセット内の利用可能なイントラ予測モードの数をビットストリームから直接得ることができ、デコーダ側で数を計算する必要がない。

本実施形態は、上述した方法に従って映像データを符号化または復号するための装置も提供する。本実施形態は、上述した方法に従って生成されたビットストリームを伝送するための装置も提供する。

本実施形態は、上述した方法に従って映像データを符号化または復号するための命令が格納されたコンピュータ可読記憶媒体も提供する。本実施形態は、上述した方法に従って生成されたビットストリームが格納されたコンピュータ可読記憶媒体も提供する。

本原理の実施形態に係る、全方位映像を符号化および復号するための典型的なシステムを示す。 図２Ａは、エクイレクタングラー投影を用いて典型的な球体表面Ｓが２ＤフレームＦにマッピングされることを示し、図２Ｂは、キューブマッピングを用いて典型的なキューブ表面が図２Ｃに示すような２Ｄフレームにマッピングされることを示す。 典型的な逆エクイレクタングラーマッピングを示す。 図４Ａは、３Ｄ表面からレンダリングされたフレームＧへ点が投影されることを示し、図４Ｂは、投影の近似を示す。 典型的なＨＥＶＣ映像エンコーダのブロック図を示す。 図６Ａは、ＨＥＶＣにおいて利用可能な３５のイントラ予測モードのセットを示し、図６Ｂは、ａｎｇｕｌａｒ予測モードによって示された方向に沿って参照サンプルがコピーされることを示す。 典型的なＨＥＶＣ映像デコーダのブロック図を示す。 レンダリングされたフレームにおける直線が、符号化されるフレームにおいて直線に見えない例を示す。 本原理の典型的な実施形態に係る、イントラ予測モードを符号化または復号するためのＭＰＭリストを適合させるための典型的な方法を示す。 図１０Ａは、ｘ‐ｙ座標系における正規化２Ｄフレームを示し、図１０Ｂは、エクイレクタングラーマッピングに関する典型的なワーピングインデックス演繹を示す。 図１１Ａは、本原理の実施形態に係る、変換「Ｔ」を計算するための典型的なワークフローを示し、図１１Ｂは、本原理の実施形態に係る、変換「Ｔ」を計算するための典型的なワークフローを示す。 本原理の実施形態に係る、エクイレクタングラーマッピングが用いられる場合、隣接する左のブロックに基づいてＭＰＭを得るための典型的なプロセスを示す。 隣接する左のブロックＬも赤道上にある、赤道上の典型的な現在のブロックＣを示す。 図１４Ａは、キューブマッピングの例を示し、図１４Ｂは、エッジにおける方向変化の例を示す。 全方位ピクチャの典型的なエクイレクタングラーレイアウト、および垂直座標に沿った参照のローカルフレームの展開を示す。 エクイレクタングラー映像の場合における、Ｙ軸に沿った様々な位置からの典型的な方向変形を示す。 ＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ）のｊｏｉｎｔ ｅｘｐｌｏｒａｔｉｏｎソフトウェア（ＪＥＭ）におけるイントラ方向モードを示す。 本原理の典型的な実施形態に係る、水平線の上下の利用可能なイントラ予測モードの数を示す。 本原理の典型的な実施形態に係る、ａ＝１、０．５、０．２５、および０．１２５に関して利用可能なイントラ予測モードを計算するための例を提供する。 本原理の典型的な実施形態に係る、方向のグループ分けおよびイントラ方向の再順序付けの例を示す。 図２１Ａは、本原理の実施形態に係る、ＭＰＭリストを用いて現在のブロックに関するイントラ予測モードを符号化または復号するための典型的な方法を示し、図２１Ｂは、本原理の実施形態に係る、固定長コードを用いて現在のブロックに関するイントラ予測モードを符号化または復号するための典型的な方法を示す。 重度の歪みの場合に、典型的なフレームにわたり直線イントラモードがどのように変化するかを示す。 長方形フレームにマッピングされた典型的な非正方形キューブを示す。 本原理の典型的な実施形態の様々な態様が実装され得る典型的なシステムのブロック図を示す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理の特定の実施形態に係るシステムの第１の実施形態を表す。 本原理に係るシステムの第１の実施形態を表す。 本原理に係るシステムの第１の実施形態を表す。 本原理に係る没入型映像レンダリングデバイスの第１の実施形態を表す。 本原理に係る没入型映像レンダリングデバイスの第１の実施形態を表す。 本原理に係る没入型映像レンダリングデバイスの第１の実施形態を表す。

大視野コンテンツは、とりわけ３次元コンピュータグラフィックイメージシーン（３Ｄ ＣＧＩシーン）、点群、または没入型映像であってよい。そのような没入型映像を意図するために、たとえば仮想現実（ＶＲ）、３６０、パノラマ、４π、ステラジアン、没入型、全方位、大視野など多数の用語が用いられ得る。

没入型映像は一般に、「通常の」映像のようにピクセル（すなわち色情報の要素）の２次元アレイである長方形フレーム上に符号化された映像を指す。多数の実装において、以下のプロセスが実行され得る。レンダリングのために、フレームは最初に、マッピング表面（たとえば球体、キューブ、ピラミッド）とも呼ばれる凸型ボリュームの内側表面にマッピングされ、次に、このボリュームの一部が仮想カメラによって捕捉される。仮想カメラによって捕捉された画像は、没入型表示デバイスのスクリーンにレンダリングされる。立体映像は、１または２つの長方形フレーム上に符号化され、デバイス特性に従って２つの仮想カメラによって捕捉されるように結合される２つのマッピング表面に投影される。

ピクセルは、フレーム内のマッピング関数に従って符号化され得る。マッピング関数は、マッピング表面に依存してよい。同じマッピング表面に関して、いくつかのマッピング関数が可能である。たとえば、キューブの面は、フレーム表面内の様々なレイアウトに従って構成され得る。球体は、たとえばエクイレクタングラー投影またはグノモン投影に従ってマッピングされ得る。選択された投影関数の結果生じるピクセルの組織化は、直線連続性、正規直交ローカルフレーム、ピクセル密度を修正または乱し、時間および空間における周期性をもたらす。これらは、映像を符号化および復号するために用いられる一般特徴である。既存の符号化および復号方法は通常、没入型映像の特異性を考慮に入れることがない。実際、没入型映像は３６０°映像であるので、たとえばパニングによって、シーンのコンテンツが変化しない間も大量のデータが符号化されることを必要とする動きおよび不連続性が生じる。没入型映像の特異性を考慮に入れつつ映像フレームを符号化および復号することは、符号化および復号方法に価値ある利点をもたらす。

図１は、実施形態例に係る符号化および復号システムの一般概観を示す。図１のシステムは、機能システムである。前処理モジュール１１０は、符号化デバイス１２０によって符号化するためのコンテンツを作成してよい。前処理モジュール１１０は、マルチ画像取得、共通空間（方向を符号化する場合、一般に３Ｄ球体）における取得した複数の画像のマージ、および限定されるものではないがたとえばエクイレクタングラーマッピングまたはキューブマッピングを用いて３Ｄ球体の２Ｄフレームへのマッピングを実行してよい。前処理モジュール１１０はまた、特定のフォーマット（たとえばエクイレクタングラー）の全方位映像を入力として受け入れ、マッピングを符号化により適したフォーマットに変更するために映像を前処理してよい。取得した映像データ表現に依存して、前処理モジュール１１０は、マッピング空間の変更を実行してよい。

符号化デバイス１２０および符号化方法は、本明細書の他の図面に関して説明される。符号化された後、たとえば没入型映像データまたは３Ｄ ＣＧＩ符号化データを符号化し得るデータは、たとえばゲートウェイ内に存在する任意のネットワークインタフェースとして一般に実装され得るネットワークインタフェース１３０へ送信される。データはその後、たとえばインターネットであるが他の任意のネットワークが予見され得る通信ネットワークを介して伝送される。その後データは、ネットワークインタフェース１４０を介して受信される。ネットワークインタフェース１４０は、ゲートウェイ、テレビ、セットトップボックス、頭部搭載型表示デバイス、没入型（投影用）壁、または任意の没入型映像レンダリングデバイスに実装され得る。

受信後、データは復号デバイス１５０へ送信される。復号機能は、以下の図２〜１２において説明される処理機能の１つである。復号されたデータは、次に、プレーヤ１６０によって処理される。プレーヤ１６０は、レンダリングデバイス１７０のためのデータを作成し、センサからの外部データまたはユーザ入力データを受信してよい。具体的には、プレーヤ１６０は、レンダリングデバイス１７０によって表示しようとする映像コンテンツの一部を作成する。復号デバイス１５０およびプレーヤ１６０は、単一のデバイス（たとえばスマートフォン、ゲーム機、ＳＴＢ、タブレット、コンピュータなど）に統合され得る。他の実施形態において、プレーヤ１６０は、レンダリングデバイス１７０に統合され得る。

たとえば没入型映像をレンダリングする場合、没入型表示デバイスの復号、再生、およびレンダリング機能を実行するために、いくつかの種類のシステムが考えられ得る。

拡張現実、仮想現実、または拡張仮想コンテンツを処理するための第１のシステムが図２〜６に示される。そのようなシステムは、処理機能、たとえば頭部搭載型ディスプレイ（ＨＭＤ）、タブレット、またはスマートフォンであってよくセンサを備え得る没入型映像レンダリングデバイスを備える。没入型映像レンダリングデバイスは、表示デバイスと処理機能との間の追加のインタフェースモジュールも備えてよい。処理機能は、１または複数のデバイスによって実行され得る。これらは、没入型映像レンダリングデバイスに統合され、または１または複数の処理デバイスに統合され得る。処理デバイスは、１または複数のプロセッサ、およびたとえば無線または有線通信インタフェースなど、没入型映像レンダリングデバイスとの通信インタフェースを備える。

処理デバイスは、たとえばインターネットなどの広域アクセスネットワークとの第２の通信インタフェースも備えてよく、たとえばホームまたはローカルゲートウェイなどのネットワークデバイスを介して、または直接、クラウドに存在するコンテンツにアクセスしてよい。処理デバイスは、たとえばイーサネットタイプのローカルアクセスネットワークインタフェースなど第３のインタフェースを介してローカルストレージにアクセスしてもよい。実施形態において、処理デバイスは、１または複数の処理ユニットを有するコンピュータシステムであってよい。他の実施形態において、処理デバイスは、有線または無線リンクを介して没入型映像レンダリングデバイスに接続され得る、または没入型映像レンダリングデバイス内のハウジングに挿入され、コネクタを介してまたは無線でこれと通信し得るスマートフォンであってよい。処理デバイスの通信インタフェースは、有線インタフェース（たとえばバスインタフェース、広域ネットワークインタフェース、ローカルエリアネットワークインタフェース）または無線インタフェース（たとえばＩＥＥＥ８０２．１１インタフェース、またはＢｌｕｅｔｏｏｔｈ（登録商標）インタフェース）である。

処理機能が没入型映像レンダリングデバイスによって実行される場合、没入型映像レンダリングデバイスに、直接またはゲートウェイを介してコンテンツを受信および／または送信するためのネットワークとのインタフェースが提供され得る。

他の実施形態において、システムは、没入型映像レンダリングデバイスおよび処理デバイスと通信する補助デバイスを備える。そのような実施形態において、この補助デバイスは処理機能の少なくとも１つを含み得る。

没入型映像レンダリングデバイスは、１または複数のディスプレイを備えてよい。デバイスは、自身のディスプレイの各々の前部において、たとえばレンズなどの光学部品を用いてよい。ディスプレイは、スマートフォンまたはタブレットのケース内など、没入型表示デバイスの一部であってもよい。他の実施形態において、ディスプレイおよび光学部品は、ユーザが装着することができるヘルメット、グラス、またはバイザーに組み込まれ得る。没入型映像レンダリングデバイスは、後述するように、いくつかのセンサを統合してもよい。没入型映像レンダリングデバイスは、いくつかのインタフェースまたはコネクタを備えてもよい。没入型映像レンダリングデバイスは、センサ、処理機能、ハンドヘルドまたは他の身体部位関連デバイスまたはセンサと通信するために、１または複数の無線モジュールを備えてよい。

没入型映像レンダリングデバイスは、１または複数のプロセッサによって実行され、コンテンツを復号またはコンテンツを処理するように構成された処理機能も備えてよい。ここでコンテンツを処理することは、表示され得るコンテンツを作成するための全機能として理解される。これはたとえば、コンテンツを復号すること、コンテンツを表示する前にマージすること、および表示デバイスに適合するようにコンテンツを修正することを備えてよい。

没入型コンテンツレンダリングデバイスの機能の１つは、仮想ボリュームとして構成されたコンテンツの少なくとも一部を捕捉する仮想カメラを制御することである。システムは、仮想カメラの姿勢を処理するために、ユーザの姿勢、たとえばユーザの頭部の姿勢を全体的または部分的に追跡する姿勢追跡センサを備えてよい。いくつかの位置決めセンサは、ユーザの変位を追跡してよい。システムは、たとえば照明、温度、または音条件を測定するために、環境に関連する他のセンサも備えてよい。そのようなセンサは、たとえば発汗率または心拍数を測定するために、ユーザの身体にも関連してよい。これらのセンサによって取得された情報は、コンテンツを処理するために用いられ得る。システムは、ユーザ入力デバイス（たとえばマウス、キーボード、リモートコントロール、ジョイスティック）も備えてよい。ユーザ入力デバイスからの情報は、コンテンツを処理し、ユーザインタフェースを管理し、または仮想カメラの姿勢を制御するために用いられ得る。センサおよびユーザ入力デバイスは、有線または無線通信インタフェースを介して、処理デバイスおよび／または没入型レンダリングデバイスと通信する。

図２５〜２９を用いて、拡張現実、仮想現実、拡張仮想、または拡張現実から仮想現実までの任意のコンテンツを表示するための第１の種類のシステムについて、いくつかの実施形態が説明される。

図２５は、没入型映像を復号、処理、およびレンダリングするように構成されたシステムの特定の実施形態を示す。システムは、没入型映像レンダリングデバイス１０、センサ２０、ユーザ入力デバイス３０、コンピュータ４０、およびゲートウェイ５０（任意選択）を備える。

図３３に示す没入型映像レンダリングデバイス１０は、ディスプレイ１０１を備える。ディスプレイは、たとえばＯＬＥＤまたはＬＣＤタイプである。没入型映像レンダリングデバイス１０は、たとえばＨＭＤ、タブレット、またはスマートフォンである。デバイス１０は、タッチ表面１０２（たとえばタッチパッドまたは触覚スクリーン）、カメラ１０３、少なくとも１つのプロセッサ１０４と接続状態にあるメモリ１０５、および少なくとも１つの通信インタフェース１０６を備えてよい。少なくとも１つのプロセッサ１０４は、センサ２０から受信した信号を処理する。

センサからの測定値のいくつかは、デバイスの姿勢を計算し、仮想カメラを制御するために用いられる。姿勢推定のために用いられるセンサは、たとえばジャイロスコープ、加速度計、またはコンパスである。たとえばカメラのリグを用いる、より複雑なシステムが用いられてもよい。この場合、少なくとも１つのプロセッサは、デバイス１０の姿勢を推定するために画像処理を実行する。他のいくつかの測定値は、環境条件またはユーザの反応に従ってコンテンツを処理するために用いられる。環境およびユーザを観察するために用いられるセンサは、たとえばマイクロフォン、光センサ、または接触センサである。たとえばユーザの視線を追跡するビデオカメラなど、より複雑なシステムが用いられてもよい。この場合、少なくとも１つのプロセッサは、予想される測定を操作するために画像処理を実行する。センサ２０およびユーザ入力デバイス３０からのデータもまたコンピュータ４０へ伝送されてよく、コンピュータ４０は、これらのセンサの入力に従ってデータを処理する。

メモリ１０５は、プロセッサ１０４のためのパラメータおよびコードプログラム命令を含む。メモリ１０５は、センサ２０およびユーザ入力デバイス３０から受信したパラメータも備えてよい。通信インタフェース１０６は、没入型映像レンダリングデバイスがコンピュータ４０と通信することを可能にする。処理デバイスの通信インタフェース１０６は、有線インタフェース（たとえばバスインタフェース、広域ネットワークインタフェース、ローカルエリアネットワークインタフェース）または無線インタフェース（たとえばＩＥＥＥ ８０２．１１インタフェース、またはＢｌｕｅｔｏｏｔｈ（登録商標）インタフェースなど）であってよい。

コンピュータ４０は、没入型映像レンダリングデバイス１０へデータを送信し、任意選択的に、没入型映像レンダリングデバイス１０へのコマンドを制御する。コンピュータ４０は、データの処理を担い、すなわち、没入型映像レンダリングデバイス１０によって表示するためにデータを作成する。処理は、コンピュータ４０のみによって行われてよく、あるいは処理の一部がコンピュータによって行われ、一部が没入型映像レンダリングデバイス１０によって行われ得る。コンピュータ４０は、直接、またはゲートウェイまたはネットワークインタフェース５０を介して、インターネットに接続される。コンピュータ４０は、インターネットから没入型映像を表現するデータを受信し、これらのデータを処理（たとえばデータを復号し、場合によっては、没入型映像レンダリングデバイス１０によって表示しようとする映像コンテンツの一部を作成）し、処理したデータを表示のために没入型映像レンダリングデバイス１０へ送信する。他の実施形態において、システムは、没入型映像を表現するデータが格納されるローカルストレージ（不図示）も備えてよく、上記ローカルストレージは、コンピュータ４０に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

図２６は、第２の実施形態を表す。この実施形態において、ＳＴＢ９０は、たとえばインターネットなどのネットワークに直接接続され（すなわちＳＴＢ９０がネットワークインタフェースを備え）、またはゲートウェイ５０を介して接続される。ＳＴＢ９０は、たとえばテレビセット１００または没入型映像レンダリングデバイス２００などのレンダリングデバイスへ、無線インタフェースまたは有線インタフェースを介して接続される。ＳＴＢの典型的な機能に加え、ＳＴＢ９０は、テレビ１００または任意の没入型映像レンダリングデバイス２００にレンダリングするために映像コンテンツを処理するための処理機能を備える。これらの処理機能は、コンピュータ４０に関して説明したものと同じであり、ここで再び説明することはない。センサ２０およびユーザ入力デバイス３０もまた、図２５に関して上述したものと同じ種類のものである。ＳＴＢ９０は、インターネットから没入型映像を表現するデータを取得する。他の実施形態において、ＳＴＢ９０は、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型映像を表現するデータを取得する。

図２７は、図２５に示す実施形態に関連する第３の実施形態を表す。ゲーム機６０は、コンテンツデータを処理する。ゲーム機６０は、没入型映像レンダリングデバイス１０へデータを送信し、任意選択的に没入型映像レンダリングデバイス１０へのコマンドを制御する。ゲーム機６０は、没入型映像を表現するデータを処理し、処理したデータを表示のために没入型映像レンダリングデバイス１０へ送信するように構成される。処理は、ゲーム機６０のみによって行われてよく、あるいは処理の一部が没入型映像レンダリングデバイス１０によって行われてもよい。

ゲーム機６０は、直接、またはゲートウェイまたはネットワークインタフェース５０を介して、インターネットに接続される。ゲーム機６０は、インターネットから没入型映像を表現するデータを取得する。他の実施形態において、ゲーム機６０は、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型映像を表現するデータを取得し、上記ローカルストレージは、ゲーム機６０に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

ゲーム機６０は、インターネットから没入型映像を表現するデータを受信し、これらのデータを処理（たとえばこれらを復号し、場合によっては、表示しようとする映像の一部を作成）し、処理したデータを表示のために没入型映像レンダリングデバイス１０へ送信する。ゲーム機６０は、センサ２０およびユーザ入力デバイス３０からデータを受信し、それらを用いて、インターネットまたはローカルストレージから取得した没入型映像を表現するデータを処理してよい。

図２８は、上記第１の種類のシステムの第４の実施形態を表し、ここで没入型映像レンダリングデバイス７０は、ハウジング７０５に挿入されたスマートフォン７０１によって形成される。スマートフォン７０１は、インターネットに接続され得るので、インターネットから没入型映像を表現するデータを取得してよい。他の実施形態において、スマートフォン７０１は、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型映像を表現するデータを取得し、上記ローカルストレージは、スマートフォン７０１に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

没入型映像レンダリングデバイス７０は、没入型映像レンダリングデバイス７０の好適な実施形態を示す図３４を参照して説明される。これは任意選択的に、少なくとも１つのネットワークインタフェース７０２およびスマートフォン７０１のためのハウジング７０５を備える。スマートフォン７０１は、スマートフォンおよびディスプレイの全機能を備える。スマートフォンのディスプレイは、没入型映像レンダリングデバイス７０のディスプレイとして用いられる。したがって、スマートフォン７０１のディスプレイ以外のディスプレイは含まれない。ただし、スマートフォンディスプレイ上のデータを見るために、たとえばレンズなどの光学部品７０４が含まれる。スマートフォン７０１は、場合によってはセンサ２０およびユーザ入力デバイス３０から受信したデータに従って、没入型映像を表現するデータを処理（たとえば復号し、表示用に作成）するように構成される。センサからの測定値のいくつかは、デバイスの姿勢を計算し、仮想カメラを制御するために用いられる。姿勢推定のために用いられるセンサは、たとえばジャイロスコープ、加速度計、またはコンパスである。たとえばカメラのリグを用いる、より複雑なシステムが用いられてもよい。この場合、少なくとも１つのプロセッサは、デバイス１０の姿勢を推定するために画像処理を実行する。他のいくつかの測定値は、環境条件またはユーザの反応に従ってコンテンツを処理するために用いられる。環境およびユーザを観察するために用いられるセンサは、たとえばマイクロフォン、光センサ、または接触センサである。たとえばユーザの視線を追跡するビデオカメラなど、より複雑なシステムが用いられてもよい。この場合、少なくとも１つのプロセッサは、予定された測定を操作するために画像処理を実行する。

図２９は、上記第１の種類のシステムの第５の実施形態を表し、ここで没入型映像レンダリングデバイス８０は、データコンテンツを処理および表示するための全機能を備える。システムは、没入型映像レンダリングデバイス８０、センサ２０、およびユーザ入力デバイス３０を備える。没入型映像レンダリングデバイス８０は、場合によってはセンサ２０およびユーザ入力デバイス３０から受信したデータに従って、没入型映像を表現するデータを処理（たとえば復号し、表示用に作成）するように構成される。没入型映像レンダリングデバイス８０は、インターネットに接続され得るので、インターネットから没入型映像を表現するデータを取得してよい。他の実施形態において、没入型映像レンダリングデバイス８０は、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型映像を表現するデータを取得し、上記ローカルストレージは、レンダリングデバイス８０に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

没入型映像レンダリングデバイス８０は、図３５に示される。没入型映像レンダリングデバイスは、ディスプレイ８０１を備える。ディスプレイは、たとえばＯＬＥＤまたはＬＣＤタイプ、タッチパッド（任意選択）８０２、カメラ（任意選択）８０３、少なくとも１つのプロセッサ８０４と接続状態にあるメモリ８０５、および少なくとも１つの通信インタフェース８０６から成ってよい。メモリ８０５は、プロセッサ８０４のためのパラメータおよびコードプログラム命令を備える。メモリ８０５は、センサ２０およびユーザ入力デバイス３０から受信したパラメータも備えてよい。またメモリは、没入型映像コンテンツを表現するデータを格納するのに足るほど大きくあってよい。このため、いくつかの種類のメモリが存在してよく、メモリ８０５は、単一メモリであるか、あるいは数種類のストレージ（ＳＤカード、ハードディスク、揮発性または不揮発性メモリなど）であってよい。通信インタフェース８０６は、没入型映像レンダリングデバイスがインターネットネットワークと通信することを可能にする。プロセッサ８０４は、ディスプレイ８０１に表示するために、映像を表現するデータを処理する。カメラ８０３は、画像処理ステップに関して環境の画像を捕捉する。没入型映像レンダリングデバイスを制御するために、このステップからデータが抽出される。

拡張現実、仮想現実、または拡張仮想コンテンツを処理するための第２のシステムが図３０〜３２に示される。そのようなシステムは、没入型壁を備える。

図３０は、第２の種類のシステムを表す。このシステムは、コンピュータ４０００からデータを受信する没入型（投影）壁であるディスプレイ１０００を備える。コンピュータ４０００は、インターネットから没入型映像データを受信する。コンピュータ４０００は通常、直接またはゲートウェイ５０００またはネットワークインタフェースを介してインターネットに接続される。他の実施形態において、没入型映像データは、没入型映像を表現するデータが格納されたローカルストレージ（不図示）からコンピュータ４０００によって取得され、上記ローカルストレージは、コンピュータ４０００に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

このシステムは、センサ２０００およびユーザ入力デバイス３０００も備えてよい。没入型壁１０００は、ＯＬＥＤまたはＬＣＤタイプであってよい。没入型壁１０００は、１または複数のカメラを備えてよい。没入型壁１０００は、センサ２０００（または複数のセンサ２０００）から受信したデータを処理してよい。センサ２０００から受信したデータは、照明条件、温度、ユーザの環境、たとえば物体の位置に関連してよい。

没入型壁１０００は、ユーザ入力デバイス３０００から受信したデータも処理してよい。ユーザ入力デバイス３０００は、ユーザ感情に関するフィードバックを与えるために、たとえば触覚信号などのデータを送信する。ユーザ入力デバイス３０００の例は、たとえばスマートフォン、リモートコントロール、およびジャイロスコープ機能を有するデバイスなどのハンドヘルドデバイスである。

センサ２０００およびユーザ入力デバイス３０００のデータは、コンピュータ４０００へ伝送されてもよい。コンピュータ４０００は、これらのセンサ／ユーザ入力デバイスから受信したデータに従って映像データを処理（たとえば復号し、表示用に作成）してよい。センサ信号は、没入型壁の通信インタフェースを介して受信され得る。この通信インタフェースは、Ｂｌｕｅｔｏｏｔｈタイプ、ＷＩＦＩタイプ、または他の任意の種類の接続であってよく、優先的には無線であるが、有線接続であってもよい。

コンピュータ４０００は、処理されたデータを没入型壁１０００へ送信し、任意選択的に、没入型壁１０００へのコマンドを制御する。コンピュータ４０００は、没入型壁１０００によって表示されるようにデータを処理、すなわち表示用に作成するように構成される。処理は、コンピュータ４０００のみによって行われてよく、あるいは処理の一部がコンピュータ４０００によって行われ、一部が没入型壁１０００によって行われ得る。

図３１は、第２の種類の他のシステムを表す。このシステムは、映像コンテンツを処理（たとえば復号し、表示用のデータを作成）および表示するように構成された没入型（投影）壁６０００を備える。このシステムは更に、センサ２０００、ユーザ入力デバイス３０００を備える。

没入型壁６０００は、ゲートウェイ５０００を介してインターネットから、またはインターネットから直接、没入型映像データを受信する。他の実施形態において、没入型映像データは、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型壁６０００によって取得され、上記ローカルストレージは、没入型壁６０００に、またはたとえばローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

このシステムは、センサ２０００およびユーザ入力デバイス３０００も備えてよい。没入型壁６０００は、ＯＬＥＤまたはＬＣＤタイプであってよい。没入型壁６０００は、１または複数のカメラを備えてよい。没入型壁６０００は、センサ２０００（または複数のセンサ２０００）から受信したデータを処理してよい。センサ２０００から受信したデータは、照明条件、温度、ユーザの環境、たとえば物体の位置に関連してよい。

没入型壁６０００は、ユーザ入力デバイス３０００から受信したデータを処理してもよい。ユーザ入力デバイス３０００は、ユーザ感情におけるフィードバックを与えるために、たとえば触覚信号などのデータを送信する。ユーザ入力デバイス３０００の例は、たとえばスマートフォン、リモートコントロール、およびジャイロスコープ機能を有するデバイスなどのハンドヘルドデバイスである。

没入型壁６０００は、これらのセンサ／ユーザ入力デバイスから受信したデータに従って映像データを処理（たとえば復号し、表示用に作成）してよい。センサ信号は、没入型壁の通信インタフェースを介して受信され得る。この通信インタフェースは、Ｂｌｕｅｔｏｏｔｈタイプ、ＷＩＦＩタイプ、または他の任意の種類の接続であってよく、優先的には無線であるが、有線接続であってもよい。没入型壁６０００は、センサおよびインターネットと通信するために少なくとも１つの通信インタフェースを備えてよい。

図３２は、没入型壁がゲームのために用いられる第３の実施形態を示す。１または複数のゲーム機７０００は、好適には無線インタフェースを介して没入型壁６０００に接続される。没入型壁６０００は、ゲートウェイ５０００を介してインターネットから、またはインターネットから直接、没入型映像データを受信する。他の実施形態において、没入型映像データは、没入型映像を表現するデータが格納されたローカルストレージ（不図示）から没入型壁６０００によって取得され、上記ローカルストレージは、没入型壁６０００に、またはローカルエリアネットワークを介してアクセス可能なローカルサーバ（不図示）にあってよい。

ゲーム機７０００は、命令およびユーザ入力パラメータを没入型壁６０００へ送信する。没入型壁６０００は、表示用のコンテンツを作成するために、場合によってはセンサ２０００およびユーザ入力デバイス３０００およびゲーム機７０００から受信した入力データに従って、没入型映像コンテンツを処理する。没入型壁６０００は、表示されるコンテンツを格納するための内部メモリも備えてよい。

１つの実施形態において、全方位映像は、映像コーデックに適したフォーマットで表現される標準長方形フレームＦへの周囲３Ｄ表面Ｓの投影を可能にするフォーマットで表現されると考えられる。３Ｄ表面を２Ｄ表面に投影するために、様々な投影が用いられ得る。たとえば図２Ａは、典型的な球体表面Ｓがエクイレクタングラー投影を用いて２ＤフレームＦにマッピングされることを示し、図２Ｂは、典型的なキューブ表面がキューブマッピングを用いて図２Ｃに示すように２Ｄフレームにマッピングされることを示す。たとえばピラミッド形、正二十面体、または八面体マッピングなど他のマッピングが、３Ｄ表面を２Ｄフレームにマッピングすることができる。

２ＤフレームＦはその後、たとえばＶＰ９、ＶＰ１０、ＭＰＥＧ−２、Ｈ．２６４／ＡＶＣ、またはＨ．２６５／ＨＥＶＣに準拠するエンコーダなど既存の映像エンコーダを用いて符号化され得る。２ＤフレームＦは、たとえば調整されたＶＰ９、ＶＰ１０、ＭＰＥＧ−２、Ｈ．２６４／ＡＶＣ、またはＨ．２６５／ＨＥＶＣエンコーダを用いて、全方位映像の特性に対応するエンコーダによって符号化されてもよい。符号化および復号の後、復号された２Ｄフレームは、対応する３Ｄ表面、たとえばエクイレクタングラーマッピングの場合は球体、またはキューブマッピングの場合はキューブに再びマッピングされ得る。３Ｄ表面はその後、最終的なレンダリングされたフレームを得るために、ユーザの視点に対応する「仮想スクリーン」に投影され得る。２Ｄフレームを復号し、３Ｄ表面からレンダリングされたフレームへ投影するステップは単一ステップに合併されてよく、この場合、復号されたフレームの一部がレンダリングされたフレームにマッピングされる。

簡潔な表記として、復号された２Ｄフレームを「Ｆ」とも称し、レンダリングに用いられる３Ｄ表面をＳとも称することとする。理解すべき点として、符号化される２Ｄフレームおよび復号される２Ｄフレームは、映像圧縮によって異なってよく、前処理における３Ｄ表面およびレンダリングにおける３Ｄ表面もまた異なってよい。本出願において、「マッピング」および「投影」という用語は相互置換的に用いられ、「ピクセル」および「サンプル」という用語は相互置換的に用いられ、「フレーム」および「ピクチャ」という用語は相互置換的に用いられる。

エクイレクタングラーマッピング

図３は、レンダリングされたフレームに２Ｄフレームがマッピングされる、典型的な逆エクイレクタングラーマッピングを示す。図３Ａは、（「エクイレクタングラーフレーム」とも称される）復号されたフレームにおけるｘ−ｙ座標内の点Ｐを示す。図３Ｂは、θ―φ極座標を用いて、Ｐからレンダリングの２Ｄ表面にマッピングされた点Ｐ’を示す。図３Ｃは、デカルト座標を用いて、３Ｄレンダリング空間Ｓ内のＰ’に対応する点Ｐ^3dを示す。図３Ｄは、ローカルレンダリングフレームＧにおける、Ｐ^3dにおいて表面に接するローカル面に投影されたＰ^3dの結果生じる点Ｐ”を示す。構成によって、Ｐ”はフレームの中心である。ローカルレンダリングフレームＧは、多くの場合ユーザが何を見たいかに基づいて、たとえばＨＭＤまたはユーザのハンドヘルドデバイスが指すものに基づいて、２ＤフレームＦの一部に対応する。ローカルレンダリングフレームＧは、ローカルレンダリングバージョンとも称される。

ＰからＰ’、Ｐ’からＰ^3d、およびＰ^3dからＰ”へのマッピングは、それぞれ「ｆ」、「３ｄ」、および「ｐｒｏｊ」と記される。図３において、逆エクイレクタングラーマッピングは、例示の目的で複数のステップ（「ｆ」、「３ｄ」、および「ｐｒｏｊ」）において示される。逆エクイレクタングラーマッピングは、たとえば「ｆ」、「３ｄ」、および「ｐｒｏｊ」を１または２つのステップに結合することによって、より少ないステップで実行され得る。

数学的に、マッピング「ｆ」は、正規座標を仮定して、フレームＦ内のピクセルＭ（ｘ，ｙ）が点Ｍ’（θ，φ）において２Ｄパラメトリック面にマッピングされた場合、
ｆ：Ｍ（ｘ，ｙ）→Ｍ’（θ，φ），θ＝２πｘ，φ＝πｙ （１）
と表すことができる。非正規化座標の場合、

である。

点Ｍ’（θ，φ）から座標Ｍ^3dの３Ｄ表面へのマッピング「３ｄ」は、以下のように表すことができる。

点Ｍ^3dからフレームＦへ戻すために、逆変換Ｔ^-1を計算する。
Ｔ^-1：Ｍ^3d→Ｍ，Ｍ＝ｆ^-1（３ｄ^-1（Ｍ^3d）） （４）
３Ｄ表面Ｓ上の点Ｍ^3d（Ｘ，Ｙ，Ｚ）から、極変換への標準デカルト座標を用いて２Ｄパラメトリックフレームへ戻すことができる。

更に２ＤフレームＦへ戻すために、
ｆ^-1：Ｍ’（θ，φ）→Ｍ（ｘ，ｙ） （６）
を用いることができる。

（一般に、極における）特異点に関して、ｘおよびｙが０に近い場合、

を直接設定してよい。ただし、モジュラーケースの場合、特別に対処すべきである。

図４Ａは、３Ｄ表面からレンダリングされたフレームＧへ点が投影されること（「ｐｒｏｊ」）を示す。Ｇにおけるローカルレンダリングフレームから見た点Ｑ’がＰ’に近い場合、表面Ｓに接する平面は、その表面自体によって近似され得る。図４Ｂにおいて、表面Ｑ’上のＱの画像によってＱ”が近似され得ることが示される。

３Ｄ空間から２Ｄ表面への投影は多くの場合、何らかのエフェクトまたは変化をもたらし、これは、結果として生じる映像を従来の平面の場合に得られるものと同様の品質／ビットレートのトレードオフで符号化することを困難にし得る。これらのエフェクトまたは変更は、以下を含んでよい。
‐強度のジオメトリ歪み
・直線が直線ではなくなる。
・直交座標系が直交ではなくなる。
‐不均一なピクセル密度：符号化されるフレーム内のピクセルは必ずしも、符号化される表面上で同じサイズ（すなわち、レンダリング段階の画像において同じサイズ）を表すわけではない。
‐強度の不連続性：フレームレイアウトは、２つの隣接するピクセル間で強度の不連続性をもたらし得る。
‐何らかの周期性がフレーム内に（たとえば１つの境界から対向する境界まで）生じ得る。

表１は、様々なマッピングに関するいくつかの変化を挙げる。

表１

以下、全方位映像の符号化および復号を説明するためにＨＥＶＣエンコーダおよびデコーダが主に用いられる。ただし本原理は、他のエンコーダまたはデコーダに適用されてよい。

図５は、典型的なＨＥＶＣエンコーダ５００を示す。１または複数のピクチャを有する映像シーケンスを符号化するために、ピクチャは１または複数のスライスに分割され、各スライスは、１または複数のスライスセグメントを含んでよい。スライスセグメントは、符号化ユニット、予測ユニット、および変換ユニットに組織化される。

本出願において、「再構成」および「復号」という用語は相互置換的に用いられ得る。必ずではないが多くの場合、「再構成」という用語はエンコーダ側で用いられ、「復号」はデコーダ側で用いられる。

ＨＥＶＣ仕様書は、「ブロック」と「ユニット」とを区別し、「ブロック」は、サンプルアレイにおける特定のエリア（たとえば輝度、Ｙ）を称し、「ユニット」は、全ての符号化色成分（Ｙ、Ｃｂ、Ｃｒ、またはモノクローム）、シンタックス要素、およびブロックに関連する予測データ（たとえば動きベクトル）の共在ブロックを含む。

符号化の場合、ピクチャは、構成可能なサイズを有する正方形の符号化ツリーブロック（ＣＴＢ）に分割され、符号化ツリーブロックの連続セットは、スライスにグループ化される。符号化ツリーユニット（ＣＴＵ）は、符号化色成分のＣＴＢを含む。ＣＴＢは、符号化ブロック（ＣＢ）に分割する４分木の根であり、符号化ブロックは、１または複数の予測ブロック（ＰＢ）に分割され、変換ブロック（ＴＢ）に分割する４分木の根を形成する。符号化ブロック、予測ブロック、および変換ブロックに対応して、符号化ユニット（ＣＵ）は、変換ユニット（ＴＵ）の木構造セットおよび予測ユニット（ＰＵ）を含み、ＰＵは、全ての色成分に関する予測情報を含み、ＴＵは、各色成分に関する残差符号化シンタックス構造を含む。輝度成分のＣＢ、ＰＢ、およびＴＢのサイズは、対応するＣＵ、ＰＵ、およびＴＵに適用される。本出願において、「ブロック」という用語は、ＣＴＵ、ＣＵ、ＰＵ、ＴＵ、ＣＢ、ＰＢ、およびＴＢのいずれかを指すように用いられ得る。また、「ブロック」は、Ｈ．２６４／ＡＶＣまたは他の映像符号化規格に記載されるようなマクロブロック、分割、およびサブブロックを指すように、より一般的には様々なサイズのデータのアレイを指すように用いられてもよい。

典型的なエンコーダ５００において、ピクチャは、後述するようにエンコーダ要素によって符号化される。符号化されるピクチャは、ＣＵのユニットで処理される。各ＣＵは、イントラまたはインターモードのいずれかを用いて符号化される。ＣＵがイントラモードで符号化される場合、イントラ予測を実行する（５６０）。インターモードの場合、動き推定（５７５）および補償（５７０）が実行される。エンコーダは、ＣＵを符号化するためにイントラモードまたはインターモードのどちらを用いるかを決定（５０５）し、予測モードフラグによってイントラ／インター決定を示す。予測残差は、元の画像ブロックから予測されたブロックを引算すること（５１０）によって計算される。

イントラモードにおけるＰＵは、同じスライス内の再構成された隣接サンプルから予測される。図６Ａに示すように、ＤＣ予測モード、ｐｌａｎａｒ予測モード、および３３のａｎｇｕｌａｒ予測モードを含む３５のイントラ予測モードのセットがＨＥＶＣにおいて利用可能である。イントラ予測参照は、現在のブロックに隣接する行および列から再構成される。参照は、過去に再構成されたブロックから利用可能なサンプルを用いて水平および垂直方向におけるブロックサイズの２倍以上に及ぶ。ａｎｇｕｌａｒ予測モードがイントラ予測に用いられる場合、参照サンプルは、図６Ｂの例に示すように、ａｎｇｕｌａｒ予測モードによって示された方向に沿ってコピーされ得る。ａｎｇｕｌａｒ予測モードは、本出願において、方向性予測モードとも称される。

ＨＥＶＣは、「Ｌ」が隣接する左のブロックのイントラ予測モードを表し、「Ａ」が隣接する上のブロックのイントラ予測モードを表す表２に示すように、輝度イントラ予測モードを予測的に符号化する場合、３つの最確モード（ＭＰＭ）、ＭＰＭ０、ＭＰＭ１、およびＭＰＭ２を考慮する。隣接する左ブロックは、図６Ｃに示すように、現在のブロックとは異なるサイズを有してよい。３つの最確モードの中でも、最初の２つは、上および左のＰＢが利用可能であり、イントラ予測モードを用いて符号化される場合、これらのＰＢの輝度イントラ予測モードによって初期化される。利用できないイントラ予測モードはいずれも、ＤＣモードであると考えられる。

表２

最初の２つの最確モードが等しくない場合、第１の最確モード（ＭＰＭ０）はＬに設定され、第２の最確モード（ＭＰＭ１）はＡに設定され、第３の最確モード（ＭＰＭ２）は、Ｐｌａｎａｒモード、ＤＣ、または垂直のどれがこの順序において最初の２つのモードの１つの複製ではないかに従って、Ｐｌａｎａｒモード、ＤＣ、または垂直に等しく設定される。最初の２つの最確モードが同じである場合、第１のモードが値ＰｌａｎａｒまたはＤＣを有すると、第２および第３の最確モードは、Ｐｌａｎａｒ、ＤＣ、または垂直のどれがこの順序において複製ではないかに従って、Ｐｌａｎａｒ、ＤＣ、または垂直として割り当てられる。最初の２つの最確モードが同じであり、第１のモードが角度値を有する場合、第２および第３の最確モードは、第１の角度（すなわちｋの値）に最も近い２つのａｎｇｕｌａｒ予測モードとして選択される。

現在の輝度予測モードが３つのＭＰＭのいずれかである場合、ＭＰＭインデックスのみがデコーダへ伝送される。そうでない場合、３つのＭＰＭ以外の現在の輝度予測モードのインデックスが、５ビット固定長コードを用いてデコーダへ伝送される。ＭＰＭを用いるイントラ予測モードの符号化は、テクスチャコンテンツが同類である場合、隣接ブロックが同じ予測モードを共有することが予想されるという想定に依拠する。

インターＣＵの場合、対応する符号化ブロックは、１または複数の予測ブロックに更に分割される。インター予測は、ＰＢレベルで実行され、対応するＰＵは、どのようにインター予測が実行されるかに関する情報を含む。

動き情報（すなわち、動きベクトルおよび参照ピクチャインデックス）は、２つの方法、すなわち「マージモード」および「高度な動きベクトル予測（ＡＭＶＰ）」でシグナリングされ得る。

マージモードにおいて、映像エンコーダまたはデコーダは、既に符号化されたブロックに基づいて候補リストを組み立て、映像エンコーダは、候補リスト内の候補の１つのインデックスをシグナリングする。デコーダ側において、動きベクトル（ＭＶ）および参照ピクチャインデックスは、シグナリングされた候補に基づいて再構成される。

ＡＭＶＰにおいて、映像エンコーダまたはデコーダは、既に符号化されたブロックから決定された動きベクトルに基づいて候補リストを組み立てる。映像エンコーダはその後、動きベクトル予測子（ＭＶＰ）を識別するための候補リスト内のインデックスをシグナリングし、動きベクトル差分（ＭＶＤ）をシグナリングする。デコーダ側において、動きベクトル（ＭＶ）は、ＭＶＰ＋ＭＶＤとして再構成される。

ＨＥＶＣにおいて、動き補償のための動き情報の精度は、輝度成分に関して（クオータペルまたは１／４ペルとも称される）４分の１サンプル、および彩度成分に関して（１／８ペルとも称される）８分の１サンプルである。７タップまたは８タップ補間フィルタは、分数サンプル位置の補間のために用いられ、すなわち、水平および垂直方向の両方におけるサンプル位置全体の１／４、１／２、および３／４が輝度に関してアドレス指定され得る。

その後、予測残差が変換（５２５）および量子化（５３０）される。量子化された変換係数、ならびに動きベクトルおよび他のシンタックス要素は、ビットストリームを出力するためにエントロピー符号化（５４５）される。エンコーダは、変換をスキップし、４×４ＴＵベースで無変換残差信号に直接量子化を適用してもよい。エンコーダは、変換および量子化の両方を回避してもよく、すなわち残差は、変換または量子化プロセスの適用なしで直接符号化される。直接ＰＣＭ符号化において、予測は適用されず、符号化ユニットサンプルはビットストリームに直接符号化される。

エンコーダは、更なる予測のための参照を提供するために、符号化されたブロックを復号する。量子化された変換係数は、予測残差を復号するために、逆量子化（５４０）および逆変換（５５０）される。復号された予測残差と予測されたブロックとを結合（５５５）すると、画像ブロックが再構成される。ループ内フィルタ（５６５）は、たとえば符号化アーチファクトを低減するためのデブロッキング／ＳＡＯフィルタリングを実行するために、再構成されたピクチャに適用される。フィルタされた画像は、参照ピクチャバッファ（５８０）に格納される。

図７は、典型的なＨＥＶＣ映像デコーダ７００のブロック図を示す。典型的なデコーダ７００において、ビットストリームは、後述するようにデコーダ要素によって復号される。映像デコーダ７００は一般に、映像データの符号化の一部として映像復号を実行する、図５に示すような符号化パスと互恵的な復号パスを実行する。

具体的には、デコーダの入力は、映像エンコーダ５００によって生成され得る映像ビットストリームを含む。ビットストリームは、変換係数、動きベクトル、および他の符号化情報を得るために、最初にエントロピー復号（７３０）される。変換係数は、予測残差を復号するために、逆量子化（７４０）および逆変換（７５０）される。復号された予測残差と予測されたブロックとを結合（７５５）すると、画像ブロックが再構成される。予測されたブロックは、イントラ予測（７６０）または動き補償された予測（すなわちインター予測）（７７５）から得られ得る（７７０）。上述したように、ＡＭＶＰおよびマージモード技術は、動き補償のための動きベクトルを導出するために用いられてよく、これは、参照ブロックのサブ整数サンプルに関する補間値を計算するために補間フィルタを用いてよい。ループ内フィルタ（７６５）は、再構成された画像に適用される。フィルタされた画像は、参照ピクチャバッファ（７８０）に格納される。

位置合わせ

図８は、レンダリングされたフレームにおける直線（８２０）が、符号化されるフレームにおいて直線に見えない（８１０）例を示す。具体的には、図８は、現在の予測ブロック（８３０）および対応する参照サンプル（８５０）のローカルマッピングおよびレンダリングを示す。ローカルマッピングおよびレンダリングにおいて、予測ブロック周囲の小部分のみがレンダリングバージョンにマッピングされる。左の画像は、符号化される典型的なエクイレクタングラーフレームＦの切り取られた一部である。右の画像は、典型的なレンダリングされたフレームにおける切り取られた一部であり、予測ブロックのローカルレンダリングバージョン（８４０）を示す。エクイレクタングラーフレームにおける予測ブロック（８３０）の隣接サンプル（８５０）は、レンダリングされたフレームＧにおける隣接エリア（８６０）にマッピングされる。参照のフレーム（８７０）は、予測ブロックの中心に中心がある。矢印（８８０）は、レンダリングバージョンが符号化される場合、従来のエンコーダによって選択され得る可能性のある方向性モードを示す。

図８の右の画像において、レンダリングされたフレームにおいてイントラ予測モードが直線に沿って伝搬してよく、ＭＰＭは符号化効率を高めると推定することが妥当である。しかし、エクイレクタングラーフレームにおいて、直線は予測ブロック（８３０）において直線ではなくなるので、エクイレクタングラーコンテンツにおけるブロックのイントラ予測モードを符号化する時にＭＰＭを直接適用することは、非常に効率が良いとは言えない。

たとえば、レンダリングされたフレームにおけるジオメトリを尊重するために隣接ブロックのイントラ予測モードを適合させることによって、全方位映像に関するＭＰＭ導出プロセスを改善することを提案する。

留意すべき点として、エクイレクタングラーフレームにおけるジオメトリ変化は、垂直方向である。１つの実施形態において、最初に、２ＤフレームＦ内の隣接イントラ予測モードを、レンダリングされたフレームＧにおける方向（すなわち角度）に変換し、次に、Ｇにおける方向を、現在のブロックに関するイントラ予測モードに変換する。すなわち、ここで隣接イントラ予測モードは現在のブロックに位置合わせされ、現在のブロックと同じ垂直レベルで表されるので、エクイレクタングラーマッピングによって生じるジオメトリ変化の影響を相殺し得る。

図９は、本原理の典型的な実施形態に係る、イントラ予測モードを符号化または復号するためにＭＰＭリストを適合させるための典型的な方法９００を示す。方法９００は、エンコーダまたはデコーダ側で用いられ得る。符号化される現在のブロックに関してエンコーダ側で用いられる場合、隣接する左および上のブロックがアクセスされ得る（９１０）。隣接ブロックに関するイントラ予測モードはその後、隣接ブロックが現在のブロックに位置合わせされるために変換され得る（９２０）。その後、隣接ブロックに関する変換されたイントラ予測モードに基づいて、ＭＰＭリストが決定され得る（９３０）。現在のブロックに関して試験された現在のイントラ予測モードが符号化され得る。現在のイントラ予測モードがＭＰＭリスト内にある場合、ＭＰＭリスト内のイントラ予測モードのインデックスのみが符号化される。そうでない場合、イントラ予測モードは、固定長符号化によって符号化され得る。現在のイントラ予測モードに関するＲＤコストが他のイントラ予測モードに関するＲＤコストよりも小さく、かつインター予測に関するＲＤコストよりも小さい場合、現在のブロックは、現在のブロックに関して現在のイントラ予測モードを用いることを選択してよい。

方法９００がデコーダ側で用いられる場合、現在のブロックに関するイントラ予測モードがＭＰＭの１つとして符号化されることをビットストリームが示すと、デコーダは、ＭＰＭインデックスを復号する。隣接する左および上のブロックがアクセスされ得る（９１０）。隣接ブロックに関するイントラ予測モードはその後、隣接ブロックが現在のブロックに位置合わせされるために変換され得る（９２０）。その後、隣接ブロックに関する変換されたイントラ予測モードに基づいて、ＭＰＭリストが決定され得る（９３０）。イントラ予測モードはその後、復号されたＭＰＭインデックスに基づいて、ＭＰＭの１つとして復号され得る。

方法９００は、隣接ブロックに関して左および上のブロックのみを考慮する。より一般的には、他のブロックが隣接ブロックとして考慮されてもよい。

例としてＨＥＶＣに従って導出されたＭＰＭを用いると、表３は、典型的な調整されたＭＰＭを示し、表中、Ｔ_L ^-1またはＴ_A ^-1は、たとえば左または上のブロックのワーピングインデックスによって示された垂直位置に基づいて、それぞれ左または上の隣接ブロックのイントラ予測モードインデックスをレンダリングされたフレーム内の角度に変換し、Ｔ_Cは、たとえば現在のブロックのワーピングインデックスによって示された垂直位置に基づいて、レンダリングされたフレーム内の角度をイントラ予測モードインデックスに再び変換する。「Ｔ_C」および「Ｔ_L ^-1」（「Ｔ_A ^-1」）の変換は、たとえば、Ｆ＝Ｔ_C（Ｔ_L ^-1（））またはＦ＝Ｔ_C（Ｔ_A ^-1（））として結合されてよく、ここで、「Ｔ_L ^-1」または「Ｔ_A ^-1」のどちらを用いるかは、対応するＭＰＭが隣接する左のブロックまたは上のブロックのどちらに由来するかに依存する。

表３

表３において、Ｌ≠ＰｌａｎａｒかつＬ≠ＤＣである場合、Ｔ_C（Ｔ_L ^-1（））がＬ＋１またはＬ−１に適用される。Ｔ_C（Ｔ_L ^-1（Ｌ＋１））またはＴ_C（Ｔ_L ^-1（Ｌ−１））がＴ_C（Ｔ_L ^-1（Ｌ））と同じである場合が生じ得る。３つの異なるＭＰＭをなお得るために、異なる実施形態において、モードＬ＋１およびＬ−１に関してＴ_C（Ｔ_L ^-1（））がＬに適用されてよく、ＭＰＭ１およびＭＰＭ２はそれぞれ、Ｔ_C（Ｔ_L ^-1（Ｌ））＋１およびＴ_C（Ｔ_L ^-1（Ｌ））−１に調整される。すなわち、「Ｔ_C（Ｔ_L ^-1（Ｌ））＝Ｔ_C（Ｔ_A ^-1（Ａ））」かつ「Ｌ≠ＰｌａｎａｒかつＬ≠ＤＣ」である場合、ＭＰＭは、以下のように導出され得る。

表３Ａ

以下において、エクイレクタングラーマッピングに関する変換「Ｔ_i」および「Ｔ_i ^-1」をどのように決定するかが詳しく説明され、ここで、Ｔ_iは、レンダリングされたフレーム内の角度を、復号されたフレーム（または符号化されるフレーム）内で表現されたイントラ予測モードインデックスへ、たとえばＨＥＶＣにおいて角度［４５°、・・・、１３５°］、ＤＣ、またはＰｌａｎａｒからインデックス［０、・・・、３５］へマッピングし、Ｔ_i ^-1は、イントラ予測モードインデックスを、レンダリングされたフレーム内の角度へ、たとえばＨＥＶＣにおいてイントラ予測モードインデックス［０、・・・、３５］から角度［４５°、・・・、１３５°］、ＤＣ、またはＰｌａｎａｒへマッピングする。構成によって、全てのワーピングインデックスに関してＴ（ＤＣ）＝１、Ｔ^-1（１）＝ＤＣ、Ｔ（Ｐｌａｎａｒ）＝０、Ｔ^-1（０）＝Ｐｌａｎａｒが定義される。

図１０Ａは、ｘ−ｙ座標系における正規化２Ｄフレームを示し、図１０Ｂは、エクイレクタングラーマッピングに関する典型的なワーピングインデックス演繹を示す。ここで、ワーピングインデックスは、ブロックのｙ座標、限定されるものではないがたとえば中心を用いて、ブロックのｙ座標に関するブロックの角のみに依拠する。簡単な記述のために、ブロックのｙ座標を示すために用いられる点をアンカー点と記す。ワーピングインデックスの展開は、エクイレクタングラーマッピングの特性により、ｃｏｓ（ｙ）によって導かれる。実際、ワーピングインデックスの数Ｎが与えられる場合、
ｗ（ｘ，ｙ）＝［Ｎ（１−ｃｏｓ（πｙ））］
を用いて、ブロックのワーピングインデックスｗを計算してよい。式中、（ｘ，ｙ）は、図１０Ａに示すようなピクチャ内のブロックの正規化座標である。この関数を用いて、ワーピングインデックスごとに１つの、最大（Ｎ＋１）の異なる方向変換表が得られ得る。他のスケール係数または変量が、ワーピングインデックスを得るために用いられてよい。一般に、ワーピングインデックスは、２Ｄフレームを生成するために用いられたマッピングに基づいて計算され得る。

図１１Ａは、本原理の実施形態に係る、変換「Ｔ」を計算するための典型的なワークフローを示す。

エクイレクタングラーマッピングは垂直方向にしか画像を歪ませないので、一般性を失わず、ｘ＝０が設定される。所与のワーピングインデックスｗに関して、ｙ座標ｙおよびｘ＝０に対応する点は、

であり、ワーピングインデックスは、
ｗ＝［Ｎ（１−ｃｏｓ（πｙ））］ （９）
として計算され得る。

Ｐ×ｆの画像であるＰ’は、
Ｐ’＝ｆ（Ｐ） （１０）
として計算され得る。Ｐ’×３ｄの画像であるＰ^3dは、
Ｐ^3d＝３ｄ（Ｐ’） （１１）
として計算され得る。その後、ｐｒｏｊ（）関数：Ｐ”＝ｐｒｏｊ（Ｐ^3d）を用いて、Ｐ”が計算され得る。

Ｐから方向ｄを指す点は、
Ｑ＝Ｐ＋εｄＰ （１２）
として表すことができ、

であり、式中、αは、（ワーピングインデックス０の各方向インデックスの角度に対応する）イントラ予測モードインデックスｄの方向角であり、すなわち、
α＝Ｔ₀ ^-1（ｄ） （１４）
である。

Ｑ×ｆの画像であるＱ’は、
Ｑ’＝ｆ（Ｑ） （１５）
として計算され得る。Ｑ’×３ｄの画像であるＱ^3dは、
Ｑ^3d＝３ｄ（Ｑ’）
として計算され得る。Ｑ^3d×ｐｒｏｊの画像であるＱ”は、
Ｑ”＝Ｐｒｏｊ（Ｑ^3d） （１６）
として計算され得る。

その後、Ｐ”とＱ”との差を表すベクトルｄＰ”が、
ｄＰ”＝Ｑ”−Ｐ” （１７）
として計算され得る。その結果、方向ｄにおけるワーピングインデックスｗの角度は、

として計算され得る。式中、ｄＰ”_xおよびｄＰ”_yは、ｄＰ”のｘおよびｙ成分である。その後、Ｔ_wがＴ_w ^-1の逆関数として計算され得る。

他の実施形態において、方向は、図１１Ｂに示すように、その点のローカルレンダリングフレームにおいて解釈される。ここで、レンダリングされたフレーム内の角度を、レンダリングされたフレーム内のイントラ予測モードインデックスにマッピングする関数Ｓ_iが計算される。

所与のワーピングインデックスｗに関して、ｙ座標ｙに対応して、すなわち

であり、ワーピングインデックス
ｗ＝［Ｎ（１−ｃｏｓ（πｙ））］ （２０）
であり、Ｐ×ｆの画像であるＰ’は、
Ｐ’＝ｆ（Ｐ） （２１）
として計算され得る。Ｐ’×３ｄの画像であるＰ^3dは、
Ｐ^3d＝３ｄ（Ｐ’） （２２）
として計算され得る。Ｐからの投影関数は、構成により、

である。

フレームＧにおいて、Ｐ”からの角度αに対応して方向ｄを指す点を以下のように計算する。
Ｑ”＝Ｐ”＋εｄＰ”＝εｄＰ” （２４）
かつ、

である。式中、αは、（ワーピングインデックス０の各方向インデックスの角度に対応する）イントラ予測モードインデックスの方向角ｄであり、すなわち、
α＝Ｓ₀ ^-1（ｄ） （２６）
である。点Ｑ^3dは、
Ｑ^3d＝Ｐｒｏｊ^-1（Ｑ”） （２７）
として計算され得る。その後、Ｑ’は、
Ｑ’＝３ｄ^-1（Ｑ^3d） （２８）
として計算され得る。Ｑは、
Ｑ＝ｆ^-1（Ｑ’） （２９）
として計算され得る。ＱとＰとの差を表すベクトルｄＰは、
ｄＰ＝Ｑ−Ｐ （３０）
として計算され得る。

その結果、方向ｄに関するワーピングインデックスｗの角度は、以下のように計算され得る。

留意すべき点として、ｄが、（関数Ｔに対応する）復号されたフレーム内で表現された方向のインデックスである、図１１Ａに示すような第１の実施形態において、レンダリングされたフレーム内の直線に関して、インデックスｄは垂直軸に沿って変化し得るが、図１１Ｂに示すような第２の実施形態において、インデックスｄは全てのブロックに関して同じである。ただし、予測段階において差が生じ、第１の実施形態の場合、ブロック予測方向はｄに関連する１つであるが、第２の実施形態において、レンダリングされたフレームから復号されたフレームへの変換が必要である。

イントラ方向性モードの場合、レンダリングされたフレーム内の所与の角度を方向性モードインデックスに変える変換（関数ＴまたはＳ）、および所与の方向性モードインデックスをレンダリングされたフレーム内の角度（角度β）に再び変える逆変換（関数Ｔ^-1またはＳ^-1）は、事前計算され、たとえばＨＥＶＣイントラ予測モードに関して生成された表４などの換算表に格納され得る。

表４

表内のワーピングインデックスｗに関して、方向性モードの個々のインデックスに関する対応角度を度単位で提供する。留意すべき点として、ワーピングインデックス０は、構成によって、従来のＨＥＶＣにおける角度を表す。その後、角度ｘを有するものに最も近いワーピングインデックスｉにおける、表内のイントラ予測方向性モードインデックスとして、Ｔ_i（ｘ）を定義する。たとえば表４において、ワーピングインデックス２の場合、Ｔ₂（１３４．５）＝３であり、１３４．５°に関して最も近い方向性モードインデックスは（１３５°に対応する）インデックス３である。同様に、逆変換の場合、Ｔ^-1 _i（ｊ）は、表４内のワーピングインデックスｉにおける方向性モードインデックスｊに対応する角度である。たとえばＴ^-1 ₁（３３）＝３６°である。

図１２は、本原理の実施形態に係る、エクイレクタングラーマッピングが用いられる場合に隣接する左のブロックに基づいてＭＰＭを得るための典型的なプロセス１２００を示す。方法１２００は、表３または表３Ａに示すようなＴ_c（Ｔ_L ^-1（Ｌ））を得るために用いられ得る。本原理は、他の隣接ブロックに基づいてＭＰＭを得るためにも用いることができる。留意すべき点として、Ｔ_L ^-1（）は、隣接する左のブロックのワーピングインデックスを計算し、左ブロックのイントラ予測モードインデックスを角度に変換するものであり、Ｔ_C（）は、現在のブロックのワーピングインデックスを得、Ｔ_L ^-1から得た角度を再びイントラ予測モードインデックスに変換するものである。

Ｔ_L ^-1（Ｌ）を計算するために、左ブロックＬの座標（ｘ_L，ｙ_L）が得られる（１２１０）。その後、左ブロックのワーピングインデックスがＬ_W＝［Ｎ（１−ｃｏｓ（πｙ_L）］として得られてよく（１２２０）、ｙ_Lは、左ブロックの位置を示す。その後、左ブロックに関するワーピング角度が、α_L＝Ｔ_LW ^-1（ｄ_L）として計算され（１２３０）、ｄ_Lは、左ブロックに関するイントラ予測モードインデックスである。

Ｔ_C（）を計算するために、現在のブロックＬの座標（ｘ_C，ｙ_C）が得られる（１２４０）。その後、現在のブロックのワーピングインデックスが、Ｃ_W＝［Ｎ（１−ｃｏｓ（πｙ_C））］として得られてよく（１２５０）、ｙ_Cは、左ブロックの位置を示す。その後、左ブロックに基づくＭＰＭに関する適応イントラ予測モードインデックスが、ｄ_C＝Ｔ_CW（α_L）＝Ｔ_CW（Ｔ_LW ^-1（ｄ_L））として計算され得る（１２６０）。

留意すべき点として、左ブロックに関する新たなイントラ予測モードインデックスは、現在のブロックと同じ垂直レベルにあり、現在のブロックのイントラ予測モードと同等である。すなわち、隣接する左のブロックおよび現在のブロックの角度は、レンダリングされたフレーム内で表現され、イントラモードは、上述したように伝搬する可能性が高い。

図１３は、典型的な赤道上の現在のブロックＣを示し、その隣接する左のブロックＬもまた赤道上にある。エクイレクタングラーマッピングの例として表４を用いると、以下のＭＰＭ導出が起こり得る。
‐左ブロックのワーピングインデックスは、左ブロックが赤道上にあるため、０である。復号された方向性イントラモードは、ｄ_L＝２である。表４から、左角α_L＝１３５°（第１行、第１列）と推論される。
‐現在のブロックのワーピングインデックスもまた、現在のブロックが赤道上にあるため、０である。左ブロックから予測されたイントラ方向は２（第１行、第１列に最も近い角度）である。エクイレクタングラーマッピングに関して、現在のブロックと隣接ブロックとが同じ垂直レベルにある場合、たとえば現在のブロックおよび隣接ブロックのアンカー点が同じ垂直レベルにある場合、変換の必要はない。留意すべき点として、様々なブロックサイズに関して、左ブロックおよび現在のブロックは、必ずしも同じワーピングインデックスを共有するわけではない。
‐上ブロックＡのワーピングインデックスは２である。復号されたイントラ予測モードインデックスは、ｄ_A＝３である。表４から、上角α_A＝１３５°（第３行、第２列）と推論される。
‐上ブロックから予測されたイントラ方向は２（第１行、第１列に最も近い角度）である。
ＭＰＭ導出によると、２つの隣接するブロックは同じ方向性予測子を提供し、すなわち、Ｔ_C（Ｔ_L ^-1（Ｌ））＝Ｔ_C（Ｔ_A ^-1（Ａ））、Ｌ≠ＰｌａｎａｒかつＬ≠ＤＣである。表３Ａを用いると、３つのＭＰＭは、ＭＰＭ０＝Ｔ_C（Ｔ_L ^-1（Ｌ））＝２、ＭＰＭ１＝Ｔ_C（Ｔ_L ^-1（Ｌ））＋１＝３、およびＭＰＭ２＝Ｔ_C（Ｔ_L ^-1（Ｌ））−１＝３４である。

上記において、ＨＥＶＣ ＭＰＭを例として用いて、隣接ブロックおよび現在のブロックの垂直レベルに基づいて隣接イントラ予測モードを調整することが説明される。本原理は、ＭＰＭが様々な方法で導出される場合に適用され得る。たとえば、昨今の開発において、ＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ）のｊｏｉｎｔ ｅｘｐｌｏｒａｔｉｏｎソフトウェア（ＪＥＭ）は、図１７に示すように、ＨＥＶＣと比べて２倍の数のイントラ方向性モードを用いる。また、ＭＰＭリストを３から６のイントラモードに拡大することが提案されている。ＭＰＭリストの導出は、表５に詳述する。この新たなリストは、隣接する左および上のブロックから導かれた２つのモードも考慮に入れる。図６Ｃに示すように左および上の候補に関して左上角部から第１のブロックを考えるのではなく、最終的なＬおよびＡ候補は、隣接ブロックの中でも最も頻度の高いモードに対応し、それぞれ現在のブロックの左および右に対応する。

表５

表５に示すようなＭＰＭに関して、左におけるイントラ予測モード（「Ｌ」）は、（Ｔ_C（Ｔ_L ^-1（Ｌ）））に調整することができ、上におけるイントラ予測モード（「Ａ」）は、（Ｔ_C（Ｔ_A ^-1（Ａ）））に調整することができ、イントラ予測モードｍｏｄｅ＝２６、１０、２、または１８は、（Ｔ_C（Ｔ_L ^-1（ｍｏｄｅ）））または（Ｔ_C（Ｔ_A ^-1（Ｌ）））に調整することができ、イントラ予測モード（「Ｍａｘ」）は、（Ｔ_C（Ｔ_Max ^-1（Ｍａｘ）））に調整することができ、Ｍａｘは、所与のコーデックの最大の方向インデックス、ＨＥＶＣの場合は３３、ＪＥＭの場合は６４を表す。

特定のマッピングが用いられ、ストリームにおいてシグナリングされる場合、ブロック座標とワーピングインデックスとの関係を自動的に推論することができる。

第１の方法は、ＭＰＭ変換のために用いられるワーピングインデックスをシグナリングすることである。シグナリングは、シーケンスレベル、スライスレベル、あるいはＣＴＵ、ＣＵ、またはＰＵレベルで行われ得る。ブロックレベルでシグナリングされる場合、ワーピングインデックスを符号化するために、コンテキストおよびエントロピー符号化が用いられる。

エンコーダ側において、ワーピング表が構成され、シーケンスレベル、スライスレベル、またはブロックレベルで送信され得る。表の構成は、符号化方法と考えられる。表の符号化は、エントロピーおよびコンテキスト符号化を用いてよい。

特定のマッピングが用いられ、ストリームでシグナリングされる場合、用いられるワーピング角度を自動的に推論することができる。この場合、エンコーダおよびデコーダの両方が同じ表を用い、これを送信する必要はない。

上記において、エクイレクタングラーマッピングに関してイントラ予測モードを調整することが説明された。キューブマッピングの場合、マッピングは、キューブ面において典型的なモードを修正することはない。しかし、エッジにおいて修正が出現する。図１４Ａは、キューブマッピングの例を示す。面は、長方形フレームに様々に分布され得る。いくつかのエッジにおいて、他の面において再構成され、それに応じて回転された隣の適切な位置を指すように、エンコーダ／デコーダに関して特定のマッピングが実装されなければならない。

その後、球体からキューブへの投影を用いて、同じ方法で方向の変化が適用され得る。図１４Ｂは、エッジにおける方向変化の例を示す。この例において、左面にあるブロックは、セグメントによって示された方向性モードを用いて符号化された。右における現在のブロックに関するＭＰＭは、その後、セグメントによって示すように修正される。

利用可能なイントラ予測モードの低減

図１５は、全方位ピクチャの典型的なエクイレクタングラーレイアウトおよび垂直座標に沿った参照のローカルフレームの展開を示す。図１５から分かるように、参照の専用ローカルフレーム、すなわち、球体（１５１０）の赤道上を中心とする、投影によって生じた変形を示す座標系は、正規直交である。垂直方向に沿って、参照のフレームを中心から離れる方へ移動すると、参照のフレーム（１５２０、１５３０）は正規直交ではなくなる。具体的には、参照のローカルフレームが（球体の極に対応する）上下の境界線に近づく方に動くとともに、参照のローカルフレームは、垂直方向に「縮んで」いく。

図１６Ａ、図１６Ｂ、図１６Ｃ、図１６Ｄ、および図１６Ｅは、それぞれ異なる緯度０°、４５°、６６°、８０°、および８５°から見た同一パターンの画像を示す。図１６Ａに示すように赤道において、全方向が利用可能であり、規則的に分布される。パターンが極に近く見えるほど、エクイレクタングラーフレームにおいて（中心における）方向は水平になる。

図６Ａおよび図６Ｂに関して説明したように、方向性イントラ予測モードにおいて、現在のブロックの予測は、周囲にある過去に再構成されたサンプルおよび予測の方向を用いて計算され、サンプルは、選択された方向に沿って現在の予測ブロックに「伝搬」される。しかし、全方位映像において、参照のローカルフレームはその中心位置に依拠するために常に正規直交ではなく、フレーム内の位置における可能な方向の数は、圧縮効率を高めるために低減され得る。たとえば、エクイレクタングラー（Ｅｒ）レイアウトにおいて、図１６は、赤道上では全方向が利用可能であるが、極に非常に近いところでは、水平方向のみが妥当であることを示す。

上記観察に基づいて、イントラＭＰＭ導出を更に改善することを提案する。様々な実施形態において、ジオメトリック歪みに依存してイントラ方向の低減を考慮に入れるために、ＭＰＭの導出が適合され得る。符号化方法もまた、全方位映像におけるブロックを見積もるためのモードの数を低減するように適合され得る。また、イントラ方向を表すシンタックス要素の符号化も改善され得る。

表６

表６は、ＭＰＭがｄに適合されることを示し、ここでパラメータｄは、ジオメトリックレイアウトに適合された角度ステップサイズを示す。たとえば、「Ｌ≠ＰｌａｎａｒかつＬ≠ＤＣ」かつ「Ｆ（Ｌ）＝Ｆ（Ａ）」の場合、ＭＰＭ２に関して「Ｆ（Ｌ）＋１」の代わりに「Ｆ（Ｌ）＋ｄ」となる。すなわち、「Ｆ（Ｌ）＋１」と「Ｆ（Ｌ）＋ｄ−１」との間のイントラ予測モードをスキップしてよいので、「Ｆ（Ｌ）」に対応する角度に隣接する角度が「Ｆ（Ｌ）＋ｄ」であると考えられる。赤道において、ｄ＝１であり、ブロックが極に近づくほどｄは増大する（より多くのイントラ予測モードがスキップされる）。ｄの計算は、以下に詳述される。

以下の表記を用いることとする。
‐ａは、参照のローカルフレームの垂直軸と水平軸との間のスケール係数を示す。構成によって、標準映像またはエクイレクタングラー映像の赤道においてａ＝１であり、エクイレクタングラー映像の極においてａ＝０である。
‐「標準」ローカルフレーム（すなわちａ＝１）に関して、方向の数はＮ（ａ）であり、たとえば現在のＪＶＥＴ Ｅｘｐｌｏｒａｔｉｏｎモデル（ＪＥＭ）では６５、ＨＥＶＣでは３３である。
‐「標準」角度ステップサイズは度単位でｓ（ａ＝１）＝１８０／（Ｎ（１）−１）である。たとえばＨＥＶＣでは５．６２５°である。
‐１８０°の「標準」イントラ方向の予測角度をＺ（ａ＝１）と定義し、水平方向より４５°下および水平方向より１３５°上をそれぞれＺ^-（ａ＝１）＝４５°およびＺ⁺（ａ＝１）＝１３５°と定義する。
‐図１８に示すように、Ｎ^-（ａ）＝（Ｎ（ａ）−１）／４は、水平より下の方向の数であり、Ｎ⁺（ａ）＝３（Ｎ（ａ）−１）／４は、水平より上の方向の数である。
‐構成により、ｄ（ａ＝１）＝１である。

ｘ軸とｙ軸との間のスケール係数ａによって所与のローカルフレームＦ_Lに関する方向を推論するために、以下の論理が適用される。
‐スケール係数ａに関する角度は、
Ｚ^-（ａ）＝ａｔａｎ（ａ＊ｔａｎ（Ｚ^-（１）））、Ｚ⁺（ａ）＝３＊Ｚ^-（ａ） （３２）
によって求められる。
‐フレーム内で同じ角度ステップを維持すると、利用可能なイントラ予測方向の数は以下のように推論される。

‐その後、パラメータｄを推論する。

図１９は、ａ＝１、０．５、０．２５、および０．１２５に関して上記計算の例を提供する。図１９の上段において、参照のローカルフレームが示される。図１９の中断において、式（３２）を用いて計算されたスケール係数αに関する角度が示され、同じ数の方向が各スケール係数ａに関して維持される。図１９の下段において、同じレベルに角度ステップを維持することが意図され、スケール係数ａが小さくなると方向の数が低減される。図１９Ａ、図１９Ｂ、および図１９Ｃから分かるように、図１９Ａにおける利用可能なイントラ予測モードのセットは、図１９Ｂまたは図１９Ｃにおける利用可能なイントラ予測モードのセットと異なるが、図１９Ａにおける水平方向の周囲の２つの隣接するイントラ予測モード間の角度差は、図１９Ｂまたは図１９Ｃにおける水平方向の周囲の２つの隣接するイントラ予測モード間の角度差と同じである。図１９Ｄにおいて、全ての角度が水平方向に倒れ込む。

低減されたイントラ予測モードのセットを表現するために、残りのイントラモードに関して同じイントラ予測モードインデックスが維持され、２つの隣接モード間の角度差を示すために角度ステップｄが用いられ得る。たとえば、赤道において利用可能なイントラ予測方向性モードインデックスは、２、３、４、・・・、かつｄ＝１であってよく、他の位置におけるインデックスは、２、５、８、・・・、かつｄ＝３であってよいが、同じインデックスは同じイントラ予測モードに対応する。エンコーダおよびデコーダは、利用可能なイントラ予測モードのみを用いる。パラメータｄは、ＭＰＭリストを構築するためにエンコーダによって用いられ、デコーダにおいて計算されるか、あるいはビットストリームで伝送されてよい。均一なステップｄを有するコーデックの場合、単一のパラメータが用いられる。不均一なステップの場合、ルックアップテーブルは、デコーダによって先験的に既知であるか、あるいはビットストリームを介して、たとえばシーケンスパラメータセットまたはビデオパラメータセットで伝送されてよい。

他の実施形態において、イントラ予測モードインデックスは、エクイレクタングラー投影の特定の場合において、ブロック位置、緯度が与えられると設定される新たなステップに依存して再組織化される。方向性モードの新たなインデックスは連続しており、２〜Ｎ−１の範囲であってよく、ここでＮは位置に依存する。

角度ａが減少すると利用可能なイントラ予測方向の数は減少するので、イントラ方向の符号化もまた改善され得る。上述したように、５ビット固定長コードは、ＨＥＶＣにおいてイントラ予測モードがＭＰＭリストに含まれない場合、イントラ予測モードを符号化するために用いられ、ＪＥＭの場合は６ビットが用いられる。所与のブロックに関して、固定長コードに関するビットの数を以下に適合させることを提案する。
ｎ＝［ｌｏｇ₂（Ｎ_a ⁺＋Ｎ_a ^-＋１）］ （３５）

効率性のために、方向符号化および値は、ローカルフレームスケール係数ａのみに依存して、エンコーダおよびデコーダ側の両方において決定され得る。エクイレクタングラーマッピングの場合、ローカルフレームスケールは、
ａ＝ｃｏｓ（φ） （３６）
と計算することができ、緯度角は、

である。

式（３７）から、緯度角φは、ブロックの垂直位置である「ｙ」に依拠することが分かる。続いて、参照スケールａのローカルフレームもまた、垂直位置に依拠し（式（３６）を参照）、パラメータｄおよび固定長コードのビット数ｎも同様に垂直位置に依拠する（式（３４）および（３５）を参照）。

予測ブロックの位置と方向の数との関係および符号化を簡略化するために、表７の例に示すように、対応表が構成され得る。

表７

ａｂｓ（φ）値＝［０，０．７８］（ｒａｄ）、「ｈ」がピクチャの高さとして［０．２５*ｈ，０．７５*ｈ］間のピクセルの場合、全てのイントラ予測方向性モードが利用可能であり、ブロックに関するイントラ予測方向性モードは、全３３モードから選択され得る。ａｂｓ（φ）値＝［０．７８，１．２６］（ｒａｄ）、［０．１*ｈ，０．２５*ｈ］または［０．７５*ｈ，０．９*ｈ］間のピクセルの場合、０〜１５のインデックスを有する約半数（１６）のイントラ予測方向性モードが利用可能である。したがって、ブロックに関するイントラ予測方向性モードは、これら１６のモードのみから選択され得る。ａｂｓ（φ）値＝［１．２６，１．４７］（ｒａｄ）、［０．０５*ｈ，０．１*ｈ］または［０．９*ｈ，０．９５*ｈ］のピクセルの場合、０〜７のインデックスを有する約４分の１（８）のイントラ予測方向性モードが利用可能である。

図２０は、利用可能な方向の数に依存して、モードの導出を容易にするために、方向をグループ分けし、イントラ方向を再順序付けする例を示す。方向の数は、緯度角φの関数として、表７に示される。ＨＥＶＣまたはＪＥＭのようにイントラ予測方向性モードに連続的にインデックスを割り当てるのではなく、インデックスはインタレース式に割り当てられ得る。表７および図２０に示す例において、モードインデックスは、ＨＥＶＣイントラ予測モードの方向に関して再組織化される。

ここで図２０において、２つの利用可能なモードしかない場合、モード０および１が維持される。４つの利用可能なモードがある場合、モード０〜３が維持される。８つの利用可能なモードがある場合、モード０〜７が維持される。１６のモードがある場合、モード０〜１５が維持される。したがって、利用可能なイントラ予測モードは常に、連続したイントラ予測モードインデックスのセットによって表されるが、その範囲は、維持されるモードの数に依存して様々であってよい。このモードインデックス構成において、同じイントラ予測モードインデックスは常に、同じイントラ予測方向に対応する。

図２１Ａは、本原理の実施形態に係る、ＭＰＭリストを用いて現在のブロックに関するイントラ予測モードを符号化または復号するための典型的な方法２１００を示す。図２１Ｂは、本原理の実施形態に係る、固定長コードを用いて現在のブロックに関するイントラ予測モードを符号化または復号するための典型的な方法２２００を示す。

エンコーダ側で用いられる場合、隣接する左および上のブロックに関するイントラ予測モードが得られる（２１１０）。たとえば式（３４）、またはパラメータｄに垂直位置を関連付けるルックアップテーブルを用いて、角度ステップサイズｄが計算され得る（２１２０）。角度ステップサイズｄが変化すると、利用可能なイントラ予測モードの数も変化する。その後、たとえばＪＥＭに関する表６に示すように、角度ステップサイズｄに基づいて、ＭＰＭリストが調整され得る（２１３０）。符号化のために試験されている現在のイントラ予測モードがＭＰＭの１つである場合、対応するＭＰＭインデックスが決定され、現在のイントラ予測モードを用いるための符号化コストが計算され得る。ＲＤコストは、現在のイントラ予測モードが現在のブロックに関して選択されるかを決定するために、他の予測モードと比較され得る。

試験中の現在のイントラ予測モードがＭＰＭの１つではない場合、エンコーダは、たとえば式（３５）に基づいて、利用可能なイントラ予測モードの数および固定長コードに関するビット数を計算してよい（２２６０）。その後、エンコーダは、計算されたビット数を用いてイントラ予測モードを符号化し（２２７０）、関連ＲＤコストに基づいて、現在のイントラ予測モードが用いられるかを決定する。

デコーダ側で用いられる場合、デコーダは、イントラＭＰＭが現在のブロックに用いられるかを決定する。デコーダは、ＭＰＭが用いられることを決定すると、エンコーダに関して行われたものと同様のステップ２１１０〜２１３０を実行する。その後、デコーダは、ＭＰＭインデックスに基づいてイントラ予測モードを復号する。デコーダは、固定長コードがイントラ予測モードに用いられることを決定すると、固定長コードに関するビット数を計算し（２２６０）、固定長コードに関するビット数に基づいて、イントラ予測モードを復号する（２２７０）。

提案される方法は、既知のジオメトリ歪みに基づいて、隣接するブロックからイントラ方向性伝搬モードを導出する一般原理に依拠する。

たとえば、映像の種類、考慮される予測ブロックの位置およびサイズに依存して、他のイントラモードとして二次曲線が追加され得る。映像が広角／短焦点距離を用いたショットであった他の例において、何らかの歪みが直線を変形させ得る。歪みを低減させるために、場合によっては円筒補正が用いられる。映像が歪んでいる場合、曲線的イントラ予測は多くの場合、特に境界線上で変形した曲線に沿って参照ピクセルを伝搬することによって、圧縮効率を高めることができる。当然、直線イントラ予測は、所与のブロック表面に関する良好な推定として維持される。両方の場合において、ＭＰＭ導出を既知の歪みに適合させることによって、性能が向上する。

図２２は、重度の歪みの場合、典型的なフレームにわたって直線イントラモードがどのように変化するかを示す。エクイレクタングラーマッピングに関する上記において、イントラ予測は、垂直方向に適合されることが説明された。留意すべき点として、他の種類の映像、たとえば短焦点距離映像の場合、レンズの中心からの径方向の変動が存在し得るので、イントラ予測は、水平方向にも適合され得る。

短焦点距離映像の場合、歪みに関する古典的モデルは、Ｂｒｏｗｎ−Ｃｏｎｒａｄｙモデルを用いることであり、ここで２Ｄ＋３Ｄの歪みは単純な２Ｄ関数（ｘ_d，ｙ_d）＝ｇ（ｘ_u，ｙ_u，Ｓ）にマージされ、（ｘ_d，ｙ_d）は、歪み後の（フレームＦにおける）ピクセル座標であり、（ｘ_u，ｙ_u）は歪み前の（フレームＧにおける）ピクセル座標である。歪み関数ｇ（）は、組成ｇ＝ｆ^-1 ｏ ３ｄ^-1 ｏ ｐｒｏｊ^-1である。歪み関数ｇ（）は、Ｂｒｏｗｎ−Ｃｏｎｒａｄｙモデルを用いて得られ得る。

図２２において、フレームの境界付近で、方向性モードはブロックごとに変化するので、隣接ブロックから導出されたＭＰＭを適合させる必要がある。古典的なＭＰＭプロセスへの修正の提案に関して上述した原理は、この新たな伝達関数ｇを考慮して適用され得る。

図２２において、利用可能な方向の数は位置ごとに異なることも分かる。極位置において、連続する歪み方向間の角度ステップは、考慮するに足りないほど小さい。したがって、方向性モードの数、およびそれに伴うシンタックスビット数の低減に関する上述の原理が適用され得る。

非正方形キューブマッピングの場合、参照のローカルフレームは、画像のほとんどの部分において正規直交ではなくなる。図２３は、長方形フレームにマッピングされた典型的な非正方形キューブを示す。この場合、解像度は、キューブ面に依存する。

利用可能な方向の数が変化すると、全ての方向が利用可能な（コーデックにおいて変化がない）場合でも、利用可能な方向のみがエンコーダ側において試験される。この場合、方向の数は、Ｎ⁺（ａ）／Ｎ^-（ａ）およびＺ⁺（ａ）／Ｚ^-（ａ）を変えることによって、それに応じて適合される。

この新たなイントラ方向リスト処理を用いるために、フラグが設定され得る。
‐ＰＰＳ（ピクチャパラメータセット）レベルで、このツールが利用可能であるかを示す。このフラグは、場合によっては、全方位映像に関する新たなＭＰＭ手順と同じである。
‐ブロック（ＣＴＵ／ＣＵ／ＰＵ）レベルで、イントラ方向処理のポリシを示す。フラグが１に設定された場合、イントラ方向の数は上述したように減少する。
利用可能なイントラ予測方向のリストは、マッピングに基づいて、エンコーダ側およびデコーダ側の両方で計算される。

利用可能な方向の数は、デコーダにも伝送され得るので、画像のマッピング種類とは無関係である。
‐ＰＰＳレベルで、現在のフレームに関して利用可能なイントラ方向の数を示す。可能な方向の数は、行または列ごと、または画像エリア（スライス、タイルなど）ごとにインデックス化され得る。
‐ＣＴＵ／ＣＵ／ＰＵレベルで、場合によっては差動／コンテキスト符号化を用いて、周囲ブロックを考慮に入れて、考慮されるブロックに関して利用可能なイントラ方向の数を示す。

映像符号化および復号中のイントラ予測のためのＭＰＭに関して様々な実施形態が説明された。たとえば、表３に示すようにＭＰＭが位置合わせされ、あるいは図１９に示すようにイントラ予測方向性モードの数が低減される。これらの様々な実施形態は、個別で、または組み合わせて用いられ得る。

図２４は、本原理の典型的な実施形態の様々な態様が実装され得る典型的なシステム２４００のブロック図を示す。システム２４００は、後述する様々な構成要素を含むデバイスとして具体化されてよく、上述したプロセスを実行するように構成される。そのようなデバイスの例は、たとえばＨＭＤ、パーソナルコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、デジタルマルチメディアセットトップボックス、デジタルテレビ受信機、パーソナル映像記録システム、接続された家電機器、およびサーバを含むがこれに限定されない。システム２４００はセンサを備えてよく、上述した典型的な映像システムを実装するために、図２４に示し当業者に知られるような通信チャネルを介して他の同様のシステムに通信可能に結合され得る。

システム２４００は、上述したような様々なプロセスを実行するためにそこにロードされた命令を実行するように構成された少なくとも１つのプロセッサ２４１０を含んでよい。プロセッサ２４１０は、当該技術において既知であるように、埋込型メモリ、入力出力インタフェース、および様々な他の回路を含んでよい。システム２４００は、少なくとも１つのメモリ２４２０（たとえば揮発性メモリデバイス、不揮発性メモリデバイス）も含んでよい。システム２４００は更に、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、フラッシュ、磁気ディスクドライブ、および／または光ディスクドライブを含むがこれに限定されない不揮発性メモリを含み得るストレージデバイス２４４０を含んでよい。ストレージデバイス２４４０は、非限定的な例として、内部ストレージデバイス、接続型ストレージデバイス、および／またはネットワークアクセス可能ストレージデバイスを備えてよい。システム２４００は、符号化映像または復号された映像を提供するためにデータを処理するように構成されたエンコーダ／デコーダモジュール２４３０も含んでよい。

エンコーダ／デコーダモジュール２４３０は、符号化および／または復号機能を実行するためにデバイスに含まれ得るモジュール（複数も可）を表す。エンコーダ５００およびデコーダ７００は、エンコーダ／デコーダモジュール２４３０において用いられ得る。既知であるように、デバイスは、符号化および復号モジュールの１または両方を含んでよい。また、エンコーダ／デコーダモジュール２４３０は、当業者には既知であるように、システム２４００の独立要素として実装されてよく、あるいはハードウェアとソフトウェアとの組み合わせとしてプロセッサ２４１０内に組み込まれてもよい。

システム２４００は、ディスプレイ（２４９０）を更に含んでよく、または通信チャネルを介してディスプレイに通信可能に結合され得る。ディスプレイはたとえばＯＬＥＤまたはＬＣＤタイプである。ディスプレイは、多くの場合大きなサイズである、没入型（投影）壁であってもよい。

システム２４００は更に、タッチ表面２４８０（たとえばタッチパッドまたは触覚スクリーン）およびカメラ２４７０を備えてよい。プロセッサ２４１０は、システム２４００の一部であってもなくてもよいセンサから受信した信号を処理してよい。センサからの測定値のいくつかは、システム２４００の姿勢またはシステム２４００に接続された他のデバイスの姿勢を計算するために用いられ得る。カメラ２４７０は、画像処理のために環境の画像を捕捉してよい。プロセッサ２４１０は、図１において説明したような前処理および後処理機能も実行してよい。

上述した様々なプロセスを実行するためにプロセッサ２４１０にロードされるプログラムコードは、ストレージデバイス２４４０に格納され、その後、プロセッサ２４１０による実行のためにメモリ２４２０にロードされ得る。本原理の典型的な実施形態によると、プロセッサ（複数も可）２４１０、メモリ２４２０、ストレージデバイス２４４０、およびエンコーダ／デコーダモジュール２４３０の１または複数は、上述したプロセスの実行中、入力映像、ビットストリーム、等式、式、行列、変数、動作、および動作ロジックを含むがこれに限定されない様々な項目の１または複数を格納してよい。

システム２４００は、通信チャネル２４６０を介して他のデバイスとの通信を可能にする通信インタフェース２４５０も含んでよい。通信インタフェース２４５０は、通信チャネル２４６０からのデータを送受信するように構成されたトランシーバを含んでよいが、これに限定されない。通信インタフェースは、モデムまたはネットワークカードを含んでよいがこれに限定されず、通信チャネルは、有線および／または無線媒体に実装され得る。システム２４００の様々な構成要素は、内部バス、ワイヤ、および印刷回路基板を含むがこれに限定されない様々な適切な接続を用いて互いに接続または通信可能に結合され得る。

本原理に係る典型的な実施形態は、プロセッサ２４１０によって実装されるコンピュータソフトウェアによって、またはハードウェアによって、あるいはハードウェアとソフトウェアとの組み合わせによって実行され得る。非限定的な例として、本原理に係る典型的な実施形態は、１または複数の集積回路によって実装され得る。メモリ２４２０は、技術環境に適した任意の種類であってよく、非限定的な例としてたとえば光メモリデバイス、磁気メモリデバイス、半導体ベースのメモリデバイス、固定メモリおよび取外し可能メモリなど任意の適切なデータストレージ技術を用いて実装され得る。プロセッサ２４１０は、技術環境に適した任意の種類であってよく、非限定的な例として、マイクロプロセッサ、汎用コンピュータ、専用コンピュータ、およびマルチコアアーキテクチャに基づいたプロセッサの１または複数を包括してよい。

様々な方法が上述され、方法の各々は、上述した方法を実現するための１または複数のステップまたはアクションを備える。方法の適切な動作のために特定の順序のステップまたはアクションが必要でない限り、特定のステップおよび／またはアクションの順序および／または使用は、修正または結合され得る。

本出願において、たとえばイントラ予測のために用いられる角度およびモードインデックスなど、様々な数値が用いられる。留意すべき点として、特定の値は例示を目的としており、本原理は、これら特定の値に限定されるものではない。

本明細書で説明される実装は、たとえば方法またはプロセス、装置、ソフトウェアプログラム、データストリーム、または信号に実装され得る。単一形式の実装の文脈でしか説明されない（たとえば方法としてのみ説明される）場合でも、説明される特徴の実装は、他の形式（たとえば装置またはプログラム）で実装されてもよい。装置は、たとえば適当なハードウェア、ソフトウェア、およびファームウェアに実装され得る。方法はたとえば、たとえばコンピュータ、マイクロプロセッサ、集積回路、またはプログラマブル論理デバイスを含む、一般に処理デバイスを指すたとえばプロセッサなどの装置に実装され得る。またプロセッサは、たとえばコンピュータ、携帯電話、ポータブル／パーソナルデジタルアシスタント（「ＰＤＡ」）、およびエンドユーザ間での情報の通信を容易にする他のデバイスなどの通信デバイスも含む。

本原理の「１つの実施形態」または「実施形態」または「１つの実装」または「実装」、ならびにそれらの他の変形例への言及は、実施形態に関して説明される特定の特徴、構造、特性などが、本原理の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書を通して様々な箇所に見られる、「１つの実施形態において」または「実施形態において」または「１つの実装において」または「実装において」といった表現、ならびに他の任意の変形例の出現は、必ずしも全てが同じ実施形態を指すわけではない。

また、本出願またはクレームは、様々な情報を「決定すること」に言及し得る。情報を決定することは、たとえば情報を推定すること、情報を計算すること、情報を予測すること、または情報をメモリから取得することの１または複数を含んでよい。

また、本出願またはクレームは、様々な情報に「アクセスすること」に言及し得る。情報にアクセスすることは、たとえば情報を受信すること、情報を（たとえばメモリから）取得すること、情報を格納すること、情報を処理すること、情報を伝送すること、情報を移動すること、情報をコピーすること、情報を消去すること、情報を計算すること、情報を決定すること、情報を予測すること、または情報を推定することの１または複数を含んでよい。

また、本出願またはクレームは、様々な情報を「受信すること」に言及し得る。「受信すること」は、「アクセスすること」と同様、幅広い表現であることが意図される。情報を受信することは、たとえば、情報にアクセスすること、または情報を（たとえばメモリから）取得することの１または複数を含んでよい。また「受信すること」は一般に、たとえば情報を格納すること、情報を処理すること、情報を伝送すること、情報を移動すること、情報をコピーすること、情報を消去すること、情報を計算すること、情報を決定すること、情報を予測すること、情報を推定することなどの動作中に何かと必要とされる。

当業者には明らかであるように、実装は、たとえば格納または伝送され得る情報を搬送するためにフォーマット化された様々な信号を生成してよい。情報はたとえば、方法を実行するための命令、または説明された実装の１つによって生成されたデータを含んでよい。たとえば信号は、説明された実施形態のビットストリームを搬送するためにフォーマット化され得る。そのような信号はたとえば、（たとえばスペクトルの無線周波数部分を用いて）電磁波として、またはベースバンド信号としてフォーマット化され得る。フォーマット化は、たとえばデータストリームを符号化し、符号化されたデータストリームによって搬送波を変調することを含んでよい。信号が搬送する情報はたとえば、アナログまたはデジタル情報であってよい。信号は、既知であるように、様々な有線または無線リンクを介して伝送され得る。信号は、プロセッサ可読媒体に格納され得る。

Claims (16)

1. 映像データを符号化する方法であって、
   ピクチャの非境界ブロックにアクセスすることと、
   前記ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定することであって、前記セット内の前記利用可能なイントラ予測モードの数は、前記ブロックの垂直位置に依存すること（２１２０、２２６０）と、
   前記決定されたイントラ予測モードを用いて、前記ブロックを符号化することと
   を備える方法。
2. 映像データを復号する方法であって、
   ピクチャの非境界ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定することであって、前記セット内の前記利用可能なイントラ予測モードの数は、前記ブロックの垂直位置に依存すること（２１２０、２２６０）と、
   前記決定されたイントラ予測モードを用いて、前記ブロックを復号することと
   を備える方法。
3. 映像データを符号化するための装置であって、少なくとも１つのメモリと、１または複数のプロセッサとを備え、前記１または複数のプロセッサは、
   ピクチャの非境界ブロックにアクセスし、
   前記ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定し、ここで前記セット内の前記利用可能なイントラ予測モードの数は、前記ブロックの垂直位置に依存し、
   前記決定されたイントラ予測モードを用いて、前記ブロックを符号化する
   ように構成される、装置。
4. 映像データを復号するための装置であって、少なくとも１つのメモリと、１または複数のプロセッサとを備え、前記１または複数のプロセッサは、
   ピクチャの非境界ブロックに関する利用可能なイントラ予測モードのセットからイントラ予測モードを決定し、ここで前記セット内の前記利用可能なイントラ予測モードの数は、前記ブロックの垂直位置に依存し、
   前記決定されたイントラ予測モードを用いて、前記ブロックを復号する
   ように構成される、装置。
5. 前記ブロックが第２のブロックよりも前記ピクチャの中心から垂直方向に離れている場合、前記ブロックに関する利用可能なイントラ予測モードの数は、前記第２のブロックに関する利用可能なイントラ予測モードの数よりも小さい、請求項１または２に記載の方法、または請求項３または４に記載の装置。
6. 前記ブロックに関する前記イントラ予測モードは、固定長コードを用いて符号化され、前記固定長コードの長さは、前記セット内の利用可能なイントラ予測モードの数（２２６０）に基づき、前記固定長コードの長さは、前記ブロックの前記垂直位置に依存する、請求項１、２、または５のいずれか１項に記載の方法、または請求項３〜５のいずれか１項に記載の装置。
7. 前記利用可能なイントラ予測モードにおける２つの隣接するイントラ予測モード間の角度差は、前記ブロックの前記位置に基づく、請求項１、２、または５〜６のいずれか１項に記載の方法、または請求項３〜６のいずれか１項に記載の装置。
8. 隣接ブロックのイントラ予測モードに基づいて、前記ブロックに関する第１の最確モードを決定することと、
   前記第１の最確モードに基づいて、前記ブロックに関する第２の最確モードを決定することであって、前記第１の最確モードと前記第２の最確モードとの間の角度差は、前記ブロックの前記位置に基づくことと
   を更に備える、請求項１、２、または５〜７のいずれか１項に記載の方法。
9. 前記１または複数のプロセッサは、
   隣接ブロックのイントラ予測モードに基づいて、前記ブロックに関する第１の最確モードを決定し、
   前記第１の最確モードに基づいて、前記ブロックに関する第２の最確モードを決定する
   ように構成され、前記第１の最確モードと前記第２の最確モードとの間の角度差は、前記ブロックの前記位置に基づく、請求項３〜７のいずれか１項に記載の装置。
10. 前記ブロックに関する前記イントラ予測モードは、前記第１の最確モードおよび前記第２の最確モードの１つであるように選択される、請求項８に記載の方法、または請求項９に記載の装置。
11. 前記ピクチャは第１のブロックおよび第２のブロックを有し、前記第１のブロックに関する利用可能なイントラ予測モードの第１のセットは、前記第２のブロックに関する利用可能なイントラ予測モードの第２のセットとは異なり、前記利用可能なイントラ予測モードの第１のセットにおける２つの隣接するイントラ予測モード間の第１の角度差は、前記利用可能なイントラ予測モードの第２のセットにおける２つの隣接するイントラ予測モード間の第２の角度差と同じである、請求項１、２、または５〜１０のいずれか１項に記載の方法、または請求項３〜８または１０のいずれか１項に記載の装置。
12. 前記ピクチャは第１のブロックおよび第２のブロックを有し、前記第１のブロックに関する利用可能なイントラ予測モードの第１のセットは、利用可能なイントラ予測モードの第２のセットとは異なり、前記第１のブロックに関する前記利用可能なイントラ予測モードの第１のセットは、連続したイントラ予測モードインデックスの第１のセットによって表され、前記第２のブロックに関する前記利用可能なイントラ予測モードの第２のセットは、連続したイントラ予測モードインデックスの第２のセットによって表される、請求項１、２、５〜９、または１１のいずれか１項に記載の方法、または請求項３〜８または１０〜１１のいずれか１項に記載の装置。
13. 前記利用可能なイントラ予測モードの第１のセットおよび前記利用可能なイントラ予測モードの第２のセットにおける同じイントラ予測モードインデックスは、同じイントラ予測モードに対応する、請求項１２に記載の方法、または請求項１２に記載の装置。
14. 前記ブロックに関する前記セット内の利用可能なイントラ予測モードの数を前記ブロックの前記位置に関連付けるためにルックアップテーブルが用いられる、請求項１、２、５〜９、または１１〜１３のいずれか１項に記載の方法、または請求項３〜８または１１〜１３のいずれか１項に記載の装置。
15. 符号化映像を表現するビットストリームであって、
    ピクチャの非境界ブロックを表現する符号化データと、
    前記ブロックに関する利用可能なイントラ予測モードのセットのうちのイントラ予測モードを表現する符号化データと
    を備え、前記セット内の前記利用可能なイントラ予測モードの数は、前記ブロックの垂直位置に依存し、前記ブロックは、前記イントラ予測モードを用いて符号化される、ビットストリーム。
16. １または複数のプロセッサによって実行されると、請求項１、２、５〜９、または１１〜１４のいずれか１項に記載の方法を実行するためのソフトウェアコード命令を備えるコンピュータプログラム製品。

Images