BasicVSR++ or LTX: Choosing the Restoration Engine

Jasna presents BasicVSR++ and LTX as different operating points in the same selective pipeline. The choice is not a universal ranking between a “basic” and a “best” model. It is a decision about how much time, hardware, access, and uncertainty the job can carry for the media being restored. This chapter compares what each engine contributes, then turns LTX's requirements and exclusions into a conditional choice that can be tested before an expensive full run.

The quality-chain model from the earlier chapters supplies the criteria. Both engines still depend on detection, temporal evidence, crop geometry, and compositing. A different restorer does not make a missed region appear, repair a wrong track, or remove a mask boundary. The engine becomes decisive after the pipeline has selected usable evidence and the reader knows what the job is trying to optimize.

What BasicVSR++ buys Jasna

BasicVSR++ is Jasna's default video restorer. The project describes it as fast, free, and available on every supported GPU path, which gives it the broadest operating envelope of the two choices. It fits the normal workflow in which detected regions are grouped into temporal clips, restored as fixed-size patches, optionally enlarged, and blended back into the source frame.

Calling it the default is not faint praise. A default has to be useful across ordinary inputs, hardware choices, and time budgets. BasicVSR++ is the engine a reader can use without first committing to a supporter model, a large download, or an NVIDIA-only feature branch. It also remains the path used by Jasna's streaming and Video Player features, where the goal is to produce a result quickly enough to watch rather than to spend many minutes on each minute of video.

Its main optimization is practical throughput with temporal context. BasicVSR++ processes clips rather than treating every frame as an unrelated still, so clip length and overlap affect stability and resource use. The reader can tune that path around the available VRAM, reduce scope when necessary, and preserve the wider pipeline's ability to process ordinary video, VR180 through the BasicVSR++ route, and other supported GPU configurations.

That breadth comes with a sensible expectation. “Fast” does not mean “always sharpest,” and “default” does not mean “correct for every close-up.” The primary result remains a 256-by-256 patch, and large mosaics or high-resolution targets may look soft without a secondary restorer. BasicVSR++ is therefore a strong starting point when the job values compatibility, throughput, and manageable resource use, but the output still has to be judged inside the crop, across time, and at the final encoded resolution.

What LTX adds—and what it costs

LTX is the slower, supporter-only video branch for NVIDIA hardware. Jasna presents it as capable of more detail and more natural results than BasicVSR++, but the project also describes it as much slower—often measured in minutes per minute of video when mosaics stay on screen. Its purpose is not to make every workflow replace the default. It offers a different exchange: more time and a narrower environment for a model path the project believes can add detail in selected cases.

The two engines also organize work differently.