STAR VAE Decode

STAR Sample does the expensive diffusion work in latent space - compressed, abstract, cheap to move around. But latents are not pixels, and pixels are what you can look at. STAR VAE Decode is the node that turns the STAR latent back into actual video frames, and it exists as its own step so that how you decode never makes the sampler run again.

The mechanics are simple in shape: it takes the latent from STAR Sample plus the STAR model (the model object carries the VAE it needs) and runs the latent through the temporal VAE - a Stable Video Diffusion autoencoder that knows frames aren't independent images, so consecutive frames decode consistently rather than drifting. The output is raw images, a standard ComfyUI IMAGE batch in the usual [frames, H, W, 3] 0–1 format, parked on the CPU. "Raw" is doing work there: these frames have been regenerated by the diffusion model and haven't been color-matched to your source yet. That's the next node's job (STAR Color Fix), and you'd be surprised how much of the "why does my upscale look washed out/different colored than the original" posts in this space are people stopping at decode instead of wiring the color fix.

The one knob, and why it exists

• vae_decode_chunk - frames decoded per VAE pass, default 1, range 1–8.

Default 1 means one frame per decode pass, which is the lowest possible peak VRAM - and it's the right default, because VAE decoding is the step that most often spikes memory at the end of a long run right when you thought you were done. If you have headroom (you finished sampling fine and have a 24GB card), raise it to 2–4 and decode gets noticeably faster; 8 exists for people with real memory to spare. The tooltip's phrasing is worth taking literally: one minimizes peak VRAM; increase only when enough VRAM is available.

There's a subtle design win baked into the split that you'll feel when you're iterating: decode chunk size is a pure VRAM/throughput trade with zero effect on the actual generated frames - the diffusion pass already happened and is deterministic from the latent. Because decoding is its own node, changing vae_decode_chunk re-runs only this node. In the older all-in-one STAR node this value invalidated the whole sampling pass, which meant fiddling with decode memory forced a full multi-minute re-upscale. Here it's a cheap knob you can wiggle freely.

Installing the pack

Search ComfyUI-STARWrapper in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/vjumpkung/ComfyUI-STARWrapper
cd ComfyUI-STARWrapper
pip install -r requirements.txt

Restart ComfyUI after. This pack needs a recent ComfyUI build - it's written against the comfy_api.latest V3 node API - plus CUDA PyTorch, a matching xformers (CUDA 13 is flagged as broken), and a hefty dependency list that includes diffusers (the SVD VAE this node uses comes through it), av, opencv-python, and a numpy<2.3 pin. The first run downloads the ~2–3GB STAR checkpoint plus the VAE and text-encoder weights automatically.

Troubleshooting

• OOM right at the end of a run - this is the decode spike. Drop vae_decode_chunk back to 1 before touching anything upstream.
• Frames that look blocky or banded - that's usually not decode; it's the raw output waiting for color fix, or an upstream issue. Run it through STAR Color Fix with your originals before judging quality.
• Type errors - decode needs the STAR latent from STAR Sample, not a ComfyUI LATENT from some other sampler. The custom types make it hard to miswire, and the error messages say so when you do.

Wire raw images into STAR Color Fix with your original frames as reference, and the graph finally produces something worth saving.