WAN VACE Keyframe Control Prep

If you've run WAN VACE more than once, you've hit the wall: it only accepts frame counts of the form 4n+1 - 1, 5, 9, 13, and so on. There's a reason. The Wan VAE squashes time roughly 4x, so N frames become ((N-1)//4) + 1 latents, and what comes back is (T-1)*4 + 1. Your 81-frame clip is fine. Your 80-frame clip errors out, or worse, silently comes back a frame count you didn't ask for. That's the trap this whole node exists to disarm.

WanVACEKeyframeControlPrep (from the DOGMA Nodes pack) does two jobs at once. First, it bakes your reference images into the control video at the frames you pick, and blanks the mask at those same frames - the classic trick for pinning identity or posing at specific moments of a VACE run. Second, it pads the sequence up to the nearest valid 4n+1 count by duplicating the first and last frames, so VACE stops choking on your length. And it hands you a small metadata object so a sibling node can strip that padding later.

What goes in

You feed it four things, and only the last one needs any thought:

• video - your control video as an IMAGE batch (pose, depth, whatever VACE will consume).
• mask_video - the control mask batch, same length as the video.
• reference_frames - the images you want locked in. A single frame or several.
• keyframe_indices - a STRING like "start, 25, end". The author's own tooltip says it all: comma/space/semicolon separated, supports start/end, and indexing is 0-based. So 24 is the 25th frame, not the 24th. The default "start, 25, end" is a decent starting point if you just want the bookends and one mid point locked.

What comes out

• control_video and control_mask_video - your prepped batches, now 4n+1 long and with the keyframes swapped in / mask blacked out.
• frame_count - the padded length. Use this to check what the node actually produced, because the parser is forgiving.
• padding_info - a WANVACE_PAD_INFO dict recording how much was added where. Wire this straight into WAN VACE Remove Added Padding after generation.

How it actually works

The node parses your indices, and here's the detail that matters: keyframes are applied once, then re-applied after padding, shifted by the pad count. The padding duplicates the first and last frames, so the node re-sets your exact requested frames at their new positions rather than letting a duplicated frame clobber them. Odd padding counts lean toward the start (one extra at the front). Reference frames that don't match your video's resolution get bilinearly resized, so you don't have to pre-crop them.

Where people get burned: more reference frames than indices means the extras are silently dropped; garbage tokens or out-of-range indices are silently skipped; and if your mask and video have different lengths, the node works on the shorter of the two and you quietly lose frames from the longer one. None of these crash - they just surprise you downstream. When in doubt, check the frame_count output.

Install

Install the pack once via ComfyUI Manager (search DOGMA Nodes), or:

cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes

then restart ComfyUI. No model files, no extra Python packages - it's pure PyTorch, which ComfyUI already ships. That's the nice thing about this pack: zero install friction, and the node is honestly small enough that you could roll it by hand. The value is that it's repeatable and it emits the padding_info you'd otherwise have to track yourself.