>>266 2passエンコでエラーが出る?ふむふむ。
そもそもの話からしたほうがいいかね?スレ3つぐらい消費するがw
茂木氏が何のために拡張AVI出力にx264用ロジックを乗せてるのかじっくり読んでくるべし。
ttp://www.marumo.ne.jp/ とりあえず。拡張AVI出力のように終端Bフレの終了を待たずにCodecを開放する早漏TOOLを使っていると、
出力されるAVIファイルの実際のフレーム数は「総フレーム数 - Bフレ連続数」になることを胆に命じていた方がいい。
この待機が必要な「Bフレ連続数」のことを内部ではディレイと呼んでいて、AVIのフレーム数はディレイ分だけ少なくなる。
当然解析結果(.stats)ファイルの行数も少なくなる。行数チェックではこれを考慮しているので一応問題ない。これが以前の実装。
pthread対応以前は、1フレームの画像分割方式だったためスレッド数を考慮しなくて良かったわけだ。
>>267 の続き...
ところが、pthread対応以降はフレームを各スレッドで処理するため、ディレイを「Bフレ連続数 - (スレッド数 - 1)」とする必要がでてきた。
当然出力されるAVIのフレーム数はディレイの分だけ減少する。Bフレ5 スレッド4なんかにした日には目も当てられない始末。
解析結果ファイルもディレイ分減少するが、2パス目のチェック時にはBフレ数しか考慮していないので、行が足りないとエラー落ちする。
当然といえば当然。
拡張AVI出力を使わないなら、1パス目はスレッド1にしないとダメだわなぁ。
そもそもvfwはこういう問題があってダメなわけで、それを分かった上で使える人だけが使うべきなんだけどな。
上を確認できるAviSynthのスクリプトを張っとく。Bフレ5 スレッド4でエンコして自分の目で見てみるといい。
Colorbars(320,160)
trim(0, 399)
ShowFrameNumber(scroll=false, offset=1, text_color=$ffff00)
>>268 訂正
pthread対応後のディレイ = Bフレ連続数 + (スレッド数 - 1)
なんで引くかな・・・すまん。○| ̄|_
訂正ついでに、AviUtilでx264vfwを使って幸せになるためには、結局のところ拡張AVI出力が必須なわけで、
そうなるとafsを使った120fps化ぐらいしか選択肢がない。一応afsでの24fps化もできるが。
あと、AviSynthとauoencの組み合わせなら、以下をスクリプトの最後に書いておくと最終フレームが抜け落ちなくてよい。
DuplicateFrame(FrameCount()-1)
Bフレを3とか4とか使いたいやつは、DuplicateFrameをもう1行追加すべし。
綺麗な方法とは言えんがね。
デフォルトだとBフレ2(推奨値)だしスレッドもせいぜい2が普通だから
最悪でも最後の1フレームが切れるかどうか。
最後の1フレームなんてあってもなくても問題ない真っ黒とか静止画の続きがほとんどだし
多少動いていても目で見て気付くようなものではないから実際はそんなに問題になってない、と。
>>270 俺はその設定だと拡張AVI出力で作成したAVI以外は糞認定だな。
なぜかというと、ここで言っているディレイってのは、言葉そのもので再生時の遅延を意味するから。
上のスクリプトのように400フレームあった場合に、無圧縮AVIとx264AVIでフレームの表示に狂いが出てくる。
ディレイ = 2 + 2 -1 = 3 ってことは、フレーム番号に下のようなずれが出る。
素AVI : 1, 2, 3, 4, 5, 6, 7,.....395, 396, 397, 398, 399, 400
x264AVI: n, n, n, b, b, 1, 2,.....390, 391, 392, 393, 394, 395
(nはnullフレを意味する。どんな映像になるかはデコーダ次第。bは先頭参照フレ。通常だと1フレになるがデコーダ次第。)
これは、音声も5フレ分(166.7ms)ディレイさせないと、ずっと音と映像がずれた状態になるわけだ。
しかも最後の映像は切れるし。これが問題じゃないって言うんなら、DTV板の住人なのかまじで?!って事だ。
だから上のスクリプトでAviUtilの標準AVI出力でエンコしてみろって。
最初の1番がやたら表示時間ながいし、395番までしか表示されないから。OK?
数フレくらいダミー足しとけば(・∀・)イイ!!