最新のTIVTC

avisynth+のpinterfさんがTIVTCの64bit版も作っています。

が、なんかtriticalさんのと結果が違うことが・・・なんで？
と思ってこの際ちゃんと確認してみました。
で、asmとは違う処理だったので、とりあえず質問してみることに。
バグなら直してくれると信じてます。
(というか直前の処理をコピペした後、変更する途中で力尽きてそのまま忘れ去られたコードに見える・・・)

→1.0.14で修正されました。さすが対応が早いですね。

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

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

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

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

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

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

dfttestをチューンしてみた

VS2017にしたらなんか遅くなったけど、いろいろやってたらまた同じぐらいの速度になったので
そして、githubのところにUPしてみた。

自分の環境で問題になる不具合がなければあまりメンテする気がないですが。

オリジナル(1.9.4)に比べてdll単体のコストは3割ほど減ってるはず。
シングルスレッド部分がボトルネックになっている環境であればこれで多少早くなるのでは？

MPEG2DecPlus_MPEG2Source(vsource,idct=4)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0)

のスクリプトでavs2pipe -benchmarkをすると28fps程＠i7-4790K
dither>=1には効果があるけど他はあまり変わらないと思います。

もうこれでいい気がする

L-SMASH Works r935

僕はずっとDGIndexを使い続けているのですが、L-SMASHってデコーダ(とは言ってもffmpegに渡すだけ？)もあったんですね。
ずっと、正しいコンテナ実装するぜ！っていうプロジェクトだけだと思ってました・・・

ffmsはtsでフレームアキュレートではないという欠点があったのですが、こちらでは-ss的な何かで正しくなっているのでしょうか。
・・・AAC抽出時の音合わせとかどうすればよいんだろう・・・LWLibavAudioSourceからの再エンコードとか？
まずはちゃんとreadme読むか・・・
→やっぱりちゃんと書いてあった

av_sync
LWLibavVideoSource読み込み時のインデックスファイル(またはファイルを生成せず
内部的に生成したインデックス）で設定された映像ストリームと音声を同期させて、音ズレを防ぎます。
ただし、映像・音声ともに Libav で読み込まれていることが同期条件となります。

先頭フレームが音声の同期ポイントとなりますが、ffmpegを用いてMPEG系映像を表示する場合、先頭GOPのIピクチャ、またはデコードが保証されないBおよびPピクチャが先頭にある場合は最初のIピクチャで代替表示するため、ClosedGOPとOpenGOPでは表示ルールが若干異なります（いずれも音声は同期する）。* 当プラグインは ffmpeg を使用しています。

Libav を用いている場合も先頭フレームが同期ポイントとなりますが、OpenGOP等のようにBピクチャ始まりであってもIピクチャで代替表示せず、壊れていても強制表示します。

=true インデックスファイルで指定されている映像ストリームと音声を同期します
=false 音声を同期させません（デフォルト）

DGIndexは先頭GOPのBフレーム部分をフレーム数として数える、という特徴があるのですが、それと同じ？

とか思っていたのでですが、 何かが違う・・・
どうも、DGIndexは完全なGOPからしか始まらない？のに対し、L-SMASHは上述の通り不完全なGOPからでも始まるようです。

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

サンプルのtsではDGIndexはlwiでkey=1となっているGOPから始まっているのに対し、l-smashはその１つ前のGOP(の一部)が存在するので。lwi(とソース)を眺める限りではpic=1がIフレーム、pic=2はPフレーム、pic=3はBフレームのようです。
音合わせはL-SMASHでデコードしたものを再エンコードするか、PTSを見て合わせるのが確実なんでしょうね。
ではそのためのスクリプトを作らねば。はて・・・どうしてこうなった・・・

あと、lwiを眺めていて知ったのですが、tsはPTS(再生時間)ではなく、DTS(デコード時間)の順番でデータが詰め込まれているようです。
Bは前後のPorIがないとデコードできないため、BBIBBPはIBBPBBとでいう順でデコードされます。

再生順に並べたとき
PTS  123456789ABCDEF
     BBIBBPBBPBBPBBP
DTS  120453786AB9DEC

デコード順に並べたとき(tsに入ってる順番)
PTS 312645978CABFDE
    IBBPBBPBBPBBPBB
DTS 0123456789ABCDE

ということはみんなPTSでは"BBIBBPBBPBBPBBP"、DTSでは"IBBPBBPBBPBBPBB"という並びで話をしているんでしょうね。
どっちも"BBIBBPBBPBBPBBP"になってるといえばそうなのですが・・・。
そんなことを考えていると、完全なフレームを得られるところから始めるm2vの実装も、存在するフレームからデコードするというL-SMASHも、GOP単位で考えようというDGIndexの考え方も、どれも正しいような。考え方の違いでしょうね。
いや、なんでこんなことを考え出したかというと、TSに入ってるフレーム(DTS)がBBIBB・・・で始まったときに5フレーム目まで正しい映像が出てこない、というのはなんでだろうと思ったので。(3つ目で完全なフレームが得られるのかと思ってた)

いろいろ新しくしたら速くなってきた

MPEG2DecPlusとUnsharpHQを新しくして、dfttestのdither_Cをもうちょっとチューニングしたら

MPEG2DecPlus_MPEG2Source(vsource,idct=4)
TDout =ScriptName+"_TDmetrics2.txt"
TFMout =ScriptName+"_TFMout2.txt"
TFM(mode=1,order=-1,PP=1,slow=2,input=TFMout,batch=true)
TDecimate(mode=1,tfmIn=TFMout,input=TDout,batch=true)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0) #unsharpHQ(STR=1.0)

