IAMCCS SCAIL Extend Plan
SCAIL-2 wants a plan before it wants your GPU — do the chunk math first
- effective_frames
- trimmed_frames
- chunk_count
- chunk_plan
SCAIL-2 runs in 81-frame chunks natively. It also takes minutes per clip on a good GPU. That combination means you should know exactly how many chunks your driving video is going to cost before you hit queue - and this node is the calculator that tells you. It's called "Extend Plan" and it does one thing: pure chunk math, zero sampling, no GPU involved.
Why this matters: SCAIL-2 was built around an 81-frame window, and everything longer gets chopped up and chained. The failure mode people actually hit is identity drift across chunk boundaries, so the way you split matters as much as the length. IAMCCS_ScailExtendPlan is the planning half of the pack's SCAIL-2 pair - the sibling IAMCCS_ScailExtends does the real sampling, and you can feed this node's chunk_plan output straight into it.
What it actually computes
Three inputs, four outputs, nothing else:
source_frames- your driving video's total frame count.chunk_length(default 81) - max frames per SCAIL chunk. Leave it at 81; that's what the model was designed around.overlap(default 5) - how many anchor frames from the previous chunk carry over. SCAIL's own default is 5.
Internally it rounds both chunk_length and overlap to the 4n+1 shape SCAIL-2 expects, then lays out the chunks. You get back effective_frames (how many of your source frames actually survive into generation), trimmed_frames (the difference - frames lost to the overlap), chunk_count, and chunk_plan, a comma-separated string of per-chunk lengths. That last one is the piece you wire downstream or just eyeball in a preview.
The one error to know: chunk_length has to exceed overlap by at least 4, or it refuses. That's not a bug - the anchor needs room to be an anchor.
Where you'd use it
Say your driving clip is 650 frames. At 81-frame chunks with 5-frame overlap, you're looking at eight chunks and roughly a dozen-plus GPU-minutes per full pass. It's cheaper to discover that number in a widget than after the first chunk has already burned ten minutes. Stick this node before IAMCCS_ScailExtends, read chunk_count, and decide whether to trim the source or accept the runtime before you queue anything.
Install
It ships in IAMCCS-nodes, so it's one install for the whole family:
- ComfyUI Manager → search "IAMCCS" → Install, then restart.
- Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Then restart ComfyUI. The pack wants ComfyUI ≥ 0.3.0, Python ≥ 3.12, and Torch ≥ 2.8 - nothing exotic, and this node in particular is just integer math, so it runs anywhere the pack does.
Gotchas
Honest note: because chunk_length and overlap snap to 4n+1, your visible per-chunk frame counts won't always match what you typed. That's intentional - SCAIL-2's temporal compression wants that shape. And if you see trimmed_frames climbing, you're paying for overlap; that's the price of continuity, not a leak. If your total runtime still surprises you, it's SCAIL-2 being SCAIL-2, not this node being wrong.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| source_frames | INT | 811–100000 | — |
| chunk_length | INT | 819–1024 | — |
| overlap | INT | 51–81 | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| effective_frames | INT | — |
| trimmed_frames | INT | — |
| chunk_count | INT | — |
| chunk_plan | STRING | — |