FlashVSR+ Upscale Video

If you're upscaling video rather than stills, this is the node you want and you can stop reading the other two. It takes a native ComfyUI VIDEO, keeps the audio, keeps the trim and crop somebody upstream already applied, and streams the thing through FlashVSR+ chunk by chunk instead of trying to hold a whole clip in VRAM at once.

Why native VIDEO and not a frame batch? Because the frame path loads the entire clip as one tensor in RAM, and video is exactly the case where you don't want that. The streaming path here reads and encodes incrementally - the author's 1080p validation ran an eight-chunk DiT pass with a peak input buffer of twenty frames.

How it works

Under the hood the node doesn't hand the VIDEO object straight to the model. It re-encodes your input to a temporary MP4 first - H.264, crf=0, ultrafast - which preserves the active trim and crop and carries the audio across. Then it reads that file, feeds bounded windows to the model, and writes the upscaled MP4 into a temp directory next to the real output. Only once the file is complete does it get renamed into place.

That last detail matters more than it sounds. Cancelled jobs don't leave a half-written MP4 in your output folder, and two concurrent runs can't fight over the same filename. The output directory gets a live file, so treat disk space as a real input: you'll transiently need room for the re-encoded source, the result, and the final copy.

The inputs

• model - from FlashVSR+ Model Loader.
• video - the VIDEO socket. Anything that outputs VIDEO works.
• scale - default 4. It's the same geometry logic as the frame node; 4× of 1080p is 8K, so think before you leave it there.
• width / height - override the sizing, one field preserving aspect ratio, both overriding outright.
• max_frames - default 0 (all of it). This is your friend: set it to 24, confirm the whole pipeline runs end to end, then unset it and go make coffee.
• filename_prefix - default FlashVSRPlus/FlashVSRPlus, relative to ComfyUI's output directory, so you get output/FlashVSRPlus/FlashVSRPlus_00001_.mp4 with the counter incrementing.

options (optional) takes FlashVSR+ Options, and with the Tiny decoder you almost certainly want it, because decode_every is what keeps long clips inside VRAM. The author's validated 1080p setup uses Turbo / Tiny / Triton / decode_every=4.

Outputs

video is a VIDEO object pointing at the MP4 that now exists on disk - feed it to a Save Video or preview node if you actually want it visible in the graph. info is a JSON string with the resolved path, content and canvas dimensions, mode, precision, the attention backend really used, and the seed. That path field is how you find the file when the graph tree has lost track of it.

Installing

ComfyUI Manager, search FlashVSR+ T8, install, restart. Registry ID flashvsr-plus-t8. Manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-Flashvsr-Plus-T8.git
python -m pip install -r Comfyui-Flashvsr-Plus-T8/requirements.txt

Run that pip with ComfyUI's Python, not your system one. Nothing in requirements.txt touches torch or transformers, which is the whole point of how this pack is packaged. Models auto-download to ComfyUI/models/flashvsr_plus on first run. You need a reasonably current ComfyUI for the VIDEO type and the pack declares >=0.36.0.

Troubleshooting

VAE uses full-clip decoding: set decode_every=0 in FlashVSR+ Options. You picked the Wan VAE decoder in the loader while the Options node still has decode_every=28. Tiny supports incremental decoding; the VAE doesn't. If long videos are your job, stay on Tiny.

Audio sounds different. Video that can't be muxed into MP4 - PCM, for instance - gets transcoded to AAC. It's not bit-identical, and this is normal.

Timestamps drift, or the length changes. The node works from the clip's declared frame rate and ComfyUI normalises variable-frame-rate sources to constant. Original per-frame PTS aren't preserved. If your source is VFR, normalise it to CFR before it enters the graph and save yourself the confusion.

It dies on an HD canvas with a mask-size error. That's SDPA refusing to build a full attention mask; the message tells you how many GiB it would have needed. Switch the loader's attention to triton_block_sparse - the README recommends Triton for HD output anyway. Shortening the clip won't help.

Slow is normal. "Fast" here is relative. It's still a diffusion model running over every frame, and the honest verdict from FlashVSR's launch was that it beat SeedVR2 on speed, not that it ran in real time. Where sources are genuinely low-resolution, SeedVR2 still wins on quality - 256px to 1024px is the comparison that keeps getting cited - so use this node when the source is decent and you want it done tonight.