WAN Outpaint Frame Calculator (Badman)

Wan's native context window is 81 frames, full stop - that hasn't moved across 2.1 or 2.2. Anything longer than that isn't one sampler pass, it's several, chained together and stitched with overlapping context frames so the seams don't show. Doing that math by hand - how many passes you need, how long each one runs, how much overlap to keep for continuity, where each chunk starts relative to the last - is exactly the kind of fiddly bookkeeping that's easy to get subtly wrong. This node does that arithmetic for you.

Where it fits in a WAN video outpaint

"Outpainting" a video clip here means extending it in time to a target length beyond what a single Wan pass can generate natively. The community's answer to Wan's fixed context has always been the same shape: run multiple samplers back to back, each one picking up where the last left off, carrying forward a handful of context frames from the end of the previous chunk so the new chunk has something to anchor its motion to instead of starting cold. Get the frame counts wrong and you either waste compute re-generating frames you didn't need, or you get a visible jump where two chunks don't line up. This calculator takes your total target frame count and works out the chunking plan - how many samplers you need, how long each chunk's generation should run, how many context frames to carry into each one, and where each chunk starts in the overall timeline - so you can wire that plan straight into a multi-sampler Wan graph instead of guessing.

Inputs and outputs

One required field: total_frames (integer, 1–10000, default 192) - the total frame count of the input video you're extending, per its own tooltip.

One optional field: additional_context_per_sampler (string, default "0,0,0") - a comma-separated list letting you pad extra context frames onto specific samplers in the chain. The tooltip gives a concrete example: "0,0,4" adds 4 extra context frames to the third sampler specifically. If you give fewer values than there are samplers in the plan, the remaining ones are padded with 0 - so you don't have to know the sampler count in advance to use this field for just the last chunk or two.

Four outputs, all INT: num_samplers (how many chained sampler passes the plan needs), generation_lengths (how many frames each pass generates), context_frames (how many frames of overlap each pass carries forward), and start_positions (where each chunk starts in the final timeline). Wire these into your chain of Wan samplers to drive the loop mechanically instead of typing frame counts into each node by hand.

Installing it

ComfyUI Manager: search ComfyUI-BadmanNodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/MariusKM/ComfyUI-BadmanNodes

This is a pure arithmetic node - no Wan model files, no extra Python packages, nothing to download. It only becomes useful once you've already got a working single-chunk Wan video pipeline to loop; on its own it just outputs numbers.

Where people get burned

This node plans the chunking, it doesn't execute it - you still have to build the sampler chain, the frame-stitching, and the context-frame feed-forward yourself, or find a chunker node pack that consumes exactly these four outputs in the shape it expects. Second, identity and motion drift across chunk boundaries is a known, unresolved limitation of Wan's chunked-extension approach generally, not something this calculator's math can fix - better context-frame counts reduce visible seams, they don't eliminate character drift over a long extension. And because additional_context_per_sampler pads with zeros for any sampler you don't specify, a short list you meant to apply broadly will silently only affect the first few chunks - double-check the count matches what num_samplers reports if the tail of your extension isn't behaving the way the front did.