Trim Frame Timeline

Once you're running a video loop that accumulates frames on disk instead of in memory, the next thing you always want is to choose. Keep the first eighty frames as a caption background. Drop the tail. Export only the middle of a long take. In the tensor world that's a slice of a batch and you eat the copy; here it isn't even a copy.

Trim Frame Timeline is the range selector for Eclipse's ECLIPSE_FRAME_TIMELINE objects. It's the boring, correct utility in the trio that shipped in Eclipse 4.4.10 (2026-09-26) with Decode and Append Timeline and Frame Timeline Loop Gate.

What it actually does

The timeline object is a frozen descriptor listing chunks of exact pixels, each chunk a range inside a frames.npy file owned by a temporary directory. Trimming walks those chunks, computes the overlap between your requested range and each one, and builds a new descriptor that reuses the same file owners. Nothing is read, nothing is copied, nothing is re-decoded - the whole operation is bookkeeping.

That matters, because the alternative - re-decoding latents or re-encoding an mp4 to change where a video starts - is boringly expensive. Here the work scales with the number of chunks (one per appended scene), not the frame count.

The inputs and outputs that matter

Three inputs, all required:

• timeline - an ECLIPSE_FRAME_TIMELINE, i.e. the output of Decode and Append Timeline or the carried value inside your loop. This node won't accept IMAGE. If you hand it a batch you get a type error, not a conversion.
• start (int, default 0) - where the retained range begins, counted in timeline order across all appended scenes.
• count (int, default 1, max 1,000,000) - how many frames to keep. Default is 1, so if you've just dropped the node in, set it.

Four outputs, and this is the part people under-use:

• timeline - the trimmed view, wire it onward.
• width, height - the frame dimensions carried by the timeline.
• count - the actual number of frames in the trimmed result.

The three integers exist so you can drive downstream nodes without hardcoding values that only the timeline knows. count is the useful one: feed it to anything that needs a frame total - a filename placeholder, a consistency or blending node, a length check. width/height let you configure an export or a caption render from the timeline itself instead of typing 512 and 896 in three places and forgetting one.

Downstream is Render Lyric Captions, Save Video, or Save Video with Generation Data - the timeline goes into the save node's image/video socket, which streams chunks at the stored FPS rather than materializing an IMAGE batch.

Install

You install the pack, not the node. ComfyUI Manager → search ComfyUI_Eclipse, or:

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

Restart afterwards - Eclipse 4.4.x needs a fresh start to register new nodes. The repo's requirements.txt covers the whole pack, including a stable-ts + faster-whisper pair for the transcription nodes you don't need here; install it only if ComfyUI complains about a module. And Eclipse 4.0.0 removed every legacy node ID, so old saved workflows need the pack's Workflow Migration Tool before they'll open.

Where people get burned

You can only trim what you stored. The range is validated as "nonempty and within stored frames" - start + count past the end of the timeline is a hard error, not a clamp. That error is usually a plan problem upstream: Decode and Append Timeline only ever wrote the frames its crop_start/keep_frames selected, so if you stored 100 frames per scene and now want to export 300 from a two-scene run, the frames simply aren't there. Decide your retained ranges when you append, not when you export.

Trimming does not free disk. A trimmed timeline shares its chunks with the one it came from. Keeping 40 frames out of 4,000 drops no bytes, and the temp folder still holds everything until the last reference goes away. If space is the issue, that's the cache's problem, not this node's.

No loop matching. The save nodes' trim modes support duration trimming for timelines - video-to-audio, audio-to-video, shortest - but loop matching and blending are explicitly not supported for timelines and will throw. If you need the ends to loop, you're working in IMAGE batches.

Caption FPS has to line up. When the trimmed timeline feeds Render Lyric Captions, the caption FPS must match the timeline's stored FPS. And frame zero of the caption background is the start of the audio excerpt you already selected, not the start of the song - so when you trim the video for a lyric render, keep whatever offset your caption trim was using. Get that wrong and the text drifts against the audio by exactly as much as you trimmed.