H3 Video Outpaint · Plan (EXP)

Outpainting video is inpainting with the mask inverted: your original footage is the part you're not allowed to touch, and everything you bolt on around it is new content the model has to invent. MiniMaxH3VideoOutpaintPlanT8 is where that bolt-on area gets defined - and it's the first node in every one of the twelve EXP workflows in examples/workflows/27-video-outpaint.

Reach for it first for a boring reason: the plan is the single thing everything downstream is keyed to. Change a margin by two pixels and you have a different plan hash, which means different caches, which means re-encoding the source. Better to discover that now than forty minutes into a 768-frame run.

What it actually computes

The node opens your source file, hashes it, and reads back width, height, frame count and fps. Then it turns your margins into a delivery canvas and a separate sampling canvas. Those two are not the same thing, and that's the important bit.

H3 works on a 32-pixel spatial grid, so the canvas gets padded up to a multiple of 32. Your generation_megapixels budget (0.5 by default) then caps how much the model actually has to chew: the padded canvas is scaled down isotropically into that budget, with unused model space treated as padding rather than stretching. The delivered frame still comes out at full size - the source rectangle gets aligned into latent cells using the slack so a partial generated strip never gets locked in as source context.

You define the target canvas two ways, and you can mix them:

• Explicit margins - left, top, right, bottom, in output pixels. Dumb, predictable, my preference when matching a specific client aspect.
• A target aspect - aspect picks from source, 9:16, 16:9, 1:1, 4:3, 3:4, 9:12 or custom, and anchor_x / anchor_y (0–1) say where the original sits inside the new canvas. 0.5/0.5 centres it; push the anchor toward the top and you get headroom instead of a floor.

window_frames picks the serial window length from a fixed list - 39, 56, 73, 90, 107, 124, 158, 192. These are the frame counts H3's temporal packing handles cleanly (roughly 5 + 17k), so don't expect free numbers. cut_frames_json is a JSON array of absolute source frame indices at hard cuts; each shot gets its own window plan, and windows don't straddle a cut. On a talking-head clip you leave it [] and get one long shot.

Inputs and outputs

The required inputs are source_video plus the geometry and window settings above. The source must be an uncropped 24fps SDR CFR file - the validator is strict, and a VFR screen recording is the usual culprit when the node refuses to build a plan.

Two outputs: plan, an opaque handle you feed to Prepare, Guidance, Preview or the prepared-cache reload; and plan_report, a JSON string you should actually read once. It's where the computed output size, sampling size, source rectangle and shot/window breakdown show up.

Install

Manager: search MiniMax H3 Audio T8 and restart ComfyUI completely. Or:

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

The pack's requirements.txt installs nothing on purpose - it keeps your ComfyUI Torch/CUDA stack safe - but generation needs ffmpeg on PATH and ComfyUI-KJNodes for the audited low-VRAM attention/FFN patches. This node itself is pure CPU geometry; it loads no model. One licensing note worth knowing before you download anything: the MiniMax H3 Community License excludes the US, EU, UK and South Korea from its grant, outputs included.

Where people get burned

Planning is cheap and re-planning is not. Changing margins, aspect, prompt, VAE or CLIP means a new run_name and a fresh preparation cache; only changing seed/steps/sampling model lets you keep the run and bump the candidate_name. And be honest about generation_megapixels on a 16GB card - that number is your actual VRAM dial, not the output resolution.