JP7073501B2 - 履歴ベース動きベクトル予測に基づいてビデオ信号を処理するための方法及び装置 - Google Patents

Description

本明細書の実施例は、インター予測（inter prediction）に基づいてビデオ信号を処理するための方法及び装置に関し、特に、履歴ベース動きベクトル予測（history-based motion vector prediction）を用いてインター予測を行うための方法及び装置に関する。

圧縮符号化とは、デジタル化した情報を通信回線を介して送信するか、または記憶（保存）媒体に適した形態で記憶するための一連の信号処理技術を意味する。映像、イメージ、音声などのメディアが圧縮符号化の対象になり得、特に、映像を対象に圧縮符号化を行う技術をビデオ映像圧縮と称する。

次世代ビデオコンテンツは、高解像度（high spatial resolution）、高フレームレート（率）（high frame rate）、および映像表現の高次元化（high dimensionality of scene representation）という特徴を有するようになる。そのようなコンテンツを処理するためには、メモリストレージ（memory storage）、メモリアクセスレート（率）（memory access rate）、および処理電力（processing power）の側面で大幅な増加をもたらすであろう。

したがって、次世代ビデオコンテンツをより効率的に処理するためのコーディングツールをデザインする必要がある。

本明細書の実施例の目的は、ＨＭＶＰ候補をマージ候補リスト（またはＡＭＶＰ候補リスト）に追加するにあたって、予測の効率を高めるための冗長（重複）性チェックに対する制限を提案する。

また、本明細書の実施例の目的は、ＨＭＶＰ候補をマージモード（またはＡＭＶＰモード）に効果的に適用するために、ＨＭＶＰテーブルの大きさを定義する方法を提案する。

本明細書の実施例で解決しようとする技術的課題は、以上で言及した技術的課題に制限されず、言及しないさらに他の技術的課題は、以下の記載から本明細書が属する技術分野で通常の知識を有する者に明確に理解されるべきである。

本明細書の実施例の一様相は、現（現在）ブロックの空間的（spatial）および時間的（temporal）隣接ブロックに基づいて、マージ候補リスト（merge candidate list）を構成する段階と、現ブロックの履歴ベースマージ候補（history based merge candidate）をマージ候補リストに追加する段階と、マージ候補リスト内で現ブロックのインター予測に用いられるマージ候補を指示するマージインデックス（merge index）を獲得する段階と、マージインデックスにより指示されるマージ候補の動き情報に基づいて、現ブロックの予測サンプルを生成する段階と、動き情報に基づいて、履歴ベースマージ候補リスト（history based merge candidate list）をアップデートする段階と、を有し、履歴ベースマージ候補は、マージ候補リストに有されるマージ候補のうち、予め定義されたマージ候補と重複しない動き情報を有する場合、マージ候補リストに追加され得る。

好ましくは、履歴ベースマージ候補リストは、マージ候補リストの最大のマージ候補の数に基づいて決定される大きさを有するように定義され得る。

好ましくは、履歴ベースマージ候補リストは、マージ候補リストの最大のマージ候補の数から１を減算した値の大きさを有するように定義され得る。

好ましくは、履歴ベースマージ候補リストの大きさは、５で定義され得る。

好ましくは、履歴ベースマージ候補は、マージ候補リストに有されるマージ候補のうち、予め定義された特定の数のマージ候補と重複しない動き情報を有する場合、マージ候補リストに追加され得る。

好ましくは、履歴ベースマージ候補は、マージ候補リストに有される特定の空間のマージ候補と重複しない動き情報を有する場合、マージ候補リストに追加され得る。

好ましくは、履歴ベースマージ候補は、履歴ベースマージ候補リスト内で予め定義された特定の数の候補から導出（誘導）され得る。

本明細書の実施例の別の一様相は、インター予測に基づいてビデオ信号を処理する装置であって、ビデオ信号を記憶するメモリと、メモリと結合したプロセッサと、を有し、プロセッサは、現ブロックの空間的（spatial）および時間的（temporal）隣接ブロックに基づいてマージ候補リスト（merge candidate list）を構成し、現ブロックの履歴ベースマージ候補（history based merge candidate）をマージ候補リストに追加し、マージ候補リスト内で現ブロックのインター予測に用いられるマージ候補を指示するマージインデックス（merge index）を獲得し、マージインデックスにより指示されるマージ候補の動き情報に基づいて現ブロックの予測サンプルを生成し、動き情報に基づいて履歴ベースマージ候補リスト（history based merge candidate list）をアップデートし、履歴ベースマージ候補は、マージ候補リストに有されるマージ候補のうち、予め定義されたマージ候補と重複しない動き情報を有する場合、マージ候補リストに追加され得る。

本明細書の実施例によれば、マージ候補リスト（またはＡＭＶＰ候補リスト）に追加するための冗長性チェックを制限することによって、冗長性チェックによる複雑度を改善し、これを通じて圧縮性能を向上させることができる。

また、本明細書の実施例によれば、ＨＭＶＰテーブルの大きさを定義することによって、ＨＭＶＰテーブルの記憶によるメモリの負担を減らすことができる。

本発明で得られる効果は、以上で言及した効果に制限されず、言及しないさらに他の効果は、以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解されるべきである。

本明細書の実施例にかかるビデオコーディングシステムの例を示す図である。 本明細書の実施例にかかるビデオ／イメージ信号のエンコーディングのためのエンコード装置の概略ブロック図である。 本明細書の実施例であって、映像信号のデコーディングのためのデコード装置の概略ブロック図である。 本明細書の実施例にかかるコンテンツストリーミングシステムの構造図の例を示す図である。 本明細書の実施例にかかるビデオ信号を処理するための装置のブロック図の例を示す図である。 本明細書の実施例にかかるブロックの分割構造の例であって、ＱＴ（Quad Tree、以下「ＱＴ」と称される）によるブロックの分割構造の例を示す図である。 本明細書の実施例にかかるブロックの分割構造の例であって、ＢＴ（Binary Tree、以下「ＢＴ」と称される）によるブロックの分割構造の例を示す図である。 本明細書の実施例にかかるブロックの分割構造の例であって、ＴＴ（Ternary Tree、以下「ＴＴ」と称される）によるブロックの分割構造の例を示す図である。 本明細書の実施例にかかるブロックの分割構造の例であって、ＡＴ（Asymmetric Tree、以下「ＡＴ」と称される）によるブロックの分割構造の例を示す図である。 インター予測に基づくビデオ／映像のエンコーディング手続、およびエンコード装置内のインター予測部を示す図である。 インター予測に基づくビデオ／映像のエンコーディング手続、およびエンコード装置内のインター予測部を示す図である。 インター予測に基づくビデオ／映像のデコーディング手続、およびデコード装置内のインター予測部を示す図である。 インター予測に基づくビデオ／映像のデコーディング手続、およびデコード装置内のインター予測部を示す図である。 現ブロックに対する空間的マージ候補の構成の例を示す図である。 本明細書の実施例にかかるマージ候補リストの構成のフローチャートの例を示す図である。 予測候補リスト（ＭＶＰ候補リスト）を構成するフローチャートの例を示す図である。 本発明の実施例にかかる動きモデル（motion models）の例を示す図である。 本発明の実施例にかかるアフィン動き予測のための制御点動きベクトルの例を示す図である。 本発明の実施例にかかるアフィン動き予測が適用されたブロックの各サブブロック別の動きベクトルの例を示す図である。 本発明の実施例にかかるアフィンマージモード（affine merge mode）でアフィン動き予測に使用される周辺ブロックの例を示す図である。 本発明の実施例にかかるアフィン動き予測が適用された周辺ブロックを使用し、アフィン動き予測が行われるブロックの例を示す図である。 本発明の実施例にかかる周辺のアフィン符号化ブロックを用いて、マージ候補リストを生成する方法を説明する図である。 本発明の実施例にかかるアフィン予測で符号化された周辺ブロックを使用してアフィンマージ候補リストを構成する方法を説明する図である。 本発明の実施例にかかるアフィン予測で符号化された周辺ブロックを使用してアフィンマージ候補リストを構成する方法を説明する図である。 本発明が実施例にかかるアフィンインターモード（affine inter mode）でアフィン動き予測に使用される周辺ブロックの例を示す図である。 本発明が実施例にかかるアフィンインターモード（affine inter mode）でアフィン動き予測が使用される周辺ブロックの例を示す図である。 本発明が実施例にかかるアフィンインターモード（affine inter mode）で周辺ブロックの動き情報を用いて動きベクトル候補を導出する方法を例示する図である。 本発明が実施例にかかるアフィンインターモード（affine inter mode）で周辺ブロックの動き情報を用いて動きベクトル候補を導出（誘導）する方法を例示する図である。 本発明の実施例にかかるサブブロック単位のアフィン動きベクトルフィールドを導出する方法の一例を示す図である。 本明細書の実施例にかかるＨＭＶＰを記憶する方法を説明するフローチャートである。 本明細書の実施例にかかる非制限的ＦＩＦＯ方式で動作するＨＭＶＰテーブルを説明する図である。 本明細書の実施例にかかる制限的ＦＩＦＯ方式で動作するＨＭＶＰテーブルを説明する図である。 本明細書の実施例にかかるＨＭＶＰ ＬＵＴおよびロングタームＨＭＶＰ ＬＵＴを例示する図である。 本明細書の実施例にかかるＨＭＶＰ ＬＵＴをアップデートする方法の一例を示す図である。 本明細書の実施例にかかる淘汰（プルーニング）チェックの対象になるＨＭＶＰ候補の数を制限する方法を例示する図である。 本明細書の実施例にかかる淘汰チェック実行方法の一例を示すフローチャートである。 本明細書の一実施例にかかる互いに異なる参照ピクチャを参照する動きベクトルを用いてＨ－ＳＴＭＶＰ候補を導出する方法を説明する図である。 本明細書の実施例にかかる継承（相続）されたアフィンＨＭＶＰ候補を導出するためのブロックの位置を例示する図である。 本明細書の実施例にかかるアフィンマージリストまたはアフィンＡＭＶＰリストを例示する図である。 本発明が適用される実施例にかかる履歴ベース動きベクトル予測に基づいて、ビデオ信号を処理する方法を例示するフローチャートである。 デジタル機器を含むサービスシステム（service system）の一例を概略的に示す図である。 デジタル機器の一実施例を説明するために示す構成のブロック図である。 デジタル機器の別の実施例を説明するために示す構成のブロック図である。 デジタル機器のさらに他の実施例を説明するために示す構成のブロック図である。 図３９乃至図４１の制御部の詳細構成の一実施例を説明するために示す構成のブロック図である。 一実施例にかかるデジタル機器のスクリーンがメイン映像（main image）と補助映像（sub image）とを同時に表示（ディスプレイ）する一例を示す図である。

本発明に関する理解を助けるために詳細な説明の一部に含まれる、添付図は、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的特徴を説明する。

以下、本明細書にかかる好ましい実施形態を添付図を参照として詳細に説明する。添付図と共に以下に開示される詳細な説明は、本明細書の例示的な実施形態を説明しようとするものであり、本明細書が実施され得る唯一の実施形態を示そうとするものではない。以下の詳細な説明は、本明細書の完全な理解を提供するために具体的な細部事項を含む。しかしながら、当業者は、本明細書がこのような具体的な細部事項がなくても実施され得ることを知る。

いくつかの場合、本明細書の概念が曖昧になることを避けるために、公知の構造および装置は省略されるか、各構造および装置の中核機能を中心としたブロック図の形式で示し得る。

また、本明細書で使用される用語は、できる限り現在広く使用される一般的な用語を選択しているが、特定の場合は、出願人が任意に選定した用語を使用して説明する。そのような場合は、該当部分の詳細な説明でその意味を明確に記載するので、本明細書の説明で使用された用語の名称だけで単純に解釈されてはならず、その該当用語の意味まで把握して解釈されるべきであることを明らかにしておく。

以下の説明で使用される特定の用語は、本明細書の理解を助けるために提供されたものであり、このような特定の用語の使用は、本明細書の技術的思想を外れない範囲で他の形態に変更され得る。例えば、信号、データ、サンプル、ピクチャ、スライス、タイル、フレーム、ブロックの場合、各コーディング過程で適切に代替して解釈され得る。

以下、本明細書における「処理ユニット」は、予測、変換および／または量子化などのエンコーディング／デコーディングの処理過程が行われる単位を意味する。また、処理ユニットは、輝度（luma）成分に対する単位と、色差（chroma）成分に対する単位と、を含む意味として解釈され得る。例えば、処理ユニットは、ブロック（block）、コーディングユニット（Coding Unit、ＣＵ）、予測ユニット（Prediction Unit、ＰＵ）、または変換ブロック（Transform Unit、ＴＵ）に該当し得る。

また、処理ユニットは、輝度成分に対する単位または色差成分に対する単位として解釈され得る。例えば、処理ユニットは、輝度成分に対するＣＴＢ（Coding Tree Block）、ＣＢ（Coding Block）、ＰＵまたはＴＢ（Transform Block）に該当し得る。あるいは、処理ユニットは、色差成分に対するＣＴＢ、ＣＢ、ＰＵまたはＴＢに該当し得る。また、これに限定されるわけではなく、処理ユニットは、輝度成分に対する単位と色差成分に対する単位とを含む意味として解釈されることもある。

また、処理ユニットは、必ずしも正方形のブロックに限定されるわけではなく、３つ以上の頂点を有する多角形の形態で構成されることもある。

また、以下、本明細書で、ピクセル、画素、または係数（変換係数または１次変換を経た変換係数）は、サンプルと通称される。また、サンプルを利用するというのは、ピクセル値、画素値、または係数（変換係数または１次変換を経た変換係数）などを利用することを意味し得る。

図１は、本明細書の実施例にかかるビデオコーディングシステムの例を示す。

ビデオコーディングシステムは、ソースデバイス１０および受信デバイス２０を含むことができる。ソースデバイス１０は、エンコードされたビデオ／映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して受信デバイス２０に伝達することができる。

ソースデバイス１０は、ビデオソース１１、エンコード装置１２、送信器１３を含み得る。受信デバイス２０は、受信器２１、デコード装置２２およびレンダラ２３を含み得る。エンコード装置１０は、ビデオ／映像のエンコード装置と呼ばれ、デコード装置２０は、ビデオ／映像のデコード装置と呼ばれる。送信器１３は、エンコード装置１２に含まれ得る。受信器２１は、デコード装置２２に含まれ得る。レンダラ２３は、ディスプレイ部を含んでもよく、ディスプレイ部は、別のデバイスまたは外部のコンポーネントで構成されてもよい。

ビデオソースは、ビデオ／映像のキャプチャ、合成または生成過程などを介してビデオ／映像を獲得することができる。ビデオソースは、ビデオ／映像のキャプチャデバイスおよび／またはビデオ／映像の生成デバイスを含み得る。ビデオ／映像のキャプチャデバイスは、例えば、１つまたは複数のカメラ、以前にキャプチャされたビデオ／映像を含むビデオ／映像のアーカイブなどを含み得る。ビデオ／映像の生成デバイスは、例えば、コンピュータ、タブレット、およびスマートフォンなどを含んでもよく（電子的に）ビデオ／映像を生成することができる。例えば、コンピュータなどを介して仮想のビデオ／映像が生成され得、この場合、関連データが生成される過程は、ビデオ／映像のキャプチャ過程と代わることができる。

エンコード装置１２は、入力ビデオ／映像をエンコードすることができる。エンコード装置１２は、圧縮およびコーディングの効率のために予測、変換、量子化等一連の手続を行うことができる。エンコードされたデータ（エンコードされたビデオ／映像情報）は、ビットストリーム（bit stream）の形態で出力されることができる。

送信部１３は、ビットストリームの形態で出力されたエンコードされたビデオ／映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して、受信デバイスの受信部に伝達することができる。デジタル記憶媒体は、ＵＳＢ（Universal Serial Bus）、ＳＤ（Secure Digital）、ＣＤ（Compact Disk）、ＤＶＤ（Digital Video Disk）、ブルーレイ（blu-ray）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）などの多様な記憶媒体を含み得る。送信部１３は、予め決められたファイルフォーマットを介してメディアファイルを生成するためのエレメントを含んでもよく、放送／通信ネットワークを介した送信のためのエレメントを含んでもよい。受信器２１は、ビットストリームを抽出し、デコード装置２２に伝達することができる。

デコード装置２２は、エンコード装置１２の動作に対応する逆量子化、逆変換、予測等の一連の手続を行い、ビデオ／映像をデコードすることができる。

レンダラ２３は、デコードされたビデオ／映像をレンダリングすることができる。レンダリングされたビデオ／映像は、ディスプレイ部を介して表示されることができる。

図２は、本明細書の実施例にかかるビデオ／イメージ信号のエンコーディングのためのエンコード装置の概略ブロック図を示す。

図２を参照すると、エンコード装置１００は、映像分割部１１０、減算部１１５、変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０、加算部１５５、フィルタリング部１６０、メモリ１７０、インター予測部１８０、イントラ予測部１８５、およびエントロピエンコーディング部１９０を含み得る。インター予測部１８０およびイントラ予測部１８５は、予測部と通称され得る。すなわち、予測部は、インター予測部１８０およびイントラ予測部１８５を含み得る。変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０は、残差（residual）処理部に含まれ得る。残差処理部は、減算部１１５をさらに含んでもよい。前述した映像分割部１１０、減算部１１５、変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０、加算部１５５、フィルタリング部１６０、インター予測部１８０、イントラ予測部１８５、およびエントロピエンコーディング部１９０は、実施例によって（かかって）１つのハードウェアコンポーネント（例えば、エンコーダまたはプロセッサ）によって構成され得る。また、メモリ１７０は、実施例によって１つのハードウェアコンポーネント（例えば、メモリまたはデジタル記憶媒体）によって構成され得、メモリ１７０は、ＤＰＢ（Decoded Picture Buffer）１７５を含み得る。

映像分割部１１０は、エンコード装置１００に入力された入力映像（または、ピクチャ、フレーム）を、１つまたは複数の処理ユニット（processing unit）に分割することができる。一例として、処理ユニットは、コーディングユニット（ＣＵ）と呼ばれる。この場合、コーディングユニットは、コーディングツリーユニット（Coding Tree Unit、ＣＴＵ）または最大のコーディングユニット（Largest Coding Unit、ＬＣＵ）からＱＴＢＴ（Quad-Tree Binary-Tree）構造によって、再帰的に（recursively）分割されることができる。例えば、１つのコーディングユニットは、四分木（クアッドツリー）構造および／または二分木（バイナリツリー）構造に基づいて、下位（deeper）デプスの複数のコーディングユニットに分割され得る。この場合、例えば、四分木構造が先に適用され、二分木構造が後に適用され得る。あるいは、二分木構造が先に適用されることもある。これ以上分割されない最終的なコーディングユニットに基づいて、本明細書にかかるコーディング手続が行われる。この場合、映像の特性によるコーディングの効率などに基づいて、最大のコーディングユニットが直ぐに最終的なコーディングユニットとして使用され得、あるいは必要に応じて、コーディングユニットは再帰的に（recursively）より下位デプスのコーディングユニットに分割され、最適なサイズのコーディングユニットが最終的なコーディングユニットとして使用され得る。ここで、コーディング手続というのは、後述する予測、変換、および復元などの手続を含み得る。別の例として、処理ユニットは、予測ユニット（ＰＵ）または変換ユニット（ＴＵ）をさらに含み得る。この場合、予測ユニットおよび変換ユニットは、それぞれ前述した最終的なコーディングユニットから分割またはパーティショニングされ得る。上記予測ユニットは、サンプル予測の単位であってもよく、上記変換ユニットは、変換係数を導出する単位および／または変換係数から残差信号（residual signal）を導出する単位であってもよい。

ユニットは、場合によって、ブロック（block）または領域（area）などの用語と混用してもよい。一般的な場合、ＭｘＮのブロックは、Ｍ個の列とＮ個の行とからなるサンプルまたは変換係数（transform coefficient）の集合を表し得る。サンプルは、一般的にピクセルまたはピクセルの値を表し得、輝度（luma）成分のピクセル／ピクセル値のみを表すこともあり、彩度（chroma）成分のピクセル／ピクセル値のみを表すこともある。サンプルは、１つのピクチャ（または映像）をピクセル（pixel）またはペル（pel）に対応する用語として使用され得る。

エンコード装置１００は、入力映像信号（オリジナル（原本）ブロック、オリジナルサンプルアレイ）から、インター予測部１８０またはイントラ予測部１８５から出力された予測信号（予測されたブロック、予測サンプルアレイ）を減算して残差信号（残差（残余）ブロック、残差サンプルアレイ）を生成することができ、生成された残差信号は、変換部１２０へ送信される。この場合、示すように、エンコード装置１００内で入力映像信号（オリジナルブロック、オリジナルサンプルアレイ）から予測信号（予測ブロック、予測サンプルアレイ）を減算するユニットは、減算部１１５と呼ばれる。予測部は、処理対象のブロック（以下、現ブロックという）に対する予測を行い、現ブロックに対する予測サンプルを含む予測されたブロック（predicted block）を生成することができる。予測部は、ブロックもしくはＣＵ単位でイントラ予測が適用されるか、またはインター予測が適用されるかを決定できる。予測部は、各予測モードに関する説明で後述するように、予測モード情報のように予測に関する多様な情報を生成してエントロピエンコーディング部１９０へ伝達することができる。予測に関する情報は、エントロピエンコーディング部１９０でエンコードされ、ビットストリームの形態で出力されることができる。

イントラ予測部１８５は、現ピクチャ内のサンプルを参照して現ブロックを予測することができる。参照されるサンプルは、予測モードに応じて、上記現ブロックの周辺（neighbor）に位置してもよく、あるいは離れて位置してもよい。イントラ予測で予測モードは、複数の非方向性モードと複数の方向性モードとを含み得る。非方向性モードは、例えば、ＤＣモードおよび平面モード（Ｐｌａｎａｒモード）を含み得る。方向性モードは、予測方向の細密な程度によって、例えば、３３個の方向性予測モードまたは６５個の方向性予測モードを含み得る。ただし、これは例であって、設定によってそれ以上またはそれ以下の数の方向性予測モードが使用され得る。イントラ予測部１８５は、周辺ブロックに適用された予測モードを用いて、現ブロックに適用される予測モードを決定することもできる。

インター予測部１８０は、参照ピクチャ上で動きベクトルにより特定される参照ブロック（参照サンプルアレイ）に基づき、現ブロックに対する予測されたブロックを導出することができる。この際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報をブロック、サブブロックまたはサンプル単位で予測することができる。動き情報は、動きベクトルおよび参照ピクチャのインデックスを含み得る。動き情報は、インター予測方向（Ｌ０予測、Ｌ１予測、Ｂｉ予測など）の情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック（spatial neighboring block）と、参照ピクチャに存在する時間的周辺ブロック（temporal neighboring block）と、を含み得る。参照ブロックを含む参照ピクチャと時間的周辺ブロックを含む参照ピクチャとは、同一であってもよく、異なってもよい。時間的周辺ブロックは、同位置の（コロケート）参照ブロック（collocated reference block）、同位置のＣＵ（ｃｏｌＣＵ）などの名称で呼ばれ、時間的周辺ブロックを含む参照ピクチャは、同位置のピクチャ（collocated picture、ｃｏｌＰｉｃ）とも呼ばれる。例えば、インター予測部１８０は、周辺ブロックに基づいて動き情報の候補リストを構成し、現ブロックの動きベクトルおよび／または参照ピクチャのインデックスを導出するために、どの候補が使用されるかを指示する情報を生成することができる。様々な予測モードに基づいてインター予測が行われ、例えば、スキップモードおよびマージモードの場合に、インター予測部１８０は、周辺ブロックの動き情報を現ブロックの動き情報として利用することができる。スキップモードの場合、マージモードと異なり、残差信号が送信されないことがある。動きベクトル予測（Motion Vector Prediction、ＭＶＰ）モードの場合、周辺ブロックの動きベクトルを動きベクトル予測子（motion vector predictor）として利用し、動きベクトル差分（motion vector difference）をシグナリングすることによって、現ブロックの動きベクトルを指示することができる。

インター予測部１８０またはイントラ予測部１８５を介して生成された予測信号は、復元信号を生成するために利用されるか、残差信号を生成するために利用されることができる。

変換部１２０は、残差信号に変換技法を適用して変換係数（transform coefficients）を生成することができる。例えば、変換技法は、ＤＣＴ（Discrete Cosine Transform）、ＤＳＴ（Discrete Sine Transform）、ＫＬＴ（Karhunen-Loeve transform）、ＧＢＴ（Graph-Based Transform）、またはＣＮＴ（Conditionally Non-linear Transform）のうちの少なくとも１つを含んでもよい。ここで、ＧＢＴは、ピクセル間の関係情報をグラフで表現する際、このグラフから得られた変換を意味する。ＣＮＴは、以前に復元された全てのピクセル（all previously reconstructed pixel）を利用して予測信号を生成し、それに基づいて獲得される変換を意味する。また、変換過程は、正方形の同じサイズを有するピクセルブロックに適用されてもよく、正方形ではない可変サイズのブロックにも適用されてもよい。

量子化部１３０は、変換係数を量子化してエントロピエンコーディング部１９０に送信し、エントロピエンコーディング部１９０は、量子化された信号（量子化された変換係数に関する情報）をエンコードしてビットストリームに出力することができる。量子化された変換係数に関する情報は、残差情報と呼ばれる。量子化部１３０は、係数のスキャン順序（scan order）に基づいてブロックの形態の量子化された変換係数を１次元のベクトルの形態で再整列することができ、１次元のベクトルの形態の量子化された変換係数に基づいて上記量子化された変換係数に関する情報を生成することもできる。エントロピエンコーディング部１９０は、例えば、指数ゴロム（exponential Golomb）、ＣＡＶＬＣ（Context-Adaptive Variable Length Coding）、ＣＡＢＡＣ（Context-Adaptive Binary Arithmetic Coding）などの多様なエンコード方法を行うことができる。エントロピエンコーディング部１９０は、量子化された変換係数以外のビデオ／イメージの復元に必要な情報（例えば、シンタックス要素（syntax elements）の値など）を共に、または別にエンコードすることもできる。エンコードされた情報（例えば、ビデオ／映像の情報）は、ビットストリームの形態でＮＡＬ（Network Abstraction Layer）ユニット単位で送信または記憶されることができる。ビットストリームは、ネットワークを介して送信されることができ、またはデジタル記憶媒体に記憶されることができる。ここで、ネットワークは、放送網および／または通信網などを含んでもよく、デジタル記憶媒体は、ＵＳＢ、ＳＤ、ＣＤ、ＤＶＤ、ブルーレイ、ＨＤＤ、ＳＳＤなどの多様な記憶媒体を含んでもよい。エントロピエンコーディング部１９０から出力された信号を送信する送信部（図示せず）および／もしくは記憶する記憶部（図示せず）は、エンコード装置１００の内／外部のエレメントとして構成されてもよく、または送信部は、エントロピエンコーディング部１９０の構成要素であってもよい。

量子化部１３０から出力された量子化された変換係数は、予測信号を生成するために利用されることができる。例えば、量子化された変換係数に対して、ループ内の逆量子化部１４０および逆変換部１５０を介して逆量子化および逆変換を適用することによって、残差信号が復元されることができる。加算部１５５は、復元された残差信号をインター予測部１８０またはイントラ予測部１８５から出力された予測信号に加えることによって、復元（reconstructed）信号（復元ピクチャ、復元ブロック、復元サンプルアレイ）を生成すことができる。スキップモードが適用された場合のように、処理対象のブロックに対する残差がない場合、予測されたブロックは、復元ブロックとして使用されることができる。加算部１５５は、復元部または復元ブロック生成部と称される。復元信号は、現ピクチャ内の次の処理対象のブロックのイントラ予測のために使用されることができ、後述するようにフィルタリングを経て、次のピクチャのインター予測のために使用されることもできる。

フィルタリング部１６０は、復元信号にフィルタリングを適用し、主観的／客観的画質を向上させることができる。例えば、フィルタリング部１６０は、復元ピクチャに多様なフィルタリング方法を適用して、修正された（modified）復元ピクチャを生成することができ、修正された復元ピクチャを復号ピクチャバッファ１７０に送信することができる。多様なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット（sample adaptive offset）、適応ループフィルタ（adaptive loop filter）、両方向フィルタ（bilateral filter）を含み得る。フィルタリング部１６０は、各フィルタリング方法に関する説明で後述するように、フィルタリングに関する多様な情報を生成してエントロピエンコーディング部１９０へ伝達することができる。フィルタリングに関する情報は、エントロピエンコーディング部１９０でエンコードされてビットストリームの形態で出力されることができる。

復号ピクチャバッファ１７０に送信された修正された復元ピクチャは、インター予測部１８０で参照ピクチャとして使用されることができる。エンコード装置１００は、これを介して、インター予測が適用される場合、エンコード装置１００およびデコード装置２００における予測のミスマッチを避けることができ、符号化の効率も向上させることができる。

復号ピクチャバッファ１７０は、修正された復元ピクチャをインター予測部１８０における参照ピクチャとして使用するために記憶することができる。

図３は、本明細書の実施例として、映像信号のデコーディングのためのデコード装置の概略ブロック図を示す。

図３を参照すると、デコード装置２００は、エントロピデコーディング部２１０、逆量子化部２２０、逆変換部２３０、加算部２３５、フィルタリング部２４０、メモリ２５０、インター予測部２６０、およびイントラ予測部２６５を含んで構成されることができる。インター予測部２６０およびイントラ予測部２６５は、予測部と通称され得る。すなわち、予測部は、インター予測部１８０およびイントラ予測部１８５を含み得る。逆量子化部２２０および逆変換部２３０は、残差処理部と通称され得る。すなわち、残差処理部は、逆量子化部２２０および逆変換部２３０を含むことができる。エントロピデコーディング部２１０、逆量子化部２２０、逆変換部２３０、加算部２３５、フィルタリング部２４０、インター予測部２６０、およびイントラ予測部２６５は、実施例によって１つのハードウェアコンポーネント（例えば、デコーダまたはプロセッサ）により構成されることができる。また、復号ピクチャバッファ２５０は、実施例によって１つのハードウェアコンポーネント（例えば、メモリまたはデジタル記憶媒体）によって実現されることができる。また、メモリ２５０は、ＤＰＢ１７５を含むことができ、デジタル記憶媒体によって構成されることもできる。

ビデオ／イメージの情報を含むビットストリームが入力されると、デコード装置２００は、図２のエンコード装置１００でビデオ／イメージの情報が処理されたプロセスに対応し、映像を復元することができる。例えば、デコード装置２００は、エンコード装置１００で適用された処理ユニットを利用してデコーディングを行うことができる。したがって、デコーディングの際の処理ユニットは、例えば、コーディングユニットであってもよく、コーディングユニットは、コーディングツリーユニットまたは最大のコーディングユニットから四分木構造および／または二分木構造に従って分割されることができる。また、デコード装置２００を介してデコーディングおよび出力された復元映像信号は、再生装置を介して再生されることができる。

