H3 · Window Inputs

Thirteen outputs. That's the number that makes people close the tab. H3 · Window Inputs is the busiest node in the H3 Relay toolkit - and once you see what it's replacing, the thirteen wires start looking like a bargain.

You're running a native Start Loop over a list of windows. Inside that loop you need: this window's source pixels, padded to a legal length; the mask for those same frames; the target audio; the history frames H3 should continue from; the audio for that history; a reference video; an anchor image; a seed; and a history length as a plain integer. Do it by hand and you need four slice nodes, three pad nodes, an audio trim, a manual seed picker and a lot of graph spaghetti that breaks the moment a window changes size.

This node does all of it, from one window record and an iteration index.

What it does with your frames

It looks up windows[iteration_index] - that's the whole reason the iteration_index input exists and why the loop must be a native Start Loop in count mode. Then, per window:

It slices source[start:end] and pads the tail by repeating the last frame up to the window's legal size. It slices the mask to the same span and pads it identically. It slices source_audio on the 24 fps clock, again padded. If the window has history (history_frames above 0), it pulls the last history+? frames of generated output from the previous carry socket, insists they sit on the exact source boundary, and grabs the matching slice of audio from either the source track or the generated one - your choice, via history_audio_mode. The anchor becomes the last history frame, or your supplied anchor, resized to the source canvas with Lanczos unless you turn resize_anchor off.

It also validates. Loudly, and early: source not RGB, dimensions not divisible by 32, mask length or resolution mismatch, 24 fps violated, missing generated history at the boundary. Every one of those would otherwise surface as a corrupted frame three stages downstream.

The inputs you actually set

• source - Prepare Source's reference_frames. Not the raw video, not a Load Video output.
• window - the windows bundle from Plan Windows (or from Review Windows, if you're doing durable rerolls).
• reference_history - on by default. It extends the reference video backwards by history-1 frames so H3 sees the same context patch as the continuation. Turn it off for source-aligned removal work where you want the guide to be exactly the window.
• history_audio_mode - source keeps your original audio as the continuation anchor (right for character swap), generated continues from H3's own generated audio, none stops it cold.

Optional inputs are the carry socket (previous), the mask, source_audio, and initial_history / initial_history_audio for the segment schedule when you're restarting from saved frames.

The outputs you'll wire

source_window goes into VAE Encode (that's your edit target), edit_mask into Apply Edit Mask, history and history_audio into Apply History, history_frames into Apply History's integer input, anchor into H3's native guide node, target_frames and seed into whatever's queueing the pass, and window into Append Window so the state knows what it just assembled. reference_video / reference_audio feed H3's reference-conditioning node for the H-1 alignment case. conditioning_length is the total conditioning extent if you need to sanity-check it.

Install

Manager → H3 Relay → restart. Manual:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

You need the H3 weights (FL2VA/Ref2VA diffusion model, the Qwen3-VL 32B text encoder, video and audio VAEs) and ComfyUI 0.37.0+ for native loops. No extra pip packages; the pack declares none. Worth saying plainly: H3's weights are territory-restricted (US, EU, UK, Korea are carved out of the MiniMax H3 Community Licence, outputs included), so check that before you plan your weekend.

Where people get burned

fps is a float and it is not decorative. Anything other than 24 (within a tolerance) throws, because slicing audio at the wrong clock silently desyncs lip movement - and you'd rather have the error.

The second one: previous must come from the loop carry socket, not from a node outside the loop. Wire it backwards and window two sees no history and dies on "Missing generated history at the exact source boundary". Third: if you built the mask chain against a different resolution than source, this node tells you so - that's the mask tool's problem, not this node's, but this is where you find out.