JP5996728B2 - 動きベクトル候補セットを生成する方法 - Google Patents

Description

本件と相互参照する関連出願は無い。

本発明は、動きベクトル候補セットを生成する方法に関する。

近年の映像伝送表示システム、特に高解像度コンテンツ対応の映像伝送表示システムは、視覚上許容できる動画を映し出すために大幅なデータ圧縮を行うことを必要とする。なぜならば、映像フレームの非圧縮シーケンスを伝送する場合、伝送媒体は、表示映像を連続動画として人間の目に視覚させるのに十分高速な速度で伝送できないからである。同時に、視覚上許容できる動画を映し出すためには、使用する圧縮技術によってフレームデータを過剰に破棄することで画質を過度に犠牲にすべきではない。

二つの相反する目標を遂げるために、ＭＰＥＧおよびＨ.２６４などの映像圧縮符号化規格では、映像フレームシーケンスの時間冗長性が利用される。換言すれば、人間の興味を引く映像シーケンスの大部分では、隣接するフレームが同一の対象や特徴を示すことが多い。そして、これら同一の対象や特徴は、撮影シーン内の当該対象の移動（これに起因して、フレーム内の局所的移動が発生する）、シーン撮影カメラの移動（これに起因して、全体の移動が発生する）、または、その両方によって、フレーム毎に僅かに移動する。

映像圧縮規格は動き予測を利用して、画像内の領域（対象に対応させてもよい）を定義し、当該領域に各領域のコンテンツのフレーム間動きを示す動きベクトルを関連付ける。これにより、連続するフレームの間で出現位置が僅かに異なっているだけなのに、連続する２つ以上のフレームに出現する対象またはパターンの冗長な符号化伝送を避けている。動きベクトルは、移動モデル（translational model）または回転、移動、拡大などの実際の映像カメラの動きを近似する他の多くのモデルによって表すことができる。したがって、動き予測とは、連続するフレーム内において同様の情報の符号化を繰り返し行う代わりに、動きベクトルを計算し、符号化する処理である。

動きベクトルは、画像全体に関することもあるが、大抵の場合、画像内の小さな領域に関する。当該画像内の小さな領域としては、矩形ブロック、任意の形状、対象の境界、または、個々の画素なども挙げられる。動きベクトルを検出するために、様々な検出方法が存在する。よく知られている方法の１つにブロックマッチング法がある。ブロックマッチング法では、現画像を矩形の画素ブロック（４×４画素、４×８画素、８×８画素、１６×１６画素など）に分割し、上記画素ブロックに最も適合する参照画像の画素ブロックを後続フレームの所定検索領域から検索して、各画素ブロックの動きベクトル（または変移ベクトル）を予測する。

上述の説明から示唆されるように、動きベクトルの使用により、ブロックを、他のフレーム内の対応ブロックを示す動きベクトルと、対象ブロックおよび参照ブロック間の“残差”または差分とについてのみ符号化することを可能にして、画像内の特定ブロックの符号化効率を向上させている。したがって、符号化が行われる必要のある差分が最小になるように、ブロックの動きベクトルを決定することが目標となる。よって、ブロックのマッチングについては、ブロックのサイズおよび配置の規定、検索方法、現フレームおよび参照フレームのブロック間のマッチング基準、または他の幾つかの側面において異なる、数多くのバリエーションが存在する。

従来の動き補償では、エンコーダが動き予測を行い、動きベクトルをビットストリームの一部として信号で送信する。動きベクトルの伝送に費やされるビットによって、ビット予算全体のかなりの部分が占められてしまうことがあり、特に低ビットレートの適用する場合、こうした現象が認められる。近年、圧縮ビットストリームにおける動き情報量を減少させるために、動きベクトル競合（ＭＶＣ：Motion Vector Competition）技術が提案されてきた。ＭＶＣでは、動きベクトル自体を予測動きベクトル（motion vector predictor）と差分動きベクトルに関して差分符号化することで、動きベクトルデータの符号化を向上させている。予測動きベクトルは、通常、レート歪みを最適化するように多数の候補からエンコーダによって選択され、動きベクトル候補は、同一フレーム内の隣接ブロックの既に符号化された動きベクトル、および／または、先行フレーム内の動きベクトルのサブセットから構成される。換言すれば、動きベクトルおよび差分の使用により、連続するフレーム間の情報の冗長性を除去してブロックデータの符号化効率を向上させると同時に、動きベクトルの符号化では、既に符号化された候補の限定セットから最適な予測を特定することで、連続するフレーム間で動きベクトルが大きく変わらない状況で冗長性を利用することができ、当該差分のビット長を最小化することができる。予測セットは、通常、空間的隣接動きベクトル（spatial motion vector neighbors）と時間的コロケート動きベクトル（temporally co-located motion vectors）との両方を含み、時空間ベクトル（spatiotemporal vectors）を含むことも可能である。

