Nodes/Mickmumpitz-Nodes/Iter Video Router
ComfyUI Node

Iter Video Router

The heartbeat of the iterative video loop

By mickmumpitz·Created 8 months ago·Updated 9 days ago· 47
Iter Video Router
  • start_image
  • current_start
  • num_start_frames
num_start_frames1

Iter Video Router is the node that makes Mickmumpitz's iterative video loop actually loop. Long-form video in ComfyUI doesn't happen in one sampler call - it happens in chunks, and the trick is that each new chunk has to start from where the last one ended. That continuity job is what this node does: on iteration 0 it hands the sampler your initial start image; on every iteration after, it hands it the last N frames of what was just generated, so the new chunk picks up seamlessly.

It's the bridge between the pack's FrameAccumulator (which collects and stores the generated frames) and the sampler itself. If you're building one of the pack's iterative workflows and you want to understand the loop, this is the node to read first - it's the one whose behavior visibly changes between iterations.

How it works

The node has a hidden iteration input injected by the pack's prompt handler at submit time - you never set it by hand. On iteration 0, it returns the start_image you wired in, along with num_start_frames. On iterations after that, it pulls the last num_start_frames frames out of the in-memory buffer that FrameAccumulator maintains. The subtle part is which frames: during a resume (picking a run back up mid-sequence), the buffer hasn't been truncated yet, so naively grabbing the end would read from the wrong iteration. The router keeps track of cumulative frame counts per iteration and uses those to find the correct read position. If the in-memory buffer isn't available at all - say you restarted ComfyUI mid-run - it falls back to loading the last saved frame from disk via a previous_frame_path, also injected by the handler.

So the node is really "give me the correct start frames for this iteration, whether that's the fresh start image, the in-memory buffer, or the disk fallback."

The inputs and outputs

  • start_image (IMAGE, required) - the initial frame for iteration 0.
  • num_start_frames (default 1) - how many overlapping frames each new chunk carries over. Match this to FrameAccumulator and your slicers.

Outputs:

  • current_start (IMAGE) - the start frames for the current iteration.
  • num_start_frames (INT) - passthrough of the value, so downstream nodes can read it.

Installing it

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

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

No models to download for the router itself; it needs the pack's full iterative loop to be meaningful.

Common issues

First, num_start_frames must agree everywhere - router, accumulator, slicer - or the overlap math falls apart and you get visible seams or doubled frames. Second, the disk fallback only loads a single frame, so it's strictly worse than the in-memory path: if you rely on it mid-loop you lose the multi-frame overlap. Third, remember this node only does something inside the pack's loop. Run it as a standalone node and iteration is stuck at 0 - it'll just pass through your start image and look deceptively like a trivial router. That's by design; the magic is the prompt handler.

CategoryMickmumpitz/video/iteration

Inputs (2)

NameTypeDefaultDescription
start_imageIMAGE
num_start_framesoptINT11–99

Outputs (2)

NameTypeDescription
current_startIMAGE
num_start_framesINT