JPWO2016031253A1

JPWO2016031253A1 - ブロックサイズ決定方法及びプログラム

Info

Publication number: JPWO2016031253A1
Application number: JP2016544967A
Authority: JP
Inventors: 芙美代鷹野
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2014-08-28
Filing date: 2015-08-27
Publication date: 2017-06-15
Anticipated expiration: 2035-08-27
Also published as: US20170257631A1; JP6569677B2; US10356403B2; WO2016031253A1

Abstract

動き推定を行う動画像符号化方式のために、動き情報を保持する単位であるブロックサイズを決定する際に必要となる計算量を削減する。プログラムは、コンピュータに、予め定められた最も深い階層のブロックである最小ブロックのそれぞれの動き情報を求めるベクトル探索処理と、動き情報を保持する単位であるブロックサイズを決定するブロックサイズ決定処理と、現に着目している階層よりも一階層深い階層のブロックであるサブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一又は複数のサブブロックをひとつの動き情報を有するひとつのブロックに統合するか否かを判定するブロック統合処理とを実行させ、前記ブロックサイズ決定処理は、最小ブロックよりも一階層浅い階層のブロックから予め定められた最も浅い階層のブロックである最大ブロックの順に、前記ブロック統合処理を階層的に実行することによりブロックサイズを決定する。

Description

本発明は動画像の符号化に関する。本発明は、特に、符号化効率を低下させることなく、演算量を削減する動画像の符号化に関する。

近年、動画像を高解像度化する要望は益々強くなっている。こうした要望に応えるため、MPEG-2、H.264/MPEG-4 AVC（以下H.264）、H.265/HEVC（以下H.265）といった符号化方式は、後に登場したものほど圧縮効率が向上している。

これらの符号化方式は、フレーム間の動き補償予測を用いて情報を圧縮することで高い符号化効率を達成する。動き補償予測は、符号化対象フレームと符号化済みの参照フレームの間の動き情報を用いて参照フレームの画像を補正し、補正された画像（予測画像）と符号化対象となる現画像の差分情報とフレーム間の動きを表す情報のみを符号化することで動画像情報を圧縮する技術である。

フレーム間の動きは、移動量を表す動きベクトルによって表現される（例えば、特許文献１参照）。参照フレームと符号化対象フレーム間の動き情報を算出する処理を動き推定という。動き推定では、デコード画像に発生するノイズ量を抑えつつ、符号化する情報量を最小化する動き情報を算出することが重要である。このため、近年の動画像符号化装置ではRD最適化(Rate-Distortion Optimization)と呼ばれる手法が広く用いられている。

一般に、RD最適化では、着目したブロックについて多数の動きベクトル候補を想定し、それら動きベクトル候補のそれぞれについてJ=D+λRで表されるレート歪みコスト（RDコスト）が算出される。そして、RDコストが最小となるような動きベクトル候補は、その着目したブロックの動きベクトルとして採用される。このように、動きベクトル候補毎にRDコストを求めることにより、着目したブロックの動きベクトルを求める処理を、動きベクトル探索と呼ぶものとする。ここで、Dは差分画像に発生する歪み量であり、Rは動き情報の符号化で発生する符号量であり、λは画像の複雑さなどに依存する重み係数である。動き情報は動きベクトル情報を含む。動きベクトル探索では、多数の動きベクトル候補それぞれについてRDコストを算出する都合上、演算量が膨大になる。

非特許文献１にはH.265規格に基づく処理の内容が記載されている。H.265動画像符号化の処理は、CU(Coding Unit)と呼ばれる最大64x64画素のブロック単位で行われる。H.265/HEVCでは、CUサイズを可変にすることで効率的に符号量を圧縮することができる。最適なCUサイズは、図７に示すように、最大サイズのブロック64x64を階層的に四分木分割した32x32、16x16、8x8画素サイズのCUから選択される。

また、H.265規格ではCUをPU（Prediction Unit）に分割して動き推定が行われる。PUは動き情報を保持する単位である。図８に示すように、PUは、CUのサイズを2Nx2Nとするとき、2Nx2N、2NxN、Nx2N、NxNのうちの最適なブロックサイズに分割される。これら４種類の分割の仕方を総称してPU分割と呼ぶものとする。このようにCU・PUのサイズを可変とし、平坦な部分では、大きなブロックで符号化することにより、動き情報の符号量を削減することができる。他方、細かな変化のある部分では、小さなブロックで符号化することにより、差分画像の歪み量を削減することができる。これにより、動き情報の符号化で発生する符号量Rと、差分画像に発生する歪み量Dにより定められるRDコストJ=D+λRを小さくすることができる。

最適なCU分割及びPU分割を選択する単純な方法は次のようなものとなる。

（Ａ１）64x64サイズのブロックがCUとして仮定される。このときの以下の（Ａ２）〜（Ａ６）の処理をCU階層深度depth=1の処理と呼ぶものとする。

（Ａ２）CUと仮定されたブロックについて、図８で示した４つのPU分割（PU partitioning）が想定される。

（Ａ３）（Ａ２）で想定された４つのPU分割のそれぞれにおいて、PU毎に動きベクトル探索が行われる。CUのサイズは2Nx2Nとする。このとき、そのCUをそのままひとつのPU、即ち、2Nx2NのサイズのPUの動きベクトルが求められる。また、そのCUを上下に二分して、2NxNの２つのPUに分割したときの各PUの動きベクトルが求められる。また、そのCUを左右に二分して、Nx2Nの２つのPUに分割したときの各PUの動きベクトルが求められる。また、そのCUを四分木分割してNxNの４つのPUに分割したときの各PUの動きベクトルが求められる。

（Ａ４）（Ａ３）で求めた各PUの動きベクトルに基づいて、PU分割毎のRDコストの合計が求められる。2Nx2NサイズのPUについてはRDコストがひとつ求められるので、そのRDコストがそのまま合計となる。このRDコストをJ(2Nx2N)と表すものとする。2NxNサイズのPUについてはRDコストが２つ求められるので、両者が合計される。この合計をJ(2NxN)と表すものとする。Nx2NサイズのPUについても同様であり、この合計をJ(Nx2N)と表すものとする。NxNサイズのPUについては４つのRDコストが求められるので、それら４つのRDコストが合計される。この合計をJ(NxN)と表すものとする。

