Control End Frame Extractor

Control End Frame Extractor is the "where should this clip be heading?" node in Mickmumpitz's iterative video stack. When you're generating video in chunks - each pass of the loop produces one 81-frame segment - you usually have a full control sequence planned out ahead of time: a depth map, a pose video, or whatever you're conditioning on, all the way to the end of the shot. This node cuts that long sequence down to the handful of frames that mark each iteration boundary, so the generation knows what state it should be aiming for.

It belongs to the pack's Video Context category and sits upstream of the loop, alongside FrameContextFit and AnchorFrameExtractor. The workflow picture: extract the target end-frames once from your full control footage, feed them into the iteration machinery, and each pass of the loop generates toward the right one instead of drifting.

How it works

It's pure index math over the batch dimension. Given num_start_frames (overlap frames between iterations) and frames_per_iteration, the node keeps frame 0 as the start anchor, then collects one frame at the end of each iteration. With the defaults - 4 start frames, 81 frames per iteration - the extracted indices are 0, 80, 157, 234, and so on until the input runs out. The rhythm matters: the first iteration runs a full 81 frames, then each later iteration steps frames_per_iteration - num_start_frames (here 77) forward, because the first num_start_frames frames of each new chunk overlap with the tail of the previous one. Matching these numbers to your actual loop parameters is the whole game - get them consistent and the end-frames land exactly on the seams.

The inputs and outputs

• images - the full control IMAGE batch (e.g. the entire depth or pose sequence for the shot).
• num_start_frames (default 4) - how many overlap frames your iterative loop uses. This must match the same setting on your IterVideoRouter / FrameAccumulator.
• frames_per_iteration (default 81) - frames generated per pass of the loop. Again, must match the loop.

The single output, end_frames, is an IMAGE batch of those boundary frames, meant to be fed into something like EndFrameInjector or used as the reference for each chunk. For a beginner the honest note: this node is useless on its own. It only does something if you're running the pack's multi-iteration loop with the same parameters on both sides, which is exactly why the author labels these Video Context nodes.

Installing it

Part of the Mickmumpitz pack - Manager search "Mickmumpitz", install, restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git

Pure tensor slicing, so only the pack's base deps (numpy, Pillow, opencv-python) are involved. Nothing to download.

Common issues

The classic mistake is a mismatch: frames_per_iteration here says 81 but your actual sampler produces a different number of frames per pass, and suddenly your end-frames are landing mid-chunk and the loop drifts. Keep this node's numbers pinned to the loop's, and if you change one, change both. Also note the output is a sub-batch of your input - the node doesn't copy frames or re-render them, so if your control sequence is already short, you'll get fewer end frames than iterations, and downstream nodes have to handle that shortfall.