H3 · Save Continuation Master

ComfyUI's native Save Video gives you H.264 or AV1. Both are delivery codecs: they throw away colour precision, they subsample chroma, and they introduce generation loss the moment you use the file as an input to anything.

That's fine for a final MP4 and wrong for continuation state. H3's history frames are the context the next window is conditioned on, so re-encoding them before they go back in means every continuation inherits a slightly degraded boundary. H3 · Save Continuation Master exists to avoid that: it writes 16-bit RGB FFV1 in an MKV, at 24 fps, losslessly.

How it works

It pipes raw rgb48le frames into ffmpeg at the source resolution and lets it encode FFV1 level 3 with gbrp16le output. Lossless, 16-bit per channel, no chroma subsampling - mathematically the same frames you handed it. The pack's CPU evidence claims every encoded sample round-trips, and that's the standard FFV1 gives you when you get the pixel format right.

The default filename_prefix is h3-relay/history, so files land in an h3-relay subfolder under output/. The node uses ComfyUI's usual save-path machinery (the same counter/subfolder logic as Save Image), then appends _history.mkv, and returns a JSON descriptor as a STRING: filename, subfolder, pixel_format: rgb48le, frame count, fps, and a SHA-256 of the finished file. It also publishes that descriptor to the UI.

The SHA-256 is the point of the descriptor, by the way. Continuation artifacts are the kind of thing you want to be able to identify without trusting a filename, and a hash lets you assert "this is the same master" across machines and sessions.

Where it goes, and what it's for

It's an output node - nothing wires out of it except the descriptor string, which you can ignore or preview. You wire frames in from wherever your accepted shot comes out: Append Window's state, Finish Windows' output, or the staged Assemble path.

The intended use is independent segment jobs: instead of one monolithic prompt that renders an entire sequence, you render a window, accept it, save its frames here, and let the next job pick them up with Load Continuation History. That's the pattern that keeps RAM bounded by one active shot instead of growing with the clip.

One honest caveat: this file holds frames, not audio. If you're resuming a chain you'll need the audio side too, and the pack's staged cache path handles audio + video together in a way this adapter doesn't. For a quick "keep these boundary frames for later", this is the tool; for a resumable production chain, use the cache the pack already maintains.

Install

Manager → H3 Relay → restart, or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

Two real requirements. ffmpeg on PATH - this node shells out and does not fall back to an in-process encoder - and enough output/ space, because 16-bit lossless video is not small. A 1664×960 window at 225 frames is comfortably into the gigabytes; a "why is my disk full" thread starts with files like these.

No pip packages. ComfyUI 0.37.0+. And the models that made those frames are under the MiniMax H3 Community Licence, whose territory excludes the US, EU, UK and South Korea, outputs included.

Where people get burned

Continuation master encoding failed is the error you get when ffmpeg exits nonzero, and it's almost always one of two things: ffmpeg isn't installed (a FileNotFoundError that reads like a node bug and isn't), or the output path already exists - the encoder is run with -n, so it refuses to overwrite. Two runs with the same prefix get different counters, so the honest cause is usually a permissions problem on the output directory rather than a genuine collision.

The other one is a quiet quality trap: if you feed this node frames that already went through an H.264 round trip, you get a perfect lossless copy of degraded frames. The master has to be captured before the delivery encode, not after. Save the master from the decoded window, then let a native Save Video make the MP4 you actually show people.