MiniMax H3 Face Refine Window Extract / 合法窗口提取 (Advanced)

The previous node planned the fix; this one does the surgery. MiniMaxH3FaceRefineWindowExtractT8Advanced takes your full source timeline plus a window plan and pulls out one window - the frames H3 will actually regenerate, padded out to a legal 17n+5-frame length with the context frames around your repair range. What comes out is exactly what you feed to the H3 sampler. Nothing has been rendered yet; this is pure frame extraction, and it does it without resizing a single pixel.

How the extraction works

The window plan already decided the frame boundaries. This node's job is to honor them: slice out the contiguous render window, attach the mapping that says which of those frames are real repair targets versus context padding, and - if you fed it source_audio - build the matching audio window. The subtle bit is what happens when your repair range butts against the very start or end of the clip and there aren't enough context frames to borrow. That's what pad_policy governs:

• reject (default) - an under-full window is an error. If the plan asks for context that doesn't exist, you find out now, not after a wasted render.
• edge_hold_exp - explicitly experimental: the boundary frame is repeated to fill the missing context. But here's the honest catch the node description states plainly: the repeated image gets context, while the corresponding audio samples stay zero - silence. Padding is a visual crutch for the model, never a real part of the source, and the node makes sure you can't forget that.

Inputs

• base_frames - your full source IMAGE timeline (same tensor the planner saw).
• window_plan - the signed plan from MiniMaxH3FaceRefineWindowPlanT8Advanced.
• window_index - which window to extract (0 is the first). For multi-window work you run this once per index, serially - never concurrent, because two H3 renders will fight over VRAM.
• pad_policy - as above.
• source_audio - optional, but connect it: the node outputs a proper audio window for the sampler, and knowing where the audio is zeroed beats discovering it later.

Outputs and where they go

• render_frames (IMAGE) - the window you encode with the video VAE and push through the sampler. This is the input to your H3 face-refine generation pass.
• render_audio (AUDIO) - its audio partner. Treat it as a generation aid. The pack is explicit: generated window audio is never authorized as the final soundtrack - the finished video always uses the full original audio track, so whatever the window render invents in audio gets discarded.
• window_mapping (type H3_T8_FACE_REFINE_WINDOW_MAPPING) - the signed map that tells the review/commit nodes which extracted frames correspond to which source frames and which regions are context. This is what keeps context and padding from ever being accepted into the result.
• source_start_seconds, render_duration_seconds - where the window sits in the source timeline.
• accept_relative_ranges_json - the planned repair range, expressed relative to the window (so the review stage knows what "the bad frames" are).
• report_json - diagnostics.

After the sampler runs, the decoded candidate and this window_mapping feed MiniMaxH3FaceRefineManualReviewT8Advanced (single-window path) or the Studio Commit node (serial path). Full graphs: examples/workflows/06-face-refine.

Install and gotchas

Pack install is the standard one - ComfyUI Manager search "MiniMax H3 Audio T8", or clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8 into custom_nodes and restart; no extra pip dependencies for this node. The whole Face Refine Window route is marked Advanced EXP, so read the plan's report_json before burning GPU time, and expect reject to be strict by design - it's stopping you from rendering a window that can't be legally reconstructed.