21.05.2022, 15:00
(20.05.2022, 21:27)mogobime Wrote: Bei mir schwankt das auch schon während eines Laufs stark rum. Dieser Art von Bug scheint mir anderweitig auch manchmal zu begegnen, z.B. ist FFT3DGPU meistens mit prefetch(X,X+1) am stabilsten. Allerdings nur bis prefetch(6,7). Sobald frames auf 8 erhöht wird kackt es komplett ab, und auch mit (prefetch(X,X-1) oder noch weniger frames. Bei prefetch(X,X) hab ich ebenfalls stark schwankende Ergebnisse.
Aber ich schweife ab... Das komische ist halt, dass das Problem mit demselben Skript beim encoding mit X264/avs2yuv nicht auftritt, sondern nur mit avsmeter64. Ist das bei dir auch so?
EDIT: Ist halt irgenwie Käse, wenn ausgerechnet ein Benchmark Tool eingebaute "Bremsen" hat, die beispielsweise bei avs2yuv64 nicht auftreten...
Hab hier bisschen Murks zusammengeschrieben. Eigentlich war es so, dass wenn nach fft3dgpu noch weitere Filter im Skript sind, man z.B. direkt nach fft3dgpu prefetch(1,7) setzen kann und am Ende des Skripts prefetch(6).
Ab prefetch(1,8) und dann prefetch(7) wird's langsam, bzw. "gebremst".
ABER:
Hab mir das jetzt nochmal genauer angesehen, und das ganze scheint bei avsmeter in erster Linie mit der RAM Nutzung zusammenzuhängen.
Außer in dem Fall, dass man beim ersten Aufruf weniger frames als threads beim zweiten angibt, das scheint aus anderen Gründen unsinnig zu sein. Beispielsweise prefetch(1,4) kombiniert mit prefetch(5) bricht ein, genauso wie prefetch (1,2) mit prefetch(3) am Ende des Skripts. Ist aber nicht nur bei avsmeter so, sondern vermutlich generell unsinnig.
Ansonsten scheint mir das einfach genauso zu sein, wie früher zu AviSynth nonplus Zeiten. Zwischen 2 und 2,5GB RAM Nutzung durch avsmeter wirds grundsätzlich langsamer bzw. wackelig
Das ist was passiert, wenn ich prefetch(1,8) mit prefetch(7) kombiniere. Der zusätzliche prefetch(1,8) erhöht die RAM Nutzung und es sind dann deutlich über 2GB.
Genauso kann ich nur den normalen prefetch am Ende des Skripts weit genug hochdrehen, irgendwo zwischen 2 und 2,5GB RAM Nutzung wird's immer wackelig.
Das kenne ich wie gesagt alles schon von früher, da scheint sich bei AviSynth+ nichts geändert zu haben. Hatte damals mal meine ich mal eine experimentelle "Auto tune threads Funktion" vorgeschlagen, die die threads automatisch erhöht/reduziert bis der maximale Speed erreicht ist und/oder maximal 2GB RAM Nutzung erreicht sind (schneller wird's dann ohnehin nicht mehr - höchstens instabil), aber da ist damals nix draus geworden.
Eigentlich wäre es, wie mir jetzt bewusst wird, mit avsmeter, welches vor dem eigentlichen encoding beispielsweise die ersten 600 frames eines videos bencht, ein womöglich gut machbarer Ansatz gewesen, da das ja auch die maximale RAM Nutzung direkt ausgibt.
Die RAM Nutzung scheint der von avs2yuv mehr oder weniger immer zu gleichen (+-20 MB), daher kann man in der Beziehung relativ genaue Rückschlüsse ziehen.
Leider bremst avsmeter bei diesem speziellen Yuv420p10 60fps file auch schon bei unter 1 GB RAM Nutzung bzw. prefetch(2). Hier scheint avsmeter irgend ein spezielles problem zu haben. Exotische Codec-Variante?!?
Würde mal bei den benchmarks, die du mit deinem 10bit file gemacht hast auf die RAM Nutzung achten, würde mich nicht wundern, wenn es immer wackelt, wenn mehr als 2GB RAM durch avsmeter belegt werden.
Möglicherweise hast du durch die Reduzierung von prefetch frames von threads*2 auf threads*1 einfach die RAM Nutzung auf unter 2GB gedrückt.
EDIT: avs2yuv64 scheint den 2GB Bug auf den ersten Blick wirklich nicht zu haben, es scheinen selbst >3GB auf den ersten Blick ohne "Stotterbremse" zu funktionieren.
Werde bei Gelegenheit mal schauen ob ffmpeg diesen bug noch hat und ob's oberhalb von 2GB RAM Nutzung in irgendeinem Fall mal schneller ist.