Bug beim Processing der gleichen Datei

[powerthrash4K]

Hallo lieber Selur,

ich habe jetzt mal versucht (ich habe die vollständig neueste dev von gestern draufgemacht, mit dem Vapoursynth-Upgrade vom 26.06.) bei einer Datei verschiedene Dateigrößen zu vergleichen. Dreimal dieselbe Datei zu processen führte früher dazu, dass die erste Datei, die dabei herauskam genauso hieß wie die Source logischerweise und die gleiche nochmal mit einem "..._new" hintendran gekennzeichnet wurde, sowie bei einer dritten mit "..._new_new". Plötzlich ersetzt aber die zweite Datei die erste Datei. Zusätzlich ist es nicht immer gegeben, dass die Queue weiterläuft, sondern nach jedem Process in der Liste stoppt. Ich weiß nicht, woran das plötzlich liegt. Zusätzlich ist jetzt auch die grafische Qualität etwas schlechter, wie man im folgenden Bild sieht. Links die neue Version (siehe Striche im Gesicht mit den lila Haaren und rechts im Vergleich die alte Version). Die Striche werden auf dem linken Bild schwächer und verwackeln auch mehr bei Bewegung. Es ist beides die gleiche Einstellung.

[Selur]

Keine Details zum Nachvollziehen, kein DebugOutput => keine Ahnung was Du machst.

[powerthrash4K]

Hier das Vergleichsbild. Ich mache gleich mal einen DebugOutput.

[Selur]

bei einer Datei verschiedene Dateigrößen zu vergleichen.

Eine Datei sollte sich nicht ändern. Wenn Du Reencodes einer Datei meinst mit unterschiedlichen Einstellungen meinst, sind die Unterschiede vermutlich auf die Einstellungsänderungen zurückz führen.

Die Striche werden auf dem linken Bild schwächer und verwackeln auch mehr bei Bewegung. Es ist beides die gleiche Einstellung.

Frage ist halt, ob die erzeugten Skripte&co auch identisch sind (bis auf Dateinamen).

Sorry, aber das Hilft auch nicht um:
a. zu versuchen das nachzustellen.
b. auch nur zu Ahnen was Du wirklich machst und was Hybrid daraus macht.

¯\_(ツ)_/¯

Cu Selur

[powerthrash4K]

Ich habe zwar 2x eine andere Einstellung gemacht, weil ich das mit lookahead level 2 testen wollte. Aber die selbe Einstellung führte zu einem anderen Ergebnis mit der alten Datei. Kann es nicht sein, dass Vapoursynth R77 hier Fehler hat?

---

Hier der DebugOutput:

[Selur]

Dass es an VapourSynth liegt, erscheint mir sehr unwahrscheinlich.

Der Debug Output enthält:
1. ein Encoding was läuft
2. das Erstellen und Ausführen eines zweiten Jobs
Beim zweiten Job wird adaptive-sharpen.glsl und RealESRGAN und zum Encoding:

"C:\Program Files\Hybrid\64bit\Vapoursynth\Lib\site-packages\vapoursynth\vspipe.exe" "C:\Users\Peter\AppData\Local\Temp\encodingTempSynthSkript_2026-06-27@10_03_07_6710_0.vpy" - --outputindex 0 -c y4m - | "C:\Program Files\Hybrid\64bit\NVEncC.exe" --y4m -i - --fps 23.976 --codec h265 --profile main10 --level auto --tier high --sar 1:1 --lookahead 32 --output-depth 10 --vbr 0 --vbr-quality 32.00 --gop-len 150 --ref 3 --bframes 3 --direct auto --bref-mode auto --no-b-adapt --lookahead 32 --mv-precision Q-pel --lookahead-level 0 --preset quality --colorrange limited --colormatrix bt709 --colorrange limited --cuda-schedule sync --output "C:\Users\Peter\AppData\Local\Temp\stars-jojos.bizarre.adventure.stardust.crusaders.egypt.hen.e24.1080p_edit_new_1_2026-06-27@10_03_07_6710_04.265"

verwendet.

Wenn Du wissen willst, ob der Unterschied an VapourSynth oder Deinen NVEncC-Einstellungen liegt, erstelle zweimal einen verlustfreinen Encode. Wenn sich die Ergebnisse unterscheiden liegt es an VapourSynth bzw. den Filtern, sind die gleich, liegt es, an Deinen Encodereinstellungen.


Generelle Anmerkung:

• Ich würde Empfehlen den temp-Ordner irgendwo hinzulegen, wo er außerhalb der Windows Struktur ist und eine Ausnahme für ihn in eventuellen Virenscannern&Co anzulegen.
  

Cu Selur

[powerthrash4K]

Hmm, könnte es unter Umständen wieder der gleiche Fehler sein, den ich damals mit Adaptive Sharpen hatte? Das könnte das Problem sein möglicherweise. Kannst du das prüfen, ob das wieder wie zuvor ist?

[Selur]

War es damals nicht das Problem, das der adaptive-sharpen.glsl nicht angewendet wurde,...?
Da er in dem Skript auftaucht, sehe ich da keine Parallele.

# adjusting color space from YUV420P8 to YUV444P16 for vsGLSLAdaptiveSharpen clip = core.resize.Spline36(clip=clip, format=vs.YUV444P16) # sharpening using GLSL Adaptive Sharpening with open("C:/Program Files/Hybrid/64bit/vsfilters/GLSL/parameterized/adaptive-sharpen.glsl") as glslf: glsl = glslf.read() glsl = glsl.replace('#define curve_height 1.0', '#define curve_height 1.0000') glsl = glsl.replace('#define anime_mode false', '#define anime_mode true') glsl = glsl.replace('#define overshoot_ctrl false', '#define overshoot_ctrl true') glsl = glsl.replace('#define video_level_out false', '#define video_level_out false') clip = core.placebo.Shader(clip, shader_s=glsl, width=clip.width, height=clip.height) from vsrealesrgan import realesrgan as RealESRGAN # adjusting color space from YUV444P16 to RGBH for vsRealESRGAN clip = core.resize.Spline36(clip=clip, format=vs.RGBH, matrix_in_s="709", range_in_s="limited", range_s="full") # resizing using RealESRGAN clip = RealESRGAN(clip, model=4, device_index=0, trt=True, trt_cache_dir=r"C:\Users\Peter\AppData\Local\Temp") # 7680x4320 # resizing 7680x4320 to 3840x2160

Falls Du etwas anderes meinst, verlinkt den Thread, um den es Dir geht.

Cu Selur

[powerthrash4K]

Deine Nachricht von 18:43 Uhr auf dieser Seite: https://forum.selur.net/thread-4360-page-4.html Ich glaube das war was mit dem boolean-Parameter damals

[Selur]

Okay, das ist auch das, was ich im Kopf hatte, aber es scheint nichts mit dem aktuellen Problem zu tun zu haben.