π Kraken Last Frame + Meta
Chain five-second WAN clips into a longer video by reusing the last frame
- images
- last_frame
- first_frame_out
- width
- height
- frames(length)
- fps
- resolution_text
WAN gives you a 5-second clip, and a 5-second clip is rarely enough. The classic workaround - the one this node is built for - is to generate a clip, take its last frame, and feed that frame back in as the first frame of the next clip. Each generation continues where the last one ended, and you stitch together a longer video without ever having to wait out a single huge frame count. π Kraken Last Frame + Meta is the node that makes that loop one wire instead of a ritual.
It's part of Kraken Tools (krakenunbound/comfyui-kraken-tools), and it's the WAN-specific half of the pack's video story: Kraken WAN Helper sets up parameters, this node does the chaining. It's a small, honest node - a pure extractor plus metadata passthrough - and that's exactly what you want in a loop.
How it works
The mechanism is trivial, which is the point. The node takes an images batch (the frames of a generated video), slices off the last frame, and returns it as a single-frame IMAGE tensor. It also returns that same frame a second time under the name first_frame_out, so the graph reads the way you think about it: this is the frame that becomes the next clip's first frame.
The width, height, frames_length, fps, and resolution_text inputs are metadata that flows straight through to identically-named outputs. That sounds boring until you realize it's the whole trick: your WAN generation node needs width/height/frames/fps on every pass, and in a loop those numbers have to keep traveling or the next generation silently resets them to defaults. This node carries them around the loop for you.
The one behavioral input is duplicate_last_frame (off by default). When WAN 2.2's pipeline adds a trailing frame at the end of a clip, the "last frame" you extract can be that synthetic bookend rather than your actual last render. Duplicating the slice is a workaround for continuity - enable it if you see a flicker or jump at the join between clips.
Outputs
- last_frame (IMAGE) β the extracted final frame; the thing you'd save or inspect.
- first_frame_out (IMAGE) β the same frame, labeled for its job: plug into the next WAN generation's first-frame input.
- width / height (INT), frames(length) (INT), fps (FLOAT), resolution_text (STRING) β metadata passthrough, feeding back into the generation node's parameters.
The loop looks like: WAN Helper β generation β Kraken Last Frame + Meta β (last_frame as first_frame back into generation) β Save. Each clip reuses the previous clip's ending as its start, so you get continuous, scene-consistent longer video instead of five unrelated clips.
Install
Pack install as usual. ComfyUI Manager β search "Kraken Tools" β Install β restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/krakenunbound/comfyui-kraken-tools
cd comfyui-kraken-tools
pip install -r requirements.txt
No model files, no special deps - this node is pure tensor slicing and bookkeeping.
Where people get burned
- Feeding it the wrong batch. The node expects the full frame batch (shape
[B,H,W,C]) from your video sampler's IMAGE output. If you feed it a single-frame preview, the "last frame" is just that one frame and your chain loops the same image forever. - Metadata drift. The passthrough only helps if you actually wire the metadata outputs back into the next generation. It's easy to connect only the image and leave the width/height/frames wires dangling - then the next clip re-derives its own defaults and your loop silently breaks continuity. Connect all the numbers.
duplicate_last_frameis a workaround, not a fix. If your joins show a one-frame jitter, flipping it on helps. If they show a real scene cut, the problem is upstream (your first-frame conditioning), and duplicating won't save you.- WAN 2.2 vs 2.1 behavior. The trailing-frame quirk is a 2.2-era thing. If you're on 2.1 and see no artifact, leave
duplicate_last_frameoff - it's not a free feature, it changes the frame count.
Longer video by chaining clips is a well-worn community path - it keeps each generation short enough to fit VRAM and sanity - and this node is the plumbing that makes it a loop instead of a chore.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | β | |
| width | INT | 83216β4096 | β |
| height | INT | 48016β4096 | β |
| frames_length | INT | 651β4096 | β |
| fps | FLOAT | 161β120 | β |
| resolution_text | STRING | 832 x 480 | β |
| duplicate_last_frameopt | BOOLEAN | false | β |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| last_frame | IMAGE | β |
| first_frame_out | IMAGE | β |
| width | INT | β |
| height | INT | β |
| frames(length) | INT | β |
| fps | FLOAT | β |
| resolution_text | STRING | β |