しかし、映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートは、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎてしまうことが多い。そのため、映像伝送の符号化システムの改善が必要とされている。

本発明の上述および他の課題、特徴、および、優れた点は、以下に示す発明の詳細な説明を添付図面と併せて考察することによって、より容易に理解されるであろう。

Frank Bossen, Philipp Kosse, "Simplified motion vector coding method", Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 2nd Meeting: Geneva, CH, 21-28 July, 2010, [JCTVC-B094]

映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートは、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎてしまうことが多い。そのため、映像伝送の符号化システムの改善が必要とされている。

好ましい実施形態は、予測動きベクトルの候補から構成される動きベクトル候補セットを生成する方法であって、第１の動きベクトルと第２の動きベクトルから構成される上記動きベクトル候補セットを生成する工程を備え、上記第１の動きベクトルは、現フレームの対象ブロックに隣接する隣接ブロックの動きベクトルであり、上記第２の動きベクトルは、上記現フレームよりも先行する先行フレーム内の第１のブロックのコロケート動きベクトルであり、上記第１のブロックは、最小サイズブロックのブロックサイズよりも大きい。
別の好ましい実施形態は、動きベクトル候補セットに含まれる動きベクトルをトリミングするトリミング方法であって、上記動きベクトル候補セットにおいて、重複する動きベクトルを特定する特定工程と、上記動きベクトル候補セットから、上記特定工程で特定された上記重複する動きベクトルを削除する削除工程と、その後、上記動きベクトル候補セットから得た上記動きベクトルをトリミングするトリミング工程とを含むことを特徴とするトリミング方法である。

別の好ましい実施形態は、受信した符号化されたデータの復号を行う復号システムであって、上記データのシンタックス要素に一連の第１シンボルを結び付けるシンタックスモデラーと、各第１シンボル内にそれぞれネスト化され、一連の第２シンボルの各第２シンボルを符号化データに結び付けるためにそれぞれ使用される複数のテーブルを記憶する少なくとも１つのバッファと、上記複数のテーブルの１つから取り出される、上記一連の第２シンボルから選択された１つの第２シンボルを使用して、上記データを、上記一連の第１シンボルの何れも含まないビットストリームに復号するデコーダとを備えることを特徴とする復号システムである。

さらに別の好ましい実施形態は、データの復号を行う復号方法であって、映像ブロックの復号に使用する動きベクトル候補セットであって、データ内に符号化された１つの動きベクトルを含む動きベクトル候補セットを受信する工程と、上記１つの動きベクトルを、上記動きベクトル候補セット内のサブセットに属している動きベクトルとして特徴付けるフラグの値を受信する工程と、上記値を使用して、上記動きベクトル候補セットをトリミングする工程と、上記動きベクトル候補セットに残存する動きベクトルの数に基づいて、上記１つの動きベクトルを上記動きベクトル候補から特定する工程とを含むことを特徴とする復号方法である。

映像伝送の符号化システムの改善することにより、映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートが、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎないようにする。

動きベクトル競合を概略して示す。 動きベクトル競合を概略して示す。 動きベクトルの符号化復号システムの例を示す。 ネスト型エントロピー符号化構造を示す。 図３に示すネスト型エントロピー符号化構造を利用するシステムを示す。 動きベクトル候補セットをトリミングすることが可能なエンコーダの例を示す。 図５のエンコーダが使用する、動きベクトル候補セットのトリミング方法の例を示す。 動きベクトル候補セットにおける、時間的コロケート動きベクトル（temporally co-located motion vector）を符号化する、別の実施形態を概略して示す。

図１Ａおよび１Ｂを参照すると、現フレーム（Ｔ＝０）内の候補ブロック（斜線で図示）の動きベクトルは、後続フレーム（Ｔ＝１）内の斜線で図示したブロックを指し示している。上記動きベクトルは、動きベクトルＶ_ａ、Ｖ_ｘ、Ｖ_ｙ、および、Ｖ_ｚからなる候補セットを参照して符号化してもよい。この例では、動きベクトルＶ_ａは、先行フレーム（Ｔ＝−１）におけるコロケート動きベクトル（co-located motion vector）であり、現フレームにおけるブロックＡを指し示している。動きベクトルＶ_ｘ、Ｖ_ｙ、および、Ｖ_ｚは、現フレームにおいては、予め符号化された動きベクトルであり、後続フレーム（Ｔ＝１）におけるブロックＸ、Ｙ、Ｚをそれぞれ指し示している。図１Ａは更にブロックＡ’、Ｘ’、Ｙ’、および、Ｚ’を示している。これらブロックは、上記動きベクトルを候補ブロックの符号化時に使用した場合、それぞれの動きベクトルによって指し示されるブロックである。

図１Ｂに示すように、動きベクトル競合（ＭＶＣ）方法を使用すると、差分Ｖ_ｄの符号長を最小化するように動きベクトルＶ_ｚが選択される。この場合、上記ベクトルの単一成分（下方）の値として“１”しか必要ではない。他の差分動きベクトルはすべて、２つの成分を符号化する必要があるか、または、単一成分に対してより大きな値が必要である。

