RIFE Frame Interpolation
RIFE frame interpolation that downloads its own weights — finally
- images
- IMAGE
Want smoother slow-motion or a higher frame rate from frames you already generated? That's frame interpolation, and RIFE (Real-Time Intermediate Flow Estimation) is the standard tool for it. AUNRIFE wraps RIFE v4.7 as a single ComfyUI node, and its best trick is one most RIFE nodes get wrong: it fetches its own model weights. Point it at a batched image tensor, set a multiplier, and the rife47 or rife49 .pth file downloads from HuggingFace to ComfyUI/models/rife on first use. No separate manual model hunt, no "where do I put this file" step.
How it works, quickly: RIFE estimates optical flow between each pair of frames and synthesizes the in-between ones. The node takes your batched IMAGE (B,H,W,C), and for every adjacent pair generates multiplier - 1 intermediates - a multiplier of 2 doubles your frame count, 10 makes it ten times longer. Output is the interpolated sequence as an IMAGE tensor, ready to hand to a video combine node.
The inputs that matter: images (your frame sequence - needs at least 2 frames; with fewer it passes the input back unchanged), ckpt_name (rife47 or rife49, both run the v4.7 architecture), multiplier (INT, 2–10), and ensemble - a boolean that runs the model twice per intermediate frame and averages the results. Ensemble costs roughly double the time for modestly better quality; I'd leave it off while you're testing, then flip it on for the final render if the motion artifacts bother you.
A couple of implementation details worth knowing before you're surprised by them. It's adapted from the ComfyUI_Fill-Nodes pack (filliptm), with architecture credit to Practical-RIFE - so this isn't a reimplementation, it's the known-good integration. Frame pairs are processed sequentially behind a ComfyUI progress bar. And if inference fails for a pair - say you run out of VRAM - the node falls back to linear interpolation for that step instead of aborting the whole run. That's the good kind of failure mode, but it's also how you get a subtly softer-looking segment if you push the batch too hard; check for OOM warnings in the console if one stretch looks less sharp.
Where this slots in: feed it frames from a video helper (VHS) or an AnimateDiff/sequence output, interpolate, then recombine to video. It's not a video-length magic wand - it's a frame doubler, and a good one.
Install: ComfyUI Manager (search "AUN"), or cd ComfyUI/custom_nodes && git clone https://github.com/loz2754/AUN-ComfyUI-Nodes, restart. Dependencies are the pack's standard light set; the first run also needs internet access to pull the weights (~tens of MB, one-time).
Troubleshooting:
- First run appears stuck → it's downloading rife47; watch the console for the progress line.
- Output looks identical to input → you gave it fewer than 2 frames.
- A middle segment looks softer → likely OOM on that pair, node fell back to linear interpolation; lower the multiplier or batch size.
- Interpolation is slow on a huge batch → normal; sequential pairs + high multiplier is inherently serial.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | A batched IMAGE tensor whose frames will be interpolated. | |
| ckpt_name | COMBO | rife47 | RIFE model checkpoint to use (rife47 or rife49; downloaded from HuggingFace to ComfyUI/models/rife on first use). |
| multiplier | INT | 22–10 | Number of frames to generate between each pair (2 = 2x frames) |
| ensemble | BOOLEAN | false | Use ensemble for better quality (slower, runs model twice and averages results) |
| enable | BOOLEAN | true | When off, the input passes through unchanged and no model is loaded. Wire the MiniMaxH3 Inputs 'rife' output here so interpolation follows the loader toggle in the same run (no bypass timing delay). |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |