LivePortrait Process

This is the node people actually search for when they mean "make my photo talk." LivePortraitProcess is the heart of the whole pack: it takes your source face, your driving frames, and the crop info from the cropper, and runs the actual LivePortrait inference - the motion extraction, warping, and generation that turns a still face into an animated one.

It's also the node that packs the most controls, and the ones that confuse beginners the most. None of them are scary once you know what each does.

The pipeline it sits in

The workflow is always: (Down)Load LivePortraitModels → LivePortraitLoad*Cropper → LivePortraitCropper → LivePortraitProcess → LivePortraitComposite. The cropper pre-computes the source face features and the crop geometry; Process consumes those plus the live_portrait_pipe and the driving images; Composite pastes the result back onto the full frame.

What the motion happens to

Mechanically it's classic LivePortrait: the motion extractor reads each driving frame's expression and head pose, those get composed onto the source identity (via the appearance feature extractor), then the warping module and SPADE decoder render the face. The interesting part is relative motion: instead of copying the driver's absolute pose, the pipeline computes the delta between the source face and the driving face - which is why the source can be a neutral photo and the driver can be off-angle, and it still works.

Inputs that matter

• source_image and driving_images - the still(s) and the motion frames. The number of driving images must be larger than the number of source images, or you get a hard error. Feed driving frames as an image batch (frames × H × W × 3), any resolution; the node resizes to 256 internally.
• relative_motion_mode - this is the control people fight over. relative (the default) is what you want for normal driving. source_video_smoothed plus driving_smooth_observation_variance is the vid2vid setup for cleaning up a jittery driving video. relative_rotation_only, single_frame, and off are for specific cases: rotation-only keeps everything but head rotation, off makes the head motion follow the driver absolutely.
• delta_multiplier - amplifies or damps the overall motion. 1 is faithful. 0 is a frozen face. Go to 1.2–1.5 if the animation reads too subtle; negative values invert expression (weird, occasionally funny, rarely useful).
• stitching (default on) - decides whether the animated face gets stitched back into the cropped frame context. Disable it if you want the raw generated head without the surrounding crop context (say, if you're doing your own compositing).
• mismatch_method - what to do when the driving video is longer than the source batch: constant holds the last source frame, cycle loops, mirror ping-pongs, cut uses the source frame at the same index. Only matters for multi-frame source video.
• lip_zero + lip_zero_threshold - suppresses lip motion below a threshold (useful for cleaning up micro mouth jitter on a talking head). Only actually does anything if you've also got retargeting on, and the node warns you if it's pointless.

Outputs

Two: cropped_image (the animated face, 512×512 per frame - this is what the composite pastes back) and output (LP_OUT, an internal dict carrying crop info, per-frame results, and the mismatch method). The second one looks useless until you realize it's the only thing LivePortraitComposite can eat.

Where people get burned

• Head ballooning. The old classic: the head pulses in scale like it's inflating. It's a crop/relative-motion problem. Use relative (or source_video_smoothed), keep the source crop stable, and ideally stabilize the driving video - Kijai's rework fixed most of this, and the community confirms the new relative modes handle it far better than the old builds did.
• Black or empty frames - a driving frame where the detector found no face gets skipped and padded with zeros, which then shows up as a black frame in the output. Keep the driver's face visible and in-frame the whole time.
• "Realtime" is a real thing but a limited one. The pack is genuinely fast - around 80–100ms per frame in ComfyUI - but that's per-frame pipeline latency in a node graph, not a live webcam app. If you want true realtime with camera input, Kijai himself says better standalone solutions exist.