デコード装置２００は、図２のエンコード装置１００から出力された信号をビットストリームの形態で受信することができ、受信した信号は、エントロピデコーディング部２１０を介してデコードされることができる。例えば、エントロピデコーディング部２１０は、ビットストリームをパージングして、映像復元（またはピクチャ復元）に必要な情報（例えば、ビデオ／映像の情報）を導出することができる。例えば、エントロピデコーディング部２１０は、指数ゴロム符号化、ＣＡＶＬＣまたはＣＡＢＡＣなどのコーディング方法に基づいてビットストリーム内の情報をデコードし、映像の復元に必要なシンタックスエレメントの値、残差に関する変換係数の量子化された値を出力することができる。より詳細には、ＣＡＢＡＣエントロピデコード方法は、ビットストリームで各構文要素に該当するビン（bin）を受信し、デコーディング対象の構文要素情報ならびに周辺およびデコーディング対象のブロックのデコーディング情報、または以前の段階でデコードされたシンボル／ビンの情報を利用してコンテキスト（context）モデルを決定し、決定されたコンテキストモデルによってビンの発生確率を予測し、ビンの算術復号（デコーディング）（arithmetic decoding）を行い、各構文要素の値に該当するシンボルを生成することができる。この際、ＣＡＢＡＣエントロピデコード方法は、コンテキストモデルの決定後、次のシンボル／ビンのコンテキストモデルのためにデコードされたシンボル／ビンの情報を利用してコンテキストモデルをアップデートすることができる。エントロピデコーディング部２１０でデコードされた情報のうちの予測に関する情報は、予測部（インター予測部２６０およびイントラ予測部２６５）に提供され、エントロピデコーディング部２１０でエントロピデコーディングが行われた残差値、すなわち、量子化された変換係数および関連のパラメータ情報は、逆量子化部２２０に入力されることができる。また、エントロピデコーディング部２１０でデコードされた情報のうちのフィルタリングに関する情報は、フィルタリング部２４０に提供されることができる。一方、エンコード装置１００から出力された信号を受信する受信部（図示せず）が、デコード装置２００の内／外部のエレメントとしてさらに構成されることができ、または、受信部は、エントロピデコーディング部２１０の構成要素であってもよい。

逆量子化部２２０では、量子化された変換係数を逆量子化することによって変換係数を出力することができる。逆量子化部２２０は、量子化された変換係数を２次元のブロックの形態で再整列することができる。この場合、エンコード装置１００で行われた係数のスキャン順序に基づいて再整列が行われ得る。逆量子化部２２０は、量子化パラメータ（例えば、量子化ステップサイズ情報）を利用して量子化された変換係数に対する逆量子化を行い、変換係数（transform coefficient）を獲得することができる。

逆変換部２３０は、変換係数に対する逆変換を適用することによって残差信号（残差ブロック、残差サンプルアレイ）を出力することができる。

予測部は、現ブロックに対する予測を行い、現ブロックに対する予測サンプルを含む予測されたブロック（predicted block）を生成することができる。予測部は、エントロピデコーディング部２１０から出力された予測に関する情報に基づいて、現ブロックにイントラ予測が適用されるか、またはインター予測が適用されるかを決定することができ、具体的なイントラ／インター予測モードを決定することができる。

イントラ予測部２６５は、現ピクチャ内のサンプルを参照することによって現ブロックを予測することができる。参照されるサンプルは、予測モードに応じて現ブロックの周辺（neighbor）に位置してもよく、または離隔して位置してもよい。イントラ予測における予測モードは、複数の非方向性モードおよび複数の方向性モードを含むことができる。イントラ予測部２６５は、周辺ブロックに適用された予測モードを利用して、現ブロックに適用される予測モードを決定することもできる。

インター予測部２６０は、参照ピクチャ上で動きベクトルにより特定される参照ブロック（参照サンプルアレイ）に基づき、現ブロックに対する予測されたブロックを導出することができる。この際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報をブロック、サブブロック、またはサンプル単位で予測することができる。動き情報は、動きベクトルおよび参照ピクチャのインデックスを含むことができる。動き情報は、インター予測方向（Ｌ０予測、Ｌ１予測、Ｂｉ予測など）に関する情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック（spatial neighboring block）と参照ピクチャに存在する時間的周辺ブロック（temporal neighboring block）とを含み得る。例えば、インター予測部２６０は、周辺ブロックに基づいて動き情報の候補リストを構成し、受信した候補選択情報に基づいて、現ブロックの動きベクトルおよび／または参照ピクチャのインデックスを導出することができる。多様な予測モードに基づいてインター予測が行われ得、予測に関する情報は、現ブロックに対するインター予測のモードを指示する情報を含むことができる。

加算部２３５は、獲得された残差信号をインター予測部２６０またはイントラ予測部２６５から出力された予測信号（予測されたブロック、予測サンプルアレイ）に加えることによって、復元信号（復元ピクチャ、復元ブロック、復元サンプルアレイ）を生成することができる。スキップモードが適用された場合のように、処理対象のブロックに対する残差がない場合、予測されたブロックは、復元ブロックとして使用されることができる。

加算部２３５は、復元部または復元ブロック生成部と呼ばれる。生成された復元信号は、現ピクチャ内の次の処理対象のブロックのイントラ予測のために使用されることができ、後述するように、フィルタリングを経て次のピクチャのインター予測のために使用されることもできる。

フィルタリング部２４０は、復元信号にフィルタリングを適用することによって、主観的／客観的画質を向上させることができる。例えば、フィルタリング部２４０は、復元ピクチャに多様なフィルタリング方法を適用し、修正された（modified）復元ピクチャを生成することができ、修正された復元ピクチャを復号ピクチャバッファ２５０に送信することができる。多様なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット（Sample Adaptive Offset、ＳＡＯ）、適応ループフィルタ（Adaptive Loop Filter、ＡＬＦ）、両方向フィルタ（bilateral filter）などを含み得る。

復号ピクチャバッファ２５０に送信された修正された復元ピクチャは、インター予測部２６０により参照ピクチャとして使用されることができる。

本明細書において、エンコード装置１００のフィルタリング部１６０、インター予測部１８０、およびイントラ予測部１８５で説明された実施例は、それぞれデコード装置のフィルタリング部２４０、インター予測部２６０、およびイントラ予測部２６５にも同一または対応するように適用されることができる。

図４は、本明細書の実施例にかかるコンテンツストリーミングシステムの構造図の例を示す。

本明細書が適用されるコンテンツストリーミングシステムは、概してエンコードサーバ４１０、ストリーミングサーバ４２０、ウェブサーバ４３０、メディアストレージ４４０、ユーザ装置４５０、およびマルチメディア入力装置４６０を含むことができる。

エンコードサーバ４１０は、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置から入力されたコンテンツをデジタルデータに圧縮してビットストリームを生成し、これをストリーミングサーバ４２０に送信することができる。別の例として、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置４６０がビットストリームを直接生成する場合、エンコードサーバ４１０は省略され得る。

ビットストリームは、本明細書が適用されるエンコード方法またはビットストリームの生成方法により生成されることができ、ストリーミングサーバ４２０は、ビットストリームを送信または受信する過程で、一時的にビットストリームを記憶することができる。

ストリーミングサーバ４２０は、ウェブサーバ４３０を介したユーザの要求（要請）に基づいて、マルチメディアデータをユーザ装置４５０に送信し、ウェブサーバ４３０は、ユーザにどのようなサービスがあるかを知らせる媒介体の役割を担う。ユーザがウェブサーバ４３０に希望するサービスを要求すると、ウェブサーバ４３０は、これをストリーミングサーバ４２０に伝達し、ストリーミングサーバ４２０は、ユーザにマルチメディアデータを送信する。この際、コンテンツストリーミングシステムは、別途の制御サーバを含むことができ、この場合、制御サーバは、コンテンツストリーミングシステム内の各装置間の命令／応答を制御する役割を担う。

ストリーミングサーバ４２０は、メディアストレージ４４０および／またはエンコードサーバ４１０からコンテンツを受信することができる。例えば、ストリーミングサーバ４２０は、エンコードサーバ４１０からコンテンツをリアルタイムで受信することができる。この場合、円滑なストリーミングサービスを提供するために、ストリーミングサーバ４２０は、ビットストリームを一定時間の間記憶することができる。

例えば、ユーザ装置４５０は、携帯電話、スマートフォン（smart phone）、ラップトップパソコン（laptop computer）、デジタル放送用端末機、ＰＤＡ（Personal Digital Assistants）、ＰＭＰ（Portable Multimedia Player）、ナビゲーション、スレートＰＣ（slate PC）、タブレットＰＣ（tablet PC）、ウルトラブック（ultrabook）、ウェアラブルデバイス（wearable device）、例えば、腕時計（ウォッチ）型端末機（smartwatch）、眼鏡（ガラス）型端末機（smart glass）、ＨＭＤ（Head Mounted Display）、デジタルＴＶ、デスクトップコンピュータ、デジタルサイネージを含み得る。

コンテンツストリーミングシステム内の各サーバは、分散サーバとして運用されることができ、この場合、各サーバで受信するデータは、分散処理されることができる。

図５は、本明細書の実施例にかかるビデオ信号を処理するための装置のブロック図の例を示す。図５のビデオ信号処理装置は、図２のエンコード装置１００または図３のデコード装置２００に該当し得る。

本明細書の実施例にかかるビデオ信号処理装置５００は、ビデオ信号を記憶するメモリ５２０と、上記メモリと結合されつつ、ビデオ信号を処理するプロセッサ５１０と、を含み得る。

本明細書の実施例にかかるプロセッサ５１０は、ビデオ信号の処理のための少なくとも１つの処理（プロセシング）回路で構成されることができ、ビデオ信号のエンコーディングまたはデコーディングのためのコマンドを実行することによって、映像信号を処理することができる。すなわち、プロセッサ５１０は、以下で説明されるエンコードまたはデコード方法を実行することによって、原本ビデオ信号をエンコードするか、エンコードされたビデオ信号をデコードすることができる。

図６は、本明細書の実施例にかかるブロックの分割構造の例であって、図６ａは、ＱＴ（quad Tree、以下「ＱＴ」と称される）、図６ｂは、ＢＴ（Binary Tree、以下「ＢＴ」と称される）、図６ｃは、ＴＴ（Ternary Tree、以下「ＴＴ」と称される）、図６ｄは、ＡＴ（Asymmetric Tree、以下「ＡＴ」と称される）によるブロックの分割構造の例を示す。

ビデオコーディングにおける１つのブロックは、ＱＴベースで分割されることができる。また、ＱＴによって分割された１つのサブブロック（subblock）は、ＱＴを使用して再帰的にさらに分割されることができる。これ以上ＱＴ分割されないリーフブロック（leaf block）は、ＢＴ、ＴＴまたはＡＴのうちの少なくとも１つの方式によって分割されることができる。ＢＴは、ｈｏｒｉｚｏｎｔａｌ ＢＴ（２ＮｘＮ、２ＮｘＮ）とｖｅｒｔｉｃａｌ ＢＴ（Ｎｘ２Ｎ、Ｎｘ２Ｎ）との２つの形態の分割を有することができる。ＴＴは、ｈｏｒｉｚｏｎｔａｌ ＴＴ（２Ｎｘ１／２Ｎ、２ＮｘＮ、２Ｎｘ１／２Ｎ）とｖｅｒｔｉｃａｌ ＴＴ（１／２Ｎｘ２Ｎ、Ｎｘ２Ｎ、１／２Ｎｘ２Ｎ）との２つの形態の分割を有することができる。ＡＴは、ｈｏｒｉｚｏｎｔａｌ－ｕｐ ＡＴ（２Ｎｘ１／２Ｎ、２Ｎｘ３／２Ｎ）、ｈｏｒｉｚｏｎｔａｌ－ｄｏｗｎ ＡＴ（２Ｎｘ３／２Ｎ、２Ｎｘ１／２Ｎ）、ｖｅｒｔｉｃａｌ－ｌｅｆｔ ＡＴ（１／２Ｎｘ２Ｎ、３／２Ｎｘ２Ｎ）、ｖｅｒｔｉｃａｌ－ｒｉｇｈｔ ＡＴ（３／２Ｎｘ２Ｎ、１／２Ｎｘ２Ｎ）の４つの形態の分割を有することができる。それぞれのＢＴ、ＴＴ、ＡＴは、ＢＴ、ＴＴ、ＡＴを使用して再帰的にさらに分割されることができる。

図６ａは、ＱＴの分割の例を示す。ブロックＡは、ＱＴによって４つのサブブロック（Ａ０、Ａ１、Ａ２、Ａ３）に分割されることができる。サブブロックＡ１は、再度ＱＴによって４つのサブブロック（Ｂ０、Ｂ１、Ｂ２、Ｂ３）に分割されることができる。

図６ｂは、ＢＴの分割の例を示す。ＱＴによってこれ以上分割されないブロックＢ３は、ｖｅｒｔｉｃａｌ ＢＴ（Ｃ０、Ｃ１）またはｈｏｒｉｚｏｎｔａｌ ＢＴ（Ｄ０、Ｄ１）に分割されることができる。ブロックＣ０のようにそれぞれのサブブロックは、ｈｏｒｉｚｏｎｔａｌ ＢＴ（Ｅ０、Ｅ１）またはｖｅｒｔｉｃａｌ ＢＴ（Ｆ０、Ｆ１）の形態のように再帰的にさらに分割されることができる。

図６ｃは、ＴＴの分割の例を示す。ＱＴによってこれ以上分割されないブロックＢ３は、ｖｅｒｔｉｃａｌ ＴＴ（Ｃ０、Ｃ１、Ｃ２）またはｈｏｒｉｚｏｎｔａｌ ＴＴ（Ｄ０、Ｄ１、Ｄ２）に分割されることができる。ブロックＣ１のようにそれぞれのサブブロックは、ｈｏｒｉｚｏｎｔａｌ ＴＴ（Ｅ０、Ｅ１、Ｅ２）またはｖｅｒｔｉｃａｌ ＴＴ（Ｆ０、Ｆ１、Ｆ２）の形態のように再帰的にさらに分割されることができる。

図６ｄは、ＡＴの分割の例を示す。ＱＴによってこれ以上分割されないブロックＢ３は、ｖｅｒｔｉｃａｌ ＡＴ（Ｃ０、Ｃ１）またはｈｏｒｉｚｏｎｔａｌ ＡＴ（Ｄ０、Ｄ１）に分割されることができる。ブロックＣ１のようにそれぞれのサブブロックは、ｈｏｒｉｚｏｎｔａｌ ＡＴ（Ｅ０、Ｅ１）またはｖｅｒｔｉｃａｌ ＴＴ（Ｆ０、Ｆ１）の形態のように再帰的にさらに分割されることができる。

一方、ＢＴ、ＴＴ、ＡＴの分割は、結合され（組み合わせられ）得る。例えば、ＢＴによって分割されたサブブロックは、ＴＴまたはＡＴによる分割が可能である。また、ＴＴによって分割されたサブブロックは、ＢＴまたはＡＴによる分割が可能である。ＡＴによって分割されたサブブロックは、ＢＴまたはＴＴによる分割が可能である。例えば、ｈｏｒｉｚｏｎｔａｌ ＢＴの分割以降、それぞれのサブブロックがｖｅｒｔｉ－ｃａｌ ＢＴに分割されることができ、またはｖｅｒｔｉｃａｌ ＢＴの分割以降、それぞれのサブブロックがｈｏｒｉｚｏｎｔａｌ ＢＴに分割されることもできる。上記２種類の分割方法は、分割の順序は異なるが、最終的に分割された形状（模様）（shapes）は同一である。

また、ブロックが分割されると、ブロックを探索する順序が多様に定義され得る。一般に、左側から右側に、上段から下段に探索を行い、ブロックを探索するというのは、各分割されたサブブロックの更なるブロックの分割が可能か否かを決定する順序を意味するか、ブロックがこれ以上分割されない場合、各サブブロックの符号化順序を意味するか、またはサブブロックから他の隣接ブロックの情報を参照する際の探索順序を意味し得る。

図７および図８は、インター予測に基づくビデオ／映像のエンコーディング手続、およびエンコード装置内のインター予測部を示す。

エンコード装置１００は、現ブロックに対するインター予測を行う（Ｓ７１０）。エンコード装置１００は、現ブロックのインター予測モードおよび動き情報を導出し、現ブロックの予測サンプルを生成することができる。ここで、インター予測モードの決定、動き情報の導出、および予測サンプルの生成手続は、同時に行われてもよく、いずれかの手続が他の手続より先に行われてもよい。例えば、エンコード装置１００のインター予測部１８０は、予測モード決定部１８１、動き情報導出部１８２、予測サンプル導出部１８３を含むことができ、予測モード決定部１８１で現ブロックに対する予測モードを決定し、動き情報導出部１８２で現ブロックの動き情報を導出し、予測サンプル導出部１８３で現ブロックの予測サンプルを導出することができる。例えば、エンコード装置１００のインター予測部１８０は、動き推定（motion estimation）を介して参照ピクチャの一定領域（サーチ領域）内で上記現ブロックと類似するブロックをサーチし、現ブロックとの差が最小または一定基準以下である参照ブロックを導出することができる。これに基づいて、上記参照ブロックが位置する参照ピクチャを指す参照ピクチャのインデックスを導出し、参照ブロックと現ブロックとの位置の差異に基づいて動きベクトルを導出することができる。エンコード装置１００は、多様な予測モードのうち、現ブロックに対して適用されるモードを決定することができる。エンコード装置１００は、多様な予測モードに対するＲＤコスト（cost）を比較し、現ブロックに対する最適な予測モードを決定することができる。

例えば、エンコード装置１００は、現ブロックにスキップモードまたはマージモードが適用される場合、後述するマージ候補リストを構成し、マージ候補リストに含まれるマージ候補の指す参照ブロックのうち、現ブロックとの差が、最小または一定基準以下である参照ブロックを導出することができる。この場合、導出された参照ブロックと関連するマージ候補が選択され、選択されたマージ候補を指すマージインデックス情報が生成され、デコード装置２００にシグナリングされることができる。選択されたマージ候補の動き情報を利用し、現ブロックの動き情報が導出されることができる。

別の例として、エンコード装置１００は、現ブロックに（Ａ）ＭＶＰモードが適用される場合、後述する（Ａ）ＭＶＰ候補リストを構成し、（Ａ）ＭＶＰ候補リストに含まれるＭＶＰ（Motion Vector Predictor）候補のうち選択されたＭＶＰ候補の動きベクトルを現ブロックのＭＶＰとして利用できる。この場合、例えば、前述した動き推定によって導出された参照ブロックを指す動きベクトルが、現ブロックの動きベクトルとして利用されることができ、ＭＶＰ候補のうち、現ブロックの動きベクトルとの差が最も小さい動きベクトルを有するＭＶＰ候補が選択されたＭＶＰ候補になることができる。現ブロックの動きベクトルからＭＶＰを引いた差分であるＭＶＤ（Motion Vector Difference）が導出されることができる。この場合、ＭＶＤに関する情報がデコード装置２００にシグナリングされることができる。また、（Ａ）ＭＶＰモードが適用される場合、参照ピクチャのインデックスの値は、参照ピクチャのインデックス情報として構成され、別にデコード装置２００にシグナリングされることができる。

エンコード装置１００は、予測サンプルに基づいて残差サンプルを導出することができる（Ｓ７２０）。エンコード装置１００は、現ブロックのオリジナルサンプルと予測サンプルとの比較を通じて、残差サンプルを導出することができる。

エンコード装置１００は、予測情報および残差情報を含む映像情報をエンコードする（Ｓ７３０）。エンコード装置１００は、エンコードされた映像情報をビットストリームの形態で出力することができる。予測情報は、予測手続に関する情報として、予測モード情報（例えば、スキップフラグ、マージフラグ、またはモードインデックス）および動き情報を含み得る。動き情報は、動きベクトルを導出するための情報である候補選択情報（例えば、マージインデックス、ｍｖｐフラグ、またはｍｖｐインデックス）を含み得る。また、動き情報は、前述したＭＶＤに関する情報および／または参照ピクチャのインデックス情報を含み得る。さらに、動き情報は、Ｌ０予測、Ｌ１予測、または双（ｂｉ）予測が適用されるか否かを示す情報を含み得る。残差情報は、残差サンプルに関する情報である。残差情報は、残差サンプルに対する量子化された変換係数に関する情報を含み得る。

出力されたビットストリームは、（デジタル）記憶媒体に記憶されてデコード装置に伝達されることができ、またはネットワークを介してデコード装置に伝達されることもできる。

一方、前述したように、エンコード装置は、上記参照サンプルおよび上記残差サンプルに基づいて、復元ピクチャ（復元サンプルおよび復元ブロック含む）を生成することができる。これは、デコード装置２００で行われるものと同一の予測結果をエンコード装置１００から導出するためであり、これを介して、コーディングの効率を高めることができるためである。したがって、エンコード装置１００は、復元ピクチャ（または復元サンプル、復元ブロック）をメモリに記憶し、インター予測のための参照ピクチャとして活用できる。復元ピクチャにインループフィルタリング手続などがさらに適用できることは前述した通りである。

図９および図１０は、インター予測に基づくビデオ／映像のデコーディング手続、およびデコード装置内のインター予測部を示す。

デコード装置２００は、エンコード装置１００で行われた動作と対応する動作を行うことができる。デコード装置２００は、受信した予測情報に基づいて現ブロックに対して予測を行い、予測サンプルを導出することができる。

具体的には、デコード装置２００は、受信した予測情報に基づいて、現ブロックに対する予測モードを決定することができる（Ｓ９１０）。デコード装置２００は、予測情報内の予測モード情報に基づいて、現ブロックにどのようなインター予測モードが適用されるかを決定できる。

例えば、デコード装置２００は、マージフラグ（merge flag）に基づいて、現ブロックにマージモードが適用されるか、または（Ａ）ＭＶＰモードが決定されるか否かを決定することができる。あるいは、デコード装置２００は、モードインデックス（mode index）に基づいて、多様なインター予測モードの候補のうちの一つを選択することができる。インター予測モードの候補は、スキップモード、マージモードおよび／もしくは（Ａ）ＭＶＰモードを含んでもよく、または後述する多様なインター予測モードを含んでもよい。

デコード装置２００は、決定されたインター予測モードに基づいて、現ブロックの動き情報を導出する（Ｓ９２０）。例えば、デコード装置２００は、現ブロックにスキップモードまたはマージモードが適用される場合、後述するマージ候補リストを構成し、マージ候補リストに含まれるマージ候補のうちの一つのマージ候補を選択し得る。マージ候補の選択は、マージインデックス（merge index）に基づいて行われ得る。選択されたマージ候補の動き情報から現ブロックの動き情報が導出され得る。選択されたマージ候補の動き情報が現ブロックの動き情報として利用され得る。

別の例として、デコード装置２００は、現ブロックに（Ａ）ＭＶＰモードが適用される場合、後述する（Ａ）ＭＶＰ候補リストを構成し、（Ａ）ＭＶＰ候補リストに含まれるＭＶＰ候補のうち選択されたＭＶＰ候補の動きベクトルを現ブロックのＭＶＰとして利用し得る。ＭＶＰの選択は、前述した選択情報（ＭＶＰフラグまたはＭＶＰインデックス）に基づいて行われ得る。この場合、デコード装置２００は、ＭＶＤに関する情報に基づいて上記現ブロックのＭＶＤを導出し得、現ブロックのＭＶＰおよびＭＶＤに基づいて、現ブロックの動きベクトルを導出し得る。また、デコード装置２００は、参照ピクチャのインデックス情報に基づいて、現ブロックの参照ピクチャのインデックスを導出し得る。現ブロックに関する参照ピクチャリスト内で、参照ピクチャのインデックスの指すピクチャが、現ブロックのインター予測のために参照される参照ピクチャとして導出され得る。

一方、後述するように、候補リストの構成なしで、上記現ブロックの動き情報が導出され得、この場合、後述する予測モードで開始された手続によって、現ブロックの動き情報が導出され得る。この場合、前述したような候補リストの構成は省略され得る。

デコード装置２００は、現ブロックの動き情報に基づいて、現ブロックに対する予測サンプルを生成することができる（Ｓ９３０）。この場合、デコード装置２００は、現ブロックの参照ピクチャのインデックスに基づいて参照ピクチャを導出し、現ブロックの動きベクトルが参照ピクチャ上で指す参照ブロックのサンプルを利用し、現ブロックの予測サンプルを導出し得る。この場合、後述するように、場合によって、現ブロックの予測サンプルのうち、全てまたは一部に対する予測サンプルのフィルタリング手続がさらに行われ得る。

例えば、デコード装置２００のインター予測部２６０は、予測モード決定部２６１、動き情報導出部２６２、予測サンプル導出部２６３を含み得、予測モード決定部１８１で受信した予測モード情報に基づいて上記現ブロックに対する予測モードを決定し、動き情報導出部１８２で受信した動き情報に関する情報に基づいて、上記現ブロックの動き情報（動きベクトルおよび／または参照ピクチャのインデックスなど）を導出し、予測サンプル導出部１８３から上記現ブロックの予測サンプルを導出し得る。

デコード装置２００は、受信した残差情報に基づいて、上記現ブロックに対する残差サンプルを生成する（Ｓ９４０）。デコード装置２００は、予測サンプルおよび残差サンプルに基づいて現ブロックに対する復元サンプルを生成し、これに基づいて復元ピクチャを生成することができる（Ｓ９５０）。以降、上記復元ピクチャにインループフィルタリング手続などがさらに適用され得ることは前述した通りである。

前述したようにインター予測手続は、インター予測モード決定段階、決定された予測モードによる動き情報導出段階、導出された動き情報に基づく予測実行（予測サンプルの生成）段階を含み得る。

インター予測モードの決定（Determination of inter prediction mode）

ピクチャ内の現ブロックの予測のために、様々なインター予測モードが使用され得る。例えば、マージモード、スキップモード、ＭＶＰモード、アフィン（Affine）モードなどの様々なモードが使用され得る。ＤＭＶＲ（Decoder side Motion Vector Refinement）モード、ＡＭＶＲ（Adaptive Motion Vector Resolution）モードなどが付随的なモードとしてさらに使用され得る。アフィンモードは、アフィン動き予測（affine motion prediction）モードと呼ばれてもよい。ＭＶＰモードは、ＡＭＶＰ（Advanced Motion Vector Prediction）モードと呼ばれてもよい。

現ブロックのインター予測モードを指す予測モード情報が、エンコード装置からデコード装置２００にシグナリングされ得る。予測モード情報は、ビットストリームに含まれてデコード装置２００で受信され得る。予測モード情報は、多数の候補モードのうちの一つを指示するインデックス情報を含み得る。あるいは、フラグ情報の階層的シグナリングを介して、インター予測モードを指示することもある。この場合、予測モード情報は、１つまたは複数のフラグを含み得る。例えば、エンコード装置１００は、スキップフラグをシグナリングしてスキップモードの適用が可能か否かを指示し、スキップモードが適用されない場合に、マージフラグをシグナリングしてマージモードの適用が可能か否かを指示し、マージモードが適用されない場合に、ＭＶＰモードが適用されるものと指示するか、更なる区分（区別）のためのフラグをさらにシグナリングすることもある。アフィンモードは、独立したモードでシグナリングされてもよく、またはマージモードもしくはＭＶＰモードなどに従属するモードでシグナリングされてもよい。例えば、アフィンモードは、後述するように、マージ候補リストまたはＭＶＰ候補リストの１つの候補で構成されることもできる。

インター予測モードによる動き情報の導出（Derivation of motion information according to inter prediction mode）

エンコード装置１００またはデコード装置２００は、現ブロックの動き情報を利用してインター予測を行うことができる。エンコード装置１００は、動き推定（motion estimation）手続を介して、現ブロックに対する最適な動き情報を導出し得る。例えば、エンコード装置１００は、現ブロックに対するオリジナルピクチャ内のオリジナルブロックを利用し、相関性の高い類似の参照ブロックを参照ピクチャ内の決められた探索範囲内で分数（端数）ピクセル単位で探索し得、これを介して、動き情報を導出し得る。ブロックの類似性は、位相（phase）ベースのサンプル値の差に基づいて導出され得る。例えば、ブロックの類似性は、現ブロック（または現ブロックのテンプレート）と参照ブロック（または参照ブロックのテンプレート）との間のＳＡＤ（Sum of Absolute Difference）に基づいて計算され得る。この場合、サーチスペース（探索領域）内のＳＡＤが、最も小さい参照ブロックに基づいて動き情報を導出し得る。導出された動き情報は、インター予測モードに基づいて、様々な方法によってデコード装置にシグナリングされ得る。

マージモードおよびスキップモード

マージモード（merge mode）が適用される場合、現在の予測ブロックの動き情報が直接送信されず、周辺の予測ブロックの動き情報を利用し、現在の予測ブロックの動き情報を導出することになる。したがって、エンコード装置１００は、マージモードを利用したことを知らせるフラグ情報、および周辺のどの予測ブロックを利用したかを知らせるマージインデックスを送信することによって、現在の予測ブロックの動き情報を指示し得る。

エンコード装置１００は、マージモードを行うために、現在の予測ブロックの動き情報を導出するために利用されるマージ候補ブロック（merge candidate block）をサーチすべきである。例えば、マージ候補ブロックは、最大５つまで利用され得るが、本明細書はこれに限定されない。そして、マージ候補ブロックの最大の数は、スライスヘッダで送信され得、本明細書はこれに限定されない。マージ候補ブロックを見付けた後、エンコード装置１００は、マージ候補リストを生成し得、これらのうち、最も小さいコストを有するマージ候補ブロックを最終的なマージ候補ブロックとして選択し得る。

本明細書は、マージ候補リストを構成するマージ候補ブロックに対する様々な実施例を提供する。

マージ候補リストは、例えば、５つのマージ候補ブロックを利用し得る。例えば、４つの空間的マージ候補（spatial merge candidate）と１つの時間的マージ候補（temporal merge candidate）とを利用し得る。

図１１は、現ブロックに対する空間的マージ候補の構成の例を示す。

図１１を参照すると、現ブロックの予測のために、左側の隣接ブロックＡ１、左下側（bottom-left）の隣接ブロックＡ２、右上側（top-right）の隣接ブロックＢ０、上側の隣接ブロックＢ１、左上側（top-left）の隣接ブロックＢ２のうちの少なくとも１つが使用され得る。現ブロックに対するマージ候補リストは、図１２のような手続に基づいて構成され得る。

図１２は、本明細書の実施例にかかるマージ候補リストの構成のフローチャートの例を示す。

コーディング装置（エンコード装置１００またはデコード装置２００）は、現ブロックの空間的周辺ブロックを探索して導出された空間的マージ候補をマージ候補リストに挿入する（Ｓ１２１０）。例えば、空間的周辺ブロックは、現ブロックの左下側角の周辺ブロック、左側の周辺ブロック、右上側角の周辺ブロック、上側の周辺ブロック、左上側角の周辺ブロックを含み得る。ただし、これは、例として前述した空間的周辺ブロック以外にも、右側の周辺ブロック、下側の周辺ブロック、右下側の周辺ブロックなどの更なる周辺ブロックが、さらに上記空間的周辺ブロックとして使用され得る。コーディング装置は、空間的周辺ブロックを優先順位に基づいて探索して使用可能なブロックを検出し、検出されたブロックの動き情報を空間的マージ候補として導出し得る。例えば、エンコード装置１００またはデコード装置２００は、図１１に示す５つのブロックをＡ１、Ｂ１、Ｂ０、Ａ０、Ｂ２の順に探索し、使用可能な候補を順次インデキシングして、マージ候補リストを構成することができる。

