MiniMax H3 Reel
The node that spills passes to disk
- samples
- vae
- audio_vae
- reel
- reel
- pass
This is one of the MiniMax/internal nodes, so a word up front: you almost never add it from the menu. The Creator and Timeline nodes write it into the graph when they expand. Your job is just to understand why it's there, because it's the difference between a long H3 render finishing and the OOM killer politely stopping by.
MiniMax H3 Reel decodes one pass of a multi-shot render, trims it, writes it to disk, and hands it on to the next link in the chain. It's the node that makes "one minute of 768p video" runnable on the kind of hardware a home user actually owns.
The problem it solves
ComfyUI keeps every node's output alive for the whole execution. A decoded pass is huge - a 768p frame is ~12 MB of float32, so a ten-second pass is on the order of 3 GB. Render five passes and the old approach held all five, plus the running totals, at once: the pack's docs quote ~81 GB of intermediates for ten 768p passes on top of the 15 GB of passes themselves. That's a render, or a crash, depending on your RAM.
So this node decodes, trims, and writes each pass straight out to a spill file as 8-bit frames, then returns only a path and a frame count. The tensors never leave the node call. Peak memory becomes the largest single pass instead of the sum of all of them, and it stops growing no matter how long the piece gets. The sound is kept as float32 in the spill - it's three orders of magnitude smaller, and a re-encode would audibly cost it.
The inputs and outputs that matter
samples- the sampled H3 AV latent for this pass. The node feeds it to core's ownVAEDecodeandvae_decode_audio, so the decode contract is ComfyUI's, not a second opinion.vaeandaudio_vae- both required; H3 samples picture and sound as a pair.head/tail- optional blend trim counts. If a pass shares a feathered run with the one in front of it (head) or runs into a supplied clip (tail), those frames are trimmed so the blend isn't played twice.reel- optional input carrying the passes in front of this one. Absent on the first.
It outputs reel (the growing MMC_REEL list of pass references) and pass (the MMC_PASS handle to this decoded pass on disk). The pass handle is what the seam nodes - Pass Frames, Pass Audio - read back from the spill.
The chaining trick
Each Reel node takes the one before it, so the chain stays an ordinary graph edge with no variadic inputs, and a pass's cache key names exactly the passes in front of it. Re-queue a render and the cached earlier passes replay from their spill files instead of being sampled again. The spill lives under ComfyUI's temp directory (core wipes it on startup) with a 12-hour keep-from-last-read window, so a server left up for days cleans up after itself.
Install is the pack install: Manager → search "H3 Creator Palette", or clone the repo into custom_nodes/, restart, hard-refresh. If you ever see this node complaining about trimming head + tail frames off a pass too short to hold them, the graph was built against arithmetic different from the pass that's actually in front of it - that's a workflow-update artifact, not a setting you broke. Drop the pass, re-queue, move on.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| samples | LATENT | — | |
| vae | VAE | — | |
| audio_vae | VAE | — | |
| headopt | INT | 00–64 | — |
| tailopt | INT | 00–64 | — |
| reelopt | MMC_REEL | The passes in front of this one. Absent on the first. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| reel | MMC_REEL | — |
| pass | MMC_PASS | — |