上述の説明は簡略化したものである。したがって、異なるサイズのブロックを使用したり、各ブロックが単一画素を表してもよく、また、更に多くの動きベクトルを候補セットに含めることも可能である。例えば、現フレーム内の予め算出された全動きベクトルを候補セットに含めることが可能であり、同様に、先行フレーム内の算出されたいかなる動きベクトルについても候補セットに含めることができる。更に、候補セットは、シーン内の大きな動きおよび急激な動きを捕えるために有用である、任意の動きベクトルを所望の数だけ含んでいてもよい。

図２を参照して上述の例を引き続き説明する。選択した動きベクトルＶ_ｚを符号化することが必要になる。直接的なアプローチとしては、エンコーダ１０が、シンボルのテーブル１４における各動きベクトル候補に値を割り当てる。これは、ハフマン（Ｈｕｆｆｍａｎ）符号化法または算術符号化法などの可変長エントロピー符号化方法を前提としたものであり、以下のような形態を採る：
動きベクトル候補 シンボル
Ｖ_ａ ０
Ｖ_ｘ １０
Ｖ_ｙ １１０
Ｖ_ｚ １１１０
なお、上記シンボルの何れも他のシンボルの前置（prefix）ではない。よってこの例では、デコーダ１２は、受信ビットストリーム内の“０”を受信した時点で中断することで当該受信ビットストリームを正確に解析し、対応するテーブル１６を参照して当該受信ビットストリームを復号することができる。更に、エンコーダおよびデコーダは、好ましくは、ビットストリームの符号化および復号が行われている間に統計を収集して、テーブル１４およびテーブル１６の各々において、動きベクトル候補へのシンボルの割り当てを再編成し、例えば、常に、最も頻度の高い動きベクトルに最も短いシンボルが割り当てられるようにする。この処理法は、一般的にエントロピー符号化と称され、通常、ビットストリームの飛躍的な可逆圧縮をもたらす。エンコーダ１０およびデコーダ１２は同一の手法を使用して、ビットストリームの開始時点で初期化されるテーブル１４およびテーブル１６を、それぞれ構築およびアップデートする。これにより、全てのシンボルに関して、シンボル符号化に使用されるテーブル１６とシンボル復号に使用されるテーブルとが、同一のテーブルになる。

エントロピー符号化を行ったとしても、図２に示すシステムでは、動きベクトル候補のセットからどの予測が選択されるかを示す信号を伝送する場合、深刻なオーバーヘッドが発生することがある。これは、予測の数が多い場合に特に起こりやすい。一方で、より多くの予測を使用するほど、差分動きベクトルの符号化効率を高めることができる。どの予測が選択されるか示す信号を送信する場合に発生するオーバーヘッドを更に低減させるために、更なる技術を採用してもよい。

第一に、予測動きベクトル候補のセットにトリミングを行い、重複したベクトルを削除してもよい。２つの動きベクトル間において水平方向の値と、垂直方向の値と、参照インデクスとが等しい場合、当該２つの動きベクトルは重複したベクトルである。用語“重複したベクトル”は、“重複した動きベクトル”、“同一のベクトル”、または、“同一の動きベクトル”と均等な意味を有する用語である。例えば、図１Ａでは、ベクトルＶ_ｘ、Ｖ_ｙは同一のベクトルであるため、これら動きベクトルのうち一方にトリミングを行うことができる。この結果、テーブルにおける最大のシンボルである“１１１０”を削除することができる。第二に、トリミングが行われた予測動きベクトルセットのサイズを知ることは、当該予測動きベクトルセットのうち最後のシンボルの最後のビットを省略できることを意味する。例えば、上述の例では、Ｖ_ｘ、Ｖ_ｙの一方にトリミングが行われ、その結果“１１０”が最後のシンボルとなっている。このシンボル“１１０”について、ビット配列“１１”がテーブルに格納される他の全ての先行シンボルから区別できる場合、“１１０”を単にビット配列“１１”として符号化してもよく、デコーダは、トリミングされたセットのサイズに基づいて、これ以上シンボルが存在しないと判断する。

これら２つの技術を加えることで、選択された予測動きベクトルを示す信号を送信する場合に発生するオーバーヘッドを大幅に低減するかもしれない。しかし、これらの技術を使用すると、予測動きベクトルのエントロピー復号が、動きの予測セットに左右されることになる。すなわち、動きの予測セットの一式が利用可能になり、且つ、正確に構築されるまで、ビットストリームの正確な解析が行えない。このような制約は、デコーダの誤り耐性に深刻な影響を及ぼし、その結果、２つの不都合を引き起こす。１つ目の不都合は時間依存性である。画像が損傷または損失した場合、後続の画像の復号が、解析段階で失敗してしまうことがある。２つ目の不都合は空間依存性である。画像の特定領域が損傷した場合、当該画像内の後続の領域の復号が、解析段階で失敗してしまうことがある。

