Wan Frame Count JK🐉

Every video model has a weird frame-count constraint, and Wan's is one of the easiest to explain: its VAE compresses the temporal dimension by 4×, so the number of frames you feed it has to be one more than a multiple of 4 - 4n+1. 81 frames, 97, 161, fine. 80 or 84 and you're asking the encoder to do something it doesn't know how to do cleanly, which shows up as dropped frames, a frozen final frame, or timing that just feels off.

Wan Frame Count JK exists so you stop thinking about it. You give it the frame count you want, it hands back the nearest valid one, rounded up.

How it works

The math is exactly what the description says: round frame_count - 1 up to the nearest multiple of 4, then add 1 back. Input 82, get 85. Input 80, get 81. It never shrinks your video - it rounds up, so if you were planning 80 frames you'll get 81 (5 seconds at 16fps instead of 5.0 exactly). If you genuinely need an exact duration, back-solve the frame rate from the valid number rather than the other way around.

Input is one field, frame_count (default 81), and the single output is wan_frame_count (INT). Wire it straight into the frame-count input of your Wan sampler or wrapper, or into a math node that derives duration.

JakeUpgrade added this node across most of its Wan video workflows in v2.1.0, and it's a good habit to keep one in any graph you build yourself. There's a sibling node, LTXV2 Frame Count JK, that does the same job with 8n+1 for Lightricks' LTX Video - the family resemblance is deliberate.

Install

It's in the JakeUpgrade pack:

cd ComfyUI/custom_nodes
git clone https://github.com/jakechai/ComfyUI-JakeUpgrade
cd ComfyUI-JakeUpgrade
pip install -r requirements.txt   # Windows standalone: install.bat

Or ComfyUI Manager → "JakeUpgrade". The node itself needs no models - the Wan models and Wan Video Wrapper are separate.

Where people get burned

The most common mistake is assuming the rule doesn't apply to you because "it mostly worked." It mostly works until you get an encode error or a clip that ends one frame early, and by then you've wasted a 14B sampling run. Also: don't point this at the loop or length-in-seconds value - it only accepts a frame count, so multiply seconds by fps first. And if you're adapting a Wan 2.1 workflow to 2.2, the 4n+1 constraint carries over; that part didn't change. Round up, generate, move on.