MiniMax H3 Clip

---

Every node in this pack's render chain decodes, trims, or spills pixels. MiniMax H3 Clip Reel is the exception: it adds supplied footage to the reel as a file, without decoding it at all. If you attach a real clip to your H3 timeline, this is the node that makes it part of the finished video.

The reason it exists is pure arithmetic. The finished video is written frame by frame, so a clip card only has to be named here - the pack's mux.py demuxes, conforms and re-encodes the file straight into the container at write time. Two minutes of 768p footage would be around 35 GB as a tensor held in memory. As a dict - a path and a reference - it's nothing. The whole pack's memory strategy is "never hold a decoded pass across a node boundary," and this node takes that to its logical extreme: don't hold the decoded frames at all, because you never needed them.

It's the clip-side counterpart to the memory trick in MiniMaxH3Reel. The reel node decodes a generated pass, writes it to disk, and drops the tensors so peak memory stays at one pass. This node handles the supplied side without even touching the pixels. Both exist to keep a long timeline from ever existing as one giant blob of frames in RAM.

The inputs that matter

• clip_data - the JSON blob describing the supplied clip: its file, kind, and what it contributes. Same format the rail's clip cards carry.
• reel - optional. The passes and clips in front of this one; absent on the first item. This is the pack's MMC_REEL type, so you're not wiring it to stock nodes.
• audio_vae - optional, and its purpose is delightfully specific. It's taken as an input for exactly one number: the sample rate its decoder outputs at. That's the rate the generated passes' sound arrives at, so it's the rate this clip's soundtrack has to be resampled to. It's a fact about the weights on your disk, not a constant the pack may assume.

Output is the reel - the running list of parts, with this clip appended.

What it doesn't do

It doesn't decode the clip, and that's a feature. The frames are only ever pulled out on demand - and that demand only exists if something actually needs a keyframe, which is what MiniMaxH3ClipFrames and MiniMaxH3ClipAudio handle when a seam sits beside the clip. A clip that nothing continues from is never decoded at all. That's why the seam helpers are separate nodes rather than outputs of this one: making them outputs would force a decode of every attached clip, whether anything needed it or not.

Installing

Internal, dev-only, ships with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/roadmaus/ComfyUI-MiniMax-Creator

Restart ComfyUI, no pip install, standard H3 weights. You won't place it by hand - the Creator does - but it's worth knowing about, because it's the answer to the obvious question "how does a two-minute clip I attached end up in a render without exploding my RAM?" The answer is that it never becomes video in memory at all.