（Ａ５）（Ａ４）で求められたRDコストの合計が最小となるようなPU分割が求められる。即ち、J(2Nx2N)、J(2NxN)、J(Nx2N)、J(NxN)のうち、最小となるものに対応するPU分割が求められる。

（Ａ６）64x64サイズのブロックを四分木分割した４つの32x32サイズのブロックを考えて、これらのブロックがそれぞれCUであると仮定される。４つの32x32サイズのブロックのそれぞれについて、（Ａ２）〜（Ａ５）が行われる。この処理をCU階層深度depth=2の処理と呼ぶものとする。

（Ａ７）64x64サイズのブロックを四分木分割した４つの32x32サイズのブロックを考え、それら32x32サイズのブロックが更に四分木分割される。即ち、64x64サイズのブロックに対して２段階の四分木分割を行うことにより得られる、合計16個の16x16サイズのブロックがそれぞれCUと仮定される。16個の16x16サイズのブロックそれぞれについて（Ａ２）〜（Ａ５）が行われる。この処理をCU階層深度depth=3の処理と呼ぶものとする。

（Ａ８）64x64サイズのブロックに対して３段階の四分木分割を行うことにより得られる、合計で64個の8x8サイズのブロックをそれぞれCUと仮定して、（Ａ２）〜（Ａ５）が行われる。この処理をCU階層深度depth=4の処理と呼ぶものとする。

（Ａ９）（Ａ１）〜（Ａ８）の結果に基づいて、64x64ブロック全体でのRDコストの合計が最小となるようなCU分割が求められる。

CUサイズ及びPUサイズの選択は画質に大きな影響を与える。その一方で、多数のCUサイズ、PUサイズに対する動きベクトル探索処理を逐一実行すると、演算量が非常に多くなる。特に、４Ｋ等の高解像度動画用の実用的なエンコーダを実装する際に、全てのCUサイズ、PUサイズでの動きベクトル探索を実行するのは現実的ではない。H.265では、選択できるブロックサイズの種類がH.264の7種類に比べて13種類に増えたため、演算量がさらに多くなっている。

このような演算量の増加を抑制するための技術が非特許文献２に記載されている。同文献に記載のMVM（Motion Vector Merging）では、まず、小さいサイズのブロックにおける動きベクトル探索によって動き情報が求められる。次に、近接ブロック間で動き情報が比較され、等しい場合に近接ブロックが統合（merge）されて大きなブロックとみなされる。これにより演算量が抑制される。

より詳しくは、まずNxNサイズのPUの動きベクトル探索が行われる。図９に示すように、４つのNxNサイズのブロックの動きベクトルのうち3つが等しい場合には、これら４つのNxNブロックがひとつの2Nx2Nサイズのブロックに統合される。また、互いに横方向に隣接する２つのブロックの動き情報が等しい場合には、４つのNxNブロックが２つの2NxNブロックに統合される。また、互いに縦方向に隣接する２つのブロックの動き情報が等しい場合には、４つのNxNブロックが２つのNx2Nブロックに統合される。

このように、隣接ブロック間で動き情報が互いに等しい場合、それらのブロックの統合が決定されると共に、その動き情報が統合後のブロックの動き情報とみなされる。このため、上述の方法のステップ（Ａ３）における、2Nx2N、2NxN、Nx2Nのサイズのブロックに関する動きベクトル探索を行う必要がなく、NxNのサイズのブロックについてのみ動きベクトル探索が行われる。

また、隣接ブロック間での動き情報の比較に応じてブロック統合が決定されるので、上述の方法のステップ（Ａ４）（Ａ５）を行う必要がない。これは、PU分割毎のRDコストの合計を比較しなくても、動き情報の比較によって適したPU分割を選択することができるからである。

図１１のフローチャートを参照して非特許文献２に記載のブロックサイズ決定処理について説明する。blockは符号化対象となるブロックを示す変数である。depthはCU階層深度を示す１以上４以下の自然数であり、初期値は１である。2Nはブロックサイズであり、2Nは64, 32, 16, 8のいずれかであって、初期値は64である。後述するように、このブロックサイズ決定処理は再帰呼び出しを含む処理である。

ステップS1101では、depthが最大、すなわち最小サイズのブロック階層か否かが判定される。depth=4ならば判定は真であり、depth=1,2,3ならば判定は偽である。

判定が真であるとき、即ち、最小サイズのブロック階層であるとき、後述するステップS1103に処理が移行する。

一方、ステップS1101の判定が偽、すなわち最小サイズのブロック階層でなければ、着目するブロックを四分木分割して生成される４つのサブブロック、subblock[1], subblock[2], subblock[3], subblock[4]のそれぞれに対して、ブロックサイズ決定処理が行われる（ステップS1102）。このブロックサイズ決定処理は、本ブロックサイズ処理自身を呼び出す再帰呼び出しとして実行される。つまり、CU階層深度depth=1,2,3の場合、本ブロックサイズ処理自身を呼び出す再帰呼び出しが行われる。サブブロックsubblock[i]は、現に着目しているブロックよりもCU階層深度が１つ深くなるので、再帰呼び出しされたブロックサイズ決定処理では、引数depthに+1が加算されている。また、上述したように、現に着目しているブロックのサイズを示す引数が2Nである一方、サブブロックsubblock[i]のサイズを示す引数はNとなっている。

ステップS1103では、ブロックblockを四分木分割したサブブロックsubblock[1]、subblock[2]、subblock[3]、subblock[4]それぞれの動きベクトル探索が行われる。ステップS1101の判定が真であってステップS1101から処理が移行してきた場合、即ち、depth=4であり、ブロックサイズが8x8の場合、そのサブブロックである4x4のブロックそれぞれについて動きベクトル探索が行われる。

ステップS1104では、ステップS1103で得られた各サブブロックの動き情報に基づいて、ブロック統合の処理が行われ、最良ブロックサイズbestPartが決定される。詳細については後述するが、ブロック統合処理は最良ブロックサイズbestPartとして2Nx2N、2NxN、Nx2N、NxNのいずれかを返す。

ステップS1105では、最良ブロックサイズbestPartにおけるRDコストbestPartCostと、それまでの最良コストminCostとの大小の比較が行われる。RDコストbestPartCostが最良コストminCostよりも小さい場合（ステップS1105のy）には、最良コストminCostがRDコストbestPartCostの値で更新され、最良深度bestDepthが現在実行中のブロックサイズ決定処理のCU階層深度の値で更新される（ステップS1106）。

