WanFunControlToVideo
Wan's control video goes straight into the latent — no ControlNet required
- positive
- negative
- vae
- clip_vision_output
- start_image
- control_video
- positive
- negative
- latent
Wan never got a classic ControlNet. Instead, control arrived through the "Fun Control" model family - Alibaba's approach where the control signal is fused directly into the VAE latent space rather than injected as a separate network. WanFunControlToVideo is the node that builds that pipeline. Give it a control_video - a pose sequence, a depth map video, edge frames, whatever the Fun Control checkpoint you loaded was trained on - and it encodes that video and concatenates it into the conditioning's latent channels alongside your start_image. The model then reads structure and content from the same latent it generates into.
How it works
Mechanically it's a sibling of WanImageToVideo with one extra optional input: control_video. The concat latent it builds has double the channels (32 instead of 16): the control video's encoded frames go into one half, and the start_image's encoded frames go into the other. Both are attached to your positive and negative conditioning as a concat_latent_image, and the optional clip_vision_output (the CLIP-Vision embedding of the first frame) joins them for I2V consistency. The latent tensor itself starts empty, and the canvas inputs - width/height (default 832x480, stepping by 16), length (default 81, stepping by 4, 4x temporal compression), batch_size - are the usual Wan arithmetic.
Outputs are positive, negative, and latent, all three feeding a KSampler running a Fun Control checkpoint.
The inputs that matter
- control_video - the structure you want the model to follow, frame for frame. This is the whole reason the node exists. The Fun Control models come in openpose, depth, and canny flavors, so the video you feed has to match the checkpoint's training.
- start_image - the content anchor, the first frame the model preserves.
- clip_vision_output - optional but recommended for I2V; it's the same vision-embedding input
WanImageToVideouses.
How you get it
Ships with ComfyUI core. The models are the real acquisition: a Wan 2.1 Fun Control checkpoint (the wan2.1_fun_control_* series from Alibaba's VideoX-Fun, or a later one for 2.2), the matching Wan VAE, the umt5 text encoder, and the CLIP-Vision model - all in the standard models/ folders. ComfyUI's example workflows show the wiring.
Where people get burned
Mismatched control type. Feeding a pose video into a depth Fun Control checkpoint is the "nothing is happening" classic - check the model's card before you blame the node. Preprocessing. The control video has to be properly preprocessed (DWPose/OpenPose skeletons, a real depth map) before it's worth encoding; garbage in, loosely-guided garbage out. It's the latent path, not a ControlNet. That means no strength or start/end dials on this node - control is baked in at full weight, and if you want to dial a condition down you're in VACE territory instead. And the ecosystem framing: by 2026, "video ControlNet" stopped being a noun - Wan control runs through VACE and Fun, LTX through IC-LoRAs - so this node is part of that vocabulary, not the SD-era one.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| vae | VAE | — | |
| width | INT | 83216–16384 | — |
| height | INT | 48016–16384 | — |
| length | INT | 811–16384 | — |
| batch_size | INT | 11–4096 | — |
| clip_vision_outputopt | CLIP_VISION_OUTPUT | — | |
| start_imageopt | IMAGE | — | |
| control_videoopt | IMAGE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| latent | LATENT | — |