IAMCCS WAN FLF Pair From Timeline
The node that hands each video chunk its first and last frame
- timeline_plan
- start_image
- end_image
- prompt
- frames
- motion
- frame_rate
- chunk_index
- chunk_count
- report
- relay_local_prompts
- relay_segment_lengths
- relay_max_frames
- relay_epsilon
- relay_timeline_data
The whole trick of IAMCCS's shotboard pipeline is that every chunk of a long video is an FLF - a "first-last-frame" transition. You generate from image A, and you tell the sampler it should arrive at image B. IAMCCS_WanFLFPairFromTimeline ("IAMCCS WAN FLF Pair From Timeline") is the node that picks which A→B pair you're working on for a given chunk, pulls the actual images off disk, and hands you everything else that chunk needs to render.
You feed it the timeline_plan from IAMCCS_WanCineInfoPure plus a chunk_index, and out come the two images, the chunk's prompt, its length, its motion setting, and the frame rate. It's the per-iteration heart of the shotboard loop, and the natural place to start when you want to understand how this pack builds a long video: one planner decides the shots, this node serves them up one at a time.
How it works
The node looks up flf_pairs[chunk_index] in the plan, resolves the start and end image paths, loads them with the board's resize settings (crop by default, 16-pixel multiple), and reads the chunk's prompt, length (falling back to the board's total duration), and motion (clamped to the 1.0–2.0 range). It also pulls the prompt-relay data for that chunk: relay_local_prompts, relay_segment_lengths, relay_max_frames, and relay_epsilon - the bits a prompt-relay system needs to splice per-chunk text into the generation.
The chunk_index input is marked lazy, so if it's wired to a loop's iteration counter the node only re-runs when the index actually changes - which is what you want in a 40-chunk render.
The outputs that matter
start_image/end_image- feed these to your anchor and end-frame encoder. The A→B contract your sampler has to honor.prompt- the per-chunk text, ready for a text encoder.frames,motion,frame_rate- pacing and motion amplitude for this chunk, wired into the motion/conditioning nodes.chunk_index,chunk_count- pass-throughs so downstream nodes know where they are in the sequence.- The
relay_*outputs - only relevant if your pipeline uses prompt relay; otherwise ignore them.
Install and practical notes
Standard IAMCCS-nodes install - ComfyUI Manager (search "IAMCCS") or:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Restart, done. No model files, no pip extras. ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.
Two things trip people up. First, the start/end images are loaded from the paths baked into the shotboard, so if you move files after planning, the node throws on a missing path - check the report output for the resolved path. Second, prompt falls back to the board's global prompt when a chunk has none, so an "empty" chunk quietly renders with the default text. If a segment looks wrong, confirm the pair you're on: chunk_index is 0-based, and mismatched loop counters are the classic off-by-one.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| timeline_plan | IAMCCS_WAN_TIMELINE_PLAN | — | |
| chunk_index | INT | 00–999 | — |
Outputs (14)
| Name | Type | Description |
|---|---|---|
| start_image | IMAGE | — |
| end_image | IMAGE | — |
| prompt | STRING | — |
| frames | INT | — |
| motion | FLOAT | — |
| frame_rate | FLOAT | — |
| chunk_index | INT | — |
| chunk_count | INT | — |
| report | STRING | — |
| relay_local_prompts | STRING | — |
| relay_segment_lengths | STRING | — |
| relay_max_frames | INT | — |
| relay_epsilon | FLOAT | — |
| relay_timeline_data | STRING | — |