x264guiEx 0.14

少し機能の追加。

要x264guiEx.ini更新。

続きを読む

続きを閉じる

一時ファイル管理法の拡張
なんとなく簡単にやる方法を思いついたのでやってみた。

・エンコード中の一時ファイル名置き換え。
・一時ファイルを作成する場所を選択できるようにした。

一時ファイル名置き換えとは、
エンコード中に作成する一時ファイル名について、
x264guiEx.iniの記載に従って
ファイル名(ディレクトリは含まない)の文字列を
置き換える。最終的に出力ファイル名はきちんと戻す。

手抜きmp4boxの"#"問題への対策。
一時ファイル名を
"#"(半角)から"＃"(全角)に置き換えるよう
x264guiEx.iniに書いておいた。

一時フォルダの場所を変更するのは、
個人的にはあんまり要らないと思うけど、
一時ファイル名置き換えを作ったら、
簡単に一時フォルダも変更できそうなので
やってしまっただけ。

mp4boxを使うときは、
ディレクトリ(フォルダ)は#を含まないように。

ほかにもなんか"ダメ文字"があれば
この置き換えをiniに書くで対処できる。
ランダムファイル名は個人的に嫌いなので、使いません。
(実はもう数行書けばできる状態だけどね)

いやまあ、ファイル名だけ置き換えとかちょっと中途半端な感じはしなくもないけど、実際使う分にはこのくらいで十分だと思う。一時フォルダも指定できるし。

ファイル名置き換えは、「～の方法はきれいじゃないから嫌い」だとか言っておいて「お前のやり方もきれいじゃねーだろ」と思うかもしれないが、許しておくれ。ま、こういうのは人それぞれ好みがあるでしょう。


その他

・動画出力やmuxをスキップし、音声エンコードのみをするモードを追加。

音声エンコードだけやり直したい場合に。x264guiでは、動画エンコードを中断したら、音声エンコードに入ったけど、それをやめてしまったので。


・x264guiEx.iniにoggenc2用設定を追加。mkv専用。



ダウンロード>>

2011冬アニメ その1

その1ってタイトルだけどその2があるかは知らん。

とりあえず、
・君に届け(2)
・IS <インフィニット・ストラトス>
・夢喰いメリー

を見た。ウチはまだこんだけ。Rioとか話題になってるみたいだけど面白いのかな？

ちなみに上の3つは今後も見てみようかなと。
君に届けは1期から見てて好きだし、ISは原作も読んでるし、あーゆーの好きだし。メリーはよくわかんないけど、とりあえず見ようかなと。

エンコード的にはみんなHDでよかった。よかったんだが…

君に届けはEDではまった。EDの部分24fpsじゃないとは。

私はこういうフレームレート関連はあんま詳しくないし、テロップのフレームレートとかは気にせず自動フィールドシフトで処理してしまうけど、さすがに君に届けはやり直したorz

そのうちまたうっかりしてやり直しになりそうでいやだ…

画質比較 - x264、CUDA、ほか

GTX460も買ってしまったことだし、画質の比較をしてみる。

もうTMPEGEnc VMW 5 体験版の期限も迫っているし…ね。

えと、あらかじめ言っておくと、画像を貼りつけまくったので、もしかすると重いです。

続きを読む

続きを閉じる

まず、環境とか基本的なところの説明から。

【環境】
OS : Win7 x64
CPU : Xeon W3680 (6C/12T, L3=12MB) @ 4014MHz
メモリ: 12GB
GPU : GTX460
念のため書いておくと、この環境だとマルチスレッド効率が低いものは遅くなってしまう。

【入力データ】
例によって Little Busters Ex のOPデモ版。
解像度 : 800x600p
fps : 30.000fps
フレーム数 : 6891 frame (約 3分49秒)
音声 : 出力しない

フィルタは全くかけず、そのままエンコードする。

そいで、平均レート1000kbpsになるようにエンコードして、その画質と速度をチェックしてみる。基本的に1passVBRを使って品質を変えながら1000kbpsになるようにエンコードするという、実にめんどくさいことをやってみた。2passを使えばいいようなもんだが、2passだと1passと違った様子が出てくるかもしれないので、今回はあくまでも1passにこだわった。

この動画(リトバスExOP)を1000kbpsってのは結構厳しいので、どうなることやら…

画質の比較には4635frame目の左上400x300の部分を使う。


試したソフトウェアは…

Aviutl0.99i8 + x264guiEx 0.13 + x264.exe r1834
TMPEGEnc Video Mastering Works 5 体験版 (v5.0.1.19)
TMPEGEnc 4 XPress (v4.7.8.309)

