Stack_WanHuMoImageToVideo

HuMo is ByteDance's 17B audio-to-talking model, and it's the same research group behind the Wan Phantom subject-to-video model - you can tell from the shared branding on their project pages. It made a real splash when it launched: the community's read on it was that it beat both Wan's own official S2V model and InfiniteTalk specifically on facial emotion and lip-sync accuracy, with one early tester noting "only 1 out of like 10 generations would be decent enough for the bad lip sync to not be noticeable at a glance" on the older options, versus HuMo landing much closer to right consistently. Stack_WanHuMoImageToVideo is Apt_Preset's config node for driving it.

How it works. ref_image is your identity anchor - the person you want speaking or performing in the output. audio_encoder_output is the audio conditioning, and note that it's a typed input, not a raw audio file: you need an audio encoder node upstream (outside this pack) to turn a raw audio clip into the embeddings this node expects before you can wire it in. width, height, and length set output dimensions, with length defaulting to 97 frames - noticeably longer than most other Wan nodes in this pack (which mostly sit at 77-81), likely because talking/singing content benefits from a slightly longer default clip than a general motion shot does. Output is HuMoImage, a config bundle for a downstream sampler.

Installing it. No extra dependency for this node in the base pack: cd ComfyUI/custom_nodes && git clone https://github.com/cardenluo/ComfyUI-Apt_Preset, restart, or search "ComfyUI-Apt_Preset" in ComfyUI Manager. What you genuinely need beyond that: the HuMo checkpoint itself (ByteDance's release, downloaded separately - this pack doesn't bundle model weights), and an audio encoder node upstream to actually produce a valid audio_encoder_output. Since HuMo is a large model at 17B parameters, budget accordingly on VRAM compared to the smaller Wan variants in this same pack.

Common issues. If lip movement doesn't track your audio at all, the first thing to check is whether audio_encoder_output is genuinely wired from a working audio encoder and not left disconnected - since this input is optional at the schema level, it's easy to forget it and get a silent generation that just doesn't move its mouth in sync with anything. Facial emotion coming out flatter or less expressive than examples you've seen is often a reference-image issue rather than a settings one - a neutral, low-expression reference gives the model less to extrapolate from than a reference already showing some animation in the face. And because this is a 17B model, an out-of-memory error is more likely here than on the lighter Wan I2V nodes in this pack - lowering resolution or frame count before assuming something's misconfigured is the first move, same as with any large video model that's simply too big for the card you're running it on.