Einige Bugs/Fehler

[powerthrash4K]

Hallo Selur,

es handelt sich um die Version vom 27.07.25 (also das neueste Update):

1. Ich kann neben einem Upscale mit Real ESRGAN animevideov3 und bei anderen Resizern unter DeNoise kein KNLMeansCL mehr nutzen, wie vor der jetzigen neuen Version vom 27.07.25. Dabei erhalte ich dann eine Fehlermeldung.
2. Kann es sein, dass fast alle anderen Modelle außer Real ESRGAN animevideo v3 einer starken CPU-Last unterliegen? Während ich bei animevideo v3 maximal bis 70% komme, ist bei allen anderen, wie z.B. bei LD Anime Compact, AnimeJanai, generell VSGAN und VSMLRT die CPU-Last voll bei 100%. Ich weiß jetzt nicht sicher, ob das vorher bei allen so war, aber z.B. bei LD Anime Compact, war die Last auch wesentlich geringer. 

Ansonsten ist die Version sehr gut. Ich bedanke mich für das ständige Aktualisieren des Programms.

LG Peter

[Selur]

Die Beschreibung "Real ESRGAN animevideov3" sagt mir nichts.
Hybrids torch-addon kommt mit '2x_realesr-animevideov3', '4x_RealESRGANv2-animevideo-xsx4' und noch einigen anderen, aber keine, "Real ESRGAN animevideov3". Und RealESRGAN als Resizer kommt mit folgenden Modellen

values << QString("x4 ESRGAN");
  values << QString("x2plus");
  values << QString("x4plus");
  values << QString("x4plus_anime");
  values << QString("realesr-anime");
  values << QString("realesr-general");

  values << QString("AnimeJaNai c");
  values << QString("AnimeJaNai uc");
  values << QString("AnimeJaNai suc");

  values << QString("AnimeJaNai sharp c");
  values << QString("AnimeJaNai sharp uc");
  values << QString("AnimeJaNai sharp suc");
  values << QString("AnimeJaNai SD c");

  values << QString("AnimeJaNai v2 c");
  values << QString("AnimeJaNai v2 uc");
  values << QString("AnimeJaNai v2 suc");

  values << QString("AniScale2");
  values << QString("OpenProteus");
  values << QString("Ani4Kv2 c");
  values << QString("Ani4Kv2 uc");

Das von Dir beschriebene Model sagt mir nichts.

Compact Modelle sind i.d.R. weniger anspruchsvoll als nicht kompakte Modelle. i.d.R. ist die Last eher auf der GPU als auf der CPU,...
Je nach Modell kann die Last auf CPU und GPU aber sehr unterschiedlich sein.

=> Versuch mal den aktuellsten dev build, falls da das Problem auch noch auftritt, lies den Sticky und mach einen ordentlichen Fehlerreport mit DebugOutput, dann kann ich vielleicht mehr dazu sagen.

Cu Selur

[powerthrash4K]

Ich habe noch ein neues Problem:

Die Nutzung von vsMLRT als Filter unter Filtering/Vapoursynth/Other funktioniert scheinbar nicht, bei VSGAN funktioniert es z.B.:

1. Ich nutze zum Processing NVEnc/H265
2. Unter Crop Resize wurde die Auflösung für den Output auf 4K gestellt, Input war 1080p
3. Unter Filtering/Vapoursynth/Frame/Resize wählte ich den Resizer RealESRGAN und das Modell realesr-anime, Resizer darunter spline144, TensorRT und FP16 angehakt
4. Unter Filtering/Vapoursynth/Line/Darkening aktivierte ich FastLineDarken
5. Unter Filtering/Vapoursynth/Sharpen wählte ich aWarpSharp2 und AdaptiveSharpen aus
6. Unter Filtering/Vapoursynth/Other wählte ich vsMLRT aus, dazu BF16 angehakt, Backend TensorRT (andere Backends funktionieren auch nicht), Wahl des Modells 2x_AnimeJanai_V2_Compact_36k.onnx unter den Verzeichnis onnx_models

Auf Preview geklickt kommt dann folgende Fehlermeldung:

---

 
Processing crasht auch, beigepackt ist die HybridDebugOutput File!

---

Das mit der hohen CPU-Last ergibt sich nur noch bei Nutzung von DPID, aber das war vorher auch nicht so. Dabei wurde unter Vapoursynth/Frame der Resizer als DPID gewählt und Darken unter Line/Darkening ausgewählt. 
 
