2005年10月05日

妖精現実さん9/2の記事コピペ::[SNOW] SNOW と x264

概要:[SNOW] SNOW と x264
関連エントリ:
妖 精現実さん8/31の記事コピペ::[SNOW] 5/3 wavelet 2パス で XviDには勝てるが…
妖 精現実さん9/3の記事コピペ::[SNOW] オプション検証メモ
タグ:[SNOW][libavcodec][mkv]


2005年9月2日

時間の関係で走り書き、不確実な要素あり。あとからちゃんとまとめます。 下のコマンドラインは1時間足らずで検証できるはず。 フィードバックは掲示板にお願いします。

世の中は、H.264だ。 DVDの後継メディアに採用、と有利な立場だし、実際、アニメには強い。 しかし、AVC一色になるのは、おもしろくない。オーディオだって、AACだけで Vorbis がなかったら、つまらないだろう。

AVCは強敵だが、無敵ではない。 まずOn2のコーデックはVP7に来て、あなどれないし、完成度も比較的高い。 単純にPSNRをとったらx264より上かもしれない。 VfWなので、使い方も容易だ。 プロプライエタリだが…。

心理的な抵抗感を別にすればRV10もある。これも既にけっこう紹介した。 技術的なこととは無関係に、 Realは実に心理的抵抗感があるのだが、最近Appleをハックしたり半面、結構体質が変わったのかな…& hellip;と思う部分もある。 ffdshowのAACデコーダもRealになった。 FAAD2がNeroに買収されGPL非互換になった結末だが、あのムカツク(と思っていた)Realに助けられるとは皮肉だ。

オープンソースのビデオコーデックといえば、 前から有名なのは Theora だ。 元はOn2のVP3だが、Theora はオープンソース。 alpha3 のころ検証した。 そろそろ新しいバージョンを検証すべき時期ではあるが、とりあえずまだアルファで、発展途上だ。

同じくオープンソースの Dirac は完全フリーであり、大きな可能性を秘めているが、これはさらに発展途上だ。 拡張子drcにてMPCでそのまま再生できるのが便利と言えば便利だが、完成度はまだまだ。 sfではDirectShowのスプリッターがときどき更新されるのだが……。

オープンソースのSNOWはどうか。以前、1パスのテスト結果を紹介して「異様な美しさ」とか書いたが、 あのときはテスト版以前で、いわば全フレームがIのようなエンコードをしていて、サイズがでかすぎ実用にならなかった。 当時のVfWでやったせいもある。 今回のテーマは、mencoderでSNOWの2パスをやり、その可能性を探る、ということだ。

内輪ではSNOWは期待されている。その気分を端的に言えば、 次のようなAVC技術批判になるだろう。 「自分で発 生させたブロックノイズを自分で検出して補正をかけるのは、 何もしないよりはずっといいとはいえ、失敗を前提とするアルゴリズム。 DivX3ナンダブ時代のベリノイズとアンチシットの関係から本質的には進歩していない。 基本のアルゴリズムを変更して、最初からブロックノイズが出ないウェーブレット変換を全体のベースに使うべき

さらにまた(論理的にはちょっとおかしい主張なのだが感覚的に)「Jpeg2000と同じこと」 「AviUtl のフィルターでもウェーブレットのやつは重いけどすごいでしょう」 「MPEGは特許特許とうざいんだ よ」 といったところ。 自分たちだけの勝手な意見、というわけではない。 例えば、MeGUI もAVCとSNOWをサポートしており、doom9氏もSNOWをAVCと並びうるものと見ているようだ。

x264も 開発初期ではあるが、 更新回数(リビジョン)も300に近づき、 既にそこそこ安定している。 効果も素晴らしく、実装もいいのだろうが、さすがはAVC、というところだ。 しかし、デブロッキングに関しては不安もある。 ffdshow にデコード時にデブロッキング指令を強制的に無視するオプションがつけられてしまうほど、賛否両論を招いている。 x264の完成度の問題もあると思うが、たぶんAVCの根幹の問題だろう。 はっきりいってデブロッキングし ないとAVCは使い物にならない。 アニメで良ければどうでもいいようなものの、実写の映画の肌のきめとか植物のテクスチャーはかなりやばいのでは…。 ちなみに、このインループフィルターは、みなさんが大嫌いなRV10の「のっぺり感」と通じる。 RV10もオプションでインループフィルターを使っている。

