WAN Unloop Frames

This is the second half of the WAN Loop Frames pair, and it's a small node with a thankless job: take the segment the sampler produced, keep only the frames that were actually blank, and stick them onto your clip so the whole thing loops.

Why it isn't trivial: what comes back from the sampler is not "the loop." It's context_frames real frames, then your generated bridge, then more context_frames real frames - plus possibly a few padding frames added to satisfy Wan's 1 + 4n frame arithmetic. Concatenating that onto your animation would duplicate footage at the seam and blow past the length you asked for. WAN Unloop Frames reads the metadata to find out exactly which slice of the segment is the new content, and appends only that.

What it actually does

Three required inputs. raw_frames must be the untouched original batch - that's WAN Loop Frames' raw_frames output, not the frames output; passing the segment here is the classic mistake. inpainted_frames is the decoded result of the sample. metadata is a forced STRING input you wire from WAN Loop Frames.

It parses the metadata JSON (format link-comfy-nodes/wan-loop-v2), re-derives the trim that was applied to the original animation, and slices exactly frames_to_add frames out of the inpainted segment starting at the blank window's offset - ignoring the context and padding frames entirely. Then:

output = trimmed_source_frames + generated_bridge_frames

One output, frames, an IMAGE batch. Play it on repeat and it cycles: trimmed clip, bridge, back to frame one. The frames you told Loop Frames to cut are gone on purpose - that's the cost of landing the seam in the right place - and the output length is exactly the frame_count that Loop Frames reported.

The validation is unusually strict, and it's strict in a useful way. It checks the raw frame count against the metadata, checks the inpainted segment length against the metadata, and checks that both batches share height, width and channel count. Then it re-derives the expected output length and raises a RuntimeError if it doesn't match. So if you broke something upstream, you find out here with a message that names both numbers rather than getting a subtly wrong clip.

Installing it

Same pack, same install as its partner node - Manager, search Link Comfy Nodes, or:

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

The pack's README is one line long and reads "AI slop nodes for my own purposes, use at your own risk (I change how nodes behave without warning)", so treat updates as capable of changing behavior between the two nodes of a pair you've already wired up. Its requirements.txt is heavy and includes a git-sourced CLIP install that can fail behind a firewall; since the pack imports all its nodes at startup, any missing dependency hides this node along with the rest.

Where people get burned

"WAN Unloop Frames requires raw_frames to be the untouched full batch: metadata expects 87, received 20." That error means you wired Loop Frames' frames output (the small segment) into raw_frames. Swap it for raw_frames; the message conveniently also tells you the segment length you did provide.

Frame counts have to survive the round trip. The sampled segment must come back at exactly the length Loop Frames produced. Anything you insert between decoding and this node - a frame interpolator, a duplicate-frame node, a hand-trimmed batch - breaks the count and the node refuses. Same for resizing: the raw and inpainted batches must match in height, width and channels, so don't upscale one and not the other.

Don't retype the metadata. It's a JSON blob full of frame indices, generated at run time from your actual batch. It exists so you never have to do the seam arithmetic by hand, which is the exact tax the community chunking nodes were built to remove elsewhere in the Wan ecosystem. Let it be a wire.