DY Wan Fun 22 Video Generation (fal)

This is the power-user video node, and the parameter list makes no secret of it. DYWanFun22_fal runs Wan 2.2's Fun/VACE control pipeline on fal - think ControlNet for video. You feed it a control video (a pose, depth, or edge sequence) plus a reference image, and it generates a new clip that follows that structure while taking its look from your prompt and reference. It's how you drive motion precisely instead of hoping a text-to-video roll lands the action you wanted.

VACE is Alibaba's Apache-2.0 video control system, one of the first-party task models still shipping on the frozen Wan 2.2 base. This node exposes a lot of it: multi-map control (pose, depth, normal, canny), LoRA slots, and a full sampler stack. Don't let the wall of inputs scare you - the required set is small, and almost everything else has a sane default.

The inputs that matter

For a first run you really only touch four:

• architecture - vace or control. VACE is the general reference-guided mode; start there.
• control_video - the driving video whose structure (motion/pose) the output follows.
• ref_image - the reference the generated video takes its appearance from.
• prompt - describes the scene and content.

Everything else is tuning. A few worth knowing: the per-map strength dials (pose_strength, depth_strength, canny_strength, strength_vace) with their matching *_video inputs let you blend multiple control signals; num_frames (81) and frames_per_second (16) set length; and there are four lora_path slots. Note lora_transformer on each LoRA - high, low, or both - which picks which expert the LoRA applies to, because Wan 2.2 is a two-expert MoE that splits denoising between a high-noise pass (motion) and a low-noise pass (detail). Speed LoRAs typically go on the low pass.

The turbo defaults tell you it's a distilled setup: num_inference_steps is 4, guidance_scale is 1, turbo_mode is on. That's correct for the accelerated path - don't "fix" it up to 20 steps and CFG 7, that's the un-distilled habit and it'll just cost more and look worse. Outputs: video_url and (optionally) frames_zip_url, both STRING lists.

Installing it

ComfyUI Manager → search ComfyUI-fal-API → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI-fal-API.git
pip install -r ComfyUI-fal-API/requirements.txt

No downloads - VACE and the control models run on fal. Set your key (config.ini, or export FAL_KEY=your_key; fal.ai/dashboard/keys), restart, find it under FAL/VideoGeneration/DY.

Where people get burned

The output is a URL (or a list of them), not a native video - send it through Fal Save Media from URL to download, or a Load-from-URL node to view. The optional frames_zip_url gives you the raw frames as a ZIP if you want to post-process.

The real trap is over-configuring. People wire up four control maps and a stack of LoRAs on the first try, get a mess, and can't tell which input caused it. Add one control signal at a time. And respect the turbo defaults - the low step count and CFG 1 are trained-in, not a mistake to correct. Content-map inputs (pose_video, depth_video, etc.) each need to actually be that kind of map for their strength dial to do anything sensible. As with all video here, it's the expensive end of the API, so prototype short (num_frames low) before committing to a long render.