WanV2V: Iter Control Group

Wan's native context is 81 frames. That's about three and a half seconds at 24 fps, and it hasn't moved - not in 2.1, not in 2.2, not ever since. So if you want a continuous minute of video, you don't generate it in one pass; you generate it in overlapping chunks and stitch them back together. That's the entire premise of the WANv2v Video Stitcher pack, and WanV2VIterControlGroup is the node doing the chopping. It's the heart of the kit.

What it does is build one chunk per iteration. You hand it the full control frame sequence (controlnet_images) plus the previous sampler's output (prev_output), and it returns the exact slice of frames you should feed into this iteration's KSampler or VACE pass. The clever bit is the overlap. Each chunk starts not at a clean boundary but with the last overlap_size frames of the previous sample, so the model always sees a real continuation of what it just made instead of a cut to fresh territory. Those duplicated frames are the seam, and the Merge De-Overlap node drops them at the end.

Mechanically it's simple arithmetic: step_size = chunk_size - overlap_size, and iteration iter covers frames [(iter-1)*step_size, (iter-1)*step_size + chunk_size). Iteration 1 just slices from the control images. Later iterations prepend the tail of prev_output and fill the rest from the control sequence, padding by repeating the last frame if the source runs dry - that's the "conclusive stitching" the README mentions for the final iteration, so your last chunk is still a full chunk_size long.

The inputs that matter:

• chunk_size (81 default) - set it to what your sampler actually handles. 81 is Wan's native context and the pack's default for a reason.
• overlap_size (8 default) - the seam width. You must use the same value in Merge De-Overlap later, or the stitch math breaks.
• iter (1 default) - 1-based. Bump it for each new chunk; the node doesn't count for you.
• controlnet_images - your full frame sequence, the master copy.
• prev_output (optional) - the previous iteration's sampler output. This one is easy to get wrong: it's not the previous control group, it's the actual video frames your last KSampler/VACE pass produced.

Two outputs matter. control_group is the IMAGE batch that goes into this iteration's sampler as the control/conditioning video. info is a STRING summarizing the frame ranges, drops and padding - wire it to a text display and glance at it once, because it's the fastest way to spot a chunk that came out the wrong length. The third, edit_mask_batch, is a MASK: by default iteration 1 is all white (everything editable) and later iterations lock the overlap region black so a VACE inpainting pass doesn't re-edit the seam. Pass a mask_master in and it splices from that instead, still prepending black frames over the overlap.

Install is the pack standard, no model downloads - this node never touches a weight, it only rearranges batches you already have:

cd ComfyUI/custom_nodes
git clone https://github.com/Kishor900/comfyui-wanv2v-video-stitcher

Restart ComfyUI and it appears under WanV2vControlnetManager/WAN. ComfyUI Manager has it too - search "ComfyUI WANv2v Video Stitcher".

Where people get burned: forgetting to increment iter (every chunk comes back identical), or feeding the wrong thing into prev_output (the overlap never carries, and you get hard jumps between chunks instead of a smooth stitch). Also keep chunk_size honest - if you tell it 81 but your sampler only fits 33, the sampler is the limit, not this node. And when a run "finishes" but the tail looks like a held frame, that's the repeat-last-frame behavior doing its job; it's a feature, not corruption.

It's fiddly, and it's the manual version of a loop that nicer packs hide behind a single node. But it's also the honest version: once you've run this loop by hand, single-node "chunker" workflows stop being magic.