一方のSNOW はアルファで、さらに開発初期であり、クラッシュしたり、変なアーティファクトが出たりするが、 それにもかかわらず既にx264に迫るものがある。 今はx264に少し負けるし、x264に比べて重いが(特にqpelを使った場合)、 開発が進めば、いい線行くのではないいか。これか Dirac か、少なくともどっちかが成功……してほしい。 デブロッキングの議論の裏返し て、 SNOWは本当のところアニメより実写に強いのだが、ウェーブレット系は基本的に輪郭を保ったままのっぺりした部分を真っ平らにできるので、 結局アニメにも適合するはずだ。

というわけで、比較テストです。 昨日アップしたやつと比べて、x264のインループフィルターを0:-1→0:3に変えた。こっちの方が良かった。3:3も同じくらい 良い。 レートが異常に高いのはOPだからです。

Huffyuv RGB 圧縮前のソース。 リージョン2DVD(アナモルフィックでない)を普通にフィルターした640x480。 もとが既にMPEG-2なので実験として理想的でないが、現実的には最もよくあるパターンの一つだろう。

SNOW と x264 x264の方が「きれい」だが少しのっぺりしている。 事実ソース自身にあるノイズまで隠している。この場合には結果オーライだが……

XviD: 1.1.0 beta2, 2200.4 kbps: 2-pass: MPEG, VHQ4 (also for bvop), qpel, Chroma, Trellis, No Turbo, No Cartoon mode
圧縮時間、再生時負荷、安定性などトータルでのコストパフォーマンスは最高のXviD。 300%で1コマずつ調べると微細なブロックノイズが出てるが、ハイモーション・シーンでこの程度は実際にはそれほど目立たない。 コマンドラインが書いてないのは、XviDはVfWで作成しているからで、書いていないところは、 デフォルト。特に、VfWのXviDで最大連続Bフレームのデフォルトは2だ。 ネイティブMPEG-4モードでどうなるかは今後の研究課題だが、 今回 XviD はMPEG-4 Part2の最高の実装例として、Part 10と比較する参考に出しているだけで、 XviD の部分はあまり真剣にとらないでほしい。 ところで、世の中にはAVIにBフレームを入れるのは邪道だ、という純粋主義者もいる。 その意味は分からないでもないが、XviDをAVIに入れるのは確立した技術であり、 Linux上でさえVfW互換モードが一般的なので、実質的にはネイティブMPEG-4を使う意味はない。 他方、AVCをAVIに入れるのが邪道かどうかは意見が分かれるところだが、 AVIに入れるのが技術的に難しいのは確かで、現状、AVIではフルスペック使えない。 最近、ffdshowがときどき2バージョンある最大要因の一つは、 ややこしいオプションを使ったAVC-in-AVIがノーマル版でクラッシュしてMSVC版でクラッシュしない、という際どい状態にあることだ。 ここでは素直に.mp4に出している。ちなみに、実は.264で出してからmuxした方がさらに安全だ。 x264から出した.mp4はQT7で再生できないので何か問題がある。ただし音声がMPEG-2 AACでは、どのみちQT7で再生できない。 FAACで生のAACを作るとデフォではこのパターンになるので注意を要する。QT6から全然直ってない。ウェブのネスケ4並に迷惑だ。

SNOW: dev-CVS-050813-01:18-3.4.4, 2199.9 kbps: 2-pass: cmp=SSD+Chroma, pred=5/3 wavelet, last_pred=3, qpel, v4mv
細部のテクスチャが冴えているが、再生時負荷もものすごい。ソフトカラオケと合わせると、P4 3G+で100%サイズでさえコマ落ち。 現在のマシンではウェーブレットのqpelはきつい。(MPCで字幕のバッファリングを切って、さらにソフト側でtrue colorにするということ。 普通にオーバーレイで字幕もなければ、そこまで重くない。)

x264: revision291: 2198 kbps: 2-pass: me 6, umh 64, bframes 6, pyramid, ref 15, analyse all+8x8dct, temporal, weightb
x264は軽い。全画面でソフトカラオケもできる。XviDのようなブロックノイズは消されていて一見きれいだが、デブロッキングでのっぺり、と両刃の 剣。 アニメだとあまり気にならないが。

XviD は一応の最善設定だが、300%に拡大すると、微細なブロックノイズが確認できる。 MPEGの宿命で仕方ない。 ウェーブレット・ベースのSNOWには、この問題はない。 x264と、ほぼ互角だが、再生時負荷が違う。SNOWに比べるとAVCははるかに軽い。 SNOWが実用的になるためには、全般的な安定はもちろんのこと、 再生がx264と同程度まで軽くなってほしい。 そうなったあかつきには、ffdshowを入れるだけで再生できるのでx264より手軽になる。 x264もVfWモードならffdshowだけで再生できるが、それは本道ではない。 他方、SNOWはもともとlavcだ。NUTに入れたいというマニアもいるが……。