このことは、深刻な問題となることがある。すなわち、先行フレームまたは現フレームの動きベクトルデータが損失したにも関わらず、動きベクトルの候補セット一式を再構築することが求められる場合、デコーダは、独立して符号化されたフレームが到達するまでは、ビットストリームの解析を行うことすらできない。このことは、動きベクトル、差分動きベクトル、および、差分の符号化に使用された情報の損失により、単に、解析されたデータを正確に復号できなくなる場合よりも、より深刻な問題となる。なぜならば、後者の場合では、引き続き受信される、上述の損失データに依存しないビットストリーム中のいかなる解析データも復号を行うことが可能であるからである。しかし、デコーダがビットストリームの解析を行えなくなってしまうと、後続のシンボルを復号する方法が絶たれてしまう。

反直観的なことではあるが、誤り耐性とオーバーヘッドとの間のトレードオフは解決不可能な事柄ではない。本発明者らは、符号化効率の向上は、動きベクトルの候補セットから選択される１つを通知することで達成されることと同様に、理論的には、序列化された候補セットの集団から選択される１つを通知することで達成できるということをさらに見出した。この符号化効率の向上は、動きベクトルのトリミングおよびtruncated unary符号との直列使用だけでなく、実際にはこれら技術の代わりとして効果をもたらすことができる。すなわち、重複した動きベクトル候補のトリミングと最長ビット長のシンボルの切り捨ての何れも行わずにビットストリーム解析を行う場合において、空間および時間の非依存性を維持することができる。

具体的には、図３を参照すると、エンコーダまたはデコーダがネスト型エントロピー符号化構造を利用しており、個別のＶＬＣテーブル２０のように複数のエントロピー符号化された動きベクトル候補セットそれぞれに対して、複数の符号化シンボル１８の１つが割り当てられる。なお、ＶＬＣテーブル２０のうち特定の１つが、他のＶＬＣテーブル２０とは異なる動きベクトルセットを含んでもよい。つまり、あるＶＬＣテーブル２０に含まれている特定の動きベクトルが、全てのＶＬＣテーブル２０に含まれている必要はない。エンコーダは、ＶＬＣテーブル２０のうち、通知される動きベクトルが最も高い頻度を持ち、その結果最も短い符号長を持つＶＬＣテーブル２０（候補セット）の１つに対応するシンボル１８の１つを通知してもよい。候補セットをそれぞれ特定する符号化されたシンボル１８自体を、必要に応じて、エントロピー符号化することもでき、または固定長符号や、他の任意の符号化技術によって符号化してもよい。

上述の説明の潜在的な前提として、全ての可能な動きベクトル候補セットの複数には、ある非ランダム分布が存在するということがある。例えば、個々の候補セットそれぞれが、互いにランダムの分布した、シンボルの順列すべてを含んでいるならば、符号化効率の向上を期待する理由が無くなる。なぜならば、削減された符号長の恩恵を受けるために、テーブルにおいて、候補セット内に十分な数の動きベクトル候補が含まれることを保証するために必要な、動きベクトル候補セットの数が大きくなりすぎてしまうからである。本質的には、動きベクトル候補から選択された１つを符号化する際に得られる効率の向上は、特定の候補セットに結び付けられたシンボルの符号化時に発生するオーバーヘッドで失われる。これは、以下のことからも理解できる。動きベクトルのエントロピー符号化が、動きベクトル間の予測可能な空間関係および時間関係によって機能し、一部の動きベクトル候補の出現頻度を他の動きベクトル候補よりも高くすることと同じように、本開示のネスト型エントロピー符号化構造は、候補セット中のシンボルの可能な順列のうちいくつかの出現頻度が他よりも高くなる場合にのみ、更なるビットストリームの圧縮を行って、符号長の長い候補セットが、符号長の短い候補セットほど頻繁には使用されなくなるようにすることを目的とする。

研究の結果、本発明者らは、本開示のネスト型エントロピー符号化構造によって符号化効率が実際に向上されるだけでなく、隣接画素または隣接画素ブロックのシンタックス要素が、セット内の動きベクトル候補の序列化の確率と相関していることを見出した。例えば、図４を参照すると、エンコーダ１０が、シンタックスモデル２４からシンタックスシンボルを入手してもよい。シンタックスモデル２４は、動きベクトル候補セットの複数のＶＬＣテーブルを区別するために使用される、符号化データ内のシンタックス要素セットを規定して、これにより、選択された動きベクトル候補を符号シンボルによって符号化する際に使用されるＶＬＣテーブルを決定するために、エンコーダおよびデコーダが使用するシンタックス要素セットも規定する。これらシンタックス要素は、例えば、時間的または空間的に隣接する画素ブロックにおける選択された動きベクトル候補に関するか、このような選択された動きベクトル候補の組み合わせに関するか、または、候補セット内の選択動きベクトルの確率分布との関連性を有するように決定された任意の要素に関することができる。一実施形態において、エンコーダ１０（したがって、およびデコーダ１２）は、シンタックス要素の異なる組み合わせを試験して、符号化効率を知的に最大化する、学習因子を備える。別の言い方をすれば、エンコーダ１０は、利用可能なシンタックス要素の異なる組み合わせを反復して選択し、選択した各組み合わせに付随する符号化効率の変化を測定し、且つ、当該各組み合わせ内の１つまたは複数のシンタックス要素を置換することで測定結果に応じた反応を行うことで、符号化効率を知的に最適化する。

