H3 Video Outpaint · 读取已完成选择 (EXP)

Every long-video workflow has this moment. Twenty-two windows sampled over two hours, then ComfyUI falls over during the save, or your machine reboots, and the graph you have in front of you wants to start from window one again.

MiniMaxH3VideoOutpaintLoadCompletedSelectionT8 exists for exactly that. It reads a confirmed selection whose windows are all committed, and hands you a sampled handle you can wire straight into the composing node. No H3 model load. No sampling. No VAE encode pass beyond the delivery decode. The pack even ships a dedicated 05_Save_Completed_Selection workflow for it, and the README calls out the case in one line: if the whole clip already sampled but the final save failed, use it.

What it demands

Inputs are prepared, candidate_name and selection_id - so it needs the same confirmed state as the selection loader, plus the stronger requirement that the sampling actually finished. The check is unforgiving on purpose. It counts the committed windows against the number of windows the plan expects, and if they don't match, or the store's status isn't sampled, you get:

所选候选尚未完成全部窗口；请先使用接续节点完成生成。

Short version: this is a save path, not a resume path. If you're two windows short, use the Continue node, not this one. That's a real fork in the road - reach for the wrong node and you'll conclude the rescue doesn't work.

Outputs

sampled is the important one, feeding MiniMaxH3VideoOutpaintComposeCandidateT8 where the decode, source-mode handling, color match and audio mux all happen. first_frame gives you a visual confirmation you're looking at the run you think you are. completed_report is JSON with the window count, the candidate ID, the selection ID, sampling_called: false, and the preview hash - that last pair being the receipt that this path genuinely didn't re-generate anything.

Why the receipt matters

A rescue node that quietly re-samples is worse than no rescue node, because you won't find out until the GPU has been busy for an hour. So this one records sampling_called: false in its own report and loads no model at all - you can see it in the process list, too. Same discipline the pack applies everywhere: the loaders load, the samplers sample, and the reports say which one ran.

Note what it does not relax: the composing node still re-verifies the first frame's RGB hash against the preview you approved. Recovery restores your ability to finish the video; it doesn't let you change what the video is.

Install

Manager: search MiniMax H3 Audio T8, then restart ComfyUI completely. 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 is empty by design - base nodes take torch, torchaudio, numpy, Pillow and safetensors from your ComfyUI install, and the optional features check their own dependencies only when used. This node itself needs the ComfyUI output cache directory, the H3 video VAE for the downstream compose, and ffmpeg on PATH for the encode. It does not need the H3 base model, the text encoder or KJNodes, because it never samples. On a big run that's the difference between finishing in minutes and starting over.

The one thing that will still bite you

Cache identity. The selection record is bound to the source file, the model, the ComfyUI core version, the KJNodes version and the sampling implementation. If you've updated any of those since the run, the load can legitimately refuse - and the pack's guidance is not to hack around the check but to keep the old results and accept that the cache belongs to the older execution. Do the update after you've delivered, not in the middle.