IMTalker Video Driven

Where IMTalkerAudioDriven makes a face talk, this node makes a face move. IMTalkerVideoDriven takes a source portrait plus a batch of driving frames and transfers the motion from a driving video onto your source person - reenactment, the same family of trick LivePortrait does. No audio, no flow-matching generator, no seed or steps to fuss with: this is the simpler, sturdier half of the pack.

If what you actually want is lip-sync to a voice, reach for the audio-driven node instead. This one earns its keep when you have footage of someone performing - head turns, eyebrows, expression changes - and you want those exact moves performed by a different face. That's your video-to-video dubbing, or just animating a still portrait with a clip of natural motion.

How it works

Unlike the audio-driven path, this node never touches wav2vec or the generator. It's all renderer. The source image is encoded once for appearance (the renderer's app_encode yields the identity features). Then every driving frame is motion-encoded, adapted, and decoded, producing one reenacted frame per driving frame. Output count matches input count: give it 150 frames, get 150 frames.

Everything is normalized to the same 256×256 square the rest of the pack uses. With crop_face on (the default), both the source and each driving frame get cropped around the detected face first - the source uses the largest detected face, and a frame with no detectable face just passes through as a full-image resize. It won't invent a face that isn't there.

Inputs and output

• model_bundle - from IMTalkerLoader.
• source_image - the face that keeps its identity. One image.
• driving_images - a batch of frames that supply the motion. The natural source is VHS_LoadVideo (set its output format to AnimateDiff for a straight frame batch), which is exactly what the bundled workflow does.
• crop_face (default true) - face-crop both source and driving frames.

The output is a single IMAGE: silent 256×256 frames, same count as your driving input. Speed and sound are on you: VHS_VideoCombine at 25fps will re-encode the frames, and if your driving video had audio you can feed VHS_LoadVideo's audio output into the combiner to carry it through - the example workflow wires it that way.

Install

Identical to the rest of the pack. ComfyUI Manager, search "ComfyUI-TP-IMtalker", or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/tpc2233/ComfyUI-TP-IMtalker.git
cd ComfyUI-TP-IMtalker
pip install -r requirements.txt

Same shared reality as the other nodes: models auto-download to ComfyUI/models/imtalker on first run, and the README's tested ceiling is ~17GB VRAM. The example workflow additionally needs ComfyUI-VideoHelperSuite, which the pack does not install for you - grab it from Manager if you load the bundled graph and see missing nodes.

Common issues

• Nothing to tune. No seed, steps, or cfg here - if the result looks off, the inputs are the problem. You want a clear, well-lit source face and driving frames with clean, full-face motion. The face detector needs to see a face; the classic failure is a source image where FAN can't find one, leaving you with an uncropped, resized mess.
• Frame rate is on you. The node emits frames; if your driving clip was 30fps and you encode at 25, the motion looks slightly off-speed. Use VHS_LoadVideo's force_rate or select_every_nth to normalize before it reaches the node.
• It's the cheap one. No ODE integration per frame and no audio model, so this is the least GPU-hungry node in the pack - a nice change of pace from the audio-driven sibling.

For reenactment specifically, this is a solid, low-drama node: fewer knobs, fewer surprises, a clear job. The audio-driven node gets the attention, but if your use case is "put this face on that performance," this is the one you want.