Das Problem mit KNLMeans entsteht scheinbar nur:
1. Wähle alle Punkte wie zuvor im ersten Ablauf, also:
Ich nutze zum Processing NVEnc/H265
Unter Crop Resize wurde die Auflösung für den Output auf 4K gestellt, Input war 1080p
Unter Filtering/Vapoursynth/Frame/Resize wählte ich den Resizer RealESRGAN und das Modell realesr-anime, Resizer darunter spline144, TensorRT und FP16 angehakt
Unter Filtering/Vapoursynth/Line/Darkening aktivierte ich FastLineDarken
Unter Filtering/Vapoursynth/Sharpen wählte ich aWarpSharp2 und AdaptiveSharpen aus
2. Unter Filtering/Vapoursynth/DeNoise wähle ich KNLMeansCL aus (Device Type: gpu)
3. Dabei entsteht ein Fehler und auch der Process klappt nicht
Nur bei Auswahl von accelerator statt gpu, lässt sich der DeNoise-Faktor nutzen

Zusätzlich funktioniert die Preview nicht mehr dauerhaft. Zuvor habe ich die Preview immer unter Filtering/Vapoursynth unten rechts mit CompareView ausgewählt. Bei jeder kleinen Änderung (z.B. andere Filterauswahl) konnte nach erneutem Klicken der Preview die Änderung angezeigt werden (in Sekundenschnelle), jetzt bleibt nach jeder Änderung der Preview-Bildschirm hängen und man muss diese erst schließen und dann nochmal neu aufrufen, zusätzlich ist die Preview-Anzeige langsamer geworden. Falls ich es nicht gesagt habe, es bezieht sich alles auf die neue dev.build vom 30.08.2025, bei der neuen bisherigen Build vom 27.07.2025 war die Preview noch schnell und gut und ohne Aufhängen.

[Selur]

Den Fehler beim KNLMeans Aufruf wenn 'gpu' ausgewählt ist sollte jetzt gefixed sein. (hab ne neue dev hochgeladen)
Wenn ich das torch-add-on oder die vs-mlrt version ändert, müssen die Engine files neu gebaut werden.
(Das Bauen sollte man nicht abbrechen, da es manchmal dazu kommt, dass man halbfertig engine files hat, was zu Problemen führt.)

Dies dauert länger für den ersten Preview, bei gleicher Auflösung und settings muss das engine file einer Version nicht neu gebaut werden.
=> Eigentlich sollten vs-mlrt und die torch filter das selber erkennen, aber

2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: WARNING: [Torch-TensorRT] - WARNING The logger passed into createInferRuntime differs from one already registered for an existing builder, runtime, or refitter. So the current new logger is ignored, and TensorRT will use the existing one which is returned by nvinfer1::getLogger() instead.
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: --- vsViewer error - END ---
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: [Torch-TensorRT] - WARNING The logger passed into createInferRuntime differs from one already registered for an existing builder, runtime, or refitter. So the current new logger is ignored, and TensorRT will use the existing one which is returned by nvinfer1::getLogger() instead.
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: --- vsViewer output - START ---
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: --- vsViewer output - END ---
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: --- vsViewer error - START ---
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: ERROR: [Torch-TensorRT] - IRuntime::deserializeCudaEngine: Error Code 1: Serialization (Serialization assertion stdVersionRead == kSERIALIZATION_VERSION failed.Version tag does not match. Note: Current Version: 240, Serialized Engine Version: 239 In nvinfer1::rt::StdArchiveReader::stdArchiveReaderInitCommon at runtime/deserialization/stdArchiveReader.cpp:49)
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: --- vsViewer error - END ---
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: [Torch-TensorRT] - IRuntime::deserializeCudaEngine: Error Code 1: Serialization (Serialization assertion stdVersionRead == kSERIALIZATION_VERSION failed.Version tag does not match. Note: Current Version: 240, Serialized Engine Version: 239 In nvinfer1::rt::StdArchiveReader::stdArchiveReaderInitCommon at runtime/deserialization/stdArchiveReader.cpp:49)
2025.09.01 - 10:40:40_Windows 10 Version 22H2 (64bit)_2025.08.30.1 - level 9: Failed to evaluate the script:
Python exception: [Error thrown at core/runtime/TRTEngine.cpp:119] Expected (cuda_engine.get() != nullptr) to be true but got false
Unable to deserialize the TensorRT engine