実写はデブロッキングと相性が悪いが、アニメはデブロッキングと相性が良いことから、 基本的に、アニメではAVCが有利。とはいえ全然未完成のくせに、完成度の高い XviD を越えられる SNOW は前途有望だ。

まだ基本的な部分もできてないSNOWだが、特に13/7 waveletはバグだらけで画面が破綻、まったく使い物にならない。 比較関数はSSDかSAD。比較関数の5/3 waveletと9/7 waveletは良くない。 SSDの方がSADよりわずかに良い感じだが微妙。

「9/7 waveletのqpelオン」が最善手とも思えるが、残念ながらコーデックのバグで正常動作しない。 chroma motionのオンオフと無関係にv4mvがオフのとき、qpel有効ではエンコードに失敗する。 qpelかつv4mvではエンコードはできるが、 9/7 waveletを使った場合、横の点線または、青い横の実線のアーティファクトが散在、実用にならない。 つまり事実上、9/7 waveletではqpelが使えない。 9/7 waveletのqpelオフも、コントラストが強い横エッジにそって横線アーティファクトが出る。 消去法で、5/3 wavelet(+qpel)(+v4mv)(+chroma motion) しかない。

アニメ特有かもしれないが、2パスで同じサイズに作った場合、フレームによっては、qpel無効の方が良くなるケースがある。

実験はmplayer2005.08.13で行った。 比較サンプルは配布しないが、 下にコマンドを書いておくので、 アニメの1分半のOPを映像のみ20〜30MBくらいで作って、XviD などと比較したら良い。

@rem SNOW <1st Pass>
mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:pred=1:cmp=257:subcmp=257:mbcmp=257:last_pred=3:qpel:v4mv:vqscale=2.0 -of avi -ffourcc SNOW -o "snowq2.avi"

@rem SNOW <2nd Pass>
mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=2:pred=1:cmp=257:subcmp=257:mbcmp=257:last_pred=3:qpel:v4mv:vbitrate=2200 -of avi -ffourcc SNOW -o "snow.avi"

@rem x264 <1st Pass>
x264 --pass 1 --keyint 240 --min-keyint 6 --bframes 6 --b-pyramid --ref 15 --filter 0:3 --bitrate 2200 --qpstep 12 --vbv-maxrate 10000 --stats "stats.log" --analyse all --8x8dct --direct temporal --weightb --me umh --merange 64 --subme 6 --cqm flat --fps 23.976 --progress -o NUL "input.avs"

@rem x264 <2nd Pass>
x264 --pass 2 --keyint 240 --min-keyint 6 --bframes 6 --b-pyramid --ref 15 --filter 0:3 --bitrate 2200 --qpstep 12 --vbv-maxrate 10000 --stats "stats.log" --analyse all --8x8dct --direct temporal --weightb --me umh --merange 64 --subme 6 --cqm flat --fps 23.976 --progress -o "output.mp4" "input.avs"


x264の例で、このモードではたぶん --vbv-maxrate は無意味だが一応。 デブロッキングを0:3にしたのはデフォルト(0:0)ではアーティファクトが出たためで、 最初0:-1を試した。その後、実験的に0:-3と0:3も試したところ、このアニメでは0:3が最良の結果だった。(3:3も同じくらい良好。)



メモ
  1. x264は設定次第ではQuickTime7で再生に問題が起き得る。これは現状、MacOSXではMPLayerかVLCを使 う他に対応手段がない。
    1. 原因はQuickTime7のAVCサポートがx264に追いついていない事(たぶん)
    2. たかだかb_frames=1で加工できなくなるなんてしょぼすぎる。(TV録画のエンコード目的にとっては)
    3. x264+aac.mp4の常用は、MEncoderの進化(-of lavf)または、ffmpegX(MEncoder+ffmpeg +mp4box)の進化を待つべき。
    4. その間ヒマなので、MEncoderのコマンド訳すとか、mp4box習得するとかして遊ぶ。
  2. SNOWはlibavcodecの一部なので、MEncoderに内蔵されている。
    1. 何事にも"プランB"は用意しておくほうが良い。
    2. libavcodec(≒ffmpeg)がAVCコデックを作っていないとゆうことは、ひょっとして、MEncoder開発 チームも「特許でがんじがらめの」.mp4対応には興が乗らない鴨。
    3. xvidから入ったからlibavcodecはノータッチなんだよなぁ、、、。
posted by ばる at 23:53| Comment(0) | TrackBack(0) | mencoder | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス: [必須入力]

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/7759712
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。