LVCD Decoder

The sampler doesn't make video. It makes latents - a compressed, noisy-feeling representation that lives in a different space from pixels. This node is the bridge back to something you can look at and save: it takes the SVDSAMPLES from the LVCD Sampler, runs them through the VAE, and hands you a normal IMAGE batch you can wire straight into a video encoder or SaveImage. In a normal image workflow the decode step is invisible to you; here it's a node with its own tuning, because decoding long video is where the VRAM blows up.

That's the whole reason this node exists rather than just being a checkbox. LVCD extends SVD past its fixed-length window during sampling, and the decoder has to handle that longer latent sequence without OOMing. It does it by tiling the decode - that's what decoding_t, decoding_olap, and decoding_first are about. Instead of decoding 40 frames in one gulp, it decodes in chunks, overlaps the seams, and blends them together so you don't see tile boundaries. The "Overlapped Blending Module" from the LVCD paper, shipped as three integers.

What you set

Four inputs, and only one of them is worth touching on most runs:

• LVCD_pipe - the same pipe object from Load LVCD Model. The decoder pulls the VAE (first_stage_model) out of it, so yes, you need it even though the pipe feels redundant by now.
• samples - the SVDSAMPLES output of the LVCD Sampler. This is the data.
• decoding_t - default 10, min 1, max 100. How many frames the VAE decodes per tile. The core knob: lower it (down toward 4-8) if you're hitting out-of-memory on long clips; raise it if your card has headroom and you want fewer, bigger tiles.
• decoding_olap - default 3. Overlap between decode tiles so the seams blend instead of showing a line. Leave it alone unless you can see artifacts where tiles meet.
• decoding_first - default 1. How many frames get decoded in the first pass before tiling kicks in. The bundled example uses 1; the default is also 1, so the practical guidance is "don't touch it."

The output is a single images socket of type IMAGE - a batch where each entry is one frame. The node also normalizes the decoded frames to 0-1 before it returns them, so you don't have to deal with the raw VAE range.

Wiring it up

In the pack's example workflow, the IMAGE output feeds VHS_VideoCombine from VideoHelperSuite, which writes the frames to an actual MP4 - set your frame rate (the example uses 8) and a prefix and you're done. You could equally use it with SaveImage per frame, or feed the frames into anything else that consumes an IMAGE batch. This is a terminal-ish node: nothing consumes its output inside this pack, and there's nothing between it and your video file.

The grounded stuff

Install is identical to the other two nodes in this pack - ComfyUI Manager search "LVCD", or git clone https://github.com/kijai/ComfyUI-LVCDWrapper into custom_nodes, restart, and make sure the pack's real dependencies (omegaconf, clip from the OpenAI repo, open-clip-torch, pytorch-lightning, timm) are present. The models you need - an SVD checkpoint in models/checkpoints and the LVCD adapter in models/lvcd - are already loaded by the time you get here, so the decoder itself adds no model downloads.

The failure mode to expect: out-of-memory during decode. It's the most common complaint with any SVD-family pipeline, and it's why decoding_t exists. If a long clip dies with a CUDA OOM, cut decoding_t in half before you start optimizing anything else - you're trading a few decode passes for the difference between a completed video and a frozen graph. And if your decoded frames look washed out or wrong, that's a sampling-side problem (check precision on the loader, or your cond_aug), not a decoder bug - the decoder just normalizes and hands back what the VAE gives it.

For such a small node it's the boring reliable end of the pipeline, which is exactly what you want: the sampler is where you tune, the decoder is where the video finally shows up.