Nodes/ComfyUI-MiniMax-H3-LongMedia/MiniMax H3 • Stitch Continuation
ComfyUI Node

MiniMax H3 • Stitch Continuation

Joining H3 continuation segments without a visible seam

By vizart-vj·Created 14 days ago·Updated 2 days ago· 71
MiniMax H3 • Stitch Continuation
  • previous_av
  • sampled_continuation_av
  • stitched_av
  • total_frames
overlap_frames22
blend_video_overlapfalse
offload_to_cpufalse

Long videos are generated in chunks, and chunks need a handshake. MiniMax H3's continuation scheme works by re-sampling the tail of your previous clip as context - the new segment starts by re-rendering the last 22 frames of what came before, so the model knows where it is. The problem is you can't just concatenate that output, because you'd be doubling up 22 frames of footage. MiniMaxH3LatentLabStitchContinuation is the node that trims the repeated prefix and welds the new segment onto the accumulated clip.

You feed it previous_av and sampled_continuation_av (both LATENT), plus overlap_frames (default 22, the native H3 continuation prefix, but adjustable from 5 to 3600 - it snaps to H3's 17k+5 frame grid). It returns stitched_av and a total_frames INT so you know exactly how long the clip got. There's an internal boundary audit in the code that verifies the stitched frame count and audio/video sync, and it throws a loud error if the numbers don't line up - so a mistimed segment fails fast instead of giving you a broken file later.

The two settings that matter

  • blend_video_overlap (default false) - smoothstep-blends the video overlap seam when on. Leave it off for the clean exact-latent handoff; flip it on if you're manually chaining and see a hard cut at the join.
  • offload_to_cpu (default false) - this one's a quiet VRAM hero. The stitched accumulator is never read back by the sampler; only the next stitch and the final decode touch it. In a long multi-pass run, leaving a growing accumulator resident on the GPU just wastes memory. Offloading is free correctness-wise - worth enabling for anything past a couple of passes.

Where it fits

This is the manual continuation path: PrepareContinuation builds a new AV latent whose opening is the synchronized tail of the previous result → you sample it → StitchContinuation removes the overlap. If you're using the MultiClip Planner or segmented_continuation mode, that assembly happens internally by the shared clip executor, and you never see this node. Reach for it when you're hand-rolling a chain or testing continuation behavior directly.

Install

One node, one pack, zero extra pip deps:

cd ComfyUI/custom_nodes
git clone https://github.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia

Restart ComfyUI, or grab it via ComfyUI Manager ("MiniMax H3 LongMedia"). The H3 checkpoint and VAEs go in ComfyUI's standard model folders.

Gotchas

  • Keep overlap_frames consistent with what PrepareContinuation used. Mismatched overlap values are the usual way to trip the boundary audit.
  • The two inputs must share geometry - the source code rejects a continuation whose batch/channels/spatial shape differs from the previous clip.
  • The MiniMax H3 weights are geofenced (no US, EU, UK, South Korea), which is a pack-wide licensing check worth remembering before you build a production pipeline on this.

If the seam is where your long-form H3 work falls apart, this node is the fix - and offload_to_cpu is the free VRAM you didn't know you were leaking.

CategoryMiniMax H3/LongMedia/Continuation

Inputs (5)

NameTypeDefaultDescription
previous_avLATENT
sampled_continuation_avLATENT
overlap_framesINT225–3600
blend_video_overlapoptBOOLEANfalseSmoothstep blend the video overlap seam.
offload_to_cpuoptBOOLEANfalseMove the stitched result to CPU RAM instead of leaving it on the GPU. Safe to enable for long multi-pass runs: this accumulator is never read back by the sampler, only by the next stitch and the final decode, so keeping it resident on the GPU across many passes just wastes VRAM.

Outputs (2)

NameTypeDescription
stitched_avLATENT
total_framesINT