Stable Video Diffusion Decoder

Last stop in the pipeline. SVDSampler hands you a LATENT - a compressed, un-viewable representation of the video - and SVDDecoder turns it into an actual stack of image frames you can watch and save. It's the third of the three nodes in thecooltechguy's SVD pack (SVDModelLoader → SVDSampler → SVDDecoder), and while it's the least glamorous of the trio, it's also the one most likely to blow up your GPU. Worth understanding before it ruins a run.

A word of orientation: Stable Video Diffusion is Stability AI's November 2023 image-to-video model, their first video model. It mattered a lot at the time and has since been overtaken by Wan 2.2 and LTX. This node doesn't change with the tides - decoding is decoding - but it's the reason a lot of SVD runs die at the finish line, so it's worth knowing.

How it works

SVD does its diffusion in a compressed latent space to keep the compute manageable - the sampler never works in full pixels. The decoder reverses that compression, running the model's decoder over the latent to reconstruct each frame at full resolution. Because it's rebuilding every frame's pixels, the decode step is memory-hungry in a way the sampler isn't: it's frequently the exact point where a workflow runs out of VRAM. Good news is there's a knob for precisely that.

The inputs that matter

• samples_z - the LATENT from SVDSampler. This is the video the decoder converts to pictures. Required.
• model - the MODEL from SVDModelLoader. Same loaded model the sampler used; the decoder needs it too. Required.
• decoding_t (default 14) - the parameter on this node. It controls how many frames get decoded at once. This is a pure VRAM lever: decoding all frames simultaneously is the memory spike, and lowering decoding_t decodes them in smaller batches instead. Quality is unaffected - you're only trading speed for headroom. If your run keeps dying at the decode step, this is the first and usually only thing to change.
• device (cuda or cpu) - leave it on cuda.

The output is IMAGE: a batch of frames, one per generated timestep. That batch doesn't play itself - you wire it into a video-combine or save node (something that stitches frames into a webp/mp4/gif) to get a file. This is also the natural place to insert frame interpolation: run the IMAGE batch through a RIFE interpolation node before combining, and you turn SVD's ~14 or ~25 raw frames into a smoother, higher-FPS clip. The pack's own example workflows do exactly that.

How to install it

• ComfyUI Manager - search ComfyUI Stable Video Diffusion (author thecooltechguy, of comfyworkflows.com), install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/thecooltechguy/ComfyUI-Stable-Video-Diffusion, then cd ComfyUI-Stable-Video-Diffusion && python install.py, and restart.

The manual install.py is a custom installer that drags in Stability's dependency stack, so it's heavier than a plain requirements file. And nothing runs until the weights are in place: download the SVD checkpoints from HuggingFace into ComfyUI/models/svd/. They're multi-gigabyte files.

Common issues & troubleshooting

Out of memory at the decode step. This is the headline failure mode, and the fix is decoding_t. Drop it - try 8, then lower - and the decoder processes fewer frames per batch. It's slower but it survives, and your output looks identical either way. This is by far the most common reason an otherwise-fine SVD run dies right at the end.

The output looks like static images, not a video. That's expected - the node outputs a batch of frames, not a movie file. You need a downstream node to combine them into a playable clip. If you skip that, ComfyUI just shows you a grid of stills.

The clip is choppy / too few frames. SVD only generates ~14 (base) or ~25 (XT) frames, so it's inherently short and low-FPS. That's not a decoder bug. Feed the IMAGE output through a RIFE frame-interpolation node before you combine, which is what the pack's high-FPS example workflow does - it multiplies the frame count so playback looks smooth instead of jerky.

Wrong model wired in. The decoder wants the same MODEL that came out of SVDModelLoader and fed the sampler. Cross-wiring a different model here - or forgetting the connection entirely in a hand-built graph - throws an error at decode time.