Kling 2.6 motion-control

Motion control is the node that takes a still of a character and a video of somebody moving, and produces your character doing that movement. Dance transfer, basically - the vendor's own default prompt is "The cartoon character is dancing." Locally this is a Wan Animate / VACE-class problem; here it's a paid call with four required inputs.

The four required inputs

input_urls is the character image as an IMAGE socket. KIE's docs are picky about it: the photo must clearly show the subject's head, shoulders and torso, at least 300px with an aspect ratio between 2:5 and 5:2, JPEG/PNG/JPG up to 10MB. The documentation describes it as an array holding a single image - so don't wire a batch in and expect anything sensible. And take the framing note seriously: a full-body shot of a distant figure is the wrong input, and a tight face crop is the wrong input too.

video_1, video_2 and video_3 are the driver clips, as numbered VIDEO sockets. The docs describe one video URL (3–30 seconds, MP4 or QuickTime, up to 100MB) that clearly shows the subject's head, shoulders and torso. The pack turns a plural URL array into three numbered sockets so you don't have to paste JSON - but the endpoint documents one, so feed video_1 and leave the other two empty unless the API tells you otherwise.

mode is 720p (default) or 1080p. Its help text is stale - it talks about std and pro, which are the older Kling naming for 720p and 1080p. The dropdown is what you actually pick from.

character_orientation is the setting people get wrong, and the tooltip spells out why: image keeps the character in the orientation of your photo and is limited to 10 seconds of video; video follows the orientation of the characters in the driver video and allows up to 30 seconds. So a 20-second dance clip with image selected is outside the documented envelope - set video for long drivers, and expect the character's facing to follow the source.

prompt (required, up to 2500 characters) describes the desired output. With a driver video supplying the motion, use the prompt for the subject and scene rather than re-describing the dance.

timeout_seconds (default 1200, range 30–7200) and callback_url round it out.

Outputs

video is the native result - your character, moving. url and all_urls_json hold the links, task_id is the KIE job reference, raw_json is the provider response, and credits_consumed / credits_left are floats, which you'll want to watch: this is one of the more expensive node types in the pack, since the driver clip's length drives the render. Results are archived to ComfyUI/output/KIE-Results/videos/.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
cd ComfyUI-KIE-Nodes-Next
pip install -r requirements.txt

Restart ComfyUI. Dependencies are requests, Pillow, numpy, PyYAML, and there are no model downloads - Kling has no local weights. Windows one-click installer in dist/. Manager may not have the pack listed; the README still treats the registry route as future work, so clone it.

Key once, in Settings → KIE.ai Nodes Next → Connection. Validated before saving, masked afterwards, and never written into workflow JSON. For headless installs, KIE_API_KEY in the environment works and takes priority over the saved key.

Where this bites

Feeding a long driver with image orientation. Anything past 10 seconds needs character_orientation = video. Expect validation failures otherwise.

Wiring a batch into input_urls. Documented as one image. Keep it to one.

Driver clips that don't show head, shoulders and torso produce mush - the model needs a body to track. Crop your dance footage to the performer before uploading.

Oversized video uploads. The documented ceiling is 100MB. Long or high-bitrate clips fail at upload, before generation.

Timeouts on 30-second pros are real, and paid for. The render continues at KIE after the node stops waiting; grab the task_id from the error and check it with the Task Status node instead of paying twice.