Extract Video Chunk

If you're doing motion transfer - driving a generated video with a reference clip - you don't feed the model the whole 300-frame driving video. You feed it one chunk at a time, and you feed each chunk its own reference. This node is what pulls chunk N out of a longer driving video, with the overlap baked in so your chunks can be blended back together later without a visible seam.

It's the workhorse of the VideoChunkTools pack. The whole rolling-reference strategy hangs on it: chunk 0 with your original reference, then each subsequent chunk with the previous chunk's last generated frame as its reference. The driving video is what tells the model what to do; the rolling reference is what keeps identity consistent while the action moves forward.

How the slicing works

The layout is simple once you see it. With chunk_frames=81 and overlap_frames=16, the stride between chunk starts is 81 − 16 = 65 frames:

Chunk 0: frames 0-80
Chunk 1: frames 65-145
Chunk 2: frames 130-210

Adjacent chunks share those 16 frames at the boundary, which is exactly what BlendVideoChunks later crossfades. One detail worth knowing: if the last chunk would run off the end of the video, it clamps to the final frame and starts earlier to stay full-size. So the last chunk covers different ground than the arithmetic suggests. That's deliberate, and it's why the is_last_chunk output exists.

The inputs that matter

• images - the full driving video / image sequence.
• chunk_index - which chunk, 0-based. Wire this up per-chunk in your hand-built chain.
• chunk_frames - frames per chunk. Default 81, which is Wan's native window. For Wan models this must be 4n+1 (81, 97, 113, 129...). The tooltip spells out the rule: ((n-1)//4)*4+1. Getting this wrong is how you end up with a clip two frames short or weird behavior at the end - the exact tax the community kept complaining about before single-node chunkers existed.
• overlap_frames - frames shared between adjacent chunks. Default 16 (~1 second at 16fps), the pack author's recommended value, and it's hard to argue with.

The outputs

• chunk - the extracted IMAGE slice, feed this to your I2V pipeline.
• total_chunks - how many chunks cover the whole video; use it to plan your loop.
• chunk_index - pass-through of the index, for chaining nodes.
• is_last_chunk - BOOLEAN, true on the final chunk. Wire this to a switch or condition if you're automating the chain, or just to stop the loop.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/gregtee2/ComfyUI_VideoChunkTools.git

Or search "VideoChunkTools" in ComfyUI Manager and install, then restart. Pure PyTorch, zero pip dependencies, no model downloads. It doesn't care which model generated your frames - it just slices a batch.

The one thing people trip on

Don't set overlap_frames ≥ chunk_frames - the node raises a clear ValueError and you'll know immediately. And if you're planning a long run, fire up VideoChunkPlanner first (same pack) to see the chunk layout before you build the whole graph. This node is the slicer; the planner is the map.