IAMCCS WanAnimate Extends

IAMCCS_WanAnimateExtends is a long-video wrapper for WanAnimate, the pose/face/background-driven character animation workflow on Wan 2.2. Native WanAnimate is stuck at a single short window, and every long-video path on Wan is the same choreography: generate a chunk, carry its tail into the next chunk as continue_motion, repeat, and pray the seams don't show. This node automates that whole loop and spends its real effort on the last part - making the joins invisible.

That seam problem is the honest wall of open video. The KB's read of the ecosystem is blunt: every one of these extension nodes is still stitching 81-frame windows, and identity/color drift across chunk boundaries is the failure mode. What separates a good wrapper from a bad one is how it grades the join. This node's answer is boundary color-matching: after each chunk seam it color-grades only the first boundary_frames (default 8) of the new chunk toward the previous tail, using reinhard_lab (default), mkl_lab, or histogram matching, ramped so the correction fades out - iamccs_boundary_ramp profile. It's a targeted cosmetic fix for the most visible chunk artifact, and it doesn't touch the rest of the frame.

How it works

It runs WanAnimateToVideo + KSampler + VAE decode in chunks. The math it expects you to know: first_chunk_length 81, next_chunk_length 77 with continue_motion_max_frames 5 - the tooltip's "77 length with 5 continue frames contributes 72 visible frames" - which is the standard WanAnimate loop arithmetic where each continuation reuses the visible tail as the motion anchor. target_frames 0 means it infers the total from your pose/background/face/mask frame count. It also trims native latent/image anchors that WanAnimate leaves at chunk boundaries, which is where trimmed_frames and source_frames outputs come from - the difference between what you fed it and what actually landed in the video.

You drive it with the usual suspects: model, positive/negative conditioning, vae, width/height, steps (default 6 - WAN Animate is a low-step distilled workflow), cfg (default 1.0), sampler_name (euler), scheduler (simple), denoise, seed/seed_mode (fixed or increment per chunk). Optional inputs let you plug in the WanAnimate control signals: clip_vision_output, reference_image, face_video, pose_video, background_video, and character_mask.

Outputs: images, frame_count, source_frames, trimmed_frames, and a chunk_plan JSON describing how the run was segmented - useful when a seam still shows and you want to see the actual chunk boundaries.

Installing it

Part of the IAMCCS-nodes pack. ComfyUI Manager → search IAMCCS, or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart ComfyUI; it's under IAMCCS/video/WanAnimate. No pip requirements. You need a WanAnimate-capable setup already working - the Wan 2.2 Animate checkpoint, VAE, and the pose/face driving inputs - since this node orchestrates, not loads. README floor: ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.

Where people get burned

• Boundary grading can't fix a real drift, only the color jump. If the character visibly changes across a seam, that's identity drift - lower boundary_strength, check your continue-motion frames, or accept the length limit. No wrapper fixes identity without a character LoRA.
• next_chunk_length + continue frames must match the WanAnimate loop math, or your frame_count will be shorter than expected. If the tail comes back a few frames short, that's the 4n+1 temporal-compression rounding at work, and this node's trim counters exist so you can see it.
• If you're also stacking LoRAs in native WanAnimate, remember this pack exists partly because native WanAnimate dropped LoRA weights - use the pack's WAN LoRA stack/apply nodes rather than assuming vanilla injection works.