From Frame to Finished File: The Operating Pipeline
Jasna's central problem is not “how do I apply an enhancement filter to a video?” It is how to change selected regions while keeping the rest of a moving, encoded media stream coherent. This chapter follows one ordinary video job through that path—from decoding and selection to restoration, compositing, and output—so a reader can locate a missed region, a visible seam, a delay, or a broken file at the stage most likely to own it.
The most useful way to understand Jasna is to follow what crosses each boundary. Full frames enter the pipeline. Detection state identifies possible mosaics. Short temporal clips and region crops cross into restoration. Restored patches return with enough information to be placed back into their original frames. Finally, encoded video and accompanying streams leave the system. The pipeline is selective, but it never stops being a media pipeline: timing, order, format, and preservation remain part of the result.
A frame enters as media data, not as a finished picture
Before Jasna can decide what to restore, it has to read the input video. The documented path decodes video on the GPU, then passes frames to the detector. The public implementation also probes the input and validates metadata before choosing how to run the job. That early validation is easy to overlook because users experience it as “the file opened,” but it defines the conditions under which later stages can make sense: the pipeline needs dimensions, timing, color information, and a usable stream before it can associate a restored patch with the correct frame.
A decoded frame is therefore more than an image. It carries a position in time. Jasna uses that timing when it later writes a frame back to the output. If the frame is selected for restoration, its pixels may be copied into a region crop and its metadata remains available for final encoding. If the frame has no target region, it still has to pass through the output path in the correct order. Selective restoration does not mean selective existence: the final video still needs a complete, ordered timeline.
This distinction helps explain why Jasna offers both whole-video and more selective paths. In a whole-video job, the pipeline examines the stream continuously and decides which regions need work. In other workflows, the user or a scan supplies effect ranges, and the system can leave spans outside those ranges alone. The common architecture is the same: source frames remain the reference, while only selected work is sent through the costly restoration path.
Selection comes before restoration
The first consequential decision is not which restoration model to use. It is which part of each frame should be restored at all. Jasna detects mosaics in each frame and tracks them over time, grouping the frames belonging to a region into clips. That sequence turns scattered frame-level evidence into a work unit that a temporal restorer can process.
The separation between full frames and region work is the source of both efficiency and risk. A detector can inspect the entire frame, but the restorer does not need to reconstruct the entire frame. It receives the crop around a selected region. Meanwhile, the original full frame continues through the pipeline so that, later, the generated patch can be blended back into its proper surroundings. The detector and tracker own the question “where and when should work happen?” The restorer owns a different question: “given this selected evidence, what patch can be generated?”
That division also creates a clear diagnosis for a common disappointment. If a mosaic is never detected, no later model choice can recover it. The restoration stage cannot act on a region that never crossed the selection boundary. Conversely, a false detection can send an ordinary region through the pipeline and produce a change that the user did not want. Treating detection as a small prelude to the “real” AI work hides the first quality gate.
Once a region is selected, its frames are grouped into clips rather than processed as unrelated stills. The clip is the unit that carries temporal context into restoration and the unit that must eventually produce results in the right frame positions. The details of how tracks start, continue, and end become crucial in the next chapter; here the architectural point is enough: Jasna does not ask the restorer to solve an undefined whole video. It creates bounded, time-aware pieces of regional work.
A clip becomes a patch, not a replacement frame
Jasna's primary video restoration stage works on a crop around the detected mosaic. The crop is enlarged enough to include context, resized and padded for the model, and restored as a 256-by-256 patch. An optional secondary restorer may enlarge that patch before it returns to the frame. This is a deliberate interface: the restoration stage produces a regional result, while the original frame remains responsible for everything outside that region.
That interface makes the system easier to reason about. The model does not need to reproduce the entire composition, camera motion, or background. It is given a focused spatial problem and, in the video path, a clip of related frames. But the interface also limits what the model can know. The fixed patch size and the crop boundary constrain available detail. Enlarging a result can make it occupy more pixels, but enlargement is not the same as recovering information that was never present in the input or inferred reliably by the primary model.
When a restored patch returns, Jasna does not simply paste a rectangular image over the frame. The blend path uses a detection-derived mask, so the amount and shape of the change follow the selected region. At clip boundaries, crossfade weights can temper the transition between overlapping results. The surrounding pixels remain source pixels rather than becoming part of the model's generated output. In the current public implementation, this is also where the system waits until the result needed for a frame is ready before blending it.
This separation of responsibilities creates a useful boundary map. Crop preparation determines what context the restorer sees. Primary restoration determines the generated patch. A secondary stage may change its scale or appearance. The mask determines where the generated result is allowed to influence the source. The frame writer determines how that blended result is represented in the output. A soft patch, a halo, or a visible boundary may involve more than one of these interfaces; blaming “the model” by default is not a sufficient diagnosis.
The final arrow in the diagram is conceptual rather than a processing loop back into the decoder: the output is a new media artifact, not a second input to the job. Its important meaning is that video pixels and companion streams converge at the output boundary. A visually correct patch is not enough if the resulting file loses usable timing, audio, or container compatibility.
Separate workers keep the stream moving
The public implementation divides the normal pass into distinct stages: decode and detect, primary restoration, secondary restoration, and blend and encode. These stages communicate through bounded queues. A queue is simply a waiting area between workers, but its bounded size matters. It prevents a fast stage from accumulating an unlimited amount of data while a slower stage catches up. If restoration slows, upstream work eventually has to wait rather than consuming memory without limit.
This arrangement lets Jasna overlap work. While one batch of frames is being decoded and inspected, an earlier clip can be going through primary restoration. A previous result can be moving through a secondary stage while the encoder handles an already blended frame. The stages are not independent: the blend worker cannot write a frame that still needs an unfinished patch, and a restoration worker cannot process a clip that selection has not produced. The queues make those dependencies explicit without requiring the entire video to be held in memory.
Memory management follows the same boundary logic. The system can move waiting frames toward system RAM when GPU memory is tight and can offload or reclaim intermediates as stages progress. That does not create a fixed memory promise. The amount of memory still depends on input resolution, clip length, selected model, secondary restoration, driver behavior, and other processes using the GPU. The architecture manages pressure; it does not make the pressure disappear.
Cancellation also reveals why the stages are coordinated. Stopping a job is not just closing a window. Workers may be waiting on queues, holding temporary patches, or preparing frames for output. The public pass drains queues while threads finish so that a blocked producer does not keep the job alive indefinitely. This is an operational detail with a user-facing consequence: a pipeline that processes media progressively must also have a defined way to stop without leaving every stage in an ambiguous state.
Encoding decides what “finished” means
After blending, Jasna sends frames to a GPU encoder. The command line supports common GPU video codecs, and quality settings such as CQ influence the trade between visual quality and file size. The encoder can apply operations such as a color LUT or sharpening as the video is written, so those operations belong to the output path rather than to the primary restoration model.
The output path also carries information that is not visible in a screenshot. Jasna copies source metadata and chapters where the destination supports them, and it tries to copy non-video streams. Audio is re-encoded only when the output container cannot hold it in its original form. This behavior is a practical form of preservation: the system is not merely creating a sequence of restored images; it is assembling a media file whose companion streams and timing should remain usable.
Encoding choices can still change the final experience. H.264 favors broad playback compatibility but may produce a larger file at similar quality; HEVC and AV1 offer different combinations of compression and hardware support. Lower CQ generally aims for better quality and a larger file, while the documented source-tied bitrate ceiling can constrain output growth for low-bitrate inputs. A source that looks excellent in memory can therefore be disappointing after an overly aggressive encode, or inconvenient if the chosen codec is not supported by the intended player.
Selected-range rendering makes this boundary even clearer. When parts of a video are copied and other parts are rendered, the output must reconcile source packets with newly encoded fragments. The codec, frame timing, keyframes, and container rules matter. A successful visual render can still require a fallback or a local re-encode to make the pieces stitch safely. The result is not a contradiction of selective restoration; it is a reminder that frame-level locality and file-level preservation solve different problems.
A stage-based way to read the result
The pipeline gives a practical order for interpreting what went wrong. A region that remains untouched points first toward detection or selection. A region that appears intermittently raises a temporal-tracking question. A jump at a boundary points toward clip construction, scene handling, overlap, or blending. A result that is present but soft points toward the fixed primary patch size or the choice of secondary restoration. A long wait or memory failure points toward stage cost and queue pressure. A file with unexpected playback or audio behavior points toward encoding and container compatibility.
These are not rigid diagnoses: several boundaries can contribute to the same symptom. But they are better starting points than changing every setting at once. Jasna's value lies partly in making the path modular enough that a reader can ask which decision produced the observed behavior. The next chapter examines the first of those decisions in detail—how individual detections become a stable timeline of regions to restore, and why the system sometimes has to decide that a region has disappeared or a shot has changed.