MiniMax H3 In-Node Long Video Loop / 节点内循环长视频 (Advanced EXP/T8)

MiniMax H3 generates clips in bounded windows - the model's native length tops out around 15 seconds, and the pack's baseline window is 124 frames. Anything longer means stitching segments, and the old way of doing that in ComfyUI is a queue of separate runs with you babysitting each one. This node is the "fire and forget" alternative the README points new long-video users at: one execution generates every segment strictly in sequence, accepts each completed segment atomically, survives interruption by resuming from disk, and streams the accepted files into one final video. You queue it once, go make coffee, and come back to a finished clip.

The key design decisions are in the description, so read them carefully. Segments run strictly in sequence - deterministic, no parallel VRAM gambling. Each completed segment is atomically accepted before the next starts, which is how interruption recovery works: what's on disk is trusted and complete. And critically, this route intentionally has no per-segment human review gate. If you want to eyeball every segment before it's committed, the pack says plainly to use the existing Background/Accepted workflow instead. This node is for people who trust the process; the review path is for people who don't.

The inputs that matter

The schema is big because it's a full pipeline in one node. The ones you'll actually touch:

• model, clip (the native H3 Qwen3-VL CLIP), video_vae, audio_vae - the usual four
• chain_id - names this job; resume keys off it, so don't change it mid-run
• total_duration_seconds (30) - how long the finished video is; segments are derived from this and the window
• width / height (736×416) and render_window_frames (124 baseline) - canvas and per-segment length
• global_prompt and segment_prompts_json - the story; per-segment overrides let you change prompt/seed per shot
• base_seed + seed_policy (increment) - how seeds roll across segments
• steps (4), shift_video (12), shift_audio (3), sampler_name (dual_clock_euler), scheduler (native_flow) - the sampling stack
• audio_mode, audio_denoise_strength (0.35) - sound handling, including lock_source to preserve original audio
• resume_existing (true) - resume only when the saved job contract matches; disable to force a fresh chain

Outputs: video, video_path, manifest_path, completed_segments (INT - how far you got, handy after a resume), status, and report_json.

Installing it

Part of the T8mars/comfyui-minimax-h3-audio-T8 pack - search "MiniMax H3 Audio T8" in ComfyUI Manager, install, restart, or:

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

Update ComfyUI itself first (recent core: comfy_api.latest, comfy.weight_adapter, comfy.patcher_extension, comfy.ldm.minimax); requirements.txt is intentionally empty. The canonical workflow is 04-long-video/In_Node_Long_Video_Loop - drag it in, replace the model and media, run.

Where people get burned

Two traps. First, the seed contract: base_seed + increment means a rerun doesn't give you the same frames unless the contract (prompts, LoRAs, sampling) is identical - which is also the condition for resume_existing to accept a resume. Change anything mid-run and the resume logic correctly refuses. Second, VRAM: the README's minimum_free_vram_mib-style floors exist for a reason; this node holds a lot in flight, so drop resolution/frame count before blaming the loop. And don't stack it with other nodes that own the sampler or MODEL forward path. FFmpeg on PATH matters too - the final mux and streaming into one video is where the "one file at the end" promise gets fulfilled.