👺 Wan Frame Trim

Wan video has a frame-count rule that bites everyone eventually. Its VAE compresses time by roughly 4x, which means the model only generates valid frame counts of the form 4n+1 - 49, 81, 97, 121, and so on. Ask for something else and one of two bad things happens: the workflow errors, or your clip comes back a couple of frames shorter than you asked, because the latent math round-tripped to the nearest valid length. This is the exact trap the community documents when the model "rounds up" or clips your output. 👺 Wan Frame Trim exists so you hit the rule on the way in instead of discovering it on the way out.

The mechanism is one line of arithmetic: it takes your input batch, finds the largest count m ≤ batch_count where m ≡ 1 (mod 4), and slices off everything after it. Feed it 83 frames and you get 81 - the largest valid count not exceeding your input. Feed it 49 and it's untouched. It's a trim, not a pad: if you're under a valid count, it cuts down to the previous valid number rather than padding up, so don't feed it 45 frames expecting 49 out. That makes it the right tool when you've generated a batch of frames (say from an upscaler, an interpolation step, or a source video) and you need to hand Wan a count it can actually chew.

Where this earns its keep is pre-processing source video for image-to-video or inpainting: your input clip is almost never 81 frames. It's 97, or 130, or 53. Run it through this node first, and the Wan nodes downstream stop complaining about impossible lengths.

Inputs and output

• images - your input batch of frames as an IMAGE tensor.
• images (output) - the batch trimmed to the largest 4n+1 count ≤ input.

Installing it

Part of Nilor Nodes (nilor-corp/nilor-nodes):

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

or ComfyUI Manager → search "Nilor Nodes" → install → restart. No model files. The README lists Kijai's comfyui-kjnodes as a prerequisite (you'll likely already have it for the Wan wrapper workflows this node feeds), and the pack's dependency list is heavier than a frame-trimmer needs - boto3, fastapi, huggingface_hub and openexr install regardless.

Troubleshooting

The validation is strict: input must be a non-empty 4D tensor, so a single unbatched frame or an empty batch raises immediately. The practical surprise is the trim direction - it never pads. A 50-frame input becomes 49, not 50, because 49 is the nearest valid count below it - and a 45-frame input stays 45, since 45 is already a valid 4n+1 count. If you need a specific valid count upwards, pad your batch first and trim after. And while the node handles the arithmetic, remember the deeper rule from the Wan docs: staying at or under 81 frames natively is what keeps clips from degrading - trimming to 81 is compliance, not a license to push 200. As with all of this pack, there's no community support to lean on; the 🛑 Nilor-Nodes error prefixes and source are your docs.