Selur's Little Message Board

Lese mich da gerade ein bisschen in das Thema DirectShow, Filtergraphen usw. ein. Wikipedia kann man da echt vergessen, selbst der Artikel in der englischsprachigen ist totaler Mist (ist auch so markiert).
Hier geht es zwar eigentlich um ein TV capturing tool, aber es werden wenigstens für Laien verständlich ein paar Grundlagen erklärt, da versteht man auch über Directshow hinaus generell etwas besser die Arbeitsteilung verschiedener Komponenten beim Video Decoding:
https://www.dvbviewer.com/handbuch/Filter.html
Über die Erwähnung von Graphedit von MS in dem Text bin ich dann auch auf GraphEditPlus und GraphStudioNext gestoßen und hab z.B. rausgefunden, dass das erwähnte K-Lite Codec Pack bei mir dazu führt, dass praktisch immer libavcodec verwendet wird (denke da wurde durch das Codec Pack der Merit erhöht), was ja auch von LsmashSource verwendet wird.
Mit dem Unterschied, dass ich dann, wenn ich DirectShowsource nutze, auch als AMD Nutzer HW-Beschleunigung in Form von DXVA2-CopyBack oder D3D911-CopyBack nutzen kann, wenn ich das in der LibavCodec GUI einstelle.
Vorausgesetzt das file wird unterstützt. Teilweise ist die eingestellte HW-Beschleunigung nicht aktiv und mir ist nicht ganz klar warum. Ist das in dem Fall überhaupt so, dass die GPU sozusagen für jeden unterstützten Codec Schaltkreise mitbringen muss, und alles andere nicht funktioniert, oder werden durch DXVA / D3D9 nicht eher generelle Funktionen/Vereinfachungen genutzt, die auf der GPU schneller ablaufen?

Und außerdem frage ich mich jetzt warum lsmashsource diese Hardwarebeschleunigungen nicht anbietet, wo das mit libavcodec, auf das es ja zurückgreift, ja offensichtlich geht... Da kann man ja nur Intel QuickSynth und Nvidias Cuvid nutzen.

Was ich mich gerade abseits davon Frage:
Warum bricht bei mir mit AvsMeter und diesem lsmashsource basierten AVS-Skript und diesem 10 bit file die performance auf 10% ein, wenn ich prefetch(X) auf größer 1 stelle. CPU-Auslastung ist nur marginal niedriger und trotzdem ist prefetch(1) 10 mal schneller als alles >1.
Wenn ich das in meinem bench skript per avs2yuv an x264 pipe, hab ich mehr fps, obwohl der Großteil der CPU von x264 beansprucht wird...
Ist das bei dir auch so? Oder kommt AVSMeter mit 10bit input nicht gut klar?!?
Hab übrigens AVSMeter64.exe und Avisynth.dll aus dem Hybid Verzeichnis verwendet.

Achtung, das im Download beigefügte AVS-skript ist so ein gemoddetes skript, in dem am Anfang der cli-Aufruf steht. Wenn man das BENCH_AVS_VPS tool damit füttert um mit x264 zu benchen, spuckt das Tool ein/mehrere AviSynth-konforme AVS-Skripte (Je nachdem wie viele prefetch Einstellungen man mit start,step,end testet) mit bereits passenden Pfaden aus. Diese Skripte kann man dann auch AvsMeter füttern.
Sollte das bench skript wegen zu hoher CPU Auslastung die Messung nicht starten wollen, muss man maxCpuLoadBeforeTest bei den Uservariablen im Kopfbereich editieren und auf einen wert >25 setzen. Kann aber auch Sinn machen das abzusenken, je nachdem welche CPU Load das System üblicherweise in Ruhe hat, wenn gerade nicht irgendwelche Hintergrundprozesse starten und die Messung verfälschen. 100 schaltet das ganze komplett ab.

https://mega.nz/file/ltQkkLiD#nxn4abOjjk...VURKKCIl5w

AVSMeter: keine Ahnung, kannst mal schauen ob es mit ner neueren AVSMeter Version (https://forum.doom9.org/showthread.php?t=174797) auch passiert.
(Benchmarke Avisynth so gut wie nie,..)

Cu Selur

(20.05.2022, 18:38)Selur Wrote: [ -> ]AVSMeter: keine Ahnung, kannst mal schauen ob es mit ner neueren AVSMeter Version (https://forum.doom9.org/showthread.php?t=174797) auch passiert.
(Benchmarke Avisynth so gut wie nie,..)

Cu Selur

Nee, null Unterschied. prefetch(1) ~40 fps, prefetch(2) und prefetch(4) ~4 fps.

Hab mal:
10 mal laufen lassen und was ich wirklich merkwprdig finde ist, dass die durchschnittliche Geschwindigkeit pro pass start unterschiedlich ist.
Hab da einige Durchläufe die nur ~25fps haben und andere die 65fps haben.
Das merkwürdige ist, dass es scheint, als ob AVSMeter zwischendurch immer mal anhält,.. Als ob er den Speicher erst füllen müsste, je seltener es anhält desto flotter ist das Decoding,..
Keine Ahnung was da passiert, wenn ich Prefetch auf 1 stelle passiert das 'nachladen' nicht, aber damit sind halt zig andere Filter schnarch lahm.
Alles sehr inkonsistent. Vermute da sind noch irgendwo Problem mit dem Thread handling.

Scheint an der frames Anzahl:
zu liegen, wenn ich da nicht threads*2 sondern nur threads nehme scheint die Geschwindigkeit konstant hoch zu sein.

Cu Selur

In dem Mega Link ist übrigens auch das getestete video enthalten. Ist 10bit yuv420 60fps.
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...

Habe das 'anhalten' auch bei avs2yuv, aber viel seltener.

(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.

Hab auch bei ffmpeg diesen alten >2GB RAM Nutzung bug nicht mehr reproduzieren können, weder mit 8bit FHD resized to 4K, noch mit 10bit 4K, QTGMC, fft3dgpu und genug threads.

Hat wohl nur noch AVSMeter dieses Relikt aus früheren AviSynth MT Zeiten. Leider ist Groucho2004 seit er sein letztes update gepostet hat, mittlerweile mehr als 1 Jahr her, von doom9 spurlos verschwunden Da macht es wohl keinen großen Sinn das Problem dort zu posten...