映像・音声同時エンコ時に、x264がエラーで終了した場合、音声出力がすべて終わるまで待機するのでなく、直ちにエラーとして終了するようにした。
ご指摘ありがとうございました。
今回は、これだけ。
※2012.8.31 8:12
githubのほうのファイルがダウンロード失敗するのを修正。
ダウンロード>>x264guiExの導入>
確かflac.exeだと2GBを超えるファイルが出力できなかった気がしたので適当に4GB未満のWAVを作って試してみました。
(readmeにDL先の記述が無かったのでとりあえずttp://flac.sourceforge.net/のやつで)
結果はやはり無理なようで、上限の2GBまでしか生成されませんでした。
まぁ2GB以上のFLACを出力する場面をあまり想像できないので実際は問題にならないような気もしますが……
今日まで（おそらく4月頃？（ver1.40前後あたり）からの変化に）まったく気付かなかったのですが、RefFramesの扱いに関して変更を加えられたようなことは無かったでしょうか？
--ref 4 設定してあるプリセットでいつの間にかref 3でしか出力できなくなってしまっているようなのですが・・・。
x264guiEXのバージョンだけ更新していてプリセットは同じものを使っているのですがref 3でしか出力されなくなってしまっている状況です。
MediaInfoで見るとx264のリビジョンは同じでもx264guiExを更新したタイミング以降のものはref 3になっていること、プリセットを作り直してもref 3であることなどからx264guiExに何らかの変更があったのではないかと推測したのですが・・・。
いかがでしょうか？
なるほど、guiExのバージョンだけ更新だと確かにguiExがあやしいですね…。(え゛
ざっと見なおしてみましたが、refそのものについての変更はなかったと思います。関係がありそうなところは、
・v1.37のコマンドの二重発行の抑制
・v1.57のMediaInfoの取り込み
で、x264に渡すコマンド発行方法に変更を加えており、そのため渡すコマンドが変化したのかな…と思います。
しかし、確認したところ、こちらではref4の指定は正常に行われています。
可能性としては、levelの指定による制限が関係あるのかなと思いましたが、よくわかりません。
・動画解像度とfps
・設定画面の下の方に表示されているコマンドライン
・コマンド入力欄のコマンドライン
・ログウィンドウのx264 options...(arguments passed...)に表示されているコマンドライン
の4つを教えていただけないでしょうか。
大丈夫と書きましたが、MediaInfoの下の方の「エンコードライブラリの設定 : ref=4」を見ていたからでした。
たしかにref 4 を指定したのに「RefFrames : 3 フレーム」となることがありますね。「エンコードライブラリの設定」の方と違う値なのがおかしいですが。
どうやら--b-pyramid strictにすると発生することがあるような気がします(x264 r2216 x64)。また古いx264guiEx(v1.30)でも発生しました。normalに戻すとRefFrames : 4 フレームになりませんか?
x264 のソースコードを見よう。
encoder/set.c line 142～
sps->vui.i_num_reorder_frames = param->i_bframe_pyramid ? 2 : param->i_bframe ? 1 : 0;
/* extra slot with pyramid so that we don't have to override the
* order of forgetting old pictures */
sps->vui.i_max_dec_frame_buffering =
sps->i_num_ref_frames = X264_MIN(X264_REF_MAX, X264_MAX4(param->i_frame_reference, 1 + sps->vui.i_num_reorder_frames,
param->i_bframe_pyramid ? 4 : 1, param->i_dpb_size));
sps->i_num_ref_frames -= param->i_bframe_pyramid == X264_B_PYRAMID_STRICT;
リオーダーフレーム数を決定。B pyramidが有効なら2、Bフレームがあるなら1、上記2つが無効なら0
まず、ref/リオーダーフレーム+1/dpbサイズ/B pyramid有効なら4無効なら1 のうちの最大の数値を取得し、16を超えていたら16にリミットしたものをrefに代入。
B pyramid strict なら refを1減らす。
だいぶ前からこういう構造。
情報不足で質問してしまい申し訳ありません。
＞どうやら--b-pyramid strictにすると発生することがあるような気
＞がします(x264 r2216 x64)。また古いx264guiEx(v1.30)でも発生
＞しました。normalに戻すとRefFrames : 4 フレームになりませんか?
理屈は分かりませんが、仰るとおりのようです。
お騒がせしてすいませんでした。
このコメントは管理人のみ閲覧できます
CnQやC1Eなどを切って、クロックを固定しても2pass目に突然アイドルクロックでしか動かなくなる、ということでしょうか。
x264guiEx側でクロックに影響するようなことはしていないはず…です。
ちょっと良くわからないので、思いつくことを書いておきます。お役に立てなかったら申し訳ないです。
2pass目ということで、CPU使用率が極めて高いために起こるのではないかなあ、と思います。OCCTなど、ベンチマークソフトによる高負荷時ではどうでしょうか。
個人的には以前GPU(GTX460)でアイドルクロックから上がらなくなり、再起動するしかなかったことがありますが、これはGPUのドライバのバージョンとMSI Afterburnerのバージョンの相性問題でした。しかしCPUのクロックとなると…。定格のようなので、冷却の問題でも無さそうですし…。
このコメントは管理人のみ閲覧できます