コーディング装置は、現ブロックの時間的周辺ブロックを探索して導出された時間的マージ候補を上記マージ候補リストに挿入する（Ｓ１２２０）。時間的周辺ブロックは、現ブロックが位置する現ピクチャと異なるピクチャである参照ピクチャ上に位置し得る。時間的周辺ブロックが位置する参照ピクチャは、同位置のピクチャ（collocated picture）またはコロケート（コル）ピクチャ（col picture）と呼ばれ得る。時間的周辺ブロックは、コロケートピクチャ上における現ブロックに対する同位置のブロック（co-located block）の右下側角の周辺ブロックおよび右下側のセンターブロックの順に探索され得る。一方、動きデータ圧縮（motion data compression）が適用される場合、コロケートピクチャに一定の記憶単位ごとに特定の動き情報を代表の動き情報として記憶し得る。この場合、上記一定の記憶単位内の全てのブロックに対する動き情報を記憶する必要がなく、これを介して動きデータ圧縮の効果が得られる。この場合、一定の記憶単位は、例えば、１６ｘ１６のサンプル単位、または８ｘ８のサンプル単位などと予め決められることもあり、あるいは、エンコード装置１００からデコード装置２００に一定の記憶単位に対するサイズ情報がシグナリングされることもある。動きデータ圧縮が適用される場合、時間的周辺ブロックの動き情報は、時間的周辺ブロックが位置する一定の記憶単位の代表の動き情報に代替され得る。すなわち、この場合、実現の側面で見ると、時間的周辺ブロックの座標に位置する予測ブロックではなく、時間的周辺ブロックの座標（左上段のサンプルポジション）に基づいて、一定値だけ算術右シフトの後、算術左シフトした位置をカバーする予測ブロックの動き情報に基づいて時間的マージ候補が導出され得る。例えば、一定の記憶単位が２ｎｘ２ｎのサンプル単位である場合、時間的周辺ブロックの座標が（ｘＴｎｂ、ｙＴｎｂ）とすれば、修正された位置である（（ｘＴｎｂ＞＞ｎ）＜＜ｎ）、（ｙＴｎｂ＞＞ｎ）＜＜ｎ））に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。具体的には、例えば、一定の記憶単位が１６ｘ１６のサンプル単位である場合、時間的周辺ブロックの座標が（ｘＴｎｂ、ｙＴｎｂ）とすれば、修正された位置である（（ｘＴｎｂ＞＞４）＜＜４）、（ｙＴｎｂ＞＞４）＜＜４））に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。あるいは、例えば、一定の記憶単位が８ｘ８のサンプル単位である場合、時間的周辺ブロックの座標が（ｘＴｎｂ、ｙＴｎｂ）とすれば、修正された位置である（（ｘＴｎｂ＞＞３）＜＜３）、（ｙＴｎｂ＞＞３）＜＜３））に位置する予測ブロックの動き情報が時間的マージ候補のために使用され得る。

コーディング装置は、現在のマージ候補の数が最大のマージ候補の数より小さいか否かを確認することができる（Ｓ１２３０）。最大のマージ候補の数は、予め定義されるか、またはエンコード装置１００からデコード装置２００にシグナリングされ得る。例えば、エンコード装置１００は、最大のマージ候補の数に関する情報を生成し、エンコードしてビットストリームの形態でデコード装置２００に伝達し得る。最大のマージ候補の数が全て満たされると、以降の候補追加過程は行われなくてもよい。

確認の結果、現在のマージ候補の数が上記最大のマージ候補の数より小さい場合、コーディング装置は、追加のマージ候補をマージ候補リストに挿入する（Ｓ１２４０）。追加のマージ候補は、例えば、ＡＴＭＶＰ（Adaptive Temporal Motion Vector Prediction）、結合された両方向予測（combined bi-predictive）マージ候補（現在スライスのスライスタイプがＢタイプである場合）および／またはゼロベクトル（zero vector）マージ候補を含み得る。

図１３は、予測候補リスト（ＭＶＰ候補リスト）を構成するフローチャートの例を示す。

ＭＶＰ（Motion Vector Prediction）モードが適用される場合、復元された空間的周辺ブロック（例えば、図１１の周辺ブロック）の動きベクトルおよび／または時間的周辺ブロック（またはＣｏｌブロック）に対応する動きベクトルを用いて、動きベクトル予測子（Motion Vector Predictor、ＭＶＰ）候補リストが生成され得る。すなわち、復元された空間的周辺ブロックの動きベクトルおよび／または時間的周辺ブロックに対応する動きベクトルは、動きベクトル予測子の候補として使用され得る。上記予測に関する情報は、上記リストに含まれる動きベクトル予測子の候補のうちから選択された最適な動きベクトル予測子の候補を指示する選択情報（例えば、ＭＶＰフラグまたはＭＶＰインデックス）を含み得る。この際、予測部は、上記選択情報を用いて、動きベクトル候補リストに含まれる動きベクトル予測子の候補のうちから、現ブロックの動きベクトル予測子を選択し得る。エンコード装置１００の予測部は、現ブロックの動きベクトルと動きベクトル予測子との間の動きベクトル差分（ＭＶＤ）を求めることができ、これをエンコードし、ビットストリームの形態で出力することができる。すなわち、ＭＶＤは、現ブロックの動きベクトルから上記動きベクトル予測子を引いた値で求められる。この際、デコード装置の予測部は、上記予測に関する情報に含まれる動きベクトル差分を獲得し、上記動きベクトル差分と上記動きベクトル予測子との加算を介して、現ブロックの上記動きベクトルを導出し得る。デコード装置の予測部は、参照ピクチャを指示する参照ピクチャのインデックスなどを上記予測に関する情報から獲得または導出し得る。例えば、動きベクトル予測子候補リストは、図１３のように構成され得る。

図１３を参照すると、コーディング装置は、動きベクトルの予測のための空間的候補ブロックを探索して予測候補リストに挿入する（Ｓ１３１０）。例えば、コーディング装置は、決められた探索の順序に従って周辺ブロックに対する探索を行い、空間的候補ブロックに対する条件を満たす周辺ブロックの情報を予測候補リスト（ＭＶＰ候補リスト）に追加し得る。

空間的候補ブロックリストを構成した後、コーディング装置は、予測候補リストに含まれる空間的候補リストの数と、既設定された基準の数（例えば、２）と、を比較する（Ｓ１３２０）。予測候補リストに含まれる空間的候補リストの数が基準の数（例えば、２）より大きいか等しい場合、コーディング装置は、予測候補リストの構成を終了し得る。

しかしながら、予測候補リストに含まれる空間的候補リストの数が基準の数（例えば、２）より小さい場合、コーディング装置は、時間的候補ブロックを探索して予測候補リストに追加挿入し（Ｓ１３３０）、時間的候補ブロックが使用されることができない場合、ゼロ動きベクトルを予測候補リストに追加する（Ｓ１３４０）。

予測サンプルの生成（Generation of prediction sample）

予測モードに応じて導出された動き情報に基づいて、現ブロックに対する予測されたブロックが導出され得る。予測されたブロックは、現ブロックの予測サンプル（予測サンプルアレイ）を含み得る。現ブロックの動きベクトルが分数サンプル単位を指す場合、補間（interpolation）手続が行われ得、これを介して参照ピクチャ内で分数サンプル単位の参照サンプルに基づいて、上記現ブロックの予測サンプルが導出され得る。現ブロックにアフィン（affine）インター予測が適用される場合、サンプル／サブブロック単位の動きベクトル（motion vector）に基づいて予測サンプルが生成され得る。両方向（bi-direction）の予測が適用される場合、第１方向の予測（例えば、Ｌ０予測）に基づいて導出された予測サンプルと、第２方向の予測（例えば、Ｌ１予測）に基づいて導出された予測サンプルの（位相による）加重和を介して、最終的な予測サンプルが導出され得る。導出された予測サンプルに基づいて復元サンプルおよび復元ピクチャが生成され得、以降、インループフィルタリングなどの手続が行われ得ることは、前述した通りである。

アフィン動き予測（Affine motion prediction）

図１４は、本発明の実施例にかかる動きモデル（motion models）の例を示す。

従来の映像圧縮技術（例えば、ＨＥＶＣ（High Efficiency Video Coding））は、符号化ブロックの動き（motion）を表現するために、１つの動きベクトル（motion vector）を使用する。ブロックごとに１つの動きベクトルを使用する方式がブロック単位の最適な動きを表現していることがあるが、実際の各画素の最適な動きではないことがある。したがって、画素単位で最適な動きベクトルを決定することができれば、符号化効率を高めることができる。そのため、本発明の実施例は、多数の動きモデル（multi motion model）を使用し、ビデオ信号を符号化または復号する動き予測（motion prediction）方法について説明する。特に、２つ乃至４つの制御点の動きベクトルを用いて、ブロックの各画素単位またはサブブロック単位で動きベクトルを表現し得、このような複数の制御点の動きベクトルを使用した予測技法は、アフィン動き予測（affine motion prediction）、アフィン予測（affine prediction）などと称される。

本発明の実施例にかかるアフィン動きモデル（affine motion model）は、図１４に示すような４つの動きモデルを表現し得る。アフィン動きモデル（Affine motion model）が表現し得る動きのうちの３つの動き（トランスレーション（translation）、スケール（scale）、ローテート（rotate））を表現するアフィン動きモデル（affine motion model）を類似アフィン動きモデル（similarity (or simplified) affine motion model）と称し、本発明の実施例を説明するにあたって、説明の便宜のために、類似アフィン動きモデル（similarity (or simplified) affine motion model）を基準に説明するが、本発明がこれに限定されるわけではない。

図１５は、本発明の実施例にかかるアフィン動き予測のための制御点の動きベクトルの例を示す。

図１５のように、アフィン動き予測は、２つの制御点の動きベクトル（Control Point Motion Vector、ＣＰＭＶ）ペア（pair）、ｖ＿０およびｖ＿１を用いて、ブロックが含む画素位置（またはサブブロック）の動きベクトルを決定し得る。この際、動きベクトルの集合は、アフィン動きベクトルフィールド（Motion Vector Field、ＭＶＦ）と称される。この際、アフィン動きベクトルフィールドは、下記の数式１を用いて決定され得る。

＜数式１＞

数式１で、ｖ＿０（ｖ＿０＝｛ｖ＿０ｘ，ｖ＿０ｙ｝）は、現ブロック１５００の左上側位置の第１の制御点の動きベクトル（ＣＰＭＶ０）を表し、ｖ＿１（ｖ＿１＝｛ｖ＿１ｘ，ｖ＿１ｙ｝）は、現ブロック１５００の右上側位置の第２の制御点の動きベクトル（ＣＰＭＶ１）を表す。また、ｗは、現ブロック１５００の幅（width）を表す。ｖ（ｖ＝｛ｖ＿ｘ，ｖ＿ｙ｝）は、｛ｘ，ｙ｝位置における動きベクトルを表す。サブブロック（または画素）単位の動きベクトルは、上記数式１を用いて導出され得る。一実施例において、動きベクトルの精度は、１／１６の精度で丸められ得る。

図１６は、本発明の実施例にかかるアフィン動き予測が適用されたブロックの各サブブロック別の動きベクトルの例を示す。

図１６を参照すると、符号化または復号の過程でアフィン動きベクトルフィールド（ＭＶＦ）は、画素単位もしくはブロック単位で決定され得る。すなわち、アフィン動き予測において、現ブロックの動きベクトルは、画素単位またはサブブロック単位で導出され得る。

画素単位でアフィン動きベクトルフィールドが決定される場合、各画素値を基準に動きベクトルが得られ、ブロック単位の場合、ブロックの中央画素値を基準に該当ブロックの動きベクトルが得られる。本文書で、図１６のようにアフィン動きベクトルフィールド（ＭＶＦ）が４＊４のブロック単位で決定される場合が仮定される。ただし、これは、説明の便宜のためのものであり、本発明の実施例が限定されるわけではない。図１６は、符号化ブロックが１６＊１６個のサンプルで構成され、４＊４サイズのブロック単位でアフィン動きベクトルフィールド（ＭＶＦ）が決定される場合の例を示す。

アフィン動き予測（affine motion prediction）は、アフィンマージモード（ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅまたはＡＦ＿ＭＥＲＧＥ）と、アフィンインターモード（ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅまたはＡＦ＿ＩＮＴＥＲ）と、を含み得る。ＡＦ＿ＩＮＴＥＲモードは、４つのパラメータベース動きモデルを用いるＡＦ＿４＿ＩＮＴＥＲモードと、６つのパラメータベース動きモデルを用いるＡＦ＿６＿ＩＮＴＥＲモードと、を含み得る。

アフィンマージモード（Affine merge mode）

ＡＦ＿ＭＥＲＧＥは、アフィン動き予測としてコーディングされた周辺ブロックのアフィン動きモデルに応じて、制御点の動きベクトル（Control Point Motion Vector：ＣＰＭＶ）を決定する。検索順序でアフィンコーディングされた周辺ブロックは、ＡＦ＿ＭＥＲＧＥのために使用され得る。１つまたは複数の隣接ブロックがアフィン動き予測としてコーディングされる際、現ブロックは、ＡＦ＿ＭＥＲＧＥとしてコーディングされ得る。

すなわち、アフィンマージモードが適用される場合、周辺ブロックのＣＰＭＶを用いて現ブロックのＣＰＭＶを導出し得る。この場合、周辺ブロックのＣＰＭＶが、そのまま現ブロックのＣＰＭＶに使用されることもあり、周辺ブロックのＣＰＭＶが、上記周辺ブロックのサイズ、および上記現ブロックのサイズなどに基づいて修正され、現ブロックのＣＰＭＶに使用されることもある。

図１７は、本発明の実施例にかかるアフィンマージモード（affine merge mode）でアフィン動き予測に使用される周辺ブロックの例を示す。

アフィンマージ（ＡＦ＿ＭＥＲＧＥ）モードで、エンコーダは、下記のような過程の符号化を行うことができる。

ステップ－１：現在の符号化ブロック１７００の周辺ブロックＡ乃至Ｅ１７１０、１７２０、１７３０、１７４０、１７５０をアルファベット順でスキャン（scanning）し、スキャン順序の基準の１番目にアフィン予測モードで符号化されたブロックをアフィンマージ（ＡＦ＿ＭＥＲＧＥ）の候補ブロックに決定

ステップ－２：決定された候補ブロックの制御点の動きベクトル（ＣＰＭＶ）を用いてアフィン動きモデルを決定

ステップ－３：候補ブロックのアフィン動きモデルに応じて、現ブロック１７００の制御点の動きベクトル（ＣＰＭＶ）が決定され、現ブロック１７００のＭＶＦを決定

図１８は、本発明の実施例にかかるアフィン動き予測が適用された周辺ブロックを使用し、アフィン動き予測が行われるブロックの例を示す。

例えば、図１８のようにブロックＡ１８２０がアフィンモード（affine mode）で符号化された場合、ブロックＡ１８２０を候補ブロックとして決定した後、ブロックＡ１８２０の制御点の動きベクトル（ＣＰＭＶ）（例えば、ｖ２およびｖ３）を用いてアフィン動きモデル（affine motion model）を導出した後、現ブロック１８００の制御点の動きベクトル（ＣＰＭＶ）ｖ０およびｖ１を決定し得る。現ブロック１８００の制御点の動きベクトル（ＣＰＭＶ）に基づいて、現ブロック１８００のアフィン動きベクトルフィールド（ＭＶＦ）が決定され、符号化が行われ得る。

図１９は、本発明の実施例にかかる周辺のアフィン符号化ブロックを用いてマージ候補リストを生成する方法を説明する図である。

図１９を参照すると、アフィンマージ候補を用いてＣＰＭＶペアを決定する場合、図１９に示すような候補が使用され得る。図１９で、候補リストのスキャン順序は、Ａ、Ｂ、Ｃ、Ｄ、Ｅに設定された場合を仮定する。ただし、本発明がこれに限定されるわけではなく、様々な順序で予め設定され得る。

実施例として、周辺ブロック（すなわち、Ａ、Ｂ、Ｃ、Ｄ、Ｅ）で利用可能なアフィンモード（またはアフィン予測）で符号化された候補（以下、アフィン候補と称される）の数が０であるとき、現ブロックのアフィンマージモードはスキップされ得る。利用可能なアフィン候補の数が１つである場合（例えば、Ａ）、該当候補の動きモデルが現ブロックの制御点の動きベクトル（ＣＰＭＶ＿０およびＣＰＭＶ＿１）を導出するのに利用され得る。この場合、該当候補を指示するインデックスが要求（またはコーディング）されなくてもよい。利用可能なアフィン候補の数が２つ以上である場合、スキャンの順序上、２つの候補がＡＦ＿ＭＥＲＧＥに対する候補リストで構成され得る。この場合、候補リスト内で選択された候補を指示するインデックスと同一の候補選択情報がシグナリングされ得る。上記選択情報は、フラグまたはインデックス情報であってもよく、ＡＦ＿ＭＥＲＧＥ＿ｆｌａｇ、ＡＦ＿ｍｅｒｇｅ＿ｉｄｘなどと称される。

本発明の実施例において、現ブロックに対する動き補償は、サブブロックの大きさに基づいて行われ得る。この場合、アフィンブロック（すなわち、現ブロック）のサブブロックの大きさが導出される。サブブロックの幅および高さがいずれも４つのルマサンプルより大きい場合、各サブブロックに対する動きベクトルが導出され、ＤＣＴ－ＩＦベースの動き補償（輝度に対する１／１６ペルおよび色差に対する１／３２）がサブブロックに対して行われ得る。そうでなければ、向上したバイリニア（二重線形）補間フィルタベース動き補償（enhanced bi-linear interpolation filter based motion compensation）が全アフィンブロックに対して行われ得る。

本発明の実施例において、マージ／スキップフラグ（merge/skip flag）が真であり、ＣＵに対する幅および高さがいずれも８より大きいか等しいとき、ＣＵレベルでアフィンフラグは、アフィンマージモードが使用されるかを指示するビットストリーム（bit stream）を介してシグナリングされる。ＣＵがＡＦ＿ＭＥＲＧＥとしてコーディングされる際、最大値「５」を有するマージ候補のインデックスは、アフィンマージ候補リストにおける動き情報の候補がＣＵのために使用されることを指定するためにシグナリングされる。

図２０および図２１は、本発明の実施例にかかるアフィン予測で符号化された周辺ブロックを使用し、アフィンマージ候補リストを構成する方法を説明する図である。

図２０を参照すると、アフィンマージ候補リストは、次の段階によって構成される。

１）モデルベースアフィン候補の挿入

モデルベースアフィン候補は、候補がアフィンモードでコーディングされた有効な周辺の再構成されたブロックから導出されることを意味する。図２０に示すように、候補ブロックに対するスキャン順序は、左側（Ａ）、上側（ｂ）、右上側（Ｃ）、および左下側（Ｄ）から左上側（Ｅ）である。

周辺の左下側ブロック（Ａ）が６－パラメータアフィンモードでコーディングされると、ブロック（Ａ）を含むＣＵの左上側角、右上側角、および左下側角の動きベクトル（ｖ＿４、ｖ＿５、ｖ＿６）を得ることになる。現ブロック上の左上側角の動きベクトル（ｖ＿０、ｖ＿１、ｖ＿２）は、６－パラメータアフィンモデルによる動きベクトル（ｖ＿４、ｖ＿５、ａｎｄ ｖ＿６）に従って計算される。

周辺の左下側ブロック（Ａ）が４－パラメータアフィンモードでコーディングされると、ブロック（Ａ）を含むＣＵの左上側角および右上側角の動きベクトル（ｖ＿４、ｖ＿５）を得ることになる。現ブロック上の左上側角の動きベクトル（ｖ＿０、ｖ＿１）は、４－パラメータアフィンモデルによる動きベクトル（ｖ＿４、ｖ＿５）に従って計算される。

２）制御点ベースアフィン候補の挿入

図２０を参照すると、制御点ベース候補は、各制御点の周辺の動き情報を結合して候補が構成されることを意味する。

制御点に対する動き情報は、まず、図２０に示す指定された空間の隣接ブロックおよび時間の隣接ブロックから導出される。ＣＰ＿ｋ（ｋ＝１、２、３、４）は、ｋ番目の制御点を表す。また、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、およびＧは、ＣＰ＿ｋ（ｋ＝１、２、３）を予測するための空間位置であり、Ｈは、ＣＰ４を予測するための時間位置である。

ＣＰ＿１、ＣＰ＿２、ＣＰ＿３、およびＣＰ＿４の座標は、それぞれ（０，０）、（Ｗ，０）、（Ｈ，０）、および（Ｗ，Ｈ）であり、ここで、ＷおよびＨは、現ブロックの幅および高さである。

各制御点の動き情報は、次の優先順位に従って得られる。

ＣＰ＿１に対して、チェックの優先順位は、Ａ→Ｂ→Ｃであり、Ａが利用可能であれば、Ａが使用される。そうでなく、Ｂが利用可能であれば、Ｂが使用される。ＡもＢも利用可能でなければ、Ｃが使用される。３つの候補がいずれも利用可能でなければ、ＣＰ１の動き情報が得られない。

ＣＰ＿２に対して、チェックの優先順位は、Ｅ→Ｄである。

ＣＰ＿３に対して、チェックの優先順位は、Ｇ→Ｆである。

ＣＰ＿４に対して、Ｈが使用される。

第二に、制御点の組み合わせが動きモデルを構成するのに使用される。

２つの制御点の動きベクトルは、４－パラメータアフィンモデルで変換パラメータを算出するのに必要である。２つの制御点は、次の６つの組み合わせ（｛ＣＰ＿１，ＣＰ＿４｝、｛ＣＰ＿２，ＣＰ＿３｝、｛ＣＰ＿１，ＣＰ＿２｝、｛ＣＰ＿２，ＣＰ＿４｝、｛ＣＰ＿１，ＣＰ＿３｝、｛ＣＰ＿３，ＣＰ＿４｝）のいずれかから選択され得る。例えば、４－パラメータアフィン動きモデルを構成するのにＣＰ＿１およびＣＰ＿２の制御点を使用することは、「Ａｆｆｉｎｅ（ＣＰ＿１，ＣＰ＿２）」と表記される。

３つの制御点の動きベクトルは、６－パラメータアフィンモデルで変換パラメータを算出するのに必要である。３つの制御点は、次の４つの組み合わせ（｛ＣＰ＿１，ＣＰ＿２，ＣＰ＿４｝、｛ＣＰ＿１，ＣＰ＿２，ＣＰ＿３｝、｛ＣＰ＿２，ＣＰ＿３，ＣＰ＿４｝、｛ＣＰ＿１，ＣＰ＿３，ＣＰ＿４｝）のいずれかから選択され得る。例えば、６－パラメータアフィン動きモデルを構成するのにＣＰ＿１、ＣＰ＿２、およびＣＰ＿３の制御点を使用することは、「Ａｆｆｉｎｅ（ＣＰ＿１，ＣＰ＿２，ＣＰ＿３）」と表記される。

また、本発明の実施例において、アフィンマージモードで、アフィンマージ候補が存在すれば、それは、常時６－パラメータアフィンモードとして考慮され得る。

アフィンインターモード（affine inter mode）

図２２は、本発明の実施例にかかるアフィンインターモード（affine inter mode）でアフィン動き予測に使用される周辺ブロックの例を示す。

図２２を参照すると、アフィン動き予測（affine motion prediction）は、アフィンマージモード（ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅまたはＡＦ＿ＭＥＲＧＥ）と、アフィンインターモード（ａｆｆｉｎｅ ｉｎｔｅｒ ｍｏｄｅまたはＡＦ＿ＩＮＴＥＲ）と、を含み得る。アフィンインターモード（ＡＦ＿ＩＮＴＥＲ）で、２つの制御点の動きベクトル予測（Control Point Motion Vector Prediction、ＣＰＭＶＰ）およびＣＰＭＶを決定した後、差に該当する制御点の動きベクトル差分値（Control Point Motion Vector Difference、ＣＰＭＶＤ）がエンコーダからデコーダへ送信され得る。具体的なアフィンインターモード（ＡＦ＿ＩＮＴＥＲ）の符号化過程は、下記の通りである。

ステップ－１：２つのＣＰＭＶＰペア（pair）の候補（candidate）を決定

ステップ－１．１：最大１２個のＣＰＭＶＰ候補の組み合わせを決定（下記の数式２を参照）

＜数式２＞

数式２で、ｖ＿０は、現ブロック２２００の左上側制御点２２１０における動きベクトル（ＣＰＭＶ０）、ｖ＿１は、現ブロック２２００の右上側制御点２２１１における動きベクトル（ＣＰＭＶ１）、ｖ＿２は、現ブロック２２００の左下側制御点２２１２における動きベクトル（ＣＰＭＶ２）であり、ｖ＿Ａは、現ブロック２２００の左上側制御点２２１０の左上側に隣接する周辺ブロックＡ２２２０の動きベクトル、ｖ＿Ｂは、現ブロック２２００の左上側制御点２２１０の上側に隣接する周辺ブロックＢ２２２２の動きベクトル、ｖＣは、現ブロック２２００の左上側制御点２２１０の左側に隣接する周辺ブロックＣ２２２４の動きベクトル、ｖ＿Ｄは、現ブロック２２００の右上側制御点２２１１の上側に隣接する周辺ブロックＤ２２２６の動きベクトル、ｖ＿Ｅは、現ブロック２２００の右上側制御点２２１１の右上側に隣接する周辺ブロックＥ２２２８の動きベクトル、ｖ＿Ｆは、現ブロック２２００の左下側制御点２２１２の左側に隣接する周辺ブロックＦ２２３０の動きベクトル、ｖ＿Ｇは、現ブロック２２００の左下側制御点２２１２の左側に隣接する周辺ブロックＧ２２３２の動きベクトルを表す。

ステップ－１．２：ＣＰＭＶＰ候補の組み合わせのうち、差異値（Difference Value、ＤＶ）が小さい値を基準に整列（sorting）し、上位２つの候補を使用（下記の数式３を参照）

＜数式３＞

ｖ＿０ｘは、現ブロック２２００の左上側制御点２２１０の動きベクトル（Ｖ０またはＣＰＭＶ０）のｘ軸エレメント、ｖ＿１ｘは、現ブロック２２００の右上側制御点２２１１の動きベクトル（Ｖ１またはＣＰＭＶ１）のｘ軸エレメント、ｖ＿２ｘは、現ブロック２２００の左下側制御点２２１２の動きベクトル（Ｖ＿２またはＣＰＭＶ＿２）のｘ軸エレメント、ｖ＿０ｙは、現ブロック２２００の左上側制御点２２１０の動きベクトル（Ｖ＿０またはＣＰＭＶ＿０）のｙ軸エレメント、ｖ＿１ｙは、現ブロック２２００の右上側制御点２２１１の動きベクトル（Ｖ＿１またはＣＰＭＶ＿１）のｙ軸エレメント、ｖ＿２ｙは、現ブロック２２００の左下側制御点２２１２の動きベクトル（Ｖ＿２またはＣＰＭＶ＿２）のｙ軸エレメント、ｗは、現ブロック２２００の幅（width）、ｈは、現ブロック２２００の高さ（height）を表す。

ステップ－２：制御点動きベクトル予測子（ＣＰＭＶＰ）ペアの候補が２より小さい場合、ＡＭＶＰ候補リストを使用

ステップ－３：２つの候補それぞれに対して制御点の動きベクトル予測子（ＣＰＭＶＰ）を決定し、ＲＤコストを比較し、小さい値を有する候補およびＣＰＭＶを最適に選択

ステップ－４：最適な候補に該当するインデックスと制御点の動きベクトル差分値（Control Point Motion Vector Difference、ＣＰＭＶＤ）とを送信

本発明の実施例において、ＡＦ＿ＩＮＴＥＲで、ＣＰＭＶＰ候補の構成過程が提供される。ＡＭＶＰと同じように、候補の数は２であり、候補リストの位置を指示するインデックスがシグナリングされる。

ＣＰＭＶＰ候補リストの構成過程は、次の通りである。

１）周辺ブロックをスキャンし、これがアフィン動き予測としてコーディングされるかをチェックする。スキャンされたブロックがアフィン予測としてコーディングされると、候補の数が２になるまでスキャンされた周辺ブロックのアフィン動きモデルから現ブロックの動きベクトルペアを導出する。

２）候補の数が２より小さい場合、候補の構成過程を行う。また、本発明の実施例において、４－パラメータ（２－制御点）アフィンインターモードが、ズーム－イン／アウト（zoom-in/out）および回転の動きモデルならびにコンテンツを予測するのに使用される。図１５に示すように、ブロックのアフィン動きフィールド（field）は、２つの制御点の動きベクトルにより記述される。

ブロックの動きベクトルフィールド（Motion Vector Field：ＭＶＦ）は、前述した式１により記述される。

従来技術で、ＡＭＶＰ（Advanced Motion Vector Prediction）モードは、ＭＶＰ（Motion Vector Prediction）インデックスおよびＭＶＤｓ（Motion Vector Differences）をシグナリングするのに必要である。ＡＭＶＰモードが本発明に適用される際、アフィン＿フラグ（ａｆｆｉｎｅ＿ｆｌａｇ）は、アフィン予測が使用されるかを指示するようにシグナリングされる。アフィン予測が適用されると、ｉｎｔｅｒ＿ｄｉｒ、ｒｅｆ＿ｉｄｘ、ｍｖｐ＿ｉｎｄｅｘおよび２つのＭＶＤｓ（ｍｖｄ＿ｘおよびｍｖｄ＿ｙ）のシンタックスがシグナリングされる。２つのアフィンＭＶＰペアを含むアフィンＭＶＰペアの候補リストが生成される。シグナリングされたｍｖｐ＿ｉｎｄｅｘは、これらのうちの一つを選択するのに使用される。アフィンＭＶＰペアは、２つの種類のアフィンＭＶＰ候補により生成される。１つは、空間的継承アフィン候補（spatial inherited affine candidate）であり、もう１つは、コーナ導出されたアフィン候補（corner derived affine candidate）である。周辺のＣＵがアフィンモードでコーディングされると、空間的継承アフィン候補が生成され得る。周辺のアフィンコーディングされたブロックのアフィン動きモデルは、２－制御点のＭＶＰペア（two-control-point MVP pair）の動きベクトルを生成するのに使用される。空間的継承アフィン候補の２－制御点ＭＶＰペアのＭＶは、次の数式を使用することによって導出される。

＜数式４＞
V_0x = V_B0x + (V_{B2_x} - V_B0x ) * ( posCurCU_Y - posRefCU_Y ) / RefCU_height+ (V_B1x - V_B0x ) * (posCurCU_X - posRefCU_X) / RefCU_width

＜数式５＞
V_0y = V_B0y + (V_{B2_y} - V_B0y ) * (posCurCU_Y - posRefCU_Y) / RefCU_height+ (V_B1y - V_B0y ) * (posCurCU_X - posRefCU_X) / RefCU_width

Ｖ＿Ｂ０、Ｖ＿Ｂ１、およびＶ＿Ｂ２が、ある参照／周辺のＣＵの左上側ＭＶ、右上側ＭＶ、および左下側ＭＶに代替されることができる場合、（ｐｏｓＣｕｒＣＵ＿Ｘ、ｐｏｓＣｕｒＣＵ＿Ｙ）は、フレームの左上側サンプルに対する現在のＣＵの左上側サンプルの位置であり、（ｐｏｓＲｅｆＣＵ＿Ｘ、ｐｏｓＲｅｆＣＵ＿Ｙ）は、フレームの左上側サンプルに対する参照／周辺のＣＵの左上側サンプルの位置である。

＜数式６＞
V_1x = V_B0x + (V_B1x - V_B0x) * CU_width / RefCU_width

＜数式７＞
V_1y = V_B0y + (V_B1y - V_B0y) * CU_width / RefCU_width

図２３は、本発明の実施例にかかるアフィンインターモード（affine inter mode）でアフィン動き予測に使用される周辺ブロックの例を示す。

図２３を参照すると、ＭＶＰペアの数が２より小さい場合、コーナ導出されたアフィン候補が使用される。周辺の動きベクトルは、図２３に示すように、アフィンＭＶＰペアを導出するのに使用される。第１のコーナ導出されたアフィン候補に対して、セットＡ（Ａ０、Ａ１、およびＡ２）で第１の利用可能なＭＶとセットＢ（Ｂ０およびＢ１）で第１の利用可能なＭＶとは、第１のＭＶＰペアを構成するのに使用される。第２のコーナ導出されたアフィン候補に対して、セットＡで第１の利用可能なＭＶとセットＣ（Ｃ０およびＣ１）で第１の利用可能なＭＶとは、右上側制御点のＭＶを計算するのに使用される。セットＡで第１の利用可能なＭＶと計算された右上側制御点ＭＶとは、第２のＭＶＰペアである。

本発明の実施例において、２つ（３つ）の候補｛ｍｖ＿０，ｍｖ＿１｝（｛ｍｖ＿０，ｍｖ＿１，ｍｖ＿２｝）を含む２つの候補セットは、アフィン動きモデルの２つ（３つ）の制御点を予測するのに使用される。与えられた動きベクトルの差分（ｍｖｄ＿０，ｍｖｄ＿１，ｍｖｄ＿２）および制御点は、次の式を使用することによって計算される。

＜数式８＞

図２４および図２５は、本発明の実施例にかかるアフィンインターモード（affine inter mode）で周辺ブロックの動き情報を用いて動きベクトル候補を導出する方法を例示する図である。

