WAN VACE Remove Added Padding

This is the bookend. WAN VACE Keyframe Control Prep pads your clip up to a 4n+1 frame count so VACE will accept it - which means whatever comes back from generation is that padded length, not the clip you actually wanted. If your next step is cropping, stitching into a longer sequence, or anything that's length-sensitive, those duplicated frames at the head and tail will bite you. WanVACERemoveAddedPadding is the cleanup pass: it trims them back off and hands you the exact frame count you started with.

It's the simplest node in the DOGMA Nodes pack, and it only exists because its sibling stores metadata in a way nobody else does. The whole point is symmetry - prep adds, this removes, and both stay in lockstep because they share the WANVACE_PAD_INFO object.

What goes in

• video - whatever WAN VACE generated, as an IMAGE batch.
• padding_info - the WANVACE_PAD_INFO dict straight out of WAN VACE Keyframe Control Prep. This is the important wire: don't hand-build it, don't grab it from another run.

The classic wiring is:

WAN VACE Keyframe Control Prep → padding_info ─────────────┐
                                    │                      │
                                    └→ (to generation)     │
WAN generated video ────────────────────────────────────→ WAN VACE Remove Added Padding

What comes out

• video - the trimmed batch at your original frame count.
• frame_count - the restored length, handy for feeding a crop or stitch step that needs to know how many frames it's dealing with.

How it works

The padding_info dict records pad_start, pad_end, and original_length from the prep pass. This node just slices video[pad_start : len - pad_end], then, if the result is still longer than original_length, truncates to that. It's defensive about it too: if you feed it a video without a valid padding_info dict it passes the video through unchanged, and if the math would produce a negative or empty range it bails and returns what it got rather than crashing mid-graph.

The practical gotcha is the one this design implies: the padding_info has to match the run that padded the video. If you regenerate the video with a different seed or a different prep config, don't reuse the old padding_info - the pad amounts could be identical, but you have no way to know, and a mismatch just means you silently slice a few frames too many or too few off the start. Make the prep node and this node sit in the same workflow and you'll never have to think about it.

Install

Same pack, same one-time setup. ComfyUI Manager → search DOGMA Nodes, or:

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

then restart. No extra dependencies - pure PyTorch, which is already there. You could absolutely write the slice yourself in a tiny script node, but then you're re-deriving the pad amounts by hand and re-introducing exactly the off-by-one errors this node exists to remove. For a two-frame, two-node workflow, just use the pair.