H3 Continuum Finalize

H3 Continuum Sampler V3.5 hands you raw chunks, not a finished clip. The decoded chunk frames are separate IMAGE batches, each with its own boundary, and every one of them needs to be fused back into one continuous video with the exact length you asked for. That's this node's whole job: H3 Continuum Assemble + Seam V3.5 is the last stop in the pipeline, and it's where your video actually becomes a video.

If you're only doing single-pass MiniMax H3 with Core nodes, you might never need it. The moment you go multi-chunk - which is the entire point of the H3 Continuum pack, because it's how you push past what one pass can do - you need something that understands the plan the sampler built. This is that something.

What it actually does

The sampler outputs an assembly_plan alongside video_latents and audio_latents. That plan is a structured map of the whole run: which chunks belong to which physical group, what order they go in, what the target geometry and duration are. This node reads that plan, stitches the decoded images and audio together in the right order, trims or pads to the exact requested total duration, and cleans up the boundaries between chunks.

The V3.5 headline feature is the buffer_backend control. Long, high-resolution H3 runs produce enormous final IMAGE tensors - the README's validated stress case was a 1536×1536, 360-frame float32 clip at 9.49 GiB. Assembling that in plain RAM was consuming 12.4 GiB of private memory. With the new Disk-backed mode the final video IMAGE is written to a memory-mapped temp file instead, dropping private memory to under 3 GiB for the same output. Audio stays in RAM either way, which is fine - audio is small.

The inputs that matter

• images - from Core Video VAE Decode.
• audio - from Core Audio VAE Decode.
• assembly_plan - from the sampler (V3.4 or V3.5). Required, and there's nothing to fiddle with.
• exact_total_duration (bool, default on) - trims/extends the final output to the exact requested length. Leave it on.
• buffer_backend (Auto / RAM / Disk-backed) - the one you might actually touch. Auto keeps outputs up to 4 GiB in RAM only when physical memory has a safety reserve, otherwise it maps to disk. On a low-RAM box you can force Disk-backed; on a machine with plenty of headroom RAM avoids disk I/O.
• video_seam (Auto / Auto 2 / Analyze Only / Off) and audio_seam (Off / Auto). Auto corrects boundary artifacts. Auto 2 experimentally adds exposure-ramp smoothing; Analyze Only reports without changing anything.
• Optional driving_audio - connect the sampler's driving_audio output. When present, your supplied track is kept as the final audio and generated-audio seam processing is bypassed.

Outputs

images (the assembled IMAGE), audio (the assembled AUDIO), and a report string if you want diagnostics on what got stitched.

Installing it

It ships with the H3 Continuum pack, so install once, get all six nodes. In ComfyUI Manager search "H3 Continuum", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum.git

Then restart ComfyUI. It has no pip dependencies beyond what ComfyUI already bundles, and it needs the MiniMax H3 weights (~42.5 GB) installed the normal way. Update with Manager, and don't mix Manager updates with manual git pull on the same install.

Where people get burned

• Disk-backed isn't a global RAM fix. It guarantees low memory for Continuum's own assembly stage, but a downstream Save / Preview / Video Helper Suite node can still allocate a full RAM copy. If you're still OOM-crashing after assembly, the copy is happening downstream.
• Disk-backed I/O is slower at final assembly. Fine for long clips, wasteful for short ones - that's what Auto is for.
• Don't expect lip sync. Driving Audio preserves your track, but visual synchronization stays model-dependent.
• On Windows, --disable-pinned-memory has helped some people with H3's host-RAM pressure, but it's environment-specific - compare the same seed with and without it before keeping it.