Whole Video
The node that remembers every scene you've made
- wait_for
- Images
- count
Every iterative-video workflow has the same dirty secret: the "infinite" video isn't infinite, it's a frame batch that somebody keeps growing by hand. Whole Video is the somebody. It's the pack's memory - it takes the frames you just made, stitches them onto everything that came before, and hands the combined batch to VHS_VideoCombine so the next Infinite_Video*.mp4 comes out a little longer each run.
If that reads like it's doing a lot, it is. It's also the node that makes the progression loop actually progressive instead of a pile of disconnected clips.
How it works
It has two modes, driven by the scene_mode string that Story Scene Switch hands it.
First Scene Generation. If an Infinite_Video*.mp4 already exists in the output folder, it archives that file as Definitive_Infinite_Video_XXX.mp4 (the XXX is an auto-incremented number) - so your history is preserved, just renamed. Then it returns only the new wait_for frames. Fresh canvas, old story safely filed away.
Further Generations. It finds the latest Infinite_Video*.mp4, reads every frame out of it (imageio talking to ffmpeg), deletes that source file, appends your new wait_for frames, and returns the combined batch. One live video, growing by one scene at a time.
Critical detail: this node never writes the video file itself. It builds the frame batch; VHS_VideoCombine does the actual encoding and is expected to write the result back under the Infinite_Video*.mp4 name. That's the contract of the whole pack - the README says so explicitly, and if you break it (by pointing the combine node at a different output name), the loop quietly stops looping.
The deletion of the source file is worth calling out twice, because it's the destructive part. Whole Video reads the old video, then removes it. Your safety net is the Definitive_Infinite_Video_XXX.mp4 archives from first-scene runs - those survive. But if you're mid-loop and something fails before the new file is written, that scene's frames are gone with the source file. Keep the archives.
One tell about where this came from: the docstring says "Concatenate QWEN videos." This pack was built around a Qwen-video pipeline, and Whole Video is the append-frame glue for it. It works with anything that can feed it an IMAGE batch, though - the mechanism doesn't care which model made the frames.
Inputs and outputs
scene_mode(STRING) - from Story Scene Switch'sSceneModeoutput; decides archive-vs-appendwait_for(IMAGE) - your newly decoded frames, typically straight from VAE DecodeImages(IMAGE) - the full batch (old + new in further mode), forVHS_VideoCombinecount(INT) - total frame count in the batch; the cheap sanity check that your append actually grew
Install and troubleshooting
Shared pack install, no model downloads:
cd ComfyUI/custom_nodes
git clone https://github.com/pmarmotte2/Comfyui-Video-Progression
then restart ComfyUI (or Manager → search "Comfyui-Video-Progression" → install → restart).
The failures that actually happen, in order of likelihood:
- The video never grows. Check
VHS_VideoCombineis writing back to theInfinite_Video*.mp4name. This is the number-one way people break the loop. - Frames come back empty. The node reads MP4s through imageio, so it needs an ffmpeg-capable backend (imageio-ffmpeg) in your environment. No backend, no old frames, and you get only the new batch - it fails soft, not loudly.
- Wrong
count. It should climb by your new frames each run. If it doesn't, either the source video wasn't found orwait_forwasn't connected - note that with nowait_forinput the node returnsNone, 0rather than crashing.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| scene_modeopt | STRING | — | |
| wait_foropt | IMAGE | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| Images | IMAGE | — |
| count | INT | — |