Mpi Video Sampling Preview

If you've generated with MiniMax H3 and watched the sampling preview look like blocky colored static, that's not your settings and it's not the model - it's ComfyUI silently giving up. A video format like H3 names no taesd_decoder_name, so the previewer falls back to Latent2RGB, which turns an in-progress latent into the smeary color blobs you're seeing. The previews still appear; they're just useless. Mpi Video Sampling Preview is the fix: it decodes the in-progress latent through a tiny TAEHV decoder and streams real RGB frames to you while the sampler runs.

It's built as a model wrapper, which makes it easy to place. You drop it anywhere on the model wire before the sampler - it clones your model, patches in a preview hook, and passes the model through untouched, so the only thing you wire onward is the model output into your KSampler. Three inputs:

• model (MODEL) - the video model, straight from its loader.
• vae (VAE) - this is not the model's real VAE. It's the tiny TAEHV preview decoder, taeh3 for MiniMax H3. The tooltip is blunt: hand over the full VAE and it decodes at full cost every step and will crawl. Feed it the tiny one.
• preview_rate (FLOAT, default 8) - playback speed in frames per second for the preview clip. It paces playback, not cost.

Here's the part that makes this node more than "decode a latent every step." A TAEHV is temporal: its MemBlocks chain state forward, so frame N is only correct if every frame before it was decoded in the same pass. You cannot cheaply decode a window out of the middle - it comes out as garbage. So every sampler step decodes the whole clip from frame 0 and bursts it. That also means you're not watching one still per step; the clip plays back at its own speed, announced via a VHS_latentpreview marker on the standard binary preview channel, which is exactly what a host app driving ComfyUI over the websocket already consumes. (Node-widget previewers like KJNodes' ModelPreviewOverride base64 onto a private event only the ComfyUI web UI can see - same idea, wrong road for anything headless.) H3's real chunking is honored too - 17 pixel frames per 5 latent tokens, each chunk's prefix trimmed and the encoder's tail pad dropped - so the frame count and timing come out exact, bit-identical against KJNodes' TAEHVDecoder on the same weight. And H3's packed audio+video latent is handled: it previews the video half and leaves audio alone.

The catch you need to know about before it bites: a plain VAELoader cannot build taeh3. ComfyUI sizes a TAEHV's edge convolutions from the latent channel count and has no case for H3's 24-channel latent with a 12-wide decoder, so it raises size mismatch for decoder.22.bias: [12] vs [3]. You load it with the companion Mpi Tiny Vae Loader node in the same pack, which rebuilds the two edge convs at the right width. You also need the taeh3 weight itself in ComfyUI/models/vae (it's madebyollin's TAEHV tiny decoder - a ~22 MB file).

Install - it ships in ComfyUi-MpiNodes. ComfyUI Manager → search "ComfyUi-MpiNodes" → Install, restart, then grab taeh3.safetensors into models/vae. Manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

No pip requirements, but it leans on ComfyUI's newer patcher_extension API, so keep ComfyUI reasonably up to date.

Troubleshooting, in order of likelihood: still seeing blobs means the tiny VAE isn't wired in (or wasn't loaded via Mpi Tiny Vae Loader). A crawl means you handed it the full H3 VAE instead of the tiny decoder - swap it. Green/artifact frames mean a non-temporal decode path - this node shouldn't do that, but if you've patched your decoder, that's your culprit. And a preview failure is caught, reported once to the console, and the generation continues - the preview vanishing is not the run failing. This is the node that makes H3 actually watchable while it cooks, and it was the specific pain people hit with H3 previews from day one.