次にステップS1104のブロック統合処理の動作について図１２を参照して説明する。ブロック統合処理では４つのブロックblockが引数となる。ただし、ここでいう引数blockが示すブロックは、図１１のフローチャートにいうsubblock[i]に相当する。

ステップS1002では、引数として指定した４つのブロックについて予め求めた動き情報に基づいて、2Nx2Nサイズのブロックへの統合の可否が判定される。統合可能な場合（ステップS1002のy）、最良ブロックサイズbestPartとして2Nx2Nが返される。非特許文献２では、2Nx2Nに統合可能な条件を４つのうち３つのブロックの動きベクトルが同一であることとしている。

ステップS1003では、引数として指定した４つのブロックについて予め求めた動き情報に基づいて、2NxNサイズのブロックへの統合の可否が判定される（ステップS1003のy）。統合可能な場合、最良ブロックサイズbestPartとして2NxNが返される。非特許文献２では2NxNに統合可能な条件は、横に並ぶ２つのブロックを一組としたとき、組となるブロック同士の動きベクトルが同一であることとしている。

ステップS1004では、引数として指定した４つのブロックについて予め求めた動き情報に基づいて、Nx2Nサイズのブロックへの統合の可否が判定される。統合可能な場合（ステップS1004のy）、最良ブロックサイズbestPartとしてNx2Nが返される。非特許文献２では、Nx2Nに統合可能な条件は、縦に並ぶ２つのブロックを一組としたとき、組となるブロック同士の動きベクトルが同一であることとしている。

ステップS1002、S1003、S1004のどの条件にも当てはまらない場合、最良ブロックサイズbestPartとしてNxNが返される。

このブロックサイズ決定処理では、次のようなタイミングで動きベクトル探索が実行される。

まず、深度depth=4のブロックサイズ決定処理が行われる。ここでは、ステップS1103において、8x8サイズブロック１（図１４）、8x8サイズブロック２（図１５）、8x8サイズブロック３（図１６）、8x8サイズブロック４（図１７）を対象とする動きベクトル探索が行われる。深度depth=4において動きベクトル探索の対象となるサブブロックは4x4サイズブロックである。

次に、8x8サイズブロック１〜４からなる16x16サイズブロック（図１８）を対象として、depth=3のブロックサイズ決定処理が行われる。ここでは、ステップS1103において8x8サイズブロックをサブブロックとして動きベクトル探索が行われる。

8x8サイズブロック１〜４を対象とするdepth=4のブロックサイズ決定処理と同様にして、8x8サイズブロック５〜８を対象とするdepth=4のブロックサイズ決定処理がそれぞれ行われる。また、8x8サイズブロック５〜８からなる16x16サイズブロック（図１９）を対象とするdepth=3のブロックサイズ決定処理が行われる。8x8サイズブロック９〜１２についても、depth=4のブロックサイズ決定処理がそれぞれ行われ、8x8サイズブロック９〜１２からなる16x16サイズブロック（図２０）を対象とするdepth=3のブロックサイズ決定処理が行われる。更に、8x8サイズブロック１３〜１６を対象とするdepth=4のブロックサイズ決定処理がそれぞれ行われ、8x8サイズブロック１３〜１６からなる16x16サイズブロック（図２１）を対象とするdepth=3のブロックサイズ決定処理が行われる。

次に、8x8サイズブロック１〜１６からなる32x32サイズブロック（図２２）を対象とするdepth=2のブロックサイズ決定処理が行われる。depth=2のステップS1103における動きベクトル探索のサブブロックは16x16サイズブロックである。

上述の、8x8サイズブロック１〜１６を対象とするdepth=4,3,2のブロックサイズ決定処理が、8x8サイズブロック１７〜３２、8x8サイズブロック３３〜４８、及び、8x8サイズブロック４９〜６４それぞれを対象として行われる。

最後に、全ブロック、即ち、8x8サイズブロック１〜６４からなる64x64サイズブロックを対象とするdepth=1のブロックサイズ決定処理が行われる。depth=1の動きベクトル探索におけるサブブロックは32x32サイズブロックである。

このように、非特許文献２に記載のブロックサイズ決定処理は、現に着目しているCU階層深度depthにおけるサブブロックそれぞれについて動きベクトル探索を行うステップ（ステップS1103）を含む。depth=4では4x4サイズブロック、depth=3では8x8サイズブロック、depth=2では16x16サイズブロック、depth=1では32x32サイズブロックをそれぞれ対象として動きベクトル探索が行われる。

特開２０１２-２５７１４８号公報

ITU-T Recommendation H.265 ''High efficiency video coding,'' Apr 2013. Felipe Sampaio, Sergio Bampi, Mateus Grellert, Luciano Agostini, Julio Mattos, "Motion Vectors Merging: Low Complexity Prediction Unit Decision Heuristic for the Inter-Prediction of HEVC Encoders", 2012 IEEE International Conference on Multimedia and Expo. p.658-662

検討を重ねた結果、発明者はブロックサイズ決定処理に要する演算量を更に削減する余地があることを見出した。

上述したように、非特許文献２に記載のブロックサイズ決定処理では、指定したCU階層深度にてブロックを四分木分割して４つのサブブロックとし、これらサブブロックのそれぞれについて動きベクトル探索が行われる。この手法には冗長な動きベクトル探索が含まれていることが判明した。

深度４のブロックサイズ決定処理では、ステップS1103において8x8サイズブロックの動きベクトル探索が行われる。一方、深度３のブロックサイズ決定処理のステップS1103では、16x16サイズブロックのサブブロックそれぞれについて動きベクトル探索が行われるが、このサブブロックとは8x8サイズブロックである。このため、8x8サイズブロックについての動きベクトル探索が繰り返されることになる。

本発明はこのような状況に鑑みてなされたものであり、その例示的な目的は、動き推定を行う動画像符号化方式のために、動き情報を保持する単位であるブロックサイズを決定する際に必要となる計算量を削減することである。

本発明は、その一態様として、コンピュータに、予め定められた最も深い階層のブロックである最小ブロックのそれぞれの動き情報を求めるベクトル探索処理と、動き情報を保持する単位であるブロックサイズを決定するブロックサイズ決定処理と、現に着目している階層よりも一階層深い階層のブロックであるサブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一又は複数のサブブロックをひとつの動き情報を有するひとつのブロックに統合するか否かを判定するブロック統合処理とを実行させ、前記ブロックサイズ決定処理は、最小ブロックよりも一階層浅い階層のブロックから予め定められた最も浅い階層のブロックである最大ブロックの順に、前記ブロック統合処理を階層的に実行することによりブロックサイズを決定する動き推定を行う動画像符号化方式のためのプログラムを記録したコンピュータ読み取り可能なプログラム記録媒体を提供する。

