Extract Start Frames For Continuations
Grab the first N frames to seed the next clip
- input_video_frames
- start_frames
Wan tops out around 81 frames per generation. Everyone who's made anything longer than five seconds knows the drill: generate a clip, take the tail of it, and feed that into the next generation so the motion continues instead of restarting. This node is a small, boring, genuinely useful piece of that loop - it pulls the first N frames off an image sequence so you can hand them to a continuation.
The name says "start frames" and that's exactly what it does: given a batch of frames, it returns the first num_frames of them. Not the last. Which is worth pausing on, because the classic last-frame-to-first-frame chaining trick grabs the end of a clip. This node is built for the newer windowed-continuation pattern, where you re-anchor the next window on the opening slice of a reference or previously-generated sequence rather than a single hand-off frame.
What it actually does
There's no model here, no sampling, no VRAM cost worth mentioning. It's a slice operation on an IMAGE batch. You give it a sequence, you say how many frames from the front you want, and it hands them back. That's the whole node. It exists so you're not doing frame-index math by hand or bolting on a general-purpose "get image from batch" node and hoping you counted right.
In the Wan world, "continuation" usually means feeding a chunk of known frames into the next generation as anchoring context so the model picks up where you left off. The KB's read on long-form Wan is blunt: the 81-frame ceiling never moved, the community just wrapped the chain-and-restitch loop in nicer nodes. This is one of the little cogs in that machinery.
The inputs and output that matter
Two inputs, both required:
input_video_frames(IMAGE) - the sequence you're slicing. Usually the decoded output of a previous Wan generation, or a reference video you've loaded.num_frames(INT, default 10) - how many frames off the front to keep. Ten is a sane default for a small overlap; bump it if your continuation logic wants a fatter anchor.
The single output is start_frames (IMAGE) - the first num_frames frames, ready to wire into whatever encode/embeds node kicks off your next window.
How to install it
It ships inside Kijai's WanVideoWrapper, so you don't install this node on its own - you install the pack. Easiest path is ComfyUI Manager: open the Custom Nodes Manager, search ComfyUI-WanVideoWrapper, install, restart. Manual is the usual:
cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt
then restart. This node itself downloads nothing - but the wrapper as a whole is a full Wan video stack, so you'll need the actual Wan model weights (Kijai mirrors fp8 versions on HuggingFace under Kijai/WanVideo_comfy) and a GPU with real VRAM before any of it does something.
Common issues & troubleshooting
You wanted the end, not the start. This is the one thing to double-check. If your continuation is meant to pick up where the previous clip ended - classic last-frame chaining - this node gives you the wrong end. It takes frames from the front. For tail-based hand-offs you want a different slice.
Off-by-a-few frame mismatches. Because the Wan VAE compresses time roughly 4x, valid frame counts follow the 4n+1 pattern (81, 77, 73…). If your continuation comes back a frame or two short, that's the latent rounding, not this node miscounting - it returns exactly the N you asked for.
Fewer frames than you asked for. If num_frames is larger than the sequence you fed in, you only get back what exists. Feed it a real clip, not a single frame.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| input_video_frames | IMAGE | Input video frames to extract the start frames from. | |
| num_frames | INT | 101–1024 | Number of frames to get from the start of the video. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| start_frames | IMAGE | — |