H3 Video Outpaint · 恢复已确认候选 (EXP)

Between "I approved this first frame" and "the video is finished" there's a lot of wall-clock time. Sessions end. Machines reboot. Power goes out. MiniMaxH3VideoOutpaintLoadSelectionT8 is how you pick that thread back up: hand it the selection_id you saved when you confirmed, and it returns the selected handle that the Continue node needs.

It's a deliberately boring node, and that's the recommendation. Its description promises two things: it reads the original candidate plus the confirmation record, and it will not generate anything or change your selection on its own.

Inputs

prepared, candidate_name, selection_id. Once you understand that prepared carries the run's cache root, the rest is just addressing: which run, which candidate under it, which confirmation of that candidate. The selection_id is a full 64-character string - the same "copy all of it, it's not a path" rule as everywhere else in this family.

Outputs

selected - the same type the confirmation node emits, so it drops straight into MiniMaxH3VideoOutpaintContinueCandidateT8 and resumes the run under the frozen settings from the moment of approval. first_frame, an IMAGE for a quick "yes, that's the one" glance. selection_report, JSON containing the selection ID, the underlying candidate ID, and the selection record itself.

Why the archive matters more than the node

The confirmation archive is the contract. It carries the approved preview's RGB hash, the colour settings, the geometry settings and the decode mode - everything the later stages need to reproduce exactly what you signed off on, and nothing they can override. That's why the composing node can refuse to publish when the recomposed first frame drifts from your approved one.

Loading by ID is therefore not a convenience feature so much as a correctness feature: it's the only supported way to get back to a verified state, because it re-reads the verified record. Rebuilding "the same" settings by hand in the UI gets you a graph that looks right and a hash that doesn't match.

When to use it vs the other loaders

• You want to look at a candidate again, or confirm one you generated earlier: Load Candidate.
• You confirmed it, and you need to finish the video: Load Selection (this node).
• Sampling finished but the file save failed or crashed: Load Completed Selection, which skips the model entirely.

Getting these three confused is the most common way to waste a re-run. The selection loader is the one that leads back into generation.

Install

Manager: search MiniMax H3 Audio T8 and restart ComfyUI completely. Manual:

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

No pip packages - requirements.txt in this pack is empty on purpose so an install can't replace the Torch/CUDA stack ComfyUI is running on. This node loads no model, no VAE and no media; it's a disk lookup plus validation. That makes it one of the few nodes here you can run on a machine that isn't the one that did the generation - provided the cache directory is in the same place.

What breaks it

Three things, all of them identity-related. A different candidate_name than the one the selection came from - the archive lives under the candidate it belongs to. A run_name mismatch, since the cache root is derived from the run name plus part of the plan hash. And an upgrade to ComfyUI core, KJNodes or the pack itself, which can legitimately change the execution identity and invalidate a cache that was valid yesterday. The docs are direct about this: after an update, don't expect to skip the identity check, and don't try to edit the record to get around it. The results and old caches are meant to be kept, not resurrected under new code.