また、本発明は、他の一態様として、予め定められた最も深い階層のブロックである最小ブロックのそれぞれの動き情報を求め、動き情報を保持する単位であるブロックサイズを決定し、現に着目している階層よりも一階層深い階層のブロックであるサブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一又は複数のサブブロックをひとつの動き情報を有するひとつのブロックに統合するか否かを判定し、前記ブロックサイズを、最小ブロックよりも一階層浅い階層のブロックから予め定められた最も浅い階層のブロックである最大ブロックの順に前記判定を階層的に実行することにより決定する動き推定を行う動画像符号化方式のためのブロックサイズ決定方法。を提供する。

本発明によれば、最小ブロックの動き情報を求めた後、その動き情報を起点として、最小ブロックよりも一階層浅い階層のブロックから最大ブロックの順に、ブロック統合処理を階層毎に実行することにより、ブロックサイズを決定するので、階層毎にベクトル探索を実行する必要がない。このため計算量を削減することができる。

図１は、本発明の第１〜第４の実施の形態に係るブロックサイズ決定処理の一例について説明するためのフローチャートである。図２は、本発明の第２の実施の形態に係るブロック統合処理について説明するためのフローチャートである。図３は、本発明の第２の実施の形態に係るブロック統合処理について説明するためのフローチャートである。図４は、本発明の第３の実施の形態に係るブロック統合処理について説明するためのフローチャートである。図５は、本発明の第３の実施の形態に係るブロック統合処理について説明するためのフローチャートである。図６は、本発明の第４の実施の形態に係るブロック統合処理について説明するためのフローチャートである。図７は、64x64サイズのＣＵを四分木分割して得られるブロックについて説明するための図である。図８は、2Nx2NサイズのCUと2Nx2N、2NxN、Nx2N、NxNサイズのPUの関係を説明するための図である。図９は、動き情報に基づいて行うブロック統合について説明するための図である。図１０は、ブロック統合情報mertgeinfoを含む統合条件に基づいてブロック統合処理の実行の要否を判定する動作を説明するための図である。図１１は、非特許文献２に記載のブロックサイズ決定処理について説明するためのフローチャートである。図１２は、非特許文献２に記載のブロックサイズ決定処理、及び、本発明の第1の実施の形態におけるブロック統合処理について説明するためのフローチャートである。図１３は、ブロックサイズ決定処理の対象となるブロックについて説明するための図である。図１４は、CU階層深度depth=4で動きベクトル探索の対象となるブロックについて説明するための図である。図１５は、CU階層深度depth=4で動きベクトル探索の対象となるブロックについて説明するための図である。図１６は、CU階層深度depth=4で動きベクトル探索の対象となるブロックについて説明するための図である。図１７は、CU階層深度depth=4で動きベクトル探索の対象となるブロックについて説明するための図である。図１８は、CU階層深度depth=3で動きベクトル探索の対象となるブロックについて説明するための図である。図１９は、CU階層深度depth=3で動きベクトル探索の対象となるブロックについて説明するための図である。図２０は、CU階層深度depth=3で動きベクトル探索の対象となるブロックについて説明するための図である。図２１は、CU階層深度depth=3で動きベクトル探索の対象となるブロックについて説明するための図である。図２２は、CU階層深度depth=2で動きベクトル探索の対象となるブロックについて説明するための図である。図２３は、CU階層深度depth=2で動きベクトル探索の対象となるブロックについて説明するための図である。図２４は、CU階層深度depth=2で動きベクトル探索の対象となるブロックについて説明するための図である。図２５は、CU階層深度depth=1で動きベクトル探索の対象となるブロックについて説明するための図である。図２６は、コンピュータの一例を示すブロック図である。

（第１の実施の形態）
本発明の第1の実施の形態であるブロックサイズ決定処理１について説明する。ブロックサイズ決定処理１は、コンピュータが、符号化対象となるブロックを示す変数block、CU階層深度を示す変数depth、ブロックサイズを示す変数2Nを指定して行う処理である。ここでは、CU階層深度depthは1以上４以下の自然数である。ブロックサイズ2Nは８、１６、３２、６４のいずれかである。CU階層深度depthの初期値は１である。ブロックサイズ2Nの初期値は64である。後述するように、ブロックサイズ決定処理１は自分自身を呼び出す再帰呼び出しを含む処理である。

ブロックサイズ決定処理１について図１のフローチャートを参照して説明する。まず、コンピュータは、CU階層深度depthが最大であるか否か、即ち、最小サイズのブロック階層か否かを判定する（ステップS101）。

判定が真、すなわち、CU階層深度depth=4であって、最小サイズのブロック階層である場合、コンピュータは、そのブロックの動きベクトル探索を行って動き情報を求め、その動き情報に基づいてそのブロックのRDコストを算出する（ステップS106）。そして、コンピュータは、現在のCU階層深度depth=4を最良深度bestDepth=4と設定（ステップS107）してリターンする。

判定が偽、即ち、CU階層深度depthが１から３であって、最小サイズのブロック階層ではない場合、コンピュータは、ブロックサイズ決定処理１を再帰呼び出しする（ステップS102）。即ち、コンピュータは、そのブロックを四分木分割して生成されるサブブロックそれぞれを対象として、ブロックサイズ決定処理１を行う。

ステップS102において、ブロックを構成する４つのサブブロックそれぞれを対象としたブロックサイズ決定処理１が終了すると、この時点で、各サブブロックの動き情報が得られる。

ステップS103では、コンピュータは、ステップS102で得られた各サブブロックの動き情報に基づいてブロック統合処理を行うことで、最良ブロックサイズbestPartを決定する。ここで行うブロック統合処理は、背景技術の欄において図１２を参照しつつ上述したものが用いられる。ブロック統合処理は、最良ブロックサイズbestPartとして2Nx2N、2NxN、Nx2N、NxNのいずれかを返す処理である。

ステップS104では、コンピュータは、最良ブロックサイズbestPartにおけるRDコストbestPartCostと、それまでの最良コストminCostとの大小を比較する。RDコストbestPartCostが最良コストminCostよりも小さい場合（ステップS104のy）、コンピュータは、RDコストbestPartCostの値で最良コストminCostを更新すると共に、現在実行中のブロックサイズ決定処理のCU階層深度の値で最良深度bestDepthを更新する（ステップS105）。

