Multishot Advance Controls

Multi-shot video workflows have a plumbing problem that image workflows mostly don't: a dozen nodes each carry their own copy of resolution, frame count, seed, and sampler settings, and nothing stops them from disagreeing. Your controls node says 896x1184, your latent node says something else, your sampler says a third thing, and you spend an hour chasing a mismatch that was never visible on the canvas.

This node is the single source of truth. It computes the render geometry and carries the seed, frame count, steps, sampler, scheduler, and shot count, then hands all of it to the sampler as typed outputs. Change one widget, every downstream consumer updates. It also folds in what used to be a separate Resolution Selector - the tooltip says so outright.

The inputs that matter

The first three are the resolution math, and they're the ones to actually think about:

• aspect_ratio - 1:1, 2:3, 3:2, 3:4, 4:3, 9:16, 16:9, or 21:9. 3:4 portrait is the default.
• megapixels - target total pixels. 1.0 MP at 3:4 with a 32 multiple resolves to 896x1184, which is right in H3's comfort zone.
• multiple - snaps width and height to this. 32 is the H3-safe default, and there's a reason it's not optional: H3's architecture wants dimensions on that grid.

Then duration and determinism:

• frames_per_shot - H3's 17k+5 grid at 24 fps. 243 is the ~10.1 second default; 362 is ~15.1 seconds, the trained max. It drives both stage A's length and stage B's per-shot length.
• seed - defaults to 0 with after-generate mode fixed, so a run is reproducible until you tell it not to be.
• steps, sampler_name, scheduler - defaults are 8 steps, er_sde, beta. Those aren't arbitrary: er_sde/beta is the pairing H3's own reference material expects, and er_sde is a sampler other Chinese video models (Anima among them) lean on too, so it's a safe family to trust here.
• shot_count - 0 means one shot per prompt in the script. The tooltip's advice is the whole point of the node: wire this to both the sampler's shot_count and any prompt generator's num_shots so they cannot disagree.

Outputs: width, height, frames_per_shot, seed, steps, sampler_name, scheduler, shot_count, use_file_prompts. Wire the first eight straight into the sampler (or into a latent/preview node that needs the geometry).

The EXTEND TAKE mode

The interesting hidden feature: take_seconds. Set it to anything other than 0 and the node stops being a simple pass-through and plans an extended take - it overrides frames_per_shot and shot_count with a window sized for your card (window, default auto) and the count that fills the requested duration, so a 60-second take becomes N joins instead of one impossible long render. Wire model in when using this so auto can size the window from the real weights (15 GB assumed otherwise).

The trap: pin_frames must match the memory sampler's pin_frames exactly (22 is the tested default). If you change the sampler's pin and leave this at 22, take_seconds calculates the wrong delivered length - you'll get takes that are visibly shorter or longer than asked.

Installing it

Ships in the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/KursatAs/ComfyUI-H3-Multishot-Advance

Restart ComfyUI. No extra dependencies, no model downloads.

Common issues

The recurring failure is forgetting it's a source, not a sink - people edit Controls, then wonder why the sampler still uses old dimensions, because they never wired width/height/frames_per_shot over. If the sampler has its own widgets, remember the sampler's local values win when you're not feeding it from this node. And with EXTEND TAKE, the pin_frames mismatch above is the classic "why is my take the wrong length" - check that one number before touching anything else. Otherwise this is one of the lower-drama nodes in the pack: it does arithmetic and passes numbers around, and it does that on purpose so the rest of your graph has one authority to listen to.