Winrar(64bit)がフリーズする

何故かは知らん。

日本語？ファイル名が含まれるファイルを圧縮した書庫を同じ実行ファイルでを開くとファイル一覧が表示できないっぽく、プログラムが応答なしに。
日本語全部というわけでもなく条件がいまいち不明ですが・・・

とりあえず5.61でも32bitバージョンか、x64の5.30以前？辺りは大丈夫っぽい。

そういえばwinrarは買ってからもう10年近くたつのにいまだに最新版を使わせてくれます。(まぁ、もともと永久にバージョンアップ無料、と言ってたからね)
ってかこれで儲かるんだろうか。
バージョンアップで金をとるシステムが一般的になってきた昨今からするとそんな事を思ってしまいます。

ついに使えなく・・・なっていはいないけど

zip/pdfの画像ビューアにずっとhamanaを使ってきてたのですが、
Win10-1809にアップデートしたら一部の設定が読み込まれない？ような状態に。
再度設定しなおせばそのセッションだけは使えるのですが、プログラムを再起動すると同じ事になります。
もうそろそろ潮時でしょうか・・・

というわけで探してみたらNeeViewというのが自由度が高くてよさげ。
起動に時間がかかるのが難点。

HoneyViewも必要なことはできるのですがカスタムしたくなる人にはあまり向かないかも。
しばらくNeeViewを使ってみて様子を見ましょう。

UnsharpHQのソースを見ていたのですが

僕はシャープフィルタにUnsharpHQを使っているのですが、ソースを眺めていてバグにしか見えないコードが・・・
あと、せっかく読んだの忘れないようにメモ

MT

MT化で早くなるぜ！
→ついでにバンディングを直そう
→あれ？dfttestのdither1だけじゃ足りなくね？
→dither2以上か・・・これってMersenne Twisterっていうよくわからんアルゴリズム使ってるんだよね・・・
→最近はSIMD化されたの(SFMT/dSFMT)があるらしいぞ
→開発者は日本人なのに日本語の関数説明ページがない・・・
→float精度で良いなら従来の方が軽いような？
→ループで呼ぶからダメらしいので、大量に生成してみたけど結局従来とあまり変わらないような？
というところで、元に戻しました。
使い方に依るのかもしれません

181216追記
→dffttestは最近16bit深度に対応した1.9.4.3があるらしい
→AVXで一部最適化されてるぞ
→その他もAVX化したら早くならんかね
→なんか速くなる時とSSEより遅くなる時とあるな・・・
→メモリアクセスがネックの場合、alignは大事なんですね
→使う関数はdither以外はあらかたAVX化したし、もうこれぐらいが限界かな
→でもやっぱりdither処理が一番コスト高い・・・こいつ(Floyd-Steinberg)をSIMD化したコードはないものか・・・
→ってかMersenneTwisterとFloyd-Steinbergを両方呼ぶ必要ってあるのかな・・・
という疑心暗鬼な今日この頃。
一応だんだん速くなってきていますが、結局MTが一番効く気がします。

↓今のdfttest.dll(fftwは除く)の各関数処理時間
(1000フレーム処理時・サンプル単位はms なのでサンプル数/1000で[ms/フレーム]になります)

dither=2,opt=0,threads=1,align=64/AVX
名前	排他サンプル数	排他サンプル %
+ dfttest.dll	16,100	27.52%
| - dither_C_sub	9,739	16.65%
| - filter_0_AVX	1,300	2.22%
| - MTRand::reload	1,253	2.14%
| - proc1_AVX	1,026	1.75%
| - proc0_AVX	887	1.52%
| - removeMean_AVX	859	1.47%
| - addMean_AVX	344	0.59%
| - memcpy	271	0.46%
| - memset	250	0.43%
| - func_0	113	0.19%

とやっていたら、一部の関数にAVX2の命令(_mm256_cvtepu8_epi32：鯖のSandyBridgeでは使えない)を使っていた・・・orz
→というのを直してもまだ動かず。
なんで？と思ってたら、浮動小数のFMAもHaswell以降だったんですね・・・。
Haswellで、AVX2：整数、FMA：浮動小数が追加されたということ？わからん。

最近のツールを知る

春ごろにL-SMASH Worksを知って、これでいいんじゃね？でもaacの同期を取るためにはちょっと手間だよね、とか思ったのですよ。

で。

世の中やっぱり誰かが同じことを思うようで、例によってmakiさんがts_parserというツールを作ってくれていました。

ts_parser.exe --mode da [options] <input.ts>

[options]
 --output <string>          出力名 を指定 (未指定の場合は入力名<input>を使用)
 --delay-type <integer>     ディレイタイプ を指定
        0 : None                無
        1 : GOP Key frame       MPEG-2 VIDEO VFAPI が該当
        2 : GOP 1st frame       DGIndex/DGDecode   が該当
        3 : 1st Video frame     Libav Reader       が該当 (L-SMASH-Works)

とのことで、まさに

先頭フレーム例
d2v：     BBIBBPBBPBBPBBP
lwi：PBBP BBIBBPBBPBBPBBP
gl ：       IBBPBBPBBPBBP

でどうしようと思った僕の疑問をすべて解決してくれました。

世の中情報って大事ですね。危うくTSを解析してaacを抜き出すにはどうしたらいいかとか考え始めてました・・・

