RVK Wan Animate 2 Loop Entry

This is the brain, not a utility node

Every long-video trick in ComfyUI is the same trick underneath: cut the timeline into native-length windows, generate them one after another, stitch. Wan Animate's native window is 81 frames, and the community consensus is that quality drifts as you chain batches - fine at one, visible by three.

The part that always sucked was the manual labour. Window the driving video by hand, remember which frame you ended on, queue segment 4, forget, come back two hours later. RVK Wan Animate 2 Loop Entry is the node that does the bookkeeping and queues its own next prompt. You press Queue once.

How it actually works

On execution the node probes drive_video, reads its frame count and exact fps (as a fraction, not a float), and computes how many segments the run needs. For each segment it hands you a planned window rather than making you slice one:

• pose_video_window - this segment's slice of the driving video, as a VIDEO. That goes into the Motion Transfer subgraph's driving-video input.
• length - the INT the subgraph samples at.
• continue_motion - the IMAGE continuation seed from the previous segment (an empty/first-frame case on segment 0).
• video_frame_offset - where this segment starts on the original timeline.
• plan, run_token, segment_index, delivery_frames, fps, output_directory - the plumbing outputs; plan goes to Collect and Advance, fps, segment_index and output_directory go to Save, output_directory also goes to Finalize.

The plan itself is where the continuity lives. Segment 0 starts at frame 0 and keeps everything. Every later segment starts at next_offset - 1 - one frame of overlap - and that single frame gets trimmed off on the way out by RVK Wan Animate 2 Collect. Minimal overlap, no duplicated frames in the delivered video, and only one raw frame ever cloned as the handoff.

The loop runs in the frontend. The pack ships a JS extension that listens for execution events, checks the run_token widget still matches the live workflow, and calls ComfyUI's queue function again for the next segment. That's also where the Stop RVK after current segment button comes from - it POSTs a stop request to the backend, the current segment finishes, and Advance reports has_more: false, which lets Finalize assemble. If you're wondering why a node has a hidden unique_id, prompt and extra_pnginfo: that's the wiring it needs to identify its own workflow.

The inputs you set

• drive_video - your full, untrimmed driving video. It must be a file-backed, constant-frame-rate video with an exactly representable frame timeline; that's a hard constraint of the whole pack, since Finalize compares audio and frame counts against it. Include audio if you want sound at the end.
• segment_length - default 81, step 4, allowed 5 to 16381. The step and the range are the Wan VAE's 4k+1 requirement (it compresses time roughly 4×, so only certain frame counts decode back cleanly). Longer segments mean fewer seams and more VRAM.
• output_directory - a fresh, relative directory under ComfyUI's output folder. If it contains any existing file, the run is rejected before a single model loads. Protection, not rudeness.
• run_token - managed by the frontend. Leave it alone. Clearing it is the documented way to start a new run.

Install and launch

Manager → Richard's Video Kits (or richards-video-kits), version 1.0.0, then restart. Manual route:

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

Only one copy of the pack. No pip dependencies (its pyproject.toml declares none), but the author pins ComfyUI ==0.36.0 and tests on Windows/NTFS with Python 3.12, frontend 1.52.7, launched with --cache-classic. Start it that way:

python main.py --cache-classic

Then import examples/wan_animate2/wan_animate2_rvk_loop.json. It carries one editable official Motion Transfer (Wan Animate 2) subgraph - models are referenced, never bundled or auto-downloaded. On 16 GiB cards the example runs WanAnimate2Cache with device=cpu, which trades speed for VRAM headroom.

Where people get burned

• Touching the graph mid-run. The extension re-queues the live workflow, so editing inputs, swapping a model, or rewiring while it's going can change what segment 7 actually is. The author's instruction is blunt: queue once and leave it open. Switching workflows or closing the tab kills the continuation.
• Expecting a resume. The loop state is in the process's memory, not on disk. Crash, restart, or leaving it idle past the run's 30-minute TTL and the handoff frame is gone. Completed segments survive; generation does not resume, and a fresh run needs a new empty directory.
• Re-running into a used directory. "Every segment already exists" is what you'll see. Use the standalone finalization workflow instead - it does no inference and just needs the same source video plus the segment directory.
• Forgetting the flag. Loaded without --cache-classic, this is off the tested configuration. It's also off it on any ComfyUI much newer than 0.36.0, which is what the pack pins.

Licence note: PolyForm Noncommercial 1.0.0. Source-available, not open source - commercial work needs permission from the author.