FlashVSR for One-Step Streaming Video Super-Resolution
[CVPR 2026] Towards Real-Time Diffusion-Based Streaming Video Super-Resolution — An efficient one-step diffusion framework for streaming VSR with locality-constrained sparse attention and a tiny conditional decoder.
At a glance
- What is it?
- FlashVSR is a diffusion-based video super-resolution framework for 4x upscaled video streams with one-step inference. Its repository includes inference code and model weights, while sparse attention and a conditional decoder target latency and resolution constraints.
- Who is it for?
- Engineers working with GPU-accelerated 4x video restoration should evaluate FlashVSR when one-step diffusion, streaming state and high-resolution output are requirements. Do not adopt it as a general multi-scale super-resolution system or assume third-party services reproduce the official pipeline.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 21, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why FlashVSR targets streaming diffusion restoration
FlashVSR addresses video super-resolution, or VSR, through a diffusion model designed for continuous video processing rather than isolated frame restoration. The README says the project is primarily designed and optimized for 4x super-resolution. Its intended users are engineers and researchers who need to upscale video with diffusion while controlling latency, memory use and the number of inference steps.
The design responds to three documented constraints: diffusion-based restoration can have high latency and computation costs, and models may generalize poorly to ultra-high resolutions. FlashVSR reduces sampling to one step and adds mechanisms intended to preserve quality while processing video streams. According to the README, the reported configuration reaches approximately 17 FPS for 768 x 1408 video on a single A100 GPU. That figure is a project claim, not a result reproduced here, and it should not be treated as a hardware-independent throughput guarantee.
This is a specialized restoration tool. The repository does not document CPU-only operation, browser deployment, real-time guarantees for consumer GPUs, or broad scaling factors beyond the recommended 4x mode. A team choosing between conventional interpolation, conventional super-resolution and diffusion restoration must decide whether one-step generation and the reported high-resolution behavior justify the added model and GPU requirements.
FlashVSR's three-stage diffusion and streaming pipeline
The abstract identifies a train-friendly, three-stage distillation pipeline as the first core component. Distillation is described as the mechanism that enables one-step streaming super-resolution, reducing the iterative process associated with diffusion inference to a single generation step. The README does not expose the individual training commands, stage definitions, schedules or model configuration files, so the repository documentation does not allow a complete reconstruction of that training procedure.
The intended data flow is video input followed by a one-step diffusion restoration stage and reconstruction of the upscaled frames. Because the framework is streaming, its stateful behavior also involves temporal continuity between incoming video content. The README records a specific bug involving `local_attention_mask` when users switch between different aspect ratios during continuous inference. The maintainers changed its update logic to prevent artifacts. That detail matters operationally because a streaming model cannot be judged only on its first processed frame; state and mask handling can affect later output.
The repository contains a `diffsynth/` package and an `examples/WanVSR/` directory, while `setup.py` identifies the distributed Python package as `diffsynth`. The package version in `setup.py` is `1.1.7`, but the repository has no GitHub releases. The README also links separate Hugging Face entries for model v1 and v1.1, so the Python package version should not be used as a substitute for the model version.
Locality-Constrained Sparse Attention and the conditional decoder
Locality-Constrained Sparse Attention, abbreviated LCSA in the README, is the project's most important compatibility warning. The authors say it removes redundant computation while addressing the resolution gap between training and testing. Its stated purpose is to limit attention to relevant local context, allowing the model to handle high-resolution video without applying unrestricted dense attention over the same token set.
The distinction is not merely an optimization label in this project. The README states that some third-party ComfyUI implementations fall back to dense attention because they omit LCSA. According to the project, this can cause noticeable quality degradation at higher resolutions, including loss of fine structure, texture aliasing and visual artifacts. Community integrations therefore need to be checked for the actual attention path rather than judged by their package name or exposed interface.
The second architectural component is a tiny conditional decoder. The README credits it with faster reconstruction while retaining quality. This shifts some work away from a larger decoder and toward a lightweight conditional reconstruction stage. Neither LCSA nor the decoder configuration is documented in the repository README, so an adopter cannot calculate memory use, compare tile behavior or reproduce the paper architecture from the available repository files alone. The named mechanisms and their stated roles are clear; their exact implementation settings are not.
Installing dependencies and reaching a first inference run
The README is truncated during the Getting Started section, immediately after it says to follow local setup steps and recommends the 4x setting. It does not provide the complete installation command, model download command or inference command. The repository does expose the dependency manifest, `requirements.txt`, and a `setup.py` file, so those files are the places to inspect for environment setup rather than a documented command that can be reproduced safely here.
The manifest pins CUDA-oriented PyTorch packages, including `torch==2.6.0+cu124` and `torchvision==0.21.0+cu124`. It also specifies `huggingface-hub==0.34.4`, `transformers==4.46.2`, `opencv-python==4.11.0.86`, `imageio-ffmpeg==0.6.0`, `safetensors==0.5.3`, `numpy==1.26.4` and `accelerate==1.8.1`. The `setup.py` metadata declares Python `>=3.6` and exposes the package as `diffsynth` version `1.1.7`. These declarations describe packaging requirements, but they are not a substitute for the missing installation instructions.
For a first real run, follow the model-specific links in the README and confirm whether the intended checkpoint is v1 or v1.1. The README links model repositories on Hugging Face and says that inference code and weights are available. It does not state whether weights are automatically downloaded, how the input video is passed to the example, or what output path is created. The project homepage and the model pages are the documented starting points; any command presented as official would need to be taken from the untruncated Getting Started section or example source.
Failure modes around model variants and community integrations
The clearest documented failure mode is omission of LCSA by a third-party integration. This is not a warning that can be resolved merely by increasing a speed setting. The README says dense fallback can alter high-resolution details and create visual artifacts, so an integration that looks similar at low resolution may still fail the project's quality requirements.
Aspect-ratio switching is another documented risk in continuous inference. The October 21, 2025 bug fix specifically changed `local_attention_mask` update logic to avoid artifacts when moving between different aspect ratios. Applications that change crop shape or source geometry during one stream should therefore check the implementation revision used by their environment. The README does not describe behavior for arbitrary geometry changes beyond that fix.
The project has no GitHub releases, while its model assets are distributed through Hugging Face. This creates version-tracking work for operators: identify the model checkpoint separately from the `diffsynth` package, retain the repository revision used for inference and verify that a wrapper includes LCSA. The README also says it is unclear whether listed cloud services run v1, v1.1 or the complete pipeline. Those services should not be treated as equivalent reproductions without checking their implementation.
FlashVSR compared with conventional video upscaling
The relevant alternative is a conventional interpolation or super-resolution pipeline that applies a fixed filtering, reconstruction or neural upscaling method across video frames without a diffusion sampling process. The practical difference is architectural. Conventional pipelines generally exchange diffusion restoration for a simpler, more predictable operator; FlashVSR instead performs one-step diffusion and uses LCSA plus a tiny conditional decoder to control the cost.
That trade-off is not absolute. FlashVSR is intended for cases where diffusion-based reconstruction and streaming behavior are valuable, particularly the README's 4x setting. A conventional method may be easier to deploy when CPU support, deterministic lightweight operation, exact scaling beyond 4x or an established video-processing interface matters more than diffusion restoration. FlashVSR's documentation does not provide a side-by-side comparison with a named conventional package, so no specific alternative package can be selected from the repository README.
For cloud evaluation, the README lists third-party services including fal.ai, WaveSpeed AI and Segmind, but explicitly warns that their version and pipeline coverage are unclear. The official repository is the reference for reproducing the documented LCSA behavior, not every integration named in the community section.
Apache-2.0 licensing and maintenance signals
FlashVSR is distributed under the Apache-2.0 license, as stated in the repository metadata and license classification. This permits use and modification under that license's terms, subject to its conditions; this review does not interpret those terms or provide legal advice. Model weights hosted on Hugging Face may have their own repository terms, which are not reproduced in the README, so users should inspect those terms separately before redistribution or commercial deployment.
The repository is not archived. Its last push was on 2026-10-15. This is a recent repository signal, but it does not establish a release cadence. There are no GitHub releases, and the README points to model versions v1 and v1.1 through separate Hugging Face repositories. Upgrade planning therefore depends on checking the model page, repository commit and dependency pins rather than assuming semantic releases exist.
The README reports a v1.1 change focused on stability and fidelity, while the repository also lists a bug fix for aspect-ratio switching. That record gives concrete upgrade targets. It does not document a rollback procedure, migration guide for cached video state or compatibility matrix across checkpoints. Those omissions matter for a streaming service, where changing the attention implementation or model version can alter existing session behavior.
Editorial conclusion
Engineers working with GPU-accelerated 4x video restoration should evaluate FlashVSR when one-step diffusion, streaming state and high-resolution output are requirements. Do not adopt it as a general multi-scale super-resolution system or assume third-party services reproduce the official pipeline. Verify first that the required model version and Locality-Constrained Sparse Attention implementation are present, because the README warns that implementations without LCSA can lose detail and introduce artifacts.
Frequently asked questions
How do I install FlashVSR for Python?
The README is truncated before the complete setup commands. It points to local setup instructions and the repository provides `requirements.txt` plus `setup.py`, where Python and dependency requirements are declared.
Does FlashVSR support video super-resolution other than 4x?
The README says the project is primarily designed and optimized for 4x video super-resolution and strongly recommends that setting. It does not document other scaling factors as supported modes.
Why does a FlashVSR integration lose detail at high resolutions?
The README warns that some third-party implementations omit Locality-Constrained Sparse Attention and fall back to dense attention. It says this can cause quality degradation, texture aliasing and visual artifacts at higher resolutions.
Are FlashVSR model weights available?
Yes. The README says inference code and model weights are available and links separate Hugging Face repositories for FlashVSR v1 and v1.1.
Can I use FlashVSR through a cloud service instead of a local GPU?
The README lists several third-party cloud and API deployments. It warns that it is unclear which model version each service uses and whether it implements the full pipeline, so the official repository is the reference for reproduction.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/openimaginglab-flashvsr)