WanVideoVaeDecode

Every Wan user hits this eventually: you ask for 81 frames, and the clip comes back 80 - or with a frozen frame stuck on the front that you never prompted for. It's not the model being sloppy. It's the Wan VAE compressing time roughly 4x, plus the keyframe-padding trick this pack uses to pin your start/end images, and a plain VAE Decode node doesn't account for either. WanVideoVaeDecode is the pack's replacement decode that knows about both, so you get back exactly the frames you asked for.

How it works

Two things happen in one node. First, it decodes the latent with the VAE's tiled decoder (decode_tiled - tile 512 with spatial overlap, and a temporal tile of 64 with an 8-frame temporal overlap, adjusted automatically to the VAE's compression factor). That's the memory-friendliness: a whole Wan clip can blow past VRAM in one shot, and tiling keeps peak usage down. Long or high-res clips are exactly where this beats the stock decode node.

Second - and this is the part with actual logic - it trims the decoded frames according to the generation mode and a frame-shift offset. The pack's encode-side nodes pad the clip with duplicated keyframe padding (that first_end_frame_shift value you set on WanFirstLastFirstFrameToVideo), so a naive decode hands you a clip with extra copies of your start/end images glued to the ends. This node slices them back off. The 4x temporal compression also means the latent's frame count doesn't map 1:1 to output frames - N latents decode to roughly (N-1)*4+1 frames - which is the "one frame short" mystery. The node's math accounts for it.

The inputs that matter

• latent - the video latent to decode, straight out of the sampler.
• vae - the Wan VAE (the 16-channel one that ships with the model; Wan's VAE is not interchangeable with an SD VAE).
• first_end_frame_shift - default 3. This must match the shift the encode side used. Each unit adds 4 frames of padding to account for, so getting it wrong leaves duplicated keyframes at the ends.
• generation_mode - the dropdown from WanVideoGenerationModeSelector: Start Image, Start to End Image, End to Start Image, or Start to End to Start Image. It decides whether to trim from the start, the end, or both. This is the exact value the selector node exists to share.

Output is a single IMAGE wire - the trimmed, decoded frames ready for your preview, video-combine, or save node.

Install and gotchas

From przewodo/ComfyUI-Przewodo-Utils: ComfyUI Manager search "ComfyUI-Przewodo-Utils", or

cd ComfyUI/custom_nodes
git clone https://github.com/przewodo/ComfyUI-Przewodo-Utils.git

then restart. No model downloads - it uses the Wan VAE you already loaded.

The one real trap is mode drift: the generation_mode and first_end_frame_shift here have to match what the encode side used, or your trimming is wrong and you're back to mystery frames. That's precisely why the pack's WanVideoGenerationModeSelector exists - wire its output into both the encode and this decode node and the two can't disagree. If you're decoding a latent from a workflow that didn't pad (text-to-video, or a stock Wan sampler), set the shift to 0 and the mode to Start Image and you'll get a clean decode with no trimming. If you're still seeing a couple of short frames after that, you're probably hitting the 4n+1 frame-count rule and should generate on a proper Wan-valid length instead.