x264guiEx 0.19

更新。

・x264 r1882でqpmaxのデフォルトが69になったのを反映。
要x264guiExDefault.ini更新

r1867やそれ以前で使う場合は--qpmaxに注意。
まあ、デフォルトから変えなければ、x264guiExは--qpmaxを指定しないので、問題ないかと。

---

ダウンロード>>

---

x264 r1881 / r1882

x264 r1881に更新されてる。

SandyBridgeのAVXに対応ってのがあるけど、
AVXは基本浮動小数点演算がほとんどらしく、
整数演算中心のx264ではさほど効果がない…らしい。

あと、たしかAVXはWin7にSP1をあてないといけない…はず。
そしてまだSP1はRCなので、ちょっと微妙かも。
(追記)現行のWin7でAVX命令はOKらしいです。diffの下のほうに書いてあったorz

ちなみに、x264guiEx 0.18はx264 r1881でも大丈夫。
→全然大丈夫じゃない模様。qpmaxのデフォルト変わっとる…


(2011.01.28追記)
r1882来てる。どうやらAVX関係で少し問題あったようで。
で、r1880の「OS対応必要なし」から、
r1882では「AVX使用にOSのサポートが必要」に変更になってる。

x264 r1867 の crf

なんかcrfの基準が変わったらしいよ…？
という話。

続きを読む

続きを閉じる

r1867の更新では
猫科研究所様の訳
表示時間を考慮した品質管理らしい。で、フレームレート25fpsが基準の中心。x264は25fpsが好きですな。keyintのデフォも25×10の250だし。ヨーロッパ(?)は25fpsなんだっけ。どうでもいいけど。

重要なのはcrfが同じでも、フレームレートによって画質が変わるということなのだが、「じゃあ実際どんくらいよ？」ってのが気になる。あと、そんなことより一番重要なのは、「r1834と同じにするにはどうすりゃいいのよ？」というあたり。この辺を実験してみた。

x264のr1834とr1867で比較。

動画は
800x600
6891frame
30fps

コマンドラインは
--preset medium --ipratio 1.5 --qcomp 0.7 --scenecut 60 --min-keyint 4 --keyint 300 --b-adapt 2 --me umh --no-fast-pskip --no-dct-decimate


これをavisynth + x264でエンコード。x264は例によってx264.nlのもの。

元の動画は30fpsなのだが、
avisynthでAssumeFPS()することで、フレームレート(だけ)をいじる。

・r1834
・r1867 30fps(29.97でもいいけど、今回大した差はないはず)
・r1867 25fps
・r1867 23.976fps
・r1867 15fps

で比較。
crfは0.5刻みで10～30の間をテスト。(この範囲外を使う人はいないっしょ？)

これまで(r1834)なら、フレームレートを変えても、出来上がる動画のサイズ(容量)は同じになる。逆に、r1867からはフレームレートを下げると高画質(低圧縮)になるはず。

で、結果。

これは全体図。
横軸がcrf値、縦軸は動画のサイズ(容量、KB単位)。

--crfは小さいほうが低圧縮(高画質)ですよ～という当たり前の図。
これだと線が重なってよくわからないので拡大。



r1834の線は、r1867 25fpsに隠れてしまっていて、ほぼ同じってことがわかる。
猫科様のところに
『目安として「これまでと同じCRF値で同じフレームあたりの品質が再現される」フレームレートが25fps』
とあるので、当然なのだが。

で、r1867 30fpsは、高圧縮(低画質)寄りになっている。同じcrfだと5%ぐらい縮んでる。むろん縮んだ分画質は悪くなってるはず。

グラフから、同じ圧縮率(画質)=同じ動画サイズにするには、30fpsならばr1834の設定よりもcrfを -0.3 ぐらいしなきゃいかんようだ。

まあ、個人的には「フレームレートによってcrf値と画質の関係が変わるってどうよ？」と思うのだが、どうせ29.97fpsでしかエンコードしない(というか自動フィールドシフト時は29.97fps指定)ので「いままでより-0.3」としておけば問題ない。うん。