あとはCUDAが使えるらしいので…
MediaCoder 0.7.5

ほかにも次の3つはCUDAが使えるというのだが、あきらめた。理由は…
PowerDirector9はなぜか自由に解像度を指定できないので800x600出力ができないorz　なんか640x480,720x480,1280x720などいわゆる「一般的な解像度」からしか選べない…論外。

MediaEspresso6はなんと動画ファイルを「インポートできません」ってんなアホな。ただのMPEG1動画なのに…私の使い方が悪いのだろうか…

badaboomはどうやらGTX4xx(5xx)のfermi系列には対応してないらしい。なん…だと…


そういやTMPEGEnc VMW5体験版がアップデートでx264 の --min-keyintに対応した。最小GOP長。私はこれを小さめの4とかにしないと気が済まないので、うれしい限り。(keyintの1/10とかねーよ)

---

その1

まずはAviutl + x264guiEx + x264.exe と TMPEGEnc VMW5 x264エンコーダ で比較してみる。だいたい似たような感じになるはず。ただまあ、体験版っていう透かしが入るので、厳密に同じではないが…

・Aviutl + x264guiEx + x264 HQ
・Aviutl + x264guiEx + x264 LQ
・TMPEGEnc VMW 5 + x264 HQ
・TMPEGEnc VMW 5 + x264 LQ

HQとLQというのはx264オプションの設定の違いで、HQは高画質・低速、LQは低画質・高速寄りの設定。

とりあえず、ビットレート。

約1000kbpsである。



つぎに、速度。

HQとLQでは大きな差があり、またTMPEGEncとAviutlではわずかにAviutlのほうが速い。これは透かしを焼きこむ分などが影響しているかもしれないし、違う原因かもしれない。

で肝心の画質比較。
まず元画像。


次にAviutl HQ。


TVMW5 x264 HQ。


Aviutl LQ。


TVMW x264 LQ。


わかりにくい場合は、画像を新しいタブで開き、タブを切り替えながら見ていくとよいと思う。
まず、originalと比較すると、当然エンコード後は一部ぼけてしまっていることがわかる。

HQ同士、LQ同士をそれぞれ比べると、ほぼ似たような画質だが、若干Aviutl+x264のほうが高画質な気がする。

HQとLQで比べると、これもまた若干だがHQのほうがきれいに見える。左下の葉のボケ具合や、右上のクドの腕の下あたりがわかりやすいだろうか。

まあでも、オプションをそろえてやれば、ほぼおなじ結果になるということがわかる。当然といえば当然だが、一応これは示しておきたかった。

あとx264は設定次第で、かなり高速にもできるし、逆に時間をかけて高画質にできる、ということもわかる。

---

その2
がんがんいこうぜ。

比較するのは
・TMPEGEnc VMW5 x264 HQ
・TMPEGEnc VMW5 x264 MQ
・TMPEGEnc VMW5 x264 LQ
・TMPEGEnc 4 XP MainConcept H.264
・TMPEGEnc VMW5 wmv
・TMPEGEnc VMW5 Divx
・TMPEGEnc VMW5 CUDA H.264
・MediaCoder CUDA H.264

例によってHQ,MQ,LQの違いはx264のオプションの差。最後に細かいオプションを書いておいた。

TMPEGEnc VMW5 CUDA H.264はVBRだとエラーで止まってしまうので、残念ながらCBR。


まずは、ビットレート。だいたい1000kbpsにそろえたよ、ということ。


次にエンコード速度。


速度についてはCUDA無双。そんなに高速で大丈夫か？
だが設定次第ではx264も速い。wmvやdivxはマルチスレッド効率が悪く6C/12Tを使いきれていない。CPU使用率がずっと低いままだった。そのためCPU使用率が高めだったx264と比べ、相対的に遅くなってしまった感がある。というよりx264のマルチスレッド効率の高さが優秀すぎるのかもしれない。

さて、画質チェック。
オリジナル


TVMW5 x264 HQ
かなり良い画質。


TVMW5 x264 MQ
HQより全体的に少しボケぎみである。


TVMW5 x264 LQ
MQと比べると、左下のほうがさらにぼけている。


TMPEGEnc4 MainConcept H.264
悪くはないんだが、よくもない。割とボケぎみ。


TVMW5 wmv
かなりぼけている。


TVMW5 Divx
wmvとは少し違った画質劣化で、ボケるというよりは細かいブロックやノイズが見える。


TVMW5 CUDA H.264。
ボケボケなうえ、でかいブロック状のものが見える。(左のほう)


MediaCoder CUDA H.264。
左のほう特大の変なブロックが見える…どっからきた…



