Wan Fun Sampler for Video to Video

This is the node with the most optional inputs in the whole pack, and that's not an accident - it's built to cover four different Wan-Fun model variants through one sampler: plain video-to-video, structural control (Canny/Depth), reference-image-guided generation, and camera-move control. Which of those you're actually doing depends entirely on which optional inputs you wire up and which Wan-Fun checkpoint you loaded - the node itself doesn't force you into one mode.

The four things this node can do

• Plain V2V - wire up validation_video and use denoise_strength to control how much of the original survives. This is straightforward img2img-style logic extended to video: 0 barely touches the source, 1 regenerates it from scratch guided only by the prompt, and the default 0.7 is a reasonable middle ground that keeps the source's motion and composition while letting the model re-render detail and style.
• Structural control - wire control_video to the output of VideoToCanny or VideoToDepth, paired with a Wan-Fun-Control checkpoint. The new video follows the edges or depth of the control video while your prompt drives everything else.
• Reference + control - add ref_image alongside control_video. This matches the README's "Reference Image + Control Video" capability: you supply an image of a character or outfit and a control video for motion, and the model tries to keep the reference's identity consistent while following the control video's structure. It's the closest thing in this pack to VACE's reference-to-video mode.
• Camera control - camera_conditions (a plain STRING input) pairs with the README's -Control-Camera checkpoint variants, which demonstrate pan up/down/left/right and combinations. The README doesn't document the exact string format this field expects, so treat it as something to reverse-engineer from the pack's own example workflows rather than something to hand-type from guesswork.

start_image is also optional and available alongside any of the above, for anchoring the first frame the way a plain I2V start image does.

The fields shared with the rest of the pack

prompt / negative_prompt follow the same rule as everywhere else here - describe the motion, don't restate what the reference or control inputs already show. video_length runs 1-161 in steps of 4 (note the floor is lower here than on the T2V samplers - this node will accept a single frame). base_resolution picks a size bucket (512-1024) the same way the Inpaint sampler does, fitting output dimensions to your input's aspect ratio rather than taking literal width/height.

steps defaults to 25 here, notably lower than the 50 you'll see on the T2V samplers - V2V and control generations generally need fewer steps since the model has more to anchor to than a blank prompt. cfg defaults to 7. scheduler is fixed to Flow.

The TeaCache group (enable_teacache, teacache_threshold, num_skip_start_steps, teacache_offload) and cfg_skip_ratio are the same speed/quality trade-offs as the other samplers - real time savings, with face consistency the thing most likely to soften if you push TeaCache hard. riflex_k (optional) is RIFLEx for extending past the native frame ceiling; community reports on it are mixed at best, more reliable on simple repeated motion than anything complex.

Output is images, the generated clip as a frame batch.

Installing VideoX-Fun

ComfyUI Manager: search "VideoX-Fun" (or "CogVideoX-Fun"). Manual: cd ComfyUI/custom_nodes && git clone https://github.com/aigc-apps/VideoX-Fun, restart. The checkpoint you need depends on which mode above you're running - a plain -Fun-InP model works for basic V2V, but Control, Reference, and Camera modes each need their matching -Control, -Control (with reference), or -Control-Camera checkpoint from the README's model zoo, dropped as a full diffusers folder under ComfyUI/models/Fun_Models/. These are the 47-64GB checkpoints, so check disk space before pulling one down.

Common issues

Wiring the wrong optional inputs for the checkpoint you loaded is the most common mistake - a plain (non-Control) checkpoint won't meaningfully use control_video, and a Control checkpoint fed nothing but validation_video won't behave like a dedicated V2V model either. Match your inputs to your checkpoint. Beyond that, the usual pack-wide issues apply: 14B-class checkpoints without the right GPU_memory_mode back at LoadWanModel will run out of memory, and mismatched video_length between this node and any upstream VideoToCanny/VideoToDepth node will leave the tail of your generation without control conditioning.