Video Resolution (FFMPEGA)

Here's a trap that costs people entire evenings: you type 1280×720 into a resolution node, the job queues fine, and Wan 2.2 hands you something subtly wrong. Not broken - shifted. Composition feels off, subjects sit slightly left of where you framed them, and if you've cropped anything in the source it now looks like it drifted.

Nothing crashed. The latent was built as height // 8 by width // 16, and 720 doesn't divide the way the model's grid wants. ComfyUI's core ResolutionSelector snaps to a multiple of 8, which is right for SDXL and wrong for every video model in this pack. Video Resolution exists to snap to the actual grid, and to refuse obviously doomed jobs instead of letting you wait on them.

What it knows about each model

model_type is the switch, and it sets three things at once: the pixel grid both axes must land on, the VAE spatial downscale used for the token estimate, and the frame-count rule.

• wan22_a14b - grid of 16, frames on 4n+1, short-edge of 832×480 as the native tier. Because 720 is divisible by 16, this model gets a true 1280×720 for 720p.
• wan22_ti2v_5b - grid of 32, 4n+1, and its 720p tier is 1280×704, not 720. That's the giveaway for why this node exists.
• minimax_h3 - grid of 32 and a frame rule of 17k+5, so its counts land on 124, 141, 158 and so on. It also carries a canvas rule (768 short edge, capped at 768×1344 area) that the node reuses straight out of ComfyUI core when core exposes it.

Sizing: buckets or megapixels

sizing defaults to bucket, and it's the mode you want. bucket picks a known-good tier - 480p, 576p, 720p, 1080p - for the chosen model. For Wan 2.2 the tooltip is blunt about why 480p is the default: 832×480 is the native trained size, and 720p costs roughly 2.2× the VRAM for it. aspect_ratio holds the area constant across ratios, so 9:16 portrait at a given bucket costs the same as 16:9 rather than quietly ballooning.

sizing: megapixels lets you set an arbitrary area via the megapixels float, still snapped to the grid. 0.4 MP is about Wan's native 832×480. Which brings us to the guard rail: allow_below_native is off by default, meaning resolutions below the model's trained floor are rejected at queue time. 0.1 MP is 320×320, roughly 7× below trained size, and it produces garbled output - the node declines to let you schedule a run that was always going to be noise. Turn it on deliberately if you're experimenting.

Frames are the better VRAM lever

The frames input snaps up to the model's rule - 4n+1 for Wan, 17k+5 for H3. Default is 81, which is a Wan number; H3 wants 124. The tooltip makes an argument worth internalising: cutting Wan from 81 to 49 frames saves about 38% of the latent tokens with no cost to per-frame quality, whereas dropping below native resolution degrades everything. So when you're squeezed, shorten before you shrink.

That only holds inside the model's trained frame range - roughly 17–121 for Wan, 124–362 for H3. Below it, motion breaks down on its own, and the correct move is to lower the bucket instead.

Outputs

width and height (grid-aligned), length (frame count, rule-snapped), and info - a human-readable summary with the final dimensions, what got snapped, the actual megapixel count, and the latent-token cost relative to native. Wire width/height/length into your empty-latent node. Read info when something looks off; it tells you whether the node moved your numbers.

Install

ComfyUI Manager → search ComfyUI-FFMPEGA → Install, or:

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

Restart. No models, no downloads - this one is arithmetic over constraints read from ComfyUI core (nodes_wan.py, nodes_minimax_h3.py) with local fallbacks if core moves them.

Where people get burned

Assuming 720p means 720. On a 32-grid model it's 704. If you've been feeding 1280×720 to TI2V-5B and wondering why the framing looks cropped, this is the answer.

Treating it as a formality. It's not a calculator - the rejection is the feature. Getting a fast "no, that resolution is below the model's floor" beats a ten-minute queue that produces static.

Mixing it with a core resolution node downstream. Whatever runs last wins. If something after this node re-snaps to 8, you're back where you started.