Wan Extract Last Frames (Latent)

This is a one-job node, and the job is small on paper but load-bearing in practice: it takes a batch of Wan latents and hands you back just the tail end. If you're chaining clips to beat Wan's 81-frame ceiling - which is the entire reason the flagship node in this pack (WanAdvancedI2V) accepts a prev_latent input - this is what produces that input.

Why this needs to be its own node

Wan 2.2 generates in fixed-length chunks natively capped around 81 frames. To go beyond that, the standard trick (long before this pack, and still the mechanism underneath SVI-style long-form workflows) is: generate a chunk, take its last several frames as continuity anchors, feed those into the next chunk's generation so it picks up where the last one left off, repeat. That's how a January 2026 community post turned into a 20-second continuous clip with no visible transitions - 15 five-second chunks stitched this way, at 340 seconds total render time for the first flagship version, longer runs going out to a minute or more on 16GB VRAM by feeding the tail forward each time.

The catch is that a Wan latent isn't pixels - you can't just crop the end off an image tensor and call it a day, because the temporal compression means frame indices don't map 1:1 onto the latent's own indexing. This node handles that conversion so you don't have to do the math by hand every time.

Inputs and outputs that matter

There are exactly two inputs, both required:

• samples (LATENT) - the full latent batch from your previous chunk's sampler/VAE stage, before it's been decoded to pixels.
• num_frames (INT, default 9, range 0-81) - how many frames from the tail you want extracted. This is the piece worth thinking about: too few and your next chunk doesn't have enough continuity context to avoid a visible seam; too many and you're wasting length budget on the next chunk re-covering ground the previous one already generated. 9 is the pack's own default and a reasonable starting point; the pack's continue_frames_count parameter on the advanced I2V node (default 5) is in the same neighborhood, so treat single digits as the normal range rather than reaching for something large.

Output: last_frames - a LATENT containing just that trailing slice, sized and formatted to plug straight into WanAdvancedI2V's prev_latent input (or WanSVIProAdvancedI2V's, same slot) for the next chunk in your chain.

Installing it

ComfyUI Manager: search "ComfyUI-Wan22FMLF". Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/wallen0322/ComfyUI-Wan22FMLF

Restart. This node has no model dependency of its own - it's a pure latent-slicing utility, so it works with whatever Wan checkpoint the rest of your chain is already using.

Common issues

Chaining several chunks and ComfyUI eventually crashes. This is a real, repeatedly-reported failure mode in the wider community, and it's usually not this node - it's memory pressure from holding many chunks' worth of latents/frames in the graph at once as you stitch a long sequence. One widely-cited long-form run needed to stitch and upscale outside ComfyUI entirely past a certain length. If you're chaining more than a handful of chunks, plan to save and clear intermediate results rather than keeping the whole chain live in one graph.

Wrong end of the video. It's easy to accidentally wire this off the first chunk's latent instead of the one you just generated, especially in a loop-style workflow where node reuse gets confusing. If chunk 2 doesn't visually continue from chunk 1, check which latent this node is actually reading from before you touch any strength parameters.

Using this when you don't need to chain. If your whole clip fits inside 81 frames, you don't need this node at all - it exists specifically for the multi-chunk continuation path. Reach for it only once you've hit Wan's native length ceiling and are building the loop that gets past it.

Mismatched num_frames between this node and the receiving node's overlap setting. If you extract 9 frames here but the downstream node's continue_frames_count (or equivalent) expects a different amount, you can end up with either a duplicated stretch of frames or a gap at the seam. Keep the two numbers aligned, or lean on WanAdvancedI2V's own trim_latent/trim_image/next_offset outputs, which exist precisely to keep this arithmetic consistent across a chain.