LTX-2 Long Video Wrapper Prep ??

IAMCCS_LTX2_LongVideoWrapperPrep is the planning node for long LTX-2 video: you tell it how long your song/clip is, your FPS, how long each generation segment should be, and which segment you're rendering right now - and it hands back the exact frame range that segment owns, with the head-anchor frames it needs for continuity, all pre-rounded to LTX-2's frame math. It's the "which frames are mine?" answer that keeps a multi-segment render from stitching together clips that don't line up.

Here's the problem it solves. LTX-2 can generate a respectable chunk natively, but a 3-minute music video is segments, and segments need four things to join cleanly: an overlap so the model has context, a head lock so segment N+1 starts exactly where segment N ended, frame counts rounded to the model's valid lengths, and a plan that's identical on every run so you can render segment 5 on Tuesday and it knows it's segment 5. If you've ever had a long-video wrapper produce a clip that comes back two frames short, or a seam where the model "invented" a new first frame, you've met the temporal-compression trap this node exists to defuse.

How it works

It divides song_duration_s by segment_duration_s to get total_segments and computes the range for segment_index. It then applies the LTX frame rules: LTX video VAEs compress time 8×, and valid lengths are 8n+1 - so ltx_round_mode (up/nearest/down) snaps frame counts to legal values, and min_frames (default 25) with min_frames_mode (repeat_last or error) protects tiny tail segments that would be too short to sample. The overlap_frames (default 9) is how much context bleeds between segments.

The continuity mechanism is the head_* family: head_k_frames (default 1) anchors the segment's opening frames to the previous segment's last frame via head_mode - hard_lock (hold the anchor exactly), linear_blend, or ramp - so the model can't drift a new opening frame into existence. head_blend_strength scales that. The outputs then tell the wrapper what to trim: trim_head_frames and continuation_trim_head_frames are the counts to cut so overlap/context frames never appear in the final cut.

planning_mode (manual_segment_seconds or auto_profile) and content_profile (videoclip/monologue) pick between explicit segment lengths and an auto profile tuned to content type. render_id and bridge_name (with use_bridge_anchor) let a detailer bridge keep identity across segments, which is how the pack keeps a character from drifting between takes.

Inputs and outputs

Inputs: source_images, song_duration_s, fps, segment_duration_s, segment_index, plus the optional planning/rounding/head options above. Outputs: images (the segment's frame range, with head anchor applied), current_segment, total_segments, segment_report, plan_report (the two JSON reports that tell you exactly what was computed - read them when a seam misbehaves), trim_head_frames, render_id, and continuation_trim_head_frames.

Installing it

Part of the IAMCCS-nodes pack. ComfyUI Manager → search IAMCCS, or:

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

Restart ComfyUI; it's under IAMCCS/LTX-2. No pip requirements, no model downloads - you feed it your frames and an LTX-2 setup you already run. README floor: ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.

Where people get burned

• Same segment_duration_s/fps/segment_index must be used on every segment run, or segments stop agreeing on the plan. This node is deterministic on purpose; changing a number mid-run corrupts the whole timeline, not one segment.
• Forgetting the 8n+1 rule still applies downstream. The node rounds its inputs; the sampler/VAE path must respect the same lengths or you get the "two frames short" clip that no amount of overlap fixes.
• min_frames_mode = error will fail your render on a short tail segment by design - switch to repeat_last unless you genuinely want a hard stop. That default-inverted footgun is the one people hit first.