Mpi H3 Masked Prefix

You've got a MiniMax H3 clip where the opening is exactly right and the tail isn't. The usual way to extend an H3 video is keyframe or guide conditioning: the model reinterprets everything and re-renders the whole clip, and you hope it keeps what worked. MpiH3MaskedPrefix is the other route, and it's sharper. It takes the prior clip's encoded tail, writes it into the front of a new, longer target latent, and masks that region out of sampling - the model generates only what comes after the seam. Nothing is regenerated, and nothing has to be trimmed afterwards.

How well the head survives is the number to care about, and it's a good one: the preserved frames measure at PSNR 38 dB against the source. That's a VAE round trip, not a re-render - effectively the original pixels back.

H3 makes this harder than it looks, which is why the node fusses about frame counts. Video lengths sit on a 17k+5 grid at 24 fps, and the audio runs on its own 40 Hz latent clock. A context length that lands on one grid but not the other drifts the audio against the picture and starts the continuation from a moment that never happened - silently. So context_frames is snapped down to the only lengths that hit both clocks: 39, 90, 141, 192…, every +51. 39 frames is 1.625 s, which is exactly 65 audio steps. The snap is reported rather than assumed, so you always know what got kept.

The inputs that matter

• latent - the TARGET AV latent at the full output length, straight from MiniMaxH3ImageToVideo, MiniMaxH3ReferenceToVideo, or EmptyMiniMaxH3LatentAV. Its canvas must match the context clip's; a mismatch raises rather than silently stretching.
• context_latent - the prior clip as an AV latent. This is where MpiH3EncodeAV earns its keep: encode the whole context run in one VAE call - frame-by-frame encoding throws away the motion the temporal packing carries.
• context_frames - how much of the prior clip to keep, in frames at 24 fps. Default 39.

Four outputs: latent (feed the H3 sampler), context_frames and new_frames (the snapped keep-length and what you're left to generate), and report, a string that tells you exactly what happened - wire it to a display node once.

The failure modes you'll actually hit

Two raises are by design. If the prior clip's frame count is off H3's 17k+5 grid, its VAE packing phase is shifted and no tail of it lands on a legal context length - the node tells you to trim the source to 17k+5 frames (39, 56, 73, …) before encoding it. Too short for the 39-frame minimum, and it says so instead of picking a near-miss. Both error messages read like they were written by someone who's hit them at 2 am.

Two workflow notes from the author are the kind of hard-won lessons you only get from shipping this: don't put a first-frame guide inside the preserved head - it fights the prefix that already owns those frames. And a clean prefix is not an anchor: on its own the model preserves the frames and then renders an unrelated scene, so pair it with a single frame-0 MiniMaxH3AddGuide. A known open defect worth knowing about: the tail carries a sparkle artifact that a zero-content prefix does NOT produce, so it comes from the written content rather than the mask.

Installing it

This is one node in Mad Pony Interactive's ComfyUi-MpiNodes pack - over a hundred utilities, AGPL-3.0 since 1.2.7 - and it installs the same way regardless of which Mpi node you're after. ComfyUI Manager: search "ComfyUi-MpiNodes" and hit install. Or do it by hand:

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

Restart ComfyUI and you're done - the pack ships no requirements.txt, so there's no pip step. torchaudio is imported lazily only when an H3 node actually runs, and ComfyUI's own audio nodes already depend on it, so on a normal H3-capable install you never think about it.

None of the Mpi H3 nodes download models. You need the H3 weights (~42.5 GB, from MiniMaxAI/MiniMax-H3) plus the H3 video VAE and audio VAE sitting on the usual ComfyUI model paths. Worth a pause before you pull them: the H3 Community License excludes the US, EU, UK and South Korea from its Applicable Territory - running the local weights there isn't licensed, and the hosted Hailuo API is the legal route in those regions.