RIFE_VFI

RIFE isn't a generator, it's the node you bolt onto the tail end of a video pipeline to make choppy 16-24fps AI clips look like they were shot at 60. It invents the frames between the frames you already have, using optical flow instead of diffusion, which is why it's fast - seconds, not minutes, for a whole clip.

The mechanism is simpler than a diffusion model and that's the whole appeal. RIFE (Real-Time Intermediate Flow Estimation) estimates the motion between two consecutive frames and warps pixels along that flow to synthesize what would sit halfway (or a quarter, or an eighth) between them. No prompt, no sampler, no model of "what should be here" beyond the two real frames you gave it. That's also where it falls apart: heavy occlusion or fast, tangled motion - crossing limbs, whipping hair - is exactly what optical flow struggles to track, so you'll see smearing or ghosting on that kind of footage no matter how you tune it.

Where it fits: generate your video at native fps with Wan, LTX, Hunyuan, or AnimateDiff, then two optional polish passes at the end - upscale for resolution, interpolate for smoothness. Order isn't fixed, but RIFE is almost always last, right before you save or preview. It's not the only option for that slot: if you want the best possible interpolation and don't mind extra compute, GIMM-VFI is what people reach for instead; if you want RIFE at max speed and don't mind a TensorRT export step, a TensorRT-compiled RIFE variant floats around too. This node sits in the middle - plain PyTorch, no export step, reasonably fast out of the box.

One thing worth knowing about this specific pack: it's probably not the RIFE node you've already seen in someone else's workflow. The much more common one ships inside Fannovel16's ComfyUI-Frame-Interpolation pack - and this node's own category (ComfyUI-Frame-Interpolation/VFI) and its model files come straight from that pack's GitHub releases. er1cw00's version is essentially a standalone reimplementation of that one node, with a few extras layered on: batch inference, float16/bfloat16 support, and optional torch.compile. If you already have Frame-Interpolation installed you don't need this too - it's for when you want RIFE specifically without pulling in a whole extra node pack for it.

The inputs that actually matter: frames is your IMAGE batch, whatever came out of your VAE decode, in order. ckpt_name picks the RIFE model version - rife426.pth is the newest and generally the best default, but it's also the one version that can't use ensemble mode; the README is explicit that ensemble gets force-disabled on it regardless of the toggle. multiplier is the whole point of the node: 2 doubles your frame count (24fps becomes 48fps), 4 triples the frames in between, and so on. ensemble trades a bit of speed for smoother output by running flow estimation in both directions - leave it on unless you're on 4.26 or in a hurry, at which point fast_mode is the other speed/quality lever, doing roughly what it says on the tin.

The dtype dropdown deserves a second look because its default is bfloat16, which only runs cleanly on RTX 30-series and newer. Older card, drop it to float32 (safe, slower) or float16. clear_cache_after_n_frames and batch_size are your VRAM/throughput knobs for long clips: lower batch_size and a tighter clear-cache interval if you're OOMing, raise batch_size if you've got headroom and want more throughput. torch_compile is a "trust the process" toggle - its own tooltip admits the first run gets slower while it compiles, then 10-30% faster after, so don't judge it off one test clip. The one optional input, optional_interpolation_states, takes an INTERPOLATION_STATES connection for skipping specific frames instead of interpolating everything uniformly; a niche control most people never wire up. Output is a single IMAGE stream - the interpolated sequence - ready for a video-combine or save node.

Installing it is the standard drill: search "ComfyUI-RIFE" in ComfyUI Manager, or clone it by hand into custom_nodes/ and run pip install -r requirements.txt (torch 2.0+, einops, packaging, numpy - nothing exotic). No model download up front: the first time you actually run the node with a given ckpt_name, it fetches that .pth from GitHub releases into ComfyUI/models/rife/ on its own. Convenient until your network can't reach GitHub, in which case the run just fails on model load - grab the file manually and drop it in that folder yourself.

A couple of real gotchas worth knowing going in. Switching ckpt_name, dtype, or torch_compile between runs forces a full model reload, so if you're iterating on the rest of the workflow, pin those three and only touch multiplier or scale_factor - otherwise you're paying the reload tax on every single run. And if bfloat16 throws odd errors or produces garbage frames, that's almost always a pre-Ampere GPU sneaking through on the default - switch dtype and move on.