Traceback (most recent call last):
  File "src/cython/vapoursynth.pyx", line 3378, in vapoursynth._vpy_evaluate
  File "src/cython/vapoursynth.pyx", line 3379, in vapoursynth._vpy_evaluate
  File "C:\Users\Peter\AppData\Local\Temp\tempPreviewVapoursynthFile10_39_06_118.vpy", line 80, in <module>
    clip = RealESRGAN(clip=clip, model=4, device_index=0, trt=True, trt_cache_dir=r"C:\Users\Peter\AppData\Local\Temp") # 7680x3264
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "contextlib.py", line 81, in inner
  File "C:\Program Files\Hybrid\64bit\Vapoursynth\Lib\site-packages\torch\utils\_contextlib.py", line 116, in decorate_context
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Hybrid\64bit\Vapoursynth\Lib\site-packages\vsrealesrgan\__init__.py", line 347, in realesrgan
    module = [torch.jit.load(trt_engine_path).eval() for _ in range(num_streams)]
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Hybrid\64bit\Vapoursynth\Lib\site-packages\torch\jit\_serialization.py", line 168, in load
    cpp_module = torch._C.import_ir_module(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: [Error thrown at core/runtime/TRTEngine.cpp:119] Expected (cuda_engine.get() != nullptr) to be true but got false
Unable to deserialize the TensorRT engine

(das ist aus dem Crash aber der gleiche Fehler wie im Preview; wenn der Preview nicht geht, wird der Encode i.d.R. auch nicht gehen.)
liest sich aber so, als ob da was schiefgeht und er eventuell ein altes .engine-file verwendet.

Konnte mit der neuen dev (Hybrid_dev_2025.09.01-143959), vsmlrt (vs-mlrt_2025.08.31) torch add-on (VapoursynthR72_torch_2025.08.30) hie kein Problem bei Deinen Settings mehr nachstellen.

Dass die Nutzung von DPID abhängig von der Auflösung mehr Ressourcen verwendet, erscheint mir korrekt.
Wobei zu bedachten ist, dass DPID nur zum Downscalen verwendet wird, wenn man den als Scaler beim Upscaling auswählt, wird irgendein default verwendet. (sieht man im Skript)


=> leere mal Deinen engine-Fileordner (scheint bei Dir "C:\Users\Peter\AppData\Local\Temp" zu sein) und versuch es mit den aktuellen Versionen.
Generell würde ich auch empfehlen:
1. tmp-Ordner von Hybrid außerhalb der Windows Ordner zu legen
2. engine-Ordner in einen separaten Ordner und außerhalb der Windows Ordner zu legen.
3. für beide Ordner in eventuellen Virenscannern Ausnahmen festzulegen.

Cu Selur

Ps.: dev Version jetzt auf Hybrid_dev_2025.09.01-162736 aktualisiert.

[powerthrash4K]

Vielen Dank für die Mühe. Ich probiere es die Tage mal (spätestens aber am Samstag, dann gebe ich Bescheid, ob es dann besser klappt). Hast du schon gesehen, woran das liegt, dass es beim Preview zwischen kleinen Änderungen hängt (z.B. Auswahl CAS unter Sharpen statt Adaptive Sharpen), wenn man nur zwischen diesen schaltet und die Preview neu lädt? Hab gerade die alte 27.07.er Version drauf, da lädt die Preview nach Änderung in Sekundenschnelle tadellos neu. Bei der dev 08.30 freezed es dauernd und man kann nicht mehr gut zwischen den einzelnen Schritten vergleichen.

[Selur]

Hab nichts eigentlich nichts am Preview Code oder vsViewer geändert, was da einen Einfluss haben sollte.
Liegt vermutlich an irgendeinem Filter der aktualisiert wurde.
Und ja, die Reihenfolge der Filter kann einen großen Einfluss auf die Geschwindigkeit habe, besonders wenn man machine learning Zeug in Kombination mit Filtern, die mehrere Frames auf einmal abrufen/verwenden.

Cu Selur

[powerthrash4K]

Ich habe noch eine Frage:

Werden eigentlich die Filter, wenn ich z.B. RealESRGAN realesr-anime als Resizer ausgewählt habe und dann den Schärfefilter CAS, Adaptive Sharpen und aWarpSharp2 auswähle, nach einer sinnvollen Reihenfolge ausgeführt, sodass das Ergebnis optimal ist oder ist die Reihenfolge eher zufällig? Wenn dies zufällig ist, kann die Reihenfolge auch irgendwo bestimmt werden? Also z.B. aWarpSharp2 verstärkt erst die Linien, CAS regelt dann erst die Schärfe und Adaptive Sharpen schärft ganz am Ende adaptiv nach?

[Selur]

Werden eigentlich die Filter, ... , nach einer sinnvollen Reihenfolge ausgeführt, sodass das Ergebnis optimal ist oder ist die Reihenfolge eher zufällig?

Die Reihenfolge der Filter ist fest. Da die optimale Reihenfolge von Filtern sehr unterschiedlich und subjektiv ist.
Wüsste keine Methode, die es automatisch (und objektiv) ermöglichen würde zu sagen: "Reihenfolge X ist besser als Reihenfolge Y."

Hybrid erlaubt die Reihenfolge der Filter zu ändern unter Filtering->Vapoursynth->Misc->Filter-
Würde auch empfehlen [INFO] About Vapoursynth Filter Order/Queue zu lesen.

Cu Selur

[powerthrash4K]

Hallo Selur,

Das Problem mit dem vsMLRT-Filter unter Filtering/Vapoursynth/Other besteht weiterhin:

1. Ich nutze zum Processing NVEnc/H265
2. Unter Crop Resize wurde die Auflösung für den Output auf 4K gestellt, Input war 1080p
3. Unter Filtering/Vapoursynth/Frame/Resize wählte ich den Resizer RealESRGAN und das Modell realesr-anime, Resizer darunter spline144, TensorRT und FP16 angehakt
4. Die Filter-Optionen aWarpSharp2, AdaptiveSharpen und FastLineDarken benutze ich diesmal nicht
5. Unter Filtering/Vapoursynth/Other wählte ich vsMLRT aus, dazu BF16 angehakt, Backend TensorRT, Wahl des Modells 2x_AnimeJanai_V2_Compact_36k.onnx unter den Verzeichnis onnx_models

Du hast glaube ich um 16 Uhr die neue Version des Programms upgeloadet. Die Version von kurz davor, habe ich jetzt genutzt, also diese hier: Hybrid_dev_2025.09.06-131411

anbei sende ich wieder die Debug-File

Der Preview-Bildschirm bleibt immer noch nach jeder Aktualisierung (z.B. Filter-Deaktivierung oder anderen Filter aktivieren und dann erneut auf Preview klicken) stehen. Den tmp-Ordner habe ich bei mir mittlerweile geleert.

[Selur]

Debug output meldet:

y4m: failed to parse y4m header.
failed to initialize file reader(s).

was auf ein Problem mit Vapoursynth hinweist.

Das Vapoursynth script:

# Imports
import vapoursynth as vs
# getting Vapoursynth core
import logging
import site
import sys
import os
core = vs.core
# Import scripts folder
scriptPath = 'C:/Program Files/Hybrid/64bit/vsscripts'
sys.path.insert(0, os.path.abspath(scriptPath))
os.environ["CUDA_MODULE_LOADING"] = "LAZY"
# Force logging to std:err
logging.StreamHandler(sys.stderr)
# loading plugins
core.std.LoadPlugin(path="C:/Program Files/Hybrid/64bit/vsfilters/Support/vszip.dll")
core.std.LoadPlugin(path="C:/Program Files/Hybrid/64bit/vs-mlrt/vstrt.dll")
core.std.LoadPlugin(path="C:/Program Files/Hybrid/64bit/vsfilters/Support/fmtconv.dll")
core.std.LoadPlugin(path="C:/Program Files/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/LSMASHSource.dll")
# Import scripts
from importlib.machinery import SourceFileLoader
vsmlrt = SourceFileLoader('vsmlrt', 'C:/Program Files/Hybrid/64bit/vs-mlrt/vsmlrt.py').load_module()
from vsmlrt import Backend
import validate
# Source: 'C:\Users\Peter\Downloads\Upscaling\Lord.of.Mysteries.S01E01.German.ML.EAC3.1080p.WebDL.x264-Pudding-sama.mkv'
# Current color space: YUV420P8, bit depth: 8, resolution: 1920x816, frame rate: 25fps, scanorder: progressive, yuv luminance scale: limited, matrix: 709, format: AVC
# Loading C:\Users\Peter\Downloads\Upscaling\Lord.of.Mysteries.S01E01.German.ML.EAC3.1080p.WebDL.x264-Pudding-sama.mkv using LWLibavSource
clip = core.lsmas.LWLibavSource(source="C:/Users/Peter/Downloads/Upscaling/Lord.of.Mysteries.S01E01.German.ML.EAC3.1080p.WebDL.x264-Pudding-sama.mkv", format="YUV420P8", stream_index=0, cache=0, prefer_hw=0)
frame = clip.get_frame(0)
# setting color matrix to 709.
clip = core.std.SetFrameProps(clip, _Matrix=vs.MATRIX_BT709)
# setting color transfer (vs.TRANSFER_BT709), if it is not set.
if validate.transferIsInvalid(clip):
  clip = core.std.SetFrameProps(clip=clip, _Transfer=vs.TRANSFER_BT709)
# setting color primaries info (to vs.PRIMARIES_BT709), if it is not set.
if validate.primariesIsInvalid(clip):
  clip = core.std.SetFrameProps(clip=clip, _Primaries=vs.PRIMARIES_BT709)
# setting color range to TV (limited) range.
clip = core.std.SetFrameProps(clip=clip, _ColorRange=vs.RANGE_LIMITED)
# making sure frame rate is set to 25fps
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# making sure the detected scan type is set (detected: progressive)
clip = core.std.SetFrameProps(clip=clip, _FieldBased=vs.FIELD_PROGRESSIVE) # progressive
# changing range from limited to full range for vsVSMLRTFilter
clip = core.resize.Bicubic(clip, format=vs.YUV420P8, matrix_s="709", range_in_s="limited", range_s="full")
# setting color range to PC (full) range.
clip = core.std.SetFrameProps(clip=clip, _ColorRange=vs.RANGE_FULL)
# adjusting color space from YUV420P8 to RGBS for vsVSMLRTFilter
clip = core.resize.Bicubic(clip=clip, format=vs.RGBS, matrix_in_s="709", range_in_s="full", range_s="full")
# filtering using VSMLRT
clip = vsmlrt.inference([clip],network_path="C:/Program Files/Hybrid/64bit/onnx_models/2x_LD-Anime_Compact_330k_net_g.onnx", backend=Backend.TRT(fp16=False,device_id=0,bf16=True,num_streams=1,verbose=True,use_cuda_graph=False,workspace=1073741824,builder_optimization_level=3,engine_folder="C:/Users/Peter/AppData/Local/Temp")) # 3840x1632
# undo resizing 3840x1632 to 1920x816
clip = core.resize.Spline64(clip=clip, width=1920, height=816) # resolution 1920x816)
# changing range from full to limited range for vsVSMLRTFilter
clip = core.resize.Bicubic(clip, format=vs.RGBS,range_in_s="full", range_s="limited")
# making sure 0-1 limits are respected
clip = core.vszip.Limiter(clip=clip, min=[0,0,0], max=[1,1,1])
from vsrealesrgan import realesrgan as RealESRGAN
# adjusting color space from RGBS to RGBH for vsRealESRGAN
clip = core.resize.Bicubic(clip=clip, format=vs.RGBH, dither_type="error_diffusion")
# resizing using RealESRGAN
clip = RealESRGAN(clip=clip, model=4, device_index=0, trt=True, trt_cache_dir=r"C:\Users\Peter\AppData\Local\Temp") # 7680x3264
# resizing 7680x3264 to 3840x1632
clip = core.resize.Bicubic(clip=clip, format=vs.RGBS)
clip = core.fmtc.resample(clip=clip, w=3840, h=1632, kernel="spline", taps=6, interlaced=False, interlacedd=False)
# adjusting output color from: RGBS to YUV420P10 for NVEncModel
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, matrix_s="709", range_in_s="full", range_s="limited", dither_type="error_diffusion") # additional resize to allow target color sampling
# set output frame rate to 25fps (progressive)
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# output
clip.set_output()

sieht für mich eigentlich korrekt aus.
=> klappt er Vapoursynth Preview?
Vermute nicht.
Scheint, als ob es ein Problem gibt, wenn man sowohl bei VSMLRT als auch RealESRGAN TRT verwendet.
Vermute, dass ich da nichts machen kann.
Heute nicht zu Hause und morgen schaue ich erst mal auf das HAVC update.
Damit das gefixed wird, muss man vermutlich einen Bug Report bei:
https://github.com/HolyWu/vs-realesrgan und https://github.com/AmusementClub/vs-mlrt machen.
Vielleicht finde ich nächste Woche irgendwann Zeit da genug zu testen, um entsprechend Bugreports zu erstellen. (Werde versuchen rauszufinden, ob dies am Wechsel zu torch 2.7.x im torch-addon oder an einer der neueren Versionen von vs-mlrt liegt.

Cu Selur