シンタックスモデル２４から入手したシンタックスシンボルを使用して、エンコーダ１０はその後、ＶＬＣテーブル２８ａ、２８ｂ、２８ｃ、２８ｄなどに含まれる、現ブロック用に選択された動きベクトルに利用可能な動きベクトルシンボルを使用し、デコーダ１２へ送信するビットストリームにおいて当該動きベクトルシンボルを符号化してもよい。また、エンコーダ１０は、選択されたシンボルに基づいて使用されるＶＬＣテーブルにおける動きベクトルシンボルの序列をアップデートする。一実施形態において、テーブル内に含まれるシンボルの出現頻度分布に変化が起こると、シンボルが再序列化される。別の実施形態において、エンコーダ１０（およびデコーダ１２）が、再序列化が行われる前のセットにおいて最も出現頻度が高かったシンボルの経過を追って、当該シンボルが必ずテーブル内で最上位に序列されるようにする（すなわち、当該シンボルの符号長が必ず最短になるようにする）。なお、この例では、シンタックスシンボルが、既に符号化されたデータのシンタックスのみによって決定されているため、デコーダ１２が同一のシンタックスモデルを使用して、受信動きベクトルシンボルを抽出する特定のＶＬＣテーブル３０ａ、３０ｂ、３０ｃ、３０ｄを決定する限りにおいて、エンコーダが動きベクトルシンボルと共にシンタックスシンボルを符号化する必要は無い。換言すれば、エンコーダ１０が、既に符号化を行ったデータのシンタックスを使用してＶＬＣテーブルを区別し、その過程でこれらＶＬＣテーブル内のシンボルの序列をアップデートしている場合、非常に高い符号化効率を達成することができる。

デコーダ１２がエンコーダ１０から符号化ビットストリームを受信すると、デコーダ１２はビットストリームを解析し、受信したシンボルに適切なＶＬＣテーブルを決定し（シンタックスモデル２６が利用可能な場合にはシンタックスモデル２６を使用して）、当該受信したシンボルを復号して、候補セットから選択された動きベクトルを識別する。また、デコーダは、エンコーダ１０と同じ方法で各ＶＬＣテーブルのアップデートを行う。

予測動きベクトルセットは、選択される動きベクトルを空間的に予測する動きベクトル候補（すなわち、現ブロックと同一フレーム内の候補）と、選択される動きベクトルを時間的に予測する動きベクトル候補（現フレームに先行するフレーム内のコロケートブロックにおける候補）と、選択される動きベクトルを時空的に予測する動きベクトル候補（すなわち、上記コロケートブロックから空間的にオフセットされている、現ブロックに先行するフレーム内の候補）とを含んでいてもよい。先に言及したように、本開示のネスト型エントロピー符号化構造により、デコーダは、動きベクトル候補のトリミングまたは符号シンボルの短縮化を行うことなくビットストリームを解析できるようになり、これにより、解析処理において空間非依存性および時間非依存性を保ち、非常に高い符号化効率を達成しつつ誤り耐性を維持することができる。または、誤り耐性を少なくとも部分的に維持しつつ、ネスト型エントロピー符号化構造を動きベクトル候補のトリミング技術または符号シンボルの削減技術とつなげて使用することができる。

