OmniHuman-1

You have a photo of a person and an audio clip, and you want the person to say it. That's OmniHuman-1: ByteDance's portrait-to-video model, and in this pack it's one node - feed it one or more reference images plus an audio file, and it animates the person talking, gesturing, and moving in sync with the audio. No local GPU, no model download, no rigging. The catch, and it's the big one: it's a closed ByteDance model running on Runware's cloud, so this is a pay-per-run deal, not a "set it and forget it" local workflow.

How it works

OmniHuman-1 is an audio-driven human animation model - the audio is the puppeteer, and it conditions facial expression, lip movement, and body motion on that signal. The node sends your reference image(s) and the audio file up to Runware, the model animates, and the result comes back as a native VIDEO. It's genuinely impressive for talking-head content, and it's the kind of thing that would normally have you renting GPU hours to run locally.

The inputs that matter

Only two are required:

• referenceImages (IMAGE) - one or more images of the person. This is your identity anchor; give it a clear, well-lit, front-facing shot of the face. More images can help, but one good one beats three blurry ones.
• audio (STRING) - the audio that drives the animation, as a UUID or URL. This is the source of the performance, so the quality of the clip sets the ceiling on the result - clean audio, one voice, decent bitrate.

From there the useful knobs:

• numberResults (1–4) - how many variations to generate. Each uses a different seed, so this is your cheap way to hedge on which take lands the expression right.
• outputFormat (MP4 / WEBM / MOV) and outputQuality (20–99) - delivery format and compression. Defaults are sensible; drop quality if you're iterating.
• safety - a toggle that gates safety.checkContent and safety.mode (none / fast / full). Off means the model's default; if you turn it on, full runs a real content check and the node's title bar will report the result (e.g. NSFW: no). Human animation is exactly the kind of model where a content check is worth leaving on if your workflow is shared.
• ttl - time-to-live toggle for generated content, only relevant when output is served as a URL. Leave it alone unless you're deep in the API weeds.

Wiring it up

The video output is a native VIDEO, so it plugs into whatever video preview/save node your ComfyUI build has. You'll typically source the reference image from another part of your graph (an image generation node, a loaded photo, a prior run) and the audio from a URL or an uploaded file's UUID.

Install and setup

Standard pack install: ComfyUI Manager → search "Runware" → install → restart, or clone plus pip install -r ComfyUI-Runware/requirements.txt (runware-sdk, pillow, soundfile - light). You'll need a Runware API key (Settings → Runware API key, RUNWARE_API_KEY, or runware auth login) and funded credits; the recurring community complaint is the ~$20 minimum top-up with a card on file. Video inference is pricier than image runs - the node's title bar shows each run's cost, so you'll see it immediately.

Troubleshooting

• Video comes back as a file path, not a VIDEO socket - older ComfyUI builds lack the VideoFromFile class, and the pack degrades to saving the file to your output folder. Check there; the clip exists, it's just not wrapped.
• The face drifts or the mouth doesn't sync - the reference image and the audio quality are the levers. Better reference, cleaner audio, and let numberResults do the hedging.
• Rejected at the safety gate - if safety.mode is full and content flags, either adjust the content or drop the mode to none if your material is clearly fine.

It's one node doing a job that used to require a dedicated avatar pipeline. The price of entry is the credits and a good audio clip - the animation itself is Runware's problem, not yours.