そしてmakiさんの補足を読んでいて書いてあったこと

[補足4]
本ツールを使用せずに、ts2aac でL-SMASH-WorksのLibav Readerに合わせる方法を提示。

(1) MurdocCutter でTSを全体選択して出力
(2) ts2aac で -B オプションを指定してAACをDemuxする

・・・ホウ・・・

なんでみんなやってないのかようやくわかった

Avisynth+でちゃんとMT化ができる(しかも安定して動きそう)ということを知りました。
というわけで、プラグインの個別最適化はそれ単体で律速になるような重量級のものでない限り、コア数を増やせば解決できるということなんですね・・・

で、

SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
#SetFilterMTMode("dfttest", MT_SERIALIZED) #same story as with sangnom2
SetFilterMTMode("TFM", MT_SERIALIZED) #MT時は外部ファイルへの出力スレッドが呼ばれないので それを使わなければOK？
SetFilterMTMode("TDecimate", MT_SERIALIZED)
SetFilterMTMode("NNEDI3", MT_MULTI_INSTANCE)

MPEG2Source(vsource,idct=4)
TFM(mode=1,order=-1,PP=1,slow=2).TDecimate(mode=1)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(sigma=4,sbsize=block,sosize=block/2,tbsize=1,dither=2,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0)

Prefetch(4)#←これがMT化に必要 昔の感覚でやると気づかないので注意

というスクリプトで50fpsを超えるようになりました。
・・・28→32fpsで喜んでいたのが馬鹿らしくなるほどの効果ですね。
そしてエンコード速度が1920x1080のソースでも30fps超が出るようになりました。

世の中、コアを増やせば簡単に速度UPできるから、dllのopenmp化とかが流行ってないのでしょうかね。
・・・ぼくもコアを増やさねば・・・

Avisynth+のMTって何なのかわからなかったのですが

AviSynthPlus
Avisynthには2.6を使っていたのですが、avisynth+というのもあります。
Avisynthは本家が止まり、その後継プロジェクトがあったのにどれも最終的に更新が止まる、というイメージがあって、こちらもプロジェクトがどこかで頓挫した・・・と思っていたらprinterfさんという方がメンテを継続しているようです。
doomのスレも賑わっているようでした。

で、なんでそんな話をし始めたかというと、
例によってdfttestのチューニングをしていたら実はバグってることに気が付いてorzとかなってたのですが実はベクトル化よりもMT化すればいいんじゃねという当たり前な結論に至って#pragma omp parallelをやってみたらメインPCでは上手くいったのに鯖でうまくいかなくて(というかスレッド化のコストが高すぎるのかCPUを100%占有した上にやたらと遅い)なんでだろうと思い、その原因がメインPCではavisynth+を使ってて鯖は2.6無印だったのが原因だった
ということに起因しているのです。

というわけで、MT化したプラグインを使うならavisynth+をインストールしましょう。
32/64の共存もやりやすくておすすめです。

ちなみに、dfttest(のdither)はベクトル化・・・というかパイプラインがストールしないように工夫するとかそんな感じのことをして、1440x1080を1000フレーム処理するのに元のコードだとdfttest単体で(fftw含まず)28sとかかかるのが、23s程に減らせます。
その中でdither部は8sを消費していて、dfttest.dllの中身では一番重い処理になっています。
ちなみに、この時
・fftw：42s
・MPEG2DecPlus：6s
・FluxSmooth:5.4s
・SplineResize：2.5s
・UnsharpHQv05：2.5s
な感じです。

これをMT化するのですが、MTのオーバーヘッドが約1s分ぐらいあるのかdfttestの時間は1sぐらい増える(24s位になる)んです。
が、処理速度は律速部分が解消され、27fps→32fpsへ向上します。(CPU負荷は32%ぐらいだったのが40%位に増えます)
MT化するに当たって本来1画面全体をdither(froid-steinberg)処理するのに対し、1画面を4分割して処理しているので、実は元と演算結果に差があるのですが、そもそもノイズを加える処理なので問題ないでしょ、という。

そういえばavisynth自体のmtを使ってないな・・・
これ使えばもっと早くなるんじゃね？
avisynthのmtって意味なくね？というのが数年前・・・5年前？ぐらいの記憶なのですが、きっとそこから変わっていると期待しています。
x264でCPUを100%使い切れてないのでちゃんと使い切ってあげようという親切心からこんなことをやってるわけですが、時代はどこまで変わってるんですかね。

→普通に別スレッドで呼んでくれているようで、コア数の分CPUを使ってくれそうです。
・・・ということはスリッパを買うしかない・・・！いや、9700とかでも良いけど


といろいろ調べていたら、やっぱりみんな考えることは同じみたいで、CMカット自動化ツール(joinlogoscp)とか、自動エンコードツール(Amatsukaze)とか、最近はいろいろ出てきているようです。(いや、前調べたのが5年前とかだから・・・)
https://github.com/nekopanda/Amatsukaze

やってることはおおよそ僕が自分用にやっていることと同じ(高機能だったり低機能だったりというのはありますが)なので、もう自分で環境をメンテしなくてよいのか・・・。
それはそれで寂しいものもありますが、誰かがやってくれるなら自分でやる必要はないですしね。

全然時代の流れについていけてませんが、ちょっと使ってみましょう。