SeedVR2 VAE Decode

The decode is the wall

Everything else in a SeedVR2 pipeline can be tamed. The decode is where it stops. ComfyUI's VAE Decode (Tiled) on this VAE decodes the whole clip in one call and keeps every decoded frame on the GPU until the end - the slicing path collects each slice and concatenates them at the finish. VRAM therefore grows with the frame count, and a 32 GB card tops out near 190 frames at 1080p. On a 30-second clip you get a third of the way through and then watch it fall over.

This node runs that same slice loop - same causal memory cache, same / scaling_factor, same even crop, same (x + 1) / 2 clamp - but moves each decoded slice to RAM as soon as it exists. VRAM becomes the decoder's working set for one tile, whatever the length of the clip. What bounds you now is system RAM, not your graphics card.

Inputs and outputs

samples (the LATENT from BC_SeedVR2VAEEncode), vae (the SeedVR2 VAE), and the same four tiling widgets as the native tiled decode: tile_size (1024), overlap (256), temporal_size and temporal_overlap. The temporal two are ignored, per the tooltip - the causal VAE slices time itself, and they're only there to match the core node's widget set. Don't tune them.

One output: IMAGE, shaped (B×T, H, W, 3), float16, values in [0, 1] - the decoded frames, ready for BC_SeedVR2PostProcess or straight to a save node if you're skipping colour correction.

Spatial tiling matches the native one (same latent-grid tiles, same pixel-grid cosine blend and count normalisation as tiled_vae), tile by tile with one causal cache at a time. The blend accumulates in float16 in RAM - about 12.5 MB per 1080p frame while the node runs - and is normalised in float32 per 4-frame chunk, so the result equals the native tiled decode inside float16 rounding.

What tile size actually means here

This is the one setting that decides whether the node runs at all. A tile that covers a whole 1080p frame needs over 31 GB of decoder working set - 2048 fails at the first slice even on a 5090. With a 1024 tile it's about 11 GB. So the defaults are the ones to use, and any urge to raise tile_size for "better quality" should be resisted: a bigger tile doesn't improve fidelity here, it just removes the blending and then OOMs.

The numbers the author measured on a 5090 (32 GB, 92 GB RAM), 720p to 1080p, 7B int8 DiT, both tiles at 1024/256: 901 frames - 30 seconds at 30 fps - in one piece, 18 minutes end to end, linear at roughly 36 seconds per second of video. VRAM stayed flat over the length. RAM is what bounded it: about 61 MB per 1080p frame across the graph's kept outputs, plus a fixed ~13 GB.

Like the encode node, it checks free VRAM against its working set first and unloads other models when it's short - the DiT stages in RAM and reloads on demand, because ComfyUI's own loader won't evict one dynamic model for another.

It logs the same way: a start line with frame and tile counts, then an update every 10 s with slice, tile, frame, VRAM used and an ETA.

Install

Manager: search ComfyUI-BCNodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/0xBeycan/ComfyUI-BCNodes

No pip step for this node - the pack's declared dependencies back two other nodes entirely. Look for it under BCNodes/seedvr2 after typing BCNodes in the node library.

Where people get burned

Frame count and RAM are now the limit, and nobody warns you. With VRAM flat, a long clip that used to fail loudly now just eats memory - 61 MB per 1080p frame adds up fast across a two-minute clip, and the graph's kept outputs count too. If the machine starts swapping, shorten the clip or close other work; dropping tile_size will not help with this one.

Do not touch the temporal widgets. They're ignored. Every minute spent wondering what temporal_overlap: 8 means is a minute you don't get back.

The colour correction still has to happen. Frames come out of here decoded but not matched to the original - that's BC_SeedVR2PostProcess's job, and skipping it is why some people's SeedVR2 output looks contrast-boosted compared to the input. Which, per every comparison thread on the subject, is the failure most often mistaken for "SeedVR2 looks bad".

Verify on your own card before a long run. tests/parity_seedvr2_video.py --vae … --tile … compares against VAE.decode_tiled (expected: equal after rounding to float16) and prints both peak VRAMs, which is a much better use of ten minutes than finding out at frame 400.