Nodes/ComfyUI-Continuity/Continuity Save
ComfyUI Node

Continuity Save

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

By roadmaus·Created 2 months ago·Updated a day ago· 128
Continuity Save
  • reel
  • done
◄fps24.00►
◄filename_prefixcontinuity/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.

CategoryContinuity/internal

Inputs (5)

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

Outputs (1)

NameTypeDescription
doneBOOLEAN—