H3 Continuum Assemble + Seam V3.4

This is the second half of the H3 Continuum pipeline, and it's the half that decides whether your long clip actually looks like one clip. The H3 Continuum Sampler V3.4 generates a handful of chunks; this node takes the decoded frames and audio, reassembles them in order, and fixes the seams where the chunks meet. Skip it and you've just got a concatenation. Use it and the boundary between chunk 1 and chunk 2 stops announcing itself.

Why seams exist at all

Each H3 chunk is an independent-ish generation. Frame 24 of chunk 1 and frame 1 of chunk 2 are generated separately, so they can differ in exposure, brightness, or a one-frame micro-flash - especially since the pack's whole point is carrying context across boundaries, not pixel-identical continuation. The assembler reads the assembly_plan from the sampler (it knows the chunk boundaries, the target frame count, and whether the final frame should be preserved) and decides what to do at each one.

That decision is the video_seam control, and it's worth understanding before you flip it to something fancy:

• Off - plain assembly, no correction.
• Analyze Only - reports the decoded boundaries in the report output without touching the frames. Great first stop if a seam looks wrong and you want to know what's actually happening.
• Auto - applies the validated transient and micro-flash correction.
• Auto 2 - experimental; adds qualified exposure-ramp smoothing on top.

The node is deliberately conservative: it can keep a native boundary when a proposed correction isn't safer, so don't assume every seam gets "fixed." Run it once on Detailed Report diagnostics to see what your boundaries actually look like, then trust Auto.

audio_seam works the same way but for decoded audio (Auto corrects audio boundaries only - the tooltip is explicit that video frames are never altered by it). And exact_total_duration (default on) trims the final output to exactly the total duration you asked for, which is why your ending doesn't drift by a frame or two.

The Driving Audio special case

When driving_audio is connected - wire the sampler's Driving Audio output into it - generated audio and Audio Seam are bypassed entirely, and the original source you fed the sampler is selected for the final output instead. That's the whole point of the V3.4 workflow: the song or dialogue track you supplied survives the trip through the model untouched. If you actually wanted the generated audio, don't connect this input. You'll also see this decision logged in the report string.

Wiring it up

video_latents -> Core VAE Decode ---------------> images
audio_latents -> Core VAE Decode Audio ---------> audio
assembly_plan (from sampler) -------------------> assembly_plan
driving_audio (from sampler, optional) ---------> driving_audio

Outputs are the final images (a single continuous batch, ready for a video encoder), the final audio, and the report string.

Install and gotchas

It ships in the same pack as the sampler, so one install covers both: ComfyUI Manager, search "H3 Continuum", or:

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

Restart, and note there are no extra pip dependencies - it uses ComfyUI's bundled torch. The two things that bite people: if you installed V3.4 during the first days of release, the pack was incomplete and Driving Audio wasn't wired end-to-end - run git pull from the custom node folder (or Manager Update) and restart. And remember that connecting Driving Audio silently disables generated-audio processing, which is a feature until it's not. This is a niche pack - no big community, so read the report output and the README's issue notes rather than hoping a forum thread will save you.