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負荷も問題にならないはずです。
