MiniMax H3 · QUALITY LATENT 2-PASS · Streamed Delivery

By the R41 revision of the IAMCCS MiniMax H3 pipeline, the finishing philosophy crystallized into something the author calls the Quality Latent 2-Pass: stage 1 renders a shot at native resolution as fast as possible, and stage 2 re-samples the latent at higher quality, upscaled, before decoding. The IAMCCS_MiniMaxH3FastLatent2PassR41 is the output node that executes that second pass per segment and streams each result straight to an MP4 - it's the terminal node of the workflow, the thing a render queue runs.

It's "fast" in the sense that the second pass is an upscale-and-refine, not a fresh generation - low steps on an upscaled latent with the original conditioning and, crucially, the original audio locked. The author's own metadata tag for the output is fast_latent_2pass_audio_locked: the video latent gets the quality treatment while the audio from stage 1 rides along untouched. Lip-sync and timing survive the second pass because the audio is never re-derived.

How it works

• It must run after the native H3 checkpoint - the node validates that a native save report reached it and errors otherwise ("FAST LATENT 2-PASS must run after the native H3 checkpoint"). The stage-1 latent, native frames/audio, resolved render ID and saved report are all inputs.
• Needs the minimax_h3_latent_upscaler_3d checkpoint installed; it raises up front if missing.
• Upscales the stage-1 latent, builds stage-2 conditioning (references, bridge frame, first/last-frame overrides all supported), samples the refine pass, then decodes through the streamed VAE/ffmpeg path IAMCCS ships with the pack so a long segment never sits in RAM as one giant tensor.
• Writes segment_XXXX.mp4 under ComfyUI/output/IAMCCS/MiniMaxH3/FAST_LATENT_2PASS/<render_id>/ and refuses to overwrite an existing segment - a deliberate anti-footgun so re-running doesn't silently corrupt a finished take.
• Writes segment metadata, and if queue_next_segment is on, enqueues the next segment's prompt automatically. That's how a whole multi-chunk film renders unattended.

Inputs that matter

The full sampling chain arrives by wire: model, clip, video_vae, audio_vae, sampled_latent, stage1_conditioning, plus the per-segment bookkeeping (cine_linx, native_frames, native_audio, resolved_render_id, native_saved_report, current_segment, total_segments, context_trim_frames, join_trim_frames). queue_next_segment (default true) is the auto-advance switch.

Optional continuity inputs: motion_state, bridge_frame, first_frame_override, last_frame_override, ref_image_1..4, ref_video, ref_video_audio, ref_audio. If you're keeping a character or style consistent through a long film, this is where the reference material enters the quality pass.

Outputs

• video_path - where the segment MP4 landed.
• report - what the pass did.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Plus MiniMax H3 support in ComfyUI, the minimax_h3_latent_upscaler_3d checkpoint in models/latent_upscale_models, and the streamed save path the pack vendors (ships with it). No separate downloads for the streamer.

Gotchas

• "segment already exists" → start a new render rather than overwriting. That guard has bitten people who re-ran a half-finished shot: bump the render ID, don't delete files to force a redo mid-chain.
• It's a per-segment output node with no IMAGE output - you don't preview from here, you wait for video_path. If you need to see frames, add a preview on the native stage-1 outputs instead.
• The native checkpoint must genuinely precede it; skipping the checkpoint node to "save time" fails validation on purpose.
• The streamed save needs working ffmpeg (the pack exposes one via imageio-ffmpeg at startup). If the log shows ffmpeg auto-expose failing, check your imageio-ffmpeg install before blaming the render.