FL Wan Video Continuation Blender

This node only makes sense next to its partner, FL_WanVideoContinue, so start there: that node builds a "continuation-ready" frame buffer by taking the last few frames of your input clip and the first few frames of your end clip and placing them at the start and end of a buffer you then run through Wan to generate the bridge in between. The catch is that buffer already contains real frames from both your input and end clips - the overlap is baked in on purpose, so Wan has something to anchor to. If you naively concatenate that generated continuation onto your original clips, you'll duplicate those overlap frames. FL_WanVideoContinuationBlender is the node that knows about that convention and strips the duplication out before stitching.

How it works

It's a cross-fade blender like its sibling FL_WanVideoBlender3Way, but purpose-built for this workflow: it auto-detects and strips the embedded overlap frames from the continuation_video (the thing you generated from FL_WanVideoContinue's buffer) before blending it against your original input and end clips. That's the whole reason this node exists separately rather than just reusing the generic 3-way blender - a generic blend has no idea those overlap frames are already duplicates and would blend real content against itself.

The inputs and outputs that matter

Four required inputs, tooltips straight from the author:

• video_1 (IMAGE) - "First video (reference resolution) - the 'input_video_frames' from FL_WanVideoContinue." This has to be the same clip you fed into FL_WanVideoContinue originally, not a re-render of it.
• continuation_video (IMAGE) - "The rendered continuation video from FL_WanVideoContinue - has embedded overlaps that will be automatically stripped." This is your Wan-generated bridge clip, run on FL_WanVideoContinue's buffer.
• video_2 (IMAGE) - "Second video - the 'end_video_frames' from FL_WanVideoContinue. Will be resized to match video_1."
• overlap_frames (INT, default 3, range 1–50) - "Number of overlap frames used in FL_WanVideoContinue. Must match the value used to create the continuation video." This is the field to get exactly right: it's not a creative dial like it is in the generic 3-way blender, it's a contract with whatever you set in FL_WanVideoContinue upstream. Note the much smaller default (3) and max (50) compared to FL_WanVideoBlender3Way's default 10 / max 1000 - this node expects a small, precise overlap, not a wide artistic dissolve.

One output: blended_video_frames (IMAGE).

How to install it

Via ComfyUI Manager - search ComfyUI_Fill-Nodes (or Fill-Nodes) - or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

Restart ComfyUI. No model downloads for this node specifically; it's tensor manipulation only, though FL_WanVideoContinue upstream of it does drive an actual Wan generation, which is where your GPU time and VRAM budget actually goes.

Common issues & troubleshooting

Mismatched overlap_frames value. This is the single most likely source of a bad result. If the number here doesn't exactly match what you set in FL_WanVideoContinue when you built the buffer, you'll either strip too many frames (losing real content from the continuation) or too few (leaving duplicate frames in, which shows up as a visible stutter or freeze right at the seam). Write the value down when you set up FL_WanVideoContinue and copy it here - don't eyeball it.

Using the wrong clip as video_1 or video_2. These aren't arbitrary "any two videos" slots - they specifically need to be the exact input_video_frames and end_video_frames you fed into FL_WanVideoContinue. Swap in a re-generated or re-cropped version of either and the overlap-stripping math will be looking at frames that don't actually match what's embedded in continuation_video.

Reaching for this node when you didn't use FL_WanVideoContinue. If you're just cross-fading three independently generated clips with no embedded overlap convention, use the plainer FL_WanVideoBlender3Way instead - this node's overlap-stripping logic assumes the FL_WanVideoContinue buffer format and will misbehave against clips that don't follow it.