MiniMax H3 Save
The last node of every H3 render — and why the pack wrote its own instead of using core's
- reel
MiniMax H3 Save is the last node of every render in this pack: the reel,
muxed into one file and written under output/. It's internal plumbing -
dev-only, emitted by the Creator or Timeline node automatically - so you'll
rarely, if ever, place it yourself. But it's the answer to two questions you'll
eventually ask: "where did my clip go?" and "why didn't the pack just use
ComfyUI's own SaveVideo?"
The where is easy. It writes to output/minimax/H3 (that's the filename_prefix
default) as an MP4, muxed from the parts the reel holds. Where the file lands on
disk - with %year%-style tokens and the MP4 quality - is a per-machine setting
under ComfyUI Settings → Folders, deliberately not part of the workflow.
The "why not core's node" is the interesting bit, and it's a real gotcha, not
pedantry. Core's SaveVideo takes a codec that's a dynamic combo - the
frontend assembles its value from a dynamic schema. A graph built in Python
(which is what the Creator emits) has no frontend, so nothing assembles it, and
the value arrives as a bare string the node then subscripts. The pack's own save
node avoids that entire class of bug by writing the container itself.
How it works
It takes a reel - a list of references - rather than one clip's tensors, and
mux.py writes it part by part. That's what stops a long timeline from ever
having to exist as one concatenated tensor first. Each part is read back a frame
at a time, conformed and re-encoded straight into the container, so a two-minute
piece never materialises as a two-minute blob of frames in memory. The same
mechanism is why the Reel node can be so cavalier about dropping tensors: the
passes live on disk, and this node reads them back at write time.
Writing the container itself also means the quality setting is always
honoured. Core's VideoFromComponents.save_to only learned crf in ComfyUI
0.29, so a quality setting used to have to be refused on older versions; the
pack's own muxer just uses it.
The inputs that matter
reel- the whole render, as the Reel node built it. Required, and the only thing that connects the render to its own output.fps- default 24, which is H3's native rate. You rarely touch it.filename_prefix- defaultminimax/H3. Change it if you want renders elsewhere underoutput/.crf- default 23 (range 0–51), the x264-style quality knob. Lower is better quality and bigger files. The README notes that changing quality and re-queueing re-writes the file - it's an input rather than a settings read so the output node isn't a cache hit that keeps the old quality.takes- optional. Which card each part of the reel is and what seed it ran on, or empty on a render with nothing to keep. This is what makes the padlock/"shoot one pass at a time" workflow work: each pass you keep is its own file undertakes/.
It's an output node with no outputs. The render reports the saved file against
the Creator or Timeline node you're actually looking at, rather than against
some expanded node on nobody's canvas - that's the set_override_display_id
trick, stamped by render.emit_tail.
Installing
Same as the rest of the pack: Manager, search "MiniMax Creator", or
cd ComfyUI/custom_nodes
git clone https://github.com/roadmaus/ComfyUI-MiniMax-Creator
Restart, no pip install, needs a ComfyUI with nodes_minimax_h3.py and the H3
weights in place. If you never lay eyes on this node, good - that means the
Creator is doing its job. But now you know where the output went, and why the
quality knob actually works.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| reel | MMC_REEL | — | |
| fps | FLOAT | 24.001–120 | — |
| filename_prefix | STRING | minimax/H3 | — |
| crf | INT | 230–51 | — |
| takesopt | STRING | — |
Outputs (0)
No outputs