コンピュータは、ステップS106、S107にてCU階層深度depth=4を対象とする処理を行う。depth=4のブロックサイズ決定処理におけるサブブロックは、4x4サイズブロックである。特に、ステップS106において、コンピュータは、8x8サイズブロック１（図１４）、２（図１５）、３（図１６）、４（図１７）を対象とする動きベクトル探索を行う。

コンピュータは、8x8サイズブロック１〜４からなる16x16サイズブロック（図１８）を対象とするdepth=3のブロックサイズ決定処理としてステップS102-S105を行う。

コンピュータは、上述の8x8サイズブロック１〜４を対象とするdepth=4のブロックサイズ決定処理と同様にして、8x8サイズブロック５〜８を対象とする動きベクトル探索をステップS106にてそれぞれ行う。更に、コンピュータは、8x8サイズブロック５〜８からなる16x16サイズブロック（図１９）を対象とするdepth=3のブロックサイズ決定処理としてステップS102-S105を行う。

コンピュータは、上述の8x8サイズブロック１〜４を対象とするdepth=4のブロックサイズ決定処理と同様にして、8x8サイズブロック９〜１２を対象とする動きベクトル探索をステップS106にてそれぞれ行う。また、コンピュータは、8x8サイズブロック９〜１２からなる16x16サイズブロック（図２０）を対象とするdepth=3のブロックサイズ決定処理としてステップS102-S105を行う。

コンピュータは、上述の8x8サイズブロック１〜４を対象とするdepth=4のブロックサイズ決定処理と同様にして、8x8サイズブロック１３〜１６を対象とする動きベクトル探索をステップS106にてそれぞれ行う。また、コンピュータは、8x8サイズブロック１３〜１６からなる16x16サイズブロック（図２１）を対象とするdepth=3のブロックサイズ決定処理としてステップS102-S105を行う。

コンピュータは、8x8サイズブロック１〜１６からなる32x32サイズブロック（図２２）を対象とするdepth=2のブロックサイズ決定処理としてステップS102-S105を行う。depth=2のブロックサイズ決定処理におけるサブブロックは、16x16サイズブロックである。

コンピュータは、上述の、8x8サイズブロック１〜１６を対象とするdepth=4,3,2のブロックサイズ決定処理と同様の処理を、8x8サイズブロック１７〜３２、8x8サイズブロック３３〜４８、及び、8x8サイズブロック４９〜６４をそれぞれ対象として行う。

最後に、コンピュータは、全ブロック、即ち、8x8サイズブロック１〜６４からなる64x64サイズブロックを対象とするdepth=1のブロックサイズ決定処理としてステップS102-S105を行う。depth=1のブロックサイズ決定処理におけるサブブロックは、32x32サイズブロックである。尚、上述の処理には、並列して実行可能な処理が多数含まれているが、これらの一部又は全部は並列処理で実現されてもよい。

上述のように、ブロックサイズ決定処理１によれば、動きベクトル探索処理を行うのはCU階層深度が最深のとき、即ち、深度４のブロックサイズ決定処理におけるステップS106のみであり、深度１〜３のブロックサイズ決定処理では動きベクトル探索処理が行われない。このため、ブロックサイズ決定処理１によれば、深度１〜４のそれぞれにおいて動きベクトル探索処理を行う従来の手法と比較して、演算量を削減することができる。

非特許文献２によれば、図１１のステップS1103に示すように、CU階層深度depth=１〜４のそれぞれにおいて、サブブロックの動きベクトル探索が行われる。depth=4では4x4サイズブロックを対象として動きベクトル探索が行われる。depth=3では8x8サイズブロックを対象として動きベクトル探索が行われる。depth=2では16x16サイズブロックを対象として動きベクトル探索が行われる。depth=1では32x32サイズブロックを対象として動きベクトル探索が行われる。これに対して、本実施形態のブロックサイズ決定処理１では、depth=4での4x4サイズブロックを対象とする動きベクトル探索のみが行われ、depth=3,2,1では動きベクトル探索が行われない。

上述の第1の実施の形態では、ブロック統合処理において、互いに隣接するサブブロックの動きベクトルが完全に一致するとき、それらサブブロックを統合するものとして説明した。第１の実施の形態の一変形例として、コンピュータは、互いに隣接するサブブロックの動きベクトルの差を求め、その差が予め定められた閾値以下の場合、それらのサブブロックの動きベクトルは一致するものとみなしてもよい。本変形例では、閾値はCU階層深度に関わらず一定とする。

（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。第1の実施の形態では、ブロック統合処理において、複数のサブブロックの統合の可否を判定する条件は、CU階層深度に関わらず一定であり、隣接するサブブロックの動きベクトルが一致するか否かに応じて、それらサブブロックの統合の可否を判定した。上述した第１の実施の形態の変形例も、CU階層深度に関わらず同じ条件でサブブロック統合の可否を判定するという点で同様であり、隣接するサブブロックの動きベクトルの差と予め定められた一定の閾値との比較結果に応じてサブブロックの統合の可否を判定した。

これに対して、第２の実施の形態では、サブブロック統合の可否を判定する際の条件が、CU階層深度に応じて異なる。第２の実施の形態は、その他の点では第１の実施の形態と同様である。以下、第１の実施の形態とは異なる点を中心として説明する。

図１のステップS103にて行うブロック統合処理として、第２の実施の形態では、図２に示したブロック統合処理２を行う。ブロック統合処理２では、引数として、統合対象サブブロックblockに加えて、CU階層深度depthをとる。ステップS201では、コンピュータは、CU階層深度depthに応じてステップS202,S203,S204で用いる判定条件を決定する。

ここで、複数のサブブロックを統合可能か判断する際に用いる判定条件を統合条件と呼び、統合条件を決定する処理を統合条件決定処理と呼ぶものとする。ブロック統合処理２では、コンピュータは、CU階層深度depthに応じて判定条件を決定する。コンピュータは、統合条件決定処理によって階層深度に応じてサブブロックの統合の要否を判定するので、画質の向上や圧縮効率の向上を図ることができる。

