并发提交｜Animate 角色动作迁移

The use case that makes this obvious

Motion transfer is an audition, not a generation. You have one character you care about and five driving clips; or one driving clip you've already picked and four character shots you're choosing between. Either way you're running trials - and trials are exactly where a serial API queue wastes your afternoon.

Animate_Motion_Transfer on its own does one transfer end to end: upload the character image, upload the motion video, submit, poll, download. A five-clip audition is five of those in a row, each blocking. This node runs the same task without blocking, and 并发接收视频（10 路） (SeedanceConcurrent_Video_Await) collects up to ten and hands them back in the order you wired them.

Same wrapper pattern as the image-side version, with a video pool behind it. If you've read the Qwen concurrent article, the only differences here are the socket types and the pool size. If you haven't: this is plumbing in the sense comfyui-node-plumbing.md means it - the node makes no media, it just changes when the work happens.

How it works

Inputs are identical to the original node, down to the tooltips - image_url/input_image, video_url/input_video, resolution, ratio, custom_ratio, frame_rate, max_frames, skip_frames, pose_method, normal_mode, neck_correction, pose_strength, camera_motion, camera_strength, mask_mode, expression_strength, chest_motion_strength, api_config, skip_error, seed. One output: future.

What happens after you hit Run:

• The original's strict validator runs before the future exists, so "provide exactly one character image" or "1080p max_frames cannot exceed frame_rate × 10" surfaces immediately and points at the right input.
• The whole execute path - PNG encode, two uploads, submission, polling, MP4 download - runs on a worker thread with its own HTTP session. Video pool default is 10, tunable with SEEDANCE_VIDEO_CONCURRENCY (1–10) before you start ComfyUI.
• The await node restores slot order, so future_3's video always leaves via video_3, whichever finishes first, and progress is aggregated across all in-flight tasks.

Failure handling matches the image side: failure_mode=raise (default) stops and names the slot; placeholder keeps the good videos and substitutes placeholders, with a per-slot summary in status_json - URLs, keys and task IDs redacted. skip_error on an individual submit node isolates just that slot even under raise.

Note what seed does here: the motion-transfer model has no documented seed parameter, so it's ComfyUI cache control only and never travels to the API. Leave it fixed with everything else unchanged and you won't pay twice for the same clip.

Wiring it up

One submit node per task. Five clips means five nodes, each with its own character image and driving video:

[5 × 并发提交｜Animate 角色动作迁移]  →  future →  [并发接收视频（10 路）]
      clip A  ─────────────────────────────────────→  future_1
      clip B  ─────────────────────────────────────→  future_2
      …

Outputs are video_1 … video_10 and status_json. The receiver fills unwired slots with placeholders, so a three-node setup still hands you ten outputs - only the ones you connected are real. Types are enforced: a SEEDANCE_VIDEO_FUTURE into the image receiver throws rather than quietly misbehaving.

The practical shape people miss: because inputs are per-node, you can flip one variable at a time. Same character across five driving clips to check pose adherence, or the same driving clip against four character shots to check likeness. That's a much better way to find the model's limit than adjusting sliders serially and losing track of which run produced what.

Install

It's in the pack already - no separate install for the wrapper. Same steps either way:

comfy node install seedance

or clone https://github.com/T8mars/ComfyUI_Seedance.git into ComfyUI/custom_nodes, install requirements.txt (one line: requests), and restart ComfyUI. The nodes land under Seedance/并发提交. There's examples/并发视频2路最小验证.json if you want to sanity-check the pipe with two clips first, and examples/并发视频10路示例.json for the full layout.

Where people get burned

Upload volume, twice per task. Every submit node uploads its own character image and its own motion video. Ten concurrent transfers is twenty uploads racing, and multi-megabyte MP4s aren't small. The API throttles per token and the pack retries with backoff, so the usual symptom is a long quiet pause, not a crash. Reuse image_url/video_url with public links if you have them - that skips the upload entirely and is the biggest speedup available here.

Failures are still paid for. placeholder mode keeps your graph alive, but a slot that errored halfway has still cost you the call. status_json is the only place the real per-slot outcome lives, so read it instead of eyeballing which preview looks broken.

Pool exhaustion across workflows. The video pool is process-wide and shared with every other video submit node in every running workflow. If something big is already saturating it, your ten transfers aren't ten concurrent transfers - they're queued behind it. Lower the worker count deliberately if you'd rather have a predictable queue than a ragged one; the 10-socket contract doesn't change either way.

The general caveat. This is a reseller gateway: metered, and your character photos and reference footage go to it. Motion transfer means real faces, which is the one input category worth thinking twice about before you fan out ten at once.