LC Frame Interpolate 🎞️

24 fps is what H3 and most video models hand you, and it reads as stutter the moment a face turns or the camera pans. Frame interpolation is the fix, and it's still the most-used post-processing step in the video stack - 2x RIFE on top of an upscale is basically the default finishing chain. The trouble is that almost every RIFE node in ComfyUI-land assumes you want exactly double. LC Frame Interpolate asks for a target frame rate instead: 30 to match phone footage, 48 or 60 for the smooth look, 23.976 if you're matching broadcast.

What it actually does

Nothing here is novel ML. The RIFE 4.26 architecture is vendored from Fannovel16's ComfyUI-Frame-Interpolation (MIT), which builds on hzwer's Practical-RIFE. The value is the plumbing around it, and there are three pieces of that worth understanding.

The frame plan. The node first works out how long the clip should be: your audio's length if you wired audio, otherwise frames ÷ source_fps. Then out_count = round(duration × target_fps). For each output frame it computes where that frame sits in time - k × source_fps / target_fps - which lands between two source frames at some fraction t, and RIFE is asked for exactly that t. That's why 24 → 30 doesn't drift and drift out of sync by the end of a clip. It also means there's no such thing as "the 2x setting".

Scene cuts. Before any of that, it shrinks every frame to a 64×64 greyscale thumbnail and compares neighbours. If the mean absolute difference exceeds scene_cut, that pair counts as a hard cut, and the in-between frames are held from one side instead of generated. A RIFE morph across a cut is a smeared ghost frame - this is the difference between a clip you can post and one you can't.

Resolution safety. Over 2048px on the long side it runs RIFE at half scale, which is the RIFE author's own advice. Dimensions that don't divide evenly by RIFE's internal scale get replicate-padded first; 2112×1216 genuinely broke 4.26 before that guard went in.

The inputs you'll touch

images is the clip. source_fps should be 24 for H3 and most video models - get this wrong and every calculation downstream is wrong with it. target_fps is what you want out. model defaults to rife426.pth, which downloads once (21 MB) into ComfyUI/models/rife/; if you already run ComfyUI-Frame-Interpolation it reuses that pack's ckpts/rife/ instead of downloading twice. The crossfade (no model) option just lerps between neighbours - instant, no weights, and visibly soft on any real motion.

scene_cut at 0.12 catches hard cuts and leaves fast motion alone. 0 turns it off. batch_size (default 4) is how many new frames go through the GPU per pass - that's your VRAM dial. And audio is optional but load-bearing: wire it and the output is made exactly as long as the sound.

Three outputs: images (your smooth clip, into LC Create Video or a save node), fps (the new rate - wire this into the save node's frame_rate, or you'll save 60 fps worth of frames at 24 and get a slow-motion clip), and info, a one-line summary of frames in, frames out, cuts held.

Install

ComfyUI Manager, search "ComfyUI LC Audio_Video Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC_AV_nodes

Then restart and check the console for [LC AV] total … nodes. One structural gotcha specific to this pack: __init__.py must sit directly in ComfyUI_LC_AV_nodes/, not inside a second nested folder - if you unzipped a zip on top of a clone, move the inner files up a level. This pack also ships no requirements.txt at all, only torch/numpy beyond stock ComfyUI, which makes it a genuinely low-risk install next to the usual video-pack dependency roulette. Offline machine? Drop rife426.pth into ComfyUI/models/rife/ yourself.

Where people get burned

The frame count explodes and takes your RAM with it: 5 seconds at 24 → 60 fps is 300 frames held as a single IMAGE batch in memory. Drop batch_size first; it changes the GPU pressure, not the output.

The audio-timing match cuts both ways. Duration comes from the audio when it's wired, and the frame plan clamps to the last source frame - so if you wire a track longer than the picture, you don't get an error, you get a freeze-frame tail. Wire the audio that belongs to that clip.

And tune scene_cut in both directions. Too low and it holds fast motion, which looks like stutter you just paid GPU time to create. Too high and it morphs a cut into a ghost. If a hard cut in your source is smearing, lower it; if a whip-pan is juddering, raise it.