WanAnimate Best Frame Window

Wan Animate - the Wan 2.2 Animate-14B character animation model - has a hard native context of 81 frames. Push past that and you're not generating one clip anymore; you're chunking a long driving sequence into overlapping windows, running each through the model, and stitching the pieces. That raises a question nobody wants to do by hand: what window size actually divides your sequence cleanly?

That's this node's entire job. Feed it your total frame count and it returns one integer: the window size that covers your sequence in the fewest, cheapest passes. No models, no GPU, no downloads - it's pure arithmetic wearing a ComfyUI costume. If you're looking at a Wan Animate workflow from this pack and wondering what the "best frame window" slot is for, this is the thing that fills it.

The mechanism is worth knowing because it explains why the answer is what it is. Wan's VAE compresses time by roughly 4x, so valid frame counts are 4n+1 - 81, 85, 89, and so on. The node searches window sizes from 57 to 97 in those 4n+1 steps, simulates covering your total frames with windows that overlap by one frame, and picks the size that minimizes total compute (passes times per-pass cost, roughly k × window²), breaking ties on wasted padding. The sweet spot is a compromise between "fewer windows" and "windows small enough to fit in VRAM," and it never exceeds 97.

The inputs that matter

Two inputs, one output, and you'll touch one of them. frame_count is your sequence's total frame count - count the actual frames of your driving video, not the number of chunks. It defaults to 81, roughly the model's native context, so the node only starts to earn its keep once your take goes past that. force_size defaults to 1, which means "calculate it for me"; set it to any value above 1 to override. Notice the step of 4 - that's the tooltip reminding you to keep an override a valid Wan frame count. The single output, frame_window_size (INT), feeds whatever your Wan Animate workflow uses as its window size when chunking.

Installing it

Installation is the pack install, nothing extra. Search lhyNodes in ComfyUI-Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lihaoyun6/ComfyUI-lhyNodes.git
python -m pip install -r ComfyUI-lhyNodes/requirements.txt

Then restart ComfyUI. The pack's requirements (ultralytics, opencv-python, numpy, yarl) are dragged in by the pack's other nodes; this one doesn't need any of them, but you're getting them either way.

Common issues

Honestly, troubleshooting here is thin because the node is a function. The realistic ways to get a wrong answer: feeding a wrong frame_count (count frames, not chunks), or forcing a size that isn't 4n+1. Two behaviors worth knowing though. If your sequence is 57 frames or fewer, the node returns your count rounded up to the next 4n+1 - a 55-frame take gives you 57, a short enough clip to run as a single window with no chunking at all. And if you never go past 81 frames, skip this node entirely; the model's native context handles it and the window is just 81.

Don't expect this node to make your animation prettier - it won't touch a pixel. What it stops is the failure where a wrong-size window makes a long take stall, silently waste compute, or come back shorter than it went in. That "why is my clip two frames short" trap is the 4n+1 rule biting you, and this is the node that keeps it from biting. It's a small utility, but it's the one you reach for exactly when your take stops fitting.