H3 Continuation · Start
Anchor Both Ends and Let H3 Fill the Middle
- clip
- vae
- first_frame
- last_frame
- reference_image
- positive
- latent
Long video out of short-clip models has one canonical move, and it's older than any of the current crop of models: generate a clip, take its last frame, use it as the first frame of the next one, repeat. The community has been doing this since the "long consistent AI anime" days, and the complaints haven't changed either - the standard answer in the knowledge base is "last-frame-to-first-frame chaining, and character consistency across the joins is still unsolved without careful engineering."
This node is the opening move of the more careful version. It's Clip 1. You give it a first frame, a last frame, and a duration, and it hands the sampler a conditioning + latent pair where both anchors are already placed.
What that buys you
Two things, and the second one is the interesting one.
The obvious one: your clip now lands on a target image instead of just ending somewhere. You can pre-generate the destination - render the keyframe you want the shot to arrive at, and the model works toward it.
The subtle one: a first/last-frame model near its final frame tends to decelerate, lock onto the target image and start repeating it. That's not a bug, it's the behaviour, and this pack treats it as the seam. Because the tail is (nearly) frozen, you can cut there and hand the latent - not a decoded frame - to the next clip, with far less visual damage than a last-frame handoff. The whole continuation family downstream, including the handover analyser, exists to find exactly that lock reliably. It only works if Clip 1 had a last frame to converge on, which is why last_frame is a required input here and optional on the Continue node.
Inputs and outputs
clip and vae come from your H3 text encoder and video VAE. prompt is your shot direction, multiline. width/height default to 1344×768. first_frame and last_frame are the anchors - both IMAGE.
Then duration, which is the field that trips people up. It's in seconds at H3's native 24 fps, and the actual frame count snaps upward to H3's 17k+5 grid. The tooltip gives the worked example: 10.0 s becomes 243 frames, which is 10.125 s. So your clip is always a hair longer than you asked for, and every downstream frame count should be read off the actual render, not your typed duration. Getting this wrong is the entire reason the pack ships an analyser and a stitch node instead of trusting you to count frames.
ref_image_size is match or max. The optional reference_image is Qwen-only and gets addressed in the prompt as <Picture 1>; it is deliberately not added to minimax_refs, so it isn't a second keyframe - it's identity and style context.
Outputs: positive (CONDITIONING) and latent (LATENT). The latent is the empty AV latent at your dimensions and snapped length; wire both into your sampler. Note there's a single positive conditioning out - a negative/zeroed conditioning is yours to build.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Manager → IAMCCS Nodes; restart, hard-refresh, one copy of the repo only. These H3 Continuation · nodes ship inside the pack's bundled FL2VA continuous-AV engine, so there's no third-party node pack to hunt down for this one. What you do need is a working H3 model setup - the pack ships no weights - and enough VRAM for FL2VA at your chosen size.
The engine's own attribution is worth a line, because it's a sign of where these ideas come from: it's built by IAMCCS and credits HerrgottMargott's H3 Infinite Continuation Suite for the continuation-method lineage, along with a handful of other H3 continuation projects. The pack's author is a known quantity in these threads - his SVI Pro v2 for Wan 2.2 was the release people credited for minute-plus long-form on consumer cards - so this lineage-aware approach is consistent with how he's worked before.
Practical notes
Start short. A 5-second clip 1 at your target resolution tells you whether your anchors are pulling in compatible directions. If the render snaps hard onto the last frame too early, your last_frame is doing too much of the work - that's a creative problem, not a node problem.
One more: the H3 Continuation · family is dated v1.2 in its descriptions, and the author's numbering moves. If a widget you saw in a tutorial isn't there, check the node's own tooltip - it's usually still the truth.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| vae | VAE | — | |
| prompt | STRING | — | |
| width | INT | 134432–16384 | — |
| height | INT | 76832–16384 | — |
| duration | FLOAT | 10.00.25–150 | Requested duration in seconds at H3's native 24 fps. The actual clip snaps upward to H3's 17k+5 frame grid (10.0 s -> 243 frames ~= 10.125 s). |
| first_frame | IMAGE | — | |
| last_frame | IMAGE | — | |
| ref_image_size | COMBO | match | 2 options: match, max |
| reference_imageopt | IMAGE | Optional Qwen-only identity/style reference. Address it as <Picture 1>. It is NOT added to minimax_refs. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| latent | LATENT | — |