上記アフィン候補リストは、アフィン動きを空間的隣接ブロック（外挿されたアフィン候補）から延びて、空間的隣接ブロック（仮想のアフィン候補）からの動きベクトルの組み合わせにより添付される（appended）（上記アフィン候補リストにおいて、アフィン動きが空間的隣接ブロックから拡張され（外挿されたアフィン候補）、このアフィン候補リストに、上記空間的隣接ブロックからの動きベクトルの組み合わせ（仮想のアフィン候補）がアペンドされる（In the affine candidate list, an affine motion is extended from spatial neighboring blocks (extrapolated affine candidates), and the affine candidate list is appended by a combination of motion vectors from the spatial neighboring blocks (virtual affine candidates)））。候補の集合は、下記のように設定される。

１．最大２つの異なるアフィンＭＶ予測子の集合が隣接ブロックのアフィン動きから導出される。隣接ブロックＡ０、Ａ１、Ｂ０、Ｂ１、およびＢ２が図２４に示すように確認される。隣接ブロックがアフィン動きモデルによって符号化され、その参照フレームが現ブロックの参照フレームと同一である場合、現ブロックの（４－パラメータアフィンモデルに対する）２つまたは（６－パラメータアフィンモデルに対する）３つの制御点が隣接ブロックのアフィンモデルから導出される。

２．図２５は、仮想のアフィン候補の集合を生成するために使用される隣接ブロックを示す。隣接ＭＶは、３つのグループに分割される：Ｓ＿０＝｛ｍｖ＿Ａ，ｍｖ＿Ｂ，ｍｖ＿Ｃ｝、Ｓ＿１＝｛ｍｖ＿Ｄ，ｍｖ＿Ｅ｝、Ｓ＿２＝｛ｍｖ＿Ｆ，ｍｖ＿Ｇ｝。ｍｖ＿０は、Ｓ０で現ブロックと同一の参照ピクチャを参照する１番目のＭＶである。ｍｖ＿２は、Ｓ１で現ブロックと同一の参照ピクチャを参照する１番目のＭＶである。

ｍｖ＿０およびｍｖ＿１が与えられると、ｍｖ＿２は、下記の数式９により導出され得る。

＜数式９＞

数式９で、現ブロックのサイズは、ＷｘＨである。

ｍｖ＿０およびｍｖ＿２のみが与えられると、ｍｖ＿１は、下記の数式１０により導出され得る。

＜数式１０＞

本発明の一実施例において、アフィンインター予測は、下記のシーケンス（sequence）によって行われ得る。

入力：アフィン動きパラメータ、参照ピクチャのサンプル

出力：ＣＵの予測ブロック

プロセス

－ アフィンブロックのサブブロックのサイズを導出

－ サブブロックの幅と、幅モード４のルマサンプル（luma samples）より大きい場合（サブブロックの幅および幅の両方が４つのルマサンプルより大きい場合（If both the width and height of a sub-block are larger than 4 luma samples））、

－ それぞれのサブブロックに対して

－ サブブロックの動きベクトルを導出

－ ＤＣＴ－ＩＦベースの動き補償（ルマに対して１／１６ペル、色差に対して１／３２ペル）をサブブロックに対して実行（invoked）

－ そうでなければ、向上したバイリニア補間フィルタ（enhanced bi-linear interpolation filter）ベースの補償が全アフィンブロックに対して実行される（invoked）

また、本発明の一実施例において、マージ／スキップフラグが偽（虚）（false）であり、ＣＵに対する幅および高さが８より大きいか等しければ、ＣＵレベルでアフィンフラグが、アフィンインターモードが使用されるか否かを指示するためにシグナリングされる。ＣＵがアフィンインターモードとしてコーディングされると、モデルフラグが４－パラメータまたは６－パラメータアフィンモデルが上記ＣＵに対して適用されるか否かを指示するためにシグナリングされる。モデルフラグが真（true）である場合、ＡＦ＿６＿ＩＮＴＥＲ ｍｏｄｅ（６－パラメータアフィンモデル）が適用され、３つのＭＶＤがパージングされ、そうでなければ、ＡＦ＿４＿ＩＮＴＥＲ ｍｏｄｅ４－パラメータアフィンモデル）が適用され、２つのＭＶＤがパージングされる。

ＡＦ＿４＿ＩＮＴＥＲモードで、アフィンマージモードと同様に、アフィン（アフィン）モードによりコーディングされた隣接ブロックから外挿された動きベクトルペアが生成され、１番目に候補リストに挿入される。

以降、候補リストのサイズが４より小さい場合、動きベクトルペア｛（ｖ＿０，ｖ＿１）｜ｖ０＝｛ｖ＿Ａ，ｖ＿Ｂ，ｖ＿ｃ｝、ｖ＿１＝｛ｖ＿Ｄ，ｖ＿Ｅ｝｝を有する候補が隣接ブロックを使用することによって生成される。図２５に示すように、ｖ＿０は、ブロックＡ、Ｂ、Ｃの動きベクトルから選択される。隣接ブロックからの動きベクトルは、参照リスト、隣接ブロックに対する参照のＰＯＣ、現在のＣＵに対する参照のＰＯＣおよび現在のＣＵの間の関係によってスケーリングされる。また、隣接ブロックＤおよびＥからｖ＿１を選択するアプローチ方式は類似する。候補リストが４より大きい場合、候補は、（候補ペアにおける２つの動きベクトルと同様に）隣接動きベクトルの一貫性（consistency）によって優先的に整列され、最初（１番目）の４つの候補が記憶される。

候補リストの数が４より小さい場合、リストは、各ＡＭＶＰ候補を複製することによって、動きベクトルペアによりパディングされる（padded）。

ＡＦ＿６＿ＩＮＴＥＲモードで、アフィンマージモードと同様に、アフィン（アフィン）モードでコーディングされた隣接ブロックから外挿された動きベクトルトリプル（affine motion vector triples）が生成され、候補リストに優先的に挿入される。

以降、候補リストのサイズが４より小さい場合、動きベクトルトリプル｛（ｖ＿０，ｖ＿１，ｖ＿２）｜ｖ０＝｛ｖ＿Ａ，ｖ＿Ｂ，ｖ＿ｃ｝、ｖ１＝｛ｖ＿Ｄ，ｖ＿Ｅ｝、ｖ２＝｛ｖ＿Ｇ，ｖ＿Ｈ｝｝を含む候補が隣接ブロックを使用して生成される。図２５で示すように、ｖ＿０は、ブロックＡ、Ｂ、またはＣの動きベクトルから選択される。隣接ブロックからの動きベクトルは、参照リスト、隣接ブロックに対する参照のＰＯＣ、現ＣＵに対する参照のＰＯＣ、および現ＣＵのＰＯＣの関係によってスケーリングされる。また、隣接ブロックＤおよびＥからｖ＿１を選択するためのアプローチ（接近）と、ＦとＧからｖ＿２を選択するためのアプローチと、は類似する。候補リストが４より大きい場合、候補は、（３つの候補における２つの動きベクトルと同様に）隣接動きベクトルの一貫性によって整列され、最初の４つの候補が記憶される。

候補リストの数が４より小さい場合、リストは、各ＡＭＶＰ候補を複製することによって（duplicating）構成される動きベクトルトリプルによりパディングされ得る。

現ＣＵのＣＰＭＶが導出された後、アフィンパラメータの数によって、現ＣＵのＭＶＦが４－パラメータアフィンモデルに対する下記の数式１１によって生成され、６－パラメータアフィンモデルに対する下記の数式１２によって生成される。

＜数式１１＞

＜数式１２＞

ここで、サブブロックのサイズＭｘＮは、下記の数式１３で導出され、ＭｖＰｒｅは、動きベクトル部分の精度（正確度）（１／１６）である。

＜数式１３＞

数式１２により導出された後、ＭおよびＮは、ｗおよびｈの分母（divisor）にするために必要であれば下方修正しなければならない。ＭまたはＮが８より小さい場合、ＷＩＦが適用され、そうでなければ、サブブロックベースのアフィン動き補償が適用される。

図２６は、本発明の実施例にかかるサブブロック単位のアフィン動きベクトルフィールドを導出する方法の一例を示す。

図２６を参照すると、各ＭｘＮのサブブロックの動きベクトルを導出するために、図２６に示すような各サブブロックの中央サンプルの動きベクトルは、数式１１または数式１２によって計算され、１／１６部分の精度で丸められる（rounded）。ＳＨＶＣアップ（上方）サンプリング補間フィルタが、導出された動きベクトルを使用して各サブブロックの予測を生成するために適用される。

ＨＥＶＣ動き補償補間フィルタと同一のフィルタ長さおよび正規化因子を有するＳＨＶＣアップサンプリング補間フィルタは、更なる部分（端数）ペル位置（additional fractional pel positions）に対する動き補償補間フィルタとして使用され得る。クロマ成分の動きベクトルの精度は、１／３２サンプルであり、１／３２ペル部分の位置の更なる補間フィルタは、２つの隣接する１／１６ペル部分の位置のフィルタの平均を使用することによって導出される。

ＡＦ＿ＭＥＲＧＥモードは、通常のマージモードの選択が行われるのと同じ方式でエンコーダ側で選択され得る。候補リストが優先的に生成され、候補で最小のＲＤ－コストが、他のインターモードのＲＤ－コストと比較するために選択される。比較の結果は、ＡＦ＿ＭＥＲＧＥが適用されるか否かに対する決定である。

ＡＦ＿４＿ＩＮＴＥＲモードのために、ＲＤコストの確認は、いずれの動きベクトルペアの候補が現ＣＵの制御点の動きベクトル予測（Control Point Motion Vector Prediction、ＣＰＭＶＰ）として選択されるかを決定するために使用される。現在のアフィンＣＵのＣＰＭＶＰが決定された後、アフィン動きの推定が適用され、制御点の動きベクトル（Control Point Motion Vector、ＣＰＭＶ）が獲得される。そうすると、ＣＰＭＶとＣＰＭＶＰとの差が決定される。

エンコーダ側で、ＡＦ＿ＭＥＲＧＥまたはＡＦ＿４＿ＩＮＴＥＲモードが以前のモード選択ステージで最適なモードとして決定される際にのみ、ＡＦ＿６＿ＩＮＴＥＲモードが確認される。

本発明の一実施例において、アフィンインター（アフィンＡＭＶＰ）モードは、下記のように行われ得る。

１）ＡＦＦＩＮＥ＿ＭＥＲＧＥ＿ＩＭＰＲＯＶＥ：アフィンモードである１番目の隣接ブロックを探索する代わりに、改善点（improvement）は、最大のコーディングユニットのサイズを有する隣接ブロックをアフィンマージ候補として探索しようとすることである。

２）ＡＦＦＩＮＥ＿ＡＭＶＬ＿ＩＭＰＲＯＶＥ：アフィンモードである隣接ブロックを通常のＡＭＶＰ手続と同様にアフィンＡＭＶＰ候補リストに追加する。

詳細なアフィンＡＭＶＰ候補リストの生成過程は、下記の通りである。

第一に、左側下の隣接ブロックがアフィン動きモデルを使用し、現在の参照インデックスと同一の参照インデックスを有するか否かが確認される。存在しなければ、左側の隣接ブロックが同じ方法で確認される。存在しなければ、左側下の隣接ブロックがアフィン動きモデルを使用し、異なる参照インデックスを有するか否かが確認される。存在すれば、スケーリングされたアフィン動きベクトルが参照ピクチャリストに追加される。存在しなければ、左側の隣接ブロックが同じ方式で確認される。

第二に、右側上部の隣接ブロック、上部の隣接ブロック、および左側上部の隣接ブロックが同じ方式で確認される。

前述した過程以降、２つの候補を探索すると、アフィンＡＭＶＰ候補リストを生成する動作を終了する。２つの候補を探索することができない場合、ＪＥＭソフトウェア内の元の動作がアフィンＡＭＶＰ候補リストを生成するために行われる。

３）ＡＦＦＩＮＥ＿ＳＩＸ＿ＰＡＲＡＭ：４－パラメータアフィン動きモデル以外に、６－パラメータアフィン動きモデルが更なるモデルとして追加される。

６－パラメータアフィン動きモデルが下記の数式１４を介して導出される。

＜数式１４＞

前述した動きモデルに６－パラメータが存在するので、左側上部の位置ＭＶ＿０、右側上部の位置ＭＶ＿１および左側下部の位置ＭＶ＿２における３つの動きベクトルがモデルを決定するために要求される。３つの動きベクトルが４－パラメータアフィン動きモデルで２つの動きベクトルと類似の方式で決定され得る。アフィンモデルマージは、常時６－パラメータアフィン動きモデルとして設定される。

４）ＡＦＦＩＮＥ＿ＣＬＩＰ＿ＲＥＭＯＶＥ：全てのアフィン動きベクトルに対する動きベクトルの制約（constraints）を除去する。動き補償の過程が動きベクトルの制約そのものを制御するようにする。

アフィン動きモデル（Affine motion model）

前述したように、アフィンインター予測（Affine inter prediction）で様々なアフィン動きモデル（affine motion model）が使用または考慮され得る。例えば、アフィン動きモデルは、前述した図１４のように、４つの動きを表現し得る。アフィン動きモデルが表現し得る動きのうち、３つの動き（トランスレーション（translation）、スケール（scale）、ローテート（rotate））を表現するアフィン動きモデルは、類似アフィン動きモデル（similarity (or simplified) affine motion model）といえる。上記アフィン動きモデルのうち、どのモデルを使用するかによって、導出されるＣＰＭＶの数および／または現ブロックのサンプル／サブブロック単位のＭＶの導出方法が変わり得る。

本発明の一実施例において、適応的な４つおよび６つのパラメータ動きモデルが使用される。ＡＦ＿ＩＮＴＥＲで、６－パラメータ動きモデルがＪＥＭで存在する４－パラメータ動きモデルに加えて提案される。６－パラメータアフィン動きモデルが下記の数式１５のように説明される。

＜数式１５＞

ここで、係数ａ、ｂ、ｃ、ｄ、ｅ、およびｆは、アフィン動きパラメータであり、（ｘ，ｙ）および（ｘ’，ｙ’）は、アフィン動きモデルの変換以前および以降のピクセル位置の座標である。ビデオコーディングでアフィン動きモデルを使用するために、ＣＰＭＶ０、ＣＰＭＶ１、およびＣＰＭＶ２が、ＣＰ０（左上側）、ＣＰ１（右上側）、およびＣＰ２（左下側）に対するＭＶであれば、数式１６が下記のように説明され得る。

＜数式１６＞

ここで、ＣＰＭＶ＿０＝｛ｖ＿０ｘ，ｖ＿０ｙ｝、ＣＰＭＶ＿１＝｛ｖ＿１ｘ，ｖ＿１ｙ｝、ＣＰＭＶ＿２＝｛ｖ＿２ｘ，ｖ＿２ｙ｝、ならびに、ｗおよびｈは、それぞれコーディングブロックの幅（width）および高さ（height）である。数式１６は、ブロックの動きベクトルフィールド（Motion Vector Field、ＭＶＦ）である。

フラグが、隣接ブロックがアフィン予測でコーディングされた際に４－パラメータまたは６－パラメータアフィン動きモデルが使用されるか否かを指示するために、ＣＵレベルでパージングされる。アフィン予測でコーディングされた隣接ブロックがなければ、フラグは省略され、４－パラメータのモデルがアフィン予測のために使用される。言い換えると、６－パラメータモデルは、１つまたは複数の隣接ブロックがアフィン動きモデルでコーディングされるという条件で考慮される。ＣＰＭＶＤの数に関して、２つおよび３つのＣＰＭＶＤが、４－パラメータおよび６－パラメータアフィン動きモデルに対してそれぞれシグナリングされる。

また、本発明の一実施例において、パターンマッチングされた動きベクトル加工（pattern-matched motion vector refinement）が使用され得る。ＪＥＭのパターンマッチングされた動きベクトル導出（ＪＥＭのエンコーダの説明で、名付けてＰＭＭＶＤ、以下ＰＭＶＤと略称）において、デコーダは、ＣＵレベルの探索のために開始のＭＶ候補を決定するために、いくつかの動きベクトル（Motion Vector、ＭＶ）を評価する必要がある。サブＣＵレベルの探索で、最適なＣＵレベルのＭＶに加えて、いくつかのＭＶ候補が追加される。デコーダは、最適なＭＶを探索するために、このようなＭＶ候補を評価する必要があり、これは、多くのメモリ帯域を要求する。提案されたパターンマッチング（キャッチング）された動きベクトル精製（Pattern-Matched Motion Vector Refinement、ＰＭＶＲ）で、ＪＥＭでＰＭＶＤにおけるテンプレートマッチング（template matching）および両方向マッチング（bilateral matching）のコンセプトが採択される。ＰＭＶＲが使用可能か否かを指示するために、スキップモードまたはマージモードが選択された際、１つのＰＭＶＲ＿ｆｌａｇがシグナリングされる。ＰＭＶＤと比較し、意味あるようにメモリ帯域幅の要求を減少させるために、ＭＶ候補リストが生成され、ＰＭＶＲが適用されると、開始のＭＶ候補のインデックスが明示的にシグナリングされる。

マージ候補リストの生成プロセスを使用することによって候補リストが生成されるが、サブＣＵマージ候補、例えば、アフィン候補およびＡＴＭＶＰ候補は除外される。両方向マッチング（bilateral matching）のために、ただ単方向予測（uni-prediction）ＭＶ候補のみが含まれる。両方向予測（bi-prediction）ＭＶ候補は、２つの単方向予測ＭＶ候補に分割される。また、（ＭＶの差が予め定義された閾（臨界）値より少ない）類似のＭＶ候補がやはり除去される。ＣＵレベルの探索のために、ダイヤモンド探索ＭＶ精製（diamond search MV refinement）がシグナリングされたＭＶ候補から始めて行われる。

サブＣＵレベルの探索は、ただ両方向マッチングマージモード（bilateral matching merge mode）でのみ使用可能である。全てのサブＣＵに対するサブＣＵレベルの探索の探索ウィンドウは、ＣＵレベルの探索の探索ウィンドウと同一である。したがって、更なる帯域幅がサブＣＵレベルの探索において要求されない。

モードでＭＶＰを精製するために、テンプレートマッチングも使用される。ＡＭＶＰモードで、２つのＭＶＰがＨＥＶＣ ＭＶＰ生成プロセスを使用することによって生成され、１つのＭＶＰインデックスがそれらのうちの１つを選択するためにシグナリングされる。選択されたＭＶＰは、ＰＭＶＲでテンプレートマッチングを使用することによってさらに精製される。適応的動きベクトル解像度（Adaptive Motion Vector Resolution、ＡＭＶＲ）が適用されると、テンプレートマッチングの精製以前に、ＭＶＰは、該当する精度で丸められる（rounded）。このような精製過程は、パターンマッチングされた動きベクトル予測子精製（Pattern-Matched Motion Vector Predictor Refinement、ＰＭＶＰＲ）と名付けられる。本文書の残りで特に定義しなければ、ＰＭＶＲは、テンプレートマッチングＰＭＶＲ、両方向マッチングＰＭＶＲ、およびＰＭＶＰＲを含む。

メモリ帯域幅の要求を減少させるために、ＰＭＶＲは、４ｘ４、４ｘ８、および８ｘ４のＣＵに対して使用できなくなる。更なるメモリ帯域幅の要求量の減少のために、６４と同一のＣＵ領域に対する｛テンプレートマッチング、両方向マッチング｝の探索範囲が｛±２，±４｝と縮小し得、６４より大きいＣＵ領域に対する｛テンプレートマッチング、両方向マッチング｝の探索範囲が｛±６，±８｝と縮小し得る。本文書のＰＭＶＲセクションで説明された前述した全ての方法を使用することによって、ＨＥＶＣにおける最悪の場合に比べて、要求されるメモリ帯域幅がＪＥＭ－７．０のＰＭＶＤで４５．９ｘからＰＭＶＲで３．１ｘと減少した。

ＨＭＶＰ（History-based Motion Vector Prediction）一般

一般に、映像圧縮技術は、２つの主要な技法として空間的および時間的冗長（重複）性（redundancy）に対する探索（exploiting）を用いる。例えば、ＨＥＶＣ（High Efficiency Video Coding、ＨＥＶＣ）およびＶＶＣは、いずれもインターコーディング（inter coding）に基づいて（の基底で）２つの動き圧縮技法を使用する。１つは、マージ（merge）動きであり、もう１つは、ＡＭＶＰ（Advanced Motion Vector Prediction）である。このような２つの予測モードに対する改善のために、様々な変更（modifications）が議論されている。これらは、候補の数を増加させることから始めて、より空間的に拡張される候補に対する探索、および非慣習的な（non-traditional）位置における時間的候補を検査することなどを含む。このような２つの技法は、一次的に可能な候補でリストを構成し、ＲＤ（Rate Distortion）コストを最小にし、ビットストリームで選択された候補をシグナリングする。

特に、最近の映像圧縮技術では、以前にコーディングされたブロックの動き情報を記憶し、記憶された動き情報を以降でコーディングされるブロックの動き予測に用いるＨＭＶＰ（History-based Motion Vector Prediction）が議論される。このようなＨＭＶＰは、マージリスト（または、マージ候補リスト）またはＡＭＶＰリスト（またはＡＭＶＰ候補リスト）に追加され得る。

デコーダは、ＨＭＶＰのためにＦＩＦＯ（First In First Out）システム（または方式）で動作するＬＵＴ（Look-Up Table）を維持する。本明細書において、ＬＵＴは、その名称に制限されず、テーブル、ＨＭＶＰテーブル、ＨＭＶＰ候補テーブル、バッファ、ＨＭＶＰバッファ、ＨＭＶＰ候補バッファ、ＨＭＶＰリスト、ＨＭＶＰ候補リストなどと称される。具体的には、非アフィン（non-affine）ＰＵ（Prediction Unit）（または、ＣＵ（Coding Unit））がデコードされる際、その動き情報は、ＬＵＴに記憶され、デコーダは、次のＰＵに対するデコーディングを進める。この際、記憶される動き情報は、ｘ（水平）およびｙ（垂直）方向の動きベクトル、参照インデックス情報、ならびにモード情報などを含み得る。

デコーダは、漸進的に（progressively）デコードされた非アフィン候補の動き情報が記憶されるＬＵＴを維持することができる。ＬＵＴのサイズは、予め定義されたＳ個の候補に制限され得る。一実施例として、ＬＵＴは、スライスの開始、ＣＴＵ行の開始、またはＣＴＵの開始でリセット（reset）され得る。

ＨＭＶＰは、マージモードおよびＡＭＶＰモードでいずれも適用され得る。マージリストは、Ｂ個の候補を有し得、ＡＭＶＰリストは、２つの候補を有し得る。従来の映像圧縮技術で、マージリストは、次の候補で構成される：ｉ）空間候補、ｉｉ）時間候補、ｉｉｉ）両方向予測（Ｂｉ－Ｐｒｅｄ）候補、ｉｖ）ゼロ動き候補（zero motion candidate）。最近、ＡＴＭＶＰ（Advanced Motion Vector Prediction）がさらに候補として考慮される方法が議論される。一例として、ＡＴＭＶＰ候補は、時間候補以前にマージリストに挿入され得る。マージリストの候補は、最大のマージリストのサイズに到達するまでマージリストに追加される。重複候補（duplicate candidate）は、マージリストに追加されなくてもよい。ＡＭＶＰリストは、２つの候補が挿入され得る。一例として、２つの候補のうちの１つは、使用可能な空間候補から選択され、２番目の候補は、時間候補から選択され得、リストが満たされない場合、ゼロ動きベクトル候補が追加され得る。

ＨＭＶＰは、ＬＵＴで候補が投入された順序と同じようにテーブルから取り出される（抜け出す）ＦＩＦＯベースで適用される。

一実施例において、ＨＭＶＰがマージリストの構成に適用される際、ＨＭＶＰ候補は、下記のようにリストの３番目の位置に挿入（または追加）され得る。

１．空間候補（Spatial Candidate）

２．時間候補（Temporal Candidate）

３．ＬＵＴに対する最大Ｓ個のＨＭＶＰ候補（Up to S HMVP Candidates for a LUT）

４．結合された両方向予測候補（Combined Bi-Pred Candidate）

５．ゼロ動きベクトル候補（Zero Motion Vector Candidate）

一実施例において、ＨＭＶＰがＡＭＶＰリストの構成に適用される際、ＨＭＶＰは、下記のように時間候補以降、３番目の位置に挿入され得る。

１．空間的候補（Spatial Candidate）

２．時間的候補（Temporal Candidate）

３．最大Ｋ個のＨＭＶＰ候補（Up to K HMVP Candidates）

４．ゼロ動きベクトル候補（Zero Motion Vector Candidate）

図２７は、本明細書の実施例にかかるＨＭＶＰを記憶する方法を説明するフローチャートである。

図２７を参照すると、デコーダは、現ＰＵ（またはＣＵ）をデコードする（Ｓ２７０１）。

デコーダは、現ＰＵが非アフィンモードでコーディングされたブロックであるかを確認する（Ｓ２７０２）。ＨＭＶＰ候補の使用を容易にするために、現ＰＵがアフィンモードでコーディングされたブロックである場合、デコーダは、現ＰＵの動き情報をテーブルに記憶しない。

現ＰＵが非アフィンモードでコーディングされたブロックである場合、デコーダは、現ＰＵの動き情報をテーブルに記憶（またはアップデート）する（Ｓ２７０３）。

本明細書の実施例において、ＨＭＶＰテーブルは、２つの方法、すなわち、ｉ）非制限的ＦＩＦＯ（unconstrained FIFO）、ｉｉ）制限的ＦＩＦＯ（constraint FIFO）方法でアップデートされ得る。前者において、重複する動き情報が存在し得るが、淘汰プロセスは適用されない。これは、全般的なプロセスの複雑度を低減させるのに寄与する。一方、後者において、淘汰プロセスが適用され、ＨＭＶＰテーブル内の重複する動き情報は存在しない。下記の図を参照して説明する。

図２８は、本明細書の実施例にかかる非制限的ＦＩＦＯ方式で動作するＨＭＶＰテーブルを説明する図である。

図２８を参照すると、テーブルに追加される候補は、テーブルの終端（右側）に追加される。反面、ＦＩＦＯ方式によってテーブルで排出される候補は、テーブルの前端（左側、最も古い候補）に位置する。

インデックスＬ－１（すなわち、終端）において、テーブルが予め定義された最大数の候補で完全に満たされなければ、除去される候補なく、新しい候補が追加される。反面、テーブルが既に完全に満たされた場合、すなわち、テーブルの最大数を満たす場合、テーブルで最も古い前端に位置する候補が除去され、新しい候補が追加される。

図２９は、本明細書の実施例にかかる制限的ＦＩＦＯ方式で動作するＨＭＶＰテーブルを説明する図である。

図２９を参照すると、制限的ＦＩＦＯが使用される場合、新しい候補を追加することが重複を引き起こす場合（すなわち、新しい候補が重複する動き情報を有する場合）淘汰が行われる。実施例として、重複する動き情報を有する候補がテーブルに存在すると、テーブル内の重複する候補は除去され、現在の候補の動き情報が追加され得る。

ＨＭＶＰ候補に対して、多くの場合で最も最近の履歴ＭＶが空間候補（または空間隣接候補）の動き情報と重複し得る。したがって、本実施例では、ＨＭＶＰ候補をＡＭＶＰまたはマージリストに追加する際、候補の追加順序をＨＭＶＰ ＬＵＴインデックスの順序と異なって設定する方法を提案する。

本明細書の実施例によれば、ＨＭＶＰ候補を適応的に調節することによって、候補リストを効率的に構成でき、これを介して、二値化（binarization）に使用されるシグナリングビンの数を減少させ、コーディング効率を高めることができる。すなわち、マージリストまたはＡＭＶＰリストに追加されるＨＭＶＰ候補は、ＨＭＶＰリスト内のインデックスにより制限されないことがある。一実施例として、次の表１は、ＡＭＶＰまたはマージリストにＨＭＶＰ候補を追加する順序を変更する方法を例示する。

＜表１＞

表１を参照すると、前述したように、最も最近に挿入されたＨＭＶＰ候補は、空間候補の動き情報と同一である可能性が高いため、これを考慮し、ＨＭＶＰ候補の追加順序をＨＭＶＰインデックスと関係なく予め定義し得る。

また、一実施例において、エンコーダ／デコーダは、ＨＭＶＰリスト内でｎ番目の候補から始まるＨＭＶＰ候補からマージリストまたはＡＭＶＰリストに追加し得る。次の表２は、ＡＭＶＰまたはマージリストに候補を追加する変更された順序を例示する。

＜表２＞

表２を参照すると、ＨＭＶＰ候補は、２番目のインデックスからマージリストまたはＡＭＶＰリストに追加され得る。

一実施例において、テーブル（ＬＵＴ）内におけるＨＭＶＰ候補の追加順序に関する情報は、エンコーダからデコーダにシグナリングされ得る。例えば、このような順序の情報は、上位レベルのシンタックス（High Level Syntax、ＨＬＳ）を介して送信され得る。上記上位レベルのシンタックスは、例えば、シーケンスパラメータセット（sequence parameter set）、ピクチャパラメータセット（picture parameter set）、スライスヘッダ（slice header）、コーディングツリーユニット（coding tree unit）、コーディングユニット（coding unit）および／または他の適切なシンタックスデータヘッダであり得る。

下記の表３は、本明細書で提案する方法が適用され得る上位レベルのシンタックス構造を例示する。

＜表３＞

表３を参照すると、ｓｅｔ＿ＨＭＶＰ＿ｏｒｄｅｒ＿ｆｌａｇが１であることは、ｓｅｔ＿ＨＭＶＰ＿ｏｒｄｅｒ＿ｆｌａｇがＣＶＳで非ＩＤＲ（non-IDR）ピクチャ内のスライスヘッダで存在することを指示する。ｓｅｔ＿ＨＭＶＰ＿ｏｒｄｅｒ＿ｆｌａｇが０であることは、ｓｅｔ＿ＨＭＶＰ＿ｏｒｄｅｒ＿ｆｌａｇがスライスヘッダで存在せず、ＶＣＳで適応的ＨＭＶＰが使用されないことを指示する。

下記の表４は、本明細書で提案する方法が適用され得るスライスセグメントヘッダシンタックス構造を例示する。

＜表４＞

表４を参照すると、ｓｌｉｃｅ＿ＨＭＶＰ＿ｉｄｘは、使用される候補の順序に対するインデックスを意味する。例えば、ｓｌｉｃｅ＿ＨＭＶＰ＿ｉｄｘが０であることは、０、１、２、３などの基本ＨＭＶＰの順序を表現し得る。同様に、１のインデックス値は、３、２、１、０のＨＭＶＰ順序を表現するために使用され得る。

また、本明細書の一実施例において、ＨＭＶＰ ＬＵＴに加えて、ロングタームリスト（long term list）を動き予測のために使用する方法を提案する。これを介して、維持されるＨＭＶＰ候補の数を増加させ得る。実施例として、２－ＨＭＶＰテーブルを考慮し得、ここで、１つは、一般ＨＭＶＰ候補を保管し、もう１つは、維持がさらに必要な候補をさらに保管するロングターム（long term）リストに使用できる。

次は、ロングタームリスト（または、ロングタームＨＭＶＰリスト）を初期化して構成する方法を例示する。

－ ＣＴＵ行の１番目のＣＴＵをデコードした後、以降のＣＴＵの１つまたは複数の履歴ＭＶがロングタームＨＭＶＰ ＬＵＴに追加され得る。このようなロングタームＨＭＶＰ ＬＵＴは、次のＣＴＵ行まで使用されるか、アップデートされないことがある。

－ 次のＣＴＵ行の開始で、ロングタームＨＭＶＰ ＬＵＴが、通常のＨＭＶＰ ＬＵＴを初期化するために使用され得る。その理由は、ＣＴＵ行の開始でＣＴＵのＨＭＶＰ候補が以前のＣＴＵ行の端における履歴ＭＶよりさらに互いに関連（co-relate）し得るためである。

