The Output Is Part of the Result: Encoding, Streaming, and Preservation

Jasna does not finish when a model produces a restored patch. The patch still has to become a usable media artifact, and that final step can change its visible quality, file size, audio, metadata, and delivery time. This chapter treats encoding and playback as part of restoration correctness. It explains how codec and CQ choices shape the delivered picture, what Jasna preserves from the source, and why a completed file, a growing fMP4, a browser stream, and the GUI Video Player represent different compromises.

The central distinction is between the image in memory and the media that reaches the viewer. A blended frame may look right before encoding, but the encoder chooses how that frame is quantized and stored. A video may contain more than a video stream, so audio, metadata, chapters, and other streams need a preservation policy. And a user who wants to watch immediately may accept a delivery path that cannot provide the most expensive restoration engine.

Encoding is a second quality boundary

Jasna supports HEVC, H.264, and AV1 for offline output, with GPU-specific encoder defaults and quality scales. The main quality control is CQ, or constant quality. Lower CQ generally aims for better visual quality and a larger file. That relationship is not a promise that every nearby value produces a different file size: the source-tied bitrate ceiling can make close CQ values converge when the limit becomes binding.

This matters because restoration changes the content that the encoder sees. A restored region may contain sharper edges or newly generated detail that needs more bits to remain legible. If the output is encoded too aggressively, the delivered file can throw away some of the visible benefit even though the model output was unchanged. If the output is allowed to grow without a reasonable ceiling, a low-bitrate source can become unexpectedly large.

Jasna's documented encoder behavior addresses that tension by tying an automatic bitrate ceiling to the source bitrate in many cases. The ceiling is intended to prevent a cheaply encoded source from expanding several times simply because CQ aims at a fixed quality target. It is not a guarantee that every source will fit a desired file size, and a user can replace it by setting a custom maxrate. A source without usable bitrate information receives a different treatment, so the behavior remains input-dependent.

The codec is also part of the delivery decision. Offline output can use the supported codec choices, while HLS streaming always uses H.264. A reader choosing a codec is therefore balancing the intended player, hardware encoder availability, quality, file size, and whether the job is a normal file or a stream. Smart-rendered selected ranges add another constraint: the output must remain compatible with the source fragments, and a different codec may not be allowed for the assembled result.

The right evaluation is the final file at its intended use. A preview that shows a sharp patch before encoding does not show whether the same edges survive the chosen CQ, codec, and container. A file that is visually good but cannot be opened by the target player is also not a successful delivery.