Nodes/ComfyUI Eclipse/Decode and Append Timeline
ComfyUI Node

Decode and Append Timeline

Keep a whole video's frames without keeping them in RAM

By r-vage·Created 11 months ago·Updated 2 days ago· 37
Decode and Append Timeline
  • samples
  • vae
  • timeline
  • timeline
◄crop_start0►
◄keep_frames1►
◄fps24.00►

Long video in ComfyUI is not one render. It's a loop: generate a scene, keep it, generate the next one conditioned on the last few frames, repeat. Every Wan-extension or MiniMax H3 segmentation workflow hits the same wall - the loop's carried value is every frame produced so far, as one IMAGE batch. It grows each iteration, gets copied each iteration, and you end up holding four minutes of float32 pixels in RAM because you wanted the last 22 frames.

Decode and Append Timeline kills that carried tensor. It does the normal VAE decode for one scene, saves the exact pixels to disk, and hands you back a small descriptor instead. No image tensors leave the node.

One thing before you go hunting for tutorials: this shipped in Eclipse 4.4.10 on 2026-09-26, it's one day old, and the repo's Readme/Frame_Timeline.md is the only prose written about it. The rest is source.

What it actually does

The execution path is short. Pull samples["samples"], unbind it if the latent is nested (H3-style audio/video latents arrive that way), run the model's own vae.decode, flatten a 5D video decode into a frame stack. Then slice out exactly [crop_start, crop_start + keep_frames) and hand those frames to the timeline writer.

The writer is where the decision lives. Each append makes a fresh temp directory and writes the pixels as a raw NumPy array, frame by frame, straight to disk. What comes back is a frozen descriptor: chunk ranges plus height, width, channels, dtype and fps. Appending to an existing timeline only adds another chunk descriptor - earlier scenes are never loaded or concatenated. When a preview or save node consumes it, the reader memory-maps each chunk, yields frames one at a time, checks for cancellation, and closes the mapping.

Precision survives the trip: float16, bfloat16, float32 and float64 all round-trip exactly, bf16 stored as its unchanged 16-bit pattern. No quantization, no interframe compression, no interpolation.

The inputs and outputs that matter

Five required inputs, four of which you set:

  • samples - the LATENT for this scene.
  • vae - native decode, so whatever the VAE does is what you get.
  • crop_start (default 0) - where the retained range starts inside the decoded scene.
  • keep_frames (default 1) - change this. The default appends a single frame; if your planner says 124, put 124, or you'll build a very smooth slideshow.
  • fps (1–120, default 24) - stored with the timeline and used by every downstream reader.

The optional timeline is the loop's carried value: wire the previous iteration's timeline in and the new scene appends to it. Leave it empty on the first scene.

The single output, timeline, goes into Preview Video's source socket (which streams every completed scene at the stored FPS), Trim Frame Timeline, Render Lyric Captions, either Save Video node, or MiniMax H3 Audio Plan Step V2.

Install

Eclipse is the thing you install - these nodes bring no dependencies of their own. In ComfyUI Manager, search the pack title ComfyUI_Eclipse. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

Then restart: new Eclipse nodes only register on a fresh start. The repo's requirements.txt covers the whole pack - torch, opencv-python, pilgram, safetensors, PyYAML, aiohttp, plus stable-ts and faster-whisper for the transcription nodes. That last pair drags in a big dependency chain you don't need here, but Manager installs the whole file anyway. Skip it unless a node actually errors.

Two lineage notes. Eclipse 4.0.0 deleted every legacy node ID, so older saved workflows need the pack's Workflow Migration Tool before they'll load. And the author's previous pack, ComfyUI-RvTools - that repo is gone. This is its successor.

Where people get burned

Disk. This is the whole cost of the design. Eclipse's own arithmetic: four minutes at 512×896, 24 fps, RGB float32 is about 29.5 GiB of temp files before previews - 5.25 MiB per frame, which is what float32 RGB at that size genuinely weighs. If temp lives on the same small SSD as your install, you'll find out the hard way. When it fills, the node raises an error naming the real temp folder and tells you to free space and stop the backend before deleting anything. Start ComfyUI with --temp-directory to put that folder on a bigger drive.

Deleting frames you still need. Nothing gets cleaned up when a run finishes, on purpose: cached timelines hold their chunks so you can re-export with different captions without regenerating. Don't delete EclipseFrames_* folders while the backend is running, and a preview MP4 can't substitute for them. It's execution-local storage, not restart recovery - after a restart those frames are gone.

The retained-range error. Planned retained range exceeds the decoded scene. means crop_start + keep_frames is more frames than the VAE produced - a mismatch between your planner's assumed scene length and the real one, easy to hit on models that accept only specific lengths (H3's 17k+5 lengths, say). Check what the decode returned before blaming the node.

Changing resolution or FPS mid-loop. An append is rejected unless dimensions, dtype and fps match the timeline it's appending to, with a plain "must remain unchanged" error. Keep the shape constant for the whole sequence or start a new timeline.

Category🌒 Eclipse/ Video

Inputs (6)

NameTypeDefaultDescription
samplesLATENT—
vaeVAE—
crop_startINT0—
keep_framesINT11–1000000—
fpsFLOAT24.001–120—
timelineoptECLIPSE_FRAME_TIMELINE—

Outputs (1)

NameTypeDescription
timelineECLIPSE_FRAME_TIMELINE—