H3 Video Outpaint · Prepare (EXP)

MiniMaxH3VideoOutpaintPrepareT8 is the unglamorous half of the four-stage chain - Plan → Prepare → Sample → Compose. It takes the plan plus your CLIP and video VAE, and does all the expensive encoding once: source frames into VAE latents, the soundtrack into the shapes H3's audio branch expects, and your prompt into conditioning. Everything lands in a cache directory keyed to the run, and the sampling stages reuse it.

If you've done masked inpainting in ComfyUI before, you already know why this separation exists. The rule everyone eventually learns is that you don't re-encode the parts you aren't regenerating. Outpaint simply can't get away with it - the whole point is that the original pixels need to survive, and the source has to be available as conditioning for every window. Do it once, verify it once, reuse it for every window and every window after that.

What it takes

The required inputs are plan, clip, video_vae, prompt, shot_prompts_json, run_name, audio_track, audio_block_tokens and resume_audio. audio_vae is optional - but only nominally. If the source has an audio stream and you don't connect it, the node raises instead of quietly dropping your sound:

this source has audio: connect the native H3 audio VAE; audio will not be silently discarded

Good behaviour, and unusual. Plenty of video nodes will happily hand you a silent file.

The two prompt fields are worth five minutes of your attention. prompt is the base prompt for the run. shot_prompts_json is a JSON array with one string per planned shot - if you supply it, it must match the shot count exactly, or the node errors. Leave it [] and the base prompt applies everywhere. On a single continuous clip that's fine; on a cut-heavy edit it's the difference between "a street at night" and "a street at night" pasted over a hard cut into a beach.

audio_track selects which stream of the source to carry through (0-based, and it validates against what's actually in the file). audio_block_tokens (default 64, 1–128) is the audio packing granularity. resume_audio lets an interrupted encode pick up where it stopped rather than starting the audio cache over.

run_name (default outpaint_01) is the cache address. Path-traversal-ish names are rejected outright - 1–64 characters of letters, digits, underscores and hyphens, no Windows device names.

Outputs are prepared, the handle you wire into Sample, Candidate and the loader nodes, and preparation_report, a JSON string with the source, audio and conditioning hashes plus generated_video_complete: false so nobody mistakes it for a finished run.

The caching rule that bites

The cache root is derived from the run name and the first 16 hex digits of the plan hash, which is why everything downstream re-validates identity. Change the source file, the margins, the prompt, the CLIP or the VAE, and you must use a new run_name. Change only seed, steps or sampling model and you keep the run, bumping candidate_name instead. Silently reusing a run name after editing the prompt is the single most common way to get a confusing mismatch error later.

Install

Manager: search MiniMax H3 Audio T8, restart ComfyUI fully. Manual:

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

requirements.txt installs no packages by design - the probe here is that the base nodes take torch, torchaudio, numpy, Pillow and safetensors from your ComfyUI environment. You do need the H3 files in the usual places: the FL2VA base model in models/diffusion_models, qwen3vl_32b_minimax_h3_int8_convrot.safetensors in models/text_encoders, and the fp16 video and fp32 audio VAEs in models/vae. Generation routes also need ComfyUI-KJNodes. And if the pack's nodes all turn red, update ComfyUI itself, the frontend and Manager before you file anything - the pack tracks native H3 support closely and a stale core is the usual cause.