Silver WAN HuMo Batch (N clips / encode once / sample once / decode once)

Read the README before you wire this one up, because the author says it plainly: SilverWanHuMoBatch has not been run end to end. The audio-conditioning path, the HuMo audio-embed wiring and the model-management assumptions are all unverified. That's unusual honesty and you should take it literally - treat this as a starting point that will probably need fixes, not a proven node.

What it's trying to do is genuinely useful, though. WAN HuMo is ByteDance's audio-conditioned human-video model - the thing people use for lip-synced talking heads and music-video shots from a single reference image. It's built on the Wan 2.1 stack (you'll find it as Wan2_1-HuMo-14B fp8 in Kijai's ComfyUI repackaging, with a Whisper-based audio encoder alongside it, and smaller community variants such as an RVC talking-head 1.3B). The important structural fact: HuMo does not generate audio. It consumes your audio as conditioning and renders lips and expression that follow it. So on this node guide_audio isn't optional flavour, it's the drive signal and the track you get back.

This node renders N such clips with the same staging trick as the pack's H3 nodes: text encoder, audio encoder, DiT and VAE each load once for the whole batch, so N clips cost about two model swaps instead of roughly 3 × N. No inter-clip continuity - these are independent takes that happen to share a voice track.

The inputs

guide_audio and audio_encoder are both required. The audio encoder is ComfyUI's Audio Encoder - normally you'd wire Load Audio Encoder plus Audio Encoder Encode into the native HuMo node; here both the encoder object and the audio go straight into this node, which encodes once and windows it per clip.

step_audio decides how that windowing works: OFF (default) locks every clip to the first clip-length window of audio, so all five clips reuse the opening four seconds. ON advances clip i to window [i*clip, (i+1)*clip]. It auto-enables whenever combine_videos is ON, on the logic that stitching implies a continuous take. If you leave step_audio off and wonder why every clip says the same sentence - that's why.

prompts is a STRING_LIST of one prompt per clip, overall_prompt is prepended to each, ref_image is the per-clip identity sheet (image i → clip i, single image reused, applied as the model's reference_latent). length is frames per clip - 97 is the HuMo default, about 4s at 24 fps - and cfg (7) guides the positive/negative pair. The rest is the familiar set: width, height, seed, steps, sampler_name, scheduler, seed_per_shot, save_video, filename_prefix, frame_rate and frame_compression.

Outputs: video_frames (a list of frame tensors, one per clip), audio (the guide-audio window each clip followed - sliced from your track, since HuMo emits none), saved_videos (newline-separated paths) and videos_rendered. Notice it emits video_frames rather than only saving; save_video can be turned off if you want to route the frames yourself.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/SilverAndJade/comfyui-silver-nodes

Then the real trap: this node imports get_audio_emb_window and linear_interpolation from comfy_extras.nodes_wan, and the pack's __init__.py imports every module at load time. On a ComfyUI old enough to not have the native HuMo node, that import fails and the whole pack disappears from your node list - including the H3 nodes you actually came for. If custom nodes raise an ImportError mentioning nodes_wan, update ComfyUI rather than reinstalling the pack. You'll also need the HuMo weights, a Wan 2.1 VAE, a Wan text encoder (umt5-xxl) and the Whisper audio encoder.

Where it bites

Since nothing here is validated, budget for debugging rather than blaming your wiring: check the console for the node's own traceback first, and be suspicious of the audio windowing arithmetic if clips come back with the wrong slice or silent. Compare against the stock HuMo node in ComfyUI - if the native node produces good lip-sync and this one doesn't, it's the packaging, not the model.

One expectation to set from the community, not the code: HuMo is a reference-to-video model, so it likes close-up portrait framing and it will happily re-plan the background. People driving it from a single still routinely report the scene changing around the subject no matter what the prompt says. Mask-and-composite is the usual workaround. As audio-driven avatars go, the field's default is still InfiniteTalk for speed, with HuMo's reputation resting on cleaner mouth and teeth detail; if this node fights you, the model is not the weak link.