H3 Infinite Take (one trajectory, any length)

Every other approach to long H3 clips joins finished blocks, which means every other approach has seams to hide. H3InfiniteTakeSampler takes a different road: it runs one denoise trajectory over an arbitrarily long audio-video latent, and the model never sees more than a single window at a time. No shot boundaries anywhere in the trajectory - no seams to fix, because there's nothing to join. It's Temporal MultiDiffusion applied to MiniMax-H3, and the headline number is the one on the tin: total_frames can go up to 3600 (~2.5 minutes at 24fps) and VRAM does not grow with it - only render time does.

How it works

Latent geometry first: 2 bootstrap rows encode the first 5 frames, then 5 rows per 17-frame block. The sampler integrates the full-length latent, but inside predict_noise the model only ever attends over one window at a time; overlapping windows' predictions blend with raised-cosine ramps. Mid-take windows get 2 rows of preceding context in the bootstrap slots (their prediction for those rows is discarded - weight 0), so every window looks like a normal clip to the model. Audio (at 40 latent-fps) is windowed to the same global timeline. The one genuine constraint is the sampler: euler-family only (euler, euler_ancestral, heun is a no), because H3's audio velocity is chain-rule-scaled - denoised isn't x0 for the audio stream, so multistep/exponential samplers that extrapolate on it mis-integrate the audio. The tooltip is explicit; the dropdown will happily show you 44 samplers, and 40 of them are a trap here.

The inputs that matter

• script - JSON {"prompts": [...]}, one prompt per window. The node prints the window count and time spans if the count doesn't match.
• total_frames - 719 = ~30s, 1450 = ~60s, snapped up to the 17k+5 grid. Again: this is a render-time knob, not a VRAM knob.
• window_frames - frames per attention window (default 243), and the model never sees more than this at once. Stay in the trained range (124-362).
• overlap_frames - overlap between windows (multiples of 17, default 34). More overlap = stronger agreement between windows, more compute.
• activation_reserve_gb - default 8, and the tooltip explains why this node pins its own reserve: the loader's auto-reserve sees two latent shapes here (the full take at load, a window per eval) and double-reserves, forcing the DiT to offload - render-verified on a 3090 at 750s/it from a 93% offloaded model. 7-8GB suits 768x1344/243f; raise it only on an OOM inside the model forward.
• derive_length_from_script - ON computes total_frames from the prompt count (one prompt per window), letting an LLM rewriter decide how long the piece is: write N shots, get N windows.

Outputs: frames (IMAGE), audio (AUDIO), windows (INT).

The progress bar, and why it's lying to you

The one thing that makes people think the node hung: a progress step is one pass over all windows, so 0/N sits still for window_count × per-window time before the first tick. That is not a hang - it's a full denoise pass finishing before the counter moves. Watch for the window span printout instead.

Install

Part of the H3 Multishot pack:

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

or ComfyUI-Manager → H3 Multishot. Restart; ComfyUI v0.30.0+. No extra dependencies beyond the models themselves (checkpoint, encoder, video + audio VAE).

If you want long and continuous, this is the honest alternative to the chain samplers: no joins to trim, no texture ratchet per hop, no boundary rules to write around. What you trade is control - one prompt per window instead of a scripted scene, and no memory bank or reference system riding along. Different tool for a different job.