The Cost of Detail: Memory, Compilation, and Secondary Restoration

Choosing a restoration engine is only the beginning of planning a Jasna job. The next question is which resource is currently limiting the chosen path: GPU memory, system memory, one-time model preparation, or steady-state throughput. This chapter turns those constraints into a job plan and separates two upgrades that are often confused: a larger temporal clip can improve continuity, while a secondary restorer can enlarge a spatial patch. The reader should finish able to change the lever that owns the bottleneck and avoid paying for a feature the selected engine cannot use.

The cost of detail is not one number. It can appear as a longer first start, a larger model download, more VRAM, more repeated work at clip boundaries, a sharper but flickering patch, or a file that takes too long to finish. Jasna's settings make these costs visible, but they remain coupled. A change that improves one dimension can make another worse.

Find the binding resource first

GPU memory is often the most visible constraint because Jasna holds temporal clips, model state, crops, and intermediate results on the accelerator. Larger BasicVSR++ clips generally provide more temporal stability and can be faster because they repeat fewer overlap frames, but they consume more VRAM. A secondary restorer adds another workload after the primary patch exists. LTX has its own memory behavior and requires at least 8 GB of VRAM, with large-canvas processing needing roughly 12 GB of free VRAM for the large-mosaic case described by the project.

System RAM is a different resource. When VRAM is low, Jasna can move waiting frames to system RAM and bring them back as the pipeline needs them. That prevents every waiting frame from occupying the GPU, but it does not make an oversized active operation fit. The model and the working clip still have to run, and moving data between memory pools can affect throughput. “It did not crash” and “it is an efficient configuration” are not the same outcome.

Preparation time is different again. NVIDIA compilation happens before the steady-state job and is reused later. A first run can therefore be slow even when the per-video configuration is sensible. Steady-state throughput is the time needed to decode, detect, restore, blend, and encode after the relevant models are ready. Treating those as one bottleneck leads to the wrong fix: lowering clip size cannot remove a one-time model preparation step, while accepting a slow uncompiled path does not solve a clip that genuinely exceeds VRAM.

The fourth resource is throughput relative to the intended use. A job that will be watched once may not justify a lengthy high-detail render. A queue of many videos may justify compilation and a larger stable clip because the preparation cost is spread across repeated work. A live or browser workflow has a different threshold: it needs restoration to stay ahead of playback, not merely to finish eventually.

A resource diagnosis starts with the symptom and the stage that owns it. If the process cannot allocate the active clip, reduce the clip or remove a later stage.