MiniMax H3 Source Media Window / 来源视频窗口 (EXP/T8)

H3 is picky about its inputs in a way that trips people up constantly: frames have to land on a 17n+5 grid, dimensions need to be multiples of 32, and the audio clock has to line up with the video clock. Grab a random slice of a source clip and feed it to the encoder, and you'll fight misalignment errors all afternoon. MiniMaxH3SourceMediaWindowT8 exists to make that step boring: it cuts a source video into an H3-legal window - 24fps, 17n+5 frames, resized to your canvas - and builds an exactly-timed 32kHz stereo audio window to go with it.

It's the "source AV redraw prep" front-end: you give it a source clip, it hands back a window your H3 VAE encoders can actually eat.

The inputs that matter

• frames - the full IMAGE batch of your source. Note the author's caveat in the description: the full input is already resident in memory. This is not streaming decode and makes no memory-safe long-video claim - for that, the pack's file-based paths are separate.
• source_fps (24), start_seconds (0) - where to cut in.
• length (124) - snapped up to H3's 17n+5 grid (the tooltip is explicit: 17n+5, so 124 → you get a legal H3 frame count, not whatever the slider said).
• width (736), height (416) - the H3 canvas, in multiples of 32.
• short_video_policy (strict) - what to do if the source is shorter than the window: strict refuses rather than guessing.
• short_audio_policy (pad_silence) - what to do if the source soundtrack runs short: pad with reported stereo silence.
• source_audio (optional) - the soundtrack. If it's missing, you get reported stereo silence, not an error and not garbage.

Outputs: the cropped/resized frames, the timed audio, plus frame_count, duration_seconds and a report explaining exactly what was cut, padded or snapped.

Why you'd reach for it

If you're doing image-to-video, video-to-video, or any "redraw this source" workflow in this pack, the encoder needs an H3-legal window and a synchronized audio clock. This node is the sanctioned way to produce both from one IMAGE input, so the rest of the graph (the pack's Source AV Prepare node, conditioning, sampling) can assume its inputs are legal. The author's own framing: this is window selection and resizing, not a streaming path and not a claim about long-video memory.

Install

Pack standard - Manager search "MiniMax H3 Audio T8", or

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8

then restart ComfyUI. No extra pip packages, no model downloads. Starter workflows live under examples/workflows/01-basic-generation/ and the source-AV examples under 03-image-video-edit/.

Where people get burned

• Forgetting the 17n+5 grid. If you hand the encoder an arbitrary 120 frames it will not round-trip cleanly. Let this node do the snapping.
• Expecting streaming. This node holds the full IMAGE batch in memory. On a long source, that's the wrong tool - the pack's file-based streaming nodes are a different route.
• Assuming strict is the only policy. If your source is a clip shorter than the window, short_video_policy controls whether you get a refusal or something usable. Set it deliberately.

It's one of those "why does this exist?" nodes until your first misalignment error, and then it's the reason your source AV workflows stop failing on frame counts.