－ 前述したプロセスは、繰り返され得る。

図３０は、本明細書の実施例にかかるＨＭＶＰ ＬＵＴ、およびロングタームＨＭＶＰ ＬＵＴを例示する図である。

図３０を参照すると、エンコーダ／デコーダは、ＨＭＶＰ候補を記憶するための２つのＬＵＴを含み得る。このうちの１つは、ＨＭＶＰ ＬＵＴ（または、一般ＨＭＶＰ ＬＵＴ、ショートタームＨＭＶＰ ＬＵＴ）であり、もう１つは、ロングタームＨＭＶＰ ＬＵＴであり得る。ＨＭＶＰ候補は、マージまたはＡＭＶＰリストに全て追加される際、図３０に示すように、ＨＭＶＰ ＬＵＴまたはロングタームＬＵＴから追加され得る。

前述したロングタームＬＵＴの使用は、新しいシンタックスエレメントを用いてシグナリングされ得る。実施例として、上記シンタックスエレメントは、上位レベルのシンタックスを介してシグナリングされ得る。例えば、シンタックスエレメントは、シーケンスパラメータセット（sequence parameter set）、ピクチャパラメータセット（picture parameter set）、スライスヘッダ（slice header）、コーディングツリーユニット（coding tree unit）、コーディングユニット（coding unit）および／または他のシンタックスデータヘッダに存在し得る。

また、本明細書の一実施例において、ＨＭＶＰ候補をＨＭＶＰ ＬＵＴに追加するにあたって、デコーディングのための柔軟性（flexibility）を考慮する方法を提案する。エンコーダ／デコーダは、ＨＭＶＰ候補をテーブルに追加するにあたって、ＰＵ（またはＣＵ）の１つまたは複数の特性に対する決定（decision）の基準を考慮し得る。

実施例として、エンコーダ／デコーダは、ＨＭＶＰ候補をテーブルに追加するにあたって、次のような事項を考慮し得る。エンコーダ／デコーダは、ＰＵのモード（例えば、マージモード、アフィンモード、ＡＭＶＰモードなど）および／またはブロックのサイズなどの特性を、個別にまたは組み合わせて考慮して候補として追加し得る。一実施例において、これ以外に他の更なる特性が考慮されることもある。例えば、ＨＭＶＰ ＬＵＴのアップデートを考慮するマージタイプ（例えば、空間候補または時間候補）、サブＰＵであるか否かなどが、候補の選択基準として考慮され得る。前述した選択基準は、以前の履歴（または、以前のＨＭＶＰ）との重複を減少させるために決定され得る。例えば、ＰＵがマージモードでコーディングされ、マージタイプが空間マージである場合、デコーダは、該当ＰＵの動き情報でＨＭＶＰ ＬＵＴをアップデートしなくてもよい。

図３１は、本明細書の実施例にかかるＨＭＶＰ ＬＵＴをアップデートする方法の一例を示す図である。

図３１を参照すると、エンコーダ／デコーダは、コーディングされた候補の動き情報を獲得する（Ｓ３１０１）。

エンコーダ／デコーダは、上記候補の動き情報でＬＵＴをアップデートするか否かを予め定義された決定の基準によって評価する（Ｓ３１０２）。前述したように、上記決定の基準は、上記候補のモード（例えば、マージモード、アフィンモード、ＡＭＶＰモードなど）、上記候補のブロックサイズおよび／または上記候補のマージタイプの少なくとも１つに関する特性を含み得る。

エンコーダ／デコーダは、上記決定の基準に基づいてＬＵＴをアップデートする（Ｓ４３０３）。すなわち、上記候補が予め定義された決定の基準を満たす場合、エンコーダ／デコーダは、上記候補の動き情報をＬＵＴに追加し得る。

また、本明細書の一実施例において、ＨＭＶＰ候補をマージリスト（またはＡＭＶＰリスト）に追加するための冗長性チェックに対する制限を提案する。冗長性チェックに対する制限は、様々な方法で定義（または実現）され得る。

一実施例において、エンコーダ／デコーダは、マージリスト内の最初の特定数の候補に対する淘汰チェックの数を制限し得る。実施例として、エンコーダ／デコーダは、マージリストの１番目の候補から特定数番目の候補までの候補に対する淘汰チェックの数を制限し得る。例えば、エンコーダ／デコーダは、マージリストの１番目の候補から特定数番目の候補までの候補に対する淘汰プロセスを行うことができる。また、淘汰チェックの対象になるＨＭＶＰ候補は、予め定義された数に制限され得る。

また、一実施例において、エンコーダ／デコーダは、淘汰チェックをマージリスト内のマージ候補の特定タイプに対して行うことによって、淘汰チェックを制限し得る。例えば、エンコーダ／デコーダは、ＨＭＶＰ候補を追加するにあたって、マージリストの空間候補に対してのみ淘汰チェックを行うことができる。あるいは、例えば、エンコーダ／デコーダは、ＨＭＶＰ候補を追加するにあたって、マージリストの空間候補の一部に対してのみ淘汰チェックを行うことができる。上記空間候補の一部は、予め定義され得る。例えば、上記予め定義される空間候補の一部は、左側の隣接空間候補および／または上側の隣接空間候補の少なくとも１つであってもよい。あるいは、例えば、エンコーダ／デコーダは、ＨＭＶＰ候補を追加するにあたって、マージリストの空間候補の一部に対してのみ淘汰チェックを行うことができ、上記空間候補の一部は、左側および上側に予め定義され得る。前述した例により、本明細書の実施例がこれに制限されるわけではなく、様々なタイプのマージ候補が組み合わされ、淘汰チェックの対象に制限され得る。

図３２は、本明細書の実施例にかかる淘汰チェックの対象になるＨＭＶＰ候補の数を制限する方法を例示する図である。

図３２を参照すると、本明細書の一実施例において、淘汰チェックの対象になるＨＭＶＰ候補の数は、Ｍ個に制限され得る。エンコーダ／デコーダは、ＨＭＶＰ候補を用いてマージリストを構成するにあたって、ＨＭＶＰ ＬＵＴ内のＭ個の候補と上記マージリストのマージ候補との間の動き情報の冗長性をチェックすることができる。

あるいは、エンコーダ／デコーダは、現在デコードされた処理ブロック（例えば、ＰＵ）の動き情報をＨＭＶＰ ＬＵＴに追加するにあたって、ＨＭＶＰ ＬＵＴ内のＭ個の候補と上記デコードされたＰＵとの動き情報の間の冗長性をチェックできる。

図３３は、本明細書の実施例にかかる淘汰チェックの実行方法の一例を示すフローチャートである。

図３３を参照すると、エンコーダ／デコーダは、デコードされた候補の動き情報を獲得し、淘汰チェックの数を決定（またはデコード（復号（解読）））する（Ｓ３３０１、Ｓ３３０２）。上記淘汰チェックの数は、上記で説明した（例えば、図３２で説明した）方法によって、エンコーダ／デコーダにおいて予め定義され得る。エンコーダ／デコーダは、決定された淘汰チェックの数に基づいて、淘汰チェックを行う（Ｓ４５０３）。

一実施例において、上記表３および表４と同様の方法で、淘汰チェックに関する情報は、上位レベルのシンタックスを介してシグナリングされ得る。この際、エンコーダからデコーダへ送信されるシンタックスエレメントは、淘汰チェックの数を指示するために、特定の上位レベルのシンタックスを介してシグナリングされ得る。上記上位レベルのシンタックスは、例えば、シーケンスパラメータセット（sequence parameter set）、ピクチャパラメータセット（picture parameter set）、スライスヘッダ（slice header）、コーディングツリーユニット（coding tree unit）、コーディングユニット（coding unit）および／または他のシンタックスデータヘッダに含まれ得る。

本明細書の一実施例において、ＨＭＶＰ候補を選択する効率的な方法を提案する。履歴動きベクトル候補（すなわち、ＨＭＶＰ候補）をマージリスト（またはＡＭＶＰリスト）に挿入する際、ＨＭＶＰ候補は、既存のマージリストと重複しないようにするために、淘汰チェックが行われ得る。この際、Ｍの大きさのマージリストとＮの大きさの履歴ＬＵＴとの間の全体の冗長性チェックを行うためには、（Ｍ－１）ｘＮ回のチェックを必要とする。

したがって、本明細書の実施例において、ＨＭＶＰ候補の数は、マージ候補に依存し得る。例えば、ＨＭＶＰ候補の数は、マージリストに存在する空間候補の数に依存し得る。あるいは、例えば、ＨＭＶＰ候補の数は、マージリストに存在する空間候補および時間候補の数に依存し得る。

マージリストに存在するマージ候補がさらに存在する場合、マージリストのマージ候補の数および／またはＨＭＶＰの数に基づく特定の基準（または規則）に従って、淘汰チェックを行うＨＭＶＰ候補の数が減少し得る。これを通じて、最悪のケースにおける冗長性チェックの数が減ることがある。

例えば、大きさ（または長さ）が６であるマージリストの場合、マージリストが満たされなければ、マージリストは、最大５個の空間または他のマージ候補を含み得る。６個のＨＭＶＰリストでＨＭＶＰ候補を挿入するためには、最悪の場合、３０個の冗長性チェックが必要であるかもしれない。

一実施例において、淘汰チェックの対象になるＨＭＶＰの数に対する制限に関する例は、次の数式１７および表５の通りである。

＜数式１７＞
if (existing_candidates >= 3)
number_hist_to_check = 7 - existing_candidates

＜表５＞

表５を参照すると、淘汰チェックの対象になるＨＭＶＰの数を２つに制限することによって、最悪のケースで、ＨＭＶＰの追加のための冗長性チェックの数は、３０回の代わりに１２回と減少し得る。

本明細書の一実施例において、履歴ベース空間時間動きベクトル予測（History-Based Spatial Temporal Motion Vector Prediction、Ｈ－ＳＴＭＶＰ）を使用してマージリストを構成する方法を提案する。Ｈ－ＳＴＭＶＰは、２つの履歴ベース空間ＭＶＰおよびＴＭＶＰの平均として導出される候補を表す。上記２つの空間ＨＭＶＰは、ＨＭＶＰバッファから獲得され得、上記ＴＭＶＰは、現在のマージリストから獲得され得る。ここで、上記空間候補は、現ブロックの以前のデコーディング順序で最後の２つのコーディングされたＭＶから獲得された候補であり得る。

例えば、最後にコーディングされたＭＶ（本明細書でＭＶ＿Ｌと称する）、最後から２番目にコーディングされたＭＶ（本明細書でＭＶ＿（Ｌ－１）と称する）、およびＭＶ＿ＴＭＶＰは、マージリストに挿入されるＨ－ＳＴＭＶＰ候補を生成するのに使用され得る。

前述した３つの候補を全て使用できる場合、マージリストに追加されるＭＶは、次の数式１８により計算され得る。

＜数式１８＞

一実施例として、前述した３つの候補のうちの２つのみが利用可能であれば、２つの候補に対してのみ平均化され、Ｈ－ＳＴＭＶＰが生成され得る。同様に、１つの候補のみ使用可能であれば、上記１つの候補のみ使用され得る。使用可能な候補がない場合、Ｈ－ＳＴＭＶＰは、マージリストの構成に使用されなくてもよい。

本明細書の一実施例において、前述した数式１８以外に他の方法を利用し、Ｈ－ＳＴＭＶＰ候補の動きベクトルを獲得する方法を提案する。

例えば、３つ以上の候補を一度に平均化する代わりに、空間候補を先に平均化した後、この結果を使用して２つの候補を再度平均化することが計算的にさらに簡単であるかもしれない。これに関する例は、次の数式の通りである。

＜数式１９＞

あるいは、次のように平均値を獲得することもできる。

＜数式２０＞

＜数式２１＞

＜数式２２＞

エンコーダ／デコーダは、数式１９乃至２１のように、まず、２つの候補を平均し、３番目の候補を用いて結果値を最終的に平均化できる。あるいは、エンコーダ／デコーダは、数式２２のように、２だけシフト演算を適用することによって、候補、すなわち、ＭＶ＿Ｌにさらに高い重要度／重みを付与し得る。前述した数式１９乃至２２を使用し、シフト演算だけで割り算の演算なしで平均値を導出し得る。

本明細書の一実施例において、Ｈ－ＳＴＭＶＰを導出するにあたって、２つの履歴ベース空間候補の代わりに、任意の数（ｎ）の空間候補を使用する方法を提案する。これらのｎ個の候補は、必ずしも連続するデコーディング順序である必要はない。任意に、または一部の規則に従って選択できる。

したがって、上記で説明した数式１８は、次の数式２３のようにより一般的な方式で表現され得る。

＜数式２３＞

別の一実施例において、５つの空間候補を使用する場合を仮定すると、時間候補に適用される重みを向上させることによって、Ｈ－ＳＴＭＶＰ候補を生成するために増加した空間候補の影響を最小にし、空間候補および時間候補を適切に反映することができる。

したがって、このために次の数式２４を用いて空間候補を共に平均した後、その結果を使用してＭＶ＿ＴＭＶＰを平均化することによって、前述した目的を達成することができる。

＜数式２４＞

本明細書の一実施例において、Ｈ－ＳＴＭＶＰを導出するために用いられる動きベクトル候補に重み（加重値）（または加重因子）を追加する方法を提案する。この際、上記重みは、経験的に決定されることもあり、固定された参照フレームまでの時間距離を考慮して決定されることもあり、または履歴テーブルにおける位置を考慮することによって決定されることもある。一例として、新しい候補は、以前の候補よりさらに多くの重みを有し得る。

すなわち、例において、本実施例において、上記で説明した数式１８は、次の数式２５のように表現され得る。

＜数式２５＞

この際、重みは、同じ値を有してもよく、不均等に分散された値を有してもよい。

本明細書の一実施例において、Ｈ－ＳＴＭＶＰ候補を導出するために使用される動きベクトルを単一参照ピクチャとしてスケーリングする方法を提案する。

図３４は、本明細書の一実施例にかかる互いに異なる参照ピクチャを参照する動きベクトルを用いて、Ｈ－ＳＴＭＶＰ候補を導出する方法を説明する図である。

図３４を参照すると、ＭＶ＿Ｌ、ＭＶ＿Ｌ－１、およびＭＶ＿ＴＭＶＰ候補は、それぞれ互いに異なる参照ピクチャを参照（または指示）する場合を仮定する。すなわち、図３４は、Ｈ－ＳＴＭＶＰ候補を生成するのに使用された各候補が異なる参照インデックスを有し得、結果として、異なる参照フレームを有し得ることを示す。

近接の参照フレームのあるフレームが、本質的にＨ－ＳＴＭＶＰの動きベクトルにさらに大きな影響を与え得るので、前述した数式１８乃至２５の平均を不均等な結果値にし得る。したがって、均等な比較および反映のために、全ての動きベクトルを単一参照フレームにスケーリングする方法を提案する。

この際、エンコーダでＲＤの最適化の一部として行われ、どの単一フレームが参照フレームに使用するのに最適であるかを決定し得る（エンコーダは、ＲＤの最適化の一部として行われたどの単一フレームが、参照フレームとして使用するのに最適であるかを決定し得る（the encoder may determine which single frame performed as part of RD optimization is most suitable for being used as a reference frame））。実施例として、選択された参照フレームは、スライスヘッダに存在するＴＭＶＰ配列インデックスと類似のスライスヘッダでシグナリングされ得る。例えば、固定された規則を使用し、使用される参照フレームを生成することが可能である。あるいは、例えば、Ｌ０から１番目に利用可能な参照（基準）フレームにスケーリングされるか、現ピクチャの順序のカウントに基づいてスケーリングされ得る。

一実施例において、前述した目的を達成するために、シーケンスパラメータセット、ピクチャパラメータセット、スライスヘッダ、コーディングツリーユニットおよび／または他のデータヘッダの一部であり得る上位レベルのシンタックス（ＨＬＳ）を用いて、単一の固定されたピクチャに関する情報を、エンコーダがデコーダへ送信し得る。例えば、次の表６および／または表７のような上位レベルのシンタックス構造が定義され得る。

＜表６＞

表６を参照すると、ｓｅｔ＿ＨＳＴＭＶＰ＿ｒｅｆ＿ｐｉｃ＿ｆｌａｇが１と同一である場合、ｓｅｔ＿ＨＳＴＭＶＰ＿ｉｄｘがＣＶＳで非ＩＤＲピクチャのスライスヘッダに存在することを示す。ｓｅｔ＿ＨＳＴＭＶＰ＿ｒｅｆ＿ｐｉｃ＿ｆｌａｇが０である場合、ｓｅｔ＿ＨＳＴＭＶＰ＿ｉｄｘがスライスヘッダに存在しないことを示す。

＜表７＞

表７を参照すると、ｓｌｉｃｅ＿ＨＭＶＰ＿ｉｄｘは、参照インデックスを指定する。一実施例として、参照インデックスは、リストＬ０に対して選択され得る。

本明細書の実施例において、上記で説明した実施例に関して、より詳細な実施例を説明する。具体的には、現ブロックのＣＰＭＶを計算（または導出）するために、位置および次元情報を使用してアフィンＨＭＶＰ候補を間接的に使用する方法を提案する。本明細書において、導出されたＣＰＭＶは、継承されたアフィンＨＭＶＰ候補と称され得る。本明細書の実施例にかかる継承されたアフィンＨＭＶＰ候補は、前述したアフィンマージリストおよび／またはアフィンＡＭＶＰリストの生成プロセスで使用され得る。

図３５は、本明細書の実施例にかかる継承されたアフィンＨＭＶＰ候補を導出するためのブロックの位置を例示する図である。

図３５を参照すると、アフィンＨＭＶＰ候補の位置および次元に基づいて、現ブロック３５０１のＣＰＭＶは、一般的な継承されたＣＰＭＶを周辺ブロックから導出する方法と類似の方法で導出され得る。すなわち、エンコーダ／デコーダは、アフィンＨＭＶＰ候補である参照ブロック３５０２の位置および次元（例えば、幅および高さ）の情報に基づいて、現ブロック３５０１の制御点の動きベクトルを導出し得る。

一実施例として、現ブロックの継承されたアフィンＨＭＶＰのＣＰＭＶは、次の数式２６および２７を用いて導出され得る。

＜数式２６＞
V0x = VB0x + (VB2_x - VB0x ) * ( posCurCU_Y - posRefCU_Y ) / RefCU_height
+ (VB1x - VB0x ) * (posCurCU_X - posRefCU_X) / RefCU_width

＜数式２７＞
V0y = VB0y + (VB2_y - VB0y ) * (posCurCU_Y - posRefCU_Y) / RefCU_height
+ (VB1y - VB0y ) * (posCurCU_X - posRefCU_X) / RefCU_width

数式２６および２７で、ｐｏｓＣｕｒＣＵ＿Ｙは、現ブロック３５０１の左上段のサンプルの垂直方向の座標値を表し、ｐｏｓＲｅｆＣＵ＿Ｙは、参照ブロック３５０２の左上段のサンプルの垂直方向の座標値を表す。ｐｏｓＣｕｒＣＵ＿Ｘは、現ブロック３５０１の左上段のサンプルの水平方向の座標値を表し、ｐｏｓＲｅｆＣＵ＿Ｘは、参照ブロック３５０２の左上段のサンプルの水平方向の座標値を表す。ＲｅｆＣＵ＿ｈｅｉｇｈｔは、参照ブロック３５０２の高さを表し、ＲｅｆＣＵ＿ｗｉｄｔｈは、参照ブロック３５０２の幅を表す。

本明細書の一実施例において、アフィンＨＭＶＰ候補（直接または継承されたＨＭＶＰ）を追加する際、アフィンマージまたはアフィンＡＭＶＰリストの生成に使用され得るアフィンＨＭＶＰ候補を選択するように制限事項が追加され得る。

一例として、アフィンＨＭＶＰ候補は、上記アフィンＨＭＶＰ候補が現ブロックに隣接する場合にのみ、アフィンマージまたはアフィンＡＭＶＰリストに追加され得る。

別の一例として、アフィンＨＭＶＰ候補は、上記アフィンＨＭＶＰ候補が現ブロックから特定の距離内に位置（または存在）する場合にのみ、アフィンマージまたはアフィンＡＭＶＰリストに追加され得る。例えば、上記特定の距離は、予め定義されたピクセル距離であり得る。エンコーダ／デコーダは、アフィンＨＭＶＰ候補が利用可能であるかを判断するために、上記アフィンＨＭＶＰ候補が予め定義された特定の距離内に位置するか否かを判断（または決定）できる。

別の一例として、アフィンＨＭＶＰ候補は、現ブロックを基準に特定の位置に位置（または存在）する場合にのみ、アフィンマージまたはアフィンＡＭＶＰリストに追加され得る。例えば、上記特定の位置に存在する場合は、上記アフィンＨＭＶＰ候補が現ブロックの左側または上側の隣接ブロックの場合であり得る。

Ｎ個のエレメントを有するアフィンＨＭＶＰ ＬＵＴに対して、全てのエレメントまたは最初のＭ個のエレメントに対する前述した確認プロセスが、マージもしくはＡＭＶＰリストが満たされるまで、または予め定義された特定のＨＭＶＰ候補の数に到達するまで、行われ得る。

本明細書の一実施例において、アフィンＨＭＶＰ候補は、アフィンマージリストおよび／またはアフィンＡＭＶＰリストにおける既に存在する継承されたアフィン候補を代替するのに使用する方法を提案する。

図３６は、本明細書の実施例にかかるアフィンマージリストまたはアフィンＡＭＶＰリストを例示する図である。

図３６を参照すると、エンコーダ／デコーダは、既存のアフィンマージリストまたはアフィンＡＭＶＰリストに存在する継承された候補を継承されたアフィンＨＭＶＰ候補で代替することができる。すなわち、エンコーダ／デコーダは、現ブロックにサブブロックベースのマージモードが適用される場合、継承されたアフィン候補、および構成されたアフィン候補を用いてサブブロックベースのマージ候補リストを生成し、継承されたアフィンＨＭＶＰ候補を導出し、上記サブブロックベースのマージ候補リストに含まれる少なくとも１つの継承されたアフィン候補を継承されたアフィンＨＭＶＰ候補で代替することができる。

また、本発明の一実施例において、アフィンＨＭＶＰのルックアップテーブル（ＬＵＴ）は、スライス、ＣＴＵ行（row）、またはＣＴＵの開始で初期化され得る。これを介して、並列処理の遂行性を向上させることができる。

以下、後述する実施例では、ＨＭＶＰからの最悪の淘汰チェック（pruning check）の数を減少させるための方法を提案する。

本明細書の実施例において、ＨＭＶＰ候補がマージリストに追加される場合、淘汰チェックの数は、マージリスト内の利用可能な候補の数、およびマージリストに追加され得るＨＭＶＰ候補の数に基づいて決定され得る。以下で、本明細書の実施例を説明するにあたって、説明の便宜のために下記のように変数を定義して説明する。

－ Ｎ_ST：マージリスト内における利用可能な（または存在する）候補の数

－ Ｎ_HMVP：テーブル内におけるＨＭＶＰ候補の数（すなわち、ＨＭＶＰテーブルの大きさ）

－ Ｎ_mrgToBeAdded：マージリストに追加されるＨＭＶＰ候補の数

－ Ｎ_HMVPChecked：淘汰チェックされるＨＭＶＰ候補の数

－ Ｎ_{max_hmvp_prunning}：ＨＭＶＰ候補をマージリストに追加するために要求される最悪の場合の淘汰チェックの数

本明細書の一実施例において、ＨＭＶＰ候補は、次の条件によってマージリストに追加され得る。

－ 第１の条件：ＬＵＴは、以前に淘汰されている場合（すなわち、ＨＭＶＰ ＬＵＴ内の候補間で同一のｍｖはない場合）

－ 第２の条件：ＨＭＶＰ ＬＵＴテーブルの大きさが６である場合

－ 第３の条件：ＨＭＶＰ候補をマージリストに追加するために利用可能な（または存在する）マージ候補の最大の数が４である場合。すなわち、最大のマージリストの大きさ（または最大のマージ候補）から１を減算した値よりもマージリスト内のマージ候補の数が小さい場合。例えば、最大のマージリストの大きさは６であってもよく、現在利用可能なマージ候補の数が５より小さい場合、ＨＭＶＰ候補を追加（または挿入）し得る。言い換えると、ＨＭＶＰ候補は、マージリストのインデックス５までのみ追加され得る。

ＨＭＶＰ候補がマージリストに追加されると（すなわち、マージ候補になると）、各ＨＭＶＰ候補は、マージ候補間の重複を除去するために淘汰チェックが必要なことがある。既存の映像圧縮技術によると、マージリストにＨＭＶＰを追加するために必要な最悪の（または最悪の場合の）淘汰チェックの数は、次の表８のように計算され得る。

＜表８＞

表８を参照すると、既存の映像圧縮技術によると、ＨＭＶＰテーブル（またはＨＭＶＰリスト、ＨＭＶＰ候補リスト）内の６つのＨＭＶＰ候補に対して淘汰チェックが行われ得る。

具体的には、１）マージリスト内の候補が１つである場合、マージリストに追加されるＨＭＶＰ候補は４つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は４であってもよい。２）マージリスト内の候補が２つである場合、マージリストに追加されるＨＭＶＰ候補は３つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は７であってもよい。３）マージリスト内の候補が３つである場合、マージリストに追加されるＨＭＶＰ候補は２つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は９であってもよい。４）マージリスト内の候補が４つである場合、マージリストに追加されるＨＭＶＰ候補は１つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は１０であってもよい。

本明細書の実施例において、上記で説明した最悪の淘汰チェックの数を減らすための方法を提案する。マージリストにマージ候補がより多く存在する場合、マージ候補（すなわち、非ＨＭＶＰ候補）が増加するのに伴って、ＨＭＶＰのコーディングの影響が減少するため、淘汰チェックするＨＭＶＰ候補の数が減少する必要があり得る。したがって、本明細書の実施例において、エンコーダ／デコーダは、最悪の淘汰チェックを減らすために、チェックされるＨＭＶＰ候補の数（ＮＨＭＶＰＣｈｅｃｋｅｄ）を、追加される利用可能なＨＭＶＰ候補の数（ＮｍｒｇＴｏＢｅＡｄｄｅｄ）と同じように設定され得る。この場合、最悪の淘汰チェックの数は、次の表９のように計算され得る。

＜表９＞

表９を参照すると、従来の映像圧縮技術と比較した際、ＨＭＶＰのための最悪の淘汰チェックの数は、１０個から６つに減り得る。

表９を参照すると、一実施例において、１）マージリスト内の候補が１つである場合、マージリストに追加されるＨＭＶＰ候補は４つであってもよい。また、４つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は４であってもよい。２）マージリスト内の候補が２つである場合、マージリストに追加されるＨＭＶＰ候補は３つであってもよい。また、３つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は６であってもよい。３）マージリスト内の候補が３つである場合、マージリストに追加されるＨＭＶＰ候補は２つであってもよい。また、２つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は６であってもよい。４）マージリスト内の候補が４つである場合、マージリストに追加されるＨＭＶＰ候補は１つであってもよい。また、１つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は４であってもよい。

本明細書の実施例において、最悪の淘汰チェックを減らすために、エンコーダ／デコーダは、淘汰チェックされるＨＭＶＰ候補の数（ＮＨＭＶＰＣｈｅｃｋｅｄ）を、追加される利用可能なＨＭＶＰ候補の数（ＮｍｒｇＴｏＢｅＡｄｄｅｄ）とＫとの和と同じ値に設定し得る。ここで、Ｋは、予め定義された定数値を表す。一例として、Ｋが１である場合、最悪の淘汰チェックの数は、次の表１０のように計算され得る。

＜表１０＞

表１０を参照すると、一実施例において、１）マージリスト内の候補が１つである場合、マージリストに追加されるＨＭＶＰ候補は４つであってもよい。また、５つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は４であってもよい。２）マージリスト内の候補が２つである場合、マージリストに追加されるＨＭＶＰ候補は３つであってもよい。また、４つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は７であってもよい。３）マージリスト内の候補が３つである場合、マージリストに追加されるＨＭＶＰ候補は２つであってもよい。また、３つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は８であってもよい。４）マージリスト内の候補が４つである場合、マージリストに追加されるＨＭＶＰ候補は１つであってもよい。また、２つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は７であってもよい。

本明細書の実施例において、最悪の場合、淘汰チェックを減少させるために、チェックされるＨＭＶＰ候補の数（ＮＨＭＶＰＣｈｅｃｋｅｄ）は、次の数式２８のように定義され得る。

＜数式２８＞

数式２８で、Ｃは、予め定義された定数値を表す。Ｃが２である場合、最悪の淘汰チェックの数は、次の表１１のように計算され得る。

＜表１１＞

表１１を参照すると、一実施例において、１）マージリスト内の候補が１つである場合、マージリストに追加されるＨＭＶＰ候補は４つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は４であってもよい。２）マージリスト内の候補が２つである場合、マージリストに追加されるＨＭＶＰ候補は３つであってもよい。また、６つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は７であってもよい。３）マージリスト内の候補が３つである場合、マージリストに追加されるＨＭＶＰ候補は２つであってもよい。また、４つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は９であってもよい。４）マージリスト内の候補が４つである場合、マージリストに追加されるＨＭＶＰ候補は、１つであってもよい。また、２つのＨＭＶＰ候補に対する淘汰チェックが行われ得る。この場合、最悪の淘汰チェックの数は７であってもよい。

ＨＭＶＰがマージリストおよび／またはＡＭＶＰリストの構成に追加される場合、マージリストおよび／またはＡＭＶＰリスト内に存在する候補との重複を避けるために、淘汰が再度行われる必要性がある。ＨＭＶＰ ＬＵＴが上記図２９で説明したように、制限的ＦＩＦＯ動作により既に淘汰されている場合、ＨＭＶＰ候補をマージリストに挿入（または追加）する際、ＨＭＶＰ候補の間で比較（または淘汰チェック）は必要ではないかもしれない。これによって、上記図２８で説明したような非制限的ＦＩＦＯテーブルを使用する場合に比べて淘汰チェックの数は減ることができる。何故なら、ＨＭＶＰ候補間の淘汰チェックは、ＨＭＶＰ候補をマージリストに挿入する際に必要なためである。前述したように、本明細書において、ＨＭＶＰ ＬＵＴは、その名称に制限されず、ＬＵＴ、テーブル、ＨＭＶＰテーブル、ＨＭＶＰ候補テーブル、バッファ、ＨＭＶＰバッファ、ＨＭＶＰ候補バッファ、ＨＭＶＰリスト、ＨＭＶＰ候補リスト、ＨＭＶＰマージ候補リスト、履歴ベースマージ候補リストなどと称される。

本明細書の一実施例において、マージリストおよび／またはＡＭＶＰリストの構成のためのＨＭＶＰ候補の挿入プロセスを考慮したＨＭＶＰルックアップテーブル（ＬＵＴ）の大きさを定義し得る。具体的には、ＨＭＶＰ候補は、予め定義されたマージリストの大きさまで追加され得る。例えば、最大のマージリストの大きさが６で定義された場合、ＨＭＶＰは、６番目の候補にならなくてもよい。マージリストに５つのマージ候補が利用可能な（または存在する）場合、ＨＭＶＰ候補は追加されなくてもよい。この場合、６番目の候補は、ＨＭＶＰを除いた候補（またはこれ以外の異なる方法）から選択され得る。したがって、前述したＨＭＶＰ候補の挿入プロセスを考慮すると、本明細書の一実施例において、次のようなＨＭＶＰ ＬＵＴの大きさの選択方法を提案する。

一実施例として、ＨＭＶＰ ＬＵＴテーブルの大きさは、（ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ － Ｋ）と同じように定義（または設定）され得る。ここで、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄは、最大のマージ候補リスト（またはマージ候補リストの最大の数、最大のマージ候補の数）を表し、この際、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄは、６で定義され得る。Ｋは、予め定義された定数を表す。例えば、Ｋは１であってもよく、この際、ＨＭＶＰ ＬＵＴの大きさは５であってもよい。

