MiniMax H3 Local MV In-Node Renderer / 全本地MV内循环生成 (Advanced EXP/T8)

Normally a multi-scene MV in ComfyUI means babysitting it: run scene one, review, queue scene two, hope the node graph doesn't drift, and hand-stitch the videos with ffmpeg afterward. This node is the "stop babysitting me" answer. It takes the scene plan and per-scene prompts produced upstream, then generates every Ref2VA scene serially through the local MiniMax H3 model you connected, resumes anything it already finished, assembles the clips with bounded memory, and muxes your original song onto the final video exactly once. All from one queue.

Three design facts make it worth understanding before you queue anything long:

Three design facts

It is fully local and serial. The model, clip (the H3 Qwen3-VL text encoder), video_vae and audio_vae are all wired from your local graph. Scenes run one at a time through that single model - no concurrent generation, no HTTP /prompt queue submission, no remote H3, LLM, TTS or video API. Serial is slower but it's what makes memory bounded and resume possible.

It resumes like a download manager. Each run is bound to a chain_id (default my_h3_local_mv) plus a contract - the prompt plan, reference image, model_id, seed, geometry, timeline and sampling summary are hashed together. Accepted scenes are saved atomically with a manifest. Interrupt a 20-scene render at scene 14 and re-run with the same chain_id and settings: it verifies the contract hasn't changed, skips the accepted scenes, and finishes the rest. Change anything material and it refuses rather than silently mixing old and new footage. resume_existing (default true) is the switch for that behavior; leave it on.

Your generated audio is a placeholder. Each scene's video is conditioned on the song via <Audio 1>, but the segment audio is never your final soundtrack - the node muxes the complete original full_song once over the assembled video. That's deliberate: no per-segment AAC seams, and the master audio stays bit-perfect. What you get out is video timed to the music with the real song on top.

Inputs and outputs that matter

The inputs that matter beyond the model wiring: reference_image (your performer identity reference), full_song, mv_prompt_plan (from the Ref2VA Prompt Compiler), chain_id, base_seed, width/height (default 1024×768, must be multiples of 32), and steps (default 8) with the dual-clock sampler_name/scheduler and shift_video/shift_audio (defaults 6/3) hidden under advanced. crf and bit_depth control the encode. model_id is audit-only metadata - it's written to the report, never used to block a file.

Outputs: video (with in-canvas preview), video_path, manifest_path, completed_scenes (how many finished - not a quality verdict, just mechanical acceptance), status, and a report_json audit string.

V1 vs the Vocal Lock route

Reality check on which renderer to use. This is the V1 renderer: it conditions each scene on the full song mix. It's the simplest to stand up and fine for prototyping a full-song MV, but the README is clear that the Vocal Lock V2/V3 chain - isolated vocal driving the mouth, official recipe - is the accepted route for verified lip-sync. If the whole point is checked mouth movement on clean vocals, go V2 or V3. If you want a fast full-song draft where the performance just needs to move with the music, this is your node. Both routes share the resume/mux architecture.

Installing it

Install: ComfyUI Manager search MiniMax H3 Audio T8, or clone into custom_nodes (git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git) and restart - after updating ComfyUI core itself, since the pack relies on the recent native-H3 and weight-adapter APIs. Run the dated Ref2VA workflow under examples/workflows/24-mv-lipsync; and remember these local H3 weights are licensed territory-restricted (excluded in the US, EU, UK and South Korea).