toobusy FlashVSR Full Decoder
Decode the chunks into one seamless video
- flashvsr_latent
- images
The sampler handled the VRAM problem; toobusy FlashVSR Full Decoder handles the seam problem. It takes the chunked latent bundle from the Long Sampler, runs each chunk through the VAE, and stitches them back together using the recorded overlaps so you don't see tile lines where one chunk ended and the next began. It's the last node in the FlashVSR chain, and the one that decides whether your upscaled video looks like one continuous clip or a patchwork.
How it works
FlashVSR's VAE is the Wan 2.1 VAE - you supply it here as a vae dropdown selecting from your models/vae/ folder. The decoder loads the VAE pipeline, decodes each chunk from the flashvsr_latent payload, and merges consecutive chunks using the overlap metadata the sampler recorded. The merge is where tiling and color handling matter: tiled runs a tiled VAE decode (the only sane option on mid-range cards), and color_fix applies color normalization so neighboring chunks don't land with a visible brightness jump. Like the sampler, it loads the VAE, decodes everything, and releases it - the chain never holds the DiT and the VAE in VRAM at once.
The tile_preset dropdown (safe / balanced / fast) is the quality/speed dial. Larger presets use more VRAM in exchange for less redundant tile computation. The author's own measured numbers on 12GB: "safe" handled a ~5-second FHD output from 0.8MP input in ~596 seconds at 8.69GB peak. That's a slow-but-alive number, and it's the honest price of FlashVSR on a small card. tile_preset_override (optional) lets you force a tile preset string from another node if you want to drive it dynamically.
The inputs that matter
flashvsr_latent- from the Long Sampler. Nothing else works here; the payload carries the chunk geometry.vae- pickWan2.1_VAE.pthfrom your VAE folder (placed there manually, per the README).tiled(on) - keep it on unless you have serious VRAM headroom; tiling is what makes multi-minute decodes possible on 24GB-class cards.color_fix(on) - keep it on. The most common "why is there a line through my video" answer is this being off.tile_preset- start atsafeon 12GB,balancedon 16GB,faston 24GB+. The VRAM & Resolution Preset node hands you the right string for your profile.
Outputs and where they go
images- a full IMAGE batch, trimmed to the original frame count. Into aCreate Video/ VHS save node, then you're done.
Install and gotchas
Part of the same FlashVSR chain install: requirements_flashvsr.txt plus the matching block_sparse_attn wheel, and the Wan 2.1 VAE file in models/vae/. If the vae dropdown is empty, that's the missing file, not a broken node.
Two things to keep in mind. First, decode is genuinely slow on low-VRAM cards - if "safe" feels glacial, that's expected behavior, and the fix is a smaller output resolution, not a faster tile preset. Second, color drift across chunks is a real FlashVSR artifact; color_fix catches most of it, but on very long clips or wildly-changing footage you may still see a flash at chunk boundaries - that's a model limitation, and the pack's own SCAIL-era work is where the community keeps hammering on the same problem. For normal footage, wire the chain once and forget the decoder exists.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| flashvsr_latent | TOOBUSY_FLASHVSR_LATENT | — | |
| vae | COMBO | 0 options: | |
| tiled | BOOLEAN | true | — |
| color_fix | BOOLEAN | true | — |
| tile_preset | COMBO | safe | 3 options: safe, balanced, fast |
| tile_preset_overrideopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |