ffmpeg /
-obmc
妖精現実-Baka Memo-2006年3月からコピペ。
著作権等については妖精のライセンス参照
OBMCについて †
具体的な実装の細部までは分かりませんが、概念的にはだいたいこういうことだそうです。
DivX、XviDなどの動画で、ビットレートが足らないときなど、もともとそんなものはないのに、
マス目状の線が出てしまうのは、よく見かけると思います。
ブロック単位に分割してから各ブロックを処理しているので、
ブロックの中身をきめ細かにしてとなりのブロックと滑らかにつながるようにできるだけの情報量がないと、ブロックの境界の線が目立ってしまうわけです。
MPEG-1ではブロックのサイズが固定（のっぺりしていておおざっぱに切ればいいところも同じに切るし、
複雑なところで繊細に処理してほしいところでも細かく切ってくれない）なのですが、
新しいコーデックでは、ブロックサイズを都合に合わせて動的に変えたり、長方形にしたり…と、
これはx264（AVC）のユーザなら、設定の検索オプションのところで、いっぱい種類があるのをよくご存知と思います。
しかし、可変ブロックであっても、ブロック境界があることには変わりないので、
効率は上がったとはいえ、原理的にブロックノイズが回避できているわけでは全然ないわけです。
AVCやWMVやRV10では、それを緩和するために、インループ・フィルターをかけています。
特にRV10ではインループが明示的に設定できるので、気が付いた方も多いと思いますが、
自分がエンコードした結果を自分で（エンコード中に）デコードしてみて、
ブロックノイズの原因になる誤差が蓄積していないか確認し、必要に応じて補正をかけるわけです。
AviUtlなどのノイズフィルターなどは、コーデックに行く前にかけるプレフィルターですし、
ffdshowなどの後処理はコーデックから出てきたデコード結果を調整するものですが、
インループは前でも後でもなくコーデック自体の中でかけているフィルターです。
しかし、このデブロッキングというのは、案外、実写とは相性が悪いです。
ブロックノイズが出ない代わり、繊細なテクスチャー、人の肌のきめなどがツルンとしてしまいます。
ただ、たいていのアニメでは、もともとツルンとしているので、この（本来は欠点の）性質がかえってランダムノイズを消して、
良い感じになってくれます。実際、ソースのノイズがデブロッキングの副作用（副作用の副作用？）で勝手に消えてくれることさえあります。
とはいえ、自分で発生させたブロック境界を消すための補正情報にレートを回すのは、巧妙ですが、
本質的には無駄です。自分でノイズを作っておいて、それの消し方をコーディングするわけですので。
最初からブロック境界がなければそういう二度手間にならず、
自分で汚したものを直すのに必要な情報量を、本質的なテクスチャーに回すことができます。
で、SNOWが実装したOBMCですが、
OBMCは、本当はh263にも規格上はあったそうなのですが、実際には使われなかったようです。
GMC同様h264では規格から外されてしまいました。
名前のとおり、オーバーラップしたブロックの動き補償です。
碁盤の目のようにきっちり切るのでなく、
各ブロックが少しずつ（上下左右斜めの8方向とも）重なって定義されています。
言い換えれば、古典的な切り方での境界付近のピクセルは、実は両側のブロックに属しているわけです。
一般に、各ピクセルは4ブロック（実装によっては3ブロック）に同時に属し、それらの加重平均をとることで、
区切りの線が目立たず「とろんと」滑らかになります。段差ができる原因が最初から回避されているわけです。
段差を補正するインループ回路も確かに巧妙で効果的ですが、最初から段差ができないようなブロックを重ね合わせた取り方、
というのは本質的に素晴らしい発想でしょう。ただ、一つのマクロの動きを何重にもコーディングして、
デコードのときにも重ね合わせて平均をとるので、計算量（CPU負荷）の問題はありますが、
まあ、少し未来にはハードが発達して何とかなるのではないでしょうか。
「波」の重なりで図形を表すウェーブレットも、
そうした従来型のアーティファクトを克服するのに貢献するはずです。
まあ、これも計算量が大変そうですが…。
開発者の方から説明してもらったことを生半可な理解で受け売りしているのでちょっと（かなり）間違ってるかもしれませんが、
あのSNOWの「とろん」とした雰囲気と異様な美しさは、だいたいそんなような感じ…らしいです。
そして、その計算がたいへんというのは、計算量が多くてもリニアの計算なので、
GPUでハード的に実装するのは原理的には簡単らしいです。そうすればCPU負荷も問題にならないはずです。
