WAN Remove Cap Frames

Think of WAN Connect Frames as scaffolding and this node as the person who comes round afterwards and takes it down. Every video model has constraints that force you to add frames you don't actually want to keep, and Wan's is the 1 + 4n length rule: the VAE steps time in fours, so a valid generation is 5, 9, 49, 81, 121 frames. When you're joining two clips, Connect pads your footage up to a legal count with repeated boundary "cap" frames and tracks exactly which positions are scaffolding. This node deletes them so they never survive into your finished clip.

It takes two required inputs and one optional: the frames you got back after generation and decode, the cap_info STRING straight off WAN Connect Frames' output, and an optional mask to trim in sync with the removed frames. Internally it parses the JSON, drops the recorded cap and padding indices, and checks the result against two rules before returning: the frame count has to match what Connect planned, and the final count has to be 1 + 4n again.

Why does that second check matter? Because the whole point of the two-node pair is that the output of Remove is itself a legal Wan length - so the joined clip can be fed straight into another generation pass as context or extended further without the frame math going sour again. That's the real design payoff: scaffolding while generating, clean 4n+1 footage afterwards.

How you'll wire it

The boringly reliable path is a straight line:

clip A + clip B → WAN Connect Frames → VAE encode →
video inpaint/regenerate pass (mask tells it to redraw the white seam) →
VAE decode → WAN Remove Cap Frames → joined clip

Keep the cap_info string and the frame count untouched between the two WAN nodes. Remove validates hard, and its errors are honest pointers at what you broke:

• "cap_info is not recognized WAN Connect Frames metadata" - you fed it a string that isn't from a current Connect run (or edited it).
• "WAN cap removal produced an unexpected frame count" - the generated result doesn't match what Connect budgeted, almost always because you changed transition_frames, a section, or the preference mode after Connect ran.

That second one is the trap to plan around: these two nodes are a matched pair and they assume nothing changes between them. Decide your counts, run Connect, run your generation, run Remove - editing the middle invalidates the metadata and you just rerun the whole thing.

If your workflow doesn't do masked seam regeneration with Wan, you don't need this node at all, which is fine - it exists to complete its sibling. But if you're stitching multi-clip Wan shots, it's the difference between babysitting frame math by hand and letting the pair handle it.

Installing it

Same pack as its sibling, Link Comfy Nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/Mister-Link/link-comfy-nodes

…or search Link Comfy Nodes in ComfyUI Manager, then restart ComfyUI. This half needs only torch on top of ComfyUI's own stack - no model files, no special runtime - though the pack's shared requirements.txt installs a pile of heavier deps for its other nodes regardless. And mind the README's one-liner: the author ships "AI slop nodes for my own purposes" and changes behavior without warning, so if a workflow breaks after an update, that's the first suspect.