H3 Continuation · Stitch

Continuation gives you clips that overlap by design. Clip 2's latent contains a slice of clip 1's history at its head, because that's how the model got its continuity - and clip 1's tail is the locked, near-frozen region you deliberately handed over. Put those clips in a timeline as-rendered and you'll see the last beat of shot 1 twice, followed by a short frozen stare.

This node does the trim. It's a picture-and-audio trimmer with one job: remove the reused head, remove the dead tail, hand you a segment that concatenates cleanly.

The three modes

Full - a true bypass. Nothing trimmed, everything passes through, head_trim_frames and tail_trim_frames both come back 0. Use it while you're still iterating; keep the full render for reference.

Stitch Ready - the working mode. It strips the reused head context plus the frames after the effective handover boundary, so what's left starts where clip 1 left off and ends at the cut point. This is what feeds your concatenation. It requires the handover wire - without it the node raises, because there is no honest way to guess the tail.

Final Clip - the last segment of a chain. It removes the duplicated head so you don't replay the previous clip, but keeps the complete tail, because there's no next clip that needs a freeze-safe landing zone and you presumably want the shot to actually arrive at its final image.

The detail that makes it frame-accurate

The tail isn't cut at the detector's raw "the shot stopped moving here" frame. It's cut at the phase-aligned latent handover boundary - the exact spot the latent slice for the next clip was taken from. That matters more than it sounds: if the picture trim and the latent slice disagree by even a couple of frames, the join plays the same beat twice with a tiny offset, or skips one, and it reads as a stutter.

The node also refuses to guess. It checks that the handover's frame count matches the rendered clip's frame count, and that the metadata is internally consistent - if the recorded end frame implies a different tail length than the metadata's own landing_tail_frames, that's an error, not a coin flip. It also refuses a plan that would remove the whole clip. And it's honest when the analyser found no lock: trim_info will carry no-lock-fallback=yes plus the requested versus effective tail.

Inputs and outputs

Required: images (the decoded FULL rendered frames for this clip) and output_mode.

Optional: handover, audio, and head_context_frames. That last one is where a lot of people stub their toe - clip 1 leaves it unconnected; clip 2 onward wants actual_head_context_frames from Continue. It's a force-input, so it must be a wire, not a typed number, and it's what tells the node how much of the head belongs to someone else.

Outputs: images and audio (trimmed in sync - the audio gets the same frame-accurate cut, which is why lip sync survives), plus trim_info, head_trim_frames and tail_trim_frames as strings and ints. Read the ints; when a join looks wrong, the first thing you want to know is how many frames each end kept.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Manager → IAMCCS Nodes is equivalent. Restart, hard-refresh, one copy in custom_nodes only - the README calls out duplicated copies as a cause of stale node definitions and broken frontend routes, and with a graph this size you do not want to be debugging ghosts.

No external dependencies and no models: it's a trimming node working on IMAGE and AUDIO tensors you already decoded. That also makes it cheap enough to leave in the graph permanently.

How I'd wire it

Analyse every clip, save the metadata with the latent, run Stitch Ready on every segment except the last, and switch the final segment to Final Clip. Then concatenate. Every clip in the chain becomes a self-contained piece with no overlap and no frozen tail, and if you need to re-roll clip 4 later, the trim numbers are recomputed from that clip's own handover metadata rather than from anything you wrote down.