MiniMax H3 Motion Segment Plan / 动作分段窗口计划 (Advanced)

A full-clip motion repair pass on a 124-frame H3 render is one big, expensive joint AV sample - great on a big card, a gamble on 16GB. MiniMaxH3MotionSegmentPlanT8Advanced exists to turn that one monolithic repair into a sequence of budgeted windows you can render one at a time. It takes your signed full-clip motion plan and chops it into sequential, budgeted windows, each small enough that a single window's second pass stays inside your VRAM envelope.

The honest part is in the description: it does not impose a global pixel/frame prohibition on you. If the motion plan's hot ranges are too many or too hot for your budget, it reports the hot cuts so you can decide - raise the budget, lower max_hold, or accept the cost. It's a budgeting tool with good manners, not a nanny.

Inputs

• frames and baseline_audio - the pass-1 material the windows are cut from.
• motion_plan - the signed full-clip plan from the analyzer; this is what gets windowed.
• max_expanded_frames (209) - the budget per window in expanded frames. 209 is the default because it's a plausible H3-grid-friendly chunk; lower it if you're tight on VRAM.
• window_index - which window you're producing (0..999). You drive the loop yourself, rendering each window sequentially.
• handle_frames (12) - overlap/handle frames between windows so the seams don't pop.
• coverage - hot_ranges_only by default (only the flagged motion ranges get repaired); the other option is full coverage.

Outputs

segment_frames - the window's frames, ready for the retiming/prepare step. window_plan - a signed per-window plan. first_frame / last_frame - window anchors. segment_audio - the matching audio slice. window_count - how many windows the full plan broke into. window_index, and report_json.

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.

Chain position: OverloadAnalyze → MotionSegmentPlan → (per window) RetimingPrepare → RecoveryComposer → RecoverAV → MotionWindowCollect. The workflow pattern is: read window_count, then run the window loop N times with increasing window_index, feeding each result into the Window Collect node. Where people stumble is expecting this node to run the loop for them - it doesn't. It produces the windows and the plan; the loop is yours (the pack's example workflows show the wiring). And if window_count comes back bigger than your patience, that's the signal to raise max_expanded_frames or tune the analyzer's max_hold down. It's Experimental, so budget for a test pass before trusting the seams.