沐阳 H3 · 段间多关键帧
How Myang stitches two H3 segments together
- conditioning
- vae
- latent
- context_latent
- context_frames
- context_audio
- audio_vae
- conditioning
- trim_frames
- masked_latent
This is the node that makes the whole pack make sense. H3 generates short clips - the practical sweet spot is a few seconds per shot - and everything beyond that is a continuity problem. 沐阳 H3 · 段间多关键帧 (H3AnchorContext) is Myang's answer: take the tail of the previous segment and pin it as multi-keyframe context at the head of the next one, so segment N+1 literally starts from where segment N left off. It's a descendant of the ComfyUI-H3-Motion-Context approach, reimplemented and extended here.
Here's the mechanism, because it's the part people get wrong. The node takes your new segment's latent plus a source of context - either the previous segment's context_latent or the decoded context_frames - and builds the context window as keyframes at frame 0 of the new segment. Crucially, the overlapping region gets no random noise: the masked_latent output carries the anchor area zeroed out, so only the genuinely new frames participate in denoising. The pinned frames are then trimmed out of the delivered portion by 沐阳 H3 · 锚点同步裁剪 (H3AnchorTrim) - which is why the node hands back a trim_frames count - so your assembled video keeps its real length. The whole window is pinned at once; there's no step-by-step scheduling to tune, which is a deliberate simplification that keeps results stable.
The inputs that matter
- context_length - the size of the continuity window. 22 frames (default) is the recommended baseline, about 0.92 seconds and 7 temporal blocks. 5 is the experimental speed anchor with just 2 blocks; 39 and 56 give stronger continuity but cost more conditioning tokens and more trim waste. Establish a two-segment baseline at 22 before comparing anything else.
- context_latent - the previous segment's latent, the usual path. Note the hard rule: previous and new segments must be the same resolution, or the node raises instead of silently producing mush.
- context_frames - decoded pixel frames instead of the latent, if that's what you have. Same result, slightly more expensive.
- context_audio / audio_vae - carry the previous segment's sound into the head of the new one. Connect both or neither; audio without an audio VAE is an error.
Outputs: conditioning (with the keyframes appended, ready for your sampler), trim_frames (feed this to H3AnchorTrim), and masked_latent (the noised-new-only latent).
Install and the conflict warning
Pack install is standard: ComfyUI Manager search "ComfyUI-MiniMaxH3-Myang", or git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang into custom_nodes, restart. No extra Python deps.
The one genuine trap here is coexistence: Myang patches ComfyUI's MiniMaxH3 layout code to support its anchors, and it does not play nicely with the older ComfyUI-H3-Motion-Context if both are installed - the README's instruction is "use only one H3 continuity implementation in a job, and restart ComfyUI before switching graphs." If anchors throw a PackedLayout has been modified style error, that's almost certainly what happened. Also: resolution must stay constant across segments when you're using temporal latents, and a clean seam doesn't mean content quality won't drift over a long chain - that's why drift correction exists as a separate node.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| conditioning | CONDITIONING | — | |
| vae | VAE | — | |
| latent | LATENT | — | |
| context_length | COMBO | 22 | 22=稳定连续窗;5=实验速度锚点(2个 temporal blocks) |
| context_latentopt | LATENT | — | |
| context_framesopt | IMAGE | — | |
| context_audioopt | AUDIO | — | |
| audio_vaeopt | VAE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |
| trim_frames | INT | — |
| masked_latent | LATENT | — |