I2VLatentPatcher

The boring way to make a "long" Wan video is to generate a segment, VAE-decode the last frame, feed it back in as the next I2V reference, and repeat. It works, and it's how most of us started. It also quietly murders your footage: every cycle squeezes the tail through the VAE again, and because Wan's temporal compression is 4x, that one frame is literally four pixels mashed into one before being re-spread. Detail gets baked out, colors drift, saturation wanders - it degrades recursively, exactly like downsampling an image over and over.

I2VLatentPatcher takes the other route: don't decode at all. It's one of four nodes in synystersocks' ComfyUI-SocksLatentPatcher pack, and it's the one to reach for when you're chaining Wan I2V segments and want the seam to not bleed.

What it actually does

The node sits between the last KSampler of one generation and the first KSampler of the next. It copies the tail of the previous generation's latent straight into the reference slot of the new latent - the spot Wan's I2V conditioning expects its first-frame reference to live. No decode, no encode, no lossy pixel round-trip. The mechanism is embarrassingly small: a handful of tensor assignments that read index (FramesLength - 1) // 4 on the frame axis of the previous samples (that's the last latent frame, thanks to Wan's 4x time compression) and stamp it into the leading frame of the new samples. There is no model, no sampling, nothing to tune inside the node - it's a copy with a very specific address book.

The inputs that matter

Only three, and two of them are obvious:

• PreviousSamples - the LATENT from the last KSampler of the previous generation. This is what gets read for the tail.
• NewSamples - the LATENT you'd otherwise feed the next KSampler (your next segment's conditioning/empty latent). This gets patched.
• FramesLength (default 65, range 1–257, step 4) - the frame count of the previous generation. This is the one people trip on. If your last segment was 81 frames, tell it 81, not 65; the math that finds the tail frame is directly based on this number, and a wrong value reads the wrong latent frame.

The output is a single LATENT that plugs into the next KSampler's latent input. One node, one wire, done.

Install

The pack is three lines to install - it has no requirements.txt, no model downloads, no Python deps beyond the numpy/torch ComfyUI already ships. ComfyUI Manager: search "SocksLatentPatcher". Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/synystersocks/ComfyUI-SocksLatentPatcher

Restart ComfyUI. The heavy stuff (Wan GGUF quants, the Wan VAE, UMT5-XXL) is your existing Wan stack, not this pack.

Where people get burned

First: this is stamped EXPERIMENTAL = True and the author calls it a WIP. Expect to tune. Second, compatibility - the author claims Wan 2.1/2.2 (both high- and low-noise passes), Hunyuan, LTX Video and SkyReel, but explicitly not Wan 2.2 TI2V-5B. Third, it's not a speed hack: the demo runs on 8GB VRAM with GGUF quants, but the author's showcase clip took ~2.5 hours on a 3060 Ti 8GB. It exists to keep quality across a chain, not to make the chain fast.

One honest caveat about what it doesn't do: the patcher owns the latent reference only. The author's current recommended workflow still VAE-decodes the tail for the text-embedding conditionals and feeds them through the reference path - the node overwrites the latent reference on top of that. So it's "no VAE on the continuation latent," not "no VAE anywhere." If you're new to infinite-video, grab the pack's example workflow rather than trying to improvise the conditioning side from scratch.