Wan Video SEI Decode

This is the last stop before you get actual video frames out of the pipeline: WanVideoSEDecode takes the latent WanVideoSESampler produced and turns it back into images via the VAE. Wire its output into a video-combine node downstream and you've got your clip.

How it works

Standard VAE decode with one notable difference from a typical version: it requires your original start and end images back as inputs, not just the sampled latent. That's unusual for a decode step, but it tracks with what this whole pack is built around - the point of the fork is anchoring generation to two fixed frames, and decode is where that anchoring gets reconciled against your actual source pixels rather than just the model's latent-space approximation of them.

The inputs and outputs that matter

• vae - from WanVideoSEVAELoader.
• samples - the LATENT from WanVideoSESampler.
• start and end - your original source images, required, the same ones you fed into WanVideoSEImageClipEncode earlier in the graph.
• enable_vae_tiling (default on) - its tooltip is direct: "Drastically reduces memory use but may introduce seams." This is the main VRAM lever on this node.
• tile_x / tile_y (default 272) and tile_stride_x / tile_stride_y (default 144 / 128) - only relevant when tiling is on. Smaller tiles use less VRAM and are more likely to show seams; the stride values control how much adjacent tiles overlap.

Output is images, typed IMAGE.

How to install it

ComfyUI Manager, search "ComfyUI-WanVideoStartEndFrames," install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/raindrop313/ComfyUI-WanVideoStartEndFrames

Nothing decode-specific to download beyond the Wan VAE file this pack already needs for WanVideoSEVAELoader - get it per Kijai's ComfyUI-WanVideoWrapper instructions, which is what the README points to for every model file in this pipeline.

Common issues & troubleshooting

Running out of VRAM on decode. Wan video decode is memory-hungry, and disabling enable_vae_tiling for cleaner output comfortably wants a 24GB-class card. Leaving tiling on is the safe default for most consumer setups; if you turn it off and run out mid-decode, that's expected, not a bug - turn tiling back on.

Visible seams with tiling on. Try raising tile_stride_x / tile_stride_y relative to the tile size first - more overlap costs more compute but blends the seams better. Shrinking the tiles further tends to make seams worse, not better, so that's not the fix.

Decode output looks wrong even though sampling looked fine. Double-check start and end are wired to the same images used at the encoding step earlier in the graph. This node isn't decoding those images independently - it's using them as required reference inputs alongside your sampled latent, so a mismatch there will show up in the output.