toobusy FlashVSR Long Sampler

FlashVSR's headline problem is simple: it's a video upscaler that was trained to look at a window of frames, not a whole movie. Feed it a 10-minute clip in one go and it either OOMs or falls apart. toobusy FlashVSR Long Sampler is the node that makes long footage feasible - it splits your video into overlapping chunks, samples each with the DiT, and hands the results to the decoder as one latent bundle with the overlap bookkeeping already done.

How it works

It takes your images tensor, resizes to the working width/height (the pre-upscale size - half your target), and computes chunk boundaries: chunk_frames long, sliding by chunk_overlap frames so neighboring chunks share context. Each chunk is sampled through the loaded FlashVSR DiT with the KV/sparse attention ratios the model uses to stay fast, and the chunked latents - plus their overlaps - go into the flashvsr_latent payload the decoder consumes. Crucially, it loads the DiT, does all the chunk sampling, and releases it before the decoder ever touches the VAE. The pack deliberately does not globally cache GPU models between runs, so a sampler+decoder pipeline peaks at one big model at a time instead of both.

That memory discipline is the whole point. On a 24GB card, the validated setup is 1024x576 input, 21-frame chunks, 8-frame overlap - you get multi-minute upscales without the OOM that kills naive FlashVSR usage.

The inputs that matter

• flashvsr_model - from the Loader.
• images - your source frames (from a VHS / video-loader node).
• width / height - the sampling resolution before the 2x upscale. The VRAM & Resolution Preset node outputs these for you.
• scale - 2 or 4. 2 is the sweet spot for the v1.1 model.
• chunk_frames (21) / chunk_overlap (8) - the memory/quality trade. Bigger chunks = more context, more VRAM. The node clamps chunk_frames to your total frame count and overlap to a valid range, so bad input degrades instead of crashing.
• local_range (11), kv_ratio (3), sparse_ratio (2) - FlashVSR's internal attention compression knobs. These are "leave alone until you know why" territory; the presets and defaults are tuned.
• steps (1) - the DiT is a distilled one-step model by design; this node runs 1–8 steps if you want to refine.

Outputs and where they go

• flashvsr_latent - a dict-like payload (chunks, overlaps, total_frames) wired straight into toobusy FlashVSR Full Decoder. It's not a normal LATENT; that's fine, the decoder is the only consumer.

Install and gotchas

Same chain install as the rest of FlashVSR: pip install -r custom_nodes/toobusy/requirements_flashvsr.txt, plus the exactly-matching block_sparse_attn wheel for your Python/PyTorch/CUDA. No wheel match = nothing here runs.

Real-world notes. First, the width/height you feed here are half the output - the settings node exists so you don't miscalculate, use it. Second, don't crank chunk_frames to 81 on a 12GB card just because the max says so; the VRAM profile presets are paired with chunk sizes for a reason. Third, if your input is genuinely low-res (like 256p), FlashVSR is the wrong tool - that's SeedVR2 territory, and the community's head-to-heads are consistent about it. FlashVSR is for sources that are already reasonable and just need to be bigger, fast.