Frame Accumulator

Long video is generated in chunks because that's all your VRAM can hold, and then you're left holding a pile of chunks. FrameAccumulator is the node that glues them into one continuous clip and, more importantly, drives the loop that generates the chunks. It's the heart of the "iterative video" style of workflow this pack is built around: generate a segment, feed its tail into the next segment as context, repeat, and this node remembers everything.

It's a bigger job than it looks. On top of accumulating frames, it handles the re-queue loop (queuing the next iteration into the prompt queue itself), trims or blends the overlapping start frames between iterations, supports resuming a run partway, and can save intermediate frames to disk.

How it works

The required inputs:

• new_frames - the frames produced by the current iteration.
• total_iterations - how many segments the full video needs.

The optional ones are where the power is:

• num_start_frames - how many frames overlap with the previous iteration (the tail you carried forward as context). The accumulator trims those duplicates off the new batch; with blend_overlap on, it cross-fades the overlap instead of hard-cutting, which kills the visible "jump" at segment boundaries.
• resume_from_iteration - if a run died mid-way, set this to the iteration you want to restart from and it truncates the buffer back to that point instead of starting over.
• save_intermediate - dump each iteration's frames to disk as you go, so a crash doesn't lose everything.

Outputs: all_frames (the accumulated video), frame_count (an INT, useful for slicing), and last_frame (the single frame to feed into the next iteration's router/context input).

The loop mechanics deserve a moment. Because it's an OUTPUT_NODE that re-queues the next iteration itself, it works in a single submit - you don't press Run repeatedly. The source is honest about the dark corners: iteration state is a module-level global, and a stale queue snapshot from an interrupted run used to cause extra iterations. The current version refreshes the snapshot at the start of every run, so the "why did it run 3 times when I asked for 2?" bug is fixed - but if you've updated from an older version, be aware the behavior changed.

Where it fits

It's the terminal of an iterative pipeline: KSampler output → FrameAccumulator, with its last_frame feeding the next iteration's start frame. Pair it with the pack's IterVideoRouter, ContextImageExtractor, and the Boundary Frame nodes to repair the seams between segments. This is the approach to "longer than the model wants" that doesn't rely on FramePack or a video-extension LoRA - it just generates and splices.

Installing it

Part of Mickmumpitz-Nodes:

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

or ComfyUI Manager → search "Mickmumpitz" → install → restart. No model downloads from this pack; it works with whatever video model you're iterating (typically Wan).

Troubleshooting

• Runs more iterations than asked - you're likely on an older version with the stale-snapshot bug. Update the pack.
• Hard jump between segments - enable blend_overlap and check num_start_frames matches what your router fed forward.
• Resume does nothing - resume_from_iteration only truncates a buffer that exists. Run the first chunk normally once, then restart from the failing iteration.
• Everything in RAM forever - the full clip accumulates in memory by design. Long videos get heavy; save_intermediate is your insurance for long runs.