MiniMax H3 Motion Auto Gate / 动作自动修复旁路 (Advanced)
The lazy gate that skips the whole repair graph when H3 got it right
- baseline_frames
- baseline_audio
- motion_plan
- repaired_frames
- repaired_audio
- frames
- audio
- did_repair
- report_json
This is the node that makes the whole Motion Recovery chain affordable. The idea: your pass-1 H3 render has a second-pass repair graph hanging off it - retiming, re-sampling, re-composing - and that graph costs several full joint AV forward passes to run. But most clips are fine. So MiniMaxH3MotionAutoGateT8Advanced decides, from the analyzer's should_repair boolean, whether to run that expensive graph at all.
The mechanism is ComfyUI's native lazy inputs, and it's the real deal: when should_repair is false, the node returns your exact pass-1 frames and audio without evaluating the connected second-pass graph. Not "runs it and discards the result" - genuinely never requests the repaired inputs. The pack verified this on a real calm clip: second_pass_requested=false, and the bypassed MP4, decoded frames, and PCM audio were byte-identical to pass-1. That's the difference between a repair system you can leave wired in and one that doubles your render time on every clip.
Inputs
The gate sits between the analyzer's verdict and the repair outputs:
should_repair- fromMiniMaxH3MotionOverloadAnalyzeT8Advanced(or whatever you're using as the decision).baseline_frames/baseline_audio- the pass-1 output, what gets returned when no repair is needed.repaired_frames/repaired_audio- the outputs of the full second-pass chain, only requested whenshould_repair=true.motion_plan- the signed plan that ties the repair chain together.
Outputs
frames and audio - either the baseline or the repaired version, whichever the gate chose. did_repair - boolean, so you know which path you're on. report_json - the gate's decision record.
Install and where it fits
Pack install once: ComfyUI Manager → search MiniMax H3 Audio T8, or git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8 into ComfyUI/custom_nodes/, restart. No pip extras, no model downloads.
Where it fits in the chain: OverloadAnalyze → AutoGate → (if repair) RetimingPrepare → RecoveryComposer → RecoverAV → back into AutoGate's repaired inputs. The thing to keep straight is the direction of data: the gate takes baseline and repaired inputs and returns the right one, and the repaired branch is only pulled when needed. People wire it backwards (repaired outputs into the sampler, baseline into nothing) and then wonder why did_repair is always false. And note it's lazy-input based, so it depends on ComfyUI's lazy execution actually being active in your setup - that's standard in current ComfyUI, but if you're on a heavily patched fork, verify the bypass really happens before trusting the speed claim. It's Experimental; the mechanism is verified, the repair quality on your clip is not.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| should_repair | BOOLEAN | — | |
| baseline_frames | IMAGE | — | |
| baseline_audio | AUDIO | — | |
| motion_plan | H3_T8_MOTION_RECOVERY_PLAN | — | |
| repaired_frames | IMAGE | — | |
| repaired_audio | AUDIO | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| frames | IMAGE | — |
| audio | AUDIO | — |
| did_repair | BOOLEAN | — |
| report_json | STRING | — |