NVIDIA DLSS Frame Generation (External Worker)
Real NVIDIA DLSS Frame Generation inside ComfyUI — 24 fps in, 48 fps out
- images
- motion_vectors
- interpolated_frames
- output_fps
- runtime_report
Your generated video is 24 fps and every motion reads a little stuttery, but re-generating it costs you another hour. That's the itch this node scratches: it runs NVIDIA's actual DLSS Frame Generation runtime on your frame batch and hands you back an interpolated clip at double (or triple, or quadruple) the frame rate. Not a RIFE model, not an approximation - the real nvngx_dlssg.dll temporal-interpolation engine that games use, bridged into ComfyUI through an external worker process.
Straight up: the name oversells it. "DLSS5" is how the experimental runtime circulates publicly, and this is an unofficial, GPL-3.0 Windows wrapper - not affiliated with NVIDIA. Where it goes beyond NVIDIA's own official RTX nodes for ComfyUI is the DLSS-G frame-generation path and the experimental neural-rendering pass. It's an alpha. Expect edges.
How it works
DLSS Frame Generation is a hardware-accelerated interpolation engine, not a diffusion model. For each pair of source frames it synthesizes the in-between(s) by warping with motion - which is why this node demands a second input most Comfy nodes don't have: motion_vectors.
You feed it an images batch plus the motion guide from the pack's DLSS 5 RAFT Motion Guide node (current-to-previous flow; R/G encode X/Y, 0.5 means zero motion). The node converts frames to RGBA, kicks off one dlssg-worker.exe process, and keeps that single native context alive for the whole sequence - no per-frame spawn. Frames and motion go over a binary pipe; the worker talks to the NVIDIA runtime and streams back the generated frames.
One detail matters: it detects scene cuts itself. scene_cut_threshold (default 0.28) compares each frame to the last by mean absolute difference; past that, temporal history resets and the node pads with duplicated source frames rather than interpolating across a hard cut and smearing everything.
The inputs that matter
Of the six, a beginner sets three:
multiplier- 2x, 3x, or 4x. Start at 2x. Multi-frame 3x/4x only works if your GPU, driver, runtime, and worker all support it, and it needs HAGS.input_fps(default 24) - used to computeoutput_fpsand timestamps. Set it to your source clip's real fps.runtime_fallback- "Fail on missing frames (recommended)" by default. That's the right call. The other option, "Hold previous frame", duplicates the last source frame to preserve duration, but the README is blunt that it produces visible judder and shouldn't be mistaken for successful interpolation.
The output is a triple: interpolated_frames (an IMAGE batch with (input_frames − 1) × multiplier + 1 frames), output_fps (input_fps × multiplier, wire it into your encoder), and runtime_report - a STRING that logs scene resets, disabled intervals, and the worker log. Feed the first two into a Video Helper Suite combine node and encode at the reported fps so duration matches the source.
Installing it
This is one of the more involved installs in the ecosystem, so don't skip setup. Windows 10/11, NVIDIA RTX, and a recent driver are non-negotiable; frame gen really wants Windows 11 and a 40- or 50-series card.
- ComfyUI Manager → install via Git URL
https://github.com/HECer/ComfyUI-DLSS5(the Registry listing wasn't approved at release, so search may not find it). Restart so the declared deps - numpy, opencv-python, py7zr, transformers, torchvision - install. - Queue the pack's one-click runtime setup node. It downloads the DLSS-G worker release and verifies its SHA-256.
- Drop a legally obtained
nvngx_dlssg.dllintoruntime/dlssg/, right besidedlssg-worker.exe. They must share one directory, and the installer never fetches the NVIDIA DLL for you - that's your homework. Don't grab a random DLL just because the filename matches.
Then run the DLSS Frame Generation Runtime Status node and confirm it reports READY before touching the generation node.
Where people get burned
- The runtime error that suggests "enable HAGS". The worker returns fewer frames than requested when the runtime decides it can't keep up or the environment isn't right - often hardware-accelerated GPU scheduling is off, or you asked for 3x/4x on an unsupported setup. Enable HAGS in Windows graphics settings and try 2x.
- "Runtime missing: dlssg-worker.exe / nvngx_dlssg.dll". Setup didn't run, or the files landed in different folders. Both must sit in the same
runtime/dlssgdirectory. - Temporal smearing across cuts. Lower
scene_cut_thresholdso more scene changes get caught and reset instead of being interpolated through. Higher = fewer resets, more artifacts at cuts. - Expecting game-engine quality. This estimates motion from pixels rather than reading engine-authored vectors, so fast chaotic motion can still ghost. It's a temporal-interpolation win, not magic.
If a single run keeps failing, the runtime_report output - not the console - is your best clue; it includes the worker's own log lines. Genuinely cool hardware plumbing when it works, and honestly a bit of a project when it doesn't.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| motion_vectors | IMAGE | — | |
| multiplier | COMBO | 3 options: 2x, 3x, 4x | |
| input_fps | FLOAT | 24.0001–240 | — |
| scene_cut_threshold | FLOAT | 0.280.01–1 | — |
| runtime_fallback | COMBO | 2 options: Fail on missing frames (recommended), Hold previous frame |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| interpolated_frames | IMAGE | — |
| output_fps | FLOAT | — |
| runtime_report | STRING | — |