例えば、図５Ａに示すように、エンコーダ１０は、動きベクトル候補セット構築モジュール４０を備えていてもよい。動きベクトル候補セット構築モジュール４０は、１つまたは複数のバッファ２８から、符号化処理中の現ブロックに適用可能な動きベクトル候補の全セットを読み出す。その後、動きベクトル候補セットトリミングモジュール４２は、選択された動きベクトルが符号化モジュール４４によって符号化される前に、シンタックスモデル２４を動きベクトル候補セットに適用することで、所定の規則に従って動きベクトル候補セットを選択的にトリミングする。符号化モジュール４４は、トリミングが行われた候補セットに基づいてシンボルを順に選択する。可能な所定規則の１つによって、例えば、既に再構築／伝送されたフレームから導出された予測動きベクトルに対して、動きベクトル候補セットモジュール４２がトリミングを行うことを防止してもよい。換言すれば、２つの予測動きベクトルが同一の値を有し、一方の予測動きベクトルが現フレームのデータに対応し、他方の予測動きベクトルが他のフレームのデータに対応している場合、これら２つの予測動きベクトルの両方をトリミングが行われたセットに含めるようにする。これにより、時間非依存性が維持される。他の可能な所定の規則によれば、例えば、動きベクトル候補セットモジュール４２が予測動きベクトルを異なる参照インデクスによってトリミングすることを防いでもよい。換言すれば、２つの予測動きベクトルが同一の水平および垂直方向の値を有し、一方の予測動きベクトルの参照インデクスが他方の予測動きベクトルの参照インデクスと異なる場合、これら２つの予測動きベクトルの両方をトリミングが行われたセットに含めるようにする。他の可能な所定の規則によれば、例えば、参照インデクスが同一で水平および／または垂直方向の値が異なる２つの動きベクトルの両方を、トリミングが行われたセットに含めるようにする。更に他の可能な所定の規則によれば、例えば、互いに同一の参照インデクスの値、水平、および、垂直方向の値を有する２つの動きベクトルがセットに存在する場合、一方の動きベクトルが動きベクトル候補セットモジュール４２によって削除される。

別の実施例として、所定の規則を設定することにより、別々のスライスに位置する領域から導出された予測動きベクトルが動きベクトル候補セットトリミングモジュール４２によってトリミングされることを防止し、空間非依存性を保ってもよい。追加の実施形態として、所定の規則を設定することにより、別々のエントロピースライスに位置する領域から導出された予測動きベクトルが動きベクトル候補セットトリミングモジュール４２によってトリミングされることを防止してもよい。エントロピースライスとは、ビットストリームの単位であり、現フレームにおいて他のデータを参照することなく、解析することができる。

上述したこれら２つの規則は、必要ならば追加可能な規則の例として、説明目的のみにおいて記載したものである。図５Ｂには、例として、新規のフラグを使用して伝送される様々なトリミング規則セットを適用するための、一般的な技術が示されている。例えば、ステップ５０において、エンコーダ１０がバッファ２８から予測動きベクトルの候補セットを受け取る。ステップ５２において、決定ステップ５３においてトリミングを適用するかを決定するために使用されるフラグが、エンコーダによって送信される（または、デコーダによってフラグが受信される）。また、どのベクトルをトリミングするかを規定するために使用できるトリミング規則セットを、任意で、同様に送信してもよい。トリミングを行わない、とフラグが示しているならば、ステップ６０の処理に進み、動きベクトル候補セット一式すべてを使用して、選択された動きベクトルを符号化する。しかし、所定の規則セットに従ってトリミングを行う、とフラグが示している場合、ステップ５４において、重複した動きベクトルのサブセットが識別される。このように、１つの実施形態として、重複した動きベクトルのサブセットとは、上記サブセットの動きベクトルそれぞれが、上記サブセット外に同一の動きベクトルを持つような動きベクトルを最大限集めたものとして考えることができる。言い換えれば、該サブセットとは、サブセットから、動きベクトル候補セットにおいて重複した動きベクトルを持たない動きベクトルを除き、かつ、同一の重複した動きベクトルの集合からたった１つだけ削除したものであってもよい。

ステップ５６において、規則セットの所定の規則に従って、選択された動きベクトル候補を重複サブセットから、選択的に削除してもよい。このステップによって、空間非依存性および/または時間非依存性を確保することが可能となる。また、任意で、動きベクトル候補を重複動きベクトルのサブセットに加えることができる。その理由について、以下に、より詳細に説明する。概念的なレベルの話でいえば、ステップ５４とステップ５６を行う目的は単に、規則セットを適用して、候補セット一式の中からトリミングされる動きベクトルを識別することである。このサブセットが識別されると、このサブセットに含まれる動きベクトル候補がステップ５８においてトリミングされ、その後、ステップ６０において、トリミングされた候補セットのサイズに基づいて、残存している動きベクトル候補のうち、選択された動きベクトルをエンコーダが符号化する。

図５Ａに示される一般的な方法の機能性を説明するために、時間ＭＶＰフラグ（temporal_mvp_flag）の例を考察する。時間ＭＶＰフラグは、候補セットから選択された動きベクトルが時間方向に位置する動きベクトルであるかどうかを示す正/誤状態を、ビットストリームにおいて伝送するために、エンコーダによって使用されるフラグである。また、そもそもの前提として、このフラグのために適用可能な規則セットは、時間非依存性を保つことを意図しているものとする。時間予測がエンコーダによって選択されている、と時間ＭＶＰフラグによって示されている場合、候補セットにおける時間予測サブセットはトリミングされない。なぜならば、時間予測サブセットをトリミングすると、時間依存性が生じるからである。しかし、候補セットにおける空間予測サブセットをトリミングすることはできる。この理由は、時間予測サブセットのサイズをデコーダ１２があらかじめ予想しているからである。

