IAMCCS WanAnimate Extend Plan
Know how many chunks your WanAnimate video needs — before sampling
- source_frames
- estimated_chunks
- chunk_plan_hint
WanAnimate can't sample an entire long animation in one shot, so the IAMCCS wrapper chops it into chunks where each chunk carries motion forward from the previous one's tail. WanAnimate Extend Plan is the planning half of that: it tells you, in advance, exactly how many chunks a given source length will need and what each chunk contributes - without spending a single sample on it.
The description says it plainly: "Plan IAMCCS WanAnimate chunk contribution without sampling." It's the companion to IAMCCS_WanAnimateExtends (the wrapper that actually runs WanAnimateToVideo + KSampler + VAE decode chunk-by-chunk). Think of it as reading the map before you drive: the plan output is a human-readable string you can eyeball or log to confirm your chunking strategy is sane.
Inputs
- source_frames - how many frames the source (pose/background/face) video has. Default 161.
- first_chunk_length (default 81) - length of the first generated chunk.
- next_chunk_length (default 77) - length of every subsequent chunk.
- continue_motion_max_frames (default 5) - how many frames of the previous visible tail get carried forward as motion continuity into the next chunk. This is the knob that controls the "continue motion" overlap.
All lengths are normalized internally to WanAnimate's required 4n+1 frame pattern, so the numbers you type get snapped to a compatible shape.
Outputs
- source_frames - echoed back.
- estimated_chunks - how many chunks the run will take. The number that actually matters for planning VRAM and time.
- chunk_plan_hint - a compact plan string like
81->+81 | 77-trim5->+72 | ..., showing each chunk, how many frames it trims, and how many new frames it adds. Great for pasting into a notes node or sharing in a workflow.
Install
Ships in IAMCCS-nodes:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
or via ComfyUI Manager (search "IAMCCS"), restart. No models, no deps - pure math.
The subtle math worth understanding: each continuation chunk contributes next_chunk_length − continue_motion_max_frames new frames, because the tail is recycled into the next chunk's motion reference. If your source is 161 frames with defaults, that's roughly two chunks. Where people get confused: continue_motion_max_frames is max - raise it to carry more motion continuity, but it also eats into new content per chunk, so there's a real tradeoff between smoothness and total length.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| source_frames | INT | 1611–100000 | — |
| first_chunk_length | INT | 815–1024 | — |
| next_chunk_length | INT | 775–1024 | — |
| continue_motion_max_frames | INT | 51–129 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| source_frames | INT | — |
| estimated_chunks | INT | — |
| chunk_plan_hint | STRING | — |