H3 Continuous - Auto Handover Analyzer (Legacy v0.x)

The name is clunky, but the job is dead simple: this node watches the end of a MiniMax H3 clip and tells you exactly where the video stopped being real footage and became a frozen landing. You'd reach for it because FL2VA clips (first-frame + last-frame video) almost always end in a locked, barely-moving tail - the model "lands" on the last frame and just sits there. If you blindly stitch the next clip onto that, you get the motion, framing, and color of a corpse. This analyzer finds the freeze so the rest of the suite can cut before it.

It's the original v0.x detector from Herrgotts-H3-Infinite-Continuation-Suite, still registered for legacy workflows. On a fresh install you probably want the newer presets (the v1.0+ analyzer), but if an old workflow loads this class, it keeps working.

How it works

The algorithm is called Stable-Tail Consensus, and it's smarter than "is the last frame different from frame N-1?" It builds a median "final state" image from the last final_reference_frames (default 15) frames, then walks backward looking for where frames stop matching that state. Why median instead of one frame? A single shimmering last frame can fake a freeze or a motion that isn't there. The median kills that.

Two gates have to agree:

• Primary lock test - candidate frames must stay within a tiny mean RGB difference of the median reference (final_mean_diff_threshold, default 0.012), with only a small percentage of the image materially different (max_final_active_area_percent, default 3).
• Secondary safety test - transitions inside the lock must be near-static too (transition_mean_diff_threshold 0.002, max_transition_active_area_percent 1), so sustained real motion can't sneak into a "locked" suffix.

Then there are robustness gates: at least min_final_match_percent (75%) of the suffix must match, a couple of consecutive outliers are tolerated, and the lock must persist for freeze_hold ending frames. Defaults here are tuned for safe-early lock detection - better to cut a couple frames early than to swallow a real freeze.

The outputs are where it pays off. handover is the H3_CONTINUOUS_HANDOVER struct that the Continue node consumes - that's the one that matters. freeze_detected, freeze_start_frame, ideal_handover_end_frame, phase_aligned_handover_end_frame, and confidence are diagnostics for when you're staring at a bad seam and want to know what it thought. ignored_tail_frames tells you how many frames it threw away, which is the number you'll care about when the math doesn't look right.

The inputs you actually touch

images is your decoded full render of the accepted clip - the node works on pixels, not latents. Everything else has sane defaults. If you change anything, it's usually:

• safety_margin (default 3): how many frames of buffer before the detected lock. safety_mode=fixed is recommended and always respects it.
• freeze_hold (default 12): how long the tail must be frozen before it counts. Lower = triggers earlier.

Installing it

This ships in the Herrgotts-H3-Infinite-Continuation-Suite pack. Easiest path is ComfyUI Manager - search "Herrgotts-H3-Infinite-Continuation-Suite" and install. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/HerrgottMargott/Herrgotts-H3-Infinite-Continuation-Suite.git

Restart ComfyUI, reload the browser. There's no heavy Python dependency - this pack hooks into ComfyUI's native MiniMax H3 implementation - but it does not ship model weights. You still need the H3 checkpoints, video/audio VAEs, and Qwen 3 VL from the Comfy-Org MiniMax-H3 repo (see the docs.comfy.org MiniMax H3 guide), which is a hefty download.

Gotchas

Feed it the accepted render - if you analyze frames that were already stitched or trimmed, the frame math against the latent won't line up. And remember it's pixel-based: H3 at 24 fps means analysis_window of 72 inspects the last 3 seconds, which is plenty for a freeze that usually shows up in the final second. If the whole window is already locked, it automatically expands backward.