反対に、temporal_mvp_flagが、時間予測がエンコーダによって選択されていないことを示す場合、いくつかの実施形態においては、候補セットに対して、重複動きベクトルをトリミングするだけでなく、時間予測もトリミングすることが可能であり、この場合、符号化する必要がある候補セットを大幅に小さくすることができる。さらに認識すべきこととして、もし適用可能な規則セットによって時間依存性および空間依存性が許容されるのならば、temporal_mvp_flagを、その値に関係なく使用して、（１）フラグを使用して伝送される、時間重複サブセットまたは空間重複サブセットをトリミングし、または、（２）フラグを使用して伝送されないサブセット全体をトリミングすることができる。

本発明者らは、偶然にも、本開示のtemporal_mvp_flagの値と、制約付きイントラ予測フラグ（constrained_intra_pred_flag）との間に確かな関連性があることを見出した。constrained_intra_pred_flagは、フレームと関連づけられ、符号化映像ビットストリームにおいて使用されることが多い。具体的には、本発明者らは、これら２つのフラグの間には、constrained_intra_pred_flagの値が１のとき強い関連性が存在し、constrained_intra_pred_flagの値が０のとき、やや弱い関連性が存在することを見出した。したがって、選択された動きベクトルを通知する際のオーバーヘッドを抑えるために、エンコーダを、任意で、以下のような構成にしてもよい。すなわち、現画素のフレームのためにconstrained_intra_pred_flagが１に設定されている場合は、本開示のtemporal_mvp_flagを符号化せずに、デコーダが、temporal_mvp_flagに対して単に等しい値を挿入または仮定するようにして、constrained_intra_pred_flagが１に設定されていない場合は、temporal_mvp_flagを符号化するように構成してもよい。または、本開示のtemporal_mvp_flagに対して、単にconstrained_intra_pred_flagと同じ値を割り振ってもよい。ただし、この場合、規定する規則セットにおいて、０という値を、候補セットにおける重複ベクトルを単にトリミングするという結果に関連付けておくことが好ましい。

このtemporal_mvp_flagシンタックスに対して、本開示のネスト型エントロピー符号化構造を追加で適用することができる。一実施形態として、temporal_mvp_flagのエントロピー符号化において使用される予測セットテンプレートを決定するために、上側隣接フラグと左側隣接フラグが使用される。これは、通常の場合、符号化値に対してエンコーダとデコーダが排他的にエントロピーシンボルを割り振り、かつ、temporal_mvp_flagが多数の値を持つ場合に有効である。別の実施形態としては、現ブロックのtemporal_mvp_flagに応じて、候補セットにおける選択された動きベクトルの符号化に使用される予測セットテンプレートが作成される。

また、別の実施形態として、temporal_mvp_flagについて上述したように、予測動きベクトルが現フレームから導出された動きベクトルと等しい場合、または以前に再構築/送信されたフレームから導出された動きベクトルと等しい場合がある。しかし、この特定の実施形態においては、現フレームから導出された固有の予測動きベクトルの数によってインデクスを付された、フラグが送信される。例えば、本実施形態における予測セットテンプレートは、候補セットにおける固有動きベクトルの数を反映する第２の符号化値によってインデクスを付された、現ブロックから左のブロックおよび上のブロックにおけるフラグの組み合わせを反映する第１の符号化値の（例えば００、０１、１０、１１ （０、１０、１１０、１１１０としてエントロピー符号化される））、可能な組み合わせをすべて区別することができる。または、本実施形態におけるコンテクストテンプレートは、現ブロックから左のブロックおよび上のブロックにおけるフラグが同一であるか（例えば、００と１１（０としてエントロピー符号化される）、と０１と１０（１０としてエントロピー符号化される））を反映する第１の符号化値と、候補セットにおける固有動きベクトルの数を反映する第２の符号化値との、可能なすべての組み合わせを識別することができる。

符号化スキームは、複数のフレームのそれぞれの時間コロケート動きベクトル（例えば、図６に示す動きベクトル）を多数含む動きベクトル候補セットを含んでよい。これが意味するところは、現フレームのブロック６４を符号化するために、エンコーダは、動きベクトル候補が抽出される各先行フレームにおいて選択された全動きベクトルの履歴を含む１つまたは複数のバッファにアクセスする必要がある場合があるということである。このためには、膨大な量のメモリが必要である。代替手段として、符号化スキームで使用される小サイズの画素ブロック（例えば、２×２の画素ブロック）をグループ化して、より大きなブロック６２とし（動きベクトルはバッファに格納され、その後に後続ブロックを符号化する際にコロケート動きベクトルとして使用される）、代わりに各グループにおいて、選択された全ベクトルの平均動きベクトル６６としてもよい。平均化処理は、コロケート動きベクトルが選択されたときはいつでも、符号化される差分が大きくなる傾向があるため、この構成はメモリ要件と引き換えに符号化効率を下げる構成といえる。そうは言っても、候補セットにおける他の動きベクトルを選ぶより、平均コロケートベクトルを使う方が効率的な場合にのみ、平均コロケートベクトルを選択するのであれば、符号化効率の減少はそれほど大きなものではない。隣接ブロックの平均値の使用に加えて、ベクトルのメディアン処理または成分毎のメディアン処理を行ってもよく、他の標準処理、例えば上限値処理、下限値処理、またはそれらを組み合わせた処理、または、いわゆる膨張（dilate）処理、収縮（erode）処理、開放（open）処理、閉鎖（close）処理などを行うこともできる。さらに、所定の位置における動きベクトルを使用してもよい。例えば、上述した後者の使用法において、大ブロックにおけるＮ番目の小サイズ画素ブロックに対応する動きベクトルを、大ブロックのためのコロケート動きベクトルとして、バッファに記録してもよい（Ｎは、大ブロックにおける小サイズブロックのラスター走査順の位置に対応する整数）。