もっと言えばcrfの0.3差なんていじる必要もない誤差でしかない。あんま気にしてもしょうがない。こんな実験するまでもなかった…と。

x264afs r1867+381

更新。

ダウンロード>>

x264 r1867から
crfの基準(?)がなんか変わったようなので、
25fps以外は(日本だと25fpsなんぞほとんど使わんが)
crf値をr1834の時と同じにしても
同じ画質にはならないようだ。
(よくわかってないorz)実験してみました>>

x264guiEx 0.18

不具合の修正を試みる。

続きを読む

続きを閉じる

0.16, 0.17では不具合があったようです。
ご報告ありがとうございました。

0.18ではそれらを解決すべく…

・v0.16から一部のx264.exeを使用すると、
encoded xxxxx frames, xx.xx fps, xxx.xx kb/s
の表示が出ない問題を解決。

・v0.17で音声処理&muxが正常に行われないことがある問題について、v0.17での音声に関する変更を元に戻した。

・優先度の同期のためのAviutlの優先度を取得するハンドルを得る方法を改善。

---

ダウンロード>>

---

不具合の報告をまとめると、
1. v0.17から音声のmuxができないんだが？
2. v0.17からエンコード開始が遅くないか？
3. v0.16から「encoded xxxxx frames, xx.xx fps, xxx.xx kb/s」の表示が出ないんだが？


で、3は私も再現できた。
パイプからの読み込みバッファの不足により、
1回で読み切れず、後ろのほうが切れてしまった模様。
→最後はパイプになにもなくなるまで読み込むようにして解決。

問題は1と2でいくらやっても再現できなかった。
OSのせいかと思って、XPModeやXPパソコンを使ってもダメ。

しかし、「ウチでは大丈夫だから放置」ってわけにもいかないので
手探りながらもとりあえず対策。

「これが原因じゃないか？」
というところを潰した過ぎず、効果があるか不安だけど。

どうでしょうか…？

x264guiEx 0.17

修正＆機能の追加。

続きを読む

続きを閉じる

・ごくまれにx264.exeが終了しているのに
音声エンコードが始まらない問題を修正(v0.16でのミス)


・x264.exeの優先度変更機能追加
- 起動時の優先度を指定できるようにした。
- エンコード中のx264.exeの優先度を変更できるようにした。
ログウィンドウ右クリックで変更。
デフォルトは「Aviutlと同期(aviutl sync)」。
Aviutlと同じ優先度になるように追従する。


ダウンロード>>

x264guiEx 0.16

不具合の修正ほか。

続きを読む

続きを閉じる

「音声エンコ前に停止」問題の解決
・特定条件下で、x264.exeが終了せず、音声エンコードが始まらない問題を解決

発生することがあったのは、

- ほぼすべてのx264.exe
1pass目に--framesを指定した場合
に加えて、
- 一部のx264.exe
HD解像度(特に縦1080)で、長時間の動画をエンコードする場合

なぜこんな微妙な条件で発生するのかよくわからないけど、パイプを閉じた後、そのハンドルも閉じないといけないのを放置していたためだった。なかなか気付けなかった…。あとテストに時間がかかるかかる…


その他
・非afs時、--framesを渡すことでAviutl側だけでなく、x264guiEx側でも残り時間を表示。ようは「音声エンコ前に停止」問題が解決したため可能になった。

・rc-lookaheadの値が大きい時や、エンコードに時間がかかる場合に、エンコード終盤にx264guiExが固まったようになるのをすこしだけ改善。

・前回の設定ファイルの保存フォルダを記憶するようにした。

・XPで、設定ファイル名を"."を含むものにすると.stg拡張子がつかないことがあるので、.stgを強制(開くときに見えなくなってしまう)

・その他「ファイルを開く」時の挙動を改善

・その他エラーを回避する細かい修正


ダウンロード>>

「音声エンコ前に停止」の件について、報告・調査してくださった方々、ありがとうございます。助かりました。0.16は結構念入りにテストしたので大丈夫だと思います。

白さ爆発

えードラゴンクライシスです、はい。

いやなんか白いなーとか、こんなの前あった気がするなーとか、思ってたんだ、うん。

