Difforum · Setup

If you've ever rendered a 121-frame clip and had the last four frames come out as a smear because your video model wanted 8k+1 and you typed 120, this node is for you. Difforum · Setup is boring and it is the first node you wire in every graph.

It answers four questions in one place - how long is the clip, how is it framed, at what frame rate, and which model family is going to render it - and it publishes the answers as params, which every other node in the pack reads. One timeline, one source of truth. That's the whole design, and it's the right one, because the alternative is five nodes each with their own idea of what "5 seconds" means.

The target grid, which is the actual feature

target is a dropdown with four entries, and each one carries the rules the model family imposes:

feedback (SD/SDXL/Flux) - any frame count, dimensions in multiples of 8. The Deforum-style loop path, most forgiving.

LTX-2 / 2.5 - frame count snapped to 8k+1, dimensions in multiples of 32. LTX 2.3 keeps those rules (it also rebuilt the VAE, so keep your preview tooling in mind).

MiniMax H3 - 17k+5 frames, multiples of 32, and 24 fps, always. If you set fps to anything else while H3 is the target, the node overrides you and says so in info. H3 (the 33B omni-modal model that opened up in August 2026) doesn't negotiate on that.

Wan 2.x - 4k+1 frames, multiples of 16.

You set a duration in seconds or frames, and the node snaps it. Expect the snapping: ask for 5 seconds at 24 fps and you get 120 frames, which is legal for everything; ask for 4.9 seconds and the grid rounds you to the nearest valid length, then tells you in info that it moved. info also prints the final resolution, length in seconds, and which size multiple it used - read it once and stop guessing.

The inputs you'll actually set

duration_mode (seconds or frames) and duration are the clip length. fps is the frame rate, remembered: H3 is 24, LTX and Wan have their own habits, and 24 is a sane default for everything else. aspect has ten presets - widescreen, vertical, square, 4:5 social, classic 4:3, ultrawide, 2.39:1 anamorphic, 2:1 univisium, plus custom, which reads custom_aspect_w and custom_aspect_h. long_edge is the longer side in pixels before snapping, and it's the one that decides whether your render is pleasant or painful.

Then two optional escape hatches. max_megapixels is a hard cap on frame area: set it to 0 and there's no cap, ~0.35 on a 16 GB Mac and ~0.65 on 24 GB are the pack's own numbers, and the node shrinks the frame to fit and reports the cap. seed is the master seed for every sampler that reads Setup, so one number seeds a whole shot instead of five.

Outputs: params (the bundle, wire it everywhere), plus width, height, frames, fps and info for nodes or notes that want the plain values.

Install

ComfyUI Manager → search Difforum, or:

cd ComfyUI/custom_nodes
git clone https://github.com/chillithebillis/Difforum.git difforum

Restart, then Templates → Difforum for working graphs. numpy is the only declared dependency, and the pack's first template (01_storyboard_no_model) needs no model at all - that's the fastest way to see the params wire doing its job. Note the pack is young and reworked its node set for 1.0 (40 nodes down to 33, with the 0.x ones still registered under Difforum/legacy so old workflows open); the templates are generated from the code, so they're more current than anything you'll find in a tutorial.

Where people get burned

The classic: wiring Setup into three nodes and setting duration on a fourth. If a node has a params socket, it takes its length and fps from there - typing a different number into a downstream node's own duration widget doesn't win, it just gets ignored or produces a mismatch that only shows up in the last second of the render.

The other one is long_edge versus the actual render size. For the feedback look, 768-1024 is fine and going higher mostly buys you time. For H3 the templates deliberately render at 640 and lift the latent 2x with a separate upscale block, so setting long_edge to 1280 and expecting more detail gets you a slower render of the same thing. And if you're on unified memory, the megapixel cap is not a suggestion - memory blows up with the square of the resolution, so a 4-second clip at a friendly size beats a crashed 8-second one at a brave one.