LTX-2 Long Video Wrapper Prep (Disk) ????

Planning a 3-minute music video in LTX-2 by hand is a gauntlet of arithmetic: the source is N frames, the segment should be 10 seconds at 24fps, LTX wants 8n+1 frame counts, you need overlap for continuity, and every number has to round consistently or the timeline drifts by the third segment. This node does all of that planning for you. Give it the song duration, the fps, and a target segment length, and it slices the source footage into per-segment image batches with the LTX-2 constraints already applied.

The "Disk" in the name is the memory story: the source frames live in a directory (iamccs_source_frames/source_video by default) and are loaded range-by-range, one segment at a time, so a 180-second video never has to sit in RAM as one giant IMAGE batch. This is the prep node for the pack's low-RAM long-video pipeline - pair it with the samplers and bridges and you get continuous generation that doesn't OOM your system RAM.

How it works

It's a three-stage pipeline inside one node:

1. Plan - an internal segment planner turns song_duration_s, fps, and segment_duration_s into a full segment table: total segments, per-segment frame counts, overlap, and trim amounts. It rounds frame counts to LTX-2's 8n+1 rule using ltx_round_mode (up default, nearest, down).
2. Slice - IAMCCS_LoadImagesFromDirLite loads just the current segment's frame range from frames_dir, driven by segment_index.
3. Anchor & pad - the segment's first frame is re-applied to the head (head_k_frames, default 1) using head_mode (hard_lock default, linear_blend, ramp) so every segment starts from a stable anchor. min_frames (default 25) guarantees a minimum length - padding by repeat_last or raising if error - with an LTX frame fix on top. Optionally use_bridge_anchor swaps in the last-frame bridge PNG as the head for genuine cross-segment continuity.

Everything important is surfaced as outputs, not buried: current_segment, total_segments, trim_head_frames, continuation_trim_head_frames, segment_report, and plan_report - plus a fresh render_id when you didn't supply one, which is what keeps the whole chain keyed together.

Inputs and outputs

• frames_dir - source frames directory.
• song_duration_s, fps, segment_duration_s, segment_index - the planning inputs.
• Optional: render_id, bridge_name, use_bridge_anchor, planning_mode (manual_segment_seconds / auto_profile), content_profile (videoclip / monologue), overlap_frames, ltx_round_mode, head_k_frames, head_mode, head_blend_strength, min_frames, min_frames_mode, min_frames_ltx_fix.

Outputs: images (the current segment), current_segment, total_segments, segment_report, plan_report, trim_head_frames, render_id, continuation_trim_head_frames.

Install

ComfyUI Manager → "IAMCCS", or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart. No extra deps - the frame loading and planning are all in-pack.

Gotchas

The whole node is a contract with its inputs: frames_dir must contain the frames in order (zero-padded names help), fps must match how those frames were extracted, and segment_duration_s times fps should be within your VRAM's comfort zone. When the timeline drifts, check plan_report first - it narrates every rounding decision, so a wrong ltx_round_mode or an overlap_frames that isn't 8n+1-friendly shows up there long before the video does. And if a segment comes back too short, min_frames_mode: error is your debugging friend: it turns silent padding into a loud failure.