Avisynthを絶讃ιょぅょ Part32 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
「AviSynthを絶賛」というのは、聞いたら答えたり報告したりなどギブアンドテイクな作業を指す。 厨と呼ばれて当然の事を、調べもしないで訊くバカが住み着くスレではないので、 avisynth.infoぐらいは読んでおくように。 【前スレ】 Avisynthを絶讃ιょぅょ Part31 http://echo.2ch.net/test/read.cgi/avi/1383985211/ 【日本語による解説】 avisynth.info http://www.avisynth.info/ 【実家】 AviSynth http://avisynth.org/mediawiki/Main_Page DecombUCFの注意点見つけました 複数clipからDecombUCFをコールするとclipが混ざることがあるようです DecombUCF中のglobal変数を変えて、DecombUCF2とか別関数を定義して回避できた >>571 DecombUCFの改良使わせていただいてます >>602 だれか>571で置き換える箇所をもう少し詳しく書いてくれる人いませんか? >>571 の置換えはこんな感じで使ってる function Limitter(内の以下箇所 str_y = "(Y==128)? 128 : (Y<128)? ( ((127-"+String(range_y)+"<Y)(Y<128-"+String(nmin_y)+"))? 0 : 56 ) : ( ((128+"+String(nmin_y)+"<Y)(Y<129+"+String(range_y)+")) ? 255 : 199 )" から return c.SmoothCustom(eval_y, eval_u, eval_v, false, 0, 0, -1) まで7行かな 以前、UtVideoで吐きだしたaviファイルを読み込ませるのは LWLibavVideoSource) よりも AVISource() のほうがいいと助言を頂いた者です。 あれからAVISource()を使っているのですが、速度が安定しません。 AvsPmod上の解析パスを走らせるときは最初から最後まで安定しているのですが、 batファイルで、avs2pipemodのbenchmarkを使ってログをとるときや ノイズ除去などの補正処理を施したaviファイルをUtVideoで出力するときに、 速度の最高値を100とすると、60あたりから始まって非常にゆっくりと100まで上昇していくという状況です。 ですが、10秒ほどAvsPmod上の解析パスを走らせた後で batファイルを実行すると最初から100の速度で安定して処理を行えています。 何が原因なのでしょうか? ショボスクリプトのスレ無くなったんで、ここ借ります。 縞なし24(5フレーム中2フレームが重複)の周期判定に使うスクリプト # 例 # S1 : 1 1 2 3 4 | 1 1 2 3 4 | ... SelectEvery(5, 1, 2, 3, 4) # S2 : 1 2 2 3 4 | 1 2 2 3 4 | ... SelectEvery(5, 0, 2, 3, 4) # S3 : 1 2 3 3 4 | 1 2 3 3 4 | ... SelectEvery(5, 0, 1, 3, 4) # S4 : 1 2 3 4 4 | 1 2 3 4 4 | ... SelectEvery(5, 0, 1, 2, 4) # DoubleWeave後、10フレーム毎に特定部分を抽出した時に縞が出ない周期を見つける # DoubleWeave().SelectEvery(10, 1) #S1 # DoubleWeave().SelectEvery(10, 3) #S2 # DoubleWeave().SelectEvery(10, 5) #S3 # DoubleWeave().SelectEvery(10, 7) #S4 DoubleWeave().SelectEvery(10, 1) #S1 この状態で周期変化すればその部分だけ縞になるから、後はその縞を検出するスクリプトなりプラグインなりで判定 >>607 の補足1 #S1 DoubleWeave().SelectEvery(10, 1) 1......1......2......3......4......1......1......2......3......4......1 1 1 1 2 2 3 3 4 4 1 1 1 1 2 2 3 3 4 4 1 1 1 1 1 2 2 3 3 4 4 1 1 1 1 2 2 3 3 4 4 0[1]2 3 4 5 6 7 8 9 0[1]2 3 4 5 6 7 8 9 #S2 DoubleWeave().SelectEvery(10, 3) 1......2......2......3......4......1......2......2......3......4......1 1 2 2 2 2 3 3 4 4 1 1 2 2 2 2 3 3 4 4 1 1 1 2 2 2 2 3 3 4 4 1 1 2 2 2 2 3 3 4 4 0 1 2[3]4 5 6 7 8 9 0 1 2[3]4 5 6 7 8 9 >>607 の補足2 #S3 DoubleWeave().SelectEvery(10, 5) 1......2......3......3......4......1......2......3......3......4......1 1 2 2 3 3 3 3 4 4 1 1 2 2 3 3 3 3 4 4 1 1 1 2 2 3 3 3 3 4 4 1 1 2 2 3 3 3 3 4 4 0 1 2 3 4[5]6 7 8 9 0 1 2 3 4[5]6 7 8 9 #S4 DoubleWeave().SelectEvery(10, 7) 1......2......3......4......4......1......2......3......4......4......1 1 2 2 3 3 4 4 4 4 1 1 2 2 3 3 4 4 4 4 1 1 1 2 2 3 3 4 4 4 4 1 1 2 2 3 3 4 4 4 4 0 1 2 3 4 5 6[7]8 9 0 1 2 3 4 5 6[7]8 9 失礼しました。 QTGMC(Preset="Faster")で縦1080のクリップ処理すると下端8ピクセルの色がおかしいんだけどおま環? 8ピクセル足して処理すれば正常になる AddBorders(0,0,0,8) QTGMC(Preset="Faster") Crop(0,0,0,-8) ピクセル数が (Blocksize - Overlap) の倍数じゃないとダメなのかな なんか聞いたことがあるよな、ないような・・ 無印Avisynth使ってる? L-SMASH使った読み込みで dr=true にしてるとか 縦の画素数が1088 になるやつ 色がおかしいって表現は適切じゃなかった 下端8ピクセルは補間されないでNNEDI3の出力がほぼそのまま出てるからボビングが激しい MDegrainがブロックの半端部分はコピーするようになってるからQTGMCの仕様っぽい >>606 の解決法わかる人いないかな? avs2aviとUtVideoを使って、処理を分けた中間ファイルを何度か出力するようにしてるんだが、 >>606 の通りにAvsPmodの解析パスをちょっと走らせた後だと 当該avsの中間ファイルの出力が早くなって全体で1時間も短縮できてしまった bat叩くだけの何か解決法ないかな? うちでは起きてないから答えようがない もっと詳細な環境情報や再現する簡潔で最低限な方法は書き出せないの? Avisynth+ r1718 avs2aviとUtVideoは最新版 以下、avsの内容 AviSource("hoge.avi",false,"YV12") return last 以下、batの内容 "avs2avi.exe" "input.avs" "output.avi" -c ULH0 これでもAvsPmodで解析パスを少し走らせる前と後で数十fpsも違ってくる なんでr1718なんや… avs2pipemodのベンチマークを10秒走らせた後ではどうなの? それで大丈夫ならavs2pipemodのTrimオプション使って10秒ベンチマーク→本番 これでバッチ1つでできるようになると思うが、根本的な解決ではないな >avs2aviとUtVideoは最新版 こういう書き方止めてくれ UtVideoは恐らく20.0.0だろうけどavs2aviは派生版含めていくつかあるからこういう書き方されると混乱を招くだけ >Avisynth+ r1718 x86なのかx64なのかそれとも両方なのか不明 とりあえずAviSynthを新しいバージョンに上げてみて再現するか調べようか 間違ってる可能性も方が高そうだけど、エスパーするとHDDのヘッドが退避してる状態でバッチ呼び出すと遅くなるとか? 解析パスだの実行してaviファイルの入ったHDDから読み出そうとした後バッチを実行するとすでにヘッドが動いてるから最初から高速で読み出せるとか 流石に全体で1時間も短縮できるって所見るにあり得なさそうだけどさ >>614 OSはWin7? 中間aviの出力先はHDD? もしWin7でHDDなら出力先をSSDに変えたら速くなるかな? SSDに変えて極端に速くなったならavs2aviの問題 avs2aviは内部の書き込み用バッファが少ない(512KBしかない)ので出力先がHDDの場合、非圧縮や可逆フォーマットで それなりの解像度の場合データ量が多いのでHDDの書き込みが追いつかなくなって速度がでない (SSDなら書き込みが速いのでバッファが少なくてもあまり問題にはならない) 自分は書き込み用バッファを増やせるようにソース書き換えて使ってる バッファを64MBまで増やすとHDDでもそれなりに速度が出るようになる Win10だとバッファ512KBでもあまり速度低下しない (Win10だとバッファの設定変えても速度にあまり変化がない、WriteFileAPIの動作が変わって内部でディスクに書き込む前にバッファリングするようになったのかも?) Win8は持ってないので分からない r1718(x86)から最新版に更新してみたけど AccessViolationが出てしまう 1年ぐらい前も同じだったのでこのままr1718で行こうと思います。 avs2aviはAvisynth.infoのアーカイブのv1.40aです。 avs2pipemodのbenchmarkを少し走らせた後で 中間ファイルの出力を行っても速度は遅かった。 で、AvsPmodで解析パスではなく単なるプレビューをしてAvsPmodを終了させずに 中間ファイルの出力を行うと速度が速かった もしかしたら解析パスとプレビューのどちらでもいいのでどちらかを行った後、 AvsPmodを終了させなければいい(メモリから解放しなければいい?)と予想して、 batを叩くだけで済ませたかったのでavs2pipemodのbenchmarkの途中で中間ファイルの出力を始めると、 benchmark中はそちらに速度を持っていかれるが、benchmarkが終わってから速度が最大あたりで安定した。 OSはWin7 出力先はHDD SSDはまだ手を出していないので試せないです。 申し訳ない。 >>620 > AccessViolationが出てしまう VC++2015/2017のランタイムを入れてないだけじゃないの? 自分ももしかしたらと思って確認したけど インストール済みだった 念のため再インストールしたけど変わらなかった あれじゃね plusの高深度カラー非対応なフロントエンド使ってるのでは ttp://csbarn.blogspot.jp/2016/07/blog-post.html 古いプラグイン使ってるなら更新したほうが良いと思うよ とりあえずプラグインフォルダをほぼ空にしてみたところ、エラーは出なくなった でも中間ファイル出力については変化なかった 今のところは>>620 のやり方でやるしかないか... autoVFRの1passの解析の時に 異常に遅いときがあるからそれのことかなとは思う もっとも最初から最後まで遅いから違うと思うけど 自分の場合は>>606 を見るまで意識してなかったけど 実際にやってみたら再現できてしまった LWLibavVideoSourceだと>>620 のような処理も必要とせずに速度が最大辺りで安定してるのも同じだった 上でplus MT環境でdecombUCFやConditional Filter使うとエラー文が表示されると書いたものだけど GRunTのセットアップ(自動読み込みフォルダへ入れる)でエラーがでなくなった まだ通してはエンコードしてないけどsrestore、decombUCF、保健用デインタレ関数では、とりあえずエラー無く動いてるもよう 本体は、Avisynth+ r2664 (20180328) 頻繁に使うプラグインならまだしもそうじゃないプラグインはオートローディングしないものだよ と思ったけどオートローディングフォルダに入れて正常で、手動でLoadPluginしたらエラーでたのかな? 何が起きてるか分からねぇ GRuntを入れずにMTを使うと>550 の状態になってたけど GRuntを読み込むと、そのエラー文が表示されなくなった Dither_add_grain16を使ってみたのですが マスククリップのような緑色のクリップができてしまいます。 LWLibavVideoSource() Dither_convert_8_to_16() Dither_add_grain16() DitherPost() return last ditherはAvisynth wikiのDither toolsの Downloadのリンク先のもの(v1.27.2)です 何が原因でしょうか? DitherのRequirementsに書かれてるmasktoolsとかのバージョンが古いとか? tp7氏のものからpinterf氏のものへ入れ替えたところ 正常に表示できるようになりました。 ありがとうございました。 家だけかもしれないが、Windows 10 1803にしてから、 AvsPmod(x64版)でF5のプレビュー画面を出そうとするとクラッシュする様になった >>637 win10の文句はmicrosoftに言え。 flash3kyuu_debandがダウンロードしようしたらリンク切れでどうしようかと思ったけど HDD内を探したらあったので再配布 http://fast-uploader.com/file/7083408071468/ アーカイブ内のテキストによると2.6系専用だそうです x64のは動いたのを確認したけど自己責任でどうぞ (作者様&ビルドしてくれた人thx) こ、これは・・ 本家のほうに送ったほうが良いような気がする >>573 Neoなら↓これでOK function MyFunction(clip c1, clip c2) { return c1.ScriptClip(function[c2](){c2.subtitle(string(current_frame))}) } TVTestで保存したTXのtsの大半が l-smash worksで読み込んでも無音… まぁ、murdoccutなり、tssplitterで頭切ると読めるようになるんだけど…ね Doom9見るとよく分からないけどpinterf版>>640 で大きな変更があったのかな AvisynthNeo試してみた。KFMDeintでお手軽に使えてよいね。 一方チャプタファイルの作成でTrimCleanを改造したのを使ってるんだけど AvisynthNeoだとWriteFileStart関数が文字列変数を指定しても見つからなくてエラーになるようだ。 AvisynthNeoのWriteFileStart修正ありがとです 初心者質問スレで、AvisynthNeoのクラッシュ報告が有るみたいです。 NeoってCUDA系のプラグイン使えないと思ってた >>649 を見る限り、使えるのかな? これからビルドしてみよう Neoをビルドして、CUDAフィルタ群もビルドして使ってみたら KTGMC.avsiでエラーが出るようになった Invalid Property request. KTGMC.avsi line 451 なんだろう。 >>654 一度に本体もPluginも変えちゃだめだったね。 Pluginの方はCUDA1.0の方でもちゃんと動く 本体の方をNeoにするとエラーが出るようだ NeoはCUDA動かないってなってなかったっけ?ってgithub見に行ったら KFMにDecombUCFを移植ってあるやん 魅力的凄すぎる・・ 最近のインタレ解除はKTGMCのBOBとSelectEvenで30fpsのCFRにしてたけど >>656 みたいのが出てくるとKFMのほうがやっぱり効率的かもしれないなー AvisynthNeo+64bit版AvsPmod改でQTGMCを使うと、初回プレビューやシーク時にエラー なお32bit版は問題なし Traceback (most recent call last): File "./avsp.py", line 11704, in OnFocusVideoWindow File "./avsp.py", line 13933, in SetVideoStatusText File "./avsp.py", line 14082, in GetVideoInfoDict File "./avsp.py", line 17272, in FormatTime TypeError: %d format: a number is required, not float プラグインのバージョンは以下の通り MaskTools2 2.2.14 MVTools2 2.7.31 nnedi3 0.9.4.51 RgTools 0.96 nnedi3はjpsdr版、それ以外はpinterf版 AvisynthNeoは0.4.0で、AvsPmodは2.5.1-90-gfcd7a61に以下のサイトのファイルに差し替えた改 https://github.com/nekopanda/AviSynthPlus/files/2108666/AvsPmod_neomod_x64.zip あと、BCS使うと486ではなく488になってしまうことも確認 ここで配布しているavisynthプラグイン、持ってる人いない?(ソース含む) 色々探したんだけど、見つけられなかった… avisynth.nlにもなかった http://putin999 blog.エフシーツー.com >>661 のリンクがおかしかったのでこっちが修正版 http://putin999.blog. エフシー2.com エフシーをfcに要修正(NGワード対策のため) どのプラグインがいるのさ Its 64bit版はnekopanda氏が公開してくれてるし 他に代用の利かないものってあったっけ? >>663 ロゴ関係 エッジレベル調整 スムージング は欲しい delogomod.dllはx64は作者も作ってない >>374 で配布した人がいるけど自分は間に合わなかった ソースは全て配布対象外だったような気がする 32bit版はプラグインフォルダに入ってるけど ソースがどっかに行っちゃったのかもともとなかったのか ttps://www.axfc.net/u/3916389 元のdelogoの作者とmoodの作者に感謝しながらDLしような >>667 tnks!! そーいや、GTX 1080 Ti 買ってしもうた これからの nekopanda氏 に期待して つか、avisynthはx86とx64でそんなに差はないだろ。 エンコ速度が変わるのはx264やx265の話だしな。 avisynthはrawでわたしてやれば特に違和感なくエンコされるはずだぜ? 動作検証すらほとんどされてないx64の野良ビルドとか正直怖すぎだぜ >>673 どのレスに対してのレスなんだ? 野良ビルドってどのこと? >>667 のことだったら、ソース入りだぞ >>673 今後、4k, 16bit/sampleとか扱うのにメモリに制限のある32bit版では心もとない気もする >>676 あがるよな だから皆64bitバイナリの無いプラグインを必死でソース探してきてビルドしたり代替プラグイン探してるのにな >>676-677 違いが出るとすれば速度よりも扱えるメモリアロケーションがx86とx64で大きく異なるぐらいだが メモリ量が増えればそれだけ負荷がハードウェアへ増大するわけで、必ずしも速度向上につながるとは言い切れんよ warpsharpやfft3dあたりが昔から重くさせるから、それらを軽量の設定にするか使わなければ我慢はできるかも。 インタレ解除とかはグラボ支援のやつで任せておけば、x86やx64に関係なくちゃちゃと終わらせてくれるしさ アマレココで吐いたaviはaviutlでは編集も再生もエンコも不自由なくできるけど avspmodで編集するとプレビュー時にエラーで固まることがあるのな。 MPC-HCでAMV類のプレビュー再生できないのもやっぱり便利悪い。 スレチだなさーせn。 アマレココでAMV使うからそうなるわけで Ut_videoとか使えば問題ない >>680 グラボ支援のインタレ解除プラグインってどれ? 今までTFM、TDeint使ってた。 >>680 何がいいたいのか解読できん。avisynthはrawでわたしてやれば特に違和感なくエンコされるはずだぜ? ←これもだが ハードウェアの負荷が増大するなら、ハードをより使ってるってことだから速度向上じゃねーか 君には32bitOSで32bitのAviSynthと32bitのx264/x265を拡張命令切って使うことをおすすめするよ >>683 D3DVP インタレ解除=24fps の意味で使ってるならそのままのほうがいい >>667 ぐわー、10分前に公開期限切れだ >>500 だけど、ワンチャン欲しい >>684 D3DVPなんてのがあったとは。 ありがとうございます。 >>686 ttps://www.axfc.net/u/3916838 >>688 ヘ⌒ヽフ ( ・ω・) dddddddddddddd / ~つと) 諦めムードだったけど ようやくゲットできた ありがとう KFM -2パス逆テレシネを実装 キターと思ったが、TFMみたいなテキストファイルの出力は無しか >>690 中間ファイルは吐くよ。バイナリだけど。テキストだと嬉しいの? KFMはAmatsukazeのためにあるものなのかな? 色々機能あるみたいだけど単体で使う感じじゃなさそう TFMがKFMになったわけじゃなさそう >>692 ドキュメントにある通り元々Amatsukaze用だけど、 Amatsukazeがないとできないのは、 VFRのタイムコードを吐くことくらいだと思う 個々のフィルタはあまり単体で使う設計になってないから、 使い方が少し面倒だけど、そこはKFMDeint使って >>691 TFMのoutputで吐くものと同等のテキストだと、とても嬉しい >>694 前にもそういう人いたけどアルゴリズムが違うから無理 余談だけどTFMのコーミング判定メトリックは誤爆しまくるから、あまりいいものではないと思う KFMは全く違うアルゴリズムでコーミング判定してる >>693 はい、ご丁寧にありがとうございます 色々探ってみます フレーム番号とフィールドマッチと縞度を知れればそれでも嬉しい 最新のNeoとプラグインを全部ビルドし直したんだが なんか動かないな。KTGMC.avsiとかでAccess Violationとかのエラーが出る nvcc の最適化を切ったらまたメッセージが変わった なんだろうな >>695 >TFMのコーミング判定メトリックは誤爆しまくるから、あまりいいものではないと思う 同感 放送波ソースではアテにならないイメージ そのための2passだと思うんだけどね エンコーダにおくるzonesの設定にも使えるから、マルチパス化した方が良い気がするけど Neoはまだうまく動かず使いきれてないけど、 CUDAは素晴らしいですね 1080Tiがあると鬼に金棒ですわ KNNEDI3とKTGMCが速いのが嬉しいですね ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる