RVK Wan Animate 2 Collect

The 90 seconds after your VAE decode

RVK Wan Animate 2 Collect has no widgets, no settings, and nothing to tune. It sits immediately after the raw VAE decode and answers two questions: which of these frames are actually mine, and what one frame carries the motion into the next segment?

If you've ever chained Wan clips by hand, you know why that's not trivial. You generate a window, you get back a slightly different number of frames than you asked for because of the 4n+1 temporal constraint, you have an overlap frame you already delivered in the previous segment, and you're left nudging a trim node until the arithmetic works. Collect is that arithmetic, formalised.

How it works

It takes raw_images and the plan from RVK Wan Animate 2 Loop Entry, and slices:

• Front: one frame is dropped on every segment except the first. That's the overlap frame the plan deliberately re-generated at next_offset - 1; dropping it here is what keeps the delivered video free of duplicated frames.
• Tail: the slice stops at the plan's valid raw frame count - min(segment_length, total_frames - start) - which throws away the padding the sampler added to reach a legal length, and, on the final segment, stops exactly at the last real frame of your driving video. No overrun.

What falls out is delivery_images: exactly the new frames for this segment, nothing doubled, nothing padded. It goes straight into RVK Save Segment Video.

The second output is the interesting one. continuation_candidate is a single frame - detached, cloned to CPU, contiguous, one frame, not a batch, not the last five frames. Advance validates it hard and stores it for the next segment. It is the entire continuity state of the run.

The author's instruction is not decorative: place this directly after the raw VAE decode, before any trimming, upscaling, or interpolation. The frame math assumes the batch it receives is the raw decode at the planned length. Anything that changes the frame count upstream - a RIFE interpolation pass, a trim node you added to "tidy up" - breaks the plan, and you'll get an error instead of a quietly short segment. Interpolation and upscaling belong after Collect, on the delivery frames.

Why one frame and not five

Hand-rolled Wan continuation usually passes several frames back so the model has context, and more overlap often seems safer. In practice people report colour and saturation drifting between chained clips, and the advice that circulates is to keep overlap tiny - a couple of frames at most. RVK's bet is that the handoff frame plus the model's own continuation conditioning is enough, and that minimizing the re-fed content minimizes the compounding error.

Be honest about what that buys you. It does not make drift disappear. Wan Animate's quality starts degrading after the first 81-frame batch and is usually noticeable around the third - that's a property of the model, and no wrapper around it fixes that. What Collect gives you is a chain where the only thing crossing a boundary is one frame, plus a segment file on disk after every step, so a bad batch costs you one segment instead of a whole run.

Wiring

• raw_images ← the raw VAE decode output of the Motion Transfer subgraph.
• plan ← plan on RVK Wan Animate 2 Loop Entry (the same plan wire also feeds Advance - fan it out).
• delivery_images → images on RVK Save Segment Video.
• continuation_candidate → continuation_candidate on RVK Wan Animate 2 Advance.

An output node it is not, so it never reports to the UI on its own; and like the rest of the pack it's non-idempotent, meaning it re-executes every queue rather than being cached.

Install

Manager → Richard's Video Kits / richards-video-kits, version 1.0.0 → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Richard-Wang-fs/ComfyUI-RichardsVideoKits

Keep one installation only - two copies of the pack under custom_nodes is a documented conflict - and restart with --cache-classic, which is the configuration the author tested (Windows, Python 3.12, ComfyUI 0.36.0, frontend 1.52.7). No pip dependencies and no model downloads; the pack carries no weights.

Where people get burned

• A short segment instead of an error. That's the tell that something between the decode and Collect changed the frame count. Pull out the node you added and put it after Collect.
• "Continuation must be one independent contiguous CPU image." You wired something else into Advance's continuation_candidate - a batch of frames, or a tensor still on the GPU. It has to be Collect's output.
• Deleting the segment files to "clean up" while testing. The delivered frames are the only copy of that window's work; the continuation frame in RAM won't rebuild them. And since nothing is persisted, a restart mid-run loses the handoff entirely - a fresh start needs a fresh empty directory.