🎞️ SM Video Base

Plain latent interpolation is a coin flip: you pick two endpoints, the sampler walks between them, and you pray the motion is what you pictured. SM Video Base is the pack's attempt to take the coin flip out of it. It lets you say exactly which reference video drives which frames of your interpolation, and how hard - deterministic, scripted motion control, no video model required.

It's the centerpiece of the IG Nodes → Steerable Motion category, and honestly the reason most people install this pack at all. It's also the most complex node here, so let's take it apart.

How it works

You feed it a base sequence of latents (your interpolation), up to 10 optional reference clips, and a text script. It then:

1. Encodes each provided video_frames_N through the VAE into latent space, resizing to match your base's spatial dimensions.
2. Parses your video_control script - one line per reference clip, in the format start_frame, end_frame, (mid_start_fraction, mid_end_fraction), (start_weight, mid_weight, end_weight). Line 1 controls video_frames_1, line 2 controls video_frames_2, and so on.
3. Builds a weight envelope per clip: a linear ramp from start_weight up to mid_weight, a hold at mid_weight, then a ramp down to end_weight - scaled by overall_video_weight.
4. Blends: base_latents * base_weight plus each weighted clip's latents, then normalizes by the total weights so you get a weighted average, not a pileup. Frames the script doesn't touch keep the base untouched.

The result is a new latent sequence where, say, frames 20–40 follow clip 1 while frames 50–150 follow clip 2, each fading in and out on your terms.

The inputs and outputs that matter

Required: base_latents (the sequence you're steering - wire in the output of an interpolation or any latent batch), vae, video_control (the multiline script; use SM Video Base Control to author and validate it), overall_video_weight (scales every clip's envelope - crank past 1.0 to push video influence harder), and base_weight (how much the base itself contributes).

Optional: video_frames_1 through video_frames_10, each an IMAGE batch from a video loader or frame sequence.

Outputs: latents (the blended sequence → straight into a KSampler), batch_count (the frame count of your base - handy for sizing loops), and weights_plot (a matplotlib-rendered chart of every envelope overlaid, so you can see what you wrote before you sample). Wire that last one into a preview node.

Where people get burned

• The format is strict. Seven comma-separated values per line, end_frame > start_frame, fractions 0 ≤ a < b ≤ 1, weights 0–1. Get it wrong and you get a clear error naming the line - annoying, but at least it's a clear error.
• A control line referencing an unprovided frame raises. And a clip with no control line is silently ignored. Keep the script and the inputs in lockstep.
• The node is loud. It prints [DEBUG] lines for every encode, every weight, every phase. Your console will look like a packet capture. Harmless, just noisy.
• This blends motion, it doesn't invent it. Your output is only as good as the reference frames and envelope you provide. Garbage clip in, garbage steering out.
• matplotlib is a hard requirement (it's in the pack's requirements.txt) - the weights_plot output depends on it.

Installing it

It's in IDGallagher/ComfyUI-IG-Nodes ("IG Interpolation Nodes"). Via ComfyUI Manager, search "IG Interpolation Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/IDGallagher/ComfyUI-IG-Nodes

Restart and let the requirements install. No model downloads for this node - the author's related project, ComfyUI-IG-Motion-I2V, is where the learned motion lives; here everything runs on the VAE you already have. And a fair warning to set expectations: the README is literally a smiley face and there's almost zero community discussion of this node by name, so you're reverse-engineering alongside everyone else. The defaults are sane, though, and the format is learnable in one sitting.