Zura Wan 2.2 Looped Chunks Sampler

Wan 2.2 Animate does character replacement from a driving clip: you give it the source footage, a mask, pose and face conditioning, a reference image, and it re-renders the performer as your character. It's genuinely good at it. It also has an 81-frame native context, which at 24 fps is three and a half seconds, and "three and a half seconds" is not a shot.

This node is the loop. It wraps the native WanAnimateToVideo sampler, renders the clip in 4n+1-frame windows, hands each window the previous window's real output frames as continue_motion, and returns one finished video plus a receipt. No separate finish node, no manual frame accounting.

Inputs

The model plumbing is ordinary: model, clip, vae, clip_vision, and a reference_image (one character view - that's the thing the sampler is replacing the performer with).

Then footage: the ZURA_FOOTAGE payload from the preparation stage. Its tooltip says "Prepared footage from the Zura Mask node" and that's the honest summary - the wire carries frames, approved mask, pose reel and face reel in one payload because a normal video wire can't. Wire reference_image from the preparation payload's character_view output and you'll never mismatch them. The prompt defaults are sensible as they stand: "Preserve the character appearance and scene." against "flicker, warped hands, extra limbs, identity drift".

steps (default 6) and cfg (default 1.0) both carry the same tooltip: the Turbo Switch node overrides them when connected. Left alone, those defaults are the accelerated recipe - 6 steps at CFG 1.0. The detailed branch of the pack's example runs 40 steps at CFG 5.0. Six is not a typo and it is not a quality setting; it's a distilled-LoRA recipe, and it only looks right if you actually loaded the LightX2V adapter and the Animate relighting LoRA the example names. seed is a plain int, and max_side (default 1280, 256–1920, step 32) sets the render's long edge.

The knobs that actually change the output

• chunk_frames (default 41, 5–409, step 4) - frames rendered per pass. Must be 4n+1 and at least twice the continuation frames. The standalone example uses 41; the integrated Studio uses 81.
• overlap_frames (default 5, min 5, step 4) - the continuation window: how many real frames of the previous chunk the next one is told to carry on from. Must be 4n+1. The tooltip's own advice is the useful part: raise to 9 when fast movement makes the join soft. Costs nothing extra, because a continuation chunk's sampling window is still exactly chunk_frames wide.
• shot_mode - Detect cuts (default), Continuous, or Manual cuts. A window never spans a cut and continuation never reaches back past the start of its own shot, so at a cut the new shot begins unconditioned and the cut stays hard. Manual cuts takes comma-separated frame numbers in cut_frames (at 24 fps, frame 96 is four seconds).
• cut_threshold (default 0.2) - lower detects more cuts. Raise it when flashes and fast movement get mistaken for edits.
• join_mode - Native continuation (default) or Soft blend. Native keeps the predecessor's real frames and discards the repeated context. Soft blend cross-fades the two renditions of the shared frames, which spreads the difference but can soften or double moving features. If a mouth looks mushy at a join, the README's own advice is to go back to native.
• viewport_render (off) - keeps the full blockout frame as Wan's background guide while regenerating the whole scene. That's the grey-blockout-to-final route, not the character-swap route.
• vision_reference - an optional second character view just for CLIP Vision; the main reference_image still guides the scene latent.

Outputs

images (the generated frames), video (finished, with the original audio and exact timing), and receipt - a JSON string.

Don't ignore the receipt. It carries chunks, the detected cuts, the resolved shots ranges, the frame plan, and per-chunk timings including continuation_delta: the mean absolute difference between the frames a chunk was asked to continue from and the version it produced. Near zero means the join is a true continuation. A large value means the chunks disagree, and that's your signal to raise overlap_frames rather than to squint at the output and hope.

Install

cd ComfyUI/custom_nodes && git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
pip install -r ComfyUI_zura_nodes/requirements.txt

Or install Zura Nodes from ComfyUI Manager (publisher ZURAVFX) and restart. Put ffmpeg and ffprobe on PATH.

Then the parts that hurt: ComfyUI-WanAnimatePreprocess for the detection nodes, the Wan Animate stack (fp8 Animate UNet, UMT5 text encoder, Wan 2.1 VAE, CLIP Vision, plus the LightX2V and relight LoRAs), and the detection weights at detection/vitpose-l-wholebody.onnx and detection/yolov10m.onnx. None of that ships with the pack.

Common issues

"Wan 2.2 requires the prepared footage payload from the Zura Mask node." You wired a VIDEO where a ZURA_FOOTAGE payload is expected. That mismatch is why this node can't just take a video - it needs the mask, pose and face tensors that a video wire can't carry.

Blurry or double mouths at joins. Try join_mode set to Native continuation, then raise overlap_frames to 9. Fast dance footage needs the deeper context.

A cut in your source came out as a soft morph. shot_mode is on Continuous, so the whole clip is one shot and every border is a continuation. Switch to Detect cuts, or give the frame numbers explicitly with Manual cuts.

You're seeing sections in the output where detail drops. The README is honest about this: a 23.75-second 720p example was accepted with detail loss between sections. Long clips are a chain of 41- or 81-frame windows and no amount of stitching makes them one inference. Inspect the joins for each render; that's what the receipt is for.

Rendering is slow enough to be a problem. Expected. The pack's own measured reference is a 16 GB RTX 4080 with 64 GB RAM, where a five-second Wan example at native 1080p ran about 25–28 minutes before preparation and speech guidance. Speed LoRAs are the usual answer and also the usual cause of plastic skin and flattened motion - pick your poison deliberately.

"continuation assembly produced N frames for a M-frame clip." The plan and the decode disagree - usually after hand-editing chunk_frames to a value that isn't 4n+1. Step 4 exists for a reason.