How JPEG XS Achieves Microsecond Latency

JPEG XS delivers sub-millisecond, visually lossless video compression designed specifically for live broadcast, medical imaging, and latency-sensitive IP workflows. Unlike traditional video codecs that measure latency in frames or tens of milliseconds, JPEG XS achieves an end-to-end delay measured in microseconds. This article examines the core architectural mechanics—line-based processing, lightweight wavelet transforms, and the elimination of inter-frame dependencies—that make this extreme performance possible.

Line-Based Processing Instead of Frame Buffering

Traditional compression standards like H.264 and HEVC require buffering entire frames or groups of pictures (GOP) to analyze motion across time. This buffering introduces significant latency, typically between 30 and 100 milliseconds or more.

JPEG XS replaces frame-based buffering with line-based processing. The codec only requires a minimal buffer of consecutive video lines (typically between 8 to 32 lines) to begin encoding. As video raster lines arrive from the sensor or source stream, compression begins immediately. This reduces the processing delay to just a fraction of a single frame duration. At 60 frames per second, a frame takes approximately 16.6 milliseconds; by operating on only a few lines, JPEG XS cuts the encoding and decoding latency down to mere tens or hundreds of microseconds.

Intra-Frame Only Compression

JPEG XS operates strictly on an intra-frame basis, meaning each video frame is compressed independently of any other. By removing inter-frame prediction, the codec eliminates the need to store reference frames in memory or wait for future frames (as required by B-frames in temporal codecs). This single-frame approach removes the memory bandwidth bottlenecks associated with temporal analysis and ensures predictable, constant latency across the entire transmission pipeline.

Lightweight Wavelet Transform

Rather than using complex mathematical transforms or heavy discrete cosine transforms (DCT) over large macroblocks, JPEG XS uses a lightweight 2D Discrete Wavelet Transform (DWT).

The wavelet transform splits the image into multiple frequency bands across vertical and horizontal directions with minimal mathematical complexity. Because it requires very few decomposition levels, the mathematical pipeline can be executed in hardware with minimal clock cycles per pixel. The transform preserves visual quality at moderate compression ratios (typically between 2:1 and 10:1) without requiring the heavy computing power that causes latency spikes.

Pipelined and Parallel Architecture

The internal pipeline of JPEG XS is designed to maximize parallel processing in silicon (ASICs and FPGAs) as well as modern multi-core CPUs and GPUs. The algorithm divides video frames into independent horizontal slices or vertical columns that can be compressed concurrently.

Because the algorithm has a low computational footprint and a flat entropy-coding structure, hardware implementations can stream data through the encoder and decoder continuously. The decoder can begin reconstructing the first pixels while the encoder is still compressing the end of the same frame.

End-to-End Latency Profile

By combining line-based buffers, intra-frame wavelet transforms, and parallel hardware pipelines, the combined encode-decode latency of JPEG XS is deterministic:

• Encoder Delay: Typically between 1 and 32 lines of video.
• Decoder Delay: Typically matching the encoder buffer, around 1 to 32 lines.
• Total Added Latency: Fractions of a millisecond (often under 200 microseconds depending on resolution and frame rate).

This microsecond-level performance allows JPEG XS to replace uncompressed video transport (such as uncompressed SDI or ST 2110-20) over IP networks, preserving live interactive control and real-time responsiveness while substantially lowering bandwidth requirements.