A Codec Built for the Wrong Assumption

For decades, the broadcast industry operated on a reasonable assumption: high-quality video required either uncompressed transport or a compression scheme that accepted significant encoding latency. H.264 and H.265 produce excellent images at modest bitrates, but their encoding pipelines introduce hundreds of milliseconds of delay. Uncompressed video over SDI or SMPTE ST 2110 is lossless and near-zero-latency but demands enormous bandwidth, especially at 4K and HDR resolutions.

JPEG XS was built to challenge that assumption. It is a visually lossless, low-complexity compression standard that achieves 4:1 to 10:1 compression ratios with encoding latency measured in single-digit milliseconds, often less than one frame. It is not the right tool for distribution to end viewers. But for contribution, production, and live event workflows where image quality and latency both matter, it is a compelling option that is moving quickly from experimental to standard practice.

The migration creates a testing problem. JPEG XS transport over IP networks carries different characteristics than uncompressed ST 2110 flows, and those differences affect how network infrastructure needs to be validated. This post covers what makes JPEG XS transport testing distinct, what failure modes matter, and how WAN emulation and monitoring tools fit into a complete validation workflow.

What Makes JPEG XS Transport Different

JPEG XS is standardized by ISO/IEC 21122 and its integration with SMPTE ST 2110 is defined in SMPTE ST 2110-22, which specifies how compressed video using JPEG XS is transported as a packetized RTP stream. Understanding the transport layer characteristics is essential before designing a test plan.

Unlike uncompressed ST 2110-20 video, JPEG XS streams have variable bitrate output. Compression ratio varies with scene content: high-motion, high-detail scenes compress less and produce larger frames, while simple scenes compress more aggressively. This variability creates a bursty traffic profile that behaves differently in network queues than constant-bitrate uncompressed video.

The bitrates involved are still substantial. A 4K/60p signal compressed at 4:1 with JPEG XS runs at roughly 4 to 6 Gbps depending on color space and bit depth. At 10:1, that drops to 1.5 to 2.5 Gbps. These are not negligible figures, and the variable bitrate characteristic means instantaneous bandwidth demand can spike well above the average, which matters for switch buffer sizing and QoS configuration.

The low-latency requirement is where JPEG XS diverges most sharply from other compression schemes. The codec is designed to complete encoding within a single line of video, not a full frame. That sub-frame latency is the core value proposition for live production. But it means the receiving decoder has an equally tight timing window. Packets that arrive late do not just cause artifact risk the way they would in a buffered streaming application; they cause decoder failure because there is no buffer depth to absorb delay.

The Specific Failure Modes to Test For

JPEG XS transport testing needs to address four categories of failure, each driven by a different network impairment type.

Packet loss sensitivity. JPEG XS does not have a built-in error concealment mechanism the way some long-GOP codecs do. A lost packet means a lost portion of a frame, and the visual artifact is typically visible. Testing needs to characterize at what packet loss rate artifacts first become apparent, and how FEC (Forward Error Correction) performance varies with different loss patterns. Random loss and burst loss produce very different outcomes, and your test plan needs to cover both. We have worked with broadcast engineering teams who found their FEC implementation handled 0.1% random loss cleanly but failed visibly at 0.05% burst loss, because the FEC packet interleaving was insufficient to recover from correlated losses.

Jitter and timing conformance. SMPTE ST 2110-22 inherits the timing model from the broader ST 2110 framework, which means PTP-synchronized transmission with defined timing constraints on how packets are paced. Network jitter that pushes packets outside those timing windows will trigger alarms on a compliant monitor. Testing should measure the jitter tolerance of the receiving decoder, establish the jitter level at which PTP timing violations begin, and verify that the monitoring infrastructure correctly flags non-conforming flows.

Bandwidth contention. Because JPEG XS bitrate varies with content, a network configured to handle average bitrate will see periodic buffer stress during high-motion content. Testing should run bandwidth restriction scenarios where available capacity is set to 110%, 105%, and then 100% of peak expected JPEG XS bitrate to identify the headroom required for stable transport. Any packet drops caused by bandwidth contention will show up immediately in the output quality.

Latency accumulation. The sub-frame latency of JPEG XS encoding is only meaningful if the network does not add significant delay. Live production workflows are often latency budget-constrained end to end: a 10ms encoding latency target means the network path needs to contribute no more than a few additional milliseconds. Testing the contribution of WAN latency to total end-to-end latency, including queuing delay under load, is important for any workflow where JPEG XS is being used as a replacement for SDI contribution over fiber.

How WAN Emulation Fits Into JPEG XS Testing

ST 2110-22 JPEG XS transport testing over a real production network is impractical for most teams. You cannot deliberately introduce packet loss or bandwidth contention on a live path. You cannot reproduce a specific impairment scenario on demand for debugging. And you cannot run the same test multiple times with identical conditions to build statistical confidence.

WAN emulation solves all three problems. A hardware emulator placed in-line between the JPEG XS encoder and the decoder replicates any combination of latency, jitter, packet loss, and bandwidth restriction with full precision and repeatability. Configure the impairment profile, run the test, capture results, modify the profile, run again. The encoder and decoder see exactly the network conditions you specified.

The PacketStorm Hurricane VII platform is particularly well suited for JPEG XS testing because it operates at full line rate for 10G and 100G interfaces without hardware-level performance compromises. For high-bitrate JPEG XS flows at 4K resolutions, the ability to apply impairments at wire speed without affecting baseline timing accuracy is a requirement, not a nice-to-have.

Combining emulation with monitoring gives you the complete picture. While the WAN emulator introduces controlled impairments, our VIP Monitor measures ST 2110-22 flow conformance in real time, reporting on packet timing, flow identification, and any deviations from the standard. This lets you correlate a specific impairment level directly with a specific compliance outcome, which is exactly the data you need to characterize system tolerance and document it for stakeholders.

For teams working with FEC over JPEG XS, the SMPTE ST 2022-7 hitless protection workflow can also be tested in conjunction with JPEG XS flows, validating that the FEC and redundancy mechanisms perform correctly under the actual impairment profiles expected on the production network path.

Getting Test Coverage Right Before Deployment

JPEG XS adoption is accelerating. Major broadcast infrastructure vendors have added ST 2110-22 support across their encoder, decoder, and switch product lines, and the standard is appearing in live production, remote production, and contribution workflows at major broadcasters globally. That adoption pace means engineering teams are being asked to validate JPEG XS infrastructure on compressed timelines.

The cost of finding a failure mode in production is orders of magnitude higher than finding it in a structured pre-deployment test. A JPEG XS transport failure during a live broadcast event is not a minor technical issue; it is visible on screen, potentially to millions of viewers.

We built our test equipment lineup to give broadcast and network engineering teams the tools to do this validation correctly. If you are preparing for a JPEG XS deployment and want to discuss a testing approach that covers the failure modes above, reach out to the PacketStorm team. We can help you design a test plan that matches your specific encoder, decoder, and network path configuration.