H3Kit 动作续接

Every local video model makes clips, not films, so everyone chains them - you can read the ecosystem's priorities off the node names that got popular: "a single node for unlimited-length video (no more chaining samplers)", auto-extend nodes, joiner nodes. Chaining is where quality lives or dies, and H3 makes it harder than the image models because there's a soundtrack to keep in sync.

H3Kit 动作续接 (motion bridge) is the piece that makes the next segment continue the last one. It takes your new segment's conditioning and latent, adds a reserved block of frames at the head, re-encodes the previous clip's final frames into the new clip's temporal phase so they land on this segment's time grid as a continuous latent block, and pins those prefix frames with a sampling mask so the sampler can't repaint them. Then it hands you the bookkeeping: the latent goes to the sampler, and the two integer outputs tell the downstream trim node exactly what to remove.

One thing to know before you compare notes with the README: the pack moved this from a fixed 22-frame context to a fixed 17-frame one (5 latent time steps), and the README still describes the 22-frame scheme. Don't hard-code either number - the node's prefix_frames output is the number for your build.

What you wire in

Required: positive_conditioning (your prompt conditioning), target_latent (this segment's H3 latent), video_vae (the H3 video VAE), and audio_tail_frames - which is the interesting one. It's how many frames of tail audio to pin, independent of the picture window, in an end-aligned window. The author's tooltip does the math for you: multiples of 3 land exactly on H3's 40Hz audio grid, multiples of 24 are whole seconds, so the default 24 pins the last second, and off-grid values get widened to the nearest whole step. If your continuation is a face talking, this is how you stop the join from clipping a syllable mid-vowel; 0 falls back to 17 frames.

Optional, and this is the split that confuses people. Give it previous_latent - the previous clip's sampler output, the same latent you fed into your decode nodes - and it works from that. Or give it previous_frames (the previous clip's already-decoded pictures) to save an extra decode, plus sound_vae and previous_audio to carry the previous clip's tail sound across the join. Both of those are ignored when previous_latent is wired.

First segment: connect nothing on the optional side. The node passes conditioning and latent through untouched, which is exactly what you want - no phantom prefix to trim.

What comes out

Four outputs, and they go to two places. positive_conditioning and target_latent feed the sampler. prefix_frames and delivery_frames feed H3Kit 音画同步裁剪, which removes the pinned head and any tail padding the length alignment added, so what you deliver is the segment you asked for rather than the segment plus context.

The usual chain looks like this:

H3 conditioning + target latent → 动作续接 → sampler → VAE decode → 音画同步裁剪 → save (24fps)

Keep resolutions identical across segments - the bridge wants the previous segment at the same resolution as this one, and the low-res/high-res stages each get their own inheritance, so in a two-stage flow you pass the previous low-res sampler output to the low-res stage and the previous high-res result to the high-res one.

Install

Manager → search ComfyUI-H3-upgrade-kit → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/flywhale-666/ComfyUI-H3-upgrade-kit.git

No Python dependencies: requirements.txt is empty and the pack declares none, so it uses the torch/torchaudio your ComfyUI already ships. What it does need is a ComfyUI new enough that the H3 layout supports arbitrary keyframe anchors - the pack validates that on first use and tells you to update ComfyUI if the layout doesn't match. Models aren't included: H3 weights, text encoder, audio and video VAEs, and any acceleration LoRA are yours.

Realistic expectations

The pinned prefix means your sampler is generating frames that will be thrown away. That's the price of continuity, and it's why the trim node exists - but if you spot-check the raw decode and see the first frames frozen, nothing is wrong.

No node fixes the model, though. The README's FAQ admits continuations aren't guaranteed seamless - backgrounds and objects at the join can still shift, because the model decides that, not the plumbing. What this buys you is that the motion carries and the frames land on the right temporal phase. If your join still clicks audibly, that's the trim node's align_audio_tail job.