EMA-VFI Interpolate

If the Tween pack had a "I'm in a hurry and my GPU is small" option, this is it. EMA-VFI Interpolate runs the EMA-VFI frame interpolation model (CVPR 2023, MCG-NJU), which trades a little robustness on extreme motion for being meaningfully faster and lighter than the pack's quality-first options - roughly 1.5GB VRAM per frame pair and noticeably quicker wall-clock times. For the classic use cases - 24→48fps on normal footage, slowing things down, smoothing a pan - it's often the pragmatic pick, and plenty of people run it as their daily driver instead of the fancier models.

Mechanically it works the same way as every pairwise interpolator: EMA-VFI estimates inter-frame motion (via attention that extracts both motion and appearance features, hence the name) and synthesizes the frame in between. multiplier picks 2x/4x/8x (recursive 2x passes), and the output count is the familiar 2N−1, 4N−3, 8N−7.

The inputs you actually touch:

• model - from the Load EMA-VFI Model node. Wire that first.
• multiplier - 2x is one pass; 4x and 8x recurse. More frames, longer waits.
• batch_size - pairs processed at once. Start at 1, raise until VRAM fills. The README's tiering applies: 1 for 8GB, 2–4 for 24GB.
• chunk_size - process in chunks of N input frames to bound VRAM (0 = off). Output still assembles in RAM, so use the Segment node for real RAM relief.
• keep_device / all_on_gpu - speed-for-VRAM trades. all_on_gpu is a 48GB+ luxury.
• source_fps / target_fps - set both (like 24 → 60) and it auto-computes a power-of-2 oversample and picks the nearest frame per target timestamp, overriding multiplier. Downsampling works too.

Outputs are images (the finished batch → VHS Video Combine), oversampled (pre-FPS-selection frames, same as images in plain multiplier mode), and elapsed_seconds.

Install. Search "Tween" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Ethanfel/ComfyUI-Tween
pip install -r requirements.txt

Restart. The model auto-downloads from Google Drive to ComfyUI/models/ema-vfi/ on the first loader run - the loader picks the large ours_t.pkl by default. You'll want VideoHelperSuite for loading and encoding the video.

Where people get burned: EMA-VFI is "less robust on extreme motion" - fast cuts, big jumps, and frantic camera moves can smear where BIM-VFI or SGM-VFI hold up. That's the documented trade, not a bug. And if the output looks subtly off, check which checkpoint the loader grabbed: the _t variants support arbitrary timesteps, the non-_t ones are fixed at the 0.5 midpoint, and mixing that up while assuming you're getting flexible timing is a real source of confusion.