Wan Video Merge (QQ)
Stitch two or three Wan clips together with actual transitions
- video1
- video2
- video3
- video
- frame_count
Wan clips cap out around 81 frames natively, which is why the community's standard move for anything longer is to generate several short clips and assemble them. The naive way to do that - a hard cut in an editor - is fine, but if you want the seam to feel like part of the shot, you want a blend. WanVideoMerge is the pack's glue: it takes two or three videos and cross-fades between them over a transition you control, instead of just slamming them end to end.
The info_schema tells the whole story. Required inputs are video1, video2, plus:
- video_speed (0.1–3.0, default 1.0) - a speed factor applied to the result. Lower than 1 stretches the timeline (slower, longer video); higher than 1 shortens it.
- transition1_frames (0–1000, default 10) - how many frames the blend between video1 and video2 takes. Zero gives a hard cut.
If you have a third clip, wire video3 and set transition2_frames for the second blend. Outputs are video (the assembled IMAGE sequence) and frame_count (INT) - handy if the next node in the chain needs to know the length. The order is fixed: video1 → blend → video2 → blend → video3.
How it works, practically
A cross-fade (and its cousins like dip-to-black) is the right tool for the "two different shots, same scene" case that dominates Wan work - a character walks out of frame in clip 1, clip 2 starts with an empty frame, and the fade hides the fact that the character isn't identical across the boundary. The community's consistency problem is real (identity drifts across clips, and the KB documents it as the unsolved 5-second-problem), so a blend that masks the seam matters more for Wan than it ever did for camera footage.
Two workflow notes. First, this node operates on decoded IMAGE frames, so it belongs after VAE decode - you can't run it on latents. Second, because it takes decoded frames, feed it clips that share resolution and frame count; it won't resize for you, and mismatched dims will bite. Use video_speed to normalize durations if your clips differ in length, and remember it changes the whole assembled result, not individual clips.
Installing it
It's part of siraxe/ComfyUI-WanVideoWrapper_QQ. Install via ComfyUI Manager (search WanVideoWrapper_QQ/SA-Nodes-QQ), or:
cd ComfyUI/custom_nodes
git clone https://github.com/siraxe/ComfyUI-WanVideoWrapper_QQ.git
Restart ComfyUI. It's pure tensor shuffling - no extra Python deps, no model downloads.
Gotchas
- Mismatched resolutions crash or look broken. Match frames per clip before merging, or you'll be debugging tensor shapes at 3am.
- Don't overuse long transitions. At default
video_speed1.0, a 100-frame transition on 81-frame clips eats more than a full clip of the fade - keeptransition1_framesmodest unless you specifically want a slow dissolve. - Pack note: the repo was renamed to ComfyUI-SA-Nodes-QQ in v1.3.4; delete any stale
wanwrapper_qqfolder incustom_nodesif old workflows reference it.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| video1 | IMAGE | — | |
| video2 | IMAGE | — | |
| video_speed | FLOAT | 1.000.1–3 | Speed factor for the resulting video. Lower values create slower, longer videos. Higher values create faster, shorter videos. |
| transition1_frames | INT | 100–1000 | Number of frames for transition between video1 and video2 |
| video3opt | IMAGE | — | |
| transition2_framesopt | INT | 200–1000 | Number of frames for transition between video2 and video3 |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| video | IMAGE | — |
| frame_count | INT | — |