本明細書の実施例によれば、ＨＭＶＰをＭａｘＮｕｍＭｅｒｇｅＣａｎｄ － Ｋ（前述したように、例えば、Ｋは１）に制限することによって、ＨＭＶＰをマージリストおよび／またはＨＭＶＰテーブルに追加する際、最悪の（または最悪の場合の）淘汰チェックの数は減り得る（上記図２９で説明した制限されたＦＩＦＯ動作）。また、本発明の実施例によれば、ＨＭＶＰ ＬＵＴの記憶のためのメモリが減少し得る。

本明細書の実施例において、前述したＨＭＶＰテーブルの大きさを考慮し、ＨＭＶＰ動き候補を有するテーブルに対して、以下で説明する実施例のようなアップデートプロセスが適用され得る。以下の実施例は、ＨＭＶＰテーブルのアップデートプロセスの一例であって、本明細書の実施例がこれに限定されるわけではない。

ＨＭＶＰテーブルのアップデートプロセス

まず、ＨＭＶＰテーブルのアップデートプロセスの入力は、次のように定義され得る。

－ 動きベクトルｍｖＬ０およびｍｖＬ１

－ 参照インデックスｒｅｆＩｄｘＬ０およびｒｅｆＩｄｘＬ１

－ 予測リスト活用フラグのｐｒｅｄＦｌａｇＬ０およびｐｒｅｄＦｌａｇＬ１

本アップデートプロセスの出力は、ＨＭＶＰ候補リストの修正された配列であってもよい。本プロセスで、ｍｖＣａｎｄは、上記動きベクトル、上記参照インデックス、上記予測リスト活用フラグを有する動きベクトル候補を示す（指称する）変数を表す。

本アップデートプロセスは、次のような段階で行われ得る。

１．変数ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔは、偽（false）に設定され、変数ｔｅｍｐＩｄｘは、０に設定される。ここで、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔは、ＨＭＶＰ候補リストに同一の動き情報が存在するかを表す変数であり、ｔｅｍｐＩｄｘは、ＨＭＶＰ候補リスト内で現在の動きベクトルと同一の動き情報を有するＨＭＶＰ候補のインデックスを表す変数である。

２．ＨＭＶＰＣａｎｄＮｕｍが０より大きい場合、ＨＭＶＰＩｄｘ＝０．．ＨＭＶＰＣａｎｄＮｕｍ－１であるそれぞれのインデックスＨＭＶＰＩｄｘに対して、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔの変数が真（true）になるまで次の段階が適用され得る。ここで、ＨＭＶＰＣａｎｄＮｕｍは、ＨＭＶＰ候補リストのＨＭＶＰ候補の数を表し、ＨＭＶＰＩｄｘは、ＨＭＶＰ候補リスト内のＨＭＶＰ候補に割り当てられたインデックスを表す。

－ ｍｖＣａｎｄがＨＭＶＰＣａｎｄＬｉｓｔ［ＨＭＶＰＩｄｘ］（すなわち、ＨＭＶＰ候補リスト内のＨＭＶＰＩｄｘを有するＨＭＶＰ候補）と同一の動きベクトルおよび同一の参照インデックスを有する場合、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔは真に設定され、ｔｅｍｐＩｄｘは、ＨＭＶＰＩｄｘに設定され得る。

３．また、ＨＭＶＰ候補リストは、次の段階によってアップデートされ得る。

（１）ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔが真であるか、またはＨＭＶＰＣａｎｄＮｕｍがＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋである場合（と同一である場合）、以下の段階が適用され得る。ここで、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄは、マージリスト（またはマージ候補リスト）の大きさ（または、マージリストの最大候補の数、最大のマージ候補の数）を表す変数であり、Ｋは、任意の定数である。一実施例において、Ｋは、予め定義され得る。また、一実施例において、Ｋは１に設定され得、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ値が６に定義されることによって、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは、５であってもよい。また、一実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは５に設定され得る。例えば、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔが真であるか、またはＨＭＶＰＣａｎｄＮｕｍが５である場合、以下の段階が適用され得る。

－ ｉｄｘ＝（ｔｅｍｐＩｄｘ＋１）．．（ＨＭＶＰＣａｎｄＮｕｍ－１）であるそれぞれのインデックスｉｄｘに対して、ＨＭＶＰＣａｎｄＬｉｓｔ［ｉｄｘ－１］は、ＨＭＶＰＣａｎｄＬｉｓｔ［ｉｄｘ］に設定され得る。すなわち、ｔｅｍｐＩｄｘ以降のインデックスを有するＨＭＶＰ候補のインデックスは、その値が１だけ減った値に設定され得る。

－ ＨＭＶＰＣａｎｄＬｉｓｔ［ＨＭＶＰＣａｎｄＮｕｍ－１］は、ｍｖＣａｎｄに設定され得る。

（２）そうでなければ（すなわち、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔは偽であり、ＨＭＶＰＣａｎｄＮｕｍがＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋより小さい場合）、以下の段階が適用され得る。前述したように、一実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは、５に設定され得る。例えば、そうでなければ（すなわち、ｉｄｅｎｔｉｃａｌＣａｎｄＥｘｉｓｔは偽であり、ＨＭＶＰＣａｎｄＮｕｍが５より小さい場合）、以下の段階が適用され得る。

－ ＨＭＶＰＣａｎｄＬｉｓｔ［ＨＭＶＰＣａｎｄＮｕｍ＋＋］は、ｍｖＣａｎｄに設定され得る。

一例として、本アップデートプロセスは、現在のスライスがＰまたはＢスライスである際に呼び出され得る。この際、変数ＨＭＶＰＣａｎｄＮｕｍは０に設定され、変数ＨＭＶＰＣａｎｄＬｉｓｔは、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋのエレメント配列で定義され得る。前述したように、一実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは５に設定され得る。例えば、この際、変数ＨＭＶＰＣａｎｄＮｕｍは０に設定され、変数ＨＭＶＰＣａｎｄＬｉｓｔは、５のエレメント配列で定義され得る。

以下では、ＨＭＶＰテーブルのアップデートプロセスの別の一例を説明する。

まず、本アップデートプロセスの入力は、次のように定義され得る。

－ 動きベクトルｍｖＬ０およびｍｖＬ１

－ 参照インデックスｒｅｆＩｄｘＬ０およびｒｅｆＩｄｘＬ１

－ 予測リスト活用フラグｐｒｅｄＦｌａｇＬ０およびｐｒｅｄＦｌａｇＬ１

本アップデートプロセスの出力は、ＨＭＶＰ候補リストの修正された配列であってもよい。本プロセスで、ｍｖＣａｎｄは、上記動きベクトル、上記参照インデックス、上記予測リスト活用フラグを有する動きベクトル候補を示す変数を表す。

本アップデートプロセスは、次のような段階で行われ得る。

１．ＨＭＶＰＩｄｘ＝０．．ＨＭＶＰＣａｎｄＮｕｍ－１であるそれぞれのインデックスＨＭＶＰＩｄｘに対して、変数ｓａｍｅＣａｎｄが真（true）になるまで次の段階が順序通り適用され得る。ここで、ｓａｍｅＣａｎｄは、ＨＭＶＰ候補リストに同一の動き情報が存在するかを表す変数である。

－ ｍｖＣａｎｄがＨＭＶＰＣａｎｄＬｉｓｔ［ＨＭＶＰＩｄｘ］と同一の動きベクトルおよび同一の参照インデックスを有する場合、ｓａｍｅＣａｎｄは真に設定される。

－ そうでなければ、ｓａｍｅＣａｎｄは、偽（false）に設定される。

－ ＨＭＶＰＩｄｘ＋＋（すなわち、ＨＭＶＰＩｄｘは、１だけ増加する）

２．変数ｔｅｍｐＩｄｘは、ＨＭＶＰＣａｎｄＮｕｍに設定される。

３．ｓａｍｅＣａｎｄが真であるか、またはＨＭＶＰＣａｎｄＮｕｍがＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋである場合、ｔｅｍｐＩｄｘ＝（ｓａｍｅＣａｎｄ？ ＨＭＶＰＩｄｘ：１）．．ＨＭＶＰＣａｎｄＮｕｍ－１であるそれぞれのインデックスｔｅｍｐＩｄｘに対して、ＨＭＶＰＣａｎｄＬｉｓｔ［ｔｅｍｐＩｄｘ］は、ＨＭＶＰＣａｎｄＬｉｓｔ［ｔｅｍｐＩｄｘ－１］に複写（または設定）される。Ｋは、任意の定数である。一実施例において、Ｋは、予め定義され得る。また、一実施例において、Ｋは１に設定され得、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ値が６として定義されることによって、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは５であってもよい。また、一実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは５に設定され得る。

４．ｍｖＣａｎｄは、ＨＭＶＰＣａｎｄＬｉｓｔ［ｔｅｍｐＩｄｘ］に複写される。

５．ＨＭＶＰＣａｎｄＮｕｍがＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋより小さい場合、ＨＭＶＰＣａｎｄＮｕｍは１ずつ増加する。前述したように、一実施例において、ＭａｘＮｕｍＭｅｒｇｅＣａｎｄ－Ｋは５に設定され得る。

以上で説明した本明細書の実施例は、説明の便宜上、それぞれの実施例を区分して説明したが、本発明がこれに制限されるわけではない。すなわち、上記で説明した実施例はそれぞれ独立して行われてもよく、１つまたは複数の様々な実施例が組み合わされて行われてもよい。

図３７は、本発明が適用される実施例にかかる履歴ベース動きベクトル予測に基づいてビデオ信号を処理する方法を例示するフローチャートである。

図３７を参照すると、説明の便宜のためにデコーダを中心に説明するが、本発明がこれに限定されるわけではなく、本明細書の実施例にかかる履歴ベース動きベクトル予測ベースのビデオ信号処理方法は、エンコーダとデコーダとで同様に行われ得る。

デコーダは、現ブロックの空間的（spatial）および時間的（temporal）隣接ブロックに基づいてマージ候補リスト（merge candidate list）を構成する（Ｓ３７０１）。

デコーダは、上記現ブロックの履歴ベースマージ候補（history based merge candidate）を上記マージ候補リストに追加する（Ｓ３７０２）。

デコーダは、上記マージ候補リスト内で上記現ブロックのインター予測に用いられるマージ候補を指示するマージインデックス（merge index）を獲得する（Ｓ３７０３）。

デコーダは、上記マージインデックスにより指示されるマージ候補の動き情報に基づいて、上記現ブロックの予測サンプルを生成する（Ｓ３７０４）。

デコーダは、上記動き情報に基づいて履歴ベースマージ候補リスト（history based merge candidate list）をアップデートする（Ｓ３７０５）。

前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれるマージ候補のうち、予め定義されたマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。

前述したように、実施例として、上記履歴ベースマージ候補リストは、上記マージ候補リストの最大のマージ候補の数に基づいて決定される大きさを有するように定義され得る。

前述したように、実施例として、上記履歴ベースマージ候補リストは、上記マージ候補リストの最大のマージ候補の数から１を減算した値の大きさを有するように定義され得る。

前述したように、実施例として、上記履歴ベースマージ候補リストの大きさは、５で定義され得る。

前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれるマージ候補のうち、予め定義された特定の数のマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。

前述したように、実施例として、上記履歴ベースマージ候補は、上記マージ候補リストに含まれる特定の空間のマージ候補と重複しない動き情報を有する場合、上記マージ候補リストに追加され得る。

前述したように、実施例として、上記履歴ベースマージ候補は、上記履歴ベースマージ候補リスト内で予め定義された特定の数の候補から導出され得る。

前述したように、実施例として、デコーダは、上記マージ候補リストが上記マージリストの最大数を満たしていない場合は、ゼロ動きベクトルを上記マージリストに追加し得る。

本発明で説明した実施例は、プロセッサ、マイクロプロセッサ、コントローラ、またはチップ上で実現されて行われ得る。例えば、各図で示す機能ユニットは、コンピュータ、プロセッサ、マイクロプロセッサ、コントローラまたはチップ上で実現されて行われ得る。

また、本発明が適用されるデコーダおよびエンコーダは、マルチメディア放送の送受信装置、モバイル通信端末、ホームシネマビデオ装置、デジタルシネマビデオ装置、監視用カメラ、ビデオ対話装置、ビデオ通信などのリアルタイムの通信装置、モバイルストリーミング装置、記憶媒体、カムコーダ、オーダメイドビデオ（ＶｏＤ）サービス提供装置、ＯＴＴビデオ（Over the top video）装置、インターネットストリーミングサービス提供装置、３次元（３Ｄ）ビデオ装置、画像電話ビデオ装置、および医療用ビデオ装置などに含まれ得、ビデオ信号またはデータ信号を処理するために使用され得る。例えば、ＯＴＴビデオ（Over The Top video）装置としては、ゲームコンソール、ブルーレイプレーヤ、インターネット接続ＴＶ、ホームシアターシステム、スマートフォン、タブレットＰＣ、ＤＶＲ（Digital Video Recorder）などを含み得る。

また、本発明が適用される処理方法は、コンピュータで実行されるプログラムの形態で生産されることができ、コンピュータが読み取られる記録媒体に記憶され得る。本発明によるデータ構造を有するマルチメディアデータもまた、コンピュータが読み取られる記録媒体に記憶され得る。上記コンピュータが読み取られる記録媒体は、コンピュータで読み取られるデータが記憶される全ての種類の記憶装置および分散記憶装置を含む。上記コンピュータが読み取られる記録媒体は、例えば、ブルーレイディスク（ＢＤ）、ユニバーサルシリアル（汎用直列）バス（ＵＳＢ）、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＲＡＭ、ＣＤ－ＲＯＭ、磁気テープ、フロッピ（登録商標）ディスク、および光学データ記憶装置を含み得る。また、上記コンピュータが読み取られる記録媒体は、搬送波（例えば、インターネットを介した送信）の形態で実現されたメディアを含む。また、エンコード方法で生成されたビットストリームが、コンピュータが読み取られる記録媒体に記憶されるか、有無線通信ネットワークを介して送信され得る。

また、本発明の実施例は、プログラムコードによるコンピュータプログラム製品で実現されることができ、上記プログラムコードは、本発明の実施例によってコンピュータで実行されることができる。上記プログラムコードは、コンピュータによって読み取り可能なキャリア上に記憶されることができる。

本明細書が適用されるデコード装置およびエンコード装置は、デジタル機器（digital de-vice）に含まれ得る。「デジタル機器（digital device）」とは、例えば、データ、コンテンツ、サービスなどを送信、受信、処理および出力の少なくとも１つを実行可能な全てのデジタル機器を含む。ここで、デジタル機器がデータ、コンテンツ、サービスなどを処理することは、データ、コンテンツ、サービスなどをエンコーディングおよび／またはデコードする動作を含む。このようなデジタル機器は、有／無線ネットワーク（wire/wireless network）を介して、他のデジタル機器、外部サーバ（external server）などとペアリングまたは接続（連結）（pairing or connecting）（以下「ペアリング」）されてデータを送受信し、必要に応じて変換（converting）する。

デジタル機器は、例えば、ネットワークＴＶ（network TV）、ＨＢＢＴＶ（Hybrid Broadcast Broadband TV）、スマートＴＶ（Smart TV）、ＩＰＴＶ（Internet Protocol Television）、ＰＣ（Personal Computer）などの固定型機器（standing device）と、ＰＤＡ（Personal Digital Assistant）、スマートフォン（Smart Phone）、タブレットＰＣ（Tablet PC）、ラップトップなどのモバイル機器（mobile device or handheld device）と、をいずれも含む。本明細書では、便宜上、後述する図３３ではデジタルＴＶを、図３４ではモバイル機器をデジタル機器の実施例として示して説明する。

一方、本明細書で記述される「有／無線ネットワーク」とは、デジタル機器またはデジタル機器と外部サーバとの間で相互接続および／またはデータの送受信のために様々な通信規格またはプロトコルをサポート（支援）する通信ネットワークを通称する。このような有／無線ネットワークは、規格により、現在または今後サポートされる通信ネットワークとそのための通信プロトコルをいずれも含み得るので、例えば、ＵＳＢ（Universal Serial Bus）、ＣＶＢＳ（Composite Video Banking Sync）、コンポーネント、Ｓ－ビデオ（アナログ）、ＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（High Definition Multimedia Interface）（登録商標）、ＲＧＢ、Ｄ－ＳＵＢなどの有線接続のための通信規格またはプロトコルと、ブルートゥース（Bluetooth）（登録商標）、ＲＦＩＤ（Radio Frequency Identification）、赤外線通信（IrDA、infrared Data Association）、ＵＷＢ（Ultra Wideband）、ジグビ（ZigBee）、ＤＬＮＡ（Digital Living Network Alliance）（登録商標）、ＷＬＡＮ（Wireless LAN）（Ｗｉ－Ｆｉ）、Ｗｉｂｒｏ（Wireless broadband）、Ｗｉｍａｘ（World Interoperability for Microwave Access）、ＨＳＤＰＡ（High Speed Down-link Packet Access）、ＬＴＥ（Long Term Evolution）、Ｗｉ－Ｆｉダイレクト（Direct）などの無線接続のための通信規格と、によって形成され得る。

以下、本明細書でただデジタル機器と名付ける場合には、コンテキストに応じて、固定型機器またはモバイル機器を意味するか、両者とも含む意味であってもよい。

一方、デジタル機器は、例えば、放送受信機能、コンピュータ機能（またはサポート）、少なくとも１つの外部入力（external input）をサポートするインテリジェント（知能型）機器であって、前述した有／無線ネットワークを介してＥメール（e-mail）、ウェブブラウジング（web browsing）、バンキング（banking）、ゲーム（game）、アプリケーション（application）などをサポートできる。また、上記デジタル機器は、手動（手記）方式の入力装置、タッチスクリーン（touch screen）、空間リモコン（space remote control）などの少なくとも１つの入力または制御手段（以下、入力手段）をサポートするためのインターフェース（interface）を備えることができる。デジタル機器は、標準化された汎用ＯＳ（Operating System）を用いることができる。例えば、デジタル機器は、汎用ＯＳのカーネル（kernel）上に様々なアプリケーション（application）を追加（adding）、削除（deleting）、修正（amending）、アップデート（updating）などを行うことができ、それを介してさらにユーザフレンドリ（user-friendly）な環境を構成して提供できる。

一方、本明細書で記述される外部入力は、外部入力機器、すなわち、前述したデジタル機器と有／無線で接続され、それを介して関連データを送／受信して処理可能な全ての入力手段またはデジタル機器を含む。ここで、上記外部入力は、例えば、ＨＤＭＩ（High Definition Multimedia Interface）（登録商標）、プレイステーション（play station）やエックスボックス（Ｘ－Ｂｏｘ）などのゲーム機器、スマートフォン、タブレットＰＣ、プリンター、スマートＴＶなどのデジタル機器をいずれも含む。

また、本明細書で記述される「サーバ（server）」とは、クライアント（client）、すなわち、前述したデジタル機器にデータを供給する全てのデジタル機器またはシステムを含む意味であって、プロセッサ（processor）とも呼ぶ。このようなサーバとしては、例えば、ウェブページまたはウェブコンテンツを提供するポータルサーバ（portal server）、広告データ（advertising data）を提供する広告サーバ（advertising server）、コンテンツを提供するコンテンツサーバ（content server）、ＳＮＳ（Social Network Service）サービスを提供するＳＮＳサーバ（SNS server）、メーカで提供するサービスサーバ（service server or manufacturing server）などが含まれ得る。

その他に、本明細書で記述される「チャンネル（channel）」とは、データを送受信するための経路（path）、手段（means）などを意味するものであって、放送チャンネル（broadcasting channel）を例に挙げることができる。ここで、放送チャンネルは、デジタル放送の活性化によって物理チャンネル（physical channel）、仮想チャンネル（virtual channel）、論理チャンネル（logical channel）などの用語で表現される。放送チャンネルは、放送網と呼ばれ得る。このように、放送チャンネルは、放送局で提供する放送コンテンツを提供または受信器でアクセス（接近）するためのチャンネルをいうもので、上記放送コンテンツは、主にリアルタイム放送（real-time broadcasting）に基づくので、ライブチャンネル（live channel）ともいう。ただし、最近では、放送のための媒体（medium）がさらに多様化され、リアルタイム放送以外に非リアルタイム（non-real time）放送も活性化されており、ライブチャンネルは、ただリアルタイム放送だけでなく、場合によっては、非リアルタイム放送を含む放送チャンネル全体を意味する用語と理解されることもある。

本明細書では、前述した放送チャンネル以外に、チャンネルに関して「任意のチャンネル（arbitrary channel）」をさらに定義する。上記任意のチャンネルは、放送チャンネルと共にＥＰＧ（Electronic Program Guide）のようなサービスガイド（service guide）と共に提供されることもでき、任意のチャンネルだけでサービスガイド、ＧＵＩ（Graphic User Interface）またはＯＳＤ画面（On-Screen Dis-play screen）を構成／提供することもできる。

一方、送受信器間で予め約束されたチャンネル番号（ナンバ）を有する放送チャンネルと異なり、任意のチャンネルは、受信器で任意に割り当てられるチャンネルであって、上記放送チャンネルを表現するためのチャンネル番号とは基本的に重複しないチャンネル番号が割り当てられる。例えば、受信器は、特定の放送チャンネルをチューニングすると、チューニングされたチャンネルを介して放送コンテンツとそのためのシグナリング情報（signaling information）とを送信する放送信号を受信する。ここで、受信器は、上記シグナリング情報からチャンネル情報をパージング（parsing）し、パージングされたチャンネル情報に基づいてチャンネルブラウザ（channel browser）、ＥＰＧなどを構成してユーザに提供する。ユーザは、入力手段を介してチャンネル切換の要求を行うと、受信器は、それに応答する（対する方式である）。

このように、放送チャンネルは、送受信端間で予め約束された内容であるので、任意のチャンネルを放送チャンネルと重複して割り当てる場合には、ユーザの混同を招いたり、混同の可能性が存在するので、前述したように重複して割り当てないことが好ましい。一方、上記のように、任意のチャンネル番号を放送チャンネル番号と重複して割り当てなくても、ユーザのチャンネルサーフィン過程で依然として混同の恐れがあるので、これを考慮し、任意のチャンネル番号を割り当てることが要求される。何故なら、本明細書による任意のチャンネルもやはり、従来の放送チャンネルと同じように入力手段を介したユーザのチャンネル切換の要求によって、同じ方式で対応し、放送チャンネルのようにアクセスされるように実現できるためである。したがって、任意のチャンネル番号は、ユーザの任意のチャンネルへのアクセスに対する便宜と放送チャンネル番号の区分または識別に対する便宜とのために、放送チャンネルのように数字の形態ではなく、任意のチャンネル－１、任意のチャンネル－２などのように文字が併記された形で定義して表示できる。一方、この場合、任意のチャンネル番号の表示は、任意のチャンネル－１のように文字が併記された形であるが、受信器内部的には、上記放送チャンネルの番号のように数字の形で認識して実現できる。その他に、任意のチャンネル番号は、放送チャンネルのように数字の形で提供されてもよく、動画チャンネル－１、タイトル－１、ビデオ－１などのように放送チャンネルと区分可能な様々な方式でチャンネル番号を定義して表示してもよい。

デジタル機器は、ウェブサービス（web service）のためにウェブブラウザ（web browser）を実行して、様々な形態のウェブページ（web page）をユーザに提供する。ここで、上記ウェブページには、動画（video content）が含まれるウェブページも含まれるが、本明細書では、動画をウェブページから別途で、または独立して分離して処理する。また、上記分離される動画は、前述した任意のチャンネル番号を割り当て、サービスガイドなどを介して提供し、ユーザがサービスガイドや放送チャンネルの視聴過程で、チャンネル切換の要求によって出力されるように実現できる。その他に、ウェブサービス以外にも、放送コンテンツ、ゲーム、アプリケーションなどのサービスに対しても、所定のコンテンツ、イメージ、オーディオ、項目などを上記放送コンテンツ、ゲーム、アプリケーション自体から独立して分離処理し、その再生、処理などのために任意のチャンネル番号を割り当て、前述したように実現できる。

図３８は、デジタル機器を含むサービスシステム（service system）の一例を概略的に示す図である。

デジタル機器を含むサービスシステムは、コンテンツプロバイダ（提供者）（Content Provider；ＣＰ）３８１０、サービスプロバイダ（Service Provider；ＳＰ）３８２０、ネットワークプロバイダ（Network Provider；ＮＰ）３８３０、およびＨＮＥＤ（Home Network End User）（Customer）３８４０を含む。ここで、ＨＮＥＤ３８４０は、例えば、クライアント３８００、すなわち、デジタル機器である。コンテンツプロバイダ３８１０は、各種のコンテンツを作製して提供する。このようなコンテンツプロバイダ３８１０として、図３８に示すように、地上波放送業者（送出者）（terrestrial broadcaster）、ケーブル放送事業者（ｃａｂｌｅ ＳＯ （System Operator））またはＭＳＯ（Multiple SO）、衛星放送業者（satellite broadcaster）、様々なインターネット放送業者（Internet broadcaster）、個人コンテンツプロバイダ（Private CPs）などを例示することができる。一方、コンテンツプロバイダ３８１０は、放送コンテンツ以外にも様々なアプリケーションなどを提供する。

サービスプロバイダ３８２０は、コンテンツプロバイダ３８１０が提供するコンテンツをサービスパッケージ化してＨＮＥＤ３８４０に提供する。例えば、図３８のサービスプロバイダ３８２０は、第１の地上波放送、第２の地上波放送、ケーブルＭＳＯ、衛星放送、様々なインターネット放送、アプリケーションなどをパッケージ化してＨＮＥＤ３８４０に提供する。

サービスプロバイダ３８２０は、ユニキャスト（uni-cast）またはマルチキャスト（multi-cast）方式でクライアント３００にサービスを提供する。一方、サービスプロバイダ３８２０は、データを予め登録された多数のクライアント３８００に一度に送信できるが、このためにＩＧＭＰ（Internet Group Management Protocol）プロトコルなどを用いることができる。

前述したコンテンツプロバイダ３８１０およびサービスプロバイダ３８２０は、同一のエンティティ（same or single entity）であってもよい。例えば、コンテンツプロバイダ３８１０が作製したコンテンツをサービスパッケージ化してＨＮＥＤ３８４０に提供することによって、サービスプロバイダ３８２０の機能も共に行うか、その反対のこともある。

ネットワークプロバイダ３８３０は、コンテンツプロバイダ３８１０および／またはサービスプロバイダ３８２０とクライアント３８００との間のデータ交換のためのネットワーク網を提供する。

クライアント３８００は、ホームネットワークを構築してデータを送受信できる。

一方、サービスシステム内のコンテンツプロバイダ３８１０および／またはサービスプロバイダ３８２０は、送信されるコンテンツの保護のために、制限受信（conditional access）またはコンテンツ保護（content protection）手段を利用することができる。この場合、クライアント３８００は、上記制限受信やコンテンツ保護に対応し、ケーブルカード（Cable CARD）（ＰＯＤ：Point of Deployment）、ＤＣＡＳ（Downloadable CAS）などの処理手段を利用することができる。

その他に、クライアント３８００も、ネットワーク網（または通信網）を介して、両方向のサービスを利用することができる。このような場合、むしろクライアント３８００がコンテンツプロバイダの機能を行ってもよく、既存のサービスプロバイダ３８２０は、これを受信して再度他のクライアントへ送信してもよい。

図３９は、デジタル機器の一実施例を説明するために示す構成のブロック図である。ここで、図３９は、例えば、図３８のクライアント３８００に該当し得、前述したデジタル機器を意味する。

デジタル機器３９００は、ネットワークインターフェース部（network interface）３９０１、ＴＣＰ／ＩＰマネージャ（TCP/IP manager）３９０２、サービス配送（伝達）マネージャ（service delivery manager）３９０３、ＳＩデコーダ３９０４、逆多重化部（demux）３９０５、オーディオデコーダ（audio decoder）３９０６、ビデオデコーダ（video decoder）３９０７、ディスプレイ部（display A/V and OSD module）３９０８、サービス制御マネージャ（service control manager）３９０９、サービスディスカバリマネージャ（service discovery manager）３９１０、ＳＩ＆メタデータのデータベース（ＳＩ＆Ｍｅｔａｄａｔａ ＤＢ）３９１１、メタデータマネージャ（metadata manager）３９１２、サービスマネージャ３９１３、ＵＩマネージャ３９１４などを含んで構成される。

ネットワークインターフェース部３９０１は、ネットワーク網を介してＩＰパケット（Internet Protocol (IP) packets）を受信または送信する。すなわち、ネットワークインターフェース部３９０１は、ネットワーク網を介してサービスプロバイダ３８２０からサービス、コンテンツなどを受信する。

ＴＣＰ／ＩＰマネージャ３９０２は、デジタル機器３９００が受信するＩＰパケットおよびデジタル機器３９００が送信するＩＰパケットに対して、すなわち、送信元（ソース）（source）と送信先（目的地）（destination）との間のパケットの伝達に関与する。また、ＴＣＰ／ＩＰマネージャ３９０２は、受信したパケットを適切なプロトコルに対応するように分類し、サービス配送マネージャ３９０３、サービスディスカバリマネージャ３９１０、サービス制御マネージャ３９０９、メタデータマネージャ３９１２などに分類されたパケットを出力する。サービス配送マネージャ３９０３は、受信されるサービスデータの制御を担当する。例えば、サービス配送マネージャ３９０３は、リアルタイムストリーミング（real-time streaming）データを制御する場合には、ＲＴＰ／ＲＴＣＰを使用することができる。上記リアルタイムストリーミングデータをＲＴＰを使用して送信する場合、サービス配送マネージャ３９０３は、上記受信したデータパケットをＲＴＰによってパージング（parsing）して逆多重化部３９０５に送信するか、サービスマネージャ３９１３の制御によって、ＳＩ＆メタデータのデータベース３９１１に記憶する。また、サービス配送マネージャ３９０３は、ＲＴＣＰを用いて上記ネットワークの受信情報をサービスを提供するサーバ側にフィードバック（feedback）する。逆多重化部３９０５は、受信したパケットを、オーディオ、ビデオ、ＳＩ（System Information）データなどで逆多重化し、それぞれオーディオ／ビデオデコーダ３９０６／３９０７、ＳＩデコーダ３９０４に送信する。

ＳＩデコーダ３９０４は、例えば、ＰＳＩ（Program Specific Information）、ＰＳＩＰ（Program And System Information Protocol）、ＤＶＢ－ＳＩ（Digital Video Broadcasting-Service Information）などのサービス情報をデコードする。

また、ＳＩデコーダ３９０４は、デコードされたサービス情報を、例えば、ＳＩ＆メタデータのデータベース３９１１に記憶する。このように記憶されたサービス情報は、例えば、ユーザの要求などによって該当構成により読み出されて用いられる。

オーディオ／ビデオデコーダ３９０６／３９０７は、逆多重化部３９０５で逆多重化された各オーディオデータおよびビデオデータをデコードする。このようにデコードされたオーディオデータおよびビデオデータは、ディスプレイ部３９０８を介してユーザに提供される。

アプリケーションマネージャは、例えば、ＵＩマネージャ３９１４およびサービスマネージャ３９１３を含んで構成され得る。アプリケーションマネージャは、デジタル機器３９００の全般的な状態を管理してユーザインターフェースを提供し、他のマネージャを管理することができる。

ＵＩマネージャ３９１４は、ユーザのためのＧＵＩ（Graphic User Interface）をＯＳＤ（On Screen Display）などを用いて提供し、ユーザからキーの入力を受けて、上記記入力による機器動作を行う。例えば、ＵＩマネージャ３９１４は、ユーザからチャンネルの選択に関するキーの入力を受けると、上記キーの入力信号をサービスマネージャ３９１３に送信する。

サービスマネージャ３９１３は、サービス配送マネージャ３９０３、サービスディスカバリマネージャ３９１０、サービス制御マネージャ３９０９、メタデータマネージャ３９１２などのサービスに関するマネージャを制御する。