わかりにくい場合は、やはり画像をタブで開き、タブを切り替えながら見ていくといいと思う。

で、わかってはいた(っていうか予想はしていた)ことだが、CUDAエンコの画質残念杉。これは静止画での比較だけど、動画で見てみるともっと動きの大きいところでは、猛烈に破たんする。

TMPEGEnc VMW5のCUDAは、そもそもCBRとVBRしかない(しかもVBRは止まってしまうのでCBRしか使えなかった)のが問題で、品質基準がない点は問題。MediaCoderのCUDA H.264は量子化量(QP)を指定できるけど、画質的にはTMPEGEnc VMW5のCUDAより悪くなっている。その他のソフトのCUDAエンコーダは使えなかったし…

ハードウェアエンコというと、あとはSpursEngineとかあるけど、あれもPowerDirector9同様、自由に出力解像度を設定できなかったような気がする(持ってないのでわかんないけど)。画質もそんなによくはない…らしいし。

話が少しずれるけど、ほかのエンコードソフト使ってみて思ったのはTMPEGEncはやっぱり使いやすいし、いろいろ便利だということ。MediaEspressoとか読み込んですらくれないし…

あとハードウェアエンコというと、TMPEGEnc VMW5の対応しているSandyBridgeのハードウェアエンコかな…ここ(リンク>>)にIntel Media SDKを使ったレビューが載っていて、x264の2倍速いよ的なことが書いてあるけど、x264の設定はどんな風なのかとか、エンコード後の画質はどうなのかとか全く触れてないから、ほとんど参考にならない。x264の速度なんて設定次第でどうとでもなるんだし。ぶっちゃけ--me tesaとか--ref 16とか使えばいくらでも遅くできる。もちろん、これはCPUのレビュー記事で、SandyBridgeでこんなこともできるっていう紹介ができているのだからこの記事としては十分だろうけど。

というわけで、やっぱx264は優秀なんじゃないだろうか。速度と画質のバランスはオプションで結構自由に設定できるし。うん。え…オプションが多すぎてわからん？「パフォーマンス」の「やや遅い」とか「やや速い」とか使いましょう。だいたいはそれで大丈夫で問題ない。

GPUはフィルタリングかな、やっぱり。私はAviutlでノイズ除去フィルタnl-meansのGPU版でGPUを使おうと思う。

ここまで読んでくれた人、長文読んでくれてありがとうです。

---

おまけその1。

BitrateViewerでビットレートの分布が見える。いずれもクリックで拡大。

TVMW5 x264 HQ


TVMW5 x264 MQ


TMPEGEnc 4 MainConcept H.264


TVMW5 Divx


TVMW5 CUDA H.264。CBR…だなあ、やっぱり。VBRはどうして動かないんだか…


MediaCoder CUDA H.264


こうしてみると、x264は若干メリハリのついた容量配分になっているようだ。



おまけその2

あとは参考程度にx264のHQ,MQ,LQのオプションをコマンドライン的に書いておく。色空間とかのオプションは省略。

HQ
かなり重めの設定。
--preset slow --crf 23 --aq-mode 0 --qcomp 0.7 --rc-lookahead 60 --scenecut 60 --min-keyint 4 --keyint 300 --subme 9 --merange 32 --ref 6 --trellis 2 --no-fast-pskip --no-dct-decimate --nal-hrd vbr --vbv-maxrate 17500 --vbv-bufsize 17500

MQ
本当は--me umhをつけたほうがいいかもしれないけど…
--preset fast --crf 23 --aq-mode 0 --scenecut 60 --min-keyint 4 --keyint 300 --ref 4 --nal-hrd vbr --vbv-maxrate 17500 --vbv-bufsize 17500

LQ
やたら速い。
--preset veryfast --crf 23 --aq-mode 0 --partitions p8x8,b8x8 --scenecut 60 --min-keyint 4 --keyint 300 --bframes 2 --b-pyramid 0 --mixed-refs --ref 2 --nal-hrd vbr --vbv-maxrate 17500 --vbv-bufsize 17500

あとは--crfをいじって1000kbpsに近づくよう調整。

x264guiEx 0.13

v0.12で音声のエンコードとmuxが失敗する問題を修正。

報告をくださった方々、ありがとうございました。おかげで助かりました。


ダウンロード>>
(2011.01.06 追記)バージョン情報が0.12のままだったのを修正、差し替えました。


ほんと気づいてみれば、アホみたいなミスだった。

そもそも失敗して当然だったのだが、なぜか私の環境では動いてしまっていて、なかなか気付けなかった。そいでXPModeを使ってやっとわかったという次第。