でもそのままやっちったんだよねー

続きを読む

続きを閉じる

というわけで白さ爆発に嵌りましたよ、という話。

POP氏が詳しく解説されています。
こちら>> POP氏の白飛びについての記事

というわけで私が書くことはそんなにないけど…
っていうかPOPさんの記事で充分だろって話はあるけど、
ヒストグラムでも見てみようかと。

普通はこんな感じ。
Y成分(ヒストグラムの灰色のやつ)の上限がだいたい守られている。
君に届け(2)の例

クリックで拡大

ドラゴンクライシスはそれがぶっ飛びます。白さ大爆発。(赤く丸したとこ)

クリックで拡大

POPさんのおっしゃる方法で修正すると、やっと少しまともに。

クリックで拡大

すこしまだ白い気もする。いや、ヒストグラム的にはOKなんだけど。白い画像の見すぎで目が変になったかな？まあ黒のほうをどうするかにもよる。

今回の画像は500KB制限に引っかかったのでjpgだけど、差は十分わかるかと。

というわけでこれからエンコードやり直すわ。

あ、ドラゴンクライシスはくぎゅが「りゅーじ」って呼んでるから2話も見る。


(追記)x264 r1867が出てるけど、x264guiEx 0.15のままでたぶん行ける。問題ない。

x264guiEx 0.15

少し修正。

要x264guiEx.ini更新。
たびたびすまない。

続きを読む

続きを閉じる

・外部エンコーダとしてバッチファイルを指定しても動かなくなっていた問題を修正。

いまさら知ったのだが、CreateProcess関数の第一引数にバッチファイルを指定してもダメらしく、第二引数に含める形で指定しないといけないらしい。v0.15ではちゃんと動くのをWin7x64とXPMode(XP32bit)で確認。

ton様、ご指摘どうもです、これで大丈夫なはずなのですが…どうでしょう。


・x264guiEx.iniを修正・更新。
ご指摘のあったところを修正。

音声エンコーダのプリセット8番目が重複していた問題(neroとqtaacenc)
muxserとかいうあやしい綴りをmuxerに修正(10箇所)
iniのバージョンを4->5に。


ダウンロード>>


ところで、Aviutlからのフレーム読み込みを別スレッドでやったら速くなるかなあと思って作ってみたが、予想通りほとんど速くならないのでやめた。理想的な設定で2%、現実的なエンコード時は0～0.2%ぐらいしか速くならない(論理コアが12もあっても)。CPUコア数が少ない場合はおそらく逆効果だし、無駄にコードが複雑になるし。

SandyBridge発売

SandyBridgeが発売されたようじゃなイカ。

さあ誰かTMPEGEnc VMW 5のIntel Media SDK ハードウェアエンコを試して、どっかに報告するでゲソ。

というわけで、私は当分買わんけど、だれか…。

と思ったらここ>>にTVMW5じゃないけどハードウェアエンコの画質が出てる。1280x720p 4Mbpsとか640x480 1.5Mbpsでの比較のよう。

・悪くはない画質。これまでのハードウェアエンコよりは優秀？
・ただ設定ビットレートが高めではある。もっと高圧縮だとどうなんだろうか？
・やはり品質基準はないのか？(←これ重要)

というわけで、まあまだよくわからない。ただ、ハードウェアエンコの宿命はパラメータ設定幅が狭くて、時間をかけて高画質・高圧縮みたいなことがしにくいこと。その辺はどうなんだろ。

SandyBridgeは、ハードウェアエンコは置いとくとしても、レビュー記事等を見るに、CPU・GPUともに順当に能力が上がっているようで、よいCPUになりそう。CPUのシングルスレッド性能も伸ばそうという努力がなされているようで、そこが特にいいと思う。いくらエンコードがマルチコアを生かせるといっても、多くなればなるほどアムダールの法則>>の示す通り、有効活用は難しくなるわけで、やはりシングルスレッドの性能を伸ばすに越したことはないと思う。あとGPUもたとえばIE9がGPUでのレンダリングを行って高速化など、ゲーム以外でも使われる機会が増えているので、GPUの性能向上もうれしいかな。