📊 Auto Loop Calculator (WanVideo 3dVAE)

Wan's 3D causal VAE has a quirk that costs people frames and sanity: its temporal compression likes frame counts that are one more than a multiple of four - the "4n+1" rule. Ask it for 48 frames and the VAE's compression ends up dropping or mangling the tail; ask for 49 and it's clean. When you're chunking a long source video through the loop pattern, every single chunk has to respect that rule, which is miserable arithmetic to do by hand across a ten-cycle render.

AutoLoopCalculatorWan is the pack's Wan-specific chunk scheduler: same job as the base calculator - produce chunk_frames and skip_frames per cycle - but everything gets snapped to the 4n+1 rule so the VAE never sees a hostile count.

How it works

It walks the same global accumulated-frame position as the other calculators, with Wan's constraints baked in:

• Every chunk is rounded up to 4n+1 frames (minimum 5).
• target_frames_per_loop is stepped in 4s (default 48) and gets proportionally rebalanced so the full video splits into even-ish loops instead of leaving a distorted final chunk.
• It tracks the physical frame limit of the source and pads requests to a valid 4n+1 count even when that exceeds what's left - the pack's VAE Safe Frame Padder clones the last frame to fill the gap, so the VAE gets a legal tensor and the extra frames are discarded later.
• Scene cuts and face-cut boundaries are snapped to the rule too: it cuts at the boundary, then rounds the chunk up to the next valid count.

It also flags the final chunk via the pack globals, which is what tells the loop trigger "this is the last one."

Inputs and outputs

• source_frame_count (INT) - from the video analyzer.
• target_frames_per_loop (INT, default 48, min 4, step 4) - chunk size ambition; the node rebalances it.
• select_every_nth (INT) - frame skipping for fps limits.
• current_loop_index (INT) - from SequentialLoopStart.
• Optional safe_faces_list (FACE_CUTS) and scene_cuts_list (SCENE_CUTS).

Outputs: chunk_frames, skip_frames, select_every_nth, and log (which is unusually good here - it tells you when it padded and by how much).

Why the rule bites

Wan 2.1/2.2's native context is roughly 81 frames; anything longer is chunking by definition, and identity drift across chunks is real. The 4n+1 rule is the other trap that's purely mechanical: it's not about quality, it's about the VAE's temporal compression window. If you've ever had a Wan render silently drop the last three frames of a chunk, this is the node that stops it. Use the Wan variant for Wan, the LTX variant for LTX - they're not interchangeable.

Install

ComfyUI Manager → search "comfyui-sequential-batcher", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Meisoftcoltd/comfyui-sequential-batcher

Restart ComfyUI. No extra model downloads. And the pack's house rule: don't launch ComfyUI with --highvram, or the memory purge between loop cycles is blocked and long Wan renders tend to OOM anyway.