買っちまった…

秋葉でGPUを買っちまった。
MSIのN460GTX Cyclone 1G OC/D5ってやつ。
つくもたんクリアファイル&紙袋がついてきた。

こいつはカード長が短いところがいい。(入れるPCケースが小さいので)

で、Radeon HD 4350 と入れ替えたんだけど、

1. Aviutlフィルタ nl-means GPUが速い。
2. TMPEGEnc VMW5のCUDAエンコードが速い。画質は残念すぎるが。
3. ゲーム? しないがなにか?
4. TMPEGEnc VMW5のCUDAフィルタはまだ試してない。

まあね、2はわかってはいたよね、うん。

ただ 1は嬉しい限り。

x264guiEx 0.12

新年早々ですけど、更新。

続きを読む

続きを閉じる

x264guiEx 0.12。
FAW関連でx264guiEx.iniも更新が必要。


・指定された画面比から、自動的にSAR比を計算するモードを追加。

「とにかくこの映像は x:y(普通16:9とか4:3)で見るんじゃ！」っていう画面比を指定して、エンコード時に解像度から自動的にSAR比を計算してx264に渡す。もちろんこれまで通り、--sarの直接指定も可能。自動計算を作ったのは、1440x1080エンコするときにいちいち--sar 4:3に設定するのが面倒になってきたから。


・FAW処理とFAWCheckにおいて、FAWの1/2サイズに対応。
1/2サイズ使えませんか～というご意見があったので。

外部音声エンコーダFAWのプリセットに1/2サイズ用を追加。FAWの1/2サイズを使用する際は、1/2サイズ用プリセットを選択するか、あるいはFAWCheckを使用する。

FAWCheckを使用した際は、自動で1/2サイズかどうかを判定し、プリセットも自動選択される。プリセットの順番は最初にフルサイズ用、2番目にハーフサイズ用としている。FAWのプリセットの順番をiniで変えてしまうと、FAWCheckを使おうとするときにx264guiEx.iniの更新を求めるメッセージが出る(ので順番を変えないでください)。


・視覚スタイルを適用してみた。まあ、私の趣味だけど。

なんで適用されないのかな～ってずっと思ってて、ちょっと調べたらすぐわかった。ツールチップのフェードはさすがに鬱陶しいので切っておいた。視覚スタイルが嫌いな人もいるってのは知ってるけど、そういう人はOSごと切ってるだろうから、適用してみても問題ない…と思う。


・ツールチップに選択されたx264.exeのバージョン情報を表示。

ただ単に x264 --version の標準出力を取得してるだけ。
x264 0.112.18xx～～とかいうやつがツールチップに出る。


・自動マルチパス時、2pass目以降のAviutlのキーフレーム探索とqpfile作成をスキップ。

よく考えたら必要ない。


・名前空間がx264guiのままだったのでx264guiExに変更。


・ほかにもエラー表示とか変えた気がする。(もう覚えてない…)


ダウンロード>>

---

【画面比を指定し、SAR比を自動計算】について

Readme_rigayaに説明を書いたので、コピペ。

x264のアスペクト比の指定はSAR(Sample Aspect Ratio)で、ようはピクセル(画素)のアスペクト比を指定するようなもんです。なので「とにかく16:9でみるんじゃ！」というような指定方法ではありません。そのため計算が必要です。

--sarの計算方法は次のようになっています。
--sar sar_x:sar_yのように指定するとします。
さらに再生時の画面比を a x b として、
動画の解像度を W x H とします。
W×sar_x : H×sar_y = a : b となればいいので、
sar_x : sar_y = a×H : b×W で求められます。
…めんどいですよね。

なのでこの機能は、このへんを自動で行います。SAR比 sar_x,sar_yの指定でなく、画面比a,bの指定から、出力時にsar_x,sar_yを自動的に計算して楽しよう、というものです。

一応、SAR比1:1重視です。つまり、SAR比の計算結果が1:1に近い時には、解像度のほうに一定の幅を認めるように計算しています。

たとえば、横解像度800のとき、16:9なら縦解像度は450ですが、16で割り切れるようにするために800x448が使われることもあります。解像度800x448と、画面比16:9で計算するとsar_x:sar_y = 224:225になりますが、こういったわずかの差の場合はsar_x:sar_y = 1:1になるようにしています。

あけましておめでとうございます。

というわけで、2011年です。

今年もよろしく。

たぶん、アニメとかエンコードとかの話しかしませんが。

ふと思ったこと。
2011年11月11日 11時11分11秒11とかだと1がめっさ並びますな。


では、今年も良い年でありますように。