ComfyUI Node

MiniMax H3 Save

The last node of every H3 render — and why the pack wrote its own instead of using core's

By roadmaus·Created 17 days ago·Updated about 19 hours ago· 58
MiniMax H3 Save
  • reel
    fps24.00
    filename_prefixminimax/H3
    crf23
    takes

    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 - default minimax/H3. Change it if you want renders elsewhere under output/.
    • 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 under takes/.

    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.

    CategoryMiniMax/internal

    Inputs (5)

    NameTypeDefaultDescription
    reelMMC_REEL
    fpsFLOAT24.001–120
    filename_prefixSTRINGminimax/H3
    crfINT230–51
    takesoptSTRING

    Outputs (0)

    No outputs