(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024161262
(43)【公開日】2024-11-15
(54)【発明の名称】符号化装置
(51)【国際特許分類】
H04N 19/105 20140101AFI20241108BHJP
H04N 19/136 20140101ALI20241108BHJP
H04N 19/176 20140101ALI20241108BHJP
【FI】
H04N19/105
H04N19/136
H04N19/176
【審査請求】有
【請求項の数】2
【出願形態】OL
(21)【出願番号】P 2024153800
(22)【出願日】2024-09-06
(62)【分割の表示】P 2022019690の分割
【原出願日】2011-09-30
(31)【優先権主張番号】12/896,795
(32)【優先日】2010-10-01
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】510185767
【氏名又は名称】ドルビー・インターナショナル・アーベー
(74)【代理人】
【識別番号】110000338
【氏名又は名称】弁理士法人 HARAKENZO WORLD PATENT & TRADEMARK
(72)【発明者】
【氏名】ス,イエピン
(72)【発明者】
【氏名】シーガル クリストファー エー.
(57)【要約】
【課題】所望される質を保つために必要となるビットレートは、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎてしまうことが多い。
【解決手段】第1の動きベクトルと第2の動きベクトルから構成される動きベクトル候補セットを生成する工程を備え、第1の動きベクトルは、現フレームの対象ブロックに隣接する隣接ブロックの動きベクトルであり、第2の動きベクトルは、現フレームよりも先行する先行フレーム内の第1のブロックのコロケート動きベクトルであり、第1のブロックは、最小サイズブロックのブロックサイズよりも大きい。
【選択図】
図1A
【特許請求の範囲】
【請求項1】
ある画像中の対象ブロックの動きベクトルを符号化する符号化装置であって、
上記対象ブロックに隣接する第1ブロックを特定する処理と、
上記対象ブロックに隣接する第2ブロックを特定する処理と、
上記第1ブロックの動きベクトルおよび上記第2ブロックの動きベクトルを決定する処理と、
上記第1ブロックの上記動きベクトルまたは上記第2ブロックの上記動きベクトルの少なくとも一方を含む、予測動きベクトル候補セットを生成する処理であって、上記第1ブロックの上記動きベクトルが上記第2ブロックの上記動きベクトルと等しい場合には、上記予測動きベクトル候補セットが上記第1ブロックの上記動きベクトルおよび上記第2ブロックの上記動きベクトルの両方ではなく1つのみを含むように、1つの動きベクトルを上記予測動きベクトル候補セットから除外する処理と、
時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるかどうかを決定する処理と、
時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるとの決定の結果、別の画像中のブロックの動きベクトルを、上記予測動きベクトル候補セットに含める処理と、
時間方向に位置する動きベクトルが予測動きベクトルとして使用できるかどうかを示すフラグを生成する処理と、
上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する処理と、を実行する符号化装置。
【請求項2】
上記対象ブロックの上記選択された予測動きベクトルに基づいて、上記対象ブロックの差分動きベクトルを生成する処理をさらに実行する請求項1に記載の符号化装置。
【発明の詳細な説明】
【技術分野】
【0001】
本件と相互参照する関連出願は無い。
【0002】
本発明は、動きベクトル候補セットを生成する方法に関する。
【背景技術】
【0003】
近年の映像伝送表示システム、特に高解像度コンテンツ対応の映像伝送表示システムは、視覚上許容できる動画を映し出すために大幅なデータ圧縮を行うことを必要とする。なぜならば、映像フレームの非圧縮シーケンスを伝送する場合、伝送媒体は、表示映像を連続動画として人間の目に視覚させるのに十分高速な速度で伝送できないからである。同時に、視覚上許容できる動画を映し出すためには、使用する圧縮技術によってフレームデータを過剰に破棄することで画質を過度に犠牲にすべきではない。
【0004】
二つの相反する目標を遂げるために、MPEGおよびH.264などの映像圧縮符号化規格では、映像フレームシーケンスの時間冗長性が利用される。換言すれば、人間の興味を引く映像シーケンスの大部分では、隣接するフレームが同一の対象や特徴を示すことが多い。そして、これら同一の対象や特徴は、撮影シーン内の当該対象の移動(これに起因して、フレーム内の局所的移動が発生する)、シーン撮影カメラの移動(これに起因して、全体の移動が発生する)、または、その両方によって、フレーム毎に僅かに移動する。
【0005】
映像圧縮規格は動き予測を利用して、画像内の領域(対象に対応させてもよい)を定義し、当該領域に各領域のコンテンツのフレーム間動きを示す動きベクトルを関連付ける。これにより、連続するフレームの間で出現位置が僅かに異なっているだけなのに、連続する2つ以上のフレームに出現する対象またはパターンの冗長な符号化伝送を避けている。動きベクトルは、移動モデル(translational model)または回転、移動、拡大などの実際の映像カメラの動きを近似する他の多くのモデルによって表すことができる。したがって、動き予測とは、連続するフレーム内において同様の情報の符号化を繰り返し行う代わりに、動きベクトルを計算し、符号化する処理である。
【0006】
動きベクトルは、画像全体に関することもあるが、大抵の場合、画像内の小さな領域に関する。当該画像内の小さな領域としては、矩形ブロック、任意の形状、対象の境界、または、個々の画素なども挙げられる。動きベクトルを検出するために、様々な検出方法が存在する。よく知られている方法の1つにブロックマッチング法がある。ブロックマッチング法では、現画像を矩形の画素ブロック(4×4画素、4×8画素、8×8画素、16×16画素など)に分割し、上記画素ブロックに最も適合する参照画像の画素ブロックを後続フレームの所定検索領域から検索して、各画素ブロックの動きベクトル(または変移ベクトル)を予測する。
【0007】
上述の説明から示唆されるように、動きベクトルの使用により、ブロックを、他のフレーム内の対応ブロックを示す動きベクトルと、対象ブロックおよび参照ブロック間の“残差”または差分とについてのみ符号化することを可能にして、画像内の特定ブロックの符号化効率を向上させている。したがって、符号化が行われる必要のある差分が最小になるように、ブロックの動きベクトルを決定することが目標となる。よって、ブロックのマッチングについては、ブロックのサイズおよび配置の規定、検索方法、現フレームおよび参照フレームのブロック間のマッチング基準、または他の幾つかの側面において異なる、数多くのバリエーションが存在する。
【0008】
従来の動き補償では、エンコーダが動き予測を行い、動きベクトルをビットストリームの一部として信号で送信する。動きベクトルの伝送に費やされるビットによって、ビット予算全体のかなりの部分が占められてしまうことがあり、特に低ビットレートの適用する場合、こうした現象が認められる。近年、圧縮ビットストリームにおける動き情報量を減少させるために、動きベクトル競合(MVC:Motion Vector Competition)技術が提案されてきた。MVCでは、動きベクトル自体を予測動きベクトル(motion vector predictor)と差分動きベクトルに関して差分符号化することで、動きベクトルデータの符号化を向上させている。予測動きベクトルは、通常、レート歪みを最適化するように多数の候補からエンコーダによって選択され、動きベクトル候補は、同一フレーム内の隣接ブロックの既に符号化された動きベクトル、および/または、先行フレーム内の動きベクトルのサブセットから構成される。換言すれば、動きベクトルおよび差分の使用により、連続するフレーム間の情報の冗長性を除去してブロックデータの符号化効率を向上させると同時に、動きベクトルの符号化では、既に符号化された候補の限定セットから最適な予測を特定することで、連続するフレーム間で動きベクトルが大きく変わらない状況で冗長性を利用することができ、当該差分のビット長を最小化することができる。予測セットは、通常、空間的隣接動きベクトル(spatial motion vector neighbors)と時間的コロケート動きベクトル(temporally co-located motion vectors)との両方を含み、時空間ベクトル(spatiotemporal vectors)を含むことも可能である。
【0009】
しかし、映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートは、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎてしまうことが多い。そのため、映像伝送の符号化システムの改善が必要とされている。
【0010】
本発明の上述および他の課題、特徴、および、優れた点は、以下に示す発明の詳細な説明を添付図面と併せて考察することによって、より容易に理解されるであろう。
【先行技術文献】
【非特許文献】
【0011】
【非特許文献1】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]
【発明の概要】
【発明が解決しようとする課題】
【0012】
映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートは、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎてしまうことが多い。そのため、映像伝送の符号化システムの改善が必要とされている。
【課題を解決するための手段】
【0013】
好ましい実施形態は、ある画像中の対象ブロックの動きベクトルを符号化する符号化装置であって、上記対象ブロックに隣接する第1ブロックを特定する処理と、上記対象ブロックに隣接する第2ブロックを特定する処理と、上記第1ブロックの動きベクトルおよび上記第2ブロックの動きベクトルを決定する処理と、上記第1ブロックの上記動きベクトルまたは上記第2ブロックの上記動きベクトルの少なくとも一方を含む、予測動きベクトル候補セットを生成する処理であって、上記第1ブロックの上記動きベクトルが上記第2ブロックの上記動きベクトルと等しい場合には、上記予測動きベクトル候補セットが上記第1ブロックの上記動きベクトルおよび上記第2ブロックの上記動きベクトルの両方ではなく1つのみを含むように、1つの動きベクトルを上記予測動きベクトル候補セットから除外する処理と、時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるかどうかを決定する処理と、時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるとの決定の結果、別の画像中のブロックの動きベクトルを、上記予測動きベクトル候補セットに含める処理と、時間方向に位置する動きベクトルが予測動きベクトルとして使用できるかどうかを示すフラグを生成する処理と、上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する処理と、を実行する。
【発明の効果】
【0014】
映像伝送の符号化システムの改善することにより、映像を符号化する際にベクトル競合技法を使用したとしても、所望される質を保つために必要となるビットレートが、当該映像をデコーダへと伝送するために使用される伝送媒体にとって高すぎないようにする。
【図面の簡単な説明】
【0015】
【
図2】動きベクトルの符号化復号システムの例を示す。
【
図4】
図3に示すネスト型エントロピー符号化構造を利用するシステムを示す。
【
図5A】動きベクトル候補セットをトリミングすることが可能なエンコーダの例を示す。
【
図5B】
図5のエンコーダが使用する、動きベクトル候補セットのトリミング方法の例を示す。
【
図6】動きベクトル候補セットにおける、時間的コロケート動きベクトル(temporally co-located motion vector)を符号化する、別の実施形態を概略して示す。
【発明を実施するための形態】
【0016】
図1Aおよび1Bを参照すると、現フレーム(T=0)内の候補ブロック(斜線で図示)の動きベクトルは、後続フレーム(T=1)内の斜線で図示したブロックを指し示している。上記動きベクトルは、動きベクトルV
a、V
x、V
y、および、V
zからなる候補セットを参照して符号化してもよい。この例では、動きベクトルV
aは、先行フレーム(T=-1)におけるコロケート動きベクトル(co-located motion vector)であり、現フレームにおけるブロックAを指し示している。動きベクトルV
x、V
y、および、V
zは、現フレームにおいては、予め符号化された動きベクトルであり、後続フレーム(T=1)におけるブロックX、Y、Zをそれぞれ指し示している。
図1Aは更にブロックA’、X’、Y’、および、Z’を示している。これらブロックは、上記動きベクトルを候補ブロックの符号化時に使用した場合、それぞれの動きベクトルによって指し示されるブロックである。
【0017】
図1Bに示すように、動きベクトル競合(MVC)方法を使用すると、差分V
dの符号長を最小化するように動きベクトルV
zが選択される。この場合、上記ベクトルの単一成分(下方)の値として“1”しか必要ではない。他の差分動きベクトルはすべて、2つの成分を符号化する必要があるか、または、単一成分に対してより大きな値が必要である。
【0018】
上述の説明は簡略化したものである。したがって、異なるサイズのブロックを使用したり、各ブロックが単一画素を表してもよく、また、更に多くの動きベクトルを候補セットに含めることも可能である。例えば、現フレーム内の予め算出された全動きベクトルを候補セットに含めることが可能であり、同様に、先行フレーム内の算出されたいかなる動きベクトルについても候補セットに含めることができる。更に、候補セットは、シーン内の大きな動きおよび急激な動きを捕えるために有用である、任意の動きベクトルを所望の数だけ含んでいてもよい。
【0019】
図2を参照して上述の例を引き続き説明する。選択した動きベクトルV
zを符号化することが必要になる。直接的なアプローチとしては、エンコーダ10が、シンボルのテーブル14における各動きベクトル候補に値を割り当てる。これは、ハフマン(Huffman)符号化法または算術符号化法などの可変長エントロピー符号化方法を前提としたものであり、以下のような形態を採る:
動きベクトル候補 シンボル
V
a 0
V
x 10
V
y 110
V
z 1110
なお、上記シンボルの何れも他のシンボルの前置(prefix)ではない。よってこの例では、デコーダ12は、受信ビットストリーム内の“0”を受信した時点で中断することで当該受信ビットストリームを正確に解析し、対応するテーブル16を参照して当該受信ビットストリームを復号することができる。更に、エンコーダおよびデコーダは、好ましくは、ビットストリームの符号化および復号が行われている間に統計を収集して、テーブル14およびテーブル16の各々において、動きベクトル候補へのシンボルの割り当てを再編成し、例えば、常に、最も頻度の高い動きベクトルに最も短いシンボルが割り当てられるようにする。この処理法は、一般的にエントロピー符号化と称され、通常、ビットストリームの飛躍的な可逆圧縮をもたらす。エンコーダ10およびデコーダ12は同一の手法を使用して、ビットストリームの開始時点で初期化されるテーブル14およびテーブル16を、それぞれ構築およびアップデートする。これにより、全てのシンボルに関して、シンボル符号化に使用されるテーブル16とシンボル復号に使用されるテーブルとが、同一のテーブルになる。
【0020】
エントロピー符号化を行ったとしても、
図2に示すシステムでは、動きベクトル候補のセットからどの予測が選択されるかを示す信号を伝送する場合、深刻なオーバーヘッドが発生することがある。これは、予測の数が多い場合に特に起こりやすい。一方で、より多くの予測を使用するほど、差分動きベクトルの符号化効率を高めることができる。どの予測が選択されるか示す信号を送信する場合に発生するオーバーヘッドを更に低減させるために、更なる技術を採用してもよい。
【0021】
第一に、予測動きベクトル候補のセットにトリミングを行い、重複したベクトルを削除してもよい。2つの動きベクトル間において水平方向の値と、垂直方向の値と、参照インデクスとが等しい場合、当該2つの動きベクトルは重複したベクトルである。用語“重複したベクトル”は、“重複した動きベクトル”、“同一のベクトル”、または、“同一の動きベクトル”と均等な意味を有する用語である。例えば、
図1Aでは、ベクトルV
x、V
yは同一のベクトルであるため、これら動きベクトルのうち一方にトリミングを行うことができる。この結果、テーブルにおける最大のシンボルである“1110”を削除することができる。第二に、トリミングが行われた予測動きベクトルセットのサイズを知ることは、当該予測動きベクトルセットのうち最後のシンボルの最後のビットを省略できることを意味する。例えば、上述の例では、V
x、V
yの一方にトリミングが行われ、その結果
“110”が最後のシンボルとなっている。このシンボル“110”について、ビット配
列“11”がテーブルに格納される他の全ての先行シンボルから区別できる場合、“110”を単にビット配列“11”として符号化してもよく、デコーダは、トリミングされたセットのサイズに基づいて、これ以上シンボルが存在しないと判断する。
【0022】
これら2つの技術を加えることで、選択された予測動きベクトルを示す信号を送信する場合に発生するオーバーヘッドを大幅に低減するかもしれない。しかし、これらの技術を使用すると、予測動きベクトルのエントロピー復号が、動きの予測セットに左右されることになる。すなわち、動きの予測セットの一式が利用可能になり、且つ、正確に構築されるまで、ビットストリームの正確な解析が行えない。このような制約は、デコーダの誤り耐性に深刻な影響を及ぼし、その結果、2つの不都合を引き起こす。1つ目の不都合は時間依存性である。画像が損傷または損失した場合、後続の画像の復号が、解析段階で失敗してしまうことがある。2つ目の不都合は空間依存性である。画像の特定領域が損傷した場合、当該画像内の後続の領域の復号が、解析段階で失敗してしまうことがある。
【0023】
このことは、深刻な問題となることがある。すなわち、先行フレームまたは現フレームの動きベクトルデータが損失したにも関わらず、動きベクトルの候補セット一式を再構築することが求められる場合、デコーダは、独立して符号化されたフレームが到達するまでは、ビットストリームの解析を行うことすらできない。このことは、動きベクトル、差分動きベクトル、および、差分の符号化に使用された情報の損失により、単に、解析されたデータを正確に復号できなくなる場合よりも、より深刻な問題となる。なぜならば、後者の場合では、引き続き受信される、上述の損失データに依存しないビットストリーム中のいかなる解析データも復号を行うことが可能であるからである。しかし、デコーダがビットストリームの解析を行えなくなってしまうと、後続のシンボルを復号する方法が絶たれてしまう。
【0024】
反直観的なことではあるが、誤り耐性とオーバーヘッドとの間のトレードオフは解決不可能な事柄ではない。本発明者らは、符号化効率の向上は、動きベクトルの候補セットから選択される1つを通知することで達成されることと同様に、理論的には、序列化された候補セットの集団から選択される1つを通知することで達成できるということをさらに見出した。この符号化効率の向上は、動きベクトルのトリミングおよびtruncated unary符号との直列使用だけでなく、実際にはこれら技術の代わりとして効果をもたらすことができる。すなわち、重複した動きベクトル候補のトリミングと最長ビット長のシンボルの切り捨ての何れも行わずにビットストリーム解析を行う場合において、空間および時間の非依存性を維持することができる。
【0025】
具体的には、
図3を参照すると、エンコーダまたはデコーダがネスト型エントロピー符号化構造を利用しており、個別のVLCテーブル20のように複数のエントロピー符号化された動きベクトル候補セットそれぞれに対して、複数の符号化シンボル18の1つが割り当てられる。なお、VLCテーブル20のうち特定の1つが、他のVLCテーブル20とは異なる動きベクトルセットを含んでもよい。つまり、あるVLCテーブル20に含まれている特定の動きベクトルが、全てのVLCテーブル20に含まれている必要はない。エンコーダは、VLCテーブル20のうち、通知される動きベクトルが最も高い頻度を持ち、その結果最も短い符号長を持つVLCテーブル20(候補セット)の1つに対応するシンボル18の1つを通知してもよい。候補セットをそれぞれ特定する符号化されたシンボル18自体を、必要に応じて、エントロピー符号化することもでき、または固定長符号や、他の任意の符号化技術によって符号化してもよい。
【0026】
上述の説明の潜在的な前提として、全ての可能な動きベクトル候補セットの複数には、ある非ランダム分布が存在するということがある。例えば、個々の候補セットそれぞれが、互いにランダムの分布した、シンボルの順列すべてを含んでいるならば、符号化効率の向上を期待する理由が無くなる。なぜならば、削減された符号長の恩恵を受けるために、テーブルにおいて、候補セット内に十分な数の動きベクトル候補が含まれることを保証するために必要な、動きベクトル候補セットの数が大きくなりすぎてしまうからである。本質的には、動きベクトル候補から選択された1つを符号化する際に得られる効率の向上は、特定の候補セットに結び付けられたシンボルの符号化時に発生するオーバーヘッドで失われる。これは、以下のことからも理解できる。動きベクトルのエントロピー符号化が、動きベクトル間の予測可能な空間関係および時間関係によって機能し、一部の動きベクトル候補の出現頻度を他の動きベクトル候補よりも高くすることと同じように、本開示のネスト型エントロピー符号化構造は、候補セット中のシンボルの可能な順列のうちいくつかの出現頻度が他よりも高くなる場合にのみ、更なるビットストリームの圧縮を行って、符号長の長い候補セットが、符号長の短い候補セットほど頻繁には使用されなくなるようにすることを目的とする。
【0027】
研究の結果、本発明者らは、本開示のネスト型エントロピー符号化構造によって符号化効率が実際に向上されるだけでなく、隣接画素または隣接画素ブロックのシンタックス要素が、セット内の動きベクトル候補の序列化の確率と相関していることを見出した。例えば、
図4を参照すると、エンコーダ10が、シンタックスモデル24からシンタックスシンボルを入手してもよい。シンタックスモデル24は、動きベクトル候補セットの複数のVLCテーブルを区別するために使用される、符号化データ内のシンタックス要素セットを規定して、これにより、選択された動きベクトル候補を符号シンボルによって符号化する際に使用されるVLCテーブルを決定するために、エンコーダおよびデコーダが使用するシンタックス要素セットも規定する。これらシンタックス要素は、例えば、時間的または空間的に隣接する画素ブロックにおける選択された動きベクトル候補に関するか、このような選択された動きベクトル候補の組み合わせに関するか、または、候補セット内の選択動きベクトルの確率分布との関連性を有するように決定された任意の要素に関することができる。一実施形態において、エンコーダ10(したがって、およびデコーダ12)は、シンタックス要素の異なる組み合わせを試験して、符号化効率を知的に最大化する、学習因子を備える。別の言い方をすれば、エンコーダ10は、利用可能なシンタックス要素の異なる組み合わせを反復して選択し、選択した各組み合わせに付随する符号化効率の変化を測定し、且つ、当該各組み合わせ内の1つまたは複数のシンタックス要素を置換することで測定結果に応じた反応を行うことで、符号化効率を知的に最適化する。
【0028】
シンタックスモデル24から入手したシンタックスシンボルを使用して、エンコーダ10はその後、VLCテーブル28a、28b、28c、28dなどに含まれる、現ブロック用に選択された動きベクトルに利用可能な動きベクトルシンボルを使用し、デコーダ12へ送信するビットストリームにおいて当該動きベクトルシンボルを符号化してもよい。また、エンコーダ10は、選択されたシンボルに基づいて使用されるVLCテーブルにおける動きベクトルシンボルの序列をアップデートする。一実施形態において、テーブル内に含まれるシンボルの出現頻度分布に変化が起こると、シンボルが再序列化される。別の実施形態において、エンコーダ10(およびデコーダ12)が、再序列化が行われる前のセットにおいて最も出現頻度が高かったシンボルの経過を追って、当該シンボルが必ずテーブル内で最上位に序列されるようにする(すなわち、当該シンボルの符号長が必ず最短になるようにする)。なお、この例では、シンタックスシンボルが、既に符号化されたデータのシンタックスのみによって決定されているため、デコーダ12が同一のシンタックスモデルを使用して、受信動きベクトルシンボルを抽出する特定のVLCテーブル30a、30b、30c、30dを決定する限りにおいて、エンコーダが動きベクトルシンボルと共にシンタックスシンボルを符号化する必要は無い。換言すれば、エンコーダ10が、既に符号化を行ったデータのシンタックスを使用してVLCテーブルを区別し、その過程でこれらVLCテーブル内のシンボルの序列をアップデートしている場合、非常に高い符号化効率を達成することができる。
【0029】
デコーダ12がエンコーダ10から符号化ビットストリームを受信すると、デコーダ12はビットストリームを解析し、受信したシンボルに適切なVLCテーブルを決定し(シンタックスモデル26が利用可能な場合にはシンタックスモデル26を使用して)、当該受信したシンボルを復号して、候補セットから選択された動きベクトルを識別する。また、デコーダは、エンコーダ10と同じ方法で各VLCテーブルのアップデートを行う。
【0030】
予測動きベクトルセットは、選択される動きベクトルを空間的に予測する動きベクトル候補(すなわち、現ブロックと同一フレーム内の候補)と、選択される動きベクトルを時間的に予測する動きベクトル候補(現フレームに先行するフレーム内のコロケートブロックにおける候補)と、選択される動きベクトルを時空的に予測する動きベクトル候補(すなわち、上記コロケートブロックから空間的にオフセットされている、現ブロックに先行するフレーム内の候補)とを含んでいてもよい。先に言及したように、本開示のネスト型エントロピー符号化構造により、デコーダは、動きベクトル候補のトリミングまたは符号シンボルの短縮化を行うことなくビットストリームを解析できるようになり、これにより、解析処理において空間非依存性および時間非依存性を保ち、非常に高い符号化効率を達成しつつ誤り耐性を維持することができる。または、誤り耐性を少なくとも部分的に維持しつつ、ネスト型エントロピー符号化構造を動きベクトル候補のトリミング技術または符号シンボルの削減技術とつなげて使用することができる。
【0031】
例えば、
図5Aに示すように、エンコーダ10は、動きベクトル候補セット構築モジュール40を備えていてもよい。動きベクトル候補セット構築モジュール40は、1つまたは複数のバッファ28から、符号化処理中の現ブロックに適用可能な動きベクトル候補の全セットを読み出す。その後、動きベクトル候補セットトリミングモジュール42は、選択された動きベクトルが符号化モジュール44によって符号化される前に、シンタックスモデル24を動きベクトル候補セットに適用することで、所定の規則に従って動きベクトル候補セットを選択的にトリミングする。符号化モジュール44は、トリミングが行われた候補セットに基づいてシンボルを順に選択する。可能な所定規則の1つによって、例えば、既に再構築/伝送されたフレームから導出された予測動きベクトルに対して、動きベクトル候補セットモジュール42がトリミングを行うことを防止してもよい。換言すれば、2つの予測動きベクトルが同一の値を有し、一方の予測動きベクトルが現フレームのデータに対応し、他方の予測動きベクトルが他のフレームのデータに対応している場合、これら2つの予測動きベクトルの両方をトリミングが行われたセットに含めるようにする。これにより、時間非依存性が維持される。他の可能な所定の規則によれば、例えば、動きベクトル候補セットモジュール42が予測動きベクトルを異なる参照インデクスによってトリミングすることを防いでもよい。換言すれば、2つの予測動きベクトルが同一の水平および垂直方向の値を有し、一方の予測動きベクトルの参照インデクスが他方の予測動きベクトルの参照インデクスと異なる場合、これら2つの予測動きベクトルの両方をトリミングが行われたセットに含めるようにする。他の可能な所定の規則によれば、例えば、参照インデクスが同一で水平および/または垂直方向の値が異なる2つの動きベクトルの両方を、トリミングが行われたセットに含めるようにする。更に他の可能な所定の規則によれば、例えば、互いに同一の参照インデクスの値、水平、および、垂直方向の値を有する2つの動きベクトルがセットに存在する場合、一方の動きベクトルが動きベクトル候補セットモジュール42によって削除される。
【0032】
別の実施例として、所定の規則を設定することにより、別々のスライスに位置する領域から導出された予測動きベクトルが動きベクトル候補セットトリミングモジュール42によってトリミングされることを防止し、空間非依存性を保ってもよい。追加の実施形態として、所定の規則を設定することにより、別々のエントロピースライスに位置する領域から導出された予測動きベクトルが動きベクトル候補セットトリミングモジュール42によってトリミングされることを防止してもよい。エントロピースライスとは、ビットストリームの単位であり、現フレームにおいて他のデータを参照することなく、解析することができる。
【0033】
上述したこれら2つの規則は、必要ならば追加可能な規則の例として、説明目的のみにおいて記載したものである。
図5Bには、例として、新規のフラグを使用して伝送される様々なトリミング規則セットを適用するための、一般的な技術が示されている。例えば、ステップ50において、エンコーダ10がバッファ28から予測動きベクトルの候補セットを受け取る。ステップ52において、決定ステップ53においてトリミングを適用するかを決定するために使用されるフラグが、エンコーダによって送信される(または、デコーダによってフラグが受信される)。また、どのベクトルをトリミングするかを規定するために使用できるトリミング規則セットを、任意で、同様に送信してもよい。トリミングを行わない、とフラグが示しているならば、ステップ60の処理に進み、動きベクトル候補セット一式すべてを使用して、選択された動きベクトルを符号化する。しかし、所定の規則セットに従ってトリミングを行う、とフラグが示している場合、ステップ54において、重複した動きベクトルのサブセットが識別される。このように、1つの実施形態として、重複した動きベクトルのサブセットとは、上記サブセットの動きベクトルそれぞれが、上記サブセット外に同一の動きベクトルを持つような動きベクトルを最大限集めたものとして考えることができる。言い換えれば、該サブセットとは、サブセットから、動きベクトル候補セットにおいて重複した動きベクトルを持たない動きベクトルを除き、かつ、同一の重複した動きベクトルの集合からたった1つだけ削除したものであってもよい。
【0034】
ステップ56において、規則セットの所定の規則に従って、選択された動きベクトル候補を重複サブセットから、選択的に削除してもよい。このステップによって、空間非依存性および/または時間非依存性を確保することが可能となる。また、任意で、動きベクトル候補を重複動きベクトルのサブセットに加えることができる。その理由について、以下に、より詳細に説明する。概念的なレベルの話でいえば、ステップ54とステップ56を行う目的は単に、規則セットを適用して、候補セット一式の中からトリミングされる動きベクトルを識別することである。このサブセットが識別されると、このサブセットに含まれる動きベクトル候補がステップ58においてトリミングされ、その後、ステップ60において、トリミングされた候補セットのサイズに基づいて、残存している動きベクトル候補のうち、選択された動きベクトルをエンコーダが符号化する。
【0035】
図5Aに示される一般的な方法の機能性を説明するために、時間MVPフラグ(temporal#mvp#flag)の例を考察する。時間MVPフラグは、候補セットから選択された動きベクトルが時間方向に位置する動きベクトルであるかどうかを示す正/誤状態を、ビットストリームにおいて伝送するために、エンコーダによって使用されるフラグである。また、そもそもの前提として、このフラグのために適用可能な規則セットは、時間非依存性を保つことを意図しているものとする。時間予測がエンコーダによって選択されている、と時間MVPフラグによって示されている場合、候補セットにおける時間予測サブセットはトリミングされない。なぜならば、時間予測サブセットをトリミングすると、時間依存性が生じるからである。しかし、候補セットにおける空間予測サブセットをトリミングすることはできる。この理由は、時間予測サブセットのサイズをデコーダ12があらかじめ予想しているからである。
【0036】
反対に、temporal#mvp#flagが、時間予測がエンコーダによって選択されていないことを示す場合、いくつかの実施形態においては、候補セットに対して、重複動きベクトルをトリミングするだけでなく、時間予測もトリミングすることが可能であり、この場合、符号化する必要がある候補セットを大幅に小さくすることができる。さらに認識すべきこととして、もし適用可能な規則セットによって時間依存性および空間依存性が許容されるのならば、temporal#mvp#flagを、その値に関係なく使用して、(1)フラグを使用して伝送される、時間重複サブセットまたは空間重複サブセットをトリミングし、または、(2)フラグを使用して伝送されないサブセット全体をトリミングすることができる。
【0037】
本発明者らは、偶然にも、本開示のtemporal#mvp#flagの値と、制約付きイントラ予測フラグ(constrained#intra#pred#flag)との間に確かな関連性があることを見出した。constrained#intra#pred#flagは、フレームと関連づけられ、符号化映像ビットストリームにおいて使用されることが多い。具体的には、本発明者らは、これら2つのフラグの間には、constrained#intra#pred#flagの値が1のとき強い関連性が存在し、constrained#intra#pred#flagの値が0のとき、やや弱い関連性が存在することを見出した。したがって、選択された動きベクトルを通知する際のオーバーヘッドを抑えるために、エンコーダを、任意で、以下のような構成にしてもよい。すなわち、現画素のフレームのためにconstrained#intra#pred#flagが1に設定されている場合は、本開示のtemporal#mvp#flagを符号化せずに、デコーダが、temporal#mvp#flagに対して単に等しい値を挿入または仮定するようにして、constrained#intra#pred#flagが1に設定されていない場合は、temporal#mvp#flagを符号化するように構成してもよい。または、本開示のtemporal#mvp#flagに対して、単にconstrained#intra#pred#flagと同じ値を割り振ってもよい。ただし、この場合、規定する規則セットにおいて、0という値を、候補セットにおける重複ベクトルを単にトリミングするという結果に関連付けておくことが好ましい。
【0038】
このtemporal#mvp#flagシンタックスに対して、本開示のネスト型エントロピー符号化構造を追加で適用することができる。一実施形態として、temporal#mvp#flagのエントロピー符号化において使用される予測セットテンプレートを決定するために、上側隣接フラグと左側隣接フラグが使用される。これは、通常の場合、符号化値に対してエンコーダとデコーダが排他的にエントロピーシンボルを割り振り、かつ、temporal#mvp#flagが多数の値を持つ場合に有効である。別の実施形態としては、現ブロックのtemporal#mvp#flagに応じて、候補セットにおける選択された動きベクトルの符号化に使用される予測セットテンプレートが作成される。
【0039】
また、別の実施形態として、temporal#mvp#flagについて上述したように、予測動きベクトルが現フレームから導出された動きベクトルと等しい場合、または以前に再構築/送信されたフレームから導出された動きベクトルと等しい場合がある。しかし、この特定の実施形態においては、現フレームから導出された固有の予測動きベクトルの数によってインデクスを付された、フラグが送信される。例えば、本実施形態における予測セットテンプレートは、候補セットにおける固有動きベクトルの数を反映する第2の符号化値によってインデクスを付された、現ブロックから左のブロックおよび上のブロックにおけるフラグの組み合わせを反映する第1の符号化値の(例えば00、01、10、11 (0、10、110、1110としてエントロピー符号化される))、可能な組み合わせをすべて区別することができる。または、本実施形態におけるコンテクストテンプレートは、現ブロックから左のブロックおよび上のブロックにおけるフラグが同一であるか(例えば、00と11(0としてエントロピー符号化される)、と01と10(10としてエントロピー符号化される))を反映する第1の符号化値と、候補セットにおける固有動きベクトルの数を反映する第2の符号化値との、可能なすべての組み合わせを識別することができる。
【0040】
符号化スキームは、複数のフレームのそれぞれの時間コロケート動きベクトル(例えば、
図6に示す動きベクトル)を多数含む動きベクトル候補セットを含んでよい。これが意味するところは、現フレームのブロック64を符号化するために、エンコーダは、動きベクトル候補が抽出される各先行フレームにおいて選択された全動きベクトルの履歴を含む1つまたは複数のバッファにアクセスする必要がある場合があるということである。このためには、膨大な量のメモリが必要である。代替手段として、符号化スキームで使用される小サイズの画素ブロック(例えば、2×2の画素ブロック)をグループ化して、より大きなブロック62とし(動きベクトルはバッファに格納され、その後に後続ブロックを符号化する際にコロケート動きベクトルとして使用される)、代わりに各グループにおいて、選択された全ベクトルの平均動きベクトル66としてもよい。平均化処理は、コロケート動きベクトルが選択されたときはいつでも、符号化される差分が大きくなる傾向があるため、この構成はメモリ要件と引き換えに符号化効率を下げる構成といえる。そうは言っても、候補セットにおける他の動きベクトルを選ぶより、平均コロケートベクトルを使う方が効率的な場合にのみ、平均コロケートベクトルを選択するのであれば、符号化効率の減少はそれほど大きなものではない。隣接ブロックの平均値の使用に加えて、ベクトルのメディアン処理または成分毎のメディアン処理を行ってもよく、他の標準処理、例えば上限値処理、下限値処理、またはそれらを組み合わせた処理、または、いわゆる膨張(dilate)処理、収縮(erode)処理、開放(open)処理、閉鎖(close)処理などを行うこともできる。さらに、所定の位置における動きベクトルを使用してもよい。例えば、上述した後者の使用法において、大ブロックにおけるN番目の小サイズ画素ブロックに対応する動きベクトルを、大ブロックのためのコロケート動きベクトルとして、バッファに記録してもよい(Nは、大ブロックにおける小サイズブロックのラスター走査順の位置に対応する整数)。
【0041】
いくつかの実施形態においては、小サイズ画素ブロックをグループ化してよりサイズの大きいブロックとするために使用される処理を、ビットストリームにおいてエンコーダからデコーダへ伝送してもよい。例えば、上記処理をシーケンスパラメータセット(sequence parameter set)において伝送してもよい。または、上記処理をピクチャパラメータセット(picture parameter set)、スライスヘッダー、または、任意の所定画素グループにおいて伝送してもよい。更に、上記処理は、ビットストリームにおいて伝送されるレベルまたはプロファイル識別子から決定することができる。
【0042】
いくつかの実施形態においては、グループ化されてより大きなブロックになった小サイズブロックの数をビットストリームにおいてエンコーダからデコーダに伝送してもよい。例えば、上記小サイズブロックの数をシーケンスパラメータセットにおいて伝送してもよい。または、上記小サイズブロックの数をピクチャパラメータセット、スライスヘッダー、または、任意の所定画素グループにおいて伝送してもよい。上記小サイズブロックの数は、ビットストリームにおいて伝送されるレベルまたはプロファイル識別子から決定してもよい。いくつかの実施形態においては、上記小サイズブロックの数を小サイズブロックの行数および列数として表してもよい。
【0043】
なお、エンコーダおよび/またはデコーダの上述の実施形態は、数多くのハードウェア、ファームウェア、または、ソフトウェア、いずれの実施においても使用可能であることを理解されたい。例えば、エンコーダは、セットトップ型記録器、サーバ、デスクトップ型コンピュータなどに使用されてもよく、デコーダは、表示装置、セットトップ型ケーブルボックス、セットトップ型記録器、サーバ、デスクトップ型コンピュータなどにおいて使用されてもよい。これらの例は例示に過ぎず、限定するものではない。本開示のエンコーダおよびデコーダをファームウェアおよび/またはソフトウェアにおいて実行する場合、本開示エンコーダおよびデコーダの様々な構成要素は、利用可能な任意の処理装置および記憶体にアクセスして上述の技術を実施してもよい。
【0044】
上述の明細書で使用した用語および表現は、本発明を説明するための用語および表現であり、本発明を限定するものではない。したがって、このような用語および表現の使用により、上で図示および説明を行った特徴またはその一部の均等物を除外するものとして意図されるものではない。そして、発明の範囲は以下の請求項のみによって規定され、且つ、限定されることを認識されたい。
【0045】
(本発明の別の表現)
なお、本発明は以下のようにも表現される。すなわち、好ましい実施形態は、画像のシーケンスのうちのある画像中の対象ブロックの予測動きベクトルを復号する復号方法であって、上記ある画像内の上記対象ブロックに隣接する第1の隣接ブロックを識別する第1の識別工程と、上記ある画像内の上記対象ブロックに隣接する第2の隣接ブロックを識別する第2の識別工程と、上記第1の隣接ブロックの動きベクトルと上記第2の隣接ブロックの動きベクトルとが等しくない場合に、上記第1の隣接ブロックおよび上記第2の隣接ブロックの両方の上記動きベクトルを含んでいる予測動きベクトル候補セットを生成する第1の生成工程と、上記第1の隣接ブロックの上記動きベクトルと上記第2の隣接ブロックの上記動きベクトルとが等しい場合に、上記第1の隣接ブロックの上記動きベクトルと上記第2の隣接ブロックの上記動きベクトルとのいずれかのみを含んでいる予測動きベクトル候補セットを生成する第2の生成工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できるかどうかを示すフラグをビットストリームから取得する工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できることを上記フラグが示す場合に、別の画像中のあるブロックの動きベクトルを上記予測動きベクトル候補セットに含める工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できないことを上記フラグが示す場合に、別の画像中の上記あるブロックの上記動きベクトルを上記予測動きベクトル候補セットから除外する除外工程と、上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する選択工程と、を含み、上記対象ブロックの動きベクトルは、上記選択された予測動きベクトルおよび差分動きベクトルに基づいて導出される。
【0046】
また、好ましい実施形態は、画像のシーケンスのうちのある画像中の対象ブロックの予測動きベクトルを復号するデコーダを備える装置であって、上記デコーダは、上記ある画像内の上記対象ブロックに隣接する第1の隣接ブロックを識別し、上記ある画像内の上記対象ブロックに隣接する第2の隣接ブロックを識別し、上記第1の隣接ブロックの動きベクトルと上記第2の隣接ブロックの動きベクトルとが等しくない場合に、上記第1の隣接ブロックおよび上記第2の隣接ブロックの両方の上記動きベクトルを含んでいる予測動きベクトル候補セットを生成し、上記第1の隣接ブロックの上記動きベクトルと上記第2の隣接ブロックの上記動きベクトルとが等しい場合に、上記第1の隣接ブロックの上記動きベクトルと上記第2の隣接ブロックの上記動きベクトルとのいずれかのみを含んでいる予測動きベクトル候補セットを生成し、時間方向に位置する動きベクトルを予測動きベクトルとして使用できるかどうかを示すフラグをビットストリームから取得し、時間方向に位置する動きベクトルを予測動きベクトルとして使用できることを上記フラグが示す場合に、別の画像中のあるブロックの動きベクトルを上記予測動きベクトル候補セットに含め、時間方向に位置する動きベクトルを予測動きベクトルとして使用できないことを上記フラグが示す場合に、別の画像中の上記あるブロックの上記動きベクトルを上記予測動きベクトル候補セットから除外し、上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択し、上記対象ブロックの動きベクトルは、上記選択された予測動きベクトルおよび差分動きベクトルに基づいて導出され、上記差分動きベクトルは、上記ビットストリームから取得される。
【0047】
また、好ましい実施形態は、画像のシーケンスのうちのある画像中の対象ブロックの予測動きベクトルを復号する方法であって、ある画像中の対象ブロックにアクセスする工程と、それぞれが上記画像中の上記対象ブロックに隣接する第1ブロックおよび第2ブロックを特定する工程と、上記第1ブロックの動きベクトルが上記第2ブロックの動きベクトルと等しくないと決定することを条件として、上記第1ブロックの上記動きベクトルおよび上記第2ブロックの上記動きベクトルを、上記対象ブロックの予測動きベクトル候補セットに含める工程と、上記第1ブロックの上記動きベクトルが上記第2ブロックの上記動きベクトルと等しいと決定することを条件として、上記第1ブロックの上記動きベクトルまたは上記第2ブロックの上記動きベクトルのいずれか一方を、上記対象ブロックの上記予測動きベクトル候補セットに含める工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できるかどうかを示すフラグをビットストリームから受信する工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できることを上記フラグが示していると決定することを条件として、別の画像中のあるブロックの動きベクトルを、上記対象ブロックの上記予測動きベクトル候補セットに含める工程と、時間方向に位置する動きベクトルを予測動きベクトルとして使用できないことを上記フラグが示していると決定することを条件として、別の画像中の上記ブロックの上記動きベクトルを、上記対象ブロックの上記予測動きベクトル候補セットから除外する工程と、上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する工程と、選択した上記予測動きベクトルおよび差分動きベクトルに基づいて、上記対象ブロックの動きベクトルを導出する工程と、上記対象ブロックと、上記対象ブロックの上記動きベクトルにより特定される参照ブロックとの間の差分としての残差ブロックを生成する工程と、を含む。
【0048】
また、好ましい実施形態は、ある画像中の対象ブロックの予測動きベクトルを符号化する符号化装置であって、上記対象ブロックに隣接する第1ブロックを特定する処理と、上記対象ブロックに隣接する第2ブロックを特定する処理と、上記第1ブロックの動きベクトルおよび上記第2ブロックの動きベクトルを決定する処理と、上記第1ブロックの上記動きベクトルまたは上記第2ブロックの上記動きベクトルの少なくとも一方を含む、予測動きベクトル候補セットを生成する処理と、時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるかどうかを決定する処理と、時間方向に位置する動きベクトルが上記対象ブロックの予測動きベクトルとして使用できるとの決定の結果、別の画像中のブロックの動きベクトルを、上記予測動きベクトル候補セットに含める処理と、上記対象ブロックの上記予測動きベクトルとして、上記予測動きベクトル候補セットから動きベクトルを選択する処理と、を実行する。
【0049】
また、好ましい実施形態は、画像のシーケンスのうちの、1または複数の符号化された画像を格納するビットストリームであって、上記1または複数の符号化された画像のうちのある画像中の対象ブロックに隣接する第1ブロックと、上記画像中の上記対象ブロックに隣接する第2ブロックと、時間方向に位置する動きベクトルが予測動きベクトルとして使用できるかどうかを示すフラグと、を備え、上記第1ブロックの動きベクトルが上記第2ブロックの動きベクトルと等しくない場合、上記対象ブロックの予測動きベクトル候補セットは、上記第1ブロックの上記動きベクトルおよび上記第2ブロックの上記動きベクトルを含み、上記第1ブロックの上記動きベクトルが上記第2ブロックの上記動きベクトルと等しく、かつ、時間方向に位置する動きベクトルが予測動きベクトルとして使用できることを上記フラグが示す場合、上記対象ブロックの上記予測動きベクトル候補セットは、上記第1ブロックの上記動きベクトルおよび上記時間方向に位置する動きベクトルを含む。