ブロック統合処理２の一例としてブロック統合処理３を挙げることができる。図３を参照すると、ブロック統合処理３の統合条件決定処理S301では、コンピュータは、CU階層深度depthに応じて、サブブロック間動きベクトル差の閾値を決定する。隣り合うサブブロックが同じ方向に動いているか否かを判定する際、第1の実施の形態の変形では、隣り合うサブブロックの動きベクトルの差を求め、その差が予め定めた閾値以下の場合に、それらのサブブロックの動きベクトルは一致すると判定された。その際に参照する閾値は、CU階層深度depthに関わらず一定だった。これに対して、ブロック統合処理３では、CU階層深度depthに応じて異なる閾値が用いられる。

一般に、階層が深い、即ち、ブロックサイズが小さいほど動き情報に必要な符号量が多くなる。ブロック統合処理３では、ステップS301において閾値thをCU階層深度depthとする。

コンピュータは、以後のステップS302-S304において統合の可否を判定する際の判定条件を、CU階層深度depthに応じて変えるように構成されている。例えば、ステップS302では、４つのブロックblock[0]、block[1]、block[2]、block[3]が四分木構造に配置されているとき、ブロックblock[0]の動き情報block[0].mvとブロックblock[1]の動き情報block[1].mvの差分と閾値thとを比較することが、block[0].mv-block[1].mv<thとして記載されている。
同様にして、ブロックblock[2]の動き情報block[2].mvとブロックblock[3]の動き情報block[3].mvの差分と閾値thとの比較を行うことが、block[2].mv-block[3].mv<thとして記載されている。また、ブロックblock[0]の動き情報block[0].mvとブロックblock[2]の動き情報block[2].mvの差分と閾値thとの比較を行うことが、block[0].mv-block[2].mv<thとして記載されている。また、ブロックblock[1]の動き情報block[1].mvとブロックblock[3]の動き情報block[3].mvの差分と閾値thとの比較を行うことが、block[1].mv-block[3].mv<thとして記載されている。これら４つの不等式で表された条件は、論理積を示す記号&&で連結されている。ステップS303、S304その他後述する図６のステップS602-S604も、同様の表記方法にて記載されている。

このようにすることにより、CU階層深度が大きいほど、閾値thが大きくなり、ブロック統合がされやすくなる一方、CU階層深度が小さいほど、閾値thが小さくなり、ブロック統合がされにくくなる。

2Nx2N統合判定であるステップS302では、コンピュータは、隣り合うサブブロックの動き情報の差を求め４つのベクトル差が全て閾値以下なら2Nx2Nと判定する。2NxN統合判定であるステップS303では、コンピュータは、横に隣り合うサブブロックの動き情報の差が全て閾値以下なら2NxNと判定する。Nx2N統合判定であるステップS304では、コンピュータは、縦に隣り合うサブブロックの動き情報の差が全て閾値以下ならNx2Nと判定する。

ブロック統合処理２の別の例としては、４つのサブブロックを2Nx2Nに統合する旨の判定をする際、動き情報が一致するサブブロックの数を、CU階層深度depthに応じて異なるものにすることが考えられる。深い階層の場合、即ち、CU階層深度depthが大きい場合には、コンピュータは、４つのサブブロックのうち任意の３つの動き情報が一致するとき、それら４つのサブブロックを統合すると判定する。一方、コンピュータは、浅い階層の場合、即ち、CU階層深度depthが小さい場合には、４つのサブブロック全ての動き情報が一致するとき、それら４つのサブブロックを統合すると判定する。

本実施の形態により、より適したブロックサイズを選択できることとなり符号化効率が向上する。

（第３の実施の形態）
次に、第３の実施の形態について説明する。第３の実施の形態では、ブロックサイズ決定処理１のブロック統合処理S203に代えて、図４に示すブロック統合処理４が用いられる。その他の動作は第1の実施の形態のブロックサイズ決定処理１と同様である。

ブロック統合処理４では、コンピュータは、統合条件としてブロック統合情報mergeInfoを用いる。ブロック統合情報mergeInfoは、より深い階層におけるブロック統合処理の結果に関する情報である。このため、ブロック統合処理４では、引数として、統合対象サブブロックblockに加えて、ブロック統合情報mergeInfoが用いられる。ステップS401では、コンピュータは、ブロック統合情報mergeInfoに応じて、ステップS402,S403,S404で用いる判定条件を決定する。

ブロック統合処理４の一例として、統合されたブロックサイズをブロック統合情報mergeInfoとして用いて判定条件を設定するブロック統合処理５を図５に示す。例えば、深いCU階層深度から浅いCU階層深度の順にブロック統合の可否を判定していく際に、現在のCU階層深度よりも深いCU階層深度においてブロックが統合できていない場合があるとする。このような場合には、動き情報の比較を行うまでもなく、現在のCU階層深度におけるサブブロックの動き情報は一致しないと判断することができる。ブロック統合処理５は、このことを考慮した処理である。

コンピュータは、ステップS501において統合条件を決定する。統合条件は、例えば、図10の右上ブロックのように深い階層で2Nx2Nに統合できなかったサブブロックが４つのうち一つでもあれば統合しない、という条件を含む。コンピュータは、この統合条件に基づいてブロック統合情報mergeInfoを判定することにより、４つのサブブロックがそれぞれ統合可能なサイズであるか否かをステップS502にて判定する。

ステップS502で偽と判断された場合、コンピュータは、その後の条件判定を行うことなく、統合できない（サイズNxN）と判断する。この場合、ステップS202-S204における、2Nx2N、2NxN、Nx2Nの統合可否を判定する処理の実行をスキップするので、その分、必要な計算量が少なくなる。

一方、ステップS502で真と判断された場合、コンピュータは、上述したブロック統合処理２のステップS202-S204を実行して、2Nx2N, 2NxNまたはNx2Nに統合するか否かを判断する。

尚、コンピュータは、ブロック統合処理２のステップS202-S204の代わりに、ブロック統合処理３またはブロック統合処理４を行うこととしてもよい。

本実施の形態によれば、より深いCU階層深度depthにおけるブロック統合処理の結果に基づいて、４つのサブブロックを2Nx2N、2NxN、Nx2Nに統合可能か否かを判定する処理の実行の要否をステップS502にて判定し、不要な場合には、これらの判定処理の実行を省略するので、ブロック統合処理の演算量を削減することができる。

（第４の実施の形態）
本実施の形態では、第３の実施の形態と同様に、より深いCU階層深度におけるブロック統合処理の結果に基づいて、ブロックが統合可能か判断する条件が決定される。第４の実施の形態では、ブロックサイズ決定処理１のブロック統合処理S203に代えて、図６に示すブロック統合処理６を用いる。その他の動作は第1の実施の形態のブロックサイズ決定処理１と同様である。

