WanVideo Add OneToAll Extend Embeds

This node is part of the long-video machinery - the stuff that gets you past Wan's 81-frame wall without hand-stitching clips. It handles the windowing for a "OneToAll" extend workflow: given the latents you've already generated, it figures out the next window of frames to produce, carries an overlap so the seam blends, and injects that into your Wan embeds. You run it in a loop and the clip grows.

The KB is refreshingly honest that this is what the whole long-Wan ecosystem actually is: "the native context is still 81 frames and has not moved. What changed through 2026 is the workflow burden" - people wrapped the chain-and-restitch loop into nodes so you ask for N frames and the node does the window math. This is one of those nodes. It's not magic length; it's automated bookkeeping over the same 81-frame ceiling.

How it works

It reads your previously-generated latents, slices out a window of a given size, overlaps it with what came before so motion is continuous, and produces embeds for generating the next chunk. It also slices the matching pose images if you're driving the extension with poses, so the control stays aligned with the frames being produced. The if_not_enough_frames setting decides what happens at the tail when there aren't enough frames left to fill a full window.

The inputs that matter

• embeds (WANVIDIMAGE_EMBEDS, required) - the embeds being extended.
• prev_latents (LATENT, required) - the latents already generated; the source the window is cut from.
• window_size (default 81) - how many frames per window. Matches Wan's native context; don't casually raise it past what the model handles.
• overlap (default 5) - how many frames each window shares with the previous one. More overlap = smoother seams but slower progress (you re-generate more shared frames). Five is the sane default the community converged on.
• frames_processed (default 0) - where you are in the sequence; the loop advances this so successive calls grab successive windows.
• if_not_enough_frames (pad_with_last or error) - tail handling. pad_with_last repeats the final frame to fill the window; error stops so you notice the ragged end instead of silently padding.

Outputs:

• image_embeds (WANVIDIMAGE_EMBEDS) - for the sampler.
• pose_slice (IMAGE) - the aligned pose frames for this window, if you passed pose_images.

The optional pose_images (IMAGE) input is for pose-driven extension; skip it for plain continuation.

How to install it

Ships in Kijai's WanVideoWrapper. ComfyUI Manager: search ComfyUI-WanVideoWrapper, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt

then restart. No download for the node; it's loop logic over your own latents. You need a working Wan generation to feed it and, for pose-driven runs, a pose source.

Common issues & troubleshooting

Identity drifts across windows. This is the failure mode of every chunked-extension method, and the KB names it repeatedly - "identity drift across chunk boundaries is still the failure mode." A bigger overlap helps the seam but doesn't fully fix drift; that's a limitation of the approach, not this node.

The clip comes back short. Wan's VAE compresses time ~4x, so valid frame counts follow the 4n+1 pattern. If your window math lands off that, you lose a frame or two per chunk. The KB's "111 frames → 28 latents → 109 frames" example is exactly this. Keep window and overlap on sane 4n+1-friendly values.

Ragged tail or a crash at the end. That's if_not_enough_frames. pad_with_last gives you a frozen last frame rather than a crash; error is the honest option if you'd rather fix the length than pad it. Pick based on whether a padded tail is acceptable.

Poses desync from frames. If you're driving with pose_images, use the pose_slice output - it's the slice aligned to the window being generated. Feeding the full pose sequence instead of the slice is how control drifts out of step.