Blend Latent Chunks (Pre-Decode)

If your long Wan videos come out with a visible flash or a double-exposure blob where two chunks meet, you've probably been joining them in the wrong place. This node is the fix: it merges two video chunk latents together along the time axis, before the VAE decode. You decode once, on the joined result, instead of decoding two chunks and hoping the seam hides itself.

It's part of the VideoChunkTools pack, which exists because I2V models like Wan 2.1/2.2 have a native context of about 81 frames and visibly snap back toward the start image past that - the "context window reversal" problem. The rolling-reference trick is to generate chunk by chunk, feeding each chunk's last frame in as the next reference, then stitch. This node is the stitching step for people who want to join in latent space rather than pixel space.

Why blend pre-decode at all

Latent joins beat pixel joins for two reasons. First, you avoid decoding each chunk separately and re-encoding, which is where artifacts creep in and where your GPU time goes. Second, the Wan VAE compresses time by ~4x: N frames become ((N-1)//4)+1 latents and decode back to (T_lat-1)*4+1 frames. That's the arithmetic behind the famous "111 frames → 28 latents → 109 frames" surprise. Blend in latent space and you're working with the compressed timeline directly, which is cheaper and - with the right mode - cleaner.

The inputs that matter

• latent_a / latent_b - the two chunk latents straight out of your samplers. Note the tooltip math: overlap_frames is in latent temporal frames, so for Wan take your pixel overlap and divide by 4 (16px → 4 latent). Default is 4, and honestly that's a fine place to start.
• blend_curve - this is where the node earns its keep:
  • hard_cut (default) - clean cut at the overlap midpoint, zero interpolation. Recommended for rolling reference, because both chunks were conditioned on nearly the same frame in the overlap zone, so there's nothing to dissolve.
  • slerp - spherical linear interpolation. This is the diffusion-proper blend; it preserves latent vector magnitude and avoids the washed-out frames that plain lerp produces. The one you want if the two chunks contain genuinely different content.
  • linear, ease_in_out, sigmoid - alpha-blend crossfades in latent space. Fine, but if you're crossfading you probably wanted BlendVideoChunks in pixels instead.

Wire both sampler latent outputs into it, then feed the single latent output into one VAE decode. You also get total_latent_frames back as an INT if you want to sanity-check the count.

The trap

It expects 5D video latents [B,C,T,H,W] and will raise an error if you feed it 4D image latents. That's a feature dressed as a bug - it's telling you this node is for video, not stills. Also keep overlap_frames smaller than the shorter chunk's temporal length, or the slicing breaks.

Installing it

Search "VideoChunkTools" in ComfyUI Manager and hit install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/gregtee2/ComfyUI_VideoChunkTools.git

Restart ComfyUI. No pip dependencies - it's plain PyTorch, which you already have. The whole core pack loads fine without WanVideoWrapper; only the two Wan-specific nodes need that extra install.

If your seams are invisible with hard_cut, great, you're done. If you're blending content that genuinely differs between chunks, slerp is the upgrade path. The name is accurate, and that's rarer than it should be.