MiniMax H3 Preview Override

Here's the thing about H3 renders: they take minutes, and stock ComfyUI shows you a still image the whole time. Core's Latent2RGBPreviewer renders x0[0, :, 0] - the first latent frame only - so you watch a frozen frame while a five-second shot samples. MiniMax H3 Preview Override fixes exactly that: it sits between the Director's model output and the sampler and renders the whole shot as it denoises, on the node.

Why does H3 even need a dedicated node? Two reasons, both mechanical. H3's latent is packed - video and audio live in one flat tensor, which has to be unpacked before anything can be drawn from it, and the LTX preview nodes don't do that. And H3 compresses time about 3.35×: a 124-frame (5 s) shot is only 37 latent frames, so playing those at 24 fps runs the preview three times too fast unless the rate is corrected.

How it works

The node attaches a callback to the sampler, unpacks the flat pack with core's unpack_latents, and renders frames one of two ways. latent2rgb (fast) is a single matmul - effectively free, rough colors, ~10 ms per frame. vae (quality) runs the real video VAE - true colors, and at 1344×768 it can cost 20–25 s per preview, because the 5 GB decoder expands 37 latent frames into 124 output frames. The result is animated WebP sent to the browser. The render 9.9s line in the status is server-side decode/scale/encode time, not the sampler's.

The knobs that matter

• decode - latent2rgb (fast) for iteration, vae (quality) when you need to judge actual detail or verify a VAE problem.
• preview_frames - how many frames of the shot to show, thinned evenly so it caps cost without cropping the timeline. This is the main cost knob; try 4–8 with VAE.
• preview_fps - a FLOAT, so the Director's fps output wires straight in (it's always 24 for H3).
• playback - true speed (default) spreads the sampled frames across the shot's real duration, so the preview lasts exactly as long as the finished clip. source fps plays them flat at preview_fps, motion at normal speed but the clip ends early.
• every_n_steps and max_preview_overhead - the throttle pair. every_n_steps never previews more often than every N steps; max_preview_overhead (default 25%) paces previews so they can't eat more than a quarter of the render time. 0 disables it.
• max_resolution - long edge of the preview image. latent2rgb frames arrive at latent size (a 1344×768 shot is an 84×48 grid), so this upscales them smoothly - smooth, but soft.
• preview_target - node shows it on this node (always available); sampler (VHS) puts it in the sampler's usual preview slot and needs VideoHelperSuite installed; both does both.
• suppress_default_preview - hides ComfyUI's built-in single-frame preview while this runs.

Output is a single MODEL with the preview attached, which you pass on to the guider as if the node weren't there.

The badge that reads "4.7fps of 24" is not broken

With true speed, the rate is derived, not set. There's one image per latent frame and H3 compresses time ~3.35×, so the rate physically can't pass preview_fps / 3.35 - measured, ~7 fps at 24. Other packs show a round 24 because they play the same frames without correcting for the compression, which runs the preview 3.35× too fast. Switch to source fps if that's the trade you want.

Installing and gotchas

Same pack, same install as the Director - ComfyUI Manager search MiniMax H3 Director, or git clone, no pip deps. Nothing special to configure unless you want the VHS sampler slot, which needs ComfyUI-VideoHelperSuite.

The vae input is only needed for vae (quality) mode. And don't go hunting for a small preview VAE like LTX 2.3's: MiniMax hasn't released a TAESD-style decoder for H3 (taesd_decoder_name is None), so fast-RGB vs full-VAE is the whole menu. The one thing to actually remember: a VAE preview allocates as much memory as a real decode, so if you're near your VRAM limit, lower preview_frames before you switch to vae (quality).