MiniMax H3 Clip Frames

---

Chained H3 pieces don't only join generated shots to generated shots. Sometimes the thing in the middle of your timeline is a clip you supplied - real footage you attached to the rail. A seam beside that clip still needs a keyframe, and that's what MiniMax H3 Clip Frames is for: the first or last frames of a supplied clip, pulled out so a generated shot can continue from them.

It's the clip-side counterpart to MiniMaxH3PassFrames, and the two differ in one crucial way. A generated pass has a spill - it was decoded, written to disk, and can be read back by reference. A supplied clip was never generated, so it has no spill to read back. This node decodes what it needs on demand, straight from the clip's file.

The design reason it exists as its own node rather than an output of the clip's reel node is worth knowing, because it's a genuine laziness win: a clip that nothing continues from is never decoded at all. MiniMaxH3ClipReel adds the clip to the finished video as a file reference without ever decoding it; only if a neighbouring generation actually needs a keyframe does this node open the file and pull frames out. What gets decoded is just the seam's width

• one frame, or a feathered run of up to 39 - not the whole clip. That's the difference between reading a few frames and transcode-dragging a two-minute file through your VRAM.

The inputs that matter

• clip_data - the JSON blob describing the supplied clip (its file, its kind). Same blob format the rail's clip cards carry.
• count - default 1, up to 64. How many frames the seam inherits. A feathered blend takes a run; a straight cut takes one.
• at - tail or head, default tail. The tail is what a generation after the clip continues from; the head is what a generation before it ends on. Easy to get backwards, so it's worth checking which side of the clip your seam sits on.

Output is an IMAGE - the frames the neighbouring shot continues from or runs into, feeding the segment's prev_image / next_image inputs in the graph the Creator builds.

Its siblings

MiniMaxH3ClipAudio is the same idea for sound - the clip's opening or closing seconds, so the neighbouring shot's audio can run into or out of the footage. And the MiniMaxH3PassFrames / MiniMaxH3PassAudio pair handle the equivalent for generated passes instead of supplied clips. The whole family exists so the Creator's "chained" mode can hand each seam its context without anyone having to think about where frames come from.

Installing

Ships with the pack, dev-only:

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

Restart ComfyUI, no pip install, standard H3 weights. You'll see this node in the wild if you expand a Creator workflow that has a supplied clip sitting in the middle of a chained timeline - and now you know why it's there: it's how a real clip you attached becomes part of the same continuous world as the generated shots around it.