Nodes/ComfyUI-SocksLatentPatcher/VaceExt8fLatentPatcher
ComfyUI Node

VaceExt8fLatentPatcher

The VACE patcher from that 'infinite video' demo, explained

By synystersocks·Created 11 months ago·Updated 11 months ago· 14
VaceExt8fLatentPatcher
  • NewSamples
  • PreviousSamples
  • LATENT
PrevGenFramesLength65

This is the flagship of the ComfyUI-SocksLatentPatcher pack - the one the author's demo video actually used. That demo, a single car image extended into a long continuous clip with no upscaling, no interpolation and no fps correction, is the whole pitch in one file: VACE extension that doesn't slowly wash out its own tail.

Here's the problem the node solves. To extend a clip with VACE, the standard pipeline decodes the tail of your previous generation to pixels, runs it (plus your original reference) through the VACE conditioning encode, and then re-encodes it back. Every one of those decompress/recompress cycles costs you - with Wan's 4x temporal compression, four frames collapse into one latent frame and get rebuilt, and that repeated consolidation is what shifts color and kills detail over a long chain. VaceExt8fLatentPatcher patches the last 8 frames of the previous generation across in latent space instead, and overwrites the VACE reference dimension with the true last frame, so the model conditions on the actual tail rather than a VAE-reconstructed approximation of it.

What it actually does

Between the last KSampler of one generation and the first KSampler of the next, the node reads the previous latent, computes the last-frame index as (PrevGenFramesLength - 1) // 4 (Wan's time compression strikes again), and stamps the tail - the last two latent frames, which is what 8 pixel-frames compress into - into the leading reference frames of the new latent. It's the most thorough of the three VACE patchers in the pack: where the 4f touches two leading frames, this one writes across three, spreading the tail's channel data through the reference region. The implementation is a dozen or so tensor assignments and nothing else - no model, no decode, no sampling. All of the heavy lifting in the workflow around it (the Wan VAE, the VACE-Fun GGUF checkpoint, the UMT5 encoder) is your existing stack.

The inputs that matter

  • PreviousSamples - the LATENT from the last KSampler of the previous generation. Source of the tail.
  • NewSamples - the latent you'd feed the next generation's first KSampler. Gets patched.
  • PrevGenFramesLength (default 65, min 1, max 257, step 4) - the previous generation's frame count. Set it to what you actually generated; the tail-finder math reads it directly.

Output is one LATENT into the next KSampler.

Install

No requirements.txt, no model downloads - the pack is pure torch/numpy tensor code. ComfyUI Manager → search "SocksLatentPatcher", or:

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

Restart ComfyUI. The VACE-Fun GGUF quants the README's demo runs on (Q4_0/Q6_K of Wan2.2-VACE-Fun-A14B) are your existing VACE setup, not part of this pack.

Where people get burned

Three things, in order of how often they bite. One: the number has to match your model. VACE-Fun ships checkpoints expecting different reference-frame counts, and the 8f is for the 8-frame context - use it with the 4f/6f patchers' workflows and the reference layout will be wrong. Two: it's EXPERIMENTAL WIP and the author is explicit that the VACE variants need per-variant parameter tuning to stabilize - the pack's 8f example workflow (wan2_2_i2vToVaceI2vPatchReRef8F) is there because the right settings don't fall out of thin air. Three: it is slow. 8GB VRAM via GGUF works, but the author's own 8f demo took about 2.5 hours on a 3060 Ti. This node exists so the 25th extension looks like the 1st - not so the 25th extension comes fast.

Categorylatent/video

Inputs (3)

NameTypeDefaultDescription
NewSamplesLATENT
PreviousSamplesLATENT
PrevGenFramesLengthINT651–257

Outputs (1)

NameTypeDescription
LATENTLATENT