ステップS601では、コンピュータは、現在のCU階層深度depthよりも深い階層のサブブロック情報に基づいて、隣接するサブブロックの動きベクトルの差と比較する閾値を決定する。一般に、小さいブロックが多いと動き情報の符号量が多くなる。このことに鑑みて、本実施の形態では、コンピュータは、深いCU階層深度で統合したサブブロックが少ない場合（統合していないサブブロックが多い場合）には閾値を大きくする。一方、コンピュータは、深いCU階層深度で統合したサブブロックが多い場合（統合していないサブブロックが少ない場合）には閾値を小さくする。深いCU階層深度で統合したサブブロックの数が多いか少ないかは、例えば予め閾値を別に定めて、その閾値よりも多い場合は多いとし、少ない場合は少ないとする。

このようにすれば、深いCU階層深度で統合したサブブロックが少ない場合には、隣接するサブブロックの動きベクトルの差が、閾値thよりも小さくなりやすいので、ステップS602-S604が真になりやすくなる。このため、深いCU階層深度にて統合できなかったブロックについても、浅いCU階層深度にて統合できる場合が起こり得るようになる。その結果、本実施の形態のブロックサイズ決定処理によれば、圧縮効率及び画質を向上することができる。

以上、本発明を実施の形態に即して説明したが、本発明はこれに限定されるものではない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。

上述の実施の形態では、ブロック分割の手法として四分木分割を用いたものを説明しているが、本発明はこれに限定されるものではない。

例えば、上述の実施の形態では、1個の64x64ブロックを４個の32x32ブロックに分割するが、その代わりに、1個の64x64ブロックを１６個の16x16ブロックに分割することとしてもよい。

また、上述の実施の形態では、１個の正方形のブロックを４個の正方形のブロックに分割するが、分割するブロックの形状、分割したブロックの形状は、どちらも、正方形に限定されるものではない。例えば、分割の方法は、正方形のブロックを２つの長方形のブロックに分割するものでもよいし、長方形のブロックを２つの正方形のブロックに分割するものでもよい。

また、上述の実施の形態では、ブロックの形状は、どのCU階層深度でも正方形であり、換言すると、CU階層深度に関わらず、ブロックの形状は相似である。しかし、ブロックの形状は、これに限定されるものではなく、CU階層深度毎に異なる形状のブロックが用いられてもよい。例えば、ブロックの形状は、１階層目は64x64の正方形のブロックとし、２階層目は64x32の長方形のブロックとし、３階層目は32x32の正方形のブロックとしてもよい。

また、ブロックサイズは、上述の実施の形態では2Nx2N,2NxN,Nx2N,NxNとして説明されたが、これに限定されるものではない。例えば、H.265におけるAMP(Asymmetric motion partitions)のような分割や他の分割でも同様に動作可能である。

また、上述の実施の形態では、ブロック統合の可否を動きベクトルに基づいて判定したが、本発明はこれに限定されるものではない。例えば、参照フレームインデックスや参照方向などの情報に基づいて判定が行われてもよい。異なる参照フレームに対する動きベクトルの場合、フレーム間距離に応じたスケーリングを行った動きベクトル情報が用いられても良い。

ブロックを統合する判定条件は、各動きベクトルを保持する小ブロックのサイズや、各小ブロックのRDコストによって重み付けされてもよい。

上述の各実施の形態に示したようなブロック統合処理によりブロックサイズを決定したあと、再び決定されたブロックサイズのみ動きベクトル探索が行われてもよい。このようにすれば低演算量で画質を向上させることもできる。

図２６は、上述した実施の形態におけるコンピュータのハードウェア構成の一例を示すブロック図である。コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、記憶装置１０４と、ドライブ装置１０５と、通信インタフェース１０６と、入出力インタフェース１０７とを備える。

ＣＰＵ１０１は、記憶装置１０４に記憶されたプログラム１０８をＲＡＭ１０３を用いて実行する。プログラム１０８は、ＲＯＭ１０２に記憶されていてもよい。また、プログラム１０８は、記録媒体１０９に記録され、ドライブ装置１０５によって読み出されてもよいし、外部装置からネットワーク１１０を介して送信されてもよい。通信インタフェース１０６は、ネットワーク１１０を介して外部装置とデータをやり取りする。入出力インタフェース１０７は、周辺機器（キーボード、マウス、表示装置など）とデータをやり取りする。通信インタフェース１０６及び入出力インタフェース１０７は、データを取得又は出力する手段として機能することができる。ブロックサイズの決定に必要なデータは、記憶装置１０４に記憶されていてもよいし、プログラム１０８に含まれていてもよい。

なお、コンピュータの構成要素の一部又は全部は、汎用又は専用の回路、プロセッサ等やこれらの組み合わせによって実現され得る。これらは、単一のチップによって構成されてもよいし、複数のチップによって構成されてもよい。

上記の実施形態の一部又は全部は以下の付記のようにも記載されうるが、これらに限定されるものではない。

（付記１）
動き推定を行う動画像符号化方式のために、動き情報を保持する単位であるブロックサイズを決定する処理をコンピュータに実行させるプログラムであって、
予め定められた最も浅い階層のブロックを最大ブロックと呼び、
最大ブロックを分割してなる、予め定められた最も深い階層のブロックを最小ブロックと呼び、
現に着目している階層のブロックを現ブロックと呼び、
現に着目している階層よりも一階層深い階層のブロックをサブブロックと呼ぶとき、
最小ブロックそれぞれの動き情報を求めるベクトル探索処理と、
サブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一乃至複数のサブブロックを、ひとつの動き情報を有するひとつのブロックに統合するか否かを判定するブロック統合処理と
をコンピュータに実行させ、
最小ブロックよりも一階層浅い階層のブロックから最大ブロックの順に、ブロック統合処理を階層的に実行することにより、ブロックサイズを決定するプログラム。

（付記２）
前記統合条件はサブブロックの動き情報の他の情報を含み、
現に着目している階層における前記統合条件を、前記他の情報に基づいて決定する統合条件決定処理を更に含む
ことを特徴とする付記１に記載のプログラム。

（付記３）
前記他の情報は、現に着目している階層の深度であることを特徴とする、付記２に記載のプログラム。

