🔗 H3 Relay · Trim AV

Here's the thing nobody tells you about latent continuation: the first N frames of a continued segment aren't new content. They're the model's regeneration of the previous segment's tail - same shot, sampled twice, around 6/255 mean absolute error per frame. Measured properly, segment B's first frame matches frame −22 of segment A at MAE 3.09, while the next-best candidate sits at 17.5. A real match, not coincidence.

The consequence is that if you just concatenate the two segments, you get about 0.92 seconds of the same action playing twice. H3RelayTrimAV cuts it. It takes the decoded frames, drops the overlap off the head, and cuts the audio by the same number of samples so the two don't drift apart. Framing it as "trim" undersells it slightly - it's the node that keeps your A/V in sync across a whole film.

The amount is automatic: wire the bridge's trim_frames output into this node's trim_frames input. On segment 1 the bridge passes through and hands over 0; from segment 2 onward it's the pin count (22, typically). Type a number in by hand and you'll eventually disagree with the bridge - the input's own tooltip says as much.

Inputs you actually touch

Required: images (from your VAEDecode), trim_frames (from the bridge - don't type it), fps (24, leave it).

audio is optional in the schema and mandatory in practice: feed it from VAEDecodeAudio. Without it, the picture gets cropped and the sound doesn't, and the audio ends up longer than the video by the trim amount - about 0.9 s per seam, compounding. If the node's report line says it found no audio wired, take that seriously; it can detect a missing input, but it cannot detect a downstream wire you've left dangling, which is why the pack ships a workflow checker for that specific mistake.

Then the one parameter with a real recommendation attached: settle_frames stays at 0. Historically people cropped the extra "settle" frames that follow the pinned region - the model replays a few frames before switching to new content, and they're a bit soft. Cropping them makes the seam jump. Measured on the same segment, varying only this value: crop 0 → seam jump 0.020 (essentially invisible), crop 8 → 0.044, crop 16 → 0.055. What you leave in is a sharpness gradient, and the eye is extremely forgiving of those. Trading a gradient for a discontinuity is a bad deal, so 0 is now the default. -1 measures a cut point automatically (fixes softness, introduces jumps - inspect it), and a positive N crops a fixed number of frames, which you'd only do to keep segments equal length.

save_pcm (on) writes an extra ~2 MB PCM sidecar per segment so concatenation reads lossless audio instead of decoding the AAC track in the mp4 and re-encoding it - your finished film's audio is then one generation, not two. A failed write only logs. diagnostics (off) turns on three read-only reporting paths: DTW alignment cost, a crop-versus-jump curve, and appearance drift. Pure printing, ~0.4 s of CPU per segment, zero GPU, no effect on any output.

Outputs: images, audio, report, and prev_tail - the last frame of the pinned region, i.e. the frame on the other side of the seam. prev_tail feeds the Post node's guide. Whether it's genuinely the previous segment's final frame depends on which bridge route you used, and the pack is upfront about that: under the bit-exact copy bridge it is; under conditioning-only pinning it's a redraw and therefore approximate.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ZenHG/ComfyUI-H3-Latent-Relay.git

Or ComfyUI Manager → Custom Nodes Manager → search h3-latent-relay. Restart the backend process. Nothing to download; this node works on decoded tensors and needs no models beyond what ComfyUI and H3 already provide.

Where it goes wrong

"Asked to crop N frames but this segment only has M" means trim_frames got the wrong value - usually hand-filled, or wired from the wrong output. Take it from the bridge.

Segment looks like it starts over. Trim AV isn't connected, or its trim_frames isn't fed by the bridge. The pack's own troubleshooting table names this as the number-one wiring mistake.

Audio and picture diverge progressively from segment 3. The tell is that it isn't constant - each seam adds to it. Almost always the save node's audio input is fed straight from VAEDecodeAudio instead of from this node's output, so the picture gets trimmed and the track doesn't.

seam_ghost and settle_sharpen. seam_ghost blends the first frame with the previous segment's last frame, and it's off because it doesn't help: total displacement dropped 7% while the number of anomalous frames doubled, so instead of one jump you get two. Fix the cause - reduce cropping - or repair softness in the image domain (Post's settle_auto), which can't introduce a jump because it doesn't touch the timeline.