Wan Advanced I2V (Ultimate)

This is the flagship node of the whole pack - the one behind the single highest-scoring Wan post in the corpus (+1833, r/StableDiffusion, January 2026): a 1280×720, 20-second, no-visible-seam clip in 340 seconds. If you've seen that thread or one of its many descendants, this is what generated it. Everything else in ComfyUI-Wan22FMLF is either a simpler version of this node or a helper for it.

What it actually solves

Wan 2.2 natively caps out around 81 frames (5 seconds at 16fps). The standard workaround is chaining: generate a clip, take its last few frames, feed them back in as the start of the next chunk, repeat. Doing that by hand means juggling frame counts, latent offsets, and the 4n+1 alignment Wan's VAE demands - get the math wrong and your stitched video is either too short or does something weird right at the seam.

This node rolls that whole loop into one place. It's the pack's answer to first/middle/last-frame conditioning plus a proper continuation mechanism (prev_latent, video_frame_offset) plus the SVI (Stable Video Infinity) integration that's what actually got it famous - SVI is EPFL's error-recycling technique for teaching Wan to correct its own drift instead of accumulating it, and this pack is one of the two or three places people actually run it from.

The inputs and outputs that matter

Standard Wan plumbing required: positive, negative, vae, width, height, length, batch_size.

The parts that make it "Ultimate":

• start_image / middle_image / end_image, each with an enable_start_frame / enable_middle_frame / enable_end_frame boolean toggle (all default true). These switches were added specifically so you can wire up all three image inputs once in a big workflow and flip individual ones off per-run without disconnecting anything.
• motion_frames (IMAGE, optional) and prev_latent (LATENT, optional) - the continuation hooks. Feed in frames/latent from the tail of your last chunk and this node picks up where it left off instead of starting cold.
• video_frame_offset - where in the overall (multi-chunk) timeline this segment starts. You bump this by the previous chunk's output length each time you loop.
• long_video_mode (combo, default DISABLED) - flip this on when you're chaining chunks; it changes how the node treats prev_latent/motion_frames.
• continue_frames_count (0-20, default 5) - how many frames of overlap/context carry from the previous chunk into this one, for continuity.
• svi_motion_strength (0-2, default 1.0) - SVI-mode-specific: how strongly motion from the previous chunk propagates forward. Below 1.0 is more stable/conservative; above 1.0 is more exaggerated motion - useful if your chained clips are reading as sluggish.
• The strength dials - high_noise_start_strength, high_noise_mid_strength, low_noise_start_strength, low_noise_mid_strength, low_noise_end_strength - work exactly like the simpler first-middle-last node: high-noise strength governs how hard a frame is enforced while motion/composition are being laid down, low-noise strength governs enforcement while detail is being refined. Defaults (0.8 high-mid, 0.2 low-mid) are tuned to avoid the classic middle-frame flicker.
• structural_repulsion_boost (1.0-2.0) - same motion-punch-up trick as the simpler node, high-noise-only.
• clip_vision_start_image / _middle_image / _end_image - optional CLIP Vision conditioning per frame.

Outputs are where this node earns its "Ultimate" name: alongside the usual positive_high, positive_low, negative, latent, it hands back trim_latent, trim_image, and next_offset - integers telling your downstream trim/save nodes exactly how much overlap to cut and what offset to feed into the next chunk's video_frame_offset. That's the piece that makes chaining a loop instead of manual arithmetic.

Installing it

ComfyUI Manager: search "ComfyUI-Wan22FMLF", install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/wallen0322/ComfyUI-Wan22FMLF

You'll need the Wan 2.2 I2V-A14B high/low-noise checkpoints and matching VAE (the README is explicit: prefer the official, non-quantized weights - quantization visibly hurts the frame-anchoring). If you're going for the full SVI long-video setup, you also need the SVI LoRA pair (Kijai's WanVideo_comfy repo hosts the HIGH/LOW rank-128 files) loaded into your model chain upstream of this node - this node builds the conditioning, it doesn't load the SVI LoRA itself.

Common issues

Chaining crashes ComfyUI, not the node. This shows up constantly in the community threads: people successfully render a dozen 5-second chunks and then the stitching/assembly step runs out of RAM or crashes ComfyUI outright, especially past a minute or so of total footage. One widely-cited report did 15 chunks (75 seconds of source clips) on 16GB VRAM / 64GB system RAM and had to stitch and upscale outside ComfyUI to get past it. If you're chaining long, budget for that and don't be surprised when the failure is in assembly, not generation.

Slow motion in the output. Not this node's fault directly - it's the standard interaction between LightX2V/speed LoRAs and Wan 2.2. If your chained clips read as sluggish, the fix people actually use is swapping in a smoothmix-style I2V checkpoint (skips needing lighting LoRAs at all) rather than fighting svi_motion_strength alone.

Getting video_frame_offset/next_offset wrong. If you wire this manually instead of piping next_offset straight into the next iteration's video_frame_offset, you'll get either a duplicated seam or a skipped one. Trust the node's own output for this - it exists precisely so you don't have to compute 4n+1-aligned frame math by hand.

Steps too high on the high-noise pass. The README's own advice: 2 steps is enough for the high-noise pass. More steps there measurably increases the odds of middle-frame flicker - this is a case where "more compute" makes the result worse, not better.