また、サービスマネージャ３９１３は、チャンネルマップ（channel map）を作り、ユーザインターフェースマネージャ３９１４から受信したキーの入力によって、上記チャンネルマップを用いてチャンネルを選択する。また、サービスマネージャ３９１３は、ＳＩデコーダ３９０４からチャンネルのサービス情報が送信されて選択されたチャンネルのオーディオ／ビデオＰＩＤ（Packet IDentifier）を逆多重化部３９０５に設定する。このように設定されるＰＩＤは、前述した逆多重化過程に用いられる。したがって、逆多重化部３９０５は、上記ＰＩＤを用いてオーディオデータ、ビデオデータ、およびＳＩデータをフィルタリング（filtering）する。

サービスディスカバリマネージャ３９１０は、サービスを提供するサービスプロバイダを選択するのに必要な情報を提供する。サービスマネージャ３９１３からチャンネルの選択に関する信号を受信すると、サービスディスカバリマネージャ３９１０は、上記情報を用いてサービスを見つける。

サービス制御マネージャ３９０９は、サービスの選択および制御を担当する。例えば、サービス制御マネージャ３９０９は、ユーザが既存の放送方式のような生放送（live broadcasting）サービスを選択する場合、ＩＧＭＰまたはＲＴＳＰなどを使用し、ＶＯＤ（Video On Demand）のようなサービスを選択する場合には、ＲＴＳＰを使用してサービスの選択、制御を行う。上記ＲＴＳＰプロトコルは、リアルタイムストリーミングに対してトリックモード（trick mode）を提供できる。また、サービス制御マネージャ３９０９は、ＩＭＳ（IP Multimedia Subsystem）、ＳＩＰ（Session Initiation Protocol）を用いて、ＩＭＳゲートウェイ３９５０を介したセクションを初期化して管理できる。プロトコルは、一実施例であり、実現例によって他のプロトコルを使用することもできる。

メタデータマネージャ３９１２は、サービスに関するメタデータを管理し、上記メタデータをＳＩ＆メタデータのデータベース３９１１に記憶する。

ＳＩ＆メタデータのデータベース３９１１は、ＳＩデコーダ３９０４がデコードしたサービス情報、メタデータマネージャ３９１２が管理するメタデータ、およびサービスディスカバリマネージャ３９１０が提供するサービスプロバイダを選択するのに必要な情報を記憶する。また、ＳＩ＆メタデータのデータベース３９１１は、システムに対するセットアップデータなどを記憶し得る。

ＳＩ＆メタデータのデータベース３９１１は、不揮発性メモリ（non-volatile RAM、ＮＶＲＡＭ）またはフラッシュメモリ（flash memory）などを使用して実現されることもできる。

一方、ＩＭＳゲートウェイ３９５０は、ＩＭＳベースのＩＰＴＶサービスにアクセスするために必要な機能を集めたゲートウェイである。

図４０は、デジタル機器の別の実施例を説明するために示す構成のブロック図である。特に、図４０は、デジタル機器の別の実施例であって、モバイル機器の構成のブロック図を例示したものである。

図４０を参照すると、モバイル機器４０００は、無線通信部４０１０、Ａ／Ｖ（Audio/Video）入力部４０２０、ユーザ入力部４０３０、センシング部４０４０、出力部４０５０、メモリ４０６０、インターフェース部４０７０、制御部４０８０、および電源供給部４０９０などを含み得る。図４０に示す構成要素は必須のものではないので、それより多くの構成要素を有するか、それよりも少ない構成要素を有するモバイル機器が実現されることもある。

無線通信部４０１０は、モバイル機器４０００と無線通信システムとの間、またはモバイル機器とモバイル機器が位置するネットワークとの間の無線通信を可能にする１つまたは複数のモジュールを含み得る。例えば、無線通信部４０１０は、放送受信モジュール４０１１、移動通信モジュール４０１２、無線インターネットモジュール４０１３、近距離通信モジュール４０１４、および位置情報モジュール４０１５などを含み得る。

放送受信モジュール４０１１は、放送チャンネルを介して外部の放送管理サーバから放送信号および／または放送に関連する情報を受信する。ここで、放送チャンネルは、衛星チャンネル、地上波チャンネルを含み得る。放送管理サーバは、放送信号および／もしくは放送関連の情報を生成して送信するサーバ、または既に生成された放送信号および／もしくは放送関連の情報を提供されて端末機に送信するサーバを意味し得る。放送信号は、ＴＶ放送信号、ラジオ放送信号、データ放送信号を含むだけでなく、ＴＶ放送信号またはラジオ放送信号にデータ放送信号が結合した形態の放送信号も含み得る。

放送関連の情報は、放送チャンネル、放送プログラムまたは放送サービスプロバイダに関する情報を意味し得る。放送関連の情報は、移動通信網を介しても提供できる。このような場合には、移動通信モジュール４０１２により受信され得る。

放送関連の情報は、様々な形態、例えば、ＥＰＧ（Electronic Program Guide）またはＥＳＧ（Electronic Service Guide）などの形態で存在し得る。

放送受信モジュール４０１１は、例えば、ＡＴＳＣ、ＤＶＢ－Ｔ（Digital Video Broadcasting-Terrestrial）、ＤＶＢ－Ｓ（Satellite）、ＭｅｄｉａＦＬｏ（Media Forward Link Only）、ＤＶＢ－Ｈ（Handheld）、ＩＳＤＢ－Ｔ（Integrated Services Digital Broadcast-Terrestrial）などのデジタル放送システムを用いてデジタル放送信号を受信することができる。もちろん、放送受信モジュール５１１は、前述したデジタル放送システムだけでなく、他の放送システムに適するように構成されることもできる。

放送受信モジュール４０１１を介して受信した放送信号および／または放送関連の情報は、メモリ４０６０に記憶され得る。

移動通信モジュール４０１２は、移動通信網上で基地局、外部端末、サーバの少なくとも１つと無線信号を送受信する。無線信号は、音声信号、画像通話信号、または文字／マルチメディアメッセージの送受信による様々な形態のデータを含み得る。

無線インターネットモジュール４０１３は、無線インターネットアクセスのためのモジュールを含めて、モバイル機器４０００に内装されるか外装され得る。無線インターネット技術としては、ＷＬＡＮ（Wireless LAN）（Ｗｉ－Ｆｉ）、Ｗｉｂｒｏ（Wireless broadband）、Ｗｉｍａｘ（World interoperability for microwave access）、ＨＳＤＰＡ（High Speed Downlink Packet Access）などが用いられる。

近距離通信モジュール４０１４は、近距離通信のためのモジュールをいう。近距離通信（short range communication）技術として、ブルートゥース（Bluetooth）（登録商標）、ＲＦＩＤ（Radio Frequency IDentification）、赤外線通信（ＩｒＤＡ，Infrared Data Association）、ＵＷＢ（Ultra WideBand）、ＺｉｇＢｅｅ、ＲＳ－２３２、ＲＳ－４８５などが用いられる。

位置情報モジュール４０１５は、モバイル機器４０００の位置情報の獲得のためのモジュールとして、ＧＰＳ（Global Position System）モジュールを例に挙げることができる。

Ａ／Ｖ入力部４０２０は、オーディオおよび／またはビデオ信号の入力のためのものであって、ここでは、カメラ４０２１およびマイク４０２２などが含まれ得る。カメラ４０２１は、画像通話モードまたは撮影モードでイメージセンサにより得られる静止画（停止映像）または動画などの画像フレームを処理する。処理された画像フレームは、ディスプレイ部４０５１に表され得る。

カメラ４０２１で処理された画像フレームは、メモリ４０６０に記憶されるか無線通信部４０１０を介して外部へ送信され得る。カメラ４０２１は、使用環境によって２つ以上が備えられることもある。

マイク４０２２は、通話モードまたは録音モード、音声認識モードなどでマイクロフォン（microphone）により外部の音響信号が入力され、電気的な音声データで処理する。処理された音声データは、通話モードである場合、移動通信モジュール４０１２を介して移動通信基地局へ送信可能な形態に変換されて出力されることができる。マイク４０２２では、外部の音響信号が入力される過程で発生する雑音（noise）を除去するための様々な雑音除去のアルゴリズムが実現され得る。

ユーザ入力部４０３０は、ユーザが端末機の動作制御のための入力データを発生させる。ユーザ入力部４０３０は、キーパッド（key pad）、ドームスイッチ（dome switch）、タッチパッド（定圧／静電）、ジョグホイール（jog wheel）、ジョグスイッチ（jog switch）などで構成され得る。

センシング部４０４０は、モバイル機器４０００の開閉状態、モバイル機器４０００の位置、ユーザの接触の有無、モバイル機器の方位、モバイル機器の加速／減速などのように、モバイル機器４０００の現在の状態を感知し、モバイル機器４０００の動作制御のためのセンシング信号を発生させる。例えば、モバイル機器４０００が移動されるか傾いた場合、モバイル機器の位置または傾きなどをセンシングできる。また、電源供給部４０９０の電源供給の有無、インターフェース部４０７０の外部機器の結合の有無等もセンシングすることもできる。一方、センシング部４０４０は、ＮＦＣ（Near Field Communication）を含む近接センサ４０４１を含み得る。

出力部４０５０は、視覚、聴覚、または触覚などに関する出力を発生させるためのものであって、ディスプレイ部４０５１、音響出力モジュール４０５２、アラーム部４０５３、およびハプティックモジュール４０５４などが含まれ得る。

ディスプレイ部４０５１は、モバイル機器４０００で処理される情報を表示（出力）する。例えば、モバイル機器が通話モードである場合、通話と関連するＵＩ（User Interface）またはＧＵＩ（Graphic User Interface）を表示する。モバイル機器４０００が画像通話モードまたは撮影モードである場合には、撮影および／または受信した映像またはＵＩ、ＧＵＩを表示する。

ディスプレイ部４０５１は、液晶ディスプレイ（Liquid Crystal Display、ＬＣＤ）、薄膜トランジスタの液晶ディスプレイ（Thin Film Transistor-Liquid Crystal Display、ＴＦＴ ＬＣＤ）、有機発光ダイオード（Organic Light-Emitting Diode、ＯＬＥＤ）、フレキシブルディスプレイ（flexible display）、３次元ディスプレイ（3D display）の少なくとも１つを含み得る。

これらのうちの一部のディスプレイは、それを介して外部を見ることができるように透明型または光透過型で構成され得る。これは、透明ディスプレイと呼ばれるが、上記透明ディスプレイの代表的な例としては、ＴＯＬＥＤ（transparent OLED）などがある。ディスプレイ部４０５１の後方構造もまた光透過型構造で構成され得る。このような構造により、ユーザは、端末機の本体（ボディ）のディスプレイ部４０５１の占める領域を介して、端末機の本体（body）の後方に位置する物を見ることができる。

モバイル機器４０００の実現形態によって、ディスプレイ部４０５１が２つ以上存在し得る。例えば、モバイル機器４０００には、複数のディスプレイ部が１つの面に離隔されるか一体で配置されてもよく、また、互いに異なる面にそれぞれ配置されてもよい。

ディスプレイ部４０５１とタッチ動作を感知するセンサ（以下「タッチセンサ」という）とが相互レイヤ構造をなす場合（以下「タッチスクリーン」という）に、ディスプレイ部４０５１は、出力装置以外に入力装置としても使用され得る。タッチセンサは、例えば、タッチフィルム、タッチシート、タッチパッドなどの形態を有し得る。

タッチセンサは、ディスプレイ部４０５１の特定部位に加えられた圧力、またはディスプレイ部４０５１の特定部位に発生する静電容量などの変化を電気的な入力信号に変換するように構成され得る。タッチセンサは、タッチされる位置および面積だけでなく、タッチ時の圧力までも検出できるように構成され得る。

タッチセンサに対するタッチ入力がある場合、それに対応する信号は、タッチ制御器に送られる。タッチ制御器は、その信号を処理した後、対応するデータを制御部４０８０に送信する。これによって、制御部４０８０は、ディスプレイ部４０５１のどの領域がタッチされているか否かなどが分かるようになる。

タッチスクリーンにより包まれるモバイル機器の内部領域、または上記タッチスクリーンの近辺に近接センサ４０４１が配置され得る。上記近接センサは、所定の検出面にアプローチする物体、あるいは、近傍に存在する物体の有無を電磁界の力または赤外線を用いて機械的接触なしで検出するセンサをいう。近接センサは、接触式センサより、その寿命が長く、その活用もまた高い。

近接センサの例としては、透過型光電センサ、直接反射型光電センサ、ミラー反射型光電センサ、高周波発振型近接センサ、静電容量型近接センサ、磁気型近接センサ、赤外線近接センサなどがある。上記タッチスクリーンが静電式である場合には、上記ポインタの近接による電界の変化でポインタの近接を検出するように構成される。この場合、タッチスクリーン（タッチセンサ）は、近接センサに分類されることもある。

以下では、説明の便宜のために、タッチスクリーン上にポインタが接触され（ない）ながらも、近接されてポインタがタッチスクリーン上に位置することが認識されるようにする行為を「近接タッチ（proximity touch）」と称し、上記タッチスクリーン上にポインタが実際に接触する行為を「接触タッチ（contact touch）」と称する。タッチスクリーン上でポインタで近接タッチされる位置というのは、ポインタが近接タッチされる際、ポインタがタッチスクリーンに対して垂直に対応する位置を意味する。

近接センサは、近接タッチと、近接タッチパターン（例えば、近接タッチ距離、近接タッチ方向、近接タッチ速度、近接タッチ時間、近接タッチ位置、近接タッチ移動状態など）と、を感知する。感知された近接タッチ動作および近接タッチパターンに相応する情報は、タッチスクリーン上に出力されることができる。

音響出力モジュール４０５２は、呼信号の受信、通話モードまたは録音モード、音声認識モード、放送受信モードなどで無線通信部４０１０から受信されるか、メモリ４０６０に記憶されたオーディオデータを出力することができる。音響出力モジュール４０５２は、モバイル機器４０００で行われる機能（例えば、呼信号の受信音、メッセージ受信音など）に関する音響信号を出力することもある。このような音響出力モジュール４０５２には、レシーバ（receiver）、スピーカ（speaker）、ブザー（buzzer）などが含まれ得る。

アラーム部４０５３は、モバイル機器４０００のイベントの発生を知らせるための信号を出力する。モバイル機器で発生するイベントの例としては、呼信号の受信、メッセージ受信、キー信号入力、タッチ入力などがある。アラーム部４０５３は、ビデオ信号やオーディオ信号以外に異なる形態、例えば、振動でイベントの発生を知らせるための信号を出力することもできる。

ビデオ信号やオーディオ信号は、ディスプレイ部４０５１や音声出力モジュール４０５２を介しても出力されることができ、ディスプレイ部および音声出力モジュール４０５１、４０５２は、アラーム部４０５３の一部に分類されることもできる。

ハプティックモジュール（haptic module）４０５４は、ユーザが感じる様々な触覚効果を発生させる。ハプティックモジュール４０５４が発生させる触覚効果の代表的な例としては、振動がある。ハプティックモジュール４０５４が発生する振動の強さとパターンなどは制御可能である。例えば、互いに異なる振動を合成して出力するか、順次出力することもできる。

ハプティックモジュール４０５４は、振動以外にも、接触皮膚面に対して垂直運動するピン配列、噴射口や吸入口を介した空気の噴射力や吸入力、皮膚表面に対する擦れ、電極（electrode）の接触、静電気力などの刺激による効果と、吸熱や発熱可能な素子を用いた冷温感の再現による効果などと、様々な触覚効果を発生させることができる。

ハプティックモジュール４０５４は、直接的な接触を介して触覚効果を伝達することができるだけでなく、ユーザが指や腕などの筋感覚を介して触覚効果を感じることができるように実現することもできる。ハプティックモジュール４０５４は、モバイル機器４０００の構成様態によって２つ以上が備えられる。

メモリ４０６０は、制御部４０８０の動作のためのプログラムを記憶することができ、入／出力されるデータ（例えば、電話帳（フォンブック）、メッセージ、静止画、動画など）を一時（仮）記憶することもできる。メモリ４０６０は、上記タッチスクリーン上のタッチ入力の際に出力される様々なパターンの振動および音響に関するデータを記憶することができる。

メモリ４０６０は、フラッシュメモリタイプ（flash memory type）、ハードディスクタイプ（hard disk type）、マルチメディアカードマイクロタイプ（multimedia card micro type）、カードタイプのメモリ（例えば、ＳＤまたはＸＤメモリなど）、ラム（Random Access Memory、ＲＡＭ）、ＳＲＡＭ（Static Random Access Memory）、ロム（Read-Only Memory、ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）、ＰＲＯＭ（Programmable Read-Only Memory）、磁気メモリ、磁気ディスク、光ディスクの少なくとも１つのタイプの記憶媒体を含み得る。モバイル機器４０００は、インターネット（internet）上でメモリ４０６０の記憶機能を行うウェブストレージ（web storage）に関して動作することもできる。

インターフェース部４０７０は、モバイル機器４０００に接続される全ての外部機器との通信路の役割を担う。インターフェース部４０７０は、外部機器からデータの送信を受けるか、電源が供給され、モバイル機器４０００内部の各構成要素に伝達するか、モバイル機器４０００内部のデータが外部機器へ送信されるようにする。例えば、有／無線ヘッドセットポート、外部充電器ポート、有／無線データポート、メモリカード（memory card）ポート、識別モジュールが備えられた装置を接続するポート、オーディオＩ／Ｏ（Input/Output）ポート、ビデオＩ／Ｏポート、イヤホーンポートなどがインターフェース部４０７０に含まれ得る。

識別モジュールは、モバイル機器４０００の使用権限を認証するための各種情報を記憶したチップであって、ユーザ認証（識別）モジュール（User Identify Module、ＵＩＭ）、加入者認証モジュール（Subscriber Identify Module、ＳＩＭ）、汎用ユーザ認証モジュール（Universal Subscriber Identity Module、ＵＳＩＭ）などを含み得る。識別モジュールが備えられた装置（以下「識別装置」）は、スマートカード（smart card）の形式で作製され得る。したがって、識別装置は、ポートを介して端末機４０００と接続され得る。

インターフェース部４０７０は、移動端末機４０００が外部のクレードル（cradle）と接続される際、クレードルからの電源が移動端末機４０００に供給される通信路になるか、ユーザによりクレードルで入力される各種の命令信号が移動端末機に伝達される通信路になり得る。クレードルから入力される各種の命令信号または電源は、移動端末機がクレードルに正確に装着されたことを認知するための信号として動作されることもある。

制御部４０８０は、通常、モバイル機器の全般的な動作を制御する。例えば、音声通話、データ通信、画像通話などのための関連する制御および処理を行う。制御部４０８０は、マルチメディアの再生のためのマルチメディアモジュール４０８１を備えることもできる。マルチメディアモジュール４０８１は、制御部４０８０内に実現されてもよく、制御部４０８０と別に実現されてもよい。制御部４０８０、特にマルチメディアモジュール４０８１は、前述したエンコード装置１００および／またはデコード装置２００を含み得る。

制御部４０８０は、タッチスクリーン上で行われる筆記入力または絵を描く入力をそれぞれ文字およびイメージで認識できるパターン認識処理を行うことができる。

電源供給部４０９０は、制御部４０８０の制御により外部の電源、内部の電源が認可され、各構成要素の動作に必要な電源を供給する。

ここに説明される様々な実施例は、例えば、ソフトウェア、ハードウェア、またはこれらの組み合わせたものを用いて、コンピュータまたはこれと類似する装置で読み取られる記録媒体内で実現されることができる。

ハードウェア的な実現によると、ここに説明される実施例は、ＡＳＩＣｓ（Application Specific Integrated Circuits）、ＤＳＰｓ（Digital Signal Processors）、ＤＳＰＤｓ（Digital Signal Processing Devices）、ＰＬＤｓ（Programmable Logic Devices）、ＦＰＧＡｓ（Field Programmable Gate Arrays、プロセッサ、制御器、マイクロコントローラ（micro-controllers）、マイクロプロセッサ（microprocessors）、その他の機能を実行するための電気的なユニットの少なくとも１つを用いて実現され得る。一部の場合に、本明細書で説明される実施例が制御部４０８０自体で実現され得る。

ソフトウェア的な実現によると、本明細書で説明される手続および機能のような実施例は、別途のソフトウェアモジュールで実現され得る。ソフトウェアモジュールのそれぞれは、本明細書で説明される１つまたは複数の機能および動作を行うことができる。適切なプログラム言語で書かれたソフトウェアアプリケーションでソフトウェアコードが実現され得る。ここで、ソフトウェアコードは、メモリ４０６０に記憶され、制御部４０８０により実行され得る。

図４１は、デジタル機器のさらに他の実施例を説明するために示す構成のブロック図である。

デジタル機器４１００の別の例は、放送受信部４１０５、外部装置インターフェース部４１３５、記憶部４１４０、ユーザ入力インターフェース部４１５０、制御部４１７０、ディスプレイ部４１８０、オーディオ出力部４１８５、電源供給部４１９０、および撮影部（図示せず）を含み得る。ここで、放送受信部４１０５は、少なくとも１つのチューナ４１１０、復調部４１２０、およびネットワークインターフェース部４１３０を含み得る。ただし、場合によって、放送受信部４１０５は、チューナ４１１０および復調部４１２０を備えるが、ネットワークインターフェース部４１３０を含まないことがあり、その反対の場合もある。また、放送受信部４１０５は、示していないが、多重化部（multiplexer）を備えてチューナ４１１０を経て復調部４１２０で復調された信号とネットワークインターフェース部４１３０を経て受信した信号とを多重化することもできる。その他に、放送受信部４０２５は、やはり示していないが、逆多重化部（demultiplexer）を備えて上記多重化された信号を逆多重化するか、上記復調された信号または上記ネットワークインターフェース部４１３０を経た信号を逆多重化することができる。

チューナ４１１０は、アンテナを介して受信されるＲＦ（Radio Frequency）放送信号のうち、ユーザにより選択されたチャンネル、または既に記憶された全てのチャンネルをチューニングしてＲＦ放送信号を受信する。また、チューナ４１１０は、受信したＲＦ放送信号を中間周波数（Intermediate Frequency、ＩＦ）信号またはベースバンド（baseband）信号に変換する。

例えば、受信したＲＦ放送信号がデジタル放送信号である場合、デジタルＩＦ信号（ＤＩＦ）に変換し、アナログ放送信号である場合、アナログベースバンド映像または音声信号（ＣＶＢＳ／ＳＩＦ）に変換する。すなわち、チューナ４１１０は、デジタル放送信号またはアナログ放送信号を全て処理することができる。チューナ４１１０で出力されるアナログベースバンド映像または音声信号（ＣＶＢＳ／ＳＩＦ）は、制御部４１７０に直接入力されることができる。

また、チューナ４１１０は、ＡＴＳＣ（Advanced Television System Committee）方式による単一キャリアのＲＦ放送信号またはＤＶＢ（Digital Video Broadcasting）方式による複数のキャリアのＲＦ放送信号を受信することができる。

一方、チューナ４１１０は、アンテナを介して受信されるＲＦ放送信号のうち、チャンネル記憶機能を介して記憶された全ての放送チャンネルのＲＦ放送信号を順次チューニングおよび受信し、これを中間周波数信号またはベースバンド信号に変換することができる。

復調部４１２０は、チューナ４１１０で変換されたデジタルＩＦ信号（ＤＩＦ）を受信して復調する。例えば、チューナ４１１０で出力されるデジタルＩＦ信号がＡＴＳＣ方式である場合、復調部４１２０は、例えば、８－ＶＳＢ（8-Vestigal Side Band）復調を行う。また、復調部４１２０は、チャネルの復号を行うこともできる。このため、復調部４１２０は、トレリスデコーダ（trellis decoder）、デインターリーバ（de-interleaver）、およびリードソロモンデコーダ（Reed-Solomon decoder）などを備え、トレリス復号、デインターリーブ、およびリードソロモン復号を行うことができる。

例えば、チューナ４１１０で出力されるデジタルＩＦ信号がＤＶＢ方式である場合、復調部４１２０は、例えば、ＣＯＦＤＭＡ（Coded Orthogonal Frequency Division Modulation）復調を行う。また、復調部４１２０は、チャネルの復号を行うこともできる。このため、復調部４１２０は、コンボリューションデコーダ（convolution decoder）、デインターリーバ、およびリードソロモンデコーダなどを備え、コンボリューション復号、デインターリーブ、およびリードソロモン復号を行うことができる。

復調部４１２０は、復調およびチャネルの復号を行った後、ストリーム信号（ＴＳ）を出力することができる。この際、ストリーム信号は、映像信号、音声信号またはデータ信号が多重化された信号であってもよい。一例として、ストリーム信号は、ＭＰＥＧ－２規格の映像信号、ドルビ（Dolby）ＡＣ－３規格の音声信号などが多重化されたＭＰＥＧ－２ ＴＳ（Transport Stream）であってもよい。具体的には、ＭＰＥＧ－２ ＴＳは、４バイト（byte）のヘッダ（header）および１８４バイトのペイロード（payload）を含み得る。

一方、前述した復調部４１２０は、ＡＴＳＣ方式およびＤＶＢ方式によってそれぞれ別に備えられることが可能である。すなわち、デジタル機器は、ＡＴＳＣ復調部およびＤＶＢ復調部をそれぞれ別に備えることができる。

復調部４１２０で出力したストリーム信号は、制御部４１７０に入力されることができる。制御部４１７０は、逆多重化、映像／音声信号の処理などを制御し、ディスプレイ部４１８０を介して映像を、オーディオ出力部４１８５を介して音声の出力を制御することができる。

外部装置インターフェース部４１３５は、デジタル機器４１００と様々な外部装置がインターフェースを取れるように環境を提供する。このため、外部装置インターフェース部４１３５は、Ａ／Ｖ入出力部（図示せず）または無線通信部（図示せず）を含み得る。

外部装置インターフェース部４１３５は、ＤＶＤ（Digital Versatile Disk）、ブルーレイ（blu-ray）、ゲーム機器、カメラ、カムコーダ、コンピュータ（ノートパソコン、タブレット）、スマートフォン、ブルートゥース機器（Bluetooth device）（登録商標）、クラウド（cloud）などの外部装置と有／無線で接続され得る。外部装置インターフェース部４１３５は、接続された外部装置を介して外部で入力される映像、音声またはデータ（イメージ含む）信号をデジタル機器の制御部４１７０に伝達する。制御部４１７０は、処理された映像、音声またはデータ信号を接続された外部装置に出力されるように制御できる。このため、外部装置インターフェース部４１３５は、Ａ／Ｖ入出力部（図示せず）または無線通信部（図示せず）をさらに含み得る。

Ａ／Ｖ入出力部は、外部装置の映像および音声信号をデジタル機器４１００に入力できるように、ＵＳＢ端子、ＣＶＢＳ（Composite Video Banking Sync）端子、コンポーネント端子、Ｓ－ビデオ端子（アナログ）、ＤＶＩ（Digital Visual Interface）端子、ＨＤＭＩ（High Definition Multimedia Interface）（登録商標）端子、ＲＧＢ端子、Ｄ－ＳＵＢ端子などを含み得る。

無線通信部は、他の電子機器と近距離無線通信を行うことができる。デジタル機器４１００は、例えば、ブルートゥース（Bluetooth）（登録商標）、ＲＦＩＤ（Radio Frequency Identification）、赤外線通信（IrDA、infrared data association）、ＵＷＢ（Ultra Wideband）、ジグビ（ＺｉｇＢｅｅ）、ＤＬＮＡ（Digital Living Network Alliance）（登録商標）などの通信プロトコルによって、他の電子機器とネットワークで接続され得る。

また、外部装置インターフェース部４１３５は、多様なセットトップボックスや前述した各種端子の少なくとも１つを介して接続され、セットトップボックスと入力／出力動作を行うこともできる。

一方、外部装置インターフェース部４１３５は、隣接する外部装置内のアプリケーションまたはアプリケーションリストを受信し、制御部４１７０または記憶部４１４０へ伝達できる。

ネットワークインターフェース部４１３０は、デジタル機器４１００をインターネット網を含む有／無線ネットワークと接続するためのインターフェースを提供する。ネットワークインターフェース部４１３０は、有線ネットワークとの接続のために、例えば、イーサネット（Ethernet）（登録商標）端子などを備えることができ、無線ネットワークとの接続のために、例えば、ＷＬＡＮ（Wireless LAN）（Ｗｉ－Ｆｉ）、Ｗｉｂｒｏ（Wireless broadband）、Ｗｉｍａｘ（World interoperability for microwave access）、ＨＳＤＰＡ（High Speed Downlink Packet Access）の通信規格などを用いることができる。

ネットワークインターフェース部４１３０は、接続されたネットワークまたは接続されたネットワークにリンクされた他のネットワークを介して、他のユーザまたは他のデジタル機器とデータを送信または受信できる。特に、デジタル機器４１００に予め登録された他のユーザまたは他のデジタル機器のうちの選択されたユーザまたは選択されたデジタル機器に、デジタル機器４１００に記憶された一部のコンテンツデータを送信することができる。

一方、ネットワークインターフェース部４１３０は、接続されたネットワークまたは接続されたネットワークにリンクされた他のネットワークを介して、所定のウェブページに接続することができる。すなわち、ネットワークを介して所定のウェブページに接続し、該当サーバとデータを送信または受信することができる。その他、コンテンツプロバイダまたはネットワーク運営者が提供するコンテンツまたはデータを受信することができる。すなわち、ネットワークを介して、コンテンツプロバイダまたはネットワークプロバイダから提供される、映画、広告、ゲーム、ＶＯＤ、放送信号などのコンテンツ、およびそれに関する情報を受信することができる。また、ネットワーク運営者が提供するファームウェア（firmware）のアップデート情報およびアップデートファイルを受信することができる。さらに、インターネットもしくはコンテンツプロバイダまたはネットワーク運営者にデータを送信することができる。

また、ネットワークインターフェース部４１３０は、ネットワークを介して、公衆に公開（open）されたアプリケーションのうち、希望するアプリケーションを選択して受信できる。

記憶部４１４０は、制御部４１７０内の各信号処理および制御のためのプログラムを記憶することもでき、信号処理された映像、音声またはデータ信号を記憶することもできる。

また、記憶部４１４０は、外部装置インターフェース部４１３５またはネットワークインターフェース部４１３０から入力される、映像、音声、またはデータ信号の一時記憶のための機能を行うこともできる。記憶部４１４０は、チャンネル記憶機能を介して、所定の放送チャンネルに関する情報を記憶することができる。

記憶部４１４０は、外部装置インターフェース部４１３５またはネットワークインターフェース部４１３０から入力される、アプリケーションまたはアプリケーションリストを記憶することができる。

また、記憶部４１４０は、後述して説明する様々なプラットフォーム（platform）を記憶することもできる。

記憶部４１４０は、例えば、フラッシュメモリタイプ（flash memory type）、ハードディスクタイプ（hard disk type）、マルチメディアカードマイクロタイプ（multimedia card micro type）、カードタイプのメモリ（例えば、ＳＤまたはＸＤメモリなど）、ラム（ＲＡＭ）、ロム（ＥＥＰＲＯＭなど）の少なくとも１つのタイプの記憶媒体を含み得る。デジタル機器４１００は、記憶部４１４０内に記憶されているコンテンツファイル（動画ファイル、静止画ファイル、音楽ファイル、文書ファイル、アプリケーションファイルなど）を再生してユーザに提供できる。

図４１は、記憶部４１４０が制御部４１７０と別に備えられた実施例を示しているが、本明細書の範囲はこれに限定されない。すなわち、記憶部４１４０は、制御部４１７０内に含まれることもある。

ユーザ入力インターフェース部４１５０は、ユーザが入力した信号を制御部４１７０へ伝達するか、制御部４１７０の信号をユーザに伝達する。

