RTX Frame Generation

Frame interpolation is the cheap rung of video work, and it's the one everybody eventually wants: your clip generates at 12 or 16 fps because that's what the model gives you, and it looks like stop-motion. Doubling the frame count smooths it out without re-generating a single pixel.

RTX Frame Generation (DaSiWa_RTX_FrameGeneration) does that on NVIDIA's Video Effects SDK - the same hardware path behind the RTX upscalers everyone compared against SeedVR2 earlier this year and mostly preferred, for being fast and not looking synthetic. Unlike an ESRGAN pass, this is temporal interpolation: it reads two finished frames and synthesises what belongs between them.

What's actually happening

The node hands consecutive frame pairs to the SDK's VideoFrameGeneration effect and writes the generated frames between them. Two modes, and they are genuinely different jobs:

• frame rate multiplier inserts M−1 frames per pair, giving (N-1)*M+1 frames out for N in. Every original frame survives untouched, and both endpoints are preserved exactly. This is the mode you want 95% of the time.
• specific timestep inserts one frame per pair at a fractional position from 0.01 to 0.99, giving 2*N-1 frames. Only 0.5 is uniformly spaced; anything else produces unequal gaps that a constant-FPS encoder can't represent, and the node logs a warning rather than pretending otherwise.

The SDK returns borrowed output buffers, so the node copies and synchronises each generated frame before calling the effect again - boring plumbing that keeps frames from getting clobbered. It also uses blocking default-stream calls on purpose: the pack's own testing reproduced SDK error −12 with non-default streams, and it chose correctness over async throughput. One nice touch: a single-frame batch passes straight through without touching CUDA or loading the SDK, so a one-image test won't fail on a missing driver.

Inputs, and the two you'll get wrong

images wants an ordered IMAGE batch of decoded frames - Get Video Components output, a VHS loader, anything that produces frames. It is not a native VIDEO object, and the node has no FPS and no audio sockets. Decode upstream, route audio separately.

multiplier (2–16, default 2) is the knob, active only in multiplier mode. mode is the SDK quality preset - LOW, MEDIUM, HIGH, default HIGH - and these are frame-generation presets, not VSR levels; there's no promised speed or quality figure, it depends on your card and how much motion is in frame. automatic_shot_change_detection is on by default, which is what you want: a hard cut between two frames is a case where interpolation invents a cross-fade nobody asked for. shot_change is a separate blunt override that marks every submitted pair as a cut - it's for a single pair, not a list of cut indices.

device_id picks the CUDA device. image_encoding is 8-bit RGB, with 10-bit RGB (RGB10A2) offered only when your installed SDK supports it - 10-bit SDR precision, not HDR, and it doesn't make the IMAGE tensor smaller. Alpha is discarded, period.

Output is a single images IMAGE batch - one wire, into Enhanced Video Combine or any encoder.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/darksidewalker/ComfyUI-DaSiWa-Nodes
cd ComfyUI-DaSiWa-Nodes && pip install -r requirements.txt

Manager search is DaSiWa-Nodes; restart after. The pack as a whole asks for an NVIDIA RTX GPU with drivers 530+, and this node specifically needs nvidia-vfx installed with VideoFrameGeneration support - which is exactly the nvidia-vfx line in the requirements file. On Windows you may also need the NVIDIA Broadcast SDK; on Linux the pip package usually just works. If your SDK predates the feature, the node says so plainly and refuses to run rather than silently degrading, and nothing auto-installs for you. It's a one-author pack - darksidewalker, the DaSiWa handle behind the Wan 2.2 video workflows on Civitai - and the video-pipeline bias shows.

Where people get burned

The encoder FPS. This is the one that ruins an otherwise perfect run. The node can't tell your encoder anything, so after a 2× multiplier you have to set the encode FPS to source × M yourself. Forget it and your clip plays at half speed with beautiful smooth motion. Same logic for specific timestep at 0.5 - encode at source FPS × 2. And note the arithmetic: because the last original frame is retained rather than duplicated, container duration can end up one frame interval off.

Memory is not constant. The node stages the previous frame, the current frame and one SDK output, and it budgets VRAM then RAM for the full output batch - but your input and output batches still live in memory and may get cached by ComfyUI. Bounded processing, not streaming. use_mmap is off by default and is the last-resort disk tier if neither VRAM nor RAM can hold the result; it needs room for the whole output, so turn it on knowingly.

Multipliers compound fast. 16× on a 5-second clip at 24 fps means thousands of frames through the encoder and a file nobody needs. 2× is the sane default, 4× is a deliberate choice. And don't ask for non-midpoint timesteps and then complain - a constant-FPS container cannot hold unequal intervals.