Wan2.1 Frame Adjuster

Wan 2.1 has a frame-count rule that quietly ruins more first runs than any other single gotcha: the number of frames has to be divisible by 4, plus 1. Valid counts are 5, 9, 13 … 81, 97, and so on. Feed it a 60-frame batch and you get an error, or worse, a silent weirdness in the output. The Wan2.1 Frame Adjuster is the one-widget fix: give it any image batch and it rounds the count up to the next valid 4x+1 value by appending gray frames to the end.

The README even tells you the intended choreography: run this, then use a "Get Frame Range from Batch" node afterward to trim back to your original frame count before you combine the video. The gray padding exists to satisfy the model, not to stay in your final clip.

How it works

Dead simple under the hood. It reads images.shape[0] as the current count, computes the next number of the form (n*4)+1 that's at least that big, and pads with gray frames. Counts under 5 get bumped to the minimum of 5. It's pure frame handling - no model involved, runs instantly, GPU or CPU.

Inputs and outputs

• images - your batch. That's the only input.
• adjusted_images - the padded batch.
• final_frame_count - the resulting valid count. 65 is already 4x+1, so it passes through unchanged; 60 rounds up to 61.
• frames_added - how many gray frames got appended. If the count was already valid, this is 0 and the batch passes through untouched.

So the workflow is: frames in, adjusted_images into the Wan sampler, and after generation grab the frame range matching your original count to drop the gray tail.

Troubleshooting

The main confusion is the gray frames themselves. They're supposed to be there during generation - if you see a gray tail on the sampled output, that's the padding doing its job, not a bug, and the trim step removes it. Second, this node pads to the next valid count but never reduces - if you're over your VRAM budget because 97 frames is too many, this won't help; that's a resolution or frame-count decision upstream. And if your batch is already 81 or 97, the node is a no-op, which is correct behavior.

Installing

Ships in TrentNodes under Trent/Utilities, so one pack install covers it. ComfyUI Manager → search "Trent Nodes" → Install, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes
cd TrentNodes
pip install -r requirements.txt

Restart after. If Manager flags the pack (a day-one repo rename left a registry duplicate it still distrusts), the manual clone is the reliable path.