例えば、ユーザ入力インターフェース部４１５０は、ＲＦ通信方式、赤外線（ＩＲ）通信方式など、多様な通信方式によって、遠隔制御装置５７００から電源のオン／オフ、チャンネル選択、画面設定などの制御信号を受信して処理するか、制御部４１７０の制御信号を遠隔制御装置５７００へ送信するように処理することができる。

また、ユーザ入力インターフェース部４１５０は、電源キー、チャンネルキー、ボリュームキー、設定値などのローカルキー（図示せず）で入力される制御信号を制御部４１７０に伝達できる。

ユーザ入力インターフェース部４１５０は、ユーザのジェスチャ（gesture）をセンシング（sensing）するセンシング部（図示せず）から入力される制御信号を制御部４１７０に伝達するか、制御部４１７０の信号をセンシング部（図示せず）へ送信できる。ここで、センシング部（図示せず）は、タッチセンサ、音声センサ、位置センサ、動作センサなどを含み得る。

制御部４１７０は、チューナ４１１０、復調部４１２０または外部装置インターフェース部４１３５を介して入力されるストリームを逆多重化するか、逆多重化された信号を処理し、映像または音声の出力のための信号を生成および出力できる。制御部４１７０は、前述したエンコード装置および／またはデコード装置を含み得る。

制御部４１７０で処理された映像信号は、ディスプレイ部４１８０に入力され、該当映像信号に対応する映像で表され得る。また、制御部４１７０で映像処理された映像信号は、外部装置インターフェース部４１３５を介して外部出力装置に入力され得る。

制御部４１７０で処理された音声信号は、オーディオ出力部４１８５にオーディオ出力され得る。また、制御部４１７０で処理された音声信号は、外部装置インターフェース部４１３５を介して外部出力装置に入力され得る。

図４１では示していないが、制御部４１７０は、逆多重化部、映像処理部などを含み得る。

制御部４１７０は、デジタル機器４１００の全般的な動作を制御することができる。例えば、制御部４１７０は、チューナ４１１０を制御し、ユーザが選択したチャンネルまたは既に記憶されたチャンネルに該当するＲＦ放送をチューニング（tuning）するように制御できる。

制御部４１７０は、ユーザ入力インターフェース部４１５０を介して入力されたユーザ命令、または内部のプログラムによってデジタル機器４１００を制御することができる。特に、ネットワークに接続してユーザが希望するアプリケーションまたはアプリケーションリストをデジタル機器４１００内にダウンロードするようにすることができる。

例えば、制御部４１７０は、ユーザ入力インターフェース部４１５０を介して受信した所定のチャンネルの選択命令によって選択したチャンネルの信号が入力されるようにチューナ４１１０を制御する。また、選択したチャンネルの映像、音声またはデータ信号を処理する。制御部４１７０は、ユーザが選択したチャンネル情報などが、処理された映像または音声信号と共に、ディスプレイ部４１８０またはオーディオ出力部４１８５を介して出力されることができるようにする。

別の例として、制御部４１７０は、ユーザ入力インターフェース部４１５０を介して受信した外部装置の映像再生命令によって、外部装置インターフェース部４１３５を介して入力される外部装置、例えば、カメラまたはカムコーダからの映像信号または音声信号が、ディスプレイ部４１８０またはオーディオ出力部４１８５を介して出力されることができるようにする。

一方、制御部４１７０は、映像を表示するようにディスプレイ部４１８０を制御することができる。例えば、チューナ４１１０を介して入力される放送映像、または外部装置インターフェース部４１３５を介して入力される外部入力映像、またはネットワークインターフェース部を介して入力される映像、または記憶部４１４０に記憶された映像を、ディスプレイ部４１８０に表示するように制御できる。この際、ディスプレイ部４１８０に表示される映像は、静止画または動画であってもよく、２Ｄ映像または３Ｄ映像であってもよい。

また、制御部４１７０は、コンテンツを再生するように制御できる。この際のコンテンツは、デジタル機器４１００内に記憶されたコンテンツ、または受信した放送コンテンツ、外部から入力される外部入力コンテンツであってもよい。コンテンツは、放送映像、外部入力映像、オーディオファイル、静止画、接続されたウェブ画面、および文書ファイルの少なくとも１つであってもよい。

一方、制御部４１７０は、アプリケーションビューの項目を入力する（に進入する）場合、デジタル機器４１００内または外部のネットワークからダウンロード可能なアプリケーションまたはアプリケーションリストを表示するように制御できる。

制御部４１７０は、様々なユーザインターフェースと共に、外部のネットワークからダウンロードされるアプリケーションをインストール（設置）および駆動するように制御できる。また、ユーザの選択により、実行されるアプリケーションに関する映像がディスプレイ部４１８０に表示されるように制御できる。

一方、図に示していないが、チャンネル信号または外部の入力信号に対応するサムネイルのイメージを生成するチャンネルブラウジング処理部がさらに備えられることも可能である。

チャンネルブラウジング処理部は、復調部４１２０で出力したストリーム信号（ＴＳ）または外部装置インターフェース部４１３５で出力したストリーム信号などの入力を受け、入力されるストリーム信号から映像を抽出し、サムネイルの映像を生成することができる。

生成されたサムネイルの映像は、そのまま、または符号化され、制御部４１７０に入力され得る。また、生成されたサムネイルの映像は、ストリームの形態で符号化され、制御部４１７０に入力されることも可能である。制御部４１７０は、入力されたサムネイルの映像を用いて、複数のサムネイルの映像を備えるサムネイルリストをディスプレイ部４１８０に表示することができる。一方、このようなサムネイルリスト内のサムネイルの映像は、次第にまたは同時にアップデートされ得る。これによって、ユーザは、複数の放送チャンネルの内容を簡便に把握できるようになる。

ディスプレイ部４１８０は、制御部４１７０で処理された映像信号、データ信号、ＯＳＤ信号、または外部装置インターフェース部４１３５で受信される映像信号、データ信号などを、それぞれＲ、Ｇ、Ｂ信号に変換して駆動信号を生成する。

ディスプレイ部４１８０は、ＰＤＰ、ＬＣＤ、ＯＬＥＤ、フレキシブルディスプレイ（flexible display）、３次元ディスプレイ（3D display）などが可能である。

一方、ディスプレイ部４１８０は、タッチスクリーンで構成され、出力装置以外に入力装置として使用されることも可能である。

オーディオ出力部４１８５は、制御部４１７０で音声処理された信号、例えば、ステレオ信号、３．１チャンネル信号または５．１チャンネル信号の入力を受け、音声で出力する。音声出力部４１８５は、様々な形態のスピーカで実現され得る。

一方、ユーザのジェスチャを感知するために、前述したように、タッチセンサ、音声センサ、位置センサ、動作センサの少なくとも１つを備えるセンシング部（図示せず）がデジタル機器４１００にさらに備えられる。センシング部（図示せず）で感知された信号は、ユーザ入力インターフェース部４１５０を介して制御部４１７０へ伝達されることができる。

一方、ユーザを撮影する撮影部（図示せず）がさらに備えられる。撮影部（図示せず）で撮影された映像情報は、制御部４１７０に入力され得る。

制御部４１７０は、撮影部（図示せず）から撮影された映像、またはセンシング部（図示せず）からの感知された信号を、それぞれまたは組み合わせてユーザのジェスチャを感知することもできる。

電源供給部４１９０は、デジタル機器４１００全般にわたって、該当電源を供給する。

特に、システムオンチップ（System On Chip、ＳＯＣ）の形態で実現され得る制御部４１７０と、映像表示のためのディスプレイ部４１８０と、オーディオの出力のためのオーディオ出力部４１８５と、に電源を供給することができる。

このため、電源供給部４１９０は、交流電源を直流電源に変換するコンバータ（図示せず）を備えることができる。一方、例えば、ディスプレイ部４１８０が多数のバックライトランプを備える液晶パネルとして実現される場合、輝度可変またはディミング（dimming）駆動のために、ＰＷＭ動作可能なインバータ（図示せず）をさらに備えることもできる。

遠隔制御装置４２００は、ユーザ入力をユーザ入力インターフェース部４１５０へ送信する。このため、遠隔制御装置４２００は、ブルートゥース（Bluetooth）（登録商標）、ＲＦ（Radio Frequency）通信、赤外線（ＩＲ）通信、ＵＷＢ（Ultra Wideband）、ジグビ（ZigBee）方式などを使用することができる。

また、遠隔制御装置４２００は、ユーザ入力インターフェース部４１５０で出力した映像、音声またはデータ信号などを受信し、これを遠隔制御装置４２００で表示するか、音声または振動を出力することができる。

前述したデジタル機器４１００は、固定型または移動型のＡＴＳＣ方式またはＤＶＢ方式のデジタル放送信号の処理が可能なデジタル放送受信器であり得る。

その他に、本明細書によるデジタル機器は、示している構成のうち、必要に応じて一部の構成を省略するか、逆に示していない構成をさらに含むこともある。一方、デジタル機器は、前述したものと異なり、チューナおよび復調部を備えず、ネットワークインターフェース部または外部装置インターフェース部を介してコンテンツを受信して再生することもできる。

図４２は、図３９乃至図４１の制御部の詳細構成の一実施例を説明するために示した構成のブロック図である。

制御部の一例は、逆多重化部４２１０、映像処理部４２２０、ＯＳＤ（On-Screen Display）生成部４２４０、ミキサ（mixer）４２５０、フレームレート変換部（Frame Rate Converter、ＦＲＣ）４２５５、およびフォーマット（formatter）４２６０を含み得る。その他、上記制御部は示していないが、音声処理部およびデータ処理部をさらに含み得る。

逆多重化部４２１０は、入力されるストリームを逆多重化する。例えば、逆多重化部４２１０は、入力されるＭＰＥＧ－２ ＴＳを、映像、音声およびデータ信号に逆多重化できる。ここで、逆多重化部４２１０に入力されるストリーム信号は、チューナまたは復調部または外部装置インターフェース部で出力されるストリーム信号であり得る。

映像処理部４２２０は、逆多重化された映像信号の映像処理を行う。このため、映像処理部４２２０は、映像デコーダ４２２５およびスケーラ４２３５を備えることができる。

映像デコーダ４２２５は、逆多重化された映像信号を復号し、スケーラ４２３５は、復号された映像信号の解像度をディスプレイ部で出力可能なようにスケーリング（scaling）する。

映像デコーダ４２２５は、様々な規格をサポートすることができる。例えば、映像デコーダ４２２５は、映像信号がＭＰＥＧ－２規格で符号化された場合には、ＭＰＥＧ－２デコーダの機能を行い、映像信号がＤＭＢ（Digital Multimedia Broadcasting）方式またはＨ．２６４規格で符号化された場合には、Ｈ．２６４デコーダの機能を行うことができる。

一方、映像処理部４２２０で復号された映像信号は、ミキサ４２５０に入力される。

ＯＳＤ生成部４２４０は、ユーザ入力によって、または自主的にＯＳＤデータを生成する。例えば、ＯＳＤ生成部４２４０は、ユーザ入力インターフェース部の制御信号に基づいて、ディスプレイ部４１８０の画面に各種データをグラフィック（graphic）やテキスト（text）の形態で表示するためのデータを生成する。生成されるＯＳＤデータは、デジタル機器のユーザインターフェース画面、様々なメニュ画面、ウィジェット（widget）、アイコン（icon）、視聴率情報（viewing rate information）などの様々なデータを含む。

ＯＳＤ生成部４２４０は、放送映像の字幕またはＥＰＧに基づく放送情報を表示するためのデータを生成することもできる。

ミキサ４２５０は、ＯＳＤ生成部４２４０で生成されたＯＳＤデータと映像処理部で映像処理された映像信号とをミキシングして、フォーマット４２６０に提供する。復号された映像信号とＯＳＤデータとがミキシングされることによって、放送映像または外部入力映像上にＯＳＤがオーバーレイ（overlay）されて表示される。

フレームレート変換部（ＦＲＣ）４２５５は、入力される映像のフレームレート（frame rate）を変換する。例えば、フレームレート変換部４２５５は、入力される６０Ｈｚ映像のフレームレートをディスプレイ部の出力周波数によって、例えば、１２０Ｈｚまたは２４０Ｈｚのフレームレートを有するように変換できる。上記のように、フレームレートを変換する方法には様々な方法が存在し得る。一例として、フレームレート変換部４２５５は、フレームレートを６０Ｈｚから１２０Ｈｚに変換する場合、第１のフレームと第２のフレームとの間に同一の第１のフレームを挿入するか、第１のフレームおよび第２のフレームから予測された第３のフレームを挿入することによって変換できる。別の例として、フレームレート変換部４２５５は、フレームレートを６０Ｈｚから２４０Ｈｚに変換する場合、既存のフレーム間に同一のフレームまたは予測されたフレームを３つさらに挿入して変換できる。一方、別の（separate）フレームの変換を行わない場合には、フレームレート変換部４２５５をバイパス（bypass）することもできる。

フォーマット４２６０は、入力されるフレームレート変換部４２５５の出力をディスプレイ部の出力フォーマットに合わせて変更する。例えば、フォーマット４２６０は、Ｒ、Ｇ、Ｂデータ信号を出力することができ、このようなＲ、Ｇ、Ｂデータ信号は、低い電圧差分信号（Low Voltage Differential Signaling、ＬＶＤＳ）またはｍｉｎｉ－ＬＶＤＳで出力されることができる。また、フォーマット４２６０は、入力されるフレームレート変換部４２５５の出力が３Ｄ映像信号である場合には、ディスプレイ部の出力フォーマットに合わせて３Ｄの形態で構成して出力することによって、ディスプレイ部を介して３Ｄサービスをサポートすることもできる。

一方、制御部内の音声処理部（図示せず）は、逆多重化された音声信号の音声処理を行うことができる。このような音声処理部（図示せず）は、様々なオーディオフォーマットを処理するようにサポートすることができる。一例として、音声信号がＭＰＥＧ－２、ＭＰＥＧ－４、ＡＡＣ、ＨＥ－ＡＡＣ、ＡＣ－３、ＢＳＡＣなどのフォーマットで符号化された場合にも、これに対応するデコーダを備えて処理できる。

また、制御部内の音声処理部（図示せず）は、ベース（base）、トレブル（treble）、音量調節などを処理することができる。

制御部内のデータ処理部（図示せず）は、逆多重化されたデータ信号のデータ処理を行うことができる。例えば、データ処理部は、逆多重化されたデータ信号が符号化された場合にも、これを復号することができる。ここで、符号化されたデータ信号としては、各チャンネルで放映される放送プログラムの開始時刻、終了時刻などの放送情報が含まれるＥＰＧ情報であり得る。

一方、前述したデジタル機器は、本明細書による例であって、各構成要素は、実際に実現されるデジタル機器の仕様によって、統合、追加、または省略され得る。すなわち、必要に応じて、２以上の構成要素が１つの構成要素に合わせられるか、１つの構成要素が２以上の構成要素に細分化され得る。また、各ブロックで行う機能は、本明細書の実施例を説明するためのものであり、その具体的な動作や装置は、本明細書の権利範囲を制限しない。

一方、デジタル機器は、装置内に記憶された映像または入力される映像の信号処理を行う映像信号処理装置であり得る。映像信号処理装置の別の例としては、図４１に示しているディスプレイ部４１８０およびオーディオ出力部４１８５が除外されたセットトップボックス（ＳＴＢ）、前述したＤＶＤプレーヤ、ブルーレイプレーヤ、ゲーム機器、コンピュータなどがさらに例示され得る。

図４３は、一実施例にかかるデジタル機器のスクリーンがメイン映像（main image）と補助映像（sub image）とを同時に表示する一例を示す図である。

一実施例にかかるデジタル機器は、スクリーン４３００にメイン映像４３１０と補助映像４３２０とを同時に表示できる。メイン映像４３１０は、第１の映像と呼ばれ、補助映像４３２０は、第２の映像と呼ばれる。メイン映像４３１０および補助映像４３２０は、動画、スチルイメージ、ＥＰＧ（Electronic Program Guide）、ＧＵＩ（Graphical User Interface）、ＯＳＤ（On-Screen Display）などを含み得、これに限定されない。メイン映像４３１０は、電子装置のスクリーン４３００に補助映像４３２０と同時に表示されながら、電子装置のスクリーン４３００より大きさが相対的に小さい映像を意味し得、ＰＩＰ（Picture In Picture）と称することもある。図４３では、メイン映像４３１０がデジタル機器のスクリーン４３００の左側上段に表示されるものとして示されているが、メイン映像４３１０が表示される位置は、これに限定されず、メイン映像４３１０は、デジタル機器のスクリーン４３００内の任意の位置で表示され得る。

メイン映像４３１０および補助映像４３２０は、相互直接または間接的に関連し得る。一例として、メイン映像４３１０は、ストリーミング（streaming）動画であり、補助映像４３２０は、ストリーミング動画と類似する情報を含む動画のサムネイル（thumbnail）を順次表示するＧＵＩであり得る。別の例として、メイン映像４３１０は、放送映像（broadcasted image）であり、補助映像４３２０は、ＥＰＧであり得る。さらに他の例として、メイン映像４３１０は、放送映像であり、補助映像４３２０は、ＧＵＩであり得る。メイン映像４３１０および補助映像４３２０の例は、これに限定されない。

一実施例において、メイン映像４３１０は、放送チャンネル（broadcasting channel）を介して受信した放送映像（broadcasting image）であり、補助映像４３２０は、放送チャンネルを介して受信した放送映像に関する情報であり得る。放送チャンネルを介して受信した放送映像に関する情報は、例えば、総合チャンネル編成表、放送プログラムの詳細情報などを含むＥＰＧ情報、放送プログラムの再放送情報などを含み得、これに限定されない。

別の一実施例において、メイン映像４３１０は、放送チャンネルを介して受信した放送映像であり、補助映像４３２０は、デジタル機器に既に記憶された情報に基づいて生成された映像であり得る。デジタル機器に既に記憶された情報に基づいて生成された映像は、例えば、ＥＰＧの基本ＵＩ（User Interface）、基本チャンネル情報、映像解像度（resolution）の操作ＵＩ、就寝予約ＵＩなどを含み得、これに限定されない。

さらに他の一実施例において、メイン映像４３１０は、放送チャンネルを介して受信した放送映像であり、補助映像４３２０は、ネットワーク網を介して受信した放送映像に関する情報であり得る。ネットワーク網を介して受信した放送映像に関する情報は、例えば、ネットワークに基づく検索エンジンを介して獲得された情報であり得る。より具体的に例を挙げると、ネットワークに基づく検索エンジンを介して、現在のメイン映像４３１０に表示されている登場人物に関する情報が獲得され得る。

しかしながら、例はこれに限定されず、ネットワーク網を介して受信した放送映像に関する情報は、例えば、人工知能（Artificial Intelligence、ＡＩ）システムを使用することによって獲得され得る。より具体的に例を挙げると、ネットワークに基づくディープラーニング（deep-learning）を用いて、現在のメイン映像４３１０に表示されている場所の地図上推定位置（estimated-location in map）が獲得され得、デジタル機器は、ネットワーク網を介して、現在のメイン映像４３１０に表示されている場所の地図上推定位置に関する情報を受信することができる。

一実施例にかかるデジタル機器は、外部からメイン映像４３１０の映像情報および補助映像４３２０の映像情報の少なくとも１つを受信することができる。メイン映像４３１０の映像情報は、例えば、放送チャンネル（broadcasting channel）を介して受信した放送信号（broadcasting signal）、メイン映像４３１０のソースコード（source code）情報、ネットワーク網を介して受信したメイン映像４３１０のＩＰパケット（internet protocol packet）情報などを含み得、これに限定されない。同様に、補助映像４３２０の映像情報は、例えば、放送チャンネルを介して受信した放送信号、補助映像４３２０のソースコード情報、ネットワーク網を介して受信した補助映像４３２０のＩＰパケット情報などを含み得、これに限定されない。デジタル機器は、外部から受信したメイン映像４３１０の映像情報または補助映像４３２０の映像情報をデコードして用いることができる。ただし、場合によって、デジタル機器は、メイン映像４３１０の映像情報または補助映像４３２０の映像情報を内部に自主的に記憶していることもある。

デジタル機器は、メイン映像４３１０の映像情報および補助映像４３２０に関する情報に基づいて、メイン映像４３１０および補助映像４３２０をデジタル機器のスクリーン４３００に表示できる。

一例で、デジタル機器のデコード装置２００は、メイン映像のデコード装置および補助映像のデコード装置を含み、メイン映像のデコード装置および補助映像のデコード装置は、それぞれメイン映像４３１０の映像情報および補助映像４３２０の映像情報をデコードすることができる。レンダラは、メイン映像のレンダラ（第１のレンダラ）および補助映像のレンダラ（第２のレンダラ）を含み、メイン映像のレンダラは、メイン映像のデコード装置でデコードされた情報に基づいて、メイン映像４３１０をデジタル機器のスクリーン４３００の第１の領域に表示されるようにすることができ、補助映像のレンダラは、補助映像のデコード装置でデコードされた情報に基づいて、補助映像４３２０をデジタル機器のスクリーン４３００の第２の領域に表示されるようにすることができる。

さらに他の例で、デジタル機器のデコード装置２００は、メイン映像４３１０の映像情報および補助映像４３２０の映像情報をデコードすることができる。デコード装置２００でデコードされた情報に基づいて、レンダラは、メイン映像４３１０および補助映像４３２０を共に処理して、同時にデジタル機器のスクリーン４３００に表示されるようにすることができる。

すなわち、本文書によると、デジタル機器で映像サービス処理方法を提供することができる。上記映像サービス処理方法によると、映像情報を受信する段階と、上記映像情報に基づいて（メイン）映像をデコードする段階と、デコードされた映像をディスプレイ内の第１の領域にレンダリングまたは表示する段階と、ディスプレイ内の第２の領域に補助映像をレンダリングまたは表示する段階と、を含み得る。この場合、第１の映像をデコードする段階は、前述した図３によるデコード装置２００におけるデコーディング手続に従うことができる。例えば、前述したように、第１の映像をデコードする段階は、インターまたはイントラ予測に基づいて現ブロックに対する予測サンプルを導出する段階と、受信した残差情報に基づいて現ブロックに対する残差サンプルを導出する段階（省略可能）と、予測サンプルおよび／または残差サンプルに基づいて復元サンプルを生成する段階と、を含み得る。さらに、第１の映像をデコードする段階は、復元サンプルを含む復元ピクチャにインループフィルタリング手続を行うことを含むこともできる。

例えば、上記補助映像は、ＥＰＧ（Electronic Program Guide）、ＯＳＤ（On Screen Display）、またはＧＵＩ（Graphic User Interface）であってもよい。例えば、上記映像情報は、放送網（broadcast network）を介して受信され、上記補助映像に関する情報は、上記放送網を介して受信されることができる。例えば、上記映像情報は、通信網（communication network）を介して受信され、上記補助映像に関する情報は、上記通信網を介して受信されることができる。例えば、上記映像情報は、放送網を介して受信され、上記補助映像に関する情報は、通信網を介して受信されることができる。例えば、上記映像情報は、放送網または通信網を介して受信され、上記補助映像に関する情報は、上記デジタル機器内の記憶媒体に記憶されていてもよい。

以上で説明された実施例は、本発明の構成要素および特徴が所定の形態で結合されたものである。各構成要素または特徴は、別途の明示的言及がない限り、選択的なものと考慮されるべきである。各構成要素または特徴は、他の構成要素や特徴と結合されない形態で実施され得る。また、一部の構成要素および／または特徴を結合し、本発明の実施例を構成することも可能である。本発明の実施例で説明される動作の順序は変更され得る。いずれかの実施例の一部の構成や特徴は、他の実施例に含まれてもよく、または他の実施例の対応する構成または特徴と代替され（交替し）得る。特許請求の範囲で明示的な引用関係がない請求項を結合して実施例を構成するか、出願後の補正によって新しい請求項に含め得ることは自明である。

本発明にかかる実施例は、様々な手段、例えば、ハードウェア、ファームウェア（firmware）、ソフトウェアまたはそれらの結合などにより実現され得る。ハードウェアによる実現の場合、本発明の一実施例は、１つまたは複数のＡＳＩＣｓ（Application Specific Integrated Circuits）、ＤＳＰｓ（Digital Signal Processors）、ＤＳＰＤｓ（Digital Signal Processing Devices）、ＰＬＤｓ（Programmable Logic Devices）、ＦＰＧＡｓ（Field Programmable Gate Arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現され得る。

ファームウェアやソフトウェアによる実現の場合、本明細書の一実施例は、以上で説明された機能または動作を行うモジュール、手続、関数などの形態で実現され得る。ソフトウェアコードは、メモリに記憶され、プロセッサによって駆動され得る。上記メモリは、上記プロセッサの内部または外部に位置し、既に公知となった多様な手段により上記プロセッサとデータをやり取りすることができる。

本発明は、本発明の必須的特徴を外れない範囲で、他の特定の形態で具体化できることは当業者にとって自明である。したがって、前述した詳細な説明は、全ての面で制限的に解釈されてはならず、例示的なものと考慮されるべきである。本発明の範囲は、添付された請求項の合理的解釈によって決定されなければならず、本発明の等価的範囲内における全ての変更は、本発明の範囲に含まれる。

以上、前述した本発明の好ましい実施例は、例示の目的のために開示されたものであって、当業者であれば、以下添付される特許請求の範囲に開示された本発明の技術的思想およびその技術的範囲内で、多様な他の実施例を改良、変更、代替または付加などが可能である。

Claims (16)

1. 画像デコード装置によって行われる画像デコード方法であって、
   現ブロックの空間的（spatial）隣接ブロックおよび時間的（temporal）隣接ブロックに基づいて、マージ候補リスト（merge candidate list）を構成する段階と、
   前記現ブロックの履歴ベース動きベクトル予測子（History-based Motion Vector Predictor；ＨＭＶＰ）候補を前記マージ候補リストに追加する段階であって、前記ＨＭＶＰ候補は、前記現ブロックのＨＭＶＰ候補を記憶するＨＭＶＰ候補リストに有される段階と、
   前記マージ候補リスト内のマージ候補の動き情報に基づいて、前記現ブロックの予測サンプルを生成する段階であって、前記マージ候補は、マージインデックスによって特定される段階と、を有し、
   前記ＨＭＶＰ候補リストは、前記マージ候補の前記動き情報に基づいて更新され、
   前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補の動き情報と前記マージ候補リスト内の予め決められた空間的マージ候補の動き情報とを比較した結果に基づいて、前記マージ候補リストに追加され、
   前記予め決められた空間的マージ候補は、前記現ブロックの左側隣接空間マージ候補および上側隣接空間マージ候補の少なくとも１つを有する、方法。
2. 前記ＨＭＶＰ候補リストの最大の大きさは、前記マージ候補リストの最大の大きさより小さい、請求項１に記載の方法。
3. 前記ＨＭＶＰ候補リストの最大の大きさは、前記マージ候補リストの最大の大きさより１だけ小さい、請求項２に記載の方法。
4. 前記マージ候補リストの最大の大きさは、６として定義され、前記ＨＭＶＰ候補リストの最大の大きさは、５として定義される、請求項２に記載の方法。
5. 前記マージ候補リストの最大の大きさは、前記マージ候補リストの利用可能な最大の大きさのうちの最大の大きさである、請求項２に記載の方法。
6. 前記ＨＭＶＰ候補は、前記マージ候補リストに最後の候補として追加されない、請求項１に記載の方法。
7. 前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補リスト内で予め決められた数の候補から導出される、請求項１に記載の方法。
8. メモリと、
   少なくとも1つのプロセッサと、を有する画像デコード装置であって、
   前記少なくとも1つのプロセッサは、
   現ブロックの空間的（spatial）隣接ブロックおよび時間的（temporal）隣接ブロックに基づいて、マージ候補リスト（merge candidate list）を構成し、
   前記現ブロックの履歴ベース動きベクトル予測子（History-based Motion Vector Predictor；ＨＭＶＰ）候補を前記マージ候補リストに追加し、前記ＨＭＶＰ候補は、前記現ブロックのＨＭＶＰ候補を記憶するＨＭＶＰ候補リストに有され、
   前記マージ候補リスト内のマージ候補の動き情報に基づいて前記現ブロックの予測サンプルを生成し、前記マージ候補は、マージインデックスによって特定される、ように構成され、
   前記ＨＭＶＰ候補リストは、前記マージ候補の前記動き情報に基づいて更新され、
   前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補の動き情報と前記マージ候補リスト内の予め決められた空間的マージ候補の動き情報とを比較した結果に基づいて、前記マージ候補リストに追加され、
   前記予め決められた空間的マージ候補は、前記現ブロックの左側隣接空間マージ候補および上側隣接空間マージ候補の少なくとも１つを有する、装置。
9. 画像エンコード装置によって行われる画像エンコード方法であって、
   現ブロックの空間的（spatial）隣接ブロックおよび時間的（temporal）隣接ブロックに基づいて、マージ候補リスト（merge candidate list）を構成する段階と、
   前記現ブロックの履歴ベース動きベクトル予測子（History-based Motion Vector Predictor；ＨＭＶＰ）候補を前記マージ候補リストに追加する段階であって、前記ＨＭＶＰ候補は、前記現ブロックのＨＭＶＰ候補を記憶するＨＭＶＰ候補リストに有される段階と、
   前記マージ候補リスト内のマージ候補の動き情報に基づいて、前記現ブロックの予測サンプルを生成する段階と、
   前記予測サンプルを生成するのに使用されるマージ候補を特定するマージインデックスをビットストリームにエンコードする段階と、を有し、
   前記ＨＭＶＰ候補リストは、前記マージ候補の前記動き情報に基づいて更新され、
   前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補の動き情報と前記マージ候補リスト内の予め決められた空間的マージ候補の動き情報とを比較した結果に基づいて、前記マージ候補リストに追加され、
   前記予め決められた空間的マージ候補は、前記現ブロックの左側隣接空間マージ候補および上側隣接空間マージ候補の少なくとも１つを有する、方法。
10. 前記ＨＭＶＰ候補リストの最大の大きさは、前記マージ候補リストの最大の大きさより小さい、請求項９に記載の方法。
11. 前記ＨＭＶＰ候補リストの最大の大きさは、前記マージ候補リストの最大の大きさより１だけ小さい、請求項１０に記載の方法。
12. 前記マージ候補リストの最大の大きさは、６として定義され、前記ＨＭＶＰ候補リストの最大の大きさは、５として定義される、請求項１０に記載の方法。
13. 前記マージ候補リストの最大の大きさは、前記マージ候補リストの利用可能な最大の大きさのうちの最大の大きさである、請求項１０に記載の方法。
14. 前記ＨＭＶＰ候補は、前記マージ候補リストに最後の候補として追加されない、請求項９に記載の方法。
15. 前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補リスト内で予め決められた数の候補から導出される、請求項９に記載の方法。
16. 画像エンコード方法によってビットストリームを送信する方法であって、前記画像エンコード方法は、
    現ブロックの空間的（spatial）隣接ブロックおよび時間的（temporal）隣接ブロックに基づいて、マージ候補リスト（merge candidate list）を構成する段階と、
    前記現ブロックの履歴ベース動きベクトル予測子（History-based Motion Vector Predictor；ＨＭＶＰ）候補を前記マージ候補リストに追加する段階であって、前記ＨＭＶＰ候補は、前記現ブロックのＨＭＶＰ候補を記憶するＨＭＶＰ候補リストに有される段階と、
    前記マージ候補リスト内のマージ候補の動き情報に基づいて、前記現ブロックの予測サンプルを生成する段階と、
    前記予測サンプルを生成するのに使用されるマージ候補を特定するマージインデックスをビットストリームにエンコードする段階と、を有し、
    前記ＨＭＶＰ候補リストは、前記マージ候補の前記動き情報に基づいて更新され、
    前記ＨＭＶＰ候補は、前記ＨＭＶＰ候補の動き情報と前記マージ候補リスト内の予め決められた空間的マージ候補の動き情報とを比較した結果に基づいて、前記マージ候補リストに追加され、
    前記予め決められた空間的マージ候補は、前記現ブロックの左側隣接空間マージ候補および上側隣接空間マージ候補の少なくとも１つを有する、方法。

Images