いくつかの実施形態においては、小サイズ画素ブロックをグループ化してよりサイズの大きいブロックとするために使用される処理を、ビットストリームにおいてエンコーダからデコーダへ伝送してもよい。例えば、上記処理をシーケンスパラメータセット（sequence parameter set）において伝送してもよい。または、上記処理をピクチャパラメータセット（picture parameter set）、スライスヘッダー、または、任意の所定画素グループにおいて伝送してもよい。更に、上記処理は、ビットストリームにおいて伝送されるレベルまたはプロファイル識別子から決定することができる。

いくつかの実施形態においては、グループ化されてより大きなブロックになった小サイズブロックの数をビットストリームにおいてエンコーダからデコーダに伝送してもよい。例えば、上記小サイズブロックの数をシーケンスパラメータセットにおいて伝送してもよい。または、上記小サイズブロックの数をピクチャパラメータセット、スライスヘッダー、または、任意の所定画素グループにおいて伝送してもよい。上記小サイズブロックの数は、ビットストリームにおいて伝送されるレベルまたはプロファイル識別子から決定してもよい。いくつかの実施形態においては、上記小サイズブロックの数を小サイズブロックの行数および列数として表してもよい。

なお、エンコーダおよび／またはデコーダの上述の実施形態は、数多くのハードウェア、ファームウェア、または、ソフトウェア、いずれの実施においても使用可能であることを理解されたい。例えば、エンコーダは、セットトップ型記録器、サーバ、デスクトップ型コンピュータなどに使用されてもよく、デコーダは、表示装置、セットトップ型ケーブルボックス、セットトップ型記録器、サーバ、デスクトップ型コンピュータなどにおいて使用されてもよい。これらの例は例示に過ぎず、限定するものではない。本開示のエンコーダおよびデコーダをファームウェアおよび／またはソフトウェアにおいて実行する場合、本開示エンコーダおよびデコーダの様々な構成要素は、利用可能な任意の処理装置および記憶体にアクセスして上述の技術を実施してもよい。

上述の明細書で使用した用語および表現は、本発明を説明するための用語および表現であり、本発明を限定するものではない。したがって、このような用語および表現の使用により、上で図示および説明を行った特徴またはその一部の均等物を除外するものとして意図されるものではない。そして、発明の範囲は以下の請求項のみによって規定され、且つ、限定されることを認識されたい。

Claims (1)

1. 連続する複数の画像のうちのある画像中の対象ブロックの予測動きベクトルを復号する復号方法であって、
   上記ある画像内の上記対象ブロックに隣接する第１の隣接ブロックを識別する第１の識別工程と、
   上記ある画像内の上記対象ブロックに隣接する第２の隣接ブロックを識別する第２の識別工程と、
   上記第１の隣接ブロックの動きベクトルと上記第２の隣接ブロックの動きベクトルとが等しくない場合に、上記第１の隣接ブロックおよび上記第２の隣接ブロックの両方の上記動きベクトルを含んでいる予測動きベクトル候補セットを生成する第１の生成工程と、
   上記第１の隣接ブロックの動きベクトルと上記第２の隣接ブロックの動きベクトルとが等しい場合に、上記第１の隣接ブロック又は上記第２の隣接ブロックのただ１つの動きベクトルを含んでいる予測動きベクトル候補セットを生成する第２の生成工程と、
   時間方向に位置する動きベクトルを予測動きベクトルとして使用できるかどうかを示すフラグをビットストリームから得る工程と、
   時間方向に位置する動きベクトルを予測動きベクトルとして使用できることを上記フラグが示す場合に、別の画像中のあるブロックの動きベクトルを上記予測動きベクトル候補セットに含める工程と、
   時間方向に位置する動きベクトルを予測動きベクトルとして使用できないことを上記フラグが示す場合に、上記予測動きベクトル候補セットに含まれる、別の画像中のあるブロックの動きベクトルを除外する除外工程と、
   上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する選択工程と、を含んでいる復号方法。

Images