Sliding Window Options

AnimateDiff's motion module was trained on 16-frame clips, full stop. That's baked into the weights, not a setting anyone can just raise. What actually lets you generate a 100-frame animation instead of a 2-second clip is a workaround: chop the full sequence into overlapping 16-frame windows, denoise each window with the same coherent-motion machinery, and stitch the results together using the overlap to smooth the seams. This node is where you control that chopping process. Leave it disconnected in AnimateDiffSampler and the pack applies sensible defaults automatically once your frame_number goes past 16 - plug this node in when you want to actually tune it.

It's also, worth knowing, the mechanism behind AnimateDiff's old reputation for being able to loop and run at "arbitrary length" - claims you'll still see in older threads and tutorials. That capability lives specifically in how these windows are scheduled, which is exactly what this node exposes.

The inputs and outputs that matter

• context_length (default 16, range 2–32) - frames per window. The README's own advice: use 16 for the best results, since that's the module's native training length; only reduce it if you're VRAM-constrained, and expect some quality loss for doing so.
• context_stride (default 1, range 1–32) - not simple frame-skipping. A value of 1 samples every frame; 2 samples every frame, then every second frame; 3 adds every third frame on top of that, and so on. It's a layered sampling pattern rather than a plain skip interval - the default of 1 is the safe, dense choice, and most people never need to touch this.
• context_overlap (default 4, range 0–32) - how many frames each window shares with its neighbor. This is what smooths the transition between windows; too little overlap and you risk visible seams where one window hands off to the next.
• context_schedule - currently a single choice, "uniform". There's nothing else to pick here today; it exists as a setting slot rather than a real decision point.
• closed_loop (default false) - makes the generated clip loop back on itself. The README is upfront that this costs you: it "will add more sampling step[s]," so expect slower generation in exchange for a clip that plays cleanly on repeat.

Output: SLIDING_WINDOW_OPTS - wire it into AnimateDiffSampler's optional sliding_window_opts input.

How to install it

Bundled with the pack.

Via ComfyUI Manager: search "comfyui-animatediff" and install.

Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ArtVentureX/comfyui-animatediff

Restart ComfyUI. No extra model downloads for this specific node - it's pure sampling configuration, not something that reads model files.

Common issues & troubleshooting

Changing these settings did nothing. Check frame_number on your AnimateDiffSampler - the sliding window mechanism only activates once you're generating more than 16 frames. Under that, the whole sequence fits in one native window and there's nothing for this node to chop up.

Visible seams or jitter where the animation seems to "reset." Try raising context_overlap - more shared frames between adjacent windows generally means a smoother handoff, at the cost of some extra compute since those overlapping frames get sampled more than once.

Long clips are slow, or you're running low on VRAM. Lower context_length below 16 rather than raising it - VRAM usage scales with the window size, not the total clip length, so a shorter window is the lever that actually helps, at some cost to per-window motion quality.

You want a loop and it's coming out choppy anyway. closed_loop gets you a clip that plays cleanly on repeat, but it's not free - combine it with a reasonable context_overlap rather than leaving overlap at the low end, since the loop seam is itself a window boundary that benefits from the same smoothing. And keep expectations honest: this produces AnimateDiff's own morphing style of loop, not a photographically clean one - that's the tradeoff people were making with this node back when "AnimateDiff can loop and nothing else can" was still true. Newer Wan-based tooling has since caught up on that specific claim, so if you're chasing loop quality rather than AnimateDiff's particular look, it's worth knowing there's now a Wan-side alternative.