😎 Sapsan-VFI Interpolate

Generated video at 16–24 fps has a certain stop-motion charm, and it wears off fast. The Sapsan-VFI Interpolate node fixes that the direct way: it invents a frame between every pair of input frames, so 24 fps becomes 48 and 16 fps becomes 32. Same clip, same duration, roughly double the smoothness.

It's the workhorse half of SnJake/SnJake_Sapsan-VFI, a compact x2 frame-interpolation pack under 😎 SnJake/VFI. The community standard for this job in video workflows is usually GIMM-VFI; Sapsan is a lightweight alternative - about 50 million parameters in a ~206 MB weights file, trained by the author on 2,700 videos. It's a genuinely useful tool for smoothing short Wan or LTX clips before upscaling, or for making slow-motion, and it's small enough that you don't need a big GPU to feel good about using it.

How it works

For every consecutive pair of frames, the model estimates optical flow in both directions at multiple scales (coarse to fine), warps each frame toward the target time t, then fuses the two warps with an occlusion-aware alpha blend plus a residual correction from a U-Net-style fusion net with a transformer attention block. Output is clamped to [0, 1]. It's the same two-stage flow-and-fuse architecture behind most modern VFI models, done small.

The inputs that matter

• images - your frame batch from a video loader (the example workflow uses VideoHelperSuite's LoadVideo → GetVideoComponents). It needs 3-channel RGB; no alpha.
• t - where in the gap the new frame lands, 0 to 1, default 0.5 (exactly halfway). Leave it unless you want the inserted frame biased toward one side, which is rare.
• match_brightness - default true, and keep it there. Generated video flickers; this rescales the predicted frame's brightness toward the inputs' mean so the in-between doesn't pulse.
• fps - optional, but wire it from GetVideoComponents anyway. The node then reports the correct doubled FPS on its fps output so your video writer labels it right. Skip it and that output is just 0.

The rest are set-and-forget: amp on auto picks bf16 (falling back to fp16) on CUDA, device on auto grabs your GPU, pad_multiple at 0 uses the value baked into the model config (8 - keep it a multiple of 8 if you touch it), and torch_compile stays off unless you're chasing speed on CUDA; if compilation fails it silently falls back to eager mode.

Outputs

You get two: images with 2N − 1 frames (one new frame per gap - so it's doubled minus one, not exact double), and fps = input FPS × 2 (or 0). Feed images into CreateVideo/SaveVideo to export. Want 4x? Run the output through the node again.

Installing and wiring it

Install is shared with the pack's loader node: ComfyUI Manager (search "Sapsan") or git clone https://github.com/SnJake/SnJake_Sapsan-VFI.git into custom_nodes/, then pip install -r requirements.txt - just pyyaml and huggingface_hub. The 😎 Sapsan-VFI Loader downloads the ~206 MB weights on first execution into ComfyUI/models/sapsan_vfi/ and hands the model to this node.

Common issues

• One frame in, nothing out - a single-frame batch is a pass-through by design, so this is expected, not a bug.
• Slow on CPU - the device dropdown has a cpu option and it works, but a few seconds per pair adds up. Leave it on auto with a GPU.
• Flicker between frames - that's what match_brightness is for; check it's on.
• Weird results at odd resolutions - the model pads internally to a multiple of 8; if you override pad_multiple, keep it a multiple of 8 (the config default is 8, matching the attention window).

It's two nodes, one download, and suddenly your 3-second clip doesn't look like a flipbook anymore.