というスクリプト(リサイズは1440x1080→1280x720)で28fps程度出るようになりました。(i7-4790@4.5GHz)
最適化対象はAVXで、AVX2用(FMA3を使う)にするともうちょっと(0.5%位？)早くなります。

何にせよ、ようやく実エンコード環境(x264と同時に走らせて)で24fpsを超えることができました(24.5fps)。
事前にTIVTCのhintsを求めてるため、本当のリアルタイムエンコードはできませんが(というかもっと時間がかかりますが)、

・・・あれ？
svml_dispmd.dllが見つかりませんとか言われる・・

確認していったら新しくしたNNEDI3_v0_9_4_47のnnedi3.dllがリンクしてるっぽい。
ってかintelってintelコンパイラか・・・
というわけでNNEDI3のノーマル版を入れたら治りました。
(ちゃんとreadmeに書いてあった・・・
Get Intel Parallel Studio 2017 redistribuables to use Intel versions.
https://software.intel.com/en-us/articles/intelr-composer-redistributable-libraries-by-version)

ついでにFluxSmoothを速くできるんじゃね？と思って探したらSSE化している人がいた！
・・・と思ったけど、x64専用になってる・・・
xmmも8以降がまんべんなく使われていて単純に32bit化するのは面倒そう・・・
いや、そもそも全部64bit化すればいいのか？とか悩みちゅう。


作ったdfttestはバグがありそうですし例によってバイナリ配布とかは面倒なので適当にdfttest.cのdiffから作ってください・・・↓

MPEG2DecPlusの速度とか

せっかくなので僕の環境(avisynth2.60 32bit i7-4790K win10 64bit)でMPEG2DecPlusの速度とかDGMpegdec比でどう違うのか確認してみました。

使ったのはこんなavs

vsource="test.d2v"
ref=DGDecode_MPEG2Source(vsource,idct=5).trim(1,5000)
target=MPEG2DecPlus_MPEG2Source(vsource,idct=4).trim(1,5000)
compare(ref,target,"","hoge5-4.log")
return last

参考：昔調べたDGMpegdecの各精度


DGDecodeのidct=5をリファレンスに取ったMPEG2DecPlusのPSNR[dB]

idct	Minimum	Average	Maximum	Overall
1,2,3,6,7: AP922整数	59.3174	63.8421	81.0069	63.2977
4: SSE2/AVX2 LLM	92.9447	101.995	111.8096	100.4447
5: IEEE 1180 reference	100.3483	111.1362	111.8096	110.6078

BSのアニメ(1920x1080)をデコードしたときの速度

idct	DGDecodeSSE	MPEG2DecPlus
3	284.398fps	255.885fps
4	187.730fps	225.459fps
5	138.206fps	102.459fps

というわけで、idct=4を使うならMPEG2DecPlusの方が速そうです。

追伸
sandybridge(i7-2600K)ではMPEG2DecPlus_MPEG2Source(idct=4)を使うと遅い・・・
haswellでは速い、ということはAVX2とかで最適化されているのかな？
→「アセンブラの排除による64bitへの対応、及びSSE2/AVX2でのintrinsicによる最適化。等」と書いてあったので、そうなのでしょう

TIVTCが64bit化

pinterf/TIVTC

僕が去年適当にやっていたのと同じようなことをちゃんとやってくれていました。
といっても僕の使い方ではTIVTCはあまりボトルネックではない(さらにこの間スクリプト内で並列処理にさせた)のであまり速度アップにはつながらないかもしれませんが。

一部のインラインアセンブリコードはC言語化して64bitへ、ということなので、MPEG2DecPlusもそうでしたし、最近の64bit化の流れはそういうところなのでしょうかね。
にしても(当たり前ですが)違う人がやっても同じアセンブラから同じようなコードが出来上がるんですね。


以下、更新履歴より。

v1.0.8 (20170429)

    Fix: TFM PP=2 and PP=5 (Blend deint)

v1.0.7 (20170427)

    fix crash in FieldDiff (in new SIMD SSE2 rewrite)

v1.0.6 (20170421) - pinterf

    project migrated to VS 2015
    AVS 2.6 interface, no Avisynth 2.5.x support
    some fixes
    x64 port and readability: move all inline asm to simd intrinsics or C
    supports and requires SSE2
    MMX and ISSE is not supported, but kept in the source code for reference
    source code cleanups

コンパイラの吐くアセンブリコードがほぼ手書きと同じレベルな件

というかもはや最適化はインラインアセンブリではなく、
「如何にコンパイラが最適化しやすいＣコードを書くか」ということに尽きる気がします。

というわけで21500ぐらいまで来ました。

何はともあれ、自分の環境(DevilsCannyon=Haswell)4.5GHzで普段使っているフィルタをかけて25～26fps出るようになったため、24フレームのアニメをフィルタをかけてリアルタイム再生できます。

参考にいつものフィルタは↓(TFMは事前処理(1pass目)なので2pass目では実質バイパス)
TFM(mode=1,order=-1,PP=1,slow=2,input=TFMout,batch=true)
TDecimate(mode=1,tfmIn=TFMout,input=TDout,batch=true)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ(STR=1.0)

7日間の残り

フロイド-スタインバーグ・ディザリング

ネックはdfttestのdither処理難ではないかというところで。
単純に最新のVCでコンパイルするだけで２割速くなりました。

が、そこからがなかなか短くならない・・・

コードの最適化もしているのですが、1000フレームのアニメをエンコードするのに
VC2015 communicateのプロファイラでモジュールのサンプル時間(1ms/sample)を測定したところ
dfttest 1.9：30123
dfttest VC14 /Ox /Arch:SSE2：25118
dfttest VC14 /Ox /Arch:SSE2 Optimized Code：22230
ほどかかっているようです。

ちなみにほかにも
fftw:39781
DGDecode:7348
FluxSmooth:3348
unsharpHW:3113
SplineResize:2457
となっています。
fftwは並列化されているためボトルネックにはならないのですが、やはりdfttestの関数自体の20s超が気になります・・・。
ディザリングをしなければこれが劇的に減るのですが、ね。

もうちょっとコードを弄ってみましょう。

というか、コンパイラで早くなったのはどうも浮動小数点の精度の所為な気がします。
というのも演算結果が変わるので・・・。
まぁ、SNは90dB以上=0.002%程度の差、1digit程度の差しかないため、実質問題はないかと。
/fp:preciseを指定しているのですが、謎です。

どこへ行こうというのかね？

MASM refference
x86/x64 SIMD命令一覧表　（SSE～AVX2）

・・・なんでこんなことを調べているのでしょうか・・・

visual studio expressを2015にしたんですよ。
んで、よくよく調べるとMASMってちゃんとVCに入ってるんですね。

というわけで今までMASM6.15でアセンブルしていたのを最新版でアセンブルしようと・・・したらできなかったという話です。

masm6では問題なくアセンブルできていたのに、その後継の14でできなくなるとは之如何に。

table1 sword 16384, 21407, 16384, 8867
movdqa xmm0,[table1]

というようなコードをアセンブルすると

エラー A2022 instruction operands must be the same size

と言われるという・・・
如何せん僕はwindowsのソフトをほとんど弄ったことがありません。
見たことがある(わかるわけではない)のも386のアセンブラぐらいというロートルなので、そもそもオペコードの意味が分からない・・・
とかいろいろグーグル先生に尋ねた結果、アドレスの書き方が良くない？らしいということが判明。

movdqa xmm0,xmmword ptr[table1]

というようにしたら治りました。

まぁ、あまり原因はわかっていないのですが。
_DATA SEGMENT PARA PUBLIC USE32 'DATA'とか書いてあるのが多少気になりますが、そもそも意味が分からない・・・

という話とは多分関係ないのですが、ひとまず、DGIndexをAVX2を有効にしてコンパイルすると
同一ソースで150MB/s→170MB/s@Haswell4.5GHzぐらいになりました。fpsは調べてませんが。
大体１割早くなった感じでしょうか。
AVX2>AVX=SSE2ぐらいで。

TIVTCも早くなったりするだろうか。
というわけで試してみたけど変わりませんでした。
そして別にコンパイラ最適かじゃなくて、Tdecimateの差分算出を並列処理させれば早くなるんじゃね？とか思って
ベクター化と並列化のメッセージ
を眺めている今日この頃。

深みにはまるだけな気がして仕方がない・・・

続・TDFM2EVFR的な何か

TDFM2EVFR的な何か
Loggia Logic

というわけで、自動でCMカットしてくれる素敵すぎるS/W、logoGuilloに対応してみました。
具体的にはlogoGuilloからTrimコマンドを受け取ってfps判定を含めて適当に加工して、出力しなおす、というスクリプトになりました。
この怪しいサイト構成を見ればわかっていただけるかと思いますが、用途としては24fpsでベタヌリな感じのもの以外は想定していません。

特徴としてはCMの頭出し検索をやるため、名探偵コナンのようにOP(ロゴあり)→提供(ロゴなし)と画面が続いている場合も切れづらい、というぐらいです。
理屈としては本編→CMは誤判定があっても、CM→本編の誤判定は少ないだろうという推定のもと、CM→本編となった時から遡って15s毎にシーンチェンジ検出を行い、15s単位でシーンチェンジがある範囲を探す、というようなところです。
一応fpsによる判定もついてますが、調査サンプルが少ないためいまいち効果は不明です。

それにしても昔自分で作ったスクリプトを今見直すと全部作り直したくなるのはどうしたものか。
やっぱりスパゲッティはいかんですね・・・。時間がないのでやりませんが。

とりあえずはこれで自動CMカット、自動VFRなことができます。
が、それをやりたいのならAutoVFRでいいんじゃないかとも思う今日この頃です。
実はちゃんと使ったことがないのでよくわかりませんが、AutoVFRはマニュアルプルダウンを目的に作ってるそうなので、楽に適当なファイルを作成したい僕の目的とは多少異なるかも？
まぁ、おいおい時間があれば使ってみたいところです。

TDFM2EVFR ダウンロード

あくまで自分で使うように作ったスクリプトなので、特殊な仕様が多々あります。
汎用品ではないので、各自の環境に合わせてお使いください。
出力結果には一切責任を持ちませんのでだまされたときはあきらめてください(汗

そして、referをblogspot.comだけにしていたためにblogspot.jpからアクセスしてくださった方々はダウンロードできない状態だったということに今気が付きました。
申し訳ない・・・。

更新履歴
120512 trim区間に「-1」を出力することがあったのを修正
120505 基本的にはfps判定アルゴリズムの見直し いろいろやったので記憶がない しばらくはこれで行く・・・予定
120501 デバッグ用のコードが入ったままで正常出力できていなかった(汗のを修正
120429 長さを一定以上にする処理の一部にバグがあったので修正
120428
・logoGuilloの出力を受け取って以下の処理をする
1.CMの頭出し検索
2.1の結果をもとにtrimコマンド、chapters.txt出力
・その他もろもろ

とりあえずできるかできないかを調べてみた

Loggia Logic: logoGuilloで検出パラメータ自動調整時に出力されるrawLmLvMap.csvについて

logoGuilloは希望通りにDGIndexに対応してくれたので実戦投入の準備を・・・。

というわけで、チューニングの良し悪しの判定方法？が公開されていたので、取り合えず実際に使う前に自分が持ってるロゴでちゃんと動くかどうかを確認。

BS4	BS11	BS-TBS
CBC	CTV	TVA

それなりに動作しそうですが、BS-TBSとCBCは微妙？
BS4は結構理想的なデータ。

意外なところでロゴが表示されていたりしなかったりしてその範囲を指定し忘れると判定精度が落ちる(当然ですが)ので要注意・・・。エンドカードとか・・・・

次は実際の判定精度を確認してみましょうか。


・・・ヤヴァイ、ほぼ完ぺきに検出してくれました。
もっと分かりにくいシーンチェンジとかの場合は失敗することもあるのかも？
ひとまずどうやって現在使っているスクリプトに組み込むかを検討しなければ・・・。

局ロゴ検出してCMカットしてくれるソフトが進化した

Loggia Logic: logoGuillo FAQ (v2.03向け)

局ロゴを検出して自動CMカットしてくれるソフトが痒いところに手が届くように進化してました。
v1からの変更点
・GUIフロントエンド搭載
・シーンチェンジ検出でカット位置修正
・カットマージンも自動補正に
・chapter.txt形式での出力対応
・avs2yuvとのパイプは自動生成
などなど。

v1の欠点だったシーンチェンジ検出対応に対応してくれたり、「CMを残したままにしたいならチャプター分割すればいいじゃない」的にchapter.txtで出力できるようになっていたりして進化の方向性が僕の理想とほぼ一致するという素敵さ加減。
後はDGDecodeに対応してくれたらよいのですが・・・。

精度もver2→2.03で良くなり、2のときはちょっと微妙だったのですが2.03になってから僕が試した限りではほぼ間違いないところで切ってくれます。

まぁ、様子を見つつ実戦投入してみましょうかね。

局ロゴ検出してCMカットしてくれるソフトが出てた

Loggia Logic: logoGuillo 導入マニュアル

aviutilプラグインの「ロゴ解析プラグイン」のロゴデータ(*.lgd)と、対象の動画データ(raw YV12)を入れるとロゴ有無を判定してロゴ有り区間のavisynth用のtrimスクリプトを吐き出してくれるS/Wです。

前々からほしかったんですよ、こういうソフト。
ロゴデータに対するオートチューニング(何を調整しているかは不明 判定閾値？)も備えており、白飛びしているような画面でロゴを判定しにくいときにはなるべく本編を残すように切るなど、なかなかよさげです。

とりあえず手持ちのCBCなロゴでは
-prm1A 0.1848602295 -prm1B 0.1978880617 -prm2B 1.0184204102 -cutMrgIn 0 -cutMrgOut 28～31？
が良さそうなのですが、ロゴ判定のタイミングは正確でも、ロゴが消えるタイミングが同じ局でも番組によって微妙に違ったりするみたいで(？)、結局番組ごとに微調整する必要がありそうです(それでも作業は1/13とかになりますが)。
僕のようなものぐさな人間に取っては面倒かも(マテ

シーンチェンジ検出も併せてやって・・・とか解決策を考えてもみましたが、結局のところ、CMカットしなくても、アニメ中に流れるCMはアニメ関係のが多いので、録っておいても良いんじゃね？と思い始めてしまいました。
ついでに、提供部分でロゴがないときなども切るかどうか、というジレンマが・・・。


まぁ便利なプログラムであることは確かなので、おいおい使ってみるのもアリですね。

DGDecodeのSSE最適化版がでたらしい

DGDecode.dll 1.58 decoding performance - Doom9's Forum
http://hank315.nl/ 最適化DLLの公開先

以前↓でavisynthでのdgmpegdecの速度を調べたのですが、
DGDecode on Avisynthの速度
avisynth.infoさんによるとGroucho2004 氏により最適化されたバージョンが出たらしいとのこと。

ただし3DNowのコードは削除・・・まぁ、今後のCPUでサポートされない奴は仕方がないでしょう。intelコンパイラのせいだそうですし。

24～27%向上ということですが、自分の環境ではどの程度？ということで以前と同じようなことをやってみました。
前と同じように

vsource="D:\hoge.d2v"
PluginDir="dokoka\avisynth\plugins\"
LoadPlugin(PluginDir+"DGDecode.dll")
DGDecode_MPEG2Source(vsource,idct=1～7).trim(5000,9999)
return last

ってなスクリプトを作ってavs2pipemod -benchを使ってX3350@3.2Gとi7-2600K@4.5Gで速度を調査しました。
ソースは地上波のアニメ(1440x1080)です。

Xeon X3350(≒C2Q9450)@3.2GHz+DDR2 800MHz 6GBでの結果

	idct=1 (32-bit MMX)	idct=2 (32-bit SSEMMX)	idct=3 (32-bit SSE2MMX)	idct=4 (64-bit Floating Point)	idct=5 (64-bit IEEE-1180 Reference)	idct=6 (32-bit SSEMMX (Skal))	idct=7 (32-bit Simple MMX (XviD))
DGDecode1.5.8	116fps	124fps	137fps	108fps	81fps	133fps	127fps
DGDecode1.5.8_SSE	130fps	139fps	157fps	121fps	89fps	154fps	144fps
速度比率	113%	113%	115%	112%	110%	116%	113%

i7-2600K@4.5GHz+DDR3 1600MHz 8GBでの結果

	idct=1 (32-bit MMX)	idct=2 (32-bit SSEMMX)	idct=3 (32-bit SSE2MMX)	idct=4 (64-bit Floating Point)	idct=5 (64-bit IEEE-1180 Reference)	idct=6 (32-bit SSEMMX (Skal))	idct=7 (32-bit Simple MMX (XviD))
DGDecode1.5.8	194fps	202fps	241fps	192fps	150fps	234fps	212fps
DGDecode1.5.8_SSE	222fps	234fps	277fps	215fps	165fps	279fps	243fps
速度比率	115%	116%	115%	112%	110%	119%	115%

10～19%速度が向上しています。
コンパイラの最適化すげぇ。
まぁ、その分危険性もはらんでいますが・・・。

PhenomII X3 720BE(定格=2.8GHz 3Core) + DDR2 800MHz 8GBでの結果

	idct=1 (32-bit MMX)	idct=2 (32-bit SSEMMX)	idct=3 (32-bit SSE2MMX)	idct=4 (64-bit Floating Point)	idct=5 (64-bit IEEE-1180 Reference)	idct=6 (32-bit SSEMMX (Skal))	idct=7 (32-bit Simple MMX (XviD))
DGDecode1.5.8	86fps	89fps	101fps	72fps	69fps	104fps	96fps
DGDecode1.5.8_SSE	94fps	98fps	112fps	78fps	75fps	117fps	105fps
速度比率	109%	110%	111%	108%	108%	112%	110%

PhenomIIでは大体10%UPぐらいでしょうか。

次に↓のようなスクリプトでリファレンスを1.5.8オリジナルのidct=5(IEEE-1180 Reference)に取って各idct時のPSNR(dB)を求めてみました。

LoadPlugin(PluginDir+"DGDecode.dll")
LoadPlugin(PluginDir+"DGDecode_old.dll")
ref=DGDecode_old_MPEG2Source(vsource,idct=5).trim(5000,9999)
target=DGDecode_MPEG2Source(vsource,idct=1).trim(5000,9999)

compare(ref,target,"","1.log")
return last

結果は

	idct=1 (32-bit MMX)	idct=2 (32-bit SSEMMX)	idct=3 (32-bit SSE2MMX)	idct=4 (64-bit Floating Point)	idct=5 (64-bit IEEE-1180 Reference)	idct=6 (32-bit SSEMMX (Skal))	idct=7 (32-bit Simple MMX (XviD))
PSNR Minimum	60.7201	60.7201	60.7201	94.1753	111.8096	61.6186	65.8953
PSNR Average	65.7081	65.7081	65.7081	107.8469	111.8096	65.8824	70.4569
PSNR Maximum	81.4593	81.4593	81.4593	111.8096	111.8096	81.4995	89.4543

となり、これは以前と同じような傾向ですね。
リファレンスからの差は
ref=5>4>>7>6≒1=2=3
な感じで、速度と精度の兼ね合いで好きなのを選べばって所で。

最後に念のため1.5.8オリジナルとSSE最適化版で同じidctでの違いを調査。

	idct=1 (32-bit MMX)	idct=2 (32-bit SSEMMX)	idct=3 (32-bit SSE2MMX)	idct=4 (64-bit Floating Point)	idct=5 (64-bit IEEE-1180 Reference)	idct=6 (32-bit SSEMMX (Skal))	idct=7 (32-bit Simple MMX (XviD))
PSNR Minimum	111.8096	111.8096	111.8096	94.9972	111.8096	111.8096	111.8096
PSNR Average	111.8096	111.8096	111.8096	108.3973	111.8096	111.8096	111.8096
PSNR Maximum	111.8096	111.8096	111.8096	111.8096	111.8096	111.8096	111.8096

・・・ん？idct=4時がちょっと違う・・・けどまぁ、実使用上は問題なさそうですし良いかな？
というわけで、最適化されて速度が向上したDGDecode、実戦投入してみましょう。


[2011-11-21追記]
～ffmpegsource最速伝説～
・・・ffmepgsourceが速いといううわさを聞き、試してみました。

上記で試したのと同じソースに対し、FFVideoSource("ソース.ts")で試したところ、
X3350@3.2GHzで486fps
i7 2600K@4.5GHzで1060fps
という素敵な速度を叩き出しました。
・・・惜しむらくはtsファイルではフレームアキュレートではないらしく、

•VOB, MPG: Seeking seems to be off by one or two frames now and then
•M2TS, TS: Seeking seems to be off a few frames here and there

とのことで、1フレームずれると大変なことになったりするような編集には向かなさそうです(？)
AVI, MKV, MP4, FLVなら良いらしいのですが。

TDFM2EVFR的な何か

Triticalさん万歳！といいつつ、TFMとTDecimateの出力ファイルから適当に24/30/60判定してEasyVFR用のデータを吐くスクリプトを作ってみました。
要はConvEV↓と機能的には大体同じことをやるだけのスクリプト。
EasyVFR & Its 自動記述プログラム 1.10e　エンコード初心者の部屋

・Avisynthな人向け
・言語はperlなので何やってるかは見てください しょーもないです
・主にTDecimateの出力を見て差分情報から24/30/60を判定 あとTFMからも何かもらう
・おぶじぇくと嗜好？なにそれおいしぃの
・スパゲティは好きですか？
・自分で使うために作っただけ
・CMカットが面倒でCMもそれなりにエンコードしようとしたらこうなった
なので期待はしないでください。


ダウンロード


更新履歴
110806 30pの判定をもうちょっとちゃんとやるようにした
110716 debug時の出力をコメントアウトするように変更
110712 公開してみる

使い方

1.↓みたいなavsでTFMとTDecimateの情報を出力
MPEG2Source(vsource,idct=4)

TFM(mode=1,order=-1,output="TFMout.txt")
TDecimate(mode=4,output="TDmetrics.txt")
return last


2.EasyVFR用の設定ファイルを出力
perl TDFManalyze.pl TFMout.txt TDmetrics.txt TDFMconf > output.txt



3.こっから先は好きな様にしてください
とりあえずEVFR2でtimecode出力

import(PluginDir+"EasyVFR_ver2.avs")
MPEG2Source(vsource,idct=4)

timecode="timecodev1.tmc"
import("output.txt")
trim(0,-1)
return last

function VFR24(clip clip){
clip
TFM(mode=1,order=-1,PP=7).TDecimate(mode=1)
return last
}

function VFR60(clip clip){
clip
temp1=last
interp=temp1.NNEDI3(field=-2,nns=1,nsize=4)
temp1.Tdeint(mode=1,type=3,mthreshL=8,mthreshC=8,edeint=interp,AP=64,APtype=1)
return last
}
function VFR30(clip clip){
clip
TFM(mode=1,order=-1)
return last
}

4.trim(0,-1)とtimecode="timecodev1.tmc"のところを変えたスクリプトを作り、
x264でtmcを指定してエンコード

x264 --tcfile-in "timecodev1.tmc" --timebase 1001/120000　encode.avs -o output.mp4

'110716
もうavisynth.infoさんに捕捉されてました。

'120429
ちょっとだけバージョンアップしました。
続・TDFM2EVFR的な何か

何故かまだやってる

何故か今週は再びVFRをやってました。

ConvEVでVFRまで自動でやってくれるスクリプトは完成しているのですが、某10・11・12話が同時放送された最終話でEDの60i判定に盛大に失敗してくれるのでなんでだ、と原因を調査していました。

途中で自分でTFMとTDecimateの出力を解析して範囲指定をするスクリプトを作ろうとか脱線していたので無駄に時間がかかっています。

現在の結論としては多分TFMをちゃんと設定すれば問題ない・・・といいな・・・。
多分TFMのMI(縞判定閾値)を80→30ぐらいにすれば大丈夫そうな気がします。

TFMには山ほどオプションがあって、今までは面倒なので
TFM(mode=1,order=-1,PP=7,slow=2)
でやってました。
が、TDecimateでVFR出力するときにはいろいろな判定が・・・

提供の静止テロップを60i判定するからなんでかな？と思っていたらどうやらクロスカラーを誤判定してたり、いろいろです。

あぁ、だんだんTFMoutからインターレース解除判定をもらってそれをベースに24p/30p/60i判定するスクリプトを作りたくなってきた・・・とりあえず作ってみようかな・・・
電波女とか、神のみとか、犬な日々、日常、アスタロッテ、そふてに、いろいは、星架か等、絵が綺麗な作品が多いとこういう意欲を掻き立てられます。
というか、見てる途中に突然スクリプトをいじりだしたりします。

それにしても一昔に比べると作画クオリティが段違いですね。良いことです。

DGDecode on Avisynthの速度

DGDecode - User Manual
Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD) > Remaining iDCTs.
Speedwise: SSE2/MMX and SSE/MMX (Skal) are usually the fastest. The IEEE-1180 Reference is easily the slowest.

精度と速度の兼ね合いになるというのは当たり前なのですが、とりあえず一番早いやつはどれなんだろうというのを調べてみました。

Athlon64だと32 bit simple mmx (xvid) が一番早かったよ(by UncasMS)、という話もあるのですが、
iDCT and its impact on encoding times [Archive] - Digital Video Forums
それは当時の最新CPUの話で、今はまた別です。

とりあえず手持ちのXeon X3350(≒Core2Quad9450)@3.2GHz + Win7 64bit + DDR2 960MHz 6GBで調べてみました。
方法は5748frameのd2vファイルに対し、

pa_pa_set(ScriptName+".csv",", ")
DGDecode_MPEG2Source(vsource,idct=1～7)
pa_pa("last")
return last

ってなスクリプトを作り、

avs2pipe_gcc.exe video %1 >nul

なバッチファイルで実験した結果

　       time[s]     fps
Total,  47.097303   122.0452  - 1: 32-bit MMX
Total,  44.569595   128.9668  - 2: 32-bit SSEMMX
Total,  39.992818   143.7258  - 3: 32-bit SSE2MMX
Total,  54.603527   105.2679  - 4: 64-bit Floating Point
Total, 119.720955    48.0116  - 5: 64-bit IEEE-1180 Reference
Total,  40.995461   140.2106  - 6: 32-bit SSEMMX (Skal)
Total,  45.682227   125.8257  - 7: 32-bit Simple MMX (XviD)

ってな感じに。
やはり、というか当たり前の話というか、SSE2が一番早い、という結果が出ました。


次に精度を調べるため。基準をIEEE-1180のリファレンスに取って、PSNRを求めてみました。

ref=DGDecode_MPEG2Source(vsource,idct=5)
target=DGDecode_MPEG2Source(vsource,idct=3)
compare(ref,target,"","hoge.log")

　      Minimum   Average   Maximum
PSNR:   57.2801   66.2722  105.7890   Overall PSNR:   64.8699    - 1: 32-bit MMX
PSNR:   57.2801   66.2722  105.7890   Overall PSNR:   64.8699    - 2: 32-bit SSEMMX
PSNR:   57.2801   66.2722  105.7890   Overall PSNR:   64.8699    - 3: 32-bit SSE2MMX
PSNR:  101.0178  111.6039  111.8096   Overall PSNR:  111.3280    - 4: 64-bit Floating Point
PSNR:   57.0100   66.0122  101.8096   Overall PSNR:   64.4922    - 6: 32-bit SSEMMX (Skal)
PSNR:   64.8524   70.5898  104.8199   Overall PSNR:   69.6416    - 7: 32-bit Simple MMX (XviD)

1-3は演算結果が全く同じようなので、一番早いのを使うのがよいのでしょう。
精度も必要という場合は 64-bit Floating Pointが誤差が1以内だったので良いのではないかと。


また、MPEG-2 VIDEO VFAPI Plug-Inも最近最適化されたという話とDGDecodeより早くなったというベンチマークをPOPさんのところでやっていたのですが、Core2でどうなのかはわからなかったためm2v.vfp v0.75経由で読みだしたときの速度もついでに調べてみました。
POP@4bit » Blog Archive » AviUtlプラグイン「MPEG-2 VIDEO VFAPI Plug-In」が大幅に高速化。ついにDGMPGDecを凌ぐ速度へ！

で、結果は

　     time[s]     fps
Total, 141.1712     40.7165   m2v.vfp(浮動小数点)
Total,  61.1951     93.9290   m2v.vfp(整数 32bit LLM)
Total,  54.6766    105.1273   m2v.vfp(整数 32bit AP-922)

となり、これを見る限り、SandyBridgeでは速くてもCore2系ではそうでもないっぽいです。

追加でCore i7 2600K@4.5G+DDR3 1600 9-9-9で7146frameな別の対象でやった結果は↓な感じで

194.465fps -1
208.223fps -2
250.210fps -3
183.132fps -4
135.801fps -5
241.795fps -6
215.911fps -7

Core2と傾向は同じですね。

そして、m2v.vfpも調べてみたのですが、POPさんのところのようにはなりませんでした。

69.548fps 浮動小数点
129.716fps 整数 32bit LLM
141.457fps 整数 32bit AP-922

・・・MTなavisynth.dllだとダメなんですかね？
SetMTmode(2,0)とか入れてみたけど変わらず。m2vのverが0.75だとダメだとか？
謎。

ま、僕はしばらくDGDecodeで行きますか。

2012/01/16追加
m2v.vfpが11月ごろにアップデートされ、速くなったらしいです。
MPEG-2 VIDEO VFAPI Plug-In

2011, 11/18 Ver. 0.7.5a
Intel Composer XE 2011 update.7 (icl ver. 12.1.1.258) でリビルド
(ver. 0.7.5 で遅くなったと報告があり、このバージョンで解消が確認できたため)

ってなわけで再調査。@i7-2600K@4.5GHzで上記とは別のソース。

107.043fps 浮動小数点
216.097fps 整数 32bit LLM
245.187fps 整数 32bit AP-922

をぉ、確かに0.75に比べて劇的に早くなってます。
というわけで上記のテストでm2v.vfpのパフォーマンスが振るわなかったのはverの所為ということで。
で、以前とソースが変わっているのでDGDecode1.5.8(SSE最適化版)でも1パターンだけ試験したところ、idct=3で275.801fps。・・・DGDecode最適化版の方が速いようです。