（付記４）
前記他の情報は、現に着目している階層よりも深い階層におけるブロック統合処理の結果に係る情報であることを特徴とする、付記２に記載のプログラム。

（付記５）
前記統合条件は、隣り合うサブブロックの間の動き情報の差分と、予め定められた前記差分に係る閾値との比較に基づいて定められるものを含むことを特徴とする付記１乃至付記４のいずれかに記載のプログラム。

（付記６）
前記統合条件は現に着目している階層の深度を含み、
前記差分に係る閾値を現に着目している階層の深度に応じて定める処理を含む付記５に記載のプログラム。

（付記７）
現に着目している階層よりも深い階層におけるブロック統合処理の結果に基づいて、現に着目している階層におけるブロック統合処理の実行の要否を判定する処理を更に含むことを特徴とする付記１乃至付記６のいずれかに記載のプログラム。

（付記８）
動き推定を行う動画像符号化方式のために、動き情報を保持する単位であるブロックサイズを決定する方法であって、
予め定められた最も浅い階層のブロックを最大ブロックと呼び、
最大ブロックを分割してなる、予め定められた最も深い階層のブロックを最小ブロックと呼び、
現に着目している階層のブロックを現ブロックと呼び、
現に着目している階層よりも一階層深い階層のブロックをサブブロックと呼ぶとき、
最小ブロックそれぞれの動き情報を求めるベクトル探索処理を処理装置にて実行する段階と、
サブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一乃至複数のサブブロックを、ひとつの動き情報を有するひとつのブロックに統合するか否かを判定するブロック統合処理を処理装置にて実行する段階と
を含み、
最小ブロックよりも一階層浅い階層のブロックから最大ブロックの順に、ブロック統合処理を階層的に実行することにより、ブロックサイズを決定する
ことを特徴とするブロックサイズ決定方法。

（付記９）
前記統合条件はサブブロックの動き情報の他の情報を含み、
現に着目している階層における前記統合条件を、前記他の情報に基づいて決定する統合条件決定処理を処理装置にて実行する段階を更に含む
ことを特徴とする付記８に記載のブロックサイズ決定方法。

（付記１０）
前記他の情報は、現に着目している階層の深度であることを特徴とする、付記９に記載のブロックサイズ決定方法。

（付記１１）
前記他の情報は、現に着目している階層よりも深い階層におけるブロック統合処理の結果に係る情報であることを特徴とする、付記９に記載のブロックサイズ決定方法。

（付記１２）
前記統合条件は、隣り合うサブブロックの間の動き情報の差分と、予め定められた前記差分に係る閾値との比較に基づいて定められるものを含むことを特徴とする付記８乃至付記１１のいずれかに記載のブロックサイズ決定方法。

（付記１３）
前記統合条件は現に着目している階層の深度を含み、
前記差分に係る閾値を現に着目している階層の深度に応じて定める処理を処理装置にて実行する段階を含む付記１２に記載のブロックサイズ決定方法。

（付記１４）
現に着目している階層よりも深い階層におけるブロック統合処理の結果に基づいて、現に着目している階層におけるブロック統合処理の実行の要否を判定する処理を処理装置にて実行する段階を更に含むことを特徴とする付記８乃至付記１３のいずれかに記載のブロックサイズ決定方法。

この出願は、２０１４年８月２８日に出願された日本特許出願特願２０１４−１７３６９８を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ブロックサイズ決定処理
２−６ブロック統合処理
１００コンピュータ

Claims

コンピュータに、
予め定められた最も深い階層のブロックである最小ブロックのそれぞれの動き情報を求めるベクトル探索処理と、
動き情報を保持する単位であるブロックサイズを決定するブロックサイズ決定処理と、
現に着目している階層よりも一階層深い階層のブロックであるサブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一又は複数のサブブロックをひとつの動き情報を有するひとつのブロックに統合するか否かを判定するブロック統合処理とを実行させ、
前記ブロックサイズ決定処理は、最小ブロックよりも一階層浅い階層のブロックから予め定められた最も浅い階層のブロックである最大ブロックの順に、前記ブロック統合処理を階層的に実行することによりブロックサイズを決定する
動き推定を行う動画像符号化方式のためのプログラムを記録したコンピュータ読み取り可能なプログラム記録媒体。
前記統合条件は、サブブロックの動き情報の他の情報を含み、
現に着目している階層における前記統合条件を、前記他の情報に基づいて決定する統合条件決定処理を更に含む
ことを特徴とする請求項１に記載のプログラム記録媒体。
前記他の情報は、現に着目している階層の深度であることを特徴とする、請求項２に記載のプログラム記録媒体。
前記他の情報は、現に着目している階層よりも深い階層における前記ブロック統合処理の結果に係る情報であることを特徴とする、請求項２に記載のプログラム記録媒体。
前記統合条件は、隣り合うサブブロックの間の動き情報の差分と、前記差分に係る閾値との比較に基づいて定められるものを含むことを特徴とする請求項１乃至請求項４のいずれかに記載のプログラム記録媒体。
前記統合条件は現に着目している階層の深度を含み、
前記差分に係る閾値を現に着目している階層の深度に応じて定める処理を含む請求項５に記載のプログラム記録媒体。
現に着目している階層よりも深い階層におけるブロック統合処理の結果に基づいて、現に着目している階層における前記ブロック統合処理の実行の要否を判定する処理を更に含むことを特徴とする請求項１乃至請求項６のいずれかに記載のプログラム記録媒体。
予め定められた最も深い階層のブロックである最小ブロックのそれぞれの動き情報を求め、
動き情報を保持する単位であるブロックサイズを決定し、
現に着目している階層よりも一階層深い階層のブロックであるサブブロックの動き情報を少なくとも含む統合条件に基づいて、互いに隣接する一又は複数のサブブロックをひとつの動き情報を有するひとつのブロックに統合するか否かを判定し、
前記ブロックサイズを、最小ブロックよりも一階層浅い階層のブロックから予め定められた最も浅い階層のブロックである最大ブロックの順に前記判定を階層的に実行することにより決定する
動き推定を行う動画像符号化方式のためのブロックサイズ決定方法。
前記統合条件は、サブブロックの動き情報の他の情報を含み、
現に着目している階層における前記統合条件を、前記他の情報に基づいて決定する
ことを特徴とする請求項８に記載のブロックサイズ決定方法。
前記他の情報は、現に着目している階層の深度であることを特徴とする、請求項９に記載のブロックサイズ決定方法。