H3 Video Outpaint · 读取已存候选 (EXP)

Chained video workflows have an unglamorous problem: the interesting state lives in memory during a run and on disk between runs. Restart ComfyUI - or just come back the next morning - and the candidate handle you were holding is gone.

MiniMaxH3VideoOutpaintLoadCandidateT8 is the way back in. Give it prepared, candidate_name and the candidate_id the Candidate node returned, and it reads the archived candidate PNG and preview record off disk. It does not sample, does not touch the VAE, and does not confirm anything on your behalf. The description spells all three out, which is the tell that the author has been burned by nodes that quietly regenerate.

The three inputs

• prepared - from Prepare or Load Prepared. This is the handle that carries the run root, which is how the node knows where to look. Same source, same plan parameters, same run_name, or the lookup fails.
• candidate_name - which attempt under that run, e.g. candidate_01. If you generated three candidates to compare, this picks one.
• candidate_id - the full 64-character identifier returned when the candidate was generated. Not a filename. Not a path. Copy all of it.

The three outputs

candidate is the same type the live Candidate node produces, so anything downstream that accepted a fresh candidate accepts a loaded one. That's the point - you can switch a graph from "generate a candidate" to "load the candidate I already have" by swapping one node.

first_frame is an IMAGE, previewed in the node, so you can look at it or feed a comparison. preview_report is JSON describing the archived preview.

Why you'd reach for it

Three real scenarios. First, comparison: generate several candidates, then load them one at a time and look at them side by side rather than re-running the sampler. Second, recovery: your machine restarted mid-review and you want the frame back. Third, resumption - load the candidate, wire it into the confirmation node, confirm, continue. Which is the cheap path for anyone whose session spans more than one sitting.

There's a guard worth knowing: the loaded handle goes through the same preview-contract validation as a live one. The archive has to be internally consistent or the node errors. That's why the ID matters so much - it's a key into a verified record, not a loose pointer at a file.

Install

Manager: search MiniMax H3 Audio T8, then restart ComfyUI fully. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

The pack's requirements.txt installs nothing on purpose so it can't replace ComfyUI's Torch, torchaudio, numpy, Pillow or safetensors. This node needs none of the heavy kit - no H3 weights, no VAE, no ffmpeg, no KJNodes - it reads a PNG and a JSON record from the ComfyUI output cache. That also makes it the fastest way to sanity-check that a run's cache survived whatever happened to your session.

Where people get it wrong

Copying a partial ID is the classic. The strings are long and easy to truncate in a terminal paste; you get a lookup failure, not a fuzzy match. The second one is subtler: the cache lives under the ComfyUI output directory, keyed by run_name plus a slice of the plan hash. If you've moved the output directory, or you're pointed at a different ComfyUI install, or you changed the source file, that run's cache isn't there. And a pack or core upgrade can invalidate caches by design - the identity check exists precisely so you don't continue a run under a different execution than the one it was sampled with. If it refuses after an update, regenerate rather than fight it.